Azure Installation

Table of Contents:

Overview

Windows Azure is a cloud-computing platform for hosting web applications. We’ve investigated the Azure platform for its potential as a host for our AppAccess program. Azure offers at least two services that provide some degree of compatibility with the installation of third-party software such as AppAccess:

Virtual Machines – Azure offers the ability to create a virtual machine with any of the following operating systems:

  • Windows 2008
  • Ubuntu
  • Red Hat
  • SUSE
  • CentOS

*Note: These machines can be accessed via SSH or Remote Desktop Connection.

Cloud Services – Once you’ve created your website in any variety of languages within a local environment, you can use Azure’s tools to package your code up into a “Cloud Service” with a configuration file for specifying behavior on Azure.

Collector Installation

Virtual Machines

If you choose the virtual machine solution, it’s remarkably easy to install AppAccess.

1. Create a virtual machine. You can follow the steps in these videos:

2. Once you’ve completed those steps, you should be logged into the Virtual Machine you created. Now you need only follow the instructions found by clicking “Add More Collectors” at the top of the AppFirst Workbench.

Cloud Services

Since the whole point of Cloud Services is to allow you to “Focus on your application, not the infrastructure,” we cannot simply crack open our application’s host and install AppAccess by hand as we could with a Virtual Machine. Instead, we must work with an automated, hands-free process Azure uses to stage our applications. In order to install our desired AppAccess software in spite of this abstraction layer, we will be using a non-interactive installation feature of the Windows AppAccess installation executable.

If you choose the Cloud Service solution, you must first create your web application. You can follow the steps found at these Azure-provided links:

These steps should provide you with instructions on how to install the appropriate Azure SDK on your Windows environment.

Once you’ve successfully created an Azure cloud service, you can modify it on your local environment to handle the installation of AppAccess. In order to do this, you must have a Windows AppAccess installation executable.

First, let’s talk about how this installation executable’s silent, non-interacive feature will be used.

  1. Rename the installation executable to something simple, such as setup.exe.
  2. Open up the Command Prompt, and navigate to the directory containing setup.exe.
  3. Run the command:
    $ setup.exe
    For example, I used the command:
    $ setup.exe
    in order to install a that was pointed to our production.
  4. The only sign that the installation is occurring will be a second Command Prompt window briefly appearing.
  5. You can verify that AppAccess was installed by entering the command:
    $ TASKLIST /FI “IMAGENAME eq AppAccess.exe”
    You will know AppAccess was installed if something is displayed resembling:

Image Name                                  PID  Session Name           Session#   Mem Usage
========================= ======== ================ =========== ============
AppAccess.exe                            1448  Services                               0          5,556 K

That is how the installation will work on your local machine. Now, let’s walk through configuring our Azure application to install AppAccess on its host.

  1. If you have followed the instructions for creating an Azure Cloud Service Application, your project files should be in a directory that shares the name of your project. Suppose your project’s name is MyWebProject. Navigate to the directory titled MyWebProject. Inside this directory, there should be both another directory titled MyWebProject and a directory titled MyWebProject.azure. There will also likely be a MyWebProject.sln file if you’ve created a Visual Studio Solution. Navigate to the inner MyWebProject directory.
  2. You should now see several files and folders, including a bin directory. Navigate to the bin directory.
  3. Place your setup.exe AppAccess Installation Executable into the bin directory.
  4. Create a new plaintext file in the bin directory titled install_collector.cmd.
  5. Edit this file to contain the line:
    setup.exe
    as discussed previously.
  6. Save the file install_collector.cmd.
  7. Navigate back out to the outer MyWebProject directory, and into the MyWebProject.Azure directory.
  8. Open the file ServiceDefinition.csdef.
  9. This is an xml file. Look for the tag, and inside of that the tag. If you do not see a tag, you can create it after the tag:

    <?xml version="1.0" encoding="utf-8"?>
    <ServiceDefinition name="MyWebProject.Azure" ... >
      <WebRole name="MyWebProject" vmsize="Small">
        <Sites>
          ...
        </Sites>
        <Endpoints>
          ...
        </Endpoints>
        <Startup>
          ...
        </Startup>
        <Imports>
    
        </Imports>
      </WebRole>
    </ServiceDefinition>
    
  10. Inside of , you need to create a startup task:
  11. <Startup>
          ...
          <Task commandLine="install_collector.cmd" executionContext="elevated" taskType="simple"/>
    </Startup>
    
  12. Save ServiceDefinition.csdef.

What we just did was place the command we want called into a .cmd file, and stored it along with the Installation Executable it calls into the application’s binary directory. Then we edited the ServiceDefinition file to run that command during the Cloud Services startup phase. Now if you deploy this application to Azure, it should install AppAccess on the application’s host before the web application comes online.

Here’s a few issues to notice:

  • Azure does not allow you to choose a hostname for the host upon which it places your application. Thus, watch out for server names on the Workbench such as rd00155d44179c and rd00155d44223f.
  • Azure may use more than one hostname for your one web application. Watch out for two or more similar servers listed on the Workbench.
  • Azure may switch hosts for your application without warning if, for example, Azure suffers a hardware problem and needs to migrate your application. Though your application should not be affected, AppAccess will be reinstalled and another server (or set of servers) may be listed on the Workbench.