El problema que encontré es que puedo instalar los módulos de Puppet con éxito. Por ejemplo:
[puppet@swarmcritic ~]$ puppet module install puppetlabs/mysql Notice: Preparing to install into /home/puppet/.puppet/modules ... Notice: Created target directory /home/puppet/.puppet/modules Notice: Downloading from https://forge.puppetlabs.com ... Notice: Installing -- do not interrupt ... /home/puppet/.puppet/modules └─┬ puppetlabs-mysql (v2.1.0) └── puppetlabs-stdlib (v4.1.0)
Pero cuando trato de invocar un módulo usando un archivo nodes.pp como este:
node 'example.com' { include '::mysql::server' }
Entonces me sale un error como este:
[puppet@example mysql]$ sudo puppet apply ~puppet/puppet/manifests/site.pp Error: Could not find class ::mysql::server for example.com on node example.com Error: Could not find class ::mysql::server for example.com on node example.com
¿Cómo puedo arreglarlo?
Puppet estaba instalando el módulo en el árbol de directorios .puppet de mi directorio de inicio, ¡pero no estaba buscando allí cuando llegó el momento de buscar el módulo! En cambio, SOLO buscaba en /etc/puppet/modules. Parece que, por defecto, solo mira allí. Si quiere que busque en ~myusername/.puppet, debe configurar una variable de ruta en /etc/puppet/puppet.conf o algo así.
Para resolver el problema, no intenté descubrir cómo modificar la ruta de Puppet. En cambio, instalé el módulo explícitamente en /etc/puppet/modules usando el siguiente comando:
sudo puppet module install -i /etc/puppet/modules puppetlabs/mysql
Una vez hecho esto, el comando de aplicación de marionetas funcionó bien.
La experimentación adicional reveló que si ejecuta el comando de instalación del módulo Puppet sin el argumento -i y acceso raíz, instalará el módulo en /etc/puppet/modules, pero si no tiene acceso raíz, lo instalará en ~ minombredeusuario/.puppet/modules/. Entonces, si hubiera puesto un sudo delante del comando de instalación de mi módulo original como este:
sudo puppet module install puppetlabs/mysql
entonces no habría habido ningún problema. ¡No tiene que especificar el argumento -i!
Todo el problema surgió porque elegí crear una cuenta de usuario para guardar todo el material de marionetas en lugar de trabajar en la cuenta raíz. Si hubiera trabajado en la cuenta raíz, Puppet (presumiblemente) habría instalado el módulo en /etc/puppet/modules y no habría habido ningún problema. Es solo porque creé una cuenta de usuario y luego invoqué el comando de instalación del módulo de marionetas sin sudo que los módulos terminaron en ~minombredeusuario/.marioneta. Siendo un novato de marionetas, tener módulos instalados en ~myusername/.puppet no parecía una mala idea. Parecía un lugar sensato para instalar los módulos, particularmente si uno ha creado una cuenta de usuario para administrar Puppet.
Todo esto no debería desanimarlo a crear una cuenta de usuario para almacenar todos sus archivos de configuración de marionetas. Pero si lo hace, recuerde poner sudo al frente del comando de instalación cuando instale módulos.
Publicado en nombre del OP.
Vale la pena señalar que la ruta del módulo se puede encontrar de la siguiente manera:
# puppet config print modulepath /etc/puppetlabs/puppet/modules:/opt/puppet/share/puppet/modules
Puede encontrar más información aquí...
depende de la versión de marioneta que esté utilizando:
en versiones anteriores (3.6 o anteriores), puede agregar la variable modulepath
a su configuración de títeres (en /etc/puppet/puppet.conf) después de aplicar la puppet module list
de ejecución de cambios en el maestro para confirmar que títeres reconoce el cambio.
en las versiones más nuevas, se supone que debe crear un entorno de títeres (en /etc/puppet hasta títeres 4.0 o /etc/puppetlabs/code para títeres 4.0 y superiores) e incluir la ruta del módulo en el archivo environment.conf. puede usar el mismo comando ( puppet module list
) para asegurarse de que los módulos estén instalados correctamente.