Déployer des batchs cloud native avec Spring Cloud Data Flow
Dans mon dernier article, j’ai tenté de faire un état des lieux des solutions possibles pour implémenter des batchs cloud natifs.
J’ai par la suite testé plus en détails les jobs et cron jobs Kubernetes en essayant d’avoir une vue OPS sur ce sujet. Le principal inconvénient (qui ne l’est pas dans certains cas) des jobs est qu’on ne peut pas les rejouer. Si ces derniers sont terminés avec succès - Vous allez me dire, il faut bien les coder - mais qu’on souhaite les rejouer pour diverses raisons, on doit les supprimer et relancer. J’ai vu plusieurs posts sur StackOverflow à ce sujet, je n’ai pas trouvé de solutions satisfaisantes relatifs à ce sujet.
Attention, je ne dis pas que les jobs et cron jobs ne doivent pas être utilisés. Loin de là.
Je pense que si vous avez besoin d’un traitement sans chaînage d’actions, sans rejeu, les jobs et cron jobs sont de bonnes options. Le monitoring et reporting des actions réalisées peut se faire par l’observabilité mise en place dans votre cluster K8S.
Après plusieurs recherches, je suis tombé sur Spring Data Flow. L’offre de ce module de Spring Cloud va au delà des batchs. Il permet notamment de gérer le streaming via une interface graphique ou via son API.
Dans cet article, je vais implémenter un exemple et le déployer dans Minikube.
1 Installation et configuration de Minikube
L’installation de minikube est décrite sur le site officiel.
Pour l’installer, j’ai exécuté les commandes suivantes:
|
|
Au premier démarrage, vous finirez l’installation
|
|
1.1 Installation de Spring Cloud Data Flow
Pour installer Spring Cloud Data Flow directement dans Kubernetes, vous pouvez exécuter les commandes suivantes:
|
|
Après quelques minutes de téléchargement, vous devriez avoir le retour suivante à l’exécution de la commande kubectl get pods
|
|
1.2 Accès au dashboard
Pour accéder au dashboard de Spring Cloud Data Flow, vous pouvez lancer les commandes suivantes:
|
|
Ensuite, vous pourrez accéder à la console web via l’URL http://localhost:8080/dashboard
.
2 Développement d’une Task
J’ai crée une simple task qui va rechercher la nationalité d’un prénom. Pour ceci, j’utilise l’API https://api.nationalize.io/.
On passe un prénom en paramètre et on obtient une liste de nationalités possibles avec leurs probabilités.
Vous trouverez les sources de cet exemple sur mon Github.
Aussi, la documentation est bien faite, il suffit de la lire.
2.1 Initialisation
J’ai initié un projet Spring avec les dépendances suivantes:
|
|
Attention, les starters et dépendances JDBC/MariaDB sont indispensables pour que votre tâche puisse enregistrer le statut des exécutions.
2.2 Construction de la tâche
Une tâche se crée facilement en annotation une classe “Configuration” par l’annotation @EnableTask
|
|
Ensuite l’essentiel du job s’effectue dans la construction d’un bean CommandLineRunner
:
|
|
Dans mon exemple, j’affiche dans la sortie standard le payload de l’API ainsi que le code HTTP de la réponse.
Voici un exemple d’exécution :
|
|
2.3 Packaging
Ici rien de nouveau, il suffit de lancer la commande:
|
|
3 Déploiement
3.1 Création et déploiement de l’image Docker
Pour déployer notre toute nouvelle tâche, nous allons d’abord créer l’image Docker avec buildpack.
Tout d’abord on va se brancher sur minikube pour que notre image soit déployée dans le repository de minikube
|
|
Ensuite, il nous reste à créer l’image Docker
|
|
Pour vérifier que votre image est bien présente dans minikube, vous pouvez exécuter la commande suivante:
|
|
3.2 Création de l’application
Avant de créer la tâche dans l’interface, il faut d’abord référencer l’image Docker en créer une application:
Il faut déclarer l’image Docker avec le formalisme présenté dans la capture d’écran.
3.3 Création de la tâche
Voici les différentes actions que j’ai réalisé via l’interface:
4 Exécution
Maintenant, il nous est possible de lancer notre tâche. Vous trouverez dans les copies d’écran ci-dessous les différentes actions que j’ai réalisé pour exécuter ma toute nouvelle tâche.
J’ai pu également accéder aux logs.
Il est également important de noter qu’ après l’exécution d’une tâche, le POD est toujours au statut RUNNING
afin que Kubernetes ne redémarre pas automatiquement le traitement.
|
|
A chaque exécution il y aura donc un pod d’alloué.
5 Aller plus loin
Parmi les fonctionnalités que j’ai découvert, on peut :
- relancer un traitement
- le programmer
- nettoyer les exécutions
- les pistes d’audit
- le chaînage des différentes tâches
Gros inconvénient pour le nettoyage: je n’ai pas constaté un impact dans les pods alloués.
6 Conclusion
Pour résumer, je vais me risquer à comparer les deux solutions jobs/cron jobs Kubernetes et une solution basée sur Spring Cloud Dataflow. Je vais donc utiliser la liste des caractéristiques présentée par M. Richards et N. Ford dans leur livre: Fundamentals of Software Architecture1.
Bien évidemment, cette notation est purement personnelle. Vous noterez que selon où on positionne le curseur, l’une des deux solutions peut s’avérer meilleure (ou pas).
Bref, tout dépend de vos contraintes et de ce que vous souhaitez en faire. A mon avis, une solution telle que Spring Cloud Dataflow s’inscrit parfaitement pour des traitements mixtes (streaming, batch) et pour des traitements Big Data.
N’hésitez pas à me donner votre avis (sans troller svp) en commentaire ou si ça concerne l’exemple, directement dans Github.
Architecture characteristic | K8s job rating | Spring Cloud Dataflow rating |
---|---|---|
Partitioning type | Domain & technical | Domain & technical |
Number of quanta 2 | 1 | 1 to many |
Deployability | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
Elasticity | ⭐⭐⭐ | ⭐⭐⭐⭐ |
Evolutionary | ⭐⭐⭐ | ⭐⭐⭐⭐ |
Fault Tolerance | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
Modularity | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
Overall cost | ⭐⭐⭐⭐ | ⭐⭐⭐ |
Performance | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
Reliability | ⭐⭐⭐⭐ | ⭐⭐⭐ |
Scalability | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
Simplicity | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
Testability | ⭐⭐⭐ | ⭐⭐⭐⭐ |