NiFi 2.x 배포본의 lib 에는 1.x 에 있던 NAR 가운데 일부가 들어 있지 않다. Hadoop · HDFS · Hive 계열이 대표적이다. 릴리스에 따라 어떤 버전에는 들어 있고 다음 버전에는 빠지는 경우도 있어, 올리고 나서야 프로세서 목록에 없다는 것을 알게 된다.
1.x 용 NAR 을 그대로 복사하는 것은 방법이 아니다. 2.x 는 확장 API 가 바뀌어 1.x NAR 을 적재하지 못한다. 필요한 것은 같은 2.x 계열로 빌드된 NAR 이다.
빌드는 마지막 수단이다. Maven Central 에 해당 버전의 NAR 이 올라와 있으면 그대로 받는다.
https://repo1.maven.org/maven2/org/apache/nifi/<ARTIFACT>/<VERSION>/<ARTIFACT>-<VERSION>.nar
curl -fsI https://repo1.maven.org/maven2/org/apache/nifi/nifi-hadoop-nar/2.5.0/nifi-hadoop-nar-2.5.0.nar
404 가 나면 그 버전에는 없는 것이다. 디렉터리를 열어 실제로 어떤 버전이 있는지 본다 — 인접 버전에는 있는 경우가 있다.
curl -s https://repo1.maven.org/maven2/org/apache/nifi/nifi-hadoop-nar/ | grep -o 'href="[0-9][^"]*"'
NAR 이 없고 jar 만 있는 경우도 있다. NiFi 가 적재하는 것은 NAR 이므로 jar 로는 대체되지 않는다.
배포본에 들어 있던 NAR 이면 그 버전의 태그로 빌드하는 것이 가장 확실하다.
git clone https://github.com/apache/nifi.git
cd nifi
git checkout rel/nifi-2.5.0
JDK 는 대상 NiFi 가 요구하는 버전에 맞춘다. NiFi 2.x 는 Java 21 을 요구한다. Maven 은 배포판 패키지 대신 공식 배포본을 쓰는 편이 낫다 — 저장소의 오래된 Maven 은 최신 플러그인을 해석하지 못해 다음과 같이 멈춘다.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-clean-plugin:3.5.0:clean
... The plugin requires Maven version 3.6.3
cd /opt
curl -fLO https://archive.apache.org/dist/maven/maven-3/3.9.9/binaries/apache-maven-3.9.9-bin.tar.gz
tar xzf apache-maven-3.9.9-bin.tar.gz
ln -s /opt/apache-maven-3.9.9 /opt/maven
export PATH=/opt/maven/bin:$PATH
mvn -v
wget 으로 받은 뒤 No such file or directory 가 나면 받기 자체가 실패한 것이다. 프록시 환경에서 HTML 오류 페이지가 저장되는 일이 흔하므로, ls -l 로 파일 크기를 먼저 확인한다.
디렉터리 구조가 릴리스 사이에 바뀌었다. 문서에 적힌 경로를 그대로 믿지 말고 찾는다.
| 계열 | 번들 경로 |
|---|---|
| 1.x · 초기 2.x | nifi-nar-bundles/ |
| 이후 2.x | nifi-extension-bundles/ |
find . -type d -name '*hdfs*'
find . -name pom.xml | grep -i hadoop
전체를 한 번 빌드해 로컬 저장소에 부모 POM 과 형제 모듈을 올려 둔 뒤, 필요한 모듈만 다시 만드는 순서가 안정적이다. 모듈 디렉터리에서 바로 mvn package 를 돌리면 의존 모듈을 찾지 못해 실패한다.
mvn clean install -DskipTests -T 1C
전체 빌드는 길다. 한 모듈만 필요하면 루트에서 그 모듈과 의존 모듈만 지정한다.
mvn clean install -DskipTests -pl nifi-extension-bundles/nifi-hadoop-bundle/nifi-hdfs-processors-nar -am
결과물은 모듈의 target 아래에 있다.
find . -name '*-nar-*.nar' -newermt '-1 hour'
NAR 은 배포본의 확장 디렉터리에 넣는다. 배포본에 따라 lib 또는 extensions 다. 이미 들어 있는 NAR 들이 어디에 있는지 보고 같은 자리에 둔다.
cp target/nifi-hdfs-processors-nar-2.5.0.nar /opt/nifi/extensions/
/opt/nifi/bin/nifi.sh restart
버전이 섞이지 않도록 한다. 같은 아티팩트의 다른 버전 NAR 이 둘 다 있으면 적재 충돌이 난다. 컨테이너 이미지로 운영한다면 이미지 빌드 단계에서 NAR 을 넣어 재현 가능하게 만든다.
적재 여부는 로그와 UI 양쪽으로 확인한다.
grep -i 'nar' /opt/nifi/logs/nifi-app.log | tail -30
UI 의 프로세서 추가 창에서 PutHDFS · FetchHDFS · ListHDFS 가 보이면 끝이다. 보이지 않으면 로그에서 해당 NAR 의 적재 실패 메시지를 찾는다. API 버전이 맞지 않으면 그 자리에 이유가 찍힌다.
1.x 에서 쓰던 템플릿(XML)은 2.x 에서 가져올 수 없다. 프로세서만 되살린다고 플로우가 옮겨지지는 않으므로, 플로우 이관은 별도로 다뤄야 한다.
Hadoop 계열 NAR 은 클러스터의 Hadoop 배포판과 라이브러리 버전이 어긋나면 적재는 되고 실행에서 실패한다. 벤더 배포판을 쓴다면 벤더가 제공하는 NiFi(CFM 등)를 쓰는 편이 안전하다.