이 페이지는 도커 컴포즈의 설치 및 사용방법에 대해 설명하고 있다.
도커 컴포즈 (Docker Compose)란?
여러 개의 컨테이너가 하나의 애플리케이션으로 동작할 때, 이를 테스트하려면 각 컨테이너를 하나씩 생성해야 한다. 여러 개의 컨테이너로 구성된 애플리케이션을 구축하기 위해서 run 명령어를 여러 번 사용할 수 있지만, 테스트 단계에서는 매번 run 명령어에 옵션을 설정해서 진행하기에 번거로움이 있다.
이를 위해 도커 컴포즈는 YAML 파일을 통해 여러 개의 컨테이너의 실행을 한 번에 관리하여 하나의 프로젝트처럼 다룰 수 있는 환경을 제공한다.
도커 컴포즈 설치
1) 리눅스
리눅스에서는 명령어 또는 깃허브에서 직접 내려받아 설치가 가능하다. (sudo 필요)
설치: $ sudo curl -L <https://github.com/docker/compose/releases/download/{설치버전}/docker-compose-`uname> -s`-`uname -m` -o /usr/local/bin/docker-compose
권한설정: $ sudo chmod +x /usr/local/bin/docker-compose
2) 윈도우 / MAC
윈도우와 mac OS X에서는 도커 툴박스나 Docker for windows, Docker for Mac을 설치하면 도커 엔진과 함께 자동 설치된다.
3) 설치완료 후 버전 확인 (도커 컴포즈 최신버전 확인)
$ docker-compose -v ($ docker-compose --version)
docker-compose version 1.29.1, build c34c88b2도커 컴포즈 사용
도커 컴포즈는 컨테이너의 설정이 정의된 YAML 파일을 읽어 도커 엔진을 통해 컨테이너를 생성하기 때문에, 가장 먼저 YAML 파일을 작성 해야하며 기존에 사용하던 명령어를 변환하는 것이 도커 컴포즈의 사용법의 대부분이다.
docker-compse.yml 작성과 활용
YAML 파일은 크게 버전, 서비스, 볼륨, 네트워크 정의 4가지 항목으로 구성된다.
도커 컴포즈는 YAML 파일의 탭(tab)을 인식하지 못하므로 2개의 공백을 사용하여 하위 항목을 구분한다.
기본적으로 현재 디렉토리 또는 상위 디렉토리에서 docker-compose.yml 파일을 찾아 컨테이너를 생성하는데, -f 옵션을 이용해서 위치와 이름을 지정할 수도 있다.
(docker-compose -f [파일경로] up -d)
version: '3.0'
services:
web:
image: [저장소이름]/[이미지이름]:[태그]
ports:
- "80:80"
links:
- mysql:db
command:
networks:
driver: ....
1) 버전 정의 (최신 버전 확인)
버전은 1, 2, 2.1, 3.0 등이 있으며 도커 컴포즈 1.8은 버전 2, 1.9는 2.1, 1.10은 3.0을 사용한다.
버전 1은 사용되지 않고, 도커 컴포즈 버전은 도커 엔진 버전에 의존성이 있으므로 가능하다면 최신 버전을 사용하는 것이 좋다. (3은 도커 스웜 모드와 호환되는 버전)
2) 서비스 정의
생성될 컨테이너들을 묶어놓은 단위로 서비스 항목 아래에는 각 컨테이너에 적용될 생성 옵션을 지정한다.
서비스는 도커 컴포즈로 생성할 컨테이너 옵션을 정의한다. 이 항목에 쓰인 각 서비스는 컨테이너로 구현되며, 하나의 프로젝트로서 도커 컴포즈에 의해 관리된다. 서비스의 이름은 services의 하위 항목으로 정의하고 컨테이너의 옵션은 서비스 이름의 하위 항목에 정의한다.
- image: 서비스의 컨테이너를 생성할 때 쓰일 이미지의 이름을 설정.
이미지 이름 포맷은 docker run의 [저장소이름]/[이미지이름]:[태그] 형태와 같으며, 존재하지 않을 경우 저장소에서 자동으로 내려받는다.
- links: —link와 동일하며, 다른 서비스에 서비스명만으로 접근할 수 있도록 설정.
[SERVICE:ALIAS]의 형식으로 별칭으로 서비스에 접근할 수도 있다.
- environment: —env, -e 옵션과 동일하며, 컨테이너 내부에서 사용할 환경변수 설정.
- command: run 명령어의 마지막에 붙는 커맨드와 같으며, 컨테이너가 실행될 때 수행할 명령어를 설정.
- depends_on: 특정 컨테이너에 대한 의존 관계를 나타내며, 이 항목에 명시된 컨테이너가 먼저 실행되고 해당 컨테이너가 실행된다.
cf> —no -deps: 특정 서비스의 컨테이너만 생성하고, 의존성이 없는 컨테이너 생성 ($ docker-compose up —no-deps web)
- ports: -p와 같으며, 서비스의 컨테이너를 개방할 포트를 설정.
단일 호스트 환경에서 80:80과 같이 호스트의 특정 포트를 서비스의 컨테이너에 연결하면 docker-compose scale 명령어로 서비스의 컨테이너의 수를 늘릴 수 없다
- build: 도커파일에서 이미지를 빌드해 서비스의 컨테이너를 생성하도록 설정.
- extends: 다른 YAML 파일이나 현재 YAML 파일에서 서비스 속성을 상속받음.
3) 네트워크 정의
- driver: 서비스의 컨테이너가 브리지 네트워크가 아닌 다른 네트워크를 사용하도록 설정할 수 있다.
- ipam: IPAM(IP Address Manager)를 위해 사용할 수 있는 옵션으로 subnet, ip 범위 등을 설정할 수 있다.
- external: YAML 파일을 통해 프로젝트를 생성할 때마다 네트워크를 생성하는 것이 아닌 기존의 네트워크를 사용하도록 설정할 수 있다.
네트워크 항목을 정의하지 않으면, 도커 컴포즈는 프로젝트별로 브리지 타입의 네트워크를 생성한다.
생성된 네트워크의 이름은 [프로젝트 이름]_default
생성 docker-compose up / 삭제 docker-compose down
4) 볼륨 정의
- driver: 볼륨을 생성할 때 사용될 드라이버를 설정한다. 어떠한 설정도 하지 않으면 local로 설정되며 사용하는 드라이버에 따라 변경해야 한다.
- external: 프로젝트를 생성할 때마다 볼륨을 매번 생성하지 않고 기존 볼륨을 사용할 수 있도록 설정한다.
5) 파일 검증하기
docker-compose config 명령어를 사용하여, 오타나 파일 포맷이 적절한지 등에 대한 검사를 진행할 수 있다.
기본적으로 현재 디렉토리의 파일을 검사 (docker-compose -f [yml파일 경로] config로 변경 가능)
+) 기타 도커 컴포즈 명령어
- 도커 컴포즈 컨테이너들 백그라운드로 띄우기
$ docker-compose up -d - 도커 컴포즈 컨테이너들 포어그라운드로 띄우기
$ docker-compose up - 도커 컴포즈 컨테이너들 내리기
$ docker-compose down - 도커 컴포즈 컨테이너들 다시 시작하기
$ docker-compose restart - 도커 컴포즈 컨테이너들 로그를 계속해서 읽기
$ docker-compose logs -f - 도커 컴포즈 컨테이너들 상태 확인
$ docker-compose ps - 도커 컴포즈 설정을 확인 (주로 -f 옵션으로 여러 개의 설정 파일을 사용할 때, 최종적으로 어떻게 설정이 적용되는지 확인)
$ docker-compose config - 다른 경로에 있는 도커 컴포즈 파일 사용 도커 컴포즈로 다른 이름이나 경로의 파일을 Docker Compose 설정 파일로 사용하고 싶다면 -f 옵션으로 명시
$ docker-compose -f /app/docker-compose.yml up - 여러 개의 도커 컴포즈 설정 파일을 사용할 수 있으며, 이 때는 나중에 나오는 설정이 앞에 나오는 설정보다 우선으로 적용된다
$ docker-compose -f docker-compose.yml -f docker-compose-test.yml up
stack
stack
1. 명사 - (보통 깔끔하게 정돈된) 무더기[더미] (→haystack)
2. 명사 - 비격식, 특히 英 많음, 다량
3. 동사 - (깔끔하게 정돈하여) 쌓다[포개다]; 쌓이다, 포개지다
여기에서의 stack도 기본 정의와 비슷한 의미로, 'YAML 파일에서 생성된 컨테이너의 묶음'으로 사용한다.
stack을 생성하면 YAML 파일에 정의된 서비스가 스웜 모드의 클러스터에서 일괄적으로 생성되며, 도커 컴포즈 명령어 docker-compose가 아닌 docker stack으로 제어한다.
이유는 스택은 도커 컴포즈에 의해 생성된 것이 아니라 스웜 모드 클러스터의 매니저에 의해 생성된 것이기 때문이다.