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.

For deployment of new empty DMS or restoring from backup, check here.

For importing an existing document store into a new empty DMS, check here.

The following describes the overall functionality/use.

Git repositories involved in the process are (PI internal links only):

Note that http access to the below repositories is only available from inside the Practice Insight network. The repositories can, however, be read/written by git through the links given in the  pages linked above.

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: es, 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);
• -logsrv will configure nuxeo and cb containers to send log messages to a graylog server in GELF format. The server details and properties of the communication are configured in the "dms.conf";
• -v (or –vv, -vvv, -vvvv) options set log level for the nuxeo and cb containers. Default log level is ERROR. -v, -vv, -vvv, -vvvv sets to WARN, INFO, DEBUG, TRACE respectively.
• -local will run the deploy script from a local only config. It is strongly discouraged to use this in production.

Options can be combined.

Examples:

./deploy.sh es 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.