Vengala Vinay

Having 9+ Years of Experience in Software Development

Home » Zero-Downtime Blue-Green Deployment Pipelines for Ruby Applications on OVH

Zero-Downtime Blue-Green Deployment Pipelines for Ruby Applications on OVH

Understanding the Blue-Green Deployment Strategy

Blue-Green deployment is a technique for releasing software that minimizes downtime and risk. It involves running two identical production environments, referred to as “Blue” and “Green.” At any given time, only one environment is live, serving production traffic. The other environment is idle, used for deployment and testing. Once the new version is deployed and validated on the idle environment, traffic is switched over. This allows for instant rollback by simply switching traffic back to the original environment if issues arise.

OVH Infrastructure for Blue-Green Deployments

For this strategy on OVH, we’ll leverage their Public Cloud instances, Load Balancers, and potentially their Container Registry if using Docker. The core idea is to have two distinct sets of identical virtual machines (VMs) or containers, each running a full instance of our Ruby application. A highly available OVH Load Balancer will sit in front of these environments, managing traffic distribution.

Setting Up Identical Environments

The first step is to provision two identical sets of infrastructure. This can be achieved through Infrastructure as Code (IaC) tools like Terraform or Ansible. For simplicity in this example, we’ll assume manual provisioning or a pre-existing script. Each environment (Blue and Green) will consist of:

  • A set of identical OVH Public Cloud instances (e.g., `b2-7` instances).
  • A database instance (e.g., PostgreSQL on OVH Managed Databases or a self-hosted instance on a separate VM). Crucially, both environments must connect to the *same* database instance to avoid data divergence during the switch. Schema changes must be backward compatible.
  • An application server (e.g., Puma or Unicorn) configured to listen on a specific port (e.g., 3000).
  • A reverse proxy (e.g., Nginx) on each instance, configured to forward traffic to the application server.

Configuring the OVH Load Balancer

The OVH Load Balancer is the critical component for traffic switching. We’ll configure it with two distinct backend pools, one for the Blue environment and one for the Green environment. Initially, only the Blue pool will be active.

Let’s assume your Blue environment instances have IP addresses 192.168.1.10, 192.168.1.11, and your Green environment instances have 192.168.1.20, 192.168.1.21. Both are running your Ruby app on port 3000.

OVH Load Balancer Frontend Configuration

This configuration defines how the load balancer accepts incoming traffic. We’ll use HTTP on port 80 and HTTPS on port 443 (assuming SSL termination at the load balancer).

OVH Load Balancer Backend Pool: Blue

This pool points to the instances in the Blue environment.

# Example configuration snippet for OVH Load Balancer (conceptual)
# Actual configuration is done via OVH API or Control Panel

# Frontend Configuration
frontend http_frontend
    bind *:80
    mode http
    default_backend blue_backend

frontend https_frontend
    bind *:443 ssl crt /etc/ssl/certs/your_domain.pem
    mode http
    default_backend blue_backend

# Backend Pool: Blue Environment
backend blue_backend
    mode http
    balance roundrobin
    option httpchk GET /health
    server blue-server-1 192.168.1.10:3000 check
    server blue-server-2 192.168.1.11:3000 check
    # ... more blue servers

OVH Load Balancer Backend Pool: Green (Initially Disabled)

This pool points to the instances in the Green environment. It’s configured identically to the Blue pool but is not currently active.

# Backend Pool: Green Environment (initially inactive)
backend green_backend
    mode http
    balance roundrobin
    option httpchk GET /health
    server green-server-1 192.168.1.20:3000 check
    server green-server-2 192.168.1.21:3000 check
    # ... more green servers

The Deployment Pipeline Workflow

The deployment process involves several distinct phases, orchestrated by your CI/CD system (e.g., GitLab CI, GitHub Actions, Jenkins).

Phase 1: Deploy to the Idle Environment (Green)

The new version of the Ruby application is deployed to the Green environment. This environment is completely isolated from live traffic. This deployment can involve updating code, installing gems, precompiling assets, and restarting the application server.

Phase 2: Smoke Testing and Validation

Once the deployment to Green is complete, a series of automated tests are executed against the Green environment. These include:

  • Smoke Tests: Basic checks to ensure the application starts and responds.
  • Integration Tests: Verifying interactions with external services (database, APIs).
  • End-to-End Tests: Simulating user journeys through the application.
  • Health Checks: Ensuring the application’s health endpoints are returning success codes.

A simple Ruby script using Net::HTTP or a tool like curl can be used for these checks.

require 'net/http'
require 'uri'

def check_health(host, port, path = '/health')
  uri = URI.parse("http://#{host}:#{port}#{path}")
  http = Net::HTTP.new(uri.host, uri.port)
  request = Net::HTTP::Get.new(uri.request_uri)

  begin
    response = http.request(request)
    if response.code.to_i == 200
      puts "Health check successful for #{host}:#{port}"
      true
    else
      puts "Health check failed for #{host}:#{port} with status code #{response.code}"
      false
    end
  rescue Errno::ECONNREFUSED
    puts "Connection refused for #{host}:#{port}"
    false
  rescue StandardError => e
    puts "An error occurred: #{e.message}"
    false
  end
