Blue-Green Deployment Using Docker

Blue-Green deployment using Docker is a release strategy where two identical environments are maintained: one active production environment and one standby environment. The new Docker container version is deployed to the standby environment, tested, and then traffic is switched to it with minimal downtime.

Simple Definition: Blue-Green deployment means running two production-like Docker environments. Blue serves live users, Green runs the new version. After validation, traffic moves from Blue to Green.

Why Blue-Green Deployment is Used

In production, direct deployments are risky. If the new version fails, users may face downtime, payment failures, login issues, or API errors. Blue-Green deployment reduces this risk by keeping the old version available while the new version is tested separately.

Current Version = Blue
New Version     = Green

Users -> Blue

Deploy Green
Test Green
Switch Traffic

Users -> Green
Blue kept for rollback

Real-Time Production Example

Assume an e-learning or interview preparation platform has these Docker services:

Nginx
API Gateway
Course Service
Interview Service
Payment Service
MySQL
Redis

You want to deploy a new version of payment-service. Instead of stopping the old container immediately, you deploy the new version as Green, test payment APIs, and then switch Nginx traffic to Green.

Blue-Green Architecture

                    Users
                      |
                    Nginx
                      |
        +-------------+-------------+
        |                           |
   Blue Environment            Green Environment
   payment:v1                  payment:v2
   currently live              new version

How It Works Step by Step

Step 1: Blue is Running

payment-blue:
  image: payment-service:v1
  port: 8081

Nginx routes production traffic to Blue.

Step 2: Deploy Green

payment-green:
  image: payment-service:v2
  port: 8082

Green runs the new version but does not receive user traffic yet.

Step 3: Test Green

curl http://localhost:8082/actuator/health
curl http://localhost:8082/api/payments/test

Validate health checks, logs, database connectivity, API response, payment gateway integration, and performance.

Step 4: Switch Traffic

Nginx upstream changes:

Before:
users -> payment-blue

After:
users -> payment-green

Step 5: Keep Blue for Rollback

If Green fails after release, quickly route traffic back to Blue.

Green Fails
   |
Switch Nginx Back
   |
Users -> Blue

Docker Compose Example

services:

  payment-blue:
    image: payment-service:v1
    container_name: payment-blue
    ports:
      - "8081:8080"
    environment:
      SPRING_PROFILES_ACTIVE: prod
      DB_URL: jdbc:mysql://mysql:3306/payment_db
    networks:
      - app-net

  payment-green:
    image: payment-service:v2
    container_name: payment-green
    ports:
      - "8082:8080"
    environment:
      SPRING_PROFILES_ACTIVE: prod
      DB_URL: jdbc:mysql://mysql:3306/payment_db
    networks:
      - app-net

  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    networks:
      - app-net

networks:
  app-net:
    driver: bridge

Nginx Routing Example

Route Traffic to Blue

upstream payment_service {
    server payment-blue:8080;
}

server {
    listen 80;

    location /api/payments/ {
        proxy_pass http://payment_service;
    }
}

Switch Traffic to Green

upstream payment_service {
    server payment-green:8080;
}

server {
    listen 80;

    location /api/payments/ {
        proxy_pass http://payment_service;
    }
}

Reload Nginx

docker exec nginx nginx -s reload

Blue-Green Deployment Flowchart

Build New Docker Image
          |
Deploy Green Environment
          |
Run Health Checks
          |
Run Smoke Tests
          |
Green Healthy?
     |              |
    No             Yes
     |              |
 Stop Green     Switch Traffic
                    |
              Monitor Production
                    |
              Failure Found?
              |           |
             Yes          No
              |            |
        Rollback Blue   Remove Old Blue Later

Production CI/CD Flow

Developer Pushes Code
      |
CI Pipeline Builds Docker Image
      |
Image Scan
      |
Push to Registry
      |
Deploy Green
      |
Run Smoke Tests
      |
Switch Load Balancer
      |
Monitor Logs and Metrics

Benefits of Blue-Green Deployment

Near zero downtime deployment
Fast rollback
Production-like testing before release
Reduced deployment risk
Better user experience

Challenges of Blue-Green Deployment

Requires double infrastructure temporarily
Database migration must be backward compatible
Traffic switching must be carefully managed
Session and cache handling can become complex

Database Migration Problem

The biggest risk in Blue-Green deployment is database compatibility. Blue and Green may run different application versions while sharing the same database.

Blue App v1  -> payment_db
Green App v2 -> payment_db

If Green changes the database schema in a way that breaks Blue, rollback becomes difficult.

Safe Database Migration Strategy

Step 1: Add new nullable columns
Step 2: Deploy app that supports old + new schema
Step 3: Backfill data
Step 4: Switch traffic
Step 5: Remove old columns later

Production Best Practices

Use immutable Docker image tags like payment-service:v1.0.3
Never use latest in production deployments
Run smoke tests before traffic switch
Keep rollback environment ready
Use health checks and monitoring
Make database migrations backward compatible
Monitor logs, latency, error rate, CPU, and memory after switch

Monitoring After Traffic Switch

Green Receives Traffic
      |
Monitor:
- HTTP 5xx errors
- API latency
- Payment failures
- Container restarts
- Memory usage
- Logs

Blue-Green vs Rolling vs Canary

Strategy	Best For	Rollback
Blue-Green	Critical releases	Very fast
Rolling	Standard releases	Moderate
Canary	Risk-controlled user rollout	Fast

Interview Answer

Blue-Green deployment using Docker is a production deployment strategy where two identical environments are maintained. The Blue environment serves current production traffic, while the Green environment runs the new Docker container version.

After deploying and testing Green, traffic is switched from Blue to Green using a load balancer or reverse proxy such as Nginx. If any issue occurs, rollback is performed quickly by routing traffic back to Blue.

This strategy is widely used for high-availability systems because it provides near zero downtime, safer releases, and fast rollback capability.

Quick Summary

Concept	Explanation
Blue	Current production version
Green	New version being deployed
Traffic Switch	Load balancer routes users to Green
Rollback	Traffic returns to Blue
Main Benefit	Near zero downtime deployment

Useful Internal Links

Final Conclusion

Blue-Green deployment using Docker is one of the safest production release strategies for containerized applications. It allows teams to deploy new versions without immediately impacting users and provides a fast rollback path if something goes wrong.

Blue-Green deployment using Docker