Alternate Deployment Patterns
+This document attempts to discuss alternate patterns for deploying
+TurboGears |version|. It is written with the assumption that you
+have at least read the :ref:`deploy_standard`, as most documents
+will simply discuss the differences from a standard deployment.
New developers should likely use the :ref:`deploy_standard` (if possible).
The choices involved in alternate installations can be daunting if you
aren't yet familiar with the various components.
-Questions to answer for yourself:
-* :ref:`deploy_web_server` -- what application will actually accept
- the http requests from the client? This is normally a service that must
- be installed as "root" in order to claim the standard ports (80 or 443)
-* :ref:`deploy_which_database` -- what server will you use to store your
-* :ref:`deploy_source` -- will you deploy with source-code-checkouts, built
- eggs, whole-application binary checkouts, zc.buildout packages,
- PIP packages or puppet scripts?
-The most common way to install TurboGears |version| for production use
-is to use the `Apache`_ web-server running the mod_wsgi extension
-to host TurboGears in a reasonably performant easily deployed
-and flexible configuration.
+The web-server, which actually receives and processes HTTP requests
+from clients and converts them to WSGI requests for your TurboGears
+project, can significantly impact the performance and scalability of
-There are many other approaches to deploying a production environment,
-and choosing which approach is best for your needs is a non-trivial
-* Apache with mod_wsgi tends to be the "default" choice. It is widely
- available, well documented, stable and easily supported by Linux
- sysadmins in production environments.
-* Apache with mod_proxy or mod_rewrite can be used to have Apache handle
- "the rest" of your site, while passing only your TurboGears application's
- requests through to a Paster server running on a non-privileged port.
-* Apache with FastCGI can be used if necessary, such as when you do not have
- control of your Apache server or a policy requires suexec or the like for
-* `Nginx`_ is often preferred by those who need speed above all else
-* The built-in Paster server will occasionablly be used by those
- who are deploying small internal sites with no more than a handful
-* IIS users may want to experiment with the WSGI support from the
+* :ref:`apache_mod_wsgi` -- the standard way to deploy on Apache
+* :ref:`apache_mod_proxy` -- runs Apache as a front-end with
+ a Paste web-server running on a local port. Allows you to run
+ the Paste server as *any* user
+* :ref:`FastCGI` -- runs Apache as a front-end with a `FastCGI`
+ process using Mod-Rewrite to make the CGI appear at the correct
+ point in the server's URL-space.
+* `paster serve production.ini` -- while not recommended for large
+ or high-traffic sites, Paste's web-server can often serve for small
+ internal sites with few users. See :ref:`deploy_daemon` for a
+ discussion of how to keep your server running.
+* :ref:`Nginx` -- an alternative asynchronous high-performance web-server
+ which can reverse-proxy TurboGears
+* :ref:`Light HTTPD <lighttpd_fcgi>` -- has built-in FastCGI support, so can
+ be used to reverse-proxy TurboGears
+* `Twisted Web2`_ -- likely only of interest if you are already using
+ Twisted for your application and simply want to host a TurboGears
+ application within it. Twisted's WSGI implementation is *not*
+ heavily optimized, so should not be used for high-performance sites.
+* MS-IIS users may want to experiment with the WSGI support from the
.. todo:: document use of `isapi-wsgi`_ with TurboGears
+.. todo:: Difficulty: Hard. Document use of IIS with TurboGears thru a proxy.
.. _`Apache`: http://httpd.apache.org/
-.. _`Nginx`: http://nginx.org/
.. _`ISAPI-WSGI`: http://code.google.com/p/isapi-wsgi/
-Normally users choose either MySQL or PostgreSQL as their production
-database back-end, but Oracle or MSSQL can also be used. The built-in
-SQLite database should not be used for production sites as a general
-rule. Obviously if you have used MongoDB/Ming you will need to deploy
-against a MongoDB database instead.
+If you are using SQLAlchemy (the default ORM for TurboGears |version|),
+then by-and-large your choice of database back-end is a matter of preference.
-TurboGears 2 provides a solid HTTP server built in, and for many
-internal corporate deployments or low traffic sites you can just fire
-up the TurboGears |version| app and point people at it.
+* :ref:`deploy_postgresql` -- is a robust, mature, well documented
+ free database server which meets or exceeds most new user's needs.
+* MySQL -- allows you to trade robustness (ACID compliance, for instance)
+ for raw speed and some exotic features that are add-ons for PostgreSQL
+* Oracle -- if your site is an Oracle shop with specialized Oracle admins
+ it may be appropriate to use an Oracle DB for your TurboGears application
+* SQLite -- can be used for *extremely* small sites (e.g. a local web-server
+ intended solely to be used by a single user). It is *extremely* easy to
+ set up and comes with later versions of Python.
+* MSSQL -- if you are already using MSSQL for your site, and have admins who
+ maintain the servers, it may be appropriate to use MSSQL for your TurboGears
This can be as simple as running::
- paster serve production.ini
-But it's also likely that you may want to automatically restart your
-TurboGears |version| app if the server reboots, or you may want to set
-it up as a windows service. Unfortunately these things can be very
-operating system specific, but fortunately they aren't
+.. todo:: Add section on "repeatable deployment options"