3 ms·
terraform plan has the benefit of showing me whether what I did is at least internally logically consistent before making any attempts to change the state of th
by nanis 5y ago
terraform plan has the benefit of showing me whether what I did is at least internally logically consistent before making any attempts to change the state of the world. It doesn't mean things can't go wrong, but it is harder to make silly mistakes that are bound to happen when you try to inject logic into JSON or YAML which are just text.
"HealthCheck": {
"Target": {
"Fn::Join": [
"",
[
"HTTP:",
{
"Ref": "WebServerPort"
},
"/"
]
]
},
Sure, the equivalent terraform would not win a beauty context either but this is just an abomination. If someone is paying me well enough, I can live with it, especially if it worked perfectly, but it doesn't. Plus, standard CloudFormation crap Amazon will push on you tends to assume a bunch of things that may or may not be true in an account that has existed for a while before a particular feature became available.
- chrisoverzero 5y agoI’m not so sure that’s a great example, since it could be written like this: HealthCheck: Target: !Sub HTTP:${WebServerPort}/ CloudFormation also has changesets which you can inspect to see what will change and why before applying them. `aws cloudformation deploy` is not all of CloudFormation.
- nanis 5y agoI am not necessarily here to debate canonical or good CloudFormation ... I took one particularly unappealing snippet that does not reveal anything that I should not be disclosing from a bit of AWS provided CloudFormation. Regardless of how you write it, whether you write JSON or YAML, you are writing logic in pure text and the difference between that vs your code going through terraform's solver is night and day IMO. Plus, in source control, I find terraform diffs much easier to grok than JSON or YAML diffs. Especially since with the latter one misplaced invisible character can pass through without being noticed and cause disaster.