Docker Compose 정리 (5/9)

이전 편: 4. 04 환경 변수와 시작 순서 설계

다음 편: 6. 02 Compose 파일 1차 정리하기

# [Docker Compose 실습] 현재 docker-compose.yml 진단하기

Compose 파일을 고치기 전에 먼저 진단해야 한다. 바로 수정부터 시작하면 "왜 이 줄을 지웠는지", "왜 이 값은 남겼는지"가 흐려진다. 이번 실습의 목표는 현재 docker-compose.yml에서 유지할 것과 정리할 것을 분리하는 것이다.

현재 파일의 구조

현재 Compose 파일은 두 서비스를 정의한다.

services:
  app:
    build: .
    ports:
      - "8081:80"
    env_file: .env
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:15-alpine
    ports:
      - "5432:5432"
    env_file:
      - .env
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}" ]
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./schema.sql:/docker-entrypoint-initdb.d/schema.sql:ro

방향은 맞다. 앱과 DB를 분리했고, DB 데이터는 볼륨에 남기고, 앱은 DB healthcheck를 기다린다. 문제는 환경 변수 범위와 오래된 Compose 관성, Dockerfile 실행 파일명 같은 세부 지점이다.

진단 명령 실행

프로젝트 루트에서 먼저 Compose가 파일을 어떻게 해석하는지 확인한다.

docker compose config

이 명령으로 확인할 것은 값 자체가 아니라 구조다.

  • version 경고가 나오는지 확인한다.
  • appdb의 environment에 어떤 변수 묶음이 들어갔는지 본다.
  • networks.default.name이 어떻게 만들어졌는지 본다.
  • volumes의 실제 이름을 본다.
  • ports가 호스트 포트와 컨테이너 포트로 어떻게 풀렸는지 본다.
출력 붙여넣기 금지

이 프로젝트의 .env에는 DB 비밀번호, AWS key, JWT secret, Admin 계정 정보가 있다. docker compose config 출력은 이 값을 펼쳐 보여주므로 외부에 공유하면 안 된다.

진단 결과

항목판단이유
app, db 서비스 분리유지앱 서버와 DB 서버가 별도 프로세스이므로 분리하는 것이 맞다
depends_on + service_healthy유지DB가 연결 가능한 상태가 된 뒤 앱을 시작할 수 있다
postgres_data 볼륨유지DB 데이터를 컨테이너 삭제와 분리한다
app_storage 볼륨조건부 유지로컬 파일 저장을 쓸 가능성이 있으면 필요하다
version: '3.8'제거최신 Compose에서는 obsolete 경고가 난다
db.env_file: .env정리DB에 AWS/JWT/Admin 값까지 들어간다
app.env_file: .env정리 권장앱에 필요한 변수만 명시하는 편이 안전하다
container_name제거 권장Compose의 프로젝트 이름 기반 네이밍과 스케일링, 복수 실행을 방해할 수 있다
db.ports: "5432:5432"선택호스트 DB 클라이언트가 필요하면 유지, 앱 내부 통신만 필요하면 제거 가능
schema.sql 마운트유지하되 주의DB 볼륨이 이미 초기화되어 있으면 다시 실행되지 않는다
Dockerfile JAR 이름수정 필요build.gradle 버전과 PROJECT_VERSION 값이 다르다

유지할 좋은 설정

현재 파일에서 가장 좋은 부분은 DB healthcheck다.

depends_on:
  db:
    condition: service_healthy

단순히 depends_on: [db]만 쓰면 DB 컨테이너가 시작된 뒤 앱 컨테이너가 시작된다. 하지만 PostgreSQL이 실제 연결을 받을 준비가 되었는지는 보장하지 않는다. 현재처럼 service_healthy를 쓰면 pg_isready가 성공한 뒤 앱이 올라간다.

이 설정은 지우지 않는다. 오히려 정리 후에도 유지해야 하는 핵심이다.

가장 먼저 고칠 대상

첫 번째 정리 대상은 version과 환경 변수 범위다.

version: '3.8'

이 줄은 최신 Compose에서 필요하지 않고, 현재 경고를 만든다. 제거한다.

그다음은 env_file이다.

db:
  env_file:
    - .env

DB 컨테이너에 필요한 것은 POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD뿐이다. .env 전체를 넣으면 필요 없는 민감정보까지 DB 컨테이너에 들어간다.

정리 방향은 다음과 같다.

db:
  environment:
    POSTGRES_DB: ${POSTGRES_DB}
    POSTGRES_USER: ${POSTGRES_USER}
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}

app도 같은 기준으로 정리한다. 앱에는 Spring, AWS, JWT, Admin, JVM 관련 변수만 넘긴다.

점검 체크리스트

  • docker compose config에서 version obsolete 경고를 확인했다.
  • db 컨테이너에 앱 전용 환경 변수가 들어가는 것을 확인했다.
  • 앱의 DB URL이 컨테이너 환경에서는 db:5432를 사용해야 한다는 점을 확인했다.
  • DB 볼륨이 있으면 schema.sql이 매번 다시 실행되지 않는다는 점을 확인했다.
  • Dockerfile의 JAR 파일명이 build.gradle 버전과 맞는지 점검 대상에 올렸다.

이 체크리스트가 끝나면 다음 문서에서 Compose 파일 자체를 1차로 정리한다.