运行chronos docker映像在桥接模式下

kt06eoxx  于 2021-06-21  发布在  Mesos
关注(0)|答案(2)|浏览(307)

我一直在组装一个poc-mesos/marathon系统,用来启动和控制docker图像。
我有一个流浪的虚拟机在virtualbox上运行,我在上面运行docker、marathon、zookeeper、mesos master和mesos slave进程,一切都按预期工作。
我决定将chronos添加到这个组合中,最初我将它作为一个服务在vagrant vm上运行,但后来选择使用mesophere/chronos映像在docker容器中运行它。
我发现,当我为容器指定主机网络模式时,可以让容器映像成功启动并运行,但当我更改为网桥模式时,就会遇到问题。
在桥接模式下,chronos框架向mesos成功注册(我可以看到mesos ui的frameworks页面上的条目),但是看起来框架本身并不知道注册成功。如果mesos主日志中包含以下消息:

strong textI1009 09:47:35.876454  3131 master.cpp:2094] Received SUBSCRIBE call for framework 'chronos-2.4.0' at scheduler-16d21dac-b6d6-49f9-90a3-bf1ba76b4b0d@172.17.0.59:37318
I1009 09:47:35.876832  3131 master.cpp:2164] Subscribing framework chronos-2.4.0 with checkpointing enabled and capabilities [  ]
I1009 09:47:35.876924  3131 master.cpp:2174] Framework 20151009-094632-16842879-5050-3113-0001 (chronos-2.4.0) at scheduler-16d21dac-b6d6-49f9-90a3-bf1ba76b4b0d@172.17.0.59:37318 already subscribed, resending acknowledgement

这意味着某种配置/通信问题,但我还没有弄清楚问题的根源到底是什么。我不确定是否有任何方法来确认mesos的确认是否返回到chronos或者检查组件之间的通信通道的状态。
我已经做了很多搜索,我可以找到的人谁遇到了同样的问题,但我没有找到一个需要做什么来纠正它详细的解释帖子。
例如,我发现下面的帖子提到了一个已经解决的问题,这意味着用户在桥接模式下成功地运行了他们的chronos容器,但是他们对解决方案的描述是模糊的。也有这个职位,但改变建议确实解决了问题,我看到的。
最后,有一个ilm的人发了一篇帖子,听起来像是我的问题,这个解决方案似乎涉及到对mesos的修复,引入了两个新的环境变量libprocess\u adversed\u ip和libprocess\u adversed\u port(在libprocess\u ip和libprocess\u port之上),但是我找不到一个合适的解释来解释应该是什么值分配给这些变量中的任何一个,所以我还没有弄清楚这个改变是否能解决我所面临的问题。
可能值得一提的是,我也在chronos调度程序组上发布了一些问题,但我没有得到任何回应。
如果有帮助的话,我运行的软件版本如下(卷装载允许我以文件形式提供其他参数的值[例如master、zk\u hosts],而不必不断更改json):

Vagrant:    1.7.4
VirtualBox: 5.0.2
Docker:     1.8.1
Marathon:   0.10.1
Mesos:      0.24.1
Zookeeper:  3.4.5

我用来启动chronos容器的json如下:

{
  "id": "chronos",
  "cpus": 1,
  "mem": 1024,
  "instances": 1,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "mesosphere/chronos",
      "network": "BRIDGE",
      "portMappings": [
        {
          "containerPort": 4400,
          "hostPort": 0,
          "servicePort": 4400,
          "protocol": "tcp"
        }
      ]
    },
    "volumes": [
      {
        "containerPath": "/etc/chronos/conf",
        "hostPath": "/vagrant/vagrantShared/chronos",
        "mode": "RO"
      }
    ]
  },
  "cmd": "/usr/bin/chronos --http_port 4400",
  "ports": [
    4400
  ]
}

如果有人有任何在这样的配置中使用chronos的经验,那么我将非常感谢您在解决此问题时提供的任何帮助。
当做,
保罗马特尔

wdebmtf2

wdebmtf21#

我设法找到了问题的答案(在这里的示例框架的帮助下),所以我想我应该发布一个解决方案来帮助其他人解决同样的问题。
chronos服务(以及示例框架)被配置为在与主机(vagrant)vm上的docker0接口相关联的ip上与zookeeper通信(在本例中为172.17.42.1)。
zookeeper会将主机报告为在127.0.1.1上可用,这是mesos主进程启动的主机vm的ip地址,但尽管可以从容器ping此ip地址,但任何连接到特定端口的尝试都将被拒绝。
解决方案是用--advertise\u ip参数启动mesos主机,并指定docker0接口的ip。这意味着尽管服务是在主机上启动的,但它看起来就像是在docker0 IonInterface上启动的一样。
完成后,mesos和chronos框架之间的通信开始完成,chronos中计划的任务成功运行。

bbuxkriu

bbuxkriu2#

运行mesos 1.1.0和chronos 3.0.1,我能够在中成功地配置chronos BRIDGE 通过显式设置 LIBPROCESS_ADVERTISE_IP , LIBPROCESS_ADVERTISE_PORT 将第二个端口固定到 hostPort 这并不理想,但我能找到的唯一方法是让它向mesos正确宣传其端口:

{
  "id": "/core/chronos",
  "cmd": "LIBPROCESS_ADVERTISE_IP=$(getent hosts $HOST | awk '{ print $1 }') LIBPROCESS_ADVERTISE_PORT=$PORT1 /chronos/bin/start.sh --hostname $HOST --zk_hosts master-1:2181,master-2:2181,master-3:2181 --master zk://master-1:2181,master-2:2181,master-3:2181/mesos --http_credentials ${CHRONOS_USER}:${CHRONOS_PASS}",
  "cpus": 0.1,
  "mem": 1024,
  "disk": 100,
  "instances": 1,
  "container": {
    "type": "DOCKER",
    "volumes": [],
    "docker": {
      "image": "mesosphere/chronos:v3.0.1",
      "network": "BRIDGE",
      "portMappings": [
        {
          "containerPort": 9900,
          "hostPort": 0,
          "servicePort": 0,
          "protocol": "tcp",
          "labels": {}
        },
        {
          "containerPort": 9901,
          "hostPort": 9901,
          "servicePort": 0,
          "protocol": "tcp",
          "labels": {}
        }
      ],
      "privileged": true,
      "parameters": [],
      "forcePullImage": true
    }
  },
  "env": {
    "CHRONOS_USER": "admin",
    "CHRONOS_PASS": "XXX",
    "PORT1": "9901",
    "PORT0": "9900"
  }
}

相关问题