Django的部署与gunicorn和nginx的(Deploying Django with gu

2019-07-01 15:37发布

站内文章 / 前沿技术

41 0

女 | 书童

私信

这是一个广泛的问题，但我想获得一个典型的答案。我一直在尝试部署使用gunicorn和nginx的在Django的站点。阅读吨的教程后，我获得了成功，但我不能肯定我遵循的步骤是不够好，没有问题或可能有更好的方法来做到这一点运行一个网站。这种不确定性是烦人。

这就是为什么我在寻找新手非常详细的和很好的解释回答。我不想解释太多我所知道的，什么我不知道，因为这会歪曲回答了一下，其他人可以受益程度较轻，从你的答案。不过，我想看看提到的一些事情是：

什么“设置”你见过最好的工作？我用的virtualenv和感动我的Django项目这个环境中，但是我已经看到了另一个设置那里是虚拟环境的项目文件夹等。
如何的方式，允许多个网站我设置的东西在一个单一的服务器托管？
为什么有些人建议使用gunicorn_django -b 0.0.0.0:8000和其他一些人提出gunicorn_django -b 127.0.0.1:8000 ？我测试了后者的Amazon EC2实例，但而前者没有问题的工作也没有工作。
什么是Nginx的配置文件背后的逻辑是什么？有这么多的教程使用我很困惑在哪一个更好大大不同的配置文件。例如，有些人用alias /path/to/static/folder等root /path/to/static/folder 。也许你可以分享你的首选配置文件。
为什么我们之间创建符号链接site-available和sites-enabled中/etc/nginx ？
一些最佳实践一如既往欢迎:-)

谢谢

Answer 1:

什么“设置”你见过最好的工作？我用的virtualenv和感动我的Django项目这个环境中，但是我已经看到了另一个设置那里是虚拟环境的项目文件夹等。

的virtualenv是分离的Python环境的方式; 正因为如此，它并没有很大一部分在部署发挥-但是在开发和测试是必需的，如果没有强烈推荐。

你会从virtualenv中获取的价值在于，它可以让你以确保库中的正确版本安装该应用程序。所以没关系，你坚持的虚拟环境不受本身。只要确保你不把它作为源代码版本控制系统的一部分。

该文件系统布局并不重要。你会看到很多的文章歌颂目录布局，甚至可以克隆为起点骨架项目的美德。我觉得这更多的是个人的喜好不是硬性要求的。当然了不错的; 但除非你知道为什么 ，它没有任何价值添加到您的部署过程-是因为一些博客建议，除非是有意义的，您的情况不这样做。例如-无需创建一个setup.py文件，如果你没有一个专用的PyPI服务器是部署工作流程的一部分。

如何的方式，允许多个网站我设置的东西在一个单一的服务器托管？

有你需要做多个站点设置两件事情：

即在公共IP侦听端口80和/或443端口，如果您有SSL服务器。
一串“进程”正在运行的实际的django源代码。

人们使用了＃1 nginx的，因为它是一个非常快的代理，并没有配备像Apache的综合服务器的开销。您可以自由使用Apache，如果你是舒服。有没有要求，即“多个网站使用Nginx的”; 你只需要是在这个端口上监听的服务，知道如何重定向（代理）在运行实际的Django代码的过程。

＃2有几种方法可以启动这些进程。 GEVENT / uwsgi是最流行的。这里要记住的唯一的事情是不要在生产中使用的runserver。

这些都是绝对的最低要求。通常人们添加某种进程管理器来控制所有的“Django的服务器”（＃2）运行。在这里，你会看到upstart和supervisor提及。我喜欢上司，因为它并不需要接管整个系统（不像暴发户）。然而，再次-这不是一个硬性要求 。你可以完美运行了一堆screen会话和detatch他们。缺点是，你要重新启动服务器，你将不得不重新启动屏幕会话。

我个人建议：

Nginx的＃1
随你挑uwsgi和gunicorn之间 - 我用uwsgi。
主管管理后端进程。
个人账户系统（用户）为您主持的每个应用程序。

