3 ms·

How does libswarm compare to etcd/fleet?

akerl_ 12y ago
This is a layer "above" etcd/fleet/geard/shipyard/etc. The idea is to standardize the way that administrators/users/developers "talk" to the various underlying containers. The intent is for it to have plugin support for etcd and fleet and all the other tools in that layer.
shykes 12y ago
The author of Fleet have started contributing a Fleet adapter :) libswarm exposes a standard interface to systems like Fleet, Mesos, Consul etc. It also has adapters for popular infrastructure providers, and for the Docker API itself. That way you can compose your architecture from standard building blocks, and change the building blocks over time without being locked in. There was huge demand for this in the Docker system because there are so many orchestration tools being announced and competing for the attention of developers and sysadmins. Just at Dockercon, New Relic announced "Centurion", Spotify announced "Helios", Google announced "Kubernetes". Having a standard interface allows for these tools to continue competing without the risk of fragmentation and lock-in. Of course the interface has to be thin enough to not get in the way. That's why we're focusing on keeping the codebase small, and the API as simple as possible.
philips 12y ago
fleet and etcd are orthogonal to the problems that libswarm is trying to solve. libswarm has a future as a nice way of doing composition of networked services that are represented as objects in pipelines. The first demo is a `swarmd` daemon that exposes a docker API endpoint on one end and aggregates between a lot of "real" Docker endpoints. The big open question is how this sort of composition works when the objects have different interfaces. So, how do we expose a "swarm" API that can be shared between different consistent data stores like etcd, zookeeper or consul. Or how do we encapsulate things like a runtime configured load balancer like nginx, apache2 or vulcand using a unified interface. My hope for the project is to look at the interface model of Go or the DBus protocol and try to get consensus around the interfaces that make sense and hide complexity.

This is a layer "above" etcd/fleet/geard/shipyard/etc. The idea is to standardize the way that administrators/users/developers "talk" to the various underlying containers. The intent is for it to have plugin support for etcd and fleet and all the other tools in that layer.

shykes 12y ago

The author of Fleet have started contributing a Fleet adapter :) libswarm exposes a standard interface to systems like Fleet, Mesos, Consul etc. It also has adapters for popular infrastructure providers, and for the Docker API itself. That way you can compose your architecture from standard building blocks, and change the building blocks over time without being locked in. There was huge demand for this in the Docker system because there are so many orchestration tools being announced and competing for the attention of developers and sysadmins. Just at Dockercon, New Relic announced "Centurion", Spotify announced "Helios", Google announced "Kubernetes". Having a standard interface allows for these tools to continue competing without the risk of fragmentation and lock-in. Of course the interface has to be thin enough to not get in the way. That's why we're focusing on keeping the codebase small, and the API as simple as possible.

philips 12y ago

fleet and etcd are orthogonal to the problems that libswarm is trying to solve. libswarm has a future as a nice way of doing composition of networked services that are represented as objects in pipelines. The first demo is a `swarmd` daemon that exposes a docker API endpoint on one end and aggregates between a lot of "real" Docker endpoints. The big open question is how this sort of composition works when the objects have different interfaces. So, how do we expose a "swarm" API that can be shared between different consistent data stores like etcd, zookeeper or consul. Or how do we encapsulate things like a runtime configured load balancer like nginx, apache2 or vulcand using a unified interface. My hope for the project is to look at the interface model of Go or the DBus protocol and try to get consensus around the interfaces that make sense and hide complexity.