Después de varias pruebas con Puppet, ir a la Puppet Camp, reuniones de la puppet-users-barcelona y la ayuda de la fabulosa gente del puppet-users-barcelona (https://groups.google.com/forum/?hl=en&fromgroups=#!forum/puppet-users-barcelona). Hemos creado esta pequeña introducción de una de las posibilidades de utilizar Puppet en Amazon EC2. Aunque Amazon hace poco lanzó el producto OpsWorks (https://aws.amazon.com/opsworks/) basado en Chef (http://finance.yahoo.com/news/amazon-services-chooses-opscode-chef-181000793.html). Por ahora, nosotros preferimos utilizar Puppet antes que Chef, porqué hay mucha documentación, mucha más comunidad y nos gusta más. Y por el momento vemos muchos más casos de éxitos de empresas importantes con Puppet que con Chef. Ejemplo de Pinterest, Wuaki.tv, Zynga, etc.
Recomendamos leer alguna Introducción de como funciona Puppet antes de leer este POST. En Google se pueden encontrar muchos (http://www.ant30.es/2011/11/puppet-gestion-de-configuracion-centralizada/)
Escenario 1: Puppet Master como nodo central.
Recordad que Puppet se presenta en dos partes: un servidor (el Puppetmaster), que recibe las conexiones de los clientes y contiene los manifests, módulos, plantillas, archivos, etc. Y luego un programa cliente que se ejecuta en cada máquina bajo control de Puppet y que se conecta mediante intercambio de certificados al PuppetMaster para conseguir su manifests.
Paquetes a instalar:
Si queremos trabajar con un PuppetMaster y nodos de puppet conectándose al Puppet Master. Primero debemos instalar mediante nuestro sistema de paquetería de nuestro Sistema Operativo los paquetes “puppet” y “puppet-master” en la máquina elegida como servidor. Luego instalamos en cada nodo cliente el paquete “puppet”.
En el servidor:
En el cliente:
# apt-get install puppetResolución de nombres:
Una vez instalados los paquetes, tendremos que hacer una sencilla configuración de Puppet. Aunque antes tendremos que forzar a todas las máquinas que el nodo llamado “puppet” apunte a la IP del puppetmaster. Por eso lo podemos hacer mediante DNS y sinó podemos porqué nosotros no controlamos el DNS, lo podemos hacer modificando el fichero “/etc/hosts” de cada máquina que contenga Puppet.
Para eso editamos el “/etc/hosts” de todas nuestras máquinas. Si por ejemplo el puppet master tiene la IP 192.168.1.20 la cosa quedaría de la siguiente forma:
127.0.0.1 localhost 127.0.1.1 machine # The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters 192.168.1.20 puppet
Si estuviésemos dentro del Puppetmaster lanzado el siguiente comando ya bastaría:
# echo `ifconfig eth0|grep addr|head -n 2|tail -n 1 |cut -d “:” -f 2 | cut -d ” ” -f 1` “puppet” >> /etc/hostsConfiguración:
Luego necesitamos editar 2 ficheros.
/etc/puppet/puppet.conf (en teoría ya viene por defecto configurado correctamente)
Miramos si existe el fichero /etc/puppet/autosign.conf, si no existe lo creamos.
Dentro del fichero /etc/puppet/autosign.conf solo hace falta que contenga una “*” que significa que toda petición de un nodo cliente que se conecte se autofirme para ahorrarnos hacerlo manualmente. Esto tiene inconvenientes de seguridad porqué todo nodo con visibilidad al PuppetMaster se podria connectar al él. Por lo tanto tendríamos que proteger la red de nodos no deseados (cerrando los puertos de Puppet). Con Security Groups de Amazon se puede solucionar o con un IP tables o con otros métodos. También podriamos configurar el PuppetMaster para firmar solo un cierto rango de IPs o ciertas máquinas que contengan estén en un subdominio de DNS. Aquí os recomendamos que busquéis en la documentación oficial de Puppet.
En este caso, el autosign.conf queda así:
Conexión de clientes:
Si acabamos de preparar el servidor Puppetmaster y queremos conectar un nodo cliente de puppet. Antes se tiene que pasar los certificados con el comando y con el mismo comando se lanza también el Puppet.
# puppet agent -tSi solo quisiesemos lanzar el nodo las veces que nosotros quisiesemos, por ejemplo al arrancar la máquina, y no mediante el demonio de Puppet. Tendríamos que apagar el demonio de Puppet y lanzar el siguiente comando:
# /usr/sbin/puppetd -t –onetime –no-daemonize (para arrancar una sola vez el Puppet y no dejarlo abierto funcionando cada 30 minutos)También tenemos la forma de probar nuevas modificaciones de Puppet sin aplicar cambios mediante el siguiente comando. Es decir para poder debugar antes.
# puppet agent -t -noop En el Puppetmaster para comprobar que esté todo bien, en el servidor podemos listar los nodos firmados y conectados usando el comando:# puppet cert –list –all
En el caso que no tuviesemos puesto el método comentado anteriormente para firmar automáticamente, podemos firmar manualmente los nuevos nodos de puppet a conectarse al Puppetmaster, mediante el siguiente comando:
En el Pupetmaster podemos revocar el certificado del nodo:
# puppet cert –revoke nodo1.example.comPara limpiar el nodo.
# puppet cert –clean nodo1.example.comO para limpiar todos los nodos.
# puppet cert –clean –allVarias cosas a tener en cuenta.
– Este es un ejemplo de muchas posibles. Hay otras opciones de autoregistrar las máquinas en un DNS como el AWS Route 53.
– Si encontráis algún error o que falta algo o que nos hayamos dejado algo. O conoceis otras formas de trabajar con EC2, no dudéis en comentarlo en el grupo de CloudAdmins de LinkedIn.
– Cuando reiniciamos las máquinas virtuales de Amazon, o creamos una AMI, podemos perder el hostname correcto de la máquina. Por lo tanto, nosotros solemos poner en el rc.local , lo siguiente para que la máquina se encienda con el hostname adecuado.
Escenario 2 : Sin nodo central Puppet Master. Todo en una sola máquina.
Mirar que fácil y que sencillo es con este método que utilizábamos en nuestros primeros tests.
Primero mediante “apt-get”, yum o equivalente instalamos el: git y puppetmaster.
# apt-get install puppetmaster git
Nos bajamos el código con nuestros manifests de Puppet. Por ejemplo con Git (también podriamos utilizar SVN, wget o lo que nos gusté más). En nuestro ejemplo:
Y luego lanzamos el puppet mediante:
# puppet agent -d /code/manifests/site.confDe esta forma la máquina hace de Puppetmaster y a la vez de cliente Puppet. Sin falta de firmar certificados y configuraciones complicadas. Lástima que aquí perdemos potencialidad de la que nos ofrece Puppet (guardar storeconfigs, los facters, etc.)
Estas 2 líneas las podríamos poner en nuestro “rc.local” del sistema operativo para que cada vez que arranque la máquina de Amazon EC2 se puppetize el entorno.
En este artículo queríamos dar las gracias a la gente de puppet-users-barcelona ( https://groups.google.com/forum/?hl=en&fromgroups=#!forum/puppet-users-barcelona ) por su ayuda, por la fabulosa PuppetCamp que organizaron y por las reuniones mensuales que hacen. Desde aquí os comentamos que es muy recomendado ir .
Referencias interesantes:
http://www.slideshare.net/roml/puppetcamp-15934250
http://kentbye.com/post/32415279029/how-pinterest-uses-amazon-ec2s-auto-scaling-features
http://www.slideshare.net/markstanislav/being-a-puppet-master-automating-amazon-ec2-with-puppet-friends
