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.

Note: Following the setup of the DMS using the Auto-deploy method, to finish the email setup, you should modify the environment specific settings in the settings.xml file in the nuxeo repository. Please check here for further information.

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.

http://172.20.32.20:7990/projects/DMSCLIENT/repos/deploy_script/browse

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

http://172.20.32.20:7990/projects/DMSCLIENT/repos/default_config/browse

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

http://172.20.32.20:7990/projects/DMSCLIENT/repos/<clientname>/browse

Script updates

If you downloaded the base OVA after 2017-06-01, you can run a scripted update command on all three scripts by issuing "./update_scripts.sh" from the home directory of the root user. If you downloaded your base OVA before that, your scripts need to be updated manually by cd'ing into their respective directory and running the "git pull" command.

Basic method of use:

  1. PI forks Default template to client specific repository with <clientname> upon request;
  2. Edit configuration files in client specific git repository as required for specific client’s DMS environment. Most of the times, only changes to containers.conf, dms.conf, and, if applicable, postfix-config.sh will need to be made (see below for some guidance on the DMS heap configuration in dms.conf). Edits to the remaining files (e.g. commands.conf) will be rare and only required in special situations, such as, for example, if proxy setups need to be catered for. They should only be made if you are sure you understand what you are doing. Make sure changes are pushed back to repository;
    Please make sure to change the standard NUXEO_PASSWORD in the dms.conf.
  3. Copy any fonts you intend using to /storage/nuxeo/fonts/ (unless you are using a different storage location; if so, adapt accordingly);
  4. Create folder ~/deploy/config/ to store configuration files and clone client specific repository into this folder;
  5. Create folder ~/deploy/deploy_script/ to store deploy script logic files and clone client specific repository into this folder;
  6. Create an empty nuxeo repository, restore from a previous DMS version (using the restore scripts - check here for details);

  7. Copy any fonts you intend using to the storage location (default is /storage/nuxeo/fonts/);

  8. cd into  ~/deploy/deploy_script/ folder and run "./deploy.sh" with necessary options.

Use for deploying DMS updates (or downgrades) in an environment that had been installed with the auto-deploy method:

  1. cd into ~/deploy/config/ and edit configuration file containers.conf to define the version that should be deployed. Make sure changes are pushed back to repository;
  2. 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.
  • For correction function of the DMS, you must set the LANGUAGE and COUNTRY variables in the dms.conf before deploying the DMS (or redeploy after setting it) to the correct values matching your location. Please check: http://www.oracle.com/technetwork/java/javase/java8locales-2095355.html and use the LANGUAGE (ISO 639) tag for the language and the COUNTRY (ISO 3166) tag for the country. 

   Example: LANGUAGE="en", COUNTRY="GB"

DMS heap settings based on installation environment:

The following heap settings to be set in dms.conf present some guidance based on user count. Note that other parameters such as status of the project (eg. document background analysis phase or only production phase), etc. play into these values which may thus be subject to change.
It's usually recommended to set the same value to the XMS and XMX part, especially for elasticsearch, as the heap extension is a costly operation. Unequal values can lead to experiences of short freezes. The XMS value will be ignored in newer DMS versions.

0-5 users

5-20 users

20-40 users

40-80 users

NX_XMS="1024M"

NX_XMS="4096M"

NX_XMS="8192M"

NX_XMS="12288M"

NX_XMX="8192M"

NX_XMX="16384M"

NX_XMX="32768M"

NX_XMX="40960M"

CB_XMS="512M"

CB_XMS="512M"

CB_XMS="1024M"

CB_XMS="4096M"

CB_XMX="1024M"

CB_XMX=“2048M”

CB_XMX=“4096M”

CB_XMX="10240M"

ES_XMS=“256M"

ES_XMS=“256M"

ES_XMS=“512M"

ES_XMS="512M"

ES_XMX=“512M"

ES_XMX=“1024M"

ES_XMX=“2048M"

ES_XMX=“4096M"

Deploying the DMS using https security

Starting version 1.9.8.2.4-2, your DMS can be deployed to make use of https security in all client/server communication. This requires a certain level of experience with basic system administration to obtain certificates and deploy them in your DMS VM. A step-by-step description of how to activate https security in your DMS environment is outlined here: Deploying the DMS in https mode