Link to a service which isn't a Docker container

[aanand]

In production, your database might not be running inside a Docker container, but it's useful to be able to represent it logically inside Compose as a service.

Compose should have a concept of "external" services, which specify a host/port and can be "linked" from other services. For example:

db:
  type: external
  host: 1.2.3.4
  port: 5432
  environment:
    POSTGRES_USER: produser
    POSTGRES_PASSWORD: prodpass

This results in services which link to this service being furnished with hostnames and environment variables in exactly the same way as if they were linked to a Docker container:

$ docker-compose run web cat /etc/hosts
127.0.0.1  localhost
1.2.3.4    db

$ docker-compose run web env
DB_PORT=tcp://1.2.3.4:5432
DB_PORT_5432_TCP=tcp://1.2.3.4:5432
DB_PORT_5432_TCP_ADDR=1.2.3.4
DB_PORT_5432_TCP_PORT=5432
DB_PORT_5432_TCP_PROTO=tcp
DB_ENV_POSTGRES_USER=produser
DB_ENV_POSTGRES_PASSWORD=prodpass

This was previously described in #988.

[aanand]

What about virtual, instead of external? I can't tell if it's less confusing or more.

[dnephin]

I've been thinking about this, and it seems strange to me. Why would this be part of a docker-compose.yml ? Any application should be able to configure itself to hit any non-docker service very easily, without compose being involved.

If this is just about adding environment variables and links, can't we already do this with the existing compose features?

I think I'm -1 on this, it's unnecessary and is going to add to additional names for things that don't need to be part of the compose lexicon.

[munhitsu]

Both docker links and env variables are two different means to fullfill the same requirement: "To enable container A to talk to container B".
As docker already started abstraction called links, it's only natural to allow it to link to external services or remote services. Otherwise let's remove links from docker.

I'm totally up for virtual/external in docker-compose.

Re naming:
virtual - virtual service, a service that we only wrap and don't define anything about it
external - an external service to what, to localhost? to docker world?

virtual reads better, but that's just me

[funkyfuture]

shouldn't that be addressed in docker first?

[dnephin]

It seems like #1158 would actually resolve this issue. Am I missing something about this idea that isn't supported by #1158 ?

I believe the environment variables could be added on the service instead.

[aanand]

@dnephin Only annoyance there is that you have to repeat the IP and environment variables for every service that "links" to it, rather than being able to define it once.

[kojiromike]

Just a thought: What if instead of simply allowing you to specify an existing not-necessarily-docker service, compose would implicitly create an ambassador? This would allow docker and compose to continue to create the connection to the external service in a not-interface-breaking way.