Docker-compose : can't connect to existing network

Docker Engine Compose
1

Hi,

I’m new to docker so forgive me is the answer to my question sounds obvious.

I’d like to connect a docker-composed container to an existing network.

Following the documentation, I added the following statements to my docker-compose.yml :

version: '3'

services:
    (...)

networks:
   default:
      external:
         name: aeria

Aeria is an existing network.

The created container doesn’t seems to be connected to that network. I used docker inspect and saw the the container is actually not connected to the right network :

"NetworkSettings": {
        "Bridge": "",
        "SandboxID": "f61e671c2ed4476f89bb5e602c8d7939bb7bf9cf8ef72fc46508fd324c518371",
        "HairpinMode": false,
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "Ports": {},
        "SandboxKey": "/var/run/docker/netns/f61e671c2ed4",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null,
        "EndpointID": "",
        "Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "",
        "IPPrefixLen": 0,
        "IPv6Gateway": "",
        "MacAddress": "",
        "Networks": {
            "bridge": {
                "IPAMConfig": null,
                "Links": null,
                "Aliases": null,
                "NetworkID": "",
                "EndpointID": "",
                "Gateway": "",
                "IPAddress": "",
                "IPPrefixLen": 0,
                "IPv6Gateway": "",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "",
                "DriverOpts": null
            }
        }

What’s that “Bridge” network ? It’s not existing.

# docker network ls                                                                          
NETWORK ID          NAME                DRIVER                       SCOPE
88ae769606f7        aeria               devplayer0/net-dhcp:latest   local
474eb6514fc5        aqua                bridge                       local
b2d5e297fcc0        host                host                         local
efac22fde510        none                null                         local

I’m lost. Thanks for your help.

Matt

2

Nobody ? :confused: That looks like a real issue !

3

You are using a customer network driver. So apparently no one knows “devplayer0/net-dhcp:latest” or its behavior. This is not just “Aeria is an existing network.”… this can be a bag full of surprises…
I would suggest to get in touch with the developer of the plugin.

4

Thank you @meyay. You are right. But I should have added that I tried with another (bridged) network and also with the automatically created network.

Result is always the same : no internet connectivity (apt update not working). I’m still investigating but I’m starting to think that it could be something else than this network problem. Does docker inspect report correctly the network information of an aborted Docker-compose session ?

5

docker inspect uses internal metadata, the result should reflect the current state.

You docker-compose.yml looks about right. Did you specificly create the networks with docker network create?

6

No because it it already created :blush:

Matthieu G. (en mode mobile)

7

So this is not a custom network you added sometime ago?!
Please share the output of docker network inspect.

8 
# docker  network inspect aeria
[
{
    "Name": "aeria",
    "Id": "88ae769606f7acff358e153f7f54335f5db41e9516c721c14c9f550dd38ced07",
    "Created": "2020-05-18T10:30:28.377188202+02:00",
    "Scope": "local",
    "Driver": "devplayer0/net-dhcp:latest",
    "EnableIPv6": false,
    "IPAM": {
        "Driver": "null",
        "Options": {},
        "Config": [
            {
                "Subnet": "0.0.0.0/0"
            }
        ]
    },
    "Internal": false,
    "Attachable": false,
    "Ingress": false,
    "ConfigFrom": {
        "Network": ""
    },
    "ConfigOnly": false,
    "Containers": {},
    "Options": {
        "bridge": "br0"
    },
    "Labels": {}
}
]

That’s a working network, I have three containers on it…

9

Oh, I hoped you would re-do your example with a different network driver and share details about that.
For this driver my suggestion is still to get in touch with the developer, as its behavior is completly unclear.

10

OK. Let’s try with aqua, which is a simple network with driver:bind :

in docker-compose.yml :

networks:
  default:
    external:
       name: aqua

I run docker-compose :

# docker-compose  -f docker-compose.yml -f docker-compose.prod.yml up -d 
Building web
Step 1/24 : FROM php:7.3.9-apache
 ---> 6f7c5e29a126
Step 2/24 : RUN apt-get update && apt-get install -y               libcurl4-gnutls-dev               libmcrypt-dev               libmosquitto-dev               gettext               nano               git-core
 ---> Running in c3d4df5b1996
Err:1 http://deb.debian.org/debian buster InRelease
  Temporary failure resolving 'deb.debian.org'

See ? No internet connectivity, even if it succeeded to connect to the network (otherwise their would be an error message).

docker inspect the container created at this step :

# docker inspect c3d4df5b1996
[
    {
        "Id": "c3d4df5b1996797e403990f58eabe1684e507cb78dd667d9d5c9a7026a9e4784",
        "Created": "2020-05-23T06:25:44.062570686Z",
        "Path": "/bin/sh",
        "Args": [
            "-c",
            "apt-get update && apt-get install -y               libcurl4-gnutls-dev               libmcrypt-dev               libmosquitto-dev               gettext               nano               git-core"
        ],
        "State": {
            "Status": "exited",
            "Running": false,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 0,
            "ExitCode": 100,
            "Error": "",
            "StartedAt": "2020-05-23T06:25:49.564309588Z",
            "FinishedAt": "2020-05-23T06:25:51.522288446Z"
        },
        "Image": "sha256:6f7c5e29a126ffe8f0389af3d6e591893a43150a19957692bcbb62c0259e4623",
        "ResolvConfPath": "/var/lib/docker/containers/c3d4df5b1996797e403990f58eabe1684e507cb78dd667d9d5c9a7026a9e4784/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/c3d4df5b1996797e403990f58eabe1684e507cb78dd667d9d5c9a7026a9e4784/hostname",
        "HostsPath": "/var/lib/docker/containers/c3d4df5b1996797e403990f58eabe1684e507cb78dd667d9d5c9a7026a9e4784/hosts",
        "LogPath": "",
        "Name": "/adoring_keldysh",
        "RestartCount": 0,
        "Driver": "devicemapper",
        "Platform": "linux",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": null,
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "none",
                "Config": {}
            },
            "NetworkMode": "default",
            "PortBindings": null,
            "RestartPolicy": {
                "Name": "",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "CapAdd": null,
            "CapDrop": null,
            "Capabilities": null,
            "Dns": null,
            "DnsOptions": null,
            "DnsSearch": null,
            "ExtraHosts": null,
            "GroupAdd": null,
            "IpcMode": "private",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "NanoCpus": 0,
            "CgroupParent": "",
            "BlkioWeight": 0,
            "BlkioWeightDevice": null,
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": null,
            "DeviceCgroupRules": null,
            "DeviceRequests": null,
            "KernelMemory": 0,
            "KernelMemoryTCP": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": null,
            "OomKillDisable": false,
            "IPv6Gateway": "",
            "MacAddress": "",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "",
                    "EndpointID": "",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "",
                    "DriverOpts": null
                }
            }
        }
    }
]

