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

<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 3.2.x

Cette rubrique explique comment gérer et configurer Edge Microgateway.

Mettre à niveau Edge Microgateway si vous disposez d'une connexion Internet

Cette section explique comment mettre à niveau une installation existante d'Edge Microgateway. Si vous travaillez sans connexion Internet, consultez Puis-je installer Edge Microgateway sans connexion Internet ?

Apigee vous recommande de tester votre configuration existante la nouvelle version avant de mettre à niveau votre environnement de production.

Exécutez la commande npm suivante pour effectuer la mise à niveau vers la dernière version d'Edge. Microgateway:
```
npm upgrade edgemicro -g
```
Pour installer une version spécifique d'Edge Microgateway, vous devez indiquer la version number dans la commande d'installation. Par exemple, pour effectuer une installation vers la version 3.2.3, utilisez le la commande suivante:
```
npm install edgemicro@3.2.3 -g
```

Vérifiez le numéro de version. Par exemple, si vous avez installé la version 3.2.3:

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

Enfin, installez la dernière version du proxy edgemicro-auth:
```
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
```

Apporter des modifications à 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.

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 correspond au répertoire avec préfixe npm. Voir <ph type="x-smartling-placeholder"></ph> Où Edge Microgateway est-il installé si vous ne trouvez pas ce répertoire.

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

edgemicro init
edgemicro configure [params]
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 ~/.edgemicro.

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

edgemicro stop
edgemicro configure [params]
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 Les env sont les noms de votre organisation et de votre environnement Apigee Edge. Vous pouvez utiliser ce fichier pour effectuer des réglages les modifications, puis les 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):

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 une organisation administrateur).
- $ENV est un environnement de votre organisation (tel que "test" ou "prod").
- $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 "configure".
Exemple :
```
edgemicro reload -o docs -e test -k 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

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 une organisation administrateur).
- $ENV est un environnement de votre organisation (tel que "test" ou "prod").
- $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 "configure".
Exemple :
```
edgemicro start -o docs -e test -k 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

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

Regardez les vidéos suivantes pour en savoir plus sur la configuration du protocole TLS dans Apigee Edge Microgateway:

Vidéo	Description
Configurer le protocole TLS unidirectionnel vers le nord	Découvrez comment configurer TLS dans Apigee Edge Microgateway. Cette vidéo présente le protocole TLS et son importance, présente dans Edge Microgateway, et montre comment configurer le protocole TLS à sens unique Northbound.
Configurer le protocole TLS bidirectionnel en direction du nord	Voici la deuxième vidéo sur la configuration du protocole TLS dans Apigee Edge Microgateway. Ce explique comment configurer le protocole TLS bidirectionnel avec la limite nord.
Configurer le protocole TLS unidirectionnel et bidirectionnel en direction du sud	Cette troisième vidéo sur la configuration de TLS dans Apigee Edge Microgateway explique comment configurer TLS vers le sud à sens unique et bidirectionnel.

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:

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.

Ajoutez l'attribut edgemicro:ssl au fichier de configuration Edge Microgateway. Pour obtenir des options, consultez le tableau ci-dessous. 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

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é: 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, 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 du 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ée par un ":".
`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 vérification échoue, une erreur est renvoyée.
`secureProtocol`	Méthode SSL à utiliser. Par exemple, "SSLv3_method" force le passage à la version 3 de SSL.
`servername`	Nom du serveur de l'extension TLS SNI (Server Name Indication).
`requestCert`	"true" pour SSL bidirectionnel ; "false" pour SSL unidirectionnel

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. Notez que vous pouvez spécifier plusieurs cibles spécifiques. Un exemple d'emplacements multicibles est inclus ci-dessous.

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

edgemicro:
...
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é:

edgemicro:
...
targets:
  - host: 'myserver.example.com'
    ssl:
      client:
        key: /Users/myname/twowayssl/ssl/client.key
        cert: /Users/myname/twowayssl/ssl/ca.crt
        passphrase: admin123
        rejectUnauthorized: true

Voici un exemple pour TLS:

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

Si vous souhaitez appliquer des paramètres TLS/SSL à plusieurs cibles spécifiques, vous devez spécifier le premier hôte de la configuration comme "vide", ce qui active les requêtes universelles, puis spécifiez des les hôtes dans n’importe quel ordre. Dans cet exemple, les paramètres sont appliqués à plusieurs hôtes spécifiques:

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

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 du 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ée par un ":".
`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 vérification échoue, une erreur est renvoyée.
`secureProtocol`	Méthode SSL à utiliser. Par exemple, "SSLv3_method" force le passage à la version 3 de SSL.
`servername`	Nom du serveur de 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 ajouter la prise en charge des revendications personnalisées sur un jeton Web JSON. (JWT), configurer l'expiration des jetons 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é

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

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

</ph> Important: Si vous modifiez l'URI du service d'authentification, vous devez également configurez ces attributs dans votre fichier de configuration Edge Microgateway: <ph type="x-smartling-placeholder">

edgeconfig:verify_api_key_url : définissez cette URL de sorte qu'elle pointe vers la clé API. de votre service d'authentification personnalisé. Dans le proxy Edgemicro-auth par défaut, cette URL est: https://myorg-myenv.apigee.net/edgemicro-auth/publicKey
edgeconfig:products - Définissez cette URL de sorte qu'elle redirige vers le point de terminaison des produits de votre service d'authentification personnalisé. Dans le proxy Edgemicro-auth par défaut, cette URL est: https://myorg-myenv.apigee.net/edgemicro-auth/products

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

Gérer les 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 . Reportez-vous également à la section Faire des modifications.

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 spécifiez le niveau de journalisation à utiliser dans la configuration edgemicro. Pour une Pour obtenir la liste complète des niveaux de journalisation et de leur description, consultez la section Attributs Edgemicro.

Par exemple, la configuration suivante définit le niveau de journalisation sur debug:

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

Modifier les intervalles des journaux

Vous pouvez configurer ces intervalles dans le fichier de configuration Edge Microgateway. Consultez également la section Apporter des modifications à la configuration.

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

Assouplir les autorisations strictes des fichiers journaux

Par défaut, Edge Microgateway génère le fichier journal de l'application (api-log.log) avec l'autorisation de fichier défini sur 0600. Ce niveau d'autorisation ne permet pas aux applications ni aux utilisateurs externes pour lire le fichier journal. Pour assouplir ce niveau d'autorisation strict, définissez logging:disableStrictLogFile à true. Lorsque cet attribut est défini sur true, le fichier journal est créé avec l'autorisation de fichier définie sur 0755. Si la valeur est false ou si l'attribut n'est pas fourni, l'autorisation par défaut est 0600.

Ajouté dans la version 3.2.3.

Exemple :

edgemicro:
 logging:
   disableStrictLogFile: true

Bonnes pratiques en matière 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 génère un fichier journal portant l'extension .log. La pour les fichiers journaux est la suivante:

edgemicro-HOST_NAME-INSTANCE_ID-api.log

Exemple :

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.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 la console, définissez l'option de ligne de commande DEBUG=* lorsque vous démarrez Edge Microgateway. Exemple :

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

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 : niveau de journalisation. Cette valeur dépend du contexte de la transaction et du niveau de journalisation défini dans la configuration edgemicro. Consultez la section Définir le niveau de journalisation. Pour les statistiques enregistrées, le niveau est défini sur stats. Les statistiques sont enregistrées à un intervalle régulier défini avec la configuration stats_log_interval ; Consultez également l'article Modifier l'intervalle des journaux.
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 : niveau de journalisation. Cette valeur dépend du contexte de la transaction et du niveau de journalisation défini dans la configuration edgemicro. Consultez la section Définir le niveau de journalisation. Pour les statistiques enregistrées, le niveau est défini sur stats. Les statistiques sont enregistrées à un intervalle régulier défini avec la configuration stats_log_interval ; Consultez également l'article Modifier l'intervalle des journaux.
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 : niveau de journalisation. Cette valeur dépend du contexte de la transaction et du niveau de journalisation défini dans la configuration edgemicro. Consultez la section Définir le niveau de journalisation. Pour les statistiques enregistrées, le niveau est défini sur stats. Les statistiques sont enregistrées à un intervalle régulier défini avec la configuration stats_log_interval ; Consultez également l'article Modifier l'intervalle des journaux.
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 : niveau de journalisation. Cette valeur dépend du contexte de la transaction et du niveau de journalisation défini dans la configuration edgemicro. Consultez la section Définir le niveau de journalisation. Pour les statistiques enregistrées, le niveau est défini sur stats. Les statistiques sont enregistrées à un intervalle régulier défini avec la configuration stats_log_interval ; Consultez également l'article Modifier l'intervalle des journaux.
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 à l'intervalle spécifié par la variable rotate_interval attribut configuration. Les entrées continueront d'être ajoutées au même fichier journal jusqu'à l'expiration de l'intervalle de rotation. Cependant, 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. Voir aussi Une bonne maintenance des fichiers journaux pratiques.

Messages d'erreur

Certaines entrées de journal contiennent des messages d'erreur. Pour aider à identifier où et pourquoi les erreurs se produisent, consultez le message d'erreur Edge Microgateway référence.

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

Emplacement fichier de configuration

Les attributs de configuration décrits dans cette section se trouvent dans la passerelle Edge Microgateway fichier de configuration. Reportez-vous également à la section Faire des modifications.

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 Configuration et la configuration d'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 Configuration et la configuration d'Edge Microgateway.
quotaUri: définit cette configuration. si vous souhaitez gérer les quotas via le proxy edgemicro-auth, déployées dans votre organisation. Si cette propriété n'est pas définie, le point de terminaison de quota est défini par défaut sur le point de terminaison interne Edge Microgateway.
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

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">
- level: (par défaut: erreur) <ph type="x-smartling-placeholder">
  - info (recommandé) : consigne toutes les requêtes et les réponses qui transitent par un Instance Edge Microgateway.
  - warn : consigne uniquement les messages d'avertissement.
  - error : enregistre uniquement les messages d'erreur.
  - debug : consigne les messages de débogage avec des informations, des avertissements et des messages d'erreur.
  - trace : consigne les informations de trace liées aux erreurs, ainsi que des informations, des avertissements et des messages d'erreur.
  - none : ne créez pas de fichier journal.
- 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 l'article Développer des plug-ins personnalisés.

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éfini sur true pour désactiver la vérification des changements automatiques.
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)
keep_alive_timeout: cette propriété vous permet de définir la passerelle Edge Microgateway. délai avant expiration (en millisecondes). (Par défaut: 5 secondes) (v3.0.6 ajoutée)
headers_timeout: cet attribut limite la durée (en millisecondes) l'analyseur HTTP attend de recevoir les en-têtes HTTP complets.
Exemple :
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
En interne, le paramètre définit l'instance Node.js Server.headersTimeout dans les requêtes. (Par défaut: 5 secondes de plus que l'heure définie avec edgemicro.keep_alive_timeout. Cette valeur par défaut empêche les équilibreurs de charge ou les proxys de perdre la connexion par erreur. (v3.1.1 ajoutée)
noRuleMatchAction: : (chaîne) action à effectuer (autoriser ou refuser l'accès) si le définie dans le plug-in accesscontrol n'est pas résolue (sans correspondance). Valeurs valides: ALLOW ou DENY. Par défaut: ALLOW (Ajoutée: v3.1.7)
enableAnalytics: : (valeur par défaut: true) définissez l'attribut sur enableAnalytics: sur empêcher le plug-in d'analyse du chargement. Dans ce cas, aucun appel à l'analyse Apigee Edge ne sera effectué. Si la valeur est true ou lorsque cet attribut n'est pas fourni, le plug-in d'analyse fonctionnera comme d'habitude. Voir Attributs Edgemicro pour plus de détails. (v3.1.8 ajoutée).
Exemple :
```
edgemicro
  enableAnalytics=false|true
```
Si enableAnalytics est défini sur false, mais que Edge Démarrez Microgateway avec le plug-in de métriques, puis le plug-in d'analyse fonctionnera comme d'habitude. car le plug-in de métriques a besoin d'un plug-in d'analyse pour fonctionner. Pour en savoir plus sur le plug-in de métriques, consultez la page Edge Microgateway v1.3.6 les notes de version.

on_target_response_abort: cet attribut vous permet de contrôler le comportement d'Edge Microgateway si la connexion entre le client (Edge Microgateway) et la le serveur cible se ferme prématurément.

Valeur	Description
Par défaut	Si `on_target_response_abort` n'est pas spécifié, le comportement par défaut est de tronquer la réponse sans afficher d'erreur. Dans les fichiers journaux, un avertissement s'affiche avec `targetResponse aborted` et un code de réponse 502.
`appendErrorToClientResponseBody`	L'erreur personnalisée `TargetResponseAborted` est renvoyée à client. Dans les fichiers journaux, un avertissement s'affiche avec `targetResponse aborted` et un code de réponse 502. Dans l'erreur `TargetResponseAborted` est consignée avec le message `Target response ended prematurely.`
`abortClientRequest`	Edge Microgateway annule la requête et un avertissement est écrit dans les fichiers journaux: `TargetResponseAborted` par le code d'état de la requête 502.

Exemple :

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

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 Utilisation une clé API.
keep-authorization-header: (valeur par défaut: false) si ce champ est défini sur "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 "true", chaque API doit disposer d'une autorisation en-tête par un jeton d'accès de support. Permet d'autoriser uniquement le modèle de sécurité OAuth (tout en en maintenant la rétrocompatibilité). (Ajoutée en version 2.4.x)
allowAPIKeyOnly : si la valeur est "true", chaque API doit comporter un l'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ée en version 2.4.x)
Ne définissez pas à la fois allowOAuthOnly et allowAPIKeyOnly sur "true". Le paramètre par défaut est que les deux indicateurs sont définis sur "false" (pour assurer la rétrocompatibilité).
gracePeriod : ce paramètre permet d'éviter les erreurs causées par des écarts entre l'horloge système et les heures Nbf (Pas avant le) ou d'émission le (IAT) spécifié dans le jeton d'autorisation JWT. Définissez ce paramètre sur le nombre de secondes autorisées. de ces écarts. (Ajoutée à la version 2.5.7)

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:

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

Filtrer les produits par nom

Utilisez la configuration suivante pour limiter le nombre de produits d'API pour lesquels Edge Microgateway de téléchargements et de processus. Pour filtrer les produits téléchargés, ajoutez l'productnamefilter paramètre de requête à l'API /products répertoriée dans le fichier *.config.yaml d'Edge Microgateway . Exemple :

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

Notez que la valeur du paramètre de requête doit être spécifiée au format "expression régulière" et peut être encodée au format URL. Par exemple, l'expression régulière ^[Ee]dgemicro.*$ intercepte les noms tels que: "edgemicro-test-1" "edgemicro_demo" et "Edgemicro_New_Demo". Valeur encodée au format URL, adaptée aux à utiliser dans le paramètre de requête, est: %5E%5BEe%5Ddgemicro.%2A%24.

Le résultat de débogage suivant montre que seuls les produits filtrés ont été téléchargés:

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

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

         ]
      },
      {
         "apiResources":[

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

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

         ]
      }
   ]
}

Filtrer les produits par attributs personnalisés

Pour filtrer les produits en fonction d'attributs personnalisés:

