我目前正在修改使用CoreOS的方案。它可能不是第一类用例。但是我想得到一个指针，如果它是有效的。由于我真的刚刚开始掌握CoreOS，我希望我的“用例”不会完全关闭。
想象一个多租户应用程序，每个租户都应该拥有自己的运行时环境。让我们在Node.js和PostgreSQL上运行一个Web应用程序，用于存储数据。每个租户环境将在各自的容器中运行在CoreOS上。数据持久性暂时被排除在外。对我而言，目前更多的是关于一般可行性。
为什么选择CoreOS？
目前，我试图坚持每个租户分离环境的想法。为了优化每个硬件主机的数据库和Web服务器实例的密度，我认为CoreOS可能是正确的选择而不是“经典”虚拟化。
另一个原因是许多租户可能不需要多于一个小型数据库实例和一个小型Web服务器。但可能还有其他租户需要一些不断扩展的部署。其他人可能需要在爆发期间临时扩展。 CoreOS听起来也很合适。
另一方面，后面必须有一个可扩展的消息传递基础架构（RabbitMQ）来处理大量消息。所有租户都将使用此基础架构，并且最多需要动态扩展。可能还会有一个“缩放”的Elasticsearch基础设施。通过我目前的“CoreOS for everything goggles”来看，这似乎也很合适。
如果整个场景通常有效，我目前无法看到如何将一般可用网站的流量路由到不同的租户容器。
想象一下该应用程序正在app.greatthing.tld上运行。用户可以登录，并且应该显示为其租户提供的应用程序。这是套接字和/或法兰绒可以解决的问题吗？或者如何通过合适的容器获得租户的解决方案？我认为这是一个普遍的问题。但至少在CoreOS容器化环境的背景下，我根本无法看到如何处理这个问题。
答案 0 :(得分：1)
CoreOS负责使用自己的工具（例如fleetctl / etcd / systemd）在集群中调度容器，并在使用flocker（实验）重新调整到不同容器时负责持久存储。他们有自己的负载平衡器。