[도커] 10장 도커 컴포즈를 이용한 여러 환경 구성

공효은·2023년 7월 12일

10.1 도커 컴포즈로 여러 개의 애플리케이션 배포하기

도커 컴포즈는 여러 개의 컨테이너로 구성된 애플리케이션을 단일 도커 엔진 호스트에서 실행하기 위한 도구이며 개발자에게 특히 유용하므로 개발 환경이나 테스트 환경에서 주로 쓰인다.
비운영 환경에서는 스케일링 기능이 필요 없으며 운영 환경만큼의 성능을 요구하지도 않는다. 그러므로 비운영 환경은 도커 컴포즈가 가장 크게 활약할 수 있는 환경이다.
여러 환경을 구성해 용도별로 사용하려면, 환경마다 애플리케이션이 다르게 동작하게끔 해야한다. 무턱대고 여러 컨테이너가 같은 포트를 통해 요청을 받게 하거나, 서버에 있는 같은 파일을 여러 컨테이너가 쓰려고 해서는 안된다.

도커 컴포즈가 어떤 도커 리소스가 애플리케이션의 일부인지 아닌지 판단하는 원리를 고려하자. 그 기준은 레이블의 명명 규칙을 따른다.

cd ./ch10/exercises

# 무작위 숫자 애플리케이션(8장)을 실행
// number 디렉터리 안에 있는 컴포즈 파일에 정의된 애플리케이션을 실행한다.
// 컴포즈는 애플리케이션을 구성하는 컨테이너를 실행하는데, 그 이름에 컴포즈 파일이 포함된 디렉터리명을 접두사로 사용한다.
docker-compose -f ./numbers/docker-compose.yml up -d

# to-do 애플리케이션(6장)을 실행
// todo-list 디렉터리의 컴포즈 파일에 정의된 애플리케이션을 실행하면 애플리케이션 컨테이너가 생성된다.
docker-compose -f ./todo-list/docker-compose.yml up -d

# to-do 애플리케이션 하나 더 실행
//앞의 명령을 한 번 더 실행해도 애플리케이션이 하나 더 실행되지 않는다. 이미 실행 중인 애플리케이션이 컴포즈 파일에 기술된 조건을 이미 만족하기 때문이다.
docker-compose -f ./todo-list/docker-compose.yml up -d

서로 다른 디렉터리에 있는 컴포즈 파일로 부터 애플리케이션을 실행할 수는 있었지만, 이미 같은 디렉터리에서 실행한 애플리케이션을 하나 더 실행하려고 하니 잘 되지 않았다. 이미 애플리케이션이 잘 실행 중인 것으로 판단하고 더 이상 새로운 컨테이너를 실행하지 않았다.

도커컴포즈가 도커 리소스가 어떤 애플리케이션의 일부인지 아닌지를 판정하기 위해 프로젝트라는 개념을 사용한다.

프로젝트 이름의 기본값은 도커 컴포즈 파일이 들어 있던 디렉터리명인데, 도커 컴포즈가 도커 리소스를 만들 때 이 프로젝트 이름을 리소스의 이름에 접두사로 붙이고, 컨테이너 이름에는 번호를 접미사로 붙인다.

컴포즈 파일이 포함된 디렉터리명이 app1이고 이 컴포즈 파일에 정의된 서비스가 web, 볼륨이 disk 라면 컴포즈가 실제 이 애플리케이션을 실행할 때 app1_disk라는 볼륨과 app1_web_1 이라는 컨테이너를 만든다.
컨테이너 이름 뒤에는 번호가 붙기 때문에 스케일링에도 대응 할 수 있다.
만약 서비스 web의 컨테이너를 두 개로 늘렷다면 새로 추가되는 컨테이너의 이름은 app1_web_2가 된다.

컴포즈가 사용하는 프로젝트 이름의 기본값을 바꿀 수 있으므로 이 프로젝트 이름을 바꾸는 방법으로 단일 도커 호스트에 같은 애플리케이션을 여러 벌 실행시킬 수 있다.

// 프로젝트 이름을 새로 지정하면 기본값이 프로젝트 이름으로 사용된 기존 애플리케이션과 별개의 것으로 취급된다.

docker-compose -f ./todo-list/docker-compose.yml -p todo-test up -d
docker container ls
// 컨테이너의 공개된 포트를 알려주므로 컨테이너 이름으로 애플리케이션의 포트도 알 수 있다.
docker container port todo-test-todo-web-1 80

애플리케이션 두벌이 실행중이다. 같은 도커 컴포즈로 저으이된 애플리케이션이지만, 프로젝트 이름이 다르기 떄문에 별개의 것으로 취급된다.

이 방법으로 도커 컴포즈를 사용해 같은 애플리케이션도 여러 벌 실행할 수 있다. 약간 아쉬운 점은 무작위로 정해진 공개 포트를 일일이 찾아야한다.
컴포즈가 제공하는 기능 중에 더 좋은 방법은 설정을 오버라이드 하는 것이다.

10.2 도커 컴포즈의 오버라이드 파일

하나의 애플리케이션을 여러 설정으로 실행해야 할 필요가 생긴 경우 대부분은 컴포즈 파일을 (각 설정 또는 환경마다 하나씩) 여러 개 두는 방법을 쓴다.
그러나 이 방법은 유지 보수 측면에서 바람직하지 않다.
이들 컴포즈 파일의 내용은 90% 이상이 중복이니 수정 시 누락이 발생한다면 환경 차이 문제가 되살아난다. 오버라이드 파일은 이런 문제를 해결하는 기능이다.
도커 컴포즈는 여러 파일을 합쳐 컴포즈 파일을 구성하는데, 나중에 지정된 파일의 내용이 이전 파일의 내용을 오버라이드(override), 즉 덮어 쓰기한다.

docker-compose.yml
- services
- 기본 컴포즈 파일에는 서비스와 모든 환경에 공통적으로 사용되는 설정이 정의된다.
docker-compose-dev.yml
- services
- networks
- dev 오버라이드 파일은 개발 환경에서만 쓰이는 서비스와 네트워크 설정이 정의된다.
docker-compose-test.yml
- services
- networks
- volumes
- test 오버라이드 파일은 테스트 환경에서만 쓰이는 서비스, 네트워크,볼륨 설정이 정의된다.
도커 컴포즈가 이들 파일을 합쳐 사용하므로 테스트 환경이라면 기본 파일과 test 오버라이드 파일을 지정하면 된다.

이렇게 구성하면 설정 파일에 중복된 내용이 없고 유지 보수성이 개선된다. 모든 환경에 공통적으로 적용될 내용 (이를테면, 이미지 태그를 최신 버전으로 변경)을 변경하고 싶다면 기본 파일을 수정하면 된다.
어느 특정 환경에만 적용하고 싶은 변경 내용이라면 해당 환경의 오버라이드 파일만 수정한다.

// 속성 하나를 변경하는 도커 컴포즈 오버라이즈 파일
# docker-compose.yml - 기본 파일
services:
   todo-web:
      image: diamol/ch06-todo-list
      ports:
        - 80
      environment:
        - Database:Provider=Sqlite
      networks:
        - app-net
        
# docker-compose-v2.yml - 오버라이드 파일
services:
   todo-web:
      image: diamol/ch06-todo-list:v2

오버라이드 파일에는 해당 환경에서 변경할 항목만 기술하면된다. 그러나 기본 컴포즈 파일의 구조를 유지해야 도커 컴포즈가 두 정의를 연결 지을 수 있다.
이 예제의 오버라이드 파일은 image 속성값 하나만 변경하는데, 이 속성은 기본 파일상의 위치와 마찬가지로 services 블록의 todo-web 블록 아래에 위치한다.
도커 컴포즈는 하나 이상의 파일이 인자로 지정됐을 때 파일을 병합한다.

config 명령어

docker-compose -f ./todo-list/docker-compose.yml -f ./todo-list/docker-compose-v2.tml config

image 속성은 오버라이드 파일의 내용이 적용된 유일한 속성이다. 나머지 설정은 기본 파일의 설정을 따른다.
config 부명령은 병합된 컴포즈 파일을 미리 볼 수 있으므로 오버라이드 파일을 검증하는 데 편리하다.
config 부명령은 설정 파일의 내용이 유효한지 확인할 뿐 애플리케이션을 실제로 실행하지는 않는다. 대신 기본 파일과 오버라이드 파일이 병합된 컴포즈 파일을 미리 볼 수 있다.
도커 컴포즈가 오버라이드 파일을 병합하는 순서는 인자로 받은 순서이다. 인자로 지정된 순서가 먼저인 파일이 순서가 나중인 파일보다 우선한다.
순서는 중요하다 잘못 나열하면 원치 않은 결과를 얻을 수 있다.

실전 응용 사례

docker-compose.yml: 기본 컴포즈 파일. 웹 및 API 서비스가 정의됐으나 포트나 도커 네트워크에 대한 정의는 빠져있다.
docker-compose-dev.yml: 개발 환경 대상의 설정. 도커 네트워크 및 서비스의 공개포트를 정의하고 헬스 체크와 디펜던시 체크를 비활성화한다. 개발자들이 빠르게 애플리케이션을 실행하는 것을 목적으로 한다.
docker-compose-test.yml: 테스트 환경 대상의 설정. 도커 네트워크를 정의하고, 헬스체크를 설정하고, 웹 서비스의 공개 포트를 정의한다. 그러나 API 서비스의 포트는 공개하지 않는다.
docker-compose-uat.yml: 사용자 인수 테스트 환경 대상의 설정. 도커 네트워크를 설정하고, 웹 서비스는 80번 표준 포트로 공개하고, 서비스 오류 발생 시 항상 재시작 하도록 설정하고, 헬스 체크를 좀 더 꼼꼼하게 하도록 지정한다.

// 기본 컴포즈 파일을 변경하기 위한 오버라이드 파일의 예

services:
  numbers-api:
    ports:
      - "8087:80"
    healthcheck:
      disable: true
      
  numbers-web:
    entrypoint:
      - dotnet
      - Numbers.Web.dll
    ports:
      - "8088:80"
      
  networks:
    app-net:
      name: numbers-dev

다른 오버라이드 파일도 동일한 구조를 따른다. 환경마다 웹 애플리케이션과 API가 사용하는 포트가 다르기 때문에 여러 개의 애플리케이션을 단일 도커 호스트에서 실행할 수 있다.

현재 있는 컨테이너를 모두 제거한 다음 무작위 숫자 애플리케이션을 여러 환경용 설정으로 실행한다. 각 환경마다 별도의 프로젝트 이름과 기본 컴포즈 파일, 오버라이드 파일이 있어야한다.

# 기존 컨테이너 모두 제거하기
docker container rm -f $(docker container ls -aq)

# 개발 환경용 설정으로 실행하기
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-dev.yml -p numbers-dev up -d

# 테스트 환경용 설정으로 실행하기
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-test.yml -p numbers-test up -d

# 인수 테스트 환경용 설정으로 실행하기
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-uat.yml -p numbers-uat up -d

이들 각각은 모두 별개의 도커 네트워크를 사용하므로 서로 독립적이다.
개발 팀에서는 이들 모두를 한 서버에서 실행하고, 팀마다 포트를 달리해 자신의 업무와 관련된 환경에 접근할 수 있다.
예를 들어 사용자 인수 테스트 환경은 80번 포트로 접근, 시스템 테스트 환경은 8080번 포트, 개발 팀의 통합 테스트 환경은 8088번 포트로 접근하는 식이다.
이들은 모든 자신만의 네트워크 안에서 해당 환경의 API 컨테이너와만 통신할 수 있다. 이 때문에 세 환경의 애플리케이션은 서로 독립적이다.
개발 환경의 애플리케이션에 여러 번 무작위 숫자를 요청해 API가 버그를 일으키더라도 시스템 테스트 환경이나 사용자 인수 테스트 환경의 애플리케이션은 잘 동작한다.
이들 환경별로 실행된 컨테이너는 도메인 네임을 사용해 서로를 식별하지만, 같은 도커 네트워크에 접속한 컨테이너끼리만 통신이 가능하다.

