[Setup] Multiple Plone sites in development and deployment

Larry Pitcher 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 ?
> Giovanni
> ----- 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, ..
>> /dbn/siten.
>> 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 ?
>> 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
>> buildout)
>> - 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
>> directories/modules.
>> Giovanni


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?

Larry Pitcher
Catapult Solutions

Web:    www.catapultsolutions.net
Email:  larry.pitcher at gmail.com
Skype:  larry.pitcher
Office:  509.849.2660
Mobil:   509.629.1376

More information about the Setup mailing list