はじめに
サポートチームのプレビュー API がライブ環境の設定を返しており、メンテナンスのドライランではプレビュー用の認証情報が拒否されています。一方、ライブ環境は引き続き動作しています。このチャレンジでは、メンテナンスの認証を弱めたりライブ環境の動作を変更したりせずに、プレビュー環境の境界を復元します。
この独立したチャレンジでは、小規模な Worker、名前付きの 2 つのローカル環境、テスト用の合成認証情報が用意された新しい VM を使用します。ガイド付き実験で学んだ設定、シークレット読み込み、ランタイムテストの方法を適用してください。成功条件は、以下の契約を両方のローカル環境が満たした後、一時的なサーバーとシークレットファイルを削除することです。ここでいう preview と live はローカルテスト環境の名前であり、このチャレンジに Cloudflare へのログインやデプロイは必要ありません。
プレビューの分離を復元する
現在の状況
準備済みのプロジェクトは /home/labex/project/preview-drift にあります。Node 22.22.0、プロジェクトローカルの Wrangler 4.131.1、独立したテストランタイムがインストールされています。開発サーバーはまだ起動していません。用意されたハンドラーは、公開ヘルスチェックと合成メンテナンスのドライランを実装しています。問題は、プレビュー環境の公開設定と認証情報の読み込みにあります。
作業範囲
wrangler.jsonc、src/index.js、.dev.vars.preview、.dev.vars.live、.gitignore を確認します。ハンドラーと設定を調べて、バインディングの契約を見つけてください。2 つの dotenv ファイルには、それぞれ異なるランダムなテスト専用認証情報が入っています。値を表示せずにキー名だけ確認できます。認証情報はこの VM 内で非公開にし、Git の対象外にしてください。
preview の Wrangler 環境をループバックアドレスのポート 8080 で起動し、live をポート 8081 で起動します。同時に実行するランタイムには、異なるインスペクターポートを指定してください。通常のプロジェクトローカルの Wrangler 開発コマンドを使用します。このチャレンジではリモートリソースを作成しません。QUEUE_LABEL は表示用の文字列であり、キューサービスではありません。
目標
両方のローカル環境で、意図した公開情報を返し、それぞれの環境に設定された認証情報でのみメンテナンスを許可できるようにします。プレビュー環境はライブ環境から分離し、既存の公開ヘルスチェックと安全な失敗動作を維持してください。
受け入れ条件
- GET
/healthは、ステータスがokの JSON を返します。プレビューは環境preview、キューsandboxを返し、ライブは環境live、キューprimaryを返します。 - 各環境は、ハンドラーの
MAINTENANCE_TOKENバインディングを通じて自身の合成認証情報を読み込みます。2 つの認証情報の値は異なる状態にし、ソースコードと公開 Wrangler 変数の外部で管理してください。ローカル dotenv ファイルは VM ユーザーだけが読み取れる状態にし、Git の対象外にしてください。 - POST
/maintenanceは、その環境自身の有効な bearer 認証情報を指定した場合だけ、operation: dry-runと環境名を含む 200 を返します。認証情報がない場合、無効な場合、別の環境の認証情報を使った場合は、error: unauthorizedを含む 401 を返します。 - 設定済みのシークレットがない場合は、
error: maintenance_unconfiguredを含む 503 を返して安全側に倒します。GET/maintenanceは引き続きerror: method_not_allowedを含む 405 を返し、未知のルートはerror: not_foundを含む 404 を返します。 - レスポンスとアプリケーションログに認証情報の値を含めません。このステップの 2 つの検証が終わるまで、両方のローカルサーバーを起動したままにします。クラウド認証、デプロイ、レポート、成功マーカーのコピーは必要ありません。
ヒント
各公開値の取得元を比較する
まず、ハンドラーが環境値をどのように参照しているかを確認し、wrangler.jsonc の名前付き環境オブジェクトと比較してください。Wrangler の環境変数は自動的には継承されません。ランタイムが選択した環境と、その環境に設定された値は別のものです。
maintenance-unconfigured のレスポンスを調査する
設定済みバインディングがない場合と、受信した認証情報が拒否された場合を区別してください。ハンドラーが参照するバインディング名と、環境ごとの dotenv ファイルにあるキー名を比較します。ローカルファイルが存在していても、ハンドラーが読み取るバインディングが定義されているとは限りません。設定を変更した後は、ランタイムが準備完了になっていることを再確認してください。
ライブ環境の動作とセキュリティ境界を維持する
ヘルスチェックとメンテナンスを両方向でテストしてください。一方の環境で有効なトークンは、もう一方の環境では無効でなければなりません。用意されたメンテナンス操作はドライランなので、正しく認証されたリクエストをテストしてもアプリケーションデータは変更されません。
クリーンなワークスペースを残す
現在の状況
修復したローカル環境は機能チェックに合格しました。開発プロセスと合成認証情報ファイルは、まだこの VM に残っています。
作業範囲
一時的な対象は、このチャレンジで使用したポート 8080 と 8081 の開発ジョブ、.dev.vars.preview と .dev.vars.live ファイル、そしてそれらの値を保持しているシェル変数だけです。修復したソース、設定、依存関係、LabEx のサービスは保持してください。
目標
修復したプロジェクトを利用可能な状態に保ち、チャレンジのサーバーとローカルシークレットファイルを残さないようにします。
受け入れ条件
- ポート 8080 と 8081 のどちらにも、待ち受け中の開発サーバーが存在しません。
- チャレンジプロジェクトに
.dev.vars*または.env*のシークレットファイルが残っていません。 - 合成認証情報に使用したシェル変数を消去します。これは学習者が行うクリーンアップ操作であり、バックエンドから対話シェルの状態を確認することはできません。
- 無関係なプロセスとファイルは保持します。このローカルのみのチャレンジでは、削除対象のクラウドリソースや Cloudflare 認証情報はありません。
ヒント
起動したジョブを対象にする
シェルのジョブ一覧を使用して、2 つの Wrangler 開発プロセスを確認します。サーバーを再起動するとジョブ番号が変わることがあります。機能検証を先に行ってください。先にシークレットを削除すると、前の検証結果を確認できなくなります。
まとめ
プレビューの環境情報の不一致は、名前付き環境の値が原因でした。また、メンテナンスの失敗は認証情報のバインディング名が原因でした。修復により、ライブ環境の動作、公開ヘルスチェック、サーバー側の認証を維持したまま、プレビューの分離を復元できました。
認証情報なし、無効、環境をまたぐ場合、有効な場合をテストしたことで、1 件の成功レスポンスだけを確認するよりも、境界を詳しく検証できました。最後のクリーンアップでは、修復したプロジェクトを保持しながら、ローカルプロセスと合成シークレットを削除しました。