🤔 해당 환경의 애플리케이션을 종료하려면?

애플리케이션을 실행할 때 지정한 프로젝트 이름도 알고 있어야 한다.
테스트 환경의 애플리케이션을 종료하려면 해당 환경의 컨테이너와 네트워크를 제거해야한다.
프로젝트 이름을 기본값에서 변경한 지금은 docker-compose up 명령을 실행할 떄 사용한 모든 파일과 프로젝트 정보를 정확히 지정해야한다.

# 프로젝트 이름을 기본값에서 변경하지 않고
# 기본 컴포즈 파일만 사용했다면 이 명령이 동작했을 것이다.
docker-compose down

# 프로젝트 이름 변경 없이
# 오버라이드 파일만 지정했다면 이 명령도 동작했을 것이다.
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-test.yml down

# 하지만 프로젝트 이름을 기본값에서 변경했으니
# 애플리케이션을 종료할 때도 다시 프로젝트 이름을 정확하게 지정해야 한다.
docker-compose -f ./numbers/docker-compose.yml -f ./numbers/docker-compose-test.yml -p numbers-test down

이 디렌터리에는 컴포즈 파일이 없고 -f 옵션으로 파일을 별도 지정하지도 않았으므로 수행할 내용이 없다.

프로젝트 이름이 지정되지 않았으므로 컨테이너 대신 컴포즈 파일에 이름이 명시적으로 지정된 네트워크(numbers) 를 찾는다.

처음 up 부명령을 실행했던 파일과 프로젝트 이름이 일치하므로 이들 리소스가 제거 대상이 된다.

한 컴퓨터에 같은 애플리케이션을 몇 벌이든 실행할 수 있으므로 도커 컴포즈는 운영 외 환경에서 가장 유용하다.
오버라이드 파일을 사용하면 애플리케이션 정의를 재사용할 수 있지만 그만큼 오버라이드 관리에 드는 호버헤드도 발생한다.
애플리케이션 배포 및 폐기 스크립트의 작성과 자동화를 익히자!

10.3 환경 변수와 비밀값을 이용해 설정 주입하기

환경 간에 애플리케이션 설정을 달리해야 하는 경우도 있다. 대부분의 애플리케이션은 설정을 환경 변수나 설정 파일로부터 읽어 오는데, 도커 컴포즈도 이들 수단을 충실히 지원한다.

💭 환경 변수와 설정 파일을 모두 다루기 위해서 도커 컴포즈의 세부적인 동작을 더 자세히 보자!

이전에 살펴본 to-do 애플리케이션으로 돌아가야한다. 환경에 따라 다음 세 가지 설정 값에 변화를 주고자 한다.

로깅: 환경별 로그 수준을 달리해 개발 환경에서 좀 더 자세한 로그를 출력하도록 할 수 있다.
데이터베이스 프로바이더: 애플리케이션 컨테이너에 포함된 파일 형태의 간이 데이터베이스와 별도의 데이터베이스 컨테이너를 선택할 수 있다.
데이터베이스 커넥션 문자열: 별도의 데이터베이스를 사용하는 경우 적용할 데이터베이스 접속 정보를 지정할 수 있다.

오버라이드 파일을 사용해 환경 별로 다른 설정값을 사용한다.
이 파일에는 웹 애플리케이션의 기본적인 정보와 비밀값 형태로 설정 파일을 지정했다.

services: 
   todo-web:
     image: diamol/ch06-todo-list
     secrets:
       - source: todo-db-connection
         target: /app/config/secrets.json

비밀값은 도커 컴포즈, 도커 스웜, 쿠버네티스에서 모두 지원하는 기능으로, 설정값을 주입하기에 매우 유용한 기능이다.
컴포즈 파일에서 비밀값의 원본 위치와 대상 위치를 모두 지정할 수 있는데, 원본 위치는 컨테이너 런타임이 비밀값의 값을 읽어오는곳이고 대상위치는 컨테이너 안에서 비밀값이 위치할 경로이다.
이 컴포즈 파일에서 사용된 비밀값은 todo-db-connection 에서 읽어오도록 돼 있는데, 이 값을 읽으려면 이 이름으로 정의된 비밀값이 해당 컴포즈 파일에 정의돼 있어야한다.
비밀값의 내용은 컨테이너 속 경로 /app/config/secrets.json 파일로 전달된다. 이 경로는 애플리케이션이 설정 파일을 찾는 경로 이기도 하다.
위 컴포즈 파일은 스크립트에서 사용된 todo-db-connection 비밀값이 해당 파일에 정의돼 있지 않기 때문에 단독으로 사용하면 유효하지 않다.

개발 환경용 오버라이드 파일이다. 이 파일은 개발 환경을 위한 추가 설정과 비밀값을 정의한다.

services: 
   todo-web:
     ports:
       - 8089:80
     environment:
       - Database:Provider=Sqlite
     env_file:
       - ./config/logging.debug.env
secrets:
  todo-db-connection:
    file: ./config/empty.json

이 오버라이드 파일에는 세 가지 프로퍼티가 정의 돼 있다. 이들 프로퍼티는 애플리케이션에 설정값을 주입해 동작을 변화시키는 역할을 한다.

environment 프로퍼티는 컨테이너 안에서만 사용되는 환경 변수를 추가한다. 이 환경 변수 값을 적용하면 애플리케이션이 데이터베이스로 파일 데이터베이스인 SQLite를 사용한다. 설정 값을 전달하는 방법 중 가장 간단한 방법이다.
evn_file 프로퍼티는 텍스트 파일의 경로를 값으로 받는다. 이 파일에 정의된 환경 변수가 컨테이너에 적용된다. 텍스트 파일에 변수 이름과 값을 등호(=)로 구분해 한 줄에 하나씩 정의한다. 같은 환경 변수를 여러 번 정의하지 않아도 환경 변수를 여러 컴포넌트에서 공유해 사용할 수 있다.
secrets 프로퍼티는 services나 networks 처럼 컴포즈 파일의 최상위 프로퍼티이며, 이 프로퍼티의 todo-db-connection의 실제 값 혹은 경로가 정의된다(여기서는 로컬 파일 시스템상의 파일로 정의 됐다). 이 예제에는 별도의 데이터베이스가 없으므로 빈 JSON 파일을 사용했다. 애플리케이션이 파일을 읽어도 추가로 적용되는 설정값은 없다.

todo-list-confiigured 디렉터리에 있는 컴포즈 파일과 오버라이드 파일을 사용해 개발환경으로 설정된 애플리케이션을 실행하라. 실행된 웹 애플리케이션에 curl을 사용해 요청을 보내고 컨테이너의 로그 수준이 더 상세해졌는지 확인한다.

# 기존 컨테이너 제거
docker container rm -f $(docker container ls -aq)

# 오버라이드 파일을 적용해 애플리케이션 실행하기(리눅스)
docker-compose -f ./todo-list-configured/docker-compose.yml -f ./todo-list-configured/docker-compose-dev.yml -p todo-dev up -d

로그에서 추출
Executed DbCommand (9ms) [Parameters=[], CommandType='Text', CommandTimeout='30']

SQL 쿼리를 볼 수 있다. 로그 수준이 변경되었다.

개발 환경에는 비밀값과 환경변수로 설정값을 주입하며, 이 비밀값과 환경 변수는 컴포즈 파일과 컴포즈 파일에 지정된 경로에 있는 설정 파일로부터 읽어 오는 방법을 사용했다.

테스트 환경에서는 컴포즈가 제공하는 다른 방법을 통해 설정값을 주입해본다. 호스트 컴퓨터의 환경 변수 값을 컨테이너에 전달하는 방법이다. 이 방법을 사용하면 컴포즈 파일을 수정하지 않아도 설정값을 변경할 수 있기 떄문에 애플리케이션의 이식성이 향상된다.

todo-web:
  ports:
    - "${TODO_WEB_PORT}:80"
  environment:
    - Database:Provider=Postgres
  env_file:
    - ./config/logging.information.env
  networks:
    - app-net

컴포즈로 애플리케이션을 실행할 때 대상 디렉터리에서 .env 파일을 발견하면, 이 파일을 환경 파일로 간주하고 파일의 내용으로부터 환경 변수를 읽어들여 애플리케이션을 실행하기 전에 적용된다.

