proxy - 在一个 url 下的马拉松 (mesos) 中运行 redis

Question

我在 mesos、marathon 中的一个 IP 地址上启动 redis 服务器时遇到问题。

我的脚步

• 创建自己的 Dockerfile，其中包含自己的 redis.conf
• 我创建自己的 docker 镜像并将其拉入 docker 存储库(名称为 arekmax/redis-instancje)
• 在 Marathon 中，我启动了我的 docker 镜像 - redis 启动并正常工作。 mesos 中的故障转移 Redis 服务器也能正常工作 - 当我关闭 192.168.18.21 服务器时 - Marathon 在第二个或第三个实例中启动 Redis。

现在我想给我的开发人员一个地址 IP，他们可以在其中使用 Redis 服务器(我不想现在给他们 192.168.18.21:31822 并且在故障转移之后给他们，例如 192.168.18.22:23124)。我需要一些代理服务器如何自动检查实际的 redis IP 和端口。

我尝试使用 bamboo project但它在端口 80 上正常工作——我不知道它可以将 bamboo 与 redis 服务器一起使用——我找不到如何将 31822(在我的情况下是 docker 容器中的 redis 端口)重定向到例如 IP 192.168.18.10 的信息: 6739(地址IP 192.168.18.10是我开发的redis服务器)

谁能帮帮我？问题的最佳解决方案是什么？我应该使用哪种代理服务器/实例/应用程序？

Answer 1

在 Mesos 环境中执行发现服务有十几种解决方案。

我们可以按照客户寻找服务的方式将他们分为三类:

1. 基于代理
   • 当客户端和服务之间有代理时，例如 HAProxy ( marathon-lb 基于它)， fabio , traefik , nixy ) 负责根据 HTTP 路径、 header 、域等对您的服务进行负载均衡。该解决方案易于开发，并提供了根据请求调整负载平衡的机会。另一方面，我们添加了额外的跃点，作为代理，我们有 MitM情况。

1. DNSlike(向特殊的知名端点询问服务位置)
   • Software Defined Network - 我们可以将每个容器的 IP 与 SDN 一起使用，这样每个容器都可以使用唯一的 IP 公开，并使用默认端口 80 用于 HTTP、443 用于 HTTPS 等来呈现其服务。这是最先进和相对较新的技术，尽管它使用普通的旧 DNS 来查找服务 IP。引入代理可能更难，但可以处理任何类型的流量。
   • Service record - 每个容器都在全局 DNS 中注册，客户端使用 DNS SRV 查询获取其 IP 和端口。领事Mesos DNS提供此类 DNS 服务器。其他一些协议(protocol)也基于这个想法(看看 Bonjure )。它试图充分利用 SDN 和代理。它设置起来相对容易，并且与协议(protocol)无关。

1. 其他
   • 任何不适合其他类型的内容，例如内部开发的解决方案，etcd或 Eureka .它可能与提供一些优化的基础架构和应用程序非常紧密。值得一提的是，有一些尝试使用 DHT基于发现服务 - Meta Service Discovery

您可以找到有关可用于创建发现服务的工具的更多详细信息 here

我们可以通过填充服务条目的方式来划分发现服务:

1. 池化
   • 定期查询 Mesos/Marathon 的状态。这就是 Mesos DNS 的工作方式。这是最简单的方法，但会在服务启动/停止和更改进入服务发现之间造成巨大的延迟。这可以通过使用健康检查来最小化。
2. 基于事件
   • 马拉松有能力 push events关于状态变化的信息(也有包含事件总线 int Mesos 的倡议 — design doc。这样 marathon-lb 正在工作。类似的工作由 marathon-consul 完成，但数据被传递给领事。
3. 在应用程序/容器中
   • 以上解决方案是异步的，因此当您的服务发现状态陈旧时可能会有一个时间跨度，例如服务已启动但尚未准备好为请求提供服务，或者服务刚刚终止。即使使用 healtcheck，我们也不能假设所有事情都发生在 0 停机时间。最大限度减少停机时间的解决方案是让应用程序在准备好处理请求时自行注册，并在停止前取消注册(也称为正常关闭)。