Tag: cdn

Front Door with WordPress on Azure App Service

Here’s a quick overview of the steps you need to take to put Front Door in front of an Azure Web App. In this case, the web app runs a WordPress site.

Step 1: DNS

Suppose you deployed the Web App and its name is gebawptest.azurewebsites.net and you want to reach the site via wp.baeke.info. Traffic will flow like this:

user types wp.baeke.info ---CNAME to xyz.azurefd.net--> Front Door --- connects to gebawptest.azurewebsites.net using wp.baeke.info host header

It’s clear that later, in Front Door, you will have to specify the host header (wp.baeke.info in this case). More on that later…

If you have worked with Azure Web App before, you probably know you need to configure the host header sent by the browser as a custom domain on the web app. Something like this:

Custom domain in Azure Web App (no https configured – hence the red warning)

In this case, we do not want to resolve wp.baeke.info to the web app but to Front Door. To make the custom domain assignment work (because the web app will verify the custom name), add the following TXT record to DNS:

TXT awverify.wp gebawptest.azurewebsites.net

For example in CloudFlare:

awverify txt record in CloudFlare DNS

With the above TXT record, I could easily add wp.baeke.info as a custom domain to the gebawptest.azurewebsites.net web app.

Note: wp.baeke.info is a CNAME to your Front Door domain (see below)

Step 2: Front Door

My Front Door designer looks like this:

Front Door designer

When you create a Front Door, you need to give it a name. In my case that is gebafd.azurefd.net. With wp.baeke.info as a CNAME for gebafd.azurefd.net, you can easily add wp.baeke.info as an additional Frontend host.

The backend pool is the Azure Web App. It’s configured as follows:

Front Door backend host (only one in the pool); could also have used the Azure App Service backend type

You should connect to the web app using its original name but send wp.baeke.info as the host header. This allows Front Door to connect to the web app correctly.

The last part of the Front Door config is a simple rule that connects the frontend wp.baeke.info to the backend pool using HTTP only.

Step 3: WordPress config

With the default Azure WordPress templates, you do not need to modify anything because wp-config.php contains the following settings:

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/');                                                        define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/');

If you want, you can change this to:

define('WP_SITEURL', 'http://wp.baeke.info/' );                                                                         define('WP_HOME', 'http://wp.baeke.info/');

Step 4: Blocking access from other locations

In general, you want users to only connect to the site via Front Door. To achieve this, add the following access restrictions to the Web App:

Access restrictions to only allow traffic from Front Door and Azure basic infrastructure services

Azure Front Door Revisited

A while ago, I wrote a post about Azure Front Door. In that post, I wrote that http to https redirection was not possible. With Azure Front Door being GA, let’s take a look if that is still the case.

In the previous post, I had the following configuration in Front Door Designer:

Azure Front Door Designer

The above configuration exposes a static website hosted in an Azure Storage Acccount (the backend in the backend pool). The custom domain deploy.baeke.info maps to geba.azurefd.net using a CNAME in my CloudFlare hosted domain. The routing rule routeall maps all requests to the backend.

The above configuration does not, however, redirect http://deploy.baeke.info to https://deploy.baeke.info which is clearly not what we want. In order to achieve that goal, the routing rules can be changed. A redirect routing rule looks as follows:

Redirect routing rule (Replace destination host was not required)

The routall rule looks like this:

Routing rule

The routing rule simply routes https://deploy.baeke.info to the azdeploy backend pool which only contains the single static website hosted in a storage account.

The full config looks like this:

Full config in Front Door designer

Although not very useful for this static website, I also added WAF (Web Application Firewall) rules to Azure Front Door. In the Azure Portal, just search for WAF and add a policy. I added a default policy and associated it with this Azure Front Door website:

WAF rules associated with the Azure Front Door frontend

If required, you can enable/disable WAF rules:

Azure Front Door in front of a static website

In the previous post, I wrote about hosting a simple static website on an Azure Storage Account. To enable a custom URL such as https://blog.baeke.info, you can add Azure CDN. If you use the Verizon Premium tier, you can configure rules such as a http to https redirect rule. This is similar to hosting static sites in an Amazon S3 bucket with Amazon CloudFront although it needs to be said that the http to https redirect is way simpler to configure there.

On Twitter, Karim Vaes reminded me of the Azure Front Door service, which is currently in preview. The tagline of the Azure Front Door service is clear: “scalable and secure entry point for fast delivery of your global applications”.

Azure Front Door Service Preview

The Front Door service is quite advanced and has features like global HTTP load balancing with instant failover, SSL offload, application acceleration and even application firewalling and DDoS protection. The price is lower that the Verizon Premium tier of Azure CDN. Please note that preview pricing is in effect at this moment.

Configuring a Front Door with the portal is very easy with the Front Door Designer. The screenshot below shows the designer for the same website as the previous post but for a different URL:

Front Door Designer

During deployment, you create a name that ends in azurefd.net (here geba.azurefd.net). Afterwards you can add a custom name like deploy.baeke.info in the above example. Similar to the Azure CDN, Front Door will give you a Digicert issued certificate if you enable HTTPS and choose Front Door managed:

Front Door managed SSL certificate

Naturally, the backend pool will refer to the https endpoint of the static website of your Azure Storage Account. I only have one such endpoint, but I could easily add another copy and start load balancing between the two.

In the routing rule, be sure you select the frontend host that matches the custom domain name you set up in the frontend hosts section:

Routing rule

It is still not as easy as in CloudFront to redirect http to https. For my needs, I can allow both http and https to Front Door and redirect in the browser:

if(window.location.href.substr(0,5) !== 'https'){
 window.location.href = window.location.href.replace('http', 'https');
}

Not as clean as I would like it but it does the job for now. I can now access https://deploy.baeke.info via Front Door!

Static site hosting on Azure Storage with a custom domain and TLS

A while ago, I blogged about webhookd. It is an application, written in Go, that can easily convert a folder structure with shell scripts into webhooks. With the help of CertMagic, I modified the application to support Let’s Encrypt certificates. The application is hosted on an Azure Linux VM that uses a managed identity to easily allow scripts that use the Azure CLI to access my Azure subscription.

I also wrote a very simple Vue.js front-end application that can call these webhooks. It’s just an index.html, a 404.html and some CSS. The web page uses Azure AD authentication to an intermediary Azure Function that acts as some sort of proxy to the webhookd server.

Since a few weeks, Azure supports hosting static sites in an Azure Storage Account. Let’s take a look at how simple it is to host your files there and attach a custom DNS name and certificate via Azure CDN.

Enable static content on Storage Account

In your Azure Storage General Purpose v2 account, simply navigate to Static website, enable the feature and type the name of your index and error document:

When you click Save, the endpoint is shown. You will also notice the $web link to the identically named container. You will need to upload your files to that container using the portal, Storage Explorer or even the Azure CLI. With the Azure CLI, you can use this command:

az storage blob upload \
     --container-name mystoragecontainer \
     --name blobName \
     --file ~/path/to/local/file

Custom domain and certificate

It’s great that I can access my site right away, but I want to use https://azdeploy.baeke.info instead of that name. To do that, create a CDN endpoint. In the storage account settings, find the Azure CDN option and create a new CDN profile and endpoint.

Important: in the settings, set the origin hostname to the primary endpoint you were given when you enabled the static website on the storage account

When the profile and endpoint is created, you can open it in the Azure Portal:

In your case, the custom domains list will still be empty at this point. You will have an new endpoint hostname (ending in azureedge.net) that gets its content from the origin hostname. You can browse to the endpoint hostname now as well.

Although the endpoint hostname is a bit better, I want to browse to this website with a custom domain name. Before we enable that, create a CNAME record in your DNS zone that maps to the endpoint hostname. In my case, in my CloudFlare DNS settings, I added a CNAME that maps azdeploy.baeke.info to gebastatic.azureedge.net. When that is finished, click + Custom Domain to add, well, your custom domain.

The only thing left to do is to add a certificate for your custom domain. Although you can add your own certificate, Azure CDN can also provide a certificate and completely automate the certificate management. Just make sure that your created the CNAME correctly and you should be good to go:

Custom certificate via Azure CDN

Above, I enabled the custom domain HTTPS feature and chose CDN Managed. Although it took a while for the certificate to be issued and copied to all points of presence (POPs), the process was flawless. The certificate is issued by Digicert:

Azure CDN certificate issued by Digicert

Some loose ends?

Great! I can now browse to https://azdeploy.baeke.info securely. Sadly, when you choose the Standard Microsoft CDN tier as the content delivery network, http to https redirection is not supported. The error when you browse to the http endpoint is definitely not pretty:

Users will probably think there is an error of some sorts. If you switch the CDN to Verizon Premium, you can create a redirection rule with the rules engine:

Premium Verizon Redirect Rule

When you add the above rule to the rules engine, it takes a few hours before it becomes active. Having to wait that long feels awkward in the age of instant gratification!

Conclusion

Being able to host your static website in Azure Storage greatly simplifies hosting both simple static websites as more advanced single page applications or SPAs. The CDN feature, including its automatic certificate management feature, adds additional flexibility.

%d bloggers like this: