The Switch to Swarm
I recently switched from using Rancher to using Docker Swarm for container orchestration. Me and my partner loved Rancher and used its built-in Cattle orchestration engine, but with the upcoming Rancher 2.0, they were only going to support Kubernetes orchestration. We tried to use Kubernetes, but we simply don’t like it. It is overcomplicated, clunky, and resource intensive compared to the simple and elegant solutions of Cattle. Upon comparing Cattle to Docker Swarm, we liked Swarm even more than we liked Cattle. They were pretty much the same in most respects, but Swarm was built into Docker and didn’t require running a dedicated server. We have already set up a working swarm cluster and it is working very nicely for us. We even created a Swarm docker plugin for distributed storage using LizardFS.
After getting into Swarm I found an issue on GitHub that concerned me quite a bit. There is a limitation imposed by Swarm that you cannot run privileged Swarm services. This is a pretty major limitation, especially when the Docker run command already supports it and many different applications need to have system privileges. It was almost a show stopper for a Docker plugin I made. I had to create a Swarm service that would run a standalone Docker container to workaround. Additionally, this issue was created two years ago and yet has had no progress so far.
It’s not the only issue like it either. There is another issue where the
docker stack deploy command won’t source a
.env file like Docker Compose does. It is a valid concern for the users of Docker, but the issue is still there without any progress after a year-and-a-half. And here are some more:
- Configs not updated when redeploying stack
docker build should support privileged operations – Actually about
docker buildnot Swarm. Open issue for almost 5 years.
- docker service create doesn’t allow --privileged flag – Another issue about Swarm privileges. Open for 2 years.
In all of these issues you see the users of Docker trying to hack their way around an issue that the Docker team doesn’t seem to care about fixing. Sometimes the response is that it is not a “bug”, but you have a lot of people who have valid use cases that they cannot facilitate because of these issues. The issues were raised by users who actually have a need for the feature, but the Docker team doesn’t seem to agree with the users that they need it.
To be completely frank these issues are starting to scare me away from Swarm, and to a lesser degree, Docker itself. They seem to represent the Docker team’s attitude as one of thinking that they know how the tool should be used more than the people that use it. I understand the Docker team’s perspective sometimes, but I think that they are really pushing away the users of Docker in these instances.
I feel like this statement reveals a fundamental disconnect between the way Docker’s developers and users view these products.
Gave up on this and switched to Kubernetes.
My fear is that I am eventually going to have my own issue that is going to be a blocker to me using Swarm, and that I am going to get similar resistance from the Docker team. The privileged swarm service issue was almost a show-stopper for one of my solutions ( and I still think that it is a shame that it has not been fixed yet ). I don’t want to go with Swarm if I am going to have to switch to something else later because of a limitation. That could be an expensive and long process if I start a major project with it.
What is the Future of Swarm?
Me and my partner still love the way Swarm is setup. The way that it handles networking and high availability and service discovery could hardly be more ideal in our opinion. It is the attitude of the Docker developers that is concerning. I would like to get some answers from the Docker team about some questions:
- Does Docker ( team ) want to keep Swarm going?
- Is there a Roadmap or plans for continuing development on Swarm?
- Are you going to give up Swarm eventually because you are supporting Kubernetes?
Me and my partner don’t wan’t to switch to Kubernets. Swarm is so much more elegant without sacrificing hardly any features. Swarm deserves more care than it gets.
If the Docker team could grant me any insight in to what the future of Swarm looks like it would be appreciated. I want to use it, but at this point I am very concerned about where it is headed.