dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.95k stars 485 forks source link

dapr sidecar not visible to container when running via podman #6846

Open atrauzzi opened 2 days ago

atrauzzi commented 2 days ago

Is there an existing issue for this?

Describe the bug

Something doesn't seem right with how Aspire expects dapr sidecars to be visible for containers.

My dapr publisher is unable to reach the sidecar that Aspire configures for me:

io.netty.channel.ConnectTimeoutException: connection timed out: host.containers.internal/169.254.1.2:38047

(this exception means that my extension was working up until the point it tries to reach out over the network)

Expected Behavior

I expect my container to be able to see the dapr sidecar.

Steps To Reproduce

Regardless of whether I use DOTNET_ASPIRE_CONTAINER_RUNTIME=podman, or not, along with the following configuration:

var daprDefaults = new DaprSidecarOptions
{
    RuntimePath = "./resources",
};

builder
    .AddKeycloak("auth", 8080, adminUser, adminPassword)
    .WithDataVolume()
    .WithBindMount("./resources/keycloak-dapr-publisher-0.0.1-all.jar", "/opt/keycloak/providers/keycloak-dapr-publisher-0.0.1-all.jar")
    .WithDaprSidecar(daprDefaults)
;

Exceptions (if any)

No exceptions are reported by Aspire, although in my specific scenario above, the code depending on the dapr sidecar is unable to reach it, and ends up throwing an exception.

I know for a fact that this code works in a manually assembled scenario, so it's not a bug in that code. You can also see that it specifically fails during resolution of the GRPC endpoint that Aspire injects on behalf of the dapr sidecar.

.NET Version info

All 9s!

Anything else?

In this case, I haven't done any network level customization, so Aspire is totally in the drivers seat. But it's still difficult to tell when host.containers.internal is going to work and when it won't.

atrauzzi commented 2 days ago

It didn't get me any different result, but I also tried to manually configure the container:

builder
    .AddContainer("name", "quay.io/keycloak/keycloak")
    // .AddKeycloak("auth", 8080, adminUser, adminPassword)
    // .WithDataVolume()
    .WithEnvironment("KEYCLOAK_ADMIN", adminUser)
    .WithEnvironment("KEYCLOAK_ADMIN_PASSWORD", adminPassword)
    .WithVolume("dapr-demo-keycloak-data", "/opt/keycloak/data/import")
    .WithHttpEndpoint(8080, 8080)
    .WithBindMount("./resources/keycloak-dapr-publisher-0.0.1-all.jar", "/opt/keycloak/providers/keycloak-dapr-publisher-0.0.1-all.jar")
    .WithArgs(["start-dev"])
    .WithDaprSidecar(daprDefaults)
;

It's basically doing exactly what the keycloak Aspire integration is doing, but yeah, no difference.

davidfowl commented 20 hours ago

Yes this is container to host networking problems