Dans l'interface utilisateur Edge, sélectionnez le proxy edgemicro_auth dans l'organisation/l'environnement où vous avez configuré Edge Microgateway.
Dans le menu "Développer", ouvrez la règle JavaAccroche dans l'éditeur.
Ajoutez un attribut personnalisé avec la clé products.filter.attributes séparée par une virgule liste de noms d'attributs. Uniquement les produits contenant l'un des noms d'attributs personnalisés est renvoyé à Edge Microgateway.
Vous pouvez désactiver la vérification pour voir si le produit est activé pour l'environnement actuel en paramétrant l'attribut personnalisé products.filter.env.enable sur false. (La valeur par défaut est "true".)
(Cloud privé uniquement) Si vous êtes sur Edge pour Private Cloud, définissez la propriété org.noncps à true pour extraire des produits pour des environnements non-CPS.

Exemple :

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

Configurer la fréquence d'envoi des données analytiques

Utilisez ces paramètres de configuration pour contrôler la fréquence à laquelle Edge Microgateway envoie d'analyse de données vers Apigee:

bufferSize (facultatif): nombre maximal d'enregistrements Analytics que le groupe peut se conserver avant de commencer à supprimer les enregistrements les plus anciens. Par défaut: 10 000
batchSize (facultatif): taille maximale d'un lot d'enregistrements Analytics. envoyés à Apigee. Par défaut: 500
flushInterval (facultatif): nombre de millisecondes entre chaque vidage de un lot d'enregistrements d'analyse envoyés à Apigee. Valeur par défaut: 5 000

Exemple :

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

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'

Séparation des appels d'API dans Edge Analytics

Vous pouvez configurer le plug-in d'analyse de façon à séparer un chemin d'accès spécifique à l'API afin qu'il apparaisse comme un proxy distinct dans les tableaux de bord Edge Analytics. Par exemple, vous pouvez séparer une API de vérification de l'état dans le tableau de bord pour éviter de la confondre avec les appels proxy d'API réels. Dans Dans le tableau de bord Analytics, les proxys distincts suivent ce modèle de dénomination:

edgemicro_proxyname-health

L'image suivante montre deux proxys distincts dans le tableau de bord Analytics: edgemicro_hello-health et edgemicro_mock-health:

Utilisez ces pour séparer les chemins relatifs et absolus du tableau de bord Analytics sous la forme de proxys distincts:

relativePath (facultatif): spécifie un chemin d'accès relatif à séparer dans le paramètre tableau de bord Analytics. Par exemple, si vous spécifiez /healthcheck, tous les appels d'API contenant le chemin d'accès /healthcheck apparaîtra dans le tableau de bord sous la forme edgemicro_proxyname-health. Notez que cette option ignore le chemin de base du proxy. Pour séparer les données en fonction d'un chemin d'accès complet, y compris le chemin de base, utilisez l'option proxyPath.
proxyPath (facultatif): spécifie le chemin d'accès complet d'un proxy d'API, y compris le proxy basepath, afin de les séparer dans le tableau de bord d'analyse. Par exemple, si vous spécifiez /mocktarget/healthcheck, où /mocktarget est le chemin de base du proxy, tous les appels d'API avec le chemin /mocktarget/healthcheck dans le tableau de bord sous la forme edgemicro_proxyname-health.

Par exemple, dans la configuration suivante, tout chemin d'API contenant /healthcheck être séparés par le plug-in d'analyse. Cela signifie que /foo/healthcheck et /foo/bar/healthcheck sera séparée en tant que proxy distinct appelé edgemicro_proxyname-health dans le tableau de bord d'analyse.

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

Dans la configuration suivante, toute API avec le chemin de proxy /mocktarget/healthcheck va sera séparé en tant que proxy distinct appelé edgemicro_proxyname-health dans le tableau de bord d'analyse.

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

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

Utiliser un proxy HTTP pour la communication avec Apigee Edge

Ajouté dans la version 3.1.2.

Pour utiliser un proxy HTTP pour la communication entre Edge Microgateway et Apigee Edge, procédez comme suit : suivantes:

Définir les variables d'environnement HTTP_PROXY, HTTPS_PROXY et NO_PROXY. Ces contrôlent les hôtes de chaque proxy HTTP que vous souhaitez utiliser pour communiquer avec Apigee Edge ou les hôtes qui ne doivent pas gérer la communication avec Apigee Edge. Exemple :
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
Notez que NO_PROXY peut être une liste de domaines séparés par une virgule que Edge Microgateway ne doit pas être utilisé comme proxy.

Pour en savoir plus sur ces variables, consultez https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables.
Redémarrez Edge Microgateway.

Utiliser un proxy HTTP pour la communication cible

Ajouté dans la version 3.1.2.

Pour utiliser un proxy HTTP pour la communication entre Edge Microgateway et les cibles de backend, effectuer les opérations suivantes:

