I feel this seen map, as well as port info, is now a bit misplaced when we're looking at the HostPort and not the container port. This port is under container, but is a host port, so it may appear on multiple containers which would be confusing.

Since we're throwing away the information where this port maps to, it could be container X or Y depending on if it's listening on IPv4 or IPv6, for instance. Thus it would be listed on both container responses but likely only one of those will be reachable.

TL;DR, seen host ports are better placed outside the container structure, on the parent response.

❯ docker run -it --rm --name alpy1 -p 127.0.0.1:8181:8181 alpine❯ docker run -it --rm --name alpy2 -p :::8181:8182 alpine❯ docker inspect alpy1 alpy2 | jq '.[] | .Name, .NetworkSettings.Ports'"/alpy1"{  "8181/tcp": [    {      "HostIp": "127.0.0.1",      "HostPort": "8181"    }  ]}"/alpy2"{  "8182/tcp": [    {      "HostIp": "::",      "HostPort": "8181"    }  ]}

Addendum: As a further improvement, I would suggest that this data parsing should also decide (or output if predetermined) which container/port the host port maps to.

Right now havingHostIp doesn't seem to be useful to the UI for the purposes of accessing applications listening inside the workspace.

Let's say you have two containers, both listening on the same port but on different interfaces:

docker run --name nginx-a -v /path/to/some/html/a:/usr/share/nginx/html:ro -d -p 127.0.0.1:8000:80 nginxdocker run --name nginx-b -v /path/to/some/html/b:/usr/share/nginx/html:ro -d -p [::1]:8000:80 nginx

When I hit the forwarded port in the Coder UI, it hits the container listening on IPv4.
Similarly, when Icurl http://localhost:8000 it also hits the container listening on IPv4. I needed to explicitly specifycurl -6 http://localhost:8000 to hit the container listening on the IPv6 interface.

If I stopped either theipv4 oripv6 container, it would fall back to whichever one was running.

Whether or not the v4 or v6 address is preferred seems to be down to the underlying OS configuration.

That makes sense, thanks for investigating. So ultimately, this confirms we can't with confidence say which container aHostPort belongs to.

I think the best option for us now is to detect that multiple containers have the same host port mapped, and if that's the case, we flag it via additional parameter. Perhaps (simplified)"conflicts": ["container2:9090/tcp"] or something like that? (Likewise container2 should have"conflicts": ["container1:8080/tcp"].)

This would allow us to surface a? in the UI, saying "this could go to either container1 port 8080 or container2 port 9090.

Alternative suggestion: a message to this effect can be dropped intowarnings as a relatively cheap and easy way to surface this situation. I don't think it's going to be that common.

OK, I've added a test case for this scenario and hopefully improved clarity overall.

A little bit of coder inflation in this path 😂

TBH there's probably a lot of "pruning" we can do in those fixtures, but I'd like to avoid changing them if possible :)