Microsoft Ignite The Tour で Azure Kubernetes Service のセッションに登壇しました

Microsoft Ignite The Tour で、「Azure Kubernetes Service を活用したマイクロサービス開発」というタイトルでブレイクアウト セッションに登壇しました。

speakerdeck.com

本家の Microsoft Ignite のローカルイベントで、日本では東京と大阪で開催されました。「マイクロサービス ＝ Kubernetes」みたいな流れは良くないので、あえて Kubernetes を使わない Functions 中心の構成を話すところから始まり、AKS の基礎的な話から本番運用を想定したベストプラクティスをいくつか紹介しました。どちらの会場も同じ内容を話しました。
gooner.hateblo.jp

東京

昨年の12月、プリンス パークタワー東京で開催されました。私のセッションは Day2 に行われ、満席で入場制限が入るほど多くの方に来て頂けました。参加者からの反応やアンケートを見る限り、まずまずの評価だったようです。後日、JAZUG のイベントの際にも、参加してくれた方から声をかけて頂けて、うれしかったです。

Day1 には、JAZUG のコミュニティポップアップの運営も少しお手伝いをしました。The Hub というシアターセッションやスポンサーブースがある部屋で、JAZUG の紹介と本家の Microsoft Ignite のまとめ、そしてLT（６本）が行われました。

裏ではセッションが行われている時間帯でしたが、たくさんの人に来て頂けました。
資料は、こちらで公開されています。
jazug.connpass.com

大阪

先月末、インテックス大阪で開催されました。私が知る限り、Microsoft が大阪で大きなイベントを開催するのは初めてでした。東京よりも広いセッション会場でしたが、立ち見の方がでるほど多くの方に来て頂けました。残念ながら Ask the Speaker がなかったのですが、The Hub にいるので質問があったらどうぞと伝えたら、数名の方が来てくれました。

新大阪からは少し遠い場所にある会場で、東京で言うとビックサイトみたいな雰囲気で、とにかく広かったです。

• 東京では２つに分かれていた The Hub が１つで一体感があった
• セッションの部屋が広いので、入場制限が入ることもない
• 次のセッションに参加するための待機列があっても移動の妨げにならない

会場の広さは、参加者の時間と気持ちの余裕に繋がるので重要だと感じました。セッションの合間に The Hub に来て、エキスパートな人たちに質問したり、スポンサーブースを回ったりできるのは、会場に来た人だけが楽しめる特権だと思います。
Micosoft にはフィードバックしておいたので、今後の東京開催のイベントでの改善に期待したいです。

おまけ

大阪からの帰りに少し観光しました。

海遊館

通天閣

道頓堀

Azure Storage の Static website に CDN を使ってカスタムドメインの HTTPS を構成する

Azure Storage の Static website で SPA なアプリケーションを公開する際に、カスタムドメインの HTTPS を構成するには、Azure CDN や Front Door との組み合わせが必要です。
今回は、Azure CDN を使って Azure Storage の Static website にカスタムドメインの HTTPS を構成してみます。

事前準備

Azure CDN では、カスタムドメインの証明書（DigiCert）を無料で準備してくれるので、カスタムドメインのみ用意します。App Service Domain の購入方法については、別の記事を参照してください。
gooner.hateblo.jp
本題ではないので、Azure CDN のエンドポイントに Static website を構成する部分は割愛します。今回は、Vue.js のアプリケーションを Static website にデプロイしました。
Azure CDN には、選択できる SKU にいくつか種類がありますが、CDN の POP からオリジンへの通信量がかからない「Standard from Microsoft」を選択しました。SKU の違いは、公式ドキュメントを参照してください。
docs.microsoft.com

Azure CDN に Static website のエンドポイントを追加する

Azure Portal から Azure CDN を開いて、Static website のエンドポイントを追加します。Origin Type に custom origin を選択し、origin hostname に Static website の URL を設定します。この URL は、Azure Blob Storage ではなく、Static website の URL であることに注意してください。

これで Azure CDN のドメインに HTTP でアクセスできるようになります。

Azure CDN にカスタムドメインを構成する

まずは、App Service Domain を購入したときに作られた DNS zone を開きます。Azure CDN のドメインを使って、staticweb.gunner-s.com というドメインのCNAMEレコードを追加します。
続いて、Azure CDN のエンドポイントのホスト名とカスタムドメインのホスト名を DNS マッピングします。

