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
Describe the two main deployment types (tenants) for Azure App Services and the hosts they use
- Multi-tenant public service hosts App Service plan
- Single-tenant App Service Environment (ASE) hosts Isolated SKU App Service plans - in your Azure virtual network
Describe an App Service scale unit and it’s two main building blocks
Added for additional context - may not be on the actual exam
It’s a collection of servers that host an run your applications. It could have more than 1,000 servers.
The main building blocks of a scale unit are:
* Front-ends
* Workers
Describe an App Service scale unit ‘front-end’
Front-ends handle HTTP and HTTPS requests - think of them as a load balancer, distributing requests to Workers
Describe what an App Service scale unit ‘worker’ does and it’s two types
Workers run your application.
A shared worker can host applications from multiple customers.
Dedicated workers are guaranteed to run one or more applications from one customer.
Describe App Service inbound features
- App-assigned address
- Access restrictions
- Service endpoints
- Private endpoints
Describe App Service outbound features
- Hybrid Connections
- Gateway-required virtual network integration
- Virtual network integration
Describe App Service inbound and outbound feature restrictions
Features used to handle inbound requests can’t be used to handle outbound requests, and vice-versa.
Describe the plans which host the two types of scale unit workers
The Free and Shared SKU plans host customer workloads on multi-tenant (multi-customer) workers.
The Basic and higher plans host customer workloads that are dedicated (single-tenant) to only one App Service plan.
Describe why knowing outbound addresses for worker VMs is useful
Knowing these is useful when scaling - and instance numbers grow.
(Worker VMs are broken down by App Service plan.
Different types may use different outbound (or inbound) IP addresses.)
