Декларативное управление конфигурацией Windows через DSC — IaC начинается с dsc.exe

«Хочу заново собрать стандартный ПК», «хочу ещё раз прогнать установку, которая оборвалась на середине», «хочу найти настройки, которые кто-то поменял руками». Когда клиентами и серверами Windows управляют инструкциями и сценариями, трудно именно воспроизвести те же настройки и удержать их.

Инструкция расходится с реальностью, если не продолжать отслеживать изменения после выполнения. У BAT и PowerShell, чтобы повторный запуск не дал двойного применения или ошибки, проверки существования и ветвления приходится писать самим. Этот труд DSC (Desired State Configuration) переносит на управление, где пишут не «шаги», а «желаемое состояние».

В статье речь о Microsoft DSC v3 (dsc.exe), который в 2025 году появился как командная утилита без зависимости от PowerShell. Это входная точка, чтобы сами клиенты и серверы Windows вести декларативным IaC (Infrastructure as Code) — примерно так, как Terraform и Ansible используют в Linux и в облаке.¹

Аудитория — разработчики и сотрудники ИТ, которые хотят уйти от инструкций и сценариев в управлении конфигурацией Windows. Исходные условия: Windows 10/11, DSC 3.0 и новее, базовые операции PowerShell; сложность средняя. Имена адаптеров начиная с DSC 3.2 и нужную версию WinGet разбираем в соответствующих местах отдельно.

1. Сначала вывод — пишем состояние и применяем после проверки

Если декларативное управление конфигурацией Windows начинаете сейчас, берите Microsoft DSC v3 (dsc.exe). В YAML/JSON пишут «желаемое состояние», а сравнение с текущим и применение оставляют DSC и ресурсам. Одну и ту же конфигурацию можно применять повторно: к пунктам, которые уже в желаемом состоянии, ничего не делается. Это и есть идемпотентное управление.²³

Но «можно применять сколько угодно раз» и «это содержимое вообще допустимо применять» — разные вещи. Сначала читают состояние, сверяют разницу и прогноз и только потом применяют. Кроме того, DSC v3 не резидентный агент, поэтому периодический аудит и восстановление проектируют отдельно.⁴¹

Читать удобно в таком порядке.

flowchart TB
    accTitle: От управления шагами к управлению состоянием
    accDescr: В сценарии-инструкции проверки существования и ветвления для повторного запуска пишут сами, а в DSC объявляют желаемое состояние, и сравнение с текущим плюс применение берут на себя DSC и ресурсы
    imp["Пишем шаги (BAT, PowerShell)"] --> guard["Сами реализуем проверки и ветвления"]
    dec["Пишем состояние (DSC)"] --> test["Сравниваем с текущим состоянием"]
    test --> set["Применяем только нужные пункты"]

Рис. 1: Ответственность за повторный запуск переносят с развилок в сценарии на объявление состояния и использование ресурсов.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 17, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Какой DSC вы читаете — четыре линии и то, чего в v3 нет

2.1. Герой статьи — самостоятельный dsc.exe

Поиск по «DSC» выдаёт четыре линии с разной записью и разным способом запуска. Сначала смотрите, о какой из них материал.⁵

Microsoft DSC v3 — не просто обновление модуля PowerShell DSC (PSDSC). Это другой продукт, переписанный с отвязанной зависимостью от PowerShell. Конфигурацию описывают данными JSON/YAML, ресурс можно реализовать на любом языке. Сам DSC работает на Linux, macOS и Windows.¹

flowchart TB
    accTitle: Родословная четырёх линий DSC
    accDescr: От PSDSC v1.1, встроенного в Windows PowerShell 5.1, ответвляются PSDSC v2 для PowerShell 7 и превью PSDSC v3 для Machine Configuration; отдельно от них переписанный без зависимости от PowerShell Microsoft DSC v3 становится действующим героем статьи
    v11["PSDSC v1.1 (встроен в WinPS 5.1)"] --> v2["PSDSC v2 (PowerShell 7)"]
    v2 --> v3ps["Превью PSDSC v3"]
    v11 -.->|"Переписан"| dsc3["Microsoft DSC v3 (dsc.exe)"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["Герой этой статьи"]

Рис. 2: Одно имя DSC, но поколение модуля PowerShell и самостоятельный dsc.exe нужно различать.

Дальше в статье «DSC» означает Microsoft DSC v3. Если в поиск добавить «DSC v3» или «dsc.exe», материалы старых поколений проще отделить. Как вызывать существующие ресурсы PSDSC — в главе 6.

2.2. v3 — не резидентная служба, которая помнит конфигурацию и чинит её сама

LCM (Local Configuration Manager) в PSDSC v1.1 был резидентным агентом: хранил конфигурацию, применял её по расписанию и восстанавливал автоматически. В DSC v3 LCM нет: это команда, которая работает, только когда её вызвали. Поставить dsc.exe и один раз применить конфигурацию недостаточно: последующие изменения сами собой не исправятся.¹

flowchart TB
    accTitle: Резидентный LCM в v1.1 против командной модели v3
    accDescr: В PSDSC v1.1 резидентный LCM хранил конфигурацию и выполнял периодический pull и автовосстановление, а DSC v3 только запускается как команда, поэтому каркас периодического запуска выбирают сами среди Планировщика заданий, CI и Machine Configuration
    v1["PSDSC v1.1: резидентный LCM"] --> pull["Хранит конфигурацию, периодический pull и автовосстановление"]
    v3["DSC v3: только запуск команды"] --> push["Каркас запуска готовите сами"]
    push -.-> ex["Планировщик заданий, CI, Machine Configuration"]

Рис. 3: В v3 «как конфигурировать» и «когда запускать» разделены; второе оставляют Планировщику заданий или вышестоящей платформе управления.

Это не просто урезание функций, а смена дизайна: способ запуска открыли современным инструментам. Но если ждать тот же pull server, что в v1.1, будет непривычно. Если нужно непрерывное принуждение, придётся выбрать площадку запуска: Планировщик заданий, CI, Machine Configuration. Конкретная эксплуатация — в главе 7.

3. Понять декларативную конфигурацию — сравнить шаги и состояние

3.1. Убрать из объявления проверки существования и ветвления

Пример: в реестре хранят режим работы приложения. Императивный PowerShell проверяет, есть ли ключ, при необходимости создаёт его и задаёт значение. Шаги, без которых повторный запуск небезопасен, ведёте сами.

# Императивно: пишем «шаги». Ветвления и порядок ведёте сами
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

В DSC то же требование становится объявлением состояния. Проверку существования и ветку создания на стороне объявления не пишут. Полный пример, где этот фрагмент стоит в resources документа конфигурации, — в главе 5.

# Декларативно: пишем «состояние». Как создать и исправить — работа ресурса
- name: Режим работы приложения
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

Разница не в том, что на PowerShell идемпотентность невозможна. Проверку и применение, которые вы писали в сценарии, поручают ресурсу. И на ПК, где установка оборвалась, и на уже настроенном можно заново применить одно и то же «желаемое состояние».²

3.2. get, test и set берёт на себя ресурс

В центре DSC стоит ресурс: для каждого объекта конфигурации — значения реестра, компонента Windows, переменной среды — он даёт операции. Пользователь пишет «что и каким должно быть», а «как настроить» оставляет ресурсу.⁶

dsc config set для конфигурации целиком сначала делает test каждого экземпляра и вызывает set только у тех, кто не в желаемом состоянии. Поэтому одну и ту же конфигурацию можно применять повторно.³

flowchart TB
    accTitle: Цикл сходимости через get, test и set
    accDescr: test сравнивает желаемое состояние из документа конфигурации с текущим; при отсутствии разницы ничего не делает, при наличии set применяет только разницу, а get позволяет проверить результат — идемпотентная сходимость
    doc["Документ конфигурации (желаемое состояние)"] --> test["test: сравнить с текущим"]
    test -->|"Разницы нет"| ok["Ничего не делать (идемпотентность)"]
    test -->|"Есть разница"| set["set: применить только разницу"]
    set --> get["get: проверить итоговое состояние"]

Рис. 4: При применении конфигурации целиком сначала сравнивают и меняют только нужные экземпляры ресурсов.

3.3. Не путать одиночный resource set и config set для конфигурации целиком

dsc resource set всегда вызывает set указанного ресурса. Есть ли предварительный тест — зависит от реализации ресурса и от implementsPretest в манифесте. Важно не считать, что предварительный тест config set есть и у resource set.³

flowchart TB
    accTitle: Предварительный тест: конфигурация целиком и одиночный вызов
    accDescr: config set тестирует каждый экземпляр и вызывает set только при необходимости, а resource set всегда вызывает set ресурса, и предварительный тест там зависит от реализации и манифеста
    config["config set"] --> test["Тестировать каждый экземпляр"]
    test --> needed{"Желаемое состояние?"}
    needed -->|"Да"| skip["set не вызывать"]
    needed -->|"Нет"| apply["Вызвать set"]
    single["resource set"] --> direct["Вызвать set ресурса"]
    direct -.-> impl["Предварительный тест — как реализовано"]

Рис. 5: Даже у одного set различают операцию над конфигурацией целиком, где DSC делает предварительный тест, и одиночный вызов, который передают ресурсу напрямую.

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

4. Первые операции — установить и наблюдать через get и test

4.1. Подготовить dsc.exe и посмотреть доступные ресурсы

Ставят двумя способами: распаковать архив с релизов GitHub и добавить в PATH либо на Windows поставить из winget, указав источник Microsoft Store.¹

# Найти и установить стабильную версию из источника Microsoft Store
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

После установки перечислите ресурсы, доступные в этой среде.

dsc resource list

Подготовить сам DSC и получить нужные ресурсы — разные проверки. Здесь находят полное имя типа, затем задают свойства для ввода. Если нужны ресурсы PSDSC старых поколений, смотрите и адаптеры в главе 6.

4.2. Сначала читать реестр в профиле пользователя

Ресурсы можно вызывать по одному, ещё не написав документ конфигурации. Следующий пример читает значение под HKCU через get и через test судит, соответствует ли оно желаемому. Ни то ни другое не меняет значение.⁷

# Получить текущее состояние (get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# Судить, соответствует ли желаемому (test) — изменений нет
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: Четыре операции команды dsc resource
    accDescr: Под командой dsc resource висят четыре операции: list показывает перечень ресурсов, get получает текущее состояние, test без изменений судит, соответствует ли оно желаемому, set применяет состояние (только у ресурсов с реализацией Set)
    cli["команда dsc resource"] --> l["list: перечень ресурсов"]
    cli --> g["get: получить текущее состояние"]
    cli --> t["test: только суждение, без изменений"]
    cli --> s["set: применить (ресурсы с Set)"]

Рис. 6: list ищет ресурс, get читает текущее значение, test сверяет разницу с объявлением, и только потом переходят к set.

Для set, который меняет машину целиком — HKLM, системные настройки — нужны права администратора. Первые пробы начинают с примера в профиле пользователя (HKCU и подобные) и перед операциями с изменением сверяют объект и права. Использование адаптера для ресурсов PSDSC линии Windows PowerShell тоже предполагает запуск от администратора.⁷ Как разделять пользователя запуска и конфигурацию — в главе 8.

5. Документ конфигурации — от объявления до проверки после применения

5.1. Собрать в YAML, «что и каким должно быть»

Документ конфигурации — YAML/JSON-файл, в котором объявляют сразу несколько экземпляров ресурсов. Минимум задают $schema и resources; у каждого экземпляра есть name (уникальное в документе отображаемое имя), type (полное имя типа ресурса) и properties (желаемое состояние).²

# standard-pc.dsc.config.yaml — желаемое состояние стандартного ПК
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: Режим работы приложения
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

Здесь объявление из главы 3 собрано в файл, а режим работы вынесен в параметр appMode. Значения, которые отличаются по отделу или среде, можно держать отдельно от тела конфигурации. parameters и variables сокращают повторные определения и позволяют выразить динамические значения. В выражениях используют подмножество функций шаблонов ARM.²

flowchart TB
    accTitle: Структура документа конфигурации
    accDescr: Документ конфигурации состоит из schema с URI схемы документа, parameters и variables, которые поглощают различия сред, и массива resources; у каждого экземпляра есть name, type и properties
    docroot["Документ конфигурации (YAML / JSON)"] --> sch["$schema: URI схемы документа"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources: массив экземпляров"]
    res --> inst["name, type, properties"]
    par -.-> inst

Рис. 7: Если схему документа, значения по средам и объявления ресурсов разделить, намерение настройки читается как данные.

Выгода данных в том, что «что должно быть настроено на этом ПК» можно ревьюить как YAML-дифф. Но «это данные» не значит «это безопасно». Ссылаемый ресурс меняет систему, поэтому проверка доверия из главы 8 тоже нужна.⁸

5.2. Идти в порядке test → what-if → set → get

Перед применением обязательно наблюдают. dsc config test сообщает, есть ли разница с желаемым состоянием; dsc config set --what-if показывает прогноз, ничего не меняя.⁴

flowchart TB
    accTitle: Четыре шага безопасного применения
    accDescr: Сначала dsc config test без изменений показывает, есть ли разница; параметр what-if у dsc config set показывает прогноз изменений; после согласия применяют set и проверяют результат через get
    t["dsc config test (есть ли разница)"] --> w["set --what-if (прогноз изменений)"]
    w --> s["dsc config set (применение)"]
    s --> g["dsc config get (проверка результата)"]

Рис. 8: Сначала смотрят разницу, затем прогноз изменений, применяют только когда это устраивает. В конце снова читают фактическое состояние.

# 1. Проверить, есть ли разница (без изменений)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. Показать прогноз, что изменится при применении (без изменений)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. Применить, когда прогноз устраивает
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. Проверить состояние после применения
dsc config get --file .\standard-pc.dsc.config.yaml

Смотрят разное. test — суждение о совпадении, what-if — прогноз изменений, get — получение фактического состояния. Если ресурс не реализует what-if сам, прогноз синтезируют из результата test, поэтому его нельзя принимать за измерение после применения.⁴

Такой порядок делает смену настроек не разовым броском: на каждом шаге можно решить. Идемпотентность и what-if не заменяют проверку прав при применении и доверия к ресурсу.

5.3. Если стартуете с уже живой среды — export ресурсов с поддержкой выгрузки

dsc config export — вход в обратную сторону: выписать текущую среду. Если во входном документе через --file перечислить ресурсы с поддержкой export, в стандартный вывод вернётся документ конфигурации со всеми существующими экземплярами этих ресурсов.⁹

# Передать входной документ с перечнем целевых ресурсов и сохранить текущий документ конфигурации
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

Выгрузить можно не любой ресурс; каждый тип ресурса во входном документе объявляют один раз. Полученную картину берут как отправную точку и решают, что вести как стандарт. export выписывает текущее состояние; считать его желаемым — решение эксплуатации.⁹

flowchart TB
    accTitle: От текущего состояния к объявлению того, чем управлять
    accDescr: Если во входном документе перечислить ресурсы с поддержкой export, получится документ конфигурации с существующими экземплярами; его содержимое проверяют и на стороне эксплуатации решают, какое состояние вести как стандарт
    input["Перечислить ресурсы с export"] --> export["dsc config export"]
    export --> current["Документ с существующими экземплярами"]
    current --> review["Проверить содержимое и выбрать стандарт"]
    review --> desired["Объявление состояния, которым управлять"]

Рис. 9: Выписать текущее состояние и решить, что принять как стандарт, — разные этапы.

6. Использовать существующие активы — адаптеры и WinGet Configuration

6.1. Ресурсы PSDSC вызывают адаптером под среду выполнения

То, что v3 — другой продукт, не делает существующие ресурсы PSDSC бесполезными. Через ресурсы-адаптеры их вызывают из документа конфигурации v3. В DSC 3.2 имена сменились, поэтому сверяйте версию установки с именами в материалах.¹⁰

Даже если сам DSC не зависит от PowerShell, существующий ресурс, вызванный через адаптер, работает в соответствующей среде PowerShell. Сторона Windows PowerShell использует встроенный PSDesiredStateConfiguration 1.1 и умеет совместимые сценарные, классовые и двоичные ресурсы.¹⁰

flowchart TB
    accTitle: Слои вокруг DSC v3
    accDescr: Слой оркестрации вроде winget configure и Azure Machine Configuration вызывает DSC v3; DSC v3 вызывает нативные ресурсы напрямую, а существующие ресурсы PSDSC — через ресурсы-адаптеры
    orch["winget configure, Machine Configuration"] --> dsc["dsc.exe (DSC v3)"]
    dsc --> native["Нативные ресурсы (Registry и др.)"]
    dsc --> adapter["Ресурсы-адаптеры"]
    adapter --> psdsc["Существующие ресурсы PSDSC (активы PowerShell)"]

Рис. 10: DSC v3 вызывает нативные ресурсы напрямую, а существующие активы PowerShell использует через адаптер.

6.2. В схеме v3 WinGet обработчиком указывают DSC v3

Вторая точка подключения — WinGet Configuration. Файлы .winget из статьи о комплектации ПК в схеме v3 тоже используют DSC v3 как обработчик. Нужны WinGet 1.11 и новее и процессор dscv3.¹¹

В metadata.winget.processor.identifier файла конфигурации указывают dscv3, а resources пишут прямо в корне документа. Содержимое — документ конфигурации DSC v3.

# WinGet Configuration v3 — внутри документ конфигурации DSC v3
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: Режим работы приложения
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

Существующий формат v2 нельзя передать dscv3 как есть. Файлы v2 с properties.configurationVersion: 0.2.0 и ресурсами внутри properties продолжают работать на прежнем обработчике. Чтобы посадить их на DSC v3, формат переносят по «Convert to v3» в официальном репозитории примеров.¹¹

То есть повторно использовать нужно разное. У PSDSC это вызов ресурса через адаптер, у WinGet — совпадение формата файла конфигурации и обработчика. Объявление состояния, которое изучаете на DSC v3, — общая основа от локального dsc.exe до winget configure при комплектации и до вышестоящих платформ вроде Machine Configuration.¹

7. Непрерывная эксплуатация — Git как источник истины и обнаружение дрейфа

7.1. Сначала автоматизировать только обнаружение и отделить его от восстановления

Документ конфигурации кладут в репозиторий Git. Если изменения ревьюят pull request, затем мержат и применяют, желаемая конфигурация и история её правок живут в одном месте. Управление, где отдельно догоняют инструкцию, сменяется управлением, где источником истины становится исполняемое объявление.

Когда после применения кто-то меняет настройки руками и они расходятся с объявленным состоянием, это дрейф конфигурации. Его обнаруживают периодическим запуском dsc config test. test ничего не меняет, поэтому обнаружение и восстановление можно разделить. Сначала автоматизируют только обнаружение; восстановление через set делают после сверки разницы.

flowchart TB
    accTitle: Цикл управления конфигурацией с Git как исходной точкой
    accDescr: Документ конфигурации в репозитории Git ревьюят через pull request, затем применяют; периодический test из Планировщика заданий или CI обнаруживает дрейф; разницу смотрят и либо восстанавливают, либо возвращаются к обновлению конфигурации
    git["Репозиторий Git (документ конфигурации)"] --> pr["Изменения ревьюят в pull request"]
    pr --> apply["Применить через dsc config set"]
    apply --> sched["Периодический запуск: dsc config test"]
    sched -->|"Обнаружен дрейф"| judge["Сверить разницу и выбрать действие"]
    judge -.->|"Конфигурация верна"| fix["Восстановить через set"]
    judge -.->|"Верна реальность"| git

Рис. 11: Объявление ревьюят и применяют, периодический test ловит разницу. Восстанавливать или обновлять объявление решают по содержимому.

Дрейф не всегда ошибка. Если на месте сделали нужное изменение, ПК не возвращают назад: обновляют документ конфигурации, ревьюят и мержат. Если верно объявление — восстанавливают через set. В обоих случаях дисциплина одна: источник истины лежит в Git.

7.2. Отличать «проверить не удалось» от «есть расхождение»

В периодическом запуске недостаточно считать успехом сам факт, что команда стартовала. Следующий пример различает сбой выполнения DSC, ошибку проверки части ресурсов и дрейф и во всех случаях завершается ненулевым кодом.

# Для периодического запуска: отличить сбой самого test, ошибку отдельного ресурса и дрейф; во всех случаях выходить с ненулевым кодом
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "Сам запуск dsc config test завершился сбоем (код завершения: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # Сбой проверки документа или ненулевой код части ресурсов. Проверка не дошла до конца — не сообщать, что всё здорово
    Write-Error "Проверка части ресурсов завершилась ошибкой. Смотрите messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "Обнаружен дрейф конфигурации"
    exit 1
}

flowchart TB
    accTitle: Отличать сбой периодической проверки от дрейфа
    accDescr: В примере периодической проверки смотрят код завершения и вывод DSC, затем hadErrors на ошибки проверки, и если inDesiredState равен false — сообщают о дрейфе
    run["Код завершения и вывод DSC"] --> q1{"Сбой запуска или нет вывода?"}
    q1 -->|"Да"| error["Сбой проверки (код 2)"]
    q1 -->|"Нет"| q2{"hadErrors?"}
    q2 -->|"Да"| error
    q2 -->|"Нет"| q3{"inDesiredState равен false?"}
    q3 -->|"Да"| drift["Обнаружен дрейф (код 1)"]
    q3 -->|"Нет"| ok["В этой проверке разницы нет"]

Рис. 12: Ошибку проверки не сообщают как «разницы нет». Дрейф — это результат, когда проверка смогла отработать и состояния не совпали.

Пример рассчитан на базовую форму из главы 5, где обычные экземпляры ресурсов перечислены напрямую. Перед тем как встраивать в мониторинг, сверьте форму результата и поведение при ошибках с той конфигурацией и теми ресурсами, которые берёте. Сбой проверки документа и ошибки ресурсов, на которые указывает hadErrors, нельзя считать здоровым состоянием.

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

LCM в DSC v3 нет, поэтому кто и когда запускает test, решают отдельно. На клиенте можно взять Планировщик заданий, на парке серверов — CI-раннер. Проектирование запуска без интерактивного пользователя — в отдельной статье.

В организациях, которые уже сводят управление в Azure, Machine Configuration даёт управляемую площадку аудита и применения настроек ОС для виртуальных машин Azure и локальных серверов через Azure Arc.¹² Выбирают: периодически запускать локальную команду или сажать на вышестоящую платформу управления.

8. Что проверить до применения — права запуска, секреты, доверие

8.1. Пользовательские и машинные настройки разделять уже на этапе конфигурации

Для set, который затрагивает машину целиком — HKLM, компоненты Windows — нужно повышение прав. Если ресурсы PSDSC линии Windows PowerShell вызывают через адаптер, запуск от администратора тоже предполагается.⁷

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

flowchart TB
    accTitle: Разделять контекст выполнения по объекту конфигурации
    accDescr: Пользовательские и машинные настройки разделяют уже в документах конфигурации, проверяют целевого пользователя и нужные права, затем передают в интерактивный или периодический запуск
    config["Настройки, которыми управлять"] --> user["Пользовательская конфигурация"]
    config --> machine["Машинная конфигурация"]
    user --> check["Проверить пользователя и права"]
    machine --> check
    check --> exec["Интерактивный или периодический запуск"]

Рис. 13: YAML недостаточно раздавать одинаково: заранее решают, от какого пользователя и с какими правами эту конфигурацию применяют.

8.2. Не класть секреты в Git и проверять ресурсы, на которые ссылаетесь

Документ конфигурации — данные, которые кладут в Git. Пароли и ключи API не пишут напрямую: параметризуют и передают в момент запуска. Параметры главы 5 разделяют различия сред, но отделить секреты от тела конфигурации тоже важно.

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

9. Итог — с нескольких настроек собрать исполняемый источник истины

Если декларативный IaC Windows начинаете сейчас — Microsoft DSC v3 (dsc.exe). Различив четыре линии DSC, сначала наблюдают одиночными get и test, затем собирают конфигурацию в YAML/JSON. При применении идут в порядке test → what-if → set → get, отделяя суждение, прогноз, применение и проверку.⁵⁴

Повторно применять можно потому, что пишут не «шаги», а «желаемое состояние», а сравнение и нужное применение берут на себя DSC и ресурсы. Существующие ресурсы PSDSC повторно используют через адаптер; активы WinGet подключают, перенеся формат на схему v3.³¹⁰¹¹

В непрерывной эксплуатации исходят из того, что у самого v3 LCM нет. Канон конфигурации кладут в Git, периодический test обнаруживает дрейф: если верна конфигурация — восстанавливают, если верна реальность — обновляют конфигурацию.¹ Права запуска, секреты и доверие к ссылкам проектируют вместе с порядком применения.

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

Похожие статьи

• Автоматизация подготовки ПК через winget и PowerShell — сделать инструкцию исполняемой
• Стоит ли переносить BAT на PowerShell — критерии решения и практика миграции
• Планировщик заданий не запускается или завершается с 0x1 — диагностика и надёжная эксплуатация
• От групповой политики к Intune — руководство по миграции для малого и среднего бизнеса
• Управление Windows Update после перевода WSUS в deprecated — как выбрать WUfB, Autopatch и Intune

Смежные области консультирования

Компания KomuraSoft LLC помогает перейти к декларативному управлению конфигурацией Windows-клиентов и серверов, автоматизировать подготовку ПК и внутреннюю стандартную среду и сделать исполняемыми инструкции, которые держались на конкретных людях.

• Технические консультации и ревью дизайна
• Доработка и сопровождение существующих Windows-программ
• Использование и перенос существующих активов
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

У DSC, кажется, несколько версий. Какую брать?

Если декларативное управление конфигурацией начинаете сейчас — Microsoft DSC v3 (dsc.exe). У DSC четыре линии: PSDSC v1.1, встроенный в Windows PowerShell 5.1; PSDSC v2 как модуль для PowerShell 7; PSDSC v3 (превью), который используют для Linux-поддержки Azure Machine Configuration; и Microsoft DSC v3, переписанный как самостоятельная команда без зависимости от PowerShell. v3 кроссплатформенный: конфигурацию пишут данными YAML/JSON, а не сценариями PowerShell, а существующие ресурсы PSDSC можно вызывать через адаптеры. В поиске добавляйте «DSC v3» или «dsc.exe» — так проще отделить материалы старых поколений.

Чем DSC v3 отличается от сценария-инструкции (BAT или PowerShell)?

Сценарий-инструкция описывает «шаги, которые выполнить», поэтому идемпотентность приходится строить самим, чтобы повторный запуск не дал двойного применения или ошибки. DSC записывает «желаемое состояние» как данные, а сравнение с текущим (test) и применение разницы (set) берут на себя ресурсы. Сколько ни запускайте один и тот же документ конфигурации, к пунктам, которые уже в желаемом состоянии, он ничего не делает, поэтому распространять и повторять можно, не считая запусков. А поскольку конфигурация — YAML-данные, ревью диффов и история поколений в Git заметно проще, чем у сценариев.

Существующие ресурсы PowerShell DSC и активы WinGet Configuration пропадут зря?

Нет. DSC v3 вызывает существующие классовые и MOF-ресурсы PSDSC через ресурсы-адаптеры (с DSC 3.2 — Microsoft.Adapter/PowerShell и Microsoft.Adapter/WindowsPowerShell; раньше — Microsoft.DSC/PowerShell и Microsoft.Windows/WindowsPowerShell). WinGet Configuration начиная со схемы v3 (WinGet 1.11 и новее) использует DSC v3 как обработчик. Существующие файлы .winget формата v2 по-прежнему работают на прежнем обработчике, но чтобы посадить их на обработчик DSC v3, нужно перевести в формат v3 по официальному руководству по преобразованию.

Как в DSC v3 «непрерывно» принуждать конфигурацию?

Сам DSC v3 — инструмент, который запускают как команду: резидентного агента и автовосстановления вроде LCM (Local Configuration Manager) из v1.1 у него нет. Если нужны непрерывное применение и аудит, либо сами устраиваете обнаружение дрейфа периодическим запуском dsc config test из Планировщика заданий или CI, либо сажаете на слой оркестрации вроде Azure Machine Configuration (через Azure Arc можно охватить и локальные серверы).

Страшно сразу запускать dsc config set. Можно заранее увидеть влияние?

Можно. dsc config test без изменений показывает, какие экземпляры ресурсов не в желаемом состоянии. У dsc config set есть ещё параметр --what-if: он показывает прогноз «что и как изменится, если запустить», ничего не меняя. Сначала сверьте разницу test и --what-if, и только когда всё устраивает — запускайте set. Так безопаснее.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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