Almost every application running as a Windows Azure Cloud Service has configuration. Application configuration in this context does not mean user-specific application data but data the application needs to work properly like external endpoint definitions, default values and more. Application configuration data can be stored and maintained is several ways. This blog post compares these.
Files on a web server
Traditionally, application configuration can often be found in “app.config” or “web.config” files. An advantage of this approach is that these files could be modified runtime without taking the web application down. However, when running in a Cloud Services, any changes to these files require a redeployment to let the changes take affect. Modifying these files directly on web role instances (using RDP) is “not done” because any changes will be lost when an instance is restarted. Clearly, this is not the way to go.
Database
Antother possibility is to store application configuration data in a database. When changes are required only an SQL script has te be executed from the Azure Database Management Portal or Management Studio. All instances of a web role will instantly have the new configuration data (as long as this data is not cached). When using Management Studio one must not forget to add a firewall rule to be able to connect to the database from a specific machine. Drawback of this approach is that using a database means additional costs and the fact that users that have access to the Windows Azure Management Portal need additional access to the database. The database must be part of a backup plan to be able to restore the actual application configuration data.
Azure Storage
Windows Azure Storage can also be used to store application configuration data. This approach is similar to using a database. It is a central place to store the data and all web role instances can access it. Modification to the application configuration can be made using a variety of tools. The primary or secondary access key must be used (but is accessible by anyone that has access to the Windows Azure Management Portal). Again, the Azure Storage container must be part of a backup plan.
Windows Azure Service Configuration
The Windows Azure Service Configuration uses 2 files to store application configuration data:
- “.csdef” (Windows Azure Service Definition Schema)
- “.cscfg” (Windows Azure Service Configuration Schema)
All parameters that are defined in the Service Definition file are assigned a value in the Service Configuration file. These values can be modified runtime in the Windows Azure Management Portal. When a modification is made, all instances of the web role are updated. An advantage of this approach is that the application managers that already have access to the Windows Azure Management Portal can use this portal to modify the application configuration.
There are 2 ways to modify the application configuration using the Azure Management Portal. First, a user can change a specific parameter in the user interface. These settings can be found on the CONFIGURE tab of a web or worker role:
When an instance of the web role gets restarted, the configuration is preserved. However, using the Management Postal user interface to make changes does not support version management. Therefore, it is a better idea to download the .cscfg file, edit it and then upload it again.
The Upload and Download buttons can be found at the bottom of the CONFIGURE tab. This way, the modified .cscfg file can be stored in a (local) version management system and this guarantees that the actual application configuration is always available when a redeploy is required.
The post Application configuration in Windows Azure Cloud Services appeared first on ICT Blog.
