Skip to content
This repository has been archived by the owner on Jun 22, 2018. It is now read-only.

ServiceDiscoveryInMinimesos

Frank Scholten edited this page Mar 21, 2016 · 4 revisions

Pros and cons of service discovery using Consul and Weave.

I'm requesting feedback on the following idea:

We want to keep minimesos compact. Adding a bunch of service discovery containers (Consul or Weave or both or neither, configurable...) is going to make the project much less concise. We will need to support a lot of different testcases as well.

The idea is to view networking/sd as a separate concern and have it started outside the context of minimesos. For example, Weave should already be up, then the only thing we need to do is to pass in Weave's Docker host endpoint into minimesos so it can configure DockerClientFactory with this endpoint. If we make the dockerHost configurable, either through cli parameter or config file, this is easy and will keep the code compact.

Now, who is responsible for starting up Weave?

One idea is to add a configuration item with a list of containers that should be started before the Mesos cluster will be run. Config file pseudo code:

{
   runBefore: [
      { "image": "weaveworks/plugin:1.4.5", "env": "etcetera" },
      { "image": "weaveworks/weaveexec:1.4.5", "env": "etcetera" }
   ]
}

What are your thoughts?

Frank's Feedback

I agree we should keep minimesos core compact yet configurable with before containers. We can make a generic container block that maps on a subclass of AbstractContainer. Typically we only have to know the image + tag version and some parameters.

{
   before {
      container {
        "image" = "weaveworks/plugin:1.4.5";
        "env" = "etcetera"     
        "command" = "command"
      }
   }  
}

If we have this setup we can support both Consul and Weave. They will run before the minimesos cluster is started