Camptocamp – Actualités

10 ans de Puppet… et ce n’est pas fini !

22 février 2018

En 2015, Puppet a fêté son 10e anniversaire. Chez Camptocamp, Puppet a totalement révolutionné notre façon d’administrer les systèmes. Nous avons adopté Puppet au cours de l’année 2007, mais cette année marque une étape importante pour nous, puisque nos quatre dépôts git de contrôle Puppet remontent tous à début 2008 ! Il est alors temps de faire un retour en arrière sur 10 ans de pratique Puppet chez Camptocamp, sur ce que nous avons essayé et appris.

puppet

Les dépôts de contrôle

Examinons d’abord nos dépôts de contrôle. Nous utilisons quatre d’entre eux pour gérer quatre infrastructures Puppet différentes (notre propre infrastructure et celle de quatre grands clients). Ce sont tous des dépôts git séparés et ils partagent des modules.

Camptocamp control repository

Lignes de code par auteur dans le dépôt de contrôle de Camptocamp

EPFL control repository

Lignes de code par auteur dans le référentiel de contrôle Client A

Dans chaque dépôt, nous installons des modules locaux (non partagés) résidant dans un répertoire de modules de site, afin qu’ils ne se confondent pas avec les modules partagés tirés par r10k.

Gestion des dépôts

Avant de passer à r10k au début de l’année 2015, nous utilisions git subtree pour gérer les modules dans les dépôts. Nous avions un crontab avec un script (githubsync) responsable de l’extraction des dépôts de modules dans les dépôts de contrôle, chaque nuit. Nous pouvions aussi faire des changements manuellement avec git subtree. La solution était assez souple, mais très sujette aux erreurs et difficile à maintenir (nous avons souvent dû corriger des fusions automatiques qui échouaient).

Gérer les modules Puppet avec git Subtree conduit à un historique complexe

Le passage à r10k en 2015 a réduit de moitié notre base de code en supprimant les modules partagés des dépôts de contrôle.

Lignes de code dans le dépôt de contrôle de Camptocamp

Historiquement, nous avons utilisé deux branches principales dans nos dépôts: stable et staging. La branche stable est utilisée par les machines critiques pour la production tandis que la branche de staging est utilisée par les nœuds moins critiques. De nouvelles fonctionnalités sont ajoutées à la branche staging où elles vivent pendant quelques jours jusqu’ à ce qu’elles soient fusionnées dans la branche stable.

Depuis 2015, le visualiseur de Diff de catalogues Puppet nous a aidé à visualiser les changements entre les deux branches avant de décider de fusionner.

Le visualiseur de Diff de catalogues Puppet aide à comparer les environnements de Puppet

Tests

Comme notre base de code a grandi et que nous avons commencé à distribuer nos modules sur la Forge, il est devenu nécessaire de mettre en place une bonne base pour tester notre code. Au cours de l’année 2013, nous avons mis en place des tests sur la plupart de nos modules et nous les avons connectés à Travis CI pour tester automatiquement nos modules.

Afin d’ajouter des tests d’acceptation à nos modules publics, nous avons commencé à fournir dynamiquement des VM sur notre cloud interne Openstack à l’aide de beaker, puis nous avons commencé à utiliser des conteneurs Docker lorsqu’ils sont devenus disponibles dans les environnements de construction Travis CI.

L’expérience de la mise en place de tests sur nos modules a conduit à une série d’articles de blog sur le développement piloté par les tests (TDD) avec Puppet. Nous avons appliqué cette méthode non seulement aux modules publics, mais aussi à nos modules internes.

Les modules

S’il y a une chose pour laquelle Camptocamp est devenu célèbre dans la communauté Puppet, c’est bien les modules. Bien que nous en maintenions une centaine sur GitHub, nous en avons publié environ la moitié sur la Forge, dont certains modules approuvés.

Modules Camptocamp sur la Forge Puppet. La taille est relative au nombre de téléchargements, l’octocat aux contributeurs et le tag aux releases; les modules verts sont approuvés.

De plus, des membres de notre équipe maintiennent les modules Augeasproviders et contribuent aux efforts de la communauté Voxpupuli.

Voxi (la mascotte de Voxpupuli, la communauté Puppet)

Puppet stack : historique

Au fil des ans, notre Puppet stack a beaucoup changé.

Comme la plupart des premiers adeptes, nous avons commencé avec un Puppet Master qui fonctionnait sur Mongrel, ce qui était plutôt lent. Nous avons ensuite utilisé Apache avec mod_passenger. La sortie de Thin en remplacement de Mongrel a été une bonne occasion pour nous de nous débarrasser d’Apache et de mettre en place des Puppet Masters basés sur Thin derrière un proxy Nginx. A ce stade, le proxy Nginx a été utilisé comme point de terminaison SSL et a permis d’acheminer les demandes vers des Puppet Masters spécifiques en fonction de l’environnement. Nous avions typiquement une machine de base pour les environnements de production (stable et staging) et une plus grosse pour les environnements de test (fonctionnalités + utilisateurs). Cela permettait d’avoir des lancements réactifs lorsque des humains étaient impliqués.

Lorsque Puppet 2.6 est sorti en 2010, notre code n’était pas prêt pour la migration en raison de nombreuses incompatibilités. Nous avons migré directement de 0.25 à 2.7 en 2012, après avoir testé intensivement à l’aide des différences de catalogue sur Jenkins.

En 2013, nous avons adopté Foreman, principalement pour pouvoir visualiser l’état de notre parc. Jusque-là, nous n’avions stocké que les rapports Puppet sur disque et envoyé des rapports sous forme de notifications sur un canal IRC. Foreman nous a donné un aperçu de notre plateforme.

Foreman est un excellent moyen de superviser un parc géré par Puppet.

Nous avons passé une bonne partie de l’année 2013 à préparer nos modules pour migrer vers Puppet 3. C’était une tâche très importante car beaucoup de nos modules historiques utilisaient le scoping dynamique (qui était obsolète dans Puppet 3) sans paramètres de classe (nous avions beaucoup utilisé l’héritage de classe dans Puppet 0.2x pour compenser cela). Ce portage s’est accompagné de nombreux travaux sur les tests (unitaires et d’acceptation) et de l’intégration continue/déploiement continu (CI/CD). Le passage de Puppet 2.7 à Puppet 3 s’est fait début 2014.

La maintenance de dizaines de modules était une tâche importante. Nous avons commencé à utiliser modulesync pour faciliter cette tâche au cours de l’été 2014, et nous l’avons adopté pour synchroniser nos dépôts de contrôle de Puppet en décembre. Depuis lors, nous maintenons nos Puppetfiles à l’aide de modulesync, en utilisant un Puppetfile statique comme modèle et Augeas pour extraire les entrées par référentiel de contrôle. Nous avons également développé puppetfile-updater pour faciliter la maintenance de notre Puppetfile.

Fin 2014, le Puppetserver (Puppet Master sur la JVM) est sorti. Nous l’avons adopté rapidement car la performance a toujours été un problème que nous avons rencontré avec le Puppet Master, et nous l’avons mis en place après notre installation.

Toute la configuration que nous avons mise en place pendant notre migration vers Puppet 3 a clairement payé pour la migration de Puppet 4, car tout était déjà en place pour automatiser les tests. Comme le changement principal dans Puppet 4 était le passage au futur parser, nous avons pu intégrer les tests tôt en utilisant Puppet 3 avec le futur parser dans la matrice de test. Mais ce qui nous a vraiment aidés dans cette migration de syntaxe, c’est le développement des plugins puppet-lint pour automatiser la détection et la correction des dépréciations de syntaxe dans Puppet 4. Nous avons pu les exécuter non seulement sur nos modules publics mais aussi sur notre base de code privée, et rapidement préparer notre code pour Puppet 4.

Lors de la sortie de Puppet 4, les paquets AIO et les changements dans les configurations nous ont incités à essayer une nouvelle façon de déployer la stack Puppet. À ce moment-là, nous avions décidé que nous préférions classer les noeuds à l’aide de code plutôt que d’utiliser une base de données, donc nous étions prêts à remplacer Foreman pour Puppetboard. Nous avons commencé à construire une stack Puppet sur Docker, et après quelques mois nous l’avons déplacée sur Rancher.

Puppetboard est un moyen facile de consulter et d’interroger les informations de la PuppetDB.

Comme de plus en plus de nos applications internes passent à Docker (Rancher et Openshift), il est devenu de plus en plus important de nettoyer le code Puppet inutilisé. À cette fin, nous avons développé puppet-ghostbuster, un outil qui utilise la PuppetDB pour trouver les classes, définitions, modèles et fichiers de Puppet inutilisés. Cela nous a aidé à nettoyer beaucoup de code. Nous avons également fait don de plusieurs modules à Voxpupuli pour être maintenus par la communauté (y compris le module puppetserver et les plugins Puppet 4 Puppet-lint).

Aujourd’hui, nous sommes vraiment satisfaits de cette installation Puppet dockérisée, et nous sommes en train de migrer notre infrastructure vers une stack Puppet 5 basée sur Openshift.

Participation communautaire

Camptocamp est impliqué dans la communauté Puppet depuis les débuts de l’outil.

En 2012, nous avons co-organisé un Puppetcamp à Genève où nous avons présenté les projets Augeas et Augeasproviders. Depuis, nous avons participé à de nombreuses autres conférences comme Puppetconf en 2014 et à la plupart des conférences du cfgmgmtcamp.

Nous participons activement à divers projets dans l’écosystème Puppet, dont Augeas, MCollective, Puppetboard, Beaker, rspec-puppet, puppet-lint ou Modulesync.

Partenariats & services

Camptocamp est devenu Partenaire Puppet en 2013 et notre équipe a depuis lors enseigné des dizaines de sessions officielles de formation Puppet dans toute l’Europe.

En 2018, Camptocamp est un partenaire Gold de Puppet Inc. en Suisse, France et Allemagne.


Que vous commenciez tout juste à utiliser Puppet ou que vous ayez besoin de conseils, de formation ou de perfectionnement, notre équipe se fera un plaisir de mettre son expérience au service de votre projet.

  1. *
  2. *
  3. *
  4. *