5 ms·

> but Docker has kind of imploded and its Swarm project has been long dead Is it? I mean, it's still there in docker and its setup instructions remain a lot mo

> but Docker has kind of imploded and its Swarm project has been long dead Is it? I mean, it's still there in docker and its setup instructions remain a lot more concise and simple than even the most "it's easy, really!" tutorials of k8s-related things tend to be. It kind of seems like it's not so much dead as it exists, it does some things, and probably isn't going to be doing a lot more new things in the future but it's honestly pretty appealing when you go looking at things like this for 'simple' use cases.

davnicwil 5y ago
Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin. A related question - the article mentions swarm here as the k8s equivalent, but can docker compose also fill this role in even simpler usecases, like just a handful of services in a typical 3 tier web stack? (especially on a team without k8s expertise that goes much beyond the functionality of docker compose) I get a general sense from reading various threads on this topic that using docker compose in prod isn't seen as a great idea, without ever having seen the why properly articulated.
- fivea 5y ago
  > Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin. This. To me Docker's swarm mode is already feature-complete and solid. The only thing that I'm aware that needs some work is the notorious intra-node connection speed issue, but that's not a blocker in any way.
- kubanczyk 5y ago
  > the article mentions swarm here as the k8s equivalent, but can docker compose also fill this role Docker-compose is inherently limited to the single node (single daemon). No redundancy. The multinode version of docker-compose is docker swarm, in terms of the yaml file being mostly just ready for migration to swarm. > something being simple and something being sort of done and not under active development are two sides of the same coin If someone's resumé is basically "5 years experience with docker swarm" they have a harder time on the market than if they had these years with k8s.
random_kris 5y ago
At work we use swarm and I love it. In past i was exposed to badly configured kuberneteres. I take docker swarm any day
KronisLV 5y ago
That's a false statement as far as the technical aspects are concerned (Swarm is still usable and supported), but is a true statement when you look at the social aspects (Kubernetes won the container wars and now both Swarm and even Nomad is uncommon to run into). Right now the company i'm in uses Swarm in a lot of places due to its simplicity (Compose file support) and low resource usage - Swarm hits the sweet spot when it comes to getting started with container orchestration and doing so without needing multiple people to wrangle the technical complexity of Kubernetes, or large VMs to deal with its resource usage, at least in on prem environments. In combination with Portainer (https://www.portainer.io/ https://www.portainer.io/) it's perhaps one of the best ways to get things done, when you expect everything to just work and aren't doing something too advanced (think along the lines of 10 servers, rather than 100, which is probably most of the deployments out there). I actually wrote about some of its advantages in my blog post, "Docker Swarm over Kubernetes": https://blog.kronis.dev/articles/docker-swarm-over-kubernetes https://blog.kronis.dev/articles/docker-swarm-over-kubernete... That said, if there are any good options to replace Swarm, it has to either be Hashicorp Nomad (https://www.nomadproject.io/ https://www.nomadproject.io/) which is a really nice platform, especially when coupled with Consul (https://www.consul.io/ https://www.consul.io/), as long as you can get past the weirdness of HCL, or it has to be K3s (https://k3s.io/ https://k3s.io/), which gives you Kubernetes without the insane bloat and hardware usage. I actually benchmarked K3s against Docker Swarm in similar app deployments: 1 leader server, 2 follower servers, running a Ruby on Rails app and an ingress, while they're under load testing by K6 (https://k6.io/ https://k6.io/). I was attempting to see whether COVID contract tracking with GPS would be viable as far as the system load goes in languages with high abstraction level, here's more info about the approach: https://blog.kronis.dev/articles/covid-19-contact-tracing-with-gps-versus-bluetooth-and-the-unexplored-potential-for-the-apps https://blog.kronis.dev/articles/covid-19-contact-tracing-wi... Honestly, the results were pretty close - on the follower servers, the overhead of the orchestrator agents were a few percent (K3s being heavier, but a few dozen MB here or there not being too relevant), whereas the bigger differences were in the leader components, where K3s was heavier almost by a factor of two, which isn't too much when you consider how lightweight Swarm is (there was a difference of a few hundred MB) and the CPU usage was reasonably close in both of the cases as well. Sadly, the text of the paper is in Latvian, so it's probably of no use to anyone, but i advise you to do your own benchmarks! Being a student back then, i couldn't afford many servers, so it's probably a good idea to benchmark those with more servers. Of note, on those VPSes (4 GB of RAM, single core), the full Kubernetes wouldn't even start, whereas at work, trying to get the resources for also running Rancher on top of a "full" Kubernetes cluster (e.g. RKE) can also take needlessly long due to the backlash from ops. Also, personally i find the Compose syntax to be far easier to deal with, rather than the amalgamation that Kubernetes uses, Helm probably shouldn't even be a thing if the deployment descriptors weren't so bloated. Just look at this: https://docs.docker.com/compose/compose-file/compose-file-v3/ https://docs.docker.com/compose/compose-file/compose-file-v3... In short: - Docker Swarm is pretty good when you're starting out with containers and is reasonably stable and easy to use - with Portainer, you can take it pretty far, be it in regards to development environments or even production - Compose format is great and works for Portainer and Docker Swarm (with minor changes), it's really nice - sadly, none of that really matters, because Kubernetes has more hype and therefore you have to learn how to use it in the industry - because of this, expect most of the tooling to be for Kubernetes and Swarm to fade into irrelevance before being retired (killed) - on the bright side, K3s is a viable and mostly non-bloated alternative to the "full" Kubernetes distros - also, Portainer supports both, so you don't even always need Rancher either
planb 5y ago
I deployed Docker Swarm in a small cluster at work this year. After evaluating K8S, Nomad and Swarm it was the solution that best fit our needs (together with Portainer for graphical management and a few scripts to deploy from jenkins). The system is simple enough that it can be documented on one wiki page and when stuff goes wrong (which fortunately hasn't happened yet) there is always a way to deploy the containers manually.
- mikepurvis 5y ago
  Interesting. I did a similar evaluation in early 2021 and landed on microk8s as the right balance of features, ease of deployment, and not having to do much hand-rolling or other manual stuff.
- GordonS 5y ago
  I have Swarm clusters running in production too, and am planning on deploying dozens more this year. Swarm is great - if you already use Compose, then you can use Swarm with ease. It's so much simpler than k8s.
  - piaste 5y ago
    Thirding the Docker Swarm... I wouldn't say "love", more like the "it's a piece of our infrastructure and it chugs along just fine, I guess it's cool?", which is sentiment I've rarely seen anyone express towards Kubernetes.
- mountainriver 5y ago
  Just FYI that swarm is EOL
  - perlwle 5y ago
    Source? It is rather the opposite based on mirantis latest blog post on Swarm https://www.mirantis.com/blog/docker-swarm-webinar-qa-long-live-docker-swarm/ https://www.mirantis.com/blog/docker-swarm-webinar-qa-long-l... > It all stems from when Mirantis first acquired the Docker Enterprise business two years ago, they put out a blog saying, “We’re gonna support Swarm for at least two more years and we’re gonna take that time to kind of see what the need is, what the market dictates…” > Unfortunately, some third parties took that and said, “Oh, they’re only going to support it for two years and then they’re going to sunset it.” That’s not true at all. This is important to us and to our future direction. We continue to invest in it and we have lots of large enterprise customers using Swarm in production at scale.
wilsonfiifi 5y ago
Yeah so the author didn’t do enough research before writing that because just the other day, Mirantis announced that docker swarm is going to be fully supported for the foreseeable future [0]. So you can confidently use swarm with your projects. [0] https://youtu.be/pCGCCQyBtjg https://youtu.be/pCGCCQyBtjg
- miked85 5y ago
  I would still be wary about committing to Docker Swarm, even Mirantis' home page is pushing Kubernetes.
  - withinboredom 5y ago
    I think any marketing page would be.
    - miked85 5y ago
      If they are promoting competing software over Swarm, you have to question that, marketing or not.

davnicwil 5y ago

Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin. A related question - the article mentions swarm here as the k8s equivalent, but can docker compose also fill this role in even simpler usecases, like just a handful of services in a typical 3 tier web stack? (especially on a team without k8s expertise that goes much beyond the functionality of docker compose) I get a general sense from reading various threads on this topic that using docker compose in prod isn't seen as a great idea, without ever having seen the why properly articulated.

fivea 5y ago
> Also came here to ask this. Seems like something being simple and something being sort of done and not under active development are two sides of the same coin. This. To me Docker's swarm mode is already feature-complete and solid. The only thing that I'm aware that needs some work is the notorious intra-node connection speed issue, but that's not a blocker in any way.
kubanczyk 5y ago
> the article mentions swarm here as the k8s equivalent, but can docker compose also fill this role Docker-compose is inherently limited to the single node (single daemon). No redundancy. The multinode version of docker-compose is docker swarm, in terms of the yaml file being mostly just ready for migration to swarm. > something being simple and something being sort of done and not under active development are two sides of the same coin If someone's resumé is basically "5 years experience with docker swarm" they have a harder time on the market than if they had these years with k8s.

random_kris 5y ago

At work we use swarm and I love it. In past i was exposed to badly configured kuberneteres. I take docker swarm any day

KronisLV 5y ago

That's a false statement as far as the technical aspects are concerned (Swarm is still usable and supported), but is a true statement when you look at the social aspects (Kubernetes won the container wars and now both Swarm and even Nomad is uncommon to run into). Right now the company i'm in uses Swarm in a lot of places due to its simplicity (Compose file support) and low resource usage - Swarm hits the sweet spot when it comes to getting started with container orchestration and doing so without needing multiple people to wrangle the technical complexity of Kubernetes, or large VMs to deal with its resource usage, at least in on prem environments. In combination with Portainer (https://www.portainer.io/ https://www.portainer.io/) it's perhaps one of the best ways to get things done, when you expect everything to just work and aren't doing something too advanced (think along the lines of 10 servers, rather than 100, which is probably most of the deployments out there). I actually wrote about some of its advantages in my blog post, "Docker Swarm over Kubernetes": https://blog.kronis.dev/articles/docker-swarm-over-kubernetes https://blog.kronis.dev/articles/docker-swarm-over-kubernete... That said, if there are any good options to replace Swarm, it has to either be Hashicorp Nomad (https://www.nomadproject.io/ https://www.nomadproject.io/) which is a really nice platform, especially when coupled with Consul (https://www.consul.io/ https://www.consul.io/), as long as you can get past the weirdness of HCL, or it has to be K3s (https://k3s.io/ https://k3s.io/), which gives you Kubernetes without the insane bloat and hardware usage. I actually benchmarked K3s against Docker Swarm in similar app deployments: 1 leader server, 2 follower servers, running a Ruby on Rails app and an ingress, while they're under load testing by K6 (https://k6.io/ https://k6.io/). I was attempting to see whether COVID contract tracking with GPS would be viable as far as the system load goes in languages with high abstraction level, here's more info about the approach: https://blog.kronis.dev/articles/covid-19-contact-tracing-with-gps-versus-bluetooth-and-the-unexplored-potential-for-the-apps https://blog.kronis.dev/articles/covid-19-contact-tracing-wi... Honestly, the results were pretty close - on the follower servers, the overhead of the orchestrator agents were a few percent (K3s being heavier, but a few dozen MB here or there not being too relevant), whereas the bigger differences were in the leader components, where K3s was heavier almost by a factor of two, which isn't too much when you consider how lightweight Swarm is (there was a difference of a few hundred MB) and the CPU usage was reasonably close in both of the cases as well. Sadly, the text of the paper is in Latvian, so it's probably of no use to anyone, but i advise you to do your own benchmarks! Being a student back then, i couldn't afford many servers, so it's probably a good idea to benchmark those with more servers. Of note, on those VPSes (4 GB of RAM, single core), the full Kubernetes wouldn't even start, whereas at work, trying to get the resources for also running Rancher on top of a "full" Kubernetes cluster (e.g. RKE) can also take needlessly long due to the backlash from ops. Also, personally i find the Compose syntax to be far easier to deal with, rather than the amalgamation that Kubernetes uses, Helm probably shouldn't even be a thing if the deployment descriptors weren't so bloated. Just look at this: https://docs.docker.com/compose/compose-file/compose-file-v3/ https://docs.docker.com/compose/compose-file/compose-file-v3... In short: - Docker Swarm is pretty good when you're starting out with containers and is reasonably stable and easy to use - with Portainer, you can take it pretty far, be it in regards to development environments or even production - Compose format is great and works for Portainer and Docker Swarm (with minor changes), it's really nice - sadly, none of that really matters, because Kubernetes has more hype and therefore you have to learn how to use it in the industry - because of this, expect most of the tooling to be for Kubernetes and Swarm to fade into irrelevance before being retired (killed) - on the bright side, K3s is a viable and mostly non-bloated alternative to the "full" Kubernetes distros - also, Portainer supports both, so you don't even always need Rancher either

planb 5y ago

I deployed Docker Swarm in a small cluster at work this year. After evaluating K8S, Nomad and Swarm it was the solution that best fit our needs (together with Portainer for graphical management and a few scripts to deploy from jenkins). The system is simple enough that it can be documented on one wiki page and when stuff goes wrong (which fortunately hasn't happened yet) there is always a way to deploy the containers manually.

mikepurvis 5y ago
Interesting. I did a similar evaluation in early 2021 and landed on microk8s as the right balance of features, ease of deployment, and not having to do much hand-rolling or other manual stuff.
GordonS 5y ago
I have Swarm clusters running in production too, and am planning on deploying dozens more this year. Swarm is great - if you already use Compose, then you can use Swarm with ease. It's so much simpler than k8s.
- piaste 5y ago
  Thirding the Docker Swarm... I wouldn't say "love", more like the "it's a piece of our infrastructure and it chugs along just fine, I guess it's cool?", which is sentiment I've rarely seen anyone express towards Kubernetes.
mountainriver 5y ago
Just FYI that swarm is EOL
- perlwle 5y ago
  Source? It is rather the opposite based on mirantis latest blog post on Swarm https://www.mirantis.com/blog/docker-swarm-webinar-qa-long-live-docker-swarm/ https://www.mirantis.com/blog/docker-swarm-webinar-qa-long-l... > It all stems from when Mirantis first acquired the Docker Enterprise business two years ago, they put out a blog saying, “We’re gonna support Swarm for at least two more years and we’re gonna take that time to kind of see what the need is, what the market dictates…” > Unfortunately, some third parties took that and said, “Oh, they’re only going to support it for two years and then they’re going to sunset it.” That’s not true at all. This is important to us and to our future direction. We continue to invest in it and we have lots of large enterprise customers using Swarm in production at scale.

wilsonfiifi 5y ago

Yeah so the author didn’t do enough research before writing that because just the other day, Mirantis announced that docker swarm is going to be fully supported for the foreseeable future [0]. So you can confidently use swarm with your projects. [0] https://youtu.be/pCGCCQyBtjg https://youtu.be/pCGCCQyBtjg

miked85 5y ago
I would still be wary about committing to Docker Swarm, even Mirantis' home page is pushing Kubernetes.
- withinboredom 5y ago
  I think any marketing page would be.
  - miked85 5y ago
    If they are promoting competing software over Swarm, you have to question that, marketing or not.