/rialto-webapp

The web front end of the RIALTO project

Primary LanguageRuby

Rialto Webapp

CircleCI Ruby Test Coverage Ruby Maintainability

This is the Blacklight frontend for Rialto.

Dependencies

  1. A database (RDS)
  2. A Solr index
  3. config/master.key containing the master key added to your clone of this repository.

Build Docker image

./bin/build

Run

docker run -p 3000:3000 \
-e SOLR_URL=http://50.16.181.132:8983/solr/rialto-dev \
-e HONEYBADGER_API_KEY=<key> \
-e RAILS_MASTER_KEY=<key> \
suldlss/rialto-webapp:latest

Run tests

Frontend:

npm test

Backend:

rake spec

To bring up a test database in a Docker container:

docker run --rm --name rialto_test_db -e POSTGRES_DB=rialto_test -p 5432:5432 -e POSTGRES_USER=$USER -d postgres:9.6.2-alpine

To bring up a test Solr in a Docker container:

docker run -d -p 8983:8983 -v $PWD/solr/conf:/myconfig solr:7 solr-create -c blacklight-core -d /myconfig

Deploy

Push updated image

The RIALTO web app is deployed as a container to AWS, and this process is managed by Terraform. The first step of the deployment process is to build, push, and tag an updated image. You can do this manually by following the Build Docker image section above and then manually pushing the updated image to Docker Hub:

docker push suldlss/rialto-webapp:latest

In practice, though, merging any commits into the master branch -- e.g., regular dependency updates -- will trigger a CI build which automates building, pushing, and tagging a new image. You can check the Docker Hub UI to see when the image was last updated.

Version tagged images (for production & stage)

In both the staging and production environments, a version tagged image is used to provide easier rollback points and make it clear what state the environment is in.

  1. https://github.com/sul-dlss/rialto-webapp/releases
  2. Draft new release: https://github.com/sul-dlss/rialto-webapp/releases/new
  3. Numeric only version tags are required to trigger the CI build and publish (i.e. 1.3.0 NOT v1.3.0).

Update container definitions in Terraform

Once the new image has been successfully pushed, the container definitions for the RIALTO web app in Terraform must be updated. Create a pull request in the terraform-aws repo that bumps the docker image version for RIALTO web app in both staging and production environments; the value must change for the new container to be pulled into the RIALTO web app. See this pull request as an example.

Note that a member of the Operations team must approve and merge this PR, but the PR does not need to be merged before beginning the next section.

Ops folks will typically trigger a production deployment upon merging the PR. In your terraform-aws PR, you may request that the person who approves and merges it deploy the changes to other environments (such as staging). In that case, you can consider your work done at this point. If on the other hand you prefer to handle the staging deployment yourself (e.g., if you'd like to do extra testing), check out the next two sections for the rest of the process.

Deploy to staging environment

Once the Terraform PR in the prior section has been merged -- or run this from your branch, no need to wait on master! -- use Terraform to deploy the RIALTO web app to the staging environment. Note that you will need a Vault account to proceed. Create an operations tasks issue to request one if you do not have one already.

  1. Install Vault via your favorite OS package management system. We use Vault to manage secrets and control access to our Terraform infrastructure.
  2. Specify our Vault root URL in an environment variable: export VAULT_ADDR=https://vault.sul.stanford.edu/
  3. Get a Vault token: vault login -method=userpass username=USERNAME password=PASSWORD
  4. Change into the RIALTO staging terraform directory: cd {terraform-aws-root-directory}/organizations/staging/rialto
  5. Ensure you have environment variables set for AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID so that you can be authenticated to AWS.
  6. Initialize terraform if you have not run this yet: terraform init
  7. Run terraform plan
    • If you are prompted for var.profile, enter the name of AWS staging profile
    • Verify that the only changes highlighted by terraform plan are related to the updated web app container: Plan: 1 to add, 1 to change, 1 to destroy.
  8. Run terraform apply
  9. Ensure you have set up the AWS console with the appropriate roles: https://github.com/sul-dlss/terraform-aws/wiki/AWS-DLSS-Dev-Env-Setup
  10. Watch the RIALTO web app deployment in the AWS console, using DevelopersRole in the sul-dlss-staging account. You should see two deployments for some time (15-20 minutes). Eventually, the newer deployment will be the only one running. That means the container has now been updated in the staging environment.
  11. In your browser, hit the RIALTO web app staging URL. If it resolves and renders, you can move on to the next section.

Deploy to production environment

Once you have verified all went well in staging, request that the Operations team run deploy the RIALTO web app to production by creating an operations tasks issue. Once this has been done, verify that the production RIALTO web app URL https://rialto.sul.stanford.edu/ resolves and renders.