これは、アドベントカレンダー1日目の記事です。
2013年10月に公開されたPowerShell DSCですが、Azureを中心にWindowsプラットフォームで静かに、しかし着実に実績を残しつつあります。
初日は、PowerShell DSCについてさらっと触れておきましょう。これからDSCを深く見る前に、少しは興味を持っていただければ幸いです。
明日は、Configuration Managementがなぜ必要なのかについてです。
PowerShell DSC とは何か
過去に @ITで記事を書いています。より深く見ていくので物足りないと思った方は楽しみにしていただけると。
https://www.atmarkit.co.jp/ait/articles/1405/22/news131.html
PowerShell DSCは、端的にいうと「サービス稼動しているデータセンターや各環境、ソフトウェア、サービスをあるべき状態に維持するための新しい構成管理プラットフォーム」です。
さて、データセンター環境って大雑把ですね。少し細かく見ていきましょう。
データセンターや各環境ってどういうこと
オンプレミスの方はご自分の環境でも結構ですよ？
データセンターと聞いてどんなことを思い浮かべますか？ そこにはWindowsサーバーだけがある？ ちがいますよね？
そう、データセンターにはスイッチングハブ、L3スイッチ、ロードバランサー、サーバー群、それを管理する機器、他にももろもろ。例が膨大なほど様々なソフトウェアが搭載された機器にあふれています。*1
当然OSがWindowsではない機器も多くあります。むしろWindowsなんて全体で1％にも満たないのが普通です。
データセンターを使っていない？ では、あなたの環境はどうでしょうか？ AWS? Azure? あるいはGCP? 例えクラウド環境においても、Windowsだけを対象にするような狭い見方はいやですし時代遅れといわれても仕方がないことでしょう。
PowerShell DSC は Windows だけを対象にはしていない
データセンターなど混在した環境では管理1つをとっても、様々なツールを使うことになりがちです。LinuxはChef/Puppet/Ansibleで？ ではスイッチは？ L3は？ LBは？ 大変ですね。
もっと標準化された技術を使って、定義されたドキュメントスキーマで構成を解釈できたらどうでしょうか？ 各種構成管理ツールから呼び出せれば、ツールと標準化された技術がスムーズに連動しそうですね？ つまり、OSやあるいは機器の違いを超えて、データセンターの各種機器に対する構成管理のプラットフォームになりえないでしょうか？
この構成管理のプラットフォームとしての存在、それがPowerShell DSCの目指すところです。
PowerShell DSCは、Windowsに依存していません。誤解を招きそうですね。PowerShell DSC は、構文としてはPowerShell の糖衣構文です。様々なキーワードやCmdletで扱いやすいようにしているので、よくPowerShell DSCといわれます。が、DSCとしての本質は糖衣構文から生成された、「mofというスキーマドキュメントに記述された内容」であり、スキーマを解釈できればどの機器でも適用ができます。
標準化された技術の利用
PowerShell DSCが使うスキーマドキュメントはOMI Standardをベースにしています。
Microsoftは、かなり以前から他社と共にHardware Abstraction Layer (HAL) に参画して、より抽象化されたOSを目指していました。Windows Server 2012は参画して初のCloud OSとしての出発といいます。
OMIはそれだけで、ながーい記事になるので興味のある人はちょっとこの辺をどうぞ。
https://blogs.technet.com/b/Windowsserver/archive/2012/06/28/open-management-infrastructure.aspx
PowerShell DSCの本質は、OMIをベースにOSや機器で縛られない構成管理です。 Windowsの実装ではCIM(以前はWMI)と呼ばれ、他OS/機器との境目をなくして標準化された技術として扱えるようにしています。
このため、PowerShell DSC は Windows だけを対象にしておらず、OMI標準に則っていれば他OSやスイッチであっても管理が可能です。
Linuxの例としてはこちらをどうぞ。
実はDockerも記事にしてたり、ね！
OSのみならずOMIを実装したスイッチも管理できるとDELL S4810やS55を例に発表もされています。
プラットフォームとツールの違い
良く勘違いされるのですが、「PowerShell DSCってWindowsにしか使えないんでしょ？ 使えない！」は誤りであり、一部正しいです。まだ未熟なのでLinuxで使いやすいかというとそうでもないでしょう。
前節で述べた通り、PowerShell DSCは、WindowsやLinuxを含めてOSだけを対象にしていません。OMIに則っていれば、OSや機器のレベルまでどれもが対象に管理できることを目指しています。「データセンター管理をも扱えるプラットフォームを目指して設計」されているのは繰り返した通りです。
そのため、ChefやPuppetは Configuration Management Toolと呼ばれるのに対して、MicrosoftはPowerShell DSCを Configuration Management Platform と表現しています。
プラットフォームとツール、その違いは何でしょうか？
Chef
Chefを使ったことがある人は、Chefの完成度にかなり満足できるでしょう。クックブックからレシピ、ナイフ、chef local modeまで、Configuration ManagementはChefで完結できます。素晴らしいです。さすがです。
しかし、スイッチに対しても適用するのはめんどうですね。
PowerShell DSC
ではDSCはどうでしょうか？ ChefチームとPowerShellチームが完全にタッグを組んでDSCは開発されました。なので、ChefとPowerShellを対比させるとよく似ていることに気づきます。
| 要素 | PowerShell DSC | Chef |
|---|---|---|
| 言語 | PowerShell | Ruby |
| エンジン | LCM | chef client |
| レシピ | Configuration | Recipe |
| クックブック | Resource | Cookbooks |
| スタンドアローン | Push | chef local mode (あるいは chef solo) |
| サーバー/ノード | Push / Pull | Chef Server |
| ノード管理 | CIM Method/ASP.NET | Knife |
でもノード管理は不十分ですし、Knifeなどコマンドの使い心地にはまだまだ及びません。ツールとしてはまだまだ未熟です。*2
ツールとして未熟でもOMIをベースにして、PowerShellに限らずRubyを含めた各種言語から呼び出すことを可能としています。実際に、ChefからResource *3、Configuration*4、 mofスキーマ*5 を直接呼び出せるようにしています。つまり、ChefはDSCを土台にすることで、WindowsであってもLinuxやUNIXと変わらない使い心地で構成管理ができます。
https://www.getchef.com/blog/2014/09/08/chef-11-16-gets-into-powershell-dsc/
先ほども紹介した通り、まだ機能が限定されているとはいえ、WindowsだけでなくLinuxやスイッチも管理できます。
つまり、「PowerShell DSC は自身のツールとしての成熟よりも、他ツールと連携できるプラットフォームとしての性格が強い」と思っていただけると、なぜConfiguration Management Platformというコンセプトがわかりやすいでしょう。
Edge Show 123
このデータセンターで！ とかプラットフォームとして！ といった考えは、 PowerShell開発チームメンバー自身も含めてMicrosoftがたびたびオープンにしているのですが、全然注目されてません。残念です。
せっかくなので1つ動画を紹介しておきます。*6
Edge Show 123 - Desired State Configuration (DSC) with PowerShell in the Datacenter
どこでDSC動かすの
PowerShell DSCのサーバー自体は、Windowsで動かすのが楽なのは事実です。Linuxでの動作はまだPushに限られているので限定的です。*7
そのためWindowsが多く、Linuxも管理したい環境にはうってつけでしょう。もちろん逆でもいいでしょうが、ふつーは数の多いOSによってCMツールをすでに導入済みでしょうから、ね。
まぁ、使いやすい方を使えばいいんですよ。はい。
PowerShell DSC の利用可能なWindows
PowerShell 4.0以上で利用でき、OSとしてはWindows 2008R2から使えます。Windows Server 2012と2008 R2には、Windows Management Framework 4.0(以降WMF4.0) を入れる必要がありますが、2012 R2はデフォルトで利用できます。
Windows 7SP1とWindows 8もWMF 4.0が必要ですが、Windows 8.1はデフォルトで利用できます。
Windows だけが PowerShell DSC の利用対象じゃない
LinuxもDSCを使えますよ？ WindowsをDSCサーバーとして、PushでLinuxも対象にできます。
OMIが必要要件なので、CentOS、Ubuntu、Oracle Linuxそれぞれいけます。Microsoftの公開しているリポジトリを紹介しておきましょう。
例えば、OMIの事前作業としては、
# Cent OS yum -y groupinstall 'Development Tools' yum -y install pam-devel yum -y install openssl-devel yum -y install python yum -y install python-devel
# Ununtu pt-get -y install build-essential apt-get -y install pkg-config apt-get -y install python apt-get -y install python-dev apt-get -y install libpam-dev apt-get -y install libssl-dev
# Oracle Linux yum -y groupinstall 'Development Tools' yum -y install pam-devel yum -y install openssl-devel yum -y install python yum -y install python-devel yum -y install wget yum -y install kernel-headers
そして、OMIのダウンロードセットアップは
mkdir /root/downloads cd /root/downloads wget https://collaboration.opengroup.org/omi/documents/30532/omi-1.0.8.tar.gz tar -xvf omi-1.0.8.tar.gz cd omi-1.0.8 ./configure | tee /tmp/omi-configure.txt make | tee /tmp/omi-make.txt make install | tee /tmp/omi-make-install.txt
あとは、DSC Linuxをセットアップ
cd /root/downloads wget https://github.com/MSFTOSSMgmt/WPSDSCLinux/releases/download/v1.0.0-CTP/PSDSCLinux.tar.gz tar -xvf PSDSCLinux.tar.gz cd dsc/ mv * /root/downloads/ cd /root/downloads make | tee /tmp/dsc-make.txt make reg | tee /tmp/dsc-make-reg.txt
最後にOMIの開始でokです。
OMI_HOME=/opt/omi-1.0.8 /opt/omi-1.0.8/bin/omiserver -d
まとめ
- PowerShell DSCはまだまだツールしては未熟。でもPowerShell v5で一気に改善される
- Windowsやそれ以外にもPowerShell DSCは使えるし、Configuration Managementの1つとして覚えて損はない
まぁ、Windowsにしか使えないし、Chefだけでいいや。という印象を少しでもぬぐっていただけるとうれしいです。ChefでWidowsを扱うよりDSCを呼び出す方が、圧倒的に楽ですよ。
.... さらっと、とは.... これから毎日PowerShell DSCに関するもろもろを連載していくので、体力が尽きないことを祈っています。
