Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Importante
O Pull Server (Windows Feature DSC-Service) é um componente suportado do Windows Server, no entanto, não há planos para oferecer novos recursos ou capacidades. gostaríamos que você soubesse que uma versão mais recente do DSC agora está disponível ao público, gerenciada por um recurso da Política do Azure chamado configuração de convidado. O serviço de configuração de convidado combina recursos de Extensão DSC, Configuração de Estado de Automação do Azure e os recursos mais comumente solicitados dos comentários dos clientes. A configuração de convidado também inclui suporte a máquinas híbridas por meio de servidores habilitados para Arc.
O Gerenciador de Configuração Local (LCM) pode ser gerenciado centralmente por uma solução Pull Service. Ao usar essa abordagem, o nó que está sendo gerenciado é registrado com um serviço e recebe uma configuração nas configurações do LCM. A configuração e todos os recursos DSC necessários como dependências para a configuração são baixados para a máquina e usados pelo LCM para gerenciar a configuração. As informações sobre o estado da máquina que está sendo gerenciada são carregadas no serviço para relatórios. Este conceito é referido como "pull service".
As opções atuais para o serviço pull incluem:
- Serviço de Configuração de Estado Desejado da Automação do Azure
- Um serviço pull em execução no Windows Server
- Comunidade manteve soluções de código aberto
- Uma quota SMB
A escala recomendada para cada solução é a seguinte:
| Solução | Nós cliente |
|---|---|
| Windows Pull Server usando banco de dados MDB/ESENT | Até 500 nós |
| Windows Pull Server usando banco de dados SQL | Até 3500 nós |
| Azure Automation DSC | Ambientes pequenos e grandes |
A solução recomendada e a opção com mais recursos disponíveis é o Azure Automation DSC. Não foi identificado um limite máximo para o número de nós por Conta de Automação.
O serviço do Azure pode gerenciar nós localmente em datacenters privados ou em nuvens públicas, como Azure e AWS. Para ambientes privados em que os servidores não podem se conectar diretamente à Internet, considere limitar o tráfego de saída apenas ao intervalo de IP do Azure publicado (consulte Intervalos de IP do Azure e Tags de Serviço).
Os recursos 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 em repouso
- Os certificados de cliente são criados e gerenciados automaticamente
- Armazenamento de segredos para gerenciar centralmente senhas/credenciais ou variáveis como nomes de servidores ou cadeias de conexão
- Gerencie centralmente a configuração do LCM do nó
- Atribuir configurações centralmente a nós clientes
- Liberar alterações de configuração para "grupos canários" para testes antes de chegar à produção
- Relatórios gráficos
- Detalhes de status no nível de granularidade de recursos DSC
- Mensagens de erro detalhadas de máquinas clientes para solução de problemas
- Integração com o Azure Log Analytics para alertas, tarefas automatizadas, aplicativo Android/iOS para relatórios e alertas
Serviço de pull DSC no Windows Server
É possível configurar um serviço pull para ser executado no Windows Server. Esteja ciente de que a solução de serviço pull incluída no Windows Server inclui apenas recursos de armazenamento de configurações e módulos para download e captura de dados de relatório em um banco de dados. Ele não inclui muitos dos recursos oferecidos pelo serviço no Azure e, portanto, não é uma boa ferramenta para avaliar como o serviço seria usado.
O serviço pull oferecido no Windows Server é um serviço Web no IIS que usa uma interface OData para disponibilizar arquivos de configuração DSC para nós de destino quando esses nós os solicitam.
Requisitos para usar um servidor pull:
- Um servidor executando:
- WMF/PowerShell 4.0 ou superior
- Função de servidor IIS
- Serviço DSC
- Idealmente, alguns meios de gerar um certificado, para proteger as credenciais passadas para o Local Configuration Manager (LCM) em nós de destino
A melhor maneira de configurar o Windows Server para hospedar o serviço pull é usar uma configuração DSC. Um script de exemplo é fornecido abaixo.
Sistemas de base de dados suportados
A partir da versão 17090 do Windows Server, o WMF 5.1 inclui suporte para a opção SQL Server para o Pull Service (Windows Feature DSC-Service). Isso fornece uma nova opção para dimensionar grandes ambientes DSC que não migraram para o Azure Automation DSC.
Para configurar o servidor pull para usar o SQL Server, defina SqlProvider como $true e SqlConnectionString como uma Cadeia de Conexão válida do SQL Server. Para obter mais informações, consulte Cadeias de conexão SqlClient. Para obter um exemplo de configuração do SQL Server com xDscWebService, primeiro leia Usando o recurso xDscWebService e, em seguida, revise 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 no GitHub.
Usando o recurso xDscWebService
A maneira mais fácil de configurar um servidor web pull é usar o recurso xDscWebService , incluído no módulo xPSDesiredStateConfiguration . As etapas a seguir explicam como usar o recurso em um Configuration que configura o serviço Web.
Chame o cmdlet Install-Module para instalar o módulo xPSDesiredStateConfiguration.
Obtenha um certificado SSL para o servidor DSC Pull de uma Autoridade de Certificação confiável, dentro da sua organização ou de uma autoridade pública. O certificado recebido da autoridade é geralmente no formato PFX.
Instale o certificado no nó que se tornará o servidor DSC Pull no local padrão, que deve ser
CERT:\LocalMachine\My. Anote a impressão digital do certificado.Selecione um GUID para ser usado como a chave de registro. Para gerar um usando o PowerShell, digite o seguinte no prompt PS e pressione enter:
[guid]::newGuid()ouNew-Guid. Essa chave será usada pelos nós clientes como uma chave compartilhada para autenticação durante o registro. Para obter mais informações, consulte a seção Chave de registro 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 pull.
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, passando a impressão digital do certificado SSL como o parâmetro certificateThumbPrint e uma chave de registro 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 cliente se registrem no servidor para que possam usar nomes de configuração em vez de uma ID de configuração, uma chave de registro que foi criada pela configuração acima é salva em um arquivo chamado RegistrationKeys.txt em C:\Program Files\WindowsPowerShell\DscService. A chave de registro funciona como um segredo compartilhado usado durante o registro inicial pelo cliente com o servidor pull. O cliente gerará um certificado autoassinado que é usado para autenticar exclusivamente no servidor pull assim que o registro for concluído com êxito. A impressão digital deste certificado é armazenada localmente e associada à URL do servidor pull.
Observação
As chaves de registro não são suportadas no PowerShell 4.0.
Para configurar um nó para autenticação com o servidor pull, a chave de registro precisa estar na metaconfiguração de qualquer nó de destino que será registrado com esse servidor pull. Observe que a RegistrationKey na metaconfiguração abaixo é removida depois que a máquina de destino se registra com êxito e que o valor deve corresponder ao RegistrationKeys.txt valor armazenado no arquivo no servidor pull ('140a952b-b9d6-406b-b416-e0f759c9c0e4' para este exemplo). Trate sempre o valor da chave de registo de forma segura, porque conhecê-lo permite que qualquer máquina de destino se registe no servidor pull.
[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
Observação
A seção ReportServerWeb permite que os dados de relatório sejam enviados para o servidor de recebimento.
A falta da propriedade ConfigurationID no arquivo de metaconfiguração significa implicitamente que o servidor pull está suportando a versão V2 do protocolo pull server, portanto, um registro inicial é necessário. Por outro lado, a presença de um ConfigurationID significa que a versão V1 do protocolo do servidor pull é usada e não há processamento de registro.
Observação
Em um cenário PUSH, existe um bug na versão atual que torna necessário definir uma propriedade ConfigurationID no arquivo de metaconfiguração para nós que nunca se registraram em um servidor pull. Isso forçará o protocolo V1 Pull Server e evitará mensagens de falha de registro.
Colocação de 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 você colocará módulos e configurações que estarão disponíveis para os nós de destino extrairem. Esses arquivos precisam estar em um formato específico para que o servidor pull os processe corretamente.
Formato do pacote do módulo de recursos DSC
Cada módulo de recurso precisa ser compactado e nomeado de acordo com o seguinte padrão <Module Name>_<Module Version>.zip.
Por exemplo, um módulo chamado xWebAdminstration com uma versão de módulo de 3.1.2.0 seria nomeado xWebAdministration_3.1.2.0.zip. Cada versão de um módulo deve estar contida em um único arquivo zip.
Como há apenas uma única versão de um recurso em cada arquivo zip, o formato de módulo adicionado no WMF 5.0 com suporte para várias versões de módulo em um único diretório não é suportado. Isso significa que, antes de empacotar módulos de recursos DSC para uso com o servidor pull, você precisará fazer uma pequena alteração na estrutura de diretórios. O formato padrão de módulos que contêm recurso DSC no WMF 5.0 é <Module Folder>\<Module Version>\DscResources\<DSC Resource Folder>\. Antes de empacotar para o servidor de receção, remova a <Module version> pasta para que o caminho se torne <Module Folder>\DscResources\<DSC Resource Folder>\. Com essa alteração, compacte a pasta como descrito acima e coloque esses arquivos zip na pasta ModulePath .
Use New-DscChecksum <module zip file> para criar um arquivo de soma de verificação para o módulo recém-adicionado.
Formato MOF de configuração
Um arquivo MOF de configuração precisa ser emparelhado com um arquivo de soma de verificação para que um LCM em um nó de destino possa validar a configuração. Para criar uma soma de verificação, chame o cmdlet New-DscChecksum . O cmdlet usa um parâmetro Path que especifica a pasta onde o MOF de configuração está localizado. O cmdlet cria um arquivo de soma de verificação chamado ConfigurationMOFName.mof.checksum, onde ConfigurationMOFName é o nome do arquivo mof de configuração. Se houver mais de um arquivo MOF de configuração na pasta especificada, uma soma de verificação será criada para cada configuração na pasta. Coloque os arquivos MOF e seus arquivos de soma de verificação associados na pasta ConfigurationPath .
Observação
Se você alterar o arquivo MOF de configuração de qualquer forma, você também deve recriar o arquivo de soma de verificação.
Ferramentas
Para configurar, validar e gerenciar o servidor pull, use as seguintes ferramentas incluídas como exemplos na versão mais recente do módulo xPSDesiredStateConfiguration:
Um módulo que ajudará com o empacotamento de módulos de recursos DSC e arquivos de configuração para uso no servidor de receção. 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 -ForceUm script que valida o servidor de pull está configurado corretamente. PullServerSetupTests.ps1.
Soluções Comunitárias para Pull Service
A comunidade DSC criou várias soluções para implementar o protocolo pull service. Para ambientes locais, eles oferecem recursos de pull service e uma oportunidade de contribuir de volta para a comunidade com aprimoramentos incrementais.
Configuração do cliente pull
Os tópicos a seguir descrevem a configuração de clientes pull em detalhes:
- Configurar um cliente de receção DSC usando um ID de configuração
- Configurar um cliente de receção DSC usando nomes de configuração
- Configurações parciais