compose支持两种共享通用配置的方法:
1.通过使用多个compose文件扩展整个compose文件
2.使用extends字段扩展单个服务
多个compose文件
使用多个compose文件可以为不同的环境或不同的工作流自定义compose应用程序。
理解多compose文件
默认下,compose读取两个文件,一个docker-compose.yml和一个可选的docker-compose.override.yml文件。通常来说,docker-compose.yml包含基本的配置。而override文件包含覆盖已存在服务或整个新服务的配置。
如果一个服务在两个文件中都有定义,那么compose就使用在”添加和覆盖配置”中描述的规则合并配置。
要使用多个override文件或不同名称的override文件,可以使用-f选项指定文件列表。compose根据在命令行指定的顺序来合并它们。
当使用多个配置文件时,必须确保文件中所有的路径是相对于base compose文件的(-f指定的第一个compose文件)。这样要求是因此override文件不需要是一个有效的compose文件。override文件可以只包含配置中的小片段。跟踪一个服务的片段是相对于哪个路径的是很困难的且令人困惑的,所以要保持路径容易理解,所以的路径必须定义为相对于base文件的路径。
示例
在本段介绍两个常见的多compose文件用例:为不同的环境更改compose app和针对compose app运行管理任务。
不同的环境
使用多文件的一个常见用例是更改用于类生产环境(可能是生产环境,临时环境或配置项)的开发compose app。要支持这样的更改,可以把一个compose配置文件分割为多个不同的文件:
从定义服务的规范配置的基本文件开始。
docker-compose.yml
- web:
- image: example/my_web_app:latest
- links:
- – db
- – cache
- db:
- image: postgres:latest
- cache:
- image: redis:latest
在下面这个示例中开发配置暴露了一些端口到主机上,挂载代码目录到容器然后构建web镜像。
docker-compose.override.yml
- web:
- build: .
- volumes:
- – ‘.:/code’
- ports:
- – 8883:80
- environment:
- DEBUG: ‘true’
- db:
- command: ‘-d’
- ports:
- – 5432:5432
- cache:
- ports:
- – 6379:6379
当执行docker-compose up命令时它会自动读取这个override文件。
现在我们创建另一个用于生产环境的override文件。
docker-compose.prod.yml
- web:
- ports:
- – 80:80
- environment:
- PRODUCTION: ‘true’
- cache:
- environment:
- TTL: ‘500’
要使用这个生产compose文件部署,运行如下命令:
- docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d
这个将会使用docker-compose.yml和docker-compose.prod.yml(没有用到docker-compose.override.yml)来部署这三个服务。
管理任务
另一个常见的用例是针对在compose app中的一个或多个服务运行adhoc或管理任务。这个示例演示备份运行中的数据库。
docker-compose.yml
- web:
- image: example/my_web_app:latest
- links:
- – db
- db:
- image: postgres:latest
在docker-compose.admin.yml中添加一个新服务用到导出数据库或备份。
- dbadmin:
- build: database_admin/
- links:
- – db
要启动一个正常的环境运行docker-compose up -d。要备份数据库,运行:
- docker-compose -f docker-compose.yml -f docker-compose.admin.yml
- run dbadmin db-backup
扩展服务
docker compose的extends关键词能够在不同的文件或甚至完全不同的项目之间共享通用的配置。如果有几个重用通用配置项集的服务,则扩展服务非常有用。使用extends你可以在一个地方定义一个通用的服务选项集然后在任何地方引用它。
注意:不能使用extends来共享links, volumes_from和depends_on配置。这是为了避免隐式依赖 – 始终在本地定义links和volumes_fromm。这确保了当读取当前文件时服务之间的依赖是清晰可见的。在本地定义这些还确保对引用文件的更改不会导致破坏。
理解extends配置
当在docker-compose.yml定义任何服务时,可以像这样声明扩展另一个服务:
- web:
- extends:
- file: common-services.yml
- service: webapp
这告诉compose重用定义在comm-services.yml文件的webapp服务配置。假设common-services.yml看起来像这样的:
- webapp:
- build: .
- ports:
- – "8000:8000"
- volumes:
- – "/data"
在这种情况下,docker-compose.yml中定义的web服务将与webapp配置一样。
我们可以进一步在本地定义(或重新定义)docker-compose.yml:
- web:
- extends:
- file: common-services.yml
- service: webapp
- environment:
- – DEBUG=1
- cpu_shares: 5
- important_web:
- extends: web
- cpu_shares: 10
也可以定义其它服务并在web服务链接它们:
- web:
- extends:
- file: common-services.yml
- service: webapp
- environment:
- – DEBUG=1
- cpu_shares: 5
- links:
- – db
- db:
- image: postgres
示例用例
当多个服务有一个通用的配置时,扩展单个服务非常有用。下面示例是有两个服务的compose app:一个web应用程序和一个queue worker。两个服务使用相同的代码和共享许多配置项。
在common.yml我们定义通用的配置:
- app:
- build: .
- environment:
- CONFIG_FILE_PATH: /code/config
- API_KEY: xxxyyy
- cpu_shares: 5
在docker-compose.yml文件我们定义使用通用配置的具体服务:
- webapp:
- extends:
- file: common.yml
- service: app
- command: /code/run_web_app
- ports:
- – 8080:8080
- links:
- – queue
- – db
- queue_worker:
- extends:
- file: common.yml
- service: app
- command: /code/run_worker
- links:
- – queue
添加和覆盖配置
compose从original服务复制配置到local服务。如果配置项定义在original服务和local服务中,local服务的值替换或扩展original服务的值。
对于单值选项如image,command或mem_limit,新值替换旧值。
- # original service
- command: python app.py
- # local service
- command: python otherapp.py
- # result
- command: python otherapp.py
注意:当使用的是version 1的compose文件格式时,build和image两个选项,在local服务使用一个选项会导致compose忽略另一个如果定义在original服务的选项。
例如,如果orginal服务定义了image: webapp且local服务定义了build: . 那么结果是服务有build: .选项没有image选项。
这是因为在verion 1文件中build和image不能一起使用。
对于多值选项ports,expose,external_link,dns,dns_search物tmpfs,compose连接两组值:
- # original service
- expose:
- – "3000"
- # local service
- expose:
- – "4000"
- – "5000"
- # result
- expose:
- – "3000"
- – "4000"
- – "5000"
对于environment, labels, volumes和devices,compose以本地定义的值优先原则来合并它们:
- # original service
- environment:
- – FOO=original
- – BAR=original
- # local service
- environment:
- – BAR=local
- – BAZ=local
- # result
- environment:
- – FOO=original
- – BAR=local
- – BAZ=local