Open eerhardt opened 7 months ago
I think most customers use it via https://www.nuget.org/packages/Microsoft.Extensions.Configuration.AzureAppConfiguration which might make more sense for Aspire
I think we should do this in preview4.
Scope creeeeeeeeeep 😉
Good thing I creeped the scope in preview1 when I snuck in the resource 😉.
Moving to preview5 as this isn't blocking preview4.
We deploy our app config settings through terraform and are considering to move it to argocd. We are anxious to learn what the aspire model will bring to the table in terms of simplicafion or consolidation. At least we strive to make our pods environment variable free. The only dependency ideally is the app config service; connected through workload identity. Supporting sentinel based reloading of settings.
Looking forward to this being added.
We are looking forward for this as well!
Aspire.Hosting.Azure.AppConfiguration is available in 8.0.0-preview.6.23214.1
I'm trying out Aspire.Hosting.Azure.AppConfiguration and running into an issue that may or may not be by-design.
I've got something like the following in my App Host:
var azureWebUiConfig = builder.ExecutionContext.IsPublishMode
? builder.AddAzureAppConfiguration(ResourceNames.AzureAppConfiguration.WebUi)
: builder.AddConnectionString(ResourceNames.AzureAppConfiguration.WebUi);
And the following in my app:
var connectionString = builder.Configuration.GetConnectionString(ResourceNames.AzureAppConfiguration.WebUi);
builder.Configuration.AddAzureAppConfiguration(connectionString);
This works at dev time, but at run time in Azure, the application fails to start. This is because the connection string is not an App Config connection string, it's only the endpoint URI. This can be seen by inspecting the secrets for the container.
Edit: Something like the following seems to work. Would still love to know if this is by-design or if there's a better solution or pattern for dealing with this:
var connectionString = builder.Configuration.GetConnectionString(ResourceNames.AzureAppConfiguration.WebApi);
if (connectionString!.StartsWith("Endpoint=", StringComparison.Ordinal))
{
builder.Configuration.AddAzureAppConfiguration(connectionString);
}
else
{
var endpointUri = new Uri(connectionString);
builder.Configuration.AddAzureAppConfiguration(azureAppConfigurationOptions =>
{
azureAppConfigurationOptions.Connect(endpointUri, new DefaultAzureCredential());
});
}
or if there's a better solution or pattern for dealing with this:
This is what a dedicated Aspire Azure App Config component would be doing for you. It would inspect the connection string and decide if it is a real "connection string", or just a URI and should be using a Credential for auth.
Note: The typical way we check is reversed from the above. We try to parse the string into a Uri first. See the following for an example:
Like others, I'll be keen to see an Aspire-friendly client usage for this.
Additionally, can the AddAzureAppConfiguration
in the AzureAppConfigurationExtensions
please allow the SKU to be defined? It is hardcoded to standard
, which overrides the AppConfigurationStore
's default of free
.
We should have an Azure App Configuration component. See https://learn.microsoft.com/azure/azure-app-configuration/quickstart-aspnet-core-app
See https://www.nuget.org/packages/Azure.Data.AppConfiguration
See also https://github.com/dotnet/aspire/pull/574