Uses STORAGE_TYPE variable to decouple span storage implementations

[codefromthecrypt]

Users can now assign STORAGE_TYPE as cassandra or mysql to start zipkin on the corresponding backend.

Fixes #56

[codefromthecrypt]

This is ready to go. If you want to test locally prior to merge, paste the following, then use docker-compose

docker build -t quay.io/openzipkin/zipkin-base:base-1.17.1 base
for I in cassandra mysql collector query web
  do docker build -t openzipkin/zipkin-$I:1.17.1 $I
done

[codefromthecrypt]

ps I think it is time we switch the default docker-compose file to mysql. The goal of docker-compose was our 5m story. MySQL is the fastest way to tell the story of zipkin, particularly as it has no setup required to show the Dependencies view.

I'm glad we have cassandra, as people may quickly outgrow mysql, but I feel we should put easiest as the first option forward.

@jamescway @michaelsembwever @kristofa @abesto @jfeltesse-mdsol @spencergibb @dsyer @vprithvi (plus anyone else) thoughts either way?

[spencergibb]

:+1:

[abesto]

I love where this is heading. One thing I'd do differently is de-duplicate the stuff in docker-compose{,-mysql}.yml using https://docs.docker.com/compose/extends/, maybe even go as far as having docker-compose-{common,mysql,cassandra}.yml. The trade-off in the latter case is of course that users will need to keep typing -f $FILE, which may or may not be an issue.

Also: sorry for the late reply :innocent:

[codefromthecrypt]

@abesto Right now, I think the default docker-compose file shouldn't be complicated, even if we keep a normalized one for testing variants.

It is so easy to make things accidentally complex when trying to normalize things. What if we keep the "front-door" file simple, and make a new file for testing variants? That way, we retain a straight-forward, non-advanced 5 minute story.

To get into details, I was thinking about was making the default docker-compose.yaml use whatever the default backend is (I think it should be mysql). In this case, we can even eliminate the STORAGE_TYPE variable, defaulting to mysql. I see value where you're going with breaking up the compose files, but I think it is slightly early for that. I suspect we will break this approach when we do kafka, which I hope we do next.

[codefromthecrypt]

@abesto punting normalized files https://github.com/openzipkin/docker-zipkin/issues/60

[codefromthecrypt]

punting decision to switch default storage to mysql https://github.com/openzipkin/docker-zipkin/issues/61

[abesto]

Good points, I'm totally OK with doing things this way. Thanks a lot for the thoughtful explanation!