Puppet: Designing modules & repositories Alexander Pacnik, LinuxTag Berlin, 08.05.2014

1. Linux Tag 2014 - Puppet
Designing Moduls and Repositories
Alexander Pacnik
Karlsruhe, 08.05.2014

2. 2
Der Schlüssel zum Erfolg ist die Kultur, nicht das Werkzeug
‣ Infrastructure as Code – der gleiche Code für alle Umgebungen (Transparenz)
‣ Continuous Delivery – Ergebnis und die Prozesse in den Mittelpunkt stellen
‣ Infrastructure Testing – die Basis jeglicher Automatisierung und Wartbarkeit
Einleitung
... worum es in diesem Vortrag geht

3. 3
Problemstellung: Unterschiedliche Anforderungen
‣ Anforderungen Betrieb (beispielsweise verschiedene Umgebungen)
‣ Anforderungen Entwicklung (beispielsweise schnelles Deployment)
‣ Anforderungen QA (beispielsweise Testbarkeit)
‣ Ziel: Flexibilität
Einleitung
... worum es in diesem Vortrag geht

4. Designing
Puppet
4
Entscheidungen im Vorfeld
... Papier und Stift bitte
Designing
Repositories
and
Environments
Designing
Modules
Getting
started

5. 5
Ziele
‣ Anforderungsanalyse
‣ Entscheidung explizit treffen, wie Puppet verwendet werden soll
Designing Puppet
... Papier und Stift bitte

6. 6
Was (soll mit Puppet verwaltet werden)?
‣ Deploymentgrenzen anhand der Verantwortung definieren
‣ Betriebssystem
‣ Wie wird die Benutzerverwaltung umgesetzt
‣ Was wird über Pakete installiert und wie bzw. wo werden sie gebaut
(keine Binaries über Puppet verteilen!)
‣ Paketversionen über Puppet oder Paketrepository (empfohlen)
sicherstellen
‣ Deployment der Stacks (Packages, Configuration, Service)
‣ Deployment der Applikation (Binaries, Configuration, SQL)
‣ Beispiel:
‣ PaaS Ansatz: Cron Jobs, php.ini etc. nur initial mit Puppet verwaltet, dann
über das Applikations-Deployment
Designing Puppet
... Papier und Stift bitte

7. 7
Wo (soll Puppet verwendet werden)?
‣ Umgebungen definieren
‣ Production, Stage, Test
‣ Vagrant, Docker
Designing Puppet
... Papier und Stift bitte

8. 8
Wer (wird Puppet verwenden)?
‣ Alle Puppet Nutzer von Anfang an beteiligen
‣ System Engineers
‣ Entwickler
Designing Puppet
... Papier und Stift bitte

9. 9
Wie (soll Puppet verwendet werden)?
‣ run mode festlegen (Ansatz wählen)
‣ Agent (State verwalten - empfohlen)
‣ Pro: Zustand eindeutig, Reports
‣ Contra: Infrastruktur notwendig
‣ Apply (Adhoc Verwaltung)
‣ Pro: einfach, über OS Pakete möglich
‣ Contra: keine Reports, nur einmalige Anwendung
‣ Pets (manuelle pflege) vs Cattle (Wegwerfware)
‣ Alle Workflows skizzieren, in denen Puppet vorkommt
‣ Puppet Entwicklung (Vagrant, Test, ...)
‣ Anwendungsentwicklung (Vagrant)
Designing Puppet
... Papier und Stift bitte

10. Designing
Puppet
10
Modulentwicklung
... Worauf es wirklich ankommt
Designing
Repositories
and
Environments
Designing
Modules
Getting
started

11. 11
Problem 1
‣ Geringe Wiederverwendbarkeit von Puppet Code
‣ Hohe Komplexität des Puppet Codes
‣ häufige if-Statements
‣ Code Duplication
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

12. 12
Component Module - Eigenschaften
‣ Unabhängig, atomar und kann jederzeit mit anderen geteilt werden
‣ Abhängigkeiten zu anderen Modulen um jeden Preis vermeiden
‣ Optionen werden über Parameter übergeben und alle Parameter werden validiert
‣ keine organisationsspezifischen oder umgebungsspezifischen Inhalte
‣ Namenskonvention: nach der Funktion die sie erfüllen
Strukturierung der Module
... atomare Module für mehr Wiederverwendbarkeit

13. 13
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

14. 14
Problem 2
‣ Ressourcen in mehreren Modulen definiert
‣ Häufige Dependency Cycles
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

15. 15
Profile (früher Services)
‣ die Klammer auf technischer Ebene
‣ besteht aus Component Modulen (und optional Ressourcen)
‣ Ein ähnliches Profil ist ein neues Profil – keine generische Profile
‣ Namenskonvention: profile_<type>_<service>[_<specialisation>]
Strukturierung der Module
... die Abstraktion aus technischer Sicht

16. 16
Strukturierung der Module
... die erste Abstraktionsebene

17. 17
Problem 3
‣ Ein technisches „Profil“ wird auf mehreren Nodes benötigt
‣ Technische Profile passen nicht zu den Business Anforderungen
‣ Logik auf Node-Ebene
‣ Unübersichtlich bei vielen Nodes
‣ Problematisch, wenn man eine ENC verwenden will
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

18. 18
Roles
‣ Abstraktionsebene aus Business-Sicht, also für was ein System steht
‣ es werden ausschließlich ein oder mehrere includes von Profilen verwendet
‣ Namenskonvention: role_<function>
Strukturierung der Module
... die Abstraktion aus Business Sicht

19. 19
Strukturierung der Module
... die zweite Abstraktionsebene

20. 20
Problem 4
‣ Wo definiere ich, was aus meinen Servern bzw. Nodes wird?
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

21. 21
Möglichkeiten
‣ ENC - empfohlen (The Foreman)
‣ Vorteile: zentral verwaltet
‣ Nachteile: keine Versionierung
‣ site.pp – im Puppet Code
‣ Vorteile: Versionierung, kann auch ohne ENC verwendet werden
‣ Nachteile: kann bei vielen Nodes unübersichtlich werden
‣ facts.d (system_role) – auf dem System
‣ Vorteile: einfach, nur ein default node
‣ Nachteile: theoretisch kann jeder Node alle Rollen annehmen
Empfehlung
‣ Nur Classification wenn möglich (Node = Classifier only)
‣ Ein Node hat eine Rolle (wenn mehrere nötig sind, eine neue Rolle schaffen)
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

22. 22
Strukturierung der Module
... die dritte Abstraktionsebene

23. 23
Zusammenfassung
‣ Sind Profile und Rollen notwendig?
‣ Nein, aber man verliert die Möglichkeit der Abstraktion
‣ Können Profile und Rollen auch im ENC definiert werden?
‣ Ja, aber man verliert die Versionierbarkeit und die Verwendung ohne ENC -
beispielsweise mit Vagrant
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

24. 24
Fazit
‣ Vorteile: Abstraktion und Entkopplung von Logik und Implementierung
‣ Nachteile:
‣ kann unübersichtlich werden, Disziplin
‣ kann kompliziert werden, wenn nicht ein Service = eine VM
(Konventionen notwendig)
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht

25. 25
Problem 5
‣ Viele if-Statements, um umgebungsspezifische Unterschiede abzufangen
‣ Unterschiedlicher Branch bzw. Klassen und Module für Umgebungen
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht

26. 26
Möglichkeiten
‣ params.pp
‣ Vorteile: Logik genau in einer Klasse, einfach, versionierbar
‣ Nachteile: Business Logik im Modul, Daten noch im Modul
‣ Hiera Function
‣ Vorteile: Daten an einer Stelle, Default-Werte möglich
‣ Nachteile: auch die modulspezifischen Daten in Hiera
‣ Params.pp und Hiera Function
‣ Vorteile: Daten in Hiera, Default-Werte in params.pp
‣ Nachteile: Debugging schwieriger (woher kam der Wert?)
‣ Data Binding
‣ Vorteile: Parameter wird automatisch in Hiera nachgeschaut
‣ Nachteile: Lookup ist nicht explizit
Trennung von Daten und Code
... Vor- und Nachteile der verschiedenen Möglichkeiten

27. 27
Empfehlung für die Verwendung mit Rollen
‣ Betriebssystemspezifische oder modulspezifische Daten in params.pp
(solange „Data in Modules“ noch nicht im Puppet Core)
‣ Alle umgebungsspezifischen Daten kommen aus Hiera
‣ Hiera Lookups sind explizit und werden validiert (stdlib)
‣ Hiera Lookups haben keine Default Werte („fail fast“ Prinzip)
Trennung von Daten und Code
... params.pp für Module, Hiera für Profile

28. 28
Trennung von Daten und Code
... die vierte Abstraktionsebene

29. Vgl. Vortrag vom Linuxtag 2013 29
Empfehlung für den Speicherort von Daten
‣ So nah wie möglich am Code (Lesbarkeit)
‣ So weit entfernt wie nötig (Abstraktion)
Vorteile von Hiera
‣ Änderungen möglich, ohne den Puppet Code zu verändern
‣ Verschiedene Backends verfügbar
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht

30. https://github.com/TomPoulton/hiera-eyaml 30
Problem 6
‣ Wie mit sensitive Daten wie Passwörter umgehen?
‣ hieradata/ in ein eigenes Repository
‣ Strings in Hiera verschlüsseln (beispielsweise mit hiera-eyaml)
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht

31. 31
Konfiguration
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht

32. 32
Verzeichnisstruktur
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht

33. 33
Problem 7
‣ Änderungen am Code sind zeitaufwändig
‣ Fehler werden erst in den Test-Umgebungen erkannt
‣ Code schwierig zu warten
Code testen
... testen für schnellere Entwicklung

34. 34
Test und Debugging
‣ Testen
‣ Syntax Checks (puppet–lint)
‣ Smoke Tests (funktionalen Prüfung des Moduls, rspec / serverspec)
‣ Performance Tests
‣ Debugging
‣ Puppet Graph
Code testen
... testen für schnellere Entwicklung

35. 35
Beispiel: Checks die lokal und auf dem Git bzw. CI System ausgeführt werden
Code testen
... testen für schnellere Entwicklung

36. 36
Beispiel: Checks, die auf dem Testsystem ausgeführt werden
Code testen
... testen für schnellere Entwicklung

37. 37
Beispiel: Graphen immer generieren
Code testen
... testen für schnellere Entwicklung

38. 38
Empfohlenes Vorgehen für das Testen
1. Lokal Syntax-Checks ausführen während der Entwicklung (Skript / $EDITOR)
2. Code auf das Entwicklungssystem synchronisieren (beispielsweise Vagrant)
3. tests/init.pp mit „puppet apply“ ausführen soweit möglich
(sinnvoll für Module, Rollen und Profile)
4. Performance-Report automatisch generieren und prüfen
5. Graphen automatisch generieren und prüfen
6. Commit / CI Tests
Code testen
... testen für schnellere Entwicklung

39. Designing
Puppet
39
Repositories und Environments
... Abhängigkeiten modellieren
Designing
Repositories
and
Environments
Designing
Modules
Getting
started

40. 40
Problem 8
‣ Ein Modul, das in vielen anderen Profilen oder Rollen verwendet wird, lässt sich
schwierig ändern
‣ Wie teste ich neue Modulversionen in verschiedenen Umgebungen?
Modulentwicklung entkoppeln
... Modularisierung und Versionierung zur Entkopplung

41. 41
Lösungsansätze für Repository zu Environment Mapping
1. Ein Repository pro Environment
‣ Vorteile: einfach
‣ Nachteile: Änderungen betreffen immer das ganze Repository
2. Ein Branch pro Environment
‣ Vorteil: Unterschiede zwischen Umgebungen und Versionen möglich
‣ Nachteile: Mergen, Änderungen betreffen immer das ganze Repository
3. Dynamic Environments und Feature-Branches
‣ Vorteile: man kann einzelne Änderungen auf einzelnen Hosts testen
‣ Nachteile: wie oben
4. Module in eigenen Repositories
‣ Vorteile: Änderungen auf Module beschränkt, einfache Integration externer
Module
‣ Nachteile: Module müssen auf dem Master „zusammengesetzt“ werden
Modulentwicklung entkoppeln
... Modularisierung und Versionierung zur Entkopplung

42. 42
Lösungsansätze für Repository zu Environment Mapping
1. Ein Repository pro Environment
‣ Vorteile: einfach
‣ Nachteile: Änderungen betreffen immer das ganze Repository
2. Ein Branch pro Environment
‣ Vorteil: Unterschiede zwischen Umgebungen Versionen möglich
‣ Nachteile: Mergen, Änderungen betreffen immer das ganze Repository
3. Dynamic Environments und Feature-Branches
‣ Vorteile: man kann einzelne Änderungen auf einzelnen Hosts testen
‣ Nachteile: wie oben
4. Module in eigenen Repositories
‣ Vorteile: Änderungen auf Module beschränkt, einfache Integration externer
Module
‣ Nachteile: Module müssen auf dem Master „zusammengesetzt“ werden
Modulentwicklung entkoppeln
... Modularisierung und Versionierung zur Entkopplung

43. 43
Modulentwicklung von der Version im Environment entkoppeln
‣ Jedes Modul wird versioniert in einem eigenen Git Repository entwickelt
‣ Optional: Hieradata pro Umgebung in eigenem Git Repository
‣ Beispiel: Minimale Struktur eines Environments mit Puppetfile
Modulentwicklung entkoppeln
... die fünfte Abstraktionsebene

44. 44
Abhängigkeiten und Versionen der Repositories werden im Puppetfile definiert
Empfehlung
‣ Nur Git verwenden (Historie) und Forge Module auf den eigenen Git Server
spiegeln
Modulentwicklung entkoppeln
... das Puppetfile

45. 45
Environment nach dem „Aufbauen“ auf dem Puppet Master
Modulentwicklung entkoppeln
... die fünfte Abstraktionsebene

46. https://github.com/rodjek/librarian-puppet 46
Repositories mit librarian-puppet verwalten
‣ Syntax
Environments aufbauen
... Möglichkeit eins - librarian-puppet

47. https://github.com/adrienthebo/r10k 47
r10k
‣ Konfiguration
‣ r10k.yaml
Environments aufbauen
... Möglichkeit zwei – r10k

48. 48
Empfehlung für den Aufbau von Git Repositories
‣ Kleinste sinnvolle Einheit wählen (Module, Environment, Hieradata)
‣ Vorteil: einfache Versionierung, mehrere Versionsstände möglich
‣ Nachteil: Übersichtlichkeit leidet
Empfehlung für den Aufbau von Puppet Environments
‣ Environment: produktzentrierten Ansatz bzw. Umgebungen anhand von
Deploymentgrenzen / Aufgaben wählen
‣ Vorteil: Änderungen haben kleinere Auswirkungen und sind einfacher
‣ Nachteil: Gefahr der Zersplitterung
Environments und Repositories
... die Empfehlung

49. Designing
Puppet
49
Dia Agenda
... worum es in diesem Vortrag geht
Designing
Repositories
and
Environments
Designing
Modules
Getting
started

50. 50
Empfehlung für das Vorgehen
1. Design bzw. Konventionen schriftlich festlegen
2. Modul-Skeleton erstellen
3. Entwicklungs- und Deployment-Workflow mit allen Beteiligten testen
4. Module, Profile, Rollen und Umgebungen entwickeln
Parameter
... um die Übersicht zu behalten

51. 51
Empfehlung für den Anfang
‣ im Zweifel mit dem einfachsten möglichen Weg beginnen
‣ iteratives Vorgehen: im zweiten Schritt versuchen zu abstrahieren / optimieren
‣ generisch vs. speziell, Skills und Zeit beachten
Parameter
... um die Übersicht zu behalten

52. 52
Fazit
‣ Puppet-Entwicklung = Software-Entwicklung
‣ Eine DSL ist keine Programmiersprache
‣ Puppet ersetzt nicht die Build-Umgebung
‣ Puppet ersetzt keine adhoc Verwaltung, falls diese notwendig ist
‣ Es wird komplexer = die einfachste Lösung ist meistens falsch
‣ Abstraktion auf allen Ebenen hilft
‣ Engineering als Dienstleister für andere Abteilungen - kein Selbstzweck
Fazit
... takeaways

53. 53
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

54. Anhang

55. 55
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