Heute möchte ich dir Container näherbringen.
Dabei beleuchten wir, was Container sind, weshalb man diese verwendet und welche Vor-und Nachteile diese mit sich bringen.
Für Verständniszwecke werden nicht alle Begriffe vertieft, falls Interesse da ist, kann dies in einem eigenen Beitrag beleuchtet werden.

Was sind Container?

Im letzten Beitrag haben wir das Thema virtuelle Maschinen angeschnitten, doch hier muss immer das Betriebssystem virtualisiert werden.
Das bedeutet, man hat nicht immer die gleiche Umgebung. Was ist also, wenn man die Anwendung (Applikation) nimmt und diese „virtualisiert“?

Dabei werden Bestandteile einer Anwendung in einen „Behälter“ gegeben.
Dieser Behälter kann dann immer wieder „schnell“ neu „ausgepackt“ werden, und das mit dem gleichen Zustand wie es „verpackt“ wurde.
Ähnlich wie reale Container funktionieren.

Man gibt etwas rein und nimmt es im gleichen Zustand wie es rein gegeben wurde wieder raus.
Container kann man als Weiterentwicklung von Virtualisierung ansehen, da du es auf die Basics hiervon aufbaust.

Deshalb verwendet man Container

Container haben viele Gründe.
Die beiden Wichtigsten sind, dass Anwendungsstacks (Applications stacks) schnell, einfach und immer gleich deployed (bereitgestellt) werden können.

Damit ist gemeint, dass ich einen Zusammenschluss von Anwendungen habe, die zusammenarbeiten müssen, um diese effizient aufsetzen zu können.
Gleichzeitig verwenden Container ein „eigenes“ Netzwerk, welches getrennt von der „Host“ Maschine ist.
Mit Host Maschine ist die Maschine gemeint, auf der du deine Container betreibst.
Grade Anwendungsentwickler, die oft und schnell eine neue Umgebung brauchen, haben hierdurch die Option unabhängig von Infrastruktur Technikern zu arbeiten.

Denn wenn die Entwicklung und Testumgebung bereits als Container Verbund verfügbar ist, kann der Entwickler sich eine Umgebung selbst aufbereiten.

Das ist grade für Unternehmen praktisch, da die Entwickler so effizienter arbeiten können und die Infrastruktur Techniker (auch gerne IT-Administrator oder System Engineer genannt) weniger ausgelastet werden und an ihren eigenen Projekten arbeiten können.
Doch nicht nur für Entwickler, sondern auch für Privatkunden und Unternehmen ist das interessant.
Einige Hersteller, wie z.B. Bitwarden, erlauben eine selbst betriebene Instanz des Password Managers.

Hierzu wird von Bitwarden die Installation über Container empfohlen und auch als einzige Installationsmöglichkeit supportet.
Denn wie bereits angemerkt, werden die Container Umgebungen vorbereitet paketiert und als Kunde erhält man sofort eine Installation wie vom Hersteller gedacht.

Bitwarden verwendet als Beispiel 11 verschiedene Container.
Dazu gehören auch ein Webserver und die Datenbank.
Also können ganze Dienste „containerisiert“ werden.
Hierzu wird von Bitwarden die Installation über Container empfohlen und auch als einzige Installationsmöglichkeit supportet.

Du kannst auch Container verwenden

Um Container zu verwenden, erfordert es nicht viel.
Du benötigst „nur“ einmal die eingeschaltete Funktion der Virtualisierung deiner Hardware und du musst dich für eine Container Basis entscheiden.

Den Container gibt es in einigen technischen Geschmacksrichtungen.
Die Bekanntesten sind Docker, Podman und LXC, dabei sei erwähnt, dass es noch einige mehr gibt.
Doch diese 3 sind soweit ich weiß, am meisten bekannt und verbreitet.

Container können auf fast allem betrieben werden, sei es auf einem PC, Laptop, Single Board Computer (SBC) ebenso auf einem Raspberry Pi oder auch auf Mini PCs.
Es gibt also keinen Grund es nicht auszuprobieren!
Ein beliebtes Projekt wie Bitwarden oder Pi-Hole sind auch als Container Installation verfügbar.

Attribute aká Vor-&-Nachteile von Container

Natürlich wie immer gibt es beides, wobei ich den Begriff Attribute bevorzuge.
Wir kennen es jede Stärke kann im falschen Kontext eine Schwäche sein.
Eine Schwäche wiederrum im richtigen Kontext als Stärke.

Nachteile

Zu den Nachteilen von Containern zählen, wie bei der Virtualisierung, dass diese nicht die gleiche Performance liefern, wie, als würde die Anwendung direkt auf einem Rechner laufen.

Das liegt an verschiedenen Faktoren, wie bei der „klassischen“ Virtualisierung, einer ist das immer erst auf Hardwareebene die Instruktionen abgearbeitet werden müssen und dann erst in den Container übergeben werden können.
Anmerkung: Man kann auch Container in einer VM verwenden, das nennt man dann Nested Virtualization.

Container Verbünde/Stacks können „schnell“ unübersichtlich werden.
Grade wenn man viele Container verwendet, muss eine Ordnung vorhanden sein.
Dies ist für Menschen allgemein nicht einfach umsetzbar, daher wird bei einer größeren Anzahl von Containern empfohlen eine „Verwaltung/Orchestration“ einzubinden.
Dieser kann nicht nur Übersicht liefern, sondern bietet meistens eine grafische Oberfläche, wodurch man auch weniger auf der Kommtandozeile Unterwegs sein muss.

Solange Container aus einem bekannten und vertrauenswürdigen Repository (kurz Repo), also ein Verzeichnis, verwendet wird, kann man davon ausgehen, dass die Container nicht schädlich sind.
Doch man kann auch „unbekannte“ oder „nicht signierte/kontrollierte“ Repos verwenden.
Das kann verschiedenste Gründe haben und birgt wie immer die Vertrauensfrage.
Daher ist hier zu empfehlen, grade am Anfang, nur offizielle Repositories zu verwenden, die von der Containertechnologie empfohlenen werden.

Ein weiterer Nachteil ist, dass Container dazu treiben, trotz ihrer Isolierung, die Sicherheit zu vernachlässigen.

Das geschieht grade deswegen, weil Container zwar isoliert laufen, doch entweder mit anderen Containern kommunizieren oder auch durch ein Komplimentieren der Host Maschine angegriffen werden können.

Auch werden Anwendungen im ersten Schritt auf Effizienz ausgelegt und nicht auf Sicherheit, was problematisch werden kann.
Grade wenn man nicht weiß, wie Container abgesichert werden können oder wenn die Anwendung auch als Stand Alone bzw. als nicht Container Installation angeboten werden.

Wichtig ist auch das Container „flüchtig“ sind, das heißt, dass im Standard beim „Herunterfahren“ von einem Container nicht nur der Container verworfen wird, sondern auch alle Daten die IM Container angefallen sind. Das können Dateien sein oder auch Konfigurationen.
Denn Container kommen in einem „Ready to Config“ Zustand, was bedeutet initial muss die Config selbst vorgenommen werden, was meist durch Interaktive Container Skripte oder grafische Oberflächen bewerkstelligt wird.

Man kann jedoch mit zusätzlichen Konfigurationen so genannte „persistent Mounts“ Punkte definieren.
Hier werden Daten aus dem Container mit einer Speicherlokation auf dem Host gespiegelt.
Bei Docker gibt es zusätzlich zu „persistent Mounts“ sogenannte Docker Volumens.

Vorteile

Wie bereits mehrmals erwähnt sind Container schnell und einfach aufgesetzt, wodurch der Betrieb effizient aufgenommen werden kann.
Das macht es grade für „Einsteiger“ und Entwickler einfacher Infrastrukturen zu betrieben.
Grade hierdurch sind auch „Updates“ einfacher, denn ich kann den Container verwerfen und die neuste Version des Container Image beziehen und diese ausspielen.
Habe ich noch „persistent Mounts“ definiert, wird automatisch z.B. meine Konfiguration eingespielt, oder auch meine abgelegten Daten. Der Wartungs- und Verwaltungsaufwand für die Anwendung selbst ist somit gesunken.

Grade weil Container isoliert sind, ist das Thema Debugging (Fehlersuche) vereinfacht, da man schneller herausfindet welche Komponente der Anwendung einen Fehler hat.
Dadurch können effizienter Lösungen und „Fixes“ eingespielt werden.
Auch ist es praktisch das hierdurch nicht direkt die gesamte Anwendung Probleme hat, sondern nur ein Teil.
Es kommt natürlich darauf an welchem Teil, dennoch ist es praktisch, wenn z.B. mein API Schnittstelle Container Probleme hat, ich dennoch auf den Webserver zugreifen kann.

Skalierbarkeit ist bei Servern und Anwendungen immer ein Thema und Container sind äußerst skalierbar.
Damit ist gemeint, wenn meine Anwendung anfänglich gut performant und mit der Zeit dem Andrang von Anfragen nicht gewachsen ist, kann eine weiterer Container (Stack) erstellt werden der mit dem vorherigen Container zusammen im Verbund arbeitet.

Der wohl signifikanteste Vorteil ist, dass Container Plattform unabhängig sind.
Bedeutet, wenn meine Anwendung als Container vorhanden ist, kann diese unabhängig vom Betriebssystem angeboten werden.
Lediglich die Containertechnologie muss unterstützt werden, jedoch muss die Anwendung nicht für mehrere Plattformen umgeschrieben werden.
Somit sinkt natürlich der Aufwand der Entwicklung.

Meine Meinung

Aus meiner Sicht bergen Container ein großes Potenzial, weshalb ich es als Schritt in Richtung Zukunft sehe.
Dadurch werden Virtuelle Maschinen jedoch nicht ersetzt, sondern ergänzt aus meiner Sicht.
Denn nicht jede Anwendung lässt sich als Container anbieten und das kann verschiedenste Gründe haben.

Auch das Umgebungen durch Container immer „gleich“ auf Anwendungsebene sind, finde ich klasse. Denn somit ist die Fehlerquote automatisch gesenkt, weshalb viele Unternehmen oder auch Privatpersonen in den Genuss von Anwendungen kommen können, ohne zu tief in die Materie der Anwendung zugehen.
Die Tatsache, dass ein Raspberry Pi in der Lage ist, je nach Anwendungen, 6 Container oder mehr gleichzeitig laufen lassen kann ist faszinierend.

The post Die Evolution der Virtualisierung: Warum Container die Zukunft sind first appeared on Dominik's Blog.