Let's take a look at a document
version: '2' services: web: image: dockercloud/hello-world ports: - 8080 networks: - front-tier - back-tier redis: image: redis links: - web networks: - back-tier lb: image: dockercloud/haproxy ports: - 80:80 links: - web networks: - front-tier - back-tier volumes: - /var/run/:/var/run/ networks: front-tier: driver: bridge back-tier: driver: bridge
You can see that a standard configuration file should contain three parts: version, services, and networks. The most important part is services and networks. Let’s first look at the writing rules of services.
1. image
services: web: image: hello-world
The second level tag under the services tag is web. This name is customized by the user and 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.
For example, the following formats are all possible:
image: redis image: ubuntu:14.04 image: tutum/influxdb image: :4000/postgresql image: a4bc65fd
2. build
In addition to being based on the specified image, the service can also perform build tasks based on a Dockerfile when starting 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 the image and then use this image to start the service container.
build: /path/to/build/dir
It can also be a relative path, and the Dockerfile can be read as long as the context is determined.
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 the 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 image and build tags, Compose will build the image and name the name after image.
build: ./dir image: webapp:tag
Since you can define the build task in , the arg tag is indispensable, just like the ARG directive in Dockerfile. It can specify environment variables during the build process, but it is canceled after the build is successful. This way of writing is also supported in the file:
build: context: . args: buildno: 1 password: secret
The following writing method is also supported, and generally speaking, the following writing method is more suitable for reading.
build: context: . args: - buildno=1 - password=secret
Unlike ENV, ARG allows null values. For example:
args: - buildno - password
This way the build process can assign values to them.
Note: YAML's boolean value (true, false, yes, no, on, off) must be enclosed in quotes (single and double quotes are OK), otherwise it will be parsed as a string.
3. command
Use command to override the commands executed by default after the container is started.
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]
4.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
In this way, the name of the container is specified as app.
5.depends_on
When using Compose, the biggest advantage is to reduce startup commands, but the order of startup of project containers is generally required. If the container is started directly from top to bottom, it will inevitably fail due to container dependency issues.
For example, when the database container is not started, the application container will exit because the database cannot be found. In order to avoid this, we need to add a tag, which is depends_on. This tag solves the problem of container dependency and startup sequence.
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 starting a web service using docker-compose up web, the two services redis and db services are also started, because the dependencies are defined in the configuration file.
It is used the same as the --dns parameter, and the format is as follows:
dns: 8.8.8.8
It can also be a list:
dns: - 8.8.8.8 - 9.9.9.9
In addition, the configuration of dns_search is similar:
dns_search: dns_search: - -
7. tmpfs
Mounting a temporary directory inside the container has the same effect as the run parameters:
tmpfs: /run tmpfs: - /run - /tmp
8. entrypoint
There is a command in the Dockerfile called the ENTRYPOINT instruction, which is used to specify the access point. Chapter 4 has compared the difference with CMD.
You can define an access point in the Dockerfile to override the definitions in the
entrypoint: /code/
The format is similar to Docker, but it can also be written like this:
entrypoint: - php - -d - zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20100525/ - -d - memory_limit=-1 - vendor/bin/phpunit
9.env_file
Remember the .env file mentioned above, which can set the Compose variables. In , you can define a file that specifically stores variables.
If a configuration file is specified via docker-compose -f FILE, the path in env_file uses the configuration file path.
If there is a variable name conflicting with the environment directive, the latter shall prevail. The format is as follows:
env_file: .env
Or set multiple according to:
env_file: - ./ - ./apps/ - /opt/
Note 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 build process. If you want to use variables in the build, the arg tag just mentioned earlier is the first choice.
10. environment
It is completely different from the env_file tag above, but it is somewhat similar to arg. The function of this tag is to set mirror variables, which can save variables into the mirror. That is to say, the startup container will also contain these variable settings, which is the biggest difference from arg.
Generally, variables of arg tags are used only during the construction process. Environment, like the ENV directive in Dockerfile, will keep variables in mirrors and containers, similar to the effect of docker run -e.
environment: RACK_ENV: development SHOW: 'true' SESSION_SECRET: environment: - RACK_ENV=development - SHOW=true - SESSION_SECRET
11. expose
This tag is the same as the EXPOSE directive in Dockerfile, which is used to specify the exposed port, but is only used as a reference. In fact, port mapping requires tags like ports.
expose: - "3000" - "8000"
12. external_links
During the process of using Docker, we will have many containers started separately using docker run. In order to enable Compose to connect these containers that are not defined in it, we need a special tag, which is external_links, which allows the containers in the Compose project to connect to those containers outside the project configuration (provided that at least one of the external containers must be connected to the same network as the service in the project).
The format is as follows:
external_links: - redis_1 - project_db_1:mysql - project_db_1:postgresql
13. extra_hosts
To add a host name tag, add some records to the /etc/hosts file, similar to the --add-host of Docker client:
extra_hosts: - "somehost:162.242.195.82" - "otherhost:50.31.209.229"
After startup, check the container's internal hosts:
162.242.195.82 somehost 50.31.209.229 otherhost
14. labels
Adding metadata to the container means the same as the LABEL instruction of Dockerfile, and the format is as follows:
labels: : "Accounting webapp" : "Finance" -with-empty-value: "" labels: - "=Accounting webapp" - "=Finance" - "-with-empty-value"
15. links
Remember the depends_on above. That tag solves the startup sequence problem. This tag solves the container connection problem. It has the same effect as the --link of Docker client, and 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. For example:
172.12.2.186 db 172.12.2.186 database 172.12.2.187 redis
The corresponding environment variables will also be created.
16. logging
This tag is used to configure logging services. The format is as follows:
logging: driver: syslog options: syslog-address: "tcp://192.168.0.42:123"
17. pid
pid: "host"
Set PID mode to host PID mode and share the process namespace with the host system. Containers use this tag to access and manipulate the namespaces of other containers and hosts.
18. ports
Map the tags of the port.
Using the HOST:CONTAINER format or just specifying the port of the container, the host will randomly map the port.
ports: - "3000" - "8000:8000" - "49100:22" - "127.0.0.1:8001:8001"
Note: When using the HOST:CONTAINER format to map ports, if you use a container port less than 60, you may get the wrong result, because YAML will parse xx:yy, the number format of this number is 60. Therefore, it is recommended to use string format.
19. security_opt
Overwrite the default label for each container. Simply put, it is the 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
20. stop_signal
Set another signal to stop the container. By default, SIGTERM stop container is used. To set another signal, you can use the stop_signal tag.
stop_signal: SIGUSR1
21. volumes
To mount a directory or an existing data volume container, you can directly use the format like [HOST:CONTAINER], or use the format like [HOST:CONTAINER:ro]. For the container, the data volume is read-only, which can effectively protect the host's file system.
The path specified by Compose's data volume can be a relative path, using . or … to specify a relative directory.
The format of the data volume can be in the following forms:
volumes: // Just specify a path, Docker will automatically create a data volume (this path is inside the container). - /var/lib/mysql // Use absolute path to mount the data volume - /opt/data:/var/lib/mysql // The relative path centered on the Compose configuration file is mounted to the container as the data volume. - ./cache:/tmp/cache // Use the user's relative path (the directory represented by ~/ is /home/<user directory>/ or /root/). - ~/configs:/etc/configs/:ro // Already named data volumes. - datavolume:/var/lib/mysql
If you do not use the host's path, you can specify a volume_driver.
volume_driver: mydriver
22. volumes_from
Mounting a data volume from other containers or services, the optional parameters are :ro or :rw. The former means the container is read-only, and the latter means that the container is readable and writable to the data volume. By default, it is readable and writable.
volumes_from: - service_name - service_name:ro - container:container_name - container:container_name:rw
23. cap_add, cap_drop
Add or remove kernel functions 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
24. cgroup_parent
Specifies the parent cgroup of a container.
cgroup_parent: m-executor-abcd
25. devices
Device mapping list. Similar to the --device parameter of Docker client.
devices: - "/dev/ttyUSB0:/dev/ttyUSB0"
26. extends
This tag can extend another service, and the extension content can be from the current file or from other files. In the case of the same service, the later generation will selectively overwrite the original configuration.
extends: file: service: webapp
Users can use this tag anywhere, as long as the tag content contains two values: file and service. The value of the file can be a relative or absolute path. If the value of the file is not specified, Compose will read the information of the current YML file.
More operation details are introduced in the following section 12.3.4.
27. network_mode
The network mode is similar to the --net parameter of Docker client, but it has a relatively additional format of service:[service name].
For example
network_mode: "bridge" network_mode: "host" network_mode: "none" network_mode: "service:[service name]" network_mode: "container:[container name/id]"
You can specify a network that uses services or containers.
28. networks
Join the specified network, the format is as follows:
services: some-service: networks: - some-network - other-network
There is also a special subtitle aliases about this tag, which is a tag used to set service alias, 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.
29. Others
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
The above are all single-value tags, similar to the effect of using docker run.
cpu_shares: 73 cpu_quota: 50000 cpuset: 0,1 user: postgresql working_dir: /code domainname: 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
Summarize
The above is personal experience. I hope you can give you a reference and I hope you can support me more.