Consul

[sma...@gmail.com]

I have been reading through the topics in this google group and keep finding stuff related to service discovery such as SkyDock DNS, Sidekicks, etcd scalability issues. I know CoreOS is partial to etcd since they wrote it... but it seems to me to truly make CoreOS and fleet great, it should be utilizing tools that already handle all these issues under a single reliable scaleable solution

https://groups.google.com/forum/#!topic/coreos-dev/0J8jh1e_WwQ

Using a sidekick allows you to manage and version the logic for the service registration separately from the app. This makes sense when you’re running an application that doesn’t speak etcd natively and isn’t going to be modified. The sidekick method allows you to start a service registration container that can run more complicated logic. It could read the docker API can make sure the container is actually up and running before announcing it. It could curl /health and read a status code. It could check connectivity to another dependent container.

Consul's service discovery already supports non native app discovery, it also handles health monitoring of the app and removing the app from the cluster if it fails.

https://groups.google.com/forum/#!searchin/coreos-dev/skydns/coreos-dev/iklEYHh5JyE/POfonV1LjF8J

Consul already supports DNS based discovery

a comparison of Consul vs etcd and skydns is available on their website... http://www.consul.io/intro/vs/index.html

I love the idea of CoreOS and Fleet but it seems like the marriage with Consul would be the perfect setup... im not biased to consul any way.... if etcd could be worked out to provide the same set of functionality to the coreos and fleet environment without SkyDNS and Sidekicks or home baked monitoring solutions then so be it. Otherwise it would be nice to see fleet operate on Consul

I am more so looking for your opinions on this not trying to start a flame war.

 

[Brandon Philips]

On Mon, May 19, 2014 at 6:59 PM, <sma...@gmail.com> wrote:
> I have been reading through the topics in this google group and keep finding
> stuff related to service discovery such as SkyDock DNS, Sidekicks, etcd

> I know CoreOS is partial to etcd since they wrote it...
> but it seems to me to truly make CoreOS and fleet great, it should be
> utilizing tools that already handle all these issues under a single reliable
> scaleable solution

etcd should help people build systems with less difficulty without
trying to solve every problem. And having different projects with a
separation of concerns is good design. If particular features become
important enough to include into etcd we will do that in time. But,
building a solid consensus data store is the focus right now.

With consul being a month old it is a far too early to say that it
solves all of these problems in a scalable and reliable way.

> Consul's service discovery already supports non native app discovery, it
> also handles health monitoring of the app and removing the app from the
> cluster if it fails.

If your application wants to build on top of zookeeper, consul or
mongodb then etcd can be used to bootstrap those services. CoreOS
provides a practical platform for building your system on top of. As a
trivial example here is a quick recipe to use etcd to bootstrap a
consul cluster on-top of CoreOS, it includes a cloud-config and script
to download and bootstrap consul automatically by using etcd:
https://gist.github.com/philips/56fa3f5dae9060fbd100

There are lots of fun new technologies that come out all the time and
having the core building blocks that CoreOS contains makes it easier
to play with them and build real working systems too.

> I am more so looking for your opinions on this not trying to start a flame
> war.

etcd+fleet provide the platform for configuring and running your
applications. It isn't a prescription that everything you run on
CoreOS use these tools directly but they work together to get systems
running on your cluster. Also, user feedback on the features and
tooling is helpful so if you have specific needs let us know.

Thanks,

Brandon

[Stephen Major]

Thank you, I have been running all types of scenarios through my head last night on how I would combine resource monitoring with fleet and coreos to listen for things like CPU load, ram usage etc and automatically respond by starting up new VMs through the digital ocean API (once they support coreos) storing the API keys in etcd and API settings. But using consul for the service discovery and monitoring. It would then kick off fleet to add more containers to the new node to handle the load

---

From: Brandon Philips
Sent: ‎5/‎20/‎2014 8:54 AM
To: coreos-dev
Subject: Re: Consul