Code articles | Docker1.12 + Swarm build dynamic micro-service applications

In this article, we talked about how Docker Swarm can be further simplified by innovation. In fact, now we have been able to easily and intuitively build a set of Docker Swarm cluster, come together to experience it 🙂

Let's take a look at the specific update:

We mentioned in the previous example, that is, a front-end and a number of back-end services together constitute the micro-service applications. Where the front end is the Traefik HTTP proxy, which is responsible for routing the requests to the backend. And the back-end is very simple, is a set of HTTP-based HTTP Web server, responsible for the return of its operation of the container ID.

1.jpg

The new Docker Swarm no longer needs to set up a separate HTTP proxy for the application container. The original architecture shown above is now streamlined to the form shown below:

2.jpg

Move widgets less – praise!

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

Faced with these new features, some friends may think that Docker Swarm cluster set the process will be more complex than the original. In fact, the whole process is more simple.

Still dubious? Here's a look.

Yes, this time we still use the Raspberry Pi cluster. I am using the Docker 1.12 internal version and installed it on Raspberry Pi. When the Docker 1.12 launched the official version, we will make targeted updates to the content.

Now look at the current configuration:

  Root @ pi6 $ docker version 
Client:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS / Arch: linux / arm

Server:
Version: 1.12.0-rc1
API version: 1.24
Go version: go1.6.2
Git commit: 1f136c1-unsupported
Built: Wed Jun 15 15:35:51 2016
OS / Arch: linux / arm

Well, Docker 1.12 RC1 is ready. Start the necessary services below.

First look at whether we can find hidden in the Docker CLI new features.

  Root @ pi6 $ docker 
Usage: docker [OPTIONS] COMMAND [arg ...]
Docker [--help | -v | --version]

A self-sufficient runtime for containers.
...
Service Manage Docker services
...
Stats Display a live stream of container (s) resource usage statistics
...
Swarm Manage Docker Swarm
...
Update update configuration of one or more containers

Run 'docker COMMAND --help' for more information on a command.

I removed the parts that were exactly the same as the previous generation, but only left the difference.

Now we can use the docker swarm command.

Query its specific role:

  Root @ pi6 $ docker swarm 

Usage: docker swarm COMMAND

Manage Docker Swarm

Options:
--help Print usage

Commands:
Init 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.

That is used to "initialize a set of Swarm". It looks like we need it. Start the command first.

  Root @ pi6 $ docker swarm init 
Swarm initialized: current node (1njlvzi9rk2syv3xojw217o0g) is now a manager.

Now that our Swarm management node is already running, we will add more nodes to the cluster.

Go to another node in the cluster and execute:

  Root @ pi1 $ docker swarm join pi6: 2377 
This node joined a Swarm as a worker.

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

For example, it sets up encrypted communication channels for 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 here is not over yet.

Swarm management node in a "docker info" brings some interesting tips. I still delete the unnecessary parts of it:

  Root @ pi6 $ docker info 
...
Swarm: active
NodeID: 1njlvzi9rk2syv3xojw217o0g
IsManager: Yes
Managers: 1
Nodes: 2
CACertHash: sha256: de4e2bff3b63700aad01df97bbe0397f131aabed5fabb7732283f044472323fc
...
Kernel Version: 4.4.10-hypriotos-v7 +
Operating System: Raspbian GNU / Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 925.4 MiB
Name: pi6
...

As we have seen, we now have a new "Swarm" section in the "docker info" output that tells us that the current node belongs to a set of Swarm management nodes and that consists of two cluster nodes.

On the second node, the output is slightly different from the managed node:

  Swarm: active 
NodeID: 3fmwt4taurwxczr2icboojz8g
IsManager: No

Here, we already have a set of interesting but still empty Swarm cluster.

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. The so-called docker service refers to the software fragment that runs in the container and is responsible for providing the "service" running in the Swarm cluster for the outside world.

Such a service may 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 previously created "whoami" image to create such a service.

  Root @ pi6 $ 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.
Root @ pi6 $ docker service ls
ID NAME SCALE IMAGE COMMAND
Buy0q65lw7ns whoami 1 hypriot / rpi-whoami

The following check whether we can through the curl command to the eth0 network interface to send l http command, which requested the directory page.

  Root @ pi6 $ curl http://192.168.178.24 
I'm 1b6df814c654

Everything goes well, applaud!

Some friends may notice that there is a "SCALE" section in the header row of the "docker swarm ls" command, which seems to mean that we can extend the service.

  Root @ pi6 $ docker service scale whoami = 5 
Whoami scaled to 5

Then to actually verify it:

  Root @ pi6 $ docker service ls 
ID NAME SCALE IMAGE COMMAND
Buy0q65lw7ns whoami 5 hypriot / rpi-whoami

Root @ pi6 $ for i in {1..5}; do curl http://192.168.178.24; done
I'm 8db1657e8517
I'm e1863a2be88d
I'm 1b6df814c654
I'm 8db1657e8517
I'm e1863a2be88d

very simple.

But this way with the original Swarm in fact almost, but in the use of more convenient and faster. Please note that we are using Raspberry Pi rather than a powerful server, so we have a more conservative estimate of performance.

Here from the perspective of a single Docker engine to see the current operating status:

  Root @ pi6 $ docker ps 
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
E1863a2be88d hypriot / rpi-whoami: latest "/ http" 2 minutes ago Up 2 minutes 8000 / tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot / rpi-whoami: latest "/ http" 2 minutes ago Up 2 minutes 8000 / tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot / rpi-whoami: latest "/ http" 8 minutes ago Up 8 minutes 8000 / tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52

As you can see, there are 5 sets of containers that have been launched, of which 3 are in "pi6".

Let's see if you can find other containers:

  Root @ pi1 docker ps 
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Db611a119c0a hypriot / rpi-whoami: latest "/ http" 6 minutes ago Up 6 minutes 8000 / tcp whoami.2.2tf7yhmx9haol7e2b7xib2emj
0a4bf32fa9c4 hypriot / rpi-whoami: latest "/ http" 6 minutes ago Up 6 minutes 8000 / tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k

So if we will this set of Swarm cluster in the "pi1", the results will be how?

  Root @ pi1 docker swarm leave 
Node left the default swarm

The following look at the operation of another node:

  Docker ps 
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
58620e3d533c hypriot / rpi-whoami: latest "/ http" 46 seconds ago Up 43 seconds 8000 / tcp whoami.2.cgc4e2ixulc2f3ehr4laoursg
Acc9b523f434 hypriot / rpi-whoami: latest "/ http" 46 seconds ago Up 43 seconds 8000 / tcp whoami.3.67bhlo3nwgehthi3bg5bfdzue
E1863a2be88d hypriot / rpi-whoami: latest "/ http" 8 minutes ago Up 8 minutes 8000 / tcp whoami.4.0lg12zndbal72exqe08r9wvpg
8db1657e8517 hypriot / rpi-whoami: latest "/ http" 8 minutes ago Up 8 minutes 8000 / tcp whoami.5.5z6mvsrdy73m5w24icgsqc8i2
1b6df814c654 hypriot / rpi-whoami: latest "/ http" 15 minutes ago Up 14 minutes 8000 / tcp whoami.1.bg4qlpiye6h6uxyf8cmkwuh52

The situation here is equivalent to a "pi1" node failure, where all containers running in "pi1" are automatically migrated to another cluster node. This mechanism is undoubtedly very important in actual production.

Then let's review the information we learned before:

We created a small dynamic micro-service application, entirely by the Docker composition. Docker Swarm is now integrated into Docker-Engine and no longer exists in stand-alone software. In most cases, this can establish an independent proxy mechanism for application back-end services. No longer need to use nginx, HAProxy or Traefik.

Despite the reduced number of active parts, we now have built-in high availability and load balancing capabilities. I am looking forward to the future Docker Swarm official version will bring new surprises, and how to collaborate with Docker Compose.

    Heads up! This alert needs your attention, but it's not super important.