ゼロダウンタイムデプロイのための最小限のHTTPプロキシ、Kamal Proxy

 (github.com/basecamp)
3 ポイント 投稿者 GN⁺ 2024-09-22 | 1件のコメント | WhatsAppで共有

Kamal Proxy - 最小限のHTTPプロキシでゼロダウンタイムデプロイを支援

機能

  • Kamal Proxy は HTTP プロキシであり、ゼロダウンタイムデプロイを簡単にオーケストレーションできるよう設計されている
  • Kamal Proxy の背後で Web アプリケーションを実行すると、進行中のトラフィックを中断することなく変更をデプロイできる
  • アプリケーション側の特別な協調なしでも動作する
  • Kamal の一部として設計されているが、単独でも、また他のデプロイツールと組み合わせても使用できる

簡単な概要

  • プロキシインスタンスを起動するには kamal-proxy run コマンドを使用する
  • 設定ファイルはないが、デフォルト値がアプリケーションに合わない場合はオプションを指定できる
  • たとえば、デフォルトのポート 80 ではなく別のポートでプロキシを実行するには: kamal-proxy run --http-port 8080
  • すべてのオプション一覧を見るには kamal-proxy help run を実行する

トラフィックルーティング

  • プロキシ経由で Web アプリケーションにトラフィックをルーティングするには、アプリケーションインスタンスをプロキシに deploy する
  • インスタンスをデプロイすると、プロキシで利用可能になり、それまで使用されていたインスタンスを置き換える
  • インスタンスの指定には hostname:port 形式を使用する
  • たとえば: kamal-proxy deploy service1 --target web-1:3000
  • プロキシは web-1:3000 を service1 というサービス名で登録し、ただちに HTTP ヘルスチェックを開始する
  • インスタンスが一定時間内に正常状態にならない場合、deploy コマンドはデプロイを中止し、異常終了コードを返す
  • 各デプロイは、それ以前にデプロイされていたインスタンスのすべてのトラフィックを引き継ぐ
  • 新しいインスタンスが正常状態になると、すべての新規トラフィックをそのインスタンスにルーティングする
  • deploy コマンドは、以前のインスタンスからのトラフィックが完全にドレインされるまで待機する
  • したがって、deploy が正常に戻れば、以前のインスタンスを削除しても進行中のリクエストは中断されない
  • 新しいインスタンスが正常状態になるまでトラフィックはルーティングされず、以前のインスタンスはトラフィックが完全にドレインされた後に削除されるため、ゼロダウンタイムデプロイが可能になる

ホストベースルーティング

  • ホストベースルーティングにより、同じサーバー上で複数のアプリケーションを実行できる
  • インスタンスをデプロイする際、トラフィックを提供するホストを指定できる
  • たとえば: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com
  • このようにデプロイされたインスタンスは、指定されたホストに対してのみトラフィックを受け取る
  • 各ホストごとに固有のインスタンスをデプロイすることで、同じサーバー上でポート衝突なしに複数のアプリケーションを実行できる
  • 特定のホストは同時に 1 つのサービスしかルーティングできない
  • たとえば: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com の後に kamal-proxy deploy service2 --target web-2:3000 --host app1.example.com を実行するとエラーになる
  • kamal-proxy remove service1 の後に kamal-proxy deploy service2 --target web-2:3000 --host app1.example.com を実行すると成功する

自動 TLS

  • Kamal Proxy はアプリケーション向けの TLS 証明書を自動で取得し、更新できる
  • インスタンスをデプロイする際に --tls フラグを追加して有効化できる
  • たとえば: kamal-proxy deploy service1 --target web-1:3000 --host app1.example.com --tls

環境変数で run オプションを指定

  • Docker コンテナで実行する場合のような環境では、環境変数を使って run オプションを指定すると便利なことがある
  • たとえば HTTP ポートを設定するには: kamal-proxy run --http-port 8080 または HTTP_PORT=8080 kamal-proxy run
  • 環境変数が他のものと衝突する場合は、KAMAL_PROXY_ 接頭辞を付けて区別できる
  • たとえば: KAMAL_PROXY_HTTP_PORT=8080 kamal-proxy run

ビルド

  • Go 環境が設定されていれば、ローカルで Kamal Proxy をビルドできる: make
  • または Docker コンテナでビルドできる: make docker

試してみる

  • examples フォルダで Docker Compose の設定を確認し、プロキシコマンドを試すことができる

GN⁺のまとめ

  • Kamal Proxy はゼロダウンタイムデプロイを支援する最小限の HTTP プロキシで、アプリケーション側の特別な協調なしでも動作する
  • ホストベースルーティングと自動 TLS 機能を提供し、複数のアプリケーションを同じサーバー上で実行できる
  • 環境変数で run オプションを指定できるため、Docker のような環境で便利
  • ゼロダウンタイムデプロイのために、新しいインスタンスへトラフィックをルーティングし、以前のインスタンスのトラフィックが完全にドレインされるまで待機する
  • 類似の機能を提供するプロジェクトとしては、NGINX、HAProxy などがある

関連記事

1件のコメント

 
GN⁺ 2024-09-22
Hacker Newsの意見

  • 'deploy' という用語の使い方が紛らわしい

    • 'bind'、'intercept'、'proxy' のような用語のほうが適切に思える

  • 無停止デプロイのためにシステム全体を構築するのはやりすぎ

    • Unixソケットをサポートするアプリ＋Webプロキシでも無停止デプロイは可能

  • Kamal Proxy は Docker Swarm の問題を解決するために存在している

    • Cloud 66 では Caddy と Traefik を使っていた

  • Kamal が Swarm を選んだ理由が気になる

    • 単純さが理由かもしれない
    • 複雑さは隠しきれず、結局は独自プロキシを作ることになる

  • Kamal Proxy は使ったことがないが、サポート面の問題から懐疑的

    • WebSockets、SSE、HTTP/3、さまざまな圧縮や暗号化のサポートが必要

  • HAProxy なら簡単にできそうなことに見える

    • hitless reload 機能がある

  • 'トラフィック一時停止' パターンを実装しているのか気になる

    • 数秒間トラフィックを止めてインフラ変更を実施できる

  • 無停止デプロイ（ZDD）がどう動くのか気になる

    • 2つのバージョンのアプリが同時に動作し、新しいトラフィックは新バージョンにルーティングされる
    • DB マイグレーションの問題をどう処理するのか気になる

  • Kamal 2 は auto-SSL をサポートし、1台のサーバーで複数アプリを簡単に動かせるようになるはず

  • 使い方が理解できない

    • 例によると 'web' サービスの 4 つのレプリカを起動している
    • 無停止デプロイのためには新しいターゲットへデプロイする必要がある
    • docker compose up --build --force-recreate web コマンドがすべてを無効にしてしまう
    • 明確なガイドが必要

  • タイムアウトを設定する方法があるのか気になる

  • NIH（Not Invented Here）症候群だ