DEV Community: theo hutchings

Deploy Virtual Servers in Your VPC

theo hutchings — Tue, 03 Jun 2025 14:35:39 +0000

You now have a VPC and firewall ready for use!
Let’s put some Linode Virtual Machines inside so we can start running our applications.

What Is Akamai Connected Cloud Compute?

Akamai Connected Cloud Compute (formerly Linode) is a core service provided by Akamai that offers scalable virtual servers in the cloud. These servers, known as Linode instances, let you deploy and run applications without managing physical hardware.

Key Features

Flexible OS (Operating System) Choices: Ubuntu, Debian, CentOS Stream, Fedora, and more
Plan Types:
- Shared CPU
- Dedicated CPU
- High-Memory
- GPU
Global Regions: Edge-optimized data centers worldwide for low-latency performance
On-Demand Scaling: Resize CPU/RAM or attach additional block storage at any time
Pay-As-You-Go: Only pay for the resources you use

Ideal Use Cases

Web hosting
Development & staging environments
Databases & data processing
Containerized & microservices workloads

With Akamai Connected Cloud Compute, you get the power and reliability of a global network—while keeping costs predictable and under your control.

Let’s now make our way to the Akamai Cloud Manager Dashboard and navigate to the Linodes tab under Compute.

At the top right, click Create Linode.

By default, the **OS* tab is selected — choose your operating system to build your application from the ground up. If you’d rather deploy a ready-made solution, switch to Marketplace for One-Click apps.*

Marketplace Tab

On the Marketplace tab, you’ll find a variety of pre-made applications you can deploy quickly. For example:

StackScripts

StackScripts allow you to run Bash scripts upon the first boot of the Linode instance. For example, you can install Nginx/Apache web servers or databases like MySQL/PostgreSQL.

To create your own StackScript, head to the StackScripts tab in Compute.

Click Create StackScript.
Provide a relevant Label and Description to remind future you what it’s for.
Select the Target Images (depending on the OS you plan to use).
Paste your script into the Script section and click Create.

Images

Images let you deploy from a snapshot or custom image you’ve created/imported. This includes existing Linodes (entire root filesystem, configuration, installed packages, and user data). Images are incredibly useful for cross-region application replication.

In the Images tab, click Capture an Image to take a snapshot of an existing Linode.

Or click Upload an Image to import a custom image you have stored locally.

Backups & Cloning

Backups: View existing Linodes with backups enabled.
Clone Linode: Take an existing Linode and clone it one-time—perfect for replicating an existing server without snapshots.

Creating Your Linode Instance

Back in the OS tab, let’s start by creating a new Linode.

Region: Select the same region where you created your VPC.
OS: Choose an operating system based on your use case. Recommendations:
1. General-purpose web/database server: Ubuntu LTS / Debian Stable
2. Enterprise RHEL-compatible workloads: AlmaLinux / Rocky Linux
3. Cutting-edge development & testing: Fedora / CentOS Stream
4. Lightweight container host: Alpine Linux / Fedora CoreOS
5. Compliance-driven environment (PCI, HIPAA): Ubuntu Pro / RHEL-compatible with ESM
6. GUI-based management or desktop-style server: Ubuntu Desktop / Fedora Workstation

Although instances are scalable, it’s a good idea to start with resources close to your expected load.

Linode Plan: Choose the resources for your Linode. Here are the instance types and suggested use cases:
1. Dedicated CPU

Description: VMs with one or more full CPU cores reserved solely for you.
Use Cases: Consistent, CPU-intensive workloads like CI/CD builds, compilers, video encoding.
Pros: No “noisy neighbor” interference, predictable performance.

2. Shared CPU

Description: “Burstable” VMs that share physical CPU cores with other tenants.
Use Cases: Development environments, low-traffic web servers, test boxes, small databases.
Pros: Lowest cost, flexible burst capacity when you need it.

3. High Memory

Description: Plans that pack more RAM per CPU core than standard offerings.
Use Cases: In-memory databases (Redis, Memcached), big-data processing, caching layers.
Pros: Run large datasets entirely in RAM for ultra-fast access.

4. GPU

Description: Instances attached to NVIDIA GPUs (e.g., Tesla T4) for parallel acceleration.
Use Cases: Machine learning training/inference, GPU-accelerated compute, video transcoding.
Pros: Massive floating-point throughput, CUDA/ROCm support.

