Partager via

Présentation de la migration d'applications

  • Article

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ée Azure Spring Apps vers Azure Container Apps.

Cet article s’applique à :✅ Essentiel/Standard ✅ Entreprise

Cet article fournit un aperçu d’une approche de migration d’applications d’Azure Spring Apps vers Azure Container Apps.

Prérequis

Déployer une application

Azure Container Apps vous permet de déployer à partir de registres de conteneurs, tels qu’Azure Container Registry (ACR) ou Docker Hub. Vous pouvez utiliser des outils tels que le Portail Microsoft Azure, Azure CLI ou d’autres pour le déploiement. L'exemple suivant vous montre comment déployer une application dans l'environnement géré cible my-container-apps. Pour plus d’informations, consultez Déployer votre première application conteneur avec containerapp up ou Déployer votre première application conteneur à l’aide du Portail Microsoft Azure.

az containerapp up \
    --resource-group my-container-apps \
    --name my-container-app \
    --location centralus \
    --environment 'my-container-apps' \
    --image mcr.microsoft.com/k8se/quickstart:latest \
    --target-port 80 \
    --ingress external

Azure Container Apps propose désormais une fonctionnalité de préversion pour les applications Java. Cette fonctionnalité permet aux utilisateurs de déployer des applications directement à partir d'un fichier JAR ou d'un code source local ou d'un référentiel de code. Nous vous recommandons fortement de déployer des applications conteneurisées à l'aide d'une image de conteneur.

Variables d'environnement

Azure Container Apps vous permet de configurer des variables d’environnement. Vous pouvez les configurer lorsque vous créez une nouvelle application ou ultérieurement en créant une nouvelle révision.

Pour modifier les variables d’environnement via le Portail Microsoft Azure, vous devez créer explicitement une nouvelle révision. Lorsque vous utilisez Azure CLI, vous pouvez mettre à jour l’application avec la commande az containerapp update, comme indiqué dans l’exemple suivant, qui crée automatiquement une nouvelle révision. Il est important de ne pas dupliquer les variables d'environnement. Si plusieurs variables ont le même nom, seule la dernière de la liste prend effet.

az containerapp update \
    --resource-group <RESOURCE_GROUP_NAME> \
    --name <APP NAME> \
    --set-env-vars <VAR_NAME>=<VAR_VALUE>

Azure Container Apps fournit également des variables d’environnement intégrées. Ces variables offrent des métadonnées de plateforme utiles pendant l'exécution. Pour plus d’informations, consultez la section Variables d’environnement intégrées de Gérer les variables d’environnement sur Azure Container Apps.

Secrets

Azure Container Apps permet de stocker en toute sécurité les valeurs de configuration sensibles, appelées secrets. Ces secrets sont définis au niveau de l'application sous forme de paires nom/valeur et sont accessibles à toutes les révisions de l'application conteneur.

Nous vous recommandons de stocker les secrets dans Azure Key Vault au lieu de les saisir directement. Vous pouvez référencer la valeur de chaque secret d’Azure Key Vault en utilisant l’un des formats suivants :

  • https://myvault.vault.azure.net/secrets/mysecret fait référence à la dernière version d'un secret.
  • https://myvault.vault.azure.net/secrets/mysecret/<version-ID> fait référence à une version spécifique d'un secret.

Pour cette approche, vous devez activer l’identité gérée pour votre application conteneur et lui accorder l’accès à Key Vault. La politique d'accès dans Key Vault doit permettre à l'application de l'utiliser GET pour obtenir des secrets. Alternativement, si Key Vault utilise le contrôle d’accès basé sur les rôles Azure, vous devez attribuer un rôle Key Vault Secrets User. Après avoir configuré l'identité gérée, vous pouvez ajouter une référence Key Vault en tant que secret dans votre application en spécifiant l'URI du secret. Ensuite, l’application peut récupérer le secret lors de l’exécution à l’aide de l’identité gérée.

Gardez les règles suivantes à l’esprit :

  • La suppression ou la modification d'un secret n'affecte pas automatiquement les révisions existantes. Lorsque vous mettez à jour ou supprimez des secrets, vous devez déployer une nouvelle révision ou redémarrer une révision existante pour refléter les modifications.
  • Vous pouvez également utiliser des secrets dans les règles d'échelle.

