Distribution av företags program med hjälp av App Service-miljönEnterprise app deployment using App Service Environment

Azure App Service är en PaaS-tjänst som används för att vara värd för en mängd olika appar i Azure: webbappar, API Apps, Functions och Mobile Apps.Azure App Service is a PaaS service used to host a variety of apps on Azure: web apps, API apps, functions, and mobile apps. App Service-miljön eller ASE gör det möjligt för företag att distribuera sina App Service appar i ett undernät i sin egen Azure-Virtual Network, vilket ger en isolerad, mycket skalbar och dedikerad miljö för deras moln arbets belastningar.App Service Environment or ASE allows enterprises to deploy their App Service apps in a subnet in their own Azure Virtual Network, providing an isolated, highly scalable, and dedicated environment for their cloud workloads.

Den här referens arkitekturen visar en gemensam arbets belastning i företaget med ASE och bästa praxis för att öka säkerheten för den här arbets belastningen.This reference architecture demonstrates a common enterprise workload using ASE, and best practices to tighten security of this workload.

GitHub-logotyp en referens implementering för den här arkitekturen finns på GitHub.GitHub logo A reference implementation for this architecture is available on GitHub.

Referens arkitektur för standard distribution av ASE

ArkitekturArchitecture

Huvud komponenten i den här arkitekturen är app Services miljön.The main component of this architecture is the App Service environment. En ASE kan distribueras antingen som extern ASE med en offentlig IP-adress eller som intern ASE med en intern IP-adress som tillhör den interna Load Balancer (ILB) .An ASE can be deployed either as external ASE with a public IP address, or as internal ASE , with an internal IP address belonging to the Internal Load Balancer (ILB) . Den här referens arkitekturen distribuerar ett företags webb program i en intern ASE, även kallat en ILB-ASE.This reference architecture deploys an enterprise web application in an internal ASE, also called an ILB ASE. Använd en ILB-ASE när ditt scenario kräver att du:Use an ILB ASE when your scenario requires you to:

  • Vara värd för intranät program på ett säkert sätt i molnet, som du kommer åt via en plats-till-plats-eller ExpressRoute.Host intranet applications securely in the cloud, which you access through a site-to-site or ExpressRoute.
  • Skydda appar med en WAF-enhet.Protect apps with a WAF device.
  • Vara värd för appar i molnet som inte listas i offentliga DNS-servrar.Host apps in the cloud that aren't listed in public DNS servers.
  • Skapa internet-isolerade appar för serverdelar, som dina appar för klientdelar säkert kan integrera med.Create internet-isolated back-end apps, which your front-end apps can securely integrate with.

En ASE måste alltid distribueras i sitt eget undernät i företagets virtuella nätverk, vilket ger en snäv kontroll över inkommande och utgående trafik.An ASE must be always deployed in its own subnet within the enterprise' virtual network, allowing a tight control of the incoming and outgoing traffic. I det här under nätet distribueras App Service-program i en eller flera App Service-planer, som är en samling fysiska resurser som krävs för att köra appen.Within this subnet, App Service applications are deployed in one or more App Service plans, which is a collection of physical resources required to run the app. Beroende på komplexitets-och resurs kravet kan en App Service plan delas mellan flera appar.Depending on the complexity and resource requirement, an App Service plan can be shared between multiple apps. Den här referens implementeringen distribuerar en webbapp som heter röstnings-app och som samverkar med ett privat webb-API och en funktion.This reference implementation deploys a web app named Voting App , that interacts with a private web API and a function. Den distribuerar också en dummy-webbapp som heter test app för att demonstrera distributioner på flera appar.It also deploys a dummy web app named Test App to demonstrate multi-app deployments. Varje App Service app finns i en egen App Service plan, vilket gör att de kan skalas separat vid behov.Each App Service app is hosted in its own App Service plan, allowing each to be scaled independently if necessary. Alla resurser som krävs av dessa värdbaserade appar, t. ex. lagring och beräkning, samt skalnings behov hanteras helt av App Service-miljön-infrastrukturen.All resources required by these hosted apps, such as storage and compute, as well as scaling needs are fully managed by the App Service Environment infrastructure.

Den enkla röstnings appen i den här implementeringen gör det möjligt för användare att visa befintliga eller skapa nya poster, samt rösta på befintliga poster.The simple voting app in this implementation, allows users to view existing or create new entries, as well as vote on the existing entries. Webb-API: et används för att skapa och hämta poster och röster.The web API is used for creation and retrieval of entries and votes. Själva informationen lagras i en SQL Server databas.The data itself is stored in a SQL Server database. Webbappens köer nyligen tillagda röster i en Service Bus-instans för att demonstrera asynkrona data uppdateringar.To demonstrate asynchronous data updates, the web app queues newly added votes in a Service Bus instance. Funktionen hämtar röster i kö och uppdaterar SQL-databasen.The function picks up queued votes and updates the SQL database. CosmosDB används för att lagra en modell som gör att webbappen hämtas till visning i webbläsaren.CosmosDB is used to store a mock-up ad, that the web app retrieves to display on the browser. Programmet använder Azure cache för Redis för hantering av cachen.The application uses Azure Cache for Redis for cache management. En Premium-nivå i Azure-cache för Redis används, vilket gör att konfigurationen till samma virtuella nätverk som ASE i sitt eget undernät.A Premium tier Azure Cache for Redis is used, which allows configuration to the same virtual network as the ASE, in its own subnet. Detta ger förbättrad säkerhet och isolering till cacheminnet.This provides enhanced security and isolation to the cache.

Webbappar är de enda komponenter som är tillgängliga för Internet via app-gatewayen.The web apps are the only components accessible to the internet via the App Gateway. API: et och funktionen är inte tillgängliga från en Internet klient.The API and the function are inaccessible from an internet client. Den inkommande trafiken skyddas av en brand vägg för webbaserade program som kon figurer ATS på App-gatewayen.The inbound traffic is protected by a Web Application Firewall configured on the App Gateway.

Följande tjänster är nyckel för att låsa ASE i den här arkitekturen:The following services are key to locking down the ASE in this architecture:

Azure Virtual Network eller VNet är ett privat Azure Cloud Network som ägs av företaget.Azure Virtual Network or VNet is a private Azure cloud network owned by the enterprise. Den ger nätverks baserad säkerhet och isolering.It provides network-based security and isolation. ASE är en App Service distribution till ett undernät för det virtuella nätverket som ägs av företaget.ASE is an App Service deployment into a subnet of the enterprise-owned VNet. Det gör det möjligt för företaget att noggrant styra nätverks utrymmet och de resurser som de har åtkomst till, med hjälp av nätverks säkerhets grupper och tjänst slut punkter .It allows the enterprise to tightly control that network space and the resources it accesses, using Network Security groups and Service Endpoints .

Application Gateway är en belastningsutjämnare för webb trafik på program nivå med TLS/SSL-avlastning och brand vägg för webbaserade program (WAF).Application Gateway is an application-level web traffic load balancer, with TLS/SSL offloading, and web application firewall (WAF) protection. Den lyssnar på en offentlig IP-adress och dirigerar trafik till program slut punkten i ILB-ASE.It listens on a public IP address and routes traffic to the application endpoint in the ILB ASE. Eftersom det här är routning på program nivå kan den dirigera trafik till flera appar inom samma ILB-ASE.Since this is application-level routing, it can route traffic to multiple apps within the same ILB ASE. Se Application Gateway flera webbplats värdar för att lära dig hur app Gateway stöder flera platser.See Application Gateway multiple site hosting to learn how App Gateway supports multiple sites.

Azure-brandväggen används för att begränsa utgående trafik från webb programmet.Azure Firewall is used to restrict the outbound traffic from the web application. Utgående trafik som inte går via tjänstens slut punkts kanaler och en routningstabell som krävs av ASE dirigeras till brand Väggs under nätet.Outgoing traffic that does not go through the service endpoint channels and a route table required by ASE, is directed to the firewall subnet. Även om det rekommenderas att Konfigurera tjänst slut punkter som ska konfigureras i brand Väggs under nätet för spårning, är det inte alltid möjligt.Although it is recommended for service endpoints to be configured on the firewall subnet for traceability, it may not be always feasible. Till exempel krävs vissa tjänst slut punkter av ASE-infrastrukturen för att finnas i ASE-undernätet.For example, some service endpoints are required by the ASE infrastructure to be on the ASE subnet. För enkelhetens skull konfigurerar den här arkitekturen alla tjänst slut punkter i ASE-undernätet.For simplicity, this architecture configures all service endpoints on the ASE subnet.

Azure Active Directory eller Azure AD ger åtkomst rättigheter och behörighets hantering till Azure-resurser och-tjänster.Azure Active Directory or Azure AD provides access rights and permissions management to Azure resources and services. Hanterade identiteter tilldelar identiteter till tjänster och appar, som hanteras automatiskt av Azure AD.Managed Identities assigns identities to services and apps, automatically managed by Azure AD. Dessa identiteter kan användas för att autentisera till alla tjänster som stöder Azure AD-autentisering.These identities can be used to authenticate to any service that supports Azure AD authentication. Detta tar bort behovet av att uttryckligen konfigurera autentiseringsuppgifter för de här apparna.This removes the need to explicitly configure credentials for these apps. Den här arkitekturen tilldelar webb programmet en hanterad identitet.This architecture assigns a managed identity to the web app.

Key Vault lagrar alla hemligheter och autentiseringsuppgifter som krävs av apparna.Key Vault stores any secrets and credentials required by the apps. Använd det här alternativet för att lagra hemligheter direkt i programmet.Use this option over storing secrets directly in the application.

Azure-pipelines ger kontinuerlig integrering och kontinuerliga distributions funktioner i den här arkitekturen.Azure Pipelines provides Continuous Integration and Continuous Deployment capabilities in this architecture. Eftersom ASE är internt i det virtuella nätverket används en virtuell dator som en hoppsida i VNet för att distribuera appar i app Services planer.Since the ASE is internal to the virtual network, a virtual machine is used as a jumpbox inside the VNet to deploy apps in the App Service plans. Pipelinen skapar apparna utanför VNet.The pipeline builds the apps outside the VNet. För förbättrad säkerhet och sömlös RDP/SSH-anslutning kan du överväga att använda det nyligen lanserade Azure-skydds som hopp.For enhanced security and seamless RDP/SSH connectivity, consider using the recently released Azure Bastion as the jumpbox.

Konfiguration för flera platserMulti-site configuration

Distribution på flera platser

Interna ASE kan vara värdar för flera webbappar och API: er med HTTP-slutpunkter.Internal ASE can host several web apps and APIs with HTTP endpoints. Dessa program är låsta från det offentliga Internet eftersom ILB IP-adress endast är tillgänglig från Virtual Network.These applications are locked down from the public internet as the ILB IP is only accessible from within the Virtual Network. Application Gateway används för att selektivt exponera dessa program på Internet.The Application Gateway is used to selectively expose these applications to the internet. ASE tilldelar en standard-URL till varje App Service-program som <default-appName>.<ASE-domain>.appserviceenvironment.net .ASE assigns a default URL to each App Service application as <default-appName>.<ASE-domain>.appserviceenvironment.net. En privat DNS-zon skapas som mappar ASE domän namn till ASE-ILB IP-adress.A private DNS zone is created that maps the ASE domain name to the ASE ILB IP address. På så sätt undviker du att använda en anpassad DNS för att komma åt apparna i VNet.This avoids using a custom DNS to access the apps within the VNet.

