構文自体の説明は行っていたんですねー。丁寧に書いているので同じ内容に書くのは無駄な感じがします。そこで、今回はもう少し実践的な話をしましょう。事前にBuildInsiderの記事にかかれているコンフィグレーション構文の基礎を知っている前提となります。コンフィグレーションを書くのはインテリセンスやタブ補完が弱く「使いにくい」のが現実です。インテリセンスもタブ補完もばっちり効き大幅に改善されたことが実感できます。利用可能なリソースだけインテリセンスに表示されます。Spaceを押すと利用可能な定義が表示されます。一々定義を抽出する?人間のやることではありません。までは、キーワードはタブ補完されても、インテリセンスが効きませんでした。インテリセンスが効きます!やった!リソースのキーワードが利用可能な値のタブ補完リソースのキーワードによっては、利用できる値が決まっていることがあります。v4まではコンフィグレーションを実行してコンパイルするまでエラーが検出できませんでしたが、v5ではタブ補完が効きます。*1ここでTabキーを押せば自動補完されます。標準で使えるリソースから、2つコンフィグレーションのサンプルを紹介しましょう。「エラーなどで突然にWindowsサービスが停止!」は、当然ありえる話なのでサービスの起動保証がほしい思ったことは誰でもあるでしょう。DSCを使えば簡単にできます。挙動の中心を支えるサービスです。このサービスの起動を保証するコンフィグレーションは次のように書けます。?これだけシンプルなら、誰が見ても何をしたいのかおおよそ予測がつくのではないでしょうか。Instrumentationサービスが例えエラーを起こしても起動している状態を保証できるのです。エラーからの自動的な状態復旧が満たされるのです。DSCを使わない手はありません。使えば、ユーザーなんてサーバーで共通で持てる?いいえ、ADは状況によっては使う選択肢から外す必要があります。スケーラブルな環境がその一例です。Infrastructure)、いつでも破棄可能(Disposable)なサーバーを構築する場合、とても重たい存在です。いつでもサーバーを捨てる、再構築するということは、なるべく状態を持たないよう(Stateless)にしないといけません。関わらず、ADに参加したコンピュータはディレクトリサービスという状態を持ちます(State-full)。ステートレスにしたい環境でステートフルを強いる(しかも容易に代替可能な機能のためだけに!)を使うのはナンセンスです。使うと、ADなんて参加せずともローカルコンピュータでユーザーとグループの状態が保証できます。リモート用にユーザーとグループを作るならこうかけます。渡すことで、ユーザー名とパスワードを外から渡すことができます。再利用すら可能なのです。ベストプラクティスです。依存関係を保証します。一見すると、上から順番に適用されいるように解釈してしまいそうですが、依存しているコンフィグレーションが実行されてから、依存するコンフィグレーションが実行される保証はありません。使って適用順序を厳密に定めてください。次のように記述します。インテリセンスがばっちり聞いてタブで自動補完されるので大変はかどります。"[リソース名1]コンフィグレーション名1"}コンフィグレーション内でのPowerShell構文利用ここまでのサンプルでは、冗長なコンフィグレーション記述をしていました。PowerShellのキーワードにすぎません。Configuraion構文内部でもPowerShellの通常構文は使えるのです。いえ、あまり使いすぎると読みにくくなります。宣言型構文を使っているのに、可読性が落ちるのは意味がないので可読性は優先する必要があります。排除からバランスを考えると、使っても以下の3つ程度に抑えるべきでしょう。静的なprivate変数foreachなどループ構文の利用Cmdletでの外部リソースの利用サービスに関するコンフィグレーションは、PowerShell構文を使うことでこのように書けます。保証を担保したいサービスが増えれば増えるほど、ループで回したくなりますよね。著しく可読性を損なわない限り、冗長な記述をPowershell構文を使ってシンプルにするのはありだと思います。使わないのはありえない。*4スクリプトリソースを使ったコンフィグレーション記述のポイントスクリプトリソースは、なんでもできます。書けばいいのか、何が問題なのかは知られていないように思います。そこでまず、スクリプトリソース利用時の基本構文について典型をお伝えしましょう。必須なのは、SetScript、TestScript、GetScriptです。GetScriptセクションでは、SetScript、TestScript、GetScript、Resultを定義します。無効するにはこう書きます。TestScript対象ノードの状態をテストするロジックを書きます。返却値は[bool]である必要があります。SetScript対象ノードの状態を設定するロジックを書きます。false、つまりあるべき状態でなかった場合にのみ実行されます。ノードの状態を取得する時に必要になります。これは典型パターンです。これは典型パターンです。これは典型パターンです。Resultには、TestScriptで設定したのと同じロジックを入れます。典型が多いのはいいのですが、冗長この上ないですね。必要悪とはこのことなのか....スクリプトリソースの問題点スクリプトリソースの利用には、たくさん問題があります。型の明示MOFの可読性低下ロジックをコンフィグレーションに直接定義これは、リソースコンセプトの破壊につながりかねないことです。するのか?再利用する場合は、リソースにするのです。コンフィグレーションをリソースにして再利用する方法や、リソースを自分で定義してもいいでしょう。*5ただ、その場限りで再利用もなく、シンプルな場合は許容できると思います。スクリプトリソースを使ってコンフィグレーションを書きたくなったら、再利用する場合はリソースにしましょう変数の参照は$using:スコープConfiguration構文内部でも、PowerShell構文は使えることを説明しました。変数が一番使いやすいでしょう。変数を参照する時は注意が必要です。スクリプトリソースの実態は、リモートで利用することが前提のスクリプトブロックです。この場合、ローカルとはコンフィグレーションを実行するDSCサーバー、リモートとはMOFを読み込むノードです。PowerShellのルールです。スコープは不要ですよ?例えば、先ほどのスクリプトリソースでローカル変数を、コンフィグレーションで参照する場合はこう書きます。ポジショナルパラメータの利用これはリモートスクリプトブロックの制限ですが、ポジショナルパラメータの利用はできません。先ほどの例なら、これはダメということです。パラメータを明示する必要があります。型は明示してください。暗黙の型変換はダメです。[String]を受け取るパラメータには、.ToString()や""で明示的にキャストが必要です。型をあいまいにするなんて避けますよねーふつー(棒)MOFの可読性低下コンフィグレーションを実行した時にMOFファイルがコンパイル生成されます。MOFを読む機会は余りありませんが、ある時はあるのです。読みにくくて仕方ありませんね。コンフィグレーションを1つだけ持てます。コンフィグレーション1つに全部の定義を書かないといけないのかというとそうではありません。ネスト(組み合わせ)が可能です。コンフィグレーション構文の中で、Nodeセクションは一回しか書けません。デフォルトで入ります。Nodeセクションを書きます。簡単ですね!ネスト対象の子コンフィグレーションにもパラメータが渡せます。