1. Puppet - Implementing Modules
Von der Planung bis zur Umsetzung
Alexander Pacnik
Karlsruhe, 26.05.2014

2. 2
Typische Probleme
‣ Falsches Verständnis von Standard
‣ Betriebsysteme erstellen Konfigurationen, die möglichst für alle Anwender
funktionieren sollen – aber: schon zwischen Distributionen gibt es erhebliche
Unterschiede
‣ Over Engineering
‣ Versuch alle möglichen Fälle von Anfang an zu berücksichtigen und im Code
abzubilden
Einleitung
... worum es in diesem Vortrag geht

3. 3
Resultierende Entwicklungsansätze
‣ Direkt mit der Implementierung starten und sich am OS orientieren
‣ Vorteil: am Anfang schnelles vorankommen
‣ Nachteil: häufiges Neuschreiben großer Teile des Codes
‣ Generalisierung
‣ Vorteil: vermeintlich Infrastructure as Code und hohe Testabdeckung
‣ Nachteil: Fokussierung auf Deployment Code statt auf Konfiguration,
Umsetzungs- und Entwicklungsaufwände nicht angemessen
Einleitung
... worum es in diesem Vortrag geht

4. 4
Alternativer Lösungsansatz
‣ Vorher eigene Standards definieren (setzt Papier und Stift voraus)
‣ Analyse, Design und Umsetzung der eigenen Module gemäß diesen Standards
‣ Vorteile
‣ Schnell in der Entwicklung und Anwendung
‣ Einfacher und wenig Code
Einleitung
... worum es in diesem Vortrag geht

5. Standards
festlegen
5
Standards festlegen
... Papier und Stift bitte
Möglichkeiten
Problem-
analyse
Umsetzungs-
beispiel

6. 6
Problem 1
‣ Wie will ich Probleme lösen?
Standards festlegen
... aber wie?

7. 7
Standards
‣ Betriebssystem Standard: Weg der möglichst für alle Nutzer funktioniert, also der
kleinste gemeinsame Nenner
‣ Projekt Standard: Möglichst minimales Regelwerk das die Art und Weise
beschreibt, wie ihr Probleme in eurem Team für euren Kunden umsetzen wollt
‣ Empfehlung: an allgemeinen Standards orientieren, aber abweichen wo es
keinen Sinn macht
Standards festlegen
... Was ist Standard?

8. 8
Tools und Aufgaben festlegen
‣ Aufgaben (Image Verwaltung, Paketbau, Configuration, Deployment, Operations)
‣ Pro Aufgabe überlegen wer es später benutzen soll (Dev/Ops/...)
‣ Pro Aufgabe überlegen in welchen Umgebungen es benötigt wird
‣ Pro Aufgabe genau ein Tool und die Struktur definieren
‣ Beispiel:
Standards festlegen
... Aufgaben und Tools festlegen

9. 9
Was gehört zum Deployment einer Applikation (Context)?
‣ Applikation (Paket oder Verzeichnis)
‣ Konfiguration (teilweise in der Applikation, teilweise auf dem System – z.B. vhost)
‣ Daten (Laufzeitdaten, beispielsweise Sessions)
Was gehört zur Konfiguration des Systems?
‣ Binaries (Programme, idR über Pakete)
‣ Konfiguration (beispielsweise unter /etc/)
‣ Daten (Laufzeitdaten, beispielsweise logs)
Standards festlegen
... Configuration vs. Deployment

10. 10
Problem
‣ Systempakete enthalten oft System und Context spezifische Daten um den Start
mit den Diensten einfach zu machen (kleinster gemeinsamer Nenner)
Lösungsansatz
‣ Alles systemspezifische wird über Puppet Component Module abgebildet
‣ Alles applikationsspezifische wird über Puppet Profile oder das Deployment
abgebildet (je nach Verantwortung – PaaS vs. full stack)
Standards festlegen
... Configuration vs. Deployment

11. 11
Standards festlegen
... C/P/M Pattern als Abstraktionsebene

