compose: Service can't be reached by defined hostname

If goal of Docker Compose is to make it easier for users to deploy a composition of services using Docker images and containers, then the file definition should be crystal clear.

When a user defines a hostname to a service, it will expect that hostname to be resolvable from other services, specially when these services participate in the same network (as per my example).

Since a service can have multiple instances, it is just logical that when I define a hostname to a service, that hostname resolves to multiple instances (thus using the new DNS feature in latest version).

If nothing of these can be implemented today, or should not be implemented at all, then it is a matter of clarifying the documentation to state either:

1. hostname should have restriction like container_name where one service instance only will exist.
2. hostname should not be allowed in the compose file because there is no value added to that rather creating confusion in users’ mind.

It’s long been an annoyance for me that compose only creates the DNS container name aliases when using docker-compose up, and not when using docker-compose run.

The --name trick solves it, but it feels like this shouldn’t be necessary.

Any update on this issue?

As a Docker Composer user, I expect that whenever I set a hostname to a service, that hostname should resolve to any instance of that service. Same should apply for the service name.

If these things should not work the same way, and a user should only rely on service name, then hostname definition should not be allowed in the compose file. It just creates confusion.

What is the last solution to dns resolve for services with hostname or domainname in the same compose file ???

After using docker for years, this docker-compose bug is a surprise.

docker run --hostname myhostname --name myname --network=mybridgenetwork --rm myimage

and as expected the container is resolvable on somebridgenetwork by myhostname but not myname on the network

Surprisingly, in docker-compose, the container would be resolvable by myname but not myhostname on the network.

---

Side note: These are two orthognal concepts: container names are meant for container management and scoped to a Docker instance, hostnames are meant for network connectivity and scoped to a network.

May I ask what is the best practice to resolve this hostname resolving issue in 2018? Should hostname be specified in the compose file?

Looking at docker inspect test_master_1, I see two aliases:

...
"Aliases": [
    "master",
    "268ef7e1e5"
],
...

The first comes from the service name, and the second is the container’s short ID. I think that by default Compose doesn’t create aliases based on hostnames.

May I ask what you’re trying to accomplish? Why can’t the hostname also be “master”, and why does the slave need to ping the master by hostname rather than by service name?

What a mess

We should probably add a warning to the docs about using hostname. I think it is rarely useful.

It’s year 2020 and the issue seems to persist still. I need hostname with domainname to work. This is NOT a feature but a bug!!! Docker-compose version 3.4

Containers are spun up by docker-compose up.

ambari-server:
    image: hdp/ambari-server
    networks:
     - dev
    hostname: ambari
    domainname: dev
...   

works:

• can be pinged by service name from other containers. i.e, ambar-server
• can ping itself by service name, i.e. ambari-server
• hostname command returns the set hostname. i.e. ambari
• can ping itself by <hostname>.<domainname> , i.e. ambari.dev

doesn’t work:

• can not be reached from other container by <hostname>.<domainname>, i.e. ambari.dev
• can not be reached from ohter container by <hostname>, i.e. ambari

A work around is to use <hostname>.<domainname> as the service name but this brings out a whole bunch of other issues, e.g. this is not allowed in swarm-kit (https://github.com/docker/swarmkit/issues/2437)

@slothkong Also, do not mistake to refer service name not image name (as I did 😦 ):

    mongodb:
        image: mongo

Mistake: MONGODB_URL=mongodb://mongo:27017 Correct: MONGODB_URL=mongodb://mongodb:27017

compose only creates the DNS container name aliases when using docker-compose up, and not when using docker-compose run.

This burnt almost 2 days of development on my end (with very cryptic failures).

Do you by chance know if docker-compose exec is also affected?

This unexpected behavior still exists. The best solution I have found is this SO answer

Still doesn’t work…

@slothkong

I solved this problem. When using driver: bridge, I use the --add-host hostname:172.x.x.x parameter in the docker run command.

The docker run needs to specify the IP (--ip) and network name (--net) for the container.

IMHO this feature does work “as expected” because it works the same way it does in Docker engine. Running a container with the --hostname argument does one thing: sets the hostname. Aliases are defined by the user (with the caveat I mentioned earlier).

Not really. With overlay network, the hostname set in a container is reachable by another container. So I disagree that it works as “expected”. In fact, what users expect (and think about new users), is that when a hostname is set, specially in the case of Docker Compose, that hostname can be used by other containers.

That is not backwards compatible, and while it is “rarely” useful, there are still cases where it is useful in its current form, so removing it completely is not really an option.

Then the feature should work as expected by users using Compose for the first time, by adding that information to the list of alises.

Could you please be more specific where, although rare, the current form is useful?

We should probably add a warning to the docs about using hostname. I think it is rarely useful.

I think it should not be allowed at all.

There was some discussion early on about using hostname instead of container_name as the default name used by docker, but that didn’t happen (I’m not sure why).

We add aliases for service name and short id to be backwards compatible and handle the common use cases. We’re also adding support for your own net-aliases in #2829

As far as I know, it’s not all that uncommon for the internal hostname to be unresolvable from the outside.

We could probably make it another alias, but I’m not sure how we’d deal with conflicts with the service names.

Hi @jake-low, I think question is why isn’t hostname defined under aliases. What is the reasoning behind this decision?