contrôleur de travailleur temporel

Contrôleur des travailleurs temporaires

Ce projet est 100% expérimental. Veuillez ne pas tenter d'installer le contrôleur dans un environnement de production et/ou partagé.

L’objectif de Temporal Worker Controller est de faciliter l’exécution de Workers sur Kubernetes tout en tirant parti du Worker Versioning.

Pourquoi

Les contraintes déterministes de Temporal peuvent causer des problèmes lors du déploiement ou de l'annulation des modifications du code du workflow.

L'approche traditionnelle du déterminisme des flux de travail consiste à intégrer de nouveaux comportements derrière les contrôles de version. Au fil du temps, ces vérifications peuvent devenir une source de dette technique, car les supprimer en toute sécurité d'une base de code est un processus minutieux qui implique souvent d'interroger tous les flux de travail en cours d'exécution.

La gestion des versions des travailleurs est une approche alternative qui permet aux exécutions de flux de travail de rester fidèles aux travailleurs exécutant une révision de code spécifique. Cela permet à un auteur de flux de travail d'omettre les vérifications de version dans le code et d'exécuter plusieurs versions de son travailleur en parallèle, en s'appuyant sur Temporal pour que les exécutions de flux de travail restent épinglées sur les travailleurs exécutant du code compatible.

Ce projet vise à fournir une automatisation qui simplifie la comptabilité autour du suivi des versions de travail qui ont encore des flux de travail actifs, de la gestion du cycle de vie des déploiements de travailleurs versionnés et de l'appel des API temporelles pour mettre à jour la version par défaut après un déploiement.

Caractéristiques

• Enregistrement des nouvelles versions de travail

• Création de ressources de déploiement de travailleurs versionnés

• Suppression des déploiements de travailleurs inaccessibles

• Déploiements manuels, bleu/vert et progressifs des nouvelles versions de Worker

• Mise à l'échelle automatique des déploiements de travailleurs

• Basculement automatisé vers des versions de travail compatibles

• Analyse Canary des nouvelles versions de travail

• Annulation facultative après expiration du délai pour les workflows sur les anciennes versions

• Passer le signal ContinueAsNew aux workflows sur les anciennes versions

Usage

Afin d'être compatibles avec ce contrôleur, les Workers doivent être configurés à l'aide de ces variables d'environnement standard :

• WORKER_BUILD_ID

• TEMPORAL_HOST_PORT

• TEMPORAL_TASK_QUEUE

• TEMPORAL_NAMESPACE

Chacun d'entre eux sera automatiquement défini dans l'environnement du modèle de pod et n'aura pas besoin d'être spécifié manuellement en dehors de la spécification TemporalWorker .

Comment ça marche

Chaque ressource TemporalWorker gère une ou plusieurs ressources Deployment standard. Chaque déploiement gère des pods qui à leur tour interrogent Temporal pour les tâches épinglées sur leurs versions respectives.

 organigramme TD
    wd[TemporalWorker]

    sous-graphique "Dernière version du travailleur/par défaut"
        d5["Déploiement v5"]
        rs5["ReplicaSet v5"]
        p5a["Pod v5-a"]
        p5b["Pod v5-b"]
        p5c["Pod v5-c"]
        d5 --> rs5
        rs5 --> p5a
        rs5 --> p5b
        rs5 --> p5c
    fin

    sous-graphe "Versions de travail obsolètes"
        d1["Déploiement v1"]
        rs1["ReplicaSet v1"]
        p1a["Pod v1-a"]
        p1b["Pod v1-b"]
        d1 --> rs1
        rs1 --> p1a
        rs1 --> p1b

        dN["Déploiement..."]
    fin

    wd --> d1
    wd --> dN
    wd --> d5

    p1a-. "sondage version v1" .-> serveur
    p1b-. "sondage version v1" .-> serveur

    p5a -. "sondage version v5" .-> serveur
    p5b-. "sondage version v5" .-> serveur
    p5c-. "sondage version v5" .-> serveur

    serveur["Serveur temporel"]

Cycle de vie des travailleurs

Lorsqu'une nouvelle version de travailleur est déployée, le contrôleur de travail automatise l'enregistrement d'une nouvelle version de travail par défaut dans Temporal.

À mesure que les anciens flux de travail terminent leur exécution et que les versions de travail obsolètes ne sont plus nécessaires, le contrôleur de travail libère également des ressources en supprimant les anciens déploiements.

 diagramme de séquence
    numérotation automatique
    participant Dev en tant que développeur
    participant K8 en tant que Kubernetes
    participant Ctl en tant que WorkerController
    participant T comme temporel

    Dev->>K8s : Créer TemporalWorker "foo" (v1)
    K8s ->> Ctl : Notifier TemporalWorker "foo" créé
    Ctl->>K8s : Créer un déploiement "foo-v1"
    Ctl->>T : Enregistrer la v1 comme nouvelle valeur par défaut
    Dev->>K8s : mettre à jour TemporalWorker "foo" (v2)
    K8s-->>Ctl : Notifier TemporalWorker "foo" mis à jour
    Ctl->>K8s : Créer un déploiement "foo-v2"
    Ctl->>T : Enregistrer la v2 comme nouvelle valeur par défaut

        Ctl->>Ctl : exécuter la détection des changements avec rupture entre la v1 et la v2
    Ctl->>T : Si versions compatibles, fusionner v1 et v2.

        API temporelle de sondage en boucle
        Ctl-->>T : Attendez la fermeture des exécutions du workflow v1
    fin

        Ctl->>K8s : Supprimer le déploiement "foo-v1"

Contribuer

Ce projet en est à ses débuts ; en tant que telles, les contributions de code externes ne sont pas encore sollicitées.

Les rapports de bogues et les demandes de fonctionnalités sont les bienvenus ! Veuillez déposer un problème.

Vous pouvez également contacter @jlegrone sur Temporal Slack si vous avez des questions, des suggestions ou si vous souhaitez apporter d'autres contributions.