무중단 배포 작업 과정3

[skylar1220]

10월 20일

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

docker compose & shell acript

• docker 이미지 롤백은 도커 허브에 올라와있는 이미지를 확인하는 작업이 필요하기 때문에 월요일에 아루의 도커 허브 계정으로 확인하면서 작업이 필요하다. 이 부분은 짜놓기만 하고 일단 실전 스크립트 버전에서는 뺀다.
• (위랑 함께 미루기) docker tag 이 명령어는 태그를 새로 붙여주는 역할인가? 인식은 어떻게 하지? 만약 latest가 붙은게 여러개라면?
• 5959 같은 포트는 확실히 안되겠네요. 이건 8080,8081을 헬스체크 포트로 바꾸는 방식을 고려해봐야겠어요. 5959로 했던 이유는 보안이었는데 이건 해결할 수 있는 다른 방법이 있을 것 같아서요.
• 동시에 켜질 때 같은 폴더를 볼륨으로 마운트하면 우리가 예상하지 못하는 일이 발생하지는 않나요?
• 중간 버전 스크립트 정리하고 시작하기

github actions

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

실전

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

---

shell script

#!/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

docker-compose.yml

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

application.yml

spring:
 profiles:
   active: prod

server:
 port: ${SERVER_PORT}

[skylar1220]

docker-compose 파일을 지금 dev 와 prod 가 공유를 하고 있는데, dev도 무중단 버전 docker-compose 파일을 쓸 필요가 있을까?

1. dev도 똑같은 docker-compose를 적용해서 무중단으로 하자: 해서 나쁠 것 없어서
   단점이 있는가? dev는 머지가 많이 일어나는데 그 때마다 dev ec2에 어플리케이션이 2개가 뜨는 순간이 짧지만 존재한다. 그 순간에 cpu, mem이 치솟아 오를 수 있다는 점.

2. dev는 무중단 배포가 아닌 docker-compose를 적용하자: 필요없는데 굳이 무중단 할 필요 없어서.
   그렇다면 dev만을 위한 docker-compose 분기를 해야할텐데 이렇게 파일이 나눠지는 게 괜찮은가? 추후 설정이 추가된다면 dev, prod용 docker-compose 파일 두 곳에 추가해야한다는 점이 번거롭다.

결정

일단 dev도 같은 무중단 버전 docker-compose 파일을 쓰자!

이유

현재는 prod 무중단배포 성공이 목표이기 때문에 dev는 무중단 필요없는데 docker-compose 파일 분리할까? 는 목표 달성 후 따로 논의후 작업하기로 결정

[skylar1220]

동시에 켜질 때 같은 폴더를 볼륨으로 마운트하면 우리가 예상하지 못하는 일이 발생하지는 않나요? - 1

1. /home/ubuntu/logs/:/logs

이 부분은 괜찮음.
어플리케이션이 2개 더라도 각각 어플리케이션에서 발생한 로그는 /logs 디렉토리의 같은 review-me.logs 파일에 저장됨.
(실험 결과 추가)

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
      - ACTUATOR_PORT=5951
      - 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
      - ACTUATOR_PORT=5952
      - TZ=Asia/Seoul
    stop_grace_period: 10s

[nayonsoso]

Actuator 의 포트를 어떻게 바꿀 것인가?

actuator 의 외부 접근을 방지하기 위한 방법으로,
‘port 를 application 과 다르게 두고, 보안 그룹으로 외부 접근 제한하기’ 이외의 다른 방법이 존재하는 것은 사실이다.

일반적인 방법들로는,
a) 스프링 시큐리티를 사용해서 특정 유저 (org.springframework.security.core.userdetails.User) 로부터의 요청만 받게 하는 방법
b) 우리만의 규칙(특정 헤더를 가진 요청만 수용)을 만들고 그에 대한 인터셉터를 만드는 방법
c) 특정한 actuator 엔트포인트만 열어두는 방법
들이 있다.

---

하지만 각각을 검토해보자면
a & b) 프로메테우스나 로드 밸런서에서 접근할 때는 ❗️헤더 없이 엔드포인트로만 접근할 것이므로 이를 막게 되는 셈❗️😱
c) 우리가 지금 열어두는 엔드포인트(health, logfile, metrics, prometheus) 중에서 실제로 사용하는 것은 health, prometheus이다.
물론 모든 엔드포인드를 열 바에는 사용하는 actuator 포트만 여는게 더 보안상 좋겠지만,
그렇다고 해서 이들을 만천하에 공개하는게 안전한가? 라는 생각이 들었다.

---

일반적이진 않지만, 충분히 적용할 수 있을법한 방법들을 생각해봤다.
a) 포트는 어플리케이션 포트와 동일하게 가되, actuator 의 엔드포인트를 아무도 예상하지 못할만한 것으로 하는 것
이를테면 지금은 ‘/actuator ’로 되어있는 엔드 포인트를 `/N9R3TuaQG’ 이런 걸로 바꾸는 것이다.
b) actuator의 엔드포인트도 블루 그린의 전략에 추가하는 것
지금의 application-{spring-profile}.yml 은 이렇게 되어있다.

management:
  endpoints:
    enabled-by-default: false
    web:
      base-path: /actuator
      exposure:
        include: health, logfile, metrics, prometheus

  server:
    port: 5959  # 이 부분을 ${ACTUATOR_PORT}로 바꾸고, docker-compose 의 환경변수로 주입받도록!

여기에서의 port 가 actuator 의 port 이므로, 이를 갈아껴주면 되는 것이다.!
예를 들어서 5959와 5960과 같이 말이다.
그리고 ip 테이블로 5959로 오는 요청을 8080은 5959로, 8081은 5960으로 연결시켜준다면
외부의 입장에서는 계속 5959 번호로 들어올 수 있게 되어 지금의 인프라 설정에서 다른 것들은 아무것도 바꾸지 않아도 된다.

---

💭 커비와 내가 내린 결론

문제를 해결하기 위한 간단한 방법 2가지가 떠올랐는데, 그중 무엇을 선택할지는
외부에 공개해도 문제가 없는 정보는 볼 통로를 만들어두어도 괜찮다.
vs 굳이 사용자에게 알려줄 필요가 없는 정보는 숨기는게 맞다.
이 두가지를 생각해봐야 할 것 같다.

만약 전자에 동의한다면,
actuator 포트는 어플리케이션 포트와 동일하게 가져가고, 엔드포인트를 uuid 같은 것으로 두는 것만으로도 해결책이 된다.
하지만 후자에 동의한다면,
actuator 포트 또한 blue-green 에 맞게 바꿔주는 것으로 해결할 수 있다.

커비와 나는 백종원과 안성재처럼 의견이 1대1로 갈렸으나,
변경의 포인트의 범위(전자는 actuator endpoint 가 바뀌면 lb 에서 핼스체크하는 uri & prometheus의 설정도 바꿔줘어 하지만,
후자는 docker-compose 파일이나 shell script 의 변경)을 고려하여 후자로 결정하게 되었다.
🧑🏻‍⚖️ 따라서, docker-compose 와 shell script 에 5959관련된 변경도 포함하도록 바꿔주어야 한다 🧑🏻‍⚖️

[skylar1220]

동시에 켜질 때 같은 폴더를 볼륨으로 마운트하면 우리가 예상하지 못하는 일이 발생하지는 않나요? - 2

2. ./application-${SPRING_PROFILE}.yml:/application.yml 부분은 문제가 발생함.

사실 SERVER_PORT 부분도 문제였음

1. 우리 호스트(ubuntu) applicaiton-prod.yml에 server.port 부분은 ${SERVER_PORT}로 되어있음

spring:
 profiles:
   active: prod
server:
 port: ${SERVER_PORT}

2. app-8080이 up되면 도커의 applicaion.yml port 부분이 8080으로 바뀌고, 호스트의 applicaiton-prod.yml 파일도 port: ${SERVER_PORT}가 아니라 port: 8080으로 바뀌게 됨.
   따라서 다음에 app-8081이 환경변수를 적용하려고 해도 ${SERVER_PORT}부분이 없어서 적용할 수 없는 문제 발생

spring:
 profiles:
   active: prod
server:
 port: 8080

결론

따라서 환경 변수가 적용된 yml을 호스트에 mount해주는 게 아니라,
호스트 파일 시스템의 application-prod.yml을 도커가 가져다가 환경 변수를 적용해서, 컨테이너의 application.yml에 적용하는 방법이 필요함

[skylar1220]

목표

1. 호스트에 application-prod.yml은 이 형태로 항상 유지 (마운트 안씀)

server:
 port: ${SERVER_PORT}

2. 각 app-8080, 8081 도커 컨테이너의 application.yml 파일에는 up했을 때 이렇게 들어가길 원함.

server:
 port: 8080 # 8081

순서

1. app-8080를 실행한다.
2. 도커 이미지를 받아서 도커 컨테이너(spring app)를 만든다.
3. 이 스프링을 실행할 때 application.yml이 필요한데 이 yml의 위치를

[skylar1220]

방법1: (불가능) 직접 도커 컨테이너에서 호스트 파일을 읽는다?

docker-compose.yml 파일을 수정하여 application.yml 파일을 호스트에서 컨테이너로 전달하는 대신, 환경 변수를 사용하여 컨테이너에서 사용할 수 있도록 한다? → 도커는 호스트를 읽을 수 없어서 불가능

services:
  app-8080:
    image: reviewme/review-me-app:release
    container_name: review-me-app
    ports:
      - "80:8080"
    environment:
      - SERVER_PORT=8080
      - TZ=Asia/Seoul
      - SPRING_PROFILES_ACTIVE=prod  # 활성화할 프로파일 설정
    command: >
      sh -c "java -jar /review-me-app.jar -Dspring.config.location=/path/to/application-${SPRING_PROFILES_ACTIVE}.yml"

방법 2. 컨테이너 시작 후 파일 복사하기

docker run -d --name app-8081 reviewme/review-me-app:release
docker cp /path/to/application-prod.yml app-8081:/application.yml

[skylar1220]

(최종) 방법 3. yml에 변경되는 port 부분만 다른 yml로 분리해서 import하기

1. 마운트를 하지 않으려고 하니 호스트 → 도커 컨테이너로 yml 파일을 가져오는 방법이 어려움
2. 마운트를 하지 않으려고 한 이유는, SERVER_PORT, ACTUATOR_PORT 등 외부에서 변수로 받아오는 부분때문이었음. 컨테이너마다 다른 변수를 갖는 applicaion.yml을 사용해야하기때문에.
3. 그렇다면 변수 부분을 분리하면, 마운트를 해도 된다. 따라서 변수 부분을 별도의 yml로 분리하면 해결!