5 ms·

Ignoring unwanted Terraform attribute changes

36 points by mrmattyboy 2y ago

nick__m 2y ago
thanks, I learned something simple and useful ! I did not know about the null_resource.
bmcgavin 2y ago
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 2y ago
  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/docs/data-sources/ecr_image 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 2y ago
  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 2y ago
null_resource is being deprecated in favor of terraform_data: https://developer.hashicorp.com/terraform/language/resources/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 2y ago
  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 2y ago
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/latest/docs/resources/container#example-usage 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 2y ago
  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 2y ago
    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...
    - 2y ago

36 points by mrmattyboy 2y ago

thanks, I learned something simple and useful ! I did not know about the null_resource.

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 2y ago
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/docs/data-sources/ecr_image 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 2y ago
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 2y ago

null_resource is being deprecated in favor of terraform_data: https://developer.hashicorp.com/terraform/language/resources/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 2y ago
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 2y ago

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/latest/docs/resources/container#example-usage 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 2y ago
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 2y ago
  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...
  - 2y ago