Tải bản đầy đủ
Objective 5.2: Choose a deployment strategy for Windows Azure web applications

Objective 5.2: Choose a deployment strategy for Windows Azure web applications

Tải bản đầy đủ

Windows Azure offers you three ways to update your application:
■■

Delete and redeploy

■■

In-place update

■■

VIP Swap

Deleting your cloud service and redeploying it is easy, but it requires downtime for your
service. You need to use the delete and redeploy option when you want to change the number of endpoints or the ports of endpoints. Any effective firewall changes require a delete
and redeploy strategy. The same is true for updating certificates and migrations to another
guest operating system. For other changes, you can use a VIP Swap or an in-place update,
which doesn't require any downtime.

Configuring an upgrade domain
When you perform an in-place upgrade, Windows Azure stops the instances, updates them,
and then brings them back online. Windows Azure doesn’t stop all instances at once. Instead,
it stops instances that are assigned to the same upgrade domain.
When Windows Azure creates new services in a cloud service deployment, they are automatically assigned to an upgrade domain. When updating your service, Windows Azure cycles
through your update domains and takes them offline one by one. This way, you won’t have
any downtime on your service.
If you look at the instance tab in your Management Portal, you can see the instances and
the update and fault domains they are assigned to (see Figure 5-5).

FIGURE 5-5  Instance settings in Windows Azure Management Portal

A fault domain is automatically assigned by Windows Azure. You need at least two instances spread across two fault domains to have maximum availability guaranteed by Windows
Azure.
By default, you have a maximum of five update domains. You can control how many upgrade domains you have by using the upgradeDomainCount attribute in your ServiceDefinition configuration file. You can have a maximum of 20 upgrade domains.
You can update your cloud service from the Windows Azure Management Portal or from
Visual Studio. To update from Visual Studio, you have to upload a certificate to Windows
Azure that associates your computer with your online subscription. Figure 5-6 shows the New
Subscription dialog box for creating a new subscription in Visual Studio.



Objective 5.2: Choose a deployment strategy for a Windows Azure web application

CHAPTER 5

375

FIGURE 5-6  Creating a new Windows Azure subscription in Visual Studio

You can also log in to the Windows Azure Management Portal and upload a package
directly to your cloud service.
While your in-place upgrade runs, your upgrade domains are updated one by one. This
means that if you have more than two upgrade domains, different upgrade domains run a
different version of your application at the same time. This is something you need to take
into account. If, for example, your database schema also changed, you can get runtime errors
when your old instances are trying to access the database. To overcome this problem, you can
use a different technique called VIP Swap.

Upgrading through a VIP Swap
A Windows Azure cloud service has two environments: production and staging. Both environments offer the same hardware, but they have different virtual IP (VIP) and service URLs. Because the staging and production environment are identical, you can perform what’s known
as a VIP Swap.
When you execute a VIP Swap, the VIP and service URL of your staging and production
environment are switched. This means that you can upload a new version of your app to the
staging environment, test it, and then bring it into production by executing a VIP Swap. For
uploading your new version to the staging environment, you still have to use the in-place
upgrade or the delete and redeploy strategy.
After your VIP Swap is finished, you have both production and staging environments that
use resources (and thus cost you money). To avoid extra costs, you can delete the staging
environment (which is the old production environment) after your VIP Swap is finished.

376

CHAPTER 5

Deploying web applications and services

A VIP Swap enables you to bring a complete set of instances into production at once,
avoiding different versions in production. However, in the practice it could be that existing
connections persist for some time. This connection still points to the old deployment. This is
something you should keep in mind when doing a VIP swap.
You execute a VIP Swap by uploading your updated project to the staging environment. If
you then navigate to the Windows Azure Management Portal, make certain that your staging instances are running. You can then click the Swap button on your staging cloud service
deployment (see Figure 5-7).

FIGURE 5-7  Swap option in the Windows Azure Management Portal

If you need to make changes to the service definition (such as number of endpoints, endpoint ports, or certificates), you need to use a VIP Swap (or redeploy your service). If there are
no changes to the service definition, you can use the in-place update to update your staging
environment.

Creating and configuring input and internal endpoints
Your cloud services in Windows Azure communicate with the outside world and with each
other. Windows Azure helps you secure your roles by using strict rules that are enforced by
settings in the firewall and in the operating system that hosts your role.
You can use both input endpoints and internal endpoints. An input endpoint is used for
external connections to your role. These connections can be made over HTTP, HTTPS, or TCP.
Internal endpoints are used for communication between the roles in the datacenter in which
they are located. These internal endpoints can use HTTP and TCP.


