Ansible & EC2 - Playbooks for orchestrating NetBSD into the cloud
As follower of my blog you have
seenthestepstowards
getting NetBSD instances started in Amazon's EC2 cloud
with a simple web application deployed on one EC2 instance
and the database on another one.

These blog articles were very detailed on purpose, to have full
logfiles available just in case needed. I have used these logs to
prepare my
pkgsrcCon 2013
talk about Ansible and Amazon's EC2, so things can be looked at
without actually running anything. As it turns out this was good,
because the 32bit NetBSD instances that I've used during my
pkgsrcCon demonstration actually decided to do a kernel panic, and the presentation
was a bit more on the theoretical side than I originally planned.

Ansible, EC2 and NetBSD final milestone 4 reached: Web and DB on separate VMs in the cloud
In the fourth and last step on my journey to use
Ansible
to bring a non-trivial system of a Web server and a DB server into
Amazon's EC2 cloud, this is the final step.
After starting out with a local VMware VM and making first steps
with Ansible and EC2, the
previous step was to push a single system
into the cloud. Now, the final step is to setup two distinct VMs, one
for the database and one for the webserver, and then make them known
to each other.

Make sure security groups are setup properly. We use one group
for the database server, and one for the webserver. This defines the
access permissions from the internet, and also allows to identify
systems for their individual configuration and also for connecting
them in the final step:

Close to optimum, but the last error is actually expectet: In
order for proper operation, the Database needs to grant the
webserver access, and the web server needs to know where the
database server is. So let's connect them!

This step is done by preparing a shell script on both systems, which
will then be ran to - depending on the system's security group - perform the
proper steps:

So much for this exercise. I'll talk about the ansible and euca2ools
packages at
pkgsrcCon 2013 in Berlin.
Join in if you're curious about
what the actual playbooks used in the above examples look like, or
stay tuned to find my presentation and all the data after pkgsrcCon
2013.

Ansible, EC2 and NetBSD milestone 2 reached: Instance preparation and communication
On my quest to use Ansible to get a NetBSD virtual machine into Amazon's EC2
cloud, I've previously
described
how I use ansible to prepare a local machine. Working from a basic NetBSD setup,
the system is setup for basic operation, the configured as both a database server
and a Web/PHP server to serve a small demo application.

Now the next step is to replace the VM with an Amazon EC2 instance.
I have previously written about how to manage Amazon/EC2 NetBSD instances,
and here are the steps that I make to first prepare an EC2 instance with NetBSD and Ansible,
and then use a regular Ansible playbook to talk to all my EC2 instances.
Note that the connection between the machines setup via euca2ools
and ansible is in the security group names. In this case,
the security group "ec2-webservers" is assumed to exist.

The terminated instances will be removed by EC2 eventually, and you can start all over.

With the above steps and the previous work to use Ansible to setup
a NetBSD system with basic configuration as database- and webserver
the next step is to put those two things together, and get a
(single) NetBSD machine into the Amazon cloud that serves as
both database and webserver.

Let's stay tune for this to happen!

Shameless plug:
I'll talk about the ansible and euca2ools packages at
pkgsrcCon 2013 in Berlin.
Join in if you're curious about
what the actual playbooks used in the above examples look like!

Talking to the cloud
After some more hacking, I have a basic understanding
of how to start Amazon NetBSD EC2 instances
using Ansible, fix the instances so they can be used
as targets for further Ansible commands, and then
actually talking to my herd of happy instances.

Here's a teaser:

Start EC2 instances, put them into ec2-webservers group.
Repeat the following command for more than one instance:

Ansible and NetBSD milestone 1 reached: playbooks for system config, web+db servers
In my quest to play with Ansible, I've reached my first milestone:
I now have playbooks that take a basic NetBSD installation,
configure it into a usable base installation, and then add
a MySQL database, Apache and PHP to use it as webserver,
and then deploy a simple web application.

The playbooks are too emberassing to publish, but here
are the steps to get things going:

