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 codice seguente mostra una configurazione di esempio 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. Puoi chiamare il proxy in questo modo:

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

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

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

La chiamata viene instradata dal traffico in entrata al MP associato a tale 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 quanto riguarda l'ambiente 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 dei proxy in qualsiasi ambiente. In modalità ibrida, la best practice prevede la creazione di più ambienti e il deployment di un numero limitato di proxy in ognuno.

Quanti proxy dovresti eseguire il deployment in un ambiente? Non esiste una risposta predefinita a questa domanda; tuttavia, la seguente tabella fornisce indicazioni generali sul motivo per cui è consigliabile limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e cosa occorre considerare durante la gestione dei deployment proxy:

Problema da considerare Descrizione
Tempo di avvio del processore di messaggi Esiste una correlazione diretta tra la quantità di tempo richiesta per l'avvio di un processore di messaggi (MP) e il numero di proxy di cui viene eseguito il deployment in tale MP. In un ambiente Kubernetes a scalabilità automatica, l'aumento del tempo di avvio potrebbe rappresentare un problema. Maggiore è il numero di proxy di cui è stato eseguito il deployment nella MP, più tempo sarà necessario per visualizzarla se è necessario scalarla o ricrearla.
Prestazioni di scalabilità Se hai più proxy di cui è stato eseguito il deployment in un ambiente e uno di loro riceve molto traffico per garantire una scalabilità automatica frequente, tutti i proxy in quell'ambiente sono in grado di scalare. L'effetto sulle prestazioni della scalabilità di più proxy con un singolo proxy ad alto traffico potrebbe essere un problema.
Vicinante rumoroso Se hai più proxy di cui è stato eseguito il deployment nello stesso ambiente e un proxy si arresta in modo anomalo, tutti i proxy nell'ambiente verranno rimossi mentre i MP vengono riavviati. Limitando il numero di proxy di cui è stato eseguito il deployment in un ambiente, riduci al minimo l'impatto di un arresto anomalo di un singolo proxy.

Gruppi di ambienti e host virtuali

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 in base alla funzione, all'indirizzo host e all'area geografica, se stai implementando un'installazione ibrida a più aree geografiche o tramite 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 e gli eventuali certificati appropriati.

Il codice seguente mostra una configurazione di esempio di override in cui sono definiti più virtualhost. Tieni presente che i nomi degli host virtuali devono essere i nomi dei gruppi dell'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