Installation using Docker Image

Prerequisites

In order to run the containerized SORMAS you need to have installed the following tools:

  1. Docker (Version 19.3 is tested to run SORMAS)

  2. docker-compose

  3. Insert this line into your /etc/hosts file:

127.0.0.1 sormas-docker-test.com
  1. As the user running docker-compose create these directories:

mkdir /srv/dockerdata/sormas/psqldata mkdir /srv/dockerdata/sormas/sormas-backup mkdir /srv/dockerdata/sormas/sormas-web

Downloading SORMAS in your system

After installing all the prerequisites from the above, please run the command below in your CLI:

Docker Pull Command

docker pull hzibraunschweig/sormas-application

Running SORMAS

Start the application

  1. Check out this repository

  2. Open a Shell in the project root directory (the directory containing the docker-compose.yml

  3. Type in

Default Logins

These are the default users for demo systems. Make sure to deactivate them or change the passwords on productive systems:

Admin name: admin pw: sadmin

Surveillance Supervisor (web UI) name: SunkSesa pw: Sunkanmi

Surveillance Officer (mobile app) name: SanaObas pw: Sanaa

Advanced Installation

To change some parameters edit the .env before running the docker-compose

These Options are available to customize the installation:

Database

SORMAS_POSTGRES_USER: User for the SORMAS Databases

SORMAS_POSTGRES_PASSWORD: Password for this User

DB_NAME: Name of the database for the SORMAS data

DB_NAME_AUDIT: Name of the database for SORMAS audit data

DB_HOST: Hostname or IP if the database host

SORMAS

SORMAS_VERSION: Version of SORMAS that should be installed (Dockerimages are provided starting from the Version 1.33.0)

SORMAS_SERVER_URL: URL under which the SORMAS installation should be accessed

DOMAIN_NAME: Name of the Domain in the Payara Server

LOCALE: Default language of the SORMAS server

EPIDPREFIX: Prefix for the data

MAIL_HOST: Hostname or IP of the SMTP host

SEPARATOR: CSV separator

EMAIL_SENDER_ADDRESS: email from which the mail is going to be send

EMAIL_SENDER_NAME: Name of the sender of the email

LATITUDE: Latitude of the map center

LONGITUDE: Logitude of the map center

SORMAS_PATH: Path to store the Dockervolumes

Changing the host name

If you would like to run SORMAS using your own host name (e.g. https://sormas.example.com) , please follow these steps:

  1. obtain a certificate and private key for the chosen host name using e.g. letsencrypt

  2. copy the certificate file (e.g. fullchain.pem if you use letsencrpyt) to the ./apache2/certs directory using these filenames:

  • [hostname].crt for the certificate file (e.g. sormas.example.com.crt)

  • [hostname].key for the private key file (e.g. sormas.example.com.key)

  1. set the environment variable SORMAS_SERVER_URL to the hostname you have chosen

  2. make sure dns resolves to the host name you have chosen

  3. run

SORMAS should now be reachable via the given hostname.

CPU and memory usage limits and reservations

For all configuration options below, memory should be given as a positive integer number followed by an upper-case "M" - for example 1000M. CPU counts should be given as a floating point value with the dot ( . ) as decimal separator, for example "2.5".

APPSERVER_JVM_MAX: Maximum heap space to be used for the java application server used by SORMAS. (For example 4096M for 4096MB). APPSERVER_MEM: Maximum available memory for SORMAS application server. Should be set to be at least 150 MB above SORMAS_JVM_MAX. (For example 4300M for 4300MB) APPSERVER_MEM_RESERVED: Memory reserved for SORMAS application server. This memory may not be used by other processes on the same host. (For example 4300M for 4300MB) APPSERVER_CPUS: CPU cores reserved for the SORMAS java application server. This should be a floating point value. (Example: 2.0 )

WEBSERVER_MEM: Maximum available memory for the used web server.(For example 1000M for 1000MB) WEBSERVER_MEM_RESERVED: Memory reserved for the used web server. This memory may not be used by other processes on the same host. (For example 400M for 400MB) WEBSERVER_CPUS: CPU cores reserved for the used web server. This should be a floating point value. (Example: 2.0 )

DB_MEM: Maximum available memory for the used database server.(For example 3000M for 3000MB) DB_MEM_RESERVED: Memory reserved for the used database server. This memory may not be used by other processes on the same host. (For example 2500M for 2500MB) DB_CPUS: CPU cores reserved for the used web server. This should be a floating point value. (Example: 3.0 )

DB_DUMP_MEM: Maximum available memory for the database dump tool.(For example 500M for 500MB) DB_DUMP_MEM_RESERVED: Memory reserved for the database dump tool. This memory may not be used by other processes on the same host. (For example 100M for 100MB) DB_DUMP_CPUS: CPU cores reserved for the used web server. This should be a floating point value. (Example: 0.5 )

PostgreSQL upgrade notes

The following tips are for people who use the project's Docker images to host a SORMAS (PostgreSQL) database in their deployment.

With the release of v2.50 the default database engine version will change, PostgreSQL 10.18 will be replaced with PostgreSQL 14.9

Before using this update, you must migrate the data structures of the current PostgreSQL instance yourself.

Bearing in mind that each deployment may be different, below are some steps on how to perform such an update (please bear in mind that these instructions will need to be adapted to individual deployment conditions).

  1. You need to run a temporary container with PostgreSQL version 14.9 and indicate the local file system as the data storage location (please adjust the volume '/custom/mount' according to own environment)

  1. Run a 'pg_dumpall' command, pipe the output to feed the psql command within new container (please adjust the name 'current_postgresql_instance' to the ones used withing own environment).

  1. Stop the whole Docker application stack including temporary 'postgres_149' container

  2. Secure the initial (current_postgresql_instance) data folder (copy / archive)

  3. Copy the data related to postgres_149 volume as it was configured within current configuration of application stack

  4. You can start the application stack and use new 'postgresql' images (please keep in mind, that the underlying data was changes and it's required from now to use news postgres image)