Compreender a função do DSC num pipeline CI/CD

Este artigo descreve os tipos de abordagens disponíveis para combinar configurações e recursos. O objetivo de cada cenário é o mesmo: reduzir a complexidade quando são preferenciais múltiplas configurações para atingir um estado final de implementação do servidor. Um exemplo disto seria várias equipas que contribuíssem para o resultado de uma implementação de servidor, como um proprietário da aplicação que mantém o estado da aplicação e uma equipa central a lançar alterações às linhas de base de segurança. As nuances de cada abordagem, incluindo os benefícios e os riscos, são detalhadas aqui.

Tipos de Técnicas de Criação Colaborativa

Existem duas soluções incorporadas na Configuration Manager Local para ativar este conceito:

Conceito	Informações Detalhadas
Configurações Parciais	Documentação
Recursos Compostos	Documentação

Compreender o impacto de cada abordagem

Qualquer uma destas soluções pode ser utilizada para gerir o resultado de uma implementação de servidor. No entanto, existe uma diferença significativa no impacto da utilização de cada abordagem.

Configurações Parciais

Ao utilizar Configurações Parciais, a Configuration Manager Local é configurada para gerir múltiplas configurações de forma independente. As configurações são compiladas de forma independente e, em seguida, atribuídas ao nó. Isto requer que o LCM seja configurado com antecedência com o nome de cada configuração.

As Configurações Parciais fornecem dois ou mais controlos completos das equipas sobre a configuração de um servidor, muitas vezes sem o benefício da comunicação ou colaboração.

Os clientes forneceram feedback de que isto pode levar a conflitos de recursos, substituições não intencionais e, em última análise, perda do verdadeiro controlo de configuração do recurso.

Além disso, os clientes forneceram feedback de que, ao utilizar este modelo, é pouco provável que cada alteração de configuração das equipas de controlo seja totalmente testada através de um pipeline de versão, o que resulta em resultados inesperados na produção.

É fundamental que seja utilizado um único pipeline para avaliar todas as alterações lançadas nos servidores.

Na ilustração abaixo, a Equipa B lança a configuração parcial para a Equipa A. Em seguida, a Equipa A executa os testes num servidor com ambas as configurações aplicadas. Neste modelo, apenas uma autoridade tem permissão para fazer alterações na produção.

Quando são necessárias alterações da Equipa B, devem submeter um Pedido Pull no ambiente de controlo de origem da Equipa A. Em seguida, a Equipa A analisaria as alterações com a automatização de teste e a versão para produção quando houver confiança de que as alterações não causarão erros nas aplicações ou serviços alojados pelo servidor.

Recursos Compostos

Um recurso composto é simplesmente uma Configuração do DSC empacotada como um recurso. Não existem requisitos especiais para configurar o LCM para aceitar recursos compostos. Os recursos são utilizados numa nova configuração e uma compilação única resulta num ficheiro MOF.

Existem dois cenários comuns para recursos compostos. A primeira é reduzir a complexidade e abstrair conceitos exclusivos. A segunda é permitir que as linhas de base sejam empacotadas para que uma equipa de aplicações implemente em segurança através do pipeline de lançamento para produção depois de todos os testes terem passado.

Configuration Name
{
  File 1
  {
    Ensure = "Present"
    Path = "c:\inetpub\file1.zip"
    Source = "http://uri/file1.zip"
  }
  Service A
  {
    Ensure = "Present"
    Name = "ServiceA"
    Status = "Running"
  }
  SecurityBaseline Settings
  {
    Ensure = "Present"
    Datacenter = "NorthAmerica"
  }
}

Os recursos compostos promovem a composição e a colaboração através de um pipeline enquanto criam maturidade operacional.

Poderá já estar a utilizar recursos compostos sem se aperceber. Um exemplo é ServiceSet. Este recurso gere o estado de vários Serviços Windows sem os listar individualmente. A propriedade Nome aceita uma matriz de cadeias para fornecer o nome de cada serviço. Quando a configuração é compilada, o MOF irá conter uma secção de Serviço exclusiva para cada um dos Nomes transmitidos ao ServiceSet.

As organizações podem ter "agentes" ou "middleware" que devem ser instalados em todos os servidores. Um recurso composto é a melhor resposta para gerir as dependências, a configuração e a configuração de tais ferramentas e utilitários.

A pessoa ou equipa responsável por soluções que abrangem vários servidores cria uma configuração que contém os respetivos requisitos. Em seguida, a configuração seria empacotada como um recurso composto com as instruções fornecidas na documentação do recurso composto. Por fim, o novo recurso composto deve ser publicado numa localização, como uma partilha de ficheiros ou um feed NuGet, onde as equipas de aplicações podem consumi-lo nas respetivas configurações.

Sempre que a equipa lança uma nova versão, incrementa o número da versão no manifesto do módulo para o respetivo recurso composto. As equipas de aplicações incluem o recurso composto na configuração que criam para gerir dependências de aplicações. Quando as equipas de Operações/Segurança lançam uma nova versão do respetivo recurso, notificam as equipas de aplicações de uma nova alteração.

As equipas de aplicações podem acionar uma versão para produção em que a única alteração é nas linhas de base. No entanto, isto proporciona uma oportunidade para avaliar o impacto nas aplicações antes do risco de uma indisponibilidade do serviço.

Nota

Os comentários sobre a utilização de recursos compostos incluem críticas de que fazer alterações requer compilar e lançar um novo MOF. Esta ação é propositada. Cada nova versão de configuração deve incluir uma referência estática a uma versão específica de cada recurso e deve ser validada por testes antes de chegar aos nós do servidor de produção. O processo de teste e libertação de alterações do controlo de origem cria um ambiente seguro para libertar alterações em lotes pequenos mas frequentes.