NETWAYS Blog

Unsere Abteilungswoche 2023

by Johannes Rauh | Mar 17, 2023 | NETWAYS, Ausbildung

Die diesjährige Abteilungswoche für uns Azubis hat mit dem alljährlichen Jahresmeeting begonnen. Hier hat unser CEO Bernd Erk einen Rückblick auf das Jahr 2022 und die Aufgaben, mit denen sich die einzelnen Abteilungen beschäftigt haben, gegeben. Außerdem wurden zukünftig anstehende Projekte angekündigt und nochmals eine Übersicht über alle Sozialleistungen, die NETWAYS bietet aufgezeigt.

Im Anschluss sollten wir Azubis aus dem ersten Lehrjahr Videos aufnehmen, welche wir am Dienstag beim Auftakt unserer Abteilungswoche benötigen werden. Das Thema für die Videos war „10 Types of Colleagues“. Zuerst haben wir als Team eine Ideensammlung gemacht, was für Typen uns so vorschweben und wie wir die Videos gestalten wollen. Im Anschluss wurden wir in Zweierteams aufgeteilt und sollten Kollegen finden, die bereit sind, bei unserem Projekt mitzumachen. Das hat sich als relativ schwierig herausgestellt, da obwohl sich der ein oder andere gefunden hat, der Großteil doch nicht mitmachen wollte.

Tag 1 – Marketing

Am Dienstag haben wir uns mit Katja und Julia aus unserer Marketing-Abteilung getroffen. Zusammen haben wir uns die am Vortag aufgenommenen Videos angeschaut und bei Szenen, bei denen wir mehr als einen Take aufgenommen haben, entschieden, welchen wir nehmen. Außerdem haben wir uns dazu entschlossen, dass wir zwei verschiedene Videos aus den Aufnahmen machen wollen. Wir haben die Clips aufgeteilt und zwei Teams gebildet, die jeweils ein Video geschnitten haben. Zum Schneiden haben wir iMovie, das hauseigene Schnittprogramm von Apple verwendet. Nachdem wir die einzelnen Clips zusammengeführt, mit Übergängen versehen und mit Effekten belegt haben, wurden die fertigen Videos exportiert. Diese werden in naher Zukunft auf unserer Instagram-Seite zu sehen sein.

Tag 2 – Finance & Administration

Mittwoch Vormittag haben uns Nadja und Luxshana aus der Abteilung Finance & Administration einen genaueren Einblick in ihre Arbeit gewährt. Zuerst in Form einer Präsentation über die Tätigkeiten unseres Frontoffice, später aber auch mit praktischen Aufgaben. Wir durften das Flaschenlager aufräumen, den Kühlschrank mit Getränken auffüllen und den Bestand im Lager prüfen. Im Anschluss ging die Präsentation weiter über in die Aufgaben des Backoffice. Unsere praktischen Aufgaben dazu bestanden darin, die Vorsteuer zu prüfen, Mahnungen zu verschicken und Rechnungen zu buchen. Zum Tagesabschluss durften wir noch bei der Reinigung der Kaffeemaschine helfen.

Tag 3 – Events & Training

Am dritten Tag haben sich Markus und Lukas vom Events & Trainings-Team bei uns vorgestellt. Die beiden haben uns erklärt, wie sie Konferenzen wie beispielsweise die OSMC oder stackconf planen, organisieren und durchführen. Auch Trainings für externe Kunden werden von den beiden arrangiert. Als Aufgabe sollten wir uns einmal Team überlegen, was alles zur Planung, Durchführung und Nachbereitung einer Konferenz dazugehört. Wir haben einige Bilder von vergangenen Events gezeigt bekommen und Geschichten dazu erzählt bekommen. Zum Schluss der Präsentation wurden uns die Tools gezeigt, mit denen in der Abteilung so gearbeitet wird. Wir durften selbst auch praktisch welche davon ausprobieren. Am Ende haben wir noch ein Quiz gemacht, um zu schauen, was wir so alles gelernt haben.

Tag 4 – Sales

Abgeschlossen hat die Abteilungswoche mit unserer Sales-Abteilung. Hier haben wir einen Einblick in die Arbeit von Christian und Chantal bekommen. Uns wurde gezeigt, was alles passiert bis ein Artikel verkauft werden kann. Als Aufgabe sollten wir Kundendaten in unserem System eintragen. Als Programm nutzen wir hierfür Sugar. Außerdem haben wir uns das Icinga Partnerportal angeschaut und gesehen, wie Kunden per Livechat direkten Kontakt zu unseren Mitarbeitern aufnehmen können.

Alles in allem habe ich durch die Abteilungswoche einen sehr guten Einblick in die Arbeit der nicht technischen Abteilungen unserer Firma bekommen und viel dazugelernt. Ich finde es sehr wichtig, über den eigenen Tellerrand hinaus zu schauen, da man die Arbeit der anderen so noch mehr zu schätzen weiß und ein besseres Gesamtbild über das eigene Unternehmen bekommt.

Johannes Rauh

Junior Developer

Johannes hat bevor er zu NETWAYS gekommen ist eine Ausbildung zum technischen Assistenten für Informatik abgeschlossen. 2022 startete er bei Icinga seine Ausbildung zum Fachinformatiker für Anwendungsentwicklung, um seinem Interesse für das Programmieren und der Softwareentwicklung weiter nachzugehen und sein Wissen zu vertiefen. Nach der Arbeit geht er regelmäßig ins Fitnessstudio oder verbringt Abende mit einem Cocktail und seiner Freundin vor Netflix.

Read more from Johannes and meet the Team

State-of-the-art Icinga-Installation – Teil 1: Plattform und Betriebssystem

by Dirk Götz | Mar 16, 2023 | NETWAYS, Icinga, Monitoring

This entry is part 1 of 2 in the series Icinga. Einfach. Erklärt.

In unserer Blogserie „Icinga. Einfach. Erklärt.“ entführen wir Dich ins Icinga-Universum. In diesem und zukünftigen Beiträgen behandeln wir viele spannende Themen, die Dir bei Deiner Arbeit mit Icinga helfen können.
Unsere erfahrenen Consultants nehmen Dich mit und teilen ihre Expertise und Sichtweise, wägen Vor- und Nachteile ab und berichten aus ihrer täglichen Arbeit mit dem Open-Source-Enterprise-Monitoring-Tool Icinga.

Den Anfang macht unser Principal Consultant Dirk Götz mit dem ersten Teil seiner Tipps für eine state-of-the-art Icinga-Installation. Darin geht er auf die Hardware- oder Containerlösung ein und welches Betriebssystem für Dich und Dein Team am besten geeignet sein könnte.

Aus zahlreichen Kundenprojekten, die ich im Laufe meiner Zeit bei NETWAYS durchgeführt habe, haben sich für mich einige Best Practices bei der Einrichtung und Konfiguration von Icinga ergeben. Um diese state-of-the-art Icinga-Installation zu beschreiben, dachte ich mir, ich gehe hier im Blog so vor wie ich es im Consulting auch würde. Das heißt, als Erstes gehe ich auf die richtige Plattform ein also primär das Betriebssystem, aber auch ob Hardware, virtuelle Maschine oder gar Container. Im zweiten Teil beantworte ich dann die Frage “Pet or Cattle”, gehe darauf ein, welche Icinga-Komponenten für mich einfach dazu gehören und beantworte nebenbei hoffentlich noch die Frage nach der Icinga-Repository-Subscription.

Hardware, virtuelle Maschine oder gar Container?

Starten wir also einmal ganz am Anfang und überlegen uns, welche Vor- und Nachteile wir von einer Hardware-Lösung hätten. Für mich gibt es hier immer noch einen großen Vorteil und zwar, dass man mit Hardware eine Icinga-Monitoring-Lösung aufbauen kann, die unabhängig von der zu überwachenden Umgebung ist. Leider ist dies in der Praxis in den meisten Fällen nicht so gegeben, wie man sich das als Consultant erhofft. Oder es ist mit viel Planung und weiteren Komponenten verbunden. Denn schon allein so etwas wie der Alarmierungsweg per Mail verkompliziert dies ungemein.
Daher überwiegen für mich in den meisten Fällen die Vorteile virtueller Maschinen und die damit verbundenen komfortablen Managementmöglichkeiten. Man muss sich nur bewusst machen, wovon dann das Monitoring abhängt, was davon vielleicht zu kompensieren ist und was einen Ausfall auslöst, der im schlimmsten Fall einen Blindflug bedeutet.
Wenn virtuelle Maschinen aus meiner Sicht die meisten Vorteile bieten, sind Container dann der nächste logische Schritt? Das Icinga-Projekt bietet auf jeden Fall eigene Container an, hat den Icinga-Prozess container-freundlich gebaut und einige Kunden laufen sehr erfolgreich mit diesem Konzept. Aber wenn ich mir die Plugin-Fähigkeit von Icinga und Modularität von Icinga Web so anschaue, so stehen diese Eigenschaften, die ich als Vorteile ansehe, dem Container-Ansatz doch etwas im Weg. Vor allem wenn dann ein Plugin durch ein Icinga-Web-Modul zur Verfügung gestellt wird, welches ohne Agent im Container nicht aufrufbar ist.

Wahl des Betriebssystems

Bei der Wahl des Betriebssystems bin ich ein großer Fan davon, besonders auf bestehendes Know-how zu setzen. Daher rate ich meinen Kunden Icinga auf der gewohnten Linux-Plattform zu installieren. Da aber jede Distribution ihre Eigenheiten sowie Vor- und Nachteile hat, müssen wir das Thema Betriebssystem etwas detaillierter betrachten. Und da sie direkt mit der Wahl der Distribution zusammenhängen, gibt es einen kleinen Exkurs in Richtung Monitoring-Plugins.

Debian-Familie

Hier ist es relativ einfach, denn für Debian und Ubuntu stellt das Icinga-Projekt Pakete frei zur Verfügung. Diese gibt es für jede bekannte Version, auch für einen ARM-Build in Raspberry Pi OS ist gesorgt.
Einzige kleine Einschränkung: Support gibt es im Falle von Ubuntu nur für LTS-Releases.
Damit Icinga nicht nur schön aussieht, sondern auch die gewünschte Überwachung liefert, werden Plugins benötigt. Monitoring-Plugins ist in der Debian-Familie die Quelle für die gleichnamigen Pakete. Hier bekommen wir eine paketierte und gut supportete Standard-Plugin-Sammlung, die zudem noch einfach zu installieren und gut gepflegt ist.
Etwas verwirrend ist der Benutzer “nagios“, der im weiteren Verlauf von den Icinga-Paketen weiterverwendet wird, die Nagios-/Icinga-1-Konfiguration, die durch die Plugins abgelegt wird, und die grobe Aufteilung auf Pakete.
Dass hier statt mit setuid mit Filesystem-Capability gearbeitet wird, finde ich persönlich sehr gut. Heißt, wir haben bei den Plugins Vor- und Nachteile, die aber vor allem dann eine Rolle spielen, wenn wir verschiedene Distributionen im Einsatz haben.
Einzig meine persönlichen teils negativen Erfahrungen mit Ubuntu lassen mich eher ein Debian empfehlen, Stichwort „Sonderwege“.

Red-Hat-Familie

Bei der Red-Hat-Familie wird es aus meiner Sicht komplizierter. Fangen wir mit Red Hat Enterprise Linux (RHEL) an. Hier gibt es die Pakete vom Icinga-Projekt auf Basis einer Repository-Subscription. Nachdem hier explizit auf RHEL gebaut wird, Partnerverträge bestehen etc. finde ich das ein berechtigtes Vorgehen!
Nächste in der Familie wären eigentlich CentOS Linux bzw. CentOS Stream. Ich sage hier eigentlich, denn CentOS Stream wird zukünftig nicht mehr aktiv unterstützt. Was heißt das für aktuelle Nutzer von CentOS? Es wird (Stand heute) keine Pakete für CentOS Stream 8 und 9 geben. Da es sich bei diesen Distributionen um den Upstream zu RHEL handelt, könnten theoretisch die RHEL-Pakete genutzt werden.
Leider werden auch die RHEL-Derivate Rocky Linux, AlmaLinux und Oracle Linux nicht aktiv als Icinga-Systeme unterstützt. Hier findet sich auf der Icinga-Homepage jedoch der Hinweis, dass die RHEL-Pakete bei Systemen, die zu 100-Prozent binär-kompatibel sind, genutzt werden können. Das ist zumindest bei Rocky Linux und AlmaLinux der Fall. Ob es sich dabei um eine gute Lösung für den Einzelfall handelt, muss man selbst entscheiden.
Erfreulicher sieht es dahingehend bei Amazon Linux aus. Im Rahmen der Icinga-Subscription bekommt man Zugriff auf die entsprechenden Pakete.
Alternativ kann mit Fedora auf Community-Support gesetzt werden.

