무중단 배포 작업 과정2

[nayonsoso]

.

[skylar1220]

2️⃣ CD 를 ec2 마다 / 순차적으로 하게 한다.

방법) max-parallel

기본적으로는 모든 러너를 사용해서 job들을 병렬적으로 수행한다. 하지만 max-parallel 설정을 통해 동시에 실행할 job의 개수를 설정해줄 수 있다.

jobs:
  test-concurrency:
    runs-on: ${{ matrix.os }}
    strategy:
      max-parallel: 1 # 동시에 1개만 job이 실행되도록 설정
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]  
    concurrency:
      group: sequential-test
      cancel-in-progress: false # 이전 작업을 취소하지 않는다는 설정

실험 결과 순서대로 하나씩 runs-on을 실행함!

[skylar1220]

발견한 것

환경 구성에 같은 태그로 되어있는 것을 기존 블루로 인식하고 제거한다.

[nayonsoso]

Code Deploy

1. Code Deploy 어플리케이션을 만든다.
2. 생성한 어플리케이션에 들어가 배포 그룹을 만든다.
3. 배포 그룹의 설정은 아래와 같이 한다.
   • 서비스 역할 : 타겟 ec2에 접근할 수 있는 역할을 설정해줘야 한다.
     • e.g. 접근하려는 리소스가 S3 이면, S3에 대한 접근 권한이 있는 역할을 설정해줘야 한다.
   • 리뷰미의 경우, 우테코에서 만들어준 project-code-deploy 역할을 부여한다.
   • 배포 유형 : 블루/그린
   • 환경 구성 : 인스턴스 수동 프로비저닝 / Amazon EC2 인스턴스
     • 인스턴스 수동 프로비저닝이란, 대체할 ec2 를 직접 지정하는 방식을 의미한다.
   • 태그 : 기존 인스턴스를 식별할 수 있는 태그를 추가한다.
     • 이때, 이 태그로 식별되는 인스턴스들은 [삭제 - 배포] 대상이 되므로 유의해야 한다.

[skylar1220]

문제 상황

1. code deploy의 블루/그린 방식으로 하면 매번 인스턴스가 삭제 - 생성되어서 ip가 바뀐다.
2. 모니터링 서버의 프로메테우스 같은 경우는 어플리케이션 서버의 ip를 등록해놔야하는데 이걸 매번 바꿔줘야하는 문제
3. ip가 아닌 도메인 주소로 등록해놓을까했지만, 모니터링에서 이렇게 접속하는 걸 실패함: curl http://api.review-me.page/9100
4. (행동대장, 코레아팀 경험) auto scaling, 대상그룹 관련 권한이 없어서 추가 요청이 필요함.

시도할 방안

1.(ec2 삭제 -생성 방식 맞음) 도메인 주소로 prod1,2에 접속할 수 있는 방법 찾아서 모니터링 서버에 도메인 주소로 박음: 블루 그린 방식 가능
2. (ec2 삭제 -생성 방식 아님) code deploy를 사용하되 롤링 방식으로 한다 - 구, 신 버전이 혼용되는 순간이 생긴다. 마이너 체인지는 괜찮지만 메이저 체인지는 사용자가 버튼 눌렀을 때 옛날 api 호출해서 오류날 수 있음
3. github action-script 사용해서 배포 순간에는 하나의 인스턴스에 2개의 어플리케이션이 뜨게한다: tps가 줄어드는 문제

[skylar1220]

롤링 방식 vs 블루-그린 방식

롤링 방식

• code deploy로 적용 가능
• 단점
  • 배포하는 동안 한 쪽 운영 서버로만 요청을 보냄. 부하가 커짐.
  • 구버전, 신버전 호환은 블루-그린과 마찬가지로 상관없음. 어차피 2대라 구, 신버전이 같이 떠있을 일은 없음. (프론트와의 호환 문제는 논외)

블루-그린 방식 (한 인스턴스에 포트 2개 활용)

• 포트 포워딩을 해줄 엔진엑스가 필요함
• 단점
  • 배포하는 동안은 한 인스턴스에 2개의 어플리케이션이 떠있으므로 CPU, 메모리에 부담이 있을 것

비교

배포 순간에 두 단점을 비교해보았을 때,
롤링 방식은 확실하게 TPS가 절반으로 준다. 한 쪽 운영 서버로만 요청을 보내기 때문에.
블루-그린 방식은 한 인스턴스에 2개의 어플리케이션이 떠있는데, 이것이 TPS를 절반으로까지 줄이지는 않을 것이라는 추측(더 근거가 필요하다)으로
블루-그린 방식을 선택하게 되었다!

[skylar1220]

✅ 블루-그린 방식이 배포시 부하가 얼마나 심해지는지 확인 필요

기존 release 를 할 때 하나를 run 할 때 CPU 는 17%(평균 3%) 그리고 메모리는 67%(평소에는 50)이 되었기 때문에, 감당할 수 있을 것이라 생각한다.

