PowerShell DSCによるプッシュ型展開（中編）：PowerShell DSCで始めるWindowsインフラストラクチャ自動化の基本（1/2 ページ）
Windows OSの設定や構成変更を簡単に、そして確実に行うことができるPowerShell DSC（Desired State Configuration）。今回はDSC Local Configuration Managerの概要とプッシュ型の展開方法について解説する。
前回は、PowerShell DSCの概要について紹介した。中編と後編では、実際にPowerShell DSCで任意のConfigurationをノードに対して展開する方法を具体的に紹介する。今回は、DSC Local Configuration Managerの概要とプッシュ型の展開方法について解説する。プル型の展開方法については、次回の後編で解説する。
使用するシステム環境
PowerShell DSCを使ってノードにConfigurationを適用するには、どのようにDSCの構成を適用するか、どのような構成を適用するのかを決める必要がある。今回は、次のような構成のシステムを使ってDSC構成を実験している。
本記事におけるDSC構成の概要
DSCサーバーに対して、プッシュノード1台とプルノード1台の構成を組んでいる。認証簡便化のため、サーバーとノードのAdministratorユーザーは同じパスワードにしている。
1台の「DSCサーバー（10.0.2.20）」と、2台のノード、「プッシュノード（10.0.2.12）」と「プルノード（10.0.2.11）」を用意している。OSは全てWindows Server 2012 R2である。
DSC Local Configuration Manager
各ノード自身が「どのようにDSC上で動作すればいいのか」に関して責務を負うDSCのエンジンを「DSC Local Configuration Manager」（以下LCM）と呼ぶ。LCMはノード上で稼働する。
LCMにどのような設定があるかを説明する前に、まずは初期設定状態を見てみよう。LCMの設定を取得するには、DSCノードとする対象マシンで次のコマンドレット（Cmdlet）を管理者権限で起動したPowerShell上で実行してほしい。
DSCサーバーとは別に用意したプッシュノード（10.0.2.12）上で直接実行する場合は、以下の1行でいい。
Get-DscLocalConfigurationManager
あるいは対象マシン（10.0.2.12）との間にNew-CimSessionでCIMセッションを生成しておけば、DSCサーバーなどリモートマシンから同コマンドをリモート実行できる。DSC関連のコマンドレットは、基本的にはCIMセッションを使ってリモートマシンへの実行をサポートしているので覚えておいてほしい。
$CimSession = New-CimSession -ComputerName 10.0.2.12
Get-DscLocalConfigurationManager -CimSession $CimSession
DSCサーバーからプッシュノード（10.0.2.12）に実行した結果が次の画面だ。DSCの初期状態は、プッシュ型で動作する設定になっている。まずは、プッシュ型で動作するために必要な設定を説明する。
RefreshMode
RefreshModeプロパティは、そのノードがプッシュ型とプル型のどちらが適用されているかを示している。
前回、「DSCの構成」で紹介した通り、ノードがどうやって構成（実体は.mofファイル）をDSCサーバーから取得するのかには「プッシュ型」と「プル型」の2種類が存在する。各ノードはプッシュ型とプル型のどちらにするのかを選択する必要がある（両方を同時に選ぶことはできない）。
プッシュ型を選択したノードに対して構成を適用するには、DSCサーバーからノードに対して構成情報を送る。そのため、DSCサーバーは構成の適用時にノードが通信可能なのかを確認する必要がある。当然ノードと通信できない場合、構成の適用が失敗する。
一方、プル型を選択したノードは、DSCサーバーからプッシュでの適用は受け付けなくなる。代わりにノード自身が、自身にひも付けられたConfiguration IDをDSCサーバーに問い合わせ、そこに置かれた構成を取得する。
RebootNodeIfNeeded
$trueにすると、適用した あるべき構成（Desired State Configuration） が参照しているDSC Resourceで「再起動を必要とした場合」に許可をする。$falseにすると、再起動は行われず、再起動が必要な旨がVerboseストリームに表示される。
CertificateID
プッシュ型、プル型のいずれにおいても、認証情報をあるべき設定に含んでいた場合、このCertificateIDに指定した証明書を用いて暗号化、復号化を試みる。
また、プル型ではDSCサーバーとプルノードの間でHTTP／HTTPSプロトコルを使ってコネクションを張る（それとは別にSMBプロトコルでやりとりすることもできるが本記事では省略する）。HTTPSでプルノードとDSCサーバーが通信する際、CertificateIDにDSCサーバーとプルノードに配置した証明書のThumbprint（拇印）を指定することで、該当する証明書を利用する。
残りの項目は、プッシュ型では利用されていないため、次回のプル型の解説で説明する。
LCMをプル型に構成してみる
さっそくだが、プル型にするノード（10.0.2.11）のLCMを初期状態のプッシュ型からプル型に変更してみよう。先にノードを構成するが、後ほどプルサーバーの構成も説明する。LCM構成の変更も、DSCを通してConfigurationキーワードを使って行える。次のコードはプル型に変更するConfigurationのサンプルだ。
Configuration DSCPullModeNode
{
param
(
[string]
$guid
)
Node 10.0.2.11
{
LocalConfigurationManager
{
AllowModuleOverwrite = $true
ConfigurationID = $guid
ConfigurationMode = "ApplyAndAutoCorrect"
DownloadManagerName = "WebDownloadManager"
DownloadManagerCustomData = @{
ServerUrl = "http://10.0.2.20:8080/PSDSCPullServer/PSDSCPullServer.svc"
AllowUnsecureConnection = "true"}
RefreshMode = "Pull"
RebootNodeIfNeeded = $true
RefreshFrequencyMins = 15
ConfigurationModeFrequencyMins = 30
}
}
}
次のように実行すると、DSCがLCM設定をCIM経由で設定するためのメタファイル「〜.meta.mof」が、-outputPathに指定した場所（この例では「C:\DSCPullModeNode」フォルダー）にノード名で生成される。
$guid = [guid]::NewGuid()
$outPath = "C:\DSCPullModeNode"
DSCPullModeNode -guid $guid -OutputPath $outPath
プル型に変更するConfigurationで.mofファイルを生成する
DSCPullModeNodeを実行して、-outputpathに指定したC:\DSCPullModeNodeに対象ノード名10.0.2.11のmeta.mofファイルが生成された様子。
次に、Set-DscLocalConfigurationManagerを実行する。このとき、〜.meta.mofの生成されたフォルダー「C:\DSCPullModeNode」を指定することで、「10.0.2.11.meta.mof」ファイルの名前になっている対象ノード（10.0.2.11）にプル構成が適用される。実行時に-Verboseスイッチを付けておけば、適用までの流れが可視化されて分かりやすいだろう。
Set-DscLocalConfigurationManager -Path $outPath -Verbose
プル型へのLCM構成を適用した後は、Get-DscLocalConfigurationManagerを使って変更後のLCM状態を確認してみよう。
$CimSession = New-CimSession -ComputerName 10.0.2.11
Get-DscLocalConfigurationManager -CimSession $CimSession
DSCサーバーから、LCMをプルノードに変更した10.0.2.11へ同コマンドを実行した結果が次の画面だ。RefreshModeプロパティを見ると、初期状態のプッシュ型からプル型に変更されていることが分かる。
プル型で動作させるための設定
プル型で動作させるために必要な設定は次の通りである。
AllowModuleOverwrite
$trueを与えると、DSCサーバーに「より新しいバージョンのモジュールが存在する」場合、ノードはそれを取得して手元のモジュールを上書きする。
プル型ではDSCサーバーからConfigurationで利用しているリソースをダウンロードできる。プッシュ型では自分でプッシュノードに配置しなくてはいけないが、プル型ではその必要がない。DSCサーバー上のモジュールパスに最新のリソースを配置すると、プルノードは現在保持しているバージョンより新しいリソースがあれば、プルサーバーから最新版を取得して置き換える。
ConfigurationID
このプロパティはGUID形式で指定する。プル型では、ノードがサーバーに問い合わせて構成（.mofファイル）を取得すると述べた。プルノードが「自分が参照するべき構成」を問い合わせる時に利用するのが、LCMに設定されたConfigurationIDだ。
プルノードはDSCサーバーに対してLCMに設定されたConfigurationIDで問い合わせリクエストを送る。DSCサーバーは、同名の.mofがDSCサーバーに存在していれば、その構成を回答する。
ConfigurationID
ConfigurationIDは、DSCサーバーでプルノードを識別するのに用いられる。
（1）プルノードは、LCMに設定されたConfigurationID（この例では「e8161096-dbcb-4e53-93a3-761bf51f43b0」）でDSCサーバーに.mofファイルをリクエストする。
（2）DSCサーバーは同名の.mofファイルがあれば、それをプルノードにダウンロードさせる。
ConfigurationMode
ConfigurationModeプロパティには、タイプが3つある。
- Apply
- ApplyAndMonitor
- ApplyAndAutoCorrect
プル型ではプッシュ型と異なり、一度適用された後も継続して構成を維持することができる。これは、プルノードがLCMにスケジュールされた間隔でサーバーに問い合わせ、ConfigurationIDで指定された.mofファイルを取得してLCMにキャッシュし、現在の構成と差異がないか確認しているからだ。
「Apply」を与えると、一度だけ構成を適用する。その結果が成功だった場合は、以降DSCサーバーに対して構成の確認や適用を行わない。
「ApplyAndMonitor」は、構成を適用した後もノードの構成がDSCサーバーで指定した あるべき構成 と差異がないか継続して確認する。しかし、ノードに「構成とのずれ（Configuration Drift）」が存在していたとしても修正を行わない。
「ApplyAndAutoCorrect」は、構成を適用してからも定期的にDSCサーバーへ問い合わせて確認する。もしConfiguration Driftが見つかった場合、自動的に あるべき構成 を適用する。
ConfigurationModeで指定できる3種類の動作モード
ConfigurationModeには、プル型の3種類の動作モード「Apply」「ApplyAndMonitor」「ApplyAndAutoCorrect」のいずれかを指定できる。
ConfigurationModeFrequencyMins
このプロパティは、何分間隔でConfiguraionModeが実行されるかを定義する。「現在の構成」が「LCMにキャッシュされたあるべき構成」とずれていないか確認する頻度である。最も小さい値は30（分）である。
ConfigurationModeFrequencyMinsの値は、後述するRefreshFrequencyMinsの倍数である必要がある。もし異なる数値を指定した場合は、自動的にRefreshFrequencyMinsに対して2倍の値になる。
ConfigurationModeFrequencyMinsパラメーター
ConfigurationModeFrequencyMinsで指定した間隔（分）で、プルノードは現在の構成がLCMにキャッシュされた あるべき構成 とずれていないか確認する。
Credential
リモートソースにアクセスするときの認証情報をセットする。
DownloadManagerName
プル型において、プルサーバーとのダウンロードに使う方式を定義する。DSCには、2つのダウンロード方法がある。
- DSCFileDownloadManager
- WebDownloadManager
「DSCFileDownloadManager」を指定した場合、DSCサーバーとプルノードはSMBファイル共有プロトコルを利用して構成のやりとりを行う。これはファイルサーバーと同様の通信プロトコルなので、イントラネットにおいてはHTTP／HTTPSプロトコルを用いるWebDownloadManagerよりもシンプルな構成にできることが多いだろう。
一方「WebDownloadManager」を指定すると、HTTP（あるいはHTTPS）プロトコルを利用する。イントラネット外部とのやり取りにおいては、HTTP／HTTPSはSMBに比べて格段にファイアウォールに左右されにくい。また、WebDdownloadManagerでのみコンプライアンスサーバー（Compliance Server）がサポートされており、プルノードの構成状況が把握できるというメリットも大きい。
そのため本記事ではWebDownloadManagerに重点を置いて説明する。
DownloadManagerCustomData
DownloadManagerに渡す値をハッシュテーブルで定義する。WebDownloadManagerでは次の2つが設定可能だ。
- ServerUrl
- AllowUnsecureConnection
「ServerUrl」は、プルサーバーのoDataエンドポイントのURLだ。
「AllowUnsecureConnection」は、プルサーバーとノード間の通信方法を選択する。$trueを渡すとHTTPになり、$falseを渡すとHTTPSになる。
WebDownloadManagerの動作モード
WebDownloadManagerにおける、DownloadManagerCustomDataによる通信方式の違い。AllowUnsecureConnectionの値によって、HTTPとHTTPSを切り替える。
DSCFileDownloadManagerの場合は、SourcePathにノードとのやりとりに用いるプルサーバーの共有フォルダー名（例：「\\DSCPullServer\PullShare」）を指定する。
RefreshFrequencyMins
このプロパティには、「プルサーバー上のあるべき構成」と「LCMがキャシュしたあるべき構成」の値がずれていないか確認する頻度を指定する。最も小さい値は15（分）だ。もし、プルサーバーとLCMでずれがあった場合は、プルサーバーから新しい構成を取得する。
LCMに関する全プロパティと構成の取得、設定方法は以上だ。
PowerShell DSCにおける構成の概要
LCMを通してDSCの あるべき構成 がどのようにDSCサーバーとノード間でやり取りされるか、以下にまとめておく。
- DSCサーバーでは、 あるべき構成 が configurationから.mofファイルへ変換、生成、配置される。
- ノードでは、RefreshMode で定義されたプッシュ型／プル型のタイプによって、サーバーで作成された.mofファイルの取得方法が変わる。プル型の場合は、DownloadManagerによって、取得時のプロトコル（HTTP／HTTPSあるいはSMB）やサーバーのエンドポイントを指定する。
- ノードは、取得した あるべき構成 をLCMにキャッシュする。
- LCMにキャッシュされた構成が、現在のノードの構成とずれていないか確認し、プッシュ型の場合は差異があったら構成を適用して完了。
- プル型の場合はプッシュ型の場合と同様に構成を適用するが、ConfigurationModeに従い、継続して監視、適用するかどうかが決まる。RefreshFrequencyMinsやConfigurationModeFrequencyMinsに設定された確認頻度、適用頻度で あるべき状態 を維持しようとする。
Copyright© Digital Advantage Corp. All Rights Reserved.