Skip to content

Latest commit

 

History

History
153 lines (111 loc) · 5.08 KB

production.md

File metadata and controls

153 lines (111 loc) · 5.08 KB
Raw

Running an instance of the Research Software Directory in production

Temporarily disabling the admin interface

You can stop users from making changes to the database by disabling the authentication to the admin interface, as follows:

docker-compose stop auth

This can be useful when upgrading the data or software to a newer version.

Note that even with a stopped auth service, determined users can still access backend directly, and users who were logged in before you disable auth will still be able to use the admin interface to make changes.

It it recommended that you post a message that users see when they try to use the admin interface. The easiest way to do this is as follows:

# log in to admin service
docker-compose run --workdir="/build" admin /bin/sh

# rename index.html
mv index.html index.html.disabled

# put a message in index.html
echo "<html>" \
"<head></head>" \
"<body>Sorry, we're doing maintenance right now. " \
"Hopefully be back soon.</body></html>" > index.html

You can check if it works by using your browser to navigate to the admin interface. Instead of the normal interface, you should now see your message.

To enable admin interface again, do the previous instructions in reverse:

# inside admin container
mv /build/index.html.disabled /build/index.html

# Enable logins again
docker-compose start auth

Updating a production instance

Every now and then, the production instance needs to be updated, so the server can get the latest security patches, and the Research Software Directory software itself can be updated to include the latest features.

The steps below differentiate between the old and the new instance of the Research Software Directory; the old instance has IP 35.156.38.208, the new one has IP 3.122.233.225. Your IP addresses will likely be different.

  1. Make a new Amazon instance by following the notes above. Some things to think about:

    • Reuse the existing security group.
    • Reuse the existing key pair.
    • Verify that you're allowed to ssh into the new instance.

  2. Transfer the rsd-secrets.env file from the old instance to the new instance.

    cd $(mktemp -d)
scp -i ~/.ssh/rsd-instance-for-nlesc-on-aws.pem \
   [email protected]:/home/ubuntu/rsd/rsd-secrets.env .
scp -i ~/.ssh/rsd-instance-for-nlesc-on-aws.pem \
   ./rsd-secrets.env \
   [email protected]:/home/ubuntu/rsd/rsd-secrets.env

  3. On the remote, create the symlink .env and let it point to rsd-secrets.env:

    cd ~/rsd
ln -s rsd-secrets.env .env

  4. Stop new additions to the database in the old Research Software Directory instance by following the notes from Temporarily disabling the admin interface. This will effectively disable the rsd-admin service.

  5. Create the backup files in the old Research Software Directory instance:

    # start an interactive shell in the backup container
docker-compose exec backup /bin/sh

# create the backup files in the container's /dump directory
/app # mongodump \
  --host ${DATABASE_HOST} \
  --port ${DATABASE_PORT} \
  --db ${DATABASE_NAME} \
  --out /dump

# leave the backup container
exit

# Copy the dump directory out of the docker container
docker cp $(docker-compose ps -q backup):/dump/rsd /home/ubuntu/rsd/dump

  6. Transfer the dumped json and bson files from the old to the new instance

    scp -r -i ~/.ssh/rsd-instance-for-nlesc-on-aws.pem \
   [email protected]:/home/ubuntu/rsd/dump .

scp -r -i ~/.ssh/rsd-instance-for-nlesc-on-aws.pem \
   ./dump/* [email protected]:/home/ubuntu/rsd/database/db-init/

  7. Start the new Research Software Directory instance.

    ssh -i ~/.ssh/rsd-instance-for-nlesc-on-aws.pem [email protected]
cd /home/ubuntu/rsd

docker-compose build
docker-compose up -d

  8. Check /CHANGELOG.md to see if you need to run any command to migrate data, e.g. when a collection has changed its schema.

  9. Next, harvest all the data from external sources using:

    docker-compose exec harvesting python app.py harvest all
docker-compose exec harvesting python app.py resolve all

  10. In case the old instance had problems with harvesting of the mentions, you may need to retrieve all mentions, as follows:

    docker-compose exec harvesting python app.py harvest mentions --since-version 0

  11. Check if the instance works correctly using a browser to navigate to the new instance's IP address.

  12. If everything looks good, stop the Research Software Directory in the old instance

    docker-compose stop

  13. Disassociate the ElasticIP address from the old instance.

  14. Associate the ElasticIP address with the new instance.

As a final step, use the Amazon EC2 management console to Stop (not Terminate) the old instance. This way, the old instance can still be reactivated in case you need to get back to the old version.