[skylar1220]

dev 서버에 어플리케이션을 하나 더 띄워보고 얼마나 CPU, 메모리가 치솟나 보면 되지 않을까?
어차피 micro이고, 깔려있는 것도 prod보다 더 많으니 dev에서 괜찮은 수치를 보인다면 prod도 안심할 수 있을 것 같다.

여기에, 단순히 견디는지가 아니라 tps에 얼마나 영향을 주는지까지 확인해보고 싶다면, dev에 실험해보는 동안 tps 부하를 줘보면 알 수 있겠다.

[skylar1220]

tps 떨어지는 거 피하기 위한 장치로 모았다가 수동 배포 방식

[skylar1220]

cd가 돌 때, 운영되고 있는 어플리케이션 쪽의 CPU, 메모리가 감당가능한지.

[nayonsoso]

🧑🏻‍⚖️ 우리는 왜 [Code Deploy의 블루 그린] 방법을 사용하지 않았는가?

Code Deploy의 블루 그린 방식을 고려했던 이유

• code deploy 의 블루 그린 방식을 사용하면 ec2를 삭제하고, 새로운 jar 파일이 담긴 ec2 를 생성해준다.
• ec2에 들어가서 작업하는게 불편하다 느꼈던 우리 팀은 항상 'ec2 상수화'를 고대했었는데, 블루 그린 방식은 이런 우리 팀의 니즈와 잘 맞아 보였다.

한계

• 하지만, ec2 를 삭제하고 새로 생성하는 것은 많은 사이드 이펙트를 야기했다.
• 일례로 우리 팀은 프로메테우스로 각 ec2 의 메트릭을 받아오고 있었다. 그리고 프로메테우스는 pull 방식이므로 target-ip를 알고 있어야 했다. 이런 모니터링 전략은 '변하지 않는 ip'가 전제되어야 했으므로, ec2 를 삭제-생성하는 code deploy의 블루그린 방식과 맞지 않았다.
• 물론 이를 해결할 수 있는 방법이 있다고는 하지만, 이를 위해서는 우리의 지금 목표인 '무중단 배포'보다 더 큰 작업이 필요할 것 같았다.

느낀 점

• Code Deploy의 블루 그린 방식을 고려하면서, 우리의 서비스는 '스케일 아웃 or 오토 스케일링'이 힘든 구조라는 것을 알게 되었다.
• 이 부분을 문제라고 느꼈으며, 추후 이를 보완할 수 있는 방법들을 찾아보기로 했다.
• 이것을 알게 되었다는 것 만으로도 의미가 있었던 삽질이라는 생각이 든다.

[skylar1220]

1. 엔진 엑스 없이 포트 포워딩(?) 할 수 있는 방법 찾기
2. 수동 blue-green 할 수 있는 방식

[nayonsoso]

1. 현재 실행 중인 컨테이너의 포트 확인
2. 새 컨테이너를 다른 포트로 실행
3. 새 컨테이너의 상태 확인
4. 트래픽을 새 컨테이너로 전환
5. 이전 컨테이너 종료

---

0. env.prod 파일로 환경 변수 설정

SPRING_PROFILE=prod
DOCKER_TAG=release
BLUE_PORT=8080
GREEN_PORT=8081

이때 설정한 환경변수는 docker-compose 파일에 적용되며, shell script 에도 적용된다.

1/ docker-compose 파일에 적용하는 방법

docker-compose --env-file .env.prod up -d

2/ shell script 에 적용하는 방법

source /.env.prod

1. Docker Compose 파일 수정

두 개의 서비스를 정의하고, 포트를 변수로 설정한다.

version: '3'
services:
 app-green: # 서비스 이름, shell 의 docker-compose up 뒤에 들어가면 하나의 서비스만 up 할 수 있다.
     image: reviewme/review-me-app:${DOCKER_TAG}
     ports:
         - "80:${GREEN_PORT}"
     environment:
         - SERVER_PORT=${GREEN_PORT}
 app-blue:
     image: reviewme/review-me-app:${DOCKER_TAG} # release
     ports:
         - "80:${BLUE_PORT}"
     environment:
         - SERVER_PORT=${BLUE_PORT}

🤔 두개의 서비스를 정의함으로써 사용되는 추가 리소스는 없을까?

cf. 서비스란, 이미지를 기반으로 실제로 실행되는 애플리케이션이다.
서비스 하위에 어떤 이미지를 어떤 환경 변수, 볼륨으로 쓸 것인지를 정할 수 있다.

두 개의 서비스를 저장해야 하므로 약간의 추가 디스크 공간이 필요하다.
하지만 Docker의 레이어 시스템 덕분에, 두 버전 간 차이만 추가로 저장되므로 큰 영향은 없다.
e.g. 이미지 하나가 5이면, 그 이미지를 사용하는 서비스가 3개일 때, 15가 사용되는 것이 아니다.

