jensens
commented
4 months ago +1 for
- separation of venv and app (actually it is what I do in my project images)
- a /backend and /frontend in one image
-1 for using supervisor or alike to start both in one
I would create a endpoint with two options to start either one or the other.
ad WSGI server: Either fix waitress or switch to a better one - in Kubernetes missing SIGINT support it is really annoying.
I can also recommend to look at Kaniko to build the images.
avoinea
tschorr
Gathering some topics for improvement base on existing issues and some discussions during Beethoven sprint 2024.
Use separate paths in frontend and backend containers instead of /app
To prepare for new plone.distributions and creating single container demo images for these distributions, I'd like to discuss to move plone-backend and plone-frontend install paths in the containers to separate paths. They both install in /app now. this means we would need to create and maintain alternative docker-entrypoint.sh's. If plone-backend would install in /backend and plone-frontend in /frontend, a single image plone-demo Docker image could copy from our containers and re-use the docker_entrypoint.sh
/data would contain the zodb/blobstorage /venv the virtualenv required for the backend. ( @ericof you mentionned something at Beethoven sprint this had advantages?
For a distribution single image demo we could then use supervisord (we have to install python anyway) or a lightweight alternative like multirun to start the separate processes.
Switch to another wsgi server
The waitress wsgi server we are now using did have a 3.0 release, but issues like ont responding to SIGINT now adds a 10 second delay to any plone-backend container shutdown. There are also other known issues with waitress. Maybe use an alternative and also actively maintained wsgi server like pyruvate from @tschorr?
Decrease final container image size
For example see #132
Please add more here.