Additional plugins can be added to the Docker container either during a custom Dockerfile build or on the fly during container startup. In both cases you can use the install-plugin command of the container:

/usr/share/product $ install-plugin --help
Usage install all Plugins: /bin/install-plugin -p <product> -v <version>
Usage install defined plugins: /bin/install-plugin -p <product> -v <version> <list of plugins to install>
Usage install BETA Plugins: /bin/install-plugin -p <product> -v <version> -b <list of plugins to install>
Usage install additional persistence: /bin/install-plugin -s <type>

Note: Plugin names can be derived, e.g. from the plugin store URL, specifically the path component after /pid: https://store.inetsoftware.de/pid/webapi.core → webapi.core

Note: There are distinct containers available for each persistence type. The MongoDB persistence is installed in the default container that has no additional tag. Available persistences are: mongodb, cosmosdb, dynamodb.

In a Dockerfile you can add the following lines to install a plugin:

# Add Web API plugin 
RUN install-plugin web.api

In a docker-compose.yml you can use the following setup to install a plugin:

version: '2.1'
services:
    service:
        command: >
            sh -c "
            install-plugin web.api &&
            ./startServer.sh -Dclearreports.config=User/Default -Dsetupautoexecution=true
            "

Note: the original startServer.sh command can be determined using docker inspect on an already running container.

Note: The example is incomplete and requires definition of the specific container.

In situations where the service is unresponsive, but the container can still be accessed, the server's subprocess can be terminated and restarted without restarting the whole container. In this case, the user has to enter the container using shell and run the following command:

ps xo pid,command | grep exitcode | grep -v grep | awk '{print $1}' | xargs -r kill -TERM

The Recovery Manager is a last-resort measure when the server was misconfigured. It can be used to fix configuration issues and remove plugins that produce unrecoverable startup issues. You can also update user information, e.g. fixing group assignments.

Important: The server is completely open to anyone who can access the host IP and port. This person can configure the system with administrative rights. You should consider using an additional firewall to secure the host port and only allow access to your own client host. Note that the -client.ip setting is not sufficient.

Note: Only a minimal set of features is available on the server, to allow you to recover from a startup issue. Not all plugins will be loaded.

Note: Your server must be run using the FORCE_IMPORT_CONFIG=1 environment variable (see mounting). Otherwise, when restarting the original server, it will overwrite the modified configuration.

Here is a step-by-step guide:

• Stop the server, but do not remove the server from docker.

# in a compose setup
docker compose stop
 
# or using classic docker command
docker stop <container-name>

• Check, which image the server was started with, e.g. using docker ps | grep <container-name>
• Check, which configuration the server was running with, e.g. using docker inspect <container-name> | grep DEFAULT_CONFIG or docker exec <container-name> env | grep DEFAULT_CONFIG. By default, that is User/Default
• Start the recovery server

docker run --rm -it --volumes-from "<container-name>" -p 9999:9999 --entrypoint /bin/sh "<container-image-name>" startRecovery.sh -clearreports.preferredconfig "User/Default" -port 9999 -client.ip "0.0.0.0-255.255.255.255"

• Access the server using http://<server-ip>:9999/
• When you are done with the configuration, stop the server using CTRL+c in the console.
• You can now restart the original service.

Here is a full explanation of the command:

• docker run –rm -it - we're running an additional sidecar container
• –volumes-from "<container-name>" - we're mounting the existing volumes from the service container. That is: the home directory, which, by default, holds the persistence and configuration.
• -p 9999:9999 - we're using the port 9999 to connect to the server externally and internally
• –entrypoint /bin/sh - the entry point must be updated to the default shell. Otherwise, the container will start by modifying the existing configuration
• "<container-image-name>" - this must be the same image as your service is running with
• startRecovery.sh - the recovery entry point script
• -clearreports.preferredconfig "User/Default" - this is the configuration we want to change. It is important, to have the same configuration as in the original server container. Otherwise, you will not be updating the correct settings.
• -port 9999 - the internal port the recovery configuration should run on
• -client.ip "0.0.0.0-255.255.255.255" - an IP access filter which you should definitely adjust to your network settings. If that filter does not match, the recovery configuration will not let you enter. Docker has the peculiarity of not necessarily recognizing the IPs of the environment - in this case the IP of your computer - correctly. It may therefore be necessary to specify a larger network as a share.

Note: The server is completely unsecured. It does not run with https / ssl encryption. It is fully open to any IP accessing this server. You should consider an additional firewall for the server and port to only allow access from your client host.