add all opentracing providers to the container build

[szuecs]

https://github.com/zalando/skipper/releases/tag/v0.10.70 added lightstep opentracing container, but we should also add jaegr and instana that we already implemented in https://github.com/skipper-plugins/opentracing

[mikkeloscar]

To follow up on your comment here: #763 (comment) it probably is worth considering moving the tracer plugins into this repository if we are going to build the images from here anyway.

The plugins doesn't really give any benefit because:

1. Must be build against the same libc as skipper binary
2. Must be build against the exactly same version of dependencies.

having it in one repository would solve 2. automatically and make 1. more natural as they would be built together anyway.

[szuecs]

@mikkeloscar I think @aryszka had the idea of having them imported as library. I thought about having it similat to "db" (name correct?) package in Go, that use an unamed import to init() the actual implementation of the db driver.

[arjunrn]

Must be build against the exactly same version of dependencies.

@mikkeloscar It actually get's worse than that. If the plugin or the main package uses vendored dependencies then there is a mismatch of types for the common dependency as described by this issue here. In this case, the opentracing-go dependency which common to the main package and the plugins. So yes, I would recommend that we move the plugins to this repository make it part of the same top-level module. It may work but I'm not certain.

[aryszka]

I agree that it is simpler to use the tracers as a lib in many cases. OTH, not sure of referencing here something that is only an opensource client library that is not useful on its own because it is only a client of an otherwise proprietary service. What do you think about this?

[szuecs]

We published all tracing providers in docker containers.
Discussions can be done in comments or mailing list or slack.