Опрашивающая служба Desired State Configuration

Управление локальным диспетчером (LCM) конфигураций можно централизировать с помощью опрашиваемой службы. При использовании такого подхода управляемый узел регистрируется в службе, и ему в параметрах локального диспетчера конфигураций назначается конфигурация. Конфигурация и все ресурсы DSC, которые необходимы в качестве зависимостей конфигурации, загружаются на компьютер и используются локальным диспетчером конфигураций для управления конфигурацией. Сведения о состоянии управляемого компьютера отправляются в службу для отчетности. Эта концепция называется "опрашивающей службой".

Текущие варианты опрашиваемой службы:

• служба Desired State Configuration в службе автоматизации Azure;
• Опрашиваемая служба в Windows Server
• Решения с открытым исходным кодом, поддерживаемые сообществом
• Общий ресурс SMB

Для каждого решения рекомендуется использовать следующий масштаб:

Рекомендуемое решение и вариант с наибольшим числом доступных функций — DSC в службе автоматизации Azure. Не определен верхний предел количества узлов на учетную запись службы автоматизации.

Служба Azure может управлять узлами в локальных частных центрах обработки данных или в общедоступных облаках, таких как Azure и AWS. Для частных сред, где серверы не могут напрямую подключаться к Интернету, рекомендуем ограничить исходящий трафик только опубликованным диапазоном IP-адресов Azure (см. сведения о диапазонах IP-адресов для центров обработки данных Azure).

Функции веб-службы, которые сейчас недоступны в опрашиваемой службе в Windows Server:

• Шифрование всех данных при передаче и хранении.
• Автоматическое создание и обслуживание клиентских сертификатов.
• Хранение секретов с централизованным управлением паролями и учетными данными или переменными, такими как имена серверов или строки подключения.
• Централизованное управление конфигурацией LCM в узле.
• Централизованное назначение конфигураций клиентским узлам.
• Выпуск изменений конфигурации для небольших групп пользователей, позволяющий протестировать решение перед реализацией в рабочей среде.
• Графические отчеты:
  • сведения о состоянии на уровне ресурсов DSC;
  • подробные сообщения об ошибках с клиентских компьютеров для устранения неполадок.
• Интеграция с Azure Log Analytics для отправки предупреждений, автоматизации задач, а также выполнения приложений Android или iOS для создания отчетов и оповещений.

Опрашиваемая служба DSC в Windows Server

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

Опрашиваемая служба в Windows Server — это веб-служба в составе IIS, которая использует интерфейс OData для создания файлов конфигурации DSC, доступных целевым узлам по запросу.

Требования к использованию опрашиваемого сервера:

• Сервер под управлением:
  • WMF/PowerShell 4.0 или более поздней версии
  • Роль сервера служб IIS
  • Служба DSC
• Рекомендуется использовать средства создания сертификата для защиты учетных данных, передаваемых в локальный диспетчер конфигураций (LCM) на целевых узлах

Для настройки размещения опрашиваемой службы в Windows Server лучше всего воспользоваться конфигурацией DSC. Пример сценария приведен ниже.

Поддерживаемые системы баз данных

Начиная с выпуска Windows Server 17090 в опрашивающей службе (компонент Windows служба DSC) поддерживается SQL Server. Это новый вариант масштабирования крупных сред DSC, которые не были перенесены в Azure Automation DSC.

Чтобы настроить на опрашивающем сервере использование SQL Server, установите значение $true для параметра SqlProvider и допустимую строку подключения SQL Server для параметра SqlConnectionString. Дополнительные сведения см. в разделе Строки подключения SqlClient. Чтобы ознакомиться с настройкой SQL Server с помощью xDscWebService, прочтите статью Использование ресурса xDscWebService и просмотрите файл 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 на GitHub.

Использование ресурса xDSCWebService

Самый простой способ настроить опрашиваемый веб-сервер — использовать ресурс xDscWebService, включенный в модуль xPSDesiredStateConfiguration. В следующих действиях показано, как использовать ресурс в скрипте Configuration, используемом для настройки веб-службы.

1. Вызовите командлет Install-Module, чтобы установить модуль xPSDesiredStateConfiguration.

   Примечание

   Install-Module включен в модуль PowerShellGet, содержащийся в PowerShell 5.0 и более поздних версий.

2. Получите SSL-сертификат для опрашивающего сервера DSC из доверенного центра сертификации (общедоступного или входящего в состав вашей организации). Полученный из центра сертификат обычно имеет формат PFX.

3. Установите сертификат на узле, который должен стать опрашиваемым сервером DSC, в расположении по умолчанию (CERT:\LocalMachine\My).

   • Запишите отпечаток сертификата.

4. Выберите идентификатор GUID для использования в качестве ключа регистрации. Чтобы создать его с помощью PowerShell, в командной строке PS введите следующее и нажмите клавишу ВВОД: [guid]::newGuid() или New-Guid. Этот ключ будет использоваться клиентскими узлами в качестве общего ключа для проверки подлинности во время регистрации. Дополнительные сведения см. в разделе "Ключ регистрации" ниже.

5. В ISE PowerShell запустите (нажав клавишу F5) следующий скрипт конфигурации (включенный в пример папки модуля xPSDesiredStateConfiguration в качестве Sample_xDscWebServiceRegistration.ps1). Этот сценарий настраивает опрашиваемый сервер.

   configuration Sample_xDscWebServiceRegistration
   {
       param
       (
           [string[]]$NodeName = 'localhost',
   
           [ValidateNotNullOrEmpty()]
           [string] $certificateThumbPrint,
   
           [Parameter(HelpMessage='This should be a string with enough entropy (randomness)' +
               ' to protect the registration of clients to the pull server.  We will use new' +
               ' GUID by default.'
           )]
           [ValidateNotNullOrEmpty()]
           [string] $RegistrationKey   # A guid that clients use to initiate conversation with pull server
       )
   
       Import-DSCResource -ModuleName PSDesiredStateConfiguration
       Import-DSCResource -ModuleName xPSDesiredStateConfiguration
   
       Node $NodeName
       {
           WindowsFeature DSCServiceFeature
           {
               Ensure = "Present"
               Name   = "DSC-Service"
           }
   
           xDscWebService PSDSCPullServer
           {
               Ensure                  = "Present"
               EndpointName            = "PSDSCPullServer"
               Port                    = 8080
               PhysicalPath            = "$env:SystemDrive\inetpub\PSDSCPullServer"
               CertificateThumbPrint   = $certificateThumbPrint
               ModulePath              = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
               ConfigurationPath       = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
               State                   = "Started"
               DependsOn               = "[WindowsFeature]DSCServiceFeature"
               RegistrationKeyPath     = "$env:PROGRAMFILES\WindowsPowerShell\DscService"
               AcceptSelfSignedCertificates = $true
               UseSecurityBestPractices     = $true
               Enable32BitAppOnWin64   = $false
           }
   
           File RegistrationKeyFile
           {
               Ensure          = 'Present'
               Type            = 'File'
               DestinationPath = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
               Contents        = $RegistrationKey
           }
       }
   }
   

6. Запустите конфигурацию, передав отпечаток SSL-сертификата с параметром certificateThumbPrint и ключ регистрации GUID с параметром RegistrationKey:

   # To find the Thumbprint for an installed SSL certificate for use with the pull server list all
   # certificates in your local store and then copy the thumbprint for the appropriate certificate
   # by     reviewing the certificate subjects
   
   dir Cert:\LocalMachine\my
   
   # Then include this thumbprint when running the configuration
   $sample_xDscWebServiceRegistrationSplat = @{
       certificateThumbprint = 'A7000024B753FA6FFF88E966FD6E19301FAE9CCC'
       RegistrationKey = '140a952b-b9d6-406b-b416-e0f759c9c0e4'
       OutputPath = 'C:\Configs\PullServer'
   }
   Sample_xDscWebServiceRegistration @sample_xDscWebServiceRegistrationSplat
   
   # Run the compiled configuration to make the target node a DSC Pull Server
   Start-DscConfiguration -Path c:\Configs\PullServer -Wait -Verbose
   

Ключ регистрации

Чтобы разрешить клиентским узлам регистрироваться на сервере для использования имен конфигурации вместо идентификаторов конфигурации, созданный конфигурацией ключ сохраняется в файле RegistrationKeys.txt в C:\Program Files\WindowsPowerShell\DscService. Ключ регистрации работает как общий секрет, используемый во время первоначальной регистрации клиента с опрашиваемым сервером. Клиент создает самозаверяющий сертификат, который используется для уникальной проверки подлинности на опрашиваемом сервере после успешного завершения регистрации. Отпечаток этого сертификата сохраняется локально и связывается с URL-адресом опрашиваемого сервера.

Для настройки проверки подлинности узла опрашиваемом сервере необходимо поместить ключ регистрации в метаконфигурацию всех целевых узлов, которые будут регистрироваться на этом опрашиваемом сервере. Обратите внимание, что RegistrationKey в метаконфигурации ниже удаляется после успешной регистрации целевого компьютера, и значение должно соответствовать значению в файле RegistrationKeys.txt на опрашиваемом сервере (в этом примере — "140a952b-b9d6-406b-b416-e0f759c9c0e4"). Значение ключа регистрации должно оставаться конфиденциальным, так как с ним любой целевой компьютер сможет зарегистрироваться на опрашиваемом сервере.

[DSCLocalConfigurationManager()]
configuration Sample_MetaConfigurationToRegisterWithLessSecurePullServer
{
    param
    (
        [ValidateNotNullOrEmpty()]
        [string] $NodeName = 'localhost',

        [ValidateNotNullOrEmpty()]
        [string] $RegistrationKey, # the key used to set up pull server in previous configuration

        [ValidateNotNullOrEmpty()]
        [string] $ServerName = 'localhost' # The name of the pull server, same as $NodeName used in previous configuration
    )

    Node $NodeName
    {
        Settings
        {
            RefreshMode        = 'Pull'
        }

        ConfigurationRepositoryWeb CONTOSO-PullSrv
        {
            ServerURL          = "https://$ServerName`:8080/PSDSCPullServer.svc"
            RegistrationKey    = $RegistrationKey
            ConfigurationNames = @('ClientConfig')
        }

        ReportServerWeb CONTOSO-PullSrv
        {
            ServerURL       = "https://$ServerName`:8080/PSDSCPullServer.svc"
            RegistrationKey = $RegistrationKey
        }
    }
}

$MetaConfigurationSplat = @{
    RegistrationKey = $RegistrationKey
    OutputPath = 'c:\Configs\TargetNodes'
}

Sample_MetaConfigurationToRegisterWithLessSecurePullServer @MetaConfigurationSplat

Отсутствие свойства ConfigurationID в файле метаконфигурации неявно означает, что опрашивающий сервер поддерживает версию 2 протокола опрашивающего сервера и требуется начальная регистрация. Наоборот, наличие свойства ConfigurationID означает, что используется версия 1 протокола опрашиваемого сервера и регистрация не выполняется.

Размещение конфигураций и ресурсов

После завершения установки опрашивающего сервера папки для размещения модулей и конфигурации, которые будут доступны целевым узлам, задаются свойствами ConfigurationPath и ModulePath в конфигурации опрашивающего сервера. Для правильной обработки опрашиваемым сервером эти файлы должны иметь специальный формат.

Формат пакета модуля для ресурсов DSC

Каждый модуль ресурса необходимо упаковать в ZIP-архив и переименовать согласно следующему шаблону: {Module Name}_{Module Version}.zip.

Например, модуль с именем xWebAdminstration с версией модуля 3.1.2.0 будет иметь имя xWebAdministration_3.1.2.0.zip. Каждая версия модуля должна находиться в собственном ZIP-файле. Так как в каждом ZIP-файле существует только одна версия ресурса, формат модулей с поддержкой нескольких версий модуля в одном каталоге, который появился в WMF 5.0, не поддерживается. Это означает, что перед упаковкой модулей ресурсов DSC для опрашиваемого сервера необходимо внести небольшое изменение в структуру каталогов. Формат модулей, содержащих ресурсы DSC, в WMF 5.0 по умолчанию таков: {Module Folder}\{Module Version}\DscResources\{DSC Resource Folder}\. Перед упаковкой для опрашиваемого сервера удалите папку {Module version}, чтобы путь стал таким: {Module Folder}\DscResources\{DSC Resource Folder}\. Выполнив это изменение, упакуйте папку в ZIP-архив, как описано выше, и поместите ZIP-архивы в папку ModulePath.

Используйте New-DscChecksum {module zip file}, чтобы создать файл контрольной суммы для только что добавленного модуля.

Формат файлов конфигурации MOF

MOF-файл конфигурации необходимо сопоставить с файлом контрольной суммы, чтобы LCM на целевом узле мог проверить конфигурацию. Чтобы создать контрольную сумму, вызовите командлет New-DscChecksum. Командлет принимает параметр Path, указывающий папку, в которой располагается MOF-файл конфигурации. Командлет создает файл контрольной суммы ConfigurationMOFName.mof.checksum, где ConfigurationMOFName — имя MOF-файла конфигурации. Если в указанной папке есть несколько MOF-файлов конфигурации, контрольная сумма создается для каждой конфигурации в папке. Поместите файлы MOF и их файлы контрольных сумм в папку ConfigurationPath.

Инструментарий

Для упрощения настройки, проверки опрашиваемого сервера и управления им в последнюю версию модуля xPSDesiredStateConfiguration в качестве примеров включены следующие инструменты:

1. Модуль, который помогает упаковывать модули ресурсов и конфигурационные файлы DSC для использования на опрашиваемом сервере. PublishModulesAndMofsToPullServer.psm1. Примеры ниже:

   # Example 1 - Package all versions of given modules installed locally and MOF files are in c:\LocalDepot
   $moduleList = @('xWebAdministration', 'xPhp')
   Publish-DSCModuleAndMof -Source C:\LocalDepot -ModuleNameList $moduleList
   
   # Example 2 - Package modules and mof documents from c:\LocalDepot
   Publish-DSCModuleAndMof -Source C:\LocalDepot -Force
   

2. Сценарий, который проверяет, что опрашиваемый сервер настроен правильно. PullServerSetupTests.ps1.

Решения сообщества для опрашиваемой службы

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

• Tug
• DSC-TRÆK

Настройка опрашивающего клиента

В следующих разделах настройка опрашивающих клиентов описывается более подробно:

• Настройка опрашивающего клиента DSC с помощью идентификатора конфигурации
• Настройка опрашивающего клиента DSC с помощью имен конфигурации
• Частичные конфигурации

См. также раздел

• Обзор Windows PowerShell Desired State Configuration
• Применение конфигураций
• Использование сервера отчетов DSC
• [MS-DSCPM]: Desired State Configuration Pull Model Protocol (MS-DSCPM: Требуемое состояние конфигурации протокола с активным опросом сообщений)
• [MS-DSCPM]: Desired State Configuration Pull Model Protocol (MS-DSCPM: Требуемое состояние конфигурации протокола с активным опросом сообщений об ошибке)