Overview

The Vagrant environment on this project served two purposes (running analysis on Windows, working around docker-on-host issues on Macs) that are now obsolete. This removes the Vagrant environment and the Ansible configuration that was used to provision it. We've had partial docker-on-host support for a while; with these changes that will be fully supported and the only way to do things. This also includes updates to the README to remove Vagrant-related documentation and make the instructions for running the development environment match the current process.

Resolves #964

Notes

1. The main sticking point was environment variables—there are a few variables that were getting configured by Ansible to always be present in the Vagrant environment, so to run on host we had to provide those to the scripts and containers some other way. The partial docker-on-host solution we had been using called for creating an .env file to define a few of those variables. The changes here do away with that in favor of providing them as defaults in the handful of docker-compose files and shell scripts where they're needed.

2. Specifically on the subject of the variables that supply AWS credentials, there are basically three environments with slightly different needs:

• In production, there are IAM roles and permissions that allow access between services

• In the local environment, we rely on an AWS profile called pfb

• In CI, where there's no way to configure a profile, we rely on AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY variables, with values provided to the workflow by Github Actions

  I believe the setup here works for all three, including support for running the deployment steps manually from a local environment, if necessary, using the pfb profile.

3. I removed the Vagrant reference in README.LOCAL-ANALYSIS.md but didn't do a full edit/update of that file, so I can't vouch for it being fully current. From a quick review it seemed like it's not way off, but it wasn't the focus here and I'm not sure it's worth spending much time on. Running the local analysis command that the Django server prints to the logs is almost always what we want to do, so documentation of how to hand-craft a command isn't that important.

Testing Instructions

• Make a clean checkout of the repo (I do this by cloning it into a new directory)
• Follow the README instructions to spin up the local development environment, and confirm that it works, you can see the data from the fixture, etc
• Run an analysis for Montpelier, VT, by using the Run Analysis form (http://localhost:9301/#/admin/analysis-jobs/create/) to create a job then copying the command from the logs into another terminal
• Confirm that it runs successfully and you can see the Montpelier results in the app

Checklist

• Add entry to CHANGELOG.md