무중단 배포 실습 - 블루그린 전략

앞서 실습 레포지토리와 환경 셋팅을 진행했습니다.

못 보신 분들이 계시다면 먼저 이 포스팅을 보고, 무중단 배포 실습을 진행해주세요.

 

https://programmer-may.tistory.com/213

무중단 배포 실습 기본 셋팅 (Github Actions, Nginx 활용)

 

블루 그린 전략

블루 그린 전략(Blue-Green Deployment)은 두 개의 동일한 환경(블루 환경과 그린 환경)을 사용하여 배포하는 방법입니다. 블루 환경에서 현재 운영 중인 버전을 실행하고, 그린 환경에서 새로운 버전을 배포합니다. 새로운 버전이 준비되면 트래픽을 블루 환경에서 모두 한번에 그린 환경으로 전환하여 배포를 완료합니다.

배포가 완료된 후 기존 구 버전이 있던 환경은 다음 배포를 위해 재사용하거나 제거할 수 있습니다.

 

bluegreen_before 브랜치

블루그린 무중단 배포 전략 도입 전 환경을 구축합니다. cd-bluegreen.yml 파일을 통해 JAR 파일을 업로드하고, 이전 프로세스를 죽이고 JAR 파일을 8081포트에서 실행합니다. 이 과정에서 다운 타임이 발생하게 됩니다.

 

bluegreen_after 브랜치

블루그린 전략 도입하여 무중단 배포를 실행합니다. cd-bluegreen.yml 파일을 통해 deploy.sh 파일을 실행합니다.

 

deploy.sh 셋팅

먼저 Termius 켜서 EC2 에 원격접속을 진행합니다.

해당 디렉토리에 배포용 쉘 스크립트를 만듭니다. 경로의 글자가 틀리지 않게 조심해주세요.

$ sudo nano /home/ubuntu/cicd/bluegreen/deploy.sh

 

해당 스크립트를 복붙해서 넣어줍니다.

여기서 중요한 것이 있습니다.

이곳에서 zeroDownTimeDeployment 대한 jar 파일 명을 변경해줘야할 수 있습니다.

프로젝트를 직접 생성해서 따라하시는 분이나 rootProject.name 이 다른 사람은 빌드했을 때 다른 이름의 jar 파일이 생기기 때문에 이부분을 맞게 바꿔줘야합니다.

 

 

본인의 프로젝트의 settings.gradle 의 rootProject.name 값을 zeroDownTimeDeployment 대신 넣어 줍니다.
뒤에 -*.jar 는 그대로 유지해야합니다. 빌드시 rootProject.name -버전-SNAPSHOT.jar 로 jar 파일이 만들어지기 때문입니다.

 

#!/bin/bash

# 현재 실행 중인 Spring Boot 애플리케이션 포트 식별
CURRENT_PORT=$(sudo ss -tulnp | grep java | awk '{print $5}' | grep -o '[0-9]*$')
echo "Current port is: $CURRENT_PORT"

# 기본 포트 설정
PORT1=8081
PORT2=8082
NEW_PORT=0

# 현재 포트에 따라 새 포트 결정
if [ -z "$CURRENT_PORT" ]; then
    # 실행 중인 포트가 없으면 기본 포트 사용
    NEW_PORT=$PORT1
elif [ "$CURRENT_PORT" -eq "$PORT1" ]; then
    NEW_PORT=$PORT2
else
    NEW_PORT=$PORT1
fi

echo "Deploying new application on port: $NEW_PORT"

# 기존의 app.jar 파일을 old_build 디렉토리로 이동
TIMESTAMP=$(date +"%Y%m%d%H%M%S")
if [ -f /home/ubuntu/cicd/app.jar ]; then
    mv /home/ubuntu/cicd/app.jar /home/ubuntu/cicd/old_build/$TIMESTAMP.jar
fi

# 새로 배포된 .jar 파일을 app.jar로 이름 변경
NEW_JAR=$(ls /home/ubuntu/cicd/zeroDownTimeDeployment-*.jar | head -n 1)
mv $NEW_JAR /home/ubuntu/cicd/app.jar

# 새로 배포된 app.jar 파일 실행
sudo chmod +x /home/ubuntu/cicd/app.jar
sudo nohup java -jar -Dserver.port=$NEW_PORT /home/ubuntu/cicd/app.jar > /home/ubuntu/console.log 2>&1 &

sleep 10
# 새 애플리케이션이 정상적으로 실행되었는지 확인
CHECK_URL=http://localhost:$NEW_PORT/actuator/health
RETRY_COUNT=0
MAX_RETRY=10

until $(curl --output /dev/null --silent --head --fail $CHECK_URL); do
    sleep 5
    if [ ${RETRY_COUNT} -eq ${MAX_RETRY} ]; then
        echo "New application failed to start. Deployment aborted."
        
        # 헬스 체크 실패 시 $NEW_PORT에서 실행 중인 프로세스를 강제 종료
        NEW_PID=$(lsof -t -i:$NEW_PORT)
        if [ -n "$NEW_PID" ]; then
            echo "Terminating process on port $NEW_PORT with PID $NEW_PID"
            sudo kill -9 $NEW_PID
        fi

        exit 1
    fi
    RETRY_COUNT=$((RETRY_COUNT+1))
done

# Nginx 설정 파일에서 proxy_pass 동적으로 변경
NGINX_CONFIG="/etc/nginx/sites-available/default"
NEW_PROXY_PASS="proxy_pass http://127.0.0.1:$NEW_PORT;"

# listen 80번 포트의 location / 블록 내에서 proxy_pass 줄만 변경
sudo sed -i '/location \/ {/!b;n;s|proxy_pass http://127.0.0.1:.*;|'"$NEW_PROXY_PASS"'|' $NGINX_CONFIG

# sed 명령어가 성공했는지 확인
if [ $? -ne 0 ]; then
    echo "Error: Failed to update Nginx config."
    exit 1
fi

# Nginx 설정 재로드
sudo service nginx reload

# 이전 애플리케이션 종료
OLD_PID=$(lsof -t -i:$CURRENT_PORT)
if [ -n "$OLD_PID" ]; then
  sudo kill -15 $OLD_PID
  sleep 7
  # 프로세스가 여전히 종료되지 않았는지 확인하고, 강제 종료 시도
  if sudo kill -0 $OLD_PID 2>/dev/null; then
    echo "Process $OLD_PID did not terminate, killing with -9"
    sudo kill -9 $OLD_PID
  fi
fi

echo "Deployment complete. Nginx is routing traffic to port $NEW_PORT."

 

복붙이 완료 됐다면, ctrl + o 를 입력하고 엔트를 눌러서 저장해 줍니다.

그리고 ctrl + x 를 눌러서 편집기에서 나갑니다.

 

Nginx 설정 셋팅

저번 포스팅에서 엔진엑스의 설정을 바꿨다면 상관이 없겠지만 그래도 확인해주겠습니다.

 

$ sudo nano /etc/nginx/sites-available/default

 

입력하여 편집기가 나왔을 때 다음과 같이 나오면 됩니다.

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8081;  # 이 부분은 deploy.sh에서 동적으로 변경됩니다.
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

 

 

bluegreen_ver1 셋팅

bluegreen_ver1 브랜치로 checkout 해줍니다.

그리고 터미널을 켜서 git pull origin bluegreen 입력하여 변경사항을 해당 브랜치에 반영해줍니다.

만약 제 레포지토리를 fork 해서 하는 것이 아니라 레포지토리를 생성해서 따라하시는 분이면, main 브랜치 내용을 main 브랜치 복붙 해서 푸시하고, 깃허브에서 main 브랜치를 본따 bluegreen, rolling, canary 브랜치를 만드시면 됩니다.

만약 변경사항이 없어서 bluegreen_ver1 브랜치 bluegreen브랜치에 풀리퀘를 보낼 수 없을 수도 있기에 수정사항을 만들어 줍니다.

 

TestController 에서 변화를 주는 걸 추천드립니다.

전 다음과 같이 설정하여 기본값을 주었습니다. 

@RestController
public class TestController {
    private static final String RESPONSE_BODY_MESSAGE = "버전 1 응답값입니다. 무중단 배포를 도입 전입니다.";
    @GetMapping("/hello")
    public ResponseEntity test() {
        return ResponseEntity.ok(RESPONSE_BODY_MESSAGE);
    }
}

 

