- Docker Compose란?
-
여러 개의 컨테이너를 하나의 서비스로 관리하는 도구를 의미함
-
저번 강의 때 order라는 서비스에 mysql, zipkins, api 등 여러 개의 컨테이너를 띄우는 거 생각하면 됨
-
YAML 파일로 컨테이너 정의 및 실행 가능
-
개발 및 배포 환경에서 다중 컨테이너 애플리케이션을 쉽게 설정할 수 있음
- 그럼 Docker Compose와 Kubernetes의 차이는 무엇일까?
1) Docker Compose
-
로컬 환경 및 개발 단계에서 컨테이너 오케스트레이션 (주로 개발 및 테스트 환경에서 사용됨)
-
YAML 파일 (
docker-compose.yml) -
로컬 개발 환경에서 사용, Auto-Scaling 없음
-
기본적으로 로드 밸런싱 미지원 (수동 설정 필요)
-
스토리지 관리: 로컬 볼륨 마운트 사용
-
배포 방식: 단순한 컨테이너 실행
2) Kubernetes
-
대규모 컨테이너 오케스트레이션 및 클러스터 관리
(주로 프로덕션 환경에서 사용) -
YAML 파일 (
deployment.yaml,service.yaml등) -
클러스터 기반으로 Auto-Scaling 지원
-
내장된 로드 밸런서 및 서비스 디스커버리 지원
-
스토리지 관리: 퍼시스턴트 볼륨 (PV, PVC) 지원
-
배포 방식: 롤링 업데이트, Canary 배포, Blue-Green 배포 지원
cf) 롤링 업데이트 vs Canary 배포
-> 롤링 업데이트는 모든 사용자에게 자동으로 점진적 배포하는 방식인 반면 Canary 배포는 일부 사용자에게만 새 버전을 먼저 제공한 후 안정성이 확보 되면 전체 배포하는 방식
- Docker Compose 관련 명령어
# docker compose 설치 확인
$ docker-compose --version
# docker compose 실행
$ docker-compose up -d
# 실행된 컨테이너 확인
$ docker ps
# 컨테이너 중지 및 삭제
$ docker-compose down그외 docker-compose 명령어가 실행안되는 이슈가 있었음
-
공식 문서(https://docs.docker.com/compose/install/) 참고하여 문제 해결
-
원인은 Docker Desktop 자동 업데이트에 의존하는 경우, 업데이트에서 관리자 비밀번호를 묻지 않으므로 심볼릭 링크가 끊어지고 docker-compose 명령을 사용할 수 없는 것 때문으로 보임.
이는 맥 사용자에게만 영향을 미친다고 함. -
아래 명령어 실행
sudo rm /usr/local/bin/docker-compose
sudo ln -s /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose /usr/local/bin/docker-compose
- Docker 이미지란?
-
실행 가능한 애플리케이션을 포함한 패키지이며, 컨테이너를 실행하는 데 사용
-
컨테이너는 Docker 이미지를 기반으로 실행되며, 이미지에는 애플리케이션 코드, 라이브러리, 의존성 등이 포함
-
Layer 기반 구조로 구성되며, 동일한 레이어를 공유하여 효율적인 스토리지 사용 가능
-
Docker 이미지 주요 명령어
# 현재 시스템에서 사용 가능한 모든 Docker 이미지 목록 확인 $ docker images # 특정 이미지 다운로드 $ docker pull <이미지 이름> # 이미지 정보 확인 $ docker inspect <이미지 이름> # 이미지 삭제 $ docker rmi <이미지 이름>
- Dockerfile 작성 및 이미지 생성 방법
-
Dockerfile이란?
: Docker 이미지를 빌드하는 데 사용되는 스크립트 파일
: 기본 이미지 선택, 패키지 설치, 애플리케이션 복사, 실행 명령어 지정 등 다양한 설정 포함 -
Dockerfile 작성 예시
# 1. 기본 이미지 선택 FROM python:3.9 # 2. 작업 디렉토리 설정 WORKDIR /app # 3. 필요 패키지 복사 COPY requirements.txt . # 4. 패키지 설치 RUN pip install -r requirements.txt # 5. 소스 코드 복사 COPY . . # 6. 컨테이너 시작 시 실행할 명령어 지정 CMD ["python", "app.py"] -
Docker 이미지 빌드 및 실행방법
# 현재 디렉토리에서 Dockerfile을 기반으로 이미지 빌드 (-t 옵션: 태그 지정) docker build -t my-python-app . # 생성된 이미지 확인 docker images # Docker 컨테이너 실행 docker run -d -p 5000:5000 my-python-app
- Docker 이미지 태깅 및 푸시
-
Docker 이미지는 Tag를 사용하여 버전 관리 가능
-
Docker Hub 또는 프라이빗 레지스트리에 푸시 가능
-
Docker 이미지 태깅 및 푸시 명령어
# 이미지 태깅 (my-python-app:v1.0으로 설정) docker tag my-flask-app {my-dockerhub-username}/my-flask-app:v1.0 # Docker hub https://hub.docker.com/ # Docker Hub 로그인 docker login # Docker Hub에 이미지 푸시 docker push {my-dockerhub-username}/my-flask-app:v1.0 # Docker Hub에서 푸시된 이미지 확인 후 실행 docker pull {my-dockerhub-username}/my-flask-app:v1.0 docker run -p 5002:5000 my-dockerhub-username/my-flask-app:v1.0
- Docker 이미지 Versioning과 Semantic Versioning
-
Docker 이미지는 Tag를 사용하여 버전 관리를 수행함
-
latest태그를 사용할 수도 있지만, 명확한 버전 관리를 위해 시멘틱 버저닝을 사용하는 것이 좋음 -
시멘틱 버저닝은 주버전(Major), 부버전(Minor), 패치버전(Patch)으로 구성됨
ex) Major.Minor.Patch1.0.0 : 초기 릴리즈 버전 1.1.0 : 기능(feature) 추가 (하위 호환 유지) 1.1.1 : 버그 수정 (패치 버전) 2.0.0 : 기존 기능을 변경하거나 호환되지 않는 수정 -
Docker에서 시멘틱 버저닝 적용 예시
# 1.0.0 버전으로 빌드 docker build -t my-dockerhub-username/my-flask-app:1.0.0 . # 1.0.1 버전으로 빌드 (패치 업데이트 포함) docker build -t my-dockerhub-username/my-flask-app:1.0.1 . # Docker Hub에 태그별로 푸시 docker push my-dockerhub-username/my-flask-app:1.0.0 docker push my-dockerhub-username/my-flask-app:1.0.1
