Nginx unit

[tobiasge]

Related Issue: -

New Behavior

• Use Nginx Unit to serve the application

Contrast to Current Behavior

• Gunicorn was used

Discussion: Benefits and Drawbacks

Removes Nginx container and with that the need to

• Collect static files at startup
• Shared volume for static files

In the current version Nginx Unit is build from sources, so the build will take a little bit longer

Changes to the Wiki

• "Deployment", "Getting Started" and "TLS" pages need an update.

Proposed Release Note Entry

• We are now using Nginx Unit to serve the application. This makes the additional Nginx container unnecessary.
• After upgrade the docker-compose.override.yml must be changed to forward traffic directly to the Netbox container
• The Netbox Python installation is now contained in a Python virtual environment located in /opt/netbox/venv

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.

[cimnine]

Some preliminary comments. As discussed in Slack, I'd like to evaluate making 'alpine' the base image and getting python and nginx-unit from there to avoid keeping nginx-unit manually up-to-date.

[cimnine]

I'm looking forward to when we have this change merged! Getting rid of the separate nginx container and the nginx-config volume hack would mean a lot.

But until then and additionally to the other comments we'll have to change the Github Action configuration as well. Here we could test with alpine:edge as an alternative build in there probably, but stick to a specific version of Alpine Linux, i.e. alpine:3.12 at the moment, for our regular builds.

As usual, feel free to disagree with any comment, but please state your reason for doing so :) Also feel free to ask for help with the build files.

[cimnine]

But until then and additionally to the other comments we'll have to change the Github Action configuration as well. Here we could test with alpine:edge as an alternative build in there probably, but stick to a specific version of Alpine Linux, i.e. alpine:3.12 at the moment, for our regular builds.

This comment was regarding the following code snippet: push.yml#L20-L23

[cimnine]

To be honest, I'm no particular fan of the change of the unitd configuration socket from unix-socket to tcp-socket. I believe it's easier to get wrong, e.g. security wise. It will also be harder to debug – for us in bug reports, but also for operation personnel –, because it'll never be clear in what configuration state a particular container is. I.e. was the configuration manipulated in the meantime?

Or in other words: I'm a fan of containers that are just configured at the start through files/secrets/environment variables, but are otherwise immutable. If the configuration changes, then restart/redeploy the container.

In your commit message (efaabf2) you've argued like this:

With this and the change made to unit in Alpine users can now load certificates into
the container an serve Netbox over an encrypted configuration.

I would still argue that this should be the job of a dedicated container, not the job of Netbox. (It's job is to serve the application.) E.g. in Kubernetes there are usually Ingress services taking care of this. Also, the big clouds have services like these. And usually they also take care of load balancing.

[tobiasge]

To be honest, I'm no particular fan of the change of the unitd configuration socket from unix-socket to tcp-socket. I believe it's easier to get wrong, e.g. security wise. It will also be harder to debug – for us in bug reports, but also for operation personnel –, because it'll never be clear in what configuration state a particular container is. I.e. was the configuration manipulated in the meantime?

Ok, I will revert this change.

[tobiasge]

The build is now based on alpine:3.13 so I think we could go forward with a release.

[cimnine]

We will need more text in the release notes:

• Introduction of Python Virtual Env
• Changes to the docker-compose.override.yml are required, because there is not nginx service anymore and the port mapping must be applied to the netbox service now.

We will also have to make quite some changes to the wiki to explain how the virtual env works (or at least that it's there) and how people can now build custom containers that include their plugins now.