Camptocamp – News

10 Jahre Puppet!

22 Februar 2018

Im Jahr 2015 feierte, Puppet  sein 10-jähriges Jubiläum.

Für uns bei Camptocamp hat dieses Open-Source Software-Konfigurationsmanagement-Tool unsere Art der Systemadministration völlig revolutioniert. Seit 2007 arbeiten wir mit Puppet, aber 2018 ist ein besonderer Meilenstein für uns, da unsere vier Puppet git control repositories alle Anfang 2008 entstanden sind!

Deswegen ist es an der Zeit, einen Rückblick auf 10 Jahre Puppentraining bei Camptocamp zu werfen – Vor allem auf das was wir probiert und was wir dazu gelernt haben.

puppet

Kontroll-Repositories

Sehen wir uns zunächst unsere Kontroll-Repositories an. Wir verwenden vier von ihnen, um vier verschiedene Puppet-Infrastrukturen (unseren eigenen und die von drei Hauptkunden) zu verwalten. Sie sind alle getrennte Git Repositories und sie teilen Module.

Camptocamp control repository

Codezeilen aufgeteilt nach Autor in Camptocamp’s eigenem Kontroll-Repository

EPFL control repository

Codezeilen aufgeteilt nach Autor in dem Kontroll- Repository von Kunde A

In jedem Repository richten wir lokale Module (nicht geteilt) ein, die sich in einem Site-Modules-Verzeichnis befinden, damit sie nicht mit den von r10k gezogenen freigegebenen Modulen verwechselt werden.

Repository-Verwaltung

Bevor wir Anfang 2015 zu r10k wechselten, haben wir git subtree verwendet, um Module in den Repositories zu verwalten. Wir hatten eine Crontab mit einem Skript (githubsync), das dafür verantwortlich war, jeden Abend Modul-Repositories in den Kontroll-Repositories zu ziehen. Wir könnten diese Änderungen auch manuell mit git subtree ziehen. Die Lösung war recht flexibel, wenn auch recht fehleranfällig und schwer zu warten (oft mussten fehlerhafte automatische Zusammenführungen wieder behoben werden).

Das Verwalten von Puppet-Modulen mit git subtree führt zu einer komplexen Historie

Der Wechsel zu r10k im Jahr 2015 hat unsere Codebasis halbiert, indem wir die freigegebenen Module aus den Kontroll-Repositories entfernt haben.

Codezeilen in Camptocamp‘s eigenem Kontroll-Repository

In der Vergangenheit haben wir zwei Hauptzweige in unseren Repositories verwendet: stable und staging. Der stable Zweig wird von produktionskritischen Maschinen verwendet, während auf dem Staging-Zweig weniger kritischen Knoten verwendet werden. Neue Funktionen werden zunächst dem Staging-Zweig hinzugefügt, indem sie einige Tage bestehen, bevor sie in den Stable-Zweig integriert werden.

Seit 2015 hilft uns der Puppet Catalog Diff Viewer dabei, Veränderungen zwischen den beiden Branchen zu visualisieren, bevor wir uns für eine Zusammenführung entscheiden.

Der Puppet Catalog Diff Viewer hilft beim Vergleich von Puppet-Umgebungen

Testen

Als unsere Codebasis wuchs und wir begannen, unsere Module auf der Puppet Forge zu verteilen, wurde es notwendig, eine gute Basis für das Testen unseres Codes zu schaffen. Im Laufe des Jahres 2013 hatten wir die meisten unserer Module getestet und an Travis CI angeschlossen, um unsere Module automatisch testen zu lassen.

Um Akzeptanztests für unsere öffentlichen Module hinzuzufügen, haben wir damit begonnern, VMs in unserer internen OpenStack-Cloud mithilfe von ‚Beaker‘ dynamisch bereitzustellen um dann auf die Verwendung von Docker-Containern umzustellen, sobald die der Travis CI Umgebungen verfügbar waren.

