Page History

The auto-deploy script provides an automatic deploy and configuration of new DMS installations with minimal administrative requirements.

Uses:

• deploying of a new (empty) DMS;
• deploying from a backup of an older DMS installation (migrating to current zero-config and auto-deploy technology);
• deploying of a new (empty) DMS and importing documents from an existing non-DMS Patricia system; and
• installing DMS updates (where the previous installation had been deployed using the auto-deploy technology).

The technology is based on git repositories for which each client will have one. The git repository contains all configuration files that are pulled to the client system and then the auto-deploy script is run. Given client specific configuration repositories are hosted at Practice Insight private servers, only users having credentials assigned by PI will have access.

The following describes the overall functionality. For deployment of new empty DMS or restoring from backup, check here in addition to the below information.

Git repositories involved in the process are:

i)      Deploy script: This contains the script logic.

https://stash.practiceinsight.io/stash/projects/DMSCLIENT/repos/deploy_script/browse

ii)     Default template: This contains a template for the client-specific configuration repository.

https://stash.practiceinsight.io/stash/projects/DMSCLIENT/repos/default_config/browse

iii)    Client repository: This will contain the client specific repo.

https://stash.practiceinsight.io/stash/projects/DMSCLIENT/repos/<clientname>/browse

Basic method of use:

1. Fork Default template to client specific repository with <clientname>;
2. Edit configuration files in client specific git repository as required for specific client’s DMS environment – make sure changes are pushed to repository;
3. Create folder ~/deploy/config/ to store configuration files and clone client specific repository into this folder;
4. Create folder ~/deploy/deploy_script/ to store deploy script logic files and clone client specific repository into this folder;
5. cd into  ~/deploy/deploy_script/ folder and run "./deploy.sh" with necessary options.

Options for deploy.sh:

• Container names are selectable options to run deploy.sh only on the specified containers: elastic, postgres, nuxeo, cb, service, postfix. If deploy.sh is run without any containers specified, all containers except postfix will be handled. Postfix container will only be installed (or updated) when specified expressly;
• -rmc will stop and remove containers listed in deploy.sh command;
• -rmi will remove all unused images (ie. Images for which no containers are run);
• -v (or –vv, -vvv, -vvvv) options set log level for nuxeo or cb containers. Default log level is ERROR. -v, -vv, -vvv, -vvvv sets to WARN, INFO, DEBUG, TRACE respectively.

Options can be combined.

Examples:

./deploy.sh elastic postgres nuxeo -rmc -rmi
./deploy.sh nuxeo cb -rmc
./deploy.sh nuxeo cb -rmc -rmi -vvv

Important Notes:

• Restarting of elastic or postgres containers without restaring nuxeo container will break DMS functionality until nuxeo container restart.
• The deploy.sh script will check if modifications have been made to the files in ~/deploy/config/ that have not been committed/pushed to the client specific git repository (ie. if there is discrepancy between the origin of the client specific git repository and the local configuration files). If such is the case, deploy.sh will not execute but output a corresponding warning and quit. It is important to commit local changes to the repository. After that, run "./deploy.sh" again.