Revenir à la version précédente de KCL

Cette rubrique explique comment rétablir la version précédente de KCL dans votre application client. Le processus de restauration comprend deux étapes :

1. Exécutez l'outil de migration KCL.

2. Redéployez le code de la version précédente de KCL.

Étape 1 : Exécuter l'outil de migration KCL

Lorsque vous devez revenir à la version précédente de KCL, vous devez exécuter l'outil de migration KCL. L'outil exécute deux tâches importantes :

• Il supprime une table de métadonnées appelée table des métriques de travail et un index secondaire global sur la table des baux dans DynamoDB. Ces artefacts sont créés par KCL 3.x mais ne sont pas nécessaires lorsque vous revenez à la version précédente.

• Il permet à tous les travailleurs de fonctionner dans un mode compatible avec KCL 1.x et de commencer à utiliser l'algorithme d'équilibrage de charge utilisé dans les versions précédentes de KCL. Si vous rencontrez des problèmes avec le nouvel algorithme d'équilibrage de charge dans KCL 3.x, cela les atténuera immédiatement.

Important

La table d'état des coordinateurs dans DynamoDB doit exister et ne doit pas être supprimée pendant les processus de migration, de restauration et de restauration anticipée.

Note

Il est important que tous les employés de votre application grand public utilisent le même algorithme d'équilibrage de charge à un moment donné. L'outil de migration KCL garantit que tous les utilisateurs de votre application grand public KCL 3.x passent en mode compatible avec KCL 1.x afin qu'ils exécutent le même algorithme d'équilibrage de charge lors du retour de l'application à la version KCL précédente.

Vous pouvez télécharger l'outil de migration KCL dans le répertoire des scripts du référentiel KCL GitHub. Exécutez le script à partir d'un utilisateur ou d'un hôte disposant des autorisations appropriées pour écrire dans la table d'état des coordinateurs, la table des métriques des travailleurs et la table des baux. Assurez-vous que les autorisations IAM appropriées sont configurées pour les applications grand public KCL. Exécutez le script une seule fois par application KCL à l'aide de la commande spécifiée :

python3 ./KclMigrationTool.py --region region --mode rollback [--application_name applicationName] [--lease_table_name leaseTableName] [--coordinator_state_table_name coordinatorStateTableName] [--worker_metrics_table_name workerMetricsTableName]

Paramètres

--region

regionRemplacez-le par votre Région AWS.

--application_name

Ce paramètre est obligatoire si vous utilisez des noms par défaut pour vos tables de métadonnées DynamoDB (table des baux, table des états des coordinateurs et table des métriques des travailleurs). Si vous avez défini des noms personnalisés pour ces tables, vous pouvez omettre ce paramètre. applicationNameRemplacez-le par le nom réel de votre application KCL. L'outil utilise ce nom pour dériver les noms de table par défaut si aucun nom personnalisé n'est fourni.

--lease_table_name

Ce paramètre est nécessaire lorsque vous avez défini un nom personnalisé pour la table des baux dans votre configuration KCL. Si vous utilisez le nom de table par défaut, vous pouvez omettre ce paramètre. leaseTableNameRemplacez-le par le nom de table personnalisé que vous avez spécifié pour votre table de location.

--coordinator_state_table_name

Ce paramètre est nécessaire lorsque vous avez défini un nom personnalisé pour la table d'état des coordinateurs dans votre configuration KCL. Si vous utilisez le nom de table par défaut, vous pouvez omettre ce paramètre. coordinatorStateTableNameRemplacez-le par le nom de table personnalisé que vous avez spécifié pour votre table d'état des coordinateurs.

--worker_metrics_table_name

Ce paramètre est nécessaire lorsque vous avez défini un nom personnalisé pour la table des métriques de travail dans votre configuration KCL. Si vous utilisez le nom de table par défaut, vous pouvez omettre ce paramètre. workerMetricsTableNameRemplacez-le par le nom de table personnalisé que vous avez spécifié pour votre tableau des métriques des travailleurs.

Étape 2 : redéployer le code avec la version précédente de KCL

Important

Toute mention de la version 2.x dans la sortie générée par l'outil de migration KCL doit être interprétée comme faisant référence à la version 1.x de KCL. L'exécution du script n'effectue pas de restauration complète, elle fait uniquement passer l'algorithme d'équilibrage de charge à celui utilisé dans la version 1.x de KCL.

Après avoir exécuté l'outil de migration KCL pour effectuer une annulation, l'un des messages suivants s'affiche :

Message 1

« Annulation terminée. Votre application exécutait deux fois plus de fonctionnalités compatibles. Revenez aux fichiers binaires de votre application précédente en déployant le code avec votre version précédente de KCL. »

Action requise : Cela signifie que vos travailleurs fonctionnaient en mode compatible avec KCL 1.x. Redéployez le code avec la version précédente de KCL auprès de vos employés.

Message no 2

« Annulation terminée. Votre application KCL exécutait 3 fois plus de fonctionnalités et reviendra à 2 fois plus de fonctionnalités compatibles. Si aucune atténuation ne s'affiche après un court laps de temps, veuillez revenir aux fichiers binaires de votre application précédente en déployant le code avec votre version précédente de KCL. »

Action requise : Cela signifie que vos travailleurs fonctionnaient en mode KCL 3.x et que l'outil de migration KCL a fait passer tous les travailleurs en mode compatible avec KCL 1.x. Redéployez le code avec la version précédente de KCL auprès de vos employés.

Message 3

« La candidature a déjà été annulée. Toutes KCLv3 les ressources susceptibles d'être supprimées ont été nettoyées afin d'éviter des frais jusqu'à ce que l'application puisse être reportée avec la migration. »

Action requise : Cela signifie que vos travailleurs ont déjà été restaurés pour fonctionner en mode compatible avec KCL 1.x. Redéployez le code avec la version précédente de KCL auprès de vos employés.