App Gateway konfigureras så att en lyssnare lyssnar på https-porten efter förfrågningar till gatewayens IP-adress.The App Gateway is configured such that a listener listens on the HTTPS port for requests to the Gateway's IP address. För enkelhetens skull använder den här implementeringen ingen offentlig DNS-registrering, och kräver att du ändrar localhost-filen på datorn så att den pekar på en godtyckligt vald URL till app gatewayens IP-adress.For simplicity, this implementation does not use a public DNS name registration, and requires you to modify the localhost file on your computer to point an arbitrarily chosen URL to the App Gateway's IP. För enkelhetens skull använder lyssnaren ett självsignerat certifikat för att bearbeta dessa förfrågningar.For simplicity, the listener uses a self-signed certificate to process these requests. App-gatewayen har backend-pooler för varje App Service programmets standard-URL.The App Gateway has backend pools for each App Service application's default URL. En routningsprincip har kon figurer ATS för att ansluta lyssnaren till backend-poolen.A routing rule is configured to connect the listener to the backend pool. Http-inställningar skapas som avgör om anslutningen mellan gatewayen och ASE ska krypteras.HTTP settings are created that determine whether the connection between the gateway and the ASE will be encrypted. De här inställningarna används också för att åsidosätta inkommande HTTP-värdens huvud med ett värdnamn som har hämtats från backend-poolen.These settings are also used to override the incoming HTTP host header with a host name picked from the backend pool. Den här implementeringen använder standard certifikat som skapats för standard-ASE App-URL: er, som är betrodda av gatewayen.This implementation uses default certificates created for the default ASE app URLs, which are trusted by the gateway. Begäran omdirigeras till standard-URL: en för motsvarande app.The request is redirected to the default URL of the corresponding app. Den privata DNS som är länkad till VNet vidarebefordrar denna begäran till ILB IP.The private DNS linked to the VNet forwards this request to the ILB IP. ASE vidarebefordrar sedan detta till den begärda app service.The ASE then forward this to the requested App service. All HTTP-kommunikation i ASE-apparna går via det privata DNS-nätverket.Any HTTP communication within the ASE apps, goes through the private DNS. Observera att lyssnaren, backend-poolen, synkroniseringsregeln och HTTP-inställningarna måste konfigureras på App Gateway för varje ASE-app.Note that the listener, backend pool, routing rule, and the HTTP settings need to be configured on the App Gateway for each ASE app.

Utforska appgw.jspå och dns.jspå för att förstå hur dessa konfigurationer görs för att tillåta flera platser.Explore appgw.json and dns.json to understand how these configurations are made to allow multiple sites. Webb programmet med namnet testapp är en tom app som skapats för att demonstrera den här konfigurationen.The web app named testapp is an empty app created to demonstrate this configuration. Dessa JSON-filer nås från distributions skriptet deploy_std. sh. De kan också nås av deploy_ha. sh, som används för en hög tillgänglig ASE-distribution med flera platser.These JSON files are accessed from the deployment script deploy_std.sh. These are also accessed by deploy_ha.sh, which is used for a high availability multi-site ASE deployment.

SäkerhetsövervägandenSecurity considerations

App Service EnvironmentApp Service Environment

En intern ASE distribueras i det virtuella företags nätverket, som är dolt från det offentliga Internet.An internal ASE is deployed in the enterprise virtual network, hidden from the public internet. Det gör det möjligt för företaget att låsa sina backend-tjänster, till exempel webb-API: er och funktioner på nätverks nivå.It allows the enterprise to lock down their backend services, such as web APIs and functions, at the network level. Alla ASE-appar med en HTTP-slutpunkt kan nås via ILB, inifrån det virtuella nätverket.Any ASE app with an HTTP endpoint, can be accessed through the ILB, from within the virtual network. App-gatewayen är konfigurerad för att vidarebefordra begär anden till webbappen via ILB.The App Gateway is configured to forward requests to the web app through the ILB. Själva webbappen går igenom ILB för att få åtkomst till API: et.The web app itself goes through the ILB to access the API. De kritiska Server dels komponenterna, det vill säga API: et och funktionen, är i praktiken inte tillgängliga från det offentliga Internet.The critical backend components, that is, the API and the function, are effectively inaccessible from the public internet.

Standard certifikat skapas för varje app service för standard domän namnet som tilldelats av ASE.Default certificates are created for each App service for the default domain name assigned by ASE. Det här certifikatet kan öka säkerheten för trafiken mellan gatewayen och appen, och det kan krävas i vissa fall.This certificate can tighten the security of the traffic between the gateway and the app, and may be required in certain scenarios. Dessa certifikat visas inte av klientens webbläsare, det kan bara svara på de certifikat som kon figurer ATS på App-gatewayen.These certificates will not be visible by the client browser, it can only respond to the certificates configured at the App Gateway.

App-GatewayApp Gateway

Referens implementeringen konfigurerar app-gatewayen program mässigt i appgw.jspå.The reference implementation configures the App Gateway programmatically in the appgw.json. Filen deploy_std. sh använder den här konfigurationen vid distribution av gatewayen:The file deploy_std.sh uses this configuration when deploying the gateway:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.json --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

KrypteringEncryption

Enligt beskrivningen i Översikt över TLS-terminering och slut punkt till slut punkt för TLS med Application Gatewaykan app Gateway använda Transport Layer Security (TLS)/Secure Sockets Layer (SSL) för att kryptera och skydda all trafik från webbläsare.As described in the Overview of TLS termination and end to end TLS with Application Gateway, App Gateway can use Transport Layer Security (TLS)/Secure Sockets Layer (SSL) to encrypt and protect all traffic from web browsers. Kryptering kan konfigureras på följande sätt:Encryption can be configured in the following ways:

  1. Krypteringen avslutades på gatewayen .Encryption terminated at the gateway . Backend-poolerna i det här fallet är konfigurerade för HTTP.The backend pools in this case are configured for HTTP. Krypteringen stoppas vid gatewayen och trafiken mellan gatewayen och App Service är okrypterad.The encryption stops at the gateway, and traffic between the gateway and the app service is unencrypted. Eftersom krypteringen är processor intensiv, förbättrar okrypterad trafik på Server delen prestanda och ger enklare certifikat hantering.Since encryption is CPU-intensive, unencrypted traffic at the backend improves performance and allows simpler certificate management. Detta ger en rimlig säkerhets nivå eftersom Server delen skyddas av nätverks konfigurationen.This provides a reasonable level of security since the backend is secured by virtue of the network configuration.

  2. Slut punkt till slut punkts kryptering .End to end encryption . I vissa fall, t. ex. särskilda krav på säkerhet eller efterlevnad, kan trafiken behöva krypteras mellan gatewayen och appen.In some scenarios, such as specific security or compliance requirements, the traffic might be required to be encrypted between the gateway and the app. Detta uppnås med hjälp av HTTPS-anslutning och konfigurering av certifikat i backend-poolen.This is achieved by using HTTPS connection, and configuring certificates at the backend pool.

