Version 2.2

Owned by Yaw Nti-Addae
Last updated: May 05, 2020 by Roy Petrie
4 min read

Versioning

Please refer to the full technology matrix for the latest update to versions used for GOBii

GDM Container Deployment Versions

This shows the Docker versions used for deployment of this release:

  • GDM:

    • git: release/2.2

    • Dockerhub: GC-GBV13_build_4

  • KDC: server_1.6.1-plugin_0.14.3-build_110

  • ownCloud: base

  • Portainer: latest

  • sherpa: latest

LDAP: base

If the system requires local authentication, a separate LDAP node can be deployed for authentication and authorization. If this is required, please refer to the local Administrator for help on deployment. (If a local administrator is unavailable, contact @Roy Petrie @ rlp243@cornell.edu)

Versions & Prerequisites [readme.md]
The versions and prerequisites can also be found in the repo readme located here.

 

Multi-Node vs Single Node Deployment

GDM can be deployed in different architectures including single node and multi-node deployment.

Single Node Deployment: A single Node deployment will deploy all containers to the same node (host). This can be a bare metal server or a virtual machine instance that hosts all the containers for the GDM services.

Multi-Node Deployment: Within a Multi-Node (Multi-Host) Environment the container instances will be deployed across different nodes (hosts)

Internal Network Communication vs External Network Communication

Using the internal network communication uses the docker network and uses this network to communicate between containers. When using the external communication, which is required (currently) for multi-node deployments, the containers communicate over external IPs and hostnames.

Some of the containers may require the /etc/hosts file to be updated to reflect all external networking communications.

Backup, Restores & Non-Destructive Deployment Requirements

The containers have been updated from Ubuntu 16.04 to 18.04 and in doing this the user and group IDs have changed within the system. This has caused some issues with mixing old and new user IDs for keeping data. Please follow the process listed below to back up the database to keep the current data without requiring a full database deletion.

Recommendation: This process is recommended to be performed regularly for Database backups. There is not currently a script to call via cron but it is recommended to do so. This is a process that can be done manually, on a regular basis, or scripted with your system administrator's help.

Backup DB

1.) Log in to db-node with the postgres user

docker exec -ti -u postgres gobii-db-node bash

2.) Run the following command to perform a database dump

pg_dumpall > </path/to/outfile>

  • Replace </path/to/outfile> with a location mounted on the host system such as /data and outside of the /data/gobii_bundle directory location.

Restore DB

1.) Log in to db-node with the postgres user

docker exec -ti -u postgres gobii-db-node bash

2.) After a deployment, a database will already exist so the new data base will need to be dropped

3.) Create each of the deleted database(s)

3.) Run the following command to perform a database dump restore

or to restore a specific database

 

File Backups

Please refer to the Non-Destructive Deployment Architecture Documentation. This is the current recommended architecture to preserve persistent data across release deployments.

To rebuild this architecture, please use the ndd_pathing.sh script to perform the proper symlinks to the persistent_data/ locations.

Running GDM Deployments

The technical documentation for running deployments via bash scripts is located in the Bitbucket cloud repo. Please refer to the proper version of the deployment for version specific technical notes and deployment processes.

gobii.deploy.bash

Post Deployment Configurations

Post Deployment Testing

Release 2.2.1 Hotfix Deployment