Azure: Centro de Arquitectura para Soluciones DevOps

3 de julio de 20224 de septiembre de 2022 Santimacnet Azure Cloud Solutions, Azure DevOps (VSTS), DevOps

El articulo de hoy es una recopilación de enlaces que suelo utilizar cuando tengo que montar temas relacionados con practicas y procesos DevOps en diferentes empresas.

Azure Architecture Center es una web donde encontraremos de forma centralizada guías, procedimientos recomendados, buenas prácticas y patrones para diseño de soluciones arquitectónicas en Microsoft Azure para todo tipo de aplicaciones.

Link: https://docs.microsoft.com/es-es/azure/architecture

Recopilacion de Escenarios para Devops

Hay varias arquitecturas y soluciones de ejemplo relacionadas con DevOps que os pueden servir de guia o aceleradores para implementar proyectos sin tener que partir de cero, os comparto la lista:

• DevTest for PaaS solutions: https://docs.microsoft.com/azure/architecture/solution-ideas/articles/dev-test-paas
• DevTest for microservices: https://docs.microsoft.com/azure/architecture/solution-ideas/articles/dev-test-microservice
• DevTest Image Factory: https://docs.microsoft.com/es-es/azure/architecture/solution-ideas/articles/dev-test-image-factory
• Immutable infrastructure using Jenkins and Terraform on Azure: https://docs.microsoft.com/azure/architecture/solution-ideas/articles/immutable-infrastructure-cicd-using-jenkins-and-terraform-on-azure-virtual-architecture-overview
• DevOps in a hybrid environment: https://docs.microsoft.com/azure/architecture/solution-ideas/articles/java-cicd-using-jenkins-and-azure-web-apps
• Java CI/CD using Jenkins and Azure web apps: https://docs.microsoft.com/azure/architecture/solution-ideas/articles/java-cicd-using-jenkins-and-azure-web-apps
• Run a Jenkins server on Azure: https://docs.microsoft.com/azure/architecture/example-scenario/apps/jenkins
• SharePoint Farm for testing: https://docs.microsoft.com/azure/architecture/solution-ideas/articles/sharepoint-farm-devtest

Como siempre, espero que os sea de utilidad.

Azure: Configurando SonarQube en Azure Container Instances (ACI) para evaluar calidad del código fuente

5 de diciembre de 20205 de diciembre de 2020 Santimacnet Azure Cloud Solutions, DevOps aci, azure

Hoy quiero comentar un caso de uso que suelo utilizar para evaluar y medir de forma rápida la calidad del código fuente de proyectos sin necesidad de montar un servidor centralizado de SonarQube y tener que administrarlo.

Antes de nada, una aclaración, este escenario que explico no es válido para entornos de producción, ya que, si por algún motivo detenemos o reiniciamos el contenedor perderemos toda la información guardada de los proyectos de SonarQube, en este contexto, estamos ejecutando un contenedor donde no usamos ningún tipo de persistencia de la información en volúmenes o BBDD.

Se trata de utilizar el servicio Azure Container Instances (ACI) para desplegar un contenedor de SonarQube en apenas 3 minutos donde subir el análisis y reporting del código fuente para tener feedback rápido de la deuda técnica que podemos encontrar generalmente en proyectos legacy o de terceros que tenemos que mantener o evolucionar en clientes.

Para ello, utilizaremos la consola con AZ CLI y los siguientes comandos para crear un recurso ACI con 2 CPUs y 4 MB:

_{$ RG=rg-SonarQubeDemo-ne
$ LOCATION=northeurope
$ ACI_NAME=aci-sonarqube
$ SONARQUBE_IMAGE=sonarqube 
$ SONARQUBE_PORT=9000
$ SONARQUBE_FQDN=santi-sonarprueba 
$ az group create --name $RG --location $LOCATION
$ az container create --resource-group $RG 
--name $ACI_NAME --cpu 2 --memory 4 
--image $SONARQUBE_IMAGE --ports $SONARQUBE_PORT --dns-name-label $SONARQUBE_FQDN 
- Running ..}

Esperamos un minuto que se publique el contenedor de SonarQube en el servicio ACI y ya lo tenemos funcionando, veremos el mensaje de Running… y la respuesta al finalizar el proceso.

Si ahora en Azure Portal buscamos el grupo de recursos rg-SonarQubeDemo-ne veremos el servicio aci-sonarqube que hemos creado, si entramos dentro del recurso, podemos visualizar su descripción general con la información de su IP publica y FQDN que podéis ver en la captura.

Para visitar nuestro SonarQube, podemos abrirlo directamente desde un navegador en la ruta: http://santi-sonarprueba.northeurope.azurecontainer.io:9000

Para acceder, hacemos Login con el usuario y password: admin y admin que viene configurado por defecto que no permitirá entrar en la interfaz para crear y configurar proyectos en SonarQube.

Si queremos analizar un proyecto típico de .NET y C#, simplemente en el apartado de Projects, creamos uno nuevo siguiendo los pasos, le damos el nombre santi-demo, generamos el token y elegimos el código fuente donde nos dará las instrucciones que tenemos que ejecutar en nuestro entorno local para ejecutar el análisis con el SonarScanner y tener las métricas disponibles en SonarQube.

Encontrareis toda la información detallada aquí: SonarScanner for MSBuild

Hemos visto lo fácil y rápido que podemos disponer de un entorno SonarQube operativo para nuestras pruebas de calidad de código.

Como siempre, espero que os sea de utilidad para vuestros proyectos.

Docker: Error during connect: Post http://pipe-docker_engine/ v1.40/auth:open//./pipe/docker_engine en Windows10

26 de julio de 202027 de julio de 2020 Santimacnet DevOps, Docker

Un problema común que sucede trabajando con Docker desde un equipo local ocurre cuando intentamos conectarnos con Docker Hub para subir o descargar imágenes a la hora de realizar Login desde nuestro equipo con Windows 10.

Si accedéis directamente en https://hub.docker.com con Login y Password correcto podéis entrar sin problemas en la plataforma de Docker Hub pero si realizamos lo mismo desde la consola de comandos con docker login aparece el error.

PS> docker login

Login with your Docker ID to push and pull images from Docker Hub. If you don’t have a Docker ID, head over to https://hub.docker.com to create one.
Username: **************
Password: ************
error during connect: Post http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.40/auth: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.

Opciones para solucionarlo

Si vemos los detalles del error nos da algunas pistas indicando como podemos solucionarlo, para ello comparto una serie de pasos que utilizo para arreglarlo:

Verificar que el usuario y password no se haya cambiado en DockerHub y no coincida con nuestras credenciales Docker actuales.
Verificar que no se realizo acceso a otro registro de imágenes como Azure Container Registry (ACR) y conectados con el user correspondiente.
Detener el icono de Docker en la barra de notificaciones de Windows 10.
Detener y arrancar de nuevo el servicio de docker en Windows 10.
Ejecutar docker con permisos de administrador en vuestro equipo.
Revisar en la barra de notificaciones de Windows10 que el icono de Docker no este bloqueado o reiniciando.
Revisar la configuración avanzada de Docker y la unidad C tenerla compartida para vuestros contenedores.

Como reiniciar los servicios de Docker

Para reiniciar Docker, recordar que se ejecuta como un servicio más de Windows10 tenemos varias opciones.

1) Desde el Administrador de tareas, eliminando la tarea de Docker Desktop.

2) Desde la pantalla de Servicios de Windows, reiniciando el servicio Docker for Windows Service.

3) También desde Powershell en modo administrador con los comandos:

PS> NET STOP com.docker.service
El servicio de Docker Desktop Service está deteniéndose.
El servicio de Docker Desktop Service se detuvo correctamente.

PS> NET START com.docker.service
El servicio de Docker Desktop Service está iniciándose.
El servicio de Docker Desktop Service se ha iniciado correctamente.

Verificando Docker

Una revisado todo lo anterior la mejor forma de asegurarnos que todo funciona bien es verificar que podemos conectarnos al DockerHub para descargar la imagen de Docker Hello World!!

PS> docker login

Login with your Docker ID to push and pull images from Docker Hub. If you don’t have a Docker ID, head over to https://hub.docker.com to create one.
Username: ************
Password:*************
Login Succeeded

PS> docker run hello-world

Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete Digest: sha256:49a1c8800c94df04e9658809b006fd8a686cab8028d33cfba2cc049724254202
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the «hello-world» image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/

Happy Docking!!

Azure DevOps: Como desactivar Pipelines con sintaxis YAML para no dispararse en cada commit

7 de junio de 202012 de junio de 2020 Santimacnet Azure DevOps (VSTS), DevOps

Un caso que sucede a veces en Azure DevOps cuando estamos definiendo procesos de integración continua con código YAML, es saber como podemos desactivar Pipelines de CI/CD para que no se ejecuten de forma automática cada vez que se hace un commit en el repo Git.

Como sabéis, al crear una nueva pipeline Azure DevOps, el asistente nos crea por defecto un archivo azure-pipelines.yml para definir nuestra build con una plantilla base para automatizar todo el proceso.

Pipelines YAML intro image

Dentro de la plantilla, podemos editar el código YAML para adaptarlo los jobs, step y task a nuestros procesos de CI/CD y en la primera linea del archivo encontramos la etiqueta de trigger: – master

Desactivando el trigger en YAML

Ya en el archivo YAML, el trigger indica que dispara la build en master de forma automática, lo normal es comentarlo o borrarlo para que no se ejecute la próxima vez.

# Docker
# Build and push an image to Azure Container Registry
# https://docs.microsoft.com/azure/devops/pipelines/languages/docker

# desactivar trigger automatico CI
# trigger:
# - master

resources:
- repo: self

variables:
....

Pero, si hacemos el commit y confirmamos los cambios en Git se vuelve a disparar la build aunque tengamos el trigger comentado o borrado.

Desactivando el trigger en Pipeline Settings

Una forma de evitar que se dispare la build, es mediante la opción de Settings de la propia Pipeline, si entramos en esta opción accederemos a un formulario donde podemos seleccionar lo siguiente:

Por último, no olvidar guardar los cambios pulsando el botón Save en la pantalla.

Desactivando el trigger en Pipeline clásico

Otra forma, un poco más escondida de desactivar el pipeline es pulsando EDIT para entrar en las opciones del pipeline clásico como se muestra en la imagen y después seleccionar en el menú los 3 puntos (…) y la opción Trigger para navegar al menu de pipeline clásico.

Por último, no olvidar guardar los cambios pulsando el desplegable y seleccionar Save en la pantalla.

Un consejo final, yo también suelo modificar el nombre del pipeline y le añado el sufijo [disabled] para identificarlo.

Como siempre, espero que os sea de utilidad!!

Docker: OCI runtime exec failed: exec failed: container_linux.go: starting container process caused accediendo al contenedor y como solucionarlo

6 de May de 20206 de May de 2020 Santimacnet DevOps, Docker

Muchas veces publicamos un contenedor en entornos de producción y necesitamos entrar dentro para revisar alguna configuración o archivos desplegados, un ejemplo típico, tenemos un contenedor utilizando un NGINX con aplicaciones Angular o React, y necesitamos realizar algún ajuste o inspección sobre la marcha antes de volver a generar la imagen desde el principio y volver a desplegarla.

El caso es que depende sobre que versión de Linux se ha construido la imagen y el sistema operativo que estemos usando Windows o Linux la forma de entrar al contenedor cambia y aparece el error que se muestra en el titulo del post.

Por ejemplo, si entro a un contenedor Alpine Linux con estos comandos no funciona, trabajando desde Windows y Visual Studio Code.

docker exec -it a800000000 /bin/bash
OCI runtime exec failed: exec failed: container_linux.go: starting container process caused «exec: \»C:/Program Files/Git/usr/bin/bash\»: stat C:/Program Files/Git/usr/bin/bash: no such file or directory»: unknown

docker exec -it a800000000 /bin/sh
OCI runtime exec failed: exec failed: container_linux.go: starting container process caused «exec: \»C:/Program Files/Git/usr/bin/sh\»: stat C:/Program Files/Git/usr/bin/sh: no such file or directory»: unknown

Como solucionarlo para acceder al contenedor

La forma de solucionarlo dependerá del contexto donde estemos trabajando para entrar al contenedor os comparto las diferentes alternativas que utilizo normalmente.

En Windows desde consola utilizar el siguiente comando:

c:\> docker exec -it a800000000 //bin//sh

c:\> docker exec -it a800000000 //bin//bash

En Visual Studio Code desde terminal con la consola Git Bash:

$ winpty docker exec -it a800000000 //bin//sh

$ winpty docker exec -it a800000000 //bin//bash

En Linux utilizar el siguiente comando:

$ sudo docker exec -it a800000000 //bin//sh

$ sudo docker exec -it a800000000 //bin//bash

Happy Docking!!

Kubernetes: Workshop (AKS)

20 de marzo de 201931 de May de 2019 Santimacnet Azure Cloud Solutions, DevOps, Kubernetes / AKS

Hoy, quiero compartir un excelente workshop de AKS, el servicio gestionado de Kubernetes en Azure que cubre los aspectos más importantes a la hora de aprender a trabajar con un orquestador desde cero, donde aprenderéis a usar contenedores para «dockerizar» las aplicaciones y después desplegarlas dentro del clúster mediante Azure DevOps usando procesos de CI/CD para finalmente conocer como monitorizar y escalar el sistema dentro de Kubernetes.

Para realizar el workshop es necesario tener conocimientos previos de Azure, DevOps, Contenedores y Kubernetes.

Enlace: https://aksworkshop.io

Que lo disfrutéis!!

DevOps Spain 2019

