I have a bicep template that creates several container apps. They shall have a custom sub domain in my private DNS zone. However, I have the problem that this leads to a circular dependency: To add the CName and verification TXT record to the DNS zone, I need the FQDN and verification from the container app. On the other hand, the deployment of the container app validates the existance of these records and fails if they are not there.
A workaround I currently use involves a boolean template parameter that must be false on the first run:
param register_custom_domains bool = false
resource container_app 'Microsoft.App/containerapps@2022-03-01' = {
// ...
properties: {
configuration: {
ingress: {
customDomains: register_custom_domains ? [
{
name: 'name'
certificateId: certifcate.id
bindingType: 'SniEnabled'
}
] : null
}
}
}
}
But this naturally requires to deploy twice. Is there a better way?
2
Answers
There is a solution that works in one pass. It is based on the fact that the verification string is the same for the container app environment and the individual containers. And since the containers will get an default domain name that is composed of the container name and the container environments defaultDomain, the CNAME and TXT records can be created before the containers.
Here is a step-by-step description to register the container app named
my_container
assubdomain.my-domain.com
:I will tell you how I have it configured which may help you.
I have a container app environment which has a custom DNS suffix of "apps.example.com" (not really, use your own here 🙂 and I’ve got a Let’s Encrypt TLS certificate for "*.apps.example.com"
You will need to configure your DNS for
This still needs to be done two stage unfortunately – but this is only once, ever.
Then I deploy my container apps into this container app environment and they get the above custom suffix, so instead of some wild random name it will have the one you give it, and also you don’t need to sort out DNS or certificates on a per-app basis as they all pick up the wildcard.
So if I deploy the Microsoft Quickstart example site "my-container-app" then it appears as my-container-app.apps.example.com, fully secured with my Let’s Encrypt wildcard certificate.
I actually have three environments, dev.example.com, test.example.com and apps.example.com so we can progress through our pipeline on independent environments keeping the container app name consistent. Three Let’s Encrypt certificates cost the same as one 🙂
Hope that helps.