Before we dive into installation and real usage, let’s talk about DeepSeek-R1 a bit and why it’s a big thing.

The team behind DeepSeek-R1-Zero took a cool approach to advancing large language models by skipping supervised fine-tuning (SFT) entirely and jumping straight into reinforcement learning (RL).

This resulted in a model capable of self-verification, reflection, and generating intricate chain-of-thoughts (CoTs) to solve complex problems. What’s borderline groundbreaking here is that this is the first open research to show RL alone can incentivize reasoning in LLMs, without the need for SFT. Development pipeline for DeepSeek-R1 includes two RL stages to improve reasoning patterns and align with human preferences, along with two SFT stages to seed the model’s reasoning and non-reasoning capabilities.

They didn’t stop at advancing reasoning in large models—they also focused on making smaller models more powerful! By distilling the reasoning patterns of larger models into smaller ones, they achieved better performance than what RL alone could achieve on small models.

Using DeepSeek-R1’s reasoning data, they fine-tuned several dense models and demonstrated exceptional benchmark results. To further benefit the community, they’ve open-sourced distilled checkpoints ranging from 1.5B to 70B parameters, based on the Qwen2.5 and Llama3 series.

What is distillation you may ask?

In the context of AI, distillation (short for knowledge distillation) is a technique used to transfer knowledge from a larger, more complex model (called the teacher) to a smaller, simpler model (called the student). The goal is to make the smaller model perform as well as—or almost as well as—the larger model, while requiring significantly fewer resources (e.g., memory, computation).

How Distillation Works:

1. Training the Teacher Model:
   A large model is trained first. This model is usually highly expressive, capable of capturing complex patterns in the data, but it may be too computationally intensive for practical deployment.
2. Soft Labels as Knowledge:
   Instead of just training the student model on the original dataset, the student learns from the soft predictions of the teacher model. These predictions include probability distributions over all possible outcomes (rather than binary correct/incorrect labels), which contain richer information about the relationships between classes.
3. Student Model Training:
   The student model is trained to mimic the teacher’s behavior using a combination of:
   • The soft predictions from the teacher model (knowledge transfer).
   • The original ground-truth data.

Why Distillation is Useful:

• Efficiency: Smaller models are faster, require less memory, and can run on devices with limited computational power (like mobile phones or edge devices).
• Scalability: By distilling large models into smaller ones, researchers and developers can deploy AI more broadly while maintaining strong performance.
• Accessibility: Distilled models often serve as the foundation for open-source projects, making advanced AI capabilities more accessible to the community.

Ok, let’s get to the interesting part and deploy our model. We can break down the entire deployment in 4 easy steps.

Step 1 – Deploy a GPU VM in Linode. I’m gonna deploy the smallest GPU VM available “RTX4000 Ada x1 Small” which costs 350$ per month.

Step 2 – Connect using SSH to your instance and install Nvidia drivers

Since I’m using Debian 12 as my OS, installing Nvidia drivers was quite easy following official instructions – https://wiki.debian.org/NvidiaGraphicsDrivers

After the driver has been install, I suggest you also install “nvtop” using:

apt install nvtop

nvtop is a cool utility which can monitor the usage of your GPU. Think of it like a “top” command, but for GPU’s.

Step 3 – Install Ollama

Installing Ollama is extremely simple, all you need to do it run a single command.

curl -fsSL https://ollama.com/install.sh | sh

Step 4 – Download and run the DeepSeek-R1 model into Ollama. Since the GPU I will be using has 20 GB of VRAM, we can fit a 14B model without any issues.

–verbose flag tells Ollama to display performance metrics after the generation has been completed.

ollama run deepseek-r1:14b --verbose

Let’s ask a simple question and see how it performs: What is distilling in the context of AI?

<think>

Hmm, distillation… I think it’s related to machine learning, specifically in training
models. Maybe it’s about transferring knowledge from one model to another? Let me recall.
Oh right, model distillation is the process where you take a complex, large model and
create a smaller, more efficient version that retains the same performance.

Wait, there are different types of distillation too. I should mention those. There’s
knowledge distillation where you transfer knowledge from a teacher model to a student
model. Then there’s parameter-efficient methods like fine-tuning or adapter-based
approaches. Also, pruning and quantization techniques come under distilling in terms of
optimizing models.

I need to make sure the explanation is clear but not too technical. The user might be
someone new to AI or looking to understand optimization techniques. They probably want a
practical understanding without getting bogged down by jargon.

Maybe I should start with the general idea, then break it down into types, and explain
each briefly. Also, highlighting why it’s important—like efficiency, scalability,
deployment on devices—would be helpful for them to grasp its value.

I should keep the response structured but conversational, avoiding any markdown. Just
plain, easy-to-understand English. Let me put that together.
</think>

In the context of AI and machine learning, distilling refers to a technique where
knowledge or information from one model is transferred to another, often simpler or
smaller model. This process aims to create a more efficient version of the original model
while preserving its performance.

Key Ideas:

1. Model Distillation:

• It involves training a “student” model to mimic the behavior or decisions of a
  larger, more complex “teacher” model.
• The teacher model is typically pre-trained on a large dataset and has high accuracy
  but may be computationally expensive or difficult to deploy.

1. Types of Distillation:

• Knowledge Distillation: The teacher model’s predictions (soft labels) are used to
  train the student model, which can lead to better generalization compared to using only
  hard labels.
• Parameter-Efficient Methods: Techniques like fine-tuning, adapter-based
  approaches, or prompt tuning allow the transfer of knowledge without copying all
  parameters from the teacher model.
• Pruning and Quantization: These are techniques used to reduce the size of a model
  by removing unnecessary weights (pruning) or reducing the precision of the weights
  (quantization).

1. Applications:

• Distillation is widely used to deploy AI models on edge devices where computational
  resources are limited.
• It also helps in scaling down large models for faster inference while maintaining
  performance.

In summary, distilling in AI is about making complex models more efficient and accessible
by transferring their knowledge to simpler or smaller models.

total duration: 19.004002094s
load duration: 12.267119ms
prompt eval count: 105 token(s)
prompt eval duration: 48ms
prompt eval rate: 2187.50 tokens/s
eval count: 615 token(s)
eval duration: 18.938s
eval rate: 32.47 tokens/s

One major difference between DeepSeek-R1 and majority of other generative AI models is that DeepSeek will show you the “train of thought” it used to get to the answer, not just the answer itself.

Once we have the model running locally, we can turn it into our own personal AI assistant by using Open-WebUI or turn it into your own coding assistant using Bolt.diy.

Ollama also has it’s on API which you can use to embed the model into your own applications.

Possibilities are endless!

BTW, we can even run a 32B parameter model, but the performance drops to 10 tokens per second and spills a bit into the RAM and CPU, but nothing drastic. Model is still fully usable and comparable to ChatGPT on a busy day.

Results you can see on the image are based on the request to build me “Space Invaders” game in HTML.

Until next time where we will take a look into bolt.diy and deploy our own coding assistant!

Alex!

The post DeepSeek-R1 on Akamai Connected Cloud first appeared on Architect the cloud.

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.

After a relatively steep learning curve, I realized that PowerShell is cool and VERY powerful for some use cases.

Well, as a small side project, I started working on a Powershell module for Akamai Connected Cloud (Linode) platform.

Why? Why not!?

Linode is already known as being VERY developer friendly, why not make it even more friendlier

General idea was to generate a module which will directly talk to the Linode API and eventually expose all platform features via some commandlet.

Besides that, I also wanted to implement some quality of life features which current Linode CLI doesn’t have.

Using the label/name of the resource in your commands.

With the current linode-cli, you need to use the resource ID in all commands which is a bit annoying for some use cases

With this module, you can use the resource label/name in your commands, and in the background the module will convert the label provided to a resource ID and use that to talk to the API.

Support for multiple Linode accounts and account switching.

I also implemented the possibility to have and switch between multiple different Linode “profiles”.

You can have a profile for your development Linode account, a profile for your test Linode account and switch between them using a single command.

Generate a random password when launching an instance

When you deploy instances with the linode-cli, you need to provide a password for the instance.

Since humans are lazy, we most probably end up using the same password over and over again. This feature will make sure that you always get a secure password generated for your Linode. Of course, you are still free to provide your own password if you like.

Check out the examples below to see how all of these things work.

How to start? It’s really easy! You will be up and running in less than 2 minutes!

Installation

To install the Linode PowerShell module, you need to clone the repository, position yourself into the module folder and import the module:

git clone https://github.com/slepix/LinodePowerShell.git
cd LinodePowerShell

Usage

Before you can use the module, you need to import it using the following command:

Import-Module -Name .\LinodePSModule.psd1

After the module has been imported, you need to configure it and add your Linode account.

Configuration

Configuration is really simple, all you need to do is run ‘Connect-LinodeAccount’ command and follow the configuration wizard.

Connect-LinodeAccount

You can run “Connect-LinodeAccount” command for each Linode account you want to add.

IMPORTANT!!!
When creating a new profile, you will be asked if you want to encrypt your Linode token or not. If you decide to encrypt the token, you won't be able to manually edit the profile file and edit the token. 

It is recommended that you use encrypted profile option and recreate a profile if you need to change the token.

User configuration is stored in “$HOME\.LinodePSModule\$name-profile.json“

Check in the examples below how you can switch between different Linode accounts.

NOTE:
You will need Linode API token with the READ/WRITE permissions for all resources in order to get the full functionality of this module.
However, you are free to limit the scope of the API token to suit your security and usage requirements.

Available commands

List of currently available commands can be viewed by running this command

(Get-Module LinodePSModule).ExportedCommands

Example commands

List all currently configured profiles

PS C:\> Get-LinodeProviderProfiles # returns a list of all configured profiles
development
test

Switch to a profile named “test”

PS C:\> Set-LinodeProviderProfile -profile test
Profile test loaded

Get a list of all regions, but only return label, id and status of each region

PS C:\> Get-LinodeRegions | Select label, id, status

label           id           status
-----           --           ------
Mumbai, IN      ap-west      ok
Toronto, CA     ca-central   ok
Sydney, AU      ap-southeast ok
Washington, DC  us-iad       ok
Chicago, IL     us-ord       ok
Paris, FR       fr-par       ok
Seattle, WA     us-sea       ok
Sao Paulo, BR   br-gru       ok
Amsterdam, NL   nl-ams       ok
Stockholm, SE   se-sto       ok
Madrid, ES      es-mad       ok
Chennai, IN     in-maa       ok
Osaka, JP       jp-osa       ok
Milan, IT       it-mil       ok
Miami, FL       us-mia       ok
Jakarta, ID     id-cgk       ok
Los Angeles, CA us-lax       ok
Dallas, TX      us-central   ok
Fremont, CA     us-west      ok
Atlanta, GA     us-southeast ok
Newark, NJ      us-east      ok
London, UK      eu-west      ok
Singapore, SG   ap-south     ok
Frankfurt, DE   eu-central   ok
Tokyo, JP       ap-northeast ok

Returns all properties of a single region

PS C:\> Get-LinodeRegion -region nl-ams # list only nl-ams region

id                     : nl-ams
label                  : Amsterdam, NL
country                : nl
capabilities           : {Linodes, Backups, NodeBalancers, Block Storage...}
status                 : ok
resolvers              : @{ipv4=172.233.33.36, 172.233.33.38, 172.233.33.35,     172.233.33.39, 172.233.33.34, 172.233.33.33, 172.233.33.31, 172.233.33.30, 172.233.33.37, 172.233.33.32;
                         ipv6=2600:3c0e::f03c:93ff:fe9d:2d10, 2600:3c0e::f03c:93ff:fe9d:2d89, 2600:3c0e::f03c:93ff:fe9d:2d79, 2600:3c0e::f03c:93ff:fe9d:2d96, 2600:3c0e::f03c:93ff:fe9d:2da5,     
                         2600:3c0e::f03c:93ff:fe9d:2d34, 2600:3c0e::f03c:93ff:fe9d:2d68, 2600:3c0e::f03c:93ff:fe9d:2d17, 2600:3c0e::f03c:93ff:fe9d:2d45, 2600:3c0e::f03c:93ff:fe9d:2d5c}
placement_group_limits : @{maximum_pgs_per_customer=100; maximum_linodes_per_pg=5}
site_type              : core

Create a new Linode named “myInstance” with the instance type of “g6-nanode-1” in nl-ams region and a randomly generated password 25 characters long running Debian 11

PS C:\> New-LinodeInstance -label myInstance -region nl-ams -type g6-nanode-1 -image linode/debian11 -generatepassword -passwordlength 25


id               : 60827598
label            : myInstance
group            :
status           : provisioning
created          : 2024-06-30T01:23:46
updated          : 2024-06-30T01:23:46
type             : g6-nanode-1
ipv4             : {172.233.40.46}
ipv6             : 2600:3c0e::f03c:94ff:fe85:29cf/128
image            : linode/debian11
region           : nl-ams
specs            : @{disk=25600; memory=1024; vcpus=1; gpus=0; transfer=1000}
alerts           : @{cpu=90; network_in=10; network_out=10; transfer_quota=80; io=10000}
backups          : @{enabled=False; available=False; schedule=; last_successful=}
hypervisor       : kvm
watchdog_enabled : True
tags             : {}
host_uuid        : 5f337dda11805445fc391c91e6dcbf45c2a38a21
has_user_data    : False
placement_group  :
lke_cluster_id   :
root_password    : eJbd\OQC9ypSagfvTSG@XREV4

Delete a Linode instance

All destructive commands will force you to use “-confirm” flag in order to actually delete a resource.

PS C:\> Remove-LinodeInstance -label myInstance  
Please use the -confirm flag in order to delete an instance

PS C:\> Remove-LinodeInstance -label myInstance -confirm
Instance 60827598 deleted

Every other command

Even though each commandlet will ask you for parameters, you can also use ‘Get-Help’ commandlet in order to find out which parameters each command requires.

Example for “New-LinodeVPC” command:

PS /> Get-Help New-LinodeVPC

NAME
    New-LinodeVPC

SYNTAX
    New-LinodeVPC [[-description] <string>] [[-apiVersion] <string>] [[-label] <string>] [[-token] <string>] [[-region] <string>] [[-subnetlabel] <string>] [[-iprange] <string>] [<CommonParameters>]

ALIASES
    None

REMARKS
    None

Cool stuff and other quality of life improvements

Compared to Linode’s existing CLI, this module will allow you to specify a label for most of the resources you’re working with. In the background the module will convert the label to the ID of the resource for you.

Example of retrieving an instance details using linode-cli:

Example retrieving an instance details using Linode Powershell module:

PS C:\> Get-Linodeinstance -label blog.dummyserver.net

id               : 12374123
label            : blog.dummyserver.net
group            :
status           : running
created          : 2024-02-29T17:53:49
updated          : 2024-06-29T00:35:47
type             : g6-standard-2
ipv4             : {172.123.123.123}
ipv6             : 2600:4c0e::f04c:95ff:fe48:cda4/128
image            : linode/ubuntu22.04
region           : nl-ams
specs            : @{disk=81920; memory=4096; vcpus=2; gpus=0; transfer=4000}
alerts           : @{cpu=180; network_in=10; network_out=10; transfer_quota=80; io=10000}
backups          : @{enabled=True; available=True; schedule=; last_successful=2024-06-29T00:29:24}
hypervisor       : kvm
watchdog_enabled : True
tags             : {prod}
host_uuid        : 123f8e495e9d51c53df4fa074e5844bce944a068
has_user_data    : True
placement_group  :
lke_cluster_id   :

Development status as of 30.06.2024

Live status: https://docs.google.com/spreadsheets/d/1UCzCSL3fRUB6cJKZJBUFEq-hPzaxGcS7B37nP12Ee3I/edit?gid=1065465499#gid=1065465499

Development is focused on providing the most important features from the start, so that’s the reason you will see a lot of less important functionalities being implemented halfway or “almost there”.

This is a very active project and my expectation is that in the next few weeks there will be full coverage.

Status of implementation is as follows:

Roadmap

Since this is a “weekend” project, no dates will be listed here

Project is under very active development and I’m expecting to finish the first stage in the next few weeks

• Stage 1 < -WE ARE HERE (30.06.2024)
  • Full functionality coverage – 45% done
• Stage 2
  • Write Pester tests for all functionalities
• Stage 3
  • Build test and release pipelines
• Stage 4
  • Get a signing certificate & publish to NuGet gallery if project gets enough traction

Contributing

To report a bug or request a feature in the module, please open a GitHub Issue. Will be happy to check it out <3

Have fun with it, please provide feedback (especially around naming commandlets) and until next time

Alex!

The post Powershell module for Linode – 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.

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.

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.