1

I try to expose a container fully into the host network with podman, with the following requirements:

  • container (will containe a DC) must be reachable from computers in the host's network
  • host must be able to communicate with the container.

The host is running debian bullseye.

So far, I have found that using the a macvlan is not the route I want to go, as it prevents host-container communication.

As detailed in the second part of this article, I set up a bridge on the host, see config attached:

    # file: /etc/network/interfaces                                
    # interfaces(5) file used by ifup(8) and ifdown(8)
    # Include files from /etc/network/interfaces.d:
    source /etc/network/interfaces.d/*

    # The loopback network interface
    auto lo
    iface lo inet loopback


    #file: /etc/network/interfaces.d/br0
    ## DHCP ip config file for br0 ##
    auto br0

    # Bridge setup
    iface br0 inet dhcp
        bridge_ports enp7s0

where enp7s0 is my ethernet device. No other config file in present in /etc/network/interfaces.d/.

Then I added a minimal brdge network using

$ sudo podman network create -d bridge  --ipv6 bridge_local
bridge_local

and I edit the configuration manually:

$ sudo nano /etc/cni/net.d/bridge_local.conflist
/etc/cni/net.d/bridge_local.conflist
{
   "cniVersion": "0.4.0",
   "name": "bridge_local",
   "plugins": [
      {
         "type": "bridge",
         "bridge": "br0",
         "ipam": {
                "type": "static",
                "addresses": [
                    {
                    "address" : "10.0.1.2/24",
                    "gateway" : "10.0.1.1"
                    }
                ],
                "routes": [
                    { "dst": "0.0.0.0/0" }
                ],
                "dns": {
                    "nameservers": [ "10.0.1.1" ]
                }
            }
         "capabilities": {
            "ips": true,
            "mac": true
         }
      },
      {
         "type": "tuning"
      }
   ]
}

With that configuration, I can create a testing container and run it, e.g.

$ sudo podman create -t --name service.dev3  --network=bridge_local alpine
...
$ sudo podman start service.dev3
service.dev3
$ sudo podman exec -it service.dev3 sh

/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    ...
    inet 10.0.1.2/24 brd 10.0.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    ...

As you can see, and as it is configrured, the testing container is assigned the IP adress 10.0.1.2. However, I would prefer to assign the IPs when creating the images, i.e. call

sudo podman create -t --name service.dev3  --network=bridge_local --ip 10.0.1.3 alpine

and not be limited to a fixed number of IPs in the network by configuration. However, the --ip flag seems to get ignored, and the resulting container still has IP 10.0.1.2. What do I need to configure to assign the IPs on creation manually?

marc
  • 264
  • 1
  • 2
  • 17
  • Why not just run the container with `--network host`? This will run it in the host's global network namespace; services running inside the container will be available to the host and will also be available to remote systems (as long they are not binding to `localhost`). – larsks Aug 08 '22 at 22:27
  • I know, that ``host`` networking would make communication between this container and the host easier. However, in view of future and additional containers, I would prefer them to appear as different units from my host. Considering future containers, many of them will have port conflicts, and if I understand correctly,, ``host`` etworking needs port (re)mapping. So, assigning separate IPs is my preferred solution. – marc Aug 09 '22 at 10:21
  • I'm having a very similar issue, it seems that neither the host nor the container sets arp information properly. What is even weirder is that arp requests for that IP are broadcasted, but no device on my lan will respond, even though I've tested and have been able to ping both the host and container from devices on the lan. – Desultory Nov 05 '22 at 23:34

0 Answers0