수정을 할때 구글 자바 컨벤션을 ci 체크스타일 설정했기 때문에 한줄에 100글자가 넘어가지 않도록 조심해주세요! 현재 기본 상태도 거의 99자 98자 되는 거 같네요. 흰색 줄이 100글자 표시 선입니다.

 

그리고 cd-bluegreen.yml 파일을 확인해줍니다.

다음과 같이 jar파일을 업로드 하고 실행하는 명령어로 되어 있어야합니다. 만약 내용이 다르다면 복붙을 하여줍니다.

name: Build and Deploy

on:
  push:
    branches:
      - bluegreen

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: application.yml
        run: |
          mkdir -p src/main/resources
          touch ./src/main/resources/application.yml
          echo "${{ secrets.APPLICATION_YML }}" > ./src/main/resources/application.yml
          cat ./src/main/resources/application.yml
      - name: Run chmod to make gradlew executable
        run: chmod +x ./gradlew

      - name: Build with Gradle
        uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
        with:
          arguments: build

      - name: Upload artifact
        uses: actions/upload-artifact@v2
        with:
          name: build-file
          path: build/libs/*.jar

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v2
        with:
          name: build-file

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Add remote server to known hosts
        run: |
          mkdir -p ~/.ssh
          ssh-keyscan ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts
      - name: Rename and transfer artifact
        run: |
          mv *.jar app.jar
          scp app.jar ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }}:~/cicd/
      - name: Execute remote commands
        run: |
          ssh -v ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }} "sudo fuser -k 8081/tcp || true"
          ssh -v ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }} "sudo fuser -k 8082/tcp || true"
          ssh -v ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }} "sudo nohup /usr/bin/java -jar -Dserver.port=8081 ~/cicd/app.jar > ~/cicd/nohup.log 2>&1 &"

 

수정 후 커밋하고 푸시 해줍니다.

 

Pull request 생성

깃허브에 풀리퀘를 보냅니다.

base 는 bluegreen이고 compare 은 bluegreen_ver1 이여야 하는 걸 꼭 확인해주세요. 디폴트 브랜치가 main 으로 되어 있어서 base가 main으로 되어 있을 것입니다. 꼭 수정해줘야합니다. bluegreen 에 푸시 되어야 깃허브 액션스가 실행되기 때문입니다.

체크 스타일 테스트와 빌드 테스트를 통과하게 되면 merge pull reqeust 해줍니다.

그러면 Actions 에 들어가면 배포가 진행되고 있는 걸 확인할 수 있습니다.

 

 

이렇게 되면 배포가 완료된 것입니다. 

포스트맨을 통해서 {http://EC2 퍼블릭 IP/hello} 요청을 보내면 무중단 배포 전이라는 말과 8081 포트에서 실행 중인 걸 확인할 수 있습니다.

 

bluegreen_ver2 셋팅

blueegreen_ver2 브랜치로 checkout 해줍니다. 그리고 git pull origin bluegreen 하여 변경점을 최신화 해줍니다. 

ver2 는 무중단 배포 도입 버전이니깐, 그에 맞게 수정을 해줄 겁니다.

먼저 응답값을 수정해주겠습니다.

 

이렇게 버전2이라는 걸 확실하게 명시해줬습니다.

 

그리고 제일 중요한 cd-bluegreen.yml 을 수정하겠습니다.

jar 파일을 업로드하고 실행하는 것이 아닌, cicd/bluegreen/ 디렉토리에 있는 deploy.sh 쉘 스크립트를 실행시켜줄 것입니다.

 

name: Build and Deploy

on:
  push:
    branches:
      - bluegreen

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: application.yml
        run: |
          mkdir -p src/main/resources
          touch ./src/main/resources/application.yml
          echo "${{ secrets.APPLICATION_YML }}" > ./src/main/resources/application.yml
          cat ./src/main/resources/application.yml
      - name: Run chmod to make gradlew executable
        run: chmod +x ./gradlew

      - name: Build with Gradle
        uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
        with:
          arguments: build

      - name: Upload artifact
        uses: actions/upload-artifact@v2
        with:
          name: build-file
          path: build/libs/*.jar

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v2
        with:
          name: build-file

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Add remote server to known hosts
        run: |
          mkdir -p ~/.ssh
          ssh-keyscan ${{ secrets.SERVER_IP }} >> ~/.ssh/known_hosts

      - name: SCP transfer
        run: scp *.jar ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }}:~/cicd

      - name: Execute remote command
        run: |
          ssh -v ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }} "sudo chmod +x ~/cicd/bluegreen/deploy.sh"
          ssh -v ${{ secrets.SERVER_USERNAME }}@${{ secrets.SERVER_IP }} "sudo ~/cicd/bluegreen/deploy.sh"

 

 

아파치 제이미터 테스트 셋팅

테스트를 하여 모니터링 하고 싶으신 분들에게 추천드립니다. 

매 간격마다 HTTP 요청을 보내서 정말 다운 타임 없이 배포가 진행되는지 실제로 보기 위함일 뿐입니다.

 

먼저 Simple HTTP rquest 템플릿을 생성하겠습니다.

 

 

 

HTTP 메소드와 URL 을 입력해줍니다. URL은 HTTP 프로토콜과 자신의 EC2 퍼블릭 IP 를 넣어주면 됩니다.

 

아파치 제이미터의 핵심은 쓰레드 그룹 설정입니다. 근데 저흰 성능 테스트 시나리오를 신경쓸 건 아니라서, 대략 7분을 기준으로 적당한 요청 간격을 보내기 위해 Ramp-up 시간은 420 에 사용자 수를 200 하겠습니다.

 

 

그리고 결과를 보기 위해서 결과 트리 보기를 추가하겠습니다. 테스트에서 우클릭하면 추가할 수 있습니다.

 

실행 버튼을 누르면 테스트를 파일로 저장하라는 말이 나오는데, 적당한 경로에 원하는 이름으로 저장합니다.

pull request를 머지하고 나서 테스트를 시작하는 것이 좋습니다. 

 

Pull request 생성

깃허브에 풀리퀘를 보냅니다.

base 는 bluegreen이고 compare 은 bluegreen_ver2 이여야 하는 걸 꼭 확인해주세요. ver1 때와 똑같습니다.

체크스타일 테스트 통과와 빌드 테스트 통과를 하면 merge pull request 해줍니다. 

푸시 되고 나서 액션스가 돌아가면 아파치 제이미터에서 초록색 재생 버튼을 눌러줍니다.

 

아파치 제이미터에서 결과를 트리보기를 눌러보면 기존에 배포된 버전1과 8081포트에서 실행되고 있는 걸 확인할 수 있습니다.

 

 

 

배포가 완료되고 나선, 버전 2 응답값과 무중단 배포가 잘 도입 된 걸 확인 할 수 있습니다.

표본 추출기 옆에 응답 데이터 탭에서 응답 body 에서 확인 할 수 있습니다.

 

 

 

8081 에서 실행되는 블루 서버가 8082 에서 그린 서버로 대체되고 구버전에서 신버전으로 다운타임 없이 잘 배포되는 걸 실습해 볼 수 있었습니다.

블루그린 배포 전략은 새로운 버전을 별도의 환경에 배포한 후, 트래픽을 전환하여 다운타임 없이 배포를 완료하는 방식입니다. 이 전략의 장점은 배포 중 오류 발생 시 간편하게 이전 버전으로 롤백할 수 있어 안정성이 높다는 것입니다. 또한, 트래픽 전환이 빠르게 이루어져 서비스의 중단이 없다는 점도 강점입니다. 그러나 단점으로는 두 개의 완전한 인프라를 유지해야 하므로, 비용이 증가할 수 있으며, 복잡한 환경 설정이 필요할 수 있다는 점이 있습니다. 지금 실습에선 신 버전이 잘 배포되면 구 버전의 프로세스는 안전하게 kill 해주었습니다. 설정이 복잡하긴 하지만, 롤링과 카나리 전략보다는 복잡하지 않은 것도 장점이 될 수 있을 거 같습니다.

포스트맨으로 구 버전이 돌아가는 포트번호로 헬스 요청을 보내면 어플리케이션 잘 내려간 걸 확인 할 수 있습니다.