Shulou(Shulou.com)06/03 Report--

Introduction to docker swarm

Swarm is a platform launched by Docker to manage docker clusters, which is almost entirely developed in go language. The code is open source in https://github.com/docker/swarm, which turns a group of Docker hosts into a single virtual host. Swarm uses the standard Docker API interface as its front-end access, in other words, various forms of Docker.

Client (compose,docker-py, etc.) can communicate with Swarm directly, and even Docker itself can easily integrate with Swarm, which greatly facilitates users to transplant the system based on single node to Swarm. At the same time, Swarm has built-in support for Docker network plug-ins, and users can easily deploy container cluster services across hosts.

The basic architecture of Swarm is shown in the following figure:

Advantages of Docker Swarm

High performance at any scale is key to enterprise-level Docker Engine clustering and container scheduling. Companies of any size-- whether they have five or thousands of servers-- can effectively use Swarm in their environment. After testing, the limit of Swarm scalability is to run 50000 deployment containers on 1000 nodes, each with a sub-second startup time and no performance degradation.

Flexible container scheduling

Swarm helps the IT operations team optimize performance and resource utilization under limited conditions. Swarm's built-in scheduler (scheduler) supports a variety of filters, including: node tags, affinity and a variety of container policies such as binpack, spread, random, etc.

Continuous availability of services

Docker Swarm is provided by Swarm Manager with high availability by creating multiple Swarm master nodes and developing alternative policies in the event of a primary master node downtime. If a master node goes down, a slave node is upgraded to a master node until the original master node returns to normal. In addition, if a node is unable to join the cluster, Swarm continues to try to join and provides error alerts and logs. When a node goes wrong, Swarm can now try to reschedule the container to a normal node.

Compatibility with Docker API and integration support

Swarm fully supports Docker API, which means it provides a seamless experience for users using different Docker tools such as Docker CLI,Compose,Trusted Registry,Hub and UCP.

Docker Swarm provides native support for core functions of Docker applications, such as multi-host networking and storage volume management

The developed Compose files can be easily deployed (via docker-compose up) to a test server or Swarm cluster. Docker Swarm can also pull and run images from Docker Trusted Registry or Hub.

one。 Experimental environment host IP address service docker01192.168.1.11swarm+service+webUI+registrydocker02192.168.1.13dockerdocker03192.168.1.20docker

All three hosts turn off the firewall, disable selinux, modify hostname, time synchronization, and add domain name resolution.

The docker version must be: from v1.12 (you can view the version using docker version)

1. Turn off the firewall and disable Selinux [root @ localhost ~] # systemctl stop firewalld [root@localhost ~] # hostnamectl set-hostname docker03 [root@localhost ~] # su-2. Time synchronization mv / etc/localtime / etc/localtime.bkcp / usr/share/zoneinfo/Asia/Shanghai/etc/localtime3. Modify the hostname (all three) [root@localhost ~] # hostnamectl set-hostname docker01 [root@localhost ~] # su-4. Add domain name resolution [root@docker01 ~] # echo 192.168.1.11 docker01 > > / etc/hosts [root@docker01 ~] # echo 192.168.1.13 docker02 > > / etc/hosts [root@docker01 ~] # echo 192.168.1.20 docker03 > > / etc/hosts II. Docker01 initializes the cluster [root@docker01 ~] # docker swarm init-- advertise-addr 192.168.1.11

-- advertise-addr: specifies the address to communicate with other docker.

The result returned above tells us that the initialization was successful, and if you want to add a work node, run the following command:

Note: tokens are only valid for 24 hours

If you want to add manager nodes: run the following command

Third, docker02 and docker03 join the cluster as worker [root@docker03 ~] # docker swarm join-- token SWMTKN-1-5kxn9wloh7npnytklwbfciesr9di7uvu521gwnqm9h2n0pbokj-1e60wt0yr5583e4mzwbxnn3a8 192.168.1.11:2377docker01 to view the cluster [root@docker01 ~] # docker node ls

* Note: the "* *" here represents the node to which it currently belongs.

