AI-powered coding assistants are the main talk in the developer world for a while, there’s no denying that. I can’t count the times I’ve read somewhere the AI will replace developers in the next X years. You’ve probably seen tools like GitHub Copilot, ChatGPT, or Tabnine popping up everywhere.

They promise to boost productivity, help with debugging, and even teach you new coding techniques. Sounds amazing, right? But like anything, AI-powered coding assistants have their downsides too. So, let’s talk about what makes them great—and where they might fall short.

Why AI Coding Assistants Are a Game-Changer

Obviously, one of the biggest advantages of using an AI assistant is the time it saves. Instead of writing the same repetitive boilerplate code over and over and over again, you can generate it in seconds. Need a quick function to parse JSON? AI has you covered. Easy peasy! Stuck on how to structure your SQL query? Just ask. This means less time spent on the boring stuff and more time on actual problem-solving.

AI is also a fantastic debugging tool. It can analyze your code, catch potential issues, and suggest fixes before you even run it. Instead of spending hours combing through error messages and Stack Overflow threads, you get quick, relevant suggestions that help you move forward faster.

And let’s not forget about learning. If you’re picking up a new language or framework, an AI assistant can guide you with real-time examples, explain unfamiliar syntax, and even generate sample projects. It’s like having a 24/7 coding mentor who doesn’t judge your questions.

Beyond just speed and learning, AI can actually help improve code quality. It can suggest best practices, helps format your code, and even recommends refactoring when your code gets messy. Plus, if you’re working in a team, it can assist with keeping code style consistent and even generate useful commit messages or documentation. Wouldn’t it be cool if we could plug the AI into our pipeline and make sure that all rules are being followed?

The downsides no one(everyone) talks about?

As cool as AI coding assistants are, you don’t need to be a genius to see that they’re far from perfect. One of the biggest concerns I personally see is over-reliance. If you’re constantly relying on AI to write your code, do you really understand what’s happening under the hood? This can be a problem when something breaks, and you don’t know how to fix it because you never really wrote the thing in the first place I’m sure you love reading someone else’s codebase and debugging that <3

Another issue is that AI-generated code isn’t always optimized or even correct! It might suggest something that works but isn’t efficient, secure, or maintainable. If you blindly accept AI suggestions without reviewing them, you could end up with a mess of inefficient or buggy code.

Then there’s the question of security. AI assistants are trained on huge datasets, and sometimes they can generate code that includes security vulnerabilities. If you’re working on sensitive stuff, you have to be extra careful about what code you’re using and where it’s coming from.

Let’s talk privacy! Many AI coding tools rely on cloud-based processing, meaning your code might be sent to external servers for analysis. If you’re working on proprietary or confidential code, you need to be aware of the risks and check the privacy policies of the tools you’re using.

And finally, while AI can make you more productive, it can also be a bit of a crutch. Some developers might start relying too much on AI for even basic things, which can slow down their growth and problem-solving skills in the long run.

So, Should You Use One?

AI coding assistants are undeniably powerful tools, but they work best when used wisely. They’re great for boosting productivity, helping with debugging, and learning new technologies—but they shouldn’t replace actual coding knowledge and problem-solving skills. Think of them as a really smart assistant, not a replacement for your own expertise.

If you use AI responsibly—review its suggestions, stay mindful of security risks, and make sure you’re still learning and improving as a developer it can be a fantastic addition to your workflow, just don’t let it do all the thinking for you

Still interested and want to start using AI in your daily work? Enter bolt.diy

bolt.diy is the open source version of Bolt.new (previously known as oTToDev and bolt.new ANY LLM), which allows you to choose the LLM that you use for each prompt! Currently, you can use OpenAI, Anthropic, Ollama, OpenRouter, Gemini, LMStudio, Mistral, xAI, HuggingFace, DeepSeek, or Groq models 

bolt.diy was originally started by Cole Medin but has quickly grown into a massive community effort to build the one of the open source AI coding assistants out there.

What do I need to get this deployed?

Well, just Terraform and a Linode account.
In the backend we will deploy a VM with a GPU attached, install bolt.diy, ollama and ask it to write some code! Maybe a simple Tic-Tac-Toe game?

Ideally you would run your bolt.diy deployment on a separate machine from the machine running the model, but for our use case, current deployment model is more than enough.

Like most of the things on this blog, guess what we’re gonna use? Yes! IaC!!!

Here’s a link to the Github repository containing the Terraform code.

Code will do the following:

1. Deploy a GPU based instance in Akamai Connected Cloud
2. Use cloud-init to install the following:
   • curl
   • wget
   • nodejs
   • npm
   • nvtop – great tool to monitor your GPU usage
   • Nvidia drivers
3. Deploy and configure a firewall which will allow SSH and bolt.diy access from your IP.
4. Configure bolt and ollama to run as a Linux service. For ollama service, we are always making sure we have a model downloaded and created with 32K context size.

How do you deploy it?

Just fill in your Linode API token and the desired region, Linode token and your IP address in variables.tf file and run the following commands:

git clone https://github.com/aslepcev/linode-bolt.diy
cd linode-bolt.diy
#Fill in the variables.tf file now
terrafom init
terraform plan
terraform apply

After a short 5-6 minute wait, everything should be deployed and ready to use. Go ahead and visit the IP address of your VM on the port 5173.

Example url: http://172.233.246.209:5173

Make sure that Ollama is selected as a provider and you’re off to the races!

What can it do?

Well, it really depends on the model we are running. With the RTX 4000 Ada GPU, we can comfortably run a 14B parameter model with 32K context size which is “ok” for smaller and simpler stuff.

I tested it out with a simple task of creating a Tic-Tac-Toe game in NodeJS. It got the functionality right the first time, but it looked like something only a mother could love

I just told it to make it a bit prettier and add some color; these were the results I got:

Interestingly, during the coding process, it made a mistake which it managed to identify and fix all on its own! All I did was press the “Ask Bolt” button.

Also, here’s a fully functioning Space Invaders alike game which it also wrote

What if I want to run a larger model? 32B parameters or even larger?

That’s very easy! Since Ollama can use multiple GPU’s, all we need to do is scale up the VM we are using to the one which includes two or more GPU’s. Akamai offers maximum of 4 GPU’s per VM which brings up to 80 GB of VRAM which we can use to run our model. I will not experiment with larger models in this blog post; this is something we will benchmark and try out in the future.

Cheers! Alex.

P.S – parts of this post were written by bolt.diy

The post Your own AI coding assistant running on Akamai cloud! first appeared on Architect the cloud.

Optimized for Linode Kubernetes Engine (LKE), the platform enhances automation and self-service, streamlining application management without requiring custom-built Kubernetes solutions.

Let’s get it up and running; like everything I do, we will avoid clickops and use IaC.

I’ve put the entire codebase on Github so you can simply clone it, configure your Linode token and run Terraform apply.

Code will deploy a LKE cluster in Amsterdam with 3 x Linode 8 GB instances and then use HELM provider to deploy Akamai Application Platform for you.

It will also create a DNS zone with the domain specified in the code and configure APL with full DNS integration, meaning you’ll be pretty much ready to go and deploy apps.

Please note that the cluster might scale up in case you decide to deploy a lot of applications.

Step 1 – clone the repository

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

Step 2 – fill out apl.tfvars file

linode_token = "YourLinodeToken"
domain = "yourdomain.com"
region = "nl-ams"
k8s_version = "1.30"
soaemail = "SoaEmail@yourdomain.com"

Step 3 – run terraform plan to verify what will be deployed

terraform plan --var-file="apl.tfvars"

Step 4 – run Terraform apply and grab some coffee

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

After the cluster has been deployed; you can go to Linode console and open the Kubernetes dashboard (you will need to download the kubeconfig file as well).

If all went smooth (and it will, because IaC :D), you should see a bunch of containers popping up while APL configures itself.

Click on Jobs on the left hand side and then on the three dots next to “apl” job.

Click on Logs, which will bring up a new window with the logs. Once the installation has completed, you will see the username, password and the URL where you can log in after everything has been set up.

Have in mind that setup will take a good 20-30 mins; there’s a lot of things which needs to be configured in the background for you

After everything has been deployed, the console website should become accessible. Login with the credentials listed in the logs of your job and you should be presented with the console.

Make sure to follow post-installation steps mentioned here in order to finish the configuration.

Cheers,

Alex!

The post Akamai Application Platform on LKE first appeared on Architect the cloud.

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.

DeepSparse is a sparsity-aware inference runtime that delivers GPU-class performance on commodity CPUs, purely in software, anywhere.

GPUs Are Not Optimal – Machine learning inference has evolved over the years led by GPU advancements. GPUs are fast and powerful, but they can be expensive, have shorter life spans, and require a lot of electricity and cooling.

Other major problems with GPU’s, especially if you’re thinking in the context of Edge computing, is that they can’t be packed as densely and are power ineffective compared to CPU’s; not to mention availability these days.

Since Akamai recently partnered up with Neural Magic, I’ve decided to write a quick tutorial on how to easily get started with running a simple DeepSparse sentiment analysis workload.

In case you want more about Akamai and Neural Magic’s partnership, make sure to watch this excellent video from TFiR. It will also give you a great summary of Akamai’s Project Gecko.

What is Sentiment analysis?

Sentiment analysis (also known as opinion mining or emotion AI) is the use of natural language processing, text analysis, computational linguistics, and biometrics to systematically identify, extract, quantify, and study affective states and subjective information. Sentiment analysis is widely applied to voice of the customer materials such as reviews and survey responses, online and social media, and healthcare materials for applications that range from marketing to customer service to clinical medicine. 

Why is DeepSparse cool? Because I’m doing analysis of 40 thousands movie reviews in 20 minutes using only TWO DUAL CORE Linode VM’s. Mind officially blown.

Let’s do some math here; rounding it up to 120 thousand processed reviews an hour, with 2 instances and a load balancer, we can process over 86 million requests a month which will cost you a staggering 82$ .

If you’re doing that on other cloud providers, you’re paying a five digit monthly bill for that pleasure.

Want to try it yourself? It’s easy!

If you want to try it out on Linode, follow instructions below.

If you want to check out Neural Magic DeepSparse repo, head out here.

Step 1. Clone the Repository.

Open your terminal or command prompt and run the following command:

git clone https://github.com/slepix/neuralmagic-linode

This code will deploy 2 x Dedicated 4 GB virtual machines and a Nodebalancer. It will also install Neural Magic’s DeepSparse runtime as a Linux service and install & configure Nginx to proxy requests to DeepSparse server listening on 127.0.0.1:5543.

WARNING: THIS IS NOT PRODUCTION GRADE SERVER CONFIGURATION!

It’s just a POC! Secure your servers and consult Neural Magic documentation if you want to go to production.

Step 2. – Terraform init

Navigate to the repo using the following command:

cd neuralmagic-linode

If you haven’t already installed Terraform on your machine, you can download it from the official Terraform website and follow the installation instructions for your operating system.

Step 3.

Initialize Terraform by running:

terraform init

Step 4. – Configure your Linode token

Open variables.tf file and paste in your Linode token. If you don’t know how to create a Linode PAT, check this article here. It should look similar like the picture. You can also adjust the region while you’re here

Token in the picture is not valid. It's just an example. 

Step 5 – Run Terraform apply

After configuring your variables, you can apply the Terraform configuration by running:

terraform apply

Terraform will show you a plan of the changes it intends to make.

Review the plan carefully, and if everything looks good, type “yes" and press Enter to apply the changes. Give it 5-6 minutes to finish everything and by visiting your Nodebalancer IP, you should be presented with a landing page for DeepSparse server API.

Step 6.

After the installation is done, it’s finally time to send some data to our API and see how it performs.

We can do that by using curl or invoke-webrequest if you’re on Windows and using Powershell.

CURL:

sentence="Neural Magic & Akamai are cool!"
nodebalancer="172.233.34.110" #PUT YOUR NODEBALANCER IP HERE
curl -X POST http://$nodebalancer/v2/models/sentiment_analysis/infer -H "Content-Type: application/json" -d "{\"sequences\": \"$sentence\"}"

PowerShell:

$sentence = "Neural Magic & Akamai are cool!"
$nodebalancer = "172.233.34.110"

$path = "v2/models/sentiment_analysis/infer"
$api = "http://$nodebalancer/$path"
$body = @{
   sequences = $sentence
} | ConvertTo-Json

