CAPÍTULO NOVENO
P
UPPET
En el capítulo anterior se han mostrado las 4 herramientas de software libre más repre-sentativas para la gestión de configuraciones. Al finalizarlo se optó por elegir a Puppet como la herramienta de meta–administración ideal para el control de sistemas. En los siguientes capítulos se irá mostrando dicho software, para finalizar en el capítulo 14 con un ejemplo de aplicación empresarial de todo lo expuesto hasta ese momento. Se comien-za por lo tanto con un análisis detallado, ventajas y desventajas del sistema Puppet.
9. Puppet
Los administradores de sistemas por norma general suelen escribir pequeños programas o script’s que realizan tareas muy simples, los cuales les ayudan a realizar las tareas más rápidamente. Si se trabaja en una organización con cientos o miles de equipos, el mantenimiento de estos se complica todavía más.
En ocasiones, algunas de las herramientas creadas por los administradores pueden ser muy buenas y potentes, pero rara vez salen del entorno de trabajo, por lo que cada uno tendrá sus soluciones y nunca serán uniformes y maduras. Cada administrador tendrá que crearse la suya.
Puppet nace con la idea de eliminar este problema. Fue creado para ayudar a los admi-nistradores con la implementación de una herramienta única y centralizada de gestión, sobre la cual depositar de manera sencilla las configuraciones y estados de los equipos, pudiendo ser reutilizadas. Puppet logra esto de dos formas:
a. Proporcionando un framework simple que pretende simplificar el trabajo de los ad-ministradores de sistemas.
b. Reutilizando el mayor código posible y permitiendo un sistema modular.
Con esto se consigue que el trabajo de administración sea mucho más simple, efectivo y eficaz, ya que sobre un pequeño servicio,puppetmasterd, se describen todos los esta-dos de los equipos. También se garantiza que el trabajo esté bien hecho, pues evita las repeticiones de tareas monótonas y el posible fallo que esto origina.
Fig. 9.1:Sistema Puppet
Puppet es una herramienta de gestión de configuraciones o lo que es lo mismo, un siste-ma de meta–administración presentado como lenguaje declarativo que describe la con-figuración deseada para un sistema.
Su estructura está formada por un servidor central y varios clientes, tal como se mues-tra en la figura 9.1. A mayores, a bajo nivel están localizadas todas las librerías que expresan la forma de trabajar.
En lugar de usar las técnicas actuales de administración de sistemas, Puppet crea un nuevo lenguaje para expresar la relación existente entre los servidores, los servicios que prestan y los objetos básicos que componen su configuración, en vez de manejar los de-talles de como realizar la configuración necesaria o prestar un determinado servicio. Los usuarios Puppet pueden expresar la configuración deseada para un host basándose en abstracciones ya implementadas a bajo nivel (ver figura 9.2). Estas son usadas para
transformar dichas expresiones en código a bajo nivel que manipula los servicios y lo-grar las configuraciones.
Una correcta configuración debe, lógicamente, proporcionar toda la información posible a la herramienta de configuración, pero esta también debe comprender que dichos datos son complicados de manejar.
La parte más compleja del sistema es la integración de las relaciones entre los servicios y los datos que lo conforman. Una de las principales características de Puppet es inten-tar eviinten-tar la complejidad de definición y por tanto ofrecer al usuario un sistema de alto nivel donde no sea necesario comprender los datos a bajo nivel sino sólo las relaciones entre los datos.
Un ejemplo de lo expresado con antelación se representa a continuación. En él se puede ver una clase que maneja datos sobre servidores Apache. Puppet únicamente maneja los atributos de Apache que necesita para realizar las configuraciones, sin importar la versión de Apache que esté en cada nodo.
define apache(version, conf, user, group) { # abstract across apache1 and apache2 $name = $version ? { 1 => "apache", 2 => "apache2", } package{ $name: install => true, } file { "$conf": user => "$user", group => "$group", source => "$conf", }
# we want the service to restart if the config file changes # or if the package gets upgraded
service { "$name": running => true,
subscribe => [file["$conf"], package["$name"]], }
}
9. Puppet
Ahora, partiendo de esta configuración se pueden definir fácilmente los nodos para eje-cutar las diversas versiones de Apache. Lo más destacado de esto es que no es necesario tener los conocimientos a bajo nivel, sino simplemente decidir qué versión hay en cada nodo.
1 # import our apache definition file
2 import "apache"
3
4 node apache_1 {
5 # use a locally-available config file
6 apache { 7 version => 1, 8 conf => "/nfs/configs/apache/server1.conf", 9 user => "www-data", 10 group => "www-data", 11 } 12 } 13 14 node apache_2 {
15 # use a config that we pull from elsewhere
16 apache { 17 version => 2, 18 conf => "http://configserver/configs/server2/httpd.conf" 19 user => "www-data", 20 group => "www-data", 21 } 22 }
Definición de estado para dos nodos
Como se puede ver observar en el nodo “apache_1” se va a ejecutar la versión 1 de Apache, mientras que en el nodo “apache_2” se va a realizar una instancia de Apache2.
Puppet es un lenguaje declarativo que separa elqué del cómo. Es aquí donde radica todo su potencial.
Elcómose realiza a bajo nivel en las librerías escritas en Ruby, que proporcionan una entidad determinada para cada máquina, sabiendo de antemano “cómo” realizar las ta-reas para ese sistema en esa arquitectura.
Por su parte la configuración delqué, queda en manos del administrador, que tiene que decidir “qué” acción realizar para cada host o grupo de hosts o, mejor dicho, definir o describir el estado deseado de cada host.
Como ya se mencionó antes, una red basada en Puppet consta de un ser-vidor y varios clientes que trabajan contra este. Este esquema está repre-sentado en la figura 9.1. El nodo servidor es consciente de la configuración completa de la red y del sistema; los clientes no tienen por qué conocerla.
Un equipo con Puppet puede ejecutar sus pro-pias configuraciones sin depender de un ser-vidor central.
Nota Un cliente se ejecuta contra un servidor
específico y es este el que determina el estado que debe tener dicho host. Por de-fecto un equipo cliente realiza un “pull” a su servidor. Es el servidor el que procesa la información y posteriormente genera un árbol de clases que tendrá que apli-car sobre dicho nodo.
En ocasiones dentro del servidor se producen cambios que es necesario que se envíen a los clientes. En este caso, es el servidor el que realiza un “push” a dichos nodos para que estos soliciten el estado nuevamente.
Fig. 9.2:Capas Puppet
Puppet está compuesto por tres capas perfectamente diferen-ciadas, que se representan en la imagen 9.2. Dichas capas constituyen la principal diferencia de este sistema de gestión de configuración con el resto y son las que le aportan la mayor potencia.
La primera de las capas ya fue vista y se verá con más detalle en los capítulos siguientes y es la capa de lenguaje de confi-guración.
La capa intermedia o capa de transacciones es la que ofrece laidempotenciadel sistema: una configuración puede ser apli-cada a un nodo un número indeterminado de veces. En apli-cada chequeo que el cliente solicita se comprueba que el estado del sistema sea el descrito; en caso de que esto no se corresponda, se ajusta lo necesario. Este comportamiento es el que permite usar las posibilidades de registro en log’s del sistema e incluso, en futuras versiones, se espera que esté disponible la posibilidad de deshacer cambios efectuados y volver a estados anteriores. Actualmente la capa de transacciones se encarga de regis-trar cualquier cambio que se produzca en alguno de los clientes; Puppet siempre dispone de un historial de todo lo realizado.
Si los cambios se efectúan se registran en el sistema.
Si los cambios están registrados en el sistema, quiere decir que se han efectuado.
Nota
La tercera y última capa que queda por comentar es la capa de más bajo nivel, la capa de abstracción de recursos. Dicha capa es la más importante, potente y la que conforma el sistema a bajo nivel. Como ya se mencionó, Puppet se centra en resolver el qué y no elcómo, pero este también hay que resolverlo en algún momento y es en esta capa dónde se realiza. Las librerías de bajo nivel, escritas en Ruby, son las encargadas de realizar las modificaciones necesarias según los recursos empleados. Dichas librerías están incluidas en las versiones de Puppet de todos los sistemas y se instalan como librerías estándar de Ruby, localizadas bajo /usr/lib/ruby/puppet/. Si se observa detenidamente dicho directorio es fácil saber para qué sirve cada librería y también saber lo que es capaz de realizar cada recurso en función de su código.
Para una mejor comprensión del sistema Puppet, alterar o añadir cualquier mejora, se aconseja revisar estas librerías.
9. Puppet
Por ejemplo la librería usada por el recurso package (ver punto 11.2.1) está descrita en el ficheropackage.rby según el sistema operativo que se detecte llama a una u otra de las librerías de instalación de paquetes que son las encargadas de realizar el trabajo. En el caso de los sistemas Debian, por ejemplo se puede hacer uso de libreríasapt.rb
ydpkg.rb, que se corresponden con sus respectivas aplicaciones de instalación de pa-quetes. Son todas estas librerías las que realizan el “cómo” que se describe en la capa inicial del lenguaje. En el caso puntual de lo comentado con antelación, para sistemas Debian, se usará la libreríaapt.rb, porque su proveedor de paquetes es apt. En caso de un sistema Gentoo1, se usaráportage.rb, porque el sistema de paquetería de este
se llama así2.
Es así comprensible que si se desea añadir un nuevo proveedor o un nuevo recurso, haya únicamente que implementar el código que lo realice, siendo entonces el sistema modu-lar, flexible y ampliable.
Los recursos de Puppet presentan una relación lógica consigo mismos. Esto quiere decir que son los propios recursos los que controlan a nivel de sintaxis que el estado declarado para un nodo no sea incongruente; no es posible definir un estado donde, por ejemplo, un usuario exista y no deba existir al mismo tiempo. La definición ya dará error.
La transmisión de datos de Puppet no está tan perfeccionada como puede estar, por ejemplo, la dersync(ver 8.1), pero sí tiene la ventaja de que usa el estándar de transmi-sión de datos XMLRPC bajo HTTPS. Como es lógico todos los datos viajan cifrados por la red, pero esto facilita la posible integración de los clientes Puppet con otros sistemas o interfaces de administración que también usen dicho protocolo.
Xen, que se estudió en el capítulo 6, permite que los datos de comunicación entre las máquinas y el servidor y entre servidores use también el protocolo XMLRPC, por lo que podría ser posible una integración sobre una interfaz de administración genérica que uniese a Xen con Puppet.
1Distribución GNU/Linux orientada a usuarios con cierta experiencia. 2
Portage: gestor de paquetes, inspirado en los ports de FreeBSD.
9.1. Desventajas
n Sistema innovador
Puppet todavía es un proyecto que está creciendo y esto se nota especialmente en las versiones del software, que cambian cada poco tiempo e incluyen una gran cantidad de mejoras, lo que obliga a estar actualizado todo el tiempo.
La versión actual de Puppet es la 0.24.
n Documentación
Las continuas mejoras hacen que la documentación, si no se trabaja con la última versión, en ocasiones parezca incorrecta.
n Sin apoyo específico
Reductive Labs es la empresa que está detrás de Puppet, pero todavía no es una empresa de renombre destacado en el mercado, por lo que puede no inspirar con-fianza.
n Sin soporte técnico
No existe un soporte técnico oficial que apoye la aplicación.
n Interfaz
No existe un interfaz de administración que facilite el desarrollo de estados para los nodos cliente ni permita configuraciones.
9. Puppet
9.2. Ventajas
X Software libre
Puppet está licenciado bajo GPL.
X Idempotencia
Las configuraciones no tienen un número máximo de veces para ejecutarse. Se aplicarán siempre que se detecte un cambio en el sistema y el estado final del sistema siempre será el mismo.
X Simplicidad y rapidez
La creación de un sistema Puppet es muy simple y la administración de sistemas usándolo como base aumenta la eficiencia del trabajo.
X Ahorro de costes
Provoca mayor productividad, lo que implica ahorro.
X Evita fallos
Ante trabajos redundantes en numerosos equipos, la administración de los mis-mos con Puppet evita fallos, pues únicamente se modifica un fichero y se aplica la configuración a todos los nodos.
X Lenguaje declarativo
Se describe el estado que se desea tener en un sistema, pero no se define cómo alcanzar dicho estado.
X El “qué” frente al “cómo”
Se deja al administrador que sea quien describa lo qué desea, pero no el cómo. Este ya no es relevante. Con ello se consigue una perfecta abstracción de la configura-ción frete al sistema/arquitectura.
X Sistema modular
El sistema Puppet es ampliamente modular y permite la creación de código reuti-lizable.
X Capa de abstracción
Es la capa más importante del sistema, sobre la que se decide el “cómo”. Existe la posibilidad de realizar nuevas mejoras en ella de forma muy simple, pues está programada en Ruby.
Finalizado este capítulo los conceptos y las ventajas de Puppet deben ser conocidos por el lector y se considera entonces que la elección de este como una buena opción para implementar el modelo del sistema de gestión de administración propuesto.
En el capítulo siguiente se va a seguir avanzando con los conceptos del modelo y para ello se hará referencia a la instalación de los servicios de Puppet, tanto en cliente como en servidor, así como la configuración de estos.
