Django ------ Deploying Django 2012.09.06

最新推荐文章于 2024-11-06 11:17:40 发布

weixin_30426957

最新推荐文章于 2024-11-06 11:17:40 发布

阅读量131

点赞数

文章标签：数据库 python 网络

原文链接：http://www.cnblogs.com/wenjiashe521/archive/2012/09/06/2672473.html

版权

This chapter covers the last essential step of building a Django application: deploying it to a production server.

Preparing your Codebase for Production:

Turning off Debug Mode :Inshort , setting DEBUG to True tells Django to assume only trusted developers are using your site. The Internet is full of untrustworthy hooligans, and the first thing you should do when you're preparing your application for deployment is set DEBUG to False.

Turning Off Template Debug Mode:Similarly, you should set TEMPLATE_DEBUG to False in production, If True, this setting tells Django's template system to save some extra infomation about every template, for use on the pretty error pages.

Implementing a 404 Template:If DEBUG is True,Django displays the useful 404error page.But if DEBUG is False, then it does something different: it renders a template called 404.html in your root template directory. So,when you are ready to deploy, you will need to create this template and put a useful "Page not found" message in it. Here is a sample 404.html.It assumes you are using template inheritance and have defined a base.html with blocks called title and content.

{% extends "base.html" %}

{% block title %}Page not found{% endblock %}

{% block content %}
<h1>Page not found</h1>

<p>Sorry, but the requested page could not be found.</p>
{% endblock %}
To test that your 404.html is working, just change DEBUG to False and visit a nonexistent URL. (This works on therunserver just as well as it works on a production server.)

Implementing a 500 Template

Similarly, if DEBUG is False, then Django no longer displays its useful error pages in case of an unhandled Python exception. Instead, it looks for a template called 500.html and renders it, like 404.html, this template should live in your root template directory.

There is one slightly tricky thing about 500.html. You can never be sure why this template is being rendered, so it should not do anything that requires a databaseconnection or relies on any potentially broken part of your infrastructure. it should not use custom template tags, If it uses template inheritance, then the parent template(s) shouldn’t rely on potentially broken infrastructure, either. Therefore, the best approach is to avoid template inheritance and use something very simple. Here’s an example 500.html as a starting point:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
    <title>Page unavailable</title>
</head>
<body>
    <h1>Page unavailable</h1>

    <p>Sorry, but the requested page is unavailable due to a
    server hiccup.</p>

    <p>Our engineers have been notified, so check back later.</p>
</body>
</html>

-------------------------------------------------------------------------------------------------------------------------

Setting up Error Alerts:

When your Django-powered site is running and an exception is raised, you will want to know it, so you can fix it, By default, Django is configured to send an e-mail to the site devepopers when your code raises an unhandled exception-- but you need to do two things to set it up.

First , change your ADMINS setting to include your e-mail address, along with the e-mail addresses of any other people who need to be notified. This setting takes a tuple of (name, email)tuples, like this:

ADMINS = (
    ('John Lennon', 'jlennon@example.com'),
    ('Paul McCartney', 'pmacca@example.com'),
)

Second, make sur your server is configured to send a e-mail. Setting up postfix, sendmail or any other mail server is outside the scope of this book, but on the Django side of things, you will want to make sure your EMAIL_HOST setting is set to the proper hostname for your mail server, It is set to 'localhost' by default, which works out of the box for most shared-hosting environment. You might also need to set EMAIL_HOST_USER EMAIL_HOST_PASSWORD EMAIL_PORT or EMAIL_USE_TLS, depanding on the complexity of your arrangement.

Also, you can set EMAIL_SUBJECT_PREFIX to control the prefix Django uses in front of its error e-mails. It’s set to'[Django] ' by default.

-------------------------------------------------------------------------------------------------------------------

Setting Up Broken Link Alerts:

If you have the CommonMiddleware installed (e.g., if your MIDDLEWARE_CLASSES setting includes 'django.middleware.common.CommonMiddleware', which it does by default), then you have the option of receiving an e-mail any time somebody visits a page on your Django-powered site that raises 404 with a non-empty referrer — that is, every broken link. If you want to activate this feature, set SEND_BROKEN_LINK_EMAILS to True (it’s False by default), and set your MANAGERS setting to a person or people who will receive these broken-link e-mails. MANAGERS uses the same syntax as ADMINS. For example:1

MANAGERS = (
    ('George Harrison', 'gharrison@example.com'),
    ('Ringo Starr', 'ringo@example.com'),
)
Note that error e-mails can get annoying; they’re not for everybody.

-----------------------------------------------------------------------------------------------------------------------

Using Different Setting for Production:

So far in this book, we have deal with only a single setting: the setting.py generated by django startproject, But as you get ready to deploy, you will likely find yourself needing multiple setting files to keep your development environment isolated from your production environment.Django makes this very easy by allowing you to use multiple settings files.

If you'd like to organize your setting files into "production" and "development" settings, you can accomplish this in one of three ways:

Set up twp full-blown, independent setting files.
Set up a "base" setting file and a second setting file that merely imports from the first one and defines whatever overrides it needs to define
Use only a single settings file that has Pyrthon logic to change the setting based on context.

First, the most basic approach is to define two separate setting files, just make a copy of it called settings_production.py,In this new file ,change DEBUG.

The second approach is similar but cuts down on refundancy, Instead of having two settings files whose contents are mostly similar, you can treat one as the 'base' file and creat another file that imports from it,For example:

# settings.py

DEBUG = True
TEMPLATE_DEBUG = DEBUG

DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'devdb'
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_PORT = ''

# ...

# settings_production.py

from settings import *

DEBUG = TEMPLATE_DEBUG = False
DATABASE_NAME = 'production'
DATABASE_USER = 'app'
DATABASE_PASSWORD = 'letmein'

Here, setting_production.py imports everything from setting.py and just redefines the setting that are particular . you can redfin any setting, not just the basic ones like DEBUG.

Finally, the most concise way of accomplishing two setting environments is to use a single setting file that branches based on the environment. One way to do this is to check the current hostname, For example:

#setting.py
import socket
if socket.gethostname() == 'my_laptop':
    DEBUG  = TEMPLATE_DEBUG = True
else:
    DEBUG = TEMPLATE_DEBUG = False

Here , we import the socket module from Python;s stadard library and use it to check the current system's hostname. We can check the hostname to determine whether the codes is being run on the production server.

Renaming setting.py: You can fix this either by editing manage.py tho change setting to the name of your module. or by using django-admin.py instead of manage.py, In the latter case , you'll need to set the DJANGO_SETTING_MODULE environment variable to the Python path to your setting file

-----------------------------------------------------------------------------------------------------------------------

DJANGO_SETTING_MODULE

With those code changes out of the way, the next part of this chapter will focus on deployment instructions for specifc environment, such as Apache. the instructions are different for each environment, but one thing remains the same: in each case, you will have to tell the Web Server your DJANGO_SETTING_MODULE. This is the entry point into your Django application. The DJANGO_SETTING_MODULE points to your settingfile, which point to your ROOT_URLCONF, which points to your views ,and so on.

Django_SETTING_MODULE is the python path to your setting file.

===========================================================================

Using Django with Apache and mod_python,but as an altenative to mod_python, you might consider using mode_wsgi, which has been developed more recently than mode_python and is getting some traction inthe Django community.

-----------------------------------------------------------------------------------------------------------------------

Using Django with FastCGI

Additionally, in some situations, FastCGI allows better security and possibly better performance than mod_python. FastCGI can also be more lightweight than Apache.

FastCGI is an efficient way of letting an external application serve page to a Web server. The Web server delegates the incoming Web requests to a FastCGI.which executes the code and passes the response back to the Web server, which, in turn, passes it back to the client's whb browser.

Like mod_python, FastCGI allows code to stay in memory, allowing requests to be served with no startup time, Unlike mode_python, a FastCGI process doesn't run inside the Web server process, but in a separate, persistent process.(自己是一个独立的进程)，

Why Run Code in a separate process? Due to the nature of FastCGI, it;s also possible to have processes that run under a different user account than the web server process.(两个进程可以运行在不同的用户权限下)，Each Apache process gets a copy of the Apache enfinem complete with all the features of Apache that Django simply doesn't take advantage of, FastCGI processes, on the other hand, only have the memory overhead of Python and Django.

Before you can using FastCGI with Django, you will need to install flup, a Python library for dealing with FastCGI.

FastCGI operates on a client/server model, and in most cases you will be starting FastCFI server process on your own, your Web server contacts your Django-FastCGI process only when the server needs a dynamic page to be loaded,Because the daemon(守护进程) is already running with the code in memory , it is able to sever the response very quickly.

A web server can connnect to a FastCGI server in one of teo ways: it can use either a Unix domain socket or a TCP socket, What you choose is a manner of preference; a TCP socket is ususlly easier due to permissions issues.

To start your server,

./manage.py runfcgi [options]

A few examples:

Running a threaded server on a TCP port:

./manage.py runfcgi method=threaded host=127.0.0.1 port=3033

Running a preforked server on a unix domain socket:

./manage.py runfcgi method=prefork socket=/home/user/mysit.sock pidfile=django.pid

Run without daemonizing the process(good for debugging):

./manage.py runfcgi daemonize=false socket=/tmp/mysite.sock

To easily restart your FastCGI daemon on Unix, you can use this small shell script:

#!/bin/bash

PROJDIR="/home/user/myproject"
PIDFILE="$PROJDIR/mysite.pid"
SOCKET="$PROJDIR/mysite.sock"


cd $PROJDIR
if [ -f $PIDFILE ]; then
    kill `cat -- $PIDFILE`
    rm -f -- $PIDFILE
fi

exec /usr/bin/env - \
    PYTHONPATH="../python:.." \
    ./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE

==========================================================================

可扩展性

既然你已经知道如何在一台服务器上运行Django，让我们来研究一下，如何扩展我们的Django安装。这一部分我们将讨论，如何把一台服务器扩展为一个大规模的服务器集群，这样就能满足每小时上百万的点击率。

有一点很重要，每一个大型的站点大的形式和规模不同，因此可扩展性其实并不是一种千篇一律的行为。以下部分会涉及到一些通用的原则，并且会指出一些不同选择。

首先，我们来做一个大的假设，只集中地讨论在Apache和mod_python下的可扩展性问题。尽管我们也知道一些成功的中型和大型的FastCGI策略，但是我们更加熟悉Apache。

运行在一台单机服务器上

大多数的站点一开始都运行在单机服务器上，看起来像图20-1这样的构架。

http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-1.png

图 20-1：一个单服务器的Django安装。

这对于小型和中型的站点来说还不错，并且也很便宜，一般来说，你可以在3000美元以下就搞定一切。

然而，当流量增加的时候，你会迅速陷入不同软件的 资源争夺 之中。数据库服务器和Web服务器都喜欢自己拥有整个服务器资源，因此当被安装在单机上时，它们总会争夺相同的资源（RAM, CPU），它们更愿意独享资源。

通过把数据库服务器搬移到第二台主机上，可以很容易地解决这个问题。

分离出数据库服务器

对于Django来说，把数据库服务器分离开来很容易：只需要简单地修改 DATABASE_HOST ，设置为新的数据库服务器的IP地址或者DNS域名。设置为IP地址总是一个好主意，因为使用DNS域名，还要牵涉到DNS服务器的可靠性连接问题。

使用了一个独立的数据库服务器以后，我们的构架变成了图20-2。

