Deploy Bonita Runtime with Docker

How to install and use the Bonita Runtime docker distribution.

This guide assumes you have a working docker environment.

Quick start

To start the latest Community release - main versions only :

docker run --name bonita -d -p 8080:8080 bonita

To start the latest Subscription release - main and maintenance versions only:

To get access to the Bonita Docker Image, please contact Bonitasoft Customer Success at customer.success@bonitasoft.com. They will provide your credential to get access to the docker repository. Docker section of Access to Bonita Artifact Repository will give you more information to connect with these credentials.

docker login bonitasoft.jfrog.io
docker pull bonitasoft.jfrog.io/docker/bonita-subscription:2023.1
docker logout bonitasoft.jfrog.io
docker run --name=bonita -d -p 8080:8080 bonitasoft.jfrog.io/docker/bonita-subscription:2023.1

Documentation of the community docker image is available here.
Information on how to access the Bonita Artifact Repository can be found here.
You need to provide a valid licence, follow these steps in order to get and configure one.

Versioning

Multiple tags exist:

latest: Points to the latest version of the platform
2023.1: Points to the latest maintenance version of the 2023.1 version
2023.1-XXXX: Tag of a maintenance version of 2023.1

latest and 2023.1 are tags that change each time a new version of the platform is released. It is safer to use the more complete version tag 2023.1-XXXX when scripting deployments to ensure the binaries do not change.

Step-by-step installation procedure

Retrieve a licence

First generate a request key into a container with a specific hostname (-h):

docker run --rm --name=bonita -h <hostname> -ti bonitasoft.jfrog.io/docker/bonita-subscription:2023.1 /bin/bash ./generateRequestKey.sh

Answer the questions related to the license you want. This will print out the request key and exit automatically from the running container.

Retrieve the licence from the customer portal and place into one folder that will be mounted as a volume of the docker container. In this example, we will use ~/bonita-lic/..

cp ~/Downloads/BonitaSubscription-7.7-Cloud_Techuser-<hostname>-20170124-20170331.lic ~/bonita-lic/.

Alternatively, you can create a named persistent volume in docker for keeping license file. See docker documentation on volumes.

Start the container

Re-create a new Bonita container with the same hostname (-h) and this host directory mounted (-v) :

docker run --name bonita -h <hostname> -v ~/bonita-lic/:/opt/bonita_lic/ -d -p 8080:8080 bonitasoft.jfrog.io/docker/bonita-subscription:2023.1

This will only add the initial license to the Bonita Runtime. To renew a license on an existing installation see Update configuration and license section

This will start a container running the Tomcat Bundle with Bonita Runtime. As you did not specify any environment variables it’s almost like if you had launched the Bundle on your host using startup.{sh|bat} (with security hardening on REST and HTTP APIs, cf Security concerns). It means that Bonita uses a H2 database here.

You can access the Runtime on http://localhost:8080/bonita and login using the default credentials : install / install

Start the container interactively

You may also run the Bonita container with an interactive shell session in order to control start and stop of the Tomcat bundle. Although the main usage of the Docker image is to automatically start the Bonita runtime, manually start and stop Tomcat may be useful for development or troubleshooting purposes.

Run the container as follows in order to get an interactive bash shell session:

docker run --name bonita -it -p 8080:8080 bonita bash

Subscription release

docker run --name bonita -h <hostname> -v ~/bonita-lic/:/opt/bonita_lic/ -it -p 8080:8080 bonitasoft.jfrog.io/docker/bonita-subscription:2023.1-XXXX bash

Then run /opt/files/startup.sh inside the container to start Tomcat. In order to stop Tomcat inside the container, press Ctrl-C.
Repeat this sequence to manually start and stop Tomcat in the container.

Link Bonita to a database

The H2 database allows the Bonita container to work out of the box, but it is not recommended outside a development environment.

