Recently AWS announced that lambda functions now support dotnet core 2.0. This is great news if you’re creating asynchronous functions that are meant to run serverless. There is a lot of good documentation out there on how to get started if you’re using the standard Windows 10 / Visual Studio setup. However, if you’re just getting started with the CLI tools and, like me, are using a Mac (either with VS Code or Visual Studio for Mac), sometimes the documentation is a sparse or is located is disparate locations.
Purpose
In this post, I’ll walk through the steps of getting a lambda function created and deployable via Jenkins. This assumes that you’re already comfortable working on your Mac (or Windows) creating basic dotnet core projects.
Creating Your Lambda Project
There’s good documentation on creating your first lambda project from the CLI that you should read through. The basic steps to get started are to first get the templates by installing them:
dotnet new -i Amazon.Lambda.Templates::*
And then generate a new template. A good one to start with is a lambda that will trigger from an S3 event, so I would typically use:
dotnet new lambda.S3
I use that as a starting point and re-structure the directory structure to suit my needs. I find it easier to have the solution file in the “root” of the repository, and then have subfolders for each library, lambda, or other unit of work. For example:
/MyProject MyProject.sln /MyLambda1/
Deploying to AWS
There are plenty of blogs on what you can do with your lambda, so I’m not going to focus on the implementation details of the lambda, but rather focus on how you can do deployments and automate your deployments.
Deploying from Development
The first step in testing your deployment is making sure that you can deploy from the command line from your development machine. If you started out with the templates, this should be ready for you out of the box. From your terminal, switch into your project directory (in my case that would be ./MyProject/MyLambda1) and run:
dotnet restore
dotnet lambda deploy-function NAME \
--function-role ROLE \
--profile PROFILE
Where
- NAME is the name of function as you want it deployed on AWS.
- ROLE is a pre-defined role that you created on AWS for your function. This is optional, but you will probably want to create a standard role for your functions depending on how you secure them.
- PROFILE is the name of a local profile that has your credentials to authenticate against your AWS account (I am going to write another blog about connections and profiles, as this can be a confusing topic for first time users). The short answer here is that the profile contains the access key and secret key that is used to connect to AWS. Previously this was information that was in your app.config or web.config file. It’s handled a little differently now.
So, for example, if I wanted to test my development deployment for a “Hello World” function, it might look like:
dotnet restore
dotnet lambda deploy-function dev-hello-world \
--function-role lambda-standard-role \
--profile codingtradeoffs
Once I confirmed that step, I would then go on to making a Jenkins job that also managed my deploys.
Deploying from Jenkins
So great. Assuming that we can deploy from the command line, then we can now work on creating out Jenkins job that will manage our production deploy. It’s going to follow the same steps, except that we need to manage our secrets. When doing local development, we can put our secrets in our ~/.aws/credentials file. But what do we do with Jenkins? Especially considering we might have multiple environments to manage.
Secret File
I wasn’t aware that you could have Jenkins manage “secret files” that get created for your build, until I read this blog by Emil. It’s worth reading though. You can use Jenkin’s credential management feature to have it securely manage your profile file. Once you go through the steps of setting that up, and setting up your test or production environment credentials, you’d end up with something that looks like this:
Emils blog goes through the process step-by-step, but if you follow Jenkin’s instructions for adding a secret file, it’s relatively painless.
Build Step
So then putting that all together, we can use the variable to tell dotnet lambda where our secret profile file exists. In the Build step, here’s the shell command we’d setup:
And there you go. You now have a secure want to manage your AWS lambda rollouts, using the very handy dotnet lambda functions execute the deploy.
Coding Tradeoffs 