Puppet a exporté des ressources pour les variables du fichier .erb?

Scénario: mon fichier de configuration est défini par un .erbfichier qui inclut l'extrait ci-dessous.

<% 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 -%>

Le fichier de configuration du serveur nécessite une entrée répétée pour chaque hôte client. Si je devais créer un tableau simple, cela fonctionnerait sans problème. Ce que je veux faire, cependant, c'est que chaque hôte s'enregistre lui-même, puis recueille les données en utilisant le <<| |>>pragma similaire à ce que l'on ferait avec les nagios_*types.

L' exemple standard pour cela implique l'exportation d'un type.

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

Cependant, je ne peux pas vraiment comprendre comment écrire un type ou le référencer d'une manière qui me permettrait de lire ce tableau de valeurs à partir du .erbmodèle. Existe-t-il un moyen d'utiliser les ressources exportées en combinaison avec une boucle variable dans un .erbfichier?

Donc, pour répondre directement à votre question, je ne pense pas qu'il soit possible d'obtenir une liste des ressources exportées directement depuis erb. Cela est dû à la nature des ressources exportées. Pour Puppet, ce sont juste plus de ressources qui doivent être créées sur l'hôte.

Mais, il existe un moyen d'accomplir ce que vous cherchez à faire. Je le fais à quelques endroits de mon environnement.

Ici, nous créons un répertoire de fichiers, un pour chaque hôte que nous voulons marquer comme "bacula_client". Nous utilisons les purge, forceet les recurseoptions pour supprimer les fichiers qui ne sont pas gérés par des marionnettes (si vous voulez supprimer un système de cette « liste »).

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" |>>

}

Ensuite, nous utilisons du code Ruby dans le .erb pour rechercher des fichiers dans ce répertoire et agir sur eux:

<% 
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 -%>

Eh bien, j'ai d'abord abandonné et défini mon @@type de fichier réel. L'avantage est que cela utilise toujours les variables sur l'hôte client.

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]
    }

    ...
}

Cela me permet d'utiliser des entrées dans le fichier erb telles que:

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

et déclarations dans mes fichiers site.pp tels que: class { bacula-client: database => "true" }

Pour gérer le répertoire lui-même:

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

        ...
}

Purger et recurse nettoie tout ce qui n'est pas défini. Lorsque je mets un hôte hors ligne, puppetstoredconfigclean $hostnamenettoie les faits et la prochaine série de marionnettes sur le directeur réinitialise la configuration de manière appropriée.

Enfin, le logiciel directeur Bacula lui-même me permet de faire ce qui suit à la fin de mon fichier bacula-dir.conf:

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

Donc, il ne semble toujours pas y avoir de moyen direct d'utiliser un modèle ERB sur un ensemble de ressources collectées, mais on peut collecter des types. Cela peut inclure des types Augeas pour tout mettre dans un seul fichier, ou un hack de collecte de fichiers dans une configuration. Cependant, cela ne comprend pas encore ce que je cherchais sur la question.

J'ai trouvé une méthode utilisant le service PuppetDB qui fonctionne assez bien dans cette situation, bien qu'elle soit un peu hackeuse. Pour l'utiliser, vous devrez avoir PuppetDB opérationnel (que vous devriez déjà avoir car vous utilisez des ressources exportées) et l'API PuppetDB devra être consultable auprès du puppetmaster (localhost).

Ensuite, vous voudrez exporter toutes les ressources que vous souhaitez rassembler dans votre tableau dans un répertoire dédié sur le système de fichiers. Ce chemin de répertoire sera utilisé pour identifier de manière unique les ressources cibles.

Ensuite, dans votre modèle, faites quelque chose comme ceci:

    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

Où nodename est le nom de domaine complet du serveur, pathRegex est le chemin de recherche mentionné ci-dessus, formaté en Ruby Regex et retVal est le tableau terminé. Cela permet de tirer parti du traitement du modèle sur le marionnettiste, de sorte que les informations d'identification API spéciales ne sont pas requises. Cela suppose également que la ressource namevar est le chemin d'accès complet des fichiers cibles, si vous avez des namevars complexes et utilisez l'attribut path une logique plus complexe sera requise. Notez également que cela renvoie toutes les ressources, à la fois exportées et locales. Les données renvoyées ont de nombreux attributs qui peuvent être utilisés pour une logique plus complexe si nécessaire.

Un peu hacky, mais ça marche bien.