CAPÍTULO NOVENO PUPPET

Transcripción

1 CAPÍTULO NOVENO PUPPET En el capítulo anterior se han mostrado las 4 herramientas de software libre más representativas 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 comienza por lo tanto con un análisis detallado, ventajas y desventajas del sistema Puppet.

2

3 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 administradores 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 administradores 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 estados 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 sistema de meta administración presentado como lenguaje declarativo que describe la configuración deseada para un sistema. Su estructura está formada por un servidor central y varios clientes, tal como se muestra 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 detalles 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 107

4 Puppet: Meta Administración transformar dichas expresiones en código a bajo nivel que manipula los servicios y lograr 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 intentar evitar 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"]], Manifiesto de control de Apache 108

5 9. Puppet Ahora, partiendo de esta configuración se pueden definir fácilmente los nodos para ejecutar 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", node apache_2 { 15 # use a config that we pull from elsewhere 16 apache { 17 version => 2, 18 conf => " 19 user => "www-data", 20 group => "www-data", 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 el qué del cómo. Es aquí donde radica todo su potencial. El cómo se 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 tareas para ese sistema en esa arquitectura. Por su parte la configuración del qué, 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 servidor y varios clientes que trabajan contra este. Este esquema está representado 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 cliente se ejecuta contra un servidor específico y es este el que determina el estado que debe tener dicho host. Por defecto 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 aplicar sobre dicho nodo. Nota Un equipo con Puppet puede ejecutar sus propias configuraciones sin depender de un servidor central. 109

6 Puppet: Meta Administración 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. Puppet está compuesto por tres capas perfectamente diferenciadas, 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 configuración. La capa intermedia o capa de transacciones es la que ofrece Fig. 9.2: Capas Puppet la idempotencia del sistema: una configuración puede ser aplicada a un nodo un número indeterminado de veces. En 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 registrar cualquier cambio que se produzca en alguno de los clientes; Puppet siempre dispone de un historial de todo lo realizado. Nota 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. 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 el có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. Nota Para una mejor comprensión del sistema Puppet, alterar o añadir cualquier mejora, se aconseja revisar estas librerías. 110

7 9. Puppet Por ejemplo la librería usada por el recurso package (ver punto ) está descrita en el fichero package.rb y 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ías apt.rb y dpkg.rb, que se corresponden con sus respectivas aplicaciones de instalación de paquetes. 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ía apt.rb, porque su proveedor de paquetes es apt. En caso de un sistema Gentoo 1, 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 modular, 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 de rsync (ver 8.1), pero sí tiene la ventaja de que usa el estándar de transmisió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. 1 Distribución GNU/Linux orientada a usuarios con cierta experiencia. 2 Portage: gestor de paquetes, inspirado en los ports de FreeBSD. 111

8 Puppet: Meta Administración 9.1. Desventajas 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 Documentación Las continuas mejoras hacen que la documentación, si no se trabaja con la última versión, en ocasiones parezca incorrecta. 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 confianza. Sin soporte técnico No existe un soporte técnico oficial que apoye la aplicación. Interfaz No existe un interfaz de administración que facilite el desarrollo de estados para los nodos cliente ni permita configuraciones. 112

9 9. Puppet 9.2. Ventajas Software libre Puppet está licenciado bajo GPL. 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. 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. Ahorro de costes Provoca mayor productividad, lo que implica ahorro. Evita fallos Ante trabajos redundantes en numerosos equipos, la administración de los mismos con Puppet evita fallos, pues únicamente se modifica un fichero y se aplica la configuración a todos los nodos. Lenguaje declarativo Se describe el estado que se desea tener en un sistema, pero no se define cómo alcanzar dicho estado. 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 configuración frete al sistema/arquitectura. Sistema modular El sistema Puppet es ampliamente modular y permite la creación de código reutilizable. 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. 113