Den här referens implementeringen använder självsignerade certifikat för app Gateway.This reference implementation uses self-signed certificates for App Gateway. För produktions kod ska ett certifikat som utfärdats av en certifikat utfärdare användas.For production code, a certificate issued by a Certificate Authority should be used. För en lista över certifikat typer som stöds, läsa certifikat som stöds för att avsluta TLS.For a list of supported certificate types, read Certificates supported for TLS termination. Läs Konfigurera en Programgateway med TLS-avslutning med hjälp av Azure Portal för att lära dig hur du skapar en gateway-avslutad kryptering.Read Configure an application gateway with TLS termination using the Azure portal to learn how to create Gateway-terminated encryption. Följande rader med kod i appgw.jskonfigureras program mässigt:The following lines of code in the appgw.json configure this programmatically:

          {
            "name": "httpListeners",
            "count": "[length(parameters('appgwApplications'))]",
            "input": {
              "name": "[concat(variables('appgwListenerName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]",
              "properties": {
                "frontendIPConfiguration": {
                  "id": "[concat(variables('appgwId'), '/frontendIPConfigurations/', variables('appgwFrontendName'))]"
                },
                "frontendPort": {
                  "id": "[concat(variables('appgwId'), '/frontendPorts/port_443')]"
                },
                "protocol": "Https",
                "sslCertificate": {
                  "id": "[concat(variables('appgwId'), '/sslCertificates/', variables('appgwSslCertificateName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]"
                },
                "hostName": "[parameters('appgwApplications')[copyIndex('httpListeners')].hostName]",
                "requireServerNameIndication": true
              }
            }
          },

För trafik mellan webbapparna på ASE och gatewayen används standard-SSL-certifikaten.For traffic between the web apps on the ASE and the gateway, the default SSL certificates are used. Backend-poolerna i den här implementeringen konfigureras för att omdirigera HTTPS-trafik med värd namnet åsidosätts av de standard domän namn som är kopplade till webbapparna.The backend pools in this implementation are configured to redirect HTTPS traffic with host name overridden by the default domain names associated to the web apps. App gatewayen litar på SSL-standardcertifikaten eftersom de utfärdats av Microsoft.The App Gateway trusts the default SSL certificates since they are issued by Microsoft. Läs konfigurera app service med Application Gateway för att veta hur dessa konfigurationer görs.Read Configure App Service with Application Gateway to know how these configurations are made. Följande rader i appgw.jspå visar hur detta konfigureras i referens implementeringen:The following lines in the appgw.json show how this is configured in the reference implementation:

         {
            "name": "backendHttpSettingsCollection",
            "count": "[length(parameters('appgwApplications'))]",
            "input": {
              "name": "[concat(variables('appgwHttpSettingsName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]",
              "properties": {
                "Port": 443,
                "Protocol": "Https",
                "cookieBasedAffinity": "Disabled",
                "pickHostNameFromBackendAddress": true,
                "requestTimeout": 20,
                "probe": {
                  "id": "[concat(variables('appgwId'), '/probes/', variables('appgwHealthProbeName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]"
                }
              }
            }
          },

Brandvägg för webbaserade programWeb Application Firewall

Brand vägg för webbaserade program (WAF) på Application Gateway skyddar webbappar från skadliga attacker, till exempel SQL-inmatning.Web Application Firewall (WAF) on the Application Gateway protects the web apps from malicious attacks, such as SQL injection. Det är också integrerat med Azure Monitor för att övervaka attacker som använder real tids logg.It is also integrated with Azure Monitor, to monitor attacks using a real-time log. WAF måste vara aktiverat på gatewayen, enligt beskrivningen i skapa en Programgateway med en brand vägg för webbaserade program med hjälp av Azure Portal.WAF needs to be enabled on the gateway, as described in Create an application gateway with a Web Application Firewall using the Azure portal. Referens implementeringen aktiverar WAF program mässigt i appgw.jspå filen med följande kodfragment:The reference implementation enables WAF programmatically in the appgw.json file with the following snippet:

        "webApplicationFirewallConfiguration": {
          "enabled": true,
          "firewallMode": "Detection",
          "ruleSetType": "OWASP",
          "ruleSetVersion": "3.0"
        },

Virtual NetworkVirtual Network

Nätverks säkerhets grupper kan associeras med ett eller flera undernät i VNet.Network security groups can be associated with one or more subnets in the VNet. Detta är säkerhets regler som tillåter eller nekar trafik att flöda mellan olika Azure-resurser.These are security rules that allow or deny traffic to flow between various Azure resources. Den här arkitekturen kopplar en separat NSG för varje undernät.This architecture associates a separate NSG for each subnet. Detta möjliggör fin justering av de här reglerna per undernät enligt de tjänster som finns i det under nätet.This allows fine-tuning of these rules per subnet, as per the service(s) contained in that subnet. Du kan till exempel utforska konfigurationen för "type": "Microsoft.Network/networkSecurityGroups" i filen ase.jspå för NSG för ASE-undernätet och i filen appgw.jspå för NSG för app Gateway-undernätet.For example, explore the configuration for "type": "Microsoft.Network/networkSecurityGroups" in the file ase.json for the NSG for the ASE subnet, and in the file appgw.json for the NSG for App Gateway subnet.

Tjänst slut punkter utökar ditt vnets privata adress utrymme och identitet för att stödja Azure-tjänster, vilket begränsar åtkomsten till dessa tjänster till enbart ditt VNet.Service endpoints extend your VNet's private address space and identity to supporting Azure services, restricting the access to these services to only your VNet. För förbättrad säkerhet bör tjänst slut punkter aktive ras i ASE-undernätet för alla Azure-tjänster som stöder det.For improved security, service endpoints should be enabled on the ASE subnet for any Azure service that supports it. Tjänsten kan sedan skyddas till Enterprise VNet genom att ställa in virtuella nätverks regler på tjänsten, vilket effektivt blockerar åtkomsten från det offentliga Internet.The service can then be secured to the enterprise VNet by setting virtual network rules on the service, effectively blocking access from public internet. ASE-infrastrukturen ställer in tjänst slut punkter för Händelsehubben, SQL Server och lagring för sin egen hantering, även om själva arkitekturen inte kan använda dem, enligt vad som anges i avsnittet system arkitektur i den här artikeln.ASE infrastructure sets up service endpoints for Event Hub, SQL Server, and Storage, for its own management, even if the architecture itself may not use them, as mentioned in the System Architecture section of this article. Den här arkitekturen konfigurerar tjänst slut punkter för de tjänster som används, som har stöd för detta: Service Bus, SQL Server, Key Vault och CosmosDB.This architecture configures service endpoints for the services used, that support this: Service Bus, SQL Server, Key Vault, and CosmosDB. Utforska den här konfigurationen i ase.jspå, som "type": "Microsoft.Network/virtualNetworks/subnets" --> "properties" --> "serviceEndpoints" .Explore this configuration in the ase.json, as "type": "Microsoft.Network/virtualNetworks/subnets" --> "properties" --> "serviceEndpoints".

Att Aktivera tjänst slut punkter i ett undernät är en två stegs process.Enabling service endpoints on a subnet is a two-step process. Resurserna behöver konfigureras för att ta emot trafik på tjänst slut punkterna från det här virtuella nätverket.The resources themselves need to be configured to receive traffic on the service endpoints from this virtual network. Mer information finns i begränsa nätverks åtkomsten till en resurs .For more information, read Restrict network access to a resource .

BrandväggFirewall

Azure Firewall-och service-slutpunkter kompletterar varandra.Azure Firewall and service endpoints complement each other. När tjänstens slut punkter skyddar resurserna genom att begränsa inkommande trafik till härstammar från ditt virtuella nätverk, kan du med Azure-brandväggen begränsa utgående trafik från dina program.While service endpoints protect the resources by restricting incoming traffic to originate from your virtual network, Azure Firewall allows you to restrict the outbound traffic from your applications. Vi rekommenderar att all utgående trafik passerar genom brand Väggs under nätet, inklusive tjänst slut punktens trafik.It is recommended to let all outbound traffic to pass through the firewall subnet, including service endpoint traffic. På så sätt kan du övervaka utgående trafik bättre.This allows better monitoring of the outbound traffic. ASE-infrastrukturen kräver dock att tjänst slut punkter för SQL Server, lagring och Event Hubs konfigureras på ASE-undernätet.However, ASE infrastructure requires service endpoints for SQL Server, Storage, and Event Hubs to be configured on the ASE subnet. Se hur du låser en app service-miljön för diskussion om brand Väggs integrering.See the Locking down an App Service Environment for discussion on firewall integration. Den här implementeringen använder dessutom CosmosDB i direkt anslutnings läge, vilket kräver att ett port intervall öppnas.Additionally, this implementation uses CosmosDB in direct connection mode, which requires a range of ports to be opened up. Detta kan komplicera brand Väggs konfigurationen.This may complicate the firewall configuration. För enkelhetens skull konfigurerar denna referens arkitektur alla tjänst slut punkter i ASE-undernätet i stället för brand Väggs under nätet.For simplicity, this reference architecture configures all service endpoints on the ASE subnet instead of the firewall subnet. Detta inkluderar slut punkter för Service Bus, CosmosDB och Key Vault, förutom de som krävs av ASE-infrastrukturen.This includes endpoints for Service Bus, CosmosDB, and Key Vault, in addition to those required by the ASE infrastructure.

Se Konfigurera Azure-brandväggen med din ASE för att lära dig hur brand väggen integreras med ASE.See Configuring Azure Firewall with your ASE to learn how firewall is integrated with the ASE. All trafik som inte går över tjänstens slut punkter och tabell över virtuella nätverks vägar kommer att övervakas och bryggas av brand väggen.Any traffic not going over the service endpoints and virtual network route table, will be monitored and gated by the firewall. Behovet av routningstabellen beskrivs i följande avsnitt.The need for the route table is described in the following section.

ASE hantering av IP-adresserASE Management IPs

ASE hanterings trafik flödar genom det virtuella Enterprise-nätverket.The ASE management traffic flows through the enterprise virtual network. Trafiken ska dirigeras direkt till dedikerade IP-adresser utanför det virtuella nätverket, så att brand väggen undviks.This traffic should be routed directly to the dedicated IP addresses outside the virtual network, avoiding the firewall. Detta uppnås genom att skapa en användardefinierad virtuell nätverks väg tabell.This is achieved by creating a user-defined virtual network route table. I artikeln App Service-miljön hanterings adresser visas de här IP-adresserna.The article App Service Environment management addresses lists these IP addresses. Den här listan kan ta för lång tid att konfigureras manuellt i brand väggen.This list can get too long to be configured in the firewall manually. Den här implementeringen visar hur det kan fyllas i program mässigt.This implementation shows how this can be populated programmatically. Följande rad i deploy_std. sh hämtar den här listan med Azure CLI och JQ, en JSON-parser för kommando raden:The following line in the deploy_std.sh obtains this list using Azure CLI and jq, a command line JSON parser:

ENDPOINTS_LIST=$(az rest --method get --uri $ASE_ID/inboundnetworkdependenciesendpoints?api-version=2016-09-01 | jq '.value[0].endpoints | join(", ")' -j)

Detta motsvarar den dokumenterade metoden för att Hämta hanterings adresser från API.This is equivalent to the documented method of getting the management addresses from API.

Följande kommandon i deploy_std. sh skapar det virtuella nätverket tillsammans med routningstabellen, enligt vad som kon figurer ats i network.jspå:The following commands in the deploy_std.sh create the virtual network along with the route table, as configured in the network.json:

VNET_NAME=$(az network vnet list -g $RGNAME --query "[?contains(addressSpace.addressPrefixes, '${NET_PREFIX}')]" --query [0].name -o tsv)
az deployment group create --resource-group $RGNAME --template-file templates/network.json --parameters existentVnetName=$VNET_NAME vnetAddressPrefix=$NET_PREFIX
VNET_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetName.value -o tsv)
VNET_ROUTE_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetRouteName.value -o tsv)

När ASE-undernätet skapas är routningstabellen kopplad till den:When the ASE subnet is created, the route table is associated with it:

az deployment group create --resource-group $RGNAME --template-file templates/ase.json -n ase --parameters vnetName=$VNET_NAME vnetRouteName=$VNET_ROUTE_NAME aseSubnetAddressPrefix=$ASE_PREFIX

