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.

Debian GNU/Linux basiert auf den grundlegenden Systemwerkzeugen des GNU-Projektes sowie dem Linux-Kernel.

Die aktuelle Version ist Debian 11 „Bullseye“ und als Vorabversion gibt es bereits Debian 12 „Bookworm“. Es bietet eine große Auswahl (Zurzeit ca. 60.000) an Anwendungsprogrammen und Werkzeugen. Auch wird Debian als Basis für viele andere Linux Distributionen genutzt. Eines der Bekannteren Ubuntu, welches eher nicht mehr zu meinen persönlichen Favoriten gehört.

So ging es los

Im August 1993 hat Ian Murdock mit der Arbeit an einem neuen Betriebssystem angefangen. Es sollte offen sein, ganz im Sinn von Linux und GNU. Er verschickte eine offene Einladung an andere Software-Entwickler und lud sie ein, bei einer Software-Distribution mitzumachen, die auf dem damals noch recht jungen Linux-Kernel basieren sollte. Debian sollte sorgfältig zusammengestellt und genauso gewissenhaft betreut und unterstützt werden. Dabei sollte es ein offenes Design aufweisen und Beiträge und Unterstützung aus der Freien-Software-Gemeinschaft einfließen lassen.

Alles begann mit einer kleinen, eingeschworenen Gruppe von Hackern von freier Software und wuchs zu einer relativ großen, gut organisierten Gruppe aus Entwicklern, Beitragenden und Anwendern heran. Mittlerweile fasst das Debian-Projekt mehr als eintausend aktive Entwickler und Unterstützer auf der ganzen Welt.

Die Satzung

Ein Projekt mit dieser Größe braucht eine gute Organisationsstruktur. Aus diesem Grund hat das Debian-Projekt klare Regeln und Richtlinien, die man hier unter der Satzung einsehen kann.

Debian – Das Wieso

Manche wundern sich, warum so viele Menschen dafür brennen, so viel Freizeit in das Programmieren, Verpacken und Betreuen von Software zu investieren und sie dann auch noch zu verschenken. Dafür gibt es eine ganze Reihe von Gründen.

Manche Leute sind von Natur aus einfach hilfsbereit und haben mit der Einbringung in ein freies Software-Projekt ihren Weg gefunden, diese Hilfsbereitschaft auszuleben.

Viele Entwickler schreiben Programme, um Computer sowie verschiedene Architekturen und Programmiersprachen besser zu verstehen.

Einige Unterstützer möchten sich für all die freie Software revanchieren, die sie benutzen dürfen und bringen sich deshalb ein. 

Dann gibt es noch viele AkademikerInnen, die an freier Software entwickeln, um ihre Kenntnisse zu erweitern und um die Ergebnisse ihrer Forschungen bekannt zu machen.

Und zu guter Letzt gibt es Unternehmen, die bei der Entwicklung und Betreuung von freier Software helfen, um Einfluss darauf zu nehmen, wie sich die Software weiterentwickelt. Besonders dann, wenn man neue Features schnell implementiert haben möchte.

Ich persönlich bin bei dem ein oder anderen Projekt dabei, weil mich die Technologie an sich interessiert und mir die Zusammenarbeit mit Menschen sehr viel Spaß macht. Und nachdem mir relativ schnell langweilig wird, benötige ich immer wieder neuen Input. Letzteres gilt natürlich für die Technologie und weniger für die Menschen. Im Grunde genommen, beteiligt man sich meistens an Open Source bzw. in diesem Kontext als Debian-Entwickler, für den Spaß und um gemeinsam etwas großartiges zu erschaffen.

Ideologie und unfreie Software

Die Debian Gemeinschaft glaubt an die freie Software. Dennoch ist es respektiert, dass Menschen manchmal unfreie Software auf ihren Computern installieren müssen. Aus diesem Grund gibt es den Beschluss seitens der Debian Entwickler, diese Menschen nach Möglichkeit zu unterstützen, daher gibt es eine immer größer werdende Anzahl von Paketen, die unfreie Software auf einem Debian-System nachinstallieren lässt.

