무중단 배포환경 구축

새 버전 컨테이너를 먼저 띄워 헬스체크를 통과시킨 뒤 Nginx 라우팅을 전환하고, 마지막에 이전 컨테이너를 내리는 Blue/Green 무중단 배포를 리눅스 호스트 한 대에 직접 구성한다.

#1. 준비 사항

호스트 — Docker Engine 과 Compose 플러그인이 설치된 리눅스 한 대. Ubuntu 22.04 이상 또는 Amazon Linux 2023 을 기준으로 한다. 리눅스 호스트에 Docker Engine 을 설치하는 방법은 Docker 공식 문서를 참고한다.

docker --version
docker compose version

sudo dnf install -y docker
sudo systemctl enable --now docker
docker --version        # Docker version 25.0.14, build 0bab007
docker compose version  # docker: 'compose' is not a docker command.

V=$(curl -s https://api.github.com/repos/docker/compose/releases/latest \
    | grep -o '"tag_name": *"[^"]*"' | cut -d'"' -f4)

sudo mkdir -p /usr/local/lib/docker/cli-plugins
sudo curl -sSL "https://github.com/docker/compose/releases/download/${V}/docker-compose-linux-x86_64" \
  -o /usr/local/lib/docker/cli-plugins/docker-compose
sudo chmod +x /usr/local/lib/docker/cli-plugins/docker-compose

docker compose version  # Docker Compose version v5.5.1

사용할 이미지

애플리케이션 — Docker Compose 장에서 만든 visit-counter(MySQL 연동판) 를 그대로 쓴다. 그 장의 app/ 디렉터리를 이 호스트로 가져다 둔다.

포트

#2. 배포 흐름

JAR 준비  ─▶  deploy.sh
                1) 서비스 이미지 빌드            (build/ 디렉터리만 컨텍스트로)
                2) (선택) 레지스트리 업로드
                3) 지금 nginx 가 보고 있는 색을 읽어 반대쪽을 대상으로 정한다
                4) 쉬고 있는 쪽에 새 컨테이너 실행
                5) 새 컨테이너 헬스체크 — /actuator/health 가 200
                6) nginx 설정 교체 → nginx -t 검사 → reload
                7) nginx(80) 를 통해 다시 200 확인
                8) 잠깐 대기(드레인) 후 이전 컨테이너 제거

핵심은 "새 컨테이너가 정상(HTTP 200)임을 확인한 뒤에만 트래픽을 전환한다" 는 점이다. 5번에서 실패하면 전환 자체를 하지 않으므로 기존 서비스가 그대로 살아 있고, 7번에서 실패하면 설정을 되돌린다. 어느 쪽이든 이전 컨테이너는 끝까지 살려둔다.

#3. 사전 작업

#3-1. 사용자 계정 도커 그룹 추가

sudo usermod -aG docker "$USER"

# 변경 사항 적용 (재로그인 또는 아래 명령어)
newgrp docker

#3-2. 도커 네트워크 생성

Compose 가 띄우는 DB·Nginx 와, deploy.sh 가 docker run 으로 띄우는 blue/green 컨테이너가 같은 네트워크에 있어야 서로 컨테이너 이름으로 통신할 수 있다. 양쪽에서 함께 쓰므로 네트워크는 미리 만들어 둔다.

docker network create dsa_service_network

#4. 디렉터리 만들기

작업 디렉터리는 /service/docker 하나다. 아래 블록을 순서대로 실행한다.

# 1) /service 와 /service/docker 를 한 번에 만든다
sudo mkdir -p /service/docker

# 2) 이후 작업을 sudo 없이 하기 위해 소유자를 현재 사용자로 넘긴다
sudo chown -R "$USER":"$USER" /service

# 3) 하위 디렉터리 생성
cd /service/docker
mkdir -p build config/nginx volumes/mysql

완성된 구조는 다음과 같다.

/service/docker/
├── docker-compose.yml              # DB + Nginx
├── .env                            # Compose 가 읽는 DB 비밀번호
├── service.env                     # blue/green 컨테이너에 넘길 접속 정보
├── deploy.sh                       # 배포 스크립트
├── deploy.log                      # 배포 기록 (자동 생성, 누적)
├── build/                          # ← 도커 빌드 컨텍스트. 여기만 빌드에 들어간다
│   ├── Dockerfile-service
│   └── visit-counter-1.0.0.jar
├── config/nginx/                   # ← 전환용 Nginx 설정 2개
│   ├── default-blue-service.conf
│   └── default-green-service.conf
└── volumes/
    └── mysql/                      # MySQL 데이터

mkdir: cannot create directory ‘/service/docker’: No such file or directory

mkdir: cannot create directory ‘volumes’: Permission denied

chown: invalid user: ‘dsa:dsa’
chown: changing ownership of 'volumes': Operation not permitted

#5. 애플리케이션 JAR 준비

배포할 대상은 Docker Compose 장의 visit-counter 다. 그 장에서 만든 app/ 디렉터리(즉 settings.gradle, build.gradle, src/ 가 들어 있는 디렉터리)를 호스트로 옮겨 둔다. 여기서 필요한 것은 JAR 하나뿐 이므로 그 장의 Dockerfile 과 docker-entrypoint.sh 는 쓰지 않는다.

# 예: ~/visit-counter/app 에 소스를 둔 경우
cd ~/visit-counter/app
ls
# build.gradle  settings.gradle  src

호스트에 JDK 와 Gradle 을 설치하지 않고 컨테이너로 빌드한다.

docker run --rm \
  -v "$PWD":/build -w /build \
  gradle:8.14-jdk21 gradle bootJar --no-daemon

산출물을 확인하고 빌드 컨텍스트로 복사한다.

ls -l build/libs/visit-counter-1.0.0.jar

cp build/libs/visit-counter-1.0.0.jar /service/docker/build/

ERROR: failed to calculate checksum of ref ...:
"/visit-counter-1.0.0.jar": not found

rm: cannot remove 'build/libs': Permission denied

sudo chown -R "$USER":"$USER" build

#6. 서비스 이미지 — Dockerfile-service

deploy.sh 가 빌드하는 서비스 이미지다. 5절에서 JAR 을 복사해 둔 /service/docker/build/ 에 이 파일 하나만 더 만든다.

cd /service/docker/build

/service/docker/build/Dockerfile-service

FROM eclipse-temurin:21-jre

