Desired State Configuration Pull Service

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:

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

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.

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.

1. 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.

2. 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.

3. 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.

4. 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() ou New-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.

5. 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
           }
       }
   }
   

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

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

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.

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 .

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:

1. 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
   

2. 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.

• Rebocador
• DSC-TRÆK

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

Ver também

• Descrição Geral do Windows PowerShell Desired State Configuration
• Aplicar configurações
• Utilizar um servidor de relatório de DSC
• [MS-DSCPM]: Desired State Configuration Pull Model Protocol
• [MS-DSCPM]: Desired State Configuration Pull Model Protocol Errata