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.
El gráfico de Helm no debe incluir
.tgzarchivos de archivo; todos los archivos deben desempaquetarse.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 obtener instrucciones sobre cómo especificar los requisitos de examen de vulnerabilidades, consulte Solución de problemas de certificación de contenedores. 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.
- La oferta de Container Marketplace admite la implementación en AKS administrado y Kubernetes habilitado para Arc. Una sola oferta solo puede tener como destino un tipo de clúster, ya sea Kubernetes administrado de AKS o Habilitado para Arc.
- Las ofertas para clústeres de Kubernetes habilitados para Arc solo admiten modelos de facturación predefinidos. Para más información sobre los modelos de facturación, consulte Planeamiento de una oferta de Azure Container.
- 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:
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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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>
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.yamlcomo referencias global.azure.images. Actualice el archivodeployment.yamlde 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. Todas las referencias de imagen de gráficos de Helm dependientes necesitarán actualizaciones y deben apuntar 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-identifierde 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:requestscampo 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:
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.
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:
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/managedClustersMicrosoft.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 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 container-package-app de empaquetado para validar los artefactos, compilar el paquete y cargar el paquete en Azure Container Registry.
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.
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>
A continuación, ejecute cpa verify para recorrer en iteración los artefactos y validarlos uno por uno y solucionar los errores. Ejecute cpa buildbundle cuando esté listo para empaquetar y cargar el CNAB en Azure Container Registry. El cpa buildbundle comando ejecuta el proceso de comprobación, compila el paquete y carga el paquete en Azure Container Registry.
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.