Token

Docker Swarm v1 includes an out-of-the-box discovery service, called Token. Token is integrated into the Docker Hub; hence, it requires all the Swarm nodes to be connected to the Internet and able to reach the Docker Hub. This is the main limitation of Token but, you will soon see, Token will allow us to make some practice in handling clusters.

In a nutshell, Token requires you to generate a UUID called, in fact, token. With this UUID, you can create a manager, act like a master, and join slaves to the cluster.

Re-architecting the example of Chapter 1 with token

If we want to keep it practical, it's time to take a look at an example. We'll use token to re-architect the example of Chapter 1, Welcome to Docker Swarm. As a novelty, the cluster will be not flat anymore, but it will consist of 1 master and 3 slaves and each node will have security enabled by default.

The master node will be the node exposing Swarm port 3376. We'll connect specifically to it in order to be able to drive the entire cluster.

Re-architecting the example of Chapter 1 with token

We can create 4 nodes with the following command:

$ for i in `seq 0 3`; do docker-machine create -d virtualbox 
    node$i; 
    done

Now, we have four machines running the last version of the Engine, with the TLS enabled. This means, as you remember, that the Engine is exposing port 2376 and not 2375.

Re-architecting the example of Chapter 1 with token

We will now create the cluster, starting from the master. Pick up one of the nodes, for example node0, and source its variables:

$ eval $(docker-machine env node0)

We now generate the cluster token and the unique ID. For this purpose, we use the swarm create command:

$ docker run swarm create
3b905f46fef903800d51513d51acbbbe
Re-architecting the example of Chapter 1 with token

As a result, the swarm container outputs the token, and the protocol that we'll be using in this example will be invoked as shown: token://3b905f46fef903800d51513d51acbbbe

Take note of this token ID, for example assigning it to a shell variable:

$ TOKEN=3b905f46fef903800d51513d51acbbbe

We now create a master and try to meet, at least, some of the basic standard security requirements, how is, we'll enable TLS encryption. As we'll see in a moment, the swarm command accepts TLS options as arguments. But how do we pass keys and certificates to a container? For this, we'll use the certificates generated by Docker Machine and placed in /var/lib/boot2docker on the host.

In practice, we mount a volume from the Docker host to the container on the Docker host. All remotely and controlled thanks to the environment variables.

With the node0 variables already sourced, we start the Swarm master with the following command:

$ docker run -ti -v /var/lib/boot2docker:/certs -p 3376:3376 swarm 
    manage -H 0.0.0.0:3376 -tls --tlscacert=/certs/ca.pem --
    tlscert=/certs/server.pem --tlskey=/certs/server-key.pem 
    token://$TOKEN

To begin, we run the container in an interactive mode to observe the swarm output. Then, we mount the node /var/lib/boot2docker directory to the /certs directory inside the swarm container. We redirect the 3376 Swarm secure ports from node0 to the swarm container. We execute the swarm command in the manage mode by binding it to 0.0.0.0:3376. Then we specify some certificates options and file paths and finally describe that the discovery service in use is token, with our token.

Re-architecting the example of Chapter 1 with token

With this node running, let's open another terminal and join a node to this Swarm. Let's start by sourcing the node1 variables. Now, we need swarm to use the join command, in order to join the cluster whose master is node0:

$ docker run -d swarm join --addr=192.168.99.101:2376 
    token://$TOKEN

Here we specify the host (itself) at address 192.168.99.101 to join the cluster.

Re-architecting the example of Chapter 1 with token

If we jump back to the first terminal, we'll see that the master has noticed that a node has joined the cluster. So, at this point of time we have a Swarm cluster composed of one master and one slave.

Re-architecting the example of Chapter 1 with token

Since we now understand the mechanism, we can stop both the docker commands in the terminals and rerun them with the -d option. So, to run containers in daemon mode:

Master:

$ docker run -t-d -v /var/lib/boot2docker:/certs -p 3376:3376 swarm 
    manage -H 0.0.0.0:3376 -tls --tlscacert=/certs/ca.pem --
    tlscert=/certs/server.pem --tlskey=/certs/server-key.pem 
    token://$TOKEN

Node:

$ docker run -d swarm join --addr=192.168.99.101:2376  
    token://$TOKEN

We will now proceed by joining the other two nodes to the cluster, source their variables, and repeat the last command as shown:

$ eval $(docker-machine env node2)
$ docker run -d swarm join --addr=192.168.99.102:2376 
    token://$TOKEN
$ eval $(docker-machine env node3)
$ docker run -d swarm join --addr=192.168.99.103:2376 
    token://$TOKEN

For example, if we open a third terminal, source the node0 variables, and specifically connect to port 3376 (Swarm) instead of 2376 (Docker Engine), we can see some fancy output coming from the docker info command. For example, there are three nodes in a cluster:

Re-architecting the example of Chapter 1 with token

So, we have created a cluster with one master, three slaves, and with TLS enabled and ready to accept containers.

We can ensure that from the master and list the nodes in the cluster. We will now use the swarm list command:

$ docker run swarm list token://$TOKEN
Re-architecting the example of Chapter 1 with token

Token limitations

Token is not deprecated yet, but probably it will be deprecated very soon. The standard requirement that every node in the Swarm should have internet connectivity is not very convenient. Moreover, the access to the Docker Hub makes this technique depend on Hub availability. In practice, it has the Hub as a single point of failure. However, using token, we were able to understand what's behind the scenes a little bit better and we met the Swarm v1 commands: create, manage, join, and list.

Now it's time to proceed further and get acquainted with real discovery services and the consensus algorithm, a cardinal principle in fault-tolerant systems.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset