1, Foreword

Docker compose has great learning significance in the application of docker container. Docker compose is a sharp tool for integrating and publishing applications. When using docker compose, it is important to know how to arrange the docker compose configuration file.

For the docker compose technology, you can view the official documents Docker Compose

The following contents are based on the downloaded Docker and Docker Compose. Please refer to the official installation tutorial of Docker Compose Install Docker Compose

II Description of construction parameters of Docker Compose configuration file

First, the official provides a docker - compose Standard example of YML configuration file

version: "3"
services:
 
  redis:
    image: redis:alpine
    ports:
      - "6379"
    networks:
      - frontend
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
 
  db:
    image: postgres:9.4
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    deploy:
      placement:
        constraints: [node.role == manager]
 
  vote:
    image: dockersamples/examplevotingapp_vote:before
    ports:
      - 5000:80
    networks:
      - frontend
    depends_on:
      - redis
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
      restart_policy:
        condition: on-failure
 
  result:
    image: dockersamples/examplevotingapp_result:before
    ports:
      - 5001:80
    networks:
      - backend
    depends_on:
      - db
    deploy:
      replicas: 1
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
 
  worker:
    image: dockersamples/examplevotingapp_worker
    networks:
      - frontend
      - backend
    deploy:
      mode: replicated
      replicas: 1
      labels: [APP=VOTING]
      restart_policy:
        condition: on-failure
        delay: 10s
        max_attempts: 3
        window: 120s
      placement:
        constraints: [node.role == manager]
 
  visualizer:
    image: dockersamples/visualizer:stable
    ports:
      - "8080:8080"
    stop_grace_period: 1m30s
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    deploy:
      placement:
        constraints: [node.role == manager]
 
networks:
  frontend:
  backend:
 
volumes:
  db-data:

This file configures multiple services. You need to understand the meaning of configuration options about the meaning of each statement in this configuration file

File configuration
The compose file is a YAML file that defines services, networks, and volumes. The default path for compose files is/ docker-compose.yml

Can be used .yml or .yaml As a file extension  

The service definition contains the configuration applied to each container started for the service, just like passing the command line parameter docker container create. Similarly, the definitions of network and volume are similar to docker network create and docker volume create.

Just as docker container create specifies options in Dockerfile, such as CMD, EXPOSE, VOLUME and ENV, you do not need to specify them docker compose again by default yml.

You can use the Bash class ${VARIABLE} syntax to use environment variables in configuration values.

configuration option

[Official document for detailed description of docker compose configuration]

2.1 version

Specify which version of the yml's composition is developed from.

2.2 image

services: #Define service
  web: # web Services
    image: hello-world # Start the image used by the service

Specifies the image that the container runs in the format:

image: redis # Image name
image: ubuntu:14.04 #Mirroring: version number
image: tutum/influxdb # Individual user level mirroring
image: example-registry.com:4000/postgresql # Image of unofficial warehouse
image: a4bc65fd # Mirror ID

2.3 build

In addition to the specified image, the service can also be based on a "Dockerfile" to execute the build task when starting with up. This build tag is build, which can specify the path of the folder where the Dockerfile is located. Compose will use it to automatically build the image, and then use the 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
build:
  context: /home/transport or./transport#context: specify the path where the Dockerfile file is located
  dockerfile: Dockerfile#Dockerfile: Specifies the name of the dockerfile under the directory specified by the context (dockerfile by default)
args:#args:Dockerf
   args: # Specify input environment variables
    buildno: 1 # environment variable
    password: secret # environment variable
image: webapp:tag # The name of the named image, according to which the image is started

2.4 command overrides the default command started by the container.

command: bundle exec thin -p 3000
command: [bundle, exec, thin, -p, 3000]

2.5 container_name: < project name > < service name > < serial number >

container_name: app # Specify a custom container name instead of the generated default name.

2.6 depends_on set dependency, establish association, and start priority

version: '2'
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

Docker compose up: start services in dependency order. In the following example, start db and redis before starting the web.

Docker compose up SERVICE: automatically include SERVICE dependencies. In the following example, docker compose up Web will also create and start db and redis.

Docker compose stop: stop services in dependency order. In the following example, the web stops before db and redis.

2.7 dns

Custom DNS server, which can be a single value or multiple values of a list.

dns: 8.8.8.8

dns:
  - 8.8.8.8
  - 9.9.9.9

2.8 dns_search

