Marioneta - Módulo

En Puppet, un módulo se puede definir como una colección de recursos, clases, archivos, definiciones y plantillas. Puppet admite una fácil redistribución de módulos, lo que es muy útil en la modularidad del código, ya que se puede escribir un módulo genérico específico y se puede usar varias veces con muy pocos cambios de código simples. Por ejemplo, esto habilitará la configuración predeterminada del sitio en / etc / puppet, con módulos enviados por Puppet propiamente dichos en / etc / share / puppet.

Configuración del módulo

En cualquier módulo de Puppet, tenemos dos particiones que ayudan a definir la estructura del código y controlar los denominados.

  • La ruta de búsqueda de módulos se configura utilizando una lista de directorios separados por dos puntos en el puppetmasterd o masterd, la sección posterior del archivo de configuración maestro de Puppet con el modulepath parámetro.

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

    La ruta de búsqueda se puede agregar en el tiempo de ejecución configurando la variable de entorno PUPPETLAB, que también debe ser una lista de variables separadas por dos puntos.

  • Configuración de control de acceso para los módulos del servidor de archivos en fileserver.conf, la configuración de la ruta para ese módulo siempre se ignora, y especificar una ruta producirá una advertencia.

Fuente de módulos

Puppet admite una ubicación diferente para almacenar módulos. Cualquier módulo se puede almacenar en un sistema de archivos diferente de cualquier máquina en particular. Sin embargo, todas las rutas donde se almacenan los módulos deben especificarse en la variable de configuración conocida comomodulepath que es, en general, una variable de ruta donde Puppet busca todos los directorios del módulo y los carga cuando se está iniciando.

Una ruta predeterminada razonable se puede configurar como:

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

Alternativamente, el directorio / etc / puppet podría establecerse como un módulo anónimo especial, que siempre se busca primero.

Nombramiento del módulo

Puppet sigue los mismos estándares de nomenclatura de un módulo en particular donde el nombre del módulo debe ser palabras normales, coincidiendo con [- \\ w +] (letra, palabra, número, guiones bajos y guiones) y sin contener el separador de espacio de nombres:: o /. Si bien puede estar permitido con respecto a las jerarquías de módulos, para los módulos nuevos no se puede anidar.

Módulo Organización Interna

Cuando el usuario crea un nuevo módulo en Puppet, sigue la misma estructura y contiene manifiesto, archivo distribuido, complementos y plantillas organizadas en una estructura de directorio específica como se muestra en el siguiente código.

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

Siempre que se crea un módulo, contiene init.pparchivo de manifiesto en la ubicación de reparación especificada dentro del directorio de manifiestos. Este archivo de manifiesto es un archivo predeterminado que se ejecuta primero en cualquier módulo en particular y contiene una colección de todas las clases asociadas con ese módulo en particular. Adicional.ppEl archivo se puede agregar directamente en la carpeta de manifiestos. Si estamos agregando archivos .pp adicionales, deben tener el nombre de la clase.

Una de las características clave que se logra mediante el uso de módulos es el uso compartido de código. Por naturaleza, un módulo debe ser autónomo, lo que significa que uno debe poder incluir cualquier módulo desde cualquier lugar y colocarlo en la ruta del módulo, que se carga cuando Puppet se inicia. Con la ayuda de módulos, se obtiene modularidad en la codificación de la infraestructura Puppet.

Ejemplo

Considere un módulo autofs que instala un mapa auto.homes fijo y genera el auto.master a partir de plantillas.

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

El sistema de archivos tendrá los siguientes archivos.

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

Búsqueda de módulo

Puppet sigue una estructura predefinida en la que contiene múltiples directorios y subdirectorios en una estructura definida. Estos directorios contienen diferentes tipos de archivos que son requeridos por un módulo para realizar ciertas acciones. Un poco de magia entre bastidores asegura que el archivo correcto se asocie con el contexto correcto. Todas las búsquedas de módulos están dentro de la ruta del módulo, una lista de directorios separados por dos puntos.

Para las referencias de archivos en el servidor de archivos, se usa una referencia similar para que una referencia a puppet: //$servername/modules/autofs/auto.homes se resuelva en el archivo autofs / files / auto.homes en la ruta del módulo.

Para hacer que un módulo sea utilizable tanto con el cliente de línea de comandos como con un puppet master, se puede usar una URL de la ruta from puppet: ///. es decir, una URL sin un nombre de servidor explícito. Dicha URL es tratada de forma ligeramente diferente porPuppet y puppetd. Puppet busca URL sin servidor en el sistema de archivos local.

Los archivos de plantilla se buscan de manera similar al manifiesto y los archivos: una mención de la plantilla ("autofs / auto.master.erb") hará que el titiritero busque primero un archivo $templatedir/autofs/auto.master.erb y entonces autofs/templates/auto.master.erben la ruta del módulo. Con las versiones Puppet de todo lo que hay debajo de Puppet, está disponible para su uso. Esto se denomina carga automática del módulo. Puppet intentará cargar automáticamente las clases y definiciones del módulo.