- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
Questo argomento illustra il routing dei percorsi di base. Il routing del percorso di base consente di configurare e gestire il modo in cui Apigee hybrid instrada le chiamate proxy delle API all'ambiente corretto.
Utilizza il routing dei percorsi di base per gestire i deployment proxy
Poiché è possibile mappare un singolo host virtuale a più ambienti in un ambiente ibrido, devi indicare un modo per specificare quale percorso di base del proxy viene mappato a un determinato ambiente.
Ad esempio, supponiamo di voler mappare due ambienti allo stesso alias host:
apitest.mydomain.net
. Nel file di override, puoi creare la seguente configurazione in cui gli ambienti dev1 e dev2 sono entrambi mappati a questo host. Ad esempio:
envs: - name: dev1 hostAlias: "apitest.mydomain.net" ... - name: dev2 hostAlias: "apitest.mydomain.net" ...
Ora, supponiamo che tu esegua il deployment dei proxy in questi ambienti. Esegui il deployment di:
- Proxy foo1 con percorso di base /foo1 a dev1
- Proxy foo2 con percorso di base /foo2 a dev2
Supponiamo che un client chiami questa API: https://apitest.mydomain.net/foo1
. Tieni presente che in questo percorso (o nell'intestazione dell'host generata per la richiesta) non esiste nulla che indichi all'ibrido a quale ambiente instradare la chiamata. È stato eseguito il deployment del proxy foo1 in dev1 o dev2?
Basandosi solo sull'URL della richiesta, non c'è modo di saperlo. Devi mappare esplicitamente ciascuno di questi percorsi di base a uno o più ambienti.
Per specificare a quale ambiente deve essere instradata una chiamata proxy, aggiungi la proprietà paths.uri.prefixes
alla proprietà envs
nel file di override, come mostrato nell'esempio seguente:
gcpProjectID: example k8sClusterName: apigee-hybrid # Apigee org name. org: my-org envs: # Apigee environment name. - name: dev1 hostAlias: "apitest.mydomain.net" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key serviceAccountPaths: synchronizer: ./service-accounts/example-apigee-synchronizer.json udca: ./service-accounts/example-apigee-udca.json paths: uri: prefixes: - /foo1 - name: dev2 hostAlias: "apitest.mydomain.net" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key serviceAccountPaths: synchronizer: ./service-accounts/example-apigee-synchronizer.json udca: ./service-accounts/example-apigee-udca.json paths: uri: prefixes: - /foo2 ...
Ora, quando arriva una chiamata API, ad esempio https://apitest.mydomain.net/foo1
, il router in entrata sa dove inviarla. Sa che viene eseguito il deployment del proxy /foo1 nell'ambiente dev1 e la chiamata viene instradata al processore di messaggi di dev1.
Se invii questa chiamata, https://apitest.mydomain.net/foo2
, verrà anch'essa instradata all'MP dell'ambiente dev2
e così via.
Riassumendo, la configurazione di paths.uri.prefixes
consente di gestire i deployment proxy
in più ambienti che condividono lo stesso alias host.
Best practice: utilizza il routing del percorso di base quando vuoi che più ambienti condividano lo stesso alias host. Il routing del percorso di base consente di limitare il numero di proxy di cui è stato eseguito il deployment in qualsiasi singolo ambiente. Per maggiori informazioni, consulta Limitare il numero di deployment proxy.
Aggiungere un nuovo ambiente allo stesso dominio
Questa sezione spiega come aggiungere un nuovo ambiente a un dominio.
In questo scenario, supponiamo di avere già eseguito il deployment di un ambiente dev1
nel cluster. In questa configurazione di esempio, sono consentiti solo i proxy con il prefisso del percorso base /foo1
:
gcpProjectID: example k8sClusterName: apigee-hybrid # Apigee org name. org: my-org envs: # Apigee environment name. - name: dev1 hostAlias: "apitest.mydomain.net" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key serviceAccountPaths: synchronizer: ./service-accounts/example-apigee-synchronizer.json udca: ./service-accounts/example-apigee-udca.json paths: uri: prefixes: - /foo1 mart: hostAlias: "mart.apigee-hybrid-docs.net" serviceAccountPath: ./service-accounts/example-apigee-mart.json sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.key metrics: serviceAccountPath: ./service-accounts/willwitman-istio-25240157d44a.json
Per aggiungere un altro ambiente che condivide lo stesso dominio:
- Crea un nuovo file di override con la configurazione del nuovo ambiente. Ad esempio, questa configurazione crea un ambiente chiamato
dev2
. In questo ambiente sono consentiti solo i proxy con il suffisso del percorso/foo2
:gcpProjectID: example k8sClusterName: apigee-hybrid # Apigee org name. org: my-org envs: # Apigee environment name. - name: dev2 hostAlias: "apitest.mydomain.net" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key serviceAccountPaths: synchronizer: ./service-accounts/example-apigee-synchronizer.json udca: ./service-accounts/example-apigee-udca.json paths: uri: prefixes: - /foo2 mart: hostAlias: "mart.apigee-hybrid-docs.net" serviceAccountPath: ./service-accounts/example-apigee-mart.json sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.key metrics: serviceAccountPath: ./service-accounts/willwitman-istio-25240157d44a.json
- Esegui i seguenti comandi in qualsiasi ordine:
apigeectl apply -f overrides/overrides-dev2.yaml -c udca
apigeectl apply -f overrides/overrides-dev2.yaml -c synchronizer
apigeectl apply -f overrides/overrides-dev2.yaml -c runtime
- Esegui il deployment del proxy foo2 nell'ambiente dev2.
- Chiama il proxy per testare la configurazione.
curl https://apitest.mydomain.net/foo2
Aggiungi un nuovo percorso di base proxy a un ambiente esistente
Per aggiungere un nuovo percorso di base a un ambiente esistente, è sufficiente aggiungere una voce prefixes
per ogni nuovo percorso di base. Ad esempio, se crei un nuovo proxy con il percorso di base /foo4 e vuoi eseguirne il deployment nell'ambiente chiamato dev2, segui questi passaggi:
- Apri il file di override contenente la definizione dell'ambiente dev2.
- Aggiungi il percorso di base
/foo4
all'elementopaths.uri.prefixes
:gcpProjectID: example k8sClusterName: apigee-hybrid # Apigee org name. org: my-org envs: # Apigee environment name. - name: dev2 hostAlias: "apitest.mydomain.net" sslCertPath: ./certs/keystore.pem sslKeyPath: ./certs/keystore.key serviceAccountPaths: synchronizer: ./service-accounts/example-apigee-synchronizer.json udca: ./service-accounts/example-apigee-udca.json paths: uri: prefixes: - /foo2 - /foo4 mart: hostAlias: "mart.apigee-hybrid-docs.net" serviceAccountPath: ./service-accounts/example-apigee-mart.json sslCertPath: ./certs/fullchain.pem sslKeyPath: ./certs/privkey.key metrics: serviceAccountPath: ./service-accounts/willwitman-istio-25240157d44a.json
- Applica il componente
runtime
al cluster:apigeectl apply -f overrides/overrides-dev2.yaml -c runtime
- Chiama il proxy per testare la configurazione.
curl https://apitest.mydomain.net/foo4
Se arriva una chiamata API per
https://apitest.mydomain.net/foo4
, ibrido sa che deve instradarla all'ambientedev2
.