Preparación de recursos técnicos de contenedor de Azure para una aplicación de Kubernetes

En este artículo se proporcionan recursos técnicos y recomendaciones para ayudarle a crear una oferta de contenedor en Azure Marketplace para una aplicación de Kubernetes.

Para obtener un ejemplo completo de los recursos técnicos necesarios para una oferta de contenedor basada en aplicaciones de Kubernetes, consulte ejemplos de ofertas de contenedor de Azure Marketplace para Kubernetes.

Conocimientos técnicos básicos

El diseño, la compilación y las pruebas de estos recursos lleva tiempo y requiere conocimientos técnicos de la plataforma de Azure y las tecnologías que se usan para crear la oferta.

Además del dominio de la solución, el equipo de ingeniería debe tener conocimientos sobre las siguientes tecnologías de Microsoft:

• Conocimientos básicos de los Servicios de Azure.
• Cómo diseñar y estructurar las aplicaciones de Azure.
• Conocimientos prácticos de Azure Resource Manager.
• Conocimientos prácticos de JSON
• Conocimientos prácticos de Helm.
• Conocimientos prácticos de createUiDefinition
• Conocimientos prácticos de plantillas de Azure Resource Manager (ARM).

Requisitos previos

• La aplicación debe estar basada en gráficos de Helm.

• Si tiene varios gráficos, puede incluir otros gráficos de Helm como subgráficos aparte del gráfico de Helm principal.

• Todas las referencias de imagen y los detalles de resumen deben incluirse en el gráfico. No se pueden descargar otros gráficos ni imágenes en tiempo de ejecución.

• Debe tener un inquilino de publicación activo o acceso a un inquilino de publicación y a una cuenta del Centro de partners.

• Debe haber creado una instancia de Azure Container Registry (ACR) que pertenezca al inquilino de publicación activo anterior. Cargará la agrupación de aplicaciones nativas en la nube (CNAB) en ella. Para más información, consulte Creación de una instancia de Azure Container Registry.

• Instalar la versión más reciente de la CLI de Azure.

• La aplicación debe poder implementarse en el entorno de Linux.

• Las imágenes deben estar libres de vulnerabilidades. Para más información sobre el examen de vulnerabilidades, consulte Evaluaciones de vulnerabilidades de Azure con Administración de vulnerabilidades de Microsoft Defender.

• Si ejecuta la herramienta de empaquetado manualmente, Docker debe instalarse en una máquina local. Para obtener más información, consulte la sección back-end de WSL 2 en la documentación de Docker para Windows o Linux. Esto solo se admite en máquinas Linux/Windows AMD64.

Limitaciones

• El marketplace de contenedor solo admite imágenes AMD64 basadas en la plataforma Linux.
• Solo AKS administrado.
• No se admiten contenedores únicos.
• No se admiten plantillas vinculadas de Azure Resource Manager.

Introducción a la publicación

El primer paso para publicar la oferta de contenedor basada en aplicaciones de Kubernetes en Azure Marketplace consiste en empaquetar la aplicación como un lote de aplicaciones nativas en la nube (CNAB). El CNAB, formado por los artefactos de la aplicación, se publica primero en azure Container Registry (ACR) privado y, posteriormente, se inserta en un ACR público propiedad de Microsoft y se usa como el único artefacto al que hace referencia en el Centro de partners.

Ahí se realiza el examen de vulnerabilidades para asegurarse de que las imágenes son seguras. Por último, la aplicación de Kubernetes se registra como un tipo de extensión para un clúster de Azure Kubernetes Service (AKS).

Una vez publicada la oferta, la aplicación aprovecha las extensiones de clúster para la característica de AKS para administrar el ciclo de vida de la aplicación dentro de un clúster de AKS.

Concesión de acceso a la instancia de Azure Container Registry.

Como parte del proceso de publicación, Microsoft copia en profundidad el CNAB de su ACR en un ACR específico de Azure Marketplace de Microsoft. Las imágenes se cargan en un registro público al que se puede acceder a todas. Este paso requiere que conceda acceso a Microsoft al registro. El ACR debe estar en el mismo inquilino de Microsoft Entra que esté vinculado a su cuenta del Centro de partners.

Microsoft tiene una aplicación de primera entidad responsable de controlar este proceso con un id de 32597670-3e15-4def-8851-614ff48c1efa. Para empezar, cree una entidad de servicio basada en la aplicación:

Linux

Nota:

