Add Travis CI support

[hectcastro]

Use Travis CI to deploy bundled versions of the micro site to both staging and production with the AWS CLI (encapsulated in cipublish). This uses a single set of credentials that are whitelisted to write to both the staging and production buckets.

Also, adjust the interaction between CloudFront and S3 so that only S3 is able to read objects in the origin via an origin access policy.

---

Testing

• Execute the following steps and ensure that the output matches the following:

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ ./scripts/infra plan
/vagrant/deployment/terraform /vagrant
Initialized blank state with remote state enabled!
Remote state configured and pulled.
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

aws_cloudfront_origin_access_identity.mmw_micro: Refreshing state... (ID: E1D041LSNFF3U1)
aws_s3_bucket.mmw_micro_logs: Refreshing state... (ID: staging-mmw-micro-logs-us-east-1)
data.aws_iam_policy_document.mmw_micro: Refreshing state...
aws_s3_bucket.mmw_micro: Refreshing state... (ID: staging-mmw-micro-origin-us-east-1)
aws_cloudfront_distribution.mmw_micro: Refreshing state... (ID: EXUCNSJRVZI4W)
aws_route53_record.mmw_micro: Refreshing state... (ID: ZURQREPIGC39W_micro.staging.app.wikiwatershed.org_A)

No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.
/vagrant

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ mkdir -p ./dist && echo "Hello, world." > ./dist/index.html

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ MMW_MICRO_DEBUG=1 ./scripts/cipublish.sh 
+ MMW_MICRO_ENV=staging
+ '[' ./scripts/cipublish.sh = ./scripts/cipublish.sh ']'
+ '[' '' = --help ']'
+ aws s3 sync --delete --acl authenticated-read ./dist s3://staging-mmw-micro-origin-us-east-1

• Inspect the Travis CI output here and expand the Deploying application section

[hectcastro]

Rebased to resolve merge conflicts and updated absolute file system paths to relative so that the build works within Travis CI.

[rajadain]

I tried to test this, but got:

> vkj infra plan
/vagrant/deployment/terraform /vagrant
Remote configuration updated
Remote state configured and pulled.
Terraform doesn't allow running any operations against a state
that was written by a future Terraform version. The state is
reporting it is written by Terraform '0.7.5'.

Please run at least that version of Terraform to continue.
Connection to 127.0.0.1 closed.

I noticed the version of Terraform had been bumped, so I provisioned my VM again, and ran the command again to get the same output. During provisioning, I noticed:

TASK [azavea.terraform : Download Terraform] ***********************************
changed: [default]

TASK [azavea.terraform : Extract and install Terraform] ************************
skipping: [default]

So apparently it knew enough to download a new Terraform version, but not install it. I couldn't find where this was described in Ansible though, short of https://github.com/azavea/ansible-terraform/blob/develop/tasks/main.yml#L20?

I can probably get this to work by destroying and recreating my VM, which on such a small project is not a big deal at all.

[hectcastro]

So apparently it knew enough to download a new Terraform version, but not install it. I couldn't find where this was described in Ansible though, short of https://github.com/azavea/ansible-terraform/blob/develop/tasks/main.yml#L20?

This is a bug in the Terraform role. Should be resolved in https://github.com/azavea/ansible-terraform/pull/6.

Tested by recreating the VM. Works well. Saw the expected messages in the console for deployment. Travis deploy was logged correctly too. But I guess the site is not currently up at staging.micro.app.wikiwatershed.org?

It is at: https://micro.staging.app.wikiwatershed.org/

[rajadain]

It is at: https://micro.staging.app.wikiwatershed.org/

This may be just me, but I always find it easier if the environment variable is always a prefix, rather than somewhere inside the URL. So, staging.url.com rather than url.staging.com. I also find it helpful to think of it as the Staging version of the Micro site, rather than the Micro version of the Staging site.