end

# Example usage for Green environment
green_hosts = ['192.168.1.20', '192.168.1.21']
all_healthy = true
green_hosts.each do |host|
  all_healthy &&= check_health(host, 3000) # Assuming app runs on port 3000
end

if all_healthy
  puts "Green environment is healthy. Proceeding to traffic switch."
  # Trigger load balancer switch via API
else
  puts "Green environment is NOT healthy. Aborting deployment."
  exit(1) # Indicate failure
end

Phase 3: Traffic Switching

This is the most critical step. The OVH Load Balancer configuration is updated to direct traffic from the Blue backend pool to the Green backend pool. This is typically done via the OVH API. The switch should be as atomic as possible.

The goal is to modify the load balancer’s default backend from blue_backend to green_backend. This might involve updating a frontend rule or changing the active backend pool.

# Conceptual OVH API call to switch traffic
# This would be part of your CI/CD script

# Assume you have an OVH API client configured
# The exact API endpoint and payload will depend on your OVH Load Balancer service

# Example: Update frontend to point to green_backend
curl -X PUT \
  "https://api.ovh.com/1.0/loadbalancer/your_loadbalancer_id/frontend/your_frontend_id" \
  -H "Content-Type: application/json" \
  -d '{
    "defaultBackend": "green_backend",
    "protocol": "http",
    "port": 80,
    "sslConfiguration": null
  }'

# If using separate frontends for HTTP/HTTPS, update both



Phase 4: Post-Switch Validation and Monitoring





Immediately after the switch, monitor application performance and error rates closely. Automated checks should continue to run against the now-live Green environment. If any issues are detected, initiate an immediate rollback.





Phase 5: Rollback Procedure





If problems are found in the Green environment after the switch, the rollback is as simple as switching the load balancer back to the Blue environment. The Blue environment, which has been serving traffic until the switch, is still running the previous stable version.




# Conceptual OVH API call to switch traffic back to Blue

# Example: Update frontend to point back to blue_backend
curl -X PUT \
  "https://api.ovh.com/1.0/loadbalancer/your_loadbalancer_id/frontend/your_frontend_id" \
  -H "Content-Type: application/json" \
  -d '{
    "defaultBackend": "blue_backend",
    "protocol": "http",
    "port": 80,
    "sslConfiguration": null
  }'



Phase 6: Decommissioning the Old Environment





Once the Green environment has been stable in production for a sufficient period, the Blue environment can be safely decommissioned or prepared for the next deployment cycle (where it would become the "Green" environment).





Database Migrations and Schema Changes





Database schema changes are the most challenging aspect of Blue-Green deployments. To maintain zero downtime, migrations must be backward compatible. This typically involves a multi-step process:





  • Step 1: Deploy migration that adds new columns/tables (no data loss). This migration is deployed to the Blue environment. The application code is updated to be compatible with both the old and new schema (e.g., it can read from old columns and write to new ones if necessary, or simply ignore the new ones).
  • Step 2: Deploy application code that uses the new schema. This code is deployed to the Blue environment.
  • Step 3: Deploy the same migration to the Green environment. Now both Blue and Green have the new schema.
  • Step 4: Deploy application code that uses the new schema to the Green environment.
  • Step 5: Switch traffic to Green.
  • Step 6: (Optional) Deploy migration that removes old columns/tables. This is done after a period of stability and traffic has been on Green.





Tools like ActiveRecord::Migration in Rails, when used carefully with backward-compatible changes, facilitate this. Always test migrations thoroughly in a staging environment that mirrors production.





Handling State and Session Management





If your application relies on sticky sessions (session affinity), the load balancer configuration needs to support it. However, for true zero-downtime deployments, it's best to avoid sticky sessions. Implement statelessness in your application servers and use a shared session store (like Redis or Memcached) accessible by both Blue and Green environments.





Containerized Deployments with Docker and OVH





If you're using Docker, the process is similar but managed at the container orchestration level. You would deploy new container images to one set of your orchestrator's nodes (e.g., Kubernetes cluster, or OVH's Managed Kubernetes service) while the other set remains active. The OVH Load Balancer would then point to the service endpoints of the new containers.





The key is that the load balancer configuration (or its equivalent in an orchestrator like Kubernetes Services and Ingress) is the single point of traffic control. OVH Container Registry can be used to store your Docker images.





Automation and CI/CD Integration





The entire Blue-Green deployment process should be automated within your CI/CD pipeline. This includes:





  • Triggering deployments to the idle environment.
  • Running automated tests against the idle environment.
  • Executing API calls to switch the load balancer.
  • Performing post-switch monitoring and automated rollback if necessary.





This level of automation is crucial for reliable and frequent deployments.