docker系列—docker-compose.yml详解-(一）

说在前面：

本文是基于version 3

build

在构建时应用的配置选项。
build 可以指定为包含构建上下文路径的字符串：

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

或者，作为具有在context下指定的路径的对象，以及可选的Dockerfile和args：

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

如果你同时指定image和build，则compose会通过build指定的目录构建容器镜像，而构建的镜像名为image中指定的镜像名和标签。

build: ./dir
image: webapp:tag

context

包含Dockerfile的目录的路径，或者git存储库的URL。

当提供的值是相对路径时，它将被解释为相对于Compose文件的位置。该目录还是发送到Docker守护程序的构建上下文。

Compose用生成的名称构建并标记它，然后使用该镜像。

build:
  context: ./dir

dockerfile

备用Dockerfile。

Compose使用一个替代文件进行构建。还必须指定一个构建路径。

build:
  context: .
  dockerfile: Dockerfile-alternate

args

添加构建镜像的参数，环境变量只能在构建过程中访问。
首先，在Dockerfile中指定要使用的参数：

ARG buildno
ARG gitcommithash

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

然后在args键下指定参数。 你可以传递映射或列表：

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

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

可以在指定构建参数时忽略该值，在这种情况下，构建时的值就是运行Compose的环境中的值。

args:
  - buildno
  - gitcommithash

注：YAML布尔值（true，false，yes，no，on，off）必须用引号括起来，这样分析器会将它们解释为字符串。

cache_from

注意：此选项是v3.2中的新增功能
指定缓存的镜像列表。
(等同于 docker container build --cache_from 的作用)

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

lables

注意：此选项是v3.3中的新增功能
使用Docker标签将元数据添加到生成的图像中。您可以使用数组或字典。
我们建议您使用反向DNS表示法，以防止标签与其他软件使用的标签冲突。
(等同于 docker container build --labels 的作用)

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 此构建容器的分区大小。指定为表示字节数的整数值或表示字节值的字符串。(等同于 docker container build --shm-size 的作用)

build:
  context: .
  shm_size: '2gb'

build:
  context: .
  shm_size: 10000000

cap_add，cap_drop

添加或删除容器功能。（ps:没用过）

cap_add:
  - ALL

cap_drop:
  - NET_ADMIN
  - SYS_ADMIN

cgroup_parent

为容器指定一个可选的父cgroup。（ps:没用过）

cgroup_parent: m-executor-abcd

command

覆盖默认命令。

command: bundle exec thin -p 3000

支持 shell 格式和 [] 格式

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

configs

不懂

container_name

指定自定义容器名称，而不是生成的默认名称。
由于Docker容器名称必须唯一，因此如果您指定了自定义名称，则不能将服务扩展到1个以上的容器。尝试这样做会导致错误。
(等同于 docker run --name 的作用)

container_name: my-web-container

credential_spec

不懂

depends_on

定义容器启动顺序 (此选项解决了容器之间的依赖关系， 此选项在 v3 版本中 使用 swarm 部署时将忽略该选项)
示例

• docker-compose up 以依赖顺序启动服务，下面例子中 redis 和 db 服务在 web 启动前启动
• 默认情况下使用 docker-compose up web 这样的方式启动 web 服务时，也会启动 redis 和 db 两个服务，因为在配置文件中定义了依赖关系
• docker-compose stop按依赖关系顺序停止服务。在以下示例中，web在db和redis之前停止。

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

deploy

注意：仅版本3。
指定与部署和运行服务相关的配置, deploy 部分是 docker stack 使用的, docker stack 依赖 docker swarm，并且被忽略docker-compose up和docker-compose run。

endpoint_mode

v3.3 版本中新增的功能, 指定服务暴露的方式

• endpoint_mode: vip-Docker为服务分配了虚拟IP（VIP），该虚拟IP充当客户端访问网络上服务的前端。Docker在客户端与服务的可用工作节点之间路由请求，而客户端却不知道有多少节点正在参与服务或其IP地址或端口。（这是默认设置。）

• endpoint_mode: dnsrr-DNS轮询（DNSRR）服务发现不使用单个虚拟IP。Docker设置服务的DNS条目，以便对服务名称的DNS查询返回IP地址列表，并且客户端直接连接到其中之一。在需要使用自己的负载平衡器或混合Windows和Linux应用程序的情况下，DNS轮询很有用。

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:

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

指定 deploy 的模式

version: "3.7"
services:
  worker:
    image: dockersamples/examplevotingapp_worker
    deploy:
      # 每个集群节点都只有一个容器
      global  
      # 用户可以指定集群中容器的数量(默认)              
      replicated           

placement

不懂

replicas

如果服务是replicated（默认）服务，请指定在任何给定时间应运行的容器数。

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

resources

资源限制
在此一般示例中，redis服务被限制为使用不超过50M的内存和0.50（不超过单个内核的50％）可用处理时间（CPU），并且具有保留20M的内存和0.25CPU时间（始终可用）。

version: "3.7"
services:
  redis:
    image: redis:alpine
    deploy:
      resources:
        # 设置容器的资源限制
        limits:
          cpus: '0.50'
          memory: 50M
        #设置为容器预留的系统资源(随时可用)
        reservations:
          cpus: '0.25'
          memory: 20M

内存不足异常（OOME）
如果服务或容器尝试使用的内存超出系统可用的内存，则可能会遇到内存不足异常（OOME），并且内核OOM杀手可能会杀死容器或Docker守护程序。为防止这种情况的发生，请确保应用程序在具有足够内存的主机上运行。

restart_policy

配置是否以及如何在退出容器时重新启动容器。替换 restart。

condition：

定义容器重启策略(接受三个参数)

• none 不尝试重启
• on-failure 只有当容器内部应用程序出现问题才会重启
• any 无论如何都会尝试重启(默认)

delay：

尝试重启的间隔时间(默认为 0s)

max_attempts：

放弃之前尝试重新启动容器的次数（默认值：一直重启）。如果重启未在configure内成功完成 window，则此尝试不会计入配置max_attempts值。例如，如果max_attempts设置为“ 2”，并且第一次尝试重启失败，则可能会尝试两次以上重启。

window：

检查重启是否成功之前的等待时间(即如果容器启动了, 隔多少秒之后去检测容器是否正常, 默认 0s)。

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：

每个容器组回滚之间等待的时间（默认为0s）。

failure_action：

回滚失败策略（默认pause）

• continue 跳过
• pause 暂停

monitor：

更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)（默认为0s）。

max_failure_ratio：

在回滚期间可以容忍的故障率（默认为0）。

order：

回滚期间的操作顺序。（默认stop-first）

• stop-first 旧任务，开始新的一个前停止
• start-first 新的任务首先启动，并且正在运行的任务简单地重叠

update_config

配置应如何更新服务。对于配置滚动更新很有用。

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

parallelism：

一次更新的容器数。

delay：

在更新一组容器之间等待的时间。

failure_action：

如果更新失败，该怎么办。（默认pause）

• continue 继续更新
• rollback 回滚更新
• pause 暂停更新(默认)

monitor：

更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)（默认为0s）。

max_failure_ratio：

更新期间可以容忍的故障率。

order：

注：仅支持V3.4及更高版本。
更新期间的操作顺序。（默认stop-first）

• stop-first 旧任务，开始新的一个前停止
• start-first 新的任务首先启动，并且正在运行的任务简单地重叠

注意：
支持 docker-compose up 和 docker-compose run 但不支持 docker stack deploy 的子选项

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