undefined | Better HN

0 pointsjdsalaro5y ago0 comments

Not OP, but I assume they mean your lambda-specific components and configurations such as IAM roles, accounts, the function itself and it's parameters are considerably long-lived in comparison to the actual code executed on top. You wouldn't be modifying your lambda-specific setup everyday. That, however, doesn't apply to the actual code, which might be modified several times a week or a day to incorporate MRs coming from different people.

0 comments

gingerlime5y ago

I’ve never used Terraform, but isn’t it “intelligent” enough to apply only the changes necessary?

idunno2465y ago

Yea, it’s that smart, but it’s a risk mitigation cause people make mistakes. You don’t really want the thing that casually you run many times a day to have the ability to accidentally delete your database. Security as well, our code deploy pipeline has less privileges than our terraform pipeline

felixhuttmann5y ago

The risk of accidentially deleting the database is real. However, it can be mitigated without introducing another tool by using a second terraform root module (with a corresponding second statefile). So you would have one terraform root module for foundational or stateful things like databases which rarely change and should never be accidentially deleted, and a second terraform root module that holds only the lambda. The former root module is applied only manually, the latter can run automated in a pipeline.

knowhy5y ago

The problem is that Terraform is stateful. Terraform will revert the Lambda code back to the state defined in Terraform when Terraform is applied after the code was updated outside of Terraform.

There is a way to mitigate this a by making Terraform ignore changes to the actual code of the Lambda.

j / k navigate · click thread line to collapse