PowerShell Desired State Configuration: назначение, возможности и использование

Вместе с Windows Server 2012 R2 представлена и новая версия PowerShell 4.0, среди всех нововведений расширение Desired State Configuration является ключевым.

Появившись, PowerShell упростил многие аспекты администрирования Windows, ведь теперь можно выполнять команды любой сложности на неограниченном количестве систем. С ростом популярности виртуализации и облачных технологий он стал еще более актуален. Но не хватало инструмента позволяющего контролировать конфигурацию. То есть, мы можем запросто указать какие роли и компоненты необходимо установить, но чтобы сказать, что чего-то в системе быть не должно или контролировать последовательность операций текущими средствами уже так не просто. Даже при использовании готовых решений PowerShell Deployment Toolkit (PDT), требуется дальнейшее конфигурирование вручную. И главное, администраторы Linux уже давно используют инструменты централизованного управления вроде Puppet и Сhef, которые позволяют при помощи ранее созданных скриптов полностью контролировать состояние систем. Теперь подобная возможность реализована и для Windows. Идея “continuous deployments” (непрерывного развертывания) для Windows с появлением нового инструмента приобретает четкие очертания.

Возможности PowerShell Desired State Configuration

Новая функция PowerShell 4.0 — Desired State Configuration (DSC, Служба настройки требуемого состояния) кроме классических операций (управление ролями и компонентами, реестром, переменными среды, каталогом, процессами, сервисами, учетными записями и выполнение сценариев PS) позволяет узнать текущую конфигурацию узла и исправить ее, если она не соответствует требуемому, или вернуть предыдущее состояние ОС. Причем DSC будет частью Windows Management Framework (WMF) 4.0 (на момент написания статьи была доступна версия Preview), а значит, он будет работать не только в Windows Server 2012 R2 и 8, но и в более ранних Windows 7 SP1, Windows Server 2008 R2 SP1 и 2012.
В новых ОС функция PowerShell Remoting включена по умолчанию, в более ранних версиях нужно не забыть разрешить подключения:

PS> Enable-PSRemoting -Force

Процесс настройки систем при помощи DSC состоит из трех этапов. Вначале следует подготовить сценарий в котором указывается конфигурация компьютеров — какие элементы должны или не должны быть установлены. Подойдет любой другой инструмент или язык третьей стороны, любая версия PowerShell, но естественно рекомендуется 4.0 в которой добавлены расширения синтаксиса, упрощающие процесс. Следующим шагом является компиляция MOF (Management Object Format) файла, в котором определяются WMI классы и их свойства. Причем файл генерируется персонально, т.е. если сценарий описывает несколько систем, каждая получит только свой файл с конкретными установками. Файл распространяется на другие сервера при помощи PowerShell Remoting, групповых политик, централизованного URI откуда его забирают клиенты или любыми другими способами (в т.ч. и вручную), где он анализируется и используется для изменения настроек. Реализованы два метода обновлений:

Последний вариант очень интересен с точки зрения масштабируемости, так как позволяет легко контролировать состояние любого количества систем, включая виртуальные машины и мобильных клиентов. И в отличие от групповых политик, настройки для целевых систем указываются более гибко и тонко.
Все действия на конечной системе выполняются при помощи ресурсов или провайдеров (по имени каталога), которые собственно и устанавливают роли и компоненты, параметры среды, копируют файлы, изменяют реестр, управляют сервисами и учетными записями, выполняют произвольные сценарии и т.д. Причем можно указывать зависимость ресурсов друг от друга, тогда некоторая настройка будет ожидать успешного окончания предыдущей операции. На сегодня таких провайдеров 12, подробно они описаны в документации (technet.microsoft.com/en-us/library/dn249921.aspx), просмотреть их можно в C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PSProviders (рис.1). В указанной папке нет каталога соответствующего File ресурсу, который является «встроенным». Очевидно, что это начало, ведь пока реализованы только провайдеры для первичных и самых востребованных операций, но в будущем их количество наверняка увеличится.
Файлы ресурсов DSC представляют собой модули PowerShell
По сути описания ресурсов представляют собой обычные модули PowerShell, поэтому их можно изменить по своему усмотрению и (что очень важно) создать своего провайдера. Это гораздо проще, чем, к примеру, написать расширение групповой политики.
Теперь разберем подробнее.

Конфигурация DSC

Модуль DSC реализует 12 командлетов и новую функцию Configuration, которая и описывает все установки. Все их вместе со справкой удобнее просмотреть в интерфейсе PowerShell ISE. Чтобы просмотреть доступные параметры, которые может принять Configuration следует ознакомиться с описаниями ресурсов. Разработчику также доступны и все функции PowerShell, здесь абсолютно никаких ограничений нет, можно задавать любые условия и прописывать любые команды. Мы же разберем классический пример, чтобы просто понять как работает DSC. Для этого установим роли IIS и Net Framework 4.5, скопируем файлы в рабочий каталог веб-сервера.
Командлеты, скрипт и создание MOF файла

	Configuration WebServer
{
 
Node (“WinServ-01”,“localhost”) # указываем узлы
 
{
	WindowsFeature IIS # название Role-провайдера и произвольное уникальное имя
{
 
# Ensure показывает, что роль будет добавлена (по умолчанию), чтобы удалить, необходимо установить в Absent
 
	Ensure = “Present” 
	Name = “Web-Server” # имя устанавливаемой роли полученного Get-WindowsFeature
}
 
WindowsFeature ASP
{
	Ensure = “Present”
	Name = “Web-Asp-Net45”
}
 
File DirCopy # название File-провайдера и произвольное имя
{
            Ensure = "Present"
            Type = "Directory" # по умолчанию используется File
            Recurse = $true # рекурсивный обход
	# исходный и конечный каталоги
            SourcePath = "C:\Demo" 
         	DestinationPath = "C:\inetpub\wwwroot"
# требует чтобы роль Web-Server была уже установлена, указывается название и имя ресурса
		Requires = "[WindowsFeature]IIS" 
}
}
}
 
# вызываем функцию
WebServer

Имя компьютеров жестко вшито в скрипт, но при необходимости их можно задавать в строке вызова, используя конструкцию:

param($ComputerName)
Node $ComputerName

При вызове функции при помощи OutputPath можно указать каталог, в который будет сохранен результат, иначе будет использован текущий:

WebServer -OutputPath "c:\dsc"

Сохраняем скрипт под любым именем (например, WebServer.ps1). Теперь чтобы получить MOF файл необходимо просто его выполнить (см.рис.2):

PS> ./WebServer.ps1

В текущем каталоге будет создан подкаталог WebServer и в нём два файла, вида «имя_узла.mof» (в примере WinServ-01.mof и localhost.mof). Можно открыть их в Блокноте (рис.3), чтобы изучить внутренние механизмы и поправить при необходимости.

MOF файл изнутри
Выполним задание в локальной системе:

PS> Start-DscConfiguration -ComputerName localhost -Path WebServer -Credential Get-Credential

После запроса учетных данных, в консоли будет показана информация о статусе задании, появится приглашение и можно вводить следующую команду. Чтобы получить больше информации по операциям следует добавить «-Wait -Verbose». Через некоторое время можно увидеть, что роли и компоненты установлены, а файлы скопированы. Анализ системного журнала также покажет новые события:

PS> Get-WinEvent -LogName Microsoft-Windows-PowerShell/Operational | OutPut-GridView

Чтобы убедиться в актуальности конфигурации следует использовать командлет «Test-DscConfiguration». В локальной системе его достаточно ввести без параметров. Для удаленной, следует получить параметры CIM сессии (Common Information Model — клиентский объект, обеспечивающий соединение локального или удаленного компьютера, содержит информацию об имени компьютера, протоколе, ID сессии и идентификатор):

PS> $Session = New-CimSession -ComputerName “WinServ-01” -Credential Get-Credential
PS> Test-DscConfiguration –CimSession $Session

Коммандлет Restore-DscConfiguration позволяет восстановить предыдущие настройки системы. Принцип запуска аналогичен Test-DscConfiguration.
Как видите всё очень просто. Теперь можно быстро задавать настройки любому количеству ПК.

Настройка среды DSC

За применение настроек на каждом узле отвечает «движок» PowerShell DSC Local Configuration Manager, который определяет метод (Push или Pull) и интервал обновлений, имя сервера для Pull, а также сервисные функции, вроде автоматической перезагрузки по необходимости или установки сертификатов. Установки по умолчанию можно получить при помощи командлета (рис. 4):

PS> Get-DscLocalConfigurationManager

Текущие настройки PowerShell DSC Local Configuration Manager
Или, если интересуют внутренние переменные можно прочитать значение объекта WMI:

PS> Get-WmiObject -Namespace "Root\Microsoft\Windows\DesiredStateConfiguration" -List

