Informazioni sugli ambienti e sui gruppi di ambienti

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 centralizzato per gli 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.

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

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 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.

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	Può contenere più gruppi di ambienti Deve avere almeno un gruppo di ambienti
Ambienti	Deve essere in almeno un gruppo di ambienti Può essere in più di un gruppo Condividere i nomi host con tutti gli altri ambienti nello stesso gruppo Può essere utilizzato per inoltrare il traffico a un URI specificato
Tipi di ambiente	Determinare le funzionalità disponibili in e con quell'ambiente Determina i prezzi per l'ambiente (vedi Tipi di ambiente).
Gruppi di ambienti	Può avere più nomi host Contiene 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 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? 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 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 i nomi host 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.

Nota: i nomi dell'ambiente e del gruppo non influiscono sull'URL dell'endpoint dell'API. Sono pensati solo per organizzare e configurare i tuoi ambienti e non sono esposti agli utenti finali del proxy.

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 elementi.

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 a quel 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

• In prod-group sono definiti i seguenti nomi host:

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

• I seguenti proxy vengono dipartiti in questi ambienti:

  • 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 instrada al proxy catalog nell'ambiente catalog-prod.
• catalog.example.com/catalog/cart instrada al proxy cart nell'ambiente cart-prod.
• payment.example.com/payment instrada al proxy payment nell'ambiente pymnt-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:

Suggerimento:

I nomi host che definisci in un gruppo di ambienti:

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

Per ulteriori informazioni, consulta Aggiungere nomi host a un gruppo.

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 dispone di certificati con caratteri jolly (ad es. *.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 proxy foo viene disegnato 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, 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:

  • Lavorare con gli ambienti
  • Lavorare con i gruppi di ambienti

• Con l'API Apigee:

  • API Environments
  • API Environment Groups
  • API di allegato del gruppo di ambienti