[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":87,"_72":88,"_35":89},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":55,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71},"id",68,"title","Production Deployment Patterns","slug","docker-part-18-deployment","excerpt","Rolling updates, blue-green, zero-downtime","## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| **Difficulty** | 🟠 Advanced |\n| **Prerequisites** | Part 15 (Dependencies), Part 17 (CI/CD) |\n| **Patterns** | Rolling, Blue-Green, Canary |\n| **Time Investment** | 26 minutes read + 90 minutes practice |\n| **Payoff** | Zero-downtime deployments, confident rollbacks |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter this article, you'll be able to:\n\n1. **Implement rolling updates** with zero downtime\n2. **Execute blue-green deployments** for instant rollbacks\n3. **Run canary deployments** to test with real traffic\n4. **Handle rollbacks** quickly and safely\n5. **Manage database migrations** during deployments\n\n---\n\n## 🔥 Production Story: The Friday Afternoon Deployment\n\n**The Setup**: 4:30 PM Friday. \"Quick hotfix, just push it.\" No testing, direct `docker compose up -d`.\n\n**What Happened**:\n```bash\n$ docker compose up -d\nRecreating api_1...\n# 100% of traffic goes to new container\n# New container fails health check\n# 30 seconds of 502 errors before old container comes back\n```\n\n**The Damage**:\n- 30 seconds of complete outage\n- 1,000+ failed requests\n- Angry customers over the weekend\n\n**The Root Cause**: No deployment strategy. `docker compose up -d` stops old container before new one is ready.\n\n**The Fix**:\n```yaml\nservices:\n api:\n deploy:\n update_config:\n order: start-first # Start new BEFORE stopping old\n failure_action: rollback\n parallelism: 1\n delay: 10s\n```\n\n**Result**: New deployments start the new container, wait for it to be healthy, then stop the old one. Zero downtime.\n\n---\n\n## 🧠 Mental Model: Deployment Strategies\n\n```\n┌─────────────────────────────────────────────────────────────────┐\n│ DEPLOYMENT STRATEGIES │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ ROLLING UPDATE (Default, safest) │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ v1 ████████████████████ │ │\n│ │ v2 ████████████████████ │ │\n│ │ ↑ start new ↑ stop old │ │\n│ │ start-first: new healthy before old stops │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n│ BLUE-GREEN (Instant switch) │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ Blue (v1) ████████████████ │ │\n│ │ Green (v2) ████████████████████████████ │ │\n│ │ ↑ switch LB │ │\n│ │ Both running, traffic switches instantly │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n│ CANARY (Gradual rollout) │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ v1 ████████████████ (90%) │ │\n│ │ v2 ██ (10%) ████ (25%) ████████████ (100%) │ │\n│ │ ↑ test with few ↑ increase ↑ full rollout │ │\n│ │ Gradually shift traffic if metrics OK │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n│ RECREATE (Downtime, simple) │\n│ ┌─────────────────────────────────────────────────────────┐ │\n│ │ v1 ████████████████ │ │\n│ │ (downtime) │ │\n│ │ v2 ████████████████████ │ │\n│ │ ↑ stop all ↑ start all │ │\n│ │ Simple but has downtime │ │\n│ └─────────────────────────────────────────────────────────┘ │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🔬 Deep Dive\n\n### 1. Rolling Updates with Docker Compose\n\n**Basic Rolling Update**:\n\n```yaml\n# docker-compose.yml\nservices:\n api:\n image: myapp:${VERSION:-latest}\n deploy:\n replicas: 3\n update_config:\n parallelism: 1 # Update 1 container at a time\n delay: 10s # Wait 10s between updates\n order: start-first # Start new before stopping old\n failure_action: rollback\n rollback_config:\n parallelism: 1\n delay: 5s\n healthcheck:\n test: curl -f http://localhost:8080/health\n interval: 10s\n timeout: 5s\n retries: 3\n start_period: 30s\n```\n\n**Deployment Script**:\n\n```bash\n#!/bin/bash\n# deploy-rolling.sh\n\nset -e\n\nVERSION=$1\nif [ -z \"$VERSION\" ]; then\n echo \"Usage: $0 \"\n exit 1\nfi\n\nexport VERSION\n\necho \"Deploying version: $VERSION\"\n\n# Pull new image first\ndocker compose pull api\n\n# Rolling update\ndocker compose up -d --no-recreate --scale api=3 api\n\n# Wait for health checks\necho \"Waiting for containers to be healthy...\"\nfor i in {1..30}; do\n HEALTHY=$(docker compose ps --format json | jq -r 'select(.Health == \"healthy\")' | wc -l)\n if [ \"$HEALTHY\" -ge 3 ]; then\n echo \"All containers healthy!\"\n break\n fi\n echo \"Healthy: $HEALTHY/3\"\n sleep 5\ndone\n\n# Verify deployment\ndocker compose ps\n```\n\n**Manual Rolling Update** (without Swarm):\n\n```bash\n#!/bin/bash\n# manual-rolling-update.sh\n\nVERSION=$1\nSERVICE=api\n\n# Get current container count\nCURRENT_COUNT=$(docker compose ps -q $SERVICE | wc -l)\n\necho \"Scaling up with new version...\"\nVERSION=$VERSION docker compose up -d --no-deps --scale $SERVICE=$((CURRENT_COUNT + 1)) --no-recreate $SERVICE\n\necho \"Waiting for new container to be healthy...\"\nsleep 30\n\necho \"Removing old containers one by one...\"\nOLD_CONTAINERS=$(docker compose ps -q $SERVICE | head -n $CURRENT_COUNT)\nfor CONTAINER in $OLD_CONTAINERS; do\n echo \"Stopping $CONTAINER...\"\n docker stop $CONTAINER\n docker rm $CONTAINER\n sleep 10\ndone\n\necho \"Deployment complete\"\ndocker compose ps\n```\n\n---\n\n### 2. Blue-Green Deployment\n\n**Architecture**:\n\n```\n ┌──────────────┐\n │ Nginx/LB │\n └──────┬───────┘\n │\n ┌────────────┴────────────┐\n │ │\n ┌─────┴─────┐ ┌─────┴─────┐\n │ Blue │ │ Green │\n │ (live) │ │ (new) │\n │ port 80 │ │ port 8080 │\n └───────────┘ └───────────┘\n```\n\n**Compose Configuration**:\n\n```yaml\n# docker-compose.blue-green.yml\n\nservices:\n nginx:\n image: nginx:alpine\n ports:\n - \"80:80\"\n volumes:\n - ./nginx.conf:/etc/nginx/nginx.conf:ro\n depends_on:\n - blue\n - green\n networks:\n - frontend\n\n blue:\n image: myapp:${BLUE_VERSION:-latest}\n environment:\n - COLOR=blue\n networks:\n - frontend\n - backend\n deploy:\n replicas: 2\n\n green:\n image: myapp:${GREEN_VERSION:-latest}\n environment:\n - COLOR=green\n networks:\n - frontend\n - backend\n deploy:\n replicas: 2\n\nnetworks:\n frontend:\n backend:\n```\n\n**Nginx Configuration**:\n\n```nginx\n# nginx.conf\nupstream backend {\n # Active color controlled by env or config reload\n server blue:8080;\n # server green:8080;\n}\n\nserver {\n listen 80;\n\n location / {\n proxy_pass http://backend;\n proxy_set_header Host $host;\n proxy_set_header X-Real-IP $remote_addr;\n }\n\n location /health {\n return 200 'OK';\n }\n}\n```\n\n**Blue-Green Deployment Script**:\n\n```bash\n#!/bin/bash\n# deploy-blue-green.sh\n\nset -e\n\nVERSION=$1\nCURRENT_COLOR=$(cat .current-color 2>/dev/null || echo \"blue\")\n\nif [ \"$CURRENT_COLOR\" = \"blue\" ]; then\n NEW_COLOR=\"green\"\n export GREEN_VERSION=$VERSION\nelse\n NEW_COLOR=\"blue\"\n export BLUE_VERSION=$VERSION\nfi\n\necho \"Current: $CURRENT_COLOR, Deploying to: $NEW_COLOR\"\n\n# 1. Deploy new version to inactive color\necho \"Starting $NEW_COLOR with version $VERSION...\"\ndocker compose -f docker-compose.blue-green.yml up -d $NEW_COLOR\n\n# 2. Wait for new deployment to be healthy\necho \"Waiting for $NEW_COLOR to be healthy...\"\nfor i in {1..30}; do\n if docker compose -f docker-compose.blue-green.yml exec $NEW_COLOR \\\n curl -sf http://localhost:8080/health > /dev/null 2>&1; then\n echo \"$NEW_COLOR is healthy!\"\n break\n fi\n echo \"Waiting... ($i/30)\"\n sleep 5\ndone\n\n# 3. Run smoke tests against new color\necho \"Running smoke tests...\"\ndocker compose -f docker-compose.blue-green.yml exec $NEW_COLOR \\\n npm run test:smoke || {\n echo \"Smoke tests failed! Aborting.\"\n exit 1\n}\n\n# 4. Switch traffic (update nginx config)\necho \"Switching traffic to $NEW_COLOR...\"\nsed -i \"s/server $CURRENT_COLOR/# server $CURRENT_COLOR/g\" nginx.conf\nsed -i \"s/# server $NEW_COLOR/server $NEW_COLOR/g\" nginx.conf\ndocker compose -f docker-compose.blue-green.yml exec nginx nginx -s reload\n\n# 5. Save current color\necho $NEW_COLOR > .current-color\n\n# 6. Optionally stop old color (keep for quick rollback)\necho \"Deployment complete. Old ($CURRENT_COLOR) still running for rollback.\"\necho \"Run './stop-old.sh' to remove old deployment.\"\n```\n\n**Instant Rollback**:\n\n```bash\n#!/bin/bash\n# rollback-blue-green.sh\n\nCURRENT_COLOR=$(cat .current-color)\nif [ \"$CURRENT_COLOR\" = \"blue\" ]; then\n ROLLBACK_COLOR=\"green\"\nelse\n ROLLBACK_COLOR=\"blue\"\nfi\n\necho \"Rolling back from $CURRENT_COLOR to $ROLLBACK_COLOR...\"\n\n# Just switch nginx upstream\nsed -i \"s/server $CURRENT_COLOR/# server $CURRENT_COLOR/g\" nginx.conf\nsed -i \"s/# server $ROLLBACK_COLOR/server $ROLLBACK_COLOR/g\" nginx.conf\ndocker compose -f docker-compose.blue-green.yml exec nginx nginx -s reload\n\necho $ROLLBACK_COLOR > .current-color\necho \"Rolled back to $ROLLBACK_COLOR\"\n```\n\n---\n\n### 3. Canary Deployment\n\n**Nginx with Weighted Traffic**:\n\n```nginx\n# nginx.conf for canary\nupstream backend {\n # 90% to stable\n server stable:8080 weight=9;\n # 10% to canary\n server canary:8080 weight=1;\n}\n\nserver {\n listen 80;\n\n location / {\n proxy_pass http://backend;\n }\n}\n```\n\n**Compose for Canary**:\n\n```yaml\n# docker-compose.canary.yml\n\nservices:\n nginx:\n image: nginx:alpine\n ports:\n - \"80:80\"\n volumes:\n - ./nginx-canary.conf:/etc/nginx/nginx.conf:ro\n networks:\n - frontend\n\n stable:\n image: myapp:${STABLE_VERSION:-latest}\n deploy:\n replicas: 9\n networks:\n - frontend\n - backend\n\n canary:\n image: myapp:${CANARY_VERSION:-latest}\n deploy:\n replicas: 1\n networks:\n - frontend\n - backend\n\nnetworks:\n frontend:\n backend:\n```\n\n**Canary Deployment Script**:\n\n```bash\n#!/bin/bash\n# deploy-canary.sh\n\nset -e\n\nVERSION=$1\nCANARY_PERCENT=${2:-10}\n\nexport CANARY_VERSION=$VERSION\n\necho \"Starting canary deployment: $VERSION ($CANARY_PERCENT%)\"\n\n# 1. Deploy canary\ndocker compose -f docker-compose.canary.yml up -d canary\n\n# 2. Wait for healthy\necho \"Waiting for canary to be healthy...\"\nsleep 30\n\n# 3. Update nginx weights\nSTABLE_WEIGHT=$((100 - CANARY_PERCENT))\ncat > nginx-canary.conf << EOF\nupstream backend {\n server stable:8080 weight=$STABLE_WEIGHT;\n server canary:8080 weight=$CANARY_PERCENT;\n}\nserver {\n listen 80;\n location / { proxy_pass http://backend; }\n}\nEOF\n\ndocker compose -f docker-compose.canary.yml exec nginx nginx -s reload\n\necho \"Canary deployed with $CANARY_PERCENT% traffic\"\necho \"Monitor metrics. Run './promote-canary.sh' or './rollback-canary.sh'\"\n```\n\n**Promote or Rollback**:\n\n```bash\n#!/bin/bash\n# promote-canary.sh\n\nCANARY_VERSION=$(docker inspect canary --format '{{.Config.Image}}' | cut -d: -f2)\n\necho \"Promoting canary version: $CANARY_VERSION\"\n\n# Update stable to canary version\nexport STABLE_VERSION=$CANARY_VERSION\ndocker compose -f docker-compose.canary.yml up -d stable\n\n# Remove canary\ndocker compose -f docker-compose.canary.yml stop canary\ndocker compose -f docker-compose.canary.yml rm -f canary\n\n# Reset nginx to stable only\ncat > nginx-canary.conf << EOF\nupstream backend {\n server stable:8080;\n}\nserver {\n listen 80;\n location / { proxy_pass http://backend; }\n}\nEOF\n\ndocker compose -f docker-compose.canary.yml exec nginx nginx -s reload\n\necho \"Canary promoted to stable\"\n```\n\n---\n\n### 4. Handling Database Migrations\n\n**Migration Strategies**:\n\n```\n┌────────────────────────────────────────────────────────────┐\n│ MIGRATION PATTERNS │\n├────────────────────────────────────────────────────────────┤\n│ │\n│ 1. BACKWARDS COMPATIBLE (preferred) │\n│ ┌─────────────────────────────────────────────────┐ │\n│ │ v1: Uses column 'name' │ │\n│ │ Migration: Add column 'full_name', copy data │ │\n│ │ v2: Uses 'full_name', ignores 'name' │ │\n│ │ Later: Drop 'name' column │ │\n│ └─────────────────────────────────────────────────┘ │\n│ │\n│ 2. EXPAND-CONTRACT │\n│ ┌─────────────────────────────────────────────────┐ │\n│ │ Expand: Add new column/table │ │\n│ │ Deploy: v2 writes to both old and new │ │\n│ │ Migrate: Backfill old data │ │\n│ │ Contract: v3 only uses new, drop old │ │\n│ └─────────────────────────────────────────────────┘ │\n│ │\n│ 3. FEATURE FLAGS │\n│ ┌─────────────────────────────────────────────────┐ │\n│ │ Deploy code with flag off │ │\n│ │ Run migration │ │\n│ │ Enable flag for small % of users │ │\n│ │ Roll out to 100% │ │\n│ └─────────────────────────────────────────────────┘ │\n│ │\n└────────────────────────────────────────────────────────────┘\n```\n\n**Migration Service in Compose**:\n\n```yaml\nservices:\n migrate:\n image: myapp:${VERSION}\n command: npm run migrate\n environment:\n - DATABASE_URL=${DATABASE_URL}\n depends_on:\n db:\n condition: service_healthy\n restart: \"no\"\n profiles:\n - migrate\n\n api:\n image: myapp:${VERSION}\n depends_on:\n db:\n condition: service_healthy\n```\n\n**Deployment with Migration**:\n\n```bash\n#!/bin/bash\n# deploy-with-migration.sh\n\nVERSION=$1\nexport VERSION\n\n# 1. Run migrations first\necho \"Running migrations...\"\ndocker compose --profile migrate run --rm migrate\n\n# Check migration success\nif [ $? -ne 0 ]; then\n echo \"Migration failed! Aborting deployment.\"\n exit 1\nfi\n\n# 2. Deploy new version\necho \"Deploying application...\"\ndocker compose up -d api\n\necho \"Deployment complete\"\n```\n\n**Reversible Migration Example**:\n\n```sql\n-- migrations/001_add_user_email.sql\n-- Up\nALTER TABLE users ADD COLUMN email VARCHAR(255);\nCREATE INDEX idx_users_email ON users(email);\n\n-- Down\nDROP INDEX idx_users_email;\nALTER TABLE users DROP COLUMN email;\n```\n\n---\n\n### 5. Health Checks and Readiness\n\n**Liveness vs Readiness**:\n\n```yaml\nservices:\n api:\n healthcheck:\n # This is liveness - is the process running?\n test: curl -f http://localhost:8080/health/live\n interval: 10s\n timeout: 5s\n retries: 3\n```\n\n**Application Health Endpoints**:\n\n```javascript\n// Express.js health endpoints\n\n// Liveness: Is the process alive?\napp.get('/health/live', (req, res) => {\n res.json({ status: 'alive' });\n});\n\n// Readiness: Can we serve traffic?\napp.get('/health/ready', async (req, res) => {\n const checks = {\n database: await checkDatabase(),\n redis: await checkRedis(),\n dependencies: await checkExternalServices()\n };\n\n const allHealthy = Object.values(checks).every(c => c.healthy);\n\n res.status(allHealthy ? 200 : 503).json({\n status: allHealthy ? 'ready' : 'not ready',\n checks\n });\n});\n\n// Full health: Detailed status\napp.get('/health', async (req, res) => {\n const checks = {\n database: await checkDatabase(),\n redis: await checkRedis(),\n memory: checkMemory(),\n uptime: process.uptime()\n };\n\n res.json({\n status: 'healthy',\n version: process.env.VERSION,\n checks\n });\n});\n```\n\n**Load Balancer Health Check**:\n\n```nginx\n# nginx.conf\nupstream backend {\n server api1:8080;\n server api2:8080;\n server api3:8080;\n}\n\nserver {\n location / {\n proxy_pass http://backend;\n proxy_next_upstream error timeout http_503;\n proxy_connect_timeout 5s;\n }\n}\n```\n\n---\n\n### 6. Zero-Downtime Deployment Checklist\n\n```yaml\n# Complete production-ready compose\n\nservices:\n api:\n image: ${REGISTRY}/api:${VERSION}\n\n # Health check for readiness\n healthcheck:\n test: [\"CMD\", \"curl\", \"-f\", \"http://localhost:8080/health/ready\"]\n interval: 10s\n timeout: 5s\n retries: 3\n start_period: 30s\n\n # Graceful shutdown\n stop_grace_period: 30s\n\n # Rolling update config\n deploy:\n replicas: 3\n update_config:\n parallelism: 1\n delay: 10s\n order: start-first\n failure_action: rollback\n rollback_config:\n parallelism: 1\n delay: 5s\n resources:\n limits:\n memory: 512M\n\n # Connection draining\n labels:\n - \"traefik.http.services.api.loadbalancer.healthcheck.interval=10s\"\n - \"traefik.http.services.api.loadbalancer.healthcheck.timeout=5s\"\n\n networks:\n - frontend\n - backend\n```\n\n**Deployment Checklist Script**:\n\n```bash\n#!/bin/bash\n# deploy-checklist.sh\n\nVERSION=$1\nREGISTRY=${REGISTRY:-docker.io}\nIMAGE=$REGISTRY/myapp:$VERSION\n\necho \"=== Pre-Deployment Checklist ===\"\n\n# 1. Verify image exists\necho \"Checking image exists...\"\ndocker manifest inspect $IMAGE > /dev/null 2>&1 || {\n echo \"❌ Image not found: $IMAGE\"\n exit 1\n}\necho \"✅ Image verified\"\n\n# 2. Check current health\necho \"Checking current deployment health...\"\nUNHEALTHY=$(docker compose ps --format json | jq -r 'select(.Health != \"healthy\")' | wc -l)\nif [ \"$UNHEALTHY\" -gt 0 ]; then\n echo \"⚠️ Warning: $UNHEALTHY unhealthy containers\"\n read -p \"Continue anyway? (y/n) \" -n 1 -r\n echo\n if [[ ! $REPLY =~ ^[Yy]$ ]]; then\n exit 1\n fi\nfi\necho \"✅ Current deployment healthy\"\n\n# 3. Run migrations\necho \"Running migrations...\"\ndocker compose --profile migrate run --rm migrate || {\n echo \"❌ Migration failed\"\n exit 1\n}\necho \"✅ Migrations complete\"\n\n# 4. Deploy with rolling update\necho \"Starting rolling update...\"\nexport VERSION\ndocker compose up -d --no-deps api\n\n# 5. Wait for rollout\necho \"Waiting for rollout to complete...\"\nfor i in {1..60}; do\n READY=$(docker compose ps --format json | jq -r 'select(.Health == \"healthy\")' | wc -l)\n TOTAL=$(docker compose ps -q api | wc -l)\n\n if [ \"$READY\" -eq \"$TOTAL\" ] && [ \"$TOTAL\" -gt 0 ]; then\n echo \"✅ All containers healthy ($READY/$TOTAL)\"\n break\n fi\n\n echo \"Progress: $READY/$TOTAL healthy\"\n sleep 5\ndone\n\n# 6. Verify new version\necho \"Verifying deployed version...\"\nDEPLOYED=$(docker compose exec api cat /app/version.txt 2>/dev/null || echo \"unknown\")\nif [ \"$DEPLOYED\" != \"$VERSION\" ]; then\n echo \"⚠️ Warning: Version mismatch. Expected $VERSION, got $DEPLOYED\"\nfi\n\necho \"=== Deployment Complete ===\"\ndocker compose ps\n```\n\n---\n\n### 7. Rollback Strategies\n\n**Quick Rollback Script**:\n\n```bash\n#!/bin/bash\n# rollback.sh\n\nPREVIOUS_VERSION=$(cat .previous-version 2>/dev/null)\n\nif [ -z \"$PREVIOUS_VERSION\" ]; then\n echo \"No previous version found. Manual rollback required.\"\n echo \"Available versions:\"\n docker images myapp --format \"{{.Tag}}\" | head -10\n exit 1\nfi\n\necho \"Rolling back to version: $PREVIOUS_VERSION\"\n\nexport VERSION=$PREVIOUS_VERSION\ndocker compose up -d api\n\n# Swap version files\nmv .current-version .failed-version\nmv .previous-version .current-version\n\necho \"Rollback complete\"\n```\n\n**Automated Rollback on Failure**:\n\n```bash\n#!/bin/bash\n# deploy-with-auto-rollback.sh\n\nVERSION=$1\nPREVIOUS_VERSION=$(cat .current-version 2>/dev/null || echo \"unknown\")\n\nexport VERSION\n\n# Save current version\necho $PREVIOUS_VERSION > .previous-version\n\n# Deploy\ndocker compose up -d api\n\n# Wait and verify\nsleep 30\n\n# Check health\nHEALTHY=$(docker compose ps --format json | jq -r 'select(.Health == \"healthy\")' | wc -l)\nREQUIRED=3\n\nif [ \"$HEALTHY\" -lt \"$REQUIRED\" ]; then\n echo \"Deployment failed! Only $HEALTHY/$REQUIRED healthy. Rolling back...\"\n\n export VERSION=$PREVIOUS_VERSION\n docker compose up -d api\n\n echo \"Rolled back to $PREVIOUS_VERSION\"\n exit 1\nfi\n\n# Save new version as current\necho $VERSION > .current-version\necho \"Deployment successful\"\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Stop-First Update Order\n\n```yaml\n# ❌ Wrong: Stops old before starting new (downtime!)\ndeploy:\n update_config:\n order: stop-first\n\n# ✅ Right: Start new before stopping old\ndeploy:\n update_config:\n order: start-first\n```\n\n### Mistake 2: No Health Check in Deployment\n\n```yaml\n# ❌ Wrong: No way to know if new container is ready\nservices:\n api:\n image: myapp:latest\n # No healthcheck!\n\n# ✅ Right: Health check ensures readiness\nservices:\n api:\n image: myapp:latest\n healthcheck:\n test: curl -f http://localhost:8080/health/ready\n start_period: 30s\n```\n\n### Mistake 3: Breaking Database Changes\n\n```sql\n-- ❌ Wrong: Breaks v1 while deploying v2\nALTER TABLE users RENAME COLUMN name TO full_name;\n\n-- ✅ Right: Backwards compatible migration\n-- Step 1 (with v1 running):\nALTER TABLE users ADD COLUMN full_name VARCHAR(255);\nUPDATE users SET full_name = name;\n\n-- Step 2 (deploy v2 that uses full_name)\n-- Step 3 (later, when v1 is gone):\nALTER TABLE users DROP COLUMN name;\n```\n\n### Mistake 4: No Rollback Plan\n\n```bash\n# ❌ Wrong: Deploy and pray\ndocker compose up -d\n\n# ✅ Right: Always have rollback ready\necho $CURRENT_VERSION > .previous-version\ndocker compose up -d\n# Keep old image available for quick rollback\n```\n\n### Mistake 5: All-at-Once Updates\n\n```yaml\n# ❌ Wrong: Updates all containers simultaneously\ndeploy:\n update_config:\n parallelism: 0 # All at once\n\n# ✅ Right: One at a time with delay\ndeploy:\n update_config:\n parallelism: 1\n delay: 10s\n```\n\n---\n\n## 🐛 Debug This\n\nDeployment completes but application is down:\n\n```bash\n$ docker compose up -d api\n[+] Running 3/3\n ✔ Container api-1 Started\n ✔ Container api-2 Started\n ✔ Container api-3 Started\n\n$ curl http://localhost/health\ncurl: (7) Failed to connect\n```\n\nAll containers show as \"Started\" but the service is unreachable. What's happening?\n\n

Click to reveal analysis

\n\n**Investigation**:\n\n```bash\n# Check container health\n$ docker compose ps\nNAME STATUS PORTS\napi-1 Up 10s (health: starting) 8080/tcp\napi-2 Up 8s (health: starting) 8080/tcp\napi-3 Up 6s (health: starting) 8080/tcp\n\n# Check logs\n$ docker compose logs api\napi-1 | Starting server...\napi-1 | Connecting to database...\napi-1 | Error: Connection refused to db:5432\n```\n\n**Root Cause**: Database isn't ready, but `depends_on` wasn't using `service_healthy` condition.\n\n**Fix**:\n\n```yaml\nservices:\n api:\n depends_on:\n db:\n condition: service_healthy # Wait for DB to be ready\n\n db:\n healthcheck:\n test: pg_isready -U postgres\n interval: 5s\n timeout: 5s\n retries: 5\n```\n\n**Additional Fix**: Add retry logic in application for resilience:\n\n```javascript\nconst connectWithRetry = async (maxRetries = 10) => {\n for (let i = 0; i < maxRetries; i++) {\n try {\n await db.connect();\n return;\n } catch (err) {\n console.log(`DB connection attempt ${i + 1}/${maxRetries} failed`);\n await sleep(2000);\n }\n }\n throw new Error('Could not connect to database');\n};\n```\n

