If you have tried to enable SSL for your Azure Web App you know that the steps to do that are:
- Purchase certificate and export it into a PFX file
- Upload PFX file to a resource group that contains your web app
- Bind the web app’s hostnames to the certificate
Out of those steps the step #1 is the most non-obvious. Just by looking through the instructions in this article you can see that the process is complex and error prone.
Recently the Azure team has released an improved support for buying certificates for Azure Web Apps. Now it is possible to purchase a certificate without ever leaving the Azure Portal UI experience. In this blog post I’ll show how easy it is to buy a certificate and enable SSL for a Web App. As an example I will walk through the process of buying a certificate and enabling SSL for my web site http://ruslany.net/ Continue Reading »
ruslany on April 5th 2016 in Other, WAWS
Some time ago I had a blog post describing how to warm up an Azure Web App during deployment slots swap. In that post I explained the sequence of actions that happens during the swap. One important point in that explanation is that if a site has any app settings or connection strings that are marked as “Slot” then during slot swap those settings are read from target (e.g. Production) slot and applied to the site in the staging slot. That causes the restart of the site’s worker process so that those changes take effect and become visible as process environment variable.
The restart of the worker process is OK for the majority of the swaps. But sometimes it would be useful to pause right after the production settings were applied on the staging slot and before the actual swap of host names happens. Recently Azure Web Apps team has released a “Swap with Preview” feature that supports that use case. That feature will give you a chance to verify that the web site in the staging slot works fine with production settings. Also this will allow you to warm up/initialize the site in any way you want. For example you can generate some load on that site so that its cache is completely pre-populated. After you are satisfied with how the site works in staging slot you can complete the swap so that the site is moved to production slot and starts taking on production traffic. The site’s worker process will not be restarted during that step, which means that the worker process in production slot is exactly what you have tested in staging slot.
Note that currently this feature is in Preview meaning that it is ready to be tried but not yet recommended for use with business-critical applications.
To demonstrate how Swap with Preview works I’ve created a site and added a “Slot” setting to it with name “SlotName” and value “Production“. Continue Reading »
ruslany on October 30th 2015 in WAWS
Azure Web App deployment slots are used to help roll out new versions of an app without downtime or cold start activation. New version is typically deployed to a staging slot, then after testing and final verification it gets swapped into a production slot. During the swap operation the Web App’s worker process may get restarted in order for some settings to take effect. Even though the swap does not proceed until the restarted worker process comes back online on every VM instance, it may still not be enough for application to be completely ready to take on production traffic. This post explains how you can use the recently enabled Application Initialization Module to completely warm up your application prior to swapping it into production. Continue Reading »
ruslany on September 30th 2015 in PHP, WAWS
When an Azure Web App makes an outbound network call it uses a set of predefined IP addresses. Usually the Web App developer needs to know those IP addresses in order to configure firewalls of external services to allow requests from that Web App. In the past it was not easy to discover the IP address of a Web App. There is an article with the list of known IP addresses for each Azure scale unit, but that is not updated as fast as the new Azure scale units brought up online.
Fortunately now it is much easier to discover the outbound IP addresses of an Azure Web App. Continue Reading »
ruslany on June 29th 2015 in WAWS
IIS has been supporting reverse proxy configuration since URL Rewrite and Application Request Routing modules were released a few years ago. It is possible to configure an IIS hosted web site to act as a reverse proxy and forward web request to other URL’s based on the incoming request URL path. This is described in details in Reverse Proxy with URL Rewrite v2 and Application Request Routing.
Not too many people know however that the same kind of configuration can be achieved with a web site hosted in Azure Web Sites. This blog post explains the configurations steps to enable that.
For example if I want to forward all the requests that come to http://ruslany.net/proxy/ to some other URL I’ll need to do two things:
- Enable proxy functionality in ARR
- Add a proxy rewrite rule
Continue Reading »
ruslany on May 16th 2014 in URLRewrite, WAWS
Windows Azure Web Sites supports Staged Publishing functionality, which allows you to create a staging site slot where you can publish a new version of the website and then test it before swapping to the production environment. By default the non-production deployment slot has its own hostname that you use to test the bits deployed there. Sometimes, however you may want to prevent users from browsing to your non-production deployment slot while you are testing it.
It is relatively easy to configure your site to block the http request if it is deployed to any non-production slot. For example let’s say I have a site ruslany.azurewebsites.net and I created a deployment slot for it and name the slot as ‘staging‘ (it is possible to give custom names to deployment slots now). The hostname for that deployment slot will be ‘ruslany-staging.azurewebsites.net‘. So to prevent access to the deployment slot from anybody except a few allowed IP addresses I can add the following rewrite rule to my site’s web.config file: Continue Reading »
ruslany on April 24th 2014 in URLRewrite, WAWS
In the beginning of the year Windows Azure Web Sites team has released a preview of the Staged Publishing functionality. The Staged Publishing allows you to create a staging site slot where you can publish a new version of the website and then test it before swapping to the production environment. This feature together with Continuous Deployment via GitHub, BitBucket or DropBox enables some very powerful deployment scenarios.
However the preview release did not provide the optimal experience for enabling Continuous Deployment (CD) for staging site. User had to configure a non-trivial workaround as described in blog post by Rick Rainey. Recently the Azure Web Sites team has released an update that fixes that problem and makes the setup of the CD with staged publishing very simple. This blog post describes how to enable CD from git repository located on BitBucket. Continue Reading »
ruslany on March 27th 2014 in Other, PHP, WAWS
The recent upgrade of Windows Azure Web Sites includes several PHP related improvements:
First, the PHP 5.5 is now available. The PHP 5.4 becomes the default version used for newly created sites.
Note that there is no SQL Server Extension support for PHP 5.5.
Continue Reading »
ruslany on December 11th 2013 in PHP, WAWS, WinCache
Windows Azure provides a reliable web sites hosting infrastructure where sites data is replicated in Azure data centers for redundancy. However it is still important to do regular backups of the site’s content and databases in order to be able to recover from a human error, problematic upgrade or a hacking attempt. With the Azure Store Add-On Cloud Cellar it is easy to setup automated backup task that will run on a predefined schedule and will backup site content and database. This post explains how to do it. Continue Reading »
ruslany on October 24th 2013 in WAWS
The information in this post is out of date and should not be used as a guidance when configuring IP SSL for Azure Web Apps. Specifically if your custom domain is a CNAME to the default web app domain (e.g. contoso.azurewebsites.net) then it is not necessary to do any A record or CNAME changes as described in this article. The web app domains will be automatically remapped to the dedicated IP address when you enable IP SSL.
Azure Web Sites started to support custom domains SSL functionality recently. There are two SSL modes supported:
- SNI based SSL. This is an extension to SSL and Transport Layer Security (TLS) that allows multiple domains to share the same IP address, with separate security certificates for each domain. Most modern browsers (including Internet Explorer, Chrome, Firefox and Opera) support SNI, however older browsers may not support SNI.
- IP based SSL. This mode associates a certificate with a domain name by mapping the dedicated public IP address of the server to the domain name. This requires each domain name (contoso.com, fabricam.com, etc.) associated with your service to have a dedicated IP address. This is the traditional method of associating SSL certificates with a web server.
The SNI SSL setup is pretty simple and is documented in “How to enable SSL web site“. The IP SSL setup is more tricky, and unfortunately an important step is missing from that article. Without performing that step the domain name configured for IP SSL will continue to work as SNI SSL. The Windows Azure team is looking into fixing the documentation and UI workflow to prevent this confusion going forward. Meanwhile this blog post explains how to make sure IP SSL is configured correctly. Continue Reading »
ruslany on July 1st 2013 in WAWS