Bootstrapping the development environment - part 3

This is the third part in a series of posts about provisioning a development environment for the ALSL project. The complete list of posts in the series are

In the first post in this series I outlined the first steps I took to create an AWS EC2 virtual machine instance and access it via ssh. In the second post I outlined some steps taken to ensure the AWS environment I create is secure.

Now that I have a virtual machine I can access via SSH I need to make sure it has the software I intend to use. This software needs to be installed in a repeatable manner so I can create and destroy the virtual machine fairly regularly if I need to. I have decided to make use of Ansible for automating infrastructure configuration. I briefly considered Chef, Puppet and Salt but decided to go with Ansible because it does not require installing any agent software on the infrastructure targets. On the other hand I hear that Ansible may be slow for use with more machines in a large scale infrastructure so I may revisit Salt in the future.

I need at least Ansible installed on my virtual machine instance and then I should be able to use it to do the rest of the setup and configuration. This should apply equally well to any infrastructure, wherever it is hosted. To make sure Ansible is installed when my instance is launched I will need to modify the aws/launch-devenv.sh script to use user data to install Ansible and git and run an Ansible playbook script from the alsl-infrastructure repo.

My user data script is based on the one I found here. The key commands are shown below.

apt_get_install git ansible
su - ubuntu -c "ansible-pull -i \"localhost,\" -d /home/ubuntu/alsl-infrastructure -U https://github.com/mshogren/alsl-infrastructure aws/alsl-ec2-dev.yml"

The alsl-ec2-dev.yml file is an Ansible playbook that runs some other ansible plays that are defined in a different folder. The plays are kept separate since they are not necessarily dependent on AWS EC2, and should run against other infrastructure, whether that be physical machines, virtual machines or containers.

To start with I created the following ansible project structure:

devenv.yml
roles
  awscli
  vim
  nodejs
  asp.net
  libuv

The playbook is at the top level, and references the roles that should be included. The roles are defined in their own sub-folder under a roles folder. This folder structure meets some conventions defined by Ansible and reduces the need to specify paths inside roles or playbooks. Further information about roles and other includes is here.

The vim role downloads vim and sets it up with a configuration that I keep under source control at https://github.com/mshogren/dotvim. I got that idea from here. The asp.net role is based on instructions I found here. Hopefully I have made my point, that is that it should be possible to create and Ansible role out of any script that an installation follows.

Some roles still need to created. For example, I need a role to clone other source repositories to the machine. I would also like to create a role that sends a notification when the machine is finished being setup, but that will require a few more things to be sorted out. I will leave that for a future post in this series.

Leave a comment