Best practices in deploying and optimizing your Plone site
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:
- Creating a repeatable deployment
- Setting up the production environment
- 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:
- setting up your development environment
- creating a virtualenv
- creating the buildout
- running the buildout
- 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 PloneRunning the buildout
Save the buildout.cfg file, and then run these two commands:
$ python bootstrap.py $ bin/buildout -vStarting 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 fgIf all goes well, you should see this:
2009-08-25 21:04:30 INFO Zope Ready to handle requestsCreating a new Plone site
Next we will create a new Plone site.
- Go to the Zope instance in your web browser: http://localhost:8080/manage and type in your username and password (admin:admin).
- From the add menu, choose “Plone Site”. Give it the ID of “Plone”.
- 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:
- Check in/out your code changes to a subversion repository
- Set up an egg proxy to avoid buildout failure if pypi is down
- 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.
Jazkarta Blog 
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/
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.
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.
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.