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. The list of outbound IP addresses is now included in the REST API Site object and can be accessed by using Azure Resource Explorer. Just select the Web App in the Resource Explorer tree view and then look for the “outboundIpAddresses” property, which will contain a comma separated list of IP addresses. For example the following screenshot shows outbound IP addresses used by my site https://ruslany.net:
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 https://ruslany.net/proxy/ to some other URL I’ll need to do two things:
Enable proxy functionality in ARR
Add a proxy rewrite rule
Any site hosted in Azure Web Sites has URL Rewrite and ARR enabled. However the proxy functionality is disabled by default in ARR. To enable that we will use the Azure Site Extension XDT transform which will modify the applicationHost.config file for our site and will enable proxy features.
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:
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.
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.
Windows Azure Web Sites has recently been upgraded to a new version. Among all the improvements and bug fixes in the new version there is one change that fixes a known issue with update of WordPress plugins. There have been numerous questions about this problem at the Azure Web Sites forum.
The need to diagnose and troubleshoot application’s failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.
This is the most obvious, but very often the most helpful diagnostics tool. The output of this function provides a lot of information about the PHP runtime. Use it to determine what PHP extensions are enabled, what are the PHP configuration settings and what values are stored in server environment variables.
In my previous post about the migration of a WordPress site to Windows Azure I mentioned that I used phpMyAdmin to import existing blog data into a MySql/ClearDb database in Windows Azure. phpMyAdmin is a web based tool for administering MySql databases. It can be used to create tables, edit the data in tables, export/import/backup data and many other tasks. I found it to be an adequate tool for all MySql db administration needs in Windows Azure. This post describes how to install and configure phpMyAdmin on Windows Azure Web Sites.
I have not been writing any blog posts for a while. That was because for the past two years I have been busy working in a team that develops the Windows Azure Web Sites – a scalable web hosting platform in Windows Azure.
Now that the Windows Azure Web Sites (WAWS) is publicly available I decided to try to move my site from private hosting to Windows Azure. My site uses WordPress (with MySql database), PHP 5.3, WinCache object and user cache, URL rewriting and many WordPress plugins. With all these different technologies (many of which are not developed by Microsoft), I thought it would be a good test of how WAWS is capable of running web sites that use open source technologies. Plus I expect that my site will be more reliable and available, comparing to my previous private hosting.
I was pleasantly surprised that the migration from private hosting to WAWS hosting was relatively quick and simple. The site has been running successfully in a Shared compute mode for a while now and none of the site’s functionality has been lost or altered. In this post I’ll explain the steps I took to move my site to WAWS hosting. Hopefully it will be useful to those who are planning to migrate their WordPress based site to WAWS.