PowerShell DSC: объявляем желаемое состояние - Windows сама себя выровняет

На прошлой неделе Microsoft официально объявила о DSC - Desired State Configuration - в составе Windows Management Framework 4.0. Для тех, кто работает с Linux-инфраструктурой, это примерно как Puppet, но для Windows, и не надо ставить ничего стороннего.

Мы про Puppet писали в феврале, потом про Ansible в июне. Оба инструмента на Windows либо не работают совсем, либо работают через костыли. DSC - это первый раз, когда Microsoft сама говорит: ладно, конфигурации как код, мы поняли.

Как это устроено

Идея та же, что в Puppet: не пишем скрипт «сделай так», а описываем, каким должен быть сервер. DSC берёт этот манифест - они называют его конфигурацией - и приводит машину в нужное состояние. Если что-то уже в порядке, трогать не будет. Если ушло в сторону - поправит.

Конфигурация пишется на PowerShell DSL. Выглядит примерно так:

Configuration WebServer {
    Node "SRV-WEB-01" {
        WindowsFeature IIS {
            Ensure = "Present"
            Name   = "Web-Server"
        }
        File SiteRoot {
            Ensure          = "Present"
            Type            = "Directory"
            DestinationPath = "D:\Sites\Default"
        }
        Service W3SVC {
            Name      = "W3SVC"
            State     = "Running"
            StartupType = "Automatic"
        }
    }
}

Запускаешь WebServer, получаешь MOF-файл - это промежуточный формат, который LCM (Local Configuration Manager) понимает и применяет. LCM живёт на каждой Windows-машине начиная с WS2012, с выходом WMF 4.0 он серьёзно прокачался.

Первый боевой случай

Один из клиентов на сопровождении накопил годами приличный зоопарк: три разные GPO отвечали за одно и то же «базовое состояние» сервера, плюс два login-скрипта, которые доделывали то, что GPO не умела. Какой из них что делает - надо было держать в голове или лезть в документацию, которую никто не обновлял.

Мы написали один DSC-манифест, который описывал то же самое: нужные фичи Windows включены, ненужные отключены, нужные службы запущены, нужные файлы и папки на месте с правильными правами. Прошлись по серверам, убедились, что конфиг применяется чисто - и отключили все три GPO и оба скрипта.

Итого: источник правды один, читается как список требований, версионируется в git.

Что понравилось, что насторожило

Идемпотентность из коробки. Это главное. Можно применять манифест хоть каждые пятнадцать минут - LCM проверит состояние и сделает только то, что расходится с описанием.

Не нужен агент. Точнее, LCM встроен в ОС. Pull-режим требует файлового сервера или специального DSC Pull Server, push-режим работает без него - запустил Start-DscConfiguration и готово.

Библиотека ресурсов скудная. Из коробки есть File, Registry, Service, WindowsFeature, Package, User, Group - базовый набор. Для чего-то специфичного придётся писать свой ресурс на PowerShell или ждать, пока сообщество напишет. Puppet в этом плане куда богаче - на Puppet Forge уже тысячи модулей.

MOF как промежуточный формат - не самая очевидная идея. Иногда ошибку компиляции в MOF понять сложнее, чем ошибку в самой конфигурации.

Отладка в push-режиме пока оставляет желать лучшего. Если что-то пошло не так - лезешь в журнал событий, ищешь нужную запись среди прочего шума. Нормального вывода типа puppet agent --test --noop не хватает.

Куда это ведёт

DSC органично ложится туда, где уже есть PowerShell-инфраструктура и Windows-парк. Для смешанных сред Linux + Windows он закрывает ровно половину - ту, где Puppet и Ansible работали плохо.

Пока это первый анонс, WMF 4.0 только выходит. Смотреть на DSC в продакшн со сложными сценариями рановато - библиотека ресурсов маленькая, инструментарий сырой. Но для базовых вещей - фичи, службы, файлы, реестр - уже вполне применимо. И главное: это наконец-то нативный подход, а не надстройка поверх групповых политик.

Планируем обкатать на ещё нескольких клиентах с однородными Windows-парками и посмотреть, как будет вести себя pull-режим в более-менее живой инфраструктуре.