5. Premium CPU

Description: High-clock-speed Intel Xeon Scalable VMs with NVMe SSD storage.
Use Cases: High-performance web apps, single-threaded workloads, latency-sensitive services.
Pros: Faster cores, ultra-low disk I/O latency.

6. Accelerated Compute

Description: Combines dedicated CPU cores with NVMe-backed storage for maximum throughput.
Use Cases: I/O-intensive applications like Elasticsearch, large-scale data analytics, CI runners.
Pros: Top-tier disk performance plus dedicated compute.

Label & Tags: Assign a clear Label representing the instance’s purpose, and use Tags to pinpoint aspects of the application. For example:

Security: Create a strong root password known only to trusted individuals.

Since we allowed SSH on port 22 via the firewall, it’s best practice to use SSH keys for even tighter security.
Click Add an SSH Key.

Label it: user-ssh-key
Key: Paste your local machine’s SSH public key.

To find your SSH public key, run on your local machine:

 ls ~/.ssh
 # Look for a .pub file, e.g., id_rsa.pub
 cat ~/.ssh/id_rsa.pub

Copy the output and paste it into the Linode creation form.

Encryption: By default, Encrypted Disk is enabled—it’s free, so leave it on to protect data at rest.
VPC & Firewall Assignment:

Under VPC, select the VPC you created earlier.
Enable Auto-Assign VPC IPv4 so the Linode automatically gets a private 10.x address.
Disable Public IPv4 Assignment if you want to restrict traffic to within your VPC.

For Subnet, select the backend subnet you set up for this Linode.
Under Firewall, select the firewall configured for your backend server.

Note: Auto-assigning a VPC IPv4 ensures the Linode is reachable within the VPC. Not assigning a public IPv4 means it won’t be directly accessible from the Internet—useful for private backend services.

Backups: If you want automatic backups, enable the Backups option (recommended for production).
Create Linode: Scroll to the bottom and click Create Linode.

You’ll see the new Linode provisioning. After about a minute, its status will change to RUNNING—awesome, you’ve successfully created a Linode server.

SSH into Your New Linode

Copy the SSH command from the Dashboard (e.g., ssh root@172.236.21.197).
On your local machine, run:

   ssh root@************

When prompted, enter the root password you set.

Initial Server Setup

1. Update & Upgrade Packages

# Refresh package index
sudo apt update

# Upgrade all installed packages
sudo apt upgrade -y

2. Install Common Utilities

Install essential packages (including Docker prerequisites):

sudo apt install -y \
  curl \
  git \
  unzip \
  apt-transport-https \
  ca-certificates \
  gnupg \
  lsb-release

curl: Fetch remote scripts/GPG keys
git: Clone repositories
unzip: Extract zip archives
apt-transport-https, ca-certificates, gnupg, lsb-release: Required for adding Docker’s HTTPS repository securely

3. Install Docker Engine & Compose

Add Docker’s GPG Key

   curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
     | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Add Docker’s APT Repository

   echo \
     "deb [arch=$(dpkg --print-architecture) \
     signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
     https://download.docker.com/linux/ubuntu \
     $(lsb_release -cs) stable" \
     | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Update Package Index & Install Docker

   sudo apt update
   sudo apt install -y \
     docker-ce \
     docker-ce-cli \
     containerd.io \
     docker-compose-plugin

Enable & Start Docker Service

   sudo systemctl enable docker
   sudo systemctl start docker
   sudo systemctl status docker

At this point, Docker is running and you can start pulling/running containers and your server is ready to start hosting!

Setting Up A VPC And Firewall In Linode (Akamai)

theo hutchings — Wed, 28 May 2025 09:59:03 +0000

Your servers are spiking and you need to be able to cope without breaking the bank. Let’s move you to the cloud, where you can deal with your new demand with cost-effective ease.

A Virtual Private Cloud (VPC) is essentially your own private network slice within the cloud, fully isolated from other tenants. Inside a VPC, you get to define your IP address ranges, create public and private subnets, and set up route tables and internet or virtual private gateways to control traffic flows.

Setting up is important. Instead of hosting your servers in a flat network, it’s best to have a VPC (Virtual Private Cloud). This will create a secure environment where it’s much easier to get your servers talking to each other without being at risk of lateral attacks.

Setting Up the VPC

