I have seen this question asked many times now: “How do I install third party software on Windows Azure?” This is a reasonably important question to address as Windows Azure applications often need to use third party software components.
In some cases, using a software component can be as simple as adding a reference to it. You can also set the Copy Local property to True to bring the component along with your service package to the cloud. However, in some cases a proper installation is required. This is because the installation does other things than just copying the component to the system (such as: modifying registry, register the components to GAC, etc.) One example would be when installing Report Viewer on the Web Role to display reports.
This article will explain three techniques you can use to install third party software on Windows Azure. We will cover why and how to install third party software, and the catches that come with each technique.
Before diving into the specific techniques, let’s refresh the concept behind the current version of Windows Azure PAAS as it relates to what we’ll be discussing.
Windows Azure emphasizes the application philosophy of scaling-out (horizontally) instead of scaling-up (vertically). To achieve this, Windows Azure introduces the stateless virtual machine (VM). This means a VM’s local disks will not be used for storage since they are considered stateless or non-persistent. Any changes made after the VM is provisioned will be gone if the VM is re-imaged. This can happen if a hardware failure occurs on the machine where the VM is hosted.
Figure 1 – Windows Azure Stateless VM and Persistent Storage
Instead, the recommended approach is to store data to dedicated persistent storage such as SQL Azure or Windows Azure Storage.
Now, let’s discuss each technique to install software on Windows Azure in more detail.
The first technique we discuss here is the fastest and easiest, but unfortunately also the most fragile. The idea is to perform a remote desktop (RDP) to a specific instance and perform manual installation. This might sound silly to some of you as we just discussed the stateless VM above. Nonetheless, this technique is pretty useful in staging or testing environments, when we need to quickly assess if a specific software can run in a Windows Azure environment.
The software installed will not be persistent.
NOTE: Do not use this technique in production.
The second technique we cover here is a Start-up Task. In my opinion, this will probably be the best solution depending on your circumstances. The idea of a Start-up Task is to execute a script (in form of a batch file) prior to the role initialization. As it will be always executed prior role initialization, even if the instance is re-imaged it will still be executed.
1. Preparing your startup script
Create a file name startup.cmd using Notepad or other ASCII editor. Copy the following example and save it.
powershell -c “(new-object system.net.webclient).downloadfile(”http://download.microsoft.com/download/E/A/1/EA1BF9E8-D164-4354-8959-F96843DD8F46/ReportViewer.exe”, ” ReportViewer.exe”) ReportViewer.exe /passive
2. Including startup.cmd to Visual Studio
The next step is to include your startup.cmd script to Visual Studio. To do that, simply right click on the project name and choose “Add Existing Item”. Browse the startup.cmd file. Next, set “Copy to Output Directory” to “Copy always”, to ensure that the script will be included inside your package when it is built.
Fiure 2 – Incuding startup.cmd in the Service
3. Adding Startup Task on your ServiceDefinition.csdef file
The final step is to add a startup section in ServiceDefinition.csdef file, specifically below the intended Role tag as illustrated in below figure.
Figure 3 – Adding Startup Task in ServiceDefinition.csdef
Here are some situations where a startup task cannot be used:
1. Installation that cannot be scripted out
2. Installation that requires many user involvement
3. Installation that takes a very long time to complete
The final technique we are looking at is VM Role. In fact, one of the reasons why Microsoft introduced VM Role is to address the issues that couldn’t be done by Startup Task.
In reality, VM Role is another option amongst Windows Azure Compute Roles. However, unlike Web and Worker Roles, you will have more responsibility when using VM Role. People often make the mistake of treating VM Role as IAAS. This is not appropriate as VM Role still inherits behaviors from Web and Worker Roles. VM Role still can be easily scaled out just like Web and Worker Roles. Similarly, storing data in VM Role’s local disk is considered non-persistent.
The following figure illustrates the lifecycle of VM Role.
Figure 4 – VM Role Lifecycle from the Windows Azure Platform Training Kit. Find the whole PowerPoint presentation here: http://acloudyplace.com/wp-content/uploads/2012/05/MovingApplicationsToTheCloudWithVMRole.pptx
Let’s drill down to the first step “Build VM Image” in more detail. There are several tasks that should be done here. First of all is to create the VHD that contains the operating system. The next step is to install Windows Azure Integration Component onto the image. Subsequently, you can install and configure the third party software. Finally, you do a SysPrep to generalize the VM image.
There are several catches when using VM Role:
1. You will have more responsibility when using VM Role, including: building, customizing, installing, uploading, and eventually maintaining the VM image.
2. Up to now, the only supported OS for VM Role is Windows Server 2008 R2.
3. At the time of writing this article, VM Role is still at beta. As we know, significant changes may happen to the beta product.
We have covered three techniques to install software in Windows Azure so far. Although, Startup task remains the recommended option in most cases, it may not be the most suitable all the time. RDP and VM Role can sometimes be advantageous depending on the scenario.
This post was also published at A Cloud Place blog.