This article contains now obsolete information. Please refer to my update article that contains details on what to do when using the non-CTP version of Windows Azure.
I’m happy to report that moving forward, my Azure Development VPC image will be using Windows 7! While this won’t really mean any difference to those of you reading this blog, it does make me happy. The new VPC image performs faster than the Vista one and as yet I’m not having any real issues with it (aside from having to figure out where stuff’s at).
Between getting my new VPC up and running and some distracting thoughts regarding how to use the cloud to extend legacy on-premise applications (long story), I have managed to get this next article up. Today I want to briefly discuss configuration options in Windows Azure.
Anyone that’s been doing .NET development is likely used to using the .config files to store configuration settings. With them you can make a quick tweak to your application by just firing up your favorite text editor and making the change. Now in an on-premise application this worked well because you usually had the ability to log into the hosting server and make the change. The downside was that if the application was hosted on multiple servers, you have to log into each server and make the same change. All the while hoping really hard that you didn’t mess one up or miss an instance.
Now lets move this scenario into the cloud. We have multiple instances of our application all running in the cloud, we also don’t have remote access to the server to make the changes ourselves. So now, we have to change our application, rebuild it, publish it to the cloud, deploy it to staging, review it, and then deploy it to production. All this for something as simple as changing a minor configuration option in a text file. The upside is that with one deployment, Azure handles updating all instances of the application for us. But have no fear, there is another option.
If you recall, back in Part 1 of my series on Azure Queues, I talked about adding the Microsoft.ServiceHosting.ServiceRuntime namespace to my class library. At the time I stated I wasn’t sure we needed it and in hindsight we really didn’t (that app would have run as a traditional asp.net application). Until now. You also hopefully recall our discussion about the ServiceConfiguration and ServiceDefinition files from my Hands on with the Azure Web Role. Together, these two items are the solution to our problem. We’ll put our settings into the ServiceConfiguration file then access them with the RoleManager class from the Microsoft.ServiceHosting.ServiceRuntime namespace.
Here we go….
Service Configuration and Definition files
A few weeks back, Ryan Dunn, author and technical Evangelist for Microsoft updated his blog with a post on why Windows Azure uses these files. In a nutshell, these files were created to allow for a configuration option that exists outside of the service deployment packages themselves.
If you’ve read the MSDN article on Understanding a Hosted Service Architecture, you already know that the Service Definition file is bundled with our deployment package. It tells the Azure Fabric what types of roles are in the package as well as what configuration options exist in the Service Configuration file. The definition will be used by the RoleManager class to allow our cloud services to access those configuration properties. These two files, configuration and definition, work hand in hand. So we’ll need to update our service definition file with our custom properties and then update the configuration with the actual values.
I’m going to use my previous QueueDemo project for this, so lets start by altering that solution’s service definition file as follows:
In the image at the right, I’ve highlighted our changes to my services configuration definition file. Inside of the web role node, I’ve added a new ConfigurationSettings node which details the three settings we’ll be adding for this solution: AS_URI, AS_AccountName, AS_SharedKey.
You can see we can create separate configuration settings for both the Web Role and (if it was present), the Worker Role. Unfortunately, at this time there’s no way to create a single configuration setting that is shared by both roles. Personally, I’m hoping I’ve either overlooked something or that this will be added in the future. If someone knows different, please let me know.
Heard back from the Azure team that this is indeed the case currently. No word on if it will change in the future or not.
With this done, now we have to switch to the service configuration file and set the values for our new keys.
I’ve put in false values, so you’ll want to insert your own Azure Storage values into settings. If you want, the local storage credentials will work just fine if you want to use the QueueDemo application as I left it at the end of that series.
Accessing Service Configuration
Creating the service configuration is only half the equation. We now need to use the RoleManager to access these settings. Among other things, the RoleManager class allows us write to the service log, access local storage (not to be confused with the Azure Storage services), and to access our configuration settings.
GetConfigurationSetting is a static method of the RoleManager class. We give this method the name of the setting we want to retrieve the setting for and it returns the value (if it exists). If the requested value does not exist, a RoleException will be thrown.
Here’s my example:
public AzureQueue(): base()
myURI = RoleManager.GetConfigurationSetting("AS_URI");
So what does this buy us?
We’ve got a configuration file, and we have accessed it from our application. But the big question now is how does this help us solve our initial problem of updating a simple entry without having to redeploy our application.
The picture to the left is a portion of the Windows Azure cloud service management page. See that “Configure…” button center below the glowey cube, that’s our solution.
Once our cloud service (web or worker, makes no difference) is deployed, we can click that button to directly access the configuration file and make changes. The Azure Fabric then pushes those changes out to all the instances so the changes can take affect.
Hopefully, once the Windows Azure management API is announced, we’ll see the ability to update this via a service. Combine that with various monitors to see how the instances of our services are running and we have a really spiffy way to remotely manage our web applications. I look forward to revisiting this subject when/if that is possible.
Likes sands through the hourglass
That’s all I have for now. I’m still messing with my QueueDemo sample project to get it working with hosted storage (darn these useless “bad request” exceptions). After that, I plan another ‘hands on’ style session with worker roles. Once I get all that out of the way, I’ll start messing with .NET services. With legacy application integration being at the forefront of my mind lately, I’m especially looking forward to working with the service bus.
Until then, if there’s something you’d like to see me mess with, don’t hesitate to drop me a line at firstname.lastname@example.org.
Till next time!