Implementación de eShopOnContainers 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.
La aplicación eShopOnContainers se puede implementar en varias plataformas de Azure. El enfoque recomendado es implementar la aplicación en Azure Kubernetes Services (AKS). Para reducir la complejidad de la implementación se puede usar Helm, una herramienta de implementación de Kubernetes. Opcionalmente, a fin de simplificar el proceso de desarrollo, los desarrolladores pueden implementar Azure Dev Spaces para Kubernetes.
Azure Kubernetes Service
Para hospedar eShop en AKS, el primer paso consiste en crear un clúster de AKS. Para ello, puede usar Azure Portal, que le guiará por los pasos necesarios. También puede crear un clúster a partir de la CLI de Azure, teniendo cuidado de habilitar el control de acceso basado en roles (RBAC) y el enrutamiento de aplicaciones. En la documentación de eShopOnContainers se detallan los pasos necesarios para crear un clúster de AKS. Una vez que lo haya creado, podrá acceder al clúster y administrarlo desde el panel de Kubernetes.
Ahora puede implementar la aplicación eShop en el clúster mediante Helm.
Implementación en Azure Kubernetes Service mediante Helm
Helm es una herramienta de administrador de paquetes de aplicaciones que funciona directamente con Kubernetes. Le ayuda a definir, instalar y actualizar aplicaciones de Kubernetes. Aunque es posible implementar aplicaciones sencillas en AKS mediante scripts de la CLI personalizados o archivos de implementación simples, las aplicaciones complejas pueden contener muchos objetos de Kubernetes y beneficiarse de Helm.
Con Helm, las aplicaciones incluyen archivos de configuración basados en texto, denominados gráficos de Helm, que describen de manera declarativa la aplicación y la configuración en paquetes de Helm. Los gráficos usan archivos con formato YAML estándar para describir un conjunto relacionado de recursos de Kubernetes. Se crean versiones de estos junto con el código de la aplicación que describen. Los gráficos de Helm pueden ser simples y complejos, según los requisitos de la instalación que describen.
Helm se compone de una herramienta cliente de línea de comandos, que consume gráficos de Helm e inicia comandos en un componente de servidor denominado Tiller. Tiller se comunica con la API de Kubernetes para garantizar el aprovisionamiento correcto de las cargas de trabajo contenedorizadas. Del mantenimiento de Helm se encarga Cloud Native Computing Foundation.
El siguiente archivo YAML presenta una plantilla de Helm:
apiVersion: v1
kind: Service
metadata:
name: {{ .Values.app.svc.marketing }}
labels:
app: {{ template "marketing-api.name" . }}
chart: {{ template "marketing-api.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
spec:
type: {{ .Values.service.type }}
ports:
- port: {{ .Values.service.port }}
targetPort: http
protocol: TCP
name: http
selector:
app: {{ template "marketing-api.name" . }}
release: {{ .Release.Name }}
Observe que la plantilla describe un conjunto dinámico de pares clave-valor. Cuando se invoca la plantilla, los valores que se incluyen entre llaves se extraen de otros archivos de configuración basados en YAML.
Encontrará los gráficos de Helm de eShopOnContainers en la carpeta /k8s/helm. En la figura 2-6 se muestra cómo se organizan los distintos componentes de la aplicación en una estructura de carpetas que Helm usa para definir e implementar implementaciones administradas.
Figura 2-6. Carpeta de Helm de eShopOnContainers.
Cada componente individual se instala mediante un comando helm install. eShop incluye un script para implementarlo todo que recorre en bucle los componentes y los instala mediante sus respectivos gráficos de Helm. El resultado es un proceso repetible, con la versión de la aplicación del control de código fuente, que cualquier persona del equipo puede implementar en un clúster de AKS con un comando de script de una línea.
Tenga en cuenta que la versión 3 de Helm elimina oficialmente la necesidad de disponer del componente de servidor Tiller. Aquí encontrará más información sobre esta mejora.
Azure Functions y Logic Apps (sin servidor)
El ejemplo de eShopOnContainers incluye compatibilidad con el seguimiento de campañas de marketing en línea. Se usa una instancia de Azure Functions para realizar un seguimiento de los detalles de la campaña de marketing de un identificador de campaña determinado. Una única instancia de Azure Functions es suficiente y más sencilla que la creación de un microservicio completo. Azure Functions tiene un modelo de compilación e implementación sencillo, especialmente cuando está configurado para ejecutarse en Kubernetes. La implementación de la función se genera mediante scripts con plantillas de Azure Resource Manager (ARM) y la CLI de Azure. Este servicio de campaña no está orientado al cliente e invoca una sola operación, lo que lo convierte en un excelente candidato para el uso de Azure Functions. La función requiere una configuración mínima, incluida la de los datos de la cadena de conexión de base de datos y la configuración del URI base de la imagen. Azure Functions puede configurarse en Azure Portal.
