Desired State Configuration Pull Service
Importante
O Servidor pull (Windows Feature DSC-Service) é um componente suportado do Windows Server. No entanto, não existem planos para oferecer novas funcionalidades ou capacidades. Gostaríamos que soubesse que está agora disponível uma versão mais recente do DSC, gerida por uma funcionalidade de Azure Policy com o nome configuração de convidado. O serviço de configuração de convidado combina as funcionalidades da Extensão DSC, Automatização do Azure State Configuration e as funcionalidades mais frequentemente pedidas do feedback dos clientes. A configuração de convidado também inclui suporte de máquina híbrida através de servidores compatíveis com o Arc.
Os Configuration Manager locais (LCM) podem ser geridos centralmente por uma solução de Serviço Pull. Ao utilizar esta abordagem, o nó que está a ser gerido é registado com um serviço e é-lhe atribuída uma configuração nas definições de LCM. A configuração e todos os recursos de DSC necessários como dependências para a configuração são transferidos para o computador e utilizados pelo LCM para gerir a configuração. As informações sobre o estado do computador que está a ser gerido são carregadas para o serviço para relatórios. Este conceito é referido como "serviço pull".
As opções atuais do serviço pull incluem:
- serviço Automatização do Azure Desired State Configuration
- Um serviço pull em execução no Windows Server
- Soluções open-source mantidas pela comunidade
- Uma partilha SMB
O dimensionamento recomendado para cada solução é o seguinte:
Solução | Nós de cliente |
---|---|
Windows Pull Server com base de dados MDB/ESENT | Até 500 nós |
Windows Pull Server com base de dados SQL | Até 3500 nós |
Azure Automation DSC | Ambientes pequenos e grandes |
A solução recomendada e a opção com mais funcionalidades disponíveis é Automatização do Azure DSC. Não foi identificado um limite superior para o número de nós por Conta de Automatização.
O serviço do Azure pode gerir nós no local em datacenters privados ou em clouds públicas, como o Azure e o AWS. Para ambientes privados em que os servidores não conseguem ligar diretamente à Internet, considere limitar o tráfego de saída apenas ao intervalo de IP do Azure publicado (veja Intervalos de IP do Datacenter do Azure).
As funcionalidades do serviço online que não estão atualmente disponíveis no serviço pull no Windows Server incluem:
- Todos os dados são encriptados em trânsito e inativos
- Os certificados de cliente são criados e geridos automaticamente
- Arquivo de segredos para gerir centralmente palavras-passe/credenciais ou variáveis como nomes de servidor ou cadeias de ligação
- Gerir centralmente a configuração LCM do nó
- Atribuir centralmente configurações a nós de cliente
- Libertar alterações de configuração para "grupos canários" para testes antes de chegar à produção
- Relatórios gráficos
- Detalhes do estado ao nível do recurso do DSC de granularidade
- Mensagens de erro verbosas de máquinas cliente para resolução de problemas
- Integração com o Azure Log Analytics para alertas , tarefas automatizadas, aplicação Android/iOS para relatórios e alertas
Serviço de solicitação do DSC no Windows Server
É possível configurar um serviço pull para ser executado no Windows Server. Tenha em atenção que a solução de serviço de solicitação incluída no Windows Server inclui apenas capacidades de armazenamento de configurações e módulos para transferir e capturar dados de relatórios para uma base de dados. Não inclui muitas das capacidades oferecidas pelo serviço no Azure, pelo que não é uma boa ferramenta para avaliar a forma como o serviço seria utilizado.
O serviço pull oferecido no Windows Server é um serviço Web no IIS que utiliza uma interface OData para disponibilizar ficheiros de configuração DSC para nós de destino quando esses nós os pedem.
Requisitos para utilizar um servidor de extração:
- Um servidor a executar:
- WMF/PowerShell 4.0 ou superior
- Função de servidor IIS
- Serviço DSC
- Idealmente, algumas formas de gerar um certificado, para proteger as credenciais transmitidas para a Configuration Manager Local (LCM) nos nós de destino
A melhor forma de configurar o Windows Server para alojar o serviço de solicitação é utilizar uma configuração do DSC. É fornecido um script de exemplo abaixo.
Sistemas de bases de dados suportados
WMF 4.0 | WMF 5.0 | WMF 5.1 | WMF 5.1 (Windows Server Insider Preview 17090) |
---|---|---|---|
MDB | ESENT (Predefinição), MDB | ESENT (Predefinição), MDB | ESENT (Predefinição), SQL Server, MDB |
A partir da versão 17090 do Windows Server, SQL Server é uma opção suportada para o Serviço Pull (Windows Feature DSC-Service). Isto fornece uma nova opção para dimensionar ambientes DSC grandes que não foram migrados para Automatização do Azure DSC.
Nota
SQL Server suporte não será adicionado às versões anteriores do WMF 5.1 (ou anterior) e só estará disponível em versões do Windows Server superiores ou iguais a 17090.
Para configurar o servidor de extração para utilizar SQL Server, defina SqlProvider como $true
e SqlConnectionString para uma cadeia de ligação de SQL Server válida. Para obter mais informações, veja Cadeias de Ligação SqlClient.
Para obter um exemplo de SQL Server configuração com xDscWebService, leia primeiro Utilizar o recurso xDscWebService e, em seguida, reveja 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 no GitHub.
Utilizar o recurso xDscWebService
A forma mais fácil de configurar um servidor de extração Web é utilizar o recurso xDscWebService , incluído no módulo xPSDesiredStateConfiguration . Os passos seguintes explicam como utilizar o recurso num Configuration
que configura o serviço Web.
Chame o cmdlet Install-Module para instalar o módulo xPSDesiredStateConfiguration .
Nota
Install-Module
está incluído no módulo PowerShellGet , que está incluído no PowerShell 5.0 e superior.Obtenha um certificado SSL para o servidor de Extração do DSC a partir de uma Autoridade de Certificação fidedigna, dentro da sua organização ou de uma autoridade pública. Normalmente, o certificado recebido da autoridade está no formato PFX.
Instale o certificado no nó que se tornará o servidor pull do DSC na localização predefinida, que deve ser
CERT:\LocalMachine\My
.- Anote o thumbprint do certificado.
Selecione um GUID para ser utilizado como Chave de Registo. Para gerar um com o PowerShell, introduza o seguinte na linha de comandos do PS e prima Enter:
[guid]::newGuid()
ouNew-Guid
. Esta chave será utilizada pelos nós de cliente como uma chave partilhada para autenticar durante o registo. Para obter mais informações, veja a secção Chave de Registo abaixo.No ISE do PowerShell, inicie (F5) o seguinte script de configuração (incluído na pasta do módulo xPSDesiredStateConfiguration como
Sample_xDscWebServiceRegistration.ps1
) . Este script configura o servidor de extração.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 } } }
Execute a configuração, transmitindo o thumbprint do certificado SSL como o parâmetro certificateThumbPrint e uma chave de registo GUID como o parâmetro 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
Chave de Registo
Para permitir que os nós de cliente se registem no servidor para que possam utilizar nomes de configuração em vez de um ID de configuração, uma chave de registo criada pela configuração acima é guardada num ficheiro com o nome RegistrationKeys.txt
no C:\Program Files\WindowsPowerShell\DscService
. A chave de registo funciona como um segredo partilhado utilizado durante o registo inicial pelo cliente com o servidor de extração. O cliente irá gerar um certificado autoassinado que é utilizado para autenticar exclusivamente no servidor de extração assim que o registo for concluído com êxito. O thumbprint deste certificado é armazenado localmente e associado ao URL do servidor de solicitação.
Nota
As chaves de registo não são suportadas no PowerShell 4.0.
Para configurar um nó para autenticar com o servidor pull, a chave de registo tem de estar na metaconfiguração de qualquer nó de destino que será registado neste servidor pull. Tenha em atenção que a Chave de Registo na metaconfiguração abaixo é removida após o computador de destino ter sido registado com êxito e que o valor tem de corresponder ao valor armazenado no RegistrationKeys.txt
ficheiro no servidor de solicitação ('140a952b-b9d6-406b-b416-e0f759c9c0e4' para este exemplo). Trate sempre o valor da chave de registo de forma segura, porque saber que permite que qualquer máquina de destino se registe no servidor de solicitação.
[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
Nota
A secção ReportServerWeb permite que os dados de relatórios sejam enviados para o servidor Pull.
A falta da propriedade ConfigurationID no ficheiro de metaconfiguração significa implicitamente que o servidor Pull está a suportar a versão V2 do protocolo do servidor Pull para que seja necessário um registo inicial. Por outro lado, a presença de um ConfigurationID significa que a versão V1 do protocolo do servidor Pull é utilizada e não existe nenhum processamento de registo.
Nota
Num cenário PUSH, existe um erro na versão atual que torna necessário definir uma propriedade ConfigurationID no ficheiro de metaconfiguração para nós que nunca se registaram num servidor Pull. Isto irá forçar o protocolo V1 Pull Server e evitar mensagens de falha de registo.
Colocar configurações e recursos
Após a conclusão da configuração do servidor Pull, as pastas definidas pelas propriedades ConfigurationPath e ModulePath na configuração do servidor Pull são onde irá colocar módulos e configurações que estarão disponíveis para os nós de destino solicitarem. Estes ficheiros têm de estar num formato específico para que o servidor Pull os processe corretamente.
Formato do pacote do módulo de recursos do DSC
Cada módulo de recursos tem de ser zipado e nomeado de acordo com o seguinte padrão {Module Name}_{Module Version}.zip
.
Por exemplo, um módulo com o nome xWebAdminstration com uma versão do módulo 3.1.2.0 teria o nome xWebAdministration_3.1.2.0.zip
. Cada versão de um módulo tem de estar contida num único ficheiro zip.
Uma vez que existe apenas uma única versão de um recurso em cada ficheiro zip, o formato de módulo adicionado no WMF 5.0 com suporte para várias versões de módulo num único diretório não é suportado. Isto significa que, antes de empacotar os módulos de recursos do DSC para utilização com o servidor Pull, terá de fazer uma pequena alteração à estrutura do diretório. O formato predefinido dos módulos que contêm o recurso DSC no WMF 5.0 é {Module Folder}\{Module Version}\DscResources\{DSC Resource Folder}\
. Antes de empacotar para o servidor Pull, remova a pasta {Module version} para que o caminho se torne {Module Folder}\DscResources\{DSC Resource Folder}\
. Com esta alteração, zipe a pasta conforme descrito acima e coloque estes ficheiros zip na pasta ModulePath .
Utilize New-DscChecksum {module zip file}
para criar um ficheiro de soma de verificação para o módulo adicionado recentemente.
Formato MOF de configuração
Um ficheiro MOF de configuração tem de ser emparelhado com um ficheiro de soma de verificação para que um LCM num nó de destino possa validar a configuração. Para criar uma soma de verificação, chame o cmdlet New-DscChecksum . O cmdlet utiliza um parâmetro Caminho que especifica a pasta onde o MOF de configuração está localizado. O cmdlet cria um ficheiro de soma de verificação com o nome ConfigurationMOFName.mof.checksum
, onde ConfigurationMOFName
é o nome do ficheiro mof de configuração. Se existirem mais do que um ficheiro MOF de configuração na pasta especificada, é criada uma soma de verificação para cada configuração na pasta. Coloque os ficheiros MOF e os respetivos ficheiros de soma de verificação associados na pasta ConfigurationPath .
Nota
Se alterar o ficheiro MOF de configuração de alguma forma, também terá de recriar o ficheiro de soma de verificação.
Ferramentas
Para facilitar a configuração, validação e gestão do servidor Pull, as seguintes ferramentas são incluídas como exemplos na versão mais recente do módulo xPSDesiredStateConfiguration:
Um módulo que ajudará a empacotar módulos de recursos do DSC e ficheiros de configuração para utilização no servidor Pull. PublishModulesAndMofsToPullServer.psm1. Exemplos abaixo:
# 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
Um script que valida o servidor Pull está configurado corretamente. PullServerSetupTests.ps1.
Soluções de Comunidade para o Serviço Pull
A comunidade DSC criou várias soluções para implementar o protocolo de serviço Pull. Para ambientes no local, estas oferecem capacidades de serviço Pull e uma oportunidade para contribuir de volta para a comunidade com melhorias incrementais.
Configuração do cliente Pull
Os tópicos seguintes descrevem a configuração detalhada dos clientes Pull:
- Configurar um cliente pull do DSC com um ID de configuração
- Configurar um cliente pull do DSC com nomes de configuração
- Configurações parciais