Kamal Proxy, der minimale HTTP-Proxy für Zero-Downtime-Deployments

Kamal Proxy – Unterstützung für unterbrechungsfreie Deployments mit einem minimalen HTTP-Proxy

Funktionen

• Kamal Proxy ist ein HTTP-Proxy, der dafür entwickelt wurde, Zero-Downtime-Deployments einfach zu orchestrieren
• Wenn eine Webanwendung hinter Kamal Proxy läuft, können Änderungen ausgerollt werden, ohne laufenden Traffic zu unterbrechen
• Funktioniert auch ohne besondere Mitwirkung der Anwendung
• Wurde als Teil von Kamal entworfen, kann aber unabhängig oder zusammen mit anderen Deployment-Tools verwendet werden

Kurzer Überblick

• Um eine Proxy-Instanz zu starten, wird der Befehl kamal-proxy run verwendet
• Es gibt keine Konfigurationsdatei, aber Optionen können angegeben werden, wenn die Standardwerte nicht zur Anwendung passen
• Um den Proxy zum Beispiel auf einem anderen Port als dem Standardport 80 auszuführen: kamal-proxy run --http-port 8080
• Die vollständige Liste der Optionen ist mit kamal-proxy help run verfügbar

Traffic-Routing

• Um Traffic über den Proxy zur Webanwendung zu routen, wird eine Anwendungsinstanz beim Proxy mit deploy bereitgestellt
• Sobald eine Instanz bereitgestellt wird, steht sie dem Proxy zur Verfügung und ersetzt die zuvor verwendete Instanz
• Bei der Angabe einer Instanz wird das Format hostname:port verwendet
• Zum Beispiel: kamal-proxy deploy service1 --target web-1:3000
• Der Proxy registriert web-1:3000 unter dem Servicenamen service1 und startet sofort HTTP-Health-Checks
• Wenn die Instanz innerhalb einer bestimmten Zeit nicht healthy wird, bricht der Befehl deploy das Deployment ab und gibt einen Fehlercode zurück
• Jedes Deployment übernimmt den gesamten Traffic der zuvor bereitgestellten Instanz
• Sobald die neue Instanz healthy ist, wird aller neuer Traffic zu dieser Instanz geroutet
• Der Befehl deploy wartet, bis der Traffic der alten Instanz vollständig ausgelaufen ist
• Wenn deploy also erfolgreich zurückkehrt, kann die alte Instanz entfernt werden, ohne laufende Requests zu unterbrechen
• Da bis zur erfolgreichen Health-Prüfung der neuen Instanz kein Traffic dorthin geroutet wird und die alte Instanz erst nach vollständigem Auslaufen des Traffics entfernt wird, sind unterbrechungsfreie Deployments möglich

Hostbasiertes Routing

• Mit hostbasiertem Routing können mehrere Anwendungen auf demselben Server betrieben werden
• Beim Deployen einer Instanz kann der Host angegeben werden, für den Traffic ausgeliefert werden soll
• Zum Beispiel: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com
• Eine so bereitgestellte Instanz empfängt nur Traffic für den angegebenen Host
• Durch das Bereitstellen einer eigenen Instanz pro Host können mehrere Anwendungen ohne Portkonflikte auf demselben Server betrieben werden
• Ein bestimmter Host kann jeweils nur auf einen Service geroutet werden
• Wenn zum Beispiel nach kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com anschließend kamal-proxy deploy service2 --target web-2:3000 --host app1.example.com ausgeführt wird, tritt ein Fehler auf
• Nach kamal-proxy remove service1 und anschließendem kamal-proxy deploy service2 --target web-2:3000 --host app1.example.com ist das Deployment erfolgreich

Automatisches TLS

• Kamal Proxy kann TLS-Zertifikate für Anwendungen automatisch beziehen und erneuern
• Dies lässt sich beim Deployen einer Instanz durch Hinzufügen des Flags --tls aktivieren
• Zum Beispiel: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com --tls

run-Optionen per Umgebungsvariablen angeben

• In Umgebungen wie beim Ausführen in einem Docker-Container kann es praktisch sein, run-Optionen über Umgebungsvariablen zu setzen
• Zum Beispiel zum Festlegen des HTTP-Ports: kamal-proxy run --http-port 8080 oder HTTP_PORT=8080 kamal-proxy run
• Falls Umgebungsvariablen mit anderen Einstellungen kollidieren, können sie mit dem Präfix KAMAL_PROXY_ unterschieden werden
• Zum Beispiel: KAMAL_PROXY_HTTP_PORT=8080 kamal-proxy run

Build

• Wenn eine Go-Umgebung eingerichtet ist, kann Kamal Proxy lokal gebaut werden: make
• Alternativ kann mit einem Docker-Container gebaut werden: make docker

Ausprobieren

• Im Beispielordner kann die Docker-Compose-Konfiguration geprüft werden, um die Proxy-Befehle auszuprobieren

Zusammenfassung von GN⁺

• Kamal Proxy ist ein minimaler HTTP-Proxy für Zero-Downtime-Deployments und funktioniert auch ohne besondere Mitwirkung der Anwendung
• Er bietet hostbasiertes Routing und automatisches TLS, sodass mehrere Anwendungen auf demselben Server ausgeführt werden können
• run-Optionen können per Umgebungsvariablen gesetzt werden, was in Umgebungen wie Docker nützlich ist
• Für unterbrechungsfreie Deployments wird der Traffic auf neue Instanzen umgeleitet, während gewartet wird, bis der Traffic auf der alten Instanz vollständig ausgelaufen ist
• Projekte mit ähnlichen Funktionen sind unter anderem NGINX und HAProxy

[GN⁺]

Hacker-News-Kommentare

• Die Verwendung des Begriffs „deploy“ ist verwirrend

  • Begriffe wie „bind“, „intercept“ oder „proxy“ scheinen passender zu sein

• Für Zero-Downtime-Deployments ein komplettes System aufzubauen, ist übertrieben

  • Mit einer App + einem Web-Proxy, die Unix-Sockets unterstützen, sind Deployments ohne Unterbrechung ebenfalls möglich

• Der Kamal-Proxy existiert, um Probleme von Docker Swarm zu lösen

  • Bei Cloud 66 wurden Caddy und Traefik verwendet

• Ich frage mich, warum Kamal sich für Swarm entschieden hat

  • Vielleicht wegen der Einfachheit
  • Komplexität lässt sich nicht verstecken, und am Ende baut man doch einen eigenen Proxy

• Ich habe den Kamal-Proxy nicht verwendet, bin aber wegen Support-Themen skeptisch

  • Unterstützung für WebSockets, SSE, HTTP/3 sowie verschiedene Kompressions- und Verschlüsselungsverfahren ist nötig

• Das klingt nach etwas, das HAProxy leicht erledigen kann

  • Es gibt die Funktion für hitless reloads

• Ich frage mich, ob das Muster „Traffic kurz pausieren“ implementiert wird

  • Damit könnte man den Traffic für ein paar Sekunden anhalten, um Infrastrukturänderungen durchzuführen

• Ich frage mich, wie Zero-Downtime-Deployment (ZDD) funktioniert

  • Zwei Versionen der App laufen gleichzeitig, und neuer Traffic wird zur neuen Version geroutet
  • Ich frage mich, wie dabei das Problem mit DB-Migrationen behandelt wird

• Kamal 2 wird Auto-SSL unterstützen und es einfacher machen, mehrere Apps auf einem Server auszuführen

• Ich verstehe nicht, wie man das benutzt

  • Laut Beispiel werden vier Replikate des Dienstes „web“ gestartet
  • Für Zero-Downtime-Deployments müsste auf ein neues Target deployt werden
  • Der Befehl docker compose up --build --force-recreate web macht das alles zunichte
  • Es braucht klarere Anleitungen

• Ich frage mich, ob es eine Möglichkeit gibt, Timeouts festzulegen

• Das ist das NIH-Syndrom (Not Invented Here)