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

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。 情報

Edge Microgateway v. 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 は組織の環境です（test / prod）。
    • 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 は組織の環境です（test / prod）。
    • 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 ウェブトークン（JWT）に追加し、トークンの有効期限を構成し、リフレッシュ トークンを生成できます。詳細については、GitHub の edgemicro-auth ページをご覧ください。

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

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

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

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

ログファイルの管理

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 の 3 種類のログレベルを設定できます。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 ウェブトークン（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 の値を取ります。統計レコードの場合は stats、警告の場合は 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 の値を取ります。統計レコードの場合は stats、警告の場合は 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 の値を取ります。統計レコードの場合は stats、警告の場合は 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 の値を取ります。統計レコードの場合は stats、警告の場合は warn、エラーの場合は error となります。
  • res - イベントを識別します。この場合は、クライアントへのレスポンスを示します。
  • s - HTTP レスポンスのステータス。
  • d - 期間（ミリ秒）。これは、ターゲット API で使用された時間と Edge Microgateway 自体で使用された時間を含む、API 呼び出しに要した合計時間です。
  • i - ログエントリの ID。4 つのイベント エントリすべてがこの ID を共有します。

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

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

Edge Microgateway 構成リファレンス

構成ファイルの場所

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

edge_config 属性

これらの設定は、Edge Microgateway インスタンスと Apigee Edge との間の対話を構成するために使用します。

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

headers 属性

これらの設定では、特定の 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 に設定した場合、API 呼び出しは Authorization ヘッダーを一切使用することなく 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:

最初のオプションは、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 というベースパスを指定すると、クライアントは https://[host]/team/blue/members と https://[host]/team/green/members のどちらも呼び出すことができます。そのため、新しいチームをサポートするために新しい API プロキシを作成する必要がありません。/**/ はサポートされていません。

重要: 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