infix/doc/container.md

Containers in Infix

The default builds of Infix do not enable any container support. This because it is not a common customer feature, and it extends build times due to bringing in a build-time dependency on Go.

However,customer specific builds may have it, and you can also roll your own based on any of the available defconfigs. For example:

cd infix/
make x86_64_defconfig

Docker Containers with Podman

Run menuconfig, search for podman, enable that and build:

make menuconfig
...
make

Enabling podman select crun, conmon, and all other dependencies. The build will take a while, but eventually you can:

make run

A convenience alias docker=podman is available, but remember, not all features or syntax of docker is available in podman.

Test it out with an example:

podman run -it --rm docker://hello-world

or a little web server:

podman run -d --rm -p 80:80 docker://nginx:alpine

In detached (-d) state you can check the status using podman ps or try to connect to the web server:

curl http://localhost

or

lynx http://localhost

Multiple Networks

It is also possible to start a container with multiple networks. The approach shown here uses CNI profiles, which means the interfaces names inside the container will always be: eth0, eth1, etc.

Pending VETH support in Infix/NETCONF, the following example sets up a VETH pair, then creates a CNI profile, and finally starts a container with two profiles, the default podman bridge and the VETH profile:

 ip link add local1 type veth peer local1_peer
 ip link set local1 up
 ip addr add 192.168.0.1/24 dev local1
 cni create host net1 local1_peer 192.168.0.42/24
 podman run -d --rm --net=podman,net1 --privileged docker://troglobit/buildroot:latest

The first profile (podman) is a the default bridged profile. When a container is started with that (default behavior), podman dynamically creates a VETH pair which has one end attached as a bridge port in the cni-podman0 bridge managed by podman, and the other end is brought up as eth0 inside the container.

The second profile is the one we created, it uses the host-device profile and does not create anything, it simply lifts the peer end of the pair into the container as eth1. This CNI profile can also be used to hand over control of physical ports to a container.

Note: here we start the container in --privileged mode. This allows the container guest unfiltered access to the host system and it might not be what you want for a production system. For that at least SECCOMP is recommended, which is out of scope for this tutorial.

NETCONF Build

If you've followed this tutorial then you now have a NETCONF based Infix system running. To run containers on it you need to leverage the Hybrid mode, described in the README but also repeated below.

To start containers in Hybrid Mode, provided the images have been downloaded with podman pull first):

root@infix:/cfg/start.d$ cat <<EOF >20-enable-container.sh
#!/bin/sh
podman-service -e -d "Nginx container" -p "-p 80:80" nginx:alpine
exit 0
EOF
root@infix:/cfg/start.d$ chmod +x 20-enable-container.sh

Reboot to activate the changes. To activate the changes without rebooting, run the script and call initctl reload.

Note: the /etc directory is a tmpfs ramdisk and contents will be lost on reboot, so to retain custom CNI profiles after reboot you need to either save them and restore in the script above, or recreate them on every boot.