This is the Capistrano project that deploys code and ingests records for Open Vault, a website maintained by WGBH Media Library and Archives.
This documentation is intended for use by WGBH-MLA staff. It is not expected to to work for the general public.
Before deploying, ensure the following:
- The target host has been created, is running on AWS, and has been fully provisioned. (Click here for inforamtion on provisioning servers for Open Vault)
- You have the private key required to SSH into the host.
- Clone the repository
git clone https://github.com/WGBH/openvault3_deploy.git
cd openvault3_deploy
- Get the private key for accessing the target host with SSH and set the permissions
The private key must be securely obtained from a WGBH-MLA developer. By
convention, the name will correspond to a set of AWS resources, in particular
an AWS keypair. Keep the private key in your ~/.ssh/ directory, with
permissions set appropriately:
```
chmod 600 ~/.ssh/xyz.wgbh-mla.org.pem
```
- Determine the IP address of the EC2 instance
Assuming your server was created with aws-wrapper, the DNS name you have does not point to the EC2 instance itself, but rather, to a load balancer in front of the the instance. To obtain the EC2 IP, you can look in the AWS console, or
cd ../aws-wrapper
ruby scripts/ssh_opt.rb --just_ips --name xyz.wgbh-mla.org
- Run
bundle install
If bundle install runs successfully, then you should be able to run a deployment or ingest records.
From the root directory of your cloned repo, run the capistrano command for the aws stage. This step could take a few minutes.
bundle exec cap aws deploy OV_HOST=1.2.3.4 OV_SSH_KEY=~/.ssh/xyz.wgbh-mla.org.pem
If there were no errors, then you should be able to see the Open Vault website running in a web browser, at the target host's IP address. If there were errors, or if you can't see the running website, then please file a bug.
To ingest into a server which is already up and running.
bundle exec cap aws ingest OV_HOST=1.2.3.4 OV_SSH_KEY=~/.ssh/xyz.wgbh-mla.org.pem OV_PBCORE=fm-export.zip
Normally, you won't have to worry about installing or uninstalling your Solr
instance. Running a deployment according to the steps above will setup a Solr
index for you (using
blacklight-jetty).
In special circumstances however, you may want to replace an existing Solr repository with a new one.
WARNING! Doing this will delete your exisiting index and its data. This operation cannot be undone. Normally you shouldn't have to do this.
bundle exec cap aws jetty:uninstall OV_HOST=1.2.3.4 OV_SSH_KEY=~/.ssh/xyz.wgbh-mla.org.pem
This will install a new Solr index (if needed), configure it, and start it. It is idempotent, and is run at the end of every deploy. Normally you shouldn't have to do this, but you may if you removed your existing Solr index using the steps above.
bundle exec cap aws jetty:install OV_HOST=1.2.3.4 OV_SSH_KEY=~/.ssh/xyz.wgbh-mla.org.pem
error notification. issue #32.