Infrastructure as Code: Provisioning Secure Perl Clusters on DigitalOcean Using Terraform

Terraform Provider Configuration for DigitalOcean

To provision resources on DigitalOcean using Terraform, we first need to configure the DigitalOcean provider. This involves specifying your authentication token and potentially a region. It’s crucial to manage your API token securely, ideally using environment variables or a secrets management system rather than hardcoding it directly into your Terraform configuration.

Create a file named versions.tf (or include this within your main main.tf) to define the provider and required Terraform version.

# versions.tf
terraform {
  required_version = ">= 1.0.0"

  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
  # Optionally specify a region if not set via environment variable
  # region = "nyc3"
}

variable "do_token" {
  description = "DigitalOcean API Token"
  type        = string
  sensitive   = true
}

You can set the do_token variable by exporting it as an environment variable before running Terraform commands:

export TF_VAR_do_token="YOUR_DIGITALOCEAN_API_TOKEN"

Defining the Perl Cluster Infrastructure

Our Perl cluster will consist of multiple Droplets, a load balancer, and potentially a managed database. We’ll use Terraform’s resource blocks to define these components. For security, we’ll configure firewalls and SSH access.

Let’s start by defining the Droplets that will host our Perl applications. We’ll create a count-based resource to easily scale the number of application servers.

# main.tf

resource "digitalocean_droplet" "perl_app" {
  count              = var.app_server_count
  name               = "perl-app-${count.index}"
  region             = var.region
  size               = var.app_droplet_size
  image              = "ubuntu-22-04-x64" # Or your preferred OS
  ssh_keys           = [digitalocean_ssh_key.deployer.id]
  monitoring         = true
  ipv6               = true
  private_networking = true

  tags = ["perl-cluster", "app-server"]

  connection {
    type        = "ssh"
    user        = "root" # Or your preferred user
    private_key = file(var.ssh_private_key_path)
    host        = self.ipv4_address
    timeout     = "2m"
  }

  provisioner "remote-exec" {
    inline = [
      "apt-get update -y",
      "apt-get upgrade -y",
      "apt-get install -y perl libapache2-mod-perl2", # Example: Apache + mod_perl
      "a2enmod perl",
      "systemctl restart apache2"
      # Add your Perl application deployment steps here
      # e.g., git clone, cpanm install, configuration
    ]
  }
}

resource "digitalocean_ssh_key" "deployer" {
  name       = "deployer-ssh-key"
  public_key = file(var.ssh_public_key_path)
}

variable "app_server_count" {
  description = "Number of Perl application servers"
  type        = number
  default     = 3
}

variable "region" {
  description = "DigitalOcean region for resources"
  type        = string
  default     = "nyc3"
}

variable "app_droplet_size" {
  description = "Droplet size for application servers"
  type        = string
  default     = "s-2vcpu-4gb"
}

variable "ssh_public_key_path" {
  description = "Path to the SSH public key file"
  type        = string
  default     = "~/.ssh/id_rsa.pub"
}

variable "ssh_private_key_path" {
  description = "Path to the SSH private key file"
  type        = string
  default     = "~/.ssh/id_rsa"
}

In this configuration:

• We define a digitalocean_droplet resource named perl_app. The count argument allows us to create multiple instances of this Droplet.
• Each Droplet is named dynamically using count.index.
• We specify the region, size, and a common Ubuntu image.
• ssh_keys associates our public key for secure access. The digitalocean_ssh_key.deployer resource uploads your public key to DigitalOcean.
• private_networking = true is essential for secure communication between Droplets within the same datacenter.
• A connection block configures Terraform’s SSH access to the Droplet for running provisioners.
• The remote-exec provisioner runs commands on the newly created Droplet. Here, we’re installing Perl and Apache with mod_perl. Crucially, you’ll need to replace these commands with your actual Perl application deployment and configuration steps. This might involve cloning a Git repository, installing Perl modules via cpanm, and setting up your web server configuration.

Load Balancer for Traffic Distribution

To distribute incoming traffic across our Perl application servers, we’ll deploy a DigitalOcean Load Balancer. This ensures high availability and can handle SSL termination.

# main.tf (continued)

resource "digitalocean_loadbalancer" "perl_lb" {
  name     = "perl-cluster-lb"
  region   = var.region
  vpc_uuid = digitalocean_vpc.perl_vpc.id # Assuming VPC is defined

  forwarding_rule {
    entry_protocol  = "http"
    entry_port      = 80
    target_protocol = "http"
    target_port     = 80
    # Optional: For HTTPS, you'd configure SSL here
    # certificate_id = digitalocean_certificate.my_cert.id
  }

  # Add HTTPS forwarding rule if using SSL
  # forwarding_rule {
  #   entry_protocol  = "https"
  #   entry_port      = 443
  #   target_protocol = "http" # Or "https" if your app servers handle SSL
  #   target_port     = 80
  #   certificate_id  = digitalocean_certificate.my_cert.id
  # }

  healthcheck {
    port     = 80
    protocol = "http"
    path     = "/" # Adjust to a health check endpoint in your app
    check_interval_seconds = 10
    response_timeout_seconds = 5
    healthy_threshold = 3
    unhealthy_threshold = 3
  }

  droplet_tag_filter = "perl-cluster,app-server" # Matches tags on app Droplets

  tags = ["perl-cluster", "loadbalancer"]
}

# Define a VPC for private networking
resource "digitalocean_vpc" "perl_vpc" {
  region = var.region
  name   = "perl-cluster-vpc"
  ip_range = "10.10.0.0/16" # Example private IP range
}

# Output the Load Balancer IP address
output "loadbalancer_ip" {
  description = "The public IP address of the DigitalOcean Load Balancer"
  value       = digitalocean_loadbalancer.perl_lb.ip
}

Key aspects of the load balancer configuration:

• name and region are self-explanatory.
• vpc_uuid links the load balancer to our private network, ensuring it can communicate with Droplets using private IPs.
• forwarding_rule defines how traffic is directed. We’ve set up HTTP forwarding from port 80 to port 80 on the backend servers. For production, you’d typically configure HTTPS here, potentially terminating SSL at the load balancer.
• healthcheck is critical for ensuring traffic is only sent to healthy application servers. Adjust the path to a dedicated health check endpoint in your Perl application.
• droplet_tag_filter automatically associates the load balancer with any Droplets that have both the perl-cluster and app-server tags. This makes scaling the application servers dynamic.
• We define a digitalocean_vpc to ensure our Droplets are on a private network, which is more secure and efficient for inter-Droplet communication.
• The loadbalancer_ip output makes it easy to find the public IP of your load balancer after deployment.

Securing the Infrastructure with Firewalls

DigitalOcean’s Cloud Firewalls provide a network-level security layer. We’ll configure a firewall to allow only necessary traffic to our Droplets and the load balancer.

# main.tf (continued)

resource "digitalocean_firewall" "perl_firewall" {
  name = "perl-cluster-firewall"

  # Apply firewall to all Droplets tagged with "perl-cluster"
  droplet_ids = [for droplet in digitalocean_droplet.perl_app : droplet.id]

  # Allow SSH from a specific IP range (e.g., your office or bastion host)
  # For broader access, consider a bastion host setup and only allow SSH to that.
  inbound_rule {
    protocol         = "tcp"
    port_range       = "22"
    source_addresses = ["YOUR_SECURE_IP_RANGE/32"] # e.g., "203.0.113.5/32" or "192.168.1.0/24"
  }

  # Allow HTTP and HTTPS from the Load Balancer's IP
  # Note: DigitalOcean Load Balancers have a fixed IP range for health checks and traffic.
  # It's best to allow traffic from the LB's public IP.
  inbound_rule {
    protocol         = "tcp"
    port_range       = "80"
    source_droplets  = [digitalocean_loadbalancer.perl_lb.id] # Allow from LB
    source_tags      = ["loadbalancer"] # Alternative: tag the LB resource
  }

  inbound_rule {
    protocol         = "tcp"
    port_range       = "443"
    source_droplets  = [digitalocean_loadbalancer.perl_lb.id]
    source_tags      = ["loadbalancer"]
  }

  # Allow all outbound traffic (common for servers to fetch updates, etc.)
  outbound_rule {
    protocol              = "tcp"
    port_range            = "1-65535"
    destination_addresses = ["0.0.0.0/0"]
  }
  outbound_rule {
    protocol              = "udp"
    port_range            = "1-65535"
    destination_addresses = ["0.0.0.0/0"]
  }
  outbound_rule {
    protocol              = "icmp"
    destination_addresses = ["0.0.0.0/0"]
  }

  tags = ["perl-cluster", "firewall"]
}

