Vagrant: Instalación y primeros pasos

Esta entrada la tenía pendiente desde que el otro día hablé con +Susana López Barreras sobre el tema. Así que por fin me decidí terminarla y publicarla. Servirá para ella y para más gente, espero.

¿Qué es Vagrant?

Vagrant es una herramienta pensada para facilitar la creación y configuración automática de entornos de desarrollo virtualizados. Aunque en sus orígines únicamente se podía usar con VirtualBox, actualmente ya es capaz de desplegar máquinas en sistemas como VMware, Amazon EC2, etc. La gran ventaja es que trabaja de la mano directamente con herramientas de centralización de configuraciones, tales como Puppet o SaltStack, de las que hablamos aquí en más de una ocasión. Es gracias a esta perfecta combinación donde reside el verdadero poder de Vagrant.

Instalación

Vagrant está disponible en los repositorios de la mayoría de distribuciones, pero yo personalmente recomiendo bajar el paquete desde la web oficial, Vagrantup.com, para disponer así de la última versión. Compensa tener la versión de la web oficial, ya que tiene importantes mejoras. Así que nos dirigimos a la parte de descargas y seleccionamos el sistema operativo que tengamos y lo descargamos. Yo personalmente me bajo la de Debian 64 ;-)

shell> wget https://dl.bintray.com/.../vagrant_1.6.5

Una vez la tenemos, simplemente instalamos el nuevo paquete,

shell> dpkg -i vagrant_1.6.5_x86_64.deb

Y desde este momento ya disponemos de Vagrant instalado en el sistema. Crear una nueva instancia de una máquina virtual a partir de ahora será muy sencillo y trivial.

Uso de Vagrant

Efectivamente, Vagrant, si no se emplea con SaltStack o Puppet, no es más que una forma diferente de crear máquinas virtuales en VirtualBox, por decirlo de forma sencilla. Aun así, es una forma muy cómoda, pues no necesitas realizar ningún tipo de instalación. Esta es la primero ventaja que tiene Vagrant. Si necesitas una máquina con un determinado sistema operativos, ya no es necesario descargar la ISO e instalarla, desde Vagrant es más sencillo.

Crear nueva máquina

shell> vagrant init
 A `Vagrantfile` has been placed in this directory. You are now
 ready to `vagrant up` your first virtual environment! Please read
 the comments in the Vagrantfile as well as documentation on
 `vagrantup.com` for more information on using Vagrant.

A continuación editamos dicho fichero (/tmp/Vagrantfile),

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
   config.vm.box = "ubuntu/precise64"
end

Dejándolo tal y como se muestra anteriormente. A continuación, simplemente,

shell> vagrant up
 Bringing machine 'default' up with 'virtualbox' provider...
  ==> default: Importing base box 'ubuntu/precise64'...
  ==> default: Matching MAC address for NAT networking...
  ...

Este comando hará todo lo necesario. Es decir, se descargará la pre-imagen de la máquina precise64 si fuese necesario, creará una nueva instancia de la máquina en VirtualBox (por defecto) y la arrancará. Para acceder a ella,

shell> vagrant ssh

Welcome to Ubuntu 12.04.5 LTS (GNU/Linux 3.2.0-72-virtual)
...

vagrant@vagrant-ubuntu-precise-64:~$

Si necesitas otra máquina, cual sea, simplemente editas el fichero y la creas. Sin complicaciones. Existen multitud de máquinas libres para descarga en vagrantcloud.

Destruir máquina

La ventaja de Vagrant y que veremos en próximas entradas es el poder de la auto-creación, pero por el momento, si tras levantar tu máquina virtual y trabajar con ella varios días, finalizaste el trabajo y ya no quieres que te ocupe espacio, simplemente,

shell> vagrant destroy
 Are you sure you want to destroy the 'default' VM? [y/N] y
  ==> default: Forcing shutdown of VM...
  ==> default: Destroying VM and associated drives...

Más

Como era de esperar, puedes apagarla, volver a levantarla, suspenderla y un largo etcétera de funcionalidades, según lo que aporte el sistema de virtualización que emplees.

Leer más

Facter: Ampliando sus posibilidades

Para aquellos que no lo sepan, Facter es una pequeña librería en la que se apoya Puppet, multiplataforma, y que sirve para obtener información de los sistemas. Su integración con Puppet es máxima y es gracias a ella que facilita la toma de decisiones según los equipos.

Desde la versión 1.7 de Facter, se han incluido una gran cantidad nueva de facts, lo que permite ya de base poder obtener mucha más información de los equipos. A mayores de este duro trabajo, también han creado una forma muy lógica y siguiendo el uso en Linux, de extender su funcionalidad. Desde esta nueva versión, es posible crear nuevas variables, escritas en texto, json o yaml. Según el tipo de fichero que creemos, debemos de emplear su sintaxis correcta.

Tras actualizar la versión de facter empleada, para comenzar a crear nuestras propias variables, únicamente debemos de crear la carpeta que las va a contener,

shell> mkdir /etc/facter/facts.d

Y a continuación, meter ahí todos los ficheros que deseemos para extender las funcionalidades que deseemos. Por ejemplo, según el formato,

• .yaml

  key1: val1
  key2: val2
  key3: val3
  

• .json

  {
     "key1": "val1",
     "key2": "val2",
     "key3": "val3"
  }
  

• .txt

  key1=value1
  key2=value2
  key3=value3
  

Tras ello, simplemente con ejecutar facter podremos ver las nuevas variables que hemos creado.

shell> facter | grep key

Si empleáis Puppet, creo que esta nueva opción os resultará, sin duda, de bastante utilidad.

Más información:

• docs.puppetlabs.com/custom_facts

Leer más

Puppet, sincronizar directorios

Puppet es una herramienta de meta-administración estupenda de la que ya hemos hablado en este blog en numerosas ocasiones. Hoy vamos a ver una funcionalidad no muy extendida, pero que puede sernos de gran ayuda llegado el caso. Cómo sincronizar directorios y contenido desde Puppet.

Aunque pueda parecer una chorrada, nos puede servir, por ejemplo, para automatizar el montaje de nuestro clúster de servidores web. Cuando se crea una nueva instancia automáticamente se copia el contenido completo del servidor web a donde corresponda, por lo que el montaje es automático y desatendido.

Para lograrlo, simplemente tenemos que emplear el tipo file de Puppet, pero en este caso indicando que es un directorio, tal como sigue,

file { "/var/www/web_site/":
   ensure   => directory,
   recurse  => true,
   checksum => md5,
   purge    => false,
   backup   => false,
   force    => true,
   owner    => 'www-data',
   group    => 'www-data',
   mode     => '644',
   source   => "puppet://$master/files/web-site/";

Así de simple lograremos que tras la ejecución de Puppet, el contenido de /var/www/web_site sea exactamente el mismo que el que está en el servidor Puppet, garantizando tener en todos los nodos la misma versión de la web, en este caso.

Leer más

dnsdomainname: Name or service not known

Si estáis trabajando con un cliente Puppet, y cada vez que éste se ejecuta sobre la máquina os da el siguiente error,

shell> puppetd agent --test
dnsdomainname: Name or service not known
info: Caching catalog for ...

Lo más probable es que cuando configurasteis el equipo se os olvidara de colocar una entrada en /etc/hosts. Esto pasa, por ejemplo, cuando a la máquina se le cambia de nombre. La forma de resolverlo es sencilla. Agregamos el nombre del equipo en el fichero citado apuntado a localhost,

127.0.1.1      nameOfMachine

Si volvéis a lanzar Puppet ya no debería de lanzaros el error de dnsdomainname.

La entrada dnsdomainname: Name or service not known la puedes leer en Puppet Linux.

Leer más

Puppet, cron cada 5 minutos

Ya hacía que no hablaba de Puppet en el blog, así que ya tocaba. No se si os acordáis, ya hace bastante tiempo, escribí un post donde explicaba cómo emplear valores aleatorios en puppet, lo que resultaba especialmente útil para un manifiesto que use cron, ya que evitábamos que todas las máquinas tirasen del recurso programado al mismo tiempo.

Pues hoy vamos a ver algo más sobre cron aplicado desde Puppet. Este es el manifiesto de partida,

cron { "update mirror":
   command   => "/usr/local/sbin/update_mirror",
   user      => root,
   hour      => 18,
   minute    => 30,
   subscribe => File["/usr/local/sbin/update_mirror"],
   ensure    => present;
}

Como se puede observar vemos que a las 18:30 se ejecuta el tarea programada. Ahora imaginémonos por un momento que nos interesa que el trabajo se ejecute cada 10 minutos. Pues bien, para hacer eso, podíamos suprimir la línea de la hora y quedarnos con una línea de minutos tal que así,

cron{
   ...
   minute    => [2,15,25,35,45,55],
   ...
}

Realmente esta opción es perfectamente viable, pero el resultado que produce no es muy bonito que digamos, a nivel de cron,

shell> crontab -e
5,15,25,35,45,55 * * * *   /usr/local/sbin/update_mirror

Aunque esta solución es perfectamente válida, quizás no sea la más óptima, ya que si tenemos que ejecutarlo cada minuto, nos quedaría una línea "un poco grande". Así que para optimizarlo, podemos hacer algo tal que así:

cron{
   ...
   minute    => "*/10"
   ...
}

Lo que produciría el siguiente resultado,

shell> crontab -e
*/5 * * * *   /usr/local/sbin/update_mirror

Leer más

puppet: Instalación y puesta en marcha del agente/cliente

En el anterior post hablamos sobre cómo realizar la instalación de un servidor en puppet. Ahora nos queda la parte del cliente. Los pasos que vamos a dar, para tener una guía que seguir son:

1. Instalación del agente
2. Primera conexión del agente al servidor
3. Firmado en el servidor del nuevo cliente (autorización del cliente)
4. Nueva conexión del agente al servidor
5. Configuración del cliente

Pues ya sin más demora vamos a comenzar con la instalación del cliente. Para ello,

agent@shell> apt-get install puppet

Y realizamos seguidamente la primera conexión al servidor puppet, que tenemos ya arrancado. Lo ideal es tener configurado en la red el servidor de puppet como una entrada DNS. En caso de que no esté, podemos conectar igualmente por IP.

agent@shell> puppetd agent --server=192.168.1.50 --test
  info: Creating a new SSL key for sid.dominio.com
  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 sid.dominio.com
  info: Certificate Request fingerprint (md5): BD:6D:27:F1:...
  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

Puesto que del lado del servidor no tenemos la opción de autofirmado, sino que queremos firmar/autorizar los clientes uno a uno, ahora desde el servidor tendremos que aceptar la nueva firma que está pendiente. Para ello, vamos al lado del servidor y

server@shell> puppetca --list
  "sid.dominio.com" (BD:6D:27:F1:...)

Vemos que tenemos una pendiente de ser firmada, así que la firmamos.

server@shell> puppetca --sign sid.dominio.com
  notice: Signed certificate request for sid.dominio.com
  notice: Removing file Puppet::SSL::CertificateRequest sid.dominio.com at '/var/lib/puppet/ssl/ca/requests/sid.dominio.com.pem'

server@shell> puppetca --list --all
  + "sid.dominio.com"  (9F:0C:7F:F8:...)
  + "test.dominio.com" (82:C6:28:68:...)

El signo + antes del nombre al listar los equipos firmados indica que ya lo tenemos listo, así que sólo nos queda regresar el cliente y ejecutar puppet para que aplique los cambios descritos en el default.pp.

agent@shell> puppetd agent --server=192.168.1.50 --test
  info: Caching catalog for sid.dominio.com
  info: Applying configuration version '1351680751'
  notice: /Stage[main]//Node[default]/File[/tmp/prueba]/ensure: created
  info: Creating state file /var/lib/puppet/state/state.yaml
  notice: Finished catalog run in 0.03 seconds

Y lo comprobamos,

agent@shell> ls -l /tmp/prueba
  -rwxr-xr-x 1 root root 0 Nov 01 18:52 /tmp/prueba

Si este artículo te ha interesado, quizás te puedan interesar también:

• Móntate tu propio servidor puppet desde cero
• Instala puppet en sistemas RedHat/CentOS

Leer más

puppet: Instalación del servidor

Después de que algunas personas me hayan pedido que haga una breve guía de cómo instalar y usar puppet por fin he sacado tiempo para hacerla. En una serie de entradas vamos a ir viendo desde cómo instalar puppet a cómo hacer algo más complejo con nuestro servidor, pasando lógicamente por la conexión del primer cliente.

Como sistema operativo para el servidor vamos a emplear Debian Squeeze (actual estable). Para las pruebas vamos a emplear una máquina llamada test, que hará de servidor. La idea es dejar un servidor puppet al que se puedan conectar los clientes y lógicamente, un servidor de certificados para que todas las comunicaciones vayan también cifradas.

En la versión estable de Debian, ahora mismo tenemos la versión 2.6.2 de puppet, tanto para servidor como para agente.

shell> apt-cache search puppet
puppet-common - Centralized configuration management
puppet        - Centralized configuration management - agent
puppetmaster  - Centralized configuration management - master
shell> apt-cache show puppetmaster 
Package:        puppetmaster
Priority:       optional
Section:        admin
Installed-Size: 384
Maintainer:     Puppet Package Maintainers
Architecture:   all
Source:         puppet
Version:        2.6.2-5+squeeze6
...
shell> apt-cache show puppet
Package:        puppet
Priority:       optional
Section:        admin
Installed-Size: 336
Maintainer:     Puppet Package Maintainers
Architecture:   all
Version:        2.6.2-5+squeeze6
...

Puesto que empleamos paquetes del repositorio oficial, la instalación es muy sencilla,

shell> apt-get install puppetmaster

Esto instalará todos los paquetes necesarios para que nuestro servidor funcione correctamente y nos lo dejará como un servidor del sistema. Servicio que únicamente nos quedará por configurar para que todo trabaje a la perfección. Cuando termine la instalación, dependerá del número de paquetes que necesites descargar y de la velocidad de tu línea, pasaremos a la parte de configuración.

En el fichero /etc/default/puppetmaster tenemos que cerciorarnos de que se permita el arranque del servicio. Puesto que vamos a emplear la instalación para un número pequeño de equipos, no vamos a configurar las opciones de alto rendimiento con proxy's de puppet.

...
START=yes
...

A continuación vamos a permitir el acceso a ficheros a los equipos y dominios que se van a conectar a nuestro equipo. Puppet por defecto contiene todos los ficheros de los módulos en /etc/puppet/files, por lo que vamos a permitir el acceso al contenido de dicha carpeta a los clientes. Para ello editamos el fichero /etc/puppet/fileserver.conf y permitimos las IP's y dominios que nos interesen. El mismo acceso habilitaremos para los plugins, por si fuese necesario sincronizar alguno desde el master.

# This file consists of arbitrarily named sections/modules
# defining where files are served from and to whom
[files]
   path  /etc/puppet/files
   allow 192.168.1.0/24
   allow *.domain_1.es
   allow *.domain_2.com

[plugins]
   path  /var/lib/puppet/plugins
   allow 192.168.1.0/24
   allow *.domain_1.es
   allow *.domain_2.com

Y finalmente sólo queda configurar el servicio propiamente dicho. En versiones anteriores existían varios ficheros de configuración, uno para el servidor y otro para el cliente, sin embargo en las últimas versiones dichos ficheros se han unificado, dejando un único fichero de configuración, /etc/puppet/puppet.conf, con varias secciones.

Vamos por lo tanto a realizar una configuración básica para poder comenzar a trabajar con puppet. Aunque existen muchas configuraciones posibles, prácticamente las opciones por defecto permiten ya emplear el servicio desde un primer momento. Un ejemplo de configuración válida es,

[main]
   logdir           = /var/log/puppet
   vardir           = /var/lib/puppet
   ssldir           = /var/lib/puppet/ssl
   rundir           = /var/run/puppet
   confdir          = /etc/puppet
   factpath         = $vardir/lib/facter
   templatedir      = $confdir/templates
   reportdir        = /var/lib/puppet/reports
   modulepath       = $confdir/modules

   config           = $confdir/puppet.conf
   manifestdir      = $confdir/manifests
   manifest         = $confdir/manifests/site.pp
   fileserverconfig = $confdir/fileserver.conf

Tras finalizar la configuración arrancamos el servicio y comprobamos que todo se inicia correctamente.

shell> /etc/init.d/puppetmaster start
Starting puppet master.

shell> tail -f /var/log/daemon.log
Nov 01 17:35:44 test puppet-master[6650]: Starting Puppet master version 2.6.2

Si todo está correcto tendremos un mensaje similar al que apareció en mis log's, diciendo que todo está correcto y que el servicio se arrancó correctamente.

Ahora lo único que queda es configurar el fichero site.pp para indicarle que cargue los módulos y manifiestos que nos interese a nosotros. Puesto que este arranque es muy sencillo, únicamente vamos a configurar lo siguiente en /etc/puppet/manifests/site.pp

import "nodes/*.pp"

Y creamos la carpeta nodes y dentro el fichero default.pp que contendrá la definición a aplicar por defecto a los hosts. En nuestro caso, la creación de un simple fichero.

node default {
 file { "/tmp/prueba":
  owner  => root,
  group  => root,
  mode  => 755,
  ensure => present;
 }
}

Llegados a este punto, ya estamos listos para recibir las conexiones de los clientes, que veremos en el siguiente post.

Si este artículo te ha interesado, quizás te puedan interesar también:

• Instala puppet en sistemas RedHat/CentOS
• Instala puppet en sistemas Debian/Ubuntu

Leer más

Y tú, ¿aún no automatizas tareas con puppet?

El otro día @pepellou retwitteó el siguiente contenido,

¿Automatizar o no? He ahí la cuestión ;) twitpic.com/9v222d
— Laura Morillo (@Laura_Morillo) junio 11, 2012

