Informazioni sugli ambienti e sui gruppi di ambienti

Stai visualizzando la documentazione di Apigee X.
Visualizza la documentazione di Apigee Edge.

Questa sezione descrive gli ambienti e i gruppi di ambienti.

Panoramica

Un ambiente è un contesto di esecuzione di runtime per i proxy API e i flussi condivisi di un'organizzazione. Devi eseguire il deployment di un proxy API in un ambiente prima di accedervi. Puoi eseguire il deployment di un proxy API in un singolo ambiente o in più ambienti.

Ogni ambiente è limitato a 60 deployment totali, al massimo 50 dei quali possono essere deployment proxy tramite proxy e flussi condivisi.

Un gruppo di ambienti (a volte chiamato envgroup nell'API Apigee) è il meccanismo di base per definire il modo in cui le richieste vengono instradate ai singoli ambienti. Puoi definire i nomi host nei tuoi gruppi di ambienti (non nei singoli ambienti) e Apigee indirizza le richieste agli ambienti all'interno di un gruppo utilizzando tali definizioni.

Per poter accedere alle risorse definite al suo interno, un ambiente deve essere membro di almeno un gruppo di ambienti. In altre parole, devi assegnare un ambiente a un gruppo prima di poterlo utilizzare.

Il raggruppamento logico degli ambienti in base al gruppo di ambienti offre i seguenti vantaggi:

• Gestione centralizzata dei nomi host: i gruppi di ambienti forniscono un luogo centralizzato per la gestione dei nomi host.
• Informazioni aggregate: con i gruppi, puoi analizzare gli errori esaminando i report per un intero gruppo di ambienti contemporaneamente anziché per singoli ambienti.
• Evitare il conflitto: raggruppando gli ambienti, puoi assicurarti che i percorsi di base per i tuoi ambienti non esistano nello stesso nome host.

Tipi di deployment supportati

In un ambiente, Apigee supporta i seguenti tipi di deployment:

Tipo	Descrizione
Proxy	Sviluppa e sottoponi a test i tuoi proxy API nei tuoi ambienti di sviluppo Apigee, quindi eseguine il deployment negli ambienti di test e produzione dell'integrazione Apigee. Vedi Deployment di un proxy API.
Archive	Sviluppa e testa manualmente i proxy API programmabili con Apigee in VS Code o i proxy API configurabili. Quindi, esegui il deployment di un archivio del tuo ambiente di configurazione proxy API nel tuo ambiente di test di integrazione e produzione Apigee. Vedi Deployment e gestione degli archivi in un ambiente Apigee.

Riepilogo delle azioni bloccate con il deployment degli archivi

Quando abiliti il deployment di archivio in un ambiente Apigee, non puoi eseguire le seguenti azioni nell'ambiente per evitare conflitti:

• Nell'interfaccia utente di Apigee non puoi visualizzare, confermare lo stato del deployment o gestire i tuoi deployment di archivio, come descritto per Eseguire il deployment di un proxy API, né utilizzare l'interfaccia utente di debug come descritto in Utilizzare debug. Come soluzione alternativa, puoi utilizzare gcloud o l'API per elencare tutti i deployment di archivio in un ambiente e utilizzare l'API Debug.
• Non è possibile 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 mappature delle coppie chiave-valore (KVM) e gli archivi chiavi TLS in un ambiente Apigee abilitato per il deployment degli archivi.

Se provi a eseguire una qualsiasi delle azioni vietate elencate in precedenza, l'azione non riuscirà e verrà visualizzato il seguente messaggio di errore:

FAILED_PRECONDITION

Punti chiave

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

Elemento	Regole
Organizzazioni	Può contenere più gruppi di ambienti Deve avere almeno un gruppo di ambiente
Ambienti	Deve essere incluso in almeno un gruppo di ambienti Possono essere presenti in più gruppi Condividere i nomi host con tutti gli altri ambienti nello stesso gruppo
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 ibridi di Apigee: ogni gruppo di ambienti creato con un ambiente associato deve essere incluso in tutti i file di override in cui viene utilizzato l'ambiente.

Esempi

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

Un gruppo di ambienti e un ambiente

La struttura più semplice è un gruppo di ambienti con un unico ambiente. Ciò è comune per le organizzazioni che attualmente stanno valutando il prodotto o non hanno ancora configurato un'infrastruttura di test o di analisi né hanno proxy in produzione.

Più ambienti in un singolo gruppo

Un'organizzazione può contenere più gruppi di ambienti. Ad esempio, puoi definire i gruppi di ambienti dev, test e prod in un'organizzazione, mappandoli ciascuno a un singolo nome host (o indirizzo IP). All'interno di ogni gruppo potrebbero esistere uno o più ambienti:

Gruppi di ambienti allineati con l'accesso

Poiché puoi assegnare lo stesso ambiente a più gruppi, puoi organizzare gli ambienti in base all'accesso. Ad esempio, puoi rendere accessibili i tuoi ambienti di produzione in un singolo gruppo di ambienti interni, ma limitare l'accesso ad alcuni di questi ambienti su un gruppo pubblico, che sarebbe aperto a Internet:

Gruppi di ambienti allineati con unità aziendali

Con un insieme più ampio e più maturo di proxy di cui è stato eseguito il deployment attivo, è comune allineare i gruppi di ambienti con le unità aziendali. Ad esempio, potresti avere gruppi di ambienti per i tuoi team di test, produzione e sviluppo:

Vuoi creare un gruppo? Apri la console

Scopri di più sugli ambienti: Continua a leggere

Per ulteriori informazioni 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

Puoi definire 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 sul proxy API.

Nota: i nomi degli ambienti e dei gruppi non influiscono sull'URL dell'endpoint API. Queste servono solo per organizzare e configurare i tuoi ambienti e non sono esposti agli utenti finali del proxy.

Per saperne di più sui percorsi di base e sulle risorse API, inizia con la sezione Informazioni sui percorsi. Inoltre, consulta i riferimenti per la configurazione del flusso e il riferimento per le variabili di flusso per comprendere meglio come questi componenti si integrano.

Nomi host

Quando crei un gruppo di ambiente, colleghi uno o più nomi host a tale 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-itv)	test-group (test-it)
Nomi host	catalog.example.com payment.example.com	dev.example.com	test.example.com

Puoi definire 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, il percorso di base e il nome della risorsa definiscono insieme l'endpoint di una richiesta API al proxy.

Puoi definire più nomi host per gruppo di ambiente. 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 chiamano entrambi la risorsa proxy1 se i nomi host catalog.example.com e payment.example.com sono definiti nello stesso gruppo di ambienti.

Per supportare più nomi host su un singolo gruppo di ambiente condiviso da più ambienti, Apigee instrada le richieste API a proxy diversi in modi diversi.

Esempio di routing

Ad esempio:

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

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

• I prod-group nomi host sono definiti nei seguenti nomi host:

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

• In questi ambienti viene 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 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 instradate a diversi proxy di cui è stato eseguito il deployment in ambienti all'interno del gruppo, a seconda del nome host e del percorso di base:

Suggerimento:

I nomi host definiti in un gruppo di ambiente:

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

Per ulteriori informazioni, consulta la sezione Aggiungere 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 ciascun gruppo di ambiente a cui appartiene l'ambiente. Questo è utile se un cliente ha certificati con caratteri jolly (come *.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
• Viene eseguito il deployment del proxy foo in shared-env con un percorso 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 vengono indirizzati allo stesso ambiente. In questo modo, a ogni gruppo di ambienti viene assegnato un nome di dominio univoco. Per Apigee ibrido, 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 coppie 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 delle KVM.

Analogamente, alcune funzionalità possono essere limitate agli ambienti o ai gruppi di ambienti all'interno dell'organizzazione. Ad esempio, i dati di analisi di Analytics sono partizionati da una combinazione di organizzazioni, ambienti e, infine, gruppo di ambienti.

Considerazioni

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

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

Risorse aggiuntive

Le informazioni seguenti 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 Groups Groups
  • API Environment Group Group