Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

Edge Microgateway v. 3.3.x

このトピックでは、Edge Microgateway の管理と構成の方法について説明します。

インターネット接続がある場合の Edge Microgateway のアップグレード

このセクションでは、既存の Edge Microgateway のインストールをアップグレードする方法について説明します。インターネット接続なしで運用している場合は、インターネット接続なしで Edge Microgateway をインストールできますか？をご覧ください。

本番環境をアップグレードする前に、新しいバージョンで既存の構成をテストすることをおすすめします。

次の npm コマンドを実行して、最新バージョンの Edge Microgateway にアップグレードします。
```
npm upgrade edgemicro -g
```
特定のバージョンの Edge Microgateway をインストールするには、インストールコマンドでバージョン番号を指定する必要があります。たとえば、バージョン 3.2.3 をインストールするには、次のコマンドを使用します。
```
npm install edgemicro@3.2.3 -g
```
バージョン番号を確認します。たとえば、バージョン 3.2.3 をインストールした場合は、次のようにします。
```
edgemicro --version
current nodejs version is v12.5.0
current edgemicro version is 3.2.3
    
```
最後に、edgemicro-auth プロキシを最新バージョンにアップグレードします。
```
edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME
```

構成の変更

知っておくべき構成ファイルには、次のものがあります。

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

このセクションでは、これらのファイルと、それらの変更について知っておくべきことについて説明します。

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

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

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

ここで、prefix は npm 接頭辞ディレクトリです。このディレクトリが見つからない場合は、Edge Microgateway のインストール場所をご覧ください。

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

edgemicro init
edgemicro configure [params]
edgemicro start [params]

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

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

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

edgemicro stop
edgemicro configure [params]
edgemicro start [params]

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

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

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

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 701e70ee718ce6dc188...78b6181d000723 \
  -s 05c14356e42ed1...4e34ab0cc824
```

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

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 701e70ee718ce...b6181d000723 \
  -s 05c1435...e34ab0cc824
```

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

Apigee Edge Microgateway での TLS の構成については、次の動画をご覧ください。

動画	説明
1 方向のノースバウンド TLS を構成する	Apigee Edge Microgateway での TLS の構成について説明します。この動画では、TLS の概要とその重要性について説明し、Edge Microgateway の TLS を紹介します。また、ノースバウンドの一方向 TLS を構成する方法についても説明します。
双方向のノースバウンド TLS を構成する	これは、Apigee Edge Microgateway での TLS の構成に関する 2 番目の動画です。この動画では、ノースバウンド双方向 TLS を構成する方法について説明します。
1 方向と 2 方向のサウスバウンド TLS を構成する	Apigee Edge Microgateway での TLS の構成に関する 3 番目の動画では、下り方向の 1 方向 TLS と双方向 TLS を構成する方法について説明します。

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

https://localhost:8000/myapi

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

openssl ユーティリティまたは任意の方法を使用して、SSL 証明書と鍵を生成または取得します。
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
```
参照先の SSL 鍵ファイルで指定された鍵は、暗号化されていない必要があります。
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`	クライアントの秘密鍵、証明書、CA 証明書を含む `pfx` ファイルへのパス（PFX 形式）。
`passphrase`	秘密鍵または PFX のパスフレーズを含む文字列。
`ca`	信頼できる証明書のリストを含む PEM 形式のファイルへのパス。
`ciphers`	使用する暗号を「:」で区切って記述した文字列。
`rejectUnauthorized`	true の場合、サーバー証明書は、指定された CA のリストと照合して検証されます。検証で不合格だった場合は、エラーが返されます。
`secureProtocol`	使用する SSL メソッド。たとえば、SSLv3_method を使用して SSL をバージョン 3 に強制します。
`servername`	SNI（Server Name Indication）TLS 拡張機能のサーバー名。
`requestCert`	双方向 SSL の場合は true、一方向 SSL の場合は false

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

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

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

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

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

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

TLS の例を次に示します。

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

複数の特定のターゲットに TLS / SSL 設定を適用する場合は、構成の最初のホストを「空」として指定する必要があります。これにより、ユニバーサルリクエストが有効になり、特定のホストを任意の順序で指定できます。この例では、設定が複数の特定のホストに適用されます。

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

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

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

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

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

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

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

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

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

重要: デフォルトの認証プロキシをオーバーライドする場合、新しいプロキシまたはサービスは、デフォルトの edgemicro-auth プロキシと同じレスポンス形式を返す必要があります。

ログファイルの管理

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 とログファイルの両方に送信することはできません。

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

使用するログレベルは edgemicro 構成で指定します。ログレベルとその説明の完全なリストについては、edgemicro 属性をご覧ください。

たとえば、次の構成では、ロギングレベルを 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

ログの間隔を変更する方法

これらの間隔は、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

厳格なログファイルへのアクセス許可を緩和する方法

デフォルトでは、Edge Microgateway は、ファイルへのアクセス許可レベルを 0600 に設定してアプリケーションログファイル（api-log.log）を生成します。この権限レベルでは、外部アプリケーションやユーザーはログファイルを読み取ることができません。この厳格な権限レベルを緩和するには、logging:disableStrictLogFile を true に設定します。この属性が true の場合、ログファイルはファイル権限が 0755 に設定されて作成されます。false の場合、または属性が指定されていない場合、権限はデフォルトで 0600 になります。

v3.2.3 で追加されました。

次に例を示します。

edgemicro:
 logging:
   disableStrictLogFile: true

ログファイルのメンテナンスに関する推奨事項

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

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

ログファイルの命名規則

各 Edge Microgateway インスタンスは、.log 拡張子を持つログファイルを生成します。ログファイルの命名規則は次のとおりです。

edgemicro-HOST_NAME-INSTANCE_ID-api.log

次に例を示します。

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.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 - ロギングレベル。この値は、トランザクションのコンテキストと、edgemicro 構成で設定されたロギングレベルによって異なります。ロギングレベルの設定方法をご覧ください。統計レコードの場合、レベルは stats に設定されます。統計レコードは、stats_log_interval 構成で設定された一定の間隔で報告されます。ログの間隔を変更する方法もご覧ください。
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 - ロギングレベル。この値は、トランザクションのコンテキストと、edgemicro 構成で設定されたロギングレベルによって異なります。ロギングレベルの設定方法をご覧ください。統計レコードの場合、レベルは stats に設定されます。統計レコードは、stats_log_interval 構成で設定された一定の間隔で報告されます。ログの間隔を変更する方法もご覧ください。
treq - イベントを識別します。この場合は、ターゲットリクエストです。
m - ターゲットリクエストで使用される HTTP 動詞。
u - ベースパスに続く URL の部分。
h - バックエンドターゲットのホストとポート番号。
i - ログエントリの ID。4 つのイベントエントリすべてがこの ID を共有します。

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

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

1436403888651 - Unix タイムスタンプ

info - ロギングレベル。この値は、トランザクションのコンテキストと、edgemicro 構成で設定されたロギングレベルによって異なります。ロギングレベルの設定方法をご覧ください。統計レコードの場合、レベルは stats に設定されます。統計レコードは、stats_log_interval 構成で設定された一定の間隔で報告されます。ログの間隔を変更する方法もご覧ください。
tres - イベントを識別します。この場合は、ターゲットレスポンスです。
s - HTTP レスポンスステータス。
d - 再生時間（ミリ秒）。ターゲットによる API 呼び出しに要した時間。
i - ログエントリの ID。4 つのイベントエントリすべてがこの ID を共有します。

4. クライアントへの送信レスポンスの例

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

1436403888651 - Unix タイムスタンプ

info - ロギングレベル。この値は、トランザクションのコンテキストと、edgemicro 構成で設定されたロギングレベルによって異なります。ロギングレベルの設定方法をご覧ください。統計レコードの場合、レベルは stats に設定されます。統計レコードは、stats_log_interval 構成で設定された一定の間隔で報告されます。ログの間隔を変更する方法もご覧ください。
res - イベントを識別します。この場合は、クライアントにレスポンスを返します。
s - HTTP レスポンスステータス。
d - 期間（ミリ秒）。これは、ターゲット API の所要時間と Edge Microgateway 自体の所要時間を含む、API 呼び出しの合計所要時間です。
i - ログエントリの ID。4 つのイベントエントリすべてがこの ID を共有します。

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

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

エラーメッセージ

一部のログエントリにはエラーメッセージが含まれます。エラーの発生場所と発生原因を特定するには、Edge Microgateway エラーリファレンスをご覧ください。

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 の設定と構成をご覧ください。
quotaUri: 組織にデプロイされている edgemicro-auth プロキシを介して割り当てを管理する場合は、この構成プロパティを設定します。このプロパティが設定されていない場合、割り当てエンドポイントはデフォルトで内部 Edge Microgateway エンドポイントになります。
```
edge_config:
  quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
```

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 - エラーメッセージのみをログに記録します。
  - debug - 情報、警告、エラーのメッセージとともにデバッグメッセージをログに記録します。
  - trace - エラーのトレース情報を、情報メッセージ、警告メッセージ、エラーメッセージとともにログに記録します。
  - none - ログファイルを作成しません。
- dir:（デフォルト: /var/tmp）ログファイルが保存されるディレクトリ。
- stats_log_interval:（デフォルト: 60）統計レコードが API ログファイルに書き込まれる間隔（秒単位）。
- rotate_interval:（デフォルト: 24）ログファイルがローテーションされる間隔（時間単位）。

plugins: プラグインは Edge Microgateway に機能を追加します。プラグインの開発の詳細については、カスタムプラグインを開発するをご覧ください。

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 で追加）
keep_alive_timeout: このプロパティを使用すると、Edge Microgateway のタイムアウト（ミリ秒単位）を設定できます。（デフォルト: 5 秒）（v3.0.6 で追加）
headers_timeout: この属性は、HTTP パーサーが完全な HTTP ヘッダーを受信するまで待機する時間（ミリ秒単位）を制限します。
次に例を示します。
```
edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000
```
内部的には、このパラメータはリクエストに Node.js の Server.headersTimeout 属性を設定します。（デフォルト: edgemicro.keep_alive_timeout で設定された時間より 5 秒長い時間。このデフォルト設定により、ロードバランサやプロキシが誤って接続をドロップするのを防ぎます。（v3.1.1 で追加）
noRuleMatchAction:（文字列）accesscontrol プラグインで指定された一致ルールが解決されない（一致しない）場合に実行するアクション（アクセスの許可または拒否）。有効な値: ALLOW または DENY。デフォルト: ALLOW（追加: v3.1.7）
enableAnalytics:（デフォルト: true）アナリティクスプラグインが読み込まれないようにするには、この属性を false に設定します。この場合、Apigee Edge Analytics への呼び出しは行われません。true に設定されている場合、またはこの属性が指定されていない場合、アナリティクスプラグインは通常どおり動作します。詳細については、edgemicro 属性をご覧ください。（v3.1.8 で追加）。
例:
```
edgemicro
  enableAnalytics=false|true
```
enableAnalytics が false に設定されているが、Edge Microgateway が指標プラグインを使用して起動されている場合、指標プラグインが機能するには分析プラグインが必要なため、分析プラグインは通常どおり動作します。指標プラグインの詳細については、Edge Microgateway v1.3.6 リリースノートをご覧ください。

on_target_response_abort: この属性を使用すると、クライアント（Edge Microgateway）とターゲットサーバー間の接続が早期に終了した場合の Edge Microgateway の動作を制御できます。

値	説明
デフォルト	`on_target_response_abort` が指定されていない場合、デフォルトの動作では、エラーを表示せずにレスポンスが切り捨てられます。ログファイルには、`targetResponse aborted` と 502 レスポンスコードを含む警告メッセージが表示されます。
`appendErrorToClientResponseBody`	カスタムエラー `TargetResponseAborted` がクライアントに返されます。ログファイルには、`targetResponse aborted` と 502 レスポンスコードを含む警告メッセージが表示されます。さらに、エラー `TargetResponseAborted` がメッセージ `Target response ended prematurely.` とともにログに記録されます。
`abortClientRequest`	Edge Microgateway はリクエストを中止し、ログファイルに警告を書き込みます。`TargetResponseAborted` と 502 リクエストステータスコードが書き込まれます。

例:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

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 キーの使用もご覧ください。
keep-authorization-header:（デフォルト: false）true に設定すると、リクエストで送信された Authorization ヘッダーがターゲットに渡されます（保持されます）。
allowOAuthOnly -- true に設定すると、すべての API にベアラーアクセストークンを含む Authorization ヘッダーを付ける必要があります。OAuth セキュリティモデルのみを許可できます（下位互換性を維持しながら）。（2.4.x で追加）
allowAPIKeyOnly -- true に設定すると、すべての API に API キーを含む x-api-key ヘッダー（またはカスタムロケーション）を付ける必要があります。API キーセキュリティモデルのみを許可できます（下位互換性を維持しながら）。（2.4.x で追加）
allowOAuthOnly と allowAPIKeyOnly の両方を true に設定しないでください。デフォルトの設定では、両方のフラグが false に設定されています（下位互換性のため）。
gracePeriod -- このパラメータは、システムクロックと、JWT 認証トークンで指定された Not Before（nbf）または Issued At（iat）時間とのわずかな不一致によって発生するエラーを防ぐのに役立ちます。このパラメータは、このような不一致を許容する秒数に設定します。（2.5.7 で追加）

プラグイン固有の属性

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

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

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

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

名前で商品をフィルタしています

Edge Microgateway がダウンロードして処理する API プロダクトの数を制限するには、次の構成を使用します。ダウンロードしたプロダクトをフィルタするには、Edge Microgateway の *.config.yaml ファイルに記載されている /products API に productnamefilter クエリパラメータを追加します。次に例を示します。

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'

クエリパラメータの値は正規表現形式で指定し、URL エンコードする必要があります。たとえば、正規表現 ^[Ee]dgemicro.*$ は、「edgemicro-test-1」、「edgemicro_demo」、「Edgemicro_New_Demo」などの名前をキャッチします。クエリパラメータでの使用に適した URL エンコード値は %5E%5BEe%5Ddgemicro.%2A%24 です。

次のデバッグ出力は、フィルタされた商品のみがダウンロードされたことを示しています。

...
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":[

         ]
      }
   ]
}

カスタム属性による商品のフィルタリング

カスタム属性に基づいて商品をフィルタするには:

Edge UI で、Edge Microgateway を構成した組織 / 環境の edgemicro_auth プロキシを選択します。
[Develop] タブで、JavaCallout ポリシーをエディタで開きます。
キー products.filter.attributes を持つカスタム属性を、属性名のカンマ区切りリストで追加します。カスタム属性名のいずれかを含む商品のみが Edge Microgateway に返されます。
カスタム属性 products.filter.env.enable を false に設定すると、現在の環境でプロダクトが有効になっているかどうかを確認するチェックを無効にできます。（デフォルトは true です）。
（プライベートクラウドのみ）Edge for Private Cloud を使用している場合は、プロパティ org.noncps を true に設定して、CPS 以外の環境のプロダクトを pull します。

次に例を示します。

<?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>

取り消しステータスによるプロダクトのフィルタリング

API プロダクトには、保留中、承認済み、取り消し済みの 3 つのステータスコードがあります。edgemicro-auth プロキシの JWT 変数設定ポリシーに、allowProductStatus という新しいプロパティが追加されました。このプロパティを使用して、JWT にリストされている API プロダクトをフィルタするには:

Apigee プロキシエディタで edgemicro-auth プロキシを開きます。

allowProductStatus プロパティを SetJWTVariables ポリシーの XML に追加し、フィルタするステータスコードのカンマ区切りのリストを指定します。たとえば、[保留中] と [取り消し済み] のステータスでフィルタするには、次のようにします。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Javascript timeLimit="20000" async="false" continueOnError="false"
    enabled="true" name="Set-JWT-Variables">
    <DisplayName>Set JWT Variables</DisplayName>
    <FaultRules/>
    <Properties>
        <Property name="allowProductStatus">Pending,Revoked</Property>
    </Properties>
    <ResourceURL>jsc://set-jwt-variables.js</ResourceURL>
</Javascript>

承認済みの商品のみを掲載する場合は、次のようにプロパティを設定します。

<Property name="allowProductStatus">Approved</Property>

プロキシを保存します。
Property タグが存在しない場合、すべてのステータスコードのプロダクトが JWT に一覧表示されます。

この新しいプロパティを使用するには、edgemicro-auth プロキシをアップグレードする必要があります。

分析の push 頻度の構成

これらの構成パラメータを使用して、Edge Microgateway が Apigee に分析データを送信する頻度を制御します。

bufferSize（省略可）: 最も古いレコードの削除を開始する前にバッファに保持できる分析レコードの最大数。デフォルト: 10000
batchSize（省略可）: Apigee に送信される分析レコードのバッチの最大サイズ。デフォルト: 500
flushInterval（省略可）: Apigee に送信される分析レコードのバッチの各フラッシュ間のミリ秒数。デフォルト: 5000

次に例を示します。

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

分析データのマスキング

次の構成では、リクエストパス情報が Edge 分析に表示されなくなります。リクエスト URI やリクエストパスをマスクするには、Microgateway 構成に以下を追加します。URI は、リクエストのホスト名とパスの部分で構成されます。

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

Edge Analytics での API 呼び出しの分離

アナリティクスプラグインを構成して、特定の API パスを分離し、Edge Analytics ダッシュボードに別のプロキシとして表示できます。たとえば、ダッシュボードでヘルスチェック API を分離して、実際の API プロキシ呼び出しと混同しないようにできます。Analytics ダッシュボードでは、分離されたプロキシは次の命名パターンに従います。

edgemicro_proxyname-health

次の図は、Analytics ダッシュボードに表示された 2 つの分離されたプロキシ（edgemicro_hello-health と edgemicro_mock-health）を示しています。

これらのパラメータを使用して、アナリティクスダッシュボードで相対パスと絶対パスを個別のプロキシとして分離します。

relativePath（省略可）: Analytics ダッシュボードで分離する相対パスを指定します。たとえば、/healthcheck を指定すると、パス /healthcheck を含むすべての API 呼び出しがダッシュボードに edgemicro_proxyname-health として表示されます。このフラグはプロキシのベースパスを無視します。ベースパスを含むフルパスに基づいて分離するには、proxyPath フラグを使用します。
proxyPath（省略可）: 分析ダッシュボードで分離する API プロキシのフルパス（プロキシのベースパスを含む）を指定します。たとえば、/mocktarget/healthcheck を指定した場合（/mocktarget はプロキシのベースパス）、パス /mocktarget/healthcheck を持つすべての API 呼び出しがダッシュボードに edgemicro_proxyname-health として表示されます。

たとえば、次の構成では、/healthcheck を含む API パスはアナリティクスプラグインによって分離されます。つまり、/foo/healthcheck と /foo/bar/healthcheck は、アナリティクスダッシュボードで edgemicro_proxyname-health という別のプロキシとして分離されます。

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

次の構成では、プロキシパス /mocktarget/healthcheck を持つ API は、アナリティクスダッシュボードで edgemicro_proxyname-health という別のプロキシとして分離されます。

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

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

Apigee Edge との通信に HTTP プロキシを使用する

バージョン 3.1.2 で追加。

Edge Microgateway と Apigee Edge 間の通信に HTTP プロキシを使用するには、次の操作を行います。

環境変数 HTTP_PROXY、HTTPS_PROXY、NO_PROXY を設定します。これらの変数は、Apigee Edge との通信に使用する各 HTTP プロキシのホスト、または Apigee Edge との通信を処理しないホストを制御します。次に例を示します。
```
export HTTP_PROXY='http://localhost:3786'
export HTTPS_PROXY='https://localhost:3786'
export NO_PROXY='localhost,localhost:8080'
```
NO_PROXY には、Edge Microgateway がプロキシしないドメインのカンマ区切りのリストを指定できます。

これらの変数の詳細については、https://www.npmjs.com/package/request#controlling-proxy-behaviour-using-environment-variables をご覧ください。
Edge Microgateway を再起動します。

ターゲット通信に HTTP プロキシを使用する

バージョン 3.1.2 で追加。

Edge Microgateway とバックエンドターゲット間の通信に HTTP プロキシを使用するには、次の操作を行います。

Microgateway 構成ファイルに次の構成を追加します。
```
edgemicro:
  proxy:
    tunnel: true | false
    url: proxy_url
    bypass: target_host # target hosts to bypass the proxy.
    enabled: true | false
```
ここで
- tunnel: （省略可）true の場合、Edge Microgateway は HTTP CONNECT メソッドを使用して、単一の TCP 接続を介して HTTP リクエストをトンネリングします。（プロキシを構成するための環境変数（後述）が TLS 対応の場合も同様です）。デフォルト: false
- url: HTTP プロキシの URL。
- bypass: （省略可）HTTP プロキシをバイパスする 1 つ以上のターゲットホスト URL をカンマ区切りで指定します。このプロパティが設定されていない場合は、NO_PROXY 環境変数を使用して、バイパスするターゲット URL を指定します。
- enabled: true で proxy.url が設定されている場合は、HTTP プロキシに proxy.url 値を使用します。true で proxy.url が設定されていない場合は、Apigee Edge との通信に HTTP プロキシを使用するで説明されているように、HTTP プロキシ環境変数 HTTP_PROXY と HTTPS_PROXY で指定されたプロキシを使用します。
次に例を示します。
```
edgemicro:
  proxy:
    tunnel: true
    url: 'http://localhost:3786'
    bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
    enabled: true
```
注: 構成ファイルで edgemicro.proxy が省略されている場合、または edgemicro.proxy.enabled が false の場合、Edge Microgateway はターゲット通信に HTTP プロキシを使用しません。
Edge Microgateway を再起動します。

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

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

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

JWT 鍵のローテーション

JWT を最初に生成した後、Edge の暗号化された KVM に保存された公開鍵と秘密鍵のペアの変更が必要になることがあります。新しい鍵ペアを生成するこのプロセスは、鍵のローテーションと呼ばれます。

Edge Microgateway での JWT の使用方法

JSON Web Token（JWT）は、RFC7519 で説明されているトークン標準です。JWT は、一連のクレームに署名する方法を提供します。このクレームは、JWT の受信者によって確実に検証できます。

CLI を使用して JWT を生成し、API キーの代わりに API 呼び出しの Authorization ヘッダーで使用できます。次に例を示します。

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

CLI で JWT を生成する方法については、トークンを生成するをご覧ください。

鍵のローテーションとは

JWT を最初に生成した後、Edge の暗号化された KVM に保存された公開鍵と秘密鍵のペアの変更が必要になることがあります。新しい鍵ペアを生成するこのプロセスは、鍵のローテーションと呼ばれます。鍵をローテーションすると、新しい秘密鍵と公開鍵のペアが生成され、Apigee Edge 組織 / 環境の microgateway KVM に保存されます。また、元の公開鍵は元の鍵 ID 値と一緒に保持されます。

JWT を生成するために、Edge は暗号化された KVM に保存されている情報を使用します。Edge Microgateway を最初に設定（構成）したときに、microgateway という KVM が作成され、鍵が入力されています。KVM の鍵は、JWT の署名と暗号化に使用されます。

KVM キーには次のものがあります。

private_key - JWT の署名に使用される最新（直近に作成された）の RSA 秘密鍵。
public_key - private_key で署名された JWT の検証に使用される最新の（最も新しく作成された）証明書。
private_key_kid - 最新（直近に作成された）の秘密鍵 ID。この鍵 ID は private_key 値に関連付けられており、鍵のローテーションをサポートするために使用されます。
public_key1_kid - 最新の（最も新しく作成された）公開鍵 ID。この鍵は public_key1 値に関連付けられており、鍵のローテーションをサポートするために使用されます。この値は秘密鍵の kid と同じです。
public_key1 - 最新の（直近に作成された）公開鍵。

鍵のローテーションを行うと、既存の鍵の値がマップ内で置き換えられ、古い公開鍵を保持するために新しい鍵が追加されます。次に例を示します。

public_key2_kid - 古い公開鍵 ID。この鍵は public_key2 値に関連付けられており、鍵のローテーションをサポートするために使用されます。
public_key2 - 古い公開鍵。

検証のために提示された JWT は、新しい公開鍵を使用して検証されます。検証で不合格だった場合は、JWT の期限が切れるまで（token_expiry* 間隔後、デフォルトは 30 分）古い公開鍵が使用されます。これにより、API トラフィックをすぐに中断することなく、鍵を「ローテーション」できます。

鍵のローテーションを行う方法

このセクションでは、鍵のローテーションを行う方法について説明します。

KVM をアップグレードするには、edgemicro upgradekvm コマンドを使用します。このコマンドの実行の詳細については、KVM のアップグレードをご覧ください。この手順は 1 回だけ行う必要があります。
edgemicro-oauth プロキシをアップグレードするには、edgemicro upgradeauth コマンドを使用します。このコマンドの実行の詳細については、edgemicro-auth プロキシのアップグレードをご覧ください。この手順は 1 回だけ行う必要があります。
~/.edgemicro/org-env-config.yaml ファイルに次の行を追加します。ここで、Microgateway を使用するように構成したのと同じ組織と環境を指定する必要があります。
```
jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
```

鍵のローテーションコマンドを実行して、鍵をローテーションします。このコマンドの詳細については、鍵のローテーションをご覧ください。

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

次に例を示します。

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

鍵のローテーション後、Edge は複数の鍵を Edge Microgateway に返します。次の例では、各鍵に一意の「kid」（鍵 ID）値があります。Microgateway は、これらの鍵を使用して認可トークンを検証します。トークンの検証で不合格だった場合、Microgateway は鍵セットに古い鍵があるかどうかを調べ、その鍵を試します。返される鍵の形式は JSON Web Key（JWK）です。この形式の詳細については、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"
    }
  ]
}

「not before」遅延の構成

バージョン 3.1.5 以前では、rotatekey コマンドによって生成された新しい秘密鍵がすぐに有効になり、生成された新しいトークンは新しい秘密鍵で署名されていました。ただし、新しい公開鍵は、マイクロゲートウェイ構成が更新されたときにのみ、10 分ごとに（デフォルトで）Edge Microgateway インスタンスで使用可能になりました。トークンの署名と Microgateway インスタンスの更新の間にこの遅延があるため、すべてのインスタンスが最新の公開鍵を受け取るまで、最新の鍵で署名されたトークンは拒否されます。

複数の Microgateway インスタンスが存在する場合、公開鍵のラグにより、ステータス 403 の断続的なランタイムエラーが発生することがありました。これは、トークンの検証が 1 つのインスタンスで成功しても、すべてのインスタンスが更新されるまで別のインスタンスで失敗するためです。

バージョン 3.1.6 以降では、rotatekey コマンドの新しいフラグを使用して、新しい秘密鍵が有効になるまでの遅延を指定できます。これにより、すべての Microgateway インスタンスが更新され、新しい公開鍵を受け取るまでの時間を確保できます。新しいフラグは --nbf で、「not before」を表します。このフラグは、遅延時間（分）を表す整数値を取ります。

次の例では、遅延が 15 分に設定されています。

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

遅延は、config_change_poll_internal 構成設定（デフォルトでは 10 分）よりも長く設定することをおすすめします。edgemicro 属性もご覧ください。

ダウンロードしたプロキシのフィルタリング

デフォルトでは、Edge Microgateway は、Edge 組織内の「edgemicro_」という命名接頭辞で始まるすべてのプロキシをダウンロードします。このデフォルトを変更して、パターンに一致する名前のプロキシをダウンロードできます。

Edge Micro 構成ファイル ~/.edgemicro/org-env-config.yaml を開きます。
edge_config の下に proxyPattern 要素を追加します。たとえば、次のパターンでは、edgemicro_foo、edgemicro_fast、edgemicro_first などのプロキシがダウンロードされます。
```
edge_config:
…
proxyPattern: edgemicro_f*
```

API プロキシなしでプロダクトを指定する

Apigee Edge では、API プロキシを含まない API プロダクトを作成できます。このプロダクト構成では、そのプロダクトに関連付けられた API キーが、組織にデプロイされた任意のプロキシで機能します。バージョン 2.5.4 以降、Edge Microgateway はこのプロダクト構成をサポートしています。

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

デバッガへの接続

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

デバッグモードで Edge Microgateway を再起動します。これを行うには、start コマンドの先頭に DEBUG=* を追加します。
```
DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET
```
注: Windows では、SET DEBUG=* を使用します。

デバッグ出力をファイルに転送するには、次のコマンドを使用します。
```
export DEBUG=* nohup edgemicro start \
-o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log
```
デバッガを起動し、デバッグプロセスのポート番号をリッスンするように設定します。
Edge Microgateway コードのステップ実行、ブレークポイントの設定、式の監視などを行うことができます。

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

ログファイルの確認

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

API キーセキュリティの使用

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

鍵のキャッシュ

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

API キーの使用

API キーは、クエリパラメータまたはヘッダーとして API リクエストに渡すことができます。デフォルトでは、ヘッダーとクエリパラメータの名前はどちらも x-api-key です。

クエリパラメータの例:

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

ヘッダーの例:

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

API キー名の構成

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

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

この例では、クエリパラメータとヘッダー名の両方が apiKey に変更されています。どちらの場合も、x-api-key という名前は使用できなくなります。構成の変更もご覧ください。

次に例を示します。

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

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

アップストリームレスポンスコードを有効にする

デフォルトでは、レスポンスが 200 ステータスでない場合、oauth プラグインは 4xx エラーステータスコードのみを返します。この動作を変更して、エラーに応じて常に正確な 4xx または 5xx コードを返すようにできます。

この機能を有効にするには、Edge Microgateway 構成に oauth.useUpstreamResponse: true プロパティを追加します。次に例を示します。

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

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

このセクションでは、OAuth2 アクセストークンと更新トークンを取得する方法について説明します。アクセストークンは、Microgateway を介して安全な API 呼び出しを行うために使用されます。更新トークンは、新しいアクセストークンを取得するために使用されます。

アクセストークンを取得する方法

このセクションでは、edgemicro-auth プロキシを使用してアクセストークンを取得する方法について説明します。

edgemicro token CLI コマンドを使用してアクセストークンを取得することもできます。CLI の詳細については、トークンの管理をご覧ください。

API 1: 認証情報を本文パラメータとして送信する

URL の組織名と環境名を置き換え、Apigee Edge のデベロッパーアプリから取得したコンシューマ ID とコンシューマシークレットの値を client_id と 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: Basic 認証ヘッダーで認証情報を送信する

クライアント認証情報を Basic 認証ヘッダーとして送信し、grant_type をフォームパラメータとして送信します。このコマンド形式については、RFC 6749: The OAuth 2.0 Authorization Framework でも説明されています。

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"

出力例

API は JSON レスポンスを返します。token プロパティと access_token プロパティに違いはありません。どちらでも使用できます。expires_in は秒単位で指定された整数値です。

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

更新トークンを取得する方法

更新トークンを取得するには、edgemicro-auth プロキシの /token エンドポイントに API 呼び出しを行います。この API 呼び出しは、password 権限付与タイプを使用して行う必要があります。このプロセスは次の手順で行います。

/token API を使用してアクセストークンと更新トークンを取得します。権限付与タイプが 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"
}'

API はアクセストークンと更新トークンを返します。レスポンスは次のようになります。expires_in 値は整数で、秒単位で指定します。

{
    "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"
}

更新トークンを使用して、同じ API の /refresh エンドポイントを呼び出すことで、新しいアクセストークンを取得できるようになりました。例:

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"
}'

API から新しいアクセストークンが返されます。レスポンスは次のようになります。

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

継続的なモニタリング

削除: この CLI 機能は、Edge Microgateway バージョン 3.3.3 で削除されました。forever-monitor は PM2 に置き換えることができます。詳細については、Apigee コミュニティの投稿 Edgemicro + PM2: Starting edgemicro as a service をご覧ください。Edge Microgateway 3.3.3 リリースノートもご覧ください。

構成ファイルのエンドポイントを指定する

複数の Edge Microgateway インスタンスを実行する場合は、それらの構成を 1 か所で管理することをおすすめします。これを行うには、Edge Micro が構成ファイルをダウンロードできる HTTP エンドポイントを指定します。このエンドポイントは、-u フラグを使用して Edge Micro を起動するときに指定できます。

次に例を示します。

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

ここで、mgconfig エンドポイントは構成ファイルの内容を返します。このファイルは、デフォルトでは ~/.edgemicro にあり、命名規則は org-env-config.yaml です。

TCP 接続データバッファリングの無効化

nodelay 構成属性を使用すると、Edge Microgateway で使用される TCP 接続のデータバッファリングを無効にできます。

デフォルトでは、TCP 接続は Nagle アルゴリズムを使用してデータをバッファリングしてから送信します。nodelay を true に設定すると、この動作が無効になります（socket.write() が呼び出されるたびにデータがすぐに送信されます）。詳細については、Node.js のドキュメントもご覧ください。

nodelay を有効にするには、Edge Micro 構成ファイルを次のように編集します。

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

スタンドアロンモードでの Edge Microgateway の実行

Apigee Edge の依存関係から完全に切り離して Edge Microgateway を実行できます。このシナリオはスタンドアロンモードと呼ばれ、インターネット接続なしで Edge Microgateway を実行してテストできます。

スタンドアロンモードでは、Apigee Edge への接続が必要なため、次の機能は動作しません。

OAuth と API キー
割り当て
アナリティクス

一方、カスタムプラグインとスパイク停止は、Apigee Edge への接続を必要としないため、正常に動作します。さらに、extauth という新しいプラグインを使用すると、スタンドアロンモードで JWT を使用して Microgateway への API 呼び出しを認可できます。

ゲートウェイの構成と起動

Edge Microgateway をスタンドアロンモードで実行するには:

$HOME/.edgemicro/$ORG-$ENV-config.yaml という名前の構成ファイルを作成します。
ファイル名の $ORG と $ENV には、任意の値を使用できます。組織と環境の組み合わせは、Edge Microgateway が起動時にファイルを見つけられるようにするための規則にすぎません。
次に例を示します。
```
vi $HOME/.edgemicro/foo-bar-config.yaml
```
次のコードをファイルに貼り付けます。
```
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
```
構成ファイルには、extauth という特別なオプションのプラグインが含まれています。このプラグインは、Microgateway に渡された有効な JWT トークンを検証します。後のステップで、トークンを取得して使用する方法を学習します。また、spikearrest プラグインは Edge との接続に依存しないため、含まれています。quota、oauth、analytics プラグインは、Edge との接続に依存しており、切断モードでは動作しないため、除外されます。カスタムプラグインは許可されており、想定どおりに機能します。
次の環境変数を値「1」でエクスポートします。
```
export EDGEMICRO_LOCAL=1
```
次の start コマンドを実行します。ここで、ローカルプロキシをインスタンス化する値を指定します。
```
edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
  -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH
```
ここで
- $ORG は、構成ファイル名で使用した「org」名です。
- $ENV は、構成ファイル名で使用した「env」名です。
- $LOCAL_PROXY_NAME は、作成されるローカルプロキシの名前です。任意の名前を付けることができます。
- $LOCAL_PROXY_VERSION は、プロキシのバージョン番号です。
- $TARGET_URL は、プロキシのターゲットの URL です。（ターゲットは、プロキシが呼び出すサービスです）。
- $BASE_PATH はプロキシのベースパスです。値の最初にスラッシュを付ける必要があります。ルートベースパスの場合は、スラッシュのみを指定します（例: 「/」）。
次に例を示します。
```
edgemicro start -o local -e test -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
構成をテストします。
```
curl http://localhost:8000/echo  { "error" : "missing_authorization" }
```
extauth プラグインが foo-bar-config.yaml ファイルにあるため、「missing_authorization」エラーが発生します。このプラグインは、API 呼び出しの Authorization ヘッダーに存在する必要がある JWT を検証します。次のセクションでは、エラーなしで API 呼び出しを通過させる JWT を取得します。

例: 認証トークンの取得

次の例は、Apigee Edge（edgemicro-auth/jwkPublicKeys）の Edge Microgateway JWT エンドポイントから JWT を取得する方法を示しています。このエンドポイントは、Edge Microgateway の標準のセットアップと構成を行うときにデプロイされます。Apigee エンドポイントから JWT を取得するには、まず標準の Edge Microgateway の設定を行い、インターネットに接続する必要があります。Apigee エンドポイントは、ここでは例としてのみ使用されており、必須ではありません。必要に応じて、別の JWT トークンエンドポイントを使用できます。その場合は、そのエンドポイントに提供されている API を使用して JWT を取得する必要があります。

microgateway 構成に extauth プラグインを含めるかどうかは任意ですが、含める場合は、API 呼び出しの Authorization ヘッダーに有効な JWT トークンを指定する必要があります。

次の手順では、edgemicro-auth/jwkPublicKeys エンドポイントを使用してトークンを取得する方法について説明します。

Apigee Edge の組織 / 環境に edgemicro-auth プロキシをデプロイするには、Edge Microgateway の標準のセットアップと構成を行う必要があります。この手順を以前に実施している場合は、繰り返す必要はありません。
Edge Microgateway を Apigee Cloud にデプロイした場合は、このエンドポイントから JWT を取得できるように、インターネットに接続する必要があります。
Edge Microgateway を停止します。
```
edgemicro stop
```
以前に作成した構成ファイル（$HOME/.edgemicro/org-env-config.yaml）で、extauth:publickey_url 属性が Apigee Edge 組織 / 環境の edgemicro-auth/jwkPublicKeys エンドポイントを指すようにします。次に例を示します。
```
extauth:
  publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
```
構成ファイル名で使用した組織名と環境名を使用して、以前と同様に Edge Microgateway を再起動します。次に例を示します。
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
認可エンドポイントから JWT トークンを取得します。edgemicro-auth/jwkPublicKeys エンドポイントを使用しているため、次の CLI コマンドを使用できます。
この手順では、インターネット接続が必要です。次のコマンドは、Apigee Edge からトークンを取得します。この手順を行うには、標準の Edge Microgateway の設定と構成を行った Apigee 組織が必要です。この手順を完了した後は、インターネットに接続する必要はありません。トークンは、有効期限が切れるまでスタンドアロンモードで引き続き機能します。

Edge Microgateway の JWT は、edgemicro token コマンドまたは API を使用して生成できます。次に例を示します。

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

ここで

your_org は、以前に Edge Microgateway を構成した Apigee 組織の名前です。
your_env は組織内の環境です。
i オプションには、edgemicro-auth プロキシを含むプロダクトを持つデベロッパーアプリのコンシューマキーを指定します。
s オプションは、edgemicro-auth プロキシを含むプロダクトを持つデベロッパーアプリのコンシューマシークレットを指定します。

このコマンドは、API 呼び出しの検証に使用できる JWT を生成するよう Apigee Edge にリクエストします。

トークンを生成するもご覧ください。

スタンドアロン構成をテストする

構成をテストするには、次のように Authorization ヘッダーにトークンを追加して API を呼び出します。

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

例:

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

出力例:

{
   "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":""
}

ローカルプロキシモードの使用

ローカルプロキシモードでは、Edge Microgateway は、Apigee Edge にデプロイされる Microgateway 対応プロキシを必要としません。代わりに、Microgateway の起動時にローカルプロキシ名、ベースパス、ターゲット URL を指定して「ローカルプロキシ」を構成します。Microgateway への API 呼び出しは、ローカルプロキシのターゲット URL に送信されます。その他の点では、ローカルプロキシモードは、Edge Microgateway を通常モードで実行する場合とまったく同じように動作します。認証は、スパイク防止、割り当ての適用、カスタムプラグインなどと同様に機能します。

ローカルモードと通常の Edge Microgateway 構成の重要な違いは次の 2 つです。（1）ローカルモードでは、Apigee Edge で Microgateway 対応プロキシを作成する必要はありません。（2）Edge で API プロダクトを作成するときに、1 つのプロキシ（edgemicro-auth プロキシ）のみを追加する必要があります。プロダクトに他のプロキシを追加する必要はありません。

ユースケースと例

ローカルプロキシモードは、1 つのプロキシのみを Edge Microgateway インスタンスに関連付ける必要がある場合に便利です。たとえば、Edge Microgateway をサイドカープロキシとして Kubernetes に挿入できます。この場合、Microgateway とサービスはそれぞれ 1 つの Pod で実行され、Microgateway はコンパニオンサービスとの間のトラフィックを管理します。次の図は、Edge Microgateway が Kubernetes クラスタでサイドカープロキシとして機能するアーキテクチャを示しています。各 Microgateway インスタンスは、コンパニオンサービスの単一のエンドポイントとのみ通信します。

サイドカーとしての Edgemicro

このスタイルのアーキテクチャの利点は、Edge Microgateway が、Kubernetes クラスタなどのコンテナ環境にデプロイされた個々のサービスに API 管理を提供することです。

ローカルプロキシモードの構成

ローカルプロキシモードで実行するように Edge Microgateway を構成する手順は次のとおりです。

edgemicro init を実行して、一般的な Edge Microgateway の設定と同様に、ローカル構成環境を設定します。Edge Microgateway を構成するもご覧ください。
一般的な Edge Microgateway の設定手順と同様に、edgemicro configure を実行します。次に例を示します。
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
このコマンドは、edgemicro-auth ポリシーを Edge にデプロイし、Microgateway の起動に必要なキーとシークレットを返します。サポートが必要な場合は、Edge Microgateway を構成するをご覧ください。
Apigee Edge で、次の必須の構成要件を満たす API プロダクトを作成します（他のすべての構成は必要に応じて管理できます）。
- edgemicro-auth プロキシをプロダクトに追加する必要があります。このプロキシは、edgemicro configure を実行したときに自動的にデプロイされました。
- リソースパスを指定する必要があります。Apigee では、このパスをプロダクト（/**）に追加することをおすすめします。詳細については、リソースパスの動作を構成するをご覧ください。Edge ドキュメントの API プロダクトを作成するもご覧ください。
Apigee Edge でデベロッパーを作成します。必要に応じて、既存のデベロッパーを使用することもできます。詳細については、Edge 管理 UI を使用してデベロッパーを追加するをご覧ください。
Apigee Edge でデベロッパーアプリを作成します。作成した API プロダクトをアプリに追加する必要があります。詳細については、Edge 管理 UI でのアプリの登録をご覧ください。
Edge Microgateway がインストールされているマシンで、次の環境変数を値「1」でエクスポートします。
```
export EDGEMICRO_LOCAL_PROXY=1
```
次の start コマンドを実行します。
```
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
```
ここで
- your_org は Apigee 組織です。
- your_environment は組織内の環境です。
- your_key は、edgemicro configure の実行時に返された鍵です。
- your_secret は、edgemicro configure の実行時に返されたシークレットです。
- local_proxy_name は、作成されるローカルプロキシの名前です。
- local_proxy_version は、プロキシのバージョン番号です。
- target_url は、プロキシのターゲット（プロキシが呼び出すサービス）の URL です。
- base_path はプロキシのベースパスです。値の最初にスラッシュを付ける必要があります。ルートベースパスの場合は、スラッシュのみを指定します（例: 「/」）。
次に例を示します。
```
edgemicro start -o your_org -e test -k 7eb6aae644cbc09035a...d2eae46a6c095f \
  -s e16e7b1f5d5e24df...ec29d409a2df853163a -a proxy1 -v 1 \
  -t http://mocktarget.apigee.net -b /echo
```

構成のテスト

ローカルプロキシ構成をテストするには、プロキシエンドポイントを呼び出します。たとえば、ベースパスに /echo を指定した場合、次のようにプロキシを呼び出すことができます。

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

有効な API キーを指定しなかったため、この最初の API 呼び出しでエラーが発生しました。このキーは、以前に作成したデベロッパーアプリで確認できます。Edge UI でアプリを開き、コンシューマキーをコピーして、次のように使用します。

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

次に例を示します。

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

出力例:

{
  "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":""
}

Synchronizer の使用

このセクションでは、Apigee Edge から構成データを取得してローカルの Redis データベースに書き込むことで Edge Microgteway の復元性を向上させるオプション機能である、Synchronizer の使用方法について説明します。Synchronizer インスタンスが実行されていると、異なるノードで実行されている他の Edge Microgateway インスタンスは、このデータベースから直接構成を取得できます。

現在、同期機能は Redis 5.0.x で動作するようにサポートされています。

Synchronizer とは

Synchronizer は、Edge Microgateway に一定レベルの復元性を提供します。これにより、Edge Microgateway のすべてのインスタンスで同じ構成が使用され、インターネットが中断した場合でも、Edge Microgateway インスタンスを起動して適切に実行できます。

デフォルトでは、Edge Microgateway インスタンスは Apigee Edge と通信して、API プロキシや API プロダクトの構成などの構成データを取得して更新できる必要があります。Edge とのインターネット接続が中断された場合でも、最新の構成データがキャッシュに保存されているため、Microgateway インスタンスは機能し続けることができます。ただし、新しい Microgateway インスタンスは、明確な接続がないと起動できません。さらに、インターネットの停止により、1 つ以上の Microgateway インスタンスが、他のインスタンスと同期していない構成情報で実行される可能性があります。

Edge Microgateway Synchronizer は、Edge Microgateway インスタンスが API プロキシトラフィックの起動と処理に必要な構成データを取得するための代替メカニズムを提供します。Apigee Edge への呼び出しから取得される構成データには、jwk_public_keys 呼び出し、jwt_public_key 呼び出し、ブートストラップ呼び出し、API プロダクト呼び出しが含まれます。同期機能により、異なるノードで実行されているすべての Edge Microgateway インスタンスを適切に起動し、Edge Microgateway と Apigee Edge 間のインターネット接続が中断された場合でも同期を維持できます。

Synchronizer は、特別に構成された Edge Microgateway のインスタンスです。その唯一の目的は、Apigee Edge をポーリングし（タイミングは構成可能）、構成データを取得して、ローカルの Redis データベースに書き込むことです。Synchronizer インスタンス自体は、API プロキシトラフィックを処理できません。異なるノードで実行されている Edge Microgateway の他のインスタンスは、Apigee Edge ではなく Redis データベースから構成データを取得するように構成できます。すべての Microgateway インスタンスはローカルデータベースから構成データを pull するため、インターネットが停止した場合でも、起動して API リクエストを処理できます。

Synchronizer インスタンスの構成

同期機能として使用する Edge Microgateway インストールの org-env/config.yaml ファイルに、次の構成を追加します。

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

次に例を示します。

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

オプション	説明
`redisHost`	Redis インスタンスが実行されているホスト。デフォルト: 127.0.0.1
`redisPort`	Redis インスタンスのポート。デフォルト: 6379
`redisDb`	使用する Redis DB。デフォルト: 0
`redisPassword`	データベースのパスワード。

環境変数 EDGEMICRO_REDIS_PASSWORD を使用して、edgemicro.redisPassword パラメータをオーバーライドできます。環境変数の値を使用した構成属性の設定もご覧ください。

最後に、構成ファイルを保存して Edge Microgateway インスタンスを起動します。Apigee Edge のポーリングが開始され、ダウンロードされた構成データが Redis データベースに保存されます。

通常の Edge Microgateway インスタンスの構成

同期ツールを実行すると、API プロキシトラフィックを処理する通常の Microgateway インスタンスを実行するように追加の Edge Microgateway ノードを構成できます。ただし、これらのインスタンスは、Apigee Edge ではなく Redis データベースから構成データを取得するように構成します。

追加の各 Edge Microgateway ノードの org-env/config.yaml ファイルに次の構成を追加します。synchronizerMode プロパティが 0 に設定されていることに注意してください。このプロパティは、API プロキシトラフィックを処理する通常の Edge Microgateway インスタンスとして動作するようにインスタンスを設定します。インスタンスは、Redis データベースから構成データを取得します。

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

次に例を示します。

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

構成プロパティ

Synchronizer の使用をサポートするために、次の構成プロパティが追加されました。

属性値説明

属性	値	説明
`edge_config.synchronizerMode`	0 または 1	0（デフォルト）の場合、Edge Microgateway は標準モードで動作します。 1 の場合、Edge Microgateway インスタンスを起動して、同期ツールとして動作させます。このモードでは、インスタンスは Apigee Edge から構成データを pull し、ローカルの Redis データベースに保存します。このインスタンスは API プロキシリクエストを処理できません。その唯一の目的は、Apigee Edge をポーリングして構成データを取得し、ローカルデータベースに書き込むことです。次に、データベースから読み取るように他の Microgateway インスタンスを構成する必要があります。
`edge_config.redisBasedConfigCache`	true または false	true の場合、Edge Microgateway インスタンスは Apigee Edge ではなく Redis データベースから構成データを取得します。Redis データベースは、Synchronizer が書き込むように構成されているデータベースと同じである必要があります。Redis データベースが利用できない場合、またはデータベースが空の場合、マイクロゲートウェイは設定のために既存の`cache-config.yaml`ファイルを探します。 false（デフォルト）の場合、Edge Microgateway インスタンスは通常どおり Apigee Edge から構成データを取得します。
`edgemicro.config_change_poll_interval`	時間間隔（秒）	Synchronizer が Apigee Edge からデータを pull するポーリング間隔を指定します。

edge_config.synchronizerMode

0 または 1

0（デフォルト）の場合、Edge Microgateway は標準モードで動作します。

1 の場合、Edge Microgateway インスタンスを起動して、同期ツールとして動作させます。このモードでは、インスタンスは Apigee Edge から構成データを pull し、ローカルの Redis データベースに保存します。このインスタンスは API プロキシリクエストを処理できません。その唯一の目的は、Apigee Edge をポーリングして構成データを取得し、ローカルデータベースに書き込むことです。次に、データベースから読み取るように他の Microgateway インスタンスを構成する必要があります。

edge_config.redisBasedConfigCache

true または false

true の場合、Edge Microgateway インスタンスは Apigee Edge ではなく Redis データベースから構成データを取得します。Redis データベースは、Synchronizer が書き込むように構成されているデータベースと同じである必要があります。Redis データベースが利用できない場合、またはデータベースが空の場合、マイクロゲートウェイは設定のために既存のcache-config.yamlファイルを探します。

false（デフォルト）の場合、Edge Microgateway インスタンスは通常どおり Apigee Edge から構成データを取得します。

edgemicro.config_change_poll_interval 時間間隔（秒） Synchronizer が Apigee Edge からデータを pull するポーリング間隔を指定します。

プラグインの除外 URL の構成

指定した URL のプラグインの処理をスキップするように Microgateway を構成できます。これらの「除外」URL は、グローバル（すべてのプラグイン）または特定のプラグインに対して構成できます。

次に例を示します。

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

この例では、プラグインはパス /hello または /proxy_one を使用して受信 API プロキシ呼び出しを処理しません。また、パスに /hello/xml が含まれる API では、json2xml プラグインがスキップされます。

analytics プラグインは除外できません。

環境変数の値を使用して構成属性を設定する

構成ファイルのタグを使用して環境変数を指定できます。指定した環境変数タグは、実際の環境変数の値に置き換えられます。置換はメモリにのみ保存され、元の構成ファイルやキャッシュファイルには保存されません。

注: デフォルトでは、<E> タグは変数の値を文字列として解析します。正の整数値とブール値を指定するには、以下の例に示すように、内部の <n> タグと <b> タグを使用します。

この例では、属性 key が TARGETS_SSL_CLIENT_KEY 環境変数の値に置き換えられます。

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

この例では、<n> タグを使用して整数値を示しています。正の整数のみがサポートされています。

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

この例では、<b> タグを使用してブール値（true または false）を示しています。

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

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

インターネット接続がある場合の Edge Microgateway のアップグレード

構成の変更

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

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

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

環境変数の設定

Edge Microgateway サーバーでの SSL の構成

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

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

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

ログファイルの管理

ログファイルの保存場所

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

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

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

ログの間隔を変更する方法

厳格なログファイルへのアクセス許可を緩和する方法

ログファイルのメンテナンスに関する推奨事項

ログファイルの命名規則

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

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

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

2. ターゲットに対して行われた送信リクエストの例:

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

エラー メッセージ

Edge Microgateway 構成リファレンス

構成ファイルの場所

edge_config 属性

edgemicro 属性

headers 属性

oauth 属性

プラグイン固有の属性

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

名前で商品をフィルタしています

カスタム属性による商品のフィルタリング

取り消しステータスによるプロダクトのフィルタリング

分析の push 頻度の構成

分析データのマスキング

Edge Analytics での API 呼び出しの分離

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

Apigee Edge との通信に HTTP プロキシを使用する

ターゲット通信に HTTP プロキシを使用する

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

JWT 鍵のローテーション

Edge Microgateway での JWT の使用方法

鍵のローテーションとは

鍵のローテーションを行う方法

「not before」遅延の構成

ダウンロードしたプロキシのフィルタリング

API プロキシなしでプロダクトを指定する

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

デバッガへの接続

ログファイルの確認

API キー セキュリティの使用

鍵のキャッシュ

API キーの使用

API キー名の構成

アップストリーム レスポンス コードを有効にする

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

アクセス トークンを取得する方法

更新トークンを取得する方法

継続的なモニタリング

構成ファイルのエンドポイントを指定する

TCP 接続データ バッファリングの無効化

スタンドアロン モードでの Edge Microgateway の実行

ゲートウェイの構成と起動

例: 認証トークンの取得

スタンドアロン構成をテストする

ローカル プロキシ モードの使用

ユースケースと例

ローカル プロキシ モードの構成

構成のテスト

Synchronizer の使用

Synchronizer とは

Synchronizer インスタンスの構成

通常の Edge Microgateway インスタンスの構成

構成プロパティ

プラグインの除外 URL の構成

環境変数の値を使用して構成属性を設定する

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

エラーメッセージ

API キーセキュリティの使用

アップストリームレスポンスコードを有効にする

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

アクセストークンを取得する方法

TCP 接続データバッファリングの無効化

スタンドアロンモードでの Edge Microgateway の実行

ローカルプロキシモードの使用

ローカルプロキシモードの構成