Die Erfahrung, Tests für unsere Module durchzuführen, führte 2015 zu einer Reihe von Blog-Posts über Puppet Test Driven Development. Wir wendeten diese Methode nicht nur auf öffentliche Module, sondern auch auf unsere internen Module an.

Module

Wenn es eine Sache gibt, für die Camptocamp in der Puppet-Community berühmt geworden ist, sind es die Module. Während wir ungefähr einhundert von ihnen auf GitHub unterhalten, haben wir ungefähr diewe have published roughly Hälfte von ihnen auf der Forge veröffentlicht, von denen einige zugelassene Module sind.

Camptoamp-Module auf der Puppet Forge. Die Grösse ist relativ zur Anzahl der Downloads, Octocat zu den Mitwirkenden und Tag zu Freigaben, grüne Module sind genehmigt.

Darüber hinaus pflegen die Mitglieder unseres Teams die Module von Augeasproviders und tragen zu den Bemühungen derVoxpupuli-Gemeinschaft bei.

Voxi (das Voxpupuli-Puppet Community- Maskottchen) auf dem Weg zu Camptocamp

Stack Geschichte

Im Laufe der Jahre hat sich unser Puppet Architektur stark verändert.

Wie die meisten Erstanwender begannen wir mit einem Puppet Master, der auf Mongrel lief, welcher ziemlich langsam war. Danach haben wir Apache mit mod_passenger benutzt. Die Veröffentlichung von Thin als Ersatz für Mongrel war für uns eine gute Gelegenheit, Apache abzulösen und Thin-basierte Puppet Master hinter einem Nginx-Proxy einzurichten. Zu diesem Zeitpunkt wurde der Nginx-Proxy als SSL-Endpunkt verwendet und konnte abhängig von den Anforderungen der Umgebung an bestimmte Puppet Master weiterleiten. Wir hatten in der Regel eine Basismaschine für Produktionsumgebungen (stable und staging) und eine größere für Tests (Features + Benutzer). Dies erlaubte reaktive Läufe, wenn Menschen beteiligt waren.

Als Puppet 2.6 2010 veröffentlicht wurde, war unser Code aufgrund vieler Inkompatibilitäten noch nicht für die Migration bereit. So haben wir 2012 direkt von 0.25 auf 2.7 migriert, nachdem wir Jenkins ausführlich mit Katalog-Diffs getestet hatten.

Im Jahr 2013 übernahmen wir Foreman, vor allem um den Zustand unserer Flotte visualisieren zu können. Bis dahin hatten wir Puppet-Reports nur auf Festplatten gespeichert und Berichte als Benachrichtigungen auf einem IRC-Kanal verschickt. Foreman gab uns großartige Einblicke auf unsere Plattform.

Foreman ist eine großartige Möglichkeit, eine Puppet-gesteuerte Flotte zu überwachen

Wir haben einen guten Teil des Jahres 2013 damit verbracht, unsere Module auf Puppet 3 zu migrieren. Dies war eine sehr komplexe Aufgabe, da viele unserer Module, historisch bedingt, das dynamische Scoping (das in Puppet 3 veraltet war) ohne Klassenparameter verwendeten (wir hatten die Klassenvererbung in Puppet 0.2x ausgiebig genutzt, um das auszugleichen). Diese Portierung wurde von einer Menge Arbeit an Tests (sowohl Einheit als auch Akzeptanz) und CI / CD begleitet. Der Wechsel von Puppet 2.7 auf 3 erfolgte Anfang 2014.

Es war eine wichtige Aufgabe dutzende von Modulen zu warten. Wir haben im Sommer 2014 begonnen, modulesync zu verwenden, um diese Aufgabe zu erleichtern und um es im Dezember zur Synchronisierung unserer Steuerungsrepositories übernehmen zu können. Seitdem pflegen wir unsere Puppetfiles mit modulesync, verwenden ein statisches Puppetfile als Vorlage und Augeas um Einträge pro Kontroll-Repository zu löschen. Wir haben auch puppetfile-updater entwickelt, um die Pflege unserer Referenz-Puppetfiles zu erleichtern.

