Gestire un ambiente del servizio app

Importante

Questo articolo riguarda ambiente del servizio app v2, usato con i piani di servizio app isolato. ambiente del servizio app v2 verrà ritirato il 31 agosto 2024. È disponibile una nuova versione di ambiente del servizio app che è più facile da usare e che viene eseguita su un'infrastruttura più potente. Per altre informazioni sulla nuova versione, iniziare con l'introduzione alla ambiente del servizio app. Se si usa attualmente ambiente del servizio app v2, seguire la procedura descritta in questo articolo per eseguire la migrazione alla nuova versione.

A partire dal 29 gennaio 2024, non è più possibile creare nuove risorse ambiente del servizio app v2 usando uno dei metodi disponibili, inclusi i modelli ARM/Bicep, il portale di Azure, l'interfaccia della riga di comando di Azure o l'API REST. È necessario eseguire la migrazione a ambiente del servizio app v3 prima del 31 agosto 2024 per evitare l'eliminazione delle risorse e la perdita di dati.

Un ambiente del servizio app (A edizione Standard) è una distribuzione di app Azure Service in una subnet nell'istanza di Azure Rete virtuale di un cliente. Un oggetto A edizione Standard è costituito da:

• Front-end: dove HTTP o HTTPS termina in un ambiente del servizio app
• Ruoli di lavoro: le risorse che ospitano le app
• Database: contiene informazioni che definiscono l'ambiente
• Archiviazione: usato per ospitare le app pubblicate dal cliente

È possibile distribuire un oggetto A edizione Standard con un indirizzo IP virtuale esterno o interno (VIP) per l'accesso alle app. Una distribuzione con un indirizzo VIP esterno è comunemente detta A esterno edizione Standard. Una distribuzione con un indirizzo VIP interno viene chiamata bilanciamento del carico interno edizione Standard perché usa un servizio di bilanciamento del carico interno (ILB). Per altre informazioni sull'ambiente del servizio app con bilanciamento del carico interno, vedere Creazione e uso di un servizio di bilanciamento del carico interno con un ambiente del servizio app.

Creare un'app in un ambiente del servizio app

Per creare un'app in un edizione Standard A, si usa lo stesso processo di quando si crea normalmente un'app, ma con alcune piccole differenze. Quando si crea un nuovo piano di servizio app:

• Invece di selezionare una località geografica per distribuire l'app, selezionare un ambiente del servizio app come posizione.
• Tutti i piani servizio app creati in un oggetto A edizione Standard possono trovarsi solo in un piano tariffario isolato.

Se non si dispone di un oggetto A edizione Standard, è possibile crearne uno seguendo le istruzioni riportate in Creare un ambiente del servizio app.

Per creare un'app in un ambiente del servizio app:

1. Selezionare Crea una risorsa>Web e dispositivi mobili>App Web.

2. Immetti il nome per l'app. Se è già stato selezionato un piano di servizio app in un edizione Standard A, il nome di dominio per l'app riflette il nome di dominio di A edizione Standard:

   

3. Seleziona un abbonamento.

4. Immettere un nome per un nuovo gruppo di risorse, oppure fare clic su Usa esistente e selezionarne uno dall'elenco a discesa.

5. Selezionare il sistema operativo.

6. Selezionare un piano di servizio app esistente nell'ambiente del servizio app o crearne uno nuovo con la procedura seguente:

   a. Dal menu portale di Azure sul lato sinistro selezionare Crea una risorsa > App Web.

   b. Selezionare la sottoscrizione.

   c. Selezionare o creare il gruppo di risorse.

   d. Immettere il nome dell'app Web.

   e. Selezionare Codice o DockerContainer.

   f. Select a runtime stack.

   g. Selezionare Linux o Windows.

   h. Selezionare il edizione Standard A nell'elenco a discesa Area.

   i. Selezionare o creare un nuovo piano di servizio app. Se si crea un nuovo piano di servizio app, selezionare le dimensioni dello SKU isolato appropriate.

   

   Nota

   Le app Linux e le app di Windows non possono trovarsi nello stesso piano di servizio app, ma possono trovarsi nello stesso ambiente del servizio app.

7. Selezionare Rivedi e crea, verificare che le informazioni siano corrette e quindi selezionare Crea.

Come funziona il ridimensionamento

Ogni app del servizio app viene eseguita in un piano di servizio app. Gli ambienti del servizio app di Azure contengono piani del servizio app, che a loro volta contengono app. Quando si ridimensiona un'app, si ridimensiona anche il piano servizio app e tutte le app nello stesso piano.

Quando si ridimensiona un piano di servizio app, l'infrastruttura necessaria viene aggiunta automaticamente. Si verifica un ritardo di tempo per ridimensionare le operazioni durante l'aggiunta dell'infrastruttura. Se si eseguono diverse operazioni di scalabilità in sequenza, viene eseguita la prima richiesta di scalabilità dell'infrastruttura e le altre vengono accodate. Al termine della prima operazione di scalabilità, tutte le altre richieste dell'infrastruttura operano insieme. E quando viene aggiunta l'infrastruttura, i piani di servizio app vengono assegnati in base alle esigenze. La creazione di un nuovo piano di servizio app è un'operazione di scalabilità perché richiede hardware aggiuntivo. Il completamento di un'operazione di scalabilità richiede in genere 30-60 minuti.

Nel servizio app multi-tenant, il ridimensionamento è immediato perché un pool di risorse è immediatamente disponibile per supportarlo. In un oggetto A edizione Standard non esiste un buffer di questo tipo e le risorse vengono allocate in base alle esigenze.

In un edizione Standard A è possibile ridimensionare un servizio app pianificare fino a 100 istanze. Un edizione Standard A può avere fino a 201 istanze totali in tutti i piani di servizio app in tale A edizione Standard.

Indirizzi IP

servizio app può allocare un indirizzo IP dedicato a un'app. Questa funzionalità è disponibile dopo aver configurato un'associazione TLS/SSL basata su IP, come descritto in Associare un certificato TLS/SSL personalizzato esistente a app Azure Servizio. In un servizio di bilanciamento del carico interno a edizione Standard non è possibile aggiungere altri indirizzi IP da usare per l'associazione TLS/SSL basata su IP.

Con un edizione Standard esterno, è possibile configurare un'associazione TLS/SSL basata su IP per l'app nello stesso modo in cui nel servizio app multi-tenant. C'è sempre un indirizzo di riserva in A edizione Standard, fino a 30 indirizzi IP. Ogni volta che si usa un indirizzo, viene aggiunto un altro in modo che un indirizzo sia sempre prontamente disponibile. È necessario un ritardo di tempo per allocare un altro indirizzo IP. Questo ritardo impedisce l'aggiunta di indirizzi IP in rapida successione.

Scalabilità front-end

Quando si aumenta il numero di istanze dei piani di servizio app, i ruoli di lavoro vengono aggiunti automaticamente per supportarli. Ogni ambiente del servizio app viene creato con due front-end. I front-end aumentano automaticamente il numero di istanze del piano a una velocità di un front-end per ogni set di 15 istanze del piano di servizio app. Ad esempio, se sono presenti tre piani servizio app con cinque istanze ciascuno, si avranno un totale di 15 istanze e tre front-end. Se si raggiunge un totale di 30 istanze, si hanno quattro front-end. Questo modello continua man mano che si aumenta il numero di istanze.

Il numero di front-end allocati per impostazione predefinita è valido per un carico moderato. È possibile ridurre il rapporto a un numero minimo di front-end per ogni cinque istanze. È anche possibile modificare le dimensioni dei front-end. Per impostazione predefinita, sono un singolo core. Nella portale di Azure è possibile modificare le dimensioni in due o quattro core.

È previsto un addebito per la modifica del rapporto o delle dimensioni front-end. Per altre informazioni, vedere Prezzi del Servizio app di Azure. Se si vuole migliorare la capacità di carico dell'A edizione Standard, si otterrà un miglioramento maggiore ridimensionando prima i front-end a due core prima di regolare il rapporto di scalabilità. La modifica delle dimensioni principali dei front-end causerà un aggiornamento dell'A edizione Standard e dovrebbe essere eseguita al di fuori dell'orario di ufficio normale.

Le risorse front-end sono gli endpoint HTTP/HTTPS per l'ambiente del servizio app. Con la configurazione front-end predefinita, l'uso della memoria per ogni front-end è di circa il 60%. Il motivo principale per ridimensionare i front-end è l'utilizzo della CPU, che è principalmente guidato dal traffico HTTPS.

Accesso all'app

In un oggetto A edizione Standard esterno, il suffisso di dominio usato per la creazione dell'app è .<asename.p.azurewebsites.net>. Se il nome A edizione Standard è external-ase e si ospita un'app denominata contoso in tale A edizione Standard, è possibile raggiungerla in questi URL:

• contoso.external-ase.p.azurewebsites.net
• contoso.scm.external-ase.p.azurewebsites.net

Per informazioni su come creare un oggetto A esterno edizione Standard, vedere Creare un ambiente del servizio app.

In un ilB A edizione Standard, il suffisso di dominio usato per la creazione dell'app è .<asename.appserviceenvironment.net>. Se il nome A edizione Standard è ilb-ase e si ospita un'app denominata contoso in tale A edizione Standard, è possibile raggiungerla in questi URL:

• contoso.ilb-ase.appserviceenvironment.net
• contoso.scm.ilb-ase.appserviceenvironment.net

Per informazioni su come creare un servizio di bilanciamento del carico interno di Azure edizione Standard, vedere Creare e usare un servizio di bilanciamento del carico interno a edizione Standard.

L'URL SCM viene usato per accedere alla console Kudu o per la pubblicazione dell'app tramite Distribuzione Web. La console Kudu offre un'interfaccia utente Web per il debug, il caricamento di file, la modifica di file e altro ancora.

Configurazione del DNS

Sei si usa un ambiente del servizio app esterno, le app create al suo interno vengono registrate con DNS di Azure. In un ambiente del servizio app esterno per rendere le app disponibili pubblicamente non sono previsti passaggi aggiuntivi. In un ambiente del servizio app ILB, è necessario gestire il proprio DNS. È possibile farlo nel proprio server DNS o nelle zone private di DNS di Azure.

Per configurare DNS nel proprio server DNS con l'ambiente del servizio app ILB:

1. creare una zona per <A edizione Standard name.appserviceenvironment.net>
2. creare un record A in tale zona che punti * all'indirizzo IP del servizio ILB
3. creare un record A in tale zona che punti @ all'indirizzo IP del servizio ILB
4. creare una zona in <A edizione Standard name.appserviceenvironment.net> denominata scm
5. creare un record A nella zona che punti * all'indirizzo IP del servizio ILB

Per configurare DNS nelle zone private di DNS di Azure:

1. creare una zona privata di DNS di Azure denominata <nome ambiente del servizio app>.appserviceenvironment.net
2. creare un record A in tale zona che punti * all'indirizzo IP del servizio ILB
3. creare un record A in tale zona che punti @ all'indirizzo IP del servizio ILB
4. Creare un record A in tale zona che punta *.scm all'indirizzo IP del servizio ILB

Le impostazioni DNS per il suffisso di dominio predefinito dell'ambiente del servizio app non limitano l'accesso alle app solo a questi nomi. In un ambiente del servizio app ILB è possibile impostare un nome di dominio personalizzato senza alcuna convalida nelle app. Se si vuole creare una zona denominata contoso.net, è possibile farlo e puntare all'indirizzo IP del servizio di bilanciamento del carico interno. Il nome del dominio personalizzato funziona per le richieste di app ma non per il sito scm. Il sito scm è disponibile solo in <appname.scm>.<asename.appserviceenvironment.net>.

Zona denominata .<asename.appserviceenvironment.net> è globalmente univoco. Prima del mese di maggio 2019, i clienti potevano specificare il suffisso di dominio dell'ambiente del servizio app ILB. Se si vuole usare .contoso.com per il suffisso di dominio, è possibile farlo e includere il sito scm. Si sono verificati problemi con tale modello, tra cui; gestione del certificato TLS/SSL predefinito, mancanza di accesso Single Sign-On con il sito scm e il requisito di usare un certificato con caratteri jolly. Il processo di aggiornamento del certificato predefinito dell'ambiente del servizio app ILB era inoltre complicato e causava il riavvio dell'applicazione. Per risolvere questi problemi, il comportamento dell'ambiente del servizio app ILB è stato cambiato e prevede ora l'uso di un suffisso di domino basato sul nome dell'ambiente del servizio app con un suffisso di proprietà di Microsoft. La modifica del comportamento dell'ambiente del servizio app ILB influisce solo su tali ambienti creati dopo maggio 2019. Gli ambienti del servizio app ILB preesistenti continuano a gestire il certificato predefinito dell'ambiente e la rispettiva configurazione DNS. Se il servizio di bilanciamento del carico interno A edizione Standard V2 è stato creato dopo maggio 2019, non è necessario gestire il certificato predefinito ilB perché è gestito da Microsoft.

Pubblicazione

In un edizione Standard A, come per il servizio app multi-tenant, è possibile pubblicare con questi metodi:

• Distribuzione Web
• FTP
• Integrazione continua (CI)
• Trascinamento della selezione nella console Kudu
• Un IDE, ad esempio Visual Studio, Eclipse o IntelliJ IDEA

Con un oggetto A esterno edizione Standard queste opzioni di pubblicazione funzionano allo stesso modo. Per altre informazioni, vedere Distribuzione nel servizio app di Azure.

Con un ilB A edizione Standard, gli endpoint di pubblicazione sono disponibili solo tramite il servizio di bilanciamento del carico interno. Il servizio di bilanciamento del carico interno è in un IP privato nella subnet dell'ambiente del servizio app nella rete virtuale. Se non si ha accesso alla rete al servizio di bilanciamento del carico interno, non è possibile pubblicare app in tale A edizione Standard. Come indicato in Creare e usare un ilB A edizione Standard, è necessario configurare IL DNS per le app nel sistema. Questo requisito include l'endpoint SCM. Se gli endpoint non sono definiti correttamente, non è possibile pubblicare. Gli IDE devono anche avere accesso alla rete al servizio di bilanciamento del carico interno per pubblicarlo direttamente.

Senza modifiche aggiuntive, i sistemi ci basati su Internet come GitHub e Azure DevOps non funzionano con un servizio di bilanciamento del carico interno edizione Standard perché l'endpoint di pubblicazione non è accessibile da Internet. È possibile abilitare la pubblicazione in un servizio di bilanciamento del carico interno a edizione Standard da Azure DevOps installando un agente di versione self-hosted nella rete virtuale che contiene il servizio di bilanciamento del carico interno a edizione Standard. In alternativa, è anche possibile usare un sistema di integrazione continua che usa un modello di pull, ad esempio Dropbox.

Gli endpoint di pubblicazione per le app in un ambiente del servizio app con bilanciamento del carico interno usano il dominio con cui l'ambiente del servizio app con bilanciamento del carico interno è stato creato, È possibile visualizzarlo nel profilo di pubblicazione dell'app e nel riquadro del portale dell'app (in Panoramica>Informazioni di base e anche in Proprietà).

Storage

Un edizione Standard A ha 1 TB di spazio di archiviazione per tutte le app nella A edizione Standard. Un piano servizio app nello SKU dei prezzi isolato ha un limite di 250 GB. In un A edizione Standard, 250 GB di spazio di archiviazione viene aggiunto per servizio app piano fino al limite di 1 TB. È possibile avere più piani servizio app rispetto a soli quattro, ma non è stato aggiunto più spazio di archiviazione oltre il limite di 1 TB.

Monitoraggio

I clienti devono monitorare i piani di servizio app e le singole app in esecuzione e intraprendere le azioni appropriate. Per ambiente del servizio app v2, è necessario prestare attenzione anche alle metriche relative all'infrastruttura della piattaforma. Queste metriche forniscono informazioni dettagliate sulle modalità di esecuzione dell'infrastruttura della piattaforma e dei server front-end (multiRole) ed è possibile intervenire se vengono usati pesantemente e non si ottiene la velocità effettiva massima.

Tramite portale di Azure e l'interfaccia della riga di comando, è possibile configurare il rapporto di scalabilità dei server front-end tra 5 e 15 (impostazione predefinita 15) servizio app istanze del piano per ogni server front-end. Un ambiente del servizio app avrà sempre almeno due server front-end. È anche possibile aumentare le dimensioni dei server front-end.

L'ambito delle metriche usato per monitorare l'infrastruttura della piattaforma è denominato Microsoft.Web/hostingEnvironments/multiRolePools.

Verrà visualizzato un ambito denominato Microsoft.Web/hostingEnvironments/workerPools. Le metriche qui sono applicabili solo a ambiente del servizio app v1.

Registrazione

È possibile integrare A edizione Standard con Monitoraggio di Azure per inviare i log relativi all'A edizione Standard a Archiviazione di Azure, Hub eventi di Azure o Log Analytics. Questi elementi vengono registrati oggi:

Situazione	Message
A edizione Standard non è integro	L'oggetto A edizione Standard specificato non è integro a causa di una configurazione di rete virtuale non valida. L edizione Standard A verrà sospeso se lo stato non integro continua. Assicurarsi che siano seguite le linee guida definite di seguito: Considerazioni sulla rete per un ambiente del servizio app.
A edizione Standard subnet è quasi esaurita	L'oggetto A edizione Standard specificato si trova in una subnet quasi esaurita. {0} Sono presenti indirizzi rimanenti. Una volta esauriti questi indirizzi, l'A edizione Standard non sarà in grado di ridimensionare.
A edizione Standard sta raggiungendo il limite totale di istanze	L'oggetto A edizione Standard specificato sta raggiungendo il limite totale dell'istanza di A edizione Standard. Attualmente contiene {0} servizio app istanze di Piano di un massimo di 201 istanze.
A edizione Standard non è in grado di raggiungere una dipendenza	L'oggetto A edizione Standard specificato non è in grado di raggiungere {0}. Assicurarsi che siano seguite le linee guida definite di seguito: Considerazioni sulla rete per un ambiente del servizio app.
A edizione Standard è sospeso	L'oggetto A edizione Standard specificato viene sospeso. La sospensione A edizione Standard può essere dovuta a una mancanza di account o a una configurazione di rete virtuale non valida. Risolvere la causa radice e riprendere l'A edizione Standard per continuare a gestire il traffico.
A edizione Standard l'aggiornamento è stato avviato	È stato avviato un aggiornamento della piattaforma all'A edizione Standard specificato. Attendere ritardi nelle operazioni di ridimensionamento.
A edizione Standard aggiornamento completato	È stato completato un aggiornamento della piattaforma all edizione Standard specificato.
Le operazioni di scalabilità sono state avviate	È iniziato il ridimensionamento di un piano servizio app ({0}). Stato desiderato: {1} I{2} lavoratori.
Le operazioni di scalabilità sono state completate	Un piano di servizio app ({0}) ha terminato il ridimensionamento. Stato corrente: {1} I{2} lavoratori.
Operazioni di scalabilità non riuscite	Non è stato possibile ridimensionare un piano di servizio app ({0}). Stato corrente: {1} I{2} lavoratori.

Per abilitare la registrazione in A edizione Standard:

1. Nel portale passare a Impostazioni di diagnostica.
2. Selezionare Aggiungi impostazione di diagnostica.
3. Specificare un nome per l'integrazione dei log.
4. Selezionare e configurare le destinazioni di log desiderate.
5. Selezionare AppServiceEnvironmentPlatformLogs.

Se si esegue l'integrazione con Log Analytics, è possibile visualizzare i log selezionando Log dal portale A edizione Standard e creando una query su AppServiceEnvironmentPlatformLogs. I log vengono generati solo quando A edizione Standard ha un evento che lo attiverà. Se l'A edizione Standard non ha un evento di questo tipo, non saranno presenti log. Per visualizzare rapidamente un esempio di log nell'area di lavoro Log Analytics, eseguire un'operazione di scalabilità con uno dei piani di servizio app nel proprio A edizione Standard. È quindi possibile eseguire una query su AppServiceEnvironmentPlatformLogs per visualizzare tali log.

Creazione di un avviso

Per creare un avviso per i log, seguire le istruzioni riportate in Creare, visualizzare e gestire gli avvisi dei log con Monitoraggio di Azure. In breve:

• Aprire la pagina Avvisi nel portale A edizione Standard
• Selezionare Nuova regola di avviso
• Selezionare la risorsa come area di lavoro Log Analytics
• Impostare la condizione con una ricerca log personalizzata per usare una query come "AppServiceEnvironmentPlatformLogs | dove ResultDescription contiene "ha iniziato il ridimensionamento" o qualsiasi cosa desiderata. Impostare la soglia in base alle esigenze.
• Aggiungere o creare un gruppo di azioni in modo desiderato. Il gruppo di azioni è la posizione in cui si definisce la risposta all'avviso, ad esempio l'invio di un messaggio di posta elettronica o un SMS
• Assegnare un nome all'avviso e salvarlo.

Preferenza di aggiornamento

Se sono presenti più edizione Standard A, è possibile che alcuni A edizione Standard vengano aggiornati prima di altri. Questo comportamento può essere abilitato tramite il portale A edizione Standard. In Configurazione è possibile impostare preferenza di aggiornamento. I tre valori possibili sono:

• Nessuno: Azure aggiornerà il file A edizione Standard in nessun batch specifico. Si tratta del valore predefinito.
• Prima: l'A edizione Standard verrà aggiornato nella prima metà degli aggiornamenti servizio app.
• Ritardo: l edizione Standard A verrà aggiornato nella seconda metà degli aggiornamenti servizio app.

Selezionare il valore desiderato e selezionare Salva. Il valore predefinito per qualsiasi A edizione Standard è Nessuno.

La funzionalità upgradePreferences ha più senso quando si dispone di più A edizione Standard perché le edizione Standard "Early" A edizione Standard s verranno aggiornate prima di "Late" A edizione Standard s.The upgradepreferences features most most sense when you have multiple A edizione Standard s because your "Early" A edizione Standard s will be upgraded before your "Late" A edizione Standard s. Quando si dispone di più A edizione Standard s, è necessario impostare le edizione Standard di sviluppo e test A edizione Standard in modo che siano "early" e la produzione A edizione Standard s sia "Late".

Prezzi

Lo SKU dei prezzi denominato Isolated è destinato all'uso solo con A edizione Standard s. Tutti i piani servizio app ospitati in A edizione Standard si trovano nello SKU dei prezzi isolato. I tassi isolati per i piani di servizio app possono variare in base all'area.

Oltre al prezzo dei tuoi piani servizio app, c'è un tasso flat per la A edizione Standard stesso. La tariffa fissa non cambia con le dimensioni del tuo A edizione Standard. Paga l'infrastruttura A edizione Standard a una velocità di scalabilità predefinita di un front-end aggiuntivo per ogni 15 istanze del piano di servizio app.

Se la frequenza di scalabilità predefinita di un front-end per ogni 15 istanze del piano servizio app non è abbastanza veloce, è possibile modificare il rapporto con cui vengono aggiunti i front-end o le dimensioni dei front-end. Quando si modifica il rapporto o le dimensioni, si paga per i core front-end che non verranno aggiunti per impostazione predefinita.

Se ad esempio si imposta la proporzione di ridimensionamento su 10, verrà aggiunto un front-end ogni 10 istanze nei piani di servizio app. La tariffa fissa copre una proporzione di ridimensionamento pari a un front-end ogni 15 istanze. Con una proporzione di ridimensionamento di 10, il costo verrà addebitato al terzo front-end aggiunto per le 10 istanze del piano di servizio app. Non è necessario pagare quando si raggiungono le 15 istanze, perché il front-end è stato aggiunto automaticamente.

Se si regolano le dimensioni dei front-end su due core, ma non si regola il rapporto, si paga per i core aggiuntivi. Un oggetto A edizione Standard viene creato con due front-end, quindi anche al di sotto della soglia di ridimensionamento automatico si paga per due core aggiuntivi se si aumentano le dimensioni a due front-end core.

Per altre informazioni, vedere Prezzi del Servizio app di Azure.

Eliminare un ambiente del servizio app

Per eliminare un ambiente del servizio app:

1. Selezionare Elimina nella parte superiore del riquadro ambiente del servizio app.

2. Immettere il nome dell'ambiente del servizio app per confermare l'eliminazione. Quando si elimina un edizione Standard A, si elimina anche tutto il contenuto all'interno di esso.

   

3. Seleziona OK.

Interfaccia della riga di comando di A edizione Standard

Sono disponibili funzionalità della riga di comando da amministrare a un edizione Standard A. I comandi dell'interfaccia della riga di comando di Azure sono indicati di seguito.

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"