Skip to content

Best practices in deploying and optimizing your Plone site

August 25, 2009

While there is ample documentation on plone.org and elsewhere about how to deploy and optimize Plone sites, the opportunities to get formal training on this subject seem to be few and far between. So I’m very excited to be teaching a new training course at the upcoming Plone Conference 2009 in Budapest entitled Best Practices for Deploying and Optimizing Plone sites.

Sign up today to reserve your spot!

In this blog post I want to go into some more detail about what topics the course will cover, and introduce a series of articles that I will post on this blog leading up to the training at the end of October.

The idea is that by writing a series of blog posts will 1) help me get my training materials prepared, 2) get feedback from the community on these materials, and 3) generate buzz about the training. In effect, killing three birds with one stone!

The two-day course will be divided into three parts:

  1. Creating a repeatable deployment
  2. Setting up the production environment
  3. Testing and automation

What you will learn in this article

For this first article in the series, we will introduce the most basic first step in setting up a Plone site: creating a buildout. This will include:

  1. setting up your development environment
  2. creating a virtualenv
  3. creating the buildout
  4. running the buildout
  5. creating the Plone site

Setting up your development environment

We will assume that you are either on Unix-like operating system, either MacOSX, Linux or BSD and that you have Python 2.4 installed on your machine. If not, you should follow these instructions on Debian/Ubuntu Linux. The basic idea here is you need the build tools, subversion, python 2.4.x, and the python dev packages so you can run buildout and compile Zope.

$ sudo aptitude install build-essential python-dev python2.4 python2.4-dev subversion

Installing Python modules with easy_install

easy_install is a tool for easily installing new Python modules in your system. The first thing we need to do is make sure easy_install is set up on your machine.

$ wget http://peak.telecommunity.com/dist/ez_setup.py
$ sudo python ez_setup.py

This will run a bunch of commands to install setuptools which includes easy_install, the command that we will use to install a lot of other utilities. Before we can create our buildout, we need to make a virtualenv.

Creating sandboxes with virtualenv

Virtualenv will let us create a virtual environment or sandbox with our own local Python. This provides separation of the Python development environment for our specific project from the operating system Python environment. We avoid polluting the system Python with a bunch of modules that are specific only to this project. This also allows different projects to have different versions of Python modules.

$ sudo easy_install-2.4 virtualenv

It will put a script in your /usr/local/bin directory called virtualenv.

$ cd /opt/local/buildouts  (or wherever you like to keep your buildouts)
$ virtualenv --python=python2.4 budapesttraining  (we use --python=python2.4 to make sure that Python 2.4 is used)

You should see something like this:

Running virtualenv with interpreter /opt/local/bin/python2.4
New python executable in budapesttraining/bin/python
Installing setuptools.............done.

Now we can go into this directory and activate this virtualenv.

$ cd budapesttraining
$ source bin/activate

Your prompt will change to (budapesttraining) so that you know this virtualenv is now active. To deactivate it, simply type “deactivate”.

Creating the buildout

Now we will create our buildout directory. Normally, we would use the ZopeSkel template, but it currently still uses plone.recipe.plone instead of the Plone egg, so we’re going to create the buildout using a more manual process, but one that will result in a much simplified buildout.cfg file. When Zope is fully eggified, then this buildout will get even more simplified since we can just say eggs = Zope, to install the latest Zope.

mkdir buildout
cd buildout
wget http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
[mate|vi|emacs] buildout.cfg  (use your text editor of choice to edit a buildout.cfg file]

Put the following in the buildout.cfg file:

[buildout]
extends = http://dist.plone.org/release/3.3/versions.cfg
versions = versions
find-links = http://dist.plone.org/thirdparty
parts =
    zope2
    instance

[zope2]
recipe = plone.recipe.zope2install
url = ${versions:zope2-url}
fake-zope-eggs = true

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
eggs =
    PIL
    Plone

Running the buildout

Save the buildout.cfg file, and then run these two commands:

$ python bootstrap.py
$ bin/buildout -v

Starting up the Zope instance

Try firing it up with this command, which will run Zope in the foreground (so you can see all the debugging information):

$ bin/instance fg

If all goes well, you should see this:

2009-08-25 21:04:30 INFO Zope Ready to handle requests

Creating a new Plone site

Next we will create a new Plone site.

  1. Go to the Zope instance in your web browser: http://localhost:8080/manage and type in your username and password (admin:admin).
  2. From the add menu, choose “Plone Site”. Give it the ID of “Plone”.
  3. Now you can go to http://localhost:8080/Plone to see your new Plone site!

Conclusion

And that concludes our first basic lesson in creating a basic buildout. As always, your feedback is most welcome. Please use the comment form at the bottom of this page.

For a more in-depth look at how to manage your Plone project using buildout, I suggest looking at Martin Aspeli’s excellent tutorial on plone.org: Managing projects with buildout.

For the next article, we will look at how to:

  1. Check in/out your code changes to a subversion repository
  2. Set up an egg proxy to avoid buildout failure if pypi is down
  3. Release eggs to pypi, plone.org and your own private egg server

Get hands-on training from Plone experts

If you are attending the Plone Conference in Budapest, and would like to participate in our comprehensive training course on Best Practices for Deploying and Optimizing Plone, the two day class costs only $300 USD. Read the full agenda – suggestions for other topics are most welcome!

Seating is limited, so I encourage you to sign up today to reserve your place.

Chris Calloway just posted an excellent summary of the other Plone training opportunities that will be offered in Budapest. This is a great opportunity to boost your knowledge of Plone and get all your Plone questions answered.

5 Comments leave one →
  1. Peter Jacobs permalink
    August 26, 2009 6:25 am

    Thank you, I have looked at my buildout script and removed the PILwoTk recipe, it works fine like you show here.

    You use:
    find-links = http://dist.plone.org/thirdparty
    but this also works for me (probably not much different?):
    find-links = http://dist.plone.org/release/3.3/

    • August 26, 2009 10:23 am

      Yeah, it looks like the only difference is that the /thirdparty has python_ldap and PILwoTk, whereas the /release/3.3 just has PIL-1.1.6 and no python_ldap. So if you need python_ldap or PILwoTk, then you should use /thirdparty, otherwise /release/3.3 should work fine.

  2. August 26, 2009 9:02 am

    Is “best practices” really using easy_install and virtualenv?

    As far as i am aware — this is completely broken — and the only recommended way of installing Plone is via buildout or the universal installer…

    I was convinced that easy_install for Plone had big red letters of warning saying “DON’T USE” all over it.

    Just use buildout.

    • August 26, 2009 10:20 am

      Geir – I am not proposing that one should use easy_install to install Plone. The article shows using buildout to install Plone. I only mention easy_install because it’s an easy way to get virtualenv installed, which *does* work with buildout. In subsequent articles we will be using easy_install to install other tools such as collective.releaser, collective.dist and ZopeSkel.

Trackbacks

  1. Avoiding buildout failure when pypi is down using collective.eggproxy | Jazkarta Blog

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: