Edge Microgateway リリースノート

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

バージョン 3.3.x

バグ修正および機能強化 v.3.3.x

3.3.3

2024 年 4 月 25 日に、Edge microgateway に対して以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.3.3 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

修正されたセキュリティの問題

• CVE-2023-0842
• CVE-2023-26115
• CVE-2022-25883
• CVE-2017-20162
• CVE-2022-31129
• CVE-2022-23539
• CVE-2022-23541
• CVE-2022-23540
• CVE-2024-21484
• CVE-2022-46175
• CVE-2023-45133
• CVE-2020-15366
• CVE-2023-26136
• CVE-2023-26115

3.3.2

2023 年 8 月 18 日に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.3.2 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

修正されたセキュリティの問題

なし。

3.3.1

2022 年 6 月 7 日に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.3.1 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

修正されたセキュリティの問題

3.3.0

2022 年 2 月 4 日に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.3.0 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

npm install apigeetool@0.15.1

バージョン 3.2.x

バグの修正および機能強化 v.3.2.x

3.2.3

2021 年 9 月 17 日に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.2.3 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

修正されたセキュリティの問題

3.2.2

2021 年 7 月 15 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.2.2 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

修正されたセキュリティの問題

3.2.1

2021 年 3 月 5 日（金曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.2.1 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

edgemicro:
 enable_GET_req_body: true

3.2.0

2021 年 1 月 21 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.2.0 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

バージョン 3.1.x

バグの修正および機能強化 v.3.1.x

3.1.8

2020 年 11 月 16 日（月）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.8 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

3.1.7

2020 年 9 月 24 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.7 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

{"message":"write after end","code":"ERR_STREAM_WRITE_AFTER_END"}

3.1.6

2020 年 8 月 20 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.6 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

3.1.5

2020 年 6 月 26 日（金曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.5 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

3.1.4

2020 年 4 月 23 日（金曜日）に、Edge microgateway の次の修正をリリースしました。

バグの修正:

バージョン 3.1.3 での依存関係の問題が修正されました。バージョン 3.1.3 は、npm リポジトリで非推奨としてマークされています。それ以外の場合、バージョン 3.1.3 リリースノートに記載されているバグ修正と機能強化はすべて、このリリースに適用されます。

3.1.3

2020 年 4 月 15 日（水曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.3 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 153509313 - Node.js デバッグ モジュールでメモリリークが発生する問題を修正しました。 この問題は、バージョン v3.1.0、v3.1.1、および 3.1.2 で発生します。
• 153509313 - 2 つの異なるトランザクションで同じメッセージ ID がロギング出力に出力される問題を修正しました。
• 151673570 - 新しい Apigee KVM API を使用するように Edge CIDR が更新されない問題が修正されました。Edge Dataprep で、KVM 値の追加と更新に新しいコマンドが使用されるようになりました。
• 152822846 - 以前のリリースでは、リソースパス マッピングの処理が Apigee Edge の処理と一致するように Edge Dataprep が更新されました。このリリースでは、パターン /literal_string/* が正しく処理されない問題を修正しました。例: /*/2/* リソースパス「/」、「/*」、「/**」の動作を構成するもご覧ください。
• 152005003 - 割り当てで組織および環境スコープの識別子を使用できるように変更されました。
• 152005003 - 割り当てで組織および環境スコープの識別子を使用できるように変更されました。org + env + appName + productName の組み合わせが割り当て ID として使用されます。

3.1.2

2020 年 3 月 16 日（月）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.3 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 151285018 - 機能が拡張され、Edge CIDR とバックエンド ターゲット間のトラフィックに HTTP プロキシ サポートが追加されました。さらに、Edge CIDR と Apigee Edge との間の既存の HTTP プロキシ サポートの問題も修正されました。詳しくは、以下をご覧ください。
  • HTTP プロキシを使用して Apigee Edge と通信する
  • ターゲット通信に HTTP プロキシを使用する
• 149101890 - ターゲット サーバーまたはロードバランサが接続を閉じた場合のログ通知コードが、ERROR から INFO に変更されました。
• 150746985 - 構成ファイルに redisBasedConfigCache: true または quotaUri: https://%s-%s.apigee.net/edgemicro-auth のいずれかが存在する場合に edgemicro verify コマンドが正しく動作しない問題を修正しました。
• 151284716 - 再読み込み中にワーカーを再起動すると、サーバー接続をより迅速に閉じるように機能が強化されました。
• 151588764 - Node.js v8 は非推奨となったため、Docker コンテナで Edge Dataprep を実行するために使用される Docker イメージの Node.js バージョンを 12 に更新する。
• 151306049 - Edge Dataprep の CLI コマンドで使用される Apigee Edge 管理 API を一覧表示するドキュメントが更新されました。 Edge CIDR が使用する管理 API をご覧ください。

3.1.1

2 月 20 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.1 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 146069701 - microgateway-core モジュールが HTTP_PROXY 環境変数と HTTPS_PROXY 環境変数を尊重しない問題を修正しました。 この変更により、YAML 構成ファイルで指定したプロキシ設定は無視されるようになりました。プロキシの指定には環境変数のみが使用されます。

  構成ファイルでプロキシ構成を指定する場合は、構成ファイルで指定したものと同じプロキシ URL を示す HTTP_PROXY 変数も指定する必要があります。たとえば、次の構成を指定するとします。

  edge_config:
    proxy: http://10.128.0.20:3128
    proxy_tunnel: true
  

  次の環境変数も指定する必要があります。

  HTTP_PROXY=http://10.128.0.20:3128

• 146320620 - 新しい設定パラメータ edgemicro.headers_timeout が追加されました。この属性は、HTTP パーサーが完全な HTTP ヘッダーを受信するまで待機する時間（ミリ秒単位）を制限します。次に例を示します。

  edgemicro:
  keep_alive_timeout: 6000
  headers_timeout: 12000

  内部的には、このパラメータによってリクエストの Node.js の Server.headersTimeout 属性が設定されます。（デフォルト: edgemicro.keep_alive_timeout で設定された時間より 5 秒長い。このデフォルト設定により、ロードバランサまたはプロキシが誤って接続をドロップするのを防止できます）。

• 149278885 - 1 つのグローバル タイムアウト設定を使用する代わりに、API プロキシレベルでターゲット API タイムアウトを設定できる新機能が追加されました。

  API プロキシで TargetEndpoint プロパティ io.timeout.millis を設定すると、Edge CIDR はそのプロパティを取得して、ターゲット エンドポイント固有のタイムアウトを適用できます。このパラメータが適用されていない場合、Edge Dataprep は、edgemicro.request_timeout で指定されたグローバル タイムアウトを使用します。

3.1.0

1 月 21 日（火）、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.1.0 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 144187500 - quotas.failOpen フラグがトリガーされると、新しい WARN レベルのイベントがログに記録される。 このフラグは、割り当て処理エラーが発生した場合、または Edge への「割り当て適用」リクエストがリモート割り当てカウンタの更新に失敗した場合にトリガーされます。この場合、次にリモート割り当ての同期が成功するまで、割り当てはローカル数に基づいてのみ処理されます。以前は、このイベントはログレベルが DEBUG に設定されている場合にのみ記録されていました。

  次に例を示します。

  2020-01-20T02:52:53.040Z [warn][localhost:8000][5][foo-eval][test][hello/][]
  [DbpGIq9jKfzPX8jvXEivhA0LPwE][f372cc30-3b2f-11ea-845f-a627f][quota][remote quota not
  available so processing locally, setting quota-failed-open for identifier: AppQuota60.Quota60]
  [GET][][][][]

• 145023519 - Edge CIDR が API プロキシの変更を検出すると、処理中のトランザクションまたは新しいトランザクションが影響を受ける問題を修正しました。プロキシが変更されると、Edge CIDR はキャッシュを更新し、ワーカーノードが再起動します。この変更により、BigQuery に送信される処理中のトランザクションと新しい API 呼び出しへの影響はありません。
• 146378327 - sourceRequest、targetRequest、targetResponse のログレベルが INFO レベルに変更されている。
• 146019878 - Edge Analytics の「API プロキシ パフォーマンス」に対して計算されたレイテンシと、Edge CIDR の sourceResponse/targetResponse ログイベントのレイテンシの不一致が修正されました。現在、Edge Analytics と CIDR のログイベントのレイテンシは一致しています。
• パターン マッチング ロジック関連の変更:
  • 147027862 - API プロダクトで指定されている次のリソースパス マッチング パターンをサポートするように OAuth プラグインが更新されました。
    • /{literal}**
    • /{literal}*
    • 上記の 2 つのパターンを自由に組み合わせる

    この変更により、Edge Dataprep プラグインは、リソースパス「/」、「/*」、「/**」の動作を構成するで説明されているように、Apigee Edge と同じパターン マッチングに従うようになりました。

  • 145644205 - apiKeys プラグインのパターン マッチング ロジックが oauth プラグインと一致するように更新。
• 143488312 - クライアント ID パラメータの先頭または末尾にスペースがあると、OAuth トークンと API キーのリクエストで JWT プロダクト リストの作成が空になる問題を修正しました。
• 145640807 と 147579179 - 「the Synchronizer」という特別な Edge CIDR インスタンスが Apigee Edge から構成データを取得してローカル Redis データベースに書き込む新機能が追加されました。他の microgateway インスタンスは、データベースから構成データを読み取るように構成できます。この機能により、Edgemicro の復元力が強化されます。Apigee Edge と通信しなくても、Microgateway インスタンスを起動して機能させることができます。詳細については、Synchronizer の使用をご覧ください。

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

バージョン 3.0.x

バグの修正および機能強化 v.3.0.x

3.0.10

11 月 8 日（金曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.0.10 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 142677575 - 機能の更新により、 リソースパス「/」、「/*」、「/**」の動作の構成で説明されているように、Edge API プロダクトで使用されるリソースパスのパターン マッチングが Apigee Edge で使用されるリソースパスのパターン マッチングに沿うようになりました。

  注: /*/2/** などの複合リソース パターンを使用する場合は、edgemicro_auth プロキシをスタンドアロン API プロダクトに追加する必要があります。次に、次のスクリーンショットに示すように、そのプロダクトをプロキシのデベロッパー アプリに含める必要があります。

  

  注: リソースパス「/」、「/*」、「/**」の動作を構成するで説明されているように、features.isSingleForwardSlashBlockingEnabled 構成プロパティは Edge Dataprep でサポートされていません。

• 143740696 - quotas 構成の構造が変更されました（バージョン 3.0.9 のリリースノートも参照）。quotas プロパティは、割り当てプラグインの構成に使用されます。構成要素がわかりやすくなるように、構造を変更しました。 割り当てプラグインを構成するには、次の YAML 構成を使用します。この構成プロパティは quotas と呼ばれます。個々の quotas 構成プロパティの詳細については、 割り当ての構成オプションをご覧ください。

  edgemicro:
    home: ../gateway
    port: 8000
    max_connections: -1
    max_connections_hard: -1
    logging:
      level: info
      dir: /var/tmp
      stats_log_interval: 60
    plugins:
      dir: ../plugins
      sequence:
        - oauth
        - quota
  quotas:
    bufferSize:
      hour: 20000
      minute: 500
      default: 10000
    useDebugMpId: true
    failOpen: true
  ...

• 141750056 - Redis を割り当てバッキング ストアとして使用できる新機能が追加されました。 useRedis が true の場合、 volos-quota-redis モジュールが使用されます。true の場合、割り当ては Redis に接続する Edge Dataprep インスタンスのみに制限されます。false の場合、volos-quota-apigee モジュールがバッキング ストアとして使用され、割り当てカウンタはグローバルです。詳細については、 割り当ての構成オプションをご覧ください。次に例を示します。

  edgemicro:
  ...
  quotas:
    useRedis: true
    redisHost: localhost
    redisPort: 6379
    redisDb: 1

• 140574210 - edgemicro-auth プロキシによって生成されたトークンのデフォルトの有効期限が、108,000 ミリ秒（1.8 分）から 1,800 秒（30 分）に変更されました。
• 143551282 - SAML 対応の組織をサポートするために、edgemicro genkeys コマンドが更新され、‑‑token パラメータが含まれるようになりました。このパラメータを使用すると、認証にユーザー名/パスワードの代わりに OAuth トークンを使用できます。詳細については、 鍵の生成をご覧ください。

3.0.9

10 月 11 日（金曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.0.9 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 141989374 - 割り当てプラグインに新しい「フェイル オープン」機能が追加されました。 この機能が有効になっている場合、割り当て処理エラーが発生した場合、または Edge への「割り当て適用」リクエストでリモート割り当てカウンタの更新に失敗した場合、次にリモート割り当て同期が成功するまで、割り当てはローカル数に基づいてのみ処理されます。どちらの場合も、リクエスト オブジェクトには quota-failed-open フラグが設定されています。

  割り当ての「フェイル オープン」機能を有効にするには、次の構成を設定します。

  quotas :
   failOpen : true

  注: さらに、OAuth プラグインの fail-open リクエスト オブジェクト フラグの名前が oauth-failed-open に変更されました。

• 142093764 - 割り当ての超過を防ぐために、edgemicro-auth プロキシの構成が変更されている。この変更では、割り当てタイプが calendar に設定されます。この改善を使用するには、edgemicro-auth をバージョン 3.0.7 以降に更新する必要があります。
• 142520568 - 割り当てレスポンスで MP（Message Processor）ID のロギングを有効にする新機能が追加されました。この機能を使用するには、edgemicro-auth プロキシをバージョン 3.0.7 以降に更新して、次の構成を設定する必要があります。

  quotas:
    useDebugMpId: true

  useDebugMpId が設定されている場合、Edge からの割り当てレスポンスには MP ID が含まれ、Edge CIDR によってログに記録されます。次に例を示します。

  {
      "allowed": 20,
      "used": 3,
      "exceeded": 0,
      "available": 17,
      "expiryTime": 1570748640000,
      "timestamp": 1570748580323,
      "debugMpId": "6a12dd72-5c8a-4d39-b51d-2c64f953de6a"
  }

3.0.8

9 月 26 日（木曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.0.8 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 140025210 - 新しい「フェイル オープン」機能が追加されました。この機能により、接続エラーにより edgemicro-auth プロキシへの API キー検証呼び出しが成功せず、期限切れの JWT トークンを更新できない場合でも、API の処理を続行できます。

  この機能を使用すると、古いトークンがキャッシュに残り、猶予期間が終了するまで再利用される猶予期間を設定できます。この機能を使用すると、一時的な接続障害が発生した場合でも、Edge Dataprep はリクエストの処理を継続できます。接続が再開して Verify API Key の呼び出しが成功すると、新しい JWT がフェッチされ、キャッシュ内の古い JWT が置き換えられます。

  新しい「フェイル オープン」機能を構成する手順は次のとおりです。

  1. Edge VMs 構成ファイルの oauth スタンザで次のプロパティを設定します。

     oauth:
       failOpen: true
       failopenGraceInterval: time_in_seconds
       cacheKey: true
       ...

     次に例を示します。

     oauth:
       failOpen: true
       failopenGraceInterval: 5
       cacheKey: true
       ...

     この例では、接続の問題で更新できない場合、古いトークンが 5 秒間使用されます。5 秒後に、認証エラーが返されます。

• 141168968 - すべてのプラグイン ログ出力に correlation_id が含まれるように更新されました。 さらに、一部のログのログレベルが必要に応じて error に変更されました。
• 140193349 - edgemicro-auth プロキシが更新され、すべての Verify API Key リクエストで Edge Dataprep のキーとシークレットが検証されるよう要求されました。Edge Dataprep は、すべての Verify API Key リクエストで常にキーとシークレットを送信するように更新されました。この変更により、クライアントは API キーのみを使用して JWT を取得できなくなります。
• 140090250 - 割り当て処理の診断ログを追加するための更新が行われました。この変更により、quoto ログの出力と他の Edge CIDR ログの関連付けが可能になりました。

3.0.7

9 月 12 日（木曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

コンポーネントのバージョン:

次の表に、Edge CIDR 3.0.7 に関連付けられた個々のコンポーネント プロジェクトのバージョン番号を示します。各コンポーネントは別々のプロジェクトであるため、リリース番号はメインのプロダクト バージョンと一致しない場合があります。

バグの修正と機能強化:

• 140075602 - 必要に応じて 5xx ステータス コードを返すように OAuth プラグインが更新されている。これまで、プラグインは 200 以外のすべてのケースで 4xx ステータス コードのみを返していました。200 ステータス以外のメッセージ レスポンスについては、エラーに応じて正確な 4xx または 5xx コードが返されます。

  この機能はデフォルトでは無効になっています。この機能を有効にするには、oauth.useUpstreamResponse: true プロパティを Edge CIDR 構成に追加します。次に例を示します。

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

• 140090623 - リリース 3.0.6 では、新しい構成プロパティ quota.quotaUri が追加されました。組織にデプロイされている edgemicro-auth プロキシを介して割り当てを管理する場合は、この構成プロパティを設定します。このプロパティが設定されていない場合、割り当てエンドポイントはデフォルトで内部の Edge CIDR エンドポイントになります。次に例を示します。

  edge_config:
    quotaUri: https://%s-%s.apigee.net/edgemicro-auth

  リリース 3.0.7 では、この新しい構成を受け入れるように edgemicro-auth が更新されました。quotaUri プロパティを使用するには、最新の edgemicro-auth プロキシにアップグレードする必要があります。詳細については、 edgemicro-auth プロキシのアップグレードをご覧ください。

• 140470888 - 認証を提供するために、Authorization ヘッダーが割り当て呼び出しに追加されました。 また、割り当て ID から「organization」を削除するように edgemicro-auth プロキシが変更されました。割り当てエンドポイントはお客様の組織に存在するため、割り当て ID は不要になります。
• 140823165 - 次のプロパティ名:

  edgemicro:
      keepAliveTimeout

  リリース 3.0.6 で誤って記載されていました。正しいプロパティ名は次のとおりです。

  edgemicro:
      keep_alive_timeout

• 139526406 - デベロッパー アプリに複数のプロダクトがある場合に割り当てカウントが正しくないバグを修正しました。複数のプロダクトを含むアプリでは、各プロダクトに割り当てが正しく適用されるようになりました。appName と productName の組み合わせが割り当て ID として使用されます。

3.0.6

8 月 29 日（木曜日）に、Edge microgateway の以下の修正と機能強化をリリースしました。

• 138633700 - 新しい設定プロパティ keepAliveTimeout を追加。このプロパティを使用すると、Edge CIDR のタイムアウト（ミリ秒単位）を設定できます。（デフォルトは 5,000 ミリ秒）。

  次に例を示します。

  edgemicro:
    keep_alive_timeout: 600

• 140090623 - 新しい設定プロパティ quotaUri を追加。組織にデプロイされている edgemicro-auth プロキシを介して割り当てを管理する場合は、この構成プロパティを設定します。このプロパティが設定されていない場合、割り当てエンドポイントはデフォルトで内部の Edge CIDR エンドポイントになります。次に例を示します。

  edge_config:
    quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
  

  この機能を使用するには、まず最新バージョンの edgemicro-auth プロキシを組織にデプロイする必要があります。詳細については、 edgemicro-auth プロキシのアップグレードをご覧ください。

• 138722809 - 新しい設定プロパティ stack_trace を追加。このプロパティを使用すると、スタック トレースをログファイルに表示するかどうかを制御できます。次に例を示します。

  stack_trace: false

  stack_trace が true に設定されている場合、スタック トレースはログに出力されます。false に設定すると、スタック トレースはログに出力されません。

3.0.5

8 月 15 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

• 139005279 - edgemicro status コマンドが適切な数のワーカー プロセスを返さない問題を修正しました。
• 138437710 - ExitCounter クラスの問題が修正され、適切なログが書き込まれない問題を修正しました。

• 139064652 - イベントログとシステムログに trace および debug ロギングレベルを追加する機能を追加。現時点では、これらのログレベルを追加する機能のみが追加されています。現在、使用可能なログレベルは info、warn、error です。
• 139064616 - ログ出力が、すべてのコンソール ログ ステートメントで標準化される。コンソールのロギング ステートメントに次の属性が含まれるようになりました。
• タイムスタンプ
• コンポーネント名
• プロセス ID
• コンソールのログメッセージ

• 138413755 - CLI コマンド cert、verify、upgradekvm、token、genkeys、revokekeys、rotatekey、configure の JWT キーとシークレット関連のログ メッセージを改善。

• 138413577 - バックエンド サービスのタイムアウトのエラー処理を追加、改善。
• 138413303 - レスポンスとソケット タイムアウトのエラー処理を追加、改善。
• 138414116 - 「接続拒否」エラーに対するエラー処理を追加、改善。

3.0.4

8 月 1 日（木曜日）、Edge microgateway の以下の修正と機能強化をリリースしました。

• 134445926 - 内部 Edge CIDR 認証の改善。
• 137582169 - 不要なプロセスが起動する問題を修正しました。この追加プロセスにより、プラグインが再読み込みされ、過剰なメモリが使用されました。 Edge Dataprep では、プロセス数が予想される上限内に収まるようになりました。
• 137768774 - ログ メッセージの改善:
  • トランザクション（リクエスト）ログをクリーンアップしました。
  • 必要に応じてログメッセージをさらに追加しました。
  • コンソール出力から関連するログファイルにトランザクション（リクエスト）ログメッセージを移動しました。
  • 一元的なロギング機能を使用するようにコンソールログを更新しました。
• 138321133、138320563 - 将来の割り当て拡張を可能にするために、割り当てバッファの基本的な内部変更を行いました。

3.0.3

7 月 23 日（火）、Edge microgateway の以下の修正と機能強化をリリースしました。

• ロギングの機能強化: 既存のランタイム ログでは、新しい eventLog() 関数を使用して、ランタイム データを一貫した形式でキャプチャしてログに記録します。ログ情報には以下が含まれます。
  • タイムスタンプ（ISO 8601: YYYY-MM-DDTHH:mm:ss.sssZ）。
  • ログレベル（error、warn、info）。
  • Hostname - リクエスト ヘッダーにあるリクエスト側のホスト名。
  • Process ID - Node.js プロセスのクラスタを実行している場合は、ロギングが発生したプロセスの ID です。
  • Apigee 組織名。
  • 組織内の環境名。
  • API プロキシ名。
  • クライアントの IP アドレス。
  • ClientId。
  • 相関 ID（現在設定されていません）。
  • Edge Dataprep のコンポーネント名。
  • カスタム メッセージ - 一部のオブジェクトが、このエラー プロパティに渡される追加情報を出力することがあります。
  • リクエスト メソッド（HTTP リクエストの場合）。
  • レスポンスのステータス コード（HTTP リクエストの場合）。
  • エラー メッセージ。
  • Error code - オブジェクトにエラーコードが含まれている場合、このプロパティに出力されます。
  • かかった時間。
  • オペレーティング システムの 線の終点マーカー。

  null のプロパティ値は、空のかっこ [] になります。

  次の例は、ログ形式を示しています。

  Timestamp [level][hostname][ProcessId][Org][Environment][APIProxy][ClientIp][ClientId][][component][customMessage][reqMethod][respStatusCode][errMessage][errCode][timeTaken]

  （137770055）。

• パフォーマンス: API プロダクトが環境に基づいてフィルタされていなかった。この問題は解決済みです。（135038879）。
• その他の機能テストの統合とコードの品質の改善。

3.0.2

2019 年 7 月 3 日（水曜日）に、Edgemicro の以下の修正と機能強化をリリースしました。

コードの品質 - ユーザーから要求された品質基準を満たすために、コードの品質が審査され、コードが変更されました。JSHint から派生したコード品質のエラーと警告に対処しました。 その結果、実際のコードエラーの一部が特定され、修復されました。すべての Apigee Edge Dataprep モジュールにこのプロセスが適用されました。microgateway-config、microgateway-core、microgateway-plugins、microgateway の 6 月 28 日と 7 月 2 日の commit をご覧ください。コード品質が変更されたすべてのモジュールは、内部ツールを使用してテストされ、お客様のユースケースにおける Edge CIDR の実行を検証します。

3.0.1

2019 年 6 月 21 日（金曜日）に、Edgemicro の以下の修正と機能強化をリリースしました。

• 134834551 - Edge CIDR でサポートされている Node.js バージョンの変更
  （Node.js でサポートされているバージョン: 8 と 12。バージョン 7、9、11 は試験運用版です）
• 134751883 - 負荷がかかった状態で再読み込みすると、Edge CIDR がクラッシュする
• 134518428 - フィルタ パターンが正しくない場合、Edge Dataprep のプロダクト エンドポイントが 5XX を返す
• 135113408 - ワーカーが予期せず終了する場合に再起動する必要がある
• 134945852 - tokenCacheSize が OAuth プラグインで使用されていない -
• 134947757 - OAuth プラグインで cacheTTL を設定する
• 135445171 - OAuth での猶予期間の計算が正しくない
• Edge Dataprep インストールに付属のメモ付きモジュールを使用する
• 135367906 - セキュリティ監査

バージョン 2.5.x

新機能と機能強化 v.2.5.x

（修正日 2.5.38、2019 年 6 月 7 日）

JWT の形式が適切でないと、トークン キャッシュの使用時にワーカーがクラッシュする可能性があります。Edge microgateway-plugins モジュールで修正されました。（b/134672029）

（2.5.37 で追加）CLI オプション edgemicro-cert -t を追加。

edgemicro cert -t オプションを使用すると、OAuth トークンを指定して管理 API を認証できます。証明書の管理もご覧ください。

（2.5.35 で追加）edgemicroctl を使用して Edge Dataprep をデバッグするサポートを追加。

mgdebug フラグは edgemicroctl で使用できます。Kubernetes 統合タスクもご覧ください。

（2.5.35 で追加）edgemicroctl の Windows ビルドを有効化。

（2.5.31 で追加）新しい edgemicro-auth/token API

新しい Edgemicro-auth/token API が追加されました。これにより、クライアント/シークレットを Base64 エンコードされた Basic 認証ヘッダーとして、grant_type をフォーム パラメータとして渡すことができるようになりました。署名なしトークンの直接取得をご覧ください。

（2.5.31 修正）プライベート構成でトークンフラグが考慮されない。

Edge for Private Cloud で OAuth2 アクセス トークンを使用するように Edge CIDR を構成すると、正しく機能しない（トークンが尊重されない）問題を修正しました。

Docker: 自己署名証明書の使用のサポート

（2.5.29 で追加）Node.js でデフォルトで信頼されていない認証局（CA）を使用している場合、Node.js で Docker コンテナを実行するときに NODE_EXTRA_CA_CERTS パラメータを使用できます。詳細については、Node.js で信頼されていない CA の使用をご覧ください。

Docker: TLS のサポート

（2.5.29 で追加）Docker コンテナで動作している Edge Dataprep で、Edge CIDR サーバーへの受信リクエスト（ノースバウンド リクエスト）と Edge CIDR からターゲット アプリケーションへの送信リクエスト（サウスバウンド リクエスト）に対して TLS がサポートされるようになりました。

次の例は、これらの TLS 構成を設定する方法について詳しく説明します。

• ノースバウンド TLS 構成の例
• サウスバウンド TLS 構成の例

これらの例では、コンテナのマウント ポイント /opt/apigee/.edgemicro を使用して証明書を読み込む方法を示します。この証明書は、その後 Edge Dataprep 構成ファイルで参照されます。

Docker: リクエスト プロキシのサポート

（2.5.27 で追加）Docker コンテナで Edge CIDR を実行する場合は、次のオプションを使用して、Microgateway がファイアウォールの背後で実行されているときのプロキシの動作を制御できます。

• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY

詳細については、Docker コンテナとして Edge Micro を実行するをご覧ください。

Docker: 最新のプラグイン手順

（2.5.27 で追加）Docker コンテナで Edge CIDR を実行する場合、プラグインをデプロイする方法は 2 つあります。オプションの一つは、Docker マウント ポイントを使用するという新しい方法です。以前に存在していたもう一方のオプションは基本的に変更されていませんが、Dockerfile は更新されています。詳しくは、次のリンクをご覧ください。

• オプション A: ボリュームにプラグイン ディレクトリをマウントする（新規）
• オプション B: プラグインをコンテナに組み込む（更新）

KVM アップグレード コマンドの新しい OAuth トークンのサポート

（2.5.27 で追加）OAuth トークンを upgradekvm コマンドで使用できます。詳細については、KVM のアップグレードをご覧ください。

Edge Analytics での API の分離

（2.5.26 で追加）新しい分析プラグイン フラグを使用すると、特定の API パスを分離して、Edge Analytics ダッシュボードで個別のプロキシとして表示できます。たとえば、ヘルスチェック API を分離して、実際の API 呼び出しと混同しないようにできます。詳細については、分析からのパスの除外をご覧ください。

ローカル プロキシの構成

（2.5.25 で追加）ローカル プロキシを使用する場合、Apigee Edge に microgateway 対応プロキシを手動で作成する必要はありません。代わりに、Microgateway はローカル プロキシのベースパスを使用します。詳細については、ローカル プロキシモードの使用をご覧ください。

スタンドアロン モードの使用

（2.5.25 で追加）Apigee Edge の依存関係から完全に切断された Edge Dataprep を実行できます。スタンドアロン モードと呼ばれるこのシナリオでは、インターネット接続なしで Edge Dataprep を実行し、テストできます。スタンドアロン モードでの Edge VMs の実行をご覧ください。

キーの取り消し

（2.5.19 追加）Edge CIDR 構成の鍵とシークレットの認証情報を取り消す新しい CLI コマンドが追加されました。

edgemicro revokekeys -o [organization] -e [environment] -u [username] -k [key] -s [secret]

Docker のサポート

（2.5.19 で追加）最新の Edge Dataprep リリースを Docker イメージとしてダウンロードできるようになりました。

docker pull gcr.io/apigee-microgateway/edgemicro:latest

Kubernetes のサポート

（2.5.19 で追加）Edge CIDR は、Kubernetes クラスタにデプロイされたサービスの前のサービスとして、またはサイドカー ゲートウェイとしてデプロイできます。Edge CIDR と Kubernetes の統合の概要をご覧ください。

TCP nodelay オプションのサポート

（2.5.16 追加）新しい構成設定 nodelay を Edge Micro 構成に追加しました。

デフォルトでは、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

Forever モニタリング用の新しい CLI オプション

（2.5.12 で追加）edgemicro forever コマンドに新しいパラメータが追加されました。これらのパラメータを使用すると、forever.json ファイルの場所を指定し、Forever バックグラウンド プロセスを開始または停止できます。Forever モニタリングもご覧ください。

例:

Forever を起動するには:

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

Forever を停止するには:

edgemicro forever -a stop

JWT 鍵のローテーション

Edge Dataprep の OAuth セキュリティに使用される JWT トークンの生成に使用される公開鍵/秘密鍵のペアをローテーションできる新機能が追加されました。 JWT 鍵のローテーションをご覧ください。

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

デフォルトでは、Edge 組織内のすべてのプロキシが、名前の接頭辞「edgemicro_」で始まるすべてのプロキシをダウンロードします。このデフォルトを変更して、名前がパターンと一致するプロキシをダウンロードできます。 ダウンロードしたプロキシのフィルタリングをご覧ください。

API プロキシのないプロダクトの指定

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

永久モニタリングのサポート

Edge Dataprep には、再起動の回数と間隔を制御するために構成できる forever.json ファイルがあります。このファイルは、Forever-monitor というサービスを構成します。このサービスは、Forever をプログラムで管理します。 Forever モニタリングをご覧ください。

Edge micro 構成ファイルの一元管理

複数の Edge CIDR インスタンスを実行している場合は、それらの構成を 1 つのロケーションから管理できます。これを行うには、Edge Micro が構成ファイルをダウンロードできる HTTP エンドポイントを指定します。 構成ファイルのエンドポイントの指定をご覧ください。

forever CLI オプションのサポート

（2.5.8 で追加）edgemicro forever [package.json] コマンドを使用して、forever.json ファイルの場所を指定します。このコマンドを追加する前は、構成ファイルが Edge CIDR のルート ディレクトリにある必要があります。

次に例を示します。

edgemicro forever ~/mydir/forever.json

再読み込みコマンドに configUrl オプションを追加

（2.5.8 で追加）edgemicro reload コマンドで --configUrl オプションまたは -u オプションを使用できるようになりました。

JWT の時間差の猶予期間

（2.5.7 で追加）OAuth 構成で gracePeriod 属性を使用すると、システム クロックと、JWT 認証トークンで指定された Not before（nbf）または Issued At（iat）時刻とのわずかな不一致によって発生するエラーを防止できます。このような不一致を許容するには、この属性を秒数に設定します。 OAuth 属性をご覧ください。

（2.5.7 で追加）OAuth 構成で gracePeriod 属性を使用すると、システム クロックと、JWT 認証トークンで指定された Not before（nbf）または Issued At（iat）時刻とのわずかな不一致によって発生するエラーを防止できます。このような不一致を許容するには、この属性を秒数に設定します。 OAuth 属性をご覧ください。

バグの修正 v2.5.x

• （問題 #236）キャッシュ消去時の入力ミスを修正しました。
• （問題 #234）Edge Dataprep 2.5.35 でクラッシュを再読み込みする。
• （問題 #135）-v オプションの使用時に、無効な仮想ホスト参照「secure」エラーが発生する。この修正により、仮想ホストが「-v」フラグに指定されたものと完全に一致するように、デプロイ前に edgemicro-auth プロキシが変更されます。また、仮想ホストには任意の数と任意の名前を指定できます（デフォルトとセキュアに制限されなくなりました）。
• （問題 #141）edgemicro 再読み込みコマンドが構成ファイル オプション -c をサポートしていません。なお、本事象はすでに解決しております。
• （問題 #142）Edge CIDR で、インストール時に非推奨の暗号に関するエラーが表示される。なお、本事象はすでに解決しております。
• （問題 #145）Edge CIDR で割り当てが機能しない。なお、本事象はすでに解決しております。
• （Apigee コミュニティの問題: https://community.apigee.com/questions/33149/emg-jwt-token-validated-against-except-api-proxies-a.html#answer-33336）OAUTH の API プロキシとリソース URI の両方に対して検証された JWT トークン。この問題は解決済みです。
• （Apigee コミュニティの問題: https://community.apigee.com/questions/47846/microgateway-not-working-with-oauth.html）Microsoft が OAuth で機能しません。なお、本事象はすでに解決しております。
• Windows の pidPath を修正しました。
• （問題 #157）エラー メッセージ「ReferenceError: deployProxyWithPassword」が定義されていない原因となった問題が修正されました。
• （問題 #169）Node.js の依存関係を更新する（npm audit）
• edgemicro-auth プロキシが Edge JWT ポリシーを使用するようになりました。プロキシは、JWT サポートを提供する際に Node.js に依存しなくなります。

バージョン 2.4.x

新機能と機能強化 v.2.4.x

1. Edgemicro-auth プロキシのカスタム エイリアスを設定する（PR 116）

edgemicro-auth プロキシのデフォルトのベースパスを変更できます。デフォルトでは、ベースパスは /edgemicro-auth です。これを変更するには、edgemicro configure コマンドで -x フラグを使用します。

例:

edgemicro configure -x /mypath …

2. ベースパスのワイルドカード サポート（PR 77）

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

3. Private Cloud 構成用に CLI に追加されたカスタム構成パス（PR 99）

デフォルトでは、Microgateway 構成ファイルは ./config/config.yaml にあります。init、configure、start の各コマンドで、-c フラグまたは --configDir フラグを使用して、コマンドラインでカスタムの設定パスを指定できるようになりました。Private Cloud インストール用のカスタム構成ディレクトリが認識されない問題を修正しました。

例:

edgemicro start -o docs -e test -k abc123 -s xyz456 -c /home/microgateway/config

4. *_PROXY 変数を尊重する（PR 61）

Edge CIDR がファイアウォールの内側にインストールされていて、パブリック クラウドの 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 CIDR は 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 Maven プロキシを処理しないホストを制御できます。NO_PROXY は、Edge CIDR がプロキシしないドメインのカンマ区切りのリストとして設定できます。次に例を示します。

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

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

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

5. ターゲット リクエストにカスタム タイムアウトを設定する（PR 57）

この構成では、ターゲット リクエストにカスタム タイムアウトを設定できます。

edgemicro:
    request_timeout: 10

タイムアウトは秒単位で設定されます。タイムアウトが発生すると、Edge CIDR は 504 ステータス コードを返します。

6. ターゲット レスポンスでカスタム HTTP ステータス メッセージを尊重する（PR 53）

Edge CIDR は、ターゲット レスポンスに設定されたカスタム HTTP ステータス メッセージに従います。以前のリリースでは、ターゲットから送信されたステータス メッセージは Node.js のデフォルトでオーバーライドされていました。

7. X-Forwarded-For ヘッダーでは、分析用に client_ip を設定できます

X-Forwarded-For ヘッダーが存在する場合、Edge Analytics で報告される client_ip 変数が設定されます。この機能により、Edge CIDR にリクエストを送信したクライアントの IP がわかります。

8. OAuth プラグインの変更

OAuth プラグインは、API キー検証と OAuth アクセス トークン検証をサポートしています。この変更が行われる前は、プラグインにはどちらのセキュリティ方式も受け入れられていました。この変更により、下位互換性を維持しながら、これらのセキュリティ モデルのいずれか 1 つのみを許可できます。

OAuth プラグインに、次の 2 つの新しいフラグが追加されました。

• allowOAuthOnly: true に設定した場合、すべての API で署名なしアクセス トークンを含む Authorization ヘッダーを指定する必要があります。

• allowAPIKeyOnly -- true に設定した場合、すべての API に API キーを含む x-api-key ヘッダー（またはカスタムの場所）を含める必要があります。

これらのフラグは、Edge CIDR 構成ファイルで次のように設定します。

oauth:
    allowNoAuthorization: false
    allowInvalidAuthorization: false
    keep-authorization-header: false
    allowOAuthOnly: false
    allowAPIKeyOnly: false

9. Edgemicro-auth プロキシの改善（PR 40）

edgemicro-auth プロキシが改善されました。これらの変更前は、プロキシは鍵を Edge Secure Store（暗号化された Vault）に保存していました。プロキシは、Edge の暗号化された Key-Value マップ（KVM）に鍵を保存します。

10. プラグインのデフォルトのターゲット URL の書き換え（PR 74）

ターゲット エンドポイント ポートをオーバーライドして、HTTP または HTTPS を選択することもできます。プラグイン コードの req.targetPort 変数と req.targetSecure 変数を変更します。HTTPS を選択するには、req.targetSecure を true に設定します。HTTP の場合は false に設定します。req.targetSecure を true に設定する場合は、こちらのディスカッション スレッドをご覧ください。

11. OAuth トークン認証の初期サポート （PR 125）

認証にユーザー名/パスワードではなく OAuth トークンを使用するように Edge Dataprep を構成できます。OAuth トークンを使用するには、edgemicro configure コマンドで次のパラメータを使用します。

-t, --token <token>

次に例を示します。

edgemicro configure -o docs -e test -t <your token>

バグの修正 v2.4.3

• Edgemicro-auth プロキシを適切に実行するために有料組織が必要となる問題を修正しました。今度は、トライアル組織でも Edge Dataprep を使用できます。（PR 5）
• ストリームがデータの処理を完了していないものの、終了ハンドラが実行されていた問題を修正しました。これにより、部分的なレスポンスが送信されました。（PR 71）
• Private Cloud インストール用のカスタム構成ディレクトリが認識されない問題を修正しました。（PR 110）
• クライアントと Edge CIDR 間の双方向 SSL に関する問題を修正しました。（PR 70）
• API キー検証が適切に機能するために、プロキシのベースパスで末尾のスラッシュが必要になる問題を修正しました。現在は、ベースパスの末尾にスラッシュを付ける必要はありません。（PR 48）

バージョン 2.3.5

新機能と機能強化 v.2.3.5

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

Edge Dataprep インスタンスが処理する microgateway 対応プロキシをフィルタできます。Edge Dataprep は、起動すると、関連付けられている組織内のすべての 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'

バージョン 2.3.3

新機能と機能強化 v.2.3.3

このリリースの新機能と改善点は次のとおりです。

自動変更ポーリングを無効にする

自動変更ポーリングを無効にするには、Microgateway 構成でこの属性を設定します。

disabled_config_poll_interval: true

デフォルトでは、定期的なポーリングにより、Edge で行われた変更（プロダクト、Microgateway 対応プロキシの変更など）と、ローカル構成ファイルに対する変更が取得されます。デフォルトのポーリング間隔は 600 秒（5 分）です。

プラグインでのターゲット URL の書き換え

プラグイン コードで req.targetHostname と req.targetPath の変数を変更することで、プラグインのデフォルトのターゲット URL を動的にオーバーライドできます。

新しいプラグイン関数のシグネチャ

ターゲット レスポンスを引数として指定する、新しいプラグイン関数のシグネチャが追加されました。これにより、プラグインがターゲット レスポンスに簡単にアクセスできるようになります。

function(sourceRequest, sourceResponse, targetResponse, data, cb)

デフォルトのロギング出力の簡素化

デフォルトでは、ロギング サービスは、ダウンロードされたプロキシ、プロダクト、JWT の JSON を省略するようになりました。これらのオブジェクトを出力するようにデフォルトに変更するには、Edge Dataprep の起動時に DEBUG=* を設定します。次に例を示します。

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

CLI にカスタム構成パスを追加。

デフォルトでは、Microgateway 構成ファイルは ./config/config.yaml にあります。init、configure、start の各コマンドで、コマンドラインでカスタムの構成パスを指定できるようになりました。次に例を示します。

edgemicro start -o docs -e test -k abc123 -s xyz456 -c /home/microgateway/config

バグの修正 v2.3.3

• 大規模なリクエスト/レスポンス中に発生したメモリリークが修正されました。
• プラグインの実行順序を修正しました。ドキュメントに記載されているとおりに動作するようになりました。
• プラグイン accumulate-request プラグインが GET リクエストでハングしなくなりました。
• accumulate-response プラグインで、レスポンス本文の欠落が原因でエラーが発生する問題を修正しました。

リリース 2.3.1

インストールに関する注意事項

以前のバージョンの Edge Dataprep では、ZIP ファイルをダウンロードすることでソフトウェアをインストールできます。これらの ZIP ファイルのサポートは終了しました。Edge Dataprep をインストールするには、以下を使用する必要があります。

npm install -g edgemicro

詳細については、インストールに関するトピックをご覧ください。

新機能と機能強化 v.2.3.1

このリリースの新機能と改善点は次のとおりです。

プロキシをフィルタ

新しい構成を使用すると、起動時に Edge Dataprep が読み込むプロキシをフィルタリングできます。以前は、Microgateway は、edgemicro configure コマンドで指定した Edge 組織/環境から取得されたすべての microgateway 対応プロキシ（edgemicro_* という名前のプロキシ）を読み込んでいました。この新機能を使用すると、このプロキシのリストをフィルタリングして、指定したプロキシのみが Edge Dataprep に読み込まれるようになります。次のように、Microgateway 構成ファイルにプロキシ要素を追加するだけです。

edge micro:
proxies:
    - edgemicro_[name]
    - edgemicro_[name]
    ...

たとえば、Edge の org/env に edgemicro_foo と edgemicro_bar という名前の 50 個の edgemicro_* プロキシがあるとします。次のように、この 2 つのプロキシのみを使用するようにマイクロゲートウェイに指示できます。

edge micro:
proxies:
    - edgemicro_foo
    - edgemicro_bar

起動時に、Microgateway は指定されたプロキシのみを呼び出すことができます。Edge の組織/環境からダウンロードされた他の microgateway 対応プロキシを呼び出そうとすると、エラーが発生します。

プラグインでターゲット リクエスト ヘッダーを設定する

ターゲット リクエスト ヘッダーを追加または変更する場合、考慮すべき基本的なパターンが 2 つあります。1 つは受信リクエストにデータを含める場合（POST リクエストの場合）、もう 1 つは含まれていない場合（単純な GET リクエストの場合）です。

受信リクエストにデータが含まれており、ターゲット リクエストにリクエスト ヘッダーを設定する場合について考えてみましょう。以前のバージョンの Edge VMs では、このケースではターゲット ヘッダーを確実に設定できませんでした。

このパターンの鍵は、まずクライアントからのすべての受信データを蓄積することです。次に、onend_request() 関数で新しい関数 request.setOverrideHeader(name, value) を使用してヘッダーをカスタマイズします。

その方法を示すサンプル プラグイン コードを次に示します。onend_request で設定されたヘッダーがターゲットに送信されます。

module.exports.init = function(config, logger, stats) {


  function accumulate(req, data) {
    if (!req._chunks) req._chunks = [];
    req._chunks.push(data);
  }

  return {

    ondata_request: function(req, res, data, next) {
      if (data && data.length > 0) accumulate(req, data);
      next(null, null);
    },

    onend_request: function(req, res, data, next) {
      if (data && data.length > 0) accumulate(req, data);
      var content = Buffer.concat(req._chunks);
      delete req._chunks;
      req.setOverrideHeader('foo', 'bar');
      req.setOverrideHeader('content-length', content.length);
      next(null, content);
    },


    onerror_request: function(req, res, data, next) {
      next(null, null);
    }

  };

}

リクエストにデータが含まれていない場合は、onrequest() ハンドラでターゲット ヘッダーを設定できます。このパターンは新しいものではありません。以前にドキュメント化されており、Edge CIDR で提供されているサンプル プラグインで使用されています。

onrequest: function(req, res, next) {
      debug('plugin onrequest');
      req.headers['x-foo-request-id'] = "bar";
      req.headers['x-foo-request-start'] = Date.now();
      next();
    }

ゼロ ダウンタイムの再読み込み機能

Edge Dataprep に構成の変更を行った後は、メッセージを破棄せずに構成を読み込むことができます。この変更により、Edge CIDR は常にクラスタモードで起動し、edgemicro start コマンドから --cluster オプションが削除されました。

さらに、3 つの新しい CLI コマンドが追加されました。これらのコマンドは、edgemicro start コマンドを実行したディレクトリと同じディレクトリから実行する必要があります。

• edgemicro status - Edge CIDR が実行中かどうかを確認します。
• edgemicro stop - Edge CIDR クラスタを停止します。
• edgemicro reload - ダウンタイムなしで Edge Dataprep 構成を再読み込みします。

ゼロ ダウンタイムでの構成の自動再読み込み

定期的に新しい構成を読み込み、変更があった場合は再読み込みを実行します。このポーリングにより、Edge で行われた変更（プロダクト、Microgateway 対応プロキシの変更など）と、ローカル構成ファイルに対する変更が取得されます。デフォルトのポーリング間隔は 600 秒（5 分）です。次のように、Microgateway 構成ファイルのデフォルトを変更できます。

edgemicro:
    config_change_poll_interval: [seconds]

CLI にバージョン情報を追加。

--version フラグが CLI に追加されました。Edge CIDR の最新バージョンを取得するには、次のコマンドを使用します。

edgemicro --version

新しい Edge CIDR サーバーの SSL オプション

Edge CIDR で、key と cert に加えて、次のサーバー SSL オプションがサポートされるようになりました。

ログファイルを stdout に送信する

新しい設定を使用して、ログデータを標準出力に送信できます。

edgemicro:
  logging:
    to_console: true  

ログファイルの管理をご覧ください。

バージョン 2.1.2

このリリースの新機能と改善点は次のとおりです。

構成にカスタム API エンドポイントを許可する

カスタム認証サービスの使用をサポートする、認可プロキシ用の新しい構成可能なエンドポイントがあります。これらのエンドポイントは次のとおりです。

• edgeconfig:verify_api_key_url
• edgeconfig:products

詳細については、 カスタム認証サービスの使用をご覧ください。

バージョン 2.1.1

このリリースの新機能と改善点は次のとおりです。

クロス プラットフォーム対応の認証プロキシをデプロイする

機能強化によって、Edge に Edge 認証プロキシをデプロイするために使用されるコマンドが Windows システムで互換性を保てるようになりました。

バージョン 2.1.0

新機能と機能強化 v.21.0

新機能と機能強化は次のとおりです。

クライアントの SSL/TLS オプションを指定する

新しい構成オプション セットを使用して、ターゲットへの SSL/TSL 接続のクライアント オプションを指定できます。 クライアント SSL/TSL オプションの使用をご覧ください。

バージョン 2.0.11

インストール ノート v2.0.11

以前のバージョンの Edge Dataprep では、ZIP ファイルをダウンロードすることでソフトウェアをインストールできます。これらの ZIP ファイルのサポートは終了しました。Edge Dataprep をインストールするには、以下を使用する必要があります。

npm install -g edgemicro

詳細については、インストールに関するトピックをご覧ください。

新機能と機能強化 v.2.0.11

新機能と機能強化は次のとおりです。

起動時にポートを指定する

start コマンドを使用すると、ポート番号を指定して、構成ファイルで指定されたポートをオーバーライドできます。PORT 環境変数を使用してポート番号を指定することもできます。詳しくは、start コマンドをご覧ください。

必要に応じて認証ヘッダーを保持する

新しい構成設定 keepAuthHeader を使用すると、リクエストで送信された Authorization ヘッダーを保持できます。true に設定すると、Auth ヘッダーがターゲットに渡されます。 oauth 属性をご覧ください。

カスタム認可サービスを使用できる

独自のカスタム サービスを使用して認証を処理する場合は、そのサービスを指すように Edge Dataprep 構成ファイルの authUri 値を変更します。詳細については、 カスタム認証サービスの使用をご覧ください。

バージョン 2.0.4

Edge Dataprep v.2.0.4 は 2016 年 5 月 25 日にリリースされました。

新機能と機能強化 v2.0.4

このリリースにおける新機能と機能強化は次のとおりです。

プロダクトのリソースパスのサポート

Edge Migrate でプロダクト内のリソースパスがサポートされるようになりました。リソースパスを使用すると、プロキシパスのサフィックスに基づいて API へのアクセスを制限できます。プロダクトの作成とリソースパスの構成の詳細については、API プロダクトを作成するをご覧ください。

npm グローバル インストールのサポート

これで、npm -g（グローバル）オプションを使用して Edge CIDR をインストールできるようになりました。このオプションの詳細については、npm のドキュメントをご覧ください。

バージョン 2.0.0

Edge Dataprep v2.0.0 は 2016 年 4 月 18 日にリリースされました。

新機能と機能強化 v.2.0.0

このリリースにおける新機能と機能強化は次のとおりです。

シングル プロセス サーバー

現在、Edge Dataprep はシングル プロセス サーバーになっています。1 つのプロセス（旧称「エージェント」）が 2 つ目のプロセスである Edge CIDR を起動する 2 つのプロセス モデルは使用されなくなりました。新しいアーキテクチャにより、自動化とコンテナ化が容易になります。

名前空間付き構成ファイル

構成ファイルには、組織と環境を使用して名前空間が適用されるようになったため、複数の CIDR を同じホストで実行できるようになりました。Edge CIDR の config コマンドを実行した後、構成ファイルが ~/.edgemicro に見つかります。

新しい環境変数

EDGEMICRO_ORG、EDGEMICRO_ENV、EDGEMICRO_KEY、EDGEMICRO_SECRET の 4 つの環境変数が追加されました。システムでこれらの変数を設定する場合は、コマンドライン インターフェース（CLI）を使用して Edge CIDR を構成し、起動する際に、それらの値を指定する必要はありません。

キャッシュに保存された構成

Apigee Edge に接続せずに再起動した場合、Edge CIDR はキャッシュに保存された構成ファイル を使用します。

クラスタモード

今回、Edge micro をクラスタモードで起動するオプションが追加されました。クラスタモードでは、マルチコア システムを利用できます。microgateway ではこの機能に Node.js クラスタ モジュールを使用します。詳細については、Node.js のドキュメントをご覧ください。

バグの修正 v2.0.0

プラグイン イベントのライフサイクルが、新しいコールバックでコードを含む非同期コードを適切に処理できるようになりました。

バージョン 1.1.2

Edge VMs v. 1.1.2 は 2016 年 3 月 14 日にリリースされました。

新機能と機能強化 v.1.1.2

このリリースにおける新機能と機能強化は次のとおりです。

パフォーマンスの向上

接続プーリングを改善するため、Node.js HTTP エージェントを適切に使用するようになりました。この強化により、高負荷下でのパフォーマンスと全体的な安定性が向上します。

リモート デバッガのサポート

node-inspector などのリモート デバッガで実行されるように Edge Dataprep を構成できます。

新しい構成ファイルの場所

Edge Dataprep を構成すると、agent/config/default.yaml ファイルが ~./edgemicro/config.yaml にコピーされるようになりました。

ログファイルのローテーション

新しい config 属性を使用すると、Edge CIDR ログのローテーション間隔を指定できます。

バグの修正 v1.1.2

以下のバグは v. 1.1.2 で修正されています。