Bienvenidos al episodio 14 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 2 de mayo de 2017.

Han pasado algunas semanas sin un episodio de deployando.me. Una de esas semanas trabajé en Buenos Aires y tuve la oportunidad acudir a una meetup de la comunidad Sysarmy, que nuclea a profesionales en el área de sistemas de la República Argentina. En ese meetup tuve el gusto de compartir mis avances en la investigación de Origin-Openshift con los presentes.

Sysarmy tiene un podcast llamado “Polémica en el /var” con noticias de nuestro campo. También son los organizadores NERDEAR.LA un evento que este año será de tres días por mediados de año. Recomiendo a todos los escuchas si está en sus posibilidades participar ya sea concurriendo o remotamente.

En las dos ultimas ediciones hablamos de vagrant

Vagrant nos permite configurar un flujo de trabajo fácil de usar, con foco en la automatización para hacer un despliegue y gestión rápida de entornos de desarrollo o producción.

En la edición 13 abordamos las boxes, que son las imagen que utiliza vagrant para levantar la máquina virtual cuando se ejecuta el comando vagrant up.

En esta edición quiero focalizar el análisis del flujo de trabajo diario, en el workflow y aprovechar comentar algunos usos que hago de vagrant.

Entonces ¿cómo iniciamos nuestro día?

Un Desarrollador puede comenzar su día haciendo un clon de un repositorio con la última versión del archivo Vagrantfile y a partir de ahi ejecutar `vagrant up` para levantar todo su entorno de trabajo para hacer el desarrollo de su aplicación en su propia máquina, con la ventaja de su propio editor, navegador y otras herramientas.

El desarrollador no tiene por que saber de vagrant o de cómo su aplicación está corriendo, pues vagrant es el medio sobre el que crea un entorno consistente, reproducible y estable para su trabajo.

Si somos administradores de sistemas nuestros desarrollos serán scripts, plantillas de automatización, configuraciones de seguridad; y necesitamos probar esos componentes.

Entonces también con `vagrant up` podemos levantar entornos que serán sandbox completos donde probar esos scripts y configuraciones, de forma de poder reproducir escenarios lo más parecidos a producción posible.

¿y qué pasa si algo queda mal, si algo falla?

Simplemente se comienza de nuevo. Con `vagrant destroy` podemos remover todos los rastros de lo que no funcionó y luego nuevamente `vagrant up` para volver a levantar desde cero un entorno fresco y, eventualmente, con las correcciones necesarias.

¿y cuando finalice nuestra jornada o debamos cambiar de tarea o proyecto?

Vagrant permite suspender o apagar entorno para continuar en otro momento o al día siguiente. Pero, si hicimos ‘push’ al repositorio de nuestros archivos también podemos ejecutar `vagrant destroy` y borrar todos los archivos de nuestro disco local, para volver a clonar cuando retomemos esta tarea y volvamos a levantar todo con `vagrant up`

Y ahora podemos tender a trabajar en nuestras propias máquinas y ya no estaremos precisando de permisos o terceros para hacer pruebas o mantener ambientes de experimentación.

Este flujo de trabajo, junto a la continua mejora y ajuste de los entornos que vamos armando en el Vagrantfile permite, no solo compartir el trabajo entre varios, sino que los diferentes proyectos compartan mejoras y que esas mejoras estén en todos los ambientes lo que nos lleva a que el famoso bug de “en mi máquina funciona” tienda a desaparecer.

¿y cómo utilizo personalmente vagrant?

En ambientes educativos utilizo vagrant para dar a mis alumnos el ambiente de trabajo que les permita probar las funcionalidad de los temas que abordamos en las lecciones. Pero también lo utilizo para que mis alumnos construyan entornos y me entreguen sus ejercicios en entornos automatizados.

He notado que resulta un recurso muy valioso en los procesos de aprendizaje tener que describir mediante automatismo lo que se ha construido siguiendo, por ejemplo un tutorial o mi guía de clase.

En mi trabajo profesional diario vagrant me ha permitido colaborar estrechamente con los programadores, levantar las aplicaciones siempre en forma idéntica, colocar ajustes de seguridad una única vez y que esos ajustes se promuevan en cada uno de los ambientes hasta producción.

Pero también me ha permitido mejorar las instalaciones de producción y que esas mejoras lleguen a los desarrolladores la próxima vez que clones el entorno y lo levanten con `vagrant up`.

La versatilidad de vagrant para utilizar tanto hipervisores locales para las máquinas virtuales como servicios de cloud públicas me ha permitido llevar esta simetría entre producción y desarrollo también a ambientes mixtos, donde el desarrollador sigue trabajando en su máquina local, pero el ambiente de producción está levantado en instancias de Amazon, por ejemplo.

Por todo esto fue que en el capítulo 12, les decía que vagrant “se trata de un software que ha cambiado mi forma diaria de trabajar, que me ha ayudado a razonar problemas de una forma distinta, que lo ejecuto todo los días y mi actividad depende mucho de él”, pues justamente sigo ese workflow de trabajo que vagrant nos propone.

En la próxima edición voy a continuar comentando las funcionalidad de vagrant en relación a la red y los disco, y abordaré el tema de ‘aprovisionamiento’, es decir, todo lo que hacemos luego de tener una maquina recién prendida y con el sistema instalado para llevarla a un nivel de producción.

Si has seguido este podcast y has ingresado a nuestro blog en deployando.me sabes que siempre publico una transcripción completa del podcast.

Pero además también suelo agregar enlaces y referencias, que permiten seguir profundizando en el tema de cada episodio.

Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me

Hasta la próxima edición.