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

问题描述

我有问题在马拉松的Mesos中的一个IP地址上启动Redis服务器.

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

我的步骤

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

• 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.

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

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.

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

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 ?

推荐答案

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

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

我们可以按照客户查找服务的方式将它们分为3组:

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

1. 基于代理
   • 在客户端和服务之间放置代理时，例如 HAProxy ( fabio ， traefik ， nixy )，可根据HTTP路径，标头，域等对服务进行负载平衡该解决方案易于开发，并提供了根据要求调整负载平衡的机会.另一方面，我们添加了额外的跃点，并且作为代理，我们具有 MitM 情况.

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. 类似于DNS(向服务定位询问特殊的知名终结点)
   • 软件定义的网络-我们可以将每个容器的IP与SDN一起使用，因此每个容器都是使用唯一的IP进行公开，并使用默认端口80(用于HTTP)，443(用于HTTPS)等展示其服务.尽管它使用简单的旧DNS查找服务IP，但这是最先进且相对较新的技术.引入代理可能会更困难，但可以处理任何类型的流量.
   • 服务记录-每个容器都在全局DNS中注册，并且客户端获取其IP和PORT使用DNS SRV查询. Consul Mesos DNS 提供了这种类型的DNS服务器.其他一些协议也基于此思想(请查看 Bonjure ).它尝试充分利用SDN和代理.它相对容易设置，并且与协议无关.

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. 其他
   • 任何其他类型都不适合的内容内部开发的解决方案 etcd 或 DHT 的发现服务-

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

您可以在此处

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

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

1. 池化
   • Mesos/Marathon会定期查询状态.这就是Mesos DNS的工作方式.这是最简单的方法，但是会导致服务启动/停止之间的巨大延迟，并且更改会进入服务发现.可以通过运行状况检查将其最小化.

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.

• Marathon能够推送事件，其中包含有关状态更改的信息(也有计划将事件总线int Mesos包含在内-设计文档.marathon-lb这样工作.

• 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.

• 以上解决方案都是异步的，因此当您的服务发现状态为陈旧状态时，可能会有一段时间.服务已启动，但尚未准备好服务请求，或者服务刚刚终止.即使进行了healtcheck，我们也不能假设所有故障都发生在停机时间为0的情况下.最小化停机时间的解决方案是让应用程序准备好在可以处理请求时进行自身注册，并在其停止之前注销(也称为正常关闭).

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