Azure Storage ports changing despite using ContainerLifetime.Persistent

[MarcinJuraszek]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We're using Azure Storage with Emulator and configure it to stay alive between runs using c.WithLifetime(ContainerLifetime.Persistent). Despite that, every time we re-run the AppHost the ports the Emulator is exposing for the app change. This is unexpected and makes things harder than they should be. E.g. we're also using Durable Functions in our project, and use Durable Functions Monitor in VS Code to inspect the inner workings of Durable Task Framework. However, because the ports for the Storage change on every run, the Monitor breaks and we have to re-add a new connection, after getting the new set of ports from Aspire Dashboard.

Expected Behavior

I would expect the Azure Storage connection string exposed by the emulator to stay stable between re-runs of App Host if configured with WithLifetime(ContainerLifetime.Persistent)

Steps To Reproduce

1. Create an App Host with an Azure Storage resource, configure it to use an emulator and set to be persistent between runs:

var storage = builder.AddAzureStorage("storage")
    .RunAsEmulator(c =>
    {
        c.WithDataVolume();
        c.WithLifetime(ContainerLifetime.Persistent);
    });

2. Run the App Host, take note of the Endpoint URLs displayed in the dashboard
3. Stop and re-start the App Host, compare the new Endpoint URLs to the one from previous run

Exceptions (if any)

No response

.NET Version info

No response

Anything else?

No response

[dbreshears]

Let's update to use proxyless for persistent containers.

[davidfowl]

I can't reproduce this on main, @MarcinJuraszek can you use a daily build and see if you can reproduce it https://github.com/dotnet/aspire/blob/main/docs/using-latest-daily.md?

[sebastienros]

Let's update to use proxyless for persistent containers.

I confirm the issue described here is that we get random exposed ports for each run:

Not sure if that is possible, but I'd like to see if we could persist the ones we got and then reuse them on a new run.

[sebastienros]

This problem applies to all containers. The solution for the foreseeable future is to use the new API introduced in this PR which can disable endpoint proxying. The direct effect is that the "Target Port" of an endpoint will be the one exposed directly by the container, so it will be stable. The risk is that there could be conflicts with other services, and that you can't run two instances of the same container with this mode. This is until some down-level work is done in ServiceSpec from DCP to allow for this scenario (probably 10.0 timeframe).

Note that the ports can be defined in the application host using WithQueuePort/WithTablePort/WithBlobPort.

[sebastienros]

Sample usage:

var builder = DistributedApplication.CreateBuilder(args);

var storage = builder.AddAzureStorage("storage").RunAsEmulator(container =>
{
#pragma warning disable ASPIREPROXYENDPOINTS001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
    container.WithDataBindMount().WithEndpointProxySupport(false);
#pragma warning restore ASPIREPROXYENDPOINTS001 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
});

[danmoseley]

@sebastienros @karolz-ms it seems from above this 9.1 issue should either be closed or moved to 10.0 to track "until some down-level work is done in ServiceSpec from DCP "?

[karolz-ms]

@danmoseley agreed. I will let you/@sebastienros do the move. The underlying issue #7046 spans app model and DCP and is really more of an intersection between the two.

[sebastienros]

@danmoseley I marked it as blocked for this reason, not the best approach but I was not sure about the decision. I am ok with closing it if @MarcinJuraszek acknowledges the recommendation works

[dotnet-policy-service]

This submission has been automatically marked as stale because it has been marked as requiring author action but has not had any activity for 14 days.
It will be closed if no further activity occurs within 7 days of this comment.