Setup NetBSD 6.0 with "base" and "etc" set, also add "pkgin" from menu

After that, a simple "phptest()" page, phpmyadmin and
my simple PHP-based web application can be run.
Administration of the system is via SSH and sudo, root
logins were disabled in the first ansible playbook.

Now to tweak the ansible playbooks to look less ugly,
use variables, and then separate database and webserver into
two separate machines - all in preparation to move them
into the Amazon EC2 cloud. Stay tuned!

For the record, here's a log of the three ansible playbooks above,
starting from my basic NetBSD installation that already has pkgin
and ansible:

Playing with
ansible,
its "ec2" module came to my attention: it is intended to manage virtual
machines in Amazon's EC2 cloud. The idea is that you describe a system
with the property "needs to run in Amazon's cloud", and ansible then
starts the machine if it isn't there already. In order to get to the point
where this can be played with, a working version of the
euca2ools package was required first.

Packaging was mostly a no-brainer, and a package is currently under review and will end up in pkgsrc eventually.
The more interesting part was to verify if the pkg actually worked as expected.
This proved tricky for two reasons: 1) my overall lack of how to use the
Amazon AWS command line tools (ec2-ami-tools, ec2-api-tools), and 2) the
fact that euca2ools is mostly written for the Eucalyptus Cloud infrastructure,
which just happens to be compatible with Amazon AWS.
To give future parties something to google, here are the steps that to
fire up a NetBSD machine in the Amazon cloud.

How - Prerequirements

A login for Amazon Web Services (AWS) is required, of which the Elastic Cloud Computing (EC2)
Xen infrastructure is a part of. I won't go into details of this, please see
the NetBSD wiki or my article
``NetBSD in der Cloud'' in the German FreeX 5/2012 magazine, pages 58-63, for details.

Before starting, a few environment variables have to be filled
with authentication information.
Log into the Amazon AWS Console,
click on your name in the upper right corner to get to the
"Security Credentials" page, and create an access key if not already present.
Get the acces key ID and the secret key, and put them into environment variables EC2_ACCESS_KEY
and EC2_SECRET_KEY:

Next create and download a X.509 certificate - make sure to get both
the file with the private key (pk-XXXX.pem) as well as the file
with the public key (cert-XXX.pem). Set the environment variables
EC2_CERT and EC2_PRIVATE_KEY to thos files, respectively:

Last, euca2ools want to know what cloud infrastructure to use for
virtual machines (EC2) and storage (S3). Coming from the
Eucalyptus project, the tools can talk to
cloud servers running Eucalyptus, OpenStack and Amazon AWS.
Communication is via HTTP, and the environment variables
EC2_URL and S3_URL have to be set accordingly:

Inside one region, systems
are grouped together in "availability zones" - usually data centers
or separate security zones within (refer to the Amazon documentation
for details). To list the availability zones in one region, use
the "euca-describe-availability-zones" command:

Now that we have a basic overview of the cloud infrastructure
with its regions and availability zones, the next questions are
what hardware is available for running virtual machine instances on,
and what operating systems can be put on.

Amazon lists
available hardware configurations on their "instance types" web
sites. Sizes range from Micro Instances with 613MB RAM, up to two CPU
cores and no local harddisk (t1.micro) to Extra Large (XL) Instances
with 15GB RAM, 8 CPU cores and 1.690 GB local harddisk. Many more
configurations are available for situations that require much memory,
much CPU, much IO, or do cluster computing with CPU and GPU.

As for the operating system and software to put on those virtual
machine instances, there is a VERY wide choice available. The
"euca-describe-images --all" command lists all available optione:

In the output, the configuration is identified by the Amazon Machine
Identifier (AMI), e.g. "ami-7fc3c30b" for a NetBSD 6.0/amd64
instance. This image ID is required when defining what virtual machine
instance to start.

Note that the "euca-describe-images" command depends on the region
setting, so you will get (and need) different output depending on the
region that you intend your instances to run in.

Setup SSH Access

When starting a NetBSD AMI, access will be via SSH to the root
account. For that, a SSH key pair needs to be created with the
"euca-add-keypair" command. The command can write the private key to a
local file, be sure to protect it properly - it will be the only way
of access to the system! Other interesting commands when managing SSH
keys are "euca-describe-keypairs" and "euca-delete-keypair":

That's actually as complicate as it gets - one command that tells what
hardware to use (t1.micro - can be omitted, a useful default will be
chosen), what SSH key to use for the root account, and what machine
image (AMI) to use are all used here. In return, the command prints a
number of information from the freshly created instance. The one used
in the following commands is the "instance id", "i-2ed60264" in this
example.

When the above command was started, this is a good time to go back to
the Amazon AWS console and have a look at your instances - you will
find the one listed above there now, too!
Instead of the web-based console, the "euca-describe-instances"
command can be used:

Now this is all nice and dandy, but we have just created a NetBSD
machine in the Amazon cloud. Let's log in!!!1!

To do so, we need the private key file created with the
"euca-add-keypair" command, and the host name. The latter is available
in the list of instances - be sure to use the one within the
"compute.anazonaws.com" domain:

% ssh -i key-eucaHF.pem -l root ec2-54-228-22-143.compute.amazonaws.com
The authenticity of host 'ec2-54-228-22-143.compute.amazonaws.com (54.228.22.143)'
can't be established.
ECDSA key fingerprint is f7:a9:f6:21:fc:d2:0e:46:03:41:f8:d5:c1:72:92:28.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-54-228-22-143.compute.amazonaws.com,54.228.22.143' (ECDSA)
to the list of known hosts.
NetBSD 6.0 (XEN3_DOMU)
Welcome to NetBSD - Amazon EC2 image!
This system is running a snapshot of a stable branch of the NetBSD
operating system, adapted for running on the Amazon EC2 infrastructure.
The environment is very similar to one provided within a typical Xen domU
installation. It contains a small, autonomous environment (including a
compiler toolchain) that you can run to build your own system.
The file system is lightly populated so you have plenty of space to play with.
Should you need a src or pkgsrc tree, please use the "bootstrap" script found
under /usr to download them. You can also use the script to set up
binary packages using "pkgin":
/usr/bootstrap.sh [src|pkgsrc|binpkg]
This AMI sends email to the maintainer on first boot, to help get
an idea of what is in use at any given time.
You are encouraged to test this image as thoroughly as possible. Should you
encounter any problem, please report it back to the development team using the
send-pr(1) utility (requires a working MTA). If yours is not properly set up,
use the web interface at: http://www.NetBSD.org/support/send-pr.html
Thank you for helping us test and improve NetBSD's quality!
Terminal type is vt220.
We recommend that you create a non-root account and use su(1) for root access.
ip-10-226-194-20# uname -a
NetBSD ip-10-226-194-20.compute.internal 6.0 NetBSD 6.0 (XEN3_DOMU) amd64
ip-10-226-194-20# exit

From here, you are on your own - it's a NetBSD machine, after all.

One word of warning at this point: Amazon AWS is not for free (as you
should be aware from the Preparations step). If you do not need
machines any more, be sure to remove them from the cluster, else this
may drive up your bill for nothing! You can use the
"euca-terminate-instances" command to do just that:

% euca-terminate-instances i-2ed60264
INSTANCE i-2ed60264

When you look at the output of "euca-describe-instances" now, you will
see that the machine's state goes from "running" first to
"shuting-down" then to "terminated" - the cloud infrastructure will
eventually be cleaned up to not list the stale machines any more.

What's next?

As stated above, the whole goal of this exercise is to manage Amazon
EC2 images from ansible. Weekend's mostly over and we will see
where this journey is going. For the time being, I'm happy to hear
about any comments of you using NetBSD on Amazon's EC2, and of
my euca2ools package.