Чем отличается DSC от обычных сценариев?

Я смотрел видео на ITPro.tv о конфигурации желаемого состояния PowerShell DSC . Они представляют его и эффективно запускают сценарий. Тем не менее, это было их первое (реальное) представление сценариев, поэтому я не заметил разницу между DSC и обычными сценариями. Я уже делал некоторые обычные сценарии, и, возможно, у них просто не было такого замечательного примера; казалось, что обычный скрипт может установить роль / функцию и просто скопировать некоторые файлы. Я не видел выгоды от DSC по сравнению с простым сценарием. Помимо машины, способной опросить какие-то изменения, которые они не охватывали на практике, просто в теории.

Каковы преимущества DSC по сравнению с традиционными сценариями; например "установить роль, скопировать файл"?

• С PowerShell вы можете подключаться к удаленным машинам и предлагать им делать что-то, так что это не только для DSC.
• С DSC кажется, что вы делаете какую-то компиляцию для создания файла mof, а затем запускаете его из оболочки после скрипта, что кажется ненужным шагом.
• Обзор MSDN читается как обзор PowerShell, и я не вижу , отличительные характеристики.

Как вы уже сказали, вы можете делать практически все, что делаете с 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.