Устанавливаются параметры также средствами DSC, для этого необходимо создать скрипт:

Configuration LocalConfigurationManager
{
    Node "localhost"
    {
        DesiredStateConfigurationSettings DscSettings
        {
	AutoRestartMode = "NoAutoRestart" 
            ConfigurationMode = "ApplyOnly"
            ConfigurationRefreshFrequencyInSeconds = 600
        }
    }
}
LocalConfigurationManager -OutputPath "С:\dsc"

Выполняем его, чтобы создать MOF файл:

PS> ./LocalConfigurationManager.ps1

И теперь применяем установки:

PS> Set-DscLocalConfigurationManager -Path "С:\dsc"

В примере только локальный узел, но естественно, что таким образом можно изменить установки PowerShell DSC Local Configuration Manager сразу на всех системах.

Настройка Pull сервера

Pull-сервер представляет собой простое веб-приложение построенное с использованием технологий WMF и выполняемое через IIS. Его легко развернуть при помощи мастера установки ролей и компонентов, в котором необходимо выбрать пункт PowerShell Desired State Configuration Service, находящийся в Windows PowerShell. Или введя команду:

PS> Install-WindowsFeature DSC-Service

После установки WMF 4.0 такой сервер может работать и в предыдущих версиях ОС Windows Server 2008 R2 SP1 и Windows Server 2012. Единственное что, в Windows Server 2008 R2 SP1 некоторые зависимости придется устанавливать вручную:

PS> Add-WindowsFeature Web-Server
PS> Add-WindowsFeature Web-Http-Tracing 
PS> dism /online /enable-feature:ManagementOdata
PS> Add-WindowsFeature NET-Http-Activation
PS> Add-WindowsFeature Web-ASP-NET

Теперь необходимо настроить веб сайт. Пойти можно несколькими путями, каждый выбирает какой удобнее, разберем общий принцип. По умолчанию все необходимые файлы находятся в C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PullServer. Можно использовать этот каталог или создать новую папку в корневом каталоге веб-сервера. Второй вариант удобнее, так как в конфигурационном файле PSDSCPullServer.config «вшит» путь С:\inetpub\wwwroot\PSDSCPullServer.
Поэтому создадим каталог wwwroot\PSDSCPullServer и копируем сюда все файлы. В подкаталог Configuration копируем файл Devices.mdb. Файл PSDSCPullServer.config переименовываем в web.config. Далее настройки можно создать вручную или воспользоваться вспомогательным скриптом SetupIISConfig.ps1 из комплекта шаблонов Management OData IIS Extension (getcodesamples.com/src/EB1209A8/38127567).
Вызываем «Диспетчер IIS» и создаем новый пул приложений и новый сайт (или используем сайт по умолчанию) в настройках которого указываем каталог PullServer созданный ранее. И разблокируем разделы.

> cd C:\Windows\System32\inetsrv\
> .\appcmd.exe unlock config /section:access
> .\appcmd.exe unlock config /section:anonymousAuthentication
> .\appcmd.exe unlock config /section:basicAuthentication
> .\appcmd.exe unlock config /section:windowsAuthentication

Сервис готов можно его указать в настройках PowerShell DSC Local Configuration Manager

ConfigurationMode = "Pull"
DownloadManagerName = "WebDownloadManager"
DownloadManagerCustomData = @{ServerUrl = "http://<pullserver>:8080/PSDSCPullServer/PSDSCPullServer.svc" }
PullActionRefreshFrequencyInSeconds =  60
</pullserver>

***

Можно прогнозировать DSC хорошие перспективы как системы управления конфигурацией Windows. Он практически полностью способен заменить групповые политики (хотя скорее они будут сосуществовать параллельно, дополняя друг друга), но более гибок. Также DSC хорошо масштабируется, удобен в плане контроля версий и главное практически не имеет ограничений. В Интернет стали появляться готовые конфигурации, особенно их много на GitHub, примеры для обучения найти легко. Единственный минус в данный момент, незаконченная документация, к тому же не редко вводящая в заблуждение из-за недействительных параметров, работавших в бета версии ОС. И пока, чтобы разобраться, приходится смотреть код модулей. Будем надеяться, что эту проблему скоро решат.

Теги:

Понравилась статья? Оставьте комментарий или подпишитесь на RSS рассылку.

Комментарии

Комментариев пока что нет

Оставить комментарий

(required)

(required)