Docker1.12 + Swarm Building dynamic microservices applications

Guide

We mentioned earlier an example of a microservices application consisting of a front-end and multiple backend services. The front end is the Traefik HTTP proxy, which is responsible for routing requests to backend services. The latter is very simple, a set of Go-based HTTP Web servers that are responsible for returning the container ID where they run.

The new Docker swarm no longer needs to set up a standalone HTTP proxy for the app container. As shown in the original schema is now reduced to the form shown:

Fewer moving parts-praise!

In addition, we built a load balancing mechanism for back-end services. We can even access these services based on any node within the cluster. The Docker Swarm also integrates a built-in mesh routing mechanism for routing requests to the appropriate back-end container.

In the face of these new features, some friends may think that the setup process of the Docker swarm cluster is more complex than it was originally. In fact, the whole process is simpler.

Still doubtful? Let's see it together.

Yes, this time we still use the Raspberry Pi cluster. I am using the Docker 1.12 build and install it on the Raspberry Pi. When Docker 1.12 launches the full version, we will update the content accordingly.

Here's a look at the current configuration:

[email protected] $ docker version client:version:1.12.0-rc1 API version:1.24 Go version:go1.6.2 Git commit:1f136c1-u nsupported built:wed June 15:35:51 os/arch:linux/arm server:version:1.12.0-rc1 API version:1.24 Go Version:go 1.6.2 Git commit:1f136c1-unsupported built:wed June 15:35:51 Os/arch:linux/arm

Well, Docker 1.12 RC1 is ready. The necessary services are launched below. First see if we can find new features hidden in the Docker CLI.

[email protected] $ docker usage:docker [OPTIONS] COMMAND [arg ...] docker [--help |-v |--version] A self-sufficient R Untime for containers. ... service Manage Docker services ... stats Display a live stream of container (s) Resource usage statistics ... swarm man Age Docker Swarm ... update update configuration of one or more containers Run ' docker COMMAND--help ' for more informatio N on a command.

I removed the part that was exactly the same as the version of the ancestors, leaving only the difference. Now we can use the Docker swarm command.

Query its specific role:

[email protected] $ docker swarm Usage:docker swarm COMMAND Manage docker swarm Options:--help Print Usage Commands:ini T Initialize a Swarm. Join join a Swarm as a node and/or manager. Update Update the Swarm. Leave leave a Swarm. Inspect inspect the Swarm Run ' Docker Swarm command--help ' For more information on a command.

This means that it is used to "initialize a set of swarm". That looks exactly what we need. Start the command first.

[email protected] $ docker swarm init swarm initialized:current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.

Now that our swarm Management node has started running, add more nodes to the cluster.

Go to another node in the cluster and execute:

[email protected] $ Docker swarm join pi6:2377 This node joined a swarm as a worker.

Using the above command, we declare each new node that should join the Swarm management node in the initial swarm cluster that we just created. Docker swarm performs related operations in the background.

For example, it sets up encrypted communication channels for each of the different cluster nodes. We no longer need to manage our own TLS certificates.

Every friend who has ever set up a Docker swarm cluster will realize how simple the new process is. But it's not over yet.

A "Docker info" in the Swarm Management node brings some interesting hints. I still delete unnecessary parts of it:

[email protected] $ docker info ... Swarm:active nodeid:1njlvzi9rk2syv3xojw217o0g ismanager:yes managers:1 nodes:2 CACertHash:sha256:de4e2bff3b63700aad 01DF97BBE0397F131AABED5FABB7732283F044472323FC ... Kernel version:4.4.10-hypriotos-v7+ Operating System:raspbian gnu/linux 8 (Jessie) Ostype:linux architecture:armv7l CP Us:4 Total memory:925.4 MiB name:pi6 ...

As you can see, we now have a new "Swarm" section in the "Docker info" output, which tells us that the current node belongs to a set of Swarm management nodes, and that the cluster is comprised of two cluster nodes.

On the second node, the output results are slightly different from the management node:

Swarm:active nodeid:3fmwt4taurwxczr2icboojz8g Ismanager:no

Here we have a set of interesting but still empty swarm clusters.

We also need to understand the new abstract definition of service in Docker 1.12. You may have noticed the Docker Service command in the previous output. A docker service is a piece of software that runs in a container and is responsible for providing the outside world with a "service" running within a swarm cluster.

Such a service can consist of a single or multiple sets of containers. In the latter case, we can ensure that the service has high availability and/or load balancing capabilities.

The following uses the "WhoAmI" image created earlier to establish such a service.

[email protected] $ docker service Create--name whoami-p 80:8000 Hypriot/rpi-whoami buy0q65lw7nshm76kvy5imxk3

With the help of the "Docker swarm ls" command, we can check the status of this new service.

[email protected] $ docker Service LS ID NAME scale IMAGE COMMAND buy0q65lw7ns whoami 1 Hypriot/rpi-whoami

The following checks whether we can request a directory page by sending an L HTTP command to the Eth0 network interface via the Curl command.

[Email protected] $ curl http://192.168.178.24 I ' m 1b6df814c654

All goes well, clap! Some friends may notice that the "scale" section exists in the header row of the "Docker swarm ls" command, which seems to imply that we can extend the service.

[email protected] $ Docker service scale whoami=5 WhoAmI scaled to 5

Let's actually verify it:

[email protected] $ docker Service LS ID NAME scale IMAGE COMMAND buy0q65lw7ns whoami 5 Hypriot/rpi-whoami [email protecte D] $ for i in {1..5}; Do Curl http://192.168.178.24; Done

Very simple.

But this way is similar to the original swarm, but it is more convenient and faster to use the feeling. Note that we are using Raspberry Pi instead of a powerful server, so we want to have a more conservative estimate of performance.

The following is the current state of operation from the perspective of a single Docker engine:

[email protected] $ docker PS CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

As you can see, there are 5 sets of containers that have been activated, 3 of which reside in the "Pi6". Let's see if we can find other containers:

[email protected] Docker PS CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES db411a119c0a hypriot/rpi-whoami:latest " /http "6 minutes ago up 6 minutes 8000/tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj 0a4bf32fa9c4 hypriot/rpi-whoami:latest"/ht TP "6 minutes ago up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k

So what happens if we swarm this set of clusters on "Pi1"?

[email protected] Docker swarm leave Node left the default swarm.

Here's how it works on the other node:

Docker PS CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

The situation here is equivalent to a "PI1" node failure, at which time all the containers running in "Pi1" are automatically migrated to another cluster node. This mechanism is undoubtedly very important in the actual production.

So here's a look at the information we've learned before:

We have created a small dynamic microservices application that is completely composed of Docker. Docker Swarm is now integrated into the docker-engine and no longer exists as a standalone software. In most cases, this can create an independent proxy mechanism for application backend services. No need to use Nginx, Haproxy, or Traefik.

Although the number of moving parts has decreased, we now have built-in high availability and load balancing capabilities. I'm looking forward to new surprises in the upcoming Docker swarm release and how to collaborate with Docker compose.

Docker1.12 + Swarm Building dynamic microservices applications