我已经完成了我的第一个Django / Python项目，现在我需要将这些东西放在真正的生产网络服务器中。
我通过互联网阅读了一些论文，我倾向于选择Ngix，Gunicorn和Git，但我发现的文档不是很完整，如果这是最佳选择，我有很多doubs。
您如何看待这个主题？我需要一种简单的方法来使我的Django项目联机，但网站仍然非常错误，我将需要在生产服务器中多次更改代码。
请告诉我一些关于我应该做些什么的线索。我有点失落......
最诚挚的问候，
答案 0 :(得分：17)
这是一个很好的blog entry，涵盖了使用Nginx和Gunicorn部署Django。我将简要介绍一下使所有不同技术变得重要的原因：
当然不需要Git或任何其他版本控制系统。为什么它适合部署Django项目是因为您通常按来源分发您的应用程序，即您不编译它或将其打包为鸡蛋。通常你会组织你的Git存储库，因为在服务器上更新你的应用程序只需要你检查最新的资源 - 没有别的。
这也不是一个严格的要求，但我强烈建议你花点时间熟悉virtualenv和pip，如果你还没有这样做，因为它会让你的Python应用程序部署到不同的运行时环境，本地或远程，轻而易举。
基本上，你的项目至少需要在Python路径上提供Django和Gunicorn，甚至可能是数据库驱动程序。这意味着，每当您尝试在某个地方部署应用程序时，您都必须安装Python并进行easy_install舞蹈。
virtualenv将重新分发Python安装，这反过来意味着默认情况下，新的Python实例将拥有相对于安装的自己的Python路径配置。 pip与类固醇上的easy_install类似，因为它支持直接从代码库中检出Python依赖项，并支持需求文件格式，您可以使用它来一次性安装和配置所有依赖项。
使用virtualenv和pip，您需要做的就是拥有一个简单的文本文件，其中包含可以使用pip解析的所有依赖项以及在计算机上安装的Python发行版。从那里你只需git checkout repo /app/path; easy_install virtualenv; virtualenv /app/path; ./app/path/scripts/activate; pip install -r /app/path/requirements.txt。然后安装并立即提供Voila，Gunicorn，Django和所有其他依赖项。当您使用/app/path/scripts中的Python实例运行Gunicorn Django脚本时，脚本将立即访问Gunicorn源，并且它将能够找到您的Django项目，该项目还可以访问Django和其他依赖项。
Web服务器主要用于服务器静态媒体。其他所有内容都代理到管理Django实例的Gunicorn实例，因为它的主要目的是托管Python WSGI应用程序而不是充当通用Web服务器，相反，您的Web服务器不需要能够处理Python应用程序
为什么经常使用Nginx是它的轻量级，非常适合提供静态媒体和代理请求。与Apache相比，它的功能更少，这使得配置和维护变得更加容易，最重要的是，如果你已经紧张，它会更有效地提供资源。
这是实际的Python应用程序，它将管理您的Django实例并提供将其公开给HTTP客户端的HTTP接口。它将启动几个工作进程，这些进程将是加载了应用程序源和它的依赖项的不同Python虚拟机。主要的Gunicorn流程将负责管理哪些工作流程管理哪些请求获得最大吞吐量。
最值得注意的是，Nginx和Gunicorn是您独立管理的独立流程。
Nginx Web服务器将公开发布，即可以通过互联网直接访问。对于静态媒体的请求，例如实际图像，CSS样式表，JavaScript源和通过文件系统可访问的PDF文件，Nginx将负责将它们在响应主体中返回给HTTP客户端，如果您将其配置为在路径中查找文件您已将项目配置为收集静态媒体。
任何其他请求都应该代理您的Gunicorn实例。它将被配置为侦听环回接口上某个端口上的HTTP请求，因此您将使用Nginx作为http://127.0.0.1:8080的反向代理来处理对Django实例的请求。
这是将Django项目部署到生产环境中的基本纲要，应该满足95％Django项目的需求。虽然我确实引用了Nginx和Gunicorn，但在设置任何Web服务器作为Python WSGI服务器的反向代理时，这是常用的方法。
答案 1 :(得分：1)
出于“简单”的目的，我使用Apache和mod_wsgi：它是well-documented并且“只是工作”。
使用Apache和mod_wsgi部署Django是一种经过验证的方法，可以让Django投入生产。 - Django docs