Docker Compose reicht nicht aus

• docker-compose ist ein Tool zum Umgang mit Docker-Containern, das komplexe Probleme bei der Bereitstellung von Anwendungen löst, für einfaches Self-Hosting für den Massenmarkt jedoch nicht ausreicht
• Es werden höherwertige Abstraktionen benötigt, darunter SQL-Datenbanken, lokaler Cache, persistenter Speicher, Service Discovery und Konzepte zur Ressourcenverwaltung

Die Rolle von Docker

• Docker ist ein Tool, das die Containerisierung popularisiert hat; das Host-System lässt sich mit einem Schiff vergleichen.
• Es gibt Hardware, Betriebssystem und Container-Runtime, und Container laufen innerhalb der Runtime und kommunizieren mit anderen Diensten wie Datenbanken oder Webservern.

Die Rolle von Docker Compose

• docker-compose ist ein Tool zur Definition einer Gruppe von Containern, die zusammenarbeiten, und erleichtert die Bereitstellung von Self-Hosting-Anwendungen.
• Es durchbricht jedoch standardisierte Schnittstellen und reproduziert Probleme, die Container ursprünglich lösen sollten.
• Beispiel: Pihole
  • Pihole ist ein DNS-Server und benötigt eine komplexe docker-compose-Datei.
  • Es müssen Container-Namen, Images, Ports, Umgebungsvariablen, Volumes, Zusatzfunktionen, Restart-Richtlinien usw. konfiguriert werden.
  • Die komplexe Konfiguration muss vom Nutzer selbst verwaltet werden; das ist ein Nachteil von Docker Compose
• Beispiel: Jitsi Meet
  • Jitsi Meet ist komplexe Software und erzeugt eine docker-compose-Konfiguration mit 4 Containern, 7 Volumes, 9 Ports und mehr als 200 Umgebungsvariablen.
• Beispiel: Andere beliebte Self-Hosting-Anwendungen haben ähnliche Probleme
  • Es gibt verschiedene Anwendungen wie Authentik, Nextcloud, Immich, Jellyfin und Paperless NGX, und jede docker-compose-Konfiguration ersetzt Dutzende bis Hunderte von docker-Befehlen.
  • Jede Anwendung kann ihre eigene Datenbank, ihren eigenen Cache und ihren eigenen HTTP-Handler enthalten, was zu doppelter Ressourcennutzung führt.

Problempunkte

• docker-compose ist zu flexibel, zu detailliert und arbeitet auf der falschen Abstraktionsebene.
• Jede Anwendung besitzt einen HTTP-Verarbeitungsprozess, einen Cache oder eine Datenbank. Das Backup der Datenbank liegt in der Verantwortung des Systembetreibers.
• Beispiel: Reverse-HTTP-Proxy
  • Ein Reverse-HTTP-Proxy ist ein Programm, das eingehende HTTP-Anfragen an andere Programme weiterleitet. Jedes Programm muss entscheiden, ob es einen Webserver enthalten soll.
  • Mit Webserver
    • Mit eingebautem Webserver funktioniert das Programm, aber nur auf bestimmten Ports; bei mehreren Containern müssen Ports umgemappt werden.
  • Ohne Webserver
    • Ohne eingebauten Webserver werden keine Ressourcen verschwendet, aber die Anwendung muss ohne Verwaltungsoberfläche konfiguriert werden.
  • DNS
    • Eine Weboberfläche hat eine Adresse, und wenn TLS gewünscht ist, wird ein Name benötigt. Wenn mehrere Dienste auf einem einzelnen Host laufen, müssen Anfragen anhand von Domain-Namen oder Pfaden weitergeleitet werden.
  • Ports
    • docker-compose erlaubt das Freigeben und Remappen von Ports, tatsächlich müsste jedoch komplexes Networking unterstützt werden.
• Beispiel: Datenbank
  • Bei einer Datenbank werden alle Dateiänderungen gelöscht, wenn der Container entfernt wird. Ein Datenbank-Container muss daher ein Volume hinzufügen, um den Datenbankinhalt zu speichern.
  • N+1=2 oder mehr
    • Für Datenbank-Backups sind Offsite-Backups erforderlich. Wenn jeder Dienst einen separaten Datenbankserver-Prozess mitliefert, werden Rechenressourcen verschwendet.

Lösung

• Wechsel zu einer höheren Abstraktionsebene und Hinzufügen von Semantik, die zwischen Containertypen wie Datenbanken, Reverse-Web-Proxys, Cache und statischen Web-Assets unterscheidet.
• Beispiel für Semantik
  • Einführung eines neuen Konfigurationsformats, mit dem sich Anwendungsname, Build, HTTPS-Reverse-Proxy und Cache-Dienst angeben lassen.
• Lösung #1
  • Jedes Programm fordert einen Reverse-Proxy an, wodurch Duplizierung und Verschwendung vermieden werden. Der Reverse-Proxy stellt den DNS-Namen bereit und leitet alle Pfade an das Programm weiter.
• Lösung #1.5
  • Hinzufügen eines Datenbank-Abschnitts, um eine SQL-standardkonforme Datenbank anzufordern, wobei das Programm „volle“ Berechtigungen erwartet.
• Lösung für Ports
  • Jedes Programm erhält eine eigene IPv6-Adresse und kann dadurch Standard-Portnummern verwenden. Aus Sicherheitsgründen wird eine Firewall verwendet, sodass nur der Reverse-Proxy auf die Ports zugreifen kann.

Tealok – eine neue Container-Runtime

• Tealok ist eine neue Container-Runtime, die höherwertige Abstraktionen und standardisierte Schnittstellen bietet.
  • Sie kümmert sich automatisch um TLS-Zertifikate, Reverse-Proxy-Konfiguration, DNS-Einträge, Backup-Verwaltung und mehr.
  • Sie nutzt IPv6, sodass jeder Container eine unabhängige IP-Adresse hat und Standard-Portnummern verwenden kann.
  • Anwendungsentwickler können Anwendungen über standardisierte Schnittstellen ohne komplexe Konfiguration bereitstellen.
• Für Betreiber bietet sie konsistente Best Practices, geringere Ressourcenverschwendung und weniger Verwaltungsaufwand.
• Für Entwickler vereinfacht sie die Bereitstellung und verringert die Entscheidungsbelastung.
• Nutzer können Datenhoheit und Unabhängigkeit vom Cloud Computing sicherstellen.

[luminance]

Ich habe bei tealok nachgesehen, aber es ist nicht in einem Zustand, der als Alternative taugt, oder?

[savvykang]

Es wäre wirklich schön gewesen, wenn auch die Runtime entfernt worden wäre.

[tujuc]

Ich denke, es ist immer noch notwendig, mit docker-compose eine Betriebsumgebung nachzubauen und damit zu arbeiten, aber ...

Auf Basis von Erfahrungen in einer ganz speziellen eigenen Umgebung zu sagen, das sei falsch, und deshalb etwas Neues gebaut zu haben ... damit kann ich mich nur schwer anfreunden. hahaha

Das ist ein Inhalt, den man leicht missverstehen kann. hahaha...

Als ich nur die Überschrift gesehen habe, dachte ich eher: „Oh, ich mag es wirklich nicht, das in der Entwicklungsumgebung zu benutzen ...“ haha

[ilbanin00]

Ich denke, schon der Versuch, docker compose für denselben Zweck wie im Haupttext zu verwenden, ist von vornherein der falsche Ansatz.

[tujuc]

Ich stimme dem teilweise zu, aber ich denke nicht, dass der Ansatz falsch war.
In der Umgebung, in der sie arbeiten konnten, war das vermutlich das Beste :)

[GN⁺]

Hacker-News-Kommentare

• Es gibt einfache Lösungen für Probleme mit Port-Mapping und dem Backup von Daten-Volumes

  • Man kann eine separate docker-compose-Datei für die Entwicklungsumgebung verwenden, um Konfigurationen je nach Umgebung unterschiedlich zu definieren
  • Man kann ein einfaches Bash-Skript für Backups schreiben und es nach S3 hochladen

• Als jemand, der auf einem privaten Server Docker für Self-Hosting verwendet, bewerte ich die Flexibilität der Docker-Konfiguration positiv

  • Die anfängliche Einrichtung hat Zeit gekostet, danach ließ es sich jedoch leicht verwalten
  • Das Hinzufügen neuer Dienste dauert kaum noch Zeit, und aus Sicherheitsgründen wird für jeden Dienst ein Nicht-Root-Benutzer erstellt
  • Mit dem macvlan-Netzwerk werden jedem Container eine eigene IP- und MAC-Adresse zugewiesen
  • Zur Verwaltung des Reverse Proxy wird Nginx Proxy Manager verwendet, und auch mehrere Instanzen mit derselben Datenbank verursachen keine Probleme

• docker-compose wird hauptsächlich für Entwicklung oder den privaten Einsatz verwendet; V2 ist im Unterschied zu V1 ein in Docker integriertes Plugin

• In Produktionsumgebungen ist Kubernetes die bessere Wahl, während docker-compose gut für lokale Entwicklung geeignet ist

• docker-compose ist ein Produkt für kleines Self-Hosting und richtet sich an Menschen ohne technischen Hintergrund

  • Es besteht Skepsis, dass ein Wechsel zu TOML Self-Hosting einfacher machen würde

• Ein Programm zum Steuern von Docker zu schreiben ist einfacher als gedacht, und die Probleme lassen sich mit einem Python-Skript lösen

• Es wird an canine.sh gearbeitet, um die Nutzung eines Kubernetes-Clusters so einfach wie bei Heroku zu machen

  • Es wird für persönliche Projekte genutzt und ermöglicht das Hosting mehrerer Apps zu geringen Kosten

• Es ist interessant, dass Tealok an einer Alternative zu docker-compose arbeitet

• docker-compose, Kubernetes und Helm werden als falsche Abstraktionsebenen betrachtet

  • Es gibt viele Versuche, verschiedene Methoden zur Ausführung und Kommunikation von Containern zu entwickeln

• Die Behauptung, docker-compose sei die falsche Abstraktionsebene, wirkt verwirrend

  • Offenbar wird ein High-Level-Interface erwartet, das ein bestimmtes Problem löst
  • Das Problem mit duplizierten Instanzen ist bei den meisten Anwendungen kein großes Problem
  • Anwendungen zu einer bestimmten Architektur zu zwingen, würde nur in bestimmten Situationen gut funktionieren