http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-2.png

图 20-2：将数据库移到单独的服务器上。

这里，我们开始步入 n-tier 构架。不要被这个词所吓坏，它只是说明了Web栈的不同部分，被分离到了不同的物理机器上。

我们再来看，如果发现需要不止一台的数据库服务器，考虑使用连接池和数据库备份将是一个好主意。不幸的是，本书没有足够的时间来讨论这个问题，所以你参考数据库文档或者向社区求助。

运行一个独立的媒体服务器

使用单机服务器仍然留下了一个大问题：处理动态内容的媒体资源，也是在同一台机器上完成的。

这两个活动是在不同的条件下进行的，因此把它们强行凑和在同一台机器上，你不可能获得很好的性能。下一步，我们要把媒体资源（任何不是由Django视图产生的东西）分离到别的服务器上（请看图20-3）。

http://new-media.djangobook.com/content/en/1.0/chapter20/scaling-3.png

图 20-3：分离出媒体服务器。

理想的情况是，这个媒体服务器是一个定制的Web服务器，为传送静态媒体资源做了优化。 lighttpd和tux (http://www.djangoproject.com/r/tux/) 都是极佳的选择，当然瘦身的Apache服务器也可以工作的很好。

对于拥有大量静态内容（照片、视频等）的站点来说，将媒体服务器分离出去显然有着更加重要的意义，而且应该是扩大规模的时候所要采取的 第一步措施 。

这一步需要一点点技巧，Django的admin管理接口需要能够获得足够的权限来处理上传的媒体（通过设置MEDIA_ROOT ）。如果媒体资源在另外的一台服务器上，你需要获得通过网络写操作的权限。如果你的应用牵涉到文件上载，Django需要能够面向媒体服务器撰写上载媒体如果媒体是在另外一台服务器上的，你需要部署一种方法使得Django可以通过网络去写这些媒体。

实现负担均衡和数据冗余备份

现在，我们已经尽可能地进行了分解。这种三台服务器的构架可以承受很大的流量，比如每天1000万的点击率。

这是个好主意。请看图 20-3，一旦三个服务器中的任何一个发生了故障，你就得关闭整个站点。因此在引入冗余备份的时候，你并不只是增加了容量，同时也增加了可靠性。

我们首先来考虑Web服务器的点击量。把同一个Django的站点复制多份，在多台机器上同时运行很容易，我们也只需要同时运行多台机器上的Apache服务器。

你还需要另一个软件来帮助你在多台服务器之间均衡网络流量： 流量均衡器（load balancer） 。你可以购买昂贵的专有的硬件均衡器，当然也有一些高质量的开源的软件均衡器可供选择。

Apaches 的 mod_proxy 是一个可以考虑的选择，但另一个配置更棒的选择是： memcached是同一个团队的人写的一个负载均衡和反向代理的程序.(见第15章)

记录

如果你使用FastCGI，你同样可以分离前台的web服务器，并在多台其他机器上运行FastCGI服务器来实现相同的负载均衡的功能。前台的服务器就相当于是一个均衡器，而后台的FastCGI服务进程代替了Apache/mod_python/Django服务器。

现在我们拥有了服务器集群，我们的构架慢慢演化，越来越复杂，如图20-4。

图 20-4：负载均衡的服务器设置。

值得一提的是，在图中，Web服务器指的是一个集群，来表示许多数量的服务器。一旦你拥有了一个前台的均衡器，你就可以很方便地增加和删除后台的Web服务器，而且不会造成任何网站不可用的时间。

慢慢变大

下面的这些步骤都是上面最后一个的变体：

当你需要更好的数据库性能，你可能需要增加数据库的冗余服务器。 MySQL内置了备份功能；PostgreSQL应该看一下Slony (http://www.djangoproject.com/r/slony/) 和 pgpool (http://www.djangoproject.com/r/pgpool/) ，这两个分别是数据库备份和连接池的工具。