Skip to content

Plone on WSGI sprint report

November 22, 2010

Two laptops, two sprinters and two bottles of whiskey. What could possibly go wrong?

This is my attempt to document what I can only describe as the “Plone on Whisk-gi” sprint… As part of the Plone deployment sprint at the recent Plone Conference in Bristol, Reed O’Brien and I decided to try to get Plone 4 working on WSGI.

Why is this important? Hanno Schlichting (current Zope2 release manager) tells us on his blog post about the recent Zope 2.13 release:

Zope 2.13 comes with native WSGI support. First pioneered in the repoze.zope2 project, this capability finally found its way back into the core and obsoletes the externally managed project. With WSGI, Zope 2 can natively talk to a variety of web servers and isn’t restricted to its own ZServer anymore. It also opens up new possibilities for writing or reusing middleware in Zope 2 or factoring out capabilities into WSGI endware. It’s expected that this new deployment model will over time become the default and the old ZServer implementation will be deprecated. There’s no concrete timeline for this yet.

What is Hanno saying here? Basically, it means that Zope 2.13 (and subsequently Plone) can run on a server without the added complexity of a long-running process (ZServer). Just as PHP-based applications enjoy ease of deployment since Apache already has mod_php enabled, so too could Zope-based applications be easily deployed if mod_wsgi were enabled.

In thinking about how Plone and Zope can be more accessible to systems administrators and hosting companies, moving to a scenario in which Zope does not require a separate long-running process, and can be deployed essentially at the Apache layer is a step in the right direction.

As Hanno alludes to above, with the WSGI deployment model, Zope/Plone are able to tap into a whole ecosystem of 3rd party WSGI middleware tools. Repoze is an initiative to extract many of the core Zope technologies into reusable WSGI middleware components, that can be used in other Python web application frameworks. More WSGI components can be found on PyPi by searching for “wsgi”.

Also, by adopting a more typical deployment method, Zope will not seem so exotic to developers coming to Zope from other Python web frameworks. For example, the official Django documentation recommends deploying Django using mod_wsgi, so Django developers will likely already be familiar with this way of deploying Python web applications. Incidentally, if you’re doing Django development, check out twod.wsgi which makes WSGI a first-class citizen in Django applications.

How does Plone fit in this picture?

Plone, arguably being the most popular Zope2 application on the market, can stand to benefit from the WSGI deployment strategy. There have already been some efforts to do so with repoze.plone and repoze.zope2 (now deprecated with the release of Zope 2.13).

Calvin Hendrix Parker blogged about deploying Plone and Zine together with Deliverance using Repoze, and Wojciech Lichota blogged about his buildout for Plone 3 with Deliverance on WSGI. Nathan Van Gheem has also written a couple blog posts about his experiences running Plone 4 with a Zope2 WSGI and running Plone 4b4 with Zope 2.13.0a1.

Now that Plone 4 is officially out and Zope 2.13 has had a final release, the instructions for getting this working are considerably easier.

Here are the steps required to get Plone 4 running under WSGI using paster.

1. Create a buildout.cfg file with the following:

[buildout]
extends =
    http://dist.plone.org/release/4.0.1/versions.cfg
    http://download.zope.org/zopetoolkit/index/1.0/zopeapp-versions.cfg
    http://download.zope.org/Zope2/index/2.13.0/versions.cfg

parts =
    instance
    paster

versions = versions

eggs +=
    roman
    Products.ZSQLMethods

[versions]
Zope2=2.13.0
Products.ZSQLMethods = 2.13.3

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
eggs +=
    ${buildout:eggs}
    Plone
    Paste
    PasteScript
    PasteDeploy
    repoze.tm2
    repoze.retry

[paster]
recipe = repoze.recipe.egg
scripts = paster
eggs = ${instance:eggs}

2. Create a zope2.ini file:

[DEFAULT]
debug = True

[app:zope]
use = egg:Zope2#main
zope_conf = %(here)s/parts/instance/etc/zope.conf

[pipeline:main]
pipeline =
    egg:paste#evalerror
    egg:repoze.retry#retry
    egg:repoze.tm2#tm
    zope

[server:main]
use = egg:paste#http
host = localhost
port = 8080

3. Run the buildout and modify the zope.conf file:

Run the buildout which will generate the paster script in the bin dir and the zope.conf file in parts/instance/etc. You then need to comment out the <http-server> part in this file. If you don’t comment out these lines, then paster will complain that there is already a server running on port 8080.

#<http-server>
# valid keys are "address" and "force-connection-close"
#  address 8080#
#</http-server>

4. Start up paster using the zope2.ini file:

$ paster serve zope2.ini
Starting server in PID 4666.
serving on http://127.0.0.1:8080

You can now go to http://127.0.0.1:8080 to see your Plone site served up by Zope on WSGI!

In the next blog post, we will describe how to get this semi-working in a production environment using mod_wsgi. For a sneak preview you can check out this buildout that Reed put together at the sprint. Note that there are a few patches that must be applied to Zope2, and hopefully Tres Seaver is reading this and will respond to them. 😉

What’s the official word on WSGI support for Plone 4?

Plone 4.1 will ship with Zope 2.13, but as Hanno states in PLIP #10776:

While Zope 2.13 provides native WSGI functionality, it is outside of this PLIP to make use of this in any way. There’s a large number of open questions around WSGI and the changes it requires to instance creation and setup, which warrant their own PLIP. A good number of those will also have an impact on the Zope 2 codebase itself, which is going to be already past a beta release by the time this PLIP gets started and thus will have to wait for Zope 2.14. I expect to see more community experimentation being done with WSGI once the capability is there. We might see a PLIP for Plone 4.2 to see those experimentations being solidified into good practice, standards and documentation.

So in other words, it’s still on the bleeding edge to try to use it, and probably not advised for production use just yet. As Hanno mentions, it’s expected that there will be more experimentation around WSGI, and as a community, we can come up with some best practices and documentation for how to do it in a sane way. Please let me know if you have done any experimentation with WSGI already, or if you’re interested in getting involved in these efforts.

8 Comments leave one →
  1. November 23, 2010 12:09 am

    Hey thanks for working on this, and also for clarifying why WSGI is cool! I’m sure 2011 will be a big year for Plone/WSGI deployments (while drinking Whiskey).

  2. November 23, 2010 12:47 am

    I’m about to move a website to plone4 in the near future and, being a django developer nowadays, I’m used to mod_wsgi 🙂

    So plone in mod_wsgi would be great.

    Note that the djangorecipe buildout recipe gives me a bin/django.wsgi file that I can directly hook up into my apache config. Something similar would be great for plone: forgoing the paster .ini file!

    • November 23, 2010 7:32 pm

      There is also a mod_wsgi buildout recipe, that will generate a wsgi python script which mod_wsgi can load. http://pypi.python.org/pypi/collective.recipe.modwsgi
      The recipe requires two parameters, the first being the eggs that have to be made available to the Python process that will run the app under WSGI and the second the path to the configuration file that will be used for the site. This last parameter value is the usual zope2.ini file that we have been using for running the application under paster.

  3. November 23, 2010 4:07 am

    Great writeup, this is all very exciting. It is great to see us starting to reap the long-promised rewards of WSG. I’m really looking forward to simpler low-end deployment stories!

  4. November 23, 2010 10:20 am

    Very nice writeup (and I didn’t know about Zope supporting WSGI, *very* nice!).

    I felt there was too little discussion about the whisky, though…

  5. Tres Seaver permalink
    November 23, 2010 3:58 pm

    I’m not sure to what I’m supposed to respond. That buildout contains two
    mutually-contradictory patches, with no writeup or justification for either.
    PLease ask Ross to open a Launchpad ticket with some verbage to accompany
    the “right” patch.

    • November 24, 2010 2:08 am

      Hi Tres – Sorry for the scarce details. I’ll ask Reed (not Ross) to provide more thorough explanation for why the patches were needed, and to open ticket(s) on Launchpad. (https://bugs.launchpad.net/zope2)

  6. November 24, 2010 5:47 pm

    Thanks for the excellent overview, and to both of you for sprinting on this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: