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. 2.5.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

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

   npm upgrade edgemicro -g

   Para fazer upgrade para uma versão específica do Edge Microgateway, especifique a versão number no comando de upgrade. Se você não especificar o número da versão, o a versão mais recente será instalada. Por exemplo, para atualizar para a versão 2.5.26, use o seguinte comando:

   npm upgrade edgemicro@2.5.26 -g

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

   edgemicro --version
   current nodejs version is v8.9.0
   current edgemicro version is 2.5.26
       

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

   edgemicro upgradeauth -o org_name -e env_name -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_name -e env_name -k key -s secret

   Em que:

   • org_name é o nome da sua organização de Edge. Você precisa ser uma organização. administrador).
   • env_name é 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_name -e env_name -k key -s secret

   Em que:

   • org_name é o nome da sua organização de Edge. Você precisa ser uma organização. administrador).
   • env_name é 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

É 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 .

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

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

É possível definir estes níveis de registro: info, warn e . O nível de informação é recomendado. Ele registra todas as solicitações e respostas da API, que é o padrão.

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

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 três tipos de arquivos de registro:

• api: registra todas as solicitações e respostas que fluem pelo Edge. Microgateway Contadores (estatísticas) e erros de API também são registrados nesse arquivo.
• err: registra tudo que é enviado para stderr.
• out: registra tudo 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 à: 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 quiser enviar esses objetos para os arquivos de registro, defina o 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: depende do contexto. Pode ser uma informação, um aviso ou um erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar em caso de avisos ou em busca de erros.
• 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: depende do contexto. Pode ser uma informação, um aviso ou um erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar em caso de avisos ou em busca de erros.
• 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: depende do contexto. Pode ser uma informação, um aviso ou um erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar em caso de avisos ou em busca de erros.
• 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: depende do contexto. Pode ser uma informação, um aviso ou um erro, dependendo do nível de registro. Podem ser estatísticas para um registro de estatísticas, avisar em caso de avisos ou em busca de erros.
• 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.

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: registra todas as solicitações e respostas que fluem por um Instância do Edge Microgateway.
    • warn: registra apenas mensagens de aviso.
    • error: registra somente mensagens de erro.
  • 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)

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:

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

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

Compatível com a v2.4.x

Se o Edge Microgateway estiver instalado por trás de um firewall, talvez o gateway não consiga se comunicar com o Apigee Edge. Nesse caso, há duas opções a serem consideradas:

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 é true, o Edge Microgateway usa o método CONNECT de HTTP 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 configurar 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, você pode definir as seguintes variáveis para controlar os hosts de cada solicitação HTTP proxy que você quer usar ou quais hosts não devem processar proxies do Edge Microgateway: HTTP_PROXY, HTTPS_PROXY e NO_PROXY.

É possível definir NO_PROXY como uma lista delimitada por vírgulas de domínios que o Edge O microgateway não deve servir como proxy. Exemplo:

export NO_PROXY='localhost,localhost:8080'

Defina HTTP_PROXY e HTTPS_PROXY como o proxy HTTP. endpoint 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 (em inglês)

Consulte também

Como configurar o Edge Microgateway por um firewall da empresa na comunidade da Apigee.

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 o JWT

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.

O Edge Microgateway usa JWTs como tokens do portador para segurança do OAuth. Quando você gera um token OAuth para o Edge Microgateway, vai receber um JWT. Você pode usar o JWT na Cabeçalho de autorização das chamadas de API. Exemplo:

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

Como gerar um novo JWT

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

edgemicro token get -o docs -e test -i G0IAeU864EtBo99NvUbn6Z4CBwVcS2 -s uzHTbwNWvoSmOy

Esse comando solicita que o Apigee Edge gere um JWT que possa ser usado para verificar a API chamadas. Os parâmetros -i e -s são os valores do ID do consumidor e do secret de um app de desenvolvedor na sua organização do Apigee Edge.

Ou você também pode gerar um JWT usando a API de gerenciamento:

curl -i -X POST "http://org-env.apigee.net/edgemicro-auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "your consumer key",
    "client_secret": "your consumer secret",
    "grant_type": "client_credentials"
  }'

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").
• client_id é o ID do consumidor no app do desenvolvedor criado anteriormente.
• client_secret é o secret do cliente no app do desenvolvedor que você criou. antes.

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é expirar (após 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.

Se você configurou a instância do Edge Microgateway antes da versão 2.5.2

Se você configurou a instância do Edge Microgateway antes da versão 2.5.2, execute estes dois comandos para fazer upgrade da KVM e da política de autenticação:

upgradekvm -o org -e env -u username

Para mais informações sobre esse comando, consulte Como fazer upgrade da KVM.

O próximo comando atualiza o proxy edgemicro-oauth que foi implantado no sua organização da Apigee quando você configurou o Edge Microgateway. Esse proxy fornece os serviços necessários para e gerar tokens.

upgradeauth -o org -e env -u username

Para mais informações sobre esse comando, consulte Como fazer upgrade do proxy Edgemicro-auth.

Como fazer a rotação das chaves

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'

Execute o comando de rotação para alternar as chaves. (Para mais informações sobre esse comando, consulte Como fazer rotação de chaves.

edgemicro rotatekey -o org -e env -u username -k kid_value

Exemplo:

edgemicro rotatekey -o jdoe -e test -u jdoe@google.com -k 2
current nodejs version is v6.9.1
current edgemicro version is 2.5.7
password:
Checking if private key exists in the KVM...
Checking for certificate...
Found Certificate
Generating New key/cert pair...
Extract new public key
Key Rotation successfully completed!

O parâmetro -k especifica um ID de chave (criança). Esse ID é usado para fazer a correspondência com uma chave específica. O Edge Microgateway usa esse valor para escolher um conjunto de chaves durante a rotação de chaves. Para mais do produto, consulte a Seção 4.5 do Especificação da chave da Web do JSON.

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"
    }
  ]
}

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 no início do comando start. Exemplo:

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

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

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

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

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": "108000"
}

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:

   {
       "token": "your-access-token",
       "access_token": "your-access-token",
       "token_type": "bearer",
       "expires_in": "108000",
       "refresh_token": "your-refresh-token",
       "refresh_token_expires_in": "431999",
       "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

Forever é uma ferramenta do Node.js que reinicia automaticamente um app Node.js caso o processo fique inativo ou tenha um erro. Borda O Microgateway tem um arquivo forever.json que pode ser configurado para controlar quantas horários e com quais intervalos o Edge Microgateway deve ser reiniciado. Esse arquivo configura uma Serviço permanente chamado forever-monitor, que gerencia o Forever programaticamente.

O arquivo forever.json está disponível na instalação raiz do Edge Microgateway. diretório. Consulte Onde o Edge Microgateway está instalado. Para detalhes sobre as opções de configuração, consulte documentação sobre monitoramento permanente.

O comando edgemicro forever inclui sinalizações que permitem especificar o local do o arquivo forever.json (a flag -f) e inicia/interrompe o monitoramento constante processo (a flag -a). Exemplo:

edgemicro forever -f ~/mydir/forever.json -a start

Para mais informações, consulte Monitoramento contínuo na referência da CLI.

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. Confirme se você tem o Edge Microgateway versão 2.5.25 ou mais recente instalado. Caso contrário, você precisa Execute o seguinte comando para fazer upgrade para a versão mais recente:

   npm install -g edgemicro

   Se precisar de ajuda, consulte Como instalar o Edge Microgateway

2. Crie um arquivo de configuração com o nome a seguir: $HOME/.edgemicro/org_name-env_name-config.yaml

   Exemplo:

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

3. 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

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

   export EDGEMICRO_LOCAL=1

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

   edgemicro start -o org_name -e environment_name -a local_proxy_name \
     -v local_proxy_version -t target_url -b base_path

   Em que:

   • your_org é a "organização" que você usou no nome do arquivo de configuração.
   • your_environment é 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 /

6. 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. Confirme se você tem o Edge Microgateway versão 2.5.25 ou mais recente instalado. Caso contrário, você precisa Execute o seguinte comando para fazer upgrade para a versão mais recente:

   npm install -g edgemicro

   Se precisar de ajuda, consulte Como instalar o Edge Microgateway

2. 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.
3. 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.

4. 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.

5. 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.

6. 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.
7. Na máquina em que o Edge Microgateway está instalado, exporte o seguinte com o valor "1".

   export EDGEMICRO_LOCAL_PROXY=1

8. 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":""
}