Unternehmensbereitstellung per Azure App Service-Umgebung

Diese Referenzarchitektur veranschaulicht eine allgemeine Unternehmensworkload, die App Service-Umgebung Version 3 verwendet. Sie beschreibt auch bewährte Methoden zum Stärken der Sicherheit der Workload.

Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

App Service-Umgebung Version 3 bietet andere Features als frühere Versionen und Vorteile gegenüber diesen Versionen. Weitere Informationen finden Sie unter Featureunterschiede. Sie können App Service-Umgebung auf zwei Arten bereitstellen:

• Als eine externe App Service-Umgebung mit einer öffentlichen IP-Adresse
• Als eine interne App Service-Umgebung mit einer internen IP-Adresse, die zum internen Lastenausgleich (Internal Load Balancer, ILB) gehört

Diese Referenzarchitektur stellt eine Unternehmenswebanwendung in einer internen App Service-Umgebung bereit, die auch als ILB-App Service-Umgebung bezeichnet wird. Verwenden Sie eine ILB-App Service-Umgebung, wenn Ihr Szenario Folgendes erfordert:

• Hosten von Intranet-Anwendungen mit erhöhter Sicherheit in der Cloud, und Zugriff darauf über ein Site-to-Site-VPN oder Azure ExpressRoute.
• Bereitstellen eine Schutzebene für Apps durch Verwendung einer Web Application Firewall (WAF).
• Apps in der Cloud hosten, die nicht in öffentlichen DNS-Servern aufgeführt sind
• Erstellen Sie vom Internet isolierte Back-End-Apps, in die Ihre Front-End-Apps auf hochsichere Weise integriert werden können.

App Service-Umgebung muss immer in einem eigenen Subnetz im virtuellen Unternehmensnetzwerk bereitgestellt werden, um eine strikte Kontrolle des eingehenden und ausgehenden Datenverkehrs zu ermöglichen. In diesem Subnetz werden App Service-Anwendungen unter einem oder mehreren App Service-Plänen bereitgestellt. Hierbei handelt es sich um eine Sammlung mit physischen Ressourcen, die für die Ausführung der App benötigt werden. Je nach Komplexität und Ressourcenanforderung kann ein App Service-Plan auch von mehreren Apps gemeinsam genutzt werden. Bei dieser Referenzimplementierung wird eine Web-App mit dem Namen Voting-App bereitgestellt, die mit einer privaten Web-API und einer Funktion interagiert. Darüber hinaus wird auch eine Dummy-Web-App mit dem Namen Test App bereitgestellt, um die Bereitstellung mehrerer Apps zu veranschaulichen. Jede App Service-App wird unter einem eigenen App Service-Plan gehostet, sodass bei Bedarf jede einzeln skaliert werden kann. Alle Ressourcen, die von diesen gehosteten Apps benötigt werden, z. B. Speicher- und Computeressourcen, sowie die Skalierungsanforderungen werden vollständig von der Infrastruktur der App Service-Umgebung verwaltet.

Mit der einfachen Voting-App in dieser Implementierung können Benutzer vorhandene Einträge anzeigen, neue Einträge erstellen und über vorhandene Einträge abstimmen. Die Web-API wird für das Erstellen und Abrufen von Einträgen und Stimmabgaben verwendet. Die eigentlichen Daten werden in einer SQL Server-Datenbank gespeichert. Zur Veranschaulichung asynchroner Datenaktualisierungen reiht die Web-App neu hinzugefügte Stimmabgaben in die Warteschlange einer Service Bus-Instanz ein. Die Funktion verwendet die Stimmabgaben aus der Warteschlange, um die SQL-Datenbank zu aktualisieren. Azure Cosmos DB wird verwendet, um eine Pseudoanzeige zu speichern, die von der Web-App für die Anzeige im Browser abgerufen wird. Die Anwendung nutzt Azure Cache for Redis für die Cacheverwaltung. Es wird eine Azure Cache for Redis-Instanz im Premium-Tarif verwendet, was die Konfiguration im gleichen virtuellen Netzwerk wie die App Service-Umgebung erlaubt, in ihrem eigenen Subnetz. Dies führt zu einer höheren Sicherheit und besseren Isolation des Caches.

