11 Mar

Using Docker Swarm? You gonna love Ansible 2.8!

The Ansible is kind of an icon of automation platform. Owned by RedHat but available as a free product on the public license. Developed both by RedHat employees and the community. Docker itself is an icon of containerization. If you use containers you know that automation is the key to simplify management of dockerized infrastructure. In Ansible 2.x many modules covering the docker operations has been introduced, but Docker Swarm was not really covered. However, it is going to change soon! There is a huge update coming with Ansible 2.8 release!

Lately, I started missing some features in Ansible that will allow me to perform some operations on Docker Swarm clusters. And I try to avoid using the command or shell modules as much as possible – running CLI commands on a remote host is like asking for troubles. I decided to fill this gap by myself and as a result, I can say I am now the Ansible community developer, author, and maintainer of a few modules – docker_swarm_facts, docker_node_facts, docker_host_facts, docker_node; and co-author of docker_swarm and the ansible.docker.swarm library.

In next posts, I wanna show you how those modules work. However, if you are looking forward using them I strongly advise you to give them a try now and report any bugs you find so we can fix them before Ansible 2.8 release. You can find them in the devel branch of Ansible repository.

Docker Swarm management in Ansible 2.8

The first modules for Swarm features were introduced in Ansible 2.7. The docker_swarm is for Swarm cluster configuration and reconfiguration while docker_swarm_service is for services management. In Ansible 2.8 you will find lots of bug fixes and improvements for those modules. My addition to the swarm management modules family is docker_swarm_facts.

Reading the information about the Swarm is part of the docker_swarm already. However, this is against the Ansible design. According to the best practices separate modules should exists for reading the state and performing the changes. Of course in the second case module can return some information about the state after the change but should not have the inspect feature implemented. The dedicated modules for reading the state, or as it is called in Ansible the facts, should end with the _facts suffix.

My docker_swarm_facts module is designed for reading the swarm configuration form the Swarm manager node.

- name: Get info on Docker Swarm
  docker_swarm_facts

The output will contain the Swarm cluster information including the worker and manager Join Tokens. It also gathers Swarm parameters available in output of other CLI commands, not only Swarm related ones. Using the module you can easily get the Raft parameters, Cluster ID or Lock status. It returns also Swarm configuration version numer which is not accessible via CLI.

List Swarm objects

There is one additional feature allowing you to get the lists of the nodes, services, and tasks. The result includes names as well as necessary information similar to the output of docker node ls, docker service ls or docker service ps commands. You can easily use those lists in other tasks in loops.

- name: Get info on Docker Swarm and extended list of registered nodes
  docker_swarm_facts:
    nodes: yes
    tasks: yes
    services: yes

To request list you need to set dedicated parameter to yes. Default output contains almost the same information as the respective CLI command output. To get more details you can add verbose_output: yes parameter which extends the range of attributes for each object on the list. However it is still not as complete as dedicated _facts module output for each object type.

- name: Get info on Docker Swarm and extended list of registered nodes
  docker_swarm_facts:
    nodes: yes
    verbose_output: yes

For each type of listed objects you can also use filters.

Happy testing of Ansible 2.8!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: