Informazioni sugli ambienti e sui gruppi di ambienti

Questa pagina si applica ad Apigee e ad Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Questa sezione descrive gli ambienti e i gruppi di ambienti.

Panoramica

Un ambiente Apigee è un ambiente software, all'interno di un'organizzazione, per la creazione e il deployment di proxy API. Devi eseguire il deployment di un proxy API in un ambiente prima di potervi accedere. Puoi eseguire il deployment di un proxy API in un singolo ambiente o in più ambienti.

Ogni ambiente è soggetto a limiti sul numero di proxy API, flussi condivisi e altre risorse di cui è possibile eseguire il deployment. Questi limiti variano in base al tipo di organizzazione Apigee (abbonamento, pagamento a consumo o Apigee Hybrid) che utilizza l'ambiente. Per informazioni più dettagliate, consulta la documentazione sui limiti.

Un gruppo di ambienti (a volte chiamato envgroup nell'API Apigee) è il meccanismo di base per definire il modo in cui le richieste vengono indirizzate ai singoli ambienti. I nomi host vengono definiti nei gruppi di ambienti (non nei singoli ambienti) e Apigee instrada le richieste agli ambienti all'interno di un gruppo utilizzando queste definizioni di nomi host.

Un ambiente deve essere membro di almeno un gruppo di ambienti prima di poter accedere ai proxy di cui è stato eseguito il deployment al suo interno. In altre parole, devi assegnare un ambiente a un gruppo prima di poterlo utilizzare.

Il raggruppamento logico degli ambienti per gruppo di ambienti offre i seguenti vantaggi:

• Gestione centralizzata dei nomi host: i gruppi di ambienti forniscono una posizione centralizzata per la gestione dei nomi host.
• Insight aggregati: con i gruppi, puoi analizzare gli errori esaminando i report per un intero gruppo di ambienti contemporaneamente anziché per i singoli ambienti.
• Evitare i conflitti: raggruppando gli ambienti, puoi assicurarti che i percorsi di base dei proxy di cui hai eseguito il deployment esistano nello stesso nome host.

Tipi di deployment supportati

Apigee supporta i seguenti tipi di deployment in un ambiente:

Tipo	Descrizione
Proxy	Sviluppa e testa i proxy API negli ambienti di sviluppo Apigee, quindi eseguine il deployment negli ambienti di test e produzione di Apigee Integration. Vedi Distribuzione di un proxy API.
Archivia	Sviluppa e testa i tuoi proxy API programmabili utilizzando Apigee in VS Code.

Riepilogo delle azioni impedite con il deployment di Archive

Quando attivi il deployment dell'archivio in un ambiente Apigee, non potrai eseguire le seguenti azioni all'interno dell'ambiente per evitare conflitti:

• Nell'interfaccia utente di Apigee, non puoi visualizzare, confermare lo stato del deployment o gestire i deployment di archivio, come descritto in Eseguire il deployment di un proxy API, o utilizzare l'interfaccia utente di Debug come descritto in Utilizzo di Debug. Come soluzione alternativa, puoi utilizzare gcloud o l'API per elencare tutti i deployment di archivi in un ambiente e utilizzare l'API Debug.
• Non puoi creare, aggiornare o eliminare file di risorse o server di destinazione utilizzando l'interfaccia utente, l'API o gcloud di Apigee.
• Al momento, l'autenticazione Google tramite service account non è supportata.

Nota: puoi gestire le mappe di coppie chiave-valore (KVM) e i keystore TLS in un ambiente Apigee abilitato per il deployment dell'archivio.

Se tenti di eseguire una delle azioni impedite elencate sopra, l'azione non andrà a buon fine e verrà visualizzato il seguente messaggio di errore:

FAILED_PRECONDITION

Unità di deployment dei proxy

Le unità di deployment dei proxy (PDU) misurano il consumo della capacità di Apigee in base al deployment dei proxy API e dei flussi condivisi nell'infrastruttura.

Un'unità di deployment del proxy è definita come un deployment di revisione del proxy API o del flusso condiviso per ambiente per istanza (regione). Poiché Apigee scala con la tua infrastruttura, un singolo deployment di proxy può essere conteggiato come più unità se viene eseguito in un ambiente che si estende su più istanze.

Calcolo delle PDU

Le PDU totali vengono calcolate sommando le unità di deployment in tutti gli ambienti della tua organizzazione. Per ogni ambiente, il contributo della PDU è il numero di revisioni di cui è stato eseguito il deployment moltiplicato per il numero di istanze (regioni) a cui è collegato l'ambiente.

In Apigee Hybrid, ogni cluster Kubernetes in cui configuri un ambiente viene conteggiato come un'istanza (regione) nel calcolo delle PDU.

La formula generale per le PDU totali è:

Total PDUs = Σ (Deployed Revisions in Envn × Instances for Envn)

Dove la somma è su tutti gli ambienti (Env_n) in cui è stato eseguito il deployment del proxy o del flusso condiviso.

Se il deployment di un proxy o di un flusso condiviso viene eseguito in ambienti collegati allo stesso numero di istanze, è possibile utilizzare una formula semplificata:

PDUs = (Deployed Revisions) × (Environments) × (Instances)

Esempi

La tabella seguente fornisce esempi di come vengono calcolate le PDU in diversi scenari di infrastruttura:

Scenario	Proxy	Ambienti	Istanze (regioni)	PDU totali
Regione singola Deployment su piccola scala	1	1	1	1
Alta affidabilità multiregionale Stesso proxy in due regioni	1	1 (collegato a 2 istanze)	2	2
Multi-ambiente Stesso proxy in Dev e Test	1	2 (Dev, Test)	1	2
Enterprise Scale Deployment globale in più ambienti (si presuppone che gli ambienti di produzione e gestione temporanea siano collegati a tutte e tre le istanze)	5	2 (Prod, Staging)	3 (Stati Uniti, UE, Asia)	30

Tipi di unità di deployment dei proxy

Le unità di deployment dei proxy conteggiano i proxy e i flussi condivisi di cui è stato eseguito il deployment negli ambienti per regione.

Questi sono i tipi di unità di deployment:

• Le unità di deployment dei proxy standard conteggiano il numero di proxy attualmente di cui è stato eseguito il deployment che si qualificano come proxy standard.
• Le unità di deployment dei proxy estensibili conteggiano il numero di proxy attualmente di cui è stato eseguito il deployment che si qualificano come proxy estensibili.
• Le unità di deployment dei flussi condivisi conteggiano il numero di flussi condivisi di cui è stato eseguito il deployment.

Il tuo utilizzo potrebbe essere soggetto alla quota di deployment, che è un limite al numero di unità di deployment che puoi utilizzare contemporaneamente. Per maggiori dettagli, consulta i tuoi diritti (Pay-as-you-go o Abbonamento 2024). Per informazioni sui limiti di sistema, consulta Unità di deployment proxy massime per istanza.

Per saperne di più sulla visualizzazione dei dettagli sull'utilizzo delle unità di deployment dei proxy e sulla quota di deployment per la tua organizzazione, consulta Visualizza l'utilizzo del deployment dei proxy.

Tipi di ambiente

Per gli utenti con pagamento a consumo, quando crei un ambiente, selezioni il tipo di ambiente: Base, Intermedio o Completo. Le caratteristiche, le funzionalità e i costi associati all'ambiente dipendono dal tipo di ambiente. Per saperne di più, consulta Tipi di ambiente con pagamento a consumo e Diritti di pagamento a consumo.

Per i piani di abbonamento Apigee, il tipo di ambiente è sempre Apigee Comprehensive e non è necessario conoscere i tipi di ambiente.

Proxy di inoltro

Apigee supporta l'inoltro del traffico a un URI specificato. Questa funzionalità si applica a livello di ambiente e può essere utilizzata per indirizzare il traffico a internet dopo l'elaborazione iniziale in un proxy.

Le richieste in entrata ai proxy nell'ambiente configurato vengono elaborate per tutte le policy incluse (consulta Supporto della funzionalità di proxy di forwarding) e poi inoltrate utilizzando HTTP al nuovo URI.

Le modifiche apportate all'impostazione del proxy di inoltro di un ambiente diventano effettive immediatamente solo per le nuove richieste. Le richieste già in fase di elaborazione vengono completate con l'impostazione attiva al momento della ricezione della richiesta.

Per istruzioni sulla configurazione del proxy di inoltro, consulta Configura il proxy di inoltro in un ambiente.

Supporto della funzionalità di proxying di forwarding

Non tutte le funzionalità proxy in disponibilità generale hanno la stessa disponibilità o applicabilità con il proxy di forwarding.

Al momento Apigee non supporta l'autenticazione di base con il proxy di forwarding, ad eccezione di Apigee Hybrid.

Questa tabella mostra il supporto per funzionalità aggiuntive:

Funzionalità o norma	Supportato/applicabile per il proxy di inoltro?
Endpoint di destinazione	Sì
Controllo di integrità HTTP	Sì
Callout di servizio	Sì
Chiamate HTTP tramite JavaScript	Sì
Destinazioni di integrazione	Sì
Concatenamento di proxy tramite loopback locali	No
Pubblicazione di messaggi	No
Cloud Logging	No
Comunicazione con Synchronizer	No
Logging dei messaggi tramite Syslog	No

Limitazioni del proxy di inoltro

GoogleToken tramite un pubblico esterno non è attualmente supportato con il proxy di forwarding.

Punti chiave

La tabella seguente elenca i punti importanti da ricordare su ambienti, organizzazioni e gruppi di ambienti:

Elemento	Regole
Organizzazioni	Può contenere più gruppi di ambienti Deve contenere almeno un gruppo di ambienti
Ambienti	Deve appartenere ad almeno un gruppo di ambienti Può essere incluso in più gruppi Condividi i nomi host con tutti gli altri ambienti dello stesso gruppo Può essere utilizzato per inoltrare il traffico a un URI specificato
Tipi di ambiente	Determinare la funzionalità disponibile in e con quell'ambiente Determina i prezzi per l'ambiente (Consulta la sezione Tipi di ambiente.)
Gruppi di ambienti	Può avere più nomi host Contengono uno o più ambienti I nomi host assegnati a un gruppo devono essere univoci per quel gruppo (non possono essere utilizzati da altri gruppi)

Utenti di Apigee Hybrid: ogni gruppo di ambienti che crei con un ambiente collegato deve essere incluso in tutti i file di override in cui viene utilizzato l'ambiente.

Esempi

Le sezioni seguenti mostrano i modi più comuni in cui gli ambienti sono strutturati all'interno dei gruppi di ambienti.

Un gruppo di ambienti e un ambiente

La struttura più semplice è un singolo gruppo di ambienti con un singolo ambiente al suo interno. Questo è comune per le organizzazioni che stanno attualmente valutando il prodotto o non hanno ancora configurato l'infrastruttura di test o analisi, né hanno proxy di cui è stato eseguito il deployment in produzione.

Più ambienti in un unico gruppo di ambienti

Un gruppo di ambienti può contenere più ambienti. Ad esempio, un singolo gruppo di ambienti, prod-group, può contenere tre ambienti, cart-prod, catalog-prod e payment-prod.

Il gruppo di ambienti ha un unico nome host, example.com. Puoi utilizzare il nome host per instradare le richieste a un proxy di cui è stato eseguito il deployment in uno degli ambienti. Tieni presente che i nomi host sono definiti a livello di gruppo di ambienti: non eseguono il routing a un ambiente specifico.

Per scoprire come creare questo gruppo di ambienti, consulta Utilizzo dei gruppi di ambienti.

Limitazione del routing a un singolo ambiente

Nell'esempio precedente, le richieste possono essere indirizzate ai proxy in tutti e tre gli ambienti da un unico nome host. Se vuoi limitare l'accesso ai proxy in un singolo ambiente, ad esempio catalog-prod, crea un altro gruppo di ambienti contenente solo l'ambiente catalog-prod. In questo modo, un nome host definito per quel gruppo di ambienti può accedere solo a catalog-prod.

Ad esempio, il nome host catalog.example.com, per il gruppo di ambienti catalog-prod-group, può instradare le richieste solo ai proxy nell'ambiente catalog-prod.

Vuoi creare un gruppo? Apri la console

Per scoprire di più sugli ambienti: Continua a leggere

Per scoprire di più sui gruppi di ambienti: Continua a leggere

Routing e percorsi di base

In una configurazione semplice, una richiesta a un proxy API di cui è stato eseguito il deployment è costituita da un nome host, un percorso di base e il nome di una risorsa API, ad esempio:

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

I nomi host vengono definiti nel gruppo di ambienti in modo che più ambienti possano condividerli. I percorsi di base e le risorse API sono definiti nel proxy API.

Nota: L'ambiente e i nomi dei gruppi non influiscono sull'URL dell'endpoint API. Servono solo per organizzare e configurare gli ambienti e non vengono esposti agli utenti finali del proxy.

Per ulteriori informazioni sui percorsi di base e sulle risorse API, consulta Informazioni sulle route. Inoltre, consulta il Riferimento per la configurazione dei flussi e il Riferimento per le variabili di flusso per comprendere meglio come questi elementi si integrano tra loro.

Nomi host

Quando crei un gruppo di ambienti, colleghi uno o più nomi host al gruppo. Ad esempio, potresti avere i seguenti gruppi di ambienti, ciascuno con i propri nomi host:

Nome gruppo di ambienti (Ambienti)	prod-group (catalog-prod cart-prod pymnt-prod)	dev-group (dev-env)	test-group (test-env)
Nomi host	catalog.example.com payment.example.com	dev.example.com	test.example.com

I percorsi di base vengono definiti sul proxy quando lo crei.

Quando esegui il deployment di un proxy in un ambiente all'interno del gruppo, il nome host, il percorso di base e il nome della risorsa definiscono insieme l'endpoint di una richiesta API a quel proxy.

Puoi definire più di un nome host in un gruppo di ambienti. Possono essere utilizzati tutti per chiamare qualsiasi proxy di cui è stato eseguito il deployment in qualsiasi ambiente del gruppo. Ad esempio, catalog.example.com/proxy1 e payment.example.com/proxy1 chiameranno entrambi la risorsa proxy1 se i nomi host catalog.example.com e payment.example.com sono definiti nello stesso gruppo di ambienti.

Esempio di routing

Ad esempio:

• Il gruppo di ambienti prod-group contiene i seguenti ambienti:

  • catalog-prod
  • cart-prod
  • pymnt-prod

• prod-group ha i seguenti nomi host definiti:

  • catalog.example.com
  • payment.example.com

• In questi ambienti è stato eseguito il deployment dei seguenti proxy:

  • Il proxy catalog su catalog-prod con un percorso di base di /catalog
  • Il proxy cart su cart-prod con un percorso di base di /catalog/cart
  • Il proxy payment su pymnt-prod con un percorso di base di /payment

Vengono creati i seguenti endpoint:

• catalog.example.com/catalog indirizza al proxy catalog nell'ambiente catalog-prod.
• catalog.example.com/catalog/cart indirizza al proxy cart nell'ambiente cart-prod.
• payment.example.com/payment indirizza al proxy payment nell'ambiente pymnt-prod.

L'esempio seguente mostra che le richieste vengono indirizzate a proxy diversi di cui è stato eseguito il deployment negli ambienti all'interno del gruppo, corrispondenti a uno qualsiasi dei nomi host e al percorso di base:

Suggerimento:

I nomi host definiti in un gruppo di ambienti:

• Deve essere univoco in tutti i gruppi di ambiente di un'organizzazione; non può essere utilizzato da più di un gruppo
• Non supportano i caratteri jolly
• I percorsi di base devono essere univoci all'interno di un gruppo di ambienti (due proxy non possono avere lo stesso percorso di base all'interno di un gruppo di ambienti)

