マシン構成のために PowerShell Desired State Configuration の動作を変更する

開始する前に、マシン構成の概要を参照することをお勧めします。

このドキュメントのビデオ チュートリアルを利用できます。

マシン構成では、PowerShell Desired State Configuration (PSDSC) バージョン 3 を使用してマシンを監査および構成します。 DSC 構成では、マシンで満たされている必要がある状態を定義します。 マシン構成での DSC の実装方法には、多くの重要な違いがあります。

マシン構成でプラットフォームをまたいで PowerShell 7 を使用する

マシン構成は、Windows と Linux の管理エクスペリエンスが一貫性を持つように設計されています。 どちらのオペレーティング システム環境でも、PowerShell DSC の知識を持つユーザーは、スクリプトのスキルを使用して構成を作成して発行できます。

マシン構成では、PowerShell DSC バージョン 3 のみが使用され、Linux 用 DSC の以前の実装や、そのリポジトリに含まれる nx* プロバイダーには依存していません。

バージョン 1.26.33 のマシン構成は、Windows 用の PowerShell 7.1.2 と Linux 用の PowerShell 7.2 プレビュー 6 で動作します。 バージョン 7.2 以降では、PSDesiredStateConfiguration モジュールは PowerShell のインストールの一部ではなくなり、代わりに PowerShell ギャラリーからモジュールとしてインストールされます。

複数の構成

マシン構成では、同じマシンへの複数の構成の割り当てがサポートされます。 マシン構成拡張機能のオペレーティング システム内で必要となる特別な手順はありません。 部分構成を構成する必要はありません。

依存関係は構成ごとに管理される

利用できるツールを使用して構成をパッケージ化すると、構成に必要な依存関係が .zip ファイルに組み込まれます。 マシンによって、構成ごとに内容が一意のフォルダーに抽出されます。 マシン構成拡張機能によって提供されるエージェントにより、構成ごとに専用の PowerShell セッションが作成されます。 そのときに使用する $Env:PSModulePath は、モジュールの自動読み込みをパッケージが抽出されたパスだけに制限します。

この変更には、次のような複数の利点があります。

• 同じマシンで、構成ごとに異なるモジュール バージョンを使用できます。
• 構成がマシンで不要になったとき、エージェントは構成が抽出されたフォルダー全体を安全に削除します。 共有される依存関係を構成間で管理する必要はありません。
• 中央のサービスでモジュールの複数のバージョンを管理する必要はありません。

成果物はパッケージとして管理される

Azure Automation State Configuration 機能には、モジュールと構成スクリプトの成果物管理が含まれます。 両方がサービスに発行されると、スクリプトを MOF 形式にコンパイルできます。 同様に、Windows プル サーバーは Web サービス インスタンスで構成とモジュールを管理する必要がありました。 これに対し、DSC 拡張機能ではモデルが簡略化されており、すべての成果物がまとめてパッケージ化され、HTTPS 要求を使用してターゲット マシンからアクセスできる場所に格納されます。 Azure Blob Storage は、成果物をホストするための一般的なオプションです。

マシン構成では、すべての成果物がまとめてパッケージ化され、HTTPS 経由でターゲット マシンからアクセスされる、簡略化されたモデルのみが使用されます。 サービスでモジュール、スクリプト、またはコンパイルを発行する必要はありません。 1 つの変更点は、コンパイル済みの MOF が常にパッケージに含まれる必要があることです。 スクリプト ファイルをパッケージに組み込み、ターゲット マシンでコンパイルすることはできません。

カスタム構成パッケージの最大サイズ

Azure Automation の状態の構成では、DSC 構成でサイズの制限がありました。 マシン構成では、圧縮前で合計 100 MB のパッケージ サイズがサポートされます。 パッケージ内の MOF ファイルのサイズに特定の制限はありません。

構成モードはパッケージ成果物で設定する

構成パッケージを作成するとき、モードは次のオプションを使用して設定されます。

• Audit - マシンのコンプライアンスを検証します。 変更は行われません。
• AuditandSet - マシンのコンプライアンス状態を検証して修復します。 マシンが準拠していない場合は、変更が行われます。

モードは、ローカル Configuration Manager サービスではなく、パッケージで設定されます。これは、各構成が異なるモードで適用される可能性があるからです。

Azure Resource Manager を介したパラメーターのサポート

構成 MOF ファイルがマシンに格納されている場合、マシン構成の割り当てで configurationParameter プロパティ配列によって設定されたパラメーターによって、そのファイル内の静的テキストが上書きされます。 パラメーターによってカスタマイズが可能になり、オペレーターが変更をサービス API から制御することができ、マシン内でコマンドを実行する必要がありません。

マシン構成の割り当てに値を渡す Azure Policy のパラメーターは、"文字列" 型である必要があります。 DSC リソースで配列がサポートされている場合でも、パラメーターを使用して配列を渡すことはできません。

外部マシンから設定されたトリガー

以前のバージョンの DSC の課題は、多くのカスタム コードを使用せずに、WinRM リモート接続に依存することなく、大規模なドリフトを修正することでした。 ゲスト構成によってこの問題が解決されます。 マシン構成のユーザーは、オンデマンド修復を使用してドリフトの修正を制御できます。

シーケンスには Get メソッドが含まれる

マシン構成でマシンを監査または構成する場合、同じイベントの順序が Windows と Linux の両方で使用されます。 動作の主な変更点は、マシンの状態に関する詳細を返す Get メソッドがサービスによって呼び出されることです。

1. 最初にエージェントで Test を実行し、構成が正しい状態であるかどうかを判断します。
2. パッケージが Audit に設定されている場合、この関数から返されるブール値によって、ゲスト割り当ての Azure Resource Manager の状態が Compliant であるか NonCompliant であるかが決定します。
3. パッケージが AuditandSet に設定されている場合、このブール値によって、Set メソッドを使用して構成を適用することによりマシンを修復するかどうかが決定します。 Test メソッドによって $false が返される場合、Set が実行されます。 Test によって $true が返される場合、Set は実行されません。
4. 最後に、プロバイダーによって Get が実行され、各設定の現在の状態が返されます。これにより、マシンが準拠していない理由と、現在の状態が準拠していることの確認に関する両方の詳細情報が得られます。

Get の特別な要件

DSC の Get メソッドには、DSC では必要とされなかったマシン構成に関する特別な要件があります。

• 返されるハッシュテーブルには Reasons という名前のプロパティが含まれている必要があります。
• Reasons プロパティは配列である必要があります。
• 配列内の各項目は、コードおよびフレーズという名前のキーを持つハッシュテーブルである必要があります。
• ハッシュテーブル以外の値を返さないでください。

Reasons プロパティは、コンプライアンス情報をどのように表すかをサービスで標準化するために使用されます。 Reasons の各項目は、そのリソースがどのように準拠しているか、または準拠していないかのメッセージと考えることができます。 リソースが複数の理由で準拠していない可能性があるため、プロパティは配列となっています。

サービスでは、プロパティ コードおよびフレーズを指定する必要があります。 カスタムリソースを作成する場合、リソースが準拠していない理由として表示するテキストをフレーズの値に設定します。 コードには特定の書式設定要件があるため、監査を行うために使用されたリソースに関する情報をレポートではっきり表示できます。 このソリューションにより、ゲスト構成を拡張できます。 出力を、Phrase プロパティの文字列値として返すことができる限り、任意のコマンドを実行できます。

• コード (文字列):リソースの名前、繰り返し、およびスペースを含まない短い名前を理由の識別子として指定します。 これら 3 つの値は、スペースを含まず、コロンで区切られている必要があります。
  • たとえば、registry:registry:keynotpresent などです
• フレーズ (文字列):設定が準拠していない理由を説明するための、人間が判読できるテキスト。
  • たとえば、The registry key $key isn't present on the machine. などです

$reasons = @()
$reasons += @{
  Code   = 'Name:Name:ReasonIdentifer'
  Phrase = 'Explain why the setting is not compliant'
}
return @{
    reasons = $reasons
}

コマンドライン ツールを使用して Get で返される情報を取得すると、予期しない出力が返されることがあります。 PowerShell で出力をキャプチャする場合でも、出力が標準エラーに書き込まれている可能性があります。 この問題を回避するには、出力を null にリダイレクトすることを検討してください。

Reasons プロパティが埋め込まれたクラス

スクリプトベースのリソース (Windows のみ) では、スキーマ MOF ファイルに Reasons クラスを次のように含めます。

[ClassVersion("1.0.0.0")]
class Reason
{
  [Read] String Phrase;
  [Read] String Code;
};

[ClassVersion("1.0.0.0"), FriendlyName("ResourceName")]
class ResourceName : OMI_BaseResource
{
  [Key, Description("Example description")] String Example;
  [Read, EmbeddedInstance("Reason")] String Reasons[];
};

クラスベースのリソース (Windows と Linux) では、PowerShell モジュールに Reason クラスを次のように含めます。 Linux では、大文字と小文字が区別されるため、Code の C と Phrase の P は大文字にする必要があります。

enum ensure {
  Absent
  Present
}

class Reason {
  [DscProperty()]
  [string] $Code

  [DscProperty()]
  [string] $Phrase
}

[DscResource()]
class Example {

  [DscProperty(Key)]
  [ensure] $ensure

  [DscProperty()]
  [Reason[]] $Reasons

  [Example] Get() {
    # return current current state
  }

  [void] Set() {
    # set the state
  }

  [bool] Test() {
    # check whether state is correct
  }
}

リソースに必須のプロパティがある場合は、Get によって Reason クラスと同時にそれらのプロパティも返される必要があります。 Reason が含まれていない場合、サービスには、Get に入力された値と Get によって返された値を比較し、詳細な比較を Reason として提供する "キャッチオール" の動作が含まれます。

構成名

カスタム構成の名前は、すべての場所で一貫している必要があります。 これらの項目の名前は同じである必要があります。

• コンテンツ パッケージの .zip ファイル
• MOF ファイル内の構成名
• Azure Resource Manager テンプレート内のマシン構成の割り当て名

Windows PowerShell でコマンドを実行する

PowerShell での Windows モジュールの実行は、DSC リソースで次のパターンを使用することで実現できます。 次のパターンでは、Windows PowerShell で使用可能な必須モジュールを検出するために PowerShell の代わりに Windows PowerShell を実行するように PSModulePath を一時的に設定します。 このサンプルは、Secure Web Server の組み込み DSC リソースで使用される DSC リソースを基に作成したスニペットです。

このパターンは、Windows PowerShell から実行する PowerShell 実行パスを一時的に設定し、必須コマンドレット (この場合は Get-WindowsFeature) を検出します。 コマンドの出力が返され、互換性要件のために標準化されます。 コマンドレットが実行されると、$env:PSModulePath が元のパスに戻ります。

# The Get-WindowsFeature cmdlet needs to be run through Windows PowerShell
# rather than through PowerShell, which is what the Policy engine runs.
$null = Invoke-Command -ScriptBlock {
    param ([string]$FileName)

    $InitialPSModulePath   = $env:PSModulePath
    $WindowsPSFolder       = "$env:SystemRoot\System32\WindowsPowershell\v1.0"
    $WindowsPSExe          = "$WindowsPSFolder\powershell.exe"
    $WindowsPSModuleFolder = "$WindowsPSFolder\Modules"
    $GetFeatureScriptBlock = {
        param([string]$FileName)

        if (Get-Command -Name Get-WindowsFeature -ErrorAction SilentlyContinue) {
            Get-WindowsFeature -Name Web-Server |
                ConvertTo-Json |
                Out-File $FileName
        } else {
            Add-Content -Path $FileName -Value 'NotServer'
        }
    }

    try {
        # Set env variable to include Windows Powershell modules so we can find
        # the Get-WindowsFeature cmdlet.
        $env:PSModulePath = $WindowsPSModuleFolder
        # Call Windows PowerShell to get the info about the Web-Server feature
        & $WindowsPSExe -command $WindowsFeatureScriptBlock -args $FileName
    } finally {
        # Reset the env variable even if there's an error.
        $env:PSModulePath = $InitialPSModulePath
    }
}

マシン構成のパブリック プレビュー期間に使用できない DSC の一般的な機能

パブリック プレビュー期間に、マシン構成では、WaitFor* リソースを使用したマシン間の依存関係の指定はサポートされません。 あるマシンで別のマシンを監視し、別のマシンがある状態に達するのを待ってから先に進むことはできません。

再起動処理は、マシン構成のパブリック プレビュー リリースでは使用できません ($global:DSCMachineStatus を使用できないことを含む)。 構成では、構成中または構成の最後にノードを再起動することはできません。

サポートされているモジュールに関する既知の互換性の問題

PowerShell ギャラリーの PsDscResources モジュールと Windows に含まれている PSDesiredStateConfiguration モジュールは、Microsoft によってサポートされ、DSC で一般的に使用される一連のリソースでした。 DSCv3 用に PSDscResources モジュールが更新されるまでは、次の既知の互換性の問題に注意してください。

• Windows に含まれている PSDesiredStateConfiguration モジュールのリソースは使用しないでください。 代わりに、PSDscResources に切り替えます。
• WindowsFeature、WindowsFeatureSet、WindowsOptionalFeature、WindowsOptionalFeatureSet リソースを PsDscResources で使用しないでください。 Windows Server 上の PowerShell 7.1.3 で DISM モジュールを読み込む際に更新が必要になる既知の問題があります。

Linux 用 DSC リポジトリに含まれていた Linux 用の nx* リソースは、C 言語と Python 言語を組み合わせて記述されていました。 Linux での DSC に進むパスでは PowerShell を使用するため、既存の nx* リソースは DSCv3 と互換性がありません。 Linux でサポートされているリソースを含む新しいモジュールが利用可能になるまで、カスタム リソースを作成する必要があります。

DSC バージョン 3 と以前のバージョンの共存

マシン構成の DSC バージョン 3 は、Windows および Linux にインストールされている以前のバージョンと共存させることができます。 実装は別々です。 ただし、DSC バージョン間の競合検出は行われないため、同じ設定を管理しようとしないでください。

次のステップ

• マシン構成の概要を確認する。
• カスタムのマシンの構成パッケージを開発する。
• GuestConfiguration モジュールを使用して、環境を大規模に管理するための Azure Policy の定義を作成する。
• Azure portal を使用してカスタム ポリシー定義を割り当てる。
• マシン構成のポリシー割り当てのコンプライアンスの詳細を確認する方法を学ぶ。