sebgoa sebgoa on containers, docker, orchestration, swarm

Swarm Reboot in Docker 1.12

Docker 1.12 announced today is a huge change for Swarm users and the container orchestration landscape in general.

Swarm has been totally rebooted using new Docker plumbing called Swarmkit. I will dive into Swarmkit in another post, but let’s have a quick glance at what this reboot means for end-users.

By just checking the usage of the Docker CLI, you will see three new commands:

$ docker swarm --help
$ docker node --help
$ docker service --help

All nodes in a cluster of Docker hosts can join a Swarm easily using Docker CLI commands. A head node first needs to be initialized and then the worker nodes can join the swarm. It will go like this:

$ docker swarm init

And on the worker nodes:

$ docker swarm join head:2377

The listening address of the Swarm master can be changed. A node can join or leave the cluster, or be upgraded to be a head node without the cluster loosing state information. This dynamic membership of the Swarm is made possible thanks to the new Swarmkit plumbing which implements the RAFT consensus algorithm (and for the ones wondering, yes it does so using the CoreOS etcd Golang libraries).

Once your Swarm is created, you can list the nodes in your cluster:

$ docker node ls
ID NAME MEMBERSHIP STATUS AVAILABILITY MANAGER STATUS 06vei5f8lirrltxefjqllwepb * ip-172-31-0-198 Accepted Ready Active Leader  
30p8lhtiqa2hqlamw2g7h4s6q ip-172-31-13-248 Accepted Ready Active  
dgz7a7wsl02fidytma43alilz ip-172-31-13-247 Accepted Ready Active  

From a networking standpoint, Swarm reboot also represents a huge change. Let’s list the networks:

docker network ls  
NETWORK ID NAME DRIVER SCOPE  
cbfa3d02f992 bridge bridge local  
f6f8b8ea7338 docker_gwbridge bridge local  
fd9c6ae182a6 host host local  
3e8l9igaph4f ingress overlay swarm  
1a2d49b62634 none null local  

We now have a default overlay network called ingress to expose services externally. And a new scope for the overlays called swarm. I am still testing the networking changes but they are significant. Remember that recently the engine shipped with an embedded DNS server to provide easy service discovery. Well, here the networking in a Swarm also provides you with embedded load-balancing among containers (think IPVS).

The third new command is docker service. This what you use to launch a group of containers. For example let’s run a service called* game* based on the image runseb/2048 with a guaranteed 4 replicas.

$ docker service create --name game --publish 80:80 --replicas 4 runseb/2048

The service name is what will be registered in DNS, Swarm will load-balanced among the containers that make up the service. A service is made of tasks (ala ECS terminology). If you are familiar with Kubernetes, a Docker Swarm service is basically a deployment (rc) and the tasks are the pods.

$ docker service ls
ID NAME REPLICAS IMAGE COMMAND  
2xia8q3b6io1 game 4/4 runseb/2048

$ docker service tasks game
ID NAME SERVICE IMAGE LAST STATE DESIRED STATE NODE 4tceqzyflwiz0f88kxq9dlqsz game.1 game runseb/2048 Running About a minute Running ip-172-31-0-198  
58grjto24nx5dqtqicp21mtbd game.2 game runseb/2048 Running About a minute Running ip-172-31-13-247  
5lh0wfhw5mqnhodcszomjit37 game.3 game runseb/2048 Running About a minute Running ip-172-31-13-248  
2y6zuue6v67elzfxpxf2uo41l game.4 game runseb/2048 Running About a minute Running ip-172-31-13-248  

I will leave at this for now, but there are lots of things to check, test and learn. The Docker 1.12 changelog is massive. To me the biggest change is listed in the Network section, I put it here again:

  • Built-in Virtual-IP based internal and ingress load-balancing using IPVS #23361

And to recap what that means:

  • Swarm is now embedded in the Docker engine. You get the engine, you get Swarm.
  •  No need for some lengthy bash commands using docker-machine to create you Swarm. Two commands and done.
  • A service is now a first class citizen in Docker which allows replication, update of images and dynamic load-balancing.

If you want to give it a try, I created a quick Ansible playbook to test it.

Docker Inc, is just getting started with this, I can foresee tons of additional development in swarmkit and some added Docker UX. This is good news for Swarm users though, while it will require some changes this is definitely far superior to the now old Swarm.