Support for environment variables

[tyler-8]

Is there any interest from other users in switching to an environment variable setup (sometimes paired with the '12 factor app' concept) for configuration settings, rather than having the playbook put all the variables directly in Python code?

Ultimately I don't think there'd be much change in the current usage of the playbook, but instead of putting all the config data in a configuration.py template, the configuration.py would simply be looking up environment variables. The playbook would also (by default) create a .env file containing the config values. The wsgi.py and manage.py files may need some minor changes (which is why those tasks need to be included during this role's tasks) and those files almost never change in NetBox itself so there's very low chance we'd conflict with anything there. It might be possible to just change the configuration.py alone and not touch the other two files, but I'd have to test with that setup.

I've been tinkering with this concept locally, and currently use it in other Django apps and it's quite nice and allows for a little more flexibility in deployments, as well as allows for securing the deployment a little more.

This tutorial on DigitalOcean has a good overview of the concept.

[Edit] We may be able to avoid python-dotenv altogether if we use a shell-script that loads the .env and runs the uwsgi and manage.py commands.

[madeinoz67]

I'm familiar with 12 factor apps and agree that apps should allow for ENV, however in cases like this My thoughts with this are that configurations should be kept in the playbook variables and therefore in source control as it allows for proper config management tracking / auditing.

[tyler-8]

@madeinoz67 - what I'm proposing doesn't change that.

The playbook would be creating the appropriate environment variables for you - it's just that now, rather than the raw values being deployed inside a .py file, they're contained within a read-only .env file, and the .py just references the environment variables.

From a playbook-user perspective, the change should be mostly transparent,

[lae]

I've used dotenv for a Django app at my old job before, and can agree it's nice to have that separation for multiple environments.

However I'm not too familiar with how you'd manage e.g. lists with environment variables. If you're going to have to split out lists in the netbox_config variable into separate strings it just seems like it'd increase the codebase for not much benefit. Or would it be possible to keep the configuration.py template mostly as-is (bar changing values) or even simplify it?

I'm also thinking that this is something that should be implemented upstream rather than in this role (and modifying files in the NetBox source is just gonna be a pain when dealing with deployments from git branches), but it does seem the proposal for it was rejected: https://github.com/netbox-community/netbox/issues/4344