Nomad: Improvement: interpolation ${local.git.tag} / ${local.git.branch} / ${local.git.commit}

Created on 22 May 2017  路  3Comments  路  Source: hashicorp/nomad

In a git flow workflow, the best practice for versioning, is to tag every release/packaged version of the service (binary, docker tag, artefact...). And closely link the nomad job with the service version.

Today, if we release a new version, we have to change the version number inside the nomad job, manually. If we forget, the running service may be out of date, or even, running with new environment variables.

It should be great to add an interpolation in a nomad job for getting the current branch name, tag name or commit hash of the repository where is executed the "nomad run".

Example:

task "my-api" {
      driver = "docker"
      config {
        image = "iadvize/my-api:${local.git.tag}${local.git.branch}${local.git.commit}"
      }
}

(some variables can be empty)

Executing a "nomad run" would automatically replace the docker tag, with the version of the current branch/tag/commit. No matter if the developer remember or forget to update it.

WDYT ?

My explanation may not be clear. Let me know if you need more details.

stagthinking themjobspec typenhancement

Most helpful comment

I'd like to +1 this. I have a very similar use case where apps get deployed multiple times a day, and they're referenced by the tag. Using this or a similar type of interpolation would allow me to place the spec in source control, and allow my deployer to issue an API/CLI call to nomad to run the job again, rerunning nomad's interpolator and picking up the new tag.

Even the ability to pull it from Consul KV would be incredible, something like (using the given example)

task "my-api" {
    driver = "docker"
    config {
        image = "iadvize/my-api:{{ key "/version/my-api" }}"
    }
}

That way, my deployer could make a POST to KV before talking to Nomad. Something like that would be awesome.

All 3 comments

Thanks for the well thought out feature request! The tricky part is it complicates interpolation by having a class of variables ${local.*} that are evaluated by the CLI and of no use to API users.

Generally we suggest people use their own templating tool to accomplish this kind of CLI-side interpolation, but I'll leave this issue open as it's definitely worth considering first class support for.

I'd like to +1 this. I have a very similar use case where apps get deployed multiple times a day, and they're referenced by the tag. Using this or a similar type of interpolation would allow me to place the spec in source control, and allow my deployer to issue an API/CLI call to nomad to run the job again, rerunning nomad's interpolator and picking up the new tag.

Even the ability to pull it from Consul KV would be incredible, something like (using the given example)

task "my-api" {
    driver = "docker"
    config {
        image = "iadvize/my-api:{{ key "/version/my-api" }}"
    }
}

That way, my deployer could make a POST to KV before talking to Nomad. Something like that would be awesome.

Thanks for the excellent use case @andrewmeissner. #1185 is the issue we've started consolidating jobspec templating requests under, so I'm going to close this issue. Please follow that one! These are all use cases we intend to support!

Was this page helpful?
0 / 5 - 0 ratings