Cette page a été traduite par l'API Cloud Translation.

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

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Edge Microgateway version 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 que vous devez connaître:

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

Cette section décrit ces fichiers et vous explique comment 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 la section 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:

Appeler le edgemicro init
Appeler le edgemicro configure [params]
Appeler le 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 le répertoire suivant : ~/.edgemicro

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

edgemicro stop
edgemicro configure [params]
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 ce modèle: [org]-[env]-config.yaml, où org et env correspondent aux noms de votre organisation et de votre environnement Apigee Edge. Vous pouvez utiliser ce fichier pour modifier la configuration, puis l'actualiser sans temps d'arrêt. Par exemple, si vous ajoutez et configurez un plug-in, vous pouvez actualiser la configuration sans subir de temps d'arrêt, comme expliqué ci-dessous.

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

Actualisez la configuration 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 (test ou production, par exemple).
- key est la clé renvoyée précédemment par la commande "config".
- secret est la clé renvoyée précédemment par la commande "config".
Exemple
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188016b3c39177d64a88754d615c74e1f78b6181d000723 -s 05c14356e42ed136b8dd35cf8a18531ff52d7299134677e30ef4e34ab0cc824
```

Si Edge Microgateway est arrêté:

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 (test ou production, par exemple).
- key est la clé renvoyée précédemment par la commande "config".
- secret est la clé renvoyée précédemment par la commande "config".
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 code secret nécessaires au démarrage d'Edge Microgateway peuvent être stockés 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, lorsque SSL est configuré, vous pouvez appeler des API via Edge Microgateway à l'aide du protocole "https", comme suit:

https://localhost:8000/myapi

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

Générez ou obtenez un certificat SSL et une clé à l'aide de l'utilitaire openssl ou de la méthode de votre choix.
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 plus d'informations sur la modification de la configuration d'Edge Microgateway, consultez la section 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 
```
Remarque:La clé spécifiée dans le fichier de clé SSL référencé ne doit pas être chiffrée.
Redémarrez Edge Microgateway. Suivez les étapes décrites dans la section Modifier la configuration en fonction du fichier de configuration que vous avez modifié: fichier par défaut ou fichier de configuration de l'environnement d'exécution.

Voici un exemple de 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:

Option	Description
`key`	Chemin d'accès à un fichier `ca.key` (au format PEM).
`cert`	Chemin d'accès à un fichier `ca.cert` (au format PEM).
`pfx`	Chemin d'accès à un fichier `pfx` contenant la clé privée, le certificat et les certificats CA du client au format PFX.
`passphrase`	Chaîne contenant la phrase secrète de la clé privée ou PFX.
`ca`	Chemin d'accès à un fichier contenant une liste de certificats de confiance au format PEM.
`ciphers`	Chaîne décrivant les algorithmes de chiffrement à utiliser, séparés par le caractère ":".
`rejectUnauthorized`	Si la valeur est "true", le certificat du serveur est vérifié par rapport à la liste des autorités de certification fournies. Si la validation échoue, une erreur est renvoyée.
`secureProtocol`	Méthode SSL à utiliser. Par exemple, SSLv3_method pour forcer SSL à utiliser la version 3.
`servername`	Nom du serveur pour l'extension TLS SNI (Server Name Indication).
`requestCert`	"true" pour le protocole SSL à deux voies ; "false" pour le protocole SSL à sens unique

Utiliser les options SSL/TLS du client

Vous pouvez configurer Edge Microgateway en tant que client TLS ou SSL lors de la connexion aux points de terminaison cibles. Dans le fichier de configuration Microgateway, définissez les options SSL/TLS à l'aide de l'élément "targets".

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 sont appliqués 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:

Option	Description
`pfx`	Chemin d'accès à un fichier `pfx` contenant la clé privée, le certificat et les certificats CA du client au format PFX.
`key`	Chemin d'accès à un fichier `ca.key` (au format PEM).
`passphrase`	Chaîne contenant la phrase secrète de la clé privée ou PFX.
`cert`	Chemin d'accès à un fichier `ca.cert` (au format PEM).
`ca`	Chemin d'accès à un fichier contenant une liste de certificats de confiance au format PEM.
`ciphers`	Chaîne décrivant les algorithmes de chiffrement à utiliser, séparés par le caractère ":".
`rejectUnauthorized`	Si la valeur est "true", le certificat du serveur est vérifié par rapport à la liste des autorités de certification fournies. Si la validation échoue, une erreur est renvoyée.
`secureProtocol`	Méthode SSL à utiliser. Par exemple, SSLv3_method pour forcer SSL à utiliser la version 3.
`servername`	Nom du serveur pour l'extension TLS SNI (Server Name Indication).

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 accepter les revendications personnalisées sur 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 dans GitHub.

