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 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 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, puoi effettuare una richiesta proxy come la seguente all'alias host apiprod.mydomain.net: 

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

e 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.

Limita il numero di deployment proxy

Per gli ambienti ibridi, il fatto che molti ambienti possano condividere gli stessi host virtuali definiti nei gruppi di ambienti significa che è necessario pensare attentamente a come si gestiscono i deployment proxy in un determinato ambiente. Nella modalità ibrida, la best practice consiste nel creare più ambienti ed eseguire 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 è consigliabile 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 di 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, l'aumento del tempo di avvio potrebbe essere un problema. Maggiore è il numero di proxy che vengono distribuiti all'MP, maggiore sarà il tempo necessario per la creazione del MP se questo deve essere scalato o ricreato.
Scalabilità delle prestazioni Se hai eseguito il deployment di diversi proxy in un ambiente e uno dei proxy riceve molto traffico al fine di scalare automaticamente spesso, tutti i proxy nell'ambiente verranno scalati con il traffico. 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 dei file MP. Limitando il numero di proxy di cui è stato eseguito il deployment in un ambiente, riduci al minimo l'impatto di un singolo arresto anomalo del 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 del nome host, regione se stai implementando un'installazione ibrida su 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 configurazione di override in cui vengono definiti più virtualhost. Tieni presente che i nomi dei virtualhost devono corrispondere ai 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