Die Web-Apps sind die einzigen Komponenten, die per Application Gateway über das Internet zugänglich sind. Der Zugriff auf die API und die Funktion ist über einen Internetclient nicht möglich. Der eingehende Datenverkehr wird durch eine WAF geschützt, die in Application Gateway konfiguriert ist.

Komponenten

Die folgenden Dienste sind zum Sperren der App Service-Umgebung in dieser Architektur wichtig:

• Azure Virtual Network ist ein privates Azure-Cloudnetzwerk, das sich im Besitz des Unternehmens befindet. Es sorgt für erweiterte netzwerkbasierte Sicherheit und Isolation. App Service-Umgebung ist eine App Service Bereitstellung in einem Subnetz des unternehmenseigenen virtuellen Netzwerks. Mit dem Dienst kann das Unternehmen diesen Netzwerkraum und die Ressourcen, auf die zugegriffen wird, streng kontrollieren, indem Netzwerksicherheitsgruppen und private Endpunkte verwendet werden.

• Application Gateway ist ein Lastenausgleich für Webdatenverkehr auf Anwendungsebene mit TLS/SSL-Abladung und WAF. Er lauscht an einer öffentlichen IP-Adresse und routet Datenverkehr an den Anwendungsendpunkt in der ILB-App Service-Umgebung. Da dieses Routing auf Anwendungsebene erfolgt, kann Datenverkehr an mehrere Apps in derselben ILB-App Service-Umgebung geroutet werden. Weitere Informationen finden Sie unter Application Gateway – Hosten mehrerer Websites.

• Azure Firewall wird verwendet, um den ausgehenden Datenverkehr der Webanwendung einzuschränken. Ausgehender Datenverkehr, der nicht über die privaten Endpunktkanäle und eine für App Service-Umgebung erforderliche Routingtabelle verläuft, wird an das Firewallsubnetz geleitet. Der Einfachheit halber konfiguriert diese Architektur alle privaten Endpunkte im Dienstsubnetz.

• Microsoft Entra ID stellt die Verwaltung von Zugriffsrechten und -berechtigungen für Azure-Ressourcen bereit. Mit verwalteten Identitäten werden Identitäten für Dienste und Apps zugewiesen, die mit Microsoft Entra ID automatisch verwaltet werden. Diese Identitäten können für die Authentifizierung bei jedem Dienst verwendet werden, der die Microsoft Entra-Authentifizierung unterstützt. Aus diesem Grund ist es nicht mehr erforderlich, explizit Anmeldeinformationen für diese Apps zu konfigurieren. Bei dieser Architektur wird der Web-App eine verwaltete Identität zugewiesen.

• Azure Key Vault speichert alle Geheimnisse und Anmeldeinformationen, die von den Apps benötigt werden. Verwenden Sie diese Option anstelle der direkten Speicherung von Geheimnissen in der Anwendung.

• GitHub Actions bietet Funktionalitäten für Continuous Integration und Continuous Deployment für diese Architektur. Da sich die App Service-Umgebung im virtuellen Netzwerk befindet, wird eine VM als Jumpbox innerhalb des virtuellen Netzwerks verwendet, um Apps in den App Service-Plänen bereitzustellen. Die Aktion erstellt die Apps außerhalb des virtuellen Netzwerks. Erwägen Sie für verbesserte Sicherheit und nahtlose RDP/SSH-Konnektivität die Verwendung von Azure Bastion für die Jumpbox.

Konfiguration für mehrere Websites

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die interne App Service-Umgebung kann mehrere Web-Apps und APIs mit HTTP-Endpunkten hosten. Diese Anwendungen sind für den Zugriff aus dem öffentlichen Internet gesperrt, da die IP-Adresse des ILB nur aus dem virtuellen Netzwerk zugänglich ist. Application Gateway wird verwendet, um diese Anwendungen selektiv im Internet verfügbar zu machen. App Service-Umgebung weist jeder App Service-Anwendung eine Standard-URL als <default-appName>.<app-service-environment-domain>.appserviceenvironment.net zu. Eine private DNS-Zone wird erstellt, die den Domänennamen der App Service-Umgebung der ILB-IP-Adresse der App Service-Umgebung zuordnet. So wird vermieden, ein benutzerdefiniertes DNS für den Zugriff auf die Apps im virtuellen Netzwerk zu verwenden.

Application Gateway ist so konfiguriert, dass ein Listener am HTTPS-Port auf Anforderungen für die IP-Adresse des Gateways lauscht. Der Einfachheit halber verwendet diese Implementierung keine öffentliche DNS-Namensregistrierung. Sie erfordert, dass Sie die localhost-Datei auf Ihrem Computer ändern, sodass eine willkürlich ausgewählte URL auf die Application Gateway IP-Adresse verweist. Um den Ablauf einfach zu gestalten, wird für den Listener zum Verarbeiten dieser Anforderungen ein selbstsigniertes Zertifikat verwendet. Application Gateway verfügt über Back-End-Pools für jede Standard-URL der App Service-Anwendung. Eine Routingregel wird konfiguriert, um für den Listener eine Verbindung mit dem Back-End-Pool herzustellen. HTTP-Einstellungen werden erstellt, die bestimmen, ob die Verbindung zwischen dem Gateway und der App Service-Umgebung verschlüsselt wird. Außerdem werden diese Einstellungen verwendet, um den eingehenden HTTP-Hostheader durch einen Hostnamen aus dem Back-End-Pool außer Kraft zu setzen. Bei dieser Implementierung werden Standardzertifikate genutzt, die für die Standard-App-URLs der App Service-Umgebung erstellt werden. Diese URLs werden vom Gateway als vertrauenswürdig angesehen. Die Anforderung wird an die Standard-URL der entsprechenden App umgeleitet. Vom privaten DNS, das mit dem virtuellen Netzwerk verknüpft ist, wird diese Anforderung an die ILB-IP-Adresse weitergeleitet. App Service-Umgebung leitet diese dann an den angeforderten App-Dienst weiter. Die gesamte HTTP-Kommunikation innerhalb der App Service-Umgebung-Apps verläuft über das private DNS. Beachten Sie, dass der Listener, der Back-End-Pool, die Routingregel und die HTTP-Einstellungen auf dem Anwendungsgateway für jede App Service-Umgebung-App konfiguriert werden müssen.

Sehen Sie sich appgw.bicep und dns.bicep an, um zu erfahren, wie diese Konfigurationen vorgenommen werden, um mehrere Sites zuzulassen. Die Web-App mit dem Namen testapp ist eine leere App, die zur Veranschaulichung dieser Konfiguration erstellt wurde. Auf diese JSON-Dateien wird mit dem Bereitstellungsskript commands_std.azcli zugegriffen. Auf diese wird auch über commands_ha.azcli zugegriffen, das für eine Hochverfügbarkeitsbereitstellung der App Service-Umgebung für mehrere Sites verwendet wird.

Szenariodetails

Azure App Service ist ein PaaS-Dienst, mit dem unter Azure verschiedene Apps gehostet werden: Web-Apps, API-Apps, Funktionen und mobile Apps. Mit App Service-Umgebung können Unternehmen ihre App Service-Apps in einem Subnetz ihres eigenen Azure Virtual Network bereitstellen, um eine isolierte, hochgradig skalierbare und dedizierte Umgebung für ihre Cloudworkloads zu erhalten.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

App Service-Umgebung

Eine interne App Service-Umgebung wird im virtuellen Unternehmensnetzwerk bereitgestellt, das vom öffentlichen Internet aus nicht sichtbar ist. Hiermit kann das Unternehmen seine Back-End-Dienste, z. B. Web-APIs und Funktionen, auf Netzwerkebene sperren. Auf alle App Service-Umgebung-Apps mit einem HTTP-Endpunkt kann aus dem virtuellen Netzwerk über den ILB zugegriffen werden. Application Gateway ist so konfiguriert, dass Anforderungen an die Web-App über den ILB weitergeleitet werden. Die Web-App selbst durchläuft den ILB, um auf die API zuzugreifen. Auf die kritischen Back-End-Komponenten, also die API und die Funktion, kann aus dem öffentlichen Internet quasi nicht zugegriffen werden.

