Additional parts of the environment in which your component is executed are specified below.
The following environment variables are injected in the container:
KBC_DATADIR: This is always
/data/in KBC; use this environment variable during component development to create development and testing environments.
KBC_RUNID: RunId from Storage; it couples all events within an API call (use this for logging)
KBC_PROJECTID: Id of the project in KBC within a KBC stack.
KBC_STACKID: Id of the KBC stack.
KBC_CONFIGID: Id of the configuration or hash of configuration data if the configuration is not named (
configDatawas used in API call).
KBC_COMPONENTID: Id of the component
The following variables are available only if “Forwards token” and “Forwards token details” are enabled in component configuration (and approved by us):
KBC_PROJECTNAME: Name of the project in KBC.
KBC_TOKENID: Id of the token running the container.
KBC_TOKENDESC: Description (user name or token name) of the token running the container.
KBC_TOKEN: The actual token running the container.
KBC_URL: The Storage API URL.
KBC_LOGGER_ADDR: IP address of GELF server
KBC_LOGGER_PORT: Port of the GELF server
The script defined in Dockerfile
CMD should provide an exit status. The
following rules apply:
exit code = 0The execution is considered successful.
exit code = 1The execution fails with a User Error; the contents of both STDOUT and STDERR will be sent to Storage API Events.
exit code > 1The execution fails with an Application Error and the contents of both STDOUT and STDERR will be sent to internal logs.
It is possible to modify the above behavior so that regardless of the exit code, all errors are User Errors.
This is done by setting
no_application_errors in component configuration.
See the implementation notes for tips on distinguishing
between a User Error and Application Error.