Office 365 の PowerShell 運用を PaaS 化してみる
背景
いくつもの Office 365 プロジェクトで Azure AD Connect サーバーや PowerShell 専用サーバーに運用スクリプトを配置するという場面に多く出くわしてきました。
「簡単な PowerShell じゃん」と言う人もいるでしょう。それによて運用・管理者はトイルが溜まるんです。
そんな現場が減ることを願って PowerShell の PaaS 化を手順化してみました。
想定シナリオ
Contoso 社はサイトコレクション管理のため、定期的に PowerShell でサイトコレクションの一覧をエクスポートしています。エクスポートされた情報からを容量の統計情報などを Power BI を通してチェックしています。
PowerShell ファイルは現在オンプレミスの Windows Server 上で動作しているため、OS のアップデートメンテナンスの影響を受けたり、資格情報をスクリプト内に記載するなど、運用に耐えられない状態です。
これらの問題を解決するため、Azure Automation を使用して、既存 PowerShell を PaaS 化してサーバーから切り離すことにしました。
諸注意
以降の手順はあくまでも検証目的のものです。
当然ですが、運用環境ではそれ相応の構成や設定を実装しましょう。
特にこんなところ
- 実行アカウントの Service Principal 化
- ソース管理連携 (しない理由が無い)
- Azure Automation の仕様確認 (課金、制約など)
本日の献立
メイン : PowerShell の PaaS 化
1. Azure Automation をデプロイする
1. まずは Azure Resource Group を作成します。
2. 作成した Resource Group で新しいリソース「オートメーション (Azure Automation)」を追加します。
3. Azure Automation のリソース名や場所を選択して「作成ボタン」をクリックします。
※ 今回「Azure 実行アカウント」は使用しないので、「いいえ」を選択します。
リソースのデプロイが完了した後に Azure Automation を開くと、こんな画面に。
4. メニューの中から「モジュール」を選択して、モジュールの追加をします。
既定では主に Azure 系のモジュールが登録されています。
5. 今回は PnP PowerShell を使うため、検索ボックスに「pnp」を入力して検索を実施します。
6. 「インポート」ボタンをクリックして、Azure Automation にモジュールを追加します。
7. モジュールの追加が完了したら、メニューの「資格情報」で「資格情報の追加」を行います。
※ 冒頭にも記載していますが今回は検証目的なので、「MFA を設定していない SharePoint 管理者アカウント」を指定しています。本番では Service Principal を変数に登録して利用するのが良いはず。
「MFA 無しアカウント」「共有アカウント」を運用で使用するのは、個人的に「無し」の方針です。
2. PowerShell スクリプトを登録する
いよいよ PowerShell スクリプトの移植を進めていきます。
1. メニューの「Runbook」から「Runbook の作成」を行います。
※ 「Runbook の種類」は「PowerShell」を選択します。
2. Runbook の作成が完了すると自動的に PowerShell の編集画面が表示されるので、まずはテストがてらテナント内のサイトコレクション一覧を出力するコードを書いてみます。
※ 既に資格情報は登録してあるので「Get-AutomationPSCredential」で読み込むことができます。
※ 冒頭にも記載したように、あくまで検証実装なので直接編集しています。運用環境では Azure Repos (Azure DevOps) とのソース管理連携を行いましょう。
3. Runbook 編集画面の「テストウィンドウ」をクリックすることで、現在の状態の PowerShell をテストすることができるので、試しに実行してみます。
4. Runbook の編集画面に戻り、データを SharePoint のライブラリにアップロードするように PowerShell コードを編集します。
5. 前述と同じように「テストウィンドウ」で実行して処理が完了すると、CSV ファイルが保存されていることが確認できます。
このままだとこれまでの PowerShell 同様にテナント情報などをべた書きしたままなので、一部の情報を Azure Automation リソース内で共有できる「変数」として扱うように設定します。
6. Azure Automation の画面まで戻って、メニューの「変数」を開いて「変数の追加」を行います。
※ ここでは変数名を「TenantName」として検証テナントの名前 (.onmicrosoft.com の前の部分) を登録します。
7. Runbook の編集画面を開き、「Get-AutomationVariable」を使って変数を読み込みます。
8. とは言え、後から CSV ファイル保存先となるサイトコレクションやライブラリを簡単に変えられるように、パラメーターを定義します。
9. 最後に「公開」をクリックして、この Runbook が利用できるようにします。
3. スケジュールを登録する
Runbook を定期実行するために 「スケジュール」を追加します。
これで Azure Automation の定期実行の登録は完了です。
オプション : Flow を使用した PowerShell の実行と活用
今回の PowerShell では利用する機会がないかもしれませんが、このように Microsoft Flow / Logic Apps を利用することで、その他のイベントをトリガーに PowerShell を実行することも可能です。
もちろん Microsoft Flow のアクションの中で Runbook パラメーターを指定できるので、Runbook を定期実行しつつ「こんな条件で実行しておきたい」なんて時には Microsoft Flow から個別に実行できるように作れたりといったことも考えられます。