Azure Automation 状態構成からマシン構成への移行計画
Note
Azure Automation State Configuration は 2027 年 9 月 30 日に廃止されます。その日までに Azure Machine Configuration に切り替えてください。 詳細については、お知らせのブログ記事を参照してください。 Azure マシンの構成サービスでは、DSC 拡張機能と Azure Automation State Configuration の機能のほか、顧客のフィードバックで最も一般的に要求されている機能が組み合わされています。 Azure マシンの構成には、Arc 対応サーバーによるハイブリッド マシンのサポートも含まれています。
マシンの構成は、Azure Automation State Configuration (別名 Azure Automation Desired State Configuration (AADSC)) によって提供される機能の、最新の実装です。 可能であれば、この新サービスにコンテンツとマシンを移行する計画を立ててください。 この記事では、Azure Automation からマシン構成に移行する計画の立て方を説明します。
マシン構成の新機能は、お客様の要求に対応したものです。
- 構成のサイズ制限を 100 MB に増やしました
- Azure Resource Graph を利用した、リソース の ID と情報を含む詳細なレポート
- 同じマシンに対する複数の構成を管理する機能
- マシンが望ましい状態ではなくなったときに修復を行うタイミングを制御する機能
- Linux と Windows 両方の PowerShell ベースの DSC リソース
作業を始める前に、Azure Policy のマシン構成に関するページで、おおまかな説明を読んでおくといいでしょう。
移行について理解する
コンテンツを先に再デプロイし、その後でマシンを移行するのが、最もいい移行方法です。 このセクションでは、移行に必要な手順について説明します。
- Azure Automation から構成をエクスポートする
- 必要なモジュールを確認して環境にロードする
- 構成をコンパイルする
- マシン構成パッケージの作成と発行
- テスト マシン構成パッケージ
- ハイブリッド マシンを Azure Arc にオンボードする
- Azure Automation State Configuration からサーバーの登録を削除する
- マシン構成を使用したサーバーへの構成の割り当て
マシン構成では、PowerShell version 7 で DSC version 2 を使用します。 DSC version 3 は、Windows および Linux で、古いバージョンの DSC と共存できます。 実装は別々になります。 ですが競合は検出されません。
マシン構成では、サービスに対するモジュールや構成の発行、サービス上でのコンパイルは必要ありません。 代わりに、専用のツールを使用してコンテンツを開発してテストし、HTTPS でマシンからアクセスできるあらゆる場所 (通常は Azure Blob Storage) にコンテンツを発行できます。
しばらくの間両方のサービスにマシンを置いておきたい場合、技術的な障壁はありません。 それら 2 つのサービスは独立しています。
Azure Automation からコンテンツをエクスポートする
最初に、Azure Automation State Configuration にあるコンテンツを検出して、マシン構成のコンテンツ パッケージを作成、テスト、発行する開発環境にそれをエクスポートし、ます。
構成
構成スクリプトは、Azure Automation からのみエクスポートできます。 ノードの構成やコンパイル済み MOF ファイルはエクスポートできません。 MOF ファイルを直接 Automation アカウントに発行して元のファイルにアクセスできなくなった場合、非公開構成スクリプトから再コンパイルする必要があります。 元の構成が見つからない場合は再作成する必要があります。
Azure Automation から構成スクリプトをエクスポートするには、まず、目的の構成がある Azure Automation アカウントと、Automation Account がデプロイされているリソース グループの名前を調べます。
PowerShell の Az.Automation モジュールをインストールします。
Install-Module -Name Az.Automation
次に、Get-AzAutomationAccount
コマンドを使用して、Automation Account と、それがデプロイされているリソース グループを特定します。 次のステップでは ResourceGroupName と AutomationAccountName プロパティが重要です。
Get-AzAutomationAccount
SubscriptionId : <your-subscription-id>
ResourceGroupName : <your-resource-group-name>
AutomationAccountName : <your-automation-account-name>
Location : centralus
State :
Plan :
CreationTime : 6/30/2021 11:56:17 AM -05:00
LastModifiedTime : 6/30/2021 11:56:17 AM -05:00
LastModifiedBy :
Tags : {}
Automation Account の構成を見つけます。 構成ごとに 1 つのエントリが出力されます。 たくさんある場合は、扱いやすいように、その情報を変数に保存します。
$getParams = @{
ResourceGroupName = '<your-resource-group-name>'
AutomationAccountName = '<your-automation-account-name>'
}
Get-AzAutomationDscConfiguration @getParams
ResourceGroupName : <your-resource-group-name>
AutomationAccountName : <your-automation-account-name>
Location : centralus
State : Published
Name : <your-configuration-name>
Tags : {}
CreationTime : 6/30/2021 12:18:26 PM -05:00
LastModifiedTime : 6/30/2021 12:18:26 PM -05:00
Description :
Parameters : {}
LogVerbose : False
最後に、Export-AzAutomationDscConfiguration
コマンドを使用して各構成をローカル スクリプト ファイルにエクスポートします。 結果のファイル名では \ConfigurationName.ps1
というパターンが使われます。
$exportParams = @{
OutputFolder = '<location-on-your-machine>'
ResourceGroupName = '<your-resource-group-name>'
AutomationAccountName = '<your-automation-account-name>'
Name = '<your-configuration-name>'
}
Export-AzAutomationDscConfiguration @exportParams
UnixMode User Group LastWriteTime Size Name
-------- ---- ----- ------------- ---- ----
12/31/1600 18:09
PowerShell パイプラインで構成をエクスポートする
すべての構成をお使いのコンピューター上のローカル フォルダーにエクスポートできます。 このプロセスを自動化するには、前の例の各コマンドの出力を次のコマンドにパイプします。
次の例では 5 つの構成をエクスポートします。 成功したかどうかは、出力パターンから判断します。
Get-AzAutomationAccount |
Get-AzAutomationDscConfiguration |
Export-AzAutomationDSCConfiguration -OutputFolder <location on your machine>
UnixMode User Group LastWriteTime Size Name
-------- ---- ----- ------------- ---- ----
12/31/1600 18:09
12/31/1600 18:09
12/31/1600 18:09
12/31/1600 18:09
12/31/1600 18:09
複雑な構成ファイルの分割を検討する
マシン構成では、マシンごとに複数の構成を管理できます。 Azure Automation State Configuration 用に書かれた構成の多くは、マシン 1 台につき構成 1 つという制約があります。 マシン構成が提供する拡張機能を活用して、大きな構成ファイルを多くの小さな構成に分割し、構成ごとに 1 つの特定のシナリオを処理できます。
マシン構成には、構成の並べ替えの順序を制御するためのオーケストレーションはありません。 順番に実行する必要がある場合は、構成の手順を 1 つのパッケージ内にまとめます。
モジュール
Azure Automation からモジュールをエクスポートしたり、どの構成にどのモジュールやバージョンが必要かを自動的に関連付けたりすることはできません。 新しいマシン構成パッケージを作成するには、ローカル環境にモジュールが存在する必要があります。 移行に必要なモジュールのリストを作成するには、PowerShell で Azure Automation へのクエリを実行して、モジュールの名前とバージョンを取得します。
カスタム作成したモジュールを使用しており、非公開の開発環境にのみ存在する場合、そのモジュールは Azure Automation からエクスポートできません。
構成とアカウントに必要なモジュールがない場合は、構成をコンパイルできません。 そのため、構成を移行できません。
Azure Automation にインポートしたモジュールのリストを取得する
Automation アカウントにインストールしたすべてのモジュールのリストを取得するには Get-AzAutomationModule
コマンドを使用します。 IsGlobal プロパティを見れば、モジュールが常に Azure Automation に組み込まれているかどうか、またはモジュールがアカウントに発行されたかどうかがわかります。
たとえば、自分のアカウントのいずれかに発行したすべてのモジュールのリストを作成するには、次のようにします。
Get-AzAutomationAccount |
Get-AzAutomationModule |
Where-Object IsGlobal -eq $false
PowerShell ギャラリーを補助的に使用して、公開しているモジュールの詳細を確認することもできます。 次の例では、新しい Automation アカウントに組み込まれており、DSC リソースを含むモジュールの一覧を示します。
Get-AzAutomationAccount |
Get-AzAutomationModule |
Where-Object IsGlobal -eq $true |
Find-Module -ErrorAction SilentlyContinue |
Where-Object {'' -ne $_.Includes.DscResource} |
Select-Object -Property Name, Version -Unique |
Format-Table -AutoSize
Name Version
---- -------
AuditPolicyDsc 1.4.0
ComputerManagementDsc 8.4.0
PSDscResources 2.12.0
SecurityPolicyDsc 2.10.0
xDSCDomainjoin 1.2.23
xPowerShellExecutionPolicy 3.1.0.0
xRemoteDesktopAdmin 1.1.0.0
PowerShell ギャラリーまたは PowerShellGet リポジトリからモジュールをダウンロードする
PowerShell ギャラリーからモジュールをインポートした場合は、出力を Find-Module
から直接 Install-Module
にパイプで渡せます。 パイプを使って複数のコマンド間で出力を受け渡しすると、その時点で Automation Account に存在するモジュールのうち、PowerShell ギャラリーに公開されているものすべてを、開発環境にロードできます。
同じ方法を使って、モジュールをカスタム NuGet フィードからプルできます。 フィードを、PowerShellGet リポジトリとしてローカル環境に登録する必要があります。
この例の Find-Module
コマンドはエラーを抑制しません。つまり、ギャラリーに存在しないすべてのモジュールに対してエラー メッセージが返されます。
Get-AzAutomationAccount |
Get-AzAutomationModule |
Where-Object IsGlobal -eq $false |
Find-Module |
Where-Object { '' -ne $_.Includes.DscResource } |
Install-Module
構成スクリプトを見て必要なモジュールを確認する
構成スクリプトを Azure Automation からエクスポートした後、その内容を見て、各構成を MOF ファイルにコンパイルするのに必要なモジュールを確認できます。 この方法は、Automation アカウントでモジュールがない構成が見つかった場合にのみ必要です。 それらの構成にはもうマシンに対する効力がありませんが、引き続きアカウントに残る場合があります。
各ファイルの先頭に向かって、"Import-DscResource
" を含む行を探します。 このコマンドは構成の内部でのみ使用でき、コンパイル時にモジュールをロードします。
たとえば、PowerShell ギャラリーの WindowsIISServerConfig
構成には、この例の行が含まれています。
configuration WindowsIISServerConfig
{
Import-DscResource -ModuleName @{ModuleName = 'xWebAdministration';ModuleVersion = '1.19.0.0'}
Import-DscResource -ModuleName 'PSDesiredStateConfiguration'
この構成では、xWebAdministration モジュールの version 1.19.0.0 と PSDesiredStateConfiguration モジュールが必要です。
Azure マシン構成でのコンテンツのテスト
Azure Automation State Configuration の内容をマシンの構成に使用できるかどうかを調べるには、「カスタム マシン構成パッケージの成果物の作成方法」の詳しいチュートリアルに従って行います。
構成を作成するの手順では、MOF ファイルを生成する構成スクリプトに、Azure Automation State Configuration からエクスポートしたスクリプトの 1 つを使用します。 構成を MOF ファイルにコンパイルしてマシン構成パッケージを作成するには、必要な PowerShell モジュールを環境にインストールしておく必要があります。
モジュールがマシン構成で動作しない場合はどうすればいいですか。
モジュールによっては、マシン構成で互換性のイシューが起こる場合があります。 よくあるのは .NET Framework と .NET Core の間の問題です。 技術的な情報について詳しくは、「Windows PowerShell 5.1 と PowerShell 7.x の違い」のページをご覧ください。
互換性の問題を解決するには、powershell.exe
を実行して、PowerShell 7 にインポートしたモジュールから Windows PowerShell でコマンドを実行します。 Azure-Policy リポジトリに、この方法を実行するサンプル モジュールがあります。このモジュールでは Windows DSC 構成 の状態を検査します。
この例は、簡単な概念実証の例にもなっています。
# example function that could be loaded from module
function New-TaskResolvedInPWSH7 {
# runs the fictitious command 'Get-myNotCompatibleCommand' in Windows PowerShell
$compatObject = & powershell.exe -NoProfile -NonInteractive -Command {
Get-myNotCompatibleCommand
}
# resulting object can be used in PowerShell 7
return $compatObject
}
移行するすべてのモジュールの Get-TargetResource に Reasons プロパティを追加する必要がありますか。
Reasons プロパティを設定すると、Azure portal で構成の割り当ての結果が見やすくなります。 モジュールの Get
メソッドで Reasons を指定しない場合は、Get
メソッドで取得できるプロパティの詳細を含む標準の出力が表示されます。 よって、移行時にこれを行うかどうかは任意です。
マシン
Azure Automation State Configuration は、Azure 上の仮想マシンと Azure 外のハイブリッド マシンのどちらでも利用できます。 これらの各シナリオに対し、異なる手順による計画を立てる必要があります。
Azure VM
Azure 上には既に Azure 仮想マシン用の リソース があります。つまり、マシン構成割り当てを行って、その仮想マシンを構成に関連付ける準備ができています。 Azure Automation State Configuration から仮想マシンを削除してから、マシン構成を使用して構成を割り当てるのが、Azure 仮想マシン移行の全体的な手順です。
Azure Automation State Configuration からマシンを削除するには「Automation State Configuration から構成とノードを削除する方法」の手順に従います。
マシンの構成を使用した構成の割り当ては、ポリシーの割り当てを作成し準拠していないリソースを特定するクイックスタートなどの、Azure Policy クイックスタートの手順に従って行います。 ステップ 6 でポリシー定義を選ぶときは、Azure Automation State Configuration から移行した、構成に対して適用可能な定義を選びます。
ハイブリッド マシン
Azure の外にあるマシンも Azure Automation State Configuration に登録できますが、Azure にはそのマシンのためのマシン リソースがありません。 マシン内のローカル Configuration Manager (LCM) サービスは、Azure Automation への接続を処理します。 ノードのレコードは、Azure Automation プロバイダーの種類のリソースとして管理されます。
Azure Automation State Configuration からマシンを削除する前に、Azure Arc 対応サーバーとして各ノードをオンボードします。 Azure Arc にオンボードすると、Azure にマシン リソースが作成されるため、Azure Policy でマシンを管理できます。 マシンはいつでも Azure Arc にオンボードできますが、Azure Automation State Configuration を使用すればこのプロセスを自動化できます。
コンテンツのエクスポートに関するトラブルシューティング
このセクションでは、既知のイシューについて詳しく説明します。
構成をエクスポートすると、ファイル名に "\" 記号が含まれる
macOS と Linux で PowerShell を使うと、Export-AzAutomationDSCConfiguration
によるファイル名の出力に関する問題が発生する場合があります。
回避策としては、PowerShell ギャラリーから AADSCConfigContent モジュールをインストールします。 このモジュールに含まれる 1 つのコマンドは、サービスに対して REST 要求を行い、Azure Automation に格納されている構成の内容をエクスポートします。
次のステップ
- カスタムのマシンの構成パッケージを開発する。
- GuestConfiguration モジュールを使用して、環境を大規模に管理するための Azure Policy の定義を作成する。
- Azure portal を使用してカスタム ポリシー定義を割り当てる。
- マシン構成のポリシー割り当てのコンプライアンスの詳細を確認する方法を学ぶ。