Docker Compose와 로컬 운영 환경
3줄 요약
- Docker Compose는 Spring, MySQL, Redis 같은 운영 의존성을 로컬에서 반복 재현해 개발 환경 차이와 운영 설정 사고를 줄이는 도구다.
- 핵심은 Compose를 운영 대체재로 쓰는 것이 아니라 service, network, volume, env, healthcheck의 계약을 로컬에서 검증하는 것이다.
- 백엔드 개발자는 Compose 파일로 의존성 주소, 데이터 보존 범위, 환경 변수, 초기화 순서, reset 절차를 명확히 남겨야 한다.
핵심 정리
- Compose service는 하나의 실행 단위다.
api, mysql, redis처럼 이름을 붙이면 같은 Compose network 안에서 service name으로 접근할 수 있다.
- Compose network에서는
localhost가 container 자기 자신을 뜻한다. Spring container에서 MySQL에 붙으려면 jdbc:mysql://mysql:3306/app처럼 service name을 써야 한다.
- Volume은 로컬 DB 데이터와 Redis 데이터가 container 재생성 후에도 남을지 결정한다. 테스트를 깨끗하게 다시 시작하려면 reset 절차도 함께 있어야 한다.
.env.local, env_file, environment는 local config를 주입하는 방법이다. 운영 Secret을 local 파일에 복사하거나 repository에 올리면 안 된다.depends_on은 시작 순서를 도울 뿐 애플리케이션 readiness를 완전히 보장하지 않는다. healthcheck와 Spring 재시도, migration 순서를 함께 설계해야 한다.- 재현 가능한 로컬 환경은
docker compose config, 고정 image version, seed data, migration, reset 명령을 포함한다.
헷갈리는 지점
- Compose가 돌아가면 운영과 같다고 생각하기 쉽다.
- 핵심은 Compose가 운영 의존성의 축소판일 뿐, 운영의 권한, 네트워크, 장애 규모, 백업 정책까지 대체하지는 않는다는 점이다.
depends_on이 있으면 DB가 준비된 뒤 Spring이 시작된다고 오해하기 쉽다.
- 핵심은 container process 시작과 DB connection 가능 상태는 다르다는 점이다.
- local
.env를 운영 Secret 관리처럼 생각하기 쉽다.
- 핵심은 local env는 재현을 위한 값이고, 운영 Secret은 접근 권한, 회전, 감사가 필요한 별도 자산이라는 점이다.
확인 질문
- Compose 로컬 환경에서 가장 먼저 확인할 계약은 무엇인가?
- service 이름, network 접근 주소, volume 보존 범위, environment key, healthcheck, reset 절차다.
- Spring container가 MySQL에
localhost로 붙으면 왜 실패할 수 있는가?
- container 내부의
localhost는 MySQL container가 아니라 Spring container 자신을 가리키기 때문이다.
- 로컬 환경 재현성을 높이려면 무엇을 문서화해야 하는가?
- 실행 명령, image version, env sample, migration/seed 순서, health 확인, 로그 확인, 데이터 reset 방법이다.