Mise à niveau et migration NiFi avec exemples pratiques : guide d'implémentation

La mise à niveau d'Apache NiFi apporte des correctifs de sécurité, des améliorations de performance et de nouvelles fonctionnalités pour les pipelines de données. Les migrations couvrent également des scénarios tels que le passage de nœud unique à cluster, d'on-premise vers le cloud, ou des déploiements side-by-side. Ce guide montre comment planifier le travail, exécuter une mise à niveau ou une migration en toute sécurité, valider le comportement et effectuer un rollback propre si nécessaire. Vous verrez des tâches concrètes et de petits exemples qui s'appliquent à des systèmes réels fonctionnant souvent aux côtés de NiFi, comme Kafka, HDFS, Spark et Airflow.

Aperçu du flux de travail

Utilisez le flux de travail de bout en bout suivant en production.

1) Évaluer et inventorier

Enregistrez la version actuelle de NiFi, l'OS et la version de Java.
Listez les NARs personnalisés, processeurs, services de contrôle et tâches de rapport.
Capturez les connecteurs et points de terminaison externes : topics Kafka et groupes de consommateurs, chemins HDFS, endpoints HTTP, JDBC, S3.
Exportez ou versionnez vos flux dans NiFi Registry, ou sauvegardez flow.xml.gz si vous n'utilisez pas Registry.
Notez la clé des propriétés sensibles, les authorizers, utilisateurs et fournisseurs d'identité.

Astuce : conservez une matrice simple des processeurs et services de contrôle dont vous dépendez, afin de confirmer rapidement leur statut de validation dans la version cible.

2) Choisir une stratégie

Mise à niveau in-place (nœud unique) : chemin le plus simple ; prévoyez une indisponibilité pendant la fenêtre.
Mise à niveau rolling (cluster) : videz et mettez à niveau un nœud à la fois pour réduire l'impact.
Blue-green (side-by-side) : exécutez un nouveau NiFi à côté de l'ancien et basculez le trafic.

Choisissez selon votre tolérance à l'indisponibilité, la taille du cluster et la facilité de rediriger le trafic (groupes de consommateurs Kafka, ingress HTTP, planificateurs comme Airflow).

3) Préparer et sauvegarder

Gélé les modifications UI pendant la fenêtre.
Sauvegardez la configuration et les données NiFi avant toute mise à niveau.

Exemple de sauvegarde (ajustez les chemins selon votre installation) :

 export NIFI_HOME=/opt/nifi-current
 export BK=/backup/nifi-$(date +%Y%m%d-%H%M%S)
 mkdir -p "$BK"

 # Arrêter NiFi
 sudo systemctl stop nifi 2>/dev/null || "$NIFI_HOME\)/bin/nifi.sh stop

 # Sauvegarder les répertoires clés
 sudo tar -C "$NIFI_HOME" -czf "$BK\)/nifi-home.tgz \
   conf flowfile_repository content_repository provenance_repository state logs

 # Optionnel : copier hors site
 # scp "$BK\)/nifi-home.tgz user@backuphost:/backups/

Capturez également nifi.properties séparément pour pouvoir comparer les paramètres comme les emplacements des repositories, les ports du cluster et les répertoires d'état.

4) Exécuter la mise à niveau

In-place nœud unique

Installez le nouveau NiFi dans un chemin versionné, ex. /opt/nifi-2.2.0.
Comparez et fusionnez les fichiers de conf : nifi.properties, authorizers.xml, login-identity-providers.xml, bootstrap.conf.
Reconstruisez ou validez les NARs personnalisés pour la nouvelle API si nécessaire.
Pointez un symlink /opt/nifi-current vers la nouvelle installation.
Démarrez et surveillez les logs pour les problèmes de validation et de services de contrôle.

Rolling cluster

Pour un nœud à la fois :

Vidangez ou offload le nœud pour qu'il cesse d'accepter du nouveau travail et que ses files locales se vident.
Déconnectez le nœud du cluster.
Arrêtez le service sur ce nœud ; mettez à niveau les binaires et la conf comme ci-dessus.
Démarrez, rejoignez le cluster et vérifiez la santé et l'équilibrage de charge.
Répétez pour le nœud suivant.

Blue-green side-by-side

Déployez un nouveau NiFi avec la version cible.
Enregistrez-le sur le même NiFi Registry (ou importez les flux) et paramétrez les endpoints.
Désactivez initialement les sources et sinks externes ; testez avec des données synthétiques.
Une fois validé, basculez le trafic :

Kafka : changez les groupes de consommateurs ou réassignez les partitions.
HTTP : mettez à jour la DNS ou la cible du load balancer.
HDFS : redirigez les writers vers le nouveau flux.

5) Valider le comportement

Activez les composants progressivement. Privilégiez les sources en lecture seule et les processeurs qui ne mutent pas d'état externe tant que vous n'avez pas confirmé la correction.
Utilisez un petit jeu de données connu pour vérifier la correction et l'idempotence.
Vérifiez le statut de validation des services de contrôle dans l'UI et les logs.
Surveillez la contre-pression et la croissance des files dans les groupes de processus clés.
Confirmez les métriques : débit, compteurs d'erreurs et latence. Inspectez la provenance pour garantir la présence des chaînes d'événements attendues.

Liste de contrôle de validation :

Aucun composant n'affiche l'état Invalid.
Les NARs personnalisés se chargent sans conflits de classpath.
Les systèmes externes comme Kafka et HDFS acceptent les connexions avec l'authentification attendue.
Les schémas de sortie et noms de fichiers respectent le contrat.

6) Mettre en production et surveiller

Retirez les limitations et seuils de contre-pression temporaires.
Réactivez les tâches de rapport et alertes.
Surveillez pendant au moins un cycle métier complet ou une fenêtre SLA.

7) Plan de rollback

In-place : arrêtez le nouveau NiFi, restaurez l'installation et la configuration précédentes depuis les sauvegardes, et redémarrez l'ancienne version.
Rolling : si un nœud montre des régressions, revenez en arrière sur ce nœud avant de passer aux autres.
Blue-green : rebasculez le trafic vers l'ancien environnement ; maintenez le nouveau désactivé jusqu'à correction.

Signaux de préparation au rollback :

Vous avez vérifié les sauvegardes et pouvez restaurer conf et repositories.
Les anciens binaires restent disponibles, et la clé des propriétés sensibles n'a pas changé de manière inattendue.
Les endpoints externes supportent un rebasculement rapide (TTL DNS, plan de réassignation des groupes de consommateurs).

Plan pilote local

Commencez par un petit pilote mesurable que vous pouvez exécuter localement. Restez ciblé, facile à inspecter, et lié à des critères de succès clairs.

Objectif du pilote

Vérifier que la version cible de NiFi exécute vos processeurs et services de contrôle clés, et qu'un flux représentatif se comporte comme attendu.

Flux de test (exemple)

Source : ConsumeKafka (topic de test) ou GenerateFlowFile pour test purement local.
Transformation : UpdateAttribute et JoltTransformJSON.
Sink : PutFile vers un répertoire temporaire.

Étapes

Installez le NiFi cible localement.
Importez ou recréez le petit flux. Si vous utilisez NiFi Registry, tirez la version du flux dans un bucket local.
Paramétrez les endpoints (kafka.bootstrap.servers, output.dir) pour pouvoir basculer entre valeurs locales et production.
Définissez les critères de succès :

Tous les composants valident sans erreur.
1 000 messages de test traités sous le temps convenu.
Schéma de sortie et noms de fichiers conformes aux attentes.
Aucune erreur dans les logs ; la provenance montre le chemin attendu.

Exécutez le pilote et consignez les résultats. S'il passe, promouvez la même version de flux vers un environnement de dev partagé et répétez avec de vrais connecteurs (Kafka, HDFS) sous charge throttlée.

Pourquoi ça fonctionne

Une portée étroite et des résultats mesurables maintiennent le risque bas et le retour rapide.

Conclusion

Une mise à niveau ou migration NiFi structurée repose sur des étapes claires : évaluer, choisir une stratégie, préparer avec des sauvegardes solides, exécuter par méthodes in-place, rolling ou blue-green, valider avec de petits jeux de données, et garder un chemin de rollback prêt. Commencez par un pilote local qui prouve la compatibilité et la performance sur une tranche de votre flux. De là, avancez vers dev, staging et production avec les mêmes artefacts versionnés et paramètres. Cette approche réduit les surprises, maintient l'indisponibilité faible et aide à intégrer des systèmes comme Kafka, HDFS, Spark et Airflow sans casser les contrats.

Prochaines vérifications

Inventaire complet et sauvegardes vérifiées.
NARs personnalisés construits et validés contre la version cible.
Contextes de paramètres définis pour tous les endpoints externes.
Étapes de rollback répétées et documentées.
Monitoring et alerting prêts pour l'observation post-bascule.