network_mode/--network should be applied to pod instead of container

[rugk]

Similar to #314 and as a result of containers/podman#10878 and other's, i.e. two use cases of actually getting the correct IP and being able to access the localhost of the host (without host networking) forced me to use such a YAML with a special podman network mode called slirp4netns with allow_host_loopback and port_handler=slirp4netns.
The only alternative is to use host networking, which the doc (IMHO correctly) says is "considered insecure"…

STR

So, here is a YAML:

version: "3.7"

services:

  caddy:
    image: caddy
    restart: unless-stopped
    network_mode: "slirp4netns:port_handler=slirp4netns,enable_ipv6=true,allow_host_loopback=true"
    ports:
      - "80:80"
      - "443:443"
      # […]
    volumes:
      - caddy_data:/data
      - caddy_config:/config
      # [ caddyfile etc.]
      # [ … ]
    environment:
      - HOST_DOMAIN=host.containers.internal
      - MAIL_ACME=${MAIL_ACME:?MAIL_ACME variable missing}
    labels:
      - io.containers.autoupdate=registry

volumes:
  caddy_data:
    # always persist volume by forcing external creation
    # https://docs.docker.com/compose/compose-file/compose-file-v3/#external
    external: true
  caddy_config:

What happens

This starts up like this:

$ podman-compose --dry-run -p caddy up
podman pod create --name=caddy --share net -p 80:80 […] -p 443:443
podman volume inspect caddy_caddy_data || podman volume create caddy_caddy_data
podman volume inspect caddy_caddy_config || podman volume create caddy_caddy_config
podman create --name=caddy_caddy_1 --pod=caddy --label io.containers.autoupdate=registry --label io.podman.compose.config-hash=123 --label io.podman.compose.project=caddy --label io.podman.compose.version=0.0.1 --label com.docker.compose.container-number=1 --label com.docker.compose.service=caddy --network slirp4netns:port_handler=slirp4netns,allow_host_loopback=true -e HOST_DOMAIN=host.containers.internal -e MAIL_ACME=************* -v caddy_caddy_data:/data -v caddy_caddy_config:/config […] --add-host caddy:127.0.0.1 --add-host caddy_caddy_1:127.0.0.1 --restart unless-stopped caddy

The problem here is that the pod does not use --network slirp4netns:port_handler=slirp4netns,allow_host_loopback=true, but only the container. This means the container's networking is totally off…

What should happen

$ podman pod create --name=caddy --share net -p 443:443 -p 80:80 […] --network slirp4netns:port_handler=slirp4netns,allow_host_loopback=true
$ podman create --name=caddy_caddy_1 --pod=caddy --label io.containers.autoupdate=registry --label io.podman.compose.config-hash=123 --label io.podman.compose.project=caddy --label io.podman.compose.version=0.0.1 --label com.docker.compose.container-number=1 --label com.docker.compose.service=caddy -e HOST_DOMAIN=host.containers.internal -e MAIL_ACME=********** -v caddy_caddy_data:/data -v caddy_caddy_config:/config […] --add-host caddy:127.0.0.1 --add-host caddy_caddy_1:127.0.0.1 --restart unless-stopped caddy
podman start -a caddy_caddy_1

When you run this, it works as it moves the network option to the pod --network slirp4netns:port_handler=slirp4netns,allow_host_loopback=true and the container seems to use the correct networking and both things work.

Workaround (failed)

Now I saw #283, so i tried this:

$ podman-compose --podman-run-args='--network slirp4netns:port_handler=slirp4netns,allow_host_loopback=true' -p caddy up

Also adding -t identity does not help.

However, just using -t identity does help, of course, as I only have one container in my YAML file. But well… that is more of a workaround is not it?

In other ways: How can I get it to work as expected (see above), respectively can it be changed to always work like this? Because what it currently does by applying the network_mode only to the container is of course never useful I guess and just creates (unexpected) network errors. (.e.g the ports are then just not exposed or so)

System

$ podman-compose version
using podman version: podman version 3.2.0
podman-composer version  0.1.7dev
podman --version
podman version 3.2.0
0
$ podman version
Version:      3.2.0
API Version:  3.2.0
Go Version:   go1.16.3
Built:        Wed Jun  9 16:24:16 2021
OS/Arch:      linux/amd64

same as in #314, basically

[SegHaxx]

Is having the client IP always be 10.0.2.100 in my nginx logs somehow a desirable use case? How am I supposed to run analytics on that?

Anyway a hacky workaround is to just make the pod by hand first, then use podman-compose to bring the rest up:

podman pod create --name=nginx --share net -p 443:443 -p 80:80 --network slirp4netns:port_handler=slirp4netns;podman-compose up

[muayyad-alsadi]

please try the latest podman-compose from v1.x branch
which is totally reworked so that it uses CNI networking no need for the 1podfw workaround.

[rugk]

Nicce, this sounds awesome! So further podman-compose don't need that --network slirp4netns:port_handler=slirp4netns; workaround anymore? Even in rootless mode? Cool!

[muayyad-alsadi]

yes even in rootless