Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Это важно
Pull Server (Windows Feature DSC-Service) является поддерживаемым компонентом Windows Server, однако предложение новых функций или возможностей не планируется. Мы хотели бы, чтобы вы знали, что более новая версия DSC теперь общедоступна, управляется функцией Политики Azure под названием гостевая конфигурация. Служба гостевой конфигурации сочетает в себе функции расширения DSC, конфигурации состояния службы автоматизации Azure и наиболее часто запрашиваемые функции из отзывов клиентов. Гостевая конфигурация также включает поддержку гибридных компьютеров через серверы с поддержкой Arc.
Локальный диспетчер конфигураций (LCM) может централизованно управляться с помощью решения Pull Service. При использовании этого подхода управляемый узел регистрируется в службе и ему назначается конфигурация в параметрах LCM. Конфигурация и все ресурсы DSC, необходимые в качестве зависимостей для конфигурации, загружаются на компьютер и используются LCM для управления конфигурацией. Информация о состоянии управляемой машины выгружается в сервис для составления отчетов. Это понятие называется «вытягивающим сервисом».
В настоящее время доступны следующие варианты службы по вытягиванию:
- Служба настройки требуемого состояния службы автоматизации Azure
- Опрашивающая служба, работающая на Windows Server
- Поддерживаемые сообществом решения с открытым исходным кодом
- Акция SMB
Рекомендуемый масштаб для каждого решения следующий:
Решение | Клиентские узлы |
---|---|
Windows Pull Server с использованием базы данных MDB/ESENT | До 500 узлов |
Windows Pull Server с использованием базы данных SQL | До 3500 узлов |
Azure Automation DSC | Как маленькие, так и большие среды |
Рекомендуемым решением и вариантом с наибольшим количеством доступных функций является DSC службы автоматизации Azure. Верхний предел количества узлов на учетную запись автоматизации не определен.
Служба Azure может управлять узлами локально в частных центрах обработки данных или в общедоступных облаках, таких как Azure и AWS. Для частных сред, в которых серверы не могут напрямую подключиться к Интернету, рассмотрите возможность ограничения исходящего трафика только опубликованным диапазоном IP-адресов Azure (см. раздел Диапазоны IP-адресов Azure и теги служб).
Ниже перечислены функции веб-службы, которые в настоящее время недоступны в службе извлечения в Windows Server.
- Все данные шифруются при передаче и хранении
- Клиентские сертификаты создаются и управляются автоматически
- Хранилище секретов для централизованного управления паролями, учетными данными или переменными , такими как имена серверов или строки подключения
- Централизованное управление конфигурацией LCM узла
- Централизованное назначение конфигураций клиентским узлам
- Выпуск изменений конфигурации в «канареечные группы» для тестирования перед подачей в рабочую среду
- Графическая отчетность
- Сведения о состоянии на уровне детализации ресурсов DSC
- Подробные сообщения об ошибках с клиентских компьютеров для устранения неполадок
- Интеграция с Azure Log Analytics для оповещений, автоматизированных задач, приложением для Android/iOS для создания отчетов и оповещений
Служба DSC pull в Windows Server
Можно настроить службу извлечения для запуска в Windows Server. Обратите внимание, что решение службы извлечения, включенное в Windows Server, включает только возможности хранения конфигураций и модулей для загрузки и записи данных отчета в базу данных. Он не включает в себя многие возможности, предлагаемые службой в Azure, и поэтому не является хорошим инструментом для оценки того, как будет использоваться служба.
Служба извлечения, предлагаемая в Windows Server, — это веб-служба в IIS, которая использует интерфейс OData для предоставления файлов конфигурации DSC целевым узлам, когда эти узлы запрашивают их.
Требования к использованию опрашивающего сервера:
- Сервер, на котором работают:
- WMF/PowerShell 4.0 или более поздней версии
- Роль сервера IIS
- Сервис DSC
- В идеале, это должны быть какие-то средства создания сертификата для защиты учетных данных, передаваемых в Local Configuration Manager (LCM) на целевых узлах
Лучший способ настроить Windows Server на хост службы pull — использовать конфигурацию DSC. Пример скрипта приведен ниже.
Поддерживаемые системы баз данных
Начиная с версии 17090 Windows Server, WMF 5.1 включает поддержку опции SQL Server для службы Pull (Windows Feature DSC-Service). Это предоставляет новый вариант масштабирования больших сред DSC, которые не были перенесены на DSC службы автоматизации Azure.
Чтобы настроить опрашивающий сервер для использования SQL Server, задайте для параметра SqlProvider значение $true
, а для параметра SqlConnectionString — допустимую строку подключения к SQL Server. Дополнительные сведения см. в разделе Строки подключения SqlClient. Пример настройки SQL Server с помощью xDscWebService сначала см. в статье Использование ресурса xDscWebService , а затем ознакомьтесь с 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 на GitHub.
Использование ресурса xDscWebService
Самый простой способ настроить веб-пулл-сервер — использовать ресурс xDscWebService , входящий в состав модуля xPSDesiredStateConfiguration . Ниже описано, как использовать ресурс в системе Configuration
, которая настраивает веб-службу.
Вызовите командлет Install-Module для установки модуля xPSDesiredStateConfiguration .
Получите SSL-сертификат для сервера DSC Pull в доверенном центре сертификации в вашей организации или в государственном центре. Сертификат, полученный от центра, обычно имеет формат PFX.
Установите сертификат на узел, который станет сервером DSC Pull, в расположении по умолчанию, которое должно быть .
CERT:\LocalMachine\My
Запишите отпечаток большого пальца сертификата.Выберите идентификатор GUID, который будет использоваться в качестве регистрационного ключа. Чтобы создать его с помощью PowerShell, введите следующее в командной строке PS и нажмите Enter:
[guid]::newGuid()
илиNew-Guid
. Этот ключ будет использоваться клиентскими узлами в качестве общего ключа для аутентификации во время регистрации. Для получения дополнительной информации см. раздел «Регистрационный ключ» ниже.В интегрированной среде сценариев 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 } } }
Запустите конфигурацию, передав отпечаток 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-адресом опрашивающего сервера.
Замечание
Регистрационные ключи не поддерживаются в PowerShell 4.0.
Чтобы настроить узел для аутентификации на опрашивающем сервере, регистрационный ключ должен находиться в метаконфигурации любого целевого узла, который будет регистрироваться на этом опрашивающем сервере. Обратите внимание, что RegistrationKey в приведенной ниже метаконфигурации удаляется после успешной регистрации целевого компьютера и что значение должно совпадать со значением, хранящимся в файле RegistrationKeys.txt
на опрашивающем сервере («140a952b-b9d6-406b-b416-e0f759c9c0e4» для этого примера). Всегда обращайтесь со значением регистрационного ключа безопасно, так как его знание позволяет любому целевому компьютеру зарегистрироваться на опрашивающем сервере.
[DSCLocalConfigurationManager()]
configuration Sample_MetaConfigurationToRegisterWithLessSecurePullServer
{
param
(
[ValidateNotNullOrEmpty()]
[string] $NodeName = 'localhost',
# the key used to set up pull server in previous configuration
[ValidateNotNullOrEmpty()]
[string] $RegistrationKey,
# The name of the pull server, same as $NodeName used in previous configuration
[ValidateNotNullOrEmpty()]
[string] $ServerName = 'localhost'
)
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
Замечание
Раздел ReportServerWeb позволяет отправлять данные отчетов на опрашивающий сервер.
Отсутствие свойства ConfigurationID в файле метаконфигурации неявно означает, что опрашивающий сервер поддерживает версию V2 протокола опрашивающего сервера, поэтому требуется первоначальная регистрация. И наоборот, наличие ConfigurationID означает, что используется версия V1 протокола опрашивающего сервера и регистрация не обрабатывается.
Замечание
В сценарии PUSH в текущем выпуске существует ошибка, из-за которой необходимо определить свойство ConfigurationID в файле метаконфигурации для узлов, которые никогда не регистрировались на опрашивающем сервере. Это приведет к принудительному использованию протокола V1 Pull Server и позволит избежать сообщений об ошибках регистрации.
Размещение конфигураций и ресурсов
После завершения настройки опрашивающего сервера в папках, определенных свойствами ConfigurationPath и ModulePath в конфигурации опрашивающего сервера, будут размещены модули и конфигурации, которые будут доступны для опрашивающих узлов. Эти файлы должны быть в определенном формате, чтобы опрашивающий сервер мог их корректно обработать.
Формат пакета модулей ресурсов DSC
Каждый ресурсный модуль должен быть заархивирован и назван в соответствии со следующей схемой <Module Name>_<Module Version>.zip
.
Например, модуль с именем xWebAdminstration и версией модуля 3.1.2.0 будет называться xWebAdministration_3.1.2.0.zip
. Каждая версия модуля должна содержаться в одном zip-файле.
Поскольку в каждом zip-файле содержится только одна версия ресурса, формат модуля, добавленный в WMF 5.0 с поддержкой нескольких версий модулей в одном каталоге, не поддерживается. Это означает, что перед упаковкой ресурсных модулей DSC для использования с pull-сервером вам потребуется внести небольшие изменения в структуру каталогов. Формат модулей, содержащих ресурс DSC по умолчанию в WMF 5.0, — <Module Folder>\<Module Version>\DscResources\<DSC Resource Folder>\
. Перед упаковкой для опрашивающего сервера удалите <Module version>
папку так, чтобы путь стал .<Module Folder>\DscResources\<DSC Resource Folder>\
С этим изменением заархивируйте папку, как описано выше, и поместите эти zip-файлы в папку ModulePath .
Используется New-DscChecksum <module zip file>
для создания файла контрольной суммы для вновь добавленного модуля.
Конфигурация формата MOF
Файл MOF конфигурации должен быть связан с файлом контрольной суммы, чтобы LCM на целевом узле мог проверить конфигурацию. Чтобы создать контрольную сумму, вызовите командлет New-DscChecksum . Командлет принимает параметр Path , который указывает папку, в которой находится MOF конфигурации. Командлет создает файл контрольной суммы с именем ConfigurationMOFName.mof.checksum
, где ConfigurationMOFName
— имя файла mof конфигурации. Если в указанной папке имеется более одного файла MOF конфигурации, для каждой конфигурации в папке создается контрольная сумма. Поместите файлы MOF и связанные с ними файлы контрольных сумм в папку ConfigurationPath .
Замечание
Если вы каким-либо образом изменяете файл MOF конфигурации, необходимо также повторно создать файл контрольной суммы.
Инструментальная оснастка
Чтобы настроить, проверить и управлять опрашивающим сервером, используйте следующие средства, включенные в качестве примеров в последнюю версию модуля xPSDesiredStateConfiguration:
Модуль, который поможет с упаковкой ресурсных модулей DSC и конфигурационных файлов для использования на pull-сервере. 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
Сценарий, который проверяет опрашивающий сервер, настроен правильно. PullServerSetupTests.ps1.
Решения сообщества для службы Pull
Сообщество DSC является автором нескольких решений для реализации протокола службы pull. Для локальных сред они предлагают возможности службы извлечения и возможность внести свой вклад в сообщество с помощью постепенных улучшений.
Конфигурация клиента по запросу
В следующих разделах подробно описывается настройка опрашивающих клиентов.
- Настройка опрашивающего клиента DSC с помощью идентификатора конфигурации
- Настройка опрашивающего клиента DSC с использованием имен конфигураций
- Частичные конфигурации