How we use HashiCorp Nomad • Hacker News Board

Re: How we use HashiCorp Nomad

#161

Post by ospider » Mon, Jun 08, 2020, 5:47 AM UTC

Actually, I think K8S is much simpler to operate than nomad.

With nomad, you have too many options, you can run your service/job as a process or within containers, but with Kubernetes, there is only one way to do things -- container, which is really a simple choice to make.

Besides, Kubernetes got etcd builtin, so I don't have to use deploy and maintain consul.

Last but not least, I still see containers mysteriously gone, and have no idea how nomad did that. With kubernetes, such thing never happened.

Re: How we use HashiCorp Nomad

#162

Post by DavyJone » Mon, Jun 08, 2020, 9:34 AM UTC

adadgar wrote: post #19

DavyJone wrote: post #8

Earlier quoted context omitted.

Does it have "easy" side-cars/init/post? Last time I checked those were missing for example.

It does! Here is the relevant documentation and examples: https://www.nomadproject.io/docs/job-specification/lifecycle... https://learn.hashicorp.com/nomad/task-deps/interjob

Ill check that out, I really think K8s is becoming a bit too complex for many customers. Thanks!

Re: How we use HashiCorp Nomad

#163

Post by aganame » Mon, Jun 08, 2020, 3:08 PM UTC

4636760295 wrote: post #6

api wrote: post #4

Earlier quoted context omitted.

Which features is Nomad missing? Feature count comparisons are meaningless unless the features are tied to actual important use cases. Lots of software is encrusted with rarely used features that just add complexity.

The main missing feature is that it's not kubernetes.

You have an extra word there.

Re: How we use HashiCorp Nomad

#164

Post by ksec » Mon, Jun 08, 2020, 4:35 PM UTC

nielsole wrote: post #14

pier25 wrote: post #13

Off topic but... I've always wondered how Cloudflare can not charge for the bandwidth. Even the free plan is super generous (CDN, SSL, etc). How are they making a profit when AFAIK all other CDNs charge you for the bandwidth (and I assume they have to pay for to their providers)?

See the second answer for a statement from cf https://webmasters.stackexchange.com/questions/88659/how-can...

Thank You! The answer was from 2016, and yet this is the first time anyone has posted this every time a similar question was raised on HN over the past few years.

Re: How we use HashiCorp Nomad

#165

Post by aprdm » Mon, Jun 08, 2020, 6:11 PM UTC

stitched2gethr wrote: post #113

aprdm wrote: post #105

Do people that aren't cloudflare scale really see the need for kubernetes and/or Nomad? Of the two Nomad seems much more sane because it does one thing only and is much simpler to manage and deploy. That said, having have used it, we are mostly moving away from it. Consul + Docker/Docker-compose with systemd in "a service per vm" model has proved much easier to administrate to our scale (couple of datacenters, ~1k VM…

From my personal experience, yes, but not just for scale. I've used Kubernetes in a 300k person organization and now in a 35 person organization. Kubernetes isn't the simplest solution, but it's just reliability in a box. You can control the network, and the servers, and the load balancing all through the API which means for most things I can install a fully clustered solution with a handful of commands. Set the numb…

I see. My last work experiences have been introducing devops workflows into companies that already had a decent tech body (~200 people) and the traditional divide between IT/Dev.

I think the approach I mention ends up being a good compromise from both sides. If I were starting a company from scratch I would certainly consider it differently.

Re: How we use HashiCorp Nomad

#166

Post by f355 » Thu, Jun 11, 2020, 8:24 AM UTC

orthoxerox wrote: post #142

q3k wrote: post #12

Earlier quoted context omitted.

Helm, however, is objectively terrible with its yaml-based templating language and zero practical modularity.

It is. But k8s has no convenient way of parameterizing releases that can beat Helm. A simple stateless application needs: - a deployment - a service - an ingress - a config map (or several) - a secret (or several) It's even worse for stateful applications. And each of the resource definitions is 60% boilerplate, 35% application-specific and 5% release- or environment-specific. Helm would probably be a nice and neat t…

k8s has a very convenient built-in way of parametrizing releases called kustomize, it is supported by kubectl since quite a few versions ago.