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.

• 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.

• Vous devez avoir installé 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 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.
• AKS managé uniquement.
• 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 :

Linux

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/ffffffff-ff6d-ff22-77ff-ffffffffffff/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>

Windows

Remarque

Si votre compte n’a pas l’autorisation de créer un principal de service, New-AzADServicePrincipal 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.

Connect-AzAccount

Vérifiez si un principal de service existe déjà pour l’ID d’application :

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App" 

Si la commande précédente ne retourne aucun résultat, créez un principal de service :

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

Obtenez l’ID du principal du service :

Get-AzADServicePrincipal -SearchString "Container Marketplace Package App"

Notez l’ID du principal de service, que vous utiliserez dans les étapes suivantes.

Ensuite, obtenez l’ID complet de votre registre :

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

Votre résultat doit être semblable à ce qui suit :

...
},
"id": "/subscriptions/ffffffff-ff6d-ff22-77ff-ffffffffffff/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 :

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

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

Enfin, inscrivez le fournisseur de ressources Microsoft.PartnerCenterIngestion sur l’abonnement que vous avez utilisé pour créer l’Azure Container Registry :

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

Surveillez l’inscription et vérifiez qu’elle est terminée avant de continuer :

Get-AzResourceProvider -ProviderNamespace Microsoft.PartnerCenterIngestion

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.yaml en tant que références global.azure.images. Mettez à jour votre fichier de modèle deployment.yaml de 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. Mettez ensuite à jour chacune de vos références d’images values.yamldépendantes pour 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-identifier d’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:requests champ 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 :

• Exemple de fichier de déploiement.
• Exemple de fichier de valeurs.

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.

Créer un fichier de paramètres de test

Un fichier de paramètres de test est un JSON utilisé conjointement avec un modèle ARM pour déployer une ressource sur Azure. Pour les applications ou extensions qui peuvent être déployées sur des clusters managés (AKS), nous avons besoin que le fichier de paramètres soit spécifié pour la validation du déploiement. Le fichier de paramètres de test doit inclure des valeurs qui permettent un déploiement de test réussi.

Remarque

Tous les paramètres ne doivent pas être inclus dans le fichier de paramètres, mais uniquement les paramètres qui n’ont pas de valeur par défaut. Pour obtenir des conseils, reportez-vous ici.

Voici un exemple de fichier de paramètres de test :

Une fois le fichier de paramètres de test créé, ajoutez-le à votre fichier manifeste :

Remarque

Dans les cas où un fichier de paramètres de test ne serait pas applicable à votre application (par exemple : l’application nécessite des secrets pour le déploiement comme une clé API ou une application déployée sur des clusters connectés), un indicateur skipdeployment est fourni pour vous permettre d’ignorer les tests de déploiement.

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 :

• CreateUiDefinition.json pour Azure
• 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’expérience actuelle du portail 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/managedClusters
• Microsoft.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	List	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	List	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 Connecter edCluster uniquement .

Pour obtenir un exemple d’application de vote qui prend en charge les clusters Azure Kubernetes Service (AKS) et les clusters Kubernetes avec Azure Arc, consultez l’exemple Connecter ed et Managed Cluster.

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 vers Azure Arc.

Utiliser l’outil d’empaquetage de conteneur

Une fois que vous avez ajouté tous les artefacts requis, exécutez l’outil d’empaquetage container-package-app.

É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.

Linux

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>

Windows

En supposant qu’il s’agit D:\<path-to-content> d’un répertoire contenant le contenu à empaquetage, la commande Docker suivante monte d:/<path-to-content> dans /data le conteneur. Veillez à remplacer d:/<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 d:/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

Ensuite, exécutez cpa verify pour itérer dans les artefacts et les valider un par un. Résolvez les échecs et exécutez cpa buildbundle lorsque vous êtes prêt à empaqueter et charger la CNAB sur votre Azure Container Registry. La cpa buildbundle commande exécute également le processus de vérification avant la génération

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

Étapes suivantes

• Créer votre offre Kubernetes