Deployment Slots Flashcards
1
Q
What tiers support deployment slots?
A
- standard, premium and isolated
- different pricing tiers support different number of slots
- to scale to different plans make sure the plan has the same or a greater number of of slots, cant downgrade if using more slots than allowed on tier below
2
Q
What are deployment slots
A
- Separate deployment areas that contain live apps with their own host names
3
Q
What are the benefits of deployment slots?
A
- allows you to validate changes in a staging slot before swapping to a prod slot
- deploying an app to a slot first and swapping into production makes sure all instances of the slot are warmed up, eliminating downtime as traffic redirection is seamless and no requests are dropped
- post swap the slot with previously staged app now has the production app, can easily swap back
4
Q
What is the first step slots take to eliminate downtime?
A
- Apply the following settings from the target slot (e.g. prod) to all instances of the source slot
- slot specific app settings and conn strings
- Continuous deployment settings if enabled
- App Service auth settings if enabled
5
Q
What is the second step slots take to eliminate downtime?
A
- wait for every instance in the source slot to complete its restart
- if any of them fail the swap operation reverts all changes to the source slot and stop the operation
6
Q
What is the third step slots take to eliminate downtime?
A
- if local cahce is enabled with custom warm up, trigger app initiation by making a HTTP request to the app root on each instance of the source slot
- if ‘applicationinitialisation’ isn’t specified, trigger an HTTP request to the app root of the source slot on each instance
- if an instance returns any HTTP response is considered warmed up
7
Q
What are the fourth and firth steps slots take to eliminate downtime?
A
- Once all instances are warmed up, swap the slots by switching the routing rules
- Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting instances
- Target slot remains online while the source slot is being prepared regardless of success or failure
8
Q
What is best practice when swapping web apps?
A
- Ensure the prod slot is always the target slot
- this way the swap operation doesn’t affect prod apps
9
Q
How can we make settings swapable between slots?
A
- Add the app setting “WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICK_SLOT_SETTINGS” in every slot and make its value 0/false
10
Q
What is the ‘swap with preview’ option?
A
- The swap operation is paused for you to validate that the source slot works with the target slot settings
- source slot is warmed up before slot completion which is good for mission-critical apps
- performs same swap operation as usual but pauses after the first step, allowing you to verify results before continuing
11
Q
What is auto swap?
A
- whenever you push code changes to the slot, app service automatically swaps the app into production after its warmed up in the source slot
- not supported on linux and web app for containers
12
Q
How can we configure a custom warm up?
A
- add the ‘applicationintialisation’ config element in web.config
- swap operation waits for this custom warm-up to finish before swapping
13
Q
What is the acitivity log?
A
- Shown on the apps resource page in the portal
- highlights information regarding a swap and appears in the logs as ‘swap web app slots’
14
Q
How does routing work with slots?
A
- by default all traffic routed to prod slot
- you can route a % of traffic to another slot
- useful if you need user feedback for a new update but you’re not ready to release it to prod
15
Q
How do we route traffic automatically with deployment slots?
A
- In the traffic % column of the slot you want to route to specify a % and click save
- the specified % is then randomly routed to the non-production slot
- A user that’s routed is pinned to that slot for the life of that client session
16
Q
How can a user tell what slot they are running on?
A
- Look at the x-ms-routing-name cookie in your HTTP headers
- production slot is x-ms-routing-name=self
- staging is the same but with =staging instead
17
Q
How can we route traffic manually with slots?
A
- Useful when you want your users to be able to opt in to or out of your beta app
- use the x-ms-routing-name query param
- e.g. a button with a href=’<webappname>.azurewebsites.net/?x-ms-routing-name=self' will take users back to production slot and every subsequent request has that cookie that pins the session to production</webappname>
18
Q
What are examples of some setting that are swapped between slots?
A
- General settings such as framework version, 32/64 bit, web sockets
- app settings (can also be configured not to)
- conn strings (can be configured not to)
- handler mappings
- webjob connect
19
Q
What are examples of some settings that are not swapped between slots?
A
- publishing endpoints
- custom domain names
- scale settings
- webjob schedulers
- IP restrictions
