PowerShell Desired State Configuration（DSC）とは（前編）：PowerShell DSCで始めるWindowsインフラストラクチャ自動化の基本（1/2 ページ）
Windows OSの設定や構成を変更する場合、GUIの管理ツールを使うのが一般的である。だが台数が多かったり、構成変更や以前の構成への復旧などが頻繁だったりするとGUIでは非常に面倒だし、間違いもしやすくなる。こんな場合はPowerShell DSCを使ってインフラ構築作業を自動化するとよい。
標準でGUI管理ツールを備えているWindows Serverでは、さまざまな設定・構築作業をGUIを通して手軽に実行できる。その半面、手動作業が必要なため、設定・構築に時間がかかったり設定を元に戻すのに手間が掛かったり、さらには複数のサーバーを同一の構成にそろえるのに苦労したりしがちだ。
このようなサーバーの構成管理やインフラストラクチャ構築を効率よくこなすべく、さまざまなソフトウェアツールが提供されてきた。しかし、これまでWindows Serverの世界では、有償だったり使い方が難しかったり、といった理由から、そうしたツールが広く利用されているとはいえないのが現状だ。
そんな中、Windows Server 2012 R2と同時期にリリースされた「PowerShell Desired State Configuration（DSC）」が構成管理の自動化ツールとして注目を集めている。詳細は後ほど説明するが、Windows OSの標準ツールになると目されていること、そして（Windows OSのライセンスがあれば）無償で利用できることが、その理由として挙げられるだろう。
本稿ではWindows Serverの管理者を対象に、このPowerShell DSCでWindowsインフラの構成管理を自動化するという前提で、その基本的な概念や特長、セットアップ方法、そして基本的な使い方まで解説する。今回の前編では概要とセットアップについて説明し、後編では実際のPowerShell DSCの利用例を紹介する。またLinuxの世界で著名な構成管理ツール「Chef」「Puppet」とPowerShell DSCとの関係や比較についても簡単に触れる。
PowerShell DSCとは?
DSCは、物理ホスト、仮想マシン、オンプレミス、クラウドといったさまざまな規模のWindowsインフラ環境において、Windowsサーバー自身を「あるべき状態（Desired State）に構成（Configuration）する」ための自動化プラットフォームだ。
DSCを使うことで、例えばWindowsのローカルユーザーやグループの作成やプロセス／サービスの操作、環境変数／レジストリ／ファイルの操作やパッケージのインストールなど、多岐にわたる構成がDSCのコードで管理可能となる。DSCには、PowerShellで記述された「Resource（リソース）」と呼ばれる機能を拡張する仕組みが用意されており、目的に応じたResourceを導入することで簡単に構成対象を追加できる。より端的にいうと、ResourceはDSCの操作を定義したものといえる。標準では12のResourceが用意されている。
| 名前 | 概要 |
|---|---|
| Archive Resource | 指定したパスに圧縮（.zip）ファイルの解凍を行う |
| Environment Resource | 環境変数を管理する |
| File Resource | ファイルやディレクトリを管理する |
| Group Resource | ローカルグループを管理する |
| Log Resource | コンフィグレーションメッセージのログ |
| Package Resource | WindowsインストーラーやSetup.exeなどのパッケージをインストールしたり、管理したりする |
| Process Resource | Windowsプロセスを管理する |
| Registry Resource | レジストリキーや値を管理する |
| Role Resource | Windowsの機能と役割を管理する |
| Script Resource | Windows PowerShellスクリプトブロックを実行する |
| Service Resource | サービスを管理する |
| User Resource | ローカルユーザーを管理する |
| PowerShell DSCの標準Resource | |
標準Resource以外にも、Microsoft PowerShellチームからDSCのリリース後、3回にわたって追加のResourceが公開されているし、他にPowerShellコミュニティも独自にResourceを開発、公開している。もちろん必要があれば自作も可能だ。
PowerShell DSCで可能になること
DSCの目的は、管理者が長年手作業で操作することによって、サーバーの設定が異なる状態（Configuration Drift）になることを防ぎ、サーバー構成をコードにすることで自動化を実現することである。
そこでDSCに求められる重要な要素として、次の3つが挙げられる。
- Infrastructure as Code
- 宣言的構文（Declarative Syntax）
- 冪等性（べき等性）
以下、順番に見ていこう。
Infrastructure as Code
DSCではインフラ設定をどのように構築、維持するべきかをPowerShellで記述して、ソースコードと同様に扱える。このような概念を「Infrastructure as Code」という。手順書をいちいち書き起こして実作業を人の手作業に任せるのではなく、PowerShellでインフラ構成を定義しておけば、実行作業はDSCに任せて自動化できる。多忙なインフラエンジニアにとっては非常に魅力的だろう。
インフラ環境をコード管理できるということは、変更内容をアプリケーションと同様にGitなどのバージョン管理システムで保持できることを意味する。インフラ環境がバージョン管理できるなら、以前のサーバーの状態へ戻すことも簡単にできるようになる。アプリケーションと同じ速度でインフラ側の変更もロールアウトできるため、本番環境への適用時間を短縮し、その他の無用な時間を削減して、変更に強いインフラ環境を手にすることができる。この意義は非常に大きい。クラウドをはじめとして、頻繁にサーバー構成が変化する環境では、まさに欠かせない。
宣言的構文（Declarative Syntax）
DSCのResourceには、操作対象のインフラの定義がPowerShellの文法で記述されている。このResourceを使って、あるべき姿にインフラを構築・維持するための定義を記述したスクリプトファイルを「Configuration（コンフィグレーション）」と呼ぶ。DSCではConfigurationを「宣言的構文（Declarative Syntax）」で記述する。
宣言的構文がもたらす効果を考えてみよう。例えば従来のバッチファイルやPowerShellスクリプトで自動化しようとすると、「どのように構成するか」を手順ごとに記述することになり、煩雑な条件判定や分岐が多くなってしまう。だが宣言的構文を用いたConfigurationでは「何をしたいか」だけを記述すればよいので、シンプルで分かりやすくなることが期待できる。
例として、「IISのインストールを行う」状況を考えてみよう。
PowerShellによる従来のコードサンプルは次の通りだ。
Import-Module ServerManager
# Web Server（IIS）の機能が未インストールかどうか確認してから、未インストールならIISをインストール
If (-not (Get-WindowsFeature "Web-Server").Installed)
{
try
{
Add-WindowsFeature Web-Server -IncludeManagementTools -ErrorAction Stop
}
catch [Exception]
{
Write-Error $_
}
}
これを、DSCで導入されたConfigurationキーワードを使って宣言的構文で記述すると次のようになる。
Configuration IISInstall
{
Node localhost
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
IncludeAllSubFeature = $true
}
}
}
いかがだろうか。「localhostに、WindowsFeature（Windowsの機能）のWeb-Server（IIS）がPresent（存在）していてほしい」という記述になっている。宣言的記述の方が読みやすくなったと感じていただけるのではないだろうか。
もう1つ例を示しておこう。以下は、IIS以外にも、ASP.NETのインストールからWebサイトの設定まで行う例だ。
Configuration WebSiteConfigInstall
{
Import-DscResource -ModuleName cWebAdministration
Node WebServer01
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
IncludeAllSubFeature = $true
}
WindowsFeature ASP
{
Ensure = "Present"
Name = "Web-Asp-Net45"
}
File DirectoryWebSite
{
Ensure = "Present"
DestinationPath = "C:\inetpub\DSCServer"
Type = "Directory"
DependsOn = "[WindowsFeature]IIS"
}
cWebAppPool WebAppPool
{
Ensure = "Present"
Name = "DSCServer"
State = "Started"
}
cWebSite WebSiteDSCServer
{
Ensure = "Present"
Name = "DSCServer"
State = "Started"
BindingInfo = SAMPLE_cWebBindingInformation
{
Protocol = "HTTP"
Port = 80
HostName = "DSCServer"
}
PhysicalPath = "C:\inetpub\DSCServer"
DependsOn = "[WindowsFeature]IIS"
ApplicationPool = "DSCServer"
}
}
}
先ほどの例と比べると、Webサイトを作成するための記述が追加されている。フォルダーの存在やWebサイトの設定を宣言する際にも、Windowsの機能を設定する際とほぼ変わらない宣言構文になっていることが分かる。
冪等性（べき等性）
3つ目の大事な要素として、DSCは「冪等性（べき等性）」を担保する。冪等性とは、「1度行っても複数回行っても、同じ結果になる」という概念だ。先のコードは何度実行してもIISがインストールされた状態に収束する。実行するたびにインストールが繰り返されることはないし、すでにインストールしているからといってエラーになることもない。自動的な構成の適用が可能になった時、本当に「あるべき（Desired State）構成（Configuration）」になったかどうかを確認することは煩わしいが、冪等性が担保されていれば自動化できるだろう。
ただし、多くのDSCの動作は冪等性が保証されているが、ResourceやConfigurationの書き方によっては担保されないことがある。Resourceを自作する時は、冪等性が保証されるように自分でプログラムコードを作り込む必要がある。
DSCの構成――プッシュ型とプル型
次は、DSCがインフラに適用される際のシステム構成を見てみよう。基本的には、DSCを管理するためのマシン（DSCサーバー）と、Resourceを適用する対象となるクライアントマシン（ノード）からなる。
DSCには、どのようにResourceを適用するかによって2種類の形式がある。
1つが「プッシュ型」だ。この方法では、DSCサーバーが各ノードに対して問い合わせてノードを構築していく。いつ設定を適用するか主導権を握っているのはDSCサーバー側である。
もう1つの構成が「プル型」だ。この方法では、各ノードがDSCサーバーに問い合わせることでノード自身を構築していく。いつ設定を適用するか主導権を握っているのは各ノードであり、ノードはDSCサーバーに対して「あるべき構成」が変化してないかどうかを定期的に確認する。
プル型の構成モデル例
プル型では、ノードからDSCサーバーに問い合わせてインフラ環境を構築する。なお、ノードからの問い合わせに応えるため、DSCサーバー上にはIISやOData EndPointなどを用意しておく必要がある。
プッシュ型はプル型に比べて「IIS」や「OData EndPoint」の構築が不要で、任意のタイミングでConfigurationを配布可能なので、少しだけDSCを試すにはうってつけだ。代わりにDSCサーバーはノードが現在疎通可能かどうか状態を知っておかないと「あるべき構成」を適用できるか分からない。
一方で、プル型はプッシュ型に比べて構築に準備が必要だ。しかしノードは設定されたタスクスケジューラに基づいて定期的に「あるべき構成」をDSCに問い合わせるため、DSCサーバーはノードの状態を気にする必要がなく、ノード間の連携をとりやすい。
DSCとChefやPuppetとの違い
さて、WindowsにおいてDSCがサーバー構成管理の唯一の手段か？ というとそうではない。例えばLinuxシステムでよく知られている「Chef」や「Puppet」という構成管理ツールは、実は以前からWindowsシステムにも適用可能だった。
2014年4月2〜3日に開催されたMicrosoftの開発者向けカンファレンス「Build2014」で、Microsoft Azureの仮想マシンが標準でChefやPuppetに対応したことが発表された。発表では、Chefは「Chef Client」においてPowerShellをネイティブでサポートし、内部ではDSCも利用している。より自然にWindowsでもChefが利用できるようにしているのだ。
- 「Chef Brings DevOps Automation to Microsoft’s Build Conference」［英語］（Chef Software）
- 「New Integrations with Microsoft Azure and Visual Studio」［英語］（Puppet Labs）
ではDSCとChefやPuppetでは何が違うのか。最大の違いは、ChefにおけるRubyなどの追加アプリケーションのインストールがDSCでは不要であることだ。これは、DSCのResourceを使って、どのようにインフラを構成、実行するかをWindowsに標準搭載されたPowerShellで記述可能だからだ。同様に、ノードにもエージェントソフトウェアをインストールする必要がない。環境によっては、インストールするソフトウェアに制限がある場合があるだろう。その場合、ChefではRubyが必要なのに対して、追加アプリケーションを入れることなくPowerShellのようなWindows標準コンポーネントだけで利用可能なDSCによる構成管理は有用だろう。
一方、似通っている点もある。DSCをChefと比べてみた。
- DSCにおける「Resource」は、イメージとしてはChefのクックブックに近い
- DSCにおける「Configuration」、ChefでいうRecipeに相当する
- 冪等性を担保していることや、Resourceの自作時に冪等性を保証できるように作り込む必要があるのは、Chefと同じ
- Chefのサーバークライアント形式はDSCのプル型と同様、ノードがサーバーに問い合わせる（その分、Chefユーザーなら親しみやすいかもしれない）
DSCはPowerShellからしか操作できないのか
先ほどChefが内部でDSCを利用していると触れた通り、PowerShell以外の言語、ツールでもDSCは操作可能だ。これはDSCが、「DMTF」という標準仕様に沿って、「Managed Object Format（MOF）」や「WS-Management」で構成されているからであり、実際のサーバー設定に用いるのはMOFファイルだからである（特定のプログラミング言語には依存していない）。
もちろん、MOFを直接メモ帳（NotePad.exe）で書くことも可能だ。だが、PowerShell 4.0ではConfigurationキーワードやインテリセンスをはじめとして「記述から実行まで」サポートされており、より簡単にMOFファイルを作成できる。そのため本記事においては、PowerShellを使ったDSC についてのみ触れる。
Copyright© Digital Advantage Corp. All Rights Reserved.