Utiliser Tanzu Build Service

Cet article s’applique à :❌ De base/Standard ✔️ Entreprise

Cet article vous montre comment utiliser VMware Tanzu Build Service avec le plan Azure Spring Apps Enterprise.

VMware Tanzu Build Service automatise la création, la gestion et la gouvernance des conteneurs à l’échelle de l’entreprise. Tanzu Build Service utilise le projet open source Cloud Native Buildpacks pour transformer le code source de l’application en images conteneur. Il exécute des builds reproductibles alignées sur les normes de conteneur modernes et maintient les images à jour.

Buildpacks

Les buildpacks VMware Tanzu fournissent une prise en charge de l’infrastructure et du runtime pour les applications. Les Buildpacks examinent généralement vos applications pour déterminer les dépendances à télécharger et la manière de configurer les applications pour qu’elles communiquent avec les services liés.

Les buildpacks de la famille de langues sont des buildpacks composites qui fournissent une prise en charge prête à l’emploi facile pour les runtimes de langage et les configurations d’application les plus populaires. Ces buildpacks combinent plusieurs buildpacks de composants dans des regroupements ordonnés. Les regroupements répondent aux exigences de chaque buildpack.

Générateurs

Un Générateur est une ressource Tanzu Build Service. Un générateur contient un ensemble de buildpacks et une pile utilisée dans le processus de création du code source.

Pool d’agents de build

Tanzu Build Service dans le plan d’entreprise est le point d’entrée pour conteneuriser les applications des utilisateurs à partir du code source et des artefacts. Un pool d’agents de build dédié réserve des ressources de calcul pour un nombre donné de tâches de génération simultanées. Le pool d’agents de build empêche la contention des ressources pour vos applications en cours d’exécution.

Le tableau suivant présente les tailles disponibles pour les jeux d’échelle du pool d’agents de construction :

Tanzu Build Service autorise au maximum une tâche de construction de la taille d’un pool à construire et deux fois les tâches de construction de la taille d’un pool à mettre en file d’attente. Si le quota du pool d’agents est insuffisant pour la tâche de génération, la requête de cette build obtient l’erreur suivante : The usage of build results in Building or Queuing status are (cpu: xxx, memory: xxxMi) and the remained quota is insufficient for this build. please retry with smaller size of build resourceRequests, retry after the previous build process completed or increased your build agent pool size.

Configurer le pool d’agents de build

Lorsque vous créez une nouvelle instance de service Azure Spring Apps Enterprise à l’aide du portail Azure, vous pouvez utiliser l’onglet Paramètres VMware Tanzu pour configurer le nombre de ressources attribuées au pool d’agents de construction.

L’image suivante montre les ressources attribuées au pool d’agents du service de construction Tanzu après le provisionnement réussi de l’instance de service. Vous pouvez également mettre à jour la taille du pool d’agents configuré ici après avoir créé l’instance de service.

Créer un service à la demande

Vous pouvez activer ou désactiver le service de construction lorsque vous créez une instance du plan Azure Spring Apps Enterprise.

Caractéristiques de construction et de déploiement

Par défaut, Tanzu Build Service est activé afin que vous puissiez utiliser un registre de conteneurs. Si vous désactivez le service de construction, vous ne pouvez déployer une application qu’avec une image de conteneur personnalisée. Les options suivantes s’offrent à vous :

• Activez le service de build et utilisez le registre de conteneurs managé Azure Spring Apps.

  Azure Spring Apps fournit un Azure Container Registry managé pour stocker des images générées pour vos applications. Vous ne pouvez exécuter la génération et le déploiement ensemble qu’en tant que seule commande, mais pas séparément. Vous pouvez utiliser les images conteneur générées pour déployer des applications dans la même instance de service uniquement. Les images ne sont pas accessibles par d’autres instances de service Azure Spring Apps Enterprise.

• Activez le service de build et utilisez votre propre registre de conteneurs.

  Ce scénario sépare la génération du déploiement. Vous pouvez exécuter des constructions à partir du code source d’une application ou d’artefacts vers une image de conteneur séparément du déploiement de l’application. Vous pouvez déployer les images de conteneurs stockées dans votre propre registre de conteneurs vers plusieurs instances de service Azure Spring Apps Enterprise.

• Désactivez le service de build.

  Lorsque vous désactivez le service de construction, vous ne pouvez déployer des applications qu’avec des images de conteneurs, que vous pouvez construire à partir de n’importe quelle instance de service Azure Spring Apps Enterprise.

Configurer les paramètres du service de construction

Vous pouvez configurer Tanzu Build Service et les paramètres du registre des conteneurs à l’aide du portail Azure ou de l’interface de ligne de commande Azure.

Déployer des applications polyglottes

Vous pouvez déployer des applications polyglottes dans une instance de service Azure Spring Apps Enterprise avec Tanzu Build Service activé ou désactivé. Pour plus d’informations, consultez Comment déployer des applications polyglottes dans Azure Spring Apps Entreprise.

Configurer l’intégration APM et les certificats d’autorité de certification

En utilisant les Buildpacks Tanzu Partner et le Buildpack CA Certificates, le plan Azure Spring Apps Enterprise offre une expérience de configuration simplifiée pour prendre en charge l’intégration de la surveillance du niveau de performance des applications (APM). Cette intégration inclut des scénarios d’intégration de certificats d’autorité de certification pour les applications polyglottes. Pour plus d’informations, consultez Comment configurer l’intégration APM et les certificats d’autorité de certification.

Journaux de génération en temps réel

Une tâche de construction est déclenchée lorsqu’une application est déployée à partir d’une commande Azure CLI. Les journaux de génération sont envoyés en streaming en temps réel dans le cadre de la sortie de commande CLI. Pour plus d’informations sur l’utilisation des journaux de génération pour diagnostiquer les problèmes, consultez Analyser les journaux et les métriques avec les paramètres de diagnostic.

Historique de build

Vous pouvez voir toutes les ressources de build dans la section Builds de la page Azure Spring Apps Build Service.

Le tableau de la section Builds contient les colonnes suivantes :

• Nom du build : Le nom du build.
• L’état d’approvisionnement : état d’approvisionnement de la build. Cette propriété peut prendre les valeurs Succeeded, Failed, Updating et Creating. Les états d’approvisionnement Updating et Creating signifient que la build ne peut pas être mise à jour tant que la build actuelle n’est pas terminée. L’état d’approvisionnement Failed signifie que votre dernière build de code source n’a pas pu générer un nouveau résultat de build.
• Quota de ressources : quota de ressources dans le pod de build de la build.
• Builder : Le générateur utilisé dans la build.
• dernier résultat de build : balise d’image de résultat de build la plus récente de la build.
• dernier état d’approvisionnement des résultats de build : état d’approvisionnement des résultats de build le plus récent. Cette propriété peut prendre les valeurs Queuing, Building, Succeeded et Failed.
• Dernière heure de transition du résultat de build : heure de la dernière transition pour le dernier résultat de build de la build.
• Dernière raison de la dernière transition du résultat de build : la dernière raison de la transition pour le dernier résultat de build de la build. Ces valeurs sont CONFIG, STACK et BUILDPACK. CONFIG signifie que le résultat de la génération est modifié par les mises à jour du générateur ou par une nouvelle opération de déploiement de code source. STACK signifie que le résultat de la build est modifié par une mise à niveau de pile. BUILDPACK signifie que le résultat de la build est modifié par une mise à niveau buildpack.
• Dernière raison de la dernière transition du résultat de build : le dernier statut de la transition pour le dernier résultat de build de la build. Les valeurs possibles sont True et False.

Pour ’état d’approvisionnement, lorsque la valeur est Failed, déployez à nouveau le code source. Si l’erreur persiste, ouvrez un ticket de support.

Pour dernier état d’approvisionnement des résultats de build, lorsque la valeur est Failed, vérifiez les journaux de génération. Pour plus d’informations, voir Dépannage des problèmes de construction courants dans Azure Spring Apps.

Pour l’état de la dernière transition du résultat de la dernière build, lorsque la valeur est Failed, voir la colonne Raison de la dernière transition du résultat de la dernière build. Si la raison est BUILDPACK ou STACK, aucune action n’est nécessaire. Si la raison est CONFIG, déployez à nouveau le code source. Si l’erreur persiste, ouvrez un ticket de support.

Étapes suivantes

• Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification