Category: Work

Bluemix Virtual Machines

bluemix-vm-header

The Bluemix platform is expanding from being a simple Cloud Foundry (CF) based PaaS, to one with a range of runtime platforms. Today you can pick one of: app, container or virtual machine (VM). I like to think of this as a continuum, sometimes you want the simplicity of an application – or the control of a virtual machine. The decision is really based on a number of factors, but as you gain more control over the environment you also take on more responsibility for securing and maintaining the environment.

If you don’t have a Bluemix account, then you’ll need one (there is a free 30 day trial).

vmtile

From your bluemix dashboard you should see the Virtual Machine (beta) button. Click on the Run Virtual Machines tile.

This in turn will take you to a sign up page which will allow you to submit a request to be enabled for VM access. Within a few minutes you should receive an email thanking you for your interest in virtual machines on Bluemix.

Now you must be patient while the elves that run the service get things ready and then send you another email indicating “You are now ready to start creating virtual machines on Bluemix!” — once you get this you’ll be ready to go.  It’s probably worth emphasizing the point that this is a service in BETA, so getting access might take some time, patience is a virtue.

Now let’s look at what it takes to create a VM on Bluemix. Login to Bluemix and click on the Run Virtual Machines tile (same path we took to sign up for access to the service). You should arrive at this screen

createvm

 

As this will be your first time, you’ll need to add a security key. This screen capture shows my key named “BluemixVM”.  To add a key, click on the +Add Key which appears under the Security Key box. You can choose to import or create a key. The easy path is to create a key – which will trigger the download of a key in your browser. I used BluemixVM as the key name and the file that was downloaded was BluemixVM.pem.

You can also upload an existing image – but to keep things simple, let’s pick Ubuntu 14.04 from the set of images that are available.

The last thing you need is to “Name your VM group” – for this post I’ll pick RooVM. Then it’s simply a matter of pressing the Create button. There are other options for size etc, but you can play with those another time.

[Insert Jeopardy ‘think’ music here..it’ll take a couple of minutes]

runningvmSo now we have a VM running in the cloud! You can see a public IP address has been assigned and it is using our BluemixVM security key.

Now let’s login, I’ll show examples from a linux machine and leave other OSes as an exercise for the user.

So now you’ve got a ssh session into the cloud based VM.

There are a couple of things you might want to do:

Let’s run a quick update to make sure that we’ve got all the latest patches

Set the default shell for your ibmcloud user

and change the last line to look like this

Let’s also install my favourite shell mosh.

Mosh
(mobile shell)
Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.

The VM image we’re using has an iptables firewall. However, ufw is also installed and being used to manage the firewall — the nice thing about ufw is that by default it will persist our changes. Mosh uses the same ports as ssh, but it additionally uses some UDP ports.

Note: the mosh installation appears to add some rules to /etc/ufw/applications.d but I don’t understand why ufw isn’t picking those up. Manually adding them as above works fine.

Now you can use mosh to connect (assuming you have mosh installed on your local laptop)

You still might want to combine mosh with tmux or screen as mosh doesn’t provide a scroll back buffer.

Last tweak – you might have noticed that sudo is providing a warning every time you use it

This is because the /etc/hosts file is badly formed. Edit it such that your hostname appears on the second line (we could probably replace ubuntu, but this is easy and won’t break anything). Below is my modified file

Now sudo executes without warning.

Footnote: this is a BETA service, don’t be surprised if some of what I show above does change. Please provide feedback via comments to this post and I’ll update accordingly.

Adding a package to boot2docker

Docker is seeing rapid adoption among the software development world. So far it seems to me a very nice way to make software installation much less painful, but there is still plenty of room for improvement.

If you’re running Linux then you can stop reading now. Docker is an abstraction layer over Linux Containers (LXC), they’ve also created a repository where pre-defined containers can be found – you can even add your own. LXC is cool stuff, but it does mean Docker runs Linux.

Windows and OSX users need to use boot2docker, a Tiny Core Linux virtual machine that has just enough stuff to run docker. This is a fine solution but often when people ask about missing tools inside of boot2docker, the answer is to install a container that has the tools you want and run inside of that container. Things quickly start to feel like Inception.

Boot2docker is based on Tiny Core Linux, so you can use the tce-load utility to install additional components if needed. So say we wanted to run Perl:

$ tce-load -wi perl5

You can sniff around the repository to figure out what packages are available.

There is documentation on adding a persistent partition to your boot2docker setup. This is useful if you want to run the tce-load every time you run without having to type it in each time. Getting this setup is a little bit fiddly, and if we’re clever we can do something a bit cooler.

Let’s build a custom boot2docker.iso file! The build process is nicely documented. We can use a Dockerfile to create our own iso with the packages we want.

Before we start, you will want to make sure that your boot2docker is running with enough resources. The default should be 2048MB which should work, you will also need enough disk space on /var/lib/docker/aufs inside boot2docker.  If you have problems consider changing your configuration.

Create a Dockerfile with the following contents:

FROM boot2docker/boot2docker

# Append indicator this is modified image
RUN echo "\nMy modified boot2docker.iso\n" >> $ROOTFS/etc/motd

# Install perl5
RUN curl -L -o /tmp/perl5.tcz $TCL_REPO_BASE/tcz/perl5.tcz && \
unsquashfs -f -d $ROOTFS /tmp/perl5.tcz && \
rm -rf /tmp/perl5.tcz

# build the iso
RUN /make_iso.sh
CMD ["cat", "boot2docker.iso"]

Then follow the boot2docker.iso build process.

$ sudo docker build -t my-boot2docker-img .
$ sudo docker run --rm my-boot2docker-img > boot2docker.iso

The FROM is used to declare the base image we want to start from. We’re building our new container on this base.

The RUN directive is executed against the current image at build time. In this case we can’t use tce-load since we’re not actually running Tiny Core Linux at this point, we’re running against the docker image we are building. This is why we’re doing the installation of perl manually. I based the installation from the boot2docker DockerFile.

The last two steps “build the iso” are lifted directly from the same boot2docker Dockerfile, these are the steps required to actually create the iso file.

Figuring out how to run the boot2docker.iso I’ll leave as an exercise for the reader.