Hacker News Reader

Comment by dastx | Hacker News Reader

Personally I wouldn't deploy the lambda code with the terraform. They inherently have different life cycles. In an ideal scenario you deploy some dummy code with terraform (just a hello world). And as a separate pipeline you deploy the actual code. Ideally, if your ci/cd supports it, you have two separate pipelines, each one only does it's thing if the relevant files have been edited, with the code depending on the terraform.

View on HN

This is how I do it. I have a file called “dummy.zip” with and empty file in it that lives in the terraform repo and that zip goes in to S3 on initial apply then CI pushes the built zip to S3 and calls the lambda update command via the CLI.

I’ve not yet had to juggle changes to the live lambda but I put in the bits to make it stamp out an alias so I can start using specific aliases to ensure new versions don’t automatically get picked up by downstream invocations. All of that has yet to be put in to practice for real.

Many people seem to think the same but I don't get it.

If you only want to change lambda's configuration without touching the code, Terraform will do exactly that since the source_code_hash hasn't changed.

Opposite is also true.

The problem is that using CD such as Codepipeline/Codedeploy it wants to use CloudFormation and SAM. I don't want to use either they are both terrible. So in the end I end up making a pipeline to build Lambda and deploy in CodeBuild. It would be nice if Amazon scrapped SAM and did something better.

That's where AWS CDK comes in, it's great. Infrastructure as (actual) code.

That’s what we do too. TF uploads a dummy file and ci/cd uploads the actual builds

> They inherently have different life cycles.

Can you expand on this?

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.

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

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

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.

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.

Reply on news.ycombinator.com