Vengala Vinay

Having 9+ Years of Experience in Software Development

Home » Dockerizing and Orchestrating Legacy Ruby Systems on Modern OVH Infrastructure

Dockerizing and Orchestrating Legacy Ruby Systems on Modern OVH Infrastructure

Assessing Legacy Ruby Application Dependencies

Before diving into containerization, a thorough audit of the legacy Ruby application’s dependencies is paramount. This involves identifying not only Ruby gems but also system-level libraries, external services, and specific environment variables crucial for its operation. For older Rails applications, this often means dealing with deprecated gems, unsupported Ruby versions, and implicit assumptions about the host operating system. A common pitfall is relying on system packages that are no longer maintained or have security vulnerabilities. Tools like bundle outdated and manual inspection of Gemfile and Gemfile.lock are starting points. However, a deeper dive into the application’s runtime behavior is necessary.

Consider an application that implicitly relies on a specific version of imagemagick installed via a system package manager. If this dependency isn’t explicitly declared and managed within the containerization strategy, the application will fail to start or exhibit unexpected behavior when deployed. Similarly, applications might depend on specific file system structures or permissions that are taken for granted in a traditional server environment but need explicit configuration within a container.

Crafting a Dockerfile for Ruby Legacy Applications

The Dockerfile is the blueprint for your container image. For legacy Ruby applications, it’s often beneficial to start with a stable, well-supported base image that aligns with the application’s Ruby version or a version that can be reliably upgraded. Alpine Linux is a popular choice for its small size, but it can sometimes introduce compatibility issues with native extensions. Debian-based images (like ruby:X.Y.Z-slim) often offer better compatibility out-of-the-box.

Here’s a sample Dockerfile demonstrating best practices for a hypothetical Rails 4 application:

# Use a specific, stable Ruby version. Consider upgrading if feasible.
FROM ruby:2.5.9-slim

# Set environment variables to prevent interactive prompts during package installation
ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8
ENV RAILS_ENV production
ENV SECRET_KEY_BASE "dummy_secret_key_base_for_build" # Required for Rails 5+ asset precompilation

