Voidプラットフォーム ウォークスルー：共有Cloudflareデプロイプラットフォームをインストールする

共有デプロイ基盤の構築は後回しにしがちです——開発者3人がそれぞれ自分のCloudflareアカウントにデプロイを始め、同じリリースを誰もロールバックできなくなるまでは。Voidプラットフォームのウォークスルーは、漠然とした「そろそろセルフホストすべきかも」という願望を、順序立ったチェックリストに変えることでその問題を解決します。以下では、このプラットフォームが実際に何なのか、最初にどの認証情報を揃えるべきか、コアインストールがどのような順序で進むのか、そして多くのチームが後から追加するオプションサービスについて解説する実践的なVoidプラットフォームのウォークスルーを紹介します。

この製品に関する混乱のほとんどは、ひとつの分岐点に由来します。自分自身のためにデプロイするのか、チームのためにデプロイするのか、という点です。自分のアプリをリリースするなら、Cloudflareへ直接デプロイすればよく、プラットフォームのインストールに触れる必要はありません。共有インフラを立ち上げる管理者であれば、プラットフォームこそがあなたがインストールし、保守し、URLを引き渡す対象になります。ここでは、あなたが後者の立場にあることを前提としています。

Voidプラットフォームが実際に果たす役割

Voidプラットフォームは、チームが共有のCloudflareアカウントにアプリケーションをデプロイできるようにします。この一文に価値の大半が込められています。開発者一人ひとりが自分のアカウント、トークン、ゲートウェイを配線する代わりに、管理者がひとつのプラットフォームをインストールして保守します。開発者はVoid CLIをそのURLに向け、有効化されたログイン方法でサインインし、デプロイします。

このプラットフォームは独立したホスティング製品ではありません。どちらのデプロイ先も同じアプリケーションAPIを使うため、直接Cloudflareにデプロイしたアプリをチームプラットフォームへ移すのに書き直す必要はありません。プラットフォームが加えるのは共有アクセスと保持されたデプロイ履歴です——複数の人がコードをリリースするようになると、この2つは非常に重要になります。

この区分が重要なのは、あなたの役割を定義するからです。インストール中、あなたは開発者ではなく管理者です。成功の指標は「自分のアプリが公開された」ことではなく、「一度も会ったことのないチームメイトが、私にメッセージを送らずに認証してデプロイできる」ことです。

最初に揃えるべき前提条件と認証情報

Voidプラットフォームのウォークスルーが最も早く停滞するのは、途中でプランの階層やアカウント権限が足りないことに気づいたときです。公式のVoidセルフホストプラットフォームインストールガイドがこれを前提条件と認証情報に分けているのには理由があります。それらは別々の意思決定であり、別々の担当者がいるからです。

インストーラーに触れる前に、以下のリストを順に確認してください。各行は、肩をすくめるのではなく、名前を挙げて答えられるべき項目です。

このうち2つはよく過小評価されます。1つ目はアカウントの選択です。後からプラットフォームを移行するのは、最初から専用アカウントを選ぶよりもはるかに苦痛です。2つ目はログイン方法です——これはインストール後の後付けではなく、すべての開発者が通過するゲートなのです。

Voidプラットフォームのウォークスルー、ステップバイステップ

以下の順序は、前提条件から認証情報を経てコアインストールへと、インストールガイドに沿って進みます。各ステップをゲートとして扱ってください。「完了」の列が本当に真になるまで次へ進まないでください。

ステップ1〜3：スコープ、前提条件、認証情報

まず、率直な問いへの答えを書き留めることから始めましょう。このプラットフォームは一人のためのものか、チームのためのものか？ 一人のためのものであれば、そこで止めてください——代わりにCloudflareへ直接デプロイしましょう。チームのためのものであれば、その答えはWorkers for Platformsとドキュメント化されたインフラを前提とすることを意味するので、インストールの時間枠を設定する前にそのための予算を確保してください。

ステップ4〜5：コアをインストールし、メールを有効化する

コアインストールにはマネージドSandboxとメールゲートウェイが含まれます。メールは自動的にオンラインになるわけではありません。共有メールドメインとゾーンを設定したときに有効になります。デプロイしたアプリからのトランザクションメールが計画に含まれるなら、これを「あれば嬉しい」ではなく必須ステップとして扱い、開発者を招待する前に実際の送信で検証してください。

ステップ6〜8：認証、最初のデプロイ、ロードマップ

ログイン方法を有効化し、パイロット開発者1人にプラットフォームURLを渡し、Void CLIを接続して小さなものをデプロイしてもらいましょう。その1回のテストは、どんなチェックリストよりも多くの設定問題を明らかにします。合格したら、後回しにしているオプションサービス——GitHubビルド、ビルドContainer、カスタムプロジェクトドメイン——を書き留めておき、コアに同梱されていると誰も思い込まないようにしてください。

直接Cloudflareとコアセルフホストプラットフォームの比較

これはブックマークする価値のある比較表です。「自分は実際に何を得ているのか？」という問いに答えてくれるからです。どちらのデプロイ先も同じアプリケーションAPIを共有しています。違いは共有アクセス、保持、そしてリクエストがどこを流れるかにあります。

最後の2行を注意深く読んでください。プラットフォーム上のSandboxはプラットフォームアカウントのWorkers Paidだけを必要とするのに対し、直接デプロイはローカルワークフローでのDockerも想定しています。そしてダッシュボードとマネージドGitHubビルドはどちらの側でも標準インストールの一部ではありません——オプトインする追加機能です。

ソロプロジェクトなら、左の列のほうが同じアプリケーションAPIに対して手間が少なくて済みます。チームなら、右の列の保持されたログと保持されたデプロイこそが、共有リリースのデバッグをそもそも可能にするものです。

オプションサービスと設定の落とし穴

Voidプラットフォームのウォークスルーがコアインストールを通過したら、残りの作業は任意です——ただし各オプションには設定上の影響があります。開発者が「自分のブランチプレビューがなぜないのか」と尋ねてきたときに初めて気づくのではなく、意図的に計画しましょう。

2つの習慣がこれらのほとんどを防ぎます。1つ目は、短い設定記録を残すことです。どのログイン方法が有効か、どのメールドメインが共有されているか、どのオプションサービスが稼働しているか。2つ目は、Cloudflare AccessがAPIを保護していて、GitHubサービスを備えたソースビルドプラットフォームを運用している場合は、Accessを緩めるのではなく分離されたWebhookイングレス設定に従うことです——修正はイングレス経路に属するのであって、セキュリティ態勢に属するのではありません。

最後に、チームプラットフォームはその設定に依存していることを忘れないでください。あるインストール向けに文書化された機能が、単に有効化されていないという理由であなたの環境には存在しないかもしれません。デフォルトを仮定するのではなく、自分のセットアップに対して検証してください。

FAQ

自分のアプリだけをデプロイする場合、Voidプラットフォームのウォークスルーは必要ですか？ いいえ。自分のためにアプリをデプロイするなら、Cloudflareへ直接デプロイしてください。プラットフォームのインストールは、チームが共有アクセスと保持されたデプロイ履歴を必要とするときにのみ、そのオーバーヘッドに見合います。

ユーザーダッシュボードは標準インストールに含まれますか？ いいえ。ユーザーダッシュボード、マネージドGitHubビルドとWebhook、ビルドContainer、カスタムプロジェクトドメインはコアインストールの一部ではありません。別々の追加機能として計画してください。

Sandboxを実行するためにプラットフォームアカウントは何を必要としますか？ プラットフォームアカウントのWorkers Paidです。直接Cloudflareデプロイは要件が少し異なり、SandboxにはDockerも必要とします。

コアインストール後にGitHubビルドを追加できますか？ はい——オプションサービスです。ソースビルドプラットフォームを使用していて、Cloudflare AccessがAPIを保護している場合は、分離されたWebhookイングレスを設定することで、アクセス制御を弱めることなくビルドとWebhookが機能し続けます。