AWS OpsWorks (1) – Entorno de desarrollo y pruebas para Chef

Este artículo va en la línea de otros que tengo en el blog sobre la creación de entornos de desarrollo, y en este caso para Chef.

Chef es una plataforma de automatización de infraestructuras de TI: permite mediante recetas, definir la configuración de los nodos de una infraestructura (servidores, cortafuegos, routers…), es decir, definir: paquetes instalados, configuraciones, usuarios, etc. Lo que en muchas ocasiones se hace de forma manual, Chef permite hacerlo programáticamente.

AWS OpsWorks: recetas Chef

Al ser Amazon Web Services como es, todo virtual para el administrador de sistemas, lleva de forma natural a usar un sistema de este tipo para que la gestión de la infraestructura sea igual de escalable que el software que se despliega en ella. Amazon no puede pensar en la escalabilidad sólo para el software que sus clientes despliegan en su nube, y consciente del coste de gestión de las infraestructuras de TI, proporciona la posibilidad de usar recetas de Chef para crear dicha infraestructura. En Amazon han llamado al servicio OpsWorks.

En el artículo anterior explicaba el ciclo de vida de OpsWorks, donde cada paso supone la ejecución de recetas propias de AWS para crear una nueva instancia de un servidor virtual y dejarla en ejecución como último objetivo, pero donde el administrador de sistemas puede añadir recetas propias para completar la creación y configuración del nodo que está siendo creado en ese momento.

Volviendo al tema principal del artículo, el administrador en este caso necesita un entorno de desarrollo de las recetas Chef que usará en OpsWorks.

Entorno de desarrollo Chef

En primer lugar: ¿qué necesita un administrador de sistemas para poder desarrollar y probar recetas Chef [para OpsWorks]?

Después de buscar por Internet y de asistir a algún que otro hangout de OpsCode, la empresa que ha creado Chef, tengo clara la respuesta:

Una máquina virtual que corresponda con la máquina objetivo que se usará en AWS.
Vagrant como herramienta (interfaz de usuario) para para ejecutar la máquina virtual en el equipo del desarrollador.
Chef Solo o Chef (cliente-servidor).

Vagrant y máquina virtual

En el caso que pongo como ejemplo, que es al que me enfrenté yo con AWS, necesitamos preparar una máquina virtual Ubuntu 12.04 x64:

vagrant init precise64 http://files.vagrantup.com/precise64.box
vagrant up

Y después de la magia de Vagrant, y dependiendo del ancho de banda disponible para la descarga de la imagen de la máquina virtual, tenemos una máquina arrancada y totalmente funcional con Ubuntu 12.04 x64:

$ vagrant ssh
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
Welcome to your Vagrant-built virtual machine.
Last login: Sun Sep  8 10:39:31 2013 from 10.0.2.2
vagrant@precise64:~$

Chef Solo y configuración de la máquina

Además de otras funciones de Vagrant que no vienen al caso en este artículo (muy interesantes el port forwarding o las carpetas compartidas entre las máquinas host y guest), la que interesa para este artículo es la posibilidad de indicarle a Vagrant que configure la máquina usando recetas Chef.

Este proceso de configuración de la máquina virtual, llamado “provisioning” (abastecimiento en español), permite definir de forma exacta la configuración de la máquina, la instalación de paquetes, servicios, etc. De esta forma, en un sólo fichero de definición de la máquina virtual tenemos todo lo necesario para un fin determinado.

Usando Chef Solo, que no requiere un servidor central que gestione un grupo de nodos con Chef, podemos definir la forma de la máquina, por ejemplo, para instalar Apache2 con el módulo PHP activado y alguna configuración adicional de fábrica:

  config.vm.provision "chef_solo" do |chef|
    chef.add_recipe "apache2"
  end

  chef.json = {
    "apache" => {
      "listen_address" => "0.0.0.0",
      "contact" => "localhost@example.com",
      "default_modules" => [ "php5" ]
    }
  }

Entorno de pruebas con recetas propias: Vagrant + Chef Solo

Con todo lo anterior, disponemos de un entorno virtualizado donde en poco tiempo podemos tener una máquina “limpia” en la cual probar nuestras propias recetas de Chef Solo para después usarlas en OpsWorks. Siempre teniendo en cuenta lo siguiente:

La versión de Chef Solo que se usa en OpsWorks__: 0.9 y 11, siendo esta última la versión por defecto.
La versión de Chef Solo que se usa en Vagrant

vagrant@precise64:~$ chef-solo --version
Chef: 10.14.2

Las particularidades del entorno final de ejecución de las recetas (OpsWorks en una máquina virtual en AWS) como por ejemplo, el ciclo de vida de OpsWorks y las recetas propias de OpsWorks que se ejecutan siempre.

Y la forma es sencilla, un repositorio local en forma de carpeta anexa al fichero de configuración Vagrant de la máquina, donde disponer las recetas propias que se referencian desde él:

Vagrantfile

cookbooks
 - cookbook1
 - cookbook2
 - cookbook3

Esto permite:

Crear recetas Chef y probarlas en la máquina (forzar el aprovisionamiento, y es aquí donde se aprovecha la característica de idempotencia de Chef):

vagrant reload --provision

Limpiar la máquina y volver a probar las recetas sin la interferencia que supone la suciedad de las pruebas que se hayan podido hacer anteriormente:

vagrant destroy && vagrant up

Terminando

El objetivo de este artículo no era ni mucho menos servir de guía de programación de recetas Chef para OpsWorks, si no demostrar cómo siempre existe un entorno de desarrollo que permite maximizar el rendimiento del tiempo que empleamos en implementar una cierta tarea de programación. En este caso, el objetivo era mostrar como disponer de un entorno de desarrollo similar al entorno final de ejecución del código (recetas Chef en este caso), para poder realizar pruebas hasta obtener la implementación deseada.

Como nota sobre el entorno de desarrollo, existe un proyecto en versión beta actualmente que proporciona un plugin para Eclipse para la edición de recetas Chef: https://github.com/limepepper/chefclipse/

Javier Jerónimo