Kommen wir zu den Plugins für Red-Hat. Hier befinden sich die Nagios-Plugins in einem zusätzlichen Repository, den „Extra Packages for Enterprise Linux“ oder im Fall von Fedora in den normalen Repos des Fedora-Projekts. Es handelt sich also um eine andere Quelle als diejenige, die bei Debian-basierten Systemen zum Einsatz kommt. Wie bei Debian wird aus „historischen Gründen“ die Gruppe „nagios“ verwendet und mit setgid gearbeitet, um Plugins höhere Rechte zu geben.
Man merkt, dass die Situation bei Red-Hat-Derivaten deutlich komplexer ist als bei Debian. Und besonders CentOS-Nutzer müssen sich aktuell nach Alternativen umsehen, was innerhalb der Community zu der einen oder anderen kritischen Stimme geführt hat.

Um der Komplexität etwas entgegenzuwirken, bauen wir bei NETWAYS wieder selbst Pakete. Unsere Buildplattform orientiert sich am Icinga-Projekt, daher bauen wir auf CentOS Linux 7, RHEL 8 und 9. Unsere Buildziele orientieren sich an unseren Kunden. Wir bauen und testen also für CentOS und RHEL, gehen von Funktion auf Rocky Linux und AlmaLinux aus, aber betrachten nicht Fedora, Oracle Linux und Amazon Linux.

SUSE-Familie

Bleibt noch SUSE Linux Enterprise Server (SLES). Diese Pakete sind ebenfalls nur für Subscription-Kunden zugänglich. Eine Alternative für alle SUSE-Fans wäre openSUSE, welches ich persönlich ebenso wie Fedora normalerweise nicht in einem Unternehmensumfeld sehe. Es soll jedoch ab 15 SP 3 zu 100-Prozent binär-kompatibel mit SLES sein, wodurch es vielleicht für den einen oder anderen in Frage kommt. Hier gibt es direkt Monitoring-Plugins über das Packagehub-Repository und da wir als NETWAYS bisher wenig Anfragen in dem Bereich hatten, bauen wir aktuell noch nicht standardmäßig für SLES.

Andere Systeme kommen nicht als Plattform für das zentrale System infrage, aber als Agent wird auch noch Windows supportet und bauen lässt sich die Software selbst auf weiteren Plattformen. Im Fall von FreeBSD und Alpine Linux werden sogar Pakete von der Community bereitgestellt.

Zusammenfassung

Welche Distribution kann ich nun empfehlen? Debian ist sinnvoll für all diejenigen, denen der Community-Support ausreicht. Wer eh schon auf Enterprise-Support beim Betriebssystem setzt, für den lohnen sich die RHEL-Pakete, auch wenn diese mit einer Icinga-Subscription verbunden sind. Alle anderen Optionen sind auch valide, aber fühlen sich einfach nicht optimal an.
Wer eine heterogene Umgebung zu überwachen hat, findet im Icinga-Umfeld neben der Verfügbarkeit, wie man oben raus lesen konnte, ein paar kleinere Baustellen, die mit Erfahrung aber leicht zu handhaben sind. Für diese kann aber das Icinga-Projekt recht wenig, denn auch wenn man versucht hat, in der Vergangenheit in Zusammenarbeit mit allen Distributionen einen gemeinsamen Kurs zu finden, ist dies leider nicht immer gelungen.