我之所以推荐＃4是隔离的权限; 再次，不作要求。

为什么有些人建议使用gunicorn_django -b 0.0.0.0:8000和其他一些人提出gunicorn_django -b 127.0.0.1:8000？我测试了后者的Amazon EC2实例，但而前者没有问题的工作也没有工作。

0.0.0.0表示“所有IP地址” -其元地址（即占位符地址）。 127.0.0.1是始终指向本地计算机的保留地址。这就是为什么它被称为“本地主机”。只有可达在同一系统上运行的进程。

通常你有监听的公共IP地址，前端服务器（＃1在上面的列表）。你应该明确地绑定服务器一个 IP地址 。

但是，如果由于某种原因，你是DHCP或者你不知道IP地址是什么（例如，其新设置的系统），你可以告诉nginx的/阿帕奇/任何其他进程绑定到0.0.0.0 。这应该是一个暂时的权宜之计 。

对于生产服务器，你就会有一个静态IP地址。如果你有一个动态IP（DHCP），那么您可以在离开0.0.0.0 。这是非常罕见的，你将有DHCP为您的生产机器虽然。

在生产中不建议结合gunicorn / uwsgi到这个地址。如果你的后端处理（gunicorn / uwsgi）绑定到0.0.0.0 ，就可能成为“直接”访问，绕过您的前端代理（nginx的/阿帕奇/等）; 有人可能只是请求http://your.public.ip.address:9000/直接尤其是访问你的应用程序，如果您的前端服务器（nginx的）和你的后端处理（Django的/ uwsgi / GEVENT）在同一运行机 。

如果你不希望有，虽然运行的前端代理服务器的麻烦，你可以自由地做到这一点。

什么是Nginx的配置文件背后的逻辑是什么？有这么多的教程使用我很困惑在哪一个更好大大不同的配置文件。例如，一些人使用“的别名/路径/到/静态/文件夹”等“根/路径/到/静态/文件夹”。也许你可以分享你的首选配置文件。

你应该知道nginx的第一件事是，它不是像Apache或IIS Web服务器 。这是一个代理。所以，你会看到像被定义“上游” /“下游”和多个“服务器”不同的术语。花一些时间和经历nginx的手动头。

有很多不同的方式来设置Nginx的; 但这里是一个回答你的问题alias与root 。 root是结合Nginx的文档根目录（以下简称“主目录”），明确指示。这是该目录将看看当你给不喜欢通路请求http://www.example.com/

alias是指“一个名称映射到一个目录”。别名目录可能不是文档根目录的子目录。

为什么我们建立网站和提供在/ etc / nginx的站点启用-之间的符号链接？

这是唯一的东西给Debian（和Debian-like系统如Ubuntu）。 sites-available列表配置文件系统上的所有虚拟主机/网站。从符号链接sites-enabled到sites-available “激活”该网站或虚拟主机。这是单独的配置文件，方便地启用/禁用主机的方式。

Answer 2:

我不是一个部署大师，但会分享我的一些做法与GEVENT部署Django的（应该是类似于但gunicorn）。

virtualenv是伟大的原因，我不会进入。然而，我发现virtualenv-wrapper （文档）是非常有用的，尤其是当你在许多项目上工作，因为它允许不同virtualenvs之间轻松切换。这并不真正适用于部署环境然而，当我确实需要使用SSH服务器上的解决，我发现这是非常有用的。使用它的另一个优点是，它管理的virtualenv目录，你这么少的体力劳动。 Virtualenvs意味着是一次性的，这样如果你有版本问题，或任何其他的安装问题，你可以转储env和创建一个新的。其结果是，它不包括任何的virtualenv中的项目代码的最佳实践。应该保持独立。

