Blue-green deployment with containers in Docker - Time & Space Complexity
We want to understand how the time to switch between blue and green environments grows as the number of containers increases.
How does deployment time change when we add more containers in blue-green deployment?
Analyze the time complexity of the following Docker commands for blue-green deployment.
# Stop old containers (blue)
docker stop blue_container_1 blue_container_2 ... blue_container_n
# Start new containers (green)
docker run --name green_container_1 image
...
docker run --name green_container_n image
# Switch traffic to green environment
# (e.g., update load balancer or DNS)
This snippet stops old containers, starts new ones, and switches traffic to the new environment.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Starting and stopping each container one by one.
- How many times: Once per container, so n times for n containers.
As the number of containers increases, the time to stop and start containers grows proportionally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 20 operations (10 stops + 10 starts) |
| 100 | About 200 operations |
| 1000 | About 2000 operations |
Pattern observation: The operations grow linearly as the number of containers increases.
Time Complexity: O(n)
This means the deployment time grows directly in proportion to the number of containers.
[X] Wrong: "Starting all containers happens instantly regardless of how many there are."
[OK] Correct: Each container start takes time, so more containers mean more total time.
Understanding how deployment time scales helps you design smoother releases and shows you think about real system behavior.
"What if we started containers in parallel instead of one by one? How would the time complexity change?"
Practice
blue-green deployment when using containers?Solution
Step 1: Understand blue-green deployment concept
Blue-green deployment uses two identical environments (blue and green) to switch traffic smoothly.Step 2: Identify the main goal
The main goal is to reduce downtime by switching user traffic from one environment to another without interruption.Final Answer:
To reduce downtime by switching traffic between two identical environments -> Option AQuick Check:
Blue-green deployment = reduce downtime [OK]
- Confusing blue-green with scaling containers
- Thinking it creates backups automatically
- Assuming it monitors resource usage
Solution
Step 1: Identify command to create and start container
Thedocker runcommand creates and starts a container from an image.Step 2: Match command to green environment container creation
docker run -d --name green_container myapp:latestruns the container detached with the name green_container.Final Answer:
docker run -d --name green_container myapp:latest -> Option BQuick Check:
Run command creates container [OK]
- Using 'docker build' which builds images, not containers
- Using 'docker push' which uploads images to registry
- Using 'docker stop' which stops containers
docker stop blue_container docker start green_container
Solution
Step 1: Analyze the commands
docker stop blue_containerstops the blue container.docker start green_containerstarts the green container.Step 2: Understand traffic switch effect
Stopping blue and starting green means traffic moves from blue to green environment.Final Answer:
The blue environment stops, and the green environment starts serving traffic -> Option CQuick Check:
Stop blue + start green = traffic switch [OK]
- Assuming both run simultaneously after stop command
- Confusing start and stop commands
- Thinking no change happens without redeploy
docker stop blue_container and docker start green_container, but users still reach the blue environment. What is the most likely cause?Solution
Step 1: Check container states
Stopping blue_container and starting green_container should switch environments if containers run properly.Step 2: Identify traffic routing cause
If users still reach blue, likely the load balancer or proxy still routes traffic to blue environment IP or port.Final Answer:
The load balancer or proxy is still routing traffic to the blue environment -> Option AQuick Check:
Traffic routing depends on load balancer config [OK]
- Assuming container start/stop alone switches traffic
- Ignoring load balancer or proxy configuration
- Thinking Docker daemon status causes routing issues
Solution
Step 1: Understand Docker Compose blue-green setup
Using two Compose files or service names (blue and green) allows running both environments side by side.Step 2: Switch traffic by updating reverse proxy
Updating the reverse proxy or load balancer to point to the active service switches traffic without downtime.Final Answer:
Use two Compose files with different service names and update the reverse proxy to point to the active service -> Option DQuick Check:
Two services + proxy update = blue-green switch [OK]
- Using same service names causing conflicts
- Not updating proxy or load balancer
- Deploying only one service without switching
Ready to prove it?
Pass the test and this pattern moves unknown