12. 12
Wiederholung Struktur
‣ Component Module
‣ Atomare Module die die Konfiguration des Systems enthalten (z.B. httpd)
‣ Modulspezifische Daten zusammen mit dem Modulcode (params.pp)
‣ Profile
‣ Technologische Klammer für unsere Module (z.B. profile_web_httpd_php)
‣ Umgebungsspezifische Daten, also Daten die sich in den Umgebungen
unterscheiden (und nur diese) werden über Hiera geladen (z.B. Memory)
‣ Optional: applikationsspezifische Spezialisierungen der Profile (z.B.
profile_web_httpd_wordpress) statt Deployment
Standards festlegen
... C/P/M Pattern als Abstraktionsebene

13. 13
Wiederholung Regeln
‣ Keine Abhängigkeiten zwischen Modulen (mod_php Teil vom httpd Modul)
‣ Keine Vererbung (Inheritance), ähnliche Profile sind neue Profile
‣ Module sollten über Parameter gesteuert werden (API)
‣ Profile und Rollen haben keine Parameter
Standards festlegen
... C/P/M Pattern als Abstraktionsebene

14. Standards
festlegen
14
Problemanalyse und Design
... Papier und Stift bitte
Möglichkeiten
Problem-
analyse
Umsetzungs-
beispiel

15. 15
Problem 2
‣ Was will ich installieren?
‣ Was kann / muss ich konfigurieren?
Problemanalyse und Design
... Papier und Stift bitte

16. * Am Beispiel CentOS mit Apache Httpd und PHP 16
Pakete und Abhängigkeiten analysieren
‣ Pakete und Abhängigkeiten finden: repoquery --requires [--resolve] php
‣ Interessante Dateien finden: repoquery --lq <Pakete>
‣ Relevanten Dateien (Skripte, Konfigurationsdateien) in eine Mindmap schreiben
Problemanalyse und Design
... was muss ich verwalten?

17. * Am Beispiel CentOS mit Apache Httpd und PHP
17
Konfigurations-Parameter bestimmen
‣ Hinter alle Dateien in der Mindmap schreiben was mit ihnen geschehen soll,
dazu den Inhalt aller relevanten Dateien durcharbeiten
‣ Ggf. aufteilen (httpd.conf -> httpd.conf und modules.conf)
Problemanalyse und Design
... was muss ich verwalten?

18. 18
Zielstruktur definieren
‣ Zweite Mindmap mit der Zielstruktur erstellen
‣ Beide Mindmaps mit dem Team / Anforderungsstellern abstimmen
Problemanalyse und Design
... wie soll es aussehen?

19. 19
Umsetzung in die Mindmap einzeichnen
‣ Hinter alle Datei schreiben wo und wie sie umgesetzt werden sollen
‣ Dateien die man 1:1 bei beibehalten will als file / template im Modul kopieren
‣ In die Zielstruktur Mindmap
Problemanalyse und Design
... um die Übersicht zu behalten

20. 20
Profile Beispiel: profile_web_apache_gitblit
‣ Aufruf des Basismoduls welches den Dienst installiert und das System konfiguriert
‣ Templates als Teil der Applikation nicht über das Deployment sonderen ein
applikationsspezifisches Profil verwaltet
‣ Loadmodule, Logging, etc. sind im vhost definiert
Möglichkeiten bei der Umsetzung
... um die Übersicht zu behalten

21. Standards
festlegen
21
Möglichkeiten bei der Umsetzung
... Papier und Stift bitte
Möglichkeiten
Problem-
analyse
Umsetzungs-
beispiel

22. 22
Problem 3
‣ Wie umsetzen?
Möglichkeiten bei der Umsetzung
... welche technischen Möglichkeiten gibt es?

23. 23
Class vs. Define
‣ Class: Ressourcen können nur einmal pro Node angewendet werden
‣ Define: Ressourcen können mehrfach angewendet werden, wenn sie eindeutig
sind
Möglichkeiten bei der Umsetzung
... um die Übersicht zu behalten

24. 24
Beispiel: for each
‣ Aufruf
‣ Define
Möglichkeiten bei der Umsetzung
... um die Übersicht zu behalten

