Lorsque vous mettez à jour la logique d'une tâche dans SchedulerX, un déploiement direct sur l'ensemble des workers risque d'impacter les charges de travail en production. SchedulerX prend en charge le déploiement canari basé sur des labels, qui achemine les tâches vers un sous-ensemble de workers à des fins de validation avant un déploiement complet.
Fonctionnement
Les workers SchedulerX signalent leurs labels au serveur via des battements de cœur (heartbeats). Chaque tâche peut cibler les workers portant un label spécifique, soit par configuration statique, soit au moment de l'exécution. Ce routage basé sur les labels constitue le mécanisme du déploiement canari.
Le processus est le suivant :
Attribuez des labels aux workers, par exemple
graypour l'environnement canari etprodpour la production.Acheminez une tâche vers les workers portant le label
grayà des fins de test.Vérifiez les résultats.
Une fois la validation réussie, déployez la modification sur les workers portant le label
prod.
Choisir une approche
| Approche | Cas d'utilisation | Retour arrière |
|---|---|---|
| Tâche canari dédiée | Tests canaris continus : vous avez besoin d'une tâche canari persistante s'exécutant parallèlement à la production | Supprimez la tâche canari ; la tâche de production continue de s'exécuter sans modification |
| Exécution canari ponctuelle | Validation rapide avant mise en production : testez une seule exécution sur les workers canaris sans dupliquer la tâche | Aucun retour arrière nécessaire ; la planification de production n'est pas affectée |
Attribuer des labels aux workers
Les workers doivent disposer de labels avant que vous ne puissiez utiliser le routage basé sur ceux-ci. SchedulerX propose deux méthodes.
Définir les labels au démarrage de l'application
Spécifiez les labels via la configuration Properties. L'exemple suivant utilise une application Spring Boot :
spring.schedulerx2.label=${label}Remplacez ${label} par la valeur du label cible, telle que prod ou gray.
Hériter des labels des tags de trafic EDAS ou MSE
Si votre application s'exécute sur Enterprise Distributed Application Service (EDAS) ou Microservices Engine (MSE), l'étiquetage du trafic applique automatiquement des labels aux workers SchedulerX. Aucune modification de code n'est requise : les workers héritent des labels configurés dans EDAS ou MSE.
Cette méthode est utile lorsque vous utilisez déjà le déploiement canari de bout en bout dans MSE, car les workers SchedulerX récupèrent les mêmes labels sans configuration supplémentaire.
Créer une tâche canari dédiée
Copiez la tâche de production pour créer une tâche canari distincte, puis attribuez des labels afin d'isoler le trafic entre les deux.
Ajoutez le label
prodà la tâche de production.Copiez la tâche de production pour créer une tâche canari.
Ajoutez le label
grayà la tâche canari.Exécutez la tâche canari pour valider les résultats sur les workers portant le label
gray.
Une fois la validation réussie, mettez à jour la tâche de production avec les modifications validées et supprimez la tâche canari.
En cas d'échec de la validation, supprimez la tâche canari. La tâche de production continue de s'exécuter sur les workers portant le label prod sans interruption.
Exécuter un test canari ponctuel
Pour valider une seule exécution sur un worker canari sans dupliquer la tâche, déclenchez manuellement la tâche existante sur un label spécifique dans la console SchedulerX.
Dans la console SchedulerX, localisez la tâche.
Sélectionnez run the specified label once et choisissez le label
gray.La tâche s'exécute une fois sur le worker portant le label
gray. La planification de production régulière continue de s'exécuter sans modification sur les workers portant le labelprod.
Automatiser l'exécution ponctuelle avec CI/CD
Utilisez des outils d'intégration continue tels que Jenkins pour déclencher automatiquement l'exécution canari ponctuelle. Cela intègre la validation canari dans votre pipeline de déploiement, de sorte que chaque version soit validée sur les workers canaris avant promotion.
