# [Docker Compose 실습] 현재 docker-compose.yml 진단하기
- 현재 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경고가 나오는지 확인한다.app과db의 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에서versionobsolete 경고를 확인했다. -
db컨테이너에 앱 전용 환경 변수가 들어가는 것을 확인했다. - 앱의 DB URL이 컨테이너 환경에서는
db:5432를 사용해야 한다는 점을 확인했다. - DB 볼륨이 있으면
schema.sql이 매번 다시 실행되지 않는다는 점을 확인했다. - Dockerfile의 JAR 파일명이
build.gradle버전과 맞는지 점검 대상에 올렸다.
이 체크리스트가 끝나면 다음 문서에서 Compose 파일 자체를 1차로 정리한다.