Section 18.1. Choosing Your Production Environment

18.1. Choosing Your Production Environment

So you've spent weeks or months developing your new application and now is the time to "go live." The first choice you have to make is determining which operating system you want to use on your production servers.

Here are the main decisions that you have to make and a few pointers to help you make these decisions. Of course, if you aren't working on your own web 2.0 start-up (and let's face it, most of us aren't), some of these choices might be imposed by your budget, your boss, or other outside forces.

18.1.1. Operating System of the Server(s): Linux, Mac OS, Windows?

The first choice you have to make is the operating system you plan to use for your upcoming deployment. The good news is that TurboGears runs equally well on all of these platforms, so it's really up to you to decide which one you want to use and support. So, you'll want to make this decision based on outside issues such as: your budget, familiarity with the operating system, your assessment of the stability/maintainability of the platform, corporate policy, and whatever other concerns are important to your particular situation. The good news is that no matter which of the major operating systems you choose, you'll be able to deploy your TurboGears application.

Of course, it's also possible that you made some choices in development that bind you to one operating system or another. For example, one of the authors deployed a TurboGears application to monitor, track, and manipulate windows services through a web interface. Because this required access to Active Directory, and Win32 services, the application as written could only be deployed on Windows.

With that said, most people find that Linux provides them with the best cost/benefit ratio for deployment. In this context, it's probably worth mentioning that unless you added OS-specific code as described above, there's nothing stopping you from using one operating system in development and another when you deploy.

18.1.2. Should I Run CherryPy behind Another Web Server?

CherryPy comes with a built-in HTTP server. This HTTP server is great for doing development, but can be limited for production websites:

• It doesn't support full HTTP/1.1.

• It doesn't have any support for Secure Sockets Layer (SSL).

• It can only listen to one port.

• It might not be very robust in handling buggy or nonstandard HTTP requests.

• It doesn't add or remove threads dynamically when the traffic increases or diminishes.

For these reasons, it is probably wise to run CherryPy behind another web server, such as Apache, IIS, or lighttpd. These web servers will provide you with several important benefits:

• You get HTTP/1.1 connections between the browser and the web client, which is where it matters the most.

• You can configure the web server to serve static data directly. This frees CherryPy from that task, and the web server will be faster than CherryPy for serving static data.

• You benefit from all the features from the web server, such as SSL support, GZip compression, and so on.

• Most web servers can handle "virtual hosting" (that is, multiple domains/websites) and direct requests to one or more CherryPy servers accordingly.

So for any TurboGears site that is going to be exposed to the public Internet, you'll probably want to take advantage of Apache, IIS, lighttpd, or another dedicated web server.

18.1.3. The Basics of Configuring TurboGears for Production

But before we get into the specifics of how you configure the front-end server to work with TurboGears, it makes sense to look a bit more deeply at the way that TurboGears configuration works, and how to configure a TurboGears project for production.

TurboGears provides three files for configuration values: dev.cfg, prod.cfg, and app.cfg. You can probably already tell from the names what they are for:

• dev.cfg stores all the configuration information specific to your development environment.

• prod.cfg stores all the information specific to your production environment.

• app.cfg stores any configuration information for your application that isn't specific to the development or production environments.

Assuming for the moment that all you've modified in your dev.cfg file is the database URL (which is often all you need to do), all you need to get your prod.cfg file ready is to update the prod.cfg file with the location of your production database. But, how do you get TurboGears to pull the values from prod.cfg rather than dev.cfg? Fortunately it couldn't be easierall you have to do is delete dev.cfg; TurboGears will automatically start using your production configuration.