# Install essential build tools and system dependencies.
# This is crucial for gems with native extensions.
# Adjust packages based on your application's specific needs.
RUN apt-get update -qq && \
    apt-get install -y --no-install-recommends \
    build-essential \
    git \
    libpq-dev \
    libxml2-dev \
    libxslt1-dev \
    nodejs \
    npm \
    imagemagick \
    && rm -rf /var/lib/apt/lists/*

# Set the working directory
WORKDIR /app

# Copy the Gemfile and Gemfile.lock first to leverage Docker cache
COPY Gemfile Gemfile
COPY Gemfile.lock Gemfile.lock

# Install gems. Use --jobs to speed up installation.
# Consider using a local gem source or a private gem server for faster builds.
RUN bundle install --jobs $(nproc) --without development test --deployment

# Copy the rest of the application code
COPY . .

# Precompile assets if it's a Rails application.
# This can be a time-consuming step. Consider doing it in a separate build stage.
RUN bundle exec rails assets:precompile

# Expose the port the application runs on
EXPOSE 3000

# Define the command to run your application
# Use a production-ready web server like Puma or Unicorn.
CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]

Key Considerations for the Dockerfile:

  • Base Image Selection: Pinning to a specific Ruby version is critical for reproducibility. If the application requires a newer Ruby, plan for a migration.
  • System Dependencies: The apt-get install command is a prime candidate for customization. Analyze your application’s gems and their native dependencies. For example, if your app uses pg, libpq-dev is essential. If it uses nokogiri, libxml2-dev and libxslt1-dev are often needed.
  • Caching: Copying Gemfile and Gemfile.lock before the rest of the application code ensures that Docker caches the gem installation layer. If only application code changes, the gems won’t need to be reinstalled.
  • Asset Precompilation: For Rails applications, assets:precompile is a mandatory step. This can significantly increase build times. For faster builds, consider multi-stage builds where assets are precompiled in a separate builder stage and then copied to the final, leaner image.
  • Production Web Server: Avoid using WEBrick for production. Puma or Unicorn are standard choices. Ensure their configuration files (e.g., config/puma.rb) are optimized for the container environment.
  • Environment Variables: Sensitive information like database credentials, API keys, and SECRET_KEY_BASE should never be hardcoded in the Dockerfile. They should be injected at runtime. The SECRET_KEY_BASE is a special case for Rails asset precompilation.

Containerizing with Docker Compose for Local Development and Testing

Docker Compose simplifies the management of multi-container Docker applications. It’s invaluable for setting up local development environments that mimic production, including databases, caching layers, and other services. This allows developers to run the entire application stack with a single command.

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: legacy_ruby_app
    ports:
      - "3000:3000"
    volumes:
      - .:/app # Mount application code for live development (optional, can slow down builds)
      - bundle_cache:/usr/local/bundle # Persist gem cache
    environment:
      RAILS_ENV: development
      DATABASE_URL: postgres://user:password@db:5432/mydb
      REDIS_URL: redis://redis:6379/0
      SECRET_KEY_BASE: <your_development_secret_key_base>
    depends_on:
      - db
      - redis
    networks:
      - app-network

  db:
    image: postgres:13
    container_name: legacy_ruby_db
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - app-network

  redis:
    image: redis:6
    container_name: legacy_ruby_redis
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    networks:
      - app-network

volumes:
  bundle_cache:
  db_data:
  redis_data:

networks:
  app-network:
    driver: bridge

Explanation of the docker-compose.yml:

  • services: Defines the individual containers.
  • app:
    • build: Specifies the Dockerfile to use.
    • container_name: A friendly name for the container.
    • ports: Maps host ports to container ports.
    • volumes:
      • .:/app: Mounts the current directory into the container. This is useful for live code changes during development but can be removed for production builds or testing to ensure you’re testing the built image.
      • bundle_cache:/usr/local/bundle: Persists the gem installation directory across container restarts, speeding up subsequent builds and runs.
    • environment: Sets environment variables. Crucially, DATABASE_URL and REDIS_URL point to the other services defined in the compose file.
    • depends_on: Ensures that the db and redis services are started before the app service.
    • networks: Connects the service to a custom bridge network for inter-container communication.
  • db and redis: Standard images for PostgreSQL and Redis, configured with necessary environment variables and persistent volumes for data.
  • volumes: Declares named volumes for persistent data and gem caching.
  • networks: Defines a custom bridge network for the services.

To run this setup, navigate to the directory containing the Dockerfile and docker-compose.yml and execute: docker-compose up -d. This will build the image (if not already built), start the containers, and run them in detached mode.

Orchestration on OVHcloud: Leveraging Managed Kubernetes (K8s)

For production deployments on OVHcloud, Kubernetes (K8s) is the de facto standard for orchestration. OVHcloud offers managed Kubernetes services that abstract away much of the underlying infrastructure management, allowing you to focus on deploying and scaling your applications.

The process involves:

  • Building and Pushing Docker Images: Your Docker image needs to be built and pushed to a container registry accessible by your Kubernetes cluster. OVHcloud provides its own Container Registry, or you can use external ones like Docker Hub, AWS ECR, or Google GCR.
# Build the Docker image
docker build -t your-registry.io/your-app:v1.0.0 .

# Log in to your OVHcloud Container Registry (replace with your actual details)
docker login your-registry.io

# Push the image
docker push your-registry.io/your-app:v1.0.0

Kubernetes Manifests (YAML): You’ll need Kubernetes resource definitions (manifests) to deploy your application. This typically includes a Deployment to manage your application pods and a Service to expose your application.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-ruby-app-deployment
  labels:
    app: legacy-ruby-app
spec:
  replicas: 3 # Start with 3 replicas for high availability
  selector:
    matchLabels:
      app: legacy-ruby-app
  template:
    metadata:
      labels:
        app: legacy-ruby-app
    spec:
      containers:
      - name: legacy-ruby-app
        image: your-registry.io/your-app:v1.0.0 # Your pushed Docker image
        ports:
        - containerPort: 3000
        env:
        - name: RAILS_ENV
          value: "production"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: database-url
        - name: REDIS_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: redis-url
        - name: SECRET_KEY_BASE
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: secret-key-base
        resources: # Define resource requests and limits
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
      # Consider using an initContainer to run database migrations
      # initContainers:
      # - name: db-migrations
      #   image: your-registry.io/your-app:v1.0.0
      #   command: ["bundle", "exec", "rails", "db:migrate", "RAILS_ENV=production"]
      #   envFrom:
      #   - secretRef:
      #       name: app-secrets

---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: legacy-ruby-app-service
spec:
  selector:
    app: legacy-ruby-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: LoadBalancer # OVHcloud will provision a LoadBalancer for external access

Explanation of Kubernetes Manifests:

  • Deployment: Manages the desired state of your application pods. It ensures that a specified number of replicas are running and handles rolling updates.
  • replicas: Defines the number of identical pods to run.
  • selector: Links the Deployment to the pods it manages.
  • template: Defines the pod specification.
  • containers:
    • name: Name of the container.
    • image: The Docker image to use.
    • containerPort: The port your application listens on inside the container.
    • env: Environment variables. Notice how sensitive variables are sourced from a Secret.
    • resources: Crucial for K8s. Define CPU and memory requests (guaranteed) and limits (maximum allowed). This prevents noisy neighbors and ensures stability.
  • initContainers (Commented Out): A common pattern is to use an init container to run database migrations before the main application containers start. This ensures your database schema is up-to-date.
  • Service: Provides a stable IP address and DNS name for accessing your application pods.
  • type: LoadBalancer: When applied to OVHcloud K8s, this automatically provisions an external load balancer, making your application accessible from the internet.

Secrets Management: For production, sensitive information like database credentials, API keys, and the SECRET_KEY_BASE should be stored in Kubernetes Secrets. Create a secret like this:

# secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  database-url: <base64_encoded_database_url>
  redis-url: <base64_encoded_redis_url>
  secret-key-base: <base64_encoded_secret_key_base>

You can encode values using `echo -n ‘your_value’ | base64`. Apply these manifests using kubectl apply -f deployment.yaml -f service.yaml -f secrets.yaml.

Database and Persistent Storage Considerations

Legacy applications often have tightly coupled database dependencies. When moving to Kubernetes, you have several options for managing your database:

  • Managed Database Services (Recommended): OVHcloud offers managed database services (e.g., OVHcloud Managed Databases) that handle backups, scaling, and high availability. This is the most robust and least operationally intensive approach. Your Kubernetes application pods would connect to these external database endpoints.
  • StatefulSets in Kubernetes: For databases running within Kubernetes, use StatefulSets. These provide stable network identifiers, persistent storage per pod, and ordered, graceful deployment and scaling. You would typically use a database image (e.g., PostgreSQL, MySQL) and configure it with a PersistentVolumeClaim (PVC) to request storage from your cluster’s storage provisioner.
  • External Persistent Volumes: If your legacy application relies on specific file storage, ensure your Kubernetes cluster is configured with appropriate StorageClasses that map to OVHcloud’s block storage or object storage solutions.

When using managed databases, ensure your application’s connection strings are correctly configured via environment variables (as shown in the Kubernetes manifests) and that network policies allow communication between your K8s pods and the managed database instances.

Monitoring, Logging, and Health Checks

Production readiness demands robust monitoring, logging, and health checking. For containerized legacy Ruby apps on K8s:

  • Health Checks (Liveness and Readiness Probes): Configure Kubernetes livenessProbe and readinessProbe in your Deployment. These tell Kubernetes when your application is healthy and ready to receive traffic. A simple HTTP endpoint (e.g., /health) that returns a 200 OK is common.
# Add these to your container spec in deployment.yaml
livenessProbe:
  httpGet:
    path: /health # Assuming you have a /health endpoint in your Rails app
    port: 3000
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 15
  periodSeconds: 5

Logging: Kubernetes aggregates logs from all containers. For effective analysis, consider a centralized logging solution. OVHcloud’s Log Management service or open-source solutions like the ELK stack (Elasticsearch, Logstash, Kibana) or Grafana Loki can be deployed within or alongside your cluster.

Monitoring: Integrate Prometheus and Grafana for metrics collection and visualization. You can deploy Prometheus operators within your K8s cluster to scrape metrics from your application (if instrumented) and the cluster itself. Tools like the ruby-prof gem or application performance monitoring (APM) solutions can provide deeper insights into Ruby application performance.

Conclusion: A Phased Approach to Modernization

Containerizing and orchestrating legacy Ruby systems on modern infrastructure like OVHcloud’s managed Kubernetes is a significant undertaking. It requires a deep understanding of the application’s dependencies, careful crafting of Dockerfiles, robust orchestration manifests, and a strategic approach to persistent storage and monitoring. While the initial effort can be substantial, the benefits in terms of scalability, resilience, and simplified management are considerable. This process also serves as a stepping stone towards further modernization, potentially paving the way for microservices or more significant refactoring efforts.