Docker Compose로 개발/운영 환경 분리하기

핵심 요약: Docker Compose의 오버라이드 기능을 사용하면 하나의 기본 설정 파일에 환경별 설정을 덮어씌워 개발/운영 환경을 깔끔하게 분리할 수 있습니다.

Docker Compose를 사용하면 개발 환경과 운영 환경을 깔끔하게 분리할 수 있습니다. 이 글에서는 환경별 설정 분리 전략과 민감한 정보 관리 방법을 소개합니다.

목차

1. 왜 환경 분리가 필요한가?
2. Docker Compose 멀티 환경 파일 구조
3. 공통 설정 작성법
4. 개발 환경 오버라이드
5. 운영 환경 오버라이드
6. 환경 변수 관리 전략
7. Makefile 자동화
8. 보안 설정

왜 환경 분리가 필요한가?

실제 프로젝트에서는 개발용 API와 운영용 API가 다른 경우가 많습니다:

환경	특징
개발	테스트넷, 모의투자 API, 디버그 로깅
운영	메인넷, 실거래 API, 최소 로깅

 

이런 설정들을 코드에 하드코딩하면 배포 시 실수가 발생하기 쉽습니다. Docker Compose의 오버라이드 기능을 활용하면 이 문제를 해결할 수 있습니다.

파일 구조

project/
├── docker-compose.yml          # 공통 설정
├── docker-compose.dev.yml      # 개발 환경 오버라이드
├── docker-compose.prod.yml     # 운영 환경 오버라이드
├── .env.example                # 환경 변수 예시 (git 커밋)
├── .env.dev                    # 개발 환경 변수 (git 무시)
└── .env.prod                   # 운영 환경 변수 (git 무시)

1. 공통 설정 (docker-compose.yml)

모든 환경에서 공유하는 기본 설정을 정의합니다:

services:
  api:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "--spider", "http://localhost:8080/health"]
      interval: 30s
      timeout: 3s
      retries: 3

2. 개발 환경 오버라이드 (docker-compose.dev.yml)

개발 전용 설정을 추가합니다:

services:
  api:
    container_name: myapp-api-dev
    environment:
      - API_URL=https://api-testnet.example.com
      - API_KEY=${DEV_API_KEY}
      - LOG_LEVEL=debug

3. 운영 환경 오버라이드 (docker-compose.prod.yml)

운영 전용 설정과 리소스 제한을 추가합니다:

services:
  api:
    container_name: myapp-api-prod
    environment:
      - API_URL=https://api.example.com
      - API_KEY=${PROD_API_KEY}
      - LOG_LEVEL=info
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 512M

실행 방법

# 개발 환경
docker compose -f docker-compose.yml -f docker-compose.dev.yml up

# 운영 환경
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

환경 변수 관리

.env 파일 자동 로딩

Docker Compose는 같은 디렉토리의 .env 파일을 자동으로 읽습니다. 별도 설정 없이 ${VARIABLE} 형태로 사용할 수 있습니다.

환경별 .env 파일 사용

기본 .env 대신 다른 파일을 사용하려면:

# 방법 1: --env-file 옵션
docker compose --env-file .env.dev up

# 방법 2: compose 파일에서 지정
services:
  api:
    env_file:
      - .env.dev

민감 정보 분리 전략

compose 파일에 넣을 것 (git 커밋):

• API URL, 엔드포인트
• 포트 번호
• 로그 레벨
• 리소스 제한

.env 파일에 넣을 것 (git 무시):

• API 키, 시크릿
• 토큰
• 패스워드

Makefile로 간편화

매번 긴 명령어를 입력하기 번거로우니 Makefile을 활용합니다:

.PHONY: docker-dev docker-prod docker-down

docker-dev:
    docker compose -f docker-compose.yml -f docker-compose.dev.yml up --build

docker-prod:
    docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build

docker-down:
    docker compose down

이제 간단히 실행할 수 있습니다:

make docker-dev   # 개발 환경 실행
make docker-prod  # 운영 환경 실행
make docker-down  # 컨테이너 종료

.gitignore 설정

민감한 환경 파일이 git에 커밋되지 않도록 합니다:

# Environment files
.env
.env.dev
.env.prod
.env.local

단, .env.example은 커밋하여 필요한 변수를 문서화합니다.

정리

항목	설명
docker-compose.yml	공통 설정 (빌드, 포트, 헬스체크)
docker-compose.dev.yml	개발 환경 오버라이드
docker-compose.prod.yml	운영 환경 오버라이드
.env.example	필요한 환경 변수 목록 (git 커밋)
.env.dev, .env.prod	실제 환경 변수 (git 무시)
Makefile	명령어 간편화

 

이 구조를 사용하면:

• 환경별 차이가 파일로 명확히 보임
• 민감 정보가 git에 노출되지 않음
• 배포 시 실수 방지
• 새 팀원도 .env.example만 보면 필요한 설정을 알 수 있음

마무리

Docker Compose의 오버라이드 기능을 활용하면 복잡한 멀티 환경 설정을 깔끔하게 관리할 수 있습니다. 핵심은 공통 설정과 환경별 설정을 분리하고, 민감한 정보는 .env 파일로 격리하는 것입니다.

이 패턴은 CI/CD 파이프라인과도 잘 어울립니다. GitHub Actions나 GitLab CI에서 환경별 .env 파일만 주입하면 동일한 Compose 파일로 다양한 환경에 배포할 수 있습니다.