GitHub + GitLab + Docker + Nginx Blue-Green Deployment

This document describes the CI/CD architecture for a microservices platform where:

• Source code is hosted in GitHub
• GitLab CI/CD builds and deploys containers
• Docker images are stored in GitLab Registry
• Docker Compose deploys services
• Blue-Green deployment using Nginx ensures zero downtime
• Dynamic pipelines build only changed microservices
• GitLab keeps only the latest 5 container images

This approach is commonly used to reduce pipeline time and infrastructure cost.

*Note

The services name used in this document are dummy service names. Since the document is generic and similar approach can be adapted for other CICD deployments irrespective of inclusion/exclusion of Microservices from the application architecture.

The pipeline includes manual approval gates to ensure controlled deployments.

Large systems may contain 20–100 microservices.

Instead of rebuilding everything, the pipeline:

1. Detects changed services
2. Generates jobs dynamically
3. Builds only those services

If only:

auth-service
booking-service

changed, then pipeline creates jobs:

build-auth-service
deploy-auth-service

build-booking-service
deploy-booking-service

Other services are skipped.

This reduces pipeline time drastically.

Each microservice is containerized and pushed to:

GitLab Container Registry

To reduce storage cost:

Keep latest 5 images  Delete older images automatically

Example:

auth-service
├── v1
├── v2
├── v3
├── v4
└── v5

Older images are removed automatically.

Production environment contains two identical environments.

1. Blue is currently serving traffic
2. New version deploys to Green
3. Health checks run
4. Nginx switches traffic
5. Blue becomes standby

Nginx acts as the traffic router.

upstream backend {
  server green:8080;
}

Switching traffic:

nginx -s reload

Result:

Zero downtime release

After deployment:

/health  /ready  /status

are validated.

Switch traffic to Green

Rollback to Blue

Users never experience downtime.

Instead of restarting the entire stack:

docker compose up -d auth-service

Only updated services restart.

Benefits:

• Faster deployment
• Less service disruption
• Lower resource usage

Each service maintains separate log directories.

Example:

logs/
  auth-service/
    auth-service-v1.log
    auth-service-v2.log
  booking-service/
    booking-service-v3.log

Benefits:

• Easy debugging
• Service isolation
• Faster incident resolution

Adapted project structure:

platform-root/

services/
│
├── auth-service/
│
├── src
│
├── Dockerfile
│
└── service.yml
│
├── booking-service/
│
├── src
│
├── Dockerfile
│
└── service.yml
│
└── payment-service/

docker/
  docker-compose.dev.yml
  docker-compose.test.yml
  docker-compose.blue.yml
  docker-compose.green.yml

nginx/
  nginx.conf
  upstream.conf

logs/
  auth-service/
  booking-service/
  payment-service/

scripts/
  detect-changed-services.sh
  generate-dynamic-pipeline.sh
  deploy-service.sh
  nginx-switch.sh
  cleanup-old-images.sh

.gitlab-ci.yml
README.md

Only changed services build.

Old images automatically removed.

Blue-Green strategy with Nginx.

Approval gates prevent accidental releases.

Per-service logging.

Supports 50+ microservices easily.

Typical full release:

~10 minutes