Partager via

Migration d’applications WildFly vers WildFly dans Azure Kubernetes Service

  • Article

Ce guide décrit ce que vous devez savoir pour effectuer la migration d’une application WildFly existante dans le but de l’exécuter sur WildFly dans un conteneur Azure Kubernetes Service.

Remarque

Cet article fournit uniquement des conseils généraux. Ni Microsoft ni Red Hat ne prennent en charge WildFly, mais la communauté WildFly peut fournir de l’aide. Pour en savoir plus sur les offres prises en charge conjointement par Red Hat et Microsoft, consultez Red Hat JBoss EAP sur Azure.

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 la capacité des serveurs

Documentez le matériel (mémoire, processeur, disque) du ou des serveurs de production actuels ainsi que le nombre moyen et maximal de requêtes et l’utilisation des ressources. Vous aurez besoin de ces informations, quel que soit le chemin de migration que vous choisissez. Cela est utile, par exemple, pour guider la sélection de la taille des machines virtuelles dans votre pool de nœuds, la quantité de mémoire à utiliser par le conteneur et le nombre de parts CPU nécessaires pour le conteneur.

Il est possible de redimensionner les pools de nœuds dans AKS. Pour savoir comment, consultez la section Redimensionner les pools de nœuds dans Azure Kubernetes Service (AKS).

Inventorier tous les secrets

Recherchez les secrets et mots de passe dans l’ensemble des propriétés et fichiers de configuration présents sur le ou les serveurs de production. Veillez à vérifier jboss-web.xml dans vos fichiers WAR. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application.

Envisagez de stocker ces secrets dans Azure Key Vault. Pour plus d’informations, consultez Concepts de base d’Azure Key Vault.

Inventorier tous les certificats

Documentez tous les certificats utilisés pour les points de terminaison SSL publics. Vous pouvez voir tous les certificats présents sur les serveurs de production en exécutant la commande suivante :

keytool -list -v -keystore <path to keystore>

Valider le bon fonctionnement de la version Java prise en charge

L’utilisation de WildFly sur Azure Kubernetes Service nécessite une version spécifique de Java. Vous devez donc vérifier que votre application s’exécute correctement avec cette version prise en charge.

Remarque

Cette validation s’avère particulièrement importante si votre serveur actuel s’exécute sur un JDK non pris en charge (comme Oracle JDK ou IBM OpenJ9).

Pour obtenir votre version actuelle de Java, connectez-vous à votre serveur de production et exécutez la commande suivante :

java -version

Pour obtenir des conseils sur la version à utiliser pour l’exécution de WildFly, consultez Requirements (Exigences).

Inventorier les ressources JNDI

Inventoriez toutes les ressources JNDI. D’autres, comme les répartiteurs de messages JMS, peuvent nécessiter une migration ou une reconfiguration.

Déterminer si la réplication de session est utilisée

Si votre application s’appuie sur la réplication de session, vous devez changer votre application pour supprimer cette dépendance.

Au sein de votre application

Inspectez le fichier WEB-INF/jboss-web.xml et/ou le fichier WEB-INF/web.xml.

Documenter les sources de données

Si votre application utilise des bases de données, vous devez capturer 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 DataSource Configuration (Configuration de la source de données) dans la documentation WildFly.

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. Le système de fichiers peut être utilisé par les modules WildFly ou par votre code d’application. Vous pouvez identifier une partie ou l’ensemble des scénarios décrits dans les sections suivantes.

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.

Contenu dynamique ou interne

Pour les fichiers fréquemment écrits et lus par votre application (comme les fichiers de données temporaires) ou les fichiers statiques uniquement visibles pour votre application, vous pouvez monter des partages de stockage Azure en tant que volumes persistants. Pour en savoir plus, consultez la section Créer et utiliser un volume avec Azure Files dans Azure Kubernetes Service (AKS).

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

Les tâches planifiées, telles que les tâches Quartz Scheduler ou les tâches cron Unix, ne doivent PAS être utilisées avec Azure Kubernetes Service (AKS). Azure Kubernetes Service ne vous empêche pas de déployer une application contenant des tâches planifiées en interne. Toutefois, si votre application a fait l’objet d’un scale-out, la même tâche planifiée peut s’exécuter plusieurs fois par période planifiée. Cette situation peut entraîner des conséquences inattendues.

Pour exécuter des tâches planifiées sur votre cluster AKS, définissez des CronJobs Kubernetes selon les besoins. Pour plus d’informations, consultez Exécution de tâches automatisées avec un CronJob.

Déterminer si une connexion à un service local est nécessaire

Si votre application doit accéder à vos services locaux, vous devez provisionner l’un des services de connectivité d’Azure. Pour plus d’informations, consultez Connecter un réseau local à Azure. Vous avez également besoin de refactoriser votre application pour qu’elle utilise les API publiques disponibles que vos ressources locales exposent.

Déterminer si les files d’attente ou les rubriques JMS (Java Message Service) sont en cours d’utilisation

Si votre application utilise des files d’attente ou des rubriques JMS, vous devez les migrer vers un serveur JMS hébergé en externe. Azure Service Bus et le protocole AMQP (Advanced Message Queuing Protocol) peuvent être une excellente stratégie de migration pour ceux qui utilisent JMS. Pour en savoir plus, consulter Utiliser Java Message Service 1.1 avec Azure Service Bus standard et AMQP 1.0.

Si des magasins persistants JMS ont été configurés, vous devez capturer leur configuration et les appliquer après la migration.

Déterminer si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x

Si votre application utilise des Entity Beans ou des CMP Beans de style EJB 2.x, vous devez refactoriser votre application pour supprimer ces dépendances.

Déterminer si la fonctionnalité Java EE Application Client est en cours d’utilisation

Si vous avez des applications clientes qui se connectent à votre application (serveur) à l’aide de la fonctionnalité Java EE Application Client, vous devez refactoriser vos applications clientes et votre application (serveur) de manière à ce qu’elles utilisent des API HTTP.

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 des minuteurs EJB sont en cours d’utilisation

Si votre application utilise des minuteurs EJB, vous devez vérifier que le code du minuteur EJB peut être déclenché par chaque instance WildFly de manière indépendante. Cette validation est nécessaire car, dans le scénario de déploiement Azure Kubernetes Service, chaque minuteur EJB est déclenché sur sa propre instance WildFly.

Déterminer si des connecteurs JCA sont utilisés

Si votre application utilise des connecteurs JCA, vous devez vérifier que ceux-ci peuvent être utilisés dans WildFly. Si l’implémentation JCA est liée à WildFly, vous devez refactoriser votre application pour supprimer cette dépendance. Si vous pouvez l’utiliser, vous devez ajouter les fichiers JAR au classpath du serveur et placer les fichiers de configuration nécessaires dans le bon répertoire du serveur WildFly pour que ceux-ci soient disponibles.

Déterminer si JAAS est en cours d’utilisation

Si votre application utilise JAAS, vous devez capturer la façon dont il est configuré. S’il utilise une base de données, vous pouvez le convertir en domaine JAAS sur WildFly. S’il s’agit d’une implémentation personnalisée, vous devez valider qu’elle peut être utilisée sur WildFly.

Déterminer si votre application utilise un adaptateur de ressource

Si votre application nécessite un adaptateur de ressources (RA), celui-ci doit être compatible avec WildFly. Déterminez si le RA fonctionne correctement sur une instance autonome de WildFly en le déployant sur le serveur et en le configurant comme il faut. S’il fonctionne correctement, vous devez ajouter les fichiers JAR au classpath du serveur de l’image Docker et placer les fichiers de configuration nécessaires dans le bon répertoire du serveur WildFly pour que ceux-ci soient disponibles.

Déterminer si votre application est composée de plusieurs WAR

Si votre application est composée de plusieurs WAR, vous devez traiter chacun de ces WAR comme des applications distinctes et suivre ce guide pour chacun d’entre eux.

Déterminer si votre application est empaquetée en tant que fichier EAR

Si votre application est empaquetée en tant que fichier EAR, veillez à examiner le fichier application.xml et à capturer la configuration.

Remarque

Si vous souhaitez pouvoir mettre à l’échelle chacune de vos applications web indépendamment pour une meilleure utilisation de vos ressources Azure Kubernetes Service (AKS), vous devez diviser l’OREILLE en applications web distinctes.

Identifier tous les processus et démons extérieurs exécutés sur les serveurs de production

Si vous avez des processus qui s’exécutent en dehors du serveur d’applications, comme les démons de supervision, vous devez les éliminer ou les migrer ailleurs.

Effectuer des tests sur place

Avant de créer vos images conteneur, migrez votre application vers les versions JDK et WildFly que vous envisagez d’utiliser sur AKS. Testez l’application minutieusement pour garantir sa compatibilité et ses performances.

Migration

Provisionner Azure Container Registry et Azure Kubernetes Service

Utilisez les commandes suivantes pour créer un registre de conteneurs et un cluster Azure Kubernetes avec un principal de service ayant le rôle Lecteur sur le registre. Veillez à choisir le modèle réseau adapté aux exigences de mise en réseau de votre cluster.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

Créer une image Docker pour WildFly

Pour créer un Dockerfile, vérifiez que les prérequis suivants sont respectés :

  • Un JDK pris en charge
  • Une installation de WildFly
  • Vos options de runtime JVM
  • Un moyen de passer des variables d’environnement (le cas échéant)

Vous pouvez ensuite effectuer les étapes décrites dans les sections suivantes, le cas échéant. Vous pouvez utiliser le dépôt WildFly Container Quickstart comme point de départ pour votre Dockerfile et votre application web.

Configurer un FlexVolume de coffre de clés

Créez un coffre de clés Azure et renseignez tous les secrets nécessaires. Pour plus d’informations, consultez Démarrage rapide : Définir et récupérer un secret depuis Azure Key Vault à l’aide d’Azure CLI. Ensuite, configurez un FlexVolume de coffre de clés pour rendre ces secrets accessibles aux pods.

Vous devez également mettre à jour le script de démarrage utilisé pour démarrer WildFly. Ce script doit importer les certificats dans le magasin de clés utilisé par WildFly avant de démarrer le serveur.

Configurer les sources de données

Pour configurer WildFly afin d’accéder à une source de données, vous devez ajouter le fichier JAR du pilote JDBC à votre image Docker, puis exécuter les commandes CLI JBoss appropriées. Ces commandes doivent configurer la source de données lors de la génération de votre image Docker.

Les étapes suivantes fournissent des instructions pour PostgreSQL, MySQL et SQL Server.

  1. Téléchargez le pilote JDBC pour PostgreSQL, MySQL ou SQL Server.

    Décompressez l’archive téléchargée pour obtenir le fichier .jar de pilote.

  2. Créez un fichier avec un nom tel que module.xml et ajoutez le balisage suivant. Remplacez l’espace réservé <module name> (y compris les accolades) par org.postgres pour PostgreSQL, com.mysql pour MySQL ou com.microsoft pour SQL Server. Remplacez <JDBC .jar file path> par le nom du fichier .jar de l’étape précédente, y compris le chemin complet à l’emplacement où le fichier sera placé dans votre image Docker, par exemple dans /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Créez un fichier avec un nom tel que datasource-commands.cli et ajoutez le code suivant. Remplacez <JDBC .jar file path> par la valeur que vous avez utilisée à l’étape précédente. Remplacez <module file path> par le nom de fichier et le chemin de l’étape précédente, par exemple /opt/database/module.xml.

    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é.

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

  4. Mettez à jour la configuration de la source de données JTA pour votre application :

    Ouvrez le fichier src/main/resources/META-INF/persistence.xml de votre application et recherchez l’élément <jta-data-source>. Remplacez son contenu comme indiqué ici :

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

  5. Ajoutez ce qui suit à votre Dockerfile pour que la source de données soit créée quand vous générez votre image Docker.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Déterminez les valeurs DATABASE_CONNECTION_URL à utiliser car elles varient selon chaque serveur de base de données et diffèrent de celles sur le portail Azure. Les formats d’URL indiqués ici sont obligatoires pour une utilisation par WildFly :

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. Quand vous créerez votre fichier YAML de déploiement à un stade ultérieur, vous devrez passer les variables d’environnement DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME et DATABASE_SERVER_ADMIN_PASSWORD avec les valeurs appropriées.

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é.

Pour plus d’informations sur la configuration de la connectivité de base de données avec WildFly, consultez PostgreSQL, MySQL ou SQL Server.

Configurer les ressources JNDI

Pour configurer chaque ressource JNDI nécessaire sur WildFly, vous devez généralement effectuer les étapes suivantes :

  1. Téléchargez les fichiers JAR nécessaires et copiez-les dans l’image Docker.
  2. Créez un fichier WildFly module.xml référençant ces fichiers JAR.
  3. Créez une configuration requise par la ressource JNDI spécifique.
  4. Créez un script CLI JBoss à utiliser durant la génération Docker pour inscrire la ressource JNDI.
  5. Ajoutez tout à Dockerfile.
  6. Passez les variables d’environnement appropriées dans votre fichier YAML de déploiement.

