Select Page

NETWAYS Blog

Foreman Birthday Event 2023 – Recap

Two years ago I started my recap of the event with “Last week on Thursday we had the Foreman Birthday event and I can proudly say it was a big success.” and I can do the same for this one.

At the beginning of the year planning for the event started in the background as we discussed in which form we want it to happen. While I was excited for having an in-person event, I quickly realized that travel restrictions and budget would still be a problem for many people, so we agreed on keeping it online for another round would be the best. So keep the fingers crossed for the next time.
When we finalized the date and it was time to find some speaker, a wild hunt started as many changes of the last year had come together. Some of my usual suspects had changed position or company, environments moved from the classic IT environment managed by Foreman to a cloud native approach managed by Kubernetes and similar effects made me fear I can not provide a good program. So I was even thinking about jumping in myself and give a talk as I still do not own a kettle prod to motivate colleagues. 😉 But in the end I was happy with the four talks we got as it was a good mix.

Thanks to our events team who did so many things in the background which I would have forgotten, the managed services team who provided the servers and Christian who did the streaming setup, we had the same setup like last time. And when I started to adjust the configuration of all the buttons on the stream deck I started to finally remember everything including the mixed feeling of excitement and nervousness. Nervousness reached its top when I started the introduction and was signaled people could not hear me, just to realize one button was still showing me muted while the one I looked showed unmuted. But after this everything went smooth.

Screencapture of the Youtube Stream with Countdown at 0:00

Our first speaker was Christian Stankowic who gave a nice look into his work at many customer projects in his talk “Lessons Learned – Automated installations and hints”. The first part of his talk was about Foreman and alternatives and why people decide for or against Foreman. I like it if a talk is not free of critique and Christian had some good points here even if you do not agree with all. His tips and tricks focus on automated installation and documentation, but there are also some on infrastructure design. And with all the tips given he was so kind to provide an example repository on github, too! Thanks again Christian, I was really happy I convinced you to give this talk.

The second one was Bastian Schmidt with “Provisioning Ubuntu hosts in Foreman” who was also was very involved with implementing the topic. It was a rocky road to get this up and running after Ubuntu moved from Preseed to Autoinstall with 20.04.3/22.04.1. Bastian talk showed how rocky it was and also how good the community was in tackling it. And his talked ended with a demo showing the next improvement currently in the making. Thanks again Bastian for the talk and even more for the hard work on this feature!

Screencapture of the Youtube Stream during the Live Q&A with Bastian Schmidt

Ewoud Kohl van Wijngaarden did his talk live as he just finished it last minute, but this also worked great. In “foreman-documentation: rethinking our documentation” we heard about past, present and future of the Foreman’s documentation. If you have not heard about before the new documentation started as the documentation for Red Hat Network Satellite which was given to the Foreman Project to make this a true open source project with upstream and downstream. From this it was a huge community effort to adapt this for Foreman and Katello while creating a good base not only for the Satellite but also Orcharhino. And now the next step is to get rid of the manual and make it the one documentation. Thanks to Ewoud and all those involved in creating and improving the documentation.

And last but not least we had Samir Jha who demoed the updates from the Katello content team. As an addition Ian Ballou had added a demo focusing on the Alternate Content Source feature and Chris Roberts did send me a demo to showcase Simple Content Access. So we finished with a great look inside the latest improvements to Katello and in the live Q&A Samir also talked about future improvements. Thanks to all of you!

In parallel and afterwards we had again the social event in workadventure which I could only join after the stream ended, but this was still enough to meet some community members. All of them were happy and gave great feedback about the event. In the end I had a quite long and productive discussion with Ewoud and Maximillian about many different topics. So I am really looking forward for the next event where I can meet this great community again!

Dirk Götz
Dirk Götz
Principal 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.

Semaphore, Rundeck oder AWX – Welches Tool eignet sich als Ansible-GUI?

Rundeck, AWX und Ansible Semaphore sind nützliche Tools zur Arbeit mit Ansible. Als Ansible-GUI lösen lösen sie die Arbeit mit Ansible von der Konsole und geben auch Fans grafischer Optionen die Möglichkeit Ansible voll auszukosten.
In meinem ersten Blogpost für NETWAYS habe ich dir bereits Ansible Semaphore vorgestellt. Dabei sind jedoch einige Fragen offen geblieben oder mir erst bei der Arbeit am Artikel gekommen:

  • Wofür ist Semaphore es das richtige Tool?
  • Was sind die Alternativen?
  • Welches Tool eignet sich am besten als Ansible-GUI

Um diese Fragen zu beantworten, werfe ich in diesem Blogpost einen Blick auf die Semaphore Alternativen Rundeck und AWX, gehe auf (aus meiner Sicht) Vor- und Nachteile ein und gebe dir am Ende mein persönliches Fazit.

Grafische Ansible Automatisierung mit Rundeck

Was ist Rundeck?

Rundeck ist eine Open-Source-Automatisierungsplattform, die dir hilft deine Automatisierungen zu verwalten und zu planen. Rundeck kann jedoch noch viel mehr als nur das Ausführen von Ansible-Playbooks, zum Beispiel das Ausführen von Remote-Befehlen oder Skripten.

Um Rundeck zu installieren stehen dir verschiedene Möglichkeiten zur Verfügung:

  • Docker-Container
  • RPM- / DEB-Paket
  • WAR-Datei auf Windows

Bei der RPM- / DEB-Installation gibt es zudem einen weiteren Punkt der beachtet werden muss: du musst den Service als initd-Skript starten.
Neben den verschiedenen Installationsmöglichkeiten verfügt Rundeck auch über einen Terraform-Provider. Damit kannst du zusätzlich deine Projekte, Jobs, ACL-Policies und SSH-Keys verwalten.

Um Ansible-Playbooks mit Rundeck auszuführen, muss Ansible auf dem Server installiert sein. Anschließend kannst du Inventories importieren und Playbooks ausführen. Vergiss dabei aber nicht, dass die Dateien die du ausführen willst lokal auf auf dem Server liegen müssen.

Versionen von Rundeck

Rundeck ist als Community-Version, Enterprise-Version und Cloud-Version verfügbar.
Bei der Cloud-Version handelt es sich um eine gemanagte SaaS-Lösung mit allen Funktionen der Enterprise-Version. Die Rundeck Enterprise-Version bietet unter Anderem die Möglichkeit zur Verwendung der Single-Sign-On-Authentifizierung, während die kostenlose Version LDAP– und PAM-Integration bietet.
High Availability durch Cluster-Betrieb und ACL-Management über die Benutzeroberfläche ist ebenfalls nur in der Enterprise-Version verfügbar.

Was gibt es sonst noch?

Zusätzlich zu Ansible bietet Rundeck weitere sogenannte “Node Executioners“, die die Remote-Konfiguration ermöglichen, z. B. einen WinRM/Powershell Executioner, mit dem PowerShell-Skripte remote ausgeführt werden können.
Oder den AWS Elastic Container Service (ECS) Node Executor (in der Enterprise-Version), der Befehle auf Amazon ECS-Containern ausführen kann.

Die Konfiguration, um Ansible verwenden zu können, war für mich relativ aufwändig. Ich hatte Probleme mich in der Benutzeroberfläche zurechtzufinden, denn das Anlegen von Nodes ist beispielsweise relativ versteckt, während das Anlegen von Jobs einfach im Job-Tab möglich ist. Dadurch hat es mich ein wenig Zeit gekostet bis ich “Nodes” (Hosts) und “Jobs” (die auszuführenden Playbooks) anlegen konnte.

Das gesagt, kommen wir zu meinen persönlichen Vor- und Nachteilen von Rundeck:

Vorteile von Rundeck

  • Einfache Installation
  • Kann viel mehr als nur Ansible
  • Teilweise über Terraform verwaltbar

Nachteile von Rundeck

  • Unübersichtliche und unintuitive Benutzeroberfläche

Grafische Ansible Automatisierung mit AWX

Was ist AWX?

AWX ist ein Open-Source-Projekt, das ein grafisches Interface und eine REST-API bereitstellt, die auf Ansible aufbauen. Das Projekt wird von Red Hat mitfinanziert und ist eines der Upstream-Projekte für die Red Hat Ansible Automation Platform.

AWX muss in einem Kubernetes-Cluster installiert werden. Es besteht zwar die Möglichkeit, es mit Docker Compose zu installieren, dies wird jedoch nur zu Testzwecken empfohlen.

Die Konfiguration erfolgt entweder über die Benutzeroberfläche oder mithilfe der AWX Ansible Collection.

Wie AWX funktioniert

Ansible Playbooks und Inventories können aus Git-Repositories (öffentlich und privat) eingelesen oder lokal auf dem Rechner abgelegt werden. Inventories können klassisch als INI- oder YAML-Datei oder aus verschiedenen Quellen als dynamische Inventories (z. B. OpenStack, AWS EC2 usw.) importiert werden.
Dynamische Inventories, für die es Plugins gibt, die AWX jedoch noch nicht nativ unterstützt, können als normale Inventory-Dateien eingebunden werden.

Für die Authentifizierung bietet AWX folgende Methoden:

  • GitHub OAuth
  • Google OAuth 2
  • LDAP
  • SAML
  • Generic OIDC

Persönlich finde ich, dass die Benutzeroberfläche von recht intuitiv zu bedienen ist und im Gegensatz zu anderen GUIs nicht überladen wirkt. Damit kommen wir zu den Vor- und Nachteilen von AWX:

Vorteile von AWX

  • Wird größtenteils von der Ansible-Community entwickelt und ist daher sehr eng mit Ansible verbunden
  • Bietet die gängigsten Authentifizierungsmethoden
  • Relativ einfach zu bedienen
  • Ist als Code konfigurierbar

Nachteile von AWX

  • Das Betreiben von AWX in einem Kubernetes-Cluster kann überwältigend sein, wenn man noch keine Erfahrung mit Kubernetes hat

Fazit

Nun habe ich dir in meinen beiden Blogbeiträgen einen groben Überblick über Semaphore, Rundeck und AWX gegeben. Jetzt bleibt mir nur noch übrig die Fragen vom Anfang zu beantworten!

Wofür ist Ansible Semaphore das richtige Tool?
Ich würde dir Semaphore empfehlen, wenn du eine Benutzeroberfläche möchtest, auf der du regelmäßig Playbooks ausführen willst. Die Infrastruktur die du damit verwalten willst sollte jedoch noch nicht allzu groß sein, da es sonst unübersichtlich werden könnte.

Für wen eigenet sich Rundeck?
Rundeck
bietet dir zwar mehr Möglichkeiten als Ansible, ist aber relativ unübersichtlich.
Rundeck ist die richtige Plattform für dich, wenn deine zu verwaltende Infrastruktur so vielfältig ist, dass neben Playbooks auch Skripte und Befehle verwaltet und geplant werden sollen.

Und was ist mit AWX?
AWX
ist aufgrund der Nähe zu Ansible und der verbesserten Konfigurationsmöglichkeiten (Konfiguration als Code durch Ansible) die Plattform der Wahl.
Besonders wenn du größere Infrastrukturen mit Hilfe von Ansible verwalten willst oder in deiner Infrastruktur bereits ein Kubernetes im Einsatz ist.

 

Ich hoffe dass ich dir mit meinen beiden Blogposts eine kleine Entscheidungshilfe geben konnte, wenn du vor der Frage stehst, welches GUI-Tool für Ansible du nutzen willst.
Wenn du darüber hinaus Hilfe bei Themen rund um Ansible, Automatisierung oder andere spannende Open Source Themen suchst, freuen ich und meine Kolleg:innen uns auf deine Nachricht!

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.

Was ist Ansible Semaphore?

Als Open Source Consultants müssen meine Kolleg:innen und ich uns regelmäßig mit neuen Technologien, Tools oder anderen Neuerungen auseinandersetzen. Dabei testen wir besonders neue Software die uns und unseren Kund:innen das Leben potenziell leichter machen können oder Tools, die gerade einen Hype erfahren. Dadurch können wir qualifiziert entscheiden, was wir in unsere tägliche Arbeit einfließen lassen und was nicht. Das Tool mit dem ich in den letzten Tagen beschäftigt habe ist Ansible Semaphore, das ich euch in meinem ersten Blogbeitrag für NETWAYS vorstellen darf.

Was ist Ansible Semaphore?

Semaphore ist eine Web-UI, in der Ansible-Playbooks ausgeführt und geplant werden können. Es bietet eine Übersicht über vorhandene Playbooks und Inventories sowie eine Funktion zur Planung von regelmäßigen Tasks. Außerdem werden auf dem Dashboard Informationen angezeigt, wann welche Tasks zuletzt ausgeführt wurden und ob sie erfolgreich waren. Um dir einen Überblick über Semaphore zu geben, gehe ich im Folgenden auf die wichtigsten Elemente ein stelle sie dir vor.

Installation von Semaphore

Semaphore ist als Snap, Deb oder RPM Paket verfügbar. Damit bedienen die Entwickler:innen alle gängigen Betriebssysteme. Zudem stellt Semaphore eine Docker-Compose-Datei bereit, um es als Docker-Container zu installieren. Die einzelnen Schritte für jede Installationsform in diesem Blogpost zu veröffentlichen würde den geplanten Rahmen sprengen. Deshalb verweise ich hier sehr gerne auf die offizielle Ansible Semaphore Installationsanleitung.

Ansible Semaphore konfigurieren

Nach der Installation kann Semaphore hast du zwei Optionen dein neues Tool zu konfigurieren:

  • Über die Kommandozeile
  • Über eine config.json Datei

Auch bei der Benutzerverwaltung haben die Entwickler:innen auf zwei bekannte Verwaltungsmöglichkeiten gesetzt: Manuelle Verwaltung und eine LDAP Anbindung. Semaphore stellt zusätzlich eine API-Schnittstelle zur Verfügung, über die User:innen Ansible Semaphore konfigurieren und steuern können. Mehr über die Konfiguration und wie genau du sie durchführst erfährst du in der API-Dokumentation von Semaphore.

Benutzeroberfläche von Semaphore

Bei einer Web-UI kommt es vor allem auf eines an: Übersichtlichkeit. Und das schafft Semaphore ganz gut. Nach dem erfolgreichen Einloggen bekommst du folgende Oberfläche angezeigt: Die Weboberfläche von Semaphore. Man sieht 3 gelaufene Tasks, einer ist erfolgreich gelaufen, die anderen sind fehlgeschlagen. An der linken Seite gibt es eine bläuliche Menüleiste, in der die Punkte Die von mir gezeigte Oberfläche hat schon ein paar Tasks im Dashboard. Bei einer frischen Installation ist es noch leer, eine Demo-Konfiguration ist also nicht vorhanden. Dafür bietet Semaphore eine interaktive Demo-Oberfläche, auf der du dich mit der neuen Umgebung vertraut machen und erst kleine Aufgaben testen kannst. Um zu veranschaulichen, wie eine Produktivumgebung von Semaphore aussehen kann, habe ich drei Beispieltasks erstellt. Eine ist erfolgreich gelaufen, die anderen beiden sind fehlgeschlagen. Dadurch kann ich euch passende Beispiele für die Darstellung des Status zeigen. Neben der Darstellung der der Tasks ist auf der linken Seite eine türkis/blaue Menüleiste mit den Menüpunkten “Dashboard”, “Task Templates”, “Inventory” “Environment”, “Key Store”, “Repositories” und “Team”. Ganz unten in der Leiste gibt es einen Slider für einen Dark Mode und du bekommst angezeigt mit welchem User du angemeld bist. Die Oberfläche ist ja schön und gut, aber wie erstelle ich jetzt Tasks? Dafür musst du noch vier Parameter konfigurieren:

Keys

