Un ambiente fornisce un contesto isolato o "sandbox" per l'esecuzione dei proxy API. In una singola organizzazione, puoi creare più ambienti. Per maggiori informazioni, vedi Informazioni su ambienti e gruppi di ambienti.
Durante un'installazione di base, hai aggiunto un ambiente per i test. Tuttavia, è consigliabile creare più ambienti e distribuire un numero limitato di proxy in ciascuno.
Informazioni su host virtuali e ambienti
Apigee hybrid utilizza gateway in entrata Istio per gestire il traffico API in entrata. I servizi MART e di runtime sono entrambi configurati con i gateway in entrata Istio per gestire le connessioni esposte all'esterno del cluster. Ciò significa, ad esempio, che tutte le richieste HTTP e HTTPS a un proxy API vengono gestite prima da un gateway di ingresso Istio.
In ibrido, crei uno o più ambienti e assegni a ciascun ambiente un alias host. L'alias host è un nome DNS. Il traffico in entrata verso quel nome DNS viene instradato dall'ingresso a quell'ambiente. Internamente, ogni ambiente viene assegnato a un solo processore di messaggi, che si occupa di elaborare le richieste proxy, applicare le policy e instradare il traffico verso e da i servizi di destinazione. Pertanto, l'alias host determina quale processore di messaggi riceve una determinata richiesta in entrata.
Il seguente codice mostra una configurazione di esempio in cui sono definiti più ambienti. Queste configurazioni devono essere inserite nel file di 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 un proxy con il percorso di base /foo1 venga sottoposto a deployment nell'ambiente
dev1. Puoi chiamare il proxy in questo modo:
curl -k https://apitest.mydomain.net/foo1
Quando questa chiamata raggiunge l'ingresso, quest'ultimo sa di inviarla al processore di messaggi
associato all'ambiente dev1, che gestisce la richiesta.
Allo stesso modo, se foo1 viene implementato anche nell'ambiente prod1,
puoi effettuare una richiesta proxy
come questa, all'alias host apiprod.mydomain.net:
curl -k https://apiprod.mydomain.net/foo1
La chiamata viene indirizzata dall'ingresso al MP associato a quell'host.
In sintesi, 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 che puoi 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 ogni ambiente.
Antipattern: esegui il deployment di tutti i proxy in un unico ambiente ibrido.
Best practice: crea più ambienti e implementa un numero limitato di proxy in ciascuno. La tecnica per gestire il modo in cui le chiamate proxy delle route ibride vengono indirizzate all'ambiente corretto che condivide un alias host è chiamata routing del percorso base.
Ad esempio, nella seguente configurazione, 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 chiamata routing del percorso base per mappare percorsi base proxy specifici a ambienti specifici. Per ulteriori informazioni, vedi routing del percorso di base.
Limita il numero di deployment dei proxy
Per l'ibrido, il fatto che molti ambienti possano condividere lo stesso host virtuale significa che devi pensare attentamente a come gestire i deployment dei proxy in un determinato ambiente. Nell'ambiente ibrido, la best practice consiste nel creare più ambienti e distribuire un numero limitato di proxy a ciascuno.
Quanti proxy devi eseguire il deployment in un ambiente? Non esiste una risposta univoca 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 ogni ambiente e su cosa devi pensare quando gestisci i deployment dei proxy:
| Problema da considerare | Descrizione |
|---|---|
| Tempo di avvio del processore di messaggi | Esiste una correlazione diretta tra il tempo impiegato da un processore di messaggi (MP) per l'avvio e il numero di proxy di cui è stato eseguito il deployment. In un ambiente Kubernetes con scalabilità automatica, un aumento del tempo di avvio potrebbe essere un problema. Più proxy vengono implementati nel MP, più tempo impiegherà l'MP a essere disponibile se deve essere scalato o ricreato. |
| Prestazioni di scalabilità | Se hai eseguito il deployment di più proxy in un ambiente e uno dei proxy riceve molto traffico, quindi viene scalato automaticamente di frequente, tutti i proxy in quell'ambiente vengono scalati insieme. L'effetto sulle prestazioni del ridimensionamento di più proxy con un singolo proxy ad alto traffico potrebbe essere un problema. |
| Vicino rumoroso | Se hai più proxy di cui è stato eseguito il deployment nello stesso ambiente e uno dei proxy si arresta in modo anomalo, tutti i proxy nell'ambiente verranno disattivati durante il riavvio dei processori di messaggi. Limitando il numero di proxy di cui viene eseguito il deployment in un ambiente, riduci al minimo l'impatto di un singolo proxy che si arresta in modo anomalo. |
Riferimento per la configurazione dell'ambiente
Per un elenco completo degli elementi di configurazione dell'ambiente, consulta envs nel
Riferimento per le proprietà di configurazione.
Utilizzo degli ambienti
Per ulteriori informazioni sulla configurazione, consulta i seguenti argomenti: