Open atrauzzi opened 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.
Yes this is container to host networking problems
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:
(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: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.