Azure CDN のカスタムドメインに HTTPS を構成する

Azure CDN が提供するマネージドな証明書を使って、カスタムドメインに HTTPS を構成します。

これで Azure CDN の構成が完了です。HTTPS のカスタムドメインでアクセスできるようになります。

まとめ

Azure CDN を使って Azure Storage の Static website にカスタムドメインの HTTPS を構成してみました。
わずか数クリックで構成できるメリットはあるのですが、Static website 単体ではカスタムドメインの HTTPS を構成できません。
Azure CDN や Front Door が必須になり、Blue / Green デプロイの実現に手間がかかるので、「SPA = Storage の Static website」ではなく、Web Apps を使う選択肢も十分に考慮しておきたいところです。

Azure Application Gateway V2 に App Service Certificate を使って HTTPS を構成する

Azure Application Gateway V2 のエンドポイントには IP アドレスが割当されますが、 バックエンドに Azure Active Directory B2C などで認証したアプリケーションを置くと、リダイレクト先として HTTPS のエンドポイントが必要となります。
カスタムドメインの HTTPS を構成する流れは公式ドキュメント通りですが、補足を加えてまとめました。
docs.microsoft.com
証明書のカスタムドメインには、Azure の App Service Domain を使いました。必ずしも Azure で購入する必要はありませんが、Azure Portal で購入手続きが完結できるメリットがあります。

事前準備

Azure Application Gateway V2 のエンドポイントに設定するカスタムドメインと証明書を用意します。App Service Domain と App Service Certificate の購入方法については、別の記事を参照してください。
gooner.hateblo.jp
本題ではないので、Azure Application Gateway V2 にバックエンドのアプリケーションを構成する部分は割愛します。今回は、.NET Core 向けの Web Apps をバックエンドに設定しました。

Azure Application Gateway V2 にカスタムドメインを構成する

App Service Domain を購入したときに作られた DNS zone を開きます。Azure Application Gateway V2 のパブリック IP アドレスを使って、demo.gunner-s.com というドメインのAレコードを追加します。
Aレコードの追加が反映されると、Azure Application Gateway V2 に HTTP のカスタムドメインでアクセスできるようになります。

App Service Certificate を Key Vault で管理する

Azure App Service 以外のリソースで App Service Certificate を利用するには、証明書を Key Vault で管理する必要があります。まず、証明書をエクスポートしますが、今の Azure Portal ではできないので、Azure PowerShell を使います。
azure.github.io

公式ドキュメントの通りに Export-AppServiceCertificate 関数を追加して実行すると、ローカルに証明書の PFX ファイルをエクスポートできます。忘れずに、実行結果に表示されるパスワードをメモしておきましょう。

Export-AppServiceCertificate -loginId yourarmemail@domain.com -subscriptionId yoursubid -resourceGroupName resourceGroupNameOfYourAppServiceCertificate -name appServiceCertificateName

続いて、Azure PowerShell でエクスポートした PFX ファイルを、Key Vault の証明書メニューからインポートします。

最後に Key Vault の Soft Delete の設定を有効にしておきます。Azure Application Gateway などの他のリソースから証明書を参照するために必要な設定です。

Azure Application Gateway V2 に HTTPS を構成する

Azure Application Gateway から Key Vault で管理している証明書にアクセスできる権限を付与する必要があります。
Azure Portal から User Assigned Managed Identity を開き、appgw-identity という Managed Identity を登録します。リソースグループは、Azure Application Gateway と同じものを選択しました。

Azure Portal から Key Vault を開き、登録した Managed Identity に Key Vault のアクセスポリシーを付与します。シークレットに GET のパーミッションが必要です。アクセスポリシーを追加した後、忘れずに保存ボタンを押しましょう。

これで準備が整ったので、Azure Application Gateway で HTTPS を構成したリスナーを追加します。Key Vault から証明書を参照して構成することができます。

リスナーを追加できたら、ルールを変更します。

これで Azure Application Gateway の構成が完了です。HTTPS のカスタムドメインでアクセスできるようになります。

まとめ

Azure Application Gateway V2 に App Service Certificate を使って HTTPS を構成してみました。
App Service Certificate は App Service 以外でも使えますし、Key Vault の連携部分を押さえておけば、Azure Portal だけで購入手続きが完結し、安全に管理することができるので、検証目的に使うのはアリかなと思います。