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.