Hacker News Reader

Comment by otterley | Hacker News Reader

> It lacks some CloudFormation features, like rolling updates. One of the great things about CloudFormation is the ability to update an AMI in a stack and have it roll out that AMI in a controlled way. In order to do this exactly the same way in Terraform, you need to learn how to do... CloudFormation.

Have you tried using `create_before_destroy` in a resource lifecycle block? Or are there issues with it that are difficult to work around?

View on HN

This works, but its critical you define "wait_for_elb_capacity" if this is in reference to an autoscaling group associated with an ELB serving any sort of inbound requests. Otherwise terraform will create the new resources, and then immediately terminate the old resources before the new resources are fully available ("f--- it, we'll do it live" mode).

This won't do a rolling deploy per se, it'll just bring up all new resources, wait for them to be healthy, and then terminate the old resources; if you want to do rolling changes, you'll need Cloudformation (or if its deploy-specific, tooling like Spinnaker).

It's also worth noting that rolling updates are a cloudformation primitive, so other tooling essentially recreates rolling updates.

What is the practical difference between the two methods? It seems like a "six of one, half a dozen of the other" kind of situation. Besides, building an entire replacement stack component before cutting over seems like a wise course of action to me (cache warming concerns aside) to avoid issues caused by inconsistency among peers.

The practical difference is that with Terrfaorm, once you've started your apply, you are committed. Rolling modifications allow you to stop and rollback if necessary.

I admit Terraform's DSL is superior to Cloudformation JSON/YAML, but Cloudformation wins on more powerful primitives for infra modifications.

Reply on news.ycombinator.com