AWS SSM Agent on an RPi 4

So as part of the work I do with AWS DeepRacer I use SSM Agent on the cars and (finally) now also on the Raspberry Pi based timing system, to make things easier I thought I’d “quickly” install and activate SSM on the RPi so I can access them remotely and show the timer online as part of DeepRacer Event Manager (DREM – more on which in another blog post)

Installing SSM on a 32bit OS on an RPi Zero or 4 was easy, just works, however on a 64bit OS I was getting errors:

dpkg: dependency problems prevent configuration of amazon-ssm-agent:armhf:
 amazon-ssm-agent:armhf depends on libc6.

dpkg: error processing package amazon-ssm-agent:armhf (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 amazon-ssm-agent:armhf

Took me a while to find the answer as I didn’t happen to have the time to get an uninterrupted run at fixing the issue and more importantly testing the fix (because I was activating SSM as part of a scripted process) each attempt meant I needed to re-install the OS on the RPi to ensure it was working correctly.

Anyway, the solution was to install libc6:armhf so now my code to install SSM on an RPi 4 running 64bit OS is as follows:

sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install -y libc6:armhf

mkdir /tmp/ssm
sudo curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/debian_arm/amazon-ssm-agent.deb -o /tmp/ssm/amazon-ssm-agent.deb
dpkg -i /tmp/ssm/amazon-ssm-agent.deb
rm -rf /tmp/ssm

And once installed activate SSM as normal.

Hopefully this helps someone, and if not it will probably help future me.

AWS and a bit of Slack

So now that we’re able to have code deploying into AWS and notifications from Jenkins into Slack it would make sense if we could check what’s happening with Elastic Beanstalk when the code is deployed (and also get a heads up of any issues with our environments.)

So Lambda and SNS to the rescue, here’s what you need:

This post about Lambda and SNS as well as this updated code, which gets a mention in the comments.

Amazon Web Services (Jenkins)

Right so we have our handy services Virtual Private Cloud (VPC) with access via OpenVPN (and the awesome Viscosity OSX VPN Client) now we need to start adding useful things into it.

(See this blog post for info)

For me the next step was looking at how we could automate deployments using our own tool chain, part of the reason we are looking at AWS is to get a bit more flexibility and also the benefits of greater automation.  We’ve already had success using BitBucket -> Codeship -> Heroku as a work flow to make our code visible and available in readily shareable environment, and it took < 5 minutes to get it up and running ;-)

Continue reading “Amazon Web Services (Jenkins)”

Auto Start / Stop servers FTW

So one of the things I’ve always liked about AWS^WCloud based services is the ability to just spin up development instances and use them, however I’m generally working for between 8 – 10 hours a day and not so often at weekends, but during those hours my servers are running and not doing much, BUT as they are racking up costs (ok so not too much for a t1.micro but the point still stands) and I knew of companies shutting down unused servers during the night and weekends and thought I should give that a go.

So the first attempt at this uses a scheduled data pipeline to run an AWSCLI command to either stop or start servers, sadly due to the lack of complexity in the scheduler in the console (please AWS just put in a text box so I can add in a crontab line) the servers get started and stopped at weekends too, but I’ve now reduced the daily uptime by 14 hours a day, 98 hours a week or 5096 hours a year (you get the point) actually if you take weekends into a count it’s even more than this.

And to do this took 10 minutes thanks to this handy tutorial provided by AWS.

Amazon Web Services (VPC + NAT + OpenVPN)

So in the process of setting up a few bits and pieces on AWS and the first area (well second after a couple of quick deploys using Elastic Beanstalk) is to get a Jenkins server up and running.

So I’m looking to deploy the Jenkins box within a Virtual Private Cloud (VPC) to block off access to Jenkins and also any test slaves it will eventually spin up.  To ensure smooth access into the VPC I’m using OpenVPN.  First step is use the VPC wizard to create the basics, I went with the “VPC with Public and Private Subnets” as this handily creates the NAT Gateway box to allow servers inside the VPC to access the interwebs.

Continue reading “Amazon Web Services (VPC + NAT + OpenVPN)”