This is the Blacklight frontend for Rialto.
config/master.key
containing the master key added to your clone of this repository../bin/build
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
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
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.
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.
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.
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.
export VAULT_ADDR=https://vault.sul.stanford.edu/
vault login -method=userpass username=USERNAME password=PASSWORD
cd {terraform-aws-root-directory}/organizations/staging/rialto
AWS_SECRET_ACCESS_KEY
and AWS_ACCESS_KEY_ID
so that you can be authenticated to AWS.terraform init
terraform plan
var.profile
, enter the name of AWS staging profileterraform plan
are related to the updated web app container: Plan: 1 to add, 1 to change, 1 to destroy.
terraform apply
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.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.