Hace un par de meses al llegar a UK y aprovechando que Amazon tiene envío a domicilio gratuito para algunos libros, aproveché para pillar un par de libros: «Web Operations» y «Continous Delivery«. Con todo el lío no había tenido tiempo para empezarlos, pero se me ocurrió comentar un día en twitter la pena que me daba tenerlos ahí sin leer cuando @trek1s me recomendó que leyera cuanto antes el de Web operations porque le había gustado bastante, así que me puse a la tarea y lo llevo bastante avanzado (prometo poner una reseña en el blog porque la verdad el libro la amerita).
En uno de los capítulos dedicado a la infraestructura como código nos cuenta cómo el reconstruir todos los servicios de una empresa ante una catástrofe debería ser tan sencillo como provisionar infraestructura en un proveedor de cloud no afectado por la catástrofe, aplicar sobre ella nuestra herramienta de gestión de la configuración para configurar todo lo necesario y rescatar del backup, aquel que estaba offsite y no fue afectado por la catástrofe, la versión más actualizada para los datos. Y si uno lo piensa bien, el tema debería ser así y nuestros esfuerzos como sysadmins deben de estar dirigidos en gran parte a objetivos tan loables cómo salvar a la empresa de la quiebra ante una catástrofe.
Cuando empezamos a implementar la plataforma de salud de Andago, uno de los primeros objetivos que me marqué y que hace tiempo llevaba intentando poner en práctica fue el de tener una buena política de la gestión de la configuración y del despliegue de las aplicaciones. En algunos de los proyectos internos ya se llevaba tiempo trabajando en esto pero normalmente en los proyectos y servicios de cliente no se había podido avanzar tanto como se debería, así que como siempre decimos una oportunidad para empezar de cero es una oportunidad para no volver a cometer los mismos errores.
Una vez definida la política, siempre sujeta a cambios y mejoras, nos pusimos a implementarla. Abriendo nuestro maletín de herramientas devops (marca Acme) decidimos utilizar subversion, puppet y los servicios de Amazon EC2. No voy a ahondar en cómo fue la implementación pero un punto que sí me ha resultado muy interesante ha sido el cambio en el modo de trabajar que hemos tenido que sufrir como equipo. Hace tiempo que venimos practicando Scrum como metodología ágil para los proyectos nuevos a desarrollar pero esta vez le sumamos el cambio que supone trabajar con la infraestructura como código. El trabajo habitual de un proyecto en la parte de configurar servicios en Linux suele ser de trastear mucho en la consola e ir documentando en nuestro wiki de referencia. En este caso el tema cambió y nos dedicamos a escribir el código de Puppet que se encargaría luego de hacer la configuración y además, con unos buenos comentarios, cubre una parte importante de la documentación del servicio.
Por otro lado sumamos que estamos trabajando de forma distribuida tanto en ubicaciones como en horarios, yo desde Reino Unido y luego equipos en España y Panama, el reto era bastante interesante. Lo bueno es que en lugar de estar toqueteando cada uno servidores en remoto lo que estabamos produciendo es código que se iba almacenando en nuestro subversion y que luego puede ser testeado, aplicado y pulido múltiples veces hasta llegar al punto deseado. A través de rsync empujábamos el código a instancias de Amazon y comprobando que todo funcionaba bien. Curiosas las sesiones de despliegue en la que todos en remoto estábamos conectados por ssh al mismo screen y viendo cómo desplegaba nuestra criatura mientras comentábamos la jugada por skype.
El siguiente reto será ir por la integración continua y las pruebas automáticas, es decir todas aquellas cosas que siempre les estamos pidiendo a los desarrolladores pero que luego nosotros no estábamos aplicando a nuestro trabajo.
Por ahora no hemos sufrido ninguna catástrofe para comprobar lo narrado por el libro pero sí hubo un punto de prueba muy interesante. El equipo de negocio decidió que, debido a que nuestro público objetivo en gran medida estaría en Estados Unidos, el despliegue que inicialmente se había realizado en la zona de Irlanda habría que migrarlo a la zona de la costa este de gringolandia. Ciertamente aún no estábamos en producción y seguíamos en las fases tempranas del proyecto y eso facilita las cosas, pero la transición fue bastante parecido a lo descrito al inicio lo cuál no hace más que reafirmar que vamos avanzando por el camino correcto.