Per saperne di più, consulta Aggiunta di nomi host a un gruppo.

Ambienti e routing condivisi

Un ambiente può appartenere a più gruppi di ambienti. Se esegui il deployment di un proxy in un ambiente di questo tipo, il proxy avrà più indirizzi, uno per ogni gruppo di ambienti a cui appartiene l'ambiente. Questa opzione è utile se un cliente dispone di certificati con carattere jolly (ad esempio *.example.com) per più partner.

Ad esempio:

• shared-env appartiene a due gruppi di ambienti:
  • partner-1 con alias host api.partner-1.com
  • partner-2 con alias host api.partner-2.com
• Il deployment del proxy foo viene eseguito in shared-env con un percorso di base /foo. Poiché shared-env è condiviso da entrambi i gruppi di ambienti, foo ha due indirizzi:
  • api.partner-1.com/foo
  • api.partner-2.com/foo

Tieni presente che entrambi i nomi host indirizzano allo stesso ambiente. In questo modo, ogni gruppo di ambienti ha un nome di dominio univoco. Per Apigee Hybrid, questo scenario può utilizzare mTLS con un certificato diverso per ogni partner.

Informazioni sull'ambito dell'ambiente

L'organizzazione fornisce l'ambito per alcune funzionalità di Apigee. Ad esempio, i dati della mappa chiave-valore (KVM) possono essere resi disponibili a livello di organizzazione, il che significa che i proxy API di cui è stato eseguito il deployment in qualsiasi ambiente all'interno dell'organizzazione possono accedere agli stessi dati KVM.

