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].<p>This should give you a location to stick in the friendly name of a container that won't get clobbered by the provider.<p>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.<p>[1]: <a href="https://registry.terraform.io/providers/kreuzwerker/docker/latest/docs/resources/container#example-usage" rel="nofollow">https://registry.terraform.io/providers/kreuzwerker/docker/l...</a><p>[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.
As tags aren't necessarily immutable, it's probably advisable to use the full hash in most situations anyway.<p>This is a useful trick in situations where the image changing under your feet isn't very important.
null_resource is being deprecated in favor of terraform_data:<p><a href="https://developer.hashicorp.com/terraform/language/resources/terraform-data" rel="nofollow">https://developer.hashicorp.com/terraform/language/resources...</a><p>~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.