GitHub Actions (along with Azure DevOps) has emerged as a powerful managed tool that allows developers to automate workflows directly within their GitHub repositories. While GitHub provides hosted runners to execute these workflows, running your own GitHub runner can offer several advantages.

1. Money talks

One of the primary benefits of running your own GitHub runner is cost efficiency. GitHub Actions provides a certain number of free minutes for public and private repositories, but once you exceed these limits, costs can add up quickly, especially if your execution takes a while

2. Customization and Control

When you run your own GitHub runner, you gain full control over the environment in which your workflows execute. This means you can customize the runner’s operating system, software, and dependencies to match your project’s specific needs. It doesn’t matter anymore if you need a particular version of a programming language, specialized libraries, or specific system configurations, your self-hosted runner can be tailored to your requirements.

3. Performance and Speed

Self-hosted runners can significantly enhance the performance of your CI/CD pipelines. Since these runners are dedicated to your projects, you can optimize them for speed and efficiency. You can run builds on beefy machines, use faster storage, or even set up parallel execution across multiple runners to speed up your workflows. This is especially beneficial for larger projects or teams with multiple repositories or a bunch of members working in parallel.

4. Security and Compliance

For organizations handling sensitive data or operating in regulated industries, security is number one. Running your own GitHub runner allows you to maintain control over your CI/CD environment. You can implement your own security measures, restrict network access, and ensure that sensitive information does not leave your secured infrastructure. Additionally, you can regularly update and audit your runner to comply with internal policies or external regulations.

5. Reduced Queue Times

Using GitHub’s hosted runners means you may encounter queue times, especially during peak usage periods. By setting up your own runners, you can mitigate these delays, ensuring that your workflows kick off as soon as possible.

How do I get it running?

Step 1 – Clone the repository using the following command.

git clone https://github.com/slepix/GitHubRunner-Linode.git

You will need to prepare 5 things; it’s not hard, I promise.

1. Linode API token with permission to deploy virtual machines – more info
2. GitHub PAT limited only to the repository you want to connect – more details
3. GitHub repository name you want to connect your runner to.
4. GitHub username which owns the repository.
5. Root password for the runner VM – can be anything, as long as it’s long and complex.

Step 2 – Fill in the details in linoderunner.tfvars file; it should look something like this.

*These are random values, so make sure to replace them with your own.

linode_api_token = "eee44387b0030bd6bb051452bg65gz56z465fba5d77c5a238ea8e12f"
github_pat = "github_pat_1HG534e67d3K52IUSL_D2vM1pzjDGjX5sCiUEXWD6TRKDut4jnJty"
root_password = "Rand0mSecurePassword.123!" # Root password for your VM
github_repo = "myawesomeapp" # Your Github repo name
github_username = "slepix" # Your GitHub username

Step 3 – run the following command:

terraform apply --var-file="linoderunner.tfvars"

Entire codebase is available at https://github.com/slepix/GithubRunner-Linode

Ok, let’s take a look at some code. Once again, we’ll go with Terraform and cloud-init to deploy and configure our server. Ideally you would use some configuration management tool like Puppet, Ansible, Chef or similar, but for this use case, we can keep it simple.

Using cloud-init, we create a new user called “gitrunner” which will be used to run the agent, update all the packes, install jq (needed by the agent configuration script) and kick off the installation of the runner as a service.

compute.tf file – this is where you can adjust the region, OS and instance type you want to run.

resource "linode_instance" "github_runner" {
  image     = "linode/ubuntu22.04"
  region    = "nl-ams"
  type      = "g6-nanode-1"
  label     = "github-runner"
  root_pass = var.root_password  # Set the root password

  metadata {
    user_data = base64encode(templatefile("./linode.yaml.tpl", {
      githubpat = var.github_pat
      githubuser = var.github_username
      githubrepo = var.github_repo
    }))
  }
}

linode.yaml.tpl file

#cloud-config
package_update: true
packages:
  - jq

