Puppet exportou recursos para variáveis de arquivo .erb?

Question

Cenário: meu arquivo de configuração é definido por um arquivo .erb que inclui o snippet abaixo.

<% backupclients.each do |backup_files| -%>
Job {
  Name = "Server"
  JobDefs = "DefaultJob"
  Client = <%= backup_files %>-fd
  Pool = TeraMonth
  Write Bootstrap = "/var/lib/bacula/<%= backup_files %>.bsr"
}
<% end -%>

O arquivo de configuração do servidor precisa de uma entrada repetida para cada host do cliente. Se eu fosse criar um array simples, isso funcionaria sem problemas. O que eu quero fazer, no entanto, é que cada host se registre e, em seguida, colete os dados usando o <<| |>> pragma semelhante ao que se faria com os tipos nagios_* .

O exemplo padrão para isso envolve a exportação de um tipo.

class ssh {
  @@sshkey { $hostname: type => dsa, key => $sshdsakey }
  Sshkey <<| |>>
}

No entanto, não consigo descobrir como escrever um tipo ou referenciá-lo de uma forma que me permita ler essa matriz de valores do modelo .erb . Existe uma maneira de usar recursos exportados em combinação com um loop variável em um arquivo .erb ?

    

Answer 1

Bem, primeiro desisti e defini meu @@ no tipo de arquivo real. A vantagem é que isso ainda está usando as variáveis no host do cliente.

class bacula-client ($database = false) {
    @@file { "${hostname}-bacula-client.conf":
            mode => 600,
            owner => bacula,
            group => root,
            path => "/etc/bacula/conf.d/${hostname}-client.conf",
            content => template("bacula-dir-cliententry.erb"),
            tag => 'bacula-client',
            notify => Service[bacula-director]
    }

    ...
}

Isso me permite usar entradas no arquivo erb, como:

<% if has_variable?("database") and database== "true" %>
    ...
<% end -%>

e declarações em meus arquivos site.pp como: class { bacula-client: database => "true" }

Para lidar com o diretório em si:

class bacula-director {
        file { '/etc/bacula/conf.d':
            ensure => directory,
            owner => bacula,
            group => root,
            mode => 600,
            purge => true,
            recurse => true
        }

        ...
}

Limpar e reciclar limpa qualquer coisa não definida. Quando eu coloco um host offline, puppetstoredconfigclean $hostname limpará os fatos e a próxima execução do boneco no diretor redefinirá a configuração de forma apropriada.

Finalmente, o próprio software do diretor Bacula me permite fazer o seguinte no final do meu arquivo bacula-dir.conf:

@|"sh -c 'for f in /etc/bacula/conf.d/*.conf ; do echo @${f} ; done'"

Portanto, ainda não parece haver uma maneira direta de usar um modelo ERB em um conjunto de recursos coletados, mas é possível coletar um tipo. Isso pode incluir os tipos de Augeas para colocar tudo em um arquivo, ou um hack de coletar arquivos em uma configuração. Ainda não inclui o que eu estava procurando na pergunta.

    

Answer 2

Portanto, para responder à sua pergunta diretamente, não acredito que seja possível obter uma lista de recursos exportados diretamente do erb. Isso se deve à natureza dos recursos exportados. Para o Puppet, eles são apenas mais recursos que precisam ser criados no host.

Mas há uma maneira de realizar o que você deseja fazer. Eu faço isso em alguns lugares no meu ambiente.

Aqui criamos um diretório de arquivos, um para cada host que queremos marcar como um "bacula_client". Usamos as opções purge , force e recurse para remover arquivos que não são gerenciados pelo Puppet (por exemplo, se você quiser remover um sistema dessa "lista").

class bacula::client {

  @@file { "/etc/bacula_clients/$fqdn":
    ensure => present,
    content => "",
    require => File['/etc/bacula_clients'],
    tag => "bacula_client",
  }

}

class bacula::server {

  #
  # .. include whatever else the server requires, like package {} file {} service {}
  #

  file { "/etc/bacula_clients":
    ensure => directory,
    purge => true,
    recurse => true,
    force => true,
  }

  # Populate directory of client files.
  File <<| tag == "bacula_client" |>>

}

Em seguida, usamos um código Ruby no .erb para procurar arquivos nesse diretório e agir sobre eles:

<% 
bacula_clients_dir = '/etc/bacula_clients'
d = Dir.open(bacula_clients_dir)

# Remove directories from the list of entries in the directory (specifically '.' and '..'):
backupclients = d.entries.delete_if { |e| File.directory? "#{bacula_clients_dir}/#{e}" }

backupclients.each do |backup_files| 
-%>
Job {
  Name = "Server"
  JobDefs = "DefaultJob"
  Client = <%= backup_files %>-fd
  Pool = TeraMonth
  Write Bootstrap = "/var/lib/bacula/<%= backup_files %>.bsr"
}
<% end -%>

    

Answer 3

Eu encontrei um método usando o serviço PuppetDB que funciona razoavelmente bem para essa situação, embora seja um pouco trabalhoso. Para usá-lo, você precisará ter o PuppetDB operacional (o que você já deve ter quando estiver usando recursos exportados) e a API do PuppetDB precisará ser quierable do mestre de fantoches (localhost).

Em seguida, você desejará exportar todos os recursos que deseja reunir em sua matriz em um diretório dedicado no sistema de arquivos. Este caminho de diretório será usado para identificar exclusivamente os recursos de destino.

Em seguida, no seu modelo, faça algo assim:

    require 'rest_client'
    require 'json'
    resources=JSON.parse(RestClient.get("http://localhost:8080/v2/nodes/#{nodename}/resources", {:accept => :json}))

    retVal = Array.new
    resources.each do |resource|
       if resource["title"] =~ /^#{pathRegex}$/
           retVal.push(resource["title"])
       end
    end

Onde nodename é o FQDN do servidor, pathRegex é o caminho de pesquisa mencionado acima, formatado como Ruby Regex e retVal é a matriz concluída. Isso aproveita que o modelo é processado no mestre de fantoches, portanto, credenciais de API especiais não são necessárias. Isso também pressupõe que o recurso namevar seja o caminho completo dos arquivos de destino, se você tiver nomes de nomes complexos e usar o atributo path, será necessária uma lógica mais complexa. Observe também que isso está retornando todos os recursos, tanto exportados quanto locais. Os dados retornados possuem muitos atributos que podem ser usados para lógica mais complexa, se necessário.

Um pouco hacky, mas funciona bem.