Standardzertifikate werden für jeden App-Dienst für den von App Service-Umgebung zugewiesenen Standarddomänennamen erstellt. Mit diesem Zertifikat kann die Sicherheit des Datenverkehrs zwischen dem Gateway und der App erhöht werden, und in bestimmten Szenarien ist dies möglicherweise erforderlich. Diese Zertifikate sind nicht über den Clientbrowser sichtbar. Er kann nur auf die Zertifikate reagieren, die für Application Gateway konfiguriert sind.

Application Gateway

Die Referenzimplementierung konfiguriert Application Gateway programmgesteuert in appgw.bicep. Die Datei commands_std.azcli verwendet diese Konfiguration beim Bereitstellen des Gateways:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --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)

Verschlüsselung

Wie unter Übersicht über TLS-Abschluss und End-to-End-TLS mit Application Gateway beschrieben, kann Application Gateway Transport Layer Security (TLS)/Secure Sockets Layer (SSL) verwenden, um den gesamten Datenverkehr von Webbrowsern zu verschlüsseln und zu schützen. Die Verschlüsselung kann wie folgt konfiguriert werden:

• Verschlüsselung endet am Gateway: Die Back-End-Pools sind in diesem Fall für HTTP konfiguriert. Die Verschlüsselung endet beim Gateway, und der Datenverkehr zwischen dem Gateway und dem App-Dienst ist unverschlüsselt. Da die Verschlüsselung CPU-intensiv ist, wird die Leistung durch unverschlüsselten Datenverkehr auf dem Back-End verbessert und die Verwaltung von Zertifikaten vereinfacht. So kann ein angemessenes Maß an Sicherheit erzielt werden, weil das Back-End aufgrund der Netzwerkkonfiguration geschützt ist.

• End-to-End-Verschlüsselung. In einigen Szenarien, z. B. bei bestimmten Sicherheits- oder Konformitätsanforderungen, muss der Datenverkehr zwischen dem Gateway und der App ggf. verschlüsselt werden. Dies wird erreicht, indem eine HTTPS-Verbindung genutzt wird und im Back-End-Pool Zertifikate konfiguriert werden.

Bei dieser Referenzimplementierung werden selbstsignierte Zertifikate für Application Gateway verwendet. Für Produktionscode sollte ein Zertifikat genutzt werden, das von einer Zertifizierungsstelle ausgestellt wurde. Eine Liste mit den unterstützten Zertifikattypen finden Sie unter Unterstützte Zertifikate für den TLS-Abschluss. Informationen zur Einrichtung einer Verschlüsselung, die auf dem Gateway endet, finden Sie unter Tutorial: Konfigurieren eines Anwendungsgateways mit TLS-Terminierung über das Azure-Portal. Die folgenden Codezeilen in appgw.bicep konfigurieren dies programmgesteuert:

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

Die Referenzimplementierung veranschaulicht die End-to-End-Verschlüsselung für den Datenverkehr zwischen Application Gateway und den Web-Apps auf der App Service-Umgebung. Es werden die SSL-Standardzertifikate verwendet. Die Back-End-Pools dieser Implementierung sind so konfiguriert, dass HTTPS-Datenverkehr mit Hostnamen, die durch die Standarddomänennamen der Web-Apps außer Kraft gesetzt werden, umgeleitet wird. Application Gateway vertraut den SSL-Standardzertifikaten, da sie von Microsoft ausgestellt werden. Weitere Informationen dazu, wie diese Konfigurationen vorgenommen werden, finden Sie unter Konfigurieren von App Service mit Application Gateway. Der folgende Code aus appgw.bicep zeigt, wie dies in der Referenzimplementierung konfiguriert wird:

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

Web Application Firewall

Der Web Application Firewall (WAF) auf Application Gateway schützt die Web-Apps vor bösartigen Angriffen, z. B. einer SQL-Einschleusung. Diese Komponente ist auch in Azure Monitor integriert, um Angriffe per Echtzeitprotokoll zu überwachen. WAF muss auf dem Gateway aktiviert sein. Dies ist unter Tutorial: Erstellen eines Anwendungsgateways mit einer Web Application Firewall über das Azure-Portal beschrieben. Die Referenzimplementierung aktiviert WAF programmgesteuert in der Datei appgw.bicep mit dem folgenden Codeschnipsel:

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

Virtual Network

Netzwerksicherheitsgruppen können einem oder mehreren Subnetzen im virtuellen Netzwerk zugeordnet werden. Hierbei handelt es sich um Sicherheitsregeln, mit denen Datenverkehr zwischen unterschiedlichen Azure-Ressourcen zugelassen oder verweigert werden kann. Bei dieser Architektur wird jedem Subnetz eine eigene Netzwerksicherheitsgruppe zugeordnet. Dies ermöglicht eine Feinabstimmung dieser Regeln pro Subnetz, je nach den in diesem Subnetz enthaltenen Diensten. Sehen Sie sich beispielsweise die Konfiguration für "type": "Microsoft.Network/networkSecurityGroups" in der Datei ase.bicep für die Netzwerksicherheitsgruppe für das App Service-Umgebung-Subnetz an, und in der Datei appgw.bicep für die Netzwerksicherheitsgruppe für das Application Gateway-Subnetz.

Private Endpunkte ermöglichen eine private Konnektivität mit erweiterter Sicherheit zwischen Clients und Azure-Diensten über ein privates Netzwerk. Sie stellen eine privat zugängliche IP-Adresse für den Azure-Dienst bereit, wodurch Datenverkehr mit erweiterter Sicherheit an eine Azure Private Link-Ressource ermöglicht wird. Die Plattform überprüft die Netzwerkverbindungen und lässt nur solche zu, die mit der angegebenen Private Link-Ressource verbunden sind. Private Endpunkte unterstützen Netzwerkrichtlinien wie Netzwerksicherheitsgruppen, benutzerdefinierte Routen und Anwendungssicherheitsgruppen. Um die Sicherheit zu verbessern, sollten Sie private Endpunkte für jeden Azure-Dienst aktivieren, der sie unterstützt. Sie können dann die Sicherheit für den Dienst im virtuellen Netzwerk verbessern, indem Sie den öffentlichen Zugriff deaktivieren und somit jeden Zugriff über das öffentliche Internet effektiv blockieren. Diese Architektur konfiguriert private Endpunkte für die Dienste, die sie unterstützen: Azure Service Bus, SQL Server, Key Vault und Azure Cosmos DB. Sie können die Konfiguration in privatedpoints.bicep ansehen.

Um private Endpunkte zu aktivieren, müssen Sie auch private DNS-Zonen konfigurieren. Weitere Informationen finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

Firewall

Azure Firewall und private Endpunkte ergänzen sich gegenseitig. Private Endpunkte helfen beim Schutz von Ressourcen, indem nur Datenverkehr zugelassen wird, der aus Ihrem virtuellen Netzwerk stammt. Mit Azure Firewall können Sie den ausgehenden Datenverkehr ihrer Anwendungen einschränken. Wir empfehlen, dass Sie den gesamten ausgehenden Datenverkehr, einschließlich des Datenverkehrs von privaten Endpunkten, über das Firewallsubnetz leiten. Dies ermöglicht eine bessere Überwachung des ausgehenden Datenverkehrs. Der Einfachheit halber konfiguriert diese Referenzarchitektur alle privaten Endpunkte nicht im Firewallsubnetz, sondern im Dienstsubnetz.

Informationen zur Integration von Azure Firewall mit App Service-Umgebung finden Sie unter Konfigurieren von Azure Firewall mit Ihrer App Service-Umgebung. Sämtlicher Datenverkehr, der nicht die privaten Endpunkte und die Routingtabelle des virtuellen Netzwerk durchläuft, wird von der Firewall überwacht und abgegrenzt.

Microsoft Entra ID

Microsoft Entra ID verfügt über Sicherheitsfeatures zum Authentifizieren von Anwendungen und Autorisieren des Zugriffs auf Ressourcen. In dieser Referenzarchitektur werden zwei wichtige Features von Microsoft Entra ID genutzt: verwaltete Identitäten und die rollenbasierte Zugriffssteuerung in Azure.

Bei Cloudanwendungen müssen die Anmeldeinformationen, die für die Authentifizierung bei Clouddiensten benötigt werden, geschützt werden. Im Idealfall werden die Anmeldeinformationen nie auf Entwicklerarbeitsstationen angezeigt oder in die Quellcodeverwaltung eingecheckt. Azure Key Vault ermöglicht das sichere Speichern von Anmeldeinformationen und Geheimnissen. Um diese abrufen zu können, muss sich die App aber trotzdem noch bei Key Vault authentifizieren. Verwaltete Identitäten für Azure-Ressourcen stellen für Azure-Dienste eine automatisch verwaltete Identität in Microsoft Entra ID bereit. Diese Identität kann für die Authentifizierung bei jedem Dienst verwendet werden, der die Microsoft Entra-Authentifizierung unterstützt, einschließlich Key Vault. Hierfür müssen keine Anmeldeinformationen in der Anwendung enthalten sein.

Mit der rollenbasierten Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) wird der Zugriff auf Azure-Ressourcen verwaltet. Dies schließt Folgendes ein:

• Welche Entität Zugriff hat: Benutzer, verwaltete Identität, Sicherheitsprinzipal.
• Welche Art von Zugriff besteht: Besitzer, Mitwirkender, Leser, Administrator.
• Zugriffsbereich: Ressource, Ressourcengruppe, Abonnement oder Verwaltungsgruppe.

Sie können den Zugriff auf App Service-Umgebung-Anwendungen sperren, indem Sie die erforderliche Rolle und die Art des Zugriffs für jede Anwendung streng kontrollieren. Auf diese Weise können mehrere Apps in der gleichen App Service-Umgebung von unterschiedlichen Entwicklungsteams bereitgestellt werden. Beispielsweise kann das Front-End von einem Team und das Back-End von einem anderen Team verwaltet werden. Die Azure RBAC kann genutzt werden, um für die einzelnen Teams den Zugriff auf die Apps zu beschränken, an denen sie arbeiten. Informationen zur Erstellung von Rollen, die für Ihre Organisation geeignet sind, finden Sie unter Benutzerdefinierte Azure-Rollen.

Key Vault

Einige Dienste unterstützen verwaltete Identitäten, aber sie verwenden Azure RBAC, um Berechtigungen für die App einzurichten. Informationen hierzu finden Sie beispielsweise im Artikel zu den integrierten Service Bus-Rollen und unter Azure RBAC in Azure Cosmos DB. Zugriff vom Typ Besitzer auf das Abonnement ist erforderlich, um diese Berechtigungen zu gewähren – auch wenn Benutzer mit Zugriff vom Typ Mitwirkender diese Dienste bereitstellen können. Damit ein größeres Team von Entwicklern die Bereitstellungsskripts ausführen kann, besteht die beste Alternative darin, die nativen Zugriffssteuerungsrichtlinien des Diensts zu verwenden:

• Für Service Bus sind dies freigegebene Zugriffssignaturen.
• Für Azure Cosmos DB sind dies Schlüssel.

Die Verbindungszeichenfolgen für diese Zugriffssteuerungsrichtlinien werden dann in Key Vault gespeichert. Auf den Tresor selbst wird über verwaltete Identitäten zugegriffen, wofür Azure RBAC erforderlich ist. Legen Sie die Zugriffsrichtlinie für diese Verbindungszeichenfolgen entsprechend fest. Es kann beispielsweise Schreibschutz für das Back-End, Leseschutz für das Front-End usw. festgelegt werden, anstatt die Standard-Stammzugriffsrichtlinie zu verwenden.

Der folgende Code in services.bicep zeigt die Key Vault-Konfiguration für diese Dienste:

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

Auf diese Verbindungszeichenfolgen-Werte wird von den Apps zugegriffen, welche auf das Schlüssel/Wert-Paar in Key Vault verweisen. Dies geschieht in der Datei sites.bicep, wie der folgende Code für die Voting-App zeigt:

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

Die Funktion greift auf ähnliche Weise auch auf die Verbindungszeichenfolge für den Service Bus-Listener zu.

Skalierbarkeit

Entwerfen skalierbarer Apps

Die Anwendung in dieser Referenzarchitektur ist so aufgebaut, dass einzelne Komponenten basierend auf der Nutzung skaliert werden können. Jede Web-App, API und Funktion wird in einem eigenen App Service-Plan bereitgestellt. Sie können jede App auf Leistungsengpässe überwachen und bei Bedarf dann hochskalieren.

Automatische Skalierung von Application Gateway

Die automatische Skalierung kann für Azure Application Gateway V2 aktiviert werden. Dies ermöglicht Application Gateway das Hoch- oder Herunterskalieren basierend auf den Auslastungsmustern des Datenverkehrs. Bei dieser Referenzarchitektur ist autoscaleConfiguration in der Datei appgw.json so konfiguriert, dass zwischen 0 und 10 weiteren Instanzen skaliert werden kann. Weitere Informationen finden Sie unter Skalierung von Application Gateway und WAF v2.

Bereitstellung

Die Bereitstellungsskripts in dieser Referenzarchitektur werden verwendet, um App Service-Umgebung, andere Dienste und die Anwendungen in App Service-Umgebung bereitzustellen. Nach der Bereitstellung dieser Anwendungen kann es sein, dass Unternehmen einen Plan für Continuous Integration und Deployment in Bezug auf die App-Wartung und auf Upgrades aufstellen möchten. In diesem Abschnitt werden einige gängige Verfahren beschrieben, die Entwickler für CI/CD-Ansätze von Anwendungen in App Service-Umgebung nutzen.

Apps können nur über das virtuelle Netzwerk in einer internen App Service-Umgebung bereitgestellt werden. Die folgenden drei Methoden werden häufig für die Bereitstellung von App Service-Umgebung-Apps verwendet:

• Manuell innerhalb des Virtual Network: Erstellen Sie eine VM im virtuellen Netzwerk von App Service-Umgebung mit den erforderlichen Tools für die Bereitstellung. Öffnen Sie die RDP-Verbindung mit der VM per NSG-Konfiguration. Kopieren Sie Ihre Codeartefakte auf die VM, erstellen Sie den Build und führen Sie dann die Bereitstellung im Subnetz von App Service-Umgebung durch. Dies ist eine einfache Möglichkeit, um eine erste Entwicklungsumgebung für Build- und Testzwecke einzurichten. Für Produktionsumgebungen ist dies aber nicht geeignet, da der erforderliche Bereitstellungsdurchsatz nicht skaliert werden kann.

• Point-to-Site-Verbindung von der lokalen Arbeitsstation: Dies ermöglicht Ihnen die Erweiterung Ihres virtuellen Netzwerks von App Service-Umgebung auf Ihren Entwicklungscomputer, um die Bereitstellung von dort aus durchzuführen. Dies ist eine weitere Möglichkeit zum Einrichten einer ersten Entwicklungsumgebung, deren Verwendung für die Produktion nicht zu empfehlen ist.

• Über Azure Pipelines: Dies implementiert eine vollständige CI/CD-Pipeline, die an einem Agent im virtuellen Netzwerk endet. Dies ist ideal für Produktionsumgebungen, für die ein hoher Bereitstellungsdurchsatz benötigt wird. Die Buildpipeline bleibt vollständig außerhalb des virtuellen Netzwerks. Die Bereitstellungspipeline kopiert die Buildobjekte auf den Build-Agent im virtuellen Netzwerk und führt dann die Bereitstellung im Subnetz von App Service-Umgebung durch. Weitere Informationen finden Sie in dieser Diskussion des selbstgehosteten Build-Agents zwischen Pipelines und dem virtuellen Netzwerk von App Service-Umgebung.

Die Verwendung von Azure Pipelines wird für Produktionsumgebungen empfohlen. Die Skripterstellung für CI/CD mit dem YAML-Schema von Azure Pipelines erleichtert die Automatisierung des Build- und Bereitstellungsprozesses. Im Rahmen dieser Referenzimplementierung wird mit azure-pipelines.yml eine CI/CD-Pipeline dieser Art für die Web-App implementiert. Es sind ähnliche CI/CD-Skripts für die Web-API und die Funktion vorhanden. Lesen Sie Verwenden von Azure Pipelines, um zu erfahren, wie diese Skripts zum Automatisieren von CI/CD für die einzelnen Anwendungen genutzt werden.

Einige Unternehmen möchten möglicherweise keinen permanenten Build-Agent innerhalb des virtuellen Netzwerks unterhalten. In diesem Fall können Sie einen Build-Agent in der DevOps-Pipeline erstellen und dann wieder entfernen, nachdem die Bereitstellung durchgeführt wurde. Dies ist zwar ein weiterer Schritt für den DevOps-Prozess, der aber bewirkt, dass die Komplexität der VM-Wartung abnimmt. Sie können auch erwägen, anstelle von VMs Container als Build-Agents zu nutzen. Build-Agents können auch vollständig vermieden werden, indem Sie die Bereitstellung über eine gezippte Datei außerhalb des virtuellen Netzwerks, typischerweise in einem Speicherkonto, durchführen. Das Speicherkonto muss von der App Service-Umgebung aus zugänglich sein. Die Pipeline sollte Zugriff auf den Speicher haben. Am Ende der Releasepipeline kann eine gezippte Datei im Blobspeicher abgelegt werden. Die App Service-Umgebung kann es dann aufgreifen und bereitstellen. Beachten Sie die folgenden Einschränkungen, die für diesen Ansatz gelten:

• Es besteht eine Diskrepanz zwischen dem DevOps-Prozess und dem tatsächlichen Bereitstellungsprozess, die zu Schwierigkeiten beim Überwachen und Nachverfolgen von Bereitstellungsproblemen führt.
• In einer gesperrten Umgebung mit geschütztem Datenverkehr müssen Sie ggf. die Regeln ändern, um auf die gezippte Datei im Speicher zugreifen zu können.
• Sie müssen bestimmte Erweiterungen und Tools in der App Service-Umgebung installieren, damit die Bereitstellung über die ZIP-Datei möglich ist.

Weitere Möglichkeiten zur Bereitstellung der Apps unter den App Service-Plänen finden Sie in den App Service-Artikeln zu den Bereitstellungsstrategien.

Kostenoptimierung

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Weitere Überlegungen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung. Mit Azure-Reservierungen können Sie Geld sparen, indem Sie sich bei zahlreichen Azure-Ressourcen für Pläne mit einer Laufzeit von einem Jahr oder drei Jahren entscheiden. Weitere Informationen finden Sie im Artikel Kaufen einer Reservierung.

Im Anschluss sind einige Aspekte aufgeführt, die im Zusammenhang mit einigen der in dieser Architektur verwendeten wichtigen Dienste berücksichtigt werden müssen.

App Service-Umgebung v3

Es gibt verschiedene Preisoptionen für App Service. Eine App Service-Umgebung wird mit dem Dienstplan „Isoliert v2“ bereitgestellt. In diesem Plan gibt es mehrere Optionen für CPU-Größen, von I1v2 bis I6v2. Diese Referenzimplementierung verwendet drei I1v2s pro Instanz.

Application Gateway

Unter Application Gateway-Preise sind die unterschiedlichen Preisoptionen angegeben. Diese Implementierung verwendet die Application Gateway Standard v2- und WAF v2-SKU, die automatische Skalierung und Zonenredundanz unterstützt. Weitere Informationen zum für diese SKU verwendeten Preismodell finden Sie unter Skalieren von Application Gateway v2 und WAF v2.

Azure Cache for Redis

Unter Azure Cache for Redis – Preise sind die unterschiedlichen Preisoptionen für diesen Dienst angegeben. In dieser Architektur wird die Premium-SKU für die Unterstützung virtueller Netzwerke verwendet.

Im Folgenden finden Sie Preisseiten für andere Dienste, die zum Sperren von App Service-Umgebung verwendet werden:

• Azure Firewall – Preise

• Key Vault – Preise

• Microsoft Entra-Preise

Bereitstellen dieses Szenarios

Informationen zur Bereitstellung der Referenzimplementierung für diese Architektur finden Sie in den GitHub-Versionshinweisen, und verwenden Sie für diesen Vorgang auch das Skript für die Standardbereitstellung.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Dhanashri Kshirsagar | Senior Content PM

Andere Mitwirkende:

• Deep Bhattacharya | Cloud Solution Architect
• Suhas Rao | Cloud Solution Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Direktes Ausführen Ihrer App in Azure App Service aus einem ZIP-Paket
• Azure Pipelines-YAML-Schema
• Abrufen der Verwaltungsadressen über eine API
• Azure Key Vault
• Azure Pipelines

Zugehörige Ressourcen

Informationen zur Erweiterung dieser Architektur, damit Hochverfügbarkeit unterstützt wird, finden Sie im Artikel zur Bereitstellung von Apps per App Services-Umgebung mit Hochverfügbarkeit.