Seite wählen

NETWAYS Blog

Ein lokales Puppet Development Environment muss her

Wenn man für Puppet Code oder Module entwickeln möchte gibt es verschiedene Ansätze die man nutzen kann:

  • locale Entwicklung, git pushen, in Entwicklungs-Environment auf produktivem Puppetmaster testen
  • lokale Entwicklung, VM mit Puppet Agent, puppet apply nutzen
  • lokale Entwicklung, VMs Puppetmaster/Puppetserver mit Puppetdb Anbindung und einer oder mehrere Clients mit Puppet Agent

Wir wollen uns hier die dritte Möglichkeit anschauen. Als Basis nutzen wir Vagrant, eine Automatisierungsplattform für reproduzierbare Entwicklungsumgebungen.Die Virtualisierung übernimmt in dem Fall  Virtual Box.Vagrant nutzt zum Provisionieren der VMs zwei verschiedene Teile:

  • sogenannte Base Boxes, ein Basisimage, auf dem alles weitere aufsetzt
  • Das sogenannte Vagrantfile das diese Box kopiert, startet und in den gewünschten Zustand überführt.

Das schöne ist Vagrantfiles und Base Boxes (sofern sie selbstgebaut sind) lassen sich wunderbar unter Versionskontrolle stellen und mit mehreren Leuten weiterentwickeln. Und das Ergebnis sieht am Ende bei jedem gleich aus, ohne das man sich ein Bein dafür ausreissen muss.
Wie sieht jetzt eine fertige Entwicklungs Umgebung aus mehreren VMs aus?

  • puppet (Puppetmaster/Puppetserver)
  • puppetdb (PuppetDB API Teil)
  • postgres-puppetdb (PuppetDB Datenbank Backend)
  • puppetclient01 (Puppet Agent, für diesen Node wird Entwickelt)

Um nun die Entwicklungsumgebung aufzubauen checkt man folgendes Git aus und installiert Virtual Box und Vagrant. Jetzt wechselt ins Repository und führt das Script yes_create_a_puppet_development_environment.sh aus. Nun entscheidet man sich für eine Puppetversion, wir nehmen Version 4. Nach ca. 20 Minuten hat man eine laufende Entwicklungsumgebung. Man hat jetzt die Wahl ob man aus dem Vagrant Ordner entwickelt oder die Grundlage in ein neues Git überführt und dieses seperat mountet. Eine Anleitung dazu findet sich in der Readme, genau wie geplante Features und Bugs
Das Git Repository für die Base Boxen findet sich Hier und die Boxen können mit Packer zu Images gebaut werden.

LConf 1.0 & LConf for Icinga 1.0.0

Vor einiger Zeit hat Tobias in seiner Blogserie „Nagios Config Interfaces“ unser Tool ‚LConf‘ vorgestellt, mit dem sich auch große Monitoringumgebungen bequem konfigurieren lassen. Wir freuen uns, heute Version 1.0 des freien (GPL) Tools veröffentlichen zu können.
Neben neuen Features wie Servicegruppen, SVN Revisions, neuen LDAP Schemas und vielen neuen Attributen mussten auch zahlreiche Bugs das Zeitliche segnen. Herunterladen kann man sich LConf wie immer auf netways.org.
Der Komfort von LConf steht und fällt natürlich mit dem verwendeten LDAP Editor. Für alle Benutzer der neuen Icinga-Web Oberfläche (und die, die es noch werden wollen) haben wir deshalb ein eigenes,  (nicht nur) auf LConf zugeschnittenen LDAP Modul entwickelt: LConf for Icinga.
Ein kleiner Auszug aus den Features:

  • Direkte Verwaltung des LConf Baums über den Browser in Icinga-Web
  • Intuitive Bedienung per Drag&Drop
  • Aliase lassen sich einfache per Drag&Drop erstellen und werden automatisch aktualisiert
  • Schlüsselwortsuche
  • Filterbarer LDAP Baum mittels Filtertemplates, die auch komplexe Filter einfach und übersichtlich ermöglichen
  • Search/Replace via Regular Expressions
  • Mehrere Datenbankverbindungen gleichzeitig möglich – inkl. Kopieren/Verschieben von Elementen einer Datenbank zur nächsten.
  • Autocomplete für viele Eigenschaften
  • Cronkintegration möglich, um von Hosts in der Icinga Host/Service Ansicht direkt zu ihrem Pendant im LDAP Baum zu springen

Serverseitig wird nur PHP5, Icinga-Web und das php_ldap Modul benötigt und schon kann man seinen Directory-Server vom Browser aus Verwalten.
Heruntergeladen werden kann auch dieses Modul ab sofort auf netways.org.