01f42053e4
This is an attempt to ease dependency management for external driver plugins, by avoiding requiring them to compile ugorji/go generated files. Plugin developers reported some pain with the brittleness of ugorji/go dependency in particular, specially when using go mod, the default go mod manager in golang 1.13. Context -------- Nomad uses msgpack to persist and serialize internal structs, using ugorji/go library. As an optimization, we use ugorji/go code generation to speedup process and aovid the relection-based slow path. We commit these generated files in repository when we cut and tag the release to ease reproducability and debugging old releases. Thus, downstream projects that depend on release tag, indirectly depends on ugorji/go generated code. Sadly, the generated code is brittle and specific to the version of ugorji/go being used. When go mod picks another version of ugorji/go then nomad (go mod by default uses release according to semver), downstream projects face compilation errors. Interestingly, downstream projects don't commonly serialize nomad internal structs. Drivers and device plugins use grpc instead of msgpack for the most part. In the few cases where they use msgpag (e.g. decoding task config), they do without codegen path as they run on driver specific structs not the nomad internal structs. Also, the ugorji/go serialization through reflection is generally backward compatible (mod some ugorji/go regression bugs that get introduced every now and then :( ). Proposal --------- The proposal here is to keep committing ugorji/go codec generated files for releases but to use a go tag for them. All nomad development through the makefile, including releasing, CI and dev flow, has the tag enabled. Downstream plugin projects, by default, will skip these files and life proceed as normal for them. The downside is that nomad developers who use generated code but avoid using make must start passing additional go tag argument. Though this is not a blessed configuration. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| .netlify | ||
| acl | ||
| api | ||
| client | ||
| command | ||
| contributing | ||
| demo | ||
| dev | ||
| devices/gpu/nvidia | ||
| dist | ||
| drivers | ||
| e2e | ||
| helper | ||
| integrations | ||
| internal/testing/apitests | ||
| jobspec | ||
| lib | ||
| nomad | ||
| plugins | ||
| scheduler | ||
| scripts | ||
| terraform | ||
| testutil | ||
| ui | ||
| vendor | ||
| version | ||
| website | ||
| .gitattributes | ||
| .gitignore | ||
| appveyor.yml | ||
| build_linux_arm.go | ||
| CHANGELOG.md | ||
| GNUmakefile | ||
| LICENSE | ||
| main.go | ||
| main_test.go | ||
| README.md | ||
| Vagrantfile | ||
Nomad 
Overview
Nomad is an easy-to-use, flexible, and performant workload orchestrator that deploys:
Nomad enables developers to use declarative infrastructure-as-code for deploying their applications (jobs). Nomad uses bin packing to efficiently schedule jobs and optimize for resource utilization. Nomad is supported on macOS, Windows, and Linux.
Nomad is widely adopted and used in production by PagerDuty, Target, Citadel, Trivago, SAP, Pandora, Roblox, eBay, Deluxe Entertainment, and more.
-
Deploy Containers and Legacy Applications: Nomad’s flexibility as an orchestrator enables an organization to run containers, legacy, and batch applications together on the same infrastructure. Nomad brings core orchestration benefits to legacy applications without needing to containerize via pluggable task drivers.
-
Simple & Reliable: Nomad runs as a single 75MB binary and is entirely self contained - combining resource management and scheduling into a single system. Nomad does not require any external services for storage or coordination. Nomad automatically handles application, node, and driver failures. Nomad is distributed and resilient, using leader election and state replication to provide high availability in the event of failures.
-
Device Plugins & GPU Support: Nomad offers built-in support for GPU workloads such as machine learning (ML) and artificial intelligence (AI). Nomad uses device plugins to automatically detect and utilize resources from hardware devices such as GPU, FPGAs, and TPUs.
-
Federation for Multi-Region, Multi-Cloud: Nomad was designed to support infrastructure at a global scale. Nomad supports federation out-of-the-box and can deploy jobs across multiple regions and clouds.
-
Proven Scalability: Nomad is optimistically concurrent, which increases throughput and reduces latency for workloads. Nomad has been proven to scale to clusters of 10K+ nodes in real-world production environments.
-
HashiCorp Ecosystem: Nomad integrates seamlessly with Terraform, Consul, Vault for provisioning, service discovery, and secrets management.
Getting Started
Get started with Nomad quickly in a sandbox environment on the public cloud or on your computer.
- Local
- AWS
- Azure
These methods are not meant for production.
Documentation & Guides
- Installing Nomad for Production
- Advanced Job Scheduling on Nomad with Affinities
- Increasing Nomad Fault Tolerance with Spread
- Load Balancing on Nomad with Fabio & Consul
- Deploying Stateful Workloads via Portworx
- Running Apache Spark on Nomad
- Integrating Vault with Nomad for Secrets Management
- Securing Nomad with TLS
- Continuous Deployment with Nomad and Terraform
- Auto-bootstrapping a Nomad Cluster
Documentation is available on the Nomad website here.
Resources
- Website
- Mailing List
- Gitter
- Webinars
- Community Calls
Who Uses Nomad
- CircleCI
- Citadel
- Deluxe Entertainment
- Jet.com (Walmart)
- PagerDuty
- Pandora
- SAP Ariba
- SeatGeek
- Spaceflight Industries
- SpotInst
- Target
- Trivago
- Roblox
- Oscar Health
- eBay
- Joyent
- Dutch National Police
- N26
- Elsevier
- Palantir
- Graymeta
- NIH NCBI
- Q2Ebanking
- imgix
- Region Syddanmark
...and more!
Contributing to Nomad
If you wish to contribute to Nomad, you will need Go installed on your machine (version 1.12.9+ is required).
See the contributing directory for more developer documentation.
Developing with Vagrant There is an included Vagrantfile that can help bootstrap the process. The created virtual machine is based off of Ubuntu 16, and installs several of the base libraries that can be used by Nomad.
To use this virtual machine, checkout Nomad and run vagrant up from the root
of the repository:
$ git clone https://github.com/hashicorp/nomad.git
$ cd nomad
$ vagrant up
The virtual machine will launch, and a provisioning script will install the needed dependencies.
Developing locally
For local dev first make sure Go is properly installed, including setting up a
GOPATH. After setting up Go, clone this
repository into $GOPATH/src/github.com/hashicorp/nomad. Then you can
download the required build tools such as vet, cover, godep etc by bootstrapping
your environment.
$ make bootstrap
...
Afterwards type make test. This will run the tests. If this exits with exit status 0,
then everything is working!
$ make test
...
To compile a development version of Nomad, run make dev. This will put the
Nomad binary in the bin and $GOPATH/bin folders:
$ make dev
Optionally run Consul to enable service discovery and health checks:
$ sudo consul agent -dev
And finally start the nomad agent:
$ sudo bin/nomad agent -dev
If the Nomad UI is desired in the development version, run make dev-ui. This will build the UI from source and compile it into the dev binary.
$ make dev-ui
...
$ bin/nomad
...
To compile protobuf files, installing protoc is required: See
https://github.com/google/protobuf for more information.
Note: Building the Nomad UI from source requires Node, Yarn, and Ember CLI. These tools are already in the Vagrant VM. Read the UI README for more info.
To cross-compile Nomad, run make prerelease and make release.
This will generate all the static assets, compile Nomad for multiple
platforms and place the resulting binaries into the ./pkg directory:
$ make prerelease
$ make release
...
$ ls ./pkg
...