Algum sistema de gerenciamento de configuração suporta explicitamente as alterações de configuração feitas diretamente em um servidor?

Question

Em geral (até onde eu posso ver) os principais sistemas de gerenciamento de infra-estrutura / configuração (Puppet, Chef, Ansible e SaltStack) são baseados na filosofia de que seus servidores são "gado" e não "pets", e Parece que eles podem ser antagônicos à idéia de que você faria uma alteração de configuração diretamente em um servidor.

Embora eu tenha trabalhado com Chef e Puppet and Salt, sempre foi do ponto de vista de um desenvolvedor trabalhar com o Vagrant para configurar caixas individuais para desenvolvimento, então minha experiência não ajuda a responder a essa pergunta.

A pergunta é: algum desses sistemas suporta o caso de uso em que você faz uma mudança diretamente para um servidor e o deixa lá por um tempo sem se preocupar que um daemon local irá sobrescrevê-lo com a configuração oficial? Você deve ser capaz de fazer a alteração (e idealmente definir a janela de tempo durante a qual ela é protegida contra sobrescrever) sem quaisquer alterações significativas (por exemplo) nas receitas do Chef ou nos estados de sal. O propósito deste caso de uso é evitar que uma mudança de configuração de cinco minutos seja afetada por fricção corporativa e as complicações de encontrar o estado de sal correto (por exemplo) e garantir que não haja efeitos colaterais e passar pelo lançamento / implantação faça um ciclo e teste para ter certeza de que você não fez nada no processo.

Se você quiser um exemplo mais concreto, suponha que você queira ajustar suas configurações de logrotate para um número de logs, para equilibrar a economia de espaço em disco e o acesso a dados históricos. Você tem uma ideia de quantos dados salvará em determinada configuração e quantos dados você acha que precisa manter, mas não tem 100% de certeza. Seria bom começar apenas fazendo a mudança, e ver (1) alguém reclama que eles precisam de mais dados históricos para alguma tarefa de depuração, ou (2) você não está economizando o máximo de espaço em disco que você esperava e precisa salvar .

Uma alteração de cinco minutos pode, na verdade, ser uma alteração de cinco minutos, se seu sistema de gerenciamento de configuração permitir que ele seja um, e depois que você quiser que essas alterações sejam feitas em todos os seus caixas que cumprem um papel específico, você pode deixar Chef / Puppet / Salt / Ansible gerenciar isso para você.

Observação: não estou perguntando sobre um caso de uso em que o sistema de gerenciamento de configuração ainda não está gerenciando um determinado tipo de arquivo de configuração, mas um caso em que <<> já gerenciar um determinado tipo de arquivo de configuração, mas você deseja fazer alterações locais e tê-las em primeiro lugar na máquina em questão e não ser sobrescrito.

Algum desses sistemas suporta meu caso de uso? (Sem precisar que eu lute com o sistema ou faça backflips para que ele funcione.)

    

Answer 1

Os sistemas de gerenciamento de configuração suportam esse caso de uso desabilitando-os no host de destino durante a alteração. Usando o chef como exemplo, você desabilitaria chef-client no nó. Isso faria com que o nó aparecesse como "obsoleto" no servidor Chef, mas isso é um lembrete útil de que o nó está fora de conformidade e que a alteração deve ser ampliada ou revertida.

Para arquivos individuais, você pode fazer um chattr + i, que nenhuma ferramenta que eu tenha visto sabe ignorar.

Um pensamento extra para o chef - para modelos de arquivo, em que o arquivo não existia antes da execução original do chef, você pode dizer ao chef: create_if_missing de forma que ele toque no arquivo apenas uma vez.

    

Answer 2

Você não mencionou o DSC do PowerShell, mas vou lançar alguns métodos para isso - especialmente porque o PowerShell está chegando a outros sistemas além do Windows. Alguns desses métodos podem ter equivalentes nas outras opções.

Posso pensar em quatro métodos para lidar com seu caso com o DSC:

1. Se você alterar algo que não foi testado por nenhum dos recursos, ele simplesmente nunca será pego. Espero que isso também se aplique a outras opções baseadas em receitas.
2. Defina o LCM como Aplicar e monitorar e faça a alteração por qualquer meio que você quiser. Você pode testar se o seu sistema ainda está em conformidade, mas não tentará corrigi-lo.

As seguintes opções têm a vantagem de tornar a sua alteração "parte da receita" e recursiva.

3. Implante seu sistema com uma configuração explícita de configurações parciais, nas quais suas configurações "extras" não são publicadas inicialmente, mas podem ser adicionadas posteriormente. Isso pressupõe que qualquer configuração que você planeje definir "temporariamente" não está em conflito com uma configuração em outra configuração. Isso realmente lhe dá a oportunidade de fazer sua alteração "parte da receita" sem precisar regenerar completamente a configuração.
4. Publique uma configuração totalmente nova incorporando sua alteração e inicie a configuração. Como a opção anterior, a configuração se aplicará idempotently (apenas novas alterações são feitas sem afetar nada definido anteriormente).

Independentemente de você usar modelos DSC push ou pull, você pode fazer essas alterações para uma única máquina ou várias.

    

Answer 3

Desconsiderando no momento a possível incongruência do conceito de gerenciar a configuração de um sistema a partir de um sistema CM e não fazê-lo ao mesmo tempo em que os comentadores já perceberam ...

Deve-se mencionar que, para este caso de uso, geralmente é possível fazer uso do que se tornou uma convenção com o software de servidor moderno - .d diretórios de configuração que permitem a inserção de trechos de configuração extras nos lugares certos.

Dessa forma, você pode fazer com que seu CM gerencie a configuração para você por meio de, por exemplo, /etc/logrotate.d/local-whatever , enquanto ao mesmo tempo você ainda pode mexer em uma máquina em particular adicionando /etc/logrotate.d/local-aaa-whatever ou similar, o que faria com que o software processasse suas configurações sobrepostas.

Obviamente, se CM tiver receitas que visem controlar a totalidade de /etc/logrotate.d/ , você ainda não terá outro recurso além de fazer coisas dentro do CM.