
Docker Swarm Cluster Complete Guide - lukasbar
https://knowledgepill.it/posts/docker_swarm_compendium/
======
orf
Swarm was interesting, but it seems that both SwarmKit and "Classic Swarm" are
dead[1][2], with no real activity since 2018.

Kubernetes, for better or for worse, has clearly completely won. Not that this
article isn't interesting for it's own sake, but it's just something to
consider.

1\.
[https://github.com/docker/swarmkit/graphs/contributors](https://github.com/docker/swarmkit/graphs/contributors)
2\.
[https://github.com/docker/classicswarm/graphs/contributors](https://github.com/docker/classicswarm/graphs/contributors)

~~~
1_player
SwarmKit and ClassicSwarm are not "docker swarm", but AFAIK precursors of it
until they've been merged into Docker itself.

As a production user of Docker Swarm though, it is effectively dead and I've
been planning a migration to k8s ASAP.

~~~
justincormack
Swarmkit is the code that runs "Docker Swarm", it is vendored in to build it.
I don't think anyone really uses Classic Swarm any more, and it was a
precursor.

~~~
1_player
I stand corrected, thanks.

------
belzebalex
Docker Swarm is a marvel. It's super easy to use yet does the job very simply.

~~~
auspex
On the surface. Easy to setup a simple use case but long term has a similar
learning curve to Kubernetes for a production deployment.

~~~
readyoubestbook
Maybe I am missing something or underestimating the complexity of a k8s
deployment, but we have been running Swarm in production for a while now and
it was/is still a breeze. So what would you consider the complexities of
running Swarm in production - I would then like to look into these - as a
means of being ahead of the curve of complexity...

~~~
belzebalex
Same for me. Swarm has been super easy to install and to use in production.
You can do highly available deployments super easily too. I don't see how one
could build the same thing more simply.

------
moomin
I know Mirantis have pledged to continue developing Docker Swarm, but it still
strikes me as a pretty risky choice for 2020.

~~~
DyslexicAtheist
I know some companies still using it because they say K8 is too complex (e.g.
learning curve) for their needs. It could be appealing to these cases.

~~~
moomin
Meh, it’s a pain to install, but that can be automated, and a pain to get your
head around, but the only features you really need for basic usage are service
and deployment.

On the other hand, most of the books on it are spectacularly bad.

------
kfk
I am looking into this now. Basically it’s either this or the super hard
Kubernetes right? I find it hard to believe that we don’t have a middle
ground?

~~~
jordanbeiber
Nomad + Consul.

Used it for years in prod - just awesome.

I’ve also used k8s extensively and nomad/consul is more ”open” and less
opinionated.

If you also manage some form of legacy infrastructure and VMs, consul is hard
to ignore.

Two go-binaries - you’re up in minutes for a test drive.

~~~
heipei
_sigh_ I've almost given up nudging folks on here to give Nomad a spin. It's
so easy to deploy and play with, heck you can run a client and server with a
single go binary on your local machine. If you compare that to all the
hundreds of different (and soon-to-be-deprecated) installation instructions
for k8s, k8s feels like a joke at best, or an evil plot at worst to get
everyone to use hosted k8s. Honestly, people use hosted k8s because you need a
full-time person/team to run it, so in the end, even though k8s is Open
Source, Google (and AWS) still win...

Nevermind that Nomad is fast, easy to grasp, very concise and can run non-
Docker workloads. Oh well...

~~~
klohto
I'm interested to hear more! The Nomad page gives me a good overview but
doesn't tell me WHY should I migrate from an existing k8 cluster. Would you be
able to sell it to me?

~~~
jordanbeiber
Off the top of my head:

\- Nomad is a more general type of workload scheduler. What I mean with
"general" is that you can schedule pretty much anything over a bunch of hosts
- not just containers e.g you have a JRE on the node? Just schedule your jar.
Execute a raw shell command? Not a problem.

\- Batch jobs with parameters? Just send it to the "dispatch" endpoint with
parameters and an optional payload. Often can replace "serverless" and
sometimes work queues.

\- Consul is a "general purpose" service discovery (dns & distributed K/V)
that can span over all your services, not just k8s ones (for this very reason
Hashicorp have built a k8s -> consul services sync tool: it is often needed!)

You include consul agent with a service definition in roles on your
ansible/salt/puppet managed VM's. They can be included in the mesh, and SD
works seamlessly between hosts and containers.

\- The consul connect (mesh) feature with envoy is much more comprehensible
than istio.

I use to say that nomad + consul is more in-line with the "unix philosophy".
You have these two binaries that do what they do independently, but they can
be hooked together if you would like to use distributed K/V and service
discovery for your scheduled workload. Add Vault to that - which often is used
without consul & nomad, but integrates as well.

They can all be easily integrated with through well defined rest API's and do
not have to be consumed as a big black box.

K8s is all or nothing.

~~~
klohto
Thanks a lot. I will definitely give it a try. Thankfully, our services are
very easily manageable and provide clear Rest APIs, it's just the overhead
cluster that's making us slow. I would love to have something like Nomad ready
and available for single-tenant deployments of our service. It's where you
need to tweak a lot and do it fast.

------
lukasbar
This guide can help people that want to pass DCA exam from Docker Inc.

