Multiple environments guidance

[parched]

We are deploying to ACA using azd and setting AZURE_ENV_NAME to something-prod. We now want another environment something-dev. We tried deploying it to the same subscription, but it failed because some resource names already existed in the prod resource group.

Is it a requirement when using Aspire that each environment goes in its own subscription? We were thinking about doing this anyway for isolation, but I couldn't find any docs that state this is a requirement.

Even if we split prod and dev into separate subscriptions, it would be nice to be able to spin up temporary environments in a single sandbox subscription.

Is there a way to make aspire take the environment name into account when naming resources? If so, shouldn't this be the default?

[davidfowl]

cc @vhvb1989

[vhvb1989]

Using WithAzdResourceNaming() has effect only for the Azure Container Environment (for naming it). It helps when you were not using builder.AddAzureContainerAppEnvironment("production") for your app and then you add it and you don't want to deploy a new instance for your app.

In your case, the name is comming from using var storage = builder.AddAzureStorage("storage-structural-analysis");

It looks like you can override the default name by doing something like:

var storage = builder.AddAzureStorage("storage")
                     .ConfigureInfrastructure((storageAccount) =>
                     {
                        var storageRes = storageAccount.GetProvisionableResources().OfType<StorageAccount>().Single();
                        storageRes.Name = "otherName";
                     });

@mitchdenny @davidfowl , is this actually supported? or does it becomes problematic if you override a resource's name?

[mitchdenny]

It should work fine because I think everywhere we resolve an endpoint we rely on the RP to tell us what it is rather than trying to compute it from what we put in and appending suffixes etc (mostly because that doesn't work across clouds).

[parched]

It looks like you can override the default name by doing something like:

var storage = builder.AddAzureStorage("storage")
                     .ConfigureInfrastructure((storageAccount) =>
                     {
                        var storageRes = storageAccount.GetProvisionableResources().OfType<StorageAccount>().Single();
                        storageRes.Name = "otherName";
                     });

@mitchdenny @davidfowl , is this actually supported? or does it becomes problematic if you override a resource's name?

How would I make it depend on the environment name? Something like
take('storagestructuralanalysis', 8) + take(${uniqueString(resourceGroup().id, 'storagestructuralanalysis')}', 16)

Will there be a fix in Aspire for this?

[parched]

We ended up changing to this

    /// <summary>
    /// Adds Azure Storage with a unique name to allow multiple environments in the same subscription. https://github.com/dotnet/aspire/discussions/12652
    /// </summary>
    public static IResourceBuilder<AzureStorageResource> AddAzureStorageWithUniqueName(
        this IDistributedApplicationBuilder builder,
        string name
    )
    {
#pragma warning disable CA1308 // Azure Storage account names must be lowercase
        var sanitizedName = System.Text.RegularExpressions.Regex.Replace(name, "[^a-zA-Z0-9]", "").ToLowerInvariant();
#pragma warning restore CA1308

        var storagePrefix = sanitizedName.Length > 11 ? sanitizedName[..11] : sanitizedName;
        var uniqueStorageName = BicepFunction.Concat(
            new StringLiteralExpression(storagePrefix),
            BicepFunction.GetUniqueString(BicepFunction.GetResourceGroup().Id, new StringLiteralExpression(name))
        );

        var storage = builder
            .AddAzureStorage(name)
            .ConfigureInfrastructure(storageAccount =>
            {
                var storageRes = storageAccount.GetProvisionableResources().OfType<StorageAccount>().Single();
                storageRes.Name = uniqueStorageName;
            });
        return storage;
    }
    ```

Which solves it for us, but it isn't a great work-around if someone is already relying on a storage account in production.