Using Buildout To Deploy a Plone 2.1 Site To The Cloud#

Plone 2.1 Buildout

Believe it or not, there are still Plone 2.1 sites in production. (And 1.0 sites too, for that matter. Just look for the tell-tale ‘/help’ sign, e.g., if you suspect Plone 1).

I know, because I just deployed one (a cool artist’s site if you have a couple hours to kill…). But I didn’t do it the “old way” with Zope 2 instances created by hand on clunky physical servers, I used Buildout and the Cloud.

Aside #1#

As an aside: it was really bothering me lately that you couldn’t (easily) find older Plone releases at SourceForge. This is by design to avoid confusion, but still confusing. So when I needed the most recent 2.1.x tarball I decided to scratch my itch and fix the “problem”. I started gathering the hard to find releases and putting them here. OK… so I only gathered one release (2.1.4), but I swear I had good intentions. If you’d like to see any additional releases “moved” to, please let me know in the comments.

Aside #2#

Another aside: I should mention here the advent of a tool that promises to simplify deployment of Python-based web applications to the cloud (or supported service, which technically does not have to be “cloud-based”) via the use of APIs (in particular, the Rackspace Cloud API, which is the only one supported so far): Silver Lining! The idea of using this tool got me so excited, I spent some time experimenting with setting up a new host with it (and purchasing their service). But when I realized it was not quite ready for production (i.e. “if you want to use Silver Lining, Silver Lining is not for you”), I ended up using the Rackspace Cloud web interface.

I was so impressed with it.

I literally moved all of my (granted, relatively small number of client sites) to their service within a matter of 1-2 months. Now, I know what you are thinking, and I do intend to explore other services (in fact, I have tried Slicehost and it was OK), but this service made my life so much easier I wanted to mention some of its key features:

  • “On the fly” requisitioning. You can add/remove hosts anytime and you only pay for the time they are up.
  • “On the fly” resizing of hosts. In my testing and real world experience, the resizing (e.g. move from a host with 256MB RAM and 10GB disk to 500MB RAM and 20GB disk) was painless (literally only cost a few minutes of downtime).
  • The potential for all of this to be done remotely via a command line tool like Silver Lining.

Aside #3#

A third and final aside: the status quo of WSGI support for Plone. Since Zope 2 is not supported by Silver Lining, the key to deploying Plone sites with it is currently to use repoze.zope2. Nate Aune has recently made some progress with this, and more work is scheduled forPlone Symposium East. My latest swipe at WSGI-Plone is here:

The actual point#

And finally, to the point of this blog entry! I have created a generic Plone 2.1 buildout for anyone interested. You can find it here: Using it is simple, as described in the README.txt:

$ svn export plone
$ cd plone
$ python2.4
$ bin/buildout
$ bin/instance fg

Since Plone 2.1 community support has expired for this release, and since Plone 2.1 shipped with Python 2.3 (if I recall correctly), this is definitely “unsupported use of Plone”. But when you need it, you need it. I have yet to experience any issues related to the Python version, for whatever that is worth (possibly due to the fact that Plone 2.1 originally shipped with Python 2.3 and Zope 2.7, then Zope 2.8 came along which worked with Python 2.4. Just a guess).