dotnet
Register a custom container host bind entry for Aspire containers
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
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.
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).
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.
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.
I've been thinking about this some more -- in relation to this: https://github.com/dotnet/aspire/issues/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.
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.
Would love love love to see full reverse proxying be built into aspire. I see it as somewhat mandatory to complete the experience. You can't properly test things like CORS during development without real-like domain names and HTTPS.
The icing on the cake would be running some kind of built in DNS that I could then configure as an upstream DNS on my machine. Easier to do on Linux as dnsmasq is within reach. Windows might take a little more strain, but I'm sure you have people you can speak to for help :wink:
Would love love love to see full reverse proxying be built into aspire. I see it as somewhat mandatory to complete the experience. You can't properly test things like CORS during development without real-like domain names and HTTPS.
The icing on the cake would be running some kind of built in DNS that I could then configure as an upstream DNS on my machine. Easier to do on Linux as dnsmasq is within reach. Windows might take a little more strain, but I'm sure you have people you can speak to for help 😉
We have to be a little careful about things that require DNS configuration changes on the workstation as developers sometimes work in environments where that isn't possible.
@mitchdenny - Yeah, I #dayjob in an environment exactly like that, or at least it'll be many discussions and tickets before it happens :sweat_smile:
I might be having a brain fart, but I can't really think of any good way to test CORS scenarios in-browser without somehow getting a good DNS setup going...?
There's a whole clown car full of same-origin, cookie, CORS, etc... related surprises waiting for Aspire devs right now. It's all school of hard knocks stuff, but the smoother the experience can be, the more "deploy to test" the tool can help people avoid inducing.
To be fair those issues always have existed. We just haven't plastered over them yet ;)
Would love love love to see full reverse proxying be built into aspire. I see it as somewhat mandatory to complete the experience. You can't properly test things like CORS during development without real-like domain names and HTTPS. The icing on the cake would be running some kind of built in DNS that I could then configure as an upstream DNS on my machine. Easier to do on Linux as dnsmasq is within reach. Windows might take a little more strain, but I'm sure you have people you can speak to for help 😉
We have to be a little careful about things that require DNS configuration changes on the workstation as developers sometimes work in environments where that isn't possible.
@mitchdenny @atrauzzi Take a look at #5508
