Overview
Have you ever experienced your app can't be accessed whenever you release a new version of your app?. In this series, we'll explore how to deploy updates with zero downtime, starting with one of the most reliable strategies — Blue-Green Deployment.
When we deploy an application on Cloud provider like AWS, Azure or GCP, we usually do like this:
- Shutting down the app
- compiled new version code
- Start app again
Looks like there's no problem with steps above until we noticed that our app is getting down or can't be accessed during the deployment process. we call this situation as downtime.
In this article we will learn how to prevent that using a one of deployment strategies called Blue-Green Deployment.
What it is Blue-Green Deployment?
Blue-Green Deployment is a strategy which we will switch the traffic from previous version instances(blue) to another identical new release instances(green) which are running on production environment. To achieve this goal, load balancer is playing crucial function to switching traffic
In this tutorial, we will use docker as a container manager and nginx as load balancer. We will deploy nextjs app and simulate it to achieve 0 downtime by using blue green deployment
Before we started, make sure you already install software bellow:
Notes: make sure you are familiar with linux environment
Install Docker and Nginx
open wsl and type bellow to install nginx
sudo apt install nginx
after nginx installed we will install docker,nodejs and git
sudo apt install docker nodejs git
after you installed the tools above, please create directory following image bellow
Setup Docker
We will use docker compose to run the app and nginx inside the container. so on Dockerfile, write this code
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]
Before Implement Blue Green Deployment
Before we start to setup the blue green deployment. i will show you the deployment before implement Blue Green deployment. i will write the docker-compose.yml like this.
services:
app:
build: ./app
container_name: app
ports:
- "5001:3000"
nginx:
image: nginx:latest
container_name: nginx-bluegreen
ports:
- "80:80"
volumes:
- ./nginx/nginx.conf:/etc/nginx/nginx.conf
- ./nginx/active_backend.conf:/etc/nginx/conf.d/active_backend.conf
and for nginx.conf
events {}
http {
server {
listen 80;
location / {
proxy_pass http://host.docker.internal:5001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}
}
and then i will write the deployment script on deploy.sh
#!/bin/bash
set -e
echo "================================="
echo "Starting Deployment..."
echo "================================="
echo ""
echo "[1/5] Building container..."
docker compose build app
echo ""
echo "[2/5] Stopping old container..."
docker compose stop app
echo ""
echo "[3/5] Removing old container..."
docker compose rm -f app
echo ""
echo "[4/5] Starting new container..."
docker compose up -d --no-deps app
echo ""
echo "[5/5] Running health check..."
sleep 5
STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost/api/health-check)
if [ "$STATUS" != "200" ]; then
echo "Deployment failed!"
exit 1
fi
echo ""
echo "================================="
echo "Deployment Success!"
echo "================================="
the i will running the container using docker compose
docker compose up
and now when i visit http://localhost the page will showing
now i will run ./deploy.sh to simulate the deployment process. when i refresh the page many times, i got the 502 bad gateway we called this as downtime
the downtime occur because i need to stop the container while i building new image version. so, the page will unavailable for some time. to prevent the downtime we need to create 2 app, one for active app and one for standby app. so when new release detected, we will rebuild the standby app, do the healthy check to make sure the app is healthy, then when app is detected as healthy app, we switch the traffic to new release app. here's the ilustration
Implement Blue Green
To Implement the Blue Green deployment, we will change our deployment mechanism like this:
- deploy 2 services called app_blue and app_green
- configure the nginx to route the traffic to app_blue
- write the current active app to "blue"
- new deployment detected
- rebuild app_green
- do health check the app_green
- if healthy switch traffic to app_green
- write the current active app to "green"
Create Healthy Check Route
Inside the nextjs app, we will create a route to indicates that the application is running well and healthy
open app/api/health-check/route.ts and write the code below:
export async function GET() {
return Response.json({
ok: true
})
}
run your app
npm run dev
then test the script by running
curl http://localhost:3000/api/health
it should return
{"ok":true}
after that, we will setup the docker compose to running 2 nextjs app and nginx as load balancer.
services:
app_blue:
build: ./app
container_name: app-blue
ports:
- "5001:3000"
app_green:
build: ./app
container_name: app-green
ports:
- "5002:3000"
nginx:
image: nginx:latest
container_name: nginx-bluegreen
ports:
- "80:80"
volumes:
- ./nginx/nginx.conf:/etc/nginx/nginx.conf
- ./nginx/active_backend.conf:/etc/nginx/conf.d/active_backend.conf
on code above, we created 2 services for apps that running on port 5001and 5002. and we created nginx services as a load balancer that will switch the traffic everytime when the new deployment found.
Setup Nginx
open nginx folder on the root folder and create nginx.conf
events {}
http {
include /etc/nginx/conf.d/active_backend.conf;
server {
listen 80;
location / {
proxy_pass http://active_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}
}
}
In nginx.conf, we forward all requests to the active backend defined in active_backend.conf, which is imported from the nginx folder.
on active_backend.conf we will write this configuration file
upstream active_backend {
server host.docker.internal:5001;
}
on active_backend.conf we created the upstream named active_backend. the active_backend is route all request to localhost:5001 that running under the docker container. so we must define host.docker.internal:5001
Store Current Active App
To store current active app. we will create new file called active_slot which is contain txt content
green
Deployment Script
We will create file deploy.sh to simulate our deployment script including :
- check the active app
- rebuild the standby app
- hit the health check of new release app
- switching the traffic to new release app
#!/bin/bash
set -e
ACTIVE=$(cat active_slot)
if [ "$ACTIVE" = "blue" ]; then
TARGET="green"
TARGET_PORT=5002
TARGET_SERVICE="app_green"
else
TARGET="blue"
TARGET_PORT=5001
TARGET_SERVICE="app_blue"
fi
echo "============================"
echo "Current Active : $ACTIVE"
echo "Deploy Target : $TARGET"
echo "============================"
echo ""
echo "[1/5] Rebuilding $TARGET_SERVICE..."
docker compose build $TARGET_SERVICE
docker compose up -d --no-deps $TARGET_SERVICE
echo ""
echo "[2/5] Waiting app startup..."
sleep 10
echo ""
echo "[3/5] Running health check..."
for i in {1..20}
do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:$TARGET_PORT/api/health-check)
if [ "$STATUS" = "200" ]; then
echo "Health check success!"
break
fi
echo "Retry $i..."
sleep 3
done
if [ "$STATUS" != "200" ]; then
echo "Health check failed!"
exit 1
fi
echo ""
echo "[4/5] Switching nginx traffic..."
cat > nginx/active_backend.conf <<EOF
upstream active_backend {
server host.docker.internal:$TARGET_PORT;
}
EOF
docker exec nginx-bluegreen nginx -s reload
echo "$TARGET" > active_slot
echo ""
echo "[5/5] Deployment success!"
echo ""
echo "Active slot now: $TARGET"
look at
docker compose build $TARGET_SERVICE
docker compose up -d --no-deps $TARGET_SERVICE
because we are running 2 services from same image we need to add
--no-deps
options to prevent the docker restart the active app while it rebuild the image. so the active app can still running.
edit page.tsx and run the deploy.sh. now the downtime is gone while we deploy new version in our app