# curl: deploy.sh 가 컨테이너 안에서 헬스체크할 때 쓴다
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl && \
    rm -rf /var/lib/apt/lists/*

# 애플리케이션을 root 가 아닌 전용 계정으로 돌린다
RUN groupadd --system app && useradd --system --gid app --no-create-home app

WORKDIR /webservice

# 빌드 산출물 — 5절에서 build/ 로 복사해 둔 JAR
COPY visit-counter-1.0.0.jar app.jar

USER app
EXPOSE 8080

# exec form — java 가 PID 1 이 되어 docker stop 의 SIGTERM 을 직접 받는다
ENTRYPOINT ["java", "-jar", "/webservice/app.jar"]

#7. 데이터베이스와 Nginx

Compose 가 관리하는 것은 DB 와 Nginx 두 개뿐 이다. blue/green 컨테이너는 deploy.sh 가 docker run 으로 직접 띄운다. 배포마다 뜨고 지는 대상을 Compose 파일에 적어 두면, 파일에 적힌 상태와 실제 상태가 계속 어긋나기 때문이다.

#7-1. 비밀값 파일 — .env

cd /service/docker

cat > .env <<'EOF'
MYSQL_ROOT_PASSWORD=RootPassword123
MYSQL_PASSWORD=UserPassword456
EOF

chmod 600 .env

#7-2. docker-compose.yml

/service/docker/docker-compose.yml

services:

  database:
    image: 'mysql:8.4'
    container_name: 'dsa-mysql'
    # ports 를 열지 않는다. 접근이 필요한 것은 같은 네트워크의 컨테이너뿐이다.
    environment:
      - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
      - MYSQL_DATABASE=visitdb
      - MYSQL_USER=visituser
      - MYSQL_PASSWORD=${MYSQL_PASSWORD}
      - TZ=Asia/Seoul
    networks:
      - dsa_service_network
    volumes:
      - ./volumes/mysql:/var/lib/mysql
    healthcheck:
      # -h 127.0.0.1 로 TCP 를 확인한다.
      test: ["CMD", "mysqladmin", "ping", "-h", "127.0.0.1", "--silent"]
      interval: 10s
      timeout: 5s
      retries: 10
      start_period: 40s
    restart: unless-stopped

  nginx:
    image: 'nginx:1.30'
    container_name: 'dsa-nginx'
    ports:
      - '80:80'
    environment:
      - TZ=Asia/Seoul
    networks:
      - dsa_service_network
    restart: unless-stopped

networks:
  dsa_service_network:
    external: true
    name: dsa_service_network

network dsa_service_network declared as external, but could not be found

#7-3. 애플리케이션 접속 정보 — service.env

blue/green 컨테이너에 넘길 값이다. Compose 가 아니라 deploy.sh 의 docker run --env-file 이 읽는다.

cd /service/docker

cat > service.env <<'EOF'
SPRING_DATASOURCE_URL=jdbc:mysql://dsa-mysql:3306/visitdb
SPRING_DATASOURCE_USERNAME=visituser
SPRING_DATASOURCE_PASSWORD=UserPassword456
EOF

chmod 600 service.env

SPRING_DATASOURCE_PASSWORD 는 .env 의 MYSQL_PASSWORD 와 같은 값 이어야 한다. 호스트 이름 dsa-mysql 은 DB 컨테이너의 이름이다. 같은 도커 네트워크 안에서는 컨테이너 이름이 그대로 호스트 이름이 된다.

SPRING_DATASOURCE_PASSWORD='UserPassword456'

#8. Nginx 전환용 설정 파일

default.conf 를 blue용과 green용 2개 만들어 config/nginx/ 에 둔다. 배포할 때 deploy.sh 가 이 중 하나를 컨테이너 안으로 복사한다. 경로와 파일 이름이 스크립트와 정확히 맞아야 하므로 아래 명령으로 만든다.

cat > /service/docker/config/nginx/default-blue-service.conf <<'EOF'
upstream service {
    server blue-service:8080;
}

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    location / {
        proxy_pass http://service;
        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;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}
EOF

# green 용은 대상 이름 한 곳만 다르다. 손으로 고치지 말고 치환해서 만든다.
sed 's/blue-service/green-service/' \
  /service/docker/config/nginx/default-blue-service.conf \
  > /service/docker/config/nginx/default-green-service.conf

grep -n 'server .*-service' /service/docker/config/nginx/*.conf

마지막 grep 의 출력은 다음과 같아야 한다.

/service/docker/config/nginx/default-blue-service.conf:2:    server blue-service:8080;
/service/docker/config/nginx/default-green-service.conf:2:    server green-service:8080;

nginx: [emerg] host not found in upstream "green-service" in /etc/nginx/conf.d/default.conf:2

#9. 배포 스크립트 — deploy.sh

/service/docker/deploy.sh

#!/bin/bash
set -u

APP="visit-counter"
NETWORK="dsa_service_network"
NGINX="dsa-nginx"

BASE="/service/docker"
BUILD_DIR="$BASE/build"
NGINX_CONF_DIR="$BASE/config/nginx"
ENV_FILE="$BASE/service.env"
DEPLOY_LOG="$BASE/deploy.log"

# 전환 후 이전 컨테이너를 지우기 전에 기다릴 시간(초)
DRAIN_SECONDS=10

# 레지스트리에 올리고 싶을 때만 값을 준다.
#   REGISTRY=docker.io/<내계정> ./deploy.sh
REGISTRY="${REGISTRY:-}"

# 로그는 덧붙인다(-a). 덮어쓰면 실행할 때마다 지워져,
# 정작 필요한 "직전 실패의 기록" 이 남지 않는다.
exec > >(tee -a "$DEPLOY_LOG")
exec 2>&1

echo "===== $(date '+%Y-%m-%d %H:%M:%S') 배포 시작 ====="

TAG=$(date +%Y%m%d%H%M%S)

# ── 1. 서비스 이미지 빌드 ────────────────────────────────────
# 컨텍스트는 build/ 하나뿐이다. /service/docker 를 통째로 넘기면
# volumes/ 아래의 MySQL 데이터까지 데몬으로 전송된다.
echo "[INFO] 이미지를 빌드한다: $APP:$TAG"
docker build -t "$APP:$TAG" -f "$BUILD_DIR/Dockerfile-service" "$BUILD_DIR" || {
  echo "[ERROR] 이미지 빌드에 실패했다."; exit 1
}

# ── 2. (선택) 레지스트리 업로드 ──────────────────────────────
if [ -n "$REGISTRY" ]; then
  echo "[INFO] $REGISTRY/$APP:$TAG 로 업로드한다."
  docker tag "$APP:$TAG" "$REGISTRY/$APP:$TAG" || exit 1
  docker push "$REGISTRY/$APP:$TAG" || {
    echo "[ERROR] 업로드에 실패했다. docker login 을 했는지 확인한다."; exit 1
  }
else
  echo "[INFO] REGISTRY 가 비어 있어 업로드는 건너뛴다."
fi

# ── 3. 지금 서비스 중인 색을 nginx 설정에서 읽는다 ───────────
# 컨테이너 상태가 아니라 "트래픽이 실제로 어디로 가는가" 를 기준으로 정한다.
current=$(docker exec "$NGINX" cat /etc/nginx/conf.d/default.conf 2>/dev/null \
          | grep -oE '(blue|green)-service' | head -n 1)

if [ "$current" = "blue-service" ]; then
  new_target="green-service"; new_port=8081; old_target="blue-service"
else
  new_target="blue-service";  new_port=8080; old_target="green-service"
fi
echo "[INFO] 현재 대상: ${current:-없음(첫 배포)} / 새로 띄울 대상: $new_target(:$new_port)"

# ── 4. 같은 이름의 컨테이너가 남아 있으면 지운다 ─────────────
if docker inspect "$new_target" > /dev/null 2>&1; then
  echo "[INFO] 이전에 남은 $new_target 컨테이너를 제거한다."
  docker rm -f "$new_target" > /dev/null || exit 1
fi

# ── 5. 새 컨테이너 실행 ──────────────────────────────────────
echo "[INFO] $new_target 컨테이너를 실행한다."
docker run -d \
  --name "$new_target" \
  --network "$NETWORK" \
  -p "127.0.0.1:$new_port:8080" \
  --env-file "$ENV_FILE" \
  --log-opt max-size=10m --log-opt max-file=3 \
  "$APP:$TAG" > /dev/null || {
  echo "[ERROR] $new_target 실행에 실패했다."; exit 1
}

# ── 6. 새 컨테이너 헬스체크 ──────────────────────────────────
echo "[INFO] $new_target 헬스체크 (최대 60초)"
health=000
for i in $(seq 1 30); do
  # 앱이 죽어 컨테이너가 Exited 가 되면 더 기다릴 이유가 없다.
  if [ "$(docker inspect -f '{{.State.Running}}' "$new_target" 2>/dev/null)" != "true" ]; then
    echo "[ERROR] $new_target 컨테이너가 종료됐다."
    break
  fi
  # 아직 기동 중이거나 curl 이 실패하면 빈 문자열이 온다.
  # 숫자 비교 대신 문자열 비교를 쓰고, 빈 값은 000 으로 바꿔 둔다.
  health=$(docker exec "$new_target" \
           curl -s -o /dev/null -w '%{http_code}' \
           http://localhost:8080/actuator/health 2>/dev/null)
  health="${health:-000}"
  [ "$health" = "200" ] && break
  echo "[INFO] 대기 중 ($i/30) - 현재 $health"
  sleep 2
done

if [ "$health" != "200" ]; then
  echo "[ERROR] $new_target 가 200 을 돌려주지 않는다($health). 전환하지 않는다."
  # 진짜 원인은 긴 스택 트레이스 위쪽에 있다. 원인이 적히는 줄을 먼저 뽑는다.
  echo "[ERROR] ---- 원인 ----"
  docker logs "$new_target" 2>&1 | grep -m 4 -E 'Access denied|SQLState|FATAL' || true
  echo "[ERROR] ---- 애플리케이션 로그 (마지막 15줄) ----"
  docker logs --tail 15 "$new_target" 2>&1
  echo "[ERROR] 원인을 더 볼 수 있도록 $new_target 컨테이너는 지우지 않는다."
  echo "[ERROR]   docker logs $new_target 2>&1 | less"
  echo "[ERROR] 다음 배포가 4번 단계에서 이 컨테이너를 자동으로 치운다."
  exit 1
fi
echo "[INFO] $new_target 준비 완료 (HTTP 200)"

# ── 7. nginx 설정 교체 → 검사 → 리로드 ──────────────────────
echo "[INFO] nginx 설정을 $new_target 로 바꾼다."
docker exec "$NGINX" cp /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.bak

rollback() {
  echo "[WARN] nginx 설정을 이전 상태로 되돌린다."
  docker exec "$NGINX" cp /etc/nginx/conf.d/default.conf.bak /etc/nginx/conf.d/default.conf
  docker exec "$NGINX" nginx -s reload
  docker rm -f "$new_target" > /dev/null
}

docker cp "$NGINX_CONF_DIR/default-$new_target.conf" \
          "$NGINX:/etc/nginx/conf.d/default.conf" || {
  echo "[ERROR] 설정 파일 복사에 실패했다. $NGINX_CONF_DIR 를 확인한다."
  docker rm -f "$new_target" > /dev/null
  exit 1
}

if ! docker exec "$NGINX" nginx -t; then
  echo "[ERROR] 새 설정이 nginx 검사를 통과하지 못했다."
  rollback
  exit 1
fi

docker exec "$NGINX" nginx -s reload || {
  echo "[ERROR] 리로드에 실패했다."; rollback; exit 1
}

# ── 8. nginx(80) 를 통해 실제로 응답하는지 확인 ──────────────
# nginx -s reload 가 0 을 돌려준 것은 "마스터에 시그널을 보냈다" 는 뜻일 뿐,
# 새 설정이 적용됐다는 증명이 아니다. 응답으로 확인한다.
echo "[INFO] nginx 를 통해 응답을 확인한다."
via=000
for i in $(seq 1 10); do
  via=$(docker exec "$new_target" \
        curl -s -o /dev/null -w '%{http_code}' \
        "http://$NGINX/actuator/health" 2>/dev/null)
  via="${via:-000}"
  [ "$via" = "200" ] && break
  sleep 2
done

if [ "$via" != "200" ]; then
  echo "[ERROR] nginx 를 통한 응답이 $via 다. 전환을 취소한다."
  docker logs --tail 20 "$NGINX"
  rollback
  exit 1
fi
echo "[INFO] nginx 를 통한 응답 확인 (HTTP 200)"

# ── 9. 이전 컨테이너 정리 ────────────────────────────────────
# 리로드 직후에도 예전 워커 프로세스가 처리 중인 요청이 남아 있다.
# 바로 지우면 그 요청들이 502 로 끝난다.
echo "[INFO] 처리 중인 요청이 끝나도록 ${DRAIN_SECONDS}초 기다린다."
sleep "$DRAIN_SECONDS"

if docker inspect "$old_target" > /dev/null 2>&1; then
  echo "[INFO] 이전 컨테이너($old_target)를 내리고 제거한다."
  # rm -f 는 SIGKILL 이다. stop 으로 SIGTERM 을 보내야 앱이 남은 요청을 마무리한다.
  docker stop -t 30 "$old_target" > /dev/null
  docker rm "$old_target" > /dev/null
fi

# 태그가 밀려난 이미지 정리
docker image prune -f --filter "dangling=true" > /dev/null

echo "===== $(date '+%Y-%m-%d %H:%M:%S') 배포 완료: $new_target ($APP:$TAG) ====="

chmod +x /service/docker/deploy.sh

deploy.sh: line 42: [: : integer expression expected

#10. 첫 배포와 무중단 확인

#10-1. DB 와 Nginx 기동

cd /service/docker
docker compose up -d
docker compose ps

database 의 상태가 healthy 가 될 때까지 기다린다. 첫 기동은 40초 안팎 걸린다.

NAME         IMAGE         STATUS
dsa-mysql    mysql:8.4     Up 45 seconds (healthy)
dsa-nginx    nginx:1.30    Up 45 seconds

이 시점에 http://<호스트>/ 로 접속하면 Nginx 기본 페이지가 보인다. 아직 우리 설정이 들어가기 전이다.

배포 전 — 아직 upstream service 설정이 들어가기 전이다

#10-2. 첫 배포

./deploy.sh

마지막 줄이 배포 완료: blue-service 면 성공이다. 확인한다.

curl http://localhost/
# 방문 횟수: 1

docker ps --format '{{.Names}} {{.Status}}'
# blue-service   Up ...
# dsa-mysql      Up ... (healthy)
# dsa-nginx      Up ...

docker exec dsa-nginx grep 'server .*-service' /etc/nginx/conf.d/default.conf
#     server blue-service:8080;

#10-3. 두 번째 배포 — 끊기지 않는지 본다

터미널을 하나 더 열어 요청을 계속 보낸다.

while true; do
  curl -s -o /dev/null -w "%{http_code} " http://localhost/
  sleep 0.3
done

원래 터미널에서 다시 배포한다.

cd /service/docker
./deploy.sh

배포가 도는 동안 반복문 쪽을 지켜본다.

200 200 200 200 200 200 200 200 200 200 200 200 ...

전환 순간에도 200 만 이어진다. t3.small 에서 실제로 돌려보면 전환을 가로질러 93회 연속 200, 502 와 000 은 0회 였다. 끝나면 대상이 바뀌어 있다.

docker exec dsa-nginx grep 'server .*-service' /etc/nginx/conf.d/default.conf
#     server green-service:8080;

docker ps --filter name=-service --format '{{.Names}}'
# green-service      ← blue 는 정리됐다

배포 기록은 누적된다.

tail -n 30 /service/docker/deploy.log

#11. 실패하면 어떻게 되는가

일부러 실패시켜 본다. service.env 의 비밀번호를 틀리게 바꾸고 배포한다.

cd /service/docker
sed -i 's/^SPRING_DATASOURCE_PASSWORD=.*/SPRING_DATASOURCE_PASSWORD=wrong/' service.env
./deploy.sh

