A. Before you create a cloud service project, you have to know which web and worker roles you will include in the cloud service solution.
B. The only way to create a worker role that listens to a Service Bus queue is to select the role template while creating the cloud service project.
C. You must provide an implementation for the RoleEntryPoint when creating a worker role.
D. Web.config settings do not work with web roles. You have to use cloud service configuration settings.
3. Which of these is true about startup tasks? (Choose all that apply.) A. Simple tasks run before the role starts processing requests.
B. Foreground tasks run before the role starts accepting requests.
C. Background tasks run before the role starts accepting requests.
D. A startup task can interact with the RoleEnvironment object.
Objective 3.2: Configure cloud services and roles
Even though the PaaS aspects of Cloud Services shield you from having to manage lower level server details, Cloud Services and Roles are feature rich and highly configurable. This section examines the configuration of key items from networking, storage, scaling, and caching.
This objective covers how to:
■
■ Configure instance size and count
■
■ Configure auto-scale
■
■ Configure cloud service networking
■
■ Configure HTTPS and upload an SSL certificate
■
■ Configure local storage
■
■ Configure multiple websites in a web role
■
■ Configure custom domains
■
■ Configure caching
Configuring instance size and count
Similar to websites and VMs, you can scale cloud service roles both in terms of instance size and instance count, and you can use auto-scale for the instance count.
Scaling role instance sizes
Role instance sizes can be scaled up or down to alter the capacity of the VM supporting the instance. For each role instance, scaling collectively adjusts:
■
■ The size of the local temp disk
■
■ The number of CPU cores available
■
■ The amount of RAM memory available
■
■ The network performance
Unlike websites and VMs, whose instance size can be adjusted through the management portal, scaling the instance size of a role instance requires that you change the cloud service definition and re-deploy the package, as described in the following steps.
1. Open your cloud service project in Visual Studio.
2. In Solution Explorer, locate and double-click the role to display the properties page.
3. On the Configuration tab, from the VM Size drop-down list, select the desired VM size for instances in the role.
4. Save your solution.
5. Publish your solution.
When the deployment completes, instances of the affected role should be running on the new instance size.
Scaling role instance count
The role instance count can be scaled using the existing management portal or by adjusting the count in the cloud service configuration and re-deploying.
ADJUSTING ROLE INSTANCE COUNT (EXISTING PORTAL)
To adjust the role instance count using the management portal, complete the following steps:
1. Navigate to the management portal accessed via https://manage.windowsazure.com.
2. Navigate to the cloud service containing the role you want to scale and click the Scale tab.
3. Scroll down to the role you want to scale, and use the Instance Count slider to adjust the value for the desired number of instances.
4. Click Save on the command bar.
Objective 3.2: Configure cloud services and roles CHAPTER 3 187 ADJUSTING ROLE INSTANCE COUNT (PREVIEW PORTAL)
Adjusting role instance count is not currently possible using the Preview portal.
ADJUSTING ROLE INSTANCE COUNT IN VISUAL STUDIO
To adjust the role instance count in Visual Studio, complete the following steps:
1. Open your cloud service project in Visual Studio.
2. In Solution Explorer, locate and double-click the role to display the properties view.
3. On the Configuration tab, in the Instance Count text box, supply the number of instances.
4. Save your solution.
5. Publish your solution.
When the deployment completes, the number of instances requested will be deployed behind the load balancer. This will also be reflected in the Instance Count slider mentioned previously.
Configuring auto-scale
Auto-scale for Cloud Services automatically adjusts the number of instances running within a role based on load or according to a schedule. It does this by provisioning additional instances in the role during a scale-up event, and de-provisioning them during a scale-down event.
Auto-scale is configured at the level of the role within a cloud service, much like it is config- ured at the level of the web hosting plan for websites or at the availability set level for VMs.
Auto-scale can be configured to make scaling decisions based on a schedule (predefined or custom schedules are supported) or with respect to the queue depth of an Azure Storage queue or Service Bus queue.
Configuring role auto-scale (existing portal)
To configure role auto-scale using the management portal, complete the following steps:
1. Navigate to the management portal accessed via https://manage.windowsazure.com.
2. Navigate to the cloud service containing the role you want to scale and click the Scale tab (as shown in Figure 3-5).
FIGURE 3-5 The scale tab for a cloud service in the management portal
3. To configure auto-scale to operate according to a schedule, complete the following steps, click Set Up Schedule Times, and, in the dialog box that appears, do one or more of the following to define the schedule:
A. To enable the day/night recurring schedule, select Different Scale Settings For Day And Night, and then use the Day Starts, Day Ends, and Time Zone drop-down lists to specify what hours are considered day time. (Azure will infer the remaining hours are night time.)
B. To enable the weekdays and weekends recurring schedule, select Different Scale Settings For Weekdays And Weekends, where weekdays are defined as Monday morning through Friday evening and weekends are Friday evening through Mon- day morning. You can adjust the time that is used for morning and for evening by using the Day Starts, Day Ends, and Time Zone drop-down lists.
C. Enable specific data ranges by filling in the grid below Specific Dates. Specify a user-friendly name for the date range, a start date and time, and an end date and time. You can add multiple date ranges as long as they do not overlap.
4. When you are finished defining schedules, click the check mark to make these sched- ules configurable on the Scale tab. Return to the Scale tab and complete the following steps:
A. From the Edit Scale Settings For Schedule drop-down list, select the schedule you want to configure.
Objective 3.2: Configure cloud services and roles CHAPTER 3 189 B. Use the Instance Count slider to adjust the number instances to the target number
your role should have during that schedule.
C. Repeat the previous two steps as necessary for any other schedules you have defined.
D. Click Save to save both the newly defined schedules and your instance count con- figurations for each schedule.
5. To scale by CPU, complete the following steps:
A. Click the Scale By Metric toggle key to select CPU.
B. Using the Target CPU slider, specify the lower threshold below which scale-down actions should be taken. You can do this by entering a value in the left-most text box or by dragging the left-most slider handler.
C. Repeat the previous step to define the threshold for the scale-up action, using the right-most text box or slider handle to adjust the threshold.
D. Using the Instance Range slider, define the minimum and maximum number of instances that auto-scale can reach at any point in time.
E. Use the Scale Up By slider to specify the number of instances to add at one time, and select a cool-off period to wait after scaling up from the Scale Up Wait Time drop-down list.
F. Similarly, configure the number of instances to scale down by using the Scale Down By and Scale Down Wait Time controls.
G. Click Save to apply your auto-scale by metric rules.
6. To scale by queue depth, complete the following steps:
A. Click the Scale By Metric toggle to select Queue.
B. Using the Instance Range slider, define the minimum and maximum number of instances that auto-scale can reach at any point in time.
C. Select the Storage Account and Queue Name (for an Azure Queue) or Service Bus Namespace and Queue Name (for a Service Bus Queue) to monitor queue depth.
D. In Target Per Machine, specify the target number of messages that Azure will scale to support per VM.
E. Using the Scale Up By slider, specify the number of instances to add at one time, and select a cool-off period to wait after scaling up from the Scale Up Wait Time drop-down list.
F. Similarly, configure the number of instances to scale down by using the Scale Down By and Scale Down Wait Time controls.
G. Click Save to apply your auto-scale by metric rules.
7. Also note that you can combine schedule-based and metric-based scaling. When you define a schedule and then select it from the Edit Scale Settings For Schedule drop- down list, you can configure scaling by CPU or by queue conditions within the time- frame represented by that schedule.
Configuring role auto-scale (Preview portal)
Auto-scale cannot currently be configured using the Preview portal.
Configuring role auto-scale using Windows PowerShell
Auto-scale cannot currently be configured using Windows PowerShell.
Configuring cloud service networking
Cloud service roles offer many mechanisms for controlling communication between Internet traffic and the role instances and between role instances.
Understanding cloud service endpoint types
Cloud service roles can be configured to expose one of three types of endpoints:
■
■ Input endpoint Controls the transport protocol (http, https, tcp, or udp) and port used by traffic coming from the Internet to instances of the role. When accessed this way, the Azure load balancer determines which role instance will receive a particular request. The IP address used to communicate with this endpoint is the virtual IP (VIP) of the cloud service, and the role instance to which the traffic goes will see the traffic on the configured localPort number or on the one assigned automatically by the Azure fabric controller if a localPort is not provided.
■
■ InstanceInput endpoint Defines a specific protocol (tcp or udp) and port that when used by Internet traffic goes via port forwarding directly to a specific role instance. The IP address used to communicate with this endpoint is the VIP of the cloud service.
■
■ Internal endpoint Configures a protocol (http, tcp, udp, or any of the aforemen- tioned) and a dynamically allocated public port range that can be used for commu- nication between roles and role instances within a cloud service. The IP address used to communicate with this endpoint is the internal IP address assigned to each role instance, and the role instance to which the traffic goes will see the traffic on the con- figured private port.
Configuring HTTPS endpoints
HTTPS endpoints enable you to secure traffic between the public Internet and your role instances via transport layer security (TLS) by using a certificate (often mislabeled as a stan- dard SSL certificate) that you either generate yourself (in the dev/test scenario) or that you purchase from a certificate authority (in the production scenario). The process has four main tasks. First, you need to acquire a certificate. Second, you need to convert the certificate into the PFX format by exporting it from the keystore. Third, you need to upload the certificate to
Objective 3.2: Configure cloud services and roles CHAPTER 3 191 the certificate store used by your cloud service. Fourth, you need to configure an endpoint in
your role that uses the HTTPS protocol and is configured to use the certificate to secure the traffic. The following sections cover each of these tasks.
ACQUIRING A CERTIFICATE
You can acquire a certificate from a certificate authority, such as GoDaddy, Thawte, or Verisign. The process for creating a certificate request and submitting it the certificate au- thority varies by vendor, and you should follow vendor instructions. However, also creating a self-signed certificate while you develop your solution offers an opportunity to become familiar with how HTTPS endpoints are configured. The steps that follow show how to create a self-signed certificate using the makecert tool that is installed with the Windows SDK (and with Visual Studio).
1. Open the command prompt and be sure to run it as an administrator.
2. Navigate to the Windows SDK you have installed on your machine. If you have Visual Studio, you will have one of the following folders with the corresponding SDK version installed. Look for makecert.exe in the corresponding SDK folder shown here:
A. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin (win7 SDK) B. C:\Program Files (x86)\Windows Kits\8.0\bin\x64 (win8 SDK)
C. C:\Program Files (x86)\Windows Kits\8.1\bin\x64 (win8.1 SDK) 3. At the command prompt, run the following command:
makecert -sky exchange -r -n “CN=<SubjectName>” -pe -a sha1 -len 2048 -sr LocalMachine -ss My “<PathTo>\<SubjectName>.cer”
In the above command, substitute <SubjectName> with a string representing the name you will use for the certificate. (In production certificates, this is your domain name, but for self-signed certificates, this value has little meaning beyond a label.) For the final parameter, provide a path for the makecert utility to write the certificate to disk. Be sure to retain the .cer extension.
This command will both create the *.cer file at the location you specified and add it to your Local Machine\Personal keystore. This latter step makes selecting the certificate within Visual Studio more convenient.
CONVERTING THE CERTIFICATE TO PFX
Before you can upload the certificate to Azure, you need to export it in the PFX format that Azure expects.
1. From the Start menu, run mmc to open an empty Microsoft Management Console.
2. From the File menu, select Add/Remove Snap-In.
3. The Add Or Remove Snap-ins dialog box opens as shown in Figure 3-6. Under Avail- able Snap-ins, click Certificates, and then click Add to open the certificates snap-in wizard.
FIGURE 3-6 The Add or Remove Snap-Ins dialog box
4. On the first page of the wizard, click Computer Account, and then click Next.
5. On the next page, leave the options unchanged and click Finish.
6. In the Add Or Remove Snap-ins dialog box, click OK.
7. In the Microsoft Management Console, expand the Certificates node in the navigation pane. The certificates are listed as shown in Figure 3-7.
FIGURE 3-7 Certificates listed under the Personal folder 8. Expand Personal, and then click Certificates.
Objective 3.2: Configure cloud services and roles CHAPTER 3 193 9. Right-click the certificate you just created and select All Tasks, Export.
10. Click Next on the first wizard page.
11. On the Export Private Key page, select Yes, Export The Private Key, and then click Next.
12. On the Export File Format page, click Next.
13. On the Security page, select the Password check box and enter a password to secure access to the certificate. You will use this password when you upload the certificate to Azure. Click Next.
14. On the File To Export page, browse to the path where you would like to save the PFX certificate. Click Next.
15. Click Finish on the summary page to create your certificate in the PFX format.
UPLOADING THE CERTIFICATE
To upload the PFX certificate, complete the following steps.
1. Navigate to the existing portal accessed via https://manage.windowsazure.com.
2. If you have not already created a cloud service that will support your deployment, click New on the command bar, and select Compute, Cloud Service, and then Quick Create.
3. When your cloud service is created, navigate to it and click the Certificates tab.
4. On the command bar, click Upload.
5. In the dialog box that appears (as seen in Figure 3-8), browse to select the PFX file you just created, and enter the password you used to secure it. Click the check mark to upload the certificate.
FIGURE 3-8 The Upload Certificate dialog box
CONFIGURING THE ROLE
The final tasks are to associate the certificate with the role and configure an HTTPS endpoint that uses that certificate.
1. Open your cloud service in Visual Studio.
2. In Solution Explorer, double-click the role to open the properties view.
3. Click the Certificates tab.
4. Click Add Certificate. A row is added to the grid on the page.
5. In the row that appears, provide a name for the certificate and leave the Store Location and Store Name options as Local Machine and My, respectively.
6. In the Thumbprint box, click the ellipses to open a dialog box that lists the certificates present in the Local Machine\Personal keystore (as shown in Figure 3-9).
FIGURE 3-9 The Select A Certificate dialog box
7. Select the certificate that you created, and click OK.
8. Click the Endpoints tab.
9. Click Add Endpoint. A row will be added to the grid on the page.
10. In the row that appears, provide a name for the endpoint, select Input as the type, en- ter HTTPS for the protocol, and enter 443 for the public port and private port. Finally, from the SSL Certificate Name drop-down list, select the name of the certificate you just added.
11. Save your solution.
12. Deploy your cloud service. When the deployment completes, you should be able to access your role using the HTTPS endpoint.
Objective 3.2: Configure cloud services and roles CHAPTER 3 195 IMPORTANT CERTIFICATE ERRORS IN THE BROWSER
If you used a self-signed certificate, attempting to access your role using a browser may generate browser warnings about the certificate not being trusted. That is okay during development; most browsers should allow you to move past the warning. Of course, in production, use a certificate acquired from a certificate authority so that visitors do not receive those warnings.
Configuring network traffic rules
Network traffic rules are configured to control or restrict how internal communication be- tween roles within a cloud service happens, effectively dictating which roles are allowed to communicate with the internal endpoints of another role within a cloud service.
Network traffic rules are best explained by example. Assume you have a cloud service with two worker roles, and you want WorkerRole2 to be accessible only from WorkerRole1, but you want WorkerRole1 to be accessible to WorkerRole2 plus any future roles you might add to the cloud service. Assuming you have defined an HTTP internal endpoint on each role, you can configure the service definition (the *.csdef) as follows:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition …>
<WorkerRole name="WorkerRole1" vmsize="Small">
<Imports>…</Imports>
<Endpoints>
<InternalEndpoint name="httpInternal" protocol="http" port="8080"/>
</Endpoints>
</WorkerRole>
<WorkerRole name="WorkerRole2" vmsize="Small">
<Imports>…</Imports>
<Endpoints>
<InternalEndpoint name="httpInternal" protocol="http" port="8080"/>
</Endpoints>
</WorkerRole>
<NetworkTrafficRules>
<OnlyAllowTrafficTo>
<Destinations>
<RoleEndpoint roleName="WorkerRole2" endpointName="httpInternal" />
</Destinations>
<WhenSource matches="AnyRule">
<FromRole roleName="WorkerRole1" />
</WhenSource>
</OnlyAllowTrafficTo>
<OnlyAllowTrafficTo>
<Destinations>
<RoleEndpoint roleName="WorkerRole1" endpointName="httpInternal" />
</Destinations>
<AllowAllTraffic/>
</OnlyAllowTrafficTo>
</NetworkTrafficRules>
</ServiceDefinition>