Was sind Container?

Container sind eine natürliche Weiterentwicklung virtueller Maschinen zur effizienten Nutzung verfügbarer Hardware-Ressourcen. Da ein Container in vielen Fällen lediglich einen kleinen Teil einer größeren Anwendung enthält (Microservices), braucht es oftmals viele Container, um eine große Anwendung vollständig bereitzustellen. Siehe hierzu auch meinen Beitrag über Docker. Während Docker eine Container-Laufzeitumgebung ist, ist Kubernetes eine Plattform für die Ausführung und Verwaltung von Containern aus vielen Container-Laufzeitsystemen. Es unterstützt zahlreiche Container-Laufzeiten, darunter Docker, containerd, CRI-O und jede Implementierung des Kubernetes CRI (Container Runtime Interface).

Im Betrieb von Container-Anwendungen spielen Verwaltungsaufgaben wie die Bereitstellung, die auf die Anfragelast bezogene automatische Skalierung, sowie das Monitoring der zum Betrieb notwendigen Anwendungscontainer und ihrer Infrastruktur eine wichtige Rolle. Es dient als Werkzeug zur Unterstützung dieser Orchestrierungsaufgaben.

Eingesetzt wird Kubernetes dabei bereits in kleinen und einfachen Containerumgebungen bis hin zu komplexen und verteilten Anwendungsfällen großer Technologieanbieter und ihrer containerbasierten Cloud-Produkte. Einige Beispiele sind hier: Microsofts Azure, IBM Cloud, Red Hat OpenShift, Amazons EKS, Googles Kubernetes Engine und Oracles OCI. Die bekannte Container-Technologie Docker wird ebenfalls unterstützt.

Kurze Zeitreise

Kubernetes (Altgriechisch für „Steuermann“) wurde ursprünglich von Joe Beda, Brendan Burns und Craig McLuckie entwickelt. Kurze Zeit später stießen weitere Google-Entwickler wie Brian Grant und Tim Hockin hinzu. 2014 stellte Google Kubernetes als Open-Source-Projekt der Öffentlichkeit vor.

Version 1.0 wurde am 21. Juli 2015 veröffentlicht. Dabei wurde auch die Gründung der Cloud Native Computing Foundation unter dem Dach der Linux Foundation angekündigt und Kubernetes wurde von Google an diese gespendet.

Was kann Kubernetes?

Kubernetes bietet eine Reihe von Möglichkeiten, die eine Orchestrierung von komplexen Container basierten Anwendungen unterstützt. Einige davon sind:

• Starten von Containern im Bedarfsfall (Ausfall bestehender Container oder hinzufügen neuer Container bei hohem Anfragevolumen).
• Überwachung anhand definierter Faktoren, ob Container noch erwartungsgemäß funktionieren.
• Sinnvolle Verteilung der eingehenden Anfragelast auf die einzelnen Container.
• Unterstützung beim Wechsel auf eine neuere Anwendungsversion.

Wie ist Kubernetes aufgebaut?

Kubernetes-Infrastrukturen können je nach Anwendungsfall hoch komplex sein. Eine Kubernetes-Installation besteht aus dem Zusammenspiel mehrerer Server. Die Server aus diesem Verbund lassen sich in zwei Kategorien einteilen: Zur ersten Kategorie gehören Server, die sich um Verwaltungsaufgaben in diesem Verbund kümmern. Sie werden als „Control Planes“ bezeichnet und führen keinen Container aus, der Teil der betriebenen Anwendung ist.

Die zweite Kategorie, die anwendungsbezogenen Container, werden auf den „Worker Nodes“ ausgeführt. Sie haben keine Verwaltungsaufgaben, sondern dienen lediglich dazu, die eigentliche Arbeitslast der Anwendung abzuarbeiten. Die notwendige Anzahl und Leistung dieser „Worker Node Server“ ermittelt sich anhand der Ressourcenanforderung der Container. Je ressourcenintensiver die Container sind, desto mehr oder performantere Worker Nodes werden benötigt.

