cetic / helm-nifi

Helm Chart for Apache Nifi
Apache License 2.0
215 stars 225 forks source link

Ability to include additional libraries in the Nifi containers #5

Closed banzo closed 5 years ago

banzo commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/cetic/helm-nifi/issues/5?email_source=notifications&email_token=ADTFILP7IVFJVKU7SNH6ASLQGTPALA5CNFSM4IJTTLNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5G45JY#issuecomment-525192871, or mute the thread https://github.com/notifications/unsubscribe-auth/ADTFILMQJQM7RLHNPSVUMWLQGTPALANCNFSM4IJTTLNA .

alexnuttinck commented 5 years ago

@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