Ability to include additional libraries in the Nifi containers

[banzo]

Database processors need database drivers libraries in the Nifi containers.

The current hack is:

wget https://jdbc.postgresql.org/download/postgresql-42.2.6.jar
kubectl cp ./postgresql-42.2.6.jar fadi/fadi-nifi-0:/opt/nifi/postgresql-42.2.6.jar
rm postgresql-42.2.6.jar

It would be nice to be able to specify a list of libraries that would be downloaded and put in nifi_home/lib as an additional option.

[alexnuttinck]

Sure, it would be nice.

Another solution is to create and publish a new Docker image from apache/nifi with these librairies. Than, you can use this image in the Helm Chart. Adding preloaded workflow would be nice too!

I will look how it can be achieved with helm.

[alexnuttinck]

I propose to use a postStart as explained here: https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/

We will have something like:

lifecycle:
  postStart:
    exec:
      command: ["/bin/sh", "-c", "your command to add the lib to the container"]

If you have a better idea, don't hesitate.

[LeeByungwoo]

I'm having the same issue

https://github.com/compose-ex/nifi-compose-bundle <- this library

How do I solve this which should not be the above method?

[alexnuttinck]

The feature is present in Chart v0.1.6 now.

@LeeByungwoo I think you should publish your artefact, then you can make a wget in the folder you want. See the postStart from values.yaml for an example.

I close this issue, but don't hesitate to open a new one.

[terence-bigtt]

How about a file deposit like container a volume shared with the nifi pod? For adding jdbc like libs this is the recommanded way, namely to put the jar somewhere accessible and to point the nifi component to the lib. Le mar. 27 août 2019 à 10:15, Alexandre Nuttinck <notifications@github.com> a écrit :

…

I propose to use a postStart as explained here: https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/ We will have something like: lifecycle: postStart: exec: command: ["/bin/sh", "-c", "your command to add the lib to the container"] If you have a better idea, don't hesitate. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5?email_source=notifications&email_token=ADTFILP7IVFJVKU7SNH6ASLQGTPALA5CNFSM4IJTTLNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5G45JY#issuecomment-525192871>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADTFILMQJQM7RLHNPSVUMWLQGTPALANCNFSM4IJTTLNA> .

[alexnuttinck]

@terence-bigtt yes, we could have an extra volumeMount to give the possibility to create other volume mounts , something like this:

          volumeMounts:
          {{- range .Values.extraVolumeMounts }}
            - name: {{ .name }}
              mountPath: {{ .mountPath }}
              subPath: {{ .subPath | default "" }}
          {{- end }}

      volumes:
      {{- range .Values.extraVolumeMounts }}
        - name: {{ .name }}
          persistentVolumeClaim:
            claimName: {{ .existingClaim }}
      {{- end }}

for the values.yaml

# Defines additional volume mounts.
extraVolumeMounts: []
  # - name: extra-volume
  #   mountPath: /mnt/volume
  #   existingClaim: volume-claim