Общие сведения о роли DSC в конвейере CI/CD

В этой статье описываются типы подходов для объединения конфигураций и ресурсов. Целью каждого сценария является уменьшение сложности в том случае, когда для достижения конечного состояния сервера развертывания лучше всего использовать несколько конфигураций. В качестве примера можно привести несколько команд, работающих над развертыванием сервера: владелец приложения, поддерживающий состояние приложения, и основная команда, выпускающая изменения для базовых конфигураций системы безопасности. Здесь описаны особенности каждого подхода, включая преимущества и риски.

Типы методов совместной разработки

Для реализации этой концепции существует два решения, встроенных в локальный диспетчер конфигураций.

Концепция	Подробные сведения
Частичные конфигурации	Документация
Составные ресурсы	Документация

Понимание влияния каждого подхода

Любое из этих решений можно использовать для управления результатом развертывания сервера. Однако существует значительная разница, касающаяся влияния каждого подхода.

Частичные конфигурации

При использовании частичных конфигураций локальный диспетчер конфигураций настраивается для управления несколькими конфигурациями независимо друг от друга. Конфигурации компилируются независимо друг от друга и затем назначаются узлу. Для этого необходимо заранее настроить LCM с именем каждой конфигурации.

Частичные конфигурации предоставляют двум или более командам полный контроль над конфигурацией сервера (часто без преимуществ взаимодействия или совместной работы).

Клиенты сообщили, что это может привести к конфликтам ресурсов, непреднамеренным переопределениям и, в конечном счете, потере реального контроля над конфигурацией ресурса.

Кроме того, клиенты отметили, что в этой модели изменения конфигураций, находящихся под контролем команд, вряд ли пройдут полное тестирование в рамках конвейера выпуска, что приведет к непредвиденным результатам в рабочей среде.

Крайне важно, чтобы для оценки всех изменений на серверах использовался один конвейер.

На рисунке ниже команда Б выпускает частичную конфигурацию и передает ее команде А. Команда А выполняет свои тесты на сервере с обеими примененными конфигурациями. В этой модели только один центр имеет разрешение на внесение изменений в рабочей среде.

Если требуются изменения от команды Б, ее участники должны отправить запрос на вытягивание в среду управления версиями команды А. Затем команда А проверит изменения с помощью автоматизации тестирования и выпустит конфигурацию в производство, если будет уверена в том, что изменения не вызовут ошибок в приложениях или службах, размещенных на сервере.

Составные ресурсы

Составной ресурс — это просто конфигурация DSC, упакованная в виде ресурса. Особых требований к настройке LCM для принятия составных ресурсов не существует. Ресурсы используются в новой конфигурации и в результатах одной процедуры компиляции в одном MOF-файле.

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

Configuration Name
{
  File 1
  {
    Ensure = "Present"
    Path = "c:\inetpub\file1.zip"
    Source = "http://uri/file1.zip"
  }
  Service A
  {
    Ensure = "Present"
    Name = "ServiceA"
    Status = "Running"
  }
  SecurityBaseline Settings
  {
    Ensure = "Present"
    Datacenter = "NorthAmerica"
  }
}

Составные ресурсы повышают уровень композиции и совместной работы с помощью конвейера при одновременном формировании операционной готовности.

Возможно, вы уже используете составные ресурсы, не осознавая этого. Примером является ServiceSet. Этот ресурс управляет состоянием нескольких служб Windows, не обращаясь к ним по отдельности. Свойство Name принимает массив строк для предоставления имени каждой службы. После компиляции конфигурации MOF-файл будет содержать уникальный раздел службы для каждого имени, переданного ServiceSet.

Организации могут иметь агентов или промежуточное ПО, которое должно быть установлено на каждом сервере. Составной ресурс является лучшим вариантом для управления зависимостями, установкой и настройкой таких средств и служебных программ.

Разработкой конфигурации в соответствии с требованиями занимается пользователь или команда, ответственные за решения для нескольких серверов. Затем конфигурация упаковывается в виде составного ресурса согласно инструкциям в документации по составным ресурсам. Наконец, новый составной ресурс следует опубликовать в расположение, например в общую папку или канал NuGet, где команды разработки приложений могут использовать его в своих конфигурациях.

При каждом выпуске новой версии команда увеличивает номер версии в манифесте модуля для составного ресурса. Команды разработчиков приложений включают составной ресурс в конфигурацию, которую они создают для управления зависимостями приложения. При выпуске новой версии ресурса команды по эксплуатации и обеспечении безопасности уведомляют команды разработчиков приложений о новых изменениях.

Команды разработчиков приложений могут запускать выпуск в рабочую среду, даже если единственным изменением является изменение базовых конфигураций. В этом случае существует возможность оценки влияния на приложения до возникновения риска сбоя службы.

Примечание

В отзывах об использовании составных ресурсов содержатся критические замечания, указывающие на то, что при внесении изменений требуется скомпилировать и выпустить новый MOF-файл. Это сделано намеренно. Каждый новый выпуск конфигурации должен содержать статическую ссылку на определенную версию каждого ресурса и должен быть протестирован перед развертыванием на узлах сервера в рабочей среде. Процесс тестирования и выпуска изменений из системы управления версиями позволяет сформировать безопасную среду для выпуска изменений небольшими, но часто выходящими пакетами.