Components use several channels to exchange information with Keboola Connection,
primarily structured folders and configuration files.
Each component has full access to the outside network (network type
bridge), unless changed to
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
KBC_CONFIGROWID: Id of the configuration row if available.
KBC_BRANCHID: Id of the development branch.
azuredepending on which kind of Stack the container is running. The value refers to the file storage used during file import end export operations.
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_REALUSER: Id of the user provided by a SAML authentication.
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.