Provide docker image for agent, collector, and query service

[badiib]

Assuming there is a cassandra instance we can point to, we need to provide working docker images for:

• The Jaeger Agent
• The Jaeger Collector
• The Jaeger Query Service
• This task is complete when proof can be provided of all 3 services run, connect to a cassandra instance, and can consume traffic/display UI results.

[yurishkuro]

a travis job that

• builds images,
• runs Won's end-to-end test on them,
• publish if successful

[black-adder]

So I don't know why we need this before we have our discovery component built, I think that should be a priority.

[yurishkuro]

Why does it depend on discovery? We already have the ability to point agent to a single collector, once #137 is done we'll be able to point to many. But doing this PR is independent.

[black-adder]

No one is going to use jaeger with only static hosts

[yurishkuro]

I quite disagree. Zipkin has no support for discovery of any kind. A lot of companies are still running on pets, not cattle, static routing is perfectly fine. And there are other ways to load balance without having discovery built-in, e.g. DNS.

[xjerod]

I agree with @yurishkuro , running collectors behind a "static" endpoint like a load balancer or k8s service is perfectly reasonable (and our exact use case).

[jpkrohling]

I'm currently working on an OpenShift template for "production" usage. This includes setting up Cassandra, creating Dockerfiles and allowing each component to be started individually. The templates might also "just work" for Kubernetes (or need small adjustments).

My current approach is:

• DaemonSet for the Agent, so that there is one agent per node
• Stateful Set for Cassandra, so that pods have predictable names and orderly rollout, making the seed logic simpler
• Services for UI, Query and Collector, so that each component can be scaled up/down individually

I'm using the fabric8/alpine-caddy image for the UI, as I understand that it's the most appropriate image (at the moment) for static assets.

No one is going to use jaeger with only static hosts

On Kubernetes/OpenShift, people would just point to the service name, which happens to be exposed as a hostname. The internal DNS server will resolve to a "cluster IP", which then load balances the traffic among the pods, perhaps using some affinity logic (ie: route requests from pods on DC 1 preferably to other pods on DC 1). So, I'd say that static hosts are the proper way to do that in cloud native deployments.

[yurishkuro]

@jpkrohling we'd still need Docker images for all 3 backend components irrespective of where they run, correct?

[jpkrohling]

Correct. On my WIP branch, I have a Dockerfile for each of the modules (query, collector and agent).

[yurishkuro]

Solved by #157