Persist current domain name with azd deploy doesn't keep domain name (again)

[christiannagel]

Output from azd version
azd version 1.18.0 (commit 2c3bc5a)

Describe the bug

Updating an Azure Container App with azd up, removes the domain name.

I've configured the setting as described with #3955, with this setting (azd config list):

{
  "alpha": {
    "aca": {
      "persistDomains": "on"
    },
    "infraSynth": "on"
  },
  "defaults": {
    "location": "westeurope",
    "subscription": "subscription-id"
  },
  "template": {
    "sources": {
      "awesome-azd": {
        "key": "awesome-azd",
        "location": "https://aka.ms/awesome-azd/templates.json",
        "name": "Awesome AZD",
        "type": "awesome-azd"
      }
    }
  }
}

Now, using azd up or azd deploy, deploys a new version of the app, and the domain name is removed.

Maybe it's no longer an alpha setting. I couldn't find documentation on this.

To re-apply the domain name (this might be an issue with Azure Container Apps), adding the domain to the ACA, and re-applying the binding no longer finds the certificate. I need to delete the certificate from the Container App Environment first before I add the domain to the ACA again.

[markuspalme]

Can confirm the issue - running into the same problem.

[JeffreyCA]

Hi @christiannagel, @markuspalme, thanks for reporting this issue.

Are you both deploying Aspire projects and if so, could you share more details about your App Host? Are you using ConfigureCustomDomain to configure custom domains?

To re-apply the domain name (this might be an issue with Azure Container Apps), adding the domain to the ACA, and re-applying the binding no longer finds the certificate. I need to delete the certificate from the Container App Environment first before I add the domain to the ACA again.

Yes this sounds like an ACA issue rather than azd. The workaround involving (az containerapp hostname bind) should work, or you can use the API Playground in Azure portal to send a PATCH request with something like:

Relative path: /subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.App/containerApps/<name>?api-version=<api-version>

Request body:

{
  "properties": {
    "configuration": {
      "ingress": {
        "customDomains": [
          {
            "name": "sub.mydomain.com",
            "certificateId": "/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.App/managedEnvironments/<managed-env-name>/managedCertificates/<managed-cert-name>",
            "bindingType": "SniEnabled"
          },
          {
            "name": "sub2.mydomain.com",
            "certificateId": "/subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.App/managedEnvironments/<managed-env-name>/managedCertificates/<managed-cert-name>",
            "bindingType": "SniEnabled"
          },
          ...
        ]
      }
    }
  }
}

[markuspalme]

@JeffreyCA in my project, Aspire isn't involved. The deployment pipeline sets the alpha.aca.persistDomains option and then provisions the infrastructure. If there is any change detected, the custom domains are gone.

These are the relevant steps in the GitHub action:

      - name: Set Preserve custom domains flag
        run: azd config set alpha.aca.persistDomains on

      - name: Provision Infrastructure
        run: azd provision --no-prompt --environment dev

[JeffreyCA]

@JeffreyCA in my project, Aspire isn't involved. The deployment pipeline sets the alpha.aca.persistDomains option and then provisions the infrastructure. If there is any change detected, the custom domains are gone.

These are the relevant steps in the GitHub action:

      - name: Set Preserve custom domains flag
        run: azd config set alpha.aca.persistDomains on

      - name: Provision Infrastructure
        run: azd provision --no-prompt --environment dev

Thanks for the info. Does your project have an infra folder with IaC? If not you can try running azd infra gen. I'm wondering how the container app defined, and how the customDomains param is being set.

If using Bicep AVM, it might look like:

module aca 'br/public:avm/res/app/container-app:0.18.1' = {
  params: {
    ...
    customDomains: [
      {
        name: customDomain
        certificateId: managedCertId
        bindingType: 'SniEnabled'
      }
    ]
}

or if using the native Bicep resource:

resource aca 'Microsoft.App/containerApps@2025-01-01' = {
  ...
  properties: {
    configuration: {
      ingress: {
        ...
        customDomains: [
          {
            name: customDomain
            certificateId: managedCertId
            bindingType: 'SniEnabled'
          }
        ]
      }

[christiannagel]

@JeffreyCA In my .NET Aspire project, I didn't use ConfigureCustomDomain yet. I haven't used PublishAsAzureContainerApp with this project yet. I'll update my projects for this new way.

With this project, I'm publishing from the client.

azd config show shows "persistDomains": "on":

{
  "alpha": {
    "aca": {
      "persistDomains": "on"
    },
    "infraSynth": "on"
  },

The bicep script doesn't include the customDomains section.

I've been successful in re-applying the certificate with the az containerpp hostname bind command, but not from the portal.

[JeffreyCA]

So alpha.aca.persistDomains only has an effect:

1. You have an Aspire project
2. On azd deploy (not azd provision)
3. You're not using PublishAsAzureContainerApp or AddAzureContainerAppEnvironment in the App Host

If you're not using PublishAsAzureContainerApp/AddAzureContainerAppEnvironment, your ACA custom domain config can get deleted in several scenarios:

1. On azd deploy and you don't have alpha.aca.persistDomains enabled
2. On azd provision (or azd up) and the provisioning state has changed
3. On azd provision --no-state

@vhvb1989 can you confirm, is the guidance to have users use PublishAsAzureContainerApp with ConfigureCustomDomain if they want to configure and persist custom domains on their container app? And any other thoughts here?

If you are using PublishAsAzureContainerApp with ConfigureCustomDomain, your custom domain config can get deleted if:

1. certificateName parameter wasn't set properly per the documentation after configuring in Azure portal:

   When deploying with custom domains configured for the first time leave the certificateName parameter empty (when prompted by the Azure Developer CLI). Once the application is deployed successfully access to the Azure Portal to bind the custom domain to a managed SSL certificate. Once the certificate is successfully provisioned, subsequent deployments of the application can use this certificate name when the certificateName is prompted.

[vhvb1989]

That's correct.

@christiannagel , Aspire projects not using AddAzureContainerAppEnvironment will be deprecated. AddAzureContainerAppEnvironment was recently introduced for Aspire 9.4 and the expectation is for users to migrate their projects (if you are deploying to Azure) to this. See: dotnet/docs-aspire#3669

Azd will start displaying a deprecation warning soon when deploying Aspire projects if you are not using AddAzureContainerAppEnvironment (see: #5277)

I will mark this issue as resolved for now.

[microsoft-github-policy-service]

Hi @@christiannagel. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[christiannagel]

@vhvb1989 thanks for your answer! Just a short follow-up question: AddAzureContainerAppEnvironment, the name parameter needs to match the environment created with azd env? What's the best practice to configure different environments with the AppHost for the azd env mapping - using configurations in addition to Debug|Release, such as Test|Staging|Production where different or no domain names are configured, or suppling configuration values to the AppHost, and deciding the infrastructure on these?