Version 2.2
- Yaw Nti-Addae
- Roy Petrie
- Monica Franciscus (Unlicensed)
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.
Post Deployment Configurations
LoaderUI Download Link
Post Deployment Testing
Release 2.2.1 Hotfix Deployment
Ā
Ā
Ā