CloudFoundry:nginx用于在Gunicorn（Docker）之上提供静态内容

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

将nginx设置为服务静态内容的反向代理的正确方法是什么？我想静态文件构建包不是一个好办法

---

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

如果你使用Cloud Foundry，你可以非常轻松地启动一两个额外的实例来扩展你的应用程序并处理更多的负载。我建议这样做，因为它非常简单，应该适用于任何类型的应用程序。然后看看客户端缓存。只需在客户端缓存文件，就可以减少服务器上静态文件请求产生的负载

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

1.）使用Python构建包推送Flask应用程序。这将为您的应用程序提供主要路径

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

通过这样做，您可以将任何请求路由到

static.example.com

路由或

www.example.com/static

路由和路径，以访问由Nginx托管的静态文件（由静态文件构建包提供）。对主路径的请求或对静态路径的请求，最终都会转到Python应用程序。平台会处理此问题，并根据您为每个应用程序定义的路由，确保路由转到正确的应用程序

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

---

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

为什么要这样做？您是否发现当前设置存在问题？如果是这样的话，问题是什么？Gunicorn文档（）中建议使用它，如果我没有弄错的话，nginx更适合并优化用于提供静态内容。我的问题是您需要它吗？添加Nginx将使事情变得更加复杂。如果你有一个流量小的应用程序，老实说，你只是在浪费时间添加Nginx。如果你需要扩大应用程序的规模，运行它，并启动应用程序的第二个或第三个实例。如果您发现您需要更有效地交付静态文件，比如如果您的大部分时间都花在提供静态文件上，您可以查看我在下面的答案中发布的内容。