users:
  - name: gitrunner
    shell: /bin/bash
    groups:
      - sudo
    sudo:
      - ALL=(ALL) NOPASSWD:ALL

runcmd:
  - export RUNNER_CFG_PAT=${githubpat}
  - su gitrunner -c "cd /home/gitrunner && curl -s https://raw.githubusercontent.com/actions/runner/main/scripts/create-latest-svc.sh | bash -s ${githubuser}/${githubrepo}" 

If all went good, you should see the new GitHub runner appear in your runner overview in a few mins.

Happy building and deploying!

Alex!

The post Get your own own Github runner deployed and configured on Linode in less than 5 minutes. first appeared on Architect the cloud.

Part 2 – Defining the project

Part 3 – this post

Welcome to the third post of “Building your IT landscape on Akamai Connected Cloud” series.

In this post we will start writing and breaking down our FR’s and NFR’s.

What are those you may ask?

Non-Functional requirement (NFR)

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.^[1]

Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of “system shall do <requirement>”, an individual action or part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model. In contrast, non-functional requirements are in the form of “system shall be <requirement>”, an overall property of the system as a whole or of a particular aspect and not a specific function. The system’s overall properties commonly mark the difference between whether the development project has succeeded or failed.

Non-functional requirements are often called the “quality attributes” of a system. Other terms for non-functional requirements are “qualities”, “quality goals”, “quality of service requirements”, “constraints”, “non-behavioral requirements”,^[2] or “technical requirements”.^[3] Informally these are sometimes called the “ilities“, from attributes like stability and portability. Qualities—that is non-functional requirements—can be divided into two main categories:

1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.^[4][5]

It is important to specify non-functional requirements in a specific and measurable way.^[6][7]

Functional requirements

In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a specification of behavior between inputs and outputs.^[1]

Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish.^[2] Behavioral requirements describe all the cases where the system uses the functional requirements, these are captured in use cases. Functional requirements are supported by non-functional requirements (also known as “quality requirements”), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form “system must do <requirement>,” while non-functional requirements take the form “system shall be <requirement>.”^[3] The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture.^[4][5]

As defined in requirements engineering, functional requirements specify particular results of a system. This should be contrasted with non-functional requirements, which specify overall characteristics such as cost and reliability. Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system.^[4]

Non-Functional requirements

Scalability: The architecture must support horizontal scaling by dynamically adding or removing servers based on demand. It should utilize auto-scaling groups and container orchestration platforms to efficiently manage resource allocation.

High Availability: The system must achieve a minimum uptime of 99.999%, employing fault-tolerant design patterns such as redundant server clusters, load balancers, and automatic failover mechanisms. It should utilize multi-region deployment to ensure high availability across geographically distributed data centers.

Performance: The system should maintain a maximum network latency of 50 milliseconds and aim for an average response time of under 100 milliseconds for all critical operations. It should optimize database queries, utilize in-memory caching, and employ content delivery networks (CDNs) for efficient content distribution.

Security: The architecture must enforce end-to-end encryption for data transmission, employing industry-standard cryptographic protocols (e.g., TLS) and secure key management practices. It should implement fine-grained access controls, two-factor authentication, and intrusion detection and prevention systems (IDS/IPS) to safeguard user data.

Data Backup and Recovery: The architecture should perform regular backups of user profiles, game progress, and configuration data, leveraging incremental backups and differential techniques for efficient storage utilization. It must implement backup redundancy across multiple geographically dispersed data centers and employ automated backup integrity verification.

Geographic Distribution: The system should utilize globally distributed data centers strategically placed to reduce network latency, leveraging content delivery networks (CDNs) and edge computing technologies. It should employ geo-routing techniques to direct users to the nearest data center, minimizing network hops.

Load Balancing: The architecture should employ dynamic load balancing algorithms based on factors like server capacity, network latency, and current workload. It should utilize intelligent load balancers that distribute traffic evenly across available servers while considering resource utilization metrics.

