Diferencia entre revisiones de «Puppet»
(→Modulos) |
(→Modulos) |
||
Línea 256: | Línea 256: | ||
puppet module search solr | puppet module search solr | ||
puppet module install <modulo> | puppet module install <modulo> | ||
+ | </pre> | ||
+ | |||
+ | = Control de versiones = | ||
+ | Para tener un control de las versiones de los manifiestos que estamos creando y manipulando he creado un repositorio de SVN donde voy actualizando las modificaciones que voy haciendo. | ||
+ | |||
+ | |||
+ | |||
+ | = Entornos = | ||
+ | Dentro de puppet se pueden definir diferentes entornos, con configuraciones separadas para cada uno. Lo típico es tener el entorno [main] para producción, uno de desarrollo y otro de preproducción. | ||
+ | |||
+ | Para definir diferentes entornos hay que añadir al fichero de configuración /etc/puppet/puppet.conf nuevos tags, como los que tenemos de [main] o [agent], con los nombres de los entornos que queremos añadir. | ||
+ | |||
+ | En mi caso he creado los siguiente entornos: | ||
+ | |||
+ | <pre> | ||
+ | [development] | ||
+ | modulepath = $confdir/environments/development/modules | ||
+ | manifest = $confdir/environments/development/manifests/site.pp | ||
+ | |||
+ | [testing] | ||
+ | modulepath = $confdir/environments/testing/modules | ||
+ | manifest = $confdir/environments/testing/manifests/site.pp | ||
</pre> | </pre> |
Revisión de 12:18 20 ene 2013
Contenido
Referencias
- Inforamción sobre primeros pasos en puppet en español aqui
- Documentación oficial de instalación de puppet aqui
- Otro documento sobre Instalación y configuración en español aqui
Introducción
Para nuestro entorno de pruebas vamos a instalar la versión enterprise de Puppet, que permite administrar hasta 10 nodos de forma gratuita. Se trata de conocer el producto de pago y ver si interesa en un futuro comprar las licencias.
Pasos para la instalación de puppet
Después de instalar Centos 6.3 añadimos el repositorio de paquetes de puppet para el YUM, con el siguiente comando
rpm -ivh http://yum.puppetlabs.com/el/6/products/i386/puppetlabs-release-6-6.noarch.rpm
Y añadiremos los paquetes para puppet enterprise
rpm -ivh http://yum-enterprise.puppetlabs.com/el/6/extras/i386/puppetlabs-enterprise-release-extras-6-2.noarch.rpm
Eso hará que estén disponibles nuevos paquetes de puppet para nuestra instalación
Para la versión 5 de EL son los siguientes:
rpm -ivh http://yum.puppetlabs.com/el/5/products/i386/puppetlabs-release-5-6.noarch.rpm rpm -ivh http://yum-enterprise.puppetlabs.com/el/5/extras/i386/puppetlabs-enterprise-release-extras-5-2.noarch.rpm
Instalación de servidor de puppet
En el servidor que nos hará de server instalamos los siguientes paquetes:
yum install puppet-server
Y después configuramos el arranque automático del servicio
chkconfig puppetmaster on
Instalación de cliente de puppet
En otra máquina instalamos el cliente de puppet, añadiendo los mismos repositorios de instalación de yum que para el server y después instalamos el agente:
yum install puppet
Antes de arrancar el servicio tendremos que cambiar la configuración para que el agente sepa a que servidor de puppet se tiene que conectar: Para ello modificamos el fichero de configuración: /etc/sysconfig/puppet, descomentando la parte que nos interesa
# The puppetmaster server PUPPET_SERVER=puppet1.test.prisadigital.int # If you wish to specify the port to connect to do so here PUPPET_PORT=8140 # Where to log to. Specify syslog to send log messages to the system log. #PUPPET_LOG=/var/log/puppet/puppet.log # You may specify other parameters to the puppet client here #PUPPET_EXTRA_OPTS=--waitforcert=500
puede ser recomendable añadir al fichero de hosts la entrada correspondiente para resolver el servidor de puppet.
Después arrancamos el servicio y lo configuramos para que se arranque de forma automática:
service puppet start chkconfig puppet on
Certificados
La comunicación entre el master y los agentes va encriptada. Para que no sea complicada la gestión de los certificados entre los agentes y el master puppet en si tiene su propia entidad certificadora y su propia gestión mediante el comando puppet.
En la máquina master podemos ver en el directorio /var/lib/puppet/ssl/ los ficheros de la entidad certificadora.
Cada vez que un agente arranque y se conecte contra el servidor master, generará una clave pública y privada, y una petición de firmado. Tendrá que ser firmada por la CA del master. Esto requiere que cada vez que se añada un agente habrá que ejecutar a mano el comando que realizar ese firmado.
Toda la gestión se realiza con los comandos:
puppet ca puppet cert
Para ver todos los certificados firmados podemos usar
puppet cert list --all
Si quitamos el --all veremos solamente las peticiones pendientes de ser firmadas, y si queremos firmar una podemos ejecutar
puppet cert sign "nombre_del_servidor"
Si queremos firmar todas las peticiones pendientes podemos usar el comando
puppet cert sign --all
Auto-firmado de peticiones
También se puede configurar que se firmen de forma automática ciertas peticiones que lleguen. Para ello se puede añadir el fichero /etc/puppet/autosign.conf, donde especificamos un FQDN de máquinas en las que confiamos. En mi caso:
prisadigital.int *.prisadigital.int
Comprobación de los agentes
Teniendo el master arrancado, podemos ejecutar un comando de comprobación del agente.
# puppet agent --test --verbose --server=<master_server> Info: Retrieving plugin Info: Caching catalog for <agent_server> Info: Applying configuration version '1358072141' Notice: Finished catalog run in 0.06 seconds
Arrancar servicios en modo consola
Durante las pruebas, para poder hacer seguimiento de que va haciendo cada servicio, podemos arrancarlos en modo conosola. Para ello, teniendo parado el servicio, podemos arrancar el master de la siguiente manera:
puppet master --no-daemonize --verbose
y el agente lo podemos arrancar con el comando
puppet agent --no-daemonize --verbose
Configuración de Puppet
El fichero principal de configuración es /etc/puppet/puppet.conf. Es el mismo fichero tanto para los agentes como para el master. Dentro de este fichero puede haber secciones [main] [master] y [agent]. Lo que va dentro de la sección main es común para agente y para master, y lo que va dentro de las otras dos secciones son especificas para el rol de esa máquina. Lo que se especifica en esas secciones de master y agente sobreescriben a lo que haya definido en Main en caso de que se duplique.
Primeras pruebas con puppet
Una buena referencia para empezar es el manual learningpuppet
Antes de empezar a crear manifiestos se puede hacer unas cuantas pruebas de como se reciben los datos de estado y como se realizan configuraciones con puppet. De esta forma se ve como usando con puppet la RAL (capa de abstracción de recursos) podemos recibir datos y modificar configuraciones de un servidor.
El ejemplo más sencillo es con los usuarios:
Si queremos ver una lista de usuarios que tiene cualquiera de los agentes podemos ejecutar el comando:
puppet resources user
Nos devolverá una lista de usuarios del sistema, en el formato de puppet:
user { 'pepe': ensure => 'present', comment => 'pepe', gid => '666', groups => ['DDesarrollo', 'nogroup', 'nogroup_old'], home => '/home/pepe', password => '*', password_max_age => '-1', password_min_age => '-1', shell => '/bin/sh', uid => '15094', } (...)
También podemos especificar un objeto en concreto, para ver su estado, de manera que solo nos devolverá los datos de este y no la lista completa
puppet resource user paco
Si añadimos atributos a este comando, además, modificará el objeto con los datos especificados. Por ejemplo, si no existiera el usuario paco, podríamos crearlo de la forma siguiente:
puppet resource user paco ensure="present" shell="/bin/bash" uid="11000"
Manifiestos
Los manifiestos son ficheros con instrucciones sobre recursos, un ejemplo de manifiesto sería un fichero que tuviera la configuración de un usuario o de la existencia de un fichero.
Podriamos definier el siguiente manifiesto /root/ejemplo.pp
file {'FicheroPrueba': ensure => present, path =>'/tmp/prueba', content => "prueba de contenido", mode => 0666, }
Y para aplicarlo localmente a una máquina podriamos ejecutarlo como:
puppet apply ejemplo.pp
de esa forma ejecutaría el comando, o conjunto de ellos, que hay en el manifiesto.
Otro ejemplo, sería el de instalar el paquete apache y levantar el servicio:
package{'httpd': ensure => present, } service{'httpd': ensure => running, enable => true, } Package['httpd'] -> Service['httpd']
La última línea es la que define el orden en el que se han de aplicar los cambios, es decir, que primero instalará el paquete y después arrancará el servicio. Este es el métido de encadenamiento.
Otra cosa que se puede hacer es definir los Metaparámetros before y required. Se añaden a cada recurso como si fuera un atributo, pero realmente no es una propiedad del recurso, solo sirve para definir el comportamiento de Puppet.
Subscribe y Notify
Otro metaparámetro interesante es el subscribe. Se asocia a ciertos recursos que pueden ser "refrescados". Sobre todo se usa con los servicios, para ser reiniciados después de si un fichero de configuración ha sido modificado.
file{'/etc/apache/httpd.conf': ensure => present, source => /opt/template/httpd.conf } service{'httpd': ensure => running, enable => true, subscribe => File['/etc/apache/httpd.conf'], }
Modulos
Son grupos de recursos que puden ser llamados desde otros manifiestos. Están organizados por directorios, generalmente en el directorio /etc/puppet/modules/. Cada módulo tendrá un directorio propio, y dentro de estos directorios se mantiene una estructrua definida como la siguiente:
/etc/puppet/modules/ssh/ /etc/puppet/modules/ssh/manifests /etc/puppet/modules/ssh/files /etc/puppet/modules/ssh/templates
Siempre existe un fichero init.pp dentro del directorio <modulo>/manifests que será el principal del modulo, y que por lo general empieza con una clase con el nombre del módulo:
class ssh { ... }
Módulos de puppet forge
En la comunidad de Puppet existen ya compartidos muchos módulos para casi todo. Una forma de buscarlos es en la web de puppet forge. También se pueden buscar a través del comando puppet, desde la línea de comandos, con:
puppet module search solr puppet module install <modulo>
Control de versiones
Para tener un control de las versiones de los manifiestos que estamos creando y manipulando he creado un repositorio de SVN donde voy actualizando las modificaciones que voy haciendo.
Entornos
Dentro de puppet se pueden definir diferentes entornos, con configuraciones separadas para cada uno. Lo típico es tener el entorno [main] para producción, uno de desarrollo y otro de preproducción.
Para definir diferentes entornos hay que añadir al fichero de configuración /etc/puppet/puppet.conf nuevos tags, como los que tenemos de [main] o [agent], con los nombres de los entornos que queremos añadir.
En mi caso he creado los siguiente entornos:
[development] modulepath = $confdir/environments/development/modules manifest = $confdir/environments/development/manifests/site.pp [testing] modulepath = $confdir/environments/testing/modules manifest = $confdir/environments/testing/manifests/site.pp