Explore Azure App Service.docx

[[Explore Azure App Service ]](https://learn.microsoft.com/en-us/training/modules/introduction-to-azure-app-service/) Contenido {#contenido.TtuloTDC} ========= [[Introduction] 2](#_Toc172042719) [[Learning objectives] 2](#learning-objectives) [[Examine Azure App Service] 2](#examine-azure-app-service) [[Built-in auto scale support] 2](#built-in-auto-scale-support) [[Container support] 2](#container-support) [[Continuous integration/deployment support] 3](#continuous-integrationdeployment-support) [[Deployment slots] 3](#deployment-slots) [[App Service on Linux] 3](#app-service-on-linux) [[Limitations] 3](#limitations) [[Examine Azure App Service plans] 4](#examine-azure-app-service-plans) [[How does my app run and scale?] 4](#how-does-my-app-run-and-scale) [[What if my app needs more capabilities or features?] 5](#what-if-my-app-needs-more-capabilities-or-features) [[Deploy to App Service] 5](#deploy-to-app-service) [[Automated deployment] 5](#automated-deployment) [[Manual deployment] 6](#manual-deployment) [[Use deployment slots] 6](#section-2) [[Continuously deploy code] 6](#continuously-deploy-code) [[Continuously deploy containers] 6](#continuously-deploy-containers) [[Explore authentication and authorization in App Service] 7](#explore-authentication-and-authorization-in-app-service) [[Why use the built-in authentication?] 7](#why-use-the-built-in-authentication) [[Identity providers] 7](#identity-providers) [[How it works] 8](#how-it-works) [[Authentication flow] 8](#authentication-flow) [[Authorization behavior] 9](#authorization-behavior) [[Token store] 9](#token-store) [[Logging and tracing] 10](#logging-and-tracing) [[Discover App Service networking features] 10](#discover-app-service-networking-features) [[Multi-tenant App Service networking features] 10](#multi-tenant-app-service-networking-features) [[Default networking behavior] 11](#default-networking-behavior) [[Outbound addresses] 11](#outbound-addresses) [[Find outbound IPs] 11](#find-outbound-ips) [[Exercise: Create a static HTML web app by using Azure Cloud Shell] 12](#exercise-create-a-static-html-web-app-by-using-azure-cloud-shell) [[Download the sample app] 13](#download-the-sample-app) [[Create the web app] 13](#create-the-web-app) [[Update and redeploy the app] 14](#update-and-redeploy-the-app) []{#_Toc172042719.anchor} Introduction ============ Your company is considering moving their web apps to the cloud and has asked you to evaluate Azure App Service. Learning objectives ------------------- After completing this module, you\'ll be able to: - - - - Examine Azure App Service ========================= Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite programming language or framework. Applications run and scale with ease on both Windows and Linux-based environments. Built-in auto scale support --------------------------- The ability to scale up/down or scale out/in is baked into the Azure App Service. Depending on the usage of the web app, you can scale the resources of the underlying machine that is hosting your web app up/down. Resources include the number of cores or the amount of RAM available. Scaling out/in is the ability to increase, or decrease, the number of machine instances that are running your web app. Container support ----------------- With Azure App Service, you can deploy and run containerized web apps on Windows and Linux. You can pull container images from a private Azure Container Registry or Docker Hub. Azure App Service also supports multi-container apps, Windows containers, and Docker Compose for orchestrating container instances. Continuous integration/deployment support ----------------------------------------- The Azure portal provides out-of-the-box continuous integration and deployment with Azure DevOps Services, GitHub, Bitbucket, FTP, or a local Git repository on your development machine. Connect your web app with any of the above sources and App Service will do the rest for you by auto-syncing code and any future changes on the code into the web app. Continuous integration and deployment for containerized web apps is also supported using either Azure Container Registry or Docker Hub. Deployment slots ---------------- When you deploy your web app you can use a separate deployment slot instead of the default production slot when you\'re running in the Standard App Service Plan tier or better. Deployment slots are live apps with their own host names. App content and configurations elements can be swapped between two deployment slots, including the production slot. App Service on Linux -------------------- App Service can also host web apps natively on Linux for supported application stacks. It can also run custom Linux containers (also known as Web App for Containers). App Service on Linux supports many language specific built-in images. Just deploy your code. Supported languages and frameworks include: Node.js, Java (JRE 8 & JRE 11), PHP, Python,.NET, and Ruby. If the runtime your application requires isn\'t supported in the built-in images, you can deploy it with a custom container. The languages, and their supported versions, are updated regularly. You can retrieve the current list by using the following command in the Cloud Shell. BashCopy az webapp list-runtimes \--os-type linux Limitations ----------- App Service on Linux does have some limitations: - - - Examine Azure App Service plans =============================== In App Service, an app always runs in an *App Service plan*. An App Service plan defines a set of compute resources for a web app to run. One or more apps can be configured to run on the same computing resources (or in the same App Service plan). When you create an App Service plan in a certain region (for example, West Europe), a set of compute resources is created for that plan in that region. Whatever apps you put into this App Service plan run on these compute resources as defined by your App Service plan. Each App Service plan defines: - - - - - The *pricing tier* of an App Service plan determines what App Service features you get and how much you pay for the plan. There are a few categories of pricing tiers: - - - ** Note** App Service Free and Shared (preview) hosting plans are base tiers that run on the same Azure virtual machines as other App Service apps. Some apps might belong to other customers. These tiers are intended to be used only for development and testing purposes. How does my app run and scale? ------------------------------ In the **Free** and **Shared** tiers, an app receives CPU minutes on a shared VM instance and can\'t scale out. In other tiers, an app runs and scales as follows: - - - - In this way, the App Service plan is the **scale unit** of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings. What if my app needs more capabilities or features? --------------------------------------------------- Your App Service plan can be scaled up and down at any time. It\'s as simple as changing the pricing tier of the plan. If your app is in the same App Service plan with other apps, you may want to improve the app\'s performance by isolating the compute resources. You can do it by moving the app into a separate App Service plan. You can potentially save money by putting multiple apps into one App Service plan. However, since apps in the same App Service plan all share the same compute resources you need to understand the capacity of the existing App Service plan and the expected load for the new app. Isolate your app into a new App Service plan when: - - - This way you can allocate a new set of resources for your app and gain greater control of your apps Deploy to App Service ===================== Every development team has unique requirements that can make implementing an efficient deployment pipeline difficult on any cloud service. App Service supports both automated and manual deployment. Automated deployment -------------------- Automated deployment, or continuous deployment, is a process used to push out new features and bug fixes in a fast and repetitive pattern with minimal effect on end users. Azure supports automated deployment directly from several sources. The following options are available: - - - Manual deployment ----------------- There are a few options that you can use to manually push your code to Azure: - - - - Use deployment slots -------------------- Whenever possible, use deployment slots when deploying a new production build. When using a Standard App Service Plan tier or better, you can deploy your app to a staging environment and then swap your staging and production slots. The swap operation warms up the necessary worker instances to match your production scale, thus eliminating downtime. ### Continuously deploy code If your project has designated branches for testing, QA, and staging, then each of those branches should be continuously deployed to a staging slot. This allows your stakeholders to easily assess and test the deployed branch. ### Continuously deploy containers For custom containers from Azure Container Registry or other container registries, deploy the image into a staging slot and swap into production to prevent downtime. The automation is more complex than code deployment because you must push the image to a container registry and update the image tag on the webapp. - - - Explore authentication and authorization in App Service ======================================================= Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal, or no code in your web app, RESTful API, mobile back end, and Azure Functions. Why use the built-in authentication? ------------------------------------ You\'re not required to use App Service for authentication and authorization. Many web frameworks are bundled with security features, and you can use them if you like. If you need more flexibility than App Service provides, you can also write your own utilities. The built-in authentication feature for App Service and Azure Functions can save you time and effort by providing out-of-the-box authentication with federated identity providers, allowing you to focus on the rest of your application. - - - Identity providers ------------------ App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. The following identity providers are available by default: Expand table **Provider** **Sign-in endpoint** **How-To guidance** ----------------------------- ------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------- Microsoft identity platform /.auth/login/aad [[App Service Microsoft identity platform login]](https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad) Facebook /.auth/login/facebook [[App Service Facebook login]](https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-facebook) Google /.auth/login/google [[App Service Google login]](https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-google) Twitter /.auth/login/twitter [[App Service Twitter login]](https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-twitter) Any OpenID Connect provider /.auth/login/\ [[App Service OpenID Connect login]](https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-openid-connect) GitHub /.auth/login/github [[App Service GitHub login]](https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-github) When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. You can provide your users with any number of these sign-in options. How it works ------------ The authentication and authorization module runs in the same sandbox as your application code. When it\'s enabled, every incoming HTTP request passes through it before being handled by your application code. This module handles several things for your app: - - - - The module runs separately from your application code and can be configured using Azure Resource Manager settings or using a configuration file. No SDKs, specific programming languages, or changes to your application code are required. ** Note** In Linux and containers the authentication and authorization module runs in a separate container, isolated from your application code. Because it does not run in-process, no direct integration with specific language frameworks is possible. Authentication flow ------------------- The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider\'s SDK. - - The following table shows the steps of the authentication flow. Expand table +-----------------------+-----------------------+-----------------------+ | **Step** | **Without provider | **With provider SDK** | | | SDK** | | +=======================+=======================+=======================+ | Sign user in | Redirects client | Client code signs | | | to /.auth/login/\. | provider\'s SDK and | | | | | | | | receives an | | | | authentication token. | | | | For information, see | | | | the provider\'s | | | | documentation. | +-----------------------+-----------------------+-----------------------+ | Post-authentication | Provider redirects | Client code posts | | | client | token from provider | | | to /.auth/login/\ for | | | | validation. | +-----------------------+-----------------------+-----------------------+ | Establish | App Service adds | App Service returns | | authenticated session | authenticated cookie | its own | | | to response. | authentication token | | | | to client | | | | | | | | code. | +-----------------------+-----------------------+-----------------------+ | Serve authenticated | Client includes | Client code presents | | content | authentication cookie | authentication token | | | in subsequent | in X-ZUMO-AUTH | | | requests | | | | (automatically | header | | | handled by browser). | (automatically | | | | handled by Mobile | | | | Apps client | | | | | | | | SDKs). | +-----------------------+-----------------------+-----------------------+ For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/\. You can also present users with one or more /.auth/login/\ links to sign in to your app using their provider of choice. ### Authorization behavior In the Azure portal, you can configure App Service with many behaviors when an incoming request isn\'t authenticated. - - ### Token store App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. When you enable authentication with any provider, this token store is immediately available to your app. ### Logging and tracing If you enable application logging, authentication and authorization traces are collected directly in your log files. If you see an authentication error that you didn\'t expect, you can conveniently find all the details by looking in your existing application logs. Discover App Service networking features ======================================== By default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. But for many applications, you need to control the inbound and outbound network traffic. There are two main deployment types for Azure App Service. The multitenant public service hosts App Service plans in the Free, Shared, Basic, Standard, Premium, PremiumV2, and PremiumV3 pricing SKUs. There\'s also the single-tenant App Service Environment (ASE) hosts Isolated SKU App Service plans directly in your Azure virtual network. Multi-tenant App Service networking features -------------------------------------------- Azure App Service is a distributed system. The roles that handle incoming HTTP or HTTPS requests are called *front ends*. The roles that host the customer workload are called *workers*. All the roles in an App Service deployment exist in a multi-tenant network. Because there are many different customers in the same App Service scale unit, you can\'t connect the App Service network directly to your network. Instead of connecting the networks, you need features to handle the various aspects of application communication. The features that handle requests to your app can\'t be used to solve problems when you\'re making calls from your app. Likewise, the features that solve problems for calls from your app can\'t be used to solve problems to your app. Expand table **Inbound features** **Outbound features** ---------------------- ---------------------------------------------- App-assigned address Hybrid Connections Access restrictions Gateway-required virtual network integration Service endpoints Virtual network integration Private endpoints You can mix the features to solve your problems with a few exceptions. The following inbound use cases are examples of how to use App Service networking features to control traffic inbound to your app. Expand table **Inbound use case** **Feature** ------------------------------------------------------------------ ---------------------- Support IP-based SSL needs for your app App-assigned address Support unshared dedicated inbound address for your app App-assigned address Restrict access to your app from a set of well-defined addresses Access restrictions Default networking behavior --------------------------- Azure App Service scale units support many customers in each deployment. The Free and Shared SKU plans host customer workloads on multitenant workers. The Basic and higher plans host customer workloads that are dedicated to only one App Service plan. If you have a Standard App Service plan, all the apps in that plan run on the same worker. If you scale out the worker, all the apps in that App Service plan are replicated on a new worker for each instance in your App Service plan. ### Outbound addresses The worker VMs are broken down in large part by the App Service plans. The Free, Shared, Basic, Standard, and Premium plans all use the same worker VM type. The PremiumV2 plan uses another VM type. PremiumV3 uses yet another VM type. When you change the VM family, you get a different set of outbound addresses. There are many addresses that are used for outbound calls. The outbound addresses used by your app for making outbound calls are listed in the properties for your app. These addresses are shared by all the apps running on the same worker VM family in the App Service deployment. If you want to see all the addresses that your app might use in a scale unit, there\'s a property called possibleOutboundIpAddresses that lists them. ### Find outbound IPs To find the outbound IP addresses currently used by your app in the Azure portal, select **Properties** in your app\'s left-hand navigation. You can find the same information by running the following Azure CLI command in the Cloud Shell. They\'re listed in the **Additional Outbound IP Addresses** field. BashCopy az webapp show \\ \--resource-group \ \\ \--name \ \\ \--query outboundIpAddresses \\ \--output tsv To find all possible outbound IP addresses for your app, regardless of pricing tiers, run the following command in the Cloud Shell. BashCopy az webapp show \\ \--resource-group \ \\ \--name \ \\ \--query possibleOutboundIpAddresses \\ \--output tsv Exercise: Create a static HTML web app by using Azure Cloud Shell ================================================================= This module requires a sandbox to complete. A [**[sandbox]**](https://learn.microsoft.com/en-us/training/support/faq?pivots=sandbox) gives you access to free resources. Your personal subscription will not be charged. The sandbox may only be used to complete training on Microsoft Learn. Use for any other reason is prohibited, and may result in permanent loss of access to the sandbox. Microsoft provides this lab experience and related content for educational purposes. All presented information is owned by Microsoft and intended solely for learning about the covered products and services in this Microsoft Learn module. [**[Sign in to activate sandbox]**](https://learn.microsoft.com/en-us/training/modules/introduction-to-azure-app-service/7-create-html-web-app?activate-azure-sandbox=true) The free sandbox allows you to create resources in a subset of the Azure global regions. Select a region from the following list when you create resources: - - - - - - - - - - In this exercise, you\'ll deploy a basic HTML+CSS site to Azure App Service by using the Azure CLI az webapp up command. You\'ll then update the code and redeploy it by using the same command. The az webapp up command makes it easy to create and update web apps. When executed it performs the following actions: - - - - Download the sample app ----------------------- In this section you\'ll use the sandbox to download the sample app and set variables to make some of the commands easier to enter. 1. 2. 3. Create the web app ------------------ 1. 2. Update and redeploy the app --------------------------- 1. 2. 3. 4.

Explore Azure App Service.docx

Document Details

Related

Full Transcript

Upgrade to continue