Date post: | 01-Jan-2016 |
Category: |
Documents |
Upload: | rodney-lang |
View: | 225 times |
Download: | 0 times |
Why Do We Have Startup Tasks?
Sometimes setup is required before execution
“At the top of the code” isn’t good enoughElevated startup task, non-elevated roleScripting often easier than C#Reusable startup tasks
“Upload a VHD” is overkillOften just need to run an MSI, unzip filesWant full PaaS experience, including patchingVM images aren’t very reusable
Startup Task Options
Defined in ServiceDefinition.csdef
Can run elevated or not
Three execution modes:
synchronous asynchronous, block shutdown
asynchronous, don’t block shutdown
Startup Task Tips
Log everything:command >> %~dp0log.txt 2>> %~dp0err.txt
/y everything:copy /y foo barecho y| cacls … [Note no space after “y”]
Use local storage (guaranteed space)
Reboots are fine, but don’t enter an infinite loop
Use “psexec -s” to test (“local system” is a weird user)
Consider “exit /b 0”
When Not To Use Startup Tasks
Long, manual, or fragile installationsUse VM Role
Things that require the IIS pool to exist alreadyUse OnStart() in an elevated web role
Processes that need to be monitored (for the most part)Easier to write proc.Start();proc.WaitForExit();
Elevated Privileges for the Role
Entire role can run elevated
<Runtime executionContext="elevated" />
For web roles, doesn’t affect web app (IIS)
ServiceDefinition.csdef:<NetworkTrafficRules>
<OnlyAllowTrafficTo><Destinations>
<RoleEndpoint endpointName="ServiceEndpoint"roleName="WorkerRole1" />
</Destinations><WhenSource matches="AnyRule">
<FromRole roleName="WebRole1" /></WhenSource>…
Punchline: When to Use VM Role
Error-prone application installations
Long running application installations
Application installations requiring manual interaction
1
2 A Windows Azure application runs multiple instances of each role
3 A Windows Azure application behaves correctly when any role instance fails
WA Programming Model: Three Rules
Windows Azure Application Platform
Automated, Consistent Application Updates
Automated, Consistent Configuration Changes
Multi-Instance Management Scale-out
High Availability Automated, Consistent OS Servicing
Platform Capabilities and App ContractStateless ImagesConsistent updatesConsistent configurationMulti-instance management
Multiple InstanceScale-outHigh Availability
Not all applications can be migrated!
Automated, Consistent Application Updates
Automated, Consistent Configuration Changes
Multi-Instance Management
Scale-out
High Availability
VM Role Doesn’t Mean Single-InstanceRule #2: A Windows Azure application runs multiple instances of each role
No high-availability without multiple instances
VM Role Doesn’t Mean “Stateful”
Rule #3: A Windows Azure application behaves correctly when any role instance fails
Running a database? Think about how the data is replicated
The Tradeoff
VM roles and web/worker roles can do the same things
We’re back to the two differences:Who handles OS servicingHow you package/deploy your application
To choose, consider:Development cost/effortOperating cost (OS maintenance)VM startup timeSkills/resources available
© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION
IN THIS PRESENTATION.