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 <ajay3...@gmail.com> 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 openwisp+unsubscr...@googlegroups.com. > 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 openwisp+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
