[CD] 블루/그린 무중단 배포 구현하기 2편 (GitHub Actions/Shell Script)

🔗 [CD] 블루/그린 무중단 배포 구현하기 1편 (NGINX/Docker Compose)

이번 포스팅에서는 1편에서 작성한 도커 컴포즈 파일을 바탕으로 블루/그린 무중단 배포를 구현할 것이다.
 

GitHub Actions란?

깃헙 액션은 깃헙에서 제공하는 자동화 도구로, 빌드, 테스트, 배포 파이프라인을 자동화할 수 있다. 깃헙 액션은 특정 이벤트가 발생하면 액션을 자동으로 실행하게 되는데, 이를 활용하여 특정 브랜치에 코드가 push 되었을 때 어플리케이션을 배포할 수 있다. 이외에도 레포지토리에 이슈가 생성될 때마다 자동으로 적절한 라벨을 붙여주는 등의 워크플로우를 만들 수 있다.

workflow

워크플로우는 하나 이상의 작업을 실행하는 자동화된 프로세스다. `.github/workflows` 디렉토리에 YAML 파일로 작성하며 레포지토리에 이벤트가 발생하면 실행된다.

runner

러너는 워크플로우를 실행하는 서버로, 한 번에 하나의 작업을 수행한다.

🚨 동일한 러너를 사용하는 작업 내에서는 데이터를 공유할 수 있다. 하지만 환경변수 등을 활용하여 여러 작업 간에 데이터를 공유할 수도 있다.

job

작업은 워크플로우 내에서 실행되는 개별 작업이다. 작업은 병렬적으로 실행되는데 다른 작업이 선행되어야 하는 경우, `needs` 옵션을 활용하여 작업이 순차적으로 실행되도록 구현할 수 있다.

step

단계는 작업 내에서 실행되는 개별 액션을 의미한다.

action

액션은 일종의 사용자 어플리케이션이다. 직접 액션을 작성할 수도 있지만 깃허브의 마켓 플레이스에서 액션을 가져와 사용하는 등 외부 액션을 사용할 수도 있다.

event

이벤트는 워크플로우를 실행하는 트리거를 의미한다. 코드 푸시, PR 생성 등이 이벤트에 해당된다.

---

블루/그린 배포를 위한 워크플로우 작성하기

로컬에서 소스코드를 빌드하고, 원격 서버에서 빌드 결과물을 실행하는 등 수동으로 배포하는 방법도 존재한다. 하지만 이는 매우 번거로운 과정인데다가 개발자의 실수가 발생할 수 있어 일관된 배포를 보장할 수 없다. 따라서 깃헙 액션으로 배포 과정을 자동화하여 신속하고 일관된 배포를 제공해보자.

배포 과정을 자동화했을 때의 이점

• 신속한 배포 : 자동화된 배포 프로세스로 빠르게 배포할 수 있다.
• 일관된 배포 품질 : 개발자 실수를 줄이고 일관된 배포 환경을 사용함으로써 예측 가능하고 안정적인 배포를 보장한다.
• 자원 절약 : 반복적이고 번거로운 작업들을 자동화하여 개발자의 시간과 노력을 절약할 수 있다.

 

배포 워크플로우

위의 이미지는 배포 워크플로우를 다이어그램으로 나타낸 것이다. 특정 브랜치로 push 되었을 때 실행되며, build와 deploy 작업으로 구성되어 있다.

name: Blue/Green CD

on:
  push:
    paths: ["backend/**"]
    branches: ["dev"]

