Como reverter uma configuração com fantoche

Question

Eu escrevi um módulo que escreve uma configuração para o rsyslog em /etc/rsyslog.d/60-custconfig.conf usando o fantoche.

Quando eu adiciono o módulo ao nó, ele funciona, mas se eu excluir o comentário ou excluir a chamada do módulo no nó, ele deverá remover o arquivo? se não, existe uma maneira de reverter uma configuração ou instalação?

    

Answer 1

Você não reverte as ações que o Puppet realizou removendo o recurso. Ao remover o recurso de seus manifestos, você está apenas dizendo ao Puppet para não gerenciá-lo (mais).

Além disso, Puppet simplesmente não lembra / sabe sobre os estados anteriores, então não pode voltar a isso. Apenas tenta mudar o sistema para um estado que você define nos manifestos.

Uma maneira que vejo aqui é incluir novamente o recurso file , mas agora com ensure => absent :

file {
    '/etc/rsyslog.d/60-custconfig.conf':
    ensure => absent,
}

Você também pode alterar o design dos módulos do Puppet desta forma:

• Gerenciar todos os arquivos de configuração do rsyslog em um módulo rsyslog.
• Crie tipos definidos personalizados virtuais a partir de outros módulos que exigem a alteração no rsyslog.
• No módulo rsyslog, colete as sub-rotinas de configuração virtual e instrua-a para excluir todos os recursos indefinidos desse tipo personalizado.

Ou ainda mais fácil é usar o módulo puppetlabs-concat , definir concat :: fragmentos virtuais em módulos e coletá-los no módulo rsyslog para construir o arquivo de configuração '60 -custconfig.conf '. Se, então, os recursos virtuais forem excluídos dos outros módulos, os fragmentos reunidos resultarão em um arquivo sem os fragmentos agora não gerenciados. Efetivamente, estes serão excluídos do arquivo.

    

Answer 2

Você precisa escrever explicitamente o código que "desfará" as ações específicas que deseja reverter.

Por exemplo, se você tem um módulo my_apache que instala alguns pacotes, configura vários arquivos e garante um certo estado, você terá que escrever outra classe dentro deste módulo, vamos chamá-lo my_apache::uninstall , que desfaz cada das coisas que o seu outro módulo fez. A classe de undo não precisa estar dentro ou parte do módulo original. Pode ser uma classe completamente separada. Uma boa maneira de alterar as classes que são aplicadas a um host é usar um ENC .

    

Answer 3

Não há uma resposta simples para reverter ou remover alterações de configuração no Puppet, mas um método simples é usar um diretório de configuração que o Puppet gerencie.

class rsyslog::config {

  file { '/etc/rsyslog.d':
    ensure  => directory,
    force   => true,
    purge   => true,
    recurse => true,
  }

  file { '/etc/rsyslog.conf':
    ensure  => present,
    content => template('rsyslog/rsyslog.conf.erb'),
  }

  file { '/etc/rsyslog.d/50-default.conf':
    ensure  => present,
    content => template('rsyslog/50-default.conf.erb'),
    require => File['/etc/rsyslog.d'],
  }

}

O que isto faz é dizer ao Puppet para possuir completamente qualquer coisa em /etc/rsyslog.d/ e deletar qualquer coisa que o Puppet não administre dentro dele. Se o servidor estava executando o haproxy anteriormente e você tem uma configuração para isso em seu syslog, quando você removeu o módulo happroxy, a referência para /etc/rsyslog.d/40-haproxy.conf desapareceria e o Puppet o removeria do diretório de configuração . Ele também gera um evento de notificação que você pode usar para que o Puppet reinicie o syslog, embora você precise de uma notificação ou ~ > cadeia para o serviço para o fazer.

    

Answer 4

Eu acho que seria possível usar um padrão com anti-modules. Por exemplo ...

zookeeper_present

Este módulo configuraria o host completamente para o zookeeper

 zookeeper_not_present

Este módulo reverteria qualquer coisa feita pelo módulo anterior.

lvs_present

Este módulo configuraria o host completamente para lvs.

lvs_not_present

Este módulo reverteria qualquer coisa feita pelo módulo anterior.

... e assim por diante

Tenha cuidado para não acabar com módulos concorrentes, onde um present_module tenta definir algo e um not_present_module tenta desfazer essa configuração. Isso pode acontecer quando você tem dois módulos que exigem a mesma coisa.

Uma maneira de resolver isso talvez seja quebrar essa configuração comum em seu próprio módulo e tornar os outros dois módulos dependentes daquele. No entanto, quando ninguém mais precisar desse módulo comum, você terá que trocá-lo manualmente para o not_present_version desse módulo no arquivo site.pp.

    

Answer 5

Para elaborar as respostas já publicadas: O Puppet gerencia recursos. Gerenciar significa conhecer o estado dos recursos e garantir que um recurso esteja no estado desejado. Você diz ao Puppet o que gerenciar e de que maneira administrá-lo. E uma vez que Puppet não mais conhece um recurso, ele não pode mais administrá-lo, obviamente. É assim que o Puppet funciona.

Imagine o estrago que causaria no sistema se o Puppet simplesmente excluísse recursos que não são mais conhecidos. Isso por si só já parece paradoxal; como você exclui qualquer coisa que você não conhece? Mas mesmo que houvesse uma maneira de fazer isso, provavelmente destruiria seu sistema.