在 Ubuntu 上使用 nginx 通过 FastCGI 运行 Python答案

【问题标题】：Running Python through FastCGI with nginx on Ubuntu在 Ubuntu 上使用 nginx 通过 FastCGI 运行 Python
【发布时间】：2013-04-05 17:58:12
【问题描述】：

我已经查看了关于此的其他线程，但大多数都没有深入了解我需要帮助的设置细节。

我有一个基于 Ubuntu 的 VPS，运行 nginx，通过端口 9000 上的 php-cgi 为 PHP 站点提供服务。

我想开始更多地使用 Python，所以我编写了一个部署脚本，我基本上想将它用作我本地 GitLab 服务器上的接收后挂钩，作为我的第一个 Python 脚本。我可以通过在命令行上运行python script.py 来成功运行此脚本，但为了将其用作接收后挂钩，我需要它能够通过 http 访问它。

我在 nginx wiki 上查看了 this guide，但中途说：

并启动django fastcgi进程：

python ./manage.py runfcgi host=127.0.0.1 port=8080

现在，就像我说的，我对 python 很陌生，而且我从未使用过 Django 框架。任何人都可以帮助我应该如何启动 fastcgi 服务器吗？我是否将./manage.py 替换为我的脚本名称？任何帮助都会得到帮助，因为我在网上找到的所有内容都涉及使用 Django。

【问题讨论】：

@Vitaliy 如果问题是如何通过 HTTP 公开此代码，那可能怎么可能相关？
@Vitaliy 我不明白这有什么关系？它甚至不使用数据库。
您应该阅读stackoverflow.com/questions/11216658/… 答案中链接到的文章； tldr- cgi 不推荐用于 Python 开发，WSGI 是现代协议。
@JonathanVanasco 在有 Apache/nginx 的设置中，WSGI 不是主要用作 paster 和 gunicorn 等应用服务器之间的抽象接口吗反向代理一堆工作进程？在“真正的”网络服务器中直接支持它并不是真正的事情。如果 OP 已经有一个他知道启用并配置了 FastCGI 的 nginx 服务器，那么使用它并没有什么问题。（似乎 WSGI 模块在 nginx 中不是标准的，所以它可能在他们的构建中不可用，the documentation for it 看起来很吓人。）
WSGI 被用作这样的抽象接口，但它也推动了诸如 Flask、Paste、web.py 等之类的设计原则。nginx 通过 uwsgi 服务器提供 wsgi 支持。留在 CGI 中没有任何问题 - 它只是一种旧的和过时的 Web 脚本方法。如果您正在学习如何将 python 用于网络内容，那么学习当前技术比人们不真正使用的旧技术更有意义。此外，您还可以获得中间件、本地测试服务器（通过任何框架）的好处，并且不必使用 cgi 模块。

标签： python http nginx installation

【解决方案1】：

我是否将 ./manage.py 替换为我的脚本名称？

没有。您的脚本极不可能是 FastCGI 服务器，或者它可以接受任何类型的 HTTP 请求，因为您提到通过命令行运行它。（根据我对 FastCGI 的了解，支持它的应用程序必须能够处理通过标准输入以特定格式传入的请求流，因此肯定会涉及一些管道。）

我想说最简单的方法是使用 some web 框架来充当 HTTP/FastCGI 中间件。供您使用像Flask（甚至Paste，但我发现文档难以理解）之类的“微框架”听起来可以正常工作。这个想法是为您的主代码提供两个接口，一个可以处理命令行参数，一个可以处理 HTTP 请求，最终两者都只会调用一个实际完成工作的函数。（如果您想保留应用程序的命令行版本。）

Flask 文档还提到 using uWSGI 或 standalone workers 作为部署选项。我不熟悉前者； ~~出于与下一段中的方法相同的原因，我不建议将后者用于简单、低流量的应用程序。~~

考虑到您使用 VPS，您甚至可以使用 the http.server module 将应用程序作为独立服务器进程运行，但我不确定这是更好的选择，除非您绝对想避免使用任何一种框架。您必须确保应用程序在服务器重新启动时启动，或者在它崩溃时重新启动，并且让 nginx 完成主管的工作似乎更容易。

更新： 从头开始，似乎 nginx 不会为您处理监督 FastCGI 工作进程，这本来是该方法的主要优点。鉴于此，您使用三种方法中的哪一种并不重要，因为您必须以一种或另一种方式设置服务主管。我会说使用 uWSGI，因为 flup（Flask+FastCGI 需要它）似乎自 2011 年以来就被废弃了，而 uWSGI nginx 本身显然支持 协议。否则，您需要使用与 nginx 不同的网络服务器，它会为您管理 FastCGI 工作器。如果这是一个选项，我会考虑 Cherokee，它可以使用 Web GUI 进行配置。

tl;dr: 你需要编写一个（非常简单的）webapp。虽然在没有任何类型的 Web 框架的情况下执行此操作是可行的，但在我看来，使用一个更容易，因为您可以免费进行一些（非平凡的）管道，并且有很多关于如何部署它们的指导。

【讨论】：

webpy.org 是一个更小的框架；重申我对这个问题的评论：当涉及到 Python Web 开发时，CGI 已被弃用，而 WSGI 是当前推荐的方法。
@JonathanVanasco 如果您能提供有关如何将 nginx 与 WSGI 应用程序连接起来的答案，那就更好了。我严重怀疑它只是一个替代品，因为 WSGI 需要切换到代理+工作者架构，或者向 nginx 添加第三方模块。我认为 FastCGI 非常适合 OP 范围内的应用程序，并且代理+工作者的好处在这里不适用。为了避免 CGI，您实际上是在派 OP 进行一些牦牛剃须。
@JonathanVanasco 至于它的价值，我看不出 FastCGI 和 WSGI 是如何相互排斥的技术。 FastCGI 是一种“在线”协议，它允许将“工作”Python 进程重用于多个 HTTP 请求。 WSGI 是在 Python 端表示这些 HTTP 请求的抽象方式。如果我正确理解链接到的文档，flup 所做的只是解析 FCGI 请求并将它们转换为任何 Python 框架都能理解的 WSGI 调用。所以选择不是 FCGI 与 WSGI，而是 FCGI 与独立 HTTP 工作者与将 Python 嵌入前端服务器。
@JonathanVanasco 实际上，您链接到的 SO 问题也说了同样的话。还有一堆其他问题的链接，也说比较两者是没有意义的。它们在架构中的用途完全不同。
正是我所追求的，谢谢大家。我现在看看安装 uWSGI，我只从 Fast CGI 开始，因为这就是我用于 PHP 的。如果有任何可用的解决方案，我总是会提供更好的解决方案。