Debian day 4: AWS CLI, .NET and Lambda functions
How did I get so dependent on the GUI?
Visual Studio with AWS Explorer on Windows definitely makes you lazy. I mean, it's fantastic to be able to build and deploy something like a Lambda function by right-clicking on the project, but sometimes it's better to understand what is going on under the hood.
Despite which, I am now pretty committed to switching to Visual Studio Code now that I am able to build everything in a similar way. My major concern at this point was making sure that when working on Windows (which will still happen) that the build/test/deploy sequence is almost exactly the same as on Debian. I thought that perhaps I would have to pull a pile of stupid stunts like this with wacky hybrid scripts but then I remembered WSL2!
Windows Subsystem for Linux (version 2) is a proper Linux kernel running alongside your Windows system. I have been using it quite a lot when dealing with some hardware that we use, the Cassia Networks X1000 Bluetooth gateway. At SmartShepherd we are often faced with 500 or more Bluetooth LE devices we need to connect to in a short period of time and it's just not possible using the bluetooth stack on Android (or pretty much anything). I have a small server application that runs on the Cassia (they use Ubuntu containers) and the environment hosts SSH sessions and secure copy for testing new versions of this. Hence the Debian install of WSL2 was getting a workout.
However, because it's already installed I might as well go the whole hog and try to replicate the .NET environment I have on Chungus the Proliant here on BUSTER3, the Acer Nitro.
Documentation and Installation
In no particular order:
Install .NET 3.1 in your local directory. I use wget, you could use curl or just download it via your browser and copy it somewhere.
wget https://dot.net/v1/dotnet-install.sh
chmod 755 dotnet-install.sh
./dotnet-install.sh -c 3.1
Once you have .NET installed (it will end up in a hidden directory .dotnet in your home directory, you then edit the .bashrc to have the following last three lines:
export PATH="$PATH:$HOME/.dotnet:$HOME/.dotnet/tools"
export DOTNET_ROOT=$HOME/.dotnet
export DOTNET_MULTILEVEL_LOOKUP=0
Not really sure what that last one does, but the tools seem to require it if you have .NET installed in your user directory rather than globally. I prefer it installed just for me, not because there are 100 other users on my machine, more force of habit from a time when I did Unix system administration on large, multi-user machines and we always defaulted to local installs of unknown stuff until we trusted it. My mentor back then insisted that the root user remain unsullied and untouched, factory fresh, so that you were never locked out of your multi hundred thousand dollar machine. Seems a bit silly on something like the Proliant that owes me about $150 but old habits die hard sometimes.
Installing the Amazon CLI is straightforward although you might have to sudo apt-get install zip unzip, I didn't on Chungus, but I did have to on Buster3.
wget https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip
unzip awscliv2.zip
sudo ./aws/install
aws --version
Lastly, the AWS tools for dotnet and the dotnet lambda templates. All of this basically allows you access to the things you would normally right-click for in Visual Studio.
dotnet new --install Amazon.Lambda.Templates::5.4.0
dotnet tool install -g Amazon.Lambda.Tools
Well, yeah, but does it work?
The Amazon.Lambda.Templates are there for creating new Lambda functions, they create a file aws-lambda-tools.defaults.json in your .NET project root that you use to fill out things like the region where your lambda function is going, security stuff etc. that I won't go into here, because AWS have better documentation for it.
Suffice to say that it does work, so (for example) if you want to package up your .NET 3.1 Lambda function as a zip file ready to deploy, you head to the root of your project and do this:
dotnet lambda package
and sure enough, it creates the zip file. dotnet lambda deploy will replace the existing Lambda. Since I did all the above in parallel on both Chungus and Buster3, the environments are as close to identical as I can make them and I can now build and deploy my Lambda functions. Next stop: Docker deployment to ECS.
Footnote
The reason Buster3 got it's name isn't terribly interesting, but I'd like to record it for posterity. When I resigned to start SmartShepherd, I got home and realised I didn't actually have a laptop to work on. Work had provided a nice little HP Spectre but when I priced one up my jaw hit the floor. They are beautiful machines but too expensive for a struggling startup. One of my kids had a cast-off laptop they used for noodling on which was a relatively ancient Toshiba C650 with a broken hinge. It was broken so I called it BUSTER. It's specifications are unimpressive but it was enough to be able to run Ti's Code Composer Studio to the point where we had an MVP. As soon as I had a few dollars I replaced it with a new Acer Aspire E5-553 called BUSTER2 because why not. Being stupid, and wanting a bargain, I didn't look too closely at the specifications, it was cheap, had a dedicated graphics card and had 16Gb of memory. Later, when I needed to play with virtualisation for Docker, it turned out the stupid thing had all virtualisation disabled in the BIOS and also in the firmware! It took a gut-wrenching play with the firmware setup to get it working. I had sworn off Acer machines after that, although BUSTER2 earned it's name. Buster2 accompanied us to Shenzhen to be part of HAX10 and mostly did the job. He still carries the stickers from that journey.
BUSTER3 was something of an accident. We were travelling (pre covid of course) and BUSTER2 was giving me a lot of grief, the keyboard was playing up and Windows 10 Pro had ground to a near halt. I spied a 2nd hand Acer Nitro 5 in the window of a well known tech recycling chain and the price was right. Despite having publically sworn off Acer machines, the specs were too good to pass up. It's been fantastic, highly recommended if you need something affordable but high performance for dev work.
(Left to right) Buster, Buster3, Buster2
