Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.
Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.
Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.
Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos.
Para lograr este objetivo no partiremos de cero, sino que usaremos dos recursos bien documentados previamente, el primero es mi serie de artículos sobre separar los procesos de Build de los de Despliegue (con Release Management) así que lo que haremos simplemente sera utilizar de un pipeline de Build ya existente (el cual evoluciono en su momento para soportar Análisis de Código Estático con SonarQube) y en vez que nuestro artefacto (un zip) se despliegue a una Web App (como lo teniamos hasta ahora) lo desplegaremos a nuestras Maquinas Virtuales; Ok, ¿y como provisiono y configuro las Maquinas Virtuales y las pongo en un balanceador de carga? Pues nos basaremos en el muy bien documentado post de John Bulla, el cual nos explica paso a paso como provisionar las maquinas virtuales en Azure, enrolarlas en el balanceador de carga, y efectuar las pruebas respectivas, pues eso… preparemos las maquinas como nos lo dice John y ahi estaremos listos para seguir con los siguientes pasos de configuración necesarios.
¡Nuestro balanceador funciona! ¿y ahora que hacemos con las maquinas?
Pues toca instalar .Net y el soporte ASP.Net, para lo cual iremos al tablero del Server Manager de nuestras MV, optamos por «Add roles and features», lo cual nos disparara un wizard que seguiremos según las imágenes:
En este punto debo comentar algo adicional respecto a la configuración de los equipos destino, tradicionalmente al trabajar con IIS siempre procuraba trabajar con usuarios locales, con los mínimos permisos posibles para realizar la tarea, obviamente por razones de seguridad, y esa era mi intención en este modo de despliegue, pero como luego pude corroborarlo con el soporte tecnico de Microsoft, si yo creo un usuario local en las maquinas destino este usuario debe de tener permisos de ¡administrador! con los riesgo que esto conlleva, por lo que queda claro que tendremos que aplicar otra alternativa a fin de garantizar la seguridad.
Ahora toca proceder a la preparación de los Deployment Groups en si, así como la instalación del agente en nuestras maquinas, para esto vamos a nuestro Proyecto en VSTS y dentro del menu «Build and release» veremos una opción «Deployment Groups», la cual seleccionaremos (Aprovechamos para ir conociendo la nueva UI «vertical» de VSTS).
Se nos ofrecerá una pantalla para poder administrar y crear nuestros Deployment Groups (en mi caso ya tengo algunos), así que escogeremos «New»:
Así que crearemos nuestro DG dándole un nombre y descripción.
Al hacer esto lo único que hemos hecho ha sido definir el contenedor lógico dentro del cual se agruparan nuestras maquinas, pero de momento VSTS esta totalmente ignorante sobre donde vamos a hacer el despliegue, así que apenas creamos nuestro DG se nos ofrecerá una pantalla desde donde copiar el script de registro, para lo cual nos bastara dar clic al botón «Copy script to the clipboard» pero antes de ello debemos asegurarnos de que el script que generemos es para Windows (también existe opción para Linux) y que tengamos seleccionada la casilla «Use a personal access token in the script for the authentication» esto nos simplificara el establecimiento de relaciones de confianza entre nuestras maquinas y los DG de VSTS.
Ahora teniendo en el portapapeles el script que copiamos de VSTS, vamos a nuestras maquinas virtuales abrimos una instancia administrativa de Powershell y ejecutamos el script, debemos tener en cuenta de que cuando se nos por la cuenta de usuario a utilizar debemos darle «Enter» para que se use la cuenta integrada AUTHORITY\SYSTEM.
Notese que no hemos agregado «tags», esta es una opción interesante para agrupar subconjuntos de servidores en un DG, pero de momento no los usaremos.
Una vez que el script ejecute sus tareas podremos ver que si vamos a la opción «Targets» en nuestro Deployment Group aparecen las maquinas que acabamos de enrolar, por lo que ya estamos listos para configurar el despliegue en si, pero eso lo cubriremos en el siguiente post.