Azure サーバーレスで PowerShell を 使う話 株式会社リクルート Yuki Nakayama 第37回 Tokyo Jazug Night (Online) 

自己紹介 中山 祐樹 Yuki Nakayama 株式会社リクルート所属（2021 年 1 月～） 主な業務：Microsoft 365 / Azure AD の運用・管理 Azure 歴 6 年ぐらい 

本日のテーマ Azure 上で PowerShell を実行する話をします。 Azure 上でサーバーレスで PowerShell を実行する方法として Azure Functions と Azure Automation の紹介・比較を行います。 

まず最初に PowerShell の話 

PowerShell? PowerShell is a cross-platform task automation solution made up of a command-line shell, a scripting language, and a configuration management framework. • Windows に標準搭載のシェル&スクリプト言語 • 標準搭載は Windows 7/Windows Server 2008 R2 以降 • クロスプラットフォーム（Linux/Mac でも使える） • オンプレ・クラウド問わずインフラ運用管理によく使われる • Azure • Microsoft 365 • Windows Server • AWS • etc... 

PowerShell Versions PowerShell 1.0 ～ 5.1（Windows PowerShell） • Windows に標準搭載 • .NET Framework 上で動く（Windows 以外では使えない） • サポートライフサイクルは OS と一緒 • 6.0 以降と区別する場合は Windows PowerShell と呼ぶ • 今後、新機能は追加されない PowerShell 6.0 ～ 7.x（旧 PowerShell Core） • （今のところ）Windows でも標準搭載されておらずインストールが必要 • .NET Core/.NET 上で動く（Mac/Linux でも動く） • サポートライフサイクルは .NET のライフサイクルに依存する（最長３年） • 6.2 までは PowerShell Core と呼ばれていたが 7.0 以降は単に PowerShell が正式名称。最新は 7.2。 • PowerShell Workflow は使えない（同等の機能が追加される予定） 

サーバーレスで PowerShell 

Azure Functions • Azure の代表的なサーバーレスサービス（FaaS） • 2019 年 11 月に PowerShell に対応（GA） • PowerShell の場合、関数の実体は run.ps1、 設定は function.json で定義する 

HTTP Trigger のイメージ（デフォルトのコード） run.ps1 $Request でクエリパラメーターや リクエストボディを受け取る $TriggerMetadata には実行日時や関 数名などのメタデータが入る $Request からクエリパラメータや リクエストボディを取り出す Push-OutputBinding でレスポンスを返す function.json 

Azure Automation • 「時間がかかり、エラーが発生しやすく、頻繁に繰り返されるタスクを Windows PowerShell で自動化するプロセスのためのクラウド オートメーショ ン サービス」（MS 公式サイト HTML description の記載） ▶ PowerShell 7 と Python も使えます • 当初から PowerShell 実行を目的としてリリースされたサービス（2014 年 7 月 GA） • スクリプト実行以外に物理/仮想マシンの構成管理や更新プログラム管理にも使 える（今回は割愛） • 使用する場合は最初に「Automation アカウント」という入れ物(?)を作成し、 「Runbook」という単位でスクリプトを管理する（ひとつの Runbook がひと つの .ps1 ファイルに対応） 

Automation アカウントと Runbook 1 Runbook = 1 スクリプトファイル 

Azure Functions vs Azure Automation 

利用できるバージョン Azure Automation • PowerShell 5.1 & PowerShell 7.1 が利用可（PowerShell 7.1 は 2022 年 3 月時点でプレビュー） Azure Functions • PowerShell 7.0 のみ利用可 PowerShell 7.x に対応していないモジュールを使う場合は Azure Functions は使用できない… 対応してないモジュールの例：AzureAD / MSOnline （どちらも 7.x への対応予定無し…） PowerShell 7.x は 5.1 の完全上位互換ではないので PowerShell 5.1 もまだまだ現役 

起動方法（トリガー） Azure Automation • ポータルから手動実行 • スケジュール実行 • Webhook • Web API / SDK からの実行（Start-AzAutomationRunbook とか） Azure Functions • HTTP トリガー • Timer トリガー • Azure Blob Storage トリガー / Azure Queue Storage トリガー / Azure Cosmos DB トリガー • Azure Event Grid トリガー / Azure Event Hub トリガー • その他いろいろ… 起動方法の豊富さ・柔軟さは Azure Functions Azure Automation は シンプル 

バインド（入力バインド・出力バインド） Azure Automation • バインド機能は無し • 実行時にパラメーターに値を渡すことはできる Azure Functions 出力バインド 入力バインド Azure Automation には バインド機能なし 他サービスと多数連携する 場合は Azure Function の方が便利 

ID（他リソースへのアクセスのための認証） Azure Automation • Azure リソースにアクセスするためには以前は実行アカウント（Run as account）を主に使用 • 実行アカウントの実体はサービスプリンシパル • 以前は Automation アカウント作成時に作成ダイアログが表示されたが現在はマネージドIDに置換 • 過去の記事は実行アカウント利用が前提のものが多いので注意 • 2021 年 11 月にマネージド ID が GA。現在はマネージド ID の利用が推奨 Azure Functions • マネージド ID ！ どちらも マネージド ID を使いましょう 

