Creating Amazon machine images (AMIs) with Ansible. (OBSOLETE)

Owned by Eddie Rubeiz
Last updated: Oct 18, 2022
2 min read

Amazon machine images (AMIs) are templates AWS uses when creating EC2 cloud servers. They are based on snapshots of existing servers.

Whenever you create an EC2 server, you will need to rely on an existing AMI. To save time when spinning up new servers, we maintain a set of AMIs that come pre-packaged with some of the more time-consuming software to compile and install, such as Ruby, Java, VIPS and ImageMagic.

We have automated the process of creating the AMIs themselves, using the build_ami ansible role.

Outline

build_ami spins up a new ec2 image; installs software on it; takes a snapshot of the server and creates an ami for later use; and finally destroys the ec2 image. The buildvariable determines what software is installed.

Later on, the AMI’s id can be used in building an ec2 servers.

Software installed

Aside from packages and system_setup, which are run on all new machines, the following three optional software installation roles are run:

Ansible role

What it does

When it runs

Ansible role

What it does

When it runs

ruby

Compiles and installs Ruby

If you pass --extra-vars "build=ruby_ami"

imagemagick

Compiles and installs imagemagick

If you pass --extra-vars "build=ruby_image_ami"

dzi
(role name for historical reasons, prob should be called vips)

Compiles and installs vips

If you pass --extra-vars "build=ruby_image_ami"

Important files

File

Contents

 

File

Contents

 

build_ami.yml

Outline of the role

 

group_vars/ruby_ami

ami metadata (instance type, disk size, aws name and tags)

 

group_vars/ruby_image_ami

ami metadata

 

roles/dzi/vars/role_vars

Current vips version

 

roles/ruby/vars/role_vars

Current ruby version

 

roles/imagemagick/vars/role_vars

Current imagemagick version

 

Example invocations

(we use the production key private-key here, as it will end up kind of permanently allowing ssh access to the machine, and we don’t want staging/test key to have access to production machines)

An AMI with ruby on top of ubuntu (used for web servers, may be used for solr server although prob not necessary)

ansible-playook --ask-vault-pass build_ami.yml --private-key=~/.ssh/chf_prod.pem --extra-vars "build=ruby_ami"

An AMI with ruby and image utilities (vips and imagemagick) (used for jobs servers)

ansible-playook --ask-vault-pass build_ami.yml --private-key=~/.ssh/chf_prod.pem --extra-vars "build=ruby_image_ami"

Viewing created AMIs in the AWS console

The images are visible at: https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images . Note in particular that the value of the AMI ID column in the table is used to tell Ansible which AMI to use when building ec2 machines. The variable used is ec2_image .

Finding or changing what AMI an ec2 instance is based on

Running grep ec2_image group_vars/* lists the AMIs our ec2 servers are based on.

For instance, as of summer 2020, if you run grep ec2_image group_vars/kithe_solr
you will get:

ec2_image: ami-00e403112709795fd #Ubuntu 18 Ruby-Java 2.6.6

While the comment is helpful, it’s possible to get this info by simply looking up the ID in the AWS console under EC2 > Images > AMIs.

To change an AMI that a given server role uses, find it’s variable file under group_vars, and change it to use the new AMI ID.

Obsolete AMI roles

There used to be a java_ami role we used for solr and fedora boxes, but is is no longer in use. ./group_vars/java_ami can be removed.