Puppet Kickstart Nürnberg, 06.06.2011 Referent: Thomas Gelf
Einführung in Puppet Kurz und würzig Soll Lust auf mehr machen!
Zuallererst... ICH! 30 Jahre "Italienischer Staatsbürger deutscher Muttersprache" oder kurz: Südtiroler! Senior Consultant bei Netways Netz, Systemplattformen und -Architektur, Software
Ich und Puppet Trainings ADMIN-Magazin 06/2010
Netways und Puppet Offizieller Schulungs-Partner von Puppetlabs Nächster Termin: 24. - 26. Mai Weitere Termine: 13. - 15. September 2011 06. - 08. Dezember 2011
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
Konfigurationsmanagement? Ist laut Wikipedia eine Managementdisziplin Management? Disziplin? KMO, KI, KÜ, KB, KA k.a.?
Aber... äääh... Kickstart? Das Schöne an Puppet: Auspacken, loslegen! Schnell erste Erfolge......ohne große Vorbereitung!
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
Wie, woher, wieso? Luke Kanies Puppet Labs Ruby Lizenz: GPL
Der Mitbewerb bcfg2 cfengine chef ssh & for-schleifen...
Welche Vorteile bietet Puppet? Reproduzierbarkeit Konsistenz Einfacher Einstieg Portabel (Linux, Solaris, BSD...)
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
Wer Erfolg und alles unter Kontrolle haben will......der benötigt: Fakten (facts) Puppets (Marionetten)...und Ruby!!
Also los! Erstes Werkzeug: ralsh Oder eigentlich: puppet resource Praktische Beispiele: ralsh user puppet resource package...
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
Um die Verwirrung perfekt zu machen... Auch Konfigurationsdateien entsprechend geändert: [puppetd] [agent] [puppetmasterd] [master]
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
Komponenten Bibliothek voll mit Rezepten Darauf aufbauend wird mit deklarativer Sprache festgelegt, wie die eigenen Systeme aussehen sollen Client- und Serverkomponenten
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)
Wo liegt die Konfiguration? Bei Bedarf auch LDAP oder SQL Aber: am attraktivsten mit klassischen Textfiles Versionskontrollsystem: Sämtliche Änderungen historisch nachvollziehbar Rollback!
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
Fakten facter Standalone-Tool Plattformübergreifend Ruby-Bibliothek System-Informationen (Praktisches Beispiel) Eigene facts möglich Good news: IPv6 facts mittlerweile im Master!
Nomen es omen Verwaltete Objekte nennen sich Resourcen Resourcen sind in Gruppen organisiert, wir sprechen hier vom Type Konfiguration oder Codeschnipsel nennen sich Manifest
Manifeste? Im Sinne der Ladungsliste eines Schiffes Was soll drauf sein Aber nicht: was müssen wir noch aufladen
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)
Ein erstes vollständiges Manifest
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
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
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!
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
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
Web-Frontends Foreman Puppet Dashboard
Danke für Ihre Aufmerksamkeit!
Noch Fragen?