【docker系列】docker-compose的YAML配置文件v2、v3版本详解
上一节在我们安装完成Harbor之后,在harbor的安装目录会生成一个docker-compose.yml
文件。这个文件是harbor官方替我们写好的,在harbor的安装目录我们可以用这个文件启动、停止、删除harbor的容器等操作。harbor通过docker compose一共启动了9个容器,所以说能够把harbor的docker-compose.yml
理解清楚,以后我们自己写docker-compose.yml
文件也就游刃有余了。
完整的harbor的docker-compose.yml
我已经上传到这里,大家点击查看。一定先把这个文件全局都看一遍形成一个印象,下面我们再来一一局部解析一下这个docker-compose.yml
文件中定义的配置语法,常用的配置也就这些,遇到新的不会的配置再补充查一下就可以了。
version
version用来表示Compose配置文件语法版本,目前的语法有3个版本,分别为1, 2.x 和 3.x。目前主流的为 3.x版本, 其与docker 1.13.0 及其以上的版本兼容。docker2.x版本的语法仍然在使用中,其与3.x语法并无太大的差异,后面介绍的过程中有差异的部分会重点说明。
version: '2.3'
- 1
image、container_name、restart
services:
log:
image: goharbor/harbor-log:v2.5.0
container_name: harbor-log
restart: always
- 1
- 2
- 3
- 4
- 5
service.log
yaml结构定义了一个服务名称叫log,services下可以定义多个服务- image:log服务使用的docker镜像是goharbor/harbor-log:v2.5.0
- container_name:log服务对应的容器名称设置为harbor-log
- restart:log服务的重启策略是always,参考前面章节《容器自启动与保活》
cap_add、 cap_drop
cap_drop:
- ALL
cap_add:
- CHOWN
- DAC_OVERRIDE
- SETGID
- SETUID
- 1
- 2
- 3
- 4
- 5
- 6
- 7
cap_drop
ALL
用于去掉容器操作linux内核的能力,因为ALL能力权限过大,出于安全性考虑把它去掉cap_add
用于为容器添加若干能力,CHOWN修改文件属主的能力;SETGID(SETUID)设置用户组ID、用户ID的能力;DAC_OVERRIDE权限更大,包含用户、用户组、ACL操作权限。
这部分用于调整容器操作内核权限、能力的配置。在v3版本中有一点点变化,就是在docker Swarm 模式中,Compose 会忽略这部分参数的值。
volumes
volumes用于定义数据卷,相信学习过《docker数据管理》内容的朋友看下面的配置都不会有任何的问题。如果有问题回去再复习一遍。
volumes:
- /var/log/harbor/:/var/log/docker/:z
- type: bind
source: ./common/config/log/logrotate.conf
target: /etc/logrotate.d/logrotate.conf
- type: bind
source: ./common/config/log/rsyslog_docker.conf
target: /etc/rsyslog.d/rsyslog_docker.conf
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
需要特殊说明的是:z
(小z)表示数据卷的内容可以在容器之间共享,如果是:Z
(大Z)表示数据卷是该容器私有的。
ports
ports完成容器与宿主机之间的端口映射,冒号前面是宿主机端口,冒号后面是容器端口(暴露给宿主机上的其他进程或容器)。
ports:
- 80:8080
- 443:8443
- 1
- 2
- 3
如果宿主机有多网卡多IP、可以指定映射的ip。映射到127.0.0.1
可以避免暴露到外网,在宿主机范围内暴露端口。下面的配置节选自log服务,通过1514端口收集各个服务的日志。
services:
log:
ports:
- 127.0.0.1:1514:10514
- 1
- 2
- 3
- 4
networks
与services同级的networks用于定义网络,sevices下的networks表明该服务所在的容器使用哪个网络。
services:
log:
networks:
- harbor
networks:
harbor:
external: false
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
如上所示定义一个新的网络名称是harbor,external: false
是否使用外部网络, 表示使用harbor这个网络,如果harbor这个网络不存在则新建该网络。external: true
则docker-compose up
不会尝试新建网络,而是使用已经存在的网络(需要自己事先将网络创建好),网络不存在就报错。
depends_on
下文示例的depends_on表示registry容器需要在log服务对应的容器启动之后才能启动,用于控制服务之间依赖关系及容器启动顺序。
registry:
depends_on:
- log
- 1
- 2
- 3
- 4
- 5
logging
配置日志选项,registry服务将自己的syslog日志发送到tcp://localhost:1514
(上文中的log服务容器),并为日志打上标签registry。
registry:
logging:
driver: "syslog"
options:
syslog-address: "tcp://localhost:1514"
tag: "registry"
- 1
- 2
- 3
- 4
- 5
- 6
目前支持三种日志驱动类型,在linux操作系统/var/log
下面的那些日志文件,基本都属于syslog。
driver: "json-file"
driver: "syslog"
driver: "none"
- 1
- 2
- 3
env_file、environment
下文中的env_file表示在docker-compose.yml
同级目录下的common/config/registryctl
有一个文件叫做env
registryctl:
env_file:
- ./common/config/registryctl/env
- 1
- 2
- 3
- 4
- 5
我们来看一下这个env文件的内容,定义了2个环境变量
CORE_SECRET=B4lHZYehQTkjRMF6
JOBSERVICE_SECRET=lplIX7YkWJayvNkW
- 1
- 2
这个env_file相当于如下的environment环境变量定义,环境变量通常是给容器使用的(在构建及启动脚本中也可以使用)。相当于修改/etc/profile
的export
环境变量的操作。
registryctl:
environment:
CORE_SECRET=B4lHZYehQTkjRMF6
JOBSERVICE_SECRET=lplIX7YkWJayvNkW
- 1
- 2
- 3
- 4
shm_size
shm_size创建容器时候指定最小共享内存,对于内存有要求的容器服务要修改这个值。
postgresql:
shm_size: '1gb'
- 1
- 2
- 3
v3和v2版本的区别总结
- 由于 Swarm mode 中网络的特殊性,Compose v3版本配置文件中一些声明比如
expose
和links
会被忽略。注意:不能再使用 link 定义的网络别名来进行容器互联,可以使用服务名连接。 - Compose v3版本配置文件中
volumes_from
不再支持,只能使用命名数据卷来实现容器数据的持久化和共享。 - Compose v3版本配置文件中引入了
deploy
指令,可对Swarm mode中服务部署的进行细粒度控制,包括resources
:定义cpu_shares
,cpu_quota
,cpuset
,mem_limit
,memswap_limit
等容器资源限制指令。(v1/v2中相应指令在v3版本的配置文件中不再被支持)restart_policy
:定义服务的重启条件 (v1/v2中restart
指令在v3版本的配置文件中不再被支持)
文章来源: zimug.blog.csdn.net,作者:字母哥哥,版权归原作者所有,如需转载,请联系作者。
原文链接:zimug.blog.csdn.net/article/details/125608404
- 点赞
- 收藏
- 关注作者
评论(0)