Pues si, retomando los contenidos técnicos y en este caso haciendo seguimiento a las novedades del ultimo Connect, nos topamos con estas (entre otras) que afectan a nuestra herramienta favorita (claro que estoy hablando de Visual Studio Team Services, VSTS):
- Versionado de tareas (Build Task), esto esta interesante, ahora podremos “congelar” la versión de las tareas a fin de no ser afectados por los cambios que Microsoft haga sobre nuestras dependencias en VSTS, estando en nuestras manos el luego actualizar a la versión mas actual.
- Crear Builds y Release desde Azure (Portal), algo para simplificar las tareas DevOps , si has visto los articulos publicados veras que tradicionalmente hemos creado nuestras Web Apps desde el portal Azure para luego ir a VSTS a fin de enlazarlo y definir nuestro flujo de Construcción y Despliegue, ahora lo que se nos ofrece es empezar a construir nuestro flujo desde el entorno del Portal de Azure, siendo que luego también estará definido en VSTS, sera motivo de darle un vistazo.
- Agentes en Linux (Preview), este si es el bombazo, pues tradicionalmente los agentes de compilación que VSTS instancia cada vez que lanzamos un proceso de Integración Continua son Maquinas Virtuales Windows, ahora tenemos la posibilidad de que estos agentes sean generados de manera “elastica” ya sea en Windows o en Linux según el requerimiento de nuestro proceso de Build o de Release, lo cual cambiara radicalmente nuestra forma de trabajo con Docker y otras tecnologías como explicare a continuación.
Como sabrán hace unos meses empece a hacer mis experimentos de despliegue de una aplicación .Net (Core) dentro de Docker, lo cual pude realizar satisfactoriamente luego de mucho esfuerzo, que me llevo a establecer los siguientes pasos:
- Crear nuestra cuenta en Docker Cloud para ir alojando las versiones de las imagenes que vayamos generando (solo es necesario una vez)
- Preparación del proyecto Web .Net Core en Visual Studio
- Agregar el proyecto a un repositorio (VSTS o GitHub)
- Configuración de los archivos de Docker
- Prueba en Docker para Windows (opcional)
- Enlazar nuestra cuenta en Docker Cloud a VSTS
- Configuración de un Agente Privado Linux (lo cual incluye, provisionar la MV y enlazarla a VSTS) (*)
- Configuración de una MV (Docker Host) que aloje nuestros contenedores Docker (podemos usar la MV del paso anterior, pero puede ser confuso, así que cuidado)
- Enlazar nuestro Docker Host a VSTS, a fin de que los procesos la reconozcan como “destino” de nuestros despliegues
- Crear nuestra Build, lo cual incluye pasos como preparar .Net Core en nuestro Agente Privado, compilar nuestro proyecto y empaquetarlo para subirlo a Docker Cloud
- Crear nuestra Release, lo que implica coger la imagen subida a Docker Cloud y ejecutarla en el contexto de nuestro Docker Host (opcionalmente podemos detener y borrar las instancias corriendo en este momento)
- Configurar nginx como proxy inverso, porque nuestras aplicaciones web se ejecutan bajo el runtime de .Net Core, que a diferencia de IIS no expone las aplicaciones al “mundo exterior”
- Y como siempre… hacer nuestros commit en el codigo fuente y disparar el proceso de despliegue
El punto que viene a cambiar es lo de la necesidad de crear un Agente Privado Linux, para hacerlo tuve que usar esta detallada guía de Donovan Brown, que como resultado final nos otorga un Agente Privado ya enlazado a nuestra instancia de VSTS, con todo el soporte para Docker y .Net Core requerido para empezar a trabajar, lo cual me permitió tener un mayor conocimiento de la plataforma y poder hacer la difusión respectiva en dos eventos hace unas semanas.
El detalle es que mi idea de trabajar con VSTS es hacer uso de las tecnologías proveídas “out of the box” por la plataforma en la medida que sea posible, y recurrir a los Agentes Privados si y solo si no hubiera otra alternativa (como por ejemplo si quisiéramos compilar proyectos de VB6), por lo que el escenario de depender de MV personalizadas para realizar Builds con tecnologías Linux se viene a reducir de manera radical, en ese sentido toca ahora investigar como utilizar los agentes “elasticos” Linux desde VSTS para hacer nuestros despliegues Docker, lo cual al final de cuentas nos ayudara a no tener todo en una sola maquina, que si… podria haber configurado dos MV, una como Agente y otra como Docker Host, pero… eso cuesta.
Asi pues se vienen nuevas investigaciones en este sentido, ¡nos vemos!