Vous pouvez utiliser des secrets dans des applications conteneurs en les référençant dans des variables d'environnement ou en les montant dans des volumes. Dans les variables d'environnement, la valeur du secret est automatiquement renseignée. Alternativement, vous pouvez monter des secrets dans des volumes. Dans ce cas, chaque secret est stocké sous forme de fichier avec le nom du secret comme nom de fichier et la valeur du secret comme contenu du fichier. Cette flexibilité vous permet de gérer les secrets en toute sécurité et d'y accéder dans l'environnement de l'application. Pour plus d’informations, consultez Gérer les secrets dans Azure Container Apps.

Si votre charge de travail sécurise la configuration sensible et récupère les propriétés du coffre de clés avec la bibliothèque spring-cloud-azure-starter-keyvault-secrets, vous pouvez utiliser Azure SDK ou Spring KeyVault PropertySource dans Azure Container Apps. Vous n'avez pas besoin de modifier le code pendant la migration.

Options JVM

Pour imprimer les options JVM dans Azure Container Apps, suivez les étapes décrites dans Créer une image de conteneur à partir d’un JAR ou d’un WAR pour conteneuriser votre application. Vous pouvez ajouter -XX:+PrintFlagsFinal dans le ENTRYPOINT de votre Dockerfile, comme indiqué dans l'exemple suivant :

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-jar", "/opt/app/app.jar"]

Pour interroger les options JVM dans Azure Container Apps, utilisez la requête suivante :

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "<APP_NAME>"
| where Log_s has_any ('{default}', '{command line}', '{ergonomic}')

Le journal suivant est un exemple qui montre les options JVM après l’exécution d’une requête :

size_t MinHeapSize = 8388608 {product} {ergonomic}
size_t MaxHeapSize = 268435456 {product} {ergonomic}

Pour ajuster les options JVM dans Azure Container Apps, vous pouvez ajouter des options JVM dans le ENTRYPOINT de votre Dockerfile comme indiqué dans l'exemple suivant :

# filename: JAR.dockerfile

FROM mcr.microsoft.com/openjdk/jdk:17-mariner

ARG JAR_FILENAME

COPY $JAR_FILENAME /opt/app/app.jar
ENTRYPOINT ["java", "-XX:+PrintFlagsFinal", "-Xmx400m", "-Xss200m", "-jar", "/opt/app/app.jar"]

Pour plus d'informations sur les options JVM, consultez Options de la machine virtuelle Java HotSpot et Configuration des options JVM.

Stockage

Azure Spring Apps et Azure Container Apps prennent tous deux en charge le stockage à l’échelle du conteneur, ce qui signifie que les données stockées sur le conteneur sont disponibles uniquement pendant l’exécution du conteneur. Pour Azure Spring Apps, le stockage total d’une application est de 5 Gio. Azure Container Apps offrent un stockage compris entre 1 et 8 Gio, selon le nombre total de vCPUs alloués. Les applications Azure Container offrent un stockage compris entre 1 et 8 Gio, selon le nombre total de processeurs virtuels alloués. Pour plus d’informations, consultez la section Stockage éphémère de Utiliser les montages de stockage dans Azure Container Apps.

Azure Spring Apps et Azure Container Apps prennent tous deux en charge le stockage permanent via Azure Files. Azure Container Apps prend en charge le montage de partages de fichiers à l’aide de protocoles SMB et NFS. Vous devez créer une définition de stockage dans l’environnement géré, puis définir un volume d’AzureFile (SMB) ou de NfsAzureFile (NFS) dans une révision. Vous pouvez effectuer l’intégralité de la configuration d’AzureFile (SMB) dans le Portail Microsoft Azure. Pour plus d’informations, consultez Créer un montage de volume Azure Files dans Azure Container Apps. La prise en charge du montage de partages NFS est actuellement en version préliminaire. Vous pouvez le configurer à l’aide d’Azure CLI ou d’un modèle ARM. Pour plus d’informations, consultez Partages de fichiers NFS Azure et la section Créer un partage de fichiers NFS Azure du Tutoriel  : Créer un partage de fichiers NFS Azure et le monter sur une machine virtuelle Linux à l’aide du Portail Microsoft Azure.

