Configura il routing del percorso di base

Questo argomento illustra il routing del percorso di base. Il routing del percorso di base consente di configurare e gestire le route ibride di Apigee le chiamate proxy all'ambiente corretto.

Usa il routing del percorso di base per gestire i deployment proxy

Poiché è possibile mappare un singolo host virtuale più ambienti in modalità ibrida, devi avere un modo per specificare quale percorso di base del proxy è mappato a quale ambiente.

Ad esempio, supponiamo che tu voglia mappare due ambienti allo stesso alias host: apitest.mydomain.net. Nel file di override, puoi creare quanto segue in cui gli ambienti dev1 e dev2 sono entrambi mappato 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 da /foo1 a dev1
  • Proxy foo2 con percorso di base da /foo2 a dev2

Supponiamo che un client chiami questa API: https://apitest.mydomain.net/foo1. Nota che non c'è nulla in questo percorso (o nell'intestazione host generata per la richiesta) che indichi a quale ambiente instradare la chiamata. È stato eseguito il deployment del proxy foo1? in dev1 o dev2? Solo in base all'URL della richiesta, non c'è modo di saperlo. Devi mappare esplicitamente ogni di questi percorsi di base verso uno o più ambienti.

Per specificare a quale ambiente deve essere instradata una chiamata proxy, aggiungi il metodo paths.uri.prefixes alla proprietà envs nel file degli 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, come: https://apitest.mydomain.net/foo1, il traffico in entrata router sa dove inviarlo. Sa che il proxy /foo1 viene eseguito il deployment in dev1 e la chiamata viene instradata al processore di messaggi di dev1.

Se invii la chiamata https://apitest.mydomain.net/foo2, verrà anch'essa instradata a i MP dell'ambiente dev2 e così via.

In sintesi, la configurazione di paths.uri.prefixes ti consente di gestire i deployment proxy tra più ambienti che condividono lo stesso alias host.

Best practice: usa il routing del percorso di base quando vuoi condividere il percorso di più ambienti che condividono 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 in un singolo ambiente. Per ulteriori informazioni, vedi Limita il numero di deployment proxy.

Aggiungi un nuovo ambiente allo stesso dominio

Questa sezione spiega come aggiungere un nuovo ambiente a un dominio.

In questo scenario, supponiamo che tu abbia già eseguito il deployment di un ambiente dev1 nel cluster. In questa configurazione di esempio, vengono utilizzati solo i proxy con il prefisso del percorso base /foo1 è consentito: 

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:

  1. Crea un nuovo file di override con la nuova configurazione di ambiente. Ad esempio, questo crea un ambiente denominato dev2. In questo ambiente, i proxy con il suffisso del percorso /foo2 sono consentiti: 
    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
  2. Esegui i seguenti comandi in qualsiasi ordine: 
    1. apigeectl apply -f overrides/overrides-dev2.yaml -c udca
    2. apigeectl apply -f overrides/overrides-dev2.yaml -c synchronizer
    3. apigeectl apply -f overrides/overrides-dev2.yaml -c runtime
  3. Esegui il deployment del proxy foo2 nell'ambiente dev2.
  4. 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, basta aggiungere un prefixes per ogni nuovo percorso di base. Ad esempio, se crei un nuovo proxy con il percorso di base /foo4 e vuoi eseguire il deployment nell'ambiente dev2, segui questi passaggi:

  1. Apri il file degli override che contiene la definizione dell'ambiente dev2.
  2. Aggiungi il percorso di base /foo4 all'elemento paths.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
  3. Applica il componente runtime al cluster: 
    apigeectl apply -f overrides/overrides-dev2.yaml -c runtime
  4. Chiama il proxy per testare la configurazione. 
    curl https://apitest.mydomain.net/foo4

    Se arriva una chiamata API per https://apitest.mydomain.net/foo4, il servizio ibrido sa per instradarlo all'ambiente dev2.