\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Rolling Update\nImplement a rolling update that:\n- Updates 1 container at a time\n- Waits for health check before continuing\n- Rolls back on failure\n\n### Exercise 2: Blue-Green Deployment\nSet up blue-green with:\n- Two parallel environments\n- Nginx switching between them\n- Instant rollback capability\n\n### Exercise 3: Canary Deployment\nImplement canary that:\n- Sends 10% of traffic to new version\n- Gradually increases to 100%\n- Can rollback instantly\n\n### Exercise 4: Database Migration\nHandle a schema change that:\n- Renames a column\n- Works during rolling update\n- Allows rollback\n\n### Exercise 5: Complete Pipeline\nCreate an end-to-end deployment:\n- Build and test in CI\n- Deploy to staging automatically\n- Deploy to production with approval\n- Automatic rollback on failure\n\n---\n\n## 🎤 Interview Questions\n\n### Q1: Explain the difference between rolling update, blue-green, and canary deployments.\n\n**Answer**:\n\n| Strategy | Traffic Pattern | Rollback Speed | Resource Cost |\n|----------|----------------|----------------|---------------|\n| Rolling | Gradual, container by container | Slow (redeploy) | Low |\n| Blue-Green | Instant switch | Instant | High (2x) |\n| Canary | Gradual % increase | Fast | Medium |\n\n**Rolling Update**:\n- Updates containers one at a time\n- Always some serving traffic\n- Rollback requires redeployment\n- Best for: Standard deployments\n\n**Blue-Green**:\n- Two complete environments\n- Traffic switches instantly\n- Instant rollback (switch back)\n- Best for: Critical systems, instant rollback needs\n\n**Canary**:\n- New version gets small traffic %\n- Monitor, then increase\n- Quick rollback (send 0% to canary)\n- Best for: Testing in production, risky changes\n\n---\n\n### Q2: How do you handle database migrations in a zero-downtime deployment?\n\n**Answer**: Use backwards-compatible migrations with expand-contract pattern:\n\n**Phase 1 - Expand** (add new, keep old):\n```sql\n-- Add new column without removing old\nALTER TABLE users ADD COLUMN full_name VARCHAR(255);\n-- Backfill\nUPDATE users SET full_name = name;\n-- Create trigger to keep in sync\nCREATE TRIGGER sync_names ...\n```\n\n**Phase 2 - Deploy** (use both):\n```javascript\n// v2 code writes to both columns\nuser.full_name = value;\nuser.name = value; // Keep old updated\n```\n\n**Phase 3 - Contract** (remove old):\n```sql\n-- Only after all instances are v2\nALTER TABLE users DROP COLUMN name;\n```\n\n**Key principles**:\n1. Never rename columns directly\n2. Never drop columns until all code is updated\n3. Always be able to roll back\n\n---\n\n### Q3: What's the `order: start-first` configuration and why is it important?\n\n**Answer**: `order: start-first` means Docker starts the new container BEFORE stopping the old one.\n\n**Without start-first** (stop-first):\n```\n1. Stop old container\n2. (Service unavailable!)\n3. Start new container\n4. Wait for health check\n5. Service available again\n```\n\n**With start-first**:\n```\n1. Start new container\n2. Wait for health check\n3. (Old still serving traffic)\n4. Stop old container\n5. Zero downtime!\n```\n\n```yaml\ndeploy:\n update_config:\n order: start-first # Critical for zero-downtime\n failure_action: rollback\n```\n\n**Requirement**: Need enough resources to run both old and new simultaneously. For a 3-replica service, briefly need capacity for 4.\n\n---\n\n### Q4: How do you implement automatic rollback on deployment failure?\n\n**Answer**: Combine health checks with failure actions:\n\n```yaml\nservices:\n api:\n healthcheck:\n test: curl -f http://localhost:8080/health/ready\n interval: 10s\n retries: 3\n start_period: 30s\n\n deploy:\n update_config:\n failure_action: rollback # Auto-rollback on health failure\n monitor: 60s # Watch for 60s after deploy\n rollback_config:\n parallelism: 1\n delay: 5s\n```\n\n**For Compose (non-Swarm)**:\n\n```bash\n#!/bin/bash\n# Deploy with timeout rollback\n\nTIMEOUT=120\nVERSION=$1\nPREV_VERSION=$(cat .version)\n\nexport VERSION\ndocker compose up -d api\n\n# Monitor health\nfor i in $(seq 1 $((TIMEOUT/10))); do\n HEALTHY=$(docker compose ps --format json | jq 'select(.Health==\"healthy\")' | wc -l)\n TOTAL=$(docker compose ps -q api | wc -l)\n\n if [ \"$HEALTHY\" -eq \"$TOTAL\" ]; then\n echo $VERSION > .version\n echo \"Deployment successful\"\n exit 0\n fi\n sleep 10\ndone\n\n# Timeout - rollback\necho \"Health check timeout. Rolling back...\"\nexport VERSION=$PREV_VERSION\ndocker compose up -d api\nexit 1\n```\n\n---\n\n### Q5: How do you handle a scenario where you need to deploy a breaking change?\n\n**Answer**: Use feature flags and gradual rollout:\n\n**Step 1**: Deploy code with feature flag OFF\n```javascript\nif (featureFlags.isEnabled('new-payment-system')) {\n useNewPaymentSystem();\n} else {\n useOldPaymentSystem();\n}\n```\n\n**Step 2**: Run database migrations\n```sql\n-- Add new tables/columns while old code still works\nCREATE TABLE new_payments (...);\n```\n\n**Step 3**: Enable feature for internal users\n```javascript\nfeatureFlags.enable('new-payment-system', { users: ['internal'] });\n```\n\n**Step 4**: Gradual rollout\n```javascript\nfeatureFlags.enable('new-payment-system', { percentage: 10 });\n// Monitor...\nfeatureFlags.enable('new-payment-system', { percentage: 50 });\n// Monitor...\nfeatureFlags.enable('new-payment-system', { percentage: 100 });\n```\n\n**Step 5**: Remove old code and flag (later release)\n```javascript\n// Remove feature flag check\nuseNewPaymentSystem();\n```\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Deployment Strategies\n\n| Strategy | Use When |\n|----------|----------|\n| Rolling | Standard deployments, most cases |\n| Blue-Green | Need instant rollback |\n| Canary | Testing risky changes |\n\n### Zero-Downtime Requirements\n1. `order: start-first` in deploy config\n2. Health checks with `start_period`\n3. Graceful shutdown handling\n4. Backwards-compatible migrations\n\n### Rollback Essentials\n- Always save previous version\n- Keep old images available\n- Automate rollback on failure\n- Test rollback procedure\n\n---\n\n## 📋 Quick Reference\n\n```yaml\n# Zero-downtime deploy config\ndeploy:\n update_config:\n order: start-first\n parallelism: 1\n delay: 10s\n failure_action: rollback\n\nhealthcheck:\n test: curl -f http://localhost:8080/health\n interval: 10s\n retries: 3\n start_period: 30s\n\nstop_grace_period: 30s\n```\n\n```bash\n# Quick rollback\nexport VERSION=$(cat .previous-version)\ndocker compose up -d api\n```\n\n---\n\n## 📅 Review Schedule\n\n- **Day 1**: Implement rolling update with health checks\n- **Day 3**: Set up blue-green deployment\n- **Day 7**: Practice database migrations\n- **Day 14**: Implement canary with monitoring\n- **Day 30**: Full deployment pipeline with rollback\n\n---\n\n## 📚 Series Navigation\n\n- **Previous**: [Part 17 - CI/CD Pipeline Patterns](/articles/docker-part-17-cicd)\n- **Next**: [Part 19 - Monitoring & Troubleshooting Production](/articles/docker-part-19-monitoring)\n- **Index**: [Docker Compendium Series](/series/docker-compendium)","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:25.567077Z","createdAt","2026-06-10T07:19:25.567664Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",16,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Devops","readingTime","seriesId","seriesOrder",18,"author",{"_31":55,"_94":57,"_95":96,"_97":98,"_99":-5,"_100":-5,"_101":-5,"_102":-5,"_103":-5},"category",{"_31":90,"_72":59,"_35":91,"_75":92,"_93":-5},"tags",[78,79,80],"series",{"_31":55,"_72":73,"_35":74,"_75":76,"_77":23},"name","Docker Compendium: From Practitioner to Expert","docker-compendium","description","Master Docker internals, optimization patterns, and production best practices. For developers who use Docker daily but want deeper understanding of what's happening under the hood. Not a beginner series - we assume you can write Dockerfiles and use docker-compose. Learn what namespaces and cgroups really do, why your builds are slow, how to debug containers that crash, and how to run Docker in production like a pro.\n","isActive",{"_31":87,"_72":88,"_35":89},{"_31":84,"_72":85,"_35":86},{"_31":81,"_72":82,"_35":83},216,"Production","production",213,"Docker","docker",246,"Deployment","deployment",7,"devops","Category for Devops","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]