Un ambiente fornisce un contesto isolato o una "sandbox" per l'esecuzione di proxy API. In una singola organizzazione puoi creare più ambienti.
Il seguente codice mostra un esempio di configurazione dell'override in cui sono definiti più ambienti.
namespace: my-namespace org: my-organization ... envs: - name: test serviceAccountPaths: synchronizer: "your_keypath/synchronizer-manager-service-account.json udca: "your_keypath/analytic-agent-service-account.json - name: prod serviceAccountPaths: synchronizer: "your_keypath/synchronizer-manager-service-account.json udca: "your_keypath/analytic-agent-service-account.json ...
Supponiamo che sia stato eseguito il deployment nell'ambiente di un proxy con percorso di base /foo1
test. Puoi chiamare il proxy come segue:
curl -k https://api.example.com/foo1
Quando questa chiamata arriva all'ingresso, quest'ultimo sa di inviarla all'elaboratore di messaggi associato all'ambiente test
, che gestisce la richiesta.
Allo stesso modo, se il deployment di foo1
viene eseguito anche nell'ambiente prod
,
potresti creare un proxy
come questa, all'alias host apiprod.mydomain.net
:
curl -k https://apiprod.example.com/foo1
La chiamata viene instradata dal server in entrata al MP associato a quell'host.
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.
Limita il numero di deployment proxy
Per l'ambiente ibrido, il fatto che molti ambienti possano condividere gli stessi host virtuali come definito nei gruppi di ambienti significa che devi riflettere attentamente su come gestire i deployment dei proxy in un determinato ambiente. Nel caso di ambienti ibridi, la best practice consiste nel creare più ambienti ed eseguire il deployment a ciascuno di essi è associato un numero limitato di proxy.
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 la quantità di tempo in cui un processore di messaggi (MP) per l'avvio e il numero di proxy di cui è stato eseguito il deployment su quel MP. In una scalabilità automatica Kubernetes, un aumento del tempo di avvio potrebbe rappresentare un problema. Maggiore è il numero di proxy deployment al MP, più tempo impiegherà quell'MP deve essere scalato o ricreato. |
Scalabilità del rendimento | 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, minimizzare l'impatto dell'arresto anomalo di un singolo proxy. |
Gruppi di ambienti e virtualhost
I gruppi di ambienti ti consentono di raggruppare gli ambienti. Gli ambienti all'interno di ogni gruppo condividono gli stessi nomi host. Puoi raggruppare gli ambienti per funzione, per indirizzo del nome host e per regione, se stai implementando un'installazione ibrida multiregionale o in base a qualsiasi altra metrica scegliere.
Poiché il routing è gestito dalla combinazione di nomi host dei gruppi di ambienti, percorsi base dei proxy API e ambienti, ogni host virtuale deve elencare solo il nome del gruppo di ambienti e eventuali certificati appropriati.
Il codice seguente mostra un esempio di configurazione di override in cui sono presenti più virtualhost definito. Tieni presente che il nome degli host virtuali deve essere quello dei gruppi di ambiente.
gcp: region: us-central1 projectID: hybrid-example k8sCluster: name: apigee-hybrid region: us-central1 org: hybrid-example contractProvider: https://us-apigee.googleapis.com # if using data residency instanceID: "my_hybrid_example" virtualhosts: - name: group-1 # the name of an environment group sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key virtualhosts: - name: group-2 sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key ...
Risorse aggiuntive
- Informazioni sugli ambienti e sui gruppi di ambienti
- Gestione degli ambienti
- Gestione dei gruppi di ambienti
- Informazioni sulle proprietà di configurazione
- Configurare gli host virtuali