Aprendamos Azure Pipelines (con videos)

Curiosamente una vez que esto de la cuarentena se hizo que las comunidades se adaptaran y empezaran a proponer eventos online, así en Agile Perú organizamos, junto al a comunidad Agile Uy, el meetup “Retros remotas desde las trincheras”   que cubrio temas muy interesantes de como enfocar nuestras retros cuando los equipos no estan juntos, situación que durara por un buen tiempo, y que creo que cubrio varias de las dudas que mencione en mi post anterior, si no han visto el video, haganlo, Camila se lucio en este meetup.

Y por el lado de las comunidades Microsoft, las cosas han estado muy activas, tan asi que el 25 de abril participe en dos eventos el Virtual Azure Community Day, organizado por el Microsoft Users Group Perú, y en el Global Azure Latinoamerica, organizado la Comunidad Xamarin en Español; en el primer caso hable sobre “Despliegue de Aplicaciones Serverless con Azure Pipelines y Azure Functions“, para luego exponer “Mejora la seguridad de tus despliegues con Environments en Azure Pipelines“, la verdad es que estaba nervioso, la expectativa sobre los eventos era alta, pero felizmente todo salio bien y además hubo algo que aprovechar….

Resulta que en mi sesión sobre Environments (tema del que ya he comentado en este blog) se me pregunto por la disponibilidad del YAML que use para mi demo, y luego me recomendaron hacer un paso a paso de como crear un multi-stage pipeline, como un paso previo a los conceptos de seguridad que explicaba sobre Environments, así que prepare este video sobre como crear tu primer multi-stage pipeline en Azure Pipelines:

Y como es lógico también comparto el YAML usado en esta demo, la cual es efectivamente una preparación para ver lo explicado en la sesión sobre seguridad y Environments:

Y ya como bonus track les dejo mi presentación sobre serverless y Azure Functions.

Espero que les sea de utilidad!! Ya en breve estaremos hablando de las novedades que se trae el Build!

Serverless: Realidad y perspectivas (y 3)

Bueno, llegamos al final de esta serie de reflexiones sobre Serverless en el contexto actual, y empezamos dejando algo claro:

Serverless no es solo Functions as a Service.

Y ¿eso por qué? Porque si bien la referencia  a Serverless nos hace pensar en Azure Functions o AWS Lambda, debemos valorar el concepto de manera adecuada, asi que de manera preliminar digamos que Serverless es un servicio cloud en el cual no tenemos “conciencia” de cual es el servidor o servidores que nos proveen la funcionalidad deseada (lo cual no quita que podamos tener una URL referencial, ojo).

En ese sentido, pues si, un Event Hub, un Service Bus, un gestor de APIs o servicios DNS calzan dentro de la definición de Serverless, de hecho en un pasado Microsoft Ignite, el orador decía que el servicio Serverless mas usado era … Azure Storage, y claro tiene sentido bajo la premisa inicial que hemos hecho ¿no?.

Ok, la definición puede ser laxa y por eso a veces me veo el lios para establecer una definición, así que para el resto del articulo hablaremos de Serverless en tanto servicios de computo en el que podemos ejecutar el código de nuestras aplicaciones abstrayendonos totalmente de los servidores (fisicos o virtuales) que dan soporte a la operación, razón por la cual cabria considerar como tales a las Logic Apps pero no a nuestras viejas cómplices las Web Apps (y mucho menos Elastic Beanstalk de AWS). Finish Reading: Serverless: Realidad y perspectivas (y 3)

Serverless: Realidad y perspectivas (2)

Bueno continuando con esta revisión respecto a la plataforma Serverless, veamos algunas consideraciones para entornos de trabajo y como enfocarlo de la mejor manera.

Para empezar debemos recordar que nuestras aplicaciones, por lo general, viven en un contexto, teniendo interacciones con otros sistemas, fuentes y consumidores de datos, sistemas externos, etc, los cuales al momento actual en su mayoría se encuentran en entornos on premise, lo cual nos lleva al reto de como hacer que nuestras aplicaciones en la nube se integren con los componentes on premise. Si nuestro ecosistema nació íntegramente en la nube (sin que eso implique ser cloud native) no es que no haya retos, pero son diferentes y a ellos nos enfocaremos en otro momento.

Lejanos son los tiempos en que las organizaciones podían tener todo un conjunto de direcciones IPV4 publicas a todos los equipos de sus organización (si, yo viví esa época en tres de mis primeros trabajos), ahora la escasez de direcciones IPv4 como las necesidades de asegurar los recursos frente a ataques e intrusiones, nos ha llevado de manera natural a un escenario en que los recursos criticos de computo de nuestras organizaciones hagan uso de direcciones IPv4 privadas, y claro, con segmentos de red dedicados y protegidos detrás de un firewall, dándose “confianza” de acceso solo a equipos dentro de la red propia de la organización (la excepción, claro, se da cuando es necesario exponer servicios al publico o a agentes externos).

Entonces cuando se aborda el crecimiento hacia la nube, un paso natural y conveniente es tratar (con las limitaciones de ancho de banda) de considerar a la nube como una continuación de nuestras redes privadas, para lo cual se habilitan VPNs, enlaces dedicados, nuevas reglas de firewall, se asignan segmentos de red (en el caso de Azure se denominan VNETs y en AWS VPCs), pero… Finish Reading: Serverless: Realidad y perspectivas (2)

Serverless: Realidad y perspectivas (1)

Aquí de vuelta al ruedo con el nuevo año, en este tiempo de ausencia desde el Microsoft Ignite, le he prestado atención a un tema muy apasionante cuyo uso e interes ha ido creciendo en los últimos años: computación serverless, así que visto el estado actual repasaremos donde estamos y hacia donde podemos ir mediante el uso de esta tecnología, especialmente con las mejoras introducidas en Azure.

A estas alturas se han dado muchas definiciones sobre lo que implican los componentes serverless, pero es mejor basarnos en lo que debería componer usualmente una arquitectura/componente serverless:

  1. Abstracción sobre los servidores utilizados. Que si, al final todo proceso computacional requiere tener hardware (servidores) por detrás, pero la diferencia es que tanto nos abstraemos sobre ellos, no que no existan; nuestras queridas amigas las Web Apps ofrecen un buen nivel de abstracción (ya no tenemos que tunear el Sistema Operativo, por ejemplo), pero con serverless damos un paso mas allá, esencialmente lo que nos importa es tener donde ejecutar nuestras porciones de código.
  2. Basado en eventos. Este tal vez sea uno de los componentes mas difícil de entender, pues para lograr efectos similares, a lo que estábamos acostumbrados es a tener procesos que cada x porción de tiempo validaban si una condición se había efectuado o no, para con ello invocar la ejecución de una acción o programa. Con este modelo basicamente vinculamos una acción sobre un recurso (una escritura de archivos, una petición HTTP, la escritura sobre una cola, un timer, etc) con un programa, y listo, sera la propia infraestructura cloud la que se haga cargo de invocar nuestro programa cuando la condición se cumpla.
  3. Escalamiento inmediato. Esto es mas sencillo de entender, si tienes muchas peticiones o uso de computo sobre tu aplicación serverless, el sistema debe ser capaz de agregar las instancias necesarias para cumplir la demanda requerida, y claro reducirla cuando el pico termine.
  4. Pago por uso. Bueno, eso es lo que se tiene mas claro cuando se trata de nube, en este caso significa solo pagar cuando nuestros programas sean invocados, aunque esto tiene algunos matices como veremos luego.

Finish Reading: Serverless: Realidad y perspectivas (1)

¿YAML Pipelines? Si, ¡fácil! (2)

Si, la evolución de Azure Pipelines hacia el mundo YAML sigue su marcha, lo cual quedo determinado con el lanzamiento de los multi-stage pipelines en el pasado Build, lo cual es un avance pues permite incorporar al modo YAML las capacidades de despliegue que ya hemos conocido desde hace buen tiempo, pero mientras este camino continua ¿como logramos que el usuario final se sienta confortable trabajando con YAML? pues la verdad sea dicha, a muchos de nosotros el trabajar a puro texto no nos hace sentir cómodos; así que (como ya vimos anteriormente) a la capacidad de agregar snipets de texto, desde el editor de tareas, hacia nuestro editor de texto, ahora se ha incorporado una ayuda que apenas Tom la menciono me encanto inmediatamente, así que vamos a ello.

Repasemos, si nosotros usamos la capacidad de agregar porciones de texto luego de parametrizar una tarea, nos vemos en la siguiente situación ¿qué hacemos si luego resulta que queremos editar la tarea y sus parámetros?, si es solo cambiar un parámetro de texto (una ruta por ejemplo) no hay mucho problema, pero si queremos cambiar mas de un parámetro dentro de una lista de opciones la cosa cambia un poco, así que lo que hasta hace poco hacía era pegar una nueva tarea con los parámetros actualizados y según correspondía reemplazaba o toda la tarea o solo la sección afectada, y a seguir adelante.

Pues bien ahora en los últimos sprint del producto se ha liberado la capacidad de editar una tarea ya existente en nuestro pipeline, para lo cual debemos fijarnos en las letritas que dicen “settings” sobre una sección de tipo task en nuestro YAML:

En este caso he elegido una tarea que me vino con la extensión para soportar Terraform (¡Si! ahora tenemos una extensión oficial para incluir despliegue de recursos cloud usando Terraform), hago clic sobre las letritas de settings y….

Listo, ya podemos editar totalmente la tarea y actualizar los parametros que hagan falta.

Espero que esto les sea de utilidad para ir avanzando en la creación de mas pipelines YAML, a estar atentos en las novedades que vendran saliendo en cuanto a los multi-stage pipelines.

Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Por aquí ya hemos hablado una vez y otra sobre como gestionar los datos sensibles (como las cadenas de conexión) de nuestras aplicaciones, porque, claro, nadie debería de poner los datos de producción en el código fuente que grabamos en nuestro repo, ¿verdad?

Anteriormente las opciones pasaban por efectuar mezclas/transformaciones de tal manera que en tiempo de compilación se generara un archivo final con los datos sensibles correspondientes a cada entorno, lo cual si bien nos daba simplificación para colocar la clave correcta en el paquete y entorno correcto, nos obligaba a seguir versionando las cadenas de conexión en el código fuente (por no mencionar que había que compilar mas de una vez); la otra opción pasaba por gestionar dentro del entorno de destino (en nuestros ejemplos: WebApps) sobrescribiendo de esta manera los valores que vinieran desde el código fuente.

Dado que ni nuestro repositorio ni nuestra herramienta de integración/despliegue deberían contener datos sensibles, usaremos un servicio de nube que nos da la seguridad necesaria para gestionar nuestras credenciales, el Azure KeyVault, el cual nos permite almacenar de manera segura y granular ya sea certificados digitales como data sensible, pudiendo restringir quienes pueden acceder a que datos y a que no (aplicando Control de acceso basado en roles: RBAC). Un mecanismo usual de accesos a estos recursos sensibles es programar dentro de nuestra aplicación un código que lea los valores en tiempo de ejecución (procurando no releer el valor a cada uso, sino hacerlo una única vez), en este caso usaremos un enfoque distinto que consistirá en leer los valores almacenados en KeyVault durante nuestro pipeline de despliegue, alterando secciones del archivo appsettings.json (porque nuestro ejemplo se basara en .Net Core) que se alojara en nuestra Web App destino (aunque también funciona perfectamente en un despliegue sobre IIS).

Así que estos serán los pasos que seguiremos:

  • Crear un KeyVault
  • Crear un “Secret” dentro de nuestro KeyVault, ahí sera donde almacenaremos una cadena de conexión a la base de datos
  • Identificar el “Principal” mediante el cual nuestro Team Project se conecta a Azure
  • Dar los permisos sobre nuestro KeyVault a dicho principal
  • Identificar en nuestra aplicación las secciones a modificar en tiempo de ejecución
  • Enlazar nuestro TeamProject contra el KeyVault, fijando el scope respectivo
  • Configurar el reemplazo de valores en el appsettings.json
  • Validar que nuestros cambios han sido desplegados en el entorno destino

Para esta demo asumiremos que tendremos tanto un pipeline de Build como de Release, de una aplicación en ASP.Net Core, en nuestro ejemplo usare la aplicación de ejemplo del libro de EF Core in Action (excelente libro que tuve el honor de revisar) cuyo código fuente se puede descargar aquí, y claro, como es usual el despliegue lo haremos contra una Azure Web App.

Para el primer paso seguiremos las instrucciones dadas en la primera parte de este articulo, en mi caso he usado estos nombres: RG_DevmoVault01 para el Resource Group y ErnestoDemoKeyVault para el KeyVault, como en este caso la creación la hemos hecho vía linea de comandos verificaremos que podemos revisar este recurso en el Portal de Azure, así:

Finish Reading: Viendo la seguridad de la configuración con Azure KeyVault, .Net Core y Azure DevOps

Presentando Azure DevOps

El día de hoy Microsoft anuncia Azure DevOps, que a primera vista podría ser un nuevo rebranding de VSTS, pero la realidad detrás de este cambio es mucho mas compleja, así que trataremos de explicarlo haciendo un poco de historia.

Team Foundation Server es presentado el 2005 como una solución integrada para las necesidades ALM de la época, en que se empezaba a buscar herramientas que apoyaran la gestión interactiva de proyectos, así como ir desarrollando los conceptos de Integración Continua y Gestión de Pruebas, rápidamente el producto fue adoptado por buena parte de las organizaciones que ya estaban trabajando con .Net como su plataforma de desarrollo de software, las versiones 2008 y 2010 fueron una mejora incremental que fueron simplificando el trabajo de los equipos, pero aun así el configurar un proyecto de Integración Continua requería pelearse con componentes de terceros y editar archivos XML.

El primer punto de quiebre se produce 2011 con el lanzamiento del preview de Team Foundation Service (que luego seria renombrado como Visual Studio Online) que al inicio era una implementación basada en Azure de los servicios que ofrecía TFS (y que me entusiasmo mucho apenas saque mi cuenta), pero que además de proveer al publico de una infraestructura ALM sin depender de la instalación de un servidor, permitió a Microsoft acelerar sus ciclos de entrega de novedades y pruebas de nuevas funcionalidades, siendo que la versión 2012 de TFS incluía como novedad esencial (al menos para mi) un nuevo modelo de creación de Builds Definitions, basado en XAML, que efectivamente hizo mas sencillo el proceso de despliegue… si usabas las plantillas proveidas en el producto! y es que la idea original era posibilitar la creación de plantillas personalizadas para diversos tipos de entorno (recuerdo que por ahí encontré una plantilla para facilitar el despliegue con ClickOnce, pero que nunca pude hacerla funcionar), para este año ya era mas que notorio el crecimiento de Git y GitHub como plataforma preferida de los desarrolladores, así que la versión 2013 de TFS incluía su propio repositorio Git (al igual que el entonces llamado Visual Studio Online), pero los cambios recién empezaban… Finish Reading: Presentando Azure DevOps

Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

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. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

¡Mudanza en MySQL

Tal vez algunos recuerden pero hace un tiempo migre este blog de Blogger a un servicio WordPress alojado en Azure, ha sido un buen tiempo desde la migración pero lo que no comente plenamente en su momento es que para poder funcionar WordPress requiere contar con una base de datos MySQL, siendo que al momento de la migración Azure no proveía un servicio manejado de MySQL por defecto se nos ofrecía una base de datos gratuita proveída por ClearDB, lo cual nos hace tener que administrar ese servicio en “otro lado”.

El caso es que entre las muchas novedades lanzadas por Microsoft en el Build del año pasado estaba el lanzamiento de una versión manejada (o sea que no tenemos que instalar un servidor Linux) de MySQL, por lo cual una de las cosas que pasaba por mi cabeza era migrar de ClearDB a Azure Database for MySQL, pero por una razón u otra siempre lo postergaba (aun cuando ya había creado una instancia en la misma zona geográfica y Resource Group que este blog!)

Y como suele suceder a veces es un hecho externo el que te hace pasar a la acción y en este caso fue la decisión de ClearDB de descontinuar los servicios gratuitos que estaba ofreciendo, dando como opción hacer un upgrade dentro de sus nuevos planes, pero como supondrán decidí hacer lo contrario y hacer pleno uso de mi BD en Azure, para lo cual seguí las instrucciones detalladas de este excelente post, con un salvedad que paso a contar:

El autor da las instrucciones para que una vez que, vía MySQL Workbench, nos hemos conectado a la BD destino y origen invoquemos un Wizard que efectúe la migración por nosotros y así lo intente, pero por alguna razón el efectuar pruebas consume el numero de conexiones que se pueden hacer hacia ClearDB, por lo que decidí jugar con otra opción: usar el backup que te ofrece ClearDB y tratar de restaurar en Azure, para lo cual entre a la consola web de ClearDB y exporte el ultimo backup disponible.

Una vez descargado el .zip exportado lo que tuve que hacer fue:

  1. Desempaquetar el archivo .sql que esta dentro del .zip (¡Si toda la base de datos esta en un archivo SQL!)
  2. En mi BD de Azure crear un schema con exactamente el mismo nombre existente en la instancia de ClearDB (para mas seguridad pueden copiar el comando de creación desde la BD origen)
  3. Seleccionar nuestra nueva bd/schema y ejecutar el SQL en cuestión.

Luego toca proseguir con las instrucciones del post respecto a la configuración de seguridad y conexión en nuestra Azure Web App de WordPress, pero adicionalmente es necesario editar el archivo wp-config.php de nuestro site, a fin de que todos los parámetros estén actualizados completamente, y claro luego de eso verificar que funcione adecuadamente, lo cual como pueden ver, va perfectamente.

Asi que … ¡gracias ClearDB, hola Azure Database for MySQL!

Las perspectivas PaaS Linux sobre Azure

Si hace unos años me hubieran dicho que estaría comentando sobre lo que menciona el titulo, me hubiera puesto a reír, pero el contexto tecnológico cambia de manera constante y este es el escenario en que los desarrolladores debemos tener claras nuestras opciones a la hora de considerar Linux como plataforma.

De mas esta comentar sobre las oportunidades que nos ofrece .Net Core para poder llegar a escenarios en los que tradicionalmente Windows estaba vedado, pero también debemos tener en cuenta las perspectivas de poder integrarnos y trabajar con otros stacks, así que si… Linux nos va a rodear bastante a los que trabajamos con .Net.

Ahora bien,  trabajar con Máquinas Virtuales Linux siempre ha sido posible desde que los proveedores de cloud empezaron a ofrecer IaaS, pero si uno basa su estrategia cloud en depender de máquinas virtuales que básicamente replican la arquitectura que se tenía on premise, no se está sacando partido de las potencialidades de la nube (optimización de costos y escalamiento) ni  tampoco se esta asumiendo un enfoque pragmático frente a los retos (o limitaciones) inherentes a la nube, como pueden ser los niveles de servicio asegurados por el proveedor (SAL), lidiar con las latencias, etc, esto y la necesidad de brindar a nuestros equipos de desarrollo con plataformas que aceleren su productividad nos deben obligar a mirar la nube más allá del IaaS.

Es con esta mirada que debemos analizar la propuesta PaaS que nos da Azure en el entorno Linux; recordemos que tradicionalmente si queríamos implementar una Web App lo que estábamos provisionando “por detrás” era una MV Windows con un IIS especialmente configurado para permitir las ventajas como slots, escalamiento, kudu, etc… lo cual nos va bien para aplicaciones .Net pero por ejemplo no nos permite correr aplicaciones Ruby, aparte de que existen escenarios en que se requiere cierta librería PHP que ¡oh sorpresa! tiene una fuerte dependencia con el sistema operativo Linux, así que era natural que Microsoft Azure venga a ofrecer una solución de Web Apps basada en Linux como una opción para los desarrolladores, misma que en este momento esta en versión de prueba.
top-level-create
Finish Reading: Las perspectivas PaaS Linux sobre Azure