With* methods don't work with containers

[davidfowl]

I was testing a project converter to container locally and I realized that it doesn't work because we pass the localhost address instead of using the host address (host.docker.internal). Localhost is local to this container so this always blows up.

using Aspire.Hosting.Otlp;
using Aspire.Hosting.Redis;

var builder = DistributedApplication.CreateBuilder(args);

var pubsub = builder.AddRedisContainer("pubsub");

// Projects
//builder.AddProject<RedisPubSub.App.Projects.Publisher>()
//    .WithRedis(pubsub);

//builder.AddProject<RedisPubSub.App.Projects.Subscriber>()
//    .WithRedis(pubsub);

// Project published as containers
builder.AddContainer("publisher", "publisher")
    .WithRedis(pubsub)
    .WithOtlpExporter();

builder.AddContainer("subscriber", "subscriber")
    .WithRedis(pubsub)
    .WithOtlpExporter();

builder.Build().Run();

The easiest fix here would be to always use host.docker.internal instead of localhost for anything that runs in a container. Injecting different environment based on the consumer might be a bit more difficult...

cc @karolz-ms

[mitchdenny]

This is going to be a pain. It appears that host.docker.internal is not enabled by default on Linux hosts. So we would need to add platform specific logic here.

[mitchdenny]

related: moby/moby#40007

[mitchdenny]

@karolz-ms for DCP on Linux we might need to invoke with --add-host=host.docker.internal:host-gateway when spinning up a container with Docker.

[danmoseley]

@adityamandaleeka is @BrennanConroy planning to pick up app model work? David suggests this might be a good one to start with. Preview 2 cc is Tues 12/5

[danmoseley]

We believe DCP work is done.

[karolz-ms]

I do not think so/don't recall us adding this option on DCP side

[davidfowl]

This wasn't the one @danmoseley , it was the command line args for containers 😄

[danmoseley]

argh -- thanks for the correction. don't mind me, just dropping in and causing chaos in the issues

[davidfowl]

Mitigation in place #1203

[davidfowl]

This may end up being the long-term solution since we're going through proxies here. I'm going to close this as resolved for now and we can track another networking support in containers here