Comment déployer des applications polyglottes dans le plan Entreprise Azure Spring 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.

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

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

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>

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

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.

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

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.

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>

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>

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>

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.

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>

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>

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>

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.

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>

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>

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 chaque build, vous pouvez également spécifier les ressources de build, comme illustré dans l’exemple suivant.

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>

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>

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>

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.

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.

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 :

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 :

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 :

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 :

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 :

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 :

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 :

Étapes suivantes

• Déployer des fichiers statiques web