Problemas que validam o manifesto Puppet com “parser de puppet validate”

Question

Estou usando puppet parser validate em um git pre-commit hook para localizar problemas antes de enviar arquivos para nosso repositório de configuração do Puppet. Infelizmente, esse comando parece ser uma verificação de sintaxe muito leve, que marca apenas erros como cotações e colchetes não balanceados.

O comando validate não parece realmente analisar a configuração e procurar itens como atributos inválidos, referências indefinidas e assim por diante. Por exemplo, o seguinte não resultará em uma reclamação:

file { 'somefile': requires => File['some-other-file'] }

Neste exemplo, requires deve ser require . Da mesma forma, isso também não gera erros:

file {'somefile': require => File['file-that-does-not-exist']}

Não há definição de recurso para file-that-does-not-exist .

Existe alguma maneira de pegar esses tipos de erros sem realmente aplicar a configuração? Eu estava esperando por algum tipo de sinalização no comando puppet apply que analisaria completamente uma configuração sem fazer alterações, mas, até onde eu posso dizer, essa opção não existe no Puppet 2.7.1.

UPDATE

puppet apply --noop parece tentar demais na outra direção. Ele tentará stat() de qualquer arquivo mencionado no manifesto, o que geralmente fará com que ele falhe com erros de permissão se tentar stat() de um arquivo que não é acessível ao usuário atual.

O que outras pessoas estão fazendo?

    

Answer 1

Em suma, este é um problema não trivial e não é facilmente resolvido analisando os manifestos. Compilar o catálogo pode expandir o escopo do teste, mas não é uma panacéia. puppet master --compile requer acesso aos fatos do nó, e idealmente um nó fictício que testa todas as classes. Você ainda tem que lidar com as limitações de:

• classes que não podem estar no mesmo catálogo (apache, apache :: disable)
• dependência entre classes.
• diferentes plataformas de sistema operacional.
• nós com parâmetros diferentes.

Por exemplo, se o nó um incluir aeb, tudo bem, mas o nó dois requer apenas b, é apenas uma falha que você verá no nó dois.

class a {
  notify { 'hi': }
}
class b {
  notify { 'bye':
    require => Notify['hi'],
  }
}

Se você tiver os recursos, poderá compilar o catálogo para todos os nós e fornecerá coberturas bastante abrangentes.

puppet apply --noop também tem suas limitações: ele falhará em um executável implementado por um pacote, ele falhará nos arquivos dependendo de um local de preparação e não testará várias plataformas a menos que você expanda o teste para uma amostra representativa de seus sistemas. Em geral, fornece uma cobertura suficiente para garantir que não haja problemas de compilação, dá uma ideia de quais sistemas são afetados, quais são as mudanças e você pode julgar pelos relatórios se as alterações são aceitáveis ou um problema real.

Na maioria dos casos, noop é suficiente, tenho visto vários graus de testes automatizados, como jenkins, onde cada módulo testa arquivos são simulados com --noop (limitações acima se aplica), ou usando o Vagrant para gerar MVs para executar o full teste de sopro.

    

Answer 2

Você pode querer considerar o bootstrap de um ambiente de teste, como o Puppet-Cucumber.

link

    

Answer 3

Para obter um pouco mais de validação de que os recursos e atributos são sensíveis, você pode compilar um catálogo de nó de amostra com puppet master --compile . Isso deve pegar o primeiro exemplo.

Não tenho certeza se as referências de recursos (o segundo exemplo) são verificadas no mestre ou no cliente, mas você sempre pode executá-las no modo no-op com puppet catalog apply ou puppet apply . Este último compilá-lo novamente e, em seguida, aplicá-lo, enquanto o primeiro deve ser capaz de tirar o catálogo compilado da validação anterior.