Docker for Elasticsearch多租户SaaS或单实例和代理？

Question

我正在尝试构建Elasticsearch作为服务的原型。我想到了两种不同的方法，我想对一个或另一个实现提出意见

1. 单一安装Elasticsearch，并在顶部添加代理层以添加用户验证（http基本身份验证+用户帐户以验证使用情况）。 这种方法相对简单，主要的挑战是正确配置集群以处理负载以及权限，因此没有数据泄漏的用户无法访问集群管理API。

2. 将Docker用作容器，并为每个用户提供一个elasticsearch实例。在这种情况下，我将使用Linux容器（Docker）提供隔离。我仍然需要管理身份验证。

实现这两者，玩游戏并了解事物的行为可能会很好。关于每种方法的利弊的任何意见？

谢谢！

Answer 1

免责声明：我是Elasticsearch服务提供商Facetflow的创始人，该提供商目前提供共享群集。

我认为这两种方法都有价值，但可能适合不同类型的客户。 看看其他SaaS提供商，比如MongoDB提供商MongoLab，他们最终提供了两种设置（虽然没有使用Docker）。

所以，我看到它们的优点和缺点：

共享群集

大多数Elasticsearch即服务提供商都以这种方式运营。

<强>优点：

1. 对于寻求良好搜索和分析的大多数用户来说，价格更便宜。
2. 更简单的维护，更少的群集供您监控
3. 与Elasticsearch集成的潜在版本较少。如果您需要与其他系统（您这样做）进行通信，请编写自己的插件（我们这样做，用于身份验证，孤岛，权利，统计等）。更少的版本将更容易维护。

<强>缺点：

1. 必须监控嘈杂的邻居，你必须扩展和重新定位索引来处理这个问题。
2. 用户必须从有限的Elasticsearch版本中进行选择，通常是单个版本。
3. 用户无法获得完整的群集管理控制权。

使用Docker的私有群集

以这种方式工作的一个提供商是Found。

<强>优点：

1. 用户可能能够部署各种版本的Elasticsearch
2. 用户可以拥有完整的群集管理员访问权限
3. 吵闹的邻居不会影响他们的群集，减少你的人工干预

<强>缺点：

1. 复杂的监控和支持。如果人们可以做任何他们想做的事情（通过api关闭群集），你必须清楚你作为提供者的责任在哪里结束，以及什么唤醒你在晚上。
2. 与多个版本的复杂集成，请参阅共享集群专业人员。
3. 更昂贵，因为您必须分配可能并非总是使用的资源。