Exercise 1: Deploying an Application Using the Windows Azure Management Portal

In this exercise, you deploy the myTODO application to Windows Azure using the Windows Azure Management Portal. To do this, you provision the required service components at the management portal, upload the application package to the staging environment and configure it. You then execute the application in this test environment to verify its operation. Once you are satisfied that it operates according to your expectations, you promote the application to production.

Note:

In order to complete this exercise, you need to sign up for a Windows Azure account and purchase a subscription.

For a description of the provisioning process, see Provisioning Windows Azure.

Task 1 – Creating a Storage Account and a Hosted Service Component

The application you deploy in this exercise requires both compute and storage services. In this task, you create a new Windows Azure storage account to allow the application to persist its data. In addition, you define a hosted service component to execute application code.

Navigate to http://windows.azure.com using a Web browser and sign in using the Windows Live ID associated with your Windows Azure account.
Figure 2
Signing in to the Windows Azure Management Portal
First, you create the storage account that the application will use to store its data. In the Windows Azure ribbon, click New Storage Account.
Figure 3
Creating a new storage account
In the Create a New Storage Account dialog, pick your subscription in the drop down list labeled Choose a subscription.
Figure 4
Choosing a subscription to host the storage account
In the textbox labeled Enter a URL, enter the name for your storage account, for example, <yourname>mytodo, where <yourname> is a unique name. Windows Azure uses this value to generate the endpoint URLs for the storage account services.
Figure 5
Choosing the URL of the new storage account
Note:
The name used for the storage account corresponds to a DNS name and is subject to standard DNS naming rules. Moreover, the name is publicly visible and must therefore be unique. The portal ensures that the name is valid by verifying that the name complies with the naming rules and is currently available. A validation error will be shown if you enter a name that does not satisfy the rules.
Select the option labeled Create or choose an affinity group and then pick Create a new affinity group from the drop down list.
Figure 6
Creating a new affinity group
Note:
The reason that you are creating a new affinity group is to deploy both the hosted service and storage account to the same location, thus ensuring high bandwidth and low latency between the application and the data it depends on.
In the Create a New Affinity Group dialog, enter an Affinity Group Name, select its Location in the drop down list, and then click OK.
Figure 7
Creating a new affinity group
Back in the Create a New Storage Account dialog, click Create to register your new storage account. Wait until the account provisioning process completes and updates the Storage Accounts tree view. Notice that the Properties pane shows the URL assigned to each service in the storage account. Record the public storage account name—this is the first segment of the URL assigned to your endpoints.
Figure 8
Storage account successfully created
Now, click the View button next to Primary access key in the Properties pane. In the View Storage Access Keys dialog, click Copy to Clipboard next to the Primary Access Key. You will use this value later on to configure the application.
Figure 9
Retrieving the storage access keys
Note:
The Primary Access Key and Secondary Access Key both provide a shared secret that you can use to access storage. The secondary key gives the same access as the primary key and is used for backup purposes. You can regenerate each key independently in case either one is compromised.
Next, create the compute component that executes the application code. Click Hosted Services on the left pane. Click on New Hosted Service button on the ribbon.
Figure 10
Creating a new hosted service
In the Create a new Hosted Service dialog, select the subscription where you wish to create the service from the drop down list labeled Choose a subscription.
Figure 11
Choosing your subscription
Enter a service name in the textbox labeled Enter a name for your service and choose its URL by entering a prefix in the textbox labeled Enter a URL prefix for your service, for example, <yourname>mytodo, where <yourname> is a unique name. Windows Azure uses this value to generate the endpoint URLs for the hosted service.
Figure 12
Configuring the hosted service URL and affinity group
Note:
If possible, choose the same name for both the storage account and hosted service. However, you may need to choose a different name if the one you select is unavailable.
Note:
The portal ensures that the name is valid by verifying that the name complies with the naming rules and is currently available. A validation error will be shown if you enter name that does not satisfy the rules.
Select the option labeled Create or choose an affinity group and then pick the affinity group you defined when you created the storage account from the drop down list.
Figure 13
Choosing an affinity group
Note:
By choosing this affinity group, you ensure that the hosted service is deployed to the same data center as the storage account that you provisioned earlier.
Select the option labeled Do not Deploy.
Note:
While you can create and deploy your service to Windows Azure in a single operation by completing the Deployment Options section, for this hands-on lab, you will defer the deployment step until the next task.
Click OK to create the hosted service and then wait until the provisioning process completes.
Figure 14
Hosted service successfully created
Do not close the browser window. You will use the portal for the next task.

Task 2 – Deploying the Application to the Windows Azure Management Portal

A hosted service is a service that runs your code in the Windows Azure environment. It has two separate deployment slots: staging and production. The staging deployment slot allows you to test your service in the Windows Azure environment before you deploy it to production.

In this task, you create a service package for the myTODO application and then deploy it to the staging environment using the Windows Azure Management Portal.

Open Microsoft Visual Studio 2010 in elevated administrator mode. To do this, in Start | All Programs | Microsoft Visual Studio 2010, right-click the Microsoft Visual Studio 2010 shortcut and choose Run as Administrator.

In the File menu, choose Open and then Project/Solution. In the Open Project dialog, browse to Ex1-DeployingWithWAZPortal\Begin in the Source folder of the lab, select MyTodo.sln in the folder for the language of your preference (Visual C# or Visual Basic) and click Open.

The solution contains the following projects:

MyTodo	A standard cloud service project configured to support a single web role named MyTodo.WebUx
MyTodo.Data.WindowsAzure	A class library project that contains data contracts for the MyTodo.WebUx application for table storage
AspProviders	An implementation of ASP.NET Membership, Role, and SessionState providers for Azure Storage
MyTodo.WebUx	A web role that hosts the MyTODO ASP.NET MVC application in Windows Azure

Ensure that the System.Web.Mvc assembly is included in the service package that you deploy to Windows Azure. To do this, for a Visual C# project, expand the References node in Solution Explorer for the MyTodo.WebUx project, right-click the System.Web.Mvc assembly and select Properties. For a Visual Basic project, right-click the MyTodo.WebUx project and select Properties. In the Project Properties window, switch to the References tab, select the System.Web.Mvc assembly, and press F4.
To add the assembly to the service package, in the Properties window for the System.Web.Mvc assembly, if Copy Local setting is set to False then change it to True.
Figure 15
Including assemblies in the service package deployed to Windows Azure
Note:
In general, you need to set Copy Local = True for any assembly that is not installed by default in the Windows Azure VMs to ensure that it is deployed with your application.
Next, change the size of the virtual machine that will host the application. To do this, in Solution Explorer, expand the Roles node of the MyTodo project and then double-click the MyTodo.WebUX role to open its properties window. In the Configuration page, locate the VM Size setting under the Instances category and choose the Extra small size from the drop down list.
Figure 16
Configuring the size of the virtual machine (VM) for the deployment
Note:
When you create your service model, you can specify the size of the virtual machine (VM) to which to deploy instances of your role, depending on its resource requirements. The size of the VM determines the number of CPU cores, the memory capacity, the local file system size allocated to a running instance, and the network throughput.
To configure the storage before deploying the service, open ServiceConfiguration.cscfg file located in MyTodo service. Replace the placeholder labeled [YOUR_ACCOUNT_NAME] with the Storage Account Name that you chose when you configured the storage account in Task 1. If you followed the recommendation, the name should follow the pattern <yourname>mytodo, where <yourname> is a unique name. Make sure to replace both instances of the placeholder, one for the DataConnectionString and the second one for the Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString.
Next, replace the placeholder labeled [YOUR_ACCOUNT_KEY] with the Primary Access Key value that you recorded earlier, when you created the storage account in Task 1. Again, replace both instances of the placeholder, one for each connection string.
Figure 17
Configuring the storage account connection strings
Now, define the version of the Windows Azure Guest Operating System that should run your service on the virtual machine. To do this, double-click the ServiceConfiguration.cscfg file in the MyTodo project to open this file in the XML editor. Now, add an osVersion attribute to the ServiceConfiguration root element and set its value to WA-GUEST-OS-1.8_201010-01, as shown in the figure below.
Note:
The value used for osVersion here is to illustrate that you can select which release of the guest OS runs your application. You may use a higher version.
Figure 18
Configuring which version of the guest operating system runs the application in the VM
Note:
The Windows Azure Fabric runs a guest operating system into which your service application will be deployed. This guest operating system is regularly updated. While rare, there is some chance that updated guest operating system versions may introduce breaking changes in your application. By setting the osVersion attribute, you ensure that your application runs in a version of the Windows Azure guest operating system that is compatible with the version of the Windows Azure SDK with which you developed it. You may then take the time to test each new osVersion prior to running it in your production deployment.
To configure the operating system version, you need to edit the service definition file directly because the current release of the Windows Azure Tools for Microsoft Visual Studio does not support setting this attribute through its user interface.
Windows Azure offers an auto-upgrade feature, that automatically upgrades your service to use the latest OS version whenever it becomes available, thus ensuring that your service runs in an environment with the latest security fixes. This is the default mode if you omit an osVersion when you deploy your service. To change an existing service to auto-upgrade mode, set the osVersion attribute to the value “*”.
For information on available versions of the Windows Azure guest operating system, see Windows Azure Guest OS Versions and SDK Compatibility Matrix.
Press CTRL + S to save the changes to the service model.
To create a service package, right-click the cloud service project and select Package.
In the Package Windows Azure Application dialog, click Package and then wait until Visual Studio creates it. Once the package is ready, Visual Studio opens a window showing the folder that contains the generated files. Close the window after you see the package.
Figure 19
Creating a service package in Visual Studio
Go to the web browser and open the Summary page for the project that you created in the previous task.
At the portal, select the hosted service that you created in the previous step and then click New Staging Deployment on the ribbon.
Note:
A hosted service is a service that runs your code in the Windows Azure environment. It has two separate deployment slots: staging and production. The staging deployment slot allows you to test your service in the Windows Azure environment before you deploy it to production.
Figure 20
Hosted service summary page
In the Create a new Deployment dialog, to select a Package location, click Browse Locally, navigate to the folder where Visual Studio generated the package in Step 10 and then select MyTodo.cspkg.
Note:
The .cspkg file is an archive file that contains the binaries and files required to run a service, in this case, the myTODO ASP.NET MVC application. Visual Studio creates the service package for you when you select Package for your Windows Azure project.
Now, to choose the Configuration File, click Browse Locally and select ServiceConfiguration.cscfg in the same folder that you used in the previous step.
Note:
The .cscfg file contains configuration settings for the application, including the instance count that you will update later in the exercise.
Finally, for the Deployment name, enter a label to identify the deployment; for example, use v1.0.
Note:
The management portal displays the label in its user interface for staging and production, which allows you to identify the version currently deployed in each environment.
Figure 21
Configuring service package deployment
Click OK to start the deployment. Notice that the portal displays a warning message when you do this. Click See more details to review and understand the message.
Figure 22
Reviewing the warnings
Note:
In this particular case, the warning indicates that only a single instance is being deployed for at least one of the roles. This is not recommended because it does not guarantee the service’s availability. In the next task, you will increase the number of instances to overcome this issue.
Click Yes to override and submit the deployment request. Notice that the package begins to upload and that the portal shows the status of the deployment to indicate its progress.
Figure 23
Uploading a service package to the Windows Azure Management Portal
Wait until the deployment process finishes, which may take several minutes. At this point, you have already uploaded the package and it is in a Ready state. Notice that the portal assigned a DNS name to the deployment that includes a unique identifier. Shortly, you will access this URL to test the application and determine whether it operates correctly in the Windows Azure environment, but first you need to configure it.
Note:
During deployment, Windows Azure analyzes the configuration file and copies the service to the correct number of machines, and starts all the instances. Load balancers, network devices and monitoring are also configured during this time.
Figure 24
Package successfully deployed

Task 3 – Configuring the Application to Increase Number of Instances

Before you can test the deployed application, you need to configure it. In this task, you change the service configuration already deployed to increase the number of instances.

In Hosted Services, select your MyTodo service and click Configure on the ribbon.
Figure 25
Configuring application settings
In the Configure Deployment dialog, select the option labeled Edit current configuration, locate the Instances element inside the MyTodo.WebUX configuration and change its count attribute to 2.
Figure 26
Configuring the Instances count
Note:
The configuration is simply an XML document that contains the value of the settings declared in the service definition file. Its initial content is determined by the ServiceConfiguration.cscfg file that you uploaded earlier, when you deployed the package in Task 2.
Note:
The Instances setting controls the number of roles that Windows Azure starts and is used to scale the service. For a token-based subscription—currently only available in countries that are not provisioned for billing—this number is limited to a maximum of two instances. However, in the commercial offering, you can change it to any number that you are willing to pay for.
Click OK to update the configuration and wait for the hosted service to apply the new settings.
Figure 27
Updating the number of role instances
Note:
The portal displays a legend "Updating deployment..." while the settings are applied.

Task 4 – Testing the Application in the Staging Environment

In this task, you run the application in the staging environment and access its Web Site URL to test that it operates correctly.

In Hosted Services, select your MyTodo service and then click the link located in the right pane under DNS name.
Figure 28
Running the application in the staging environment
Note: The address URL is shown as <guid>.cloudapp.net, where <guid> is some random identifier. This is different from the address where the application will run once it is in production. Although the application executes in a staging area that is separate from the production environment, there is no actual physical difference between staging and production – it is simply a matter of where the load balancer is connected.
Note:
In the future, you will be able to have multiple “virtual” areas, for test, QA, pre-production, etc...
Click Start to prepare the application for first time use, which requires you to create a new account. To do this, navigate to register menu.
Figure 29
Application running in the staging environment
Complete the account details by entering a user name, email address, and password and then click Register.
Note:
Account information is stored in the storage account created earlier. Data is not shared between to do lists.
Figure 30
Creating a new account
Next, the application enumerates the lists that you have currently defined. Since this is your first use, no lists should appear.
Figure 31
Application ready to be used
If you wish to explore the application, create a new TODO list and enter some items.

Task 5 – Promoting the Application to Production

Now that you have verified that the service is working correctly in the staging environment, you are ready to promote it to final production. When you deploy the application to production, Windows Azure reconfigures its load balancers so that the application is available at its production URL.

In Hosted Services, select your MyTodo service and then click Swap VIP on the ribbon.
Figure 32
Promoting the application to the production slot
On the Swap VIPs dialog, click OK to swap the deployments between staging and production.
Figure 33
Promoting the application to the production deployment
Click the DNS name link to open the production site in a browser window and notice the URL in the address bar.
Figure 34
Application running in the production environment
Note:
If you visit the production site shortly after its promotion, the DNS name might not be ready. If you encounter a DNS error (404), wait a few minutes and try again. Keep in mind that Windows Azure creates DNS name entries dynamically and that the changes might take few minutes to propagate.
Note:
Even when a deployment is in a suspended state, Windows Azure still needs to allocate a virtual machine (VM) for each instance and charge you for it. Once you have completed testing the application, you need to remove the deployment from Windows Azure to avoid an unnecessary expense. To remove a running deployment, go to Hosted Services, select the deployment slot where the service is currently hosted, staging or production, and then click Stop on the ribbon. Once the service has stopped, click Delete on the ribbon to remove it.