Informazioni sugli ambienti

Un ambiente fornisce un contesto o una "sandbox" isolati per l'esecuzione di proxy API. In un'unica 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 un proxy con il percorso di base /foo1 sia di cui è stato eseguito il deployment nell'ambiente test. Potresti chiamare il proxy nel seguente modo: 

curl -k https://api.example.com/foo1

Quando questa chiamata raggiunge il traffico in entrata, il componente in entrata sa di inviarla al processore di messaggi associati all'ambiente test, che gestisce la richiesta.

Analogamente, se foo1 viene implementato anche nell'ambiente prod, puoi effettuare una richiesta proxy come questa all'alias host apiprod.mydomain.net: 

curl -k https://apiprod.example.com/foo1

La chiamata viene inoltrata dall'ingresso all'MP associato all'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 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 sulle prestazioni della scalabilità con un singolo proxy a traffico elevato 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.

Gruppi di ambienti e virtualhost

Gruppi di ambienti ti consentono di raggruppare gli ambienti. Gli ambienti all'interno di ciascun gruppo condividono gli stessi hostname. 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 di base dei proxy API, e ambienti, ogni host virtuale deve elencare solo il nome del gruppo di ambiente e le 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

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