Foreman-Training nun auch mit Ansible und Monitoring-Integration

English version below
Foreman-Logo
Es ist nun bald anderthalb Jahre her, dass ich die Trainingsunterlagen veröffentlichen durfte, die in Zusammenarbeit mit dem Foreman-Projekt und dort auch als offizielles Training aufgeführt sind. In der Zeit hat sich im Projekt selbst aber auch vor allem an den Plugins viel getan. Auch konnte Feedback in offiziellen und Inhouse-Schulungen sowie Workshops gesammelt werden. Um dem Rechnung zu tragen versuche ich die Schulung regelmäßig zu aktualisieren und zu erweitern.
Foreman training presentation
Nachdem es sich bei dem Update diesmal um ein größeres handelt, dachte ich mir, ich fasse es mal in einem Blogpost zusammen. Diesmal habe ich es gewagt und statt wie bisher auf eine bereits länger veröffentliche Version auf den Release Candidate für 1.16 gesetzt, da mit diesem Support für Puppet 5 kommt. Auch wenn ich nicht über den höheren Ressourcenbedarf von Puppet 5 begeistert bin, da er deutlich höhere Anforderungen an unsere Schulungsnotebooks stellt, war es auch Zeit der Entwicklung hier Rechnung zu tragen und somit ist in den Schulungen ab sofort Puppet 5 der Standard. Wenn ich gerade von Konfigurationsmanagement rede, kann ich auch gleich die erste große Neuerung präsentieren und zwar ist nun auch die Ansible-Integration Teil der Schulung. Dies ist dem Interesse geschuldet, das sich sowohl in Anfragen in allen Bereichen bei NETWAYS, dem Interesse der Kollegen und auf den Foreman-Mailinglisten sowie auf dem Foreman-Geburtstag gezeigt hat.
Die zweite große Erweiterung ist die Monitoring-Integration, auf die ich persönlich sehr stolz bin. Allein in die Vorbereitung der Übung floss hier einiges an Zeit um den Schulungsteilnehmern ein möglichst gutes Trainingserlebnis zu gewährleisten. Den Neuerungen im OpenSCAP-Plugin wurde mit einer optionalen Übung Rechnung getragen. Optional damit es keine Zeit frisst, wenn bei Schulungsteilnehmern kein Bedarf besteht, aber gerade mit den Tailoring-Files lässt sich eine OpenSCAP-Policy sehr gut und einfach auf den eigenen Bedarf anpassen. Bereits beim letzten Update hatte ich das Plugin “Expire Hosts” hinzugefügt, da ich in vielen Kundenumgebungen entsprechende Anforderungen ausmachen konnte. Leider musste ich das ABRT-Plugin zumindest temporär rausnehmen, da dieses erst aktualisiert werden muss um wieder mit Foreman bzw. dem Smart-Proxy kompatibel zu sein.
(mehr …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Foreman's 8th birthday – How was the party?

Foreman logo
As you may remember we gave the Foreman Project another party to celebrate its 8th birthday, so now it is time for a small recap.
At 12:30 I welcomed a group of about 20 people for the event coming mostly from Southern Germany, but with Ewoud Kohl van Wijngaarden coming down from the Netherlands we had again at least one international guest. Afterwards we started with the hands-on session. This session was planned as a completely open session, so some discussions and hacking started while others played around with the demo systems I prepared. In addition to the basic setup containing several ways of provisioning, Puppet for configuration management and some plugins like OpenSCAP, Remote Execution and Expire Hosts one demo setup included the Monitoring Plugin, so Host provisioning included adding them to Icinga Web 2 Director and monitor them. Another one had added Docker integration, CoreOS provisioning and updating via Foreman’s Omaha Plugin. The third one was installed using nightly builds of Foreman and the plugins to demonstrate Puppet 5 and Ansible. The last demo was showing Katello and its Lifecyclemanagement. I think every system has created some interest but this year the most persons were interested in Ansible and Monitoring Integration, followed by Lifecyclemanagement and OpenSCAP.
Foreman Event 2017 - Start
I tried to get the talks in a reasoned order, so Michael Moll started with his talk “The last year in Foreman” which gave a nice look inside last year’s development and changes and some hints on future improvements. The second speaker was Timo Goebel with “Foreman – Advanced Use Cases” who had many ideas what he could talk about from his experience at dm/filiadata, but in the end he demonstrated how to deploy a CoreOS cluster including update management via the Omaha Plugin he created. Third talk was “Refactoring Katello Installer modules” by Ewoud Kohl van Wijngaarden who is constantly improving the quality of the Puppet modules used by the Foreman, Katello and the Kafo installer. I and probably many others will be really happy when he reaches his goal to allow a distributed setup of Katello and users being capable of upgrading Foreman to Katello. Last but not least Evgeni Golov explained some lessons learned and showed possible problems he come across while migrating a big environment to Red Hat Satellite 6 (the Red Hat branded version of Katello) in his talk “Mass-Migration of 5000 Servers to Foreman/Katello with bootstrap.py”.
Foreman Event 2017 - Evening
The casual part started afterwards with beer and pizza but it did not stop nice and productive discussions from going on. From the feedback I got all attendees enjoyed the event like I did and everyone took some additional knowledge and ideas with him when I closed the door 3 hours later. So I think you can look forward for next year and Foreman’s 9th birthday. If you can not wait, our next Foreman training is already end of September.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Foreman räumt auf

Foreman Logo
Dank Virtualisierung und automatischer Provisionierung sind schnell und einfach Entwicklungs- und Testsysteme zur Verfügung gestellt und jeder bestellt fleißig neue Systeme, aber wie viele melden sich dann wirklich zurück wenn ein System nicht mehr gebraucht wird? Aus meiner Erfahrung heraus möchte ich behaupten die wenigsten tun dies. So kommt es, dass Ressourcen reserviert sind und brach liegen oder schlimmer noch tatsächlich belegt aber nicht mehr wirklich genutzt werden. Manuelle Aufräumaktionen treffen dann entweder zu wenig oder zu viele Systeme und kosten zu viel Zeit und Nerven. Wie schön wäre es wenn man die Kollegen erziehen könnte? Da es mit den Kollegen wohl nicht klappen wird, erziehen wir stattdessen unsere Umgebung und zwar mit dem Plugin “Expire Hosts” für Foreman.
Die Installation übernimmt wie mittlerweile bei fast allen Plugins der Foreman Installer und danach können wir auch direkt konfigurieren wie Systeme zukünftig von diesem Plugin behandelt werden sollen.
Foreman Expire Hosts Settings
Wie man sieht kann man drei Zeiten einstellen und zwar wann die erste und zweite Benachrichtigung relativ zum Ablaufdatum erfolgen soll und nach wie viel Tagen es nach Ablauf gelöscht werden soll nachdem das System am Ablaufdatum heruntergefahren wurde. Außerdem kann eingestellt werden, ob der Besitzer des Systems oder nur der Administrator das Ablaufdatum nachträglich ändern darf und ob die Angabe eine Pflicht ist. Wer dies als Administrator will kann sich auch auf die Liste der zusätzlichen Email-Empfänger setzen, da sonst nur der Besitzer benachrichtigt wird.
Wenn die allgemeinen Einstellungen nun passen erhält jeder Host ein Eingabefeld zur Einstellung seines Ablaufdatums unter den zusätzlichen Informationen.
Foreman Expire Hosts Host
Zusätzlich zur Email-Benachrichtigung zeigt Foreman auch noch im Webinterface den Status an und warnt auch hier vor dem Ablauf.

Foreman Expire Hosts OkForeman Expire Hosts Warning

Zwar ist das Plugin primär für virtuelle Maschinen gedacht, funktioniert aber auch bei physikalischen Systemen. Wenn Foreman das Powermanagement für diese steuern kann, fährt es diese auch herunter. Wenn nicht weiß der Administrator zumindest, dass das System zum Herunterfahren und Löschen freigegeben ist.
Ich denke mal für dieses Plugin finden so einige Administratoren einen sinnvollen Anwendungsfall, weshalb ich es auch neben vielen weiteren Plugins in die Foreman-Schulung aufgenommen habe.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Orchestration mit Foreman

Foreman Logo
Ich möchte heute mal wieder ein Plugin vorstellen, das Foreman um eine neue Funktionalität erweitert. Diesmal handelt es sich um das Plugin “Remote Execution” and die Funktionalität möchte ich mal “Orchestration” nennen.
Nachdem sich unter dem Begriff Orchestration jeder was anderes vorstellt und es mindestens zwei verschiedene Ansätze in der IT gibt, möchte ich mit einer kleine Definition und Abgrenzung anfangen. In diesem Fall verstehe ich unter Orchestration die zentrale Steuerung von Jobs, sowohl zum direkten als auch zeitgesteuerten Ausführung auf den angebundenen Systemen. Der zweite Aspekt zentrale Steuerung von Jobs auf verschiedenen Systemen mit Abhängigkeiten zu einander wird hier leider nicht bedient. Das Plugin unterstützt einen Administrator somit darin beispielsweise allen Systemen ein Update-Kommando zu schicken, um die Logik das jeweils nur ein Knoten im Cluster gleichzeitig gemacht werden soll muss er sich also weiterhin kümmern.
Aber fangen wir doch einfach von vorne mit der Installation an. Diese erfolgt am einfachsten mit dem Foreman-Installer, welcher die Puppet-Module des Projekts verwendet. Wenn man diesen Installationsweg nimmt und auch gleich den Provider “SSH” dazu nimmt, bekommt man gleich alles fertig eingerichtet. Dies heißt es gibt dann einen SSH-Key auf dem Smart-Proxy, der per Snippet direkt auf neuen Systemen als “Authorized Key” für “root” deployed wird. Um bestehende Systeme muss sich noch gekümmert werden, aber dies übernimmt das Konfigurationsmanagement gerne. Wer hier nicht mit “root” arbeiten will oder darf, kann dem Plugin auch einen anderen Anmeldebenutzer, effektiven Benutzer zur Ausführung und die Methode zum Wechseln zwischen diesen konfigurieren. Wem “SSH” als Provider nicht gefällt, kann sich bereits den Entwicklungsstand des “Ansible“-Providers anschauen, für die Zukunft sind noch weitere Provider wie “Salt” oder “MCollective” geplant.
Im Webinterface von Foreman erhält man nun die Option Jobs auszuführen. Ich empfehle den Weg über die Hostliste, um mehrere Host auszuwählen und dann für alle eine “Run Job”-Action auszulösen. Für den Power-User funktioniert auch der direkte Einstieg über die Job-Maske und mit eine Suchbedingung wie alle Systeme mit einer bestimmten Betriebssystemversion oder alle Produktivsysteme.
Job Invocation
Nachdem ein Job eingeplant wurde, wird dieser im Hintergrund über das Foreman-Task-Plugin ausgeführt und man kann für jeden Job die Ausführung sehen, so dass man weiß auf wie vielen System der Job noch ausgeführt werden muss, schon erfolgreich oder mit Fehlern gelaufen ist.
Job Result
Auch der Output jedes einzelnen Systems kann nachgeschaut werden, so dass man sieht warum ein Job fehlgeschlagen ist oder auch bei erfolgreicher Ausführung natürlich was genau passiert ist.
Job Output
Die ausführbaren Kommandos basieren auf Job-Templates ähnlich den Provisioning-Templates. Neben dem generischen Kommandos sind bereits Templates zum Softwaremanagement, Powermanagement, Steuerung von Diensten und der Interaktion mit Puppet vorbereitet. Zusätzlichen können natürlich eigene Templates erstellt werden, inklusive den Eingabemasken mit Validierung.
Neben der sofortigen Ausführung lassen sich Jobs auch zeitgesteuert einplanen. Hierbei wird angegeben wann frühestens aber auch wann spätestens der Job ausgeführt wird. Außerdem können auch wiederkehrende Jobs im gleichen Stil wie Cronjobs eingeplant werden.
Alles in allem ist für mich das “Remote Execution”-Plugin eine echte Bereicherung für Foreman und der logisch nächste Schritt nach Provisioning und Konfigurationsmanagement, weshalb es auch Teil der Foreman-Schulung geworden ist. Von SSH als Provider bin ich allerdings noch nicht überzeugt und will mir mit dem Wissen aus unserer Ansible-Schulung auch mal diesen Provider im Detail anschauen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Compliance Reports in Foreman

Foreman Logo
Ein Steckenpferd von mir ist Security und ich habe mich daher schon vor einer ganzen Weile auch mit OpenSCAP beschäftigt, um umgesetzte Sicherheitsmaßnahmen auch zu visualisieren und regelmäßig auf Compliance zu prüfen. Mein damaliger Workflow bestand dann noch aus Cronjobs, Monitoringplugin und selbstgestricktem Dateiupload, doch nun nimmt mir auch hier Foreman die Arbeit ab.
Doch einmal langsam und von vorne: Was ist OpenSCAP eigentlich? SCAP ist die Abkürzung für Security Content Automation Protocol. Dieses baut auf bereits etablierten Standards auf um sicherheitsrelevante Software-Fehler und Konfigurationsprobleme darzustellen und bringt diese in eine Form, die eine automatisierte Auswertung ermöglicht. OpenSCAP ist eine OpenSource-Implementierung dieses Standards und liefert beispielhafte Richtlinien für verschiedene Linux-Distributionen und Anwendungen wie Java oder Firefox, Werkzeuge zur Überprüfung und Anpassung der Richtlinien an Firmenvorgaben.
Diese Werkzeuge macht sich das Foreman-Plugin OpenSCAP zu Nutze um Compliance Reports zu integrieren. Prinzipiell besteht es aus drei Komponenten. Das eigentliche Plugin erweitert Foreman um die Möglichkeit SCAP-Regelwerke im Datastream-Format hochzuladen, im Anschluss darin enthaltene Profile Hostgruppen zuzuweisen, eine Anleitung für den Administrator zu erzeugen und zu guter Letzt die Reports der Systeme anzuzeigen. Die Kommunikation läuft hierbei über den Smart Proxy, der ebenfalls durch ein Plugin erweitert wird, das den Download der Profile und den Upload der Reports ermöglicht. Zur Konfiguration der Systeme kommt Puppet zum Einsatz wofür ein entsprechendes Modul zur Verfügung steht.
Das ganze sieht dann so aus:
OpenSCAP-Guide in Foreman
Foreman-OpenSCAP-Guide
OpenSCAP-Report in Foreman
Foreman-OpenSCAP-Report
Ergebnis inklusive Lösungsvorschlag im OpenSCAP-Report in Foreman
Foreman-OpenSCAP-Result
Wie man allerdings auf den Bildern sieht habe ich mir keine Mühe gegeben mein eigenes Demosystem weiter abzusichern. Nun könnte ich entweder die angemeckerten Missstände beheben oder ich nehme mir aus dem OpenSCAP-Projekt die SCAP-Workbench und schneidere mir mein eigenes Profil zurecht. Auch dies geht sehr simpel und graphisch, nur wenn neue Definitionen und Checks geschrieben werden müssen wird es komplizierter.
SCAP-Workbench
Wer sicherstellen will, dass seine Systeme bereits von Anfang an sicher installiert sind und auf Fedora, Red Hat Enterprise Linux, CentOS oder ein anderes Derivat setzt, kann hierfür sogar ein Plugin für den Installer Anaconda nutzen.
Anaconda-OpenSCAP
Mir hätte damals ein solcher Satz an Werkzeugen viel Arbeit abgenommen, daher hoffe ich zumindest einigen der Lesern etwas an die Hand gegeben zu haben um eine weitere Anforderung an ihre Umgebung zu lösen. Neben diesem gibts auch noch weitere Plugins die Foreman um ein vielfaches mächtiger machen, einen Teil davon auch in unserer Foreman-Schulung.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Softwaremanagement – Katello

Katello Logo
Da ich regelmäßig auf die Wichtigkeit von Softwaremanagement im Zusammenhang mit Konfigurationsmanagement verweise, mich zumindest mit Packaging in Form von RPMs häufig auseinandersetze und auch schon der Softwarelösung Spacewalk bzw. Red Hat Network Satellite 5 befasst habe, liegt es nahe mich auch mit Katello zu befassen. Insbesondere da dies ein Foreman-Plugin ist und auch das Upstream-Projekt zum Red Hat Network Satellite 6 ist.
Katello bündelt hierbei mehrere Anwendungen und integriert diese in die Foreman-Oberfläche. Namentlich sind dies Pulp für das eigentliche Softwaremanagment und Candlepin für das Subskriptionmanagement, welche dann wiederum ihre eigenen Abhängigkeiten wie etwa Gutterball für das Zertifikatsmanagement mitbringen. Schaut man sich die Abhängigkeiten an, ist man ganz froh, dass der Katello-Installer die komplette Konfiguration für einen übernimmt und man nicht jede Komponente einzeln installieren muss. Der Installer ist hierbei stark parametrierbar, da im Hintergrund Puppet-Code verwendet wird und die in diesem verwendeten Parameter über den Installer gesetzt werden können.
Nach der Installation erhalte ich also einen vollwertigen Foreman mit zusätzlichen Snippets für die Anbindung an das Softwaremanagement. Dieses kann aus zwei Richtungen betrachtet werden. Zum einen den Hosts welche als sogenannte Content-Hosts auftauchen, was es ermöglicht Software-Repositories zuzuweisen, installierte Software abzufragen und wenn der entsprechende Agent auf dem System installiert ist sogar Softwareinstallationen und -updates aus der Weboberfläche heraus zu steuern.
Katello Content-Host
Natürlich geht dies nicht nur für einzelne Hosts sondern es lassen sich auch mehrere auswählen oder vordefinierte Sets in Form von Host Collections bilden.
Zum anderen gibt es den weit größeren Teil zum Management von Software. Hierbei hat man die Möglichkeit verschiedene Produkte zu definieren, welche dann auch wiederum aus verschiedenen Repositories bestehen. Somit ist es kein Problem sich beispielsweise die Icinga-Repositories in all ihrer Pracht lokal zu spiegeln. Einen eigenen Bereich bilden die Red Hat Repositories, wobei sich hier Subskription- und Softwaremanagement mischen, aber auch diese lassen sich mit dem Manifest aus dem Red Hat Network mit wenigen Mausklicks spiegeln. Die Synchronisation lässt sich hierbei über Pläne steuern, die auch direkt in der Oberfläche erstellt werden. Wirklich mächtig wird das ganze dann durch Content Views, die es erlauben feste Zusammenstellungen von Paketen zu erstellen und sich auch einfach in einander verschachteln lassen, und Livecycle-Environements, welche dann Content Views über die verschiedenen Stages wie Entwicklung, Test und Produktion hindurch bekannt macht. Somit ist es ein leichtes in Produktion nur getestete Updates einzuspielen!
Die Benennung Content View kommt übrigens daher, dass der gleiche Mechanismus auch für Puppet-Code und Docker-Container funktioniert. Letztere habe ich allerdings bisher nicht getestet, für Puppet-Code ist dieses Feature ganz nett, aber nur wenn man hier keine hohe Dynamik braucht. Wenn dies eine Anforderung ist, insbesondere auch für den Einstieg in Puppet, empfehle ich daher zumindest für Puppet die Content-Views zu ignorieren und normale Enviroments zu nutzen. Die Content-Views sind aber flexibel genug um auch mal ein Sicherheitsupdate schnell in alle Stage zu promoten.
Vom Host aus betrachtet sehen Content-View und Lifecycle-Environment dann folgendermaßen aus:
Katello System Content-View
Das Subskription-Management wird die meiste Zeit wohl nur genutzt werden um sich gegen Red Hat entsprechend rechtlich sauber aufzustellen. Diese bieten hierbei dann auch eine Lösung virt-who für ihre virtuellen Subskriptions bei denen der Host subskripiert wird und damit die Nutzung beliebig vieler virtueller Installationen erlaubt. Aber auch die interne Nutzung eröffnet viele Möglichkeiten. Für Katello ist standardmäßig das Organisation/Location-Feature von Foreman aktiv, so dass die Subskriptions auf die einzelnen internen Bereiche aufgeteilt werden können. Außerdem können auch selbst erstellte Produkte entsprechend limitiert werden, will man verhindern das beispielsweise kostenpflichtige Software überall installiert wird oder dass ein Wildwuchs an zum Beispiel Icinga-Installationen entsteht.
Klingt alles gut? Find ich auch! Allerdings möchte ich nicht ein paar Nachteile verschweigen. Zum einen ist das Produkt noch relativ jung und es finden sich immer noch Kinderkrankheiten, zum anderen treibt so eine Lösung die Komplexität nach oben. Außerdem lassen sich aktuell nur RPM-basierte Systeme verwalten, zumindest bis die Entwicklung bei Pulp-Debian weiter vorangeschritten ist. Hier hat Spacewalk noch die Nase vorn, allerdings gefällt mir Content-View und Lifecycle-Environment sehr gut, was beim Spacewalk alles noch individuell geskriptet werden muss. Auch kann Spacewalk nicht nur das Softwaremanagement fernsteuern, sondern beliebige Befehle absetzen, aber auch hieran arbeitet das Foreman-Team.
Wer also noch eine Lösung dieser Art sucht, sollte sich Katello oder auch den Satellite 6 definitiv mal ansehen. Wer schon eine Lösung hat und mit dieser zufrieden ist, sollte die Entwicklung zumindest verfolgen bis Kinderkrankheiten beseitigt und letzte Features implementiert wurden. Und falls wer zwar schon Softwaremanagement, aber noch kein Provisioning und Konfigurationsmanagement hat, sollte sich Foreman anschauen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Deployment, aber bitte ohne PXE

Foreman Logo
Es ist schon eine Weile her, dass ich zum Foreman Discovery-Plugin geschrieben hab. Dieses zählt immer noch zu den von mir am meisten genutzten Plugins und wäre mit seinen Neuerungen wie Discovery-Regeln und erweiterbaren Images sicher auch einen neuen Blogpost wert. Aber die häufigste Frage, die mir in dem Zusammenhang gestellt wird, ist “Ich kann/darf unsere DHCP-/PXE-Konfiguration nicht anpassen. Geht das auch ohne PXE?”.
Natürlich kann ich das Discovery-Image auch einfach lokal starten, aber ich möchte eine weitere Lösung in Form des Bootdisk-Plugins für Foreman vorstellen. Dieses bietet zwar nicht die Funktionen wie Discovery-Regeln und darauf basierendes automatisches Deployment, hat aber den Vorteil auch komplett ohne DHCP und TFTP auskommen zu können.
Die Installation ist einfach, da es sowohl für RPM-basierte als auch Deb-basierte Systeme als entsprechendes Paket vorliegt. Nach der Installation einfach noch Foreman durchstarten und es findet sich ein neuer Menü-Paket “Boot disk” auf der Host-Ansicht. Dieser lässt es zu drei verschiedene Arten Installationsabbilder herunterzuladen. Voraussetzung sind hierfür die iPXE-Templates, die allerdings standardmäßig mitgeliefert werden.
Für Umgebungen in denen zwar DHCP genutzt werden kann, aber weder feste Reservierungen noch eine Anpassung der PXE-Konfiguration möglich ist, bietet sich das generische Installationsabbild an. Dieses enthält in ungefähr einem Megabyte Größe nur den Teil der notwendig ist um sich bei Foreman mit einer MAC-Adresse zu melden und die gewünschte Konfiguration zu erfragen. Danach wird der Installer für das entsprechende Betriebssystem aus dem TFTP-Verzeichnis von Foreman heruntergeladen und die Installation anhand von Kickstart, Preseed, etc. beginnt.
Für Umgebungen in denen gar kein DHCP zur Verfügung steht, können individuelle Boot-Medien heruntergeladen werden, die eine statische Netzwerkkonfiguration für die Installation enthalten. Nachdem von diesem gestartet wurde, wird wieder alles weitere nachgeladen und die Installation beginnt.
In Umgebungen oder auf Hardware bei der auch das Nachladen des Installers nicht klappt, können die individuellen “Full Images” verwendet werden, welche auch noch Installer und Installationsanweisungen enthalten. Dies ist natürlich die aufwendigste Variante, da das Image bei jeder Änderung neu erstellt werden muss. Wobei sich natürlich die Frage stellt wie oft der Aufwand tatsächlich betrieben werden muss.
Um nun keine Hamster-Käufe bei CD-Rohlingen auszulösen, handelt es sich bei den Installationsabbildern um hybride Images, die auch direkt auf einen USB-Stick übertragen werden können. Somit kann jeder Foreman-Nutzer dieses Plugin schnell und einfach ausprobieren und wer noch kein Foreman benutzt, aber keine Lust mehr auf manuelle Installationen hat, sollte diesem ein Chance geben. Wer sich bei der Einrichtung helfen lassen möchte, findet diese natürlich bei uns! 😉

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Metal as a Service mit Foreman

Nachdem ich mich die letzten Blog-Einträge als Liveberichterstatter für diverse Konferenzen präsentiert habe, wird es mal wieder Zeit für etwas technisches. Da ich mich für Foreman sehr begeistern kann und auch viele meiner letzten Projekte sich um das Thema drehten, soll es auch in diesem Blog darum gehen.
Bei Foreman handelt es sich um ein Frontend für Puppet, das neben der üblichen Funktionen noch Provisionierung ergänzt. Standardmäßig liefert es hierbei PXE und entsprechende Templates für die automatisierte Installation aus. Diese Templates decken hierbei mit Kickstart (Red Hat Derivate), Autoyast (SuSE), Preseed (Debian) und Jumpstart (Solaris) schon einiges ab. Will ich nun diese nutzen, muss ich einfach meinen Host anlegen, es wird für die entsprechende MAC-Adresse eine DHCP-Reservierung vorgenommen und wenn das System bootet wird es direkt installiert und konfiguriert.
Noch einfacher ist es wenn ich mittels Compute Resource direkt die benötigte virtuelle Maschine anlegen kann, da ich mir so sogar das Herausfinden der MAC-Adresse sparen kann. Diesen Luxus möchte ich natürlich auch für Hardware-Systeme und damit wäre ich auch bei meinem eigentlichen Thema angekommen: Foreman Discovery.
Bei Foreman Discovery handelt es sich um ein Plugin für Foreman. Diese sind relativ leicht installiert entweder mit yum auf einem Red Hat System oder mittels bundler auf allen anderen Systemen. Die allgemeine Anleitung findet hierfür sich im Foreman Wiki. Plugins können hierbei genauso neue Funktionen in die Foreman Oberfläche integrieren wie in jeden anderen Bereich der Anwendung.
Sobald dann das Plugin erfolgreich installiert ist taucht im Menü ein weiterer Unterpunkt Discovered Hosts unter Provisioning auf. Hier finden sich die entdeckten Hosts, denen dann ein Betriebssystem und Konfiguration zugewiesen werden kann. Der Neustart in den Installationsvorgang passiert dann automatisch direkt nach dem Abschluß der Zuweisung.
Damit die Systeme auftauchen müssen diese ein spezielles Image booten. Dieses gibt es in zwei Versionen basierend auf Tiny Core Linux und oVirt. Ersteres ist etwas schmaller, unterstützt weniger Hardware und soll deshalb zu Gunsten von letzterem abgelöst werden. Für den Produktiveinsatz sind diese ohne Remotezugang und somit einhergehende Manipulationsmöglichkeit konfiguriert, ein Testimage mit Remotezugang gibt es allerdings auch. Wem dies nicht reicht erstellt sich selbst ein Image welches er dabei nach Bedarf anpassen kann.
Mein Tipp nun noch für die Konfiguration im PXE-Menu. Hierbei bitte nicht der Anleitung auf der Plugin-Homepage folgen, sondern einen zweiten Eintrag vornehmen und den Default auf dem lokalen Boot lassen. Dies verhindert, dass irgendwann ein produktives System das Discovery-Image gebootet hat und nicht erreichbar ist. Natürlich muss dann jemand im Discovery-Fall den zweiten Eintrag auswählen, aber dies geht gegebenenfalls über Remotemanagement oder kann der Techniker direkt nach dem Einbau machen.
Somit steht auch Metal as a Service mit Foreman nichts mehr im Wege!

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.