We leveraged just two dual-core VMs and a Nodebalancer to process a pretty impressive number(40K) of movie reviews in just 20 minutes. However, deploying in a single region can lead to latency/availability issues and doesn’t fully utilize the global reach of modern cloud infrastructure Akamai Connected Cloud offers.

Also, single region deployments are kinda boring

In this post, we’ll expand our deployment by setting up virtual machines in all available Linode regions and replacing the current Nodebalancer with Akamai’s new Cloud Load Balancer (currently in beta access).

What is Akamai’s new Cloud Load Balancer you may ask? It’s really cool peace of tech.

Think of it like an umbrella over the internet; it gives you the possibility to load balance your workloads across ANY location; it can be on prem, Akamai’s cloud, some other hyper-scaler, heck, it can even be your home IP address if you want to

As long as it can be reached over the internet, Cloud Load Balancer can use it to deliver the request.

Joking aside, here’s a more official description of the service:

The Akamai Cloud Load Balancer (ACLB) (formerly referred to as Akamai Global Load Balancer) is a layer 4 and 7 load balancer that distributes traffic based on performance, weight, and content (HTTP headers, query strings, etc.). The ACLB is multi-region, independent of Akamai Delivery, and built for East-West and North-South traffic. Key features include multi-region/multi-cloud load balancing and method selection.

Why Scale Globally?

Scaling out our application across multiple regions has several benefits:

1. Reduced Latency: By having servers closer to our users, we can significantly reduce the time it takes for requests to travel back and forth.
2. High Availability: Distributing the load across multiple regions ensures that if one region goes down, well, we kinda don’t care, our app stays online
3. Better Performance: I mean, you can’t beat physics; simply having the possibility to do compute closer to the user improves performance and user experience.

Step-by-Step Deployment Guide

Ok, let’s get into the meaty part; codebase from our previous post hasn’t changed significantly; only thing which we changed is that we’re not hardcoding out region anymore, but we are fetching the list of available regions from Linode API and deploying an instance in each region.

In the code which fetches the regions, you will notice that I commented out the authentication part.

Some regions are available only to authenticated users; if you’re one of those, just uncomment those few lines and the full region list will be returned to you.

Let’s start with terraform plan and see what we will create.

terraform plan

Ok, 25 instances, just what we expect since Akamai has 25 compute regions currently publicly available.

Let’s proceed with terraform apply

terraform apply

I don’t know about you, but I always nerd out on seeing a bunch of servers popping up in the console

In a minute or two we should have all instances deployed. After the instances have been deployed, cloud-init will kick off and install DeepSparse server with an Nginx proxy in front (check out the previous post or the YAML file in the repo for more details).

Awesome! After we’ve got the infrastructure up and running, last step is to add our nodes to the Cloud load balancer pool; at the moment we will need to do some Clickops CLB service is currently in beta so IaC support isn’t out yet.

First step is creating a Cloud Load Balancer by clicking the “Create Cloud Load Balancer” button and giving it a name.

During the beta period, Cloud Load Balancer is deployed only in 5 locations. This number will grow drastically once the service goes GA.

With Akamai’s Cloud Load Balancer, everything starts with a “Configuration“. Let’s create one by pressing “Add Configuration” button.

We will configure our load balancer to “listen” on both HTTP and HTTPS. Once we selected HTTPS as our protocol, we need to add a certificate.

In order to do that, we need to prepare our certificate and private key which we will paste into the configuration field. In this case I will use a self-signed certificate.

At this stage we will only cover the configuration for the HTTPS protocol, HTTP is really easy and won’t bother wasting your time on it.

We need to paste in the certificate & the key, enter the SNI hostname and press “Create and Add” button.

After we’ve got the configuration and the certificate added, we need to create a “Route“. Let’s click on “Create a New HTTP Route” button and give it a name.

Great, we’ve created a route, but the route is currently empty and it doesn’t route anything. We will come back to this a bit later.

Next step is to save our configuration and click on “Service Targets” tab.

