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:

  • .NET 3.1 instructions here
  • AWS CLI here
  • AWS Lambda templates here

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

Popular posts from this blog

Tailscale ate my network (and I love it)

Image
No matter where you go, there you are If you're like me, you travel occasionally. Access to your office from home, or from an airport lounge, or from a hotel room is paramount to being productive for most of us now. While I had a fairly simple Tailscale setup that got me into my test machines in the office, what I really wanted was to integrate my AWS production VPC into that system. It's surprisingly simple. Tailscale AWS instructions What do you want to do that for? In the "before tailscale" times, if I needed to test against the production AWS resources or connect dBeaver for database maintenance, I would edit the security group to add my IP address, do my testing, edit the security group to remove myself. This is as error prone as it sounds. I quite often forgot to remove my IP address from the allowed addresses, a major potential security risk when you are travelling. Tailscale has an extremely nifty way to get around it: if you run up a small ec2 ins...
Read more

Stupid stunts with WSL2 , Python3 and AWS ECS

Image
Hand rolled CMS system gets a previewer The ongoing process of updating the help system on the SmartShepherd inspired two new features: editing of the html in a temporary location and a small web server to check your work before pushing it to production. The surprise? That GitHub desktop will show you a side-by-side view if you change an image file. Can't believe I didn't notice that before. Can you hold my camel for me? Sometimes I get so far down a dead end I don't realise how many issues could be sorted simply by re-thinking something. The initial deployment of the SmartShepherd web server was to an Elastic Beanstalk setup on AWS, mostly because I had no idea what I was doing. Elastic Beanstalk isn't really one product, it's more of an elaborate script that creates systems for you. In my case, it was spinning up a small Windows EC2 instance, installing the .NET Core website and auto-configuring a load balancer to point to that instance. I mean, it's...
Read more

Time machine: Solaris 2.6 on QEMU

Image
You can never go home A big chunk of my professional career in the 1990s was spent with a Sparcstation on my desk. Before that the 68000 Sun2 and Sun3 floated past my sticky fingers but the Sparc machines quickly superseded those. I don't remember too much about which ones: pretty sure there was at least one IPX, one Sparcstation 5, a Sparcstation 10 and then the last one was most likely an Ultra 1 or maybe even an Ultra 5. It was a long time ago. Every now and again I think about how productive those machines were and do a little Ebay digging on how much one would be worth to have around. Except I don't have the room for more machines and the idea of trying to revive 25 year old hardware from that era is well beyond my electronic capabilities. Never fear, QEMU is here. Following these excellent instructions from Adafruit , you too can install Solaris 2.6 and have your very own emulated machine. Note that there is one instruction in there I am not sure you need. A...
Read more