When deploying in production, mind the following points.
Set the resource limits (CPU and memory) for all the containers (either in Docker, see Docker documentation, or in OpenShift, see OpenShift documentation).
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.
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 {{ projectname }} 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.