Docker-compose external_links not able to connect

问题:

I have a couple of app containers that I want to connect to the mongodb container. I tried with external_links but I can not connect to the mongodb.

I get

MongoError: failed to connect to server [mongodb:27017] on first connect

Do I have to add the containers into the same network to get external_links working?

MongoDB:

version: '2'
services:
  mongodb:
    image: mongo:3.4
    restart: always
    ports:
      - "27017:27017"
    volumes:
      - data:/data/db
volumes:
  data:

App:

version: '2'
services:
  app-dev:
    restart: Always
    build: repository/
    ports:
      - "3000:80"
    env_file:
      - ./environment.env
    external_links:
      - mongodb_mongodb_1:mongodb

Networks:

# sudo docker network ls
NETWORK ID          NAME                      DRIVER              SCOPE
29f8bae3e136        bridge                    bridge              local
67d5519cb2e6        dev_default               bridge              local
9e7097c844cf        host                      host                local
481ee4301f7c        mongodb_default           bridge              local
4275508449f6        none                      null                local
873a46298cd9        prod_default              bridge              local

回答1:

Documentation at https://docs.docker.com/compose/compose-file/#/externallinks says

If you’re using the version 2 file format, the externally-created containers must be connected to at least one of the same networks as the service which is linking to them.

Ex:

Create a new docker network

docker network create -d bridge custom

docker-compose-1.yml

    version: '2'

    services:
      postgres:
        image: postgres:latest
        ports:
          - 5432:5432
        networks:
          - custom

    networks:
      custom:
        external: true

docker-compose-2.yml

    version: '2'

    services:
      app:
        image: training/webapp
        networks:
          - custom
        external_links:
          - postgres:postgres

    networks:
      custom:
        external: true

回答2:

Yuva's answer above for the version 2 holds good for version 3 as well.

The documentation for the external_links isn't clear enough.

For more clarity I pasted the version 3 variation with annotation

version: '3'

services:
  app:
    image: training/webapp
    networks:
      - <<network created by other compose file>>
    external_links:
      - postgres:postgres

networks:
  <<network created by other compose file>>:
    external: true

回答3:

Recently I faced Name resolution failure trying to link 2 containers handled by docker-compose v3 representing gRPC server and client in my case, but failed and with external_links.

I'll probably duplicate some of the info posted here, but will try to summarize as all these helped me solving the issue.

From external_links docs (as mentioned in earlier answer):

If you’re using the version 2 or above file format, the externally-created containers must be connected to at least one of the same networks as the service that is linking to them.

---

The following configuration solved the issue.

project-grpc-server/docker-compose.yml

version: '3'
services:
    app:
        networks:
            - some-network
networks:
    some-network:

Server container configured as expected.

---

project-grpc-client/docker-compose.yml

services:
    app:
        external_links:
            # Assigning easy alias to the target container
            - project-grpc-server_app_1:server
        networks:
            # Mentioning current container as a part of target network
            - project-grpc-server_some-network
networks:
    # Announcing target network (where server resides)
    project-grpc-server_some-network:
        # Telling that announced network already exists (shouldn't be created but used)
        external: true

When using defaults (no container_name configured) the trick with configuring client container is in prefixes. In my case network name had prefix project-grpc-server_ when working with docker-compose and than goes the name itself some-network (project-grpc-server_some-network). So fully qualified network names should be passed when dealing with separate builds.

While container name is obvious as it appears from time to time on the screen the full network name is not easy-to-guess candidate when first facing this section of Docker, unless docker network ls.

I'm not a Docker expert, so please don't judge too strict if all this is obvious and essential in Docker world.