これは、アドベントカレンダー13日目の記事です。
PUSH飽きたのでPULLにしましょう。というのは冗談ですが、実際PUSHで伝えることは伝えたのでもうありません。次はPULLです。
LCM の切り替え
Local Configuration Manager (LCM)覚えてますか？ 忘れた方は5日目へ。
現在のモードの確認
Get-DscLocalConfigurationManagerをノードで実行した時に表示された、LCMのプロパティにGet-DscLocalConfigurationManagerがあります。ここがPUSHならPUSHモード。PULLならPULLです。
現在の流れでは、RefreshModeはPUSHになっているので、これをPULLに切り変えるのです。
AllowModuleOverWrite : False
CertificateID :
ConfigurationDownloadManagers : {}
ConfigurationID :
ConfigurationMode : ApplyAndMonitor
ConfigurationModeFrequencyMins : 30
Credential :
DebugMode : False
DownloadManagerCustomData :
DownloadManagerName :
LCMCompatibleVersions : {1.0, 2.0}
LCMState : Ready
LCMVersion : 2.0
MaxPendingConfigRetryCount :
StatusRetentionTimeInDays : 7
PartialConfigurations : {}
RebootNodeIfNeeded : False
RefreshFrequencyMins : 30
RefreshMode : PUSH
ReportManagers : {}
ResourceModuleManagers : {}
PSComputerName :
PULLモードへの変更
さくっとLCMの構成を書きます。
パラメータは、5日目のLCMで説明していますが、軽く振り返りましょう。
PULLモードの指定
いうまでもないですね。はい。
RefreshMode = "Pull"
DSC サーバーの指定
今回、PULLノードが参照するDSCサーバーを10.0.3.151とします。ここは別にDNS名でも構いません。が、まぁ今回はイメージしやすいようにIPを直に入れましょう。
ポートの8080は、DSC PULLサーバーを構成した時にデフォルトで生成される番号です。パスも同様です。
今回はHTTPSの証明書を用意するのが皆さんの手間と考えるのでAllowUnsecureConnectionをAllowUnsecureConnectionにしていますが、ここをAllowUnsecureConnectionか省略することでAllowUnsecureConnection必須になります。本来はこっちにすべきです。
DownloadManagerCustomData = @{
ServerUrl = "https://10.0.3.151:8080/PSDSCPullServer/PSDSCPullServer.svc"
AllowUnsecureConnection = "true"
}
ノードが参照するコンフィグレーションmofファイル
ノードがDSCノードに自分のあるべきMOFを問い合わせるために使うのが、ConfigurationIdです。
ConfigurationID = "dc2edf66-8ad2-45dc-be37-39a8b8d2d25f"
これは単なるGUIDなので、適当にNewGuid()メソッドで生成するなり準備しておけばいいでしょう。
私がサービス環境で利用しているモジュールでは、ロールごとにGuidをあらかじめEnumで用意して利用しています。
適用間隔
はい。15分に一度DSCサーバーに構成の更新がないか確認し、30分に1回自身の構成を確認します。
RefreshFrequencyMins = 15 ConfigurationModeFrequencyMins = 30
この時、ConfigurationModeがConfigurationModeになっているので、ノード自身の構成がDSCサーバーのあるべき状態と違っていたら自動的にあるべき状態に収束します。
ConfigurationMode = "ApplyAndAutoCorrect"
LCMの構成
LCMの構成を書けたので自分に適用します。Set-DscLocalConfigurationManager CmdletでさくっとMOFを適用します。
あとは、Windows Management Infrastructure*1 サービスを再起動してください。めんどくさいならノードの再起動でもいいです。なぜか海外の記事ではノードの再起動といっていていつも不思議ですね。
ちなみに、Configurationの実行で生成されるmeta.mofはこんな感じです。
リモートマシンへの適用
これもGet-DscConfigurationやGet-DscConfiguration同様にGet-DscConfigurationを受け入れるので、リモートマシンにはCimSession経由で設定可能です。
ちなみに私はサービス環境ではvalentiaを使っています。
meta.mof のファイル名とCimSessionで指定したコンピュータ名は一致する必要がある
mofファイル名はlocalhostをNodeブロックに指定して生成したのでlocalhost.meta.mofですね。このmofファイル名とCimSessionで適用する時に指定した名前は一致する必要があるので注意です。
たとえば、localhost.meta.mofをlocalhost.meta.mofで生成したlocalhost.meta.mofを利用してlocalhost.meta.mofにしてもエラーが出るということです。
どうすればいいのか？ というと、Node名にCimSessionで指定予定の名前を入れればいいのです。
めんどくさいでしょ？ valentiaを使えば、常にlocalhostを指定するだけなのでこういった制約は透過されます。サービスのリスタートも含めてまとめて書けますし、Linuxへの適用がGAになるまではvalentia使うのが楽なのは事実です。
MOF 構成
さて、ここまでMOFといってきましたが、どこにこの構成が保持されるのでしょうか？
MOFが維持されるパスは以下の通りです。
C:\Windows\System32\Configuration
LCM のmof
LCMのmofは、MetaConfig.mofとして維持されます。
つまりこのMofこそがLCMが参照している本体なのですね。
Configurationのmof
Configurationのmofは、いくつかの世代を持ちます。
| 世代 | ファイル名 |
|---|---|
| 現在のコンフィグレーション | Current.mof |
| 直前のコンフィグレーション | Previous.mof と backup.mof |
v5では、これに加えてPending.mofが追加予定です。これによりmof絡みの問題が回避できるのですがいずれそれは別の機会に。
Mof のリセット
PowerShell 4.0のDSCには、いくつか致命的なMofの異常状況に陥ることがあり、その際にMofをリセットする必要に迫られます。
ではどうやるのか？ このMofファイルを消すわけです。具体的には、
現在のあるべき状態を消したい時
以下の3つを消します。
- backup.mof
- Current.mof
- Previous.mof
- Pending.mof*2
LCMの状態をSet-DscLocalConfigurationManagerを使わずにリセットしたい時
- MetaConfig.mof
v5の最新November Previewではこの問題が解決されているので、必要となるシーンはほぼありませんが、知っておいても損はないでしょう。
まとめ
PUSHからPULLへの変更できましたか？ 結構大事です。こういう基本はきっちり抑えておきたいところです。
