domgreen

Over the past couple of weeks I have been looking at migrating existing ASP.NET applications from being hosted in on premise to being hosted on the Windows Azure Platform.

One of the problems that I have run into whilst trying to migrate the applications to Windows Azure was ensuring that the Event Log’s and Performance Counter were accessible and could be written to by the application.

When running inside of Windows Azure applications tend to run without elevated permissions so we ended up running into multiple security messages signifying that the application could not write to the required event logs due to the lack of security permissions.

A work around for this is to use a new feature recently added to Windows Azure and the ability to create startup tasks that can be run as administrator when the VM starts. From this we can run command statements to install the event logs and performance counters.

Getting a startup task running in the Azure nodes means adding the following snippet to each role, this will run the specified command line task (startup.cmd) with elevated privileges before anything else is done on the VM (taskType=simple).

The file startup.cmd is then added to the site (or could be added as an additional file during packaging) and ensure that the properties are set so that this and any other file needed for the startup task is set to “Copy always” this will ensure the file is within the package when built.

Within this startup.cmd task we are to first set up PowerShell and then run our own PowerShell script which will contain the code to start register the event logs:

Within CreateEventLog.ps1 we can then easily create event logs and sources with the following PowerShell snippet:

This will now have created the needed event logs that can be written to by the application when it starts running ... no more security errors, and your eventlog is now accessiable.

After a previous post where I discussed the benefits of using existing tools over creating your own build tasks I have been able to reproduce exactly the same deployment script working in Rake as I had previously shown in MSBuild using the Windows Azure Tools to control the deployment and initialization of instances in the public and local cloud environments.

When deploying to the public cloud the only thing that I have changed in the scenario is to add a line to use the CSPack tool rather than relying on the MSBuild tasks supplied with the Windows Azure SDK to create the cloud package for my application.

The full Rake build, deployment and initialization script is below, showing that we can use all the same tools and concepts independent of the build engine. This script relies heavily on calling out to the command line with the exec method that I have created to pass in the command line arguments.

When running an automated build to deploy your application into Windows Azure you need to at some point run a packaging script, this will take all the components of your application and turn them into a .cspkg file ready to be deployed to Azure with the correct configuration.

I would have normally done this using the CSPack Tool and something like this:

This shows a CSPack command creating a web and worker role for an application (tokenized).

This gets annoying to keep updating and can actually get quite confusing especially when the SDK upgrades and you need to go and figure out what changes you need to make to your packing command to ensure the .cspkg file is created correctly.

However, there is good news coming … if you are using MSBuild you can call upon the build targets that are part of the Windows Azure SDK and allow it to do all of the packaging for you.

The targets are typically located here:

C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets

You can then add these targets to your own MSBuild targets like so:

Then call on the following targets:

• CorePublish – This packages up your application as a .cspkg file to be published into the  public cloud
• CorePackageComputeService – This packages the application so that it can be run on the local development fabric.

These two targets use the CSPack command under the hood but allows you to defer the responsibility to the Azure targets rather than having to write the CSPack command yourself.

Here is how I have used these targets on a previous project:

Microsoft have made a small update to the Windows Azure Dev Portal and added the ability to configure the operating system that are running on your nodes and how they are updated.

As you can see in the below image the new magic “OS Settings…” button is now available.

Clicking on the “OS Settings…” button takes you to the following screen to configure your operating system options and how it is updated:

I have recently been working on a big Azure application that we have been wanting to deploy to the cloud and test, to make sure that no unexpected bugs occur whilst the application is in the wild and give the opportunity to see how it performs.

Now the big problem has been deploying our application to the cloud every time we wanted to update the application online, we had a dev sit there and manually publish the service, upload the package and initialize the instances. This obviously wasn't great as one of the developers on the team would have to take time out from his tasks / bugs to upload the application.

However, the Azure team came through with some great releases just over a week ago that would allow the management of our services via an API. As soon as I read the blog post announcing the Windows Azure Service Management API I knew that my prayers had been answered and we would be able to automate deployment of our application out to the cloud. This surprisingly was much easier to understand and implement than I imagined as a sample called csmanage.exe was included with the release giving a hook into all of the API’s (documentation).

The most time consuming part turned out to be wrapping the calls to csmanage.exe into build scripts and watching a number of builds and deployments fail before getting it right (no one likes to wait 15mins only to see a red light).

So here’s what I did to get our application deploying on the daily build:

Seting up the Service

Setting up the service requires you to upload a certificate to your Azure login, this can either be done with the following handy command line argument:

Or use Eric Nelson’s walk through “Using IIS to generate a X509 certificate”.

Now we just need to log into the portal and upload the certificate, taking note of your Subscription ID and certificate thumbprint.

Configure csmanage.exe

With this information we can now configure the csmanage tool to talk with the service management API.

Packaging the Cloud Service

When deploying prior to the release of the management API I would normally right click the Cloud service within Visual Studio and let it handle the packing of the application itself, however during the build we will need to do this automatically. So we can dig out cspack.exe a command line application to package up your solution that was shipped with the Azure SDK.

When packaging the application we need to give the cspack executable a number of arguments these are, the service definition so that it knows what configuration to expect, any web roles and their containing folder, any worker roles with the folder containing the dll and also the name of the dll and an optional out parameter. I normally use the out parameter to ensure that I have the correct name and location of the package for the next step.

Uploading cspkg to Azure Storage

When deploying with the csmanage.exe we need to ensure that the packaged solution is available in blob storage on the same account you are deploying to, to do this I have created a simple command line application that takes the cspkg file and puts it into a folder called “packages” in our storage area.

Using csmanage.exe

Now that we have our package in Azure storage and csmanage.exe configured we can use the management API to call out to our service and deploy to Azure.

I first suspend and delete any service that is currently running:

This leave me safe in the knowledge that the creation of a package will not fail due to a running service.

Now the important part using csmanage.exe to create a deployment in our hosted service, within this command I am selecting the hosting area I wish to create the deployment, the production slot as well as the location of the package (blob storage) and any configuration that will be used in the deployed service.

Once the service is successfully deployed we can set the status of the deployment to a running state and allow it to initialize itself.

Once the deployment is fully initialized users can start using the application.

Creating Build Targets

With the correct commands figured out and correctly deploying my application to the cloud I decided to write some build targets to do this during our daily builds. To do this I used the msbuild exec command (I know this is probably really ugly but it gets the job done, well at least until the Azure boys give some built in tasks).

The only problem I found with this that the csmanage.exe will return exit codes and so the exec command will need to ignore these, or will treat them as errors during the build.

Multiple Deployments

On the current project we are actually deploying the application to a number of different sites for test, performance etc. so have also had to create a number of scripts to ensure that the endpoints are correct for each of the deployments. Added to this we needed to check that the csmangae.exe and the cloud apps configuration (cscfg) are set up correctly using the sdc tasks and their xml setters to get this working.

Now at the end of each day the latest iteration of our application is uploaded and deployed to Azure, leaving us devs to be happy coders and not worry about deployment :) .