Configuration)。Managerの概要とプッシュ型の展開方法について解説する。DSCの概要について紹介した。DSCで任意のConfigurationをノードに対して展開する方法を具体的に紹介する。Managerの概要とプッシュ型の展開方法について解説する。プル型の展開方法については、次回の後編で解説する。DSCを使ってノードにConfigurationを適用するには、どのようにDSCの構成を適用するか、どのような構成を適用するのかを決める必要がある。今回は、次のような構成のシステムを使ってDSC構成を実験している。本記事におけるDSC構成の概要DSCサーバーに対して、プッシュノード1台とプルノード1台の構成を組んでいる。認証簡便化のため、サーバーとノードのAdministratorユーザーは同じパスワードにしている。1台の「DSCサーバー(10.0.2.20)」と、2台のノード、「プッシュノード(10.0.2.12)」と「プルノード(10.0.2.11)」を用意している。Manager」(以下LCM)と呼ぶ。LCMはノード上で稼働する。LCMにどのような設定があるかを説明する前に、まずは初期設定状態を見てみよう。LCMの設定を取得するには、DSCノードとする対象マシンで次のコマンドレット(Cmdlet)を管理者権限で起動したPowerShell上で実行してほしい。DSCサーバーとは別に用意したプッシュノード(10.0.2.12)上で直接実行する場合は、以下の1行でいい。Get-DscLocalConfigurationManagerあるいは対象マシン(10.0.2.12)との間にNew-CimSessionでCIMセッションを生成しておけば、DSCサーバーなどリモートマシンから同コマンドをリモート実行できる。DSC関連のコマンドレットは、基本的にはCIMセッションを使ってリモートマシンへの実行をサポートしているので覚えておいてほしい。$CimSessionDSCサーバーからプッシュノード(10.0.2.12)に実行した結果が次の画面だ。DSCの初期状態は、プッシュ型で動作する設定になっている。プッシュ型で動作するために必要な設定を説明する。R2では、「RefreshMode」が「PUSH」となっている。RefreshModeRefreshModeプロパティは、そのノードがプッシュ型とプル型のどちらが適用されているかを示している。前回、「DSCの構成」で紹介した通り、ノードがどうやって構成(実体は.mofファイル)をDSCサーバーから取得するのかには「プッシュ型」と「プル型」の2種類が存在する。各ノードはプッシュ型とプル型のどちらにするのかを選択する必要がある(両方を同時に選ぶことはできない)。プッシュ型を選択したノードに対して構成を適用するには、DSCサーバーからノードに対して構成情報を送る。そのため、DSCサーバーは構成の適用時にノードが通信可能なのかを確認する必要がある。ノードと通信できない場合、構成の適用が失敗する。プル型を選択したノードは、DSCサーバーからプッシュでの適用は受け付けなくなる。IDをDSCサーバーに問い合わせ、そこに置かれた構成を取得する。Resourceで「再起動を必要とした場合」に許可をする。$falseにすると、再起動は行われず、再起動が必要な旨がVerboseストリームに表示される。CertificateIDプッシュ型、プル型のいずれにおいても、認証情報をあるべき設定に含んでいた場合、このCertificateIDに指定した証明書を用いて暗号化、復号化を試みる。プル型ではDSCサーバーとプルノードの間でHTTP/HTTPSプロトコルを使ってコネクションを張る(それとは別にSMBプロトコルでやりとりすることもできるが本記事では省略する)。HTTPSでプルノードとDSCサーバーが通信する際、CertificateIDにDSCサーバーとプルノードに配置した証明書のThumbprint(拇印)を指定することで、該当する証明書を利用する。残りの項目は、プッシュ型では利用されていないため、次回のプル型の解説で説明する。LCMをプル型に構成してみるさっそくだが、プル型にするノード(10.0.2.11)のLCMを初期状態のプッシュ型からプル型に変更してみよう。先にノードを構成するが、後ほどプルサーバーの構成も説明する。LCM構成の変更も、DSCを通してConfigurationキーワードを使って行える。次のコードはプル型に変更するConfigurationのサンプルだ。30}}}次のように実行すると、DSCがLCM設定をCIM経由で設定するためのメタファイル「〜.meta.mof」が、-outputPathに指定した場所(この例では「C:\DSCPullModeNode」フォルダー)にノード名で生成される。$outPathプル型に変更するConfigurationで.mofファイルを生成するDSCPullModeNodeを実行して、-outputpathに指定したC:\DSCPullModeNodeに対象ノード名10.0.2.11のmeta.mofファイルが生成された様子。次に、Set-DscLocalConfigurationManagerを実行する。このとき、〜.meta.mofの生成されたフォルダー「C:\DSCPullModeNode」を指定することで、「10.0.2.11.meta.mof」ファイルの名前になっている対象ノード(10.0.2.11)にプル構成が適用される。実行時に-Verboseスイッチを付けておけば、適用までの流れが可視化されて分かりやすいだろう。-Verboseプル構成がノードに適用されている様子Set-DscLocalConfigurationManagerを使って、対象ノード10.0.2.11へプル型構成を適用している様子。プル型へのLCM構成を適用した後は、Get-DscLocalConfigurationManagerを使って変更後のLCM状態を確認してみよう。$CimSessionDSCサーバーから、LCMをプルノードに変更した10.0.2.11へ同コマンドを実行した結果が次の画面だ。RefreshModeプロパティを見ると、初期状態のプッシュ型からプル型に変更されていることが分かる。LCM設定状態を確認するRefreshModeが「Pull」となっている。プル型で動作させるための設定プル型で動作させるために必要な設定は次の通りである。AllowModuleOverwrite$trueを与えると、DSCサーバーに「より新しいバージョンのモジュールが存在する」場合、ノードはそれを取得して手元のモジュールを上書きする。プル型ではDSCサーバーからConfigurationで利用しているリソースをダウンロードできる。プッシュ型では自分でプッシュノードに配置しなくてはいけないが、プル型ではその必要がない。DSCサーバー上のモジュールパスに最新のリソースを配置すると、プルノードは現在保持しているバージョンより新しいリソースがあれば、プルサーバーから最新版を取得して置き換える。ConfigurationIDこのプロパティはGUID形式で指定する。プル型では、ノードがサーバーに問い合わせて構成(.mofファイル)を取得すると述べた。プルノードが「自分が参照するべき構成」を問い合わせる時に利用するのが、LCMに設定されたConfigurationIDだ。プルノードはDSCサーバーに対してLCMに設定されたConfigurationIDで問い合わせリクエストを送る。DSCサーバーは、同名の.mofがDSCサーバーに存在していれば、その構成を回答する。ConfigurationIDConfigurationIDは、DSCサーバーでプルノードを識別するのに用いられる。(1)プルノードは、LCMに設定されたConfigurationID(この例では「e8161096-dbcb-4e53-93a3-761bf51f43b0」)でDSCサーバーに.mofファイルをリクエストする。(2)DSCサーバーは同名の.mofファイルがあれば、それをプルノードにダウンロードさせる。ConfigurationModeConfigurationModeプロパティには、タイプが3つある。ApplyApplyAndMonitorApplyAndAutoCorrectプル型ではプッシュ型と異なり、一度適用された後も継続して構成を維持することができる。これは、プルノードがLCMにスケジュールされた間隔でサーバーに問い合わせ、ConfigurationIDで指定された.mofファイルを取得してLCMにキャッシュし、現在の構成と差異がないか確認しているからだ。「Apply」を与えると、一度だけ構成を適用する。その結果が成功だった場合は、以降DSCサーバーに対して構成の確認や適用を行わない。差異がないか継続して確認する。Drift)」が存在していたとしても修正を行わない。「ApplyAndAutoCorrect」は、構成を適用してからも定期的にDSCサーバーへ問い合わせて確認する。ConfigurationModeで指定できる3種類の動作モードConfigurationModeには、プル型の3種類の動作モード「Apply」「ApplyAndMonitor」「ApplyAndAutoCorrect」のいずれかを指定できる。ConfigurationModeFrequencyMinsこのプロパティは、何分間隔でConfiguraionModeが実行されるかを定義する。「現在の構成」が「LCMにキャッシュされたあるべき構成」とずれていないか確認する頻度である。小さい値は30(分)である。ConfigurationModeFrequencyMinsの値は、後述するRefreshFrequencyMinsの倍数である必要がある。異なる数値を指定した場合は、自動的にRefreshFrequencyMinsに対して2倍の値になる。ずれていないか確認する。Credentialリモートソースにアクセスするときの認証情報をセットする。DownloadManagerNameプル型において、プルサーバーとのダウンロードに使う方式を定義する。DSCには、2つのダウンロード方法がある。DSCFileDownloadManagerWebDownloadManager「DSCFileDownloadManager」を指定した場合、DSCサーバーとプルノードはSMBファイル共有プロトコルを利用して構成のやりとりを行う。これはファイルサーバーと同様の通信プロトコルなので、イントラネットにおいてはHTTP/HTTPSプロトコルを用いるWebDownloadManagerよりもシンプルな構成にできることが多いだろう。「WebDownloadManager」を指定すると、HTTP(あるいはHTTPS)プロトコルを利用する。イントラネット外部とのやり取りにおいては、HTTP/HTTPSはSMBに比べて格段にファイアウォールに左右されにくい。Server)がサポートされており、プルノードの構成状況が把握できるというメリットも大きい。そのため本記事ではWebDownloadManagerに重点を置いて説明する。DownloadManagerCustomDataDownloadManagerに渡す値をハッシュテーブルで定義する。WebDownloadManagerでは次の2つが設定可能だ。ServerUrlAllowUnsecureConnection「ServerUrl」は、プルサーバーのoDataエンドポイントのURLだ。「AllowUnsecureConnection」は、プルサーバーとノード間の通信方法を選択する。$trueを渡すとHTTPになり、$falseを渡すとHTTPSになる。WebDownloadManagerの動作モードWebDownloadManagerにおける、DownloadManagerCustomDataによる通信方式の違い。AllowUnsecureConnectionの値によって、HTTPとHTTPSを切り替える。DSCFileDownloadManagerの場合は、SourcePathにノードとのやりとりに用いるプルサーバーの共有フォルダー名(例:「\\DSCPullServer\PullShare」)を指定する。DSCFileDownloadManagerの動作DSCFileDownloadManagerとの通信はSMBプロトコルで行われる。RefreshFrequencyMinsこのプロパティには、「プルサーバー上のあるべき構成」と「LCMがキャシュしたあるべき構成」の値がずれていないか確認する頻度を指定する。小さい値は15(分)だ。プルサーバーとLCMでずれがあった場合は、プルサーバーから新しい構成を取得する。ずれていないか確認する。LCMに関する全プロパティと構成の取得、設定方法は以上だ。どのようにDSCサーバーとノード間でやり取りされるか、以下にまとめておく。configurationから.mofファイルへ変換、生成、配置される。定義されたプッシュ型/プル型のタイプによって、サーバーで作成された.mofファイルの取得方法が変わる。プル型の場合は、DownloadManagerによって、取得時のプロトコル(HTTP/HTTPSあるいはSMB)やサーバーのエンドポイントを指定する。LCMにキャッシュする。LCMにキャッシュされた構成が、現在のノードの構成とずれていないか確認し、プッシュ型の場合は差異があったら構成を適用して完了。プル型の場合はプッシュ型の場合と同様に構成を適用するが、ConfigurationModeに従い、継続して監視、適用するかどうかが決まる。