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" <toff...@uni.net>
To: <setup@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.
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
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
Hi,
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.pitc...@gmail.com
Skype: larry.pitcher
Office: 509.849.2660
Mobil: 509.629.1376
_______________________________________________
Setup mailing list
Setup@lists.plone.org
https://lists.plone.org/mailman/listinfo/setup
