The best practices described in Two scoops of django and 12 factor app <https://12factor.net/> are good ones.
On Mon, Apr 1, 2019 at 7:32 PM A Stanley <[email protected]> wrote: > Thanks that clears it up for me. Agreed, the system that launches the > stack should provide all of the production settings which shouldn't be > stored in git or docker images. > > I am familiar with --buld-args, I use them sometimes to save the date/time > the container was built inside the image. The commit hash is good info. I > may have to borrow that from you :) > > I'm still new to Django so I've just been following the guidance from "Two > Scoops of Django" and django-cookiecutter. It's worked well for my use > cases but I need to get more familiar with all of the parts of Openwisp to > be able to say if it does or does not fit. > > On Mon, Apr 1, 2019 at 6:42 PM Federico Capoano < > [email protected]> wrote: > >> On Mon, Apr 1, 2019 at 5:21 PM A Stanley <[email protected]> wrote: >> >>> Federico, just to make sure I understand, how do you envision an end >>> user setting things like Django's 'SECRET_KEY' and 'ALLOWED_HOSTS'? I >>> guess I'm confused by; >>> >>> The only env vars that make sense and I can think of now are env vars >>>> which contain the commit hash of the openwisp modules used. >>>> >>> >> We should surely use env vars for SECRET_KEY and ALLOWED_HOSTS, but we >> should not set these with --build-args during image build time, the env >> vars will be set by the system which brings up the container, right? >> >> Do you know what --build-args does? >> I used it recently to have the commit hash of a repo embedded in the >> image, so it could be used easily in sentry <https://sentry.io> and from >> the sentry error detail you would see which version of the app is affected >> by a bug. >> In our case is a bit more complicated because we have more modules but we >> may figure out a way to have that as well. >> >> Also, for configuration files, should there be something like a >>> 'base_settings.py' that includes all required settings and then an option >>> for end users to load additional settings via bind mounts/volumes? >>> >> >> Django gives the possibility to set the default settings, so we could do >> that in openwisp-utils to set the settings that are usually the same for >> all openwisp instances (so the settings file becomes leaner and easier for >> us to read and maintain). >> Then we can use env vars for the rest of the settings and have some >> settings generated dynamically depending on the content of some other >> settings or ENV variables, this kind of implementation could also live in >> openwisp-utils. >> We have to figure out the best way, this will take some trial and error I >> believe. Don't you think? >> I tried providing some ideas, if anyone has other interesting ideas >> please share. >> >> Federico >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OpenWISP" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "OpenWISP" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
