Once all settings are ready, start the node by clicking the Deploy server button at the bottom of the page.<\/li>\n<\/ol>\n\n\n\nRepeat until you have three CoreOS nodes up and running.<\/p>\n\n\n\n
Log into each node over SSH using the keys you included or with the root user and password provided by the deployment process.<\/p>\n\n\n\n
Configuring Docker Swarm on CoreOS<\/h2>\n\n\n\n The Docker CE comes with an integrated cluster management solution. It allows the creation of a swarm of docker nodes that can deploy application services. As the first-party solution, no additional software is needed to use Swarm orchestration to create and manage a cluster.<\/p>\n\n\n\n
CoreOS usually handles updates automatically, but in this case, use the command below to run the update manually.<\/p>\n\n\n\n
sudo update_engine_client -update\n...\nUpdate succeeded -- reboot needed.<\/pre>\n\n\n\nOnce the update is completed, reboot the nodes to start using the new version.<\/p>\n\n\n\n
sudo reboot\n...\nCoreOS stable (2079.3.0)<\/pre>\n\n\n\nThe Docker Swarm follows a decentralised design where nodes can handle any role in the cluster. The node specialisations for managers and workers are chosen at runtime. As the cluster must have at least one manager, the first node initializing the cluster is assigned as such. Subsequent nodes joining the cluster are usually added as workers but can be assigned as either. The flexibility means that the entire swarm can be built from a single disk image with little differentiation.<\/p>\n\n\n\n
Create a new swarm cluster with the initialization command below. Replace the manager_private_ip<\/span> with the private IP of the host you are creating the cluster on.<\/p>\n\n\n\ndocker swarm init --advertise-addr manager_private_ip<\/span><\/pre>\n\n\n\nWhen the swarm starts successfully, you can see a docker swarm join command in the output, as shown in the example below. Use the command on your other nodes to join them to the swarm.<\/p>\n\n\n\n
docker swarm join --token SWMTKN_token<\/span> manager_private_ip<\/span><\/pre>\n\n\n\nWhen all nodes are connected, use the following command on the manager to check that the nodes are ready to accept tasks.<\/p>\n\n\n\n
docker node ls\n\nID HOSTNAME STATUS AVAILABILITY MANAGER STATUS\n3h39l1ex8c1i5oo2xn4qnwkj6 * node0 Ready Active Leader\n4bdtzjfa0qw799e6npb4dxvl1 node1 Ready Active\ncu0jd5hb2l56swx9siq42f7li node2 Ready Active<\/pre>\n\n\n\nIf you run into problems joining nodes to the swarm, you can have the problematic node leave the cluster with the command below.<\/p>\n\n\n\n
docker swarm leave<\/pre>\n\n\n\nThen try to join again using the token and manager IP address as shown on your manager node. If every node of the cluster leaves, the swarm is disbanded and any node can start a new cluster with the initialization command.<\/p>\n\n\n\n
Running services on Docker Swarm<\/h2>\n\n\n\n Services are deployed on the cluster with simple requests for a number of containers of a certain application image. For example, if you deploy 5 replicas of a web host container, the manager takes the request and instructs the worker nodes to run more containers until the number of replicas is fulfilled.<\/p>\n\n\n\n
The swarm nodes enforce TLS authentication and encryption to secure communication between nodes. All of this is done by default and requires no additional attention. It is also possible to use self-signed root certificates, but for most cases, it is fine to go with the default implementation.<\/p>\n\n\n\nPrepare the cluster for containerized services by creating a network overlay for the containers to attach to.<\/p>\n\n\n\n
docker network create \n--driver overlay \n--subnet 10.0.0.0\/12 \n--opt encrypted \nservices\n<\/pre>\n\n\n\nThen start a pair of web hosts with the following command.<\/p>\n\n\n\n
docker service create \n--replicas 2 \n--name nginx \n--network services \n--publish 80:80 \nnginx<\/pre>\n\n\n\nldm0yem039fj9eeet1s26gckt\noverall progress: 2 out of 2 tasks\n1\/2: running [==================================================>]\n2\/2: running [==================================================>]\nverify: Service converged\n<\/pre>\n\n\n\nYou can see all currently deployed services with the command below.<\/p>\n\n\n\n
docker service ls<\/pre>\n\n\n\nID NAME MODE REPLICAS IMAGE PORTS\nldm0yem039fj nginx replicated 2\/2 nginx:latest *:80->80\/tcp<\/pre>\n\n\n\nIf you want to take a closer look at a specific service, use the next command.<\/p>\n\n\n\n
docker service ps nginx<\/pre>\n\n\n\nID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS\nmem2a0tbqx04 nginx.1 nginx:latest node1 Running Running 9 seconds ago\n4sbg87lfh6fo nginx.2 nginx:latest node2 Running Running 9 seconds ago<\/pre>\n\n\n\nThe output shows which nodes are running the containers.<\/p>\n\n\n\n
Networking in the Swarm cluster<\/h2>\n\n\n\n The swarm manages multi-host networking which supports overlay network services. The cluster manager automatically assigns virtual IP addresses to the containers that join the overlay. The swarm runs an embedded DNS server, which makes it possible for the swarm to also assign each container a unique DNS name that is resolvable from any container within the overlay network. This greatly simplifies service discovery and allows load balancing from the get-go.<\/p>\n\n\n\nDocker creates a number of network configurations by default. You can see the currently active networks using the ls<\/em> command in the network<\/em> scope.<\/p>\n\n\n\ndocker network ls<\/pre>\n\n\n\nNext to test the connection between containers, create a simple busybox<\/em> service with the following command. The sleep parameter ensures the container remains alive long enough for you to have time to connect to it, as without having anything to do the container would simply exit.<\/p>\n\n\n\ndocker service create \n--name busybox \n--network services \nbusybox \nsleep 3000<\/pre>\n\n\n\nWhen the service is running, check which node it is on.<\/p>\n\n\n\n
docker service ps busybox\n\nID NAME IMAGE NODE DESIRED STATE CURRENT STATE\neh2iznb6b8x8fm79eclmwbv7h busybox.1 busybox node1 Running Running 9 seconds ago\n<\/pre>\n\n\n\nThen, connect to that node through SSH and check the name of the container.<\/p>\n\n\n\n
docker ps\n\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES\ne5329caea747 busybox:latest \"sleep 3000\" 2 minutes ago Up 2 minutes busybox.1.4czfvm7771qy8lmbiz2bv4nbwdocker<\/pre>\n\n\n\nUse the full container name to open it in a new terminal. For example as below but by using the container name shown in your terminal.<\/p>\n\n\n\n
docker exec -it busybox.1.4czfvm7771qy8lmbiz2bv4nbwdocker \/bin\/sh<\/pre>\n\n\n\nThe following nslookup<\/em> commands only work within a container connected to the overlay. Try to look up the web host service.<\/p>\n\n\n\nnslookup nginx\n\nServer: 127.0.0.11\nAddress 1: 127.0.0.11\n\nName: nginx\nAddress 1: 10.10.1.2<\/pre>\n\n\n\nService Address 1<\/em> is the IP address for the load balancer. You can test the connectivity using wget within the busybox.<\/p>\n\n\n\nwget -O- 10.10.1.2<\/pre>\n\n\n\nAlternatively, you can also look up the specific container addresses.<\/p>\n\n\n\n
nslookup tasks.nginx\n\nServer: 127.0.0.11\nAddress 1: 127.0.0.11\n\nName: tasks.nginx\nAddress 1: 10.10.1.4 nginx.1.288l03z4xzjrpfy53aokk1msd.services\nAddress 2: 10.10.1.3 nginx.2.ajyko9rdg8b7oiomd400y240g.services<\/pre>\n\n\n\nSimilarly, the direct container addresses are reachable from within the busybox container.<\/p>\n\n\n\n
wget -O- 10.10.1.3<\/pre>\n\n\n\nIn both cases, you should see the default nginx welcome page in the reply.<\/p>\n\n\n\n
Service scaling and management<\/h2>\n\n\n\n Services running on the cluster are easily scalable through a single parameter. You can declare the number of replicas a service should have and the swarm manager automatically adapts by adding or removing containers to maintain the desired state.<\/p>\n\n\n\n
The swarm also provides resilience through the reconciliation of the desired states. The manager continuously monitors the state of the nodes in the cluster. If a node goes offline, the manager will reconcile the difference in the desired state and the current state by redeploying the lost services on the available nodes.<\/p>\n\n\n\n
Inspect the web host service currently running on your cluster. Using the \u2013pretty<\/em> parameter formats the output into a more human readable list.<\/p>\n\n\n\ndocker service inspect --pretty nginx<\/pre>\n\n\n\nCreate an additional container for the web host by updating the scale of the service with the following command.<\/p>\n\n\n\n
docker service scale nginx=3<\/pre>\n\n\n\nThen, check which node was assigned to run the third task. Note that a single node can host multiple containers of the same service.<\/p>\n\n\n\n
docker service ps nginx<\/pre>\n\n\n\nIf you ever have to scale down the entire cluster or even just temporarily shut down a node, you can prepare the swarm in advance by updating the node availability. Empty one of the nodes in your cluster by changing its availability to drain<\/em> with the command below.<\/p>\n\n\n\ndocker node update --availability=drain <node hostname><\/pre>\n\n\n\nThe swarm manager will then migrate any containers running on the drained node elsewhere in the cluster. Scale the service back down again.<\/p>\n\n\n\n
docker service scale nginx=2<\/pre>\n\n\n\nLastly, return the node availability back to active, therefore allowing new containers to run on it as well.<\/p>\n\n\n\n
docker node update --availability=active <node hostname><\/pre>\n\n\n\nThe cluster is then ready for anything. You may still want to remove the web host containers when you are done with them to free up the port reservations.<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n That concludes this guide to Docker Swarm for getting started. The inclusion of native Swarm orchestration is a big update, but it is very easy to learn the basics. As a result, managing your swarm is greatly simplified thanks to first-party support.<\/p>\n\n\n\n
The automatic TLS configuration enables a secure connection between nodes, along with the already secure UpCloud private network in which only cloud servers on your account are connected. The Swarm networking allows containers to communicate easily using service names through the secure overlay; however, remember to take care when publishing container ports to the public network.<\/p>\n\n\n\n
Next, you might wish to look into the load balancing provided by the swarm orchestration. You can read more about the Swarm mode routing mesh<\/a> in the docker documentation. Together with an external proxy, the swarm can manage an idea backend for distributed services.<\/p>\n","protected":false},"author":3,"featured_media":24573,"comment_status":"open","ping_status":"closed","template":"","community-category":[223],"class_list":["post-2317","tutorial","type-tutorial","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/tutorial\/2317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/tutorial"}],"about":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/types\/tutorial"}],"author":[{"embeddable":true,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/comments?post=2317"}],"version-history":[{"count":0,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/tutorial\/2317\/revisions"}],"wp:attachment":[{"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/media?parent=2317"}],"wp:term":[{"taxonomy":"community-category","embeddable":true,"href":"https:\/\/upcloud.com\/global\/wp-json\/wp\/v2\/community-category?post=2317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Swarm](\"https:\/\/upcloud.com\/media\/Swarm-automatic-TLS-1-2.png\")
<\/figure>\n\n\n\n![\"Docker](\"https:\/\/upcloud.com\/media\/Docker-Swarm-Networking-2.png\")
<\/figure>\n\n\n\n