När brand väggen skapas uppdaterar firewall.jsi konfigurations filen den här ROUTNINGSTABELLEN med ASE hanterings-IP-adresser, följt av brand Väggs-IP: n.When the firewall is created, the firewall.json configuration file updates this route table with the ASE management IPs, followed by the firewall IP. Detta styr den återstående trafiken genom brand Väggs-IP:This drives the remaining traffic through the firewall IP:

"variables": {
    "firewallSubnetName": "AzureFirewallSubnet",
    "firewallPublicIpName": "[concat('firewallIp', '-', uniqueString(resourceGroup().id))]",
    "firewallName": "[concat('firewall', '-', uniqueString(resourceGroup().id))]",
    "aseManagementEndpoints": "[split(replace(parameters('aseManagementEndpointsList') ,' ', ''), ',')]",
    "copy": [
      {
        "name": "aseManagementIpRoutes",
        "count": "[length(variables('aseManagementEndpoints'))]",
        "input": {
          "name": "[replace(variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')], '/', '-')]",
          "properties": {
            "addressPrefix": "[variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')]]",
            "nextHopType": "Internet"
          }
        }
      }
    ]
  },
  "resources": [
    {
      "type": "Microsoft.Network/routeTables",
      "apiVersion": "2019-11-01",
      "name": "[parameters('vnetRouteName')]",
      "location": "[parameters('location')]",
      "tags": {
        "displayName": "UDR - Subnet"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Network/azureFirewalls', variables('firewallName'))]"
      ],
      "properties": {
        "routes": "[concat(variables('aseManagementIpRoutes'), array(json(concat('{ \"name\": \"Firewall\", \"properties\": { \"addressPrefix\": \"0.0.0.0/0\", \"nextHopType\": \"VirtualAppliance\", \"nextHopIpAddress\": \"', reference(concat('Microsoft.Network/azureFirewalls/', variables('firewallName')),'2019-09-01','Full').properties.ipConfigurations[0].properties.privateIPAddress, '\" } }'))))]"
      }
    },

Hanterings-IP-listan kan ändras efter att routningstabellen har distribuerats, vilket innebär att den här routningstabellen måste distribueras om.The management IP list may change after the route table is deployed, in which case this route table will need to be redeployed.

Azure Active DirectoryAzure Active Directory

Azure Active Directory tillhandahåller säkerhetsfunktioner för att autentisera program och ge åtkomst till resurser.Azure Active Directory provides security features to authenticate applications and authorize access to resources. Den här referens arkitekturen använder två viktiga funktioner i Azure Active Directory: hanterade identiteter och rollbaserad åtkomst kontroll.This reference architecture uses two key features of Azure Active Directory: managed identities, and role based access control.

När du skapar moln program måste de autentiseringsuppgifter som krävs för att autentisera till moln tjänster skyddas.When building cloud applications, the credentials required to authenticate to cloud services, must be secured. Vi rekommenderar att autentiseringsuppgifterna aldrig visas på arbets stationer för utvecklare eller checkas in i käll kontrollen.Ideally, the credentials should never appear on developer workstations or checked into source control. Azure Key Vault är ett sätt att lagra autentiseringsuppgifter och hemligheter på ett säkert sätt, men appen måste ändå autentisera till Key Vault för att hämta dem.Azure Key Vault provides a way to securely store credentials and secrets, but the app still has to authenticate to Key Vault to retrieve them. Hanterade identiteter för Azure-resurser tillhandahåller Azure-tjänster med en automatiskt hanterad identitet i Azure AD.Managed Identities for Azure resources provides Azure services with an automatically managed identity in Azure AD. Den här identiteten kan användas för att autentisera till alla tjänster som stöder Azure AD-autentisering, inklusive Key Vault, utan några autentiseringsuppgifter i programmet.This identity can be used to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in the application.

Rollbaserad åtkomst kontroll eller RBAC hanterar åtkomst till Azure-resurser.Role-based access control or RBAC manages access to Azure resources. Det här omfattar:This includes:

  • vilken entitet som har åtkomst: användare, hanterad identitet, säkerhets objekt.which entity has the access: user, managed identity, security principal.
  • vilken typ av åtkomst den har: ägare, deltagare, läsare, administratör.what type of access it has: owner, contributor, reader, admin.
  • åtkomstens omfattning: resurs, resurs grupp, prenumeration eller hanterings grupp.scope of the access: resource, resource group, subscription, or management group.

Du kan låsa åtkomsten till ASE-program genom att noggrant kontrol lera vilken roll som krävs och vilken typ av åtkomst för varje app.You can lock down access to ASE applications by tightly controlling the role required and the type of access for each app. På så sätt kan flera appar distribueras på samma ASE från olika utvecklings team.This way, multiple apps can be deployed on the same ASE from different development teams. Klient delen kan till exempel hanteras av ett team och Server delen av en annan.For example, the frontend might be handled by one team, and the backend by another. RBAC kan användas för att begränsa varje grupps åtkomst till de appar som den arbetar med.RBAC can be used to limit each team's access to the app(s) it is working on. Utforska anpassade roller i Azure RBAC för att skapa roller som är lämpliga för din organisation.Explore Custom roles in Azure RBAC to create roles suitable to your organization.

Key VaultKey Vault

Vissa tjänster har stöd för hanterade identiteter, men de använder RBAC för att ställa in behörigheter för appen.Some services support managed identities, however they use RBAC to set up permissions for the app. Se till exempel Service Bus Inbyggda RBAC-rollersamt RBAC i CosmosDB.For example, see Service Bus' built-in RBAC roles, as well as RBAC in CosmosDB. Ägar åtkomst till prenumerationen krävs för att bevilja dessa behörigheter, även om personal med deltagar åtkomst kan distribuera dessa tjänster.Owner access to the subscription is required for granting these permissions, even though personnel with Contributor access can deploy these services. För att göra det möjligt för en större grupp utvecklare att kunna köra distributions skripten är nästa bästa alternativet att använda sig av de inbyggda principerna för åtkomst kontroll för tjänsten:To allow a wider team of developers to be able to run the deployment scripts, the next best option is to use native access control policies of the service:

Anslutnings strängarna för dessa principer för åtkomst kontroll lagras sedan i Key Vault.The connection strings for these access control policies are then stored in the Key Vault. Själva valvet nås via hanterade identiteter, vilket inte kräver RBAC.The vault itself is accessed through managed identities, which does not require RBAC. Ange åtkomst principen för dessa anslutnings strängar på lämpligt sätt.Set the access policy for these connection strings appropriately. Till exempel skrivskyddad för Server delen, lässkyddad för klient delen och så vidare, i stället för att använda standard principen för rot åtkomst.For example, read-only for the backend, write-only for the frontend, and so on, instead of using default root access policy.

Följande kodfragment i services.jspå visar konfiguration av nyckel valvet för dessa tjänster:The following snippet in services.json shows the KeyVault configuration for these services:

    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/CosmosKey')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosName'))]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.DocumentDB/databaseAccounts',variables('cosmosName')),'2015-04-08').primaryMasterKey]"
      }
    },
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/ServiceBusListenerConnectionString')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'ListenerSharedAccessKey')]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'ListenerSharedAccessKey'),'2015-08-01').primaryConnectionString]"
      }
    },
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/ServiceBusSenderConnectionString')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'SenderSharedAccessKey')]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'SenderSharedAccessKey'),'2015-08-01').primaryConnectionString]"
      }
    },

Dessa anslutnings sträng värden används av apparna genom att referera till Key Vault nyckel/värde-paret.These connection string values are accessed by the apps, by referencing the Key Vault key/value pair. Detta görs i sites.jspå filen som följande kodfragment visas för röstnings appen:This is done in the sites.json file as the following snippet shows for the Voting App:

   "properties": {
        "enabled": true,
        "name": "[variables('votingWebName')]",
        "hostingEnvironment": "[variables('aseId')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('votingWebPlanName'))]",
        "siteConfig": {
          "appSettings": [
            {
...
...
...
            {
              "name": "ConnectionStrings:sbConnectionString",
              "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('serviceBusSenderConnectionStringSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
            },
...
...
            {
              "name": "ConnectionStrings:RedisConnectionString",
              "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('redisSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
            },
...
...
            {
              "name": "ConnectionStrings:CosmosKey",
              "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('cosmosKeySecretName')), '2016-10-01').secretUriWithVersion, ')')]"
            }

Funktionen kommer även åt Service Bus lyssnare-anslutningssträng på liknande sätt.The function also accesses the Service Bus listener connection string in a similar manner.

SkalbarhetsövervägandenScalability considerations

Utforma skalbara apparDesign scalable apps

Programmet i denna referens arkitektur är strukturerat så att enskilda komponenter kan skalas baserat på användning.The application in this reference architecture is structured so that individual components can be scaled based on usage. Varje webbapp, API och funktion distribueras i en egen App Service plan.Each web app, API, and function is deployed in its own App Service plan. Du kan övervaka varje app för Flask halsar i prestanda och sedan skala upp den vid behov.You can monitor each app for any performance bottlenecks, and then scale it up if required. Läs förbättra skalbarheten i ett Azure-webbprogram om du vill lära dig att utforma skalbara webb program med hjälp av Azure App Service.Read Improve scalability in an Azure web application to learn how to design scalable web applications using Azure App Service.

Automatisk skalning av app GatewayAutoscaling App Gateway

Autoskalning kan aktive ras på Azure Application Gateway v2.Autoscaling can be enabled on Azure Application Gateway V2. Detta gör det möjligt för app Gateway att skala upp eller ned baserat på trafik belastnings mönstren.This allows App Gateway to scale up or down based on the traffic load patterns. Den här referens arkitekturen konfigurerar autoscaleConfiguration i filen appgw.jspå för att skala mellan noll och 10 ytterligare instanser.This reference architecture configures autoscaleConfiguration in the file appgw.json to scale between zero and 10 additional instances. Mer information finns i skalnings Application Gateway och WAF v2 .See Scaling Application Gateway and WAF v2 for more details.

DistributionsövervägandenDeployment considerations

Distributions skripten i denna referens arkitektur används för att distribuera ASE, andra tjänster och programmen i ASE.The deployment scripts in this reference architecture are used to deploy ASE, other services, and the applications inside the ASE. När dessa program har distribuerats kan företag ha en plan för kontinuerlig integrering och distribution av program underhåll och-uppgraderingar.Once these applications are deployed, enterprises might want to have a plan for continuous integration and deployment for app maintenance and upgrades. I det här avsnittet visas några av de vanliga sätt som utvecklarna använder för CI/CD med ASE-program.This section shows some of the common ways developers use for CI/CD of ASE applications.

Appar kan bara distribueras till en intern ASE i det virtuella nätverket.Apps can be deployed to an internal ASE only from within the virtual network. Följande tre metoder används ofta för att distribuera ASE-appar:The following three methods are widely used to deploy ASE apps:

  1. Manuellt i Virtual Network – skapa en virtuell dator i ASE VNet med de verktyg som krävs för distributionen.Manually inside the Virtual Network - Create a virtual machine inside the ASE VNet with the required tools for the deployment. Öppna RDP-anslutningen till den virtuella datorn med en NSG-konfiguration.Open up the RDP connection to the VM using an NSG configuration. Kopiera kod artefakter till den virtuella datorn, byggs och distribueras till ASE-undernätet.Copy your code artifacts to the VM, build, and deploy to the ASE subnet. Det här är ett enkelt sätt att konfigurera en första utvecklings miljö för build och test.This is a simple way to set up an initial build and test development environment. Det rekommenderas dock inte för produktions miljön eftersom det inte kan skala det nödvändiga distributions flödet.It is however not recommended for production environment since it cannot scale the required deployment throughput.

  2. Peka på plats anslutning från lokal arbets Station – på så sätt kan du utöka ditt ASE VNet till utvecklings datorn och distribuera därifrån.Point to site connection from local workstation - This allows you to extend your ASE VNet to your development machine, and deploy from there. Det här är ett annat sätt att konfigurera en inledande utvecklings miljö och rekommenderas inte för produktion.This is another way to set up an initial dev environment, and not recommended for production.

  3. Via Azure-pipelines – detta implementerar en komplett CI/CD-pipeline, som slutar i en agent som finns i det virtuella nätverket.Through Azure Pipelines - This implements a complete CI/CD pipeline, ending in an agent located inside the VNet. Detta är idealiskt för produktions miljöer som kräver stora flöden av distribution.This is ideal for production environments requiring high throughput of deployment. Den Bygg pipelinen förblir helt utanför det virtuella nätverket.The build pipeline remains entirely outside the VNet. Den distribuera pipelinen kopierar de inbyggda objekten till bygg agenten i VNet och distribuerar sedan till ASE-undernätet.The deploy pipeline copies the built objects to the build agent inside the VNet, and then deploys to the ASE subnet. Mer information finns i den här diskussionen om den lokala Bygg agenten mellan pipelines och ASE VNet.For more information, read this discussion on the self-hosted build agent between Pipelines and the ASE VNet.

Användning av Azure-pipeline rekommenderas för produktions miljöer.Using Azure Pipelines is recommended for production environments. Skript CI/CD med hjälp av yaml-schemat i Azure hjälper till att automatisera bygg-och distributions processerna.Scripting CI/CD with the help of Azure Pipelines YAML schema helps to automate the build and deployment processes. Azure-pipelines. yml implementerar CI/CD-pipeline för webbappen i denna referens implementering.The azure-pipelines.yml implements such a CI/CD pipeline for the web app in this reference implementation. Det finns liknande CI/CD-skript för webb-API: et och funktionen.There are similar CI/CD scripts for the web API as well as the function. Läs Använd Azure-pipeline för att lära dig hur dessa används för att automatisera CI/CD för varje program.Read Use Azure Pipelines to learn how these are used to automate CI/CD for each application.

Vissa företag kanske inte vill behålla en permanent build-agent i VNet.Some enterprises may not want to maintain a permanent build agent inside the VNet. I så fall kan du välja att skapa en bygge-agent i DevOps-pipeline och avriva den när distributionen är klar.In that case, you can choose to create a build agent within the DevOps pipeline, and tear it down once the deployment is completed. Detta lägger till ett annat steg i DevOps, men minskar komplexiteten med att underhålla den virtuella datorn.This adds another step in the DevOps, however it lowers the complexity of maintaining the VM. Du kan även överväga att använda behållare som bygg agenter i stället för virtuella datorer.You may even consider using containers as build agents, instead of VMs. Bygg agenter kan också helt undvikas genom att distribuera från en zippad fil som placeras utanför VNet , vanligt vis i ett lagrings konto.Build agents can also be completely avoiding by deploying from a zipped file placed outside the VNet , typically in a storage account. Lagrings kontot måste vara tillgängligt från ASE.The storage account will need to be accessible from the ASE. Pipelinen ska kunna komma åt lagringen.The pipeline should be able to access the storage. I slutet av lanserings pipelinen kan en zippad fil släppas i blob-lagringen.At the end of the release pipeline, a zipped file can be dropped into the blob storage. ASE kan sedan välja att installera och distribuera.The ASE can then pick it up and deploy. Tänk på följande begränsningar för den här metoden:Be aware of the following limitations of this approach:

  • Det finns en från koppling mellan DevOps och den faktiska distributions processen, vilket leder till problem vid övervakning och spårning av eventuella distributions problem.There is a disconnect between the DevOps and the actual deployment process, leading to difficulties in monitoring and tracing any deployment issues.
  • I en låst miljö med säker trafik kan du behöva ändra reglerna för att få åtkomst till den zippade filen på lagrings platsen.In a locked down environment with secured traffic, you may need to change the rules to access the zipped file on the storage.
  • Du måste installera vissa tillägg och verktyg på ASE för att kunna distribuera från zip-filen.You will need to install specific extensions and tools on the ASE to be able to deploy from the zip.

Om du vill veta mer om hur appar kan distribueras till App Services planerna läser du App Service artiklar som fokuserar på distributions strategier.To know some more ways the apps can be deployed to the App Service plans, read the App Service articles focusing on deployment strategies.

KostnadsövervägandenCost considerations

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure.Use the Azure pricing calculator to estimate costs. Andra överväganden beskrivs i avsnittet Cost i Microsoft Azure Well-Architected Framework.Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework. Med Azure Reservations kan du spara pengar genom att registrera dig för en 1- eller 3-årsplan för flera Azure-resurser.Azure Reservations help you save money by committing to one-year or three-years plans for many Azure resources. Läs mer i artikeln köpa en reservation.Read more in the article Buy a reservation.

Här är några saker som du bör tänka på för några av de viktiga tjänster som används i den här arkitekturen.Here are some points to consider for some of the key services used in this architecture.

App Service EnvironmentApp Service Environment

Det finns olika pris alternativ för App Service.There are various pricing options available for App Service. En App Service miljö distribueras med hjälp av den isolerade tjänste planen.An App Service environment is deployed using the Isolated Service Plan. I den här planen finns det tre alternativ för CPU-storlekar – I1, I2 och i3.Within this plan, there are three options for CPU sizes - I1, I2, and I3. Den här referens implementeringen använder tre I1's per instans.This reference implementation is using three I1's per instance.

Application GatewayApplication Gateway

Application Gateway prissättning tillhandahåller olika pris alternativ för app Gateway.Application Gateway pricing provides various pricing options for App Gateway. Vi använder Application Gateway Standard_v2 och WAF_V2 SKU som stöder automatisk skalning och zon redundans.We are using the Application Gateway Standard_v2 and WAF_v2 SKU , that supports auto scaling and zone redundancy. Läs den här artikeln om du vill veta mer om den pris modell som används för den här SKU: n.Read this article to know more about the pricing model used for this SKU.

Azure Cache for RedisAzure Cache for Redis

Azure cache för Redis-prissättning ger de olika pris alternativen för den här tjänsten.Azure Cache for Redis pricing provides the various pricing options for this service. Den här arkitekturen använder Premium-SKU: n för stöd för virtuella nätverk.This architecture uses the Premium SKU , for the virtual network support.

Följande är pris sidor för andra tjänster som används för att låsa ASE:The following are pricing pages for other services used to lock down the ASE:

Distribuera lösningenDeploy the solution

Om du vill distribuera referens implementeringen för den här arkitekturen går du till README-GitHuboch följer skriptet för standard distribution .To deploy the reference implementation for this architecture, see the GitHub readme, and follow the script for standard deployment .

Nästa stegNext steps

Mer information om hur du utökar den här arkitekturen för att ge stöd för hög tillgänglighet finns i program distribution med hög tillgänglighet med hjälp av app Services miljöTo learn how to extend this architecture to support high availability, read High availability app deployment using App Services Environment.