Ejecutando, depurando y desplegando microservicios con “Tye”. De paso, un vistazo a LENS

En este post vamos a ver de una manera simple y directa el uso de Project Tye y cómo desplegar aplicaciones .NET Core / .NET 5 en Kubernetes en general y, en AKS en particular. Gracias a Tye, a partir de ahora, este tipo de despliegues va a ser mucho más sencillo. ¿Te atreves?

Ademas, veremos que es Kubernetes LENS y como este permite la integración con Prometheus en un solo click.

En definitiva, todo lo que necesitamos para ejecutar, depurar, desplegar y gestionar nuestra aplicación en un cluster de Kubernetes, y, por si fuera poco, todo ello en unos unos pocos minutos, 😉

¿Que es Tye?

Tye (o Project Tye), es una herramienta de desarrollo que facilita el desarrollo, los tests y la implementación de microservicios y aplicaciones distribuidas. Incluye un orquestador local para facilitar el desarrollo de microservicios y la capacidad de implementar microservicios en Kubernetes con una configuración mínima y de manera muy sencilla.

Tye no solo permite el despliegue de aplicaciones dotnet, si bien para proyectos .NET (ficheros .csproj), lo facilita MUY ENORMEMENTE. ¡De entrada, te olvidas de los “.dockerfile”, Tye los genera automáticamente por ti!.

Para más detalle, podemos echar un ojo aquí, al repositorio de Github de Tye.

Podríamos decir también que es equivalente a Docker Compose, pero presenta justo las diferencias que lo hacen mucho mas sencillo e indicado especialmente para proyectos .NET Core / Net5. Por ejemplo, los servicios no tienen porque ser únicamente contenedores, pueden ser también “ejecutables” (en este caso con algunas configuraciones para la comunicación) y, por supuesto directamente, proyectos .NET (.csproj).

Si te interesa saber más sobre la comunicación entre ejecutables y/o conteneros, Eduard Tomás (@eiximenis) detalla mucho mucho más este tema en este post.

En la pasada #dotNETConf, vimos la siguiente tabla que resume a modo de Cheat Sheet los comandos de Tye y una comparativa con otras herramientas. Creo que de un vistazo puede aclarar muchas dudas sobre lo que es Tye y hasta dónde puede llegar.

Imagen

Instalar Tye

Esta instalación es sencilla, basta únicamente con utilizar “dotnet tool install -g” tal y como se muestra a continuación, indicando la versión ya que en estos momentos no existe aún una versión release.

dotnet tool install -g Microsoft.Tye --version "0.5.0-*" --add-source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json

Desarrollar/trabajar con un ejemplo

mkdir microservices
cd microservices

dotnet new razor -n frontend
dotnet new webapi -n backend
dotnet new sln
dotnet sln add frontend backend // (*) Añadir código para acceder desde el frontend al backend y uso de Redis Cache
tye init

(*) Puedes añadir manualmente este código o utilizar directamente el que puedes encontrar en este repo de Git.

El comando anterior tye init crea un fichero “tye.yml” tal y como se muestra a continuación:

name: microservices
services:
- name: frontend
  project: frontend/frontend.csproj
  replicas: 1  
- name: backend
  project: backend/backend.csproj
  replicas: 1
- name: redis
  image: redis
  bindings:
  - port: 6379
    connectionString: "${host}:${port}"

Como podremos observar en el código, para la comunicación entre frontend y backend no se especifica la ruta base, ni mucho menos se utiliza hardcode, en su lugar, se especifica el nombre del backend y el Service Discovery de Tye se encarga del resto. Para usarlo, bastará con añadir a nuestro proyecto la referencia al paquete nuget: “Microsoft.Tye.Extensions.Configuration“. ¡Si quieres profundizar sobre ello, visita este link!.

Ejecución en local

Ejecutar tye run desde línea de comandos y navegar a la url del Dasboard de tye tal y se observa en el detalle de ejecución (http://127.0.0.1:8000, para este caso en particular).

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-7.png
La imagen tiene un atributo ALT vacío; su nombre de archivo es image-9.png

Importante: Tanto el puerto del Dashboard como el del resto de servicios/proyectos, cambiará de manera dinámica, por lo que es importante tenerlo en cuenta.

Por detrás, Tye, usa Docker y genera las imágenes y contenedores necesarios para ello. Podemos comprobarlo si ejecutamos desde línea de comandos “docker ps“, tal y como muestra la siguiente salida.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-20.png

Despliegue en AKS

En primer lugar y previo a ejecutar el despliegue, es importante asegurar que:

  • Existe un Cluster de AKS. ¡Para este ejemplo, he utlizado la última versión 1.19.3 (aun en preview).!
  • Realizar el login en el Cluster de AKS y obtener las credeciales para su acceso
az login --tenant <TENANT-ID>
az account set -s <SUBSCRIPTION-ID>
az aks get-credentials --resource-group <RESOURCE_GROUP_NAME> --name <AKS_CLUSTER_NAME>
  • Permitir a AKS el acceso a Azure Container Registry. Para ello, ejecutar la siguiente instrucción una vez que haya sido creado el Cluster de AKS.
az aks update -n <AKS_NAME> -g <RESOURCE_GROUP_NAME> --attach-acr <AZURE_CONTAINER_REGISTRY_NAME>
  • Ejecutar desde línea de comandos: “tye deploy -y” e indicar el Container Registry cuando se requiera. De igual forma, indicar la cadena de conexión de Redis Cache, la cual quedará almacenada como un secreto en AKS.

Acceso a la Información de AKS (“Dashboard”)

Para la visualización, consulta de log y gestión de nuestro Cluster AKS, disponemos de varias herramientas, que revisamos a continuación:

La versión 1.19.3 de AKS ya no permite lanzar el Dasboard desde linea de comando con el CLI “AZ”. Ha quedado deprecado y, en su lugar, es el Portal de Azure quien nos presenta esta información. Eso si, por el momento en modo “Preview”.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-12.png

Por otro lado, y además de “kubectl” (como es de sobra conocida), contamos con la extension para VSCode, “Kubernetes“, tal y como muestra la siguente imagen, y que también, es conocida.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-10.png

Disponemos además, de otra herramienta, que me ha enamorado y que he descubierto recientemente, gracias a “@JGallardoRama”. Se trata de “LENS“, un IDE tanto para Windows como para MAC y Linux, que gestiona diferentes Cluster de Kubernetes (Minikute, AKS, EKS, GKE, etc.) así como la integración con Helm y otros orquestadores. Es más, permite, con un simple click (opción de menú: “File – Cluster Settings – Features (Metrics) – Install), la integración con Prometheus, instalándolo automáticamente en el Cluster de Kubernetes.

LENS: World’s most popular Kubernetes IDE provides a simplified, consistent entry point for developers, testers, integrators, and DevOps, to ship code faster at scale. Lens is the only IDE you’ll ever need to take control of your Kubernetes clusters. It is a standalone application for MacOS, Windows and Linux operating systems. Lens is an open source project and free!

En la siguiente imagen podemos ver una imagen de LENS, y en concreto, la opción de “Overview” del Cluster. Vemos también acceso directo a los Pods, Deployments, etc. y la posibilidad de realizar acciones, como eliminar, editar y escalar. ¡En mi opinión, creo que no tardará en disponer de la realización de todas estas acciones de manera masiva, lo que la hará mucho mas y útil 🙂!

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-14.png

En esta otra, podemos ver la integración con Prometheus.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-15.png

Incluyendo un Ingress

Si añadimos al final del fichero “tye.yaml” el siguiente código, dotaremos a nuestra aplicación/sistema de un ingress.

ingress:
  - name: ingress
    bindings:
      - port: 8080
    rules:
      - path: /
        service: frontend

Si ejecutamos nuevamente “tye deploy -i” y navegamos a la IP externa/publica proporcionada por AKS, comprobamos que nuestra aplicación se ejecuta correctamente, en el puerto 80.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-17.png

Depuración

  • Ejecutar “tye run –debug
  • Atachar el proceso correspondiente al proyecto de frontend o backend desde Visual Studio Code o Visual Studio.
La imagen tiene un atributo ALT vacío; su nombre de archivo es image-18.png

Pero, ¿Qué ocurre al depurar si tenemos 3 réplicas? Tendremos que depurar cada una de ellas de manera independiente, o bien, abrir tantas instancias de Visual Studio Code o Visual Studio como replicas existan.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-19.png

Espero que sea de utilidad y ayude a perder un poco el miedo para crear y probar arquitecturas e infraestructuras basadas en Kubernetes.

Referencias:

Tooling para presentar Charlas/Eventos/Demos

Durante estos días está teniendo lugar la #dotNETConf en la que no solo estamos viento novedades de .NET, también es momento para compartir todo tipo de experiencias. En concreto en este post, quiero hacer mención a dos de las herramientas que usan los Presentadores, y que ademas @shanselman contaba ayer en una de sus charlas.

ZoomIt

ZoomIt es la herramienta de Sysinternals, para anotaciones y zoom de pantalla.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-4.png

La siguiente imagen muestra un rectangulo y una flecha señalando la caja de texto de “Power Toys Run” :

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

Aunque con 5 min de dedicación es facil entenderla al completo, los paso seguidos son estos para este ejemplo en concreto son los siguientes:

  • Ctrl + 1. Realiza el zoom de la pantalla. ¡Si pulsamos Ctrl + 2 en su lugar evitamos hacer el zoom, si no lo necesitamos!
  • Mouse Left Click. Fijamos el zoom en el punto en el que poner el foco.
  • [Opcional]. En este punto, al pulsar la tecla, r, g, b, y, el color del rectangulo o la flecha cambiará por Red, Gree, Blue o Yellow, respectivamente.
  • Ctrl + Mouse Left Click. Pintamos el rectangulo.
  • Shift + Ctrl + Mouse Left Click. Pintamos la flecha.

Nota: Las combinaciones de teclas indicadas son las predetermindas, si bien, estas pueden ser adecuadas a nuestro antojo.

Azure Mask

Azure Mask (Az Mask). Es una extensión de Chrome / Edge (Chromium) que permite enmascarara (o hacer “blur“) de todas los textos de caracter sensible al navegar a lo largo del Portal de Azure.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image.png
Extesión de Chrome
La imagen tiene un atributo ALT vacío; su nombre de archivo es image-3.png
Habilitar / Deshabilitar el enmascarado

A continuación podemos ver un ejemplo de su uso:

La imagen tiene un atributo ALT vacío; su nombre de archivo es azmask-1.gif

Nota: Como excepción, la parte de la url correspondiente a la subscripción no es ofuscada por la herramienta.

Creo que voy a comenzar a sustituir a “Magnifier” y, por supuesto, a dejar enmascarar manualmente cada pantallazo de Azure que incluyo en mis posts 🙂

Saludos/regards and enjoy #dotNETConf days !

[Learning] Angular + NodeJS para un “.NET-tero (C#)”

 

Como fanático, enamorado y apasionado del mundo DotNet/DotNetCore (C#), durante las últimas semanas, he podido dedicar tiempo a incrementar mis Skills, tanto en Frontend (Angular) como en un nuevo lenguaje de backend (nodejs) y mucho, mucho Visual Studio Code.

Hasta ahora, siempre he sido totalmente autodidacta dedicando mucho esfuerzo en leer, usar Google, Stack Overflow y mucha practica (prueba + error), etc. Si bien, en esta ocasión, he decidido hacer un curso con el objetivo de profundizar mucho mas y conocer todo este nuevo mundo.

He de decir, que tras finalizarlo (32.5h codificando + pruebas personales, cacharreos varios, etc.) me siento muy satisfecho con lo aprendido. Tanto es así, que el día a día ya me ha llevado a proyectos reales por estos derroteros, facilitándome mucho el trabajo y, lo mas importante, ahorrándome tiempo.

Para los que me conocen, creí que nunca lo diría (a pesar de que ya tenía conocimientos básicos), pero hasta me gusta Angular y NodeJs. Bueno, en cuanto a NodeJs, es posible que me aventuré también con NestJS, con el que también he “cacharreado” un poquito.

Por si alguno le interesa el curso, es este: Angular Avanzado – De Cero a Experto. A continuación indico brevemente su contenido:

Tiene como objetivo partir del conocimiento actual de Angular (Angular 2, 4, 5, 6, 7, 8, 9 o 10), y llevarlo al siguiente nivel creando una gran aplicación modular de gran escala (Admin-pro). No enseña las bases de Angular, sino que parte, de saber cómo utilizar servicios, componentes básicos, ciclo de vida de un componente y el enrutado/rutas.  Es totalmente práctico, y se centra en ir haciendo una aplicación completa desde cero, que va desde el Front-End hasta el Backend, trabajando con MongoDB, JWT y Google SignIn. Es decir un largo camino a través de los siguientes hitos principales:

  • MEAN Stack: Mongo, Express, Angular, Node
  • Estructura de una aplicación de Angular a gran escala
  • Aplicación en base a módulos
  • Temas(Themes)/CSSs
  • Backend server completo:  Express, RESTFul API, Subida de archivos, CORS, MongoDB, JWT, Revisión de tokens de Google SignIn, Paginación de datos
  • Contenido de Angular enriquecido para trabajar con el el backend server
  • Pruebas unitarias
  • Pruebas de integración
  • Google SignIn protegido por token desde el Front-End hasta el Backend
  • Uso de librerías de terceros en proyectos de Angular
  • Rutas con configuraciones
  • Programación reactiva.
  • Control de versiones y releases
  • Publicación en Heroku.
  • Firebase: Cloud Functions, Firestore y Hosting
  • Y, mucho más.

Agradecer a @fernando_her85, el magnifico esfuerzo de de este curso, así como felicitarle por su gran capacidad como comunicador.

A continuación facilita los distintos repositorios de Github con todo el material del curso, de acuerdo a mi implementación:

Creo que Goty / Goty-Backend, va a ser una muy buena aplicación de ejemplo para siguientes charlas/eventos que imparta y, ¿porque no? Implementarlas en NetCore. O mejor aún en Net5 :D.

Un saludo & happy Angular/Node learning/coding…
Juanlu

Gran momento en el Podcast: NTN con @elbruno y @jc_quijano

Partiendo de no tener un guión inicial, durante 1h, (que me han parecido minutos), he compartido con @elbruno y @jc_quijano una gran momento. Momento tan cercano y familiar, que hasta me ha llegado a suponer un empujón emocional y motivacional. ¡Pilas cargadas para seguir al pie del cañón tecnológico otros tantos años más!

Hemos hablado de temas como: Blazor, Arquitectura de Software, generación de código, usuarios de Windows que usan Mac (:D), Angular por todos lados (y en especial para un “.NET-tero” como yo), consumición de contenidos online, Microsoft Ignite, NetCoreConf y mucho, mucho más.

Un repaso general y cambios de impresiones, que creo que merece la pena escuchar. ¡Nos faltó la cervecita!

Aquí os dejo el link: https://www.ivoox.com/ntn-66-sobre-exceso-eventos-audios-mp3_rf_57486368_1.html

Un placer estar de este otro lado/canal y espero que lo disfrutéis como yo lo he disfrutado.

Un saludo
Juanlu.

[TIP] Actualización del Password de Outlook en MaC

Ahora que utilizo el Mac también para trabajar, me encuentro con situaciones del día a día, algunas triviales, pero que sin embargo, son un “tostón”. En este caso particular, el simple hecho de actualizar el password de Outlook. A continuación recojo los pasos para conseguirlo fácilmente:

  1. Salir de Outlook y todas la aplicaciones Office.
  2. Iniciar Keychain Access mediante alguno de los siguientes métodos:
    • Click en Finder, click en Utilities en el menú Go , y, double-click en Keychain Access.
    • En Spotlight Search, (Command + Space) escribir Keychain Access, y hacer double-click en Keychain Access.
  3. En el campo de búsqueda introducir Exchange.
    • Seleccionar cada uno de los items para ver la cuenta (Account) que aparece en la parte superior y hacer click en Delete.
    • Nota: Repetir este paso para todos los items de la cuenta de Exchange.
  4. En el campo de búsqueda introducir: adal.
    • Seleccionar todos los items cuyo tipo es MicrosoftOffice15_2_Data: ADAL:<GUID>, y borrarlos (Click en el botón Delete).
  5. Nuevamente introducir en el campo de búsqueda: office.
    • Eliminar todos los items con los nombres: Microsoft Office Identities Cache 2 y Microsoft Office Identities Settings 2.
  6. Finalmente salir de Keychain Access.

Gracias/Thanks to : Alvina Gupta. Ref: Resolved: Outlook Mac Keeps Asking for Credentials.

Un saludo

Improving the Code Quality in .Net and .Net Core projects using NDepends

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-7.png

Continuando con el análisis de código, la cobertura y los tests como ya viemos en este post (“Runing Tests and Code Coverage without Visual Studio. OpenCover con coverlet y ReportGenerator“), seguiremos profundizando en el “Code Quality”, y conoceremos otra buena herramienta, también extensión de Visual Studio e integración con Azure DevOps, NDepends:

NDepend es la única extensión de Visual Studio que puede decirnos que durante la última hora, el código recién escrito ha introducido una deuda técnica que costaría, por ejemplo, de 30 minutos. Sabiendo esto, podemos arreglar el código, incluso antes de comprometerlo con el control de código fuente.
Con NDepend, las reglas son consultas C# LINQ que se pueden crear y personalizar en cuestión de segundos. Estas consultas contienen fórmulas de C# para calcular estimaciones técnicas de la deuda.
El conjunto de reglas predeterminado ofrece más de cien reglas de código que detectan una amplia gama de Code Smell que incluyen código espagueti, código muerto, breaking changes, y mal uso de POO.

Antes de nada, quiero aprovechar la oportunidad y dar las gracias a Patrick Smacchia, quien me a invitado a probarla y a sacar mis propias conclusiones, que sin duda, me adelanto a decir que han sido satisfactorias.

Así mismo quiero hacer referencia a este post de Variable Not found, donde @jmaguilar, comentaba las bondades de esta herramienta. Profundizaré comentando nuevas características y mejoras que han seguido llegando. Como podemos ver, directamente al abrir la herramienta nos encontramos ya con nuevas integraciones: AppVeryor, Bamboo, VSCoverage, OpenCover, DotCover, NCover además delas ya conocidas: VSTS, TeamCity, Sonarqube, Jenkins y Reflector:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

Par probarla, instalaremos la extensión para Visual Studio y utilizaremos este ejemplo (https://github.com/juanluelguerre/DotNet.ApiRest.BasicTemplate) .

En Visual Studio 2019, tenemos una nueva opción de menú (Extensions – NDepend) con multitud de opciones:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image.png

Para añadir la solución , proyectos y/o ensamblados y así asociar NDepend para su ejecución, ejecutamos “NDepend Project Properties” y a continuación, el análisis (Run Analysis) tras el cual se muestra un Dashboard. Dashboard que representa un resumen general del estado de nuestra aplicación. A partir del mismo podemos acceder a cada uno de sus detalles que iran siendo mostrados en la ventana de la derecha y nos irán facilitando la posibilidad de navegar por el código e incluso ejecutar acciones sobre propio código.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-2.png

Uno de los puntos interesantes es la facilidad para hacer consultas sobre el código o incluso definir nuevas reglas, usando un lenguaje muy similar a “Linq” . Para ello bastará con editar las mismas o bien crear una nueva.

En lo que respecta, por ejemplo, a la deuda técnica, podemos verla detallada por método e incluso acceder y/o modificar el código “Linq” equivalente.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-3.png

Asi mismo, para nuevas personalizaciones tenemos varias alternativas mediante el menu: “Tools – NDepend – new y sub-menu: Code query… | Code Rule… \ Quality Gate… | Tend Metric…\ Trend Chart… \ Rule File… \ Project …“.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-5.png

Donde, para la creación de una nueva consulta (“Tools – NDepend – new – Code Query“), navegamos a la ventana de edición que incluso incorpora Intellisense, lo que nos facilita mucho más el trabajo.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

En cuanto a la covertura de código, NDepends proporciona el siguiente detalle de manera totalmente gráfica en proporción al número de lineas de código (LOC), e incluso, en la ventana de la derecha, el % de cobertura, a nivel de namespace, clase, método, etc..

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-7.png

La matriz de dependencias no cambia mucho con respecto a la que ya conocíamos,

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-9.png

sin embargo, el gráfico/diagrama de dependencias si que lo hace, con un diseño mucho más moderno y una navegación mucho más amigable e intuitiva y, nuevamente con posibilidad de edición:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-11.png

Por otro lado, en la esquina inferior derecha de Visual Studio, encontramos también una opción, en la que, además de algunos accesos directos, vemos a modo de resumen datos significativos sobre el estado de nuestro código.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-1.png

Que también cuenta con una opción “Run Analysis and Build Report“, que, además de mostrar el Dashboard, como hemos visto anteriormente, genera un report local (en formato html), totalmente navegable y accesible a todos los detalles. Como podemos imaginar, su consumo, va a permitirnos no depender directamente de Visual Studio.

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-4.png

Por ultimo, NDepend cuenta con una herramienta de línea de comando avanzada (NDepend Power Tools), que hace uso del API de NDepends y proporciona una amplia variedad de características, desde la búsqueda de código duplicado, facilidad para la revisión de código y, hasta la detección de cambios de API públicas:

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-5.png

Como conclusión, y coincidiendo con @jmaguilar, NDepend:

  • No requiere la edición “Enterprise” de Visual Studio y tenemos la posibilidad de usar su versión stand alone.
  • Es una herramienta, en mi opinión muy potentente, que además resulta casi imprescindible en grandes proyectos y de alto y constante mantenimiento.
  • Esencial al adquirir/heredar proyectos de terceros, donde de un primer vistazo vamos a poder tener una amplia visión sobre el estado del mismo. Va a permitirno poder hacer una valoración y saber a que nos enfrentamos desde un primer momento.
  • Añadir, que se trata de una herramienta de pago con su versión trial que puedes descargar aquí.

Espero que sirva de utilidad y que ayude a seguir creciendo como programadores además de a continuar mejorando y aprendiendo de las buenas practicas.

Happy Coding and good Quality !

Referencias:

[Event] Inteligencia Artificial, Bots, VUIs, Cognitive Services y Azure

[Disponible Material Everis CodeFest 2019] – Sessión: Bots, asistentes de voz y otras interfaces del futuro .

Espero que además de esta sessión, el evento en general haya sido intereante, entretenido, divertido, además de productivo, etc. 😉

Github

Nos vemos en el próximo evento
Un saludo
Juanlu

PD: Mas información sobre el evento: http://codefest.everis.com/

From GitHub to Azure App Service through Jenkins pipelines

Desde mi punto de vista Azure DevOps es quizas una de las mejores herramientas como orquestadora de Pipelines para DevOps, al menos con la que me siento más cómodo trabajando y para mi, la mas fácil. Si bien, hoy vamos a ver como trabajar con Jenkins para conseguir el mismo objetivo que ya vimos en el post anterior (con Azure DevOps) y para la aplicación MyBudget.

Configuración

Aunque podemos descargar e instalalar localmente Jenkins, vamos a optar por una instalación en Azure.

  • Crear un nuevo recurso (Create a resource)
  • Seleccionar Jenkins
  • Pulsar el boton de crear y completar los pasos indicados hasta finalmente pulsar “OK”.

Creación de un nuevo recurso “Jenkins” en Azure

  • Una vez creado el servidor Jenkins, tendremos acceso a la VM. Por defecto el protocolo de acceso es HTTP, por lo que no podremos acceder directamente a traves navegador a la url “xxx.cloudapp.azure.com“. Por tanto, tendremos que hacerlo via localhost mediante ssh de la forma: ssh -L 127.0.0.1:8080:localhost:8080 username@xxxwesteurope.cloudapp.azure.com, tal y como muestra la siguiente imagen:

  • En estos momentos ya podremos acceder al portal de jenkins vía http://localhost:8080, si bien para poder compilar la aplicación MyBudget, necesitaremos instalar el SDK de NetCore para Linux (Ubuntu) utilizando para ello las siguentes instrucciones.

Para conocer la distribución de linux para la que actualizar el SDK, podemos ejecutar el comando “cat /proc/version” desde la consola Cloud Shell.

wget -q https://packages.microsoft.com/config/ubuntu/16.04/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-2.2

  • Adicionalmente y para que Jenkins pueda acceder y desplegar en Azure App Service, necesitamos dos plugins que podemos instalar desde el menú: Manage Jenkin – Manage Plugins:
    • Azure Credentials
    • Azure App Service Plugin

Pipeline

Ahora que ya tenemos todo configurado, crearemos el Pipeline, cuyo objetivo es compilar y ejecutar los tests unitarios de forma automática (CI – Continuous Integration) tras cada push/merge en la rama “master”, para a continuación, disparar el proceso de CD (Continuous Deployment) para el despliegue a DEV de manera automática y a Producción, previa aprobación. Supondremos que nuestros dos Azure App Services (para DEV y PROD) han sido creados previamente.

En primer lugar creamos una nueva credencial para el acceso a Azure (gracias al plugin “Azure Credential”):

  • Desde el terminal Cloud Shell de Azure, ejecutar las siguientes dos instrucciones:
    • az account set –subscription “<AZURE SUBSCRIPTION NAME>”
    • az ad sp create-for-rbac –name “MyBadget” –password <PASSWORD

  • Con el resultado de dichos comandos completar la siguiente información para añadir así la nueva credencial de tipo “Microsoft Azure Service Principal“, donde:
    • Client ID, se corresponde con el appId.
    • Client Secret, con el password.
    • Tenat ID, con el tenant y,
    • Subscription ID, con la subscripción de Azure, que también podemos obtener con la instrucción “az account show“.
  • Pulsar en “Verify Service Principal” para asegurar que la credencial es correcta.
  • Pusar en “OK”.

Las dos intrucciones anteriores registran una nueva aplicación (“MyBadget”) en el Directorio Activo de Azure. Navegando a ella, podemos ver también los valores de los parámetros antes introducidos.

  • Crear un nuevo Pipiline con el nombre “MyBudget-CI-CD”.
  • Parametrizar el proyecto marcando el check “This project is parameterized” y crear los siguientes parámetros:
    • RESORCE_GROUP, con el valor correspondiente al nombre del Resource Group de azure donde se encontraran los Azure App Services destino del despliegue: mybudget.
    • APP_NAME_DEV con el valor “mybudgetdev” y, APP_NAME_PROD con el valor “mybudgetprod“. Donde ambos parámetros se corresponden con el nombre del Azure App Service y que a su vez forma parte de la url: https://<APP_NAME_DEV|APP_NAME_PROD>.azurewebsites.net.
    • AZURE_CREDENTIAL_ID, del tipo “Microsoft Azure Service Principal” y requediro y selecciónar la credencial previamente creada: “Azure-Enterprise-MyBudget“.
  • Marcar el check “Github hook trigger for GITScm polling”.
  • Crear el script para la Pipeline (Declarativo).

pipeline {
    agent any
    stages {
        stage('Checkout git repo (DEV)') {
            steps {
                git branch: 'master', url: params.GIT_REPO
            }
        }
        
        stage('Build and Publish') {
            steps {
                sh(script: "dotnet publish MyBudget.sln -c Release", returnStdout: true)
            }
        }
        
        stage('Deploy to Azure (DEV)') {
            steps {
                azureWebAppPublish azureCredentialsId: params.AZURE_CREDENTIAL_ID, 
                resourceGroup: params.RESOURCE_GROUP, 
                appName: params.APP_NAME_DEV, 
                sourceDirectory: "MyBudget/bin/Release/netcoreapp2.2/publish/"
            }
        }
        
        stage('Deploy to Azure (PROD)') {  
            steps {
                input 'Do you approve deployment to PRO?'
                
                azureWebAppPublish azureCredentialsId: params.AZURE_CREDENTIAL_ID, 
                resourceGroup: params.RESOURCE_GROUP, 
                appName: params.APP_NAME_PROD, 
                sourceDirectory: "MyBudget/bin/Release/netcoreapp2.2/publish/"
            }
        }        
    }
}

Aunque hemos optado para este post la opción “inline” para la creación de la Pipeline, la recomendación es usar un fichero “jenkinsfile” dado que el repositorio de código fuente jugará un papel importante en el mismo al igual que para el resto de código de nuestra aplicación.

Continuous Integration/Delivery

Para configurar la Integración continua (CI) en Jenkins, y así poder disparar el Pipeline automáticamente, es necesario incluir un Webhook en el repositorio de github, a traves de la opción: “Settings – Webhooks” y añadiendo el sufijo “/github-webhook” a la url de Jenkins:

Finalmente si hacemos un cambio en el código y un push a “master”, el Pipeline se activará debido al Webhook en Github y el proceso de CI/CD dará comienzo.

En el ejemplo, para el despliegue a “PROD” se ha incluido la aprobación, al igual que en el post anterior con Azure DevOps.

Happy DevOps
Juanlu

Nota: No olvidemos apagar la VM cuando no la usemos para ahorra créditos de Azure.

Referencias:

From GitHub to Azure App Service through Azure DevOps pipelines

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-21.png

En post anteriores vimos como compilar, ejecutar tests y lanzar la cobertura de código desde línea de comandos e incluso ejecutamos el análisis estático con Sonarqube:

pues bien, en éste veremos como hacer todo esto en Pipelines de Azure DevOps y además, concluiremos con una publicación en dos entornos (Development y Producción) basados en Azure App Service. En resumen, vamos a construir un sistema de CI y CD, para el que seguiremos los siguientes pasos, teniendo en cuenta como en ocasiones anteriores que nuestro código se encuentra en Github y concretamente aquí (MyBudget):

  • Configurar “Azure Pipelines” en GitHub buscándo esta carácterística en el Marketplace y eligiendo el plan gratuito.

  • Desde el Portal de Azure (aunque podemos elegir otra alternativa), crear dos Azure App Services (mybudgetdev y mybudgetpro) basados en Windows.
  • Nota: Podríamos optar por crear un sólo App Service con dos Slots, si bien, supondría un coste que con el plan básico de los App Services no exite.

Plan básico (Free) para la creación de Azure App Services

Creando Azure App Services (Windows) desde el Portal

  • Crear las Pipelines en Azure DevOps. Una para Build y otra para Release.
  • Nota: Si no disponemos de ningún proyecto Azure DevOps, lo creamos siguiendo los pasos detallados aquí.

Seleccionar como origen de código “GitHub”

Seleccionar la plantilla “Azure Web App fro ASP.NET”

Crear y deshabilitar las opciones de publicación a Azure App Service

  • Actualizar el paso “VsTest – testAssemblies“, como sigue, para la propiedad “Test Files”:

**\bin\$(BuildConfiguration)\**\*test*.dll
!**\obj\**
!**\xunit.runner.visualstudio.testadapter.dll !**\xunit.runner.visualstudio.dotnetcore.testadapter.dll

  • Guardar y ejecutar (“Queue”) la build. Nota: Podríamos haber optado por no deshabilitar esta publicación/deploy, si bien, queremos separar build (CI) de Deploy (CD) y conocer así, el funcionamiento de una Release.
  • Seleccionar la opción de menú: Pipelines – Release y crear una nueva release (+ new release pipeline) y pulsar “Apply” para la plantilla “Azure App Service deployment“.

Crear nueva release para la plantilla “Azure App Service deployment”

  • Establecer el nombre del Stage como “Development”.
  • Marcar el artefacto origen que lanzará la release, que en este caso se corresponde con la build anteriormente creada.

Nombrar al Stage como “Development” y seleccionar la build a partir de la cual se generará la release

  • Configurar el State “Develpment”, y seleccionar una subscripción de Azure.
  • Optar por el tipo de App Service basado en Windows.
  • Seleccionar el App Service “mybudgetdev“, dejando el resto de valores por defecto.

Configurar el stage “Delopment” y seleccionar el App Service “mybudgetdev”

  • Configurar el trigger para el Continuous Deployment a partir de la build.

Configurar el trigger para el Continuous Deployment (CD)

  • Crear un nuevo Stage “Production” seleccionado nuevamente la plantilla “Azure App Service deployment” y configurar el Stage al igual que el anterior, seleccionando en este caso el App Service “mybudgetpro“.

  • Clicar sobre el icono (persona) del Stage de Production y marcar como triger “Afer stage” seleccionando “Development” como Stage anterior.
  • Habilitar también “Pre-deployment approvals” e introducir el email del aprobador, que será quien de el OK para el despliegue al entorno de Producción. Nota: Utilizamos esta opción simplemente por simular un Continuous Delivery, es decir, el requerimiento de un paso/despligue a Producción previa aprobación.

  • Finalmente, tras hacer un commit en la rama “develop” de git y tras un PR a la rama “master”, nuestrá build se ejecutará de manera automática y tras ella, el proceso de Continuous Deploy comenzará también su ejecución.

Build en ejecución tras un PR a “master”

Tras la finalización de la Build, Release en ejecución y aprobación pendiente para Producción

Espero que sirva de utilidad y, principalmente para entender el proceso de CI y CD en un vistazo rápido.

Happy Azure DevOps
Juanlu

Azure Ubuntu VM + SSH & RDP

La imagen tiene un atributo ALT vacío; su nombre de archivo es image-6.png

En este post vamos a ver como crear desde Azure una máquina virtual Ubuntú y como conectarnos a ella vía SSH e incluso vía RDP para hacerlo también gráficamente. Para ello:

  • Desde el Portal de Azure (Portal.azure.com) pulsar “Create a resorce” en el menú lateral izquierdo.
  • Seleccionar la subscripción e introducir un nombre (ej.: goku).
  • Configurar la cuenta ssh donde:
  • Desde la consola (“terminal”) de comandos ejecutar los siguientes comandos. En windows podemos usar también la consola de bash (Windows WSL (“Windows Subsystem Linux”)):

ssh-keygen -t rsa -b 2048
cat .ssh/id_rsa.pub

  • Copiar el resultado del comando “cat” a exceptión del sufijo final, tal y como muestra la imagen anterior.
  • Completar y continuar los pasos del portal de Azure.

Activar puertos SSH, RDP y HTTP/S para descarga de paquetes (apt-get) desde la VM

  • Finalmente pulsar “Create” para crear la máquina virtual
  • Pulsar el botón “Connect” – “SSH” y a continuación copiar la instrucción “ssh” a ejecutar en el terminal.

Instrucción ssh para conectar con la VM (IP máquina azure)

Resultado de la ejecución ssh

  • A continuación, una vez establecida la conexión ssh, instalar XRDP y UBUNTU-DESKTOP.

sudo apt-get clean sudo apt-get update sudo apt-get install xrdp sudo apt-get install ubuntu-desktop

  • Una vez ejecutados y completados estos comandos, desde el portal de Azure y para la VM “Goku”, seleccionar la opción del menu lateral “Reset password” para introducir las credenciales necesarias para la conexión RDP.
  • A continuación seleccionar la opción “RDP” de conexión y pulsar en “Download RDP File“.

Información de conexión RDP

Completados todos los pasos, incluida la espera para la ejecución de los comandos “apt-get install …“, que son unos 15 min. aproximadamente, podremos realizar la conexión gráfica vía RDP con exíto.

Saludos and happy Ubuntu Cloud play
Juanlu