Aws

Running a Midas in AWS

Use Case

Create an EC2 instance running Ubuntu, bootstrap it to run Puppet, provision a Midas instance with Puppet.

Motivation

Run Midas in the cloud, which enables dynamic resource allocation and flexibility.

Background

Amazon creates EC2 instances based on OS Amazon Machine Images (AMI). AMIs come from OS providers and can be bootstrapped for different purposes.

Ideally we will have a bootstrapped image for our instances, but in lieu of that, we can boostrap the box through scripts.

Requirements

• An AWS account and credentials ( AWS_ACCESS_KEY, AWS_SECRET_KEY, account_name.pem)

• A copy of the bootstrap.sh script from this repo (unfortunately you'll need to have this file and then later clone this repo on the EC2 instance).

Provision an EC2 EBS instance with Midas using boto

We will use the boto python library. You could alternatively accomplish this through the AWS web interface of AWS command line tools.

An EBS instance will maintain the state of the OS when the instance is stopped. E.g., bring up the instance, install some packages, stop the instance. When you bring the instance back up, the packages remain. When the instance is stopped you pay for the EBS storage of the OS, but not the EC2 instance.

connect to AWS (python)

from boto.ec2.connection import EC2Connection
# specify the machine image for US east ubuntu 12.04 amd64 ebs
# see http://cloud-images.ubuntu.com/locator/ec2/
ami = 'ami-1ebb2077'
conn = EC2Connection(AWS_ACCESS_KEY, AWS_SECRET_KEY)

create a security group with SSH, HTTP & HTTPS (python)

security_group = 'midas-server'
security_description = 'Security rules for a https Midas server'
repo_sg = conn.create_security_group(security_group, security_description)
repo_sg.authorize('tcp', 80, 80, '0.0.0.0/0')
repo_sg.authorize('tcp', 22, 22, '0.0.0.0/0')
repo_sg.authorize('tcp', 443, 443, '0.0.0.0/0')

create a new instance, this costs money (python)

# a micro instance in this case
reservation = conn.run_instances(image_id=ami,
                                 key_name=YOUR_KEY_NAME,
                                 security_groups=[security_group],
                                 instance_type='t1.micro')

interrogate the instance (python)

# it is possible your reservations will be stale and you'll need to request it again
reservations = conn.get_all_instances()
# we only asked for one instance
instance = reservations.instances[0]
# to get the state (pending, running, stopping, stopped, shutting-down, terminated)
instance.state
# to get the region
instance.region
# to get the availability zone
instance.placement
# dns name is used to ssh to the box and to view its web server
instance.dns_name
# to shut down the instance (but not delete it)
instance.stop()

bootstrap and provision the box (bash)

From the shell of a machine with access to the bootstrap.sh script from this repo, and with access to your_account.pem.

Copy bootstrap.sh to the EC2 instance, based on its dns_name.

Ubuntu AMIs have ubuntu as the root user.

scp -i your_account.pem bootstrap.sh ubuntu@dns_name:~/

ssh to the EC2 instance, bootstrap it.

ssh -i your_account.pem ubuntu@dns_name
./bootstrap.sh

The bootstrap.sh command will clone this repo, and get the box ready to be provisioned with a Midas instance via Puppet.

cd infrastructure
./provision.sh

This Midas instance will have a self-signed certificate, will allow traffic through HTTP and HTTPS, and will redirect all of the HTTP traffic to HTTPS. The Midas base dir will be the box's docroot (meaning going to https://dnsname/ will take you to Midas).

EBS volume creation and attachment (python)

I'm inclined to say create a separate EBS volume for the assetstore and the database portion of the Midas instance, so these can be moved to different servers, snapshotted separately, duplicated or have other maintenance or changes made. I feel this gives the most flexibility, although the cost is management of additional and separate resources.

First we create a 5 GB EBS volume, in the same availability zone as the EC2 instance, and attach it to the EC2 instance. This size is totally arbitrary.

vol = conn.create_volume(5, instance.placement)
# ask for this volume to be mounted at /dev/sds
conn.attach_volume(vol.id, instance.id, '/dev/sds')
# this will take take some minutes
# check the state of the volume (creating, in-use, detaching, available)
volume.status
# if you want to detach the volume from the instance
volume.detach()

move mysql to the attached EBS volume (bash)

Find the name of the volume. If you requested /dev/sds when you asked for the EBS volume it will likely show up as /dev/xvds.

Use these commands on the EC2 instance after the volume is attached.

# see the mounted volumes
df -h
# see all attached block storage devices
sudo fdisk -l

You'll find your attached volume as the device in fdisk that isn't in df. Assuming you haven't mounted the volume before.

Once you have the device name, you can uncomment the mysql.sh script in this repository, set the device name, and run the script. WARNING, this script will reformat the volume and all data will be lost. This script will format the volume as XFS, stop mysql server, move the mysql data files to the attached EBS volume, then restart msyql. Why is the script commented? It seemed like a good idea at the time.

./mysql.sh

move the Midas assetstore to the EBS volume

TODO

TODO: explain about mount failures, ssh problems, detach, attach as secondary, fix issue, mount on /etc/rc.local for ebs, console_output, or just terminate instance and start over

SSL encryption

The scripts above generate and use a self-signed SSL certificate for the webserver. If your organization has a way to distribute additional certificate authorities (CAs), you may wish to generate a new key and sign it with a self-generated certificate authority that employees can then import into their browser (or have imported for them by sysadmins). Here are instructions for how to Become your own SSL Certificate Authority.