🚫 🤹🏽 👈🏾 Windows Server 2012 R2の望ましい状態構成の実際の使用 ☘️ 🔲 👨🏼‍🎓

Linux Admin：これはWindows用の「Puppet」に関する記事であり、Linux用のDSCのベータ版が既にあります。

トピックの対象者：最新のPowerShell 5.0については何もありません。WindowsServer 2012 R2の「ボックス」からのみ利用可能です。

前文

2013年、Windows Server 2012 R2のリリースに伴い、MicrosoftはPowershell Desired State Configuration（DSC）の導入を発表しました。

この時点で、Linux用の類似のシステムが何をするのか（例えば、すでに述べたPuppetなど）を多少想像しました。したがって、提案された機能は、完全に自動化されたシステム構成には不十分だと思われました。 Powershell 5.0と新しいDSC機能についての最近の報告だけが、このテクノロジーに再び注意を払うように促しました。

理解するために、私はより簡単なタスクを思いつきました：

私たちが開発したASP.NETアプリケーションを自分のサーバーに個別にインストールしたい特定のクライアントがあるとします。 IISに加えて、MS SQL Serverが必要です。また、オペレーティングシステムのいくつかの設定を行い、いくつかの重要なユーティリティをインストールする必要があります。

新しくインストールされたWindows Server 2012 R2で必要なすべてを実行するインストールおよび構成手順の代わりに、構成スクリプトを発行することはできますか？

この記事をよりよく理解するために、Microsoftブログ（ http://habrahabr.ru/company/microsoft/blog/253497/）の説明を最初に読んでください。

開始位置

元々、サーバーはどこかのホスティングプロバイダーから注文されたと想定されていました。 Windows Server 2012 R2がインストールされており、管理者パスワードとサーバーのIPアドレスを含むアラートが表示されました。

そして、次の例のように、1つのコマンドを入力します。

makemagic -server new.example.com

しばらくすると、システムを使用する準備が整います。

残念ながら、これはまだ不可能です。しかし、良いニュースがあります-Windows Server 2016の次のバージョンになります。この記事を書いている間、以下に説明する構成は（もちろん、更新プログラムをインストールせずに）インストールされたTechnical Preview 3のみに適用されます。

サーバー

使用可能な統合更新プログラムを含むWindows Server 2012 R2のイメージがある場合は、このセクションをスキップしてください。

現在のバージョン（2012 R2）では、更新チェーンに問題があります。

私がやろうとした最初のタスクの1つは、タイムゾーンの確認/設定でした。これを行うには、最新のタイムゾーン更新プログラムをインストールする必要があります。
KB2919355の大規模な更新が必要なため、この更新はインストールされません。
これは、私の場合、KB2975061の更新を希望しています。

これらの更新は、新しくインストールされたシステムにWindows Updateを介してインストールすることはできません。

したがって、2つのオプションがあります。1）Windows Updateを介してすべての更新プログラムをインストールしますが、時間がかかります（このプロセスは後で完了できます）、または2）最も必要なもののみを配置します。

2番目のケースでは、これを行います。RDPを介してサーバーに接続し、昇格された権限でPowershellコンソールを実行し、必要な更新を直接リンク経由でダウンロードしてインストールします。

 Invoke-WebRequest -Uri http://download.microsoft.com/download/3/9/7/3971FEA1-C483-409E-BF13-219F8A6E907E/Windows8.1-KB2975061-x64.msu -OutFile .\Downloads\Windows8.1-KB2975061-x64.msu .\Downloads\Windows8.1-KB2975061-x64.msu /quiet /norestart Invoke-WebRequest -Uri http://download.microsoft.com/download/2/5/6/256CCCFB-5341-4A8D-A277-8A81B21A1E35/Windows8.1-KB2919355-x64.msu -OutFile .\Downloads\Windows8.1-KB2919355-x64.msu .\Downloads\Windows8.1-KB2919355-x64.msu /quiet /promtrestart

再起動後、サーバーは構成を受信する準備が整います。

Windows Server 2016 TP3はすぐにDSCを試す準備ができていることを思い出します。

管理コンピューター

重要：したがって、前のセクションをスキップできます：使用可能な方法でこの構成例をテストするには、MS SQL Server 2014イメージをサーバーに接続し、Express Editionを選択してR：として接続します。

すでにWindows 10にアップグレードしたユーザーを失望させる必要があります。このシステムで作成された構成を使用できない微妙な違いがあります。 Powershell 5.0をインストールしたユーザーにも同じことが当てはまります。

構成の作成と適用は、Windows 8.1で実行されました。 Powershellバージョン：

 PS C:\Users\nelsh> $PSVersionTable Name Value ---- ----- PSVersion 4.0 WSManStackVersion 3.0 SerializationVersion 1.1.0.1 CLRVersion 4.0.30319.34209 BuildVersion 6.3.9600.17400 PSCompatibleVersions {1.0, 2.0, 3.0, 4.0} PSRemotingProtocolVersion 2.2

しかし、これでもまだ十分ではありません。管理者のコンピューターで、Powershell Remotingを有効にする必要があります（サーバーで、2つの更新プログラムをインストールした後、PSRemotingは既に有効になっています）。これは、昇格された権限でPowershellコンソールで実行されます。

 Enable-PSRemoting -Force

さらに、管理者のコンピューターから他のコンピューターへの接続を許可する必要があります（！）。

 Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

便宜上、作成したサーバーのIPアドレスを含む行をhosts

追加しました。

 <ip-address> cs1.example.com

サンプルのソースコードはGithubで入手できます： https : //github.com/nelsh/DSC-WS2012R2

最初の構成

これは、DSC-W2012R2.ps1ファイルの最初のバージョンのスクリーンショットです（便宜上、DSC-W2012R2-First.ps1という名前でリポジトリにあります）。

1〜21行-DSCW2012R2と呼ばれる構成自体。
- その中の3行目から7行目で、パラメーターが1つだけになることを通知します-サーバー名の配列です。
- 8行目で、必要なPowerShellモジュールを接続します
- 10〜20行-構成で使用されるリソースのリスト。私たちの場合、「スクリプト」リソースは1つしかなく、それより少し低くなっています。
23-25行-手順の1つはユーザーを追加することなので、ユーザーのパスワードを作成する必要があります。暗号化を処理しないために、パスワードを平文で構成に保存することを許可します。
27行目-構成の作成。このスクリプトを実行した結果、ファイルDSCW2012R2 \ cs1.example.com.mofが作成されます-コンパイル済みの構成のようなものです。
29〜31行-cs1.example.comという名前のサーバーへの構成のアプリケーションを開始します。サーバーにアクセスするためのユーザー名とパスワードを要求するための標準ウィンドウが最初に表示されます。
33行目から、サーバーのペアを同時にセットアップする例。

リソースに戻る-Powershell DSCには12の組み込みリソースがあります。それらのほとんど（または12個中11個）は単純で理解しやすいものです。しかし、システムを完全に構成するには、明らかに十分ではありません。 Microsoftは、必要なリソースを独自に作成することをお勧めします。しかし、正直なところ、今でもこれに対処したいという特別な欲求はありません。

ただし、最初に会ったときは、 スクリプトリソースに注意を払いませんでした。例をさらに詳しく見てみましょう。

  Script First { TestScript = { if ( "Test script content" ) { $true } else { $false } } SetScript = { "Set script content" } GetScript = { return @{ Result = "Result for GetScript" GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } }

これは、何もしない最も簡単なオプションです。仕組み：

構成を適用するには、Start-DSCConfigurationコマンドを呼び出します（29行目）。
スクリプトは、リソースのリストを処理中に「Script First」リソースに到達すると、最初にTestScript変数からコードを呼び出します。この例では、常に$ trueを返します。
しかし、彼が$ falseを返した場合、SetScript変数からコードが呼び出されます。

Powershellコードはこれらの変数に含めることができます-スケールは空想にのみ依存します。理想的には、TestSciptのコードは、SetScriptコードで行われたすべての設定が正しいことを確認する必要があります。

最初の構成を実行してみましょう（古い習慣として、Far Managerから始めます）。

 powershell.exe -ExecutionPolicy RemoteSigned .\DSC-WS2012R2.ps1

エラーなしで完了しました。

管理者のコンピューターからスキャンを開始する方法を説明しないために、サーバーにアクセスしていくつかのコマンドを実行しました。

最初： Test-DSCConfiguration

構成を確認します。最後のメッセージ（黄色のテキストの後）に注意してください-True。つまり設定がチェックされ、エラーは検出されませんでした。

次のコマンド： Get-DSCConfiguration

現在の構成に関する詳細をGet-DSCConfiguration

ます。このスクリーンショットで「スクリプトファースト」リソースのコードをチェックして、それが何からどこにあるのかを理解するだけで十分です。

この瞬間、私はおそらく、すべてがうまくいくことに気づきました。

だから。に移りましょう...

高度な構成

ノードの構成に実際のタスクを追加し始めます。

最初に確認したいのは、コンピューター名とメインのDNSサフィックスです。 DNSゾーンでこのコンピューターの名前がcs1.example.comの場合、名前はcs1、dnsサフィックスはexample.comです

名前から始めましょう。最初にこのコードを書きました：

  $shortName = $Server.Split(".")[0].ToLower() Script ComputerName { SetScript = { Rename-Computer -NewName $shortName } GetScript = { return @{ Result = $env:computerName GetScript = $GetScript.Trim(); SetScript = $SetScript.Trim(); TestScript = $TestScript.Trim() } } TestScript = { $env:computerName.ToLower() -eq $shortName } }

しかし、それは機能しません。 SetScript、GetScript、およびTestScriptは、スコープ外の変数については何も知りません。行の書式設定を使用してのみ転送できます。このように：

  $shortName = $Server.Split(".")[0].ToLower() Script ComputerName { SetScript = ({ Rename-Computer -NewName "{0}" } -f @($shortName)) GetScript = { return @{ Result = $env:computerName GetScript = $GetScript.Trim(); SetScript = $SetScript.Trim(); TestScript = $TestScript.Trim() } } TestScript = ({ $env:computerName.ToLower() -eq "{0}" } -f @($shortName)) }

dnsサフィックスの検証により、すべてがよりシンプルであることが判明しました。これはレジストリ内のパラメーターなので、標準のレジストリリソースを使用します。

  Registry PrimaryDomainSuffix { Key = "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\" ValueName = "NV Domain" Ensure = "Present" ValueData = "example.com" ValueType = "String" }

実験中に更新が自動的に設定されないように、Windows Updateを構成します。利用可能なアップデートの通知のみを受け取ります：

  Script WindowsUpdateSettings { SetScript = { $WUSettings = (New-Object -com "Microsoft.Update.AutoUpdate").Settings $WUSettings.NotificationLevel=2 $WUSettings.IncludeRecommendedUpdates=$true $WUSettings.Save() } GetScript = { return @{ Result = '' GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = { $WUSettings = (New-Object -com "Microsoft.Update.AutoUpdate").Settings; $WUSettings.NotificationLevel -eq 2 -and $WUSettings.IncludeRecommendedUpdates -eq $true } }

いくつかの重要な更新を取得し、それでもタイムゾーンを設定します

次に重要なパラメーターはタイムゾーンです。そして、なぜモスクワの時間がすべての人に適しているわけではないと提案したのですか？どうやらこれ：

したがって、最初の問題：Windows Updateを介した個別の更新のための組み込みのインストールツールはないようです。幸いなことに、この問題を解決する小さなユーティリティがあります。

ユーティリティのディレクトリを作成します。

  $abcUpdatePath = "C:\UTILS\ABC-Update" $abcUpdateZip = Join-Path $abcUpdatePath "ABC-Update.zip" File AbcUpdateDir { Ensure = "present" DestinationPath = $abcUpdatePath Type = "Directory" }

ダウンロード：

  Script AbcUpdateDownload { DependsOn = "[File]AbcUpdateDir" SetScript = ({ Invoke-WebRequest -Uri http://abc-deploy.com/Files/ABC-Update.zip -OutFile {0} } -f @($abcUpdateZip)) GetScript = { return @{ Result = $TestScript GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = ({ Test-Path {0} } -f @($abcUpdateZip)) }

組み込みのアーカイブリソースを使用して解凍します。

  Archive AbcUpdateUnpack { Ensure = "Present" DependsOn = "[Script]AbcUpdateDownload" Path = $abcUpdateZip Destination = $abcUpdatePath }

開始し、タイムゾーンの更新に加えて、すぐに.NET Frameworkをバージョン4.5.2に更新します。

  Script AbcUpdateNet452Install { DependsOn = "[Archive]AbcUpdateUnpack" SetScript = { C:\UTILS\ABC-Update\ABC-Update.exe /a:install /k:2934520 } GetScript = { return @{ Result = if ( Get-HotFix -Id KB2934520 -ErrorAction SilentlyContinue ) { "KB2934520: Installed" } else { "KB2934520: Not Found" } GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = { if ( Get-HotFix -Id KB2934520 -ErrorAction SilentlyContinue ) { $true } else { $false } } } Script AbcUpdateTimeZoneInstall { DependsOn = "[Archive]AbcUpdateUnpack" SetScript = { C:\UTILS\ABC-Update\ABC-Update.exe /a:install /k:3013410 } GetScript = { return @{ Result = if ( Get-HotFix -Id KB3013410 -ErrorAction SilentlyContinue ) { "KB3013410: Installed" } else { "KB3013410: Not Found" } GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = { if ( Get-HotFix -Id KB3013410 -ErrorAction SilentlyContinue ) { $true } else { $false } } }

最後にタイムゾーンに到達しました。科学的な突進の方法によって、私はバイカル湖の近くの時間帯を選びました。

私はこのオプションを見つけました：tzutil.exeコマンドラインユーティリティを使用してのみタイムゾーンを変更し、Powershellを使用してのみチェックできます。ただし、このケースは特別です。インストール中に、1つの値「北アジア東部標準時」が使用され、まったく異なる「ロシアTZ 7標準時」がチェックされます。

  Script TimeZoneSettings { SetScript = { tzutil.exe /s "North Asia East Standard Time" } GetScript = { return @{ Result = [System.TimeZone]::CurrentTimeZone.StandardName GetScript = $GetScript.Trim(); SetScript = $SetScript.Trim(); TestScript = $TestScript.Trim() } } TestScript = { [System.TimeZone]::CurrentTimeZone.StandardName -eq "Russia TZ 7 Standard Time" } }

ロシアのすべてのタイムゾーンでこのような災害のようです。

Windowsコンポーネント

それらを使用すると、すべてが非常にシンプルで、インターネット上の非常に多くの例があります。 Windows管理者はコンポーネントのインストールと削除のみを行っているように思われるかもしれません。構成の最初の2つのWindowsFeatureリソースのみ：

  WindowsFeature offFSSMB1 { Ensure = "Absent" Name = "FS-SMB1" } WindowsFeature WebAspNet45 { Ensure = "Present" Name = "Web-Asp-Net45" IncludeAllSubFeature = $True }

最初の場合、コンポーネントは削除され、2番目の場合、すべての依存関係とともにインストールされます。

パッケージのインストール

Far Managerの例について。まず、既知の方法でパッケージをダウンロードする必要があります。

  Script FarDownLoad { SetScript = { Invoke-WebRequest -Uri http://www.farmanager.com/files/Far30b4400.x64.20150709.msi -OutFile C:\Users\Public\Downloads\Far30b4400.x64.20150709.msi } GetScript = { return @{ Result = Test-Path C:\Users\Public\Downloads\Far30b4400.x64.20150709.msi GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = { Test-Path C:\Users\Public\Downloads\Far30b4400.x64.20150709.msi } }

リソースパラメータでは、パッケージは「ProductId」です。また、msiファイルを分析し、これと同じ「ProductId」を報告するプログラムもあるようです。先に進みました。このパラメーターを使用せずに構成をすぐに適用しようとしましたが、エラーテキストに「ProductId」と正しい「Name」が見つかりました。リソースの説明は次のとおりです。

  Package FarInstall { Ensure = "Present" DependsOn = "[Script]FarDownLoad" Name = "Far Manager 3 x64" ProductId = 'E5512F32-B7C1-48E3-B6AF-E5F962F99ED6' Path = "C:\Users\Public\Downloads\Far30b4400.x64.20150709.msi" Arguments = '' LogPath = "C:\Users\Public\Downloads\FarInstall.log" }

ユーザーと権利

問題の声明によると、サーバーは顧客の管理下にありますが、それでも、継続的統合サーバーを使用してWebアプリケーションを更新できることを認めました。 Jenkins CIを使用します（ちなみに、その中のすべてのタスクはPowershellにも実装されています）。

最小バージョンでは、UsersグループにJenkinsユーザーが必要で、Webアプリケーションが存在するディレクトリへの書き込みアクセス権があります。 c:\web

ます。

ユーザーは次の方法で作成されます。

  $JenkinsCredential = New-Object System.Management.Automation.PSCredential(` "Jenkins", ("Pa`$`$w0rd" | ConvertTo-SecureString -asPlainText -Force)` ) User JenkinsUser { UserName = "Jenkins" Ensure = "Present" Password = $JenkinsCredential PasswordChangeNotAllowed = $true PasswordNeverExpires = $true }

構成で暗号化されたパスワードを使用する方法がありますが、簡単な方法を使用します。この場合、ユーザー「Jenkins」はパスワード「Pa $$ w0rd」で作成されます。

ディレクトリの作成は通常の方法で行われます。しかし、ディレクトリへの権利の割り当てと検証では、いじくり回す必要がありました。

  $AccessStringTmpl = "NT AUTHORITY\SYSTEM Allow FullControl`nBUILTIN\Administrators Allow FullControl`nBUILTIN\Users Allow ReadAndExecute, Synchronize`nCS1\Jenkins Allow Modify, Synchronize" File DirDweb { Ensure = "present" DestinationPath = "c:\web" Type = "Directory" } Script AclsDweb { DependsOn = "[File]DirDweb" SetScript = { icacls c:\web /reset /t /q takeown.exe /fc:\web /r /a /dy icacls.exe c:\web /inheritance:r icacls.exe c:\web /grant:r "Administrators:(OI)(CI)(F)" "System:(OI)(CI)(F)" "Users:(OI)(CI)(RX)" "Jenkins:(OI)(CI)(M)" /t /q } GetScript = { return @{ Result = (get-acl c:\web).AccessToString GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = ({ (get-acl c:\web).AccessToString -eq "{0}" } -f @($AccessStringTmpl)) }

最も簡単な方法は、 icacls.exe

を使用して権利を割り当てることicacls.exe

。この場合、次の順序で実行されます。

1行目：すべての権限をリセットし、親ディレクトリからの継承を有効にします
2番目：ビルトイングループAdministratorsが所有者として割り当てられます
3番目：継承がキャンセルされ、すべての権利が削除されます
4番目：管理者およびSYSTEMに対する完全な権限の割り当て、ユーザーに対する読み取り、Jenkinsに対する変更。

検証には、メソッド(get-acl c:\web).AccessToString

受信した文字列は、 $AccessStringTmpl

変数と一致する必要があります。ちなみに、この例ではエラーがあります-サーバー名「CS1」が行に明示的に示されています-そして、値$Server.Split(".")[0].ToUpper()

に置き換えてください。

MS SQL

サードパーティのモジュールを使用しないことにしたことを少し後悔しました。 MS SQL Serverをインストールおよび構成するためのモジュールが既にあるため。しかし、自動インストール用の構成ファイルがあり、試してみることにしました。

まず、別のWindowsコンポーネントが必要です-「WindowsFeature NetFrameworkCore」リソース：

  WindowsFeature NetFrameworkCore { Ensure = "Present" Name = "Net-Framework-Core" IncludeAllSubFeature = $True }

次に、インストーラーの構成ファイルは「Script MSSQLConfigDownLoad」リソースです。

  Script MSSQLConfigDownLoad { SetScript = { Invoke-WebRequest -Uri https://raw.githubusercontent.com/nelsh/DSC-WS2012R2/master/SQL2014-Setup.ini -OutFile C:\Users\Public\Downloads\SQL2014-Setup.ini } GetScript = { return @{ Result = Test-Path C:\Users\Public\Downloads\SQL2014-Setup.ini GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = { Test-Path C:\Users\Public\Downloads\SQL2014-Setup.ini } }

第三に、MS SQL Server 2014の一部のエディションの配布キットにイメージを接続したことを覚えていますか？

  Script MSSQL { SetScript = { r:\setup.exe /configurationfile=C:\Users\Public\Downloads\SQL2014-Setup.ini /SAPWD=1q@w3e } GetScript = { return @{ Result = if ( Get-Service -Name "MSSQLSERVER" -ErrorAction SilentlyContinue ) { "Servise MSSQLSERVER is exist" } else { "Servise MSSQLSERVER not found" } GetScript = $GetScript; SetScript = $SetScript; TestScript = $TestScript } } TestScript = { if ( Get-Service -Name "MSSQLSERVER" -ErrorAction SilentlyContinue ) { $true } else { $false } } }

R：。として接続されているExpress Editionドライブを使用しました。その過程で、データベースエンジンとFullSearch、および管理ツールがインストールされます。 TestScriptのテストが最も簡単です-MSSQLSERVERサービスがあるかどうか。

...そして、サーバー上のプロセスのリストから、インストールが開始したことに気付きました-実験が完了したと見なすことができることが明らかになりました。

さらなるカスタマイズは状況によって異なります。動作中のアプリケーションを緊急に表示する必要がある場合、何らかの方法でアプリケーションを取得してインストールします。

（緊急なしで）計画的なインストールがある場合は、ファイアウォールを事前に構成し、ユーティリティ（監視、バックアップ）をインストールできます。誰でも独自のオプションを使用できます。私たちが使用しているものから、AWStatsは最大の困難を引き起こす可能性があります。TestScriptのコードは小さなプログラムに似ていますが、これも解決可能です。

したがって、この時点で停止することにしました。私の意見では、誰もが自分の状況に適応できる良い例であることがわかりました。

予備結果

私の意見では、DSCはWindows Serverの次のバージョンを待たずに採用することができます。

このテクノロジーは、ドメインインフラストラクチャのグループポリシーを完全に置き換えることはできませんが、特定の利点があります。

構成サーバーを使用して、手動モードと自動モードの両方で使用できます。
Active Directoryの存在に関係なく使用することも、グループポリシーと一緒に使用することもできます。
構成ディレクトリはバージョン管理システムに配置できます。
Powershell 5.0のリリースにより、追加モジュールを使用する便利な方法が得られました-powershellgallery.comを参照してください。コミュニティによって作成されたモジュールはすでに多数あります。おそらく、それらの中には既に私の例のスクリプトを置き換えることができるものがあります。

この記事の例ではエラーが発生する可能性があり、おそらくより効果的なソリューションがあることに注意してください。

最後の重要な注意事項 ：私が理解したように、セットアッププロセス中に必要な再起動の問題は、新しいバージョンであっても解決策はありません。したがって、上記の構成は2つのパス（2012R2と2016の両方）で適用され、コンポーネントのインストールによって中断され、再起動が要求されます。次に、構成のアプリケーションを再度開始する必要があります。

便利なリンク

この記事のすべての例は、Githubのプロジェクトにあります

https://github.com/nelsh/DSC-WS2012R2
Windows PowerShellの望ましい状態の構成の概要

https://technet.microsoft.com/en-us/library/dn249912.aspx
Powershell 5.0およびDSCの近い将来

https://www.powershellgallery.com/

http://blogs.msdn.com/b/powershell/archive/2015/09/15/updated-dsc-resource-kit-available-in-powershell-gallery.aspx

Windows Server 2012 R2の望ましい状態構成の実際の使用

前文