No sé si os lo he comentado ya varias veces pero me encanta la nueva mentalidad alrededor de las tendencias Devops y las Operaciones Web ágiles. Creo que es un cambio de mentalidad necesario y un gran avance para nuestra profesión pero que implica cambios a todos los niveles. Ya llevaba tiempo pensando en escribir sobre el tema ya que los recursos en inglés sobre el mismo son inagotables, pero creo que no hay tanto en español, así que os voy a dejar un batiburrillo de reflexiones que últimamente me dan vueltas en la cabeza.
El otro día estuve en el London Puppet User Group meeting y disfruté bastante de las charlas especialmente la segunda en la que mostraron un enfoque diferente en la definición de recursos orientado a provisionar varios servidores a través de Open Nebula y dejarlos configurados y operativos, todo ello a través de Puppet. Pena que todavía no he tenido la suerte de poder acercarme a London Devops y me alegro infinito de que Madrid Devops siga viento en popa, desde aquí mis felicitaciones a Mari Carmen por el empeño que está poniendo y a todos los que os acercáis a compartir por ese foro, ¿se nota que os echo de menos? 😀
Una de las primeras cosas que me vinieron a la cabeza es que no estoy seguro de si la orientación que está tomando la gente de Puppet Labs va muy en la línea de lo que yo busco en su producto. Por un lado, mantener dos desarrollos separados para la edición Enterprise y la edición Comunidad y por otro, el enfoque hacia grandes corporaciones y hacia la incorporación de elementos cómo gestión de CMDB, Workflows, etc para mí rompe un poco con la mentalidad Unix: pequeñas herramientas que hacen muy bien su trabajo y que en conjunto te dan una gran flexibilidad. Personalmente me gustaria que se trabajara más en la parte de orquestación y en romper el enfoque nodista, decidir el estado de mis nodos, por uno mucho más orientado a conjunto o a servicio.
Me encanta mcollective, creo que es una herramienta muy potente, pero no dejo de verla cómo un loop ssh para ejecutar un comando en el resultado de la busqueda de nodos que cumplen ciertas características y no lo termino de enlazar con una orquestación más basada en estados cómo es puppet sino en acciones.
Por cierto, si tenéis tiempo libre y os interesa el tema de Puppet os recomiendo que le echéis un vistazo a los videos de la pasada Puppet Conf y también a este repositorio Git que ha compartido la gente de Wikimedia con los manifiestos que ellos están usando para gestionar su infraestructura.
Otra reflexión sobre puppet, antes de pasar a otro tema, me vino del descubrimiento que en las plantillas para ficheros tipo erb podía utilizar todo el código Ruby que quisiera y esto solucionó algunos de los problemas que me estaban rondando últimamente para definir algunas plantillas algo complejas. Desde entonces un run-run en mi cabeza no para de decirme si aplicando el mismo concepto no sería mucho más potente el uso de Chef que utiliza una sintaxis más amplia y te permite utilizar el juego completo de instrucciones de ruby en tus manifiestos. Hace tiempo que no pruebo Chef, pero comentando esto con gente de la conferencia me comentaban que la orientación de Chef no cambia únicamente en eso sino que también hay que tener en cuenta que al contrario que Puppet, la ejecución de la configuración en Chef en varias ocasiones consecutivas sobre el mismo entorno en el mismo estado podría no dar lugar a los mismos efectos. Aquí me vendría bien ayuda de gente que se haya pegado más con los dos sistemas, ¿cómo véis el estado del arte los Chefistas y los Puppeteros?
Y de paso aprovecho también para volcar a texto otra de mis inquietudes de los últimos meses. Hace ya tiempo que quiero ampliar mis habilidades aprendiendo y cogiendo práctica con un lenguaje de scripting que me ayude a ser más eficiente y amplie mis posibilidades. Al principio python parecía el camino adecuado, pero cada día que pasa siento que hay más y más herramientas de administración escritas en ruby, con lo que me crece la duda, por ahora sigo poco a poco la senda de python y ya sé que la respuesta a la pregunta es: aprende los dos, pero cómo el tiempo es limitado habrá que dividir los esfuerzos o priorizarlos, ¿cómo lo véis?
Una parte de la charlas posteriores entre cervezas y pizza que me encantó era lo que comentaba uno de los asistentes: «Yo no quiero a los desarrolladores anden tocando en mis servidores», pero estuve pensando y creo que no sólo es la idea correcta sino que habría que ampliarla «No quiero a nadie rondando en mis servidores, ya sean de los equipos de desarrollo u operaciones y menos aún alguien de fuera», si hay que hacer retoques en los entornos de producción estos deberían hacerse siempre desde las herramientas de gestión de configuración y cambios de tus entornos y a través de unos workflows definidos y probados ampliamente, nunca tener que realizar acciones directas sobre las máquinas. Otro de los comentarios fue que «los equipos de desarrollo quieren estar modificando continuamente lo subido y a veces van demasiado rápido», y creo que aquí está otro de los puntos clave del cambio que estamos intentando llevar a cabo con mentalidades ágiles y devops: nuestro objetivo debe ser el de habilitar el cambio y potenciarlo, eso sí poniendo los mecanismos necesarios para asegurar el éxito: integración continua, desarrollo guiado por pruebas, automatización del despliegue, paso rápido entre entornos de pre y pro o despliegue continuo son los habilitadores para ello y tenemos que encontrar la mejor manera de integrarlos en nuestros ciclos para ganar en agilidad.
Y en el terreno herramientas, no puedo dejar de comentar una de mis favoritas en los últimos días es Vagrant, si no la habéis probado no tardéis mucho en hacerlo. Hace tiempo que estaba buscando un sistema que me permitiera gestionar facilmente máquinas virtuales en mi portátil de forma que si necesito probar algo en una Debian, Redhat o lo que sea pueda levantarla rapidamente tener un entorno configurado rápidamente y hacer la prueba y destruir la máquina. Para ello Vagrant es ideal, es un conjunto de scripts en Ruby, elo aquí de nuevo, que usan Virtualbox por debajo normalmente en modo no gráfico y que te permite levantar una serie de plantillas de máquinas virtuales (os recomiendo vagrantbox.es para descargarlas), además tiene integración con puppet y chef de forma que puedes indicarle que ejecute un manifiesto al arrancar y que te deje el entorno ya configurado según unos parámetros. Impresionantes las posibilidades también para los equipos de desarrollo a los que se puede pasar un entorno similar al de producción y ellos pueden ejecutarlo en sus máquinas para desarrollar, hacer pruebas, etc… Vamos, no hay día que no me levante al ritmo de un comandazo «vagrant up»!
Por último voy a dejar a continuación tres juegos de transparencias que me han gustado bastante en los últimos días y que creo que son bastante explicativas de todo esto al rededor del movimiento Devops:
Y lo más importante, si has llegado hasta aquí por favor deja tu comentario en la entrada para que generemos algo de debate al rededor del tema. Muchas gracias a todos. 😀