I’ve been a huge fan of Orchard for some time. Last year the Orchard team put together a conference they called the Orchard Harvest, and they’re doing the conference again this year in Europe. Specifically, in Amsterdam. If you’re an Orchard user or site owner I’d encourage you take a look at the Harvest. Some great speakers will be at the event in a great location and I’m sure there’ll be some awesome information. Find out more about the harvest at http://orchardharvest.org/.
If you’re a web developer working with ASP.NET, Node.js, PHP, Python, or you have plans on building your site in C++, Azure Web Sites is the best thing since sliced bread. With support for virtually every method of deployment and with support for most of the major web development models you can’t beat it. Until recently, SSL was the only question mark for a lot of web site owners, as WAWS doesn’t yet support SSL out of the box (trust me, it’s coming, I promise). The good news is that there’s a method of achieving SSL-secured sites now. In this blog post I’ll introduce the idea of a workaround my engineering friends in the Web Sites team call the SSL Forwarder, and to demonstrate how you can get up and running with an SSL-protected Azure-hosted web site in just a few minutes’ work.
First, I’d like to point out one very important point about the SSL Forwarder solution. This solution works, and we have a handful of community members actively using this solution to provide an SSL front-end for their web sites. So feel comfortable using it, but understand that this isn’t something you’ll have to do forever, as SSL is indeed coming as an in-the-box feature for Web Sites. If you love the idea of Azure Web Sites but the lack of in-the-box SSL support is a deal-breaker for you and your organization, this is a viable option to get you up and running now. However, the SSL Forwarder isn’t an officially supported solution, in spite of one being actively used by numerous customers. So if you set this up and you experience anything weird, feel free to contact me directly via the comment form below, or on Twitter, or by email (and I’ll give you my email address on Twitter if you need it). All that being said, I’ve heard from quite a few in the community who are using this solution that it has mitigated their concern and they appear to be running quite well with this in place.
Don’t panic when you see this solution. Do read the introduction, once you see grok how it all works, the SSL Forwarding solution is a whole lot less intimidating. I admit to having freaked out with fear when I first saw this. I’m no expert at most of the things involved in this exercise, but the Web Sites team literally put together a “starter project” for me to use, and it took me 1 hour to get it working. If I can do this, you can do this.
The idea of the SSL Forwarder is pretty simple. You set up a Cloud Service using the Azure portal that redirects traffic to your Azure Web Site. You can use all the niceties of Web Sites (like Git deployment, DropBox integration, and publishing directly to your site using Visual Studio or WebMatrix) to actually build your web site, but the requests actually resolve to your Cloud Service endpoint, which then proxies HTTP traffic into your Web Site.
The diagram to the right shows how this solution works, at a high level. The paragraph below explains it in pretty simple terms. I think you’ll agree that it isn’t that complicated and that the magic that occurs works because of tried-and-true IIS URL Rewrite functionality. In order to obtain the 99.9% uptime as outlined in the Azure SLA, you’ll need to deploy at least 2 instances of the Cloud Service, so the diagram shows 2 instances running. As well, the code provided with this blog post as a starting point is defaulted to start 2 instances. You can back this off or increase it however you want, but the 99.9% uptime is only guaranteed if you deploy the Cloud Service in 2 instances or more (and there’s no SLA in place yet for Web Sites, since it’s still in preview at the time of this blog post’s release, so you can host your Web Site on as many or as few instances as you like).
You map your domain name to your Cloud Service. Traffic resolves to the Cloud Service, and is then reverse-proxied back to your Web Site. The Cloud Service has 1 Web Role in it, and the Web Role consists of a single file, the Web.config file. The Web.config in the Web Role contains some hefty IISRewrite rules that direct traffic to the Web Site in which your content is hosted. In this way, all traffic – be it HTTP or HTTPS traffic – comes through the Cloud Service and resolves onto the Web Site you want to serve. Since Cloud Services support the use of custom SSL certificates, you can place a certificate into the Cloud Service, and serve up content via an HTTPS connection.
- A Azure Cloud Project
- A web site that’s used as a Web Role for the Cloud Project
- A web site that’s deployed to Azure Web Sites (you’ll want to replace this one with the project you’re deploying or just remove it, it’s just there as part of the sample)
Create the Cloud Service and Web Site
First thing is, I’ll need to create a Web Site to host the site’s code. Below is a screen shot of me creating a simple web site myself using the Azure portal.
Obviously, I’ll need to create a Azure Cloud Service, too. In this demo, I’ll be using a new Cloud Service called SSLForwarder, since I’m not too good at coming up with funky names for things that don’t end in a capital R (and when I do, Phil teases me, so I’ll spare him the ammunition). Below is another screen shot of the Azure portal, with the new Cloud Service being created.
If you’re following along at home work, leave your browser open when you perform the next step, if you even need to perform the next step, as it is an optional one.
Create a Self-signed Certificate
This next step is optional, and only required if you don’t already have an SSL certificate in mind that you’d like to use. I’ll use the IIS Manager to create my own self-signed certificate. In the IIS Manager I’ll click the Server Certificates applet, as shown below.
When I browse this site secured with this certificate, there’ll be an error message in the browser informing me that this cert isn’t supposed to be used by the domain name from where it’s being served. Since you’ll be using a realSSL certificate, you shouldn’t have to worry about that error when you go through this process (and I trust you’ll forgive a later screen shot where the error is visible).
Once that applet loads up in the manager, I’ll click the link in the actions pane labeled Create Self-Signed Certificate.
I’ll name my certificate SSLForwarderTesting, and then it appears in the list of certificates I have installed on my local development machine. I select that certificate from the list and click the link in the Actions pane labeled Export to save the cert somewhere as a file.
Then I find the location where I’ll save the file and provide it with a password (which I’ll need to remember for the next step).
Now that this [optional] step is complete I have a *.PFX file I can use to install my certificate in the Cloud Service.
Install the SSL Certificate into a Cloud Service
To activate SSL on the Cloud Service I’ll need to install an SSL certificate into the service using the Azure portal. Don’t panic, this is easier than it sounds. Promise. Five minutes, tops.
Back in my browser, on the Azure portal page, I’ll click the Cloud Service that’ll be answering HTTP/S requests for my site. The service’s dashboard page will open up.
I’ll click the Certificatestab in the navigation bar.
I’m going to want to upload my certificate, so this next step should be self-explanatory.
The next dialog gives me a pretty hard-to-screw-up dialog. Unless I forgot that password.
(cue the sound of hands ruffling through hundreds of post-its)
Once the certificate is uploaded, I’ll click the new cert and copy the thumbprint to my clipboard, maybe paste it into Notepad just for the moment…
Configuring the Cloud Service’s SSL Certificate
With the SSL cert installed and the thumbprint copied, I’ll open up the ServiceConfiguration.cloud.cscfg file in Visual Studio 2012 and set the thumbprint’s configuration. I could also do this using the built-in Azure tools in Visual Studio, but since I’ve got the thumbprint copied this is just as easy to do directly editing the files. Plus, the Web Sites team made it pretty obvious where to put the thumbprint, as you’ll see from the screen shot below.
Configuring the URL Rewrite Rules in the Web Role
Remember the architectural overview from earlier. The main thing this Cloud Service does is to answer HTTP/S requests and then reverse-proxy that traffic back to the Web Site I’m happily hosting in Azure. Setting up this proxy configuration isn’t too bad, especially when I’ve got the code the team handed me. I just look for all the places in the Web.config file from the Web Role project that mentions foo.com or foo.azurewebsites.net or foo…well, you get the idea.
Here’s the Web.config file from the Web Role project before I edit it to comply with the Web Site and Cloud Service I created to demonstrate this solution open in Visual Studio 2012. I’ve marked all the spots you’ll need to change in the screen shot.
Here’s the file after being edited. Again, I’ll indicate the places where I made changes.
Now that the Cloud Service and the Web.config file of the Web Role project’s been configured to redirect traffic to another destination, the proxy is ready for deployment. The solution’s Cloud project is defaulted to run at 2 instances, so that’s something you’ll want to remember – you’ll be paying for 2 instances of the Cloud Service you’ll be using to forward HTTP/S traffic to your Web Site.
Publish the Cloud Service
Within Visual Studio 2012, I right-click the Cloud project and select the Publish context menu item.
A dew dialogs will walk me through the process of publishing the SSLForwarder service into Azure. It may take a few minutes to complete, but once it publishes the Cloud Service will be running in your subscription and ready to respond to HTTP/S requests.
To verify everything’s working, try hitting the Cloud Service URL – in my case sslforwarder.cloudapp.net,to see if it’s answering requests or spewing errors about unreachable hosts, either of which wouldn’t be surprising – we’ve redirected the Cloud Service’s Web Role to a Web Site. That web site probably isn’t set up yet, so you could see some unpredictable results.
If you actually pre-configured your SSLForwarder Cloud Service to direct traffic to a *.azurewebsites.net you’re already running you’re pretty much finished, and you’re probably running behind HTTPS without any problems right now. If not, and the idea of publishing Web Sites from Visual Studio is new to you, you’ll have a chance to use that technique here.
Publish a Azure Web Site
I’ll go back into the Azure portal and go specifically to the SSLForwarder Web Site I created earlier on in the post.
Once the site’s dashboard opens up, I’ll find the link labeled download publishing profile. This file will be used by Visual Studio during publishing to make the process very simple.
Publishing and Browsing an SSL-encrypted Web Site
Once the publish settings file has been downloaded, it’s easy to push the site to Web Sites using Visual Studio 2012 or WebMatrix. With the sample project provided I’ll open up the Web Application project I want to publish to Web Sites. Then, I’ll right-click the web site project and select the Publish menu item.
Then, the publish process will make the remainder of the publishing experience pretty simple.
Remember to thank Sayed Hashimi if you need him out and about, he loves to hear thoughts on publishing and uses suggestions to make the experience an improved one for you. He also has a stupendous team of people working with him to execute great publishing experiences, who love feedback.
The publish process dialogs will walk you through the simple act of publishing your site up to Azure. Once it completes (which usually takes 30-60 seconds for a larger site) the site will open up in a web browser.
Note the URL still shows HTTP, and it also shows the URL of the Azure Web Site you created. You’ll need to manually enter in the URL for the Cloud Service you created.
For me, that’s www.sslforwarder.com. So long as the domain name you enter resolves toCloud Service you should be alright. You can also opt for the *.cloudapp.net approach too, as the domain name of the site you want to put out. Whatever your preference for solving this particular issue.
I’m going to go ahead and change the domain name andthe protocol, so our hit to the site being hosted in Web Sites will respond to it receiving an SSL-encrypted request, then load the site in the browser.
Note – this is when you’ll need to forgive me for showing you something that causes a warning in the browser. It’s just that way since I used a self-signed cert in a Azure service, so we should expect to see an error here. It’s right there in the browser’s address bar, where it says “Certificate Error.” If I’d used a real SSL cert, from a real authority, the error wouldn’t be there.
So for many months I’ve heard users request SSL on Web Sites, saying everything about it is awesome.Then they stare at me and wait about 3 seconds and usually follow it up with “but you’ve gotta get me SSL man, I’m over here and I gotta have my SSL”. I understand their desire for us to support it, and luckily, the Web Sites team and our engineering organization is so willing to share their solutions publicly. This is a great solution, but it won’t work in every situation and isn’t as good as what the Web Sites teams have in plans for the future. The SSL Forwarder solution is a good stop-gap, a good temporary solution to a problem we’ve had a lot of requests about.
Hopefully this helps in your decision to give Azure Web Sites a shot. If SSL has been your sole reason for not wanting to give it a try, now you have a great workaround in place that you can facilitate to get started right now.
If you’ve not yet used WebMatrix,
what are you waiting for?!?!?!? you’re missing out on a great IDE that helps you get a web site up and running in very little time. Whether you’re coding your site in PHP, Node.js, or ASP.NET, WebMatrix has you covered with all sorts of great features. One of the awesome features of WebMatrix is the number of templates it has baked in. Starter templates for any of the languages it supports are available, as are a number of practical templates for things like stores, personal sites, and so on. As of the latest release of Azure Web Sites, all the awesome WebMatrix templates are now also available in the Web Sites application gallery. Below, you’ll see a screen shot of the web application gallery, with the Boilerplate template selected.
Each of the WebMatrix gallery projects is now duplicated for you as a Web Site application gallery entry. So even if you’re not yet using WebMatrix, you’ll still have the ability to start your site using one of its handy templates.
Impossible, you say?
See below for a screenshot from within the WebMatrix templates dialog, and you’re sure to notice the similarities that exist between the Application Gallery entries and those previously only available from directly within WebMatrix.
As before, WebMatrix is fully supported as the easiest Azure-based web development IDE. After you follow through with the creation of a site from the Application Gallery template list from within the Azure portal, you can open the site live directly within WebMatrix. From directly within the portal’s dashboard of a new Boilerplate site, I can click the WebMatrix icon and the site will be opened up in the IDE.
Now that it’s open, if I make any changes to the site, they’ll be uploaded right back into Azure Web Sites, live for consumption by my site’s visitors. Below, you’ll see the site opened up in WebMatrix.
If you’ve not already signed up, go ahead and sign up for a free trial of Azure, and you’ll get 10 free sites (per region) to use for as long as you want. Grab yourself a free copy of WebMatrix, and you’ll have everything you need to build – and publish – your site directly into the cloud.
I wanted to let you know about an event I’ll be speaking at in early April. Along with my good friend and mentor Scott Hunter, “el master’o’ASP.NET,” I'll be presenting at the Web Camps in Dallas, Texas. I’d love to see you there.
Dallas isn’t the only stop for the Web Camps tour. Our other good buddy, Jon Galloway, has worked hard creating this year’s Web Camps content, and has been out on the road promoting all the awesome new stuff we’ve released with the ASP.NET framework and tools. Along with Mr. Hunter, I’ll be presenting demonstrations and content related to all of the awesome topics below:
- Keynote: The ASP.NET Web Platform in Context
- What’s new in ASP.NET 4.5 and Visual Studio 2012
- Building and deploying websites with ASP.NET MVC 4
- Creating HTML5 Applications with jQuery
- Building a service layer with ASP.NET Web API
- Leveraging your ASP.NET development skills to build apps for Office
- Building and leveraging social web apps in ASP.NET
- Building for the mobile web
- Real-time communications with SignalR
- Leveraging Azure and Azure Web Sites
So if you’re an ASP.NET developer, or you’ve been thinking about learning more about the new stuff available in the ASP.NET stack, come on out and join Scott Hunter and I on Friday, April 5 in Dallas, TX. We’ve got a whole series of these events lined up lots of other places, so check out the other areas where we’ll be heading and join us at one of those great events, too.
- March 20 - Oslo, Norway - Cory Fowler
- March 22 – Lisbon, Portugul - Cory Fowler
- March 25 – London, UK - Cory Fowler, Steve Sanderson and Stuart Leeks
- March 27 – Cambridge, MA - Nathan Totten
- April 3 – Copenhagen, Denmark - Jon Galloway and Mads Kristensen
- April 5 – Dallas, TX with Brady Gaster and Scott Hunter
- April 6 – Istanbul, Turkey - Jon Galloway, Tugberk Ugurlu and Umit Sunar
- April 12 – Bellevue, WA - Nathan Totten and Cory Fowler
- April 19 – Sunnyvale, CA - Nathan Totten and Jon Galloway
- April 26 – San Diego, CA - Jon Galloway
Jon, myself, and the rest of the team welcome you to this great series of events. We hope to see you there!
I’ve been asked a lot of great questions about Azure Web Sites since the feature launched in June. Things like on-premise integration, connecting to service bus, and having multiple environments (like staging, production, etc), are all great questions that arise on a pretty regular cadence. With this post, I’m going to kick off a series on solving real-world problems for web site and PaaS owners that will try to address a lot of these questions and concerns. I’ve got a few blog posts in the hopper that will address some of these questions, rather than just cover how certain things are done. Those posts are great and all (and a lot of fun to write), but they don’t answer some real-world, practical questions I’ve been asked this year. Stay tuned to this area of my site, as I’ll be posting these articles over the next few weeks and probably into the new year. As I post each of these solutions I’ll update this post so you have a one-stop shop to go to when you need to solve one of these problems.
Posts in this Series
Multiple Environments with Azure Web Sites
In this post I demonstrate how to have production and staging sites set up for your web site so that you can test your changes in a sandbox site before pushing your production site and potentially causing damage to it (and your reputation). If you’ve wondered how to gate your deployments using Azure Web Sites, this is a good place to start. You’ll learn how to use Azure Web Sites with a GitHub.com repository and some creative branching strategies to maintain multiple environments for a site.
Managing Multiple Azure Web Site Environments using Visual Studio Publishing Profiles
This post takes the same sort of scenario as presented in the first article. Rather than use GitHub.com as a means to executing a series of gated environment deployments it focuses on the awesome features within Visual Studio for web publishing. Specifically, you’ll see how to use publishing profiles to deploy to multiple Azure Web Sites, so that a team of peers responsible for releasing a site can do so without ever needing to leave Visual Studio.
This post also takes a look at the idea of release management and how this solution answers the question of doing proper release management with a cloud-hosted web site. If you’ve wondered how your SDLC could fit in the idea of continuously maintaining a series of environments for gating your releases using Visual Studio’s super-simple publishing features, this is a great place to start.
Connecting Azure Web Sites to On-Premises Databases Using Azure Service Bus
This post introduces the idea creating a hybrid cloud setup using a Azure Web Site and the Azure Service Bus, to demonstrate how a web site hosted in Azure can connect to your on-premises enterprise database. If you’ve been wondering how to save data from your Azure Web Site into your local database but didn’t know how to do it, or if you’re thinking of taking baby steps in your move toward cloud computing, this post could provide some good guidance on how to get started.
Continuous Delivery to Azure Web Sites using TeamCity
My good friend Magnus put together a very extensive and informative blog post on using Azure Web Sites with TeamCity. If you're a CI user, or a TeamCity user, you'll want to check this out, as it is a great recipe for implementing your CI builds against Azure Web Sites. Magnus worked really hard on this blog post and started working on it for his Windows AzureConf talk, and I'm proud to see how it came together for him.
Jim O'Neil's Blog Series on Integrating Azure Web Sites and Notifications
Jim's blog series - part 1, part 2, and part 3 - are great if you're looking into implementing instant messaging with your Azure Web Site. This series is great, and I feel it shows off some amazing potential and adds a whole new dimension to what's possible on the platform. Take a look at these posts, they're quite inspiring.
G. Andrew Duthie’s Series on Back-end Data Services with Windows 8 Applications
The @devhammer himself has created an awesome series on putting your data in the cloud, so your Windows 8 applications have a common place from which to pull the data. In this series, he discusses how to use Azure Web Sites to create an API that can be called by a Windows 8 application. If you’re delving into Windows 8 development and have been wondering how you could use Web Sites to create the APIs you’ll be calling, this series is a must-read.
Maarten Balliauw on Configuring IIS Methods for ASP.NET Web API with Azure Web Sites
My good friend and dedicated MVP Maarten just wrote up a great post on configuring IIS within Azure Web Sites to support additional HTTP methods like HEAD and PATCH using configuration files. If you’re trying to do some deeper Web API functionality and have struggled with getting these types of HTTP methods supported, this could solve your problem.
Branches, Team Foundation Services, and Azure Web Sites
Wouter de Kort covers how to achieve the multiple-environment approach using Team Foundation Services online. If you're using TFS and you want to set up multiple branches that deploy to a variety of web sites, this article will help you get going. This is a great introduction to using TFS for multiple branches with Azure Web Sites.