Early Thinking
This post describes some new Azure features and how they might help us in leveraging the power of the web/app.config files again. The content is this article is written, before any CTP/Beta versions of these features are available, so the details might be incorrect and there might be some wrong assumptions. I will verify all of these parts, once the features are made available.
Current situation
Until now, an important difference between deploying a web application (or web service) on a local or hosted server and deploying a web application (or web service) to Windows Azure was the usage of the web.config file.
In a standard web application (hosted on IIS), the web.config can easily be changed to update configuration settings. When changing this file, the web application gets refreshed and the new settings are being applied.
On Azure, there was a total different story. The web.config was compiled with the deployment package and to change it, a new version of the packaged needed to be uploaded, resulting in a lot of work/time before the new settings got applied. Luckily, Windows Azure provided a nice alternative: the serviceconfiguration files (.cscfg). This file allowed to specify configuration values that could be loaded at runtime through the following code:
RoleEnvironment.GetConfigurationSettingValue("myValue"); code.
Painpoints with the Azure serviceconfiguration files.
The idea is great, having service configuration files managed on Role level and not on instance level. But there are some big disadvantages in the following scenarios:
WCF Configuration settings
WCF has tons of configuration settings and I am a big fan of having my service endpoints configured through the .config files. This allows for easy change and full declarative configuration, without having the settings (binding/behaviors) compiled with the program. And since the introduction of the WCF Router service, even more configuration (the pub/sub logic) gets in the .config file.
Having all these settings in the Azure .cscfg file, would be very hard to maintain, or we’d need to switch to custom configuration files.
Custom configuration settings
In most of the applications that are developed at Codit, we use custom configuration sections to have a better structured configuration experience. These configuration sections are complex types and no standard name/value configuration pairs. Migrating these applications to Azure, would mean our configuration logic would need to be totally redesigned.
ASP.NET settings
ASP.NET also include a lot of settings that might need to be changed at runtime.
PDC announcements
At PDC a lot of stuff was announced that can help us here. This article described the various announcements and their impact on the configuration issues I described above.
Remote desktop capabilities
Through the updated Azure management portal (didn’t that look a 100 times nicer than the current one?), we will soon be able to have Remote Desktop access to our web. This will be done by adding the following Modules in the service definition file (.csdef)
<Imports>
<Import moduleName="RemoteAccess" />
<Import moduleName="RemoteForwarder" />
</Imports>
This allows us to connect to a running instance of an Azure role. This way we can alter the web.config file and have everything updated as on a regular web application.
The biggest disadvantages of this approach are the following:
- When having multiple instances (which is required to have High Availability), we need to remote in on every running instance of our web role.
- Our changes will be undone when our instance restarts or gets redeployed, because the machine gets ’prepped’ again, resulting in a fresh installation of our Azure package.
The new Azure VM Role
Through the announced Windows Azure VM Role, we will be able to customize our own Virtual Machine, by uploading a pre-built virtual hard disk (VHD) to a blob storage account.
The steps to do this are the following :
- Install Windows Server 2008 R2 Enterprise on the VHD
- Add any Additional software you might need on the VM Role instances
- Install Windows Azure Integration Components that include the following components
- Agent
- Runtime interface (topo, config, shutdown notification)
- Remote Desktop configurator
- Windows Azure Drives driver
- Generalize the VHD is recommended, by using sysprep (machine name will be assigned by Azure.)
By using a difference VHD, it might be easy to upload a new version of that VHD with the updated configuration file on it and have the changes applied. Besides that, the same approach can be taken as described in the previous section (remote desktop capabilities).
The biggest disadvantages of this approach are the following:
- To upload a new version of the VHD difference disk, the role might need to be reinitiated (to be tested, once the VM Role is available for CTP)
- Cumbersome way of changing the web.config.
Startup tasks
As shown in the CloudCover show of two weeks ago (watch episode), there is a possibility of executing startup tasks, when the role instance starts up. This looks like the best suited feature to solve our config file problem.
I am making one crucial assumption here (that I’ll check once this is made available): I believe the start up tasks are being executed prior to the Role Instance initiation – so before the web application is started. This means we can still change the web.config without having the web application being recycled automatically.
Leveraging the startup tasks will allow us to take the web.config from a configurable blob container and write it to the application directory on the Azure instances. Therefore, we just need to write a script that performs this logic. (code will be in a future post). Then we just need to configure that script in the Startup element in the csdef configuration file:
<Startup>
<Task commandline="updateconfig.cmd" executionContext="elevated"
taskType="simple/foreground/background" />
</Startup>
This approach looks like the best approach to make our web.config and app.config files configurable again.
Conclusion
A lot of uncertainties, because there is no bit available yet to test this with. So, please expect a reviewed post, once it has been made available.
But one thing is for sure: the new Azure features will make Azure application development much more flexible again.
Sam Vanhoutte, Codit