Puppet - Module entwickeln - Von der Planung bis zur Umsetzung
 

Puppet - Module entwickeln - Von der Planung bis zur Umsetzung

on

  • 126 views

 

Statistics

Views

Total Views
126
Views on SlideShare
126
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Puppet - Module entwickeln - Von der Planung bis zur Umsetzung Puppet - Module entwickeln - Von der Planung bis zur Umsetzung Presentation Transcript

  • 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 Einleitung ... worum es in diesem Vortrag geht
  • 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 Einleitung ... worum es in diesem Vortrag geht
  • 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 Standards festlegen ... C/P/M Pattern als Abstraktionsebene
  • 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 ... C/P/M Pattern als Abstraktionsebene
  • Standards festlegen 14 Problemanalyse und Design ... Papier und Stift bitte Möglichkeiten Problem- analyse Umsetzungs- beispiel
  • 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 Möglichkeiten Problem- analyse Umsetzungs- beispiel
  • 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 Möglichkeiten bei der Umsetzung ... um die Übersicht zu behalten
  • 24 Beispiel: for each ‣  Aufruf ‣  Define Möglichkeiten bei der Umsetzung ... um die Übersicht zu behalten
  • 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 Möglichkeiten bei der Umsetzung ... Möglichkeiten Parameter von Profil an das Modul zu übergeben
  • 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 Möglichkeiten bei der Umsetzung ... Möglichkeiten Parameter von Profil an das Modul zu übergeben
  • 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 Möglichkeiten Problem- analyse Umsetzungs- beispiel
  • 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: alexander.pacnik@inovex.de
  • 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