added a docker-compose file to the main repo, and an explanation regarding its usage to the docs #306
Conversation
de-robat
requested review from
black-adder,
oibe,
vprithvi and
yurishkuro
as code owners
|
|
|
I believe that the most appropriate way would be to create a repository under the Jaeger Tracing organization, like it's done for the OpenShift and Kubernetes templates: |
|
@jpkrohling That's what i wanted to do as well. I checked back with @yurishkuro . So my original question asked on gitter has been:
The response was that putting it under /cmd/ in the main repo might be a good idea. But still there are open questions regarding the test integration. I opened this PR mainly to document the advances we made regarding the compose-file an make it accessible to others as well. So lets continue the discussion of the proper way to contribute it here, to render the decision making process more transparent. Pardon me for not starting it here in the first place. |
crossdock could extend this compose file. By doing this we don't have to implement any additional tests. |
| command: /go/bin/agent-linux -collector.host-port=jaeger-collector:14267 | ||
| jaeger-query: | ||
| image: jaegertracing/jaeger-query:0.5 | ||
| networks: |
There was a problem hiding this comment.
yep, you need to name the network even if its configuration is basically an empty object. you could configure some stuff here, but we don't need anything beside the defaults. So we are just creating the network with the name we are using above.
There was a problem hiding this comment.
you probably noticed my comment is intended to be for line 69 :) The correct answer for this line is: the query joins the network to reach the cassandra db as it will inject the name resolving for -cassandra.servers=cassandra
| restart: unless-stopped | ||
| command: /go/bin/collector-linux -cassandra.servers=cassandra -cassandra.keyspace=jaeger_v1_dc1 -cassandra.connections-per-host 2 | ||
| jaeger-agent: | ||
| image: jaegertracing/jaeger-agent:0.5 |
There was a problem hiding this comment.
given that "compose" is unlikely to be used for production, perhaps latest image would be better here?
@pavolloffay but even with latest I don't think this can be used as a base for crossdock test since the crossdock should build the images from the current source code.
There was a problem hiding this comment.
I could simply override image configuration https://docs.docker.com/compose/extends/#adding-and-overriding-configuration.
Or crossdock target could compile images, and run the compose.
There was a problem hiding this comment.
think it could be altered to do a live build, https://docs.docker.com/compose/compose-file/compose-file-v2/#build for the image on the test infrastructure, but i'm not 100% aware of all build prerequisites for the jaeger components to build. For the purpose of handing it over to people who are interested in trying out the setup with all components (not the standalone way), i'd rather vote for fixed versions, but that would indeed be followed by regular updates. Given the test run properly, than "latest" wouldn't be an issue. But that's a bit out of scope for me. So probably two docker files? Or even more? There is a stack up and coming with ES, and most likely you won't have the agent on the collectors Infrastructure neither. So probably the jagertracing org would indeed be a better fit.
For production environments i'll soon setup a rancher catalog and add it to the rancher repo anyways.
|
done in #493 |
I wan't to provide a docker-compose file to conveniently start a jaeger stack in a docker environment. This PR does resolve #286 as it yields the results of the issues findings.