ROMANCE DAWN for the new world

Microsoft Azure を中心とした技術情報を書いています。

Azure Pipelines で Azure Functions のパイプラインを構築する

先日の記事で、Azure DevOps の Multi-Stage Pipelines を使って Azure Web Apps にデプロイする内容を記載しました。
gooner.hateblo.jp
今回は、Azure Functions 向けのパイプラインを構築します。Azure Web Apps との違いは少ないので、相違点のみを記載します。

パイプラインの全体設計

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

ビルド用パイプライン

まず、ビルド用の build-pipelines.yml です。

parameters:
  imageName: ''
  buildConfiguration: ''
  projects: ''
  testProjects: ''

jobs:
- job: Build
  pool:
    vmImage: ${{parameters.imageName}}
  steps:
  - task: DotNetCoreCLI@2
    displayName: 'Build'
    inputs:
      command: 'build'
      projects: ${{parameters.projects}}
      arguments: '--configuration ${{parameters.buildConfiguration}}'
  - task: DotNetCoreCLI@2
    displayName: 'Test'
    inputs:
      command: 'test'
      projects: ${{parameters.testProjects}}
      arguments: '--configuration ${{parameters.buildConfiguration}}'
  - task: DotNetCoreCLI@2
    displayName: 'Publish'
    inputs:
      command: 'publish'
      publishWebProjects: false
      arguments: '--configuration ${{parameters.buildConfiguration}} --output $(System.DefaultWorkingDirectory)/publish'
      zipAfterPublish: true
  - publish: publish
    displayName: 'Publish artifact'
    artifact: functionApp

Azure Web Apps との違いは、publishWebProjects の値を ture から false に変更した部分のみです。

リリース用パイプライン

次に、リリース用の release-pipelines.yml です。

parameters:
  imageName: ''
  azureSubscription: ''
  functionAppsName: ''
  functionAppsType: ''
  functionAppsSlotName: 'production'
  environment: ''
  keyVaultEndpoint: ''

jobs:
- deployment: Deploy_Azure_Functions
  displayName: 'Release'
  pool:
    vmImage: ${{parameters.imageName}}
  environment: ${{parameters.environment}}
  strategy:
    runOnce:
      deploy:
        steps:
        - task: AzureFunctionApp@1
          displayName: 'Deploy to Azure Functions'
          inputs:
            azureSubscription: ${{parameters.azureSubscription}}
            appType: ${{parameters.functionAppsType}}
            appName: ${{parameters.functionAppsName}}
            slotName: ${{parameters.functionAppsSlotName}}
            package: '$(Pipeline.Workspace)/**/*.zip'
            deploymentMethod: runFromPackage
            appSettings: -KeyVault:Endpoint ${{parameters.keyVaultEndpoint}}

Azure Web Apps との違いは、Azure Function App task の AzureFunctionApp@1 を使って、デプロイを行っている部分のみです。
docs.microsoft.com

まとめ

パイプライン起動用の azure-pipelines.yml と azure-pipelines-production.yml については、変更する必要はありません。

f:id:TonyTonyKun:20200127172144p:plain

あとは、Variable groups を使って、パイプラインごとにデプロイ先の Azure Functions の名前を渡してあげれば、OKです。
こちらから、パイプライン YAML の全体を確認できます。
github.com

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 のイベントの際にも、参加してくれた方から声をかけて頂けて、うれしかったです。

f:id:TonyTonyKun:20200223110003j:plain

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

f:id:TonyTonyKun:20200223104941j:plain

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

大阪

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

f:id:TonyTonyKun:20200223110037j:plain
f:id:TonyTonyKun:20200223110102j:plain

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

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

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

おまけ

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

f:id:TonyTonyKun:20200223110150j:plain
海遊館
f:id:TonyTonyKun:20200223110219j:plain
通天閣
f:id:TonyTonyKun:20200223110251j:plain
道頓堀

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 であることに注意してください。

f:id:TonyTonyKun:20200205180709p:plain

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

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

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

f:id:TonyTonyKun:20200205181413p:plain

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

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

f:id:TonyTonyKun:20200205181539p:plain

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

f:id:TonyTonyKun:20200219164316p:plain

まとめ

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