Custom DNS search domain. It can be a single value or a list.

dns_search: example.com
dns_search:
dc1.example.com
dc2.example.com

2.9 tmpfs
Install a temporary file system in the container. It can be a single value or multiple values of a list.

tmpfs: /run
tmpfs:
  - /run
  - /tmp

2.10 entrypoint

entrypoint: /code/entrypoint.sh #Override the container's default entrypoint

2.11 env_file

env_file: .env
Add environment variables from the file. It can be a single value or multiple values of a list.

env_file: # list format

env_file: # List format
  - ./common.env
  - ./apps/web.env
  - /opt/secrets.env

2.12 environment: image variable

Add environment variables. You can use arrays or dictionaries, any Boolean values that need to be enclosed in quotation marks to ensure that the YML parser does not convert them to True or False.

environment:
  RACK_ENV: development
  SHOW: 'true'
  SESSION_SECRET:
 
environment:
  - RACK_ENV=development
  - SHOW=true
  - SESSION_SECRET

2.13 expose

Exposes the definition of the port, but does not map to the host, and is only accessed by the connected service.
Only internal ports can be specified as parameters:

expose:
 - "3000"
 - "8000"

2.14 external_links: link external containers

external_links: # inject the address of the container into the host file

external_links: # Inject the address of the container into the host file
 - redis_1
 - project_db_1:mysql # add alias
 - project_db_1:postgresql

2.15 extra_hosts

Add host name mapping

extra_hosts:
 - "somehost:162.242.195.82"
 - "otherhost:50.31.209.229"

A mapping relationship with ip address and host name will be created in / etc/hosts in the internal container of this service:

162.242.195.82 somehost
50.31.209.229 otherhost

2.16 links: it has the same effect as the -- link of Docker client, and will be connected to containers in other services

links:
 - db
 - db:database
 - redis

2.17 logging

Logging configuration for the service.

logging:
  driver: syslog # Specify the logging driver of the service container. The default value is JSON file. There are three options: Driver: "JSON file" driver: "syslog" driver: "none"
  options:
    syslog-address: "tcp://192.168.0.42:123"

2.18 labels

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"

2.19 pid

Specify pid name

pid: "host"

2.20 port

Specifies the exposure of the port

ports:
 - "3000"
 - "8000:8000"
 - "49100:22"
 - "127.0.0.1:8001:8001"

2. 21 security_opt

Override the default label for each container. In short, it is to manage the tags of all services. For example, set the user tag value of all services to user.

security_opt:
  - label:user:USER
  - label:role:ROLE

label:user:USER # Set the user label of the container
label:role:ROLE # Set the role label of the container
label:type:TYPE # Set the security policy label for the container
label:level:LEVEL # Set the safety level label of the container

2.22 stop_signal

Sets the override signal to stop the container.
stop_signal: SIGUSR1

2.23 volumes

volumes:
  // Just specify a path, and Docker will automatically create a data volume (this path is inside the container).
  - /var/lib/mysql
 
  // Mount data volumes using absolute paths
  - /opt/data:/var/lib/mysql
 
  // The relative path centered on the Compose configuration file is mounted to the container as a data volume.
  - ./cache:/tmp/cache
 
  // Use the relative path of the user (~ / indicates that the directory is / home / < user Directory > / or / root /).
  - ~/configs:/etc/configs/:ro
 
  // A named data volume already exists.
  - datavolume:/var/lib/mysql

2.24 volumes_from

Mount a data volume from another container or service. 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. It is readable and writable by default

volumes_from:
  - service_name
  - service_name:ro
  - container:container_name
  - container:container_name:rw

2.25 cap_add, cap_drop

The ability to add or remove hosts owned by a container

cap_add:
  - ALL
 
cap_drop:
  - NET_ADMIN # Network administrator privileges
  - SYS_ADMIN

2.26 network_mode

Set network mode

network_mode: "bridge"
network_mode: "host"
network_mode: "none"
network_mode: "service:[service name]"
network_mode: "container:[container name/id]"

2.27 ulimits

Override container default ulimits

ulimits:
	nproc: 65535
	nofile:
	soft: 20000
	hard: 40000

2.28 extends

Connect other files

extends:
  file: common.yml
  service: webapp

2.29 networks

Configure the network to which the container is connected, and reference the entry under the top-level networks

services:
  some-service:
    networks:
     - some-network
     - other-network

2.30 stop_grace_period

The specified cannot be processed in the container SIGTERM (Or any stop_signal Signal)，How long to wait before sending SIGKILL Signal close container
stop_grace_period: 1s # Wait 1 second
stop_grace_period: 1m30s # Wait 1 minute 30 seconds
 The default wait time is 10 seconds.

2.31 secrets

Store sensitive data

version: "3.1"
services:

	mysql:
	    image: mysql
	    environment:
 	        MYSQL_ROOT_PASSWORD_FILE: /run/secrets/my_secret
	    secrets:
		    - my_secret
	    secrets:
		   my_secret:
		   file: ./my_secret.txt

2.32 aliases

Other containers on the same network can use the service name or this alias to connect to the service of the corresponding container

2.33 restart

no: Is the default restart policy, and the container will not be restarted under any circumstances.
always: The container always restarts.
on-failure: When the container exits abnormally (the exit status is not 0), the container will be restarted.
unless-stopped: Always restart the container when it exits, but do not consider Docker Container that has been stopped when the daemon starts
restart: "no"
restart: always
restart: on-failure
restart: unless-stopped
 Note: swarm Cluster mode, use restart_policy. 

2.34 devices

Specifies the device mapping list.

devices:
"/dev/ttyUSB0:/dev/ttyUSB0"

2.35 healthcheck

It is used to detect whether the docker service is running healthily.

healthcheck:
test: ["CMD", "curl", "-f", "http://localhost "] # setup checker
interval: 1m30s # Set detection interval
timeout: 10s # Set detection timeout
retries: 3 # Set retry times
start_period: 40s # After startup, how many seconds to start the detection program

2.36 cgroup_parent

Specifying the parent cgroup group for the container means that the resource restrictions of the group will be inherited.

cgroup_parent: m-executor-abcd

2.37 deploy

Specify the configuration related to the deployment and operation of docker swarm cluster service.

understand:
docker run Stand alone operation, single container
docker-compose Running multiple containers on a single machine
docker swarm Cluster service
docker service create  Create a single service in the cluster;
docker stack Managing multiple services in a cluster;

version:"3.7"

services:

   redis:

     image:redis:alpine

     deploy:

       replicas:6

       update_config:

         parallelism:2

         delay:10s

       restart_policy:

         condition:on-failure

There are several sub options to choose from:

endpoint_ Mode (first)

• endpoint_mode: Specifies the service discovery method for connecting to clients outside the group
• endpoint_mode:vip: Docker assigns a virtual IP(VIP) to the service as the "front end" part of the client to access services on the network.
• endpoint_ Mode: DNSRR: the DNS polling (DNSRR) service found that a single virtual IP is not used. Docker sets the DNS entry for the service so that the DNS query for the service name returns a list of IP addresses, and the client connects directly to one of them. If you want to use your own load balancer or mix Windows and Linux applications, DNS polling scheduling The (round robin) function is very practical.

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:

Labels (second)

Specifies the tags of the service, which are set only on the service

version:"3.7"

services:

   web:

     image:web

     deploy:

       labels:

         com.example.description:"Thislabelwillappearonthewebservice"

Set the labels on the container by labeling the labels outside deploy

version:"3.7"

services:

   web:

     image:web

     labels:

       com.example.description:"Thislabelwillappearonallcontainersforthewebservice"

Mode (third)

global: there is only one container per set node

replicated: Specifies the number of containers (default)

version:"3.7"

services:

   worker:

     image:dockersamples/examplevotingapp_worker

     deploy:

       mode:global

Placement (fourth)

Specify constraints and preferences

version:"3.7"

services:

   db:

     image:postgres

     deploy:

       placement:

         constraints:

           - node.role == manager

           - engine.labels.operatingsystem == ubuntu 14.04

         preferences:

          - spread:node.labels.zone

Replicas (fifth)

If the service is replicated (default), you need to specify the number of containers to run

version:"3.7"

services:

   worker:

     image:dockersamples/examplevotingapp_worker

     networks:

       - frontend

       - backend

     deploy:

        mode:replicated

       replicas:6

Resources (sixth)

Configure resource limits

version:"3.7"

services:

   redis:

     image:redis:alpine

     deploy:

       resources:

         limits:

           cpus:'0.50'

           memory:50M

         reservations:

           cpus:'0.25'

            memory:20M

In the example, the redis service limits the use of no more than 50M memory and 0.50 (50%) available processing time (CPU), and reserves 20M memory and 0.25 CPU time.

2.38 endpoint_mode: the way to access cluster services.

endpoint_mode: vip
Docker The cluster serves an external virtual server ip. All requests will pass through this virtual machine ip Arrive at the machine inside the cluster service.
endpoint_mode: dnsrr
#DNS polling (DNSRR). All requests will automatically poll to obtain an ip address in the cluster ip list.

2.39 labels

Use the Docker tag to add metadata to the container. You can use arrays or dictionaries. Similar to LABELS in Dockerfile:

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"

2.40 configs

Use the service configs configuration to give each service corresponding access rights, and support two different syntax.

Note: the configuration must exist or be defined at the top level of this stack file, otherwise the stack deployment will be invalid

• SHORT syntax

The SHORT syntax can only specify the configuration name, which allows the container to access the configuration and install it in / < config_ Name > in the container, both the source name and the target mount point are set to the configuration name.

version: "3.3"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    configs:
      - my_config
      - my_other_config
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

The above example uses SHORT syntax to grant redis service access to my_config and my_other_config and my_other_config is defined as an external resource, which means that it has been defined in Docker. It can be deployed through the docker config create command or through another stack. If none of the external deployment configurations exist, the stack deployment fails with a config not found error.

Note: the config definition is only supported in the composition file format of version 3.3 or later. The Boolean values (true, false, yes, no, on, off) of YAML must be enclosed in quotation marks (single quotation marks or double quotation marks), otherwise it will be parsed as a string.

• LONG syntax

The LONG syntax provides more detailed information for creating service configurations

• source: the name of the configuration that exists in Docker
• target: the path or name of the file to be loaded in the task of the service. If not specified, the default is/
• UID and GID: the numeric UID or GID that holds the installed configuration file in the task container of the service. If not specified, the default is on Linux. Windows does not support.
• Mode: the permission of the file installed in the task container of the service, expressed in octal. For example, 0444 represents a file readable. The default is 0444. If the configuration files cannot be written, because they are installed in the temporary file system, if the writable bit is set, it will be ignored. The executable bit can be set. If you are not familiar with UNIX file permission mode[ Unix Permissions Calculator](http://permissions-calculator.org/)

The following example displays my in a container_ The config name is set to redis_config, set the mode to 0440 (Group readable) and set the user and group to 103. The redis service cannot access the my_other_config configuration.

version: "3.3"
services:
  redis:
    image: redis:latest
    deploy:
      replicas: 1
    configs:
      - source: my_config
        target: /redis_config
        uid: '103'
        gid: '103'
        mode: 0440
configs:
  my_config:
    file: ./my_config.txt
  my_other_config:
    external: true

You can grant corresponding access permissions to multiple configured services at the same time, or you can mix LONG and SHORT syntax. Defining a configuration does not mean granting service access.

2.42 restart_policy

Configure how to restart a container when it exits.

condition: Optional none，on-failure perhaps any(Default: any). 
delay: Set how long to restart (default: 0).
max_attempts: The number of attempts to restart the container. If the number of attempts exceeds, no more attempts will be made (default: always retry).
window: Set the container restart timeout (default: 0).

2.43 rollback_config

Configure how the service should be rolled back if the update fails.

parallelism: Number of containers rolled back at one time. If set to 0, all containers will be rolled back at the same time.
delay: Time to wait between rollback of each container group (default = 0) s). 
failure_action: What if rollback fails. One of them continue perhaps pause(default pause). 
monitor: After each container is updated, continuously observe whether it fails (ns|us|ms|s|m|h)(The default is 0 s). 
max_failure_ratio: The tolerable failure rate during rollback (0 by default).
order: The sequence of operations during rollback. One of them stop-first(Serial rollback), or start-first(Parallel rollback (default) stop-first ). 

2.44 update_config

Configuring how services should be updated is useful for configuring rolling updates.

parallelism: Number of containers updated at one time.
delay: The time to wait between updating a set of containers.
failure_action: What should I do if the update fails. One of them continue，rollback perhaps pause (Default: pause). 
monitor: After each container is updated, continuously observe whether it fails (ns|us|ms|s|m|h)(The default is 0 s). 
max_failure_ratio: The tolerable failure rate during the update process.
order: The sequence of operations during rollback. One of them stop-first(Serial rollback), or start-first(Parallel rollback (default) stop-first). 
Note: only supported V3.4 And later.