If I want to add a custom, very specific-to-me Source implementation to Hindsight, I can bake it into an extending Docker image and Hindsight will pull it into the system.
# my_plugins/foo.ex
defmodule Foo do
defstruct [:bar, :baz]
defimpl Source do
# ...
end
end
FROM inhindsight/hindsight:latest
COPY my_plugins/ plugins/
$ docker build -t myhindsight:extended .
All Hindsight services started in the myhindsight/hindsight image will compile and load plugins on startup. And so, the Foo destination is available for use throughout the system. This should work for any/all protocol implementations.
If a plugin file can't be compiled, applications will blow up immediately so users can't continue on the assumption that everything is OK. If no plugins exist or the directory is missing (local dev), Hindsight considers everything fine.
Some things to consider:
I'm not testing this through the Docker layer beyond manually.
Developing a custom impl will be a PITA since that code base will have no reference to our protocols without recreating them.
Deploying via Helm will require image.repository and image.tag to be set to the extended image values.
If I want to add a custom, very specific-to-me
Source
implementation to Hindsight, I can bake it into an extending Docker image and Hindsight will pull it into the system.All Hindsight services started in the
myhindsight/hindsight
image will compile and load plugins on startup. And so, theFoo
destination is available for use throughout the system. This should work for any/all protocol implementations.If a plugin file can't be compiled, applications will blow up immediately so users can't continue on the assumption that everything is OK. If no plugins exist or the directory is missing (local dev), Hindsight considers everything fine.
Some things to consider:
image.repository
andimage.tag
to be set to the extended image values.