2. application.yml 수정

docker-compose 에서 지정한 환경변수로 port 를 설정한다.

spring:
 profiles:
   active: prod

server:
 port: ${SERVER_PORT}

3. 배포 스크립트 작성

아래 과정에서
grep 으로 어떻게 docker 내부의 application 중에서 살아있는게 뭔지? 어떻게 가져올건지? 에서 막혔고
같은 맥락으로, 새로운 docker 이미지가 잘 떠있는지를 어떻게 health-check 할수 있을지? 에서 막혔다.
🚧공사중....🚧

#!/bin/bash

# .env.prod 파일의 내용을 환경변수로 저장
source /.env.prod 

# 현재 활성화된 포트 확인
CURRENT_PORT=$(docker ps --filter name=app -q | xargs -I {} docker port {} | grep -o '808[01]')

# 새로운 포트 설정
if [ "$CURRENT_PORT" == ${BLUE_PORT} ]; then 
NEW_PORT=${GREEN_PORT}
NEW_COLOR=green
else
NEW_PORT=${BLUE_PORT}
NEW_COLOR=blue
fi

# 새 버전 배포
docker-compose --env-file .env.prod up -d app-$NEW_COLOR   # e.g. 컨테이너 서비스명: app-green

# 새 컨테이너 상태 확인
MAX_RETRIES=10
RETRY_INTERVAL=5

for i in $(seq 1 $MAX_RETRIES)
do
    if nc -z localhost $NEW_PORT; then
        echo "New version is up and running on port $NEW_PORT"
        break
    fi

    if [ $i -eq $MAX_RETRIES ]; then
        echo "New version failed to start, rolling back"
        docker-compose --env-file .env.prod stop app-$NEW_COLOR
        exit 1
    fi

    echo "Waiting for the new version to start... (Attempt $i/$MAX_RETRIES)"
    sleep $RETRY_INTERVAL
done


  # 이전 버전 종료
docker-compose --env-file .env.prod stop app-$([ "$NEW_COLOR" == "blue" ] && echo "green" || echo "blue")

4. GitHub Actions 워크플로우 수정:

- name: Deploy new version
 run: |
   chmod +x ./deploy.sh
   sudo ./deploy.sh
 working-directory: ${{ env.APPLICATION_DIRECTORY }}/app

[nayonsoso]

10월 19일

어떤 순서로 일을 처리할 것인가?

docker compose & shell acript

•  CD 가 시작될 때,
  • 기존 것을 감지하여 ❓
  • 어떤 포트 & 서비스로 새로운 서비스를 시작할지 결정하고
  • 새로운 서비스를 docker pull 받아서 시작하고
  • 새로운 서비스 헬스 체크를 통과하면 기존 서비스 다운 ❓
  • 헬스 체크 실패하면 롤백 :: 새로운 서비스 다운(확실 x) & 기존 서비스 업
  • 80으로 접근하던 것을 다른 서비스로 매핑하는 서비스를 바꾼다고 해서 트래픽이 잘 가나? 동시에 두개의 서비스가 떠있는 상태가 된다면, 80 포트로 들어온 요청은 두가지 서비스로 둘 다 가나? docker compose 나 shell 로 안된다면 어떤 것을 활용을 해야 할까? -> 더 공부 필요 ❓❓
    ❗️시간 절약을 위해서 모든 물음표가 다 해결된 후 구현을 시작한다❗️

github actions

• bash 파일과 함께 docker-compose 를 실행하도록 변경
• 수동으로 할 수 있게 (트리거) 변경

실전

• 개발 서버에 적용을 해본다. 
• 배포 하는 순간에 Jmeter 로 요청을 보내서 확인을 한다. ❓

어떻게 해야 이 일을 더 효율적으로 처리할 수 있을까?

• 역할을 분담해서 ❓를 해결한다.
• 지피티와 같은 검색 툴을 적극 활용한다.

[skylar1220]

커비 작업 1. 동시에 두개의 서비스가 떠있는 상태가 된다면, 80 포트로 들어온 요청은 두가지 서비스로 둘 다 가나?

하고 싶은것 새로운 쪽 어플리케이션이 잘 run되기 전까지는 기존 서비스로 요청이 가고,
새로운 서비스가 잘 run되면 새로운 서비스로 요청이 가게한다.

[skylar1220]

방법: iptables를 사용해서 포트 포워딩 강제

#!/bin/bash

# .env.prod 파일의 내용을 환경변수로 저장
source /.env.prod 

# 현재 활성화된 포트 확인
CURRENT_PORT=$(docker ps --filter name=app -q | xargs -I {} docker port {} | grep -o '808[01]')

# 새로운 포트 설정
if [ "$CURRENT_PORT" == ${BLUE_PORT} ]; then 
   NEW_PORT=${GREEN_PORT}
   NEW_COLOR=green
