Puppet se utiliza para automatizar varias tareas rutinarias de configuración de administradores de sistemas.
Puppet en un sistema de gestión de configuración de nivel empresarial.
Le permite definir el estado de su infraestructura de TI. Una vez que se define, Puppet aplicará automáticamente el estado correcto de manera continua.
1. Arquitectura de marionetas
Típicamente, Puppet tiene un componente de servidor y varios agentes. Debe designar un servidor en su red como titiritero, y cada nodo en su red tendrá instalado el agente de títeres.
La forma más común de aplicar la configuración de marionetas a un cliente es utilizar el demonio del maestro de marionetas (puppetmasterd) y el demonio del cliente de marionetas (puppetd). También puede aplicar manualmente los manifiestos usando la herramienta de títeres.
La configuración se define en el maestro de marionetas, se compila y luego se envía automáticamente a los clientes de marionetas cuando se conectan.
Puppet es compatible con una amplia gama de plataformas y sistemas operativos diferentes, y ejecutará automáticamente los comandos apropiados para aplicar su manifiesto en cada entorno.
Un manifiesto no es más que detalles sobre archivos, paquetes, operaciones de configuración escritas en un lenguaje que la marioneta puede entender.
Cada nodo de Puppet se pone en contacto con el titiritero, de forma predeterminada cada 30 minutos, para confirmar que su configuración está actualizada. Si la configuración es diferente o hay alguna configuración nueva disponible, se vuelve a compilar y luego se aplica al nodo de la marioneta.
En este tutorial, explicaremos cómo crear algunos manifiestos básicos y aplicarlos a los clientes usando la herramienta de títeres.
La mayor parte de la configuración del sistema se puede ver mediante la herramienta de línea de comandos de marionetas. Todos los componentes de configuración están organizados en recursos. Los recursos se agrupan en colecciones. Los recursos se componen de tipo, título y serie de atributos.
2. Ejemplo de archivo de recursos de marionetas
El siguiente es un ejemplo básico sobre cómo ver un recurso de marionetas. En este caso, el recurso de marionetas que estamos viendo es un archivo (/etc/nsswitch).
# puppet resource file /etc/nsswitch.conf
file { '/etc/nsswitch.conf':
ensure => 'file',
content => '{md5}0d6009cdfd12646d251e86303bc0c48c',
ctime => 'Sun May 18 13:20:02 -0400 2014',
group => '0',
mode => '644',
mtime => 'Tue May 04 15:22:21 -0400 2010',
owner => '0',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
type => 'file',
}
Puppet viene con una serie de tipos de recursos de forma predeterminada, incluidos tipos para administrar archivos, servicios, paquetes, trabajos cron y sistemas de archivos, entre otros.
En el ejemplo anterior, archivo es el tipo de recurso y /etc/nsswitch.conf es el título del recurso que se administrará.
Todo lo demás son atributos del tipo de recurso y valores presentes en los atributos. También puede ampliar la marioneta para agregar sus propios tipos de recursos.
Para ver todos los tipos de recursos disponibles, use el siguiente comando:
# puppet resource --types augeas computer cron exec file filebucket group host nagios_hostdepend .. ..
3. Ejemplo de archivo de manifiesto de marionetas
Echemos un vistazo a cómo crear un archivo de manifiesto simple y ejecutar el comando de títeres para aplicar la configuración al servidor.
El siguiente ejemplo crea un archivo de manifiesto simple site.pp en el directorio /etc/puppet/manifests que creará un archivo de prueba en /var/tmp.
Inicialmente, como vemos a continuación, no tenemos el archivo de prueba.
# ls -ld /var/tmp/testfile ls: cannot access /var/tmp/testfile: No such file or directory
La siguiente es la declaración de recursos dentro del archivo de manifiesto (site.pp):
# cat site.pp
file { "/var/tmp/testfile":
ensure => "present",
owner => "root",
group => "root",
mode => "664",
content => "This is a test file created using puppet.
Puppet is really cool",
}
Para fines de demostración, estamos ejecutando el maestro de marionetas y el agente en el mismo nodo.
Cuando ejecute el comando de aplicación de marionetas por primera vez con la opción -noop, se realizará una ejecución en seco sin aplicar realmente la configuración.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.06 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: current_value absent, should be present (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.03 seconds
Lo anterior para ver qué hará la nueva configuración sin realizar cambios en el nodo.
Ahora, ejecute el comando sin la opción –noop para aplicar realmente la configuración como se muestra a continuación.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/File[/var/tmp/testfile]/ensure: created Notice: Finished catalog run in 0.05 seconds
Una vez que se ejecute con éxito, verá que se crea el nuevo archivo temporal en /var/tmp/testfile con los contenidos definidos en site.pp.
# ls -ld /var/tmp/testfile -rw-rw-r--. 1 root root 69 Jun 26 14:25 /var/tmp/testfile # cat /var/tmp/testfile This is a test file created using puppet. Puppet is really cool
4. Controle un servicio en un nodo remoto usando Puppet
Este es un ejemplo para cambiar el servicio del estado detenido al estado en ejecución en los nodos del agente.
Cuando este manifiesto de configuración se guarda en el servidor maestro en una ubicación específica en el directorio de configuración de marionetas, el agente que se ejecuta en todos los nodos se pone en contacto con el nodo maestro, obtiene la configuración y la aplica en todos los nodos del cliente para que de esta manera se inicie el servicio. en todos los nodos del agente después de que la configuración de la marioneta se haya ejecutado correctamente.
# puppet resource service multipathd
service { 'multipathd':
ensure => 'stopped',
enable => 'false',
}
En este ejemplo, controlaremos el servicio multipathd. Puede usar títeres para controlar cualquier servicio que se esté ejecutando en el sistema. Por ejemplo, httpd, mysqld, etc.
# puppet resource service multipathd > site.pp
Asegúrese de que site.pp tenga los siguientes valores. Si no es así, edítelo en consecuencia.
# vi site.pp
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
Primero haga una prueba para asegurarse de que funciona como se esperaba.
# puppet apply site.pp --noop Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds Notice: /Stage[main]/Main/Service[multipathd]/ensure: current_value stopped, should be running (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Finished catalog run in 0.06 seconds
Finalmente, aplique el archivo de configuración, que iniciará el servicio (en este ejemplo, multipathd), si aún no se está ejecutando.
# puppet apply site.pp
Notice: Compiled catalog for pemaster.mydomain.com in environment production in 0.07 seconds
Notice: /Stage[main]/Main/Service[multipathd]/ensure: ensure changed 'stopped' to 'running'
Notice: Finished catalog run in 0.28 seconds
# puppet resource service multipathd
service { 'multipathd':
ensure => 'running',
enable => 'true',
}
# chkconfig --list | grep multipath
multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
5. Instalar un paquete en un nodo remoto usando Puppet
Puede realizar la instalación del paquete en todos los nodos del agente de forma remota mediante una marioneta.
El siguiente es un archivo de manifiesto de muestra para la instalación del paquete.
# cat site.pp
package { 'httpd':
ensure => 'present',
}
En este ejemplo, instalará el paquete Apache httpd si no está presente en el sitio remoto. Como puede ver a continuación, instaló el paquete.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.70 seconds Notice: /Stage[main]/Main/Package[httpd]/ensure: created Notice: Finished catalog run in 79.97 seconds
Verifique que el paquete esté instalado correctamente usando el comando rpm.
# rpm -qa | grep -i httpd httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
6. Dos tipos de colecciones de títeres
Los recursos pueden configurar las características de los elementos de configuración únicos en los nodos. Sin embargo, la mayoría de los servicios y aplicaciones se componen de múltiples recursos.
Por ejemplo, un servidor web consta del paquete de software, los usuarios para ejecutar el software y una variedad de archivos de configuración, registro y otros.
Las colecciones de recursos le permiten recopilar los recursos, asignarlos a la colección y aplicar la colección a los nodos de agente.
Hay 2 tipos de recopilación de recursos:
- Clases
- Definiciones
7. Ejemplo de colección de clases de marionetas
Una clase es una colección de recursos que representa un solo elemento de configuración en su nodo, mientras que la definición es una colección de elementos de configuración que tienen múltiples representaciones en su nodo.
En el ejemplo anterior, después de la instalación del paquete, los servicios no se inician de forma predeterminada. Podemos crear un manifiesto simple con clase para instalar el paquete e iniciar el servicio después de la instalación.
En el siguiente ejemplo, especificamos la relación entre dos recursos usando el atributo require.
# cat site.pp
class apache {
package { 'httpd':
ensure => 'present',
}
service {'httpd':
ensure => 'running',
require => Package["httpd"],
}
}
include apache
Esto garantiza que se cumpla la condición antes de que se apliquen los cambios de recursos. En este caso, el servicio httpd requiere que se instale primero el paquete httpd antes de que pueda intentar activar los servicios.
# puppet apply site.pp Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.93 seconds Notice: /Stage[main]/Apache/Package[httpd]/ensure: created Notice: /Stage[main]/Apache/Service[httpd]/ensure: ensure changed 'stopped' to 'running' Notice: Finished catalog run in 32.82 seconds # chkconfig --list | grep http httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off # rpm -qa | grep -i http httpd-2.2.15-39.el6.centos.x86_64 httpd-tools-2.2.15-39.el6.centos.x86_64
8. Ejemplo de colección de definiciones de marionetas
Una definición es un tipo de colección de recursos de marionetas.
Las definiciones deben usarse para los elementos de configuración que tienen varias instancias en un nodo.
Por ejemplo, el servidor httpd puede tener varios hosts virtuales definidos. Puede crear una definición para configurar hosts virtuales y pasar los argumentos apropiados para configurar cada uno. Siempre que cada conjunto de argumentos fuera diferente, la marioneta configuraría el nuevo host virtual cada vez que se evaluara la definición.
El siguiente es un ejemplo de un manifiesto simple con una clase y una definición.
# cat site1.pp
class testdefine {
define testdefine ($data) {
file {"$title":
ensure => file,
content => $data,
}
}
testdefine {'/var/tmp/puppetfile1':
data => "The name of the file is puppetfile1 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile2':
data => "The name of the file is puppetfile2 and it is created by puppet\n",
}
testdefine {'/var/tmp/puppetfile3':
data => "The name of the file is puppetfile3 and it is created by puppet\n",
}
}
include testdefine
Ejecute la clase de títeres anterior y el manifiesto de definición como se muestra a continuación.
# puppet apply site1.pp
Notice: Compiled catalog for pemaster.mydomain.net in environment production in 0.24 seconds
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile2]/File[/var/tmp/puppetfile2]/ensure: defined content as '{md5}9079bd9c7650ae7d503c7df1a68bb9f0'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile3]/File[/var/tmp/puppetfile3]/ensure: defined content as '{md5}75d495f0d3180b1f2dd052ac208d81fe'
Notice: /Stage[main]/Testdefine/Testdefine::Testdefine[/var/tmp/puppetfile1]/File[/var/tmp/puppetfile1]/ensure: defined content as '{md5}1fa93f1f2b82f8358866d58b2cb2f0b4'
Notice: Finished catalog run in 0.19 seconds
# ls -l /var/tmp/puppetfile*
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile1
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile2
-rw-r--r--. 1 root root 64 Jun 26 19:11 /var/tmp/puppetfile3
# cat /var/tmp/puppetfile*
The name of the file is puppetfile1 and it is created by puppet
The name of the file is puppetfile2 and it is created by puppet
The name of the file is puppetfile3 and it is created by puppet
9. Ejemplo de archivo de configuración de nodo Puppet
Hasta ahora hemos visto definir recursos y colecciones de recursos en forma de clases y definiciones.
Ahora el siguiente paso es cómo asignar estos recursos y colecciones a los clientes.
Aquí hay un ejemplo de cómo se definen los nodos en node.pp.
Puppet usa este archivo para determinar qué clase (que contiene recursos) debe ir a qué servidor, por ejemplo, en el cliente 1 desea ejecutar la clase httpd que contiene recursos como el paquete httpd, el servicio httpd y en el cliente 2 desea ejecutar la clase ngnix que contiene recursos como el paquete ngnix, el servicio ngnix y otros archivos de configuración de ngnix.
El siguiente archivo de muestra nodes.pp explica esto:
node 'puppetclient1.mydomain.net' {
include httpd_class
}
node 'puppetclient2.mydomain.net' {
include ngnix_class
}
node default {
package { "perl":
ensure => present }
}
Dentro de la definición de su nodo, puede agregar recursos, clases y definiciones.
Las clases se agregan usando la función include.
En puppetclient1.mydomain.net hemos incluido httpd_class y en puppetclient2.mydomain.net hemos incluido ngnix_class.
También puede incluir varias clases con una sola función de inclusión. Si no coincide ninguna definición de nodo, toma los valores predeterminados definidos. En este caso, si hay otros nodos, simplemente instalará paquetes perl si no está presente.
10. Importar archivos de manifiesto de marionetas
Los recursos, clases y definiciones se almacenan en archivos de manifiesto.
Un archivo de manifiesto especial, llamado manifiesto del sitio, es el núcleo de nuestra configuración.
Al iniciar el demonio maestro de Puppet, el archivo de manifiesto del sitio, ubicado de forma predeterminada en /etc/puppet/manifests/site.pp, debe estar presente.
En los ejemplos anteriores, usamos site.pp solo para explicar cómo aplicar los manifiestos.
En un entorno de marionetas real, su sitio.pp tendrá solo los siguientes contenidos y desde este archivo se importan los demás archivos para su ejecución.
# cat site.pp import "templates.pp" import "nodes.pp" import "classes/*" import "groups/*" import "users/*" import "os/*"
La siguiente es la estructura del directorio del manifiesto de la marioneta:
- /manifests/classes/ – Directorio que contiene todas las clases
- /manifests/site.pp:el archivo de manifiesto principal
- /manifests/templates.pp:contiene nodos de plantilla
- /manifests/nodes.pp:contiene definiciones de nodos
- /manifests/definitions/:contiene todas las definiciones
- /manifests/groups/:contiene manifiestos que configuran grupos
- /manifests/os/:contiene clases diseñadas para configurar nodos con sistemas operativos particulares
- /manifests/users/:contiene manifiestos que configuran usuarios
- /manifest/files/:contiene módulos de servidor de archivos para archivos distribuibles de Puppet