Comment déployer des applications polyglottes dans le plan Entreprise Azure Spring Apps

Remarque

Les plans Essentiel, Standard et Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce de mise hors service d’Azure Spring Apps.

Le plan de consommation standard et dédiée sera déconseillé à compter du 30 septembre 2024, avec un arrêt complet après six mois. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer le plan de consommation Standard et dédié Azure Spring Apps vers Azure Container Apps.

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

Cet article vous montre comment déployer des applications polyglottes dans le plan Azure Spring Apps Entreprise et comment ces applications polyglottes peuvent utiliser les fonctionnalités de service de build fournies par des buildpacks.

Prérequis

• Une instance de plan Azure Spring Apps Entreprise déjà approvisionnée. Pour plus d’informations, consultez Démarrage rapide : Générer et déployer des applications sur Azure Spring Apps à l’aide du plan Enterprise.
• Azure CLI version 2.45.0 ou ultérieure. Utilisez la commande suivante pour installer l’extension Azure Spring Apps : az extension add --name spring

Déployer des applications polyglottes dans une instance de service

Cette section s’applique à la création et au déploiement d’applications polyglottes lorsque le service de build est activé. Si vous désactivez le service de build, vous pouvez uniquement déployer des applications avec une image conteneur personnalisée. Vous pouvez créer votre propre image ou utiliser une image générée par une instance Azure Spring Apps Entreprise. Pour plus d’informations, consultez Déployer une application avec une image conteneur personnalisée.

Gérer les générateurs

Lorsque vous créez une instance Azure Spring Apps Entreprise, vous devez choisir un générateur par défaut dans l’un des buildpacks de famille de langage pris en charge suivants :

• Buildpack Java Azure pour VMware Tanzu
• Buildpack .NET Core pour VMware Tanzu
• Buildpack Go pour VMware Tanzu
• Buildpack Web Servers pour VMware Tanzu
• Buildpack Node.js pour VMware Tanzu
• Buildpack Python pour VMware Tanzu
• Buildpack Java Native Image pour VMware Tanzu
• Buildpack PHP pour VMware Tanzu

Pour plus d’informations, consultez Buildpacks de famille de langage pour VMware Tanzu.

Ces buildpacks prennent en charge la génération avec du code source ou des artefacts pour les applications Java, .NET Core, Go, fichiers statiques web, Node.js et Python. Vous pouvez également voir les versions buildpack lors de la création ou de l’affichage d’un générateur. Et vous pouvez créer un générateur personnalisé en spécifiant des buildpacks et une pile.

Tous les générateurs configurés dans une instance de service Azure Spring Apps sont répertoriés dans la page Service de build, comme illustré dans la capture d’écran suivante :

Sélectionnez Ajouter pour créer un nouveau générateur. La capture d’écran suivante montre les ressources que vous devez utiliser pour créer le générateur personnalisé. La pile du système d’exploitation inclut Bionic Base, Bionic Full, Jammy Tiny, Jammy Base et Jammy Full. Bionic est basé sur Ubuntu 18.04 (Bionic Beaver) et Jammy est basé sur Ubuntu 22.04 (Jammy Jellyfish). Pour plus d’informations, consultez la section Recommandations relatives à la pile du système d’exploitation.

Nous recommandons d’utiliser Jammy OS Stack pour créer votre générateur, car VMware déprécie Bionic OS Stack.

Vous pouvez également modifier un générateur personnalisé lorsque le générateur n’est pas utilisé dans un déploiement. Vous pouvez mettre à jour les Buildpacks ou la pile de systèmes d’exploitation. Toutefois, le nom du générateur est en lecture seule.

Le générateur est une ressource qui contribue en continu à vos déploiements. Il fournit les dernières images de runtime et les derniers buildpacks.

Vous ne pouvez pas supprimer un générateur lorsque des déploiements actifs existants sont en cours de génération avec celui-ci. Pour supprimer un générateur dans cet état, suivez ces étapes :

1. Enregistrez la configuration sous un nouveau générateur.
2. Déployez les applications avec le nouveau générateur. Les déploiements sont liés au nouveau générateur.
3. Migrez les déploiements sous le générateur précédent vers le nouveau générateur.
4. Supprimez le générateur d’origine.

Recommandations relatives à la pile du système d’exploitation

Dans Azure Spring Apps, nous recommandons d’utiliser Jammy OS Stack pour créer votre générateur, car Bioinic OS Stack est en voie de dépréciation par VMware. La liste suivante décrit les options disponibles :

• Jammy Tiny : Adapté à la génération d’une image minimale pour une taille et une empreinte de sécurité les plus petites possibles. Comme avec la génération d’une image native Java, il peut réduire la taille de l’image conteneur finale. Les bibliothèques intégrées sont limitées. Par exemple, vous ne pouvez pas vous connecter à une instance d’application pour résoudre les problèmes , car il n’existe aucune bibliothèque shell.

  • La plupart des applications Go.
  • Applications Java. Certaines options de configuration Apache Tomcat, telles que la définition de bin/setenv.sh, ne sont pas disponibles parce que Tiny n’a pas d’interpréteur de commandes.

• Jammy Base : Adapté à la plupart des applications sans extension native.

  • Applications Java et applications .NET Core.
  • Applications Go qui nécessitent certaines bibliothèques C.
  • Applications Node.js, Python ou Web Servers sans extension native.

• Jammy Full : Comprend la plupart des bibliothèques et convient aux applications avec des extensions natives. Par exemple, il inclut une bibliothèque plus complète de polices. Si votre application s’appuie sur l’extension native, utilisez la pile Full.

  • Applications Node.js ou Python avec des extensions natives.

Pour plus d’informations, consultez Piles Ubuntu dans la documentation de VMware.

Gérer le registre de conteneurs

Cette section vous montre comment gérer le registre de conteneurs utilisé par le service de build si vous activez le service de build avec votre propre registre de conteneurs. Si vous activez le service de build avec un registre de conteneurs managé Azure Spring Apps, vous pouvez ignorer cette section.

Après avoir activé un registre de conteneurs d’utilisateurs avec le service de build, vous pouvez afficher et configurer le registre à l’aide du portail Azure ou d’Azure CLI.

Azure portal

Pour afficher, ajouter, modifier et supprimer le registre de conteneurs, suivez ces étapes :

1. Ouvrez le portail Azure.

2. Sélectionnez Registre de conteneurs dans le volet de navigation.

3. Sélectionnez Ajouter pour créer un registre de conteneurs.

   

4. Pour un registre de conteneurs, sélectionnez le bouton de sélection (...), puis Modifier pour afficher la configuration du registre.

   

5. Passez en revue les valeurs de la page Modifier le registre de conteneurs.

   

6. Pour supprimer un registre de conteneurs, sélectionnez le bouton de sélection (...), puis Supprimer pour supprimer le registre. Si le registre de conteneurs est utilisé par le service de build, il ne peut pas être supprimé.

   

Azure CLI

Utilisez la commande suivante pour lister tous les registres de conteneurs pour l’instance de service :

az spring container-registry list \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> 

Utilisez la commande suivante pour afficher le registre de conteneurs :

az spring container-registry show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name>

Utilisez la commande suivante pour mettre à jour le registre de conteneurs :

az spring container-registry update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name> \
    --server <your-container-registry-login-server> \
    --username <your-container-registry-username> \
    --password <your-container-registry-password>

Utilisez la commande suivante pour supprimer le registre de conteneurs :

az spring container-registry delete \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <your-container-registry-name> 

Si le service de build utilise le registre de conteneurs, vous ne pouvez pas le supprimer.

Le service de build peut utiliser un registre de conteneurs et peut également changer le registre de conteneurs associé. Ce processus prend du temps. Lorsque le changement se produit, l’ensemble des ressources de générateur et de build sous le service de build sont regénérées, puis les images conteneur finales sont envoyées (push) au nouveau registre de conteneurs.

Azure portal

Pour changer le registre de conteneurs associé au service de build, suivez ces étapes :

1. Ouvrez le portail Azure.

2. Sélectionnez Service de build dans le volet de navigation.

3. Sélectionnez Registre de conteneurs référencé afin de mettre à jour le registre de conteneurs pour le service de build.

   

Azure CLI

Utilisez la commande suivante pour afficher le service de build :

az spring build-service show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name>

Utilisez la commande suivante pour mettre à jour le service de build avec un registre de conteneurs spécifique :

az spring build-service update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --registry-name <your-container-registry-name> 

Générer et déployer des applications polyglottes

