App Services Ortamı kullanarak kurumsal dağıtım

Azure
App Service

Azure App Service , Azure 'da çeşitli uygulamaları barındırmak Için kullanılan PaaS hizmetidir: Web Apps, API Apps, işlevler ve mobil uygulamalar.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 ortamı veya Ao , kuruluşların, bulut iş yükleri için yalıtılmış, yüksek oranda ölçeklenebilir ve ayrılmış bir ortam sağlayarak App Service uygulamalarını kendi Azure sanal ağındaki bir alt ağda dağıtmasını sağlar.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.

Bu başvuru mimarisi, ASE kullanan ortak bir kurumsal iş yükünü ve bu iş yükünün güvenliğini artırmak için en iyi uygulamaları gösterir.This reference architecture demonstrates a common enterprise workload using ASE, and best practices to tighten security of this workload.

GitHub logosu Bu mimari için bir başvuru uygulama GitHub'da kullanılabilir.GitHub logo A reference implementation for this architecture is available on GitHub.

Standart ATıCı dağıtımı için başvuru mimarisi

MimariArchitecture

Bu mimarinin ana bileşeni App Service ortamıdır.The main component of this architecture is the App Service environment. Ao, iç Load Balancer (ıLB) ait BIR iç IP adresi ile genel bir IP adresi veya iç Ao olarak tek bir AO olarak dağıtılabilir.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). Bu başvuru mimarisi, kurumsal bir Web uygulamasını bir iç ASE 'de dağıtır ve ıLB ASE olarak da bilinir.This reference architecture deploys an enterprise web application in an internal ASE, also called an ILB ASE. Senaryonuz şunları gerektirdiğinde bir ıLB Ao kullanın:Use an ILB ASE when your scenario requires you to:

  • Siteden siteye veya ExpressRoute aracılığıyla erişebileceğiniz intranet uygulamalarını bulutta güvenli bir şekilde barındırın.Host intranet applications securely in the cloud, which you access through a site-to-site or ExpressRoute.
  • Bir WAF cihazındaki uygulamaları koruyun.Protect apps with a WAF device.
  • Genel DNS sunucularında listelenmeyen uygulamaları bulutta barındırma.Host apps in the cloud that aren't listed in public DNS servers.
  • Ön uç uygulamalarınızın güvenli bir şekilde tümleştirilebileceği, İnternet’ten yalıtılmış arka uç uygulamaları oluşturma.Create internet-isolated back-end apps, which your front-end apps can securely integrate with.

Bir ASE 'nin her zaman kuruluşun sanal ağı içindeki kendi alt ağında dağıtılması gerekir ve gelen ve giden trafiğin sıkı bir denetimine izin verir.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. Bu alt ağ içinde App Service uygulamalar, uygulamayı çalıştırmak için gerekli olan fiziksel kaynakların bir koleksiyonu olan bir veya daha fazla App Service planınadağıtılır.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. Karmaşıklık ve kaynak gereksinimlerine bağlı olarak, birden çok uygulama arasında App Service bir plan paylaşılabilir.Depending on the complexity and resource requirement, an App Service plan can be shared between multiple apps. Bu başvuru uygulaması, özel Web API 'SI ve bir işlevle etkileşime geçen Oylama uygulaması adlı bir Web uygulaması dağıtır.This reference implementation deploys a web app named Voting App, that interacts with a private web API and a function. Ayrıca, birden çok uygulama dağıtımını göstermek için test uygulaması adlı bir kukla Web uygulaması dağıtır.It also deploys a dummy web app named Test App to demonstrate multi-app deployments. Her bir App Service uygulaması kendi App Service planında barındırılır, her birinin gerektiğinde bağımsız olarak ölçeklendirilmesine olanak tanır.Each App Service app is hosted in its own App Service plan, allowing each to be scaled independently if necessary. Depolama ve işlem gibi bu barındırılan uygulamalar için gereken tüm kaynakların yanı sıra ölçekleme ihtiyaçları de App Service Ortamı altyapısı tarafından tam olarak yönetilir.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.

Bu uygulamadaki basit oylama uygulaması, kullanıcıların var olan girdileri görüntülemesine ve yeni giriş oluşturmasına izin verir.The simple voting app in this implementation, allows users to view existing or create new entries, as well as vote on the existing entries. Web API 'SI, girişlerin ve oylarının oluşturulması ve alınması için kullanılır.The web API is used for creation and retrieval of entries and votes. Verilerin kendisi SQL Server veritabanında depolanır.The data itself is stored in a SQL Server database. Web uygulaması, zaman uyumsuz veri güncelleştirmelerini göstermek için yeni eklenen oyları bir Service Bus örneğine göre sıralar.To demonstrate asynchronous data updates, the web app queues newly added votes in a Service Bus instance. İşlevi, sıraya alınan oyları seçer ve SQL veritabanını güncelleştirir.The function picks up queued votes and updates the SQL database. CosmosDB, Web uygulamasının tarayıcıda görüntülenmek üzere aldığı bir sahte ad depolamak için kullanılır.CosmosDB is used to store a mock-up ad, that the web app retrieves to display on the browser. Uygulama, önbellek yönetimi için Redsıs için Azure önbelleğini kullanır.The application uses Azure Cache for Redis for cache management. Reds için bir Premium katman Azure önbelleği, kendi alt ağında Ao ile aynı sanal ağ ile yapılandırmaya izin veren kullanılır.A Premium tier Azure Cache for Redis is used, which allows configuration to the same virtual network as the ASE, in its own subnet. Bu, önbelleğe gelişmiş güvenlik ve yalıtım sağlar.This provides enhanced security and isolation to the cache.

Web uygulamaları, uygulama ağ geçidi aracılığıyla internet erişimine açık olan tek bileşendir.The web apps are the only components accessible to the internet via the App Gateway. API ve işleve bir Internet istemcisinden erişilemez.The API and the function are inaccessible from an internet client. Gelen trafik, uygulama ağ geçidinde yapılandırılmış bir Web uygulaması güvenlik duvarı tarafından korunur.The inbound traffic is protected by a Web Application Firewall configured on the App Gateway.

Aşağıdaki hizmetler, Bu mimaride Ao 'nun kilitlenme anahtarıdır:The following services are key to locking down the ASE in this architecture:

Azure sanal ağı veya VNet, kuruluşun sahip olduğu özel bir Azure bulut ağı.Azure Virtual Network or VNet is a private Azure cloud network owned by the enterprise. Ağ tabanlı güvenlik ve yalıtım sağlar.It provides network-based security and isolation. ASE, kuruluşa ait VNet 'in bir alt ağına bir App Service dağıtımdır.ASE is an App Service deployment into a subnet of the enterprise-owned VNet. Kuruluşun ağ güvenlik grupları ve hizmet uç noktaları kullanarak ağ alanını ve eriştiği kaynakları sıkı bir şekilde denetlemesine olanak tanır.It allows the enterprise to tightly control that network space and the resources it accesses, using Network Security groups and Service Endpoints.

Application Gateway , TLS/SSL boşaltma ve Web uygulaması güvenlik duvarı (WAF) koruması ile uygulama düzeyinde bir Web trafiği yük dengeleyicidir.Application Gateway is an application-level web traffic load balancer, with TLS/SSL offloading, and web application firewall (WAF) protection. Genel bir IP adresini dinler ve trafiği ıLB Ao 'daki uygulama uç noktasına yönlendirir.It listens on a public IP address and routes traffic to the application endpoint in the ILB ASE. Bu uygulama düzeyinde yönlendirme olduğundan, trafiği aynı ıLB Ao içindeki birden çok uygulamaya yönlendirebilir.Since this is application-level routing, it can route traffic to multiple apps within the same ILB ASE. Uygulama ağ geçidinin birden çok siteyi nasıl desteklediğini öğrenmek için bkz. birden çok site barındırma Application Gateway .See Application Gateway multiple site hosting to learn how App Gateway supports multiple sites.

Azure Güvenlik Duvarı , giden trafiği Web uygulamasından kısıtlamak için kullanılır.Azure Firewall is used to restrict the outbound traffic from the web application. Hizmet uç noktası kanalları ve AX için gereken bir yol tablosu üzerinden gitilmemiş giden trafik, güvenlik duvarı alt ağına yönlendirilir.Outgoing traffic that does not go through the service endpoint channels and a route table required by ASE, is directed to the firewall subnet. Hizmet uç noktalarının izlenebilirlik için güvenlik duvarı alt ağında yapılandırılması önerilse de, her zaman mümkün olmayabilir.Although it is recommended for service endpoints to be configured on the firewall subnet for traceability, it may not be always feasible. Örneğin, Ao altyapısının AX alt ağında olması için bazı hizmet uç noktaları gereklidir.For example, some service endpoints are required by the ASE infrastructure to be on the ASE subnet. Kolaylık olması için, bu mimari Ao alt ağında tüm hizmet uç noktalarını yapılandırır.For simplicity, this architecture configures all service endpoints on the ASE subnet.

Azure Active Directory veya Azure AD, Azure kaynaklarına ve hizmetlerine erişim hakları ve izin yönetimi sağlar.Azure Active Directory or Azure AD provides access rights and permissions management to Azure resources and services. Yönetilen kimlikler , Azure AD tarafından otomatik olarak yönetilen hizmetlere ve uygulamalara kimlik atar.Managed Identities assigns identities to services and apps, automatically managed by Azure AD. Bu kimlikler, Azure AD kimlik doğrulamasını destekleyen herhangi bir hizmette kimlik doğrulaması yapmak için kullanılabilir.These identities can be used to authenticate to any service that supports Azure AD authentication. Bu, bu uygulamalar için kimlik bilgilerini açıkça yapılandırma gereksinimini ortadan kaldırır.This removes the need to explicitly configure credentials for these apps. Bu mimari Web uygulamasına yönetilen bir kimlik atar.This architecture assigns a managed identity to the web app.

Key Vault , uygulamalar için gereken tüm gizli dizileri ve kimlik bilgilerini depolar.Key Vault stores any secrets and credentials required by the apps. Gizli dizileri doğrudan uygulamada depolamak için bu seçeneği kullanın.Use this option over storing secrets directly in the application.

Azure Pipelines , Bu mimaride sürekli tümleştirme ve sürekli dağıtım özellikleri sağlar.Azure Pipelines provides Continuous Integration and Continuous Deployment capabilities in this architecture. ASE sanal ağın iç ağı olduğundan, sanal makine , App Service planlarına uygulama dağıtmak için VNET içinde bir sıçrama kutusu olarak kullanılır.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. İşlem hattı, uygulamaları VNet dışında oluşturur.The pipeline builds the apps outside the VNet. Gelişmiş güvenlik ve sorunsuz RDP/SSH bağlantısı için, en son yayınlanan Azure savunma 'yı sıçrama kutusu olarak kullanmayı düşünün.For enhanced security and seamless RDP/SSH connectivity, consider using the recently released Azure Bastion as the jumpbox.

Çok siteli yapılandırmaMulti-site configuration

Çok siteli dağıtım

İç ASE, HTTP uç noktaları ile çeşitli Web uygulamalarını ve API 'Leri barındırabilir.Internal ASE can host several web apps and APIs with HTTP endpoints. ILB IP 'si yalnızca sanal ağ içinden erişilebildiği için, bu uygulamalar genel İnternet 'ten kilitlidir.These applications are locked down from the public internet as the ILB IP is only accessible from within the Virtual Network. Application Gateway, bu uygulamaları Internet 'te seçmeli olarak göstermek için kullanılır.The Application Gateway is used to selectively expose these applications to the internet. ATıCı, her App Service uygulamasına varsayılan bir URL atar <default-appName>.<ASE-domain>.appserviceenvironment.net .ASE assigns a default URL to each App Service application as <default-appName>.<ASE-domain>.appserviceenvironment.net. Ao etki alanı adını Ao ıLB IP adresine eşleyen Özel BIR DNS bölgesi oluşturulur.A private DNS zone is created that maps the ASE domain name to the ASE ILB IP address. Bu, VNet 'teki uygulamalara erişmek için özel bir DNS kullanılmasını önler.This avoids using a custom DNS to access the apps within the VNet.

Uygulama ağ geçidi, bir dinleyicinin ağ geçidinin IP adresine yönelik ISTEKLER için HTTPS bağlantı noktasını dinlediği şekilde yapılandırılır.The App Gateway is configured such that a listener listens on the HTTPS port for requests to the Gateway's IP address. Kolaylık olması için, bu uygulama ortak bir DNS ad kaydı kullanmaz ve uygulama ağ geçidinin IP 'sine rastgele seçilmiş bir URL 'yi işaret etmek için bilgisayarınızdaki localhost dosyasını değiştirmenizi gerektirir.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. Basitlik için, dinleyici, bu istekleri işlemek için otomatik olarak imzalanan bir sertifika kullanır.For simplicity, the listener uses a self-signed certificate to process these requests. Uygulama ağ geçidinde her bir App Service uygulamasının varsayılan URL 'SI için arka uç havuzları vardır.The App Gateway has backend pools for each App Service application's default URL. Bir yönlendirme kuralı , dinleyiciyi arka uç havuzuna bağlanacak şekilde yapılandırılır.A routing rule is configured to connect the listener to the backend pool. Ağ geçidi ve ASE arasındaki bağlantının şifrelenip şifrelenmeyeceğini tespit eden http ayarları oluşturulur.HTTP settings are created that determine whether the connection between the gateway and the ASE will be encrypted. Bu ayarlar ayrıca, gelen HTTP ana bilgisayar üst bilgisini, arka uç havuzundan çekilen bir ana bilgisayar adıyla geçersiz kılmak için de kullanılır.These settings are also used to override the incoming HTTP host header with a host name picked from the backend pool. Bu uygulama, ağ geçidi tarafından güvenilen varsayılan ATıCı uygulama URL 'Leri için oluşturulan varsayılan sertifikaları kullanır.This implementation uses default certificates created for the default ASE app URLs, which are trusted by the gateway. İstek, karşılık gelen uygulamanın varsayılan URL 'sine yeniden yönlendirilir.The request is redirected to the default URL of the corresponding app. VNET 'e bağlı özel DNS bu isteği ıLB IP 'ye iletir.The private DNS linked to the VNet forwards this request to the ILB IP. Daha sonra bunu istenen App Service 'e iletir.The ASE then forward this to the requested App service. ASE uygulamalarındaki tüm HTTP iletişimleri özel DNS üzerinden ilerler.Any HTTP communication within the ASE apps, goes through the private DNS. Dinleyici, arka uç havuzu, yönlendirme kuralı ve HTTP ayarlarının her bir ASE uygulaması için uygulama ağ geçidinde yapılandırılması gerektiğini unutmayın.Note that the listener, backend pool, routing rule, and the HTTP settings need to be configured on the App Gateway for each ASE app.

Bu yapılandırmaların birden çok siteye izin vermek için nasıl yapıldığını anlamak için üzerindeappgw.js ve dns.jsüzerinde gezin.Explore appgw.json and dns.json to understand how these configurations are made to allow multiple sites. Adlı Web uygulaması, testapp Bu yapılandırmayı göstermek için oluşturulmuş boş bir uygulamadır.The web app named testapp is an empty app created to demonstrate this configuration. Bu JSON dosyalarına deploy_std. shdağıtım betiğiyle erişilir. Bunlara ayrıca yüksek kullanılabilirliğe sahip çok SITELI ASE dağıtımıiçin kullanılan deploy_ha. shtarafından erişilir.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.

Güvenlik konularıSecurity considerations

App Service OrtamıApp Service Environment

Şirket içi bir ASE, genel İnternet 'ten gizlenen kurumsal sanal ağda dağıtılır.An internal ASE is deployed in the enterprise virtual network, hidden from the public internet. Kuruluşun, Web API 'Leri ve işlevleri gibi arka uç hizmetlerini ağ düzeyinde kilitlemesine olanak tanır.It allows the enterprise to lock down their backend services, such as web APIs and functions, at the network level. HTTP uç noktası olan herhangi bir ASE uygulamasına, sanal ağ içinden ıLB aracılığıyla erişilebilir.Any ASE app with an HTTP endpoint, can be accessed through the ILB, from within the virtual network. Uygulama ağ geçidi, istekleri ıLB aracılığıyla Web uygulamasına iletecek şekilde yapılandırılmıştır.The App Gateway is configured to forward requests to the web app through the ILB. Web uygulamasının kendisi, API 'ye erişmek için ıLB aracılığıyla geçer.The web app itself goes through the ILB to access the API. Kritik arka uç bileşenlerinin, yani API ve işlevi, genel İnternet 'ten etkin bir şekilde erişilemez.The critical backend components, that is, the API and the function, are effectively inaccessible from the public internet.

Varsayılan sertifikalar, Ao tarafından atanan varsayılan etki alanı adı için her bir App Service için oluşturulur.Default certificates are created for each App service for the default domain name assigned by ASE. Bu sertifika, ağ geçidi ile uygulama arasındaki trafiğin güvenliğini güçedebilir ve belirli senaryolarda gerekli olabilir.This certificate can tighten the security of the traffic between the gateway and the app, and may be required in certain scenarios. Bu sertifikalar istemci tarayıcısı tarafından görülemeyecektir, yalnızca uygulama ağ geçidinde yapılandırılan sertifikalara yanıt verebilir.These certificates will not be visible by the client browser, it can only respond to the certificates configured at the App Gateway.

Uygulama ağ geçidiApp Gateway

Başvuru uygulaması, uygulama ağ geçidini üzerindeappgw.jsprogram aracılığıyla yapılandırır.The reference implementation configures the App Gateway programmatically in the appgw.json. Deploy_std. sh dosyası, ağ geçidini dağıtmakta bu yapılandırmayı kullanır: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)

ŞifrelemeEncryption

Application Gateway Ile TLS sonlandırmasına ve uçtan uca TLS 'ye genel bakışbölümünde açıklandığı gibi, uygulama ağ geçidi, Web tarayıcılarındaki tüm trafiği şifrelemek ve korumak Için Aktarım KATMANı güvenliği (TLS)/Güvenli Yuva Katmanı (SSL) kullanabilir.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. Şifreleme, aşağıdaki yollarla yapılandırılabilir:Encryption can be configured in the following ways:

  1. Şifreleme ağ geçidinde sonlandırıldı.Encryption terminated at the gateway. Bu durumda, arka uç havuzları HTTP için yapılandırılmıştır.The backend pools in this case are configured for HTTP. Şifreleme ağ geçidinde duraklar ve ağ geçidi ile App Service arasındaki trafik şifrelenmemiş olur.The encryption stops at the gateway, and traffic between the gateway and the app service is unencrypted. Şifreleme CPU açısından yoğun olduğundan, arka uçta şifrelenmemiş trafik performansı artırır ve daha basit sertifika yönetimine olanak tanır.Since encryption is CPU-intensive, unencrypted traffic at the backend improves performance and allows simpler certificate management. Bu, arka ucun ağ yapılandırmasının sanallaştırılan güvenliği sağladığından makul bir güvenlik düzeyi sağlar.This provides a reasonable level of security since the backend is secured by virtue of the network configuration.

  2. Uçtan uca şifreleme.End to end encryption. Belirli güvenlik veya uyumluluk gereksinimleri gibi bazı senaryolarda trafiğin ağ geçidi ile uygulama arasında şifrelenmesi gerekebilir.In some scenarios, such as specific security or compliance requirements, the traffic might be required to be encrypted between the gateway and the app. Bu, HTTPS bağlantısı kullanılarak sağlanır ve arka uç havuzunda sertifikaları yapılandırır.This is achieved by using HTTPS connection, and configuring certificates at the backend pool.

Bu başvuru uygulaması, uygulama ağ geçidi için otomatik olarak imzalanan sertifikalar kullanır.This reference implementation uses self-signed certificates for App Gateway. Üretim kodu için, bir sertifika yetkilisi tarafından verilen bir sertifika kullanılmalıdır.For production code, a certificate issued by a Certificate Authority should be used. Desteklenen sertifika türlerinin listesi için, TLS sonlandırma için desteklenen sertifikalarıokuyun.For a list of supported certificate types, read Certificates supported for TLS termination. Ağ Geçidi ile sonlandırılmış şifreleme oluşturmayı öğrenmek için Azure Portal kullanarak bir uygulama ağ GEÇIDINI TLS sonlandırmasıyla yapılandırma makalesini okuyun.Read Configure an application gateway with TLS termination using the Azure portal to learn how to create Gateway-terminated encryption. appgw.jsaşağıdaki kod satırları programlı bir şekilde yapılandırılır: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
              }
            }
          },

ATıCı ve ağ geçidinde bulunan Web uygulamaları arasındaki trafik için varsayılan SSL sertifikaları kullanılır.For traffic between the web apps on the ASE and the gateway, the default SSL certificates are used. Bu uygulamadaki arka uç havuzları, Web Apps ile ilişkili varsayılan etki alanı adları tarafından geçersiz kılınan ana bilgisayar adı ile HTTPS trafiğini yeniden yönlendirmek üzere yapılandırılmıştır.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. Uygulama ağ geçidi, Microsoft tarafından yayımlandıklarından bu yana varsayılan SSL sertifikalarına güvenir.The App Gateway trusts the default SSL certificates since they are issued by Microsoft. Bu yapılandırmaların nasıl yapıldığını öğrenmek için Application Gateway Ile yapılandırma App Service okuyun.Read Configure App Service with Application Gateway to know how these configurations are made. appgw.jsüzerindeki aşağıdaki satırlar, bunun başvuru uygulamasında nasıl yapılandırıldığını göstermektedir: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)]"
                }
              }
            }
          },

Web Uygulaması Güvenlik DuvarıWeb Application Firewall

Application Gateway Web uygulaması güvenlik duvarı (WAF) , Web uygulamalarını SQL ekleme gibi kötü amaçlı saldırılara karşı korur.Web Application Firewall (WAF) on the Application Gateway protects the web apps from malicious attacks, such as SQL injection. Ayrıca, gerçek zamanlı günlük kullanılarak gerçekleştirilen saldırıları izlemek için Azure Izleyici ile de tümleştirilir.It is also integrated with Azure Monitor, to monitor attacks using a real-time log. Azure Portal kullanarak Web uygulaması güvenlik duvarı ile uygulama ağ geçidi oluşturmabölümünde açıklandığı gıbı, WAF 'nin ağ geçidinde etkinleştirilmesi gerekir.WAF needs to be enabled on the gateway, as described in Create an application gateway with a Web Application Firewall using the Azure portal. Başvuru uygulama, aşağıdaki kod parçacığı ile dosyadaki appgw.jsprogram aracılığıyla WAF 'yi sunar: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"
        },

Sanal AğVirtual Network

Ağ güvenlik grupları , VNET 'teki bir veya daha fazla alt ağ ile ilişkilendirilebilir.Network security groups can be associated with one or more subnets in the VNet. Bunlar, çeşitli Azure kaynakları arasında trafik akışına izin veren veya reddeden güvenlik kurallarıdır.These are security rules that allow or deny traffic to flow between various Azure resources. Bu mimari her alt ağ için ayrı bir NSG 'yi ilişkilendirir.This architecture associates a separate NSG for each subnet. Bu, alt ağda yer alan hizmet (ler) de dahil olmak üzere bu kuralların alt ağ başına ince olarak ayarlanmasını sağlar.This allows fine-tuning of these rules per subnet, as per the service(s) contained in that subnet. Örneğin, "type": "Microsoft.Network/networkSecurityGroups" aken alt ağı için NSG 'nin üzerindekiase.js Için yapılandırma ve uygulama ağ geçidi alt ağı için nsg için appgw.js dosyasında için yapılandırmayı inceleyin.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.

Hizmet uç noktaları , Azure hizmetlerini desteklemek için sanal ağınızın özel adres alanını ve kimliğini genişlettecek ve bu hizmetlere erişimi yalnızca VNET 'iniz ile kısıtlıyor.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. Gelişmiş güvenlik için, hizmet uç noktalarının kendisini destekleyen herhangi bir Azure hizmeti için ASE alt ağında etkinleştirilmesi gerekir.For improved security, service endpoints should be enabled on the ASE subnet for any Azure service that supports it. Daha sonra hizmet, hizmette sanal ağ kuralları ayarlanarak, genel İnternet 'ten erişimi etkin bir şekilde engelleyerek kurumsal VNet ile güvenli hale getirilir.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 altyapısı, Bu makalenin sistem mimarisi bölümündebelirtildiği gibi, mimarinin kendi yönetimi Için Olay Hub 'ı, SQL Server ve depolama için hizmet uç noktalarını ayarlar.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. Bu mimari, kullanılan hizmetler için hizmet uç noktalarını yapılandırır: Service Bus, SQL Server, Key Vault ve CosmosDB.This architecture configures service endpoints for the services used, that support this: Service Bus, SQL Server, Key Vault, and CosmosDB. ase.jsüzerindekibu yapılandırmayı farklı bir şekilde gezin "type": "Microsoft.Network/virtualNetworks/subnets" --> "properties" --> "serviceEndpoints" .Explore this configuration in the ase.json, as "type": "Microsoft.Network/virtualNetworks/subnets" --> "properties" --> "serviceEndpoints".

Bir alt ağda hizmet uç noktalarının etkinleştirilmesi iki adımlı bir işlemdir.Enabling service endpoints on a subnet is a two-step process. Kaynakların, bu sanal ağdan gelen hizmet uç noktalarında trafik alacak şekilde yapılandırılması gerekir.The resources themselves need to be configured to receive traffic on the service endpoints from this virtual network. Daha fazla bilgi için, bir kaynağa ağ erişimini kısıtla konusunu okuyun.For more information, read Restrict network access to a resource .

Güvenlik duvarıFirewall

Azure Güvenlik Duvarı ve hizmet uç noktaları birbirini tamamlayanı.Azure Firewall and service endpoints complement each other. Hizmet uç noktaları, gelen trafiği sanal ağınızdan itibaren kısıtlayarak kaynakları koruurken, Azure Güvenlik Duvarı, uygulamalardan giden trafiği kısıtlamanıza olanak sağlar.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. Tüm giden trafiğin, hizmet uç noktası trafiği dahil olmak üzere güvenlik duvarı alt ağından geçmesini sağlamak önerilir.It is recommended to let all outbound traffic to pass through the firewall subnet, including service endpoint traffic. Bu, giden trafiğin daha iyi izlenmesini sağlar.This allows better monitoring of the outbound traffic. Ancak, Ao altyapısı, AI alt ağında SQL Server, depolama ve Event Hubs yapılandırmak için hizmet uç noktaları gerektirir.However, ASE infrastructure requires service endpoints for SQL Server, Storage, and Event Hubs to be configured on the ASE subnet. Güvenlik Duvarı tümleştirmesi hakkında tartışma için App Service ortamı kilitleme bölümüne bakın.See the Locking down an App Service Environment for discussion on firewall integration. Ayrıca, bu uygulama doğrudan bağlantı modunda Cosmosdbkullanır ve bu da bir dizi bağlantı noktasının açılmasını gerektirir.Additionally, this implementation uses CosmosDB in direct connection mode, which requires a range of ports to be opened up. Bu işlem, güvenlik duvarı yapılandırmasını karmaşıklaştırır.This may complicate the firewall configuration. Kolaylık olması için bu başvuru mimarisi, tüm hizmet uç noktalarını güvenlik duvarı alt ağı yerine as alt ağında yapılandırır.For simplicity, this reference architecture configures all service endpoints on the ASE subnet instead of the firewall subnet. Bu, Ao altyapısının gerektirenlere ek olarak Service Bus, CosmosDB ve Key Vault uç noktaları içerir.This includes endpoints for Service Bus, CosmosDB, and Key Vault, in addition to those required by the ASE infrastructure.

Güvenlik duvarının Ao ile nasıl tümleştirildiği hakkında bilgi edinmek için bkz. Azure Güvenlik Duvarı 'Nı Aşirle yapılandırma .See Configuring Azure Firewall with your ASE to learn how firewall is integrated with the ASE. Hizmet uç noktaları ve sanal ağ yolu tablosundan geçmeden trafik, güvenlik duvarı tarafından izlenir ve alınır.Any traffic not going over the service endpoints and virtual network route table, will be monitored and gated by the firewall. Yol tablosu gereksinimi aşağıdaki bölümde açıklanmıştır.The need for the route table is described in the following section.

ATıCı yönetimi IP 'LeriASE Management IPs

ASE yönetimi trafiği, kurumsal sanal ağ üzerinden akar.The ASE management traffic flows through the enterprise virtual network. Bu trafik, sanal ağın dışındaki özel IP adreslerine doğrudan yönlendirilmelidir ve güvenlik duvarından kaçınılmalıdır.This traffic should be routed directly to the dedicated IP addresses outside the virtual network, avoiding the firewall. Bu, Kullanıcı tanımlı bir sanal ağ yolu tablosuoluşturularak elde edilir.This is achieved by creating a user-defined virtual network route table. Yönetim adresleri App Service ortamı MAKALESINDE bu IP adresleri listelenir.The article App Service Environment management addresses lists these IP addresses. Bu listenin güvenlik duvarında el ile yapılandırılması çok uzun sürebilir.This list can get too long to be configured in the firewall manually. Bu uygulama, bunun nasıl program aracılığıyla doldurulamayacağını gösterir.This implementation shows how this can be populated programmatically. Deploy_std. sh dosyasında aşağıdaki satır, bu LISTEYI Azure CLI ve JQkullanarak bir komut satırı JSON ayrıştırıcısı ile edinir: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)

Bu, API 'den yönetim adreslerini almamakalesinde belgelenen yönteme eşdeğerdir.This is equivalent to the documented method of getting the management addresses from API.

Deploy_std. sh içindeki aşağıdaki komutlar, network.jsüzerindeyapılandırıldığı şekilde, sanal ağı yol tablosuyla birlikte oluşturun: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)

Ao alt ağı oluşturulduğunda, yol tablosu onunla ilişkilendirilir: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

Güvenlik Duvarı oluşturulduğunda, yapılandırma dosyası firewall.js bu yol tablosunu atıcı yönetim IP 'leri ile ve ardından Güvenlik Duvarı IP 'si ile güncelleştirir.When the firewall is created, the firewall.json configuration file updates this route table with the ASE management IPs, followed by the firewall IP. Bu, kalan trafiği güvenlik duvarı IP 'si üzerinden yürütür: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, '\" } }'))))]"
      }
    },

Yönetim IP listesi, yol tablosu dağıtıldıktan sonra değişebilir, bu durumda bu yol tablosunun yeniden dağıtılması gerekir.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, uygulamaların kimliğini doğrulamak ve kaynaklara erişimi yetkilendirmek için güvenlik özellikleri sağlar.Azure Active Directory provides security features to authenticate applications and authorize access to resources. Bu başvuru mimarisi Azure Active Directory: Yönetilen kimlikler ve Azure rol tabanlı erişim denetimi 'nin iki temel özelliğini kullanır.This reference architecture uses two key features of Azure Active Directory: managed identities, and Azure role-based access control.

Bulut uygulamaları derlerken, bulut hizmetlerinde kimlik doğrulaması için gereken kimlik bilgileri güvenli olmalıdır.When building cloud applications, the credentials required to authenticate to cloud services, must be secured. İdeal olarak, kimlik bilgileri geliştirici iş istasyonlarında hiçbir şekilde gösterilmemelidir veya kaynak denetimine iade edilmelidir.Ideally, the credentials should never appear on developer workstations or checked into source control. Azure Key Vault, kimlik bilgilerini ve gizli dizileri güvenli bir şekilde saklamak için bir yol sağlar, ancak uygulamanın yine de bunları almak için Key Vault kimlik doğrulaması gerekir.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. Azure kaynakları Için Yönetilen kimlikler Azure AD 'de otomatik olarak yönetilen bir kimlikle Azure hizmetleri sağlar.Managed Identities for Azure resources provides Azure services with an automatically managed identity in Azure AD. Bu kimlik, uygulamada kimlik bilgileri olmadan Key Vault dahil olmak üzere Azure AD kimlik doğrulamasını destekleyen herhangi bir hizmette kimlik doğrulaması yapmak için kullanılabilir.This identity can be used to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in the application.

Azure rol tabanlı erişim denetimi (Azure RBAC) , Azure kaynaklarına erişimi yönetir.Azure role-based access control (Azure RBAC) manages access to Azure resources. Şunları içerir:This includes:

  • hangi varlık erişimi vardır: Kullanıcı, yönetilen kimlik, güvenlik sorumlusu.which entity has the access: user, managed identity, security principal.
  • Ne tür erişim vardır: sahip, katkıda bulunan, okuyucu, yönetici.what type of access it has: owner, contributor, reader, admin.
  • erişim kapsamı: kaynak, kaynak grubu, abonelik veya yönetim grubu.scope of the access: resource, resource group, subscription, or management group.

Gerekli rolü ve her bir uygulama için erişim türünü sıkı bir şekilde denetleyerek Ao uygulamalarına erişimi azaltabilirsiniz.You can lock down access to ASE applications by tightly controlling the role required and the type of access for each app. Bu şekilde, birden çok uygulama farklı geliştirme ekiplerinden aynı ada dağıtılabilir.This way, multiple apps can be deployed on the same ASE from different development teams. Örneğin, ön uç bir ekip tarafından ve arka uç başka bir takım tarafından işlenebilir.For example, the frontend might be handled by one team, and the backend by another. Azure RBAC, her ekibin üzerinde çalıştığı uygulama (ler) e erişimini sınırlamak için kullanılabilir.Azure RBAC can be used to limit each team's access to the app(s) it is working on. Kuruluşunuza uygun roller oluşturmak için Azure özel rollerini keşfedebilirsiniz.Explore Azure custom roles to create roles suitable to your organization.

Key VaultKey Vault

Bazı hizmetler yönetilen kimlikleri destekler, ancak uygulama izinlerini ayarlamak için Azure RBAC kullanırlar.Some services support managed identities, however they use Azure RBAC to set up permissions for the app. Örneğin, Service Bus ' yerleşik rollerininyanı sıra Azure Cosmos DB Azure RBAC' na bakın.For example, see Service Bus' built-in roles, as well as Azure RBAC in Azure Cosmos DB. Bu izinleri vermek için aboneliğe sahip erişimi gereklidir, ancak katkıda bulunan erişimi olan personel bu hizmetleri dağıtabilir.Owner access to the subscription is required for granting these permissions, even though personnel with Contributor access can deploy these services. Geliştiricilerin daha geniş bir takımının Dağıtım betiklerini çalıştırmasına izin vermek için, bir sonraki en iyi seçenek, hizmetin yerel erişim denetim ilkelerini kullanmaktır: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:

Bu erişim denetimi ilkelerine ait bağlantı dizeleri daha sonra Key Vault depolanır.The connection strings for these access control policies are then stored in the Key Vault. Kasaya Azure RBAC gerektirmeyen Yönetilen kimlikler üzerinden erişilir.The vault itself is accessed through managed identities, which does not require Azure RBAC. Bu bağlantı dizeleri için erişim ilkesini uygun şekilde ayarlayın.Set the access policy for these connection strings appropriately. Örneğin, arka uç için salt okunurdur, ön uç için salt yazılır ve varsayılan kök erişim ilkesini kullanmak yerine bu şekilde devam eder.For example, read-only for the backend, write-only for the frontend, and so on, instead of using default root access policy.

services.js ' de aşağıdaki kod parçacığında, bu hizmetler Için Anahtar Kasası yapılandırması gösterilmektedir: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]"
      }
    },

Bu bağlantı dizesi değerlerine Key Vault anahtar/değer çiftine başvurarak uygulamalar tarafından erişilir.These connection string values are accessed by the apps, by referencing the Key Vault key/value pair. Bu, oylama uygulaması için aşağıdaki kod parçacığında gösterildiği gibi dosyada sites.js yapılır: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, ')')]"
            }

İşlev Ayrıca Service Bus dinleyici bağlantı dizesine benzer bir şekilde erişir.The function also accesses the Service Bus listener connection string in a similar manner.

Ölçeklenebilirlik konusunda dikkat edilmesi gerekenlerScalability considerations

Ölçeklenebilir uygulamalar tasarlamaDesign scalable apps

Bu başvuru mimarisinde bulunan uygulama, tek tek bileşenlerin kullanıma göre ölçeklendirilebilmeleri için yapılandırılmıştır.The application in this reference architecture is structured so that individual components can be scaled based on usage. Her Web uygulaması, API ve işlevi kendi App Service planına dağıtılır.Each web app, API, and function is deployed in its own App Service plan. Her bir uygulamayı herhangi bir performans sorunu için izleyebilir ve gerekirse ölçeklendirebilirsiniz .You can monitor each app for any performance bottlenecks, and then scale it up if required. Azure App Service kullanarak ölçeklenebilir Web uygulamaları tasarlamayı öğrenmek için bir Azure Web uygulamasındaki ölçeklenebilirliği geliştirme konusunu okuyun.Read Improve scalability in an Azure web application to learn how to design scalable web applications using Azure App Service.

Uygulama ağ geçidini otomatik ölçeklendirmeAutoscaling App Gateway

Otomatik ölçeklendirme, Azure Application Gateway v2 üzerinde etkinleştirilebilir.Autoscaling can be enabled on Azure Application Gateway V2. Bu, uygulama ağ geçidinin trafik yükü düzenlerine göre ölçeği artırma veya azaltma olanağı sağlar.This allows App Gateway to scale up or down based on the traffic load patterns. Bu başvuru mimarisi autoscaleConfiguration , sıfır ve 10 ek örnek arasında ölçeklendirmek için appgw.js dosya içinde yapılandırır.This reference architecture configures autoscaleConfiguration in the file appgw.json to scale between zero and 10 additional instances. Daha fazla ayrıntı için bkz. ölçek Application Gateway ve WAF v2 .See Scaling Application Gateway and WAF v2 for more details.

Dağıtma konularıDeployment considerations

Bu başvuru mimarisinde dağıtım betikleri Ao, diğer hizmetleri ve Ao 'nun içindeki uygulamaları dağıtmak için kullanılır.The deployment scripts in this reference architecture are used to deploy ASE, other services, and the applications inside the ASE. Bu uygulamalar dağıtıldıktan sonra kuruluşlar, uygulama bakımı ve yükseltmeleri için sürekli tümleştirme ve dağıtım planına sahip olmak isteyebilir.Once these applications are deployed, enterprises might want to have a plan for continuous integration and deployment for app maintenance and upgrades. Bu bölümde, geliştiricilerin Ao uygulamalarının CI/CD 'si için kullanacağı bazı yaygın yollar gösterilmektedir.This section shows some of the common ways developers use for CI/CD of ASE applications.

Uygulamalar yalnızca sanal ağ içinden bir iç aya dağıtılabilir.Apps can be deployed to an internal ASE only from within the virtual network. Ao uygulamalarını dağıtmak için aşağıdaki üç yöntem yaygın olarak kullanılır:The following three methods are widely used to deploy ASE apps:

  1. Sanal ağ Içinde el ile -dağıtım için gerekli araçları kullanarak ASE VNET içinde bir sanal makine oluşturun.Manually inside the Virtual Network - Create a virtual machine inside the ASE VNet with the required tools for the deployment. Bir NSG yapılandırması kullanarak VM 'ye RDP bağlantısı açın.Open up the RDP connection to the VM using an NSG configuration. Kod yapıtlarınızı VM 'ye kopyalayın, derleyin ve as alt ağına dağıtın.Copy your code artifacts to the VM, build, and deploy to the ASE subnet. Bu, ilk derleme ve test geliştirme ortamını ayarlamaya yönelik basit bir yoldur.This is a simple way to set up an initial build and test development environment. Ancak, gerekli dağıtım verimini ölçeklendiremediğinden üretim ortamında önerilmez.It is however not recommended for production environment since it cannot scale the required deployment throughput.

  2. Yerel iş istasyonundan site bağlantısı noktası -bu, ASE VNET 'nizi geliştirme makinenize genişletmenizi ve buradan dağıtmanızı sağlar.Point to site connection from local workstation - This allows you to extend your ASE VNet to your development machine, and deploy from there. Bu, ilk geliştirme ortamını ayarlamaya yönelik başka bir yoldur ve üretim için önerilmez.This is another way to set up an initial dev environment, and not recommended for production.

  3. Azure Pipelines aracılığıyla -bu, sanal ağın içinde bulunan bir aracıdan biten tam bir CI/CD işlem hattı uygular.Through Azure Pipelines - This implements a complete CI/CD pipeline, ending in an agent located inside the VNet. Bu, dağıtım için yüksek performans gerektiren üretim ortamları için idealdir.This is ideal for production environments requiring high throughput of deployment. Derleme işlem hattı tamamen VNet dışında kalır.The build pipeline remains entirely outside the VNet. Dağıtım ardışık düzeni, oluşturulan nesneleri VNet 'in içindeki yapı aracısına kopyalar ve ardından ASE alt ağına dağıtır.The deploy pipeline copies the built objects to the build agent inside the VNet, and then deploys to the ASE subnet. Daha fazla bilgi için, işlem hatları ve ASE VNET arasındaki şirket içinde barındırılan derleme aracısındabu tartışmayı okuyun.For more information, read this discussion on the self-hosted build agent between Pipelines and the ASE VNet.

Azure Pipelines kullanmak üretim ortamları için önerilir.Using Azure Pipelines is recommended for production environments. Azure Pipelines YAML şeması yardımıyla CI/CD komut dosyası oluşturma, derleme ve dağıtım işlemlerini otomatikleştirmenize yardımcı olur.Scripting CI/CD with the help of Azure Pipelines YAML schema helps to automate the build and deployment processes. Azure-Pipelines. yıml , bu başvuru uygulamasındaki Web uygulaması IÇIN bir CI/CD işlem hattı uygular.The azure-pipelines.yml implements such a CI/CD pipeline for the web app in this reference implementation. Web API 'si IÇIN benzer CI/CD betikleri ve işlevide vardır.There are similar CI/CD scripts for the web API as well as the function. Bunların her bir uygulama için CI/CD 'yi otomatikleştirmek üzere nasıl kullanıldığını öğrenmek için Azure Pipelines kullanın .Read Use Azure Pipelines to learn how these are used to automate CI/CD for each application.

Bazı kuruluşlar VNet içinde kalıcı bir yapı Aracısı sürdürmek istememeyebilir.Some enterprises may not want to maintain a permanent build agent inside the VNet. Bu durumda, DevOps ardışık düzeninde bir yapı Aracısı oluşturmayı seçebilir ve dağıtım tamamlandıktan sonra bunu koparın.In that case, you can choose to create a build agent within the DevOps pipeline, and tear it down once the deployment is completed. Bu, DevOps 'a başka bir adım ekler, ancak VM 'nin bakımının karmaşıklığını düşürür.This adds another step in the DevOps, however it lowers the complexity of maintaining the VM. Kapsayıcıları, sanal makineler yerine yapı aracıları olarak kullanmayı da düşünebilirsiniz.You may even consider using containers as build agents, instead of VMs. Derleme aracıları, genellikle bir depolama hesabında VNET dışında yerleştirilmiş daraltılmış bir dosyadan dağıtım yaparak da tamamen kaçınılarak olabilir.Build agents can also be completely avoiding by deploying from a zipped file placed outside the VNet, typically in a storage account. Depolama hesabının Ao 'dan erişilebilir olması gerekir.The storage account will need to be accessible from the ASE. İşlem hattı depolamaya erişebilmelidir.The pipeline should be able to access the storage. Yayın ardışık düzeninin sonunda, daraltılmış bir dosya BLOB depolamaya bırakılabilir.At the end of the release pipeline, a zipped file can be dropped into the blob storage. Ao daha sonra bunu seçip dağıtabilir.The ASE can then pick it up and deploy. Bu yaklaşımın aşağıdaki sınırlamalarından haberdar olun:Be aware of the following limitations of this approach:

  • DevOps ile gerçek dağıtım işlemi arasında bir bağlantı kesilir ve dağıtım sorunlarını izlerken ve izlemedeki zorluklara karşı önde gelen sorunlar vardır.There is a disconnect between the DevOps and the actual deployment process, leading to difficulties in monitoring and tracing any deployment issues.
  • Güvenli trafiğe sahip kilitli bir ortamda, depolama üzerindeki daraltılmış dosyaya erişmek için kuralları değiştirmeniz gerekebilir.In a locked down environment with secured traffic, you may need to change the rules to access the zipped file on the storage.
  • Zip 'ten dağıtım yapabilmesi için Ao 'ya belirli uzantıları ve araçları yüklemeniz gerekir.You will need to install specific extensions and tools on the ASE to be able to deploy from the zip.

Uygulamaların App Service planlarına dağıtılması için daha fazla yol bildirmek üzere dağıtım stratejilerine odaklanan App Service makaleleriniokuyun.To know some more ways the apps can be deployed to the App Service plans, read the App Service articles focusing on deployment strategies.

Maliyetle ilgili konularCost considerations

Maliyetleri tahmin etmek için Azure fiyatlandırma hesaplayıcısını kullanın.Use the Azure pricing calculator to estimate costs. Diğer konular, Microsoft Azure Well-Architected Framework 'Ünmaliyet bölümünde açıklanmaktadır.Other considerations are described in the Cost section in Microsoft Azure Well-Architected Framework. Azure Rezervasyonları birçok Azure kaynağı için bir yıllık veya üç yıllık planları kabul ederek tasarruf etmenize yardımcı olur.Azure Reservations help you save money by committing to one-year or three-years plans for many Azure resources. Bir ayırma satın almamakalesinde daha fazla bilgi edinin.Read more in the article Buy a reservation.

Aşağıda, Bu mimaride kullanılan bazı önemli hizmetler için göz önünde bulundurmanız gereken bazı noktaları bulabilirsiniz.Here are some points to consider for some of the key services used in this architecture.

App Service OrtamıApp Service Environment

App Service için kullanılabilen çeşitli fiyatlandırma seçeneklerivardır.There are various pricing options available for App Service. Bir App Service ortamı yalıtılmış hizmet planıkullanılarak dağıtılır.An App Service environment is deployed using the Isolated Service Plan. Bu plan içinde, CPU boyutları için üç seçenek vardır-I1, I2 ve I3.Within this plan, there are three options for CPU sizes - I1, I2, and I3. Bu başvuru uygulamasında örnek başına üç I1's kullanılıyor.This reference implementation is using three I1's per instance.

Application GatewayApplication Gateway

Application Gateway fiyatlandırması , uygulama ağ geçidi için çeşitli fiyatlandırma seçenekleri sağlar.Application Gateway pricing provides various pricing options for App Gateway. Otomatik ölçeklendirmeyi ve bölge yedekliliği destekleyen Application Gateway Standard_v2 ve WAF_v2 SKU 'su kullanıyoruz.We are using the Application Gateway Standard_v2 and WAF_v2 SKU, that supports auto scaling and zone redundancy. Bu SKU için kullanılan fiyatlandırma modeli hakkında daha fazla bilgi edinmek için Bu makaleyi okuyun.Read this article to know more about the pricing model used for this SKU.

Redis için Azure ÖnbelleğiAzure Cache for Redis

Redsıs fiyatlandırması Için Azure önbelleği , bu hizmet için çeşitli fiyatlandırma seçenekleri sağlar.Azure Cache for Redis pricing provides the various pricing options for this service. Bu mimari, sanal ağ desteği için Premium SKU 'su kullanır.This architecture uses the Premium SKU, for the virtual network support.

Aşağıda, ATıCı 'yi kilitlemek için kullanılan diğer hizmetlere yönelik fiyatlandırma sayfaları verilmiştir:The following are pricing pages for other services used to lock down the ASE:

Çözümü dağıtmaDeploy the solution

Bu mimari için başvuru uygulamasını dağıtmak için GitHub Beniokudosyasına bakın ve Standart dağıtım için betiği izleyin.To deploy the reference implementation for this architecture, see the GitHub readme, and follow the script for standard deployment.

Sonraki adımlarNext steps

Bu mimariyi yüksek kullanılabilirliği destekleyecek şekilde genişletmeyi öğrenmek için, App Services ortamını kullanarak yüksek kullanılabilirliğe sahip uygulama dağıtımımakalesini okuyun.To learn how to extend this architecture to support high availability, read High availability app deployment using App Services Environment.