refactor to run containers as executables

[woodsaj]

This change removes supervisord from a bunch of images and instead runs each container as an executable.

This has a lot of added benefits

1) execution of the binaries is wrapped by wait.sh, so that you can just pass a comma separated list of host:ports to wait for before starting the executable via environment variable "WAIT_HOSTS". 2) after modifying code and rebuilding you just need to restart the container. eg docker restart raintank_eventtank_1 3) The images should just work outside of the raintank-docker environment. Moving forward i would like split containers up over a few different docker-compose configs (fig.yaml). So for example, you could just bring up the stack without the benchmark tools running. 4) For each file in the "screens" directory, if the file begins with an underscore "_", then the commands are run on the host and not in a shell of the container.

down side

1) logs are now only accesable via docker logs -f raintank_eventtank_1 which is only a problem if you want to grep across all logs for something. This of course can be addressed easily enough by just changing the screens command to something like docker logs -f raintank_eventtank_1 |tee logs/eventtank.log

[woodsaj]

this commit also completely removes NSQ

[woodsaj]

@Dieterbe how do you feel about this?

[Dieterbe]

• big +1 on removing supervisord, it's pretty useless at this point.
• bye NSQ. you will be missed
• logs are pretty important to me. esp. MT/cassandra. i often need to seek throughout the entire logfile and want to stay able to do this. I think this can be done with docker log but not sure if it retains the entire history. just running docker log -f foo > logs/somefile would work too i suppose, or patching MT to support logging to a file which then can be volume mounted.
• one thing i always liked back in the day litmus was a fork of grafana, and i was basically developing on grafana, is how it would auto-recompile and auto-restart itself using bra when there was a code change. such a model wouldn't work well anymore now (cause you'd have to dirty the project repo with changes to the bra config, which gets annoying when doing git operations). for tools like carbon-relay-ng this would be nice to have (not necessarily for MT because it's so stateful and i don't want to restart it for every code change)
• are we now explicitly acknowledging that, besides the original image build, we're not going to be compiling stuff in docker containers anymore while having the stack running? This is often touted as an advantage of containers (that every build is "isolated" and "uncontaminated") but i think go vendoring provides this sufficiently anyway, so we can compile on the host. In fact I often want to make temporary changes to libraries i'm using or even use different go compiler builds, to compile the stuff i'm running in the stack. doing the compilation outside of the container and restarting the container with a new volume mapped binary is fine by me, but this feels like something we should make sure we're on the same page about. I can imagine i'll be restarting certain containers a lot and may want to make a tool to make that quicker, we'll see..
• this also means we have our containers do less and less. for many of our go software it seems the container pretty much only contains a binary and a config file, which more often than not will be volume mapped from the host anyway. but i still see value in the network abstractions and using docker-compose to manage what's up and not.
• i want to make our containers as standard as possible (e.g. install binaries in $GOPATH/bin, which gets added into $PATH, instead of /opt/raintank and whatever). not sure if related with your PR, but FWIW.
• one thing I'ld like to work more towards, and this PR helps with that, is being able to do different "scenarios": scripting the execution of MT ingest and query workloads (which often require different MT settings), all while having the monitoring stay up and running.
• i see the collector stuff is removed. is that because we simply use raintank-probe now?
• the start.sh's are too redundant. we can move all the common stuff into wait.sh so that each container only has to add the starting of their own binary. (and even that could probably be made generic by just passing it as args)
• now that we're starting to build docker containers for some of our software (metrictank, graphite-api, etc), do we plan to just use those, and stop building them in this project?

[woodsaj]

• treating containers as executables actually makes running bra possible. You would just need to set your bra config to restart the container after re-building.
• Yes, builds are not performed inside containers. This is primarily for the use case of being able to easily develop locally with new/updated dependencies. "isolated" and "uncontaminated" binaries is not at all important for a development environment which is constantly changing.
• raintank-collector has been depreciated. it has been replaced by raintank-probe.
• i would prefer to use the images we have in dockerHub over building local images where possible. I would also like to change the namespace of the raintank-docker images built to raintank-dev/* For many services we just need to set a config specific to the raintank-docker env, we could just add the custom config into the "official" images on dockerHub, eg:

From raintank/metrictank
COPY raintank-docker-config.ini /etc/raintank/metrictank.ini