Vue d’ensemble de Java sur Azure Container Apps
Azure Container Apps peut exécuter n’importe quelle application Java conteneurisée dans le cloud tout en offrant des options flexibles pour déployer vos applications.
Quand vous utilisez Container Apps pour vos applications Java conteneurisées, vous bénéficiez des avantages suivants :
Mise à l’échelle économique : quand vous utilisez le plan Consommation, vos applications Java peuvent être mises à l’échelle à zéro. Le scale-in en cas de faible demande pour votre application entraîne automatiquement une baisse des coûts pour vos projets.
Options de déploiement : Azure Container Apps s’intègre à Buildpacks, ce qui vous permet de déployer directement à partir d’une build Maven, avec des fichiers d’artefact ou votre propre fichier Dockerfile.
Déploiement JAR (aperçu) : vous pouvez déployer votre application conteneur directement à partir d’un fichier JAR.
Déploiement WAR (aperçu) : vous pouvez déployer votre application conteneur directement à partir d’un fichier WAR.
Prise en charge de l’IDE : vous pouvez déployer votre application conteneur directement à partir d’IntelliJ.
Ajustement automatique de la mémoire (aperçu) : Container Apps optimise la façon dont la machine virtuelle Java (JVM) gère la mémoire, mettant à disposition le plus possible de mémoire pour vos applications Java.
Variables d’environnement de génération (aperçu) : vous pouvez configurer des paires clé-valeur personnalisées pour contrôler la génération d’images Java à partir du code source.
Cet article détaille les informations dont vous avez besoin pour créer des applications Java sur Azure Container Apps.
Types de déploiement
L’exécution d’applications conteneurisées signifie généralement que vous devez créer un fichier Dockerfile pour votre application, mais l’exécution d’applications Java sur Container Apps vous offre d’autres options.
| Type | Description | Utilise Buildpacks | Utilise un fichier Dockerfile |
|---|---|---|---|
| génération de code source | Vous pouvez déployer directement sur Container Apps à partir de votre code source. | Oui | Non |
| Build Artifact | Vous pouvez créer une build Maven pour le déploiement sur Container Apps | Oui | Non |
| Dockerfile | Vous pouvez créer votre fichier Dockerfile manuellement et avoir un contrôle total sur votre déploiement. | Non | Oui |
Remarque
Les déploiements Buildpacks prennent en charge JDK versions 8, 11, 17 et 21.
Types d’applications
Différents types d’application sont implémentés sous forme d’application conteneur individuelle ou de travail Container Apps. Utilisez le tableau suivant pour vous aider à déterminer le type d’application le mieux adapté à votre scénario.
Les exemples listés dans ce tableau ne sont pas exhaustifs, mais vous aident à mieux comprendre l’intention des différents types d’application.
| Type | Exemples | Implémenter en tant que... |
|---|---|---|
| Applications web et points de terminaison d’API | Spring Boot, Quarkus, Apache Tomcat et Jetty | Application conteneur individuelle |
| Applications console, tâches planifiées, exécuteurs de tâches, programmes de traitement par lots | SparkJobs, tâches ETL, programme de traitement par lots Spring, travail de pipeline Jenkins | Travail Container Apps |
Débogage
Quand vous déboguez votre application Java sur Container Apps, veillez à inspecter l’agent in-process Java pour les messages de débogage du flux de journal et de la console.
Dépannage
Gardez à l’esprit les éléments suivants quand vous développez vos applications Java :
Ressources par défaut : par défaut, une application a la moitié d’un processeur et 1 Go disponibles.
Processus sans état : quand votre application conteneur effectue un scale-in, de nouveaux processus sont créés et arrêtés. Veillez à planifier à l’avance afin d’écrire les données dans un stockage partagé, comme des bases de données et des partages de système de fichiers. Ne comptez pas sur la disponibilité dans un autre conteneur des fichiers écrits directement dans le système de fichiers conteneur.
Mise à l’échelle à zéro comme valeur par défaut : si vous devez garantir qu’une ou plusieurs instances de votre application s’exécutent en continu, veillez à définir une règle d’échelle pour mieux répondre à vos besoins.
Comportement inattendu : si votre application conteneur n’est pas générée, ne démarre pas ou ne s’exécute pas, vérifiez que le chemin d’artefact est défini correctement dans votre conteneur.
Problèmes de prise en charge de Buildpack : si votre Buildpack ne prend pas en charge les dépendances ou la version Java dont vous avez besoin, créez votre propre fichier Dockerfile pour déployer votre application. Vous pouvez voir un exemple de fichier Dockerfile pour référence.
Signaux SIGTERM et SIGINT : par défaut, JVM gère les signaux
SIGTERMetSIGINT, et ne les passe pas à l’application, sauf si vous interceptez ces signaux et que vous les gérez dans votre application en conséquence. Container Apps utiliseSIGTERMetSIGINTpour le contrôle de processus. Si vous ne capturez pas ces signaux et que votre application s’arrête de façon inattendue, vous risquez de perdre ces signaux, sauf si vous les conservez dans le stockage.Accès aux images conteneur : si vous utilisez un déploiement d’artefact ou de code source en combinaison avec le registre par défaut, vous n’avez pas d’accès direct à vos images conteneur.
Surveillance
Tous les outils d’observabilité standard fonctionnent avec votre application Java. Quand vous générez vos applications Java pour qu’elles s’exécutent sur Container Apps, gardez à l’esprit les éléments suivants :
Métriques : les métriques JVM (Java Virtual Machine) sont essentielles pour surveiller l’intégrité et les performances de vos applications Java. Les données collectées contiennent des insights sur l’utilisation de la mémoire, le garbage collection et le nombre de threads de votre machine virtuelle JVM. Vous pouvez vérifier les métriques suivantes pour vous aider à garantir l’intégrité et la stabilité de vos applications.
Journalisation : envoyez les messages d’erreur et d’application à
stdoutoustderrorpour qu’ils puissent apparaître dans le flux de journal. Évitez de journaliser directement dans le système de fichiers du conteneur, comme c’est le cas avec les services de journalisation populaires.Configuration du monitoring des performances : déployez des services de monitoring de performances dans un conteneur distinct dans votre environnement Container Apps pour qu’il puisse accéder directement à votre application.
Diagnostics
Azure Container Apps offre des outils de diagnostic intégrés pour l’usage exclusif des développeurs Java. Cette prise en charge simplifie le débogage et la résolution des problèmes des applications Java s’exécutant sur Azure Container Apps pour plus d’efficacité et de facilité.
- Niveau d’enregistreur dynamique : vous permet d’accéder à différents niveaux de détails du journal et de les vérifier sans modification du code ni vous forcer à redémarrer votre application. Vous pouvez consulter Définir le niveau d’enregistreur dynamique pour référence.
Mise à l'échelle
Si vous devez garantir que les demandes de vos applications de front-end accèdent au même serveur ou que votre application de front-end est divisée entre plusieurs conteneurs, veillez à activer les sessions rémanentes.
Sécurité
Le runtime Container Apps termine TLS/SSL pour vous au sein de votre environnement Container Apps.
Gestion de la mémoire
Pour optimiser la gestion de la mémoire dans votre application Java, vous pouvez vérifier que l’ajustement de mémoire JVM est activé dans votre application.
La mémoire est mesurée en paire de gibioctets (Gio) et de cœurs de processeur. Le tableau suivant montre la plage de ressources disponibles pour votre application conteneur.
| Seuil | Cœurs d’unité centrale | Mémoire en gibioctets (Gio) |
|---|---|---|
| Minimum | 0,25 | 0.5 |
| Maximum | 4 | 8 |
Les cœurs sont disponibles par incréments de 0,25 cœurs, avec une mémoire disponible à un ratio de 2 pour 1. Par exemple, si vous avez besoin de 1,25 cœurs, vous avez 2,5 Gio de mémoire disponible pour votre application conteneur.
Remarque
Pour les applications utilisant JDK version 9 et inférieure, veillez à définir des paramètres de mémoire JVM personnalisés pour qu’ils correspondent à l’allocation de mémoire dans Azure Container Apps.
Prise en charge des composants Java
Azure Container Apps prend en charge les composants Java suivants en tant que services managés :
Eureka Server pour Spring: l’inscription et la découverte des services sont des exigences clés pour maintenir une liste d’instances d’application dynamique. Votre application utilise cette liste pour le routage et l’équilibrage de charge des requêtes entrantes. La configuration manuelle de chaque client prend du temps et introduit le risque d’erreur humaine. Eureka Server simplifie la gestion de la découverte de services en fonctionnant en tant que registre de services où les microservices peuvent s’inscrire eux-mêmes et découvrir d’autres services au sein du système.
Config Server pour Spring: Config Server fournit une gestion centralisée de la configuration externe pour les systèmes distribués. Ce composant conçu pour relever les défis de la gestion des paramètres de configuration sur plusieurs microservices dans un environnement natif cloud.
Passerelle pour Spring : la passerelle pour Spring offre un moyen efficace et puissant de router, gérer et traiter les requêtes d’API dans le cadre d’une architecture de microservices. Elle sert de passerelle API qui route les requêtes externes vers différents services, en ajoutant différentes fonctionnalités comme le filtrage, l’équilibrage de charge, etc.
Admin for Spring : le composant managé Admin for Spring fournit une interface d’administration conçue pour les applications web Spring Boot qui ont des points de terminaison d’actionneur. Un composant managé fournit les capacités d’intégration et de gestion à votre application conteneur en vous permettant de lier votre application conteneur au composant Admin for Spring.