静的サイトを公開する前に、新しい版を確かめる場所が要る。 人が見る確認用の画面は、ログインで閲覧者を限定しておきたい。 一方で、AIやスクリプトによる自動の確認は、人と同じログインを通れない。
本稿では、CloudFrontの継続的デプロイを使っている静的サイトで、人は認証付きの確認用配信から、自動の確認は本番ドメインへヘッダーを付けてStagingから、同じ公開前の版を確かめる構成を整理する。 当社のサイトの公開手順で採った構成で、経路を分けるときに決めたことと、運用で注意する点を示す。
1. 前提: 継続的デプロイの配信と、確認用の配信
CloudFrontの継続的デプロイ（CloudFront continuous deployment）は、本番の配信（Primary）とStagingの配信を組にして使う。 Stagingの設定で新しい版を試し、よければ昇格（Promote）でStagingの設定をPrimaryへコピーする。
公開前の版を人が確かめるために、Stagingとは別に、確認用の配信を置いている。 確認用の配信はStagingと同じ版を参照し、エッジでログインを求めて閲覧者を限定する。
別の配信を置く理由は、Stagingの配信へ直接アクセスできないためである。 閲覧者はStagingのドメイン名、IPアドレス、別名のどれでも直接リクエストできず、本番の配信へのリクエストの一部が、継続的デプロイのポリシーに従ってStagingへ送られる。
2. 振り分けの方式を選ぶ
継続的デプロイのポリシーには、振り分けの方式が2つある。
重み方式は、実際の閲覧者で新しい設定を試すカナリアリリースに向く。 ただし公開前の版を確かめる目的では、確認が済む前の版が一般の閲覧者の一部に出るうえ、確認する側のリクエストがStagingに届くかは確率で決まる。
そこで、自動の確認にはヘッダー方式を選んだ。 ヘッダーを付けないリクエストは本番の配信のまま処理されるため、一般の閲覧者には影響しない。
3. 人と自動の確認で経路を分ける
閲覧者を認証で限定したい場合は、確認用の配信で担保する。 Stagingの経路には認証がなく、見られにくさの根拠はヘッダーの名前と値が知られていないことだけである。
このため、ヘッダーの値は秘密情報として扱わないと決めた。 ヘッダーの名前と値は、インフラを定義するコード（IaC）とその状態ファイルに平文で残る。リポジトリや状態ファイルを読める人には分かる前提である。
この前提を受け入れられるのは、Stagingで見られるのが近く公開する予定の版だからである。 確認用の配信とStagingは同じ版を参照するので、ヘッダーの経路が使える間は、確認用の配信の中身も認証なしで見られる。 中身そのものを厳密に隠したい版では、ヘッダーの経路を開かない運用が要る。
4. 公開までの流れ
- 新しい版を配置し、Stagingと確認用の配信をその版へ向ける。
- 継続的デプロイのポリシーを有効にする。
- 自動の確認が、本番ドメインへヘッダーを付けて版の目印を取得し、公開前の版が返ったかを確かめる。
- 一致したら、同じヘッダーでページを検査する。
- 人が確認用の配信で内容を確かめる。
- 昇格する。CloudFrontはStagingの設定をPrimaryへコピーし、ポリシーを無効にする。以後、すべてのリクエストがPrimaryで処理される。
ポリシーの有効化は、IaCではなく運用の手順で行っている。 昇格のたびにCloudFront側でポリシーが無効になるため、IaCで有効・無効の値を持つと、実際の状態とすぐに食い違うからである。
当社の環境では、昇格の後もPrimaryとStagingにポリシーの紐付けが残ることを、操作の記録で確かめている。 それでも、配置の手順ではポリシーを有効にする前に紐付けを確かめ、なければ付けるようにしている。
5. 返った版を突き合わせる
ヘッダーを付けても、Stagingに届くとは限らない。 CloudFrontのサービス全体が混み合う時間帯は、ポリシーの設定に関係なく、すべてのリクエストがPrimaryへ送られることがある。
そのまま検査すると、公開中の版を公開前の版だと思い込んで合格させてしまう。 そこで、成果物に版の目印（配置した版の名前を書いた小さなファイル）を含め、自動の確認は最初にそれを取得する。
ページを検査するときも、ヘッダーは検査対象のドメインへのリクエストだけに付ける。 外部のサービスへ送るリクエストにまで付けると、ヘッダーの値を外部へ渡すことになる。
6. 運用で注意すること
本番と同じ配信経路で確かめると、手元の確認では見つからない問題も見つかる。 当社では、配信の応答ヘッダーで指定しているコンテンツセキュリティポリシーが、UIのライブラリがCSSに埋め込んだフォントを許可しておらず、ブラウザが読み込みを拒否していたことが、この確認で分かった。 手元の確認用サーバーは同じヘッダーを返さないため、それまでの検査では出ていなかった。
7. まとめ
公開前の確認は、誰が見るかで守り方が変わる。 人のための経路は認証で限定し、自動の確認のための経路は「見られても困らない」前提で開き、届いた先を毎回確かめる。 経路ごとに前提を決めておくと、確認の自動化とアクセスの限定を両立できる。