You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
The text was updated successfully, but these errors were encountered: