Un ambiente fornisce un contesto o una "sandbox" isolati per l'esecuzione di proxy API. In una singola organizzazione puoi creare più ambienti. Per saperne di più, consulta 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 implementare un numero limitato di proxy in ciascuno.
Informazioni su host virtuali e ambienti
Apigee hybrid utilizza gateway di ingresso Istio per gestire il traffico API in entrata. I servizi MART e di runtime sono entrambi configurati con i gateway di ingresso Istio per gestire le loro 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 di ingresso Istio.
In modalità ibrida, crei uno o più ambienti e assegni a ogni ambiente un alias host. L'alias host è un nome DNS. Il traffico in entrata per quel nome DNS viene indirizzato dall'ingresso a quell'ambiente. All'interno, ogni ambiente è assegnato a un solo processore di messaggi, che si occupa di elaborare le richieste proxy, applicare i criteri e instradare il traffico verso e da i servizi target. Pertanto, l'alias host determina quale elaboratore di messaggi riceve qualsiasi richiesta in entrata.
Il seguente codice mostra un esempio di configurazione in cui sono definiti più ambienti. Queste configurazioni appartengono al file delle sostituzioni. 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 sia dipiegato nell'ambiente
dev1. Puoi chiamare il proxy come segue:
curl -k https://apitest.mydomain.net/foo1
Quando questa chiamata arriva all'ingresso, quest'ultimo sa di inviarla all'elaboratore di messaggi associato all'ambiente dev1, che gestisce la richiesta.
Analogamente, 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 inoltrata dall'ingresso all'MP associato all'host.
In sintesi, a ogni ambiente creato deve essere assegnato un alias host. Ogni ambiente è associato 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 ambiente ibrido.
Best practice: crea più ambienti e implementa un numero limitato di proxy in ciascuno. La tecnica per gestire il modo in cui l'ambiente ibrido instrada le chiamate proxy all'ambiente corretto che condivide un alias host è chiamata routing del percorso 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 chiamata routing del percorso base per mappare percorsi base proxy specifici a ambienti specifici. Per ulteriori informazioni, consulta la sezione relativa al routing del percorso di base.
Limita il numero di deployment dei proxy
Per l'ambiente ibrido, il fatto che molti ambienti possano condividere lo stesso host virtuale significa che devi riflettere attentamente su come gestire i deployment dei proxy in un determinato ambiente. In un ambiente ibrido, la best practice è creare più ambienti e implementare un numero limitato di proxy in ciascuno.
Quanti proxy devi implementare in un ambiente? Non esiste una risposta fissa a questa domanda. Tuttavia, la tabella seguente fornisce indicazioni generali sul perché è consigliabile limitare il numero di proxy di cui è stato eseguito il deployment in ogni ambiente e su cosa occorre tenere presente quando si gestiscono i deployment dei proxy:
| Problema da considerare | Descrizione |
|---|---|
| Tempo di avvio del processore di messaggi | Esiste una correlazione diretta tra il tempo necessario per l'avvio di un elaboratore di messaggi (MP) e il numero di proxy di cui è stato eseguito il deployment in quell'MP. In un ambiente Kubernetes con scalabilità automatica, un aumento del tempo di avvio potrebbe essere un problema. Più proxy vengono di'implementati nel pool di proxy, più tempo occorrerà per la sua attivazione se deve essere scalato o ricreato. |
| Prestazioni di scalabilità | Se hai implementato più proxy in un ambiente e uno di questi riceve molto traffico, quindi viene scalato automaticamente di frequente, tutti i proxy nell'ambiente verranno scalati di conseguenza. L'effetto sul rendimento della scalabilità di più proxy con un singolo proxy ad alto traffico potrebbe essere un problema. |
| Vicino rumoroso | Se hai diversi proxy di cui è stato eseguito il deployment nello stesso ambiente e uno si arresta in modo anomalo, tutti i proxy nell'ambiente verranno disattivati 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 del crash di un singolo proxy. |
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: