Register a custom container host bind entry for Aspire containers

[danegsta]

Rather than depending on host.docker.internal or host.podman.internal (which may not even be present in all containers), Aspire can bind its own custom domain to refer to the local host machine from the container. This change adds a new host.aspire.internal entry to containers created by Aspire and updates our default hostname logic to use that, regardless of the specific container runtime.

I've tested this with Docker Desktop and Podman Desktop and everything continues to work as expected (including host.docker.internal on Docker Desktop and host.containers.internal on Podman). The command being used is supported on docker-ce as well, so this should work for Linux users who wouldn't otherwise have a host.docker.internal entry.

Microsoft Reviewers: Open in CodeFlow

[danegsta]

Inspiration for this came from comments on #4191

[danegsta]

Did a bit of testing with docker-ce on WSL; it looks like in that scenario it has the same issue we've run into with podman, where it can't access ports on the local machine that are bound to 127.0.0.1; it seems that only ports bound to 0.0.0.0 from the local machine are accessible. This does still improve the experience with Docker Desktop/Podman Desktop.

[mitchdenny]

I like the idea of normalizing this for Aspire so we don't have to special-case Podman and Docker Desktop everywhere. I think we need to think about our DNS / networking story all up in the not too distant future.

For example should we ever get to the situation where each app host instance has its own network, or multiple networks to simulate network isolation? If that is the case would we want the host DNS name to be more dynamic (I don't know ... I'm just asking the question).

[danegsta]

For containers, custom Docker networks (not the default bridge network) support some real cool features regarding DNS, since Docker acts as a DNS server for the individual containers. You're able to bind containers to a network and assign them specific DNS that will resolve to the container IP automatically.

For Windows processes, it gets a bit uglier, since DNS is a system level configuration. You either have to register a custom DNS server (which causes network issues on the host if your server isn't running) or you have to elevate to edit the hosts file to add/remove entries.

[davidfowl]

This feels like it should be handled by dcp. Dcp runs the container with the a custom host name and tells aspire what the host name is.

[davidfowl]

But! I see the appeal. Hmmmm

[mitchdenny]

I've been thinking about this some more -- in relation to this: #850

I'm trying to come to grips with what value adding networking support would provide to Aspire, and I keep coming back to name resolution and observability for local development being the most compelling features.

By exerting greater control over the networks (probably something DCP would do TBH) we could make name resolution better -- BUT we could potentially also improve observability.

Right now we spin up proxies in front of containers/services to support things like replicas. But what if that reverse proxy could also feed us information that we can display on the Aspire dashboard - for example you could capture HTTP request payloads for inspection and replay.

[davidfowl]

The proxy we have is a tcp proxy, very low level (bytes). Sure it could feed us data to use but I'm not sure it solves this issue.

[mitchdenny]

Yeah that won't give us much value in terms of diagnosability.