Hacker News new | ask | show | jobs
by glynnforrest 1705 days ago
> Flexible Workload Support

This is Nomad's most underrated feature, IMHO. You don't have to use containers for everything if you don't want to. For example, if you're a golang shop you can run everything as native binaries and cut out docker completely.

Nomad has much simpler networking, i.e. no web of iptables rules to figure out. You can add Consul connect as a service mesh if you need it, but if you don't, you can keep things very simple. Simple = easy to understand, run, and debug.

The main downside for me is a lack of plug and play pieces, e.g. a helm chart for Grafana or Prometheus. You'll have to write your own job for those, though it's very easy to learn. I'd love to see a series of Nomad recipes that people could use.

I think it's the ideal choice for on-prem, bare-metal, or 'weird' deployments where you need a bit more control. You can build the exact stack you need with the different HashiCorp projects with minimal overhead.

I can't recommend it enough! I help people move to Nomad, my email is in my profile if you want to chat :)

4 comments

> For example, if you're a golang shop you can run everything as native binaries and cut out docker completely.

Ironically you can also just deploy a go executable into an empty Docker container and it's basically the same as the raw executable, but with all the config abstracted to be the same as other containers'.

Good point! Although Docker does add a networking layer on top. I'd prefer to run something like HAProxy without Docker if possible.
You can run it on the host network as well.
Adding the networking layer is a good thing since it's centrally managed
Flexible workload support doesn't sound great to me.

Good tools have very specific use-cases so as soon as you start talking about IIS on windows, VMs, containers etc. it just sounds like lots of the dependencies you are trying to remove in a scalable system.

Containers are relatively restrictive but they also enforce good discipline and isolation of problems which is a good idea imho. I would not want to continue to support our Windows servers running IIS, just too much to sort out.

I understand what you're saying. Fewer runtimes = fewer problems.

It's not going to force your hand. You can disable all the task drivers except the docker driver if you want a container-only cluster. The drivers themselves are lightweight.

In an ideal world, every company is two years old and only produces software in perfect docker containers, but in reality there's always some service that doesn't work in a container but could benefit from job scheduling.

I think it's great that we can add scheduling to different runtimes. Some folks want or need to use those different runtimes, and I like that Nomad lets you do that.

The question often isn't what we as individuals want, though. It's what's good for the business given operational, budgetary, and personnel constraints.

Many people still have mission-critical Windows applications. Windows has nominal container support, but the footprint of a basic Windows container image is extremely high and the limitations of how you can use them are pretty onerous.

> The main downside for me is a lack of plug and play pieces,

Hashicorp just announced Nomad Packs filling that precise niche. Still in beta, and it was a long time coming but IMHO it was the main thing missing and is honestly awesome.

Here's the repo link in case you need it for Nomad Pack. https://github.com/hashicorp/nomad-pack
I looked into Nomad a whole back, and finding good examples was a problem - Packs looks fantastic!
This has been my biggest pain point - world+dog shares their helm charts, but blog posts or git*.com repos with non-trivial cluster recipes are rare.

f.e. We're exploring cortexmetrics currently, and spinning the full stack version up on k8s (openshift) was straightforward. Porting all that spaghetti onto nomad would be a huge job, though part of the frustration is knowing someone, tucked away on a private network, has already done this.

> the frustration is knowing someone, tucked away on a private network, has already done this.

Hard agree. I know this person and have been this person before.

I've toyed with the idea of writing a book of Nomad recipes and tips, I wonder if anyone would read it?

Also, watch this space, helm for Nomad may be coming soon: https://github.com/hashicorp/nomad-pack

A book - probably not so much.

The big value of sites (mostly github master repos) that offer recipes for saltstack/chef/ansible/puppet, or the helm collective, etc - are that they're continually being tweaked as new versions of (upstream) software are released.

They usually all require a fair bit of localisation before they 'just work', at least in my experience, but the template taken from a proven functioning system, and then abstracted & shared, is worth its weight in gold.

I've set up a few nomad jobs, but nothing anywhere as complex as, say, this cortexmetrics monstrosity. Even our k8s & nomad guru baulks at such an undertaking.