Composefile v2 & default bridge network ERROR: b'Network-scoped alias is supported only for containers in user defined networks'

[niko]

When using composefile version 2 with the default bridge network this error occurs:

$ docker-compose up
Creating dockercomposetest_debian_1
ERROR: b'Network-scoped alias is supported only for containers in user defined networks'

This is my docker-compose.yml:

version: '2'

services:
  debian:
    image: debian:wheezy

networks:
  default:
    external:
      name: bridge

I'm using compose 1.6.0 and docker 1.10.1.

[dnephin]

To use the bridge network use network_mode: https://docs.docker.com/compose/compose-file/#network-mode

Compose relies on network scoped aliases, so if you try to use bridge as an external network it will set those aliases. If you use network_mode, it will disable the built-in aliases, and rely on the aliases made available by the bridge network.

[niko]

Thanks! Works like a charm!

[sabberworm]

@dnephin Is it possible to join both the bridge external network and other networks at the same time? It seems it should be possible but when I do it like the OP I get the error mentioned and when I use network_mode: bridge I get:

ERROR: 'network_mode' and 'networks' cannot be combined

[ninchan8328]

Would also like to know if a container can join a default bridge network as a external network and a custom network at the same time. Please help!

[ninchan8328]

I figured out, i can have the docker-compose to start the container in a custom network and then do a docker network connect bridge [container] to join the default network that way.

[prologic]

I'm also trying to find a way to connect a service to the default bridge network and it's own. @niko ninchan8328 How did you end up doing this? Is there a way to easily do both?

[allamand]

regarding this message ERROR: 'network_mode' and 'networks' cannot be combined is there a way for a container to access both user defined overlay networks & physical external network such as host or bridge ?

[ninchan8328]

@prologic the way i do is to have the docker-compose spin up the container in its network, then use the docker network connect command to assign the container to different network as needed. I don't think you can do the default bridge and dedicated network at the same time in the compose file but I could be wrong

[prologic]

@ninchan8328 Ahh I see. This sounds like a very good use case for a new autodock plugin say autodock-network-attach whose sole responsibility is to listen to started events for any container that have an environment NETWORK_ATTACH=<network1,network2,networkN> for a list of networks to attach to after being brought up.

I'll implement this tonight; because it'll mean that I don't have to use network_mode: "bridge" in many of my services and explicitly attach the ones that need attaching to the "bridge" network :)

[sueastside]

My current workaround for joining the bridge network and the default compose created one:

version: '3'
services:
  multi-network-service
    image: ubuntu
    labels:
       - networks=bridge
  connect-bridge:
    image: stmllr/docker-client
    volumes:
     - /var/run/docker.sock:/var/run/docker.sock:ro
    depends_on:
       - multi-network-service
    command: /bin/sh -c 'docker ps -f label=networks=bridge --format "{{.ID}}" | xargs docker network connect bridge'

Which gives me:

"Networks": {
    "bridge": {
        ...
    },
    "test_default": {
        "Aliases": [
            "multi-network-service",
            "a579a8c514ff"
        ],
        ...
    }
}

[Wilfred]

For future reference, the docs for network_mode are here: https://docs.docker.com/compose/compose-file/#network_mode (there seems to be a website bug that prevents browsers scrolling to #network_mode, but it is on that page)

The configuration provided by the bug reporter:

version: '2'

services:
  debian:
    image: debian:wheezy

networks:
  default:
    external:
      name: bridge

Should be:

version: '2'

services:
  debian:
    image: debian:wheezy
    network_mode: bridge

[prologic]

@Wilfred This doesn't work for docker stack deploy ...:

Ignoring unsupported options: network_mode

[NullVoxPopuli]

I have an issue where I can network two images together via docker but not docker-compose.

I've asked about it here: https://groups.google.com/forum/#!topic/drools-setup/VvYVh1GWFps
but maybe you guys know the answer, since this github issue is directly related to my problem.

what I need, is for 2 compose services to use the same network as the default network used by regular docker commands.

Edit:

using the above network_mode: bridge fixes my problem!

[rivassh]

How to choose Static with network_mode: bridge

[cundi]

For future reference, the docs for network_mode are here: https://docs.docker.com/compose/compose-file/#network_mode (there seems to be a website bug that prevents browsers scrolling to #network_mode, but it is on that page)

The configuration provided by the bug reporter:

version: '2'

services:
  debian:
    image: debian:wheezy

networks:
  default:
    external:
      name: bridge

Should be:

version: '2'

services:
  debian:
    image: debian:wheezy
    network_mode: bridge

it works for me

[ghost]

Does anyone have a work-around for: 'network_mode' and 'networks' cannot be combined?

[Ljzn]

how to set static ip address with network_mode?

[liudonghua123]

I want to set one of my service to use both the default and external bridge (make it work for nginx-proxy auto self discovery) network, I tried a lot of methods like the following, but it always gave me ERROR: for dns-management-frontend network-scoped alias is supported only for containers in user defined networks error.

version: '2'
services:
  dns-management-frontend:
    image: daocloud.io/liudonghua123/dns-management-frontend
    environment:
    - VIRTUAL_HOST=dns-management.domain.com
    depends_on:
    - dns-management-backend
    ports:
    - 80
    restart: always
    networks:
    - default
    - bridge
  dns-management-backend:
    image: daocloud.io/liudonghua123/dns-management-backend
    depends_on:
    - db
    ports:
    - 8080
    restart: always
    networks:
    - default
  db:
    image: daocloud.io/liudonghua123/dns-management-db
    volumes:
    - ./mysql-data:/var/lib/mysql
    ports:
    - 3306
    restart: always
    networks:
    - default
  redis:
    image: redis
    ports:
    - 6379
    restart: always
    networks:
    - default
networks:
  bridge:
    external:
      name: bridge

[aschoerg]

Since I had the same problem and fix seemed to happen since then:

@sueastside your workaround is genius and the only working solution I found after 4h of search. I have a database that runs on the host machine and I need to connect to it. THANK YOU SO MUCH!!!

The only thing, that need to be changed to run now is the command of the connection bridge (add -L 1 at xargs):
command: /bin/sh -c 'docker ps -f label=networks=bridge --format "{{.ID}}" | xargs -L 1 docker network connect bridge'

[bozdoz]

Note that you can just use the docker image to run the same command:

  connect-bridge:
    image: docker:stable
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    command: /bin/sh -c "docker ps -f label=networks=bridge -q | xargs -I'{}' docker network connect bridge {}"

Also, it can easily fail if brought up a second time and errors with endpoint with name already exists in network bridge, but hopefully that's not a big deal.

[VasiliPupkin256]

@dnephin your short explanation of the cause of the issue doesn't make sense. Why can it set those aliases for networks created with docker network create but can't set aliases for the bridge network? Why can't it make an exception for it? This is an obvious and straightforward usecase, a container needs to connect to the host and the only default docker interface on the host is bridge i.e. docker0. Why users have to implement crutches like the one made by @sueastside ? It isn't complete by the way, there is a delay between the time when multi-network-service is up and the time when it is connected to the bridge, so its command should also delay and wait for this event.

Ok. This is the point when I decided for myself that docker-compose is just a toy and is not suitable for any decent setup. I have to implement everything through nasty custom scripts and direct calls to docker.