Provide docker image for agent, collector, and query service about jaeger HOT 10 CLOSED

a travis job that

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

from jaeger.

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

from jaeger.

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.

from jaeger.

No one is going to use jaeger with only static hosts

from jaeger.

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.

from jaeger.

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).

from jaeger.

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.

from jaeger.

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

from jaeger.

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

from jaeger.

Solved by #157

from jaeger.