I’m extremely excited to announce that this site is now being hosted by Windows Azure Websites! Despite how easy it actually was to move my site over to Windows Azure, it’s taken me quite a long time due to how busy I’ve been with other things. I’m very happy to report that the site is loading faster and handling load much better now that it’s been moved to the cloud. I did run into a few issues moving over all of the code and content that I’d like to share in case anyone else out there runs into them.
CNAME’s and a records
With Windows Azure Websites, you get 10 free websites running in a multitenant virtual machine. This means that the server hosting your site(s) is also hosting other sites. One of the limitations of this is that you don’t get the option to use custom domain names. However, if you upgrade to either a Shared or Reserved instance (pricing information is here), on top of getting upgraded specs (better quotas on CPU, memory, and network usage), you are able to set custom domain names. Changing from the free mode to either Shared or Reserved is super easy and can be done from your site’s Scale tab in the Windows Azure Portal:
All you have to do is tap whichever one you want. Once you’ve done that, you’ll be able to set custom domains from the Configure tab in the portal. The next step can be very easy depending on how your site is set up. If you’re not using a “naked domain” (meaning there is a “www.” or “blog.” before your domain) then all you need to do is add a CNAME record in your DNS settings to direct from www or blog (whatever your subdomain is) to sitename.azurewebsites.net. According to the custom domain documentation, you can also set up a CNAME record for awverify and have it redirect to awverify.sitename.azurewebsites.net. To be safe, I had done both in my DNS records:
You’ll need to remove (or replace) any existing records that match the subdomains you’re using. Now, if your site was using a subdomain like www or blog, you could be fine and go back to the portal and add in your custom domain, however, if your site is using a “naked domain” like mine is (I redirect everything for www.chrisrisner.com to chrisrisner.com) you need to take one more step and add an a record. In order to do this, you first need to get the IP address you should point your a records at. Return to the portal and click on the Manage Domains button on the bottom of the screen (when in your site setup):
In the modal that pops up, when you scroll to the bottom, you’ll see the IP address you should use:
Once you have that, you can then add a records for your site:
It’s important to note that your domain will likely already have these records in it’s DNS settings. You’ll need to alter the existing ones and use the new IP address. Now you can return to the portal and go to the Manage Domains button again and add your custom domains. Once you do this, it takes effect immediately. This meant that my site was not down at all (with the exception of a few minutes while I sorted out the next issue).
Websites and connection strings
One of the great things about Windows Azure Websites is the ability to set connection strings and app keys in the portal so you don’t have to put sensitive information in the web.config. It also allows you to make changes to these values on the fly from the portal instead of having to modify your web.config. To see and edit these, you’ll need to go into the Configure tab for your website in the portal. Scroll down and you should see app settings and connection strings:
My uses Entity Framework for the database connections so I have an Entity Framework connection string in my web.config. If you’ve never seen a SQL connection string and compared it to one for EF, they look a little different. Here’s a normal SQL connection string that you’d see in a web.config file:
<add name="ConnectionStringName" providerName="System.Data.SqlClient"
connectionString="Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;" />
Now let’s look at one for EF:
<add name="ConnectionStringName" providerName="System.Data.EntityClient"
connectionString="metadata=res://*/Models.Name.csdl|res://*/Models.Name.ssdl|res://*/Models.Name.msl;provider=System.Data.SqlClient;provider connection string="Data Source=qnc1dmpuuz.database.windows.net;Initial Catalog=databaseName;User Id=userName;Password=password;MultipleActiveResultSets=True"" />
The actual connectionString attribute is quite different, however, this is not an issue when adding a connection string in the portal. There is a connection string type drop down and you can choose custom to enter the EF value:
However, there is an issue with the different providerName attribute. EF specifically looks for a connection string with a provider name of System.Data.EntityClient. However, if you add your EF string using the portal, it won’t have this provider type. This means that, as of right now you can’t put an EF connection string in the portal. The team is aware of this though I’m not sure when a fix will be out.
Moving files through GIT
The second issue I ran into was with pushing all of my files up to Windows Azure Websites using GIT. The markup and code files for my site don’t actually rack up that much space, however, I am hosting a lot of image and archive files within my site’s folders (I’ve since started serving up files through Windows Azure Storage). When I tried to do the push, I received this error:
Unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; result=65, HTTP code = 0
fatal: The remote end hung up unexpectedly
The essence of the issue is that the buffer size being used to push the files was too small. I did some searching and found out how to increase the postBuffer value:
git config http.postBuffer 524288000
I still ended up with issues the push of all the data files would stall. To solve this, I only pushed a few files up to the server at a time. Another solution would have been to have moved these files using FTP, though, that would mean the files wouldn’t be in the GIT history for my site.
Cloud Powered
With the exception of those two issues, the move to Windows Azure Websites so seamless and super easy. Since I moved my site I’ve noticed a significant decrease in load times and less data throughput (since more and more of the images are being served up by Windows Azure Storage and not my website). Additionally, thanks to the ease of scaling Windows Azure Websites, if my site ever gets ridiculously busy, I can easily change the number of instances running my site (from the Scale tab) to support the increased load.