Elasticity: The system should dynamically scale compute and storage resources based on real-time demand, leveraging auto-scaling policies, and cloud provider-specific scaling features. It should employ predictive scaling algorithms based on historical usage patterns and anticipated traffic spikes.

Network Performance: The architecture must ensure low packet loss rates (<0.5%) and maintain a minimum network bandwidth of 100 Gbps for optimal delivery experiences. It should utilize advanced network protocols and traffic optimization techniques (e.g., congestion control, Quality of Service) to minimize latency and packet jitter.

Cross-Platform Compatibility: The system must provide consistent gameplay experiences across various platforms (Windows, macOS, Linux, Xbox, PlayStation, iOS, Android). It should support platform-specific optimizations (e.g., DirectX, Vulkan) and employ adaptive streaming technologies to adjust game quality based on device capabilities.

Content Delivery: The architecture should leverage a globally distributed content delivery network (CDN) with edge caching to accelerate game content delivery. It should utilize HTTP/2 or QUIC protocols for efficient content transmission and employ delta compression and differential updates to minimize bandwidth usage during game updates and patches.

Integration with Third-Party Services: The system should provide well-documented APIs and SDKs for seamless integration with payment gateways, social media platforms, and analytics tools. It should support OAuth 2.0 for secure user authentication and authorization, and employ asynchronous messaging protocols (e.g., AMQP) for reliable inter-service communication.

Compliance and Legal Requirements: The architecture must comply with relevant data protection regulations (e.g., GDPR, CCPA), ensuring user consent management, anonymization of personal data, and secure storage practices

Monitoring and Analytics: The architecture should include a comprehensive monitoring and analytics framework that collects real-time performance metrics, system logs, and user behavior data. It should leverage centralized logging systems, distributed tracing, and log aggregation tools for efficient monitoring and troubleshooting. Additionally, it should employ machine learning algorithms and anomaly detection techniques to identify potential security threats and performance bottlenecks.

Modularity and Extensibility: The architecture should be designed with a modular and extensible approach, using microservices and service-oriented architecture (SOA) principles. It should allow for the seamless integration of new game titles, features, and external services by leveraging containerization technologies (e.g., Docker) and orchestration platforms (e.g., Kubernetes). The system should facilitate independent deployment and scalability of individual components without impacting the overall system performance or user experience.

FUNCTIONAL REQUIREMENTS

Game Storage and Management: The infrastructure should provide a scalable and efficient storage solution for hosting game files, patches, updates, and downloadable content. It should support large file storage and provide mechanisms for organizing and managing game assets.

Content Distribution: The infrastructure should incorporate a content delivery network (CDN) or a similar mechanism to distribute game files and updates to users globally. It should ensure low-latency and high-bandwidth content delivery for optimal user experience.

File Compression and Optimization: The infrastructure should include tools and processes to compress and optimize game files, reducing their size without compromising quality. This helps minimize bandwidth requirements and improves download and installation times.

Bandwidth Management: The infrastructure should monitor and manage bandwidth usage effectively to ensure fair allocation and prevent congestion during peak usage periods. It should implement traffic shaping or rate limiting mechanisms to optimize network performance.

Dynamic Scaling: The infrastructure should support dynamic scaling to accommodate fluctuations in user demand for game downloads and updates. It should automatically scale resources, such as storage capacity and network bandwidth, to handle increased traffic and ensure fast and reliable file delivery.

Redundancy and Data Replication: The infrastructure should implement redundancy and data replication mechanisms to ensure high availability and data durability. It should replicate game files across multiple storage nodes or data centers to mitigate the risk of data loss and minimize downtime.

Parallel Processing: The infrastructure should leverage parallel processing techniques to optimize the distribution of large game files. It should split files into smaller chunks and distribute them concurrently to speed up downloads and ensure efficient utilization of network resources.

File Integrity Verification: The infrastructure should incorporate mechanisms to verify the integrity of game files during storage and transmission. It should use checksums or other hashing algorithms to detect and handle corrupted or tampered files, ensuring users receive error-free game content.

