Puppet - Implementing Modules. Von der Planung bis zur Umsetzung. Alexander Pacnik Karlsruhe,

Transkript

1 Puppet - Implementing Modules Von der Planung bis zur Umsetzung Alexander Pacnik Karlsruhe,

2 Einleitung... worum es in diesem Vortrag geht Typische Probleme Falsches Verständnis von Standard Betriebsysteme erstellen Konfigurationen, die möglichst für alle Anwender funktionieren sollen aber: schon zwischen Distributionen gibt es erhebliche Unterschiede Over Engineering Versuch alle möglichen Fälle von Anfang an zu berücksichtigen und im Code abzubilden 2

3 Einleitung... worum es in diesem Vortrag geht Resultierende Entwicklungsansätze Direkt mit der Implementierung starten und sich am OS orientieren Vorteil: am Anfang schnelles vorankommen Nachteil: häufiges Neuschreiben großer Teile des Codes Generalisierung Vorteil: vermeintlich Infrastructure as Code und hohe Testabdeckung Nachteil: Fokussierung auf Deployment Code statt auf Konfiguration, Umsetzungs- und Entwicklungsaufwände nicht angemessen 3

4 Einleitung... worum es in diesem Vortrag geht Alternativer Lösungsansatz Vorher eigene Standards definieren (setzt Papier und Stift voraus) Analyse, Design und Umsetzung der eigenen Module gemäß diesen Standards Vorteile Schnell in der Entwicklung und Anwendung Einfacher und wenig Code 4

5 Standards festlegen... Papier und Stift bitte Standards festlegen Problemanalyse Möglichkeiten Umsetzungsbeispiel 5

6 Standards festlegen... aber wie? Problem 1 Wie will ich Probleme lösen? 6

7 Standards festlegen... Was ist Standard? Standards Betriebssystem Standard: Weg der möglichst für alle Nutzer funktioniert, also der kleinste gemeinsame Nenner Projekt Standard: Möglichst minimales Regelwerk das die Art und Weise beschreibt, wie ihr Probleme in eurem Team für euren Kunden umsetzen wollt Empfehlung: an allgemeinen Standards orientieren, aber abweichen wo es keinen Sinn macht 7

8 Standards festlegen... Aufgaben und Tools festlegen Tools und Aufgaben festlegen Aufgaben (Image Verwaltung, Paketbau, Configuration, Deployment, Operations) Pro Aufgabe überlegen wer es später benutzen soll (Dev/Ops/...) Pro Aufgabe überlegen in welchen Umgebungen es benötigt wird Pro Aufgabe genau ein Tool und die Struktur definieren Beispiel: 8

9 Standards festlegen... Configuration vs. Deployment Was gehört zum Deployment einer Applikation (Context)? Applikation (Paket oder Verzeichnis) Konfiguration (teilweise in der Applikation, teilweise auf dem System z.b. vhost) Daten (Laufzeitdaten, beispielsweise Sessions) Was gehört zur Konfiguration des Systems? Binaries (Programme, idr über Pakete) Konfiguration (beispielsweise unter /etc/) Daten (Laufzeitdaten, beispielsweise logs) 9

10 Standards festlegen... Configuration vs. Deployment Problem Systempakete enthalten oft System und Context spezifische Daten um den Start mit den Diensten einfach zu machen (kleinster gemeinsamer Nenner) Lösungsansatz Alles systemspezifische wird über Puppet Component Module abgebildet Alles applikationsspezifische wird über Puppet Profile oder das Deployment abgebildet (je nach Verantwortung PaaS vs. full stack) 10

11 Standards festlegen... C/P/M Pattern als Abstraktionsebene 11

12 Standards festlegen... C/P/M Pattern als Abstraktionsebene Wiederholung Struktur Component Module Atomare Module die die Konfiguration des Systems enthalten (z.b. httpd) Modulspezifische Daten zusammen mit dem Modulcode (params.pp) Profile Technologische Klammer für unsere Module (z.b. profile_web_httpd_php) Umgebungsspezifische Daten, also Daten die sich in den Umgebungen unterscheiden (und nur diese) werden über Hiera geladen (z.b. Memory) Optional: applikationsspezifische Spezialisierungen der Profile (z.b. profile_web_httpd_wordpress) statt Deployment 12

13 Standards festlegen... C/P/M Pattern als Abstraktionsebene Wiederholung Regeln Keine Abhängigkeiten zwischen Modulen (mod_php Teil vom httpd Modul) Keine Vererbung (Inheritance), ähnliche Profile sind neue Profile Module sollten über Parameter gesteuert werden (API) Profile und Rollen haben keine Parameter 13

14 Problemanalyse und Design... Papier und Stift bitte Standards festlegen Problemanalyse Möglichkeiten Umsetzungsbeispiel 14

15 Problemanalyse und Design... Papier und Stift bitte Problem 2 Was will ich installieren? Was kann / muss ich konfigurieren? 15

16 Problemanalyse und Design... was muss ich verwalten? Pakete und Abhängigkeiten analysieren Pakete und Abhängigkeiten finden: repoquery --requires [--resolve] php Interessante Dateien finden: repoquery --lq <Pakete> Relevanten Dateien (Skripte, Konfigurationsdateien) in eine Mindmap schreiben * Am Beispiel CentOS mit Apache Httpd und PHP 16

17 Problemanalyse und Design... was muss ich verwalten? Konfigurations-Parameter bestimmen Hinter alle Dateien in der Mindmap schreiben was mit ihnen geschehen soll, dazu den Inhalt aller relevanten Dateien durcharbeiten Ggf. aufteilen (httpd.conf -> httpd.conf und modules.conf) * Am Beispiel CentOS mit Apache Httpd und PHP 17

18 Problemanalyse und Design... wie soll es aussehen? Zielstruktur definieren Zweite Mindmap mit der Zielstruktur erstellen Beide Mindmaps mit dem Team / Anforderungsstellern abstimmen 18

19 Problemanalyse und Design... um die Übersicht zu behalten Umsetzung in die Mindmap einzeichnen Hinter alle Datei schreiben wo und wie sie umgesetzt werden sollen Dateien die man 1:1 bei beibehalten will als file / template im Modul kopieren In die Zielstruktur Mindmap 19

20 Möglichkeiten bei der Umsetzung... um die Übersicht zu behalten Profile Beispiel: profile_web_apache_gitblit Aufruf des Basismoduls welches den Dienst installiert und das System konfiguriert Templates als Teil der Applikation nicht über das Deployment sonderen ein applikationsspezifisches Profil verwaltet Loadmodule, Logging, etc. sind im vhost definiert 20

21 Möglichkeiten bei der Umsetzung... Papier und Stift bitte Standards festlegen Problemanalyse Möglichkeiten Umsetzungsbeispiel 21

22 Möglichkeiten bei der Umsetzung... welche technischen Möglichkeiten gibt es? Problem 3 Wie umsetzen? 22

23 Möglichkeiten bei der Umsetzung... um die Übersicht zu behalten Class vs. Define Class: Ressourcen können nur einmal pro Node angewendet werden Define: Ressourcen können mehrfach angewendet werden, wenn sie eindeutig sind 23

24 Möglichkeiten bei der Umsetzung... um die Übersicht zu behalten Beispiel: for each Aufruf Define 24

25 Möglichkeiten bei der Umsetzung... Möglichkeiten Parameter von Profil an das Modul zu übergeben 1. Template mit Parametern jegliche Konfiguration wird über Parameter übergeben und validiert Vorteil: Validierung der Parameter, Tests mit rspec Nachteil: ab Parameter hohe Komplexität und unübersichtlich Empfehlung: bei wenigen Parametern auf Modulebene 25

26 Möglichkeiten bei der Umsetzung... Möglichkeiten Parameter von Profil an das Modul zu übergeben 2. Template mit Parametern 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 Empfehlung: bei optionalen Parametern auf Modulebene 26

27 Möglichkeiten bei der Umsetzung... Möglichkeiten Parameter von Profil an das Modul zu übergeben 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 Empfehlung: nur im Notfall verwenden, besser Modules und Profiles Pattern 27

28 Problemanalyse und Design... um die Übersicht zu behalten Entscheidungskriterien für die Umsetzung Nur parametrisieren was für den aktuellen Fall benötigt wird Beispiel: bei einem Betriebssystem ist die params.pp oft nicht notwendig Wie viele Konfigurationen ändern sich bei der Verwendung des Moduls? Zur Orientierung: 10-15: als Parameter auf Modulebene (httpd.conf) >15 aber optional: als Hash wenn möglich auf Modulebene (modules.conf) >15 aber mandatory: als Datei / Template auf Profil ebene (vhost.conf) 28

29 Entscheidungen im Vorfeld... Papier und Stift bitte Standards festlegen Problemanalyse Möglichkeiten Umsetzungsbeispiel 29

30 Beispiel... der Code Demo 30

31 Parameter... um die Übersicht zu behalten Fazit Bei wenig Erfahrung oder komplexen Modulen empfiehlt es sich die beiden Mindmaps tatsächlich in schriftlicher Form zu verfassen Iteratives Vorgehen heißt mit (nur) den Informationen zu arbeiten die man aktuell hat. Für Erweiterungen planen, aber noch nicht implementieren (!) Die Module und deren Weiterentwicklung dürfen den Betrieb aber nicht bremsen, sonst müssen ihn schneller machen. 31

32 Take-Away Take-Away Der Fokus sollte auf der Konfiguration der Systeme und nicht auf dem Code zur Konfiguration liegen. Code muss kurz und selbsterklärend sein 32

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

34 Anhang

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