Compartilhar via

Serviço de Pull de Desired State Configuration

  • Artigo

Importante

O Servidor de Recepção (Recurso do Windows Serviço DSC) é um componente compatível com o Windows Server, no entanto, não há planos de oferecer novos recursos ou funcionalidades. Gostaríamos que você soubesse que uma versão mais recente do DSC agora está em disponibilidade geral, gerenciada por um recurso de Azure Policy configuração de convidado nomeada. O serviço de configuração de convidado combina recursos de extensão de DSC, State Configuration da Automação do Azure e os recursos mais solicitados dos comentários dos clientes. A configuração de convidado também inclui suporte a computadores híbridos por meio de servidores habilitados para Arc.

O LCM (Gerenciador de Configurações Local) pode ser gerenciado centralmente por uma solução de Serviço de Pull. Ao usar essa abordagem, o nó que está sendo gerenciado é registrado com um serviço e uma configuração é atribuída a ele em configurações de LCM. A configuração e todos os recursos de DSC necessários como dependências para a configuração são baixados para o computador e usados pelo LCM para gerenciar a configuração. As informações sobre o estado do computador que está sendo gerenciado são carregadas no serviço para relatório. Esse conceito é conhecido como "serviço de pull".

As opções atuais para o serviço de pull incluem:

  • Serviço de Configuração de Estado Desejado da Automação do Azure
  • Um serviço de pull em execução no Windows Server
  • Soluções de software livre mantidas pela comunidade
  • Um compartilhamento SMB

A escala recomendada para cada solução é a seguinte:

Solução Nós clientes
Servidor de Pull do Windows usando o banco de dados MDB/ESENT Até 500 nós
Servidor de Pull do Windows usando o banco de dados SQL Até 3.500 nós
DSC de Automação do Azure Ambientes pequenos e grandes

A solução recomendada, e a opção com a maioria dos recursos disponíveis, é DSC de Automação do Azure. Não foi identificado um limite superior 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 AWS e o Azure. Para ambientes privados, onde os servidores não podem se conectar diretamente à Internet, considere limitar o tráfego de saída apenas ao intervalo de IPs do Azure publicado (consulte Intervalos de IP de Datacenter do Azure).

Entre os recursos do serviço online que não estão disponíveis no serviço de pull no Windows Server estão:

  • Todos os dados são criptografados em trânsito e em repouso
  • Certificados de cliente são criados e gerenciados automaticamente
  • Armazenamento de segredos para gerenciar centralmente senhas/credenciais, ou variáveis como nomes de servidor ou cadeias de conexão
  • Gerenciar centralmente o nó Configuração do LCM
  • Atribuir centralmente configurações a nós do cliente
  • Alterações na configuração de versão de "grupos canário" para teste antes de chegar à produção
  • Relatório gráfico
    • Detalhes de status no nível de granularidade de recursos de DSC
    • Mensagens de erro detalhadas de computadores cliente para solução de problemas
  • Integração com o Azure Log Analytics para alertas, tarefas automatizadas, aplicativo para Android/iOS para relatórios e alertas

Serviço de pull de DSC no Windows Server

É possível configurar um serviço de pull para ser executado no Windows Server. Fique ciente de que a solução de serviço de pull incluída no Windows Server contém apenas as funcionalidades de armazenamento de configurações e módulos para download e de captura de dados de relatório para um banco de dados. Ela não inclui muitas das funcionalidades oferecidas pelo serviço no Azure e, portanto, não é uma boa ferramenta para avaliar o modo como o serviço seria usado.

O serviço de pull oferecido no Windows Server é um serviço Web no IIS que utiliza uma interface OData para disponibilizar arquivos de configuração DSC para nós de destino quando são pedidos por tais nós.

Requisitos para usar um servidor de pull:

  • Um servidor que execute:
    • WMF/PowerShell 4.0 ou posterior
    • Função de servidor do IIS
    • Serviço de DSC
  • Idealmente, alguns meios de gerar um certificado para proteger as credenciais passadas para o Gerenciador de Configurações Local (LCM) em nós de destino

A melhor maneira de configurar o Windows Server para hospedar o serviço de pull é usar uma configuração DSC. Um script de exemplo é fornecido abaixo.

Sistemas de banco de dados com suporte

WMF 4.0 WMF 5.0 WMF 5.1 WMF 5.1 (Windows Server Insider Preview 17090)
MDB ESENT (padrão), MDB ESENT (padrão), MDB ESENT (padrão), SQL Server, MDB

A partir da versão 17090 do Windows Server, o SQL Server é uma opção compatível com o serviço de pull (Recurso do Windows Serviço DSC). Essa é uma nova opção para dimensionar grandes ambientes de DSC que não foram migrados para o DSC de Automação do Azure.

Observação

O suporte ao SQL Server não será adicionado às versões anteriores do WMF 5.1 (ou mais antigas) e só estará disponível nas versões do Windows Server maiores ou iguais à 17090.

Para configurar o servidor de recepção para usar o SQL Server, defina SqlProvider para $true e SqlConnectionString para uma cadeia de conexão válida do SQL Server. Para obter mais informações, confira Cadeias de conexão SqlClient. Para obter um exemplo de configuração do SQL Server com xDscWebService, primeiro leia Como usar o recurso xDscWebService e examine 2-xDscWebService_RegistrationUseSQLProvider_Config.ps1 no GitHub.

Usando o recurso xDscWebService

A maneira mais fácil de configurar um servidor de recepção Web é usar o recurso xDscWebService, incluído no módulo xPSDesiredStateConfiguration. As etapas a seguir explicam como usar o recurso em uma Configuration que defina o serviço Web.

  1. Chame o cmdlet Install-Module para instalar o módulo xPSDesiredStateConfiguration.

    Observação

    Install-Module está incluído no módulo PowerShellGet, que está incluído no PowerShell 5.0 e posterior.

  2. Obtenha um certificado SSL para o servidor de Pull de DSC de uma Autoridade de Certificação confiável, seja de dentro de sua organização ou de uma autoridade pública. O certificado recebido da autoridade geralmente está no formato PFX.

  3. Instale o certificado no nó que se tornará o servidor de pull de DSC na localização padrão, que deve ser CERT:\LocalMachine\My.

    • Anote a impressão digital do certificado.

  4. Selecione um GUID a ser usado como a Chave de Registro. Para gerar um usando o PowerShell, insira o seguinte no prompt do PS e pressione enter: [guid]::newGuid() ou New-Guid. Essa chave será usada por nós de cliente como uma chave compartilhada para autenticação durante o registro. Para obter mais informações, confira a seção Chave de registro abaixo.

  5. No ISE do PowerShell, inicie (F5) o script de configuração a seguir (incluído na pasta do módulo xPSDesiredStateConfiguration como Sample_xDscWebServiceRegistration.ps1). Esse script configura o servidor de 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
        }
    }
}

  6. 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 Registro

Para permitir que os nós clientes sejam registrados no servidor para poderem 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 de pull. O cliente gerará um certificado autoassinado, que será usado para realizar uma autenticação exclusiva no servidor de recepção depois que o registro for concluído com êxito. A impressão digital do certificado é armazenada localmente e associada à URL do servidor de pull.

Observação

Não há suporte para chaves de registro no PowerShell 4.0.

Para configurar um nó para ser autenticado no servidor de recepção, a chave de registro deverá estar na metaconfiguração do nó de destino que será registrado nesse servidor de recepção. Observe que a RegistrationKey na metaconfiguração abaixo é removida após o computador de destino ser registrado com sucesso e que o valor deve corresponder ao valor armazenado no arquivo RegistrationKeys.txt no servidor de pull ('140a952b-b9d6-406b-b416-e0f759c9c0e4' neste exemplo). Sempre trate o valor da chave do registro com segurança, porque o conhecimento permite que qualquer computador de destino seja registrado com o servidor de pull.

[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

Observação

A seção ReportServerWeb permite que dados de relatório sejam enviados ao servidor de pull.

A falta da propriedade ConfigurationID no arquivo metaconfiguração significa, implicitamente, que esse servidor de pull dá suporte à versão V2 do protocolo de servidor de pull, de modo que um registro inicial é necessário. Por outro lado, a presença de uma ConfigurationID significa que a versão V1 do protocolo do servidor de pull é usada e não há nenhum processamento de registro.

Observação

Em um cenário de PUSH, há um bug na versão atual que exige a definição de uma propriedade ConfigurationID no arquivo de metaconfiguração para nós que nunca foram registrados em um servidor de pull. Isso forçará o uso do protocolo de Servidor de Pull V1 e evitará mensagens de falha de registro.

Colocando configurações e recursos

Após a instalação do servidor de pull ser concluída, as pastas definidas pelas propriedades ConfigurationPath e ModulePath na configuração do servidor de pull são onde você colocará módulos e configurações que estarão disponíveis para pull pelos nós de destino. Esses arquivos precisam estar em um formato específico para que o servidor de recepção processe-os corretamente.

Formato de 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 do módulo correspondente a 3.1.2.0 seria nomeadoxWebAdministration_3.1.2.0.zip. Cada versão de um módulo deve estar contido em um único arquivo zip. Como há apenas uma única versão de um recurso em cada arquivo zip, não há suporte para o formato do módulo adicionado ao WMF 5.0 com suporte para várias versões de módulo em um único diretório. Isso significa que antes de empacotar módulos de recursos DSC para uso com o servidor de pull, você precisará fazer uma pequena alteração na estrutura de diretórios. O formato padrão de módulos contendo recursos DSC no WMF 5.0 é {Module Folder}\{Module Version}\DscResources\{DSC Resource Folder}\. Antes de empacotar o servidor de pull, remova a pasta {versão do módulo} para que o caminho se torne {Module Folder}\DscResources\{DSC Resource Folder}\. Com essa alteração, compacte a pasta conforme 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 na qual se encontra o MOF de configuração. O cmdlet cria um arquivo de soma de verificação chamado ConfigurationMOFName.mof.checksum, em que ConfigurationMOFName é o nome do arquivo MOF de configuração. Se houver mais de um arquivo MOF de configuração na pasta especificada, será criada uma soma de verificação para cada configuração na pasta. Coloque os arquivos MOF e os arquivos de soma de verificação associados na pasta ConfigurationPath.

Observação

Se alterar o arquivo MOF de configuração de qualquer forma, você também deverá recriar o arquivo de soma de verificação.

Ferramentas

Para facilitar a configuração, validação e gerenciamento do servidor de pull, as ferramentas a seguir são incluídas como exemplos na versão mais recente do módulo xPSDesiredStateConfiguration:

  1. Um módulo que ajudará com empacotamento de módulos de recursos DSC e arquivos de configuração para uso no servidor de 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

  2. Um script que valida o Servidor de Pull está configurado corretamente. PullServerSetupTests.ps1.

Soluções da comunidade para o Serviço de Pull

A comunidade de DSC criou várias soluções para implementar o protocolo de serviço de pull. Para ambientes locais, elas oferecem funcionalidades de serviço de pull e uma oportunidade de retribuir à comunidade, contribuindo com melhorias incrementais.

Configuração do cliente de pull

Os tópicos a seguir descrevem em detalhes a configuração de clientes de pull:

Confira também