Documentation de référence sur l'opération et la configuration d'Edge Micropasser

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Edge Microgateway v. 2.4.x

Présentation

Cette rubrique explique comment gérer et configurer Edge Microgateway, y compris la surveillance, la journalisation et le débogage.

 Modifier la configuration

Voici les fichiers de configuration à connaître :

• Fichier de configuration système par défaut
• Fichier de configuration par défaut pour une instance Edge Microgateway nouvellement initialisée
• Fichier de configuration dynamique pour les instances en cours d'exécution

Cette section traite de ces fichiers et de ce que vous devez savoir pour les modifier. Pour en savoir plus sur les paramètres du fichier de configuration, consultez la documentation de référence sur la configuration d'Edge Microgateway.

Fichier de configuration système par défaut

Lorsque vous installez Edge Microgateway, un fichier de configuration système par défaut est placé ici :

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

où [prefix] est le répertoire de préfixe npm. Consultez Où Edge Microgateway est-il installé ?.

Si vous modifiez le fichier de configuration système, vous devez réinitialiser, reconfigurer et redémarrer Edge Microgateway :

1. Appeler edgemicro init
2. Appeler edgemicro configure [params]
3. Appeler edgemicro start [params]

Fichier de configuration par défaut pour les instances Edge Microgateway nouvellement initialisées

Lorsque vous exécutez edgemicro init, le fichier de configuration système (décrit ci-dessus), default.yaml, est placé dans ce répertoire : ~/.edgemicro.

Si vous modifiez le fichier de configuration dans ~/.edgemicro, vous devez reconfigurer et redémarrer Edge Microgateway :

1. edgemicro stop
2. edgemicro configure [params]
3. edgemicro start [params]

Fichier de configuration dynamique pour les instances en cours d'exécution

Lorsque vous exécutez edgemicro configure [params], un fichier de configuration dynamique est créé dans ~/.edgemicro. Le fichier est nommé selon le modèle suivant : [org]-[env]-config.yaml, où org et env sont les noms de votre organisation et de votre environnement Apigee Edge. Vous pouvez utiliser ce fichier pour modifier la configuration, puis la recharger sans temps d'arrêt. Par exemple, si vous ajoutez et configurez un plug-in, vous pouvez recharger la configuration sans aucun temps d'arrêt, comme expliqué ci-dessous.

Si Edge Microgateway est en cours d'exécution (option sans temps d'arrêt) :

