CloudFoundry：用于在 Gunicorn (Docker) 之上提供静态内容的 nginx答案

【问题标题】：CloudFoundry: nginx for serving static content on top of Gunicorn (Docker)CloudFoundry：用于在 Gunicorn (Docker) 之上提供静态内容的 nginx
【发布时间】：2019-01-29 02:55:18
【问题描述】：

我目前在 Docker 容器中运行 Gunicorn 服务器，为 Flask 应用程序和静态内容提供服务（在 Swisscom CloudFoundry 上）。

将 nginx 设置为提供静态内容的反向代理的正确方法是什么？我假设 Staticfile buildpack 不是要走的路吗？

有人能指出我正确的方向吗？

【问题讨论】：

为什么要这样做？您是否发现当前设置存在问题？如果有，有什么问题？
建议在 Gunicorn 文档 (docs.gunicorn.org/en/stable/deploy.html) 中使用，如果我没记错的话，nginx 更适合和优化服务静态内容。
我的问题是你需要那个吗？添加 Nginx 会使事情变得更加复杂。如果你有一个流量很小的小应用程序，老实说，你只是在浪费时间添加 Nginx。如果您需要扩展，请在不使用它的情况下运行它并启动您的应用程序的第二个或第三个实例。如果您发现自己确实需要更有效地交付静态文件，例如，如果您的大部分时间都花在提供静态文件上，您可以查看我在下面的答案中发布的内容。

标签： docker nginx cloud-foundry swisscomdev

【解决方案1】：

如果您使用的是 Cloud Foundry，那么启动一个或两个额外的实例来扩展您的应用程序并处理更多负载非常容易。我建议这样做，因为它非常简单，并且应该适用于任何应用程序类型。那并查看客户端缓存。您可以通过简单地在客户端缓存文件来减少对静态文件的请求所产生的服务器负载。

如果您确实要提供大量静态文件，并且扩展应用的其他实例并不划算，您可以执行以下操作：

1.) 使用 Python buildpack 推送您的 Flask 应用程序。这将为您的应用提供主要路线。

2.) 使用静态文件构建包使用单独的主机名或上下文路径推送您的应用程序文件。例如：static.example.com 或 www.example.com/static。

通过这样做，您将把任何请求路由到 static.example.com 路由或 www.example.com/static 路由和由 Nginx 托管的静态文件的路径（由静态文件 buildpack 提供）。对主路由的请求或对静态路径的请求，最终都会转到您的 Python 应用程序。平台会处理此问题，并确保根据您为每个应用定义的路由将路由转到正确的应用。

唯一的缺点是这依赖于您将静态内容分离出来，以便您可以为静态内容映射自定义路由或自定义路由和路径。也就是说，我认为这不应该是一个问题，因为您正在运行 Flask。如果这是一个问题，您始终可以映射多条路线 + 路径。根据您的文件的结构，这可能需要映射大量路由 + 路径。

正如我上面提到的，这具有依赖平台将静态请求路由到一个应用程序并将所有其他请求路由到另一个应用程序的优势。如果您尝试将 Nginx 设置为代理，您会为您的请求添加更多的代理层和更多的延迟。

【讨论】：