このページは Cloud Translation API によって翻訳されました。

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

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

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

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

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

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

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

次の npm コマンドを実行して、Edge の最新バージョンにアップグレードします。 Dataproc:
```
npm upgrade edgemicro -g
```
Edge Appliance の特定のバージョンをインストールするには、バージョンを指定する必要があります。 number を指定します。たとえば、バージョン 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 AppSheet インスタンスのデフォルト構成ファイル
実行中のインスタンスの動的構成ファイル

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

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

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

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

ここで、prefix は npm 接頭辞ディレクトリです。<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.yaml（org と env は Apigee Edge の組織名と環境名。このファイルを使用して、ダウンタイムなしで再読み込みできます。たとえば、プラグインを追加して構成する場合、以下で説明するように、ダウンタイムを発生させることなく構成を再読み込みできます。

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

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 が停止した場合:

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 を構成するには、次の操作を行います。

openssl ユーティリティまたは任意の方法で、SSL 証明書と鍵を生成または取得します。

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

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 を確認するサービス。

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

ログファイルの管理

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 では次の方法を採用することをおすすめします。プラクティス:

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

ログファイルの命名規則

各 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

Windows では、SET DEBUG=* を使用します。

「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">
- level: （デフォルト: error） <ph type="x-smartling-placeholder">
  - info - （推奨）インスタンスです。
  - warn - 警告メッセージのみを記録します。
  - error - エラーメッセージのみを記録します。
  - debug - デバッグメッセージを info、warn、エラーメッセージとともにログに記録します。
  - trace - エラーのトレース情報とともに info、warn、エラーメッセージを記録します。
  - none - ログファイルを作成しません。
- dir: （デフォルト: /var/tmp）ログファイルが保存されるディレクトリあります。
- stats_log_interval: （デフォルト: 60）統計情報がいつ作成されたかを示す間隔 api ログファイルに書き込まれます。
- rotate_interval: （デフォルト: 24）ログファイルが処理される間隔（時間単位）回転しました。

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

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
```
enableAnalytics が false に設定されているにもかかわらず、Edge が Dataproc が指標プラグインを使用して起動したら、分析プラグインが通常どおり動作します。これは、指標プラグインが機能するために分析プラグインを必要とするためです。詳細については、指標プラグインについては、Edge Scanner v1.3.6 をご覧ください。リリースノートをご覧ください。

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 で追加）。
allowOAuthOnly と allowAPIKeyOnly を true に設定します。デフォルトの設定では、両方のフラグが false に設定されています。（下位互換性のため）。
gracePeriod -- このパラメータを使用すると、システムクロックと、Not Before（nbf）または Issued At（iat）時刻との間の差異 JWT 認証トークンで指定されているとおりです。このパラメータを、許可する秒数に設定します不一致が生じることもあります（2.5.7 で追加）。

プラグイン固有属性

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

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

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

         ]
      }
   ]
}

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

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

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

例:

<?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 プロキシを使用するには、次の操作を行います。次のとおりです。

環境変数を設定する HTTP_PROXY、HTTPS_PROXY、NO_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 をご覧ください。
Edge Appliance を再起動します。

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

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

Edge Appliance とバックエンドターゲット間の通信に 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 マネージャーは 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_PROXY と HTTPS_PROXY を使用します。詳細については、 Apigee Edge との通信に HTTP プロキシを使用する。
次に例を示します。
```
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 Gateway はターゲット通信用の HTTP プロキシ。
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 トラフィックを直ちに中断することなく使用できます。

鍵のローテーション方法

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

KVM をアップグレードするには、edgemicro upgradekvm コマンドを使用します。詳細情報については、アップグレード KVM で接続します。この手順は 1 回だけ行います。
edgemicro-oauth プロキシをアップグレードするには、edgemicro upgradeauth コマンドを使用します。このコマンドの実行の詳細については、をご覧ください。 Edgemicro-auth プロキシのアップグレード。この手順は 1 回だけ行います。
~/.edgemicro/org-env-config.yaml ファイルに次の行を追加します。ここで、には、マイクロゲートウェイで使用する構成と同じ組織と環境を指定します。
```
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 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_」で始まる必要があります。このデフォルトを変更して、プロキシをダウンロードできます。名前にパターンが一致するものを見つけます。

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 マネージャーはこのプロダクトをサポートしています。できます。

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

デバッガへの接続

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

Edge Appliance をデバッグモードで再起動します。これを行うには、DEBUG=* を start コマンドの先頭:
```
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 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_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: 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 レスポンスが返されます。token と access_token プロパティ。どちらでもかまいません。expires_in は、秒単位で指定された整数値。

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

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

更新トークンを取得するには、次のトークンの /token エンドポイントに対して API 呼び出しを行います。 edgemicro-auth プロキシ。この 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"
    }

Forever モニタリング

削除: この CLI 機能は Edge AppSheet のバージョンで削除されました。 3.3.3.マイページ forever-monitor を PM2 に置き換えることができます。詳細については、Apigee API を使用してコミュニティ投稿: Edgemicro + PM2: サービスとして Edgemicro を開始する。 Edge AppSheet 3.3.3 リリースノートもご覧ください。

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

複数の 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 アルゴリズムを使用して、データを送信する前にバッファリングします。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 Appliance をスタンドアロンモードで実行する

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

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

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

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

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

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

$HOME/.edgemicro/$ORG-$ENV-config.yaml という名前の構成ファイルを作成します。
ファイル名には、$ORG と $ENV に任意の値を使用できます。 org/env の組み合わせは、Edge が次のタイミングでファイルを検出できるようにする、単なる規則です。起動します。

例:
```
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 は「組織」です。構成ファイル名で使用した名前を使用します。
- $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」とエラーが発生します。このプラグインは、Authorization に存在する必要がある JWT を検証しますヘッダーがあります。次のセクションでは、API 呼び出しを許可する JWT を取得します。エラーは発生しません。

例: 認証トークンの取得

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

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

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

標準的な標準的な設定と構成を行い、edgemicro-auth プロキシをデプロイします。 Apigee Edge 上の組織/環境にデプロイします。すでにこの手順を行った場合は、この手順を繰り返す必要はありません。
Edge Appliance を Apigee Cloud にデプロイした場合は、このエンドポイントから JWT を取得できるようにインターネットに接続する必要があります。
Edge Appliance を停止します。
```
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 Appliance を再起動します。次に例を示します。
```
edgemicro start -o foo -e bar -a proxy1 -v 1 -t http://mocktarget.apigee.net -b /
```
認可エンドポイントから JWT トークンを取得します。edgemicro-auth/jwkPublicKeys を使用しているため次の CLI コマンドを使用できます。
この手順では、インターネット接続が必要です。次のコマンドは、トークンを取得できます。この手順を行うには、Apigee 組織として標準の Edge AppSheet の設定と構成を実施済みである。この手順を行った後は、Google Compute Engine やできます。トークンは、有効期限が切れるまでスタンドアロンモードで引き続き機能します。

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。その他の点については、ローカルプロキシモードは、初期化します。認証の仕組みはアラートや割り当ての適用、カスタムプラグインなどに利用できます。

ローカルモードと通常の Edge Appliance の 2 つの重要な違い（1）ローカルモードでは、マイクロゲートウェイ対応の IP アドレスを作成する必要は Apigee Edge 上のプロキシ、および（2）Edge で API プロダクトを作成する場合、そのプロキシにはプロキシを 1 つだけ追加する必要があります。 edgemicro-auth プロキシ。このプロダクトに他のプロキシを追加する必要はありません。

ユースケースと例

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

サイドカーとしての Edgemicro

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

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

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

edgemicro init を実行して、ローカルの構成環境を通常の Edge Apigee 設定の場合とまったく同じです。関連項目 Edge AppSheet を構成します。
一般的な Edge AppSheet 設定の場合と同様に、edgemicro configure を実行します。示されます。次に例を示します。
```
edgemicro configure -o your_org -e your_env -u your_apigee_username
```
このコマンドは、edgemicro-auth ポリシーを Edge にデプロイし、キーを返します。と Secret を指定します。詳しくは、 Edge AppSheet を構成します。
Apigee Edge で、次の必須構成を使用して API プロダクトを作成します。（必要に応じて他のすべての構成を管理できます）。 <ph type="x-smartling-placeholder">
- プロダクトに edgemicro-auth プロキシを追加する必要があります。このプロキシ edgemicro configure を実行したときに、自動的にデプロイされました。
- リソースパスを指定する必要があります。Apigee では、このパスを商品: /**。詳細については、リソースパスの動作を構成するをご覧ください。関連情報: API の作成製品をご覧ください。
Apigee Edge でデベロッパーを作成します。または、既存のデベロッパーを使用することもできます。願っています詳細については、Edge 管理 UI を使用してデベロッパーを追加するをご覧ください。
Apigee Edge で、デベロッパーアプリを作成します。API プロダクトを追加するには、追加します。詳細については、Edge へのアプリの登録できます。
Edge Appliance がインストールされているマシンで、次のものをエクスポートします。値を「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 の使用

このセクションでは、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`	データベースのパスワード。

環境変数 EDGEMICRO_REDIS_PASSWORD を使用すると、 edgemicro.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 するポーリング間隔を指定します。

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 については、プラグインはスキップされます。

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> タグを使用してブール値（つまり false 値）を返します。

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

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

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

構成の変更

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

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

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

環境変数の設定

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

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

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

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

ログファイルの管理

ログファイルの保存場所

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

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

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

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

ログファイルの厳格な権限の緩和方法

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

ログファイルの命名規則

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

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

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

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

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

エラー メッセージ

Edge AppSheet 構成リファレンス

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

Edge_config 属性

Edgemicro の属性

ヘッダー属性

OAuth 属性

プラグイン固有 属性

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

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

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

分析の push 頻度の構成

分析データのマスキング

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

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

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

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

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

JWT 鍵のローテーション

Edge AppSheet による JWT の使用方法

鍵のローテーションとは

鍵のローテーション方法

「以前」ルールの遅延

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

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

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

デバッガへの接続

ログファイルの確認

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

鍵のキャッシュ保存

API キーの使用

API キー名を設定する

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

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

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

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

Forever モニタリング

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

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

Edge Appliance をスタンドアロン モードで実行する

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

例: 認証トークンの取得

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

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

ユースケースと例

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

構成のテスト

Synchronizer の使用

Synchronizer とは

Synchronizer インスタンスの構成

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

構成プロパティ

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

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

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

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

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

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

エラーメッセージ

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

プラグイン固有属性

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

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

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

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

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

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

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

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

Edge Appliance をスタンドアロンモードで実行する

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

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