Oft erhalten wir Fragen wie:
- “Unterstützt ihr Docker?”
- “Wie können wir Docker auf unserem Managed Server nutzen?”
- “Bietet ihr Managed Docker an?”
Diese Anfragen häuften sich und bisher mussten wir leider immer etwa so antworten:
“Leider ist dies momentan nicht möglich. Da Docker als root laufen muss, wären wir nicht in der Lage, den von uns erzielten Security Standards zu gewährleisten. Container sind momentan nur mit nine Managed Google Kubernetes Cluster möglich.”
Aber ab jetzt(!) können wir euch diese Antwort geben:
”ABER SICHER! UND WIE WIR DAS KÖNNEN! :D"
Realistisch gesehen, würden wir sehr wahrscheinlich etwas professioneller antworten. 😉
Nichtsdestotrotz können wir euch jetzt eine vollständige daemon- und rootless Container-Laufzeit namens "Podman" anbieten.
Wahrscheinlich denkt ihr gerade: “Moment mal... das ist aber nicht Docker? Ich wollte doch Docker!".
Und ja, ihr habt natürlich recht! Aber bitte, bleibt noch einen Moment da und lest weiter. Wir werden euch alles erklären. Vorneweg schon mal soviel: Podman ermöglicht es, Applikationen leichter zu implementieren, produktive Deployments schneller zu testen, die Implementierung drastisch zu verkürzen und sogar Dienste zu nutzen, die (noch) nicht als Managed Services verfügbar sind.
Klingt das gut? Grossartig, dann lasst uns jetzt in den spannenderen Teil eintauchen!
Podman und der Unterschied zu Docker
Als erstes: Podman ist funktionell nahezu identisch mit Docker. Beide Lösungen sind Container-Laufzeiten und können die gleichen OCI-Images verwenden. Daher ist auch die Syntax weitgehend identisch.
Der Hauptunterschied besteht darin, wie sie mit dem Container-Stack umgehen.
Lasst uns zunächst aber einen Schritt zurückgehen und die Funktionsweise von Docker etwas genauer ansehen. Dies wird uns helfen zu verstehen, was Podman so einzigartig macht.
Docker verwendet eine Client-Server-Architektur. Der Docker-Client spricht mit dem Docker-Daemon, der die umfangreiche Arbeit des Aufbaus, des Betriebs und der Verteilung der Docker-Container übernimmt. Zudem kommuniziert dieser Docker-Daemon noch mit weiteren Daemons, um sämtliche Docker-Dienste verwalten zu können.
Wenn ihr also einen Befehl wie "docker run" absetzt, sendet der Client diese Befehle über die API-Anfragen an dockerd (den Docker-Daemon), der diesen anschliessend ausführt.
Vergleichen wir dies nun mit Podman und werfen wir einen Blick auf dessen Architektur:
Der wichtigste Unterschied ist die Absenz eines zentralisierten Daemons. Wie bereits erwähnt, ist Podman eine daemonless Container-Laufzeit und das ist der wirklich coole Teil daran!
Erstens (und dieser Punkt ist riesig!) können Container von jedem Benutzer, mit oder ohne root-Rechten, ausgeführt werden.
Zweitens, kein zentralisierter Daemon-Prozess wird mehr benötigt. Jeder Container erzeugt seine eigenen Child-Prozesse und bearbeitet die Anfragen selbst (dies wird auch als Fork/Execution-Modell bezeichnet).
Diese Architektur führt zu einer viel robusteren und sicheren Container-Umgebung.
Wenn ein Container auf Docker ein Problem hat, dass den zentralisierten Daemon betrifft, könnte sich dies auch auf alle anderen Container auswirken. Bei Podman kann das aufgrund der Architektur nicht passieren.
Dazu kommt, dass die Ausführung eines Containers als Root ein massives Sicherheitsrisiko darstellt.
Je nach Image und den verwendeten Diensten könnten möglicherweise einige Schwachstellen in der Architektur ausgenutzt werden, um aus einem Container auszubrechen und root-Privilegien auf dem Host-System zu erlangen. Angesichts dessen ist es die beste Praxis, alle Container als Nicht-root-Benutzer zu betreiben.
Da ist aber noch ein weiterer grosser Vorteil für Podman gegenüber Docker: Podman kann nicht nur Container wie Docker ausführen, sondern auch Pods nutzen, welche sich bei Kubernetes findet (daher der Name "Podman").
Ein Pod ist wie ein geschlossenes System. Es kapselt einen oder mehrere Applikations-Container, einschliesslich Speicherressourcen und einer eindeutigen Netzwerkidentität (IP-Adresse) sowie Steuerungsoptionen wie die Container laufen sollen, ein.
Nehmt als Beispiel das Diagramm auf der rechten Seite:
Hier haben wir einen Pod, der zwei Container und ein Volume enthält.
Auf einem Container läuft ein Webserver, während der andere Container eine File-Puller-Applikation beinhaltet.
Der Datei-Puller extrahiert Dateien aus dem Content Manager und speichert sie auf dem gemeinsam genutzten Volumen. Der Webserver greift auf die Dateien aus dem gemeinsam genutzten Volume zu und liefert die Dateien an den Benutzer.
Trotz der drei verschiedenen internen Objekte wird dies aus externer Sicht nur als eine Entität betrachtet, da alles im gleichen Namespace läuft und daher nur eine externe IP hat.
Source: https://kubernetes.io/docs/concepts/workloads/pods/pod-overview
Wann sollte Podman verwendet werden?
An diesem Punkt werden vermutlich einige von euch die Frage haben: "Also... ist dies die perfekte Lösung für alle unsere Use-Cases oder gibt es irgendwelche Nachteile?
Nun, wenn ihr eine komplexere Infrastruktur mit hoher Verfügbarkeit und grosser Skalierbarkeit betreiben möchtet, dann solltet ihr die Verwendung unseres Managed GKE (Google Kubernetes Engine) in Betracht ziehen: https://www.nine.ch/de/produkte/gke
Für viele andere Anwendungsfälle ist diese Lösung jedoch perfekt! Sehen wir uns ein paar Beispiele an:
- Ist das Ausrollen neuer Releases immer schmerzhaft, zeitaufwendig und oft auch mit einer langen Ausfallzeit verbunden?
Dann ist es an der Zeit, die Applikation in einem Container laufen zu lassen. Dazu wird ein Image mit allen benötigten Abhängigkeiten erstellt und mit der Applikation in einem Container gestartet. Sobald eine neue Version bereit steht, wird ein neuer Container mit der neuen Version darin gestartet.
- Vielleicht möchtet ihr eine neue Website mit möglichst wenig Aufwand erstellen. Im Idealfall wäre dies eine sofort einsatzbereite Lösung, die einfach funktioniert.
Warum nicht mal schnell das beliebte Ghost CMS oder Wordpress ausprobieren? Es gibt einige coole Container-Images, die bereits mit alle notwendigen Abhängigkeiten und eine Grundkonfiguration daher kommen. Alles, was ihr tun müsst ist, einen Container von diesem Image aus zu starten und schon könnt ihr loslegen.
- Eventuell verwendet ihr Docker bereits lokal auf eurem Rechner, um eure neue Applikation zu entwickeln/testen und nun wollt ihr diese in eure Produktionsumgebung einführen.
- Ist bei euch noch eine alte Applikation im Einsatz, die PHP 5 benötigt? Podman schafft auch hier Abhilfe!
Nehmt einfach ein Image, das die benötigte PHP-Version enthält oder erstellt selbst eines und stellt die Applikation in einem Container bereit.
Bonus: Mit dieser Methode kann das Sicherheitsrisiko bei Verwendung einer veralteten Version massiv verringert werden, da die alte PHP-Version vom Host System abgeschottet ist.
Natürlich sind manchmal hier und da noch ein paar Konfigurationen erforderlich, um die Applikation in einem Container ausführen zu können. Aber für viele Mainstream-Applikationen stehen bereits fertige Images zur Verfügung.
- Vielleicht plant ihr eine Migration eurer Applikation auf unseren nine Managed GKE-Service? Höchstwahrscheinlich wird die Applikation einige Optimierungen und Anpassungen benötigen, um perfekt auf GKE laufen zu können.
Gute Nachrichten! Podman ist die ideale Lösung für diesen Fall. Es ermöglicht euch, die Applikationen für einen reibungslosen Umstieg auf GKE vorzubereiten. Podman verwendet sogar die gleichen Kubernetes YAML-Dateien.
Die Möglichkeiten mit Podman sind endlos und werden euch in vielerlei Hinsicht helfen. Wir sind sicher, ihr werdet begeistert sein 💙!
Warum sind Lösungen wie Podman erst jetzt verfügbar?
Container und Sicherheit sind ein komplexes Thema. Die Nachfrage nach einer Rootless-Container-Runtime von Seiten der Community wächst stetig.
Docker wurde angepasst, um als Nicht-root-Benutzer ausgeführt werden zu können, jedoch wurde es nicht für dieses Szenario konzipiert und reduziert daher die Benutzerfreundlichkeit und Funktionalität. Selbst dann gibt es immer noch einige Sicherheitsprobleme. Deswegen war Docker keine Lösung, die wir als Managed Service absegnen konnten.
Heute sind viele verschiedene Container-Laufzeiten verfügbar, darunter CRI-O, LXC, rtk und containerd, um nur einige der beliebtesten zu nennen. Wie ihr vermutlich bemerkt habt, hat sich keine dieser Lösungen zum klaren Marktführer entwickelt. Einige von ihnen können zwar rootless laufen, aber bei allen müssen entweder beim Funktionsumfang oder bei der Bedienbarkeit Abstriche gemacht werden.
Mitte 2017 tauchte ein neuer Konkurrent in der Arena auf - Podman:
Podman wollte die grundlegenden Architektur-Probleme von Docker lösen und dabei die gleichen Funktionalitäten bieten. Schon damals schien es ein interessantes Konzept mit grossem Potenzial zu sein und es erwies sich in den folgenden Jahren als richtig.
Mit den neuesten Versionen ist Podman nun in Bezug auf Sicherheit, Funktionalität und Stabilität fest etabliert. Aufgrund dieser Entwicklungen und Maturität der Software, sind wir nun in der Lage, euch Podman als einen unserer Managed Services anzubieten.
Nebenbei bemerkt: Red Hat unterstützt das Podman-Projekt sehr stark. Das Unternehmen hat Podman in RHEL 7.6 veröffentlicht und die Docker-Unterstützung ab RHEL 8 sogar ganz eingestellt.
Erste Schritte
Haben wir euer Interesse geweckt? Dann lasst uns anfangen Spass mit Containern zu haben!
Unser neuer Managed Simple Service "Podman" ist für alle Managed Server mit Ubuntu 18.04 oder neuer für derzeit CHF 30.- pro Monat erhältlich.
Podman kann im Handumdrehen auf Ihrem System installiert werden. Schreibt uns einfach ein Support-Ticket und wir werden euch "containerisieren"!
Einen ersten Einblick erhaltet ihr auch mit unserer Schritt-für-Schritt-Anleitung für die Einrichtung eines Ghost-CMS in einem Podman-Pod: https://support.nine.ch/a/4a1j_NF4fOQ
Wir werden in den kommenden Wochen zusätzliche Beispiele für Anwendungsfälle und deren Umsetzung mit Podman vorstellen.
Und wie immer, wenn ihr Fragen zu unseren Produkten habt, lasst es uns einfach wissen. Wir helfen euch gerne weiter!
