Today I have plone 5.2 (python 3.9) buildout setup with almost 50 plone sites each with its own mount point (plone.recipe.filestorage) for easy management. Also, each site is using one of three themes we developed.
We are considering strategies for future migration to Plone 6 (without volto initially), and tinkering with docker images for plone-backend and plone-zeo. Since those images are pip based we can’t use plone.recipe.filestorage.
What you guys recommend? A container for each site? Or just stick with buildout?
Any experiences with similar setups are appreciated.
run one central PostgreSQL with an own database per site and use RelStorage. Also use a connection-pooler like pgbouncer to deal with the connections.
I would go one container per site. I tend to run it on small Kubernetes cluster (like K3S), but that is a matter of taste, i.e. a dependent on the size and redundancy needs of the sites a single node Docker Swarm setup can be enough.
What is the recommended way in an scenario with Volto Sites?
If we have say 50 backend-containers. Is it recommended to have also 50 frontend-containers?
If the sites have really reduced traffic/requests: Is it possible/recommendable to have 1 frontend-container serving more than one backend-container? Is this technically feasible at all? Does this make sense?
No, not right now. One frontend container for each site, due to technical limitations. There is an initiative to solve this issue, but it's stalled right now.
And if we have different sites on the same instance?
I've been playing with this and I was somehow able to access the different Sites with localhost:3000/Plone1 and localhost:3000/Plone2. But when trying to login the urls were confusing the server.
Am I correct assuming that this scenario too is not yet feasible?
so the server-side generation of the HTML, when handling multiple websites, is wrong, because the config is not supposed to be shared between websites.
Now, you may say "all my websites are configured the same", or you have logic that can accomodate the identical config. But the problem is that the apiPath is held in the config. So the task would be to untangle the apiPath and always compute it in the helpers and also make sure that the existing code is also properly updated.
The overhead of running two instances/containers with one site each vs one with multiple sites is minimal. But the headache with multiple sites in one Zope is hurting.
Warning: this is not a supported combination. I think quite some fixes were needed in Zope to support Python 3.9, and that has only gone in Zope 5, which can only be used with Plone 6. Some fixes in Plone were likely needed as well, which may also be available only in Plone 6. And you will need to upgrade the pyScss package to 1.4.0, otherwise Plone won't startup.
Also on our central testing server, Jenkins, you can see with which Python versions Plone 5.2 is tested. Python 3.9 is not one of them.
So you should use Python 3.8. But... if your 50 Plone sites currently run without problems, then you can choose to ignore this advice.
I setup a PostgreSQL cluster too with each site having its on DB. I am working on using pgbouncer to deal with connection pooling but I can't tell if my pooler is working correctly (from the logs). my clients are pointing at the db server on port 5432... how did you manage to get zope clients able to talk on say 6432? would you be able to describe (briefly) how you did your setup? once I finish my documentation, I can contribute it to the new docs if the use case warrants.
FWIW, I'm keen on docker as a dev tool but I don't feel comfortable with it as production. Our team is a little pressed learning how to use the new tooling in the Plone6 universe, I'd rather for now stick with supervisor or pm2 running wsgi than worrying about the surface area docker presents.
By any chance have you used pg_auto_failover in your travels? My PostgreSQL cluster lives within premise VMware so I am planning on straddling both datacenter within the building and using pgbouncer to make sure connections play nicely with the server and the before mentioned failover plugin to keep things nice if something were to go south (sorta my own flavor of ZRS?).
going to duplicate my cluster and try integrating pg_auto_failover on my test instance and then try for production. If this is successful, I'll be sure to share.
