Version Controlling Job Config Files

Hi All,

I’m an absolute beginner to Nomad and am curently working my way through the official tutorials. If this question has already been answered elsewhere then please point it out.

I understand that job config files can/are checked into version control. What is the nomadic idiom for maintaining job configurations for different types of environments?

To elaborate, consider a developer who wants to deploy the same job to multiple clusters that have different resource constraints. For instance deploy to a lightweight local dev cluster, test, then promote to more powerful QA/Staging/Prod clusters. The developer wants to test everything locally using a two instance group of an application container, whereas the same would require 8 instances in QA, and prod.

I’d hazard a guess that maybe jobs can be parametrised to achieve this effect, but am not sure. A cursory search of online resources did not yield much information on this.


Not a direct answer, but see also: GitOps Workflow with Nomad

Hi @egmanoj :wave:

@marco-m pointed to some great discussions already, but the TL;DR is that you probably should start looking into Nomad Pack, which is the tool we’re building to help do just that.

Take a look at this Grafana pack for an example on how to do this.

1 Like

Thanks @lgfa29 :wave:

I must note that I haven’t worked with Nomad Pack at all. The file you linked to appears to be a job template, and the cpu/memory seem to be parametrised. Will investigate how this gets converted into a job, how the job is version controlled etc. Do let me know if there is anything else I should check out.

1 Like

I linked in the previous message as well, but just in case here is our tutorial. It’s a good place to get started :slightly_smiling_face:

1 Like

Of course you did. And I completely missed it :man_facepalming:


For those who visit this topic in the future: HashiCorp recently released a really nice Nomad Pack walk-through Nomad Pack Walkthrough - YouTube

1 Like