Alle Aufgaben eines Kubernetes-Clusters werden redundant auf mehreren Servern betrieben, um die Hochverfügbarkeit auch im Störungsfall aufrechtzuerhalten.

Fazit

Kubernetes bietet als Open-Source-System zur Orchestrierung von Containern viele Vorteile. Besonders lohnt sich der Einsatz bei umfangreichen und hochskalierbaren Cloud-Anwendungen. Wenn man es einsetzt, kommt man schnell zu dem Punkt, an dem es komplex und aufwändig wird. Für ein effektives Management der Plattform brauchen Unternehmen Mitarbeitende mit Spezialwissen. Da diese Experten am Markt schwer zu finden sind und sich der Einsatz meist schon aus Kosten- und Rentabilitätsgründen nicht lohnt, lagern viele Unternehmen, die Kubernetes einsetzen, das Management und den Betrieb an diverse Managed Cloud Solution Provider aus. Man sollte aber nicht unbeachtet lassen, dass sich der Einsatz von Kubernetes nicht in jedem Fall lohnt. Letztendlich ist es immer eine Abwägung der Kosten und Aufwände gegen den Ertrag, den man sich durch den Einsatz erhofft.

Der Beitrag Kubernetes – Die Kunst des Container-Orchestrierens erschien zuerst auf CEOsBay.

Kurze Zeitreise

Jenkins ist in erster Linie eine Entwicklung von Kohsuke Kawaguchi. Einem ehemaligen Mitarbeiter von Sun Microsystems, der es unter dem Namen Hudson entwickelt hat. Kawaguchi verließ das Unternehmen, nachdem Oracle es Ende Januar 2010 übernahm. Er behielt aber die Leitung bei Hudson und arbeitete nach eigenen Angaben auf freiberuflicher Basis weiter bei Oracle. Oracle hielt nach wie vor die Namensrechte an Hudson. Aus diesem Grund hat man das Projekt schließlich in Jenkins umbenannt. Die Namensgebung erfolgte laut der Entwickler aufgrund der äquivalenten Assoziation der beiden Wörter mit dem Beruf des Butlers.

Oracle trieb die Entwicklung von Hudson weiterhin voran. Deshalb spricht man heute von einem Fork (einer „Abspaltung“) in der Softwareentwicklung. Im Jahr 2016 wurde die Entwicklung von Hudson zugunsten von Jenkins eingestellt und der Eclipse Foundation gespendet. Die Entwicklung wird jetzt als Open-Source-Projekt unter der Leitung der CD Foundation, einer Organisation innerhalb der Linux Foundation, verwaltet.

Wofür Pipelines?

Im Grunde genommen automatisieren Pipelines Tests und Berichte zu isolierten Änderungen in einer größeren Codebasis in Echtzeit und erleichtern die Integration unterschiedlicher Codezweige in einen Hauptzweig. Man erkennt dadurch schnell Fehler in einer Codebasis, erstellt die Software, automatisiert das Testen der Builds, bereitet die Codebasis für die Bereitstellung (Auslieferung) vor und stellt schließlich Code in Containern und auf virtuellen Maschinen sowie Bare-Metal- und Cloud-Servern bereit. Es gibt auch kommerzielle Versionen von Jenkins, auf die ich in diesem Beitrag aber nicht weiter eingehe.

Continious Integration / Kontinuierliche Integration

Kontinuierliche Integration hat sich seit der Erfindung weiterentwickelt. Ursprünglich war es die Norm, dass Teams einen Build pro Tag veröffentlichten. Nun ist es die Regel, dass jedes Teammitglied täglich oder häufiger Aktualisierungen einreicht, die man als Commit bezeichnet (Siehe Git / GitHub). Dies erfolgt bei jeder wesentlichen Änderung eines Builds. Bei der richtigen Anwendung bietet Continuous Integration verschiedene Vorteile, wie zum Beispiel ständige Rückmeldungen zum Status der Software. Da man durch CI, Mängel frühzeitig in der Entwicklung erkennt, sind Fehler in der Regel kleiner, weniger komplex und leichter zu beheben.

Jenkins und CI/CD

Im Laufe der Zeit wurden Jenkins Continuous Delivery und Deployment hinzugefügt. Continuous Delivery bedeutet, dass das Erstellen und Packen von Code für die spätere Bereitstellung in Test-, Produktions-Staging- und Produktionsumgebungen automatisiert wird. Continuous Deployment automatisiert den letzten Schritt der Bereitstellung des Codes an seinem endgültigen Ziel.

In beiden Fällen reduziert die Automatisierung die Anzahl der auftretenden Fehler, da die richtigen Schritte und Best Practices in Jenkins kodiert sind. Jenkins beschreibt einen gewünschten Zustand und der Automatisierungsserver stellt sicher, dass dieser Zustand erreicht wird. Darüber hinaus macht diese Automatisierung die Bereitstellung schneller, da Vorgänge nicht mehr an personelle Beschränkungen gebunden sind. Schließlich reduziert es die Belastung des Entwicklungs- und Betriebsteams, indem es die Notwendigkeit von manuellen Rollouts mitten in der Nacht und am Wochenende beseitigt.

Jenkins und Microservices

Jenkins bewährt sich besonders in Microservices-Architekturen. Da es eines der Ziele von Microservices ist, Anwendungen und Dienste häufig zu aktualisieren, sollte man dafür sorgen, dass die Bandbreite die Releases nicht verzögert. Mehr und kleinere Dienste mit schnelleren Update-Intervallen lassen sich nur durch Automatisierung gut umsetzen – und dafür ist es wohl die richtige Wahl.

Jenkins X

Das Jenkins X-Projekt wurde 2018 mit dem Ziel gestartet, eine moderne, Cloud-native Version von Jenkins zu erschaffen. Das Projekt steht ebenfalls unter der Leitung der CD Foundation. Die Architektur, Technologie und Pipeline-Sprache unterscheiden sich grundsätzlich von Jenkins. Jenkins X ist für Kubernetes konzipiert und verwendet es in einer eigenen Implementierung. Andere Cloud-native Technologien, die Jenkins X verwendet, sind Helm und Tekton, auf die ich in gesonderten Beiträgen eingehen werde.

Wie funktioniert Jenkins?

Jenkins läuft auf einer Vielzahl von Betriebssystemen bzw. Plattformen. Darunter gibt es Windows, MacOS und Unix-Varianten. Am besten jedoch läuft es auf Linux. Es erfordert mindestens eine Java 8 VM oder höher und kann auf Oracle Java Runtime Environment oder Open Java Development Kit ausgeführt werden. Normalerweise läuft es als Java-Servlet innerhalb eines Jetty-Anwendungsservers. Es kann aber auch auf anderen Java-Anwendungsservern wie Apache Tomcat ausgeführt werden. Auch kann es in einem Docker-Container ausgeführt werden. Im Docker Hub-Online-Repository sind aus diesem Grund schreibgeschützte Jenkins-Images verfügbar.

Um Jenkins zu auszuführen, werden Pipelines erstellt. Eine Pipeline ist eine Reihe von Schritten, die der Jenkins-Server ausführt. Diese Schritte sind in einem Klartext-Jenkins-File gespeichert. Das Jenkins-File verwendet eine geschweifte Klammersyntax, die einer JSON gleicht. Schritte in der Pipeline werden als Befehle mit Parametern deklariert und in geschweiften Klammern gekapselt. Der Jenkins-Server liest dann die Jenkins-Datei und führt die Befehle aus, wobei der Code die Pipeline vom festgeschriebenen Quellcode zur Produktionslaufzeit weiterleitet. Ein Jenkins-File kann über eine grafische Benutzeroberfläche oder durch Code erstellt werden.

Plugins

Für Jenkins sind eine Reihe von Plugins verfügbar, damit es mit anderen Tools zusammenarbeiten kann. Mit Plugins lässt sich auch der Funktionsumfang der Software erweitern. Fertige bzw. bewährte Plugins können aus dem Online-Repository für Jenkins-PlugIns heruntergeladen und über die Jenkins-Webbenutzeroberfläche oder -CLI (Kommandozeile, Command Line Interface) geladen werden. Man kann aber auch eigene Plugins entwickeln.

Plugins helfen bei der Integration anderer Entwicklertools in die Jenkins-Umgebung, fügen der Web-UI neue Elemente hinzu. Dies dient im Allgemeinen der erleichterten Verwaltung und Benutzung. Ein wichtiges Einsatzgebiet von Plugins ist das Bereitstellen von Integrationspunkten für CI/CD-Quellen und -Ziele. Dazu gehören Software-Versionskontrollsysteme (SVCs) wie Git und Atlassian BitBucket, Container-Laufzeitsysteme – insbesondere Docker, sowie Hypervisoren wie VMware vSphere, Public-Cloud-Instanzen wie Google Cloud Platform und AWS und schließlich Private-Cloud-Systeme wie OpenStack. Es gibt auch Plugins, die eine Kommunikation mit Betriebssystemen über FTP, CIFS und SSH unterstützen.

Plugins verwenden ihren eigenen Satz von Java-Annotationen und Designmustern, die definieren, wie sie instanziiert werden. Die Plugin-Entwicklung nutzt außerdem die Maven-Bereitstellung für Jenkins.

Sicherheit

Bei der Sicherheit geht es vor allem darum den Server und die Benutzer zu schützen. Die Serversicherheit wird mehr oder weniger auf dieselbe Art und Weise erreicht, wie auf regulären Servern. Der Zugriff auf den Standort, beispielsweise eine VM oder einen Bare-Metal-Server, ist so konfiguriert, dass möglichst wenige Prozesse mit dem Server kommunizieren dürfen. Dies wird durch typische Serverbetriebssysteme und Netzwerksicherheitsfunktionen erreicht.

Darüber hinaus ist der Zugriff auf den Server über die Jenkins-Benutzeroberfläche mit den regulären Mechanismen, wie Multi-Faktor-Authentifizierung oder der Beschränkung der Anzahl von legitimierten Benutzern, geschützt.

Jenkins enthält außerdem Sicherheitsfunktionen für die interne Nutzerdatenbank. Man unterscheidet zwei Sicherheitsbereiche. Zum einen den Sicherheitsbereich und den Autorisierungsbereich. Im Sicherheitsbereich regeln Administratoren, wer Zugriff hat, und im Autorisierungsbereich bestimmen die Nutzer selbst, was man mit dem Zugriff anstellen kann.

Fazit

Ein großer Vorteil von Jenkins sind die Unmengen an verfügbaren Plugins. Diese tragen zu einer enormen Flexibilität bei. Auch die umfangreichen Skript- und deklarativen Sprachen, mit denen man stark benutzerdefinierte Pipelines erstellen kann, stellen einen großen Mehrwert dar. Da es weitestgehend neutral ist, passt es gut in die meisten Umgebungen, einschließlich in komplexe Hybrid- und Multi-Cloud-Systeme.

Da Jenkins schon etwas länger als vergleichbare Lösungen in diesem Bereich verwendet wird, gibt es umfangreiche Dokumentationen und zahlreiche Community-Ressourcen, an denen man sich bedienen kann. Diese Ressourcen erleichtern die Installation, Verwaltung und Fehlerbehebung ungemein.

Da die gesamte Lösung auf Java basiert, steht es auf einer soliden Basis, die man mit gängigen Designmustern und Frameworks erweitern kann. Auch wenn sich die Installation relativ einfach gestaltet, kann es relativ schwierig sein, komplexe Pipelines zu entwickeln, zu debuggen und zu warten.

Das Open-Source-System ist außerdem eine Single-Server-Architektur. Dies kann jedoch die Ressourcen auf einen einzigen Computer, eine virtuelle Maschine oder einen Container einschränken. Cluster werden nicht unterstützt. Diese Tatsache kann die Leistung enorm einschränkten. Es kann auch dazu führen, dass es zum Server-Sprawl kommt und man den Überblick über all die einzelnen Jenkins-Server verliert.

Der Beitrag Jenkins – Automatisierte Arbeitsabläufe beim Testing erschien zuerst auf CEOsBay.