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. > 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? Thanks, Andrew On Sat, Mar 30, 2019 at 3:47 PM Federico Capoano <[email protected]> wrote: > We should only generate images once, the env vars can be set at run time > and configurations file can be loaded from volumes or from private git > repositories if needed and can be manipulated with shell or python scripts. > We can't generate one image for each organization, I myself manage many > different organizations and having to maintain one image for each would add > a crazy load on people like me. > That is very inefficient and I see no advantage in doing that. > > Keep in mind the following important concept: > > - the image is the software, the base images will be identical for all > users > - environment variables and django settings are configurations, those > change by each organization and can be set at run time > > 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. > > Please review this important detail before going ahead with your prototype. > > Federico > > On Sat, Mar 30, 2019 at 2:43 PM Ajay Tripathi <[email protected]> wrote: > >> Hi, >> >> Please see the following project details: >> >> We create base images for openwisp-modules with all the system and python >> packages installed. >> The user would be expected to use these base images and create images for >> their organization by following the usage instructions provided after >> setting the appropriate values for their organization in the `.env` file. >> Note: During this build, django settings like `SECRET_KEY` would be set >> in the image, hence the generated images are to be kept in a private >> registry and the values of the `.env` can be saved privately for >> re-creating the images as well. >> I have implemented this here[1]. >> The `base/` directory in this implementation contains the Dockerfiles and >> requirements for creating the base images that are to be pulled by the user. >> The user simply has to manipulate all the values in the `.env` file, >> then run `make_secret_key.py` to generate a new secret key. >> Finally, build the images with `docker-compose build`. >> When the images are ready, the newly generated images can be used in >> production. >> >> Let me know if that sounds good to you. >> >> Something you should keep in mind, since we are porting what we learned >>> in ansible-openwisp2 to docker, we should somewhat follow the path we >>> learned there and offer a similar feature set. >>> >> >> Got it! >> >> >>> In your diagram, I see different boxes for PostgreSQL, I'm not sure if >>> that's good, could you expand on that? Are those different postgresql >>> server instances? How are they synced? >>> Is there a better way? Have you found some information about best >>> practices around this subject? >>> >> >> Unfortunately I don't have much knowledge about the best practices. For >> now, I'll represent as one instance of postgres in the diagram and research >> on it and get back to you. >> >> >>> >>> There's a diagram with nginx and django-freeradius, this doesn't seem to >>> make sense to me. OpenWISP Radius is based on django-freeradius and that's >>> our radius module, we won't run django-freeradius alone (you can consider >>> django-freeradius as a base library / django reusable app). >>> >>> I see gunicorn being mentioned, I'm pretty happy with uWSGI and I would >>> like to continue using that as our application server. >>> >>> Would be great to see the different containers/services being listed in >>> the diagram example: >>> >>> - OpenWISP Dashboard: admin + openwisp-users views >>> - OpenWISP Controller (connections branch) views and APIs >>> - OpenWISP Network Topology views and APIs >>> - OpenWISP Radius views and APIs >>> - websocket server of OpenWISP >>> - celery worker >>> - celery-beat >>> - OpenVPN management VPN >>> - freeradius instance >>> >>> And do not forget to indicate the mounted volumes that allow to store >>> persistently files that are uploaded by users (eg: floor plan images). >>> >> >> Alright, Got it. :) >> >> Ajay >> >> >> Ref: >> --- >> [1]: >> https://github.com/atb00ker/scripts-lab/tree/master/experiment/dockerize-openwisp >> >> -- >> 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.
