5 ms·

Nomad seems great, and I wanted to jump in a lot of times, but I found it hard to do. I'm not sure why though. Setting up a basic project is easy if you follow

Nomad seems great, and I wanted to jump in a lot of times, but I found it hard to do. I'm not sure why though. Setting up a basic project is easy if you follow their tutorials, but at a certain point it just gets confusing, and you end up piecing things together, because you'll need Consul and Vault. So after a while I just got lost. Maybe because I don't live and breathe all the orchestration related jargon. In my limited experience, and my use-case, I found that dealing with docker-compose and docker stack is much more straightforward, and seems to work out of box.

heipei 5y ago
I agree with you that if you're looking at single-node deployments, Nomad or any distributed orchestrator will feel like overkill. I personally use Nomad quite a lot, but for single-box systems I'll happily revert to using plain Docker containers started via systemd service files. The beauty of something like Nomad is that you can run it on a single box with moderately more effort than docker compose, but then you can flick a switch and have your workloads run across multiple machines.
- maccard 5y ago
  > The beauty of something like Nomad is that you can run it on a single box with moderately more effort than docker compose, but then you can flick a switch and have your workloads run across multiple machines. How is that any different to kubernetes with k3s?
  - sofixa 5y ago
    k3s is still drastically more complex, with a lot more moving parts.
    - maccard 5y ago
      Honest question; how? And what difference does that make to running an app? Running on k8s involves writing 2 yaml files, and scaling is literally the flick of a switch. The architecture of nomad may be simpler but how does that benefit me as a user? I've been running apps in kubernetes for about 2 years now at a "mild" scale and not once has the complexity of k8s been the show stopping issue it's made out to be here on HN.
kawsper 5y ago
I think the first upgrade from docker-compose towards nomad is running nomad in a single-server setup (not recommended, but for the same reasons docker-compose on a single server is a bad idea if you want high-availability).
schmichael 5y ago
Nomad Team Lead here -> You're definitely not alone, and we know it. Once you add Consul, Vault, namespaces, ACLs, mTLS, etc you have quite the infrastructure to maintain. HashiCorp is making a big push to cloud to help alleviate this operational burden, but there's a lot we intend to do to make it easier to self-host as well. We're continually refining Terraform modules[1] to ease setup, although Nomad's own terraform directory is in dire need of updating. Running Consul and/or Vault with Nomad is definitely possible, but we need to do the hard work of testing and publishing best practices. Once you have Nomad up and running, staring at an empty job file is daunting as well! We're approaching that problem from 2 angles: better tools for guided job creation, and more modular job files. Templating tools already provide some job file modularization, but nothing as unified as the Helm/Charts experience. Nomad lacks any sort of central job repository as well. You can expect us to chip away at these problems like we've approached everything else: incremental improvements while maintaining backward compatibility. And for those willing (or eager!) to let someone else handle the operational burden for you: stay tuned for exciting things coming from HashiCorp Cloud Platform! [1] https://registry.terraform.io/modules/hashicorp/nomad/aws/latest/submodules/nomad-cluster https://registry.terraform.io/modules/hashicorp/nomad/aws/la...
- harryvederci 5y ago
  One thing I found a bit daunting is that the documentation says you should never run Nomad on a single node in production. Could you tell me what the downside would be of running Nomad on 1 server in dev mode, versus running an application on 1 server without Nomad? Doing so could make it easier to start off a project with Nomad from the start, and expanding to the full blown "3-or-5 Nomad Servers, 1-to-10000 Nomad Clients" setup when needed. But maybe I'm not seeing the full picture.
  - schmichael 5y ago
    It's largely a testing and documentation issue on our end. Nomad clients (the daemon's running on each node managing workloads) keep your services running even if they lose contact with Nomad servers (the schedulers), so a Nomad outage != a service outage. Please start filing issues encountered in single server setups to help us improve the situation! What I'm afraid is that the lack of issues does not mean that it's a pain-free experience.
mike1o1 5y ago
I agree. I love the idea of it, but as a relative newcomer to the space, some of the documentation and examples definitely felt a bit "draw the rest of the owl". I think a lot of that lies in the fact that all of the pieces stand-alone, which is a selling point, but it makes it difficult to see how they all join together to create the bigger picture. I'd love to see a good tutorial on setting up a complete environment, with Vault, Consul and Nomad (and Waypoint!) with best practices. Something like "here's how to deploy your rails app with Nomad and Vault" would be great to see the big picture.

heipei 5y ago

I agree with you that if you're looking at single-node deployments, Nomad or any distributed orchestrator will feel like overkill. I personally use Nomad quite a lot, but for single-box systems I'll happily revert to using plain Docker containers started via systemd service files. The beauty of something like Nomad is that you can run it on a single box with moderately more effort than docker compose, but then you can flick a switch and have your workloads run across multiple machines.

maccard 5y ago
> The beauty of something like Nomad is that you can run it on a single box with moderately more effort than docker compose, but then you can flick a switch and have your workloads run across multiple machines. How is that any different to kubernetes with k3s?
- sofixa 5y ago
  k3s is still drastically more complex, with a lot more moving parts.
  - maccard 5y ago
    Honest question; how? And what difference does that make to running an app? Running on k8s involves writing 2 yaml files, and scaling is literally the flick of a switch. The architecture of nomad may be simpler but how does that benefit me as a user? I've been running apps in kubernetes for about 2 years now at a "mild" scale and not once has the complexity of k8s been the show stopping issue it's made out to be here on HN.

kawsper 5y ago

I think the first upgrade from docker-compose towards nomad is running nomad in a single-server setup (not recommended, but for the same reasons docker-compose on a single server is a bad idea if you want high-availability).

schmichael 5y ago

Nomad Team Lead here -> You're definitely not alone, and we know it. Once you add Consul, Vault, namespaces, ACLs, mTLS, etc you have quite the infrastructure to maintain. HashiCorp is making a big push to cloud to help alleviate this operational burden, but there's a lot we intend to do to make it easier to self-host as well. We're continually refining Terraform modules[1] to ease setup, although Nomad's own terraform directory is in dire need of updating. Running Consul and/or Vault with Nomad is definitely possible, but we need to do the hard work of testing and publishing best practices. Once you have Nomad up and running, staring at an empty job file is daunting as well! We're approaching that problem from 2 angles: better tools for guided job creation, and more modular job files. Templating tools already provide some job file modularization, but nothing as unified as the Helm/Charts experience. Nomad lacks any sort of central job repository as well. You can expect us to chip away at these problems like we've approached everything else: incremental improvements while maintaining backward compatibility. And for those willing (or eager!) to let someone else handle the operational burden for you: stay tuned for exciting things coming from HashiCorp Cloud Platform! [1] https://registry.terraform.io/modules/hashicorp/nomad/aws/latest/submodules/nomad-cluster https://registry.terraform.io/modules/hashicorp/nomad/aws/la...

harryvederci 5y ago
One thing I found a bit daunting is that the documentation says you should never run Nomad on a single node in production. Could you tell me what the downside would be of running Nomad on 1 server in dev mode, versus running an application on 1 server without Nomad? Doing so could make it easier to start off a project with Nomad from the start, and expanding to the full blown "3-or-5 Nomad Servers, 1-to-10000 Nomad Clients" setup when needed. But maybe I'm not seeing the full picture.
- schmichael 5y ago
  It's largely a testing and documentation issue on our end. Nomad clients (the daemon's running on each node managing workloads) keep your services running even if they lose contact with Nomad servers (the schedulers), so a Nomad outage != a service outage. Please start filing issues encountered in single server setups to help us improve the situation! What I'm afraid is that the lack of issues does not mean that it's a pain-free experience.

mike1o1 5y ago

I agree. I love the idea of it, but as a relative newcomer to the space, some of the documentation and examples definitely felt a bit "draw the rest of the owl". I think a lot of that lies in the fact that all of the pieces stand-alone, which is a selling point, but it makes it difficult to see how they all join together to create the bigger picture. I'd love to see a good tutorial on setting up a complete environment, with Vault, Consul and Nomad (and Waypoint!) with best practices. Something like "here's how to deploy your rails app with Nomad and Vault" would be great to see the big picture.