Смотрел на ITPro.tv видео про Конфигурация желаемого состояния PowerShell DSC. Они вводят его и эффективно запускают сценарий. Однако это было их первое (настоящее) введение сценариев, поэтому я не заметил разницы между DSC и обычными сценариями. Раньше я делал несколько обычных сценариев, и, возможно, у них просто не было такого замечательного примера; казалось, что обычный скрипт может установить роль / функцию и скопировать некоторые файлы. Я не видел преимущества DSC по сравнению с простым скриптом. Кроме того, что машина могла опрашивать какие-то изменения, которые они не охватывали на практике, а только теоретически.
Каковы преимущества DSC перед традиционными скриптами; например «установить роль, скопировать файл»?
Как вы уже сказали, вы можете делать практически все, что делали бы с DSC, с прямым кодом PowerShell.
Но DSC - это управление конфигурацией.
Управление конфигурацией - это шаблоны и методы использования кода и различных систем для обеспечения того, чтобы система находилась в определенном состоянии. Ссылка 1 2
Одна важная вещь в управлении конфигурациями - идемпотентность. Это означает, что код, описывающий вашу систему, в системе управления конфигурацией будет периодически проверяться и запускаться в вашей системе. Многие базовые сценарии плохо спроектированы и будут работать правильно в первый раз, когда вы используете их для настройки системы, но в следующий раз они будут ошибаться, дублировать вещи и так далее. В идеале системы управления конфигурацией будут абстрагироваться от значительной части кода тестирования и проверки состояния, который вы должны вручную добавить в сценарий, чтобы сделать его идемпотентным.
Еще одна важная вещь о DSC и многих других системах управления конфигурациями - это создание повторно используемые ресурсы которые действительно делают ту работу, которой можно поделиться с кем угодно в мире. Таким образом, ваша фактическая «конфигурация» должна состоять лишь из нескольких конкретных деталей, специфичных для вашей среды. Это также означает, что вам нужно писать намного меньше кода, поскольку вы можете повторно использовать вещи, которые использовались и проверялись многими другими людьми.
Я привел несколько ссылок выше, но в Интернете можно найти много хороших веб-сайтов, посвященных теории систем управления конфигурациями. Общая теория применима ко всем системам управления конфигурацией (puppet, chef, dsc, ansible и т. Д.), Ее, безусловно, стоит изучить и использовать в большинстве сред.
Предлагаю вам взглянуть на https://docs.microsoft.com/en-us/powershell/dsc/dscforengineers#i-have-powershell-why-do-i-need-desired-state-configuration.
Я занимаюсь DevOps как руководитель проекта C # еще до того, как он так назывался. Я написал десятки таких сценариев типа «настроить общий ресурс», «создать приложение в IIS» и «проверить, установлен ли IIS Rewrite». Обычно меня просят сделать это кто-то, кто думает: «Это всего лишь одна строка кода, чтобы сделать X». Но что, если вещь уже существует? Что делать, если шаги 1,3 уже существуют, а шаги 2,4 нет, или шаг 2 (скажем, пул приложений IIS) настроен не так, как в прошлый раз?
Да, DSC требует, чтобы вы называли каждую «часть» скрипта. Что сначала кажется утомительным. Но если вы не назовете его, то механизм DSC и поставщики не смогут сказать вам, какая часть скрипта занимает слишком много времени или какая часть скрипта дает сбой.
Если вы занимаетесь папками, IIS, развертыванием приложений или функциями Windows, я настоятельно рекомендую вам потратить несколько дней на изучение DSC.