Automatisation CI/CD avec Apache Hop : exemples pratiques pour des pipelines fiables

Introduction

Apache Hop est une plateforme d'intégration de données open source qui permet de concevoir et d'exécuter des pipelines de données de manière visuelle. À mesure que les équipes développent leurs opérations de données, elles ont besoin de pratiques CI/CD (Continuous Integration/Continuous Delivery, intégration et livraison continues) pour déployer les pipelines de manière fiable. Cet article fournit des exemples pratiques pour automatiser le déploiement, la configuration, la vérification et le retour en arrière des pipelines Apache Hop.

Nous nous adressons aux développeurs, consultants DevOps et équipes techniques de startups qui recherchent la sécurité opérationnelle. Vous apprendrez à vérifier votre environnement, à effectuer des modifications contrôlées, à valider les résultats et à récupérer après un échec. Chaque étape inclut des commandes concrètes, les sorties attendues, les signaux d'échec et les chemins de récupération.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, éviter les secrets dans les commandes, vérifier les résultats et savoir comment revenir en arrière. Nous utilisons des espaces réservés comme <HOP_HOME> et <ENVIRONMENT> au lieu d'identifiants réels ou de production.

Inventaire de la version et de l'environnement

Avant d'automatiser quoi que ce soit, sachez ce que vous avez. Cette section couvre les commandes d'inventaire essentielles et les vérifications pour le CI/CD Apache Hop.

Version installée et topologie de déploiement

Tout d'abord, identifiez la version d'Apache Hop et la manière dont il est déployé (autonome, en cluster ou conteneurisé). Utilisez la CLI Hop ou vérifiez le répertoire d'installation.

Exemple de commande (lecture seule) :

cd <HOP_HOME>
./hop-conf.sh --version

Sortie attendue :

Apache Hop 2.1.0

Si la version est antérieure à 2.0, consultez les notes de mise à niveau avant de continuer.

La topologie de déploiement est importante : si vous utilisez Hop Server (exécution à distance), vérifiez que le serveur est joignable.

Exemple de commande :

curl -s http://<HOP_SERVER_HOST>:8080/hop/status

Sortie attendue :

{"status":"UP"}

Enregistrez la sortie et l'horodatage dans votre document d'inventaire.

Prérequis

Assurez-vous d'avoir :

• Java 11 ou supérieur (Hop 2.x nécessite Java 11+).
• Les variables d'environnement définies : HOP_HOME, HOP_CONFIG_FOLDER.
• L'accès au contrôle de version pour les pipelines et les configurations.
• Git installé et configuré.

Exemple de vérification :

java -version

Sortie attendue :

openjdk version "11.0.20" 2023-07-18

Si ce n'est pas le cas, installez Java 11 avant de continuer.

Observation en lecture seule

Commencez toujours par une commande en lecture seule pour comprendre l'état actuel. Par exemple, listez tous les projets dans Hop :

./hop-run.sh -j list_projects -f <HOP_CONFIG_FOLDER>

Sortie attendue :

Projects:
  - sales_etl
  - marketing_etl

Cela vous indique quels pipelines existent et leurs noms.

Changement minimal justifié

Lorsque vous modifiez la configuration, changez un élément à la fois. Exemple : mettre à jour une chaîne de connexion à une base de données dans un projet partagé. D'abord, affichez la valeur actuelle :

./hop-conf.sh -p sales_etl -g <ENVIRONMENT> -c database_connection -a show

Sortie attendue :

Current value: jdbc:postgresql://old-db-host:5432/sales

Planifiez ensuite le changement : mettre à jour vers jdbc:postgresql://new-db-host:5432/sales avec un plan de retour en arrière.

Signal de vérification

Après tout changement, vérifiez avec une commande qui affiche la nouvelle valeur :

./hop-conf.sh -p sales_etl -g <ENVIRONMENT> -c database_connection -a show

Sortie attendue :

Current value: jdbc:postgresql://new-db-host:5432/sales

Si la sortie ne correspond pas, revenez à la valeur précédente.

Chemin de configuration sécurisé

Les changements de configuration sont courants en CI/CD. Cette section montre comment les effectuer en toute sécurité à l'aide de fichiers de configuration spécifiques à l'environnement et des outils intégrés de Hop.

Utiliser des configurations spécifiques à l'environnement

Apache Hop prend en charge les dossiers de configuration pour différents environnements (dev, test, prod). Stockez les détails de connexion et les variables dans des fichiers spécifiques à l'environnement, et non en dur dans les pipelines.

Exemple :

Dans <HOP_CONFIG_FOLDER>/environments/prod/config.xml, définissez une variable :

<hop-config>
  <variable>
    <name>DB_HOST</name>
    <value>prod-db.internal</value>
  </variable>
</hop-config>

Dans votre pipeline, référencez ${DB_HOST}. Cela garde les secrets hors de votre dépôt et permet des substitutions par environnement.

Gestion des changements avec Git

Versionnez vos pipelines et configurations dans Git. Par exemple, une structure de dépôt :

hop-pipelines/
  projects/
    sales_etl/
      main.hpl
      transform.hpl
  config/
    dev/
      config.xml
    prod/
      config.xml

Lorsque vous devez modifier un pipeline, créez une branche :

git checkout -b feature/update-sales-connection

Faites les modifications, testez localement, puis fusionnez via une demande de tirage (pull request) après revue.

Appliquer les changements de configuration

Après la fusion, appliquez la nouvelle configuration à l'environnement cible.

Exemple de commande :

./hop-conf.sh -p sales_etl -g prod -c database_connection -a update -v "jdbc:postgresql://new-db-host:5432/sales"

Sortie attendue :

Configuration updated successfully.

Vérifiez ensuite comme indiqué précédemment.

Rayon d'impact et retour en arrière

Avant d'appliquer, déterminez le rayon d'impact : quels pipelines utilisent cette configuration ? Utilisez le vérificateur de dépendances de Hop :

./hop-run.sh -j list_dependencies -p sales_etl -f <HOP_CONFIG_FOLDER>

Cela liste tous les pipelines qui dépendent de l'élément de configuration.

Pour revenir en arrière, inversez le changement :

./hop-conf.sh -p sales_etl -g prod -c database_connection -a update -v "jdbc:postgresql://old-db-host:5432/sales"

Testez ce chemin de récupération dans un environnement de préproduction avant de vous y fier en production.

Vérification et diagnostics

Après le déploiement d'un pipeline, vérifiez qu'il fonctionne comme prévu. Cette section couvre les tests fonctionnels et les diagnostics.

Exécuter un pipeline en mode test

Apache Hop peut exécuter un pipeline et capturer des métriques sans écrire dans la cible (selon la conception du pipeline). Pour un test simple, exécutez le pipeline avec un nombre limité de lignes.

Exemple de commande :

./hop-run.sh -j main -p sales_etl -f <HOP_CONFIG_FOLDER> -r "first=10"

Sortie attendue :

Pipeline executed successfully. Rows processed: 10

Si le pipeline échoue, inspectez le fichier journal spécifié dans la sortie.

Vérifier les journaux pour les erreurs

Les journaux Hop se trouvent généralement dans <HOP_HOME>/logs. Utilisez grep pour trouver les erreurs :

grep -i "error" <HOP_HOME>/logs/hop.log | tail -20

Exemple de sortie :

2024-01-15 10:30:45 ERROR Database connection failed: jdbc:postgresql://new-db-host:5432/sales

Cela indique un problème de connectivité. Corrigez la chaîne de connexion ou l'accès réseau.

Valider les métadonnées du pipeline

Avant l'exécution, validez le XML du pipeline pour détecter les erreurs de syntaxe :

./hop-run.sh -j validate -p sales_etl -f <HOP_CONFIG_FOLDER>

Sortie attendue :

Pipeline validation successful.

Si ce n'est pas le cas, la sortie listera les erreurs spécifiques.

Surveiller Hop Server

Si vous utilisez Hop Server, surveillez sa santé et l'état d'exécution des pipelines :

curl -s http://<HOP_SERVER_HOST>:8080/hop/pipelines

Sortie attendue (JSON) :

[{"name":"sales_etl.main","status":"RUNNING","lastExecution":"2024-01-15T10:30:00Z"}]

Cela vous aide à confirmer que le pipeline s'exécute comme prévu.

Modes d'échec et récupération

Les échecs arrivent. Cette section décrit les modes d'échec courants et comment récupérer.

Erreur de configuration

Mode d'échec : Le pipeline échoue car une variable est indéfinie ou incorrecte.

Diagnostic : Vérifiez les journaux pour « Variable not found » ou similaire.

Exemple :

2024-01-15 11:00:00 ERROR Variable ${DB_HOST} not defined in environment prod

Récupération : Définissez la variable dans la configuration de l'environnement ou corrigez le paramètre du pipeline. Puis relancez.

Échec de connectivité

Mode d'échec : La connexion à la base de données échoue en raison du réseau ou des identifiants.

Diagnostic : Utilisez ping, telnet ou un client de base de données pour tester la connectivité. Dans Hop, le message d'erreur affichera l'URL de connexion.

Récupération : Corrigez l'accès réseau ou mettez à jour les identifiants via hop-conf.sh. Vérifiez avec ./hop-conf.sh -a show.

Erreur de logique du pipeline

Mode d'échec : Le pipeline s'exécute mais produit des résultats incorrects.

Diagnostic : Comparez les compteurs de sortie et les données d'échantillon avec ce qui est attendu. Utilisez la journalisation intégrée de Hop pour capturer les lignes intermédiaires.

Récupération : Corrigez la conception du pipeline, validez les modifications et redéployez. Revenez à une version précédente si nécessaire.

Procédures de retour en arrière

Ayez toujours un plan de retour en arrière. Pour les changements de pipeline, utilisez Git pour annuler :

git revert <commit-hash>

Pour la configuration, utilisez la commande pour définir la valeur précédente (comme indiqué précédemment).

Pour un retour en arrière complet de l'environnement, redéployez le dossier de configuration Hop précédent et redémarrez Hop Server.

Exemple de commande pour redémarrer Hop Server (si vous utilisez systemd) :

sudo systemctl restart hop-server

Vérifiez ensuite l'état :

sudo systemctl status hop-server

Sortie attendue :

● hop-server.service - Apache Hop Server
   Loaded: loaded (/etc/systemd/system/hop-server.service; enabled)
   Active: active (running) since Mon 2024-01-15 12:00:00 UTC; 5s ago

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle avant et après toute opération CI/CD. Remplissez les valeurs concrètes pour votre environnement.

Liste de contrôle avant changement

• [ ] Enregistrer la version actuelle d'Apache Hop : ./hop-conf.sh --version → sortie : Apache Hop 2.1.0
• [ ] Vérifier les variables d'environnement : echo $HOP_HOME → /opt/hop
• [ ] Lister les projets actuels : ./hop-run.sh -j list_projects -f <HOP_CONFIG_FOLDER> → sortie : sales_etl, marketing_etl
• [ ] Identifier le pipeline cible et ses dépendances : ./hop-run.sh -j list_dependencies -p sales_etl -f <HOP_CONFIG_FOLDER> → sortie : main.hpl depends on transform.hpl
• [ ] Sauvegarder la configuration actuelle : cp -r <HOP_CONFIG_FOLDER> <BACKUP_LOCATION>
• [ ] Définir le rayon d'impact : quels pipelines/processus sont affectés ?
• [ ] Préparer les commandes de retour en arrière (par ex., annuler le commit, restaurer la sauvegarde de configuration).

Exécution du changement

• [ ] Appliquer le changement de configuration ou déployer le nouveau pipeline.
• [ ] Exécuter la validation : ./hop-run.sh -j validate -p sales_etl -f <HOP_CONFIG_FOLDER> → attendu : Pipeline validation successful.
• [ ] Exécuter un test : ./hop-run.sh -j main -p sales_etl -f <HOP_CONFIG_FOLDER> -r "first=10" → attendu : Rows processed: 10
• [ ] Vérifier les journaux pour les erreurs : grep -i "error" <HOP_HOME>/logs/hop.log | tail -20 → attendu : aucune nouvelle erreur.

Vérification post-changement

• [ ] Confirmer la nouvelle valeur de configuration : ./hop-conf.sh -p sales_etl -g prod -c database_connection -a show → attendu : jdbc:postgresql://new-db-host:5432/sales
• [ ] Surveiller l'exécution du pipeline via Hop Server ou les journaux : curl -s http://<HOP_SERVER_HOST>:8080/hop/pipelines → attendu : statut RUNNING
• [ ] Comparer la sortie des données avec ce qui est attendu (par ex., nombre de lignes, valeurs d'échantillon).
• [ ] Mettre à jour la documentation et les enregistrements d'inventaire.

Exécution du retour en arrière (si nécessaire)

• [ ] Annuler le commit Git : git revert <commit-hash>
• [ ] Restaurer la configuration depuis la sauvegarde : cp -r <BACKUP_LOCATION>/* <HOP_CONFIG_FOLDER>/
• [ ] Redémarrer Hop Server : sudo systemctl restart hop-server
• [ ] Vérifier l'état du service : sudo systemctl status hop-server → attendu : active (running)
• [ ] Re-exécuter les vérifications pour confirmer le succès du retour en arrière.

Conclusion

L'automatisation CI/CD avec Apache Hop ne fonctionne que si chaque étape est versionnée, observable et réversible. Copier des commandes sans vérifier les prérequis et les sorties attendues conduit à des échecs. Utilisez les listes de contrôle et les exemples de cet article pour construire un pipeline de déploiement sûr pour vos flux de données.

Commencez par une vérification à faible risque : enregistrez l'état actuel, exécutez un contrôle documenté, comparez les résultats et examinez les dépendances. Ensuite, développez votre automatisation de manière incrémentale.

Un flux de travail technique fiable rend les échecs visibles, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision.