Azure の App Service Domain と App Service Certificate を使ってカスタムドメインの HTTPS を構成する

Azure の App Service Domain と App Service Certificate を購入し、いくつかのリソースに対して、カスタムドメインの HTTPS を構成してみました。
必ずしも Azure で購入する必要はありませんが、Azure Portal で購入手続きが完結し、Azure Key Vault で安全に管理することができるメリットがあります。

App Service Domain

Azure Portal から、App Service Domain を選択してドメインを購入します。ドメイン名のほかに、連絡先情報など入力するだけです。もちろん、App Service 以外でも使えるドメインです。今回は、gunner-s.com というドメインを購入しました。

購入できるドメインは、GoDaddy で管理されていて有効期間は１年間です。自動更新がデフォルトで設定されています。

App Service Certificate

App Service Certificate から証明書を購入します。似た名前の App Service Managed Certificates という無料のサービスもありますが、まだプレビューとなります。
今回は、demo.gunner-s.com というドメインをワイルカードなしで購入しました。ワイルドカードが使える証明書を購入できるプランもあります。

証明書を使えるようにするため、いくつかのステップが必要となります。
まずは、Azure Key Vault へ証明書をインポートします。App Service 以外から証明書を参照するためには、soft delete の設定を有効にする必要があるので、専用の Key Vault を用意したほうがいい気がします。

次に、ドメインの検証です。画面に表示される Domain Verification Token をコピーしておきます。

App Service Domain を購入したときに作られた DNS zone を開きます。コピーした Domain Verification Token を使って、demo.gunner-s.com というドメインのTXTレコードを追加します。

TXTレコードを追加したら、App Service Certificate の画面に戻って検証ボタンを押すと、5分ほどで検証が完了します。

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

Azure App Services の場合、Azure Portal からさくっとカスタムドメインの HTTPS を構成できます。

1. Azure DNS zone で、CNAMEレコードを登録する
2. Azure App Services でカスタムドメインを割り当てる
3. Azure App Services で App Service Certificate をインポートする

公式ドキュメントの通りなので、詳しい手順は割愛します。
docs.microsoft.com
docs.microsoft.com

下記のように、Azure App Services にカスタムドメインの HTTPS でアクセスできるようになります。

Azure App Services 以外のリソースにカスタムドメインの HTTPS を構成する

Azure App Services 以外のリソースに対して、カスタムドメインの HTTPS を構成してみます。

• Application Gateway V2
• Azure Storage Static website + CDN

記事を分けたので、下記のリンクを参照してください。
gooner.hateblo.jp
gooner.hateblo.jp

まとめ

Azure の App Service Domain と App Service Certificate を購入し、いくつかのリソースに対して、カスタムドメインの HTTPS を構成してみました。
本番運用で使うこともできますが、Azure Portal だけで購入手続きが完結し、Azure Key Vault で安全に管理することができるので、検証目的に使うのはアリかなと思います。

Azure Pipelines で Variable groups を使ってパイプラインを構築する

先日の記事で、Azure DevOps の Multi-Stage Pipelines を使って Azure Web Apps にデプロイする内容を記載しました。
gooner.hateblo.jp
YAML をソースコードのリポジトリで管理する想定なので、環境毎に異なる情報やパスワードなどのシークレットな情報をリポジトリに含めたくありません。そこで、Azure DevOps の Variable groups を使って、パイプラインを書き換えてみました。

パイプラインの全体設計

先日の記事と同様に、パイプラインは、自動デプロイされる開発環境向け（Commit Stage）と承認デプロイされる本番環境向け（Production Stage）を作りました。
YAML を Build と Release に分けて、可変部をパラメータで切り替えできるテンプレートを作ることで再利用性を向上させます。

Variable groups とは

Variable groups は、Azure DevOps 内に定義した Key-Value のデータをグループ化し、YAML パイプラインに渡すことができる機能です。
docs.microsoft.com
Azure DevOps の Library メニューから Variable groups を登録します。このユースケースでは、ブランチ毎にデプロイ先の Azure Web Apps が異なるので、Commit Stage と Production Stage でグループを分けて、webAppsName を登録します。
variable-group-commit と variable-group-production の２つの Variable groups を登録しました。

今回は利用しませんが、パスワードなどのシークレットな情報は、Value の右横の鍵マークをクリックすると、値をマスクすることができ、登録した人以外には非公開にすることも可能です。また、Azure Key Vault で値を管理することもできます。

パイプライン

変更する YAML は、パイプライン起動用の azure-pipelines.yml です。

trigger:
- master

variables:
- group: variable-group-commit
- name: imageName
  value: 'windows-2019'
- name: buildConfiguration
  value: 'Release'
- name: projects
  value: '**/WebApplication.csproj'
- name: testProjects
  value: '**/WebApplication.Tests.csproj'
- name: azureSubscription
  value: 'AzureSponsorships'
- name: webAppsType
  value: 'webApp'
- name: environment
  value: 'Commit-Stage'

stages:
- stage: Build
  jobs:
  - template: pipelines/build-pipelines.yml
    parameters:
      imageName: $(imageName)
      buildConfiguration: $(buildConfiguration)
      projects: $(projects)
      testProjects: $(testProjects)
    
- stage: Release
  dependsOn:
  - Build
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
  jobs:
  - template: pipelines/release-pipelines.yml
    parameters:
      imageName: $(imageName)
      azureSubscription: $(azureSubscription)
      webAppsName: $(webAppsName)
      webAppsType: $(webAppsType)
      environment: $(environment)

variables の webAppsName を削除する代わりに、group: variable-group-commit を追加することで、Variable groups から値を受け取ることができます。
Variable groups と YAML に定義する variables の両方を使いたいので、既存の variables を name-value 形式で書き換えています。
同様の手順で、本番環境向けパイプラインの azure-pipelines-production.yml も変更すれば、完了です。

まとめ

YAML をソースコードのリポジトリで管理する場合、環境毎に異なる情報やパスワードなどのシークレットな情報をリポジトリに含めたくありません。
Azure DevOps の Variable groups を使うことで、YAML パイプラインに値を渡すことができるので、実プロジェクトに適用する際にはうまく活用したい機能です。
こちらから、パイプライン YAML の全体を確認できます。
github.com

Azure Lab Services を使って複数の仮想マシンを構築する

ハンズオンなどのトレーニングにおいて、受講者向けに複数の仮想マシンを Azure 上に構築する方法をまとめておきます。
Azure Portal からポチポチと１台ずつ作るのは厳しいため、選択肢としては次の２つの方法があると思います。

• Azure Resource Manager テンプレート
• Azure Lab Services

この記事では、Azure Lab Services を使う方法について記載します。
Azure Resource Manager テンプレート を使う方法については、こちらの記事を参照してください。
gooner.hateblo.jp

Azure Lab Services とは？

Azure Lab Services は、ハンズオンなどのトレーニング向けに Azure の仮想マシンを展開できるサービスで、受講者は仮想マシンに RDP 接続して使うことができます。
受講者１人につき１台の仮想マシンだけでなく、複数のサーバーで構成された環境を展開することもできます。
昨年の2月末に GA しており、東日本と西日本のどちらのリージョンでも使えます。

Lab Account を作成する

まず、ハンズオンを開催する講師側で必要な作業を実施します。
Azure Portal から、Azure Lab Services を作成します。リソース名やリージョンなど基本的な情報だけを入力すればOKです。
その他の項目は必須ではありませんが、今回はハンズオン向けの仮想マシンイメージを作成済みの想定なので、Shared Image Gallery を指定しました。

Classroom Lab を作成する

Lab Account が作成されたら、Azure Portal のリンクをクリックすると、Azure Lab Services Portal に移動します。左上の「空色 Lab Services」というタイトルが微妙な感じですが、気にせず進めます。

ハンズオン向けの新しいラボを作成します。※上記の画面は、すでに２つ作成済み。
まずは、必要な仮想マシンサイズとイメージを選択します。Shared Image Gallery を指定して Lab Account を作成していると、ここでカスタムイメージを選択できます。

次に、仮想マシンのユーザー名とパスワードを設定します。仮想マシンを使う受講者にパスワードを変更させることもできます。

最後にポリシーを設定しますが、後で変更することも可能です。クォータは、ラボに対してスケジュールされた時間外にユーザーが利用できる時間です。自動シャットダウンなども設定できます。

完了ボタンを押すと、ラボで利用する仮想マシンのテンプレートが作成されるのですが、上記のメッセージにもあるように割と時間がかかります。

20分ほど待つと、仮想マシンのテンプレート作成が完了します。

仮想マシンを展開する

仮想マシンのテンプレートが作成できたら、受講者が利用する台数分を公開します。

これもメッセージにあるように、割と時間がかかります。40分ほどで３台の仮想マシンを公開できました。仮想マシンプールで、３台すべてが受講者に未割当の仮想マシンであることを確認できます。

公開した仮想マシンを受講者に払い出したいので、ユーザーの追加ボタンからメールアドレスを登録します。メールアドレスは、手入力もしくは CSV ファイルで登録できます。

ユーザーを登録できたら、全員を招待ボタン から受講者へ招待メールを送信します。これでハンズオンを開催する講師側で必要な作業は完了です。

受講者が仮想マシンを利用する

ここからは、ハンズオンに参加する受講者側で必要な作業です。ハンズオンのラボへの参加を招待するメールが届いているはずです。

ラボへの登録のリンクをクリックして、Azure Lab Services Portal にサインインします。サインインするには、Microsoft アカウントが必要となります。

受講者は、自分に割り当てられた仮想マシンが表示されるので、赤印をクリックして RDP ファイルをダウンロードすることができます。

Azure Lab Services の課金体系

Azure Lab Services の課金対象となるのは、アクティブな仮想マシンのみです。シャットダウンされているインスタンスは課金対象外ですし、通常の仮想マシンのように、コンピューティングやストレージやネットワークへの課金がありません。
ハンズオンで使った分だけ、シンプルかつリーズナブルに利用できるサービスです。詳細は、公式サイトで確認してください。

まとめ

Azure Lab Services を使って、複数の仮想マシンを Azure 上に構築してみました。
ARM テンプレートは仮想マシンを作るだけですが、Azure Lab Services はハンズオンなどのトレーニング向けに特化しているメリットがあります。

• 受講者向けにメールで仮想マシンに招待できる
• 講師側で仮想マシンを起動できる時間帯や自動シャットダウンを制御できる
• コスト計算がシンプルで通常の仮想マシンよりも安い

しかし、仮想マシンのテンプレート作成や展開に時間がかかりすぎるので、今後の改善を期待したいです。