Vengala Vinay

Having 9+ Years of Experience in Software Development

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

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

Understanding Blue-Green Deployments for WooCommerce

Blue-Green deployment is a strategy to minimize downtime and risk by 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 in the idle environment, traffic is switched over. This allows for instant rollback if issues arise.

For a WooCommerce application hosted on OVH, this typically involves managing two distinct sets of web servers, application servers (PHP-FPM), and potentially database replicas. The key challenge is orchestrating the traffic switch and ensuring data consistency across both environments, especially with a transactional system like WooCommerce.

Infrastructure Setup on OVH

We’ll assume a typical OVH setup leveraging their Public Cloud instances. This could involve:

  • Load Balancer: An OVH Load Balancer (or a self-managed HAProxy/Nginx instance) to distribute traffic and manage the switch.
  • Web Servers: Two identical sets of Nginx or Apache servers.
  • Application Servers: Two identical sets of PHP-FPM instances.
  • Database: A primary database and potentially read replicas. For zero-downtime writes during a switch, a more advanced strategy involving database replication or a shared, highly available database cluster is necessary. For simplicity in this example, we’ll focus on a single primary database and manage potential write interruptions during the switch.
  • Shared Storage: For WooCommerce uploads (wp-content/uploads), a shared filesystem (like NFS or a distributed file system) is crucial so both environments access the same media. Alternatively, synchronizing uploads between environments is required.

Orchestrating the Traffic Switch with HAProxy

HAProxy is an excellent choice for managing the traffic switch due to its robust health checks and flexible configuration. We’ll configure it to point to either the “Blue” or “Green” backend servers.

First, let’s define our backend server groups in HAProxy’s configuration file (e.g., /etc/haproxy/haproxy.cfg).

HAProxy Configuration Snippet

frontend http_frontend
    bind *:80
    mode http
    default_backend bk_woocommerce

backend bk_woocommerce_blue
    mode http
    balance roundrobin
    option httpchk GET /healthz.php
    server blue_web1 192.168.1.10:80 check
    server blue_web2 192.168.1.11:80 check

backend bk_woocommerce_green
    mode http
    balance roundrobin
    option httpchk GET /healthz.php
    server green_web1 192.168.2.10:80 check
    server green_web2 192.168.2.11:80 check

# Initially, all traffic goes to Blue
backend bk_woocommerce
    mode http
    default_backend bk_woocommerce_blue

We’ve introduced a meta-backend bk_woocommerce that defaults to bk_woocommerce_blue. This allows us to easily switch the active environment by changing the default_backend directive.

Health Check Endpoint

A simple healthz.php file on each web server is essential for HAProxy’s health checks. This script should perform basic checks (e.g., database connectivity, essential WordPress files exist) and return a 200 OK status if healthy.

<?php
// healthz.php
// Basic check for WooCommerce health

// Attempt to include wp-load.php to check WordPress core
if (file_exists('../../../wp-load.php')) {
    require_once('../../../wp-load.php');

    // Check database connection
    global $wpdb;
    if ($wpdb->ping() === false) {
        header('HTTP/1.1 503 Service Unavailable');
        echo 'Database connection failed.';
        exit;
    }

    // Add more checks as needed (e.g., essential plugin status, file permissions)

    header('HTTP/1.1 200 OK');
    echo 'OK';
    exit;
} else {
    header('HTTP/1.1 503 Service Unavailable');
    echo 'wp-load.php not found.';
    exit;
}
?>

Deployment Workflow

The deployment process involves deploying to the inactive environment, testing, and then switching traffic.

Step 1: Prepare the Green Environment

Ensure the Green environment servers (green_web1, green_web2, etc.) are running the same base configuration as the Blue environment but are not receiving live traffic. This means they are registered in HAProxy but are currently in the “standby” state.

Step 2: Deploy New Code to Green

Use your CI/CD pipeline (e.g., Jenkins, GitLab CI, GitHub Actions) to deploy the new WooCommerce code, themes, and plugins to the Green environment’s web and application servers. This typically involves:

  • Cloning the repository.
  • Running Composer install/update.
  • Syncing files to the web server (e.g., using rsync, SCP, or a deployment tool).
  • Applying database migrations (if any).

Important: Database migrations require careful handling. If migrations modify the database schema in a way that is incompatible with the old code, you cannot simply switch back. Strategies include:

  • Backward-compatible migrations: Ensure migrations can be applied and then rolled back without breaking the old code.
  • Multi-step deployments: Deploy code that can handle both old and new schema, then apply migration, then switch traffic.

Step 3: Database Synchronization/Migration

This is the most critical part for transactional systems. If your Green environment uses a separate database instance, you need to ensure it’s up-to-date with the Blue environment’s primary database. Options include:

  • Replication: Set up replication from the Blue database to the Green database. This is ideal for read-heavy workloads but requires careful handling of write operations during the switch.
  • Downtime for writes: For a brief period, stop all writes to the Blue database, wait for replication to catch up to Green, then switch traffic. This introduces a small write downtime.
  • Shared Database Cluster: Use a highly available database cluster (e.g., Galera Cluster, Aurora) accessible by both environments. This is the most complex but offers true zero-downtime writes.

For this example, let’s assume we’re using replication and will tolerate a brief write pause.

Step 4: Run Smoke Tests on Green

Before switching traffic, run automated smoke tests against the Green environment. These tests should verify critical user flows:

  • Homepage loads correctly.
  • Product pages load correctly.
  • Add to cart functionality works.
  • Checkout process (at least to the payment gateway step) works.
  • Admin login and basic operations.

You can direct these tests to the Green servers directly via their IP addresses or by temporarily modifying your local hosts file to point a domain to the Green environment’s IP.

Step 5: The Traffic Switch

This is the moment of truth. The switch is performed by reconfiguring HAProxy. This can be done dynamically without restarting HAProxy.

First, pause writes to the Blue database if not using a shared cluster or advanced replication. This is the window for potential write downtime.

Then, dynamically update HAProxy’s configuration. You can achieve this by:

# Option 1: Reload HAProxy configuration (requires root/sudo)
sudo systemctl reload haproxy

# Option 2: Use HAProxy Runtime API (more advanced, allows dynamic changes without reload)
# This requires enabling the stats socket in haproxy.cfg:
# listen stats
#     bind *:9000
#     mode http
#     stats enable
#     stats uri /stats
#     stats admin if TRUE
#     stats auth user:password

# Then use socat or curl to send commands:
echo "set backend bk_woocommerce bk_woocommerce_green" | sudo socat stdio /run/haproxy/admin.sock
# Or if using HTTP API:
# curl -s -X POST --data-binary "set backend bk_woocommerce bk_woocommerce_green" http://localhost:9000/v2/config/set/backend

After the HAProxy configuration is updated, new incoming connections will be routed to the Green environment. Existing connections to the Blue environment will continue to complete.

Step 6: Post-Switch Verification

Immediately after the switch, perform a quick round of manual checks on the live site. Monitor logs for any new errors. If everything appears stable, resume database writes (if paused) and consider the deployment successful.

Step 7: Rollback Procedure

If critical issues are detected in the Green environment after the switch, rolling back is as simple as reversing the HAProxy configuration change:

# Reload HAProxy to point back to Blue
sudo systemctl reload haproxy

# Or using the Runtime API:
echo "set backend bk_woocommerce bk_woocommerce_blue" | sudo socat stdio /run/haproxy/admin.sock

This instantly redirects traffic back to the stable Blue environment. The Blue environment remains untouched and ready to serve.

Handling WooCommerce Uploads

WooCommerce relies heavily on the wp-content/uploads directory for product images and other media. This directory must be accessible and consistent across both Blue and Green environments.

  • Shared Network Filesystem (NFS): Mount an NFS share on all web servers in both Blue and Green environments. This is the simplest approach for consistency. Ensure the NFS server itself is highly available.
  • Object Storage (S3-compatible): Use a plugin to store uploads in an S3-compatible object storage service (like OVH’s Object Storage). This decouples storage from the servers entirely.
  • Synchronization: Implement a robust synchronization mechanism (e.g., rsync, Syncthing) to copy new uploads from the active environment to the inactive one. This adds complexity and potential for lag.

For zero-downtime deployments, a shared filesystem or object storage is strongly recommended.

Automating the Pipeline

The entire process can be automated using a CI/CD tool. A typical pipeline might look like this:

  • Trigger: On merge to the main branch or a tag creation.
  • Build: Build Docker images (if using containers) or package application code.
  • Deploy to Green: Push code to Green environment servers.
  • Database Migration (if applicable): Apply migrations to the Green database replica or staging DB.
  • Automated Testing: Run comprehensive smoke and integration tests against the Green environment.
  • Manual Approval: A manual gate for final sign-off before the traffic switch.
  • Traffic Switch: Execute HAProxy configuration update.
  • Post-Deployment Monitoring: Automated checks and alerts.
  • Rollback Trigger: Automated rollback on critical test failures or alerts.

This automation significantly reduces the human error associated with manual deployments and ensures consistency.

Considerations for WooCommerce Specifics

WooCommerce has several components that need attention:

  • Cron Jobs: WordPress/WooCommerce cron jobs (wp-cron.php) should ideally be handled by a dedicated system or a server-level cron job that triggers wp-cli. Ensure this is configured identically for both Blue and Green environments, and that only the *active* environment’s cron jobs are running to avoid duplicate actions (e.g., double order processing). A common approach is to disable wp-cron.php and use server cron jobs, ensuring they only run on the active environment.
  • Caching: Ensure your caching strategy (e.g., Varnish, Redis, object cache plugins) is compatible with blue-green. Cache invalidation might be necessary after a switch, or ensure caches are cleared/primed for the new environment.
  • External Services: Payment gateways, shipping APIs, etc., should be accessible from both environments. Ensure API keys and configurations are consistent.
  • Session Management: If using external session storage (e.g., Redis), ensure it’s accessible by both environments.

Conclusion

Implementing zero-downtime blue-green deployments for WooCommerce on OVH requires careful planning of infrastructure, traffic management, and data consistency. By leveraging tools like HAProxy for traffic switching and establishing robust deployment and testing pipelines, you can achieve highly available and resilient WooCommerce applications, minimizing user impact during updates.