First, select the VPC tab under Networking.

Click Create VPC at the top right.

In the “Create VPC” form, choose your region and give your VPC a meaningful label.

After your VPC is created, you’ll see its dashboard. You’ll want to create separate subnets for the back-end and front-end servers. By putting your public web servers in one subnet and your private database or application servers in another, you keep them neatly separated. This allows you to create separate firewalls to limit access to non-public applications Click Create Subnet.

Label this subnet for the service you plan to deploy on it—for example, backend-service.

You should now see your new subnet listed in the VPC dashboard.

Repeat steps 4–6 for any other services (e.g. frontend-service, monitoring).

When you’re done, your VPC dashboard will list each subnet you created, all ready to have machines attached.

Setting Up Firewalls

Firewalls should always follow the basic security principle of least privilege. All inbound traffic should be blocked except for the access you explicitly allow. Here are some example rules you might consider:

Select the Firewalls tab under Networking.

Click Create Firewall at the top right.

Let’s start with your backend firewall:

Inbound Policy: Drop by default. This means that all incoming connections are blocked unless you explicitly allow them with a rule.
Leave the “Linodes” (assigned machines) blank for now as we have not yet created them.
Click Create.

Back in your Firewalls dashboard, we should see your newly created firewall. click the new firewall to open its Rules tab.

Add the rules you need for your backend services:

Rule 1: Allow SSH from Admin

Label: allow-ssh-from-admin
Protocol / Port: TCP / 22
Sources: ADMIN_IP/32
Action: Accept

This lets your personal machine SSH into the backend. To find your IP, visit https://whatismyipaddress.com/ and use the IPv4 address. The /32 suffix restricts it to exactly that one IP.

Rule 2: Allow Frontend → Backend (HTTPS)

Label: allow-https-from-frontend
Protocol / Port: TCP / 443
Sources: FRONTEND_SUBNET_CIDR
Action: Accept

This lets your frontend instances call your backend over HTTPS.

Rule 3: Allow CI/CD Deployment

Label: allow-cicd-deployment
Protocol / Port: TCP / 22
Sources: CICD_SERVER_IP/32
Action: Accept

Your CI/CD runner needs SSH access to deploy new code.

Rule 4: Allow Frontend → Database

Label: allow-frontend-to-db
Protocol / Port: TCP / 5432
Sources: FRONTEND_SUBNET_CIDR
Action: Accept

If you’re using PostgreSQL on the default port 5432, this lets your frontend talk to your database.

After adding all required rules, your backend firewall rules tab should look like this:

Click Save Changes to apply.

Ensure Inbound Policy remains Drop so only your specified rules are allowed.
Outbound Rules can usually be left empty: most backends don’t need to initiate connections to the Internet directly, so dropping outbound by default prevents accidental data exfiltration.

Frontend Firewall

Follow the same steps to create a firewall for your frontend machines:

Rule 1: SSH from Admin

Label: allow-ssh-from-admin
Protocol / Port: TCP / 22
Sources: ADMIN_IP/32
Action: Accept

Here, you’ll want to allow inbound HTTP (port 80) and HTTPS (port 443) traffic from 0.0.0.0/0 so that your web server is accessible from the Internet.

Rule 2: HTTP (public)

Label: allow-http
Protocol / Port: TCP / 80
Sources: 0.0.0.0/0
Action: Accept

Rule 3: HTTPS (public)

Label: allow-https
Protocol / Port: TCP / 443
Sources: 0.0.0.0/0
Action: Accept

Rule 4: Allow database responses

Label: allow-response-from-backend-pg
Protocol / Port: TCP / 5432
Sources: BACKEND_SUBNET_CIDR
Action: Accept

This lets your frontend accept Postgres traffic from your backend subnet.

You should add rules for each back-end application and its corresponding port.

After adding all needed rules, your dashboard will look like this:

Remember: Inbound policy stays set to Drop—only the ports and sources you explicitly allow will work.

Final Tips

Least Privilege: Only open the ports and source IPs/subnets you absolutely need.
Review Regularly: When your infrastructure changes (new CI runners, different subnets), update your firewall rules.
Use Private Subnets: Keep all backend services isolated from the public Internet whenever possible.

With this in place, your Linode VPC and firewalls will be locked down to only the traffic you explicitly allow—and everything else will be dropped by default. Happy deploying!