Partager via

Migration d’applications Tomcat vers Azure Container Apps

  • Article

Ce guide décrit ce que vous devez savoir lorsque vous souhaitez migrer une application Tomcat existante pour qu'elle s'exécute sur Azure Container Apps (ACA).

Prémigration

Pour garantir la réussite de la migration, avant de commencer, effectuez les étapes d’évaluation et d’inventaire décrites dans les sections suivantes.

Inventorier les ressources externes

Les ressources externes, comme les sources de données, les répartiteurs de messages JMS, etc., sont injectées par le biais de l’interface JNDI (Java Naming and Directory Interface). Certaines de ces ressources peuvent nécessiter une migration ou une reconfiguration.

Au sein de votre application

Examinez le fichier META-INF/context.xml. Recherchez les éléments <Resource> à l’intérieur de l’élément <Context>.

Sur le ou les serveurs d’applications

Examinez les fichiers $CATALINA_BASE/conf/context.xml et $CATALINA_BASE/conf/server.xml, ainsi que les fichiers .xml trouvés dans les répertoires $CATALINA_BASE/conf/[engine-name]/[host-name].

Dans les fichiers context.xml, les ressources JNDI sont décrites par les éléments <Resource> à l’intérieur de l’élément <Context> de niveau supérieur.

Dans les fichiers server.xml, les ressources JNDI sont décrites par les éléments <Resource> à l’intérieur de l’élément <GlobalNamingResources>.

Sources de données

Les sources de données sont des ressources JNDI dont l’attribut type a la valeur javax.sql.DataSource. Pour chaque source de données, réunissez les informations suivantes :

  • Quel est le nom de la source de données ?
  • Quelle est la configuration du pool de connexions ?
  • Où trouver le fichier JAR du pilote JDBC ?

Pour plus d’informations, consultez JNDI Datasource HOW-TO (Guide pratique sur les sources de données JNDI) dans la documentation Tomcat.

Toutes les autres ressources externes

Il n’est pas possible de décrire toutes les dépendances externes possibles dans ce guide. Il incombe à votre équipe de vérifier que vous pouvez satisfaire à toutes les dépendances externes de votre application après la migration.

Inventorier les secrets

Mots de passe et chaînes sécurisées

Recherchez dans l’ensemble des propriétés et fichiers de configuration présents sur les serveurs de production d’éventuels chaînes secrètes et mots de passe. Pensez à vérifier server.xml et context.xml dans $CATALINA_BASE/conf. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification à l’intérieur de votre application. Il peut s’agir du fichier META-INF/context.xml et, pour les applications Spring Boot, des fichiers application.properties ou application.yml.

Déterminer si le système de fichiers est utilisé et de quelle manière

Toute utilisation du système de fichiers sur le serveur d’applications nécessite une reconfiguration ou, dans de rares cas, des modifications architecturales. Vous pouvez identifier une partie ou l’ensemble des scénarios suivants.

Contenu statique en lecture seule

Si votre application sert actuellement du contenu statique, vous aurez besoin d’un autre emplacement pour lui. Vous pouvez envisager de déplacer le contenu statique vers Azure Blob Storage et d'ajouter Azure CDN pour des téléchargements rapides à l'échelle mondiale. Pour plus d’informations, consultez Hébergement de sites web statiques dans le service Stockage Azure et Démarrage rapide : Intégrer un compte de stockage Azure à Azure CDN.

Contenu statique publié dynamiquement

Si votre application autorise le contenu statique chargé/produit par votre application mais immuable après sa création, vous pouvez utiliser le Stockage Blob Azure et Azure CDN comme décrit ci-dessus, avec une fonction Azure pour gérer les chargements et l’actualisation du réseau CDN. Nous avons mis à votre disposition un exemple d’implémentation dans Chargement et préchargement CDN de contenu statique avec Azure Functions.

Identifier le mécanisme de persistance de session

Pour identifier le gestionnaire de persistance de session en cours d’utilisation, examinez les fichiers context.xml dans votre application et votre configuration Tomcat. Recherchez l’élément <Manager>, puis notez la valeur de l’attribut className.

Les implémentations PersistentManager intégrées à Tomcat, telles que StandardManager ou FileStore, ne sont pas conçues pour être utilisées avec une plate-forme distribuée et échelonnée telle que ACA. ACA peut équilibrer la charge entre plusieurs instances et redémarrer de manière transparente n'importe quelle instance à tout moment, il n'est donc pas recommandé de persister l'état mutable dans un système de fichiers.

Si la persistance de session est nécessaire, vous devez utiliser une autre implémentation PersistentManager qui écrit dans un magasin de données externe, comme VMware Tanzu Session Manager avec le cache Redis.

Cas particuliers

Certains scénarios de production peuvent nécessiter plus de changements ou imposer plus de limitations. Même si de tels scénarios peuvent être rares, il est important de s’assurer qu’ils ne sont pas applicables à votre application ou qu’ils sont correctement résolus.

Déterminer si l’application s’appuie sur des tâches planifiées

Les tâches planifiées, comme les tâches Quartz Scheduler ou les travaux Cron, ne peuvent pas être utilisées avec des déploiements Tomcat conteneurisés. Si votre application a fait l’objet d’un scale-out, une seule tâche planifiée peut s’exécuter plusieurs fois par période planifiée. Cette situation peut entraîner des conséquences inattendues.

Inventoriez toutes les tâches planifiées à l’intérieur ou à l’extérieur du serveur d’applications.

Déterminer si votre application contient du code propre au système d’exploitation

Si votre application contient du code avec des dépendances vis-à-vis du système d’exploitation hôte, vous devez la refactoriser pour supprimer ces dépendances. Par exemple, vous devrez peut-être remplacer toute utilisation de / ou \ dans les chemins d'accès au système de fichiers par File.Separator ou Paths.get si votre application fonctionne sous Windows.

Déterminer si MemoryRealm est utilisé

MemoryRealm nécessite un fichier XML persistant. Sur ACA, vous devrez ajouter ce fichier à l'image du conteneur ou le charger sur un stockage partagé mis à la disposition des conteneurs. (Pour plus d'informations, voir la section Identifier le mécanisme de persistance de session). Le paramètre pathName devra être modifié en conséquence.

Pour déterminer si MemoryRealm est actuellement utilisé, examinez vos fichiers server.xml et context.xml et recherchez les éléments <Realm> dont l’attribut className a la valeur org.apache.catalina.realm.MemoryRealm.

Test sur place

Avant de créer des images conteneur, migrez votre application vers les kits JDK et Tomcat que vous envisagez d’utiliser sur ACA. Testez votre application minutieusement pour garantir sa compatibilité et ses performances.

Paramétrer la configuration

Lors de la prémigration, vous aurez probablement identifié des secrets et des dépendances externes, comme des sources de données, dans les fichiers server.xml et context.xml. Pour chaque élément ainsi identifié, remplacez le nom d’utilisateur, le mot de passe, la chaîne de connexion ou l’URL par une variable d’environnement.

Remarque

Microsoft vous recommande d’utiliser le flux d’authentification le plus sécurisé disponible. Le flux d’authentification décrit dans cette procédure, par exemple pour les bases de données, les caches, la messagerie ou les services IA, nécessite un niveau de confiance très élevé dans l’application et comporte des risques non présents dans d’autres flux. Utilisez ce flux uniquement lorsque des options plus sécurisées, telles que les identités managées pour les connexions sans mot de passe ou sans clé, ne sont pas viables. Pour les opérations d’ordinateur local, préférez les identités utilisateur pour les connexions sans mot de passe ou sans clé.

Par exemple, supposons que le fichier context.xml contienne l’élément suivant :

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="{password}"
/>

Dans ce cas, vous pouvez le changer comme indiqué dans l’exemple suivant :

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Migration

Remarque

Certains déploiements Tomcat peuvent avoir plusieurs applications en cours d’exécution sur un même serveur Tomcat. Si c’est le cas dans votre déploiement, nous vous recommandons vivement d’exécuter chaque application dans un pod distinct. Ainsi, vous optimisez l’utilisation des ressources pour chaque application tout en minimisant la complexité et le couplage.

Préparer les artefacts de déploiement

Clonez le référentiel GitHub Démarrage rapide de Tomcat sur les conteneurs. Ce référentiel contient un Dockerfile et des fichiers de configuration Tomcat avec de nombreuses optimisations recommandées. Dans les étapes ci-dessous, nous décrivons les modifications que vous devrez probablement apporter à ces fichiers avant de créer l’image conteneur et de la déployer sur ACA.

Ajouter des ressources JNDI

Modifiez server.xml pour ajouter les ressources que vous avez préparées lors des étapes de pré-migration, telles que les sources de données, comme le montre l'exemple suivant :

Remarque

