Implementación de contenedores en Azure
Sugerencia
Este contenido es un extracto del libro electrónico “Architecting Cloud Native .NET Applications for Azure” (Diseño de la arquitectura de aplicaciones .NET nativas en la nube para Azure), disponible en Documentos de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.
Hemos hablado de contenedores en este capítulo y en el capítulo 1. Hemos visto que los contenedores proporcionan muchas ventajas para las aplicaciones nativas de nube, como la portabilidad. En la nube de Azure, puede implementar los mismos servicios contenedorizados en entornos de ensayo y producción. Azure proporciona varias opciones para hospedar estas cargas de trabajo contenedorizadas:
- Azure Kubernetes Services (AKS)
- Instancia de Azure Container (ACI)
- Azure Web Apps for Containers
Azure Container Registry
Al contenedorizar un microservicio, primero se compila una "imagen" del contenedor. 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 comando Docker Build desde la API de Docker, una estrategia mejor es crearla como parte de un proceso de compilación automatizado.
Una vez creadas, las imágenes de contenedor se almacenan en los registros de contenedor. Estos registros 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 de implementación en los hosts de contenedor de Azure. También puede protegerlos mediante los mismos procedimientos de seguridad e identidad que se usan con otros recursos de Azure.
Puede crear una instancia de Azure Container Registry mediante Azure Portal, la CLI de Azure o herramientas de PowerShell. Crear un registro en Azure es sencillo. Hace falta una suscripción a 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
Cuando 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. El formato que tendrá es registryname.azurecr.io.
docker tag mycontainer myregistry.azurecr.io/mycontainer:v1
Después de etiquetar la imagen, use el comando docker push 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 quitarla 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. Más información en el capítulo sobre DevOps nativo de nube.
ACR Tasks
ACR Tasks es un conjunto de características disponibles en Azure Container Registry, que amplía el ciclo de desarrollo de bucle interno mediante la creación y administración de imágenes de contenedor en la nube de Azure. En lugar de invocar docker build y docker push localmente en la máquina de desarrollo, se controlan automáticamente en la nube mediante ACR Tasks.
El siguiente comando de la CLI de AZ compila una imagen de contenedor y la 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 por el bloque de comandos anterior, no es necesario instalar Docker Desktop en la máquina de desarrollo. Además, puede configurar desencadenadores de tarea de ACR para volver a generar imágenes de contenedor tanto en el código fuente como en las actualizaciones de imágenes base.
Azure Kubernetes Service
A lo largo de este capítulo, hemos hablado de Azure Kubernetes Service (AKS). Hemos visto que es el orquestador de contenedores de hecho que administra aplicaciones nativas de nube contenedorizadas.
Una vez que implemente una imagen en un registro, como ACR, puede configurar AKS para extraerla 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. Luego, el sistema enrutará un pequeño porcentaje de usuarios a la versión recién implementada. A medida que el equipo gane confianza en la nueva versión, pueden implementar más instancias y retirar la antigua. 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 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
- Resource group
- Nombre del clúster de Kubernetes
- Region
- 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
- Authentication
- Redes
- Supervisió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 considerables. En estos escenarios, la aplicación entera no se puede hospedar en una máquina de desarrollo (especialmente un portátil). Azure Bridge a Kubernetes soluciona la falta de compatibilidad. Permite a los desarrolladores trabajar con una versión local de su servicio mientras la aplicación entera se hospeda en un clúster de desarrollo de AKS.
Cuando están listos, los desarrolladores prueban sus cambios localmente mientras se ejecutan contra la aplicación completa del clúster de AKS, sin replicar las dependencias. En segundo plano, el puente combina el código de la máquina local con los servicios de AKS. Los desarrolladores pueden recorrer en iteración y depurar código rápidamente directamente en Kubernetes mediante Visual Studio o Visual Studio Code.
Gabe Monroy, exvicepresidente de administración de productos en Microsoft, lo describe bien:
Imagine que es un nuevo empleado que intenta corregir un error de 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 al de producción, como la configuración del IDE, la cadena de herramientas de creación, las dependencias de servicios contenedorizados, un entorno de Kubernetes local, los simulacros de los servicios de respaldo, etc. Con todo el tiempo que conlleva configurar el entorno de desarrollo, corregir ese primer error podría tardar días. También podría usar Bridge to Kubernetes y AKS.
