consul-template as standalone container

[andrexus]

docker-gen is a similar project and it can be installed as a separate container. There is an option -notify-sighup that can send a SIGHUP signal to another container e.g. nginx to reload its configuration.

-notify-sighup="": send HUP signal to container.  Equivalent to `docker kill -s HUP container-ID`

I don't actually know how they achieved this, but I think it's a great feature that allows you to run consul-template as a separate container (not bundled with nginx).

[sethvargo]

Hi @andrexus

Thank you for opening an issue. I am not sure I understand the issue here. Consul Template is not coupled with nginx, and it can be run in a container very easily. Is there a particular feature you are looking for?

[andrexus]

I mean that when a template is rendered by consul-template it is usually required to reload the configuration of the server that is using the rendered templates e.g. nginx. And if consul-template is running as a separate container there is no option to tell another container to reload its configuration

[sethvargo]

Hi @andrexus

The command that is specified is arbitrary - it can be any bash/shell command you specify, so I do not see why it could not notify another container. For example:

$ consul-template -template "in.ctmpl:out.ctmpl:docker kill -s HUP my-container-id"

Were you experiencing issues?

[andrexus]

But you can't do it if consul-template is running standalone in it's own container.

[sethvargo]

@andrexus this is correct. I'm afraid it is a bit outside of the scope for a tool like Consul Template to manage inter-container communication. docker-gen is a Docker-specific, container-specific tool, so it makes sense to have that type of functionality and bindings to Docker. Consul Template, on the other hand, is a general purpose tool designed to work with or without Docker.

We recommend running Consul Template inside the Docker container of the process you want generate templates for. Consul Template is incredibly lightweight and portable, so it should not be a problem! :smile:

[andrexus]

@sethvargo thanks for your answer. Actually I solve this problem the same way you suggested, making an image with consul-template bundled together with nginx. I thought my feature request might be interesting for project like this, but I'm totally fine if you mind that this is going too far (:

[xied75]

@sethvargo running consul-template binary as a separate process within a running container, would it break the idea that each container should only have one process?

[nicolasbarbe]

@sethvargo Running both processes (consul-template and nginx) in the same container is an issue if consul-template needs to be upgraded, crashed or any other reasons that will force me to restart the container ...
I found another approach that consists in mounting the docker socket and executable from the host as a volume in the container. Hence, I can access the docker daemon on the host and execute 'docker kill -s HUP container-ID' from inside the container.

[cabrinoob]

@nicolasbarbe : good idea! Do you have a example of the docker run command and the mounting params you use to do this? Thanks.

[nicolasbarbe]

@cabrinoob, you can mount the host docker socket in a container using this:
-v /var/run/docker.sock:/var/run/docker.sock Best.

[ahammond]

The problem is of course that mounting the docker binary into the container can be awkward. Especially if it's a scratch container. http://blog.dixo.net/2015/02/sending-signals-from-one-docker-container-to-another/ describes a reasonable solution for signaling. Of course you'd have to switch from scratch to busybox for your base.

consul-template -template "in.ctmpl:out.ctmpl:echo -e "POST /containers/nginx/kill?signal=HUP HTTP/1.0\r\n" | nc -U /var/run/docker.sock"

This is pretty seriously ugly, but it lets me use the stock nginx container. My immediate followup question is "what use is the scratch based consul-template container"? If the whole point is to manage config files and then signal a daemon, seems to me that it should be really, really good at signaling daemons. Given that it's in a docker container, it should be really, really good at signaling daemons in other docker containers... :)

The real question is if consul-template belongs in a container by itself, or if it should be a tenant in another daemon's container. I'm leaning in the direction of treating it as a tool rather than as a daemon.

[tanner-bruce]

@ahammond in terms of kubernetes, consul-template should be ran as either a side-car or init container.

[olivertappin]

You can run supervisord as PID 1 and nginx and consul-template as your processes managed by supervisord. This approach is mentioned in the following article from Google Cloud:

Using a process management system such as supervisord to manage one or several apps in the container.
https://cloud.google.com/solutions/best-practices-for-building-containers