Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Referencia de operación y configuración de Edge Microgateway

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Edge Microgateway v. 3.2.x

En este tema, se explica cómo administrar y configurar Edge Microgateway.

Actualiza Edge Microgateway si tienes conexión a Internet

En esta sección, se explica cómo actualizar una instalación existente de Edge Microgateway. Si trabajas sin conexión a Internet, consulta ¿Puedo instalar Edge Microgateway sin conexión a Internet?.

Apigee recomienda que pruebes tu configuración existente con la nueva versión antes de actualizar tu entorno de producción.

Ejecuta el siguiente comando de npm para actualizar a la versión más reciente de Edge Microgateway:
```
npm upgrade edgemicro -g
```
Para instalar una versión específica de Edge Microgateway, debes especificar el número de versión en el comando de instalación. Por ejemplo, para instalar la versión 3.2.3, usa el siguiente comando:
```
npm install edgemicro@3.2.3 -g
```

Verifica el número de versión. Por ejemplo, si instalaste la versión 3.2.3:

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

Por último, actualiza el proxy edgemicro-auth a la versión más reciente:
```
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
```

Cómo realizar cambios de configuración

Los archivos de configuración que debes conocer incluyen los siguientes:

Archivo de configuración predeterminado del sistema
Archivo de configuración predeterminado para una instancia de Edge Microgateway recién inicializada
Archivo de configuración dinámico para instancias en ejecución

En esta sección, se analizan estos archivos y lo que debes saber para cambiarlos.

Archivo de configuración predeterminada del sistema

Cuando instalas Edge Microgateway, se coloca un archivo de configuración del sistema predeterminado aquí:

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

Aquí, prefix es el directorio de prefijo npm. Consulta Dónde se instala Edge Microgateway si no puedes encontrar este directorio.

Si cambias el archivo de configuración del sistema, debes volver a inicializar, configurar y reiniciar Edge Microgateway:

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

Archivo de configuración predeterminado para las instancias de Edge Microgateway recién inicializadas

Cuando ejecutas edgemicro init, el archivo de configuración del sistema (descrito anteriormente), default.yaml, se coloca en el directorio ~/.edgemicro.

Si cambias el archivo de configuración en ~/.edgemicro, debes volver a configurar y reiniciar Edge Microgateway:

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

Archivo de configuración dinámico para ejecutar instancias

Cuando ejecutas edgemicro configure [params], se crea un archivo de configuración dinámico en ~/.edgemicro. El archivo se denomina según este patrón: org-env-config.yaml, donde org y env son los nombres de tu organización y entorno de Apigee Edge. Puedes usar este archivo para realizar cambios en la configuración y, luego, volver a cargarlos sin tiempo de inactividad. Por ejemplo, si agregas y configuras un complemento, puedes volver a cargar la configuración sin incurrir en tiempo de inactividad, como se explica a continuación.

Si Edge Microgateway está en ejecución (opción sin tiempo de inactividad):

Vuelve a cargar la configuración de Edge Microgateway:
```
edgemicro reload -o $ORG -e $ENV -k $KEY -s $SECRET
```
Donde:
- $ORG es el nombre de tu organización de Edge (debes ser administrador de la organización).
- $ENV es un entorno de tu organización (como "test" o "prod").
- $KEY es la clave que devolvió anteriormente el comando de configuración.
- $SECRET es la clave que devolvió anteriormente el comando de configuración.
Por ejemplo:
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

Si Edge Microgateway está detenido, haz lo siguiente:

Reinicia Edge Microgateway:
```
edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
Donde:
- $ORG es el nombre de tu organización de Edge (debes ser administrador de la organización).
- $ENV es un entorno de tu organización (como "prueba" o "prod").
- $KEY es la clave que devolvió anteriormente el comando de configuración.
- $SECRET es la clave que devolvió anteriormente el comando de configuración.
Por ejemplo:
```
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

Este es un ejemplo de un archivo de configuración. Para obtener detalles sobre la configuración del archivo de configuración, consulta la referencia de configuración de 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

Configura variables de entorno

Los comandos de la interfaz de línea de comandos que requieren valores para tu organización y entorno de Edge, y la clave y el secreto necesarios para iniciar Edge Microgateway, se pueden almacenar en estas variables de entorno:

EDGEMICRO_ORG
EDGEMICRO_ENV
EDGEMICRO_KEY
EDGEMICRO_SECRET

Establecer estas variables es opcional. Si los configuras, no tienes que especificar sus valores cuando usas la interfaz de línea de comandos (CLI) para configurar y, luego, iniciar Edge Microgateway.

Cómo configurar SSL en el servidor de Edge Microgateway

Mira los siguientes videos para obtener información sobre la configuración de TLS en Apigee Edge Microgateway:

Video	Descripción
Configura TLS unidireccional de salida	Obtén información para configurar TLS en Apigee Edge Microgateway. En este video, se proporciona una descripción general de TLS y su importancia, se presenta TLS en Edge Microgateway y se muestra cómo configurar TLS unidireccional de salida.
Configura TLS bidireccional de Northbound	Este es el segundo video sobre la configuración de TLS en Apigee Edge Microgateway. En este video, se explica cómo configurar la TLS bidireccional de salida.
Configura TLS unidireccional y bidireccional para el tráfico de salida	En este tercer video sobre la configuración de TLS en Apigee Edge Microgateway, se explica cómo configurar TLS unidireccional y bidireccional descendente.

Puedes configurar el servidor de Microgateway para que use SSL. Por ejemplo, con SSL configurado, puedes llamar a las APIs a través de Edge Microgateway con el protocolo "https", de la siguiente manera:

https://localhost:8000/myapi

Para configurar SSL en el servidor de Microgateway, sigue estos pasos:

Genera u obtén un certificado y una clave SSL con la utilidad openssl o el método que prefieras.
Agrega el atributo edgemicro:ssl al archivo de configuración de Edge Microgateway. Para obtener una lista completa de las opciones, consulta la siguiente tabla. Por ejemplo:
```
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
```
La clave especificada en el archivo de claves SSL al que se hace referencia no debe estar encriptada.
Reinicia Edge Microgateway. Sigue los pasos que se describen en Cómo realizar cambios de configuración según el archivo de configuración que editaste: el archivo predeterminado o el archivo de configuración del entorno de ejecución.

A continuación, se muestra un ejemplo de la sección edgemicro del archivo de configuración, con 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

A continuación, se incluye una lista de todas las opciones de servidor compatibles:

Opción	Descripción
`key`	Ruta de acceso a un archivo `ca.key` (en formato PEM).
`cert`	Ruta de acceso a un archivo `ca.cert` (en formato PEM).
`pfx`	Ruta de acceso a un archivo `pfx` que contiene la clave privada, el certificado y los certificados de CA del cliente en formato PFX.
`passphrase`	Es una cadena que contiene la frase de contraseña de la clave privada o el archivo PFX.
`ca`	Ruta de acceso a un archivo que contiene una lista de certificados de confianza en formato PEM.
`ciphers`	Es una cadena que describe los algoritmos de cifrado que se usarán, separados por un ":".
`rejectUnauthorized`	Si es verdadero, el certificado del servidor se verifica con la lista de AC proporcionadas. Si falla la verificación, se muestra un error.
`secureProtocol`	Es el método SSL que se usará. Por ejemplo, SSLv3_method para forzar SSL a la versión 3.
`servername`	Es el nombre del servidor para la extensión TLS de SNI (indicación de nombre del servidor).
`requestCert`	Es verdadero para SSL bidireccional y falso para SSL unidireccional.

Uso de opciones de SSL/TLS del cliente

Puedes configurar Edge Microgateway para que sea un cliente de TLS o SSL cuando se conecte a los extremos de destino. En el archivo de configuración de Microgateway, usa el elemento targets para establecer las opciones de SSL/TLS. Ten en cuenta que puedes especificar varios objetivos específicos. A continuación, se incluye un ejemplo de segmentación para varios objetivos.

En este ejemplo, se proporcionan parámetros de configuración que se aplicarán a todos los 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

En este ejemplo, la configuración solo se aplica al 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

Este es un ejemplo de TLS:

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

En el caso de que desees aplicar la configuración de TLS/SSL a varios destinos específicos, debes especificar el primer host en la configuración como "vacío", lo que habilita las solicitudes universales, y, luego, especificar hosts específicos en cualquier orden. En este ejemplo, la configuración se aplica a varios hosts específicos:

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

A continuación, se incluye una lista de todas las opciones de cliente compatibles:

Opción	Descripción
`pfx`	Ruta de acceso a un archivo `pfx` que contiene la clave privada, el certificado y los certificados de CA del cliente en formato PFX.
`key`	Ruta de acceso a un archivo `ca.key` (en formato PEM).
`passphrase`	Es una cadena que contiene la frase de contraseña de la clave privada o el archivo PFX.
`cert`	Ruta de acceso a un archivo `ca.cert` (en formato PEM).
`ca`	Ruta de acceso a un archivo que contiene una lista de certificados de confianza en formato PEM.
`ciphers`	Es una cadena que describe los algoritmos de cifrado que se usarán, separados por un ":".
`rejectUnauthorized`	Si es verdadero, el certificado del servidor se verifica con la lista de AC proporcionadas. Si falla la verificación, se muestra un error.
`secureProtocol`	Es el método SSL que se usará. Por ejemplo, SSLv3_method para forzar SSL a la versión 3.
`servername`	Es el nombre del servidor para la extensión TLS de SNI (indicación de nombre del servidor).

Cómo personalizar el proxy de edgemicro-auth

De forma predeterminada, Edge Microgateway usa un proxy implementado en Apigee Edge para la autenticación de OAuth2. Este proxy se implementa cuando ejecutas edgemicro configure por primera vez. Puedes cambiar la configuración predeterminada de este proxy para agregar compatibilidad con reclamos personalizados a un token web JSON (JWT), configurar el vencimiento del token y generar tokens de actualización. Para obtener más detalles, consulta la página edgemicro-auth en GitHub.

Usa un servicio de autorización personalizado

De forma predeterminada, Edge Microgateway usa un proxy implementado en Apigee Edge para la autenticación de OAuth2. Este proxy se implementa cuando ejecutas edgemicro configure por primera vez. De forma predeterminada, la URL de este proxy se especifica en el archivo de configuración de Edge Microgateway de la siguiente manera:

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

Si deseas usar tu propio servicio personalizado para controlar la autenticación, cambia el valor de authUri en el archivo de configuración para que apunte a tu servicio. Por ejemplo, es posible que tengas un servicio que use LDAP para verificar la identidad.

Importante: Si anulas el proxy de autenticación predeterminado, el nuevo proxy o servicio debe devolver un formato de respuesta idéntico al proxy de edgemicro-auth predeterminado.

Administra archivos de registro

Edge Microgateway registra información sobre cada solicitud y respuesta. Los archivos de registro proporcionan información útil para la depuración y la solución de problemas.

Dónde se almacenan los archivos de registro

De forma predeterminada, los archivos de registro se almacenan en /var/tmp.

Cómo cambiar el directorio predeterminado del archivo de registro

El directorio en el que se almacenan los archivos de registro se especifica en el archivo de configuración de Edge Microgateway. Consulta también Cómo realizar cambios de configuración.

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

Cambia el valor de dir para especificar un directorio de archivos de registro diferente.

Envía registros a la consola

Puedes configurar el registro de modo que la información de registro se envíe a la salida estándar en lugar de a un archivo de registro. Establece la marca to_console en verdadero de la siguiente manera:

edgemicro:
  logging:
    to_console: true

Con este parámetro de configuración, los registros se enviarán a la salida estándar. Actualmente, no puedes enviar registros a stdout y a un archivo de registro.

Cómo establecer el nivel de registro

Especificas el nivel de registro que se usará en la configuración de edgemicro. Para obtener una lista completa de los niveles de registro y sus descripciones, consulta atributos de edgemicro.

Por ejemplo, la siguiente configuración establece el nivel de registro en debug:

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

Cómo cambiar los intervalos de registro

Puedes configurar estos intervalos en el archivo de configuración de Edge Microgateway. Consulta también Cómo realizar cambios en la configuración.

Los atributos configurables son los siguientes:

stats_log_interval: (predeterminado: 60) Intervalo, en segundos, en el que se escribe el registro de estadísticas en el archivo de registro de la API.
rotate_interval: (predeterminado: 24) Es el intervalo, en horas, en el que se rotan los archivos de registro. Por ejemplo:

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

Cómo relajar los permisos estrictos de los archivos de registro

De forma predeterminada, Edge Microgateway genera el archivo de registro de la aplicación (api-log.log) con el nivel de permiso de archivo establecido en 0600. Este nivel de permiso no permite que las aplicaciones o los usuarios externos lean el archivo de registro. Para relajar este nivel de permisos estricto, establece logging:disableStrictLogFile en true. Cuando este atributo es true, el archivo de registro se crea con el conjunto de permisos de archivo establecido en 0755. Si es false o si no se proporciona el atributo, el permiso se establece de forma predeterminada en 0600.

Se agregó en la versión 3.2.3.

Por ejemplo:

edgemicro:
 logging:
   disableStrictLogFile: true

Prácticas recomendadas para el mantenimiento de archivos de registro

A medida que se acumulan los datos de los archivos de registro con el tiempo, Apigee recomienda que adoptes las siguientes prácticas:

Dado que los archivos de registro pueden ser bastante grandes, asegúrate de que el directorio de archivos de registro tenga espacio suficiente. Consulta las siguientes secciones: Dónde se almacenan los archivos de registro y Cómo cambiar el directorio predeterminado de los archivos de registro.
Borra o mueve los archivos de registro a un directorio de archivo independiente al menos una vez a la semana.
Si tu política es borrar registros, puedes usar el comando de la CLI edgemicro log -c para quitar (limpiar) los registros más antiguos.

Convención de nomenclatura de archivos de registro

Cada instancia de Edge Microgateway genera un archivo de registro con la extensión .log. La convención de nomenclatura para los archivos de registro es la siguiente:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Por ejemplo:

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

Acerca del contenido de los archivos de registro

Se agregó en la versión 2.3.3

De forma predeterminada, el servicio de registro omite el JSON de los proxies, los productos y el token web JSON (JWT) descargados. Si deseas generar estos objetos en la consola, establece la marca de línea de comandos DEBUG=* cuando inicies Edge Microgateway. Por ejemplo:

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

En Windows, usa SET DEBUG=*

Contenido del archivo de registro "api"

El archivo de registro "api" contiene información detallada sobre el flujo de solicitudes y respuestas a través de Edge Microgateway. Los archivos de registro de la API tienen el siguiente nombre:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Para cada solicitud realizada a Edge Microgateway, se capturan cuatro eventos en el archivo de registro "api":

Solicitud entrante del cliente
Se realizó una solicitud saliente al destino
Respuesta entrante del destino
Respuesta saliente al cliente

Cada una de estas entradas separadas se representa en una notación abreviada para ayudar a que los archivos de registro sean más compactos. A continuación, se muestran cuatro entradas de ejemplo que representan cada uno de los cuatro eventos. En el archivo de registro, se ven de la siguiente manera (los números de línea son solo para referencia en el documento, no aparecen en el archivo 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

Analicemos cada uno de ellos:

1. Ejemplo de solicitud entrante del cliente:

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

1436403888651: Marca de fecha de Unix
info: Es el nivel de registro. Este valor depende del contexto de la transacción y del nivel de registro establecido en la configuración de edgemicro. Consulta Cómo configurar el nivel de registro. En el caso de los registros de estadísticas, el nivel se establece en stats. Los registros de estadísticas se informan en un intervalo regular establecido con la configuración de stats_log_interval. Consulta también Cómo cambiar los intervalos de registro.
req: Identifica el evento. En este caso, es la solicitud del cliente.
m: Es el verbo HTTP que se usa en la solicitud.
u: Es la parte de la URL que sigue a la ruta base.
h: Es el host y el número de puerto en el que Edge Microgateway está escuchando.
r: Es el host y el puerto remotos en los que se originó la solicitud del cliente.
i: Es el ID de la solicitud. Las cuatro entradas de eventos compartirán este ID. A cada solicitud se le asigna un ID único. Correlacionar los registros de registro por ID de solicitud puede proporcionar información valiosa sobre la latencia del objetivo.
d: Es la duración en milisegundos desde que Edge Microgateway recibió la solicitud. En el ejemplo anterior, la respuesta del destino para la solicitud 0 se recibió después de 7 milisegundos (línea 3), y la respuesta se envió al cliente después de 4 milisegundos adicionales (línea 4). En otras palabras, la latencia total de la solicitud fue de 11 milisegundos, de los cuales 7 fueron del destino y 4 del propio Edge Microgateway.

2. Ejemplo de solicitud saliente realizada al destino:

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

1436403888651: Marca de fecha de Unix
info: Es el nivel de registro. Este valor depende del contexto de la transacción y del nivel de registro establecido en la configuración de edgemicro. Consulta Cómo configurar el nivel de registro. En el caso de los registros de estadísticas, el nivel se establece en stats. Los registros de estadísticas se informan en un intervalo regular establecido con la configuración de stats_log_interval. Consulta también Cómo cambiar los intervalos de registro.
treq: Identifica el evento. En este caso, es la solicitud de destino.
m: Es el verbo HTTP que se usa en la solicitud de destino.
u: Es la parte de la URL que sigue a la ruta base.
h: Es el host y el número de puerto del destino de backend.
i: Es el ID de la entrada de registro. Las cuatro entradas de eventos compartirán este ID.

3. Muestra de la respuesta entrante del destino

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

1436403888651: Marca de fecha de Unix

info: Es el nivel de registro. Este valor depende del contexto de la transacción y del nivel de registro establecido en la configuración de edgemicro. Consulta Cómo configurar el nivel de registro. En el caso de los registros de estadísticas, el nivel se establece en stats. Los registros de estadísticas se informan en un intervalo regular establecido con la configuración de stats_log_interval. Consulta también Cómo cambiar los intervalos de registro.
tres: Identifica el evento. En este caso, es la respuesta de destino.
s: Es el estado de la respuesta HTTP.
d: Es la duración en milisegundos. Es el tiempo que tarda el destino en realizar la llamada a la API.
i: Es el ID de la entrada de registro. Las cuatro entradas de eventos compartirán este ID.

4. Ejemplo de respuesta saliente para el cliente

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

1436403888651: Marca de fecha de Unix

info: Es el nivel de registro. Este valor depende del contexto de la transacción y del nivel de registro establecido en la configuración de edgemicro. Consulta Cómo configurar el nivel de registro. En el caso de los registros de estadísticas, el nivel se establece en stats. Los registros de estadísticas se informan en un intervalo regular establecido con la configuración de stats_log_interval. Consulta también Cómo cambiar los intervalos de registro.
res: Identifica el evento. En este caso, se responde al cliente.
s: Es el estado de la respuesta HTTP.
d: Es la duración en milisegundos. Es el tiempo total que tarda la llamada a la API, incluido el tiempo que tarda la API de destino y el tiempo que tarda el propio Edge Microgateway.
i: Es el ID de la entrada de registro. Las cuatro entradas de eventos compartirán este ID.

Programación del archivo de registro

Los archivos de registro se rotan en el intervalo especificado por el atributo de configuración rotate_interval. Se seguirán agregando entradas al mismo archivo de registro hasta que venza el intervalo de rotación. Sin embargo, cada vez que se reinicia Edge Microgateway, recibe un UID nuevo y crea un nuevo conjunto de archivos de registro con este UID. Consulta también las Prácticas recomendadas para el mantenimiento de archivos de registro.

Mensajes de error

Algunas entradas de registro contendrán mensajes de error. Para identificar dónde y por qué se producen los errores, consulta la referencia de errores de Edge Microgateway.

Referencia de configuración de Edge Microgateway

Ubicación del archivo de configuración

Los atributos de configuración que se describen en esta sección se encuentran en el archivo de configuración de Edge Microgateway. Consulta también Cómo realizar cambios de configuración.

Atributos de edge_config

Estos parámetros de configuración se usan para configurar la interacción entre la instancia de Edge Microgateway y Apigee Edge.

bootstrap: (predeterminado: none) URL que apunta a un servicio específico de Edge Microgateway que se ejecuta en Apigee Edge. Edge Microgateway usa este servicio para comunicarse con Apigee Edge. Esta URL se devuelve cuando ejecutas el comando para generar el par de claves pública/privada: edgemicro genkeys. Consulta Cómo configurar Edge Microgateway para obtener más detalles.
jwt_public_key: (valor predeterminado: none) URL que apunta al proxy de Edge Microgateway implementado en Apigee Edge. Este proxy funciona como un extremo de autenticación para emitir tokens de acceso firmados a los clientes. Esta URL se devuelve cuando ejecutas el comando para implementar el proxy: edgemicro configure. Consulta Cómo configurar Edge Microgateway para obtener más detalles.
quotaUri: Establece esta propiedad de configuración si deseas administrar las cuotas a través del proxy edgemicro-auth que se implementa en tu organización. Si no se configura esta propiedad, el extremo de cuota se establece de forma predeterminada en el extremo interno de Edge Microgateway.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

Atributos de edgemicro

Estos parámetros de configuración establecen el proceso de Edge Microgateway.

port: (predeterminado: 8000) Es el número de puerto en el que escucha el proceso de Edge Microgateway.
max_connections: (valor predeterminado: -1) Especifica la cantidad máxima de conexiones entrantes simultáneas que puede recibir Edge Microgateway. Si se supera este número, se muestra el siguiente estado:

res.statusCode = 429; // Too many requests
max_connections_hard: (valor predeterminado: -1) Es la cantidad máxima de solicitudes simultáneas que Edge Microgateway puede recibir antes de cerrar la conexión. Este parámetro de configuración está diseñado para frustrar los ataques de denegación de servicio. Por lo general, se establece en un número mayor que max_connections.
logging:
- level: (predeterminado: error)
  - info: (Recomendado) Registra todas las solicitudes y respuestas que fluyen a través de una instancia de Edge Microgateway.
  - warn: Registra solo los mensajes de advertencia.
  - error: Registra solo los mensajes de error.
  - debug: Registra mensajes de depuración junto con mensajes de información, advertencia y error.
  - trace: Registra información de seguimiento para los errores junto con mensajes de información, advertencia y error.
  - none: No se crea un archivo de registro.
- dir: (predeterminado: /var/tmp) Es el directorio en el que se almacenan los archivos de registro.
- stats_log_interval: (predeterminado: 60) Intervalo, en segundos, en el que se escribe el registro de estadísticas en el archivo de registro de la API.
- rotate_interval: (predeterminado: 24) Es el intervalo, en horas, en el que se rotan los archivos de registro.

plugins: Los complementos agregan funcionalidad a Edge Microgateway. Para obtener detalles sobre el desarrollo de complementos, consulta Cómo desarrollar complementos personalizados.

dir: Es una ruta de acceso relativa desde el directorio ./gateway al directorio ./plugins, o bien una ruta de acceso absoluta.
sequence: Es una lista de módulos de complementos que se agregarán a tu instancia de Edge Microgateway. Los módulos se ejecutarán en el orden en que se especifican aquí.

debug: Agrega la depuración remota al proceso de Edge Microgateway.
- port: Es el número de puerto en el que se escuchará. Por ejemplo, configura el depurador de tu IDE para que detecte solicitudes en este puerto.
- args: Argumentos para el proceso de depuración. Por ejemplo: args --nolazy
config_change_poll_interval: (predeterminado: 600 segundos) Edge Microgateway carga una nueva configuración periódicamente y ejecuta una recarga si se modificó algo. El sondeo detecta los cambios realizados en Edge (cambios en productos, proxies compatibles con microgateways, etc.), así como los cambios realizados en el archivo de configuración local.
disable_config_poll_interval: (predeterminado: false) Se establece en true para desactivar la sondeo de cambios automático.
request_timeout: Establece un tiempo de espera para las solicitudes de destino. El tiempo de espera se establece en segundos. Si se produce un tiempo de espera, Edge Microgateway responde con un código de estado 504. (Se agregó en la versión 2.4.x)
keep_alive_timeout: Esta propiedad te permite establecer el tiempo de espera de Edge Microgateway (en milisegundos). (Valor predeterminado: 5 segundos) (Se agregó en la versión 3.0.6)
headers_timeout: Este atributo limita la cantidad de tiempo (en milisegundos) que el analizador de HTTP esperará para recibir los encabezados HTTP completos.
Por ejemplo:
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
Internamente, el parámetro establece el atributo Server.headersTimeout de Node.js en las solicitudes. (Valor predeterminado: 5 segundos más que el tiempo establecido con edgemicro.keep_alive_timeout. Este parámetro de configuración predeterminado evita que los balanceadores de cargas o los proxies descarten erróneamente la conexión. (Se agregó en la versión 3.1.1)
noRuleMatchAction: (cadena) Es la acción a realizar (permitir o denegar el acceso) si no se resuelve la regla de coincidencia especificada en el complemento accesscontrol (no hay coincidencia). Valores válidos: ALLOW o DENY. Valor predeterminado: ALLOW (se agregó en la versión 3.1.7)
enableAnalytics: (valor predeterminado: true) Establece el atributo en false para evitar que se cargue el complemento de Analytics. En este caso, no se realizarán llamadas a las estadísticas de Apigee Edge. Si se establece como true o cuando no se proporciona este atributo, el complemento de Analytics funcionará como de costumbre. Consulta los atributos de edgemicro para obtener más detalles. (Se agregó en la versión 3.1.8).
Ejemplo:
```
edgemicro
  enableAnalytics=false|true
```
Si enableAnalytics se establece en false, pero se inicia Edge Microgateway con el complemento de métricas, el complemento de Analytics funcionará como de costumbre, ya que el complemento de métricas necesita que funcione el complemento de Analytics. Para obtener información sobre el complemento de métricas, consulta las notas de la versión de Edge Microgateway v1.3.6.

on_target_response_abort: Este atributo te permite controlar cómo se comporta Edge Microgateway si la conexión entre el cliente (Edge Microgateway) y el servidor de destino se cierra antes de tiempo.

Valor	Descripción
Predeterminado	Si no se especifica `on_target_response_abort`, el comportamiento predeterminado es truncar la respuesta sin mostrar un error. En los archivos de registro, se muestra un mensaje de advertencia con `targetResponse aborted` y un código de respuesta 502.
`appendErrorToClientResponseBody`	El error personalizado `TargetResponseAborted` se devuelve al cliente. En los archivos de registro, se muestra un mensaje de advertencia con `targetResponse aborted` y un código de respuesta 502. Además, el error `TargetResponseAborted` se registra con el mensaje `Target response ended prematurely.`.
`abortClientRequest`	Edge Microgateway anula la solicitud y se escribe una advertencia en los archivos de registro: `TargetResponseAborted` con el código de estado de solicitud 502.

Ejemplo:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

Atributos de encabezados

Estos parámetros de configuración determinan cómo se tratan ciertos encabezados HTTP.

x-forwarded-for: (predeterminado: true) Establece el valor en falso para evitar que los encabezados x-forwarded-for se pasen al destino. Ten en cuenta que, si hay un encabezado x-forwarded-for en la solicitud, su valor se establecerá en el valor de client-ip en Edge Analytics.
x-forwarded-host: (predeterminado: true) Establece este valor en falso para evitar que los encabezados x-forwarded-host se pasen al destino.
x-request-id: (predeterminado: true) Establece este valor en falso para evitar que los encabezados x-request-id se pasen al destino.
x-response-time: (predeterminado: true) Establece en falso para evitar que los encabezados x-response-time se pasen al destino.
vía: (predeterminado: verdadero) Se establece en falso para evitar que los encabezados vía se pasen al destino.

Atributos de OAuth

Estos parámetros de configuración determinan cómo Edge Microgateway aplica la autenticación del cliente.

allowNoAuthorization: (valor predeterminado: false) Si se establece en verdadero, se permite que las llamadas a la API pasen por Edge Microgateway sin ningún encabezado de autorización. Establece este valor en falso para requerir un encabezado de autorización (predeterminado).
allowInvalidAuthorization: (valor predeterminado: false) Si se configura como verdadero, se permite el paso de las llamadas a la API si el token que se pasó en el encabezado de autorización no es válido o venció. Establece este parámetro en falso para requerir tokens válidos (opción predeterminada).
authorization-header: (valor predeterminado: Authorization: Bearer) Es el encabezado que se usa para enviar el token de acceso a Edge Microgateway. Es posible que desees cambiar el valor predeterminado en los casos en que el destino necesite usar el encabezado de autorización para algún otro propósito.
api-key-header: (valor predeterminado: x-api-key) Es el nombre del encabezado o parámetro de consulta que se usa para pasar una clave de API a Edge Microgateway. Consulta también Cómo usar una clave de API.
keep-authorization-header: (valor predeterminado: false) Si se establece en verdadero, el encabezado Authorization enviado en la solicitud se pasa al destino (se conserva).
allowOAuthOnly: Si se establece en verdadero, cada API debe incluir un encabezado de autorización con un token de acceso de portador. Te permite habilitar solo el modelo de seguridad de OAuth (y mantener la retrocompatibilidad). (Se agregó en la versión 2.4.x)
allowAPIKeyOnly: Si se establece en verdadero, cada API debe incluir un encabezado x-api-key (o una ubicación personalizada) con una clave de API.Te permite habilitar solo el modelo de seguridad de la clave de API (y mantener la compatibilidad con versiones anteriores). (Se agregó en la versión 2.4.x)
No establezcas allowOAuthOnly y allowAPIKeyOnly en verdadero. La configuración predeterminada es que ambas marcas se establezcan en falso (para la retrocompatibilidad).
gracePeriod: Este parámetro ayuda a evitar errores causados por pequeñas discrepancias entre el reloj del sistema y las horas de No antes de (nbf) o Emitido en (iat) especificadas en el token de autorización JWT. Establece este parámetro en la cantidad de segundos que se permitirán para tales discrepancias. (Se agregó en la versión 2.5.7)

Atributos específicos del complemento

Consulta Uso de complementos para obtener detalles sobre los atributos configurables de cada complemento.

Proxies de filtrado

Puedes filtrar los proxies compatibles con microgateway que procesará una instancia de Edge Microgateway. Cuando se inicia Edge Microgateway, se descargan todos los proxies compatibles con microgateway de la organización con la que está asociado. Usa la siguiente configuración para limitar los proxies que procesará el microgateway. Por ejemplo, esta configuración limita a tres los proxies que procesará la microgateway: edgemicro_proxy-1, edgemicro_proxy-2 y edgemicro_proxy-3:

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

Filtrar productos por nombre

Usa la siguiente configuración para limitar la cantidad de productos de API que Edge Microgateway descarga y procesa. Para filtrar los productos descargados, agrega el parámetro de búsqueda productnamefilter a la API de /products que se indica en el archivo *.config.yaml de Edge Microgateway. Por ejemplo:

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

Ten en cuenta que el valor del parámetro de búsqueda debe especificarse en formato de expresión regular y estar codificado como URL. Por ejemplo, la expresión regular ^[Ee]dgemicro.*$ detecta nombres como los siguientes: "edgemicro-test-1" , "edgemicro_demo" y "Edgemicro_New_Demo". El valor codificado como URL, adecuado para usar en el parámetro de consulta, es: %5E%5BEe%5Ddgemicro.%2A%24.

El siguiente resultado de depuración muestra que solo se descargaron los productos filtrados:

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

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

         ]
      },
      {
         "apiResources":[

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

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

         ]
      }
   ]
}

Cómo filtrar productos por atributos personalizados

Para filtrar productos según atributos personalizados, sigue estos pasos:

En la IU de Edge, selecciona el proxy edgemicro_auth en la organización o el entorno en el que configuraste Edge Microgateway.
En la pestaña Develop, abre la política JavaCallout en el editor.
Agrega un atributo personalizado con la clave products.filter.attributes y una lista separada por comas de nombres de atributos. Solo se devolverán a Edge Microgateway los productos que contengan cualquiera de los nombres de atributos personalizados.
De manera opcional, puedes inhabilitar la verificación para ver si el producto está habilitado para el entorno actual configurando el atributo personalizado products.filter.env.enable como false. (El valor predeterminado es verdadero).
(Solo para la nube privada) Si usas Edge para la nube privada, establece la propiedad org.noncps en true para extraer productos para entornos que no son de CPS.

Por ejemplo:

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

Cómo filtrar productos por estado de revocación

Los productos de API tienen tres códigos de estado: Pendiente, Aprobado y Revocado. Se agregó una nueva propiedad llamada allowProductStatus a la política Set JWT Variables en el proxy edgemicro-auth. Para usar esta propiedad y filtrar los productos de API que se indican en el JWT, haz lo siguiente:

Abre el proxy edgemicro-auth en el editor de proxy de Apigee.

Agrega la propiedad allowProductStatus al XML de la política SetJWTVariables y especifica una lista de códigos de estado separados por comas para filtrar. Por ejemplo, para filtrar por los estados Pendiente y Revocado, haz lo siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript timeLimit="20000" async="false" continueOnError="false"
    enabled="true" name="Set-JWT-Variables">
    <DisplayName>Set JWT Variables</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="allowProductStatus">Pending,Revoked</Property>
    </Properties>
    <ResourceURL>jsc://set-jwt-variables.js</ResourceURL>
</Javascript>

Si solo quieres que se muestren los productos Aprobados, configura la propiedad de la siguiente manera:

<Property name="allowProductStatus">Approved</Property>

Guarda el proxy.
Si no está presente la etiqueta Property, en el JWT se incluirán los productos con todos los códigos de estado.

Para usar esta nueva propiedad, debes actualizar el proxy edgemicro-auth.

Configura la frecuencia de envío de estadísticas

Usa estos parámetros de configuración para controlar la frecuencia con la que Edge Microgateway envía datos de estadísticas a Apigee:

bufferSize (opcional): Es la cantidad máxima de registros de Analytics que el búfer puede contener antes de comenzar a descartar los registros más antiguos. Valor predeterminado: 10,000
batchSize (opcional): Es el tamaño máximo de un lote de registros de Analytics que se envían a Apigee. Valor predeterminado: 500
flushInterval (opcional): Es la cantidad de milisegundos entre cada vaciado de un lote de registros de Analytics enviados a Apigee. Valor predeterminado: 5,000

Por ejemplo:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

Enmascaramiento de datos de análisis

La siguiente configuración evita que la información de la ruta de acceso a la solicitud aparezca en las estadísticas de Edge. Agrega lo siguiente a la configuración de microgateway para enmascarar el URI de solicitud o la ruta de acceso de la solicitud. Ten en cuenta que el URI consta del nombre de host y las partes de la ruta de acceso de la solicitud.

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

Cómo separar las llamadas a la API en Edge Analytics

Puedes configurar el complemento de Analytics para segregar una ruta de acceso a la API específica de modo que aparezca como un proxy independiente en los paneles de Edge Analytics. Por ejemplo, puedes segregar una API de verificación de estado en el panel para evitar confundirla con las llamadas reales al proxy de API. En el panel de Analytics, los proxies segregados siguen este patrón de nomenclatura:

edgemicro_proxyname-health

En la siguiente imagen, se muestran dos proxies segregados en el panel de Analytics: edgemicro_hello-health y edgemicro_mock-health:

Usa estos parámetros para separar las rutas de acceso relativas y absolutas en el panel de Analytics como proxies independientes:

relativePath (opcional): Especifica una ruta de acceso relativa para segregar en el panel de Analytics. Por ejemplo, si especificas /healthcheck, todas las llamadas a la API que contengan la ruta de acceso /healthcheck aparecerán en el panel como edgemicro_proxyname-health. Ten en cuenta que esta marca ignora la ruta base del proxy. Para segregar en función de una ruta de acceso completa, incluida la ruta de acceso base, usa la marca proxyPath.
proxyPath (opcional): Especifica una ruta de acceso completa del proxy de API, incluida la ruta base del proxy, para segregarla en el panel de Analytics. Por ejemplo, si especificas /mocktarget/healthcheck, donde /mocktarget es la ruta base del proxy, todas las llamadas a la API con la ruta /mocktarget/healthcheck aparecerán en el panel como edgemicro_proxyname-health.

Por ejemplo, en la siguiente configuración, el complemento de Analytics separará cualquier ruta de API que contenga /healthcheck. Esto significa que /foo/healthcheck y /foo/bar/healthcheck se segregarán como un proxy independiente llamado edgemicro_proxyname-health en el panel de Analytics.

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

En la siguiente configuración, cualquier API con la ruta de proxy /mocktarget/healthcheck se segregarán como un proxy independiente llamado edgemicro_proxyname-health en el panel de estadísticas.

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

Configura Edge Microgateway detrás de un firewall de la empresa

Usa un proxy HTTP para la comunicación con Apigee Edge

Se agregó en la versión 3.1.2.

Para usar un proxy HTTP para la comunicación entre Edge Microgateway y Apigee Edge, haz lo siguiente:

Configura las variables de entorno HTTP_PROXY, HTTPS_PROXY y NO_PROXY. Estas variables controlan los hosts de cada proxy HTTP que deseas usar para la comunicación con Apigee Edge, o bien qué hosts no deben controlar la comunicación con Apigee Edge. Por ejemplo:
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
Ten en cuenta que NO_PROXY puede ser una lista de dominios delimitada por comas a los que Edge Microgateway no debería enviar solicitudes a través de proxy.

Para obtener más información sobre estas variables, consulta https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables
Reinicia Edge Microgateway.

Usa un proxy HTTP para la comunicación de destino

Se agregó en la versión 3.1.2.

Para usar un proxy HTTP para la comunicación entre Edge Microgateway y los destinos de backend, haz lo siguiente:

Agrega la siguiente configuración al archivo de configuración de microgateway:
```
edgemicro:
  proxy:
    tunnel: true | false
    url: proxy_url
    bypass: target_host # target hosts to bypass the proxy.
    enabled: true | false
```
Donde:
- tunnel: (Opcional) Cuando es verdadero, Edge Microgateway usa el método HTTP CONNECT para crear un túnel de solicitudes HTTP a través de una sola conexión TCP. (Lo mismo sucede si las variables de entorno, como se menciona a continuación, para configurar el proxy tienen habilitado TLS). Predeterminada: false
- url: Es la URL del proxy HTTP.
- bypass: (Opcional) Especifica una o más URLs de host de destino separadas por comas que deben omitir el proxy HTTP. Si no se configura esta propiedad, usa la variable de entorno NO_PROXY para especificar qué URLs de destino se deben omitir.
- habilitado: Si es verdadero y proxy.url está configurado, usa el valor de proxy.url para el proxy HTTP. Si es verdadero y no se configura proxy.url, usa los proxies especificados en las variables de entorno del proxy HTTP HTTP_PROXY y HTTPS_PROXY, como se describe en Usa un proxy HTTP para la comunicación con Apigee Edge.
Por ejemplo:
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
NOTA: Nota: Si se omite edgemicro.proxy en el archivo de configuración o si edgemicro.proxy.enabled es falso, Edge Microgateway no usará un proxy HTTP para la comunicación de destino.
Reinicia Edge Microgateway.

Usa comodines en proxies compatibles con Microgateway

Puedes usar uno o más comodines "*" en la ruta base de un proxy edgemicro_* (compatible con Microgateway). Por ejemplo, una ruta base de /team/*/members permite que los clientes llamen a https://[host]/team/blue/members y a https://[host]/team/green/members sin necesidad de crear proxies de API nuevos para admitir equipos nuevos. Ten en cuenta que no se admite /**/.

Importante: Apigee NO admite el uso de un comodín “*” como el primer elemento de una ruta base. Por ejemplo, NO se admite la búsqueda de /*/.

Rotación de claves JWT

Cómo Edge Microgateway usa JWTs

El token web JSON (JWT) es un estándar de token que se describe en RFC7519. Los JWT proporcionan una forma de firmar un conjunto de reclamaciones, que el destinatario del JWT puede verificar de forma confiable.

Puedes generar un JWT con la CLI y usarlo en el encabezado de autorización de las llamadas a la API en lugar de una clave de API. Por ejemplo:

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

Para obtener información sobre cómo generar JWTs con la CLI, consulta Genera un token.

¿Qué es la rotación de claves?

En algún momento, después de generar un JWT por primera vez, es posible que debas cambiar el par de claves públicas/privadas almacenado en el KVM encriptado de Edge. Este proceso de generación de un par de claves nuevo se denomina rotación de claves. Cuando rotas las claves, se genera un nuevo par de claves públicas/privadas y se almacena en el KVM “microgateway” en tu organización o entorno de Apigee Edge. Además, la clave pública anterior se conserva junto con su valor de ID de clave original.

Para generar un JWT, Edge usa la información almacenada en la KVM encriptada. Se creó un KVM llamado microgateway y se completó con claves cuando configuraste inicialmente Edge Microgateway. Las claves de la KVM se usan para firmar y encriptar un JWT.

Las claves del KVM incluyen lo siguiente:

private_key: Es la clave privada RSA más reciente (creada más recientemente) que se usa para firmar JWTs.
public_key: Es el certificado más reciente (creado más recientemente) que se usa para verificar los JWT firmados con private_key.
private_key_kid: Es el ID de la clave privada más reciente (creada recientemente). Este ID de clave está asociado al valor de private_key y se usa para admitir la rotación de claves.
public_key1_kid: Es el ID de la clave pública más reciente (creada recientemente). Esta clave se asocia con el valor de public_key1 y se usa para admitir la rotación de claves. Este valor es el mismo que el KID de la clave privada.
public_key1: Es la clave pública más reciente (creada más recientemente).

Cuando realizas la rotación de claves, los valores de clave existentes se reemplazan en el mapa y se agregan claves nuevas para conservar las claves públicas anteriores. Por ejemplo:

public_key2_kid: Es el ID de la clave pública anterior. Esta clave está asociada al valor de public_key2 y se usa para admitir la rotación de claves.
public_key2: Es la clave pública anterior.

Los JWTs que se presenten para su verificación se verificarán con la nueva clave pública. Si falla la verificación, se usará la clave pública anterior hasta que venza el JWT (después del intervalo token_expiry*, que es de 30 minutos de forma predeterminada). De esta manera, puedes "rotar" las claves sin interrumpir de inmediato el tráfico de la API.

Cómo rotar las claves

En esta sección, se explica cómo realizar una rotación de claves.

Para actualizar KVM, usa el comando edgemicro upgradekvm. Para obtener detalles sobre cómo ejecutar este comando, consulta Cómo actualizar KVM. Solo debes realizar este paso una vez.
Para actualizar el proxy edgemicro-oauth, usa el comando edgemicro upgradeauth. Para obtener detalles sobre cómo ejecutar este comando, consulta cómo actualizar el proxy de edgemicro-auth. Solo debes realizar este paso una vez.
Agrega la siguiente línea a tu archivo ~/.edgemicro/org-env-config.yaml, en la que debes especificar la misma organización y el mismo entorno para los que configuraste el microgateway:
```
jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
```

Ejecuta el comando de rotación de claves para rotarlas. Para obtener detalles sobre este comando, consulta Rotación de claves.

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

Por ejemplo:

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

Después de la rotación de claves, Edge devuelve varias claves a Edge Microgateway. Ten en cuenta que, en el siguiente ejemplo, cada clave tiene un valor "kid" (ID de clave) único. Luego, el microgateway usa estas claves para validar los tokens de autorización. Si falla la validación del token, el microgateway busca si hay una clave más antigua en el conjunto de claves y prueba con esa clave. El formato de las claves devueltas es JSON Web Key (JWK). Puedes leer sobre este formato en 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"
    }
  ]
}

Cómo configurar una demora de "no antes de"

En las versiones 3.1.5 y anteriores, la nueva clave privada generada por el comando rotatekey entraba en vigencia de inmediato, y los tokens nuevos generados se firmaban con la nueva clave privada. Sin embargo, la nueva clave pública solo estaba disponible para las instancias de Edge Microgateway cada 10 minutos (de forma predeterminada) cuando se actualizaba la configuración del microgateway. Debido a este retraso entre la firma del token y la actualización de la instancia de microgateway, los tokens firmados con la clave más reciente se rechazarían hasta que todas las instancias recibieran la clave pública más reciente.

En los casos en que existen varias instancias de microgateway, el retraso de la clave pública a veces provocaba errores intermitentes de tiempo de ejecución con el estado 403, ya que la validación del token se realizaba correctamente en una instancia, pero fallaba en otra hasta que se actualizaban todas las instancias.

A partir de la versión 3.1.6, una nueva marca en el comando rotatekey te permite especificar una demora para que la nueva clave privada entre en vigencia, lo que permite que todas las instancias de microgateway se actualicen y reciban la nueva clave pública. La nueva marca es --nbf, que significa "no antes de". Esta marca toma un valor entero, la cantidad de minutos de retraso.

En el siguiente ejemplo, la demora se establece en 15 minutos:

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

Ten en cuenta que una buena práctica es establecer la demora en más que el parámetro de configuración config_change_poll_internal, que es de 10 minutos de forma predeterminada. Consulta también los atributos de edgemicro.

Cómo filtrar proxies descargados

De forma predeterminada, Edge Microgateway descarga todos los proxies de tu organización de Edge que comienzan con el prefijo de nomenclatura "edgemicro_". Puedes cambiar este valor predeterminado para descargar proxies cuyos nombres coincidan con un patrón.

Abre el archivo de configuración de Edge Micro: ~/.edgemicro/org-env-config.yaml
Agrega el elemento proxyPattern en edge_config. Por ejemplo, el siguiente patrón descargará proxies como edgemicro_foo, edgemicro_fast y edgemicro_first.
```
edge_config:
…
proxyPattern: edgemicro_f*
```

Cómo especificar productos sin proxies de API

En Apigee Edge, puedes crear un producto de API que no contenga proxies de API. Esta configuración del producto permite que una clave de API asociada a ese producto funcione con cualquier proxy implementado en tu organización. A partir de la versión 2.5.4, Edge Microgateway admite esta configuración del producto.

Depuración y solución de problemas

Cómo conectarse a un depurador

Puedes ejecutar Edge Microgateway con un depurador, como node-inspector. Esto es útil para solucionar problemas y depurar complementos personalizados.

Reinicia Edge Microgateway en modo de depuración. Para ello, agrega DEBUG=* al comienzo del comando start:
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
NOTA: En Windows, usa SET DEBUG=*

Para dirigir la salida de depuración a un archivo, puedes usar este comando:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Inicia el depurador y configúralo para que escuche el número de puerto del proceso de depuración.
Ahora puedes revisar el código de Edge Microgateway, establecer interrupciones, observar expresiones y mucho más.

Puedes especificar marcas estándar de Node.js relacionadas con el modo de depuración. Por ejemplo, --nolazy ayuda a depurar código asíncrono.

Cómo verificar los archivos de registro

Si tienes problemas, asegúrate de examinar los archivos de registro para obtener detalles de la ejecución y la información de los errores. Para obtener más información, consulta Administra archivos de registro.

Cómo usar la seguridad de las claves de API

Las claves de API proporcionan un mecanismo simple para autenticar a los clientes que realizan solicitudes a Edge Microgateway. Para obtener una clave de API, copia el valor de la clave de consumidor (también llamado ID de cliente) de un producto de Apigee Edge que incluya el proxy de autenticación de Edge Microgateway.

Almacenamiento en caché de claves

Las claves de API se intercambian por tokens de portador, que se almacenan en caché. Para inhabilitar el almacenamiento en caché, configura el encabezado Cache-Control: no-cache en las solicitudes entrantes a Edge Microgateway.

Usa una clave de API

Puedes pasar la clave de API en una solicitud a la API como un parámetro de consulta o en un encabezado. De forma predeterminada, el encabezado y el nombre del parámetro de consulta son x-api-key.

Ejemplo de parámetro de consulta:

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

Ejemplo del encabezado:

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

Cómo configurar el nombre de la clave de API

De forma predeterminada, x-api-key es el nombre que se usa tanto para el encabezado de la clave de API como para el parámetro de consulta. Puedes cambiar este valor predeterminado en el archivo de configuración, como se explica en Cómo realizar cambios en la configuración. Por ejemplo, para cambiar el nombre a apiKey, haz lo siguiente:

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

En este ejemplo, tanto el parámetro de consulta como el nombre del encabezado se cambian a apiKey. El nombre x-api-key ya no funcionará en ninguno de los casos. Consulta también Cómo realizar cambios de configuración.

Por ejemplo:

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

Para obtener más información sobre el uso de claves de API con solicitudes de proxy, consulta Protege Edge Microgateway.

Habilita los códigos de respuesta ascendentes

De forma predeterminada, el complemento oauth solo devuelve códigos de estado de error 4xx si la respuesta no tiene el estado 200. Puedes cambiar este comportamiento para que siempre devuelva el código 4xx o 5xx exacto, según el error.

Para habilitar esta función, agrega la propiedad oauth.useUpstreamResponse: true a la configuración de Edge Microgateway. Por ejemplo:

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

Cómo usar la seguridad de tokens de OAuth2

En esta sección, se explica cómo obtener tokens de acceso y actualización de OAuth2. Los tokens de acceso se usan para realizar llamadas seguras a la API a través de la micropuerta de enlace. Los tokens de actualización se usan para obtener tokens de acceso nuevos.

Cómo obtener un token de acceso

En esta sección, se explica cómo usar el proxy edgemicro-auth para obtener un token de acceso.

También puedes obtener un token de acceso con el comando de la CLI de edgemicro token. Para obtener detalles sobre la CLI, consulta Administración de tokens.

API 1: Envía credenciales como parámetros del cuerpo

Sustituye los nombres de tu organización y entorno en la URL, y reemplaza los valores de ID de consumidor y secreto del consumidor obtenidos de una app para desarrolladores en Apigee Edge por los parámetros del cuerpo client_id y 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: Envía credenciales en un encabezado de autenticación básica

Envía las credenciales de cliente como un encabezado de autenticación básica y el grant_type como un parámetro de formulario. Esta forma de comando también se analiza en RFC 6749: The OAuth 2.0 Authorization Framework.

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"

Resultado de muestra

La API devuelve una respuesta JSON. Ten en cuenta que no hay diferencia entre las propiedades token y access_token. Puedes usar cualquiera de los dos. Ten en cuenta que expires_in es un valor entero especificado en segundos.

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

Cómo obtener un token de actualización

Para obtener un token de actualización, realiza una llamada a la API al extremo /token del proxy edgemicro-auth. DEBES realizar esta llamada a la API con el tipo de otorgamiento password. En los siguientes pasos, se describe el proceso.

Obtén un token de acceso y un token de actualización con la API de /token. Ten en cuenta que el tipo de otorgamiento es 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"
}'

La API devuelve un token de acceso y un token de actualización. La respuesta es similar a esta. Ten en cuenta que los valores de expires_in son números enteros y se especifican en segundos.

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

Ahora puedes usar el token de actualización para obtener un nuevo token de acceso llamando al extremo /refresh de la misma API. Por ejemplo:

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

La API devuelve un nuevo token de acceso. La respuesta es similar a la siguiente:

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

Supervisión permanente

Forever es una herramienta de Node.js que reinicia automáticamente una app de Node.js en caso de que el proceso se detenga o tenga un error. Edge Microgateway tiene un archivo forever.json que puedes configurar para controlar cuántas veces y con qué intervalos se debe reiniciar Edge Microgateway. Este archivo configura un servicio Forever llamado forever-monitor, que administra Forever de forma programática.

Puedes encontrar el archivo forever.json en el directorio raíz de instalación de Edge Microgateway. Consulta Dónde se instala Edge Microgateway. Para obtener detalles sobre las opciones de configuración, consulta la documentación de forever-monitor.

El comando edgemicro forever incluye marcas que te permiten especificar la ubicación del archivo forever.json (la marca -f) y comenzar o detener el proceso de supervisión de Forever (la marca -a). Por ejemplo:

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

Para obtener más información, consulta Forever monitoring en la referencia de la CLI.

Cómo especificar un extremo de archivo de configuración

Si ejecutas varias instancias de Edge Microgateway, es posible que desees administrar sus configuraciones desde una sola ubicación. Para ello, especifica un extremo HTTP en el que Edge Microgateway pueda descargar su archivo de configuración. Puedes especificar este extremo cuando inicies Edge Micro con la marca -u.

Por ejemplo:

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

donde el extremo de mgconfig devuelve el contenido de tu archivo de configuración. Este es el archivo que, de forma predeterminada, se encuentra en ~/.edgemicro y tiene la siguiente convención de nomenclatura: org-env-config.yaml.

Cómo inhabilitar el almacenamiento en búfer de datos de conexión TCP

Puedes usar el atributo de configuración nodelay para inhabilitar el almacenamiento en búfer de datos para las conexiones TCP que usa Edge Microgateway.

De forma predeterminada, las conexiones TCP usan el algoritmo de Nagle para almacenar datos en búfer antes de enviarlos. Si se configura nodelay como true, se inhabilita este comportamiento (los datos se enviarán de inmediato cada vez que se llame a socket.write()). Consulta también la documentación de Node.js para obtener más detalles.

Para habilitar nodelay, edita el archivo de configuración de Edge Micro de la siguiente manera:

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

Ejecuta Edge Microgateway en modo independiente

Puedes ejecutar Edge Microgateway completamente desconectado de cualquier dependencia de Apigee Edge. Este escenario, llamado modo independiente, te permite ejecutar y probar Edge Microgateway sin conexión a Internet.

En el modo independiente, no funcionan las siguientes funciones, ya que requieren conexión a Apigee Edge:

OAuth y clave de API
Cuota
Analytics

Por otro lado, los complementos personalizados y la detención de picos funcionan normalmente, ya que no requieren una conexión a Apigee Edge. Además, un nuevo complemento llamado extauth te permite autorizar llamadas a la API del microgateway con un JWT mientras se encuentra en modo independiente.

Configura e inicia la puerta de enlace

Para ejecutar Edge Microgateway en modo independiente, haz lo siguiente:

Crea un archivo de configuración con el siguiente nombre: $HOME/.edgemicro/$ORG-$ENV-config.yaml
Puedes usar los valores que desees para $ORG y $ENV en el nombre del archivo. La combinación de organización y entorno es simplemente una convención que permite que Edge Microgateway encuentre el archivo cuando se inicia.

Por ejemplo:
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
Pega el siguiente código en el archivo:
```
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
```
El archivo de configuración contiene un complemento especial y opcional llamado extauth. Este complemento verifica un token JWT válido que se pasa al microgateway. En un paso posterior, aprenderás a obtener y usar el token. Además, ten en cuenta que el complemento spikearrest se incluye porque no depende de la conectividad con Edge. Los complementos quota, oauth y analytics se excluyen porque dependen de la conectividad con Edge y no funcionarán en el modo desconectado. Se permiten los complementos personalizados y funcionarán como se espera.
Exporta la siguiente variable de entorno con el valor "1":
```
export EDGEMICRO_LOCAL=1
```
Ejecuta el siguiente comando de start, en el que proporcionas valores para crear una instancia del proxy local:
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
Donde:
- $ORG es el nombre de la organización que usaste en el nombre del archivo de configuración.
- $ENV es el nombre de "env" que usaste en el nombre del archivo de configuración.
- $LOCAL_PROXY_NAME es el nombre del proxy local que se creará. Puedes usar el nombre que quieras.
- $LOCAL_PROXY_VERSION es el número de versión del proxy.
- $TARGET_URL es la URL del destino del proxy. (El destino es el servicio al que llama el proxy).
- $BASE_PATH es la ruta base del proxy. Este valor debe comenzar con una barra diagonal. Para una ruta base raíz, especifica solo una barra, por ejemplo, "/".
Por ejemplo:
```
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Probar la configuración
```
curl http://localhost:8000/echo  { "error" : "missing_authorization" }
```
Como el complemento extauth está en el archivo foo-bar-config.yaml, obtienes un error "missing_authorization". Este complemento valida un JWT que debe estar presente en el encabezado de autorización de la llamada a la API. En la siguiente sección, obtendrás un JWT que permitirá que las llamadas a la API se realicen sin el error.

Ejemplo: Obtención de un token de autorización

En el siguiente ejemplo, se muestra cómo obtener un JWT del extremo JWT de Edge Microgateway en Apigee Edge (edgemicro-auth/jwkPublicKeys). Este extremo se implementa cuando realizas una configuración estándar de Edge Microgateway. Para obtener el JWT del extremo de Apigee, primero debes realizar la configuración estándar de Edge Microgateway y conectarte a Internet. El extremo de Apigee se usa aquí solo como ejemplo y no es obligatorio. Si lo deseas, puedes usar otro extremo de token JWT. Si lo haces, deberás obtener el JWT con la API proporcionada para ese extremo.

Incluir el complemento extauth en la configuración de tu microgateway es opcional, pero, si lo haces, deberás proporcionar un token JWT válido en el encabezado de autorización para las llamadas a la API.

En los siguientes pasos, se explica cómo obtener un token con el extremo edgemicro-auth/jwkPublicKeys:

Debes realizar una configuración estándar de Edge Microgateway para implementar el proxy edgemicro-auth en tu organización o entorno en Apigee Edge. Si ya realizaste este paso, no es necesario que lo repitas.
Si implementaste Edge Microgateway en Apigee Cloud, debes tener conexión a Internet para obtener un JWT de este extremo.
Detén Edge Microgateway:
```
edgemicro stop
```
En el archivo de configuración que creaste anteriormente ($HOME/.edgemicro/org-env-config.yaml), dirige el atributo extauth:publickey_url al endpoint edgemicro-auth/jwkPublicKeys en tu organización o entorno de Apigee Edge. Por ejemplo:
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Reinicia Edge Microgateway como lo hiciste antes, con los nombres de organización o entorno que usaste en el nombre del archivo de configuración. Por ejemplo:
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Obtén un token JWT del extremo de autorización. Como usas el extremo edgemicro-auth/jwkPublicKeys, puedes usar este comando de la CLI:
Para este paso, necesitarás una conexión a Internet. El siguiente comando recupera un token de Apigee Edge. Para realizar este paso, debes tener una organización de Apigee en la que hayas realizado una configuración estándar de Edge Microgateway. Después de realizar este paso, no es necesario que te conectes a Internet. El token seguirá funcionando en el modo independiente hasta que venza.

Puedes generar un JWT para Edge Microgateway con el comando edgemicro token o una API. Por ejemplo:

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

Donde:

your_org es el nombre de tu organización de Apigee para la que configuraste Edge Microgateway anteriormente.
your_env es un entorno en la organización.
La opción i especifica la clave de consumidor de una app para desarrolladores que tiene un producto que incluye el proxy edgemicro-auth.
La opción s especifica el secreto del consumidor de una app para desarrolladores que tiene un producto que incluye el proxy edgemicro-auth.

Este comando le solicita a Apigee Edge que genere un JWT que luego se puede usar para verificar las llamadas a la API.

Consulta también Genera un token.

Prueba la configuración independiente

Para probar la configuración, llama a la API con el token agregado en el encabezado de autorización de la siguiente manera:

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

Ejemplo:

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

Resultado de ejemplo:

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

Cómo usar el modo de proxy local

En el modo de proxy local, Edge Microgateway no requiere que se implemente un proxy adaptado a microgateway en Apigee Edge. En cambio, debes configurar un "proxy local" proporcionando un nombre de proxy local, una ruta base y una URL de destino cuando inicies el microgateway. Luego, las llamadas a la API del microgateway se envían a la URL de destino del proxy local. En todos los demás aspectos, el modo de proxy local funciona exactamente igual que ejecutar Edge Microgateway en su modo normal. La autenticación funciona de la misma manera, al igual que la detención de picos y la aplicación de cuotas, los complementos personalizados, etcétera.

Las dos diferencias importantes entre el modo local y la configuración normal de Edge Microgateway son las siguientes: (1) En el modo local, no necesitas crear un proxy compatible con microgateway en Apigee Edge y (2) cuando creas un producto de API en Edge, debes agregarle solo un proxy, el proxy edgemicro-auth. No es necesario que agregues ningún otro proxy al producto.

Caso de uso y ejemplo

El modo de proxy local es útil cuando solo necesitas asociar un proxy único con una instancia de Edge Microgateway. Por ejemplo, puedes incorporar Edge Microgateway en Kubernetes como un proxy sidecar, en el que un microgateway y un servicio se ejecutan en un solo Pod, y en el que el microgateway administra el tráfico hacia y desde su servicio complementario. En la siguiente figura, se ilustra esta arquitectura en la que Edge Microgateway funciona como un proxy sidecar en un clúster de Kubernetes. Cada instancia de microgateway se comunica solo con un extremo en su servicio complementario:

Edgemicro como Sidecar

Un beneficio de este estilo de arquitectura es que Edge Microgateway proporciona administración de APIs para servicios individuales implementados en un entorno de contenedores, como un clúster de Kubernetes.

Cómo configurar el modo de proxy local

Para configurar Edge Microgateway de modo que se ejecute en el modo de proxy local, sigue estos pasos:

Ejecuta edgemicro init para configurar tu entorno de configuración local, exactamente como lo harías en una configuración típica de Edge Microgateway. Consulta también Cómo configurar Edge Microgateway.
Ejecuta edgemicro configure, como lo harías en un procedimiento de configuración típico de Edge Microgateway. Por ejemplo:
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
Este comando implementa la política edgemicro-auth en Edge y devuelve una clave y un secreto que necesitarás para iniciar el microgateway. Si necesitas ayuda, consulta Cómo configurar Edge Microgateway.
En Apigee Edge, crea un producto de API con los siguientes requisitos de configuración obligatorios (puedes administrar todas las demás configuraciones como desees):
- Debes agregar el proxy edgemicro-auth al producto. Este proxy se implementó automáticamente cuando ejecutaste edgemicro configure.
- Debes proporcionar una ruta de acceso al recurso. Apigee recomienda agregar esta ruta de acceso al producto: /**. Para obtener más información, consulta Cómo configurar el comportamiento de la ruta de recursos. Consulta también Crea productos de API en la documentación de Edge.
En Apigee Edge, crea un desarrollador o puedes usar uno existente si lo deseas. Si necesitas ayuda, consulta Cómo agregar desarrolladores con la IU de administración de Edge.
En Apigee Edge, crea una app para desarrolladores. Debes agregar el producto de API que acabas de crear a la app. Si necesitas ayuda, consulta Cómo registrar una app en la IU de administración de Edge.
En la máquina en la que está instalado Edge Microgateway, exporta la siguiente variable de entorno con el valor "1".
```
export EDGEMICRO_LOCAL_PROXY=1
```
Ejecuta el siguiente comando de 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
```
Donde:
- your_org es tu organización de Apigee.
- your_environment es un entorno en tu organización.
- your_key es la clave que se devolvió cuando ejecutaste edgemicro configure.
- your_secret es el secreto que se devolvió cuando ejecutaste edgemicro configure.
- local_proxy_name es el nombre del proxy local que se creará.
- local_proxy_version es el número de versión del proxy.
- target_url es la URL del destino del proxy (el servicio al que llamará el proxy).
- base_path es la ruta base del proxy. Este valor debe comenzar con una barra diagonal. Para una ruta base raíz, especifica solo una barra, por ejemplo, "/".
Por ejemplo:
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

Prueba la configuración

Puedes probar la configuración del proxy local llamando al extremo del proxy. Por ejemplo, si especificaste una ruta base de /echo, puedes llamar al proxy de la siguiente manera:

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

Esta llamada inicial a la API produjo un error porque no proporcionaste una clave de API válida. Puedes encontrar la clave en la app para desarrolladores que creaste anteriormente. Abre la app en la IU de Edge, copia la clave de consumidor y usa esa clave de la siguiente manera:

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

Por ejemplo:

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

Resultado de ejemplo:

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

Cómo usar el sincronizador

En esta sección, se explica cómo usar el sincronizador, una función opcional que mejora la capacidad de recuperación de Edge Microgateway, ya que le permite recuperar datos de configuración de Apigee Edge y escribirlos en una base de datos de Redis local. Con una instancia del sincronizador en ejecución, otras instancias de Edge Microgateway que se ejecutan en diferentes nodos pueden recuperar su configuración directamente desde esta base de datos.

Actualmente, la función de sincronizador es compatible con Redis 5.0.x.

¿Qué es el sincronizador?

El sincronizador proporciona un nivel de resiliencia para Edge Microgateway. Ayuda a garantizar que cada instancia de Edge Microgateway use la misma configuración y que, en caso de interrupción de Internet, las instancias de Edge Microgateway puedan iniciarse y ejecutarse correctamente.

De forma predeterminada, las instancias de Edge Microgateway deben poder comunicarse con Apigee Edge para recuperar y actualizar sus datos de configuración, como las configuraciones de productos de API y proxies de API. Si se interrumpe la conexión a Internet con Edge, las instancias de microgateway pueden seguir funcionando porque los datos de configuración más recientes se almacenan en caché. Sin embargo, las nuevas instancias de microgateway no pueden iniciarse sin una conexión clara. Además, es posible que una interrupción de Internet provoque que una o más instancias de microgateway se ejecuten con información de configuración que no esté sincronizada con otras instancias.

El sincronizador de Edge Microgateway proporciona un mecanismo alternativo para que las instancias de Edge Microgateway recuperen los datos de configuración que necesitan para iniciar y procesar el tráfico del proxy de API. Los datos de configuración recuperados de las llamadas a Apigee Edge incluyen la llamada jwk_public_keys, la llamada jwt_public_key, la llamada de arranque y la llamada a los productos de API. El sincronizador permite que todas las instancias de Edge Microgateway que se ejecutan en diferentes nodos se inicien correctamente y permanezcan sincronizadas, incluso si se interrumpe la conexión a Internet entre Edge Microgateway y Apigee Edge.

El sincronizador es una instancia de Edge Microgateway configurada de forma especial. Su único propósito es sondear Apigee Edge (el tiempo es configurable), recuperar datos de configuración y escribirlos en una base de datos local de Redis. La instancia del sincronizador en sí no puede procesar el tráfico del proxy de API. Otras instancias de Edge Microgateway que se ejecutan en diferentes nodos se pueden configurar para recuperar datos de configuración de la base de datos de Redis en lugar de Apigee Edge. Dado que todas las instancias de microgateway extraen sus datos de configuración de la base de datos local, pueden iniciarse y procesar solicitudes a la API incluso en caso de interrupción de Internet.

Configura una instancia de sincronizador

Agrega la siguiente configuración al archivo org-env/config.yaml para la instalación de Edge Microgateway que deseas usar como sincronizador:

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

Por ejemplo:

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

Opción	Descripción
`redisHost`	Es el host en el que se ejecuta tu instancia de Redis. Valor predeterminado: 127.0.0.1
`redisPort`	Es el puerto de la instancia de Redis. Valor predeterminado: 6379
`redisDb`	Es la base de datos de Redis que se usará. Valor predeterminado: 0
`redisPassword`	La contraseña de tu base de datos

Puedes usar la variable de entorno EDGEMICRO_REDIS_PASSWORD para anular el parámetro edgemicro.redisPassword. Consulta también Cómo establecer atributos de configuración con valores de variables de entorno.

Por último, guarda el archivo de configuración y, luego, inicia la instancia de Edge Microgateway. Comenzará a sondear Apigee Edge y a almacenar los datos de configuración descargados en la base de datos de Redis.

Configura instancias normales de Edge Microgateway

Con el sincronizador en ejecución, puedes configurar nodos adicionales de Edge Microgateway para ejecutar instancias regulares de microgateway que procesen el tráfico del proxy de API. Sin embargo, configuras estas instancias para que obtengan sus datos de configuración de la base de datos de Redis en lugar de Apigee Edge.

Agrega la siguiente configuración al archivo org-env/config.yaml de cada nodo adicional de Edge Microgateway. Ten en cuenta que la propiedad synchronizerMode está configurada como 0. Esta propiedad establece que la instancia opere como una instancia normal de Edge Microgateway que procesa el tráfico del proxy de API, y la instancia obtendrá sus datos de configuración de la base de datos de Redis.

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

Por ejemplo:

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

Propiedades de configuración

Se agregaron las siguientes propiedades de configuración para admitir el uso del sincronizador:

Atributo Valores Descripción

Atributo	Valores	Descripción
`edge_config.synchronizerMode`	0 o 1	Si es 0 (el valor predeterminado), Edge Microgateway funciona en su modo estándar. Si es 1, inicia la instancia de Edge Microgateway para que funcione como sincronizador. En este modo, la instancia extraerá datos de configuración de Apigee Edge y los almacenará en una base de datos local de Redis. Esta instancia no puede procesar solicitudes de proxy de API. Su único propósito es sondear Apigee Edge para obtener datos de configuración y escribirlos en la base de datos local. Luego, debes configurar otras instancias de microgateway para que lean desde la base de datos.
`edge_config.redisBasedConfigCache`	Verdadero o falso	Si es verdadero, la instancia de Edge Microgateway recupera sus datos de configuración de la base de datos de Redis en lugar de Apigee Edge. La base de datos de Redis debe ser la misma en la que se configuró el sincronizador para escribir. Si la base de datos de Redis no está disponible o está vacía, el microgateway busca un archivo `cache-config.yaml` existente para su configuración. Si es falso (valor predeterminado), la instancia de Edge Microgateway recupera los datos de configuración de Apigee Edge como de costumbre.
`edgemicro.config_change_poll_interval`	Intervalo de tiempo en segundos	Especifica el intervalo de sondeo para que el sincronizador extraiga datos de Apigee Edge.

edge_config.synchronizerMode

0 o 1

Si es 0 (el valor predeterminado), Edge Microgateway funciona en su modo estándar.

Si es 1, inicia la instancia de Edge Microgateway para que funcione como sincronizador. En este modo, la instancia extraerá datos de configuración de Apigee Edge y los almacenará en una base de datos local de Redis. Esta instancia no puede procesar solicitudes de proxy de API. Su único propósito es sondear Apigee Edge para obtener datos de configuración y escribirlos en la base de datos local. Luego, debes configurar otras instancias de microgateway para que lean desde la base de datos.

edge_config.redisBasedConfigCache

Verdadero o falso

Si es verdadero, la instancia de Edge Microgateway recupera sus datos de configuración de la base de datos de Redis en lugar de Apigee Edge. La base de datos de Redis debe ser la misma en la que se configuró el sincronizador para escribir. Si la base de datos de Redis no está disponible o está vacía, el microgateway busca un archivo cache-config.yaml existente para su configuración.

Si es falso (valor predeterminado), la instancia de Edge Microgateway recupera los datos de configuración de Apigee Edge como de costumbre.

edgemicro.config_change_poll_interval Intervalo de tiempo en segundos Especifica el intervalo de sondeo para que el sincronizador extraiga datos de Apigee Edge.

Cómo configurar URLs de exclusión para complementos

Puedes configurar el microgateway para que omita el procesamiento de complementos para URLs especificadas. Puedes configurar estas URLs de "exclusión" de forma global (para todos los complementos) o para complementos específicos.

Por ejemplo:

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

En este ejemplo, los complementos no procesarán las llamadas entrantes al proxy de API con las rutas de acceso /hello o /proxy_one. Además, se omitirá el complemento json2xml para las APIs que tengan /hello/xml en su ruta de acceso.

No puedes excluir el complemento analytics.

Cómo establecer atributos de configuración con valores de variables de entorno

Puedes especificar variables de entorno con etiquetas en el archivo de configuración. Las etiquetas de variables de entorno especificadas se reemplazan por los valores reales de las variables de entorno. Los reemplazos se almacenan solo en la memoria y no en los archivos de configuración o caché originales.

Nota: De forma predeterminada, la etiqueta <E> analiza los valores de las variables como cadenas. Para especificar valores booleanos y de números enteros positivos, usa las etiquetas internas <n> y <b>, como se ilustra en los siguientes ejemplos.

En este ejemplo, el atributo key se reemplaza por el valor de la variable de entorno TARGETS_SSL_CLIENT_KEY, y así sucesivamente.

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

En este ejemplo, la etiqueta <n> se usa para indicar un valor de número entero. Solo se admiten números enteros positivos.

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

En este ejemplo, la etiqueta <b> se usa para indicar un valor booleano (es decir, verdadero o falso).

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