Diese Tatsache kann besonders zu Beginn relativ herausfordernd sein, da man bereits zur Installation von Debian nicht freie Treiber Pakete für diverse Hardware installieren muss, die nicht standardmäßig auf den Installationsmedien mitgeliefert werden. Besonders betroffen hierbei, sind in der Regel die Treiber für die Netzwerkkarte, da man diese bereits bei der Installation benötigt, um aktualisierte Pakete bereits bei der initialen Installation mitzuinstallieren. Doch dies werde ich, mit einer hohen Wahrscheinlichkeit, bei einem späteren Beitrag nochmals ausführlich thematisieren.

Das Projekt

So gesehen, kann sich jeder als Debian Entwickler registrieren, der den sogenannten New-Member-Prozess erfolgreich durchläuft. Die Bewerber kommen hinsichtlich ihrer Kenntnisse und Fähigkeiten auf den Prüfstand. Außerdem wird sichergestellt, dass sie mit der Philosophie des Projektes vertraut sind.

Der Name des Betriebssystems leitet sich von den Vornamen des Debian-Gründers Ian Murdock und seiner damaligen Freundin und späteren Ehefrau Debra Lynn ab. Bereits wenige Monate nach der Gründung, im Mai 1994, entschied sich das Projekt zu einer Änderung des offiziellen Namens von Debian zu Debian GNU/Linux.

Letzteres ging mit der Auffassung der Free Software Foundation einher, dass das häufig als Linux bezeichnete Betriebssystem eine Variante des GNU-Systems sei. Dahingehend gab es einen relativ bekannten Namensstreit, den ich hier nicht wirklich thematisieren werde. Wen es aber interessiert, kann gerne hier vorbeischauen.

Allgemein spricht man nur noch von Debian, wenn man von Debian spricht 😀

Das System ist bekannt für seine Paketverwaltung dpkg und deren Frontend APT. Mit diesen ist es möglich, alte Versionen von Debian GNU/Linux durch aktuelle zu ersetzen oder neue Softwarepakete zu installieren. Sie sind ebenfalls dafür zuständig, alle von einem Programm benötigten Abhängigkeiten aufzulösen, also alle Programmpakete zu laden und zu installieren, welche die gewünschte Software benötigt.

Sicherheit

Alle Probleme mit der Software sind öffentlich behandelt, so auch sämtliche Sicherheitsprobleme. Aspekte der Sicherheit sind öffentlich auf der debian-security-announce-Mailingliste zur Diskussion freigegeben. Debian‘s Sicherheitsgutachten (Audits) werden über eine öffentliche Mailingliste versendet (Sowohl unter den Entwicklern als auch mit den externen Mailinglisten) gleichzeitig auf einem öffentlichen Server bekanntgegeben.

Durch diese Handhabung verspricht man sich ein schnelleres Auffinden von Sicherheitslücken und damit die Möglichkeit, diese auch eher beheben zu können. Die entgegengesetzte Herangehensweise des Security Through Obscurity (Sicherheit durch Unklarheit bedeutet, dass man sich in der Sicherheitstechnik auf die Geheimhaltung des Entwurfs oder der Implementierung als Hauptmethode zur Gewährleistung der Sicherheit eines Systems oder einer Komponente verlässt) ist dagegen als unpraktikabel angesehen. 

Die Tatsache, dass die Entwicklung der Distribution öffentlich sichtbar unter Beteiligung einer Vielzahl von Personen geschieht, erfordert besondere Sicherheitsmaßnahmen. Änderungen an Paketen sind grundsätzlich mit einem verifizierbaren Schlüssel digital signiert. Die Überprüfung der Gültigkeit der Signatur erfolgt beim Anwender vor der Installation. Diese Maßnahme soll es Dritten erschweren, schädliche Software in Debian-Pakete einzuschleusen.

Die Paketbetreuer passen die Sicherheitsaspekte ihrer jeweiligen Software an die allgemeinen Grundsätze von Debian an. Daher sind Dienste nach der Installation oft als „sicher“ voreingestellt, was von einem Benutzer als „Einschränkung“ empfunden werden kann. Dennoch versucht Debian, Sicherheitsaspekte und einfache Administration abzuwägen. Zum Beispiel werden Dienste wie ssh und ntp nicht inaktiv installiert, wie es bei den Distributionen der BSD-Familie üblich ist. Auf BSD werde ich in einem zukünftigen Beitrag eingehen.

Wenn ein Sicherheitsproblem in einem Debian-Paket entdeckt wird, kommt es zusammen mit einer Einschätzung der dadurch entstehenden Gefahr in die Öffentlichkeit bzw. wird auf den vorher erwähnten Wegen publiziert. Parallel wird so schnell wie möglich ein Sicherheitsupdate dieses Pakets vorbereitet und auf speziellen Servern veröffentlicht. Kritische Sicherheitslücken werden auf diese Weise häufig innerhalb von Stunden geschlossen.

An dieser Stelle ist es vielleicht sinnvoll zu erwähnen, dass die von Debian angepasste Implementierung des für die Schlüsselerstellung zuständigen Zufallsgenerators der OpenSSL-Bibliothek zwischen September 2006 und Mai 2008 mit einer erheblichen Sicherheitslücke lief. Die generierten geheimen Schlüssel konnten abgeschätzt und damit in kurzer Zeit (vor-)berechnet werden (1024- und 2048-Bit-Schlüssel in ungefähr zwei Stunden). Insbesondere OpenSSH und die sichere Kommunikation in Webbrowsern waren davon betroffen.

Das Sicherheitsrisiko besteht weiterhin für alle RSA-Schlüssel, die in diesem Zeitraum auf betroffenen Systemen erstellt wurden und seit der Aktualisierung der Bibliothek nicht neu erstellt wurden. Auch alle DSA-Schlüssel, die jemals von einem Rechner mit fehlerhaftem Zufallszahlengenerator verwendet wurden, sind seitdem unsicher. Selbst wenn diese ursprünglich auf einem Rechner mit korrekt arbeitendem Zufallszahlengenerator erstellt wurden. Zu einem der größeren Sicherheitslücken kam es auch im Jahr 2019. Denn da wurde in dem Paketmanagertool von Debian („apt“ bzw. „apt-get“) eine Sicherheitslücke entdeckt, die es einem Man-in-the-Middle-Angreifer ermöglichte Code bei einem Update auszuführen.

Fun Facts

Die Stadt München war zwischen 2006 und 2013 mit Debian-basierten Betriebssystemen LiMux auf freier Software unterwegs. Spekulationen zufolge switchten sie durch Einfluss von Microsoft, da sie mit einer Deutschland-Zentrale von Unterschleißheim nach München-Schwabing umzogen, zu Microsoft. Dies könnte mit der Gewerbesteuer an die Stadt München zusammenhängen, meinte der ein oder andere Autor im Manager-Magazin.

Fazit

Wie bereits erwähnt, empfinde ich Debian als äußerst sympathisches Projekt bzw. Distribution. Nichtsdestotrotz ist es, meiner Meinung nach, noch kein einsteigerfreundliches Betriebssystem. Zum einen, wegen der unfreien Treiber, die gegebenenfalls vor- oder nachinstalliert werden müssen und zum anderen, weil grundsätzlich jedes System nach der Neuinstallation Sicherheitslücken enthält, die von fähigen Personen geschlossen werden müssen. Debian GNU/Linux bietet umfangreiche Möglichkeiten, das System vor unbefugten Zugriffen abzuschotten. Allerdings reicht es nicht aus nur Sicherheits-Updates aufzuspielen. Der Anwender selbst kann und muss aktiv sein System „härten“. Und dafür muss man schon einiges an Fachwissen mitbringen.

Sicherlich kann sich der Nutzer über Sicherheitsrisiken unter den genannten Quellen bereits im Vorfeld informieren. Doch auch während und nach der Installation des Debian-Betriebssystems muss der Nutzer auf einige grundlegende Dinge achten. Dies beginnt bei den BIOS-Einstellungen, geht über die Absicherung des Bootloaders und schlussendlich bei der Installation von Sicherheits-Patches bzw. zur Anpassung von Diensten und sicherheitsrelevanten Dateien.

Daher ist es vielleicht sinnvoll, mit einem „einfacheren“ System wie Ubuntu zu beginnen und sich so langsam in die Materie einzuarbeiten, wenn man in der Zukunft etwas unabhängiger und konsequenter unterwegs sein will.

