Files
infix/doc/container.md
T

110 lines
3.6 KiB
Markdown

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.
[podman]: https://podman.io