1. Rechargez la configuration d'Edge Microgateway :

   edgemicro reload -o [org] -e [env] -k [key] -s [secret]

   Où :

   • org est le nom de votre organisation Edge (vous devez être administrateur de l'organisation).
   • env est un environnement de votre organisation (par exemple, test ou production).
   • key est la clé renvoyée précédemment par la commande configure.
   • secret est la clé renvoyée précédemment par la commande de configuration.

   Exemple

   edgemicro reload -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824

Si Edge Microgateway est arrêté :

1. Redémarrez Edge Microgateway :

   edgemicro start -o [org] -e [env] -k [key] -s [secret]

   Où :

   • org est le nom de votre organisation Edge (vous devez être administrateur de l'organisation).
   • env est un environnement de votre organisation (par exemple, test ou production).
   • key est la clé renvoyée précédemment par la commande configure.
   • secret est la clé renvoyée précédemment par la commande de configuration.

   Exemple

   edgemicro start -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824

Voici un exemple de fichier de configuration. Pour en savoir plus sur les paramètres du fichier de configuration, consultez la documentation de référence sur la configuration d'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

Définir des variables d'environnement

Les commandes de l'interface de ligne de commande qui nécessitent des valeurs pour votre organisation et votre environnement Edge, ainsi que la clé et le secret nécessaires au démarrage d'Edge Microgateway, peuvent être stockées dans les variables d'environnement suivantes :

• EDGEMICRO_ORG
• EDGEMICRO_ENV
• EDGEMICRO_KEY
• EDGEMICRO_SECRET

La définition de ces variables est facultative. Si vous les définissez, vous n'avez pas besoin de spécifier leurs valeurs lorsque vous utilisez l'interface de ligne de commande (CLI) pour configurer et démarrer Edge Microgateway.

Configurer SSL sur le serveur Edge Microgateway

Vous pouvez configurer le serveur Microgateway pour qu'il utilise SSL. Par exemple, avec SSL configuré, vous pouvez appeler des API via Edge Microgateway avec le protocole "https", comme ceci :

https://localhost:8000/myapi

Pour configurer SSL sur le serveur Microgateway, procédez comme suit :

1. Générez ou obtenez un certificat et une clé SSL à l'aide de l'utilitaire openssl ou de la méthode de votre choix.
2. Ajoutez l'attribut edgemicro:ssl au fichier de configuration Edge Microgateway. Pour obtenir la liste complète des options, consultez le tableau ci-dessous. Pour savoir comment modifier la configuration d'Edge Microgateway, consultez Modifier la configuration. Par exemple :
   

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

3. Redémarrez Edge Microgateway. Suivez les étapes décrites dans Apporter des modifications à la configuration en fonction du fichier de configuration que vous avez modifié : le fichier par défaut ou le fichier de configuration du runtime.

Voici un exemple de la section "edgemicro" du fichier de configuration, avec SSL configuré :

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

Voici la liste de toutes les options de serveur compatibles :

Utiliser les options SSL/TLS du client

Vous pouvez configurer Edge Microgateway pour qu'il soit un client TLS ou SSL lors de la connexion aux points de terminaison cibles. Dans le fichier de configuration Microgateway, utilisez l'élément "targets" pour définir les options SSL/TLS.

Cet exemple fournit des paramètres qui seront appliqués à tous les hôtes :

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

Dans cet exemple, les paramètres ne s'appliquent qu'à l'hôte spécifié :

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

Voici un exemple pour TLS :

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

Voici la liste de toutes les options client compatibles :

Personnaliser le proxy edgemicro-auth

Par défaut, Edge Microgateway utilise un proxy déployé sur Apigee Edge pour l'authentification OAuth2. Ce proxy est déployé lorsque vous exécutez edgemicro configure pour la première fois. Vous pouvez modifier la configuration par défaut de ce proxy pour ajouter la prise en charge des revendications personnalisées à un jeton Web JSON (JWT), configurer l'expiration du jeton et générer des jetons d'actualisation. Pour en savoir plus, consultez la page edgemicro-auth sur GitHub.

Utiliser un service d'authentification personnalisé

Par défaut, Edge Microgateway utilise un proxy déployé sur Apigee Edge pour l'authentification OAuth2. Ce proxy est déployé lorsque vous exécutez edgemicro configure pour la première fois. Par défaut, l'URL de ce proxy est spécifiée dans le fichier de configuration Edge Microgateway comme suit :

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

Si vous souhaitez utiliser votre propre service personnalisé pour gérer l'authentification, modifiez la valeur authUri dans le fichier de configuration pour qu'elle pointe vers votre service. Par exemple, vous pouvez disposer d'un service qui utilise LDAP pour valider l'identité.

Gérer les fichiers journaux

Edge Microgateway enregistre des informations sur chaque requête et réponse. Les fichiers journaux fournissent des informations utiles pour le débogage et le dépannage.

Emplacement de stockage des fichiers journaux

Par défaut, les fichiers journaux sont stockés dans /var/tmp.

Modifier le répertoire de fichier journal par défaut

Le répertoire dans lequel les fichiers journaux sont stockés est spécifié dans le fichier de configuration Edge Microgateway. Pour savoir comment modifier la configuration, consultez Modifier la configuration.

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

Modifiez la valeur dir pour spécifier un autre répertoire de fichiers journaux.

Envoyer des journaux à la console

Vous pouvez configurer la journalisation de sorte que les informations de journal soient envoyées à la sortie standard au lieu d'un fichier journal. Définissez l'indicateur to_console sur "true" comme suit :

edgemicro:
  logging:
    to_console: true  

Avec ce paramètre, les journaux seront envoyés à la sortie standard. Pour le moment, vous ne pouvez pas envoyer de journaux à la fois vers stdout et vers un fichier journal.

Définir le niveau de journalisation

Vous pouvez définir les niveaux de journalisation suivants : info, warn et error. Nous vous recommandons d'utiliser le niveau INFO. Il consigne toutes les requêtes et réponses de l'API. Il s'agit de la valeur par défaut.

Modifier les intervalles du journal des modifications

Vous pouvez configurer ces intervalles dans le fichier de configuration Edge Microgateway. Pour savoir comment modifier la configuration, consultez Modifier la configuration.

Les attributs configurables sont les suivants :

• stats_log_interval : (par défaut : 60) Intervalle, en secondes, auquel l'enregistrement des statistiques est écrit dans le fichier journal de l'API.
• rotate_interval : (par défaut : 24) Intervalle, en heures, auquel les fichiers journaux sont permutés. Exemple :

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

Remarque  : Les fichiers journaux archivés ne sont pas compressés. Lorsqu'un intervalle commence, un fichier journal est créé avec un nouvel horodatage.

Bonnes pratiques de maintenance des fichiers journaux

Étant donné que les données des fichiers journaux s'accumulent au fil du temps, Apigee vous recommande d'adopter les pratiques suivantes :

• Étant donné que les fichiers journaux peuvent devenir assez volumineux, assurez-vous que le répertoire des fichiers journaux dispose de suffisamment d'espace. Consultez les sections Où sont stockés les fichiers journaux et Comment modifier le répertoire par défaut des fichiers journaux.
• Supprimez ou déplacez les fichiers journaux vers un répertoire d'archive distinct au moins une fois par semaine.
• Si votre règle consiste à supprimer les journaux, vous pouvez utiliser la commande CLI edgemicro log -c pour supprimer (nettoyer) les journaux plus anciens.

Convention de dénomination des fichiers journaux

Chaque instance Edge Microgateway génère trois types de fichiers journaux :

• api : enregistre toutes les requêtes et réponses qui transitent par Edge Microgateway. Les compteurs (statistiques) et les erreurs de l'API sont également consignés dans ce fichier.
• err : enregistre tout ce qui est envoyé à stderr.
• out : enregistre tout ce qui est envoyé à stdout.

Voici la convention d'attribution de noms :

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

Exemple :

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

À propos du contenu des fichiers journaux

Ajouté dans la version 2.3.3

Par défaut, le service de journalisation omet le code JSON des produits, des proxys téléchargés et du jeton Web JSON (JWT). Si vous souhaitez afficher ces objets dans les fichiers journaux, définissez DEBUG=* lorsque vous démarrez Edge Microgateway. Exemple :

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

Remarque  : Sous Windows, utilisez SET DEBUG=*.

Contenu du fichier journal "api"

Le fichier journal "api" contient des informations détaillées sur le flux de requêtes et de réponses via Edge Microgateway. Les fichiers journaux "api" sont nommés comme suit :

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Pour chaque requête envoyée à Edge Microgateway, quatre événements sont enregistrés dans le fichier journal "api" :

• Demande entrante du client
• Requête sortante envoyée à la cible
• Réponse entrante de la cible
• Réponse sortante au client

Chacune de ces entrées distinctes est représentée sous forme abrégée pour rendre les fichiers journaux plus compacts. Voici quatre exemples d'entrées représentant chacun des quatre événements. Dans le fichier journal, ils se présentent comme suit (les numéros de ligne ne sont fournis que pour référence dans le document, ils n'apparaissent pas dans le fichier journal).

(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

Examinons-les un par un :

1. Exemple de requête entrante d'un client :

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

• 1436403888651 : code temporel Unix
• info : cela dépend du contexte. Peut être "info", "warn" ou "error", selon le niveau de journalisation. Peut être "stats" pour les statistiques, "warn" pour les avertissements ou "error" pour les erreurs.
• req : identifie l'événement. Dans ce cas, il s'agit d'une requête du client.
• m : verbe HTTP utilisé dans la requête.
• u : partie de l'URL qui suit le chemin de base.
• h : hôte et numéro de port sur lesquels Edge Microgateway est à l'écoute.
• r : hôte et port distants d'où provient la requête du client.
• i : ID de la demande. Les quatre entrées d'événement partageront cet ID. Chaque requête se voit attribuer un ID unique. La corrélation des enregistrements de journaux par ID de requête peut fournir des informations précieuses sur la latence de la cible.
• d : durée en millisecondes depuis la réception de la requête par Edge Microgateway. Dans l'exemple ci-dessus, la réponse de la cible à la requête 0 a été reçue après 7 millisecondes (ligne 3), et la réponse a été envoyée au client après 4 millisecondes supplémentaires (ligne 4). En d'autres termes, la latence totale de la requête était de 11 millisecondes, dont 7 millisecondes pour la cible et 4 millisecondes pour Edge Microgateway lui-même.

2. Exemple de requête sortante envoyée à la cible :

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

• 1436403888651 : code temporel Unix
• info : cela dépend du contexte. Peut être "info", "warn" ou "error", selon le niveau de journalisation. Peut être "stats" pour les statistiques, "warn" pour les avertissements ou "error" pour les erreurs.
• treq : identifie l'événement. Dans ce cas, il s'agit d'une demande cible.
• m : verbe HTTP utilisé dans la requête cible.
• u : partie de l'URL qui suit le chemin de base.
• h : hôte et numéro de port de la cible de backend.
• i : ID de l'entrée de journal. Les quatre entrées d'événement partageront cet ID.

3. Exemple de réponse entrante de la cible

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

1436403888651 : code temporel Unix

• info : cela dépend du contexte. Peut être "info", "warn" ou "error", selon le niveau de journalisation. Peut être "stats" pour les statistiques, "warn" pour les avertissements ou "error" pour les erreurs.
• tres : identifie l'événement. Dans ce cas, il s'agit de la réponse cible.
• s : état de la réponse HTTP.
• d : durée en millisecondes. Temps nécessaire à la cible pour effectuer l'appel d'API.
• i : ID de l'entrée de journal. Les quatre entrées d'événement partageront cet ID.

4. Exemple de réponse sortante au client

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

1436403888651 : code temporel Unix

• info : cela dépend du contexte. Peut être "info", "warn" ou "error", selon le niveau de journalisation. Peut être "stats" pour les statistiques, "warn" pour les avertissements ou "error" pour les erreurs.
• res : identifie l'événement. Dans ce cas, la réponse au client.
• s : état de la réponse HTTP.
• d : durée en millisecondes. Il s'agit du temps total pris par l'appel d'API, y compris le temps pris par l'API cible et le temps pris par Edge Microgateway lui-même.
• i : ID de l'entrée de journal. Les quatre entrées d'événement partageront cet ID.

Planification des fichiers journaux

Les fichiers journaux sont alternés à l'intervalle spécifié par l'rotate_interval rotate_interval. Des entrées continueront d'être ajoutées au même fichier journal jusqu'à l'expiration de l'intervalle de rotation. Toutefois, chaque fois qu'Edge Microgateway est redémarré, il reçoit un nouvel UID et crée un nouvel ensemble de fichiers journaux avec cet UID. Consultez également Bonnes pratiques de maintenance des fichiers journaux.

Documentation de référence sur la configuration d'Edge Microgateway

Emplacement du fichier de configuration

Les attributs de configuration décrits dans cette section se trouvent dans le fichier de configuration Edge Microgateway. Pour savoir comment modifier la configuration, consultez Modifier la configuration.

Attributs edge_config

Ces paramètres permettent de configurer l'interaction entre l'instance Edge Microgateway et Apigee Edge.

• bootstrap : (par défaut : aucun) URL pointant vers un service spécifique à Edge Microgateway s'exécutant sur Apigee Edge. Edge Microgateway utilise ce service pour communiquer avec Apigee Edge. Cette URL est renvoyée lorsque vous exécutez la commande permettant de générer la paire de clés publique/privée : edgemicro genkeys. Pour en savoir plus, consultez Configurer Edge Microgateway.
• jwt_public_key : (par défaut : aucune) URL qui pointe vers le proxy Edge Microgateway déployé sur Apigee Edge. Ce proxy sert de point de terminaison d'authentification pour émettre des jetons d'accès signés aux clients. Cette URL est renvoyée lorsque vous exécutez la commande de déploiement du proxy : edgemicro configure. Pour en savoir plus, consultez Configurer Edge Microgateway.

Attributs edgemicro

Ces paramètres configurent le processus Edge Microgateway.

• port : (par défaut : 8000) numéro de port sur lequel le processus Edge Microgateway écoute.
• max_connections : (par défaut : -1) Spécifie le nombre maximal de connexions entrantes simultanées qu'Edge Microgateway peut recevoir. Si ce nombre est dépassé, l'état suivant est renvoyé :
  
  res.statusCode = 429; // Too many requests
  
• max_connections_hard : (par défaut : -1) Nombre maximal de requêtes simultanées qu'Edge Microgateway peut recevoir avant de fermer la connexion. Ce paramètre vise à contrecarrer les attaques par déni de service. En règle générale, définissez-le sur un nombre supérieur à max_connections.
• logging:
  • level : (par défaut : error)
    • info : consigne toutes les requêtes et réponses qui transitent par une instance Edge Microgateway.
    • warn : enregistre uniquement les messages d'avertissement.
    • error : enregistre uniquement les messages d'erreur.
  • dir : (par défaut : /var/tmp) Répertoire dans lequel les fichiers journaux sont stockés.
  • stats_log_interval : (par défaut : 60) Intervalle, en secondes, auquel l'enregistrement des statistiques est écrit dans le fichier journal de l'API.
  • rotate_interval : (par défaut : 24) Intervalle, en heures, auquel les fichiers journaux sont permutés.

• plugins : les plug-ins ajoutent des fonctionnalités à Edge Microgateway. Pour en savoir plus sur le développement de plug-ins, consultez Développer des plug-ins personnalisés.

• dir : chemin relatif du répertoire ./gateway vers le répertoire ./plugins ou chemin absolu.
• sequence : liste des modules de plug-in à ajouter à votre instance Edge Microgateway. Les modules s'exécutent dans l'ordre dans lequel ils sont spécifiés ici.

• debug  : ajoute le débogage à distance au processus Edge Microgateway.
  • port : numéro de port à écouter. Par exemple, configurez le débogueur de votre IDE pour qu'il écoute sur ce port.
  • args : arguments du processus de débogage. Exemple :args --nolazy
    
• config_change_poll_interval: (valeur par défaut : 600 secondes) : Edge Microgateway charge une nouvelle configuration périodiquement et exécute un rechargement en cas de modification. L'interrogation détecte toutes les modifications apportées à Edge (modifications des produits, des proxys compatibles avec la passerelle Microgateway, etc.) ainsi que celles apportées au fichier de configuration local.
  
• disable_config_poll_interval : (par défaut : false) Définissez sur true pour désactiver l'interrogation automatique des modifications.
• request_timeout : définit un délai avant expiration pour les requêtes cibles. Le délai avant expiration est défini en secondes. En cas de délai avant expiration, Edge Microgateway répond avec un code d'état 504. (Ajouté v2.4.x)

Attributs d'en-tête

Ces paramètres permettent de configurer le traitement de certains en-têtes HTTP.

• x-forwarded-for : (par défaut : true) Définissez sur "false" pour empêcher la transmission des en-têtes x-forwarded-for à la cible. Notez que si un en-tête x-forwarded-for est présent dans la requête, sa valeur sera définie sur la valeur client-ip dans Edge Analytics.
• x-forwarded-host : (par défaut : true) Définissez sur "false" pour empêcher la transmission des en-têtes x-forwarded-host à la cible.
• x-request-id : (par défaut : true) Définissez la valeur sur "false" pour empêcher la transmission des en-têtes x-request-id à la cible.
• x-response-time : (par défaut : true) Définissez sur "false" pour empêcher la transmission des en-têtes x-response-time à la cible.
• via : (par défaut : true) Définissez sur "false" pour empêcher la transmission des en-têtes "via" à la cible.

Attributs OAuth

Ces paramètres configurent la façon dont l'authentification du client est appliquée par Edge Microgateway.

• allowNoAuthorization : (par défaut : false) Si la valeur est définie sur "true", les appels d'API sont autorisés à transiter par Edge Microgateway sans aucun en-tête d'autorisation. Définissez cette valeur sur "false" pour exiger un en-tête d'autorisation (par défaut).
• allowInvalidAuthorization : (valeur par défaut : false) Si la valeur est définie sur "true", les appels d'API sont autorisés à passer si le jeton transmis dans l'en-tête Authorization n'est pas valide ou a expiré. Définissez cette valeur sur "false" pour exiger des jetons valides (valeur par défaut).
• authorization-header : (par défaut : Authorization: Bearer) En-tête utilisé pour envoyer le jeton d'accès à Edge Microgateway. Vous pouvez modifier la valeur par défaut si la cible doit utiliser l'en-tête d'autorisation à d'autres fins.
• api-key-header : (par défaut : x-api-key) Nom de l'en-tête ou du paramètre de requête utilisé pour transmettre une clé API à Edge Microgateway. Consultez également Utiliser une clé API.
• keepAuthHeader : (valeur par défaut : false) si la valeur est définie sur "true", l'en-tête "Authorization" envoyé dans la requête est transmis à la cible (il est conservé).
• allowOAuthOnly : si la valeur est définie sur "true", chaque API doit comporter un en-tête d'autorisation avec un jeton d'accès Bearer. Vous permet d'autoriser uniquement le modèle de sécurité OAuth (tout en conservant la rétrocompatibilité). (Ajouté dans la version 4.2.x)
• allowAPIKeyOnly : si la valeur est définie sur "true", chaque API doit comporter un en-tête x-api-key (ou un emplacement personnalisé) avec une clé API.Vous pouvez ainsi n'autoriser que le modèle de sécurité de clé API (tout en conservant la rétrocompatibilité). (Ajouté dans la version 4.2.x)

Attributs spécifiques aux plug-ins

Pour en savoir plus sur les attributs configurables de chaque plug-in, consultez "Utiliser des plug-ins".

Serveurs proxy de filtrage

Vous pouvez filtrer les proxys compatibles avec les microgateways qu'une instance Edge Microgateway traitera. Lorsqu'Edge Microgateway démarre, il télécharge tous les proxys compatibles avec Microgateway dans l'organisation à laquelle il est associé. Utilisez la configuration suivante pour limiter les proxys que le microgateway traitera. Par exemple, cette configuration limite à trois le nombre de proxys que la micro-passerelle traitera : edgemicro_proxy-1, edgemicro_proxy-2 et edgemicro_proxy-3 :

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

Masquer les données analytiques

La configuration suivante empêche les informations sur le chemin de requête de s'afficher dans les données analytiques Edge. Ajoutez les éléments suivants à la configuration de la passerelle de microservices pour masquer l'URI de la demande et/ou le chemin d'accès de la demande. Notez que l'URI se compose du nom d'hôte et du chemin d'accès de la requête.

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

Configurer Edge Microgateway derrière un pare-feu d'entreprise

Version 4.2.x compatible

Si Edge Microgateway est installé derrière un pare-feu, il est possible qu'il ne puisse pas communiquer avec Apigee Edge. Dans ce cas, deux options s'offrent à vous :

Option 1 :

La première option consiste à définir l'option edgemicro: proxy_tunnel sur "true" dans le fichier de configuration de la micro-passerelle :

edge_config:

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

Lorsque proxy_tunnel est défini sur true, Edge Microgateway utilise la méthode HTTP CONNECT pour tunneliser les requêtes HTTP sur une seule connexion TCP. (Il en va de même si les variables d'environnement pour configurer le proxy sont compatibles avec TLS.)

Option 2 :

La deuxième option consiste à spécifier un proxy et à définir proxy_tunnel sur "false" dans le fichier de configuration du microgateway. Exemple :

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

Dans ce cas, vous pouvez définir les variables suivantes pour contrôler les hôtes de chaque proxy HTTP que vous souhaitez utiliser, ou les hôtes qui ne doivent pas gérer les proxys Edge Microgateway : HTTP_PROXY, HTTPS_PROXY et NO_PROXY.

Vous pouvez définir NO_PROXY comme une liste de domaines délimités par des virgules vers lesquels Edge Microgateway ne doit pas rediriger le trafic. Exemple :

export NO_PROXY='localhost,localhost:8080'

Définissez HTTP_PROXY et HTTPS_PROXY sur le point de terminaison du proxy HTTP auquel Edge Microgateway peut envoyer des messages. Exemple :

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

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

Pour en savoir plus sur ces variables, consultez :

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

Voir aussi

Configurer Edge Microgateway derrière un pare-feu d'entreprise sur la communauté Apigee.

Utiliser des caractères génériques dans les proxys compatibles avec Microgateway

Vous pouvez utiliser un ou plusieurs caractères génériques "*" dans le chemin d'accès de base d'un proxy edgemicro_* (compatible avec la micro-passerelle). Par exemple, un chemin de base /team/*/members permet aux clients d'appeler https://[host]/team/blue/members et https://[host]/team/green/members sans que vous ayez besoin de créer de proxys d'API pour gérer les nouvelles équipes. Notez que /**/ n'est pas accepté.

Important : Apigee n'accepte PAS le caractère générique "*" en tant que premier élément d'un chemin de base. Par exemple, la recherche /*/ n'est PAS acceptée.

Débogage et dépannage

Se connecter à un débogueur

Vous pouvez exécuter Edge Microgateway avec un débogueur, tel que node-inspector. Cela s'avère utile pour dépanner et déboguer les plug-ins personnalisés.

1. Redémarrez Edge Microgateway en mode débogage. Pour ce faire, ajoutez DEBUG=* au début de la commande de démarrage. Exemple :
   
   DEBUG=* edgemicro start -o myorg -e test -k db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s 6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed
   

   Remarque : Sous Windows, utilisez SET DEBUG=*.

2. Démarrez votre débogueur et configurez-le pour qu'il écoute le numéro de port pour le processus de débogage.
3. Vous pouvez maintenant parcourir le code Edge Microgateway, définir des points d'arrêt, observer des expressions, etc.

Vous pouvez spécifier des indicateurs Node.js standards liés au mode débogage. Par exemple, --nolazy permet de déboguer du code asynchrone.

Vérifier les fichiers journaux

Si vous rencontrez des problèmes, veillez à examiner les fichiers journaux pour obtenir des informations sur l'exécution et les erreurs. Pour en savoir plus, consultez Gérer les fichiers journaux.

Utiliser la sécurité des clés API

Les clés API fournissent un mécanisme simple pour authentifier les clients qui envoient des requêtes à Edge Microgateway. Vous pouvez obtenir une clé API en copiant la valeur de la clé client (également appelée ID client) à partir d'un produit Apigee Edge qui inclut le proxy d'authentification Edge Microgateway.

Mise en cache des clés

Les clés API sont échangées contre des jetons du porteur, qui sont mis en cache. Vous pouvez désactiver la mise en cache en définissant l'en-tête Cache-Control: no-cache sur les requêtes entrantes vers Edge Microgateway.

Utiliser la sécurité des jetons OAuth2

Pour en savoir plus sur l'utilisation d'un jeton OAuth avec les requêtes de proxy, consultez Sécuriser Edge Microgateway.

Utiliser une clé API

Pour en savoir plus sur l'utilisation des clés API avec les requêtes de proxy, consultez Sécuriser Edge Microgateway.

Configurer le nom de la clé API

Par défaut, x-api-key est le nom utilisé pour l'en-tête ou le paramètre de requête de la clé API. Vous pouvez modifier cette valeur par défaut dans le fichier de configuration, comme expliqué dans Apporter des modifications à la configuration.  Par exemple, pour remplacer le nom par apiKey :

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