11:40 a.m.
Hi Keith!
Thanks for taking the time to explore this with me!
For each container that doesn't need to talk to any other
container, set `network_mode: none` for that container's entry in the `services:`
top-level element. Please note that I haven't personally tried combining
`network_mode: none` with `ports:` within the same container, so if that doesn't work
as I described that may be my fault.
Generally I'm not too interested in blocking containers entirely - I'm
interested in web app containers that are either on the other side of
the proxy themselves, or communicating with the container that is.
For each container that needs to talk to another container, define a
network in the `networks:` top-level element with `internal: true` set for it. In each
container's entry in the `services:` top-level element, include that network in
`networks:`.
When I do that, DNS name resolution stops working: I cannot nslookup
<other container> e.g. a database from within a web server container,
which is useful for avoiding having to hardcode IPs. Any way to help
with that?
I think the podman resolver (Netavark) is listening on the configured IP
in /etc/resolv.conf (10.89.0.1:53 for example) but trying to talk to it
times out.
If you only want the containers' exposed ports to be accessible
on the machine running the containers, specify 127.0.0.1 in addition to the port(s)
themselves in each container's `ports:` section (syntax here:
https://github.com/compose-spec/compose-spec/blob/master/05-services.md#p...).
Yup, I already do that.