Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
La gestion des changements peut être difficile à mesure que vous développez des applications conteneurisées dans le cloud. En fin de compte, vous avez besoin de la prise en charge pour suivre les modifications, garantir le temps d’activité et disposer de mécanismes pour gérer les restaurations lisses.
La gestion des modifications dans Azure Container Apps est alimentée par des révisions, qui sont une instantané de chaque version de votre application conteneur.
Les principales caractéristiques des révisions sont les suivantes :
Immuable : une fois établie, une révision reste inchangeable.
Versioned : les révisions agissent comme un enregistrement des versions de l’application conteneur, capturant son état à différentes étapes.
Provisionné automatiquement : lorsque vous déployez une application conteneur pour la première fois, une révision initiale est automatiquement créée.
Modifications délimitées : bien que les révisions restent statiques, les modifications d’étendue de l’application peuvent affecter toutes les révisions, tandis que les modifications de portée de révision créent une nouvelle révision.
Enregistrement historique : par défaut, vous avez accès à 100 révisions inactives, mais vous pouvez ajuster ce seuil manuellement.
Plusieurs révisions : vous pouvez exécuter plusieurs révisions simultanément. Cette fonctionnalité est particulièrement utile lorsque vous devez gérer simultanément différentes versions de votre application.
Chaque révision subit des états spécifiques, influencés par son état et sa disponibilité. Pendant son cycle de vie, une application conteneur passe par différents provisionnements, exécutions et état inactif.
Lorsque vous créez une nouvelle révision, l’application conteneur subit un démarrage et une préparation case activée s. Pendant cette phase, l’état d’approvisionnement sert de guide pour suivre la progression de l’application conteneur.
Statut | Description |
---|---|
Approvisionnement | La révision se trouve dans le processus de vérification. |
approvisionné | La révision a réussi à passer toutes les case activée. |
Échec de l’approvisionnement | La révision a rencontré des problèmes lors de la vérification. |
Une fois qu’une application conteneur est correctement configurée, une révision entre dans sa phase d’exploitation. L’état d’exécution permet de surveiller l’intégrité et les fonctionnalités d’une application conteneur.
Statut | Description |
---|---|
Approvisionnement | La révision se trouve dans le processus de vérification. |
Mettre à l’échelle à 0 | Zéro réplica en cours d’exécution et non l’approvisionnement de nouveaux réplicas. L’application conteneur peut créer de nouveaux réplicas si des règles de mise à l’échelle sont déclenchées. |
Activation | Zéro réplica en cours d’exécution, un réplica en cours d’approvisionnement. |
Échec de l’activation | Le premier réplica n’a pas pu être approvisionné. |
Mise à l’échelle/traitement | Le scale-in ou le scale-out se produit. Un ou plusieurs réplicas sont en cours d’exécution, tandis que d’autres réplicas sont provisionnés. |
En cours d’exécution | Un ou plusieurs réplicas sont en cours d’exécution. Il n’y a aucun problème à signaler. |
Exécution (au maximum) | Le nombre maximal de réplicas (conformément aux règles d’échelle de la révision) est en cours d’exécution. Il n’y a aucun problème à signaler. |
Annulation de l'approvisionnement | La révision passe d’active à inactive et supprime toutes les ressources qu’elle a créées. |
Détérioré | Au moins un réplica dans la révision est dans un état d’échec. Affichez les détails de l’état en cours d’exécution pour des problèmes spécifiques. |
Échec | Les erreurs critiques ont provoqué l’échec des révisions. L’état en cours d’exécution fournit des détails. Les causes courantes sont les suivantes : •Résiliation • Code de sortie 137 |
Les révisions peuvent également entrer un état inactif. Ces révisions ne possèdent pas d’états d’approvisionnement ou d’exécution. Toutefois, Azure Container Apps conserve une liste de ces révisions, en tenant compte jusqu’à 100 entrées inactives. Vous pouvez activer une révision à tout moment.
Vous pouvez utiliser le --max-inactive-revisions
paramètre avec les commandes ou containerapp update
les containerapp create
commandes pour contrôler le nombre de révisions inactives suivies par Container Apps.
Cet exemple montre comment créer une application conteneur qui suit 50 révisions inactives :
az containerapp create --max-inactive-revisions 50
Azure Container Apps prend en charge deux modes de révision. Votre choix de mode détermine le nombre de révisions de votre application simultanément actives.
Modes de révision | Description | Default |
---|---|---|
Unique | Les nouvelles révisions sont automatiquement configurées, activées et mises à l’échelle à la taille souhaitée. Une fois que tous les réplicas s’exécutent comme défini par la règle de mise à l’échelle, le trafic est redirigé de l’ancienne version vers la nouvelle version. En cas d’échec d’une mise à jour, le trafic reste pointé vers l’ancienne révision. Les anciennes révisions sont automatiquement déprovisionnée. | Oui |
Multiple | Vous pouvez avoir plusieurs révisions actives, fractionner le trafic entre les révisions et choisir quand déprovisionner les anciennes révisions. Ce niveau de contrôle est utile pour tester plusieurs versions d’une application, des tests bleu-vert ou prendre le contrôle total des mises à jour d’application. Pour plus de détails, reportez-vous au fractionnement du trafic. |
Pour les applications conteneur avec le trafic HTTP externe, les étiquettes dirigent le trafic vers des révisions spécifiques. Une étiquette fournit une URL unique que vous pouvez utiliser pour acheminer le trafic vers la révision correspondant à l’étiquette.
Pour basculer le trafic entre les révisions, vous pouvez déplacer l’étiquette d’une révision vers une autre.
Les étiquettes sont utiles pour tester de nouvelles révisions. Par exemple, lorsque vous souhaitez accorder l’accès à un ensemble d’utilisateurs de test, vous pouvez leur donner l’URL de l’étiquette. Ensuite, lorsque vous souhaitez déplacer vos utilisateurs vers une autre révision, vous pouvez déplacer l’étiquette vers cette révision.
Les étiquettes fonctionnent indépendamment du fractionnement du trafic. Le fractionnement du trafic distribue le trafic à destination de l’URL de l’application conteneur vers les révisions en fonction du pourcentage de trafic. Lorsque le trafic est dirigé à destination de l’URL d’une étiquette, le trafic est routé vers une révision spécifique.
Un nom d’étiquette doit :
-
)Les étiquettes ne doivent pas :
--
)Vous pouvez gérer les étiquettes depuis la page de Gestion des révisions de votre application conteneur dans le portail Azure.
L’URL de l’étiquette est disponible dans le volet détails de révision.
En mode révision unique, Container Apps garantit que votre application ne subit pas de temps d’arrêt lors de la création d’une nouvelle révision. La révision active existante n’est pas désactivée tant que la nouvelle révision n’est pas prête.
Si l’entrée est activée, la révision existante continue de recevoir 100 % du trafic jusqu’à ce que la nouvelle révision soit prête.
Une nouvelle révision est considérée comme prête lorsque :
En mode révision multiple , vous pouvez contrôler quand les révisions sont activées ou désactivées et quelles révisions reçoivent le trafic d’entrée. Si une règle de fractionnement du trafic est configurée avec latestRevision
défini sur true
, le trafic ne bascule pas vers la dernière révision tant qu’elle n’est pas prête.
Bien que le mode révision unique soit la valeur par défaut, vous pouvez parfois avoir un contrôle total sur la façon dont vos révisions sont gérées.
Le mode de révision multiple vous offre la possibilité de gérer manuellement votre révision. Par exemple, l’utilisation de plusieurs modes de révision vous permet de déterminer exactement la quantité de trafic allouée à chaque révision.
Le diagramme suivant montre une application conteneur avec deux révisions.
Ce scénario suppose que l’application conteneur est dans l’état suivant :
Au lieu d’utiliser une règle de routage pour rediriger le trafic vers une révision, vous souhaiterez peut-être rendre une révision disponible pour les demandes d’une URL spécifique. Plusieurs modes de révision peuvent vous permettre d’envoyer toutes les demandes entrantes dans votre domaine à la dernière révision, tandis que les demandes d’une révision plus ancienne sont disponibles via des étiquettes pour un accès direct.
En mode de révision multiple, vous pouvez activer ou désactiver les révisions si nécessaire. Les révisions actives sont opérationnelles et peuvent gérer les demandes, tandis que les révisions inactives restent inactives.
Container Apps ne facture pas les révisions inactives. Toutefois, il existe une limite sur le nombre total de révisions disponibles, les plus anciennes étant purgées une fois que vous dépassez le nombre de 100.
Les modifications apportées à une application conteneur sont classées dans les deux catégories suivantes : modifications de niveau révision et de niveau application. Les modifications de niveau révision déclenchent une nouvelle révision lorsque vous déployez votre application, contrairement aux modifications de niveau application.
Une révision est créée lorsqu’une application conteneur est mises à jour avec des modifications de niveau révision. Les modifications sont limitées à la révision dans laquelle elles sont déployées et n’affectent pas les autres révisions.
Une modification de niveau révision est une modification apportée aux paramètres de la section properties.template
du modèle de ressource d’application conteneur.
Ces paramètres sont les suivants :
Lorsque vous déployez une application conteneur avec des modifications de niveau application :
Les modifications de niveau révision sont définies en tant que modification apportée aux paramètres de la section properties.configuration
du modèle de ressource d’application conteneur.
Ces paramètres sont les suivants :
Vous pouvez personnaliser le nom de révision et les étiquettes pour mieux s’aligner sur vos conventions d’affectation de noms ou stratégie de contrôle de version.
Chaque révision dans Container Apps est affectée à un identificateur unique. Bien que les noms soient générés automatiquement, vous pouvez personnaliser le nom de révision.
Le format classique d’un nom de révision est le suivant :
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Par exemple, si vous avez une application conteneur nommée album-api et que vous décidez du suffixe de révision first-revision, le nom de révision complet devient album-api-first-revision.
Un nom de suffixe de révision doit :
-
)Les noms ne doivent pas avoir :
--
)Vous pouvez définir le suffixe de révision dans le modèle ARM, via l’interface de ligne de commande Azure az containerapp create
et les commandes az containerapp update
, ou lors de la création d’une révision via le portail Azure.
Voici les cas d’usage courants pour l’utilisation de révisions dans les applications conteneur. Cette liste n’est pas une liste exhaustive de l’objectif ou des fonctionnalités d’utilisation des révisions Container Apps.
Les révisions simplifient le processus d’introduction de nouvelles versions de votre application. Lorsque vous êtes prêt à déployer une mise à jour ou une nouvelle fonctionnalité, vous pouvez créer une nouvelle révision sans affecter la version active actuelle. Cette approche garantit une transition fluide et réduit les interruptions pour les utilisateurs finaux.
Parfois, vous devez revenir rapidement à une version antérieure et stable de votre application. Vous pouvez revenir à une révision précédente de votre application conteneur si nécessaire.
Lorsque vous souhaitez tester différentes versions de votre application, les révisions peuvent prendre en charge les tests A/B. Vous pouvez acheminer un sous-ensemble de vos utilisateurs vers une nouvelle révision, recueillir des commentaires et prendre des décisions éclairées en fonction des données réelles.
Les révisions prennent en charge la stratégie de déploiement bleu-vert. En ayant deux révisions parallèles (bleues pour la version dynamique et verte pour la nouvelle), vous pouvez progressivement effectuer une phase dans une nouvelle révision. Une fois que vous êtes confiant dans la stabilité et les performances de la nouvelle version, vous pouvez basculer le trafic entièrement vers l’environnement vert.
Événements
Créer des applications intelligentes
17 mars, 23 h - 21 mars, 23 h
Rejoignez la série de rencontres pour créer des solutions IA évolutives basées sur des cas d’usage réels avec d’autres développeurs et experts.
S’inscrire maintenantEntrainement
Module
Mettre à l’échelle et gérer des applications conteneur déployées - Training
Ce module traite du concept de révisions dans Azure Container Apps et aborde les options de gestion du cycle de vie des applications. Il couvre également les options de mise à l’échelle et les paramètres d’entrée, notamment le fractionnement du trafic pour Azure Container Apps.