デプロイ

英語版が原文です。

indx は 1 つのイメージとして出荷されます。そのイメージが API、s3 を除くすべてのエンジンエクストラ、それらのエンジンがダウンロードする重み、 そしてドキュメントサイトを運び、すべてを examples/app2.py が 1 つのオリジンから配信します （ADR-0039）。 イメージがデプロイの単位で、ターゲットはそれを動かし、その前に境界を置きます。

イメージ

Dockerfile は linux/amd64 のみをビルドします（vibrato に aarch64 のホイールがないため）。 ステージは変更がそれに依存するものだけを無効化する順に並びます。マニフェスト、サードパーティの ホイール、パッケージ、そして重みとサイトはそれぞれ自分のステージでビルドされ最後にコピーされます。

重みはそれ自体が 1 つのイメージです （ADR-0041）。 weights ターゲットが Hugging Face に到達する唯一のステージです。scripts/warm_weights.py が そこで各エンジンを構築し、それが満たす 3 つのキャッシュがイメージのすべてです。タグは w-<key> で、 scripts/weights_key.sh がモデルを名指しする 5 つのファイルをダイジェストします。2 つのワークフローは そのタグがないときだけ GHCR に公開します。以後のすべてのビルドは、CI でもデプロイでも、重みを GHCR から 取得します。ランタイムステージはネットワークを切ってウォームのスクリプトを再度走らせるので、公開された 重みがそのコードに対して完全でなければビルドは失敗します。

コマンド	すること
just infra::image::weights	indx-everything-weights:local を Hugging Face から一度だけビルド
just infra::image::build	その上に indx-everything:local をビルド
just infra::image::run	:8000 で実行
just infra::image::verify	ビルド済みイメージの証明。/health、エクストラが加えるすべての機能、サイト、Scalar
just infra::image::smoke	build のあと verify

.github/workflows/image.yml はイメージの入力が変わるたびに verify を走らせます。デプロイの ワークフローは同じ Dockerfile を自分のレジストリへ sha-<commit> のタグでビルドし、1 つのレイヤー キャッシュを共有します。

ターゲット

• AWS。Cloudflare のエッジだけを受け入れる ALB の背後の 1 つの Fargate タスク、3 つの Terraform スタック、手動起動のワークフロー。本番のデプロイです。
• Azure。マネージド証明書で自分のホスト名を直接配信する Consumption の環境の 1 つの Container App、1 つの Terraform スタック、手動起動のワークフロー。
• GCP。Cloudflare のエッジだけを受け入れる Cloud Armor の ポリシーを持つグローバルロードバランサーの背後に閉じた 1 つの Cloud Run サービス、 1 つの Terraform スタック、手動起動のワークフロー。

AWS が本番のデプロイです。Azure と GCP はそれぞれ 1 つのスタック、同じイメージ、そして変数としての モデルのレーンです。GCP は Cloudflare だけを通す境界を保ち、よそのゾーンの Host を Cloud Armor の ルールで閉じます （ADR-0053）。 Azure に境界はありません。ホスト名は DNS のみのレコードで、証明書は Azure が発行するからです。 そこでよその Host を閉じるのはホスト名によるルーティングです （ADR-0064）。 それぞれに AWS のものと同じ形の手動起動のワークフローがあり、名前の上では AWS と何も共有しません。 自分の変数、シークレット、GitHub Environment を持つので、どのワークフローも別のクラウドのホスト名を 取ることはできません （ADR-0054）。 運用者はどちらのスタックも引き続き手で適用でき、それは同じスタックです。