Detailed explanation of Docker Compose configuration file
Reprint linkimage
services:
web:
image: hello-world
The second level label under the services label is web, the name is user-defined, it is the service name. image is the image name or image ID of the specified service. If the image does not exist locally, Compose will try to pull the image.
build
In addition to the specified image, the service can also perform the build task based on a Dockerfile when it is started with up. This build tag is build, which can specify the path to the folder where the Dockerfile is located. Compose will use it to automatically build this image and then use this image to start the service container.
build: /path/to/build/dir
It can also be a relative path, as long as the context is determined, the Dockerfile can be read
build: ./dir
Set the context root directory, and then specify the Dockerfile based on that directory
build:
context: ../
dockerfile: path/of/Dockerfile
Note that build is a directory. If you want to specify a Dockerfile file, you need to use the dockerfile tag in the child tag of the build tag, as in the example above. If you specify both the image and build tags, Compose will build the image and name the image the name after image.
build: ./dir
image: webapp:tag
Since the build task can be defined in docker-compose.yml, the arg label must be indispensable, just like the ARG instruction in the Dockerfile, it can specify environment variables during the build process, but cancel it after the build is successful, in docker-compose. The yml file also supports such writing:
build:
context: .
args:
buildno: 1
password: secret
The following writing method is also supported. Generally speaking, the following writing method is more suitable for reading
build:
context: .
args:
- buildno=1
- password=secret
Unlike ENV, ARG allows null values. E.g:
args:
- buildno
- password
so that the build process can assign values to them
Note: YAML boolean values (true, false, yes, no, on, off) must be enclosed in quotes (single or double quotes), otherwise they will be parsed as strings.
command
Use command to override the default command executed after the container starts.
command: bundle exec thin -p 3000
It can also be written in a format similar to that in Dockerfile:
command: [bundle, exec, thin, -p, 3000]
container_name
As mentioned earlier, the container name format of Compose is: <project name><service name><serial number> Although you can customize the project name and service name, if you want to fully control the naming of the container, you can use this tag to specify:
container_name: app
The name of the container is then specified as app.
depends_on
When using Compose, the biggest advantage is that there are fewer startup commands, but the order in which the project container is started is generally required. If the container is started directly from top to bottom, it will inevitably fail to start due to container dependencies. For example, if the application container is started when the database container is not started, the application container will exit because the database cannot be found. In order to avoid this situation, we need to add a label, depends_on, which solves the dependency of the container and the sequence of startup. The problem. For example, the following container will start the redis and db services first, and finally start the web service:
version: '2'
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres
Note that by default, when the web service is started by docker-compose up web, the redis and db services are also started because the dependencies are defined in the configuration file.
dns
Same use as the --dns parameter, the format is as follows:
dns: 8.8.8.8
Can also be a list:
dns:
- 8.8.8.8
- 9.9.9.9
In addition, the configuration of dns_search is also similar:
dns_search: example.com
dns_search:
- dc1.example.com
- dc2.example.com
tmpfs
Mount the temporary directory inside the container, which has the same effect as the run parameter:
tmpfs: /run
tmpfs:
- /run
- /tmp
entrypoint
There is an instruction called ENTRYPOINT instruction in Dockerfile, which is used to specify the access point. Chapter 4 has compared the difference with CMD. Access points can be defined in docker-compose.yml, overriding the definitions in Dockerfile:
entrypoint: /code/entrypoint.sh
The format is similar to Docker, but can also be written like this:
entrypoint:
- php
- -d
- zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so
- -d
- memory_limit=-1
- vendor/bin/phpunit
env_file
Remember the .env file mentioned earlier, this file can set Compose's variables. In docker-compose.yml, a file dedicated to storing variables can be defined. If a configuration file is specified via docker-compose -f FILE, the path in env_file will use the configuration file path.
If any variable names conflict with the environment directive, the latter will prevail. The format is as follows:
env_file: .env
Or set multiple according to docker-compose.yml:
env_file:
- ./common.env
- ./apps/web.env
- /opt/secrets.env
It should be noted that the environment variables mentioned here are for the Compose of the host. If there is a build operation in the configuration file, these variables will not enter the construction process. If you want to use variables in the construction, it is still the first choice. arg tag.
environment
It is completely different from the env_file label above, but somewhat similar to arg. The function of this label is to set image variables, which can save variables into the image, which means that the started container will also contain these variable settings, which is similar to arg. The biggest difference. Variables of the general arg label are only used during the build process. The environment, like the ENV instruction in the Dockerfile, will always save the variable in the image and container, similar to the effect of docker run -e.
environment:
RACK_ENV: development
SHOW: 'true'
SESSION_SECRET:
environment:
- RACK_ENV=development
- SHOW=true
- SESSION_SECRET
expose
This label is the same as the EXPOSE instruction in the Dockerfile, used to specify the exposed ports, but it is only for reference. In fact, the port mapping of docker-compose.yml also needs a label such as ports.
expose:
- "3000"
- "8000"
external_links
In the process of using Docker, we will have many containers that are started with docker run alone. In order for Compose to connect to these containers that are not defined in docker-compose.yml, we need a special label, external_links, which allows Compose projects to Containers inside are connected to containers outside the project configuration (provided that at least one of the outer containers is connected to the same network as the service inside the project). The format is as follows:
external_links:
- redis_1
- project_db_1:mysql
- project_db_1:postgresql
extra_hosts
Adding a hostname tag is to add some records to the /etc/hosts file, similar to the --add-host of the Docker client:
extra_hosts:
- "somehost:162.242.195.82"
- "otherhost:50.31.209.229"
View the hosts inside the container after startup:
162.242.195.82 somehost
50.31.209.229 otherhost
labels
Adding metadata to the container has the same meaning as the LABEL instruction of the Dockerfile. The format is as follows:
labels:
com.example.description: "Accounting webapp"
com.example.department: "Finance"
com.example.label-with-empty-value: ""
labels:
- "com.example.description=Accounting webapp"
- "com.example.department=Finance"
- "com.example.label-with-empty-value"
links
Remember the depends_on above, that label solves the startup sequence problem, this label solves the container connection problem, and has the same effect as the Docker client's --link, which will connect to containers in other services. The format is as follows:
links:
- db
- db:database
- redis
The alias used will be automatically created in /etc/hosts in the service container. E.g:
172.12.2.186 db
172.12.2.186 database
172.12.2.187 redis
Corresponding environment variables will also be created.
logging
This tag is used to configure the logging service. The format is as follows:
logging:
driver: syslog
options:
syslog-address: "tcp://192.168.0.42:123"
The default driver is json-file. Only json-file and journald can display logs through docker-compose logs. There are other ways to view logs, but Compose does not currently support them. Optional values can be specified using options. For more information on this you can read the official documentation: https://docs.docker.com/engine/admin/logging/overview/
pid
pid: "host"
Set the PID mode to host PID mode to share the process namespace with the host system. Containers using this tag will be able to access and manipulate the namespaces of other containers and hosts.
ports
The label of the mapped port. Use the HOST:CONTAINER format or just specify the port of the container, and the host will randomly map the port.
ports:
- "3000"
- "8000:8000"
- "49100:22"
- "127.0.0.1:8001:8001"
Note: When mapping ports using the HOST:CONTAINER format, you may get incorrect results if you use a container port less than 60, because YAML will parse numbers in the format xx:yy as hexadecimal. So it is recommended to use string format.
security_opt
Override the default label for each container. Simply put, it is a label that manages all services. For example, set the user tag value of all services to USER.
security_opt:
- label:user:USER
- label:role:ROLE
stop_signal
Set another signal to stop the container. By default SIGTERM is used to stop the container. To set another signal you can use the stop_signal tag.
stop_signal: SIGUSR1
volumes
To mount a directory or an existing data volume container, you can directly use the format [HOST:CONTAINER], or use the format [HOST:CONTAINER:ro]. For the container, the data volume is read-only Yes, this can effectively protect the host's file system. Compose's data volume specified path can be a relative path, use . or .. to specify a relative directory. The format of the data volume can be in any of the following forms:
volumes:
// 只是指定一个路径，Docker 会自动在创建一个数据卷（这个路径是容器内部的）。
- /var/lib/mysql
// 使用绝对路径挂载数据卷
- /opt/data:/var/lib/mysql
// 以 Compose 配置文件为中心的相对路径作为数据卷挂载到容器。
- ./cache:/tmp/cache
// 使用用户的相对路径（~/ 表示的目录是 /home/<用户目录>/ 或者 /root/）。
- ~/configs:/etc/configs/:ro
// 已经存在的命名的数据卷。
- datavolume:/var/lib/mysql
If you don't use the host's path, you can specify a volume_driver.
volume_driver: mydriver
volumes_from
To mount data volumes from other containers or services, the optional parameters are: ro or: rw, the former indicates that the container is read-only, and the latter indicates that the container is readable and writable to the data volume. Read and write by default.
volumes_from:
- service_name
- service_name:ro
- container:container_name
- container:container_name:rw
cap_add, cap_drop
Add or remove kernel functionality for containers. The detailed information is explained in the previous container chapter and will not be repeated here.
cap_add:
- ALL
cap_drop:
- NET_ADMIN
- SYS_ADMIN
cgroup_parent
Specifies the parent cgroup of a container.
cgroup_parent: m-executor-abcd
devices
Device mapping list. Similar to the --device parameter of the Docker client.
devices:
- "/dev/ttyUSB0:/dev/ttyUSB0"
extends
This tag can extend another service. The extended content can be from the current file or from other files. In the case of the same service, the later ones will selectively overwrite the original configuration.
extends:
file: common.yml
service: webapp
Users can use this tag anywhere, as long as the content of the tag contains two values, file and service. The value of file can be a relative or absolute path. If the value of file is not specified, Compose will read the information of the current YML file.
network_mode
The network mode is similar to the --net parameter of the Docker client, except that there is a relatively more service:[service name] format. E.g:
network_mode: "bridge"
network_mode: "host"
network_mode: "none"
network_mode: "service:[service name]"
network_mode: "container:[container name/id]"
You can specify the network that uses the service or container.
networks
Join the specified network, the format is as follows:
services:
some-service:
networks:
- some-network
- other-network
There is also a special sub-tag aliases on this tag, which is a tag used to set service aliases, for example:
services:
some-service:
networks:
some-network:
aliases:
- alias1
- alias3
other-network:
aliases:
- alias2
The same service can have different aliases on different networks.
other
There are also these tags: cpu_shares, cpu_quota, cpuset, domainname, hostname, ipc, mac_address, mem_limit, memswap_limit, privileged, read_only, restart, shm_size, stdin_open, tty, user, working_dir These are all single-valued tags, similar to The effect of using docker run.
cpu_shares: 73
cpu_quota: 50000
cpuset: 0,1
user: postgresql
working_dir: /code
domainname: foo.com
hostname: foo
ipc: host
mac_address: 02:42:ac:11:65:43
mem_limit: 1000000000
memswap_limit: 2000000000
privileged: true
restart: always
read_only: true
shm_size: 64M
stdin_open: true
tty: true