Case Study on Development and configuration options in MS Azure
-Paresh Bapat, Apurva Joshi, Shalaka Padalkar, Shaunak Pusalkar
1.Introduction:
● Microsoft Azure is a cloud computing service created by Microsoft for building, testing, deploying, and managing applications and services using Microsoft-managed data centres.
● It provides software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS) and also supports many different programming languages, tools, and frameworks, including Microsoft-specific and third-party software and systems as well.
● The project Azure was announced in October 2008, it had the codename “Project Red Dog” and released on February 1, 2010, as Windows Azure before being renamed to Microsoft Azure on March 25, 2014.
2. Creation of an Azure project:
● After finishing the installation, create an Azure Cloud Service project, for working with Azure Cloud Services. The cloud service is a compute container for infinitely scalable, highly available and multi-tier cloud-based applications.
● Steps for creating an Azure application:
1. start Visual Studio with elevated privileges, click on the File menu and choose New Project to bring up the New Project dialog.
2. Under Installed Templates- Visual C# select the Cloud node and select the Azure Cloud Service Project template to bring up the New Cloud Service Project dialog. This dialog helps you to add roles to a cloud service.
Roles and Instances:
● A role is nothing but a definition for both the app and the PaaS-managed VM (virtual machine) it will run on, defining, for example, which diagnostics settings should be used and what endpoints are supposed to be exposed, which OS and modules should be installed on the VM etc.
● It can also be viewed as your template that lets you create as many or as few instances (that is, VMs) as you need to scale to the current requirements on your cloud service. There are presently two types of roles you can create from Visual Studio:
● There are currently two types of roles you can create from Visual Studio:
1. Web Role: A Web application running on IIS(Internet Information Services). It’s accessible via an HTTP or HTTPS endpoints. Generally, this is used for front-end web applications and web services.
2. Worker Role: A background processing application that runs arbitrary .NET code. It also has the ability to expose Internet-facing and internal endpoints on HTTP, HTTPS, TCP and User Datagram Protocol.
The Instances directly correspond to VMs in the cloud running roles defined by the role template.
Source : Microsoft azure documentation
3. Web Application Projects to Cloud Service conversion
● · In the conversion of web projects to cloud service projects we can azurify an existing web application project. Let’s suppose we have already Web Application project such as ASP.NET MVC 4 project that we want to exert to Azure, then select the project choose proper command “Add Azure Cloud Service Project”.
● · This command adds a cloud service project to the solution. Also visual studio adds the NuGet references for Azure project to the MVC project.
● · In addition the tool sets the Copy Local property foe System.Web.MVC assembly to true because the assembly isn’t available on Azure.
4. Debugging an Azure application locally
○ In the current world of software development, the technology of cloud computing has taken an important place. The triage of software crashes however has become more challenging because of the use of the cloud. Software crashes never happen at a good time, therefore it is important that you beforehand know where you can get all your logs. So that you can build an efficient triage strategy.
○ One Best strategy to adopt is to debug the applications locally.
○ If the detailed error message doesn’t provide enough information, and you can’t recreate the error locally , another way to troubleshoot is to run in debug mode remotely. We can set breakpoints, manipulate memory directly, step through code, and even change the code path.
Now the steps that we need to take to remotely or locally to debug the application are:-
● Open the web project that we created.
● Then we Open Controllers\HomeController.cs.
● Then we Delete the About() method and insert the following code in its place. public ActionResult About() {
string currentTime = DateTime.Now.ToLongTimeString();
ViewBag.Message = “The current time is “ + currentTime;
return View(); }
● Then we Set a breakpoint on the ViewBag.Message line.
● In Solution Explorer, right-click the project, and click Publish.
● In the Profile drop-down list, select the same profile that you used. Then, click Settings.
● In the Publish dialog, click the Settings tab, and then change Configuration to Debug, and then click Save.
● Click Publish. After deployment finishes and your browser opens to the Azure URL of your app, close the browser.
● In Server Explorer, right-click your app, and then click Attach Debugger. Click About in the menu.
● Visual Studio stops on the breakpoint, and the code is running in Azure, not on your local computer.
● Hover over the current Time variable to see the time value.
● Enter a new value for the currentTime variable, such as “Now running in Azure” Press F5 to continue running.
● The About page running in Azure displays the new value that you entered into the currentTime variable.
Some Important points to remember and consider for remote/local debugging:-
● Avoid long stops at breakpoints when remote debugging. Azure treats a process that is stopped for longer than a few minutes as an unresponsive process, and shuts it down.
● You can manually attach the debugger to any process, not only the app process (w3wp.exe).
● A timer starts on the server when you enable the remote debugging feature, and after 48 hours the feature is automatically turned off. This 48-hour limit is done for security and performance reasons. You can easily turn the feature back on as many times as you like. We would recommend leaving it disabled when not actively debugging.
5. Publishing to Azure
After the development, modification and debugging of the application locally it is ready to be deployed to Azure. It is good practice to observe the lifecycle of application creation before allowing a final publication in the production environment of Azure. First in a test environment, an application has to be published. Basically, the test environment is a cloud service that is needed to build, and use for testing purposes.This environment allows us to test if the application built behaves as expected when hosted in Azure. Once the tests are successful, it can be published to the staging environment. In this environment, user-acceptance tests can be done to validate if the application provides the functionality for which it was designed.
In the November 2011 edition, the publishing process was greatly strengthened with the launch of a new publishing wizard.
● Now, Right-click on the Azure project to open the wizard and pick Publish.
● Notice that to right-click on an Azure website, not an ASP.NET MVC project, like a Web Server project. Otherwise the Web Publishing Wizard, and not the Azure Publishing Wizard, will be introduced to deploy the Web.
● When Publishing for the first time it is needed to click on the ‘Sign in to import credentials’ icon on the publish page to download the .publishsettings file.
● The metadata and credentials required for Visual Studio to work with Azure subscription are included in this file.
● The .publishsettings download page will create a Visual Studio Azure Management Certificate and embed it along with your subscription information in the .publishsettings format. When downloaded, all these details will be installed and saved on the local development computer.
Important Note: This file includes very confidential information, such as your subscription ID and certificate of management, so it is better to save the file in a protected location or uninstall it directly after importing it.
Once the file is downloaded to the development machine, it can be imported by using the import button on the first page of the wizard. All of the subscriptions will now turn up in the drop-down box. The good thing about the drop-down box is that security settings can also be handled, such as generating new certificates, renaming credentials, and so on.
● The Publishing Wizard
○ In Publishing Wizard, by clicking the next button it takes us to the common settings tab. This tab helps to pick a current, or even build a new, cloud service.
○ It also gives an option to select which environment to deploy for development or staging and which service setup to use.
○ The multiple service configurations talked earlier, here we can choose which ones to use for deployment.
● Common Settings Tab
○ Remote Desktop and Web deploy can be enabled on this tab as well.
○ Enabling Remote Desktop is very helpful if we have chosen to connect Azure to particular function instances later for diagnostic purposes.
○ If we have agreed to allow Remote Desktop and the deployment has been successfully published, then we can connect directly to the role instance using the “Connect using Remote Desktop” context menu in the Server Explorer instance.
○ The Server Explorer context menu automatically shows menu items depending on the features allowed during the publishing process.
● Connect using Remote Desktop
○ In the Advanced Settings tab of the publishing wizard, there are several helpful settings. In order to prevent performance impacts caused by latency, it is suggested to build or use storage accounts at the same location as the cloud provider using them. Furthermore, Finally, after applying the settings we want to use for publishing, we’ll be taken to the summary page of the wizard.
○ The summary page lists all the configurations that have been made and helps to save a publication target profile.
○ The profile stores the Visual Studio Publish Setup, unlike the cloud configuration. Basically, the target profile is an MSBuild specification file with the .azurePubxml file extension.
○ All the configurations that are added to the Publishing Wizard are contained in that file. This comes in handy, when we have different publication settings or several target environments.\
○ Now, the only thing is needed to pick is the publishing profile for the production environment, instead of running through the wizard again before to submit it to production.This is quite effective with regard to standardizing publishing.
Note: Visual Studio will perform a one-time update of the connection strings for diagnostics and caching in the service configuration file by default with the value for the publish storage account if the value is still UseDevelopmentStorage=true. This behavior can be disabled in the Role Designer by unchecking the “Update development storage connection strings …” checkbox.
Update Development Storage Connection Strings for Diagnostics and Caching
● After successful development, press the Publish button.
● Since it can take some time to publish, it is helpful for Visual Studio to have a comprehensive status on which publishing stage is currently running in the Azure Operation Log window.
● Although the background publishing process manages multiple activities, it still gives a pretty decent idea of which stage is actually being carried out from looking at the publishing status of the Action Log.
● Activity Log window appears after successful publishing.
● We can now browse to our cloud service in the browser by clicking the “Web site URl” in the window.
6. Working with Server Explorer to Access Azure
● While making connections using Remote Desktop to Azure Compute instances and Azure Virtual Machines is a big asset, it’s creditable pointing out some of the other useful aspects in Server Explorer.
● It has an option to connect directly to the Azure Service Bus by providing the namespace and the key for that namespace in jun2012 SDK.
● It has visibility into Service Bus queues and topics when connected. New Service Bus queues and topics can be created as shown in Fig
● Figure Creating a New Service Bus Queue
○ storage accounts to the Azure storage node can be added and have look on stored in the BLOBs and tables. Recently ,only reading the data in Azure storage using Server Explorer is possible.
7. Troubleshooting:
● Along with Windows event log data sources, their is option to add code that collects Azure trace logs, infrastructure logs, crash dumps and so on.
● The main difference in collecting diagnostics data in Azure versus an on-premises application is where the diagnostics data is their.
● Azure stores the diagnostics data in Azure storage . Some diagnostics data, like IIS logs and IIS failed requests, is stored in BLOB storage; remaining data, such as trace logs, performance counters and Windows event logs, is stored in table storage.
● Figure shows a storage account named intellitrace test with BLOB and table storage containing Azure diagnostics data. The BLOBs and tables are easily recognized, as they start with “wad-” or “WAD.”
● Figure Storage Account Containing Diagnostics Data
○ To move the data to the storage, it is main to use the ScheduledTransferPeriod property. The following code shows an example for Windows event logs:
○ XML
○ Copy:diagConfig.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(1.0);
● IntelliTrace is available in the Visual Studio Ultimate editions only.
● Check if the Worker Role in your project started as expected. Reason behind it is there’s some tracing code in the WorkerRole:RoleEntryPoint class, you can use IntelliTrace to debug the RoleenvironmentOnStart event.
● After the publish that is successful, when you right-click on a compute instance in Server Explorer and have IntelliTrace started for the deployment, you get another context menu item saying “View IntelliTrace logs”. Remember that enabling IntelliTrace and Profiling are mutually exclusive .
Visual Studio downloads the logs and displays them when we click on “View IntelliTrace logs” , as shown in Figure .
● Figure Debugging Using IntelliTrace
○ The IntelliTrace window gives good information on the sequence of the events, particular events and exception information. Visual Studio takes you to the appropriate code in the code editor when you click on an event.