Recently, had a chance encounter with lambdas and dotnet. AWS SAM provides a pretty good hello-world for dotnet application. So, I gave that a chance and below are some of my findings.
Table of Contents
Dotnet SDK
Currently, SAM works with dotnetcore2.0 and dotnetcore2.1. And the latest available version of dotnet SDK is 3.1. In order to work with the hello-world example of AWS SAM with dotnet, you would need at least sdk version 2.1 installed on your machine (I was able to make it work with sdk 3.1 too).
Dotnet Tools
You might also want to install aws dotnet tools. These are required by sam to create, build and deploy the lambda functions. If you don't have them installed, then you can do so by
dotnet tool install -g Amazon.Lambda.Tools
If you get an error that dotnet not found, then you might want to check the location /usr/local/share/dotnet/dotnet. This needs to have symlink to /usr/local/bin. In order to do that, just run
ln -s /usr/local/share/dotnet/dotnet /usr/local/bin
While running sam build, you might run into the following issue:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-xyz does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
To resolve it, add the following $HOME/.dotnet/tools to your PATH variable. This should do it, export PATH=$PATH:$HOME/.dotnet/tools
SAM Build
Now when you run sam build, it will build the code and put the compiled files into .aws-sam/build directory and will also create the package to deploy to aws lambda via sam deploy. If all of your setup is correct, then you can either invoke this lambda locally via sam local invoke OR deploy it to AWS via sam deploy -g.
Dotnet Publish
If you don't want to run the sam build and have some more control over how you build your code, you can do that via dotnet publish. With this you can provide more options like runtime, configuration etc for the build. Also you can specify an alternate location for the output files. Only other thing you would need to do is that you will have to manually create the zip file to deploy to lambda. You can do that by using any compression tool (zip for unix, for eg.).
Dotnet Lambda
Another way you can do is via dotnet lambda. This feature is available via Dotnet Tools. Using this, you can combine the build and package steps together. This creates the deployable package which you can either deploy to lambda manually or via the tool itself (dotnet lambda deploy-function).
These were some of my findings and being an alien to dotnet universe, these things were very frustrating and tricky to resolve. So, thought of putting it all together in one place.
Sample code can be found here
dotnet-sam
This project contains source code and supporting files for a serverless application that you can deploy with the SAM CLI. It includes the following files and folders.
- src - Code for the application's Lambda function.
- events - Invocation events that you can use to invoke the function.
- test - Unit tests for the application code.
- template.yaml - A template that defines the application's AWS resources.
The application uses several AWS resources, including Lambda functions and an API Gateway API. These resources are defined in the template.yaml file in this project. You can update the template to add AWS resources through the same deployment process that updates your application code.
Deploy the sample application
The Serverless Application Model Command Line Interface (SAM CLI) is an extension of the AWS CLI that adds functionality for building and testing Lambda applications. It uses Docker to run your functions in an Amazon Linux…
.
Top comments (0)