As PostgreSQL is the recommended database for qualification and production environments, follow one of these next sections to configure your Bonita container to run on PostgreSQL database. You can work with either a PostgreSQL Container, or PostgreSQL as an installed service.

PostgreSQL Container

From Bonita 2022.1 onwards, the Bonita docker image does not include configuration scripts for Postgres

Therefore the PostgreSQL container needs to be configured to work with Bonita before starting the Bonita container. The configuration of a PostgreSQL database to work with Bonita is described in detail in the database configuration page.
Alternatively, Bonita provides a preconfigured PostgreSQL image on docker-hub.
You can run the image with the following command:

docker run --name mydbpostgres -d bonitasoft/bonita-postgres:12.6

This image is built from the following GitHub repository, which can be further adapted/customized to suit your needs.

Using docker compose

Create a file docker-compose.yml with the following content

# Use tech_user/secret as user/password credentials
version: '3'

services:
  db:
    image: bonitasoft/bonita-postgres:12.6
    environment:
      POSTGRES_PASSWORD: example
    restart: always
    command:
      - -c
      - max_prepared_transactions=100
  bonita:
    image: bonitasoft.jfrog.io/docker/bonita-subscription:2023.1
    hostname: <hostname>
    volumes:
      - ~/bonita-lic:/opt/bonita_lic/
    ports:
      - 8080:8080
    environment:
      - DB_VENDOR=postgres
      - DB_HOST=db
      - DB_PORT=5432
      - DB_NAME=bonita
      - DB_USER=bonita
      - DB_PASS=bpm
      - BIZ_DB_NAME=business_data
      - BIZ_DB_USER=business_data
      - BIZ_DB_PASS=bpm
      - TENANT_LOGIN=tech_user
      - TENANT_PASSWORD=secret
      - PLATFORM_LOGIN=pfadmin
      - PLATFORM_PASSWORD=pfsecret
      - MONITORING_USERNAME=monitorAdmin
      - MONITORING_PASSWORD=monitor_Secr3t-P455w0rD
    restart: on-failure:2
    depends_on:
      - db
    entrypoint:
      - bash
      - -c
      - |
        set -e
        echo 'Waiting for PostgreSQL to be available'
        maxTries=10
        while [ "$$maxTries" -gt 0 ] && [ $$(echo 'QUIT' | nc -w 1 "$$DB_HOST" 5432; echo "$$?") -gt 0 ]; do
            sleep 1
            let maxTries--
        done
        if [ "$$maxTries" -le 0 ]; then
            echo >&2 'error: unable to contact Postgres after 10 tries'
            exit 1
        fi
        exec /opt/files/startup.sh /opt/bonita/server/bin/catalina.sh run

Replace <hostname> with the one used in the licence generation command
Replace ~/bonita-lic with the folder containing the license (on Windows use / and avoid ~)
leave double $$ untouched

Run docker compose up, wait for it to initialize completely, and visit http://localhost:8080, or http://host-ip:8080 (as appropriate).

PostgreSQL as an installed service

If you don’t want to run your database in a docker container, the following file env.txt needs to be configured and provided to the docker run command:

DB_VENDOR=postgres
DB_HOST=172.17.0.2
DB_PORT=5432
DB_NAME=custombonitadb
DB_USER=custombonitauser
DB_PASS=custombonitapass
BIZ_DB_NAME=custombusinessdb
BIZ_DB_USER=custombusinessuser
BIZ_DB_PASS=custombusinesspass

docker run --name=bonita -h <hostname> --env-file=env.txt -d -p 8080:8080 bonitasoft.jfrog.io/docker/bonita-subscription:2023.1

Start Bonita with custom security credentials

docker run --name=bonita -v ~/bonita-lic:/opt/bonita_lic/ -h <hostname> -e "TENANT_LOGIN=tech_user" -e "TENANT_PASSWORD=secret" -e "PLATFORM_LOGIN=pfadmin" -e "PLATFORM_PASSWORD=pfsecret" -e "MONITORING_USERNAME=monitorAdmin" -e "MONITORING_PASSWORD=monitor_Secr3t-P455w0rD" -d -p 8080:8080 bonitasoft.jfrog.io/docker/bonita-subscription:2023.1

Now you can access the Bonita Runtime on localhost:8080/bonita and login using: tech_user / secret

Secure your remote access

This docker image ensures to activate by default static (all editions) and dynamic authorization checks (Subscription editions only) on REST API. To be coherent it also deactivates the HTTP API. But for specific needs, like exposing directly the Runtime APIs through HTTP (not to be mixed up with the REST API), you can override this behavior by setting HTTP_API to true:

docker run -e HTTP_API=true -e HTTP_API_PASSWORD=S0me-h11p-s3cr3t --name bonita -v ~/bonita-lic:/opt/bonita_lic/ -h <hostname> -d -p 8080:8080  bonitasoft.jfrog.io/docker/bonita-subscription:2023.1

Environment variables

When you start the bonita image, you can adjust the configuration of the Bonita instance by passing one or more environment variables on the docker run command line.

PLATFORM_PASSWORD

This environment variable is recommended for you to use the Bonita image. It sets the platform administrator password for Bonita. If it is not specified, the default password platform will be used.

PLATFORM_LOGIN

This optional environment variable is used in conjunction with PLATFORM_PASSWORD to define the username for the platform administrator. If it is not specified, the default username platformAdmin will be used.

TENANT_PASSWORD

This environment variable is recommended for you to use the Bonita image. It sets the tenant administrator password for Bonita. If it is not specified, the default password install will be used.

TENANT_LOGIN

This optional environment variable is used in conjunction with TENANT_PASSWORD to define the username for the tenant administrator. If it is not specified, the default username install will be used.

MONITORING_USERNAME

This optional environment variable is used in conjunction with MONITORING_PASSWORD to define the access to endpoints protected with BASIC Auth access: the Monitoring endpoint, the JMX publisher, and the API health endpoints. If it is not specified, the default monitoring username monitoring will be used.

MONITORING_PASSWORD

This optional environment variable is used in conjunction with MONITORING_USERNAME to define the access to endpoints protected with BASIC Auth access: the Monitoring endpoint, the JMX publisher, and the API health endpoints., the default monitoring password mon1tor1ng_adm1n will be used.

REST_API_DYN_AUTH_CHECKS

Removed & does not work anymore, now you can use BONITA_RUNTIME_AUTHORIZATION_DYNAMICCHECK_ENABLED instead.

BONITA_RUNTIME_AUTHORIZATION_DYNAMICCHECK_ENABLED (Subscription editions only)

This optional environment variable is used to enable/disable dynamic authorization checking on Bonita REST API. The default value is true, which will activate dynamic authorization checking.

HTTP_API

This optional environment variable is used to enable/disable the Bonita HTTP API. The default value is false, which will deactivate the HTTP API. From Bonita 2022.1, HTTP API is protected with Basic access authentication. See the following 2 parameters to configure Basic access authentication.

HTTP_API_USERNAME

This optional environment variable is used to configure the HTTP API Basic access authentication username. The default value is http-api.

HTTP_API_PASSWORD

This optional environment variable is used to configure the HTTP API Basic access authentication password. There is no default value, and providing a value is mandatory if HTTP_API=true.

JMX_REMOTE_ACCESS

This optional environment variable is used to enable/disable the access to the JMX console from a remote machine.
Default value is false.
The host to connect to is the name / IP address of the bonita server, the port to connect to is 9000.
The credentials to connect are the environment variables MONITORING_USERNAME, MONITORING_PASSWORD.

REMOTE_IP_VALVE_ENABLED

This optional environment variable allows to activate/deactivate reverse proxy redirection. Default value is false.

ACCESSLOGS_STDOUT_ENABLED

This optional environment variable allows to activate/deactivate writing Tomcat access logs to standard output. Default value is false.

ACCESSLOGS_FILES_ENABLED

This optional environment variable allows to activate/deactivate writing Tomcat access logs to a specific file. When activated, will write those logs to /opt/bonita/logs/ inside the docker container. In practice, it is only useful when mounting a volume to the aforementioned directory. Default value is false.

ACCESSLOGS_PATH

If ACCESSLOGS_FILES_ENABLED=true, this optional environment variable overrides the default path to of the access log file. Default value is /opt/bonita/logs.

ACCESSLOGS_PATH_APPEND_HOSTNAME

If ACCESSLOGS_FILES_ENABLED=true, this optional environment variable allows to append a subdirectory with the hostname to the full path of the directory to put access log files into. Default value is false.

ACCESSLOGS_MAX_DAYS

If ACCESSLOGS_FILES_ENABLED=true, this optional environment variable allows to automatically delete access log files after a certain number of days. Default value is 30.

HEAPDUMP_PATH

This optional environment variable overrides the default path of the heap dump file. Default value is /opt/bonita/logs.

HTTP_MAX_THREADS

This optional environment variable allows to specify the maximum Http thread number Tomcat will use to serve HTTP/1.1 requests. Directly modifies the maxThreads parameter in the server.xml file of the Tomcat inside the docker container. More information on the usefulness of this parameter can be found here. Default value is 20.

JAVA_OPTS

This optional environment variable is used to customize JAVA_OPTS. The default value is -Xms1024m -Xmx1024m. The syntax to use is -e JAVA_OPTS="-Xms2048m -Xmx2048m"

DB_VENDOR

This environment variable is automatically set to postgres or mysql if the Bonita container is linked to a PostgreSQL or MySQL database using --link. The default value is h2. It can be overridden if you don’t use the --link capability.

DB_HOST, DB_PORT

These variables are optional, used in conjunction to configure the bonita image to reach the database instance. There are automatically set if --link is used to run the container.

BONITA_DS_CONNECTION_POOL_INITIAL_SIZE, BDM_DS_CONNECTION_POOL_INITIAL_SIZE

Change the default value for the Bonita and/or the BDM datasource initialSize. This is the initial number of connections when the connection pool starts.

BONITA_DS_CONNECTION_POOL_MAX_TOTAL, BDM_DS_CONNECTION_POOL_MAX_TOTAL

Change the default value for the Bonita and/or the BDM datasource maxTotal. This is the maximum number of active connections that can be allocated from this pool at the same time.

BONITA_DS_CONNECTION_POOL_MIN_IDLE, BDM_DS_CONNECTION_POOL_MIN_IDLE

Change the default value for the Bonita and/or the BDM datasource minIdle. This is the minimum number of active connections that always established after pool created and connection has reached this size.

BONITA_DS_CONNECTION_POOL_MAX_IDLE, BDM_DS_CONNECTION_POOL_MAX_IDLE

Change the default value for the Bonita and/or the BDM datasource maxIdle. This is the maximum number of connections that should be kept in the pool at all times.

DB_NAME, DB_USER, DB_PASS

These variables are used in conjunction to create a new user, set that user’s password, and create the bonita database.

DB_NAME default value is bonitadb.

DB_USER default value is bonitauser.

DB_PASS default value is bonitapass.

BIZ_DB_NAME, BIZ_DB_USER, BIZ_DB_PASS

These variables are used in conjunction to create a new user, set that user’s password and create the bonita business database.

BIZ_DB_NAME default value is businessdb.

BIZ_DB_USER default value is businessuser.

BIZ_DB_PASS default value is businesspass.

BONITA_SERVER_LOGGING_FILE, BONITA_SETUP_LOGGING_FILE

DEPRECATED See how to configure logger

Since Bonita 7.9 BONITA_SERVER_LOGGING_FILE and BONITA_SETUP_LOGGING_FILE can be used to update logging configuration.

BONITA_SERVER_LOGGING_FILE default value is /opt/bonita/conf/logs/log4j2-appenders.xml,/opt/bonita/conf/logs/log4j2-loggers.xml

BONITA_SETUP_LOGGING_FILE default value is /opt/bonita/setup/logback.xml

INSTALL_PROVIDED_PAGES

When building a Self Contained Application, Bonita Admin Application and Bonita User Application are no longer installed after the packaging process. If your custom application is using pages from one of those applications, set this property to have those pages installed anyway at Bonita Runtime startup.

Default value is false.

Logger configuration

To ease the logger configuration, you can mount a volume on folder /opt/bonita/conf/logs containing the configuration files:

docker run -v ~/my-config/log4j:/opt/bonita/conf/logs ...

The volume must contain the 2 files log4j2-loggers.xml and log4j2-appenders.xml

Log4j2 automatically reloads configuration files when there is a change. However, if the file is invalid, the initial version of that file is used instead, and is not reloaded unless one of the other watched file is changed.

If not user is specified to create the container (--user), the filesystem access rights are downgraded to allow only the bonita user (inside the Docker container), meaning that a standard user cannot access the log4j2 configuration folder on the host machine (~/my-config/log4j in this example) anymore. Make sure to access it as a "sudoer" to hot-modify the logger configuration, or specify a dedicated user when creating the container:

docker run --user <my-dedicated-bonita-user> -v ~/my-config/log4j:/opt/bonita/conf/logs ...

CLUSTER_MODE

This environment variable activates the Cluster mode on Bonita, allowing to start several nodes that will join the cluster.

This will automatically disable Hibernate L2 cache.

Migrating from an earlier version of Bonita

The migration scripts affect only the database, not the Bonita instance. The procedure to migrate a Bonita container is therefore as follow:

Stop and destroy the running Bonita container.
Play the migration script on your Bonita database see migrate the platform from an earlier version of Bonita.
Get the new Bonita docker image, as explained above.
Update the license, see Update configuration and license section
Start a new Bonita container.

Update configuration and license

Once renewed from Bonita Customer Portal, the license file and the configuration files are updated using the Setup tool.

Setup tool can be used outside the Docker container directly by downloading the Tomcat bundle and running it from there.

The setup tool needs to be able to access the database. Because of that, if the database is in a docker container, its port must be exposed to the host.

See setup tool page for more information.

Troubleshoot and debug problems inside a Docker container

Bonita 2023.1 docker image comes with a set of tools embedded, jattach, that allows to interact with the Tomcat JVM inside a Bonita container via Dynamic Attach mechanism.

Example of useful commands it supports, that you can run from outside the container, include:

docker exec <CONTAINER_NAME> jattach 1 jcmd VM.flags to see all JVM flags passed to Bonita Tomcat JVM:

Connected to remote JVM
JVM response code = 0
-XX:CICompilerCount=4 -XX:ConcGCThreads=2 -XX:G1ConcRefinementThreads=8 -XX:G1HeapRegionSize=1048576 -XX:GCDrainStackTargetSize=64 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/bonita/server/logs

docker exec <CONTAINER_NAME> jattach 1 properties to see all System properties that Java will use:

Connected to remote JVM
JVM response code = 0
#Fri Sep 10 14:03:16 GMT 2021
com.arjuna.ats.arjuna.common.propertiesFile=/opt/bonita/server/conf/jbossts-properties.xml
sysprop.bonita.bdm.db.vendor=h2
awt.toolkit=sun.awt.X11.XToolkit
java.specification.version=11
sun.cpu.isalist=
sun.jnu.encoding=ANSI_X3.4-1968
java.class.path=/opt/bonita/server/lib/ext/bonita-tomcat-juli-8.0.0.jar\:/opt/bonita/server/bin/bootstrap.jar\:/opt/bonita/server/bin/tomcat-juli.jar
sysprop.bonita.db.vendor=h2
java.vm.vendor=Ubuntu

Read the official jattach documentation for a complete list of supported commands.