Puppet - Module entwickeln - Von der Planung bis zur Umsetzung

Puppet - Implementing Modules

Von der Planung bis zur Umsetzung

Alexander Pacnik Karlsruhe, 26.05.2014

2

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

Einleitung ... worum es in diesem Vortrag geht

3

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


4

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


Standards festlegen

5

Standards festlegen ... Papier und Stift bitte

Möglichkeiten Problem- analyse

Umsetzungs- beispiel

6

Problem 1 ‣  Wie will ich Probleme lösen?

Standards festlegen ... aber wie?

7

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

Standards festlegen ... Was ist Standard?

8

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:

Standards festlegen ... Aufgaben und Tools festlegen

9

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)

Standards festlegen ... Configuration vs. Deployment

10

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)

Standards festlegen ... Configuration vs. Deployment

11

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

12

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


13

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


Standards festlegen

14

Problemanalyse und Design ... Papier und Stift bitte



15

Problem 2 ‣  Was will ich installieren?

‣  Was kann / muss ich konfigurieren?

Problemanalyse und Design ... Papier und Stift bitte

* Am Beispiel CentOS mit Apache Httpd und PHP 16

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

Problemanalyse und Design ... was muss ich verwalten?

* Am Beispiel CentOS mit Apache Httpd und PHP

17

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)

Problemanalyse und Design ... was muss ich verwalten?

18

Zielstruktur definieren ‣  Zweite Mindmap mit der Zielstruktur erstellen

‣  Beide Mindmaps mit dem Team / Anforderungsstellern abstimmen

Problemanalyse und Design ... wie soll es aussehen?

19

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

Problemanalyse und Design ... um die Übersicht zu behalten

20

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

Möglichkeiten bei der Umsetzung ... um die Übersicht zu behalten

Standards festlegen

21

Möglichkeiten bei der Umsetzung ... Papier und Stift bitte



22

Problem 3 ‣  Wie umsetzen?

Möglichkeiten bei der Umsetzung ... welche technischen Möglichkeiten gibt es?

23

Class vs. Define ‣  Class: Ressourcen können nur einmal pro Node angewendet werden

‣  Define: Ressourcen können mehrfach angewendet werden, wenn sie eindeutig sind


24

Beispiel: for each ‣  Aufruf

‣  Define


25

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

‣  Vorteil: Validierung der Parameter, Tests mit rspec

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

‣  Empfehlung: bei wenigen Parametern auf Modulebene

Möglichkeiten bei der Umsetzung ... Möglichkeiten Parameter von Profil an das Modul zu übergeben

26

2. Template mit Parametern 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

‣  Empfehlung: bei optionalen Parametern auf Modulebene


27

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


28

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)

Problemanalyse und Design ... um die Übersicht zu behalten

Standards festlegen

29

Entscheidungen im Vorfeld ... Papier und Stift bitte



30

Demo

Beispiel ... der Code

31

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.

Parameter ... um die Übersicht zu behalten

32

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

Take-Away

33

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

35

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

Technology

Puppet - Module entwickeln - Von der Planung bis zur Umsetzung