Een App Service-omgeving beheren
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.
Een App Service Environment (ASE) is een implementatie van Azure-app Service in een subnet in het Azure Virtual Network-exemplaar van een klant. Een ASE bestaat uit:
- Front-ends: waar HTTP of HTTPS wordt beëindigd in een App Service-omgeving
- Werknemers: De resources die uw apps hosten
- Database: bevat informatie die de omgeving definieert
- Opslag: wordt gebruikt om de door de klant gepubliceerde apps te hosten
U kunt een ASE implementeren met een extern of intern virtueel IP-adres (VIP) voor toegang tot apps. Een implementatie met een extern VIP wordt meestal een externe ASE genoemd. Een implementatie met een intern VIP wordt een ILB AS-omgeving genoemd omdat deze gebruikmaakt van een interne load balancer (ILB). Zie Een ILB AS-omgeving maken en gebruiken voor meer informatie over de ILB AS-omgeving.
Een app maken in een ASE
Als u een app in een ASE wilt maken, gebruikt u hetzelfde proces als wanneer u normaal gesproken een app maakt, maar met enkele kleine verschillen. Wanneer u een nieuw App Service-plan maakt:
- In plaats van een geografische locatie te kiezen waarin u uw app wilt implementeren, kiest u een ASE als uw locatie.
- Alle App Service-plannen die in een ASE zijn gemaakt, kunnen alleen in een geïsoleerde prijscategorie staan.
Als u geen ASE hebt, kunt u er een maken door de instructies te volgen in Een App Service-omgeving maken.
Een app maken in een ASE:
Selecteer Een resourceweb>en mobiele>web-app maken.
Voer een naam voor de app in. Als u al een App Service-plan in een ASE hebt geselecteerd, weerspiegelt de domeinnaam voor de app de domeinnaam van de ASE:
Selecteer een abonnement.
Voer een naam in voor een nieuwe resourcegroep of selecteer Bestaande gebruiken en selecteer een naam in de vervolgkeuzelijst.
Selecteer uw besturingssysteem.
Selecteer een bestaand App Service-plan in uw ASE of maak een nieuw plan door de volgende stappen uit te voeren:
a. Selecteer in het menu aan de linkerkant van Azure Portal een resourceweb-app >maken.
b. Selecteer het abonnement.
c. Selecteer of maak de resourcegroep.
d. Voer de naam van uw web-app in.
e. Selecteer Code of DockerContainer.
f. Selecteer een runtimestack.
g. Selecteer Linux of Windows.
h. Selecteer uw ASE in de vervolgkeuzelijst Regio .
i. Selecteer of maak een nieuw App Service-plan. Als u een nieuw App Service-plan maakt, selecteert u de juiste geïsoleerde SKU-grootte.
Notitie
Linux-apps en Windows-apps kunnen zich niet in hetzelfde App Service-plan bevinden, maar ze kunnen zich in dezelfde App Service-omgeving bevinden.
Selecteer Beoordelen en maken, controleer of de informatie juist is en selecteer vervolgens Maken.
Hoe schalen werkt
Elke App Service-app wordt uitgevoerd in een App Service-plan. App Service-omgevingen bevatten App Service-plannen en App Service-plannen bevatten apps. Wanneer u een app schaalt, schaalt u ook het App Service-plan en alle apps in datzelfde plan.
Wanneer u een App Service-plan schaalt, wordt de benodigde infrastructuur automatisch toegevoegd. Er is een tijdsvertraging voor het schalen van bewerkingen terwijl de infrastructuur wordt toegevoegd. Als u meerdere schaalbewerkingen op volgorde uitvoert, wordt de eerste aanvraag voor de infrastructuurschaal uitgevoerd en worden de andere in de wachtrij geplaatst. Wanneer de eerste schaalbewerking is voltooid, werken de andere infrastructuuraanvragen allemaal samen. En wanneer de infrastructuur wordt toegevoegd, worden de App Service-plannen waar nodig toegewezen. Het maken van een nieuw App Service-plan is zelf een schaalbewerking omdat er extra hardware wordt aangevraagd. Een schaalbewerking duurt meestal 30-60 minuten. Upgrades zijn ook bewerkingen die het schalen blokkeren terwijl ze worden uitgevoerd.
In de multitenant App Service is schalen direct omdat een groep resources direct beschikbaar is om deze te ondersteunen. In een ASE is er geen dergelijke buffer en worden resources toegewezen op basis van behoefte.
In een ASE kunt u een App Service-plan schalen tot 100 exemplaren. Een ASE kan maximaal 201 exemplaren bevatten voor alle App Service-abonnementen in die ASE.
IP-adressen
App Service kan een toegewezen IP-adres toewijzen aan een app. Deze mogelijkheid is beschikbaar nadat u een TLS/SSL-binding op basis van IP hebt geconfigureerd, zoals beschreven in Bind an existing custom TLS/SSL certificate to Azure-app Service. In een ILB AS-omgeving kunt u geen meer IP-adressen toevoegen die moeten worden gebruikt voor de TLS/SSL-binding op basis van IP.
Met een externe ASE kunt u een OP IP gebaseerde TLS/SSL-binding voor uw app op dezelfde manier configureren als in de multitenant App Service. Er is altijd één reserveadres in de ASE, maximaal 30 IP-adressen. Telkens wanneer u de ene gebruikt, wordt er een andere toegevoegd, zodat een adres altijd direct beschikbaar is. Een tijdsvertraging is vereist om een ander IP-adres toe te wijzen. Deze vertraging voorkomt het toevoegen van IP-adressen achter elkaar.
Front-end schalen
Wanneer u uw App Service-abonnementen uitschaalt, worden werknemers automatisch toegevoegd om ze te ondersteunen. Elke ASE wordt gemaakt met twee front-ends. De front-ends worden automatisch uitgeschaald met een snelheid van één front-end voor elke set van 15 Exemplaren van het App Service-plan. Als u bijvoorbeeld drie App Service-abonnementen met elk vijf exemplaren hebt, hebt u in totaal 15 exemplaren en drie front-ends. Als u in totaal 30 exemplaren schaalt, hebt u vier front-ends. Dit patroon wordt voortgezet terwijl u uitschaalt.
Het aantal front-ends dat standaard wordt toegewezen, is goed voor een gemiddelde belasting. U kunt de verhouding verlagen tot slechts één front-end voor elke vijf exemplaren. U kunt ook de grootte van de front-ends wijzigen. Standaard zijn ze één kern. In Azure Portal kunt u in plaats daarvan de grootte wijzigen in twee of vier kernen.
Er worden kosten in rekening gebracht voor het wijzigen van de verhouding of de front-endgrootten. Zie Azure-app Service-prijzen voor meer informatie. Als u de laadcapaciteit van uw ASE wilt verbeteren, krijgt u meer verbetering door eerst te schalen naar front-ends met twee kernen voordat u de schaalverhouding aanpast. Als u de kerngrootte van uw front-ends wijzigt, wordt er een upgrade van uw ASE uitgevoerd en moet deze buiten normale kantooruren worden uitgevoerd.
Front-endbronnen zijn het HTTP/HTTPS-eindpunt voor de ASE. Met de standaard front-endconfiguratie is het geheugengebruik per front-end consistent ongeveer 60 procent. De belangrijkste reden voor het schalen van uw front-ends is HET CPU-gebruik, dat voornamelijk wordt aangestuurd door HTTPS-verkeer.
App openen
In een externe ASE is het domeinachtervoegsel dat wordt gebruikt voor het maken van apps.<asename.p.azurewebsites.net>. Als uw ASE een externe as heet en u een app host die contoso in die ASE heet, bereikt u deze op deze URL's:
- contoso.external-ase.p.azurewebsites.net
- contoso.scm.external-ase.p.azurewebsites.net
Zie Een App Service-omgeving maken voor meer informatie over het maken van een externe ASE.
In een ILB AS-omgeving is het domeinachtervoegsel dat wordt gebruikt voor het maken van apps.<asename.appserviceenvironment.net>. Als uw ASE de naam ilb-ase heeft en u een app host met de naam contoso in die ASE, bereikt u deze op deze URL's:
- contoso.ilb-ase.appserviceenvironment.net
- contoso.scm.ilb-ase.appserviceenvironment.net
Zie Een ILB AS-omgeving maken en gebruiken voor informatie over het maken van een ILB AS-omgeving.
De SCM-URL wordt gebruikt voor toegang tot de Kudu-console of voor het publiceren van uw app met behulp van Web Deploy. De Kudu-console biedt u een webgebruikersinterface voor foutopsporing, het uploaden van bestanden, het bewerken van bestanden en nog veel meer.
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:
- een zone maken voor <ASE name.appserviceenvironment.net>
- Maak in die zone een A-record die * verwijst naar het IP-adres van de ILB
- Maak in die zone een A-record die @ verwijst naar het IP-adres van de ILB
- maak een zone in <ASE name.appserviceenvironment.net> met de naam scm
- Maak in die SCM-zone een A-record die * verwijst naar het IP-adres van de ILB
DNS configureren in Azure DNS particuliere zones:
- Maak een Azure DNS privézone met de naam <ASE-naam>.appserviceenvironment.net
- Maak in die zone een A-record die * verwijst naar het IP-adres van de ILB
- Maak in die zone een A-record die @ verwijst naar het IP-adres van de ILB
- 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 naar het IP-adres van de ILB verwijzen. De aangepaste domein naam werkt voor app-aanvragen, maar niet voor de SCM-site. De scm-site is alleen beschikbaar op <appname.scm.<>asename.appserviceenvironment.net>.
De zone met de naam .<asename.appserviceenvironment.net> is wereldwijd uniek. Voor 2019 konden klanten het achtervoegsel van het domein van de ILB ASE opgeven. Als u .contoso.com wilt gebruiken voor het domeinachtervoegsel, kunt u dit doen en dat zou de scm-site 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. Als uw ILB ASE V2 na mei 2019 is gemaakt, hoeft u het standaardcertificaat van de ILB niet te beheren omdat het wordt beheerd door Microsoft.
Publiceren
In een AS-omgeving, net als bij de app-service met meerdere tenants, kunt u deze methoden publiceren:
- Web-implementatie
- FTP
- Continue integratie (CI)
- Slepen en neerzetten in de Kudu-console
- Een IDE, zoals Visual Studio, Eclipse of IntelliJ IDEA
Met een externe ASE werken deze publicatieopties allemaal op dezelfde manier. Zie Implementatie in Azure-app Service voor meer informatie.
Met een ILB AS-omgeving zijn de publicatie-eindpunten alleen beschikbaar via de ILB. De ILB bevindt zich op een privé-IP in het ASE-subnet in het virtuele netwerk. Als u geen netwerktoegang tot de ILB hebt, kunt u geen apps op die ASE publiceren. Zoals vermeld in Een ILB AS-omgeving maken en gebruiken, moet u DNS configureren voor de apps in het systeem. Deze vereiste omvat het SCM-eindpunt. Als de eindpunten niet juist zijn gedefinieerd, kunt u het niet publiceren. Uw IDE's moeten ook netwerktoegang hebben tot de ILB om er rechtstreeks naar te kunnen publiceren.
Zonder extra wijzigingen werken CI-systemen op internet, zoals GitHub en Azure DevOps, niet met een ILB AS-omgeving, omdat het publicatie-eindpunt niet toegankelijk is voor internet. U kunt publiceren naar een ILB ASE vanuit Azure DevOps inschakelen door een zelf-hostende releaseagent te installeren in het virtuele netwerk dat de ILB ASE bevat. U kunt ook een CI-systeem gebruiken dat gebruikmaakt van een pull-model, zoals Dropbox.
De publicatie-eindpunten voor apps in een ILB AS-omgeving maken gebruik van het domein waarmee de ILB AS-omgeving is gemaakt. U kunt het zien in het publicatieprofiel van de app en in het portalvenster van de app (in Overzicht>essentials en ook in Eigenschappen).
Storage
Een ASE heeft 1 TB opslagruimte voor alle apps in de ASE. Een App Service-plan in de geïsoleerde prijs-SKU heeft een limiet van 250 GB. In een ASE wordt 250 GB opslagruimte toegevoegd per App Service-plan tot de limiet van 1 TB. U kunt meer App Service-abonnementen hebben dan slechts vier, maar er is geen opslagruimte meer toegevoegd dan de limiet van 1 TB.
Controleren
Als klant moet u de App Service-plannen en de afzonderlijke apps bewaken die worden uitgevoerd en de juiste acties uitvoeren. Voor App Service Environment v2 moet u ook aandacht besteden aan de metrische gegevens rondom de platforminfrastructuur. Deze metrische gegevens geven u inzicht in de manier waarop de platforminfrastructuur en front-endservers (multiRole) bezig zijn en u kunt actie ondernemen als ze intensief worden gebruikt en u geen maximale doorvoer krijgt.
Via Azure Portal en CLI kunt u de schaalverhouding van uw front-endservers tussen 5 en 15 (standaard 15) App Service-planexemplaren per front-endserver configureren. Een App Service Environment heeft altijd minimaal twee front-endservers. U kunt ook de grootte van de front-endservers vergroten.
Het bereik met metrische gegevens dat wordt gebruikt om de platforminfrastructuur te bewaken, wordt aangeroepen Microsoft.Web/hostingEnvironments/multiRolePools
.
U ziet een bereik met de naam Microsoft.Web/hostingEnvironments/workerPools
. De metrische gegevens hier zijn alleen van toepassing op App Service Environment v1.
Logboekregistratie
U kunt uw ASE integreren met Azure Monitor om logboeken over de ASE te verzenden naar Azure Storage, Azure Event Hubs of Log Analytics. Deze items worden vandaag geregistreerd:
Situatie | Bericht |
---|---|
ASE is beschadigd | De opgegeven ASE is beschadigd vanwege een ongeldige configuratie van het virtuele netwerk. De ASE wordt onderbroken als de status Beschadigd blijft. Zorg ervoor dat de hier gedefinieerde richtlijnen worden gevolgd: Netwerkoverwegingen voor een App Service-omgeving. |
ASE-subnet is bijna buiten de ruimte | De opgegeven ASE bevindt zich in een subnet dat bijna buiten de ruimte is. Er zijn {0} resterende adressen. Zodra deze adressen zijn uitgeput, kan de ASE niet meer worden geschaald. |
ASE nadert de totale exemplaarlimiet | De opgegeven ASE nadert de totale exemplaarlimiet van de ASE. Het bevat {0} momenteel Exemplaren van het App Service-plan van maximaal 201 exemplaren. |
ASE kan geen afhankelijkheid bereiken | De opgegeven ASE kan niet worden bereikt {0}. Zorg ervoor dat de hier gedefinieerde richtlijnen worden gevolgd: Netwerkoverwegingen voor een App Service-omgeving. |
ASE is onderbroken | De opgegeven ASE is onderbroken. De ASE-schorsing kan worden veroorzaakt door een accounttekort of een ongeldige configuratie van een virtueel netwerk. Los de hoofdoorzaak op en hervat de ASE om door te gaan met verkeer. |
DE ASE-upgrade is gestart | Er is een platformupgrade naar de opgegeven ASE gestart. Verwacht vertragingen in schaalbewerkingen. |
De ASE-upgrade is voltooid | Een platformupgrade naar de opgegeven ASE is voltooid. |
Schaalbewerkingen zijn gestart | Een App Service-plan ({0}) is begonnen met schalen. Gewenste staat: {1} Ik{2} werkers. |
Schaalbewerkingen zijn voltooid | Het schalen van een App Service-plan ({0}) is voltooid. Huidige staat: {1} Ik{2} werkers. |
Schaalbewerkingen zijn mislukt | Een App Service-plan ({0}) kan niet worden geschaald. Huidige staat: {1} Ik{2} werkers. |
Logboekregistratie inschakelen voor uw ASE:
- Ga in de portal naar Diagnostische instellingen.
- Selecteer Diagnostische instellingen toevoegen.
- Geef een naam op voor de logboekintegratie.
- Selecteer en configureer de gewenste logboekbestemmingen.
- Selecteer AppServiceEnvironmentPlatformLogs.
Als u integreert met Log Analytics, kunt u de logboeken zien door Logboeken te selecteren in de ASE-portal en een query te maken op AppServiceEnvironmentPlatformLogs. Logboeken worden alleen verzonden wanneer uw ASE een gebeurtenis heeft die deze activeert. Als uw ASE geen dergelijke gebeurtenis heeft, zijn er geen logboeken. Als u snel een voorbeeld van logboeken in uw Log Analytics-werkruimte wilt zien, voert u een schaalbewerking uit met een van de App Service-plannen in uw ASE. Vervolgens kunt u een query uitvoeren op AppServiceEnvironmentPlatformLogs om deze logboeken te bekijken.
Een waarschuwing maken
Als u een waarschuwing wilt maken voor uw logboeken, volgt u de instructies in Logboekwaarschuwingen maken, weergeven en beheren met behulp van Azure Monitor. Kortom:
- De pagina Waarschuwingen openen in uw ASE-portal
- Nieuwe waarschuwingsregel selecteren
- Selecteer uw resource als uw Log Analytics-werkruimte
- Stel uw voorwaarde in met een aangepaste zoekopdracht in logboeken om een query te gebruiken zoals 'AppServiceEnvironmentPlatformLogs | waarbij ResultDescription 'is begonnen met schalen' bevat of wat u maar wilt. Stel de drempelwaarde zo nodig in.
- U kunt desgewenst een actiegroep toevoegen of maken. In de actiegroep definieert u het antwoord op de waarschuwing, zoals het verzenden van een e-mailbericht of een sms-bericht
- Geef uw waarschuwing een naam en sla deze op.
Upgradevoorkeur
Als u meerdere AS-omgevingen hebt, wilt u mogelijk dat sommige AS-omgevingen worden bijgewerkt voordat anderen worden bijgewerkt. Dit gedrag kan worden ingeschakeld via uw ASE-portal. Onder Configuratie hebt u de optie om upgradevoorkeur in te stellen. De drie mogelijke waarden zijn:
- Geen: Azure voert een upgrade uit van uw ASE in geen bepaalde batch. Dit is de standaardwaarde.
- Vroeg: Uw ASE wordt in de eerste helft van de App Service-upgrades bijgewerkt.
- Laat: Uw ASE wordt bijgewerkt in de tweede helft van de App Service-upgrades.
Selecteer de gewenste waarde en selecteer Opslaan. De standaardwaarde voor een ASE is Geen.
De functie upgradePreferences is het meest zinvol wanneer u meerdere AS's hebt, omdat uw 'vroege' AS's worden bijgewerkt voordat uw 'late' AS's worden bijgewerkt. Wanneer u meerdere AS's hebt, moet u uw ontwikkelings- en test-AS's instellen op 'Vroeg' en uw productie-AS's op 'Laat'.
Prijzen
De prijs-SKU met de naam Isolated is alleen voor gebruik met AS-omgevingen. Alle App Service-abonnementen die in de ASE worden gehost, bevinden zich in de geïsoleerde prijs-SKU. Geïsoleerde tarieven voor App Service-abonnementen kunnen per regio verschillen.
Naast de prijs van uw App Service-abonnementen is er een vast tarief voor de ASE zelf. Het vaste tarief verandert niet met de grootte van uw ASE. Het betaalt voor de ASE-infrastructuur met een standaardschaalsnelheid van één extra front-end voor elke 15 App Service-planinstanties.
Als de standaardschaalsnelheid van één front-end voor elke 15 App Service-planexemplaren niet snel genoeg is, kunt u de verhouding aanpassen waarmee front-ends worden toegevoegd of de grootte van de front-ends. Wanneer u de verhouding of grootte aanpast, betaalt u voor de front-endkernen die niet standaard worden toegevoegd.
Als u bijvoorbeeld de schaalverhouding aanpast naar 10, wordt er een front-end toegevoegd voor elke 10 exemplaren in uw App Service-abonnementen. De vaste vergoeding dekt een schaalsnelheid van één front-end voor elke 15 exemplaren. Met een schaalverhouding van 10 betaalt u een vergoeding voor de derde front-end die wordt toegevoegd voor de 10 Exemplaren van het App Service-plan. U hoeft er niet voor te betalen wanneer u 15 exemplaren bereikt, omdat deze automatisch is toegevoegd.
Als u de grootte van de front-ends aanpast aan twee kernen, maar de verhouding niet aanpast, betaalt u voor de extra kernen. Er wordt een AS-omgeving gemaakt met twee front-ends, dus zelfs onder de drempelwaarde voor automatisch schalen betaalt u voor twee extra kernen als u de grootte vergroot naar front-ends met twee kernen.
Zie Azure-app Service-prijzen voor meer informatie.
Een ASE verwijderen
Een ASE verwijderen:
Selecteer Verwijderen boven aan het deelvenster App Service Environment .
Voer de naam van uw ASE in om te bevestigen dat u deze wilt verwijderen. Wanneer u een ASE verwijdert, verwijdert u ook alle inhoud erin.
Selecteer OK.
ASE CLI
Er zijn opdrachtregelmogelijkheden voor het beheer van een ASE. De Azure CLI-opdrachten worden hieronder vermeld.
C:\>az appservice ase --help
Group
az appservice ase : Manage App Service Environments v2.
This command group is in preview. It may be changed/removed in a future release.
Commands:
create : Create app service environment.
delete : Delete app service environment.
list : List app service environments.
list-addresses : List VIPs associated with an app service environment.
list-plans : List app service plans associated with an app service environment.
show : Show details of an app service environment.
update : Update app service environment.
For more specific examples, use: az find "az appservice ase"