https://github.com/vaelatern/nomad-declarative
Declarative configuration of your nomad cluster
https://github.com/vaelatern/nomad-declarative
Last synced: about 2 months ago
JSON representation
Declarative configuration of your nomad cluster
- Host: GitHub
- URL: https://github.com/vaelatern/nomad-declarative
- Owner: Vaelatern
- License: other
- Created: 2025-01-10T02:55:54.000Z (4 months ago)
- Default Branch: master
- Last Pushed: 2025-03-26T03:50:52.000Z (about 2 months ago)
- Last Synced: 2025-03-26T04:35:28.432Z (about 2 months ago)
- Language: Go
- Size: 0 Bytes
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Orchestrated Jobs As Configuration
Nomad and k3s are awesome.
Unfortunately, there isn't really a paved path for operators to define their entire compute cluster jobs as a consistent set of programs that are running.
Sure you can always reconstruct your cluster state by re-applying the same files you applied before, but which files DID you apply before? That's what I'm hoping to help solve here.
## How To Think Of This Tool
Let's declare in a configuration file (or `.d` style configuration files within a directory) a set of Jobs.
Those Jobs can come from Packs.
Those Jobs can contain multiple nomad jobs (one per file), variables to apply to Nomad, policies, plain text to reference, and whatever else you can think of.
These Packs can come from any reachable origin. We use the [go-fsimpl](https://pkg.go.dev/github.com/hairyhenderson/go-fsimpl) library to ease selection of pack remotes.
Packs have names. Packs have origins. Packs can have a different name at the origin than we name them ourselves.
Jobs have names. Those have to be unique in the output. That uniqueness is not enforced in the configuration file.
If you have anything that needs to be templated based on your job name, just template it. It's fine.
## Config file
This is provided as toml. There is a top level dictionary, with "pack name" as the key. The second layer is "Job name." It is this second layer that must be unique.
Parameters that alter how the pack is interpreted start with an underscore. Right now these are:
### Pack
- `_origin`
- `_origin-name`
- `_name` - this defaults to the pack name
### Job
Convention is the job name is passed automatically to the templates as `jobname` and datacenters as `datacenters`.
Only `jobname` is automatically set.
## Bug tracker
- Problem: Can't pull packs from authenticated sources
- Problem: Too much in cmd/
* Solution: Refactor mostly into `internal`