環境変数 Azure Automation • 共有リソース（Automation アカウント内で共有できる変数など） • 変数（暗号化可）/資格情報（ユーザー名とパスワード） • 接続（サービスプリンシパルの接続情報）/証明書 • 暗号化された変数や資格情報などはシステム管理の Key Vault に格納される • 暗号化された値はポータルからも見えなくなる Azure Functions • 環境変数はアプリケーション設定に格納 • セキュアな値の場合は Key Vault に格納してマネージド ID で接続 追加のリソース無しで 証明書や資格情報も格納できる Azure Automation が便利 

モジュール管理 Azure Automation • 共有リソース（モジュール） • Automation アカウントに PowerShell ギャラリーから事前にインストールしておく • カスタムモジュールの場合も同様に共有リソースにアップロード Azure Functions • 「requirements.psd1」に記載しておくと起動時に PowerShell ギャラリーから読み込む • 指定できるモジュールは最大 10 個まで • Az など多数のモジュールを読み込むモジュールの場合は時間がかかるので注意 • カスタムモジュールの場合は Function App のモジュールに含めておく Azure Automation は カスタムモジュール管理がやや面倒 Azure Functions は 柔軟だがやや面倒 

実行ログ Azure Automation • Runbook の実行結果は「ジョブ」という単位で記録される • 実行履歴は既定で１カ月保持される • 30 日以上保持したい場合は Azure Monitor に転送 Azure Functions • ポータルではリアルタイムの実行ログは確認できる • Aplication Insights の利用が基本（必須ではないが、ほぼ必須） 追加リソース無しで基本的なログが 管理できる Azure Automation の方が やや便利？ 

開発環境 Azure Automation • ポータルで直接コーディング • ローカルで開発した場合はポータル/SDK から .ps1 ファイルをアップロード • ローカルで Azure Automation を実行する方法は今のところ無し Azure Functions • ポータルで直接コーディング • Azure Functions Core Tools と VSCode の Azure Functions Extension でローカル実行も可 開発環境は Azure Functions の方が 整っている 

デプロイ Azure Automation • ポータル / SDK から ps1 ファイルをアップロード • 「ソース管理」（GitHub/Azure Repos のリポジトリと Automation アカウントを同期） • GitHub / Azure Repos 以外のリポジトリでは使えない Azure Functions • VSCode の拡張機能から直接アップロード • GitHub Actions / Azure Pipeline 等を利用して CI/CD 使える環境は限られるが Azure Automation のソース管理は便利 

複雑な実行（スクリプトの連携） Azure Automation • モジュラー Runbook • Runbook から他の Runbook を呼び出す機能 • 子 Runbook は親 Runbook と同じジョブとして実行される Azure Functions • Durable Functions（PowerShell での Durable Functions は 2021 年 5 月 GA） • クライアント関数・オーケストレーター関数・アクティビティ関数を組み合わせて実行 Azure Automation でもある程度 複雑なことは可能 Durable Functions が使いたいなら Azure Functions 

最大実行時間 Azure Automation • ジョブあたりの最大実行時間は３時間 • ３時間以上実行したい場合は Hybrid Runbook Worker（サーバーレスじゃないけど） Azure Functions • 従量課金の場合は最大 10 分 • Durable Functions の場合、オーケストレーター関数は制限なし（アクティビティ関数は最大10 分） • Premium / App Service プランの場合は無制限（月額課金なのでサーバーレスっぽくなくなる） 従量課金の場合は Azure Function の 制限が厳しい 

必要なリソース Azure Automation • 作成するリソースは Automation アカウントのみ • Runbook もリソースグループにひとつずつ表示される • （Runbook でリソースグループが溢れるのでリソースグループは分けておいた方がよい） Azure Functions • Function App / App Service プラン / ストレージアカウントが必須） • ストレージアカウントにはソースコードと一時ファイルなどが格納される • Application Insights / Log Analytics ワークスペースもほぼ必須 • セキュアな管理には Key Vualt（キーコンテナーも） 

料金 Azure Automation • ¥0.232/分 • 毎月 500 分の無料実行 Azure Functions • ¥0.001850/GB 秒 • 100 万実行回数あたり ¥23.121 • 毎月 400,000 GB 秒 の無料時間 / 100 万実行回数まで無料 • その他ストレージアカウントや Application Insights の料金もかかる Azure Automation は明朗会計 Azure Functions は料金が読みづらい 

まとめ Azure Automation • PowerShell 5.1 が必要な場合は Azure Automation • シンプルなスクリプト実行の場合は Azure Automation が第一候補？ • 実行時間が長い/料金が分かりやすい/証明書や資格情報管理が単独で可能… Azure Functions • 別言語での Azure Functions の開発に慣れているならアリ • 複雑度が高い場合もアリ（バインドや Durable Functions） • Web API 的に使いたい場合（HTTP トリガー） 両方の特徴を把握して自分に合った方を選びましょう 

ありがとうございました