puppet: designing modules & repositories
DESCRIPTION
Puppet: Designing modules & repositories Alexander Pacnik, LinuxTag Berlin, 08.05.2014TRANSCRIPT
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 ... worum es in diesem Vortrag geht
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 ... Papier und Stift bitte
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
Wo (soll Puppet verwendet werden)?
‣ Umgebungen definieren
‣ Production, Stage, Test
‣ Vagrant, Docker
Designing Puppet ... Papier und Stift bitte
8
Wer (wird Puppet verwenden)?
‣ Alle Puppet Nutzer von Anfang an beteiligen
‣ System Engineers
‣ Entwickler
Designing Puppet ... Papier und Stift bitte
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
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
Strukturierung der Module ... atomare Module für mehr Wiederverwendbarkeit
13
Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
14
Problem 2 ‣ Ressourcen in mehreren Modulen definiert
‣ Häufige Dependency Cycles
Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
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
Strukturierung der Module ... 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
Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
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
Strukturierung der Module ... die zweite Abstraktionsebene
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
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
Strukturierung der Module ... 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
Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
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
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
Trennung von Daten und Code ... 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)
Trennung von Daten und Code ... params.pp für Module, Hiera für Profile
28
Trennung von Daten und Code ... 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
Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
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
Konfiguration
Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
32
Verzeichnisstruktur
Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
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 ... testen für schnellere Entwicklung
35
Beispiel: Checks die lokal und auf dem Git bzw. CI System ausgeführt werden
Code testen ... testen für schnellere Entwicklung
36
Beispiel: Checks, die auf dem Testsystem ausgeführt werden
Code testen ... testen für schnellere Entwicklung
37
Beispiel: Graphen immer generieren
Code testen ... testen für schnellere Entwicklung
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
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
Modulentwicklung entkoppeln ... Modularisierung und Versionierung zur Entkopplung
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
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
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
Environment nach dem „Aufbauen“ auf dem Puppet Master
Modulentwicklung entkoppeln ... 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 ... worum es in diesem Vortrag geht
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: [email protected]
Anhang
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