デプロイとバージョン

アプリは POST /v1/apps で作るか、プロジェクトにその名前のアプリがなければ作成する glac deploy で作ります。image を指定すれば、同時に最初のバージョンがデプロイされます。以降のデプロイは POST /v1/apps/{app}/versions、または同じ --name での glac deploy です。

glac deploy ghcr.io/acme/api:1.4 --name api --port 8080 --ready-http /healthz
glac deploy ghcr.io/acme/api:1.5 --name api        # the next version of the same app

バージョンとは

バージョンは、アプリの動き方を変えるものから構成されます。

• イメージ（デプロイ時にダイジェストで固定。後でタグが別のものを指しても、バージョンは変わらない）
• 起動コマンドまたはその引数、ポート、準備完了のチェック
• 環境変数、シークレット、プライベートイメージをプルするためのシークレット
• サイズ、ボリュームとドライブ、起動前に書き込むファイル、ユーザー、作業ディレクトリ、停止のしかた
• 種類（存在する間ずっと動く service か、最後まで実行する job）とホスト名
• ランタイム設定（runtime、後述）

これらのどれかを変更すると、新しいバージョンがデプロイされます。バージョンは作成後に変更されることはありません。同じタグを再びデプロイしても新しいバージョンが作られます。その時点でタグが別のイメージを指しているかもしれないためです。

バージョンの resolved は、デプロイがイメージについて一度だけ調べた内容を示します。ダイジェストで示すイメージ、インスタンスに問い合わせるポート、そして unmounted_volumes（イメージがボリュームとして宣言しているパス（VOLUME）のうち、バージョンのボリュームもドライブもマウントされていないもの）です。Docker ならそこに独自のボリュームをマウントしますが、ここではそのようなパスは各インスタンス専用のディスク上のディレクトリになり、新しいバージョンには引き継がれません。glac deploy はこれについて警告します。

ほかの設定はすぐに反映され、バージョンは作られません。スケール、リージョン、キー、ネットワークルール、ラベル、ログの設定、公開するかどうか、名前です。

ランタイム設定

バージョンの runtime は、Compose ファイルの ulimits、sysctls、tmpfs、dns、shm_size が求めるものを設定します。インスタンスのマシンは、テンプレートを保存する前、起動時にこれを適用し、制限は起動コマンドと、インスタンス内で実行するすべてのコマンドに適用されます。

• ulimits：Docker の名前による制限（nofile、nproc、memlock、stack など）。ソフトリミットとハードリミットの両方に使う数値か、{soft, hard} で指定し、-1 は制限なしです。開けるファイル数は 1〜1,048,576 です。指定しなければ、Docker と同じく、開けるファイル数は 1,024 で、最大 524,288 まで引き上げられます。
• sysctls：Docker がコンテナに設定を許すカーネル設定（net.*、kernel.shm*、kernel.msg*、kernel.sem、fs.mqueue.*）。それ以外は拒否され（400、その設定名を示す）、マシンのカーネルにない設定はバージョンのビルドを失敗させます。
• tmpfs：インスタンスのメモリ上に置く最大 16 個のファイルシステム。それぞれ {path, size_bytes, mode} で指定します（指定しなければメモリの半分、モード 1777）。マシン自身のパス（/proc、/sys、/dev、/run）、プラットフォームのパス、ボリュームのパスには重ねられません。
• dns：イメージのものの代わりに使う /etc/resolv.conf（{servers, search, options}）。プロジェクトのプライベートネットワーク上では、プラットフォームがそのサーバーに代わって問い合わせに応答し、プロジェクトの名前を先に解決します。
• shm_size_bytes：/dev/shm のサイズ。指定しなければメモリの半分です。

glac deploy postgres:16 --name db --ulimit nofile=65535 --sysctl net.core.somaxconn=1024 --shm-size 1g
glac cube update db --reset runtime        # none again

--ulimit、--sysctl、--tmpfs /scratch:size=64m,mode=1770、--dns、--dns-search、--dns-option、--shm-size のどれかを指定すると、バージョンのランタイム設定全体が置き換わります。SDK と MCP サーバーの cube_deploy は runtime を受け付けます。サンドボックスも作成時に同じ runtime を受け付けます（サンドボックスの作成）。

glac cube update api -e KEY=value は 1 つの変数を設定し、ほかの変数はそのまま残します。API と SDK では、デプロイに渡した env と secrets がバージョンのすべてになります。

デプロイの流れ

プラットフォームはイメージをプルし、アプリが動く各リージョンのマシンで起動し、準備完了のチェックを待ってから、動いているサービスをテンプレートとして保存します。インスタンスはこのテンプレートのコピーなので、どのインスタンスでもサービスはすでに動いています。

バージョンは building から、ready か failed になります。準備ができると、アプリのトラフィックを受け取ります。古いバージョンで処理中のリクエストには応答し、新しいリクエストは新しいバージョンに送られ、リクエストは 1 つも失われません。立ち上がらなかったバージョンは failed になり、イメージの最後の出力が error に入り、トラフィックは元のバージョンのままです。ディスクにバージョンを置く空きがないマシンは飛ばされ、同じリージョンで空きのある別のマシンが使われます。どのマシンにも空きがなければ、バージョンはすぐに失敗します（drive_full。マシンのディスクの使用率付き）。バージョンを何も受け取らないマシンで building のまま放置されることはなく、2 分後に、マシンが返した内容とともに失敗します（deploy_stalled）。glac deploy はバージョンを待ち、失敗すると 1 で終了します。--no-wait ならすぐに戻ります。

glac cube versions api       # newest first: building, ready or failed, and which has the traffic

ロールバック

{"version": …}（番号か ID）を付けた POST /v1/apps/{app}/rollback、または glac cube rollback api 3 で、トラフィックを ready の別のバージョン（古くても新しくても可）に送ります。バージョンを指定しなければ、コマンドラインは現在より前で準備ができている最新のバージョンを選びます。

マシンは、トラフィックを受けているバージョン、ビルド中のバージョン、そして準備ができた最新 3 つのバージョン（プラットフォームが決める数で、どのアプリでも同じ）のテンプレートを保持します。そのため、これらへのロールバックではトラフィックがすぐに移ります。テンプレートが消去された古いバージョンは先にビルドし直され、準備ができた時点でトラフィックが移ります。デプロイと同じく、その完了を待ちます。すべてのバージョンは glac cube versions に残り、一度でも準備ができたバージョンならどれにでもロールバックできます。

アプリの削除

glac cube rm api（DELETE /v1/apps/{app}）で、アプリの名前が解放されます。処理中のリクエストにはさらに最大 30 秒応答し、WebSocket は閉じられ、その後インスタンスが削除されます。ログは、プランがログを保持する期間中、アプリの ID で引き続き読めます。

制限

アカウントのすべてのプロジェクトのアプリの数には上限があり（超えると 403 app_limit_reached）、1 つのアプリの環境変数とシークレットの合計数にも上限があり（403 env_limit_reached）、アカウントが 1 時間に作成できるアプリとバージョンの数にも上限があります（403 plan_cap_reached、Retry-After 付き）。

その他の制限は制限を参照してください。