Informazioni sugli ambienti

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

Il codice seguente mostra un esempio di override della configurazione 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 venga eseguito il deployment di un proxy con il 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 traffico in entrata sa di doverla inviare al processore di messaggi associato all'ambiente test, che gestisce la richiesta.

Analogamente, se viene eseguito il deployment di foo1 anche nell'ambiente prod, potresti effettuare una richiesta proxy come la seguente all'alias host apiprod.mydomain.net: 

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

Inoltre, la chiamata viene instradata dal traffico in entrata al MP associato a quell'host.

Antipattern: esegui il deployment di tutti i proxy in un unico ambiente ibrido.

Best practice: crea più ambienti ed esegui il deployment di un numero limitato di proxy in ciascuno di essi.

Limita il numero di deployment proxy

Per quanto riguarda gli ambienti ibridi, il fatto che molti ambienti possano condividere gli stessi host virtuali definiti nei gruppi di ambienti significa che occorre valutare attentamente le modalità di gestione dei deployment proxy in un determinato ambiente. Nel modello ibrido, la best practice prevede la creazione di più ambienti ed il deployment di un numero limitato di proxy in ciascuno.

Quanti proxy dovresti eseguire il deployment in un ambiente? Non esiste una risposta predefinita a questa domanda; tuttavia, la seguente tabella fornisce indicazioni generali sui motivi per cui è opportuno limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e su cosa devi considerare quando gestisci i deployment dei proxy:

Problema da considerare Descrizione
Tempo di avvio del processore dei messaggi Esiste una correlazione diretta tra il tempo impiegato da un processore di messaggi (MP) per avviarsi e il numero di proxy di cui è stato eseguito il deployment in questo MP. In un ambiente Kubernetes a scalabilità automatica, un aumento del tempo di avvio potrebbe essere un problema. Maggiore è il numero di proxy di cui viene eseguito il deployment al MP, più tempo sarà necessario perché tale MP debba essere generato se questo deve essere scalato o ricreato.
Scalabilità delle prestazioni Se hai eseguito il deployment di più proxy in un ambiente e uno dei proxy riceve molto traffico al fine di scalare frequentemente in modo automatico, tutti i proxy nell'ambiente verranno scalati 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 un proxy si arresta in modo anomalo, tutti i proxy nell'ambiente verranno rimossi al riavvio degli MP. Limitando 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 ogni gruppo condividono gli stessi nomi host. Puoi raggruppare gli ambienti per funzione, indirizzo nome host, regione se stai implementando un'installazione ibrida per più regioni o in base a qualsiasi altra metrica scelta.

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 ambienti ed eventuali certificati appropriati.

Il codice seguente mostra un esempio di override della configurazione in cui vengono definiti più virtualhost. Tieni presente che il nome dei virtualhost deve essere i nomi dei gruppi di ambienti. 

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