Blue-green deployment with containers in Docker - Deep Dive

Overview - Blue-green deployment with containers

What is it?

Blue-green deployment is a method to update software with minimal downtime by running two identical environments called blue and green. One environment serves live traffic while the other is idle or used for testing new versions. When the new version is ready, traffic switches from the old environment to the new one instantly. Using containers, this switch is fast and isolated, making deployments safer and smoother.

Why it matters

Without blue-green deployment, updating software can cause downtime or errors that affect users. This method reduces risks by allowing quick rollback and testing before switching live traffic. It improves user experience by avoiding interruptions and helps teams deploy updates confidently and frequently.

Where it fits

Learners should know basic container concepts and how to run containers with Docker. After this, they can learn about advanced deployment strategies, continuous integration/continuous deployment (CI/CD), and orchestration tools like Kubernetes.

Mental Model

Core Idea

Blue-green deployment runs two identical container environments side-by-side and switches user traffic instantly to update software without downtime.

Think of it like...

Imagine a theater with two identical stages: one stage is live with actors performing, while the other is set up with a new play. When the new play is ready, the audience is quickly moved to the new stage without interrupting the show.

┌───────────────┐       ┌───────────────┐
│   Blue Env    │──────▶│  Serving Live │
│ (Current App) │       │   Traffic     │
└───────────────┘       └───────────────┘
         ▲                       ▲
         │                       │
         │ Switch traffic        │
         │                       │
┌───────────────┐       ┌───────────────┐
│  Green Env    │       │  Idle / Ready │
│ (New Version) │       │  for Testing  │
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Containers and Images

Concept: Containers package applications and their dependencies into isolated units that run the same everywhere.

Docker containers are like lightweight boxes that hold your app and everything it needs to run. Images are the blueprints for these containers. You can start, stop, and remove containers easily without affecting your system.

Result

You can run your app in a container that behaves the same on any machine.

Understanding containers is essential because blue-green deployment relies on running multiple isolated app versions side-by-side.

2

Foundation

Basic Deployment with Docker Containers

Concept: Deploying an app means running its container and making it accessible to users.

You run a container from an image using 'docker run'. For example, 'docker run -d -p 80:80 myapp' starts your app on port 80. This container serves live traffic until stopped.

Result

Your app is live and users can access it through the exposed port.

Knowing how to deploy a single container is the first step before managing multiple environments for blue-green deployment.

3

Intermediate

Setting Up Blue and Green Environments

Concept: Create two separate container sets representing blue and green environments to run different app versions simultaneously.

Run two containers on different ports or networks: one for the current version (blue) and one for the new version (green). For example: 'docker run -d -p 8080:80 myapp:v1' (blue) 'docker run -d -p 8081:80 myapp:v2' (green) Users currently access blue on port 8080 while green is idle or tested on 8081.

Result

Two app versions run side-by-side without interfering, ready for traffic switch.

Separating environments allows safe testing and quick switching, which is the core of blue-green deployment.

4

Intermediate

Switching Traffic Between Environments

🤔Before reading on: do you think switching traffic means stopping the old container or just redirecting users? Commit to your answer.

Concept: Switching traffic means redirecting user requests from blue to green without downtime, often using a load balancer or proxy.

Use a reverse proxy like Nginx or a load balancer to route traffic. Initially, it sends requests to blue. When green is ready, update the proxy config to send traffic to green instead. This switch is instant and does not require stopping containers immediately.

Result

Users start accessing the new version without noticing downtime.

Traffic switching is about controlling user access smoothly, not about stopping containers abruptly.

5

Intermediate

Testing and Validating the Green Environment

🤔Before reading on: do you think green environment should be tested before switching traffic? Commit to yes or no.

Concept: The green environment must be fully tested before receiving live traffic to avoid errors.

Run tests against the green container on its port or network. Check functionality, performance, and stability. Only after passing tests do you switch traffic from blue to green.

Result

Confidence that the new version works correctly before users see it.

Testing green first prevents broken updates and improves reliability.

6

Advanced

Automating Blue-Green Deployment with Docker Compose

🤔Before reading on: do you think automation requires complex scripts or can be simple with Docker tools? Commit to your answer.

Concept: Docker Compose can define blue and green services and automate switching by updating configurations.

Create a docker-compose.yml with two services: blue and green, each with different image tags and ports. Use scripts or CI/CD pipelines to update the green service, test it, then switch a proxy service to route traffic to green. Example snippet: services: blue: image: myapp:v1 ports: - "8080:80" green: image: myapp:v2 ports: - "8081:80" proxy: image: nginx ports: - "80:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf Switching proxy config changes upstream from blue to green.

Result

Deployment becomes repeatable, less error-prone, and faster.

Automation reduces human error and speeds up blue-green deployment cycles.

7

Expert

Handling Data and State in Blue-Green Deployments

🤔Before reading on: do you think blue-green deployment automatically handles database changes safely? Commit to yes or no.

Concept: Managing data consistency and migrations is critical because containers are stateless but apps often rely on databases.

Plan database schema changes carefully. Use backward-compatible migrations so both blue and green versions can work with the same database. Avoid destructive changes during deployment. Sometimes use feature flags or separate databases to prevent conflicts. Rollback is easier if data is consistent.

Result

