The storage classes are responsible for storing previous consul watch output. Even though multiple backends are supported, you will only ever have one backend enabled and configured at a time. This is needed so that future runs of consul watch can compare output with previous watch runs. The entire purpose of the consul_watcher project is to create this diff and send it to a destination.
The most basic form of storage is the disk storage class. The behavior of this class is driven by the configuration file. Please see the detailed disk class documentation for configuration options.
Since we know for sure that consul is installed and running, it is probably a good idea to enable consul kv as a backend storage type. The main concern here is that we need to make sure we ignore the storage path from the consul watch, so we do not get into an infinite watch loop. The consul storage class is responsible for reading and writing previous json runs in the consul kv store. Configuration for this is tricky as we need to drive the docker entrypoint with environmental variables. The docker entrypoint is what is running the consul watch command, so it needs access to consul environmental variables. The direction is to start using the configuration files for all things related to the ruby script. For now the consul_watcher will only look at the configuration file for consul backend settings. This will lead to duplicated settings (env vars and config file). The behavior might change in the future (allow env var references in config file for example).