Questa pagina si applica ad Apigee e 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 creare ed eseguire 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 che possono essere di cui può essere eseguito il deployment. Questi limiti variano in base al tipo di organizzazione Apigee (abbonamento, pagamento a consumo o ibrida) che utilizza l'ambiente. Per informazioni più dettagliate, consulta la documentazione relativa ai 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 inoltrate ai singoli ambienti. Definisci i nomi host nei gruppi di ambienti (non nei singoli ambienti) e Apigee inoltra 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 che tu possa accedere ai proxy di cui è composto. 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 degli hostname: i gruppi di ambienti forniscono un unico punto di gestione degli hostname.
- Approfondimenti aggregati: con i gruppi, puoi analizzare gli errori esaminando contemporaneamente i report per un intero gruppo di ambienti anziché per singoli ambienti.
- Evitare conflitti: raggruppando gli ambienti, puoi assicurarti che i percorsi di base per i proxy di cui è stato eseguito il deployment esistano sotto lo 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 nei tuoi ambienti di sviluppo Apigee, quindi esegui il deployment negli ambienti di produzione e di test di integrazione di Apigee. Consulta Eseguire il deployment di un proxy API. |
Archivia | Sviluppare e testare i proxy API programmabili utilizzando Apigee in VS Code. |
Riepilogo delle azioni impedite con il deployment dell'archivio
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 archiviati, come descritto in Eseguire il deployment di un proxy API, né utilizzare l'interfaccia utente di debug come descritto in Utilizzare il debug. Come soluzione alternativa, puoi utilizzare gcloud o l'API per elencare tutti i deployment dell'archivio in un ambiente e utilizzare l'API di 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 account di servizio non è supportata.
Se provi a eseguire una delle azioni bloccate sopra elencate, l'azione non andrà a buon fine e verrà visualizzato il seguente messaggio di errore:
FAILED_PRECONDITION
Unità di deployment del proxy
Le unità di deployment dei proxy conteggiano i proxy e i flussi condivisi di cui è stato eseguito il deployment negli ambienti per regione.
Di seguito sono riportati 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 rientrano nella categoria dei proxy standard.
- Le unità di deployment dei proxy estensibili conteggiano il numero di proxy attualmente di cui è stato eseguito il deployment e che rientrano nella categoria dei 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, ovvero un limite al numero di unità di deployment che puoi utilizzare contemporaneamente. Per informazioni dettagliate, 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 ulteriori informazioni su come visualizzare l'utilizzo delle unità di deployment del proxy e i dettagli della quota dei deployment per la tua organizzazione, consulta Visualizzare l'utilizzo del deployment del proxy.
Tipi di ambiente
Gli utenti con pagamento a consumo devono selezionare il tipo di ambiente quando creano un ambiente: Base, Intermedio o Comprensivo. Le caratteristiche, le funzionalità e i costi associati all'ambiente dipendono dal tipo di ambiente. Per saperne di più, consulta Tipi di ambienti di pagamento a consumo e Diritti di pagamento a consumo.
Per i piani di abbonamento, il tipo di ambiente è sempre Completo 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 sottoposte a verifica per verificare la presenza di eventuali criteri inclusi (consulta Supporto della funzionalità di inoltro tramite proxy) e poi inoltrate tramite HTTP al nuovo URI.
Le modifiche apportate all'impostazione del proxy inoltrante di un ambiente vengono applicate immediatamente solo alle nuove richieste. Le richieste già in fase di elaborazione vengono completate con l'impostazione in vigore al momento della ricezione della richiesta.
Per le istruzioni su come configurare il proxy in avanti, consulta Configurare il proxy in avanti in un ambiente.
Supporto della funzionalità di proxy di inoltro
Non tutte le funzionalità dei proxy disponibili a livello generale hanno la stessa disponibilità o applicabilità con il proxy in avanti.
Al momento Apigee non supporta l'autenticazione di base con il proxy in avanti, tranne che in Apigee Hybrid.
Questa tabella mostra il supporto di funzionalità aggiuntive:
Funzionalità o norme | Supportato/applicabile per il proxy in avanti? |
Endpoint di destinazione | Sì |
Controllo di integrità HTTP | Sì |
Callout di servizio | Sì |
Chiamate HTTP tramite JavaScript | Sì |
Target di integrazione | Sì |
Catena di proxy tramite loopback locali | No |
Pubblicazione di messaggi | No |
Cloud Logging | No |
Comunicazione con il sincronizzatore | No |
Registrazione dei messaggi tramite Syslog | No |
Limitazioni del proxy in avanti
GoogleToken tramite un segmento di pubblico esterno non è attualmente supportato con il proxy in avanti.
Punti chiave
La tabella seguente elenca i punti importanti da ricordare su ambienti, organizzazioni e gruppi di ambienti:
Elemento | Regole |
---|---|
Organizzazioni |
|
Ambienti |
|
Tipi di ambiente |
(vedi Tipi di ambiente). |
Gruppi di ambienti |
|
Esempi
Le sezioni seguenti illustrano i modi 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 è un problema comune per le organizzazioni che stanno attualmente valutando il prodotto o che non hanno ancora configurato l'infrastruttura di test o di analisi e non hanno ancora implementato proxy in produzione.
Più ambienti in un unico gruppo di ambienti
Un gruppo di ambienti può contenere più ambienti. Nell'esempio seguente, c'è un singolo gruppo di ambienti, prod-group, che contiene tre ambienti, cart-prod, catalog-prod e payment-prod.
Il gruppo di ambienti ha un singolo nome host, example.com
. Puoi utilizzare il nome host per inoltrare 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 vengono instradati a un ambiente specifico.
Per scoprire come creare questo gruppo di ambienti, consulta Utilizzo dei gruppi di ambienti.
Limitare l'instradamento a un singolo ambiente
Nell'esempio precedente, le richieste possono essere inoltrate ai proxy in tutti e tre gli ambienti da un singolo nome host. Se vuoi limitare l'accesso ai proxy in un singolo ambiente, ad esempio catalog-prod, crea un altro gruppo di ambienti che contenga solo l'ambiente catalog-prod. In questo modo, un nome host definito per quel gruppo di ambienti potrà accedere solo a catalog-prod.
Nell'esempio seguente, 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?
|
Per scoprire di più sugli ambienti:
|
Per scoprire di più sui gruppi di ambienti:
|
Routing e percorsi base
In una configurazione semplice, una richiesta a un proxy API di cui è stato eseguito il deployment è composta 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
Definisci gli hostname nel gruppo di ambienti in modo che possano essere condivisi da più ambienti. I percorsi base e le risorse API sono definiti nel proxy API.
Per ulteriori informazioni sui percorsi di base e sulle risorse API, consulta Informazioni sui percorsi. Inoltre, consulta la sezione Riferimento per la configurazione dei flussi e la sezione Riferimento per le variabili dei flussi per approfondire l'integrazione di questi componenti.
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, ognuno con i propri nomi host:
Nome gruppo di ambienti (Ambienti) |
prod-group (catalog-prod cart-prod pymnt-prod) |
dev-group (dev-env) |
gruppo-test (test-env) |
---|---|---|---|
Nomi host | catalog.example.com payment.example.com |
dev.example.com | test.example.com |
Definisci i percorsi di base sul proxy quando lo crei.
Quando esegui il deployment di un proxy in un ambiente all'interno del gruppo, il nome host più il percorso di base e il nome della risorsa definiscono insieme l'endpoint di una richiesta API al proxy.
Puoi definire più di un nome host in un gruppo di ambienti. Tutti possono essere utilizzati 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
gli hostname 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
I seguenti proxy vengono dipartiti in questi ambienti:
- Il proxy
catalog
sucatalog-prod
con un percorso di base di/catalog
- Il proxy
cart
sucart-prod
con un percorso di base di/catalog/cart
- Il proxy
payment
supymnt-prod
con un percorso di base di/payment
- Il proxy
Vengono creati i seguenti endpoint:
catalog.example.com/catalog
instrada al proxycatalog
nell'ambientecatalog-prod
.catalog.example.com/catalog/cart
instrada al proxycart
nell'ambientecart-prod
.payment.example.com/payment
instrada al proxypayment
nell'ambientepymnt-prod
.
L'esempio seguente mostra che le richieste vengono inoltrate a diversi proxy di cui è stato eseguito il deployment negli ambienti all'interno del gruppo, corrispondenti a uno qualsiasi dei nomi host e al percorso di base:
Routing ed ambienti 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. Questo è utile se un cliente ha certificati con caratteri jolly (ad esempio *.example.com) per più partner.
Ad esempio:
shared-env
appartiene a due gruppi di ambienti:partner-1
con alias hostapi.partner-1.com
partner-2
con alias hostapi.partner-2.com
- Il proxy
foo
viene disegnato inshared-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, a ogni gruppo di ambienti viene assegnato 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 delle mappe 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 limitate a ambienti o gruppi di ambienti all'interno dell'organizzazione. Ad esempio, i dati di analisi di Apigee sono suddivisi in base a una combinazione di organizzazione, ambiente e (eventualmente) gruppo di ambienti.
Considerazioni
Ogni deployment in un ambiente ha il potenziale di influire sul routing del traffico per ogni gruppo di ambienti a cui è collegato. Quando vengono aggiunti nuovi percorsi base, questi possono iniziare a acquisire traffico completamente nuovo o un sottoinsieme di 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 causare il reindirizzamento del traffico esistente a un proxy diverso. Quando il traffico viene reindirizzato, può essere indirizzato a un proxy nello stesso ambiente o, se più ambienti condividono un unico gruppo di ambienti, a un proxy in un ambiente diverso.
Deve essere preso in considerazione anche il numero totale di percorsi base del proxy API aggiunti a un ambiente o a un gruppo di ambienti. Per un rendimento ottimale, Apigee consiglia di utilizzare non più di 3000 percorsi base dell'proxy API per ambiente Apigee o gruppo di ambienti. Il superamento di questo valore consigliato 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 l'interfaccia utente di Apigee:
-
Con l'API Apigee: