Closed llinder closed 7 years ago
I've been thinking about your suggestion on the layered approach in Docker. I really like this idea though it does have the draw back of not being able to perform tests on the fat jar. Using the Spring Boot tests seem to be a nice way to ensure the configuration changes instantiate the correct beans. Of course the draw back is duplicate tests and pom configuration.
I guess I don't have a strong preference either way though the POM configuration is a little more predictable in my opinion. Also its easier to run things locally and debug as apposed to layering jar files in Docker.
For what its worth I am running this Docker build in production now and things are working well so far.
I think if we are going to make a server project here, we should name it zipkin-server-aws? Still hoping we can give a choice of a layered approach, though maybe it isn't valuable enough. @bsideup is our docker testing guru.. maybe he has ideas.
Plus we do have an existing practice of setting up docker-X repos which have an advantage and disadvantage. Ex we have to align publishing, but we can change them incidental to eachother and sometimes the change to docker doesn't require java knowledge.
At any rate, if we think this zipkin-server-aws type of thing is good enough, maybe let's do it. I'd hate to let best be the enemy of good.
@llinder @adriancole FYI Spring Boot's fat jars feature is not a problem: http://bsideup.blogspot.com.ee/2015/04/spring-boots-fat-jars-vs-docker.html
@bsideup thanks for the link. @adriancole I'm not a huge fan of the duplication required for the server build here either. I will give the layered Docker approach a shot and hopefully have something working later this week.
anybody have time to rebase this?
I probably can rebase tomorrow. Was caught up in some other tasks but I might be able to revisit changing this to a more layer approach over the holidays. If I split this up should the Docker file go in the docker-zipkin repo?
Thanks, Lance. I added https://github.com/openzipkin/docker-zipkin-aws which could take the same form as docker-zipkin-dependencies. I think that will be best eventhough it separates the files out. Particularly, those with docker expertise can ignore the java component details.
Closing this in favor of a simplified PR. Once these changes are merged https://github.com/openzipkin/zipkin-aws/pull/28 I will open a new PR that just includes an executable jar build with AWS dependencies. The Dockerfile is moving to https://github.com/openzipkin/docker-zipkin-aws and I will open a PR once a snapshot of the executable jar is published.
This is still work in progress but wanted to get it out for discussion.Basically this is a copy an paste of our internal build of Zipkin Server that includes AWS dependencies.This also deviates from how current Zipkin docker builds are handled. I'm not expecting that folks will want to adopt this approach but thought it was worth sharing. One advantage of keeping the Dockerfile local to the project is that the docker build can happen as part of a release instead of requiring a separate release step.