Temporary placeholder so I can get a task ID for the pull request, will be edited and filled out in a few minutesThe goal here was to gain a few more options around configurability for containers.
The two pieces of this goal are:
* Better build configurability, without the need for a full blown custom repository. To this end, I've introduced the option to be able build a container based on a Dockerfile/Containerfile. This would allow near infinite configurability.
* Better network management. I'm one that hates NAT/masquerading and the lack of concise control over the network. So this allows one to create a traditional bridge, minus the NAT, which can then be dropped into something like a zone firewall.
Example config:
```
admin@edge# show container
name ubuntubuild {
containerfile /config/containers/kroytest.Containerfile
image kroy/test
network service01 {
address 10.72.1.202
}
}
name ubuntutest {
image ubuntu:focal
network service01 {
}
}
network service01 {
enable-bridging
prefix 10.72.1.0/24
}
```
The container, `ubuntubuild` builds a container based on the Containerfile noted and has a static IP
```
admin@edge# cat /config/containers/kroytest.Containerfile
FROM ubuntu:20.04
RUN apt-get update -y
RUN apt-get install ssh-import-id -y
RUN apt-get install openssh-server -y
RUN apt-get install iproute2 -y
CMD ssh-import-id-gh kroy-the-rabbit && service ssh start && bash
```
The container `ubuntutest` just pulls from the registry as normal. It gains an IP address automatically.
The next change is the `enable-bridging` in the network. This disables the masquerading functionality of the network and exposes the network directly.
So a traceroute through my desktop. Hop #2 is the VyOS install running the container.
```
❯ traceroute 10.72.1.202
traceroute to 10.72.1.202 (10.72.1.202), 30 hops max, 60 byte packets
1 route01.lan.kroy.io (10.9.1.3) 0.662 ms 0.618 ms 0.606 ms
2 10.245.245.9 (10.245.245.9) 0.860 ms 0.699 ms 0.838 ms
3 10.72.1.202 (10.72.1.202) 0.881 ms 0.870 ms 0.860 ms
```
***
There are two outstanding things from this that I'm not fully sure how to resolve.
* Right now this works flawlessly with zone based firewalls. But I'm not sure what to do to allow this interface to use traditional firewalling. Does it just need to include a template?
```
set zone-policy zone LAN interface cni-podman0
```
* cnd-podman0 is now available for use in NAT/firewalling/etc. But it's ugly and not very VyOS-y. This can be changed, but I'm not sure to what. `container0`, `container1` etc?
This is all tested and working and pull request is incoming.