Azure Web AppsでGUIでらくらく、OIDC認証、 Continuous Delivery、ブルーグリーンディプロイメント !!

ISID X（クロス）イノベーション本部の三浦です。本記事は電通国際情報サービス Advent Calendar 2021の19日目のポストです。

本記事では、Azure Web Appsでは簡単にモダンな開発ができることをキャプチャーを多めで説明します。 GUIからポチポチ設定でここまで簡単にできるということをお伝えするのが目的です。（あまりインフラに詳しくないアプリ開発者でも簡単にインフラ構築、運用ができるかもしれないといった内容です）

触れる技術要素
今回の模擬システムの説明
今回の環境でできること
OpenID Connectによる認証（Office 365のユーザーでお手軽認証）の構築
webappsのディプロイスロットによる、ブルーグリーンディプロイ
GitHub Actionによる継続的デリバリー
まとめ

触れる技術要素

Azure Web Apps
- OpenID Connectによる認証（Office 365のユーザーでお手軽Single Sign On）
- ディプロイスロットによるブルーグリーンディプロイ
- GitHub ActionによるContinuous Delivery

今回の模擬システムの説明

Azure Web Apps + cognitive searchのシンプルなシステムです。 Azure Web Appsの機能で、OpenID ConnectでSingle Sign Onし、GitHubから、ステージング環境へGitHub Actionで継続的デリバリーし、GUI上の操作で簡易にブルーグリーンディプロイをします。また、app insightsによるAPM監視、および、log analytics によるログ管理をしています。

今回のエントリでは用いてる技術のうち「OpenID Connectによる認証」「ディプロイスロットによるブルーグリーンディプロイ」「GitHub Actionによる継続的デリバリー」を紹介します。

今回の環境でできること

Azure Web Apps のOpenID Connect認証による簡単な Office 365ユーザーで Single Sign On(AzureAD)
ブルーグリーンディプロイによる停止時間の短縮、障害時の高速切り戻し
GitHub acitionによる継続的デリバリー

OpenID Connectによる認証（Office 365のユーザーでお手軽認証）の構築

下記のようにGUI操作していくだけで、簡易にOffice 365のユーザーで認証が可能となります。

ここの設定を間違えると、認証してないユーザー、全世界のAzureADのユーザーにこのシステムが公開されてしまうので注意です。

このように設定すると、webapp側にRelying Party としての設定が完了、AzureAD側にOpenID Provider としてのリソースが作成されています。

では、AzureADに遷移し、OpenID Providerとしての追加設定をします。

まず、プロパティを開き下記の項目を設定します。デフォルトの「いいえ」の場合、そのテナントの全てのユーザーがwebapps にアクセス可能となります。「はい」の場合は後述の手順により、webapps単位でアクセスするユーザーを制限できます。例えば、マルチテナント的に複数の顧客をゲストユーザーとして登録しているテナントで、「いいえ」で設定してしまうと、他社向けのシステムが見えてしまうといったことが起こります。

次に、このアプリケーションへのアクセス権を与えるユーザーを追加してます。

ここでポイントなのは、AzureADのゲストユーザーも追加可能であるということです。これは、他社のOffice 365ユーザーに対して、他社の管理者の作業なしにSingle Sign Onが可能だということです。顧客が普段使ってるOffice 365のユーザーでのSingle Sign Onが数分で構築できる強力な機能です。

また、社内向けシステムを検討する際にも、煩雑な情シスへのIDP関連の申請を省略して普段使っているOffice 365のID、MFAを用いたシステムが提供可能となります。 Single Sign Onの設定は開発者、ID管理側、双方に一定の知識が必要でトラブリやすい作業です。しかし、Azure Web Apps + azureADのゲストユーザーを用いることでこの作業を大幅に簡易化できます。

webappsのディプロイスロットによる、ブルーグリーンディプロイ

では、次に、ブルーグリーンディプロイを設定します。Azure Web Apps には、ブルーグリーンディプロイを実現するための ディプロイスロット という仕組みがあります。これを作成します。「スロットの追加」を選択し、「次から設定を複製」で元のスロットを選ぶだけで、アプリケーション設定がコピーされます（環境変数、javaバージョン、tomcatバージョンなど）。また、待機スロット用のURL、サーバが作成されます。

できあがったディプロイスロットを入れ替えるにはスワップするだけです。

これにより、待機スロットでJavaやTomcatをバージョンアップし、動作確認が取れたらスワップするといったことも可能になります。スワップ時には、下記のように変更差分をわかりやすく表示してくれます。

また、待機スロットにGitHub Actionから継続的デリバリーし、動作確認してからスワップで本番環境にアプリケーションを展開することもできます。

なお、今回の手順で待機スロットを使うためには、『OpenID Connectによる認証』の再作成が必要です。スロットの設定を複製するときに認証設定も複製されているのですが、この認証設定はURLと結びついているためこのままでは動作しません。再作成で、待機スロット用の認証を構成しましょう。

GitHub Actionによる継続的デリバリー

ここまでの作業で認証付きの待機スロットが準備でき、安全にアプリケーションをディプロイできる環境が整いました。では、GitHub Actionによる継続的デリバリーを設定します。継続的デリバリーは待機スロットにし、待機スロットでディプロイ後アプリケーションの動作確認して、スワップで運用スロットに展開するといったながれとなります。

「ディプロイセンター」で、GitHubを選択し、レポジトリ、ブランチ情報を入力します。