Publishing a Cloud Service with options from Visual Studio_Microsoft Azure Development Cookbook Second Edition-QQ阅读男生玄幻网

上QQ阅读APP看书，第一时间看更新

Publishing a Cloud Service with options from Visual Studio

Microsoft Azure always shipped with an SDK for developers and a complementary toolset for Visual Studio integration. In earlier versions of the official SDK, many features were only available through the online portal at https://manage.windowsazure.com. At the time of writing this book, Microsoft released its major SDK update that lets developers quickly manage almost everything of the cloud infrastructure directly from Visual Studio. Hence, it is now simpler to get on Azure and run a Cloud Service compared to the past.

When we publish a Cloud Service into Azure, we should know some foundation concepts in advance, in order to understand the ecosystem better. First, to deploy a Cloud Service, a deployment slot should be created. This could be done through the portal or from Visual Studio, and it consists of creating a DNS name in [myCS].cloudapp.net form. This DNS, under the hood, is linked to a load balancer that actually redirects the Internet traffic to the CS, to each instance of our service, choosing it with a round-robin algorithm. This means that regardless of the topology, we are deploying to Azure in this Cloud Service. Every web endpoint that we are publishing stands behind this layer of balancing to provide the system with transparent scaling capabilities.

During the deployment, we also decide the options that CS should be deployed with:

Production/staging slot
Remote desktop support
Diagnostics collection
Remote debugging
IntelliTrace support
Incremental/simultaneous update

After we perform the deployment, our service, comprehensive of all the roles of the package, as defined in the Setting up solutions and projects to work with Cloud Services recipe, is running in the cloud and is accessible through the DNS name Azure provided us.

Getting ready

For this recipe, we can create a sample solution on the fly by navigating to File | New project | Cloud wizard or using the WAHelloWorld project created earlier.

How to do it…

We are going to see how to deploy a Cloud Service package to the cloud. We can do this by performing the following steps:

Right-click on the Azure wrapper project (WAHelloWorld) and select Publish.
In the Publish Microsoft Azure Application window, click on Sign In to authenticate.
In the browser window, enter the credentials of the Microsoft Account (former Live ID) associated with the Azure account and continue.
In the Choose your subscription dropdown, choose the subscription that will host your service.
If your subscription is empty or it does not contain a Cloud Service, you will be prompted with the Create Microsoft Azure Services window.
Enter a name into the Name box, and choose a location for your service.
In the Cloud Service dropdown, choose the Cloud Service to which you want your service to be deployed.
In the Environment dropdown, choose Production.
In the Service configuration dropdown, choose Cloud.
In the Build configuration dropdown, choose the correct build configuration, according to the ones available in your service (in the WAHelloWorld example, choose Release).
Note
Configuring the remote desktop is optional.
Check on the Enable Remote Desktop for all roles checkbox.
In the Remote Desktop Configuration window, specify a username, a password, and a date for account expiration. Then, click on OK.
Tip
Using RDP on Microsoft Azure is not recommended due to the nature of PaaS services. It is recommended that you use it only for dev/test purposes and rely on external or active monitoring to troubleshoot and resolve issues.
Note
The advanced settings tab is optional.
Specify WAHelloWorld Version 1 in the Deployment label box.
Leave the Append current date and time checkbox unchecked.
If your subscription is empty or it does not contain a storage account, you will be prompted with the Create Microsoft Azure Services window.
Enter a name into the Name box, and choose a location for your service.
In the Storage account dropdown, choose the storage account where Visual Studio will upload the package file, letting Azure deploy it from the Blob storage.
Uncheck every checkbox except the Deployment update one, then click on Settings.
In the Deployment settings window, select Incremental update.
Check the If deployment can't be updated, do a full deployment checkbox and confirm.
Note
Conclusion.
Next, in the Summary page of the wizard, check all the information and then save your publish profile file.
Click on Publish.
After few or several minutes (it depends on the size of your deployment), check the Microsoft Azure Activity Log tab in VS for completion of the deployment process.
At completion, if your service has a role with a valid HTTP endpoint, navigate to it at http://[nameOfCloudService].cloudapp.net.

How it works…

