Recurso definido pelo Puppet - parametrização seletiva?

Question

No momento, estou batendo cabeça tentando encontrar a "melhor maneira" de obter esse tipo de granularidade para o fantoche: Eu tenho um servidor executando o memcached no ambiente de teste e outro em execução no ambiente de produção.

Esses servidores são executados com diferentes opções do memcached e estou usando o monitor para reiniciá-los, se necessário, o monit é gerenciado por meio do fantoche e monitora o memcached por meio de um memcached.monitrc, bastante simples até o momento.

Meu problema é: Eu tenho um recurso definido chamado "monit :: monitor" que recebe um nome para obter um template para esse recurso, como

monit::monitor { 'memcached': }

Este é o código para monit :: monitor:

define monit::monitor($template_params = {}) {
    file { "/etc/monit/monit.d/${name}.monitrc":
            ensure => present,
            content => template("monit/${name}.monitrc.erb"),
    }
}

Isso irá procurar por "memached.monitrc.erb" no diretório modules / monit / templates e imprimi-lo, mas nesse arquivo eu preciso parametrizar o parâmetro de memória do memcached, se ele for executado em test env ele deve ser 64m, se em produção, 3072m.

templates / memcached.monitrc.erb parece com isso

 check process memcached with pidfile /var/run/memcached0.pid
  start program = "/usr/bin/memcached -d -p 11211 -U 11211 -u memcached -m <%= template_params['memory'] %> -t 4 -c 1024 -P /var/run/memcached/memcached0.pid"
  stop program = "/bin/kill -9 'cat /var/run/memcached0.pid'; rm /var/run/memcached0.pid"
  if failed host 127.0.0.1 port 11211 then restart
  group cache

O que eu estou usando agora é que monit :: monitor suporta um hash para templates param, mas isso ofusca o uso do template então você precisa olhar o template para ver quais parâmetros ele deve receber e eu acho que existe um melhor solução para isso ...

Obrigado pela atenção e desculpe se soou confuso: P

    

Answer 1

Minha solução para esse tipo de problema é pegar todos os números mágicos dos manifestos de marionetes e procurá-los quando eles forem necessários usando extlookup . Eu não precisei usá-lo em um modelo, mas deve funcionar .

Então, no seu caso, eu posso ter

extlookup / production.example.com.csv

memcache_memory,3072m

extlookup / testing.example.com.csv

memcache_memory,64m

Em seguida, sua linha de modelos mudaria para se tornar

start program = "/usr/bin/memcached -d -p 11211 -U 11211 -u memcached -m <%= extlookup('memcache_memory') %> -t 4 -c 1024 -P /var/run/memcached/memcached0.pid"

e o valor seria definido automaticamente para cada máquina.

Devo observar que alguns desenvolvedores de marionetes pensam que pesquisam dados em seus manifestos ou modelos são Uma Coisa Ruim e você deve ter todos os seus dados definidos em seus nós e explicitamente passá-los para onde eles precisam passar por classes e definições paramaterizadas. Depois de ler esse tópico da lista de discussão, ainda acho que o extlookup é a solução superior hoje, mas você pode querer lê-lo e decidir por si mesmo.

    

Answer 2

Tanto quanto sei, é uma fraqueza fundamental dos modelos que é preciso referir-se a eles para saber quais parâmetros eles exigem. Eu mesmo, garanto que a documentação do módulo deixa claro quais variáveis o template requer, e o template em si pode conter uma seção de comentários com as mesmas informações.

    

Answer 3

Bem, eu não teria um hash para os params, eu apenas faria os params diretamente, assim:

define monit::monitor($memory = "64m") {
  # ...
}

Você poderia até fazer:

define monit::monitor::testing($memory = "64m") {
  # ...
}

E crie várias definições diferentes para cada uma delas e use o mesmo arquivo de modelo para ela. Desta forma, a definição é rotulada pelo nome (monit :: monitor :: testing, monit :: monitor :: prod, etc), e os parâmetros estão na definição. Peça-lhes que chamem um primary define, talvez, com todos os valores especificados para seus padrões normais, ou algo assim.

Eu acho que provavelmente seria mais claro.