これは、PowerShell DSC Advent Calendar 2014 - Adventar 12日目の記事です。
時空の歪みが観測できてます？
今日は対象ノードをあるべき状態に収束させたことを確認してみましょう。
目次
ノードに適用されたコンフィグレーションを確認する
まずは、ノード自身がどんなコンフィグレーションを適用されたのか確認してみましょう。
Get-DscConfiguration
PowerShell DSC には、現在ノードに適用されたコンフィグレーションに対して、ノードが現在どういう状態なのか確認するための専用 Cmdlet があります。
コンフィグレーションを適用したノード上で実行してみた結果です。
現在のノードの状態が取得できました。
ではサービスを停止してみると？
適用したコンフィグレーションについて、サービスが停止した現在のノード状態が取得できていますね。
こうして、コンフィグレーションの適用状態を取得するために使うのが、Get-DscConfiguration Cmdletです。
リモートノードの確認
CimSessionの利用
このCmdletには-CimSessionパラメータがあるので、対象ノードへの CimSession を生成しておけばリモート上のノードに対して実行することもできます。
valentiaの利用
しかし、リモートに向けて一々cimSession をラップするのはあれなので valentiaを使うと認証周りも含めてローカルで実行しているのと同様に扱えます。
実際運用している実環境では、valentia がデフォルトで入っているため valentia で各種 DSC Cmdlet をラップしたモジュールを使っています。
CIMではなくvalentia 経由の実行にすることで、「認証周り」や「非同期処理」を意識することなくローカルでの実行をスクリプトブロック{}で括るだけでまったく同じ挙動をするようにしています。Linux 向けの DSC がGAされるまではCIMの真価は薄いため、コストがかからず高速に動作するため重宝しています。
ノードがあるべき状態か確認する
ノードの現在のコンフィグレーションが取得できることはわかりました。しかし状態を一々確認するのはだるいため、現在ノードがコンフィグレーションで指示した状態なのかどうか boolean で端的に欲しくなります。
| 返戻値 | 状態 |
|---|---|
$true |
現在あるべき状態である |
$false |
現在あるべき状態でない |
このために利用するのが、Test-DscConfiguration Cmdlet です。
早速実行してみましょう。
コンフィグレーション実行直後に実行すると結果は、trueです。
サービスを片方停止させるとfalse にかわりました。
どうでしょうか？わかりやすいですね。
リモートノードへの実行
Get-DscConfiguraitionと同じで CimSessionが使えます。
しかし本番環境では、valentia でラップしてより使いやすくしています。標準より数倍楽なのでいいですね。
問題点
さて、Test-DscConfiguration ですが、問題点があります。
- 複数ノードに実行した時にどのノードがtrue/falseかわからない
- falseの時にどのコンフィグレーションが問題なのかわからない
対策を見てみましょう。
複数ノードに実行した時にどのノードがtrue/falseかわからない
私は現状valentia を使っているのでこの問題は自然と解決しています。valentia では、対象ノードごとの状態を示してくれるためです。
通常利用している人にとっては、厄介ですね。結果をforeachでまわして加工するのが妥当でしょうか？
DSC側での改善が待たれる機能となっています。
falseの時にどのコンフィグレーションが問題なのかわからない
最も厄介なのはこれです。
対策は単純で、2つあります。
- テストを書く
- 2本木探索
テストを書く
ツールとしては、serverspec や pester があります。現状 DSC を利用する仲間の間では Pesterが主流です。
現状、私も Pester を使っています。通常の PowerShell スクリプトに書くテストと同様にサーバー状態をテストできるので重宝します。
二本木探索
複数のコンフィグレーションに分岐している時に有効です。
この場合、コンフィグレーションをリマークしつつ探索すればくぎれるためです。が、初めからテストを書いていればいい話なので手法の問題であるのも事実です。
さくっと調べるならいいでしょう。
まとめ
テスト大事。完結させるので待っててね？