Y la verdad es que el contenido está en sí muy bien. Representa en una línea muy clara lo que implica en administración de sistemas la automatización. Fuera del término 'geek', automatizar puede suponer una gran ventaja a la hora de ahorrarse trabajo y sobre todo, evitar fallos por replicación.

En el gráfico del tweet se representaba la diferencia entre administradores 'geeks' y 'no geeks'. Yo quiero subir un nivel y demostrar la verdadera potencia de puppet.

puppet: simple automatization

Juzgarlo vosotros: ¿vale la pena? ;-)


Si este artículo te ha interesado, quizás te puedan interesar también:

• Móntate tu propio servidor puppet desde cero
• Instala puppet en sistemas RedHat/CentOS
• Instala puppet en sistemas Debian/ubuntu

Leer más

puppet manifest for ntp

Clase ntp:

class ntp {
   package { "ntp":
      ensure     => installed;
   }

   group { "ntp":
      ensure     => present;
   }

   define ntpconf ($ntpserver = [ "0.debian.pool.ntp.org" ]) {
      file { "/etc/ntp.conf":
         owner   => root,
         group   => root,
         mode    => 644,
         content => template("ntp.conf.erb"),
         require => Package[ "ntp" ],
         notify  => Service[ "ntp" ];
      }
   }

