Argo Workflows et Argo Events : orchestrer des chaînes de traitements sur Kubernetes

Ce que fait Argo Workflows

Argo Workflows exécute des chaînes de traitements sur Kubernetes : des étapes qui s'enchaînent, se passent des fichiers, tournent en parallèle quand elles le peuvent, et reprennent là où elles ont échoué. Une chaîne est un fichier YAML : elle se relit, se versionne et se revoit comme le reste de votre infrastructure.

Argo Events la déclenche : à l'heure dite, à l'arrivée d'un fichier, à la réception d'un message, sur un webhook, ou sur un changement dans le cluster.

Ce que Kubernetes ne sait pas faire seul

Un Job exécute un traitement jusqu'à son terme, et s'arrête là. Dès que le travail a plusieurs étapes, quatre choses lui manquent : dire qu'une étape en attend une autre, passer un fichier de l'une à l'autre, rejouer la même chaîne avec d'autres paramètres, et reprendre à l'étape qui a échoué plutôt qu'au début.

C'est exactement ce vide que comble Argo Workflows, et la formation détaille chacun de ces quatre points, mesures à l'appui.

Trois familles d'usage

Une chaîne de traitements n'est pas réservée au batch de nuit, et la mécanique est la même partout. Les traitements par lots montrent le mieux l'ordre des étapes, les fichiers échangés et la reprise. Les chaînes CI/CD montrent le paramétrage, les matrices de tests et l'intégration à une forge. L'automatisation d'infrastructure montre les sorties qui décident de la suite et les boucles sur un inventaire.

Le décor bancaire reste le principal, mais chaque chapitre puise son exemple complet dans l'une ou l'autre de ces familles.

Objectifs

1. Décrire une chaîne de traitements avec ses étapes, ses dépendances et ses paramètres, dans un fichier qu'une équipe peut relire et versionner.

2. Faire circuler des fichiers entre les étapes, et comprendre pourquoi un volume partagé ne suffit pas à l'échelle.

3. Réutiliser une définition entre plusieurs chaînes, et la planifier sur un calendrier.

4. Exploiter au quotidien : reprendre après un échec, borner le parallélisme, respecter une fenêtre, archiver l'historique, alerter la bonne équipe.

5. Déclencher sur événement, à l'arrivée d'un fichier ou d'un message, plutôt qu'à heure fixe.

6. Reprendre un existant : lire les définitions d'un ordonnanceur en place et en générer les chaînes par un script, plutôt que de les réécrire à la main.

7. Assembler le tout sur un cas complet, et le recevoir sur des critères exécutables plutôt que sur une impression.

Un conteneur simule un ordonnanceur en place pour l'objectif 6. Il est écrit pour la formation, ne reproduit aucun produit existant, et son format est inventé.

Comment cette formation est faite

Chaque commande, chaque sortie de terminal et chaque durée publiée ici a été exécutée sur un cluster réel, sous Argo Workflows 4.1 et Argo Events 1.9. Les résultats contrariants aussi : quand une mesure contredit ce qui se raconte, c'est la mesure qui est écrite, avec les chiffres.

Tous les chapitres suivent la même trame : le problème, les termes à définir, la démonstration mesurée, un exemple complet qu'on peut copier et exécuter en entier, les pièges qui coûtent une demi-journée, puis ce qu'il faut retenir.

Le lab

Un cluster Kubernetes de quatre machines, un plan de contrôle et trois nœuds de travail, 4 vCPU et 4 Go de mémoire chacun. Un registre d'images et un serveur Git complètent le décor.

Vous pouvez les créer en quelques minutes sur CETIC Cloud Platform : à la création du compte, une fois l'adresse e-mail activée, 180 euros de crédit sont offerts, valables un mois, largement de quoi suivre toute la formation.

Prérequis

Kubernetes au niveau du quotidien : Pod, Deployment, Job, ConfigMap, et l'usage courant de kubectl. La ligne de commande. Savoir lire un programme suffit, quel que soit son langage : il n'est jamais demandé d'en écrire.

Aucune connaissance préalable d'Argo n'est nécessaire. La formation Argo CD du même atelier n'est pas un prérequis, mais les deux se complètent : celle-ci déploie des traitements, l'autre déploie des applications.