Runc: networking setup inside the container

Created on 26 Jun 2015  Â·  8Comments  Â·  Source: opencontainers/runc

Hello,

runc is working fine. thanks for that.

However, I would like to get networking connectivity inside the container first and then next stage to get container talking to the host and eventually to the internet.

I've defined network key in container.json as such:

$ cat container.json                                                                                                                                          [...]
    "network": [
    {
        "type": "loopback",
        "address": "127.0.0.1/0",
        "gateway": "localhost"
    },
    {
        "type": "veth",
            "name": "net",
        "bridge": "br0",
        "address": "172.17.42.2",
        "gateway": "172.17.42.1",
        "host_interface_name": "veth0"
    }
    ],
[...]

However, i can't connect to a listening socket inside the container:

root@shell:~# cat test.py 
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
s.bind(('127.0.0.1', 1234))
s.listen(0)
while True:
    m = s.accept()
    print 'ack'
(virtualenv)root@shell:~# python test.py &
[1] 21
(virtualenv)root@shell:~# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:1234          0.0.0.0:*               LISTEN      21/python    
(virtualenv)root@shell:~# echo a >/dev/tcp/127.0.0.1/1234
bash: connect: Network is unreachable
bash: /dev/tcp/127.0.0.1/1234: Network is unreachable
(virtualenv)root@shell:~# ip addr
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
(virtualenv)root@shell:~# ifconfig lo 127.0.0.1 up
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFFLAGS: Operation not permitted

Some sys details below:

$ runc -v
runc version 0.1
$ uname -a
Linux octopus 3.19.0-22-generic #22-Ubuntu SMP Tue Jun 16 17:15:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 15.04
Release:    15.04
Codename:   vivid

How to get interface lo up and get the socket talking?
Thanks.

Most helpful comment

On Fri, Jun 26, 2015 at 10:18:27AM -0700, Alexander Morozov wrote:

There is no network section in spec now. We probably should have some.

For what it's worth, you can currently (48182db8c, 2015-07-07) just
use the host's network configuration with the following changes to the
stock config:

  • Add to mounts:

{
"type": "bind",
"source": "/etc/resolv.conf",
"destination": "/etc/resolv.conf",
"options": "rbind,ro"
}

  • Remove from linux.resources:

"network": {
"classId": "",
"priorities": null
}

  • Remove from linux.namespaces:

{
"type": "network",
"path": ""
}

If you want ‘ping’ and similar to work in your container, add NET_RAW
to linux.capabilities.

All 8 comments

Full container.json below:

{
    "version": "0.1",
    "os": "linux",
    "arch": "amd64",
    "processes": [
        {
            "tty": true,
        "user": "root",
            "args": [
                "bash"
            ],
            "env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
                "TERM=xterm"
            ],
            "cwd": "/root"
        }
    ],
    "root": {
        "path": "rootfs",
        "readonly": false 
    },
    "cpus": 1.1,
    "memory": 1024,
    "hostname": "shell",
    "network": [
    {
        "type": "loopback",
        "address": "127.0.0.1/0",
        "gateway": "localhost"
    },
    {
        "type": "veth",
            "name": "net",
        "bridge": "br0",
        "address": "172.17.42.2",
        "gateway": "172.17.42.1",
        "host_interface_name": "veth0"
    }

    ],
    "namespaces": [
        {
            "type": "process"
        },
        {
            "type": "network"
        },
        {
            "type": "mount"
        },
        {
            "type": "ipc"
        },
        {
            "type": "uts"
        }
    ],
    "capabilities": [
        "AUDIT_WRITE",
        "KILL",
        "NET_BIND_SERVICE",
    "CHOWN",
        "DAC_OVERRIDE",
        "FSETID",
        "FOWNER",
        "MKNOD",
        "NET_RAW",
        "SETGID",
        "SETUID",
        "SETFCAP",
        "SETPCAP",
        "NET_BIND_SERVICE",
        "SYS_CHROOT",
        "KILL",
        "AUDIT_WRITE"
    ],
    "devices": [
        "null",
        "random",
        "full",
        "tty",
        "zero",
        "urandom"
    ],
    "mounts": [
        {
            "type": "proc",
            "source": "proc",
            "destination": "/proc",
            "options": ""
        },
        {
            "type": "tmpfs",
            "source": "tmpfs",
            "destination": "/dev",
            "options": "nosuid,strictatime,mode=755,size=65536k"
        },
        {
            "type": "devpts",
            "source": "devpts",
            "destination": "/dev/pts",
            "options": "nosuid,noexec,newinstance,ptmxmode=0666,mode=0620,gid=5"
        },
        {
            "type": "tmpfs",
            "source": "shm",
            "destination": "/dev/shm",
            "options": "nosuid,noexec,nodev,mode=1777,size=65536k"
        },
        {
            "type": "mqueue",
            "source": "mqueue",
            "destination": "/dev/mqueue",
            "options": "nosuid,noexec,nodev"
        },
        {
            "type": "sysfs",
            "source": "sysfs",
            "destination": "/sys",
            "options": "nosuid,noexec,nodev"
        }
    ]
}

There is no network section in spec now. We probably should have some.

I also vote for networking ... just ran across this after testing out runc

On Fri, Jun 26, 2015 at 10:18:27AM -0700, Alexander Morozov wrote:

There is no network section in spec now. We probably should have some.

For what it's worth, you can currently (48182db8c, 2015-07-07) just
use the host's network configuration with the following changes to the
stock config:

  • Add to mounts:

{
"type": "bind",
"source": "/etc/resolv.conf",
"destination": "/etc/resolv.conf",
"options": "rbind,ro"
}

  • Remove from linux.resources:

"network": {
"classId": "",
"priorities": null
}

  • Remove from linux.namespaces:

{
"type": "network",
"path": ""
}

If you want ‘ping’ and similar to work in your container, add NET_RAW
to linux.capabilities.

instead of adding a networks section to the spec, one can just prepare a complete network namespace (e.g.: using libnetwork or appc CNI plugins) and pass it in as the netns path:

"namespaces": [
    {
        "type": "network",
        "path": "/var/run/netns/something"
    }
],

@fabiokung It's definitely not so easy in many cases(we learned it hardway with libnetwork). Also for many people will be enough just veth pair or ipvlan interface by default.

You can see my response here for a proper way to setup networking for containers spawned with runc

https://github.com/opencontainers/runc/issues/201#issuecomment-182626457

Thanks!

instead of adding a networks section to the spec, one can just prepare a complete network namespace (e.g.: using libnetwork or appc CNI plugins) and pass it in as the netns path:

"namespaces": [
    {
        "type": "network",
        "path": "/var/run/netns/something"
    }
],

This will help.
https://medium.com/@Mark.io/https-medium-com-mark-io-network-setup-with-runc-containers-46b5a9cc4c5b

Was this page helpful?
0 / 5 - 0 ratings