Objective 5.2: Choose a deployment strategy for a Windows Azure web application

CHAPTER 5

377

When using input endpoints, you declare a unique port on which you want your role to
listen. This port is used by the load balancer of Windows Azure to connect your role to the
Internet. Your service can have 25 input endpoints defined, which can be distributed across
your different roles. You can also declare 25 internal endpoints.
You declare a new internal or external endpoint in the ServiceDefinition.csdef file in your
cloud project. When you create a new cloud project with one web role and one worker role,
the file looks like this:
























NOTE  MULTIPLE ROLES IN ONE CLOUD PROJECT AID

When using a cloud project you can add multiple roles to one single project—for example,
a web role that’s public for your users and a worker role that’s internal and does all the
processing. Those projects can be deployed together and form one single cloud project.

MORE INFO  SERVICEDEFINITION SCHEMA

For a complete description of the ServiceDefinition schema, see http://msdn.microsoft.com/
en-us/library/windowsazure/ee758711.aspx.

The web role has one input endpoint defined. This is the default endpoint that listens to
port 80, the default port for HTTP traffic.

378

CHAPTER 5

Deploying web applications and services

The worker role has no endpoints declared. You can add an input endpoint by adding the
following XML to the WorkerRole element:




Now the load balancer forwards any incoming requests to port 8080 to your role. One
thing to note is that when working with the local Windows Azure emulator, ports are remapped to avoid conflicts. The emulator takes the first port that’s available on your local PC.
This means that port 80 will be remapped to 81 (if it’s not in use) and 8080 to 8081.
Inside your worker role, you can now use an HTTPListener to listen for incoming requests:
public override void Run()
{
HttpListener listener = new HttpListener();
listener.Prefixes.Add("http://*:8081/");
listener.Start();
while (true)
{
HttpListenerContext context = listener.GetContext();
HttpListenerRequest request = context.Request;
HttpListenerResponse response = context.Response;
string responseString = " Hello world!";
byte[] buffer = System.Text.Encoding.UTF8.GetBytes(responseString);
response.ContentLength64 = buffer.Length;
System.IO.Stream output = response.OutputStream;
output.Write(buffer, 0, buffer.Length);
output.Close();
}
}

This code creates an instance of the HttpListener class and starts it to listen to port 8081.
You then use the GetContext method to wait for an incoming request. When a request arrives, a string with an HTML page containing the words Hello World! is written. If you run this
code and navigate to http://127.0.0.1:8081 in your browser, you will see the text Hello World!
returned from your worker role.
You can also edit the endpoint configuration of your project by using the editor in Visual
Studio. Open the editor by double-clicking the name of your role in your cloud services project. You can see what the endpoints look like in Figure 5-8.



Objective 5.2: Choose a deployment strategy for a Windows Azure web application

CHAPTER 5

379

FIGURE 5-8  Editing endpoints in the Visual Studio editor

To select an input or internal endpoint, you can also choose the option of an
InstanceInputEndpoint, also called direct ports. This way, you can use a range of ports on your
public IP address that are then mapped to a port on your role instances. You define a direct
port like this:






The parent element specifies the local port you want to use on your roles and the protocol. The AllocatePublicPortFrom element then specifies a range of ports that you want to use
publicly.
MORE INFO  CONFIGURING DIRECT PORTS

For more information on how to configure direct ports, see http://msdn.microsoft.com/
en-us/library/windowsazure/dn127053.aspx.

Specifying operating system configuration
The ServiceDefinition.csdef file specifies settings that are used to configure a complete cloud
service. You can also configure settings for your specific roles.
You do this by using the ServiceConfiguration.cscfg files. There are two versions of this file:
one for your local development emulator and one when you deploy to the cloud. In this file,
you can configure how many instances you want for each role, configuration settings for your
diagnostics, and other things such as certificates.

380

CHAPTER 5

Deploying web applications and services

You can also specify the version of your operating system that you want to use in Windows
Azure. If you create a new cloud project with one web role and one worker role, you get the
following ServiceConfiguration file for the cloud deployment:

xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"
osFamily="3" osVersion="*" schemaVersion="2013-03.2.0">



"UseDevelopmentStorage=true" />





"UseDevelopmentStorage=true" />




At the top-level element, you see settings for osFamily and osVersion.
The osFamily attribute can be one of the following values:
■■

Specifies the OS family that is substantially compatible with Windows Server 2008 SP2.
This Guest OS family retiring began on June 1, 2013, and will complete on June 1, 2014.
You should not use this OS to create new installations.

■■

Specifies the OS family that is substantially compatible with Windows Server 2008 R2.

■■

Specifies the OS family that is substantially compatible with Windows Server 2012.

The osVersion attribute is used to specify the version of the guest OS that your role should
run. You can set this value to * if you want to run on the newest version. This enables automatic upgrades and is a recommended best practice. You can also enter a specific version
manually. You are then responsible for changing this value to update to later versions. Your
version should follow the following format:
WA-GUEST-OS-M.m_YYYYMM-nn

Where:
■■

WA-GUEST-OS is a fixed string.

■■

M.m refers to the major and minor versions.

■■

YYYY refers to the year.

■■

MM refers to the month.

■■



nn serves as a sequence number to differentiate between releases, which typically
supersede previous releases.

Objective 5.2: Choose a deployment strategy for a Windows Azure web application

CHAPTER 5

381

MORE INFO  GUEST OS CONFIGURATION

For a list of all available Windows Azure Guest OSs, see http://msdn.microsoft.com/en-us/
library/windowsazure/ee924680.aspx.

Thought experiment 
Updating your cloud service
In this thought experiment, apply what you’ve learned about this objective. You can
find answers to these questions in the “Answers” section at the end of this chapter.
Your company distributes a cloud service with multiple worker and web roles. A new
update will soon be available, and you are considering the different options you
have for updating the cloud service.
With this in mind, answer the following questions:

1. What is the difference between VIP Swap and in-place upgrade?
2. Which one do you prefer? Why?

Objective summary
■■

■■

■■

■■

■■

382

There are three different ways of updating your cloud service: delete and redeploy, inplace update, and VIP Swap.
An in-place upgrade means that Windows Azure will update your instances according
to the upgrade domain they belong to. This can lead to running multiple versions of
your service at the same time.
A cloud service can be deployed to both a staging and a production environment. A
VIP Swap brings your staging environment into production and your production environment to staging.
Your roles can have internal and external endpoints. You define these endpoints in
your ServiceDefinition.csdef file.
In the ServiceConfiguration.cscfg file, you can configure settings such as the number of
instances you want for each role. You can also configure which operating system you
want to run on.

CHAPTER 5

Deploying web applications and services

Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is
correct or incorrect in the “Answers” section at the end of this chapter.
1. You are deploying a new cloud service with only a web role, and you want to make

sure that you get the maximum guaranteed uptime, even during upgrades. How many
instances do you need?
A. 1
B. 2
C. 3
D. 4
2. You want to be able to communicate directly from your web role to your worker role,

and you want to make sure that your worker role stays secure by disallowing public
access. What do you do?
A. Add an InputEndpoint to the web role in your ServiceConfiguration.cscfg file.
B. Add an InputEndpoint to your worker role in your ServiceConfiguration.cscfg file.
C. Add an InternalEndPoint to the web role in your ServiceConfiguration.cscfg file.
D. Add an InternalEndPoint to your worker role in your ServiceConfiguration.cscfg file.
3. You want to follow the recommended best practices for configuring your Windows

Azure Guest OS. Which values do you use? (Choose all that apply.)
A. osFamily=”3”
B. osFamily=”1”
C. osVersion=”*”
D. osVersion=”WA-GUEST-OS-2.12_201208-02”

Objective 5.3: Configure a web application for
deployment
When deploying your application, there are a couple of things you can already configure in
your development environment. You can make sure, for example, that the correct settings are
used for things like your database connection or WCF configuration.
This objective covers several different ways to prepare your application for deployment, including an on-premises environment or on Windows Azure. You need to know both of these
configurations for the exam.



Objective 5.3: Configure a web application for deployment

CHAPTER 5

383

This objective covers how to:
■■

Switch from production/release mode to debug mode

■■

Transform web.config by XSLT

■■

Use SetParameters to set up an IIS app pool

■■

Configure WCF endpoints, bindings, and behaviors

■■

Configure Windows Azure configuration settings

Switching from production/release mode to debug
When building your projects, you use a build configuration. Two configurations are declared
by default: release and debug. For the exam, you should know the differences between these
configurations and the scenarios in which they should be used.
In release mode, your code is optimized for running as fast as possible. Of course, this is
something that you want to use when your code is deployed to your production server.
However, release mode is not handy when you are debugging your applications. When
you compile an application in debug mode, extra instructions are added to your compiled
code. This ensures that debugging is supported, and that you can easily step through your
code with a debugger.
In addition to your build configuration, there is also a debug switch in your web.config file:






By setting this value to false, you turn debug mode off.
In Visual Studio, you also have an option to select which debuggers you want to load when
debugging your project, as you can see in Figure 5-9.

384

CHAPTER 5

Deploying web applications and services