Partager via

Approvisionner Azure Container Apps

  • 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 une vue d’ensemble des considérations relatives à la création d’Azure Container Apps.

Dans Azure Spring Apps, les applications sont déployées dans une instance de service, qui fournit une plateforme entièrement managée. De même, dans Azure Container Apps, les applications conteneur sont créées dans un environnement Azure Container Apps, qui sert d’hôte de base pour les applications. Bien que les deux services fournissent des environnements d’hébergement, ils diffèrent selon différents aspects, tels que les modèles tarifaires, la maintenance, le support régional et les opérations de gestion. Cet article explore ces différences et fournit de l'aide pour la création et la gestion d’environnements Azure Container Apps.

Prérequis

Créer un environnement Azure Container Apps

Pour créer un environnement Azure Container Apps, utilisez la commande suivante :

az containerapp env create \
    --resource-group $RESOURCE_GROUP \
    --name $ENVIRONMENT \
    --location "$LOCATION"

Pour obtenir d’autres options de configuration, consultez Commandes CLI Azure Container Apps.

Après avoir créé l’environnement, vous pouvez déployer une application conteneur dans celui-ci. Pour obtenir des instructions pas à pas, consultez Démarrage rapide : Déployer votre première application conteneur à l’aide du portail Azure.

Remarque

Les environnements d’application conteneur sont supprimés automatiquement s’ils répondent à certaines conditions, par exemple si un environnement reste inactif pendant plus de 90 jours. Pour obtenir la liste complète des conditions, consultez la section Stratégies des environnements Azure Container Apps.

Prise en charge de la région

Les régions actuellement prises en charge par Azure Container Apps peuvent ne pas s’aligner complètement sur ces régions prises en charge par Azure Spring Apps. Vérifiez la disponibilité la plus récente dans la section Produits disponibles par région.

Tarification

Pour une instance Azure Spring Apps, les frais sont basés sur l’un des plans disponibles : Essentiel, Standard ou Entreprise. Dans Azure Container Apps, la tarification dépend de votre type d’environnement et des profils de charge de travail que vous choisissez.

Type d’environnement

Il existe deux types d’environnement dans Azure Container Apps : Workload profile et Consumption only. Vous pouvez spécifier le type d’environnement à l’aide du paramètre --enable-workload-profiles lors de la création de votre environnement Azure Container Apps. Par défaut, --enable-workload-profiles est défini sur true lors de la création d’un environnement Workload profile. Si vous la définissez sur false, un environnement Consumption only est créé.

Les environnements Workload profile vous permettent de créer des profils de charge de travail dédiés et de consommation.

Les environnements Consumption only ne prennent pas en charge la création de profils de charge de travail.

Pour connaître les considérations relatives à la facturation pour différents types, vous trouverez plus d’informations dans la section Types des environnements Azure Container Apps. Si vous envisagez d’utiliser votre propre réseau virtuel, tenez compte des différences décrites dans le tableau suivant :

Type d’environnement Types de plans pris en charge Description
Profils de charge de travail Consommation, Dédié Prend en charge les routes définies par l’utilisateur (UDR), la sortie via NAT Gateway et la création de points de terminaison privés dans l’environnement d’applications conteneur. La taille minimale requise du sous-réseau est /27.
Consommation uniquement Consommation Ne prend pas en charge les routes définies par l’utilisateur, la sortie via NAT Gateway, le peering par le biais d’une passerelle distante ou d’autres sorties personnalisées. La taille minimale requise du sous-réseau est /23.

Pour plus d’informations, consultez Environnements Azure Container Apps

Profil de charge de travail

Si vous choisissez de créer un environnement Workload profile, vous pouvez utiliser le profil par défaut Consumption ou créer des profils Dedicated supplémentaires pour répondre à vos exigences d’application spécifiques. Le tableau ci-dessous décrit ces options :

Type de profil Description Utilisation potentielle
Consommation Ajouté automatiquement à n’importe quel nouvel environnement. Applications qui ne nécessitent pas de configuration matérielle spécifique
Dédié (usage général) Équilibre les ressources de mémoire et de calcul Applications nécessitant de grandes quantités de processeur et/ou de mémoire
Dédié (mémoire optimisée) Ressources de mémoire accrues Applications qui ont besoin d’accéder à des données en mémoire volumineuses, à des modèles Machine Learning en mémoire ou à d’autres exigences élevées en mémoire
Dédié (GPU activé) (préversion) GPU activé avec des ressources de mémoire et de calcul accrues disponibles dans les régions USA Ouest 3 et Europe Nord. Applications qui nécessitent un GPU.

Pour plus d’informations sur les types et tailles de profil de charge de travail, consultez la section Types de profils de Charge de travail dans Azure Container Apps.

Estimation des coûts

Utilisez la calculatrice de prix Azure pour estimer les coûts des deux types de profil de charge de travail en fonction des besoins en ressources de votre application.

Envisagez de mettre à l’échelle les configurations et les déclencheurs de mise à l’échelle automatique, car ils affectent considérablement l’utilisation des ressources.

Pour plus d’informations, consultez Profils de charge de travail dans Azure Container Apps.

Maintainance

Azure Container Apps garantit un redémarrage d’application harmonieux pendant la maintenance sous-jacente. Vous pouvez configurer une fenêtre de maintenance pour votre environnement d’application à l’aide de la commande suivante :

az containerapp env maintenance-config add \
    --resource-group <RESOURCE_GROUP> \
    --environment <ENVIRONMENT_NAME> \
    --weekday Monday \
    --start-hour-utc 1 \
    --duration 8

Comme pour la fonctionnalité de maintenance planifiée dans Azure Spring Apps, vous pouvez définir les jours de la semaine, l’heure de début et la durée (au moins 8 heures) dans Azure Container Apps. Container Apps effectue des mises à jour non critiques en fonction de votre configuration de maintenance.

Remarque

Les heures au format UTC sont exprimées en utilisant le format horaire de 24 heures. Par exemple, si vous voulez que votre heure de début soit 13h00, la valeur de start-hour-utc est 13.

Azure Container Apps garantit que la maintenance démarre dans la fenêtre de maintenance configurée, mais ne garantit pas que la maintenance se termine dans la fenêtre de temps.

Seules les mises à jour non critiques suivent la fenêtre de maintenance configurée. Les mises à jour critiques ne le font pas.

Pour plus d’informations, consultez Maintenance planifiée d’Azure Container Apps.

Fiabilité

Prise en charge des zones de disponibilité

Dans la plupart des régions, Azure Spring Apps et Azure Container Apps utilisent des zones de disponibilité dans les régions où les services sont disponibles. Pour obtenir la liste des régions qui prennent en charge des zones de disponibilité, consultez Services Azure prenant en charge les zones de disponibilité. Azure Container Apps offre la même prise en charge de la fiabilité, quel que soit votre type de plan.

Pour activer les zones de disponibilité dans Azure Container Apps, vous devez spécifier un réseau virtuel avec un sous-réseau disponible lors de la création de l’environnement d’application conteneur. Azure Spring Apps et Azure Container Apps utilisent le même paramètre pour activer la redondance de zone. Pour plus d’informations sur l’activation des zones de disponibilité, consultez Fiabilité dans Azure Container Apps.

Récupération d’urgence

Azure Spring Apps et Azure Container Apps utilisent une stratégie unifiée pour la reprise d’activité et la continuité d’activité. Pour plus d’informations, consultez la section Récupération d’urgence inter-régions et continuité d’activité de Fiabilité dans Azure Container Apps.

Limitations connues

  • Démarrer/arrêter : Azure Spring Apps vous permet de démarrer ou d’arrêter l’ensemble de l’instance de service ou des applications individuelles. En revanche, Azure Container Apps prend en charge les fonctionnalités de démarrage/d’arrêt uniquement au niveau de l’application conteneur, et non pour l’ensemble de l’environnement.
  • Supprimer : lorsque vous supprimez une instance de service Azure Spring Apps, toutes les ressources sous-jacentes sont automatiquement supprimées. En revanche, pour Azure Container Apps, vous devez d’abord supprimer des sous-ressources, par exemple la suppression de toutes les applications conteneur avant de supprimer l’environnement des applications conteneur.