3 ms·
I've been doing IaC in AWS since terraform 0.11 (now added Azure and AWS CDK to the mix). Most cloud providers (and don't get me started with software platform
by pid-1 5y ago
I've been doing IaC in AWS since terraform 0.11 (now added Azure and AWS CDK to the mix).
Most cloud providers (and don't get me started with software platforms) support IaC as a complete afterthought. The day you decide to use IaC, you will have chosen to spend your days fighting against their APIs to make things nice and immutable.
Moreover, most languages and tooling are rather immature. Things like secrets, testing, CI/CD, multi repo infra, collaboration, describing stuff that changes itself (e.g. databases that update automatically) are not well understood, solved problems.
Consequently I'm quite diligent when writing my infra as code nowadays. I reserve it for things that really play nice with immutability and are not likely to change all the time. Also, as the author says, not coupling infra code with apllication code is gold advice.
- chrisshroba 5y agoAny pointers to what you use instead for managing those kinds of corner cases like things that modify themselves?
- vageli 5y agoOne solution is adding the attributes you expect to be modified to ignored_changes in a lifecycle block[0], which instructs terraform to disregard changes to those attributes when calculating diffs for plan/apply. That allows you to specify a value for that attribute at creation time and allow for its subsequent manual/non-terraform-managed modification without causing "drift". [0]: https://www.terraform.io/language/meta-arguments/lifecycle https://www.terraform.io/language/meta-arguments/lifecycle