Deploy a release candidate

This procedure describes how to deploy a release candidate to the Staging or Production server – the process is the same as these are both read-only Ontoserver instances.

The process may need to vary if the Staging and/or Production servers are scaled instances. For more details of the impacts please refer to Horizontally scaled read-only endpoint.

Stop the server

This procedure also assumes that the Staging/Production server does not need to be always on, and can therefore have an outage to deploy the release candidate. If a zero down time deployment is required this process can be adapted to achieve that with supporting infrastructure. Please refer to Zero down time deployments for more details.

The Staging/Production server Ontoserver container should be shut down. The procedure to do this will vary depending upon your container hosting technology.

Reconfigure preload feed URL

A new preload URL will have been created as part of the procedure to create a release candidate described above. This URL will need to be configured into the Staging/Production server, replacing the existing configured release candidate URL from the previous deployment to the Staging/Production server. This is achieved by changing the environment variable atom.preload.feedLocation passed to the Staging/Production server’s docker container. For example changing

atom.preload.feedLocation=https://syndication-server/feed/release-candidate-20200815T1300/syndication.xml

to

atom.preload.feedLocation=https://syndication-server/feed/release-candidate-20200820T1630/syndication.xml

to shift from a release candidate taken on August 15 to August 20.

Specifically how this configuration is supplied will depend on the technology used to configure and host the Ontoserver container – e.g. Kubenetes, Helm, Docker Compose…etc. Refer to the hosting details of your specific installation.

Clear database and storage

The Staging/Production server’s state should be cleared so that it can be rebuilt from the data in the new preload feed. There are two aspects to this

  1. Ontoserver’s database
  2. Ontoserver’s filesystem storage

Depending upon whether persistent or transient storage is being used for the Staging/Production server (refer to Shared resources and persistent storage) and the hosting technologies being used, this process may vary. However broadly

  • if transient storage/database is being used simply stopping and deleting the Ontoserver container and its PostgreSQL container is sufficient
  • if persistent storage/database is being used
    • The Ontoserver container must be stopped
    • Its persistent disk content must be cleared to blank, or the persistent disk replaced with a new blank persistent disk
    • Ontoserver’s PostgreSQL database schema must be emptied, this can simply be achieved by dropping and recreating the schema