Deployments avoid data loss or corruption during version switches.

Understanding data handling prevents the most serious failures in blue-green deployments.

Under the Hood

Blue-green deployment works by running two full sets of containerized applications in parallel, each isolated by ports, networks, or hosts. A traffic router or load balancer directs user requests to one environment at a time. When switching, the router updates its configuration to point to the new environment instantly. Containers remain running during the switch, allowing quick rollback if needed. This isolation ensures no shared state conflicts during deployment.

Why designed this way?

It was designed to solve the problem of downtime and risky updates in production. Traditional deployments often stop the old version before starting the new one, causing outages. Blue-green deployment avoids this by preparing the new version fully before switching. Alternatives like rolling updates exist but can be complex and slower. Blue-green offers simplicity and safety at the cost of doubling resource usage temporarily.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│  User Traffic │──────▶│  Load Balancer│──────▶│ Blue Env (App)│
│               │       │ (Traffic Ctrl)│       │  Port 8080    │
└───────────────┘       └───────────────┘       └───────────────┘
                                   │
                                   │ Switch config
                                   ▼
                          ┌───────────────┐
                          │ Green Env     │
                          │ (New Version) │
                          │  Port 8081    │
                          └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does blue-green deployment eliminate the need for testing? Commit to yes or no.

Common Belief: Blue-green deployment means you don't need to test the new version because you can switch back anytime.

Reality: Testing is still essential before switching traffic to avoid exposing users to broken or unstable versions.

Why it matters: Skipping tests can cause users to experience bugs or crashes, damaging trust and requiring emergency rollbacks.

Quick: Do you think blue-green deployment always halves resource usage? Commit to yes or no.

Common Belief: Blue-green deployment reduces resource usage because only one environment runs at a time.

Reality: It actually doubles resource usage temporarily because both blue and green environments run simultaneously.

Why it matters: Underestimating resource needs can cause performance issues or extra costs during deployment.

Quick: Does switching traffic mean stopping the old environment immediately? Commit to yes or no.

Common Belief: Switching traffic requires stopping the old containers right away to avoid conflicts.

Reality: Old containers usually stay running for a short time to allow rollback and handle in-flight requests.

Why it matters: Stopping too early can cause errors or lost requests, harming user experience.

Quick: Is blue-green deployment always the best choice for every app? Commit to yes or no.

Common Belief: Blue-green deployment is the best deployment method for all applications.

Reality: It may not suit apps with complex state or very large resource constraints; other methods like canary or rolling updates might be better.

Why it matters: Choosing the wrong deployment strategy can cause unnecessary complexity or failures.

Expert Zone

1

Blue-green deployment requires careful network and port management to avoid conflicts and ensure smooth traffic switching.

2

Database migrations must be backward-compatible to allow both blue and green versions to run simultaneously without errors.

3

Rollback is not just switching traffic back; it may require cleaning up state or data changes introduced by the new version.

When NOT to use

Avoid blue-green deployment when resource constraints prevent running duplicate environments or when the application tightly couples state that cannot be easily shared. In such cases, consider rolling updates or canary deployments that update parts of the system gradually.

Production Patterns

In production, blue-green deployment is often combined with automated CI/CD pipelines, health checks, and monitoring. Traffic switching is managed by load balancers or service meshes. Teams use feature flags to control new features during deployment. Database migrations are scripted and tested separately to ensure smooth transitions.

Connections

Canary Deployment

Alternative deployment strategy with gradual traffic shifting

Understanding blue-green helps grasp canary deployments, which update small user segments progressively instead of all at once.

Load Balancing

Blue-green relies on load balancers to switch traffic between environments

Knowing how load balancers route traffic clarifies how blue-green deployment achieves instant environment switching.

Theater Stage Management

Both involve preparing a new setup while the current one runs live, then switching audiences

Recognizing this pattern in theater helps understand the importance of seamless transitions in software deployment.

Common Pitfalls

#1 Switching traffic before testing the green environment

Wrong approach:

Update proxy to green environment immediately after deployment without validation.

Correct approach:

Run tests on green environment first, then update proxy to switch traffic only after successful validation.

Root cause:

Misunderstanding that blue-green deployment replaces testing rather than complements it.

#2 Using the same ports for blue and green containers causing conflicts

Wrong approach:

docker run -d -p 80:80 myapp:v1

docker run -d -p 80:80 myapp:v2

Correct approach:

docker run -d -p 8080:80 myapp:v1

docker run -d -p 8081:80 myapp:v2

Root cause:

Not realizing that two containers cannot bind the same host port simultaneously.

#3 Stopping old containers immediately after switching traffic

Wrong approach:

After switching proxy, run 'docker stop' on blue containers right away.

Correct approach:

Keep blue containers running briefly to handle ongoing requests and allow quick rollback.

Root cause:

Assuming traffic switch means old environment is instantly obsolete.

Key Takeaways

Blue-green deployment runs two identical container environments to enable instant traffic switching with zero downtime.

It requires running both old and new versions simultaneously, which doubles resource usage temporarily but improves safety.

Traffic switching is managed by load balancers or proxies, not by stopping containers immediately.

Testing the new environment before switching traffic is essential to avoid exposing users to errors.

Handling data and database migrations carefully is critical to prevent failures during deployment.