Der Beitrag Debian – Für Stabilität und Freiheit erschien zuerst auf CEOsBay.

Was sind Container?

Zu dem heutigen Industriestandard gehört die Verwendung von virtuellen Maschinen (VMs) zur Ausführung von Softwareanwendungen zum Alltag. Ein Docker-Container ist eine Standardsoftwareeinheit, die einen Code in all seinen Abhängigkeiten speichert. So wird die Anwendung schnell und zuverlässig auf verschiedensten Computerumgebungen lauffähig. Ein Container bildet ein leichtes eigenständiges ausführbares Softwarepaket ab, das alles enthält, was zum Ausführen einer Anwendungscodelaufzeit benötigt wird. Was im Grunde genommen benötigt wird sind in der Regel der Programmcode, diverse RunTime-Engines, Systemtools, die dazugehörigen Systembibliotheken und so ziemlich alle Einstellungen. Diese containerisierte Software läuft unabhängig von dem Betriebssystem, also auf Linux-, Mac- und Windows-basierten Systemen. Und dies vollkommen unabhängig von der jeweiligen Infrastruktur. Die Container isolieren die Software von der Umgebung und stellen sicher, dass sie trotz der Unterschiede einheitlich funktioniert.

Vorteile von Containern

Docker-Container sind besonders beliebt, weil sie gegenüber Virtuellen Maschinen (VMs) viele Vorteile bieten. VMs enthalten grundsätzlich vollständige Kopien eines umfassenden Betriebssystems, die Anwendung(en) selbst, alle erforderlichen Binärdateien und Bibliotheken. Diese Tatsache beansprucht in der Regel Unmengen an Speicherkapazität.

VMs booten im Vergleich auch ausgesprochen langsam. Container benötigen grundsätzlich weniger Speicherplatz, da ihre Images normalerweise nur wenige hundert Megabyte groß sind. So können bei dem Einsatz von Docker viel mehr Anwendungen gleichzeitig verarbeitet werden. Dies reduziert Verwendung von VMs und Betriebssystemen.

