tech.guitarrapc.cóm

Technical updates

PowerShell DSC Advent Calendar 2014 : Day 8 ConfigurationData を使ったロールや属性の指定

これは、アドベントカレンダー8日目の記事です。

http://www.adventar.org/calendars/579

7日目は、MOFファイルの生成について説明しました。コンフィグレーションの実行でMOFファイルがコンパイルされる。はい簡単です。

8日目の今日は、コンフィグレーションの実行時に出てきたコンフィグレーションデータ(ConfiguraionData)の利用についてです。

順番に見ていきましょう。

コンフィグレーションデータとは

MSDNにあります。

http://technet.microsoft.com/en-us/library/dn249925.aspx

コンフィグレーションデータを使う目的は、あるべき状態 と 環境データの分離です。

つまり、コンフィグレーションで「あるべき状態」の記述をしたくても、対象のノード名など環境データが混じってしまうと「あるべき状態」の流用が困難になるでしょう。

ではParamで渡すのはどうでしょうか? やはりこれも余り適しません。なぜならCMツールは、役割(ロール)ごとにノード共通のあるべき状態を収束するためのものだからです。つまり、そのロールにはあるべき状態が定まっており、それは静的に定まるでしょう。Paramは動的にコンフィグレーションを実行する時に便利ですが、それは実行時まであるべき状態が定まっていないなら使えますがそうではない。ということです。

たとえば、WebサーバーにインストールするのはIISやASP.NET。DBサーバーならSQLServer。ほら、ロールごとにいれるもの決まってますよね? これが、静的に事前に定まっているということです。

まとめるとこうです。

あるべき状態の記述 環境データの記述
コンフィグレーション コンフィグレーションデータ

具体的に見てみましょう。

コンフィグレーションデータの記述

7日目に示したノードを含むサービスに関するコンフィグレーションを使って「コンフィグレーション(あるべき状態)」と「コンフィグレーションデータ(環境データ)」に分離してみましょう。

元々のコンフィグレーション

https://gist.github.com/d89fbd801be78b907924

まずコンフィグレーションデータです。コンフィグレーションの中から、環境に依存するであろうノード名とサービス名を分離しました。これらをHashtable形式で記述します。*1

コンフィグレーションデータ

https://gist.github.com/d07986082c25e8a895f3

1つのHashtable内で、利用するロールごとに分離できる要素を記述しています。あるべき状態はそのままに、環境に属するデータを分離。これが、コンフィグレーションデータの役割です。

コンフィグレーション でロールや属性を指定する

コンフィグレーションです。ロールベースで指定できるようにしています。

環境データを分離したコンフィグレーション

https://gist.github.com/3d52bab84734149ffba8

先ほどのハッシュテーブルを利用して、ロールからキーを指定して、さらに必要な属性をキーを使って指定します。

そこでParam()ブロックを設けて、Param()を渡してコンフィグレーションデータからロールを選択で切る用にしました。これで、コンフィグレーションデータを渡せば、任意の環境に合わせた構成になります。

コンフィグレーションデータを渡して実行する

Configuraion構文の実行時におけるデフォルトパラメータにあるConfiguraionがそれです。

パラメーター
    -ConfigurationData <hashtable>

        必須                         false
        位置                         2
        パイプライン入力を許可する   false
        パラメーター セット名           (すべて)
        エイリアス                      なし
        動的                     false

コンフィグレーションデータをコンフィグレーションの実行時に渡してみましょう。今回は対象をDSCとするため、-Role-Roleを指定します。

https://gist.github.com/2b1871a54ffe786c6b36

では実行してみましょう。RoleRoleをフィルタした通りに、NodeがRoleになっていることがMOFファイル名からわかりますね。

    Directory: D:\service


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2014/12/09      2:59           1858 127.0.0.1.mof

実行結果のMOFファイルです。サービス名もConfiguraionDataで指定した通りに、ConfiguraionDataConfiguraionDataになっていますね。

https://gist.github.com/62fa66390af54b64a3f5

まとめ

今回はコンフィグレーションデータの基本をお伝えしました。あるべき状態、環境依存のデータ。いろいろな分離方法がありますが、Nodeに関してはコンフィグレーションデータを使うのが定石になっています。

コンフィグレーションデータからしか渡せないパラメータなどもあるため、それは後日説明します。

ちなみに、コンフィグレーションの分離しすぎは無用な混乱をもたらすことがあるのと同様、コンフィグレーションデータもむやみに分離すると柔軟性が失われたり可読性を損なったりします。

そこはあえて、似たようなコンフィグレーションでも許容することも大事です。

*1:産廃がここでも....ほげ...まぁはい。