Loading Services...
포스트 내용에 대한 의견이나 질문을 남길 수 있습니다. 답글과 좋아요는 로그인한 사용자 기준으로 기록됩니다.
현재 글을 기준으로 앞뒤 글을 바로 이동해서 볼 수 있습니다.
도커는 개발자의 일상에 깊숙이 자리 잡았지만, 막상 빌드 명령어를 선택할 때면 헷갈림이 시작된다. 기본적인 docker build .와 docker-compose build 사이에서 많은 개발자들이 혼란을 겪는다. 이 두 명령어는 언제 어떻게 사용해야 할까?
docker build . 명령어의 특징
docker build . 명령어는 가장 기본적인 도커 이미지 빌드 방식이다. 이 명령어는 현재 디렉토리(.)를 빌드 컨텍스트로 사용하며, 단일 Dockerfile을 기반으로 하나의 이미지만 생성한다. 간단한 애플리케이션이나 마이크로서비스 하나를 개발할 때 주로 사용된다.
docker build -t 애플리케이션이름:태그 .
이 방식은 직관적이고 간단하지만, 태그를 수동으로 지정해야 하며 빌드 인자나 환경 변수를 매번 명시적으로 지정해야 하는 번거로움이 있다. 특히 여러 서비스로 구성된 복잡한 애플리케이션에서는 관리가 어려워진다.
docker-compose build의 강점
반면 docker-compose build는 docker-compose.yml 파일에 정의된 모든 서비스를 한 번에 빌드할 수 있는 강력한 도구다. 이 방식의 주요 장점은 다음과 같다:
실제 프로덕션 환경에서는 단일 컨테이너로 애플리케이션을 운영하는 경우가 드물다. 데이터베이스, 캐시 서버, 프론트엔드, 백엔드 등 여러 컨테이너가 함께 작동하는 경우가 대부분이며, 이런 복잡한 구성에서는 docker-compose build가 필수적이다.
프로덕션 환경에서 도커 컴포즈의 가치는 더욱 빛난다. 실제 사례를 통해 왜 단순히 docker build .보다 docker-compose build가 더 나은 선택일 수 있는지 살펴보자.
예상치 못한 500 에러와 해결책
한 개발팀은 Python-Magic 라이브러리를 추가하기 위해 Dockerfile과 requirements.txt만 수정한 후, docker build . 명령어로 새 이미지를 빌드했다. 그러나 배포 후 웹 애플리케이션에서 500 에러가 발생했다. 원인을 파악하기 위해 디버깅한 결과, 도커 컨테이너가 제대로 설정되지 않았음을 발견했다.
문제 해결을 위해 docker-compose build를 사용했더니 에러가 사라졌다. 이유는 다음과 같았다:
이 사례는 단순히 패키지를 추가하는 작은 변경이라도, 프로덕션 환경에서는 docker-compose build가 더 안전한 선택일 수 있음을 보여준다.
멀티스테이지 빌드의 복잡성
현대 도커 개발에서는 멀티스테이지 빌드가 일반적이다. 빌드 단계와 실행 단계를 분리하여 최종 이미지 크기를 줄이는 기법이다. 이런 복잡한 Dockerfile을 사용할 때 docker-compose build는 다음과 같은 이점을 제공한다:
실제 서비스 운영 환경에서는 단순히 이미지를 빌드하는 것 이상의 전략이 필요하다. 프로덕션 환경에 적합한 도커 빌드 전략을 알아보자.
환경별 설정 분리
개발, 테스트, 스테이징, 프로덕션 환경은 각기 다른 설정이 필요하다. Docker Compose를 활용하면 다양한 환경 설정을 효과적으로 관리할 수 있다:
docker-compose.yml (기본 설정) version: '3' services: web: build: . ports: - "8000:8000" docker-compose.prod.yml (프로덕션 오버라이드) version: '3' services: web: environment: - NODE_ENV=production deploy: replicas: 3
이렇게 설정 파일을 분리하고 다음과 같이 사용할 수 있다:
docker-compose -f docker-compose.yml -f docker-compose.prod.yml build
CI/CD 파이프라인 통합
지속적 통합과 배포(CI/CD) 파이프라인에서 도커 빌드를 자동화하는 것은 필수적이다. GitHub Actions, Jenkins, GitLab CI 등의 도구와 Docker Compose를 결합하면 다음과 같은 이점이 있다:
무중단 배포(Zero-Downtime Deployment)는 사용자 경험을 유지하면서 새 버전의 애플리케이션을 배포하는 전략이다. 도커 환경에서 무중단 배포를 구현하는 방법을 살펴보자.
무중단 배포의 기본 원리
무중단 배포의 핵심 원리는 간단하다: 새 버전을 배포할 때 기존 버전을 즉시 중단하지 않고, 두 버전을 일정 시간 동안 공존시키면서 트래픽을 점진적으로 새 버전으로 전환하는 것이다. 도커 환경에서는 이런 배포 패턴을 쉽게 구현할 수 있다.
블루-그린 배포 전략
블루-그린 배포는 무중단 배포의 대표적인 방식이다. 현재 운영 중인 환경(블루)과 동일한 새 환경(그린)을 준비한 후, 트래픽을 한 번에 전환하는 방식이다.
docker-compose.blue.yml version: '3' services: web: image: myapp:1.0 ports: - "80:8000" docker-compose.green.yml version: '3' services: web: image: myapp:1.1 ports: - "8080:8000"
블루-그린 배포 과정:
docker-compose -f docker-compose.green.yml up -ddocker-compose -f docker-compose.blue.yml down카나리 배포 전략
카나리 배포는 새 버전을 일부 사용자에게만 점진적으로 노출시키는 방식이다. 이를 통해 문제가 발생했을 때 영향을 최소화할 수 있다.
docker-compose.yml version: '3' services: web-v1: image: myapp:1.0 deploy: replicas: 9 web-v2: image: myapp:1.1 deploy: replicas: 1 nginx: image: nginx:latest volumes: - ./nginx.conf:/etc/nginx/nginx.conf ports: - "80:80"
이 설정에서는 트래픽의 10%만 새 버전으로 라우팅되며, 모니터링 결과에 따라 점진적으로 비율을 높여갈 수 있다.
실제 현장에서 발생할 수 있는 도커 빌드 및 배포 문제와 해결책을 살펴보자.
이미지 크기 최적화 문제
도커 이미지 크기가 너무 크면 배포 시간이 길어지고 리소스 낭비가 발생한다. 이는 무중단 배포 속도에도 영향을 미친다.
해결책:
최적화된 멀티스테이지 빌드 예시 FROM node:14-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx:alpine COPY --from=builder /app/build /usr/share/nginx/html
컨테이너 간 통신 문제
무중단 배포 중 새 버전과 구 버전의 컨테이너가 데이터베이스나 캐시와 같은 상태 저장 서비스와 통신할 때 문제가 발생할 수 있다.
해결책:
롤백 전략의 중요성
무중단 배포 과정에서 문제가 발생했을 때 빠르게 이전 버전으로 돌아갈 수 있는 롤백 전략이 필수적이다.
롤백 스크립트 예시 #!/bin/bash echo "문제 감지, 롤백 시작..." docker-compose -f docker-compose.blue.yml up -d sleep 5 docker-compose -f docker-compose.green.yml down echo "롤백 완료"
무중단 배포를 효과적으로 구현하기 위한 도커 기반 아키텍처를 설계해보자.
오케스트레이션 도구의 활용
대규모 프로덕션 환경에서는 Docker Compose만으로는 한계가 있다. Kubernetes, Docker Swarm 같은 오케스트레이션 도구를 활용하면 더 강력한 무중단 배포가 가능하다.
Kubernetes에서는 다음과 같은 리소스를 활용할 수 있다:
상태 관리와 데이터 지속성
무중단 배포에서 가장 어려운 부분 중 하나는 상태 관리다. 컨테이너가 교체되어도 데이터가 유지되어야 한다.
services: database: image: postgres:13 volumes: - postgres_data:/var/lib/postgresql/data volumes: postgres_data:
모니터링과 알림 체계
무중단 배포 중 문제를 신속하게 감지하기 위한 모니터링 시스템이 필수적이다. Prometheus, Grafana, ELK 스택 등을 도커 환경과 통합하여 실시간 모니터링을 구축할 수 있다.
services: app: image: myapp:latest labels: - "prometheus.scrape=true" - "prometheus.port=8080" prometheus: image: prom/prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml
도커 빌드와 무중단 배포는 현대적인 소프트웨어 개발 및 운영의 핵심 요소다. 단순히 docker build .와 docker-compose build 중 하나를 선택하는 문제를 넘어, 애플리케이션의 복잡성과 환경에 따라 적절한 전략을 선택하고 구현해야 한다. 특히 무중단 배포를 통해 사용자 경험을 유지하면서 지속적인 개선을 이루는 것이 중요하다.
올바른 도커 빌드 전략과 무중단 배포 아키텍처를 구축함으로써, 개발팀은 더 빠르고 안정적으로 소프트웨어를 제공할 수 있게 된다. 이는 결국 비즈니스의 경쟁력 강화로 이어진다.