Nomad Provider

HashiCorp Nomad is an application scheduler. The Nomad provider exposes resources to interact with a Nomad cluster.

Use the navigation to the left to read about the available resources.

Example Usage

# Configure the Nomad provider
provider "nomad" {
  address = "http://nomad.mycompany.com:4646"
  region  = "us-east-2"
}

# Register a job
resource "nomad_job" "monitoring" {
  jobspec = file("${path.module}/jobspec.hcl")
}

Argument Reference

The following arguments are supported:

The headers configuration block accepts the following arguments:

An example using the headers configuration block with repeated blocks and headers:

provider "nomad" {
  headers {
    name = "Test-Header-1"
    value = "a"
  }
  headers {
    name = "Test-header-1"
    value = "b"
  }
  headers {
    name = "test-header-2"
    value = "c"
  }
}

Multi-Region Deployments

Each instance of the nomad provider is associated with a single region. Use alias to specify multiple providers for multi-region clusters:

provider "nomad" {
  address = "http://nomad.mycompany.com:4646"
  region  = "us"
  alias   = "us"
}

provider "nomad" {
  address = "http://nomad.mycompany.com:4646"
  region  = "eu"
  alias   = "eu"
}

resource "nomad_job" "nomad_us" {
  provider = nomad.us
  jobspec  = file("${path.module}/jobspec-us.nomad")
}

resource "nomad_job" "nomad_eu" {
  provider = nomad.eu
  jobspec  = file("${path.module}/jobspec-eu.nomad")
}

Configuring Multiple Tokens

Nomad supports passing a Vault or Consul token during job registration; this token is used only to verify that the submitter has permissions to access the Vault or Consul SI policies used in the Nomad job. When running the Nomad CLI, this token can be provided in a number of ways:

For Vault:

For Consul:

When using the Nomad Provider to register Nomad jobs, the options are similar:

There are two problems that arise. The first is that we likely want to avoid putting these tokens into Terraform files where they may be inadvertently distributed. The second is that different Nomad jobs might require different tokens, each with access to a different set of policies. In this case, there are a few different strategies for managing the tokens and ensuring that the correct token is used for a particular job.

One approach is to use provider aliases, creating a Nomad Provider for each token:

provider "nomad" {
  alias = "a"
  vault_token = var.vault_token_a
  consul_token = var.consul_token_a
}

provider "nomad" {
  alias = "b"
  vault_token = var.vault_token_b
  consul_token = var.consul_token_b
}

resource "nomad_job" "job_a" {
  provider = nomad.a
  jobspec = file("${path.module}/job_a.hcl")
}

resource "nomad_job" "job_b" {
  provider = nomad.b
  jobspec = file("${path.module}/job_b.hcl")
}

The tokens can be passed from the command lines as variables:

$ terraform apply  -var vault_token_a=s.lraLq3axH9mkbdVRkWS6H06Q  \
                   -var vault_token_b=s.koqvVqdAkG8yt7irxDdmIQiC  \
                   -var consul_token_a=fc0ff975-e845-4140-804c-c348e9414ff8 \
                   -var consul_token_b=aed18d86-dd9d-4029-8a7a-906f6bba640a

The downside here is that it requires creating multiple Nomad provider aliases and specifying the desired alias for every job resource. Another approach is to inject the tokens into the jobspec using templatefile:

resource "nomad_job" "job_a" {
  jobspec = templatefile(
    "${path.module}/job_a.hcl.tmpl",
    {
      vault_token = "s.lraLq3axH9mkbdVRkWS6H06Q"
      consul_token = "fc0ff975-e845-4140-804c-c348e9414ff8"
    }
  )
}

resource "nomad_job" "job_b" {
  jobspec = templatefile(
    "${path.module}/job_b.hcl.tmpl",
    {
      vault_token = "s.koqvVqdAkG8yt7irxDdmIQiC"
      consul_token = "aed18d86-dd9d-4029-8a7a-906f6bba640a"
    }
  )
}

This approach has the benefit that only jobs requiring a token need to be modified.