Allow -notify-sigup to work with docker-compose

[Herkemer]

In a docker-compose situation, the container name isn't known in advance. A way to tell -notify-sigup to pull the container name from an environment variable (ie $nginx_NAME) would be helpful.

After more reading, I might be misunderstanding how docker-compose sets the environment variables.

I'm looking for a solution to putting docker-gen in a separate container from nginx and still being able to use -notify-sigup on the container which gets turned into _nginx_1 and not really known ahead of time (unless you assume how docker-compose is going to name the containers).

This might get solved in a future release when docker-compose includes the ability to name your containers whatever you'd like.

[jayfk]

This docker-compose 0.4 came the ability to add a container_name to the configuration.

I played around with it today:

nginx:
  image: nginx:latest
  container_name: nginx
  ports:
    - "1.2.3.4:80:80"
    - "1.2.3.4:443:443"
  volumes:
     - /tmp/nginx:/etc/nginx/conf.d
     - /path/to/certs:/etc/nginx/certs

nginx_dockergen:
  image: jwilder/docker-gen
  volumes_from: 
    - nginx
  volumes:
    - /var/run/docker.sock:/tmp/docker.sock:ro
    - /path/to/templates:/etc/docker-gen/templates
  links:
    - nginx
  command: "-notify-sighup nginx -watch -only-exposed /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf"

You'll have to change ports and /path/to/templates//path/to/certs to match those of your host.

[otherguy]

If you start more than one instance of your docker-compose orchestration (i.e. you sometimes have a *_nginx_2 container), you can use this in your entrypoint shell script:

    CONTAINER_ID=$(cat /proc/self/cgroup | grep "cpu:/" | sed 's/\([0-9]\):cpu:\/docker\///g')
    DOCKER_COMPOSE_PROJECT=$(docker inspect --format='{{(index .Config.Labels "com.docker.compose.project" )}}' ${CONTAINER_ID})
    DOCKER_COMPOSE_NUMBER=$(docker inspect --format='{{(index .Config.Labels "com.docker.compose.container-number" )}}' ${CONTAINER_ID})    
    NGINX_CONTAINER=$(docker inspect --format "{{ .Id }}" ${DOCKER_COMPOSE_PROJECT}_nginx_${DOCKER_COMPOSE_NUMBER})

[bibby]

Came digging through the issues for this topic exactly.
I'm using rancher, and while the definition style is similar to that of docker-compose, the container names will invariably be a fresh uuid. I'm having to modify the CMD of the docker-gen whenever the nginx front container flips.

Like #82, it'd be nice to be able to flag the nginx container with a value that docker-gen can identify as its SIGHUP target.

[spali]

same problem... testing currently with ranger. But it's a problem of orchestration (usually with docker-compose).
Probably labels would be the solution. So defining a label on the container which should be notified (could be more than one) would be a great deal. docker-gen should then evaluate containers with a custom defined label attached.

[Vad1mo]

I think labels would be the best option to go as it will work independently of compose or any other technology.

[jayfk]

@darkwinternight where does the docker command in your example come from?

[otherguy]

@jayfk well it has to be present inside the container, of course. You will also need to mount the docker socket into the container

[philicious]

having the same situation with docker-compose. is there still movement in this issue ?

[emcniece]

I'm working with this inside Rancher and would like to see this happen. I don't have enough time right this instant, but let's try and make a roadmap.

1. config.go needs a new parameter. Maybe something like NotifyLabel string and NotifyLabels map[string]docker.Signal.
2. generator.go in the sendSignalToContainer function should handle iterating config.NotifyLabels
3. To iterate, go-dockerclient container.go ListContainers method could be used.
4. Function sendSignalToContainer label iteration needs to extract labels from existing containers. go-dockerclient container.go details the APIContainers model.
5. After finding containers that have the expected label, killOpts can be set and g.Client.KillContainer can be fired.

To develop this, the Docker image for this repo will need to be built and tested against a functioning Swarm/Rancher stack. If we're really ambitious, we could try writing tests too... but this is pretty much my first time writing Go.

[Munsio]

docker-gen has the ability to use an config file as described here
With this config file you also have the ability to define the containers which should be notified.

In the rancher environment we have the rancher metadata service which is quite helpful with the described problem. But all in all you can build an solution to your problem with docker-compose by our own.

Create your own image with an small bash script which searches for the flag in all available docker containers and use the uuid of that container in the config-file. The only thing you need to take care of is that this script is running after all containers are created and before they are started. Afaik it is possible to define this order.

[emcniece]

@Munsio unfortunately Rancher assigns random and unique names to containers, so specifying the container notification in the template won't match containername or container_id.

What we would like to do here is add the ability for docker-gen to notify containers based on label, not just name or id. Is there an easier way to accomplish this?

[Munsio]

Maybe i was unclear - i didn't mean that my solution is the solution for everything i know that it is an workaround and that an implemented feature which lets us use a label for sighub signals is definitely better, unfortunately until we get this feature we have to use this workarounds.

And about the name thats why i mentioned to run the script every time after the container gets created and before it gets started.

[s4s0l]

What about auto container discovery based on mounts? Docker-gen could detect it is running in container, and if it is generating some files they are probably mounted in some other container/containers. Docker - gen could find these containers and notify them all. Would cover scaled compose services, rancher, and swarm environment. Of course it would have to pay attention to nodes/hosts but seems doable.

Finding containers by labels is ok but it may be harder to maintain.

If you think it makes sense I'm willing to spend some time on it and prepare PR.

[bibby]

After 8-9 years, let me just say that I am personally very delighted.