L’exemple ci-dessous montre les étapes nécessaires à la création de la ressource JNDI pour la connectivité JMS à Azure Service Bus.

  1. Téléchargez le fournisseur Apache Qpid JMS.

    Décompressez l’archive téléchargée pour obtenir les fichiers .jar.

  2. Créez un fichier avec un nom tel que module.xml et ajoutez le balisage suivant dans /opt/servicebus. Vérifiez que les numéros de version des fichiers JAR correspondent aux noms des fichiers JAR de l’étape précédente.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Créez un fichier jndi.properties dans /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Créez un fichier avec un nom tel que servicebus-commands.cli et ajoutez le code suivant.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Ajoutez ce qui suit à votre Dockerfile pour créer la ressource JNDI quand vous générez votre image Docker.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. Quand vous créerez votre fichier YAML de déploiement à un stade ultérieur, vous devrez passer les variables d’environnement MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC et SB_TOPIC avec les valeurs appropriées.

Passer en revue la configuration de WildFly

Consultez le guide d’administration de WildFly pour découvrir les étapes de prémigration supplémentaires non couvertes par les instructions précédentes.

Générer l’image Docker et l’envoyer (push) à Azure Container Registry.

Après avoir créé le Dockerfile, vous devez générer l’image Docker et la publier sur votre registre de conteneurs Azure.

Si vous avez utilisé notre dépôt GitHub WildFly Container Quickstart, le processus de génération de l’image et de son envoi (push) à votre registre de conteneurs Azure revient à appeler les trois commandes suivantes.

Dans ces exemples, la variable d’environnement MY_ACR contient le nom de votre registre de conteneurs Azure et la variable MY_APP_NAME contient le nom de l’application web que vous souhaitez utiliser sur votre registre de conteneurs Azure.

Générez le fichier WAR :

mvn package

Connectez-vous à votre registre de conteneurs Azure :

az acr login --name ${MY_ACR}

Générez et envoyez (push) l’image :

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

Vous pouvez également utiliser l’interface CLI de Docker pour générer et tester l’image localement, comme indiqué dans les commandes suivantes. Cette approche peut simplifier le test et l’affinage de l’image avant son déploiement initial sur ACR. Toutefois, vous devez installer l’interface CLI de Docker et vérifier que le démon Docker est en cours d’exécution.

Générez l’image :

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Exécutez l’image localement :

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Vous pouvez maintenant accéder à votre application sur http://localhost:8080.

Connectez-vous à votre registre de conteneurs Azure :

az acr login --name ${MY_ACR}

Envoyez (push) l’image à votre registre de conteneurs Azure :

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Pour plus d’informations sur la génération et le stockage d’images conteneur dans Azure, consultez le module Learn Créer et stocker des images conteneur avec Azure Container Registry.

Provisionner une adresse IP publique

Si votre application doit être accessible à l’extérieur de vos réseaux internes ou virtuels, vous avez besoin d’une adresse IP statique publique. Vous devez provisionner cette adresse IP dans le groupe de ressources du nœud de votre cluster, comme indiqué dans l’exemple suivant :

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Déployer sur Azure Kubernetes Service (AKS)

Créez et appliquez un ou plusieurs fichiers YAML Kubernetes. Pour plus d’informations, consultez Démarrage rapide : Déployer un cluster Azure Kubernetes Service (AKS) à l’aide d’Azure CLI. Si vous créez un équilibreur de charge externe (que ce soit pour votre application ou un contrôleur d’entrée), veillez à fournir l’adresse IP provisionnée dans la section précédente en tant que LoadBalancerIP.

Incluez les paramètres externalisés en tant que variables d’environnement. Pour plus d’informations, consultez Définir des variables d’environnement pour un conteneur. N’incluez pas de secrets (comme des mots de passe, des clés API et des chaînes de connexion JDBC). Ceux-ci sont traités dans la section suivante.

Veillez à inclure des paramètres de mémoire et de processeur lors de la création de votre fichier YAML de déploiement pour que vos conteneurs soient correctement dimensionnés.

Configurer un stockage persistant

Si votre application nécessite un stockage non volatile, configurez un ou plusieurs volumes persistants.

Migrer des tâches planifiées

Pour exécuter des tâches planifiées sur votre cluster AKS, définissez des CronJobs Kubernetes selon les besoins. Pour plus d’informations, consultez Exécution de tâches automatisées avec un CronJob.

Post-migration

Maintenant que vous avez effectué la migration de votre application vers Azure Kubernetes Service, vous devez vérifier qu’elle fonctionne comme prévu. Une fois que vous avez terminé, vous recevez nos recommandations qui vous permettent de rendre votre application plus native dans le cloud.

Recommandations