Implementación de contenedores en Azure

Hemos analizado los contenedores de este capítulo y en el capítulo 1. Hemos visto que los contenedores proporcionan muchas ventajas a las aplicaciones nativas de la nube, incluida la portabilidad. En la nube de Azure, puede implementar los mismos servicios en contenedores en entornos de ensayo y producción. Azure proporciona varias opciones para hospedar estas cargas de trabajo en contenedor:

• Azure Kubernetes Services (AKS)
• Azure Container Instance (ACI)
• Azure Aplicaciones Web para Contenedores

Azure Container Registry (Registro de Contenedores de Azure)

Al incluir en contenedores un microservicio, primero se compila un contenedor "image". La imagen es una representación binaria del código de servicio, las dependencias y el entorno de ejecución. Aunque puede crear manualmente una imagen mediante el Docker Build comando desde la API de Docker, un mejor enfoque es crearla como parte de un proceso de compilación automatizado.

Una vez creadas, las imágenes de contenedor se almacenan en registros de contenedor. Permiten compilar, almacenar y administrar imágenes de contenedor. Hay muchos registros disponibles, tanto públicos como privados. Azure Container Registry (ACR) es un servicio de registro de contenedor totalmente administrado en la nube de Azure. Conserva las imágenes dentro de la red de Azure, lo que reduce el tiempo para implementarlas en los hosts de contenedor de Azure. También puede protegerlos mediante los mismos procedimientos de seguridad e identidad que se usan para otros recursos de Azure.

Puede crear una instancia de Azure Container Registry mediante Azure Portal, la CLI de Azure o las herramientas de PowerShell. La creación de un registro en Azure es sencilla. Requiere una suscripción de Azure, un grupo de recursos y un nombre único. En la figura 3-10 se muestran las opciones básicas para crear un registro, que se hospedará en registryname.azurecr.io.

Figura 3-10. Crear un registro de contenedor

Una vez que haya creado el registro, deberá autenticarse con él para poder usarlo. Normalmente, iniciará sesión en el registro mediante el comando de la CLI de Azure:

az acr login --name *registryname*

Una vez autenticado, puede usar comandos de Docker para insertar imágenes de contenedor en él. Sin embargo, para poder hacerlo, debe etiquetar la imagen con el nombre completo (URL) del servidor de inicio de sesión de ACR. Tendrá el formato registryname.azurecr.io.

docker tag mycontainer myregistry.azurecr.io/mycontainer:v1

Después de etiquetar la imagen, use el docker push comando para insertar la imagen en la instancia de ACR.

docker push myregistry.azurecr.io/mycontainer:v1

Después de insertar una imagen en el registro, se recomienda quitar la imagen del entorno de Docker local mediante este comando:

docker rmi myregistry.azurecr.io/mycontainer:v1

Como procedimiento recomendado, no debe insertar manualmente imágenes en un registro de contenedor. En su lugar, use una canalización de compilación definida en una herramienta como GitHub o Azure DevOps. Obtenga más información en el capítuloCloud-Native DevOps.

Tareas de ACR

ACR Tasks es un conjunto de características disponibles en Azure Container Registry. Amplía el ciclo interno de desarrollo a través de la creación y administración de imágenes de contenedor en la nube de Azure. En lugar de invocar un docker build y un docker push localmente en tu máquina de desarrollo, son gestionados automáticamente por las tareas de ACR en la nube.

El siguiente comando de la CLI de AZ compila una imagen de contenedor e lo inserta en ACR:

# create a container registry
az acr create --resource-group myResourceGroup --name myContainerRegistry008 --sku Basic

# build container image in ACR and push it into your container registry
az acr build --image sample/hello-world:v1  --registry myContainerRegistry008 --file Dockerfile .

Como puede ver en el bloque de comandos anterior, no es necesario instalar Docker Desktop en la máquina de desarrollo. Además, puede configurar los desencadenadores de tareas de ACR para que recompilen imágenes de contenedores cuando se actualizan tanto el código fuente como las imágenes base.

Azure Kubernetes Service

En este capítulo se describe Azure Kubernetes Service (AKS). Hemos visto que es el orquestador de contenedores de hecho que administra aplicaciones nativas de nube contenedorizadas.

Una vez implementada una imagen en un registro, como ACR, puede configurar AKS para extraer e implementarla automáticamente. Con una canalización de CI/CD implementada, puede configurar una estrategia de versión controlada para minimizar el riesgo que conlleva implementar rápidamente actualizaciones. La nueva versión de la aplicación se configura inicialmente en producción sin tráfico que se enrute a ella. A continuación, el sistema enrutará un pequeño porcentaje de usuarios a la versión recién implementada. A medida que el equipo obtiene confianza en la nueva versión, puede implementar más instancias y retirar el antiguo. AKS admite fácilmente este estilo de implementación.

Al igual que con la mayoría de los recursos de Azure, puede crear un clúster de Azure Kubernetes Service mediante el portal, la línea de comandos o las herramientas de automatización como Helm o Terraform. Para empezar a trabajar con un nuevo clúster, debe proporcionar la siguiente información:

• Suscripción de Azure
• Grupo de recursos
• Nombre del clúster de Kubernetes
• Región
• Versión de Kubernetes
• Prefijo del nombre DNS
• Tamaño del nodo
• Recuento de nodos

Esta información es suficiente para empezar. Como parte del proceso de creación en Azure Portal, también puede configurar opciones para las siguientes características del clúster:

• Escala
• Autenticación
• Redes
• Monitorización
• Etiquetas

En este inicio rápido se explica cómo implementar un clúster de AKS mediante Azure Portal.

Azure Bridge to Kubernetes

Las aplicaciones nativas de la nube pueden crecer de forma grande y compleja, lo que requiere que se ejecuten recursos de proceso significativos. En estos escenarios, toda la aplicación no se puede hospedar en una máquina de desarrollo (especialmente un portátil). Azure Bridge to Kubernetes aborda la deficiencia. Permite a los desarrolladores trabajar con una versión local de su servicio mientras hospedan toda la aplicación en un clúster de desarrollo de AKS.

Cuando esté listo, los desarrolladores prueban sus cambios localmente mientras se ejecutan en la aplicación completa del clúster de AKS, sin replicar dependencias. En segundo plano, el puente combina el código de la máquina local con los servicios de AKS. Los desarrolladores pueden iterar rápidamente y depurar código directamente en Kubernetes usando Visual Studio o Visual Studio Code.

Gabe Monroy, ex vicepresidente de administración de productos en Microsoft, lo describe bien:

Imagine que es un nuevo empleado que intenta corregir un error en una aplicación compleja de microservicios que consta de docenas de componentes, cada uno con su propia configuración y servicios de respaldo. Para empezar, debe configurar el entorno de desarrollo local para que pueda imitar la producción, incluida la configuración del IDE, la cadena de herramientas de creación, las dependencias de servicio en contenedor, un entorno local de Kubernetes, los simulacros para los servicios de respaldo, etc. Con todo el tiempo implicado en la configuración del entorno de desarrollo, corregir ese primer error podría tardar días. O bien, podría usar Bridge to Kubernetes y AKS.