현대적인 서버 운영에서는 코드를 수정할 때마다 직접 서버에 접속해서 배포하는 방식보다 자동화된 배포 시스템을 사용하는 것이 일반적입니다.
기존 방식:
개발자
↓
서버 접속
↓
Git Pull
↓
Docker Build
↓
Container 재시작
문제:
- 배포 과정 반복
- 실수 가능성 증가
- 작업 시간 증가
- 배포 기록 관리 어려움
CI/CD 환경에서는 다음 과정이 자동으로 실행됩니다.
코드 변경
↓
Git Push
↓
자동 Build
↓
자동 Test
↓
Docker Image 생성
↓
Production 배포
Docker Compose와 CI/CD를 결합하면 안정적인 서버 배포 환경을 만들 수 있습니다.
이번 글에서는 Docker Compose 기반 CI/CD 개념부터 Git Workflow, 자동 Image Build, Container 배포 과정, Production 운영 구조까지 알아보겠습니다.
CI/CD란 무엇인가?
CI/CD는 소프트웨어 배포 과정을 자동화하는 방법입니다.
CI:
Continuous Integration
지속적 통합
의미:
개발자가 코드 작성
↓
자동 Build
↓
자동 Test
CD:
Continuous Deployment
지속적 배포
의미:
Test 성공
↓
자동 Production 배포
전체 구조:
Developer
↓
Git Repository
↓
CI Pipeline
↓
Docker Build
↓
Docker Compose Deploy
↓
Production Server
Docker Compose CI/CD가 필요한 이유
수동 배포:
코드 수정
↓
서버 접속
↓
명령 실행
↓
서비스 확인
문제:
- 배포 실수
- 환경 차이
- 버전 관리 어려움
자동 배포:
Git Push
↓
Pipeline 실행
↓
자동 배포
장점:
- 빠른 배포
- 동일한 환경 유지
- 오류 감소
- 작업 기록 저장
Docker Compose CI/CD 기본 구조
Production 구조:
Developer
↓
GitHub
↓
CI/CD Tool
↓
Docker Image Build
↓
Docker Registry
↓
Production Server
↓
Docker Compose
각 역할:
Git:
소스 코드 관리
CI Tool:
자동 작업 실행
Docker:
Container Image 생성
Compose:
서비스 배포 관리
Docker Compose Git Workflow 구성
일반적인 Branch 구조:
main
↓
Production
develop
↓
Development
구조:
개발자
↓
develop Branch
↓
Test
↓
main Merge
↓
Production Deploy
장점:
- 안정적인 배포
- 테스트 가능
- Rollback 쉬움
Docker Compose Docker Image 자동 Build
CI 과정에서 Image를 생성합니다.
기본 과정:
Source Code
↓
Dockerfile
↓
Docker Build
↓
Image 생성
명령:
docker build -t my-app .
결과:
my-app:v1.0
Production에서는 Version Tag를 사용하는 것이 좋습니다.
예:
my-app:1.0.0
Docker Compose Docker Registry 사용
생성한 Image는 Registry에 저장합니다.
구조:
Docker Build
↓
Docker Image
↓
Registry 저장
↓
Server Pull
대표 Registry:
- Docker Hub
- GitHub Container Registry
- Private Registry
예:
docker push my-app:1.0.0
Docker Compose 자동 배포 과정
Production 배포 흐름:
Git Push
↓
CI 실행
↓
Docker Image Build
↓
Registry Push
↓
Server Pull
↓
docker compose up -d
서버 명령:
docker compose pull
docker compose up -d
동작:
기존 Container
↓
새 Image 적용
↓
서비스 업데이트
Docker Compose 배포 Script 작성
deploy.sh:
#!/bin/bash
docker compose pull
docker compose up -d
docker compose ps
실행:
chmod +x deploy.sh
결과:
자동 배포 Script 완성
Docker Compose CI/CD 환경 변수 관리
CI/CD에서는 Secret 관리가 중요합니다.
관리 대상:
- Docker Registry Password
- SSH Key
- Database Password
- API Token
구조:
CI Secret
↓
Pipeline
↓
Server Deploy
직접 작성:
password: 123456
비추천
Secret 사용:
GitHub Secrets
↓
Workflow
↓
Deploy
Docker Compose Rollback 전략
배포 후 문제가 발생할 수 있습니다.
문제:
새 Version 배포
↓
Application 오류
Rollback:
이전 Image Version
↓
Container 재배포
예:
현재:
my-app:2.0
이전:
my-app:1.9
변경:
image: my-app:1.9
재배포:
docker compose up -d
Docker Compose 무중단 배포 구조
서비스 규모가 커지면 무중단 배포가 필요합니다.
Blue Green 방식:
사용자
↓
Load Balancer
↓
Blue Container
새 Version:
Green Container
과정:
Green 배포
↓
테스트
↓
Traffic 변경
↓
Blue 종료
장점:
- 서비스 중단 최소화
- 빠른 Rollback
Docker Compose CI/CD 장애 대응
배포 실패 시 확인:
Image:
docker images
Container:
docker compose ps
Log:
docker compose logs
Health:
docker inspect container
확인 순서:
Image
↓
Container
↓
Log
↓
Healthcheck
Docker Compose CI/CD Best Practice
운영 추천:
- Image Version 고정
- 자동 Test 추가
- Secret 사용
- Rollback 준비
- 배포 Log 저장
- Healthcheck 적용
권장 구조:
Git Push
↓
CI/CD
↓
Docker Build
↓
Registry
↓
Compose Deploy
↓
Monitoring
자주 묻는 질문
Docker Compose도 자동 배포가 가능한가요?
가능합니다.
CI/CD 시스템과 연결하면 자동 배포 환경을 구성할 수 있습니다.
Image를 매번 새로 Build해야 하나요?
코드 변경 시 새로운 Version Image를 만드는 방식이 일반적입니다.
Production 서버에서 Git Pull 방식은 안 좋은가요?
가능하지만 자동화 환경에서는 Registry 기반 배포가 더 안정적입니다.
CI/CD를 꼭 사용해야 하나요?
서비스 규모가 커질수록 자동 배포 시스템의 필요성이 증가합니다.
마무리
Docker Compose CI/CD 자동화는 안정적인 서버 운영을 위한 핵심 과정입니다.
최종 배포 구조:
Developer
↓
Git Repository
↓
CI/CD Pipeline
↓
Docker Image
↓
Registry
↓
Docker Compose
↓
Production Server
↓
Monitoring
이 구조를 사용하면 코드 변경부터 Production 배포까지 반복 작업을 자동화할 수 있습니다.
다음 글에서는 실제 자동 배포를 구현하는 Docker Compose GitHub Actions 연동 방법을 알아보겠습니다.