Spin up disposable EC2 instances

moln: a VM start script

Life as a developer is challenging, and might be quite miserable at times, you have to install quite a bunch of software on your machine for disparate urges, sometimes just to be able to evaluate some configuration. And no, you probably don't want automatic updates if - for some reason - you need an older environment that reflects customer production.

You're likely to get quite some clutter on your main development machines after a while.

You also have Docker, of course, but as it turns out, if you work on a range of things and build/download images all the time, you'll quickly fill up your local disk.

So, even if you're not properly that kind of Cloud guy, you will appreciate being able to spin up virtual machines with your stuff, work on them for a couple of hours, save what you need and destroy them.

There are fancier way you could do this, of course. But we're not really up to copy-paste YML around here, nor excessively inclined towards Go-implemented seamonsters. We're not autoscaling a microservice we're just in need of a clean slate in order to explore some stuff for ourselves.

Wouldn't it be nice to start such a machine like that:

$ moln -s <image-flavour>

Where I had defined the flavour in a config:

~/.moln/machine-<image-flavour>.conf

We're not trying to reimplement Vagrant here, just a shell to spin up my machine: moln

That config might take some brainpower, bud I assume you'll end up reusing the same config for the same purposes. And of course, you want to have different models for different purposes, all living in your config directory.

An example config:

flavour=jdkimage
group_config=~/.moln/group-sg0001.conf
keypair=~/.moln/keypair-jdkimage.pem
ami_id=ami-030839b239f3ebcdf
image_type=t3.nano

Ok, before creating the image config, you will have to create a security group, like this:

moln -g sg0001

This all is expected to work towards AWS provided that you:

  •    have installed the AWS CLI 
    
  •    have a working CLI profile
    
  •    you have access to your AWS console and know how to destroy an instance if you don't want to have it running.
    

But in reality everything is done in a way that vendor-specific is abstracted away and relegated to the config files. In other words, I'll be likely to reimplement the start/stop options for Azure and Google, because of course using someone else's computer sucks, but being able of choosing whose that one should sucks less.

Also by default we want the image to be started to run some default script, like:

cat ~/.moln/script-jdkimage.sh 
#! /bin/bash

exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1

PACKAGES="sqlite3 openjdk-11-jdk-headless pandoc"

apt-get update

for p in $PACKAGES; do
  apt-get -y install $p
done

This is easier done than discussed.

A short synopsis of the implemented options:

moln -g <security-group>                : create <security-group>
moln -s <image-flavour>                 : start  a new instance of <image>
moln -k <profile><instance-id>          : terminate <instance-id>
moln -a <profile><instance-id>          : prints IP for <instance-id> in <profile>
moln -l <profile>                       : list instances for <profile>

I hope you like Moln or -at least- the ideas behind that.

Paolo Lulli 2021



[security]