Damit sind wir am Ende des ersten Teils meiner Vorstellung einer state-of-the-art Icinga-Installation. Ich hoffe Dir damit weiterhelfen zu können!
Falls Du bereits jetzt Interesse an Icinga gefunden hast und es auch in Deinem Unternehmen vorschlagen oder sogar einführen willst, führen ich oder ein:e Kolleg:in gerne eine individuelle Betrachtung der vorhanden IT-Umgebung durch. Im Rahmen eines solchen Consultingtermins erstellen wir gerne zunächst ein Proof of Concept. Natürlich können wir auch gleich mit der Implementierung von Icinga beginnen.

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.

Read more from Dirk and meet the Team

Herzlichen Glückwunsch zum 10-jährigen Jubiläum, Markus Waldmüller!

by Katja Kotschenreuther | Mar 10, 2023 | Team

This entry is part 6 of 6 in the series Hip, hip, hurray - NETWAYS Anniversaries

10 Jahre ist‘s her, dass unser Markus Teil der NETWAYS Crew geworden ist. Anlässlich seines Jubiläums im März dieses Jahres werden wir heute einige coole Insights über sein bisheriges #Life@NETWAYS bekommen. Viel Spaß dabei!

Hi Markus, erstmal herzlichen Glückwunsch zu 10 Jahren NETWAYS! Mit welchen 3 Begriffen würdest Du Deine bisherige Zeit bei NETWAYS beschreiben?

“Servus! Das ist wirklich eine gute Frage. Um mal alle Situationen abzudecken, reichen 3 Begriffe nicht ganz, ich entscheide mich einfach mal für: Erlebnisreich – Herausfordernd – Lustig”

Ich hab‘ mal ein bisschen in unserem Bilder-Archiv gestöbert und so einige lustige Fotos von Dir gefunden. Daher eine äußerst wichtige Frage an Dich: Was hat es mit diesem Bild auf sich? Bist Du etwa Helenes größter Fan? 😂

“Wie komm ich da jetzt nur raus? 😉

Das Bild stammt noch aus der „Atemlos“-Zeit und ist in unserem alten Büro an der Kaffeemaschine entstanden. Das war kurz vor Weihnachten als wir noch deutlich weniger waren als heute und das Weihnachts-Wichteln entstand. Da es damals im Vorfeld noch keine Namensauslosung gab, musste man etwas „generisches“ schenken. Zu der Zeit waren wir natürlich alle große Helene Fans und die CD somit eine top Idee! Dass ich keinen CD-Spieler mehr hatte, war Nebensache und ein paar Monate später hatten wir sogar das „Most booked Helene Fischer Double“ als Liveact bei uns auf der OSMC in Nürnberg. Achja, Helene ist schon toll!”

Du trägst ja heute den ehrenwerten Titel des Lead Consultants. Auf welchen Job hast Du Dich damals bei NETWAYS beworben und wie sah Deine berufliche Laufbahn bis heute aus? Erzähl mal!

“Ja, mein Titel hat sich im Lauf der Zeit schon ein paar Mal geändert und ich bin (fast) sicher, dass es nicht lange bleiben wird. Nach meiner gescheiterten Selbstständigkeit und bestandener Technikerschule hab ich hier als Consultant angefangen.

Die ersten Jahre waren wir alle noch sehr viel „on the road“. Heißt: Montags nach Nürnberg ins Büro, danach zum Kunden oder zum Training und Freitag Abends wieder heim. Nach 3-4 Jahren hab ich dann in unserem gewachsenen Team die Möglichkeit bekommen, auch andere Aufgaben wahrzunehmen und mich beispielsweise auch bei interner Organisation, Strategie oder Personalmanagement mit einzuklinken. So ist das auch bis heute geblieben, auch wenn ich mich 2019 ein halbes Jahr „ausgeklinkt“ habe, um privat die Welt zu bereisen.