至于设立多个站点， virtualenv是相当多的答案。你应该为每个项目单独virutalenv。只是，仅仅可以解决很多问题。然后，当你部署一个不同的Python程序将运行避免了部署之间的任何可能的冲突不同的网站。一个工具，我特别发现，在同一台服务器上管理多个网站是非常有益的supervisor （文档）。它提供了启动，停止和重新启动不同Django的情况下一个简单的界面。它也能够自动重新启动的过程，当它出现故障或计算机启动时，向上的。因此，举例来说，如果一些异常引发并没有什么捕获它，整个网站可以下去。监会赶上并会自动重启Django的实例。以下是一个示例主管程序（一个单一的过程）的配置：

[program:foo]
command=/path/toviertualenv/bin/python deploy.py
directory=/path/where/deploy.py/is/located/
autostart=true
autorestart=true
redirect_stderr=True
user=www

对于Nginx的，我知道它可以在第一次是压倒性的。我发现Nginx的书是非常有用的。它解释了所有主要nginx的指令。

在我的nginx的安装，我找到了最好的做法是只设置在核心CONFIGS nginx.conf文件，然后我有一个单独的文件夹sites ，我保持nginx的CONFIGS每个网站我的主机。然后，我只是包括在核心配置文件文件夹中的所有文件。我用的指令include sites/+*.conf; 。这样，它不仅包括启动与文件+的内标志sites文件夹。这样，仅仅通过文件名，我可以控制哪些配置文件得到加载。所以，如果我想禁用某个网站，我只是要重命名的配置文件并重新启动nginx的。真不知道你是什么意思“之间的符号链接的网站，提供和网站使用，在/ etc / nginx的”在你的问题，因为这些是Apache的命名的文件夹，但他们完成类似任务为include指令。

至于root和alias指令，他们几乎除非他们的根计算的相同。在alias ，无论在location在下降，而在根中它没有。您有以下nginx的配置图片：

location /static {
    alias /some/path/;
}
location /static2 {
    root /some/other/path/;
}

如果用户去这些URL，然后nginx的将尝试寻找在系统上的以下地方的文件：

/static/hello/world.pdf => /some/path/hello/world.pdf
/static2/hello/world.pdf => /some/other/path/static2/hello/world.pdf

这是nginx的网站简单的配置：

server {
    server_name .foodomain.com;
    listen 80;

    access_log logs/foodomain.log;

    gzip                on;
    gzip_http_version   1.0;
    gzip_comp_level     2;
    gzip_proxied        any;
    gzip_min_length     1100;
    gzip_buffers        16 8k;
    gzip_types          text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Some version of IE 6 don't handle compression well on some mime-types, so just disable for them
    gzip_disable "MSIE [1-6].(?!.*SV1)";

    # Set a vary header so downstream proxies don't send cached gzipped content to IE6
    gzip_vary on;

    location / {
        proxy_read_timeout      30s;
        proxy_pass              http://localhost:8000;
        proxy_set_header        Host                 $host;
        proxy_set_header        User-Agent           $http_user_agent;
        proxy_set_header        X-Real-IP            $remote_addr;
    }

    location /media {
        alias   /path/to/media/;
        expires 1y;
    }

    location /static {
        autoindex on;
        expires   1y;
        alias     /path/to/static/;
    }

     location /favicon.ico {
        alias /path/to/favicon.ico;
    }
}

希望这有助于你一点。

Answer 3:

好了，就最佳实践都在关注你问你的问题，我不禁共享工具，创造了奇迹对我来说，从字面上！我自己用眼花缭乱的gunicorn，nginx的，supervisorD的几个配置文件的几个地点！但我渴望以某种方式自动执行的全过程，这样我可以更改我的应用程序/网站，并立即部署它。它的名字是Django的fagungis。你可以找到我的经历细节的Django部署自动化这里。我只是配置了fabfile.py一次（Django的fagungis使用织物自动化的全过程，使一个的virtualenv中是非常方便的管理托管在单个服务器上几个网站的依赖远程服务器，它使用nginx的，gunicorn和supervisorD处理Django项目/站点部署），并从到位桶Django的fagungis克隆我的最新项目（我使用subversioning）并部署它在我的远程服务器上，我只是在我的本地机器的外壳，它进入三个命令！对我来说，这已经被证明是对的Django部署的最佳，无忧无虑的做法。