Un ambiente fornisce un contesto isolato o una "sandbox" per l'esecuzione dei proxy API. In un'unica organizzazione, puoi creare più ambienti. Per maggiori informazioni, consulta Informazioni sugli ambienti e sui gruppi di ambienti.
Durante un'installazione di base, hai aggiunto un ambiente per i test. Tuttavia, consigliamo di creare più ambienti e di eseguire il deployment di un numero limitato di proxy su ciascuno di essi.
Informazioni sugli ambienti e sugli host virtuali
Apigee hybrid utilizza gateway Istio in entrata per gestire il traffico API in entrata. I servizi MART e runtime sono entrambi configurati con gateway Istio in entrata per gestire le proprie connessioni esposte all'esterno del cluster. Ciò significa, ad esempio, che tutte le richieste HTTP e HTTPS a un proxy API vengono prima gestite da un gateway in entrata Istio.
Nella modalità ibrida, puoi creare uno o più ambienti e assegnare a ciascun ambiente un alias host. L'alias host è un nome DNS. Il traffico in entrata verso quel nome DNS viene instradato dal traffico in entrata verso quell'ambiente. Internamente, ogni ambiente è assegnato a un solo processore di messaggi, che si occupa di elaborare le richieste proxy, applicare criteri e instradare il traffico da e verso i servizi di destinazione. Pertanto, l'alias host determina quale processore di messaggi riceve una determinata richiesta in entrata.
Il codice seguente mostra una configurazione di esempio in cui sono definiti più ambienti. Queste configurazioni appartengono al file degli override. Tieni presente che gli ambienti dev1 e prod1 hanno alias host diversi:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: prod1
hostAlias: "apiprod.mydomain.net"
...
Supponiamo che sia stato eseguito il deployment di un proxy con percorso di base /foo1 nell'ambiente
dev1. Potresti chiamare il proxy nel seguente modo:
curl -k https://apitest.mydomain.net/foo1
Quando questa chiamata raggiunge il traffico in entrata, il contatto in entrata sa di inviarla al processore di messaggi associato all'ambiente dev1, che gestisce la richiesta.
Allo stesso modo, se viene eseguito il deployment di foo1 anche nell'ambiente prod1,
puoi effettuare una richiesta proxy di questo tipo all'alias host apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
La chiamata viene instradata dal server in entrata al MP associato a quell'host.
Riassumendo, a ogni ambiente che crei deve essere assegnato un alias host. Ogni ambiente viene mappato a un solo processore di messaggi e l'alias host determina quale processore di messaggi riceve una determinata richiesta.
Gli ambienti possono condividere lo stesso alias host
Apigee hybrid ti consente di creare più ambienti da gestire come preferisci. Ad esempio, puoi creare diversi ambienti di sviluppo (dev1, dev2, dev3 e così via) e mappare un singolo alias host a ciascuno. Inoltre, puoi eseguire il deployment di più proxy in ciascun ambiente.
Antipattern: esegui il deployment di tutti i proxy in un ambiente ibrido.
Best practice: crea più ambienti ed esegui il deployment di un numero limitato di proxy in ciascuno. La tecnica per gestire il modo in cui le chiamate proxy instradano ibride all'ambiente corretto che condivide un alias host è denominata routing del percorso di base.
Ad esempio, nella configurazione seguente, gli ambienti dev1 e dev2 condividono lo stesso alias host:
envs:
- name: dev1
hostAlias: "apitest.mydomain.net"
...
- name: dev2
hostAlias: "apitest.mydomain.net"
...
Quando più ambienti condividono lo stesso alias host, devi utilizzare la tecnica di configurazione denominata routing del percorso di base per mappare percorsi di base specifici del proxy ad ambienti specifici. Per ulteriori informazioni, vedi Routing del percorso di base.
Limita il numero di deployment proxy
Per il settore ibrido, il fatto che molti ambienti possano condividere lo stesso host virtuale significa che è necessario valutare attentamente come gestire i deployment proxy in qualsiasi ambiente specifico. In modalità ibrida, la best practice consiste nel creare più ambienti ed eseguire il deployment di un numero limitato di proxy su ciascuno.
Quanti proxy dovresti eseguire per il deployment in un ambiente? Non esiste una risposta predefinita a questa domanda; tuttavia, la tabella seguente fornisce indicazioni generali sul motivo per cui è una buona idea limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e su cosa è necessario considerare quando si gestiscono i deployment dei proxy:
| Problema da considerare | Descrizione |
|---|---|
| Tempo di avvio del processore di messaggi | Esiste una correlazione diretta tra la quantità di tempo impiegata da un processore di messaggi (MP) per l'avvio e il numero di proxy di cui è stato eseguito il deployment su quel MP. In un ambiente Kubernetes a scalabilità automatica, un aumento del tempo di avvio potrebbe rappresentare un problema. Maggiore è il numero di proxy di cui viene eseguito il deployment nella MP, più tempo sarà necessario per la creazione di un file MP se deve essere scalato o ricreato. |
| Scalabilità del rendimento | Se hai più proxy di cui è stato eseguito il deployment in un ambiente e uno dei proxy riceve molto traffico da scalare automaticamente, tutti i proxy nell'ambiente scaleranno di conseguenza. L'effetto sulle prestazioni della scalabilità di più proxy con un singolo proxy a traffico elevato potrebbe essere un problema. |
| Vicino rumoroso | Se hai eseguito il deployment di più proxy nello stesso ambiente e si verifica un arresto anomalo di un proxy, tutti i proxy nell'ambiente verranno rimossi durante il riavvio degli MP. Se limiti il numero di proxy di cui è stato eseguito il deployment in un ambiente, riduci al minimo l'impatto dell'arresto anomalo di un singolo proxy. |
Riferimento per la configurazione dell'ambiente
Per un elenco completo degli elementi di configurazione dell'ambiente, consulta envs nella
pagina di riferimento sulle proprietà di configurazione.
Utilizzo degli ambienti
Per ulteriori informazioni sulla configurazione, consulta i seguenti argomenti: