Support NetBox plugins

[manusys64]

I would like to know if is possible to add custom plugins through helm chart? I saw that in default values there are 2 variables related to plugins:

plugins: []
pluginsConfig: {}

I have tried to add a plugin within plugin list variable like so:

plugins: 
- netbox_dns

but helm chart fail to deploy due to this error (which is legit)

django.core.exceptions.ImproperlyConfigured: Unable to import plugin netbox_dns: Module not found. Check that the plugin module has been installed within the correct Python environment.
[ Use DB_WAIT_DEBUG=1 in netbox.env to print full traceback for errors here ]
⏳ Waiting on DB... (0s / 30s)
django.core.exceptions.ImproperlyConfigured: Unable to import plugin netbox_dns: Module not found. Check that the plugin module has been installed within the correct Python environment.

So how we can install new plugins to NetBox deployed via helm chart?

Thank you and best regards!

[JevgenijsKonevs]

@manusys64 One way how you can install the plugins is to create custom Netbox Docker image.

Example of Dockerfile config :

FROM netboxcommunity/netbox:v3.5.1

RUN . /opt/netbox/venv/bin/activate && \
    pip install netbox-plugin-dns 

Add reference to the custom Dockerfile in Helm chart :

image:
  repository: YOUR_REPOSITORY
  tag: "IMAGE_TAG"
plugins:
  - netbox_dns

[viperbmw]

I have tried to use this Dockerfile to build a custom image.

FROM netboxcommunity/netbox:latest
RUN echo "netbox-secrets" >> requirements.txt && \
    echo "netbox-secrets" >> local_requirements.txt \
    echo "netbox-topology-views" >> requirements.txt && \
    echo "netbox-topology-views" >> local_requirements.txt \
    echo "netbox-bgp" >> requirements.txt && \
    echo "netbox-bgp" >> local_requirements.txt
RUN . /opt/netbox/venv/bin/activate && pip install netbox-secrets netbox-topology-views netbox-bgp
RUN mkdir -p /opt/netbox/netbox/static/netbox_topology_views/img
SHELL ["/bin/bash", "-c"]
RUN echo $'\n\
PLUGINS = ["netbox_secrets", "netbox_bgp","netbox_topology_views"]\n\
PLUGINS_CONFIG = {\n\
    \'netbox_topology_views\': {\n\
        \'static_image_directory\': \'netbox_topology_views/img\',\n\
        \'allow_coordinates_saving\': True,\n\
        \'always_save_coordinates\': True\n\
    }\n\
}' >> /opt/netbox/netbox/netbox/configuration.py
RUN SECRET_KEY="dummydummydummydummydummydummydummydummydummydummy" /opt/netbox/venv/bin/python /opt/netbox/netbox/manage.py collectstatic --no-input

When I try to use the custom image in the Helm Chart I get

/opt/netbox/docker-entrypoint.sh: line 20: ./manage.py: No such file or directory
[ Use DB_WAIT_DEBUG=1 in netbox.env to print full traceback for errors here ]
⏳ Waiting on DB... (18s / 30s)

What am I doing wrong?

When using the image in docker compose it works.........

[LeoColomb]

After an extensive study, I'm going to close this feature request. Adding plugin installation at runtime is against the container (and Kubernetes) principle. This is very well explained by @cimnine in https://github.com/netbox-community/netbox-docker/pull/1071:

This change would – in my opinion – go against a basic principle of containers: That containers (and everything that defines them) are fully defined during build-time (or at least after the build) and that everything required by the container is packaged together. In other words, a container should provide everything that is required to run that container, besides truly external dependencies like databases or configuration.

This applies even more in a Kubernetes context. In a same deployment, a new pod is expected to be as equal as possible as another one. Adding an installation step breaks that rule, adds surface for errors and breakage. While adding the installation step as an init container is possible, it requires storing the Python virtual environment in a volume, which is more tricky than just a pip install and would makes upgrade much more challenging.

The recommended way to process is the one documented on NetBox container image wiki (and written above by @JevgenijsKonevs). That way also ensures the Python compatibility between plugins and NetBox itself is mostly checked outside the Kubernetes deployment.

---

With the use of Helm chart, the custom image build and use can be simplified to the following steps.

1. Build your own image with the plugins (and their requirements) bundled on top of NetBox image. The following is a Dockerfile example:

   FROM netboxcommunity/netbox:latest
   RUN /opt/netbox/venv/bin/pip install --no-warn-script-location \
       plugin_1 \
       plugin_2
   

2. Use the chart values to load the configuration. For example:

   plugins:
     - plugin-1
     - plugin-2
   pluginsConfig:
     plugin-2:
       custom: true
   

[gclawes]

A counterexample is the Grafana helm chart, which has a facility to download grafana plugins dashboards at deploy time from the grafana plugin/dashboard registries using an initContainer:

https://github.com/grafana/helm-charts/blob/6eecb003569dc41a494d21893b8ecb3e8a9741a0/charts/grafana/templates/_config.tpl#L85-L110

https://github.com/grafana/helm-charts/blob/6eecb003569dc41a494d21893b8ecb3e8a9741a0/charts/grafana/templates/_pod.tpl#L60-L106

This works very well. The plugins/dashboards are downloaded to an emptyDir volume, so the base filesystem of the containers is not strictly "modified".

Air-gapped installs (where the internet cannot be reached) are handled by the ability to pass in a download URL directly instead of the registry IDs:

grafana:
  dashboards:
    default:
      raarrr:
        gnetId: 12896
        datasource: Prometheus
      exportarr:
        url: https://raw.githubusercontent.com/onedr0p/exportarr/master/examples/grafana/dashboard2.json