-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure Front Door/DNS support #2526
Conversation
…ot necessary to access the deployed container app resource
Co-authored-by: David Fowler <davidfowl@gmail.com>
First off, thanks for the contribution. Aspire is fast moving as we iterated extremely rapidly to try and land on an extensible model for building resources like this. Given where we've landed now, we wouldn't take this PR as is because:
Bicep resources are fine, but we'd rather you iterate on this in a separate nuget until then. |
Thanks for giving it a look! I took a spin through the Azure.Provisioning.* packages this morning and they're quite lightweight at this point and easy to produce as most of the heavy lifting is happening in Azure.ResourceManager.*, so it should be pretty easy to build such a Front Door/DNS package over there first and revisit this to take that dependency. |
Closing this out. The Azure CDK is getting a big revamp soon, these resources won't be in it, but we'll soon have an obvious place to ask for more resources (not in this repository 😄 ) |
@davidfowl do you know where (repository & issue) we could track progress for these resources? |
https://github.com/Azure/azure-sdk-for-net/ This is our issue tracking it #5583 |
This is a first draft of my proposal to add Azure Front Door support with Azure DNS (mostly for DNS verification for custom domain issuance and ingest mapping).
I haven't yet dug into what's necessary to hook this up to the actual provisioning pipeline, but it's complete enough that I can share the basics of it to get the idea across.
The "dns-zone" Bicep template is straightforward - it's just deploying a fresh DNS zone assuming nothing already exists like the rest of the AZD deployment today.
The "frontdoor" Bicep template is a little more convoluted and could use some cleaning up, but the idea is that I've defined an
AzureFrontDoorOptions
type to which the user can specify all manner of configuration options to pass to the Front Door instance (e.g. Standard vs Premium, which protocols to support, support HTTPS redirect, etc.). I like using enums personally to configure values over magic strings, especially since different resources in Azure are so picky about the casing and punctuation used, so I added an extension to simplify using those here.Otherwise, Front Door deployment is straightforward once you get past all the parameters. It starts with a reference to the container app (meaning if this is all dropped into a single file as
synth infra
does today, it'll take a dependency on that automatically), then deploys the various aspects of the Front Door. There's a configuration flag to deploy not just the apex custom domain, but also the "www." subdomain, so from there I add those resources to the Front Door instance, add a reference to the DNS zone and add the A, CName (if spinning up for "www." as well) and TXT records as applicable.Bicep doesn't really have a "wait until" or "continue if this operation completes" mechanism, so some sort of logging line indicating that it might take a few minutes for the DNS validation to complete and the certificate issued might be worth having.
I'm eager to see if this is along the lines of what you had in mind. Please pile in with your thoughts!
This PR was created in light of my request at #2497