Vous pouvez générer et déployer des applications polyglottes des manières suivantes à l’aide du registre de conteneurs :

• Pour le service de build utilisant le registre de conteneurs Azure Spring Apps géré, vous pouvez générer une application sur une image et la déployer dans l’instance de service Azure Spring Apps actuelle. La génération et le déploiement sont exécutés ensemble à l’aide de la commande az spring app deploy.

• Pour le service de build utilisant un registre de conteneurs géré par l’utilisateur, vous pouvez générer une application dans une image conteneur et la déployer dans l’instance Azure Spring Apps Entreprise actuelle et dans d’autres instances. Les commandes de génération et de déploiement sont distinctes. Vous pouvez utiliser la commande de build pour créer ou mettre à jour une build, puis utiliser la commande de déploiement afin de déployer l’image conteneur sur l’instance de service.

Pour plus d’informations, consultez la section Service de build à la demande dans Utiliser le service de build Tanzu.

Les exemples suivants montrent quelques commandes de build utiles.

az configure --defaults group=<resource-group-name> spring=<service-name>

az spring build-service build list
az spring build-service build show --name <build-name>
az spring build-service build create --name <build-name> --artifact-path <artifact-path>
az spring build-service build update --name <build-name> --artifact-path <artifact-path>
az spring build-service build delete --name <build-name>

Les exemples Azure CLI suivants montrent la génération et le déploiement d’un fichier d’artefact pour deux scénarios de registre de conteneurs :

• Registre de conteneurs Azure Spring Apps géré.
• Registre de conteneurs géré par l’utilisateur.

Registre de conteneurs Azure Spring Apps géré

Cet exemple génère et déploie avec une seule commande. La commande suivante spécifie un générateur pour générer une application sur une image conteneur, puis déploie l’application directement dans l’instance de service Azure Springs Apps Entreprise.

Si vous ne spécifiez pas le générateur, un générateur default est utilisé.

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Registre de conteneurs géré par l’utilisateur

Cet exemple génère ou met à jour une application et la déploie en utilisant deux commandes. Avec un registre de conteneurs géré par l’utilisateur, vous pouvez déployer une application uniquement à partir d’une image conteneur personnalisée. Pour plus d’informations, consultez Déployer une application avec une image conteneur personnalisée.

La commande suivante génère une application :

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

La commande suivante met à jour une build existante :

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

La commande suivante déploie une application.

az spring app deploy \
   --resource-group <resource-group-name> \
   --service <Azure-Spring-Apps-instance-name> \
   --name <app-name> \
   --container-image <your-container-image> \
   --container-registry <your-container-registry> \
   --registry-password <your-password> \
   --registry-username <your-username>

Si vous déployez l’application avec un fichier d’artefact, utilisez --artifact-path pour spécifier le chemin d’accès au fichier. Les fichiers JAR et WAR sont acceptables.

Si Azure CLI détecte le package WAR en tant que fichier JAR léger, utilisez --disable-validation pour désactiver la validation.

L’exemple suivant déploie le dossier de code source dans un déploiement actif à l’aide du paramètre --source-path pour spécifier le dossier.

Registre de conteneurs Azure Spring Apps géré

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

Registre de conteneurs géré par l’utilisateur

La commande suivante génère une application :

az spring build-service build create \
   --resource-group <resource-group-name> \
   --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

La commande suivante met à jour une build existante :

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --builder <builder-name> \
    --source-path <path-to-source-code>

Pour déployer l’application, consultez Déployer une application avec une image conteneur personnalisée.

Vous pouvez également configurer l’environnement de build pour générer l’application. Par exemple, dans une application Java, vous pouvez spécifier la version JDK à l’aide de l’environnement de build BP_JVM_VERSION.

Pour spécifier des environnements de build, utilisez --build-env, comme illustré dans l’exemple suivant. Les variables d’environnement de build disponibles sont décrites plus loin dans cet article.

Registre de conteneurs Azure Spring Apps géré

La commande suivante déploie une application :

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Registre de conteneurs géré par l’utilisateur

La commande suivante génère une application :

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

La commande suivante met à jour une build existante :

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Pour déployer l’application, consultez Déployer une application avec une image conteneur personnalisée.

Pour chaque build, vous pouvez également spécifier les ressources de build, comme illustré dans l’exemple suivant.

Registre de conteneurs Azure Spring Apps géré

La commande suivante déploie une application :

az spring app deploy \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <app-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Registre de conteneurs géré par l’utilisateur

La commande suivante génère une application :

az spring build-service build create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

La commande suivante met à jour une build existante :

az spring build-service build update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name <build-name> \
    --build-env <key1=value1> <key2=value2> \
    --build-cpu <build-cpu-size> \
    --build-memory <build-memory-size> \
    --builder <builder-name> \
    --artifact-path <path-to-your-JAR-file>

Pour déployer l’application, consultez Déployer une application avec une image conteneur personnalisée.

La ressource processeur/mémoire de build par défaut est 1 vCPU, 2 Gi. Si votre application a besoin d’une plus petite ou plus grande quantité de mémoire, utilisez --build-memory pour spécifier les ressources mémoire, par exemple 500Mi, 1Gi, 2Gi et ainsi de suite. Si votre application a besoin d’une plus petite ou plus grande quantité de ressources processeur, utilisez --build-cpu pour spécifier les ressources processeur, par exemple 500m, 1, 2 et ainsi de suite. La limite maximale de ressources processeur/mémoire pour une build est 8 vCPU, 16Gi.

Les ressources processeur et mémoire sont limitées par la taille du pool d’agents du service de build. Pour plus d’informations, consultez la section Pool d’agents de build dans Utiliser le service de build Tanzu. La somme du quota de ressources de build de traitement ne peut pas dépasser la taille du pool d’agents.

Le nombre parallèle de tâches de build dépend de la taille du pool d’agents et de chaque ressource de build. Par exemple, si la ressource de build est 1 vCPU, 2 Gi par défaut et que la taille du pool d’agents est 6 vCPU, 12 Gi, le numéro de build parallèle est 6.

Les autres tâches de build sont bloquées pendant un certain temps en raison des limitations de quota de ressources.

Votre application doit écouter sur le port 8080. Les applications Spring Boot utilisent automatiquement 8080 à la place de SERVER_PORT.

Langages pris en charge pour les déploiements

Le tableau suivant indique les fonctionnalités prises en charge pour chaque langage.

Fonctionnalité	Java	Python	Nœud	.NET Core	Go	Fichiers statiques	Java Native Image	PHP
Gestion de cycle de vie des applications	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Affecter un point de terminaison	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Azure Monitor	✔️	✔️	✔️	✔️	✔️	✔️		✔️
Intégration APM prête à l’emploi	✔️
Déploiement bleu/vert	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Domaine personnalisé	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Mise à l’échelle - Mise à l’échelle automatique	✔️	✔️	✔️	✔️	✔️	✔️		✔️
Mise à l’échelle - Mise à l’échelle manuelle (scale-in, scale-out, scale-up, scale-down)	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Identité gérée	✔️	✔️	✔️	✔️	✔️	✔️	️	✔️
Portail des API pour VMware Tanzu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Spring Cloud Gateway pour VMware Tanzu	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Service de configuration des applications pour VMware Tanzu	✔️						✔️
VMware Tanzu Service Registry	✔️						✔️
App Live View pour VMware Tanzu	✔️						✔️
Réseau virtuel	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Adresse IP sortante	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
E2E TLS	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Résolution avancée des problèmes -Vidage de threads/segments de mémoire/JFR	✔️
Apporter votre propre stockage	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Intégrer la liaison de service à Resource Connector	✔️						✔️
Zone de disponibilité	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Événements du cycle de vie d’une application	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Taille d’application réduite - 0,5 processeur virtuel et 512 Mo	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Automatiser les déploiements d’applications avec Terraform et Azure Pipeline Task	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Suppression réversible	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Expérience de diagnostic interactive (basée sur AppLens)	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
CONTRAT SLA	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Personnalisation des sondes d’intégrité	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
Connexion au shell web pour la résolution des problèmes	✔️	✔️	✔️	✔️	✔️	✔️	️ ✔️	✔️
Débogage à distance	✔️				️	️	️

Pour plus d’informations sur les configurations prises en charge pour les différentes applications de langage, consultez la section correspondante plus loin dans cet article.

Limitations de Java Native Image

Native Image est une technologie permettant de compiler du code Java à l’avance sur un exécutable natif. Les images natives offrent différents avantages, comme un démarrage instantané et une consommation de mémoire réduite. Vous pouvez empaqueter des images natives dans une image conteneur légère pour un déploiement plus rapide et plus efficace. En raison de l’Optimisation du monde fermé, les limitations suivantes s’appliquent :

• Les fonctionnalités Java suivantes nécessitent une configuration au moment de la génération de l’exécutable :
  • Chargement de classes dynamiques
  • Réflexion
  • Proxy dynamique
  • JNI (Java Native Interface)
  • Sérialisation
• Bytecode n’est plus disponible au moment de l’exécution, c’est pourquoi le débogage et la surveillance avec des outils ciblés sur la JVMTI ne sont plus possibles.

Les fonctionnalités suivantes ne sont pas prises en charge dans Azure Spring Apps en raison de la limitation de Java Native Image. Azure Spring Apps les prend en charge lorsque Java Native Image et la communauté passent au-dessus de la limitation.

Fonctionnalité	Pourquoi elle n’est pas prise en charge
Azure Monitor	Les images natives générées par GraalVM ne prennent pas en charge les métriques JVM.
Mise à l’échelle – mise à l’échelle automatique	Les images natives générées par GraalVM ne prennent pas en charge les métriques JVM.
Intégration APM prête à l’emploi	Le fournisseur et le buildpack APM ne prennent pas en charge les images natives.
Identité managée	Les SDK Azure ne prennent pas en charge les images natives.
Résolution avancée des problèmes – Image mémoire de threads/tas/JFR	Les images natives générées par GraalVM ne prennent pas en charge l’image mémoire de threads/tas/JFR.
Débogage à distance	GraalVM Native Image ne prend pas en charge le débogage à distance.
Connexion sans mot de passe à l’aide du connecteur de services	Le SDK Azure Java ne prend pas en charge les images natives.

Remarque

Dans les différentes sections de configuration de génération et de déploiement de langage suivantes, --build-env signifie que l’environnement est utilisé dans la phase de génération. --env signifie que l’environnement est utilisé dans la phase d’exécution.

Nous vous recommandons de spécifier la version du langage au cas où la version par défaut changerait. Par exemple, utilisez --build-env BP_JVM_VERSION=11.* pour spécifier Java 11 comme version du JDK. Pour les autres langages, vous pouvez obtenir le nom de la variable d’environnement dans les descriptions suivantes.

Déployer des applications Java

Le buildpack pour le déploiement d’applications Java est tanzu-buildpacks/java-azure.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Fournit le kit Microsoft OpenJDK.	Configure la version de JVM. La version par défaut du JDK est la version 17. Actuellement prises en charge : JDK 8, 11, 17 et 21.	BP_JVM_VERSION	--build-env BP_JVM_VERSION=11.*
	Env. d’exécution. Configure si le Suivi de la mémoire native (NMT) Java est activé. La valeur par défaut est true. Non pris en charge dans le JDK 8.	BPL_JAVA_NMT_ENABLED	--env BPL_JAVA_NMT_ENABLED=true
	Configure le niveau de détail de la sortie du Suivi de la mémoire native (NMT) Java. La valeur par défaut est résumé. Définissez la valeur sur détail pour avoir une sortie NMT détaillée.	BPL_JAVA_NMT_LEVEL	--env BPL_JAVA_NMT_ENABLED=summary
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez la section Configurer des certificats d’autorité de certification pour les builds et les déploiements d’applications dans Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Intégrer l’agent APM Application Insights, Dynatrace, Elastic, New Relic, App Dynamic.	Consultez Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Déployer le package WAR avec Apache Tomcat ou TomEE.	Définissez le serveur d’application à utiliser. Définissez la valeur tomcat pour utiliser Tomcat et tomee pour utiliser TomEE. La valeur par défaut est tomcat.	BP_JAVA_APP_SERVER	--build-env BP_JAVA_APP_SERVER=tomee
Prendre en charge les applications Spring Boot.	Indique s’il faut contribuer à la prise en charge des liaisons Spring Cloud pour l’image au moment de la génération. La valeur par défaut est false (Faux).	BP_SPRING_CLOUD_BINDINGS_DISABLED	--build-env BP_SPRING_CLOUD_BINDINGS_DISABLED=false
	Indique s’il faut configurer automatiquement les propriétés de l’environnement Spring Boot à partir de liaisons au moment de l’exécution. Cette fonctionnalité nécessite que les liaisons Spring Cloud soient déjà installées au moment de la génération, sinon elles ne font rien. La valeur par défaut est false (Faux).	BPL_SPRING_CLOUD_BINDINGS_DISABLED	--env BPL_SPRING_CLOUD_BINDINGS_DISABLED=false
