Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Swarm Cluster Complete Guide

knowledgepill.it

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Docker Swarm Cluster Complete Guide

#31

Post by klohto »

heipei wrote: post #24
jordanbeiber wrote: post #13

Earlier quoted context omitted.

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.

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…

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?

Re: Docker Swarm Cluster Complete Guide

#32

Post by jordanbeiber »

klohto wrote: post #31
heipei wrote: post #24

Earlier quoted context omitted.

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…

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?

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.

Re: Docker Swarm Cluster Complete Guide

#33

Post by klohto »

jordanbeiber wrote: post #32
klohto wrote: post #31

Earlier quoted context omitted.

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?

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 repl…

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.

Re: Docker Swarm Cluster Complete Guide

#34

Post by moomin »

DyslexicAtheist wrote: post #5
moomin wrote: post #3

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

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.

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.

Re: Docker Swarm Cluster Complete Guide

#35

Post by belzebalex »

readyoubestbook wrote: post #26
auspex wrote: post #15

Earlier quoted context omitted.

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

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...

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.

Re: Docker Swarm Cluster Complete Guide

#36

Post by dilyevsky »

kfk wrote: post #17
auspex wrote: post #12

Earlier quoted context omitted.

Kubernetes really isn't as difficult as you might think. Early on it was "hard" because most people were learning containers as well as Kubernetes. Also how that we have managed services like EKS, GKE, AKS it's really straight forward to learn. I would suggest start with a GKE cluster and deploy nginx.

There are many managed services, which is great, but how does this work when your storage is somewhere else? For instance I might decide to put the storage (postgres and minio) on a cheap Hetzner dedicated server, how would this work with EKS? I am especially trying to understand doing analytics and ML with dask.distributed. I think running compute on managed Kubernetes with storage inside another server could (hybri…

You’ll get charged an arm and a leg for egress (from aws) so have to pretty much commit to aws built in storage (either ebs or efs mounted volumes) or local machine storage (eg nvme drives)

Re: Docker Swarm Cluster Complete Guide

#37

Post by justRafi »

kfk wrote: post #17
auspex wrote: post #12

Earlier quoted context omitted.

Kubernetes really isn't as difficult as you might think. Early on it was "hard" because most people were learning containers as well as Kubernetes. Also how that we have managed services like EKS, GKE, AKS it's really straight forward to learn. I would suggest start with a GKE cluster and deploy nginx.

There are many managed services, which is great, but how does this work when your storage is somewhere else? For instance I might decide to put the storage (postgres and minio) on a cheap Hetzner dedicated server, how would this work with EKS? I am especially trying to understand doing analytics and ML with dask.distributed. I think running compute on managed Kubernetes with storage inside another server could (hybri…

You can use headless services[1] to incorporate external endpoints. There's also various CoreDNS plugins[2] that do wonders.

[1]: https://kubernetes.io/docs/concepts/services-networking/serv... [2]: https://coredns.io/plugins/

Re: Docker Swarm Cluster Complete Guide

#38

Post by blondin »

heipei wrote: post #24
jordanbeiber wrote: post #13

Earlier quoted context omitted.

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.

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…

my thing with hashicorp products is the feeling that they are geared towards enterprise and not the community at large.

people don't write about them or teach you about them. i have only seen a couple of youtube videos, just mentioning them. i got a book on terraform (the only one i could find that covers it) that wanted me to use AWS to even begin the examples.

it feels like these tools are only used in the enterprise realm.

very sad and discouraging.

Re: Docker Swarm Cluster Complete Guide

#39

Post by winxton »

belzebalex wrote: post #9

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

Agreed. It's my go to for smaller projects and what I recommend for those who don't want to spend more than a day figuring out how to deploy their pet project as it's a logical progression from docker-compose in dev to a production environment.

https://dockerswarm.rocks is better for a more complete, production-ready setup guide.

Re: Docker Swarm Cluster Complete Guide

#40

Post by elsonrodriguez »

ernststavrob wrote: post #21
gas9S9zw3P9c wrote: post #20

Earlier quoted context omitted.

I don't understand why people think Kubernetes is "hard" - I find it quite straightforward and the documentation is excellent. I've been running my side projects on a single k8s clusters and rarely have issues. Yes, there is a learning curve. It's not a Heroku where you enter one command and it just works. You'll need to spend a few days to become familiar with the basics concepts. And it may take weeks grasp the adv…

Kubernetes is "hard" when you're not running on the cloud. The solutions for persistent storage and networking are a mess when you're running on self-hosted infrastructure.

This is a trap. The best way to do storage on K8s is not to do it. Especially on-premises.

The networking used to be simple, you could just set up a few static routes and manually assign blocks of CIDRs to nodes and be done. I'm sure there there are some newer networking API components that obfuscated the whole thing in the name of "simplicity" because nobody understands networking anymore.

Post reply on HN