これは、PowerShell DSC Advent Calendar 2014 - Adventar 13日目の記事です。
時空の歪みが観測でき(略
PUSH 飽きたので(おぅ、PULL にしましょう。というのは冗談ですが、実際PUSHで伝えることは伝えたのでもうありません。次はPULLです。
目次
LCM の切り替え
Local Configuration Manager (LCM)覚えてますか？ 忘れた方は5日目へ (また時空の...。
現在のモードの確認
Get-DscLocalConfigurationManagerをノードで実行した時に表示された、LCM のプロパティにRefreshModeがあります。ここが 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を true にしていますが、ここを falseか省略することで HTTPS必須になります。本来はこっちにすべきです。
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がApplyAndAutoCorrectになっているので、ノード自身の構成がDSCサーバーのあるべき状態と違っていたら自動的にあるべき状態に収束します。
ConfigurationMode = "ApplyAndAutoCorrect"
LCMの構成
LCMの構成を書けたので自分に適用します。Set-DscLocalConfigurationManager Cmdlet でさくっとMOFを適用します。
あとは、Windows Management Infrastructure*1 サービスを再起動してください。めんどくさいなら ノードの再起動でもいいです。なぜか海外の記事では ノードの再起動といっていていつも不思議ですね。
ちなみに、Configurationの実行で生成されるmeta.mofはこんな感じです。
リモートマシンへの適用
これも Get-DscConfigurationやTest-DscConfiguration同様にCimSessionを受け入れるので、リモートマシンには CimSession経由で設定可能です。
ちなみに私はサービス環境では valentiaを使っています。
meta.mof のファイル名とCimSessionで指定したコンピュータ名は一致する必要がある
mofファイル名はlocalhost をNodeブロックに指定して生成したのでlocalhost.meta.mofですね。このmofファイル名とCimSessionで適用する時に指定した名前は一致する必要があるので注意です。
たとえば、localhost.meta.mofを $cimSession = New-CimsSession -ComputerName hoge で生成した $cimSession を利用して Set-DscLocalConfigurationManager -CimSession $cimSession にしてもエラーが出るということです。
どうすればいいのか？というと、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 v4 のDSCには、いくつか致命的なMofの異常状況に陥ることがあり、その際に Mofをリセットする必要に迫られます。
ではどうやるのか？このMofファイルを消すわけです。具体的には、
現在のあるべき状態を消したい時
以下の3つを消します。
- backup.mof
- Current.mof
- Previous.mof
- Pending.mof*2
LCMの状態をSet-DscLocalConfigurationManagerを使わずにリセットしたい時
- MetaConfig.mof
v5 の最新 November Preview ではこの問題が解決されているので、必要となるシーンはほぼありませんが、知っておいても損はないでしょう。
まとめ
PUSH から PULL への変更できましたか？結構大事です。こういう基本はきっちり抑えておきたいところです。
