Docker compose 로 컨테이너 명시적 관리
도커 컴포즈 - 여러 컨테이너의 관리
컨테이너를 관리하는 데 있어서 사용하는 도구 및 방법은 다양하지만 그중에 있어서 가장 기본적인 방법입니다.
도커 컴포즈를 사용하면 단일 서버에서 여러 컨테이너를 프로젝트 단위로 묶어서 관리할 수 있습니다. 또한 docker-compose.yml YAML 파일을 통해 명시적 관리가 가능합니다.
도커 컴포즈의 기능
◾️ 프로젝트 단위로 도커 네트워크와 볼륨 관리
◾️ 프로젝트 내 서비스 간 의존성 정의 가능
◾️ 프로젝트 내 서비스 디스커버리 자동화
◾️ 손 쉬운 컨테이너 수평 확장
◾️ 서비스는 보통 기능적인 측면으로 분리한 단위이고 서비스 내에서 여러개의 컨테이너가 구성됩니다. 이때 서비스 내의 컨테이너는 수평적으로 스케일 인 아웃 하며 조정 가능합니다.
의존성 관계 정의
도커 컴포즈를 사용하면 같은 프로젝트 내에서도 여러 서비스의 구성과 의존성 관계를 정의할 수 있습니다. 의존성 관계란 예를 들면 s1 이 새성되어야 s2가 생성 가능한 s2는 s1에 종속됨을 정의할 수 있습니다. 예를들면 s2가 WAS서버이고 s1 이 mysql이 될수 있지요
도커 컴포즈 매커니즘 다이어그램
여러개의 컨테이너로 구성된 여러 서비스를 프로젝트 단위로 묶어서 같은 네트워크나 볼륨등을 사용하게 하고 이를 모두 docker-compsoe.yml 이라는 파일로 명세하여 관리할 수 있도록 하는 것이 docker-compose 입니다.
프로젝트 (Project)
◾️ 도커 컴포즈에서 다루는 워크스페이스 단위.
◾️ 함께 관리하는 서비스 컨테이너의 묶음.
◾️ 프로젝트 단위로 기본 도커 네트워크가 생성 됨.
서비스 (Service)
◾️ 도커 컴포즈에서 컨테이너를 관리하기 위한 단위.
◾️ scale을 통해 서비스 컨테이너의 수 확장 가능.
컨테이너 (Container)
◾️ 서비스를 통해 컨테이너 관리
※ AWS ECR 과 비교
이와 유사한 구조로 AWS ECR은 프로젝트==클러스터, 서비스 == 서비스, 컨테이너==task 와 같은 구조를 가집니다
docker-compose 파일 syntax
도커컴포즈 파일의 구성은 version, services, networks, volumes 총 4개의 최상위 옵션을 기본으로 사용하합니다.
도커컴포즈 버전에 따라 문법은 조금씩 상이할 수 있습니다. 따라서 docker 공식 홈페이지의 compatibility 를 확인하여야 합니다. 🔗
현재 공식적으로 도커에서 지원하는 도커컴포즈의 구성요소는 다음과 같습니다.
컴포즈 파일 구성요소
The Compose file is a YAML file defining:
◾️ Version (Optional) 도커 컴포즈 파일은 버전 정보를 포함해야 합니다. 버전 정보는 파일의 구문과 사용 가능한 기능을 결정합니다.
◾️ Services (Required) 각 서비스는 이름을 가지며, 컨테이너 이미지, 포트 매핑, 환경 변수, 볼륨 마운트 등의 구성 옵션을 설정할 수 있습니다.
◾️ Networks 여러 서비스 간의 네트워크 통신을 관리하기 위해 사용됩니다. 네트워크 정의는 서비스와 연결될 수 있으며, 각 네트워크는 이름과 드라이버 등 의 옵션을 설정할 수 있습니다.
◾️ Volumes 볼륨은 컨테이너와 호스트 간의 데이터 공유를 위해 사용됩니다. 볼륨 정의는 이름과 드라이버 등의 옵션을 설정할 수 있습니다.
◾️ Configs configs ****블록은 애플리케이션의 구성 파일을 관리하는 데 사용됩니다. 구성 파일은 서비스의 환경 변수, 설정 파일 등의 설정을 포함합니다. config 블록을 사용하여 애플리케이션의 구성을 정의하면 환경 변수 값의 중복을 피하고, 여러 컨테이너에서 일관된 구성을 유지할 수 있습니다.
◾️ Secrets secrets 블록은 애플리케이션에서 사용되는 비밀 정보를 관리하는 데 사용됩니다. 비밀 정보는 암호, 인증서, API 키 등을 포함할 수 있습니다.
Docker-compose의 주요 사용 목적
로컬 개발 환경 구성
◾️ 특정 프로젝트의 로컬 개발 환경 구성 목적으로 사용
◾️ 프로젝트의 의존성(Redis, MySQL, Kafka 등)을 쉽게 띄울 수 있음
자동화된 테스트 환경 구성
◾️ CI/CD 파이프라인 중 쉽게 격리된 테스트 환경을 구성하여 테스트 수행 가능
단일 호스트 내 컨테이너를 선언적 관리
◾️ 단일 서버에서 컨테이너를 관리할 때 YAML 파일을 통해 선언적으로 관리 가능