Selbst in großen Umgebungen werden Server und Netzwerke oft noch manuell administriert. Dies ist nicht nur unwirtschaftlich und ineffizient, sondern auch noch sehr fehleranfällig. Und manchmal schaffen es die Administratoren kaum noch mit dem Wachstum der IT mitzuhalten. Das Zauberwort heißt Automatisierung: Regelmäßig wiederkehrende Aufgaben, wie Paketinstallationen, Konfigurationsänderungen oder Rechnerinstallationen werden nicht mehr manuell durchgeführt, sondern nur noch zentral beschrieben und dann ausgerollt. Dabei ist es egal ob solche Änderungen einmal oder tausendfach in einem Cluster durchgeführt werden müssen. In diesem Vortrag erhalten Sie einen Basisüberblick über die Funktionsweisen und Möglichkeiten von Puppet.

1. Puppet Kickstart
Referent: Thomas Gelf
Nürnberg, 06.06.2011

2.  Einführung in Puppet
 Kurz und würzig
 Soll Lust auf mehr machen!

3. Zuallererst... ICH!
 30 Jahre
 "Italienischer Staatsbürger deutscher Muttersprache"
…oder kurz: Südtiroler!
 Senior Consultant bei Netways
 Netz, Systemplattformen und -Architektur, Software

4. Ich und Puppet
 Trainings
 ADMIN-Magazin 06/2010

5. Netways und Puppet
 Offizieller Schulungs-Partner von Puppetlabs
 Nächster Termin: 24. - 26. Mai
 Weitere Termine:
13. - 15. September 2011
06. - 08. Dezember 2011

6. Was ist eigentlich Puppet?
 Werkzeug für das Konfigurationsmanagement
 Gute Anregung zum Reflektieren der eigenen Vorgänge
und Arbeitsweise
 Alle Systeme sind gleich?
 Im Grunde eine Abstraktionsschicht zwischen dem
Administrator und seinen Systemen

7. Konfigurationsmanagement?
 Ist laut Wikipedia eine „Managementdisziplin“
 Management?
 Disziplin?
 KMO, KI, KÜ, KB, KA – k.A.?

8. Aber... äääh... Kickstart?
 Das Schöne an Puppet:
Auspacken, loslegen!
 Schnell erste Erfolge...
...ohne große Vorbereitung!

9. So ganz ohne Plan? Besser nicht!
 Ein guter Plan kann WIRKLICH nicht schaden:
– Wofür genau will man Puppet nutzen?
– Was fällt in seine Zuständigkeit, was nicht?
 Aber zuallererst:
– Kennenlernen
– Rumspielen
– Ausprobieren

10. Wie, woher, wieso?
 Luke Kanies
 Puppet Labs
 Ruby
 Lizenz: GPL

11. Der Mitbewerb
 bcfg2
 cfengine
 chef
 ssh & for-Schleifen
 ...

12. Welche Vorteile bietet Puppet?
 Reproduzierbarkeit
 Konsistenz
 Einfacher Einstieg
 Portabel (Linux, Solaris, BSD...)

13. Warum ist Puppet anders?
 Im Vordergrund stehen:
„Die Abhängigkeiten zwischen den zu konfigurierenden
Komponenten“
 Und die Details der Konfiguration?
Werden in den Hintergrund verschoben!
 Deklarative Sprache

14. Wer Erfolg und alles unter Kontrolle haben will...
 ...der benötigt:
Fakten (facts)
Puppets (Marionetten)
...und Ruby!!

15. Also los!
 Erstes Werkzeug: ralsh
 Oder eigentlich: puppet resource
 Praktische Beispiele:
– ralsh user
– puppet resource package
– ...

16. Zu Befehl!
 Wie jetzt? ralsh oder puppet resource?
Puppet bis 0.25 Puppet 2.6
puppetmasterd puppet master
puppetd puppet agent
puppet puppet apply
puppetca puppet cert
ralsh puppet resource
puppetqd puppet queue
filebucket puppet filebucket
puppetdoc puppet doc
pi puppet describe

17. Um die Verwirrung perfekt zu machen...
 Auch Konfigurationsdateien entsprechend geändert:
 [puppetd] → [agent]
 [puppetmasterd] → [master]

18. Welche Version einsetzen?
 Empfehle mit 2.6 zu starten: viel mehr Möglichkeiten
 Grundsätzlich:
