Hacker News new | ask | show | jobs
by mrmattyboy 845 days ago
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.

1 comments

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...

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 ;)