Risoluzione degli errori di capacità dell'ambiente in App contenitore di Azure

Quando crei un nuovo ambiente App contenitore di Azure, il provisioning può fallire con un errore di capacità. Il messaggio di errore include un link a questo articolo. Questo articolo spiega perché si verifica l'errore, cosa puoi provare immediatamente e come pianificare le implementazioni per ridurre l'impatto dei vincoli di capacità.

Perché si verifica l'errore

L'errore indica che la regione selezionata ha una capacità limitata per l'infrastruttura gestita necessaria a creare il tuo ambiente. La domanda può superare la capacità disponibile anche in una regione che supporta le Container App.

Note

Capacità e quota sono diverse. La quota limita quante risorse puoi utilizzare; la capacità determina se il servizio può allocare quelle risorse al momento della richiesta. Un aumento della quota non risolve i vincoli di capacità regionali. Se invece la distribuzione segnala un limite di quota, vedi Quote per App contenitore di Azure.

Recuperare da un tentativo di provisioning non riuscito

  1. Conferma l'errore. Rivedi i dettagli dell'errore del deployment non riuscito. Se il messaggio fa riferimento a questo articolo, segui questi passaggi. Registra la regione di destinazione e il messaggio di errore completo. Questa guida si applica agli errori di capacità di provisioning dell'ambiente, non agli errori di avvio dell'applicazione o pull dell'immagine.

  2. Prova un'altra regione supportata. Se le tue esigenze lo permettono, crea l'ambiente in un'altra regione. Verifica che la regione supporti le funzionalità e i profili di carico di lavoro necessari per le Container Apps, che tu abbia una quota sufficiente in quella regione e che i requisiti di networking, dipendenze e residenza dei dati possano essere soddisfatti. Vedi aree geografiche supportate. Per un carico di lavoro esistente, vedi Spostare App contenitore di Azure in un'altra area geografica.

  3. Riprova più tardi se devi usare la stessa regione. La capacità disponibile può variare nel tempo, quindi un tentativo successivo potrebbe avere successo. Aspetta che il tentativo di provisioning attuale finisca prima di riprovare. Per le distribuzioni automatiche, utilizzare un criterio di ripetizione con un numero massimo di tentativi e ritardi crescenti invece di tentativi continui e rapidi. Non c'è un intervallo di ritentativo garantito o un tempo entro cui la capacità diventa disponibile.

Pianificare le distribuzioni per la flessibilità in termini di capacità

Usa le seguenti pratiche per darti più opzioni di deployment. Nessuno di questi garantisce che una richiesta di provisioning abbia successo.

Usare più aree

Identifica almeno due regioni che possono ospitare il tuo carico di lavoro. Quando le tue esigenze lo permettono, pianifica tre o più regioni per darti più alternative se una regione è limitata. Valida la disponibilità delle funzionalità, la quota, la latenza, la localizzazione dei dati e i servizi dipendenti in ogni regione candidata prima di dover distribuire.

Per la ridondanza regionale, distribuire ambienti e applicazioni separate in più regioni, configurare l'instradamento del traffico e il failover, e pianificare la replica dei dati per dipendenze con stato. Avere solo una lista di regioni alternative non garantisce il failover. Vedi le soluzioni multiregione personalizzate per la resilienza.

Fornitura in anticipo rispetto ai tempi previsti

Crea e convalida i tuoi ambienti prima di un lancio, una migrazione o un altro evento sensibile al tempo. Prevedete del tempo per riprovare o usare una regione alternativa invece di rendere la creazione dell'ambiente una dipendenza da gestire all'ultimo minuto.

Creare un ambiente presto non riserva capacità per una scalabilità futura. Tieni conto del costo delle risorse che implementi e delle politiche del ciclo di vita dell'ambiente, specialmente se un ambiente rimane inattivo. Vedi Billing in App contenitore di Azure.

Prova a fare provisioning fuori dall'orario lavorativo

Se il tuo orario lo permette, prova a eseguire il provisioning fuori dal normale orario lavorativo per la regione target. Ad esempio, prova una finestra tra le 3:00 e le 5:00 nel fuso orario locale della regione target.

Considera questa finestra come un'opzione da valutare, non come un periodo garantito di capacità disponibile. Azure soddisfa la domanda globale e i vincoli di capacità possono persistere anche fuori dagli orari di lavoro locali.

Valuta i requisiti di ridondanza di zona

Gli ambienti ridondanti a zona distribuiscono l'infrastruttura su più zone di disponibilità all'interno di una regione. Questo requisito limita la flessibilità del posizionamento rispetto a un ambiente che non richiede ridondanza di zona.

Se le tue esigenze di disponibilità lo permettono, valuta di creare un nuovo ambiente senza ridondanza di zona e integrarlo con implementazioni in altre regioni. Questa opzione potrebbe offrire maggiore flessibilità nel provisioning, ma non garantisce la capacità disponibile.

Importante

La ridondanza di zona e quella regionale proteggono contro diversi guasti. Un dispiegamento multiregione non è un sostituto equivalente della ridondanza di zona all'interno di ogni regione. Non rimuovere la protezione di zona necessaria solo per aggirare un errore di provisioning. Rivedi l'affidabilità in App contenitore di Azure prima di cambiare il tuo design.

Scegli la ridondanza delle zone quando crei l'ambiente. Non puoi abilitarlo o disabilitarlo su un ambiente esistente; un'impostazione diversa richiede un nuovo ambiente e la ridistribuzione delle tue app. Vedi Creare un'app container ridondante a zona.

Quando contattare il supporto

Se il provisioning rimane bloccato dopo aver provato le opzioni applicabili, o se i requisiti impediscono di usare un'altra regione o una configurazione di ridondanza diversa, crea una richiesta di supporto di Azure per Container Apps.

Includere l'ID sottoscrizione, il gruppo di risorse, il nome dell'ambiente o l'ID della risorsa, l'area di destinazione, l'impostazione della ridondanza della zona, il messaggio di errore completo, i timestamp dei tentativi non riusciti in UTC e gli ID di correlazione o di operazione, se disponibili. Descrivi i tentativi e le regioni alternative che hai provato, insieme a eventuali scadenze di dispiegamento o requisiti regionali.

Una richiesta di supporto può aiutare a indagare sul guasto, ma non garantisce un'allocazione immediata della capacità. Richiedere un aumento della quota solo se l'errore segnalato identifica anche un limite della quota.