Resolve the correct container runtime and chose appropriate host name

[thangchung]

When I tried to run AddPostgres with WithPgAdmin as well as AddRedis with WithRedisCommander, nothing worked on Podman native.

I struggled to find the root cause and finally found the problem when I ran:

> podman ps
> podman exec -it <pg admin container id> sh
> cat servers.json
{"Servers":{"1":{"Name":"postgreSQL","Group":"Aspire instances","Host":"host.docker.internal","Port":5432,"Username":"postgres","SSLMode":"prefer","MaintenanceDB":"postgres","PasswordExecCommand":"echo \u0027<password>\u0027"}}} 

Look at the Host, it still pointed to host.docker.internal although I run on Podman. And the same thing happened to Redis with RedisCommander And I think this is a bug.

OS: Windows 11
.NET 8.0.200
.NET Aspire version: 8.0.0-preview.4.24127.7+2cbacd4bf15147d0ce67e915f6932bffb3f7e720
Podman version: 4.9.0

/cc @davidfowl

[davidfowl]

@danegsta Is there a way to query the container runtime from dcp?

Seems like we should be using host.containers.internal for podman. We have a configurated based override in other places but it seems like these are hardcoded:

aspire/src/Aspire.Hosting/Redis/RedisCommanderConfigWriterHook.cs

Line 34 in 184b129

var hostString = $"{(hostsVariableBuilder.Length > 0 ? "," : string.Empty)}{redisInstance.Name}:host.docker.internal:{redisInstance.PrimaryEndpoint.Port}:0";

aspire/src/Aspire.Hosting/MySql/PhpMyAdminConfigWriterHook.cs

Line 37 in 184b129

context.EnvironmentVariables.Add("PMA_HOST", $"host.docker.internal:{endpoint.Port}");

aspire/src/Aspire.Hosting/Postgres/PgAdminConfigWriterHook.cs

Line 38 in 184b129

writer.WriteString("Host", "host.docker.internal");

aspire/src/Aspire.Hosting/MongoDB/MongoDBBuilderExtensions.cs

Line 78 in 184b129

context.EnvironmentVariables.Add("ME_CONFIG_MONGODB_URL", $"mongodb://host.docker.internal:{resource.PrimaryEndpoint.Port}/?directConnection=true");

[DamianEdwards]

We'll need this exposed in the app model during lifecycle callbacks to allow other resources to do this too.

[karolz-ms]

@davidfowl we have this thing called DcpDependencyCheck that is run as part of DcpHostService startup. It gathers the information about container runtime. I am not sure if the result of the check is readily available to the callbacks, but it should be pretty easy to make it available.

[karolz-ms]

IDcpDependencyCheckService is already part of the DistributedApplicationBuilder https://github.com/dotnet/aspire/blob/main/src/Aspire.Hosting/DistributedApplicationBuilder.cs#L95

[davidfowl]

It’s not currently not those callbacks run a bit too early today. If we have the information then we can figure out how to make it work.

[danegsta]

We do provide the identified runtime from DCP as part of those dependency checks, but something to consider is that there are ways to bind a custom local machine address in a container if we wanted to make this work consistently across runtimes.

[davidfowl]

I'm going to do a cheap fix for preview 4 to make this configurable. We have this same problem in other parts of the stack but it's centralized. I'm going to make this use the same logic. In preview 5, we can make it more automatic based on the container runtime.

[davidfowl]

PR is up. It will still require manual work for preview4, we'll make it more automagic in p5.

[davidfowl]

We do provide the identified runtime from DCP as part of those dependency checks, but something to consider is that there are ways to bind a custom local machine address in a container if we wanted to make this work consistently across runtimes.

Lets' chat about doing this @danegsta

[karolz-ms]

I am a little surprised that host.docker.internal did not work with Podman. These PRs should have enabled it, if I understand things correctly: containers/common#1592 and containers/common#1549

[davidfowl]

@karolz-ms that PR adds host.containers.internal it seems.