Metadata Management: The infrastructure should provide a robust metadata management system to store and retrieve information related to game files. It should support efficient indexing and searching of game metadata, enabling users to discover and access relevant game content easily.

Version Control and Rollbacks: The infrastructure should facilitate version control and rollbacks for game files and updates. It should enable users to access previous versions of games and easily revert to a stable version in case of issues with new releases.

Secure File Transfer: The infrastructure should ensure secure transmission of game files and updates over the network. It should utilize encryption protocols (e.g., SSL/TLS) to protect data during transit, preventing unauthorized access or tampering.

Geo-replication and Regional Caching: The infrastructure should support geo-replication and regional caching of game files to reduce latency and improve download speeds for users in different geographical locations. It should strategically place storage nodes or caching servers in proximity to users for efficient content delivery.

User Account Storage: The infrastructure should provide secure and scalable storage for user account data, including profiles, preferences, and game libraries. It should ensure fast retrieval of user-specific information to enable personalized experiences across different devices.

API for Content Management: The infrastructure should offer APIs for seamless integration with game developers and content providers. It should provide functionality to upload, manage, and distribute game files programmatically, allowing for automated content ingestion and updates.

Usage Analytics and Reporting: The infrastructure should include analytics and reporting capabilities to track usage statistics, such as download counts, bandwidth consumption, and user engagement with game content. It should provide insights to improve content delivery strategies and optimize resource allocation.

In the next post, we will finally get to the “meaty” part and start drawing some architecture diagrams and writing some code.

Cheers, Alex.

The post Building your IT landscape on Akamai Connected Cloud – Part 3 – Writing down requirements first appeared on Architect the cloud.

I’m sure all of you have been in a situation where after deploying Compute Instances, it’s almost always needed to perform additional configuration before your server is ready to do any real work.

This configuration might include creating a new user, adding an SSH key, installing software, etc…it could also include more complicated tasks like configuring a web server or other software that runs on the instance. Performing these tasks manually can be error prone, slow and is not scalable.

To automate this process, Linode offers two provisioning automation tools: Metadata/cloudinit and StackScripts.

Cool, but what is Linode’s Metadata service? Well, in a nutshell it’s an API which is accessible only within your instance, nothing more

While the Metadata service is designed to be consumed by cloud-init, there are no barriers in using it without cloud-init and with any other software/script you can think of. If your software can send and read http requests, it can use Linode’s metadata service.

This allows you to use the same tools across multiple cloud providers enabling you to be really flexible on where and how you run your workloads.

One of the great use-cases for metadata is to dynamically configure your environment based on instance tags or some other parameters.

Let’s take this example; we have our dev and production environment and we want to make sure that the VM which we deployed is configured in the same way, just with different user data (test database vs a production database). Your deployment pipeline process can query the instance’s metadata service, read the tags and instantly know that it’s deploying to a test environment and which database to use.

Other use-case is for bootstrapping your servers and installing some configuration management agents like Chef or similar.

The Metadata service provides both instance data and optional user data, both of which are explained below:

• Instance data: The instance data includes information about the Compute Instance, including its label, plan size, region, host identifier, tags and more.
• User data: User data is one of the most powerful features of the Metadata service and allows you to define your desired system configuration, including creating users, installing software, configuring settings, and more. User data is supplied by the user when deploying, rebuilding, or cloning a Compute Instance. This user data can be written as a cloud-config file, or it can be any script that can be executed on the target distribution image, such as a bash script.User data can be submitted directly in the Cloud Manager, Linode CLI, or Linode API. It’s also often programmatically provided through IaC (Infrastructure as Code) provisioning tools like Terraform.

Ok, how do I use metadata service? It’s really quite simple

1. Log into the instance which is running an OS image which supports metadata service
2. Generate your API token using the following command

export TOKEN=$(curl -X PUT -H "Metadata-Token-Expiry-Seconds: 3600" http://169.254.169.254/v1/token)

This will put the authentication token into a TOKEN variable.

3. Fetch the data

#Instance info
curl -H "Metadata-Token: $TOKEN" http://169.254.169.254/v1/instance
#Network info
curl -H "Metadata-Token: $TOKEN" http://169.254.169.254/v1/network
#User data
curl -H "Metadata-Token: $TOKEN" http://169.254.169.254/v1/user-data | base64 --decode

What data do I get back?

#Instance info
root@localhost:~# curl -H "Metadata-Token: $TOKEN" http://169.254.169.254/v1/instance
backups.enabled: false
host_uuid: 85815b0f16cfa8b12aa12a36530476e701111111
id: 51048111
label: jumphost-us-iad
region: us-iad
specs.disk: 25600
specs.gpus: 0
specs.memory: 1024
specs.transfer: 1000
specs.vcpus: 1
tags: app:jumphost
tags: region:us-iad
tags: stage:dev
type: g6-nanode-1

#Network info
root@localhost:~# curl -H "Metadata-Token: $TOKEN" http://169.254.169.254/v1/network
ipv4.public: 172.233.197.127/32
ipv6.link_local: fe80::f03c:93ff:fe56:3512/128
ipv6.slaac: 2600:3c05::f03c:93ff:fe56:3512/128

Cheers, Alex!

The post Linode’s Metadata service is live! first appeared on Architect the cloud.

While Network Helper is really useful, it’s becomes a problem when you deploy an instance serving as an internet gateway in your VLAN. In order to assign an IP address, DNS and a gateway, we need to deploy a DHCP server. Network Helper cannot set DNS and gateway settings.

Please have in mind that you can also install the DHCP server on your IGW (Internet gateway) instance as well, but for the purposes of this post, we will assume that we have a standalone DHCP server.

First thing we need to do is to create a Linode StackScript which we will use to automatically install and configure our DHCP server.

#!/bin/bash
#<UDF name="DEFLEASETIME" Label="Default lease time" example="3600" />
#<UDF name="MAXLEASETIME" Label="Max lease time" example="14400" />
#<UDF name="SUBNET" Label="Subnet" example="10.10.10.0" />
#<UDF name="NETMASK" Label="Netmask" example="255.255.255.0" />
#<UDF name="STARTRANGE" Label="Start range" example="10.10.10.10" />
#<UDF name="ENDRANGE" Label="End range" example="10.10.10.250"/>
#<UDF name="ROUTER" Label="Router" example="10.10.10.1" />
#<UDF name="DNS1" Label="DNS1" example="10.10.10.2" />
#<UDF name="DNS2" Label="DNS2" example="10.10.10.3" />
apt update -y
apt install -y isc-dhcp-server
mv /etc/dhcp/dhcpd.conf{,.backup}
cat > /etc/dhcp/dhcpd.conf << EOF
default-lease-time $DEFLEASETIME;
max-lease-time $MAXLEASETIME;
authoritative;
 
subnet $SUBNET netmask $NETMASK {
 range $STARTRANGE $ENDRANGE;
 option routers $ROUTER;
 option domain-name-servers $DNS1, $DNS2;
}
EOF
sed -i 's/INTERFACESv4=""/INTERFACESv4="eth1"/' /etc/default/isc-dhcp-server
systemctl restart isc-dhcp-server.service

After we’ve got our StackScript created, we can deploy a VM from it by clicking on “Deploy New Linode” button and filling out all the required details. Make sure that you assign the virtual machine to the VLAN you are using in your region.

You can use default settings for “Default lease time” and “Max lease time“, just make sure to adjust the “Subnet” and mask to match the ones you’re using in your VLAN.

We can also use Terraform to create our Stackscript by using “linode_stackscript” resource – https://registry.terraform.io/providers/linode/linode/latest/docs/resources/stackscript

For details on how to use Terraform to deploy instance from a StackScript, check out this blog post on how to use “stackscript_data” block to provide StackScript parameters – https://blog.slepcevic.net/deploying-linode-marketplace-stackscripts-with-terraform/

Cheers, Alex.

The post How to deploy a DHCP server in a Linode VLAN first appeared on Architect the cloud.

Quick glance at Linode’s Terraform provider shows that we can deploy instances using StackScripts, but in order to do that, we need to specify the StackScript ID. If we are deploying from our own StackScript, it’s easy, you just reference it like this and you’re good to go.

resource "linode_stackscript" "foo" {
  label = "foo"
  description = "Installs a Package"
  script = <<EOF
#!/bin/bash
# <UDF name="package" label="System Package to Install" example="nginx" default="">
apt-get -q update && apt-get -q -y install $PACKAGE
EOF
  images = ["linode/ubuntu18.04", "linode/ubuntu16.04lts"]
  rev_note = "initial version"
}

resource "linode_instance" "foo" {
  image  = "linode/ubuntu18.04"
  label  = "foo"
  region = "us-east"
  type   = "g6-nanode-1"
  authorized_keys    = ["..."]
  root_pass      = "..."

  stackscript_id = linode_stackscript.foo.id
  stackscript_data = {
    "package" = "nginx"
  }
}

“Problem” comes when we want to deploy a product from the marketplace, in order to do that we need to collect a few things first.

1. ID of the StackScript you want to deploy
2. List of supported OS images
3. Check which variables we need to provide to the StackScript.

Step 1 – Fetching the StackScript ID. In this case, I’ll do it using linode-cli, but you’re free to use any other method

linode-cli stackscripts list --label "Redis Sentinel Cluster One-Click"

Output of this command looks like this

From here, we need to write down the ID of the script, and check the list of supported images. In this case, I’ll deploy a stackscript with the ID 1132204 which is owned by Linode.

Next step is to check which variables we need to provide to the StackScript. We can easily see that by running the following Powershell command:

$stackscripts = ((wget https://cloud.linode.com/api/v4/linode/stackscripts?page_size=500).Content | convertfrom-json)
$stackscripts.data | where {$_.id -like "1132204"} | select -expand user_defined_fields
name                   label
----                   -----
token_password         Your Linode API token
sudo_username          The limited sudo user to be created in the cluster
sslheader              SSL Information
country_name           Details for self-signed SSL certificates: Country or Region
state_or_province_name State or Province
locality_name          Locality
organization_name      Organization
email_address          Email Address
ca_common_name         CA Common Name
common_name            Common Name
clusterheader          Cluster Settings
add_ssh_keys           Add Account SSH Keys to All Nodes?
cluster_size           Redis cluster size

And finally put all of those variables into our Terraform code, which in end looks something like this:

resource "linode_instance" "redis" {
        image = "linode/ubuntu22.04"
        label = "RedisCluster"
        group = "Redis"
        tags = [ "stage:dev" ]
        region = "eu-central"
        type = "g6-standard-1"
        authorized_users = [ "yourUsername" ]
        root_pass = "SuperRandomPassW0rd.123!"
        stackscript_id = 1132204
        stackscript_data = {
            "token_password" = "yourLinodeToken"
            "sudo_username" = "myuser"
            "sslheader" = "Yes" #Default YES
            "country_name" = "NL"  #Two letter country code
            "state_or_province_name" = "South Holland" 
            "locality_name" = "Rotterdam" 
            "organization_name" = "Org Name" 
            "email_address" = "yourEmail@here.com" 
            "ca_common_name" = "Redis CA" 
            "clusterheader" = "Yes" 
            "add_ssh_keys" = "no" #yes or no
            "cluster_size" = "3" #3 or 5
        }
}

Notice we are required to provide our Linode token in order to deploy this cluster; this can be the same token you’re using for your existing Terraform code, so you can simple reference a environment variable in your code and off you go

Cheers, Alex.

The post Deploying Linode Marketplace StackScripts with Terraform first appeared on Architect the cloud.

For us to actually start using the solution, we need to do a few things:

1. Create the users
2. Create or import SSH keys & configure 2FA using Google Authenticator
3. Configure network and firewalls around our jumphost and rest of the infrastructure
4. Connect

Creating users

Creating users is extremely easy doing Cockpit; on top of that, it gives the users to self manage their keys and 2FA configuration.

1. Go to the URL or IP of the Cockpit server you just deployed and log in using the credentials you’ve configured in your StackScript.
2. On the left hand side, click the “Account” menu option and then on “Create new account” button
3. Enter the user details and press “Create button”.

After the user(s) has been successfully created, let’s switch to the user’s point of view and see how rest of the onboarding process looks like.

1. Log in with the user’s credential we’ve just created and navigate to “Terminal” option.
2. Once there, type in: google-authenticator and press enter. This will start the process of configuring your 2FA authentication
3. You are free to modify the authentication behavior, just make sure to save the authenticator file when the wizard asks you to do so.

As a final step, we just need to upload our SSH public key and we’re all set to start securely connecting to our infrastructure.

Entire procedure is really straight forward; go to “Accounts”, click on your username, and on the right hand side, under the “SSH Keys” section, click the “+” button. Paste you PUBLIC ssh key and click “Add Key” button.

That’s it! You’re done! In the upcoming blog posts, I’ll talk how to configure your local machine to connect to your infrastructure, how to secure the infrastructure you’re connecting to, and finally, how can we make this solution highly available.

Cheers, Alex.

The post Installing and configuring 2FA enabled web managed access solution (jumphost) to any infrastructure deployed on Akamai Connected Cloud Compute – part 2 first appeared on Architect the cloud.

Related posts

Part 1 – Intro

Part 2 – this post

Welcome to the second part of the “Building your IT landscape on Akamai Connected Cloud” series.

In this post we will define the basic scenario and requirements for our “demo” project which we will build on Akamai Connected Cloud.

SCENARIO

We have a company called “Vapor” which is an online only company selling games and offering them for download.

Having bad experiences with a MSP, they turned to Akamai for help.

Besides aiming for better performance, Vapor’s DevOps team wanted to be more hands-on and have the ability to tweak the things “under the hood” so the entire solution can be rearchitected down the line to fit the new cloud provider.

Project has two major phases; first and critical phase is to do a lift and shift of the current platform and improve it with minimum amount of effort; introduce monitoring and management software and create pipelines. Current solution experiences a lot of downtime which directly correlates to lost revenue.

Second phase is to containerize and modernize the entire stack by utilizing Akamai’s managed Kubernetes service (LKE) and compute capabilities. Additionally, Vapor has plans to establish presence in APAC, EMEA and AMER regions in the near future so that requirement should be taken into consideration while designing the infrastructure.

Current Tech stack

Custom made application based on PHP and MySQL with few thousands of articles.

Application is running on eight web servers behind a load balancer. Standalone host is running MySQL database engine, while game data is stored in object storage 200 TB in size.

Hardware specifications

• 8 x Web servers: 16 CPU cores, 64 GB RAM, 200 GB SSD
  • Average CPU usage is 70%
  • 80% memory usage
  • 400 IOPS on average
• Database server: 32 CPU cores, 128 GB RAM, 500 GB SSD
  • DB is around 300 GB and growing 10% every quarter
  • 90% RAM usage
  • 5500 IOPS on average, with occasional spikes to 10000 IOPS
• Load balancer
  • 1000 requests/s on average, with occasional spikes to 2500 req/s.
• Object storage
  • Currently hosted with a different cloud provider

Monitoring and management is handled by the current MSP, so we have an open playing field when it comes to choosing technologies which we will use for monitoring, access, security, etc…

Simplistic overview of the current infrastructure

Where do we want to be in the future?

Before we start writing any code (yes, everything we will do will be done in code), we need to define our project goals, functional and non-functional requirements and try to predict the future a bit

Let’s start with the main project goals;

• Improve availability
• Lower hosting costs compared to the current provider
• Improve performance
• Build for scale
• Accommodate new modernization efforts which are in the pipeline
• Support world wide presence with the ability to do edge computing in the future
• Make it secure
• Make it easy to run
• Make it automated
• Make developers happy <3

Overview of the new infrastructure layout

As you can see, our infrastructure layout can be broken down into classic DT(A)P approach, along side a management and backup account.

Our management account will run all “operational” services we need to run our infrastructure, like monitoring, build and deployment pipelines, security tooling, secure access services, etc…, while we will have Development, Test and Production accounts for our dev/test and production workloads.

Goal will be to make our development, test and production accounts identical in every aspect besides scale. That will ensure that all infrastructure and application tests we will be running are giving realistic results.

Finally, we will have a dedicated Akamai Connected Cloud account in a different region where we will run our backup software and DR infrastructure.

Additionally, any Akamai Connected Cloud service we might need (like virtual machines, object storage, LKE clusters, etc…) will also be deployed in it’s own corresponding (DTAP) account.

Our intention is to have all environments physically and logically separated as much as possible.

Entire infrastructure will be built using code, primarily Terraform and Ansible for the first phase, while for the second phase, we will look into using some Kubernetes and application management tooling and pipelines. TBD.

In the next post we will start to define our functional and non-functional requirements for the entire project, drilling down into specific category and start defining our roadmaps.

Cheers, Alex.

The post Building your IT landscape on Akamai Connected Cloud – Part 2 – Defining the project first appeared on Architect the cloud.

Part 1 – Intro

Part 2 – Defining the project

Intro

These blog post series will serve as an example on how to utilize Akamai Connected Cloud to build and run your company’s IT landscape.

In the series we will cover everything from infrastructure design, building the infrastructure using modern IaaC tools, to management and monitoring.

After going through the infrastructure part, we will shift focus on building our application’s build and deployment pipelines.

As a final part of the series, we will round it up with security tooling

Plan:

• Define the project
• Write down requirements
• Build infrastructure diagrams
• Build the infrastructure
  • Terraform for IaaC
  • Ansible/Puppet/Chef for configuration management (TBD)
  • Core infrastructure
  • Management infrastructure
  • Monitoring infrastructure
  • Build/deployment infrastructure
• Build pipelines
• Security tooling
• Management lifecycle
• Modernize

What is Akamai Connected Cloud?

Akamai Connected Cloud delivers enterprise-grade, cloud-based solutions at scale around the globe. Akamai’s cloud computing services place compute, storage, database, and other services closer to your customers, key industries, and IT centers. 

This means developers can focus on coding while Akamai handles the infrastructure, placing your workloads according to your needs and delivering apps where and when your users want them. Our aggressive egress pricing is designed to bring CDN-like economics to cloud data transfer, offering significantly discounted rates compared with other cloud providers, helping you maximize your cloud ROI.

Build, deploy, and secure performant workloads

Akamai Connected Cloud is a continuum of compute from core to edge, paired with our security, CDN, and 24/7/365 support. This will enable you to more efficiently build, deploy, and secure performant workloads that require single-digit millisecond latency and global reach. 

And with Linode’s developer-friendly DNA, you’ll find it simpler to deploy distributed applications. Developers will be able to use these capabilities for applications, workloads, and use cases that haven’t been imagined yet.

Which cloud services are available in Akamai Connected Cloud?

• Compute
  • Shared CPU virtual machines
  • Dedicated CPU virtual machines
  • LKE – Managed Kubernetes
• Storage
  • Block storage
  • Object Storage
• Managed services & one click clusters
  • MySQL
  • PostegreSQL
  • Redis
  • MongoDB
• Networking
  • Load balancer
  • Cloud firewall
  • VLAN
  • DNS Manager
  • DDoS Protection
• Delivery
  • Adaptive Media
  • Download Delivery
  • Ion
  • Global Traffic
• Security
  • Guardicore
  • Kona Site Defender
  • App & API Protector
  • Bot Manager
  • Account Protector
  • EAA

Stay tuned for the next post where we will start defining our project and scope down the requirements.

The post Building your IT landscape on Akamai Connected Cloud – Part 1 – INTRO first appeared on Architect the cloud.