실제 서버 운영에서는 개발 환경과 운영 환경을 동일하게 사용할 수 없습니다.
개발자가 테스트하는 환경과 실제 사용자가 접속하는 Production 환경은 목적이 다르기 때문입니다.
잘못된 구조:
Development 설정
↓
Production 서버 적용
↓
보안 문제
↓
장애 발생
예:
개발 환경:
- Debug 활성화
- 전체 Port 공개
- 테스트 Database 사용
운영 환경:
- Debug 비활성화
- 보안 강화
- 실제 Database 사용
Docker Compose에서는 환경별 설정 파일을 분리하여 관리할 수 있습니다.
기본 구조:
Development
↓
docker-compose.dev.yml
Production
↓
docker-compose.prod.yml
이번 글에서는 Docker Compose 환경 분리 개념부터 Compose Override, 환경 변수 관리, Development·Production 구성 방법, 실제 서버 운영 구조까지 알아보겠습니다.
Docker Compose 환경 분리가 필요한 이유
하나의 Compose 파일만 사용하면 환경별 설정 관리가 어렵습니다.
예:
ports:
- "3000:3000"
개발에서는 필요하지만 Production에서는 불필요할 수 있습니다.
또 다른 문제:
개발 Database
↓
운영 Database
↓
잘못 연결 위험
따라서 환경별 설정을 분리해야 합니다.
Docker Compose 환경 구성 방식
일반적인 구조:
project
├── docker-compose.yml
├── docker-compose.dev.yml
├── docker-compose.prod.yml
└── .env
역할:
기본 설정
docker-compose.yml
공통 설정 관리
개발 환경
docker-compose.dev.yml
테스트용 설정
운영 환경
docker-compose.prod.yml
Production 설정
Docker Compose 기본 파일 구성
docker-compose.yml:
services:
app:
image: my-app
networks:
- backend
networks:
backend:
공통 설정:
- Service 이름
- Network
- 기본 Image
Docker Compose Development 환경 구성
docker-compose.dev.yml:
services:
app:
environment:
NODE_ENV: development
ports:
- "3000:3000"
volumes:
- ./src:/app/src
특징:
- Source Code Mount
- Debug 활성화
- 빠른 수정
구조:
Host Source
↓
Container
↓
실시간 반영
Docker Compose Production 환경 구성
docker-compose.prod.yml:
services:
app:
environment:
NODE_ENV: production
restart:
unless-stopped
특징:
- Debug 제거
- Restart 적용
- 안정성 강화
Docker Compose 환경 실행 방법
Development 실행:
docker compose \
-f docker-compose.yml \
-f docker-compose.dev.yml \
up -d
동작:
기본 설정
+
개발 설정
↓
Development 환경
Production 실행:
docker compose \
-f docker-compose.yml \
-f docker-compose.prod.yml \
up -d
동작:
기본 설정
+
운영 설정
↓
Production 환경
Docker Compose Override 방식
Docker Compose는 기본적으로 override 파일을 지원합니다.
기본:
docker-compose.yml
자동 적용:
docker-compose.override.yml
실행:
docker compose up -d
자동으로:
기본 파일
+
Override 파일
결합됩니다.
Docker Compose Environment 분리
환경 변수도 분리해야 합니다.
개발:
.env.dev
DATABASE_HOST=dev-db
DATABASE_NAME=test
운영:
.env.prod
DATABASE_HOST=prod-db
DATABASE_NAME=production
실행:
Development:
docker compose --env-file .env.dev up -d
Production:
docker compose --env-file .env.prod up -d
Docker Compose Database 환경 분리
Database는 반드시 분리해야 합니다.
개발:
Application
↓
Test Database
운영:
Application
↓
Production Database
잘못된 구조:
개발 서버
↓
운영 Database 연결
위험:
- 데이터 손상
- 테스트 데이터 입력
- 서비스 장애
Docker Compose Volume 환경 분리
Volume도 분리해야 합니다.
Development:
volumes:
- dev-data:/data
Production:
volumes:
- prod-data:/data
구조:
개발 데이터
≠
운영 데이터
Docker Compose Port 환경 분리
개발:
ports:
- "3000:3000"
운영:
ports:
- "80:80"
또는:
Database Port
외부 공개 X
Docker Compose Debug 설정 분리
개발:
DEBUG=true
운영:
DEBUG=false
이유:
Production에서 Debug 정보 노출은 보안 위험입니다.
Docker Compose Image 환경 분리
개발:
image: my-app:dev
운영:
image: my-app:v1.0.0
장점:
- 테스트 가능
- 안정적인 배포
- Rollback 가능
Docker Compose CI/CD와 환경 분리
자동 배포 환경:
Git Push
↓
CI Build
↓
Test Environment
↓
Production Deploy
구조:
develop branch
↓
Development
main branch
↓
Production
Docker Compose Production 환경 체크리스트
배포 전 확인:
Environment:
운영 변수 적용
Database:
Production DB 연결
Volume:
운영 데이터 유지
Security:
Secret 적용
Monitoring:
상태 확인 가능
Docker Compose 환경 분리 Best Practice
추천 구조:
project
├── docker-compose.yml
├── docker-compose.dev.yml
├── docker-compose.prod.yml
├── .env.dev
├── .env.prod
└── secrets
관리 원칙:
- 공통 설정 분리
- 환경별 설정 분리
- Database 분리
- Volume 분리
- Secret 분리
자주 묻는 질문
Compose 파일을 하나만 사용해도 되나요?
가능하지만 Production에서는 환경 분리를 권장합니다.
개발과 운영 Database를 같이 사용하면 안 되나요?
위험합니다.
데이터 보호를 위해 분리하는 것이 좋습니다.
docker-compose.override.yml은 언제 사용하나요?
개발 환경에서 기본 설정을 덮어쓸 때 많이 사용합니다.
환경 분리는 CI/CD에도 필요한가요?
필수에 가깝습니다.
자동 배포 과정에서 환경별 설정이 필요합니다.
마무리
Docker Compose 환경 분리는 안정적인 서비스 운영을 위한 기본 구조입니다.
개발 환경과 Production 환경을 분리하면 다음 장점이 있습니다.
안전한 테스트
↓
예측 가능한 배포
↓
장애 감소
↓
쉬운 관리
Production 서버에서는 반드시 환경별 Compose 파일, Environment, Database, Volume, Secret을 분리하는 구조를 사용하는 것이 좋습니다.
다음 글에서는 자동 배포 환경 구축을 위한 Docker Compose CI/CD 배포 자동화 방법을 알아보겠습니다.