Identité managée

Chaque application conteneur dispose d’une identité gérée attribuée par le système ou d’identités gérées attribuées par l’utilisateur pour accéder aux ressources Azure protégées. Pour savoir comment gérer les identités et accorder des autorisations, consultez Identités gérées dans Azure Container Apps.

Chaque application conteneur dispose d’un point de terminaison REST interne, accessible via la variable d’environnement IDENTITY_ENDPOINT, qui diffère du point de terminaison utilisé dans Azure Spring Apps. Si votre application utilise une requête HTTP directe GET, vous devez ajuster le code pour obtenir le point de terminaison correct. Si votre application utilise une identité gérée via la bibliothèque cliente Azure Identity, vous n’avez pas besoin de modifier le code, car Azure Identity gère ce détail automatiquement.

Lorsqu’une charge de travail accède à des ressources Azure protégées, elle doit récupérer un jeton d’accès à l’aide de l’ID d’application ou de l’ID client d’une identité gérée. Dans un environnement Azure Spring Apps, vous pouvez définir l’ID client d’une identité managée attribuée par le système ou par l’utilisateur. Vous pouvez également le laisser vide et laisser le service sélectionner l’ID d’application à partir de l’une des identités gérées. Dans Azure Container Apps, vous ne pouvez pas spécifier explicitement l’ID d’application lorsque vous utilisez une identité managée attribuée par le système. Cependant, l'ID d'application est requis lors de l'utilisation d'une identité gérée attribuée par l'utilisateur.

Sondes d’intégrité

Azure Container Apps et Azure Spring Apps prennent tous deux en charge les trois types de sondes d’intégrité, notamment la sonde de démarrage, la sonde d’activité et la sonde de préparation. Pour Azure Container Apps, les sondes peuvent utiliser le protocole HTTP ou TCP. exec n’est pas pris en charge.

Dans Azure Spring Apps, les paramètres de sonde sont configurés sur la ressource de déploiement. En revanche, pour Azure Container Apps, les paramètres de sonde sont définis sur la ressource d’application conteneur. Les options suivantes sont disponibles :

Propriété Description Azure Spring Apps Azure Container Apps
probeAction L'action de la sonde. Prend en charge HTTPGetAction, TCPSocketAction, et ExecAction. Il n'y a aucune propriété pour le type d'action. L'utilisateur doit utiliser soit httpGet ou tcpSocket directement.
disableProbe Indique si la sonde est désactivée. Boolean Boolean
initialDelaySeconds Le nombre de secondes après le démarrage de l'instance d'application avant que les sondes ne soient initialisées. La valeur varie de 1 à 60.
periodSeconds À quelle fréquence, en secondes, effectuer la sonde. La valeur minimale est 1. La valeur varie de 1 à 240, avec une valeur par défaut de 10.
timeoutSeconds Le nombre de secondes après lequel la sonde expire. La valeur minimale est 1. La valeur varie de 1 à 240, avec une valeur par défaut de 1.
failureThreshold Le nombre minimum d'échecs consécutifs pour que la sonde soit considérée comme ayant échoué après avoir réussi. La valeur minimale est 1. La valeur varie de 1 à 10, avec une valeur par défaut de 3.
successThreshold Nombre minimal de réussites consécutives pour que la probe soit considérée comme réussie après avoir échoué. La valeur minimale est 1. La valeur varie de 1 à 10, avec une valeur par défaut de 1.
terminationGracePeriodSeconds La durée facultative en secondes dont le pod a besoin pour se terminer correctement en cas de défaillance de la sonde. La valeur par défaut est 90 secondes. La valeur maximale est de 3600 secondes.

Actuellement, vous ne pouvez pas configurer les sondes pour Azure Container Apps directement sur le Portail Microsoft Azure. Au lieu de cela, vous devez les configurer à l’aide d’un modèle ARM ou d’un fichier YAML d’application conteneur via Azure CLI. Pour plus d’informations, consultez Sondes d’intégrité dans Azure Container Apps.

Mise à l’échelle

Azure Container Apps prend en charge la mise à l’échelle horizontale via un ensemble de règles de mise à l’échelle. Lorsqu'une règle est ajoutée ou modifiée, une nouvelle révision de l'application conteneur est créée.

La mise à l'échelle comporte trois catégories de déclencheurs : HTTP, TCP et personnalisé. HTTP et TCP sont basés sur le nombre de requêtes ou de connexions réseau. Pour plus d’informations, consultez Définir des règles de mise à l’échelle dans Azure Container Apps.

Échelle de déclenchement basée sur le CPU ou la mémoire

Les règles de mise à l'échelle des applications de conteneur personnalisées sont basées sur ScaledObjectKEDA scaler. Vous pouvez réaliser une mise à l'échelle avec des applications conteneurs en fonction de l'utilisation du processeur ou de la mémoire via CPU scaler et Memory scaler KEDA.

L'exemple suivant illustre une configuration dans laquelle une mise à l'échelle se produit lorsque l'utilisation moyenne de la mémoire dépasse 25 %. L'utilisation de la mémoire inclut la mémoire utilisée par l'application conteneur actuelle ainsi que les pods concernés, tels que les conteneurs sidecar internes. KEDA inclut une configuration intégrée pour empêcher l'application conteneur de flotter. Pour plus d’informations sur les paramètres internes, consultez Définir des règles de mise à l’échelle dans Azure Container Apps. Vous devez vérifier le comportement pendant l’exécution pour vous assurer qu’il répond à vos besoins.

az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name memory-scaler \
    --scale-rule-type memory \
    --scale-rule-metadata "type=Utilization" \
                          "value=25"

Échelle de déclenchement basée sur des métriques Java

KEDA propose un scaler Azure Monitor, qui permet une mise à l’échelle basée sur des métriques disponibles dans Azure Monitor. Vous pouvez utiliser cette fonctionnalité pour mettre à l’échelle vos applications de manière dynamique en fonction de mesures spécifiques à Java publiées sur Azure Monitor.

Prérequis

Étapes

  1. Ajoutez des secrets. Utilisez la commande suivante pour stocker l’ID client et le secret de l’application Microsoft Entra dans Azure Container Apps en tant que secrets :

    az containerapp secret set \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --secrets activeDirectoryClientId=<Microsoft-Entra-Application-Client-ID> \
              activeDirectoryClientPassword=<Microsoft-Entra-Application-Client-Password>

  2. Définissez une règle de mise à l'échelle. Utilisez la commande suivante pour créer une règle de mise à l’échelle personnalisée qui utilise le scaler Azure Monitor. Cette règle déclenche des actions de mise à l’échelle en fonction d’une métrique Java spécifique, telle que JvmThreadCount, surveillée via Azure Monitor.

    az containerapp create \
    --resource-group MyResourceGroup \
    --name my-containerapp \
    --image my-queue-processor --environment MyContainerappEnv \
    --min-replicas 1 --max-replicas 10 \
    --scale-rule-name thread-count \
    --scale-rule-type azure-monitor \
    --scale-rule-auth "activeDirectoryClientId=activeDirectoryClientId" \
                      "activeDirectoryClientPassword=activeDirectoryClientPassword" \
    --scale-rule-metadata "activationTargetValue=1" \
                          "metricAggregationInterval=0:1:0" \
                          "metricAggregationType=Maximum" \
                          "metricName=JvmThreadCount" \
                          "resourceGroupName=MyResourceGroup" \
                          "resourceURI=MyContainerAppShortURI" \
                          "subscriptionId=MyResourceID" \
                          "targetValue=30" \
                          "tenantId=MyTenantID"

Détails de la clé

  • Gestion des secrets : les informations d'identification de l'application (identifiant client et mot de passe) sont stockées en toute sécurité sous forme de secrets.
  • Critères de mise à l'échelle : le paramètre metricName identifie la métrique Java - JvmThreadCountdans ce cas - qui est utilisée pour évaluer quand la mise à l'échelle doit se produire.
  • Valeur cible : le paramètre targetValue définit le seuil de mise à l'échelle, par exemple, la mise à l'échelle lorsque le nombre de threads dépasse 30.

En configurant cette règle, votre application conteneur peut ajuster dynamiquement le nombre d'instances en fonction des mesures de performances spécifiques à Java, améliorant ainsi la réactivité et l'utilisation des ressources.