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

<ph type="x-smartling-placeholder"></ph> 現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント
詳細

Edge マネージャー v. 3.2.x

このトピックでは、Edge Appliance を管理および構成する方法について説明します。

インターネット接続を利用できる場合の Edge Appliance のアップグレード

このセクションでは、既存の Edge Appliance 環境をアップグレードする方法について説明します。 インターネットに接続せずに操作している場合は、次をご覧ください: インターネット接続なしで Edge Appliance をインストールできますか?

既存の構成を 新しいバージョンをアップグレードする必要があります。

  1. 次の npm コマンドを実行して、Edge の最新バージョンにアップグレードします。 Dataproc:
    npm upgrade edgemicro -g

    Edge Appliance の特定のバージョンをインストールするには、バージョンを指定する必要があります。 number を指定します。たとえば、バージョン 3.2.3 にインストールするには、次のコマンドを使用します。 次のコマンドを実行します。

    npm install edgemicro@3.2.3 -g
  2. バージョン番号を確認します。たとえば、バージョン 3.2.3 をインストールした場合は、次のようになります。
    edgemicro --version
    current nodejs version is v12.5.0
    current edgemicro version is 3.2.3
        
  3. 最後に、edgemicro-auth プロキシを最新バージョンにアップグレードします。
    edgemicro upgradeauth -o $ORG -e $ENV -u $USERNAME

構成の変更

把握しておく必要がある構成ファイルの内容は次のとおりです。

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

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

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

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

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

ここで、prefixnpm 接頭辞ディレクトリです。<ph type="x-smartling-placeholder"></ph>をご覧ください。 このディレクトリが見つからなかった場合は、Edge AppSheet がインストールされている場所

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

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

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

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

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

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

動的 構成ファイルを使用して、

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

Edge AppSheet が稼働中の場合(ゼロ ダウンタイム オプション):

  1. Edge Gateway 構成を再読み込みします。
    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 Appliance が停止した場合:

  1. Edge Appliance を再起動します。
    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 AppSheet 構成リファレンスをご覧ください。

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 組織と Cloud Identity の値が必要なコマンドライン インターフェースのコマンド 鍵とシークレットは、これらのフォルダに格納できます。 使用します。

  • EDGEMICRO_ORG
  • EDGEMICRO_ENV
  • EDGEMICRO_KEY
  • EDGEMICRO_SECRET

これらの変数の設定は省略可能です。これらを設定する場合、値を指定する必要はありません。 。

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

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

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

SSL を使用するように AppSheet サーバーを構成できます。たとえば、SSL が構成されている場合、 「https」を使用して Edge Appliance を介して API を呼び出すことができます。次のように指定します。

https://localhost:8000/myapi

Apigee サーバーで SSL を構成するには、次の操作を行います。

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

以下は、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 メソッド。たとえば、SSL を強制的にバージョン 3 に設定する SSLv3_method です。
servername SNI(Server Name Indication)TLS 拡張機能のサーバー名。
requestCert 双方向 SSL の場合は true、一方向 SSL の場合は false

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

ターゲットに接続するときに、TLS または SSL クライアントとして Edge Appliance を構成できます 提供しますAppSheet 構成ファイルで、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 メソッド。たとえば、SSL を強制的にバージョン 3 に設定する SSLv3_method です。
servername SNI(Server Name Indication)TLS 拡張機能のサーバー名。

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

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

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

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

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

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

<ph type="x-smartling-placeholder">

ログファイルの管理

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

ログファイルの保存場所

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

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

ログファイルが保存されるディレクトリは、Edge AppSheet の構成で指定されます。 表示されます。関連情報: 構成の作成 変更します

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 の値を変更して、別のログファイル ディレクトリを指定します。

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

ログ情報を特定の外部 IP アドレスではなく標準出力に送信するように、ロギングを構成できます。 表示されます。次のように to_console フラグを true に設定します。

edgemicro:
  logging:
    to_console: true

この設定では、ログは標準出力に送信されます。現在のところ、Google Cloud コンソールと ログファイルに書き込みます。

ロギングレベルの設定方法

edgemicro 構成で使用するログレベルを指定します。1 つの ログレベルとその説明の完全なリストについては、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 AppSheet 構成ファイルで構成できます。構成の変更もご覧ください。

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

  • 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 AppSheet は、ファイル権限を持つアプリケーション ログファイル(api-log.log)を生成します。 0600 に設定します。この権限レベルでは、外部アプリや外部ユーザーが ログファイルを読み取ることができます。この厳格な権限レベルを緩和するには、logging:disableStrictLogFile を設定します。 宛先: trueこの属性が true の場合、ログファイルは 0755 に設定されている必要があります。false の場合、または属性が指定されていない場合、権限はデフォルトで 0600 になります。

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

次に例を示します。

edgemicro:
 logging:
   disableStrictLogFile: true

ログファイルの適切なメンテナンス方法

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

ログファイルの命名規則

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

edgemicro-HOST_NAME-INSTANCE_ID-api.log

次に例を示します。

edgemicro-mymachine-local-MTQzNTgNDMxODAyMQ-api.log

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

v2.3.3 で追加

デフォルトでは、ロギング サービスは、ダウンロードしたプロキシ、プロダクト、JSON の JSON の JSON を省略します。 ウェブトークン(JWT)。これらのオブジェクトをコンソールに出力する場合は、コマンドライン フラグを DEBUG=* を Edge で起動します。例:

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

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

「api」ログファイルには、リクエストとレスポンスのフローに関する詳細情報が含まれます。 接続します「api」各ログファイルに次のような名前を付けます。

edgemicro-mymachine-local-MTQzNjIxOTk0NzY0Nw-api.log

Edge Appliance に対して行われたリクエストごとに、「api」で 4 つのイベントがキャプチャされます。 ファイル:

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

これらの個別のエントリは、ログを簡単に作成できるように省略表記で表現されます。 よりコンパクトになります。以下に、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 Appliance のホストとポート番号 考えてみましょう
  • r - クライアントがリクエストするリモートホストとポート あります。
  • i - リクエスト ID。4 つのイベント エントリすべてでこの ID が共有されます。各 リクエストには一意のリクエスト ID が割り当てられます。ログレコードをリクエスト ID で関連付けることで、 ターゲットのレイテンシについて 貴重な分析情報を得られるからです
  • d - リクエストを受信してからの経過時間(ミリ秒) 説明します。上記の例では、リクエスト 0 に対するターゲットのレスポンスが受信されました。 7 ミリ秒(3 行目)の後にレスポンスがクライアントに送信された後、 ミリ秒(4 行目)。言い換えれば、リクエストのレイテンシの合計は、 ターゲットでかかっていた 7 ミリ秒と Edge Appliance で 4 ミリ秒だったことがわかります できます。

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 つのイベント エントリすべてで あります。

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 つのイベント エントリすべてで あります。

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

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

1436403888651 - Unix の日付スタンプ

  • info - ロギングレベル。この値は、トランザクションのコンテキストとロギングレベルによって異なります。 edgemicro 構成内。ロギングレベルの設定方法をご覧ください。 統計情報レコードの場合、レベルは stats に設定されます。統計レコードの報告先 stats_log_interval 構成で設定された一定間隔。ログ間隔を変更する方法もご覧ください。
  • res - イベントを識別します。この場合、 できます。
  • s - HTTP レスポンスのステータス。
  • d - 期間(ミリ秒単位)。こちらが所要時間 (ターゲット API にかかった時間と Edge にかかった時間を含む) 接続されています。
  • i - ログエントリの ID。4 つのイベント エントリすべてで あります。

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

rotate_interval で指定した間隔でログファイルをローテーションします。 構成属性。エントリは ローテーション間隔が満了するまで保持されます。ただし、Edge から Cloud Storage への 新しい UID を受け取り、その UID で新しいログファイルのセットを作成します。関連項目 ログファイルの適切なメンテナンス プラクティスをご覧ください。

エラー メッセージ

一部のログエントリにはエラー メッセージが含まれます。エラーの発生場所と原因を特定するために Edge AppSheet のエラーを 参照をご覧ください。

Edge AppSheet 構成リファレンス

アプリケーションの 構成ファイル

このセクションで説明する構成属性は Edge Appliance にあります。 構成ファイルが更新されます。関連情報: 構成の作成 変更します

Edge_config 属性

これらの設定は、Edge マネージャー インスタンスとユーザーのやり取りを構成するために Apigee Edge

  • bootstrap: (デフォルト: なし)Edge を指す URL Apigee Edge で実行される Apigee Edge 固有のサービス。Edge AppSheet はこのサービスを使用して、 Apigee Edge と通信します。この URL は、 公開鍵/秘密鍵のペア: edgemicro genkeys詳しくは、設定 と Edge Appliance の構成をご覧ください。
  • jwt_public_key: (デフォルト: なし)Edge AppSheet を指す URL Apigee Edge にデプロイされている プロキシプロキシを構成しますこのプロキシは、サービス アカウントに対する認証エンドポイント クライアントへの署名付きアクセス トークンの発行この URL は、コマンドを edgemicro Configure してプロキシをデプロイします。詳しくは、設定 と Edge Appliance の構成をご覧ください。
  • quotaUri: この設定を設定します。 edgemicro-auth プロキシを使用して割り当てを管理する場合は、 組織にデプロイされます。このプロパティが設定されていない場合は、 割り当てエンドポイントのデフォルトは、内部 Edge AppSheet エンドポイントになります。
    edge_config:
      quotaUri: https://your_org-your_env.apigee.net/edgemicro-auth
    

Edgemicro の属性

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

  • port: (デフォルト: 8000)Edge Gateway のポート番号 リッスンします。
  • max_connections: (デフォルト: -1) 最大 10 個の同時受信接続を接続できます。この番号が 超過すると、次のステータスが返されます。

    res.statusCode = 429; // Too many requests
  • max_connections_hard: (デフォルト: -1)同時接続の最大数 リクエストをシャットダウンします。この設定 サービス拒否攻撃を阻止するためのものです。通常、この値は max_connections.
  • logging: <ph type="x-smartling-placeholder">
      </ph>
    • level: (デフォルト: error) <ph type="x-smartling-placeholder">
        </ph>
      • info - (推奨) インスタンスです。
      • warn - 警告メッセージのみを記録します。
      • error - エラー メッセージのみを記録します。
      • debug - デバッグ メッセージを info、warn、エラー メッセージとともにログに記録します。
      • trace - エラーのトレース情報とともに info、warn、エラー メッセージを記録します。
      • none - ログファイルを作成しません。
    • dir: (デフォルト: /var/tmp)ログファイルが保存されるディレクトリ あります。
    • stats_log_interval: (デフォルト: 60)統計情報がいつ作成されたかを示す間隔 api ログファイルに書き込まれます。
    • rotate_interval: (デフォルト: 24)ログファイルが処理される間隔(時間単位) 回転しました。
  • dir: ./gateway ディレクトリから ディレクトリまたは絶対パスで指定します。
  • 順序: Edge Appliance に追加するプラグイン モジュールのリスト 作成します。モジュールは、ここで指定された順序で実行されます。
  • debug: Edge AppSheet プロセスにリモート デバッグを追加します。
    • port: リッスンするポート番号。たとえば、IDE デバッガを このポートをリッスンします
    • args: デバッグ プロセスの引数。例: args --nolazy
  • config_change_poll_interval:(デフォルト: 600 秒)Edge AppSheet 定期的に新しい構成を読み込み、なんらかの変更があった場合は再読み込みを行います。ポーリング は、すべての変更(プロダクト、Microgateway 対応プロキシの変更など)を ローカル構成ファイルに対する変更も記録されます。
  • disable_config_poll_interval:(デフォルト: false) 自動変更ポーリングを無効にする場合は true
  • request_timeout: ターゲット リクエストのタイムアウトを設定します。タイムアウトは 秒です。タイムアウトが発生すると、Edge Gateway は 504 ステータス コードを返します。(追加済み v2.4.x)
  • keep_alive_timeout: このプロパティを使用すると、Edge Scanner を設定できます。 タイムアウト(ミリ秒単位)。(デフォルト: 5 秒)(v3.0.6 で追加)
  • headers_timeout: この属性は時間(ミリ秒単位)を制限します。 HTTP パーサーは、この ReplicaSet 内の 完全な HTTP ヘッダーです。

    例:

    edgemicro:
      keep_alive_timeout: 6000
      headers_timeout: 12000

    内部的には、このパラメータにより Node.js Server.headersTimeout 属性を使用します。(デフォルト: edgemicro.keep_alive_timeout で設定した時刻。このデフォルトの 設定することで、ロードバランサやプロキシが誤って接続をドロップするのを防ぐことができます)。(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
  • on_target_response_abort: この属性を使用すると、 クライアント(Edge Scanner)と ターゲット サーバーが早期に閉じられます。
    説明
    デフォルト on_target_response_abort が指定されていない場合、デフォルトの動作 エラーを表示せずにレスポンスを切り捨てることです。ログファイルでは、 targetResponse aborted と 502 レスポンス コードとともに表示されます。
    appendErrorToClientResponseBody カスタム エラー TargetResponseAborted が できます。ログファイルでは、 targetResponse aborted と 502 レスポンス コードとともに表示されます。イン また、エラー TargetResponseAborted が次のメッセージとともにログに記録されます。 Target response ended prematurely.
    abortClientRequest Edge AppSheet がリクエストを中止し、ログファイルに警告が書き込まれます。 TargetResponseAborted は、502 リクエスト ステータス コードに置き換えます。

例:

edgemicro:
 on_target_response_abort: appendErrorToClientResponseBody | abortClientRequest

ヘッダー属性

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

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

OAuth 属性

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

  • allowNoAuthorization: (デフォルト: false)true に設定すると、API 呼び出しは Authorization ヘッダーを一切使用せずに Edge Appliance を通過できます。次に設定 Authorization ヘッダーを要求する場合は false(デフォルト)。
  • allowInvalidAuthorization: (デフォルト: false)true に設定した場合、API 呼び出しは Authorization ヘッダーで渡されたトークンが無効または期限切れの場合に渡すことができる。これを設定 false に設定します(有効なトークンが必要です)(デフォルト)。
  • authorization-header: (デフォルト: Authorization: Bearer) アクセス トークンを Edge Appliance に送信します。次のような場合は、デフォルトを変更することをおすすめします。 ターゲットは他の目的で Authorization ヘッダーを使用する必要がある。
  • api-key-header: (デフォルト: x-api-key)ヘッダーまたはクエリの名前 パラメータ。また、 API キー
  • keep-authorization-header: (デフォルト: false)true に設定すると、Authorization ヘッダー そのリクエストで送信されたデータはターゲットに渡されます(保持されます)。
  • allowOAuthOnly - true に設定した場合、すべての API で Authorization API が必要 署名付き URL を生成します。OAuth セキュリティ モデルのみを許可できます(ただし、 下位互換性を維持します)。(2.4.x で追加)。
  • allowAPIKeyOnly - true に設定した場合、すべての API で x-api-key ヘッダー(またはカスタムの場所)に API キーを格納します。これにより、 (下位互換性を維持しながら)API キー セキュリティ モデルのみ。(2.4.x で追加)。
  • gracePeriod -- このパラメータを使用すると、 システム クロックと、Not Before(nbf)または Issued At(iat)時刻との間の差異 JWT 認証トークンで指定されているとおりです。このパラメータを、許可する秒数に設定します 不一致が生じることもあります(2.5.7 で追加)。

プラグイン固有 属性

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

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

Edge Controls インスタンスが処理する Apigee 対応プロキシをフィルタリングできます。 Edge AppSheet は、起動すると、サービス インスタンスのマイクロゲートウェイ対応のプロキシをすべてダウンロードします。 関連付けられています次の構成を使用して、接続先のプロキシを制限する 処理しますたとえば、この構成では、マイクロサービスのプロキシが 次の 3 つに処理されます。edgemicro_proxy-1edgemicro_proxy-2、 および edgemicro_proxy-3:

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

名前による商品のフィルタリング

次の構成を使用して、Edge AppSheet が作成する API プロダクトの数を制限します。 ダウンロードや処理が不要になりますダウンロードした商品をフィルタするには、productnamefilter を追加します Edge Appliance *.config.yaml にリストされている /products API へのクエリ パラメータ 表示されます。例:

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

         ]
      }
   ]
}

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

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

  1. Edge UI で、組織/環境の edgemicro_auth プロキシを選択します。 外部 IP アドレスを使用します。
  2. [Develop] をタップして、JavaCallout ポリシーをエディタで開きます。
  3. キー products.filter.attributes を持つカスタム属性をカンマ区切りで追加します 属性名のリストを返します。いずれかのカスタム属性名を含む商品のみ Edge Appliance に返されます。
  4. このチェックは必要に応じて無効にできます 現在の環境でプロダクトが有効になっているかどうかを カスタム属性 products.filter.env.enablefalse に設定。 (デフォルトは true です)。
  5. (プライベート クラウドのみ)Edge for Private Cloud を使用している場合は、次のプロパティを設定します。 CPS 以外の環境の商品を pull するには、org.noncpstrue に設定します。
  6. 例:

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