else
   NEW_PORT=${BLUE_PORT}
   NEW_COLOR=blue
fi

# 기존 활성화된 포트로 포워딩 유지
# 설명: 이 작업은 네트워크 레벨에서 이루어지기 때문에, docker-compose에서 ports 설정을 통해 추가된 포트 매핑이 있더라도 iptables 규칙이 우선됩니다. 
# 즉, 새 버전의 컨테이너가 떠서 80:8081로 포워딩되더라도, iptables에서 이미 정의된 포워딩 규칙에 의해 요청은 여전히 CURRENT_PORT로만 전달됩니다.
echo "Forwarding 80 -> $CURRENT_PORT"
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port $CURRENT_PORT

# 새 버전 배포
docker-compose --env-file .env.prod up -d app-$NEW_COLOR   # e.g. 컨테이너 서비스명: app-green

# 새 컨테이너 상태 확인
MAX_RETRIES=10
RETRY_INTERVAL=5

for i in $(seq 1 $MAX_RETRIES)
do
   if nc -z localhost $NEW_PORT; then
       echo "New version is up and running on port $NEW_PORT"
       break
   fi

   if [ $i -eq $MAX_RETRIES ]; then
       echo "New version failed to start, rolling back"
       docker-compose --env-file .env.prod stop app-$NEW_COLOR
       exit 1
   fi

   echo "Waiting for the new version to start... (Attempt $i/$MAX_RETRIES)"
   sleep $RETRY_INTERVAL
done

# 새 버전으로 포워딩 업데이트
echo "Updating forwarding: 80 -> $NEW_PORT"
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port $NEW_PORT     # 새 포트로 포워딩

# 이전 버전 종료
docker-compose --env-file .env.prod stop app-$([ "$NEW_COLOR" == "blue" ] && echo "green" || echo "blue")

[skylar1220]

Q. REDIRECT --to-port $CURRENT_PORT 의 CURRENT_PORT가 green_port랑 일치하면 app-green 서비스로 가고, blue_port랑 일치하면 app_blue 서비스로 간다고? 그게 포트 일치만 보고 간다는게 맞아?

네, 정확히 그렇습니다. iptables 명령어에서 설정한 포트 리다이렉트 규칙은 포트 번호만을 기준으로 동작합니다. 즉, iptables의 설정에서 REDIRECT --to-port $CURRENT_PORT라는 명령어는 특정 포트로 리다이렉트하라는 의미입니다. 포트 번호가 어떤 컨테이너의 포트인지에 상관없이, 해당 포트로 모든 트래픽이 전달됩니다.

왜 포트 번호가 중요한가?

iptables -t nat -A PREROUTING 명령어는 네트워크 레벨에서 동작하며, 포트 번호에 따라 트래픽을 리다이렉트합니다. 이때 리다이렉트 대상은 컨테이너의 서비스 이름이 아니라 포트 번호입니다. 즉, 포트 80으로 들어오는 요청을 --to-port $CURRENT_PORT로 리다이렉트하면, 현재 $CURRENT_PORT로 설정된 포트로 트래픽이 전달됩니다.

예를 들어:

1. **CURRENT_PORT가 GREEN_PORT**라면:

   • iptables에서 REDIRECT --to-port $CURRENT_PORT는 REDIRECT --to-port $GREEN_PORT로 해석됩니다.
   • 그 결과, 80번 포트로 들어오는 모든 요청은 app-green 서비스의 포트로 전달됩니다.

2. **CURRENT_PORT가 BLUE_PORT**라면:

   • iptables에서 REDIRECT --to-port $CURRENT_PORT는 REDIRECT --to-port $BLUE_PORT로 해석됩니다.
   • 이때 80번 포트로 들어오는 요청은 app-blue 서비스의 포트로 전달됩니다.

핵심

• 포트 일치만을 기준으로 요청이 전달됩니다. 서비스 이름(app-green 또는 app-blue)은 중요하지 않으며, 어떤 서비스가 해당 포트를 사용하는지에 따라 트래픽이 리다이렉트됩니다.
• 따라서, iptables 규칙에 따라 포트 번호가 일치하는 서비스로 요청이 전달됩니다. app-green이 GREEN_PORT를 사용하고 있고, iptables가 해당 포트로 리다이렉트하도록 설정되었다면, 해당 포트에 연결된 서비스로 요청이 가는 방식입니다.

이 설정은 컨테이너에서 어떤 포트가 어느 서비스로 연결되는지에 따라 다르게 동작하지만, 최종적으로는 포트 번호가 요청의 흐름을 결정합니다.

[nayonsoso]

산초 작업 - 컨테이너 포트를 기반으로 지금 8080 이 떠있는지 / 8081이 떠있는지 확인한다.

get_current_port() {
    local current_port=$(docker ps --format '{{.Names}}:{{.Ports}}' | 
                         grep '^review-me-app' | 
                         grep -E ':::80->(8080|8081)/tcp' | 
                         sed -E 's/.*:::80->([0-9]+)\/tcp.*/\1/')
    if [ -z "$current_port" ]; then
        echo "No active 'review-me-app' container found running on port 8080 or 8081"
        exit 1
    fi
    echo $current_port
}

CURRENT_PORT=$(get_current_port)
echo "Current active port: $CURRENT_PORT"

docker ps --format '{{.Names}}:{{.Ports}}'

• 현재 실행중인(up) 컨테이너의 이름과 포트 정보를 함께 출력한다.

grep 'review-me-app'

• review-me-app 이라는 이름이 포함된 라인만 찾는다.

grep -E ':::80->(8080|8081)/tcp'

• 정규 표현식을 사용해서, 80번 포트가 8080 또는 8081 로 매핑되어있는 라인만 찾는다.

sed -E 's/.:::80->([0-9]+)/tcp./\1/'

• sed 명령어로 :::80->8080/tcp 형식의 문자열을 8080 또는 8081 로 치환한다.

[skylar1220]

커비 작업 2. 기존 어플리케이션으로 간 요청을, 받은 요청까지는 처리하고 docker-compose down하는 방법

graceful shutdown

1. stop_grace_period 설정: docker-compose.yml 파일에 stop_grace_period 옵션을 추가하여, 컨테이너가 종료되기 전에 주어진 시간 동안 요청 처리를 완료할 수 있는 시간을 줍니다.

version: '3'
services:
  app-green:
    image: reviewme/review-me-app:${DOCKER_TAG}
    ports:
      - "80:${GREEN_PORT}"
    environment:
      - SERVER_PORT=${GREEN_PORT}
    stop_grace_period: 10s

  app-blue:
    image: reviewme/review-me-app:${DOCKER_TAG}
    ports:
      - "80:${BLUE_PORT}"
    environment:
      - SERVER_PORT=${BLUE_PORT}
    stop_grace_period: 10s

2. docker-compose stop 명령어는 컨테이너를 중지하지만, stop_grace_period 설정에 따라 지정된 시간 동안 요청 처리를 마무리할 수 있도록 대기합니다. 이 시간이 초과되면, 컨테이너는 강제로 종료됩니다.

docker-compose --env-file .env.prod stop app-$([ "$NEW_COLOR" == "blue" ] && echo "green" || echo "blue")

[nayonsoso]

산초 작업 - 새로 up 한 서비스가 잘 살아있는지를 체크한다.

처음에는 health-check 엔드포인트로 확인하는 방법을 고려했다.
하지만 스프링 어플리케이션 자체가 8080 / 8081 로 분기가 되는 것과 달리,
❗️헬스 체크 엔드포인트는 {우리만의_비밀_엔드포인트} 로 고정이 되어있다.❗️
따라서 {우리만의_비밀_엔드포인트} 로 요청을 보내서 up 이라는 응답이 오더라도,
이게 블루가 healthy 한건지, 그린이 healthy 한건지 알아낼 방법이 없다.

따라서, docker ps + grep 으로 새로 띄운 서비스의 포트가 있는지 확인하는 방법으로 결정했다.
어플리케이션이 실행하는데에 실패했다면, 포트가 열리지 않을 것이므로 이 방법도 유효하다 생각한다.

# new_port 변수가 설정되어 있다고 가정

check_service() {
    local container_info=$(docker ps --format '{{.Names}}:{{.Ports}}' | 
                           grep '^review-me-app' | 
                           grep -E ":::80->$new_port/tcp")

    if [ -n "$container_info" ]; then
        echo "Service 'review-me-app' is running and mapped from port 80 to $new_port"
        return 0
    else
        echo "Service 'review-me-app' is not running or not mapped correctly"
        return 1
    fi
}

docker ps --format '{{.Names}}:{{.Ports}}'

• 현재 실행중인(up) 컨테이너의 이름과 포트 정보를 함께 출력한다.

** grep '^review-me-app'**

• review-me-app 으로 시작하는 이름이 포함되어있는 라인을 찾는다.

grep -E ":::80->$new_port/tcp

• new_port 변수로 컨테이너 포트가 띄워졌는지 확인한다.

if [ -n "$container_info" ]; then

• container_info 의 값이 존재하는 것이 조건이다.

[skylar1220]

현재까지 작업 반영 (10.19 19:35 기준)

1. 배포 스크립트

#!/bin/bash

# .env.prod 파일의 내용을 환경변수로 저장
source /.env.prod 

# 현재 활성화된 포트 확인
get_current_port() {
    local current_port=$(docker ps --format '{{.Names}}:{{.Ports}}' | 
                         grep '^app' | 
                         grep -E ':::80->(8080|8081)/tcp' | 
                         sed -E 's/.*:::80->([0-9]+)\/tcp.*/\1/')
    if [ -z "$current_port" ]; then
        echo "No active app container found running on port 8080 or 8081"
        exit 1
    fi
    echo "$current_port is current port!"
}

