function keys in aca draft #9938
Conversation
github-actions
bot
added
the
area-integrations
dotnet-policy-service
bot
added
the
community-contribution
| /// <summary> | ||
| /// Gets the collection of keys associated with the Azure Functions resource. | ||
| /// </summary> | ||
| public List<AzureFunctionsKey> Keys { get; } = []; |
There was a problem hiding this comment.
Do we want this set of keys to be mutable or is it actually a fixed collection that we initialize once?
There was a problem hiding this comment.
Customers can call resource.PublishWithFunctionKey("MyTrigger") (which I haven't added yet)... so the list needs to be built up as these PublishWith___Key() calls are made. If that can be done all at once at the end, sure... just wasn't sure what pattern to use?
There was a problem hiding this comment.
If we were to take inspiration from the WithRoleAssignments API we would make WithFunctionKey take a list of (AzureFunctionsKeyType Type, string TriggerName). Then we can call WithAnnotation(new AzureFunctionsAnnotation) once in the call with the list of items.
src/Aspire.Hosting.Azure.Functions/AzureFunctionsProjectResourceExtensions.cs
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| return containerApp; | ||
| } | ||
|
|
||
| private static void ProcessFunctionsSecretVolumes(AzureFunctionsAnnotation annotation, AzureResourceInfrastructure infra, ContainerApp app) |
There was a problem hiding this comment.
Parts of this feel generic enough that we can probably plug them into a ProcessSecretVolumes method and take the functions specific volume name and properties?
There was a problem hiding this comment.
yes I agree... but that didn't exist yet and I don't know all the ins-and-outs of volume setups and what may be needed. I only knew the exact parts I needed, and I barely knew that :-)
| /// </summary> | ||
| /// <param name="builder"></param> | ||
| /// <returns></returns> | ||
| public static IResourceBuilder<AzureFunctionsProjectResource> PublishWithAdminKey(this IResourceBuilder<AzureFunctionsProjectResource> builder) |
There was a problem hiding this comment.
Do we anticipate that end-users will need to call this API in their code (or overloads of it that target different key types)?
There was a problem hiding this comment.
this API, not really, no -- I went ahead and made it internal now actually. And my latest commit has the public ones for other key types
The goals with these PublishWith__Key() APIs are:
- By adding an Admin and a "default" Host key automatically, the app is ready-to-run for all scenarios
- Customers can also call
.PublishWithFunctionKey("MyFunction")to add a function-specific key - We will auto-gen the key for you in Aspire to make sure it's an HIS. And make sure it's named and mounted correctly for our secrets repository to read it.
- If you want to edit a key, you do that via ACA secret management.
- You can even manually create them via ACA secret management -- you just have to name them correctly and have them go to the right mounted volume (something we can document)
|
Is there any reason this needs to be a volume and not an env variable? |
|
Can you write a test that generates the bicep so we can see it. |
If I recall... the main reason was b/c Functions already has a |
brettsam
force-pushed
the
brettsam/func_keys
branch
from
81ab656 to
e21fa8b
Compare
Resolves Azure/azure-functions-host#11165