Mettre à jour et déployer des modifications dans Azure Container Apps
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.
Cycle de vie
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.
État d’approvisionnement
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. |
État en cours d’exécution
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 |
État inactif
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.
Modifier la limite de révision inactive
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
Modes de révision
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. |
Étiquettes
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.
- Lorsqu’elles sont déplacées d’une révision à une autre, les étiquettes conservent la même URL.
- Une étiquette peut être appliquée à une seule révision à la fois.
- L’allocation pour le fractionnement du trafic n’est pas nécessaire pour les révisions avec étiquettes.
- Les étiquettes sont les plus utiles lorsque l’application est en mode de révisions multiples.
- Vous pouvez activer les étiquettes, le fractionnement du trafic ou les deux.
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 :
- Se compose de caractères alphanumériques minuscules ou de tirets (
-) - Commencer par un caractère alphabétique
- Fin avec un caractère alphanumérique
Les étiquettes ne doivent pas :
- Avoir deux tirets consécutifs (
--) - Être plus de 64 caractères
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.
Déploiement sans temps d’arrêt
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 :
- La révision a été configurée avec succès
- La révision a été mise à l’échelle pour correspondre au nombre de réplicas des révisions précédentes (respectant le nombre minimal et maximal de réplicas de la nouvelle révision)
- Tous les réplicas ont passé leurs sondes de démarrage et de préparation
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.
Utiliser plusieurs révisions
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.
Fractionnement du trafic
Le diagramme suivant montre une application conteneur avec deux révisions.
Ce scénario suppose que l’application conteneur est dans l’état suivant :
- L’entrée est activée, ce qui rend l’application conteneur disponible via HTTP ou TCP.
- La première révision a été déployée en tant que Revision 1.
- Une fois le conteneur mis à jour, une nouvelle révision a été activée comme Revision 2.
- Les règles de répartition du trafic sont configurées pour que Revision 1 reçoive 80 % des demandes et que Revision 2 reçoive les 20 % restants.
Accès direct à la révision
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.
État d’activation
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.
Types de modification
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.
Changements de niveau révision
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 :
- Suffixe de révision
- Configuration et images de conteneur
- Règles de mise à l’échelle de l’application conteneur
Changements de niveau application
Lorsque vous déployez une application conteneur avec des modifications de niveau application :
- Les modifications sont appliquées globalement à toutes les révisions.
- Aucune révision n’est créée.
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 :
- Valeurs secrètes (les révisions doivent être redémarrées avant qu’un conteneur ne reconnaisse les nouvelles valeurs secrètes)
- Mode de révision
- Configuration d’entrée, notamment :
- Activation ou désactivation de l’entrée
- Règles de fractionnement du trafic
- Étiquettes
- Informations d’identification pour les registres de conteneurs privés
- Paramètres Dapr
Personnaliser les révisions
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.
Suffixe de nom
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 :
- Se compose uniquement de caractères alphanumériques minuscules ou de tirets (
-) - Commencer par un caractère alphabétique
- Fin avec un caractère alphanumérique
Les noms ne doivent pas avoir :
- Deux tirets consécutifs (
--) - Être plus de 64 caractères
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.
Cas d’utilisation
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.
Gestion des versions
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.
Restauration des versions précédentes
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.
Test A/B
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.
Déploiement Blue-Green
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.