25. 25
1. Template mit Parametern
‣ jegliche Konfiguration wird über Parameter übergeben und validiert
‣ Vorteil: Validierung der Parameter, Tests mit rspec
‣ Nachteil: ab 10-15 Parameter hohe Komplexität und unübersichtlich
‣ Empfehlung: bei wenigen Parametern auf Modulebene
Möglichkeiten bei der Umsetzung
... Möglichkeiten Parameter von Profil an das Modul zu übergeben

26. 26
2. Template mit Parametern und Hash
‣ die wichtigsten 10-15 Konfigurationen werden über Parameter übergeben, alle
weiteren über einen Hash
‣ Vorteil: es wird weiterhin eine API verwendet und die Anzahl der Parameter
sowie die Templates bleiben überschaubar
‣ Nachteil: Inhalt eines Hash ist schwieriger zu validieren bzw. zu testen
‣ Empfehlung: bei optionalen Parametern auf Modulebene
Möglichkeiten bei der Umsetzung
... Möglichkeiten Parameter von Profil an das Modul zu übergeben

27. 27
3. Konfigurationsdateien
‣ hier wird von einem Modul lediglich eine Konfigurationsdatei ausgeliefert, die vom
aufrufenden Modul überschrieben werden kann
‣ Vorteil: einfach und schnell
‣ Nachteil: keine Validierung durch Parameter und das Überschreiben ist nicht in
der init.pp ersichtlich
‣ Empfehlung: nur im Notfall verwenden, besser Modules und Profiles Pattern
Möglichkeiten bei der Umsetzung
... Möglichkeiten Parameter von Profil an das Modul zu übergeben

28. 28
Entscheidungskriterien für die Umsetzung
‣ Nur parametrisieren was für den aktuellen Fall benötigt wird
‣ Beispiel: bei einem Betriebssystem ist die params.pp oft nicht notwendig
‣ Wie viele Konfigurationen ändern sich bei der Verwendung des Moduls? Zur
Orientierung:
‣ 10-15: als Parameter auf Modulebene (httpd.conf)
‣ >15 aber optional: als Hash wenn möglich auf Modulebene (modules.conf)
‣ >15 aber mandatory: als Datei / Template auf Profil ebene (vhost.conf)
Problemanalyse und Design
... um die Übersicht zu behalten

29. Standards
festlegen
29
Entscheidungen im Vorfeld
... Papier und Stift bitte
Möglichkeiten
Problem-
analyse
Umsetzungs-
beispiel

30. 30
Demo
Beispiel
... der Code

31. 31
Fazit
‣ Bei wenig Erfahrung oder komplexen Modulen empfiehlt es sich die beiden
Mindmaps tatsächlich in schriftlicher Form zu verfassen
‣ Iteratives Vorgehen heißt mit (nur) den Informationen zu arbeiten die man aktuell
hat. Für Erweiterungen planen, aber noch nicht implementieren (!)
‣ Die Module und deren Weiterentwicklung dürfen den Betrieb aber nicht bremsen,
sonst müssen ihn schneller machen.
Parameter
... um die Übersicht zu behalten

32. 32
Take-Away
‣ Der Fokus sollte auf der Konfiguration der Systeme und nicht auf dem Code zur
Konfiguration liegen.
‣ Code muss kurz und selbsterklärend sein
Take-Away

33. 33
Vielen Dank für Ihre Aufmerksamkeit
Kontakt
Alexander Pacnik
IT Engineering & Operations
Project Management
inovex GmbH
Ludwig-Erhard-Allee 6
76133 Karlsruhe
Mobil: +49 (0)173 3181 040
Mail: alexander.pacnik@inovex.de

34. Anhang

35. 35
Quellen
‣ Puppet Style Guide
http://docs.puppetlabs.com/guides/style_guide.html
‣ Puppet Language Guide
http://docs.puppetlabs.com/guides/language_guide.html
‣ Puppet Referenzen
http://docs.puppetlabs.com/references/latest/
‣ Puppet Guides
http://docs.puppetlabs.com/guides/
‣ Puppet Blog
https://puppetlabs.com/blog/
Lizenz des Vortrags
‣ Creative Commons (by-nc-nd)
Anhang
... wo sie in Ruhe nachlesen können