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

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet 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.

Monthly Snap November > Icinga 2 Director, OSMC, HW group Updates, AVTECH, Request Tracker, Foreman, Ceph, Git, Icinga 2 API, Braintower

SnspIn November, Thomas Gelf began with announcing the Icinga Director 1.2.0 release.

Isabel informs about new HW group Updates and the new Firmware for AVTECH Room Alert 3E.

Then Julia H. said thank you to our OSMC sponsors and wrote about why to join the OSMC Hackathon

Jennifer told us why we visualize while Markus Waldmüller presents the auto-provisioning with Foreman

Furthermore, Michael reviewed the PuppetConf in San Diego and told why Git Squash is magic.

Christian announced our availability of Request Tracker starter packages and Martin K. informed what to know about the Puppet Enterprise 3.8 End of Life

Towards the end of November, Tobias gave an Icinga 2 API Cheat Sheet, while Tim gave a Ceph training review.

Finally, Isabel wrote about the new Braintower Software and Updates.

 

 

Julia Hackbarth

Autor: Julia Hackbarth

Julia ist seit 2015 bei NETWAYS. Sie hat im September ihre Ausbildung zur Kauffrau für Büromanagement gestartet. Etwas zu organisieren macht ihr großen Spaß und sie freut sich auf vielseitige Herausforderungen. In ihrer Freizeit spielt Handball eine große Rolle: Julia steht selbst aktiv auf dem Feld, übernimmt aber auch gerne den Part als Schiedsrichterin.

Icinga2 & LSW

Ich musste feststellen das man mit dem Linux Subsystem for Windows auch Icinga2 + Icingaweb2 auch zum laufen bringen kann auf einem Windows.

Also hier mein kleiner Erfahrungsbericht:

Es galt erstmal heraus zufinden welches Ubuntu in dem Subsystem verwendet wird.

Dazu verwenden wir folgendes Kommando:

# lsb_release -a

selection_019

Nun installieren wir erstmal Updates:

# sudo -i && apt-get update
gefolgt von eurem PW und dann dem Update:

selection_020

Als nächstes installieren wir das Icinga2 Repo fuer die anstehende installation von Icinga2.

# add-apt-repository ppa:formorer/icinga && apt-get update

selection_022

Nun legen wir mit der Datenbank los:

# apt-get install mariadb-server mariadb-client -y

Es muss hiernach das Passwort für den MySQL Root Benutzer angelegt werden.

# /etc/init.d/mysql start
# mysql_secure_installation

Login zu Mariadb:

# mysql -p
Anlegen der Icinga-IDO Datenbank:

selection_027

# create database icinga;
Festlegen des IDO Benutzers:

# grant all on icinga.* to 'icinga'@'localhost' identified by 'icinga';
# apt-get install nagios-plugins-all -y

Damit haben wir die Plugin-Checks installiert aber es fehlt uns noch der Webserver :

Dem widmen wir uns nun :

# apt-get install apache2
gefolgt von der simplen installation von icinga2;

# apt-get install icinga2

selection_031

Wir starten nun erstmal den Icinga2 Service:

# /etc/init.d/icinga2 start
Nun brauchen wir natuerlich auch den Rest 🙂

# apt-get install icingaweb2 icingacli icinga2-ido-mysql
Nach dem die Installation durchgelaufen ist editieren wir erstmal die IDO Konfig Datei:

selection_034

# vi /etc/icinga2/features-enabled/ido-mysql.conf
und kommentieren alle wichtigen eintraege ein und ändern Sie ggf. ab.

Wir müssen auch noch die die php.ini editieren:

# vi /etc/php5/apache2/php.ini
Wir suchen darin nach date.timzezone und tragen hier eine Sinnvolle Zeitzone ein.

apt-get install php5-gd php5-imagick

gefolgt von :

# /etc/init.d/httpd restart
Auch ein enablen der Commandpipe ist notwendig:

# icinga2 feature enable command
Fuer das Webfrontend benoetigen wir einen setup token

# icingacli setup token create
Der Webserver läuft schon , wir oeffen im Edge die folgende adresse https://127.0.0.1/icingaweb2/setup

und benutzen den angeforderten Token.

Wir fuellen das Setup Sinnvoll aus 🙂

Ausserdem muss ggf. die iptables firewall eingetragen werden:

# iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

selection_054

Und erhalten zum Schluß ein laufendes Icinga2 welches im LSW installiert ist.

Ich hoffe ihr hattet bischen Spaß beim dem nachvollziehen oder nachbauen.

Ich freue mich über Feedback jeglicher Art.

Gruß

David

David Okon

Autor: David Okon

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

MesosCon Europe

Dieses Jahr findet die MesosCon Europe in Amsterdam statt. Neben schönem Wetter und einer tollen Stadt erwartet uns ein breites Programm rund um das Apache Mesos Framework.

Mesos selbst ist ein Cluster Framework zur Verwaltung der im Rechenzentrum zur Verfügung stehenden Ressourcen (z.B. CPU, Ram, Storage). Ein Scheduler in Mesos bietet diese Ressourcen verschiedensten Applikationen an und startet diese. Insbesondere im Containerumfeld bietet Mesos in Kombinationen mit Marathon (ein Mesos Plugin) viele Möglichkeiten seine Applikationen zu verwalten.

Die kürzlich veröffentlichte Version 1.0 ist natürlich ein großes Thema. So bietet Mesos jetzt neben einer neuen HTTP API auch einen unified containerizer zum Starten verschiedener Container Formate. Auch im Networking Bereich bietet die neue Version neue Features, vor allem die Möglichkeit eine IP je Container zu vergeben gehört zu den Highlights. Nicht zuletzt wird der Release von einem neuen Autorisierungsmodell abgerundet.

Das breit angelegte Programm bietet in den nächsten zwei Tagen Vorträge zu vermutlich allen Themen rund um Mesos, Marathon, Microservices, Service Discovery, Storage, DC/OS und mehr, aber natürlich geben auch namhafte Firmen wie Twitter und Netflix Einsicht in ihre Setups, bei denen natürlich Mesos die Microservices verwaltet.

Ein Hackathon am Freitag lässt die Konferenz schön ausklingen. Leider geht es für uns vorher schon zurück nach Nürnberg.

Achim Ledermueller

Autor: Achim Ledermueller

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Ist schon wieder Webinar Zeit?

netways Auch in der Hitze des Sommers gibt es natürlich weiterhin Bedarf an diversen IT-Dienstleistungen wie Outsourcing, Hosting, Monitoring, Configuration Management und natürlich allem voran Umweltüberwachung.

In den kommenden Monaten wollen wir genau diese Themen in unseren Webinaren ansprechen und – sofern möglich – anhand von Live-Demos veranschaulichen. Die nächsten Termine stehen dabei schon fest:

Titel Zeitraum Registrierung
NETWAYS Cloud: Der Weg zur eigenen VM 15. Juli 2016 – 10:30 Uhr Anmelden
Foreman: Berechtigungen 28. Juli 2016 – 10:30 Uhr Anmelden
Umweltüberwachung im Rechenzentrum 04. August 2016 – 10:30 Uhr Anmelden
SMS Alarmierung einrichten 25. August 2016 – 10:30 Uhr Anmelden
Foreman: Docker Integration 05. Oktober 2016 – 10:30 Uhr Anmelden

Alle unsere Webinare zeichnen wir auf, damit diese auch nachträglich noch einmal angesehen werden können. Hinterlegt werden Sie dann in unserem Webinar-Archiv.

Christian Stein

Autor: Christian Stein

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Docker-Registry und das Geheimnis des Löschens

DockerLogo

Wenn man sich dazu entschließt, eine Docker-Registry zu installieren und zu konfigurieren, möchte man Images zentral abspeichern und verwalten können. Dies bietet viele Vorteile für den abteilungsübergreifenden Einsatz von Docker, aber auch ein paar Komplikationen im Umgang mit der Registry.
Wenn man mit dieser Registry arbeitet, entsteht irgendwann folgendes Problem. Das Löschen von Images funktioniert nicht wirklich.

Der Server ist fertig konfiguriert und man übermittelt Images an die Registry.
Der Speicherplatz wird zunehmend belegt, es liegen veraltete Images im Storage, die nicht mehr benötigt werden. Laut der Dokumentation von Docker, soll dieses Problem dadurch gelöst werden, dass man über die API Images “ganz einfach” löschen kann:

curl -k -X DELETE https://localhost:5000/v2/$imagename$/manifests/latest

Jedoch werden sich viele dann über diese (oder ähnliche) Fehlermeldung(en) ärgern:

{"errors":[{"code":"INVALID_DIGEST","message":"The digest is invalid"}]}

Laut Dokumentation, kann ein Image über die API nur dann gelöscht werden, wenn es durch den Namen und die Referenz(Tag, zum Beispiel “latest”) identifiziert werden kann, jedoch nur mittels “Digest”.
Ein Digest ist ein Wert um ein Image eindeutig identifizieren zu können. Er wird beim zum Beispiel bei einem Pull oder Push angezeigt. (Achtung! Der Digest ist nicht die Image ID, die beispielsweise bei einem “docker images” Command angezeigt wird.)

docker pull ubuntu
(...)
93f3596230c2: Pull complete
c06698a70f80: Pull complete
b6ea91fdc1f6: Pull complete
a53404c22cd2: Pull complete
Digest: sha256:c9f94277901034f3f40e73c861aee970da33dce9af2c02f13e1a4a72cdc0f8cb

Das Problem ist nun, dass der oben genannte DELETE nicht funktioniert. Eine kritische Alternative hierfür ist, auf der Commandline das Verzeichnis zu löschen

rm -rf ubuntu

Das Problem hierbei wären die Blobs, die als “Leiche” zurück bleiben würden. Wieso dies kritisch ist, möchte ich kurz versuchen zu erklären:
Jedes Image, besteht aus mehreren Layern, wobei die Layer aufeinander aufbauen. Der oberste Layer bekommt einen Tag (zum Beispiel “latest”). Blobs sind “BlobSums” (Digest) für die einzelnen Layer. Die einzelnen Layer sind wie der Digest des kompletten Images bei einem Pull, Push oder einem Api Request ersichtlich.

"schemaVersion": 1,
"name": "ubuntu",
"tag": "latest",
"architecture": "amd64",
"fsLayers": [
{
"blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4"
},
{
"blobSum": "sha256:a53404c22cd2ac9f68c352d17667ec1a2e36f22ca729983c40e1f24c106def6f"
},
{
"blobSum": "sha256:b6ea91fdc1f68eb0274174fd8c4eeea4baeee4986c942cbc7a21be82778e78b3"
},
{
(etc)

Beim Push in die Registry wird im Verzeichnis “blob” ein Eintrag für jeden Layer angelegt, mit der jeweiligen BlobSum. Löscht man nun ein “Image” aus der Registry, werden nur die Daten des Images gelöscht die im Verzeichnis “v2/repositories/$IMAGENAME” liegen. Auf den ersten Blick ist das Image gelöscht, denn in der Registry wird es nicht mehr als verfügbares Images zum Pull angezeigt. Die restlichen Layer jedoch und somit auch die Blobs, bleiben bestehen, womit sehr viel Speicherplatz mit nicht nutzbaren Daten belegt wird. Auch andere, von Docker erstellte Abhängigkeiten werden so nicht gelöscht. Das Problem ist dann, dass das Pushen des selben Images zurück in die Registry fehlerhaft sein wird, da versucht wird, Layer zu pushen, die schon hinterlegt sind und zu einem Image gehören aber nicht mehr zuordbar sind.

Komplizierter würde es werden, wenn man zum Beispiel nicht nur ein Image löschen möchte, sondern beispielsweise alle “untagged Images”. Dies sind veraltete Images, ohne einen Tag. Dies geschieht beispielsweise bei einem Push eines Images mit dem gleichem Namen.

Will oder kann man die Images nicht über die API löschen bietet “Burnettk” auf GitHub mit einem kleinen Skript eine gute Alternative.
Es handelt sich hier um ein Script, das ein Image anhand des Names identifiziert, und alles dazugehörige löscht. Was hierfür nötig ist, ist eine Environment Variable, die auf das Reporitory gesetzt wird. Als Beispiel:

export REGISTRY_DATA_DIR=/opt/registry_data/docker/registry/v2

Dannach kann das Script als normales Command genutzt werden. Um alle untagged Images zu löschen, kann man mit einer kleinen Schleife arbeiten, die innerhalb des Repoitory Verzeichnisses läuft:

for i in *; do delete_docker_registry_image --untagged --image $i; done;

Wenn man in diesem Verzeichnis, Images in einem weiteren Unterverzeichnis abspeichert, muss das Script kopiert und angepasst werden:

repositories_dir="repositories/$UNTERVERZEICHNIS"

An dieser Stelle bietet es sich auch an, diesen Löschvorgang in Form eines Crons zu automatisieren. Das Problem, dass die Registry zu wenig Speicherplatz frei hat, wäre so gelöst. Vielleicht kommt von Docker in den nächsten Docker-Engine Versionen eine brauchbare Lösung mit, jedoch ist das für mich die bisher beste Lösung.
dockerDocker, Docker, Docker!

Marius Gebert

Autor:

Marius ist seit September 2013 bei uns beschäftigt. Er hat im Sommer 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und kümmert sich nun um den Support unserer Hostingkunden. Seine besonderen Themengebiete erstrecken sich vom Elastic-Stack bis hin zu Puppet. Auch an unserem Lunchshop ist er ständig zu Gange und versorgt die ganze Firma mit kulinarischen Köstlichkeiten. Seine Freizeit verbringt Marius gern an der frischen Luft und wandert dabei durch die fränkische Schweiz