CURRENT_PORT=$(get_current_port)

# 새로운 포트 설정
if [ "$CURRENT_PORT" = "8080" ]; then 
   NEW_PORT=8081
elif [ "$CURRENT_PORT" = "8081" ]; then
   NEW_PORT=8080
else
   echo "Error: Unexpected CURRENT_PORT value: $CURRENT_PORT"
   exit 1
fi

# 기존 활성화된 포트로 포워딩 유지
echo "Forwarding 80 -> $CURRENT_PORT"
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port $CURRENT_PORT

# 새 버전 배포
docker-compose --env-file .env.prod up -d app-$NEW_PORT 

# 새 컨테이너 상태 확인
is_new_container_healthy() {
    docker ps --format '{{.Names}}:{{.Ports}}' | 
    grep '^app' | 
    grep -E ":::80->$NEW_PORT/tcp"
}

# 반복하며 새 컨테이너 상태 확인
MAX_RETRIES=10
RETRY_INTERVAL=5

for i in $(seq 1 $MAX_RETRIES)
do
   container_info=$(is_new_container_healthy)
   if [ -n "$container_info" ]; then
       echo "New version is up and running on port $NEW_PORT"
       break
   fi
   if [ $i -eq $MAX_RETRIES ]; then
       echo "New version failed to start, rolling back"
       docker-compose --env-file .env.prod �down app-$NEW_PORT
       exit 1
   fi
   echo "Waiting for the new version to start... (Attempt $i/$MAX_RETRIES)"
   sleep $RETRY_INTERVAL
done

# 새 버전으로 포워딩 업데이트
echo "Updating forwarding: 80 -> $NEW_PORT"
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port $NEW_PORT

# 이전 버전 종료 (graceful shutdown)
OLD_PORT=$([ "$NEW_PORT" == "8080" ] && echo "8081" || echo "8080")
docker-compose --env-file .env.prod stop app-$OLD_PORT

2. Docker Compose 파일

version: '3'
services:
  app-8080:
    image: reviewme/review-me-app:${DOCKER_TAG}
    container_name: review-me-app
    ports:
      - "80:8080"
      - "5959:5959"
    volumes:
      - ./application-${SPRING_PROFILE}.yml:/application.yml
      - /home/ubuntu/logs/:/logs
    environment:
      - SERVER_PORT=8080
      - TZ=Asia/Seoul
    stop_grace_period: 10s

  app-8081:
    image: reviewme/review-me-app:${DOCKER_TAG}
    container_name: review-me-app
    ports:
      - "80:8081"
      - "5959:5959"
    volumes:
      - ./application-${SPRING_PROFILE}.yml:/application.yml
      - /home/ubuntu/logs/:/logs
    environment:
      - SERVER_PORT=8081
      - TZ=Asia/Seoul
    stop_grace_period: 10s

[skylar1220]

PORT 변수 제거한 env 파일

SPRING_PROFILE=prod
DOCKER_TAG=release

[nayonsoso]

🤔 롤백 작업 시작 전, 의문이 드는 것

1. 헬스 체크 for 문에서 새로운 서비스가 unhealthy 하다는게 확정되어 💡exit 1 로 빠져나간다면💡,
   뒤에 있는 것들이 실행이 아예 안되는지? 아니면 그 for 문만 빠져나가는지?
   → for 문 뒤에 있는 port 를 바꾸고, 기존 서비스를 종료하는 작업이 뒤에 있기 때문에, 스크립트 자체를 빠져나가야 한다.
   만약 for 문만 빠져나가는 거라면, 스크립트 자체를 빠져나게 하는 방법을 찾아본다.

2. docker up 으로 새로운 서비스를 띄운 경우, 💡어플리케이션 run 이 안되는데 떠있기만 할 수는 있나?💡
   아니면 자동으로 down 되나?
   → 자동으로 down 되지 않는 거라면 우리가 직접 down 하는 것을 추가로 해줘야 한다.
   그런데 직접 down해야 하고? 1번에서 파일 자체를 나가는 거라면? 파일 나가기 전에 down 을 해줘야 한다.

---

3. bash 파일 실행 결과가 성공/ 실패 인지를 반환하는 방법 찾아야함
   : 이유는 실패한 경우 push한 도커 이미지를 이전 버전으로 돌려놔야해서
   : bash가 비정상 종료(새로운 서비스 run 실패)를 알려주기 위해서.

4. (도커 이미지를 돌려놓는 방법이 기존 존재 or 쉽다면) 도커 이미지 직전 버전 가져오는 방법 찾기
   : 다음 배포(대부분 hotfix)에서 덮어씌워지니 괜찮다고 생각할 수도 있지만, 잘못된 이미지가 올라와있는 동안 그 이미지를 받아서 어플리케이션을 실행하는 일말의 위험성을 없애기 위해

---

