Prototypage d'infra à l'aide de Docker et Ansible

J'utilise depuis quelques temps l'outil Ansible pour gérer mes environnements. Il y a peu, j'ai eu besoin de mettre en place des tests automatiques. Comme toujours, c'est posé la question de savoir où lancer ces fameux tests.

La réponse classique aurait de se baser sur des VM mais comme d'habitude, j'avais des difficultés à avoir ces machines :

• Il faut demander une entrée DNS ;
• Il me faut une adresse IP ;
• Il faut l'installer ;
• Attention, l'hyperviseur est bientôt saturé ;
• Mais qui va payer ?
• Mais qui va sauvegarder ?

Bref, comme toujours, la VM de test est presque aussi compliquée à installer qu'une VM de production et je n'arrive pas à expliquer aux gens qu'il s'agit d'un besoin jetable.

Dans ce cadre, j'ai repensé aux quelques tests que j'avais réalisé sur Docker il y a quelques temps et je me suis dit que ce produit pourrait très bien répondre à mon besoin.

Disclaimer : Ce qui va suivre n'est absolument pas conseillé dans le cadre d'une production. Ce besoin s'inscrit dans un besoin de prototypage d'infra. Ce mode de fonctionnement n'est pas assez stable - du moins pour l'instant - dans des besoins sérieux.

Bref, je demande une VM avec Docker dessus et partant de là, je peux commencer à travailler.

Le principe

Mon besoin est de pouvoir me connecter à un container en faisant mes opérations comme si j'étais dans une vraie machine. Pour se faire, je suis quand même obligé de lancer un process pour faire croire à Docker et Ansible que quelque chose tourne. Dans un premier temps, j'ai fait quelques tests en lançant avec des commandes sleep ou tail -f /dev/null. Le problème est que lorsque j'ai voulu démarrer mes services à l'aide de systemd, j'ai eu quelques plantages.

Problème systemd dans Docker

L'un des premiers problèmes que j'ai abordé a été la gestion des spécificités de systemd. En effet, dans le cas des distributions modernes (centos 7, ubuntu 15.10 ou 16.04), le démarrage est entièrement géré par systemd. Le seul petit hic étant que ce dernier change entièrement la façon de gérer les services. C'est assez marrant d'ailleurs, ce changement m'a fait pensé à la refonte des services dans Solaris 10 (attention, un troll c'est glissé dans ce paragraphe).

Il faut donc embarquer systemd dans votre container Docker. Mais d'un autre côté, ça me permet de virer la commande tail -f.

Ce qu'il y a de rigolo dans tout ça, c'est qu'il est plus simple de gérer un centos 6 dans Docker qu'une version 7.

Problème systemd dans Docker (suite)

Vous allez me dire, dépose un fichier /etc/init.d lance le avec un shell et ça fonctionnera pareil. Et bien non puisque même si vous passez par le script directement, systemd l'intercepte et vous vous retrouvez avec le magnifique message d'erreur suivant :

Failed to get D-Bus connection: Operation not permitted

Le problème vient du fait que systemd a besoin d'accéder à tout un tas de chose pour gérer le contexte de lancement des process. La solution est donc de lancer le container en mode privileged avec les problèmes de sécurité que ça peut entraîner. Encore une fois, il ne s'agit pas d'un problème dans mon contexte mais je vous le déconseille vivement dans un autre contexte (en production par exemple).

Problème systemd dans Docker (suite)

Le lancement du premier container se passe très bien mais rapidement, je constate que certains process getty se lancent en se goinfrant 100% de CPU. En creusant un peu, je me rends compte que systemd (sous centos 7) lance automatiquement le service getty@tty1. Le premier lancement n'a pas de conséquence mais le problème apparaît au lancement des containers suivants. Ici, la solution est relativement simple : désactivation du service à la construction de l'image Docker. Ci-dessous l'instruction dans Dockerfile permettant de le réaliser :

RUN systemctl disable getty@tty1

Redémarrage des containers

Ayant fini par faire fonctionner mes playbooks, je me suis dit qu'il était temps de tester un arrêt/relance du container pour voir comment ça se comporte. Là encore, ça ne fonctionne pas vraiment bien. Ne comptez donc pas (pour l'instant) utiliser systemd pour gérer le démarrage des services de vos containers.

Connexion au container

J'en ai parlé il y a peu mais là, pas de problème : Ansible dispose d'un connecteur docker natif. Il faut donc se débrouiller pour affecter la valeur docker à la variable ansible_connection et le tour est joué.

Modélisation du réseau

Un autre truc qui a bien fonctionné est la capacité de Docker à manipuler des réseaux virtuels. Par le passé, sous Linux, cette partie pouvait être vraiment une gageure. J'avais écrit un article sur le sujet à l'époque. Il vous fallait gérer l'ajout de bridge, gérer la création des interfaces virtuelles de vos VM. Ici, rien de ce genre, vous créez votre réseau et Docker se charge du reste :

• Création du bridge ;
• Visibilité des containers dans le même réseau.

Ci-dessous un exemple de lancement de la création d'un réseau Docker :

docker network create demo

Tous les containers que nous rajouteront dans ce réseau par la suite auront automatiquement une résolution DNS disponible.

Pour conclure

Vous l'aurez compris, systemd et Docker ne sont pas les meilleurs amis du monde. Je trouve ça d'autant plus dommage que je pense qu'il y aurait clairement quelque chose d'intéressant à avoir si le support de ces deux produits avaient été meilleurs. Si comme moi vous avez utilisé des solutions à base de zone Solaris, vous pouvez passer votre chemin, il ne s'agit pas du même niveau de stabilité.

Une autre leçon à retenir de tout ceci est que Docker n'est clairement pas un remplacement d'une virtualisation classique. Ne partez surtout dans l'idée de réutiliser les mêmes outils sans passer du temps sur les adaptations préalables. Cette bascule doit absolument se faire dans le cadre d'une refonte de votre application et de sa gestion.

Pour le reste, l'outil Docker est très pratique à utiliser et vous permettra de prototyper très rapidement votre infra sans trop d'effort.

Un autre outil intéressant que je suis en train de creuser semble être Packer. En effet, cet outil permet de réutiliser vos playbooks pour la création de vos images Docker. Le gros avantage est que vous n'avez donc qu'un travail minimum pour créer indifféremment des machines classiques ou des containers et en vous garantissant d'avoir la même chose partout.

Attention toutefois, il s'agit pour moi d'une situation transitoire si vous avez décidé de partir sous Docker. Il reste très important de mon point de vue de simplifier vos installations et de passer par du Dockerfile. Idéalement, Ansible ne devrait vous servir que pour l'enchaînement de vos différentes tâches ou dans la gestion des machines qui ne sont pas dans le cloud (base de données par exemple) ou pour la gestion de l'infra Docker.

Concernant le code Ansible/Docker, vous pourrez retrouver des exemples dans le repository sur github du repository Meetup Ansible Paris #9. Bonne lecture !