Simplify plugin installation

[tobiasge]

Related Issue: -

New Behavior

Netbox plugins can now be mounted into the container and will be loaded automatically from the mounted path. A configuration file to enabled the plugin in has to be mounted additionally.

To install a plugin from outside the container you need to use the same Python version as is used in the container. At the moment that is Python 3.11. Assuming you are in the netbox-docker directory and using the default configuration, just run this command, to install the netbox-initializers plugin:

pip install --target=plugins netbox-initializers

This installation method will only work for plugins that don't need to collectstatic.

Contrast to Current Behavior

A new image has to be build, to install a plugin

Discussion: Benefits and Drawbacks

• See above

Changes to the Wiki

• Update plugins Wiki page

Proposed Release Note Entry

• Install plugins via mounted path

Double Check

• I have read the comments and followed the PR template.
• I have explained my PR according to the information in the comments.
• My PR targets the develop branch.

[jose-pr]

Waiting for this feature, any news?

[tobiasge]

I don't think I will go forward with this change because of the limitation that it won't work with collectstatic.
About 30% of Plugins need to run collectstatic after installation.

[jose-pr]

You can still mount static to keep it persistent and collectstatic only when needed.

[cimnine]

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.

I argue strongly against adopting this change and this way of simplifying plugin support also from a maintainer perspective: I fear that this creates impossible-to-debug problems that will get reported back to us.

However, if someone has to add a plugin by extending our container using a Dockerfile, it's a much cleaner boundary for error diagnostics. And it's much simpler for us to help in such cases.

From an operations' perspective, it's IMO also more desirable to know which plugins (and which exact files) are bundled with a certain NetBox instance, rather than mounting such files into the container during runtime. (Which – to me – cries to become a problem when updating to a new version of NetBox / NetBox Docker. Also, it's harder to roll back an update to a plugin that way.)

An idea to simplify plugin support could be to create (and maintain) a GitHub Template Repository and link to it from the Wiki or Readme. That repository could already provide a sample Dockerfile, along some GitHub Actions to automatically build the container and publish it to the GitHub Container Registry. That repo could even contain a respective Renovate config, so that Renovate creates PRs for updates of the plugin(s) and of the NetBox Docker image, thereby automating and reducing maintenance overhead.