Linux Tag Puppet. Designing Moduls and Repositories. Alexander Pacnik Karlsruhe,

Transkript

1 Linux Tag Puppet Designing Moduls and Repositories Alexander Pacnik Karlsruhe,

2 Einleitung... worum es in diesem Vortrag geht 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 2

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

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

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

6 Designing Puppet... Papier und Stift bitte 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 6

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

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

9 Designing Puppet... Papier und Stift bitte 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) 9

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

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

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

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

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

15 Strukturierung der Module... die Abstraktion aus technischer Sicht 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>] 15

16 Strukturierung der Module... die erste Abstraktionsebene 16

17 Strukturierung der Module... das Baukastenprinzip und Spielregeln für mehr Übersicht 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 17

18 Strukturierung der Module... die Abstraktion aus Business Sicht 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> 18

19 Strukturierung der Module... die zweite Abstraktionsebene 19

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

21 Strukturierung der Module... das Baukastenprinzip und Spielregeln für mehr Übersicht 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) 21

22 Strukturierung der Module... die dritte Abstraktionsebene 22

23 Strukturierung der Module... das Baukastenprinzip und Spielregeln für mehr Übersicht 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 23

24 Strukturierung der Module... das Baukastenprinzip und Spielregeln für mehr Übersicht 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) 24

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

26 Trennung von Daten und Code... Vor- und Nachteile der verschiedenen Möglichkeiten 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 26

27 Trennung von Daten und Code... params.pp für Module, Hiera für Profile 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) 27

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

29 Trennung von Daten und Code... Daten Auslagern für mehr Übersicht 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 Vgl. Vortrag vom Linuxtag

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

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

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

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

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

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

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

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

38 Code testen... testen für schnellere Entwicklung 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 38

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

40 Modulentwicklung entkoppeln... Modularisierung und Versionierung zur Entkopplung 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? 40

41 Modulentwicklung entkoppeln... Modularisierung und Versionierung zur Entkopplung 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 41

42 Modulentwicklung entkoppeln... Modularisierung und Versionierung zur Entkopplung 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 42

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

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

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

46 Environments aufbauen... Möglichkeit eins - librarian-puppet Repositories mit librarian-puppet verwalten Syntax 46

47 Environments aufbauen... Möglichkeit zwei r10k r10k Konfiguration r10k.yaml 47

48 Environments und Repositories... die Empfehlung 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 48

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

50 Parameter... um die Übersicht zu behalten 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 50

51 Parameter... um die Übersicht zu behalten 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 51

52 Fazit... takeaways 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 52

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

54 Anhang

55 Anhang... wo sie in Ruhe nachlesen können Quellen Puppet Style Guide Puppet Language Guide Puppet Referenzen Puppet Guides Puppet Blog Lizenz des Vortrags Creative Commons (by-nc-nd) 55

56 Backup

57 Modulentwicklung... Worauf es wirklich ankommt Implementing Modules 57

58 Parameter... um die Übersicht zu behalten Übersicht Abhängigkeiten Containment / Anchoring Sprach Syntax / DSL Conditionals 58

59 Parameter... um die Übersicht zu behalten Problem 9 nicht intuitive Verwendung von Modulen (Konfiguration zu Parameter Mapping) hohe Aufwände bei Anpassungen von Puppet Modulen 59

60 Parameter... um die Übersicht zu behalten 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 60

61 Parameter... um die Übersicht zu behalten 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 Parameter unübersichtlich 61

62 Parameter... um die Übersicht zu behalten 2. Parameter und Hash die wichtigsten 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 62

63 Parameter... um die Übersicht zu behalten 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 63

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

65 Modulentwicklung entkoppeln... Das Modulefile Abhängigkeiten und Versionen des Moduls werden im Modulefile definiert 65