Terraform-provider-azurerm: azurerm_cdn_endpoint support for custom domains

Created on 5 Oct 2017  路  48Comments  路  Source: terraform-providers/terraform-provider-azurerm

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

_This issue was originally opened by @iustinam as hashicorp/terraform#16261. It was migrated here as a result of the provider split. The original body of the issue is below._


Hi,
Is there any plan to add support for CDN custom domains? I could not find that in https://github.com/hashicorp/terraform/pull/4759/files
Azure templates have support for that as in:
https://docs.microsoft.com/en-us/azure/templates/microsoft.cdn/profiles/endpoints
https://docs.microsoft.com/en-us/azure/templates/microsoft.cdn/profiles/endpoints/customdomains

Thanks

new-resource serviccdn

Most helpful comment

Any update on this?
I have noticed terraform actually deletes existing custom domain records if we have any update in the CDN itself (like origin url change).
This is the most frustrating since it is not showing it is going to delete it. It just does.

All 48 comments

Just checked - this is now in the SDK so we should be able to proceed with this soon 馃憤

The current documentation reads as if this is possible in the description. Maybe in the immediate, the documentation should be noted that this feature is not yet available.

The CDN Endpoint is exposed using the URL format .azureedge.net by default, but custom domains can also be created.

custom domain support would be most beneficial.

Hey folks! Just to let you know that we鈥檙e planning on taking a look at this this week :)

Note I learned through recent experience with Microsoft's support team that only Verizon_Standard and Verizon_Premium support custom domains. The Akamai_Standard implementation currently doesn't support custom domains.

I learned through experience that much of what I needed to configure for the Verizon_Premium CDN could only be done through the verizon configuration portal and that domain validation required tickets to be bridged from Microsoft to Verizon to execute with an 8hr SLA.

I captured what I experienced here[1] and here[2] and I will follow this thread to hopefully revisit this someday?

1: https://azure.serverlessexample.ga/index.html
2: https://blog.tidalmigrations.com/serverless-on-azure-for-beginners-with-cloudflare-and-terraform-98a746d0f095

Blocked on an Azure API issue - reassigned to future

Is this still an API issue? In the Azure portal you can enable custom domains and they appear very quickly, so it appears automated and not done via 8hr SLAs. Also, in the automation code I can see Standard_Microsoft as a SKU option.

What are the open questions on this? I am aware of limitation by skus, but would it be alright to have the validation check for the sku of the endpoint and use that for the time being to say that the resource gets created.

Additionally I realize that it takes 8 hours, but maybe the SSL enabled function only checks to see that it's not disabled and if it's any other state it's considered a success.

I believe it may just require some additional documentation.

The current documentation reads as if this is possible in the description. Maybe in the immediate, the documentation should be noted that this feature is not yet available.

The CDN Endpoint is exposed using the URL format .azureedge.net by default, but custom domains can also be created.

Could be good idea to remove this from documentation, it took me sometime to find this issue and realize this is not yet possible..

The documentation has been updated in #2425

I had a stab at adding the necessary support for this, only to discover that the Endpoint struct in https://github.com/Azure/azure-sdk-for-go/blob/e924335e24341fbcd625b3241eaa7ec4b8bdbc34/services/cdn/mgmt/2017-10-12/cdn/models.go#L1326 doesn't include the appropriate type for resources. Given the template, https://docs.microsoft.com/en-gb/azure/templates/Microsoft.Cdn/2017-10-12/profiles/endpoints supports this is this an omission on the part of the API?

Hi @imavroukakis , "resources" is not a property of Endpoint. "resources" is a keyword in arm-template that describes the resource you want to create. Check this example. It creates a profile as the main resources, then creates an endpoint as a sub-resource of profile. If you would like to create a custom domain, you can add a "resources" in the endpoint and put this template in it. This will generate multiple API calls to the RP to create each resources specified in the template.

Thanks @hytao , my point was that the Azure Go SDK was missing the necessary constructs to allow for custom domains. It seems that they have now added this (https://github.com/Azure/azure-sdk-for-go/issues/4111#issuecomment-519291360)

Hi all, is there anything else currently blocking the support of custom domains?

Would also like to see this implemented to completely automate the process

Plus one for Terraform support and custom domain.

How are folks doing this programmatically now?

@hammer5280 we dont

I don't see what's blocking this. As imavroukakis mentioned it looks like it's already available in the SDK.

And it's also available in Azure Resource Manager.

{
    "type": "Microsoft.Cdn/profiles/endpoints/customdomains",
    "apiVersion": "2016-04-02",
    "name": "[concat(parameters('storageAccount'), '/', parameters('endpoint'), '/subdomain-mydomain-com')]",
    "dependsOn": [
        "[resourceId('Microsoft.Cdn/profiles/endpoints', parameters('storageAccount'), parameters('endpoint'))]",
        "[resourceId('Microsoft.Cdn/profiles', parameters('storageAccount'))]"
    ],
    "properties": {
        "hostName": "subdomain.mydomain.com"
    }
}

Hi, is there any progress on this element?

Hi!
@tombuildsstuff you seem to have followed this topic since the very beginning, do you know if this feature is planned?
Thank you

Hi all,

Given this issue is not assigned to anyone can we assume its not on the roadmap yet?

Cheers all

@tombuildsstuff If you can give me some indications, I could try to open a PR for this feature.

@AlexandreSi the api version to use is:
https://github.com/Azure/azure-sdk-for-go/tree/master/services/cdn/mgmt/2019-04-15/cdn

The first change to do would be to upgrade the existing CDN resource to that api version:
https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/cdn/resource_arm_cdn_profile.go#L8

Then probably a new resource for azurerm_cdn_endpoint_custom_domain

Note: I'm not sure if you could right acceptance tests for the SSL side of it, the front door ones, just do an http side.

@katbyte @WodansSon could you remove upstream-microsoft from this, I can't see anything blocking this, and I've just called the rest api for it and it worked for me (at least the custom https via keyvault part of it)

Any update on this?
I have noticed terraform actually deletes existing custom domain records if we have any update in the CDN itself (like origin url change).
This is the most frustrating since it is not showing it is going to delete it. It just does.

I've just come across this problem - it is still applicable. Where are the files responsible for that part of the provider? I could try to implement a PR.

@rmaziarka read my second to last comment :)

@rmaziarka I have started to look at implementing this. I have done zero Go so just feeling my way through it. Feel free to hit me up on Twitter if you want to help https://github.com/andymac4182/terraform-provider-azurerm/tree/feat/azurerm_cdn_endpoint_custom_domain

I would love any feedback from the team as well if possible.

I would be interested in having this feature as well and am willing to contribute.

I'm wondering how you would integration test the feature in the first place. Am I missing something and someone can point me into the right direction?

AFAIK when creating the custom domain, we would need to have a "public" CNAME record pointing to the endpoint, right? How would we set that up in an automated way? Especially when running the tests locally...

AFAIK when creating the custom domain, we would need to have a "public" CNAME record pointing to the endpoint, right? How would we set that up in an automated way? Especially when running the tests locally...

I think it would need to be a separate dns resource to map the endpoint CNAME and cdnverify CNAME to the cdn.

Any idea when this is likely to be released?

Hey guys, I will look into this recently.

@andymac4182 Thank you for your initial work :+1:
Rather than embedding the custom domain subresource into the cdn endpoint resource, I might choose to create a seperate resource for custom domain, as it better fits the rest API.

@timja Thank you for providing the document links above :+1:
Also I agree that for the HTTPS support, it might be hard/inappropriate to implement in terraform as there is manual validation involved. Whilst, for the case ~of enabling HTTPs with a CDN managed certificate~ that custom domain is mapped to your CDN endpoint by a CNAME record , which shall be an automatic process. As we can poll the auto approval status, we might be able to implement only that part for HTTPS support.

@confix I suppose the CNAME record has already been supported by azurerm_dns_cname_record.

Thanks for picking this up @magodo I haven't been able to get back to this.

Whilst, for the case of enabling HTTPs with a CDN managed certificate, which shall be an automatic process. As we can poll the auto approval status, we might be able to implement only that part for HTTPS support.

It's the same as frontdoor, as long as your CNAME records are in place or cdnverify record then it can be automatically verified, not just for managed certificates.

_Note: cdnverify doesn't work for all cdn providers._

@magodo Correct me if I am wrong but the issue is not about creating the CNAME record but rather automatically setting up a test/ephemeral domain so that the custom domains endpoint can do the verification.

As far as I remember, there are no such tests for blob storage custom domains (did I probably just miss them?) and that is probably why. The question is whether integration tests can be done and I am just complicating things or the feature cannot be covered by automated tests in the first place.

Anyhow, if I can be of any help implementing the feature, let me know.

@magodo Correct me if I am wrong but the I

As far as I remember, there are no such tests for blob storage custom domains (did I probably just miss them?) and that is probably why. The question is whether integration tests can be done and I am just complicating things or the feature cannot be covered by automated tests in the first place.

There's limited integration tests of the frontdoor resource for ssl for this reason, there's a workaround of setting the custom domain to the frontdoors public domain, but I'm not sure if that will work here.

@confix Maybe we need to implement #4683 first, so that we can have an ephemeral domain during integretion test?

@timja Using the public doman of the cdn endpoint as the hostName in custom domain API will results into error below:

{
    "error": {
        "code": "BadRequest",
        "message": "We couldn't find a DNS record for custom domain that points to endpoint. To map a domain to this endpoint, create a CNAME record with your DNS provider for custom domain that points to endpoint."
    }
}

@confix Another workaround is to prepare a domain name before the test, then pass in the domain name and its corresponding dns zone info (i.e. name, resource group name) as input to the test.

Example: https://gist.github.com/magodo/ced95a6c93f8b7c40d525116ae6bf0ce

Hope this helps.

Any idea when this will be available? Is the PR ready to be integrated? Currently missing this piece in the puzzle. :)

@devployment The PR is blocked by lack of a decent automatical integration test. The reviewers are evaluating the testing methodology used in the PR.

Any chance this will make it to v2.30.0? Or is there an ETA?

Is there really no update on this? I'd assumed I would run into a problem at some point, but not with cdn endpoint support.

Any update would be nice. Running into an issue with this not being supported.

How is this open for 3 years? It's supported by the Azure CLI/SDK for some time now.

Why would I have a CDN and no custom domain?

(sorry for the passive aggressiveness, manual steps always erk me)

All Hail Terraform!

For anyone looking for a workaround that requires everything to be in code/terraform.

You can use FrontDoor as the Frontend with caching and a storage account backend.

Although the terraform resources for FrontDoor are extremely unstable right now. At least they exist.

Another workaround is to use call the following az command in local-exec block. It requires Azure CLI to be installed and configured, though.

az cdn custom-domain create
az cdn custom-domain enable-https

az cdn endpoint validate-custom-domain can be used to check the domain name is free before trying calling az cdn custom-domain create

Was this page helpful?
0 / 5 - 0 ratings