My company has been using static website storage on Azure since it was in beta. We host web forms that need to be updated annually and replaced at the same URL.
We take the following steps setting up a site (mostly in the Azure portal):
1. Create a storage account configured as a static website and upload the static html, js and css files to it.
2. Create a CDN endpoint with an Origin Type of Storage Static Website and a hostname of the static website URL created in step 1
3. Once the endpoint is created and deployed, copy endpoint URL
4. Go to our DNS Zone and add a record set (each of these sites is set up as a subdomain) of type CNAME, using the cdn endpoint URL as the Alias and a TTL of 1 hour. Alias Record Set is set to "no"
5. Go back to the CDN profile I created and add a custom domain, using the subdomain I just created as the custom hostname. Enable CDN managed for that hostname.
After step 5, it takes a few hours for the new URL to be publicly available with https.
This all still works correctly. Where we have been having issues starting just in the past month is in the process for annually updating the sites. Our process requires that we create an entirely new static website and seamlessly cut over to the new files at the same URL. The most recent process we had that worked was this:
Go to the CDN endpoint created in step 2 above and select Origin in the Settings menu
Select the current origin (we always only have one)
In the dialog that comes up, select the new storage account as the origin hostname (in the portal we are shown a drop-down list of our active static site storage accounts in this field).
The "Origin Host Header" field automatically populates with the same URL that was selected as the Origin Hostname.
If we haven't done so already (this is a new requirement as of a year or so ago), I set the priority to 1 and the weight to 1000, because we only have one origin for the endpoint.
Save changes and return to the endpoint overview.
Click the "Purge" button and select "Purge All."
Until a few weeks ago, this functioned perfectly. We would continue to see the old files at the URL until the purge had completed (usually about an hour), at which point we would see the new files. There was no down time.
A few weeks ago, we started to see an error in step 6 (saving changes). When we tried to complete the steps as listed, we see an error message stating that Origin Host Headers can't be used in this configuration. The only way we have found to save the changes is to delete the pre-populated information in the Origin Host Headers field, save changes, and then purge. This so far has worked eventually, but we are experiencing 1-5 hours of downtime on our live site while this change is made. When we attempt to load the site we see a "URI Invalid" message which eventually is replaced by the new files. Since we are doing this for live sites, we need to be able to cut over without downtime. Is there some part of this process that we should be doing differently? The portal documentation is not up to date on the changes that have been made to the process. Thank you for any help.