この記事はAzure App Service Team BlogのZero to Heroシリーズの記事に感銘を受けて、和訳&改変&自分で新規執筆した記事です。 この記事を通してWeb Appsの基礎から実運用の方法まで、筆者自身が見直す機会としてシリーズ化して掲載する事にしました。 本家の「Zero to Hero」というフレーズの通り、Azure App Serviceを使ったことの無い方は一人前になれるように、すでに利用している方は知識のアップデートに役立てていただければと思います。
なお、連載の5回目からは筆者オリジナルのコンテンツを掲載しています。目次からまとめて読めますので、是非どうぞ。
【Azure初心者から上級者まで!】Azure App Service を使いこなしてゼロからヒーローになる
これはApp Service でゼロからヒーローを目指す連載の3番目の記事です。この記事を読むにはこれまでの2つの記事を終えていることを想定しています。
この時点で、メインブランチにソースコードがコミットされる度にステージングのスロットにデプロイする CI/CD のパイプラインがGitHub Actions に構築済みです。この記事では、ステージング環境とプロダクション環境のスロットをスワップすることによって プロダクション環境に新しいビルドをリリースする方法を学びます。 また、プロダクションへのトラフィックを一部ステージングに流し、新しいビルドを全リリースする前にテストする方法を学びます。
Azureポータルを開きます。左側のメニューから[デプロイ スロット]を選択します。
新しいブレードが開き、Webアプリケーションのスロットがリスト表示されます。
プロダクション と staging のスロットを見つけ、上部にある[スワップ]ボタンをクリックします。
[スワップ]ボタンを押すと、メニューがポップアップし、スワップ後に変更されるコンフィグレーションの値が表形式で表示されます。
Appsettings環境変数として設定されているキーバリュー型のコンフィグレーションです。今後の記事でもう少し詳細に触れる予定です。下部の[スワップ]をクリックして、スワップします。
処理が終わり、プロダクションのサイトを見るとサンプルアプリケーションが確認できます。
今回はステージングスロットにはサンプルアプリケーションをデプロイしています。スワップが判別できるようにHTMLページに判別できるようなテキストやプレースホルダを設定しておくと良いでしょう。
また、 カスタムコンテナーのスロットを使用する事も出来ます。
ここまでに、メインブランチにプッシュがあるたびにGitHub Actions のワークフローを起動するGitHubのリポジトリを用意しています。ワークフローはアプリケーションのビルドとステージングへのデプロイを行います。ステージングサイトを使って、最新の変更を評価することができます。
準備ができたら、スワップボタンかCLIコマンドを使ってスロットをスワップします。
大きいチームで働いている場合、テスト用のスロット、品質保証、カナリアリリース、A/Bテスト等の為にスロットを作ります。 ここに複数スロットのユースケースがあります。
デプロイとリリースの間には暗黙的な特性があります。よりこの特性について知るには、 この記事が良いでしょう。
プロダクションのトラフィックを使って新しいデプロイを完全にリリースする前に一部テストするのは、プロダクションにおけるテストはよくある手法です。 これはトラフィックのシャドーイング、ミラーリング、カナリアという総称で呼ばれます。 トラフィックの シャドーイング とミラーリングは興味深いトピックです。しかし、この記事ではスコープから外します。 残りのセクションでは、App Service の新しいデプロイをどのようにプロダクションにリリースする前に カナリアリリース するか説明します。
Azureポータルで、[デプロイ スロット]メニューに遷移します。 スロットの表の中で、トラフィックという項目があります。 デフォルトでは、全てのトラフィックはプロダクションスロットにルーティングされています。 トラフィックのパーセンテージを 10% ステージングスロットに向けてみましょう。 [保存] をクリックします。シンプルな変更で、1/10のプロダクションへのトラフィックが、新しいビルドに流れるようになります。 「カナリアリリース」と呼ばれる手法です。
「カナリアリリース」 という総称の起源は the “canary in a coal mine” idiomになります。
これでプロダクションのトラフィックが一部新しいビルドに向くようになったので、 デプロイの成功、予期せぬ問題のエラーをキャッチしてコードのパスを把握したり、用心深くモニターします。
Application InsightsやSplunk、Dynatraceのようなモニタリングツールを使っているなら、ステージングスロットのメトリクスやログをタグ付けして、正確にデータやレポートを分割したいと思います。
クライアントサイドにあるクッキーのx-ms-routing-name
に設定されている名称でどのスロットに繋がっているかわかります。
このクッキーを取得して、メトリックやログをタグ付けすると良いでしょう。
モニタリングのサービスダッシュボードで、フィルタしたり、データを分割して閲覧できます。
サーバーサイドのコードであれば、スロットは環境変数のWEBSITE_HOSTNAME
からホスト名とスロット名が取得できるのでわかります。
クライアントサイドのクッキーのように、環境変数を取得してメトリクスやログをタグ付けできます。
x-ms-routing-name のクエリパラメータを使って手動でクライアントを特定のスロットにルーティングもできます。
「おめでとうございます」最新のデプロイをリリースする方法を学びました。 また、プロダクションへのトラフィックを一部だけ、リリースする前の新しいビルドに流す、カナリアリリースも出来るようになりました。 次の記事では、証明書、ドメイン、セキュリティ、より高度なコンフィグレーションについてカバーします。 お楽しみに!
お問い合わせはこちらから
問い合わせる