Production 서버에 코드를 배포하기 전에 반드시 확인해야 하는 과정이 있습니다.
바로 테스트입니다.
자동 배포 시스템에서 가장 위험한 상황은 다음과 같습니다.
개발자가 코드 수정
↓
자동 배포 실행
↓
Production 반영
↓
서비스 오류 발생테스트 과정이 없다면 작은 코드 변경도 전체 서비스 장애로 이어질 수 있습니다.
CI/CD 환경에서는 배포 전에 자동 테스트 단계를 추가합니다.
기본 구조:
Git Push
↓
CI 실행
↓
Docker Build
↓
Container 실행
↓
Test 진행
↓
성공
↓
Deploy이번 글에서는 Docker Compose 테스트 환경 구성부터 Container 테스트, Database 테스트, Healthcheck 검증, CI Pipeline 연결까지 알아보겠습니다.
Docker Compose 테스트 자동화란?
테스트 자동화는 사람이 직접 확인하던 과정을 Pipeline이 대신 실행하는 방식입니다.
기존 방식:
개발자
↓
서버 실행
↓
직접 확인
↓
배포자동화 방식:
Git Push
↓
자동 Test
↓
결과 확인
↓
배포 결정테스트 대상:
- Docker Build 성공 여부
- Container 실행 여부
- Application 동작
- Database 연결
- API 응답
- Service 상태
Docker Compose Test 환경 구조
운영 환경과 테스트 환경은 분리해야 합니다.
구조:
Development
↓
Test Environment
↓
Production예:
docker-compose.yml
공통 설정
docker-compose.test.yml
테스트 설정
docker-compose.prod.yml
운영 설정Docker Compose Test Compose 파일 작성
docker-compose.test.yml:
services:
app:
image: my-app:test
environment:
NODE_ENV: test
database:
image: mysql:8
environment:
MYSQL_DATABASE: test구조:
Test Application
↓
Test DatabaseProduction Database와 완전히 분리합니다.
Docker Compose Container 실행 테스트
첫 번째 테스트:
Container 정상 실행 확인
실행:
docker compose -f docker-compose.test.yml up -d확인:
docker compose ps성공:
app
running실패:
Exited (1)Docker Compose Healthcheck 테스트
Healthcheck는 자동 테스트의 기본입니다.
설정:
healthcheck:
test:
- CMD
- curl
- localhost:3000
interval: 10s
retries: 3검증:
docker compose ps결과:
healthyDocker Compose API 테스트 자동화
Application이 정상 응답하는지 확인합니다.
예:
curl http://localhost:3000/api/health정상:
{
"status":"ok"
}실패:
500 ErrorCI에서는 실패 처리:
exit 1Docker Compose Database 연결 테스트
Application과 Database 연결을 확인합니다.
테스트:
Application
↓
Database Connection
↓
Query 실행확인:
- Connection 성공
- Migration 실행
- Table 생성
예:
npm run migration:testDocker Compose Migration 테스트
Database 변경 작업도 테스트해야 합니다.
구조:
Migration File
↓
Test Database 적용
↓
오류 확인예:
npm run migrate성공:
Migration Complete실패:
Migration ErrorDocker Compose Unit Test 연결
Application 코드 테스트도 함께 실행합니다.
예:
npm test구조:
Source Code
↓
Unit Test
↓
Container Test
↓
DeployDocker Compose GitHub Actions 테스트 Pipeline
Workflow 예:
name: Test
on:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Start Container
run: docker compose up -d
- name: Test
run: npm test동작:
Pull Request 생성
↓
Test 실행
↓
성공 여부 확인Docker Compose Build 테스트
Image Build 오류도 배포 전에 확인합니다.
실행:
docker compose build확인:
- Dockerfile 오류
- Package 설치 오류
- Build 실패
Docker Compose Security Test
Production 배포 전 보안 검사도 가능합니다.
확인:
- 취약한 Image
- 노출 Port
- Secret 포함 여부
예:
docker scout cvesDocker Compose 테스트 실패 대응
테스트 실패:
Pipeline 실패
↓
Deploy 중단확인:
- Build Log
docker compose build- Container Log
docker compose logs- Test Result
- Code 수정
Docker Compose Test와 Production 배포 연결
최종 구조:
Developer
↓
Git Push
↓
CI Test
↓
Build
↓
Health Check
↓
Production Deploy중요:
Test 성공 전에는 Production 배포를 하지 않습니다.
Docker Compose 테스트 Best Practice
운영 추천:
- Test 환경 분리
- Database 별도 구성
- Healthcheck 사용
- API Test 추가
- Migration 검증
- Build Test 실행
권장 Pipeline:
Code Commit
↓
Unit Test
↓
Docker Build
↓
Container Test
↓
Security Test
↓
Deploy자주 묻는 질문
테스트 없이 자동 배포하면 안 되나요?
가능하지만 Production 장애 위험이 크게 증가합니다.
Test Database는 운영 Database와 같이 사용해도 되나요?
권장하지 않습니다.
테스트 전용 Database를 사용하는 것이 안전합니다.
Docker Compose도 자동 테스트가 가능한가요?
가능합니다.
CI/CD Pipeline과 연결하면 자동 검증할 수 있습니다.
테스트가 모두 통과하면 안전한가요?
테스트는 오류 가능성을 줄이는 과정이며 Monitoring과 Backup도 함께 필요합니다.
마무리
Docker Compose 테스트 자동화는 안정적인 CI/CD 환경을 만드는 핵심 단계입니다.
최종 Pipeline:
Git Push
↓
자동 Test
↓
Docker Build
↓
Container 검증
↓
Health Check
↓
Production Deploy이 구조를 적용하면 문제가 있는 코드가 Production 서버에 배포되는 것을 방지할 수 있습니다.
다음 글에서는 서비스 중단을 최소화하는 배포 방식인 Docker Compose Blue Green 배포 전략을 알아보겠습니다.