Início / server / Perguntas / 685265
Accepted
Flup
Asked: 2015-04-25 02:09:31 +0800 CST

Verificando a configuração exim gerada pelo fantoche antes de implantar

  • 772

Eu uso o Puppet para gerar /etc/exim4.confe quero ter certeza de que a configuração é válida antes de instalar o arquivo em sistemas de produção.

Eu considerei—

  • usando um gancho git para chamarexim4 -bV -C filename ... mas isso não vai funcionar porque eu uso um modelo ERB para gerar o arquivo, então o resultado final não é realmente gerado até que o agente Puppet seja executado. Eu já tenho um git hook para testar a sintaxe do ERB.

  • deixando o script init verificar o arquivo de configuração ... mas isso não é bom o suficiente porque, embora o script se recuse a recarregar o Exim se a configuração for inválida, o arquivo já terá sido instalado e as chamadas diretas para o Exim (para enviar e-mail de aplicativos, por exemplo) falhará.

Idealmente, o que eu quero é algum tipo de diretiva Puppet que se pareça com

file { '/etc/exim4/exim4.conf':
    content => template("exim/etc/exim4/exim4.conf.erb"),
    notify => Service[exim4],
    but_before_we_install_check_syntax_with => '/usr/bin/exim4 -bV -C',
}

Como posso verificar a sintaxe do arquivo de configuração depois de gerado pelo Puppet, mas antes de ser instalado?

Estou usando Exim 4.80 e Puppet 2.7.26 em sistemas Debian Wheezy.

puppet

3 respostas

  1. Best Answer

    Parece que você está descrevendo o validate_cmdparâmetro exatamente. Da referência do tipo Puppet parafile :

    Um comando para validar a sintaxe do arquivo antes de substituí-lo. Se o Puppet precisar reescrever um arquivo devido a uma nova fonte ou conteúdo, ele verificará primeiro a validade do novo conteúdo. Se a validação falhar, o recurso de arquivo falhará.

    Esse comando deve ter um caminho totalmente qualificado e deve conter um token de porcentagem (%) onde esperaria um arquivo de entrada. Deve sair 0 se a sintaxe estiver correta e diferente de zero caso contrário. O comando será executado no sistema de destino ao aplicar o catálogo, não no mestre de marionetes.

    No seu exemplo, acho que você faria isso:

    file { '/etc/exim4/exim4.conf':
    content      => template("exim/etc/exim4/exim4.conf.erb"),
    notify       => Service[exim4],
    validate_cmd => '/usr/bin/exim4 -bV -C %',
}
    • 4

  2. Você pode testar a configuração resultante usando um gancho git para iniciar uma máquina virtual/contêiner (o Docker seria ideal para isso) e aplicar o manifesto nesse ambiente.

    Se você estiver fazendo isso regularmente, considere a implementação de um sistema de CI (como Jenkins ) para o qual você envia suas alterações, faça com que o CI execute um conjunto de testes e, com sucesso, envie as alterações para a produção.

    • 2

  3. Eu provavelmente criaria apenas três tarefas que dependem uma da outra: -

    • Gerar .conf modelo em /tmp
    • Teste gerado .conf
    • Mova .conf e notifique o serviço

    Existe uma razão para que isso não funcione neste caso?

    • 0

relate perguntas