本文へスキップ

サービス設定 ​

サービスの Settings タブには、ビルドと実行の方法がまとまっています。Save で変更を保存し、変更は次のデプロイで反映されるので、準備ができたら Redeploy をクリックします。変数には専用のタブ(環境変数)があり、ドメインとポートも同様です(Networking)。

名前、ホスト名、ID ​

  • Service Name はコンソールに表示される名前です。変更しても動いているものには影響しません。
  • Private hostname は、プロジェクトの他のサービスがこのサービスに接続するときの名前で、<hostname>.zenavo.internal になります(プライベートネットワーク)。小文字、数字、ハイフンが使え、先頭は英字です。変更は次のデプロイで反映されます。古いアドレスを使っている箇所も更新してください。
  • Service ID は恒久的で再利用されません。ボリューム、ログ、API のルートがこれを使います。API や CLI で使うときはここからコピーしてください。

設定ファイル ​

Configs → Open Config Editor で、イメージを変えずに Nginx の設定や JSON の設定ファイルなどをコンテナにマウントできます。ファイルごとに次を設定します。

  • Mount path:コンテナ内のファイルのフルパス。例:/etc/nginx/conf.d/default.conf。
  • Mode:8 進数のパーミッション(デフォルトは 0644)。
  • 内容。
  • Replace ${VARIABLE} references with the service's variables:デプロイ時に環境変数の値を埋め込むので、シークレットは変数に置いたままにできます。

設定ファイルは変数と同じく暗号化して保存され、Kubernetes Secret としてサーバーに書き込まれます。コンテナ内では読み取り専用です。アプリが変更して保持するファイルにはボリュームを使ってください。

ソースとビルド ​

Zenavo がビルドするサービスでは、Source と Build のセクションに、リポジトリとブランチ、Root directory、Dockerfile、Auto deploy、Watch paths、Build arguments、zbpack options があります。GitHub、ビルドプラン、ローカルディレクトリを参照してください。Docker イメージを実行するサービスにはイメージが表示され、ビルドするものはありません。

起動コマンド ​

イメージを変えずに、コンテナが実行するものを上書きします。

項目上書きするもの例
Startup Command (ENTRYPOINT)イメージの ENTRYPOINTdocker-entrypoint.sh
Arguments (CMD)イメージの CMD(エントリーポイントに渡されます)npm run start:prod

空欄ならイメージのデフォルトを使います。値はシェルを通さずに直接実行されます。空白を含む部分は引用符で囲み、&&、|、$VARIABLES が必要なら sh -c "…" と書きます。例:sh -c "npx prisma migrate deploy && node server.js"。

ヘルスチェックとクラッシュ上限 ​

Health Check は、新しいインスタンスがトラフィックを受けられる状態になったかを判断します。ヘルスチェックを参照してください。

Automatic Restart After Crashes Attempts はクラッシュ上限です。1 つのインスタンスが何回再起動したらサービスを一時停止するかを決めます。-1(デフォルト)は無制限に再起動し、0 は最初のクラッシュで一時停止します。一時停止されると Service suspended の通知が送られます。

リソース制限 ​

デフォルトでは、サービスはサーバーにある CPU とメモリをすべて使えます。同じサーバー上の他のサービスを圧迫しないよう、インスタンスごとに上限を設定できます。

  • CPU (m):ミリコア単位。1000 で 1 コア、500 で半分。上限に達したサービスは遅くなるだけで、停止はしません。
  • Memory (Mi):MiB 単位。超えたサービスは強制終了されて再起動し(メモリ不足)、クラッシュ上限の回数に数えられます。

空欄なら制限はありません。メモリは普段の使用量より十分な余裕を持って設定してください。サービスの Usage タブで使用量を確認できます(メトリクス)。

レプリカ ​

Replicas を使うと、プロジェクトのサーバー上でサービスのインスタンスを最大 20 個まで動かせます。トラフィックは準備のできたインスタンスに分散され、デプロイ時は 1 つずつ置き換えられるので、1 つのインスタンスがクラッシュしたり置き換わったりしてもサービスは応答を続けます。

  • レプリカは同じサーバー上で動くので、プロセスのクラッシュには備えられますが、サーバーのダウンには備えられません。
  • ボリュームのあるサービスは、ボリュームをインスタンス間で共有できないため、複数のレプリカを使えません。
  • 各レプリカには上記のリソース制限がかかり、メモリはそれぞれ独立しています。セッション、アップロード、キャッシュはプロセス内ではなく、データベース、Redis、オブジェクトストレージに置いてください。

一時停止と削除 ​

Danger Zone で:

  • Suspend Service はサービスを停止し、Resume Service するまでアクセスできなくなります。設定、ドメイン、ボリュームは残ります。ロールバックと一時停止を参照してください。
  • Delete Service は、サービス名を入力するとプロジェクトからサービスを削除します。サービスは次のデプロイ(プロジェクトの Settings にある Deploy all)で停止します。ボリュームはプロジェクトを削除するまでサーバーに残ります。このサービスに依存していたサービスは、その起動を待たなくなります。

マニフェストでは ​

同じ設定は、プロジェクトのマニフェストにあるサービスのフィールドです(Settings → Advanced → Edit JSON、または API)。

json
{
  "name": "web",
  "hostname": "web",
  "entrypoint": ["docker-entrypoint.sh"],
  "command": ["npm", "run", "start:prod"],
  "configs": [{ "path": "/app/config.json", "content": "{\"apiUrl\": \"${API_URL}\"}", "mode": 420, "envsubst": true }],
  "crash_limit": 5,
  "cpus": 0.5,
  "memory_mb": 512,
  "replicas": 2
}

JSON の mode は 10 進数(420 が 0644)、cpus の単位はコアです。

Zeabur とは関係ありません。