NGINX Unit是一个完全动态的应用服务器,可以提供多种语言以及每种语言的多个版本。 它是动态的,因为您使用 RESTful JSON API 来更改内存中的配置,而无需服务中断或配置重新加载。
在 10 月份的NGINX Conf 2018演讲中,我展示了如何在现有生产环境中配置新应用。 具体来说,在 PHP 上运行 WordPress 的情况下,我部署了一个使用 Django 框架的 Python应用。 我还展示了如何从文件加载配置以及按照 API 调用的参数指定的方式加载配置。
本博客包含了我在演示中使用的所有命令和配置代码,以方便您适应自己的部署。
为了 NGINX Conf 上的演示,我安装了以下软件:
root
权限,或通过sudo
进行同等访问(必要时我们会使用)我还安装了 PHP 和 WordPress 作为现有应用。
切换到我们创建 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
默认情况下,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 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
在此命令中:
PUT
方法在最后一个参数(URL)指定的位置创建一个新的 NGINX Unit 配置对象。 请参阅下面的最后要点。--data-binary
参数告诉curl
完全按照提供的内容加载django.config的内容,保留换行符和回车符,并且不进行任何类型的处理。--unix-socket
参数定义 NGINX Unit API 正在监听的位置。 (我们使用sudo
命令是因为我们使用套接字的默认所有者root
。)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 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”