(Invoke-WebRequest -Uri $api -Method Post -ContentType "application/json" -Body $body -ErrorAction Stop).content

In both cases make sure to paste in the IP address of the Nodebalancer you deployed and modify the sentence as you wish.

Benchmark time!

In the repository, I’ve included a file called movies.csv and three files; two PowerShell and one Python file.

movies.zip – unzip this one in the same folder where your benchmark scripts are.

analyze.ps1 – PowerShell based benchmark, sends requests in serial – not performant.

panalyze.ps1 – PowerShell based benchmark, sends requests in parallel – better performant

pypanalyze.py – Python based benchmark, sends requests in parallel – best performer (doh!) <-use this

All you need to do to in order to kick off a benchmark is to update the the URL variable with your Nodebalancer IP and you’re off to the races.

Does it scale?

Yes! For kicks I’ve added a third node and the same job finished in 825 seconds. Feel free to add as many nodes as you like and see what numbers you can get. Additionally, you can play with the number of workers in the Python file.

Note 1: python script has been written with the help of ChatGPT :) Results matched with my PowerShell version against verified smaller sample size(check note 2), so I'm gonna call it good :)
	 
Note 2: PowerShell versions don't handle some comments as they should and end up sending garbage to the API. Happens in 3% of the cases. Most probably some encoding/character issue which I couldn't be bothered to fix :)

Note3: Movies.csv file has been generated by using data from https://kaggle.com/

Cheers,

Alex.

The post Sentiment analysis of 40 thousand movie reviews in 20 minutes using Neural Magic’s DeepSparse inference runtime and Linode virtual machines. first appeared on Architect the cloud.

Since Linode now support cloud-init and metadata service, I decided to extend their example by using cloud-init to do the installation of Docker Engine and HarperDB container.

All you need to do to get HarperDB running is to copy all of these files in the same folder while making sure to keep the filenames the same (harperdb.yaml at least).

After that, simply run Terraform init, then Terraform apply and in 2-3 minutes you should have your HarperDB instance up and running.

terraform init
terraform apply -var="token=YourLinodeToken"

harperdb.yaml

#cloud-config
runcmd:
  - sudo apt-get update
  - sudo apt-get install -yq ca-certificates curl gnupg lsb-release
  - sudo install -m 0755 -d /etc/apt/keyrings
  - for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done
  - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
  - sudo chmod a+r /etc/apt/keyrings/docker.gpg
  - echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  - sudo apt-get update
  - sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
  - sudo mkdir /home/harperdb
  - sudo chmod 777 /home/harperdb
  - sudo docker run -d -v /home/harperdb:/home/harperdb/hdb -e HDB_ADMIN_USERNAME=HDB_ADMIN -e HDB_ADMIN_PASSWORD=password -p 9925:9925 -p 9926:9926 harperdb/harperdb

compute.tf

resource "linode_instance" "harperdb" {
  image = "linode/ubuntu22.04"
  region = "nl-ams" #Pick The region you want
  type = "g6-standard-1"
  root_pass = "YourRootPassword!" #Change this :D
   metadata {
    user_data = base64encode(file("${path.module}/harperdb.yaml"))
  }
}

resource "linode_firewall" "harperdb_firewall" {
  label = "harperdb"

  inbound {
    label    = "ssh"
    action   = "ACCEPT"
    protocol = "TCP"
    ports    = "22"
    ipv4     = ["0.0.0.0/0"]
    ipv6     = ["::/0"]
  }

  inbound {
    label    = "harperdb"
    action   = "ACCEPT"
    protocol = "TCP"
    ports    = "9925-9926"
    ipv4     = ["0.0.0.0/0"]
    ipv6     = ["::/0"]
  }

  inbound_policy = "DROP"
  outbound_policy = "ACCEPT"
  linodes = [linode_instance.harperdb.id]
}

terraform {
  required_providers {
    linode = {
      source = "linode/linode"
    }
  }
}

provider "linode" {
  token = var.token
}

variable "token" {
    default = ""
    type = string
}

Alex.

The post Deploying HarperDB Docker container on Linode VM using Terraform and cloud-init 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.