Un ambiente fornisce un contesto o una "sandbox" isolati per l'esecuzione di proxy API. In una singola organizzazione puoi creare più ambienti.
Il codice seguente mostra un esempio di override della configurazione in cui sono presenti più ambienti definito.
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
sia di cui è stato eseguito il deployment nell'ambiente test. Puoi chiamare il proxy come segue:
curl -k https://api.example.com/foo1
Quando questa chiamata arriva all'ingresso, quest'ultimo sa di inviarla all'elaboratore di messaggi associato all'ambiente test
, che gestisce la richiesta.
Allo stesso modo, se il deployment di foo1
viene eseguito anche nell'ambiente prod
,
potresti creare un proxy
come questa, all'alias host apiprod.mydomain.net
:
curl -k https://apiprod.example.com/foo1
La chiamata viene inoltrata dall'ingresso all'MP associato all'host.
Antipattern: esegui il deployment di tutti i proxy in un ambiente ibrido.
Best practice: crea più ambienti e implementa un numero limitato di proxy in ciascuno.
Limita il numero di deployment dei proxy
Nel caso degli ambienti ibridi, il fatto che molti ambienti possano condividere gli stessi host virtuali come definito nei gruppi di ambienti, che devi pensare attentamente a come gestire le tue distribuzioni proxy per qualsiasi completamente gestito di Google Cloud. In un ambiente ibrido, la best practice è creare più ambienti e implementare un numero limitato di proxy in ciascuno.
Quanti proxy devi implementare in un ambiente? Non c'è una risposta impostata a questa domanda: tuttavia, la tabella seguente fornisce indicazioni generali sul motivo per cui si tratta di un è buona norma limitare il numero di proxy di cui è stato eseguito il deployment in ciascun ambiente e il numero devi pensare quando gestisci i deployment proxy:
Problema da considerare | Descrizione |
---|---|
Tempo di avvio del processore di messaggi | Esiste una correlazione diretta tra il tempo necessario per l'avvio di un elaboratore di messaggi (MP) e il numero di proxy di cui è stato eseguito il deployment nell'MP. In una scalabilità automatica Kubernetes, un aumento del tempo di avvio potrebbe rappresentare un problema. Più proxy vengono di'implementati nel pool di proxy, più tempo occorrerà per la sua attivazione se deve essere scalato o ricreato. |
Prestazioni di scalabilità | Se hai più proxy di cui è stato eseguito il deployment in un ambiente e uno dei proxy viene molto traffico, in modo che spesso venga scalato automaticamente, tutti i proxy dell'ambiente di rete lo scalerà di conseguenza. L'effetto sulle prestazioni della scalabilità con un singolo proxy a traffico elevato potrebbe essere un problema. |
Vicino rumoroso | Se hai diversi proxy di cui è stato eseguito il deployment nello stesso ambiente e uno si arresta in modo anomalo, tutti i proxy nell'ambiente verranno disattivati durante il riavvio degli MP. Se limiti il numero di proxy di cui è stato eseguito il deployment in un ambiente, riduci al minimo l'impatto del crash di un singolo proxy. |
Gruppi di ambienti e virtualhost
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 host, per regione se stai implementando un'installazione ibrida multi-regione o per qualsiasi altra metrica che scegli.
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 ambiente e le eventuali certificati appropriati.
Il codice seguente mostra un esempio di override della configurazione in cui sono presenti più virtualhost definito. 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
- Informazioni sugli ambienti e sui gruppi di ambienti
- Gestione degli ambienti
- Gestire i gruppi di ambienti
- Informazioni sulle proprietà di configurazione
- Configurare gli host virtuali