Im Key Store können SSH-Keys und Benutzer-Passwort-Paare abgelegt werden. Diese werden verwendet, um sich bei den Servern, auf denen die Ansible-Playbooks ausgeführt werden, zu authentifizieren. Die Keys werden auch zur Authentifizierung bei den Repositories verwendet, in denen die Playbooks liegen.

Inventories

Inventories enthalten, wie bei klassischem Ansible, die Server/Hosts, auf denen die Playbooks ausgeführt werden sollen. Inventories können entweder direkt in der Oberfläche angelegt werden oder auf dem Host-System von Semaphore abgelegt werden.

Environments

In Semaphore können verschiedene Environments angelegt werden, in denen Environment-Variablen gesetzt werden können.

Repositories

Die Playbooks, die verwendet werden sollen, müssen über Git-Repositories eingebunden werden. Diese Repositories können auf Git-Servern oder als lokale Repositories auf dem Host-System vorliegen. Zum Einbinden von Repositories wird ein Access Key aus dem Key Store benötigt. Bei Repositories, die über ssh eingebunden werden, ist dies ein privater SSH-Key. Bei HTTPS-Repositories muss ein Access Key vom Typ “None” eingebunden werden, der nichts beinhaltet, aber angelegt sein muss. Somit können nur öffentliche Repositories über HTTPS eingebunden werden.

Erstellen und Ausführen von Tasks

Sobald alle oben genannten Komponenten eingerichtet sind, können “Task Templates” erstellt werden. Anders als bei Ansible bestimmen Tasks in Semaphore, welche Playbooks ausgeführt werden. Ein Task Template umfasst:

  • Was passiert: Welches Playbook verwendet wird
  • Wo es passiert: Welches Inventory verwendet wird
  • Wie es passiert: Welches Environment verwendet wird
  • Wann es passiert: Planung durch Cron

Es gibt drei Arten von Templates: Task, Build,Deploy

  • Normale Tasks führen einfach Playbooks aus
  • Builds werden verwendet, um Artefakte (z.B. Packages oder Docker Container) zu erstellen. Semaphore unterstützt die Artefakterstellung nicht von Haus aus, das Build Template liefert lediglich eine Versionierung.
  • Deploys werden verwendet, um mit Build erstellte Artefakte zu deployen/installieren. Deploy Templates werden immer mit Build Templates verknüpft. Dadurch kann eine bestimmte Version des Artefakte auf den spezifizierten Servern installiert werden.

Nachdem das Task-Template erstellt wurde, drückt man einfach auf “Play”! Semaphore bietet die Möglichkeit, die Playbooks im Debug-Modus (ansible-playbook –vvvv), als Dry-Run (–check) oder im “Diff”-Modus (–diff) auszuführen. Der bekannte Output von Ansible wird dann angezeigt und kann auch nach dem Durchlauf eingesehen werden. Dadurch kann man bei einem fehlgeschlagenen Play nachsehen, welcher Fehler aufgetreten ist.

Fazit

Semaphore eignet sich meiner Ansicht nach zum gemeinsamen Arbeiten mit den gleichen Playbooks. Durch das benutzerfreundliche Interface erhält man schnell einen Überblick über die Ausführung von Tasks auf verschiedenen Geräten und deren Erfolg.  Die Cron-Funktion der Tasks ermöglicht eine regelmäßige Ausführung, was beispielsweise beim Aktualisieren von installierten Paketen nützlich ist. Es besteht allerdings auch noch Verbesserungsbedarf. Bei der Arbeit kann es hinderlich sein, dass private Git-Repositories nicht über HTTPS eingebunden werden können, da keine Authentifizierung möglich ist. Die “CI”-Funktionen mit den Build- und Deploy-Tasks werfen auch noch einige Fragen auf und sind vielleicht noch nicht ganz ausgereift. Wenn du dir jetzt denkst, dass sich Ansible Semaphore eigentlich ganz interessant anhört, du aber wissen willst wie es sich im Vergleich mit den GUI-Tools Rundeck und AWX beweist, dann habe ich gute Nachrichten für dich: Ich habe genau diese drei Tools miteinander verglichen und mein persönliches Fazit gezogen. Das Ergebnis meines Tests liest du im entsprechenden Blogpost.

