Un ambiente fornisce un contesto isolato o una "sandbox" per l'esecuzione di proxy API. In un'unica organizzazione, puoi creare più ambienti. Per ulteriori informazioni, vedi Informazioni sugli ambienti e sui gruppi di ambienti.
Durante un'installazione di base, hai aggiunto un ambiente per i test. È consigliabile, tuttavia, creare più ambienti ed eseguire il deployment di un numero limitato di proxy a ciascuno.
Informazioni su host virtuali e ambienti
Apigee hybrid utilizza Gateway in entrata Istio per gestire il traffico API in entrata. Il MART e i servizi di runtime sono entrambi configurati con gateway in entrata Istio per gestire i propri di 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.
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 per quel nome DNS viene indirizzato dall'ingresso a 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 dai servizi di destinazione. Pertanto, l'alias host determina quale elaboratore di messaggi riceve qualsiasi richiesta in entrata.
Il codice seguente mostra una configurazione di esempio in cui più ambienti sono definito. 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 un proxy con il percorso di base /foo1 sia dipiegato nell'ambiente
dev1. Potresti chiamare il proxy nel seguente modo:
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.
Allo stesso modo, se il deployment di foo1 viene eseguito anche nell'ambiente prod1,
potresti creare un 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.
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 che puoi gestire come preferisci. Per Ad esempio, puoi creare diversi ambienti di sviluppo: dev1, dev2, dev3 e così via e mappa una 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 a ciascuno. La tecnica per gestire il modo in cui ibridi instradano le chiamate proxy all'indirizzo un ambiente che condivide un alias host è chiamato routing del percorso di base.
Ad esempio, nella configurazione seguente, gli ambienti dev1 e dev2 condivide 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 instradamento dei percorsi di base per mappare percorsi di base dei proxy specifici ad ambienti specifici. Per ulteriori informazioni, consulta la sezione relativa al routing del percorso di base.
Limita il numero di deployment dei proxy
Nel caso dell'ibrido, il fatto che molti ambienti possano condividere lo stesso host virtuale significa che devi pensare attentamente a come gestire le tue distribuzioni proxy per qualsiasi completamente gestito di Google Cloud. 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 c'è una risposta impostata a questa domanda: tuttavia, la tabella seguente fornisce indicazioni generali sul motivo per cui si tratta di un è buona norma limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e il numero devi pensare quando gestisci i deployment 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 nell'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 più proxy di cui è stato eseguito il deployment in un ambiente e uno dei proxy viene molto traffico, in modo che spesso venga scalato automaticamente, tutti i proxy dell'ambiente di rete lo scalerà 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, minimizzare 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 nel
riferimento per le proprietà di configurazione.
Utilizzo degli ambienti
Per ulteriori informazioni sulla configurazione, consulta i seguenti argomenti: