ISID テックブログ

ISIDが運営する技術ブログ

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

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

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

触れる技術要素

  • 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、サーバが作成されます。

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

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

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

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

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

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

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

そうすると、mvnを前提としたGitHub acitonの設定ファイルが自動的にGitHubにコミットされます。 が、本プロジェクトではgraldeを使用していたので、適宜修正をします。

これだけで継続的デリバリーが構成されます。

まとめ

Azureでは、このように、GUIによりポチポチするだけでこのような環境を作成できます。 とある案件では、今回の手順をキャプチャーベースでDevのメンバーに展開することにより

「Devで簡単に巻き取れそうなので横展開は今後Devでやっていきます」

というありがたいお言葉をいただくことができました。 Azureをうまく使うことにより、Opsの関与を非常に減らした運用ができるのではないか?と思います。

Opsに負担をかけずに運用したいDevの方、構築・リリース作業で手一杯になっているOpsの方は、Azure Web Appsを使った環境構築を試してみてはいかがでしょうか

執筆:@miura.toshihiko、レビュー:@sato.taichiShodoで執筆されました