You are viewing the RapidMiner Hub documentation for version 10.2 - Check here for latest version
Docker images for RapidMiner StandPy
The documentation below describes the images implementing RapidMiner StandPy, which is a component consisting of the following Docker images:
You can read a description for each container below.
These containers are only functional when deployed together, they will not function as intended individually. Check out the RapidMiner StandPy deployment guide to see how these should be deployed.
StandPy Router
This container implements proxy functionality which exposes the StandPy containers to other components of the RapidMiner AI Hub. A single router is sufficient to serve multiple StandPy containers.
For available versions, please see the tags on Docker Hub.
Configuration
- Volumes: none
- Ports: none.
- Networks: this container is the bridge between the AI Hub docker network and the StandPy docker network, so both need to be added.
- Environment variables:
ENGINE_<ENGINE_NAME>_HOST: the docker hostname of the StandPy container which should be served by this router.ENGINE_<ENGINE_NAME>_TOKEN: the optional security token (passphrase) which can be used for securing the StandPy container.
In the above variables, the <ENGINE_NAME> provided will be used by the router to direct requests to the StandPy container at http://<router-alias>/<engine_name>.
StandPy Container
This container implements a single StandPy execution engine, which can serve requests using a centrally managed Python environment specified by the user.
For available versions, please see the tags on Docker Hub.
Configuration
- Volumes
rm-coding-shared-vol:/opt/coding-shared:ro: volume mount to access the centrally managed Python environments.
- Ports: none.
- Networks: should only be accessible on the internal docker network created only for StandPy containers.
- Environment variables:
CONDA_ENV: name of the Python environment, as defined in Platform Admin.WORKERS: number of worker threads. used to serve incoming requests. Optional, defaults to 1.TIMEOUT: timeout, in seconds, for each incoming execution request. Optional, defaults to 30 seconds.MAX_REQUESTS: the number of requests after which a worker thread is restarted. Optional, if not provided, workers are never restarted. Set this to a low number for cleaner execution and a tradeoff in latency.