Add support for confd generated config file

[blaggacao]

Confd files are usually generated by a sidekickcontainer, which volumes are shared with the main container. As either of:

• generating config files takes some time
• sidekick starts before main container
  can happen, this just loops over the config file folder and only contines when once available.

A very common pattern for confd managed config files.

[jsternberg]

A few comments on this. The first is why isn't it possible to launch the sidekick container before the telegraf container is launched? It seems like one is a dependency of the other and should be generated before the telegraf container is even generated.

The second is I don't like the indefinite waiting. I would rather telegraf fail to start if there is no config file rather than confusing the user into wondering why the container never starts and never has a log. For this to be merged, at a minimum, I would need there to be logging messages that it was waiting for a config file and it would need to not be indefinite waiting. I would still prefer that this behavior is handled outside of the docker image though if possible.

[blaggacao]

I think even if controlling the startup order of sidekicks (I think that's possible) signalling successful generation of a config file to the main container might be a different beast, so while waiting some seconds you have a very high probability that config was built.
I agree on timeout and logging.

However, this can be very easily integrated into a custom docker. I think the decision of integrating should depend on your strategy about how to manage dynamic configurations. I mean confd is just one option, although a common one.

[sparrc]

@blaggacao can you link to other projects that do this? I agree with @jsternberg, if the config file is a pre-requisite then it seems like the sidekick container should complete before launching the telegraf container,

Any configuration management system can do that for you.

[blaggacao]

Here we go, in this repo there is a wealth of examples of this pattern. https://github.com/rancher/catalog-dockerfiles/blob/master/elasticsearch/containers/0.5.0/elasticsearch-conf/run.sh

As a sidenote, the sidekick can be longrunning, which is actually what happens with confd in order to pick up config changes. So it doesn't exit.

EDIT: Right now in my testing I experience that the KV store (rancher metadata service) is not always readily available, don't know why. Also, networking takes some time depending on the scheduler, if I remember right rancher is around 15 secs, docker swarm a little more, and kubernetes and mesos even more...

In conclusion: No guarantees can be made to this docker as to config files available at startup.

[sparrc]

@blaggacao I meant more general docker files, like the one we are dealing with here. It would make sense for dockerfiles within the rancher project to have this looping since it is specific to that problem.

[blaggacao]

Here is another one for an kubernetes docker file: https://github.com/fbrbovic/kubernetes-reverseproxy/blob/master/src/boot.sh

This is very characteristic for kv-configuration patterns, unless the very same application has it's own kv-watcher routine which waits until configuration is available.

So I would instead of "more general" formulate the following anatomy:
"Configuration Agnostic" vs "Distributed Configuration Ready" - well I just foolishly invented those terms in order to point out the argument.

EDIT: Reading over your comment again, I spotted you mention "configuration management system". I don't know what that is. I think it corresponds to what cluster manager such as rancher, mesos, kubernetes call that scheduler? ... I grew up in the last two years. 😄

[jsternberg]

I'm going to close this. This is specialized behavior and it's pretty easy for anyone who needs this to extend the base image and modify entrypoint.sh to wait for a configuration file.