本日、HTTPアプリケーションのクローズドベータ版を発表します。これは、HTTPトラフィックへの変更を安全にテストおよびデプロイするための新しい方法です。HTTPアプリケーションは、設定のバージョン管理およびCloudflareのグローバルエッジネットワーク上のHTTPトラフィックへの変更のロールアウトを制御する機能を提供します。より高度な制御を必要とする企業のお客様は、アクセス取得のためにCustomer Successマネージャーにお問い合わせください。
設定を管理する上での問題点
Cloudflareの最初の頃から、WebサイトやWebアプリケーションの管理は、私たちがゾーンと呼ぶものを通して行われてきました。これは、DNSゾーンの概念に由来しています。このモデルは長年にわたってお客様に貢献してきましたが、エッジ設定を管理する上で、次のような困難が生じます。
ステージング環境のセットアップにお客様の手作業が必要。
本番とステージングで設定がずれるリスク。
ソフトウェア開発では、変更を本番環境に移す前、あるいはライブトラフィックに影響を与える前に安全な環境でテストを行い、その妥当性を確認したいものです。多くの一般的なソフトウェア開発ライフサイクルでは、これはテストと検証のために変更をステージング環境またはプリプロダクション環境にデプロイすることを意味します。現在お客様がCloudflare上でこれを行う最も一般的な方法は、それらのゾーンのホスト名で示される2つのゾーンの使用することです。例えば、1つは_staging.example.com_というステージング用、1つは_example.com_ という本番用のゾーンを使用します。これにより、変更を保護することができ、核心的な問題を解決することができます。ステージングゾーンでエラーが発生しても、本番環境には影響しません。
しかし、ステージングで正常に検証された変更を本番に適用するには、お客様はそれらの変更を手動でコピーするか、CloudflareのTerraformプロバイダーを使用して自動化を構築する必要があります。多くの場合、この作業は手動による「変更リクエスト」プロセスで行われ、チケットに変更内容が記録されます。そして、誰か（多くの場合、別の人）がそのチケットを受け取り、手動で提供された指示に基づいて同じ変更を正確に再現しなければなりません。これはエラーが発生しやすいプロセスであり、このプロセスのエラーは、関係する変更によっては、障害につながる可能性があります。さらに、ステージングと本番設定の間で設定にズレが生じると、さらに複雑な問題が発生する可能性があります。
当社は、お客様に、Cloudflare上でサービスの管理に安全性と信頼性を提供したいと考えています。前述の問題を解決するために、ルーティングルールと一緒にHTTPアプリケーションを発表します。
HTTPアプリケーション
HTTPアプリケーションは、エッジ設定をホスト名ではなく、ユースケースごとに管理する方法です。各HTTPアプリケーションには、マーケティングWebサイトや内部アプリケーションの設定を処理するなどの目的があります。各HTTPアプリケーションは、ページルール、ファイアウォールルール、キャッシュ設定など、トラフィックを管理するための設定のスナップショットを示す設定のバージョンで構成されています。HTTPアプリケーション内の各バージョンの設定は、他のバージョンとは独立していますが、新しいバージョンが作成されると、その前のバージョンのコピーとして初期化されます。
ルーティングルール
ゾーンとは異なり、HTTPアプリケーションの各バージョンは、特定のホスト名から独立しています。では、ゾーンのようにバージョンがホスト名に縛られない場合、HTTPアプリケーションのどのバージョンが特定のトラフィックセットに影響を与えるかをどのように決定するのでしょうか。その答えがルーティングルールです。ルーティングルールでは、HTTPアプリケーションのどのバージョンをどのトラフィック、すなわちホスト名に適用するかを決めることができます。ルーティングルールはCloudflareのルールセットエンジンによって提供されており、Cloudflareアカウントで管理されているホスト名を設定のバージョンにマッピングする条件付き「if then」ルールの使用に依存しています。例として、リクエストのホスト名が「www.example.com」にマッチした場合、マーケティングHTTPアプリケーションのバージョン2を適用します。このルールがエッジで実行されると、通常のゾーン設定であるwww.example.comの代わりに、HTTPアプリケーションのバージョン2で定義された設定がエッジで使用されることになります。
ルーティングルールは、ステージングルールと本番ルールの2種類のルールをサポートしています。記述されているように、どちらもホスト名のリストを取りますが、ステージングルールを作成するときに、エッジの特定のIPにトラフィックが送られたときにのみルールが実行されるように、追加でフィルタを適用します。つまり、ステージングIPのwww.example.comにトラフィックを送ることで安全に変更をテストすることができ、顧客は影響を受けないということです。さらに、本番用ルーティングルールを作成して変更を検証すると、まったく同じ設定がすべてのお客様に本番で適用されます。
しかし、話はこれくらいにして、実際の活用例を見てみましょう！
HTTPアプリケーションを使用した安全なテストと変更のデプロイ
このウォークスルーでは、私は既存の顧客の役を演じるつもりです。私は顧客にサービスを提供する既存のゾーンを持っており、アセットの場所を書き換えることができるように、変換ルールをいくつか変更したいと思います。しかし、私は正規表現があまり得意ではないので、ミスをするとすべての顧客のサイトを壊してしまいそうです！ゾーンに直接変更を加えるのではなく、HTTPアプリケーションとルーティングルールを使って、変更を行い、テストし、ロールアウトする予定です。
まず、Cloudflareダッシュボードにログインします。アカウントを選択すると、サイドバーにHTTPアプリケーションが表示されます。これを選択すると、最初のHTTPアプリケーションを作成するためのオプションが与えられます。
HTTPアプリケーションの空の状態ページを表すCloudflareダッシュボード
最初のHTTPアプリケーションを作成するには、名前を付けて、既存のゾーン（この場合はexample.com）を選択する必要があります。CloudflareはHTTPアプリケーションの最初のバージョンの設定を初期化するために、そのゾーンを使用します。ゾーンから既存の設定をコピーすることで、安全なコピーができ、設定を手動で再構築する必要がありません。
[作成]を選択すると、最初のHTTPアプリケーションが出来上がります！現在、最初のバージョンは作成中です。裏側では、Cloudflareがexample.comの既存の設定を、このHTTPアプリケーションのバージョン1へコピーしています。正常にコピーされると、設定の編集を開始できます。
アプリケーション例のバージョンリストで、バージョン1が作成されていることを示します。
このバージョンには、他のゾーンと同じように編集を加えることができます。しかし、2つの重要な違いがあります。第一に、私が今行う変更は、Cloudflareのエッジでのライブトラフィックには影響しません。なぜなら、このバージョンの設定にトラフィックを送るルーティングルールをまだ作成していないからです。第二に、ゾーンに関連するすべてのものをHTTPアプリケーションで制御することはできません。すなわち、DNSレコード、SSL証明書、Spectrum、負荷分散などです。
ルールが作成されていないことを示すバージョン1のTransform rules。
Transform Rules下のルールセクションに、アセットのパスを正しい場所に書き換えるための新しいルールを作成します。example.com/assets/*へのあらゆるリクエストに対して、example.com/internal/files/assets/*となるようパスを書き換えます。
「Rewrite Assets」という名前のバージョン1の変換ルールを作成します。このルールは、「/assets/*」で始まるリクエストのパスを「internal/files/assets/*」に置き換えます。
「Rewrite Assets」という名前の新しいルールを示すバージョン1のTransform rulesが作成されました。
この時点で、私は変更を加えましたが、今度はそれをテストしたいと思います。そのためには、バージョン編集セクションを出て、このHTTPアプリケーションのルーティングルールに向かいます。ここでは、既存のトラフィックをこのバージョンの設定でルーティングできるようにするルールを作成できます。
アプリケーション例のルーティングルールの空リスト。
私は、顧客に影響を与えることなく、この変更をテストする唯一の存在になりたいので、ステージングルールを作成することにします。ステージングルールを作成すると、このバージョンをテストするために使用できるIPがルール作成画面に表示されることに注意してください。
リクエストがexample.comに一致し、エッジIPが192.168.1.1または192.168.2.2のときに一致するステージングのルーティングルールを作成し、バージョン1の設定を適用します
ルールを作成したら、example.comのリクエストをこれらのIPに送信するよう、自分のコンピュータを設定することができます。Rackspaceでは、総合ガイドに、ローカルマシンのホストファイルを変更してこれを行う方法が紹介されています。さて、私がexample.comにアクセスすると新しい変換ルールが実行されますが、このサイトを訪れる他の人たちに対しては、何も変化がありません。
ステージング用のルールが1つ作成されたことを示す、アプリケーション例のルーティングルール。
変更がうまくいったと確信したら、本番用のルーティングルールを作成して、example.comへのすべてのトラフィックにこの変更を適用することができます。そして、できました！
リクエストがexample.comに一致するとバージョン1が適用される本番用ルールの作成を示すルーティングルール作成画面。
更新されると、私のサイトのアセットへのパスは、すべてのリクエストに対して_example.com_に書き換わります。
バージョン1のステージングルールと本番用ルールの両方を示すアプリケーション例のルーティングルール。
次はどうなるのでしょうか？別の変更セットを加える準備ができたら、HTTPアプリケーションでバージョン1を複製してバージョン2を作成することができます。初期状態では、バージョン2はバージョン1の設定と完全に一致しますが、一致するルーティングルールがないため、どのトラフィックにも適用されません。
バージョン1がステージングと本番に適用され、バージョン2は編集可能だが、どこにも使用されていないことを示すアプリケーション例のバージョンリスト。
これで、以前バージョン1で行ったように、バージョン2を安全に編集することができるようになりました。今回は、悪意のあるトラフィックが私のサイトへアクセスするのを防止するために、ファイアウォールルールにいくつか変更を加えたいと思います。バージョン2で変更を加えても、ステージングのルーティングルールがバージョン2を使用するように更新するまで、エッジでのトラフィックは変更されません。このため、自信を持って変更を行い、安全にテストすることができます。
バージョン2がステージングに使用され、バージョン1がまだ本番で使用されていることを示すアプリケーション例のルーティングルールのリスト。
この新しい変更セットを検証した後、本番用ルーティングルールを更新してバージョン2を使用することで、すべてのトラフィックにバージョン2をプッシュすることができます。同じプロセスを、それ以降に行う変更セットごとに行うことができます。
HTTPアプリケーションのクローズドベータ版の提供開始
HTTPアプリケーションとルーティングルールにより、お客様は設定変更の方法とタイミングをより自由にコントロールできるようになりました。これにより、誤った変更によってサイトが破壊される心配が軽減されます。この機能は、企業の顧客向けのクローズドベータ版として提供されていますが、ご興味のある方は、アクセス取得方法についてCloudflareのアカウントチームにお問い合わせください！