Implantación de Puppet Linux

Puede llegar un momanto en nuestro trabajo donde se con empiece a complicar el administrar nuestros servidores debido no ya a la complejidad del propio sistema sino al número de máquinas que debemos tener controladas.

Debido a la creciente tendencia de virtualizar todo lo que tengamos en plataforma Intel, el número de servidores RHEL a administrar está rozando ya las 80 máquinas. Cuando tenemos que tener configurados correctamente o hacer algún cambio en los DNS, SNMP, NTP, etc se hace inviable y tedioso entrar en cada una de ellas, hacer los cambios pertinentes y reiniciar el servicio. Para poder tener todo ésto controlado desde una consola central utilizamos Puppet Linux.

Lo tenemos disponible para RHEL, Debian y cualquier distribución. La aplicación consta de un servidor principal que se llama Puppetmaster (y no Master of Puppets, aunque no estaría mal) y un pequeño agente que instalamos en cada una de las máquinas a administrar. Para Debian está en los repositorios oficiales pero para RHEL hay que echar mano de los repos de EPEL, que aunque estén mantenidos por Fedora son perfectamente compatibles con RHEL.

Configuración del puppetmaster:

El servidor lo tengo en una máquina bastante potente que, entre otras cosas, ahora también hace de servidor Puppet. Ésta máquina corre Debian Squeeze. Evidenetemente también podemos instalar el puppetmaster en una máquina con RHEL, pero en el entorno donde estoy, me venía especialmente bien ya que ésta máquina tiene bastante tarjetas de red y la puedo configurar para que tenga conexión a las distintas subredes de todos los entornos que tenemos y no andar abriendo puertos en el firewall.

Instalación sencilla: apt-get install puppetmaster

Con Puppet podemos hacer muchas cosas. Yo de momento únicamente lo uso para mantener ficheros de configuración actualizados y monitorizar servicios. Pero también se puede instalar software, por ejemplo.

Toda la configuración de Pupput la entrontramos en /etc/puppet

El primer fichero que debems configurar es /etc/puppet/fileserver.conf

Aquí es donde pondremos la ruta local donde estarán los ficheros que queremos pasarle a los clientes y quién puede y quién no, acceder a ellos.

[files]
path /etc/puppet/files
allow *

En mi caso, podrá acceder todo el mundo previa firma del certificado. Más adelante veremos cómo se hace ésto.

El siguiente fichero es: /etc/puppet/puppet.conf

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates
certname=puppetmaster
autosign=false
reports=rrdgraph

Lo que está en negrita es lo que yo he añadido: certname -> nombre del servidor (debe coincidir con el hostname, sino seguramente dará problemas de certificado); autosign -> false, para que cualquier cliente deba ser validado desde el servidor para poder acceder a él. Prefiero dejarlo así para controlar mejor los clientes. Podríamos ponerlo a true para ahorrarnos éste paso; reports -> ésto es para que nos genere gráficas con rrd de la actividad de los clientes (no muy buenas por cierto, tengo que mirar de hacerlo de otra forma).

El funcionamiento de Puppet es a base de declaraciones de clases con una sintaxis propia del aplicativo. Todas éstas declaracione (o manifiestos) se encuentran en /etc/puppet/manifests

Yo utilizo una clase principal llamada /etc/puppet/manifests/site.pp dentro de la cual llamo a las diferentes clases que previamente he creado. Por ejemplo, he creado una clase por cada servicio que quiero monitorizar, una por cada fichero que quiero mantener, etc, pero se podrían agrupar (seguramente más adelante lo haré…)

site.pp:

import “classes/*.pp”

# Defaults para todos los nodos
node default {
include f_resolv_conf
include f_ntp_conf
include f_snmp_conf
include f_sshd_config
include s_snmp
include s_ntp
include s_sshd
}

Todos los include hacen referencia a ficheros dentro de classes/ con la extensión .pp Por adptar una nomenclatura los que empiezan con f_ hacen referencia a ficheros de configuración y los que empiezan con s_ a la monitorización de servicios. Pongo un ejemplo de cada uno, todos son iguales.

puppetmaster:/etc/puppet/manifests# cat classes/f_resolv_conf.pp
class f_resolv_conf {
file {“/etc/resolv.conf”:
ensure => present,
mode => 644,
owner => root,
group => root,
source => “puppet://puppetmaster/files/resolv.conf”
}
}

Las variables son autoexplicativas, verdad?

Comentar únicamente, que el servir el fichero se hace a través de un pequeño servidor web que se instala con el puppetmaster y escucha en el puerto 8140/tcp aunque también tiene el 8443/tcp abierto y a la escucha para las peticiones de certificados.

puppetmaster:/etc/puppet/manifests# cat classes/s_ntp.pp
class s_ntp {
service { “ntpd”:
pattern => “ntp”,
ensure => “running”,
start => “service ntpd start”,
stop => “service ntpd stop”,
hasstatus => “true”,
hasrestart => “true”,
}
}

Nos podemos encontrar un problema en las variables start y stop. No todas las distribuciones Linux arrancan y paran servicios de la misma manera. Para solventar éste problema, Puppet Linux nos permite, dentro de la clase, hacer distinciones de distros y aplicar unos comandos u otros según corresponda. Para ésto se utiliza la herramienta facter, que se instala junto con el cliente puppet y que le permite, entre otras cosas, averiguar con quién está hablando. En mi entorno no he tenido que hacer ésta distinción, al menos todavía ya que todos los servidores corren RHEL. El hasstatus quiere decir que si los demonios de arranque/parada tienen la opción ‘status’ pues que la use para averiguar el estado del servicio, y el hasrestart para que si tienen la opción ‘restart’ se use en vez de hacer un stop/start a la hora de refrescar el servicio.

Y por la parte servidor poco más, pasamos ahora a la parte cliente.

Como he dicho, en los repos oficiales de RHEL no se encuentra Puppet, pero podemos echar mano de EPEL para la instalación.

En nuestro servidor cliente crearemos un /etc/yum.repos.d/epel.repo nuevo con los siguiente:

[epel]
name=Extra Packages for Enterprise Linux 5 – $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-5&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 5 – $basearch – Debug
#baseurl=http://download.fedoraproject.org/pub/epel/5/$basearch/debug
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-debug-5&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
gpgcheck=0

[epel-source]
name=Extra Packages for Enterprise Linux 5 – $basearch – Source
#baseurl=http://download.fedoraproject.org/pub/epel/5/SRPMS
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-source-5&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL
gpgcheck=0

Y nada más, ahora basta un yum -y install puppet. No es necesario tener registrada la máquina en la RHN, a no ser que el paquete contenga algunas dependencias que tienen que ser descargadas de los repos de RH, entonces nos fallará la instalación. Tendremos que registrar la máquina previamente.

Una vez instalado sólamente tenemos que configurar 2 ficheros:

1: /etc/puppet/puppet.conf -> añadimos una línea nueva en la sección [main] con ‘server = puppetmaster’ (nombre del servidor)

2: /etc/sysconfig/puppet -> añadimos PUPPET_EXTRA_OPTS=–report (para que genere reports de actividad)

Una vez tenemos todo configudado, vamos a validarnos en nuestro servidor con el certificado:

[root@bddesa1 ~]# puppetd -t
warning: peer certificate won’t be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won’t be verified in this SSL session
warning: peer certificate won’t be verified in this SSL session
info: Creating a new SSL certificate request for bddesa1.ha.gva.es
info: Certificate Request fingerprint (md5): 53:83:53:7E:50:49:85:B5:40:99:27:8A:03:4D:D3:92
warning: peer certificate won’t be verified in this SSL session
warning: peer certificate won’t be verified in this SSL session
warning: peer certificate won’t be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled
[root@bddesa1 ~]#

Ahora tenemos que firmar el certificado en nuestro servidor. Nos vamos al puppetmaster:

puppetmaster:/# puppetca –list
bddesa1 (53:83:53:7E:50:49:85:B5:40:99:27:8A:03:4D:D3:92)

puppetmaster:/# puppetca –sign bddesa1
notice: Signed certificate request for bddesa1
notice: Removing file Puppet::SSL::CertificateRequest bddesa1 at ‘/var/lib/puppet/ssl/ca/requests/bddesa1.pem’
puppetmaster:/#

Ahora que ya hemos firmado el certificado, volvermos a ejecutar puppetd -t en el cliente y vemos que conecta correctamente al servidor y empieza a actualizar los ficheros, chequear servicios y todo lo que le hayamos configurado.

Por ejemplo, los cambios del DNS:

— /etc/resolv.conf    2011-10-18 16:55:19.000000000 +0200
+++ /tmp/puppet-file.11280.0    2011-12-23 10:15:10.000000000 +0100
@@ -1,3 +1,6 @@
search domain.org
nameserver 1.2.3.4
nameserver 5.6.7.8
+options timeout:1 attempts:1
info: FileBucket adding {md5}e5b242192d3a5a4017158eb34c932925
info: /Stage[main]/F_resolv_conf/File[/etc/resolv.conf]: Filebucketed /etc/resolv.conf to puppet with sum e5b242192d3a5a4017158eb34c932925
notice: /Stage[main]/F_resolv_conf/File[/etc/resolv.conf]/content: content changed ‘{md5}e5b242192d3a5a4017158eb34c932925’ to ‘{md5}1b603ae49bc8c2e33e018085c9e2bf1a’

Arrancamos el servicio en el cliente: service puppet start

Y lo añadimos al arranque: chkconfig –level 35 puppet on

De ésta forma cuando haya que cambiar algo masivamente en todas las máquinas, entraremos al puppetmaster, cambiamos el fichero que conrresponda y añadimos alguno nuevo, y se replicará de forma automática entre todos los clientes.

Si tocamos algo de la configuración del puppetmaster no hace falta reiniciar el servicio ya que él sólo se autorecarga. Si queremos forzar la actualización de los clientes hay que entrar en cada uno de ellos y ejecutar ‘puppetd -t’, si no tocamos nada, cada 30 minutos los clientes hacen una nueva consulta al servidor.

He leído en algunos foros que el mini-servidor web que lleva el puppetmaster puede llegar a saturarse por muchas peticiones de los clientes. En éste caso, hay gente que lo ha sussituído por un Apache o cualquier otro. De momento, yo no me he encontrado con ningún problema y llego añadidas unos 30 servidores.

Salut! y espero que aproveche.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s