first off: Thanks for creating and more important maintaining such a great tool for the community.
I just tried to deploy a testing instance for a group in our organization (dzd-ev.de)
Modern production deployment happens via containers most of the time. Therefor it is really great that you provide the community with a docker container.
With having some experience in software development and IT operation under my belt I will be so cocky and just leave you some feedback here (without knowing anything about your processes and reasoning. maybe it will help otherwise just delete it)
I realized that you tried to squeeze everything you need into one container. On first sight that is a great idea: Anyone who wants to deploy your application just need to start this one containers.
On second sight that approach comes with a lot of pitfalls, anti-best practices and false incentives.
A multi container approach with a docker compose file that transparently links all your modules is much more flexible, maintainable and only a tiny bit more complex to setup.
First pitfall for me was: How do i backup and restore the postgres db? It is very hard to replicate what the user/password and database is. It almost feels like as you would have tried to hide the DB from the operator
There are a bunch of articles out there why you should have one container per process. But having at least the database in an extra container is a basic best practice.
Lets have a real life examples what i mean by false incentives: In our case we had a lab person, with some basic IT knowledge. It was possible for the person to spin up a openbis instance. Was it possible to create a automated backup of the state of the application and restore the data if needed? : No. A postgress data volume is not a restorable backup.
Will the database brake some day and nobody knows there was a postgres running inside the container and data will be lost, tears will be shed? Possible. Who will be blamed? Not the failing postgres DB but openbis as a software product.
My approach is: Do not hide complexity to lure spare time admins. This approach will help spare time admins in short time but possible hurt them much more in the longtime. On the other side it makes professional production deployments just harder. I want to seperate reverse proxy, database and webworkers. That is only possible at the moment if i build my own containers.
In short: Would be great if there is a container per process/module and a good docker-compose file to wrap it all up instead of the single-do-it-all container. I think this will also streamline your CI/CD Repo very much. It looks complex a.f. on first sight
If you want to talk about CI/CD or have soem support just give me a ping at firstname.lastname@example.org
Thanks for reading and have a great one