Testez localement et automatiquement vos déploiements Puppet grâce à Docker

Image non disponible

Puppet est un outil permettant de déployer rapidement des applications et des outils sur les différents environnements d'un projet.

Basés sur un modèle maître/agents, les déploiements, avec Puppet, sont incrémentaux et reproductibles d'un environnement à l'autre ou d'une instance de machine à une autre.

Néanmoins, tout n'est pas parfait et il peut être compliqué de tester ses développements en local ou de tester de manière automatisée les déploiements.

Heureusement, Docker va permettre d'améliorer tout cela.

Pour les besoins du tutoriel, un simple projet Node.Js illustrera les choses.

Les sources utilisées sont disponibles sur Github.

Pour vos suggestions et commentaires, un espace est créé sur le forum.
1 commentaire Donner une note à l'article (5)

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Besoin initial

Sur ma mission actuelle, tous les déploiements sont effectués avec Puppet. Comme sur la plupart des projets, plusieurs environnements sont disponibles pour les différentes phases de développement : plateforme de développement, intégration, recette, préproduction et production.

Les applications sont packagées sous forme de RPM (format des packets sous Red Hat, CentOS) et un repository yum personnalisé est disponible pour les déployer.

La première problématique rencontrée est la suivante :

aucun environnement spécifique n'est dédié aux développements Puppet. Ceux-ci se font donc directement sur l'environnement de développement, au risque de parfois bloquer les déploiements d'applications qui se font en continu sur cet environnement ;

de plus, ces développements ne sont pas versionnés directement depuis l'environnement et doivent être reportés sur le poste du développeur pour qu'il puisse les pusher.

II. Tester en local grâce à Docker

Pour répondre à cette problématique, Docker semble être la solution la plus pertinente. Il va permettre de démarrer facilement son propre environnement en local semblable à la dev et de tester tout type de machine.

II-A. Création des images

Tous les services utilisés sur les environnements sont démarrés à partir de systemd sur une base centOS 7. L'image suivante va servir de base à la mise en place de la solution :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
FROM centos:7

ENV PUPPET_VERSION 3.8.7

RUN rpm --import https://yum.puppetlabs.com/RPM-GPG-KEY-puppetlabs && \
    rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
RUN yum install yum-utils -y && \
    yum-config-manager --enable centosplus >& /dev/null && \
    yum clean all
RUN yum install puppet-server-$PUPPET_VERSION -y \
    && yum clean all

RUN (cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;

VOLUME [ "/sys/fs/cgroup" ]

CMD ["/usr/sbin/init"]

Cette image réalise deux choses importantes :

  • installation de Puppet à partir d'une base CentOS 7 (ligne 5 à 11). Il s'agit du dernier RPM disponible et non de la dernière version de Puppet ;
  • activation de systemd. Par défaut, l'image CentOS ne permet pas l'exécution de systemd et l'erreur suivante est renvoyée : systemd failed to get d-bus connection.
    Les services utilisant systemd, cette image l'active et permettra de simuler l'environnement souhaité (ligne 13 à 22).

La philosophie de Docker prône un container pour un service. C'est pourquoi systemd est désactivé dans l'image de base CentOS. L'utilisation faite ici de Docker va à l'encontre de ce principe, ceci afin de simuler une machine complète et non un container classique.

Comme évoqué plus haut, Puppet fonctionne en master/slaves, deux images sont nécessaires. Voici le master :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
FROM xebia/centos7-systemd:latest

EXPOSE 8140

VOLUME ["/etc/puppet"]

COPY ./puppet-master.sh /opt/
COPY ./puppet-master.conf /etc/puppet/puppet.conf
COPY ./puppet.service /etc/systemd/system/

RUN chmod +x /opt/puppet-master.sh

RUN chmod +x /etc/systemd/system/puppet.service

RUN ln -s /etc/systemd/system/puppet.service /etc/systemd/system/multi-user.target.wants/puppet.service

CMD ["/usr/sbin/init"]
  • Cette image se base sur celle créée précédemment.
  • Les agents Puppet communiquent avec le master via le port 8140. Il est donc exposé ligne 3.
  • Ligne 7 à 9, copie des fichiers nécessaires au démarrage du service puppet-master.
  • Ligne 15, activation du service puppet-master qui sera démarré automatiquement via systemd.
  • Ligne 17, la commande /usr/sbin/init permet d'initialiser le container ainsi que les services systemd (donc le puppet-master).

Voici une description rapide des fichiers copiés dans cette image :

  • puppet-master.sh : élimine tous les certificats enregistrés dans le puppet-master. Ceci permet de lancer plusieurs fois un container agent avec le même nom. Il démarre également Puppet en mode master ;
  • puppet-master.conf : configuration de Puppet. Point important, les certificats SSL sont autoacceptés afin de permettre l'automatisation de la création d'agents ;
  • puppet.service : fichier de description de service pour systemd démarrant le puppet-master.sh.

Voici l'image de l'agent Puppet :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
FROM xebia/centos7-systemd:latest

COPY ./puppet-agent.sh /opt/

COPY ./puppet-agent.conf /etc/puppet/puppet.conf

RUN chmod +x /opt/puppet-agent.sh

CMD ["/usr/sbin/init"]

Plus simple, elle copie un script permettant la connexion au puppet-master.

II-B. Provisionning

À présent, toutes les images nécessaires au développement en local sont disponibles. Pour faciliter l'utilisation de celles-ci, voici un fichier docker-compose décrivant les containers à lancer :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
version: '2'
services:
  master:
    image: xebia/puppet-master
    hostname: master.docker
    ports:
      - "8140:8140"
    cap_add:
      - SYS_ADMIN
    volumes:
      - ./puppet/modules:/etc/puppet/modules
      - ./puppet/hieradata:/etc/puppet/hieradata
      - ./site.pp:/etc/puppet/manifests/site.pp
      - ./hiera.yaml:/etc/puppet/hiera.yaml

  repo:
    image: xebia/puppet-agent
    hostname: repo.docker
    ports:
      - "80"
    links:
      - master
    depends_on:
      - master
    cap_add:
      - SYS_ADMIN
    volumes:
      - ./repo:/opt/repo/

Sans rentrer dans les détails de ce fichier, voici les points essentiels.

  • Deux services sont présents : le puppet master et le service repo permettant d'avoir un repository yum local. Le principe d'installation d'un repository yum personnel étant hors scope de l'article, je vous invite à voir le code source pour plus de détails.
  • Chaque service possède la capacité SYS_ADMIN nécessaire au bon fonctionnement de systemd.
  • Les volumes mis à disposition via le docker-compose.yml permettent la mise en place d'un « hot reload » des sources Puppet. Ainsi il ne sera pas nécessaire de relancer les containers pour tester les développements.

II-C. Lancement

Tout est à présent prêt pour tester les développements en local. Pour ce faire, il suffit de lancer les commandes suivantes :

 
Sélectionnez
1.
2.
3.
4.
$> docker-compose up -d
Creating network "articlepuppetdocker_default" with the default driver
Creating articlepuppetdocker_master_1
Creating articlepuppetdocker_repo_1

Cette commande lance la base nécessaire au développement. À noter le nom des containers créés qui vont servir par la suite.

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
$> docker exec articlepuppetdocker_repo_1 /opt/puppet-agent.sh
$> docker exec articlepuppetdocker_repo_1 /usr/bin/createrepo /opt/repo
Spawning worker 0 with 1 pkgs
Spawning worker 1 with 0 pkgs
Spawning worker 2 with 0 pkgs
Spawning worker 3 with 0 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

La première commande permet à l'agent d'attendre que le puppet master soit up, puis lance Puppet afin qu'il provisionne le nécessaire au repository local.

La deuxième commande crée le repository en tant que tel avec les RPM stockés dans le répertoire ./repo de la machine.

À présent, le développement local porte sur la machine app1. Pour tester ce développement, la commande suivante permet d'instancier le container :

 
Sélectionnez
$> docker run -h app.docker --rm --cap-add=SYS_ADMIN --name puppet_test_1 -p 3000:3000
-h app1.docker -e FACTER_environment="dev" --link articlepuppetdocker_master_1
--link articlepuppetdocker_repo_1 --network articlepuppetdocker_default xebia/puppet-agent

Les paramètres importants de cette commande sont :

  • --cap-add=SYS_ADMIN : comme pour les autres containers, cette capacité est nécessaire pour systemd ;
  • -e FACTER_environment="dev" : variable d'environnement Puppet permettant de spécifier l'environnement du container. Elle pourra être passée à « prod » pour tester la configuration de prod ;
  • Les deux --link pour que le container puisse communiquer avec le puppet master et le repo (nom de container obtenu lors de la commande docker-compose) ;
  • --network articlepuppetdocker_default afin de connecter le container au réseau créé par la commande docker-compose.

Maintenant, il est possible de lancer autant de fois que nécessaire l'agent puppet pour tester le développement :

 
Sélectionnez
$> docker exec puppet_test_1 puppet agent -t

Dans l'exemple de l'article, le curl suivant permet de valider les déploiements :

 
Sélectionnez
$> curl localhost:3000
Hello World!

III. Un peu d'automatisation

Nous pouvons maintenant tester les développements Puppet en local. Mais, toujours grâce à Docker, il est possible de pousser le principe plus loin et de tester automatiquement le déploiement de l'application sur les différentes plateformes.

L'application nodeJs écoute le port 3000 sur la dev, mais le port 8000 en production. Ceci est une version simpliste de ce que l'on trouve dans la vraie vie. En fonction de l'environnement, les configurations des applications et des machines changent. Ces changements sont visibles dans les fichiers hieradata et il n'est pas rare de voir un oubli de configuration sur un environnement en particulier.

Encore une fois, Docker va permettre de tester tout ça facilement. Un des paramètres parmi ceux utilisés pour lancer le container de test (FACTER_environment) permet de spécifier l'environnement où se déploie virtuellement l'application.

Ainsi, il est possible de tester n'importe quelle configuration de déploiement. Voici un exemple de script shell permettant de tester tous les environnements de l'application (dev, prod) run_jenkins.sh :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
#!/usr/bin/env bash

docker-compose up -d
docker exec articlepuppetdocker_repo_1 /opt/puppet-agent.sh
docker exec articlepuppetdocker_repo_1 /usr/bin/createrepo /opt/repo

# Test
EXIT=0
for env in dev prod
do
    echo "Launch container"
    docker run -h app1.docker.$env -d --cap-add=SYS_ADMIN --name puppet_test_1 -e FACTER_environment="${env}" --link articlepuppetdocker_master_1 --link articlepuppetdocker_repo_1 --network articlepuppetdocker_default xebia/puppet-agent
    echo "Execute puppet"
    docker exec puppet_test_1 puppet agent -t
    RETURN=$?
    if [ $RETURN -ne 2 ] && [ $RETURN -ne 0 ]
    then
       echo "Fail in puppet run ${env}."
       EXIT=1
    else
        echo "Success in puppet run ${env}."
    fi
    echo "Stop container"
    docker stop puppet_test_1
    echo "Rm container"
    docker rm -v puppet_test_1
done

Intégré dans une usine logicielle type Jenkins, ce script permettra de tester automatiquement tous les environnements pour toutes les machines.

IV. Conclusion

Cette solution a été mise en place suite à un besoin réel chez un client. Exécuté toutes les nuits à travers Jenkins, le script permet le test de 12 types de machines différents sur 6 environnements soit 72 types de déploiements. Ce script permet d'éviter les oublis de configuration sur les environnements post-dev.

La partie développement en local facilite grandement la vie de l'équipe DevOps qui ne bloque plus les développeurs pour tester les développements Puppet. Ils peuvent également travailler avec leur IDE préféré et avoir tous les outils classiques d'un développeur à disposition.

Notes de la rédaction Developpez.com

Nous remercions Xebia pour l'autorisation à publier ce tutoriel. Nos remerciements également à Winjerome pour la mise au gabarit Developpez.com et Claude Leloup pour sa relecture orthographique.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2017 Romain Niveau. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.