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.
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:
{
"type": "bind",
"source": "/etc/resolv.conf",
"destination": "/etc/resolv.conf",
"options": "rbind,ro"
}
"network": {
"classId": "",
"priorities": null
}
{
"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
networkssection 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
Most helpful comment
On Fri, Jun 26, 2015 at 10:18:27AM -0700, Alexander Morozov wrote:
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:
{
"type": "bind",
"source": "/etc/resolv.conf",
"destination": "/etc/resolv.conf",
"options": "rbind,ro"
}
"network": {
"classId": "",
"priorities": null
}
{
"type": "network",
"path": ""
}
If you want ‘ping’ and similar to work in your container, add NET_RAW
to linux.capabilities.