5. docker-compose 파일을 지금 dev 와 prod 가 공유를 하고 있는데, 8081 / 8080 의 분리를 dev에도 적용해서
   💡dev도 무중단으로 해야 할 필요가 있을까?💡 아니면 docker-compose 도 분기를 할 방법이 있나?

[skylar1220]

✅ 두 서비스의 중복이 심하다 해결 방법 없을까?

[skylar1220]

bash 파일을 거의 완성해가니 실제 실행할 때를 상상해보며 드는 생각

github action을 썼을 때는 어디서 문제가 발생했는지 볼 수 있었는데 bash 파일 내부는 스텝별로 어느 문제가 안에서 생겼는지는 못보겠지?
하지만 로그가 있으니 괜찮을듯?

[donghoony]

중간중간 step별로 echo를 달아주면 어떤 작업을 하다가 죽었는지는 확인할 수 있을 거예요

[skylar1220]

크크크 이미 달았죠 필요한 부분 더 달아야겠다🤭 그나저나 아루 지켜보고 있었구나ㅋㅋㅋㅋ👀

[skylar1220]

롤백 관련 커비 작업

1. 헬스 체크에서 unhealthy 하다는게 확정되어 exit 1 로 빠져나간다면, 뒤에 있는 것들이 실행이 아예 안되야하는데 그런가?

그렇다. exit 1이 실행되면 스크립트의 실행이 즉시 중단된다. 따라서, 스크립트를 종료하고, 지정한 상태 코드(여기서는 1)를 반환한다.
GitHub Actions는 이 종료 코드를 감지해서 해당 스텝은 Error: Process completed with exit code 1를 출력하며 실패한다.

2. docker up은 성공했는데, 어플리케이션 run이 실패하는 경우 docker는 계속 up 상태인가?

맞다. 왜냐면 docker up은 성공했는데, 어플리케이션 run이 실패하는 아래와 같은 경우가 있어서.

• 애플리케이션 코드 오류: 새 버전에서 코드에 문제가 발생하여 애플리케이션이 시작하지 못하는 경우. 예를 들어, 데이터베이스 연결 오류나 종속성 누락 등입니다.
• 환경 변수 문제: .env.prod 파일의 환경 변수가 올바르게 설정되지 않아서 애플리케이션이 필요한 구성 요소에 접근할 수 없는 경우.
• 포트 충돌: 이미 해당 포트를 사용하는 다른 컨테이너가 있을 경우, 애플리케이션이 해당 포트에서 시작하지 못할 수 있습니다.
• 자원 부족: 시스템 자원(CPU, 메모리 등)이 부족하여 컨테이너가 제대로 실행되지 못하는 경우.

그럼 어플리케이션 실패하면 직접 down 해줘야하나?

놀랍게도 이미 처리가 되어있다.

5. docker-compose 파일을 지금 dev 와 prod 가 공유를 하고 있는데, 8081 / 8080 의 분리를 dev에도 적용해서 dev도 무중단으로 해야 할 필요가 있을까?

1. dev도 똑같은 docker-compose를 적용해서 무중단으로 하자: 해서 나쁠 것 없어서

단점이 있는가? dev는 머지가 많이 일어나는데 그 때마다 dev ec2에 어플리케이션이 2개가 뜨는 순간이 짧지만 존재한다. 그 순간에 cpu, mem이 치솟아 오를 수 있다는 점.

2. dev는 무중단 배포가 아닌 docker-compose를 적용하자: 필요없는데 굳이 무중단 할 필요 없어서.

그렇다면 dev만을 위한 docker-compose 분기를 해야할텐데 이렇게 파일이 나눠지는 게 괜찮은가? 추후 설정이 추가된다면 dev, prod용 docker-compose 파일 두 곳에 추가해야한다는 점이 번거롭다.

아니면 docker-compose 파일은 하나를 쓰되, 그 안에 태그를 통해 구분해서 dev 인 거는 include??등을 활용해 하나 포트로 하고,
prod는 2개 포트로 하고 이렇게 할 수 있을 것 같기도하고..

[skylar1220]

• ) 추가로 생각 든거 echo 필요한 부분 더 달기

[nayonsoso]

shell script 의 정상 종료와 비정상 종료를 GitHub action 에서 알 수 있나?

1. 스크립트에서 종료 코드를 지정함으로써 정상 종료 & 비정상 종료를 표현할 수 있다.
2. 명시적으로 exit 하지 않으면, 가장 마지막에 실행된 명령어의 종료 코드가 스크립트 전체의 종료 코드가 된다.
3. 깃허브 액션에서 어떤 shell 스크립트 실행이 실패했을 경우, 그 step 이 실패한 것으로 간주한다.
4. 기본적으로, 한 step 이 실패하면 해당 job 에 있는 다른 남은 step 은 실행하지 않는다.
5. 하지만 아래와 같이 설정함으로써 shell 실패 시 할 동작을 지정해줄 수 있다.
6. 이때 Step that might fail은 빨간색으로, Run only on failure는 초록색으로 표시되어 각 스텝의 실행 결과를 시각적으로 알 수 있다.

steps:
  - name: Step that might fail
    run: ./risky_script.sh
    continue-on-error: true

  - name: Run only on failure
    if: ${{ failure() }}
    run: echo "The previous step failed"

➡️ 우리에게 적용해보자면...
shell script 실행 후 실패(새로운 서비스로 갈아끼우는 것 실패)했을 때,
롤백을 github action에서도 할 수가 있다!!!

[nayonsoso]

도커 이미지 직전 버전 가져오는 방법 찾기

• 도커의 태그를 통해서 관리할 수 있다.
• 참고) 하나의 이미지에 여러 태그를 달 수 있으므로,
  우리가 기존에 달았던 develop 또는 release 와 충돌나지 않는다.

방법 :

1. 새로운 이미지를 빌드하고 올릴 때, latest 라는 태그를 단다.
2. runner 에서 latest 태그로 pull 을 한다.
3. 만약 이 과정에서 실패해서 롤백을 해야한다면
   최신 이미지에 previous 를 달고, 이전에 previous 를 latest 태그로 갈아껴준다.

name: CD Pipeline

on:
  push:
    branches: [ main ]

env:
  DOCKER_IMAGE: myorganization/myapp

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Login to Docker Hub
      uses: docker/login-action@v1
      with:
        username: ${{ secrets.DOCKER_HUB_USERNAME }}
        password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

    - name: Build new image
      # 새로운 도커 이미지를 만들고, 마지막 커밋을 태그로 단다 (식별하기 위해서)
      run: docker build -t ${{ env.DOCKER_IMAGE }}:${{ github.sha }} .

    - name: Update tags
      run: |
        # 현재의 latest 이미지를 pull 한다.
        docker pull ${{ env.DOCKER_IMAGE }}:latest || true
        
        # latest 를 previous로 태그 한다.
        docker tag ${{ env.DOCKER_IMAGE }}:latest ${{ env.DOCKER_IMAGE }}:previous || true
        
        # 새로운 이미지를 latest 로 태그한다.
        docker tag ${{ env.DOCKER_IMAGE }}:${{ github.sha }} ${{ env.DOCKER_IMAGE }}:latest

    - name: Push images
      run: |
        docker push ${{ env.DOCKER_IMAGE }}:${{ github.sha }}
        docker push ${{ env.DOCKER_IMAGE }}:latest
        docker push ${{ env.DOCKER_IMAGE }}:previous

    - name: Deploy and test
      id: deploy
      run: |
        # 배포 스크립트
        ./deploy-and-test.sh
      continue-on-error: true

    - name: Rollback if deployment failed
      if: steps.deploy.outcome == 'failure'
      run: |
        echo "Deployment failed. Rolling back to previous version."
        
        # previous 이미지를 가져온다.
        docker pull ${{ env.DOCKER_IMAGE }}:previous
        
        # previous 이미지를 latest 로 바꾼다.
        docker tag ${{ env.DOCKER_IMAGE }}:previous ${{ env.DOCKER_IMAGE }}:latest
        
        # 그리고 푸쉬한다.
        docker push ${{ env.DOCKER_IMAGE }}:latest

[skylar1220]

읽다보니 질문

1. docker tag 이 명령어는 태그를 새로 붙여주는 역할인가? 인식은 어떻게 하지? 만약 latest가 붙은게 여러개라면?
2. 원래 이전 스텝이 에러를 발생하면 action의 run이 끝나는 게 아니었나?

[donghoony]

      run: |
        # 현재의 latest 이미지를 pull 한다.
        docker pull ${{ env.DOCKER_IMAGE }}:latest || true
        
        # latest 를 previous로 태그 한다.
        docker tag ${{ env.DOCKER_IMAGE }}:latest ${{ env.DOCKER_IMAGE }}:previous || true

pull 실패, previous 태그가 실패하더라도 || true 때문에 계속 진행할 텐데, 이거 괜찮은가요 ?

[donghoony]

아래쪽에는 반대로 || true 가 없어요 ~~

[donghoony]

main 브랜치, myorganization은 예시라서 적힌 거죠 ??

[donghoony]

이거 이틀전거구나

[skylar1220]

우리 서비스에 적용

(어플리케이션 a, b는 각 8080, 8081 포트로 스프링 어플리케이션을 실행할 수 있는 상태, 하나의 인스턴스 내에서 실행됨)

• 어플리케이션 a가 실행되고 있는동안, 어플리케이션 a로만 요청을 보낸다.
• 이 때, 어플리케이션 b를 up한다. 어플리케이션 b로 아직 요청을 보내지는 않는다.
• 어플리케이션 b에 대한 헬스체크가 끝나면 어플리케이션 b의 포트로 요청을 보내고, 어플리케이션 a는 down한다.