PowerShell DSC を使用して必要な状態を実現する

10 分

PowerShell DSC を使用して、VM の必要な状態を指定できます。このユニットでは、PowerShell DSC の詳細と、それを使用してご使用の VM の状態を制御する方法について学習します。このシナリオ例では、PowerShell DSC を使用して、ご使用のすべての Web サーバーに Windows Server 用の IIS が一貫した方法でインストールおよび構成されるようにします。

このユニットを完了するまでに、次のことを行います。

ノードと構成ブロックについて理解する。
資格情報資産について理解する。
PowerShell DSC コードを記述して Microsoft IIS をべき等でインストールする。

DSC リソース

PowerShell DSC が宣言型のスクリプト言語であることを見てきました。宣言型プログラミングでは、過程ではなく結果に焦点を当てます。一連の VM で Azure リソースを一貫した方法で構成してデプロイする必要がある場合は、PowerShell DSC が役立ちます。ソフトウェアとサービスをインストールして構成するための技術的な手順に慣れていない場合でも、PowerShell DSC を使用できます。

Windows Server には、PowerShell DSC の一連のリソースが組み込まれています。これらのリソースを表示するには、Get-DSCResource PowerShell コマンドレットを実行します。

Get-DscResource | select Name,Module,Properties

次の表には、組み込みの PowerShell DSC リソースの一部が示されています。

リソース	説明
File	ノード上のファイルとフォルダーを管理する
Archive	.zip 形式のアーカイブを圧縮解除する
Environment	システム環境変数を管理する
Log	DSC イベントログにメッセージを書き込む
Package	パッケージをインストールまたは削除する
Registry	ノードのレジストリキーを管理する (HKEY ユーザーを除く)
Script	ノードで PowerShell コマンドを実行する
Service	Windows サービスを管理する
User	ノードのローカルユーザーを管理する
WindowsFeature	ノードの役割または機能を追加または削除する
WindowsOptionalFeature	ノードのオプションの役割または機能を追加または削除する
WindowsProcess	Windows プロセスを管理する

Active Directory 統合など、より複雑なリソースに対しては、毎月更新される DSC リソースキットを使用します。このモジュールの最後にある「まとめ」ユニットに、DSC リソースキットへのリンクがあります。

構成するリソースは、既に VM の一部または VM イメージの一部である必要があります。そうでない場合は、ジョブのコンパイルと実行が失敗します。

DSC コードブロックの構造

DSC コードブロックには、4 つのセクションが含まれています。次の例を使用して詳しく見ていきます。例で示されている番号は、構文の一部ではありません。これらはコメントとして示されており、後の説明のセクションを示します。

Configuration MyDscConfiguration {              ##1
    Node "localhost" {                          ##2
        WindowsFeature MyFeatureInstance {      ##3
            Ensure = 'Present'
            Name = 'Web-Server'
        }
    }
}
MyDscConfiguration -OutputPath C:\temp\         ##4

構成の構文には、次のセクションが含まれます。

Configuration:構成ブロックは、最も外側のスクリプトブロックです。 Configuration キーワードで始まり、名前を指定します。ここでは、構成の名前は MyDscConfiguration です。

構成ブロックには、必要な構成が記述されています。構成ブロックは関数のようなものと考えてください。ただし、リソースをインストールするためのコードではなく、インストールするリソースの記述が含まれています。

PowerShell 関数と同様に、構成ブロックではパラメーターを受け取ることができます。たとえば、ノード名をパラメーター化できます。
```
Configuration MyDscConfiguration {
param
(
    [string] $ComputerName='localhost'
)

Node $ComputerName {
    ...
}
```
Node: 1 つ以上のノードブロックを持つことができます。ノードブロックによって、構成のコンパイル時に生成される .mof ファイルの名前が決まります。たとえば、ノード名 localhost では localhost.mof ファイルを 1 つだけ生成しますが、その .mof ファイルを任意のサーバーに送信できます。複数のノード名を使用する場合は、複数の .mof ファイルを生成します。

複数のホストをターゲットにするには、ノードブロックで配列表記を使用します。次に例を示します。
```
Node @('WEBSERVER1', 'WEBSERVER2', 'WEBSERVER3')
```
Resource:1 つまたは複数のリソースブロックを使用して、構成するリソースを指定できます。この例では、1 つのリソースブロックで WindowsFeature リソースが参照されています。この WindowsFeature リソースを使用して、Windows の機能 Web-Server が確実にインストールされます。
MyDscConfiguration: この呼び出しでは、MyDscConfiguration ブロックが呼び出されます。関数を実行するのと似ています。構成ブロックは、実行時に Managed Object Format (MOF) ドキュメントにコンパイルされます。 MOF は Desktop Management Task Force によって作成されたコンパイル言語であり、インターフェイス定義言語が基になっています。

DSC スクリプトに列記されているすべてのノードに対し、-OutputPath パラメーターで指定したフォルダーに .mof ファイルが作成されます。

DSC スクリプトでの構成データ

構成データブロックでは、構成プロセスで必要になる可能性があるデータを提供できます。このデータは、名前付きノードに適用することも、すべてのノードにグローバルに適用することもできます。

構成データブロックは、ノードの配列を含む名前付きブロックです。その配列は AllNodes という名前にする必要があります。 AllNodes 配列内では、NodeName 変数を使用してノードのデータを指定します。

前のシナリオを使用して、各ノードにインストールされる Web サーバーで、SiteName プロパティを別の値に設定するものとします。次のように構成データブロックを定義します。

$datablock =
@{
    AllNodes =
    @(
        @{
            NodeName = "WEBSERVER1"
            SiteName = "WEBSERVER1-Site"
        },
        @{
            NodeName = "WEBSERVER2"
            SiteName = "WEBSERVER2-Site"
        },
        @{
            NodeName = "WEBSERVER3"
            SiteName = "WEBSERVER3-Site"
        }
    );
}

プロパティを各ノードで同じ値に設定する場合は、AllNodes 配列内で NodeName = "*" を指定します。

DSC スクリプトのセキュリティで保護された資格情報

DSC スクリプトでは、構成プロセスのために資格情報が必要になる場合があります。資格情報をプレーンテキストでソースコード管理ツールに置くことは避けてください。代わりに、Azure Automation の DSC 構成では、PSCredential オブジェクトに格納されている資格情報を参照できます。 DSC スクリプトのパラメーターを定義するには、PSCredential 型を使用します。スクリプトを実行する前に、ユーザーの資格情報を取得し、その資格情報を使用して新しい PSCredential オブジェクトを作成して、このオブジェクトをパラメーターとしてスクリプトに渡します。

既定では、資格情報は .mof ファイルで暗号化されず、プレーンテキストとして公開されます。資格情報を暗号化するには、構成データで証明書を使用します。証明書の秘密キーは、構成を適用するノード上に存在している必要があります。証明書は、ノードの LCM を使用して構成されます。

PowerShell 5.1 以降では、ノード上の .mof ファイルは保存時に暗号化されます。転送中には、すべての資格情報が WinRM によって暗号化されます。

構成をノードにプッシュする

構成用にコンパイル済みの .mof ファイルを作成した後は、Start-DscConfiguration コマンドレットを実行してそれをノードにプッシュできます。ディレクトリへのパスを追加すると、そのディレクトリで見つかったすべての .mof ファイルがノードに適用されます。

Start-DscConfiguration -path D:\

このステップは、前のユニットで学習した "プッシュモード" に対応します。

ノードの構成をプルする

Azure に数百の VM がある場合は、プッシュモードよりプルモードの方が適しています。

プルサービスとして機能するように Azure Automation アカウントを構成できます。構成を Automation アカウントにアップロードし、このアカウントに VM を登録するだけです。

構成をコンパイルする前に、DSC プロセスで必要なすべての PowerShell モジュールを Automation アカウントにインポートします。これらのモジュールでは、必要な状態を達成するためにタスクを完了する方法が定義されています。

たとえば、前のユニットの DSC スクリプトでは、xSmbShare PowerShell モジュールを使用して、ファイル共有の状態を確認する "方法" が DSC に指示されていました。 DSC によって、モジュールが Automation アカウントからノードに自動的にプルされます。

次の図では、Azure Automation State Configuration の設定方法を示します。これらの手順については、次のユニットで詳しく説明します。

DSC を設定するステップを示す図。

既定では 15 分後に、VM の LCM によって、DSC 構成ファイルに対する変更がないか、Azure Automation がポーリングされます。 VM でのすべての変更が、Desired State Configuration に記録されます。構成を変更する場合は、それを Automation アカウントにアップロードして、VM を自動的に再構成できます。

次の図では、VM 上で必要な状態を管理するための LCM のプロセスを示します。

VM によって Azure Automation がポーリングされる方法を示す図。

Automation アカウントは、資格情報をネイティブに処理します。この管理により、資格情報のセキュリティ保護と操作の複雑さが軽減されます。