새 컨테이너는 뜨지만 DB 에 붙지 못한 Spring Boot 가 기동을 포기하고 종료한다. 앱이 PID 1 이므로 컨테이너도 함께 Exited 가 되고, 스크립트는 그것을 보고 기다림을 끝낸다. 종료 코드는 1 이다.

[INFO] 대기 중 (4/30) - 현재 000
[ERROR] blue-service 컨테이너가 종료됐다.
[ERROR] blue-service 가 200 을 돌려주지 않는다(000). 전환하지 않는다.
[ERROR] ---- 원인 ----
WARN 1 --- [main] org.hibernate.orm.jdbc.error : HHH000247: ErrorCode: 1045, SQLState: 28000
WARN 1 --- [main] org.hibernate.orm.jdbc.error : Access denied for user 'visituser'@'172.18.0.5' (using password: YES)
[ERROR] ---- 애플리케이션 로그 (마지막 15줄) ----
...
Caused by: org.hibernate.HibernateException: Unable to determine Dialect without JDBC metadata
...
[ERROR] 원인을 더 볼 수 있도록 blue-service 컨테이너는 지우지 않는다.

t3.small 에서 잰 이 실패는 12초 만에 끝났다. 앱이 죽으면 컨테이너가 Exited 가 되고, 스크립트가 그것을 보고 60초를 다 기다리지 않기 때문이다.

docker logs blue-service 2>&1 | grep -m1 'Access denied'

그 사이에도 서비스는 멀쩡하다.

curl http://localhost/
# 방문 횟수: 5        ← 이전 컨테이너가 계속 응답한다

docker exec dsa-nginx grep 'server .*-service' /etc/nginx/conf.d/default.conf
#     server green-service:8080;   ← 설정도 그대로다

비밀번호를 되돌리고 다시 배포하면 정상으로 돌아온다.

sed -i 's/^SPRING_DATASOURCE_PASSWORD=.*/SPRING_DATASOURCE_PASSWORD=UserPassword456/' service.env
./deploy.sh

docker ps -a --filter name=blue-service --format '{{.Names}} {{.Status}}'
# blue-service Exited (1) ...

docker logs --tail 100 blue-service

tail -n 60 /service/docker/deploy.log

#12. CI 도구에 연결하려면 (선택)

여기까지가 이 장의 실습이다. 배포를 사람이 실행했지만, deploy.sh 자체는 누가 실행해도 같게 동작한다. CI 도구를 붙인다는 것은 이 스크립트를 대신 실행할 주체를 하나 두는 일이다.

• GitHub Actions — 워크플로가 SSH 로 접속해 deploy.sh 를 실행한다. 서버에 CI 도구를 설치하지 않아도 된다. 구성은 GitHub Actions로 자동 배포하기 에 있다.