Auch der Einsatz von Containern auf Edge-Devices, z.B. auf kompakten Einplatinencomputern (Single-Board Computer (SBC) wie die beliebten Raspberry Pi’s oder NVIDIA Jetson’s, sowie robusten und wartungsarmen Embedded PC’s in der Industrie, ist problemlos möglich. Container sind flexibler und effektiver als VMs und die Verwendung von Docker in der Cloud ist ebenfalls sehr beliebt. Die Möglichkeit, dass verschiedene Anwendungen auf einer einzelnen Betriebssystem-Instanz ausgeführt werden können, verbessert vielfältige Einsatzmöglichkeiten immens. Ein weiterer entscheidender Vorteil von Containern ist die Fähigkeit, Apps nicht nur voneinander, sondern auch von ihrem zugrundeliegenden System zu isolieren.

So kann der Anwender leicht bestimmen, wie eine zugewiesene containerisierte Einheit das jeweilige System und die vorhandenen Ressourcen (CPU, GPU und Netzwerk) nutzt. Zudem stellt es auch sicher, dass Daten und Code voneinander getrennt bleiben was durchaus eine weitere Sicherheitsinstanz darstellen kann.

Komponenten von Docker

Die Docker-Plattform besteht aus einer Reihe von Komponenten. Desktop und Engine sind die zwei wesentlichen Bestandteile davon. Images definieren den Inhalt von Containern. Container sind lauffähige Instanzen von Images. Der Daemon ist eine Hintergrundanwendung, die Images und -Container verwaltet und ausführt. Der Client ist ein Befehlszeilenprogramm (CLI Command-Line Interface) „Ein Befehlszeileninterpreter oder Befehlszeilenprozessor.“ Es verwendet eine Befehlszeilenschnittstelle, um Befehle von einem Benutzer in Form von Textzeilen zu empfangen, dass die API des Daemons aufruft. Registries enthalten Images, und der Hub ist ein weit verbreitetes öffentliches Registry. Zudem gibt es noch die Toolbox, um Docker auf Systeme zu bringen, die nicht nativ unterstützt werden. Dies wird dadurch erreicht, indem eine virtualisierte Linux-Instanz gestartet wird. Dies geschieht beispielsweise innerhalb von VirtualBox. Und Docker wird dann innerhalb dieser virtuellen Maschine ausgeführt.‎ Ein Großteil von Docker (jedoch nicht Desktop) ist Open Source. Lizenziert ist es unter der Apache-V2-Lizenz.

Docker Desktop

Während die meisten Komponenten sowohl für Windows, Mac und Linux verfügbar sind, und trotz der Tatsache, dass die meisten Container auf Linux lauffähig sind, ist Docker Desktop lediglich für Windows und Mac verfügbar. Docker Desktop ist ein GUI-Tool (Graphical User Interface / Grafische Benutzeroberfläche), welches im Wesentlichen eine virtuelle Maschineninstallation abdeckt. Diese virtuelle Maschine ist unter Linux nicht notwendig, da hier direkt die Engine lauffähig ist. Docker Desktop dient unter Windows und Mac zum Management verschiedener Komponenten und Funktionen, einschließlich von Containern, Images, Volumes (an Container angehängter Speicher), lokalem Kubernetes (eine Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen – Doch hierzu später mehr), Entwicklungsumgebungen innerhalb von Containern und vielem mehr.

Docker-Images und -Registry

Ein Docker-Image ist eine unveränderliche Datei, die im wesentlichen Sinn einen Schnappschuss eines Containers darstellt. Images werden mit dem Befehl „build“ erstellt und erzeugen einen Container, wenn sie mit „run“ gestartet werden. Images werden in einer Registry wie „registry.hub.docker.com“ gespeichert. Sie sind so konzipiert, dass sie aus mehreren Schichten anderer Images bestehen können. So muss bei der Übermittlung von Images über das Netzwerk nur eine geringe Datenmenge übertragen werden.

Docker-Container

Als Programmierer spricht man bei einem Image immer von einer Klasse und bei Containern über eine Instanz einer Klasse – bzw. über ein Laufzeitobjekt. Container sind der Grund, warum Docker so vielfältig verwendet wird: Sie sind leichtgewichtige und portable Kapselungen einer Umgebung, in der Anwendungen ausgeführt werden können.

Docker-Engine

Bei einem Blick auf die Docker-Engine und ihre Komponenten, kann man eine grundlegende Vorstellung davon erhalten, wie das System funktioniert. Mit der Engine entwickelt man Anwendungen, stellt sie zusammen, liefert sie aus und im Anschluss kann man sie ausführen, indem die folgenden Komponenten verwenden: Der Docker Deamon – Ein dauerhafter Hintergrundprozess, der Images, Container, Netzwerke und Speichervolumen verwaltet. Der Daemon „betrachtet“ ständig die Docker-API-Anforderungen und verarbeitet sie.

Die Docker Engine REST API – Eine Schnittstelle, die von Anwendungen verwendet wird, um mit dem Daemon zu interagieren. Auf sie kann über einen https-Client zugegriffen werden. Der Docker Client bzw. die CLI – Ermöglicht den Benutzern die Interaktion mit Docker. Er kann sich auf demselben Host wie der Daemon befinden oder eine Verbindung zu einem Daemon auf einem entfernten Host herstellen und mit mehr als einem Daemon kommunizieren.

Der Docker-Client bietet eine Befehlszeilenschnittstelle (CLI = Command Line Interpreter), über die man einem Daemon Befehle zum Erstellen, Ausführen und Anhalten von Anwendungen erteilen kann. Der Hauptzweck des Clients besteht darin, ein Mittel zur Verfügung zu stellen, mit dem Images aus einer Registry gezogen und auf einem Docker-Host ausgeführt werden können. Die gängigen Befehle, die von einem Client ausgegeben werden, sind: docker build, docker pull und docker run.

Portainer – Zur Vereinfachung der Arbeit mit Docker-Befehlen ist das freie, intuitive und leicht zu implementierende GUI (Graphical User Interface = Grafische Benutzeroberfläche) Portainer oft eine gute Wahl. Die Verwaltung der Engines und das komplette Management ist mit Portainer auch für kleine Projekte geeignet. Ich selbst hatte nur wenig Kontakt damit, daher bitte mit Vorsicht genießen ;). Hardwareinformationen wie die Anzahl der Prozessoren und die Größe des Arbeitsspeichers, sowie Docker-spezifische Informationen (Anzahl der Container, Images, Volumes und Networks) sind auf jeden Fall relativ leicht ersichtlich. So kann das Dockertool mit seiner übersichtlichen Weboberfläche die Standard-Docker-Funktionen und die Verwaltung übernehmen.

