[systemd-devel] Container, private network and socket activation

Tue Feb 3 19:40:33 PST 2015

> Hmm, to implement something like this I think the best option would be
> to set up the interface to later pass to the container first on the
> host, then listen on the container's IP address on the host. When a
> connection comes in the container would have to be started via socket
> activation, and would then have to take over the container interface
> (with --network-interface=), so that all further connections are
> delivered directly to the container and the host is not involved
> anymore. 

I managed to set this up. In short:

# ip link add type veth
# ip addr add 192.168.10.10/24 brd + dev veth1
# ip addr add 192.168.10.20/24 brd + dev veth0
# ip link set veth1 up
# ip link set veth0 up
# brctl addif br_lxc veth0

This sets two interfaces, one of which (veth1) goes to the container via
the following service file:

[Unit]
Description=My little container

[Service]
Type=simple
KillMode=process
ExecStart=/usr/bin/systemd-nspawn -jbD /media/Kabi/debian-tree/ \
	--network-interface=veth1 \
	--bind /media/Kabi/apache/:/apache/ \
	--bind /media/Kabi/backup_packages/apt/archives/:/var/cache/apt/archives/ \
	--bind /media/Kabi/repozytorium:/repozytorium \
	3

In addition, I have my bridge interface set:

auto br_lxc
iface br_lxc inet static
	address 192.168.10.100
	netmask 255.255.255.0
	broadcast 192.168.10.255
	bridge_ports none
	bridge_waitport 0
	bridge_fd 0

The next thing is to socket activate the container through this file:

[Unit]
Description=The HTTP/HTTPS socket of my little container

[Socket]
ListenStream=192.168.10.10:80
ListenStream=192.168.10.10:443

When I start the socket, I get:

root:~# systemctl start mycontainer.socket
root:~# systemctl status mycontainer.socket
● mycontainer.socket - The HTTP/HTTPS socket of my little container
   Loaded: loaded (/etc/systemd/system/mycontainer.socket; static; vendor preset: enabled)
   Active: active (listening) since Wed 2015-02-04 04:00:51 CET; 1s ago
   Listen: 192.168.10.10:80 (Stream)
           192.168.10.10:443 (Stream)

Feb 04 04:00:51 morfikownia systemd[1]: Listening on The HTTP/HTTPS socket of my little container.

That's all for the host.

In the container I had to configure the passed interface via /etc/network/interface :

auto veth1
iface veth1 inet static
        address 192.168.10.10
        netmask 255.255.255.0
        broadcast 192.168.10.255
        gateway 192.168.10.100

And that's it. This setup works. I mean, when I type in my firefox http://192.168.10.10, the
container boots and I'm able to browse the page.

Now I have some questions:

1. When I try to connect for the very first time, I get a timeout, even though the container
is working. I can cancel the connection immediately, and reconnect after 2-3 sec and then the
page shows up. All subsequent connections work without a problem, just the first one gets
a timeout. Is there a way to fix this, so the first connection that boots the system could
be somehow delayed, so after a while the page would show up?
2. Is there a way to shut down the container automatically after some period of inactivity?
Let's say there's no traffic for 30min, and after this time the container goes down.
3. How to stop the container manually? I'm asking because when I try via
"systemctl stop mycontainer.service" , it stops, but:

...
Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Halting system.
Feb 04 04:15:58 morfikownia systemd-machined[14353]: Machine debian-tree terminated.
Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Container debian-tree has been shut down.
Feb 04 04:15:58 morfikownia systemd[1]: Starting My little container...
Feb 04 04:15:58 morfikownia systemd[1]: Stopping Container debian-tree.
Feb 04 04:15:58 morfikownia systemd[1]: Stopped Container debian-tree.
Feb 04 04:15:58 morfikownia kernel: br_lxc: port 1(veth0) entered disabled state
Feb 04 04:15:58 morfikownia kernel: device veth0 left promiscuous mode
Feb 04 04:15:58 morfikownia kernel: br_lxc: port 1(veth0) entered disabled state
Feb 04 04:15:58 morfikownia systemd-nspawn[15325]: Spawning container debian-tree on /media/Kabi/debian-tree.
Feb 04 04:15:58 morfikownia systemd-nspawn[15325]: Press ^] three times within 1s to kill container.
Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service: main process exited, code=exited, status=237/n/a
Feb 04 04:15:58 morfikownia systemd[1]: Failed to start My little container.
Feb 04 04:15:58 morfikownia systemd[1]: Unit mycontainer.service entered failed state.
Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service failed.
Feb 04 04:15:58 morfikownia systemd[1]: Starting My little container...
Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service: main process exited, code=exited, status=237/n/a
Feb 04 04:15:58 morfikownia systemd[1]: Failed to start My little container.
Feb 04 04:15:58 morfikownia systemd[1]: Unit mycontainer.service entered failed state.
Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service failed.
Feb 04 04:15:58 morfikownia systemd[1]: Starting My little container...
Feb 04 04:15:58 morfikownia systemd-nspawn[15325]: Failed to resolve interface veth1: No such device
Feb 04 04:15:58 morfikownia systemd-nspawn[15338]: Spawning container debian-tree on /media/Kabi/debian-tree.
Feb 04 04:15:58 morfikownia systemd-nspawn[15338]: Press ^] three times within 1s to kill container.
Feb 04 04:15:58 morfikownia systemd-nspawn[15338]: Failed to resolve interface veth1: No such device
Feb 04 04:15:58 morfikownia systemd[1]: mycontainer.service: main process exited, code=exited, status=237/n/a
Feb 04 04:15:58 morfikownia systemd[1]: Failed to start My little container.
...

Why does it boot immediately after shutdown?

4. Is there a way to persist the interfaces (veth0 and veth1)? Because after the container
goes down, they're deleted, so I have to create them anew.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150204/ad131ad4/attachment.sig>