This is the place where we will define our target groups and origin servers. Click on “New Service Target” button

Next steps are quite explanatory, we need to give it a name and add the nodes which we want to load balance across.

Remember, this can be one of the existing Linode instance or it can be ANY IP address which can be reached via the internet.

This is the step where I could really use IaC support, we need to add all 25 servers by using ClickOps to our “Endpoints” list.

This is also the place where you can also select the load balancing algorithm which will be used to balance requests between the nodes. At the moment there are 5 of them available:

• Round Robin
• Least Request
• Ring Hash
• Random
• Maglev

Last step in “Service Target” configuration is to set the path and host header we will use for the health checks on the nodes and click on “Save Service Target” button.

We’re almost there, I promise

Final step is to go back to the “Routes” tab, click on the route which we’ve created earlier and click on Edit button.

In the rule configuration we will enter the hostname which we want to match upon and select our “Service target” from the dropdown.

We can also do advanced request matching based on path, header, method, regex or query string but for now we will use path prefix.

Ok, we have configured our Cloud Load balancer; final step to get our application running is to create a CNAME record for my subdomain “clbtest.slepcevic.net” and point it to “MDEE053110.mesh.akadns.net” (visible in the Summary page of the load balancer).

Let’s go ahead and visit our website. We see that our DeepSparse API server is happily responding and ready to receive requests! Woohoo!

Yes, it’s that easy. In less than 10 minutes we have deployed a globally distributed application on Akamai Connected Cloud. Once IaC support for Cloud Load Balancer is rolled out, we can bring this time down to 5 minutes without any problems.

Ok, 25 regions is cool, but that isn’t truly global is it?

Yes, you’re right; with 25 regions we have covered the large majority of the global (internet) population. Can we do better? For sure! Welcome Gecko!

Gecko?

Akamai’s new initiative, code-named Gecko, is set to revolutionize cloud computing by integrating cloud capabilities directly into Akamai’s extensive edge network. This move aligns perfectly with Akamai’s strategy to provide high-performance, low-latency, and globally scalable solutions. By embedding compute capabilities at or VERY near the edge, Gecko aims to deliver workloads closer to users, devices, and data sources than ever before.

What Does Gecko Mean for Our Deployment in the future?

Gecko’s will enable us to deploy our sentiment analysis application in hundreds of new locations worldwide, including traditionally hard-to-reach areas. This means extremely reduced latency, improved performance, and enhanced availability for users across the world.

The Benefits of Deploying on Gecko

1. Ultra-Low Latency: By running our workloads even closer to end-users, we can drastically reduce the time it takes to process and respond to requests.
2. Global Reach: With Gecko, we can deploy in cities and regions where traditional cloud providers struggle to reach, ensuring a truly global presence.
3. Scalability and Flexibility: With Akamai’s large compute footprint, we can scale out our application to tens of thousands of nodes across hundreds of locations.
4. Consistent Experience: Let’s be real, if you’re running a global application, you’re most probably dealing with multiple providers; with Gecko we can consolidate all of your workloads and location coverage with a single provider. Just the operational benefits of that should be enough to “tickle” your brain into considering it for your application.

Want to try it yourself?

Have fun Go ahead and clone the repo from https://github.com/slepix/neuralmagic-globalLinode and sign up to receive beta access to the new Cloud Load balancer on https://www.linode.com/green-light/ .

NeuralMagic running across all Linode (including Gecko) regions in the next post? Perhaps

Cheers! Alex

The post Deploying a GLOBAL sentiment Analysis service using DeepSparse and Akamai Connected Cloud first appeared on Architect the cloud.

What’s the Plan?

1. Fetch the list of regions: Use Terraform’s HTTP provider to retrieve the list of Linode regions via the Linode API.
2. Deploy Instances: Use Terraform’s Linode provider to deploy instances in each of these regions.
3. Grab some coffee: Sit back and relax while Terraform does the heavy lifting.

Pre-requisites

Before we begin, make sure you have:

• A Linode account (If not, sign up here).
• A Linode API token (Grab it from your Linode dashboard).
• Terraform installed on your machine (Download it from here).

Step-by-Step Guide

Step 1: Define Providers and Variables

We’ll start by defining our providers and variables. The HTTP provider will fetch the regions, and the Linode provider will deploy our instances.

provider "http" {}

variable "token" {
type = string
default = "mytoken" # Replace with your actual Linode API token
}

Step 2: Fetch Regions from Linode API.

Next, let’s fetch the list of regions using the HTTP provider. We’ll decode the JSON response to extract the region IDs.

Please note that if you uncomment the “request_headers” part, you will get a list of regions only available to your user/account. By default you will get a list of all public regions.

data "http" "regions" {
  url = "https://api.linode.com/v4/regions"

#   request_headers = {
#     Authorization = "Bearer ${var.token}"
#   }
}

locals {
  regions = [for region in jsondecode(data.http.regions.response_body).data : region.id]
}

Step 3: Deploy Linode Instances

Now comes the fun part! We’ll utilize Terraform’s “for_each" feature to loop through the regions and deploy a virtual machine.

provider "linode" {
  token = var.token
}

resource "linode_instance" "instances" {
  for_each = toset(local.regions)

  label    = "linode-${each.key}"
  region   = each.key
  type     = "g6-standard-1"  # Example Linode type, adjust as needed
  image    = "linode/ubuntu20.04"  # Example image, adjust as needed
  root_pass = "your_secure_password"  # Replace with a secure password
  authorized_keys = [file("~/.ssh/id_rsa.pub")]  # Adjust path to your public key
}

Step 4: Outputs

Finally, let’s define some outputs to see the regions and instances we’ve created.

output "regions" {
  value = local.regions
}

output "instances" {
  value = { for instance in linode_instance.instances : instance.id => instance }
}

Wrapping Up

And there you have it! With just a few lines of code, we’ve automated the deployment of Linode instances across all regions. Terraform takes care of the heavy lifting, allowing you to focus on what matters most – enjoying a cup of coffee while your infrastructure magically sets itself up :D+

Until next time, Alex!

The post Easy way to deploy Linode instances across all (core) regions using Terraform first appeared on Architect the cloud.

Assigning a firewall via CloudManager is quite easy and self-explanatory. Create a firewall, add the rules you need and simply select that firewall when you create a load balancer.

More fun part is to use IaC, mainly Terraform.

Example code which will create a NodeBalancer, Firewall device and assign it to a load balancer.

NodeBalancer Terraform code:

resource "linode_nodebalancer" "primaryregion-lb" {
    label = "nodebalancer-web-${var.primary_region}"
    region = var.primary_region
    client_conn_throttle = 0
}

resource "linode_nodebalancer_config" "primaryregion-lb-config" {
    nodebalancer_id = linode_nodebalancer.primaryregion-lb.id
    port = 80
    protocol = "http"
    check = "http"
    check_path = "/"
    check_attempts = 3
    check_timeout = 30
    stickiness = "none"
    algorithm = "leastconn"
}

resource "linode_nodebalancer_node" "primary" {
    count = "2"
    nodebalancer_id = linode_nodebalancer.primaryregion-lb.id
    config_id = linode_nodebalancer_config.primaryregion-lb-config.id
    address = "${element(linode_instance.web-primary.*.private_ip_address, count.index)}:80"
    label = "nodebalancer-web-${var.primary_region}"
    weight = 50
}

Terraform code to create a Firewall and assign it to the said load balancer.

resource "linode_firewall" "lb-fw" {
  label = "lb-pub"

  inbound {
    label    = "allow-http"
    action   = "ACCEPT"
    protocol = "TCP"
    ports    = "80"
    ipv4     = ["0.0.0.0/0"]
    ipv6     = ["::/0"]
  }

  inbound {
    label    = "allow-https"
    action   = "ACCEPT"
    protocol = "TCP"
    ports    = "443"
    ipv4     = ["0.0.0.0/0"]
    ipv6     = ["::/0"]
  }

  inbound_policy = "DROP"

  outbound_policy = "ACCEPT"

  nodebalancers = [linode_nodebalancer.primaryregion-lb.id]
}

If you’ve ever used Terraform and Linode, you will notice it’s exactly the same approach we do when we want to assign a firewall device to a Linode (virtual machine); only difference is that we reference the “nodebalancer” instead of “linodes”.

Cheers,

Alex.

The post Assigning a firewall to Linode NodeBalancer using Terraform and Cloud Manager. first appeared on Architect the cloud.

After kicking off the migration through the Cloud Manager (which took <15 minutes), my instance wasn’t responding to any network requests. Problem was completely cause by me, by configuring a static IP on the VM. After the VM got migrated to Amsterdam DC, it got a new IP which wasn’t configured on the interface.

The Lish Console, also called the Linode Shell, provides direct console access to all of your Compute Instances. Through Lish, you can easily access your Compute Instance’s internal Linux system and run commands, install software, or configure applications. Lish is especially useful when you are not able to connect to your server through other means, such as SSH or the entire network stack is down.

Alongside Lish, there’s also a tool called Glish, which stands for “Graphical Linode Shell“, which you guessed it, has the ability to display your desktop environment, including Windows.

Problem comes when we run an UNSUPPORTED deployment of Windows OS on Linode and want to send “CTRL + ALT + DEL” command to the OS. Glish doesn’t have that ability built-in.

When I say unsupported I mean that Windows OS works on Linode (quite good!), but there’s no official support from Linode when it comes to debugging your system.

If the VM starts up (aka, passes the “BIOS” stage and has a boot attempt) Linode’s work here is done and support won’t be able to provide any help with debugging your instance in case it doesn’t work properly. With that out of the way, let’s check out what options we have to fix the IP address of the interface.

1. Extract a valid GLISH session ID and use noVNC to connect over a WebSocket (more complex)
2. Use Windows SAC console which is available via Lish to configure the IP on your network adapter (less complex)

We’ll go with option 2 Go to Linode Cloud Manager, click on your VM and launch Lish Console.

You will be presented with a screen like this:

What we see here is Special Admin Console (SAC) capability built into Windows.

Type in “cmd” and press Enter. You will get an output saying that a new “channel” was created.

After the channel has been created, we need to switch to it.

We can do that by pressing ESC and then TAB. This will switch us to the new channel and prompt us to authenticate to the server. If you ever used screen in Linux, this concept will be familiar to you

After logging in, you’ll be presented with a familiar looking command prompt screen.

From here you can launch Powershell to do more complex stuff, but now we will just configure the new network settings by using the classic netsh command. Make sure to replace the IP address and the subnet to match your VM. You can see those settings in Cloud Manager by clicking on your VM and then on the Network tab

#Example
netsh interface ip set address "Ethernet" static YourNewIP Mask Gateway

#Example
netsh interface ip set address "Ethernet" static 172.233.47.111 255.255.255.0 172.233.47.1

In case you have multiple network interfaces attached to your VM, make sure to replace “Ethernet” with the name of your adapter.

Cheers, Alex.

The post Fix Linode Windows VM IP configuration using Windows SAC console and Lish. first appeared on Architect the cloud.

1:58 to be exact

Ok, what is cloud-init in the first place?

Cloud-init is a widely used open-source package for initializing and configuring cloud instances (virtual machines or instances) in cloud computing environments. It is commonly used in infrastructure as a service (IaaS) and cloud platforms such as Akamai Connected Cloud, Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and various other cloud providers.

Cloud-init allows you to define and execute custom scripts and configuration at instance launch time or when an instance boots. It is typically provided with the cloud instance’s metadata during its provisioning. This metadata can include user data, which consists of cloud-init configuration in the form of a script or YAML file.

Key features and use cases of cloud-init include:

Operating System Configuration: You can use cloud-init to perform various tasks like setting the hostname, configuring network interfaces, setting up users, and more.

Package Installation: Cloud-init can be used to install software packages, libraries, or applications on the newly provisioned instance.

User Data: You can pass user-specific data to the instance, which can be used to customize the instance’s behavior at boot time. For example, you can use it to configure software, install additional packages, or run scripts.

Security: You can use cloud-init to set up SSH keys for secure access, set firewall rules, or perform other security-related tasks.

Customization: Cloud-init allows you to define instance-specific customizations, making it easier to automate the setup and configuration of instances.

Cloud Provider Agnostic: While commonly used in various cloud providers, cloud-init is not tied to a specific cloud platform. It’s available and can be used in many different environments.

Flexibility: You can provide cloud-init configuration as a script or a YAML file, giving you flexibility in how you define the initialization and configuration process.

Ok, but how do I use it? It’s quite simple actually.

In this example, we install 5 packages and run a few commands to download WordPress, create a DB user, prepare wp-config file and so on.

Please make sure to use a better password and/or a better way to deliver the credentials to the VM. Password in plain text is just for demo purposes and it’s just plain wrong (ha ha, get it! :D)!

Log into your Linode Cloud manager interface and click on “Create Linode” button.

Make sure to select a distribution which support cloud-init! Those are indicated by a “file” icon next to the distro name.

Next step (beside selecting the region, instance type, key and password), is to expand the “User Data” section and paste in the following code and press “Deploy”.

#cloud-config
packages:
  - apache2
  - mysql-server
  - php8.1
  - libapache2-mod-php8.1
  - php8.1-mysql
runcmd:
  - mkdir -p /var/www/html  # Create the /var/www/html directory if it doesn't exist
  - rm -f /var/www/html/index.html  # Remove the default index.html file
  - [wget, https://wordpress.org/latest.tar.gz, -O, /tmp/wordpress.tar.gz]
  - [tar, -xvzf, /tmp/wordpress.tar.gz, -C, /var/www/html]
  - mv /var/www/html/wordpress/* /var/www/html/  # Move WordPress files to the root of the web directory
  - [chown, -R, www-data:www-data, /var/www/html]
  - |
    mysql -u root -e "CREATE DATABASE wordpress;"
    mysql -u root -e "CREATE USER 'wordpressuser'@'localhost' IDENTIFIED BY 'ComplexPassword123#';"
    mysql -u root -e "GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpressuser'@'localhost';"
    mysql -u root -e "FLUSH PRIVILEGES;"
  - cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php
  - sed -i 's/database_name_here/wordpress/g' /var/www/html/wp-config.php
  - sed -i 's/username_here/wordpressuser/g' /var/www/html/wp-config.php
  - sed -i 's/password_here/ComplexPassword123#/g' /var/www/html/wp-config.php
  - a2enmod php8.1  # Enable PHP module
  - systemctl restart apache2  # Restart Apache to apply the changes

Open your browser and navigate to the IP address of the server and less than 2 minutes after you should be greeted with a WordPress “Finish setup” page where you need to specify your email, username and password.

You can accomplish the same thing via Terraform by using the “metadata” block and encoding your cloud-init script in base64.

resource "linode_instance" "wordpressviacloudinit" {
  label = "Wordpress-via-cloudinit"
  image = "linode/ubuntu22.04"
  region = "us-iad"
  type = "g6-standard-1"
  authorized_keys = ["ssh-rsa AAAA...Gw== user@example.local"]
  root_pass = "terr4form-test"
  metadata {
    user_data = "I2Nsb3VkLWNvbmZpZwpwYWNrYWdlczoKICAtIGFwYWNoZTIKICAtIG15c3FsLXNlcnZlcgogIC0gcGhwOC4xCiAgLSBsaWJhcGFjaGUyLW1vZC1waHA4LjEKICAtIHBocDguMS1teXNxbApydW5jbWQ6CiAgLSBta2RpciAtcCAvdmFyL3d3dy9odG1sICAjIENyZWF0ZSB0aGUgL3Zhci93d3cvaHRtbCBkaXJlY3RvcnkgaWYgaXQgZG9lc24ndCBleGlzdAogIC0gcm0gLWYgL3Zhci93d3cvaHRtbC9pbmRleC5odG1sICAjIFJlbW92ZSB0aGUgZGVmYXVsdCBpbmRleC5odG1sIGZpbGUKICAtIFt3Z2V0LCBodHRwczovL3dvcmRwcmVzcy5vcmcvbGF0ZXN0LnRhci5neiwgLU8sIC90bXAvd29yZHByZXNzLnRhci5nel0KICAtIFt0YXIsIC14dnpmLCAvdG1wL3dvcmRwcmVzcy50YXIuZ3osIC1DLCAvdmFyL3d3dy9odG1sXQogIC0gbXYgL3Zhci93d3cvaHRtbC93b3JkcHJlc3MvKiAvdmFyL3d3dy9odG1sLyAgIyBNb3ZlIFdvcmRQcmVzcyBmaWxlcyB0byB0aGUgcm9vdCBvZiB0aGUgd2ViIGRpcmVjdG9yeQogIC0gW2Nob3duLCAtUiwgd3d3LWRhdGE6d3d3LWRhdGEsIC92YXIvd3d3L2h0bWxdCiAgLSB8CiAgICBteXNxbCAtdSByb290IC1lICJDUkVBVEUgREFUQUJBU0Ugd29yZHByZXNzOyIKICAgIG15c3FsIC11IHJvb3QgLWUgIkNSRUFURSBVU0VSICd3b3JkcHJlc3N1c2VyJ0AnbG9jYWxob3N0JyBJREVOVElGSUVEIEJZICdDb21wbGV4UGFzc3dvcmQxMjMjJzsiCiAgICBteXNxbCAtdSByb290IC1lICJHUkFOVCBBTEwgUFJJVklMRUdFUyBPTiB3b3JkcHJlc3MuKiBUTyAnd29yZHByZXNzdXNlcidAJ2xvY2FsaG9zdCc7IgogICAgbXlzcWwgLXUgcm9vdCAtZSAiRkxVU0ggUFJJVklMRUdFUzsiCiAgLSBjcCAvdmFyL3d3dy9odG1sL3dwLWNvbmZpZy1zYW1wbGUucGhwIC92YXIvd3d3L2h0bWwvd3AtY29uZmlnLnBocAogIC0gc2VkIC1pICdzL2RhdGFiYXNlX25hbWVfaGVyZS93b3JkcHJlc3MvZycgL3Zhci93d3cvaHRtbC93cC1jb25maWcucGhwCiAgLSBzZWQgLWkgJ3MvdXNlcm5hbWVfaGVyZS93b3JkcHJlc3N1c2VyL2cnIC92YXIvd3d3L2h0bWwvd3AtY29uZmlnLnBocAogIC0gc2VkIC1pICdzL3Bhc3N3b3JkX2hlcmUvQ29tcGxleFBhc3N3b3JkMTIzIy9nJyAvdmFyL3d3dy9odG1sL3dwLWNvbmZpZy5waHAKICAtIGEyZW5tb2QgcGhwOC4xICAjIEVuYWJsZSBQSFAgbW9kdWxlCiAgLSBzeXN0ZW1jdGwgcmVzdGFydCBhcGFjaGUyICAjIFJlc3RhcnQgQXBhY2hlIHRvIGFwcGx5IHRoZSBjaGFuZ2VzCg=="
  }
  group = "foo"
  tags = [ "foo" ]
  swap_size = 512
  private_ip = false
}

Of course, you can use cloud-init for pretty much anything you want but the ideal usecase would be bootstrapping your instance so your configuration management tool can take over after Terraform creates it.

Until next time!

Cheers, Alex.

The post From zero to WordPress in less than 2 minutes on Linode using cloud-init and/or Terraform 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.

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.