Prendre en charge la génération d’applications basées sur Maven à partir de la source.	Utilisé pour un projet multimodule. Indique le module dans lequel trouver l’artefact d’application. Par défaut, il s’agit du module racine (vide).	BP_MAVEN_BUILT_MODULE	--build-env BP_MAVEN_BUILT_MODULE=./gateway
Prendre en charge la génération d’applications basées sur Gradle à partir de la source.	Utilisé pour un projet multimodule. Indique le module dans lequel trouver l’artefact d’application. Par défaut, il s’agit du module racine (vide).	BP_GRADLE_BUILT_MODULE	--build-env BP_GRADLE_BUILT_MODULE=./gateway
Activer la configuration des étiquettes sur l’image créée.	Configure les étiquettes spécifiées par OCI avec des noms de variables d’environnement courts et des étiquettes arbitraires à l’aide d’une syntaxe délimitée par des espaces dans une variable d’environnement unique.	BP_IMAGE_LABELS BP_OCI_AUTHORS Découvrez d’autres variables d’environnement ici.	--build-env BP_OCI_AUTHORS=<value>
Intégrer l’agent JProfiler.	Indique s’il faut intégrer la prise en charge de JProfiler. La valeur par défaut est false (Faux).	BP_JPROFILER_ENABLED	phase de génération : --build-env BP_JPROFILER_ENABLED=true phase d’exécution : --env BPL_JPROFILER_ENABLED=true BPL_JPROFILER_PORT=<port> (facultatif, la valeur par défaut est 8849) BPL_JPROFILER_NOWAIT=true (facultatif. Indique si JVM s’exécute avant que JProfiler ne soit attaché. La valeur par défaut est true.)
	Indique s’il faut activer la prise en charge de JProfiler au moment de l’exécution. La valeur par défaut est false (Faux).	BPL_JPROFILER_ENABLED	--env BPL_JPROFILER_ENABLED=false
	Indique le port sur lequel l’agent JProfiler écoute. La valeur par défaut est 8849.	BPL_JPROFILER_PORT	--env BPL_JPROFILER_PORT=8849
	Indique si JVM s’exécute avant que JProfiler ne soit attaché. La valeur par défaut est true.	BPL_JPROFILER_NOWAIT	--env BPL_JPROFILER_NOWAIT=true
Intégrer l’agent JRebel.	L’application doit contenir un fichier rebel-remote.xml.	N/A	N/A
AES chiffre une application au moment de la génération, puis la déchiffre au moment du lancement.	Clé AES à utiliser au moment de la génération.	BP_EAR_KEY	--build-env BP_EAR_KEY=<value>
	Clé AES à utiliser au moment de l’exécution.	BPL_EAR_KEY	--env BPL_EAR_KEY=<value>
Intégrer l’agent AspectJ Weaver.	<APPLICATION_ROOT>/aop.xml existe et aspectj-weaver.*.jar existe.	N/A	N/A

Déployer des applications .NET

Le buildpack pour le déploiement d’applications .NET est tanzu-buildpacks/dotnet-core.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Configurer la version du runtime .NET Core.	Prend en charge Net6.0 et Net8.0. Vous pouvez configurer via un fichier projet runtimeconfig.json ou MSBuild. Le runtime par défaut est 6.0.*.	N/A	N/A
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez la section Configurer des certificats d’autorité de certification pour les builds et les déploiements d’applications dans Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Intégrer les agents APM Dynatrace et New Relic.	Consultez Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Activer la configuration des étiquettes sur l’image créée.	Configure les étiquettes spécifiées par OCI avec des noms de variables d’environnement courts et des étiquettes arbitraires à l’aide d’une syntaxe délimitée par des espaces dans une variable d’environnement unique.	BP_IMAGE_LABELS BP_OCI_AUTHORS Découvrez d’autres variables d’environnement ici.	--build-env BP_OCI_AUTHORS=<value>

Déployer des applications Python

Le buildpack pour le déploiement d’applications Python est tanzu-buildpacks/python.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Spécifier une version Python.	Prend en charge 3.8.*, 3.9.*, 3.10.*, 3.11.*, 3.12.*. La valeur par défaut est 3.10.* Vous pouvez spécifier la version via la variable d’environnement BP_CPYTHON_VERSION pendant la génération.	BP_CPYTHON_VERSION	--build-env BP_CPYTHON_VERSION=3.8.*
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez la section Configurer des certificats d’autorité de certification pour les builds et les déploiements d’applications dans Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Activer la configuration des étiquettes sur l’image créée.	Configure les étiquettes spécifiées par OCI avec des noms de variables d’environnement courts et des étiquettes arbitraires à l’aide d’une syntaxe délimitée par des espaces dans une variable d’environnement unique.	BP_IMAGE_LABELS BP_OCI_AUTHORS Découvrez d’autres variables d’environnement ici.	--build-env BP_OCI_AUTHORS=<value>

Déployer des applications Go

Le buildpack pour le déploiement d’applications Go est tanzu-buildpacks/go.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Spécifier une version Go.	Prend en charge 1.21.*, 1.22.*. La valeur par défaut est 1.21.*. La version Go est automatiquement détectée à partir du fichier go.mod de l’application. Vous pouvez remplacer cette version en définissant la variable d’environnement BP_GO_VERSION au moment de la génération.	BP_GO_VERSION	--build-env BP_GO_VERSION=1.22.*
Configurer plusieurs cibles.	Spécifie plusieurs cibles pour une build Go.	BP_GO_TARGETS	--build-env BP_GO_TARGETS=./some-target:./other-target
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez la section Configurer des certificats d’autorité de certification pour les builds et les déploiements d’applications dans Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Intégrer l’agent APM Dynatrace.	Consultez Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Activer la configuration des étiquettes sur l’image créée.	Configure les étiquettes spécifiées par OCI avec des noms de variables d’environnement courts et des étiquettes arbitraires à l’aide d’une syntaxe délimitée par des espaces dans une variable d’environnement unique.	BP_IMAGE_LABELS BP_OCI_AUTHORS Découvrez d’autres variables d’environnement ici.	--build-env BP_OCI_AUTHORS=<value>

Déployer des applications Node.js

Le buildpack pour le déploiement d’applications Node.js est tanzu-buildpacks/nodejs.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Spécifier une version Node.	Prend en charge 16.*, 18.*, 19.*, 20.*. La valeur par défaut est 20.*. Vous pouvez spécifier la version Node via un fichier .nvmrc ou .node-version à la racine du répertoire de l’application. BP_NODE_VERSION remplace les paramètres.	BP_NODE_VERSION	--build-env BP_NODE_VERSION=20.*
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez la section Configurer des certificats d’autorité de certification pour les builds et les déploiements d’applications dans Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Intégrer l’agent APM Dynatrace, Elastic, New Relic, App Dynamic.	Consultez Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Activer la configuration des étiquettes sur l’image créée.	Configure les étiquettes spécifiées par OCI avec des noms de variables d’environnement courts et des étiquettes arbitraires à l’aide d’une syntaxe délimitée par des espaces dans une variable d’environnement unique.	BP_IMAGE_LABELS BP_OCI_AUTHORS Découvrez d’autres variables d’environnement ici.	--build-env BP_OCI_AUTHORS=<value>
Déployer une application Angular avec Angular Live Development Server.	Spécifiez l’hôte avant d’exécuter ng serve dans le package.json : ng serve --host 0.0.0.0 --port 8080 --public-host <your application domain name>. Le nom de domaine de l’application est disponible dans la page Vue d’ensemble de l’application, dans la section URL. Supprimez le protocole https:// avant de continuer.	BP_NODE_RUN_SCRIPTS NODE_ENV	--build-env BP_NODE_RUN_SCRIPTS=build NODE_ENV=development

Déployer des applications WebServer

Le buildpack pour le déploiement d’applications WebServer est tanzu-buildpacks/web-servers.

Pour plus d’informations, consultez Déployer des fichiers statiques web.

Déployer des applications Java Native Image (préversion)

Le buildpack pour le déploiement d’applications Java Native Image est tanzu-buildpacks/java-native-image.

Vous pouvez déployer des applications d’image native Spring Boot à l’aide du buildpack tanzu-buildpacks/java-native-image. Spring Native prend en charge la compilation d’applications Spring Boot dans des exécutables natifs. Le buildpack utilise Liberica Native Image Kit (NIK) pour créer des images natives d’applications Spring Boot et ces applications sont entièrement prises en charge.

Lorsque vous générez une image native Java, vous devez définir l’environnement de build BP_NATIVE_IMAGE avec la valeur true et la ressource de mémoire de build ne doit pas être inférieure à 8Gi. La taille du pool d’agents du service de build ne doit pas être inférieure à 4 vCPU, 8 Gi. Pour plus d’informations, consultez la section Pool d’agents de build dans Utiliser le service de build Tanzu.

Si vous souhaitez générer l’image native dans une image conteneur de taille plus petite, nous vous recommandons d’utiliser un générateur avec la pile de système d’exploitation Jammy Tiny. Pour plus d’informations, consultez la section Recommandations relatives à la pile du système d’exploitation.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Intégrer Bellsoft OpenJDK.	Configure la version du JDK. Actuellement prises en charge : JDK 8, 11, 17 et 21.	BP_JVM_VERSION	--build-env BP_JVM_VERSION=17
Configurer les arguments pour la commande native-image.	Arguments à passer directement à la commande native-image. Ces arguments doivent être valides et correctement formés ou la commande native-image échoue.	BP_NATIVE_IMAGE_BUILD_ARGUMENTS	--build-env BP_NATIVE_IMAGE_BUILD_ARGUMENTS="--no-fallback"
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	Non applicable.	Non applicable.
Activer la configuration des étiquettes sur l’image créée	Configure les étiquettes spécifiées par OCI avec des noms de variables d’environnement courts et des étiquettes arbitraires à l’aide d’une syntaxe délimitée par des espaces dans une variable d’environnement unique.	BP_IMAGE_LABELS BP_OCI_AUTHORS Découvrez d’autres variables d’environnement ici.	--build-env BP_OCI_AUTHORS=<value>
Prendre en charge la génération d’applications basées sur Maven à partir de la source.	Utilisé pour un projet multimodule. Indique le module dans lequel trouver l’artefact d’application. Par défaut, il s’agit du module racine (vide).	BP_MAVEN_BUILT_MODULE	--build-env BP_MAVEN_BUILT_MODULE=./gateway

Il existe des limitations pour Java Native Image. Pour plus d’informations, consultez la section Limitations de Java Native Image.

Déployer des applications PHP

Le buildpack pour le déploiement d’applications PHP est tanzu-buildpacks/php.

Le buildpack Tanzu PHP est uniquement compatible avec la pile de système d’exploitation complète. Nous recommandons d’utiliser un générateur avec la pile de système d’exploitation Jammy Full. Pour plus d’informations, consultez la section Recommandations relatives à la pile du système d’exploitation.

Le tableau suivant répertorie les fonctionnalités prises en charge dans Azure Spring Apps :

Description de la fonctionnalité	Commentaire	Variable d’environnement	Utilisation
Spécifier la version PHP.	Configure la version PHP. Actuellement prises en charge : PHP 8.1.*, 8.2.* et 8.3.*. La valeur par défaut est 8.1*	BP_PHP_VERSION	--build-env BP_PHP_VERSION=8.1.*
Ajouter des certificats CA au magasin de confiance système lors de la génération et de l’exécution.	Consultez la section Configurer des certificats d’autorité de certification pour les builds et les déploiements d’applications dans Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Intégrer l’agent APM Dynatrace, New Relic, APP Dynamic.	Consultez Guide pratique pour configurer l’intégration APM et les certificats d’autorité de certification.	N/A	N/A
Sélectionner un serveur web.	Les options de paramètre sont php-server, httpd et nginx. La valeur par défaut est php-server.	BP_PHP_SERVER	--build-env BP_PHP_SERVER=httpd
Configurer le répertoire web.	Lorsque le serveur web est HTTPD ou NGINX, le répertoire web est par défaut htdocs. Lorsque le serveur web est le serveur intégré PHP, le répertoire web par défaut est /workspace.	BP_PHP_WEB_DIR	--build-env BP_PHP_WEB_DIR=htdocs

Étapes suivantes

• Déployer des fichiers statiques web