Edge Microgateway の操作と構成のリファレンス

現在、Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントをご確認ください。 情報

Edge Microgateway バージョン 2.4.x

概要

このトピックでは、モニタリング、ロギング、デバッグなど、Edge Microgateway を管理および構成する方法について説明します。

構成の変更

知っておくべき構成ファイルは次のとおりです。

  • デフォルトのシステム構成ファイル
  • 新しく初期化された Edge Microgateway インスタンスのデフォルト構成ファイル
  • 実行中のインスタンスの動的構成ファイル

このセクションでは、これらのファイルと、その変更について知っておくべきことについて説明します。構成ファイルの設定の詳細については、Edge Microgateway 構成リファレンスをご覧ください。

デフォルトのシステム構成ファイル

Edge Microgateway をインストールすると、デフォルトのシステム構成ファイルが次の場所に配置されます。

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

ここで、[prefix] は npm 接頭辞ディレクトリです。Edge Microgateway のインストール場所をご覧ください。

システム構成ファイルを変更する場合は、Edge Microgateway を再初期化、再構成、再起動する必要があります。

  1. edgemicro init に電話
  2. edgemicro configure [params] に電話
  3. edgemicro start [params] に電話

新しく初期化された Edge Microgateway インスタンスのデフォルト構成ファイル

edgemicro init を実行すると、システム構成ファイル（上記の説明） default.yaml が ~/.edgemicro ディレクトリに配置されます。

~/.edgemicro の構成ファイルを変更する場合は、Edge Microgateway を再構成して再起動する必要があります。

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

実行中のインスタンスの動的構成ファイル

edgemicro configure [params] を実行すると、~/.edgemicro 内に動的構成ファイルが作成されます。ファイル名は [org]-[env]-config.yaml というパターンで決まります。ここで、org と env は Apigee Edge の組織名と環境名です。このファイルを使用して構成を変更し、ダウンタイムなしで再読み込みできます。たとえば、プラグインを追加して構成する場合、下記で説明するように、ダウンタイムを発生させずに構成を再読み込みできます。

Edge Microgateway が実行されている場合（ゼロ ダウンタイム オプション）:

  1. Edge Microgateway 構成を再読み込みします。 
    edgemicro reload -o [org] -e [env] -k [key] -s [secret]

    ここで

    • org は Edge 組織名です（組織管理者である必要があります）。
    • env は組織の環境です（テスト環境や本番環境など）。
    • key は、以前に Configure コマンドで返された鍵です。
    • secret は、以前に Configure コマンドで返された鍵です。

    例

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

Edge Microgateway が停止している場合:

  1. Edge Microgateway を再起動します。 
    edgemicro start -o [org] -e [env] -k [key] -s [secret]

    ここで

    • org は Edge 組織名です（組織管理者である必要があります）。
    • env は組織の環境です（テスト環境や本番環境など）。
    • key は、以前に Configure コマンドで返された鍵です。
    • secret は、以前に Configure コマンドで返された鍵です。

    例

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

以下に構成ファイルの例を示します。構成ファイルの設定の詳細については、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

環境変数を設定する

Edge の組織と環境の値、および Edge Microgateway の起動に必要な鍵とシークレットを必要とするコマンドライン インターフェース コマンドは、次の環境変数に格納できます。

  • EDGEMICRO_ORG
  • EDGEMICRO_ENV
  • EDGEMICRO_KEY
  • EDGEMICRO_SECRET

これらの変数の設定は省略可能です。これらを設定すると、コマンドライン インターフェース（CLI）を使用して Edge Microgateway を構成して起動する際に、値を指定する必要はありません。

Edge Microgateway サーバーで SSL を構成する

SSL を使用するように Microgateway サーバーを構成できます。たとえば、SSL が構成されている場合、次のように「https」プロトコルを使用して Edge Microgateway から API を呼び出すことができます。

https://localhost:8000/myapi

Microgateway サーバーで SSL を構成する手順は次のとおりです。

  1. openssl ユーティリティまたは任意の方法で、SSL 証明書と鍵を生成または取得します。
  2. Edge Microgateway 構成ファイルに edgemicro:ssl 属性を追加します。オプションの一覧については、以下の表をご覧ください。Edge Microgateway 構成の変更の詳細については、構成の変更をご覧ください。次に例を示します。
     edgemicro:
     ssl:
         key: <absolute path to the SSL key file>
         cert: <absolute path to the SSL cert file>
         passphrase: admin123 #option added in v2.2.2
         rejectUnauthorized: true #option added in v2.2.2
         requestCert: true
  3. Edge Microgateway を再起動します。編集した構成ファイル（デフォルト ファイルまたはランタイム構成ファイル）に応じて、構成の変更で説明されている手順を行います。

SSL を構成した構成ファイルの edgemicro セクションの例を次に示します。

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

サポートされているすべてのサーバー オプションは次のとおりです。

オプション 説明
key ca.key ファイルのパス（PEM 形式）。
cert ca.cert ファイルのパス（PEM 形式）。
pfx クライアントの秘密鍵、証明書、PFX 形式の CA 証明書を含む pfx ファイルのパス。
passphrase 秘密鍵または PFX のパスフレーズを含む文字列。
ca 信頼できる PEM 形式の証明書のリストを含むファイルのパス。
ciphers 使用する暗号を記述した文字列を「:」で区切って指定します。
rejectUnauthorized true の場合、サーバー証明書は指定された CA のリストと照らし合わせて検証されます。検証が失敗した場合は、エラーが返されます。
secureProtocol 使用する SSL メソッド。たとえば、SSL をバージョン 3 に強制するには、「SSLv3_method」と入力します。
servername SNI（Server Name Indication）TLS 拡張機能のサーバー名。
requestCert 双方向 SSL の場合は true、一方向 SSL の場合は false

クライアント SSL/TLS オプションの使用

ターゲット エンドポイントに接続するときに、Edge Microgateway を TLS または SSL クライアントとして構成できます。Microgateway 構成ファイルで、targets 要素を使用して SSL/TLS オプションを設定します。

この例では、すべてのホストに適用される設定を示します。

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

この例では、設定は指定したホストにのみ適用されます。

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

TLS の例を次に示します。

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

サポートされているすべてのクライアント オプションは次のとおりです。

オプション 説明
pfx クライアントの秘密鍵、証明書、PFX 形式の CA 証明書を含む pfx ファイルのパス。
key ca.key ファイルのパス（PEM 形式）。
passphrase 秘密鍵または PFX のパスフレーズを含む文字列。
cert ca.cert ファイルのパス（PEM 形式）。
ca 信頼できる PEM 形式の証明書のリストを含むファイルのパス。
ciphers 使用する暗号を記述した文字列を「:」で区切って指定します。
rejectUnauthorized true の場合、サーバー証明書は指定された CA のリストと照らし合わせて検証されます。検証が失敗した場合は、エラーが返されます。
secureProtocol 使用する SSL メソッド。たとえば、SSL をバージョン 3 に強制するには、「SSLv3_method」と入力します。
servername SNI（Server Name Indication）TLS 拡張機能のサーバー名。

edgemicro-auth プロキシのカスタマイズ

デフォルトでは、Edge Microgateway は Apigee Edge にデプロイされたプロキシを OAuth2 認証に使用します。 このプロキシは、最初に edgemicro configure を実行したときにデプロイされます。このプロキシのデフォルト構成を変更して、JSON Web Token（JWT）にカスタム クレームのサポートを追加し、トークンの有効期限を構成して更新トークンを生成できます。詳細については、GitHub の edgemicro-auth ページをご覧ください。

カスタム認証サービスの使用

デフォルトでは、Edge Microgateway は Apigee Edge にデプロイされたプロキシを OAuth2 認証に使用します。 このプロキシは、最初に edgemicro configure を実行したときにデプロイされます。デフォルトでは、このプロキシの URL は Edge Microgateway 構成ファイルで次のように指定されています。

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

独自のカスタム サービスを使用して認証を処理する場合は、サービスを指すように構成ファイルの authUri 値を変更します。たとえば、LDAP を使用して本人確認を行うサービスがあるとします。

ログファイルの管理

Edge Microgateway により、各リクエストとレスポンスに関する情報がログに記録されます。ログファイルは、デバッグとトラブルシューティングに役立つ情報を提供します。

ログファイルの保存場所

デフォルトでは、ログファイルは /var/tmp に保存されます。

デフォルトのログファイル ディレクトリを変更する方法

ログファイルが保存されるディレクトリは、Edge Microgateway 構成ファイルで指定します。構成の変更の詳細については、構成の変更をご覧ください。

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

dir の値を変更して、別のログファイル ディレクトリを指定します。

コンソールにログを送信する

ログ情報がログファイルではなく標準出力に送信されるように、ロギングを構成できます。次のように to_console フラグを true に設定します。

edgemicro:
  logging:
    to_console: true

この設定では、ログは標準出力に送信されます。現時点では、stdout とログファイルの両方にログを送信することはできません。

ロギングレベルを設定する方法

ログレベルは、info、warn、error に設定できます。info レベルは推奨です。デフォルトで、すべての API リクエストとレスポンスがログに記録されます。

ログ間隔を変更する方法

これらの間隔は Edge Microgateway 構成ファイルで構成できます。構成の変更の詳細については、構成の変更をご覧ください。

構成可能な属性は次のとおりです。

  • stats_log_interval: （デフォルト: 60）統計情報レコードが API ログファイルに書き込まれる間隔（秒単位）。
  • rotate_interval: （デフォルト: 24）ログファイルをローテーションする間隔（時間単位）。例:
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

注: アーカイブされたログファイルは圧縮されません。間隔が開始されると、新しいタイムスタンプで新しいログファイルが作成されます。

ログファイルのメンテナンスのおすすめの方法

ログファイルデータは時間の経過とともに蓄積されるため、次の方法を採用することをおすすめします。

  • ログファイルは非常に大きくなる可能性があるため、ログファイル ディレクトリに十分な空き容量があることを確認してください。以降のログファイルの保存場所とデフォルトのログファイル ディレクトリを変更する方法をご覧ください。
  • 少なくとも 1 週間に 1 回、ログファイルを削除するか、別のアーカイブ ディレクトリに移動してください。
  • ポリシーでログを削除する場合は、CLI コマンド edgemicro log -c を使用して古いログを削除（クリーンアップ）できます。

ログファイルの命名規則

各 Edge Microgateway インスタンスは、3 種類のログファイルを生成します。

  • api - Edge Microgateway を通過するすべてのリクエストとレスポンスをログに記録します。API カウンタ（統計情報）とエラーもこのファイルに記録されます。
  • err - stderr に送信されたすべてのものを記録します。
  • out - stdout に送信されたものをすべてログに記録します。

命名規則は次のとおりです。

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

例:

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

ログファイルの内容について

v2.3.3 で追加

デフォルトでは、このロギング サービスは、ダウンロードされたプロキシ、プロダクト、JSON Web Token（JWT）の JSON を省略します。これらのオブジェクトをログファイルに出力する場合は、Edge Microgateway を起動するときに DEBUG=* を設定します。例:

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

注: Windows の場合は、SET DEBUG=* を使用してください。

「api」ログファイルの内容

「api」ログファイルには、Edge Microgateway を介したリクエストとレスポンスのフローに関する詳細情報が含まれています。「api」ログファイルの名前は次のようになります。

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Edge Microgateway に対するリクエストごとに、4 つのイベントが「api」ログファイルにキャプチャされます。

  • クライアントからの受信リクエスト
  • ターゲットへの送信リクエスト
  • ターゲットからの受信レスポンス
  • クライアントへの発信レスポンス

ログファイルをよりコンパクトにするため、これらの個別のエントリは省略表記で表されます。ここでは、4 つのイベントのそれぞれを表す 4 つのサンプル エントリを示します。ログファイルには、次のようになります（行番号はドキュメント内での参照用であり、ログファイルには含まれていません）。

(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

1 つずつ見ていきましょう。

1. クライアントからの受信リクエストの例:

1436403888651 info req m=GET, u=/, h=localhost:8000, r=::1:59715, i=0
  • 1436403888651 - Unix 日付スタンプ
  • info - コンテキストによって異なります。ログレベルに応じて、info、warn、error のいずれかになります。統計情報レコードの場合は統計情報、警告の警告、エラーの場合はエラーになります。
  • req - イベントを識別します。この場合はクライアントからのリクエストです。
  • m - リクエストで使用される HTTP 動詞。
  • u - URL のベースパスに続く部分。
  • h - Edge Microgateway がリッスンしているホストとポート番号。
  • r - クライアント リクエスト送信元のリモートホストとポート。
  • i - リクエスト ID。4 つのイベント エントリすべてでこの ID を共有します。各リクエストには一意のリクエスト ID が割り当てられます。ログレコードをリクエスト ID と関連付けることで、ターゲットのレイテンシに関する有益な情報を得ることができます。
  • d - Edge Microgateway がリクエストを受信してからの期間（ミリ秒）。上記の例では、リクエスト 0 に対するターゲットのレスポンスは 7 ミリ秒後に受信され（3 行目）、さらに 4 ミリ秒後にレスポンスがクライアントに送信されました（4 行目）。つまり、リクエスト レイテンシの合計は 11 ミリ秒で、このうち 7 ミリ秒はターゲットで、4 ミリ秒は Edge Microgateway 自体で使用されました。

2. ターゲットに対する送信リクエストのサンプル:

1436403888665 info treq m=GET, u=/, h=127.0.0.1:8080, i=0
  • 1436403888651 - Unix 日付スタンプ
  • info - コンテキストによって異なります。ログレベルに応じて、info、warn、error のいずれかになります。統計情報レコードの場合は統計情報、警告の警告、エラーの場合はエラーになります。
  • treq - イベントを識別します。ここでは、ターゲット リクエストです。
  • m - ターゲット リクエストで使用される HTTP 動詞。
  • u - URL のベースパスに続く部分。
  • h - バックエンド ターゲットのホストとポート番号。
  • i - ログエントリの ID。4 つのイベント エントリすべてでこの ID を共有します。

3. ターゲットからの受信レスポンスのサンプル

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

1436403888651 - Unix 日付スタンプ

  • info - コンテキストによって異なります。ログレベルに応じて、info、warn、error のいずれかになります。統計情報レコードの場合は統計情報、警告の警告、エラーの場合はエラーになります。
  • tres - イベントを識別します。この場合、目標回答数を指定します。
  • s - HTTP レスポンス ステータス。
  • d - 期間（ミリ秒単位）。ターゲットによる API 呼び出しにかかった時間。
  • i - ログエントリの ID。4 つのイベント エントリすべてでこの ID を共有します。

4. クライアントへの送信レスポンスのサンプル

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

1436403888651 - Unix 日付スタンプ

  • info - コンテキストによって異なります。ログレベルに応じて、info、warn、error のいずれかになります。統計情報レコードの場合は統計情報、警告の警告、エラーの場合はエラーになります。
  • res - イベントを識別します。この場合、クライアントへのレスポンス。
  • s - HTTP レスポンス ステータス。
  • d - 期間（ミリ秒単位）。これは、ターゲット API にかかった時間と Edge Microgateway 自体でかかった時間を含む、API 呼び出しにかかった合計時間です。
  • i - ログエントリの ID。4 つのイベント エントリすべてでこの ID を共有します。

ログファイルのスケジュール

ログファイルは、rotate_interval 構成属性で指定された間隔でローテーションされます。ローテーション間隔が終了するまで、エントリは同じログファイルに継続的に追加されます。ただし、Edge Microgateway が再起動されるたびに、新しい UID を受け取り、この UID を使用して新しいログファイルのセットを作成します。ログファイルの適切なメンテナンス方法もご覧ください。

Edge Microgateway 構成リファレンス

構成ファイルの場所

このセクションで説明する構成属性は、Edge Microgateway 構成ファイルにあります。構成の変更の詳細については、構成の変更をご覧ください。

edge_config 属性

これらの設定は、Edge Microgateway インスタンスと Apigee Edge の間のインタラクションを構成するために使用されます。

  • bootstrap: （デフォルト: なし）Apigee Edge で実行されている Edge Microgateway 固有のサービスを指す URL。Edge Microgateway は、このサービスを使用して Apigee Edge と通信します。公開鍵/秘密鍵のペアを生成するコマンド edgemicro genkeys を実行すると、この URL が返されます。詳細については、Edge Microgateway の設定と構成をご覧ください。
  • jwt_public_key: （デフォルト: なし）Apigee Edge にデプロイされている Edge Microgateway プロキシを指す URL。このプロキシは、署名付きアクセス トークンをクライアントに発行するための認証エンドポイントとして機能します。プロキシをデプロイするコマンド edgemicro Configure を実行すると、この URL が返されます。詳細については、Edge Microgateway の設定と構成をご覧ください。

edgemicro 属性

これらの設定では、Edge Microgateway プロセスを構成します。

  • port: （デフォルト: 8000）Edge Microgateway プロセスがリッスンするポート番号。
  • max_connections: （デフォルト: -1）Edge Microgateway が受信できる同時受信接続の最大数を指定します。この数を超えると、次のステータスが返されます。

    res.statusCode = 429; // Too many requests
  • max_connections_hard: （デフォルト: -1）接続をシャットダウンする前に Edge Microgateway が受信できる同時リクエストの最大数。この設定は、サービス拒否攻撃を阻止するためのものです。通常は、max_connections よりも大きな数に設定します。
  • logging:
    • level:（デフォルト: error）
      • info - Edge Microgateway インスタンスを通過するすべてのリクエストとレスポンスをログに記録します。
      • warn - 警告メッセージのみをログに記録します。
      • error - エラー メッセージのみをログに記録します。
    • dir: （デフォルト: /var/tmp）ログファイルが保存されるディレクトリ。
    • stats_log_interval: （デフォルト: 60）統計情報レコードが API ログファイルに書き込まれる間隔（秒単位）。
    • rotate_interval: （デフォルト: 24）ログファイルをローテーションする間隔（時間単位）。
  • dir: ./gateway ディレクトリから ./plugins ディレクトリへの相対パスまたは絶対パス。
  • sequence: Edge Microgateway インスタンスに追加するプラグイン モジュールのリスト。モジュールはここで指定された順序で実行されます。
  • debug: Edge Microgateway プロセスにリモート デバッグを追加します。
    • port: リッスンするポート番号。たとえば、このポートでリッスンするように IDE デバッガを設定します。
    • args: デバッグ プロセスへの引数。例: args --nolazy
  • config_change_poll_interval: （デフォルト: 600 秒）Edge Microgateway は定期的に新しい構成を読み込み、変更があった場合は再読み込みを実行します。このポーリングにより、Edge で行われた変更（プロダクト、Microgateway 対応プロキシなどに対する変更）と、ローカル構成ファイルに対する変更が取得されます。
  • disable_config_poll_interval:（デフォルト: false）自動変更ポーリングをオフにするには、true に設定します。
  • request_timeout: ターゲット リクエストのタイムアウトを設定します。タイムアウトは秒単位で設定します。タイムアウトが発生すると、Edge Microgateway は 504 ステータス コードを返します。（v2.4.x で追加）

header 属性

これらの設定は、特定の HTTP ヘッダーの処理方法を構成します。

  • x-forwarded-for: （デフォルト: true）x-forwarded-for ヘッダーがターゲットに渡されないようにするには、false に設定します。リクエストに x-forwarded-for ヘッダーがある場合、その値は Edge Analytics の client-ip 値に設定されます。
  • x-forwarded-host: （デフォルト: true）x-forwarded-host ヘッダーがターゲットに渡されないようにするには、false に設定します。
  • x-request-id: （デフォルト: true）x-request-id ヘッダーがターゲットに渡されないようにするには、false に設定します。
  • x-response-time: （デフォルト: true）x-response-time ヘッダーがターゲットに渡されないようにするには、false に設定します。
  • via: （デフォルト: true）via ヘッダーがターゲットに渡されないようにするには、false に設定します。

OAuth 属性

これらの設定では、Edge Microgateway でクライアント認証を適用する方法を構成します。

  • allowNoAuthorization: （デフォルト: false）true に設定すると、Authorization ヘッダーなしで API 呼び出しが Edge Microgateway を通過できるようになります。Authorization ヘッダーを要求するには、これを false に設定します（デフォルト）。
  • allowInvalidAuthorization: （デフォルト: false）true に設定すると、Authorization ヘッダーで渡されたトークンが無効または期限切れの場合でも API 呼び出しで通過できます。有効なトークンを要求するには、これを false に設定します（デフォルト）。
  • authorization-header: （デフォルト: Authorization: Bearer）アクセス トークンを Edge Microgateway に送信するために使用されるヘッダー。ターゲットが他の目的で Authorization ヘッダーを使用する必要がある場合は、このデフォルトを変更できます。
  • api-key-header: （デフォルト: x-api-key）API キーを Edge Microgateway に渡すために使用されるヘッダーまたはクエリ パラメータの名前。API キーを使用するもご覧ください。
  • keepAuthHeader: （デフォルト: false）true に設定すると、リクエストで送信された Authorization ヘッダーがターゲットに渡されます（保持されます）。
  • allowOAuthOnly: true に設定すると、すべての API が署名なしアクセス トークンを含む Authorization ヘッダーを送信する必要があります。（下位互換性を維持しながら）OAuth セキュリティ モデルのみを許可できます。（4.2.x で追加）
  • allowAPIKeyOnly -- true に設定すると、すべての API に API キーを含む x-api-key ヘッダー（またはカスタムの場所）を含める必要があります。下位互換性を維持したまま、API キー セキュリティ モデルのみを許可できます。（4.2.x で追加）

プラグイン固有の属性

各プラグインで構成可能な属性の詳細については、プラグインの使用をご覧ください。

プロキシのフィルタリング

Edge Microgateway インスタンスが処理する microgateway 対応プロキシをフィルタリングできます。Edge Microgateway が起動すると、関連付けられている組織内のすべての microgateway 対応プロキシがダウンロードされます。次の構成を使用して、Microgateway が処理するプロキシを制限します。たとえば、この構成では、Microgateway が処理するプロキシを edgemicro_proxy-1、edgemicro_proxy-2、edgemicro_proxy-3 の 3 つに制限します。

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

分析データのマスキング

次の構成では、リクエストパスの情報が Edge Analytics に表示されません。microgateway の構成に以下を追加して、リクエスト URI やリクエストパスをマスクします。URI は、リクエストのホスト名とパスの部分で構成されます。

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

会社のファイアウォールの内側で Edge Microgateway を設定する

v4.2.x に対応

Edge Microgateway がファイアウォールの内側にインストールされている場合、ゲートウェイが Apigee Edge と通信できない場合があります。この場合、次の 2 つのオプションが考えられます。

オプション 1:

1 つ目の方法は、Microgateway 構成ファイルで edgemicro: proxy_tunnel オプションを true に設定することです。

edge_config:

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

proxy_tunnel が true の場合、Edge Microgateway は HTTP CONNECT メソッドを使用して、単一の TCP 接続で HTTP リクエストをトンネリングします。（プロキシを構成する環境変数で TLS が有効になっている場合も同様です）。

オプション 2:

2 つ目の方法は、プロキシを指定し、Microgateway 構成ファイルで proxy_tunnel を false に設定することです。例:

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

この場合、変数 HTTP_PROXY、HTTPS_PROXY、NO_PROXY を設定して、使用する各 HTTP プロキシのホストや、Edge Microgateway プロキシを処理しないホストを制御できます。

NO_PROXY は、Edge Microgateway がプロキシしないドメインのカンマ区切りリストとして設定できます。例:

export NO_PROXY='localhost,localhost:8080'

HTTP_PROXY と HTTPS_PROXY を、Edge Microgateway がメッセージを送信できる HTTP プロキシ エンドポイントに設定します。例:

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

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

これらの変数の詳細については、以下をご覧ください。

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


関連ドキュメント

Apigee コミュニティの 会社のファイアウォールの内側で Edge Microgateway を設定する方法

Microgateway 対応プロキシでのワイルドカードの使用

edgemicro_*（Microgateway 対応）プロキシのベースパスには、1 つ以上の「*」ワイルドカードを使用できます。たとえば、ベースパスを /team/*/members にすると、新しいチームをサポートするために新しい API プロキシを作成しなくても、クライアントは https://[host]/team/blue/members と https://[host]/team/green/members を呼び出せます。/**/ はサポートされていません。

重要: Apigee では、ベースパスの最初の要素としてワイルドカード「*」を使用できません。たとえば、/*/ 検索はサポートされていません。


デバッグとトラブルシューティング

デバッガに接続する

Edge Microgateway は、node-inspector などのデバッガで実行できます。これは、カスタム プラグインのトラブルシューティングとデバッグに役立ちます。

  1. Edge Microgateway をデバッグモードで再起動します。そのためには、start コマンドの先頭に DEBUG=* を追加します。次に例を示します。

    DEBUG=* edgemicro start -o myorg -e test -k db4e9e8a95aa7fabfdeacbb1169d0a8cbe42bec19c6b98129e02 -s 6e56af7c1b26dfe93dae78a735c8afc9796b077d105ae5618ce7ed

    注: Windows の場合は、SET DEBUG=* を使用してください。

  2. デバッガを起動し、デバッグ プロセス用のポート番号をリッスンするよう設定します。
  3. Edge Microgateway コードのステップ実行、ブレークポイントの設定、式の監視などを行えるようになりました。

デバッグモードに関連する標準の Node.js フラグを指定できます。たとえば、--nolazy は非同期コードのデバッグに役立ちます。

ログファイルの確認

問題が発生した場合は、ログファイルで実行の詳細とエラー情報を確認してください。詳しくは、ログファイルの管理をご覧ください。

API キーのセキュリティを使用する

API キーは、Edge Microgateway にリクエストを行うクライアントを認証するシンプルなメカニズムを提供します。API キーは、Edge Microgateway 認証プロキシを含む Apigee Edge プロダクトからコンシューマ キー（クライアント ID とも呼ばれます）の値をコピーすることで取得できます。

鍵のキャッシュ保存

API キーは署名なしトークンと交換され、キャッシュに保存されます。キャッシュ保存を無効にするには、Edge Microgateway への受信リクエストに Cache-Control: no-cache ヘッダーを設定します。

OAuth2 トークン セキュリティの使用

プロキシ リクエストで OAuth トークンを使用する詳しい方法については、Edge Microgateway の保護をご覧ください。

API キーを使用する

プロキシ リクエストで API キーを使用する方法については、Edge Microgateway の保護をご覧ください。

API キー名を設定する

デフォルトでは、x-api-key は API キーヘッダーまたはクエリ パラメータに使用される名前です。このデフォルト値は、構成の変更で説明されているように、構成ファイルで変更できます。 たとえば、次のように名前を apiKey に変更します。

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