Lucy Siemer
Lucy Siemer
Consultant

Lucy ist seit Mai 2023 bei NETWAYS als Consultant tätig, nachdem sie im Jahr 2022 ihre Ausbildung zur Fachinformatikerin für Systemintegration erfolgreich abgeschlossen hat. Ihre Schwerpunkte liegen auf den Bereichen Kubernetes, Infrastructure as Code und Monitoring. Neben ihrer Arbeit bei NETWAYS betreut Lucy auch privat ihre eigene Infrastruktur auf Kubernetes. Darüber hinaus ist sie leidenschaftlich daran interessiert, eigene Kleider zu nähen und individuelle Designs zu kreieren.

Foreman Birthday Event 2023 – Save the date

I can happily announce we will have a Birthday event on 27.07. this year again. I will be our host again, supported by my colleagues from NETWAYS, ATIX and the Foreman Project. When I talked to people at Cfgmgmtcamp, I was told by many that they really liked the format from 2021 and many companies still have travel or budget restrictions, so we decided to keep the event online. Hopefully returning to a face to face event in the future, but we will see what time brings.

What is planned so far?

We want to have 5-6 30 minute talks and I will moderate the event as live stream on youtube starting 15:00. But as the event also always was not only about the talks and knowledge, but also a social get-together we do want to provide some option to chat during the talks and breaks and have some accompanying social event.

If you like to give a talk please get in touch with me as I am in charge for planing this year (here in the community or via email). We aim for a wide variety of talks, be it a new plugin or some new tricks for an old one, a case study showing your environment, about Foreman itself, Katello/Satellite/Orcharhino, Pulp, Candlepin or even Puppet and Ansible or the Community. Everything related to Foreman will be considered. We plan to have all talks pre-recorded and will provide guidance for doing so. After the talk we want to give everyone the chance to ask questions, so the speaker can answer them live.

For the chat and the social event we will very likely use the same tools again which made the last event such a success, but perhaps our event team will come up with some improvements. If you want to reminisce about the last event or if you missed it and want to know what I am talking about, you can find my recap here at our blog.

How to stay up to date?

So save the date and spread the word! I will collect news in the Foreman-Community and at the latest will write another blog post when the program is finalized.

Dirk Götz
Dirk Götz
Principal 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.

Kubernetes 101: Was ist eigentlich Kubernetes?

This entry is part 1 of 7 in the series Alles rund um Kubernetes

Egal, ob du bereits einmal versucht hast, online begehrte Tickets zu ergattern, dir bei einschlägigen Onlineshops einen Raspberry Pi zu sichern, oder in letzter Zeit einfach nur einmal ChatGPT ausprobieren wolltest, eine Sache hatten diese drei (völlig frei erfundenen) Szenarien mutmaßlich gemeinsam – die Websites waren langsam, crashten, oder ließen dich minuten- bis stundenlang in einer Warteschlange sitzen. Das liegt in den meisten Fällen ganz einfach daran, dass die Webserver bzw. dahinter gelagerten Backends der Flut an Anfragen nicht gewachsen sind. Hat man seine Anwendungen “traditionell” auf VMs oder direkt auf Hardware installiert, fällt es mitunter schwer, kurzfristig auf solche Anfragespitzen zu reagieren. Die Folge aus Nutzersicht sind u.a. Serviceausfälle, Timeouts oder Drosselungen, was es natürlich zu vermeiden gilt. Hierbei kann Kubernetes helfen, und Ausfallsicherheit ist einer der am öftesten genannten Vorteile des Betriebs von Anwendungen auf Kubernetes – doch was ist Kubernetes überhaupt?

Was ist Kubernetes – und was ist es nicht?

