本文是基于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
包含Dockerfile的目录的路径,或者git存储库的URL。
当提供的值是相对路径时,它将被解释为相对于Compose文件的位置。该目录还是发送到Docker守护程序的构建上下文。
Compose用生成的名称构建并标记它,然后使用该镜像。
build: context: ./dir
备用Dockerfile。
Compose使用一个替代文件进行构建。还必须指定一个构建路径。
build: context: . dockerfile: Dockerfile-alternate
添加构建镜像的参数,环境变量只能在构建过程中访问。
首先,在Dockerfile中指定要使用的参数:
ARG buildno ARG gitcommithash RUN echo "Build number: $buildno" RUN echo "Based on commit: $gitcommithash"
然后在args键下指定参数。 你可以传递映射或列表:
build: context: . args: buildno: 1 gitcommithash: cdc3b19 12345 build: context: . args: - buildno=1 - gitcommithash=cdc3b19
可以在指定构建参数时忽略该值,在这种情况下,构建时的值就是运行Compose的环境中的值。
args: - buildno - gitcommithash
注
:YAML布尔值(true,false,yes,no,on,off)必须用引号括起来,这样分析器会将它们解释为字符串。
注意
:此选项是v3.2中的新增功能
指定缓存的镜像列表。
(等同于 docker container build –cache_from 的作用)
build: context: . cache_from: - alpine:latest - corp/web_app:3.14
注意
:此选项是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: "" 123456 build: context: . labels: - "com.example.description=Accounting webapp" - "com.example.department=Finance" - "com.example.label-with-empty-value"
注意
:以3.5版文件格式添加
设置 /dev/shm 此构建容器的分区大小。指定为表示字节数的整数值或表示字节值的字符串。(等同于 docker container build –shm-size 的作用)
build: context: . shm_size: '2gb' 123 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。
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:
指定服务标签。这些标签仅在服务上设置,而不在服务的任何容器上设置。
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"
指定 deploy 的模式
version: "3.7" services: worker: image: dockersamples/examplevotingapp_worker deploy: global replicated
如果服务是replicated(默认)服务,请指定在任何给定时间应运行的容器数。
version: "3.7" services: worker: image: dockersamples/examplevotingapp_worker networks: - frontend - backend deploy: mode: replicated replicas: 6
资源限制
在此一般示例中,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。
定义容器重启策略(接受三个参数)
- none 不尝试重启
- on-failure 只有当容器内部应用程序出现问题才会重启
- any 无论如何都会尝试重启(默认)
尝试重启的间隔时间(默认为 0s)
放弃之前尝试重新启动容器的次数(默认值:一直重启)。如果重启未在configure内成功完成 window,则此尝试不会计入配置max_attempts值。例如,如果max_attempts设置为“ 2”,并且第一次尝试重启失败,则可能会尝试两次以上重启。
检查重启是否成功之前的等待时间(即如果容器启动了, 隔多少秒之后去检测容器是否正常, 默认 0s)。
version: "3.7" services: redis: image: redis:alpine deploy: restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s
注意
:3.7版文件格式及更高版本
配置在更新失败的情况下应如何回滚服务。
一次要回滚的容器数。如果设置为0,则所有容器将同时回滚。
每个容器组回滚之间等待的时间(默认为0s)。
回滚失败策略(默认pause)
- continue 跳过
- pause 暂停
更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)(默认为0s)。
在回滚期间可以容忍的故障率(默认为0)。
回滚期间的操作顺序。(默认stop-first)
- stop-first 旧任务,开始新的一个前停止
- start-first 新的任务首先启动,并且正在运行的任务简单地重叠
配置应如何更新服务。对于配置滚动更新很有用。
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
一次更新的容器数。
在更新一组容器之间等待的时间。
如果更新失败,该怎么办。(默认pause)
- continue 继续更新
- rollback 回滚更新
- pause 暂停更新(默认)
更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)(默认为0s)。
更新期间可以容忍的故障率。
注
:仅支持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
原文链接:https://blog.csdn.net/qq_36306519/article/details/130878264?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168994567316800182722850%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=168994567316800182722850&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-25-130878264-null-null.268%5Ev1%5Ekoosearch&utm_term=docker%E3%80%81wordpress%E3%80%81wordpress%E5%BB%BA%E7%AB%99%E3%80%81wordpress%E4%B8%BB%E9%A2%98%E3%80%81%E5%AE%B9%E5%99%A8%E9%95%9C%E5%83%8F%E3%80%81