   service { "ntp":
      name       => $operatingsystem ?{
         debian  => "ntp",
         ubuntu  => "ntp",
         default => "ntpd",
      },
      ensure     => running,
      enable     => true,
      provider   => debian,
      subscribe  => File[ "/etc/ntp.conf" ];
   }
}

Y la forma de usarlo,

include ntp
ntp::ntpconf { "ntp":
   ntpserver => [ "0.debian.pool.ntp.org", "127.0.0.1" ]
}

Leer más

puppet cheat sheet

Puppet, del que ya hablamos muchas veces en este blog tiene una perfecta y extensa guía de lenguaje que permite realizar las configuraciones necesarias, pero también ofrece una pequeña chuleta que sirve de guía para comenzar en esos primeros momentos.

La puedes descargar aquí y la verdad, tenerla siempre a mano es realmente útil.

Leer más

puppet, valores aleatorios de ejecución

En muchas ocasiones puede por el motivo que sea no interesarnos que un script se ejecute en todos los equipos al mismo tiempo, por ejemplo, para no colapsar una línea o un servidor. Si empleamos puppet para tener todos los datos y configuraciones sincronizadas, eso puede resultar algo complicado, pues lo que se escribe en un equipo se escribe en el resto. Si bien es cierto que para cada equipo se pueden definir diferentes tareas, imaginaros tener que 'configurar' una misma tarea para todos los equipos uno a uno, para eso no empleamos un sistema de meta-administración!

Pues bien, si partimos de la configuración de tarea cron habitual,

cron { "update mirror":
        command   => "/usr/local/sbin/update_mirror",
        user      => root,
        hour      => 18,
        minute    => 30,
        subscribe => File["/usr/local/sbin/update_mirror"],
        ensure    => present;
     }

