【（技術）力の試練】Github Copilot と一緒に Azure App Service をデプロイしてみよう

筆者は問い合わせ対応やトラブルシューティングなどの技術支援、エンジニアのトレーニングなどの対応のため検証用の Azure 環境を用意しています。
せっかく準備した Azure 環境なのですが、最近は問い合わせの対応もすくなくちょっと持て余し気味でもったいないな...
そう考えていたところ

神の名におき 試練を与えよう...
ミドルウェアの動作環境を構築し、プラットフォーム技術者としての技量を示すのだ...

という Azure 環境を活用するのにもってこいな天からのお告げがありました。
しかも試練を克服すると賃金アップが期待できるとのこと！
ぜひやっていきましょう

方針について

せっかくなので過去案件で使っていた Github Copilot 君と会話しながら進めていきます。

ゼロベースでポチポチリソースを作っていくのは時間がかかることに加えて再現が難しくなるため、Azure Developer CLI (azd) で Bicep ファイルに定義したインフラをデプロイする Infrastructure as Code（IaC）的な手法での構築を目指してみようと思います。

今回は App Service on Linux 上に Django ベースの Web アプリケーションを起動して PostgreSQL サーバー上にアプリの情報を格納する、という構成としました。
上記以外にも Microsoft からいろいろなテンプレートが提供されていますが、これまでの経験からある程度勝手のわかる言語や構成のものを選んでみました。

目指すのはこんな環境です。

デプロイの準備

最終的にデプロイまでにはクライアント側に下記の設定が必要となりました。
（諸々試行錯誤した結果なので、取りこぼしがあるかもしれません）
特に、コンテナイメージの取得やデプロイに Docker を利用しているようなので、Docker Desktop のインストールをした上で起動しておく必要がある点には注意が必要です。

• Git for Windows
• PowerShell
• Azure Developer CLI
• Docker Desktop

参考情報としてバージョン情報の抜粋を載せておきます。
実施時点での最新版でもない中途半端な感じですが、おそらく最新のバージョンにしてもそこまで以降の手順に影響はないかと思います。

azd version
azd version 1.14.0 (commit c928795c47f27d1e997c217147dc649054ac05c8)

git version
git version 2.46.0.windows.1

$PSVersionTable.PSVersion.ToString()
7.4.7

docker info --format '{{.ServerVersion}} {{.OperatingSystem}}'
27.0.3 Docker Desktop

Copilot くんと構築開始

構成ファイルを取得するため、PowerShell か git bash 上で git clone していきます。

git clone https://github.com/Azure-Samples/msdocs-django-postgresql-sample-app.git 

今回はインフラ関係のコードやデータベースへの接続設定を更新する必要がある starter-no-infra ブランチに切り替え、Github Copilot が修正箇所を適切に指摘できるか実験してみましょう。

$ git switch starter-no-infra
branch 'starter-no-infra' set up to track 'origin/starter-no-infra'.
Switched to a new branch 'starter-no-infra'

ちなみに変える必要のある個所としてはこの部分です。
この部分をコメントアウトする必要があるというわけなんですが、気づいてくれるでしょうか?
大丈夫かな

Vscode で git clone したフォルダをひらき、@workspace でワークスペース全体を対象として質問をしてみると、ちゃんと更新が必要な箇所の指摘をしてくれます。

実は該当箇所のコメントアウトを外すだけで動作はするのですが、改善案まできっちり出してくるあたりデキますね
では該当箇所のコメントアウトを外して、アプリケーションコードのデプロイを行っていきます。

azd init コマンドを実行し、インフラの定義が含まれる infra フォルダーや azure.yaml を生成します。
--init 以降のテンプレート名はこのアプリケーションで使用するテンプレート名を指定していきます。

$ azd init --template python-app-service-postgresql-infra

重要なのは infra フォルダ内に生成される main.bicep と resource.bicep です。

main.bicep は、重要な変数、パラメーター、名前付け規則などが含まれる最初の読み込みファイルです。
今回生成されたファイルでは infra フォルダ内の resource.bicep を呼び出しており、作成するリソース名などの具体的な設定内容は resources.bicep を参照することになっています。（下記）

main.bicep

module resources 'resources.bicep' = {
  name: 'resources'
  scope: resourceGroup
  params: {
    name: name
    location: location
    resourceToken: resourceToken
    tags: tags
    databasePassword: databasePassword
    principalId: principalId
    secretKey: secretKey
  }
}

resources.bicep 各リソースの定義部分、まずは Azure Apps Services のリソースの定義部分です。
App Service Plan の定義部分にこの App Service を Linux ベースで作成すること、
App Service 側の定義に使用する言語指定 linuxFxVersion などが書かれていることがわかります。

resources.bicep(Azure Apps Services 部分抜粋)

// The App Service plan is configured to the B1 pricing tier
resource appServicePlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: '${appName}-plan'
  location: location
  kind: 'linux'
  properties: {
    reserved: true
  }
  sku: {
    name: 'B1'
  }
}

