Compose: Allow mixing of the default bridge with other networks

Created on 18 May 2016  路  10Comments  路  Source: docker/compose

In the V2 config it is not possible to define a custom network for a composed group of containers and then have a limited number of those containers also exposed on the default bridge. This is because the default bridge doesn't support network aliases.

It would be very helpful if compose knew how to handle this situation. Or, I guess, alternatively, maybe docker itself needs an option to disable legacy mode on the default bridge.

arenetworking

Most helpful comment

Almost a year and a half and no word on this error message? It's so incredibly vague and this issue is the top result for it.

Can we get some information here?

All 10 comments

This would be absolutely helpful with nginx-proxy, see here:
https://github.com/jwilder/nginx-proxy/issues/487#issuecomment-230093806

+1 for allowing containers to be exposed on the default bridge

EDIT: Finally, I was able to solve the following issue using a custom docker network (e.g., front). For the moment, since we can't to do so using the default bridge because of the legacy mode, you can follow steps described here with such this project...


Hi, just wondering if there is any updates about this issue?

TL;DR: Trying to set up a front network stack over a custom bridge (pre-existing bridge) along with an internal network (public and private network at the same time) without using port-mapping or IPTables, but bridges.

I'm trying to set up such this project, here is a try:

version: '3.0'
networks:
    back:
        driver: bridge
        driver_opts:
            com.docker.network.bridge.enable_ip_masquerade: "false"
            com.docker.network.internal: "true"
        internal: true
        ipam:
            driver: default
            config:
                - subnet: 10.1.0.0/24
    front:
        external:
            name: bridge
services:
    db:
        image: mariadb:latest
        container_name: db
        environment:
            MYSQL_DATABASE: app
            MYSQL_PASSWORD: app-admin
            MYSQL_ROOT_PASSWORD: root
            MYSQL_USER: admin-app
        ports:
            - 3306:3306/tcp
        # network_mode: bridge
        networks:
            - back
        restart: always
        volumes:
            - ${ROOT}/conf/mysql/my.cnf:/etc/mysql/conf.d/my.cnf:ro
            - dbdata:/var/lib/mysql:rw
    http:
        build: build/nginx
        container_name: http
        links:
            - php
        ports:
            - 80:80/tcp
            - 443:443/tcp
        # network_mode: bridge
        networks:
            - front
        restart: always
        volumes:
            - ${ROOT}/conf/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
            - ${ROOT}/conf/nginx/conf.d:/etc/nginx/conf.d:ro
            - ${ROOT}/data/www/webroot:/usr/share/nginx/webroot:ro
            - ${ROOT}/data/www/lab:/usr/share/nginx/lab:ro
            - ${ROOT}/data/www/vendor:/usr/share/nginx/vendor:ro
            - ${ROOT}/data/www/static:/usr/share/nginx/static:ro
            - ${ROOT}/log/nginx:/usr/share/nginx/log:rw
    php:
        build: build/php-fpm
        container_name: php
        links:
            - db
        privileged: true
        # network_mode: bridge
        networks:
            - front
            - back
        restart: always
        command: php-fpm --allow-to-run-as-root
        volumes:
            - ${ROOT}/conf/php-fpm/www.conf:/etc/php5/fpm/pool.d/www.conf:ro
            - ${ROOT}/conf/php/php.ini:/usr/local/etc/php/php.ini:ro
            - ${ROOT}/data/www/webroot:/usr/share/nginx/webroot:ro
            - ${ROOT}/data/www/lab:/usr/share/nginx/lab:ro
            - ${ROOT}/data/www/vendor:/usr/share/nginx/vendor:rw
volumes:
    dbdata:
        driver: local

I've set up a custom bridge (/etc/network/interfaces):

# Loopback NIC
auto lo
iface lo inet loopback

# Ethernet NIC
auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto br0
iface br0 inet static
    bridge_ports eth0
    address 172.16.57.148
    netmask 255.255.0.0
    gateway 172.16.10.1
    dns-search miletrie.lan
    dns-nameservers 172.16.57.146 172.16.10.32 172.16.10.33

And, configured my dockerd to use it instead of the default docker0 bridge:

systemctl stop docker.service docker.socket
ip link set dev docker0 down
brctl delbr docker0
cat <<-'EOF' >/etc/default/docker
##
# Location of Docker binary (especially for development testing)
#
DOCKERD="/usr/bin/dockerd"

##
# General daemon startup options
# https://docs.docker.com/engine/reference/commandline/docker/
#
DOCKER_OPTS="--ip=0.0.0.0 \
             --ipv6=false \
             --ip-masq=false \
             --ip-forward=false \
             --iptables=false \
             --userland-proxy=false \
             --icc=true \
             --bridge=br0 \
             --fixed-cidr=172.16.57.224/28 \
             --dns=172.16.10.32 \
             --dns=172.16.10.33 \
             --dns-search=miletrie.chl"

EOF
cat <<-'EOF' >/etc/systemd/system/docker.service.d/exec.conf
[Service]
EnvironmentFile=-/etc/default/docker
ExecStart=
ExecStart=/usr/bin/dockerd $DOCKER_OPTS

EOF
systemctl daemon-reload
systemctl restart docker.service docker.socket

Complete steps are described here.

Now, when I try to set up the project:

docker-compose pull
docker-compose build
docker-compose up -d

It returns the following error:

ERROR: for php  Network-scoped alias is supported only for containers in user defined networks
ERROR: Encountered errors while bringing up the project.

Please let me know if you need more information!

Looking forward to hearing from you!

Almost a year and a half and no word on this error message? It's so incredibly vague and this issue is the top result for it.

Can we get some information here?

This would be absolutely helpful with nginx-proxy, see here:
jwilder/nginx-proxy#487 (comment)

I have the same problem, and I also posted a question in https://stackoverflow.com/questions/57782423/how-to-make-a-docker-compose-service-to-use-multiple-network, but still got little help.

This would be very helpful for gradual migration to user defined networks.

@Creased -- you mentioned you had found a workaround. The link provided seems to no longer work -- could you describe the steps here?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This is still relevant.

This issue has been automatically marked as not stale anymore due to the recent activity.

Bump. What if you want to upgrade to docker-compose on an existing stack? This approach assumes 100% greenfield.

Was this page helpful?
0 / 5 - 0 ratings