# Add a tag to the load balancer resource for easier firewall referencing
resource "digitalocean_tag" "loadbalancer_tag" {
  key  = "loadbalancer"
  value = "true"
  resource_id = digitalocean_loadbalancer.perl_lb.id
}

Explanation of the firewall rules:

• The firewall is applied to all Droplets tagged with perl-cluster.
• SSH Access: The first inbound_rule allows SSH (port 22) access. It is critical to restrict source_addresses to only trusted IPs. For a production environment, consider using a bastion host and only allowing SSH from the bastion.
• Load Balancer Access: Rules are added to allow HTTP (port 80) and HTTPS (port 443) traffic originating from the perl_lb. Using source_droplets or source_tags referencing the load balancer is the most robust way to ensure traffic is allowed from the LB.
• Outbound Access: We allow all outbound traffic, which is typical for servers needing to download updates, fetch dependencies, or communicate with external services.
• We explicitly tag the load balancer resource to make referencing it in the firewall easier.

Optional: Managed Database

For stateful applications, a managed database is highly recommended. Here’s how you might provision a PostgreSQL database.

# main.tf (continued)

resource "digitalocean_database_cluster" "perl_db" {
  name       = "perl-app-db"
  engine     = "pg" # PostgreSQL
  version    = "14" # Specify your desired PostgreSQL version
  region     = var.region
  size       = "db-s-1vcpu-2gb" # Adjust size as needed
  node_count = 1 # For high availability, set to 3

  # Enable private networking for secure access from Droplets
  private_network_subnet = digitalocean_vpc.perl_vpc.id

  # Configure firewall rules for the database
  # Allow connections only from the VPC subnet
  db_firewall {
    uuid = digitalocean_vpc.perl_vpc.id
  }

  tags = ["perl-cluster", "database"]
}

# Output database connection details (handle sensitive data carefully)
output "db_host" {
  description = "Database host address"
  value       = digitalocean_database_cluster.perl_db.host
  sensitive   = true
}

output "db_port" {
  description = "Database port"
  value       = digitalocean_database_cluster.perl_db.port
  sensitive   = true
}

output "db_name" {
  description = "Database name"
  value       = digitalocean_database_cluster.perl_db.database
  sensitive   = true
}

output "db_user" {
  description = "Database username"
  value       = digitalocean_database_cluster.perl_db.username
  sensitive   = true
}

output "db_password" {
  description = "Database password"
  value       = digitalocean_database_cluster.perl_db.password
  sensitive   = true
}

Important considerations for the database:

• We use digitalocean_database_cluster to provision a managed PostgreSQL instance.
• private_network_subnet ensures the database is accessible only via its private IP within the VPC, enhancing security.
• The db_firewall rule explicitly allows connections from our VPC.
• Sensitive Outputs: Database credentials are sensitive. Terraform marks them as such, but you must handle these outputs securely, perhaps by passing them to your application’s configuration management or directly into environment variables on your Droplets (e.g., via a secrets manager or a separate provisioning step).

Deployment Workflow

With the Terraform configuration in place, the deployment process is straightforward:

1. Initialize Terraform: Navigate to your Terraform project directory and run terraform init. This downloads the DigitalOcean provider.
2. Review the Plan: Run terraform plan to see exactly what resources Terraform will create, modify, or destroy. Carefully review this output.
3. Apply the Configuration: Execute terraform apply. Terraform will prompt you to confirm the changes. Type yes to proceed with provisioning the infrastructure.
4. Access Your Application: Once the apply is complete, Terraform will output the load balancer’s IP address. You can then access your Perl application via this IP.
5. Destroy Resources (when needed): To tear down the entire infrastructure, run terraform destroy.

This IaC approach provides a repeatable, version-controlled, and secure method for deploying and managing your Perl clusters on DigitalOcean. Remember to adapt the application deployment steps within the remote-exec provisioner to match your specific application’s needs.