Esta página foi traduzida pela API Cloud Translation.

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

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Edge Microgateway v. 2.4.x

Informações gerais

Neste tópico, discutimos como gerenciar e configurar o Edge Microgateway, incluindo monitoramento, geração de registros e depuração.

Como fazer alterações na configuração

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

Arquivo de configuração padrão do sistema
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 é preciso saber sobre alterações. Para detalhes sobre as definições do arquivo de configuração, consulte Referência de configuração do Edge Microgateway.

Arquivo de configuração padrão do sistema

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 de prefixos npm. Consulte Onde o Edge Microgateway está instalado.

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

Ligar para edgemicro init
Ligar para edgemicro configure [params]
Ligar para edgemicro start [params]

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

Quando você executa edgemicro init, o arquivo de configuração do sistema (descrito acima), default.yaml, é colocado neste diretório: ~/.edgemicro

Se você alterar o arquivo de configuração em aproximadamente /.edgemicro, precisará reconfigurar e reiniciar o Edge Microgateway:

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

Arquivo de configuração dinâmica para instâncias em execução

Quando você executa edgemicro configure [params], um arquivo de configuração dinâmica é criado em aproximadamente /.edgemicro. Ele é nomeado de acordo com este padrão: [org]-[env]-config.yaml, em que org e env são os nomes da organização e do ambiente do Apigee Edge. É possível usar esse arquivo para fazer alterações na configuração e recarregá-las sem inatividade. Por exemplo, se você adicionar e configurar um plug-in, poderá recarregar a configuração sem causar inatividade, conforme explicado abaixo.

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

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 um administrador da organização).
- env é um ambiente na sua organização (como teste ou produção).
- key é a chave retornada anteriormente pelo comando configure.
- secret é a chave retornada anteriormente pelo comando de configuração.
Exemplo
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824
```

Se o Edge Microgateway for interrompido:

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 um administrador da organização).
- env é um ambiente na sua organização (como teste ou produção).
- key é a chave retornada anteriormente pelo comando configure.
- secret é a chave retornada anteriormente pelo comando de configuração.
Exemplo
```
edgemicro start -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824
```

Confira um exemplo de arquivo de configuração. Para detalhes sobre as definições do arquivo de configuração, consulte 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 o ambiente e a organização do Edge, além da chave e do secret necessários para iniciar o Edge Microgateway, podem ser armazenados nessas variáveis de ambiente:

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

A configuração dessas variáveis é opcional. Se você configurá-los, não precisará especificar os valores ao usar a interface de linha de comando (CLI) para configurar e iniciar o Edge Microgateway.

Como configurar o SSL no servidor Edge Microgateway

É possível configurar o servidor do Microgateway para usar o SSL. Por exemplo, com o SSL configurado, é possível chamar APIs pelo Edge Microgateway com o protocolo "https", da seguinte maneira:

https://localhost:8000/myapi

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

Gere ou consiga um certificado SSL e uma chave usando o utilitário openssl ou o método de sua preferência.
Adicione o atributo edgemicro:ssl ao arquivo de configuração do Edge Microgateway. Para uma lista completa de opções, consulte a tabela abaixo. Para detalhes sobre como modificar a configuração do Edge Microgateway, consulte Como fazer alterações na configuração. 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 
```
Observação:a chave especificada no arquivo de chave SSL referenciado não pode ser criptografada.
Reinicie o Edge Microgateway. Siga as etapas descritas em Como fazer alterações na configuração, dependendo do arquivo de configuração editado: o arquivo padrão ou o de ambiente de execução.

Confira 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:

Opção	Descrição
`key`	Caminho para um arquivo `ca.key` (no formato PEM).
`cert`	Caminho para um arquivo `ca.cert` (no formato PEM).
`pfx`	Caminho para um arquivo `pfx` que contém a chave privada, o certificado e os certificados de CA do cliente no formato PFX.
`passphrase`	String com a senha longa da chave privada ou PFX.
`ca`	Caminho para um arquivo que contém uma lista de certificados confiáveis no formato PEM.
`ciphers`	String que descreve as criptografias a serem usadas, separadas por um ":".
`rejectUnauthorized`	Se verdadeiro, o certificado do servidor será verificado de acordo com a lista de CAs fornecidas. Se a verificação falhar, um erro será retornado.
`secureProtocol`	O método SSL a ser usado. Por exemplo, SSLv3_method para forçar o SSL para a versão 3.
`servername`	O nome do servidor para a extensão SNI (Indicação de nome do servidor) TLS.
`requestCert`	verdadeiro para SSL bidirecional; falso para SSL unidirecional

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

É possível configurar o Edge Microgateway para ser um cliente TLS ou SSL ao se conectar aos endpoints de destino. No arquivo de configuração do Microgateway, use o elemento de destinos para definir as opções de SSL/TLS.

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

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 somente ao host especificado:

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 de TLS:

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

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

Opção	Descrição
`pfx`	Caminho para um arquivo `pfx` que contém a chave privada, o certificado e os certificados de CA do cliente no formato PFX.
`key`	Caminho para um arquivo `ca.key` (no formato PEM).
`passphrase`	String com a senha longa da chave privada ou PFX.
`cert`	Caminho para um arquivo `ca.cert` (no formato PEM).
`ca`	Caminho para um arquivo que contém uma lista de certificados confiáveis no formato PEM.
`ciphers`	String que descreve as criptografias a serem usadas, separadas por um ":".
`rejectUnauthorized`	Se verdadeiro, o certificado do servidor será verificado de acordo com a lista de CAs fornecidas. Se a verificação falhar, um erro será retornado.
`secureProtocol`	O método SSL a ser usado. Por exemplo, SSLv3_method para forçar o SSL para a versão 3.
`servername`	O nome do servidor para a extensão SNI (Indicação de nome do servidor) TLS.

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. Você pode alterar a configuração padrão desse proxy para adicionar suporte a declarações personalizadas a um JSON Web Token (JWT), configurar a expiração do token e gerar tokens de atualização. Para saber mais, consulte a página edgemicro-auth no GitHub.

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

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

Se você 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.

Observação:Importante:se você substituir o proxy de autenticação padrão, o novo proxy ou serviço precisará retornar um formato de resposta idêntico ao proxy edgemicro-auth padrão.

Como gerenciar arquivos de registros

O Edge Microgateway registra informações sobre cada solicitação e resposta. Os arquivos de registros oferecem informações úteis 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 diretório de arquivos de registros padrão

O diretório em que os arquivos de registros são armazenados é especificado no arquivo de configuração do Edge Microgateway. Para mais detalhes sobre como fazer alterações na configuração, consulte Como fazer alterações na configuração.

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 dir para especificar um diretório diferente para o arquivo de registros.

Enviar registros para o console

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

edgemicro:
  logging:
    to_console: true

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

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

Você pode definir esses níveis de registro: info, warn e error. O nível de informação é recomendado. Ela registra todas as solicitações e respostas da API e é o padrão.

Como mudar os intervalos de registro

É possível configurar esses intervalos no arquivo de configuração do Edge Microgateway. Para mais detalhes sobre como fazer alterações na configuração, consulte Como fazer alterações na configuração.

Os atributos configuráveis são os seguintes:

stats_log_interval: (padrão: 60) intervalo, em segundos, quando o registro de estatísticas é gravado no arquivo de registros da API.
rotate_interval: (padrão: 24) intervalo, em horas, em que os arquivos de registros são alternados. 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

Observação : os arquivos de registro arquivados não são compactados. Quando o intervalo começa, um novo arquivo de registros é criado com um novo carimbo de data/hora.

Boas práticas de manutenção de arquivos de registros

À medida que os dados dos arquivos de registros são acumulados ao longo do tempo, a Apigee recomenda que você adote as seguintes práticas:

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

Convenção de nomenclatura do arquivo de registros

Cada instância do Edge Microgateway produz três tipos de arquivos de registros:

api: registra todas as solicitações e respostas que passam pelo Edge Microgateway. Os contadores (estatísticas) e os erros da API também são registrados nesse arquivo.
err: registra tudo o que é enviado para stderr.
out: registra tudo o que é enviado para stdout.

Esta é a convenção de nomenclatura:

edgemicro-<Host Name>-<Instance ID>-<Log Type>.log

Exemplo:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log
edgemicro-mymachine-local-MTQzNTg1NDMODAyMQ-err.log
edgemicro-mymachine-local-mtqzntgndmxodaymq-out.log

Sobre o conteúdo do arquivo de registros

Adicionado em: v2.3.3

Por padrão, o serviço de geração de registros omite o JSON de proxies, produtos salvos e o JSON Web Token (JWT). Se você quiser enviar esses objetos para os arquivos de registros, defina DEBUG=* ao iniciar o Edge Microgateway. Exemplo:

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

Observação : no Windows, use SET DEBUG=*.

Conteúdo do arquivo de registro "api"

O arquivo de registro "api" contém informações detalhadas sobre o fluxo de solicitações e respostas pelo Edge Microgateway. Os arquivos de registro "api" são nomeados da seguinte forma:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Para cada solicitação feita para o Edge Microgateway, quatro eventos são capturados no arquivo de registros "api":

Solicitação recebida do cliente
Solicitação enviada ao destino
Resposta recebida do destino
Resposta enviada ao cliente

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

(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 analisá-los um por um:

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 Unix
info: depende do contexto. Pode ser informações, alerta ou erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar sobre avisos ou erro de erros.
req: identifica o evento. Nesse caso, a solicitação é do cliente.
m: o verbo HTTP usado na solicitação.
u: a parte do URL após o caminho de base.
h: o número do host e da porta em que o Edge Microgateway está detectando.
r: o host remoto e a porta em que a solicitação do cliente foi originada.
i: o ID da solicitação. As quatro entradas de evento vão compartilhar esse ID. Cada solicitação recebe um ID exclusivo. A correlação de registros por ID da solicitação pode fornecer insights valiosos sobre a latência do destino.
d: duração em milissegundos desde que a solicitação foi recebida pelo Edge Microgateway. No exemplo acima, a resposta do destino para a solicitação 0 foi recebida após sete milissegundos (linha 3), e a resposta foi enviada ao cliente após mais quatro milissegundos (linha 4). Em outras palavras, a latência total da solicitação foi de 11 milissegundos, sendo sete milissegundos obtidos pelo destino e quatro milissegundos pelo próprio Edge Microgateway.

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 Unix
info: depende do contexto. Pode ser informações, alerta ou erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar sobre avisos ou erro de erros.
treq: identifica o evento. Nesse caso, direcione a solicitação.
m: o verbo HTTP usado na solicitação de destino.
u: a parte do URL após o caminho de base.
h: número do host e da porta do destino de back-end.
i: o ID da entrada de registro. As quatro entradas de evento vão compartilhar esse ID.

3. Exemplo de resposta recebida do destino

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

1436403888651: carimbo de data Unix

info: depende do contexto. Pode ser informações, alerta ou erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar sobre avisos ou erro de erros.
tres: identifica o evento. Nesse caso, segmentação de resposta.
s: o status da resposta HTTP.
d: a duração em milissegundos. O tempo que o destino levou para a chamada de API.
i: o ID da entrada de registro. As quatro entradas de evento vão compartilhar esse ID.

4. Exemplo de resposta de saída para o cliente

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

1436403888651: carimbo de data Unix

info: depende do contexto. Pode ser informações, alerta ou erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar sobre avisos ou erro de erros.
res: identifica o evento. Nesse caso, resposta ao cliente.
s: o status da resposta HTTP.
d: a duração em milissegundos. É o tempo total que a chamada de API leva, incluindo o tempo gasto pela API de destino e o próprio Edge Microgateway.
i: o ID da entrada de registro. As quatro entradas de evento vão compartilhar esse ID.

Programação do arquivo de registros

Os arquivos de registros são rotacionados no intervalo especificado pelo atributo de configuração rotate_interval. As entradas continuarão sendo adicionadas ao mesmo arquivo de registro até que o intervalo de rotação expire. No entanto, sempre que o Edge Microgateway é reiniciado, ele recebe um novo UID e cria um novo conjunto de arquivos de registros com esse UID. Consulte também Práticas recomendadas de manutenção de arquivos de registros.

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 localizados no arquivo de configuração do Edge Microgateway. Para mais detalhes sobre como fazer alterações na configuração, consulte Como fazer alterações na configuração.

Atributos Edge_config

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

bootstrap: (padrão: nenhum) um URL que aponta para um serviço específico do Edge Microgateway em execução na 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ública/privada: edgemicro genkeys. Para mais detalhes, consulte Como instalar e configurar o Edge Microgateway.
jwt_public_key: (padrão: nenhum) um URL que aponta para o proxy do Edge Microgateway implantado no Apigee Edge. Esse proxy serve como um endpoint de autenticação para emitir tokens de acesso assinados aos clientes. Esse URL é retornado quando você executa o comando para implantar o proxy: edgemicro configure. Para mais detalhes, consulte Como instalar e configurar o Edge Microgateway.

Atributos Edgemicro

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

porta: (padrão: 8000) o número da porta em que o processo do Edge Microgateway detecta.
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 esse 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 solicitações simultâneas que o Edge Microgateway pode receber antes de encerrar a conexão. O objetivo dessa configuração é impedir ataques de negação de serviço. Normalmente, defina-o como um número maior que max_connections.
logging:
- level (padrão: erro):
  - info: registra todas as solicitações e respostas que passam por uma instância do Edge Microgateway.
  - warn: registra apenas mensagens de aviso.
  - error: registra apenas mensagens de erro.
- dir: (padrão: /var/tmp) o diretório onde os arquivos de registros são armazenados.
- stats_log_interval: (padrão: 60) intervalo em segundos quando o registro de estatísticas é gravado no arquivo de registros da API.
- rotate_interval: (padrão: 24) intervalo, em horas, em que os arquivos de registros são alternados.

Plug-ins: os plug-ins adicionam funcionalidade ao Edge Microgateway. Para detalhes sobre o desenvolvimento de plug-ins, consulte Como desenvolver plug-ins personalizados.

dir: um caminho relativo do diretório ./gateway para o diretório ./plugins ou um caminho absoluto.
sequência: uma lista de módulos de plug-in que serão adicionados à sua instância do Edge Microgateway. 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 seu depurador 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) o Edge Microgateway carrega uma nova configuração periodicamente e executa uma atualização se algo for alterado. A pesquisa coleta todas as alterações feitas no Edge (alterações em produtos, proxies com reconhecimento de microgateway etc.), bem como alterações feitas no arquivo de configuração local.
disable_config_poll_interval: (padrão: false) defina como true para desativar a pesquisa de alteração automática.
request_timeout: define um tempo limite para solicitações de destino. O tempo limite é definido em segundos. Se um tempo limite for atingido, o Edge Microgateway vai responder com um código de status 504. (Adicionado v2.4.x)

Atributos de cabeçalhos

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

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

Atributos OAuth

Essas 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 terão permissão para passar pelo Edge Microgateway sem nenhum cabeçalho de autorização. Defina como "false" para exigir um cabeçalho de autorização (padrão).
allowInvalidAuthorization: (padrão: falso) se definido como verdadeiro, as chamadas de API terão permissão para passar se o token transmitido no cabeçalho de autorização for inválido ou tiver expirado. Defina como "false" para exigir tokens válidos (padrão).
autorização-header (padrão: autorização: portador): 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 "Autorização" para outra finalidade.
api-key-header: (padrão: x-api-key) o nome do cabeçalho ou parâmetro de consulta usado para transmitir uma chave de API para o Edge Microgateway. Consulte também Como usar uma chave de API.
keepAuthHeader: (padrão: false) se definido como verdadeiro, o cabeçalho de autorização enviado na solicitação será transmitido para o destino (ele será preservado).
allowOAuthOnly: se definido como verdadeiro, cada API precisa ter um cabeçalho de autorização com um token de acesso do portador. Permite permitir apenas o modelo de segurança OAuth, mantendo a compatibilidade com versões anteriores. (Adicionado 4.2.x)
allowAPIKeyOnly: se definida como verdadeira, cada API precisa transportar um cabeçalho x-api-key (ou um local personalizado) com uma chave de API.Permite apenas o modelo de segurança da chave de API, mantendo a compatibilidade com versões anteriores. (Adicionado 4.2.x)
Observação:não defina allowOAuthOnly e allowOAuthOnly como "true". Por padrão, as duas sinalizações são definidas como "false" (para compatibilidade com versões anteriores).

Atributos específicos do plug-in

Consulte Como usar plug-ins para ver 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 vai processar. Quando o Edge Microgateway é iniciado, ele faz o download de todos os proxies com reconhecimento de microgateway na organização a que está associado. Use a configuração a seguir para limitar quais proxies o microgateway processará. Por exemplo, esta configuração limita a três proxies que o microgateway processará: edgemicro_proxy-1, edgemicro_proxy-2 e edgemicro_proxy-3:

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

Mascaramento de dados de análise

A configuração a seguir impede que as informações do caminho da solicitação sejam exibidas na análise do Edge. Adicione o seguinte à configuração do microgateway para mascarar o URI e/ou o caminho da solicitação. O URI consiste no nome do host e nas partes do caminho da solicitação.

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

Como configurar o Edge Microgateway atrás de um firewall da empresa

Versão v4.2.x compatível

Se o Edge Microgateway estiver instalado atrás de um firewall, talvez o gateway não consiga se comunicar com o Apigee Edge. Nesse caso, há duas opções que você pode considerar:

Opção 1:

A primeira opção é definir a opção Edgemicro: proxy_tunnel como "true" no arquivo de configuração do microgateway:

edge_config:

    proxy: http://10.224.16.85:3128
    proxy_tunnel: true

Quando proxy_tunnel for true, o Edge Microgateway usará o método HTTP CONNECT para encapsular solicitações HTTP em uma única conexão TCP. O mesmo acontece se as variáveis de ambiente para configurar o proxy estiverem com o TLS ativado.

Opção 2:

A segunda opção é especificar um proxy e definir proxy_tunnel como "falso" no arquivo de configuração do microgateway. Exemplo:

edge_config:
     proxy: http://10.224.16.85:3128
     proxy_tunnel: false

Nesse caso, é possível configurar as variáveis a seguir para controlar os hosts de cada proxy HTTP que você quer usar ou quais hosts não podem processar proxies do Edge Microgateway: HTTP_PROXY, HTTPS_PROXY e NO_PROXY.

É possível definir NO_PROXY como uma lista de domínios delimitados por vírgulas para os quais o Edge Microgateway não deve representar. Exemplo:

export NO_PROXY='localhost,localhost:8080'

Defina HTTP_PROXY e HTTPS_PROXY para o endpoint do proxy HTTP que o Edge Microgateway pode enviar mensagens para ele. Exemplo:

export HTTP_PROXY='http://localhost:3786'

export HTTPS_PROXY='https://localhost:3786'

Para mais informações sobre essas variáveis, consulte:

https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables

Veja também

Como configurar o Edge Microgateway por trás de um firewall da empresa na comunidade Apigee.

Como usar caracteres curinga em proxies com reconhecimento de Microgateway

É possível usar um ou mais caracteres curinga "*" no caminho base de um proxy edgemicro_* (com reconhecimento de Microgateway). Por exemplo, um caminho base de /team/*/members permite que os clientes chamem https://[host]/team/blue/members e https://[host]/team/green/members sem que você precise criar novos proxies de API para dar suporte a novas equipes. Observe que não há suporte para /**/.

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

Depuração e solução de problemas

Como se conectar a um depurador

É possível executar o Edge Microgateway com um depurador, como o node-Inspector. Isso é útil para solucionar problemas e depurar plug-ins personalizados.

Reinicie o Edge Microgateway no modo de depuração. Para isso, adicione DEBUG=* ao início do comando "start". Por exemplo:

DEBUG=* edgemicro start -o myorg -e test -k db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s 6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed

Observação:no Windows, use SET DEBUG=*.
Inicie o depurador e configure-o para detectar o número da porta do processo de depuração.
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 Node.js padrão relacionadas ao modo de depuração. Por exemplo, --nolazy ajuda na depuração de código assíncrono.

Verificando arquivos de registro

Se estiver com problemas, examine os arquivos de registro para saber os detalhes da execução e as informações sobre erros. Para mais detalhes, consulte Como gerenciar arquivos de registros.

Usar a segurança da chave de API

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

Armazenamento de chaves em cache

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 de entrada para o Edge Microgateway.

Como usar a segurança de tokens OAuth2

Para detalhes sobre como usar um token OAuth com solicitações de proxy, consulte Microgateway de borda segura.

Como usar uma chave de API

Para detalhes sobre o uso de chaves de API com solicitações de proxy, consulte Secure Edge Microgateway.

Observação:também é possível transmitir a chave de API em um parâmetro de consulta. Por exemplo, em que [key] é a chave de API, uma string de letras e números:

curl "http://localhost:8000/hello?"x-api-key=[key]"

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 ou 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 o nome para apiKey:

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