1 de marzo de 201915 de May de 2019 Santimacnet DevOps

El pasado 28 de Febrero se celebro el DevOps Spain 2019, organizado por mi empresa atSistemas, con un enfoque técnico y de negocio del mundo DEVOPS, donde disfrutamos de los mejores ponentes nacionales/internacionales con la participación de empresas como Microsoft, AWS, Oracle, IBM, RedHat, GitHub, Mango entre otras.

Aquí estuvimos con otros compañeros haciendo Networking al final del evento:

devops-spain-foto1

Y con todo el equipo organizador al final del dia

devops-spain-foto2

Los mejores momentos de DevOps Spain 2019

Todos los videos de las charlas

Los videos de las charlas estan publicados en el canal atSistemas Youtube

Que los disfrutéis !!

DevOps: Application Insights for Developers

15 de enero de 201911 de julio de 2019 Santimacnet DevOps

Application Insights es el APM que ofrece Microsoft en plataforma Azure para monitorizar y supervisar la disponibilidad, el rendimiento y el uso de aplicaciones web, también se puede utilizar con otros tipos de aplicaciones para identificar y diagnosticar rápidamente errores sin esperar a que un usuario los reporte.

Application Insights, es útil para muchos roles desde Developers, DevOps, IT Pro y negocio, ya que, recopila toda la información que envian las aplicaciones sobre su rendimiento para facilitar tomar decisiones informadas, que se pueden integrar con otras plataformas como PowerBI o Excel para mantener, mejorar su aplicación y análisis de datos de los usuarios entre otras muchas cosas.

En este articulo, hoy veremos la parte más orientada a Developers y tiene que ver con el API REST que ofrece Application Insights, donde integrar, consultar y recopilar datos para nuestras aplicaciones.

La encontramos en este link: https://dev.applicationinsights.io y disponemos de todas estas opciones:

En concreto, a parte de la documentación donde encontramos como usar el API REST para trabajar con ella, tenemos la parte más interesante en el API Explorer: https://dev.applicationinsights.io/apiexplorer/metrics donde podemos realizar llamadas REST y probar sin necesidad de programar código para empezar a obtener métricas de uso.

Tutoriales y Documentación

Para concluir, os comparto un link oficial de Microsoft donde vemos la integración con PowerBI para ver la potencia de todo este sistema funcinando: https://blogs.msdn.microsoft.com/charles_sterling/2017/10/24/using-power-bi-and-application-insights-rest-apis-to-gain-insight-into-your-application-health/

DevOps: Introducción al nuevo Azure DevOps

5 de enero de 201912 de junio de 2020 Santimacnet Azure DevOps (VSTS), DevOps

Para empezar el año, quiero compartir una serie de videos oficiales ofrecidos por el equipo de producto de Azure DevOps para conocer todas las novedades y potencia de esta plataforma y ver todas sus posibilidades.

Son videos introductorios que estan en Channel9, para comenzar a trabajar con Azure DevOps:

On-demand videos

Introduction to Azure DevOps

Building and Deploying your Code with Azure Pipelines

Continuous Builds with your GitHub projects using Azure Pipelines

Manage and store your code in Azure Repos

Automated and Manual Testing with Azure Test Plan

Plan your work with Azure Boards

Getting started with package management using Azure Artifacts

Introducing GitHub pull requests for Visual Studio Code

Como siempre que los disfruteis!!

DevOps: Blue/Green & Canary Deployment

12 de May de 201822 de junio de 2018 Santimacnet DevOps

A la hora de publicar nuestras aplicaciones y servicios en entornos de producción tenemos 2 formas de realizarlo: Blue/Green o Canary y un mismo objetivo, probar el software sobre una audiencia específica acotado en el tiempo, antes de lanzar la aplicación a todos los usuarios.

Veamos la idea en estos diagramas para entenderlo mejor.

Blue/Green Deployment: Desplegar todo a la vez

En este caso, se debe redirigir todo el tráfico a la vez entre entornos y se necesita duplicar la infraestructura para hacer el SWAP.

Canary Deployment: Desplegar de forma incremental

En este caso, se puede redirigir trafico entre las dos versiones a la vez y se puede reutilizar la misma infraestructura porque no hacemos SWAP.

devops-canary2

Otra ventaja importante en los dos casos, si algo falla con la nueva versión, la estrategia de reversión es simplemente redirigir a los usuarios a la versión anterior hasta que haya resuelto el problema.

Martin Fowler explica con todo detalle el proceso en estos 2 artículos:

BlueGreen:http://martinfowler.com/bliki/BlueGreenDeployment.html
Canary: http://martinfowler.com/bliki/CanaryRelease.html