我正在设置Flask / uswgi网络服务器。我仍然对微服务架构感到疑惑：
我应该将带有uwsgi的nginx和Flask放在一个容器中，还是将它们放在两个不同的容器中并链接起来？
我打算在Kubernetes集群中运行这些服务。
由于
答案 0 :(得分：4)
简答：
我会将nginx和uwsgi / flask应用程序部署为单独的容器。这为您提供了一种更灵活的体系结构，允许您将更多微服务容器链接到nginx实例，因为您对更多服务的需求也在增长。
<强>解释
使用docker，通常的策略是将nginx服务和uwsgi / flask服务拆分为两个独立的容器。然后，您可以使用链接链接它们。这是docker世界中常见的架构哲学。像docker-compose这样的工具简化了运行多个容器和在它们之间形成链接的管理。以下docker-compose配置文件显示了以下示例：
version: '2'
services:
app:
image: flask_app:latest
volumes:
- /etc/app.cfg:/etc/app.cfg:ro
expose:
- "8090"
http_proxy:
image: "nginx:stable"
expose:
- "80"
ports:
- "80:8090"
volumes:
- /etc/app_nginx/conf.d/:/etc/nginx/conf.d/:ro
这意味着如果要添加更多应用程序容器，可以通过链接将它们轻松地附加到同一个ngnix代理。此外，如果您想升级基础架构的一部分，比如升级nginx，或者从apache转移到nginx，那么您只需重新构建相关容器，并将所有其余容器留在该位置。
如果要将两个服务添加到单个容器中（例如，通过从Dockerfile ENTRYPOINT启动supervisord进程），这将允许您更容易选择使用socks文件在nginx和uwsgi进程之间进行通信，而不是知识产权，但我不认为这是一个足够强大的理由将两者放在同一个容器中。
另外，考虑一下最终你是否最终运行了20个微服务并且每个都运行着自己的nginx实例，这意味着你现在有20套nginx（access.log / error.log）日志来跟踪20个容器。
如果您正在使用＆＃34;微服务＆＃34;体系结构，这意味着随着时间的推移，您将添加越来越多的容器。在这样的生态系统中，将nginx作为单独的docker进程运行并将微服务链接到它，可以更容易地根据您不断扩展的需求进行扩展。
此外，某些任务只需要完成一次。例如，如果nginx服务在其自己的容器上运行，则可以在nginx容器中完成SSL终止，并使用适当的SSL证书配置一次，而不管有多少微服务连接到它。
关于服务发现的说明
如果容器在同一主机中运行，则链接所有容器很容易。如果容器在多个主机上运行，使用Kubernetes或Docker swarm，那么事情可能会变得有点复杂，因为您（或您的集群框架）需要能够将您的DNS地址链接到您的nginx实例和docker容器需要能够找到＆＃39;彼此 - 这增加了一点概念开销。 Kubernetes通过将容器分组到pod，定义服务等来帮助您实现这一目标。
答案 1 :(得分：1)
Docker的理念是在容器中使用微服务。在过去几年中，术语“Microservice Architecture”如雨后春笋般涌现，以描述将软件应用程序设计为independently deployable services套件的特定方式。
据说，您可以将uwcgi部署在单独的容器中，并从microservices architecture中受益。
microservices architecture的一些优点是：
答案 2 :(得分：1)
如果您在Flask / uwsgi服务器前使用Nginx，那么您将使用Nginx作为代理：它负责将流量转发到服务器，最终负责TLS加密，也许是身份验证等...
使用像Nginx这样的代理的目的是能够对服务器进行负载均衡：Nginx代理接收请求，并在多个服务器之间分配负载。
这意味着您需要一个Nginx实例，以及Flask / usqgi服务器的一个或多个实例作为＆＃39;上游＆＃39;服务器
要实现这一点，唯一的方法是使用单独的容器。
请注意，如果您使用的是AWS或GKE等云提供商，它可以为您的Kubernetes群集提供负载均衡器，并且您只是使用Nginx来转发流量（即不是使用它进行TLS或auth）那么您可能甚至不需要Nginx代理，但可以使用为您执行代理的服务。添加Nginx只会让您获得更多控制权。