Up to step 3, we link VS with our Microsoft Account (formerly, Live ID). As a Microsoft account could be the administrator and co-administrator of multiple Azure subscriptions at the same time, after the authentication, the dropdown mentioned in step 4 could be a pretty long list of entries.

In step 5, we create a Cloud Service on the Azure platform; this means that we create the deployment slots (one for production, one for staging) to run our service. Every time we create a service in the Azure platform, we must cope with the localization of the service, in terms of the choice of a datacenter. There are actually about 13 datacenters, plus one in China:

Europe North: Ireland
Europe West: Netherlands
US Central: Iowa
US East: Virginia
US East 2: Virginia
US West: California
US North Central: Illinois
US South Central: Texas
Asia Pacific East: Hong Kong
Asia Pacific Southeast: Singapore
Japan East: Saitama Prefecture
Japan West: Osaka Prefecture
Brazil South: Sao Paulo State
Tip
Two new datacenters in Australia have also been announced, but not yet released to the public.

In steps 7 and 8, we chose which slot to use for deployment and which configuration to publish for it. For each new Cloud Service project, VS creates two service configuration files: a local one and a cloud one.

In step 9, we choose the build configuration. This step is related to the actual build settings of our solution. In the new solution, there are just two configurations (debug/release), but the list could be longer according to real-life projects and complexity.

In steps 10 and 11, we configured the remote desktop. Though this is not recommended, this could let us connect to each instance to troubleshoot any issues and master the OS configuration of an Azure Virtual Machine image. Due to security implications in this process, a self-signed certificate is generated automatically to establish the TLS connection. It is also possible to provide our own valid certificate by clicking on More Options in the Remote Desktop Configuration window.

Tip

We learned that in Azure, we have many instances behind a single load balancer (therefore, a single IP) to RDP the instances we must proceed one-by-one with different combinations of ip:port.

Steps 12 and 13 were straightforward. They indicated the name of the deployment for further administrative tasks.

In steps 14 and 15, we chose a storage account. As we never talked about this feature earlier in the book, just keep in mind that a Cloud Service could be connected to a storage account to provide it with logging and diagnostics data.

From steps 16 to 18, we set up the options for update. As Azure could have a previous online version of our service, we had to decide how to manage the update. By unchecking the Deployment update checkbox, we completely bypassed the update process, telling Azure to delete the old deployment because a new one was going to arrive. Otherwise, we can specify how to update the service, gracefully (incremental update) or suddenly (simultaneously update). In the incremental update, Azure updates a service instance by instance, theoretically without service interruption. On the other hand, Azure updates every instance at the same time, causing an interruption of the service. In some cases, a deployment could not be updated. If this is the case, then perform a delete-and-replace operation.

In step 19, we saved the publish settings to use them later, thus avoiding repeating all the steps, by directly clicking on Publish from the summary pane. In step 21, we recognized the VS-integrated progress window, refreshed periodically from an Azure service. We can also use it to stop/cancel pending operations, as it reflects the portal operations.

There's more…

If we checked the Enable Remote Desktop for all roles checkbox during the publishing process, it is possible to connect to each instance directly from Visual Studio using the following steps:

Locate the Microsoft Azure node in the Server Explorer.
Locate the Cloud Services subnode and the Cloud Service you want to connect to (in the example, WAHelloWorld).
Expand the node, and select the production or staging deployment.
Expand the node and the role of interest; it will show a list of the deployed instance.
Tip
This list, as for the list of Cloud Services and related roles, could depend on the actual running configuration of your service. Remember that a Cloud Service can contain many roles, and each role can have many instances.
Right-click on the selected instance (from instance 0 to instance "N"), and choose Connect using Remote Desktop….
Confirm the settings in the Remote Desktop Connection window and enter the VM. If prompted with a credential set (in most cases, only for the password), type the ones you gave in the publishing process.
You are now connected to a real running instance of Azure.
Tip
While connected to the real instance of Azure, you can poke around the OS, observing the following:
- The filesystem topology (the C: / D: / E)
- The virtualized hardware (processor, RAM, and so on)
- The network settings (internal IP, gateway, and so on)

We cannot actually rely on the information we gain by browsing the VM, as it is subject to change frequently without control by the user.