Inject chosen container name in container

[octplane]

Because it can be desirable for monitoring, having the container name accessible in the container could be useful.

Use case include:

• monitoring the docker from outside
• monitoring the applications inside the docker
• wanting to merge the data with coherent data.

Currently, there is not way to get the container name apart from being outside the docker, or being able to talk to the docker daemon. This is clearly not something we want from out inner applications. I suggest passing a simple environment variable could do the trick in most case.

[dnephin]

I think with the new networking support coming in the next release, you'll be able to use hostname for this instead of container name.

[dnephin]

#2334 (comment) has another use case for this.

I think this may also address the issue raised in #1131

Using a predefined environment variable (as implemented in #1504) seems like a reasonable way to implement this. The only other option would be to set the hostname, but we saw that was disruptive to other use cases.

One potential problem is that containers can be renamed, but the environment variable would not get updated on a rename (there is no way to update the environment). So when it gets renamed, the value would be incorrect.

Another option might be to use add-host to add another line to /etc/hosts. We won't know the container IP address yet, so we can't set it to that, but maybe there is some other alias that can be used?

I don't know of any other way we can set this in the container.

[okgemaltoprg]

What about /etc/container_name (we already have debian_version, system-release, etc.). Anybody can grep/cat the value and it can be changed on the fly.

[okgemaltoprg]

So, the final decision is just to use uid (hostname) and ignore the fact that there are use cases where it's simply not enough?

[dnephin]

There hasn't been any decision made about this yet.

The case you describe in #2334 seems to be pretty rare, and maybe is more of an issue with Registrator being too limited about how it registers containers. Other container-dns solutions support ways to override the name.

What about /etc/container_name

I don't think there are any facilities for adding files to the container at runtime, and we won't want to be adding an extra volume to every container.

The approach of using an environment variable breaks when containers are renamed, so we don't yet have a reliable alternative to using the unique hostname.

[okgemaltoprg]

:/ I agree with you on the statements. However, I thought that Registrator+Consul isn't so rare :) I solved it already with custom microservice managing alternative hosts as I want it, but that's not perfect solution and I will start looking for alternatives soon.

Other container-dns solutions support ways to override the name.

Could you help me and name some?

[dnephin]

https://github.com/crosbymichael/skydock#plugin-support
https://github.com/ehazlett/interlock
https://github.com/jwilder/docker-gen (only a partial solution)
https://github.com/tonistiigi/dnsdock#overrides-from-env-metadata
https://www.npmjs.com/package/docker-dns (not sure about this project, but it does seem to use container ids)

These are the ones I know about

[jippi]

any update on this? quite frustrating that each container just get a random id as hostname, and not ${service}-${scale} or just the $NAMES column

[dnephin]

We are still trying to understand why a container needs to know its name instead of just a unique id. If you could provide more information about your use case that would be valuable. There is no clear solution to this yet because: the problem is not yet well understood, and the proposed solutions will break with container renaming.

The only update is that with the new aliasing being proposed for user defined networks it should be possible for a container to query dns for alternative CNAME entries, which gives you an option for determining the service name.

[brunoborges]

@dnephin I believe that issue #2551 has a better problem statement, and use case.

[jippi]

for my case, i use the hostname to sniff out the service group the container is part of, and the scale of it (from e.g. tutum.co and rancher) - based on that, i can deduce if the container should be doing different things, e.g. try to scan and figure out how many "siblings" it got as well.. also, in consul, the hostname is the identifier for the container(s), so having their id as hostname makes it impossible to get an easy-to-understand overview of what nodes are currently running or not

[ziru]

@dnephin i would like to setup Jenkins with one master node, and two slaves nodes. the Jenkins slave nodes share the same image, and thus using scale=2 can easily get me two slave nodes. however, when configuring the master node, i need to tell the master node how it could reach the two slave nodes. in this case, it will be easier to enter slave node details, such as slave-1, slave-2. and the master will take over managing such slave nodes and dispatch Jenkins jobs when necessary.

admittedly, i can create slave-1, slave-2 as different named services, but using scale=2 seems easier, and i can easily bump up to 4 slave nodes, if wanted.

[ayen-tibco]

+1

[daniel-smith-kaazing]

I too have a use case. I am writing a test case in which I want my container that runs a Java JMS client. I want to use the scale feature and have each JMS client use its scale index as part of its selector for both its producers and its consumers. Not having this is painful as I have to copy the section in my docker-compose.yml for the client, making as many copies as I want instances to run, and explicitly set the param I want in the environment of each copied section.
I can't use the randomly generated hostname as I want, say client #1 to always use the same client #1 selector, not a random one each time it runs.

[l1990790120]

My use case is simply i want my kafka consumer to be set to different partition number on each container. Wanted to parse the container name from env to set it.

[sheldonh]

Use case: I want my docker-entrypoint.sh to print "container awesome-test waiting for container awesome-mysql".

[limeandcoconut]

I want the first copy of a scaled service to use a known id for something and all of the other copies to gen new ids for themselves then wait for the first container to touch a file.

[c-fos]

I aggregate app errors in Sentry. In Senry i want to see container name instead of just id. So the app must khow container name

[asfernandes]

I want to do simple logging to file inside application and being able to scale the containers, redirecting logs from each instance to different directories.

[enanablancaynumeros]

Another use case is being able to monitor in flower (celery tasks, potentially also airflow celery executors) which container name (in our case it is a container per queue environment) is executing each task and not only in which host is the container running.

[dargolith]

We're using a microservice architecture where services provide RPCs on an RPC-engine. It would be nice to use the stack declaration (compose file) to give the services on that sub-system the same name as declared in the compose file. It is possible by setting some environmental to the same name, but it would be nice to just be able to use the service name specified in the compose file.

[chanjarster]

use case: we want to know container name when using docker service create or docker stack deploy, so we can get the service instance # and using that number to set jvmRoute property of tomcat.

For example: container name is abc.2.yqta2ftatvgggik5d6090eglk, so jvmRoute will be 2.

Using hostname as jvmRoute value works, but that will be a little harder to debug.

For example, if jvmRoute is 2, the sessionid generated by tomcat will be xxxxxx.2. So I can immediately know the problem is related to no.2 task. If jvmRoute is hostname like f7edcdee2ac4, the sessionid generated by tomcat will be xxxxx.f7edcdee2ac4, then i have to do some searching to know which task is related to.

[Dico200]

I need a unique username for registration with a service that is only necessary at runtime, and it would ideally be meaningful for debugging.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.

[hendrics]

shame it was closed. We have a very similar usecase to other people.

[tommymcguiver]

I bring up my services in docker compose and want the container name to get dynamic configuration from a remote configuration service.

A hack i'm using inside my docker container, doing a reverse DNS lookup. I'm removing the scale number cause i don't want it for my use case.

#!/bin/bash
get_service_name() {
    ip="$(cat /etc/hosts | grep -E '172\.|192\.|10\.' | awk '{print $1}')"
    dig +noall +answer -x "$ip" | awk '{print $5}' | cut -f2 -d _
}
get_service_name

[BarisJKC]

Thanks a lot @tommymcguiver, I have updated cut -f1 -d . section to get the name of my container.

[treybrisbane]

@tommymcguiver I think you can shorten that to:

dig -x "$(hostname -i)" +short | cut -d _ -f 2

(The hostname -i gives you the container IP address, and dig's +short argument strips out most of the unnecessary output)