分析の push 頻度の構成

次の構成パラメータを使用して、Edge Apigee による送信頻度を制御します。 分析データを Apigee に取り込むには、

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

例:

analytics:
  bufferSize: 15000
  batchSize: 1000
  flushInterval: 6000

分析データのマスキング

次の構成では、リクエストパスの情報が Edge に表示されません。 分析できます以下をマイクロゲートウェイの構成に追加して、リクエスト URI をマスクします。 リクエストパスを指定します。URI は、リクエストのホスト名とパスの部分で構成されます。

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

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

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

edgemicro_proxyname-health

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

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

  • relativePath(省略可): PCollection 内で分離する相対パスを 分析ダッシュボード。たとえば、/healthcheck を指定すると、そのパスを含むすべての API 呼び出し /healthcheck はダッシュボードに 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

Cloud Router の背後にある 企業のファイアウォール

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

バージョン 3.1.2 で追加されました。

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

  1. 環境変数を設定する HTTP_PROXYHTTPS_PROXYNO_PROXY。これらの 変数は、HTTP プロキシ サーバーとの通信に使用する各 HTTP プロキシのホストを制御します。 Apigee Edge、または Apigee Edge との通信を処理しないホスト。 次に例を示します。
    export HTTP_PROXY='http://localhost:3786'
    export HTTPS_PROXY='https://localhost:3786'
    export NO_PROXY='localhost,localhost:8080'

    NO_PROXY には、Edge AppSheet が処理するドメインのカンマ区切りリストを指定できます。 にプロキシしないようにします。

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

  2. Edge Appliance を再起動します。

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

バージョン 3.1.2 で追加されました。

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

  1. Microgateway 構成ファイルに次の構成を追加します。
    edgemicro:
      proxy:
        tunnel: true | false
        url: proxy_url
        bypass: target_host # target hosts to bypass the proxy.
        enabled: true | false

    ここで

    • tunnel: (省略可)true の場合、Edge マネージャーは HTTP CONNECT メソッドを使用して HTTP をトンネリングします。 1 つの TCP 接続を介して複数のリクエストを実行できます。(環境変数が 以下で説明しますが、 TLS が有効になっている必要があります)。デフォルト: false
    • url: HTTP プロキシの URL。
    • bypass: (省略可)対象となる 1 つ以上のターゲット ホスト URL をカンマ区切りで指定します。 HTTP プロキシをバイパスしますこのプロパティが設定されていない場合は、NO_PROXY を使用する 環境変数を使用して、バイパスするターゲット URL を指定します。
    • enabled: true で proxy.url が設定されている場合、HTTP プロキシに proxy.url 値を使用します。 true で proxy.url が設定されていない場合、HTTP プロキシで指定されたプロキシを使用します。 環境変数 HTTP_PROXYHTTPS_PROXY を使用します。詳細については、 Apigee Edge との通信に HTTP プロキシを使用する

    次に例を示します。

    edgemicro:
      proxy:
        tunnel: true
        url: 'http://localhost:3786'
        bypass: 'localhost','localhost:8080' # target hosts to bypass the proxy.
        enabled: true

  2. Edge Appliance を再起動します。

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

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

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

JWT 鍵のローテーション

JWT を最初に生成した後、アプリケーションの認証情報を Edge 暗号化 KVM に格納されている公開鍵/秘密鍵のペア。新しい鍵を生成するプロセス 鍵のローテーションと呼ばれます。

Edge AppSheet による 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 に格納されている公開鍵/秘密鍵のペア。新しい鍵を生成するプロセス 鍵のローテーションと呼ばれます。鍵をローテーションすると、新しい秘密鍵と公開鍵のペアが生成され、 「microgateway」に格納されますApigee Edge 組織/環境での KVM。また、 古い公開鍵は、元の鍵 ID 値と一緒に保持されます。

JWT を生成するために、Edge は暗号化された KVM に格納されている情報を使用します。 最初の設定(構成)時に microgateway という KVM が作成され、キーが入力されました 説明します。KVM 内の鍵は、JWT の署名と暗号化に使用されます。

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

  • private_key - 署名に使用された最新の(最近作成された)RSA 秘密鍵 JWT。

  • public_key - JWT の検証に使用される最新の(最近作成された)証明書 秘密鍵で署名されます。

  • private_key_kid - 最新の(最近作成された)秘密鍵 ID。この鍵 ID private_key の値に関連付けられ、鍵のローテーションをサポートするために使用されます。

  • public_key1_kid - 最新の(最近作成された)公開鍵 ID。このキーは、 関連付けられており、鍵のローテーションをサポートするために使用されます。この値 同じです。

  • public_key1 - 最新の(最近作成された)公開鍵。

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

  • public_key2_kid - 古い公開鍵の ID。このキーは Kubernetes の public_key2 の値が含まれ、鍵のローテーションをサポートするために使用されます。

  • public_key2 - 古い公開鍵。

検証のために提示された JWT は、新しい公開鍵を使用して検証されます。条件 検証に失敗した場合、JWT が期限切れになるまで(token_expiry* の間隔、デフォルトは 30 分)は古い公開鍵が使用されます。イン こうすると、その部分を「回転」API トラフィックを直ちに中断することなく使用できます。

鍵のローテーション方法

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

  1. KVM をアップグレードするには、edgemicro upgradekvm コマンドを使用します。詳細情報 については、アップグレード KVM で接続します。この手順は 1 回だけ行います。
  2. edgemicro-oauth プロキシをアップグレードするには、edgemicro upgradeauth コマンドを使用します。 このコマンドの実行の詳細については、をご覧ください。 Edgemicro-auth プロキシのアップグレード。この手順は 1 回だけ行います。
  3. ~/.edgemicro/org-env-config.yaml ファイルに次の行を追加します。ここで、 には、マイクロゲートウェイで使用する構成と同じ組織と環境を指定します。
    jwk_public_keys: 'https://$ORG-$ENV.apigee.net/edgemicro-auth/jwkPublicKeys'
  4. 鍵のローテーション コマンドを実行して、鍵をローテーションします。このコマンドの詳細については、以下をご覧ください。 鍵のローテーション

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

    例:

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

鍵のローテーション後、Edge は複数の鍵を Edge Appliance に返します。注: 次の例では、各キーに固有の「kid」が(キー ID)値。その後、マイクロサービスはこれらを使用して 認証トークンを検証できます。トークンの検証で不合格だった場合、マイクロゲートウェイは 鍵セットに古い鍵があるかどうかを確認し、その鍵を試します。<ph type="x-smartling-void-element"><br></ph> 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"
    }
  ]
}

「以前」ルールの遅延

バージョン 3.1.5 以前では、rotatekey コマンドによって生成された新しい秘密鍵は すぐに有効になり、生成された新しいトークンは新しい秘密鍵で署名されました。ただし、 新しい公開鍵は、(デフォルト)10 分ごとにのみ、Edge API インスタンスで利用可能になりました。 ゲートウェイの構成が更新された日時。トークン署名とトークンの署名と 最新の鍵で署名されたトークンは、次の日付になるまで拒否されます。 すべてのインスタンスが最新の公開鍵を受信しました。

複数のマイクロゲートウェイ インスタンスが存在する場合、公開鍵の遅延により、 ステータス 403 の断続的なランタイム エラーが発生する。これは、トークンの検証が すべてのインスタンスが更新されるまで別のインスタンスで失敗します。

バージョン 3.1.6 以降では、rotatekey コマンドの新しいフラグを使用して、新しい遅延時間 秘密鍵が有効になり、すべてのマイクロサービス インスタンスが更新される 新しい公開鍵を受け取ります。新しいフラグは --nbf です。これは「以前にない」という意味です。 このフラグには整数値(遅延時間(分))を指定できます。

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

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

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

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

デフォルトでは、Edge AppSheet は Edge 組織内のすべてのプロキシをダウンロードします。 名前の接頭辞「edgemicro_」で始まる必要があります。このデフォルトを変更して、プロキシをダウンロードできます。 名前にパターンが一致するものを見つけます。

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

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

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

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

デバッガへの接続

node-inspector などのデバッガを使用して Edge Appliance を実行できます。これは カスタムプラグインのトラブルシューティングとデバッグです

  1. Edge Appliance をデバッグモードで再起動します。これを行うには、DEBUG=*start コマンドの先頭:
    DEBUG=* edgemicro start -o $ORG -e $ENV -k $KEY -s $SECRET

    デバッグ出力をファイルに送信するには、次のコマンドを使用します。

    export DEBUG=* nohup edgemicro start \
    -o $ORG -e $ENV -k $KEY -s $SECRET 2>&1 | tee /tmp/file.log

  2. デバッガを起動し、デバッグ プロセスのポート番号をリッスンするように設定します。
  3. これで、Edge Appliance のコードのステップ実行、ブレークポイントの設定、式の監視、 といった具合です

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

ログファイルの確認

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

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

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

鍵のキャッシュ保存

API キーは、署名なしトークンと交換され、キャッシュに保存されます。キャッシュへの保存は、 Edge への受信リクエストの 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 Appliance

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

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

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

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

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

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

アクセス トークンの取得方法

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

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

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

URL の組織名と環境名は実際のものに差し替えてください。 Apigee のデベロッパー アプリから取得したコンシューマ ID とコンシューマ シークレットの値に置き換えます 本文パラメータ client_idclient_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: OAuth 2.0 Authorization Framework(OAuth 2.0 認可フレームワーク)。

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

出力例

API から JSON レスポンスが返されます。tokenaccess_token プロパティ。どちらでもかまいません。expires_in は、 秒単位で指定された整数値。
{
"token": "eyJraWQiOiIxIiwidHlwIjoi",
"access_token": "eyJraWQiOiIxIiwid",
"token_type": "bearer",
"expires_in": 1799
}

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

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

  1. /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"
    }
  2. これで、以下を呼び出して更新トークンを使用し、新しいアクセス トークンを取得できるようになりました。 同じ 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"
        }

Forever モニタリング

Forever は、このアプリケーションの プロセスが停止した場合やエラーが発生した場合は、Node.js アプリを自動的に再起動します。エッジ AppSheet には forever.json ファイルがあり、このファイルを構成して、 その間隔と再起動間隔を指定します。このファイルでは、 Forever を管理する forever-monitor という Forever サービス できます。

forever.json ファイルは Edge AppSheet のルート インストールにあります されます。<ph type="x-smartling-placeholder"></ph>をご覧ください。 Edge Appliance がインストールされている場所を確認します。構成オプションについて詳しくは、このモジュールの forever-monitor のドキュメントをご覧ください。

edgemicro forever コマンドには、コマンドのロケーションを指定するためのフラグが含まれています。 forever.json ファイル(-f フラグ)、Forever モニタリングを開始/停止する (-a フラグ)。例:

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

詳細については、CLI リファレンスの Forever モニタリングをご覧ください。

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

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

例:

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 Appliance で使用される TCP 接続。

デフォルトでは、TCP 接続は Nagle アルゴリズムを使用して、データを送信する前にバッファリングします。nodelaytrue に設定する。 この動作を無効にする(データは、 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 Appliance をスタンドアロン モードで実行する

任意のネットワークから完全に切断された Edge Apigee Edge の依存関係。スタンドアロン モードと呼ばれるこのシナリオでは、Edge Apigee を実行してテストできます。 インターネット接続がなくても 利用できます

次の機能は接続が必要なため、スタンドアロン モードでは動作しません 次の操作を行います。

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

一方、カスタム プラグインと Spike Arrest は、 Apigee Edge への接続が必要です。さらに、extauth という新しいプラグインを使用すると、 スタンドアロン モードで、JWT を使用してマイクロゲートウェイへの API 呼び出しを認可します。

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

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

  1. $HOME/.edgemicro/$ORG-$ENV-config.yaml という名前の構成ファイルを作成します。

    例:

    vi $HOME/.edgemicro/foo-bar-config.yaml
  2. このファイルに次のコードを貼り付けます。
    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
  3. 次の環境変数を値「1」でエクスポートします。
    export EDGEMICRO_LOCAL=1
  4. 次の start コマンドを実行します。ここでは、インスタンスをインスタンス化するための値を指定します。 ローカル プロキシ:
    edgemicro start -o $ORG -e $ENV -a $LOCAL_PROXY_NAME \
      -v $LOCAL_PROXY_VERSION -t $TARGET_URL -b $BASE_PATH

    ここで

    • $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 /
  5. 構成をテストします。
    curl http://localhost:8000/echo  { "error" : "missing_authorization" }

    extauth プラグインは foo-bar-config.yaml ファイルにあるため、 「missing_authorization」とエラーが発生します。このプラグインは、Authorization に存在する必要がある JWT を検証します ヘッダーがあります。次のセクションでは、API 呼び出しを許可する JWT を取得します。 エラーは発生しません。

例: 認証トークンの取得

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

edgemicro-auth/jwkPublicKeys エンドポイントを使用してトークンを取得する手順は次のとおりです。

  1. 標準的な標準的な 設定と構成を行い、edgemicro-auth プロキシをデプロイします。 Apigee Edge 上の組織/環境にデプロイします。すでにこの手順を行った場合は、この手順を繰り返す必要はありません。
  2. Edge Appliance を Apigee Cloud にデプロイした場合は、このエンドポイントから JWT を取得できるようにインターネットに接続する必要があります。
  3. Edge Appliance を停止します。
    edgemicro stop
  4. 先ほど作成した構成ファイル($HOME/.edgemicro/orgenv-config.yaml)で、 extauth:publickey_url を指す 属性を Apigee Edge 組織/環境の edgemicro-auth/jwkPublicKeys エンドポイントに追加します。次に例を示します。
    extauth:
      publickey_url: 'https://your_org-your_env.apigee.net/edgemicro-auth/jwkPublicKeys'
  5. 構成ファイル名で使用した組織名/環境名を使用して、以前と同様に Edge Appliance を再起動します。次に例を示します。
    edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
  6. 認可エンドポイントから JWT トークンを取得します。edgemicro-auth/jwkPublicKeys を使用しているため 次の CLI コマンドを使用できます。

Edge AppSheet 用の JWT を生成するには、edgemicro token コマンドを使用するか、 API例:

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

ここで

  • your_org は、前に割り当てた 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 API にプロキシ サーバーを microgateway 対応プロキシ Apigee Edge にデプロイされます代わりに「ローカル プロキシ」を構成し、提供することで、 ローカル プロキシ名、ベースパス、ターゲット URL を 起動します。そして、マイクロサービスへの API 呼び出しがターゲット ローカル プロキシの URL。その他の点については、ローカル プロキシ モードは、 初期化します。認証の仕組みは アラートや割り当ての適用、カスタム プラグインなどに利用できます。

ユースケースと例

ローカル プロキシモードは、単一のプロキシを 1 つの Edge Appliance に関連付けるだけでよい場合に便利です。 作成します。たとえば、Pod をサイドカー プロキシとして Kubernetes に挿入すると、 2 つのマイクロサービスがそれぞれ 1 つの Pod で実行され、各マイクロサービスが コンパニオンサービスから分離できます次の図は、Edge が Google Cloud の Dataproc は、Kubernetes クラスタでサイドカー プロキシとして機能します。各マイクロゲートウェイインスタンスは 次のように、コンパニオン サービスの 1 つのエンドポイントにのみ接続します。

サイドカーとしての Edgemicro

このスタイルのアーキテクチャの利点は、Edge Gateway が API を コンテナ環境にデプロイされた個々のサービスを管理する 作成します。

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

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

  1. edgemicro init を実行して、ローカルの構成環境を 通常の Edge Apigee 設定の場合とまったく同じです。関連項目 Edge AppSheet を構成します。
  2. 一般的な Edge AppSheet 設定の場合と同様に、edgemicro configure を実行します。 示されます。次に例を示します。
    edgemicro configure -o your_org -e your_env -u your_apigee_username

    このコマンドは、edgemicro-auth ポリシーを Edge にデプロイし、キーを返します。 と Secret を指定します。詳しくは、 Edge AppSheet を構成します。

  3. Apigee Edge で、次の必須構成を使用して API プロダクトを作成します。 (必要に応じて他のすべての構成を管理できます)。 <ph type="x-smartling-placeholder">
      </ph>
    • プロダクトに edgemicro-auth プロキシを追加する必要があります。このプロキシ edgemicro configure を実行したときに、自動的にデプロイされました。
    • リソースパスを指定する必要があります。Apigee では、このパスを 商品: /**。詳細については、リソースパスの動作を構成するをご覧ください。関連情報: API の作成 製品をご覧ください。
  4. Apigee Edge でデベロッパーを作成します。または、既存のデベロッパーを使用することもできます。 願っています詳細については、Edge 管理 UI を使用してデベロッパーを追加するをご覧ください。

  5. Apigee Edge で、デベロッパー アプリを作成します。API プロダクトを追加するには、 追加します。詳細については、Edge へのアプリの登録 できます
  6. Edge Appliance がインストールされているマシンで、次のものをエクスポートします。 値を「1」に設定します。
    export EDGEMICRO_LOCAL_PROXY=1
  7. 次の 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 の使用

このセクションでは、Synchronizer の使用方法について説明します。Synchronizer は、 エッジ マイクロサービスの復元性を強化するために、 Apigee Edge から構成データを取得して、ローカルの Redis データベースに書き込みます。あり Synchronizer インスタンス、別のノードで実行されている他の Edge Apigee インスタンス このデータベースから直接構成を取得できます。

現在、syncrhonizer 機能は Redis 5.0.x で動作します。

Synchronizer とは

Synchronizer は、Edge Appliance に一定の復元力を提供します。これにより、 すべてのインスタンスが同じ構成を使用し、 インターネット障害が発生した場合に、Edge Datalab インスタンスを起動して実行できます。 確認します。

デフォルトでは、Apigee Edge のインスタンスは、次の目的で Apigee Edge と通信できる必要があります。 API プロキシや API プロダクトの構成などの構成データを取得して更新する。 Edge とのインターネット接続が中断しても、マイクロサービス インスタンスは引き続き 最新の構成データがキャッシュに保存されるためです。ただし 新しいマイクロゲートウェイインスタンスは 明確な接続がないと起動できませんさらに、インターネットから 構成で 1 つ以上のマイクロサービス インスタンスが実行される 他のインスタンスと同期されていない情報を取得できます。

Edge Scanner Synchronizer は、Edge API の代替メカニズムを提供します。 API プロキシ トラフィックの起動と処理に必要な構成データを取得できます。 Apigee Edge の呼び出しから取得される構成データには、jwk_public_keys 呼び出し、 jwt_public_key 呼び出し、ブートストラップ呼び出し、API プロダクト呼び出しです。 Synchronizer は、すべての Edge AppSheet に対して可能にします。 異なるノードで実行中のインスタンスを適切に起動し、再起動しても Edge Appliance と Apigee Edge の間のインターネット接続が中断されます。

Synchronizer は、特別に構成された Edge Appliance のインスタンスです。唯一の目的 Apigee Edge をポーリングし(タイミングは構成可能)、構成データを取得し、 ローカルの Redis データベースに書き込みますSynchronizer インスタンス自体は API プロキシを処理できません トラフィックです。異なるノードで実行されている Edge Appliance の他のインスタンスは、 Apigee ではなく Redis データベースから構成データを取得するように構成されている 。すべての Apigee インスタンスは、構成データをローカル インターネットにあっても API リクエストを起動して処理できます。 困難です。

Synchronizer インスタンスの構成

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 データベースのパスワード。

最後に、構成ファイルを保存し、Edge AppSheet インスタンスを起動します。新しい Apigee Edge をポーリングし、ダウンロードした構成データを Redis データベースに保存する。

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

Synchronizer が動作している状態で、追加の Edge Controls ノードを構成できます。 API プロキシ トラフィックを処理する通常のマイクロゲートウェイ インスタンスを実行します。ただし、 構成データを Redis データベースからではなく、 Apigee Edge

追加する各 Edge Appliance ノードに次の構成を追加します。 org-env/config.yaml ファイル。なお、synchronizerMode プロパティが 0 に設定されていることを確認します。このプロパティにより、インスタンスを通常の動作として動作するように設定できます。 API プロキシ トラフィックを処理し、そのインスタンスによって取得される 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 Scanner は標準モードで動作します。

1 の場合、Edge AppSheet インスタンスを起動して、Synchronizer として動作します。この モードの場合、インスタンスは Apigee Edge から構成データを pull して、 ローカルの Redis データベースに 書き込まれますこのインスタンスは API プロキシ リクエストを処理できません。 Apigee Edge をポーリングして構成データをポーリングし、それをローカル データベースです次に、他のマイクロサービス インスタンスがデータベースから読み取るように構成する必要があります。

edge_config.redisBasedConfigCache true または false true の場合、Edge Dataproc インスタンスは、インスタンスから構成データを取得します。 Apigee Edge からではなく Redis データベースを使用します。Redis データベースは同じである必要があります Synchronizer が書き込み先として構成されていることがわかります。Redis データベースが利用できない場合や、 データベースが空の場合、Microgateway は既存の cache-config.yaml を探します。 構成ファイルを定義します。

false(デフォルト)の場合、Edge マネージャー インスタンスは構成データを取得します。 Apigee Edge を通常どおり起動します。

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

プラグインの除外 URL の設定

プラグインの処理をスキップするように、マイクロゲートウェイを設定できます。 できます。これらの「除外」やグローバル URL(すべてのプラグイン) 特定のプラグインだけの場合もあります

次に例を示します。

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

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

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

環境変数は、構成内でタグを使用して指定できます。 表示されます。指定した環境変数のタグが実際の環境に置き換えられます。 使用します。交換品はメモリにのみ保存され、元の場所には保存されません キャッシュに保存することもできます。

この例では、属性 keyTARGETS_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> タグを使用してブール値( つまり false 値)を返します。

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