Utiliser un service d'authentification personnalisé

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 disposez peut-être d'un service qui utilise LDAP pour vérifier l'identité.

Remarque:Important:Si vous remplacez le proxy d'authentification par défaut, le nouveau proxy ou service doit renvoyer un format de réponse identique au proxy edgemicro-auth par défaut.

Gérer les fichiers journaux

Edge Microgateway enregistre des informations sur chaque requête et chaque 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.

Changer le répertoire par défaut des fichiers journaux

Le répertoire dans lequel les fichiers journaux sont stockés est spécifié dans le fichier de configuration Edge Microgateway. Pour en savoir plus sur les modifications de 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 les journaux à la console

Vous pouvez configurer la journalisation de sorte que les informations de journal soient envoyées vers la sortie standard plutôt que vers 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 vers la sortie standard. Actuellement, vous ne pouvez pas envoyer de journaux à la fois à stdout et à 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 d'information. Il consigne toutes les requêtes et réponses de l'API, et il s'agit de l'option par défaut.

Modifier les intervalles de journalisation

Vous pouvez configurer ces intervalles dans le fichier de configuration Edge Microgateway. Pour en savoir plus sur les modifications de configuration, consultez Modifier la configuration.

Les attributs configurables sont les suivants:

stats_log_interval: (par défaut: 60) intervalle, en secondes, lorsque l'enregistrement de statistiques est écrit dans le fichier journal de l'API.
rotate_interval: (valeur par défaut: 24) intervalle, en heures, pendant lequel les fichiers journaux sont alterné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. 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 suivantes:

Étant donné que les fichiers journaux peuvent être assez volumineux, assurez-vous que le répertoire de fichiers journaux dispose d'un espace suffisant. Consultez les sections suivantes Emplacement de stockage des fichiers journaux et Modifier le répertoire par défaut des fichiers journaux.
Vous devez supprimer les fichiers journaux ou les déplacer vers un répertoire d'archives distinct au moins une fois par semaine.
Si votre règle consiste à supprimer des journaux, vous pouvez utiliser la commande CLI edgemicro log -c pour supprimer (nettoyer) les anciens journaux.

Convention d'attribution de noms pour les fichiers journaux

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

api : consigne toutes les requêtes et réponses qui transitent par Edge Microgateway. Les compteurs (statistiques) de l'API et les erreurs sont également consignés dans ce fichier.
err : consigne tous les éléments envoyés à stderr.
out : consigne 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é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 jeton Web JSON (JWT). Si vous souhaitez générer ces objets dans les fichiers journaux, définissez la 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 des requêtes et des 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 capturés dans le fichier journal "api" :

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

Chacune de ces entrées distinctes est représentée par une notation abrégée pour rendre les fichiers journaux plus compacts. Voici quatre exemples d'entrées représentant chacun des quatre événements. Elles se présentent comme suit dans le fichier journal (les numéros de ligne ne sont fournis qu'à titre indicatif dans le document ; ils n'y apparaissent pas).

(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 une par une:

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, selon le niveau de journalisation. Il peut s'agir de statistiques liées à un enregistrement de statistiques, d'un avertissement en cas d'avertissement ou d'une erreur en cas d'erreur.
req : identifie l'événement. Dans ce cas, il s'agit de la requête du client.
m : verbe HTTP utilisé dans la requête.
u : partie de l'URL qui suit le chemin de base.
h : numéro de l'hôte et du port sur lesquels Edge Microgateway écoute.
r : hôte distant et port d'où provient la requête du client.
i : ID de la requête. Les quatre entrées d'événement partageront cet ID. Chaque requête se voit attribuer un ID unique. La mise en corrélation des enregistrements de journal par ID de requête peut fournir des informations précieuses 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 requête 0 a été reçue au bout de 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 des requêtes était de 11 millisecondes, dont 7 millisecondes par la cible et 4 millisecondes par Edge Microgateway lui-même.

2. Exemple de requête sortante adressé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, selon le niveau de journalisation. Il peut s'agir de statistiques liées à un enregistrement de statistiques, d'un avertissement en cas d'avertissement ou d'une erreur en cas d'erreur.
treq : identifie l'événement. Ici, il s'agit de la requête 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 du 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 : horodatage Unix

info : dépend du contexte. Il peut s'agir d'une information, d'un avertissement ou d'une erreur, selon le niveau de journalisation. Il peut s'agir de statistiques liées à un enregistrement de statistiques, d'un avertissement en cas d'avertissement ou d'une erreur en cas d'erreur.
tres : identifie l'événement, Dans ce cas, cible la réponse.
s : état de la réponse HTTP.
d : durée en millisecondes. Temps nécessaire à l'appel d'API par la cible.
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 : horodatage Unix

info : dépend du contexte. Il peut s'agir d'une information, d'un avertissement ou d'une erreur, selon le niveau de journalisation. Il peut s'agir de statistiques liées à un enregistrement de statistiques, d'un avertissement en cas d'avertissement ou d'une erreur en cas d'erreur.
res : identifie l'événement. Dans ce cas, répondez 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 nécessaire à Edge Microgateway lui-même.
i : ID de l'entrée de journal. Les quatre entrées d'événement partageront cet ID.

Planification du fichier journal

Les fichiers journaux sont alternés selon l'intervalle spécifié par l'attribut de configuration rotate_interval. Les entrées continueront d'être ajoutées au même fichier journal jusqu'à l'expiration de l'intervalle de rotation. Toutefois, chaque fois que Edge Microgateway est redémarré, reçoit un nouvel UID et crée un ensemble de fichiers journaux avec cet UID. Consultez également l'article 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 en savoir plus sur les modifications de 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) une URL qui pointe 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 pour générer la paire de clés publique/privée: edgemicro genkeys. Pour en savoir plus, consultez la section Configurer Edge Microgateway.
jwt_public_key: (valeur par défaut: aucune) URL pointant vers le proxy Edge Microgateway qui est 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. L'URL suivante est renvoyée lorsque vous exécutez la commande edgemicro configure pour déployer le proxy. Pour en savoir plus, consultez la section 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 d'arrêter la connexion. Ce paramètre est destiné à contrecarrer les attaques par déni de service. En règle générale, définissez-la 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 : consigne uniquement les messages d'avertissement.
  - error : consigne uniquement les messages d'erreur.
- dir: (valeur 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, lorsque l'enregistrement de statistiques est écrit dans le fichier journal de l'API.
- rotate_interval: (valeur par défaut: 24) intervalle, en heures, pendant lequel les fichiers journaux sont alternés.

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

dir: chemin d'accès relatif entre le répertoire ./gateway et le répertoire ./plugins, ou un chemin absolu.
Sequence: liste des modules de plug-in à ajouter à votre instance Edge Microgateway. 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, configurez votre débogueur IDE pour qu'il écoute 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 changé. L'interrogation récupère toutes les modifications apportées à Edge (modifications apportées aux produits, aux proxys compatibles avec les micropasserelles, etc.) ainsi que les modifications apportées au fichier de configuration local.
disable_config_poll_interval: : (valeur par défaut: false) Définissez la valeur sur disable_config_poll_interval: pour disable_config_poll_interval: l'interrogation de modifications automatiques.
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 d'expiration du délai, Edge Microgateway répond avec un code d'état 504. (Ajout de la version 2.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 (par défaut : true) : définissez la valeur 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 se trouve dans la demande, sa valeur sera définie sur la valeur de l'adresse IP du client dans Edge Analytics.
x-forwarded-host: (par défaut: true) définissez la valeur sur "false" pour empêcher la transmission des en-têtes x-forwarded-host à la cible.
x-request-id: (valeur 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: vrai) définissez la valeur sur "false" pour empêcher la transmission des en-têtes x-response-time à la cible.
via: (valeur par défaut: true) définissez la valeur sur "false" pour empêcher la transmission à la cible via des en-têtes.

Attributs OAuth

Ces paramètres configurent la manière dont l'authentification client est appliquée par Edge Microgateway.

allowNoAuthorization: (valeur par défaut: false). Si la valeur est définie sur "true", les appels d'API sont autorisés à passer 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 à être transmis 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 (par défaut).
permission-header (valeur 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 lorsque la cible doit utiliser l'en-tête "Authorization" à 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 la page Utiliser une clé API.
keepAuthHeader (par défaut : false) : si la valeur par défaut est "true", l'en-tête d'autorisation envoyé dans la requête est transmis à la cible (il est conservé).
allowOAuthOnly : si cette valeur est définie sur "true", chaque API doit comporter un en-tête d'autorisation avec un jeton d'accès de support. Permet de n'autoriser que le modèle de sécurité OAuth (tout en maintenant la rétrocompatibilité). (Ajout de 4.2.x)
allowAPIKeyOnly : si ce paramètre est défini sur "true", chaque API doit comporter un en-tête x-api-key (ou un emplacement personnalisé) avec une clé API.Vous permet d'autoriser uniquement le modèle de sécurité de la clé API (tout en maintenant la rétrocompatibilité). (Ajout de la version 4.2.x)
Remarque:Ne définissez pas à la fois allowOAuthOnly et allowOAuthOnly sur "true". Le paramètre par défaut est que les deux indicateurs sont définis sur "false" (pour assurer la rétrocompatibilité).

Attributs spécifiques aux plug-ins

Pour plus d'informations sur les attributs configurables pour chaque plug-in, consultez la section Utiliser des plug-ins.

Filtrer les proxys

Vous pouvez filtrer les proxys compatibles avec la micro-passerelle qu'une instance Edge Microgateway traitera. Au démarrage d'Edge Microgateway, il télécharge tous les proxys compatibles avec les micro-passerelles dans l'organisation à laquelle il est associé. Utilisez la configuration suivante pour limiter les proxys traités par la micropasserelle. Par exemple, cette configuration limite le nombre de proxys traités par la micropasserelle à trois: 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 l'affichage des informations de chemin de requête dans les analyses Edge. Ajoutez le code suivant à la configuration de la micropasserelle pour masquer l'URI et/ou le chemin de la requête. Notez que l'URI se compose des parties nom d'hôte et chemin d'accès de la requête.

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

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

Compatible avec la version 4.2.x

Si Edge Microgateway est installé derrière un pare-feu, la passerelle risque de ne pas pouvoir communiquer avec Apigee Edge. Dans ce cas, vous pouvez envisager deux options:

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 CONNECT HTTP pour tunneliser les requêtes HTTP via une seule connexion TCP. (Il en va de même si les variables d'environnement permettant de configurer le proxy sont activées avec le protocole TLS.)

Option 2 :

La deuxième option consiste à spécifier un proxy et à définir "proxy_tunnel" sur "false" dans le fichier de configuration de la micro-passerelle. 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 quels hôtes ne doivent pas gérer les proxys Edge Microgateway: HTTP_PROXY, HTTPS_PROXY et NO_PROXY.

Vous pouvez définir NO_PROXY en tant que liste de domaines séparés par une virgule vers lesquels Edge Microgateway ne doit pas se servir d'un proxy. Exemple :

export NO_PROXY='localhost,localhost:8080'

Définissez HTTP_PROXY et HTTPS_PROXY sur le point de terminaison du proxy HTTP 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

Découvrez comment configurer Edge Microgateway derrière un pare-feu d'entreprise dans 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 de base d'un proxy edgemicro_* (compatible avec Microgateway). Par exemple, un chemin de base de /team/*/members permet aux clients d'appeler https://[host]/team/blue/members et https://[host]/team/green/members sans avoir à créer de proxys d'API pour prendre en charge les nouvelles équipes. Notez que /**/ n'est pas compatible.

Important:Apigee ne permet PAS l'utilisation du caractère générique "*" comme premier élément d'un chemin de base. Par exemple, la recherche /*/ n'est PAS prise en charge.

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 est utile pour le dépannage et le débogage des plug-ins personnalisés.

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=*.
Démarrez votre débogueur et configurez-le pour qu'il écoute le numéro de port pour le processus de débogage.
Vous pouvez maintenant parcourir le code d'Edge Microgateway, définir des points d'arrêt, des expressions de contrôle, etc.

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

Vérifier les fichiers journaux

Si vous rencontrez des problèmes, veillez à consulter les détails de l'exécution et les erreurs dans les fichiers journaux. 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 incluant le proxy d'authentification Edge Microgateway.

Mise en cache des 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 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 plus d'informations sur l'utilisation d'un jeton OAuth avec des requêtes proxy, consultez Secure Edge Microgateway.

Utiliser une clé API

Pour plus d'informations sur l'utilisation de clés API avec des requêtes proxy, consultez Secure Edge Microgateway.

Remarque:Vous pouvez également transmettre la clé API dans un paramètre de requête. Par exemple, où [key] correspond à la clé API, une chaîne de lettres et de chiffres :

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

Configurer le nom de la clé API

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

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