在一个 url 下在马拉松 (mesos) 中运行 redis [英] Run redis in marathon (mesos) under one url

查看:14
本文介绍了在一个 url 下在马拉松 (mesos) 中运行 redis的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

我的步骤

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

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

我尝试使用

  1. DNSlike(向特殊的知名端点询问服务位置)
      1. 其他
        • 任何不适合其他类型的东西,例如内部开发的解决方案,etcd尤里卡.基础设施和应用程序提供一些优化可能会非常紧张.值得一提的是,有一些尝试使用基于 DHT 的发现服务 - 元服务发现

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

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

      1. 池化
        • Mesos/Marathon 会定期查询状态.这就是 Mesos DNS 的工作方式.这是最简单的方法,但会导致服务启动/停止和更改进入服务发现之间的巨大延迟.使用运行状况检查可以最大限度地减少这种情况.
      2. 基于事件
        • Marathon 能够推送事件以及有关状态变化的信息(也有包含事件总线 int Mesos 的倡议 — 设计文档.marathon-lb 就是这样工作的.类似的工作由 marathon-consul 但数据被传递给 consul.
      3. 在应用程序/容器中
        • 上述解决方案是异步的,因此当您的服务发现状态过时时可能会有一个时间跨度,例如服务已启动但尚未准备好处理请求,或者服务刚刚终止.即使使用了healtcheck,我们也不能假设所有事情都会在0 停机时间内发生.最大限度减少停机时间的解决方案是让应用程序在准备好处理请求时自行注册,并在它停止之前取消注册(也称为正常关闭).

      I have problem witch start redis server on one IP address in mesos, marathon.

      My steps

      • create own Dockerfile who include own redis.conf
      • I create my own docker image and pull it into docker repo (name arekmax/redis-instancje)
      • in Marathon I start my docker images - redis start and work properly. Failover redis server in mesos also work properly - when I shut-down 192.168.18.21 server - Marathon start Redis in second or third instance.

      Now I want give my developer one adress IP where they can use redis server (I don't want give them now 192.168.18.21:31822 and after failover for example 192.168.18.22:23124). I need some proxy server how will auto check actual redis IP and port.

      I try use bamboo project but it work properly to port 80 - I don't know its possibility to use bamboo with redis server - i can't find information how to redirect 31822 (in my situation redis port in docker container) to for example IP 192.168.18.10:6739 (address IP 192.168.18.10 it's for my developer redis server)

      Can anyone help me? what is the best solution of the problem? what kind of proxy server/instance/application I should use ?

      解决方案

      There are dozen solutions for performing discovery service in Mesos environment.

      We can divide them into 3 groups by the way how client find services:

      1. Proxy based
        • When between clients and service sits proxy e.g., HAProxy (marathon-lb is based on it), fabio, traefik, nixy) that takes care of loadbalancing your services basing on HTTP path, header, domain e.t.c. This solution is the easy to develop and gives opportunity to tune loadbalancing based on request. On the other hand we add additional hop and as a proxy we have MitM situation.

      1. DNSlike (ask special well known endpoint for location of service)
        • Software Defined Network - we can use IP per container with SDN so each container is exposed with unique IP and presents it's services using default ports 80 for HTTP, 443 for HTTPS and so on. This is most advanced and relatively new techniqe although it uses plain old DNS to find service IP. It could be harder to intorduce then proxy but will work with any type of traffic.
        • Service record - where every container is registered in global DNS and client obtain it's IP and PORT using DNS SRV queries. Consul Mesos DNS provides this type of DNS server. Also some other protocols are based on this idea (take a look at Bonjure). It tries get best of both SDN and proxy. It's relatively easy to setup and it's protocol agnostic.

      1. Other
        • Anything that doesn't fit into other types e.g. inhouse developed solution, etcd or Eureka. It could be deeply tight with infrastructure and application providing some optimizations. It's worth mention that there are some tries to use DHT based discovery service - Meta Service Discovery

      You can find more details about tools that could be used for creating Discovery Service here

      We can divide Discovery Services by the way they are populated with service entries:

      1. Pooling
        • Mesos/Marathon is periodically queried about state. This is how Mesos DNS is working. This is easiest method but will cause huge delay beteween service start/stop and changes gets into service discovery. This could be minimized by using healthchecking.
      2. Event based
        • Marathon has ability to push events with information about state changes (There is initative to include event bus int Mesos too — design doc. This way marathon-lb is working. Similar job is done by marathon-consul but data are passed to consul.
      3. In app/container
        • Above sollutions are asynchronus so there could be a timespan when your service discovery state is stale e.g. service started but is not ready to serve requests, or service just died. Even with healtcheck we could not assume all things happen with 0 downtime. Solution to minimize downtime is to let application register itself when it's ready to serve requests, and deregister before it stop (aka graceful shutdown).

      这篇关于在一个 url 下在马拉松 (mesos) 中运行 redis的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