Een App Service-omgeving voor een interne load balancer maken en gebruiken

Belangrijk

Dit artikel gaat over App Service Environment v2, dat wordt gebruikt met geïsoleerde App Service-plannen. App Service Environment v1 en v2 worden vanaf 31 augustus 2024 buiten gebruik gesteld. Er is een nieuwe versie van App Service Environment die eenvoudiger te gebruiken is en wordt uitgevoerd op een krachtigere infrastructuur. Voor meer informatie over de nieuwe versie begint u met de inleiding tot de App Service-omgeving. Als u momenteel App Service Environment v1 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.

Vanaf 31 augustus 2024 zijn Service Level Agreement (SLA) en servicetegoeden niet langer van toepassing op App Service Environment v1- en v2-workloads die in productie blijven omdat ze buiten gebruik worden gesteld. Het buiten gebruik stellen van de App Service Environment v1- en v2-hardware is gestart. Dit kan van invloed zijn op de beschikbaarheid en prestaties van uw apps en gegevens.

U moet de migratie naar App Service Environment v3 onmiddellijk voltooien of uw apps en resources kunnen worden verwijderd. We proberen alle resterende App Service Environment v1 en v2 automatisch te migreren met behulp van de in-place migratiefunctie, maar Microsoft maakt geen claim of garanties over de beschikbaarheid van toepassingen na automatische migratie. Mogelijk moet u handmatige configuratie uitvoeren om de migratie te voltooien en de SKU-keuze van uw App Service-plan te optimaliseren om aan uw behoeften te voldoen. Als automatische migratie niet haalbaar is, worden uw resources en bijbehorende app-gegevens verwijderd. We dringen er ten zeerste op aan dat u nu actie moet ondernemen om een van deze extreme scenario's te voorkomen.

Als u extra tijd nodig hebt, kunnen we een eenmalige respijtperiode van 30 dagen aanbieden om uw migratie te voltooien. Raadpleeg het overzicht van de respijtperiode voor meer informatie en om deze respijtperiode aan te vragen. Ga vervolgens naar Azure Portal en ga naar de blade Migratie voor elk van uw App Service-omgevingen.

Zie de buitengebruikstelling van App Service Environment v1/v2 voor de meest recente informatie over de buitengebruikstelling van App Service Environment v1 en v2.

De Azure App Service-omgeving is een implementatie van Azure App Service in een subnet in een virtueel Azure-netwerk (VNet). Er zijn twee manieren om een Azure App Service-omgeving (ASE) te implementeren:

• Met een VIP-adres op een extern IP-adres, vaak aangeduid als Externe AS-omgeving.
• Met een VIP-adres op een intern IP-adres, vaak aangeduid als een ILB AS-omgeving omdat het interne eindpunt een ILB (Internal Load Balancer) is.

In dit artikel wordt uitgelegd hoe u een ILB AS-omgeving maakt. Zie Inleiding tot de App Service-omgevingen voor een overzicht van de ASE. Zie [Een externe ASE maken][MakeExternalASE] voor meer informatie over het maken van een externe ASE.

Overzicht

U kunt een AS-omgeving implementeren met een eindpunt dat toegankelijk is via internet of met een IP-adres in uw VNet. De AS-omgeving moet zijn geïmplementeerd met een ILB om het IP-adres in te stellen op een VNet-adres. Als u de ASE-omgeving implementeert met een ILB, moet u de naam van uw ASE opgeven. De naam van uw ASE wordt gebruikt in het domeinachtervoegsel voor de apps in uw ASE. Het domeinachtervoegsel voor uw ILB-ASE is <ASE naam>.appserviceenvironment.net. Apps die zijn gemaakt in een ILB-ASE, worden niet in de openbare DNS geplaatst.

Bij eerdere versies van de ILB-ASE was het nodig dat u een domeinachtervoegsel en een standaardcertificaat voor HTTPS-verbindingen opgaf. Het domeinachtervoegsel wordt niet meer gebruikt bij het maken van de ILB-ASE en er is ook geen standaardcertificaat meer nodig. Wanneer u nu een ILB-ASE maakt, wordt het standaardcertificaat door Microsoft verzorgd en wordt dit vertrouwd door de browser. U kunt nog steeds aangepaste domeinnamen instellen voor apps in uw ASE en certificaten instellen voor die aangepaste domeinnamen.

Met een ILB-ASE kunt u de volgende dingen doen:

• Intranettoepassingen veilig hosten in de cloud, waartoe u toegang hebt via een site-naar-site- of ExpressRoute.
• Apps beveiligen met een WAF-apparaat
• Apps die niet worden vermeld op openbare DNS-servers, hosten in de cloud.
• Back-end-apps met internetisolatie maken, waarmee front-end-apps veilig kunnen worden geïntegreerd.

Uitgeschakelde functionaliteit

Er is een aantal dingen dat u niet kunt doen wanneer u een ILB AS-omgeving gebruikt:

• Gebruik TLS/SSL-binding op basis van IP.
• IP-adressen toewijzen aan specifieke apps.
• Een certificaat kopen en gebruiken met een app via Azure Portal. U kunt certificaten rechtstreeks bij een certificeringsinstantie verkrijgen en ze gebruiken met uw apps. U kunt ze niet verkrijgen via Azure Portal.

Een ILB AS-omgeving maken

Zie Een ASE maken met behulp van een Azure Resource Manager-sjabloon als u een ILB AS-omgeving wilt maken.

Notitie

De naam van de App Service-omgeving mag niet langer zijn dan 36 tekens.

Een app maken in een ILB AS-omgeving

Het maken van een app in een ILB AS-omgeving werkt hetzelfde als het maken van een app in een AS-omgeving.

1. Selecteer in Azure Portal Een resource maken>Web>Web-app.

2. Voer de naam van de app in.

3. Selecteer het abonnement.

4. Selecteer of maak een resourcegroep.

5. Selecteer uw publicatie, runtimestack en besturingssysteem.

6. Selecteer een locatie waar de locatie een bestaande ILB-AS-omgeving is.

7. Selecteer of maak een App Service-plan.

8. Selecteer Beoordelen en maken en selecteer vervolgens Maken wanneer u klaar bent.

WebJobs, Functions en de ILB AS-omgeving

Een ILB AS-omgeving biedt ondersteuning voor zowel Functions als WebJobs. Als u echter met deze wilt werken via de portal, hebt u netwerktoegang tot de SCM-site nodig. Dit betekent dat de host van de browser zich in het virtuele netwerk moet bevinden of ermee moet zijn verbonden. Als uw ILB-AS-omgeving een domeinnaam heeft die niet eindigt op appserviceenvironment.net, moet u uw browser vragen het HTTPS-certificaat te vertrouwen dat wordt gebruikt door uw SCM-site.

DNS-configuratie

Wanneer u een externe ASE gebruikt, worden apps die in uw ASE zijn gemaakt, geregistreerd bij Azure DNS. Er zijn geen extra stappen in een externe ASE voor uw apps die openbaar beschikbaar moeten zijn. In een ILB ASE-omgeving moet u uw eigen DNS beheren. U kunt dit doen in uw eigen DNS-server of met Azure DNS privézones.

DNS configureren in uw eigen DNS-server met uw ILB-ASE:

1. een zone maken voor <ASE name.appserviceenvironment.net>
2. Maak in die zone een A-record die * verwijst naar het IP-adres van de ILB
3. Maak in die zone een A-record die @ verwijst naar het IP-adres van de ILB
4. maak een zone in <ASE name.appserviceenvironment.net> met de naam scm
5. Maak in die SCM-zone een A-record die * verwijst naar het IP-adres van de ILB

DNS configureren in Azure DNS particuliere zones:

1. Maak een Azure DNS privézone met de naam <ASE-naam>.appserviceenvironment.net
2. Maak in die zone een A-record die * verwijst naar het IP-adres van de ILB
3. Maak in die zone een A-record die @ verwijst naar het IP-adres van de ILB
4. Maak in die zone een A-record die *.scm verwijst naar het IP-adres van de ILB

De DNS-instellingen voor uw ASE-standaard domeinachtervoegsel beperken u niet dat uw apps toegankelijk zijn voor die namen. U kunt een aangepaste domeinnaam instellen zonder validatie voor uw apps in een ILB-ASE. Als u vervolgens een zone met de naam contoso.net wilt maken, kunt u dit doen en deze naar het IP-adres van de ILB wijzen. De aangepaste domein naam werkt voor app-aanvragen, maar niet voor de SCM-site. De SCM-site is alleen beschikbaar op <app-naam>.scm.<ASE-naam>.appserviceenvironment.net.

De zone met de naam <ASE-naam>.appserviceenvironment.net is wereldwijd uniek. Voor 2019 konden klanten het achtervoegsel van het domein van de ILB ASE opgeven. Als u. contoso.com wilde gebruiken voor het domeinachtervoegsel, kon u dit doen en dat zou de SCM-site kunnen bevatten. Er waren uitdagingen met dat model, waaronder; het beheren van het standaard TLS/SSL-certificaat, het ontbreken van eenmalige aanmelding bij de scm-site en de vereiste voor het gebruik van een jokertekencertificaat. Het upgradeproces van het ILB ASE-standaard certificaat was tevens verstoord en veroorzaakte het opnieuw opstarten van de toepassing. Om deze problemen op te lossen, is het ILB ASE-gedrag gewijzigd om een domeinachtervoegsel te gebruiken op basis van de naam van de ASE en met een achtervoegsel dat eigendom is van Microsoft. De wijziging van het ILB ASE-gedrag heeft alleen invloed op ILB ASE's gemaakt na mei 2019. Bestaande ILB ASE's as moeten nog steeds het standaard certificaat van de ASE en de bijbehorende DNS-configuratie beheren.

Publiceren met een App Service-omgeving met interne load balancer

Elke app die wordt gemaakt, heeft twee eindpunten. In een ILB ASE-omgeving hebt u <app-naam>.<Domein voor ILB AS-omgeving> en <app-naam>.scm.<Domein voor ILB AS-omgeving>.

De SCM-sitenaam leidt naar de Kudu-console, genaamd de Geavanceerde portal, binnen Azure Portal. Met behulp van de Kudu-console kunt u omgevingsvariabelen bekijken, de schijf verkennen, een console gebruiken, en nog veel meer. Zie Kudu-console voor Azure App Service voor meer informatie.

Op internet gebaseerde CI-systemen, zoals GitHub en Azure DevOps, werken nog steeds met een ILB AS-omgeving, als de buildagent toegankelijk is via internet en zich op hetzelfde netwerk bevindt als de ILB AS-omgeving. Als de buildagent dus, in het geval van Azure DevOps, is gemaakt in hetzelfde VNET als de ILB AS-omgeving (verschillende subnetten vormen geen probleem), kan met deze agent code worden opgehaald uit Azure DevOps-git en worden geïmplementeerd in de ILB AS-omgeving. Als u niet zelf een buildagent wilt maken, moet u een CI-systeem met een pull-model gebruiken, zoals Dropbox.

De publicatie-eindpunten voor apps in een ILB AS-omgeving maken gebruik van het domein waarmee de ILB AS-omgeving is gemaakt. Dit domein wordt weergegeven in het publicatieprofiel van de app en in de portalblade van de app (Overzicht>Essentials en ook Eigenschappen). Als u een ILB AS-omgeving hebt met het domeinachtervoegsel <ASE name.appserviceenvironment.net> en een app met de naam mytest, gebruikt u mytest.<ASE name.appserviceenvironment.net> voor FTP en mytest.scm.contoso.net voor MSDeploy-implementatie.

Een ILB AS-omgeving configureren met een WAF-apparaat

U kunt een Web Application Firewall-apparaat (WAF) koppelen aan uw ILB-AS-omgeving om alleen de apps weer te geven die u nodig hebt via internet en de rest alleen toegankelijk vanuit het VNet te houden. Zo kunt u onder andere beveiligde toepassingen met meerdere lagen bouwen.

Zie Een WAF (Web Application Firewall) configureren met uw App Service-omgeving voor meer informatie over het configureren van de ILB AS-omgeving met een WAF-apparaat. In dit artikel leest u hoe u een virtueel Barracuda-apparaat gebruikt met de AS-omgeving. Een andere optie is het gebruik van Azure Application Gateway. Application Gateway maakt gebruik van de OWASP-kernregels om alle toepassingen te beveiligen die erachter zijn geplaatst. Zie Introduction to the Azure web application firewall (Inleiding tot de WAF (Web Application Firewall) in Azure) voor meer informatie over Application Gateway.

ILB AS-omgevingen die zijn gemaakt vóór mei 2019

Voor ILB AS-omgevingen die werden gemaakt vóór 2019, moest u het domeinachtervoegsel instellen tijdens het maken van de AS-omgeving. U moest ook een standaardcertificaat uploaden dat was gebaseerd op het achtervoegsel van dat domein. Met een oudere ILB AS-omgeving is het niet mogelijk om eenmalige aanmelding uit te voeren op de Kudu-console met apps in die ILB AS-omgeving. Bij het configureren van een DNS voor een oudere ILB AS-omgeving moet u het A-record met jokerteken instellen op een zone die overeenkomt met uw domeinachtervoegsel. Voor het maken of wijzigen van ILB ASE met aangepast domeinachtervoegsel moet u Azure Resource Manager-sjablonen en een API-versie vóór 2019 gebruiken. De api-versie van de laatste ondersteuning is 2018-11-01.

Aan de slag

• Zie Introduction to App Service environments (Inleiding tot App Service-omgevingen) om aan de slag te gaan met AS-omgevingen.