Add CloudFormation support via Troposphere

This changeset adds support for Amazon Web Services CloudFormation via
Troposphere, a Python library for describing CloudFormation stacks.

There are currently 4 stacks:

- VPC

The VPC consists of 4 subnets, 2 public and 2 private. The subnets are
spread across 2 availability zones. There is a NAT instance for each
availability zone, and one bastion instance for the entire VPC.

- Data store (contains database and cache)

The data stores consist of a PostgreSQL RDS instance setup across
multiple availability zones and a Redis ElastiCache instance. The RDS
instance creates a default database (`nyc_trees`) automatically. The
ElastiCache Redis instance has AOF enabled. Both live inside the private
subnets.

- App servers

The application servers live within a vanilla Auto Scaling Group (ASG)
that is associated with an Elastic Load Balancer (ELB). Health checks
run by the ELB trigger changes in the ASG. All application servers live
inside the private subnets, but are fronted by their own ELB.

- Tile servers

The tile servers live within a vanilla Auto Scaling Group (ASG) that is
associated with an Elastic Load Balancer (ELB) as well. Health checks
run by the ELB trigger changes in the ASG. All tile servers live inside
the public private, but are fronted by their own ELB.

Additional AWS deployment details are housed in the `README`.

Resolves #24.
Add test provisioning path

This changeset introduces an alternate provisioning path for testing
environments. The majority of the differences in a test provisioning
path are associated with the omission of monitoring (Collectd, RELP,
Logstash). There is a new `nyc-trees.monitoring` role that attempts to
encapsulate monitoring tasks associated with a metrics/logs producer.

The environmental variable `VAGRANT_ENV` is used to determine which
provisioning path is taken. Inside of Jenkins, `VAGRANT_ENV` will be set
to `TEST`, which will adjust the Ansible inventory used.
Update data store backup and maintenance windows

After applying the CloudFormation template, I encountered the following
errors with the previous backup and maintenance windows:

- Backup and maintenance window for RDS cannot overlap
- Maintenance window for RDS and ElastiCache must be at least 60 minutes

This changeset includes adjustments to repair those errors, along with
Eastern Time Zone translation comments.
Remove SNS topic from VPC CloudFormation stack

Instead of creating the SNS topic used for global stack notifications
inside of the VPC stack, it seems better to create it outside of
CloudFormation so that we can associate it with all other CloudFormation
stacks. This will allow us to get notifications more easily when stacks
are modified.
Grow bastion root volume

The default root volume for instances is 8GB. This change ensures that
the root volume for the bastion instance (plays a dual role as a
monitoring server) is 128GB.
Remove use of collectd_hostname

`collectd_hostname` was being used to populate the Collectd
configuration file's `Hostname` setting. If omitted, Collectd uses the
`gethostname(2)` system call to automatically set `Hostname`. This
behavior is much more desirable for EC2.

See also: https://github.com/azavea/ansible-collectd/pull/1
Merge branch 'feature/remove-collectd-hostname' into develop
Fix Apache and Nginx race condition with /var/www/html

Kibana uses `/var/www/html` as its web root and Nginx attempts to serve
its static assets from there. Later, Apache is installed for the
Graphite Web interface, and the Apache package dumps a test site into
`/var/www/html`. Unfortunately, this overwrites the static assets that
Kibana and Apache's test site have in common (`index.html`).

This changeset makes the Graphite installation go first, followed by
Kibana. In addition, the Apache installation also removes the test site
*if* `apache_delete_default_site` is `True`.

See also: https://github.com/azavea/ansible-apache2/pull/2
Merge branch 'feature/fix-apache-nginx-race' into develop
Use .galaxy_install_info to trigger role installation

The `ansible-galaxy` command is nice enough to leave behind a bit of
metadata associated with role installation
(`role_name/meta/.galaxy_install_info`). The `Vagrantfile` now attempts
to determine the version of an installed role based off of the metadata
in that file. If the versions don't match, an install of all role
dependencies occurs.

I'm not in love with this solution, but I think that it is better than
force reinstalling all role dependencies every time (~10 seconds on
every provision).
Merge branch 'feature/smarter-ansible-role-install' into develop
Fix issue with initial ansible galaxy install.

I got the error message: "to_yaml" not defined
Merge pull request #65 from maurizi/fix-ansible-roles-install

Fix issue with initial ansible galaxy install.
Add simple shell script for running manage.py commands

All arguments are passed through, so you can do:
`./manage.sh runserver`
or
`./manage.py migrate core`
or any other management command, from your host, without having to
wrap you call with envdir
Use sane defaults for the Django runserver

If you don't use 0.0.0.0:8000, the runserver is only accessible from
the VM itself.
Show correct way to use runserver

Unless you specify 0.0.0.0:8000 as an argument, runserver will only allow
connections from localhost.  This seems to pair badly with using a Vagrant
private network.
Merge pull request #68 from maurizi/run-tools

Add simple shell script for running manage.py commands
Merge pull request #71 from maurizi/fix-readme

Show correct way to use runserver
Add Packer support

This changeset adds support for creating Amazon Machine Images (AMIs)
that correspond to the types of Vagrant box definitions used in
development. Because we will be making use of the Relational Database
Service (RDS) and ElastiCache (for Redis) in production, services like
PostgreSQL and Redis are excluded from the images.

The 3 AMI types are:

- Monitoring

This AMI contains Kibana, Logstash, and Graphite/Statsite. The goal is
to use this AMI for the bastion host, giving it two roles (bastion and
monitoring server).

- Application

This AMI houses the Django application and maintains pointers to all of
the services it depends on (tile, cache, database).

- Tile

This AMI contains the tiler and maintains pointers to the cache and
database services.

Two other notable additions that were required for Packer support are
private DNS support and a deployment helper to string together
CloudFormation inputs/outputs.

- Private DNS support

Route 53 has support for private DNS. The plan is to use the
`nyc-trees.internal` domain for services available within the Virtual
Private Cloud (VPC). For example, the application server will always be
configured to talk to the cache via
`cache.services.nyc-trees.internal`. This allows AMI creation to be more
flexible in the event that we have to replace the caching cluster.

- Deployment helper

`deployment-helper.sh` contains almost all of the code to connect
CloudFormation stacks. It is a fair amount of Bash, but it defers a lot
of the heavy lifting to the `awscli`.

I originally started down the path of writing tooling in Python with
Boto and Cement, but ran into hurdles due to my Python rustiness and
Cement framework confusion. Also, I don't think that my Python code
would have turned out better than the Python code in the `awscli`.

It would be great to revisit the CloudFormation tooling at a later point
in a way that solves this problem across all Azavea teams.

See the `README` for more details on how an actual deployment would
work.
Merge branch 'feature/packer' into develop