Depuis des années, la conteneurisation a été décrite comme incontournable dans le monde DevOps, en plus de ses innombrables avantages en termes de développement et de test. Je vais vous parler des avantages à dockeriser vos jobs Talend, comment les exploiter et comment adapter l’environnement de ces conteneurs à vos besoins.
Job2docker
Pour que Talend ne soit pas en reste alors que la containerisation a le vent en poupe, Job2docker a été créé. La première release date de juillet 2018. Il s’agit d’un projet qui permet de convertir un job Talend en image Docker. Au sein de l’image résultante, seul notre job est lancé et est créé pour les développeurs afin qu’ils puissent l’utiliser pendant leur développement, leurs tests et / ou le débogage.
Les jobs Talend sont conçus pour fonctionner immédiatement, car ils ne sont finalement que de simples applications Java (du moins pour Talend Data Integration). Ces applications sont autonomes et ont tout inclus pour leur fonctionnement, elles peuvent donc être facilement déclarées dans un Dockerfile et lancées en toute la sécurité du moment que toutes les dépendances ont été incluses et correctement installées.
Si tout fonctionne correctement, pourquoi dockeriser nos jobs?
Parmi de nombreuses autres raisons, voici celles qui, à mon avis, sont les plus importantes:
- Nous connaissons déjà l’environnement dans lequel notre job va être exécuté : Il n’est pas nécessaire d’improviser lorsque nous installons l’environnement pour nos jobs, car c’est nous qui l’avons créé, nous sommes certains que nos jobs seront lancés dans le même environnement que celui dans lequel nous l’avons développé.
- Le démarrage et l’intégration ne seraient plus un problème : Étant donné que les jobs sont des conteneurs, ils peuvent être intégrés à n’importe quelle machine avec Docker inclus. Ainsi, nous pourrions par exemple inclure le TAC (et d’autres services Talend) dans des conteneurs et tirer parti des fonctionnalités d’intégration facile de Docker. Nous pouvons également créer rapidement un Proof Of Concept (PoC) pour les clients qui veulent un test fonctionnel pour un projet.
- CI / CD : Comme les jobs sont des images Docker, ils peuvent être enregistrées dans un Registry Docker, et par conséquent ils peuvent être facilement gérés et, si nécessaire, restaurés en quelques secondes. Pas besoin de désinstaller et de réinstaller des environnements ou des jobs et comme ils sont indépendants les uns des autres (chacun a son Java et ses dépendances), il n’y a pas à craindre qu’une désinstallation ou une modification d’un job en affecte un autre.
- Test dans différents environnements : Comme nos images Docker sont créées à partir d’un Dockerfile, elles sont facilement modifiables. Par exemple, nous pourrions tester nos jobs dans différentes versions de Java, avec différents certificats SSL, avec des autorisations différentes pour les utilisateurs. Enfin, nous avons la liberté de jouer avec les environnements que nous créons spécialement pour les tests.
- Scalabilité -> Pas de surexploitation ou de sous-emploi des machines : Si notre projet est dans le cloud, nous pouvons utiliser n’importe quel système d’orchestration de conteneur, tel que Kubernetes, pour créer des règles permettant de construire ou de détruire automatiquement des conteneurs en fonction du besoin de traitement.
- Reproduction facile des jobs : Le même job peut être exécuté dans différents clients. Par exemple, si nous avons un job qui récupère les régions en France et les stocke dans un fichier, il est très probable que nous l’utiliserons dans plus d’un projet. Dans ce cas, il suffit d’ajouter l’exécution de ce job à notre flux de travail. Si celui-ci existe déjà, il ne suffit que de changer la version du job et un flux de travail CI / CD (par exemple) se débrouille pour récupérer cette nouvelle version à partir du Registry et mettre à jour nos jobs pour tous les projets impliqués .
- Sécurité : Le conteneur peut être créé en mode ‘lecture seule’ et n’expose que le(s) port(s) dont nous avons réellement besoin.
- Administration des ressources sur une machine : Avec Kubernetes, il est facile d’attribuer une partie des ressources du serveur d’exécution aux conteneurs. Par exemple, nous pourrions créer des stratégies pour que le Job1 ne consomme que 30% de la mémoire RAM, tandis que le Job2, dont on sait qu’il a un traitement plus lourd, consomme les 70% restants.
Ok, vous m’avez convaincu, comment puis-je le faire ?
1. Clonez le projet
git clone https://github.com/Talend/job2docker.git
Un dossier appelé job2docker sera créé avec le projet git téléchargé.
2.Lancez le setup pour l’installation
cd job2docker
./job2docker-setup
Notez qu’à la fin, le message de la console vous indique où se trouve le script à partir duquel le « listener » peut être lancé.
3.Lancez le “listener” : Job2Docker_listener
cd /home/yabir/talend/
./job2docker_listener
A partir du moment où le script « listener » est lancé, il « écoutera » tous les jobs buildés dans le dossier indiqué. (Dans mon cas c’est ‘/ home / yabir / shared_jobs’)
Ne fermez pas ce terminal !
Ne vous inquiétez pas de l’erreur sur la première ligne de la console. Ceci est un bug du projet et n’interfère pas avec le fonctionnement du projet.
4. Buildez votre job et enregistrez-le dans le dossier partagé avec le listener
a.Pour le test, j’ai créé un job appelé j_hello_synaltic (notez le nom en minuscule), dans lequel je montre le message « Hello Synaltic » dans la console à l’aide d’un tFixedFlowInput et d’un tLogRow, comme indiqué dans l’image suivante.
b. dans l’onglet ‘Référentiel’, double cliquez sur le job et cliquez sur “Construire le job”
c. Indiquez que vous souhaitez enregistrer le job compilé dans le dossier écouté par le « listener ». Remarque: si vous avez deux écrans, localisez la console du listener sur le deuxième écran pour vérifier les logs de job2docker.
Quelques secondes après avoir cliqué sur le bouton Finish, sur la console du listener, nous pouvons voir que job2docker reconnaît le zip et commence son traitement. À la fin des ses logs, il y a des messages intéressants, tels que le point d’entrée Dockerfile (entrypoint) laquelle est lancé lors de la création d’un conteneur. Nous pouvons voir aussi à la fin qu’il n’y a pas eu d’erreur dans la construction de l’image.
Vous pouvez valider que l’image a été bien créée en lançant « docker images » sur la console bash :
5. Finalement, lancez votre job en créant un conteneur à partir de l’image créée par job2docker.
Une fois que vous avez créé l’image Docker, elle peut être publiée dans n’importe quel Docker Registry et faire partie de votre flux de travail CI / CD.
Bug trouvé et améliorations
Vous ne pouvez pas dockeriser les jobs dont le nom contient des lettres majuscules! C’est pourquoi j’ai fait un fork du projet depuis le github de Talend, j’ai corrigé le problème et j’ai suggéré ma modification à Talend. Pendant que ceci est validé, vous pouvez cloner ma version dans notre Gitlab. J’ai aussi ajouté l’inclusion du nom du client et du nom du projet au nom de l’image créée, par exemple : synaltic/gameofthrones/hellojontargaryen:0.1 en suivant le format {client}/{projet}/{job}:{version}.
Architecture CI / CD
Job2docker est totalement intégré à une stack Talend Cloud open source. Par exemple, nous pourrions implémenter le use case suivant pour automatiser les tests et les mises en production :
- Le développeur crée le job et fait le commit vers le Git (dans Talend Open Studio manuellement ou dans la version Pro en clicant sur « Push vers Git »).
- Jenkins reconnaît le changement dans le code et exécute les tâches suivantes :
- Construction du job dans Maven et dans le répertoire partagé de job2docker (afin que l’image soit créée).
- Une fois l’image créée, elle est enregistrée dans le Docker Registry pour être ré-utilisée dans d’autres flux de travail.
- Enfin, nous pouvons utiliser Airflow pour créer un plan d’exécution.
Toutes ces briques peuvent être implémentées en utilisant Kubernetes pour faciliter le paramétrage et le DevOps.
N’oubliez pas de suivre les bonnes pratiques recommandées par Talend.
Merci !
Bonsoir,
Tout d’abord merci pour ce tuto !
J’ai quelques questions qui en découlent :
– Dans GIT, qu’est-ce qui est déposé exactement ? Juste le code source et non le build ?
– Dans la partie Jenkins, comment se fait le build des jobs ? Est-ce qu’on envoi le build généré par le commandline/studio ou bien il est nécessaire de créer un script permettant de builder le job ?
Merci 🙂
Bonjour,
Merci pour votre retour.
Voici mes réponses :
– C’est juste le code source qui est enregistré dans Git.
– Il est nécessaire de créer un script (ou « pipeline ») pour builder les jobs. Ici un exemple de comment le faire à partir du code source : https://www.jenkins.io/doc/tutorials/build-a-java-app-with-maven/
Bonjour,
Merci pour le tuto, très intéressant.
J’ai une question concernant ce passage :
« Jenkins reconnaît le changement dans le code et exécute les tâches suivantes :
– Construction du job dans Maven et dans le répertoire partagé de job2docker (afin que l’image soit créée).
»
Est-il possible avec la version Talend Open Source de générer un build directement depuis les sources GIT, avec Jenkins par exemple, sans le module Talend CommandLine (réservé à la version payante) et le plugin Maven CI/CD ?
Avez-vous un exemple d’implémentation ?
Le lien que vous avez mentionné dans votre réponse à un commentaire concerne une app java, mais j’imagine que les jobs Talend et particulièrement les routes et webServices ont des spécificités non ?
Merci d’avance de votre retour 🙂
Bonjour,
Si vous voulez le tenter et merci de nous faire vos retours…
Il existe certaines personnes de la communauté qui ont élaboré et partager de telle fonctionnalités
https://github.com/TalendStuff
En espérant vous éclairer.