Configurare il routing del percorso base

Questo argomento illustra il routing del percorso base. Il routing del percorso di base ti consente di configurare e gestire il modo in cui Apigee hybrid indirizza le chiamate proxy API all'ambiente corretto.

Utilizzare il routing del percorso base per gestire i deployment dei proxy

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

Ad esempio, supponiamo che tu voglia mappare due ambienti allo stesso alias host: apitest.mydomain.net. Nel file degli 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"
    ...

Supponiamo ora che tu esegui 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 host generata per la richiesta) non c'è nulla che indichi a Hybrid a quale ambiente inoltrare la chiamata. Il proxy foo1 è disegnato su dev1 o dev2? Non è possibile stabilire se si tratta di una richiesta di autorizzazione o di una richiesta di accesso. Devi mappare esplicitamente ciascuno di questi percorsi di base a uno o più ambienti.

Per specificare a quale ambiente deve essere indirizzata una chiamata proxy, aggiungi la proprietà paths.uri.prefixes alla proprietà envs nel file delle sostituzioni, 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 router di ingresso sa dove inviarla. Sa che il proxy /foo1 è dipiegato nell'ambiente dev1 e che la chiamata viene indirizzata all'elaboratore dei messaggi di dev1.

Se invii questa chiamata, https://apitest.mydomain.net/foo2, viene inoltrata anche all'MP dell'ambiente dev2 e così via.

In sintesi, la configurazione paths.uri.prefixes ti consente di gestire i deployment dei proxy tra 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 base ti consente di limitare il numero di proxy di cui è stato eseguito il deployment in un singolo ambiente. Per ulteriori informazioni, consulta Limitare il numero di implementazioni dei proxy.

Aggiungere 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, sono consentiti solo i proxy con il prefisso del percorso di 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:

  1. Crea un nuovo file di override con la nuova configurazione dell'ambiente. Ad esempio, questa configurazione crea un ambiente denominato 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
  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

Aggiungere un nuovo percorso base del proxy a un ambiente esistente

Per aggiungere un nuovo percorso base a un ambiente esistente, aggiungi una voce prefixes per ogni nuovo percorso base. Ad esempio, se crei un nuovo proxy con il percorso di base /foo4 e vuoi eseguirlo nell'ambiente dev2, segui questi passaggi:

  1. Apri il file delle sostituzioni 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, hybrid sa come indirizzarla all'ambiente dev2.