zero

zero (ShipZero) とは？

zero は、自社インフラ上で Docker イメージを実行するためのシングルサーバー向けデプロイエンジンです。コマンドラインのワークフローを提供し、イメージのデプロイ、HTTPS の自動プロビジョニング、健康チェック後のトラフィックルーティングを自動化します。

主な目的は、コンテナイメージからライブエンドポイントへの移行で発生する一般的なセットアップ作業を排除することです。設定ファイル、Web UI、YAML を必要としません。また、同じコマンド駆動型アプローチでプレビューデプロイとロールバックもサポートします。

主な機能

• コンテナイメージからの1コマンドデプロイ: zero deploy でレジストリ（例: ghcr.io/...）の任意の Docker イメージをデプロイし、アプリケーションのポートを自動検出します。
• HTTP リダイレクト付き自動 HTTPS: デプロイフロー内で Let’s Encrypt による HTTPS をプロビジョニングし、HTTP → HTTPS リダイレクトを有効化します。
• ヘルスチェックによるゼロダウンタイムのトラフィック切替: 一時ポートで新しいコンテナを起動し、TCP または HTTP ヘルスチェックを実行。チェックに成功した場合のみトラフィックを切り替えます。
• プレビュー環境: --preview <name>（例: pr-21）を使用して一時デプロイを作成し、専用サブドメインを割り当てます。プレビューは自動的に期限切れになります。
• 即時ロールバック: zero rollback <app> で前のイメージを起動し、ヘルスチェックを実行してトラフィックを戻します。チェックに失敗した場合は変更を適用しません。
• ライブ端末メトリクスとログ: CPU、メモリ、ネットワーク統計を端末にストリーミングし、zero logs --server でサーバーログもストリーミング可能です。
• Webhook 自動デプロイ: HMAC-SHA256 で署名された Webhook リクエストを検証し、レジストリイベントからデプロイをトリガー。タグが一致しない場合はプレビューデプロイを作成します。
• マルチコンテナアプリ向け Docker Compose 対応: エントリーサービスと名前を指定して Docker Compose ファイルをデプロイ。プル、起動、ヘルスチェック、ルーティングを処理します。

zero の使い方

1. サーバーのセットアップ: Linux VPS とドメインを用意します。
2. zero のインストール:
   • VPS 上: curl -fsSL https://shipzero.sh/install.sh | sudo bash
   • ローカルマシン（CLI）: curl -fsSL https://shipzero.sh/cli/install.sh | bash
3. SSH 経由で接続: zero login <email-or-identifier>（例: zero login [email protected]）。
4. イメージのデプロイ: zero deploy <image-reference>（例: zero deploy ghcr.io/shipzero/demo:latest）。
5. 出力の確認: ヘルスチェック後、zero がライブ URL（ドメインと検出ポートに基づく）を表示します。

プレビューの場合、--preview を使用（例: zero deploy demo --preview pr-21）。ロールバック時は zero rollback <app> を実行します。

ユースケース

• 単一の Docker 化 Web アプリのデプロイ: イメージをビルドしてレジストリにプッシュ後、zero deploy <image>:latest で HTTPS エンドポイントとヘルスチェック付きトラフィック切替を取得。
• プルリクエストのレビュー用プレビュー: --preview <identifier> を渡して PR ごとにプレビューを作成し、生成されたサブドメイン URL をレビュアーと共有。
• リリース時の安全なロールバック: 新しいコンテナがヘルスチェックに失敗したり異常動作した場合、zero rollback <app> でダウンタイムゼロ（ヘルスチェック成功後のみ切替）で元に戻す。
• レジストリからの継続デプロイ: Webhook エンドポイント URL とシークレットを設定し、署名付き POST でデプロイをトリガー。タグで通常デプロイかプレビューかを分岐。
• マルチコンテナサービスのデプロイ: Docker Compose で記述されたアプリの場合、zero deploy --compose <file> --service <name> --name <stack> で compose ファイルの全サービスをデプロイし、エントリーサービスのトラフィックをルーティング。

FAQ

• ここでの「ゼロダウンタイム」とは？
  新しいコンテナを起動し、TCP または HTTP ヘルスチェックを実行後、原子的にルートを切り替えます。チェック失敗時は前のバージョンにトラフィックが留まります。

• zero は設定ファイルや YAML を必要とする？
  ページでは 設定ファイル不要、Web UI 不要 と明記されており、通常のワークフローで YAML を回避します。

• zero はどのように HTTPS を有効化する？
  Let’s Encrypt を使用して自動的に HTTPS をプロビジョニングし、HTTP リダイレクトも実行します。

• 単一イメージだけでなく複数コンテナをデプロイ可能？
  はい。Docker Compose 対応があり、compose ファイル、エントリーサービス、デプロイ名を渡します。

• プレビューはどのように作成・管理する？
  --preview <name> を渡して作成し、ライブサブドメイン URL を生成。ページではプレビューが自動期限切れになると記載されています。

代替案

• 従来のPaaS (platform-as-a-service): これらのサービスはHTTPS、プレビュー、デプロイフローを管理しますが、通常は自社サーバーではなくプラットフォーム上で動作します。柔軟性や「サーバー所有」の制御をトレードオフする可能性があります。
• 自前リバースプロキシ + 手動コンテナオーケストレーション: 自前のツールで類似のHTTPSやルーティングを実現できますが、ワークフローはより手動です（サービス起動/停止、ヘルスチェック、ルーティング切替、証明書を自分で扱います）。
• 汎用コンテナデプロイツール (CLIベースのオーケストレータ): 単一ホストにコンテナをデプロイするツールは類似の手順をカバーできますが、設定ファイルの追加、カスタムルーティング、手動ヘルスチェックやロールバックロジックが必要になる場合があります。
• マルチノードデプロイ用のKubernetes: マルチノードオーケストレーション、RBAC、Webダッシュボードが必要なら、zeroのような単一サーバーデプロイエンジンとは異なる選択肢としてKubernetesが適します。