Migrating a Blog to Windows Azure Web Sites
For many years, I’ve hosted my blog on Orcsweb. I moved there about 5 years ago or so, after outgrowing webhost4life. Orcsweb is a huge supporter of the community and has offered free hosting to MVPs and MSFTies, so it seemed like a no brainer to go to a first class host at no charge. Orcs is also local (Charlotte, NC) and I know many of the great folks there. But, the time has come to move my blog to Windows Azure Web Sites (WAWS). (This switch, of course, should be transparent.)
This isn’t meant as disappointment with Orcs, but lately I’ve noticed my site throwing a lot of 503 Service Unavailable messages. Orcs was always incredibly prompt at fixing the issue (I was told the app pool was stopping for some reason), but I always felt guilty pinging support. Frankly, my blog is too important to me, so it seemed time to take responsibility for it.
WAWS allows you to host 10 sites for free, but if you want custom domain names, you need to upgrade to the shared plan at $10/mo. This is a great deal for what you get, and offers great scalability options when needed. My colleague, Andrew, recently had a great post on WebGL in IE11, and he got quite a bit of traction from that post as you can see from the green spike in his site traffic:
This is where the cloud shines: if you need multiple instances for redundancy/uptime, or simply to scale when needed, you can do it with a click of a button, or even automatically.
Migrating the blog was a piece of cake. You’ve got a couple of options with WAWS: you can either create a site from a gallery of images (like BlogEngine.net, Wordpress, et al.), as shown in red below, or simply create an empty website to which you can deploy your own code (shown in green).
Although I use BlogEngine, I already have all the code locally so instead of creating a site from the gallery, I created an empty website using Quick Create and then published the code. If you’re starting a new blog, it’s certainly faster to select a blog of your choice from the gallery and you’re up and running in a minute.
After clicking Quick Create, you just need to enter a name (your site will be *.azurewebsites.net) and a region for your app to live:
Once your site is created (this should only take a few seconds) we’ll see something like this:
Since the site I’m going to be pushing up has already been created, all I need right now is the publish profile. You can certainly publish from source control, but for the time being let’s assume we have a website in a directory we want to publish. I saved that file in a convenient place.
There are two quick ways to bring up the Publish dialog in VS, either through Build – Publish Web Site, or right click on project and select Publish Web Site.
The next step is to locate the publish profile:
Once imported, the connection details should be filled and the connection validated:
The first deploy can obviously take a little while depending on the size of the solution, and you can see what’s going on in the output window:
The website should launch automatically when done:
Easy, huh? On the configure page, we can add our custom DNS names:
For example, on my blog, I’ve got a few domains that I’ve added:
When first trying to add a domain name, you may see something like this:
What the message is saying is that before the website will respond to that domain, we need to prove that we, in fact, own the domain name. We can go about this two ways, either by creating an A record or CNAME. A CNAME is technically the most appropriate, however, it’s often insufficient because many people try browse to a root domain, such as “https://structuretoobig.com” instead of “https://www.structuretoobig.com” or “https://blog.structuretoobig.com”. In these cases, you need an A record, but that’s another topic entirely.
Here’s an example of the somedomain CNAME for my blog on my DNS registrar (this is not something you do on Windows Azure – this is to be done by your domain registrar):
Once done, you might have to wait a short while for those changes to propagate the DNS cache. (1 hour TTL is pretty low – typically you’d bump that a bit higher but when doing migrations, it’s best to keep this low so any changes you make are more immediate.)
Once done and after waiting about 2 minutes, the domain is verified in the Windows Azure DNS page:
In this case I created a CNAME over to this blog, so if we try it, here we are! How cool is that … I’m writing about what’s on the screen. Hmmm … this is kind of strange…
So what if we wanted to create something from the gallery, instead? For example, setting up a new BlogEngine site instead of downloading the code and publishing it. If we clicked on “From Gallery” when first creating our web site, we’ll see something like this:
The advantage of this approach is that it copies all of the files for you into your site. You still have total access to those files, but this is perfect for new blogs and you know you’ll have a working configuration right away. On the dashboard of the page, you’ll notice you have all the links you need to connect to your site, download a publish profile, set up source control, etc. You can also configure an FTP password.
If we open this in FileZilla, we can see it has the same directory structure as our code, as the gallery image happens to be using the same version. If we wanted to, we could pull down this code and redeploy it as necessary with any changes:
The bottom line: this post took a lot longer to write that it did for me to migrate my entire blog. It’s easy to get going, and scalable to exactly what you need. If you’re pulling in advertising or have critical uptime needs, you can have 2 or more instances for extra reliability and load capacity, or simply when needed. If you don’t need a custom DNS name, the free tier gives you some great benefits and liberal usage.
Want to get started with Azure? Here’s a link to a free trial, and of course, the free stuff remains free after the trial.