Referência de operações e configurações do Edge Microgateway

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Edge Microgateway v. 3.3.x

Neste tópico, você verá como gerenciar e configurar o Edge Microgateway.

Como fazer upgrade do Edge Microgateway se tiver uma conexão de Internet

Nesta seção, explicamos como fazer upgrade de uma instalação do Edge Microgateway. Se você estiver operando sem uma conexão de Internet, consulte Posso instalar o Edge Microgateway sem uma conexão de Internet?

A Apigee recomenda que você teste sua configuração atual com para a nova versão antes de fazer upgrade do ambiente de produção.

1. Execute o seguinte comando npm para fazer upgrade para a versão mais recente do Edge Microgateway:

   npm upgrade edgemicro -g

   Para instalar uma versão específica do Edge Microgateway, é preciso especificar a versão number no comando de instalação. Por exemplo, para instalar a versão 3.2.3, use o seguinte comando:

   npm install edgemicro@3.2.3 -g

2. Confira o número da versão. Por exemplo, se você instalou a versão 3.2.3:

   edgemicro --version
   current nodejs version is v12.5.0
   current edgemicro version is 3.2.3
       

3. Por fim, atualize para a versão mais recente do proxy edgemicro-auth:

   edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

Como fazer alterações na configuração

Os arquivos de configuração que você precisa conhecer incluem:

• Arquivo de configuração do sistema padrão
• Arquivo de configuração padrão para uma instância recém-inicializada do Edge Microgateway
• Arquivo de configuração dinâmica para instâncias em execução

Esta seção discute esses arquivos e o que você precisa saber sobre como alterá-los.

Configuração padrão do sistema arquivo

Quando você instala o Edge Microgateway, um arquivo de configuração do sistema padrão é colocado aqui:

prefix/lib/node_modules/edgemicro/config/default.yaml

Em que prefix é o diretório do prefixo npm. Consulte Onde o Edge Microgateway está instalado, se não for possível localizar esse diretório.

Se você alterar o arquivo de configuração do sistema, será necessário reinicializar, reconfigurar e reiniciar o Edge Microgateway:

edgemicro init
edgemicro configure [params]
edgemicro start [params]

Arquivo de configuração padrão para instâncias recém-inicializadas do Edge Microgateway

Ao executar edgemicro init, o arquivo de configuração do sistema (descrito acima), default.yaml, é colocado no diretório ~/.edgemicro.

Se você mudar o arquivo de configuração no ~/.edgemicro, precisará reconfigurar e reiniciar Edge Microgateway:

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

Dinâmico de configuração para instâncias em execução

Ao executar edgemicro configure [params], um modelo arquivo de configuração é criado em ~/.edgemicro. O arquivo é nomeado de acordo com este padrão: org-env-config.yaml, em que org e env são os nomes dos ambientes e da organização do Apigee Edge. É possível usar esse arquivo para fazer configurações alterações e depois recarregá-las sem tempo de inatividade. Por exemplo, se você adicionar e configurar um plug-in, você pode recarregar a configuração sem incorrer em inatividade, conforme explicado abaixo.

Se o Edge Microgateway estiver em execução (opção de inatividade zero):

1. Atualize a configuração do Edge Microgateway:

   edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET

   Em que:

   • $ORG é o nome da sua organização de Edge. Você precisa ser uma organização. administrador).
   • $ENV é um ambiente na sua organização (como "teste" ou "prod").
   • $KEY é a chave retornada anteriormente pelo comando configure.
   • $SECRET é a chave retornada anteriormente pelo comando configure.

   Por exemplo:

   edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
     -s 05c14356e42ed1...4e34ab0cc824

Se o Edge Microgateway for interrompido:

1. Reinicie o Edge Microgateway:

   edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   Em que:

   • $ORG é o nome da sua organização de Edge. Você precisa ser uma organização. administrador).
   • $ENV é um ambiente na sua organização (como "teste" ou "prod").
   • $KEY é a chave retornada anteriormente pelo comando configure.
   • $SECRET é a chave retornada anteriormente pelo comando configure.

   Exemplo:

   edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
     -s 05c1435...e34ab0cc824

Este é um exemplo de arquivo de configuração. Veja mais detalhes sobre as definições do arquivo de configuração na referência de configuração do Edge Microgateway.

edge_config:
  bootstrap: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/bootstrap/organization/docs/environment/test
  jwt_public_key: 'https://docs-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://docs-test.apigee.net/edgemicro-auth/products'
edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  verify_api_key_url: 'https://docs-test.apigee.net/edgemicro-auth/verifyApiKey'
analytics:
  uri: >-
    https://edgemicroservices-us-east-1.apigee.net/edgemicro/axpublisher/organization/docs/environment/test

Como definir variáveis de ambiente

Os comandos da interface de linha de comando que exigem valores para sua organização de Edge e e a chave e o secret necessários para iniciar o Edge Microgateway podem ser armazenados variáveis de ambiente:

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

A definição dessas variáveis é opcional. Se você configurá-las, não precisa especificar os valores delas quando você usa a interface de linha de comando (CLI) para configurar e iniciar o Edge Microgateway.

Como configurar SSL no Edge Microgateway servidor

Assista aos vídeos a seguir para saber como configurar o TLS no Apigee Edge Microgateway:

É possível configurar o servidor Microgateway para usar SSL. Por exemplo, com o SSL configurado, você pode chamar APIs pelo Edge Microgateway com o "https" da seguinte forma:

https://localhost:8000/myapi

Para configurar o SSL no servidor Microgateway, siga estas etapas:

1. Gere ou consiga uma chave e um certificado SSL usando o utilitário openssl ou o método que preferir.
2. Adicione o atributo edgemicro:ssl ao arquivo de configuração do Edge Microgateway. Para um guia lista de opções, consulte a tabela abaixo. Por exemplo:
   

   edgemicro:
     ssl:
      key: <absolute path to the SSL key file>
      cert: <absolute path to the SSL cert file>
      passphrase: admin123 #option added in v2.2.2
      rejectUnauthorized: true #option added in v2.2.2
      requestCert: true

3. Reinicie o Edge Microgateway. Siga as etapas descritas em Como fazer alterações na configuração dependendo de qual arquivo de configuração editado: o arquivo padrão ou o arquivo de configuração do ambiente de execução.

Veja um exemplo da seção edgemicro do arquivo de configuração, com SSL configurado:

edgemicro:
  port: 8000
  max_connections: 1000
  max_connections_hard: 5000
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - oauth
  ssl:
    key: /MyHome/SSL/em-ssl-keys/server.key
    cert: /MyHome/SSL/em-ssl-keys/server.crt
    passphrase: admin123 #option added in v2.2.2
    rejectUnauthorized: true #option added in v2.2.2

Esta é uma lista de todas as opções de servidor compatíveis:

Como usar as opções SSL/TLS do cliente

É possível configurar o Edge Microgateway como um cliente TLS ou SSL ao se conectar ao destino endpoints. No arquivo de configuração do Microgateway, use o elemento de destinos para definir o SSL/TLS . É possível definir vários destinos específicos. Um exemplo de vários destinos está incluído a seguir.

Este exemplo apresenta configurações que serão aplicadas a todos os hosts:

edgemicro:
...
targets:
  ssl:
    client:
      key: /Users/jdoe/nodecellar/twowayssl/ssl/client.key
      cert: /Users/jdoe/nodecellar/twowayssl/ssl/ca.crt
      passphrase: admin123
      rejectUnauthorized: true

Neste exemplo, as configurações são aplicadas apenas ao host especificado:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

Veja um exemplo para TLS:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    tls:
      client:
        pfx: /Users/myname/twowayssl/ssl/client.pfx
        passphrase: admin123
        rejectUnauthorized: true

Se você quiser aplicar configurações de TLS/SSL a vários destinos específicos, será preciso definir o primeiro host na configuração como "empty", o que ativa solicitações universais e, em seguida, especifica dos hosts em qualquer ordem. Neste exemplo, as configurações são aplicadas a vários hosts específicos:

targets:
 - host:   ## Note that this value must be "empty"
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       passphrase: admin123
       rejectUnauthorized: true
 - host: 'myserver1.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true
 - host: 'myserver2.example.com'
   ssl:
     client:
       key: /Users/myname/twowayssl/ssl/client.key
       cert: /Users/myname/twowayssl/ssl/ca.crt
       rejectUnauthorized: true

Esta é uma lista de todas as opções de cliente compatíveis:

Como personalizar o proxy Edgemicro-auth

Por padrão, o Edge Microgateway usa um proxy implantado no Apigee Edge para a autenticação OAuth2. Esse proxy é implantado quando você executa edgemicro configure inicialmente. É possível mudar a configuração padrão deste proxy para adicionar suporte para declarações personalizadas a um JSON Web Token (JWT), configure a expiração do token e gere tokens de atualização. Para mais detalhes, consulte a página edgemicro-auth no GitHub.

Como usar um serviço de autenticação personalizado

Por padrão, o Edge Microgateway usa um proxy implantado no Apigee Edge para a autenticação OAuth2. Esse proxy é implantado quando você executa edgemicro configure inicialmente. Por padrão, é especificado no arquivo de configuração do Edge Microgateway da seguinte maneira:

authUri: https://myorg-myenv.apigee.net/edgemicro-auth

Se quiser usar seu próprio serviço personalizado para lidar com a autenticação, altere o Valor authUri no arquivo de configuração para apontar para seu serviço. Por exemplo, você pode ter um serviço que usa LDAP para verificar a identidade.

Como gerenciar arquivos de registro

O Edge Microgateway registra informações sobre cada solicitação e resposta. Os arquivos de registro fornecem informações informações para depuração e solução de problemas.

Onde os arquivos de registro são armazenados

Por padrão, os arquivos de registro são armazenados em /var/tmp.

Como alterar o registro padrão diretório de arquivos

O diretório em que os arquivos de registros são armazenados é especificado na configuração do Edge Microgateway . Consulte também Como realizar a configuração mudanças.

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Altere o valor de dir para especificar um diretório diferente de arquivos de registro.

Enviar registros para o console

É possível configurar o registro de modo que as informações de registro sejam enviadas para a saída padrão em vez de para um do arquivo de registros. Defina a flag to_console como "true" da seguinte maneira:

edgemicro:
  logging:
    to_console: true

Com essa configuração, os registros serão enviados para a saída padrão. Atualmente, não é possível enviar registros para ambos stdout e em um arquivo de registros.

Como definir o nível de geração de registros

Você especifica o nível de registro a ser usado na configuração edgemicro. Para um a lista completa de níveis de registro e as respectivas descrições, consulte atributosedgemicro.

Por exemplo, a configuração a seguir define o nível de geração de registros como debug:

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: debug
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Como alterar intervalos de registro

É possível configurar esses intervalos no arquivo de configuração do Edge Microgateway. Consulte também Como fazer alterações na configuração.

Os atributos configuráveis são:

• stats_log_interval: (padrão: 60) intervalo, em segundos, quando as estatísticas registro é gravado no arquivo de registro da API.
• rotate_interval: (padrão: 24) Intervalo, em horas, quando os arquivos de registro forem girado. Exemplo:

edgemicro:
  home: ../gateway
  port: 8000
  max_connections: -1
  max_connections_hard: -1
  logging:
    level: info
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Como diminuir as permissões rígidas do arquivo de registros

Por padrão, o Edge Microgateway gera o arquivo de registros do aplicativo (api-log.log) com a permissão de arquivo definido como 0600. Este nível de permissão não autoriza usuários ou aplicativos externos para ler o arquivo de registro. Para aliviar esse nível de permissão restrito, defina logging:disableStrictLogFile para true. Quando esse atributo é true, o arquivo de registro é criado com a permissão de arquivo definida como 0755. Se for false ou se o atributo não for fornecido, a permissão será padronizada para 0600.

Adicionado na v3.2.3.

Exemplo:

edgemicro:
 logging:
   disableStrictLogFile: true

Práticas recomendadas de manutenção de arquivos de registros

À medida que os dados dos arquivos de registro se acumulam ao longo do tempo, a Apigee recomenda que você adote as seguintes práticas recomendadas:

• Como os arquivos de registro podem ficar muito grandes, verifique se o diretório do arquivo de registro espaço suficiente. Consulte as seções Onde os arquivos de registro são armazenados e Como alterar o arquivo de registro padrão diretório.
• Exclua ou mova os arquivos de registro para um diretório separado pelo menos uma vez por semana.
• Se a política for excluir registros, use o comando da CLI edgemicro log -c para remover (limpar) registros mais antigos.

Convenção de nomenclatura do arquivo de registros

Cada instância do Edge Microgateway produz um arquivo de registros com uma extensão .log. A para arquivos de registro é a seguinte:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Exemplo:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

Sobre o conteúdo do arquivo de registros

Adicionado à: v2.3.3

Por padrão, o serviço de geração de registros omite o JSON de proxies, produtos e o JSON baixados Web Token (JWT). Se você quiser enviar esses objetos para o console, defina a sinalização de linha de comando DEBUG=* quando você iniciar o Edge Microgateway. Exemplo:

DEBUG=* edgemicro start -o docs -e test -k abc123 -s xyz456

Conteúdo de "api" arquivo de registros

A "API" O arquivo de registros contém informações detalhadas sobre o fluxo de solicitações e respostas pelo Edge Microgateway. A "API" os arquivos de registro têm o seguinte nome:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Em cada solicitação feita ao Edge Microgateway, quatro eventos são capturados na "API" registro arquivo:

• Solicitação recebida do cliente
• Solicitação enviada ao destino
• Resposta de entrada do alvo
• Resposta enviada ao cliente

Cada uma dessas entradas separadas é representada em uma notação abreviada para ajudar a tornar o registro arquivos mais compactos. Aqui estão quatro entradas de exemplo que representam cada um dos quatro eventos. No registro , eles têm esta aparência (os números das linhas servem apenas para referência no documento, não aparecem no arquivo de registro).

(1) 1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
(2) 1436403888665 info treq m=GET, u=/, h=127.0.0.18080, i=0
(3) 1436403888672 info tres s=200, d=7, i=0
(4) 1436403888676 info res s=200, d=11, i=0

Vamos analisar cada um deles:

1. Exemplo de solicitação recebida do cliente:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0

• 1436403888651: carimbo de data do Unix
• info: o nível de geração de registros. Esse valor depende do contexto da transação e do nível de registro definido na configuração de edgemicro. Consulte Como definir o nível de geração de registros. Para registros de estatísticas, o nível é definido como stats. Os registros das estatísticas são reportados em um intervalo regular definido com a configuração stats_log_interval. Consulte também Como alterar intervalos de registro.
• req: identifica o evento. Nesse caso, faça uma solicitação do para o cliente.
• m: o verbo HTTP usado na solicitação.
• u: a parte do URL após o caminho de base.
• h: o host e o número da porta em que o Edge Microgateway está ouvindo.
• r: o host remoto e a porta em que a solicitação do cliente se originou.
• i: o ID da solicitação. As quatro entradas de evento compartilharão esse ID. Cada recebe um ID de solicitação exclusivo. A correlação de registros de log por ID de solicitação pode dar insights valiosos sobre a latência do alvo.
• d: a duração em milissegundos desde o recebimento da solicitação por o Edge Microgateway. No exemplo acima, a resposta do destino para a solicitação 0 foi recebida após 7 milissegundos (linha 3), e a resposta foi enviada ao cliente após mais 4 milésimos de segundo (linha 4). Em outras palavras, a latência total da solicitação foi de 11 milissegundos, quais 7 milissegundos foram usados pelo alvo e 4 milissegundos pelo Edge Microgateway por conta própria.

2. Exemplo de solicitação de saída feita ao destino:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0

• 1436403888651: carimbo de data do Unix
• info: o nível de geração de registros. Esse valor depende do contexto da transação e do nível de registro definido na configuração de edgemicro. Consulte Como definir o nível de geração de registros. Para registros de estatísticas, o nível é definido como stats. Os registros das estatísticas são reportados em um intervalo regular definido com a configuração stats_log_interval. Consulte também Como alterar intervalos de registro.
• treq: identifica o evento. Neste caso, a solicitação de destino.
• m: o verbo HTTP usado na solicitação de destino.
• u: a parte do URL após o caminho de base.
• h: o host e o número da porta do destino do back-end.
• i: o ID da entrada de registro. As quatro entradas de evento compartilharão isso ID.

3. amostra de resposta recebida do alvo

1436403888672 info tres s=200, d=7, i=0

1436403888651: carimbo de data do Unix

• info: o nível de geração de registros. Esse valor depende do contexto da transação e do nível de registro definido na configuração de edgemicro. Consulte Como definir o nível de geração de registros. Para registros de estatísticas, o nível é definido como stats. Os registros das estatísticas são reportados em um intervalo regular definido com a configuração stats_log_interval. Consulte também Como alterar intervalos de registro.
• tres: identifica o evento. Nesse caso, a resposta-alvo.
• s: o status da resposta HTTP.
• d: a duração em milissegundos. O tempo gasto para chamar a API por ao alvo.
• i: o ID da entrada de registro. As quatro entradas de evento compartilharão isso ID.

4. Exemplo de resposta enviada ao cliente

1436403888676 info res s=200, d=11, i=0

1436403888651: carimbo de data do Unix

• info: o nível de geração de registros. Esse valor depende do contexto da transação e do nível de registro definido na configuração de edgemicro. Consulte Como definir o nível de geração de registros. Para registros de estatísticas, o nível é definido como stats. Os registros das estatísticas são reportados em um intervalo regular definido com a configuração stats_log_interval. Consulte também Como alterar intervalos de registro.
• res: identifica o evento. Nesse caso, a resposta ao para o cliente.
• s: o status da resposta HTTP.
• d: a duração em milissegundos. Esse é o tempo total gasto pela chamada de API, incluindo o tempo gasto pela API de destino e o tempo que o Edge leva O próprio Microgateway.
• i: o ID da entrada de registro. As quatro entradas de evento compartilharão isso ID.

Programação do arquivo de registros

Os arquivos de registro são girados no intervalo especificado por rotate_interval. atributo de configuração. As inscrições continuarão sendo adicionadas mesmo arquivo de registro até o intervalo de rotação expirar. No entanto, sempre que o Edge Microgateway for reiniciado, ele recebe um novo UID e cria um novo conjunto de arquivos de registro com esse UID. Consulte também Boa manutenção de arquivos de registro práticas recomendadas de autenticação.

Mensagens de erro

Algumas entradas de registro vão conter mensagens de erro. Para ajudar a identificar onde e por que os erros ocorrem, confira o erro do Edge Microgateway como referência.

Referência de configuração do Edge Microgateway

Local do arquivo de configuração

Os atributos de configuração descritos nesta seção estão no Edge Microgateway de configuração do Terraform. Consulte também Como realizar a configuração mudanças.

Atributos do Edge_config

Essas configurações são usadas para definir a interação entre a instância do Edge Microgateway e Apigee Edge.

• bootstrap: (padrão: nenhum) um URL que aponta para um Edge Serviço específico do microgateway em execução no Apigee Edge. O Edge Microgateway usa esse serviço para se comunicar com o Apigee Edge. Esse URL é retornado quando você executa o comando para gerar o par de chaves públicas/privadas: edgemicro genkeys. Consulte a Configuração e configurar o Edge Microgateway para saber mais.
• jwt_public_key: (padrão: nenhum) um URL que aponta para o Edge Microgateway proxy implantado no Apigee Edge. Esse proxy serve como um endpoint de autenticação para a emissão de tokens de acesso assinados para clientes. Esse URL é retornado quando você executa o comando para implantar o proxy: edgemicro configure. Consulte a Configuração e configurar o Edge Microgateway para saber mais.
• quotaUri: defina essa configuração se quiser gerenciar cotas pelo proxy edgemicro-auth que está implantados na organização. Se a propriedade não for definida, o endpoint de cota usa como padrão o endpoint interno do Edge Microgateway.

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

atributos do Edgemicro

Essas configurações definem o processo do Edge Microgateway.

• port: (padrão: 8000) o número da porta em que o Edge Microgateway o processo de detecção.
• max_connections: (padrão: -1) especifica o número máximo de conexões de entrada simultâneas que o Edge Microgateway pode receber. Se este número for excedido, o seguinte status será retornado:
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard: (padrão: -1) o número máximo de chamadas solicitações que o Edge Microgateway pode receber antes de encerrar a conexão. Esta configuração tem como objetivo frustrar ataques de negação de serviço. Normalmente, defina-o como um número maior que max_connections.
• geração de registros:
  • level: (padrão: erro)
    • info: (recomendado) registra todas as solicitações e respostas que fluem por meio de um Instância do Edge Microgateway.
    • warn: registra apenas mensagens de aviso.
    • error: registra somente mensagens de erro.
    • debug: registra mensagens de depuração, além de mensagens de informação, de aviso e de erro.
    • trace: registra informações de trace de erros, além de mensagens de informação, aviso e erro.
    • none: não cria um arquivo de registros.
  • dir: (padrão: /var/tmp) o diretório onde os arquivos de registro estão armazenados.
  • stats_log_interval: (padrão: 60) intervalo, em segundos, quando as estatísticas record é gravado no arquivo de registro da API.
  • rotate_interval: (padrão: 24) Intervalo, em horas, quando os arquivos de registro forem girado.

• plug-ins: os plug-ins adicionam funcionalidade ao Edge Microgateway. Para mais detalhes sobre o desenvolvimento de plug-ins, consulte Desenvolver plug-ins personalizados.

• dir: um caminho relativo do diretório ./gateway para o ./plugins ou um caminho absoluto.
• sequência: uma lista de módulos de plug-in a serem adicionados ao Edge Microgateway instância. Os módulos serão executados na ordem em que forem especificados aqui.

• debug: adiciona a depuração remota ao processo do Edge Microgateway.
  • port: o número da porta a ser detectada. Por exemplo, defina o depurador do ambiente de desenvolvimento integrado para detectar nessa porta.
  • args: argumentos para o processo de depuração. Por exemplo: args --nolazy
    
• config_change_poll_interval:: (padrão: 600 segundos) Edge Microgateway carrega uma nova configuração periodicamente e executa uma atualização caso algo mude. A enquete pega todas as alterações feitas no Edge (alterações em produtos, proxies com reconhecimento de microgateway etc.) conforme bem como as alterações feitas no arquivo de configuração local.
  
• disable_config_poll_interval:: (padrão: falso) defina como true para desativar a pesquisa automática de alterações.
• request_timeout: define um tempo limite para as solicitações de destino. O tempo limite é definido em segundos. Se ocorrer um tempo limite, o Edge Microgateway responderá com um código de status 504. (Adicionado v2.4.x)
• keep_alive_timeout: esta propriedade permite que você defina o Edge Microgateway tempo limite (em milissegundos). (Padrão: 5 segundos) (Adicionado na v3.0.6)
• headers_timeout: limita o tempo (em milissegundos) deste atributo. o analisador HTTP espera para receber cabeçalhos HTTP completos.

  Exemplo:

  edgemicro:
    keep_alive_timeout: 6000
    headers_timeout: 12000

  Internamente, o parâmetro define o Node.js Server.headersTimeout nas solicitações. (Padrão: 5 segundos a mais que o horário definido com edgemicro.keep_alive_timeout. O padrão impede que balanceadores de carga ou proxies descarreguem erroneamente a conexão.) (Adicionado na v3.1.1)

• noRuleMatchAction: (string) a ação a ser tomada (permitir ou negar o acesso) se o regra de correspondência especificada no plug-in accesscontrol não é resolvida (não tem correspondência). Valores válidos: ALLOW ou DENY Padrão: ALLOW (adicionado: v3.1.7)
• enableAnalytics: (padrão: true) defina o atributo como false para impedir que o plug-in do Google Analytics sejam carregados. Nesse caso, nenhuma chamada para a análise do Apigee Edge será feita. Se definido como true ou quando se esse atributo não for fornecido, o plug-in do Google Analytics funcionará normalmente. Consulte edgemicro para detalhes. (Adicionado na v3.1.8).

  Exemplo:

  edgemicro
    enableAnalytics=false|true

• on_target_response_abort: este atributo permite controlar como o Edge Microgateway se comporta se a conexão entre o cliente (Edge Microgateway) e o servidor de destino fecha prematuramente.

  Valor	Descrição
  Padrão	Se on_target_response_abort não for especificado, o comportamento padrão é truncar a resposta sem mostrar um erro. Nos arquivos de registro, um aviso será mostrada com targetResponse aborted e um código de resposta 502.
  appendErrorToClientResponseBody	O erro personalizado TargetResponseAborted é retornado à para o cliente. Nos arquivos de registro, um aviso será mostrada com targetResponse aborted e um código de resposta 502. Em Além disso, o erro TargetResponseAborted é registrado com a mensagem Target response ended prematurely.
  abortClientRequest	O Edge Microgateway cancela a solicitação e um aviso é gravado nos arquivos de registro: TargetResponseAborted pelo código de status da solicitação 502.

Exemplo:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

atributos de cabeçalhos

Essas configurações definem como certos cabeçalhos HTTP são tratados.

• x-forwarded-for (padrão: true): defina como "falso" para evitar x-forwarded-for passem para o destino. Se um cabeçalho x-forwarded-for estiver na solicitação, o valor será definido como o valor de client-ip no Edge Analytics.
• x-forwarded-host (padrão: verdadeiro): defina como falso para evitar cabeçalhos x-forwarded-host sejam passados para o destino.
• x-request-id (padrão: verdadeiro): defina como falso para evitar x-request-id a serem passados para o destino.
• x-response-time (padrão: true): defina como falso para evitar cabeçalhos x-response-time passados para o destino.
• via: (padrão: true) defina como "false" para impedir que os cabeçalhos sejam passados para o destino.

atributos OAuth

Estas configurações definem como a autenticação do cliente é aplicada pelo Edge Microgateway.

• allowNoAuthorization: (padrão: false) Se definido como verdadeiro, as chamadas de API serão têm permissão para passar pelo Edge Microgateway sem nenhum cabeçalho de autorização. Defina como falso para exigir um cabeçalho de autorização (padrão).
• allowInvalidAuthorization (padrão: false): se definida como "true", as chamadas de API serão tem permissão de transmitir se o token passado no cabeçalho de autorização for inválido ou tiver expirado. Definir isto como falso para exigir tokens válidos (padrão).
• autorização-header: (padrão: autorização: Bearer) o cabeçalho usado para enviar o token de acesso para o Edge Microgateway. É possível alterar o padrão nos casos em que o destino precisa usar o cabeçalho de autorização para outra finalidade.
• api-key-header (padrão: x-api-key): é o nome do cabeçalho ou da consulta. parâmetro usado para transmitir uma chave de API ao Edge Microgateway. Consulte também Como usar uma chave de API.
• keep-authorization-header: (padrão: falso) se for definido como verdadeiro, o cabeçalho de autorização enviado na solicitação é passado para o destino (ele é preservado).
• allowOAuthOnly: se definido como "true", todas as APIs precisarão ter uma autorização com um token de acesso do portador. Permite que você permita apenas o modelo de segurança OAuth (embora e manter a compatibilidade com versões anteriores). (Adicionado 2.4.x)
• allowAPIKeyOnly: se definida como "true", toda API precisa ter um x-api-key (ou um local personalizado) com uma chave de API.Permite que você autorize apenas o modelo de segurança da chave de API (mantendo a compatibilidade com versões anteriores). (Adicionado 2.4.x)
• gracePeriod: esse parâmetro ajuda a evitar erros causados por problemas discrepâncias entre o relógio do seu sistema e os horários de "Não antes" (nbf) ou emitidos em (iat) especificado no token de autorização JWT. Defina esse parâmetro como o número de segundos para permitir para essas discrepâncias. (Adicionado 2.5.7)

Específico do plug-in atributos

Consulte Como usar plug-ins para obter detalhes sobre os atributos configuráveis de cada plug-in.

Como filtrar proxies

É possível filtrar quais proxies com reconhecimento de microgateway uma instância do Edge Microgateway processará. Quando o Edge Microgateway é iniciado, ele faz o download de todos os proxies com reconhecimento de microgateway organização está associado. Use a seguinte configuração para limitar quais proxies o o microgateway será processado. Por exemplo, esta configuração limita os proxies que o microgateway será processada para três: edgemicro_proxy-1, edgemicro_proxy-2, e edgemicro_proxy-3:

edgemicro:
  proxies:
  - edgemicro_proxy-1
  - edgemicro_proxy-2
  - edgemicro_proxy-3

Filtrar produtos por nome

Use a configuração a seguir para limitar o número de produtos de API que o Edge Microgateway downloads e processos. Para filtrar os produtos transferidos por download, adicione o productnamefilter. Parâmetro de consulta para a API /products listada no Edge Microgateway *.config.yaml . Exemplo:

edge_config:
  bootstrap: >-
    https://edgemicroservices.apigee.net/edgemicro/bootstrap/organization/willwitman/environment/test
  jwt_public_key: 'https://myorg-test.apigee.net/edgemicro-auth/publicKey'
  managementUri: 'https://api.enterprise.apigee.com'
  vaultName: microgateway
  authUri: 'https://%s-%s.apigee.net/edgemicro-auth'
  baseUri: >-
    https://edgemicroservices.apigee.net/edgemicro/%s/organization/%s/environment/%s
  bootstrapMessage: Please copy the following property to the edge micro agent config
  keySecretMessage: The following credentials are required to start edge micro
  products: 'https://myorg-test.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24'

O valor do parâmetro de consulta deve ser especificado no formato de expressão regular e ter codificação URL. Por exemplo, a regex ^[Ee]dgemicro.*$ captura nomes como: “edgemicro-test-1” "edgemicro_demo" e "Edgemicro_New_Demo". O valor codificado para URL, adequado para usar no parâmetro de consulta, é: %5E%5BEe%5Ddgemicro.%2A%24.

A saída de depuração a seguir mostra que apenas os produtos filtrados foram transferidos por download:

...
2020-05-27T03:13:50.087Z [76060] [microgateway-config network] products download from https://gsc-demo-prod.apigee.net/edgemicro-auth/products?productnamefilter=%5E%5BEe%5Ddgemicro.%2A%24 returned 200 OK
...
....
....
{
   "apiProduct":[
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590549037549,
         "createdBy":"k***@g********m",
         "displayName":"test upper case in name",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590549037549,
         "lastModifiedBy":"k***@g********m",
         "name":"Edgemicro_New_Demo",
         "proxies":[
            "catchall"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[

         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1590548328998,
         "createdBy":"k***@g********m",
         "displayName":"edgemicro test 1",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1590548328998,
         "lastModifiedBy":"k***@g********m",
         "name":"edgemicro-test-1",
         "proxies":[
            "Lets-Encrypt-Validation-DoNotDelete"
         ],
         "quota":"null",
         "quotaInterval":"null",
         "quotaTimeUnit":"null",
         "scopes":[

         ]
      },
      {
         "apiResources":[
            "/",
            "/**"
         ],
         "approvalType":"auto",
         "attributes":[
            {
               "name":"access",
               "value":"public"
            }
         ],
         "createdAt":1558182193472,
         "createdBy":"m*********@g********m",
         "displayName":"Edge microgateway demo product",
         "environments":[
            "prod",
            "test"
         ],
         "lastModifiedAt":1569077897465,
         "lastModifiedBy":"m*********@g********m",
         "name":"edgemicro_demo",
         "proxies":[
            "edgemicro-auth",
            "edgemicro_hello"
         ],
         "quota":"600",
         "quotaInterval":"1",
         "quotaTimeUnit":"minute",
         "scopes":[

         ]
      }
   ]
}

Como filtrar produtos por atributos personalizados

Para filtrar produtos com base em atributos personalizados:

1. Na IU do Edge, selecione o proxy edgemicro_auth na organização/ambiente. em que você configurou o Edge Microgateway.
2. No toque em "Desenvolver", abra a política Javacall no editor.
3. Adicione um atributo personalizado com a chave products.filter.attributes separados por vírgulas lista de nomes de atributos. Somente produtos que contenham qualquer um dos nomes de atributos personalizados serão retornados para o Edge Microgateway.
4. É possível desativar a verificação para ver se o produto está ativado para o ambiente atual definindo o atributo personalizado products.filter.env.enable para false. O padrão é "true".
5. (Apenas nuvem privada) Se você estiver no Edge para a nuvem privada, defina a propriedade org.noncps para true para extrair produtos para ambientes não CPS.

Exemplo:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout async="false" continueOnError="false" enabled="true" name="JavaCallout">
    <DisplayName>JavaCallout</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="products.filter.attributes">attrib.one, attrib.two</Property>
        <Property name="products.filter.env.enable">false</Property>
        <Property name="org.noncps">true</Property>
    </Properties>
    <ClassName>io.apigee.microgateway.javacallout.Callout</ClassName>
    <ResourceURL>java://micro-gateway-products-javacallout-2.0.0.jar</ResourceURL>
</JavaCallout>

Como configurar a frequência de push da análise

Use estes parâmetros de configuração para controlar a frequência com que o Edge Microgateway envia dados de análise para a Apigee:

• bufferSize (opcional): o número máximo de registros de análise que o o buffer pode conter antes de começar a descartar os registros mais antigos. Padrão: 10.000
• batchSize (opcional): o tamanho máximo de um lote de registros de análise enviados para a Apigee. Padrão: 500
• flushInterval (opcional): o número de milissegundos entre cada limpeza do um lote de registros analíticos enviados para a Apigee. Padrão: 5000

Exemplo:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Mascaramento de dados de análise

A configuração a seguir impede que as informações do caminho da solicitação apareçam no Edge análise de dados em nuvem. Adicione o seguinte à configuração do microgateway para mascarar o URI de solicitação e/ou caminho da solicitação. Observe que o URI consiste nas partes do nome do host e do caminho da solicitação.

analytics:
  mask_request_uri: 'string_to_mask'
  mask_request_path: 'string_to_mask'

Como separar chamadas de API no Edge Analytics

Você pode configurar o plug-in do Google Analytics para separar um caminho de API específico de forma que ele apareça como um proxy separado nos painéis do Edge Analytics. Por exemplo, é possível segregar uma API de verificação de integridade no painel para evitar confundi-la com chamadas reais de proxy de API; Na No painel de análise de dados, os proxies segregados seguem este padrão de nomenclatura:

edgemicro_proxyname-health

A imagem a seguir mostra dois proxies segregados no painel do Google Analytics: edgemicro_hello-health e edgemicro_mock-health:

Use estas para segregar caminhos relativos e absolutos no painel do Google Analytics como proxies diferentes:

• relativePath (opcional): especifica um caminho relativo para segregar no painel do Analytics. Por exemplo, se você especificar /healthcheck, todas as chamadas de API que tiverem o caminho /healthcheck vai aparecer no painel como edgemicro_proxyname-health. Essa sinalização ignora o caminho base do proxy. Para segregar com base em um caminho completo, incluindo o caminho de base, use a sinalização proxyPath.
• proxyPath (opcional): especifica um caminho completo do proxy de API, incluindo o proxy caminho de base, para segregar no painel de análise. Por exemplo, se você especificar /mocktarget/healthcheck, em que /mocktarget for o caminho base do proxy, todas as chamadas de API com o caminho /mocktarget/healthcheck aparecem no painel como edgemicro_proxyname-health.

Por exemplo, na configuração a seguir, qualquer caminho de API que contenha /healthcheck será ser segregados pelo plug-in do Google Analytics. Isso significa que /foo/healthcheck e /foo/bar/healthcheck serão segregados como um proxy separado chamado edgemicro_proxyname-health no painel de análise.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  relativePath: /healthcheck

Na configuração a seguir, qualquer API com o caminho de proxy /mocktarget/healthcheck será segregado como um proxy separado chamado edgemicro_proxyname-health em no painel de análise.

analytics:
  uri: >-
    https://xx/edgemicro/ax/org/docs/environment/test
  bufferSize: 100
  batchSize: 50
  flushInterval: 500
  proxyPath: /mocktarget/healthcheck

Como configurar o Edge Microgateway em um firewall da empresa

Usar um proxy HTTP para comunicação com o Apigee Edge

Adicionado na versão 3.1.2.

Para usar um proxy HTTP para comunicação entre o Edge Microgateway e o Apigee Edge, faça o seguinte:

1. Defina as variáveis de ambiente HTTP_PROXY, HTTPS_PROXY e NO_PROXY. Esses de controle controlam os hosts de cada proxy HTTP que você quer usar para comunicação com Apigee Edge ou quais hosts não devem processar a comunicação com o Apigee Edge. Exemplo:

   export HTTP_PROXY='http://localhost:3786'
   export HTTPS_PROXY='https://localhost:3786'
   export NO_PROXY='localhost,localhost:8080'

   Observe que NO_PROXY pode ser uma lista de domínios delimitados por vírgulas que o Edge Microgateway não devem servir como proxy.

   Para mais informações sobre essas variáveis, consulte https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables (em inglês)

2. Reinicie o Edge Microgateway.

Usar um proxy HTTP para comunicação de destino

Adicionado na versão 3.1.2.

Para usar um proxy HTTP na comunicação entre o Edge Microgateway e os destinos de back-end, siga estas etapas: faça o seguinte:

1. Adicione a seguinte configuração ao arquivo de configuração do microgateway:

   edgemicro:
     proxy:
       tunnel: true | false
       url: proxy_url
       bypass: target_host # target hosts to bypass the proxy.
       enabled: true | false

   Em que:

   • tunnel: (opcional) quando verdadeiro, o Edge Microgateway usa o método HTTP CONNECT para encapsular o HTTP. solicitações em uma única conexão TCP. O mesmo acontece se as variáveis de ambiente, mencionadas abaixo, para configurar o proxy são TLS ativado). Padrão: false
   • url: o URL do proxy HTTP.
   • bypass: (opcional) especifica um ou mais URLs de host de destino separados por vírgula que deve ignorar o proxy HTTP. Se esta propriedade não for definida, use o operador variável de ambiente para especificar quais URLs de destino devem ser ignorados.
   • enabled: se verdadeiro e proxy.url estiver definido, use o valor proxy.url para o proxy HTTP. Se verdadeiro e proxy.url não estiver definido, use os proxies especificados no proxy HTTP variáveis de ambiente HTTP_PROXY e HTTPS_PROXY, conforme descrito em Usar um proxy HTTP para comunicação com o Apigee Edge.

   Exemplo:

   edgemicro:
     proxy:
       tunnel: true
       url: 'http://localhost:3786'
       bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
       enabled: true

2. Reinicie o Edge Microgateway.

Como usar caracteres curinga com reconhecimento de microgateway proxies

Você pode usar um ou mais caracteres "*" caracteres curinga no caminho base de uma edgemicro_* (com reconhecimento de microgateway). Por exemplo, um caminho base de /team/*/members permite que os clientes liguem para https://[host]/team/blue/members e https://[host]/team/green/members sem precisar criar novos proxies de API para apoiar novas equipes. Observe que /**/ não é compatível.

Importante: a Apigee NÃO é compatível com o uso de um caractere curinga "*" como primeiro elemento de um caminho base. Por exemplo, isto NÃO é compatível: a pesquisa /*/.

Como fazer a rotação de chaves JWT

Em algum momento após a geração inicial de um JWT, talvez seja necessário alterar o par de chaves públicas/privadas armazenado na KVM criptografada de borda. Esse processo de gerar uma nova chave é chamado de rotação de chaves.

Como o Edge Microgateway usa JWTs

JSON Web Token (JWT) é um padrão de token descrito em RFC7519. O JWT é uma maneira de assinar um conjunto de declarações, que podem ser verificados com segurança pelo destinatário do JWT.

É possível gerar um JWT usando a CLI e usá-lo no Cabeçalho de autorização de chamadas de API em vez de uma chave de API. Exemplo:

curl -i http://localhost:8000/hello -H "Authorization: Bearer eyJhbGciOiJ..dXDefZEA"

Para informações sobre como gerar JWTs com a CLI, consulte Gerar um token.

O que é a rotação de chaves?

Em algum momento após a geração inicial de um JWT, talvez seja necessário alterar o par de chaves públicas/privadas armazenado na KVM criptografada de borda. Esse processo de gerar uma nova chave é chamado de rotação de chaves. Quando você faz a rotação das chaves, um novo par de chaves privada/pública é gerado e armazenadas no "microgateway" KVM na sua organização/ambiente do Apigee Edge. Além disso, a chave pública antiga é mantida com seu valor de ID de chave original.

Para gerar um JWT, o Edge usa as informações armazenadas na KVM criptografada. Um A KVM chamada microgateway foi criada e preenchida com chaves quando você a definiu (configurado). o Edge Microgateway. As chaves na KVM são usadas para assinar e criptografar um JWT.

As chaves KVM incluem:

• private_key: a chave privada RSA mais recente (criada mais recentemente) usada para assinar JWTs

• public_key: o certificado mais recente (criado mais recentemente) usado para verificar JWTs assinado com private_key.

• private_key_kid: o ID da chave privada mais recente (criado mais recentemente). Este ID de chave está associado ao valor private_key e é usado para oferecer suporte à rotação de chaves.

• public_key1_kid: o ID da chave pública mais recente (criado mais recentemente). Essa chave é associado ao valor public_key1 e é usado para dar suporte à rotação de chaves. Esse valor é a mesma que a chave privada filha.

• public_key1: a chave pública mais recente (criada mais recentemente).

Quando você executa a rotação de chaves, as chaves-valor atuais são substituídas no mapa e as novas são adicionadas para manter as chaves públicas antigas. Exemplo:

• public_key2_kid: o ID antigo da chave pública. Essa chave está associada ao public_key2 e é usado para dar suporte à rotação de chaves.

• public_key2: a chave pública antiga.

Os JWTs apresentados para verificação serão verificados com a nova chave pública. Se a verificação falhar, a chave pública antiga será usada até que o JWT expire (após o intervalo token_expiry*, o padrão é 30 minutos). Em Dessa forma, você pode "girar" sem interromper imediatamente o tráfego da API.

Como fazer a rotação de chaves

Nesta seção, explicamos como executar uma rotação de chaves.

1. Para fazer upgrade da KVM, use o comando edgemicro upgradekvm. Para mais detalhes sobre como executar esse comando, consulte Como fazer upgrade da KVM. Você só precisa realizar essa etapa uma vez.
2. Para fazer upgrade do proxy edgemicro-oauth, use o comando edgemicro upgradeauth. Para obter detalhes sobre como executar este comando, consulte Faça upgrade do proxy Edgemicro-auth. Você só precisa realizar essa etapa uma vez.
3. Adicione a linha abaixo ao arquivo ~/.edgemicro/org-env-config.yaml, em que você precisa: Especifique a mesma organização e o mesmo ambiente que você configurou para usar o microgateway:

   jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'

4. Execute o comando de rotação para alternar as chaves. Para mais detalhes sobre esse comando, consulte Rotação de chaves.

   edgemicro rotatekey -o $ORG -e $ENV -k $KEY -s $SECRET

   Exemplo:

   edgemicro rotatekey -o docs -e test \
   -k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
   -s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47
   

Após a rotação de chaves, o Edge retorna várias chaves para o Edge Microgateway. Na exemplo a seguir, cada chave tem um atributo "criança" exclusivo (ID da chave). O microgateway usa essas para validar tokens de autorização. Se a validação do token falhar, o microgateway procurará verifica se há uma chave mais antiga no conjunto de chaves e tenta essa chave. O formato do é a JSON Web Key (JWK). Você pode ler sobre esse formato no RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

Configurar um "não antes" atraso

Nas versões 3.1.5 e anteriores, a nova chave privada gerada pelo comando rotatekey entra em vigor imediatamente, e os novos tokens gerados são assinados com a nova chave privada. No entanto, a nova chave pública só foi disponibilizada para instâncias do Edge Microgateway a cada 10 minutos (por padrão); quando a configuração do microgateway foi atualizada. Por causa desse atraso entre a assinatura do token e a atualização da instância de microgateway, os tokens assinados com a chave mais recente seriam rejeitados até todas as instâncias receberam a chave pública mais recente.

Nos casos em que há várias instâncias de microgateway, o atraso da chave pública às vezes resultava em erros intermitentes de tempo de execução com status 403, porque a validação do token passaria instância, mas falha em outra até que todas tenham sido atualizadas.

A partir da versão 3.1.6, uma nova flag no comando rotatekey permite especificar um atraso para o novo a chave privada se torna eficaz, permitindo tempo para que todas as instâncias de microgateway sejam atualizadas e receber a nova chave pública. A nova flag é --nbf, que significa "não antes". Essa sinalização usa um valor inteiro, o número de minutos de atraso.

No exemplo a seguir, o atraso é definido como 15 minutos:

edgemicro rotatekey -o docs -e test \
-k 27ee39567c75e4567a66236cbd4e86d1cc93df6481454301bd5fac4d3497fcbb \
-s 4618b0008a6185d7327ebf53bee3c50282ccf45a3cceb1ed9828bfbcf1148b47 \
--nbf 15

Uma prática recomendada é definir o atraso para um valor maior do que a configuração do config_change_poll_internal. que é 10 minutos por padrão. Consulte também atributosedgemicro.

Como filtrar proxies baixados

Por padrão, o Edge Microgateway faz o download de todos os proxies na sua organização de Edge que começam com o prefixo de nomenclatura "edgemicro_". É possível alterar esse padrão para fazer o download de proxies cujos nomes correspondem a um padrão.

1. Abra o arquivo de configuração do Edge Micro: ~/.edgemicro/org-env-config.yaml
2. Adicione o elemento proxyPattern em Edge_config. Por exemplo, o padrão a seguir de download de proxies, como Edgemicro_foo, Edgemicro_fast e Edgemicro_first.

   edge_config:
   …
   proxyPattern: edgemicro_f*

Como especificar produtos sem proxies de API

No Apigee Edge, é possível criar um produto de API que não contenha proxies de API. Essa configuração de produto permite que uma chave de API associada ao produto funcione com qualquer proxy implantado na sua organização. A partir da versão 2.5.4, o Edge Microgateway é compatível com este produto configuração do Terraform.

Como depurar e solucionar problemas

Como se conectar a um depurador

É possível executar o Edge Microgateway com um depurador, como o node-inspector. Isso é útil para solução de problemas e depuração de plug-ins personalizados.

1. Reiniciar o Edge Microgateway no modo de depuração. Para fazer isso, adicione DEBUG=* ao começo do comando start:

   DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

   .

   Para direcionar a saída de depuração a um arquivo, use este comando:

   export DEBUG=* nohup edgemicro start \
   -o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log

2. Inicie o depurador e configure-o para detectar o número da porta no processo de depuração.
3. Agora é possível percorrer o código do Edge Microgateway, definir pontos de interrupção, expressões de observação, e assim por diante.

É possível especificar sinalizações padrão do Node.js relacionadas ao modo de depuração. Por exemplo: --nolazy ajuda com a depuração do código assíncrono.

Como verificar arquivos de registro

Se você estiver com problemas, examine os arquivos de registro para conferir detalhes de execução e erros informações imprecisas ou inadequadas. Para detalhes, consulte Como gerenciar arquivos de registro.

Como usar a segurança da chave de API

As chaves de API oferecem um mecanismo simples para autenticar clientes que fazem solicitações ao Edge Microgateway Você pode conseguir uma chave de API copiando o valor da chave do cliente (também chamado de ID do cliente) de um produto do Apigee Edge que inclui o proxy de autenticação do Edge Microgateway.

Armazenamento em cache de chaves

As chaves de API são trocadas por tokens do portador, que são armazenados em cache. Para desativar o armazenamento em cache, defina o cabeçalho Cache-Control: no-cache nas solicitações recebidas no Edge; Microgateway

Como usar uma chave de API

Você pode passar a chave de API em uma solicitação de API como um parâmetro de consulta ou em um cabeçalho. Por padrão, o cabeçalho e o nome do parâmetro de consulta são x-api-key;

Exemplo de parâmetro de consulta:

curl http://localhost:8000/foobar?x-api-key=JG616Gjz7xs4t0dvpvVsGdI49G34xGsz

Exemplo de cabeçalho:

curl http://localhost:8000/foobar -H "x-api-key:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Como configurar o nome da chave de API

Por padrão, x-api-key é o nome usado para o cabeçalho da chave de API e o parâmetro de consulta. Você pode alterar esse padrão no arquivo de configuração, conforme explicado em Como fazer alterações na configuração. Por exemplo, para alterar nome para apiKey:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  api-key-header: apiKey

Neste exemplo, o parâmetro de consulta e o nome do cabeçalho são alterados para apiKey. A x-api-key não vão mais funcionar em nenhum dos casos. Consulte também Como fazer alterações na configuração.

Exemplo:

curl http://localhost:8000/foobar -H "apiKey:JG616Gjz7xs4t0dvpvVsGdI49G34xGsz"

Para mais informações sobre como usar chaves de API com solicitações de proxy, consulte Secure Edge Microgateway

Ativar códigos de resposta upstream

Por padrão, o plug-in oauth retornará apenas códigos de status de erro 4xx se a resposta não for um status 200. Você pode alterar esse comportamento para que ele sempre retorna o código 4xx ou 5xx exato, dependendo do erro.

Para ativar esse recurso, adicione o oauth.useUpstreamResponse: true para a configuração do Edge Microgateway. Exemplo:

oauth:
  allowNoAuthorization: false
  allowInvalidAuthorization: false
  gracePeriod: 10
  useUpstreamResponse: true

Como usar a segurança do token OAuth2

Esta seção explica como obter tokens de acesso OAuth2 e tokens de atualização. Os tokens de acesso são usados chamadas de API seguras pelo microgateway. Os tokens de atualização são usados para obter novos tokens de acesso.

Como receber um token de acesso

Esta seção explica como usar o proxy edgemicro-auth para receber um token de acesso.

Também é possível receber um token de acesso usando o comando edgemicro token da CLI. Para detalhes sobre a CLI, consulte Como gerenciar tokens.

API 1: enviar credenciais como parâmetros de corpo

Substitua os nomes da organização e do ambiente no URL e substitua os valores de ID e de chave secreta do cliente recebidos de um app de desenvolvedor na Apigee Borda dos parâmetros de corpo client_id e client_secret:

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2: enviar credenciais em um cabeçalho de autenticação básica

Envie as credenciais do cliente como um cabeçalho de Autenticação básica e o grant_type como um parâmetro de formulário. Esse formulário de comando também é discutido RFC 6749: o framework de autorização do OAuth 2.0 (em inglês).

http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

Exemplo de saída

{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": 1799
}

Como receber um token de atualização

Para obter um token de atualização, faça uma chamada de API para o endpoint /token do proxy edgemicro-auth. Você PRECISA fazer essa chamada de API com password. tipo de concessão. As etapas a seguir percorrem o processo.

1. Receba um token de acesso e atualização com a API /token. Observe que o tipo de concessão é password:

   curl -X POST \
     https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
      "client_secret":"bUdDcFgv3nXffnU",
      "grant_type":"password",
      "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
      "password":"bUdD2FvnMsXffnU"
   }'

   A API retorna um token de acesso e um token de atualização. A resposta é semelhante a isso. Observe que expires_in valores inteiros e são especificados em segundos.

   {
       "token": "your-access-token",
       "access_token": "your-access-token",
       "token_type": "bearer",
       "expires_in": 108,
       "refresh_token": "your-refresh-token",
       "refresh_token_expires_in": 431,
       "refresh_token_issued_at": "1562087304302",
       "refresh_token_status": "approved"
   }

2. Agora é possível usar o token de atualização para obter um novo token de acesso chamando o endpoint /refresh da mesma API. Exemplo:

   curl -X POST \
     https://willwitman-test.apigee.net/edgemicro-auth/refresh \
     -H 'Content-Type: application/json' \
     -d '{
      "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
      "client_secret":"bUdDc2Fv3nMXffnU",
      "grant_type":"refresh_token",
      "refresh_token":"your-refresh-token"
   }'

   A API retorna um novo token de acesso. A resposta será semelhante a esta:

   {
       "token": "your-new-access-token"
       }

Monitoramento contínuo

Como especificar um endpoint do arquivo de configuração

Se você executa várias instâncias do Edge Microgateway, talvez queira gerenciar as configurações delas de um único local. Para isso, especifique um endpoint HTTP em que o Edge Micro possa fazer o download do arquivo de configuração. Você pode especificar esse endpoint ao iniciar o Edge Micro usando a sinalização -u.

Exemplo:

edgemicro start -o jdoe -e test -u http://mylocalserver/mgconfig -k public_key -s secret_key

em que o ponto de extremidade mgconfig retorna o conteúdo do seu arquivo de configuração. Este é o arquivo que, por padrão, está localizado em ~/.edgemicro e tem a convenção de nomenclatura: org-env-config.yaml.

Como desativar o armazenamento em buffer de dados de conexão TCP

É possível usar o atributo de configuração nodelay para desativar o armazenamento em buffer de Conexões TCP usadas pelo Edge Microgateway.

Por padrão, as conexões TCP usam o protocolo Nagle algoritmo para armazenar os dados em buffer antes de enviá-los. Definindo nodelay como true, desativa esse comportamento (os dados disparam imediatamente cada vez que socket.write() é chamado). Consulte também a documentação do Node.js documentação para saber mais.

Para ativar nodelay, edite o arquivo de configuração do Edge Micro da seguinte maneira:

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Como executar o Edge Microgateway no modo autônomo

É possível executar o Edge Microgateway completamente desconectado de qualquer Dependência do Apigee Edge. Esse cenário, chamado de modo autônomo, permite executar e testar o Edge Microgateway sem conexão com a Internet.

No modo independente, os seguintes recursos não funcionam porque exigem conexão ao Apigee Edge:

• OAuth e chave de API
• Cota
• Analytics

Por outro lado, plug-ins personalizados e detenção de pico funcionam normalmente, exigem conexão com o Apigee Edge. Além disso, um novo plug-in chamado extauth permite autorizar chamadas de API para o microgateway com um JWT no modo autônomo.

Como configurar e iniciar o gateway

Para executar o Edge Microgateway no modo autônomo:

1. Crie um arquivo de configuração chamado da seguinte maneira: $HOME/.edgemicro/$ORG-$ENV-config.yaml

   Exemplo:

   vi $HOME/.edgemicro/foo-bar-config.yaml

2. Cole o código a seguir no arquivo:

   edgemicro:
     port: 8000
     max_connections: 1000
     config_change_poll_interval: 600
     logging:
       level: error
       dir: /var/tmp
       stats_log_interval: 60
       rotate_interval: 24
     plugins:
       sequence:
         - extauth
         - spikearrest
   headers:
     x-forwarded-for: true
     x-forwarded-host: true
     x-request-id: true
     x-response-time: true
     via: true
   extauth:
     publickey_url: https://www.googleapis.com/oauth2/v1/certs
   spikearrest:
     timeUnit: second
     allow: 10
     buffersize: 0

3. Exporte a seguinte variável de ambiente com o valor "1":

   export EDGEMICRO_LOCAL=1

4. Execute o comando start a seguir, em que você fornece valores para instanciar a proxy local:

   edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
     -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

   Em que:

   • $ORG é a "organização" que você usou no nome do arquivo de configuração.
   • $ENV é o "env". nome usado no arquivo de configuração nome.
   • $LOCAL_PROXY_NAME é o nome do proxy local que será criado. Você pode usar qualquer nome que quiser.
   • $LOCAL_PROXY_VERSION é o número da versão do proxy.
   • $TARGET_URL é o URL do destino do proxy. O objetivo é o que o proxy chama.
   • $BASE_PATH é o caminho base do proxy. Esse valor precisa começar com barra. Para um caminho base raiz, especifique apenas uma barra. por exemplo, "/".

   Exemplo:

   edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

5. Testar a configuração.

   curl http://localhost:8000/echo  { "error" : "missing_authorization" }

   Como o plug-in extauth está no arquivo foo-bar-config.yaml, você receber uma "missing_authorization" erro. Este plug-in valida um JWT que precisa estar presente no arquivo de cabeçalho da chamada de API. Na próxima seção, você vai encontrar um JWT que permita chamadas de API passar sem o erro.

Exemplo: como receber um token de autorização

O exemplo a seguir mostra como receber um JWT do endpoint JWT do Edge Microgateway na Apigee Edge (edgemicro-auth/jwkPublicKeys). Esse endpoint é implantado quando você executa uma configuração e configuração padrão do Edge Microgateway. Para receber o JWT do endpoint da Apigee, primeiro faça a configuração padrão do Edge Microgateway e conectado à Internet. O endpoint da Apigee é usado aqui para fins de exemplo e não é obrigatório. É possível usar outro endpoint de token JWT, se quiser. Se fizer isso, você precisará obter o JWT usando a API fornecida para o endpoint.

As etapas a seguir explicam como receber um token usando o endpoint edgemicro-auth/jwkPublicKeys.

1. Você deve realizar uma configuração configuração do Edge Microgateway para implantar o proxy edgemicro-auth à organização/ao ambiente no Apigee Edge. Se você já realizou essa etapa anteriormente, não é necessário repeti-la.
2. Se você implantou o Edge Microgateway na Apigee Cloud, precisa estar conectado à Internet para receber um JWT desse endpoint.
3. Parar o Edge Microgateway:

   edgemicro stop

4. No arquivo de configuração que você criou anteriormente ($HOME/.edgemicro/org-env-config.yaml), apontar extauth:publickey_url ao endpoint edgemicro-auth/jwkPublicKeys na organização/ambiente do Apigee Edge. Exemplo:

   extauth:
     publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'

5. Reinicie o Edge Microgateway como antes, usando os nomes de organização/ambiente usados no nome do arquivo de configuração. Exemplo:

   edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /

6. Receba um token JWT do endpoint de autorização. Porque você está usando o edgemicro-auth/jwkPublicKeys use este comando da CLI:

É possível gerar um JWT para o Edge Microgateway usando o comando edgemicro token ou uma API. Exemplo:

edgemicro token get -o your_org -e your_env \
  -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Em que:

• your_org é o nome da organização da Apigee que você já conhece. o Edge Microgateway configurado.
• your_env é um ambiente na organização.
• A opção i especifica a chave do cliente de um app do desenvolvedor que tem um produto. que inclui o proxy edgemicro-auth.
• A opção s especifica o segredo do cliente de um aplicativo de desenvolvedor que tem um que inclui o proxy edgemicro-auth.

Esse comando solicita que o Apigee Edge gere um JWT que possa ser usado para verificar a API chamadas.

Testar a configuração autônoma

Para testar a configuração, chame a API com o token adicionado no cabeçalho "Authorization" da seguinte maneira:

curl http://localhost:8000/echo -H "Authorization: Bearer your_token

Exemplo:

curl http://localhost:8000/echo -H "Authorization: Bearer eyJraWQiOiIxIiwidHlwIjo...iryF3kwcDWNv7OQ"

Exemplo de saída:

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

Como usar o modo de proxy local

No modo de proxy local, o Edge Microgateway não precisa de uma proxy microgateway-aware sejam implantados no Apigee Edge. Em vez disso, configure um "proxy local" fornecendo um nome de proxy local, caminho de base e URL de destino iniciar o microgateway. As chamadas de API para o microgateway são enviadas para o destino URL do proxy local. Em todos os outros aspectos, o modo de proxy local funciona exatamente da mesma forma que a execução O Edge Microgateway está no modo normal. A autenticação funciona da mesma maneira, assim como o pico aplicação de cotas e restrições, plug-ins personalizados e assim por diante.

Caso de uso e exemplo

O modo de proxy local é útil quando você só precisa associar um único proxy a um Edge Microgateway instância. Por exemplo, é possível injetar o Edge Microgateway no Kubernetes como um proxy de arquivo secundário, em que um um microgateway e um serviço são executados em um único pod e em que o microgateway gerencia o tráfego para e do serviço de acompanhamento. A figura a seguir ilustra essa arquitetura em que o Edge O microgateway funciona como um proxy de arquivo secundário em um cluster do Kubernetes. Cada instância de microgateway se comunica a apenas um endpoint no serviço complementar:

Um benefício desse estilo de arquitetura é que o Edge Microgateway fornece APIs gerenciamento de serviços individuais implantados em um ambiente de contêiner, como em um cluster do Kubernetes.

Como configurar o modo de proxy local

Para configurar o Edge Microgateway para ser executado no modo de proxy local, siga estas etapas:

1. Execute edgemicro init para definir seu ambiente de configuração local, exatamente como você faria em uma configuração típica do Edge Microgateway. Consulte também Configurar o Edge Microgateway.
2. Execute edgemicro configure, como você faria em uma configuração típica do Edge Microgateway procedimento Exemplo:

   edgemicro configure -o your_org -e your_env -u your_apigee_username

   Esse comando implanta a política edgemicro-auth no Edge e retorna uma chave e o segredo necessário para iniciar o microgateway. Se precisar de ajuda, consulte Configurar o Edge Microgateway.

3. No Apigee Edge, crie um produto de API com a seguinte configuração obrigatória (você pode gerenciar todas as outras configurações como quiser):
   • Você precisa adicionar o proxy edgemicro-auth ao produto. Este proxy foi implantado automaticamente quando você executou edgemicro configure.
   • Você precisa fornecer um caminho de recurso. A Apigee recomenda adicionar esse caminho o produto: /**. Para saber mais, consulte Configurar o comportamento do caminho do recurso. Consulte também Criar API produtos na documentação do Edge.

4. No Apigee Edge, crie um desenvolvedor ou use um desenvolvedor atual desejo. Para receber ajuda, consulte Como adicionar desenvolvedores usando a interface de gerenciamento de borda.

5. No Apigee Edge, crie um app de desenvolvedor. Você precisa adicionar o produto de API que que acabou de ser criada no app. Para receber ajuda, consulte Como registrar um aplicativo no Edge de gerenciamento de conteúdo.
6. Na máquina em que o Edge Microgateway está instalado, exporte o seguinte com o valor "1".

   export EDGEMICRO_LOCAL_PROXY=1

7. Execute o seguinte comando start:

   edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
       -a local_proxy_name -v local_proxy_version -t target_url -b base_path

   Em que:

   • your_org é sua organização da Apigee.
   • your_environment é um ambiente na sua organização.
   • your_key é a chave retornada quando você executou edgemicro configure.
   • your_secret é o secret retornado durante a execução. edgemicro configure.
   • local_proxy_name é o nome do proxy local que será criado.
   • local_proxy_version é o número da versão do proxy.
   • target_url é o URL do destino do proxy (o serviço que o proxy ).
   • base_path é o caminho base do proxy. Esse valor precisa começar com barra. Para um caminho base raiz, especifique apenas uma barra. por exemplo, "/".

   Exemplo:

   edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
     -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
     -t http://mocktarget.apigee.net -b /echo

Como testar a configuração

Você pode testar a configuração do proxy local chamando o endpoint do proxy. Por exemplo: Se você especificou um caminho de base de /echo, chame o proxy da seguinte maneira:

curl  http://localhost:8000/echo
{
  "error" : "missing_authorization",
  "error_description" : "Missing Authorization header"
}

Esta chamada de API inicial gerou um erro porque você não forneceu uma chave de API válida. Encontre a chave no app do desenvolvedor criado anteriormente. Abra o app na interface do Edge e copie a chave do cliente e use-a da seguinte maneira:

curl  http://localhost:8000/echo -H 'x-api-key:your_api_key'

Exemplo:

curl  http://localhost:8000/echo -H "x-api-key:DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP"

Exemplo de saída:

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}

Como usar o sincronizador

Esta seção explica como usar o sincronizador, um recurso opcional que aumenta a resiliência do Edge Microgteway, para recuperar dados de configuração do Apigee Edge e gravá-los em um banco de dados local do Redis. Com uma instância do sincronizador em execução e outras instâncias do Edge Microgateway em execução em nós diferentes podem recuperar a configuração diretamente desse banco de dados.

Atualmente, o recurso sincronizador funciona com o Redis 5.0.x.

O que é o sincronizador?

O sincronizador fornece um nível de resiliência para o Edge Microgateway. Ele ajuda a garantir que todas as instâncias do Edge Microgateway usem a mesma configuração em caso de interrupção da Internet, as instâncias do Edge Microgateway podem ser iniciadas e executadas corretamente.

Por padrão, as instâncias do Edge Microgateway precisam se comunicar com o Apigee Edge para recuperar e atualizar os dados de configuração, como as configurações do proxy de API e do produto da API. Se a conexão de Internet com o Edge for interrompida, as instâncias de microgateway poderão continuar porque os dados de configuração mais recentes são armazenados em cache. No entanto, as novas instâncias de microgateway não é possível iniciar sem uma conexão nítida. Além disso, é possível que um site interrupção para resultar na execução de uma ou mais instâncias de microgateway com configuração informações que não estejam sincronizadas com outras instâncias.

O sincronizador do Edge Microgateway fornece um mecanismo alternativo para o Edge Microgateway instâncias para recuperar os dados de configuração necessários para a inicialização e o processamento do tráfego do proxy de API. Os dados de configuração recuperados das chamadas para o Apigee Edge incluem: a chamada jwk_public_keys, as chamadas jwt_public_key, de inicialização e de produtos de API. O sincronizador possibilita que todos os clusters do Edge Microgateway instâncias em execução em nós diferentes para iniciar corretamente e permanecer em sincronia, mesmo que a conexão de Internet entre o Edge Microgateway e o Apigee Edge foi interrompida.

O sincronizador é uma instância especialmente configurada do Edge Microgateway. Sua única finalidade é pesquisar o Apigee Edge (o tempo pode ser configurado), recuperar dados de configuração e gravá-los em um banco de dados Redis local. A própria instância do sincronizador não pode processar o proxy de API do tráfego de entrada. Outras instâncias do Edge Microgateway em execução em nós diferentes podem ser definido para recuperar dados de configuração do banco de dados do Redis, e não da Apigee Borda Como todas as instâncias de microgateway extraem os dados de configuração do do banco de dados, eles podem iniciar e processar solicitações de API mesmo no caso de uma conexão interrupção.

Como configurar uma instância do sincronizador

Adicione a seguinte configuração ao arquivo org-env/config.yaml para a instalação do Edge Microgateway que você quer usar como sincronizador:

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Exemplo:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 1
  redisBasedConfigCache: true

Por fim, salve o arquivo de configuração e inicie a instância do Edge Microgateway. Ele vai começar pesquisa no Apigee Edge e armazenamento de dados de configuração baixados no banco de dados do Redis.

Como configurar instâncias comuns do Edge Microgateway

Com o sincronizador em execução, é possível configurar outros nós do Edge Microgateway para executar instâncias regulares de microgateway que processam o tráfego de proxy de API. No entanto, você configura essas instâncias para receber os dados de configuração a partir do banco de dados do Redis, e não do Apigee Edge.

Adicione a configuração a seguir a cada nó extra do Edge Microgateway org-env/config.yaml. Observe que o synchronizerMode é definida como 0. Esta propriedade define a instância para operar como um A instância do Edge Microgateway processa o tráfego do proxy da API e recebe os dados de configuração do banco de dados do Redis.

edgemicro:
  redisHost: host_IP
  redisPort: host_port
  redisDb: database_index
  redisPassword: password
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Exemplo:

edgemicro:
  redisHost: 192.168.4.77
  redisPort: 6379
  redisDb: 0
  redisPassword: codemaster
edge_config:
  synchronizerMode: 0
  redisBasedConfigCache: true

Propriedades de configuração

As propriedades de configuração a seguir foram adicionadas para permitir o uso do sincronizador:

Como configurar URLs de exclusão para plug-ins

É possível configurar o microgateway para pular o processamento de plug-ins para os URLs especificados. É possível configurar essas ações URLs globalmente (para todos os plug-ins) ou para plug-ins específicos.

Exemplo:

...
edgemicro:
  ...
  plugins:
    excludeUrls: '/hello,/proxy_one' # global exclude urls
    sequence:
      - oauth
      - json2xml
      - quota
json2xml:
  excludeUrls: '/hello/xml'  # plugin level exclude urls
...

Neste exemplo, os plug-ins não processarão as chamadas de proxy de API recebidas com o caminhos /hello ou /proxy_one. Além disso, o json2xml será ignorado nas APIs com /hello/xml no caminho.

Como definir atributos de configuração com valores de variáveis de ambiente

É possível especificar variáveis de ambiente usando tags no arquivo de . As tags de variável de ambiente especificadas são substituídas pelo ambiente real valores variáveis. As substituições são armazenadas apenas na memória e não no original ou armazenar arquivos em cache.

Neste exemplo, o atributo key é substituído pelo valor do atributo a variável de ambiente TARGETS_SSL_CLIENT_KEY e assim por diante.

targets:
  - ssl:
      client:
        key: <E>TARGETS_SSL_CLIENT_KEY</E>
        cert: <E>TARGETS_SSL_CLIENT_CERT</E>
        passphrase: <E>TARGETS_SSL_CLIENT_PASSPHRASE</E>

Neste exemplo, a tag <n> é usada para indicar um valor inteiro. Somente positiva são aceitos.

edgemicro:
  port: <E><n>EMG_PORT</n></E>

Neste exemplo, a tag <b> é usada para indicar um booleano ( ou seja, verdadeiro ou false).

quotas:
  useRedis: <E><b>EMG_USE_REDIS</b></E>