Blue-green deployment with containers in Docker - Step-by-Step Execution

Process Flow - Blue-green deployment with containers

Start with Blue environment live

↓

Deploy new version to Green environment

↓

Test Green environment

↓

Switch traffic

↓

Green becomes live

↓

Blue becomes idle, ready for next update

This flow shows how traffic switches between two container environments (Blue and Green) to deploy updates safely.

Execution Sample

Docker

docker run -d --name blue_app myapp:v1
# Blue is live

docker run -d --name green_app myapp:v2
# Green deployed

docker stop blue_app
# Stop Blue

docker network connect proxy green_app
# Switch traffic to Green

This sequence deploys version 1 on Blue, then version 2 on Green, then switches traffic by stopping Blue and connecting Green to the proxy.

Process Table

Step	Action	Blue container state	Green container state	Traffic routing	Result
1	Run Blue container with v1	Running v1	Not running	Traffic to Blue	Blue app live serving users
2	Run Green container with v2	Running v1	Running v2	Traffic to Blue	Green ready but no traffic
3	Test Green container	Running v1	Running v2	Traffic to Blue	Green verified healthy
4	Stop Blue container	Stopped	Running v2	Traffic to Blue (stopped)	Blue stopped, no traffic served
5	Connect Green to proxy	Stopped	Running v2	Traffic to Green	Green app live serving users
6	Blue idle for next update	Stopped	Running v2	Traffic to Green	Deployment complete, ready for next cycle

💡 Blue stopped and traffic switched to Green, deployment finished successfully

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Blue container	Not running	Running v1	Running v1	Running v1	Stopped	Stopped	Stopped
Green container	Not running	Not running	Running v2	Running v2	Running v2	Running v2	Running v2
Traffic routing	None	To Blue	To Blue	To Blue	To Blue (stopped)	To Green	To Green

Key Moments - 3 Insights

Why do we keep the Green container running but not serving traffic initially?

Green runs with the new version to allow testing without affecting live users. This is shown in step 2 and 3 where Green is running but traffic is still to Blue.

What happens if the Green environment fails testing?

Traffic stays on Blue, and Green can be fixed or rolled back. This is implied in the decision after step 3 where failure leads to no traffic switch.

Why do we stop the Blue container before switching traffic to Green?

Stopping Blue ensures no conflicting traffic or resource usage. Step 4 shows Blue stopped before traffic is switched in step 5.

Visual Quiz - 3 Questions

Look at the execution table, what is the state of the Blue container at step 3?

A Not running

B Stopped

C Running v1

D Running v2

💡 Hint

Check the 'Blue container state' column at step 3 in the execution table.

At which step does traffic switch from Blue to Green?

A Step 5

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'Traffic routing' column to see when traffic moves to Green.

If we did not stop Blue before switching traffic, what would the execution table show at step 5?

A Blue stopped, traffic to Green

B Blue running, traffic to Blue and Green simultaneously

C Blue running, traffic to Green only

D Blue stopped, traffic to Blue

💡 Hint

Think about container states and traffic routing if Blue remains running at step 5.

Concept Snapshot

Blue-green deployment uses two container sets: Blue (live) and Green (new).
Deploy new version to Green while Blue serves users.
Test Green, then switch traffic to Green.
Stop Blue to avoid conflicts.
Green becomes live; Blue idle for next update.
This ensures zero downtime and easy rollback.

Full Transcript

Blue-green deployment with containers means running two versions of an app in parallel. First, the Blue environment runs the current live version. Then, the new version is deployed to the Green environment without affecting users. After testing Green to confirm it works well, traffic is switched from Blue to Green by stopping Blue and routing users to Green. This switch happens smoothly to avoid downtime. Blue then stays idle, ready for the next update cycle. This method helps keep apps running without interruption and allows quick rollback if needed.