Docker Compose
Docker Compose는 여러 컨테이너 서비스를 하나의 `compose.yml` 파일로 정의하고 함께 실행하는 도구입니다. 단일 컨테이너를 넘어서 애플리케이션 전체를 서비스 집합으로 다루게 해 주는 얇은 오케스트레이션 계층입니다.
▶아키텍처 다이어그램
🔍 구조 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
웹 서버, API, 데이터베이스, 캐시를 각각 `docker run`으로 띄우면 명령이 길어지고, 포트·환경 변수·볼륨·네트워크를 사람이 매번 맞춰야 합니다. 순서가 조금만 어긋나도 API가 DB보다 먼저 떠서 실패하고, 팀원마다 실행 방법이 달라져 재현성이 깨집니다. 멀티 컨테이너 구성을 수동 명령으로 유지하는 것은 금방 한계에 부딪힙니다.
컨테이너가 단일 프로세스 실행 단위로 자리잡자, 실제 애플리케이션은 늘 여러 컨테이너의 조합이라는 사실이 더 도드라졌습니다. 개발 환경에서 특히 '이 프로젝트를 켜는 표준 명령 하나'가 필요했고, Compose가 그 역할을 맡았습니다. 대규모 클러스터 오케스트레이션 이전에도 작은 서비스 묶음을 정의하는 선언 계층은 필요했습니다.
Compose 파일에는 서비스별 이미지나 빌드 방법, 포트, 환경 변수, 볼륨, 네트워크 연결이 선언됩니다. `docker compose up`을 실행하면 Compose가 프로젝트 이름을 기준으로 필요한 네트워크와 볼륨을 만들고, 각 서비스를 그 규칙에 맞게 기동합니다. 서비스 이름은 곧 네트워크 DNS 이름이 되므로, `api`가 `db`를 이름으로 바로 찾을 수 있습니다.
웹과 DB를 함께 정의하기
services:
web:
build: .
ports:
- "3000:3000"
environment:
DB_HOST: db
depends_on:
db:
condition: service_healthy
db:
image: postgres:16
volumes:
- db-data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
retries: 5
volumes:
db-data: {}서비스, 볼륨, 헬스 체크를 한 파일에 묶으면 실행 방법이 문서가 아니라 선언 그 자체가 됩니다.
서비스 이름이 곧 내부 DNS 이름이 됩니다
services:
api:
image: my-api:latest
worker:
image: my-worker:latest
environment:
API_BASE_URL: http://api:8080같은 Compose 프로젝트 안에서는 `api` 같은 서비스 이름이 내부 호스트명으로 동작하므로, 고정 IP를 직접 관리할 필요가 없습니다.
Docker Compose와 Dockerfile은 모두 텍스트 파일로 보이지만 책임이 다릅니다. Dockerfile은 하나의 이미지를 빌드하는 규칙이고, Compose는 여러 이미지나 빌드 결과를 어떻게 함께 실행할지 정의합니다. 또한 Compose는 컨테이너 런타임 자체가 아니라, 런타임 위에서 여러 서비스를 프로젝트 단위로 묶어 주는 도구입니다.
실무에서는 로컬 개발과 통합 테스트, 작은 운영 환경에서 Compose가 특히 강합니다. 각 서비스의 포트와 환경 변수, 데이터 저장 위치를 코드로 남겨 온보딩 문서를 줄이고, `docker compose up` 한 번으로 같은 스택을 재현할 수 있습니다. 다만 Compose를 잘 쓰려면 서비스 경계를 억지로 한 파일에 몰아넣기보다, 함께 기동해야 할 묶음이 무엇인지 먼저 분명히 해야 합니다.