[Issue] Figure out flow for custom domain names

[pamelafox]

• Make sure you've installed the latest version using instructions in the wiki

Output from azd version

azd version 0.7.0-beta.1 (commit 9ce7165)

Describe the bug

Everything is working as currently designed, so this is more a bug in the process than the code.

I would like to be able to use azd to deploy a website that has a custom domain attached (on Static Web Apps, App Service, or Container Apps). However, if I specify a domain name in Bicep using 'Microsoft.Web/staticSites/customDomains@2022-03-01' that has not yet been verified, then I get an error during the provision stage. I cannot verify a domain name until I know the website endpoint, however, since the DNS record is a CNAME for 'www' with the value of the website endpoint.

This is how I ended up doing it for my personal website, www.pamelafox.org:

1. I set up the infra with domainName as a parameter defaulting to empty string, and only conditionally create the custom domain if the parameter is non-empty:
   https://github.com/pamelafox/pamelafox-site/blob/main/infra/swa.bicep#L24
2. I then run azd up with domainName still empty in main.parameters.json
3. When I see the deployed endpoint URI, I go to my registrar and add a CNAME of www->endpoint
   and wait a few minutes
4. I set domainName in main.parameters.json and re-deploy.

That seemed to work, but it's possible that I also intervened in the Portal in between those steps.
Maybe there'd be a more straightforward approach if I used Azure's registrar? I already have a registrar I pay for, so I set it up there.

[weikanglim]

Not sure if it helps, but I usually think of setting up DNS for an application as two separate steps:

1. Get the app up-and-running with a private endpoint (run provision)
2. At some point when the code is deployed, and everything is healthy, use DNS records to point to the private endpoint. You could choose to use the Azure offering here. It can either be done through the Portal manually, or via a separate bicep deployment to be automated.

I don't think you'd want to set up DNS immediately as part of the app provisioning, until you have everything confirmed working.

[rajeshkamal5050]

We need to provide some guidance around this before GA.

[rajeshkamal5050]

@weikanglim @pamelafox is there any existing Azure documentation which already exists which we can point to as part of Azd FAQ?

cc @savannahostrowski @ellismg

[savannahostrowski]

I managed to setup a custom domain via Bicep for an ACA template but it's not perfect and it's also a bit of a chicken and an egg problem.

I have my certificate as a managed certificate in the Container App Environment (added after first provision). Then I just use the certificateId as part of the customDomain ingress property in the Container App. It's probably harmless but less than ideal as I'd rather have no one know anything about my deployments but I hardcoded the managed certificate name. This was just the simplest thing I could think of.

So at the end of the day, the UX flow for someone consuming this template would be:

• Comment out the custom domain and managed certificate resource bits for first provision
• Add a cert as a managed certificate in the CAE
• Grab certificate name
• Uncomment the custom domain Bicep and pop in the cert name
• Re-provision

https://github.com/savannahostrowski/terminal-personal-site/blob/07e32659fde54dc82ac45acc9544931d33fd0be5/infra/core/host/container-app.bicep#L31

[pamelafox]

It may be possible to do a slightly nicer workflow by using conditions in the Bicep? i.e. customDomain is in parameters.json, only create the resources in the Bicep if customDomain is !empty. Or is there a reason commenting out is necessary vs. Bicep conditionals?

[savannahostrowski]

I'm no Bicep expert so perhaps a conditional statement will suffice! I will investigate this a bit further and circle back!

[weikanglim]

I'd love for the flow to look sequential:

1. Provision infrastructure provision
2. Provision domain names provision public-dns

But if we find the single IaC easier to reason about, that'd be fine too.

From an advanced IaC authoring perspective, creating bicep conditionals based on Azure state may make it harder to test and maintain over time.