New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add container host names to `/etc/hosts` #2335

Closed
paulepanter opened this Issue Oct 22, 2013 · 27 comments

Comments

Projects
None yet
@paulepanter

paulepanter commented Oct 22, 2013

The containers should be reachable by their host names from other containers.

Creating two containers with

$ sudo docker run -i -t -h test tianon/debian /bin/bash

and

$ sudo docker run -i -t -h test2 tianon/debian /bin/bash

it should be possible, to run ping test2. That is useful, when having a database image and running only one container from it. If the container crashes or a new one is started from an updated image, I do not want to update all the configuration files of my containers using that database server.

If no hostname is specified, the container ID is used by default for the host name, so every container has one already.

As /etc/hosts is bind mounted, couldn’t this be used for this by adding or removing entries.

I saw that for LXC(?) a DNSmasq instance is running. Maybe that could be used for that too. paultag in #docker on <irc.freenode.net> told me, that a FQDN is needed for that. Just provide a default dockernet for example.

If that is not wanted for all use cases, Docker should provide a config option for that.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Oct 22, 2013

Contributor

This would be interesting, but it would conflict with #2267.
Some people want to be able to customize /etc/hosts; meaning that it should be writable.
Do you have an idea to reconcile both requirements?

Contributor

jpetazzo commented Oct 22, 2013

This would be interesting, but it would conflict with #2267.
Some people want to be able to customize /etc/hosts; meaning that it should be writable.
Do you have an idea to reconcile both requirements?

@paulepanter

This comment has been minimized.

Show comment
Hide comment
@paulepanter

paulepanter Oct 23, 2013

As written, one way would be to have a config option, how to deal with /etc/hosts. As a solution for this ticket, instead of creating /etc/hostname and /etc/hosts for each container separately under /var/lib/docker/…, one could just bind mount one /etc/hosts.docker (or whatever) into every container. This file could even be passed to docker using a config option and, as argued in the initial post, Docker will update this file as containers are started or stopped.

paulepanter commented Oct 23, 2013

As written, one way would be to have a config option, how to deal with /etc/hosts. As a solution for this ticket, instead of creating /etc/hostname and /etc/hosts for each container separately under /var/lib/docker/…, one could just bind mount one /etc/hosts.docker (or whatever) into every container. This file could even be passed to docker using a config option and, as argued in the initial post, Docker will update this file as containers are started or stopped.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Oct 23, 2013

Contributor

So, basically, people could switch between two behaviors:

  • use a Docker-generated /etc/hosts which lists the other containers running on the machine;
  • use a container-managed /etc/hosts (which won't list other containers, well unless they are manually added by the container itself).

Is that right?

Also, another question: what about multi-tenant installs? I.e. when I run containers for multiple different persons, they will see each other's containers in /etc/hosts... How do you suggest to address that?

Contributor

jpetazzo commented Oct 23, 2013

So, basically, people could switch between two behaviors:

  • use a Docker-generated /etc/hosts which lists the other containers running on the machine;
  • use a container-managed /etc/hosts (which won't list other containers, well unless they are manually added by the container itself).

Is that right?

Also, another question: what about multi-tenant installs? I.e. when I run containers for multiple different persons, they will see each other's containers in /etc/hosts... How do you suggest to address that?

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Oct 23, 2013

Member

Also, doesn't the links branch make it so that containers must be explicitly be exposed or linked to communicate?

Member

tianon commented Oct 23, 2013

Also, doesn't the links branch make it so that containers must be explicitly be exposed or linked to communicate?

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Oct 23, 2013

Contributor

Oh, and I think that we discussed about a flag to switch between "open communication between containers" and "only linked containers can communicate", so maybe we could have something like this (in post-link world):

  • in "open communication mode", /etc/hosts gets populated with all containers, unless overridden on a per-container basis (i.e. when the container changes its "local" /etc/hosts)
  • in "closed communication mode", /etc/hosts get populated only with containers that you are linked with...?
Contributor

jpetazzo commented Oct 23, 2013

Oh, and I think that we discussed about a flag to switch between "open communication between containers" and "only linked containers can communicate", so maybe we could have something like this (in post-link world):

  • in "open communication mode", /etc/hosts gets populated with all containers, unless overridden on a per-container basis (i.e. when the container changes its "local" /etc/hosts)
  • in "closed communication mode", /etc/hosts get populated only with containers that you are linked with...?
@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Oct 23, 2013

Member

Ok, so further assuming post-links land, would "open communication mode" /etc/hosts be populated with just the container IDs, or would it also contain the container "name"?

Member

tianon commented Oct 23, 2013

Ok, so further assuming post-links land, would "open communication mode" /etc/hosts be populated with just the container IDs, or would it also contain the container "name"?

@paulepanter

This comment has been minimized.

Show comment
Hide comment
@paulepanter

paulepanter Oct 24, 2013

Tianon, what do you mean with »or would it also contain the container "name"«? If you mean the host name passed by -h … then I would use that as a name.

There is no problem though putting both names in into /etc/hosts.

paulepanter commented Oct 24, 2013

Tianon, what do you mean with »or would it also contain the container "name"«? If you mean the host name passed by -h … then I would use that as a name.

There is no problem though putting both names in into /etc/hosts.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Oct 24, 2013

Member

There's the hostname, yes, but then there's also the container name (in a post-links world): #2162

Member

tianon commented Oct 24, 2013

There's the hostname, yes, but then there's also the container name (in a post-links world): #2162

@paulepanter

This comment has been minimized.

Show comment
Hide comment
@paulepanter

paulepanter Oct 24, 2013

By the way, does LXC use its own DNSmasq server, which Docker does not use? The package dnsmasq-base is installed on my host as a dependency of the package lxc and ps aux | grep -i dnsmasq matched.

dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0

But Docker uses different IP addresses 172.….

My point is, DNSmasq could be used and a file be added matching the host name and IP address, which DNSmasq should use then.

paulepanter commented Oct 24, 2013

By the way, does LXC use its own DNSmasq server, which Docker does not use? The package dnsmasq-base is installed on my host as a dependency of the package lxc and ps aux | grep -i dnsmasq matched.

dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0

But Docker uses different IP addresses 172.….

My point is, DNSmasq could be used and a file be added matching the host name and IP address, which DNSmasq should use then.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Oct 24, 2013

Contributor

The lxc package installs dnsmasq and configures lxcbr0, but Docker doesn't use those.

Contributor

jpetazzo commented Oct 24, 2013

The lxc package installs dnsmasq and configures lxcbr0, but Docker doesn't use those.

@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack Dec 6, 2013

Contributor

@tianon What is the status of this issue? Should we close it or imlpement it? I like the idea to have a /etc/hosts filled with all linked container's ips/hostname/name.hostname/name. What do you think?

Contributor

creack commented Dec 6, 2013

@tianon What is the status of this issue? Should we close it or imlpement it? I like the idea to have a /etc/hosts filled with all linked container's ips/hostname/name.hostname/name. What do you think?

@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack Dec 6, 2013

Contributor

/cc @jpetazzo

Contributor

creack commented Dec 6, 2013

/cc @jpetazzo

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Dec 7, 2013

Member

I think it would be a really sweet optional addition, especially if it includes all the container IDs and then hostnames for containers where that's specified.

Member

tianon commented Dec 7, 2013

I think it would be a really sweet optional addition, especially if it includes all the container IDs and then hostnames for containers where that's specified.

@frankscholten

This comment has been minimized.

Show comment
Hide comment
@frankscholten

frankscholten Dec 12, 2013

I would love to be able to reach every container by name instead of having to docker inspect | grep IP et cetera. I saw there is a -dns option. Does anyone know a script snippet that makes a Docker container register itself with a dnsmasq instance?

frankscholten commented Dec 12, 2013

I would love to be able to reach every container by name instead of having to docker inspect | grep IP et cetera. I saw there is a -dns option. Does anyone know a script snippet that makes a Docker container register itself with a dnsmasq instance?

@jamshid

This comment has been minimized.

Show comment
Hide comment
@jamshid

jamshid Dec 12, 2013

Contributor

I know clients might cache a DNS lookup, so it's not the most reliable way to do service discovery, but don't know a good alternative. The services I'm running via docker need an IP address or hostname in a config file and I want to point them to other containers.

Here's a little hack that seems to be working for me. I call this script after stopping or starting any containers, it updates /etc/hosts and sends "kill -HUP dnsmasq". Then I run each container with -dns pointing to the docker host (eg, your vagrant vm).

https://gist.github.com/jamshid/7934004

Contributor

jamshid commented Dec 12, 2013

I know clients might cache a DNS lookup, so it's not the most reliable way to do service discovery, but don't know a good alternative. The services I'm running via docker need an IP address or hostname in a config file and I want to point them to other containers.

Here's a little hack that seems to be working for me. I call this script after stopping or starting any containers, it updates /etc/hosts and sends "kill -HUP dnsmasq". Then I run each container with -dns pointing to the docker host (eg, your vagrant vm).

https://gist.github.com/jamshid/7934004

@aidanhs

This comment has been minimized.

Show comment
Hide comment
@aidanhs

aidanhs Dec 16, 2013

Contributor

+1

  • Real example 1 - just set DATABASE_URL to the same alias you're linking to ('db' in this case).
  • Real example 2 - no need to put wrapper scripts for every config file you have.

Personally I'd make the hostname in /etc/hosts the link name. When linking we're populating the environment with variables based on the link name ($_PORT_3306_TCP_PORT, $_PORT_3306_TCP_ADDR), so it seems more consistent to put that in /etc/hosts as well.

Contributor

aidanhs commented Dec 16, 2013

+1

  • Real example 1 - just set DATABASE_URL to the same alias you're linking to ('db' in this case).
  • Real example 2 - no need to put wrapper scripts for every config file you have.

Personally I'd make the hostname in /etc/hosts the link name. When linking we're populating the environment with variables based on the link name ($_PORT_3306_TCP_PORT, $_PORT_3306_TCP_ADDR), so it seems more consistent to put that in /etc/hosts as well.

@cdekok

This comment has been minimized.

Show comment
Hide comment
@cdekok

cdekok Apr 22, 2014

Yes this would be a nice feature 👍

cdekok commented Apr 22, 2014

Yes this would be a nice feature 👍

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 16, 2014

Contributor

With the PR #5525 we are now writing linked containers names into the etc hosts file. I believe this resolve this issue as well. We voted for only adding linked containers names instead of all containers because it is a better longer term tradeoff for multi tenancy and other usecases.

Contributor

crosbymichael commented May 16, 2014

With the PR #5525 we are now writing linked containers names into the etc hosts file. I believe this resolve this issue as well. We voted for only adding linked containers names instead of all containers because it is a better longer term tradeoff for multi tenancy and other usecases.

@CristianCantoro

This comment has been minimized.

Show comment
Hide comment
@CristianCantoro

CristianCantoro Dec 14, 2014

Sorry if this is not the right place to bring this up, but I wanted a clarification.
First things first, for what I can understand this not done natively except for linked containers.

What I mean is that so I can not either do:
docker run -h foobar.local -t cristiancantoro/foo <some_command>
If I do on the host:
ping foobar.local
I get nothing.

The same is true if I set the name of the container:
docker run --name foobar -t cristiancantoro/foo <some_command>

Of course if I get the container's IP address (via, say, docker inspect) and the I do:
ping <container_address>
this works.

From what I have read @jpetazzo's Piperwork seems a tool to do the job. Another tool is @bnfinet's docker-dns.
Am I getting this right?

CristianCantoro commented Dec 14, 2014

Sorry if this is not the right place to bring this up, but I wanted a clarification.
First things first, for what I can understand this not done natively except for linked containers.

What I mean is that so I can not either do:
docker run -h foobar.local -t cristiancantoro/foo <some_command>
If I do on the host:
ping foobar.local
I get nothing.

The same is true if I set the name of the container:
docker run --name foobar -t cristiancantoro/foo <some_command>

Of course if I get the container's IP address (via, say, docker inspect) and the I do:
ping <container_address>
this works.

From what I have read @jpetazzo's Piperwork seems a tool to do the job. Another tool is @bnfinet's docker-dns.
Am I getting this right?

@tjwebb

This comment has been minimized.

Show comment
Hide comment
@tjwebb

tjwebb Dec 28, 2014

I would love to be able to reach every container by name instead of having to docker inspect | grep IP et cetera.

Amen.

tjwebb commented Dec 28, 2014

I would love to be able to reach every container by name instead of having to docker inspect | grep IP et cetera.

Amen.

@MichaelMackus

This comment has been minimized.

Show comment
Hide comment
@MichaelMackus

MichaelMackus Oct 29, 2015

Bump. This would be really nice. For instance, being able to mysql into my db container from the host would be great and prevent me from ever needing to docker exec -it NAME bash

MichaelMackus commented Oct 29, 2015

Bump. This would be really nice. For instance, being able to mysql into my db container from the host would be great and prevent me from ever needing to docker exec -it NAME bash

@aidanhs

This comment has been minimized.

Show comment
Hide comment
@aidanhs

aidanhs Oct 29, 2015

Contributor

For the record:

  • as of 1.8.0 all container names were put into /etc/hosts of all other containers
  • as of 1.9.0 (planned) the feature from 1.8.0 will be disabled on the default bridge, and will only be available on networks you create yourself (#17325)

@MichaelMackus you're asking for something different - this issue is container<->container connectivity.
For your use case, you can use https://github.com/gliderlabs/resolvable to insert a DNS server into /etc/resolv.conf of the host and allow you to ping containers.

Contributor

aidanhs commented Oct 29, 2015

For the record:

  • as of 1.8.0 all container names were put into /etc/hosts of all other containers
  • as of 1.9.0 (planned) the feature from 1.8.0 will be disabled on the default bridge, and will only be available on networks you create yourself (#17325)

@MichaelMackus you're asking for something different - this issue is container<->container connectivity.
For your use case, you can use https://github.com/gliderlabs/resolvable to insert a DNS server into /etc/resolv.conf of the host and allow you to ping containers.

@MichaelMackus

This comment has been minimized.

Show comment
Hide comment
@MichaelMackus

MichaelMackus Oct 30, 2015

@aidanhs thanks - resolvable looks like exactly what I was looking for!

MichaelMackus commented Oct 30, 2015

@aidanhs thanks - resolvable looks like exactly what I was looking for!

@mitar

This comment has been minimized.

Show comment
Hide comment
@mitar

mitar Oct 31, 2015

as of 1.9.0 (planned) the feature from 1.8.0 will be disabled on the default bridge, and will only be available on networks you create yourself

Could this be made a configuration option for Docker instead? So should the default bridge have this feature or not? And then the host can decide? In this way it can be made backwards compatible, with Docker 1.9 hosts just have to enable it, while the new default would be that it is disabled?

mitar commented Oct 31, 2015

as of 1.9.0 (planned) the feature from 1.8.0 will be disabled on the default bridge, and will only be available on networks you create yourself

Could this be made a configuration option for Docker instead? So should the default bridge have this feature or not? And then the host can decide? In this way it can be made backwards compatible, with Docker 1.9 hosts just have to enable it, while the new default would be that it is disabled?

@scher200

This comment has been minimized.

Show comment
Hide comment
@scher200

scher200 commented Nov 9, 2015

+1

@strarsis

This comment has been minimized.

Show comment
Hide comment
@strarsis

strarsis Feb 29, 2016

+1 for Docker host being able to resolve containers running on it by their names.
It could be realized with e.g. consul + registrator + using consul DNS on the Docker host.
But this would fit in as native Docker feature.

strarsis commented Feb 29, 2016

+1 for Docker host being able to resolve containers running on it by their names.
It could be realized with e.g. consul + registrator + using consul DNS on the Docker host.
But this would fit in as native Docker feature.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 29, 2016

Contributor

@strarsis This is already implemented when using user-defined networks via DNS.

Contributor

cpuguy83 commented Feb 29, 2016

@strarsis This is already implemented when using user-defined networks via DNS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment