Terraform: AWS: change the ami creates a new instance

[mzupan]

I'm trying to setup some backend infrastructure. If we update our AMI like doing a yum update then creating a new AMI and then add it to a var like

variable "ami" {
    description = "The ami to use"
    default = { 
        prod = "ami-d6b5b6be"
    }
}

The old instances with the old ami get destroyed and new ones are created. I don't think a ami change should always call for a new instance. Is there a way to say ignore changes for these set of keys if any are seen?

[radeksimko]

I'm considering that you're using the variable in aws_instance (EC2 instance).

What exactly do you expect to happen when you change the AMI? This is not a launch configuration in ASG where you could do a scheduled/on-demand rolling update and just change the config (AMI).

Have a look at the AWS API, it doesn't offer any way to update AMI:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html

The only chance to specify AMI ID is during the launch:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html

[mzupan]

I'm not asking to update the ami of a running instance.. i guess it would be nice to have a change in the ${var.ami} of a previously running instance not kill the instance to rebuild a new one. Since we tend to change the base ami every month or so it would tear down our whole infrastructure.

I mean i can write a tool to update the state json. I guess just throwing it out there if others have this issue also

thanks

[mitchellh]

This is difficult, because it really is working as intended. You're changing the AMI, then telling Terraform you want the AWS intances to have that AMI, and Terraform is correcting your declarative state.

Terraform is declarative: it is how you want your infrastructure RIGHT NOW. When you apply it, it gets you to that state.

I can see the use case, I suppose what you want is a way to ignore certain fields if they are already created.

We don't have any plans to do this ourselves, but would welcome any contribution here. In the mean time, please work around it by having multiple variables (with the old and new AMIs). It isn't the cleanest, but it is more corret: some set of instances are old, some set are new.

[mzupan]

@mitchellh thanks.. if I get time and can figure it out in a good manner, I'll work on an ignore option.

I was just putting it out there to see if others might find it useful. Thanks for the quick replies.

[jmvbxx]

I know this is an old ticket but I wanted to share my use case.

We have quite a large infrastructure built 100% in terraform starting back in January. Since that time we've been using the same ami. It's getting to the point that the base ami is too old and we need to update it.

As mentioned above, changing the ami will delete our entire infrastructure and rebuild it with the new ami. Of course this is not viable. Instead we have decided on a non-ideal solution which is to update our base ami every six months, rename the var and then update on an as need basis.

So, of course I would love to be able to simply say .. Give me all new instances with this new ami and leave all existing in peace. But I understand @mitchellh's point of view and appreciate the potential complexity of generating a solution.

Thanks to the entire Hashicorp team for all the awesome work!

[mzupan-rms]

@jmvbxx that's what the ignore_changes lifecycle is for in the resource

lifecycle {
    ignore_changes = ["ami"]
}

[jeremiegoldberg]

@mzupan-rms

THANK YOU !

You saved my day.

[oryband]

lifecycle { ignore_changes = ["ami"] }

this needs to be documented under a "scenarios" section in the offical docs or something similar.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.