PowerShell DSC を使用して必要な状態を実現する
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 の設定方法を示します。 これらの手順については、次のユニットで詳しく説明します。
既定では 15 分後に、VM の LCM によって、DSC 構成ファイルに対する変更がないか、Azure Automation がポーリングされます。 VM でのすべての変更が、Desired State Configuration に記録されます。 構成を変更する場合は、それを Automation アカウントにアップロードして、VM を自動的に再構成できます。
次の図では、VM 上で必要な状態を管理するための LCM のプロセスを示します。
Automation アカウントは、資格情報をネイティブに処理します。 この管理により、資格情報のセキュリティ保護と操作の複雑さが軽減されます。