실습
설정이 추가된 to-do 애플리케이션 예제 디렉터리까지 이동해 도커 컴포즈에 별도의 파라미터를 지정하지 않고 애플리케이션을 실행시킨다.

컴포즈 명령을 아무 인자 없이 실행하면 .env 파일에 포함된 기본값을 컴포즈 파일 및 컴포즈 실행 옵션으로 사용한다. 이 기본값을 적용하면 코어 컴포즈 파일에 테스트 환경의 설정값이 적용되므로 데이터베이스 컨테이너와 웹 컨테이너가 모두 생성된다.

이 환경 파일에는 테스트 환경을 위한 애플리케이션 설정이 기본값으로 들어있으며, 파일명만 바꾸면 쉽게 개발환경 설정을 기본값으로 할 수 있다.
컴포즈 파일과 함께 환경 파일을 잘 관리하면 어떤 파일이 어떤 환경의 설정값에 해당하는지에 대한 문서 역할을 대신할 수 있으나 주의할 점이 있다.
도커 컴포즈는 .env 파일만을 환경 파일로 간주하기 때문에 환경 파일 여러 개를 만들어 바꿔가면서 사용할 수 없다.

environment 프로퍼티를 사용해 환경 변수를 지정하는 방법은 간단하고 컴포즈 파일의 가독성도 좋다. 그러나 평문 텍스트로 작성되기 때문에 API 키나 데이터베이스 접속 정보 같은 민감한 정보에는 사용하지 않는 편이 좋다.
비밀값에 설정값을 지정하는 방법은 모든 컨테이너 런타임에서 적용 가능하고 민감한 정보가 유출될 우려도 없기 때문에 유연성 면에서 가장 뛰어나다.
비밀값의 실제 값은 로컬 파일 시스템에 저장할 수도 있고 도커 스웜이나 쿠버네티스 클러스터에 저장할 수도 있다. 실제 값이 어디에 저장되든 애플리케이션이 실행될 때 컨테이너 속의 특정한 파일로 전달된다.
설정값을 파일에 저장한 다음 이 파일의 경로를 environment_file 프로퍼티에 지정하는 방법은 서비스 간에 공유하는 설정이 많은 경우에 유용하다.
컴포즈가 로컬에 위차한 파일을 읽어 각 설정 값을 지정해 주기 때문에 원격 컴퓨터에서 실행중인 도커 엔진을 다룰 때도 로컬 컴퓨터의 설정값을 적용할 수 있다.
환경 파일 .env는 환경을 막론하고 기본 설정을 지정할 때 유용하다.

10.4 확장 필드로 중복 제거하기

도커 컴포즈 설정 기능은 비교적 단순한 기능이기 때문에 사용하다 보면 금세 나름의 한계점에 부닥친다. 이중 가장 흔한 경우는 서비스 간 많은 설정값을 공유하는 컴포즈 파일의 덩치가 점점 커지는 문제이다.
=> 이 문제를 해결하기 위한 도커 컴포즈의 기능인 확장 필드.

확장 필드는 YAML의 여러 블록을 한곳에서 정의하는 기능이다. 컴포즈 파일에서는 스크립트 전체에 걸쳐 이 블록을 재사용하는 효과가 있다.
컴포즈 파일에서는 스크립트 전체에 걸쳐 이 블록을 재사용하는 효과를 얻을 수 있다.
확장 필드는 스크립트의 중복을 제거하는 동시에 잠재적인 오류를 줄여준다.

도커 컴포즈 파일에 정의된 확장 필드

x-logging: &logging
  logging:  
    options:
      max-size: '100m'
      max-file: '10'

x-labels: &labels
  app-name: image-gallery

서비스 정의에서 YAML 병합을 통해 확장 필드를 사용한 예

services:
  accesslog:
    <<: *logging
    labels:
      <<: *labels

  iotd:
    ports:
      - 8080:80
    <<: *logging
    labels:
      <<: *labels
      public: api

확장 필드를 재사용 할 때는 YAML 병합 문법을 사용해 <<: 과 같이 쓴다.
그러므로 <<:logging 위치에 해당 YAML 파일의 logging 확장 필드값이 병합된다.
컴포즈가 이 파일을 처리하고 나면 서비스의 logging에 logging 확장 필드의 값이 들어가고, labels에 labels 확장필드에 정의된 레이블이 추가된다.

실습
컴포즈 파일의 확장 필드가 처리되는 것을 확인하려면 config 부명령을 사용하면 되고 굳이 애플리케이션을 실행할 필요는 없다. 이 명령을 사용하면 입력된 내용을 모두 검증한 후 확장 필드가 서비스 정의에 모두 병합된 최종 컴포즈 파일을 출력한다.

# 운영 환경 오버라이드 파일이 적용된 컴포즈 파일의 최종 내용을 출력한다.
docker-compose -f ./docker-compose.yml -f ./docker-compose-prod.yml config

name: image-gallery
services:
  accesslog:
    image: diamol/ch09-access-log
    labels:
      app-name: image-gallery
    logging:
      options:
        max-file: "10"
        max-size: 100m
    networks:
      app-net: null
  grafana:
    depends_on:
      prometheus:
        condition: service_started
    image: diamol/ch09-grafana
    labels:
      app-name: image-gallery
    logging:
      options:
        max-file: "10"
        max-size: 100m
    networks:
      app-net: null
    ports:
    - mode: ingress
      target: 3000
      published: "3000"
      protocol: tcp
  image-gallery:
    image: diamol/ch09-image-gallery
    labels:
      app-name: image-gallery
      public: web
    logging:
      options:
        max-file: "10"
        max-size: 100m
    networks:
      app-net: null
    ports:
    - mode: ingress
      target: 80
      published: "80"
      protocol: tcp
  iotd:
    image: diamol/ch09-image-of-the-day
    labels:
      app-name: image-gallery
      public: api
    logging:
      options:
        max-file: "10"
        max-size: 100m
    networks:
      app-net: null
    ports:
    - mode: ingress
      target: 80
      published: "8080"
      protocol: tcp
  prometheus:
    environment:
      DOCKER_HOST: ""
    image: diamol/ch09-prometheus
    labels:
      app-name: image-gallery
    logging:
      options:
        max-file: "10"
        max-size: 100m
    networks:
      app-net: null
    ports:
    - mode: ingress
      target: 9090
      published: "9090"
      protocol: tcp
networks:
  app-net:
    name: image-gallery-prod
x-labels:
  app-name: image-gallery
x-logging:
  logging:
    options:
      max-file: "10"
      max-size: 100m

확장 필드는 컴포즈 파일을 관리하는 베스트 프랙티스 중 한 가지 방법이다. 특히 로깅 및 레이블 설정은 모든 서비스에 공통적으로 적용되는 경우가 많다.
확장 필드는 여러 컴포즈 파일에 한꺼번에 적용할 수 없다.
코어 컴포즈 파일에 정의된 확장 필드를 오버라이드 파일에서 사용할 수 없다.

10.5 도커를 이용한 설정 워크플로 이해하기

이번 장에서는 도커 컴포즈를 이용해 서로 다른 환경을 정의하는 방법을 다음과 같은 세가지 핵심 영역 위주로 봤다.

애플리케이션 구성 요소의 조합

모든 환경에서 전체 스택을 실행할 필요는 없다. 오버라이드 파일을 사용하면 공통된 서비스는 그대로 두고 환경마다 필요한 서비스를 달리하는 설정을 간편하게 작성할 수 있다.

컨테이너 설정

각 환경의 상황과 요구 사항에 맞춰 설정을 바꿀 필요가 있다.
공개 포트는 다른 컨테이너와 충돌하지 않도록 중복 x
볼륨 경로는 테스트 환경에서는 로컬 드라이브를 사용하지만 운영 환경에서는 공유 스토리지가 사용된다.
오버라이드 파일과 ,도커 네트워크로 각 애플리케이션을 분리하는 방법으로 이런 요구 사항을 모두 만족 시키면서 단일 서버에 여러 개의 애플리케이션을 실행한다.