Ajoutez la configuration suivante au fichier de configuration de la micropasserelle:
```
edgemicro:
  proxy:
    tunnel: true | false
    url: proxy_url
    bypass: target_host # target hosts to bypass the proxy.
    enabled: true | false
```
Où :
- tunnel (facultatif) : (facultatif) si la valeur est "true", Edge Microgateway utilise la méthode HTTP CONNECT pour tunneler HTTP de requêtes sur une seule connexion TCP. Il en va de même si les variables d'environnement, comme mentionnées ci-dessous, pour la configuration du proxy si TLS est activé). Par défaut : false
- url: URL du proxy HTTP.
- contourner (facultatif) : spécifie une ou plusieurs URL d'hôte cible séparées par une virgule qui doivent contourner le proxy HTTP. Si cette propriété n'est pas définie, utilisez NO_PROXY pour spécifier les URL cibles à ignorer.
- enabled: si "true" et que proxy.url est défini, utilisez la valeur proxy.url pour le proxy HTTP. Si la valeur est "true" et que proxy.url n'est pas défini, utiliser les proxys spécifiés dans le proxy HTTP les variables d'environnement HTTP_PROXY et HTTPS_PROXY, comme décrit dans Utilisez un proxy HTTP pour la communication avec Apigee Edge.
Exemple :
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
REMARQUE : Remarque: Si edgemicro.proxy est omis du ou si edgemicro.proxy.enabled est défini sur "false", Edge Microgateway n'utilisera pas un proxy HTTP pour la communication cible.
Redémarrez Edge Microgateway.

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 d'une Proxy edgemicro_* (compatible avec les microservices) 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 que vous ayez besoin de créer de nouveaux proxys d'API pour soutenir de nouvelles équipes. Notez que /**/ n'est pas accepté.

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, la recherche /*/ n'est PAS prise en charge.

Effectuer une rotation des clés JWT

Comment Edge Microgateway utilise les jetons JWT

Le jeton Web JSON (JWT, JSON Web Token) est une norme de jeton décrite dans le document RFC7519. Le jeton JWT permet de signer un ensemble de revendications, qui peut être vérifié de manière fiable par le destinataire du jeton JWT.

Vous pouvez générer un jeton JWT à l'aide de la CLI et l'utiliser dans le En-tête d'autorisation des appels d'API au lieu d'une clé API. Exemple :

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

Pour en savoir plus sur la génération de jetons JWT avec la CLI, consultez la page Générer un jeton.

Qu'est-ce que la rotation des clés ?

Après avoir généré un jeton JWT, vous devrez peut-être modifier le jeton paire de clés publique/privée stockée dans la KVM chiffrée Edge. Ce processus de génération d'une nouvelle clé s'appelle la rotation des clés. Lorsque vous effectuez une rotation des clés, une nouvelle paire de clés privée/publique est générée stocké dans la "microgateway" KVM dans votre organisation/environnement Apigee Edge. En outre, l'ancienne clé publique est conservée avec sa valeur d'ID de clé d'origine.

Pour générer un jeton JWT, Edge utilise les informations stockées dans la KVM chiffrée. A Une KVM appelée microgateway a été créée et contient des clés lors de sa configuration initiale Edge Microgateway. Les clés de la KVM sont utilisées pour signer et chiffrer un jeton JWT.

Les clés KVM sont les suivantes:

private_key : dernière clé privée RSA (la plus récente) utilisée pour signer les jetons JWT.
public_key : dernier certificat (le plus récemment créé) utilisé pour vérifier les jetons JWT signé avec la clé private_key.
private_key_kid : le dernier ID de clé privée (créé le plus récemment). Cet ID de clé est associée à la valeur private_key et est utilisée pour prendre en charge la rotation des clés.
public_key1_kid : dernier ID de clé publique (le plus récemment créé). Cette clé est associée à la valeur "public_key1" et permet la rotation des clés. Cette valeur est identique à l'enfant de clé privée.
public_key1 : la dernière clé publique (créée en dernier)

Lorsque vous effectuez une rotation des clés, les valeurs de clé existantes sont remplacées dans le mappage sont ajoutées pour conserver les anciennes clés publiques. Exemple :

public_key2_kid : ancien ID de clé publique Cette clé est associée au public_key2 et permet de gérer la rotation des clés.
public_key2 : ancienne clé publique

Les jetons JWT présentés pour validation seront validés à l'aide de la nouvelle clé publique. Si la vérification échoue, l'ancienne clé publique sera utilisée jusqu'à l'expiration du JWT (après l'intervalle token_expiry*, 30 minutes par défaut). Dans de cette façon, vous pouvez « faire pivoter » sans interrompre immédiatement le trafic de l'API.

Effectuer une rotation des clés

Cette section explique comment effectuer une rotation des clés.

Pour mettre à niveau la KVM, utilisez la commande edgemicro upgradekvm. Pour en savoir plus lors de l'exécution de cette commande, consultez la section Mise à niveau la KVM. Vous n'avez besoin d'effectuer cette étape qu'une seule fois.
Pour mettre à niveau le proxy edgemicro-oauth, utilisez la commande edgemicro upgradeauth. Pour plus d'informations sur l'exécution de cette commande, consultez la section Dégradation du proxy Edgemicro-auth Vous n'avez besoin d'effectuer cette étape qu'une seule fois.
Ajoutez la ligne suivante à votre fichier ~/.edgemicro/org-env-config.yaml, où vous devez spécifiez l'organisation et l'environnement que vous avez configurés pour utiliser la micropasserelle:
```
jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
```

Exécutez la commande de rotation des clés pour effectuer la rotation des clés. Pour plus d'informations sur cette commande, consultez Rotation des clés :

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

Exemple :

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

Après la rotation des clés, Edge renvoie plusieurs clés à Edge Microgateway. Notez que Dans l'exemple suivant, chaque clé possède une valeur "enfant" unique (ID de clé). La micropasserelle utilise ensuite ces pour valider les jetons d'autorisation. Si la validation du jeton échoue, la micropasserelle cherche voyez si le jeu de clés contient une clé plus ancienne et essaie cette clé. Le format du renvoyées est une clé Web JSON (JWK). Pour en savoir plus sur ce format, consultez le document RFC 7517.

{
  "keys": [
    {
      "kty": "RSA",
      "n": "nSl7R_0wKLiWi6cO3n8aOJwYGBtinq723Jgg8i7KKWTSTYoszOjgGsJf_MX4JEW1YCScwpE5o4o8ccQN09iHVTlIhk8CNiMZNPipClmRVjaL_8IWvMQp1iN66qy4ldWXzXnHfivUZZogCkBNqCz7VSC5rw2Jf57pdViULVvVDGwTgf46sYveW_6h8CAGaD0KLd3vZffxIkoJubh0yMy0mQP3aDOeIGf_akeZeZ6GzF7ltbKGd954iNTiKmdm8IKhz6Y3gLpC9iwQ-kex_j0CnO_daHl1coYxUSCIdv4ziWIeM3dmjQ5_2dEvUDIGG6_Az9hTpNgPE5J1tvrOHAmunQ",
      "e": "AQAB",
      "kid": "2"
    },
    {
      "kty": "RSA",
      "n": "8BKwzx34BMUcHwTuQtmp8LFRCMxbkKg_zsWD6eOMIUTAsORexTGJsTy7z-4aH0wJ3fT-3luAAUPLBQwGcuHo0P1JnbtPrpuYjaJKSZOeIMOnlryJCspmv-1xG4qAqQ9XaZ9C97oecuj7MMoNwuaZno5MvsY-oi5B_gqED3vIHUjaWCErd4reONyFSWn047dvpE6mwRhZbcOTkAHT8ZyKkHISzopkFg8CD-Mij12unxA3ldcTV7yaviXgxd3eFSD1_Z4L7ZRsDUukCJkJ-8qY2-GWjewzoxl-mAW9D1tLK6qAdc89yFem3JHRW6L1le3YK37-bs6b2a_AqJKsKm5bWw",
      "e": "AQAB",
      "kid": "1"
    }
  ]
}

Configurer une instruction "pas avant" retard

Pour les versions 3.1.5 et antérieures, la nouvelle clé privée générée par la commande rotatekey prenait immédiatement, et les nouveaux jetons générés ont été signés avec la nouvelle clé privée. Toutefois, la nouvelle clé publique n'était mise à la disposition des instances Edge Microgateway que toutes les 10 minutes (par défaut) lors de l'actualisation de la configuration de la microgateway. En raison de ce délai entre la signature du jeton et l'actualisation de l'instance microgateway, les jetons signés avec la dernière clé seront rejetés jusqu'à toutes les instances ont reçu la dernière clé publique.

Lorsqu'il existe plusieurs instances de micropasserelle, le délai de clé publique entraînait parfois des erreurs d'exécution intermittentes avec l'état 403, car la validation des jetons transmettait mais échouent sur une autre instance jusqu'à ce que toutes les instances soient actualisées.

À partir de la version 3.1.6, un nouvel indicateur dans la commande rotatekey vous permet de spécifier un délai pour la nouvelle la clé privée, ce qui laisse le temps d'actualiser toutes les instances de la micropasserelle. et recevez la nouvelle clé publique. Le nouvel indicateur est --nbf, qui signifie "pas avant". Cette option nécessite une valeur entière correspondant au nombre de minutes de retard.

Dans l'exemple suivant, le délai est défini sur 15 minutes:

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

Notez qu'une bonne pratique consiste à définir le délai sur une valeur supérieure au paramètre de configuration config_change_poll_internal, qui est de 10 minutes par défaut. Consultez également les attributs Edgemicro.

Filtrer les proxys téléchargés

Par défaut, Edge Microgateway télécharge tous les proxys de votre organisation Edge commençant par le préfixe "edgemicro_". Vous pouvez modifier cette valeur par défaut pour télécharger des proxys dont les noms correspondent à un modèle.

Ouvrez votre fichier de configuration Edge Micro: ~/.edgemicro/org-env-config.yaml
Ajoutez l'élément proxyPattern sous Edge_config. Par exemple, le format suivant télécharger des proxys tels que Edgemicro_foo, Edgemicro_fast et Edgemicro_first.
```
edge_config:
…
proxyPattern: edgemicro_f*
```

Spécifier des produits sans proxy d'API

Dans Apigee Edge, vous pouvez créer un produit d'API qui ne contient aucun proxy d'API. Cette configuration de produit permet à une clé API associée au produit de fonctionner avec n'importe quelle déployé dans votre organisation. Depuis la version 2.5.4, Edge Microgateway est compatible avec ce produit configuration.

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.

Redémarrez Edge Microgateway en mode débogage. Pour ce faire, ajoutez DEBUG=* au au début de la commande start:
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
REMARQUE : Sous Windows, utilisez SET DEBUG=*

Pour diriger la sortie de débogage vers un fichier, vous pouvez utiliser la commande suivante:
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
Démarrez votre débogueur et configurez-le pour qu'il écoute le numéro de port pendant le processus de débogage.
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 une clé API

Vous pouvez transmettre la clé API dans une requête API en tant que paramètre de requête ou dans un en-tête. Par défaut, L'en-tête et le nom du paramètre de requête sont tous deux x-api-key.

Exemple de paramètre de requête:

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

Exemple d'en-tête :

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

Configurer le nom de la clé API

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

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

Dans cet exemple, le paramètre de requête et le nom de l'en-tête sont tous deux remplacés par apiKey. La Le nom x-api-key ne fonctionnera plus ni dans les deux cas. Voir aussi Modifier la configuration

Exemple :

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

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

Activer les codes de réponse en amont

Par défaut, le plug-in oauth ne renvoie que des codes d'état d'erreur 4xx si la réponse n'est pas un code d'état 200. Vous pouvez modifier ce comportement renvoie le code exact 4xx ou 5xx, en fonction de l'erreur.

Pour activer cette fonctionnalité, ajoutez oauth.useUpstreamResponse: true à votre configuration Edge Microgateway. Exemple :

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

Utiliser la sécurité des jetons OAuth2

Cette section explique comment obtenir des jetons d'accès et d'actualisation OAuth2. Les jetons d'accès sont utilisés pour des appels d'API sécurisés via la micropasserelle. Les jetons d'actualisation permettent d'obtenir de nouveaux jetons d'accès.

Comment obtenir un jeton d'accès

Cette section explique comment utiliser le proxy edgemicro-auth pour obtenir un jeton d'accès.

Vous pouvez également obtenir un jeton d'accès à l'aide de la commande CLI edgemicro token. Pour en savoir plus sur la CLI, consultez la page Gérer les jetons.

API 1: Envoyer les identifiants en tant que paramètres du corps

Remplacez le nom de l'organisation et de l'environnement dans l'URL, puis Remplacez les valeurs "Consumer ID" (ID client) et "Consumer Secret" (Code secret client) obtenues à partir d'une application de développement sur Apigee. Edge pour les paramètres de corps client_id et client_secret:

curl -i -X POST "http://<org>-<test>.apigee.net/edgemicro-auth/token" \
-d '{"grant_type": "client_credentials", "client_id": "your_client_id", \
"client_secret": "your_client_secret"}' -H "Content-Type: application/json"

API 2: Envoyer les identifiants dans un en-tête Basic Auth

Envoyez les identifiants client sous la forme d'un en-tête "Basic Authentication" et l'événement grant_type en tant que paramètre de formulaire. Ce formulaire de commande est également abordé dans RFC 6749: Framework d'autorisation OAuth 2.0.

http://<org>-<test>.apigee.net/edgemicro-auth/token -v -u your_client_id:your_client_secret \
-d 'grant_type=client_credentials' -H "Content-Type: application/x-www-form-urlencoded"

Exemple de résultat

L'API renvoie une réponse JSON. Notez qu'il n'existe aucune différence entre token et access_token. Vous pouvez utiliser l'une ou l'autre de ces options. Notez que expires_in est une valeur entière spécifiée en secondes.

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

Obtenir un jeton d'actualisation

Pour obtenir un jeton d'actualisation, effectuez un appel d'API vers le point de terminaison /token du Proxy edgemicro-auth. Vous DEVEZ effectuer cet appel d'API avec l'password type d'octroi. Suivez les étapes ci-dessous pour suivre la procédure.

Obtenez un jeton d'accès et d'actualisation avec l'API /token. Notez que le type d'attribution est password:

curl -X POST \
  https://your_organization-your_environment.apigee.net/edgemicro-auth/token \
  -H 'Content-Type: application/json' \
  -d '{
   "client_id":"mpK6l1Bx9oE5zLdifoDbF931TDnDtLq",
   "client_secret":"bUdDcFgv3nXffnU",
   "grant_type":"password",
   "username":"mpK6lBx9RoE5LiffoDbpF931TDnDtLq",
   "password":"bUdD2FvnMsXffnU"
}'

L'API renvoie un jeton d'accès et un jeton d'actualisation. La réponse est semblable à cette étape. Notez que expires_in prend la valeur des entiers et est exprimé en secondes.

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

Vous pouvez maintenant utiliser le jeton d'actualisation pour obtenir un nouveau jeton d'accès en appelant le point de terminaison /refresh de la même API. Exemple :

curl -X POST \
  https://willwitman-test.apigee.net/edgemicro-auth/refresh \
  -H 'Content-Type: application/json' \
  -d '{
   "client_id":"mpK6l1Bx9RoE5zLifoDbpF931TDnDtLq",
   "client_secret":"bUdDc2Fv3nMXffnU",
   "grant_type":"refresh_token",
   "refresh_token":"your-refresh-token"
}'

L'API renvoie un nouveau jeton d'accès. La réponse est semblable à ceci:

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

Surveillance permanente

Forever est un outil Node.js qui redémarre automatiquement une application Node.js si le processus s'interrompt ou rencontre une erreur. Périphérie Microgateway comporte un fichier forever.json que vous pouvez configurer pour contrôler le nombre et les intervalles de redémarrage d'Edge Microgateway. Ce fichier configure un Service permanent appelé forever-monitor, qui gère Forever de manière programmatique.

Vous pouvez trouver le fichier forever.json dans l'installation racine d'Edge Microgateway . Voir <ph type="x-smartling-placeholder"></ph> Emplacement d'installation d'Edge Microgateway Pour en savoir plus sur les options de configuration, consultez documentation sur l'enregistrement permanent de la surveillance.

La commande edgemicro forever inclut des options qui vous permettent de spécifier l'emplacement le fichier forever.json (option -f), et démarrer/arrêter la surveillance permanente. (l'option -a). Exemple :

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

Pour en savoir plus, consultez la section Surveillance en permanence dans la documentation de référence de la CLI.

Spécifier un point de terminaison de fichier de configuration

Si vous exécutez plusieurs instances Edge Microgateway, vous pouvez gérer leurs configurations à partir d'un même emplacement. Pour ce faire, spécifiez un point de terminaison HTTP à partir duquel Edge Micro peut télécharger son fichier de configuration. Vous pouvez spécifier ce point de terminaison lorsque vous démarrez Edge Micro en utilisant l'indicateur -u.

Exemple :

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

où le point de terminaison mgconfig renvoie le contenu de votre fichier de configuration. Il s'agit du fichier qui, par défaut, se trouve dans ~/.edgemicro et respecte la convention d'attribution de noms suivante: org-env-config.yaml

Désactiver la mise en mémoire tampon des données de connexion TCP

Vous pouvez utiliser l'attribut de configuration nodelay pour désactiver la mise en mémoire tampon des données pour Connexions TCP utilisées par Edge Microgateway.

Par défaut, les connexions TCP utilisent le protocole Nagle algorithme pour mettre en mémoire tampon les données avant de les envoyer. Définir nodelay sur true désactive ce comportement (les données se déclenchent immédiatement socket.write() est appelé). Reportez-vous également à la documentation Node.js dans la documentation.

Pour activer nodelay, modifiez le fichier de configuration Edge Micro comme suit:

edgemicro:
  nodelay: true
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24

Exécuter Edge Microgateway en mode autonome

Vous pouvez exécuter Edge Microgateway sans connexion Dépendance Apigee Edge. Ce scénario, appelé mode autonome, vous permet d'exécuter et de tester Edge Microgateway sans connexion Internet.

En mode autonome, les fonctionnalités suivantes ne fonctionnent pas, car elles nécessitent une connexion vers Apigee Edge:

OAuth et clé API
Quota
Analyse

En revanche, les plug-ins personnalisés et la fonctionnalité d'arrêt des pics fonctionnent normalement, nécessitent une connexion à Apigee Edge. De plus, un nouveau plug-in appelé extauth vous permet autoriser les appels d'API vers la micropasserelle avec un jeton JWT en mode autonome ;

Configurer et démarrer la passerelle

Pour exécuter Edge Microgateway en mode autonome:

Créez un fichier de configuration nommé comme suit: $HOME/.edgemicro/$ORG-$ENV-config.yaml
Vous pouvez utiliser toutes les valeurs de votre choix pour $ORG et $ENV dans le nom de fichier. La combinaison org/env est simplement une convention qui permet à Edge Microgateway de trouver le fichier il démarre.

Exemple :
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
Collez le code suivant dans le fichier :
```
edgemicro:
  port: 8000
  max_connections: 1000
  config_change_poll_interval: 600
  logging:
    level: error
    dir: /var/tmp
    stats_log_interval: 60
    rotate_interval: 24
  plugins:
    sequence:
      - extauth
      - spikearrest
headers:
  x-forwarded-for: true
  x-forwarded-host: true
  x-request-id: true
  x-response-time: true
  via: true
extauth:
  publickey_url: https://www.googleapis.com/oauth2/v1/certs
spikearrest:
  timeUnit: second
  allow: 10
  buffersize: 0
```
Le fichier de configuration contient un plug-in spécial et facultatif appelé extauth. Ce plug-in vérifie un jeton JWT valide transmis à la micropasserelle. Dans une étape ultérieure, vous apprendrez à obtenir et utiliser le jeton. Notez également que le plug-in spikearrest est inclus car il ne repose pas sur la connectivité avec Edge. quota Les plug-ins oauth et analytics sont exclus, car ils reposent sur la connectivité avec Edge et ne fonctionne pas en mode déconnecté. Les plug-ins personnalisés sont autorisés et fonctionneront comme prévu.
Exportez la variable d'environnement suivante avec la valeur "1" :
```
export EDGEMICRO_LOCAL=1
```
Exécutez la commande start suivante, dans laquelle vous indiquez les valeurs à instancier proxy local:
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
Où :
- $ORG correspond à "l'organisation" que vous avez utilisé dans le nom du fichier de configuration.
- $ENV correspond à l'environnement "env". que vous avez utilisé dans le fichier de configuration son nom.
- $LOCAL_PROXY_NAME est le nom du proxy local qui sera créé. Vous pouvez utiliser le nom de votre choix.
- $LOCAL_PROXY_VERSION est le numéro de version du proxy.
- $TARGET_URL est l'URL de la cible du proxy. (La cible est la que le proxy appelle.)
- $BASE_PATH est le chemin de base du proxy. Cette valeur doit commencer par un préfixe . Pour un chemin d'accès de base racine, spécifiez simplement une barre oblique ; Exemple : "/".
Exemple :
```
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Tester la configuration
```
curl http://localhost:8000/echo  { "error" : "missing_authorization" }
```
Comme le plug-in extauth se trouve dans le fichier foo-bar-config.yaml, vous obtenir une autorisation "missing_permission" . Ce plug-in valide un jeton JWT qui doit être présent dans l'autorisation de l'appel d'API. Dans la section suivante, vous allez obtenir un jeton JWT qui permettra les appels d'API sans l'erreur.

Exemple: Obtenir un jeton d'autorisation

L'exemple suivant montre comment obtenir un jeton JWT à partir du point de terminaison JWT Edge Microgateway sur Apigee Edge (edgemicro-auth/jwkPublicKeys). Ce point de terminaison est déployé lorsque vous effectuez une configuration et une configuration standards d'Edge Microgateway. Pour obtenir le jeton JWT à partir du point de terminaison Apigee, vous devez d'abord configurer Edge Microgateway standard, puis être connecté à Internet. Le point de terminaison Apigee est utilisé ici à des fins d'exemple et n'est pas obligatoire. Si vous le souhaitez, vous pouvez utiliser un autre point de terminaison de jeton JWT. Dans ce cas, vous devez obtenir le jeton JWT l'API fournie pour ce point de terminaison.

L'inclusion du plug-in extauth dans la configuration de votre micropasserelle est facultative, mais si vous l'inclure, vous devrez afin de fournir un jeton JWT valide dans l'en-tête Authorization pour les appels d'API.

Les étapes suivantes expliquent comment obtenir un jeton à l'aide du point de terminaison edgemicro-auth/jwkPublicKeys :

Vous devez effectuer une opération standard installation et configuration d'Edge Microgateway pour déployer le proxy edgemicro-auth à votre organisation/environnement sur Apigee Edge. Si vous avez déjà effectué cette étape, vous n'avez pas besoin de la répéter.
Si vous avez déployé Edge Microgateway vers Apigee Cloud, vous devez être connecté à Internet pour pouvoir obtenir un jeton JWT à partir de ce point de terminaison.
Arrêtez Edge Microgateway:
```
edgemicro stop
```
Dans le fichier de configuration que vous avez créé précédemment ($HOME/.edgemicro/org-env-config.yaml), pointer vers extauth:publickey_url au point de terminaison edgemicro-auth/jwkPublicKeys de votre organisation/environnement Apigee Edge. Exemple :
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
Redémarrez Edge Microgateway comme précédemment, en utilisant les noms org/env que vous avez utilisés dans le nom du fichier de configuration. Exemple :
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
Obtenez un jeton JWT à partir du point de terminaison d'autorisation. Parce que vous utilisez edgemicro-auth/jwkPublicKeys vous pouvez utiliser la commande CLI suivante:
Cette étape nécessite une connexion Internet. La commande suivante récupère un jeton d'Apigee Edge. Pour effectuer cette étape, vous devez disposer d'une organisation Apigee dans laquelle vous avez effectué une configuration et une configuration Edge Microgateway standards. Une fois cette étape effectuée, vous n'avez pas besoin d'être connecté à à Internet. Le jeton continuera de fonctionner en mode autonome jusqu'à son expiration.

Vous pouvez générer un jeton JWT pour Edge Microgateway à l'aide de la commande edgemicro token ou une API. Exemple :

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

Où :

your_org est le nom de l'organisation Apigee pour laquelle vous avez précédemment configuré Edge Microgateway.
your_env est un environnement de l'organisation.
L'option i spécifie la clé client d'une application de développement contenant un produit. qui inclut le proxy edgemicro-auth.
L'option s spécifie le code secret client d'une application de développement ayant un produit qui inclut le proxy edgemicro-auth.

Cette commande demande à Apigee Edge de générer un JWT qui peut ensuite être utilisé pour vérifier l'API appels.

Consultez également Générer un jeton.

Tester la configuration autonome

Pour tester la configuration, appelez l'API avec le jeton ajouté dans l'en-tête "Authorization", comme suit:

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

Exemple :

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

Exemple de résultat :

{
   "headers":{
      "user-agent":"curl/7.54.0",
      "accept":"*/*",
      "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
      "client_received_start_timestamp":"1535134472699",
      "x-authorization-claims":"eyJhdDbiO...M1OTE5MTA1NDkifQ==",
      "target_sent_start_timestamp":"1535134472702",
      "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
      "x-forwarded-proto":"http",
      "x-forwarded-host":"localhost:8000",
      "host":"mocktarget.apigee.net",
      "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
      "via":"1.1 localhost, 1.1 google",
      "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
      "connection":"Keep-Alive"
   },
   "method":"GET",
   "url":"/",
   "body":""
}