aquí vemos que en todos los equipos que tengan configurado este cron, ejecutará el script /usr/local/sbin/update_mirror a las 18:30 todos los días. En este caso, el script consume un considerable ancho de banda, así que si por el motivo que sea se ejecuta en 5 equipos, puede dejarnos sin ancho de banda para trabajar. Por lo tanto... lo ideal sería poder ejecutarlo a horas diferentes, así que... desde puppet, ¿cómo lo hacemos?

$hour = fqdn_rand(23)
cron { "update mirror":
        command   => "/usr/local/sbin/update_mirror",
        user      => root,
        hour      => $hour,
        minute    => 30,
        subscribe => File["/usr/local/sbin/update_mirror"],
        ensure    => present;
}

Pues bien, simplemente creamos una variable que pueda tener un valor aleatorio de 0 a 23 y dependiente del cliente y éste lo escribimos en $hour. Ahora al actualiza el cliente veremos lo siguiente,

shell> puppetd agent --test
info: Caching catalog for mirror.cluster1
info: Applying configuration version '1338798215'
notice: /Stage[main]/Cron[update mirror]/hour: hour changed '18' to '14'
notice: Finished catalog run in 4.71 seconds

Vemos que cambiar el valor de 18 a 14, siendo 14 el valor aleatorio que ha obtenido del cliente. Si ahora se ejecuta en otro nodo, veremos que el valor es 22, es decir, el valor aleatorio de fqdn_rand(23).

shell> puppetd agent --test
info: Caching catalog for mirror.cluster2
info: Applying configuration version '1338798215'
notice: /Stage[main]/Cron[update mirror]/hour: hour changed '18' to '22'
notice: Finished catalog run in 4.26 seconds

Y con esto conseguimos aleatorizar los tiempos de ejecución de puppet.

Leer más

puppet: decisiones usando facter

puppet usa por defecto una serie de variables que son dadas por facter, un software que comprueba diversos parámetros del sistema cliente y se los envía al máster para poder usarlos y tomar decisiones.
Las principales variables de facter se verán en otro post, pero entre ellas se encuentra la versión del sistema operativo, el sistema operativo, la IP, el dominio, etc.



Un ejemplo de éste uso sería:

file { "localtime":
   path  => $operatingsystem ?{
      debian  => "/etc/localtime",
      ubuntu  => "/etc/localtime",
      redhat  => "/etc/sysconfig/clock",
      centos  => "/etc/sysconfig/clock",
      suse    => "/etc/sysconfig/clock",
      default => "/etc/localtime", 
   },
   owner => root,
   group => root,
   mode  => 0644;
}

O también, esta otra forma,

...
case $fqdn {
   server1.domain.com: {
      mailalias {
         logcheck:
            ensure    => present,
            recipient => [ "miguel@company.com" ];
      }
   }

   server3.company.es: {
      mailalias {
         logcheck:
            ensure    => present,
            recipient => [ "javier@company.com" ];
      }
   }

   default: {
      mailalias {
         logcheck:
            ensure    => present,
            recipient => [ "logs@company.com" ];
      }
   }
}
...

Leer más

Howto install puppet on CentOS

CentOS por defecto no tiene en sus repositorios una versión de puppet. ¡Increíble pero cierto! Por lo tanto, para poder usar puppet en CentOS o Red Hat, tendremos que instalarlo nosotros mismos desde cero.

En este post vamos a describir cómo poder hacerlo de forma sencilla y con paquetes ya compilados, en este caso por Puppet Labs. Los creadores de puppet ofrecen un repositorio con la última versión de puppet disponible para CentOS. Para agregar dicho repositorio, únicamente habrá que crear un nuevo fichero de tipo repositorio bajo /etc/yum.repos.d/ con la siguiente información.

shell> vi /etc/yum.repos.d/puppet.repo
[puppetlabs]
  name=Puppet Labs Packages
  baseurl=http://yum.puppetlabs.com/el/6/products/x86_64/
  enabled=1
  gpgcheck=0

[puppetlabs2]
  name=Puppet Labs Packages Deps
  baseurl=http://yum.puppetlabs.com/el/6/dependencies/x86_64/
  enabled=1
  gpgcheck=0

Tras ésto, ya están disponibles para la instalación los paquetes puppet de cliente y servidor. Sólo hay que proceder a su instalación con yum. En el servidor sería así,

shell> yum install puppet-server

Para el cliente,

shell> yum install puppet

A partir de aquí, el resto del funcionamiento será el típico de puppet, tanto para el servidor como el cliente.

Si este artículo te ha interesado, quizás te puedan interesar también:

• Móntate tu propio servidor puppet desde cero
• Instala puppet en sistemas Debian/ubuntu

Leer más

puppet: usando parámetros para mejorar legibilidad

puppet permite realizar configuraciones complejas basadas en parámetros, lo cual permite la posterior exportación de las configuraciones a otros sistemas y arquitecturas de una forma mucho más simple.

Escenificándolo, se podría crear una clase, params, sobre la cual se definirán los diversos valores que podrán coger las variable, en función de determinados parámetros, por ejemplo $operatingsystem.

class basico::params {
   $provider = $operatingsystem ? {
      /(ubuntu|debian)/ => "debian",
      default           => "init",
   }
   $atoppack = $operatingsystem ? {
      default           => "atop",
   }
}

Y luego sólo habría que incluir dicha subclase donde se desee usar y llamar a sus variables, que siempre tendrán un valor.

class basico::atop {
   require bascio::params

   package { "atop":
      name     => "${basico::params::atoppack}",
      ensure   => installed;
   }
}

En este ejemplo, el paquete atop está únicamente disponible para sistemas debian/ubuntu, en caso de que ahora aparezca un nuevo sistema redhat, en el que el paquete atop tiene otro nombre, atop.noarch, éste no se podría instalar desde puppet sin modificar la clase basico::atop con un case. Al tener la clase de params definida, únicamente habría que añadir un nuevo valor redhat para la variable $atoppack, tal como sigue,

class basico::params {
   $atoppack = $operatingsystem ? {
      redhat  => "atop.noarch",
      default => "atop",
   }
}

Aunque su utilidad pueda no parecer muy grande, realmente sí lo es, por que la toma de decisiones en función de casos está en un único fichero y no dentro del propio manifiesto, lo que asegura que no se altere el funcionamiento. Aunque en el caso presentado su utilidad puede no ser excesiva, el uso de una subclase para los parámetros es altamente recomendable.

Leer más

puppet manifest for zabbix-agent

A continuación, el manifiesto necesario para instalar el agente zabbix en todos los sistemas cliente que deseemos sin esfuerzo alguno desde puppet.

Primero, creamos la subclase de parámetros, por si es necesario alguna modificación, sólo tocar este fichero.

class zabbix::params {
   $agent_packagename = $operatingsystem ? {
      debian=> "zabbix-agent",
      ubuntu=> "zabbix-agent",
      default=> "zabbix",
   }

   $server_packagename = $operatingsystem ? {
      debian=> "zabbix-server-mysql",
      ubuntu=> "zabbix-server-mysql",
      default=> "zabbix-server",
   }

   $provider = $operatingsystem ? {
      debian=> "debian",
      ubuntu=> "debian",
      default=> "init",
   }

   $agent_servicename = $operatingsystem ? {
      debian=> "zabbix-agent",
      ubuntu=> "zabbix-agent",
      default=> "zabbix",
   }

   $server_servicename = $operatingsystem ? {
      debian=> "zabbix-server",
      ubuntu=> "zabbix-server",
      default=> "zabbix-server-mysql",
   }

   $agent_configfiled = $operatingsystem ? {
      default=> "/etc/zabbix/zabbix_agentd.conf",
   }

   $agent_configfile = $operatingsystem ? {
      default=> "/etc/zabbix/zabbix_agent.conf",
   }

   $server_configfiled = $operatingsystem ? {
      default=> "/etc/zabbix/zabbix_server.conf",
   }

   $agent_dir = $operatingsystem ? {
      default=> "/etc/zabbix",
   }
}

La clase zabbix.

Leer más

puppet manifest for git

Como se comentó en el último post sobre git, antes de comenzar a usarlo y crear repositorios, se muestra la clase que permite la configuración automática de git cuando un usuario se crea desde puppet.

class usuarios {
   define add_user($username, $git=false) {
      user { "$name":
         ensure        => present,
         membership    => inclusive,
         comment       => $username,
         home          => "/home/$name",
         provider      => useradd,
         shell         => "/bin/bash",
      }

      file { "/home/$name/":
         owner         => $name,
         group         => $operatingsystem ? {
            suse       => "users",
            default    => "$name",
         },
         mode          => 750,
         ensure        => directory;
      }
      if $key {
         file { "/home/$name/.gitconfig":
            owner      => $name,
            group      => $operatingsystem ? {
               suse    => "users",
               default => "$name",
            },
            mode       => 0600,
            require    => File["/home/$name"],
            content    => template("templates/gitconfig.erb");
         }
      }
   }
}

Leer más

puppet: creando grupos

Para crear o modificar un grupo del sistema desde puppet,

group {
   ssh:
      ensure => present,
      gid    => 55;
   usuariosremotos:
      ensure => present,
      gid    => 56;
}

Leer más

Puppet con entornos de trabajo

Ya tengo hablado sobre las ventajas de usar Puppet como herramienta de administración. Hace tiempo que estoy trabajando sobre una plataforma grande y necesita varios entornos y todo desde el mismo servidor Puppet. Instalar varios servidores para poder tener en cada uno un entorno diferente no sería viable, así que lo más lógico, como se presupone, que Puppet los maneje.

¿Cómo manejar diferentes entornos desde Puppet?

Un único servidor de Puppet es capaz de manjera varios entornos de desarrollo gracias a la variable environment del cliente. En el equipo cliente únicamente habrá que definir el entorno de trabajo sobre el que se desear estar y luego en el servidor tenerlos definidos, con sus módulos, sus templates, etc.

Para poder hacer habilitar los diferentes entornos de trabajo, simplemente tendremos que hacer unos pequeños cambios en nuestros equipos,

On master

[puppetmasterd]
        masterport = 8140
        storeconfigs = true
        environments = production,development

[production]
        manifestdir = /etc/puppet/manifests/production
        modulepath  = /etc/puppet/modules/production
        manifest    = /etc/puppet/manifests/production/site.pp

[development]
        manifestdir = /etc/puppet/manifests/development
        manifest = /etc/puppet/manifests/development/site.pp
        modulepath = /etc/puppet/modules/development

On client

[puppetd]
        server = puppet.mydomain.com
        reports = store,log
        report = true
        rrd = false
        environment = production
        reportserver = $server
        runinterval = 1800

Leer más

Memoria para el concurso de SL

Tras la finalización de mi PFC sobre Pupppet decidí sacarle un poco más de partido y me presenté al concurso de software libre con él. La idea no era ganarlo, ni de lejos, sino dar a conocer las ventajas que tiene el software de meta-administración y sobre todo en el ámbito universitario.

Os colgaré aquí la memoria que presenté para el concurso y que intenta resumir, en muy poco espacio, todo el trabajo que se ha realizado para el proyecto, pero que en realidad será el que evalúen. Puesto que considero que el objetivo no es el concurso, sino que la gente de sistemas pueda cambiar el chip y empezar a usar estas herramientas, pues entre otras muchas facilidades, está la de mantener las configuraciones de todos los equipos en el mismo estado. Y eso, para los administradores de sistemas es lo más importante.

Por cierto, si te animas a probarlo, deja un comentario :-)

Leer más

Puppet, herramienta de meta-administración

Aunque durante la andadura de este blog casi seguro que hablaremos de muchas más cosas, en este primer post inaugural, vamos a hablar sobre por qué emplear Puppet como herramienta de administración descentralizada.

Este post tiene el origen en que mi proyecto fin de carrera de la Ingeniería Informática opté por realizar un trabajo de investigación sobre herramientas de meta-administración, y entre ellas Puppet.

Aunque en el mercado y también como software libre existen más herramientas que hacen lo mismo, las ventajas que ofrece Puppet sobre las demás, decantaron la balanza a su favor. Así que en contraposición a herramientas más conocidas como rsync, cfengine o ZENwork, optaremos por emplear Puppet para que haga el trabajo por nosotros.

Puppet, entre otras ventajas presenta,

• Software libre
• Idempotencia
• Simplicidad y rapidez
• Ahorro de costes
• Evitar fallos repetitivos
• Lenguaje declarativo
• El qué vs el cómo
• Diferenciación en tres capas

A continuación se dejo el capítulo que hace referencia al análisis más exhaustivo que hice sobre esta herramienta de meta-administración, las ventajas y también sus desventajas.

Leer más