In each of these posts, we explored different levels of interactivity and how the Serverless Framework helps you develop and deploy your AWS Lambda functions and .net core and C#. In this post, we are going to delve a little deeper again into one specific area of how you can create Environment Variables with the Serverless Framework and share them with the .net core executable.
This is a useful strategy to learn as it helps you to create easily configurable and maintainable infrastructure as code and helps to element those Magic Strings from your code base.
We are going to make use of the serverless.yml to create our environment variables so if you not all that familiar with it then I recommend reading the high-level serverless.yml reference but I will explain the features we’re going to use as I go through.
Environment Variables in Serverless Framework
The Environment tag in the Serverless Framework YAML file enables you to create service-wide environment variables which you can easily make use of in other programming languages, for instance in nodejs based lambda functions you could simply create an environment variable in your serverless.yml as follows
Environment:Variables:TABLE_NAME:SomeTableName
You can then simply reference and get the value from the environment variable in your code as follows
Once this is added we can now add an environment variable to our serverless.yml. We’ll create an environment variable called SaySomething and provide some arbitary statement.
service:Hello-Configurationprovider:name:awsruntime:dotnetcore2.1environment:SaySomething:"Eating coconuts is cool"package:individually:truefunctions:hello:handler:HelloConfiguration::Threenine.ConfigTest.Functions.Speak::Greetpackage:artifact:bin/release/netcoreapp2.1/hello.zip
We can then edit our LambdaConfiguration.cs to the below
If we build, deploy and invoke our lambda this will work fine. However, I’m sure the clean coders amongst you will be thinking that this is dirty and we have polluted the code base a little.
Adding Environment Variables to Dependency Injection
Next we’ll create a class that we will use to store the environment variable, we will make available to the classes in which will make use of it via dependency injection.
In this case it’s a very simple class which is going t have a property we will make use of later.
The .net core framework enables us to really easily now configure and bind these variables at runtime using the Environment Variables Configuration Provider , all that we now really do is rename our Environment Variable in our serverless.yaml to include the name of our Class and a double underscore
When working with hierarchical keys in environment variables, a colon separator (:) may not work on all platforms (for example, Bash). A double underscore (__) is supported by all platforms and is replaced by a colon.
service:Hello-Configurationprovider:name:awsruntime:dotnetcore2.1environment:SpeakEnvironment__SaySomething:"Eating coconuts is cool"package:individually:truefunctions:hello:handler:HelloConfiguration::Threenine.ConfigTest.Functions.Speak::Greetpackage:artifact:bin/release/netcoreapp2.1/hello.zip
Modify the StartUp class to configure the environment variables and wire them up for Dependency Injection we do this on line 20, which is similar to what we did previously.
The above example works great, however you may have still spotted an additional concern. Perhaps you’re thinking this is great but what if you wanted to have different configuration options for your specific environments. For instance what if you wanted data that is created in your staging environment be redirected to different tables or queues than the ones you use in the Production ?
Fortunately, the Serverless Framework provides a super simple option, a configuration for your serverless.yml. By convention, this is typically implemented by creating an additional env.configs.yml
Typically you’ll use this file to create Environment Specific configuration information or sensitive information. For instance, you may want to store your AWS Account ID or even version or feature information.
This file will most likely not be stored in your Source Code Repository and will probably be managed by your DevOps process. However, in my case I included it in the repo to provide a sample.
I’ll create a simple file to provide a general idea:
feature:<feature_name>version:1.0.0.0region:<aws_region>accountId:<aws_account_id>something:"Coconuts are cool to eat"
In our case we created a variable which we name something and provided an arbitrary value. We can now edit our serverless.yml to make use of this file
We now have an easy to configure Lambda and the ability to create environment variables within our Serverless.yaml and consume them in our .net core lambda.