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

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Edge Microgateway version 2.4.x

Présentation

Cet article 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 que vous devez 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 l'exécution d'instances

Cette section traite de ces fichiers et de ce que vous devez savoir avant de les modifier. Pour en savoir plus sur les paramètres des fichiers de configuration, consultez la page Configurer Edge Microgateway référence.

Configuration système par défaut fichier

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 avec préfixe npm. Découvrez 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]

Dynamique fichier de configuration pour exécuter des instances

Lorsque vous exécutez edgemicro configure [params], un objet dynamique est créé dans ~/.edgemicro. Le nom du fichier est le suivant motif: [org]-[env]-config.yaml, où org et env correspondent à votre organisation Apigee Edge et les noms d'environnement. Vous pouvez utiliser ce fichier pour apporter des modifications à la configuration, puis les actualiser sans temps d'arrêt. Par exemple, si vous ajoutez et configurez un plug-in, vous pouvez recharger sans temps d'arrêt, comme expliqué ci-dessous.

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

1. Actualisez 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'entreprise).
   • env est un environnement de votre organisation (comme un environnement de test ou produit).
   • key est la clé renvoyée précédemment par la configuration .
   • secret est la clé renvoyée précédemment par la configure.

   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'entreprise).
   • env est un environnement de votre organisation (comme un environnement de test ou produit).
   • key est la clé renvoyée précédemment par la configuration .
   • secret est la clé renvoyée précédemment par la configure.

   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 des fichiers de configuration, voir Edge Microgateway documentation de référence sur la configuration.

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 d'interface de ligne de commande qui nécessitent des valeurs pour votre organisation Edge et et la clé et le code secret nécessaires au démarrage d'Edge Microgateway peuvent être stockés dans variables d'environnement:

• 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 configurez et démarrez Edge Microgateway à l'aide de l'interface de ligne de commande (CLI).

Configurer SSL sur Edge Microgateway serveur

Vous pouvez configurer le serveur Microgateway pour qu'il utilise SSL. Par exemple, si SSL est configuré, peut appeler des API via Edge Microgateway avec le préfixe "https" comme suit:

https://localhost:8000/myapi

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

1. Générez ou obtenez une clé et un certificat SSL à l'aide de l'utilitaire openssl ou de la méthode de votre choix.
2. Ajoutez l'attribut edgemicro:ssl à Edge Microgateway fichier de configuration. Pour obtenir la liste complète des options, consultez le tableau ci-dessous. Pour en savoir plus sur modifier la configuration Edge Microgateway, consultez la section Apporter des modifications à la configuration. 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 la section 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 de l'environnement d'exécution.

Voici un exemple de la section Edgemicro du fichier de configuration, dans laquelle le protocole SSL est 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 en tant que client TLS ou SSL lors de la connexion à la cible les points de terminaison. Définissez SSL/TLS dans le fichier de configuration Microgateway à l'aide de l'élément "targets" options.

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 de 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 modifiez la configuration par défaut de ce proxy afin d'ajouter la prise en charge des revendications personnalisées dans un fichier JSON Web jeton (JWT), configurer l'expiration des jetons et générer des jetons d'actualisation. Pour en savoir plus, consultez la page edgemicro-auth ; dans 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, remplacez la valeur authUri du fichier de configuration pour qu'elle pointe vers votre service. Pour exemple, vous pouvez avoir un service qui utilise LDAP pour vérifier l'identité.

Gestion fichiers journaux

Edge Microgateway enregistre des informations sur chaque requête et réponse. Les fichiers journaux fournissent des 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 journal par défaut répertoire de fichiers

Le répertoire de stockage des fichiers journaux est spécifié dans la configuration Edge Microgateway . Pour plus d'informations sur les modifications de configuration, consultez la section 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 fichier journal.

Envoyer des journaux à la console

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

edgemicro:
  logging:
    to_console: true  

Avec ce paramètre, les journaux sont envoyés vers la sortie standard. Actuellement, vous ne pouvez pas envoyer de journaux stdout et dans un fichier journal.

Définir le niveau de journalisation

Vous pouvez définir les niveaux de journalisation suivants: info, warn, et error. Le niveau d'information est recommandé. Il consigne toutes les requêtes API et il s'agit de la valeur par défaut.

Modifier les intervalles de journalisation

Vous pouvez configurer ces intervalles dans le fichier de configuration Edge Microgateway. Pour savoir comment créer des modifications de configuration, consultez la section Effectuer des modifications.

Les attributs configurables sont les suivants:

• stats_log_interval: (valeur par défaut: 60) intervalle, en secondes, lorsque les statistiques est écrit dans le fichier journal de l'API.
• rotate_interval: (valeur par défaut: 24) intervalle, en heures, lorsque les fichiers journaux sont a fait pivoter. 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. Lorsque l'intervalle commence, un fichier journal est créé avec un nouvel horodatage.

Bonnes pratiques de maintenance des fichiers journaux

Au fur et à mesure que les données des fichiers journaux s'accumulent, Apigee vous recommande d'adopter les pratiques:

• Les fichiers journaux pouvant devenir très volumineux, assurez-vous que le répertoire du fichier journal contient un espace suffisant. Consultez les sections Où les fichiers journaux sont-ils stockés ? et Comment modifier le fichier journal par défaut ? .
• Supprimez ou déplacez les fichiers journaux dans un répertoire d'archive distinct au moins une fois par semaine.
• Si votre stratégie consiste à supprimer des journaux, vous pouvez utiliser la commande CLI edgemicro log -c pour supprimer (nettoyer) les anciens journaux.

Convention d'attribution de noms aux fichiers journaux

Chaque instance Edge Microgateway produit trois types de fichiers journaux:

• api : consigne toutes les requêtes et les réponses qui transitent par Edge. Microgateway. Les compteurs (statistiques) et les erreurs d'API sont également consignés dans ce fichier.
• err : consigne tous les éléments envoyés à stderr.
• out : consigne tous les éléments envoyés à 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ée dans: v2.3.3

Par défaut, le service de journalisation omet le JSON des proxys et des produits téléchargés, ainsi que le JSON Jeton Web (JWT). Si vous souhaitez générer 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 de "api" fichier journal

L'API contenant des informations détaillées sur le flux de requêtes et de réponses via Edge Microgateway. L'API Les fichiers journaux sont nommés comme suit:

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

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

• Requête 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 la forme d'une notation abrégée pour aider à rendre le journal plus compacts. Voici quatre exemples d'entrées représentant chacun des quatre événements. Dans le journal ils ressemblent à ceci (les numéros de ligne servent uniquement de 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 du client:

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

• 1436403888651 : horodatage Unix
• info : dépend du contexte. Il peut s'agir d'une information, d'un avertissement ou d'une erreur, en fonction du niveau de journalisation. Il peut s'agir de statistiques pour un enregistrement de statistiques, d'un avertissement en cas d'avertissements ou en cas d'erreurs.
• req : identifie l'événement. Dans ce cas, la demande client.
• m : le verbe HTTP utilisé dans la requête.
• u : partie de l'URL située après le chemin de base.
• h : hôte et numéro de port sur lesquels Edge Microgateway à l'écoute.
• r : hôte et port distants sur lesquels la requête du client d'origine.
• i : ID de la requête. Les quatre entrées d'événement partageront cet ID. Chaque se voit attribuer un ID de requête unique. La mise en corrélation des enregistrements de journal par l'ID de requête peut donner de précieux insights sur la latence de la cible.
• d : durée en millisecondes écoulées depuis la réception de la requête par Edge Microgateway. Dans l'exemple ci-dessus, la réponse de la cible à la demande 0 a été reçue. après sept millisecondes (ligne 3), et la réponse a été envoyée au client au bout de quatre millisecondes en millisecondes (ligne 4). En d'autres termes, la latence totale des requêtes était de 11 millisecondes, dont 7 millisecondes ont été prises par la cible et 4 millisecondes par 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 : horodatage Unix
• info : dépend du contexte. Il peut s'agir d'une information, d'un avertissement ou d'une erreur, en fonction du niveau de journalisation. Il peut s'agir de statistiques pour un enregistrement de statistiques, d'un avertissement en cas d'avertissements ou en cas d'erreurs.
• treq : identifie l'événement. Dans ce cas, la requête cible.
• m : le verbe HTTP utilisé dans la requête cible.
• u : partie de l'URL située après le chemin de base.
• h : hôte et numéro de port de la cible backend.
• i : ID de l'entrée de journal. Les quatre participants de l'événement partageront ceci ID.

3. Exemple de réponse entrante de la cible

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

1436403888651 : horodatage Unix

• info : dépend du contexte. Il peut s'agir d'une information, d'un avertissement ou d'une erreur, en fonction du niveau de journalisation. Il peut s'agir de statistiques pour un enregistrement de statistiques, d'un avertissement en cas d'avertissements ou en cas d'erreurs.
• tres : identifie l'événement. Dans ce cas, la réponse cible.
• s : état de la réponse HTTP.
• d : durée en millisecondes. Temps nécessaire à l'appel d'API la cible.
• i : ID de l'entrée de journal. Les quatre participants de l'événement partageront ceci ID.

4. Exemple de réponse sortante au client

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

1436403888651 : horodatage Unix

• info : dépend du contexte. Il peut s'agir d'une information, d'un avertissement ou d'une erreur, en fonction du niveau de journalisation. Il peut s'agir de statistiques pour un enregistrement de statistiques, d'un avertissement en cas d'avertissements ou en cas d'erreurs.
• res : identifie l'événement. Dans ce cas, la réponse client.
• s : état de la réponse HTTP.
• d : durée en millisecondes. Il s'agit du temps total nécessaire par l'appel d'API, y compris le temps pris par l'API cible et le temps pris par Edge Microgateway elle-même.
• i : ID de l'entrée de journal. Les quatre participants de l'événement partageront ceci ID.

Programmation des fichiers journaux

Les fichiers journaux sont alternés selon l'intervalle spécifié par La configuration rotate_interval . Les entrées continueront d'être ajoutées au même fichier journal jusqu'à l'intervalle de rotation expire. Cependant, à chaque redémarrage d'Edge Microgateway, il reçoit un nouvel UID et crée un un nouvel ensemble de fichiers journaux avec cet UID. Consultez également la page Bonnes pratiques en matière de maintenance des fichiers journaux.

Configuration Edge Microgateway référence

Emplacement fichier de configuration

Les attributs de configuration décrits dans cette section se trouvent dans la passerelle Edge Microgateway fichier de configuration. Pour plus d'informations sur les modifications de configuration, consultez la section 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) une URL qui pointe vers un Edge Service spécifique à une micropasserelle 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 pour générer le paire de clés publique/privée: edgemicro genkeys. Reportez-vous à la section Paramètre et configurer Edge Microgateway.
• jwt_public_key: (par défaut: aucun) URL pointant vers Edge Microgateway qui est déployé sur Apigee Edge. Ce proxy sert de point de terminaison d'authentification pour l'émission de jetons d'accès signés aux clients. Cette URL est renvoyée lorsque vous exécutez la commande pour Déployez le proxy: edgemicro configure. Reportez-vous à la section Paramètre et configurer Edge Microgateway.

Attributs Edgemicro

Ces paramètres configurent le processus Edge Microgateway.

• port: (par défaut: 8000) numéro de port sur lequel la passerelle Edge Microgateway que le processus écoute.
• max_connections (valeur par défaut : -1) : spécifie le nombre maximal de les 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: (valeur par défaut: -1) le nombre maximal de connexions simultanées que Edge Microgateway peut recevoir avant d'arrêter la connexion. Ce paramètre est destiné à contrer les attaques par déni de service. Généralement, définissez-la sur un nombre supérieur à max_connections.
• logging: <ph type="x-smartling-placeholder">
  </ph>
  • level: (par défaut: erreur) <ph type="x-smartling-placeholder">
    </ph>
    • info : consigne toutes les requêtes et réponses transmises via un Instance Edge Microgateway.
    • warn : consigne uniquement les messages d'avertissement.
    • error : enregistre uniquement les messages d'erreur.
  • dir: (par défaut: /var/tmp) le répertoire dans lequel les fichiers journaux sont stockées.
  • stats_log_interval: (valeur par défaut: 60) intervalle, en secondes, lorsque les statistiques est écrit dans le fichier journal de l'API.
  • rotate_interval: (valeur par défaut: 24) intervalle, en heures, lorsque les fichiers journaux sont a fait pivoter.

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

• dir: chemin d'accès relatif du répertoire ./gateway vers ./plugins ou un chemin d'accès absolu.
• Sequence: liste des modules de plug-in à ajouter à votre Edge Microgateway Compute Engine. Les modules s'exécutent dans l'ordre indiqué ici.

• debug : ajoute le débogage à distance au processus Edge Microgateway.
  • port: numéro de port à écouter. Par exemple, définissez votre débogueur IDE à écouter sur ce port.
  • args: arguments du processus de débogage. Exemple :args --nolazy
    
• config_change_poll_interval: (par défaut: 600 secondes) Edge Microgateway charge régulièrement une nouvelle configuration et exécute une actualisation si quelque chose a été modifié. Le sondage récupère toutes les modifications apportées sur Edge (modifications apportées aux produits, proxys compatibles avec les micropasserelles, etc.) comme ainsi que les modifications apportées au fichier de configuration local.
  
• disable_config_poll_interval: : (valeur par défaut: false) Définir sur true pour désactiver le changement automatique. les sondages.
• request_timeout: définit un délai avant expiration pour les requêtes cibles. Le délai avant expiration est défini dans secondes. En cas d'expiration du délai, Edge Microgateway renvoie un code d'état 504. (Ajouté v2.4.x)

attributs d'en-têtes

Ces paramètres configurent la manière dont certains en-têtes HTTP sont traités.

• x-forwarded-for: (valeur par défaut: true) Définir sur "false" pour empêcher x-forwarded-for à transmettre à la cible. Notez que si un en-tête x-forwarded-for figure dans la demande, sa valeur sera définie sur la valeur client-ip dans Edge Analytics.
• x-forwarded-host: (valeur par défaut: true) Définir sur "false" pour empêcher en-têtes x-forwarded-host à transmettre à la cible.
• x-request-id: (valeur par défaut: true) défini sur "false" pour empêcher x-request-id à transmettre à la cible.
• x-response-time: (valeur par défaut: true) défini sur "false" pour empêcher en-têtes x-response-time à transmettre à la cible.
• via: (valeur par défaut: true) définie sur "false" pour empêcher les en-têtes via transmis à la cible.

Attributs OAuth

Ces paramètres configurent la manière dont Edge Microgateway applique l'authentification du client.

• allowNoAuthorization: (valeur par défaut: false) Si ce paramètre est défini sur "true", les appels d'API sont autorisé à passer par Edge Microgateway sans aucun en-tête Authorization du tout. Définir sur "false" pour exiger un en-tête "Authorization" (par défaut).
• allowInvalidAuthorization: (valeur par défaut: false) si ce champ est défini sur "true", les appels d'API sont si le jeton transmis dans l'en-tête Authorization n'est pas valide ou a expiré. Définir 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 dans les cas où la cible doit utiliser l'en-tête Authorization à d'autres fins.
• api-key-header: (par défaut: x-api-key) le nom de l'en-tête ou de la requête utilisé pour transmettre une clé API à Edge Microgateway. Consultez également la section Utiliser une clé API.
• keepAuthHeader (valeur par défaut : false) : si la valeur est "true", l'en-tête "Authorization" envoyée dans la requête est transmise à la cible (elle est conservée).
• allowOAuthOnly : si la valeur est définie sur "true", chaque API doit comporter En-tête d'autorisation avec un jeton d'accès de support. Permet d'autoriser uniquement la sécurité OAuth (tout en maintenant la rétrocompatibilité). (Ajoutée à la version 4.2.x)
• allowAPIKeyOnly : si la valeur est "true", chaque API doit transmettre Un en-tête x-api-key (ou un emplacement personnalisé) associé à une clé API. d'autoriser uniquement le modèle de sécurité de la clé API (tout en maintenant la rétrocompatibilité) ; (Ajoutée à la version 4.2.x)

Propre au plug-in Attributs

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

Filtrer les proxys

Vous pouvez filtrer les proxys compatibles avec la micropasserelle qu'une instance Edge Microgateway traitera. Au démarrage d'Edge Microgateway, il télécharge tous les proxys compatibles avec la micropasserelle du organisation à laquelle il est associé. Utilisez la configuration suivante pour limiter les proxys que microgateway traitera. Par exemple, cette configuration limite les proxys de la micropasserelle traitera trois éléments: edgemicro_proxy-1, edgemicro_proxy-2, et edgemicro_proxy-3:

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

Masquage des données d'analyse

La configuration suivante empêche l'affichage des informations du chemin de requête dans Edge analyse. Ajoutez le code suivant à la configuration de la microgateway pour masquer l'URI de la requête et/ou dans le chemin de la requête. Notez que l'URI se compose des parties de la requête (nom d'hôte et chemin d'accès).

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 que la passerelle ne puisse pas communiquer avec Apigee Edge. Dans ce cas, deux options s'offrent à vous:

Option 1 :

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

edge_config:

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

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

Option 2 :

La deuxième option consiste à spécifier un proxy et à définir proxy_tunnel sur "false" dans le de configuration 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 pour chaque proxy que vous souhaitez utiliser ou les hôtes qui ne doivent pas gérer Edge Microgateway. proxys: HTTP_PROXY, HTTPS_PROXY, et NO_PROXY.

Vous pouvez définir NO_PROXY sous la forme d'une liste de domaines séparés par une virgule. vers lequel Edge Microgateway ne doit pas fournir de proxy. Exemple :

export NO_PROXY='localhost,localhost:8080'

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

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

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

Pour en savoir plus sur ces variables, consultez les pages suivantes:

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

Voir aussi

<ph type="x-smartling-placeholder"></ph> Comment configurer Edge Microgateway derrière le pare-feu de l'entreprise dans la communauté Apigee.

Utiliser des caractères génériques dans une configuration compatible avec les microservices proxys

Vous pouvez utiliser un ou plusieurs "*" dans le chemin de base un proxy edgemicro_* (compatible avec Microgateway). Par exemple, un chemin d'accès de base de /team/*/members permet aux clients de appelez https://[host]/team/blue/members et https://[host]/team/green/members sans vous devez créer de nouveaux proxys d'API pour prendre en charge de nouvelles équipes. Remarque que /**/ n'est pas pris en charge.

Important:Apigee n'accepte PAS l'utilisation du caractère générique "*" en tant que premier élément d'un chemin de base. Par exemple, il ne s'agit PAS compatible: recherche /*/.

Débogage et Dépannage

Se connecter à un débogueur

Vous pouvez exécuter Edge Microgateway avec un débogueur, tel que node-inspector. Ceci est utile pour pour résoudre les problèmes et déboguer des plug-ins personnalisés.

1. Redémarrez Edge Microgateway en mode débogage. Pour ce faire, ajoutez DEBUG=* à au début de la commande « start ». 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 pendant le processus de débogage.
3. Vous pouvez maintenant parcourir le code Edge Microgateway, définir des points d'arrêt, surveiller les expressions et ainsi de suite.

Vous pouvez spécifier des indicateurs Node.js standards liés au mode débogage. Par exemple : --nolazy aide à déboguer le code asynchrone.

Vérifier les fichiers journaux

Si vous rencontrez des problèmes, examinez les détails de l'exécution et les erreurs dans les fichiers journaux des informations. 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 envoyant des demandes à Edge Microgateway. Pour obtenir une clé API, copiez la valeur de la clé client (également appelée "ID client") d'un produit Apigee Edge incluant le proxy d'authentification Edge Microgateway.

Mise en cache de clés

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

Utiliser la sécurité des jetons OAuth2

Pour plus d'informations sur l'utilisation d'un jeton OAuth avec des requêtes de proxy, consultez la section Sécuriser Edge Microgateway.

Utilisation une clé API

Pour plus d'informations sur l'utilisation de clés API avec les requêtes de proxy, consultez la section 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 la requête de clé API. . Vous pouvez modifier cette valeur par défaut dans le fichier de configuration, comme expliqué dans la section Apporter des modifications à la configuration. Pour Par exemple, pour remplacer le nom par apiKey:

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