Utiliser le mode proxy local

En mode proxy local, Edge Microgateway ne nécessite pas Proxy compatible avec les micro-passerelles à déployer sur Apigee Edge. À la place, vous configurez un "proxy local" en fournissant un nom de proxy local, un chemin de base et une URL cible lorsque vous démarrer la micropasserelle. Les appels d'API à la micropasserelle sont ensuite envoyés URL du proxy local. À tous les autres égards, le mode proxy local fonctionne exactement de la même manière que l'exécution Edge Microgateway en mode normal. L'authentification fonctionne de la même manière l'application des quotas, les plug-ins personnalisés, etc.

Les deux principales différences entre le mode local et la passerelle Edge Microgateway standard (1) En mode local, vous n'avez pas besoin de créer une passerelle compatible avec les micropasserelles sur Apigee Edge et (2) lorsque vous créez un produit d'API sur Edge, vous ne devez lui ajouter qu'un seul proxy, au proxy edgemicro-auth. Vous n'avez pas besoin d'ajouter d'autres proxys au produit.

Cas d'utilisation et exemple

Le mode proxy local est utile lorsque vous n'avez besoin d'associer qu'un seul proxy à une Edge Microgateway Compute Engine. Par exemple, vous pouvez injecter Edge Microgateway dans Kubernetes en tant que proxy side-car, où un microgateway et un service s'exécutent chacun dans un pod unique, et où la microgateway gère le trafic et de son service associé. La figure suivante illustre cette architecture dans laquelle Edge Microgateway fonctionne comme un proxy side-car dans un cluster Kubernetes. Chaque instance de micropasserelle communique vers un seul point de terminaison sur son service associé:

