[ACA] Persist current custom domain #3955
Conversation
…urrent custom Domains from the existing ACA and use it for creating a new revision
vhvb1989
requested review from
ellismg,
wbreza,
hemarina and
weikanglim
as code owners
There was a problem hiding this comment.
I'm not opposed to us doing something tactical here - but I'm not sure this is it. I'm really nervous about the Read + Merge thing.
If we want to keep this as a targeted thing, behind a feature flag, until we can get this the done the right way, I could be convinced of it, I think, as long as I was sure that long term we would be getting away from this general idea.
But I'd much rather see if we could leverage the metadata feature or somehow and have something in the app host that shows you're doing custom domains.
|
I think we should talk about what the IaC way to do this is. I don’t fully understand what that looks like for custom domains as there are manual steps that need to happen after the first deployment that modify future deployments. Deploy the application |
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSIDocumentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
|
@vhvb1989 I tried this build out and it didn't appear to work. I had a domain setup and working and then I deployed it and it removed the domain. I tried initially via VS, but when it didn't work I set it back up and then tried again via the command-line. |
|
I ran with debug on and where it says it is setting the body before doing the PUT to arm, I can't see the custom domain settings in there. |
|
@ellismg I don't think that you will be able to avoid reading state from the target environment. In order to set a domain you need to provide a managed certificate ID (its a RID). That RID isn't likely to be in the local environment anywhere (particularly in CI deployment scenarios). So at the very least you would need to query for RID for the manged certificate for domains you are publishing just to check that if it exists you don't try to duplicate it (which would lead to a deployment failure). |
|
@mitchdenny , did you run |
|
Yeah I did. I'll go through it again to confirm. |
|
Yeah it definitely isn't working, here is my AZD version: My workflow was as follows:
|
|
Wait ... your instruction above might be incorrect ... should be: (emphasis alpha) |
|
Yep that was it ... hey its working. Ship it! :) |
Keep forgetting about that |
I'm just glad that we've got something working for custom domains. Now we just need to decide whether want to ship it or not? @ellismg I know we want the purity of this working with IaC vs. some special case handling for ACA, but I think this is actually going to be a pretty common requirement. AppService does something similar here from what I can tell. |
|
@ellismg @vhvb1989 we would like to get this feature in for the next release of IF we do end up being able to solve it using Bicep generation from the AppHost (with some further support from AZD around prompting then we can look to remove the alpha feature. |
|
@mitchdenny I'm okay for us to merge this change in to unblock the scenario - but I do think the general strategy of merging existing state from the cloud with the "desired state" from the IaC is going to make stuff tricky for us long term and we need to figure out a way to reflect this in IaC. I'm not sure what any additional properties we're going to want to copy in this way long term (are there others like this that you can't set "all the time" and so even solving it with |
|
We should make sure to document this feature as customers are running into it |
|
@csharpfritz I wanted to make sure you saw this as well! |
* Adding alpha feature `alpha.aca.persistDomains` which would use the current custom Domains from the existing ACA and use it for creating a new revision
|
I'm assuming this:
Can't be implemented from a VS publish profile ? |
|
/cc @ellismg @bradygaster I'm not sure to be honest |
It's a setting for the local installed Bonus points for querying the current value with |
|
@Steinblock ah of course. Nice! |
|
In case it helps, azd also offers this as dynamic configuration via environment variables (useful for CI scenarios):
For this particular example, |
|
With .NET Aspire 9.0 we are introducing the ability to do greater customization on the container app resources. This means that we'll be moving the setting of the custom domain into the app host (where you'll be able to parameterize it). The workflow will still be a little clunky but we are working with the ACA team to see if we can streamline it somewhat. |
|
@mitchdenny Can you link us to some docs or the feature PR so that we can learn how to adapt our existing configuration appropriately? |
|
There are no docs yet. We are still mid milestone working on if we can smooth this out. |
Understood there are no docs.. is there somewhere we can track and follow along with the evolution of this feature? |
|
@csharpfritz here is the latest issue that I'm tracking: My investigation there has led to this PR: |
Adding feature flag:
aca.persistDomainsWhen turned on:
azd config set alpha.aca.persistDomains on, azd will use any existing customDomains from a ACA before deploying an update for it, preventing the deletion of any manually-configured custom domain from the Portal.