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 :

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.

Diagramme montrant les trois étapes du traitement de l’offre groupée, passant de « Copier l’offre groupée dans un registre appartenant à Microsoft » à « Analyse des vulnérabilités », puis « Inscription de type d’extension ».

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 :

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.yaml en tant que références global.azure.images. Mettez à jour deployment.yaml pour 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.

    Capture d’écran d’un fichier deployment.yaml correctement mis en forme. Les références d’images paramétrées sont affichées, qui ressemblent au contenu de l’exemple de fichier deployment.yaml lié dans cet article.

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

    Capture d’écran d’un fichier values.yaml correctement mis en forme. Les images utilisent des synthèses. Le contenu ressemble à l’exemple de fichier values.yaml lié dans cet article.

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.

    Capture d’écran d’une étiquette d’identificateur de facturation correctement mise en forme dans un fichier deployment.yaml. Le contenu ressemble à celui de l’exemple de fichier depoyment.yaml lié dans cet article.

    Capture d’écran de demandes de ressources processeur dans un fichier deployment.yaml. Le contenu ressemble à l’exemple de fichier depoyment.yaml lié dans cet article.

  • Ajoutez une valeur d’identificateur de facturation pour global.azure.billingidentifier dans values.yaml.

    Capture d’écran d’un fichier values.yaml correctement mis en forme, montrant le champ Azure > billingIdentifier global>.

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-identifier d’identificateur de facturation à votre deployment.yaml fichier (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/managedClusters

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

Capture d’écran de l’exemple createUiDefinition lié dans cet article. Les définitions de ’value1’ et ’value2’ sont affichées.

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 :

Capture d’écran de l’exemple createUiDefinition lié dans cet article. Les lignes de sortie pour le titre de l’application, « value1 » et « value2 » sont affichées.

À partir de là, les valeurs sont transmises au modèle Azure Resource Manager et sont propagées au graphique Helm pendant le déploiement :

Capture d’écran de l’exemple de modèle Azure Resource Manager lié dans cet article. Sous « configurationSettings », les paramètres pour le titre de l’application, « value1 » et « value2 » sont affichés.

Enfin, les valeurs sont consommées par le graphique Helm :

Capture d’écran de l’exemple de graphique Helm lié dans cet article. Les valeurs de titre de l’application, « value1 » et « value2 » sont affichées.

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.

Étapes suivantes