[HN Gopher] Ignoring unwanted Terraform attribute changes
___________________________________________________________________
Ignoring unwanted Terraform attribute changes
Author : mrmattyboy
Score : 35 points
Date : 2025-03-23 18:09 UTC (4 days ago)
(HTM) web link (blog.mattsbit.co.uk)
(TXT) w3m dump (blog.mattsbit.co.uk)
| nick__m wrote:
| thanks, I learned something simple and useful ! I did not know
| about the null_resource.
| bmcgavin wrote:
| As tags aren't necessarily immutable, it's probably advisable to
| use the full hash in most situations anyway.
|
| This is a useful trick in situations where the image changing
| under your feet isn't very important.
| koolba wrote:
| You can have that indirection itself in a data element that
| does the lookup of the image and returns the digest:
| https://registry.terraform.io/providers/hashicorp/aws/latest...
|
| So the data element would lookup the tag, and the specific hash
| is used in the deployment. No funky replace triggers needed.
| mrmattyboy wrote:
| Sure, you're right in most cases. In the use-case I had, it's a
| private registry with "immutable" tags (at least enough to stop
| accidental overwrites - and it is a homelab, so if someone else
| did it, I'd have worse problems ;))
|
| The point was more about using null_triggers (or
| `terraform_data` I see) and using the trigger replacement, with
| the docker resources as purely an illustration.
| JohnMakin wrote:
| null_resource is being deprecated in favor of terraform_data:
|
| https://developer.hashicorp.com/terraform/language/resources...
|
| ~8 years in or so with terraform and I've found null_resource to
| be a useful crutch in doing things like, "take this source and
| compile it with this script that'll basically never change, then
| put it somewhere that's defined in terraform." Overly relying on
| this mechanism feels like terraform code smell to me, just from
| my personal experience, if that's even a thing.
| mrmattyboy wrote:
| Absolutely, needs-and-musts, it's certainly not a nice thing..
| but again, Terraform isn't a scripting language, so sometimes
| bits of hack are needed!
| RulerOf wrote:
| I've never used this provider, and while I do think you're right
| that the provider probably shouldn't change the attribute on you,
| the docs for the `docker_container` resource[1] suggest
| populating the `image` argument with the `image_id` attribute of
| a `docker_image` resource[2].
|
| This should give you a location to stick in the friendly name of
| a container that won't get clobbered by the provider.
|
| I do like the explanation you provided though, because this is
| the kind of puzzle you can't really solve with Terraform until
| you've run into it. I've never used the `replace_triggered_by`
| feature.
|
| [1]:
| https://registry.terraform.io/providers/kreuzwerker/docker/l...
|
| [2]: I was originally expecting `docker_image` to be a data
| source, but the resource seems to be the recommended method for
| this, and I didn't wrap my brain around the differences between
| the data source and the resource before writing.
| mrmattyboy wrote:
| Good point - I hadn't actually looked massively hard into
| solving it with this provider - I had to do it again for
| another use-case recently and decided to blog about it (and
| also try my hand at a short post).. but used this example from
| a while ago because it seemed much more relatable than the
| latest encounter :D
|
| I guess, assuming you're not building the image, whether you
| use the data source of image probably isn't too important
| (assuming the data source is able to lookup images that aren't
| present on the local machine :thinking:).
|
| Edit: and now I've seen that in the docker image resource, they
| reference using the data source to be able to track remote
| image SHA changes, in order to trigger an image re-pull :doh:
|
| Feels like we've gone full-circle with this :D
| shooker435 wrote:
| Great find and post.
|
| I've run into this exact thing. Luckily rebuilding a
| container doesn't cause downtime for us and 99% of our
| changes require rebuilding an image, so I've just left it as
| is...
|
| It is annoying though when we make a small infra change and
| have to wait for the container image to build...
| zanecodes wrote:
| Similarly, older versions (<3.0) of the provider had a
| `build` attribute for the `docker_registry_image` resource,
| which made it possible to build and publish an image to a
| registry, without causing unnecessary rebuilds if there was
| no local version of the image on the build host.
|
| Now you have to use the `docker_image` resource to build a
| local image on the build host, and then use the
| `docker_registry_image` resource to publish it to the
| registry. In a CI/CD scenario with ephemeral runners, there
| will never be a local version of the image on the build
| host, so the image will always be rebuilt on every
| Terraform run, even if there are no changes to it.
|
| It's a tricky problem to solve from a provider design
| standpoint, since building a Docker image necessarily
| creates a local Docker image on the build host, which may
| not be a desirable side effect for the
| `docker_registry_image` resource to have and raises other
| design questions with no universal answers (Should it
| delete the local image after building? What if there's
| already a local image with the same name/tag, but it's not
| in the Terraform state; should it use the existing one or
| build a new one and overwrite the existing one? If the
| `docker_registry_image` resource is removed, should any
| corresponding local images also be delete? etc.)
| captn3m0 wrote:
| I run docker over terraform on my homeserver and use exactly
| this invocation.
___________________________________________________________________
(page generated 2025-03-27 23:01 UTC)