Feature Request: Label URL should be compatible with custom domain

[dsczltch]

Is your feature request related to a problem? Please describe.
It's currently impossible to execute a request to a labeled revision by using the custom domain. It's only available on the default random generated domain.

Describe the solution you'd like.
Label URL and Revision URL should use custom domain instead of the random generated domain.

Describe alternatives you've considered.
Trying to use the random generated domain provided. Unfortunately, due to the randomness of the domain, we are unable to use it.

Additional context.
Documentation regarding Label URL: https://learn.microsoft.com/en-us/azure/container-apps/revisions#labels

[dsczltch]

Any update on this feature request ?

[cachai2]

Hi @dsczltch, thanks for flagging this. I've added making the label URL compatible with custom domain to our backlog, and we'll evaluate this to see if we get this added.

Can you elaborate a bit on the randomness of the generated domain making it unusable for you with labels? Do you mean the randomness in the generated name of the default domain?

[bgrainger]

We use custom domains and managed certificates to host a container at myapi.example.com. We are using labels for PR builds. When a developer opens a PR, we have a GitHub Actions workflow that:

• Builds a container
• Deploys that container as a new revision (with no traffic)
• Sets the label pr123 (using the PR number)

However, the labeled container is only available at https://myapicontainername---pr123.randomwords-digits.westus2.azurecontainerapps.io/. To work around this, we currently have wildcard DNS point at a private HAProxy instance that reverse proxies pr123.myapi.example.com to myapicontainername---%[var(req.pr_label)].randomwords-digits.westus2.azurecontainerapps.io. I'd love to be able to remove this proxy.

My ideal scenario is that the label is exposed as a subdomain of the custom domain that's already set up, e.g., pr123.myapi.example.com. We would set up wildcard DNS for *.myapi.example.com as a CNAME to the Container App domain, and ACA would provision a managed wildcard TLS certificate for *.myapi.example.com. Incoming requests would be interpreted as a label and routed to the container revision with that label (if one exists), otherwise display the "no container app" error page.

(It might also work to have myapi--pr123.example.com, but that's harder on our end to configure DNS if we also have yourapi--pr234.example.com and thirdapi--pr345.example.com that all have to be CNAMEd to different Container Apps. They can't just be *.example.com.)

[dsczltch]

@cachai2 Hi, at first the random default domain was not available in the terraform output. It is now. However, we are use to provision and deprovision resources automatically, which update the default domain. Many developers use services hosted on container app and are not going to look for a new URL everytime, that's why we configured custom domain.

I think @bgrainger explained very well the use case we all want to use.

[cachai2]

Thanks @bgrainger and @dsczltch for the detailed feedback. This is super helpful in understanding the exact scenario and what you're looking to address. The feature ask makes sense. I'll follow-up with the team to see if we can get this onto the roadmap.

[ahmelsayed]

It might also work to have myapi--pr123.example.com, but that's harder on our end to configure DNS if we also have yourapi--pr234.example.com and thirdapi--pr345.example.com that all have to be CNAMEd to different Container Apps. They can't just be *.example.com.

@bgrainger if I'm understanding this correctly, you should be able to achieve this today. See this doc https://learn.microsoft.com/en-us/azure/container-apps/environment-custom-dns-suffix

Essentially, you can replace the randomwords-digits.westus2.azurecontainerapps.io part with your own custom example.com domain. You just need 1 wildcard DNS record for *.example.com to your environment IP.

Then whenever you create app foo, you can reach it at https://foo.example.com, and if you add a pr123 label then you can reach it at https://foo---pr123.example.com.

[bgrainger]

Thanks for the link to the docs; I hadn't seen that particular one before. Some pain points I foresee from trying that:

1. The current custom subdomain for the Container App is myapi which doesn't match the Container App name of myapicontainername. Not a deal-breaker, but a little bit of unnecessary friction. I'd prefer the exact name from the custom domain to be used.
2. Requires us to provision and regularly update a wildcard certificate. Obviously can be automated (ACME, etc.) but would be nice to have this be built in.
3. Setting up wildcard DNS for *.example.com is a broad requirement and I don't think I could get approval to have all new and mistyped subdomains for my company resolve by default to a (non-existent) Container App.
4. Since there is a single domain suffix per Container App Environment, you're forced to have domain suffixes that reflect internal team structure (if you should have more than one CAE). Currently, I can have team1api.example.com and team2api.example.com that are served from different Container App Environments. But since only one team can claim *.example.com, I'd have to redeploy the apps at, say, team1api.team1.example.com and team2api.team2.example.com (with wildcard domain suffixes that match my internal team structure). I don't want to be forced to use DNS to expose the internal organization of Azure resources.

For companies that already have public DNS highly structured according to internal organizational boundaries, the custom DNS suffix suggestion might work, but in general I don't see it being feasible.