Kubernetes

Ein Thema, mit dem ich mich auch noch auseinandersetzen werde und es noch einen gesonderten Beitrag darüber geben wird. Im Grunde genommen ist Kubernetes ein Open-Source-System, welches mit Hilfe von Prozessautomatisierung die Verwaltung der Container übernimmt und somit Hand in Hand mit dem Docker zusammenarbeitet.

In einem Helm-Chart werden Konfigurationsdaten an Kubernetes übergeben. Dort wird konfiguriert, welche Container ausgerollt, überwacht und verwaltet werden sollen. Kubernetes löst diese Aufgabe auch mit einer hohen Anzahl an Containern problemlos. Außerdem kann Kubernetes Ressourcen perfekt einsetzen. Maschinen, die nicht benötigt werden, können entweder ausgeschaltet oder an andere Tasks weitervergeben werden, um Kosten sowie Kapazitäten zu sparen und folglich ein besseres Ressourcenmanagement zu ermöglichen.

Auf welchen Betriebssystemen läuft Docker?

Ein Docker-Container läuft mit der Engine direkt unter Linux und auf jedem Host-Computer, der die Container-Laufzeitumgebung „Docker Desktop“ unterstützt (Mac und Windows). Die Anwendungen müssen nicht an das Host-Betriebssystem angepasst werden. So kann sowohl die Anwendungsumgebung, als auch die zugrunde liegende Betriebssystemumgebung sauber und minimalistisch gehalten werden. Containerbasierte Anwendungen können so problemlos von Systemen in Cloud-Umgebungen oder von Entwickler-Notebooks auf Server geschoben werden, wenn das Zielsystem Docker und alle damit verwendeten Tools von Drittanbietern unterstützt.

Wie kann Docker installiert werden?

• Installationsanleitung für Docker Desktop (Windows)
• Installationsanleitung für Docker Desktop (Mac)
• Installationsanleitung für die Docker-Engine auf diversen Linux Distributionen

Microservices-Modell – Was ist das?

Die meisten Geschäftsanwendungen bestehen aus mehreren separaten Komponenten, die in einem sogenannten „Stack“ organisiert sind. Beispiele hierfür sind ein Webserver, eine Datenbank oder ein In-Memory-Cache. Container ermöglichen es, diese einzelnen Komponenten zu einer funktionalen Einheit mit leicht austauschbaren Teilen zusammenzustellen. Verschiedene Container können diese Komponenten beinhalten. So kann jede Komponente für sich gepflegt, aktualisiert und unabhängig von den anderen modifiziert werden. Im Grunde ist dies das Microservices-Modell des Anwendungsdesigns. Indem die Anwendungsfunktionalität in separate und in sich geschlossene Dienste unterteilt ist, bietet das Modell eine Alternative zu langsamen traditionellen Entwicklungsprozessen und unflexiblen Apps. Leichtgewichtige übertragbare Container machen es einfacher, Microservices basierende Anwendungen zu erstellen und zu pflegen.

Alles in allem trägt Docker dazu bei, die Verwaltung einer kompletten Infrastruktur wesentlich zu vereinfachen, indem es die zugrunde liegenden Instanzen leichter, schneller und robuster macht. Darüber hinaus trennt es die Anwendungsschicht von der Infrastrukturebene und bringt die dringend benötigte Portabilität, Zusammenarbeit und Kontrolle über die Softwarebereitstellungskette. Es wurde für moderne DevOps-Teams entwickelt. Das Verständnis seiner Architektur kann helfen, das Beste aus containerisierten Anwendungen herauszuholen.

Der Beitrag Docker – Verpacken, verteilen und überall ausführen – Laufzeitumgebung für Softwareanwendungen erschien zuerst auf CEOsBay.