resource web 'Microsoft.Web/sites@2024-04-01' = {
  name: appName
  location: location
  tags: union(tags, { 'azd-service-name': 'web' }) // Needed by AZD
  properties: {
    siteConfig: {
      linuxFxVersion: 'PYTHON|3.12' // Set to Python 3.12
      ftpsState: 'Disabled'
      minTlsVersion: '1.2'
    }
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
  identity: {
    type: 'SystemAssigned'
  }
}

他のリソース（PostgreSQL、Redis Cache）の定義部分についても、同様に resources.bicep に定義が書かれています。

azd init を実行すると環境名の入力プロンプトが表示され、Enter キーで次へ進むと前述のファイルが生成されていきます。

以上の手順で作成された infra フォルダーにあるコードとしてのインフラストラクチャ ファイルを使用して、Azure にリソースを作成していきます。
途中で作成するサブスクリプション、リージョンなどを選択しておきます。

$ azd provision

本来はこれで必要なリソースが作成されるはずなのですが、あれれ?

なんか怒られてますね。
ここで画面左下のキラキラを押してみます。

どうやらリソースの名称が長すぎるようですよ、とエラーを読み解いてくれます。

言うとおりに修正して再実行してみたところ、再度問題発生。
どうやら Bicep ファイル内部で定義している Key Vault の名称が直前に作成したものと同じものになっていたため、以下の制約に引っかかってしまった模様。

アイテム保持ポリシーの期間はキー コンテナーの作成時にのみ構成でき、後で変更できません。 7 日から 90 日までの範囲で設定できますが、既定は 90 日です。 論理的な削除と消去保護の保持ポリシーの両方に同じ期間が適用されます。
保有期間が経過するまで、論理的に削除されたキー コンテナーの名前を再利用することはできません。

ちょっとここで対処方法を検討してみました
調査した結果キーコンテナーの完全削除は実際ちょっと難しそうな印象であったため、同名のリソースを作らないような仕組みを考えていく、という方針にかじを切ってみます。
具体的にはAzure Key Vault のリソース名を一意にするため、末尾に時刻の文字列を付与することにしました。

ここまでは人間の仕事。ここからはズボラをかまして Copilot に働いてもらいましょう
修正箇所を選択の上 Ctrl+i で代わりに書いてもらいます。

ということでこんな感じに更新してみました。

main.bicep

// 現在の時刻を "hhmm" フォーマットで取得
@description('Current time in "hhmm" format')
param currentTime string = utcNow('hhmm')

// resourveToken の末尾に現在の時刻を追加
var resourceToken = '${toLower(uniqueString(subscription().id, name, location))}${currentTime}'

再実行。今度はうまくリソースが作成できていそうですね。
Cache for Redis のデプロイにかなり時間がかかるので全体で 20 分弱かかりました。

Azure ポータルなどで、リソースが作成されていることを確認してみましょう。
試しに az コマンドで作成したリソースグループのリソースを一覧にしてみたところ、想定通り infra フォルダ内で定義されていたリソースが作成されていることがわかります。

次は src フォルダーに定義されているアプリまたはサービスをデプロイします。

$ azd deploy

ここで事前にインストールした Docker Desktop を起動しておきます。
内部的に docker のコマンドを使用するためです。

成功するとこんな感じに。

ここまで実施したらあとはアプリの動作状況を確認するだけ。と言いたいところですが
Django のマイグレーションファイル (migrations/) を適用し、データベースに必要なテーブルやカラムを作成する必要があります。

参考: マイグレーション | Django documentation | Django
https://docs.djangoproject.com/ja/5.2/topics/migrations/

この作業は Azure App Services 上でマイグレーション用のコマンドを実行する必要がありますので、azd deploy の際に表示された SSH 接続用の URL にアクセスすればよいのですが...おや?

ない。URLが無い。
本来は AZD の出力で SSH セッションの URL が表示される想定なのですが。
目的達成を目前にしてよくわからない現象に遭遇してしまいました。
Github Copilot に雑に聞いてみましょう。

どうやら https://<app-name>.scm.azurewebsites.net/webssh/host がその URL だよと言われているようです。
さてこれ本当かな、と一応裏を取ってみましょう。
ここで表示されるものは App Service の SSH アクセス用の URL なので、公開情報的には下記に言及がありました。内容見た範囲では Copilot の言っていることは正しそうです。
自力でコードを見て即この説明ができるとはなかなかやりますね。

適当な Web ブラウザに表示された URL を打ち込み、無事に ssh 接続のプロンプト画面が表示されたら、マイグレーションのコマンドを実行しましょう。

python manage.py migrate

では改めて、azd deploy 実行時に表示されたエンドポイントへアクセスしてみます。

デモアプリ起動を確認できました！！
UI を捜査して適当にデータを格納してみます。うまく動いているようですね。
ひとまず構築成功といってよいでしょう。

一通り遊んだら、リソースを削除しておきましょう。削除操作は azd down --purge です。

まとめ

まずは当初予定していた環境を構築することができて安心しました。
今回は Github Copilot のサポートを受けやすいようにという意図もありこのような方法（IaC）での構築にチャレンジしてみましたが、想像以上にやりやすいと感じます。

今回のようにリソースの構成なども含めてコードに定義されている状況の場合は特に、全体の構成の把握やトラブルシューティングを強力にサポートしてくれます。
実はここに書かなかっただけで自力で解決したエラーなどもたくさんあるのですが、直接の解決法を提示されなくても仮説をたてるためにいろいろなヒントをくれるこういったツールはやはり便利。

今後もぜひ活用していきたいものだと思いました。