Von Puppen und Marionetten
Konfigurationsmanagement mit Puppet
Puppet Dashboard
Puppet will in erster Linie ein Framework für die Konfigurationsverwaltung sein, eine GUI gehörte nicht zu den Prioritäten. Mittlerweile sind zwei nennenswerte Web-Frontends für Puppet verfügbar, das Puppet Dashboard und Foreman. Während das Dashboard (zu sehen in Abbildung 2) in erster Linie eine Übersicht über die von Puppet gesteuerten Rechner sowie Reports über erfolgreiche und fehlgeschlagene Aktionen bereitstellt, hat sich Foreman einiges mehr vorgenommen. Neben dem Dashboard ähnlichen Reports und einem auf Facter basierenden Inventar will Foreman sämtliche manuellen Arbeitsschritte vom Provisioning bis zur Konfiguration des Rechners automatisieren. Der »Vorarbeiter« macht sich Gedanken über DNS, DHCP, TFTP (erstellt PXE-Dateien), die Verwaltung der CA sowie eine rudimentäre CMDB oder Schnittstellen zu einer solchen.
Noch ist nicht ganz klar, ob und wie die beiden Projekte in Zukunft zusammenarbeiten wollen. Zwei sich überschneidende Oberflächen sind zuviel des Guten, aber Konkurrenz belebt ja bekanntlich das Geschäft. Gegenwärtig scheint der Status Quo den beiden jedenfalls nicht zu schaden. Jedenfalls abgesehen von der Tatsache, dass beide den Port 3000 für sich beanspruchen. Um sie beide nebeneinander zu betreiben, kommt man um einen kleinen Eingriff in den Code der jeweiligen Report-Skripts nicht herum.
Installation Dashboard
Das Dashboard ist noch nicht als Debian-Paket verfügbar, weshalb man die Installation händisch entsprechend Listing 6 vornehmen muss. Vorher hat man bereits das Dashboard von der Puppet-Website heruntergeladen und entpackt.
Ein wenig unschön ist die Tatsache, dass seit Version 1.0.3 empfohlen wird, dem Benutzer des Webservers Schreibrechte auf sämtliche Ordner des Dashboards zu geben. Aufgrund eines weiteren kleinen Bugs rund um den Konfigurationsschalter libdir
muss zudem
derzeit puppet_dashboard.rb von Hand verschoben werden.
Die in Listing 7 gezeigte Virtualhost-Konfiguration legt man als neue Datei puppet-dashboard im Ordner /etc/apache2/sites-available ab, aktiviert sie mit a2ensite puppet-dashboard und startet anschließend Apache neu. Unter http://server:3000/ ist jetzt das neue Puppet-Dashboard zu bewundern.
Listing 6: Installation Puppet Dashboard
apt-get install build-essential irb libmysql-ruby libmysqlclient-dev libopenssl-ruby libreadline-ruby mysql-server rake rdoc ri ruby ruby-dev cp config/database.yml.example config/database.yml # Datenbank-Konfiguration eventuell anpassen rake RAILS_ENV=production db:create rake RAILS_ENV=production db:migrate ./script/server -e production mv puppet-dashboard-1.0.3 /usr/share/puppet-dashboard chown -R www-data. /usr/share/puppet-dashboard cp -a /usr/share/puppet-dashboard/ext/puppet/puppet_dashboard.rb /var/lib/puppet/reports/
Listing 7: Virtualhost für das Puppet-Dashboard
Listen 3000 <VirtualHost *:3000> PassengerHighPerformance on PassengerMaxPoolSize 12 PassengerPoolIdleTime 1500 # PassengerMaxRequests 1000 PassengerStatThrottleRate 120 RailsAutoDetect On ServerName localhost DocumentRoot /usr/share/puppet-dashboard/public <Directory /usr/share/puppet-dashboard/public> Options None AllowOverride AuthConfig Order allow,deny allow from all </Directory> ErrorLog /var/log/apache2/dashboard.example.com_error.log LogLevel warn CustomLog /var/log/apache2/dashboard.example.com_access.log combined ServerSignature On </VirtualHost>
Installation Foreman
Von der Foreman-Website lassen sich fertige Debian-Pakete herunterladen, vorher sollte man aber noch Rails und die SQLite-Bibliothek für Ruby installieren: apt-get install rails libsqlite3-ruby
. Auch hier muss die Schnittstelle für die Live-Reports leider händisch kopiert werden:
cp /usr/share/foreman/extras/puppet/foreman/files/foreman-report.rb /var/lib/puppet/reports/foreman.rb
Da auch Foreman auf die Nutzung des Ports 3000 besteht, muss jetzt einer der beiden weichen. Am einfachsten ist es, in der zuvor für das Dashboard erstellten VirtualHost-Konfiguration den Port zu wechseln und den Port in dem entsprechenden Skript unter /var/lib/puppet/reports anzupassen. Auch das Skript von Foreman muss eventuell angepasst werden, wenn man sich nicht »foreman« als zusätzlichen Host-Alias einrichten will.
Skalierbarkeit
Puppet nutzt für gewöhnlich Webrick als Webserver, jenseits von Testumgebungen mit einigen wenigen Rechnern ist hiervon aber strikt abzuraten. Jede Puppet-Version kann alternativ auch mit Mongrel arbeiten, seit Version 0.24.6 unterstützt es auch Passenger.
Passenger (auch bekannt als mod_rails oder mod_rack) ist eine Apache-Erweiterung, die das Ausführen von Rails- oder Rackanwendungen innerhalb von Apache erlaubt. Ubuntu 10.10 liefert eine entsprechende Konfiguration bereits mit, und ein einfaches apt-get install puppetmaster-passenger
nimmt dem Administrator viel lästige Konfigurationsarbeit ab. Damit sollte man eine Weile auskommen, ansonsten lässt sich Puppet bei Bedarf auch ähnlich einer gewöhnlichen Webanwendung mit Reverse Proxies auch auf mehrere Rechner verteilen.
Um einen großen Verbund von Puppen und Marionetten macht sich Marionette Collective oder kurz Mcollective Gedanken. Mcollective setzt auf einen Broadcast-basierten Ansatz, um möglichst effizient große Cluster ansteuern zu können. Imdem auf bewährte Middleware und Message Broker wie ActiveMQ gesetzt wird, muss hier das Rad nicht neu erfunden werden. Auch für die jeweiligen Metadaten setzt man auf Bewährtes: MCollective kommt mit Puppet, Chef, Facter, Ohai und Eigenentwicklungen zurecht.
Der Ansatz scheint zu überzeugen und die jüngste Übernahme des Projekts durch PuppetLabs lässt auf eine integrierte Lösungen dieser beiden Frameworks in der Zukunft hoffen. Die Übernahme wurde anlässlich des Puppet Camps im Oktober 2010 bekanntgegeben, eine kleine Roadmap zur zukünftigen Zusammenarbeit steht auch schon fest.
Stay tuned
Puppet und sein Umfeld entwickeln sich beeindruckend schnell weiter, und gerade die jüngsten Entwicklungen lassen aufhorchen. Die immer größere werdende Gemeinschaft stellt auf den Plattformen des Herstellers eine wachsende Zahl an Erweiterungen und Modulen zur Verfügung. So sind die meisten Standardaufgaben bereits implementiert und lassen sich einfach auf die eigene Umgebung übertragen. Auf das was kommt, darf man also auf jeden Fall gespannt sein.
Der Autor
Thomas Gelf ist Senior Consultant bei der Netways GmbH, die seit über 10 Jahren im Bereich Open Source Systems Management und Datacenter-Solutions tätig ist, und hat langjährige Erfahrung im Bereich großer Open-Source-Infrastrukturen, Systems-Management-Lösungen und Datenbanken.