Imperative Programming を日本語でどう訳すべきなのかググると、命令型プログラミングと呼ぶことが多いようですね。 一方で、 Declarative programmingは、宣言型プログラミングだとか。
さて、これまで PowerShell 1.0 - 3.0 までは、所謂 Imperative Programming 「命令型プログラミング」が主体となってきました。 これに対して、TechEd NA 2013において、Jeffrey Snover と Kenneth Hansen から、PowerShell 4.0では Desired State Configuration (DSC)を取り込む事が明らかにされました。
では、そのDSC でどう変わるのかを見てみましょう。 本内容を示すに当たり、秀逸に纏められた記事があったので、参照しつつ進めていきます。
Imperative versus declarative syntax in PowerShell
DSCとは
神様 Jeffrey Snover がDSCについて講演しています。 Desired State Configuration in Windows Server 2012 R2 PowerShell キーワードはここで。
PowerShell Desired State Configuration Enables you to ensure that the components of your data center have the correct configuration. Allows "continuous deployment" and prevents "configuration drift" Uses language extensions and providers to enable declarative, autonomous and idempotnt (repeatable) Deployment, Configuration and Conformance of standards-based manged elements.
ざっくり和訳すると
PowerShell Desired State Configuration とは データセンター(大規模環境)において 各コンポーネント (IISなど) が正しい設定になっているかを確実にしてくれる 継続したデプロイを可能にして、設定(コンフィグ)が流れてしまうことを防ぐ 言語拡張(各国の言語)で、宣言を可能にし、繰り返し実行してもデプロイ結果、設定を維持します。
データセンター(大規模環境)において 各コンポーネント (IISなど) が正しい設定になっているかを確実にしてくれる
これまでの命令型では、このモジュールが含まれて入ることを確認して、なければ入れて、あれば次の..... と順に順に実行しました。
一方で、DSC では あるべき姿を示し、足りない部分を psd1 で定義したとおりにセットアップします。 この時、 HashTableを用いてDSCを構造化して示す、つまり declarative syntax と表されています。 依存を解決し、必要に応じて処理をすすめる、これが可能になります。
継続したデプロイを可能にして、設定(コンフィグ)が流れてしまうことを防ぐ
宣言をベースにしているため、変更があった場合は、その箇所の宣言を変えるだけです。 つまり、過程、変更を考慮してコードに落とす必要はなく、宣言を変えるのみで済みます。
この小さな変更が、継続したデプロイを可能にし、人による理解の差異を少なくします。
言語拡張(各国の言語)で、宣言を可能にし、繰り返し実行してもデプロイ結果、設定を維持します。
DSCはあるべき姿にする = 命令型のような、考慮もれにより開始状態によって結果が変わることを防ぎます。 つまり、初期状態から設定しても、設定完了後に再度実行しても結果は変わりません。
standards-based manged elements = これは、DSCは PowerShellなの?それとも Windowsの機能なの? にかけています。講演中、これに対して二人はこのように答えています。
"First inplemented on Windows, Using PowerShell Language and WMI and PowerShell Extention Mode."
もう少し分かり易く言うと、 「DSCはPowerShellだけの機能ではなく、 Windowsの core OSに新たに実装された機能です。 PowerShell 4.0の DSCは、PowerShellを用いてより容易にDSCを扱おうというものです。」
Imperative と DSCの違い - PowerShell 3.0までのImperativeな記述
Pull/Push型に関しては、またの機会に記事に起こすとして、Imperative と DSCの違いを見てみましょう。 これは、PowerShell 3.0までにおける、Imperativeスタイルで記述したIISと ASP.NETのインストールスクリプト例です。
Import-Module ServerManager
#Check and install ASP.NET 4.5 feature
If (-not (Get-WindowsFeature "Web-Asp-Net45").Installed) {
try {
Add-WindowsFeature Web-Asp-Net45
}
catch {
Write-Error $_
}
}
#Check and install Web Server Feature
If (-not (Get-WindowsFeature "Web-Server").Installed) {
try {
Add-WindowsFeature Web-Server
}
catch {
Write-Error $_
}
}
#Create a new website
Add-PSSnapin WebAdministration
New-WebSite -Name MyWebSite -Port 80 -HostHeader MyWebSite -PhysicalPath "$env:systemdrive\inetpub\MyWebSite"
#Start the website
Start-WebSite -Name MyWebSite
見てわかる通り、「望む結果に至るために、どのようにすればいいのか」 (how to perform what we need to perform) を記述しています。
この場合で言うと、ASP.NETやIISが存在するかを確認してから、無ければ機能追加をして、WebSiteを作成して、WebSiteを開始しています。 見慣れた記述であり、私自身毎日このような記述を書いています。
Imperative と DSCの違い - PowerShell 4.0からのDSCを用いた記述
これと同じ結果を、PowerShell 4.0からは DSC で行えます。
Configuration WebSiteConfig
{
Node MyWebServer
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
}
WindowsFeature ASP
{
Ensure = "Present"
Name = "Web-Asp-Net45"
}
Website MyWebSite
{
Ensure = "Present"
Name = "MyWebSite"
PhysicalPath = "C:\Inetpub\MyWebSite"
State = "Started"
Protocol = @("http")
BindingInfo = @("*:80:")
}
}
}
先ほどのImperativeな記述と見比べてください。
「あってほしい望む結果を示しており、どのようになされるべきかは記述していません」 (what needs to be done and not how it needs to be done)
1. ASP.NETとIISがあることを望み(Ensure = "Present")
2. WebSiteも存在して、(Ensure = "Present")
3. 名称などが記述され
4. DSC実行後開始していることを望んでいます。(State = "Started")
これが、これまでのImperativeとdeclarative syntax との違いです。
もちろん、DSCというフレームワーク内で、上記を実現するためにdeclarative syntaxの宣言以外にやるべきことはあります。 が、何をしたいのかが、Imperativeに比べて、DSCの方が明らかに見やすくなっていることが分かると思います。
詳しい DSCの設定は後日に譲るとして、DSCが目指すこれからの PowerShell 4.0 これが主体となる事を如実に感じさせ、わくわくしてきますね！ また、PowerShell 4.0と DSCについては記事にしたいと思います。
