GNOME Website - Plone Deployment

This page aggregates all information necessary to deploy the GNOME website Plone instance in the GNOME servers.

Location

The test Plone instance should be available at website-test.gnome.org.

Code

See GnomeWeb/Plone/Development for information about the code repository.

Concepts

Plone can be installed using the Unified Installer, the Package-Manager of the operating system of your trust or using a custom setup based on the release of a stable Plone version. The Unified Installer is easy to use and offers a nacked Plone after a few minutes. Unified Installer is based on buildout and offers a graphical UI. Its perfect for people just trying out Plone. Packages deployed with the operating system are (with some exceptions) usally Plone-stone-age and not recommended. Pure Buildout without the Unfified Installer around is perfect for flexible deployments. Latter is what we target at.

Plone: Zope + buildout

Plone uses the deployment scripting system zc.buildout (short buildout). It performs a bunch of tasks to get a Zope 2.10 prepared for the WGO up and running. It keeps complex things together: Python-eggs (packages) from packages index servers like PyPI or svn checkouts referenced through svn:externals property. In the buildout configuration file are all python-package dependencies defined. The specific buildout for WGO lives in the Plone Foundations collective subversion repository. Zope 2.10 is compiled using the configure/make/make-install (CMMI) process.

Buildout can be segmented: I.e. base.cfg file contains all commaon configuration, a 'develop.cfg' contains all needed for a single local development instance and the buildout.cfg contains the full stack needed for the deployment on the live site.

The buildout itself lives usally also in a VCS, subversion is used much in plones world.

After starting the Zope webapplication server you'll get an empty zope database container which can be accessed through the webbrowser. Inside an Plone Site object need to be created and the wgo configuration need to be applied. This is done once. In subsequent installations the database-file can be copied into the ZEO-database-server before Zope is started.

Caching & Clustering

A single Zope instance is not suited to serve a hi-load site like WGO. Zope is not a webserver nor a caching server. To make WGO-Plone fast a reverse-proxy-cache is needed. First choice for Plone, zope and other cms/webapplication is varnish. Varnish 2 need to be setup for use with plone. This is usally done using buildout as well.

A single Zope instance has by default 4 worker threads. Because of Pythons limitations to use multi-core system within one thread and optimizations of internal caches we reduce the worker threads to 2 and start two instances per CPU-core. A load balancer like pound can be used (or the new varnish built-in balancer configured).

All Zope-instances are using one database provided by the ZEO-Server (Zope Enterprise Objects: Zopes Object Database Server).

Webserver

Varnish can be used direct to listen on port 80, do url-rewriting and serve pages to the public. Because of security concerns usally a bullet-proof web-server like Apache or nowadays often Nginx is used. Nginx has some advantages like lightweight implementation, better web-application-server support etc., but in case of WGO it doesn't matter.

Dependencies

• Use Plone 3.2.2 (latest stable final) (or 3.3 final if final is released before milestone 2 is reached, 3.3rc2 is already released)
• Python 2.4.5
• Most dependencies are declared and resolved inside the buildout.

The Deployment in detail

Hardware Requirements

Input needed! Here we need details of what is possible (hardware) vs. what is needed (how many visitors, hits/day, pages/day, ... stats).

Service Map

Missing: What in details is needed and how does it work toegether.

Recipe: Roll out the deployment

Add the detailed deployment documentation step by step here

Continuous build

Ideally, the test Plone instance running on GNOME servers would always be using the latest code from the repository. We could use the same approach than the current GNOME website where a commit on the git repository automatically triggers a new build of the website. In case the Plone code resides out GNOME git during the 2.28 cycle, we can have a predefined number of builds per day (1-2).

Missing: provide a script that checks out the latest code and rebuilds the code and restarts the Plone instance