0
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 Umgebu...
3
Problemstellung: Unterschiedliche Anforderungen
‣  Anforderungen Betrieb (beispielsweise verschiedene Umgebungen)
‣  Anf...
Designing
Puppet
4
Entscheidungen im Vorfeld
... Papier und Stift bitte
Designing
Repositories
and
Environments
Designing
...
5
Ziele
‣  Anforderungsanalyse
‣  Entscheidung explizit treffen, wie Puppet verwendet werden soll
Designing Puppet
... Pap...
6
Was (soll mit Puppet verwaltet werden)?
‣  Deploymentgrenzen anhand der Verantwortung definieren
‣  Betriebssystem
‣  Wi...
7
Wo (soll Puppet verwendet werden)?
‣  Umgebungen definieren
‣  Production, Stage, Test
‣  Vagrant, Docker
Designing Pupp...
8
Wer (wird Puppet verwenden)?
‣  Alle Puppet Nutzer von Anfang an beteiligen
‣  System Engineers
‣  Entwickler
Designing ...
9
Wie (soll Puppet verwendet werden)?
‣  run mode festlegen (Ansatz wählen)
‣  Agent (State verwalten - empfohlen)
‣  Pro:...
Designing
Puppet
10
Modulentwicklung
... Worauf es wirklich ankommt
Designing
Repositories
and
Environments
Designing
Modu...
11
Problem 1
‣  Geringe Wiederverwendbarkeit von Puppet Code
‣  Hohe Komplexität des Puppet Codes
‣  häufige if-Statements...
12
Component Module - Eigenschaften
‣  Unabhängig, atomar und kann jederzeit mit anderen geteilt werden
‣  Abhängigkeiten ...
13
Strukturierung der Module
... das Baukastenprinzip und Spielregeln für mehr Übersicht
14
Problem 2
‣  Ressourcen in mehreren Modulen definiert
‣  Häufige Dependency Cycles
Strukturierung der Module
... das Ba...
15
Profile (früher Services)
‣  die Klammer auf technischer Ebene
‣  besteht aus Component Modulen (und optional Ressource...
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 Busine...
18
Roles
‣  Abstraktionsebene aus Business-Sicht, also für was ein System steht
‣  es werden ausschließlich ein oder mehre...
19
Strukturierung der Module
... die zweite Abstraktionsebene
20
Problem 4
‣  Wo definiere ich, was aus meinen Servern bzw. Nodes wird?
Strukturierung der Module
... das Baukastenprinz...
21
Möglichkeiten
‣  ENC - empfohlen (The Foreman)
‣  Vorteile: zentral verwaltet
‣  Nachteile: keine Versionierung
‣  site...
22
Strukturierung der Module
... die dritte Abstraktionsebene
23
Zusammenfassung
‣  Sind Profile und Rollen notwendig?
‣  Nein, aber man verliert die Möglichkeit der Abstraktion
‣  Kön...
24
Fazit
‣  Vorteile: Abstraktion und Entkopplung von Logik und Implementierung
‣  Nachteile:
‣  kann unübersichtlich werd...
25
Problem 5
‣  Viele if-Statements, um umgebungsspezifische Unterschiede abzufangen
‣  Unterschiedlicher Branch bzw. Klas...
26
Möglichkeiten
‣  params.pp
‣  Vorteile: Logik genau in einer Klasse, einfach, versionierbar
‣  Nachteile: Business Logi...
27
Empfehlung für die Verwendung mit Rollen
‣  Betriebssystemspezifische oder modulspezifische Daten in params.pp
(solange...
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)
‣  S...
https://github.com/TomPoulton/hiera-eyaml 30
Problem 6
‣  Wie mit sensitive Daten wie Passwörter umgehen?
‣  hieradata/ in...
31
Konfiguration
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht
32
Verzeichnisstruktur
Trennung von Daten und Code
... Daten Auslagern für mehr Übersicht
33
Problem 7
‣  Änderungen am Code sind zeitaufwändig
‣  Fehler werden erst in den Test-Umgebungen erkannt
‣  Code schwier...
34
Test und Debugging
‣  Testen
‣  Syntax Checks (puppet–lint)
‣  Smoke Tests (funktionalen Prüfung des Moduls, rspec / se...
35
Beispiel: Checks die lokal und auf dem Git bzw. CI System ausgeführt werden
Code testen
... testen für schnellere Entwi...
36
Beispiel: Checks, die auf dem Testsystem ausgeführt werden
Code testen
... testen für schnellere Entwicklung
37
Beispiel: Graphen immer generieren
Code testen
... testen für schnellere Entwicklung
38
Empfohlenes Vorgehen für das Testen
1.  Lokal Syntax-Checks ausführen während der Entwicklung (Skript / $EDITOR)
2.  Co...
Designing
Puppet
39
Repositories und Environments
... Abhängigkeiten modellieren
Designing
Repositories
and
Environments
D...
40
Problem 8
‣  Ein Modul, das in vielen anderen Profilen oder Rollen verwendet wird, lässt sich
schwierig ändern
‣  Wie t...
41
Lösungsansätze für Repository zu Environment Mapping
1.  Ein Repository pro Environment
‣  Vorteile: einfach
‣  Nachtei...
42
Lösungsansätze für Repository zu Environment Mapping
1.  Ein Repository pro Environment
‣  Vorteile: einfach
‣  Nachtei...
43
Modulentwicklung von der Version im Environment entkoppeln
‣  Jedes Modul wird versioniert in einem eigenen Git Reposit...
44
Abhängigkeiten und Versionen der Repositories werden im Puppetfile definiert
Empfehlung
‣  Nur Git verwenden (Historie)...
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
...
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)
‣ ...
Designing
Puppet
49
Dia Agenda
... worum es in diesem Vortrag geht
Designing
Repositories
and
Environments
Designing
Modul...
50
Empfehlung für das Vorgehen
1.  Design bzw. Konventionen schriftlich festlegen
2.  Modul-Skeleton erstellen
3.  Entwick...
51
Empfehlung für den Anfang
‣  im Zweifel mit dem einfachsten möglichen Weg beginnen
‣  iteratives Vorgehen: im zweiten S...
52
Fazit
‣  Puppet-Entwicklung = Software-Entwicklung
‣  Eine DSL ist keine Programmiersprache
‣  Puppet ersetzt nicht die...
53
Vielen Dank für Ihre Aufmerksamkeit
Kontakt
Alexander Pacnik
IT Engineering & Operations
Project Management
inovex GmbH...
Anhang
55
Quellen
‣  Puppet Style Guide
http://docs.puppetlabs.com/guides/style_guide.html
‣  Puppet Language Guide
http://docs.p...
Upcoming SlideShare
Loading in...5
×

Puppet: Designing modules & repositories

669

Published on

Puppet: Designing modules & repositories
Alexander Pacnik, LinuxTag Berlin, 08.05.2014

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
669
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Puppet: Designing modules & repositories"

  1. 1. Linux Tag 2014 - Puppet Designing Moduls and Repositories Alexander Pacnik Karlsruhe, 08.05.2014
  2. 2. 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. 3. 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
  4. 4. Designing Puppet 4 Entscheidungen im Vorfeld ... Papier und Stift bitte Designing Repositories and Environments Designing Modules Getting started
  5. 5. 5 Ziele ‣  Anforderungsanalyse ‣  Entscheidung explizit treffen, wie Puppet verwendet werden soll Designing Puppet ... Papier und Stift bitte
  6. 6. 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 Designing Puppet ... Papier und Stift bitte
  7. 7. 7 Wo (soll Puppet verwendet werden)? ‣  Umgebungen definieren ‣  Production, Stage, Test ‣  Vagrant, Docker Designing Puppet ... Papier und Stift bitte
  8. 8. 8 Wer (wird Puppet verwenden)? ‣  Alle Puppet Nutzer von Anfang an beteiligen ‣  System Engineers ‣  Entwickler Designing Puppet ... Papier und Stift bitte
  9. 9. 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 ... Papier und Stift bitte
  10. 10. Designing Puppet 10 Modulentwicklung ... Worauf es wirklich ankommt Designing Repositories and Environments Designing Modules Getting started
  11. 11. 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. 12. 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. 13. 13 Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  14. 14. 14 Problem 2 ‣  Ressourcen in mehreren Modulen definiert ‣  Häufige Dependency Cycles Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  15. 15. 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. 16. 16 Strukturierung der Module ... die erste Abstraktionsebene
  17. 17. 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 Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  18. 18. 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. 19. 19 Strukturierung der Module ... die zweite Abstraktionsebene
  20. 20. 20 Problem 4 ‣  Wo definiere ich, was aus meinen Servern bzw. Nodes wird? Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  21. 21. 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) Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  22. 22. 22 Strukturierung der Module ... die dritte Abstraktionsebene
  23. 23. 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 Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  24. 24. 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) Strukturierung der Module ... das Baukastenprinzip und Spielregeln für mehr Übersicht
  25. 25. 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. 26. 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. 27. 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. 28. 28 Trennung von Daten und Code ... die vierte Abstraktionsebene
  29. 29. 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 Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
  30. 30. 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) Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
  31. 31. 31 Konfiguration Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
  32. 32. 32 Verzeichnisstruktur Trennung von Daten und Code ... Daten Auslagern für mehr Übersicht
  33. 33. 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. 34. 34 Test und Debugging ‣  Testen ‣  Syntax Checks (puppet–lint) ‣  Smoke Tests (funktionalen Prüfung des Moduls, rspec / serverspec) ‣  Performance Tests ‣  Debugging ‣  Puppet Graph Code testen ... testen für schnellere Entwicklung
  35. 35. 35 Beispiel: Checks die lokal und auf dem Git bzw. CI System ausgeführt werden Code testen ... testen für schnellere Entwicklung
  36. 36. 36 Beispiel: Checks, die auf dem Testsystem ausgeführt werden Code testen ... testen für schnellere Entwicklung
  37. 37. 37 Beispiel: Graphen immer generieren Code testen ... testen für schnellere Entwicklung
  38. 38. 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 Code testen ... testen für schnellere Entwicklung
  39. 39. Designing Puppet 39 Repositories und Environments ... Abhängigkeiten modellieren Designing Repositories and Environments Designing Modules Getting started
  40. 40. 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. 41. 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 Modulentwicklung entkoppeln ... Modularisierung und Versionierung zur Entkopplung
  42. 42. 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 Modulentwicklung entkoppeln ... Modularisierung und Versionierung zur Entkopplung
  43. 43. 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. 44. 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. 45. 45 Environment nach dem „Aufbauen“ auf dem Puppet Master Modulentwicklung entkoppeln ... die fünfte Abstraktionsebene
  46. 46. https://github.com/rodjek/librarian-puppet 46 Repositories mit librarian-puppet verwalten ‣  Syntax Environments aufbauen ... Möglichkeit eins - librarian-puppet
  47. 47. https://github.com/adrienthebo/r10k 47 r10k ‣  Konfiguration ‣  r10k.yaml Environments aufbauen ... Möglichkeit zwei – r10k
  48. 48. 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
  49. 49. Designing Puppet 49 Dia Agenda ... worum es in diesem Vortrag geht Designing Repositories and Environments Designing Modules Getting started
  50. 50. 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. 51. 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 Parameter ... um die Übersicht zu behalten
  52. 52. 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. 53. 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: alexander.pacnik@inovex.de
  54. 54. Anhang
  55. 55. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×