{"id":7353,"date":"2018-04-13T09:59:04","date_gmt":"2018-04-13T01:59:04","guid":{"rendered":"http:\/\/rmohan.com\/?p=7353"},"modified":"2018-04-13T09:59:04","modified_gmt":"2018-04-13T01:59:04","slug":"docker-swarm","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=7353","title":{"rendered":"docker swarm"},"content":{"rendered":"

Docker Engine Starting from version 1.12.0, Docker Swarm is integrated natively. The operation of the cluster can be directly controlled by the docker service command, which is very convenient and the operation process is greatly simplified.\u00a0Docker Swarm For the average developer, the biggest advantage lies in the native support of the load balancing mechanism, which can effectively scale the service up. With the help of the Raft Consensus algorithm, the robustness of the system is very good and can be tolerated as much as possible (n -1)\/2 fault nodes.
\nBuild Swarm Cluster<\/p>\n

Install the latest docker<\/p>\n

curl -sSL https:<\/span>\/\/get.docker.com\/ | sh<\/span><\/span><\/code><\/pre>\n
CentOS<\/a><\/span> 7<\/span>?????<\/span><\/code><\/pre>\n
firewall-cmd --permanent --zone=trusted --add-port=2377\/tcp && \\<\/span><\/span>\r\nfirewall-cmd --permanent --zone=trusted --add-port=7946\/tcp && \\<\/span><\/span>\r\nfirewall-cmd --permanent --zone=trusted --add-port=7946\/udp && \\<\/span><\/span>\r\nfirewall-cmd --permanent --zone=trusted --add-port=4789\/udp && \\<\/span><\/span>\r\nfirewall-cmd --reload <\/span><\/span><\/code><\/pre>\n
Create a management node<\/p>\n
$ docker swarm init --advertise-addr 192.168<\/span>.99<\/span>.100<\/span><\/span>\r\nSwarm initialized: current node (dxn1zf6l61qsb1josjja83ngz) is<\/span> now a manager.<\/span>\r\n\r\nTo<\/span> add a worker to<\/span> this swarm, run the following command:<\/span>\r\n    docker swarm join<\/span> \\<\/span>\r\n    --token SWMTKN-1<\/span>-49<\/span>nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8<\/span>vxv8rssmk743ojnwacrr2e7c \\<\/span>\r\n    192.168<\/span>.99<\/span>.100<\/span>:2377<\/span><\/span>\r\n\r\nTo<\/span> add a manager to<\/span> this swarm, run the following command:<\/span>\r\n    docker swarm join<\/span> \\<\/span>\r\n    --token SWMTKN-1<\/span>-61<\/span>ztec5kyafptydic6jfc1i33t37flcl4nuipzcusor96k7kby-5<\/span>vy9t8u35tuqm7vh67lrz9xp6 \\<\/span>\r\n    192.168<\/span>.99<\/span>.100<\/span>:2377<\/span><\/span><\/code><\/pre>\n
When the management node is created, we can view the node creation status through the docker info and docker node ls commands.<\/p>\n
$ docker info<\/span>\r\n\r\nContainers:<\/span> 2<\/span><\/span>\r\nRunning:<\/span> 0<\/span><\/span>\r\nPaused:<\/span> 0<\/span><\/span>\r\nStopped:<\/span> 2<\/span><\/span>\r\n  ...snip...<\/span>\r\nSwarm:<\/span> active<\/span>\r\n  NodeID:<\/span> dxn1zf6l61qsb1josjja83ngz<\/span>\r\n  Is Manager: true<\/span><\/span>\r\n  Managers:<\/span> 1<\/span><\/span>\r\n  Nodes:<\/span> 1<\/span><\/span>\r\n  ...snip...<\/span><\/code><\/pre>\n
$ docker node ls<\/span>\r\n\r\nID                           HOSTNAME  STATUS<\/span>  AVAILABILITY  MANAGER STATUS<\/span><\/span>\r\ndxn1zf6l61qsb1josjja83ngz *  manager1  Ready   Active        Leader<\/span>\r\n??worker??<\/span><\/code><\/pre>\n
According to the previous command line output result prompt, two workers are now added to the cluster.\u00a0Remember to replace the corresponding token and IP address with the actual value during execution.<\/p>\n
$ docker swarm join<\/span> \\<\/span>\r\n  --token  SWMTKN<\/span>-1<\/span>-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \\<\/span>\r\n  192.168<\/span>.99.100<\/span>:2377<\/span><\/span>\r\n\r\nThis<\/span> node joined a swarm as<\/span> a worker.<\/span>\r\n$ docker swarm join<\/span> \\<\/span>\r\n  --token SWMTKN<\/span>-1<\/span>-49nj1cmql0jkz5s954yi3oex3nedyz0fb0xx14ie39trti4wxv-8vxv8rssmk743ojnwacrr2e7c \\<\/span>\r\n  192.168<\/span>.99.100<\/span>:2377<\/span><\/span>\r\n\r\nThis<\/span> node joined a swarm as<\/span> a worker.<\/span>\r\n#????????hostname `hoshnamectl set<\/span>-hostname worker2`<\/span><\/code><\/pre>\n
Now we can see all the nodes in the cluster on the manager1 node<\/p>\n
$ docker node ls<\/span>\r\n\r\nID                           HOSTNAME  STATUS<\/span>  AVAILABILITY  MANAGER STATUS<\/span><\/span>\r\n3g1y59jwfg7cf99w4lt0f662    worker2   Ready   Active<\/span>\r\nj68exjopxe7wfl6yuxml7a7j    worker1   Ready   Active<\/span>\r\ndxn1zf6l61qsb1josjja83ngz *  manager1  Ready   Active        Leader<\/span><\/code><\/pre>\n
So far, the cluster environment has been set up.<\/p>\n
Deployment Test Service<\/p>\n
We deployed nginx as an example to test the Swarm cluster we built.<\/p>\n
$ docker service create<\/span> --replicas 3 --publish 8080:80 --name helloworld nginx<\/span><\/span><\/code><\/pre>\n
The –replicas parameter here is used to indicate how many instances nginx needs to deploy because there are three physical machines. If replicas is set to 3, swarm will deploy one instance on each of the three machines.\u00a0If you want to rescale the number of instances, you can use the following command.<\/p>\n
docker service scale<\/span> helloworld=5<\/span><\/span><\/code><\/pre>\n
We can check the deployment of nginx through a series of commands, such as<\/p>\n
$ docker service inspect --pretty helloworld<\/span><\/span>\r\n$ docker service ps helloworld<\/span><\/code><\/pre>\n
Deleting a service is also very simple and you can simply execute rm.<\/p>\n
$ <\/span>docker service rm helloworld<\/span><\/code><\/pre>\n
Let’s look at a docker-compose.yml file first. It doesn’t matter what this is doing. It’s just a format that is easy to explain:<\/p>\n
version:<\/span> '2'<\/span><\/span>\r\nservices:<\/span><\/span>\r\n  web:<\/span><\/span>\r\n    image:<\/span> dockercloud\/hello-world<\/span>\r\n    ports:<\/span><\/span>\r\n      - 8080<\/span><\/span>\r\n    networks:<\/span><\/span>\r\n      - front-tier<\/span>\r\n      - back-tier<\/span>\r\n\r\n  redis:<\/span><\/span>\r\n    image:<\/span> redis<\/span>\r\n    links:<\/span><\/span>\r\n      - web<\/span>\r\n    networks:<\/span><\/span>\r\n      - back-tier<\/span>\r\n\r\n  lb:<\/span><\/span>\r\n    image:<\/span> dockercloud\/haproxy<\/span>\r\n    ports:<\/span><\/span>\r\n      - 80<\/span>:80<\/span><\/span>\r\n    links:<\/span><\/span>\r\n      - web<\/span>\r\n    networks:<\/span><\/span>\r\n      - front-tier<\/span>\r\n      - back-tier<\/span>\r\n    volumes:<\/span><\/span>\r\n      - \/var\/<\/span>run\/docker.sock:\/var\/<\/span>run\/docker.sock <\/span>\r\n\r\nnetworks:<\/span><\/span>\r\n  front-tier:<\/span>\r\n    driver:<\/span> bridge<\/span>\r\n  back-tier:<\/span>\r\ndriver:<\/span> bridge<\/span><\/code><\/pre>\n
It can be seen that a standard configuration file should contain three major parts: version, services, and networks. The most critical part is services and networks. Let’s first look at the rules for writing services.<\/p>\n
    \n
  1. Image\n
    services:<\/span><\/span>\r\n  web:<\/span><\/span>\r\nimage:<\/span> hello-world<\/span><\/code><\/pre>\n
    The second-level tag under the services tab is web. The name is customized by the user. It is the service name.
    \nImage is the image name or image ID of the specified service.\u00a0If the image does not exist locally, Compose will try to pull the image.
    \nFor example, the following formats are all possible:<\/p>\n
    image:<\/span> redis<\/span>\r\nimage:<\/span> <\/span>Ubuntu<\/a>:<\/span><\/span>14.04<\/span><\/span>\r\nimage:<\/span> tutum\/influxdb<\/span>\r\nimage:<\/span> example-registry.com:<\/span>4000<\/span>\/postgresql<\/span>\r\nimage:<\/span> a4bc65fd<\/span><\/code><\/pre>\n<\/li>\n
  2. Build<\/li>\n<\/ol>\n
    The service can be based on a specified image, or it can be based on a Dockerfile. When you use up to start a build task, this build tag is the build, which specifies the path to the Dockerfile folder.\u00a0Compose will use it to automatically build this image and then use this image to start the service container.<\/p>\n
    build:<\/span> \/path\/<\/span>to\/build\/<\/span>dir<\/span><\/code><\/pre>\n
    It can also be a relative path, and the Dockerfile can be read as long as the context is determined.<\/p>\n
    build:<\/span> .\/dir<\/span><\/code><\/pre>\n
    Set the context root and specify the Dockerfile as the target.<\/p>\n
    build:<\/span><\/span>\r\n  context:<\/span> ..\/<\/span>\r\n  dockerfile:<\/span> path\/of\/<\/span>Dockerfile<\/span><\/code><\/pre>\n
    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 above example.
    \nIf you specify both the image and build tags, Compose will build the image and name the image after the image.<\/p>\n
    build:<\/span> .\/dir<\/span>\r\nimage:<\/span> webapp:<\/span>tag<\/span><\/code><\/pre>\n
    Since you can define the build task in docker-compose.yml, you must have the arg tag. Just like the ARG directive in the Dockerfile, it can specify the environment variables during the build process, but cancel after the build succeeds, at docker-compose. The yml file also supports this notation:<\/p>\n
    build:<\/span><\/span>\r\n  context:<\/span> .<\/span>\r\n  args:<\/span><\/span>\r\n    buildno:<\/span> 1<\/span><\/span>\r\n    password:<\/span> secret<\/span><\/code><\/pre>\n
    The following writing is also supported. In general, the following wording is more suitable for reading.<\/p>\n
    build:<\/span><\/span>\r\n  context:<\/span> .<\/span>\r\n  args:<\/span><\/span>\r\n    -<\/span> buildno=1<\/span><\/span>\r\n    -<\/span> password=secret<\/span><\/code><\/pre>\n
    Unlike ENV, ARG allows null values.\u00a0E.g:<\/p>\n
    args:<\/span><\/span>\r\n  - buildno<\/span>\r\n  - password<\/span><\/code><\/pre>\n
    This way the build process can assign values ??to them.<\/p>\n
    Note: YAML Boolean values ??(true, false, yes, no, on, off) must be quoted (either single or double quotes), otherwise they will be parsed as strings.<\/p>\n
      \n
    1. Command<\/li>\n<\/ol>\n
      Use command to override the default command executed after the container starts.<\/p>\n
      command<\/span>: bundle exec<\/span> thin -p 3000<\/span><\/code><\/pre>\n
      It can also be written in a format similar to Dockerfile:<\/p>\n
      command<\/span>: [bundle, exec<\/span>, thin, -p, 3000]<\/span><\/code><\/pre>\n
      4.container_name<\/p>\n
      As mentioned earlier, Compose’s container name format is: <project name> <service name> <serial number>
      \nAlthough you can customize the project name, service name, but if you want to fully control the container’s name, you can use this tag to specify:<\/p>\n
      container_name:<\/span> app<\/span><\/code><\/pre>\n
      The name of this container is specified as app.<\/p>\n
      5.depends_on<\/p>\n
      In the use of Compose, the biggest advantage is to use less to start the command, but the order of the general project container startup is required, if you start the container directly from top to bottom, it will inevitably fail because of container dependency problems.
      \nFor example, if the application container is started when the database container is not started, the application container will exit because it cannot find the database. In order to avoid this situation, we need to add a label, namely depends_on, which resolves the container’s dependency and startup sequence. The problem.
      \nFor example, the following container will start two services redis and db, and finally start the web service:<\/p>\n
      version:<\/span> '2'<\/span><\/span>\r\nservices:<\/span><\/span>\r\n  web:<\/span><\/span>\r\n    build:<\/span> .<\/span>\r\n    depends_on:<\/span><\/span>\r\n      - db<\/span>\r\n      - redis<\/span>\r\n  redis:<\/span><\/span>\r\n    image:<\/span> redis<\/span>\r\n  db:<\/span><\/span>\r\n    image:<\/span> postgres<\/span><\/code><\/pre>\n
      Note that when launching a web service using the docker-compose up web method by default, both the redis and db services are started because the dependencies are defined in the configuration file.<\/p>\n
      6.dns<\/p>\n
      The same as the –dns parameter, the format is as follows:<\/p>\n
      Dns: 8.8.8.8
      \ncan also be a list:<\/p>\n
      dns<\/span>:<\/span>\r\n  -<\/span> 8.8<\/span>.8<\/span>.8<\/span><\/span>\r\n  -<\/span> 9.9<\/span>.9<\/span>.9<\/span><\/span><\/code><\/pre>\n
      In addition, the configuration of dns_search is similar:<\/p>\n
      dns_search<\/span>: example<\/span>.com<\/span><\/span>\r\ndns_search<\/span>:<\/span>\r\n  -<\/span> dc1<\/span>.example<\/span>.com<\/span><\/span>\r\n  -<\/span> dc2<\/span>.example<\/span>.com<\/span><\/span><\/code><\/pre>\n
        \n
      1. Tmpfs<\/li>\n<\/ol>\n
        Mounting a temporary directory inside the container has the same effect as the run parameter:<\/p>\n
        tmpfs:<\/span> \/run<\/span>\r\ntmpfs:<\/span><\/span>\r\n  -<\/span> \/run<\/span>\r\n  -<\/span> \/tmp<\/span><\/code><\/pre>\n
          \n
        1. Entrypoint<\/li>\n<\/ol>\n
          In the Dockerfile there is an instruction called the ENTRYPOINT directive that specifies the access point, and Chapter 4 has the difference compared to the CMD.
          \nThe access point can be defined in docker-compose.yml, overriding the definition in the Dockerfile:<\/p>\n
          Entrypoint: The \/code\/entrypoint.sh
          \nformat is similar to Docker, but can also be written like this:<\/p>\n
          entrypoint:<\/span><\/span>\r\n    - php<\/span>\r\n    - -d<\/span>\r\n    - zend_extension=\/usr\/<\/span>local\/lib\/<\/span>php\/extensions\/<\/span>no-debug-non-zts-20100525<\/span>\/xdebug.so<\/span>\r\n    - -d<\/span>\r\n    - memory_limit=-1<\/span><\/span>\r\n    - vendor\/bin\/<\/span>phpunit<\/span><\/code><\/pre>\n
          9.env_file<\/p>\n
          Remember the .env file mentioned earlier. This file can set Compose variables.\u00a0In docker-compose.yml, you can define a file that stores variables.
          \nIf the configuration file is specified with docker-compose -f FILE, the path to the env_file uses the configuration file path.<\/p>\n
          If there is a conflict between the variable name and the environment instruction, the latter will prevail.\u00a0The format is as follows:<\/p>\n
          Env_file: .env
          \nor set multiple according to docker-compose.yml:<\/p>\n
          env_file:<\/span><\/span>\r\n  - .\/common.env<\/span>\r\n  - .\/apps\/<\/span>web.env<\/span>\r\n  - \/opt\/<\/span>secrets.env<\/span><\/code><\/pre>\n
          Note that the environment variable mentioned here is for the host’s Compose. 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 your build, it is still preferred. The arg tag.<\/p>\n
            \n
          1. Environment<\/li>\n<\/ol>\n
            Unlike the above env_file tag, which is somewhat similar to arg, the effect of this tag is to set the mirror variable, which can save the variable to the image, which means that the starting container will also contain these variable settings. This is the same as arg. The biggest difference.
            \nGeneral arg tag variables are used only during the build process.\u00a0The ENV instruction in environment and Dockerfile will keep the variables in the image and container, similar to the effect of docker run -e.<\/p>\n
            environment:<\/span><\/span>\r\n  RACK_ENV:<\/span> development<\/span>\r\n  SHOW:<\/span> 'true'<\/span><\/span>\r\n  SESSION_SECRET:<\/span><\/span>\r\n\r\nenvironment:<\/span><\/span>\r\n  -<\/span> RACK_ENV=development<\/span>\r\n  -<\/span> SHOW=true<\/span><\/span>\r\n  -<\/span> SESSION_SECRET<\/span><\/code><\/pre>\n
              \n
            1. The expose<\/li>\n<\/ol>\n
              This tag is the same as the EXPOSE directive in the Dockerfile. It is used to specify the exposed port, but only as a reference. In fact, the port mapping of docker-compose.yml still has a tag like ports.<\/p>\n
              expose:<\/span><\/span>\r\n - \"3000\"<\/span><\/span>\r\n - \"8000\"<\/span><\/span><\/code><\/pre>\n
                \n
              1. External_links<\/li>\n<\/ol>\n
                In the Docker process, we have a lot of containers that are started using docker run alone. To make Compose connect to containers that are not defined in docker-compose.yml, we need a special label, external_links, which allows the Compose project to work. The containers inside are connected to containers outside of the project configuration (provided that at least one container in the external container is connected to the same network as the service in the project).
                \nThe format is as follows:<\/p>\n
                external_links:<\/span><\/span>\r\n -<\/span> redis_1<\/span>\r\n - project_db_1:<\/span>mysql<\/span>\r\n - project_db_1:<\/span>postgresql<\/span><\/code><\/pre>\n
                  \n
                1. Extra_hosts<\/li>\n<\/ol>\n
                  Add the host name tag, which is to add some records to the \/etc\/hosts file, similar to the –add-host of the Docker client:<\/p>\n
                  extra_hosts:<\/span><\/span>\r\n - \"somehost:162.242.195.82\"<\/span><\/span>\r\n - \"otherhost:50.31.209.229\"<\/span><\/span><\/code><\/pre>\n
                  View the internal hosts of the container after startup:<\/p>\n
                  162.242<\/span>.195<\/span>.82<\/span>  somehost<\/span><\/span>\r\n50.31<\/span>.209<\/span>.229<\/span>   otherhost<\/span><\/span><\/code><\/pre>\n
                    \n
                  1. Labels<\/li>\n<\/ol>\n
                    Add metadata to the container, and the meaning of the Dockerfile’s LABEL directive is as follows:<\/p>\n
                    labels:<\/span><\/span>\r\n  com.example.description:<\/span> \"Accounting webapp\"<\/span><\/span>\r\n  com.example.department:<\/span> \"Finance\"<\/span><\/span>\r\n  com.example.label-with-empty-value:<\/span> \"\"<\/span><\/span>\r\nlabels:<\/span><\/span>\r\n  - \"com.example.description=Accounting webapp\"<\/span><\/span>\r\n  - \"com.example.department=Finance\"<\/span><\/span>\r\n  - \"com.example.label-with-empty-value\"<\/span><\/span><\/code><\/pre>\n
                      \n
                    1. Links<\/li>\n<\/ol>\n
                      Remember the above depends_on, that the tag solves the startup sequence problem, this tag resolves the container connection problem, and is the same as the docker client’s –link, which connects to containers in other services.
                      \nThe format is as follows:<\/p>\n
                      links:<\/span><\/span>\r\n -<\/span> db<\/span>\r\n - db:<\/span>database<\/span>\r\n -<\/span> redis<\/span><\/code><\/pre>\n
                      The alias used will be automatically created in \/etc\/hosts in the service container.\u00a0E.g:<\/p>\n
                      172.12<\/span>.2<\/span>.186<\/span>  db<\/span><\/span>\r\n172.12<\/span>.2<\/span>.186<\/span>  database<\/span><\/span>\r\n172.12<\/span>.2<\/span>.187<\/span>  redis<\/span><\/span><\/code><\/pre>\n
                      The corresponding environment variable will also be created.<\/p>\n
                        \n
                      1. Logging<\/li>\n<\/ol>\n
                        This tag is used to configure the log service.\u00a0The format is as follows:<\/p>\n
                        logging:<\/span><\/span>\r\n  driver:<\/span> syslog<\/span>\r\n  options:<\/span><\/span>\r\n    syslog-address:<\/span> \"tcp:\/\/192.168.0.42:123\"<\/span><\/span><\/code><\/pre>\n
                        The default driver is json-file.\u00a0Only json-file and journald can display logs through docker-compose logs. There are other ways to view logs, but Compose does not support them.\u00a0For optional values, use options.
                        \nFor more information on this you can read the official documentation:
                        \nhttps:\/\/docs.docker.com\/engine\/admin\/logging\/overview\/<\/a><\/p>\n
                          \n
                        1. Pid<\/li>\n<\/ol>\n
                          Pid: “host”
                          \nsets the PID mode to host PID mode, sharing the process namespace with the host system.\u00a0Containers using this tag will be able to access and manipulate the namespaces of other containers and hosts.<\/p>\n
                            \n
                          1. Ports<\/li>\n<\/ol>\n
                            Map the port’s tag.
                            \nUsing the HOST:CONTAINER format or just specifying the port of the container, the host randomly maps ports.<\/p>\n
                            ports<\/span>:<\/span>\r\n -<\/span> \"3000\"<\/span>\r\n -<\/span> \"8000:8000\"<\/span><\/span>\r\n -<\/span> \"49100:22\"<\/span><\/span>\r\n -<\/span> \"127.0<\/span>.0<\/span>.1<\/span>:8001<\/span>:8001\"<\/span><\/span><\/code><\/pre>\n
                            Note: When using HOST:CONTAINER format to map ports, if you use a container port less than 60 you may get a wrong result, because YAML will parse xx:yy this number format is hexadecimal.\u00a0Therefore, it is recommended to use a string format.<\/p>\n
                              \n
                            1. Security_opt<\/li>\n<\/ol>\n
                              Override the default label for each container.\u00a0Simply put, it is the label for managing all services.\u00a0For example, set the user tag for all services to USER.<\/p>\n
                              security_opt:<\/span><\/span>\r\n  - label:<\/span>user:<\/span>USER<\/span>\r\n  - label:<\/span>role:<\/span>ROLE<\/span><\/code><\/pre>\n
                                \n
                              1. Stop_signal<\/li>\n<\/ol>\n
                                Set another signal to stop the container.\u00a0The SIGTERM stop container is used by default.\u00a0Set another signal to use the stop_signal tag.<\/p>\n
                                Stop_signal: SIGUSR1<\/p>\n
                                  \n
                                1. Volumes<\/li>\n<\/ol>\n
                                  Mount a directory or an existing data volume container, either directly using the format [HOST:CONTAINER], or using the format [HOST:CONTAINER:ro], which is read-only for containers This can effectively protect the host’s file system.
                                  \nThe Compose data volume designation path can be a relative path, using . or .. to specify the relative directory.
                                  \nThe format of the data volume can be in the following forms:<\/p>\n
                                  Volumes:
                                  \n\/\/ Just specify a path, Docker will automatically create a data volume (this path is inside the container).<\/p>\n
                                  - \/var<\/span>\/lib\/mysql<\/span><\/code><\/pre>\n
                                  \/\/ Mount data volume using absolute path<\/p>\n
                                    - \/opt\/data<\/span>:\/var\/lib\/mysql<\/span><\/span><\/code><\/pre>\n
                                  \/\/ The relative path centered on the Compose configuration file is mounted as a data volume to the container.<\/p>\n
                                  - .\/cache<\/span>:\/tmp\/cache<\/span><\/span><\/code><\/pre>\n
                                  \/\/ Use the relative path of the user (the directory represented by ~\/ is \/home\/<user directory>\/ or \/root\/).<\/p>\n
                                   - ~\/configs:\/etc<\/span>\/configs\/<\/span>:ro<\/span><\/span><\/code><\/pre>\n
                                  \/\/ An existing named data volume.<\/p>\n
                                  - datavolume:<\/span>\/var\/<\/span>lib\/mysql<\/span><\/code><\/pre>\n
                                  If you do not use the host’s path, you can specify a volume_driver.<\/p>\n
                                  volume_driver:<\/span> mydriver<\/span><\/code><\/pre>\n
                                    \n
                                  1. Volumes_from<\/li>\n<\/ol>\n
                                    Mount data volumes from other containers or services. 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 writeable to the data volume.\u00a0It is readable and writable by default.<\/p>\n
                                    volumes_from:<\/span><\/span>\r\n  - service_name<\/span>\r\n  - service_name:<\/span>ro<\/span>\r\n  - container:<\/span>container_name<\/span>\r\n  - container:<\/span>container_name:<\/span>rw<\/span><\/code><\/pre>\n
                                      \n
                                    1. Cap_add, cap_drop<\/li>\n<\/ol>\n
                                      Add or remove the container’s kernel features.\u00a0Detailed information is explained in the previous section of the container and will not be repeated here.<\/p>\n
                                      cap_add:<\/span><\/span>\r\n  - ALL<\/span>\r\n\r\ncap_drop:<\/span><\/span>\r\n  - NET_ADMIN<\/span>\r\n  - SYS_ADMIN<\/span><\/code><\/pre>\n
                                        \n
                                      1. Cgroup_parent<\/li>\n<\/ol>\n
                                        Specifies the parent cgroup of a container.<\/p>\n
                                        Cgroup_parent: m-executor-abcd<\/p>\n
                                          \n
                                        1. Devices<\/li>\n<\/ol>\n
                                          List of device mappings.\u00a0Similar to the –device parameter of the Docker client.<\/p>\n
                                          devices:<\/span><\/span>\r\n  - \"\/dev\/ttyUSB0:\/dev\/ttyUSB0\"<\/span><\/span><\/code><\/pre>\n
                                            \n
                                          1. Extends<\/li>\n<\/ol>\n
                                            This tag can be used to extend another service. Extended content can be from the current file, or from other files, and the same service. Latecomers can choose to overwrite the original configuration.<\/p>\n
                                            Extends\u00a0:\u00a0file: common.yml
                                            \nservice: webapp
                                            \nusers can use this tag anywhere, as long as the tag content contains both file and service values.\u00a0The value of file can be a relative or absolute path. If you do not specify the value of file, Compose will read the current YML file information.
                                            \nMore details of the operation are described later in subsection 12.3.4.<\/p>\n
                                              \n
                                            1. Network_mode<\/li>\n<\/ol>\n
                                              The network mode is similar to the –net parameter of the Docker client, except that there is a relatively more service:[service name] format.
                                              \nE.g:<\/p>\n
                                              network_mode:<\/span> \"bridge\"<\/span><\/span>\r\nnetwork_mode:<\/span> \"host\"<\/span><\/span>\r\nnetwork_mode:<\/span> \"none\"<\/span><\/span>\r\nnetwork_mode:<\/span> \"service:[service name]\"<\/span><\/span>\r\nnetwork_mode:<\/span> \"container:[container name\/id]\"<\/span><\/span><\/code><\/pre>\n
                                              You can specify the network that uses the service or container.<\/p>\n
                                                \n
                                              1. Networks<\/li>\n<\/ol>\n
                                                Join the specified network in the following format:<\/p>\n
                                                services:<\/span><\/span>\r\n  some-service:<\/span><\/span>\r\n    networks:<\/span><\/span>\r\n     -<\/span> some-network<\/span>\r\n     -<\/span> other-network<\/span><\/code><\/pre>\n
                                                There is also a special child tag aliases for this tag. This is a tag to set the service alias, for example:<\/p>\n
                                                services:<\/span><\/span>\r\n  some-service:<\/span><\/span>\r\n    networks:<\/span><\/span>\r\n      some-network:<\/span><\/span>\r\n        aliases:<\/span><\/span>\r\n         -<\/span> alias1<\/span>\r\n         -<\/span> alias3<\/span>\r\n      other-network:<\/span><\/span>\r\n        aliases:<\/span><\/span>\r\n         -<\/span> alias2<\/span><\/code><\/pre>\n
                                                The same service can have different aliases on different networks.<\/p>\n
                                                  \n
                                                1. other<\/li>\n<\/ol>\n
                                                  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
                                                  \nThese are all single-valued tags, similar to Use docker run effect.<\/p>\n
                                                  cpu_shares<\/span>: 73<\/span>\r\ncpu_quota<\/span>: 50000<\/span>\r\ncpuset<\/span>: 0,1<\/span>\r\n\r\nuser<\/span>: postgresql<\/span>\r\nworking_dir<\/span>: \/code<\/span>\r\n\r\ndomainname<\/span>: foo.com<\/span>\r\nhostname<\/span>: foo<\/span>\r\nipc<\/span>: host<\/span>\r\nmac_address<\/span>: 02:42:ac:11:65:43<\/span>\r\n\r\nmem_limit<\/span>: 1000000000<\/span>\r\nmemswap_limit<\/span>: 2000000000<\/span>\r\nprivileged<\/span>: true<\/span>\r\n\r\nrestart<\/span>: always<\/span>\r\n\r\nread_only:<\/span> true<\/span><\/span>\r\nshm_size:<\/span> 64<\/span>M<\/span>\r\nstdin_open:<\/span> true<\/span><\/span>\r\ntty:<\/span> true<\/span><\/span><\/span><\/span><\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"
                                                  Docker Engine Starting from version 1.12.0, Docker Swarm is integrated natively. The operation of the cluster can be directly controlled by the docker service command, which is very convenient and the operation process is greatly simplified. Docker Swarm For the average developer, the biggest advantage lies in the native support of the load balancing mechanism, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[82],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/7353"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7353"}],"version-history":[{"count":1,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/7353\/revisions"}],"predecessor-version":[{"id":7354,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/7353\/revisions\/7354"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7353"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7353"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7353"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}