Tous les produits
Search
Centre de documentation

Platform For AI:Gérer les versions, les déploiements canari et les restaurations de version

Dernière mise à jour :Aug 26, 2026

EAS propose des stratégies de publication, un basculement progressif du trafic vers des instances canari et une gestion des versions pour déployer en toute sécurité les modifications de service, valider les nouvelles versions sur le trafic de production et revenir rapidement en arrière en cas de problème.

Présentation

La gestion des versions couvre le déploiement des modifications de service (nouvelles images, paramètres, modèles, etc.) en production. Elle inclut trois fonctionnalités :

  • Publier les modifications en production : contrôlez la cadence des mises à jour grâce à des stratégies de publication (déroulantes, par lots ou avec pause) afin d'éviter toute interruption des requêtes. Par défaut, les mises à jour déroulantes remplacent progressivement les réplicas tandis que l'arrêt gracieux vide les requêtes en cours. Pour les services comportant des dizaines ou des centaines de réplicas qui nécessitent des déploiements par étapes avec des points de contrôle, utilisez des plans de mise à jour pour un contrôle plus fin.

  • Valider sur le trafic de production : affectez les services de production et canari au même groupe de services, répartissez le trafic réel entre eux selon un ratio, puis transférez progressivement tout le trafic vers le service canari une fois sa stabilité confirmée.

  • Consulter l'historique et restaurer : chaque mise à jour crée un instantané de version. Consultez l'historique des déploiements, comparez les versions et revenez à n'importe quelle version précédente en cas de problème.

Publier les modifications en production

Choisissez une stratégie de publication en fonction du niveau de risque associé à la modification :

  • Mise à jour déroulante (par défaut) : mécanisme sous-jacent de toutes les mises à jour. Le système crée progressivement de nouveaux réplicas et remplace les anciens en fonction de max_surge (nombre de réplicas autorisés au-delà du nombre souhaité) et de max_unavailable (nombre maximal de réplicas indisponibles). Les anciens réplicas s'arrêtent de manière gracieuse après avoir vidé les requêtes en cours. Il s'agit du comportement par défaut pour les redémarrages de service et les mises à jour de paramètres. Pour plus d'informations, consultez Mises à jour déroulantes et arrêt gracieux.

  • Plan de mise à jour : ajoute des fonctionnalités de traitement par lots et de pause aux mises à jour déroulantes. Utilisez les plans de mise à jour lorsque le service compte des dizaines ou des centaines de réplicas et que vous devez avancer par étapes, en vérifiant les métriques métier entre chaque lot. Les modes de lot manuel et automatique sont pris en charge ; vous pouvez mettre en pause, ajuster ou restaurer à tout moment. Pour plus d'informations, consultez Plan de mise à jour.

Remarque

Utilisez la stratégie déroulante par défaut pour les mises à jour courantes. Pour les déploiements à grande échelle, à haut risque ou par étapes, ajoutez un plan de mise à jour.

Valider sur le trafic de production

Les publications canari fonctionnent via des groupes de services : un service de production et un service canari partagent un seul point d'accès qui distribue le trafic selon le nombre de réplicas ou un poids personnalisé. Acheminez d'abord une petite partie du trafic vers le service canari, vérifiez qu'il est sain, puis augmentez progressivement le ratio jusqu'à ce que le service canari gère l'intégralité du trafic. Pour plus d'informations, consultez Groupes de services.

Consulter l'historique et restaurer

Dans la liste des services d'inférence, localisez le service cible et cliquez sur la version actuelle dans la colonne Version pour ouvrir la liste des versions. La liste des versions permet d'effectuer les actions suivantes :

  • Consulter la configuration de déploiement : affichez les paramètres de déploiement d'une version, y compris l'image, les spécifications des ressources, les variables d'environnement et la commande de démarrage.

  • Identifier l'auteur : déterminez qui a effectué chaque modification à des fins d'audit.

  • Comparer les versions : sélectionnez deux versions et comparez leurs configurations de déploiement pour identifier précisément les modifications. Cela permet d'évaluer l'impact avant une restauration ou de résoudre les problèmes après une mise à jour.

  • Restaurer cette version : restaurez le service avec la configuration de déploiement d'une version sélectionnée. Le bouton est désactivé pour la version actuelle.

Deux points importants à garder à l'esprit concernant les restaurations :

  • Compatibilité entre versions : une restauration nécessite que l'image, les fichiers de modèle, les variables d'environnement et les autres ressources de la version cible soient toujours disponibles. Si l'image a été supprimée ou si les dépendances externes ont changé, la restauration peut échouer ou entraîner des problèmes de service.

  • Choix entre deux méthodes de restauration :

    • Si la mise à jour est entièrement terminée et que vous devez revenir à une ancienne version, utilisez la restauration via la liste des versions. Elle suit la stratégie de mise à jour déroulante et n'est pas affectée par les plans de mise à jour.

    • Si la mise à jour est encore en cours (certains réplicas ont basculé, mais pas tous) et que le service dispose d'un plan de mise à jour activé, utilisez plutôt la restauration via le plan de mise à jour (lot manuel avec le nombre de réplicas cible défini sur 0). Les réplicas déjà mis à jour reviennent progressivement en arrière, ce qui est plus rapide.