Puppet - Designing Moduls and Repositories...‣ Hiera Lookups sind explizit und werden validiert (stdlib) ‣ Hiera Lookups haben keine Default Werte („fail fast“ Prinzip) Trennung

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


7

Wo (soll Puppet verwendet werden)?

‣  Umgebungen definieren

‣  Production, Stage, Test

‣  Vagrant, Docker


8

Wer (wird Puppet verwenden)?

‣  Alle Puppet Nutzer von Anfang an beteiligen

‣  System Engineers

‣  Entwickler


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

10

Modulentwicklung ... Worauf es wirklich ankommt


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


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

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


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?


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

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


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

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


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


35

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


36

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


37

Beispiel: Graphen immer generieren


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


Designing Puppet

39

Repositories und Environments ... Abhängigkeiten modellieren


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

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


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


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

Backup

57

Modulentwicklung ... Worauf es wirklich ankommt

Implementing Modules

58

Übersicht ‣  Abhängigkeiten

‣  Containment / Anchoring

‣  Sprach Syntax / DSL

‣  Conditionals


59

Problem 9 ‣  nicht intuitive Verwendung von Modulen (Konfiguration zu Parameter Mapping)

‣  hohe Aufwände bei Anpassungen von Puppet Modulen


60

Dimensionen, die bei der Modulentwicklung wichtig sind ‣  Komplexität der Konfiguration(-sdatei) die wir lösen müssen

‣  Zielgruppe für das Modul (Skill Level)

‣  Zeit

Ziele ‣  Funktionsweise des Moduls sollte in der init.pp ersichtlich sein

‣  Alle Parameter sollten explizit in der init.pp gesetzt und validiert werden


61

1. Parameter ‣  jegliche Konfiguration wird über Parameter übergeben und validiert

‣  Vorteil: Validierung der Parameter, Tests mit rspec

‣  Nachteil: hohe Komplexität und Aufwände, ab 10-15 Parameter unübersichtlich


62

2. Parameter 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


63

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


http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php 64

Modul Skeleton

Das erste Modul ... Ein Template für alle

65

Abhängigkeiten und Versionen des Moduls werden im Modulefile definiert

Modulentwicklung entkoppeln ... Das Modulefile

Documents

Puppet - Designing Moduls and Repositories...‣ Hiera Lookups sind explizit und werden validiert (stdlib) ‣ Hiera Lookups haben keine Default Werte („fail fast“ Prinzip) Trennung