Относительно недавно обновился базовый пакет с основными библиотеками DSC. И вот что я хочу сказать по этому поводу. DSC отлично подходит для разработки и разработчиков. И очень плохо подходит для поддержки и системных администраторов.
Я вижу следующие стоп-факторы в использовании DSC как инструмента автоматизации:
- DSC по своей архитектуре работает исключительно в рамках конкретного хоста. Это приводит к тому, что если мы хост перегружаем, то логика работы движка DSC сбрасывается. DSC начинает заново выполнять полученный от администратора скрипт, а не с того момента, где в скрипте возникла команда на перезагрузку сервера. Потенциально, этот стоп-фактор может снять настройка ActionAfterReboot LCM’а, которая появилась в Windows Server 2016
- DSC не имеет штатного инструмента для постановки выполнения скрипта на паузу. Администратор должен переписывать базовые модули, чтобы этот инструмент можно было таки использовать
- DSC по своей архитектуре постоянно проигрывает скрипт, который получил от администратора. Если у нас в скрипте будет заложена стандартная логика “вывести ресурс из под нагрузки” ⇒ “обновить” ⇒ “вернуть ресурс в работу”, то эта логика будет постоянно проигрываться движком DSC. Ни один штатный ресурс (за исключением разве что xExchange) не предусматривает проверки версионности конфигурации. Следовательно, сразу после завершения скрипта нужно будет быстро-быстро бежать и затирать всю полученную перед обновлением конфигурацию, как это описано, например, тут
Поэтому, коллеги, не верьте политруку, политрук лжёт 🙂
Ссылки:
DSC Resource Kit Release June 2018
How to remove all PowerShell DSC configuration documents (MOF files)?
мне кажется ты как то не так используешь DSC – он же, по сути, замена GPO. Не надо его использовать для выполнения разовых команд.
Не комиссар, а политрук.
2Kirill Nikolaev
Кирилл, а ты по нему документацию читал? Видел как его позицируют? 🙂 Как средство деплоя (не только). Раз назвался груздем – полезай в кузов 😉
2Dima Razbornov
И правда, что это я. Сейчас поправлю 🙂