Préparer des ressources techniques de conteneur Azure pour une application Kubernetes
Cet article fournit des ressources et recommandations techniques pour vous aider à créer une offre de conteneur sur la Place de marché Azure pour une application Kubernetes.
Pour obtenir un exemple complet des ressources techniques requises pour une offre de conteneur basé sur une application Kubernetes, consultez Exemples d’offres de conteneur pour Kubernetes de la Place de marché Azure.
Connaissances techniques fondamentales
Concevoir, créer et tester ces ressources demande du temps et des connaissances techniques sur la plateforme Azure et les technologies utilisées pour créer l’offre.
En plus du domaine de votre solution, votre équipe d'ingénierie doit connaître les technologies Microsoft suivantes :
- Connaissances de base des services Azure
- Comment concevoir et créer des applications Azure
- Expérience de travail avec Azure Resource Manager
- Expérience de travail avec JSON
- Connaissance pratique de Helm
- Connaissance pratique de createUiDefinition
- Connaissance pratique des Modèles Azure Resource Manager (ARM)
Prérequis
Votre application doit être basée sur un graphique Helm.
Le graphique Helm ne doit pas inclure de
.tgzfichiers d’archivage ; tous les fichiers doivent être décompressés.Si vous avez plusieurs graphiques, vous pouvez inclure d’autres graphiques helm en tant que sous-graphiques en dehors du graphique helm principal.
L’ensemble des références d’image et détails de synthèse doivent être inclus dans le graphique. Aucun autre graphique ou image ne peut être téléchargé lors de l’exécution.
Vous devez disposer d’un locataire de publication actif ou d’un accès à un locataire de publication et à un compte d’Espace partenaires.
Vous devez avoir créé un Registre de conteneurs Azure (ACR) qui appartient au locataire de publication actif ci-dessus. Vous allez charger l’offre groupée d’applications natives cloud (CNAB) vers celle-ci. Pour plus d’informations, consultez Créer un Registre de conteneurs Azure.
Installez la dernière version d’Azure CLI.
L’application doit pouvoir être déployée dans un environnement Linux.
Les images doivent être exemptes de vulnérabilités. Pour obtenir des conseils sur la spécification des exigences d’analyse des vulnérabilités, consultez Résoudre les problèmes de certification de conteneur. Pour en savoir plus sur l’analyse des vulnérabilités, consultez les évaluations des vulnérabilités pour Azure avec Gestion des vulnérabilités Microsoft Defender.
Si vous exécutez l’outil d’empaquetage manuellement, Docker doit être installé sur un ordinateur local. Pour plus d’informations, consultez la section back-end WSL 2 dans la documentation Docker pour Windows ou Linux. Cela est uniquement pris en charge dans les machines Linux/Windows AMD64.
Limites
- La Place de marché de conteneur ne prend en charge que des images AMD64 basées sur la plateforme Linux.
- L’offre De la Place de marché de conteneurs prend en charge le déploiement sur AkS managé et Kubernetes avec Arc. Une offre unique ne peut cibler qu’un seul type de cluster, managé AKS ou Kubernetes avec Arc.
- Les offres pour les clusters Kubernetes avec Arc prennent uniquement en charge les modèles de facturation prédéfinis. Pour plus d’informations sur les modèles de facturation, consultez Planifier une offre Azure Container.
- Les conteneurs uniques ne sont pas pris en charge.
- Les modèles Azure Resource Manager liés ne sont pas pris en charge.
Présentation de la publication
La première étape pour publier sur la Place de marché Azure votre offre de conteneur basé sur une application Kubernetes consiste à empaqueter votre application en tant qu’offre groupée d’applications natives cloud (CNAB). Le CNAB, composé des artefacts de votre application, est d’abord publié sur votre Registre de conteneurs Azure privé (ACR), puis envoyé (push) à un ACR public appartenant à Microsoft, et est utilisé comme seul artefact que vous référencez dans l’Espace partenaires.
À partir de là, l’analyse des vulnérabilités est effectuée pour garantir la sécurité des images. Enfin, l’application Kubernetes est inscrite en tant que type d’extension pour un cluster Azure Kubernetes Service (AKS).
Une fois votre offre publiée, votre application tire parti des extensions de cluster pour la fonctionnalité AKS pour gérer le cycle de vie de votre application à l’intérieur d’un cluster AKS.
Donner accès à votre Azure Container Registry
Dans le cadre du processus de publication, Microsoft copie en profondeur votre CNAB de votre ACR vers un ACR appartenant à Microsoft, Place de marché Azure spécifique à ACR. Les images sont chargées dans un registre public accessible à tous. Cette étape requiert que vous accordiez à Microsoft l’accès à votre registre. L’ACR doit se trouver dans le même locataire Microsoft Entra lié à votre compte Espace partenaires.
Microsoft dispose d’une application tierce responsable de la gestion de ce processus avec un id de 32597670-3e15-4def-8851-614ff48c1efa. Pour commencer, créez un principal de service basé sur l’application :
Remarque
Si votre compte n’a pas l’autorisation de créer un principal de service, az ad sp create retourne un message d’erreur contenant « Privilèges insuffisants pour effectuer l’opération ». Contactez votre administrateur Microsoft Entra pour créer un principal de service.
az login
Vérifiez si un principal de service existe déjà pour l’application :
az ad sp show --id 32597670-3e15-4def-8851-614ff48c1efa
Si la commande précédente ne retourne aucun résultat, créez un principal de service :
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa
Notez l’ID du principal de service, que vous utiliserez dans les étapes suivantes.
Ensuite, obtenez l’ID complet de votre registre :
az acr show --name <registry-name> --query "id" --output tsv
Votre résultat doit être semblable à ce qui suit :
...
},
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...
Ensuite, créez une attribution de rôle pour accorder au principal de service la possibilité d’extraire des éléments de votre registre à l’aide des valeurs que vous avez obtenues précédemment :
Pour attribuer des rôles Azure, vous devez disposer de :
- autorisations
Microsoft.Authorization/roleAssignments/write, telles que Administrateur de l’accès utilisateur ou Propriétaire
az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull
Enfin, inscrivez le fournisseur de ressources Microsoft.PartnerCenterIngestion sur l’abonnement que vous avez utilisé pour créer l’Azure Container Registry :
az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait
Surveillez l’inscription et vérifiez qu’elle est terminée avant de continuer :
az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>
Collecter les artefacts pour répondre aux exigences en matière de format de package
Chaque CNAB est composé des artefacts suivants :
- Graphique Helm
- CreateUiDefinition
- Modèle ARM
- Fichier manifeste
Mettre à jour le graphique Helm
Assurez-vous que le graphique Helm respecte les règles suivantes :
Tous les noms et références d’images sont paramétrés et représentés dans
values.yamlen tant que références global.azure.images. Mettez à jour votre fichier de modèledeployment.yamlde graphique Helm pour pointer ces images. Cela garantit que le bloc d’images peut être mis à jour pour référencer les images ACR de Place de marché Azure.
Si vous avez plusieurs graphiques, vous pouvez inclure d’autres graphiques helm en tant que sous-graphiques en dehors du graphique helm principal. Toutes les références d’images
values.yamlde graphique helm dépendantes auront besoin de mises à jour et doivent pointer vers les images incluses dans le graphique principal.Lorsque vous référencez des images, vous pouvez utiliser des balises ou des synthèses. Toutefois, il est important de noter que les images sont retaguées en interne pour pointer vers azure Container Registry (ACR) appartenant à Microsoft. Lorsque vous mettez à jour une balise, une nouvelle version du CNAB doit être envoyée au Place de marché Azure. Cela permet de refléter les modifications dans les déploiements des clients.
Modèles de facturation disponibles
Pour tous les modèles de facturation disponibles, reportez-vous aux options de licence pour les applications Azure Kubernetes.
Effectuer des mises à jour en fonction de votre modèle de facturation
Après avoir examiné les modèles de facturation disponibles, sélectionnez-en un approprié pour votre cas d’usage et effectuez les étapes suivantes :
Effectuez les étapes suivantes pour ajouter l’identificateur dans les modèles de facturation par cœur, par pod, par nœud :
Ajoutez une étiquette
azure-extensions-usage-release-identifierd’identificateur de facturation à la spécification pod dans vos fichiers yaml de charge de travail .Si la charge de travail est spécifiée en tant que spécifications Deployments ou Replicasets ou Statefulsets ou Daemonsets, ajoutez cette étiquette sous .spec.template.metadata.labels.
Si la charge de travail est spécifiée directement en tant que spécifications pod, ajoutez cette étiquette sous .metadata.labels.
Pour le modèle de facturation perCore , spécifiez la demande d’UC en incluant le
resources:requestschamp dans le manifeste de ressource de conteneur. Cette étape n’est requise que pour le modèle de facturation parCore .
Au moment du déploiement, la fonctionnalité d’extensions de cluster remplace la valeur de l’identificateur de facturation par le nom de l’instance d’extension.
Pour obtenir des exemples configurés pour déployer l’application de vote Azure, consultez les rubriques suivantes :
Pour le modèle de facturation des compteurs personnalisés, ajoutez les champs répertoriés ci-dessous dans le fichier values.yaml de votre modèle Helm.
- clientId doit être ajouté sous global.azure.identity
- La clé planId doit être ajoutée sous global.azure.marketplace. planId
- resourceId doit être ajouté sous global.azure.extension.resrouceId
Au moment du déploiement, la fonctionnalité d’extensions de cluster remplace ces champs par les valeurs appropriées. Pour obtenir des exemples, consultez l’application Azure Vote Custom Meters.
Valider le graphique Helm
Pour vérifier que le graphique Helm est valide, testez la possibilité de l’installer sur un cluster local. Vous pouvez également utiliser helm install --generate-name --dry-run --debug pour détecter certaines erreurs de génération de modèle.
Créer et tester le fichier createUiDefinition
Le fichier JSON createUiDefinition définit les éléments d’interface utilisateur du portail Azure lors du déploiement de l’application. Pour plus d’informations, consultez l’article suivant :
ou consultez un exemple de définition d’interface utilisateur qui demande des données d’entrée pour un choix de cluster nouveau ou existant et transmet des paramètres à votre application.
Après avoir créé le fichier createUiDefinition.json pour votre application, vous devez tester l’expérience utilisateur. Pour simplifier les tests, copiez le contenu de votre fichier dans l’environnement de bac à sable. Le bac à sable présente votre interface utilisateur dans l’actuelle expérience du portail en plein écran. Le bac à sable est la méthode recommandée pour afficher un aperçu de l’interface utilisateur.
Créer le modèle Azure Resource Manager (ARM)
Un modèle ARM définit les ressources Azure à déployer. Par défaut, vous allez déployer une ressource d’extension de cluster pour l’application Place de marché Azure. Si vous le souhaitez, vous pouvez choisir de déployer un cluster AKS.
Actuellement, nous n’autorisons que les types de ressources suivants :
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
Par exemple, consultez cet exemple de modèle ARM conçu pour obtenir les résultats de l’exemple de définition d’interface utilisateur lié précédemment et transmettre des paramètres à votre application.
Flux de paramètres utilisateur
Il est important de comprendre comment les paramètres utilisateur circulent dans les artefacts que vous créez et empaquetez. Dans l’exemple d’application de vote Azure, les paramètres sont initialement définis lors de la création de l’interface utilisateur via un fichier createUiDefinition.json :
Les paramètres sont exportés via la outputs section :
À partir de là, les valeurs sont passées au modèle Azure Resource Manager et sont propagées au graphique Helm pendant le déploiement :
Enfin, les valeurs sont passées dans le graphique values.yaml Helm, comme indiqué.
Remarque
Dans cet exemple, extensionResourceName est également paramétré et passé à la ressource d’extension de cluster. De même, d’autres propriétés d’extension peuvent être paramétrées, comme l’activation de la mise à niveau automatique pour les versions mineures. Pour plus d’informations sur les propriétés d’extension de cluster, consultez Paramètres facultatifs.
Créer un fichier manifest
Le manifeste du package est un fichier yaml qui décrit le package et son contenu, et indique à l’outil d’empaquetage où trouver les artefacts dépendants.
Les champs utilisés dans le manifeste sont les suivants :
| Name | Type de données | Description |
|---|---|---|
| applicationName | Chaîne | Nom de l’application |
| publisher | Chaîne | Nom de l’éditeur |
| description | Chaîne | Brève description du package |
| version | Chaîne au format #.#.# |
Chaîne de version qui décrit la version du package d’application, peut ou non correspondre à la version des fichiers binaires à l’intérieur. |
| helmChart | Chaîne | Répertoire local dans lequel se trouve le graphique Helm par rapport à ce manifest.yaml |
| clusterARMTemplate | Chaîne | Chemin d’accès local d’un modèle ARM décrivant un cluster AKS répondant aux exigences du champ de restrictions |
| uiDefinition | Chaîne | Chemin d’accès local d’un fichier JSON décrivant une expérience de création sur le portail Azure |
| registryServer | Chaîne | ACR auquel envoyer (push) la CNAB finale |
| extensionRegistrationParameters | Collection | Spécification des paramètres d’inscription d’extension. Incluez au moins defaultScope en tant que paramètre. |
| defaultScope | Chaîne | Étendue par défaut de votre installation d’extension. Les valeurs acceptées sont cluster ou namespace. Si l’étendue cluster est définie, une seule instance d’extension est autorisée par cluster. Si l’étendue namespace est sélectionnée, une seule instance est autorisée par espace de noms. Un cluster Kubernetes pouvant avoir plusieurs espaces de noms, plusieurs instances d’extension peuvent exister. |
| espace de noms | Chaîne | (Facultatif) Spécifiez l’espace de noms dans où l’extension est installée. Cette propriété est requise quand defaultScope a la valeur cluster. Pour connaître les restrictions de nommage des espaces de noms, consultez Espaces de noms et DNS. |
| supportedClusterTypes | Collection | (Facultatif) Spécifiez les types de cluster pris en charge par l’application. Les types autorisés sont : « managedClusters », « connectedClusters ». « managedClusters » fait référence aux clusters Azure Kubernetes Service (AKS). « connectedClusters » fait référence aux clusters Kubernetes avec Azure Arc. Si supportedClusterTypes n’est pas fourni, toutes les distributions de « managedClusters » sont prises en charge par défaut. Si supportedClusterTypes est fourni et qu’un type de cluster de niveau supérieur donné n’est pas fourni, toutes les distributions et versions de Kubernetes pour ce type de cluster sont traitées comme non prises en charge. Pour chaque type de cluster, spécifiez une liste d’une ou plusieurs distributions avec les propriétés suivantes : -distribution - distributionSupported - unsupportedVersions |
| distribution | Liste | Tableau de distributions correspondant au type de cluster. Indiquez le nom des distributions spécifiques. Définissez la valeur sur ["All"] pour indiquer que toutes les distributions sont prises en charge. |
| distributionSupported | Boolean | Valeur booléenne qui indique si les distributions spécifiées sont prises en charge. Si la valeur est false, la fourniture d’UnsupportedVersions provoque une erreur. |
| unsupportedVersions | Liste | Liste des versions pour les distributions spécifiées qui ne sont pas prises en charge. Opérateurs pris en charge : - « = » La version donnée n’est pas prise en charge. Par exemple, « =1.2.12 » - «> » Toutes les versions supérieures à la version donnée ne sont pas prises en charge. Par exemple, «> 1.1.13 » - «< » Toutes les versions inférieures à la version donnée ne sont pas prises en charge. Par exemple, «< 1.3.14 » - "..." Toutes les versions de la plage ne sont pas prises en charge. Par exemple, « 1.1.2...1.1.15 » (inclut la valeur de droite et exclut la valeur de gauche) |
Pour obtenir un exemple configuré pour l’application de vote, consultez l’exemple de fichier manifeste suivant.
Structurer votre application
Placez le fichier createUiDefinition, le modèle ARM et le fichier manifeste à côté du graphique Helm de votre application.
Pour obtenir un exemple d’annuaire correctement structuré, consultez l’exemple Azure Vote.
Pour obtenir un exemple d’application de vote qui prend en charge les clusters Kubernetes avec Azure Arc, consultez l’exemple ConnectedCluster uniquement .
Pour plus d’informations sur la configuration d’un cluster Kubernetes avec Azure Arc pour la validation de l’application, consultez Démarrage rapide : Connecter un cluster Kubernetes existant à Azure Arc.
Utiliser l’outil d’empaquetage de conteneur
Une fois que vous avez ajouté tous les artefacts requis, exécutez l’outil container-package-app d’empaquetage pour valider les artefacts, générer le package et charger le package dans Azure Container Registry.
Étant donné que les CNAB sont un nouveau format et que nous avons une courbe d’apprentissage, nous avons créé une image Docker pour container-package-app laquelle l’environnement et les outils de démarrage sont nécessaires pour exécuter correctement l’outil d’empaquetage.
Vous avez deux options pour utiliser l’outil d’empaquetage. Vous pouvez l’utiliser manuellement ou l’intégrer dans un pipeline de déploiement.
Exécuter manuellement l’outil d’empaquetage
Vous pouvez extraire l’image la plus récente de l’outil d’empaquetage à partir de mcr.microsoft.com/container-package-app:latest.
La commande Docker suivante extrait l’image la plus récente de l’outil d’empaquetage et monte un répertoire.
En supposant qu’il s’agit ~\<path-to-content> d’un répertoire contenant le contenu à empaquetage, la commande Docker suivante monte ~/<path-to-content> dans /data le conteneur. Veillez à remplacer ~/<path-to-content> par l’emplacement de votre propre application.
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
Exécutez les commandes suivantes dans l’interpréteur de commandes du conteneur container-package-app. Veillez à remplacer <registry-name> par le nom de votre ACR :
export REGISTRY_NAME=<registry-name>
az login
az acr login -n $REGISTRY_NAME
cd /data/<path-to-content>
Pour authentifier l’ACR, il existe deux options. Une option consiste à utiliser az login comme indiqué précédemment, et la deuxième option est via Docker en exécutant docker login 'yourACRname'.azurecr.io. Entrez votre nom d’utilisateur et votre mot de passe (le nom d’utilisateur doit être votre nom ACR et le mot de passe est la clé générée fournie dans Portail Azure) et exécutez-le.
docker login <yourACRname.azurecr.io>
Ensuite, exécutez-les cpa verify pour itérer dans les artefacts et les valider un par un et résolvez les défaillances. Exécutez cpa buildbundle quand vous êtes prêt à empaqueter et à charger le CNAB dans votre Azure Container Registry. La cpa buildbundle commande exécute le processus de vérification, génère le package et charge le package dans azure Container Registry.
cpa verify
cpa buildbundle
Remarque
Utilisez cpa buildbundle --force uniquement si vous souhaitez remplacer une étiquette existante. Si vous avez déjà attaché ce CNAB à une offre de Place de marché Azure, incrémentez plutôt la version dans le fichier manifeste.
Intégrer dans un pipeline Azure
Pour obtenir un exemple d’intégration container-package-app dans un pipeline Azure, consultez l’exemple Azure Pipeline
Dépannage
- Aide sur la résolution des problèmes liés à l’empa
- Aide sur la publication de résolution des problèmes