[Docker] 도커 컴포즈
업데이트:
4.1 도커 컴포즈를 사용하는 이유
- 여러개의 컨테이너가 하나의 애플리케이션으로 동작할 때 하나씩 하기 번거로울 수 있음
- 매번 run 명령어에 옵션을 설정해 cli로 컨테이너를 생성하기보다는 여러개의 컨테이너를 하나의 서비스로 정의해 컨테이너 묶음으로 관리할 수 있다면 좀 더 편리할 것
=> 도커 컴포즈는 컨테이너를 이용한 서비스의 개발과 CI를 위해 여러개의 컨테이너를 하나의 프로젝트로서 다룰 수 있는 작업환경 제공
- 도커 컴포즈는 여러개의 컨테이너의 옵션과 환경을 정의한 파일을 읽어 컨테이너를 순차적으로 생성하는 방식으로 동작
- run 명령어의 옵션 그대로 사용 가능
- 각 컨테이너의 의존성, 네트워크 볼륨 등을 함께 저으이 가능
- 스웜 모드의 서비스와 유사하게 설정 파일에 정의된 서비스의 컨테이너 수를 유동적으로 조절할 수 있으며 컨테이너의 서비스 디스커버리도 자동으로 이뤄짐
4.3 도커 컴포즈 사용
4.3.1 도커 컴포즈 기본 사용법
- 컨테이너의 설정이 정의된 YAML 파일을 읽어 도커 엔진을 통해 컨테이너를 생성
- 프로젝트 이름을 별도로 입력하지 않으면 기본적으로 docker-compose.yml 파일이 위치한 디렉터리의 이름을 프로젝트 이름으로 사용
- 하나의 서비스에는 여러개의 컨테이너가 존재할 수 있다
- 특정 서비스의 컨테이너만 증가시키는 것도 가능
4.3.2 도커 컴포즈 활용
4.3.2.1 YAML 파일 작성
- 도커 컴포즈를 사용하려면 컨테이너 설정을 저장해 놓은 YAML 파일이 필요 => 기존에 사용하던 run 명령어를 YAML 파일로 변환하는 것이 도커 컴포즈 사용법의 대부분
- YAML 파일은 크게 4가지 항목으로 구성됨
- 버전 정의
- 서비스 정의
- 볼륨 정의
- 네트워크 정의
- 서비스 정의를 가장 많이 사용. 볼륨 저으이와 네트워크 정의는 서비스로 생성된 컨테이너에 선택적으로 적용
- 버전 정의
- 버전 1, 2, 2.1, 3이 있지만 도커 스웜과 호환되는 버전 3 사용 권장
- 일반적으로 YAML파일의 맨 윗 부분에 명시
- 서비스 정의
- 도커 컴포즈로 생성할 컨테이너 옵션 정의
- 이 항목에 쓰인 각 서비스는 컨테이너로 구현되며 하나의 프로젝트로서 도커 컴포즈에 의해 관리됨
- 서비스 이름은 services 하위 항목으로 정의하고 컨테이너의 옵션을 서비스 이름의 하위 항목에 정의
- images
- 서비스의 컨테이너를 생성할 때 쓰일 이미지의 이름을 설정
- 이미지 이름의 포맷은 docker run과 동일
- links
- docker run 명령어의 –link와 같음
- 다른 서비스에 서비스명만으로 접근 가능하게 해줌
- [SERVICE:ALIAS]의 형식을 사용하면 서비스에 별칭으로 접근 가능
- environment
- docker run 명령어의 –env, -e 옵션과 동일
- 서비스의 컨테이너 내부에서 사용할 환경변수를 지정하여 딕셔너리나 배열 형태로 사용 가능
- command
- 컨테이너가 수행될 때 수행할 명령어 설정
- docker run 명령어의 마지막에 붙는 커맨드와 동일
- depends_on
- 특정 컨테이너에 대한 의존관계 나타냄
- 이 항목에 명시된 컨테이너가 먼저 생성되고 실행됨
- links도 depends_on과 같이 컨테이너의 생성 순서와 실행 순서를 정의하지만 depends_on은 서비스 이름으로만 접근 가능하다는 차이가 있음
- 특정 서비스의 컨테이너만 생성하되 의존성이 없는 컨테이너를 생성하려면 –no-deps 옵션을 사용
- ports
- docker run 명령어의 -p와 같으며 서비스의컨테이너를 개방할 포트를 설정
- 그러나 단일 호스트 환경에서 80:80과 같이 호스트의 특정 포트를 서비스 컨테이너에 연결하려면 docker-compose scale 명령어로 서비스의 컨테이너 수 늘리기 불가
- build
- build 항목에 정의된 도커파일에서 이미지를 빌드해 서비스의 컨테이너를 생성하도록 설정
- build 항목에서는 도커 파일에 사용될 컨텍스트나 도커 파일의 이름, 도커 파일에서 사용될 인자 값을 설정할 수 있음
- build 항목을 YAML 파일에 정의해 프로젝트를 생성하고 난 뒤 도커 파일을 변경하고 다시 프로젝트를 생성해도 이미지를 새로 빌드하지 않음
- docker-compose up -d 에 –build 옵션을 추가하거나 docker-compose build 명령어를 사용해 도커 파일이 변경되도 컨테이너를 생성할 때 마다 빌드하도록 설정 가능
- extends
- 다른 YAML 파일이나 현재 YAML 파일에서 서비스 속성을 상속받게 설정
- file 항목을 설정하지 않으면 현재 YAML 파일에서 extends할 서비스를 찾음
- depends_on, links, volumnes_from 항목은 각 컨테이너 사이의 의존성을 내포하고 있으므로 extends로 상속받을 수 없음
- 네트워크 정의
- driver
- 기본적으로 브리지 타입 네트워크 생성
- ipam
- IP Address Manager를 위해 사용할 수 있는 옵션
- subnet, ip 범위 등 설정 가능
- external
- YAML 파일을 통해 프로젝트를 생성할 때 마다 네트워크를 생성하는 것이 아닌 기존의 네트워크를 사용하도록 설정
- external 옵션은 준비된 네트워크를 사용하므로 driver, driver_ops, ipam 옵션과 함꼐 사용 가능
- 볼륨 정의
- driver
- 볼륨이 생성될 때 사용될 드라이버
- default는 local
- external
- external 옵션을 설정하면 프로젝트를 매번 생성하지 않고 기존 볼륨을 사용하도록 설정
- YAML 파일 검증하기
- external 옵션을 설정하면 프로젝트를 매번 생성하지 않고 기존 볼륨을 사용하도록 설정
- docker-compose config로 오타 검사나 파일 포멧이 적절한지 검사
4.3.2.2 도커 컴포트 네트워크
- 네트워크 항목을 정의하지 않으면 프로젝트별로 브리지 타입의 네트워크를 생성
- 생성된 네트워크의 이름은 [프로젝트 이름]_default
- docker-compose up 명령어로 생성
- docker-compose down 명령어로 삭제
- docker-compose scale 명령어로 생성되는 컨테이너도 브리지 타입의 네트워크 사용
- 서비스의 이름으로 서비스 내 컨테이너 접근 가능
- 스웜모드와 유사하지만 작동원리는 다름
4.3.2.3 도커 스웜 모드와 함께 사용하기
- 도커 컴포즈와 스웜 모드를 함께 사용할 수 있는 도커 스택
- 스택은 YAML 파일에서 생성된 컨테이너 묶음
- YAML 스택은 생성하면 YAML 파일에 정의된 서비스가 스웜 모드의 클러스터에서 일괄적으로 생성됨
- 스택은 docker-compose가 아닌 docker stack으로 제어해야 함
- 스택은 도커 컴포즈에 의해서 생성된 것이 아니라 스웜 모드 클러스터의 매니저에 의해 생성된 것이기 때문
4.4 도커 학습을 마치며: 도커와 컨테이너 생태계
- 사실 도커 데몬은 컨테이너가 아님
- 실제로 컨테이너라고 부를 수 있을만한 것은 dockerd가 아닌 runC
- 여러개의 runC 컨테이너 프로세스 및 이미지를 관리하는 주체가 바로 containered
댓글남기기