Upgrade et migration NiFi : guide pratique avec exemples

Intro

Cette version française explique NiFi upgrade and migration with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Mettre à niveau Apache NiFi apporte des correctifs de sécurité, des gains de performance et de nouvelles fonctionnalités pour vos data pipelines. Les migrations couvrent aussi les passages d'un nœud unique à un cluster, d'un environnement on‑prem vers le cloud, ou des déploiements côte à côte. Ce guide montre comment planifier le travail, exécuter un NiFi upgrade ou une NiFi migration en toute sécurité, valider le comportement (NiFi validation) et effectuer un NiFi rollback propre si nécessaire. Vous verrez des tâches concrètes, des checklists et de petits exemples qui reflètent des systèmes voisins de NiFi comme Kafka, HDFS, Apache Spark et Apache Airflow.

Vue d'ensemble du workflow

Utilisez le workflow de bout en bout suivant en production.

1) Évaluer et inventorier

Relever la version actuelle de NiFi, l'OS et la version de Java.
Lister les NARs personnalisés, processeurs, services contrôleurs et tâches de reporting.
Recenser les connecteurs et endpoints externes : topics et consumer groups Kafka, chemins HDFS, endpoints HTTP, JDBC, S3, etc.
Exporter ou versionner vos flows dans NiFi Registry, ou sauvegarder flow.xml.gz si vous n'utilisez pas le Registry.
Noter la sensitive properties key, les authorizers, les utilisateurs et les identity providers.

Astuce : tenez un tableau simple des processeurs et services contrôleurs utilisés, pour confirmer rapidement leur statut de validation dans la version cible.

2) Choisir une stratégie

Upgrade sur place (nœud unique) : le plus simple ; prévoir une indisponibilité durant la fenêtre.
Rolling upgrade (cluster) : drainer et mettre à niveau un nœud à la fois pour réduire l'impact.
Blue‑green (côte à côte) : faire tourner un nouveau NiFi à côté de l'ancien puis basculer le trafic.

Choisissez selon votre tolérance à l'indisponibilité, la taille du cluster et la facilité de rediriger le trafic (consumer groups Kafka, entrée HTTP, ordonnanceurs comme Airflow).

3) Préparer et sauvegarder

Geler les changements via l'UI pendant la fenêtre.
Sauvegarder la configuration et les données NiFi avant tout upgrade.

Exemple de sauvegarde (adaptez les chemins à 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

# Optionnellement, copier hors hôte
# scp "$BK"/nifi-home.tgz user@backuphost:/backups/

Conservez aussi nifi.properties séparément afin de comparer les paramètres tels que l'emplacement des repositories, les ports de cluster et les répertoires d'état.

4) Exécuter l'upgrade

Sur place, nœud unique

Installer le nouveau NiFi dans un chemin versionné, par exemple /opt/nifi-NEW.
Comparer et fusionner les fichiers de conf : nifi.properties, authorizers.xml, login-identity-providers.xml, bootstrap.conf.
Recompiler ou valider les NARs personnalisés vis‑à‑vis de la nouvelle API si nécessaire.
Pointer un lien symbolique /opt/nifi-current vers la nouvelle installation.
Démarrer et surveiller les logs pour détecter les problèmes de validation et de services contrôleurs.

Rolling upgrade en cluster

Pour un nœud à la fois : drainer ou offloader le nœud pour qu'il cesse de prendre du travail et vide ses files locales.
Déconnecter le nœud du cluster.
Arrêter le service sur ce nœud ; mettre à niveau binaires et conf comme ci‑dessus.
Démarrer, rejoindre à nouveau le cluster, et vérifier la santé du cluster ainsi que la répartition de charge.
Répéter pour le nœud suivant.

Blue‑green côte à côte

Monter un nouveau NiFi à la version cible.
L'enregistrer sur le même NiFi Registry (ou importer les flows) et paramétrer les endpoints.
Désactiver au début les sources et sinks externes ; tester avec des entrées synthétiques.
Une fois validé, basculer le trafic :

Kafka : changer de consumer groups ou réassigner les partitions.
HTTP : mettre à jour la cible DNS ou du load balancer.
HDFS : faire pointer les writers vers le nouveau flow.

5) Valider le comportement

Activer les composants progressivement. Privilégier les sources en lecture seule et les processeurs qui ne modifient pas l'état externe jusqu'à confirmation.
Utiliser un petit jeu de données connu pour vérifier la justesse et l'idempotence.
Contrôler dans l'UI et les logs le statut de validation des services contrôleurs.
Surveiller la backpressure et la croissance des files dans les groupes de processus clés.
Confirmer les métriques : débit, erreurs et latence. Inspecter la provenance pour vérifier les chaînes d'événements attendues.

Checklist de validation :

Aucun composant n'est en état Invalid.
Les NARs personnalisés se chargent sans conflits de classpath.
Les systèmes externes (Kafka, HDFS, etc.) acceptent les connexions avec l'auth attendue.
Les schémas de sortie et les noms de fichiers respectent le contrat.

6) Mise en production et monitoring

Retirer les throttles et limites de backpressure temporaires.
Réactiver les tâches de reporting et les alertes.
Surveiller au moins un cycle métier complet ou la fenêtre SLA.

7) Plan de rollback

Sur place : arrêter le nouveau NiFi, restaurer l'ancienne installation et les sauvegardes de configuration, puis redémarrer l'ancienne version.
Rolling : si un nœud présente des régressions, revenir en arrière sur ce nœud avant de poursuivre.
Blue‑green : rebasculez le trafic vers l'ancien environnement ; gardez 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 sensitive properties key n'a pas changé de façon inattendue.
Les endpoints externes permettent une bascule rapide (TTL DNS, plan de réassignation des consumer groups).

Plan pilote local

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

Objectif du pilote

Vérifier qu'une version cible de NiFi exécute vos processeurs et services contrôleurs clés, et qu'un flow représentatif se comporte comme prévu.

Flow de test (exemple)

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

Étapes

Installer la version cible de NiFi en local.
Importer ou recréer le petit flow. Si vous utilisez NiFi Registry, récupérer la version du flow dans un bucket local.
Paramétrer les endpoints (kafka.bootstrap.servers, output.dir) pour basculer entre valeurs locales et de production.
Définir les critères de succès :

Tous les composants se valident sans erreurs.
1 000 messages test sont traités sous un temps convenu.
Le schéma de sortie et les noms de fichiers correspondent aux attentes.
Pas d'erreurs dans les logs ; la provenance montre le chemin attendu.

Exécuter le pilote et consigner les résultats. S'il réussit, promouvoir la même version de flow vers un environnement de dev partagé et répéter avec des connecteurs réels (Kafka, HDFS) sous charge limitée.

Pourquoi cela fonctionne

Un périmètre restreint et des résultats mesurables limitent le risque et accélèrent le feedback.

Conclusion

Un NiFi version upgrade ou une migration structurée se résume à des étapes claires : évaluer, choisir une stratégie, préparer avec des sauvegardes solides, exécuter via une approche sur place, rolling ou blue‑green, valider avec de petits jeux de données et garder une voie de rollback prête. Commencez par un pilote local qui prouve la compatibilité et la performance sur un échantillon de votre flow. Ensuite, progressez vers dev, staging et production avec les mêmes artefacts versionnés et paramètres. Cette démarche réduit les surprises, minimise l'indisponibilité et facilite l'intégration avec Kafka, HDFS, Apache Spark et Apache Airflow sans rompre les contrats.

Prochaines vérifications

L'inventaire est complet et les sauvegardes sont vérifiées.
Les NARs personnalisés sont construits et validés contre la version cible.
Les contexts de paramètres sont définis pour tous les endpoints externes.
Les étapes de rollback sont répétées et documentées.
Le monitoring et les alertes sont prêts pour l'observation post‑bascule.