Hello!
I am wondering if Swarm is supported already? I read this blog post from a year ago http://rancher.com/rancher-support-for-docker-swarm-and-machine/ but I still cannot find anything on the docs.
If not already implemented is still part of the plan?
Best regards,
Alejandro
Currently, we have our own scheduling service in Rancher that mimics a lot of what swarm does, but we are looking to add native swarm to Rancher.
Thanks @denise, I am aware of the duplication of functionality, but I am sure having the option would ease the decision of moving/trying Rancher easier for a lot of people currently running Swarm.
I put a +1 on the issue, and I really feel that as little “duplication” of effort that Rancher can do would be best… From a development background, I know for a fact that resources are finite and anything needs to be prioritized… If docker uses as much from the standard ecosystem as possible, with pluginability for as many other things it can be what sets docker apart from the crowd in the future…
Despite the current limitations and bugs which can be annoying and prevent me from currently using it in production, rancher is pretty much the platform I’m eyeing… It ticks most if not all boxes…
Some things I can mention however:
ps: a small little question as I’m unsure where to put it, will rancher-compose be in fact deprecated in favor of docker-compose straight? (I think there was a talk abt this being the case, which IMO does make sense), but cant find it now… also, any plans for compose v2 support?
Good luck and thanks so much for your work Rancher Labs! Can we send beer?
From what I seem to distill from Twitter, Swarm integration is coming…
The combination of Swarm as a single entity combined with (for instance) the network overlay of Rancher would be great!
For me the “single entity” has the advantage when going for a more “cron driven” solution like Mesos Chronos, where you want to speak to one entrypoint.
Apart from that, I’ve always remembered that Rancher did not want to compete with Docker native features. So I can imagine that at a given point… Features like rancher-compose will be depricated, IF the native solution can replace it. Though be aware that the service description of rancher-compose enhances (and builds further) on the docker-compose.
Yes, marketing likes to make pictures… that screen totally exists today :-D.
Essentially there is nothing preventing you from installing Swarm today and connecting it to the same hosts that are used by Rancher. And we can make a catalog template that will install it for you.
LOL @vincent marketing always cracks me up… It does exist, only the options arent “Kube / Swarm” the options are “Rancher / Kube / Swarm” and the last 2 are disabled, oh and, its also hidden in the UI 
Its my understanding that docker-swarm “competes” (in functionality) with the rancher scheduling, so how would it function if we install it by ourselves or with a catalog? What benefit would one have from installing swarm on a rancher environment? Or even Kubernetes on a rancher environment? (in the case of Kube I’m perhaps even further from seeing a connection since the terms and topology/rationale are so distant)…
On thing which is often spoken abt on here is around scheduling and re-scheduling… Apparently swarm still doesnt “reschedule” containers if the host dies? (sounds weird? but there is a feature spec here which implies that https://github.com/docker/swarm/issues/1488) … anyways, what it does/doesnt is moot, I understand the value (at least for me lol) of Rancher being focused on being the de facto Docker “PaaS”/AWS-style system/[insert description you like here]… And part of this vision is employing docker components whenever possible, as well as being wire-compatible to as much as possible…
So basically as much as rancher can use from docker instead of replicating functionality its to everyone’s benefit… (ex: rancher had its own networking and now uses docker-networking, right?), etc It benefits users migrating or trying rancher, the most, as they dont need to change apps or learn new paradigms, etc… It benefits the Rancher team because they can focus on what needs improving and not dupilcated functionality, it helps users who may have team members who prefer to interact directly with a specific rancher tool, etc, etc…
On a small side-note, will rancher-compose cli be deprecated in favor of docker-compose cli? and will compose v2 be supported?
@RVN_BR That was yesterday… today it actually exists:
You’ll probably want to listen to the meetup tomorrow for the rationale discussion from those marketing guys 
. Obviously we like the Rancher/Cattle experience but if you want k8s/swarm there’s no reason we can’t manage those too and let you discover why you might prefer ours.
rancher-compose will be updated to support the v2 format at some point.
Hey Guys,
Congrats on going GA and reaching 1.0! 
Kudos to all!
I realize we now have 3 options… Cattle scheduler, Swarm and Kube…
Is there anywhere we can see an overview of each, and what features one might gain/lose over another?
Its my understanding that Rancher stacks would work on any scheduler? (or am I mistaken… I did find a Stacks option inside a swarm cluster, but it was semi-hidden away… so is that an error?) (also fyi when you are in a swam cluster, it mentions Kubernetes… I am reloading my rancher dev setup right now, I’ll update exactly where it shows up…)
Basically my main question, where can we see a comparison of each, and what differs in rancher in terms of each other? Is it possible/advisable/not-advisable to have a single host as multiple environments with different schedulers? What about a single host with mutliple environments and the same scheduler?
Thanks a lot for clearing it all up… In case there is another post or article outlining this, please let me know!
+1 for a comparison between the three, both feature wise, and what you get in rancher with each.
I don’t think you’ll be able to register a single node to more than one environment at a time, regardless of scheduler, but it’s a good question. 
