Informazioni sugli ambienti

Un ambiente fornisce un contesto isolato o una "sandbox" per l'esecuzione dei proxy API. In un'unica organizzazione, puoi creare più ambienti.

Il codice seguente mostra un esempio di configurazione di 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 di un proxy con percorso di base /foo1 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 contatto in entrata sa di inviarla al processore di messaggi associato all'ambiente test, che gestisce la richiesta.

Allo stesso modo, se viene eseguito il deployment di foo1 anche nell'ambiente prod, puoi effettuare una richiesta proxy di questo tipo 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 in ciascuno.

Limita il numero di deployment proxy

Nel caso dell'ibrido, il fatto che molti ambienti possano condividere gli stessi host virtuali definiti nei gruppi di ambienti significa che devi pensare attentamente a come gestire i deployment proxy in qualsiasi ambiente specifico. In modalità ibrida, la best practice consiste nel creare più ambienti ed eseguire il deployment di un numero limitato di proxy su ciascuno.

Quanti proxy dovresti eseguire per il deployment in un ambiente? Non esiste una risposta predefinita a questa domanda; tuttavia, la tabella seguente fornisce indicazioni generali sul motivo per cui è una buona idea limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e su cosa è necessario considerare quando si gestiscono i deployment dei proxy:

Problema da considerare Descrizione
Tempo di avvio del processore di messaggi Esiste una correlazione diretta tra la quantità di tempo impiegata da 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 a scalabilità automatica, un aumento del tempo di avvio potrebbe rappresentare un problema. Maggiore è il numero di proxy di cui viene eseguito il deployment nella MP, più tempo sarà necessario per la creazione di un file MP se deve essere scalato o ricreato.
Scalabilità del rendimento Se hai più proxy di cui è stato eseguito il deployment in un ambiente e uno dei proxy riceve molto traffico da scalare automaticamente, tutti i proxy nell'ambiente scaleranno di conseguenza. L'effetto sulle prestazioni della scalabilità di più proxy con un singolo proxy a traffico elevato potrebbe essere un problema.
Vicino rumoroso Se hai eseguito il deployment di più proxy nello stesso ambiente e si verifica un arresto anomalo di un proxy, tutti i proxy nell'ambiente verranno rimossi 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 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 ciascun gruppo condividono gli stessi nomi host. Puoi raggruppare gli ambienti per funzione, indirizzo del nome host, regione se stai implementando un'installazione ibrida multiregionale o in base a qualsiasi altra metrica di tua scelta.

Poiché il routing è gestito dalla combinazione di nomi host dei gruppi di ambienti, percorsi di base dei proxy API e ambienti, per ogni host virtuale è sufficiente indicare il nome del gruppo di ambiente e gli eventuali certificati appropriati.

Il codice seguente mostra un esempio di configurazione di override 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