Ansible : Comment générer des labs et développer ses playbooks facilement

par | 19 Sep 2020 | Ansible, Docker | 4 commentaires

Une galère répandue

Tu viens de trouver un bout de playbook sur le web.

Tu te demandes certainement sur quelles machines tu peux le tester ?

  • Tu ne veux pas le tester directement sur un de tes environnements ?
  • Tu as la flemme de déployer une vm juste pour ça ?
  • Ni de perdre du temps à faire des retours sur « snapshot » pour tester tes modifications ?

Tu n’es pas le seul dans cette galère !

Je n’en pouvais plus de ces bricolages en local sur mon poste, de ces vm qui me bouffent toutes mes ressources ou de ces retours sur « snapshot » interminables.

Aujourd’hui, j’aimerais partager avec toi une méthode que j’utilise et qui me change la vie. C’est assez simple, ça fonctionne avec Docker et je suis certain que tu vas trouver ça utile.

Note : Si tu travailles avec Ansible, j’ai créé une cheat sheet pour te faire gagner du temps.

Pourquoi c’est important de pouvoir générer de petits environnements de tests rapidement ?

Tu te demandes peut-être si cela vaut la peine de t’ennuyer avec Docker pour développer ou tester tes playbooks ?

Eh bien, voici 5 raisons qui vont te convaincre de lire la suite :

  • Tu vas vraiment gagner du temps.
  • Tu vas te contraindre à « push » ton code dans un dépôt Git.
  • Ça ne va rien te coûter.
  • Tu peux faire tout cela en ligne, sans installer Docker en local (petite astuce cadeau).
  • Tu pourras tester autre chose que des playbook Ansible.

Sans plus attendre, je te montre ça.

Créer des labs de tests à l’infini avec Docker sans galère.

Lab Ansible facilement

Afin de partager cela avec toi (et d’éventuellement te permettre d’y contribuer), j’ai créé un projet sur Github. Le concept est très simple, il est directement inspiré de la vidéo de « cocadmin » sur le sujet.

Voilà un petit schéma pour voir la cible :

Lab de tests Ansible

On va se créer une machine (un conteneur) « master », depuis laquelle on va développer nos playbooks. Puis, nos machines « slaves » (toujours des conteneurs) seront simplement des conteneurs joignables en SSH.

Je te mets à disposition les images « Docker » qui vont bien pour faire tes petits bricolages.

  • 3 dernières versions de Debian
  • 3 dernières versions d’Ubuntu
  • 2 dernières versions de CentOS

Si tu as besoin d’autres images fais-moi un petit mail, je les ajouterai au dépôt et au Docker hub.

Trois prérequis (ou pas) pour commencer

  1. Docker
  2. Docker-compose
  3. Git

Tous ces outils s’installent en une ligne de commande du type :

sudo apt-get install docker.io docker-compose git  

Tu trouveras en ligne les infos pour installer ces trois petits outils facilement. Je n’ai pas d’inquiétude à ce sujet.

Tu fais peut-être partie de ceux qui bossent sur Windows (c’est mon cas aussi au taf malheureusement). Du coup, ces trois prérequis peuvent être pénibles et je le conçois très bien. Cela même si tu as avec une distrib WSL2 et qu’il existe des solutions de contournement qui font que c’est envisageable.

Si tu veux esquiver toute la partie galère de mise en place des prérequis, tu peux te rendre sur le site « Play whith docker ». C’est un projet maintenu par l’équipe docker. Ils mettent un lab à disposition pour tester Docker gratuitement. Tu as juste à créer ton compte docker et c’est parti, tu as accès à un environnement docker fonctionnel 😉

Jusque-là donc, pas de galère, c’est simple. La suite va être encore plus simple.

Étape 1 : Cloner le dépôt

Tout ce dont tu as besoin se trouve sur un dépôt public Github. Il te suffit de le cloner.

git clone https://github.com/acoilier/ansible_lab.git

Voici une petite explication de l’arborescence du projet :

.
├── config				# Répertoire avec les fichiers de conf pour Ansible
│   ├── ansible.cfg		
│   └── hosts
├── docker-compose.yml	# docker-compose d'exemple pour créer le lab
├── dockerfile			# Répertoire contenant les dockerfile
├── README.md			
└── workdir				# Le répertoire de travail
    └── ping.yml		# Playbook pour tester l'accès a nos machines

L’objectif est de développer ses playbooks depuis le répertoire « workdir ». Les fichiers « hosts » et « ansible.cfg » utilisés par défaut par Ansible sont présents dans le répertoire « config ».

Ces fichiers sont mappés directement sur le serveur « master ». Ça te permet de créer et supprimer ce serveur sans perdre tes modifications. Tu peux les modifier depuis ton poste avec l’IDE de ton choix. Moi j’utilise « Visual studio code » et j’ouvre le terminal directement depuis celui-ci.

Note : si tu ne comptes pas modifier les images Docker de tes serveurs, tu peux supprimer le répertoire « dockerfile« .

Maintenant que tu as la structure de ton espace de travail, tu vas pouvoir commencer à construire ton lab.

Étape 2 : Choisir ses serveurs

Pour créer tes serveurs avec Docker tu dois les déclarer dans le fichier docker-compose.yml. C’est un fichier « yaml » que Docker va lire pour créer ton lab. Tu as simplement à modifier celui qui se trouve à la racine du projet.

version: '3'
services:
  master:
    container_name: master
    image: acoilier/ubuntu-ansible:latest
    working_dir: /root/workdir
    volumes:
      - ./workdir:/root/workdir
      - ./config:/etc/ansible
    command: tail -f /dev/null
  
  debian:
    container_name: debian
    image : acoilier/debian-sshd:latest
  ubuntu:
    container_name: ubuntu
    image: acoilier/ubuntu-sshd:latest
  centos:
    container_name : centos
    image: acoilier/centos-sshd:latest

Le serveur master est déjà fonctionnel, tu peux constater les répertoires « workdir » et « config » qui sont mappés à l’intérieur (lignes 8 et 9).

Pour tes serveurs cibles, il te suffit de suivre les modèles de « services » qui sont déjà déclarés. Par défaut, tu as trois serveurs (Debian, Ubuntu et CentOS) dans leur dernière version. Tu peux changer la version en remplaçant « latest » par la version que tu souhaites.

Pour l’instant, j’ai upload seulement les images des 3 dernières versions de ces 3 OS sur le docker hub. Je te laisse allé vérifier la disponibilité de nouvelles images dans le « README » du dépôt ou sur le site de docker directement.

Pour exemple, si tu ne veux pas la dernière version d’Ubuntu (20.04), mais la version 16.04 :

  ubuntu :
    container_name : ubuntu
    image: acoilier/ubuntu-sshd:16.04

Si tu veux mapper un port local de ta machine pour tester une interface web c’est possible, il te suffit de rajouter les lignes 4 et 5 comme ceci :

  ubuntu :
    container_name : ubuntu
    image: acoilier/ubuntu-sshd:16.04
    ports :
    - "8080:80"

Tu peux également mapper tes serveurs entre eux pour qu’ils communiquent. Par exemple un serveur web vers une base de données avec l’ajout de « links ». Tout cela est bien documenté sur les doc Docker..

Ce qu’il faut retenir c’est que tu puisses utiliser les images Docker et y accéder en SSH. Que le user de connexion c’est « root » et que le mot de passe c’est aussi « root » sur toutes les images.

Étape 3 : Créer son lab

Pour créer ton lab, c’est très simple, il te suffit de te positionner à la racine du projet (là où il y a le fichier docker-compose.yml) et de faire la commande suivante :

docker-compose up -d

À ce moment docker télécharge les images, et te créer ton lab. Quand c’est terminé, tu peux voir les conteneurs qui tournent avec la commande :

docker ps

Imaginons maintenant que tu veuilles plusieurs images Ubuntu. Dans ce cas, il est très simple d’en rajouter avec l’option : –scale. Tu as juste à spécifier : nom_du_service=nombre_de_serveurs.

Il y a un point important si tu veux utiliser cette option, tu ne dois pas définir le nom du conteneur, ils seront générés directement par Docker. Il faudra donc supprimer la ligne « container_name : ubuntu » du service en question dans le fichier docker-compose.yml.

docker-compose up -d --scale ubuntu=3

Tu pourras alors vérifier que tes conteneurs tournent bien avec la commande : docker ps. Tu verras alors le nom qui leur est affecté.

Le nom de tes serveurs est important, car c’est le nom que tu devras utiliser dans ton fichier « hosts » Ansible. En effet docker s’occupe de la résolution DNS entre les conteneurs, on ne s’embête pas avec les IP.

Étape 4 : Se connecter au serveur « master »

Tout devrait être OK, tu vas pouvoir commencer à travailler 😉
Pour cela tu vas pouvoir te connecter au serveur master avec la commande suivante :

docker-compose exec master bash

Te voilà maintenant dans le conteneur depuis lequel tu vas lancer tes playbooks. Quand tu te connectes, tu te retrouves dans le répertoire « workdir » qui contient déjà un playbook « ping.yml ».

Exécute-le pour tester la connexion vers tes serveurs.

Pour rappel tu peux modifier le fichier « hosts » et le fichier « ansible.cfg » depuis le conteneur « master » dans le répertoire « /etc/ansible/ » ou directement depuis ton poste en local, ils se trouvent dans le répertoire « config« .

ansible-playbook ping.yml

Tu peux aussi te connecter directement en « ssh » dans tes conteneurs en « root » :

ssh root@ubuntu

Étape 5 : Développer ses playbooks

developper ses playbook

Pour développer, il te suffit maintenant de créer tes playbooks dans le répertoire « ansible_lab/workdir » sur ton poste en local. Cela te permet d’utiliser ton IDE préféré.

Idem pour le fichier d’inventaire par défaut que tu retrouves sur ton poste local dans : « ansible_lab/config/hosts ».

Pour compléter ton inventaire, il faut bien que tu mettes le nom des conteneurs. Tu peux le savoir avec la commande docker -ps depuis ton poste si tu n’as pas utilisé l’option « container_name ».

[all]
ubuntu
ansible_lab_debian_1

Ensuite, tu lances l’exécution de tes playbooks depuis le serveur « master ».

Voilà un petit screen de mon écran quand je dev mes playbooks. Je travaille sur les fichiers avec mon IDE directement dans l’arborescence locale de mon poste. Je garde deux terminaux, un pour gérer le lab docker (en haut à droite) et l’autre dans le conteneur « master » (en bas à droite) pour lancer mes playbooks.

ansible test playbook

Maintenant, on va voir l’un des principaux avantages de cette solution. C’est la rapidité avec laquelle tu réinitialises ton lab après avoir testé un playbook.

Étape 6 : Supprimer le lab

Pour supprimer le lab, rien de plus simple.

  • Tu te positionnes à la racine du projet (là où il y a le fichier docker-compose.yml).
  • Tu exécutes la commande docker-compose down

Il te suffira alors de relancer la commande : docker-compose up -d pour relancer ton lab.

Les fichiers que tu as modifiés sont gardés, seuls tes serveurs vont être réinitialisés.

Nous en avons terminé avec l’utilisation basic des labs avec docker. Cela couvrira certainement les besoins principaux de beaucoup d’entre nous.

Nous allons maintenant voir deux autres points très pratiques pour aller un peu plus loin.

Customiser les images des serveurs distants

Tu peux les utiliser directement en faisant un « pull », car elles sont toutes sur le Docker hub. Sinon tu peux modifier de fichiers « dockerfile » et les « build » en « local », car ils sont tous présents dans le dépôt.

Utilisation des images « Docker » en une ligne de commande

Il est possible d’utiliser directement les images sans passer par l’image « Master ».

Pour illustrer ça on va faire un test avec en déployant une machine Ubuntu.

sudo docker run -d -P --name test_sshd acoilier/ubuntu-sshd:20.04

Maintenant que ton image est up, il ne te reste plus qu’à voir quel port local est mappé vers le port « ssh » de ton conteneur.

sudo docker port test_sshd 22

La commande docker ps t’indique aussi cette information.

Dans mon cas, c’est le port 37876 pour joindre le conteneur en « SSH ».

Tu peux maintenant tester une connexion, le mot de passe est « root ».

ssh root@localhost -p 37876

Du coup dans ton inventaire Ansible il faudra bien choisir ton IP local et spécifier le port de connexion avec la variable « ansible_port=37876 ».

[ubuntu]
localhost ansible_port=37876

Pour supprimer ton conteneur :

sudo docker stop test_sshd && sudo docker rm test_sshd

Un conteneur ce n’est pas une vm

Petit disclaimer qui me semble quand même utile de préciser.

La plupart du temps, les playbooks que nous développons sont joués sur des machines virtuelles (ou physiques). Il faut garder en tête qu’il y’a des différences entre un conteneur et un serveur.

Par exemple :

  • Il peut manquer des paquets par rapport à une installation depuis l’ISO de la distribution.
  • Un reboot du service principal du conteneur va le stopper. Dans notre cas « sshd ».
  • La gestion du réseau n’est pas disponible.
  • Absence de « systemd ».

La liste n’est pas exhaustive, mais ces quelques points sont les principaux. Si vous avez d’autres problématiques liées à l’utilisation des conteneurs, n’hésitez pas a nous en faire part dans les commentaires.

Bien que ces points puissent être pénibles, ce n’est pas vraiment un problème si on les garde bien en tête.

Conclusion

Tu viens de découvrir comment je m’organise pour tester et développer mes playbooks Ansible. Tu peux toi aussi, et dès maintenant, te créer ces labs en quelques secondes.

Il faut en effet passer passer par l’utilisation de docker (cela peut en freiner certains), mais le gain de temps est garanti.

Crés toi dès maintenant ton petit lab, tu t’en resserviras très certainement. N’oublie pas de télécharger ta « cheat sheet Ansible » et de la garder près de toi 😉

Merci à toi, pour ton attention. Si cet article t’a plu, partage-le, cela me ferait très plaisir.

Alexandre

Alexandre

Admin Devops à Nantes

Créateur de sysadmin as code, j'ai à cœur de proposer des ressources de qualité pour aider les sysadmins à switcher vers le DevOps, kiffer et booster leur carrière.

4 Commentaires

  1. Nicolas K.

    Le problème avec cette approche, tu l’évoques avec l’absence de systemd, c’est que, suite aux changements dans les fichiers de configuration, les rôles ont souvent besoin de redémarrer le service pour lequel ils sont écrit. Et à moins d’utiliser de lancer des conteneurs avec systemd dedans ça ne fonctionnera pas.

    Réponse
    • Alexandre

      En effet c’est un des soucis avec cette approche, il faut bien le garder en tête. Je n’ai pas pris le temps de creuser trop le sujet pour systemd dans les conteneurs, c’est dans ma Todo. Je ferais certainement un update là-dessus…

      Réponse
  2. Fanch

    Molecule est très bien aussi 😉
    https://molecule.readthedocs.io/en/latest/
    Même si leur doc indique que c’est pour tester des roles, je m’en sers souvent pour tester des playbooks, ou des morceaux de playbook

    Réponse
    • Alexandre

      Merci pour ce retour, en effet je n’ai jamais testé Molécule. Je vais regarder de plus près et pourquoi pas en faire un article.

      Réponse

Soumettre un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Newsletter du devops

Bientôt disponible

 

La formation n'est pas encore disponible.

Inscris-toi à la newsletter du sysadmin pour être informé lors de sa sortie.

en savoir plus

On se retrouve dans ta boite mail

Télécharger le PDF

Télécharger la version PDF

 

✔ Possibilité de faire des copier/coller

✔ Version imprimable à garder près de toi

✔ Inscription à la newsletter du sysadmin

Rendez-vous dans tes emails pour télécharger ta cheat sheet.

Pin It on Pinterest

Share This

Ça te plait ?

Partage-le avec tes collègues