Microsoft vous recommande d’utiliser le flux d’authentification le plus sécurisé disponible. Le flux d’authentification décrit dans cette procédure, par exemple pour les bases de données, les caches, la messagerie ou les services IA, nécessite un niveau de confiance très élevé dans l’application et comporte des risques non présents dans d’autres flux. Utilisez ce flux uniquement lorsque des options plus sécurisées, telles que les identités managées pour les connexions sans mot de passe ou sans clé, ne sont pas viables. Pour les opérations d’ordinateur local, préférez les identités utilisateur pour les connexions sans mot de passe ou sans clé.

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

Pour obtenir des instructions supplémentaires sur les sources de données, consultez les sections suivantes de la page JNDI Datasource How-To (Guide pratique sur les sources de données JNDI) dans la documentation Tomcat :

Générer et envoyer (push) l’image

La façon la plus simple de générer et charger l’image sur Azure Container Registry (ACR) afin qu’elle soit utilisée par ACA consiste à utiliser la commande az acr build. Cette commande ne nécessite pas l’installation de Docker sur votre ordinateur. Par exemple, si vous avez le Dockerfile du repo tomcat-container-quickstart et le package d'application petclinic.war dans le répertoire actuel, vous pouvez construire l'image du conteneur dans ACR avec la commande suivante :

az acr build \
    --registry $acrName \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" 
    --build-arg APP_FILE=petclinic.war \
    --build-arg SERVER_XML=prod.server.xml .

Vous pouvez omettre le paramètre --build-arg APP_FILE... si votre fichier WAR est nommé ROOT.war. Vous pouvez omettre le paramètre --build-arg SERVER_XML... si le fichier XML de votre serveur se nomme server.xml. Les deux fichiers doivent se trouver dans le même répertoire que le Dockerfile.

Vous pouvez également utiliser Docker CLI pour construire l'image localement à l'aide des commandes suivantes. Cette approche peut simplifier le test et l’affinage de l’image avant son déploiement initial sur ACR. Toutefois, elle nécessite que l’interface CLI de Docker soit installée et le démon de Docker en cours d’exécution.

# Build the image locally.
sudo docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally.
sudo docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# You can now access your application with a browser at http://localhost:8080.

# Sign in to ACR.
sudo az acr login --name $acrName

# Push the image to ACR.
sudo docker push "${acrName}.azurecr.io/petclinic:1"

Pour plus d'informations, consultez la section Construire et stocker des images de conteneurs avec Azure Container Registry.

Déployer sur Azure Container Apps

La commande suivante illustre un exemple de déploiement :

az containerapp create \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --environment <ENVIRONMENT_NAME> \
    --image <IMAGE_NAME> \
    --target-port 8080 \
    --ingress 'external' \
    --registry-server <REGISTRY_SERVER> \
    --min-replicas 1

Pour un démarrage rapide plus approfondi, consultez Démarrage rapide : Déployez votre première application conteneurisée.

Post-migration

Maintenant que vous avez migré votre application vers ACA, vous devez vérifier qu’elle fonctionne comme prévu. Une fois que vous avez terminé, nous vous fournissons des recommandations pour rendre votre application plus native dans le cloud.

Recommandations

  • Concevez et implémentez une stratégie de continuité de l’activité et de reprise d’activité. Pour les applications stratégiques, envisagez une architecture de déploiement multirégion. Pour plus d'informations, voir Meilleures pratiques pour la continuité des activités et la reprise après sinistre dans Azure Kubernetes Service (AKS).

  • Évaluez les éléments inclus dans le fichier logging.properties. Envisagez d’éliminer ou de réduire une partie de la sortie de journalisation pour améliorer les performances.

  • Envisagez de surveiller la taille du cache de code et d'ajouter les paramètres -XX:InitialCodeCacheSize et -XX:ReservedCodeCacheSize à la variable JAVA_OPTS dans le fichier Docker pour optimiser davantage les performances. Pour plus d’informations, consultez la rubrique sur le paramétrage de codecache dans la documentation Oracle.

  • Ajoutez des groupes d’actions et des règles d’alerte Azure Monitor pour détecter et résoudre rapidement les conditions aberrantes.

  • Envisagez de répliquer le déploiement d'Azure Container Apps dans une autre région pour réduire la latence et augmenter la fiabilité et la tolérance aux pannes. Utilisez Azure Traffic Manager pour équilibrer la charge entre les déploiements, ou utilisez Azure Front Door pour ajouter le déplacement SSL et le pare-feu d’applications web avec la protection DDoS.

  • Si la géoréplication n’est pas nécessaire, ajoutez une passerelle d’application Azure pour ajouter le déplacement SSL et le pare-feu d’applications web avec la protection DDoS.