• Jenkins — 서버 안에서 돌기 때문에 준비할 것이 더 많다. 아래에 정리한다.

Jenkins 컨테이너로 이 스크립트를 실행하려면

Jenkins 를 컨테이너로 띄워 호스트의 도커를 다루게 하려면 최소 네 가지가 필요하다. 공식 이미지를 그대로 쓰면 하나도 충족되지 않는다.

1. 도커 CLI — jenkins/jenkins:lts-jdk21 에는 docker 명령이 없다. CLI 를 설치한 이미지를 따로 만들어야 한다.

2. 도커 소켓 — /var/run/docker.sock 을 마운트해야 컨테이너 안에서 호스트의 도커를 조작할 수 있다.

3. 소켓 접근 권한 — 소켓은 호스트의 docker 그룹 소유다. 컨테이너의 jenkins 사용자(UID 1000)를 그 그룹 GID 에 넣어줘야 한다.

4. 작업 디렉터리 — deploy.sh 와 build/, config/nginx/ 가 컨테이너 안에서도 같은 경로로 보여야 한다.

# 볼륨 디렉터리를 만들고, 호스트의 docker 그룹 GID 를 확인한다
mkdir -p /service/docker/volumes/jenkins
sudo chown -R 1000:1000 /service/docker/volumes/jenkins
getent group docker | cut -d: -f3

  jenkins:
    image: '<도커 CLI 를 설치해 직접 만든 이미지>'
    container_name: 'dsa-jenkins'
    ports:
      - '48080:8080'
    environment:
      - TZ=Asia/Seoul
    group_add:
      - '<위에서 확인한 docker 그룹 GID>'
    networks:
      - dsa_service_network
    volumes:
      - ./volumes/jenkins:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
      - /service/docker:/service/docker

