AWS Lambda – Dev environment in 120 seconds
Tags: aws, serverless, lambda, dotnet
Published: 2021-09-28 09:39:46

---
title: AWS Lambda – Dev environment in 120 seconds 
published: true
description: Okay, despite roaring success we had with the previous attempt at this, setting up VS Code dev containers for AWS SAM proved to be quite a bit of a pain. &hellip; Continue reading &#8220;AWS Lambda Dev container in 120 seconds&#8221;
tags: aws, serverless, lambda, dotnet
canonical_url: https://blog.wiseowls.co.nz/index.php/2021/09/28/aws-lambda-dev-container-in-120-seconds/
cover_image: https://blog.wiseowls.co.nz/wp-content/uploads/2021/09/alternate-skate-_tH3YCjPCCE-unsplash-scaled.jpg
series: Dev containers for life
---

Okay, despite roaring success we had with [the previous attempt](https://dev.to/timur_kh/azure-functions-dev-environment-in-120-seconds-2a8n) at this, setting up VS Code dev containers for AWS SAM proved to be quite a bit of a pain. And we’re still not sure if it’s worth it. But it was interesting to set up and may be useful in some circumstances, so here we go.

Some issues we ran into
-----------------------

The biggest issue by far was the fact that SAM heavily relies on containers which for us means we’ll have to go deeper and use [docker-in-docker dev container](https://github.com/microsoft/vscode-dev-containers/tree/main/containers/docker-in-docker) as a starting point. The base image there comes with bare minimum software and dotnet SDK is not part of it. So, we’ll have to install everything ourselves:

```bash
#!/usr/bin/env bash

set -e

if [ "$(id -u)" -ne 0 ]; then
    echo -e 'Script must be run as root. Use sudo, su, or add "USER root" to your Dockerfile before running this script.'
    exit 1
fi

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
rm -rf ./aws
rm ./awscliv2.zip
echo "AWS CLI version `aws --version`"

curl -L "https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip" -o "aws-sam-cli-linux-x86_64.zip"
unzip aws-sam-cli-linux-x86_64.zip -d sam-installation
sudo ./sam-installation/install
echo "SAM version `sam --version`"
rm -rf ./sam-installation
rm ./aws-sam-cli-linux-x86_64.zip

wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt-get update; \
  sudo apt-get install -y apt-transport-https && \
  sudo apt-get update && \
  sudo apt-get install -y dotnet-sdk-3.1

# Installing lambda tools was required to get lambda to work while I was testing different approaches. It may have become redundant after so many iterations and changes to the script, but probably does not hurt
dotnet tool install -g Amazon.Lambda.Tools
export PATH="$PATH:$HOME/.dotnet/tools"
```


This is fairly straightforward: [install AWS CLI and SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install-linux.html) as described in the documentation, and then install [dotnet SDK](https://docs.microsoft.com/en-us/dotnet/core/install/linux-debian). All we need to do now, is call it from the main `Dockerfile`.

It also helps to pre-populate container with extensions we’re going to need anyway:

```json
"extensions": [
	"ms-azuretools.vscode-docker",
	"amazonwebservices.aws-toolkit-vscode",
	"ms-dotnettools.csharp",
	"redhat.vscode-yaml",
	"zainchen.json" // this probably can be removed
],
```


Debugging experience
--------------------

Apparently debugging AWS Lambda is[ slightly different](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/serverless-apps-run-debug-no-template.html) from Azure functions in a sense that it’s not intended for invocation from a browser but rather accepts an event via built-in dispatcher. We could potentially spend more time on it and get it to work with browsers but that looked good enough for the first stab.

Building up the winning sequence
--------------------------------

With all of the above in mind we ended up with roughly the following sequence to get debugging to work:

1. started with modified Docker-in-Docker template and added all tools
2. opened the container up and used AWS extension to generate lambda skeleton app (after a couple of failed attempts we settled on **dotnetcore3.1 (image)** template)
3. we then let OmniSharp run, pick up all C# projects and restore packages
4. after that we rebuilt container to reinitialise extensions and make sure we’re starting off afresh
5. Once we reopened the container, we use AWS extension again to generate launch configuration (it is important to let SAM know what version of dotnet we’re going to need. check out `launch.json` to verify)
6. And finally, we run it

Action!
-------

![screen capture of the process](https://blog.wiseowls.co.nz/wp-content/uploads/2021/09/AWSLambdaContainerDemo-1024x505.gif)As always, code is in [Github](https://github.com/tkhadimullin/vscode-dev-containers-aws-sam).