Analogamente, alcune funzionalità possono essere applicate ad ambienti o gruppi di ambienti all'interno dell'organizzazione. Ad esempio, i dati di analisi di Apigee sono partizionati in base a una combinazione di organizzazione, ambiente e (infine) gruppo di ambienti.

Considerazioni

Ogni deployment in un ambiente può influire sul routing del traffico per ogni gruppo di ambienti a cui è collegato l'ambiente. Quando vengono aggiunti nuovi percorsi di base, questi possono iniziare ad acquisire traffico completamente nuovo o un sottoinsieme del traffico esistente già gestito da un deployment esistente.

Analogamente, quando i percorsi di base vengono rimossi, potrebbero corrispondere a endpoint che non ricevono più traffico o potrebbero causare il reindirizzamento del traffico esistente a un proxy diverso. Quando il traffico viene reindirizzato, potrebbe essere indirizzato a un proxy nello stesso ambiente o, se più ambienti condividono un singolo gruppo di ambienti, a un proxy in un ambiente diverso.

Deve essere considerato anche il numero totale di percorsi di base dei proxy API aggiunti a un ambiente o a un gruppo di ambienti. Per prestazioni ottimali, Apigee consiglia di utilizzare non più di 3000 percorsi di base dei proxy API per ambiente o gruppo di ambienti Apigee. Il superamento di questo limite può comportare un aumento della latenza per tutti i deployment di proxy API nuovi ed esistenti.

Risorse aggiuntive

Le seguenti informazioni descrivono come gestire gli ambienti e i gruppi di ambienti:

• Con la UI di Apigee:

  • Utilizzo degli ambienti
  • Utilizzo dei gruppi di ambienti

• Con l'API Apigee:

  • API Environments
  • API Groups
  • API Environment group attachment