My attempt at Gitlab PR review environments with Nomad(blog.mattsbit.co.uk)
blog.mattsbit.co.uk
My attempt at Gitlab PR review environments with Nomad
https://blog.mattsbit.co.uk/2024/02/22/gitlab-ephemeral-environments-for-pull-requests/
9 comments
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.
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.
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.
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 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 ;)
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 ;)
Hey this is very cool.
I did something similar with Kubernetes, work has some OSE clusters that will generate DNS for you, it works great and the devs love using it. It’s a little bespoke but its simple and gets a lot of attention.
Plus since the namespaces preexist the workloads, we spin them up for the entire branch lifetime (times out after n days). Makes everyones jobs a lot easier.
Anything that helps shift lifecycle requirements and testing left has huge impact on DX.
I did something similar with Kubernetes, work has some OSE clusters that will generate DNS for you, it works great and the devs love using it. It’s a little bespoke but its simple and gets a lot of attention.
Plus since the namespaces preexist the workloads, we spin them up for the entire branch lifetime (times out after n days). Makes everyones jobs a lot easier.
Anything that helps shift lifecycle requirements and testing left has huge impact on DX.
One thing that I haven't out how to do is allowing unauthenticated Gitlab users to view deployments/environments for public projects.
Not only is the "deployments" tab missing (which isn't the _end_ of the world), but the environment (with the link to the instance) isn't shown in pull requests until the user logs in.
Does anyone know if this is possible? I couldn't find much in Gitlab's docs
Not only is the "deployments" tab missing (which isn't the _end_ of the world), but the environment (with the link to the instance) isn't shown in pull requests until the user logs in.
Does anyone know if this is possible? I couldn't find much in Gitlab's docs
Think it is only possible with public projects
It's definitely a public project :)
Edit: Ah, I found it - it's the permissions for 'Operations'
Edit: Ah, I found it - it's the permissions for 'Operations'
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
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)