Ende 2014 wurde der Puppetserver (Puppet Master unter JVM) veröffentlicht. Wir haben diesen schnell übernommen, da die Leistung für uns immer ein Problem darstellte, die wir mit Hilfe des Puppet Masters verbessern konnten.

Das gesamte Setup, das wir während unserer Migration zu Puppet 3 zusammengestellt haben, hat sich für die Migration von Puppet 4 bezahlt gemacht, da bereits alles vorhanden war, um das Testen zu automatisieren. Da die Hauptänderung in Puppet 4 der Wechsel zum future Parser war, konnten wir Tests bereits zuvor mit Puppet 3 mit dem future Parser in die Testmatrix integrieren. Was uns aber bei dieser Migration wirklich geholfen hat, war die Entwicklung vonpuppet-lint Plugins, um die statische Analyse vom Quellcode in Puppet 4 zu automatisieren. Wir konnten diese nicht nur auf unseren öffentlichen Modulen, sondern auch auf unserer privaten Codebasis ausführen. Unseren Code für Puppet 4 wurde so schnell bereitgestellen.

Als Puppet 4 veröffentlicht wurde, ermutigten uns die AIO-Pakete (All In One) und die Änderungen der Konfigurationspfade, einen neuen Weg zu finden, den Puppet-Stack zu implementieren. Zu diesem Zeitpunkt entschieden wir uns, es vorzuziehen, Knoten im Code zu klassifizieren, anstatt eine Datenbank zu verwenden, sodass wir bereit waren, von Foreman auf Puppetboard zu wechseln. Wir haben angefangen, einen Puppet Stack auf Docker zu bauen, und nach ein paar Monaten haben wir ihn nach Rancher verlegt.

Puppetboard ist eine einfache Möglichkeit, Informationen aus der PuppetDB einzusehen und abzufragen

Da immer mehr unserer internen Anwendungen auf Docker (Rancher und Openshift) laufen, ist es immer wichtiger geworden, unbenutzten Puppet-Code zu bereinigen. Zu diesem Zweck haben wir puppet-ghostbuster ntwickelt, ein Tool, das mithilfe der PuppetDB unbenutzte Puppet-Klassen, Defines, Templates und Dateien findet. Dies hat uns geholfen, viel Code aufzuräumen. Außerdem haben wir Voxpupuli mehrere Module für die Wartung der Community gespendet (einschließlich des Puppetserver-Moduls und der puppet-lint Plugin von Puppet 4).

Heute sind wir sehr zufrieden mit dieser Dockerized Puppet Umgebung und migrieren unsere Infrastruktur auf eine Puppet 5 Umgebung basierend auf Openshift.

Gesellschaftliches Engagement

Camptocamp ist seit den Anfängen des Tools in der Puppet-Community involviert.

Im Jahr 2012 waren wir Co-Organisator eines Puppetcamps in Genf, bei dem wir die Projekte Augeas und Augeasproviders vorgestellt habenSeitdem haben wir uns auf vielen anderen Konferenzen wie die Puppetconf 2014 und den meisten cfgmgmtcamp Events beteiligt.

Wir beteiligen uns aktiv an verschiedenen Projekten im Puppet-Ökosystem, darunter Augeas, MCollective, Puppetboard, Beaker, rspec-puppet, puppet-lint oder Modulesync.

Partnerschaften und Dienstleistungen

Camptocamp ist seit den Anfängen des Tools in der Puppet-Community involviert.

Seit 2018 hält Camptocamp den Gold-Partner Status von Puppet Inc. für die Schweiz, Frankreich und Deutschland.


Egal, ob Sie gerade erst mit Puppet beginnen oder eine fortgeschrittene Beratung, Schulung oder Entwicklung benötigen, unser Team ist gerne bereit, unsere Erfahrung in Ihr Projekt einzubringen.

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