Migrer un réseau virtuel personnalisé

Article
02/06/2025

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

Dans Azure Spring Apps, vous pouvez déployer vos applications au sein d’un réseau virtuel managé. Cette configuration permet une communication sécurisée entre vos applications et d’autres ressources dans votre réseau virtuel, comme des bases de données et d’autres services. Azure Container Apps offre des fonctionnalités similaires, mais avec quelques différences. Cet article explore ces différences et fournit de l’aide sur la création et la gestion d’environnements Azure Container Apps avec des réseaux virtuels managés.

Prérequis

Un abonnement Azure actif. Si vous n’en avez pas, vous pouvez créer un compte gratuit Azure.
Azure CLI.

Créer un environnement Azure Container Apps avec un réseau virtuel

Dans Azure Spring Apps, vous devez configurer deux sous-réseaux au sein d’un réseau virtuel : un pour le runtime du système et un autre pour l’application utilisateur. Cette configuration garantit l’isolation et la sécurité des composants système et des applications utilisateur. D’autre part, Azure Container Apps simplifie la configuration réseau en ne nécessitant qu’un seul sous-réseau pour l’infrastructure au sein d’un réseau virtuel.

Dans Azure Container Apps, le réseau virtuel d’infrastructure est isolé du réseau virtuel du client, ce qui élimine la nécessité d’accorder l’autorisation de service au réseau virtuel, comme c’est requis dans Azure Spring Apps. Il existe deux types d’environnements pris en charge. Pour plus d’informations, consultez la section Types de Environnements Azure Container Apps. Quand vous utilisez l’environnement de profils de charge de travail, vous devez mettre à jour le réseau virtuel de façon à déléguer le sous-réseau à Microsoft.App/environments. Pour plus d’informations, consultez la section Créer un environnement de Fournir un réseau virtuel à un environnement Azure Container Apps.

En outre, les exigences pour les plages de sous-réseaux plus petit diffèrent entre les deux services.

Pour créer un environnement Azure Container Apps avec un réseau virtuel, utilisez la commande Azure CLI suivante :

az containerapp env create \
    --resource-group $RESOURCE_GROUP \
    --name $ENVIRONMENT \
    --location "$LOCATION" \
    --internal-only true \
    --infrastructure-subnet-resource-id "$INFRASTRUCTURE_SUBNET"

La variable $INFRASTRUCTURE_SUBNET correspond à l’ID de ressource d’un sous-réseau dans le réseau virtuel du client, qui est destiné aux composants d’infrastructure et aux conteneurs d’applications utilisateur. Pour plus d’informations, consultez la section Créer un environnement de Fournir un réseau virtuel à un environnement Azure Container Apps.

Le choix d’utiliser un réseau virtuel client dans Azure Container Apps ne signifie pas que votre application conteneur ne peut pas accepter de requêtes publiques. Si vous voulez limiter complètement l’accès au réseau virtuel du client, vous devez définir le paramètre --internal-only sur true. Ce paramètre garantit qu’aucun point de terminaison public n’est créé. Pour plus d’informations, consultez la section Adresse IP virtuelle de Mise en réseau dans un environnement Azure Container Apps et Fournir un réseau virtuel à un environnement Azure Container Apps interne.

Migrer l’application vers Azure Container Apps

Après avoir créé un environnement Azure Container Apps, l’étape suivante consiste à migrer votre application vers Azure Container Apps. Pour plus d’informations, consultez Mappage des concepts. Pour migrer chaque application conteneur Azure, consultez Vue d’ensemble de la migration d’application, puis sélectionnez une image conteneur ou un artefact pour le processus de migration.

Modifier le paramètre d’entrée

Azure Container Apps offre plus d’options qu’Azure Spring Apps pour personnaliser les paramètres d’entrée. Pour plus d’informations, consultez Personnaliser la configuration d’entrée dans Azure Spring Apps.

Le tableau suivant mappe les propriétés de configuration entre les deux services :

Fonctionnalité	Azure Spring Apps	Azure Container Apps
Affinité de session	`ingressSettings.sessionAffinity`	`ingress.stickySessions.affinity`
Durée maximale du cookie de session	`ingressSettings.sessionCookieMaxAge`	`EasyAuthConfig.login.cookieExpiration.timeToExpiration`
Protocole principal	`ingressSettings.backendProtocol`	`ingress.transport`
Authentification du client	`ingressSettings.clientAuth`	`ingress.clientCertificateMode`
Délai d’expiration de lecture d’entrée	`ingressSettings.readTimeoutInSeconds`	240
Délai d’expiration d’envoi d’entrée	`ingressSettings.sendTimeoutInSeconds`	240

Azure Container Apps ne permet pas aux utilisateurs de spécifier une valeur de délai d’expiration personnalisée. Au lieu de cela, il applique un délai d’expiration des requêtes intégré pour les requêtes HTTP, qui est limité à 240 secondes. Par conséquent, si une requête dépasse cette durée, la connexion est arrêtée automatiquement de façon à garantir une gestion efficace des ressources et empêcher les requêtes longues de monopoliser le système.

Azure Container Apps ne prend pas directement en charge un élément de configuration session-max-age. Cependant, vous pouvez gérer les durées et les comportements des sessions via d’autres paramètres associés. Par exemple, vous pouvez utiliser le paramètre cookieExpiration dans la configuration de EasyAuth pour contrôler la durée d’une session d’authentification. Ce paramètre vous permet de spécifier la durée pendant laquelle le cookie d’authentification reste valide.

Pour plus d’informations sur les paramètres d’entrée fournis par Azure Container Apps, consultez Entrée dans Azure Container Apps.

Azure Spring Apps et Azure Container Apps offrent des moyens de générer des points de terminaison accessibles publiquement. Dans Azure Spring Apps, chaque déploiement a une URL unique à des fins de test pendant les déploiements bleus-verts. De façon similaire, dans Azure Container Apps, une étiquette de révision fournit une URL unique que vous pouvez utiliser pour router le trafic vers la révision spécifique à laquelle l’étiquette est affectée. Pour plus d’informations, consultez la section Étiquettes de Mettre à jour et déployer des modifications dans Azure Container Apps.

Dans Azure Spring Apps, le système sonde automatiquement le port 1025 pour les applications sur le plan De base/Standard, et le port 8080 pour les applications sur le plan Entreprise. Ces sondes permettent de déterminer si le conteneur d’application est prêt à accepter du trafic. En revanche, Azure Container Apps offre plus de flexibilité en permettant aux utilisateurs de spécifier eux-mêmes le port de la sonde en utilisant le paramètre --target-port. Ce paramètre permet aux utilisateurs de contrôler davantage la configuration et le comportement de leur application.

Pour mettre à jour le port cible d’entrée d’une application conteneur, vous pouvez utiliser la commande Azure CLI suivante :

az containerapp ingress update \
    --resource-group <resource-group> \
    --name <app-name> \
    --target-port <target-port>

La liste suivante explique chaque paramètre :

--name : le nom de votre application conteneur.
--resource-group : le groupe de ressources contenant votre application conteneur.
--target-port : le port sur lequel votre application conteneur écoute.

Pour plus d’informations, consultez la section Activer l’entrée de Configurer l’entrée pour votre application dans Azure Container Apps.

Modifier le paramètre de sortie (UDR)

Azure Spring Apps et Azure Container Apps offrent tous deux des moyens de contrôler le trafic sortant via la fonctionnalité Apportez votre propre table de routage – Routes définies par l’utilisateur (UDR) – avec Pare-feu Azure. Notez cependant les différences suivantes :

Il n’est pas nécessaire d’ajouter une attribution de rôle pour un fournisseur de ressources Azure Container Apps.
Un sous-réseau dédié pour le sous-réseau d’exécution du service Azure Container Apps n’est pas requis.
Azure Container Apps offre un moyen plus flexible de prendre en charge les routes définies par l’utilisateur (UDR). Dans Azure Container Apps, il n’est pas nécessaire de définir explicitement l’option --outbound-type sur userDefinedRouting lors de l’approvisionnement d’Azure Spring Apps.

Pour plus d’informations, consultez la section Routes de Configuration d’un sous-réseau avec l’interface CLI et Contrôler le trafic sortant dans Azure Container Apps avec des routes définies par l’utilisateur.

Dans Azure Container Apps, seuls les profils de charge de travail de type Environnement prennent en charge les routes définies par l’utilisateur. En outre, Azure Container Apps prend en charge la sortie via NAT Gateway et la création de points de terminaison privés dans l’environnement d’application conteneur.

Pour créer un environnement Azure Container Apps prenant en charge les routes définies par l’utilisateur, utilisez la commande suivante :

az containerapp env create \
    --resource-group $RESOURCE_GROUP \
    --name $ENVIRONMENT \
    --location "$LOCATION" \
    --enable-workload-profiles \
    --infrastructure-subnet-resource-id "$INFRASTRUCTURE_SUBNET"

Définissez le paramètre --enable-workload-profiles sur true pour activer les profils de charge de travail.

Sécuriser les réseaux virtuels avec des groupes de sécurité réseau

Azure Spring Apps et Azure Container Apps offrent tous deux une prise en charge robuste, ce qui vous permet de gérer et de sécuriser efficacement le trafic sortant en utilisant des groupes de sécurité réseau. Les principales différences se trouvent dans les configurations spécifiques.

Pour plus d’informations, consultez Sécurisation d’un réseau virtuel personnalisé dans Azure Container Apps avec des groupes de sécurité réseau.

Modifier les paramètres DNS

Azure Spring Apps et Azure Container Apps prennent tous deux en charge l’utilisation de serveurs DNS personnalisés dans un réseau virtuel du client. Nous vous recommandons d’ajouter l’adresse IP d’Azure DNS 168.63.129.16 en tant que serveur DNS en amont dans le serveur DNS personnalisé.

Pour plus d’informations, consultez la section DNS de Mise en réseau dans l’environnement Azure Container Apps.

Actuellement, Azure Container Apps dans un type d’environnement Consommation uniquement ne prend pas en charge le vidage des modifications des paramètres DNS comme le fait Azure Spring Apps. Pour plus d’informations, consultez Vider les modifications des paramètres DNS dans Azure Spring Apps. Cependant, le type de profil de charge de travail d’environnement actualise automatiquement les paramètres DNS toutes les 5 minutes.

Azure Container Apps prend en charge le déploiement avec une zone DNS privée. Pour plus d’informations, consultez la section Déployer avec un DNS privé de Fournir un réseau virtuel à un environnement Azure Container Apps. Cette approche offre un moyen plus flexible que l’utilisation d’Azure Spring Apps pour prendre en charge la liaison d’une zone DNS privée. Pour plus d’informations, consultez la section Lier la zone DNS privée avec Azure Spring Apps de Accéder à une application dans Azure Spring Apps dans un réseau virtuel.

Accéder à une application dans Azure Container Apps au sein d’un réseau virtuel du client

Azure Container Apps fournit à la fois les fonctionnalités Accès au réseau public et Point de terminaison privé pour exposer des applications à Internet ou pour les sécuriser au sein d’un réseau privé. De façon similaire, Azure Spring Apps prend en charge ces fonctionnalités comme décrit dans les articles suivants :

Partager via