Unser kleines Team ist mit NETWAYS Professional Services inzwischen eine eigene Firma. Wir machen nicht nur Consulting, sondern auch Produktsupport und Betriebsunterstützung sowie einiges mehr. Neben der Stellvertretung von Tobi Redel kümmere ich mich heute mit meinem Team insbesondere um „Planung und Development“ und insgesamt, dass alles möglichst rund läuft. Ich versuche aber auch, den technischen Aspekt nicht zu verlieren und bin zwischendrin auch immer noch im Kundeneinsatz oder kümmere mich um Trainings.”

Als Consultant warst Du früher aufgrund von Kundenbesuchen sehr viel auf Reisen. In welchen Ländern warst Du unterwegs und was war Dein persönliches Highlight?

“Hauptsächlich war ich natürlich bei unserem Kunden in Deutschland oder im deutschsprachigen Ausland, wie z.B. Österreich, Schweiz, Liechtenstein, etc. unterwegs. Ansonsten durfte ich auch ein paar Mal weiter weg und eigentlich war natürlich alles cool.

Besonders erwähnenswert ist auf jeden Fall meine erste „große“ Reise als wir 2014 auf der PuppetConf in San Francisco, also USA, waren. Anschließend haben wir in den Räumen von GitHub das erste Icinga Camp überhaupt veranstaltet. Mit San Diego (Konferenz) oder Atlanta (Training) ging’s für mich danach noch öfter über „den großen Teich“.

Meinen ersten (und bisher einzigen) Vortrag hab ich in Bangalore, Indien, gehalten. Die Trainings in Polen rücken da schon fast in den Hintergrund. Bis heute spricht man hier aber von den Erlebnissen rund um das Training in Windhoek, Namibia. Auch wenn’s meistens etwas anstrengend war, bin ich für jedes Ziel dankbar. Und in meinem Reisepass ist auf jeden Fall noch seeehr viel Platz für alles, was da noch so kommt ;-)”

Auch firmenintern war jedes Jahr was los: Mallorca, Amsterdam, Ski-Wochenenden und nicht zu vergessen die Teamevents in Eurer Abteilung. Hier gibt’s bestimmt die ein oder andere lustige Story. Hau mal eine für uns raus!

“Da gibt’s auf jeden Fall viele lustige Geschichten, die da passiert sind. Allerdings ist die Erinnerung da unter uns gesprochen teilweise schon etwas „neblig“. Aber mir fällt da beispielsweise die Gründung der „NETWAYS-Polonaise“ ein, als wir mit der Bluetooth Box durch die Schlafzimmer gezogen sind, um die Zahl der Feiernden wieder anzukurbeln. Das hat wunderbar funktioniert und die Polonaise wurde zur spaßigen Tradition, bei einigen sogar mit professionellen Verbarrikadierungstaktiken.”

Welche Dinge schätzt Du an NETWAYS als Arbeitgeber am meisten?

“Da gibt es so einiges und vieles ist für mich so normal geworden, dass ich es bestimmt vergesse zu erwähnen. Arbeitstechnisch spielt für mich vielleicht die individuelle Gestaltungs- und -entwicklungsmöglichkeit die größte Rolle. Die letzten Jahre haben gezeigt, dass sich NETWAYS auch in schwierigen Zeiten nochmal von vielen anderen Firmen abhebt und in besonderem Maß für die Mitarbeiter da ist.

Daneben ist für mich aber auch das Drumherum, z.B. eben mit den diversen Veranstaltungen, wichtig. Das sorgt für Spaß und Abwechslung. Im Laufe der Jahre sind hier für mich viele (sehr) gute Freundschaften entstanden, die ich nicht missen möchte. Der Begriff der NETWAYS-Family trifft das schon ganz gut und auch das Gehalt kommt (über)pünktlich ;-)”

Nach 10 Jahren Betriebszugehörigkeit gibt’s als Treuebonus eine Reise geschenkt. Hast Du schon Ideen oder sogar einen Plan, wo es hingehen wird?

“Entgegen meiner normalen Gepflogenheiten soll das Ziel „gleich um die Ecke“ sein und es geht mit meinem Bruder nach Irland, vorausgesetzt es ergibt sich mal eine längere Pause vom Fussball.”

Und was sind Deine Wünsche und Pläne für Deine Zukunft bei NETWAYS? Wo soll da die Reise hingehen?

