NGINX 会议 2018：为生产applications配置 NGINX 单元 - 为 Django 项目提供服务

阿曼达·博科文

2018 年 11 月 28 日发布

NGINX Unit是一个完全动态的应用服务器，可以提供多种语言以及每种语言的多个版本。它是动态的，因为您使用 RESTful JSON API 来更改内存中的配置，而无需服务中断或配置重新加载。

在 10 月份的NGINX Conf 2018演讲中，我展示了如何在现有生产环境中配置新应用。具体来说，在 PHP 上运行 WordPress 的情况下，我部署了一个使用 Django 框架的 Python应用。我还展示了如何从文件加载配置以及按照 API 调用的参数指定的方式加载配置。

本博客包含了我在演示中使用的所有命令和配置代码，以方便您适应自己的部署。

先决条件

为了 NGINX Conf 上的演示，我安装了以下软件：

Ubuntu 16.04
NGINX Plus，但除非另有说明，您可以使用 NGINX 开源
安装了所有语言模块的 NGINX Unit
Python 3
Django （未配置 - 这是演示和本博客所讨论的内容）
root权限，或通过sudo进行同等访问（必要时我们会使用）

我还安装了 PHP 和 WordPress 作为现有应用。

创建 Django 项目

切换到我们创建 Django 项目的目录：
```
$ cd /var/www/
```
使用django-admin startproject命令初始化新项目。我们称之为djapp 。
```
$ sudo django-admin startproject djapp
```
进入项目目录：
```
$ cd djapp
```
使用manage.py脚本为项目迁移数据库，这对于新创建的项目是必需的。 Django 默认使用 SQLite，我在演示中接受默认值，但您可以使用任何满足您项目需求的数据库。

manage.py脚本由我们在步骤 2 中运行的django-admin命令安装；它执行与django-admin相同的命令并接受相同的参数，但自动派生并使用一些项目特定的设置，这很有帮助。有关详细信息，请参阅Django 文档。
```
$ sudo python3 manage.py 迁移
```
虽然对于像这样的示例项目来说这不是严格必要的，但我们建议您创建 Django超级用户身份：
```
$ sudo python3 manage.py 创建超级用户
```
切换到包含settings.py文件的子目录，该文件是由步骤 2 中的django-admin startproject命令创建的。
```
$ cd /var/www/djapp/djapp
```
使用您喜欢的文本编辑器打开settings.py 。这里我们使用nano ：
```
$ sudo nano 设置.py
```
找到ALLOWED_HOSTS行并添加应用的域名、主机名或 IP 地址：
```
ALLOWED_HOSTS = ['域名']
```
还要在文件末尾添加以下行，以命名存储应用提供的所有静态内容的目录（参见步骤 9）。
```
STATIC_ROOT = '/var/www/djapp/djapp/static'
```
改回主项目目录（ manage.py所在的目录）。
```
$ CD..
```
运行manage.py collectstatic命令收集位于 Django 项目中的所有静态文件并将其放入步骤 7 中定义的STATIC_ROOT位置。
```
$ sudo python3 manage.py collectstatic
```

配置 NGINX

默认情况下，Django 本身为项目提供静态内容，但 NGINX Open Source 和 NGINX Plus 提供了更出色的性能。这里我们配置了 NGINX Plus，但是除了下面提到的一项功能之外，您可以使用 NGINX 开源。

将目录更改为/etc/nginx/conf.d ，这是特定于功能（或在我们的例子中是特定于应用）的 HTTP 配置文件的常规位置：
```
$ cd /etc/nginx/conf.d
```

创建一个名为django.conf的文件（再次，我们使用nano ）：

$ sudo nano django.conf

插入以下配置，启用缓存。

该配置还包括 NGINX Plus 独有的两个功能。如果您正在使用 NGINX Plus 并且想要利用以下功能，请取消注释相关指令：

扩展指标收集，由status_zone指令为此虚拟服务器启用。我假设NGINX Plus API已在配置的其他地方启用。
主动健康检查，由health_check指令启用。

需要注意的一点是，在 NGINX Conf 的演示中，我将本地机器的 IP 地址指定为proxy_set_header指令的第二个参数。在生产环境中，使用$host变量更有意义，如下所示。

# 后端的上游组（运行 Python应用的NGINX 单元）
上游 django_unit {
区域 django_unit 64k；
服务器 127.0.0.1:8000；
}

服务器 {
听 8080；
# 如果使用 NGINX Plus 和 NGINX Plus API，则取消注释以收集指标
#状态区域 django；

# 启用缓存
代理缓存django_cache；
代理缓存有效 200 60米；

# 静态文件的根目录
根目录/var/www/djapp/djapp；

# 代理到 NGINX Unit 后端
地点 / {
代理密码<a href="http://django_unit;">http://django_unit;</a>

# 第二个参数必须匹配你的生产主机名和
#settings.py 中的 ALLOWED_HOSTS
proxy_set_header 主机 $host;

# 如果使用 NGINX Plus，则取消注释以启用主动健康检查
#健康检查；
}

# 从 Django 收集并由其提供的静态文件的位置
# NGINX Plus; 可以为空（如这里），因为它继承了
# 来自其父块的“root”指令
位置/静态{
}
}

检查配置的语法有效性：
```
$ sudo nginx –t
```
修复所有错误后，重新加载配置：
```
$ sudo nginx -s 重新加载
```

配置 NGINX 单元

最后，我们需要配置 NGINX Unit 来为应用提供请求。

运行此curl命令以显示当前 NGINX Unit 配置，该配置适用于在 PHP 上运行的 WordPress。我没有在这里显示输出，但是 WordPress 配置出现在下面的第 6 步中，以及我们即将添加的 Python 应用程序的配置。
请注意，我对curl命令使用了sudo ，但对于大多数curl命令，可能不需要这样做。这是必要的，因为要访问 UNIX 套接字，我们需要root对其具有的读写权限。
```
$ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/
```
更改为 NGINX Unit 配置文件的目录。

请记住，这些文件是可选的，只是一种加载配置集合的便捷方式，无需将所有数据作为参数键入对 NGINX Unit API 的调用。由于文件内容是通过 API 上传的（就像所有配置数据一样），因此 NGINX Unit 不知道文件位置，也无法在启动时自动读取文件（与 NGINX Open Source 和 NGINX Plus 不同）。相反，NGINX Unit 将其运行时状态保存在单独的目录中。
```
$ cd /etc/unit
```

创建一个名为django.config的文件（再次，我们使用nano ）：

$ sudo nano django.config

添加以下 JSON，它代表我们的 Python应用。

{
“类型”：“python”，
“进程”： 5、
      “模块”：“djapp.wsgi”，
      “路径”：“/var/www/djapp”
}

运行此curl命令将django.config中包含的 JSON 加载为由 NGINX Unit 管理的新应用对象，名为djapp ：
```
$ sudo curl -X PUT --data-binary @/etc/unit/django.config --unix-socket /run/control.unit.sock http://localhost/config/ 应用/djapp
```
在此命令中：
- HTTP PUT方法在最后一个参数（URL）指定的位置创建一个新的 NGINX Unit 配置对象。请参阅下面的最后要点。
- --data-binary参数告诉curl完全按照提供的内容加载django.config的内容，保留换行符和回车符，并且不进行任何类型的处理。
- --unix-socket参数定义 NGINX Unit API 正在监听的位置。（我们使用sudo命令是因为我们使用套接字的默认所有者root 。）
- 最后一个参数定位并命名新的应用对象，以使用django.config中的 JSON 格式的配置数据进行填充： config是顶级 NGINX Unit 配置对象， 应用应用对象的父级， djapp 是新应用对象的名称。
为应用定义监听器对象。我们不需要像步骤 4 中那样加载配置数据文件，而是直接在curl命令行上定义数据，指定djapp应用监听端口 8000。
```
$ sudo curl -X PUT --data-binary '{"应用":" djapp "}' --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/*:8000'
```

重复步骤 1 中的curl命令以显示 NGINX Unit 配置，该配置现在包括我们的 Python应用djapp （以橙色突出显示）：

$ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/ { “监听器”: { “127.0.0.1:8090”: { “应用”: “script_index_php” }, “127.0.0.1:8091”: { “应用”: “direct_php” }, “*:8000”: { “应用”: “djapp” } }, “应用”: { “script_index_php”: { “type”: “php”, “进程”: { “max”: 20、“备用”： 5 }, “用户”：“www-data”， “组”：“www-data”， “根”：“/var/www/wordpress”， “脚本”：“index.php” }, “direct_php”：{ “类型”：“php”， “进程”：{ “最大”： 5、“备用”： 0 }, “用户”：“www-data”， “组”：“www-data”， “根”：“/ var / www / wordpress”， “索引”：“index.php” }, “djapp”：{ “类型”：“python”， “进程”： 5、“模块”：“djapp.wsgi”，“路径”：“/var/www/djapp” } } }

概括

在这篇文章中，我们开始使用 NGINX Unit 在生产中为 WordPress 运行 PHP应用，并添加了一个 Python应用。在演示中，我使用 NGINX Plus 仪表板来显示添加新应用时不会对现有应用造成中断，但您可以使用任何系统监控工具（例如ps命令）来实现此目的。 NGINX Unit 配置的动态特性为您正在运行的应用节省资源，并确保新部署的零停机时间和应用版本之间的平稳过渡。

要了解更多信息，请访问unit.nginx.org 。

阅读有关 F5 NGINX 的更多博客文章 ›

“这篇博文可能引用了不再可用和/或不再支持的产品。有关 F5 NGINX 产品和解决方案的最新信息，请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”

NGINX 会议 2018： 为生产applications配置 NGINX 单元 - 为 Django 项目提供服务

先决条件

配置 NGINX

配置 NGINX 单元

概括

交付并保障每一款应用

联系

NGINX 会议 2018：为生产applications配置 NGINX 单元 - 为 Django 项目提供服务