four。 Set manager node (docker01) not to work [root@docker01 ~] # docker node update docker01-- availability drain

Setting the host docker01 will not run containers, but containers that are already running will not stop

There are three options that can be configured after the "--availability" option, as follows:

"active": work; "pause": temporarily not working; "drain": permanent non-working

[root@docker01 ~] # docker node ls

five。 Docker01 deploy a graphical webUI interface 1.docker01 import image [root@docker01~] # docker pull dockersamples/visualizer2. Launch a container [root@docker01 ~] # docker run-d-p 8080 HOST=192.168.1.100-e PORT=8080-v / var/run/docker.sock:/var/run/docker.sock-- name visualiaer dockersamples/visualizer3 based on the image. Verify http://192.168.1.11:8080/ through browser access

If you cannot access the web page, you need to enable routing and forwarding.

[root@docker01] # echo net.ipv4.ip_forward = 1 > > / etc/sysctl.conf [root@docker01] # sysctl-p6. Docker01 deployment A private warehouse Docker01 deployment 72 docker pull registry// download registry image 73 docker run-itd-- name registry-p 5000VOL5000-- restart=always registry:latest// based on registry image Start a container 78 vim / usr/lib/systemd/system/docker.service # 13 modify ExecStart=/usr/bin/dockerd-- insecure-registry 192.168.1.11 systemctl daemon-reload81 systemctl restart docker.service// 5000 80 restart docker76 docker tag busybox:latest 192.168.1.11:5000/busybox:v1 / / rename the container a label 77 docker ps

78 vim / usr/lib/systemd/system/docker.service # 13 Line modify ExecStart=/usr/bin/dockerd-- insecure-registry 192.168.1.11 insecure-registry 5000 80 systemctl daemon-reload81 systemctl restart docker.service// restart docker100 docker push 192.168.1.11:5000/busybox:v1// upload containers to private warehouse Docker02 and docker03 add private warehouse 78 vim / usr/lib/systemd/system/docker.service # 13 line modify ExecStart=/usr/bin/dockerd-insecure- Registry 192.168.1.11 registry 5000 80 systemctl daemon-reload81 systemctl restart docker.service// restart docker99 docker pull 192.168.1.11/busybox:v1// test download 7. Custom image requirements: change the content of the access interface based on httpd image. The tag version of the image is v1Magne v2jie v3, and the corresponding host content is v1Magne xgp666, v2Magne xgp666, v2Magne xgp666 [root@docker01 ~] # docker pull httpd// download httpd image.

Create three test directories

[root@docker01 ~] # mkdir {v1jue v2recoverv3} / / create a test directory

Docker01,v1 directory operation

[root@docker01 ~] # cd v1 [root@docker01 v1] # echo v1 Xgp666 > index.html// create test web page [root@docker01 v1] # vim Dockerfile// write DockerfileFROM httpdADD index.html/ usr/local/apache2/htdocs/index.html [root@docker01 v1] # docker build-t 192.168.1.11:5000/httpd:v1. / / create image based on dockerfile [root@docker01 v1] # docker push 192.168.1.11:5000/httpd:v1// upload just created image to private repository

Docker01,v2 directory operation

[root@docker01 v1] # cd.. / v2 [root@docker01 v2] # echo v2 Magazine xgp666 > index.html [root@docker01 v2] # vim Dockerfile / / write DockerfileFROM httpdADD index.html / usr/local/apache2/htdocs/index.html [root@docker01 v2] # docker build-t 192.168.1.11:5000/httpd:v2. / / create an image based on dockerfile [root@docker01 v2] # docker push 192.168.1.11:5000/httpd:v2// upload the image you just created to the private repository

Docker01,v3 directory operation

[root@docker01 v1] # cd.. / v3 [root@docker01 v2] # echo v3 Magazine xgp666 > index.html [root@docker01 v2] # vim Dockerfile / / write DockerfileFROM httpdADD index.html / usr/local/apache2/htdocs/index.html [root@docker01 v2] # docker build-t 192.168.1.11:5000/httpd:v3. / / create an image based on dockerfile [root@docker01 v2] # docker push 192.168.1.11:5000/httpd:v3// upload just created image to private repository 8. Publish a service based on the above mirror requirements: the number of copies is 3. The name of the service is bdqn [root@docker01 v3] # docker service create-- replicas 3-- name bdqn-p 80:80 192.168.1.11:5000/httpd:v1

Check the network.

[root@docker03 ~] # docker network ls

The default Ingress network, including the custom overlay network created, provides a unified entrance to the container that the back end really provides services to users.

Service publishes services through ingress load balancing, and all node in the swarm cluster participate in the ingress routing grid (ingress routing mesh). Access to any node+PublishedPort can access the service.

When accessing port 80 on any node, Docker routes your request to the active container. In the cluster node itself, port 80 may not be actually bound, but the routing grid knows how to route traffic and prevent any port conflicts.

The routing grid listens on the published port for any IP address assigned to the node. For externally routable IP addresses, the port is available from outside the host. For all other IP addresses, it can only be accessed from within the host.

Check out the created copy [root@docker01 v3] # docker service ps bdqn

Browser test access to http://192.168.1.11:80,http://192.168.1.13:80,http://192.168.1.20:80

Modify the content of docker02 and docker03 test web pages docker02 [root@docker02 ~] # docker exec-it 388f3bd9dd33 / bin/bashroot@388f3bd9dd33:/usr/local/apache2# cd htdocs/root@388f3bd9dd33:/usr/local/apache2/htdocs# echo 123 > index.html docker03 [root@docker03 ~] # docker exec-it 281454867fac / bin/bashroot@281454867fac:/usr/local/apache2# echo 321 > htdocs/index.html test access (each one will be displayed and load balancing will be performed)

Requirement: the number of copies is 3. The name of the service is: test [root@docker01 v3] # docker service create-- replicas 3-- name test-p 80 192.168.1.11:5000/httpd:v1 View the created service mapping port [root@docker01 v3] # docker service ls

Default mapping port 30000-32767

nine。 Capacity expansion and reduction of service [root@docker01 v3] # docker service scale bdqn=6 capacity reduction [root@docker01 v3] # docker service scale bdqn=4

The number of replicas can be set directly through scale.

ten。 Service upgrade and rollback (1) upgrade

Detailed explanation of docker service upadte command parameters

-- force forces the service to be updated and restarted, regardless of configuration or image changes

-- image formulates updated images

-- with-registry-auth sends Registry authentication details to the Swarm agent. Private warehouse needs to carry this parameter.

[root@docker01 ~] # docker service update-- visit the version test that image 192.168.1.11:5000/httpd:v2 bdqn// upgrades the bdqn service to v2

(2) smooth update [root@docker01 ~] # docker service update--image 192.168.1.11:5000/httpd:v3-- update-parallelism 2-- update-delay 1m bdqn / / both services update together, and then continue to update every other minute

By default, swarm- updates only one copy at a time, and there is no waiting time between the two copies, so we can use the

-- update-parallelism; sets the number of copies to update in parallel.

-- update-delay: specifies the interval between rolling updates.

Test and visit.

(3) rollback operation [root@docker01 ~] # docker service rollback bdqn

Note that by default, the rollback operation of docker swarm can only be rolled back to the state of the previous operation, not continuously to the specified operation.

Test and visit.

National Day holiday, attention:

If multiple services are enabled on a machine, allocate cpu and memory resources reasonably, because tomcat will eat memory when starting compilation, and docker is started by multiple threads, so it is best to limit (set resources.limits) otherwise it will cause memory to run out at the same time. Failure to start some services can also result in setting error restart (restart_policy.condition:on-failure). In addition, you should pay attention to setting resources.reservations Do not exceed the percentage of total memory or cpu, otherwise it will cause later services to fail to obtain cpu or memory resources with a "no suitable node (insufficien" error) (this error is strange. A service does not start and does not output a log. Using "docker stack ps [xxxx]" to check the status will show this error).

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.