I haven’t blogged for a while because of being very busy at work. Things are slowing down a bit so I will try to write more frequently.
Azure SDK 2.5 made big changes to Azure diagnostics. It introduced Azure PaaS Diagnostic extension. Even though this was a good long term strategy the implementation was less than perfect. Here were a few issues that were introduced as a result of Azure SDK 2.5
- Local emulator did not support diagnostics
- No support for using different diagnostics storage account for different environments
- Manual editing required to create XML configuration file needed by Set-AzureServiceDiagnosticsConfiguration. This PowerShell cmdlet was required to deploy the diagnostic extension
- To make matters worse there was a bug in the PowerShell cmdlet which surfaced when you had a . in the name of the roles.
All these factors made it impossible to do continuous integration/deployment for Cloud service projects.
A few days ago Azure SDK 2.6 was released. I went through the release notes and read up the documentation. I ran tests to see if sanity has been restored. I am glad to report all the issues introduced by SDK 2.5 have been fixed. Here is a summary of improvements.
- Local emulator now supports diagnostics.
- Ability to specify different diagnostics storage account for different service configuration
- To simplify configuration of paas diagnostics extension the package output from Visual Studio contains the public configuration XML for the diagnostics extension for each role.
- PowerShell version 0.9.0 which was released along with the Azure SDK 2.6 also fixed the pesky bug that was happening when you had a . in the name of the role.
Here is a document that provides all the gory details for Azure SDK 2.6 diagnostics changes.
If you are developing application and still not using continuous integration and continuous deployment you should be learn more about it. I will use rest of this blog post to show how you can use PowerShell cmdlets to automate the installation and updating of PaaS diagnostics extension for Cloud Services built using Azure SDK 2.6.
I installed Azure SDK 2.6 on my development machine. I install PowerShell cmdlets(version 0.9.0) and Azure CLI as well.
I created a simple Cloud Service Project. I added a web role and a worker role to it.
I added one more Service Configuration called “Test” to this project.
I examined the properties of the WebRole1 to see what has changed with SDK 2.6
If you select “All Configurations” you can still enable/disable the diagnostics like you used to do in SDK 2.5
When I selected “Configure” button to configure the diagnostics I found that we don’t have to select the diagnostics storage account in the “General” tab like we used to do. Rest of the configuration is same.
Returning back to the configuration of the WebRole1 I changed the Service Configuration to “Cloud”.
In the past there was no way to configure diagnostics storage account for configuration type.
But now we can define a different diagnostics storage account for each configuration type.
Quick examination of the ServiceConfiguration.Cloud.cscfg confirmed that diagnostics connection string was defined in it.
This makes a lot of sense because rest of the environment specific configuration setting are also defined in the same file.
I did not want to deploy this project directly from Visual Studio because most build servers do not use Visual studio to deploy applications.
First I created a deployment package by selecting the Cloud project and select Package.
Selected the “Cloud” Service Configuration and Press “Package” button.
The project was built and packaged successfully. It opened up the location where the package and related files were created.
It created a directory called app.publish in the bin\debug directory under the cloud service project.
This is not any different from the past. However there is a new directory called Extensions.
Extensions directory has PubConfig.xml file for each role type. You had to create this file manually from diagnostics.wadcfg in the past. These files are needed by PowerShell cmdlets that are used to deploy diagnostics extension.
We use AppVeyor for continuous integration and deployment. It uses msbuild to build the projects.
I ran “Developer Command Prompt for Visual Studio 2013” and used the following command to build and package the cloud project.
msbuild <ccproj_file> /t:Publish /p:PublishDir=<temp_path>
I verified that msbuild also created the package and all the related files.
PowerShell Cmdlets for Azure Diagnostics
For new Cloud Services there are two ways to apply diagnostics extensions.
- You can pass the extension configuration to New-AzureDeployment via –ExtensionConfiguration parameter.
- You can create the Cloud Service first and use Set-AzureServiceDiagnosticsExtension to apply the PaaS diagnostics extension.
You can learn about it here.
I chose method one because it was faster than applying extension in a separate call.
Deploying PaaS Diagnostics Extension for the first time
The following script creates a new Cloud Services, creates the diagnostics configuration and deploys the package which also deploys the PaaS diagnostics extension.
I am setting the diagnostics extension for each Role separately.
At the end of this script I use Get-AzureServiceDiagnosticsExtension to verify if the diagnostics has been installed.
You can also use Visual Studio Server Explorer to view the diagnostics.
Update PaaS Diagnostics Extension
I wanted to see how we can update diagnostics extension so I made these changes to my project.
I added a new worker role to the same project. I also changed the the configuration of diagnostics.
Typically an extension is only deployed once. To deploy the extension again you have two option:
- You can either change the name of the extension
- You can remove the extension and install it again
I chose the second option.
Here is what this script does:
It removes the PaaS Diagnostics extension from the cloud service
It creates PaaS diagnostics configuration for each role.
It updates the Cloud Service and applies PaaS diagnostics extension to each role including the new worker role Hard.WorkerRole.
Having a . in the name used to break the Set-AzureServiceDiagnosticsExtension. It is nice to see it is working now
Azure SDK 2.6 has addressed most of the issues related to deploying diagnostics to Cloud Services that were introduced by SDK 2.5. Cleanest way to update diagnostics extensions is the remove the existing diagnostics extension and setting it again during the deployment. I tested deploying Diagnostics extension individually on each role it took 3-4 minutes to deploy each extension so if you have a large number of roles your deployment times may increase. In my case with 3 role types it was taking 12 minutes for the script to run. When I used –ExtensionConfiguration parameter of New-AzureDeployment and Set-AzureDeployment it took only 5 minutes for the entire script to run.