Edgemicro en tant que side-car

L'avantage de ce style d'architecture est qu'Edge Microgateway fournit des API des services individuels déployés dans un environnement de conteneurs, un cluster Kubernetes.

Configurer le mode proxy local

Pour configurer Edge Microgateway afin qu'il s'exécute en mode proxy local, procédez comme suit:

Exécutez edgemicro init pour configurer votre environnement de configuration local exactement comme vous le feriez dans une configuration Edge Microgateway classique. Voir aussi Configurez Edge Microgateway.
Exécutez edgemicro configure, comme vous le feriez dans une configuration Edge Microgateway classique. procédure. Exemple :
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
Cette commande déploie la règle edgemicro-auth sur Edge et renvoie une clé dont vous aurez besoin pour démarrer la micropasserelle. Si vous avez besoin d'aide, consultez Configurez Edge Microgateway.
Sur Apigee Edge, créez un produit d'API avec la configuration obligatoire suivante : (vous pouvez gérer toutes les autres configurations à votre guise): <ph type="x-smartling-placeholder">
- Vous devez ajouter le proxy edgemicro-auth au produit. Ce proxy a été déployé automatiquement lors de l'exécution de edgemicro configure.
- Vous devez fournir un chemin d'accès à la ressource. Apigee recommande d'ajouter ce chemin le produit: /**. Pour en savoir plus, consultez la section Configurer le comportement du chemin d'accès à la ressource. Voir aussi Créer une API produits dans la documentation Edge.
Sur Apigee Edge, créez un développeur, ou faites appel à un développeur existant si vous souhaiter. Pour obtenir de l'aide, consultez Ajouter des développeurs à l'aide de l'interface utilisateur de gestion Edge.
Sur Apigee Edge, créez une application de développement. Vous devez ajouter le produit API que vous que vous venez de créer dans l'application. Pour obtenir de l'aide, consultez la section Enregistrement d'une application dans Edge de gestion centralisée.
Sur la machine sur laquelle Edge Microgateway est installé, exportez les éléments suivants : avec la valeur "1".
```
export EDGEMICRO_LOCAL_PROXY=1
```
Exécutez la commande start suivante :
```
edgemicro start -o your_org -e your_environment -k your_key -s your_secret \
    -a local_proxy_name -v local_proxy_version -t target_url -b base_path
```
Où :
- your_org est votre organisation Apigee.
- your_environment est un environnement de votre organisation.
- your_key est la clé qui a été renvoyée lors de l'exécution edgemicro configure
- your_secret est le secret qui a été renvoyé lors de l'exécution edgemicro configure
- local_proxy_name est le nom du proxy local qui sera créé.
- local_proxy_version est le numéro de version du proxy.
- target_url est l'URL de la cible du proxy (le service auquel le proxy appel).
- base_path est le chemin de base du proxy. Cette valeur doit commencer par un préfixe . Pour un chemin d'accès de base racine, spécifiez simplement une barre oblique ; Exemple : "/".
Exemple :
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

Tester la configuration

Vous pouvez tester la configuration locale du proxy en appelant le point de terminaison du proxy. Par exemple : Si vous avez spécifié le chemin de base /echo, vous pouvez appeler le proxy comme suit:

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

Ce premier appel d'API a généré une erreur, car vous n'avez pas fourni de clé API valide. Vous trouverez la clé dans l'application de développement que vous avez créée précédemment. Ouvrez l'application dans l'interface utilisateur Edge, copiez la clé client, puis utilisez-la comme suit:

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

Exemple :

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

Exemple de résultat :

{
  "headers":{
    "user-agent":"curl/7.54.0",
    "accept":"*/*",
    "x-api-key":"DvUdLlFwG9AvGGpEgfnNGwtvaXIlUUvP",
    "client_received_start_timestamp":"1535134472699",
    "x-authorization-claims":"eyJhdWQiOi...TQ0YmUtOWNlOS05YzM1OTE5MTA1NDkifQ==",
    "target_sent_start_timestamp":"1535134472702",
    "x-request-id":"678e3080-a7ae-11e8-a70f-87ae30db3896.8cc81cb0-a7c9-11e8-a70f-87ae30db3896",
    "x-forwarded-proto":"http",
    "x-forwarded-host":"localhost:8000",
    "host":"mocktarget.apigee.net",
    "x-cloud-trace-context":"e2ac4fa0112c2d76237e5473714f1c85/1746478453618419513",
    "via":"1.1 localhost, 1.1 google",
    "x-forwarded-for":"::1, 216.98.205.223, 35.227.194.212",
    "connection":"Keep-Alive"
  },
  "method":"GET",
  "url":"/",
  "body":""
}

Utiliser le synchronisateur

Cette section explique comment utiliser le synchronisateur, une fonctionnalité facultative améliore la résilience d'Edge Microgteway en lui permettant pour récupérer les données de configuration d'Apigee Edge et les écrire dans une base de données Redis locale. Avec Une instance de synchroniseur en cours d'exécution, les autres instances Edge Microgateway s'exécutant sur différents nœuds peuvent récupérer leur configuration directement dans cette base de données.

La fonctionnalité de synchronisation est actuellement compatible avec Redis 5.0.x.

Qu'est-ce que le synchronisateur ?

Le synchronisateur offre un certain niveau de résilience à Edge Microgateway. Cela permet de garantir que chaque instance d'Edge Microgateway utilise la même configuration, et que En cas de perturbation sur Internet, les instances Edge Microgateway peuvent démarrer et s'exécuter. correctement.

Par défaut, les instances Edge Microgateway doivent pouvoir communiquer avec Apigee Edge pour récupérer et actualiser leurs données de configuration, telles que les configurations du proxy API et des produits d'API. Si la connexion Internet avec Edge est interrompue, les instances de microgateway peuvent continuer à car les dernières données de configuration sont mises en cache. Cependant, les nouvelles instances de microgateway ne peut pas démarrer sans une connexion claire. De plus, une connexion Internet toute interruption pour qu'une ou plusieurs instances de micro-passerelle s'exécutent avec les paramètres des informations non synchronisées avec d'autres instances.

Le synchronisateur Edge Microgateway offre un mécanisme alternatif pour Edge Microgateway instances pour récupérer les données de configuration dont elles ont besoin pour démarrer et traiter le trafic proxy API. Les données de configuration récupérées à partir des appels à Apigee Edge incluent: l'appel jwk_public_keys, l'appel jwt_public_key, l'appel d'amorçage et l'appel de produits d'API. Le synchronisateur permet de gérer l'ensemble instances s'exécutant sur des nœuds différents afin qu'elles démarrent correctement et restent synchronisées la connexion Internet entre Edge Microgateway et Apigee Edge est interrompue.

Le synchroniseur est une instance spécialement configurée d'Edge Microgateway. Son seul objectif consiste à interroger Apigee Edge (le délai est configurable), à récupérer les données de configuration et l'écrire dans une base de données Redis locale. L'instance de synchronisation ne peut pas traiter le proxy d'API du trafic. D'autres instances d'Edge Microgateway s'exécutant sur différents nœuds peuvent être configuré pour récupérer les données de configuration à partir de la base de données Redis plutôt que d'Apigee Périphérie. Comme toutes les instances microgateway récupèrent leurs données de configuration base de données, ils peuvent démarrer et traiter des requêtes API, même dans le cas perturbation de la sécurité.

Configurer une instance de synchronisateur

Ajoutez la configuration suivante au fichier org-env/config.yaml pour l'installation d'Edge Microgateway que vous souhaitez utiliser comme synchronisateur:

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

Exemple :

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

Option	Description
`redisHost`	Hôte sur lequel votre instance Redis est exécutée. Par défaut: 127.0.0.1
`redisPort`	Port de l'instance Redis. Par défaut: 6379
`redisDb`	Base de données Redis à utiliser. Valeur par défaut : 0
`redisPassword`	Mot de passe de votre base de données.

Vous pouvez utiliser la variable d'environnement EDGEMICRO_REDIS_PASSWORD pour remplacer le paramètre edgemicro.redisPassword. Consultez également la section Définir des attributs de configuration avec des valeurs de variables d'environnement

Enfin, enregistrez le fichier de configuration et démarrez l'instance Edge Microgateway. Elle va commencer. d'interroger Apigee Edge et de stocker les données de configuration téléchargées dans la base de données Redis.

Configurer des instances Edge Microgateway standards

Lorsque le synchronisateur est en cours d'exécution, vous pouvez configurer des nœuds Edge Microgateway supplémentaires pour exécuter des instances de micropasserelle standards qui traitent le trafic proxy API. Cependant, vous configurez ces instances d'obtenir leurs données de configuration à partir de la base de données Redis plutôt que de Apigee Edge.

Ajoutez la configuration suivante à chaque nœud Edge Microgateway supplémentaire org-env/config.yaml. Notez que synchronizerMode est définie sur 0. Cette propriété définit l'instance pour qu'elle fonctionne d'instance Edge Microgateway qui traite le trafic de proxy API, et l'instance obtient ses données de configuration à partir de la base de données Redis.

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

Exemple :

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

Propriétés de configuration

Les propriétés de configuration suivantes ont été ajoutées pour permettre l'utilisation du synchronisateur:

Attribut Valeurs Description

Attribut	Valeurs	Description
`edge_config.synchronizerMode`	0 ou 1	Si 0 (valeur par défaut), Edge Microgateway fonctionne en mode standard. Si la valeur est 1, démarrez l'instance Edge Microgateway pour qu'elle fonctionne comme un synchronisateur. Dans ce l'instance extrait les données de configuration d'Apigee Edge et les stocke une base de données Redis locale. Cette instance n'est pas en mesure de traiter les requêtes de proxy d'API. son Son seul but est d'interroger Apigee Edge pour récupérer les données de configuration et de les écrire base de données. Vous devez ensuite configurer d'autres instances de microgateway afin qu'elles lisent les données de la base de données.
`edge_config.redisBasedConfigCache`	True ou False	Si la valeur est "true", l'instance Edge Microgateway récupère ses données de configuration à partir du Redis au lieu d'Apigee Edge. La base de données Redis doit être la même dans lequel le synchronisateur est configuré pour écrire. Si la base de données Redis est indisponible ou Si la base de données est vide, la microgateway recherche un `cache-config.yaml` existant pour sa configuration. Si la valeur est "false" (valeur par défaut), l'instance Edge Microgateway récupère les données de configuration à partir de Apigee Edge comme d'habitude.
`edgemicro.config_change_poll_interval`	Intervalle de temps, en secondes	Spécifie l'intervalle d'interrogation du synchronisateur pour extraire les données d'Apigee Edge.

edge_config.synchronizerMode

0 ou 1

Si 0 (valeur par défaut), Edge Microgateway fonctionne en mode standard.

Si la valeur est 1, démarrez l'instance Edge Microgateway pour qu'elle fonctionne comme un synchronisateur. Dans ce l'instance extrait les données de configuration d'Apigee Edge et les stocke une base de données Redis locale. Cette instance n'est pas en mesure de traiter les requêtes de proxy d'API. son Son seul but est d'interroger Apigee Edge pour récupérer les données de configuration et de les écrire base de données. Vous devez ensuite configurer d'autres instances de microgateway afin qu'elles lisent les données de la base de données.

edge_config.redisBasedConfigCache

True ou False

Si la valeur est "true", l'instance Edge Microgateway récupère ses données de configuration à partir du Redis au lieu d'Apigee Edge. La base de données Redis doit être la même dans lequel le synchronisateur est configuré pour écrire. Si la base de données Redis est indisponible ou Si la base de données est vide, la microgateway recherche un cache-config.yaml existant pour sa configuration.

Si la valeur est "false" (valeur par défaut), l'instance Edge Microgateway récupère les données de configuration à partir de Apigee Edge comme d'habitude.

edgemicro.config_change_poll_interval Intervalle de temps, en secondes Spécifie l'intervalle d'interrogation du synchronisateur pour extraire les données d'Apigee Edge.

Configurer des URL d'exclusion pour les plug-ins

Vous pouvez configurer la microgateway afin d'ignorer le traitement des plug-ins pour certaines URL. Vous pouvez configurer ces options "exclure" URL globales (pour tous les plug-ins) ou pour des plug-ins spécifiques.

Exemple :

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

Dans cet exemple, les plug-ins ne traitent pas les appels de proxy d'API entrants avec chemins /hello ou /proxy_one. De plus, le json2xml Le plug-in sera ignoré pour les API dont le chemin contient /hello/xml.

Vous ne pouvez pas exclure le plug-in analytics.

Définir des attributs de configuration avec des valeurs de variables d'environnement

Vous pouvez spécifier des variables d'environnement à l'aide de balises dans le fichier de configuration . Les tags de variables d'environnement spécifiés sont remplacés par les tags d'environnement réels variables. Les remplacements ne sont stockés qu'en mémoire et ne sont pas stockés dans l'original de configuration ou de cache.

Remarque : Par défaut, la balise <E> analyse les valeurs des variables. sous forme de chaînes. Pour spécifier des valeurs entières et booléennes positives, utilisez la fonction Balises <n> et <b> comme illustré dans les exemples ci-dessous.

Dans cet exemple, l'attribut key est remplacé par la valeur de l'attribut TARGETS_SSL_CLIENT_KEY, etc.

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

Dans cet exemple, la balise <n> est utilisée pour indiquer une valeur entière. Uniquement les valeurs positives Les nombres entiers sont acceptés.

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

Dans cet exemple, la balise <b> indique une valeur booléenne ( c'est-à-dire vrai ou "false").

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