Thanks for your help !

11

Update : I tried with a basic alpine container, with RUN apk update in the Dockerfile. It doesn’t work either.

I’m puzzled.

12

I have no experience whether the network actualy is used during an image build as well, as I always seperate build and runtime configurations. I usualy have a makefile that encapsulates the details on how to build my apps, my containers, publishes their artifacts and deploys thir services. I use the makefile localy during development and from within a cicd-pipelines that is triggered by git pushs.

I only experienced those type of network issues on AWS with EKS and KOPS clusters, when I deploy a Kubernetes build pod to build base images that download stuff from the internet. I never experienced the same problem with Docker Enterprise on AWS.

Thus, said: I have never seen that a network inspect does not list all containers connected to it. it is odd that your container only is attached to a network called “bridge” to it, even though you placed it in a different network. It is absolutly odd that all details have empty/null values for this network. I have never seen this before.

After gathering the facts (main fact beeing: details are missing and wrong), I am clueless as you. It doesn’t make sense and looks like something is seriously messed up. I would disable the firewall, restart the host and see if the behavior still exists - maybee it is just a hickup.

Good luck!

13

Thank you so much for sharing your thoughts with me.

I did some more tests today.

  • I believe that the oddities are the consequence of the aborted state of the container composed by docker-compose. Therefore there would be nothing to learn from the status of that wanna-be container.

  • I successfully build a simple container using compose and was able to attach to it and confirm that it had internet access. However, composing the same container with a RUN apt-get update statement in the docker-compose.yml file failed the same way as explained above.

Conclusion, this has nothing to do with a network attachment problem like I thought. It would be related that some odd state during the composing of the future container (?)

More to read here : https://stackoverflow.com/questions/39867602/no-internet-inside-docker-compose-service

I’ll report my future findings.

14

Hi,

It’s and older post but this issue is for attach existing networks into a docker-composer.yml file.

You need to put the network, but no need to define the driver type, only you need to put than this network has an external network:

services:
  
  yourservice:
        networks:
       - nameofnetwork
 
networks:
   nameofnetwork:
    external: true

you declare in the networks yml definition than this network is external. The name of the network as the same as the existing network, can’t change it inside the docker-composer file.

1 Like