[Setup] Multiple Plone sites in development and deployment
unclelarry at inlandnet.com
Tue Mar 8 17:26:59 UTC 2011
On 3/8/2011 2:02 AM, Giovanni Toffoli wrote:
> I've just run against an annoying limitation of the buildout.
> After a few attempts I was able to implement a setup configuration
> extending the default buildout.cfg of Plone 4 with
> - multiple mount-points added to the default zope instance
> - a Zeo server handling a second ZODB with 2 mount-points
> - a number of Zeo clients.
> following the documentation of plone.recipe.zope2instance,
> collective.recipe.filestorage and plone.recipe.zeoserver.
> Then I tried to extend further the buildout by adding
> - a second Zeo server handling its own ZODB and mount-points.
> But I realized that plone.recipe.unifiedinstaller doesn't allow to have
> more than one zeoserver in the same buildout. It seems that what the
> buildout generates is all ok, but the plonectl script, due to the
> limitations in the ctl.py module.
> This is an expected behaviour (but no warning is issued); however, it is
> a pity in my view. Somebody could object against writing too
> large/complex buildouts, but I find very convenient being able to share
> among different projects most of the Zope/Plone code and of the buildout
> settings (eggs, zcml slugs, aso). Should I open a ticket in dev.plone.org ?
> ----- Original Message ----- From: "Giovanni Toffoli" <toffoli at uni.net>
> To: <setup at lists.plone.org>
> Sent: Thursday, March 03, 2011 1:25 PM
> Subject: [Setup] Multiple Plone sites in development and deployment
>> I recap my development environment:
>> - no Zeo, no proxies but Apache
>> - 1 ZODB in file Data.fs
>> - N mount-points: sub-folders db1, db2, .. dbn (files db1.fs, db2.fs,
>> .. dbn.fs)
>> - N Plone sites at the physical addresses /db1/site1, /db2/site2, ..
>> THE NEW QUESTIONS
>> For deployment, till now I always made the assumption of having a
>> unique ZODB (with a few mount-points) and a unique ZeoServer. But
>> possibly this isn't a reasonable choice.
>> My new questions, roused by a couple of replies, are:
>> 1. better having a different ZODB and a different ZeoServer per Plone
>> site ?
>> 2. in this case, the CPU and RAM overheads are acceptable ?
>> MY PROVISIONAL CONCLUSIONS
>> If the answers to both questions above are YES, in the deployment I
>> could keep the modularity of the development environment as follows:
>> - M sites; they could be subsets of sites coming from similar but
>> distinct development environments, on both Linux and Windows
>> - 1 ZODB per site, say in file sitej_db.fs (to be created by the
>> - 1 mount point per site, in ZODB sitej_db, sub-folder dbj (file dbj.fs)
>> - Plone object filej, in sub-folder dbj
>> - 1 ZeoServer and 1 or more Zeo clients, or no Zeo at all, per site.
>> In this case, the buildout file would be bigger but probably I would
>> be able to write it by myself. In each case, I would have a unique
>> buildout and would share among the sites both Zope and Plone
Standard procedure is to have two buildout files like: production.cfg
and staging.cfg that extend your main buildout file. These files will
have the settings for your zeo and zope instances. They will be
basically the same, but with the servers running on different ports.
Install the production and staging instances in separate directories.
I've got a script that copies the ZODB file and the blob directories
from production to staging so that I can test new things on a recent
copy of the production site.
I like keeping my production and staging environments separate like
this. I can delete the staging instance without harming the production site.
There's not too much overhead with this method. You just have to update
your buildout from SVN when you make changes, then run your buildout...
Does that help?
Email: larry.pitcher at gmail.com
More information about the Setup