초기 화면은 잠겨 있고, 잠금 해제 암호는 컨테이너 안에 있다.

docker exec dsa-jenkins cat /var/jenkins_home/secrets/initialAdminPassword

http://<호스트>:48080 에 접속해 이 값을 입력하고, 권장 플러그인 설치 → 관리자 계정 생성 → 작업(Freestyle) 생성 → 빌드 스텝에 /service/docker/deploy.sh 를 넣는 순서로 진행한다.

Jenkins 첫 화면 — 잠금 해제 암호는 컨테이너 안 파일에 있다

/var/run/docker.sock 마운트는 호스트 루트 권한을 넘겨주는 것과 같다. 그 소켓에 접근할 수 있으면 호스트의 아무 디렉터리나 마운트한 특권 컨테이너를 만들 수 있다. Jenkins 에 작업을 만들 수 있는 사람은 곧 호스트를 장악할 수 있는 사람이 된다.

학습용 서버라면 감수할 수 있지만, 공용 서버에서는 빌드 전용 사용자·별도 호스트·소켓 프록시 같은 대책 없이 이렇게 두지 않는다.

#13. 정리

cd /service/docker

# blue/green 컨테이너
docker rm -f blue-service green-service 2>/dev/null

# DB 와 Nginx
docker compose down

# 네트워크
docker network rm dsa_service_network

데이터까지 지우려면 volumes/mysql 을 삭제한다. MySQL 이 root 소유로 만든 파일이 섞여 있으므로 sudo 가 필요하다.

sudo rm -rf /service/docker/volumes/mysql