Get best of the week

De que lado você está: Empurre e Puxe na Configuração de Estado Desejado

Já descrevemos como descrever a configuração no DSC (Desired State Configuration) e desmontamos o agente LCM (Local Configuration Manager) interno para aplicar a configuração no servidor. Na primeira parte do artigo, caminhamos passo a passo sobre os principais recursos da ferramenta, juntamente com Evgeny Parfenov, da DataLine .

Aqui, abordamos as configurações e os recursos nos modos Push e Pull.



O que diremos:


  1. Diferenças entre os modos Push e Pull
  2. Modo push em detalhes
  3. Modo de puxar em detalhes

Diferenças entre os modos Push e Pull


No modo Push, iniciamos manualmente ou por script o processo de aplicação de alterações no servidor (local ou remotamente). O Gerenciador de configuração local (LCM) aplica a configuração interativamente.

No modo Pull, o agente LCM agendado no servidor compara sua configuração com a configuração publicada no repositório de configuração compartilhado. Se houver alterações, a configuração é copiada localmente e aplicada.

Os prós e os contras de ambos os modos de operação são bastante óbvios.
EmpurrarPuxar
+
  1. Custo. Não requer a instalação de servidores adicionais.
  2. Arquitetura simples. Todas as configurações são armazenadas localmente no formato conveniente para o administrador.
  3. Adequado para teste. Dsc
  4. DevOps Way. Ao implantar servidores, é muito fácil automatizar e se encaixar na filosofia da infraestrutura como um código.
  5. run-once .
  1. . .
  2. . DSC .
  3. Azure Automation State Configuration, Windows Server 2012R2+
–
  1. On-Premise c . , .
  1. , .
  2. On-Premise GPO, .
  3. — , .
A configuração de recursos também é um pouco diferente para modos diferentes. Como lembramos, para usar um recurso, você precisa instalá-lo localmente e no servidor.

No caso de usar o modo Push, o administrador deve primeiro instalar todos os recursos necessários no servidor gerenciado e no PC, de onde a configuração será enviada.

No modo Pull, o agente DSC no servidor gerenciado pode instalar independentemente todos os recursos necessários a partir do servidor Pull; a tarefa do administrador é colocá-los no servidor Pull. No entanto, lembramos que é impossível prever a aplicação da configuração no modo Pull, pois o GPO não é uma entrega garantida de configurações.

Modo push em detalhes






O processo de nível superior de gravação e aplicação de configurações DSC pode ser representado da seguinte forma: No primeiro estágio ( Autoria ), descrevemos a configuração usando qualquer IDE que seja conveniente para nós (Bloco de Notas, PowerShell ISE, Código do Visual Studio e outros). Após a conclusão, compilamos os arquivos de configuração mof (o processo de compilação é descrito em nosso artigo anterior ).

No segundo estágio ( armazenamento temporário / compilação ), começamos a aplicar a configuração do arquivo mof compilado usando o cmdlet Start-DSCConfiguration . No processo, o servidor de gerenciamento transmite o arquivo .mof do servidor LCM, que deve aplicar a configuração.
Nesse caso, é melhor usar a opção -Verbose. Para controle completo do processo de configuração:

PS C:\windows\system32> Start-DscConfiguration -Path C:\EnvironmentVariable_Path\ -Wait -Verbose

# C 
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer COMPUTER with user sid
S-1-5-21-SID.

#  
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]
VERBOSE: [COMPUTER]: LCM:  [ Start  Resource ]  [[Environment]CreatePathEnvironmentVariable]

#       (test)
VERBOSE: [COMPUTER]: LCM:  [ Start  Test     ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' does not exist.
VERBOSE: [COMPUTER]: LCM:  [ End    Test     ]  [[Environment]CreatePathEnvironmentVariable]  in 0.1320 seconds.
#      “Environment variable 'TestPathEnvironmentVariable' does not exist”

#       
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' created with value 'TestValue'.
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]  [[Environment]CreatePathEnvironmentVariable]  in 0.0690 seconds.
VERBOSE: [COMPUTER]: LCM:  [ End    Resource ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]    in  2.1900 seconds.
#  

#  
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 2.749 seconds

Pode-se observar que o mecanismo verificou a presença da variável, não a encontrou e criou uma nova, de acordo com a configuração especificada:



Na terceira etapa ( Execução ), o agente DSC LCM entra no jogo. Ele recebe um arquivo mof, verifica, coloca-o em uma pasta $env:systemRoot/system32/configuratione inicia um fluxo de trabalho de aplicação do arquivo de configuração:

  1. LCM recebe, aplica o arquivo de configuração. O arquivo é renomeado para pending.mof e colocado em$env:systemRoot/system32/configuration
    • Se o aplicativo do arquivo de configuração falhar, o arquivo pending.mof permanecerá e o LCM tentará aplicá-lo no próximo ciclo.
  2. Se o arquivo current.mof já estiver na pasta, ele será renomeado para previous.mof
  3. Se o aplicativo do arquivo de configuração for concluído com êxito, o LCM o renomeia para current.mof
  4. O arquivo current.mof é copiado para o arquivo backup.mof

Graficamente, o fluxo de trabalho pode ser representado da seguinte maneira:



Para gerenciar arquivos de configuração diferentes, existe um cmdlet Remove-DSCConfigurationDocument que permite excluir documentos específicos, se necessário por algum motivo. No entanto, nada nos impede de removê-los manualmente.

Modo de puxar em detalhes


O modo pull é mais difícil de implantar e configurar, mas simplifica bastante o processo de gerenciamento de servidores conectados a ele.

O esquema geral será mais ou menos assim: o



modo Pull requer a implantação de um servidor Pull. Na verdade, é um servidor da Web comum, que pode fornecer aos clientes arquivos e recursos mof que podem ser necessários ao aplicar configurações de arquivos mof. Este último simplifica bastante o processo de gerenciamento e configuração de servidores, pois a tarefa de fornecer os recursos necessários recai sobre o cliente. O servidor Pull atua ao mesmo tempo como repositório \ repositório de recursos.

O servidor pull pode fornecer acesso a recursos e arquivos de configuração por meio de dois protocolos:

  1. SMB. . DFS-R. , , . SMB , Kerberos.
  2. Http\https. . IIS.

A instalação do servidor pull pode ser feita através dos recursos regulares que a equipe de desenvolvimento do DSC oferece. Mais detalhes podem ser encontrados aqui . Ou use soluções orientadas pela comunidade: aqui ou aqui .

O fluxo de trabalho para trabalho adicional com o servidor pull é o seguinte:

  1. Configuramos os clientes (LCM) para trabalhar com um servidor pull.
  2. Carregar arquivos de recursos para o servidor pull.
  3. Preparamos arquivos de configuração do cliente (gravação e compilação) e arquivos com somas de verificação.
  4. Aprecie o resultado.

Configurando Clientes (LCM) para Trabalhar com um Servidor Pull

Para fazer isso, use as seguintes configurações do LocalConfigurationManager (v5) :

Bloco de configurações:

  • CertificateID - indica a impressão digital do certificado para proteger logins / senhas transmitidas na configuração.
  • ID da configuração - contém o GUID do cliente. Somente as configurações que contêm seu GUID no nome do arquivo de configuração serão aplicadas ao cliente. A configuração é deixada para compatibilidade com versões mais antigas do servidor pull. É melhor usar a configuração RegistrationKey.
  • RefreshMode - para trabalhar com servidores Pull, especifique Pull nesta configuração.

Bloco ConfigurationRepositoryWeb:

  • AllowUnsecureConnection - permitir \ não permitir conexão sem autenticação.
  • CertificateID - indica a impressão digital do certificado no cliente, que será usada no processo de autenticação mútua com o servidor.
  • ConfigurationNames - uma matriz de nomes de configuração que serão aplicados ao cliente.
  • RegistrationKey - um segredo gerado no servidor, usado pelo cliente para se registrar no servidor.
  • ServerURL - URL do servidor Pull com configurações.

Bloco ResourceRepositoryWeb:

  • AllowUnsecureConnection - permitir \ não permitir conexão sem autenticação.
  • CertificateID - indica a impressão digital do certificado no cliente, que será usada no processo de autenticação mútua com o servidor.
  • RegistrationKey - um segredo gerado no servidor, usado pelo cliente para se registrar no servidor.
  • ServerURL - URL do servidor Pull com recursos.

Bloco ReportServerWeb:

  • AllowUnsecureConnection - permitir \ não permitir conexão sem autenticação.
  • CertificateID - indica a impressão digital do certificado no cliente, que será usada no processo de autenticação mútua com o servidor.
  • RegistrationKey - um segredo gerado no servidor, usado pelo cliente para se registrar no servidor.
  • ServerURL - URL do servidor Pull com relatórios.

Fazendo Upload de Arquivos de Recursos para o Servidor Pull

Depois de aplicar as novas configurações no LCM, que o ensinará a usar o servidor Pull, você poderá fazer upload de arquivos de recursos para o servidor . Os recursos são carregados no servidor na forma de arquivos zip (a pasta com o recurso é compactada em zip). Regra para nomear esse arquivo:

{ModuleName}_{Version}.zip

O local do arquivo padrão $env:PROGRAMFILES\WindowsPowerShell\DscService\Modules. Ao instalar o servidor Pull, essa pasta pode ser redefinida. Além do arquivo com a pasta do recurso compactada em zip, você também deve colocar o arquivo com a soma de verificação desse recurso compactado no mesmo local. Por exemplo, assim:

New-DscChecksum -Path .\xPSDesiredStateConfiguration_8.4.4.0.zip

Colocando Arquivos de Configuração do Cliente no Servidor Pull

É importante observar aqui que podemos usar dois modos de operação do cliente nesse caso (na verdade dois e meio): o cliente do servidor receberá a configuração usando o ConfigurationID ou o cliente usará o nome da configuração - ConfigurationName . Se for necessário aplicar várias configurações, todas elas poderão ser especificadas no Nome da Configuração, mas você precisará configurar o LCM para trabalhar com configurações parciais.

Ao usar o ConfigurationID, é preciso enfatizar que o arquivo de configuração mof que será aplicado ao cliente conterá um GUID (ele está contido no ConfigurationID). No caso de usar o ConfigurationName, o arquivo mof conterá o nome da configuração, que especificaremos em ConfigurationName. Nos dois casos, além do arquivo mof, o arquivo de soma de verificação de configuração também será colocado lá:

New-DscChecksum -Path '.\' -Force

Em conclusão


Examinamos duas maneiras de aplicar alterações ao servidor nos modos Push e Pull. Examinamos os recursos de uso e tentamos explicar todas as nuances que podem surgir ao trabalhar com esses modos no DSC. Se você ainda tiver dúvidas, vamos discutir nos comentários. E se você não teve visibilidade suficiente, venha para a nossa reunião on-line em 28 de maio: analisaremos os sistemas de comunicações unificadas e recursos de comunicação (configurando o upload de logs do Exchange no Elastic, Microsoft Endpoint Manager para gerenciar iOS, Android e Windows 10) e falaremos com mais detalhes sobre os limites de aplicabilidade Configuração de estado desejado do PowerShell. Você só precisa se registrar .

More articles:


All Articles