Tags and run_tags

Packer
1

Hey all.

Im using packer to build an AMI in AWS. I’ve been reading about tagging my AMI and the running instance. The two methods are ‘tags’ and ‘run_tags’.

Unfortunately ‘run_tags’ are also inherited by the finished AMI, but in my scenario I don’t want this to be the case. I do require specific run_tags to perform some of the provisioning of the AMI, but I don’t need them on the final AMI.

Is there a way to separate these two?

I found this issue where they made the change to always include run_tags on the final AMI, but no way not to.

Thanks!

2

I have a similar use case, and also don’t see any way to do this. (Would like to add some tags to builder resources to ensure they are cleaned up in case of aborted build, but not to the AMI itself).

3

This is an old thread, but I thought I’d reply in case it helps somebody else.

We set the Name tag like this:

  run_tags = merge(local.default_tags, {
    Name = "packer builder (mycorp-base-al2023)"
  })

  tags = merge(local.default_tags, {
    Name = "mycorp-base-al2023"
  })

The resulting AMI gets the name tag mycorp-base-al2023. The EC2 instance used by packer gets the name tag packer builder (mycorp-base-al2023), which is handy so we can identify some of the random EC2 instances running in our build account.

Sometimes we have pipeline jobs that are abruptly terminated. Those sometimes result in stopped EC2 instances, so the run_tags are helpful to identify those as well.

When doing some AMI management, we found some AMIs with the name tag packer builder (mycorp-base-al2023). This was surprising to us, because we don’t ever intend to create AMIs with this tag.

Best I can tell, packer uses the run_tags during the AMI creation, and once the creation is done, it applies the tags to the AMI. If the packer job is abruptly terminated at the right time, the AMI might be created, but the final tags won’t be applied.

So I think this could help @tpensyl. Just define your tag both in run_tags and tags, but with different values. Your cleanup code can look for the value from the run_tags. Any fully completed AMI builds will not have this value.

4

Thanks @ jpriebe . That’s what we ended up doing, too. In our case, we wanted a custom optional tag (e.g. delete_after_2h:true) on the builder, and to omit the tag entirely from the ami. As this wasn’t possible, we settled for overriding the tag on the final AMI with a nonfunctional value.