Open arkiaconsulting opened 5 years ago
@arkiaconsulting,
It's a great suggestion indeed! My understanding is that specific reference is only applicable for Azure App Services/Azure Functions. Nevertheless, we should work with these respective teams to help App Configuration feel native across Azure.
We just announced the Key Vault Reference feature in App Configuration. Please open new issues if you have any feedback. https://github.com/Azure/AppConfiguration-Announcements/issues/1
Hi, This is a « must have » feature ! Without references link for app services, it’s useless at this time. We really love to have it as feature.
Thanks, Alex
Hello! Do you guys have any news on providing this feature? Thanks!
We've been in conversation with the App Service/Azure Functions team but looks like this was not able to be scheduled within this year. We will keep trying to get this into their future planning.
cc: @lisaguthrie @AlexandraKemperMS
@adriend-advz I think that with the AppConfiguration nuget, binding your App Service/Function is very easy, removing the need to be able to reference App Configuration items that way. Do you have a special use case ?
@adriend-advz I think that with the AppConfiguration nuget, binding your App Service/Function is very easy, removing the need to be able to reference App Configuration items that way. Do you have a special use case ?
Hi @arkiaconsulting , from Ops side, this is a not acceptable solution that AppService get directly information from a KV or App Configuration. Usually dev team ask a grant for list all settings, and so we can't control which config/secrets especially when KV/AppConfiguration are shared by multiples teams/projects. So, to reference in AppSetting permit to control who and what are consumed from WebApp/FunctionApp, and in more when we deploy infra with IaC (like Terraform) we can know if some configs/secrets are not use anymore and can be delete, without tracking GIT repo for code as C# for people doesn't know some dev language.
In conclusion, AppConfiguration for ops teams without AppSettings referencing is acually useless and we still use AppSettings for configuration. And about Key Vaults secrets, like referencing is possible, we deploy it everytime and everywhere when it's needed. So until we don't have this feature, AppConfiguration will never use in our projets.
Hope that this use case, who is not special, can explain the reason of this must-have feature.
Have a nice day, and remain at your disposal if need further informations Regards Alexandre
Hi! I just have one more question regarding this: I was planning to however use this app configuration task but removing everything related to key vault references to avoid pushing wrong reference. When doing the deployment, it basically wiped all the keys that were not in the properties file. Is there a way to avoid such a behavior? Thanks in advance!
@adriend-advz What app configuration task
are you talking about ?
Hi @arkiaconsulting! My bad, I was referring to the release pipeline task "Azure App Configuration Push".
@Yiming-Jia, can you help @adriend-advz ?
@adriend-advz the issue you described is tracked in #398 (or open a new issue if it's different). Let's not mix that with the current thread.
@alex-3sr thanks for sharing the feedback.
Found App Configuration just yesterday and was a bit disappointed that it has no app service integration in this way.
OP's example - @Microsoft.AppConfiguration(ConfigurationUri=https://my.azconfig.io/configs/mykey/mylabel)
- would make AppConfiguration much more useful and easier to work with.
But... I'd like to suggest an alternative:
@Microsoft.AppConfiguration(KeyValueUri=https://my.azconfig.io/configs/mykey/mylabel)
@Microsoft.AppConfiguration(FeatureToggleUri=https://my.azconfig.io/features/kyKey/mylabel)
Scratch that, just realised the URI would point to either configs or features.
I'm wondering if recursive resolution might be possible for this, also? So if my App Configuration reference was to return a key vault reference, if that could then be resolved to the keyvault item value as normal:
Web App configuration reference
@Microsoft.AppConfiguration(ConfigurationUri=https://my.azconfig.io/configs/mykey/mylabel)
App Configuration item value:
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931)
This could also resolve App Configuration Key Vault references automatically, too. Although I cannot work out how to deploy these via ARM template so have just been storing the URI reference to key vault items, instead.
For anyone who is interested in this feature, it will be helpful for the App Service team to prioritize the work if you can upvote the request below. Thanks!
For anyone who is interested in this feature, it will be helpful for the App Service team to prioritize the work if you can upvote the request below. Thanks!
Hi, There was already a feedback for this : https://feedback.azure.com/forums/920545-azure-app-configuration/suggestions/39505483-app-config-reference
Hi all,
Sorry to bump a thread, I usually never do that .. but I'm still exciting to wait this feature ^^
Have a nice day to all Regards Alexandre
Thanks for the query @alex-3sr. It may take some time, but we started working on this together with the App Service team now.
This feature is critical for properly implementing 12factor app design, which mandates that configuration be provided as orthogonal environment variables. We have multiple Azure app services with dozens of settings each and we cannot use App Configuration because those apps are configured to get all their configuration from environment variables.
What would this mean for injection of IConfigurationRefresher
checking sentinels etc or the feature flags with the [FeatureGate]
attributes on the controllers?
It'd be separate from that, wouldn't it?
What would this mean for injection of
IConfigurationRefresher
checking sentinels etc or the feature flags with the[FeatureGate]
attributes on the controllers?
If you are using the App Configuration provider library, you won't need this because you can pull configuration and feature flags from App Configuration directly. This integration is useful for applications that don't know (or you don't want it to know) about App Configuration because key-values in App Configuration will be available as environment variables to your applications.
What would this mean for injection of
IConfigurationRefresher
checking sentinels etc or the feature flags with the[FeatureGate]
attributes on the controllers?If you are using the App Configuration provider library, you won't need this because you can pull configuration and feature flags from App Configuration directly. This integration is useful for applications that don't know (or you don't want it to know) about App Configuration because key-values in App Configuration will be available as environment variables to your applications.
Understood @zhenlan, clients who care about these features should still be using the AppConfiguration library. Thanks.
Hi @arkiaconsulting, @alex-3sr, @adriend-advz, @mattboothman, @cpdohert, @PanosKousidis, @BzSpi, @Kittoes0124, and @Azalenski, based on your requests, we have been building the @Microsoft.AppConfiguration Reference in App Service and it is now available in Private Preview! We would love for you to try out this feature and hear your feedback. To get access to the private preview, please fill out this survey: App Config Reference Private Preview Access Survey and we will reach out to you. Note that for any Microsoft private preview, you or your company will need to sign an NDA if you/they have not already done so.
Hello @arkiaconsulting, @alex-3sr, @adriend-advz, @mattboothman, @cpdohert, @PanosKousidis, @BzSpi, @Kittoes0124, and @azalenski, this feature is now in Public Preview. Please let us know if you have any feedback!
Hello @arkiaconsulting, @alex-3sr, @adriend-advz, @mattboothman, @cpdohert, @PanosKousidis, @BzSpi, @Kittoes0124, and @azalenski, this feature is now in Public Preview. Please let us know if you have any feedback!
Hi @avanigupta - where do you want feedback? If here then:
I'm hitting our App Configuration Service (ACS) from an Azure Function using app configuration references. I notice that a request appears to be made to ACS for each app setting individually, ie the config retrieval is not batched into a single call.
I can retrieve all of our app config keyvalues using azure cli eg
az appconfig kv list --key "/ian/api/dev/*" --connectionstring "Endpoint ..."
where "/ian/api/dev/" is the common prefix of all of my app config key names.
Obviously the key names could be completely different with no common prefixing.
But I wonder whether some logic could be built into the "fetch" code that checks for common prefixing and retrieves a whole batch (up to 100 entries?) in a single call. Retrieved keyvalues could then be matched to app settings based on their full keyname.
Would eliminate some of the 429s we're seeing (even in Standard tier).
Thanks!
Thanks for the feedback @ianrandell-sh. This is definitely something we want to add in future.
When a AppService uses a Key Vault Reference and the secret changes, the App Service will be restarted. From this article
If a version is not specified in the reference, then the app will use the latest version that exists in the key vault. When newer versions become available, such as with a rotation event, the app will automatically update and begin using the latest version within 24 hours.
Do changes to AppConfig also trigger restart of an AppService with AppConfig References? If not, is this on the roadmap?
Changes in AppConfig won't be picked up in App Service automatically today. You will have to manually trigger a restart of your App Service for it to pick up the changes. Will an auto refresh within 24 hours, like what's supported in the Key Vault reference, work for you?
@zhenlan Bouncing Yes, automatically restarting - even ~24hrs after changing config - would be useful when changing non-essential config, like log level or APM config.
I'm really looking forward to see it working soon.
What about offering the opportunity to reference App Configuration values the same way we can do with Key Vault References.
Key Vault: @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931)
App Configuration: @Microsoft.AppConfiguration(ConfigurationUri=https://my.azconfig.io/configs/mykey/mylabel)
That way, we can provision those references during provisioning phase, keeping client code agnostic of the environment in which its deployed. This is especially interesting when using Managed Identities.