add hooks for running pre- and post-init scripts

[RangerRick]

New Behavior

Look for *.sh scripts in /opt/init/pre/ and /opt/init/post/. If they exist, run them (under bash -e) in sort-order, at the beginning (before initializing venv) and end of the entrypoint, respectively.

Contrast to Current Behavior

The current way to perform customizations at init is to either replace the entrypoint script in CMD, or to change it to call another script, both of which are a bit heavy-handed and rely too much on understanding the internals of the docker image.

Discussion: Benefits and Drawbacks

Benefits:

• easier to perform custom actions during startup of the docker container

Drawbacks:

• more potential for failures during startup (but hopefully the logging is enough to debug issues if they arise)

Changes to the Wiki

It would be useful to expand the entry on extending the build to note the new hooks for adding scripts (including examples for mounting volumes manually, plus the init-files volume in the docker-compose.yaml).

Proposed Release Note Entry

Provide hooks before startup of Netbox to perform additional initialization steps.

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.

[tobiasge]

I'm not sure if we wan't this added to the default image, because we will get more issues from people that broke their container with scripts. We had something similar with Python scripts that could be included, that had the same effect.

What are the use cases here?

@cimnine What do you think?

How is the volume supposed to be used? The configuration as it is now would create a volume in /var/lib/docker/volumes/ (where most users don't have wirte access). So they wouldn't be able to add scripts anyhow.
To make it easier to use we would need to mount a directory like it is done with the configuration or we could only extend the documentation on how to copy scripts into the image on build.

[cimnine]

What are the use cases here?

That's the question I have as well. As it is, I'm against proceeding with this suggested change. A user would still have to mount those pre- and post-scripts, or extend the image. If users can't use the container as-is anyway, then they can also just mount their own entrypoint script and gain full control over everything, and just invoke the original entrypoint script whenever the time has come to do so.

Also, I believe it would get complicated, since the worker and houskeeping instances are based on the same image. So there would have to be a way to distinguish which instance is starting in the pre- and post-scripts. And that's where I fear that things become fragile.

I suggest that such a scenario – with pre- and post-scripts – should simply be described in the wiki. That should be enough guidance for people who are not that familiar with Linux scripts and the Entrypoint mechanics.