1.1: Create Azure App Service web apps - Explore Azure App Service Flashcards
Describe Azure App Service key components and value (4 points)
- Built in auto-scaling - scale up/down or in/out
- Out-of-the-box CI/CD
- Deployment slots - ability to swap between slots
- Native support for Linux hosting (for Node.js, Java, PHP, Python etc.)
Describe App Service Plans and the main settings you define for them
A set of compute resources for a web app (or web apps) to run on.
Azure Functions can run in an App Service plan (or a Consumption plan - where you control nothing)
Each App Service plan defines:
* Region (West US, East US, etc.)
* Number of VM instances
* Size of VM instances (Small, Medium, Large)
* Pricing tier (Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3, Isolated)
Describe pricing tier (compute) categories
Shared compute (Free and Shared tiers) - Can’t scale out, shares resource pools with other customers apps.
Dedicated compute (All other tiers) - Can scale out, runs on dedicated VMs
Isolated (Isolated tier) - Max scale out options, runs dedicated Azure VMs on dedicated Azure Virtual Networks
Consumption - Auto-scales, only available to function apps
Describe how apps run and scale on Free and Shared tiers
An app receives CPU minutes on a shared VM instance and can’t scale out
Describe how apps run and scale on VM instances for Basic, Standard, Premium, PremiumV2, PremiumV3, and Isolated tiers (4 points)
- An app runs on all VM instances configured in an App Service plan
- If multiple apps use the same plan they share VM instances
- All deployment slots run on the same VM instances
- Logs/Backups/WebJobs use CPU cycles from these VM instances
What can you do when your app needs more capabilities?
- You could change the pricing tier.
- You could save money by putting apps into one App Service plan.
- Isolate your app into its own App Service Plan.
Isolate your app into a new App Service plan when:
* The app is resource-intensive.
* You want to scale the app independently from the other apps in the existing plan.
* The app needs resources in a different geographical region.
Describe automated deployment options (3 points)
- Azure DevOps
- GitHub
- Bitbucket
Describe manual deployment options (4 points)
- Git
- CLI - az webapp up
- Zip - curl
- FTP/S
Describe when to use deployment slots, what you do, and why you’d use them
When: Use deployment slots when deploying new production builds.
How: In Standard App Service Plan tier and better you can deploy to a staging environment (slot) and swap it with your prod slot.
Why: This warms the worker instances - eliminating downtime.
Why use built-in authentication for App Services or Azure Functions?
Saves you time and effort by providing out-of-the-box authentication with a federated identity provider.
- No need to write it yourself - it’s built into the platform - requires no particular language, SDK, security expertise
- You can integrate with multiple providers: AAD, Facebook, Google….
Describe the default identity providers (5 points)
- Microsoft Identity Platform (AAD)
- Any OpenID Connect provider
Describe how authentication and authorisation modules work
The authentication and authorisation modules run in the same sandbox as your code.
When enabled every incoming HTTP/S request passes through these modules before being handled by your application
They:
* Authenticates users with the specified provider
* Validates, stores, and refreshes tokens
* Manages the authenticated session
* Injects identity information into request headers
The module runs separately from your code
Describe the ‘without provider SDK’ authentication flow (4 steps)
- Redirect client to /.auth/login/[provider]
- Provider redirects client to /.auth/login/[provider]/callback
- App service adds authenticated cookie to response
- Client includes authentication cookie in subsequent requests
Describe the ‘with provider SDK’ authentication flow (4 steps)
- Client code signs user in with providers SDK
- Client posts token from provider to /.auth/login/ for validation.
- App Service returns its own authentication token
- Client code presents authentication token in X-ZUMO-AUTH header
Describe authorisation behaviour options (what you can do when you receive a request that isn’t authenticated - 2 points)
Allow unauthenticated: Defers authorisation of unauthenticated traffic to your app code. Flexible and allows you to present multiple sign-on providers
Required authentication: Rejects unauthenticated traffic. Can redirect to one of the identity providers. If from a mobile app will return a 401/403