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