env:
  DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
  GITHUB_SHA: ${{ github.sha }}

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Generate .env file and SSL files
        run: |
          cd backend
          echo "${{ secrets.ENV_FILE }}" > .env
          echo "DOCKER_USERNAME=${{ secrets.DOCKER_USERNAME }}" >> .env
          echo "GITHUB_SHA=${{ github.sha }}" >> .env
          mkdir -p config/nginx/ssl/
          echo "${{ secrets.SSL_OPTIONS }}" > config/nginx/ssl/options-ssl-nginx.conf
          echo "${{ secrets.SSL_FULLCHAIN }}" > config/nginx/ssl/fullchain.pem
          echo "${{ secrets.SSL_PRIVKEY }}" > config/nginx/ssl/privkey.pem
          echo "${{ secrets.SSL_DHPARAMS }}" > config/nginx/ssl/ssl-dhparams.pem

      - name: Add Remote Host Key to known_hosts
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PUBLIC_KEY }}" >> ~/.ssh/known_hosts

      - name: Copy some files needed for Deployment to Remote Server
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT }}
          source: "backend/.env,backend/deploy.sh,backend/config,backend/compose.blue-deploy.yml,backend/compose.green-deploy.yml,backend/Dockerfile.nginx"
          target: "~/app/"
          overwrite: true

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_ACCESS_TOKEN }}

      - name: Build & Push Docker Images (Blue & Green)
        run: |
          cd backend
          docker-compose -f compose.blue-build.yml build
          docker-compose -f compose.green-build.yml build
          docker-compose -f compose.blue-build.yml push
          docker-compose -f compose.green-build.yml push

  deploy:
    needs: build
    runs-on: ubuntu-latest

    steps:
      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_ACCESS_TOKEN }}

      - name: Run a New Version of the application on Remote Server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT }}
          script: |
            cd ~/app/backend
            chmod +x deploy.sh
            source deploy.sh

---

build 작업 작성하기

빌드 작업은 도커 이미지를 빌드하고 도커 허브에 푸시하는 역할이다. 단계별로 하나씩 살펴보자.

 

Checkout code

체크아웃은 레포지토리의 특정 브랜치, 커밋 등을 가져오는 작업이다. 즉, 워크플로우가 실행될 때의 상태를 가져온다. 일반적으로 `actions/checkout` 액션을 이용한다.
 

Generate .env file and SSL files

깃헙 시크릿을 이용하여 env 파일과 ssl 파일을 생성하는 작업이다. 원격 서버에 어플리케이션을 배포하기 위해서는 환경변수들을 전달해줘야 한다. 하지만 env 파일은 레포지토리에 올라가면 안되는 민감한 정보들을 담고 있다. 따라서 깃헙 시크릿을 이용하여 env 파일을 생성해야 한다.
 

Add Remote Host Key to known_hosts

ssh로 원격 서버에 접속하기 위해서는 `/.ssh/known_hosts` 파일이 필요하다. 해당 파일은 클라이언트가 서버의 신뢰성을 확인하는 데 사용되며 원격 서버의 공개키를 저장한다.
 

Copy some files needed for Deployment to Remote Server

환경변수, 배포 스크립트 등 배포할 때 필요한 파일들을 원격 서버에 전달하는 작업이다.
 

Login to Docker Hub

다음 단계에서 도커 허브에 이미지를 푸시해야 하기 때문에 도커 허브에 로그인한다.
 

Build & Push Docker Images (Blue & Green)

도커 컴포즈 파일을 바탕으로 블루 버전, 그린 버전 이미지를 빌드한다. 이미지를 빌드한 후, 생성된 이미지를 도커 허브에 푸시한다. 추후에 원격 서버에서 푸시된 이미지를 가져와 실행하게 된다.

---

deploy 작업 작성하기

배포 작업은 도커 허브로부터 이미지를 가져와 컨테이너를 실행한다.

 

Login to Docker Hub

다음 단계에서 도커 허브에 접근하여 이미지를 가져와야 하므로 도커 허브에 로그인한다.
 

Run a New Version of the application on Remote Server

쉘 스크립트를 실행하여 새로운 버전의 어플리케이션을 배포하는 작업이다. `deploy.sh` 파일을 실행하기 위해서는 사전에 실행권한을 부여해줘야 한다.

---

블루/그린 배포 쉘 스크립트 작성하기

깃헙 액션의 배포 스크립트가 너무 길어져서 `deploy.sh`라는 별도의 파일로 분리했다. 위의 deploy 작업에서 해당 쉘 스크립트를 실행하여 블루/그린 배포를 수행한다.
 

서버에서 실행중인 버전 확인하기

도커 명령어를 이용하여 서버에서 어떤 버전이 실행 중인지 확인한다. 이름에 blue라는 문자열이 포함된 경우, 블루 버전이 실행중이므로 그린 버전에서 신규 버전의 어플리케이션을 띄워야 한다. 반대의 경우엔 블루 버전에서 신규 어플리케이션을 실행한다.

if sudo docker ps --filter "name=blue" --format '{{.ID}}' | grep -E .; then
  RUN_TARGET="green"
  STOP_TARGET="blue"
  WAS_RUN_PORT=3002
  WAS_STOP_PORT=3000
else
  RUN_TARGET="blue"
  STOP_TARGET="green"
  WAS_RUN_PORT=3000
  WAS_STOP_PORT=3002
fi

`RUN_TARGET`은 신규 버전이 실행되는 버전을, `STOP_TARGET`은 구버전이 실행되는 버전을 의미한다.
 

신규 어플리케이션 띄우기

앞에서 신규 어플리케이션을 어디서 띄워야 하는지 알아냈다. 이제 도커 명령어를 이용하여 컨테이너를 실행할 것이다.

DOCKER_COMPOSE_FILE="compose.$RUN_TARGET-deploy.yml"

sudo docker-compose -f "$DOCKER_COMPOSE_FILE" pull
sudo docker-compose -f "$DOCKER_COMPOSE_FILE" up -d

도커 컴포즈 파일을 이용하여 도커 허브로부터 이미지를 가져오고 컨테이너를 실행한다.

 

NGINX를 이용하여 트래픽 전환하기

신규 어플리케이션이 실행되고 나면 기존 버전으로 가던 트래픽을 신규 어플리케이션을 향하도록 수정해야 한다.

NGINX_ID=$(sudo docker ps --filter "name=nginx" --quiet)
NGINX_CONFIG="/etc/nginx/conf.d/default.conf"

sudo docker exec $NGINX_ID /bin/bash -c "sed -i 's/was-$STOP_TARGET:$WAS_STOP_PORT/was-$RUN_TARGET:$WAS_RUN_PORT/' $NGINX_CONFIG"
sudo docker exec $NGINX_ID /bin/bash -c "sed -i 's/signal-$STOP_TARGET:$((WAS_STOP_PORT + 1))/signal-$RUN_TARGET:$((WAS_RUN_PORT + 1))/' $NGINX_CONFIG"
sudo docker exec $NGINX_ID /bin/bash -c "nginx -s reload"

엔진엑스도 컨테이너에서 실행 중이기 때문에 이름에 nginx가 포함된 컨테이너의 아이디를 조회한다. 이제 `sudo docker exec`를 이용하여 엔진엑스 컨테이너의 설정파일을 수정한다.
 
만약 구버전이 블루 버전에서 실행중이라면 엔진엑스는 `was-blue:3000`과 `signal-blue:3001`로 프록시한다. 트래픽을 전환하기 위해 `sed -i`로 `was-blue:3000`을 `was-green:3002`, `signal-blue:3001`을 `signal-green:3003`로 치환하여 그린 버전으로 프록시하도록 변경한다. 마지막으로 수정된 설정파일을 반영하기 위해 엔진엑스를 리로드한다.

 

구버전의 어플리케이션 종료하기

이전 단계로 인해 트래픽이 신규 어플리케이션을 향하도록 변경되었다. 이제 더 이상 사용하지 않는 구버전의 어플리케이션을 종료하는 작업만 남았다.

STOP_CONTAINER_ID=$(sudo docker ps --filter "name=$STOP_TARGET" --quiet)
if [ -n "$STOP_CONTAINER_ID" ]; then
  sudo docker stop $STOP_CONTAINER_ID
  sudo docker rm $STOP_CONTAINER_ID
  sudo docker image prune -af
fi

도커 명령어를 이용하여 구버전의 컨테이너를 멈추고 삭제한다. 나는 디스크 공간 낭비를 막기 위해 사용하지 않는 이미지도 삭제해줬다.
 
도커 + 엔진엑스 + 깃헙 액션을 활용한 블루/그린 무중단 배포 완성이다!!

🔗 Blue/Green CD 워크플로우
🔗 deploy.sh

---

참고자료

• https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions