Reference and guidelines

이 주제에서는 Compose 파일 형식의 버전 3 에 대해 설명합니다. 이것은 최신 버전입니다.

Compose and Docker compatibility matrix

Compose 파일 형식에는 1, 2, 2.x 및 3.x 의 여러 버전이 있습니다. 아래 표는 간략히 보여줍니다. 각 버전에 포함 된 내용과 업그레이드 방법에 대한 자세한 내용은 버전 및 업그레이드 정보를 참조하십시오.

이 표는 특정 Docker 릴리스를 지원하는 Compose 파일 버전을 보여줍니다.

Compose file format	Docker Engine release
3.7	18.06.0+
3.6	18.02.0+
3.5	17.12.0+
3.4	17.09.0+
3.3	17.06.0+
3.2	17.04.0+
3.1	1.13.1+
3.0	1.13.0+
2.4	17.12.0+
2.3	17.06.0+
2.2	1.13.0+
2.1	1.12.0+
2.0	1.10.0+
1.0	1.9.1.+

표에 표시된 Compose 파일 형식 버전 외에도 Compose 자체는 릴리스 작성에 표시된 대로 릴리스 일정에 있지만 파일 형식 버전이 반드시 각 릴리스마다 증가하지는 없습니다. 예를 들어, Compose 파일 형식 3.0 은 Compose release 1.10.0에서 처음 도입되었으며 이후 릴리스에서는 점차 버전이 지정되었습니다.

Compose file structure and examples

다음은 Swarm에 앱 배포의 Docker for Beginners lab 주제에 사용된 투표 앱 샘플의 샘플 작성 파일입니다 :

Example Compose file version 3

version: "3.7"
services:

  redis:
    image: redis:alpine
    ports:
      - "6379"
    networks:
      - frontend
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure

  db:
    image: postgres:9.4
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    deploy:
      placement:
        constraints: [node.role == manager]

  vote:
    image: dockersamples/examplevotingapp_vote:before
    ports:
      - "5000:80"
    networks:
      - frontend
    depends_on:
      - redis
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
      restart_policy:
        condition: on-failure

  result:
    image: dockersamples/examplevotingapp_result:before
    ports:
      - "5001:80"
    networks:
      - backend
    depends_on:
      - db
    deploy:
      replicas: 1
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure

  worker:
    image: dockersamples/examplevotingapp_worker
    networks:
      - frontend
      - backend
    deploy:
      mode: replicated
      replicas: 1
      labels: [APP=VOTING]
      restart_policy:
        condition: on-failure
        delay: 10s
        max_attempts: 3
        window: 120s
      placement:
        constraints: [node.role == manager]

  visualizer:
    image: dockersamples/visualizer:stable
    ports:
      - "8080:8080"
    stop_grace_period: 1m30s
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  frontend:
  backend:

volumes:
  db-data:

이 참조 페이지의 주제는 Compose 파일 자체의 구조를 반영하기 위해 최상위 키별로 알파벳순으로 구성됩니다. build, deploy, depends_on, networks 등과 같이 구성 파일에서 섹션을 정의하는 최상위 키는 하위 주제로 지원하는 옵션과 함께 나열됩니다. 이것은 Compose 파일의 ::들여 쓰기 구조에 매핑됩니다.

Service configuration reference

작성 파일은 services, networks 및 volumes을 정의하는 YAML 파일입니다. Compose 파일의 기본 경로는. / docker-compose.yml입니다.

팁: 이 파일에 .yml 또는 .yaml 확장자를 사용할 수 있습니다. 그들은 둘 다 작동합니다.

서비스 정의는 명령 행 매개 변수를 docker container create에 전달하는 것과 같이 해당 서비스를 위해 시작된 각 컨테이너에 적용되는 구성을 포함합니다. 마찬가지로 네트워크 및 볼륨 정의는 docker network create및 docker volume create와 유사합니다.

docker container create와 마찬가지로, CMD, EXPOSE, VOLUME, ENV와 같은 Dockerfile 에 지정된 옵션은 기본적으로 존중되므로 docker-compose.yml에서 다시 지정할 필요가 없습니다.

Bash 와 같은 ${VARIABLE}구문을 사용하여 구성 값에 환경 변수를 사용할 수 있습니다. 자세한 세부 내용은 변수 대체를 참조하십시오.

이 섹션에는 버전 3 의 서비스 정의에서 지원하는 모든 구성 옵션 목록이 포함되어 있습니다.

build

빌드시 적용되는 구성 옵션.

build는 빌드 컨텍스트에 대한 경로를 포함하는 문자열로 지정할 수 있습니다.

version: "3.7"
services:
  webapp:
    build: ./dir

또는 context에서 경로가 지정되고 선택적으로 tionally Dockerfile 및 args가 지정된 객체로:

version: "3.7"
services:
  webapp:
    build:
      context: ./dir
      dockerfile: Dockerfile-alternate
      args:
        buildno: 1

build뿐만 아니라 image도 지정하면 Compose 는 image 에 지정된 webapp 및 선택적 tag를 사용하여 빌드된 이미지의 이름을 지정합니다.

build: ./dir
image: webapp:tag

결과적으로 . / dir에서 빌드 된 webapp라는 이미지와 tag태그가 붙습니다.

참고: 이 옵션은 (버전 3) 작성 파일이 있는 웜 모드에서 스택 배포 인 경우 무시됩니다. docker stack 명령은 사전 빌드된 이미지만 허용합니다.

CONTEXT

Dockerfile 을 포함하는 디렉토리의 경로 또는 Git 저장소의 URL 입니다.

제공된 값이 상대 경로인 경우 Compose 파일의 위치를 기준으로 해석됩니다. 이 디렉토리는 Docker 데몬으로 전송되는 빌드 컨텍스트이기도 합니다.

작성은 생성된 이름으로 빌드하고 태그를 지정한 후 그 이미지를 사용합니다.

build:
  context: ./dir

DOCKERFILE

대체 Dockerfile.

작성은 대체 파일을 사용하여 빌드합니다. 빌드 경로도 지정해야합니다.

build:
  context: .
  dockerfile: Dockerfile-alternate

ARGS

빌드 프로세스 중에 만 액세스 할 수 있는 환경 변수인 빌드 인수를 추가하십시오.

먼저 Dockerfile 에 인수를 지정하십시오.

ARG buildno
ARG gitcommithash

RUN echo "Build number: $buildno"
RUN echo "Based on commit: $gitcommithash"

그런 다음 build 키 아래에 인수를 지정하십시오. 매핑 또는 목록을 전달할 수 있습니다.

build:
  context: .
  args:
    buildno: 1
    gitcommithash: cdc3b19

build:
  context: .
  args:
    - buildno=1
    - gitcommithash=cdc3b19

참고: Dockerfile 에서 FROM 명령어 앞에 ARG를 지정하면 FROM 아래의 빌드 명령어에서 ARG를 사용할 수 없습니다. 두 곳에서 인수를 사용할 수 있어야하는 경우에는FROM 명령으로도 지정하십시오. 사용법에 대한 자세한 내용은 ARGS와 FROM의 상호 작용 이해를 참조하십시오.

빌드 인수를 지정할 때 값을 생략할 수 있습니다. 이 경우 빌드시의 값은 Compose 가 실행중인 환경의 값입니다.

args:
  - buildno
  - gitcommithash

참고: YAML 부울 값 (true, false, yes, no, on, off)은 구문 분석기가 이를 문자열로 해석하도록 따옴표로 묶어야합니다.

CACHE_FROM

참고: 이 옵션은 v3.2 의 새로운 기능

엔진이 캐시 확인에 사용하는 이미지 목록입니다.

build:
  context: .
  cache_from:
    - alpine:latest
    - corp/web_app:3.14

LABELS

참고: 이 옵션은 v3.3 의 새로운 기능

Docker labels를 사용하여 결과 이미지에 메타 데이터를 추가하십시오. 배열이나 사전을 사용할 수 있습니다.

레이블이 다른 소프트웨어에서 사용되는 레이블과 충돌하지 않도록 역 DNS 표기법을 사용하는 것이 좋습니다.

build:
  context: .
  labels:
    com.example.description: "Accounting webapp"
    com.example.department: "Finance"
    com.example.label-with-empty-value: ""

build:
  context: .
  labels:
    - "com.example.description=Accounting webapp"
    - "com.example.department=Finance"
    - "com.example.label-with-empty-value"

SHM_SIZE

버전 3.5 파일 형식으로 추가됨

이 빌드 컨테이너의 /dev/shm 파티션 크기를 설정하십시오. 바이트 수를 나타내는 정수 값 또는 바이트 값을 나타내는 문자열로 지정하십시오.

build:
  context: .
  shm_size: '2gb'

build:
  context: .
  shm_size: 10000000

TARGET

버전 3.4 파일 형식으로 추가됨

Dockerfile에 정의된 대로 지정된 스테이지를 빌드하십시오. 자세한 내용은 다단계 빌드 문서를 참조하십시오.

build:
  context: .
  target: prod

cap_add, cap_drop

컨테이너 기능을 추가하거나 삭제하십시오. 전체 목록은 man 7 기능을 참조하십시오.

cap_add:
  - ALL

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

참고: 이 옵션은 (버전 3) 작성 파일을 사용하여 스웜 모드에서 스택을 배포 할 때 무시됩니다.

cgroup_parent

컨테이너의 선택적 상위 cgroup 을 지정하십시오.

cgroup_parent: m-executor-abcd

참고: 이 옵션은 (버전 3) 작성 파일을 사용하여 스웜 모드에서 스택을 배포 할 때 무시됩니다.

command

기본 명령을 오버라이드합니다.

command: bundle exec thin -p 3000

이 명령은 dockerfile와 비슷한 방식으로 목록이 될 수도 있습니다.

command: ["bundle", "exec", "thin", "-p", "3000"]

configs

서비스 별 configs 구성을 사용하여 서비스별로 구성에 대한 액세스 권한을 부여하십시오. 서로 다른 두 가지 구문 변형이 지원됩니다.

참고: 구성이 이미 존재하거나이 스택 파일의 최상위 `configs '구성에 정의되어 있어야 합니다. 그렇지 않으면 스택 배치가 실패합니다.

구성에 대한 자세한 내용은 configs를 참조하십시오.

SHORT SYNTAX

짧은 구문 변형은 구성 이름만 지정합니다. 이것은 컨테이너에게 설정에 대한 액세스 권한을 부여하고 컨테이너 내의 /에 마운트합니다. 소스 이름과 대상 마운트 지점은 모두 구성 이름으로 설정됩니다.

다음 예제는 짧은 구문을 사용하여 redis 서비스에 my_config 및 my_other_config 구성에 대한 액세스 권한을 부여합니다. my_config의 값은 . /my_config.txt 파일의 내용으로 설정되며, my_other_config는 외부 리소스로 정의됩니다. 이는 docker config create명령을 실행하거나 다른 스택 배포를 통해 Docker 에 이미 정의되어 있음을 의미합니다. 외부 구성이 존재하지 않으면 스택 배치가 실패하고 config not found오류가 발생합니다.

참고: config 정의는 작성 파일 형식의 버전 3.3 이상에서만 지원됩니다.

version: "3.7"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    configs:
      - my_config
      - my_other_config
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

LONG SYNTAX

긴 구문은 서비스의 태스크 컨테이너 내에서 구성을 작성하는 방법에 대한 세분성을 제공합니다.

• source: Docker 에 존재하는 구성의 이름입니다.
• target: 서비스의 작업 컨테이너에 마운트 할 파일의 경로와 이름입니다. 지정되지 않은 경우 기본값은/입니다.
• uid and gid: 서비스의 태스크 컨테이너에 마운트 된 구성 파일을 소유하는 숫자 UID 또는 GID 입니다. 지정하지 않으면 Linux 에서 기본값은 '0'입니다. Windows 에서는 지원되지 않습니다.
• mode: 서비스의 작업 컨테이너 내에 마운트된 파일에 대한 권한 (8 진 표기법). 예를 들어, 0444는 세계가 읽을 수 있는 것을 나타냅니다. 디폴트는0444입니다. 구성은 임시 파일 시스템에 마운트되어 쓰기 가능하므로 쓰기 가능 비트를 설정하면 무시됩니다. 실행 비트를 설정할 수 있습니다. UNIX 파일 권한 모드에 익숙하지 않은 경우 이 permissions calculator가 유용할 수 있습니다.

다음 예제는 컨테이너 내에서 my_config 이름을 redis_config로 설정하고 모드를 0440 (그룹 판독 가능)으로 설정하고 사용자와 그룹을 103으로 설정합니다. redis 서비스는my_other_config 설정에 접근할 수 없습니다.

version: "3.7"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    configs:
      - source: my_config
        target: /redis_config
        uid: '103'
        gid: '103'
        mode: 0440
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

서비스에 여러 구성에 대한 액세스 권한을 부여할 수 있으며 길고 짧은 구문을 혼합할 수 있습니다. 구성을 정의한다고 해서 서비스 액세스가 허용되는 것은 아닙니다.

container_name

생성된 기본 이름이 아닌 사용자 정의 컨테이너 이름을 지정하십시오.

container_name: my-web-container

Docker 컨테이너 이름은 고유해야하므로 사용자 정의 이름을 지정한 경우 1 컨테이너 이상으로 서비스를 확장 할 수 없습니다. 이렇게하면 오류가 발생합니다.

참고: 이 옵션은 (버전 3) 작성 파일을 사용하여 스웜 모드에서 스택을 배포 할 때 무시됩니다.

credential_spec

참고: 이 옵션은 v3.3 에서 추가되었습니다. 작성 파일과 함께 gMSA (그룹 관리 서비스 계정) 구성 사용은 작성 버전 3.8 에서 지원됩니다.

관리 서비스 계정에 대한 자격 증명 사양을 구성하십시오. 이 옵션은 Windows 컨테이너를 사용하는 서비스에만 사용됩니다. credential_spec은 file://또는 registry://형식이어야 합니다.

file:을 사용할 때, 참조된 파일은 Docker 데이터 디렉토리의 CredentialSpecs 서브 디렉토리에 있어야 하며, Windows 의 경우 기본값은 C:\ProgramData\Docker\입니다. 다음 예제는 C:\ProgramData\Docker\CredentialSpecs\my-credential-spec.json이라는 파일에서 자격 증명 사양을 로드합니다.

credential_spec:
  file: my-credential-spec.json

registry:를 사용할 때 자격 증명 사양은 데몬 호스트의 Windows 레지스트리에서 읽습니다. 지정된 이름의 레지스트리 값은 다음 위치에 있어야합니다.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Containers\CredentialSpecs

다음 예제는 레지스트리의 my-credential-spec이라는 값에서 자격 증명 사양을 로드합니다.

credential_spec:
  registry: my-credential-spec

EXAMPLE GMSA CONFIGURATION

서비스에 대한 gMSA 자격 증명 사양을 구성할 때는 다음 예제와 같이 config로 자격 증명 사양 만 지정하면 됩니다.

version: "3.8"
services:
  myservice:
    image: myimage:latest
    credential_spec:
      config: my_credential_spec

configs:
  my_credentials_spec:
    file: ./my-credential-spec.json|

depends_on

서비스 간 Express 종속성, 서비스 종속성은 다음과 같은 동작을 유발합니다.

• docker-compose up은 의존성 순서로 서비스를 시작합니다. 다음 예에서 db와 redis는 web보다 먼저 시작됩니다.

• docker-compose up SERVICE는SERVICE의 종속성을 자동으로 포함합니다. 다음 예에서 docker-compose up web은 db와 redis도 작성하고 시작합니다.

• docker-compose stop은 종속성 순서로 서비스를 중지합니다. 다음 예제에서 web은 db와 redis보다 먼저 중지됩니다.

간단한 예:

version: "3.7"
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

depends_on을 사용할 때 주의해야 할 사항이 몇 가지 있습니다:

• depends_on은 web을 시작하기 전에 db와 redis가 “준비”될 때까지 기다리지 않습니다. 서비스가 준비 될 때까지 기다려야 하는 경우 이 문제에 대한 자세한 내용과 해결 전략은 시작 순서 제어를 참조하십시오.

• 버전 3 은 더 이상 conditions_on의 조건형식을 지원하지 않습니다.

• 버전 3 Compose 파일이 있는 웜 모드에서 스택 배포에는 depends_on 옵션이 무시됩니다.

deploy

Version 3에 만.

서비스 배포 및 실행과 관련된 구성을 지정하십시오. 이것은 docker stack deploy를 사용하여 swarm에 배포 할 때만 적용되며docker-compose up 및docker-compose run에서는 무시됩니다.

version: "3.7"
services:
  redis:
    image: redis:alpine
    deploy:
      replicas: 6
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure

몇 가지 하위 옵션을 사용할 수 있습니다.

ENDPOINT_MODE

스웜에 연결하는 외부 클라이언트에 대한 서비스 검색 방법을 지정하십시오.

Version 3.3에 만.

• endpoint_mode: vip - Docker 는 클라이언트가 네트워크에서 서비스에 도달하기 위한 프런트 엔드 역할을 하는 가상 IP (VIP)를 서비스에 할당합니다. Docker 는 서비스에 참여하는 노드 수 또는 IP 주소 또는 포트에 대한 클라이언트 지식없이 클라이언트와 사용 가능한 작업자 노드간에 요청을 라우팅합니다. (이것이 기본값입니다.)

• endpoint_mode: dnsrr - DNSRR (DNS 라운드 로빈) 서비스 검색은 단일 가상 IP 를 사용하지 않습니다. Docker 는 서비스 이름에 대한 DNS 쿼리가 IP 주소 목록을 반환하고 클라이언트가 이들 중 하나에 직접 연결되도록 서비스에 대한 DNS 항목을 설정합니다. DNS 라운드 로빈은 자체 로드 밸런서를 사용하려는 경우 또는 하이브리드 Windows 및 Linux 응용 프로그램에 유용합니다.

version: "3.7"

services:
  wordpress:
    image: wordpress
    ports:
      - "8080:80"
    networks:
      - overlay
    deploy:
      mode: replicated
      replicas: 2
      endpoint_mode: vip

  mysql:
    image: mysql
    volumes:
       - db-data:/var/lib/mysql/data
    networks:
       - overlay
    deploy:
      mode: replicated
      replicas: 2
      endpoint_mode: dnsrr

volumes:
  db-data:

networks:
  overlay:

endpoint_mode 옵션은 swarm mode CLI 명령 docker service create에서 플래그로 작동합니다. 모든 swarm 관련 docker 명령의 빠른 목록은 Swarm mode CLI 명령을 참조하십시오.

스웜 모드에서의 서비스 검색 및 네트워킹에 대한 자세한 내용은 스웜 모드 항목에서 서비스 검색 구성을 참조하십시오.

LABELS

서비스 레이블을 지정하십시오. 이 레이블은 서비스에서만 설정되고 서비스의 컨테이너에는 설정되지 않습니다.

version: "3.7"
services:
  web:
    image: web
    deploy:
      labels:
        com.example.description: "This label will appear on the web service"

컨테이너에 레이블을 설정하려면 deploy 외부의 labels 키를 사용하십시오:

version: "3.7"
services:
  web:
    image: web
    labels:
      com.example.description: "This label will appear on all containers for the web service"

MODE

global (정확히 swarm node 당 하나의 컨테이너) 또는replicated (지정된 컨테이너 수).
기본값은replicated입니다. (자세한 내용은 Swarm 주제의 Replicated and global services를 참조하십시오.)

version: "3.7"
services:
  worker:
    image: dockersamples/examplevotingapp_worker
    deploy:
      mode: global

PLACEMENT

구속 조건 및 환경 설정의 배치를 지정하십시오. 구문과 사용 가능한 constraints 및 preferences 유형에 대한 자세한 설명은 docker service create documentation 을 참조하십시오.

version: "3.7"
services:
  db:
    image: postgres
    deploy:
      placement:
        constraints:
          - node.role == manager
          - engine.labels.operatingsystem == ubuntu 14.04
        preferences:
          - spread: node.labels.zone

REPLICAS

서비스가 replicated (기본값) 인 경우, 주어진 시간에 실행해야 할 컨테이너 수를 지정하십시오.

version: "3.7"
services:
  worker:
    image: dockersamples/examplevotingapp_worker
    networks:
      - frontend
      - backend
    deploy:
      mode: replicated
      replicas: 6

RESOURCES

리소스 제약 조건을 구성합니다.

참고: 버전 2.x를 3.x로 업그레이드에 설명된 대로 버전 3(cpu_shares, cpu_quota, cpuset, mem_limit, memswap_limit, mem_swappiness) 이전의 파일 작성에서 비 swarm 모드에 대한 이전 자원 제한 조건 옵션을 대체합니다.

이들 각각은 docker service create와 유사한 단일 값입니다.

이 일반적인 예에서, redis서비스는 50M 이하의 메모리와 사용 가능한 처리 시간 (CPU)의 0.50 (단일 코어의 50 %) 이하를 사용하도록 제한되며, 메모리 20M 와 0.25는 CPU 시간을 예약합니다(항상 사용 가능).

version: "3.7"
services:
  redis:
    image: redis:alpine
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 50M
        reservations:
          cpus: '0.25'
          memory: 20M

아래 주제는 스웜의 서비스 또는 컨테이너에 대한 자원 제한 조건을 설정하는 데 사용 가능한 옵션을 설명합니다.

비 swarm 모드 컨테이너에서 리소스를 설정하는 옵션을 찾고 있습니까?

여기에 설명 된 옵션은 deploy키 및 스웜 모드에만 해당됩니다. 비 swarm 배포에서 리소스 제약 조건을 설정하려면 파일 형식 버전 2 CPU, 메모리 및 기타 리소스 옵션 작성을 사용하십시오. 추가 질문이 있으면 GitHub 문제 docker/compose/4513에 대한 토론을 참조하십시오.

Out Of Memory Exceptions (OOME)

서비스 나 컨테이너가 시스템이 사용할 수있는 것보다 많은 메모리를 사용하려고하면 메모리 부족 예외 (OOME)가 발생하고 컨테이너 또는 Docker 데몬이 커널 OOM 킬러에 의해 종료 될 수 있습니다. 이러한 상황이 발생하지 않도록하려면 메모리가 충분한 호스트에서 응용 프로그램을 실행하고 메모리 부족의 위험 이해를 참조하십시오..

RESTART_POLICY

컨테이너가 종료 될 때 컨테이너를 다시 시작할지 여부와 방법을 구성합니다. restart를 대체합니다.

• condition: none, failure 또는 any 중 하나 (기본값: any).
• delay: 재시작 시도 간 대기 시간으로, duration (기본값 : 0)으로 지정됩니다.
• max_attempts: 포기하기 전에 컨테이너를 다시 시작하려고 시도하는 횟수입니다 (기본값: 절대 포기하지 않음). 구성된 window내에서 다시 시작이 실패하면 구성된 max_attempts값에 포함되지 않습니다. 예를 들어, max_attempts가 2로 설정되어 있고 첫 번째 시도에서 재시작이 실패하면 두 번 이상의 재시작이 시도될 수 있습니다.
• window: 재시작 성공 여부를 결정하기 전에 대기하는 시간으로, duration (기본값: 즉시 결정)로 지정됩니다.

version: "3.7"
services:
  redis:
    image: redis:alpine
    deploy:
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s

ROLLBACK_CONFIG

버전 3.7 파일 형식 이상

업데이트 실패시 서비스를 롤백하는 방법을 구성합니다.

• parallelism: 한 번에 롤백 할 컨테이너 수입니다. 0 으로 설정하면 모든 컨테이너가 동시에 롤백됩니다.
• delay: 각 컨테이너 그룹의 롤백 간 대기 시간 (기본값 0)
• failure_action: 롤백에 실패한 경우 수행 할 작업 continue 또는 pause 중 하나 (기본 pause)
• monitor: 실패 (ns|us|ms|s|m|h)를 모니터링하기 위해 각 작업이 업데이트된 후의 기간 (기본값 0).
• max_failure_ratio: 롤백 중에 허용되는 실패율 (기본값 0).
• order: 롤백 중 작업 순서 stop-first (오래된 작업은 새 작업을 시작하기 전에 중지됨) 또는 start-first (새 작업이 먼저 시작되고 실행중인 작업이 잠시 겹침) 중 하나입니다 (기본값: stop-first).

UPDATE_CONFIG

서비스 업데이트 방법을 구성합니다. 롤링 업데이트를 구성하는 데 유용합니다.

• parallelism: 한 번에 업데이트 할 컨테이너 수입니다.
• delay: 컨테이너 그룹 업데이트 사이의 대기 시간입니다.
• failure_action: 업데이트가 실패한 경우 수행 할 작업 continue, rollback 또는 pause 중 하나 (기본값: pause).
• monitor: 실패 (ns|us|ms|s|m|h)를 모니터링하기 위해 각 작업이 업데이트 된 후의 기간 (기본값 0).
• max_failure_ratio: 업데이트 중 허용되는 실패율.
• order: 업데이트 중 작업 순서 stop-first (오래된 작업은 새 작업을 시작하기 전에 중지됨) 또는 start-first (새 작업이 먼저 시작되고 실행중인 작업이 잠시 겹침) 중 하나 (기본 stop-first) 주의: v3.4 이상에서만 지원됩니다.

주의: order는 작성 파일 형식의 v3.4 이상에서만 지원됩니다.

version: "3.7"
services:
  vote:
    image: dockersamples/examplevotingapp_vote:before
    depends_on:
      - redis
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
        delay: 10s
        order: stop-first

NOT SUPPORTED FOR DOCKER STACK DEPLOY

docker-compose up 및 docker-compose run에 대해 지원되는 다음 하위 옵션은 docker stack deploy 또는deploy 키에 대해 지원되지 않습니다.

• build
• cgroup_parent
• container_name
• devices
• tmpfs
• external_links
• links
• network_mode
• restart
• security_opt
• userns_mode

팁: 서비스, 스웜 및 docker-stack.yml 파일의 볼륨을 구성하는 방법 섹션을 참조하십시오. 볼륨은 지원되지만 스웜 및 서비스와 함께 작동하려면 이름이 지정된 볼륨으로 구성되거나 필수 볼륨에 액세스 할 수 있는 노드로 제한되는 서비스와 연결되어 있어야합니다.

devices

장치 매핑 목록 --device docker client create 옵션과 같은 형식을 사용합니다.

devices:
  - "/dev/ttyUSB0:/dev/ttyUSB0"

참고: 이 옵션은 (버전 3) 작성 파일이있는 웜 모드에서 스택 배포 인 경우 무시됩니다.

dns

사용자 지정 DNS 서버 단일 값 또는 목록일 수 있습니다.

dns: 8.8.8.8

dns:
  - 8.8.8.8
  - 9.9.9.9

dns_search

맞춤 DNS 검색 도메인 단일 값 또는 목록 일 수 있습니다.

dns_search: example.com

dns_search:
  - dc1.example.com
  - dc2.example.com

entrypoint

기본 진입점을 재정의합니다.

entrypoint: /code/entrypoint.sh

진입 점은 dockerfile와 비슷한 방식으로 목록이 될 수도 있습니다.

entrypoint:
    - php
    - -d
    - zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
    - -d
    - memory_limit=-1
    - vendor/bin/phpunit

참고: entrypoint를 설정하면 둘 다 ENTRYPOINT Dockerfile 명령으로 서비스 이미지에 설정된 기본 진입 점을 무시합니다. 그리고 이미지의 기본 명령을 지웁니다. - Dockerfile 에 CMD 명령이 있으면 무시됩니다.

env_file

파일에서 환경 변수를 추가하십시오. 단일 값 또는 목록일 수 있습니다.

docker-compose -f FILE로 작성 파일을 지정한 경우,env_file의 경로는 파일이 있는 디렉토리를 기준으로 합니다.

환경 섹션에 선언된 환경 변수가 이 값을 대체합니다. – 해당 값이 비어 있거나 정의되지 않은 경우에도 마찬가지입니다.

env_file: .env

env_file:
  - ./common.env
  - ./apps/web.env
  - /opt/secrets.env

Compose 는 env 파일의 각 줄이 VAR=VAL 형식 일 것으로 예상합니다. #로 시작하는 줄은 주석으로 취급되며 무시됩니다. 빈 줄도 무시됩니다.

# Set Rails/Rack environment
RACK_ENV=development

참고: 서비스에서 build 옵션을 지정하면 환경 파일에 정의된 변수가 빌드 중에 자동으로 표시되지 않습니다 . 빌드 시간 환경 변수를 정의하려면 build의 args 하위 옵션을 사용하십시오.

'VAL'의 값은 그대로 사용되며 전혀 수정되지 않습니다. 예를 들어 값이 따옴표로 묶인 경우 (쉘 변수의 경우와 같이) 따옴표는 Compose 에 전달된 값에 포함됩니다.

리스트에 있는 파일의 순서는 변수에 지정된 값을 두 번 이상 나타나는 값을 결정하는 데 중요합니다. 목록의 파일은 위에서 아래로 처리됩니다. a.env 파일에 지정되고 b.env 파일에 다른 값이 할당된 동일한 변수에 대해 b.env가 아래에 (나중에) 나열되면 b.env의 값이 나타납니다. 예를 들어, docker-compose.yml에 다음과 같은 선언이 있습니다.

services:
  some-service:
    env_file:
      - a.env
      - b.env

그리고 다음 파일들:

# a.env
VAR=1

그리고

# b.env
VAR=hello

$VAR 는 hello 입니다.

environment

환경 변수를 추가하십시오. 배열이나 사전을 사용할 수 있습니다. 모든 부울 값; true, false, yes no 는 YAM 파서에 의해 True 또는 False 로 변환되지 않도록 따옴표로 묶어야합니다.

키만있는 환경 변수는 Compose 가 실행중인 시스템의 해당 값으로 해석되므로 비밀 또는 호스트 별 값에 도움이 될 수 있습니다.

environment:
  RACK_ENV: development
  SHOW: 'true'
  SESSION_SECRET:

environment:
  - RACK_ENV=development
  - SHOW=true
  - SESSION_SECRET

참고: 서비스에서 build 옵션을 지정하면environment에 정의된 변수가 빌드 중에 자동으로 표시되지 않습니다. 빌드 시간 환경 변수를 정의하려면build의 args 하위 옵션을 사용하십시오.

expose

호스트 컴퓨터에 포트를 게시하지 않고 포트를 노출합니다. 링크된 서비스에만 액세스할 수 있습니다. 내부 포트만 지정할 수 있습니다.

expose:
 - "3000"
 - "8000"

external_links

이 'docker-compose.YAM' 밖에서 또는 Compose 외부에서 시작된 컨테이너, 특히 공유 또는 공통 서비스를 제공하는 컨테이너에 대한 링크. external_links는 컨테이너 이름과 링크 별명 (CONTAINER:ALIAS)을 지정할 때 레거시 옵션 `links '와 유사한 의미를 따릅니다.

external_links:
 - redis_1
 - project_db_1:mysql
 - project_db_1:postgresql

참고:

버전 2 이상 파일 형식을 사용하는 경우 외부에서 만든 컨테이너를 연결하는 서비스와 동일한 네트워크 중 하나 이상 링크는 기존 옵션입니다. 대신 networks를 사용하는 것이 좋습니다.

이 옵션은 (버전 3) 작성 파일이있는 웜 모드에서 스택 배치 인 경우 무시됩니다.

extra_hosts

호스트 이름 매핑을 추가하십시오. docker client --add-host 매개 변수와 동일한 값을 사용하십시오.

extra_hosts:
 - "somehost:162.242.195.82"
 - "otherhost:50.31.209.229"

IP 주소와 호스트 이름을 가진 항목이 이 서비스의 컨테이너 내부에 있는 /etc/hosts에 생성됩니다.