– Alte Clients laufen auch mit neuem Server
– Gilt umgekehrt nicht immer
 Bei Upgrade also immer den Server zuerst!
 Und...
...das Testen nicht vergessen!
 Falls nicht von Distro bereitgestellt: Ruby-Gem

19. Komponenten
 Bibliothek voll mit „Rezepten“
– Darauf aufbauend wird mit deklarativer Sprache
festgelegt, wie die eigenen Systeme aussehen sollen
 Client- und Serverkomponenten

20. Architektur
 SSL-Verbindung zum Master
 XML-RPC oder auch REST
 Master verpackt die Konfiguration für den Client
 Client vergleicht diese mit seinem Status Quo...
 ...und korrigiert eventuelle Abweichungen
(Praktisches Beispiel)

21. Wo liegt die Konfiguration?
 Bei Bedarf auch LDAP oder SQL
 Aber: am attraktivsten mit klassischen Textfiles
 Versionskontrollsystem:
– Sämtliche Änderungen historisch nachvollziehbar
– Rollback!

22. Puppet kann VCS? SVN? GIT?
 Jain.
 Use the right tool for the right job!
 Puppet stellt „nur“ die Infrastruktur zum Verteilen der
Konfiguration bereit
 Wer diese liefert, ist ihm ziemlich egal

23. Fakten
 facter
 Standalone-Tool
 Plattformübergreifend
 Ruby-Bibliothek
 System-Informationen
(Praktisches Beispiel)
 Eigene „facts“ möglich
 Good news: IPv6 facts mittlerweile im Master!

24. Nomen es omen
 Verwaltete Objekte nennen sich „Resourcen“
 Resourcen sind in Gruppen organisiert, wir sprechen
hier vom „Type“
 Konfiguration oder Codeschnipsel nennen sich
„Manifest“

25. Manifeste?
 Im Sinne der Ladungsliste eines Schiffes
 Was soll drauf sein
 Aber nicht: was müssen wir noch aufladen

26. Wie soll so ein Manifest aussehen?
 Hübsch. Syntax Highlighting → vim-puppet
 Puppet lässt uns ziemlich freie Hand
 Es ist eine gute Idee, sich an die „Best Practices“ zu
halten
http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Best_Practice
http://projects.puppetlabs.com/projects/puppet/wiki/Advanced_Puppet_Pattern
 Alles in „Modules“ packen
 Beispiele suchen! (http://forge.puppetlabs.com/ etc)
(Praktische Beispiele)

27. Ein erstes vollständiges Manifest

28. Was fehlt noch zur vollständigen Umgebung?
 Zentrale Konfigurationsdatei: puppet.conf
 Abschnitt [main] → Pfade
 Evtl noch Abschnitte für [master] etc
 Distributionsspezifisches (z.b. /etc/defaults/puppet)
 Das zentrale Manifest liegt für gewöhnlich unter
/etc/puppet/manifests/site.pp

29. Kennenlernen
 Master und Agent kennen sich noch nicht!
 Client stellt automatisch eine Zertifikatsanfrage
 Auf dem Master sichtbar:
# puppet cert --list
client1.example.com
# puppet cert --sign client1.example.com
 WICHTIG: Saubere Namensauflösung

30. Schnelltest
 Es reicht eine einfache site.pp:
node default {
notice("Unbelievable, it's really working!")
}
 Auf dem Master muss im Syslog eine entsprechende
Meldung erscheinen, in etwa so:
(Scope(Node[default])) Unbelievable, it's really working!

31. Wichtige Begriffe
 Catalog: Gesamtheit der Ressourcen, Dateien,
Eigenschaften für ein bestimmtes System
 Class: Behälter für Ressourcen
 Definition, Defined Type: auf Anwendungsebene
definierter Resource-Typ (!= native type)
 Plugin: eigene Typen, mit Ruby erstellt
 Templates: ERB-Dateien, um systemspezifische
Konfigurationsdateien erstellen zu können
 Variablen: Variablen, aber unveränderlich

32. Serverbetrieb
 Out of the box mit webrick
– Will man NICHT haben
 Alternativ: mongrel
 Besser: Passenger (= mod_rails für Apache)
 Im Idealfall: fertige Pakete aus Distro
 Neue Ansätze: MCollective

33. Web-Frontends
 Foreman
 Puppet Dashboard

34. Danke für Ihre Aufmerksamkeit!

35. Noch Fragen?