Your website or webapp often requires static content (e.g. images, files) to fully function as intended. Hosting these files within your app-directory is fine up to a point, but as your storage needs grows, it will soon become unmanageable. Transitioning to a Content Delivery Network (CDN) can be the solution you need to combat storage and performance issues. Especially webapps using a lot of dynamic content, like this blog, can benefit from separating the file storage from its app instance.
This article will explain how to quickly get started using Azure Storage and the Azure Content Delivery Network for hosting your files, and how to interact with your Azure Storage account from your webapp.
Retrieving static images and other static files for your webapp is most efficiently done by reaching your file via a URL. This way your browser (and infrastructure) can optimize the delivery process by caching the files and resources. Our goal for this article is to set up Azure Storage and Azure CDN so you can retrieve your files via a URL with your own custom domain. From your webapp you can then simply load your images and files via HTML-tags like <img src=”https://static.mydomain.com/image1.jpg”>. I will not go in to other ways of retrieving files from storage, like using byte streams, in this article.
In order to get to the point where we can simply use HTML links to get to our files, we need to do a couple of things.
- We need to create an Azure Storage account and configure it
- We need to create an Azure Content Delivery Network endpoint and configure it
- We need to be able to upload files to files to our Azure Storage account from our webapp
Before we get started, make sure you have full access to your Azure account and to your domain’s DNS settings.
Creating and Configuring Your Azure Storage Account for File Hosting
In order to use files for file hosting, we need to create an Azure Storage Account, configure a custom domain, and configure the access rights so our files can be accessed via HTTP.
Creating the storage account is rather basic, as we can use the default settings when creating the account. We choose Standard performance and General Purpose storage, and for Replication we can select LRS or higher depending on your needs. Pricing will increase the more advanced the replication-level you select. Initially, we need to set ‘Secure transfer required) (under Advanced-settings) to Disabled as we first want to test basic connectivity without configuring certificates.
When our Storage Account is successfully deployed, we can first manually upload a file for testing purposes. Go to Blobs and create a new container. For example, we name our container ‘images’ and we set our Public access level to ‘Blob (anonymous read access for blobs only)’. This way we can access your files from outside of our Azure account.
Click on the container and select Upload on the toolbar, upload a sample image for testing purposes of your liking.
We now have your test file uploaded, and we are ready to test if we can retrieve the file from our website. All we need to do is find the endpoint URL for our Storage Account, and test access using our browser. You can find your Storage Account URL under de Properties tab and look for ‘PRIMARY BLOB SERVICE ENDPOINT’. It is generally the name of your account followed by a Microsoft domain.
In my demo scenario it looks like this:
The containers we create, like the ‘images’-container we created previously, are accessed via a subfolder structure in the URL. In our case we can test the access of our file by combining our storage endpoint with our container name and file name, resulting in.
If you try to access the URL from your browser, you should be able to successfully load the file. If not, make sure your URL is correct and you do not have your container-settings set to Private.
We now have our account created, a file uploaded and access set, all that is left is to configure our custom domain. If you don’t have your own domain or are fine using the default storage URL endpoint, you can skip this step.
To configure your custom domain we simply go to the Custom Domain-tab and follow the instructions on the page. As this is sometimes a struggle to get working, I found the next tips to be helpful:
- Set the TTL (Time To Live) of your DNS records to the lowest possible, this will propagate your new settings the fastest
- Try both verification options in parallel
- Give the system time to propagate your changes, even if you set your DNS TTL to 1 minute, give it an hour if things don’t work out initially
- Create a subdomain for hosting your static files, for instance use static.mydomain.com or files.mydomain.com for your custom domain
When your custom domain is successfully configured, you can test the accessibility of your file via the browser again, but now using your custom domain. Don’t forget to still use the folder structure in your URL, so use http://files.mydomain.com/images/file.png to test.
As you may have noticed, HTTPS is not working with Azure Storage Accounts and Custom Domains. This is not a configuration issue, but Azure Storage does not support HTTPS for Azure Storage Accounts at the time of writing (unless you are willing to accept not using custom domains). When testing your file accessibility at this stage you must use HTTP and not HTTPS. This comes back to the initial creation of the Storage Account where we set Secure transfer required to Disabled. This allows us to test the accessibility without HTTPS.
If your webapp or website is using HTTPS you will be forced to use HTTPS for your external resources because your browser will otherwise not grant your website the ‘secure’ seal and will warn the user the website is not fully secure.
In order to use Azure Storage with HTTPS and custom domains you must linked your Azure Storage account to an Azure Content Delivery Network Endpoint.
Creating and Configuring Your Azure Content Delivery Network Endpoint with A Custom Domain
Creating and configuring your Azure CDN endpoint is straightforward. Using the ‘Azure CDN’-tab on the Storage Account blade as shown below, can you create a new CDN endpoint using the default settings.
After successful deployment of your new CDN endpoint, you can migrate your custom domains from your storage account to your CDN endpoint.
The last step is to configure the HTTPS certificate for your CDN endpoint with custom domain. You can choose to upload your own certificate, or use Azure’s certificate service, which is quite pricey compared to providing your own certificate.
Uploading your own certificate does require you to create a Key Vault Entry but this is well documented in the Azure Documentation. You can enable and configure HTTPS for CDN custom domains under the CDN Profiles blade, selecting your endpoint, Custom Domains and then selecting your domain. Finally switch ‘Custom domain HTTPS’ to On and configure the certificate.
For your CDN endpoint the default settings should be fine, make sure that both HTTP and HTTPS are enabled.
You can again simply test if everything functions properly by trying to access your uploaded file via the browser and using your custom domain and HTTPS.
Upload Files to Your Azure Storage Account from Your WebApp
Uploading files to your Azure Storage and CDN can be done manually or via code. Uploading files manually is an easy way to quickly manage your storage when your files do not change frequently. You can manage your files via the Azure Portal, as we used in the beginning of this article, or by using the Azure Storage Explorer.
If you want to upload and manage files via code, if you want to allow your users to upload files for instance, you can do so via the Azure API’s. Azure has several client libraries that connect to Azure’s Storage REST API. For connecting to Azure Storage from a .NET application, you can use the WindowsAzure.Storage package as described on Azure Storage APIs for .NET.
If it turns out that Azure Storage and Azure CDN does not meet your needs, you can always opt to use other services. Alternatives to Azure Storage and CDN as a single solution are for example FileStack and Google Cloud Platform CDN.