Puppet: Designing modules & repositories

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

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
Problemstellung: Unterschiedliche Anforderungen
‣  Anforderungen Betrieb (beispielsweise verschiedene Umgebungen)
‣  Anforderungen Entwicklung (beispielsweise schnelles Deployment)
‣  Anforderungen QA (beispielsweise Testbarkeit)
‣  Ziel: Flexibilität
Einleitung

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

5
Ziele
‣  Anforderungsanalyse
‣  Entscheidung explizit treffen, wie Puppet verwendet werden soll
Designing Puppet

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

7
Wo (soll Puppet verwendet werden)?
‣  Umgebungen definieren
‣  Production, Stage, Test
‣  Vagrant, Docker
Designing Puppet

8
Wer (wird Puppet verwenden)?
‣  Alle Puppet Nutzer von Anfang an beteiligen
‣  System Engineers
‣  Entwickler
Designing Puppet

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

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

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
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
... atomare Module für mehr Wiederverwendbarkeit

13

14
Problem 2
‣  Ressourcen in mehreren Modulen definiert
‣  Häufige Dependency Cycles

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>]
... die Abstraktion aus technischer Sicht

16
... die erste Abstraktionsebene

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

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>
... die Abstraktion aus Business Sicht

19
... die zweite Abstraktionsebene

20
Problem 4
‣  Wo definiere ich, was aus meinen Servern bzw. Nodes wird?

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)

22
... die dritte Abstraktionsebene

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

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)

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
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
... Vor- und Nachteile der verschiedenen Möglichkeiten

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)
... params.pp für Module, Hiera für Profile

28
... die vierte Abstraktionsebene

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

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)

31
Konfiguration

32
Verzeichnisstruktur

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
Test und Debugging
‣  Testen
‣  Syntax Checks (puppet–lint)
‣  Smoke Tests (funktionalen Prüfung des Moduls, rspec / serverspec)
‣  Performance Tests
‣  Debugging
‣  Puppet Graph
Code testen

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

36
Beispiel: Checks, die auf dem Testsystem ausgeführt werden
Code testen

37
Beispiel: Graphen immer generieren
Code testen

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

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

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

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

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
... die fünfte Abstraktionsebene

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
... das Puppetfile

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

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

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

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

Designing
Puppet
49
Dia Agenda
Designing
Repositories
and
Environments
Designing
Modules
Getting
started

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

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

Puppet: Designing modules & repositories

Weitere ähnliche Inhalte

Andere mochten auch (10)

Ähnlich wie Puppet: Designing modules & repositories (20)

Mehr von inovex GmbH (20)

Puppet: Designing modules & repositories