How can I update the $LATEST version of a lambda to a previous one, including all configurations?
Exporting the lambda version and uploading it, indeed update the code but not all configurations, e.g., Layers, File systems, etc.
Related
I receive the following warning from AWS, but I don't know how to fix this problem.
My understanding, I'll have to upgrade my local computer Node version to version 14, then re-build my application and push up again to AWS.
Description: Checks for Lambda functions that are configured to use a runtime that is approaching deprecation or is deprecated. Deprecated runtimes are not eligible for security updates or technical support.
My question, do I have to rebuild my application using Node version 14 or something simple like change the runtime version in AWS Lambda?
It is not about local build. Each lambda has a language environment. Change your lambda environment/setting/config.
When I'm in AWS --> Lambda > Functions > myFunctionName, whenever I edit the Code and then run the Test (clicking on Test button to Left of Deploy), it is running the test on the old (deployed) version of the code. This happens whether or not I File > Save first.
This is easy to confirm by just adding a console.log("blah"); and seeing that it does not appear in the Test output.
The Test > Execution Results also confirm the test is running on $LATEST (see bolded section):
Response
null
Function Logs
START RequestId: <snip> Version: $LATEST
<snip>
Of course I can test my version by deploying it, but isn't there any way to test BEFORE I deploy? (Sorry if this is an ignorant question - I feel I'm missing something dead obvious...)
Assuming you are doing it via AWS Console.
In the console, only LATEST is available for editing.
And for testing the function you need to deploy a version.
Lambda function versions
You can change the function code and settings only on the unpublished version of a function. When you publish a version, the code and most of the settings are locked to maintain a consistent experience for users of that version
You can test separately by publishing versions Lambda function versions
You can Lambda function aliases
for better handling these versions.
Configuring functions in the console
Please point me to the documentation where AWS defines $LATEST of the lambda version, or suggest that it is how AWS uses a terminology without defining it.
Clearly AWS lambda documents say $LATEST is a version.
AWS Lambda Function Versions
If you haven't published a version of the selected function, the Versions panel lists only the $LATEST version.
Initially I thought it is like HEAD tag pointing to the latest commit in a Git branch. Git commit is immutable, but lambda version is not.
AWS Lambda Function Versions
A version can be published one which is persistent.
The system creates a new version of your Lambda function each time that you publish the function. ... When you publish a version, the code and most of the settings are locked to ensure a consistent experience for users of that version.
But also it can be unpublished that can be changed and saved.
You can change the function code and settings only on the unpublished version of a function.
So I guess is, since I could not find the definition by AWS, that $LATEST is a temporary snapshot of code+runtime+setting which someone has saved at some point in an AWS account, and has not yet been updated and saved.
I suppose it is like work-in-progress transient artifact in a local git repository. We would not know what the code is because someone may be saving it, and we never know what we are executing if we do not use a published, hence immutable, version as the qualifier at invocation.
And personally believe a version should be immutable. It should not be mutable like Lambda $LATEST. Version 1 as of March 19 3PM or version 1 as of March 20 1PM do not make any sense to me. Version 1 must be unique. If change is made, the it must be version 1.1 or 2.0.
Invoke
POST /2015-03-31/functions/FunctionName/invocations?Qualifier=Qualifier HTTP/1.1
Please advise if this is correct understanding, and we should not use $LATEST for invocation unless only one person is working on and testing.
And if it is so, I suppose having $LATEST serves no practical purpose in a proper engineering where we should be able to consistently identify a revision of a code and reproduce the same result if we re-do the same procedure on the revision.
Update
Currently I believe my confusion was because of the inconsistent and possibly wrong naming by AWS.
Version is immutable if published but mutable if not published in which case called $LATEST.
Version can be a snapshot of a lambda function but it can be a integer number.
$LATEST is pointing to the last saved lambda function which can be changed anytime, hence we cannot know for certain what we are executing or looking at if we use $LATEST. $LATEST I see could be different from what someone else sees. It looks to me working on $LATEST is working on a moving target.
AWS has so many strange "gotchas" like ECS capacity provider is immutable and cannot delete once created and if the ECS cluster is deleted, that capacity provider remains there and invisible, causing errors when trying to create a new capacity provider for a new ECS cluster with the same name (the bug which called "as designed" finally fixed though). I believe $LATEST is one of them.
Based on the comments, the following helped to clarify the issues:
When you refer to "version" in lambda you usually mean "published version" (e.g., 1, 2, 3) which is immutable. $LATEST is simply most recent "unpublished version" which you can change at will. You keep working/testing on $LATEST till you are satisfied with it. Once you are happy, you can "freeze" it by publishing it. At the time it becomes immutable version no. 1, for instance.
Since versions are immutable, aliases are normally used in your clients code. The aliases can be changed to point to different versions whenever you publish new version of your function. If versions were mutable, or could somehow be "unpublished", aliases would be rather pointless.
I have AWS Bot with some intents and Lamda function. I need a seperate platform for stage and production release.
When I change any intent or lamda function it can't affect in production BOT Build,only affect in stage build.
How it possible?
How can manage the Lamda function?
I have tried with the AWS BOT Alias and version. But don't know how to handle Lamda function
Lex Versioning and Aliases
A version is a numbered snapshot of your work that you can publish for use in different parts of your workflow, such as development, beta deployment, and production.
An alias is a pointer to a specific version of a bot. With an alias, you can easily update the version that your client applications are using. For example, you can point an alias to version 1 of your bot. When you are ready to update the bot, you publish version 2 and change the alias to point to the new version.
When you version an Amazon Lex resource you create a snapshot of the resource so that you can use the resource as it existed when the version was made. Once you've created a version it will stay the same while you continue to work on your application.
$LATEST is the working copy of your resource. You can update only the $LATEST version and until you publish your first version, $LATEST is the only version of the resource that you have.
So you create a Lex Bot and are always working on the LATEST version.
Any changes you make only affect the LATEST version.
You cannot make changes to older versions of your Bot.
When you build the bot, a new version is automatically created, incrementing the version number by 1.
When you publish the bot, you will be able to select which Alias should be updated to this new version.
You can create an Alias and set or change the Version number in the Settings tab.
Lambda Function Versioning and Aliases
Conceptually, an AWS Lambda alias is a pointer to a specific Lambda function version.
When you publish a version, AWS Lambda makes a snapshot copy of the Lambda function code (and configuration) in the $LATEST version. A published version is immutable. That is, you can't change the code or configuration information.
Each time you publish a version, AWS Lambda copies $LATEST version (code and configuration information) to create a new version.
Match Lex Version to Lambda Version
Back in the Lex Console, you are able to specify by a dropdown menu which version or alias of the Lambda Function the Bot intents should use.
So keep your In-Development alias in $LATEST versions of both. Then also create a Production alias for both the Bot and Lambda and keep your Production bot pointed to your Production Lambda alias.
If I try to use boto3 Lambda create_function() to create a Lambda function, and I try to include Layers via Layers=['string'] parameter, I get the following error message:
Unknown parameter in input: "Layers", must be one of: FunctionName, Runtime, Role, Handler, Code, Description, Timeout, MemorySize, Publish, VpcConfig, DeadLetterConfig, Environment, KMSKeyArn, TracingConfig, Tags
... any ideas? The documentation suggests that this should work, but something is clearly off here. NOTE: I also have a similar problem with "Layers" in update_function_configuration() as well.
My guess is that the version of boto3 that the AWS Lambda console uses has not been updated/refreshed yet to support Layers. Because when I run the same code locally on a machine with a fairly recent version of boto3, it runs without any problems. I have already tried using both listed Python runtimes of 3.6 and 3.7 that in the AWS console, but neither worked. These runtimes have respective versions of boto3 of 1.7.74 and 1.9.42. But my local machine has 1.9.59. So perhaps the addition of Lambda Layers occurred between 1.9.42 and 1.9.59.
My guess is that the version of boto3 that the AWS Lambda console uses has not been updated/refreshed yet to support Layers.
That's completely right. AWS usually updates the available libraries on AWS Lambda regularly, but hasn't updated them for several months now for unknown reasons.
The supported API endpoints are actually not defined in boto3, but in botocore.
Currently botocore 1.10.74 is available on AWS Lambda, while support for AWS Lambda Layers got added in botocore 1.12.56.
To avoid such incompatibilities between your code and the versions of available libraries, you should create a deployment package containing boto3 and botocore in addition to your AWS Lambda function code, so your code uses your bundled versions instead the ones AWS provides. That's what AWS suggests as part of their best practices as well:
Control the dependencies in your function's deployment package.
The AWS Lambda execution environment contains a number of libraries such as the AWS SDK for the Node.js and Python runtimes (a full list can be found here: Lambda Execution Environment and Available Libraries). To enable the latest set of features and security updates, Lambda will periodically update these libraries. These updates may introduce subtle changes to the behavior of your Lambda function. To have full control of the dependencies your function uses, we recommend packaging all your dependencies with your deployment package.