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 delle sostituzioni 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. Puoi chiamare il proxy come segue: 

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.

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 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 dei proxy

Nel caso degli ambienti ibridi, il fatto che molti ambienti possano condividere gli stessi host virtuali come definito nei gruppi di ambienti, che devi pensare attentamente a come gestire le tue distribuzioni proxy per qualsiasi completamente gestito di Google Cloud. 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 esiste una risposta predefinita 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 gestisce il 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 nell'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.
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 eseguito il deployment di più proxy nello stesso ambiente, si arresta in modo anomalo, tutti i proxy nell'ambiente vengono rimossi mentre I MP vengono riavviati. 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

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 seguente codice mostra un esempio di configurazione delle sostituzioni in cui sono definiti più virtualhost. 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