Docker1.12 + Swarm build dynamic microservice applications

Docker1.12 + Swarm build dynamic microservice applications
GuideWe have mentioned an example before, that is, a microservice application composed of a front-end and multiple backend services. The frontend is the Traefik HTTP proxy, which routes requests to the backend service. The backend is very simple. It is a set of HTTP Web Servers Based on Go and is responsible for returning the ID of the container where it runs.

The new Docker Swarm does not need to set an independent HTTP proxy for the Application container. The original architecture shown in is now simplified as shown in the following format:

Fewer moving parts-like!

In addition, we also have a built-in load balancing mechanism for backend services. We can even access these services from any node in the cluster. Docker Swarm also integrates a built-in mesh Routing Mechanism to route requests to suitable backend containers.

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

Still skeptical? Let's take a look.

That's right. We still use the Raspberry Pi cluster this time. I am using Docker 1.12 and install it on the Raspberry Pi. After the official version of Docker 1.12 is released, we will update the content accordingly.

Next let's take a 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

Good. Docker 1.12 RC1 is ready. Start the necessary services. First, let's see if we can find the hidden new functions in Docker CLI.

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 directly removed the parts that are exactly the same as those of the previous generation, but only kept the differences. Now we can use the docker swarm command.

Query its specific functions:

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 to say, it is used to "initialize a set of Swarm ". It seems exactly what we need. Start the command first.

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

Now our Swarm management node is running, and then 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 in the initial Swarm cluster we just created that each new node should be added to the Swarm management node. Docker Swarm Performs related operations in the background.

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

Every friend who once 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 tips. I still Delete unnecessary parts:

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 you can see, we now have a new "Swarm" section in the "docker info" output result, which tells us that the current node belongs to a set of Swarm management nodes, the cluster consists of two cluster nodes.

The output result of the second node is slightly different from that of the Management node:

Swarm: active NodeID: 3fmwt4taurwxczr2icboojz8g IsManager: No

Here, we have an interesting but 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. Docker service is a software segment that runs in a container and is responsible for providing services to the external world in a Swarm cluster.

Such a service can be composed of one or more 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 checks whether the curl command can send the l http command to the eth0 network interface to request the directory page.

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

All goes well, applaud! Some may notice that the "SCALE" section exists in the header line of the "docker swarm ls" command, which seems to mean we can expand the service.

root@pi6 $ docker service scale whoami=5 whoami scaled to 5

Let's 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

Very simple.

However, this method is similar to the original Swarm, but it is easier and faster to use and feel. Please note that we use Raspberry Pi instead of powerful servers, so we need to have a more conservative estimation of performance.

The following describes the current running status from the perspective of a single Docker engine:

root@pi6 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

As you can see, there are 5 started containers, 3 of which reside in "pi6. Let's see if other containers can be found:

root@pi1 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 "/http" 6 minutes ago Up 6 minutes 8000/tcp whoami.3.2r6mm091c2ybr0f9jz4qaxw9k

What if we place this Swarm cluster on "pi1?

root@pi1 docker swarm leave Node left the default swarm.

Next let's take a look at the running status on another node:

docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

This is equivalent to the failure of the "pi1" node. At this time, all containers running in "pi1" will be automatically migrated to another cluster node. This mechanism is undoubtedly very important in actual production.

Next, let's review the previous information:

We have created a small dynamic microservice application, which is totally composed of Docker. Docker Swarm is now integrated into Docker-Engine, instead of independent software. In most cases, this can establish an independent proxy mechanism for the Application backend service. Nginx, HAProxy, or Traefik is no longer required.

Despite the decrease in the number of active parts, we now have built-in high availability and load balancing functions. I am very much looking forward to what new surprises will be brought about in the official version of Docker Swarm and how to collaborate with Docker Compose.

From: https://linux.cn/article-7607-1.html

Address: http://www.linuxprobe.com/docker1-12-swarm.html