Dockerizing and Orchestrating Legacy Ruby Systems on Modern AWS Infrastructure

Assessing Legacy Ruby Application Dependencies

Before embarking on the containerization journey for a legacy Ruby application, a thorough assessment of its dependencies is paramount. This involves identifying not only Ruby gems but also system-level libraries, external services, and specific runtime versions. For older applications, particularly those built on Ruby 1.8 or 1.9, this step is critical as direct upgrades might be infeasible without significant refactoring. The goal is to create an isolated, reproducible environment that mirrors the application’s current operational state as closely as possible.

Key areas to investigate include:

• Ruby Version: Determine the exact Ruby version used. Tools like ruby -v or checking Gemfile (if present) are starting points. For very old systems, this might be a version no longer officially supported.
• System Libraries: Many Ruby gems rely on underlying C libraries (e.g., libxml2, openssl, imagemagick). Identify these by examining gem installation logs or by attempting to build the application in a clean environment.
• Database Drivers: Note the specific database (e.g., MySQL, PostgreSQL) and the version of the corresponding adapter gem.
• External Services: Document dependencies on external APIs, message queues (e.g., RabbitMQ, Redis), or file storage systems.
• Environment Variables: Catalog all environment variables the application expects for configuration.

Crafting the Dockerfile for a Legacy Ruby App

The Dockerfile is the blueprint for your container image. For legacy Ruby applications, it often requires a multi-stage build to keep the final image lean and secure. We’ll start with a base image that provides the necessary Ruby version and then copy over the application code and its dependencies.

Consider an application with a Gemfile and Gemfile.lock. We’ll assume a need for specific system libraries like libpq-dev for PostgreSQL and imagemagick.

Multi-Stage Dockerfile Example

This example uses a Debian-based image for broader compatibility with system libraries. The first stage installs Ruby and gems, and the second stage copies only the necessary artifacts.

Stage 1: Builder

# Stage 1: Builder
FROM ruby:2.3.8-slim-stretch as builder

LABEL maintainer="Your Name <[email protected]>"

# Set environment variables to prevent interactive prompts during package installation
ENV DEBIAN_FRONTEND=noninteractive

# Install essential build tools and system libraries
RUN apt-get update -qq && apt-get install -y --no-install-recommends \
    build-essential \
    git \
    libpq-dev \
    imagemagick \
    libxml2-dev \
    libxslt-dev \
    && rm -rf /var/lib/apt/lists/*

# Set working directory
WORKDIR /app

# Copy Gemfile and Gemfile.lock
COPY Gemfile Gemfile.lock ./

# Install gems. Use a specific bundler version if required by the legacy app.
# For older Ruby versions, you might need to install bundler separately first.
# RUN gem install bundler -v '~>1.17.0'
RUN bundle install --jobs $(nproc) --retry 3

# Copy the rest of the application code
COPY . .

# Precompile assets if it's a Rails application
# RUN bundle exec rails assets:precompile

Stage 2: Final Image

# Stage 2: Final Image
FROM ruby:2.3.8-slim-stretch

LABEL maintainer="Your Name <[email protected]>"

ENV DEBIAN_FRONTEND=noninteractive

# Install only runtime dependencies
RUN apt-get update -qq && apt-get install -y --no-install-recommends \
    libpq5 \
    imagemagick \
    libxml2 \
    libxslt1 \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy gems and application code from the builder stage
COPY --from=builder /usr/local/bundle /usr/local/bundle
COPY --from=builder /app /app

# Expose the port the application runs on (e.g., Puma or Unicorn)
EXPOSE 3000

# Define the command to run the application
# This will vary based on your application's server (Puma, Unicorn, etc.)
# Example for Puma:
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]
# Example for Unicorn:
# CMD ["bundle", "exec", "unicorn", "-c", "config/unicorn.rb"]

Important Considerations:

• Ruby Version Pinning: Ensure the FROM instruction uses the exact Ruby version. If the official image for that specific version doesn’t exist, you might need to build it from source or find a compatible community image.
• System Dependencies: Carefully list all required system packages. Use apt-get install -y --no-install-recommends to minimize image size. Clean up apt cache with rm -rf /var/lib/apt/lists/*.
• Gem Installation: bundle install can be time-consuming. Running it in the builder stage and then copying the installed gems (/usr/local/bundle) to the final stage is crucial for efficiency.
• Asset Precompilation: For Rails applications, uncomment and adapt the assets:precompile step if necessary.
• Application Server: The CMD instruction must correctly invoke your application’s server (Puma, Unicorn, Passenger, etc.) with its configuration.
• Environment Variables: Sensitive configurations should not be hardcoded. Use environment variables, which can be injected at runtime by the orchestrator.

Orchestrating with Amazon ECS and Fargate

Amazon Elastic Container Service (ECS) with AWS Fargate provides a serverless compute engine for containers, abstracting away the underlying EC2 instances. This is ideal for legacy applications where managing infrastructure is an added burden.

ECS Task Definition

The Task Definition describes how to run your container(s) on ECS. It specifies the Docker image, CPU/memory requirements, environment variables, port mappings, and logging configuration.

Example Task Definition (JSON)

{
    "family": "legacy-ruby-app",
    "networkMode": "awsvpc",
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "cpu": "512",
    "memory": "1024",
    "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
    "taskRoleArn": "arn:aws:iam::123456789012:role/legacyRubyAppTaskRole",
    "containerDefinitions": [
        {
            "name": "legacy-ruby-container",
            "image": "YOUR_AWS_ACCOUNT_ID.dkr.ecr.YOUR_REGION.amazonaws.com/legacy-ruby-app:latest",
            "essential": true,
            "portMappings": [
                {
                    "containerPort": 3000,
                    "hostPort": 3000,
                    "protocol": "tcp"
                }
            ],
            "environment": [
                {
                    "name": "RAILS_ENV",
                    "value": "production"
                },
                {
                    "name": "DATABASE_URL",
                    "valueFrom": "arn:aws:secretsmanager:YOUR_REGION:123456789012:secret:my-db-secret-XXXXXX:username::"
                },
                {
                    "name": "DATABASE_PASSWORD",
                    "valueFrom": "arn:aws:secretsmanager:YOUR_REGION:123456789012:secret:my-db-secret-XXXXXX:password::"
                },
                {
                    "name": "SECRET_KEY_BASE",
                    "valueFrom": "arn:aws:secretsmanager:YOUR_REGION:123456789012:secret:my-rails-secrets-XXXXXX:secret_key_base::"
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/legacy-ruby-app",
                    "awslogs-region": "YOUR_REGION",
                    "awslogs-stream-prefix": "ecs"
                }
            }
        }
    ]
}

Explanation:

• family: A name for your task definition.
• networkMode: "awsvpc": Required for Fargate.
• requiresCompatibilities: ["FARGATE"]: Specifies Fargate as the launch type.
• cpu and memory: Define the compute resources for the task. Adjust based on your application’s needs.
• executionRoleArn: IAM role for ECS agent to pull images and send logs.
• taskRoleArn: IAM role for your application to access other AWS services (e.g., Secrets Manager, S3).
• containerDefinitions: An array of containers.
• image: The ECR repository URI for your Docker image.
• portMappings: Maps the container port to the host (though with awsvpc, this is less about host mapping and more about defining the service’s ingress port).
• environment: Crucial for legacy apps. Use valueFrom to pull secrets from AWS Secrets Manager, avoiding hardcoding sensitive data.
• logConfiguration: Configures sending logs to CloudWatch Logs for centralized monitoring.

ECS Service and Load Balancer Integration

An ECS Service manages the desired number of tasks and handles deployments. Integrating with an Application Load Balancer (ALB) provides a stable entry point, SSL termination, and distributes traffic across your tasks.

Steps:

1. Create an ALB: Set up an ALB in your VPC with appropriate subnets and security groups.
2. Create a Target Group: Configure a target group pointing to the port your container exposes (e.g., 3000) and the VPC.
3. Create an ECS Cluster: If you don’t have one, create an ECS cluster (choose “Networking only” for Fargate).
4. Create an ECS Service:
   • Select your cluster.
   • Choose the Task Definition created earlier.
   • Select the desired number of tasks (e.g., 2 for high availability).
   • Configure networking: Select your VPC, subnets, and a security group that allows inbound traffic on port 3000 from the ALB’s security group.
   • Under “Load balancing,” choose “Application Load Balancer.”
   • Select your ALB and the previously created Target Group.
5. Configure ALB Listener: Set up an HTTPS listener on the ALB (port 443) with an ACM certificate, forwarding traffic to your ECS Target Group. Optionally, set up an HTTP listener (port 80) to redirect to HTTPS.

Database Migration and Connectivity

Legacy Ruby applications often have tightly coupled database logic. Migrating the database to a managed AWS service like Amazon RDS is highly recommended. For Fargate tasks, ensure the task’s security group allows outbound connections to the RDS instance’s security group on the database port (e.g., 5432 for PostgreSQL).

Connecting from Fargate to RDS

1. RDS Security Group: Create or modify your RDS instance’s security group to allow inbound traffic on the database port from the ECS Task Execution Security Group or a dedicated security group for your Fargate tasks.

2. ECS Task Security Group: Ensure the security group associated with your ECS Fargate task allows outbound traffic to the RDS instance’s security group on the database port.

3. Database Credentials: As shown in the Task Definition example, use AWS Secrets Manager to store and retrieve database credentials securely. The taskRoleArn in the Task Definition must have permissions to access Secrets Manager.

4. Database URL/Configuration: Update your application’s configuration (often via environment variables like DATABASE_URL) to point to the RDS endpoint. The legacy application might need minor code adjustments if it uses hardcoded connection strings.

Monitoring and Logging

Effective monitoring and logging are crucial for maintaining the health and performance of containerized legacy applications. AWS CloudWatch is the natural choice when using ECS and Fargate.

CloudWatch Logs Configuration

The logConfiguration in the ECS Task Definition directs container logs to CloudWatch Logs. Ensure you have a log group (e.g., /ecs/legacy-ruby-app) created or allow ECS to create it. You can then set up metric filters and alarms based on log patterns.

Application Performance Monitoring (APM)

For deeper insights into application performance, consider integrating an APM tool. Many legacy Ruby applications can be instrumented with agents like:

• New Relic
• Datadog
• AppSignal

These agents typically require specific environment variables or configuration files to be present within the container. You can inject these via the environment section of your ECS Task Definition or by including them in your Docker image during the build process.

Rollback and Disaster Recovery Strategies

Containerization simplifies rollbacks. ECS services support rolling deployments, allowing you to gradually replace old tasks with new ones. If a deployment introduces issues, you can quickly revert to a previous task definition version.

Automated Rollbacks

Configure your ECS Service’s deployment controller to automatically roll back if a specified number of tasks fail to become healthy within a given timeframe. This is often tied to the health checks configured in your ALB Target Group.

Disaster Recovery

For DR, consider:

• Multi-AZ Deployments: Deploy your ECS service across multiple Availability Zones within a region. Fargate tasks are automatically distributed.
• Multi-Region Strategy: For higher availability, replicate your infrastructure (ECS, ALB, RDS) in a secondary AWS region. This involves more complex setup, potentially using AWS CloudFormation or Terraform for infrastructure as code and Route 53 for DNS-based failover.
• Database Backups: Ensure your RDS instance has automated backups enabled and test restore procedures regularly.

By carefully containerizing and orchestrating legacy Ruby applications on AWS ECS with Fargate, you can achieve improved scalability, reliability, and manageability, extending the life of valuable existing systems while leveraging modern cloud infrastructure.