Si su cuenta no tiene permisos suficientes para crear una entidad de servicio, az ad sp create devuelve un mensaje de error que contiene el texto "Privilegios insuficientes para completar la operación". Póngase en contacto con el administrador de Microsoft Entra para crear una entidad de servicio.

az login

Compruebe si ya existe una entidad de servicio para la aplicación:

az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa 

Si el comando anterior no devuelve ningún resultado, cree una nueva entidad de servicio:

az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa

Anote el identificador de la entidad de servicio que se usará en los pasos siguientes.

A continuación, obtenga el identificador completo del registro:

az acr show --name <registry-name> --query "id" --output tsv

La salida debe tener una apariencia similar a la siguiente:

...
},
"id": "/subscriptions/ffffffff-ff6d-ff22-77ff-ffffffffffff/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

A continuación, cree una asignación de roles para conceder a la entidad de servicio la capacidad de extraer del registro con los valores obtenidos anteriormente:

Para asignar roles de Azure, es necesario tener:

• Permisos Microsoft.Authorization/roleAssignments/write, como Administrador de acceso de usuarios o Propietario

az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull

Por último, registre el proveedor de recursos Microsoft.PartnerCenterIngestion en la misma suscripción usada para crear el Azure Container Registry:

az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait

Supervise el registro y confirme que se ha completado antes de continuar:

az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>

Windows

Nota:

Si su cuenta no tiene permisos suficientes para crear una entidad de servicio, New-AzADServicePrincipal devuelve un mensaje de error que contiene el texto "Privilegios insuficientes para completar la operación". Póngase en contacto con el administrador de Microsoft Entra para crear una entidad de servicio.

Connect-AzAccount

Compruebe si ya existe una entidad de servicio para el identificador de aplicación:

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App" 

Si el comando anterior no devuelve ningún resultado, cree una nueva entidad de servicio:

New-AzADServicePrincipal -ApplicationId 32597670-3e15-4def-8851-614ff48c1efa

Obtenga el identificador del objeto de la entidad de servicio:

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App"

Anote el identificador de la entidad de servicio que se usará en los pasos siguientes.

A continuación, obtenga el identificador completo del registro:

Select-AzSubscription -SubscriptionId <subscriptionId>
Get-AzContainerRegistry -ResourceGroupName <resource-group> -Name <registry-name>

La salida debe tener una apariencia similar a la siguiente:

...
},
"id": "/subscriptions/ffffffff-ff6d-ff22-77ff-ffffffffffff/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

A continuación, cree una asignación de roles para conceder a la entidad de servicio la capacidad de extraer del registro:

Para asignar roles de Azure, es necesario tener:

• Permisos Microsoft.Authorization/roleAssignments/write, como Administrador de acceso de usuarios o Propietario

New-AzRoleAssignment -ObjectId <sp-id> -Role acrpull -Scope <registry-id>

Por último, registre el proveedor de recursos Microsoft.PartnerCenterIngestion en la misma suscripción usada para crear el Azure Container Registry:

Connect-AzAccount
Select-AzSubscription -SubscriptionId <subscription-id>
Register-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

Supervise el registro y confirme que se ha completado antes de continuar:

Get-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

Recopilación de artefactos para cumplir los requisitos de formato de paquete

Cada CNAB se compone de los siguientes artefactos:

• Gráfico de Helm
• CreateUiDefinition
• Plantilla de ARM
• Archivo de manifiesto

Actualización del gráfico de Helm

Asegúrese de que el gráfico de Helm cumpla las reglas siguientes:

• Todos los nombres y referencias de imagen se parametrizan y se representan en values.yaml como referencias global.azure.images. Actualice el archivo deployment.yaml de plantilla de gráfico de Helm para que apunte estas imágenes. Esto garantiza que el bloque de imágenes se pueda actualizar para hacer referencia a las imágenes de ACR de Azure Marketplace.

• Si tiene varios gráficos, puede incluir otros gráficos de Helm como subgráficos aparte del gráfico de Helm principal. A continuación, actualice cada una de las referencias de imagen dependientes para que apunten a las imágenes incluidas en el gráfico values.yamlprincipal.

• Al hacer referencia a imágenes, puede usar etiquetas o resúmenes. Sin embargo, es importante tener en cuenta que las imágenes se vuelven a etiquetar internamente para que apunten a Azure Container Registry (ACR) propiedad de Microsoft. Al actualizar una etiqueta, se debe enviar una nueva versión de CNAB a Azure Marketplace. Esto es para que los cambios se puedan reflejar en las implementaciones de clientes.

  

Modelos de facturación disponibles

