ちゃんと動作確認したのは Azure Functions だけど、基本的には Azure App Service の制限の話のはずなので、Web Apps とかでも考え方は同じはず。
Azure Functions で Automation 使用して .NET から Azure PowerShell を使う場合、考慮が必要なのは下記 3 点。
- PowerShell 本体のバージョン
- Azure PowerShell のバージョン
- PowerShell の実行権限
それぞれ詳細を以下に説明する。
PowerShell 本体のバージョンについて
App Service は PaaS なので、.NET ランタイムと同じく PowerShell 本体のバージョンを開発者が選ぶことはできない。 2019/4 現在は、以下のように 5.1 がインストールされている様子（Kudu で確認）。
> $PSVersionTable
上記より古い想定は不要と思うが、最新の PowerShell で実装された機能など使っている場合は、ローカルでは動くのに Azure に上げたら動かないという可能性がありえるので、Azure 上のバージョンで問題ないかは早めに確認しておくのが無難。
2018 年までは結構古い 4.0 でバージョンが止まっていたので、必ずしも最新のバージョンがインストールされるとは限らないことに注意。
Azure PowerShell のバージョンについて
PowerShell 本体のバージョンと異なり、App Service VM 上にインストールされている Azure PowerShell のバージョンは恐ろしいほど低く、2019/4 現在は、以下のようにバージョン 1.4 となっている。
> Get-Module -ListAvailable -Name Azure -Refresh
利用する内容にもよるとは思うが、基本的には古すぎて、これを利用するのは現実的ではないと思われる。 PowerShell 本体同様、PaaS なので VM イメージに含まれる上記ライブラリをアップデートするのは無理なのだが、対策はある。
Question: Azure Powershell Scripts in a Function · Issue #294 · Azure/Azure-Functions · GitHub
詳細は上記サイトを確認してもらいたいが、要は、
- 対象 Auzre PowerShell モジュールをフォルダごと App Service のフォルダにアップロード
- プログラムでは、1 でアップロードした psd1 モジュールを Global パラメータ付きでインポート
- 通常通り、Azure PowerShell のコマンドを使用
となる。当該モジュールは Kudu でアップロードして使用するのももちろん可能だが、Functions などのプロジェクトで使用するのであれば、プロジェクトの静的ファイルに当該モジュールを含めて、プロジェクトのデプロイ時に Auzre PowerShell のライブラリも一緒にデプロイされるようにした方が、デプロイが楽になると思われる。
また、そうすることでローカルでも Azure でも常に同じバージョンの Azure PowerShell を使うことになるので、ローカルと Azure で動作に差異が発生する可能性が抑えられる。
PowerShell の実行権限について
.NET の Automation で PowerShell を使用する場合は、PowerShell 実行権限の変更が必要になる。詳細は下記参照。
