[mdaniel]

heh, terraform is just ... special

  resource "nomad_job" "terrareg" {
    jobspec = <<EOHCL
  job "terrareg" {

but to be actually constructive, a fun trick is that one can patch this stanza in via the GL pipeline and thus allow local $(tofu plan) runs without needing, or running the risk of, live gitlab credentials

  variables:
    # Backend required for Gitlab state
    BACKEND_TF: |
      terraform {
        backend "http" {
        }
      }
  before_script:
  - echo "$BACKEND_TF" > backend.tf

it may also interest this audience that due to gitlab's in-container shell detection scheme, often a better entrypoint override is entrypoint: ["/usr/bin/env"] (assuming such a thing exists, of course)

[mrmattyboy]

Hey :)

That's a good idea for the backend - thank you!

And yes, I should have used the used a separate HCL file for the nomad_job - aside from being cleaner, it would have also avoided some horrific JSON encode that I had to use for an environment variable (think: `env { blah = eplace("\"", "\\\"", jsonencode(local.something))`), since I could just pass the jsonencode value straight to the value of the parameter, rather than getting Terraform to convert it to a string for the template.

[neomantra]

Thanks for sharing this; happy to see the spreading of Nomad insights. I had once upon a time done this with GitLab and Kubernetes, but now that I switched to Nomad, I lost that... will explore this further.

I manage a lot of these sorts of templates... I "Terraform template" the "Nomad Job", which also sometimes has its own Nomad template stanzas. [1] Separating it all makes things easier to track, although I suspect that when you have that scaffolding set up, you don't need to look at it or modify it much.

If I know I want something JSON, then I include "_JSON" in the variable name and then it's clear I should have a `jsonencode` there. [2]

[1] https://github.com/neomantra/terraform-nomad-temporal/blob/m... [2] https://github.com/neomantra/terraform-nomad-temporal/blob/m...

[mrmattyboy]

I do completely agree - the main problem I had was that, I tried doing this whilst writing the blog post side-by-side and was aware that the more complex it became, the harder it would be to show it. If I'd use separate files for the HCL then I'd need to show them both (and I think adding a little bit of cognitive complexity to read). So then adding templates etc, would increase that more.

I know for the "creating a server", I just used a module, but all it's meant to say is "I created a machine" and how I did that probably wasn't that important (apart maybe any tiny fragments of useful information with the variables), so I left it as a module. Same with the nomad setup - but at the same time, for what I was trying to achieve, running `nomad agent -dev` would have sufficed, so was somewhat happy with skipping it and showing the module call as "nomad was setup".

So for the remainder, I tried to prefer simplicity and readability, rather than "this is the best way to write Terraform and dynamic modules".

But, I completely agree with you :) Given the nature of the project it's in the pipeline for - I can certainly saying that I like a good Terraform module ;)

[jen20]

Not really sure what's wrong with the Terraform example, other than the lack of use of the heredoc with hanging indents, which would correctly nest the job spec.