Watchdog runs as the root process inside container, and ensures the desired data, inputs, environment, is prepared for the plugin.
How it works?
Watchdog acts similar to systemd, initd, or any other process manager. When you publish a new plugin in the form of a docker image / package, our engine injects watchdog binary inside the container, and hereby it takes control over the context. watchdog overrides the ENTRYPOINT or CMD instruction, and runs as the bootstrapping ENtRYPOINT. After it's inception, it proxies the received instruction to the desired CMD or ENTRYPOINT that were defined prior. From here on everything works as expected, as it should.
Usage
Note: Watchdog's runs as the root process inside container with PID 0, and forks the desired plugin. All the interaction between the tool and hosts happens via watchdog.
All the configurable parameters can be injected via command-line arguments or environment variables. If both are present, environment variables overrides command lie arguments.
Absolute root path. All the other path variables will be relative to BASEPATH.
INPUTPATH
Absolute path to the base input directory.
OUTPUTDIR
Absolute path to the base output directory. Once your plugin exits gracefully, the output directory is synced-in with persistent storage, and data can later be accessed via user, or another plugin.
RESULTSJSON
Absolute path to which the process should save / publish final results. The data needs to be a valid JSON file. The results are stored in the database, and are used as main source of truth. If the file is not present, it is assumed that the plugin failed to finish the task, or encountered an exception while running, even if the exit was graceful.
Make sure to create a valid JSON file if the plugin finished the task successfully.
LOGTOFILE
Accepts a boolean value with default value of false. If the value is true, STDOUTFILE and STDERRFILE are used as the source for logs, else STDOUT and STDERR pipes are used.
One of the use case can be, when you have a plugin that outputs tremendous amount of log data, specific / filtered & useful logs can be piped to STDOUTFILE and STDERRFILE.
It is recommended to output only required data in logs, as it can slow down the process due to I/O congestion.
STDOUTFILE
If LOGTOFILE is set to a value of true, STDOUT pipe is ignored and file pointing to STDOUTFILE is used.
STDERRFILE
If LOGTOFILE is set to a value of true, STDOUT pipe is ignored and file pointing to STDERRFILE is used.
ENABLELOGGING
Accepts a boolean value, which if set to false , logging is disabled and not persisted / streamed. (Default: true)
OUTPUTSCHEMA
Path to a valid JSON Schema, which is used a validation source for content inside RESULTSJSON, and only persisted if is valid.
IfOUTPUTSCHEMA points to a path that does not contain a valid JSON Schema file, any data is accepted and persisted, but it creates a hassle for other plugins to use the output data as an input source. If you want the plugin to be used by others, it is recommended to define JSON Schema before publishing your plugin.