I have a fairly simple GitHub action that deploys my Lambda functions in addition to updating the layers that they use. However after doing so, the functions continue to use the old version of the layer. I have to go in to the console and manually update the functions to use the new layers.
Is there any way to do this via the cli or similar?
I know it's possible to specify a layer and version for a function with that, but I can't see a way to automatically set it to the latest version of the layer.
Here's my current action for deployment, for reference - https://github.com/Jademalo/JadeBots/blob/aws-lambda/.github/workflows/lambda-deploy.yml
Related
i am new to AWS.
I need to create a Lambda function in AWS, but before it i need to review some code of previously created functions. But when i want to review code of function there's a message
The deployment package of your Lambda function "tes-GetInfo" is too large to enable inline code editing. However, you can still invoke your function.
Does anyone know is it possible to some how review it in AWS.
I was looking a lot but still haven't found any ways to do it here.
You can download your function code by exporting it, assuming your function was developed in some interpreted language like JavaScript/Python.
This can be done by doing an export to the function:
Go to your function and in the Actions dropdown select Export function:
Chose Download deployment package.
This will download the deployed function locally and you will be able to investigate your code.
I'm using CodePipeline to deploy my CloudFormation templates that contain Lambda functions as AWS::SAM::Functions.
The CodePipeline is triggered by a commit in my main branch on GitHub.
The Source Stage in the CodePipeline retrieves the source files from GitHub. Zero or more Lambda functions could change in a commit. There are several Lambda Functions in this repository.
I intend on running through taskcat for CloudFormation Templates and Unit Tests for Lambda Python code during a test stage and then deploy the CloudFormation templates and Lambda Functions to production. The problem is, I can't figure out how to differentiate between changed and unchanged Lambda functions or automate the deployment of these Lambda functions.
I would like to only test and deploy new or update changed Lambda functions along with my CloudFormation templates - what is the best practice for this (ideally without Terraform or hacks)?
Regarding testing: Best practice is actually to simply test all lambda code in the repo on push before deploying. You might skip some work for example with github actions that you only test the files that have changed, but it definitely takes some scripting and it hardly ever adds much value. Each testing tool has its own way of dealing with that (sometimes you can simply pass the files you want to test as an argument and then its easy, but sometimes test tools are more of a all-or-nothing approach and it gets quite complicatedreal fast).
Also, personally I'm not a big fan of taskcat since it doesn't really add a lot of value and it's not a very intuitive tool (also relatively outdated IMO). Is there a reason you need to do these types of testing?
Regarding deployment: There are a few considerations when trying to only update lambdas that have changed.
Firstly, cloudformation already does this automatically: as long as the cloudformation resource for the lambda doesn't change, the lambda will not be updated.
However, SAM has a small problem there, since it will re-package the lambda code on every pipeline run and update the CodeUri property of the lambda. And thus the lambda gets updated (even though the code might stay the same).
To work around this, you have several options:
Simply accept that SAM updates your function even though the code might not have changed.
Build SAM locally, and use the --cached and --cache-dir option when deploying in your pipeline. Make sure to push the folder that you set as cache-dir.
Use a different file packaging tool than SAM. Either some custom script that or something else that only pushes your code to s3 when the files have changed.
If you're into programming I'd suggest you take a look into CDK. It's a major upgrade from cloudformation/SAM, and it handles code bundling better (only updates when files have changed). Also the testing options are much wider for CDK.
I want to make a bot that makes other bots on Telegram platform. I want to use AWS infrastructure, look like their Lamdba functions are perfect fit, pay for them only when they are active. In my concept, each bot equal to one lambda function, and they all share the same codebase.
At the starting point, I thought to make each new Lambda function programmatically, but this will bring me problems later I think, like need to attach many services programmatically via AWS SDK: Gateway API, DynamoDB. But the main problem, how I will update the codebase for these 1000+ functions later? I think that bash script is a bad idea here.
So, I moved forward and found SAM (AWS Serverless Application Model) and CloudFormatting, which should help me I guess. But I can't understand the concept. I can make a stack with all the required resources, but how will I make new bots from this one stack? Or should I build a template and make new stacks for each new bot programmatically via AWS SDK from this template?
Next, how to update them later? For example, I want to update all bots that have version 1.1 to version 1.2. How I will replace them? Should I make a new stack or can I update older ones? I don't see any options in UI of CloudFormatting or any related methods in AWS SDK for that.
Thanks
But the main problem, how I will update the codebase for these 1000+ functions later?
You don't. You use lambda alias. This allows you to fully decouple your lambda versions from your clients. This works because you are using an alias of your function in your client's code (or api gateway). The alias is fixed and does not change.
However, alias is like a pointer - it can point to different versions of your lambda function. Therefore, when you publish a new lambda version you just point alias to it. Its fully transparent from your clients and their alias does not require any change.
I agree with #Marcin. Also it would be worth checking serverless? Seems like you are still experimenting so most likely you are deploying using bash scripts with AWS SDK/SAM commands. This is fine but once you start getting the gist of what your architecture looks like, I think you will appreciate what serverless can offer. You can deploy/teardown cloudformation stacks in matter of seconds. Also you can use serverless-offline so that you can have a local build of your AWS lambda architecture on your local machine.
All this has saved me hours of grunt work.
Simple explanation of my current infrastructure: I am using AWS Lambdas (running python code there), which are deployed via the Gitlab CI using serverless framework.
Explanation of situation: I currently have an AWS Lambda which uses a specific library version (for now say version 1.x.x). At some point in time, this Lambda will start using a new version of the this library (say 2.x.x), but I want both of these lambdas to be still deployed and available to handle requests.
If at some other point in time the version 3.x.x of the library comes, I want to keep the lambda using version 3.x.x and 2.x.x running (basically the current version and current version - 1 lambdas). Lets call them Lambda_NEW and Lambda_OLD.
AWS lambdas have the concepts of versions and aliases which could be used, but unfortunately they are not supported by serverless directly.
Note: serverless supports multiple versions (which cannot be named) and there is a plugin called serverless-aws-aliases which can set aliases for you, but that one refer to the actual AWS Lambda versions (see https://github.com/serverless-heaven/serverless-aws-alias/issues/148).
Do you have any idea on how to tackle it?
My only valid thought so far is to keep two branches (NEW and OLD) which will use two different versions of the library, and each branch will have its different deploy CI. This is very counter intuitive though, since I don't know how to maintain develop and master branches. Also, when to deploy to which stage etc.
Also I somehow want both Lambda_NEW and Lambda_OLD to be deployed on the same time (e.g. when switching to library 5.x.x, I want version 5.x.x to be in the NEW and version 4.x.x in the old)
I'm not sure from your post, but I gather that you want a way to handle canary deployments, so that you could easily roll back changes? If that's not the case, could you edit your question and provide a bit more clarity?
If that's the case, I'd recommend following this guide and using the canary-deployments plugin, which will automatically create aliases for new versions, and allows you to define how traffic is shifted between deployed versions.
I have a question about the lambda functions versioning capabilities.
I know how the standard way of versioning works out of the box in AWS but I thought there is a way for the publisher to specify the version number which would tag a specific snapshot of the function. More exactly what I was thinking of was including in the uploaded zip file a config.json where the version would be specified. And this would be used afterwards by AWS for tagging.
The reason I am asking is because I would like, for example, to keep in sync the version of the lambda function with the CI job build number that built (zipped) the lambda.
Any ideas?
Many thanks
A good option would be store your CI job build number as an environment variable on the Lambda function.
Its not exactly a recommended way to version AWS Lambda functions, but definitely helps in sticking to typical 1.x.x. versioning strategies and keeping them consistent across the pipeline.
Flipping the topic the other way around. Can we go with AWS Lambda versions 1.2.3., and then find a way to have our CI builds also use a single digit version no? Im not yet comfortable with this approach, and like the flexibility of 1.x.x as a versioning scheme to indicate major.minor.patch.
Standard Lambda versioning.
This is the most detailed blog I came across on this topic.
https://www.concurrencylabs.com/blog/configure-your-lambda-function-like-a-champ-sail-smoothly/
When you are deploying the Lambda function through CLI command or API, its not possible to give a custom version number. Its currently an automatically generated value by aws.
This makes it not possible to map the version number in a configuration file to the Lambda version supporting your use case.