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.
L’ensemble des références d’image et détails de synthèse doivent être inclus dans le graphique. Aucun graphique ou image supplémentaire ne peut être téléchargé au moment 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 Azure Container Registry (ACR) dans lequel vous allez charger l’offre groupée d’applications natives cloud (CNAB), et accordé à l’ID d’application Microsoft principale l’autorisation d’accéder à votre ACR. Pour plus d’informations, consultez Créer un Azure Container Registry.
Vous devez avoir installé la dernière version d’Azure CLI.
L’application doit pouvoir être déployée dans un environnement Linux.
Si vous exécutez l’outil d’empaquetage CNAB manuellement, vous aurez besoin de Docker installé sur votre ordinateur local.
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.
Important
L’expérience d’offre basée sur une applications Kubernetes est en préversion. Les fonctionnalités en préversion sont disponibles en libre-service et font l’objet d’un consentement. Les préversions sont fournies « en l’état » et « en fonction des disponibilités », et sont exclues des contrats de niveau de service et de la garantie limitée. Les préversions sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production.
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). Cette CNAB, constituée des artefacts de votre application, sera d’abord publiée sur votre Azure Container Registry (ACR) privé, puis envoyée à un ACR appartenant à Microsoft, et utilisée comme unique 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 disposera des Extensions de cluster pour 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 effectuera une copie complète de votre CNAB à partir de votre ACR vers un ACR spécifique de la Place de marché Azure appartenant à Microsoft. Cette étape requiert que vous accordiez à Microsoft l’accès à votre registre.
Microsoft a créé une application propriétaire responsable de la gestion de ce processus, dont l’id est 32597670-3e15-4def-8851-614ff48c1efa. Pour commencer, créez un principal de service basé sur l’application :
Notes
Si votre compte ne dispose pas d’autorisations pour 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 Azure Active Directory pour créer un principal de service.
az login
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 affecter des rôles Azure, vous devez disposer :
- Autorisations
Microsoft.Authorization/roleAssignments/write, telles que Administrateur de l’accès utilisateur ou Propriétaire de l’accès utilisateur
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ée 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 à jourdeployment.yamlpour pointer vers ces images. Cela garantit que le bloc d’images peut être mis à jour et référencé par l’ACR de la Place de marché Azure.
Si vous avez des sous-graphiques, extrayez le contenu sous les graphiques et mettez à jour chacune de vos références d’images dépendantes pour pointer vers les images incluses dans le
values.yamldu graphique principal.Les images doivent utiliser des synthèses plutôt que des étiquettes. Cela garantit que la génération de CNAB est déterministe.
Modèles de facturation disponibles
| Option de licence | Processus de transaction |
|---|---|
| Gratuit | Référencez votre offre gratuitement pour les clients. |
| Apportez votre propre licence (BYOL) | L’option BYOL (Apporter votre propre licence) permet à vos clients d’intégrer des licences logicielles existantes à Azure.* |
| Pour chaque cœur de cluster | Répertoriez votre offre Azure Container avec des tarifs facturés en fonction du nombre total de cœurs d’UC dans le cluster (signalés à la fréquence horaire). Vous fournissez le prix d’un cœur d’UC et nous allons incrémenter la tarification en fonction du nombre total de cœurs d’UC dans le cluster. |
| Par cœur | Répertoriez votre offre Azure Container avec la tarification facturée pour chaque cœur utilisé par l’instance d’extension de l’application Kubernetes (signalée à la fréquence horaire). Vous fournissez le prix d’un cœur de processeur et nous allons incrémenter la tarification en fonction des cœurs utilisés par l’instance d’application Kubernetes dans le cluster. |
| Par cluster | Répertoriez votre offre Azure Container avec la tarification facturée pour chaque instance de l’extension d’application Kubernetes sur le cluster (signalée à la fréquence horaire). Vous fournissez le prix d’une instance de l’application Kubernetes et nous allons incrémenter la tarification en fonction du nombre d’instances de l’application Kubernetes sur le cluster. |
| Par chaque nœud du cluster | Répertoriez votre offre Azure Container avec la tarification facturée en fonction du nombre total de nœuds dans le cluster (signalés à la fréquence horaire). Vous fournissez le prix d’un nœud dans le cluster et nous allons incrémenter la tarification en fonction de la taille du matériel dans le cluster. |
| Par nœud | Répertoriez votre offre Azure Container avec la tarification facturée pour chaque nœud sur lequel l’instance d’extension de l’application Kubernetes s’exécute (signalée à la fréquence horaire). Vous fournissez le prix d’un nœud dans le cluster et nous allons incrémenter la tarification en fonction du nombre de nœuds sur lesquels l’instance d’application Kubernetes s’exécute dans le cluster. |
| Par pod | Répertoriez votre offre Azure Container avec la tarification facturée pour chaque pod sur lequel l’instance d’extension de l’application Kubernetes s’exécute (signalée à la fréquence horaire). Vous fournissez le prix d’un nœud dans le cluster et nous incrémenterons la tarification en fonction du nombre de pods utilisés sur lesquels l’instance d’application Kubernetes s’exécute dans le cluster. |
- En tant qu’éditeur, vous prenez en charge tous les aspects de la transaction de licence logicielle, notamment la commande, l’exécution de celle-ci, sa mesure, sa comptabilisation et sa facturation, ainsi que son paiement et son encaissement.
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 procédez comme suit :
Effectuez les étapes suivantes pour ajouter un identificateur dans le modèle de facturation par cœur :
Ajoutez une étiquette d’identificateur de facturation et une demande de cœurs de processeur à votre fichier
deployment.yaml.
Ajoutez une valeur d’identificateur de facturation pour
global.azure.billingidentifierdansvalues.yaml.
Effectuez les étapes suivantes pour ajouter une étiquette d’identificateur de facturation dans le modèle de facturation Par pod et Par nœud :
- Ajoutez une étiquette
azure-extensions-usage-release-identifierd’identificateur de facturation à votredeployment.yamlfichier (sousÉtiquettes>de métadonnées>de modèle>).
Notez qu’au moment du déploiement, la fonctionnalité d’extensions de cluster remplacera la valeur de l’identificateur de facturation par le nom de type d’extension que vous fournissez lors de la configuration des détails du plan.
Pour obtenir des exemples configurés pour déployer l’application de vote Azure, consultez les rubriques suivantes :
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 CreateUiDefinition.json pour Azure ou regardez 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 le test, utilisez un environnement de bac à sable qui charge votre fichier dans le portail. Le bac à sable présente votre interface utilisateur dans l’expérience portail actuelle et 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. Vous allez déployer une ressource d’extension de cluster pour l’application de la 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, regardez cet exemple de modèle ARM conçu pour recueillir les résultats de l’exemple de définition d’interface utilisateur lié ci-dessus, et transmettre des paramètres à votre application.
Créer le fichier manifeste
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 :
| Nom | Type de données | Description |
|---|---|---|
| applicationName | String | Nom de l’application |
| publisher | String | Nom de l’éditeur |
| description | String | Brève description du package |
| version | Chaîne au format #.#.# |
La chaîne de version décrivant la version du package d’application peut ou non correspondre à la version des fichiers binaires que celui-ci contient. Mappé au champ de version de Porter |
| helmChart | String | Répertoire local dans lequel se trouve le graphique Helm par rapport à ce manifest.yaml |
| clusterARMTemplate | String | Chemin d’accès local d’un modèle ARM décrivant un cluster AKS répondant aux exigences du champ de restrictions |
| uiDefinition | String | Chemin d’accès local d’un fichier JSON décrivant une expérience de création sur le portail Azure |
| registryServer | String | 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 | String | É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 | String | (Facultatif) Spécifiez l’espace de noms dans lequel l’extension sera 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. |
Pour obtenir un exemple configuré pour l’application de vote, consultez l’exemple de fichier manifeste suivant.
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. Les paramètres sont initialement définis lors de la création de l’interface utilisateur via un fichier createUiDefinition.json :
Notes
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.
et sont exportés via la section outputs :
À partir de là, les valeurs sont transmises au modèle Azure Resource Manager et sont propagées au graphique Helm pendant le déploiement :
Enfin, les valeurs sont consommées par le graphique Helm :
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 de répertoire correctement structuré, consultez l’exemple de référentiel.
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 format généralement nouveau nécessitant un apprentissage, nous avons créé une image Docker pour container-package-app contenant l’environnement et les outils d’amorçage requis 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 que ~\<path-to-content> est un répertoire dans lequel se trouve le contenu à empaqueter, la commande Docker suivante monte ~/<path-to-content> sur /data dans 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>
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 commande cpa buildbundle exécute également le processus de vérification avant la génération.
cpa verify
cpa buildbundle
Notes
Utilisez cpa buildbundle --force uniquement si vous souhaitez remplacer une étiquette existante. Si vous avez déjà attaché cette CNAB à une offre de la Place de marché Azure, incrémentez plutôt la version dans le fichier manifeste.
Intégrer dans un pipeline Azure
Pour voir un exemple d’intégration de container-package-app dans un pipeline Azure, consultez Exemple de pipeline Azure.