When deploying in production, mind the following points.
Set the entities time to live to a relevant value for the use case. Bigger it is, longer data will be kept (and accessible by the users), but bigger will be the storage needed by the database as well. The property to be set is the following: “optim-server.mongo.entities.ttl” and the value provided should be in seconds. To tune this property, the following environment variable should be used: OPTIMSERVER_MONGO_ENTITIES_TTL . By default, time to live is set to one week. An infinite time to live is set with a -1 value.
All the database usernames and passwords must be overridden, see the dbos-secrets chart.
Use Keycloak and not basic auth to handle authentication. Change the Keycloak configuration to suit your needs. In particular, the following environments variables need to be tuned: KEYCLOAK_USER, KEYCLOAK_PASSWORD and KEYCLOAK_IMPORT. By default, we initialize Keycloak with a json file, containing the “decisionbrain” realm, the “optimserver” client and some users. Here is the used realm.json file:
At least the users should be removed in favor of a Single Sign On configuration of Keycloak, for example (see Keycloak documentation).
A High Availability deployment might be needed. If it is, MongoDB, RabbitMQ and the Optimization Server master have to be deployed in cluster mode. The different instances of the master would have to use the same MongoDB cluster and the same RabbitMQ cluster. Let us note that the SSE endpoints, the web console, and the synchronous jobs are not compatible with HA mode yet.
By default, a worker stops when its underlying task throws an
java.lang.Error (not a
You can disable this behavior by setting the
WORKER_EXITONCRITICALERROR environment variable to
The JWT secret key must be changed. It is a 32 characters random string,
you can configure it on master with
OPTIMSERVER_JWTKEY and with
MASTER_JWTKEY on workers.