Un primer vistazo a Puppet


Bueno, hoy traigo un popurrí de conceptos sobre Puppet que espero sirvan para tener una primera idea de algunas de sus características y opciones. Si eres un master of puppets, éste no es tu post.

Puppet es una de las herramientas de gestión centralizada de servidores (y workstations) más conocidas. En su página web, ofrecen varios videos gratuitos que explican con más detalle qué es y cómo funciona.

Bolt y Puppet Tasks

Bolt: standalone, opensource agentless task runner para ejecutar ad-hoc imperative tasks en entornos pequeños.

$gem install bolt

Puppet tasks: para resolver tareas que no encajan bien en el modelo tradicional puppet. Las Puppet Tasks son una forma simple y rápida de actualizar paquetes al instante, reiniciar servicios o ejecutar cualquier otro tipo de acción similar en tus nodos.

# Ejecuto un comando en dos nodos (boron2 y boron5)
$bolt command run "netstat -an | grep 'tcp.*LISTEN'" -n boron2,boron5

# Pongo mis comandos en un script en cualquier lenguaje que entiendan mis nodos. 
# Este script se copiará a los nodos, en un dir temp, lo ejecutará, devolverá 
# el output y después lo eliminará
$bolt script run myscript.sh -n boron-2,boron-5

Cómo pasar de un SCRIPT a una TASK?

La API de las tasks, define cómo el programa debería recibir el input y cómo debería ser el output. Los tasks tienen API, los scripts no. Las tasks interpretarán cualquier parámetro que siga esta convención: ${PT_nameofparam} (PT = Puppet Task)

i.e. mytask.json

#!/bin/bash
netstat -an | grep 'tcp.*{PT_port}.*LISTEN'"

Ahora podemos usar «bolt task» en lugar de «bolt script»:

$bolt task run mytask.sh -n boron2,boron5 port=25

Módulos en Puppet

Las tasks pueden vivir dentro de módulos de Puppet. Puppet Development Kit (PDK) es una forma fácil de empezar a escribir módulos. Los módulos requiren de cierta estructura de carpetas:

$tree modules/packages/
packages/
+-- tasks
    +-- mytask.json
    +-- mystask.sh

Una vez tengamos nuestra task dentro de un módulo, podremos ejecutarla con bolt haciéndole referencia (modulename:taskname) además de pasárle el parámetro -m con el que le diremos dónde está el directorio que contiene mis módulos

$bolt task run packages:mytask -m ../modules -n boron2,boron5 port 25

Los módulos nos permiten tener las tareas ordenadas por función.

Metadata

Como vemos, en el ejemplo anterior además de la definición de la tarea dentro del módulo (mytask.sh), encontramos un fichero llamado igual, pero con extensión .json. Se trata de un fichero de metadatos. Este fichero sirve para añadir información útil de cara a compartir la tarea y reusarla. Básicamente añade documentación in-line para tus tareas (i.e qué parámetros necesita tu task, qué tipo de parámetros, cómo se los pasas -environment, etc.)

El metadata, está en el mismo directorio que tu task, se llama igual, pero con formato y extensión .json

Conceptos básicos

Ahora que hemos visto una milésima parte de Puppet, es hora de poner un poco de órden. Puppet es lenguaje declarativo; tienes que definir el estado final del sistema, los recursos que tendrá el sistema, así como las dependencias entre ellos.

i.e. recursos de puppet

file{$web_directory:
ensure => directory,
owner => 'www-data',
group => 'www-data',
}

host{$virtual_host:
ip => '127.0.0.1',
}

Puppet consta de:

  • Una infraestructura basada en agent/master
  • PuppetDB: Reporting centralizado (PuppetDB)
  • MCollective (Live systems management): permite ver en tiempo real el estado de nuestras máquinas, ver cuales tienen tal configuración o tal paquete y aplicar cambios «ligeros» en masa
  • The puppet forge: un montón de módulos ya definidos y listos para usar.

Puppet agent

  • Se instala en cada server.
  • Hacen el trabajo de instalar y configurar el software. Son ellos quienes inician las acciones (no es el master)
  • Pueden configurarse para ejecutarse de forma regular, bajo demanda, o nada
  • Puede ser ejecutado en modo «noop» (no operations) para ver el estado actual del sistema, compararlo con el deseado, y devolver un report
  • «Masterless Puppet»: Puedes ejecutar el «Puppet Lifecycle» entero desde el propio server con «puppet apply», que consta de:
    1. Lee el fichero de configuración
    2. Compila el catálogo
    3. Aplica cambios en el sistema local

Puppet master

  • Mantiene una cópia del código de puppet (modulos, manifests…). Cuando un agente contacta al master, éste determina qué software y configuración aplica para ese agente, y configura un (largo) fichero de catálogo que se le envía al agente para que lo procese.
  • Es el repositorio de información sobre todo el entorno. Además de los módulos y manifiestos, también tiene datos relacionados con estos entornos.
  • Compila catálogos para cada nodo del entorno.
  • Recibe informes de todos los agentes.
  • Puppet master será está siendo reemplazado por el puppet server, el cual está basado en JVM en lugar de en Ruby.

MCollective

  • Ofrece la funcionalidad de «push» en Puppet (hemos visto que son los agentes los que inician cualquier tarea, no el master)

Puppet es cross-platform

  • Puppet se puede ejecutar en cualquier sistema que soporte Ruby.
  • «facter» recoge la info del server y se lo pasa al master, indicándole cómo el catálogo se debería aplicar.
  • La capa de abstracción de recursos (RAL) require de «tipos» para definir recursos, y «providers» que definen la interacción (o el cómo) se hará (i.e. mkdir en linux).

[Fuente]

Un poco más en detalle

Y para finalizar,

Recursos
Se encargan de (y por tanto definen) que exista un usuario, un fichero o que esté instalado un determinado paquete (user, file, package, service, etc.). La definición de un recurso sigue el siguiente formato:

resource_type { 'resource_name'
  attribute => value
  ...
}

Manifest
Los programas en Puppet se llaman manifests. Contienen código puppet y los ficheros tienen la extensión .pp

Clases
En Puppet, las clases son bloques de código que pueden ser llamados desde cualquier otra parte. Las clases pueden ser declaradas de dos formas:

1) Normal: Puppet evaluará el código de la clase

include example_class

2) Como recurso: permite especificar los parámetros de la clase, los cuales sobreescribirán los valores por defecto de los atributos de la clase.

class { 'example_class': }

i.e. de uso de esta segunda opción:

node 'host2' {
  class { 'apache': }             # use apache module
  apache::vhost { 'example.com':  # define vhost resource
    port    => '80',
    docroot => '/var/www/html'
  }
}

NOTA: Al hacer include de una clase, ésta se declarará, pero si se vuelve a hacer el mismo includo, no tendrá efecto pues la clase ya se ha incluído. También se puede hacer «require», que actuará como dependencia, es decir le indicará a Puppet que esa clase se tiene que aplicar antes que cualquier recurso de la propia clase.

Modulos
Ya hemos introducido los módulos varios párrafos antes. Sólo añadir que tienen una estructura de directorios específica; consta de una colección de manifests y data (ficheros, templates, etc.) y que se usan para tener el código de puppet organizado. Es BEST PRACTICE usar módulos para organizar casi todos tus manifests.

Un módulo básico consta de: [puppet-root-folder]/modules/[module-name]/manifests/init.pp
En este fichero, se define una clase llamada igual que el [module-name] y dentro de la clase se contendrá el manifest.

Node block
Un bloque de código tipo «nodo» se aplicará únicamente a los agentes que hagan match con ese nodo.

[Fuente]

Deja una respuesta

Tu dirección de correo electrónico no será publicada.