Informazioni sugli ambienti

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

Il seguente codice 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 un proxy con il percorso di base /foo1 venga sottoposto a deployment nell'ambiente test. Puoi chiamare il proxy in questo modo: 

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

Quando questa chiamata raggiunge l'ingresso, quest'ultimo sa di inviarla al processore di messaggi associato all'ambiente test, che gestisce la richiesta.

Allo stesso modo, 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 indirizzata dall'ingresso al MP associato a quell'host.

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

Best practice: crea più ambienti e implementa un numero limitato di proxy in ciascuno.

Limita il numero di deployment dei proxy

Per l'ibrido, il fatto che molti ambienti possano condividere gli stessi host virtuali come definiti nei gruppi di ambienti significa che devi pensare attentamente a come gestire i deployment dei proxy in un determinato ambiente. Nell'ambiente ibrido, la best practice consiste nel creare più ambienti e distribuire un numero limitato di proxy a ciascuno.

Quanti proxy devi eseguire il deployment in un ambiente? Non esiste una risposta univoca 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 ogni ambiente e su cosa devi pensare quando gestisci i deployment dei proxy:

Problema da considerare Descrizione
Tempo di avvio del processore di messaggi Esiste una correlazione diretta tra il tempo impiegato da un processore di messaggi (MP) per l'avvio e il numero di proxy di cui è stato eseguito il deployment. In un ambiente Kubernetes con scalabilità automatica, un aumento del tempo di avvio potrebbe essere un problema. Più proxy vengono implementati nel MP, più tempo impiegherà l'MP a essere disponibile se deve essere scalato o ricreato.
Prestazioni di scalabilità Se hai eseguito il deployment di più proxy in un ambiente e uno dei proxy riceve molto traffico, quindi viene scalato automaticamente di frequente, tutti i proxy in quell'ambiente vengono scalati insieme. L'effetto sulle prestazioni del ridimensionamento di più proxy con un singolo proxy ad alto traffico potrebbe essere un problema.
Vicino rumoroso Se hai più proxy di cui è stato eseguito il deployment nello stesso ambiente e uno dei proxy si arresta in modo anomalo, tutti i proxy nell'ambiente verranno disattivati durante il riavvio dei processori di messaggi. Limitando il numero di proxy di cui viene eseguito il deployment in un ambiente, riduci al minimo l'impatto di un singolo proxy che si arresta in modo anomalo.

Gruppi di ambienti e virtual host

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 hostname, per regione se stai implementando un'installazione ibrida multiregionale o per qualsiasi altra metrica che scegli.

Poiché il routing è gestito dalla combinazione di nomi host del gruppo di ambienti, percorsi di base del proxy API e ambienti, ogni host virtuale deve elencare solo il nome del gruppo di ambienti e gli eventuali certificati appropriati.

Il seguente codice mostra un esempio di configurazione di override in cui sono definiti più virtual host. Tieni presente che il nome degli host virtuali deve corrispondere al nome 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