Kubernetes ist ein ursprünglich von Google entwickelter Container-Orchestrator und war ursprünglich als interner Nachfolger für Borg gedacht. Mitte 2014 wurde Kubernetes dann von Google als Open Source Software releast. Im Rahmen des Releases der Version 1.0.0 am 21. Juli 2015 wurde es an die CNCF (Cloud Native Computing Foundation) überschrieben, eine Tochter-Foundation der Linux Foundation, die inzwischen eine große Anzahl an Projekten betreibt und verwaltet (s. CNCF Landscape). Die bei Veröffentlichung dieses Artikels aktuelle Version von Kubernetes ist v1.26. Wie der Begriff Container-Orchestrator bereits erahnen lässt, kümmert sich Kubernetes um den Betrieb von in Containern laufenden Anwendungen innerhalb eines sog. Clusters, also einer verteilten Umgebung auf mehreren Nodes, die bspw. auf VMs aufgesetzt werden und gemeinsam die Ressourcen des Clusters bereitstellen. Aspekte, um die sich Kubernetes kümmert, betreffen u.A.

  • Netzwerk: Wie können Container miteinander kommunizieren? Wie können Endnutzer und andere Dienste außerhalb des Clusters mit Cluster-internen Diensten kommunizieren?
  • Scheduling: Wie müssen/sollen/dürfen Container auf die verschiedenen Cluster-Nodes verteilt werden, sodass sie möglichst ausfallsicher/ressourceneffizient/gleichmäßig verteilt sind?
  • Berechtigungen: Welche Entität (Nutzer, Service, Systemaccount) darf in welchem Kontext was?
  • Servicediscovery: Welche Services sind in einem Cluster zu finden und reagieren auf (Nutzer-)Anfragen?
  • Flexibilität: Wieviel Last müssen meine Services gerade verarbeiten? Wie soll auf Spitzen reagiert werden?

Worum sich Kubernetes hingegen nicht kümmert, ist der tatsächliche Betrieb der Container auf den jeweiligen Nodes des Clusters – ganz im Gegenteil. Kubernetes ist zu einem großen Teil agnostisch gegenüber der genutzten Container-Runtime, sie muss lediglich konform zur von Kubernetes definierten Plugin-Schnittstelle CRI (Container Runtime Interface) sein. Das ermöglicht die Nutzung verschiedener Container-Runtimes wie bspw. containerd oder CRI-o je nach Anforderungen und Vorlieben.

Kubernetes kümmert sich ebenso wenig um Speicherverwaltung oder die Etablierung eines Cluster-internen Netzwerks, auch hierfür definiert es allerdings Schnittstellen, die von Plugins genutzt werden können, um solche Dienste zu ermöglichen: CSI (Container Storage Interface) bzw. CNI (Container Network Interface). Wichtig ist außerdem darauf hinzuweisen, dass Kubernetes deine Anwendungen nicht “magisch” ausfallsicher macht – die Anwendungen müssen von vornherein dahingehend entworfen und entwickelt werden, dass sie Ausfallsicherheit bieten können, Kubernetes unterstützt dann bei der Realisierung.

Die Existenz der gerade besprochenen Schnittstellen für Runtimes, Netzwerk und Speicherverwaltung ist ein gutes Beispiel für eine von Kubernetes größten Stärken – der Abstrahierung und Standardisierung einer ganzen Bandbreite an Fähigkeiten und Voraussetzungen für den alltäglichen Betrieb von Anwendungen. Möglich macht das eine umfangreiche und bei Bedarf frei erweiterbare API, die den momentanen (und teilweise historischen) Zustand des Clusters für berechtigte Akteure zugänglich und manipulierbar macht. Mehr dazu gibt es im kommenden Blogpost zur Architektur von Kubernetes.

Container, Docker, Kubernetes – Warum der Hype?

Betrachtet man den Fokus auf Konferenzen rund um Softwareentwicklung- bzw. -betrieb seit ca. 2017/8, sind Themen im Blickpunkt fast immer Kubernetes, Docker, Container, oder alle drei gemeinsam. Softwareentwicklung befindet sich seitdem im Wandel, weg von sog. Monolithen, die sämtliche Bestandteile einer Applikation als ein “Bündel” beinhalten, hin zu einer Flotte an Microservices, die voneinander unabhängig entwickelt, getestet, installiert und skaliert werden können. Aufgrund der abgespeckten Größe dieser Microservices bietet sich eine Installation in von Betriebssystemen weitestgehend unabhängigen Containern an, was die Flexibilität weiter erhöht.

Der de-facto Standard sowohl für die Definition und Paketierung dieser Container in sog. Images als auch für die Entwicklung der beinhalteten Software auf den lokalen Rechnern der Entwickler ist Docker. Benötigt man im alltäglichen, produktiven Betrieb der Microservices in ihren Kombinationen dann eine Vielzahl von Containerinstanzen, wird es Zeit für einen Orchestrator: Kubernetes. Aus diesen Zusammenhängen ergibt sich die seit Jahren steigende globale Popularität und Adaptierung von Containern, Docker und Kubernetes bei vielen Unternehmen, von Fortune 10 Companies bis zu Startups.

In der Theorie ermöglicht die bereits erwähnte umfangreiche Kubernetes-API in Kombination mit den offenen, wohl-definierten Schnittstellen den für den Betrieb der Cluster zuständigen Plattformteams, je nach Bedarf vorhandene oder interne Dritt-Software einzubinden, um gewünschtes Verhalten der Plattform als Ganzes zu erzielen oder existierendes Verhalten zu erweitern oder zu präzisieren.
Gleichzeitig ermöglicht es Entwicklern, sich durch die Kapselung von Software in Microservices sowie die Abstraktion der späteren Laufzeitumgebung durch Kubernetes, sich voll und ganz auf ihre Software zu konzentrieren und gleichzeitig schneller Feedback zu bekommen – CI/CD (Continuous Integration/Continuous Delivery) ist gelebter Alltag auf und mit Kubernetes. In der Praxis ist das “Unterfangen Kubernetes” natürlich nicht ganz so einfach – sonst würde ich nicht hier sitzen und diese Artikelserie schreiben.

Ist Kubernetes etwas für mich und meine Anwendungen?

Als Consultant muss ich hier natürlich antworten “Das kommt darauf an…” – nutzt du/dein Unternehmen evtl. bereits heute Container für den Betrieb von Applikationen bspw. mittels Docker Compose oder Docker Swarm? Dann ist Kubernetes lediglich der nächste logische Schritt, zumal die beiden genannten Lösungen ab einer gewissen Größe und einem gewissen Anforderungsproblem nicht mehr flexibel und skalierbar genug sein werden.
Erfahrung zeigt, dass gerade zustandslose (“stateless”) Applikationen verhältnismäßig einfach auf Kubernetes migrierbar sind und enorm von den “Bordmitteln” eines Kubernetes-Clusters profitieren (Loadbalancing, Scheduling auf verschiedene Nodes, Servicediscovery, usw.). Doch auch wenn ihr größtenteils zustandsbehaftete (“stateful”) Applikationen im Einsatz habt oder noch “klassisch”, ohne den Einsatz von Containern, deployed, ist das im Jahr 2023 kein zwingendes Argument gegen Kubernetes mehr.

Grundsätzlich bist du sicherlich gut damit beraten, dir Kubernetes einmal anzuschauen, wenn du von mindestens einem der oben erwähnten Vorteile (Containernetzwerk, Scheduling, Berechtigungsmanagement, Servicediscovery, Flexibilität) im Gegensatz zu der momentan im Einsatz befindlichen Infrastruktur (Hypervisors, Baremetal, Cloud ohne Kubernetes) profitieren könntest. Es gibt Ressourcen, Tools und Hilfsmittel für fast alle denkbaren Szenarien rund um Anwendungsentwicklung und -betrieb, und ansonsten sind wir mit unserem Schulungs– und Beratungsangebot rund um Kubernetes ja auch noch da. Und nicht zuletzt folgen noch einige Blogartikel in dieser Serie, die hoffentlich das ein oder andere Fragezeichen wegwischen werden.

Daniel Bodky
Daniel Bodky
Platform Advocate

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.