“Meine Wünsche waren schon immer vom Baggersee aus zu arbeiten und in Frührente zu gehen.

Ansonsten haben mir gerade die letzten Jahre verdeutlicht, wie schnell doch alles ganz anders kommen kann als erwartet, deswegen warte ich einfach mal ab was da sonst noch alles so passiert.”

Vielen Dank, Markus für das tolle Interview! Wir wünschen Dir für die nächsten Jahre nur das Beste und hoffen, dass Du uns noch lang erhalten bleibst!

Katja Kotschenreuther

Marketing Manager

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Online Marketing Managerin kümmert sie sich neben der Optimierung unserer Websites und Social Media Kampagnen hauptsächlich um die Bewerbung unserer Konferenzen und Trainings. In ihrer Freizeit ist sie immer auf der Suche nach neuen Geocaches, bereist gern die Welt, knuddelt alle Tierkinder, die ihr über den Weg laufen und stattet ihrer niederbayrischen Heimat Passau regelmäßig Besuche ab.

Read more from Katja and meet the Team

Kubernetes 101: Was ist Kubernetes und warum brauche ich es?

by Daniel Bodky | Mar 9, 2023 | NETWAYS, Automation, Serien

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

Hi! Ich bin Daniel, Open Source IT Consultant und großer Kubernetes-Fan. Zukünftig nehme ich dich in unserer neuen Blogserie “Alles rund um Kubernetes” mit auf eine Reise in die Welt von Kubernetes. Den Start der neuen Reihe macht eine Serie von Artikeln rund um das Thema “Kubernetes 101”. In deren Verlauf werde ich verschiedene Aspekte der Arbeit mit und auf Kubernetes beleuchten. Angefangen bei einer Vorstellung des Tools selbst und der dahinterstehenden Ideologie über die Installation auf unterschiedlichen Betriebssystemen in verschiedensten Umgebungen bis hin zum Betrieb und der Absicherung eines Kubernetes-Clusters werde ich auf viele Szenarien und Gesichtspunkte eingehen.
In diesem ersten Artikel geht es darum, die Grundlagen des Themas überhaupt einmal kennenzulernen. Ich beantworte die Fragen “Was ist Kubernetes eigentlich?” “Warum ist es momentan so im Trend?” Und “Könnte dir Kubernetes den Betrieb deiner Anwendungen erleichtern?”. Und nun viel Spaß bei deinem Einstieg in die Container-Orchestrierung!

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

Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. 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.

Read more from Daniel and meet the Team

Sommer, Sonne, Software – Rückblick CIVO NAVIGATE 2023

by Daniel Bodky | Mar 6, 2023 | Automation, DevOps, Soziales, Kubernetes

Anfang Februar durfte ich nach Tampa, Florida reisen, um auf der IT-Konferenz Civo Navigate zu sprechen, die in diesem Rahmen zum ersten Mal stattfand. Mit Beiträgen rund um Kubernetes, Edge Computing, Machine Learning, DevOps, GitOps, Observability, Security und Cloud Native Transformation war das Angebot an Themen breit gefächert. Sicherlich vor allem aus diesem Grund (und nicht nur wegen Temperaturen bis zu 30 Grad und toller Location) fanden sich zusätzlich zu 50 angekündigten Speakern, u. a. von ARM, GitLab, oder SUSE auch ca. 300-350 Teilnehmer vom 7.-8. Februar in Tampa ein.

Eingeleitet wurde die Konferenz durch einen Keynote-Block auf der Main Stage, wo nach einem Grußwort von Civo’s CEO Mark Boost ein ca. einstündiger Schwenk aus Steve Wozniak’s Leben folgte für viele Besucher bereits das erste Highlight. Im Anschluss ging es dann los mit den verschiedenen Beiträgen, vorgetragen auf drei separaten Tracks – zwei für klassische Talks und einer für praxisbezogenere Workshops. Für mich hieß es direkt ‘Showtime!’, ich hatte den ersten Slot auf dem Workshop-Track erwischt, wo ich eine einstündige Einführung in Acorn gab.

Kubernetes-Deployments einfacher gestalten!

Acorn ist ein Tool in erster Linie für Entwickler, die ihre Anwendungen in ihre Kubernetes-Cluster deployen möchten, ohne direkt allzu tief in Kubernetes als Framework einsteigen zu wollen. Mein Kollege Markus hatte Acorn vor Kurzem bereits in seinem Blogpost über Application Management in Kubernetes erwähnt, und ich hatte nun die Gelegenheit, einem interessierten Publikum von ca. 20 Teilnehmern die Software näher zu bringen. Ziel des Workshops war es, eine Gästebuch-Anwendung von einem Docker-basierten Deployment mithilfe von Acorn auf Kubernetes umzustellen. Die Folien zu meinem Workshop finden sich unter acorn.dbodky.me, und in Kombination mit den Workshop-Unterlagen auf GitHub könnt ihr den Workshop bei Interesse auch daheim durchgehen. 😉

Auf den erfolgreichen Workshop folgte analog zu Markus’ Blogartikel eine angeregte Diskussion, welche Tools für Application/Deploy Management auf Kubernetes denn nun am geeignetsten seien. Darauf gibt es natürlich keine eindeutige Antwort, geschweige denn eine Patentlösung, aber im Laufe der Gespräche wurden immer wieder Epinio, entwickelt von SUSE, und Namespace von Namespace Labs genannt – zu Epinio gab es am Folgetag sogar einen weiteren Workshop. Persönlich habe ich mir bisher keine der beiden Lösungen angeschaut, werde das aber nun schleunigst nachholen, und wer weiß, evtl. folgt ja demnächst ein weiterer Blogpost. Die Nachfrage nach Möglichkeiten, Kubernetes und seine Bedienung für den alltäglichen Gebrauch zu abstrahieren, ist auf Entwicklerseite allem Anschein nach auf jeden Fall vorhanden.

GitOps, Security und KI

Im Anschluss hatte ich jedenfalls gut lachen – zwei Stunden nach Konferenzbeginn war ich bereits “nur noch Teilnehmer” und konnte nach Lust und Laune verschiedene andere Talks besuchen, mich mit interessierten Teilnehmern unterhalten und die sommerlichen Temperaturen von bis zu 30 Grad genießen. Für mich war interessant zu sehen, in welche Schwerpunkte sich der Großteil der Beiträge würde einordnen lassen, und für mich stachen dabei zwei Dinge heraus – GitOps und Absicherung von Kubernetes-Clustern. Zu diesen Themen gab es einige interessante Talks, angefangen bei Best Practice Sammlungen zu GitOps und Tools, die eine Kombination von GitOps und ClickOps ermöglichen, bis hin zum Einsatz von Service Meshes in Kubernetes zur Absicherung von Netzwerkverkehr in Kubernetes-Clustern.

Auch ein sehr interessanter Beitrag über das Hacken von Kubernetes-Clustern war im Programm enthalten, sodass man sich dem Thema “Sicherheit” auch einmal aus Sicht des Angreifers widmen konnte. Doch auch andere Themen fanden Beachtung – so gab es nicht nur einige Beiträge zu den Themen ML/AI auf Kubernetes und Edge Computing, der Veranstalter Civo stellte im Rahmen seiner Konferenz auch neue Produkte in diesen Bereichen vor, was beispielhaft für die momentanen Trends rund um “Cloud Native” und Kubernetes gesehen werden kann.

See you later, alligator!

Größter Pluspunkt der Konferenz als Ganzes waren für mich definitiv die Workshops, die durchgängig im Ablauf zu finden waren – so konnte man seinen persönlichen Talk-Marathon über 48 Stunden zwischendurch immer mal wieder mit praktischeren Fingerübungen und Case Studies auflockern und nebenbei noch sein bestehendes Wissen zu bestimmten Tools aufbessern oder komplett neu erwerben. Das nächste Mal stattfinden wird Civo Navigate im September 2023 in London, und wer weiß, evtl. werde ich euch auch dann wieder von meinem Beitrag und der Konferenz allgemein berichten dürfen.

Daniel Bodky

Consultant

Read more from Daniel and meet the Team