SlideShare ist ein Scribd-Unternehmen logo
Puppet Kickstart
Referent: Thomas Gelf
Nürnberg, 06.06.2011
 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?

Weitere ähnliche Inhalte

PDF
Grundlagen puppet
PDF
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
PDF
OSMC 2010 | Verwendung von Puppet in verteilten Monitoring Umgebungen by Birg...
PDF
Konfigurations Management mit Puppet (Webinar vom 17.10.2013)
PDF
Puppet: Aufbau einer Puppet Enterprise Umgebung (Webinar vom 28.03.2014)
PDF
Einführung in Puppet
PDF
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
PPTX
Puppet und OpenStack - Ein gutes Team
Grundlagen puppet
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
OSMC 2010 | Verwendung von Puppet in verteilten Monitoring Umgebungen by Birg...
Konfigurations Management mit Puppet (Webinar vom 17.10.2013)
Puppet: Aufbau einer Puppet Enterprise Umgebung (Webinar vom 28.03.2014)
Einführung in Puppet
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
Puppet und OpenStack - Ein gutes Team

Ähnlich wie OSDC 2011 | Puppet from Scratch by Thomas Gelf (13)

PDF
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
PDF
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
PDF
Upgrading Puppet CommitterConf Essen 2014
PDF
Puppet - Entwicklungsworkflow und Basismodule
PDF
Puppet: Windows Configuration Management (Webinar vom 12.12.2014)
PDF
Systemmanagement mit Puppet und Foreman
PDF
Opensource Tools für das Data Center Management
PDF
Systemmanagement mit Puppet und Foreman
PPTX
Icinga mit Puppet - Hamburg 2013
PDF
Serverprovisioning in einer dynamischen Infrastruktur
PDF
Puppet: Designing modules & repositories
PDF
Puppet - Umgebungen, Daten & Code, Abhängigkeiten
PDF
System- & Konfigurationsmanagement mit Foreman & Puppet
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
System-Management-Trio: Zentrale Verwaltung mit facter, puppet und augeas
Upgrading Puppet CommitterConf Essen 2014
Puppet - Entwicklungsworkflow und Basismodule
Puppet: Windows Configuration Management (Webinar vom 12.12.2014)
Systemmanagement mit Puppet und Foreman
Opensource Tools für das Data Center Management
Systemmanagement mit Puppet und Foreman
Icinga mit Puppet - Hamburg 2013
Serverprovisioning in einer dynamischen Infrastruktur
Puppet: Designing modules & repositories
Puppet - Umgebungen, Daten & Code, Abhängigkeiten
System- & Konfigurationsmanagement mit Foreman & Puppet
Anzeige

OSDC 2011 | Puppet from Scratch by Thomas Gelf

  • 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)
  • 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
  • 34. Danke für Ihre Aufmerksamkeit!