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 la creazione e il deployment di proxy API. Prima di poter accedere a un proxy API, devi eseguirne il deployment in un ambiente. Puoi eseguire il deployment di un proxy API in un singolo ambiente o in più ambienti.

Ogni ambiente è soggetto a limiti al numero di proxy API, flussi condivisi e altre risorse che possono essere sottoposti a deployment. Questi limiti variano in base al tipo di organizzazione Apigee (in abbonamento, pay-as-you-go 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 indirizzate ai singoli ambienti. Definisci i nomi host 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 gestire i nomi host.
  • Approfondimenti aggregati: con i gruppi, puoi analizzare gli errori esaminando i report per un intero gruppo di ambienti contemporaneamente 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 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 esegui il deployment negli ambienti di test di integrazione e produzione di Apigee. Consulta Deployment 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 dell'archivio

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

  • Nella UI di Apigee non puoi visualizzare, confermare lo stato del deployment o gestire i deployment degli archivi, come descritto in Deployment di un proxy API, né utilizzare la UI di debug come descritto in Utilizzo di Debug. Come soluzione alternativa, puoi utilizzare gcloud o l'API per elencare tutti i deployment di archiviazione in un ambiente e utilizzare l'API Debug.
  • Non puoi creare, aggiornare o eliminare file di risorse o server di destinazione utilizzando la UI, l'API o gcloud di Apigee.
  • Al momento, l'autenticazione Google tramite service account non è supportata.

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

Questi sono i tipi di unità di deployment:

  • Le unità di deployment proxy standard conteggiano il numero di proxy attualmente sottoposti a deployment che sono considerati proxy standard.
  • Unità di deployment proxy estensibili conteggia il numero di proxy attualmente sottoposti a deployment che sono considerati proxy estensibili.
  • Le unità di deployment del flusso condiviso 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 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 ulteriori informazioni sulla visualizzazione dell'utilizzo delle unità di deployment proxy e dei dettagli della quota di deployment per la tua organizzazione, vedi Visualizzare l'utilizzo del deployment proxy.

Tipi di ambiente

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

Per i piani in abbonamento, il tipo di ambiente è sempre completo e non devi conoscere i tipi di ambiente.

Proxy di inoltro

Apigee supporta l'inoltro del traffico a un URI specificato. Questa funzionalità viene applicata 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 norme incluse (vedi Supporto della funzionalità di proxy di inoltro) e poi inoltrate tramite HTTP al nuovo URI.

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

Per istruzioni sulla configurazione del proxy di inoltro, vedi Configurare il proxy di inoltro in un ambiente.

Supporto della funzionalità di proxy di inoltro

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

Al momento Apigee non supporta l'autenticazione di base con proxy di inoltro, tranne in Apigee Hybrid.

Questa tabella mostra il supporto per funzionalità aggiuntive:

Funzionalità o norma 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ì
Concatenazione 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 di inoltro

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

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 appartenere ad almeno un gruppo di ambienti
  • Può appartenere a più di un gruppo
  • Condividere 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 le funzionalità disponibili in e con quell'ambiente
  • Determinare il prezzo per l'ambiente

(vedi Tipi di ambiente).
Gruppi di ambienti
  • Può avere più nomi host
  • Contenere uno o più ambienti
  • I nomi host assegnati a un gruppo devono essere univoci per quel gruppo (non possono essere utilizzati da altri gruppi)

Esempi

Le sezioni seguenti mostrano 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. Questo è comune per le organizzazioni che stanno attualmente valutando il prodotto o che non hanno ancora configurato l'infrastruttura di test o di analisi, né hanno proxy implementati 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 singolo nome host, example.com. Puoi utilizzare il nome host per indirizzare le richieste a un proxy di cui è stato eseguito il deployment in uno qualsiasi degli ambienti. Tieni presente che i nomi host sono definiti a livello di gruppo di ambienti: non vengono indirizzati a un ambiente specifico.

Consulta la sezione Utilizzo dei gruppi di ambienti per scoprire come creare questo gruppo di ambienti.

Limitare il routing a un singolo ambiente

Nell'esempio precedente, le richieste possono essere indirizzate 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 può accedere solo a catalog-prod.

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

 

Pronto a 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 è 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

Definisci i nomi host nel gruppo di ambienti in modo che possano essere condivisi da più ambienti. I percorsi di base e le risorse API sono definiti nel proxy API.

Per saperne di più sui percorsi di base e sulle risorse API, inizia con Informazioni sulle route. Inoltre, consulta il riferimento alla configurazione del flusso e il riferimento alle variabili di flusso per comprendere meglio come si combinano questi elementi.

Nomi host

Quando crei un gruppo di ambienti, colleghi uno o più nomi host a quel 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)		 test-group

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

  • I seguenti proxy vengono implementati 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 route al proxy catalog nell'ambiente catalog-prod.
  • catalog.example.com/catalog/cart route al proxy cart nell'ambiente cart-prod.
  • payment.example.com/payment route al proxy payment nell'ambiente pymnt-prod.

L'esempio seguente mostra che le richieste vengono indirizzate a proxy diversi distribuiti agli ambienti all'interno del gruppo, corrispondenti a uno qualsiasi dei nomi host e al percorso di base:

Le richieste API vengono indirizzate a diversi ambienti all'interno del gruppo in base al nome host e al percorso di base

Ambienti condivisi e routing

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. Ciò è 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 l'alias host api.partner-1.com
    • partner-2 con l'alias host api.partner-2.com
  • Il proxy foo viene eseguito il deployment su 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 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.

Allo stesso modo, alcune funzionalità possono essere limitate a 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 (alla fine) 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 l'ambiente. Quando vengono aggiunti nuovi percorsi di base, questi potrebbero iniziare ad acquisire traffico completamente nuovo oppure un sottoinsieme del traffico esistente già gestito da un deployment esistente.

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

Va preso in considerazione anche il numero totale di basepath 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 basepath proxy API per ambiente Apigee o gruppo di ambienti. Il superamento di questo suggerimento 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: