Marionnette - Module

Dans Puppet, un module peut être défini comme un ensemble de ressources, classes, fichiers, définitions et modèles. Puppet prend en charge la redistribution facile des modules, ce qui est très utile pour la modularité du code car on peut écrire un module générique spécifié et peut l'utiliser plusieurs fois avec très peu de changements de code simples. Par exemple, cela activera la configuration du site par défaut sous / etc / puppet, avec les modules fournis par Puppet proprement dit dans / etc / share / puppet.

Configuration du module

Dans tout module Puppet, nous avons deux partitions qui aident à définir la structure du code et à contrôler les dénominations.

Le chemin de recherche des modules est configuré à l'aide d'une liste de répertoires séparés par deux-points dans le puppetmasterd ou masterd, la dernière section du fichier de configuration principal de Puppet avec le modulepath paramètre.

[puppetmasterd] 
... 
modulepath = /var/lib/puppet/modules:/data/puppet/modules

Le chemin de recherche peut être ajouté au moment de l'exécution en définissant la variable d'environnement PUPPETLAB qui doit également être une liste de variables séparées par deux-points.

Paramètres de contrôle d'accès pour les modules de serveur de fichiers dans fileserver.conf, la configuration du chemin pour ce module est toujours ignorée et la spécification d'un chemin produira un avertissement.

Source des modules

Puppet prend en charge un emplacement différent pour stocker les modules. Tout module peut être stocké dans différents systèmes de fichiers d'une machine particulière. Cependant, tous les chemins où sont stockés les modules doivent être spécifiés dans la variable de configuration appeléemodulepath qui est en général une variable de chemin où Puppet recherche tous les répertoires du module et les charge lors du démarrage.

Un chemin par défaut raisonnable peut être configuré comme -

/etc/puppet/modules:/usr/share/puppet:/var/lib/modules.

Alternativement, le répertoire / etc / puppet pourrait être établi comme un module anonyme spécial, qui est toujours recherché en premier.

Nommage des modules

Puppet suit les mêmes normes de dénomination d'un module particulier dans lequel le nom du module doit être des mots normaux, correspondant à [- \\ w +] (lettre, mot, nombre, trait de soulignement et tirets) et ne contenant pas le séparateur d'espace de noms:: ou /. Bien que cela puisse être autorisé concernant les hiérarchies de modules, il ne peut pas être imbriqué pour les nouveaux modules.

Organisation interne du module

Lorsque l'utilisateur crée un nouveau module dans Puppet, il suit la même structure et contient un manifeste, un fichier distribué, des plugins et des modèles organisés dans une structure de répertoires spécifique, comme indiqué dans le code suivant.

MODULE_PATH/ 
   downcased_module_name/ 
      files/ 
      manifests/ 
         init.pp 
      lib/ 
         puppet/ 
            parser/ 
               functions 
            provider/ 
            type/ 
         facter/ 
      templates/ 
      README

Chaque fois qu'un module est créé, il contient init.ppmanifest à l'emplacement de correctif spécifié dans le répertoire manifestes. Ce fichier manifeste est un fichier par défaut qui s'exécute en premier dans un module particulier et contient une collection de toutes les classes associées à ce module particulier. Additionnel.ppLe fichier peut être ajouté directement sous le dossier manifestes. Si nous ajoutons des fichiers .pp supplémentaires, ils doivent être nommés d'après la classe.

L'une des principales caractéristiques obtenues grâce à l'utilisation de modules est le partage de code. Un module par nature devrait être autonome, ce qui signifie que l'on devrait être capable d'inclure n'importe quel module de n'importe où et de le déposer sur le chemin du module, qui est chargé au démarrage de Puppet. Avec l'aide de modules, on obtient la modularité dans le codage d'infrastructure Puppet.

Exemple

Considérez un module autofs qui installe une carte auto.homes fixe et génère le fichier auto.master à partir de modèles.

class autofs { 
   package { autofs: ensure => latest } 
   service { autofs: ensure => running } 
   
   file { "/etc/auto.homes": 
      source => "puppet://$servername/modules/autofs/auto.homes" 
   } 
   file { "/etc/auto.master": 
      content => template("autofs/auto.master.erb") 
   } 
}

Le système de fichiers contiendra les fichiers suivants.

MODULE_PATH/ 
autofs/ 
manifests/ 
init.pp 
files/ 
auto.homes 
templates/ 
auto.master.erb

Recherche de module

Puppet suit une structure prédéfinie dans laquelle il contient plusieurs répertoires et sous-répertoires dans une structure définie. Ces répertoires contiennent différents types de fichiers requis par un module pour effectuer certaines actions. Un peu de magie dans les coulisses s'assure que le bon fichier est associé au bon contexte. Toutes les recherches de modules se trouvent dans le modulepath, une liste de répertoires séparés par deux-points.

Pour les références de fichiers sur le serveur de fichiers, une référence similaire est utilisée afin qu'une référence à puppet: //$servername/modules/autofs/auto.homes soit résolue dans le fichier autofs / files / auto.homes dans le chemin du module.

Pour rendre un module utilisable à la fois avec le client en ligne de commande et un maître de marionnettes, on peut utiliser une URL du chemin from puppet: ///. c'est-à-dire une URL sans nom de serveur explicite. Cette URL est traitée légèrement différemment parPuppet et puppetd. Puppet recherche une URL sans serveur dans le système de fichiers local.

Les fichiers modèles sont recherchés de la même manière que les fichiers manifestes et les fichiers: une mention de modèle («autofs / auto.master.erb») obligera le maître de marionnettes à rechercher un fichier dans $templatedir/autofs/auto.master.erb et alors autofs/templates/auto.master.erbsur le chemin du module. Avec les versions Puppet de tout ce qui se trouve sous le Puppet, il est disponible. C'est ce qu'on appelle le chargement automatique du module. Puppet tentera de charger automatiquement les classes et les définitions à partir du module.