Informazioni sugli ambienti

Un ambiente fornisce un contesto isolato o "sandbox" per l'esecuzione di 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
...

Supponi che il deployment di un proxy con il percorso di base /foo1 venga eseguito nell'ambiente test. Puoi chiamare il proxy in questo modo: 

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

Quando questa chiamata raggiunge il traffico in entrata, questo in entrata lo invia 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 come questa all'alias host apiprod.mydomain.net: 

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

Inoltre, la chiamata viene instradata dal traffico in entrata alla pagina MP associata a tale 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

Per quanto riguarda gli ambienti ibridi, il fatto che molti ambienti possano condividere gli stessi host virtuali definiti nei gruppi di ambienti, devi valutare con attenzione come gestire i tuoi deployment proxy in qualsiasi ambiente. La soluzione ibrida prevede la creazione di più ambienti e il deployment di un numero limitato di proxy in ciascuno.

Quanti proxy devi 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 è utile limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e sugli aspetti da considerare in merito alla gestione dei deployment dei proxy:

Problema da considerare Descrizione
Tempo di avvio del processore di messaggi Esiste una correlazione diretta tra la quantità di tempo necessaria per l'avvio di un elaboratore di messaggi (MP) e il numero di proxy di cui è stato eseguito il deployment in tale 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 è stato eseguito il deployment nell'MP, più tempo sarà necessario per l'individuazione del MP, se è necessario scalarlo o ricrearlo.
Scalabilità delle prestazioni Se hai più proxy di cui è stato eseguito il deployment in un ambiente e uno di loro riceve molto traffico in modo da scalare automaticamente, tutti i proxy in quell'ambiente verranno scalati con quell'ambiente. L'effetto legato alla scalabilità di più proxy con un singolo proxy a traffico elevato potrebbe essere un problema.
Vicinante rumoroso Se hai eseguito il deployment su 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 MP. Limitando il numero di proxy di cui è stato eseguito il deployment in un ambiente, puoi ridurre al minimo l'impatto di un singolo arresto anomalo del proxy.

Gruppi di ambienti e host virtuali

I gruppi di ambienti consentono di raggruppare ambienti. Gli ambienti all'interno di ogni gruppo condividono gli stessi nomi host. Puoi raggruppare gli ambienti in base alla funzione, all'indirizzo host, all'area geografica se implementi un'installazione ibrida su più aree geografiche o in base a qualsiasi altra metrica che scegli.

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

Il seguente codice mostra un esempio di configurazione di override in cui sono definiti più virtualhost. Tieni presente che il nome dei virtualihost 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