Para todos los modelos de facturación disponibles, consulte las opciones de licencia para aplicaciones de Azure Kubernetes.

Realización de actualizaciones basadas en el modelo de facturación

Después de revisar los modelos de facturación disponibles, seleccione uno adecuado para su caso de uso y complete los pasos siguientes:

Complete los pasos siguientes para agregar el identificador en los modelos de facturación por núcleo, por pod y por nodo :

• Agregue una etiqueta azure-extensions-usage-release-identifier de identificador de facturación a la especificación de pod en los archivos yaml de carga de trabajo .

  • Si la carga de trabajo se especifica como Deployments o Replicasets o Statefulsets o Daemonsets especificaciones, agregue esta etiqueta en .spec.template.metadata.labels.

  • Si la carga de trabajo se especifica directamente como especificaciones de pod, agregue esta etiqueta en .metadata.labels.

    

    

    

    

• Para el modelo de facturación de perCore , especifique solicitud de CPU mediante la inclusión del resources:requests campo en el manifiesto de recursos del contenedor. Este paso solo es necesario para el modelo de facturación por núcleo .

  

En el momento de la implementación, la característica de extensiones de clúster reemplaza el valor del identificador de facturación por el nombre de la instancia de extensión.

Para ver ejemplos configurados para implementar la aplicación de votación de Azure, consulte lo siguiente:

• Ejemplo de archivo de implementación.
• Ejemplo de archivo de valores.

Para el modelo de facturación de medidores personalizados, agregue los campos que se enumeran a continuación en el archivo values.yaml de la plantilla de Helm.

• clientId debe agregarse en global.azure.identity
• la clave planId debe agregarse en global.azure.marketplace. planId
• resourceId debe agregarse en global.azure.extension.resrouceId.

En el momento de la implementación, la característica de extensiones de clúster reemplaza estos campos por los valores adecuados. Para obtener ejemplos, consulte la aplicación basada en medidores personalizados de Azure Vote.

Creación de un archivo de parámetros de prueba

Un archivo de parámetros de prueba es un JSON que se usa junto con una plantilla de ARM para implementar un recurso en Azure. En el caso de las aplicaciones o extensiones que se pueden implementar en clústeres administrados (AKS), es necesario especificar el archivo de parámetros para la validación de implementación. El archivo de parámetros de prueba debe incluir valores que permitirían una implementación de prueba correcta.

Nota:

No todos los parámetros deben incluirse en el archivo de parámetros, solo los parámetros que no tienen un valor predeterminado. Para obtener instrucciones, consulte aquí.

Este es un archivo de parámetros de prueba de ejemplo:

Una vez creado el archivo de parámetros de prueba, agréguelo al archivo de manifiesto:

Nota:

En situaciones en las que un archivo de parámetros de prueba no sería aplicable a la aplicación (por ejemplo, la aplicación requiere secretos para implementar como una clave de API o implementaciones de aplicaciones en clústeres conectados), se proporciona una marca skipdeployment para permitir omitir las pruebas de implementación.

Validación del gráfico de Helm

Para asegurarse de que el gráfico de Helm es válido, pruebe que se puede instalar en un clúster local. También puede usar helm install --generate-name --dry-run --debug para detectar determinados errores de generación de plantillas.

Creación y prueba de createUiDefinition

Un archivo createUiDefinition es un archivo JSON que define los elementos de la interfaz de usuario para Azure Portal al implementar la aplicación. Para más información, vea:

• CreateUiDefinition.json para Azure
• o vea un ejemplo de una definición de interfaz de usuario que solicita datos de entrada para una elección de clúster nueva o existente y pasa parámetros a la aplicación.

Después de crear el archivo createUiDefinition.json para la aplicación, debe probar la experiencia del usuario. Para simplificar las pruebas, copie el contenido del archivo en el entorno de espacio aislado. El espacio aislado presenta la interfaz de usuario en la experiencia del portal actual y en pantalla completa. El espacio aislado es la manera recomendada de obtener una vista previa de la interfaz de usuario.

Creación de plantillas de Azure Resource Manager (ARM)

Una plantilla de ARM define los recursos de Azure que se van a implementar. De forma predeterminada, implementará un recurso de extensión de clúster para la aplicación de Azure Marketplace. Opcionalmente, puede optar por implementar un clúster de AKS.

Actualmente solo se permiten los siguientes tipos de recursos:

• Microsoft.ContainerService/managedClusters
• Microsoft.KubernetesConfiguration/extensions

Por ejemplo, consulte esta plantilla de ARM de ejemplo diseñada para tomar resultados de la definición de interfaz de usuario de ejemplo vinculada anteriormente y pasar parámetros a la aplicación.

Flujo de parámetros de usuario

Es importante saber cómo fluyen los parámetros de usuario por los artefactos que va a crear y empaquetar. En el ejemplo de aplicación de votación de Azure, los parámetros se definen inicialmente al crear la interfaz de usuario a través de un archivo createUiDefinition.json :

Los parámetros se exportan a través de la outputs sección :

Desde allí, los valores se pasan a la plantilla de Azure Resource Manager y se propagan al gráfico de Helm durante la implementación:

Por último, los valores se pasan al gráfico de Helm, values.yaml como se muestra.

Nota:

En este ejemplo, extensionResourceName también se parametriza y se pasa al recurso de extensión de clúster. De forma similar, se pueden parametrizar otras propiedades de la extensión, como habilitar la actualización automática para versiones secundarias. Para más información sobre las propiedades de la extensión de clúster, consulte parámetros opcionales.

Creación del archivo de manifiesto

El manifiesto del paquete es un archivo yaml que describe el paquete y su contenido, e indica a la herramienta de empaquetado dónde buscar los artefactos dependientes.

Los campos usados en el manifiesto son los siguientes:

Nombre	Tipo de datos	Descripción
applicationName	Cadena	Nombre de la aplicación
publisher	Cadena	Nombre del publicador
descripción	Cadena	Descripción breve del paquete
version	Cadena en formato #.#.#	Cadena de versión que describe la versión del paquete de aplicación, podría o no coincidir con la versión de los archivos binarios que contiene.
helmChart	Cadena	Directorio local donde se puede encontrar el gráfico de Helm con respecto a este manifest.yaml
clusterARMTemplate	Cadena	Ruta de acceso local donde se puede encontrar una plantilla de ARM que describa un clúster de AKS que cumpla los requisitos en el campo de restricciones.
uiDefinition	Cadena	Ruta de acceso local en la que se puede encontrar un archivo JSON que describe una experiencia de creación de Azure Portal
registryServer	Cadena	La instancia de ACR donde se debe insertar la agrupación CNAB final.
extensionRegistrationParameters	Collection	Especificación de los parámetros de registro de extensión. Incluya al menos defaultScope y como parámetro.
defaultScope	Cadena	Ámbito predeterminado para la instalación de la extensión. Los valores aceptados son cluster o namespace. Si se establece el ámbito cluster, solo se permite una instancia de extensión por clúster. Si se selecciona el ámbito namespace, solo se permite una instancia por espacio de nombres. Como un clúster de Kubernetes puede tener varios espacios de nombres, pueden existir varias instancias de extensión.
espacio de nombres	Cadena	(Opcional) Especifique el espacio de nombres en el que se instala la extensión. Esta propiedad se usa cuando defaultScope se establece en cluster. Para conocer las restricciones de nomenclatura de espacios de nombres, consulte Espacios de nombres y DNS.
supportedClusterTypes	Collection	(Opcional) Especifique los tipos de clúster admitidos por la aplicación. Los tipos permitidos son: "managedClusters", "connectedClusters". "managedClusters" hace referencia a clústeres de Azure Kubernetes Service (AKS). "connectedClusters" hace referencia a los clústeres de Kubernetes habilitados para Azure Arc. Si no se proporciona supportedClusterTypes, todas las distribuciones de "managedClusters" se admiten de forma predeterminada. Si se proporciona supportedClusterTypes y no se proporciona un tipo de clúster de nivel superior determinado, todas las distribuciones y versiones de Kubernetes para ese tipo de clúster se tratan como no compatibles. Para cada tipo de clúster, especifique una lista de una o varias distribuciones con las siguientes propiedades: -distribución - distributionSupported - nosupportedVersions
distribution	List	Matriz de distribuciones correspondientes al tipo de clúster. Proporcione el nombre de distribuciones específicas. Establezca el valor en ["All"] para indicar que se admiten todas las distribuciones.
distributionSupported	Booleano	Valor booleano que representa si se admiten las distribuciones especificadas. Si es false, proporcionar UnsupportedVersions produce un error.
unsupportedVersions	List	Lista de versiones de las distribuciones especificadas que no son compatibles. Operadores admitidos: - No se admite la versión dada "=". Por ejemplo, "=1.2.12" - ">" No se admiten todas las versiones superiores a la versión especificada. Por ejemplo, ">1.1.13" - "<" No se admiten todas las versiones inferiores a la versión especificada. Por ejemplo, "<1.3.14" - "..." No se admiten todas las versiones del intervalo. Por ejemplo, "1.1.2...1.1.15" (incluye el valor del lado derecho y excluye el valor del lado izquierdo)

Para ver un ejemplo configurado para la aplicación de votación, consulte el siguiente ejemplo de archivo de manifiesto.

Estructura de la aplicación

Coloque el archivo createUiDefinition, la plantilla de ARM y el archivo de manifiesto junto al gráfico de Helm de la aplicación.

Para ver un ejemplo de un directorio estructurado correctamente, consulte ejemplo de Azure Vote.

Para ver un ejemplo de la aplicación de votación que admite clústeres de Kubernetes habilitados para Azure Arc, consulte Ejemplo de solo ConnectedCluster.

Para obtener un ejemplo de la aplicación de votación que admite clústeres de Azure Kubernetes Service (AKS) y clústeres de Kubernetes habilitados para Azure Arc, consulte Ejemplo de clústeres conectados y administrados.

Para más información sobre cómo configurar un clúster de Kubernetes habilitado para Azure Arc para validar la aplicación, consulte Inicio rápido: Conexión de un clúster de Kubernetes existente a Azure Arc.

Uso de la herramienta de empaquetado de contenedores

Una vez que haya agregado todos los artefactos necesarios, ejecute la herramienta de empaquetado container-package-app.

Dado que los CNAB son un nuevo formato y tienen una curva de aprendizaje, hemos creado una imagen de Docker para container-package-app con el entorno de arranque y las herramientas necesarias para ejecutar correctamente la herramienta de empaquetado.

Tiene dos opciones para usar la herramienta de empaquetado. Puede usarlo manualmente o integrarlo en una canalización de implementación.

Ejecución manual de la herramienta de empaquetado

La imagen más reciente de la herramienta de empaquetado se puede extraer de mcr.microsoft.com/container-package-app:latest.

El siguiente comando de Docker extrae la imagen de la herramienta de empaquetado más reciente y también monta un directorio.

Linux

Suponiendo ~\<path-to-content> que es un directorio que contiene el contenido que se va a empaquetar, el siguiente comando de Docker se monta ~/<path-to-content> /data en en el contenedor. Asegúrese de reemplazar ~/<path-to-content> por su propia ubicación de la aplicación.

docker pull mcr.microsoft.com/container-package-app:latest

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

Ejecute los siguientes comandos del shell de contenedor container-package-app. Asegúrese de reemplazar <registry-name> por el nombre de su instancia de ACR:

export REGISTRY_NAME=<registry-name>

az login 

az acr login -n $REGISTRY_NAME 

cd /data/<path-to-content>

Para autenticar ACR, hay dos opciones. Una opción es mediante el uso az login de como se muestra anteriormente y la segunda opción es a través de Docker mediante la ejecución docker login 'yourACRname'.azurecr.iode . Escriba el nombre de usuario y la contraseña (el nombre de usuario debe ser el nombre de ACR y la contraseña es la clave generada proporcionada en Azure Portal) y se ejecuta.

docker login <yourACRname.azurecr.io>

Windows

Suponiendo D:\<path-to-content> que es un directorio que contiene el contenido que se va a empaquetar, el siguiente comando de Docker se monta d:/<path-to-content> /data en en el contenedor. Asegúrese de reemplazar d:/<path-to-content> por su propia ubicación de la aplicación.

docker pull mcr.microsoft.com/container-package-app:latest

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v d:/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

A continuación, ejecute cpa verify para recorrer en iteración los artefactos y validarlos uno por uno. Solucione los errores y ejecute cpa buildbundle cuando esté todo preparado para empaquetar y cargar el CNAB en la instancia de Azure Container Registry. El cpa buildbundle comando también ejecuta el proceso de comprobación antes de compilar

cpa verify

cpa buildbundle 

Nota:

Use cpa buildbundle --force solo si desea sobrescribir una etiqueta existente. Si ya ha asociado este CNAB a una oferta de Azure Marketplace, incremente la versión en el archivo de manifiesto.

Integración en una instancia de canalización de Azure

Para obtener un ejemplo de cómo integrar container-package-app en una canalización de Azure, consulte el ejemplo de Azure Pipeline.

Solución de problemas

• Ayuda para solucionar problemas de empaquetado
• Ayuda para la solución de problemas de publicación

Contenido relacionado

• Creación de la oferta de Kubernetes