# mulesoft Omni Gateway (gateway) - Full Documentation # A2A エージェントカードポリシー

ポリシー名

A2A エージェントカード

概要

ゲートウェイの公開 URL と一致するようにエージェントカード URL を書き換える

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
このポリシーでは、Agent2Agent プロトコル (A2A) バージョン v0.2.3 以前がサポートされます。A2A バージョンについての詳細は、 「A2A Releases (A2A リリース)」​を参照してください。
## [](#概要)概要 A2A エージェントカードポリシーでは、公開される URL がバックエンドサービスを直接参照するのではなく Flex Gateway A2A サーバーインスタンスの公開エンドポイントを参照するように A2A エージェントカードの応答の URL を書き換えます。これにより、すべてのクライアント要求が Flex Gateway を通じてルーティングされるようになり、セキュリティやアクセス制御を適用すると同時にバックエンドリソースへの直接アクセスを防止できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A エージェントカードポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Consumer URL (コンシューマー URL)

JSON-RPC 要求が送信されるエージェントの A2A サービスのコンシューマー URL。
コンシューマー URL が設定されていない場合、サーバーインスタンスの公開エンドポイントが使用されます。

Card Path (カードパス)

エージェントがカードを提示するパス。
# A2A エージェントカードポリシー

ポリシー名

A2A エージェントカード

概要

ゲートウェイの公開 URL と一致するようにエージェントカード URL を書き換える

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
## [](#概要)概要 A2A エージェントカードポリシーでは、公開される URL がバックエンドサービスを直接参照するのではなく Flex Gateway A2A サーバーインスタンスの公開エンドポイントを参照するように A2A エージェントカードの応答の URL を書き換えます。これにより、すべてのクライアント要求が Flex Gateway を通じてルーティングされるようになり、セキュリティやアクセス制御を適用すると同時にバックエンドリソースへの直接アクセスを防止できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A エージェントカードポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Consumer URL (コンシューマー URL)

JSON-RPC 要求が送信されるエージェントの A2A サービスのコンシューマー URL。
コンシューマー URL が設定されていない場合、サーバーインスタンスの公開エンドポイントが使用されます。

Card Path (カードパス)

エージェントがカードを提示するパス。
# A2A スキーマ検証ポリシー

ポリシー名

A2A スキーマ検証

概要

エージェント要求を検証し、A2A 仕様に準拠していることを確認する

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
このポリシーでは、Agent2Agent プロトコル (A2A) バージョン v0.2.3 以前がサポートされます。A2A バージョンについての詳細は、 「A2A Releases (A2A リリース)」​を参照してください。
## [](#概要)概要 A2A スキーマ検証ポリシーでは、A2A サーバーへのすべての要求が A2A スキーマに準拠していることを検証します。検証に失敗すると、ポリシー違反を報告します。 このポリシーの設定パラメーターはありません。 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A スキーマ検証ポリシーはローカルモードではサポートされません。 # A2A スキーマ検証ポリシー

ポリシー名

A2A スキーマ検証

概要

エージェント要求を検証し、A2A 仕様に準拠していることを確認する

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
## [](#概要)概要 A2A スキーマ検証ポリシーでは、A2A サーバーへのすべての要求が A2A スキーマに準拠していることを検証します。検証に失敗すると、ポリシー違反を報告します。 このポリシーの設定パラメーターはありません。 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A スキーマ検証ポリシーはローカルモードではサポートされません。 # A2A プロンプトデコレーターポリシー

ポリシー名

A2A プロンプトデコレーター

概要

プロンプトをコンテキスト情報でデコレーションします

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

このポリシーの戻りコードは存在しません。
このポリシーでは、Agent2Agent プロトコル (A2A) バージョン v0.2.3 以前がサポートされます。A2A バージョンについての詳細は、 「A2A Releases (A2A リリース)」​を参照してください。
## [](#概要)概要 A2A プロンプトデコレーターポリシーでは、アップストリームサーバーに送信される前に指定されたプロンプトに追加のコンテンツを挿入します。挿入するコンテンツは DataWeave 文字列パラメーターとして、またはファイルを参照する方法で指定できます。さらに、DataWeave 式を使用してプロンプトをデコレーションする要求を絞り込むことができます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A プロンプトデコレーターポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Text Decorators (テキストデコレーター)

プロンプトに追加するテキストデコレーションのリスト。

Prompt Text (プロンプトテキスト)

要求に挿入するプロンプトテキストを生成する DataWeave 式。例: #['Use Imperial metric units']​。

Condition (条件)

デコレーションするプロンプトを絞り込む DataWeave 式。例: #[attributes.headers['id']==1]​。

File Decorators (ファイルデコレーター)

プロンプトに追加するファイルデコレーションのリスト。

Condition (条件)

デコレーションするプロンプトを絞り込む DataWeave 式。例: #[attributes.headers['id']==1]​。

File Name (ファイル名)

ファイル名を含む DataWeave 式。例: #['Decorator name']​。

File Mime Type (ファイル MIME タイプ)

挿入するファイルの MIME タイプを含む DataWeave 式。例: #['application/json']​。

File Source (ファイルソース)

ファイルコンテンツが base64 でエンコードされたデータの場合は ​[Base64]​ を選択し、ファイルコンテンツが外部ファイルに対する URL の場合は ​[Uri]​ を選択します。

Content (コンテンツ)

base64 でエンコードされたファイルコンテンツまたはコンテンツファイルをダウンロードするための URL を含む DataWeave 式。例: #['https://domain/file-location'] や #['QmFzZTY0IGVuY29kZWQgZmlsZSBjb250ZW50']。
# A2A プロンプトデコレーターポリシー

ポリシー名

A2A プロンプトデコレーター

概要

プロンプトをコンテキスト情報でデコレーションします

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 A2A プロンプトデコレーターポリシーでは、アップストリームサーバーに送信される前に指定されたプロンプトに追加のコンテンツを挿入します。挿入するコンテンツは DataWeave 文字列パラメーターとして、またはファイルを参照する方法で指定できます。さらに、DataWeave 式を使用してプロンプトをデコレーションする要求を絞り込むことができます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A プロンプトデコレーターポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Text Decorators (テキストデコレーター)

プロンプトに追加するテキストデコレーションのリスト。

Prompt Text (プロンプトテキスト)

要求に挿入するプロンプトテキストを生成する DataWeave 式。例: #['Use Imperial metric units']​。

Condition (条件)

デコレーションするプロンプトを絞り込む DataWeave 式。例: #[attributes.headers['id']==1]​。

File Decorators (ファイルデコレーター)

プロンプトに追加するファイルデコレーションのリスト。

Condition (条件)

デコレーションするプロンプトを絞り込む DataWeave 式。例: #[attributes.headers['id']==1]​。

File Name (ファイル名)

ファイル名を含む DataWeave 式。例: #['Decorator name']​。

File Mime Type (ファイル MIME タイプ)

挿入するファイルの MIME タイプを含む DataWeave 式。例: #['application/json']​。

File Source (ファイルソース)

ファイルコンテンツが base64 でエンコードされたデータの場合は ​[Base64]​ を選択し、ファイルコンテンツが外部ファイルに対する URL の場合は ​[Uri]​ を選択します。

Content (コンテンツ)

base64 でエンコードされたファイルコンテンツまたはコンテンツファイルをダウンロードするための URL を含む DataWeave 式。例: #['https://domain/file-location'] や #['QmFzZTY0IGVuY29kZWQgZmlsZSBjb250ZW50']。
# A2A 個人情報 (PII) ディテクターポリシー

ポリシー名

A2A PII ディテクターポリシー

概要

エージェントに送信される要求で個人情報 (PII) を検出します

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
このポリシーでは、Agent2Agent プロトコル (A2A) バージョン v0.2.3 以前がサポートされます。A2A バージョンについての詳細は、 「A2A Releases (A2A リリース)」​を参照してください。
## [](#概要)概要 A2A PII ディテクターポリシーでは、エージェントに送信される要求で個人情報 (PII) を検出します。PII が検出された場合、要求を記録またはブロックできます。PII が検出された場合、ポリシー違反は必ず報告されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A PII ディテクターポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Entities (エンティティ)

検出する PII の種別を定義する配列。複数の PII 種別を選択できます。サポートされている値は、​Email (メール)​、​US SSN​、​Credit Card (クレジットカード)​、​Phone Number (電話番号)​ です。
詳細は、​PII Types (PII 種別)​を参照してください。

アクション

PII が検出された場合に実行するアクション。サポートされている値は、​Log (記録)​ または ​Block (ブロック)​ です。
### [](#pii-types)PII Types (PII 種別) A2A PII ディテクターポリシーを設定する際に、検出する PII の種別を選択できます。 次の表で、このポリシーで検出できる PII の種別について説明します。
PII 種別 説明

Email (メール)

User.Name+tag@example.com​ などの標準的なメールアドレス

US SSN

標準的な形式の米国社会保障番号 (SSN) : XXX-XX-XXXX​。ここで、各 ​X​ は数字です。たとえば、​123-45-6789​ です。

Credit Card (クレジットカード)

4 つの数字を省略可能なスペースまたはハイフンで 4 つのグループに区切った形式のクレジットカード番号。例: 1234-5678-9012-3456​、​1234 5678 9012 3456​、​1234567890123456​。

Phone Number (電話番号)

さまざまな書式の米国の電話番号。国コード、括弧、スペース、ハイフン、ドットの有無は問いません。例: 123-456-7890​、​(123) 456-7890​、​123.456.7890​、​+1 123 456 7890​、​1234567890​。
# A2A 個人情報 (PII) ディテクターポリシー

ポリシー名

A2A PII ディテクターポリシー

概要

エージェントに送信される要求で個人情報 (PII) を検出します

カテゴリ

A2A

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
## [](#概要)概要 A2A PII ディテクターポリシーでは、エージェントに送信される要求で個人情報 (PII) を検出します。PII が検出された場合、要求を記録またはブロックできます。PII が検出された場合、ポリシー違反は必ず報告されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード A2A PII ディテクターポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Entities (エンティティ)

検出する PII の種別を定義する配列。複数の PII 種別を選択できます。サポートされている値は、​Email (メール)​、​US SSN​、​Credit Card (クレジットカード)​、​Phone Number (電話番号)​ です。
詳細は、​PII 種別​を参照してください。

アクション

PII が検出された場合に実行するアクション。サポートされている値は、​Log (記録)​ または ​Block (ブロック)​ です。
### [](#pii-types)PII 種別 A2A PII ディテクターポリシーを設定する際に、検出する PII の種別を選択できます。 次の表で、このポリシーで検出できる PII の種別について説明します。
PII 種別 説明

Email (メール)

User.Name+tag@example.com​ などの標準的なメールアドレス

US SSN

標準的な形式の米国社会保障番号 (SSN) : XXX-XX-XXXX​。ここで、各 ​X​ は数字です。たとえば、​123-45-6789​ です。

Credit Card (クレジットカード)

4 つの数字を省略可能なスペースまたはハイフンで 4 つのグループに区切った形式のクレジットカード番号。例: 1234-5678-9012-3456​、​1234 5678 9012 3456​、​1234567890123456​。

Phone Number (電話番号)

さまざまな書式の米国の電話番号。国コード、括弧、スペース、ハイフン、ドットの有無は問いません。例: 123-456-7890​、​(123) 456-7890​、​123.456.7890​、​+1 123 456 7890​、​1234567890​。
# Anypoint Monitoring でのランタイムログとアクセスログの表示 Anypoint Monitoring を使用して、ランタイムログとアクセスログの両方を表示します。Anypoint Monitoring の絞り込みを使用して、さまざまな詳細ログビューを表示します。 Runtime Manager Flex Gateway UI から Anypoint Monitoring にアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateway\]**​ を選択します。 3. API を追加するゲートウェイの名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 5. **\[View logs in Anypoint Monitoring (Anypoint Monitoring でログを表示)\]**​ をクリックします。 この操作により、Anypoint Monitoring UI に移動します。 # Anypoint Monitoring での管理 Flex Gateway ランタイムログとアクセスログの表示 Anypoint Monitoring を使用して、ランタイムログとアクセスログの両方を表示します。Anypoint Monitoring の絞り込みを使用して、さまざまな詳細ログビューを表示します。 Runtime Manager Flex Gateway UI から Anypoint Monitoring にアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 5. **\[View logs in Anypoint Monitoring (Anypoint Monitoring でログを表示)\]**​ をクリックします。 この操作により、Anypoint Monitoring UI に移動します。 # Anypoint Monitoring での管理 Flex Gateway ランタイムログとアクセスログの表示 Anypoint Monitoring を使用して、ランタイムログとアクセスログの両方を表示します。Anypoint Monitoring の絞り込みを使用して、さまざまな詳細ログビューを表示します。 Runtime Manager Flex Gateway UI から Anypoint Monitoring にアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 5. **\[View logs in Anypoint Monitoring (Anypoint Monitoring でログを表示)\]**​ をクリックします。 この操作により、Anypoint Monitoring UI に移動します。 # Anypoint Monitoring での自己管理ランタイムログとアクセスログの表示 Anypoint Monitoring を使用して、ランタイムログとアクセスログの両方を表示します。Anypoint Monitoring の絞り込みを使用して、さまざまな詳細ログビューを表示します。 Runtime Manager Flex Gateway UI から Anypoint Monitoring にアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 5. **\[View logs in Anypoint Monitoring (Anypoint Monitoring でログを表示)\]**​ をクリックします。 この操作により、Anypoint Monitoring UI に移動します。 # Anypoint Monitoring での自己管理ランタイムログとアクセスログの表示 Anypoint Monitoring を使用して、ランタイムログとアクセスログの両方を表示します。Anypoint Monitoring の絞り込みを使用して、さまざまな詳細ログビューを表示します。 Runtime Manager Flex Gateway UI から Anypoint Monitoring にアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 5. **\[View logs in Anypoint Monitoring (Anypoint Monitoring でログを表示)\]**​ をクリックします。 この操作により、Anypoint Monitoring UI に移動します。 # Anypoint Platform への Flex Gateway ログ出力の無効化 Anypoint Flex Gateway ログにより、起動、シャットダウン、API 要求、API 応答、ポリシー、Fluent Bit に関するインサイトが得られます。ログにより、開発者やシステム管理者は問題や異常を識別して解決できます。ただし、Anypoint Platform へのログ出力を無効化する必要がある場合があります。 ログ出力を無効化する前に、トラブルシューティング機能に対する潜在的な影響を検討してください。場合によって、ログの冗長レベルを調整するほうが適切な場合があります。 次のログの Anypoint Platform への送信を無効化できます。 - 次のようなランタイムログ: - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン。 - デプロイされた API とポリシー。 - Flex Gateway の設定ミスの可能性またはその他のエラー。 - 次のようなアクセスログ: - 一定期間の Envoy との受信インタラクションの説明。 - 特定の API に対する受信要求と応答。
無効化できるのは Anypoint Platform に送信されるログのみです。標準出力 (STDOUT) に変更はありません。
Anypoint Platform へのログの送信は、ローカル設定ファイルを使用して無効化します。次のチュートリアルでは、ファイルを作成してデプロイする方法について説明します。

20%

25%

20%

20%

Linux サービスとして Flex Gateway の Anypoint Platform ログ出力を無効化する

コンテナで Flex Gateway の Anypoint Platform ログ出力を無効化する

Kubernetes クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する

OpenShift クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - 出力に応じて、ログの送信先のサービスが動作していることを確認します。ログ出力サービスについての詳細は、​[「サードパーティサービスの Flex Gateway 出力の設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-third-party-logs-config)​を参照してください。 ## [](#linux)Linux サービスとして Flex Gateway の Anypoint Platform ログ出力を無効化する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。次に例を示します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/disable-logs-config.yaml ``` 2. 設定ファイルで、​`spec.logging.runtimeLogs.outputs.anypoint`​ と ​`spec.logging.accessLogs.outputs.anypoint`​ のどちらかまたは両方を ​`disabled`​ に設定します。ファイルは次のようになります。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 3. ファイルを保存します。 ## [](#containers)コンテナで Flex Gateway の Anypoint Platform ログ出力を無効化する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、ステップ 4 までスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. `app`​ ディレクトリに移動します。 4. `disable-logs-config.yaml`​ という名前の新しい設定 YAML ファイルを作成します。 5. 設定ファイルで、​`spec.logging.runtimeLogs.outputs.anypoint`​ と ​`spec.logging.accessLogs.outputs.anypoint`​ のどちらかまたは両方を ​`disabled`​ に設定します。ファイルは次のようになります。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 6. 設定ファイルを保存します。 7. 設定ディレクトリボリュームを使用して Flex Gateway を再起動します。 - Docker - Podman ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
## [](#kubernetes)Kubernetes クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する Anypoint Platform へのログを無効化する手順は、次のとおりです。 1. 次の例の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 2. `spec.logging.runtimeLogs.outputs.anypoint`​ と ​`spec.logging.accessLogs.outputs.anypoint`​ のどちらかまたは両方を ​`disabled`​ に設定します。 ## [](#openshift)OpenShift クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する Anypoint Platform へのログを無効化する手順は、次のとおりです。 1. 次の例の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 2. `spec.logging.runtimeLogs.outputs.anypoint`​ と ​`spec.logging.accessLogs.outputs.anypoint`​ のどちらかまたは両方を ​`disabled`​ に設定します。 ## [](#関連情報)関連情報 - [サードパーティサービスの Flex Gateway 出力の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-third-party-logs-config) - [メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-message-logging) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) # Anypoint Platform への Flex Gateway ログ出力の無効化 Anypoint Flex Gateway ログにより、起動、シャットダウン、API 要求、API 応答、ポリシー、Fluent Bit に関するインサイトが得られます。ログにより、開発者やシステム管理者は問題や異常を識別して解決できます。ただし、Anypoint Platform へのログ出力を無効化する必要がある場合があります。 ログ出力を無効化する前に、トラブルシューティング機能に対する潜在的な影響を検討してください。場合によって、ログの冗長レベルを調整するほうが適切な場合があります。 次のログの Anypoint Platform への送信を無効化できます。 - 次のようなランタイムログ: - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン。 - デプロイされた API とポリシー。 - Flex Gateway の設定ミスの可能性またはその他のエラー。 - 次のようなアクセスログ: - 一定期間の Envoy との受信インタラクションの説明。 - 特定の API に対する受信要求と応答。
無効化できるのは Anypoint Platform に送信されるログのみです。標準出力 (STDOUT) に変更はありません。
Anypoint Platform へのログの送信は、ローカル設定ファイルを使用して無効化します。次のチュートリアルでは、ファイルを作成してデプロイする方法について説明します。

20%

25%

20%

20%

Linux サービスとして Flex Gateway の Anypoint Platform ログ出力を無効化する

コンテナで Flex Gateway の Anypoint Platform ログ出力を無効化する

Kubernetes クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する

OpenShift クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - 出力に応じて、ログの送信先のサービスが動作していることを確認します。ログ出力サービスについての詳細は、​[「サードパーティサービスの Flex Gateway 出力の設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-third-party-logs-config)​を参照してください。 ## [](#linux)Linux サービスとして Flex Gateway の Anypoint Platform ログ出力を無効化する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。次に例を示します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/disable-logs-config.yaml ``` 2. 設定ファイルで、​`spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。ファイルは次のようになります。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 3. ファイルを保存します。 ## [](#containers)コンテナで Flex Gateway の Anypoint Platform ログ出力を無効化する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、ステップ 4 までスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. `app`​ ディレクトリに移動します。 4. `disable-logs-config.yaml`​ という名前の新しい設定 YAML ファイルを作成します。 5. 設定ファイルで、​`spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。ファイルは次のようになります。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 6. 設定ファイルを保存します。 7. 設定ディレクトリボリュームを使用して Flex Gateway を再起動します。 - Docker - Podman ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
## [](#kubernetes)Kubernetes クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する Anypoint Platform へのログを無効化する手順は、次のとおりです。 1. 次の例の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 2. `spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。 ## [](#openshift)OpenShift クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する Anypoint Platform へのログを無効化する手順は、次のとおりです。 1. 次の例の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 2. `spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。 ## [](#関連情報)関連情報 - [サードパーティサービスの Flex Gateway 出力の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-third-party-logs-config) - [メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-message-logging) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) # Anypoint Platform への Flex Gateway ログ出力の無効化 Anypoint Flex Gateway ログにより、起動、シャットダウン、API 要求、API 応答、ポリシー、Fluent Bit に関するインサイトが得られます。ログにより、開発者やシステム管理者は問題や異常を識別して解決できます。ただし、Anypoint Platform へのログ出力を無効化する必要がある場合があります。 ログ出力を無効化する前に、トラブルシューティング機能に対する潜在的な影響を検討してください。場合によって、ログの冗長レベルを調整するほうが適切な場合があります。 次のログの Anypoint Platform への送信を無効化できます。 - 次のようなランタイムログ: - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン。 - デプロイされた API とポリシー。 - Flex Gateway の設定ミスの可能性またはその他のエラー。 - 次のようなアクセスログ: - 一定期間の Envoy との受信インタラクションの説明。 - 特定の API に対する受信要求と応答。
無効化できるのは Anypoint Platform に送信されるログのみです。標準出力 (STDOUT) に変更はありません。
Anypoint Platform へのログの送信は、ローカル設定ファイルを使用して無効化します。次のチュートリアルでは、ファイルを作成してデプロイする方法について説明します。

20%

25%

20%

20%

Linux サービスとして Flex Gateway の Anypoint Platform ログ出力を無効化する

コンテナで Flex Gateway の Anypoint Platform ログ出力を無効化する

Kubernetes クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する

OpenShift クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - 出力に応じて、ログの送信先のサービスが動作していることを確認します。ログ出力サービスについての詳細は、​[「サードパーティサービスの Flex Gateway 出力の設定」](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-third-party-logs-config)​を参照してください。 ## [](#linux)Linux サービスとして Flex Gateway の Anypoint Platform ログ出力を無効化する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。次に例を示します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/disable-logs-config.yaml ``` 2. 設定ファイルで、​`spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。ファイルは次のようになります。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 3. ファイルを保存します。 ## [](#containers)コンテナで Flex Gateway の Anypoint Platform ログ出力を無効化する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、ステップ 4 までスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. `app`​ ディレクトリに移動します。 4. `disable-logs-config.yaml`​ という名前の新しい設定 YAML ファイルを作成します。 5. 設定ファイルで、​`spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。ファイルは次のようになります。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 6. 設定ファイルを保存します。 7. 設定ディレクトリボリュームを使用して Flex Gateway を再起動します。 - Docker - Podman ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
## [](#kubernetes)Kubernetes クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する Anypoint Platform へのログを無効化する手順は、次のとおりです。 1. 次の例の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 2. `spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。 ## [](#openshift)OpenShift クラスターで Flex Gateway の Anypoint Platform ログ出力を無効化する Anypoint Platform へのログを無効化する手順は、次のとおりです。 1. 次の例の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: info outputs: anypoint: disabled accessLogs: outputs: anypoint: disabled ``` 2. `spec.logging.runtimeLogs.outputs.anypoint`​ または ​`spec.logging.accessLogs.outputs.anypoint`​ を ​`disabled`​ に設定します。 ## [](#関連情報)関連情報 - [サードパーティサービスの Flex Gateway 出力の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-third-party-logs-config) - [メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-message-logging) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) # API Manager API ツールを使用した Flex Gateway の設定 Anypoint Platform を介して API Manager ユーザーインターフェースを使用する代わりに、 [Anypoint Platform 開発者ポータル](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/)​から API Manager API ツールを使用して、接続モードで Flex Gateway を設定できます。このツールにより、コマンドラインを使用して API Manager と通信できるようになります。このチュートリアルの手順を使用して、API インスタンスの作成、デプロイ、ポリシーの適用、および削除を行います。 API Manager API についての詳細は、 [API Manager API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​を参照してください。
Jenkins パイプラインを使用してこれらのコマンドを自動化するには、​「Jenkins Pipeline を使用した接続モードでの Flex Gateway の自動化」​を参照してください。
## [](#始める前に)始める前に API Manager API を使用して Flex Gateway を設定する前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)​。 2. [接続モードでの Flex Gateway を登録して実行します](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​。 3. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 - **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** API Manager API を使用するために​[接続アプリケーションで Flex Gateway を登録して実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-app)​する必要はありませんが、適切なスコープを含めれば同じ接続アプリケーションを使用できます。 - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 4. 作成または適用する Exchange アセットのグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.1`​ です。 5. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - API をデプロイする Flex Gateway のランタイム​**対象 ID** **対象 ID**​ を見つけるには、​**\[Anypoint Platform\] > \[Runtime Manager\] > \[Flex Gateway\]**​ に移動します。 ## [](#access-management-アクセス管理-から認証トークンを取得する)\[Access Management (アクセス管理)\] から認証トークンを取得する API Manager API を使用してコールを行うには、認証トークンを取得する必要があります。 1. 次の情報を収集します。 - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 2. プレースホルダーを次の内容に置き換えたら、次の要求を実行して認証トークンを取得します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' \ --header 'Content-Type: application/json' \ --data-raw '{ "grant_type": "client_credentials", "client_id": "", "client_secret": "" }' ``` 3. 返された認証トークンを保存します。 ## [](#api-インスタンスを作成する)API インスタンスを作成する API Manager API を使用して API インスタンスを作成する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: [「\[Access Management (アクセス管理)\] から認証トークンを取得する」](#obtain-an-authorization-token-from-access-management)​ステップで収集された認証トークン - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: API の URI アップストリーム - ``​: プロキシ URI、API インスタンスのポートとベースパスの組み合わせ (例: `http://0.0.0.0:/`​) 2. 必要に応じて、​`"endpointUri"`​ を収集するか、​`"endpointUri"`​ 項目を削除します。 - ``​: API のコンシューマーエンドポイント (例: `http://consumer-endpoint.com`​) 3. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "spec": { "groupId": "", "assetId": "", "version": "" }, "endpoint": { "deploymentType": "HY", "uri": "", "proxyUri": "", "isCloudHub": null }, "technology": "flexGateway" "endpointUri": "" // OPTIONAL }' ``` 4. インスタンスのデプロイ、ポリシーの適用、または削除を行うために、応答からインスタンス ID ​`"id"`​ を保存します。 ## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API Manager API を使用して API インスタンスをデプロイする手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: [「API インスタンスを作成する」](#create-an-api-instance)​からのインスタンス ID ​`"id"` - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: Runtime Manager から収集された対象 ID 2. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/proxies/xapi/v1/organizations//environments//apis//deployments' \ --header 'Content-Type: application/json' \ --header 'Authorization: bearer ' \ --data-raw '{ "type": "HY", "gatewayVersion": "", "targetId": "", "environmentId": "" }' ``` ## [](#ポリシーの適用)ポリシーの適用 API Manager API を使用して、接続モードポリシーを Flex Gateway にのみ適用できます。 API Manager API を使用して API インスタンスにポリシーを適用する手順は、次のとおりです。 1. 次の情報を収集します。 - ポリシー GAV: - ``​: Exchange のポリシーグループ ID - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.1`​) - `"configurationData"`​: ポリシーの必須設定パラメーター + Each policy has unique configuration data fields。​`"username"`​ 項目と ​`"password"`​ 項目は一例です。ポリシーの設定データを見つけるには、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory)​を参照してください。 2. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis//policies' \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "configurationData":{ "username": "user", "password": "test" }, "pointcutData":null, "assetId": "", "assetVersion": "", "groupId": "" }' ``` ## [](#api-インスタンスの削除)API インスタンスの削除 API Manager API を使用して API インスタンスを削除するには、サンプルコンテンツを置き換えた後に、Anypoint Platform に対して DELETE 要求を実行します。 ```ssh curl --location --request DELETE 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis/' \ --header 'Content-Type: application/json' \ --header 'Authorization: bearer ' ``` ## [](#関連情報)関連情報 - [Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-jenkins-api) - [Anypoint 開発者 API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/) # API Manager API ツールを使用した Flex Gateway の設定 Anypoint Platform を介して API Manager ユーザーインターフェースを使用する代わりに、 [Anypoint Platform 開発者ポータル](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/)​から API Manager API ツールを使用して、接続モードで Flex Gateway を設定できます。このツールにより、コマンドラインを使用して API Manager と通信できるようになります。このチュートリアルの手順を使用して、API インスタンスの作成、デプロイ、ポリシーの適用、および削除を行います。 API Manager API についての詳細は、 [API Manager API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​を参照してください。
Jenkins パイプラインを使用してこれらのコマンドを自動化するには、​「Jenkins Pipeline を使用した接続モードでの Flex Gateway の自動化」​を参照してください。
## [](#始める前に)始める前に API Manager API を使用して Flex Gateway を設定する前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)​。 2. [接続モードでの Flex Gateway を登録して実行します](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​。 3. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 - **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** API Manager API を使用するために​[接続アプリケーションで Flex Gateway を登録して実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-app)​する必要はありませんが、適切なスコープを含めれば同じ接続アプリケーションを使用できます。 - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 4. 作成または適用する Exchange アセットのグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.1`​ です。 5. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - API をデプロイする Flex Gateway のランタイム​**対象 ID** **対象 ID**​ を見つけるには、​**\[Anypoint Platform\] > \[Runtime Manager\] > \[Flex Gateway\]**​ に移動します。 ## [](#access-management-アクセス管理-から認証トークンを取得する)\[Access Management (アクセス管理)\] から認証トークンを取得する API Manager API を使用してコールを行うには、認証トークンを取得する必要があります。 1. 次の情報を収集します。 - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 2. プレースホルダーを次の内容に置き換えたら、次の要求を実行して認証トークンを取得します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' \ --header 'Content-Type: application/json' \ --data-raw '{ "grant_type": "client_credentials", "client_id": "", "client_secret": "" }' ``` 3. 返された認証トークンを保存します。 ## [](#api-インスタンスを作成する)API インスタンスを作成する API Manager API を使用して API インスタンスを作成する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: [「\[Access Management (アクセス管理)\] から認証トークンを取得する」](#obtain-an-authorization-token-from-access-management)​ステップで収集された認証トークン - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: API の URI アップストリーム - ``​: プロキシ URI、API インスタンスのポートとベースパスの組み合わせ (例:​`http://0.0.0.0:/`​) 2. 必要に応じて、​`"endpointUri"`​ を収集するか、​`"endpointUri"`​ 項目を削除します。 - ``​: API のコンシューマーエンドポイント (例: `http://consumer-endpoint.com`​) 3. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "spec": { "groupId": "", "assetId": "", "version": "" }, "endpoint": { "deploymentType": "HY", "uri": "", "proxyUri": "", "isCloudHub": null }, "technology": "flexGateway" "endpointUri": "" // OPTIONAL }' ``` 4. インスタンスのデプロイ、ポリシーの適用、または削除を行うために、応答からインスタンス ID ​`"id"`​ を保存します。 ## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API Manager API を使用して API インスタンスをデプロイする手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: [「API インスタンスを作成する」](#create-an-api-instance)​からのインスタンス ID ​`"id"` - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: Runtime Manager から収集された対象 ID 2. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/proxies/xapi/v1/organizations//environments//apis//deployments' \ --header 'Content-Type: application/json' \ --header 'Authorization: bearer ' \ --data-raw '{ "type": "HY", "gatewayVersion": "", "targetId": "", "environmentId": "" }' ``` ## [](#ポリシーの適用)ポリシーの適用 API Manager API を使用して、接続モードポリシーを Flex Gateway にのみ適用できます。 API Manager API を使用して API インスタンスにポリシーを適用する手順は、次のとおりです。 1. 次の情報を収集します。 - ポリシー GAV: - ``​: Exchange のポリシーグループ ID - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.1`​) - `"configurationData"`​: ポリシーの必須設定パラメーター + Each policy has unique configuration data fields。​`"username"`​ 項目と ​`"password"`​ 項目は一例です。ポリシーの設定データを見つけるには、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory)​を参照してください。 2. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis//policies' \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "configurationData":{ "username": "user", "password": "test" }, "pointcutData":null, "assetId": "", "assetVersion": "", "groupId": "" }' ``` ## [](#api-インスタンスの削除)API インスタンスの削除 API Manager API を使用して API インスタンスを削除するには、サンプルコンテンツを置き換えた後に、Anypoint Platform に対して DELETE 要求を実行します。 ```ssh curl --location --request DELETE 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis/' \ --header 'Content-Type: application/json' \ --header 'Authorization: bearer ' ``` ## [](#関連情報)関連情報 - [Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-jenkins-api) - [Anypoint 開発者 API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/) # API Manager API ツールを使用した Flex Gateway の設定 Anypoint Platform を介して API Manager ユーザーインターフェースを使用する代わりに、 [Anypoint Platform 開発者ポータル](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/)​から API Manager API ツールを使用して、接続モードで Flex Gateway を設定できます。このツールにより、コマンドラインを使用して API Manager と通信できるようになります。このチュートリアルの手順を使用して、API インスタンスの作成、デプロイ、ポリシーの適用、および削除を行います。 API Manager API についての詳細は、 [API Manager API ドキュメント](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​を参照してください。
Jenkins パイプラインを使用してこれらのコマンドを自動化するには、​「Jenkins Pipeline を使用した接続モードでの Flex Gateway の自動化」​を参照してください。
## [](#始める前に)始める前に API Manager API を使用して Flex Gateway を設定する前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)​。 2. [接続モードでの Flex Gateway を登録して実行します](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​。 3. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 - **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** API Manager API を使用するために​[接続アプリケーションで Flex Gateway を登録して実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-app)​する必要はありませんが、適切なスコープを含めれば同じ接続アプリケーションを使用できます。 - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 4. 作成または適用する Exchange アセットのグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.1`​ です。 5. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - API をデプロイする Flex Gateway のランタイム​**対象 ID** **対象 ID**​ を見つけるには、​**\[Anypoint Platform\] > \[Runtime Manager\] > \[Flex Gateway\]**​ に移動します。 ## [](#access-management-アクセス管理-から認証トークンを取得する)\[Access Management (アクセス管理)\] から認証トークンを取得する API Manager API を使用してコールを行うには、認証トークンを取得する必要があります。 1. 次の情報を収集します。 - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 2. プレースホルダーを次の内容に置き換えたら、次の要求を実行して認証トークンを取得します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' \ --header 'Content-Type: application/json' \ --data-raw '{ "grant_type": "client_credentials", "client_id": "", "client_secret": "" }' ``` 3. 返された認証トークンを保存します。 ## [](#api-インスタンスを作成する)API インスタンスを作成する API Manager API を使用して API インスタンスを作成する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: [「\[Access Management (アクセス管理)\] から認証トークンを取得する」](#obtain-an-authorization-token-from-access-management)​ステップで収集された認証トークン - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: API の URI アップストリーム - ``​: プロキシ URI、API インスタンスのポートとベースパスの組み合わせ (例: `http://0.0.0.0:/`​) 2. 必要に応じて、​`"endpointUri"`​ を収集するか、​`"endpointUri"`​ 項目を削除します。 - ``​: API のコンシューマーエンドポイント (例: `http://consumer-endpoint.com`​) 3. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "spec": { "groupId": "", "assetId": "", "version": "" }, "endpoint": { "deploymentType": "HY", "uri": "", "proxyUri": "", "isCloudHub": null }, "technology": "flexGateway" "endpointUri": "" // OPTIONAL }' ``` 4. インスタンスのデプロイ、ポリシーの適用、または削除を行うために、応答からインスタンス ID ​`"id"`​ を保存します。 ## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API Manager API を使用して API インスタンスをデプロイする手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: [「API インスタンスを作成する」](#create-an-api-instance)​からのインスタンス ID ​`"id"` - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: Runtime Manager から収集された対象 ID 2. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/proxies/xapi/v1/organizations//environments//apis//deployments' \ --header 'Content-Type: application/json' \ --header 'Authorization: bearer ' \ --data-raw '{ "type": "HY", "gatewayVersion": "", "targetId": "", "environmentId": "" }' ``` ## [](#ポリシーの適用)ポリシーの適用 API Manager API を使用して、接続モードポリシーを Flex Gateway にのみ適用できます。 API Manager API を使用して API インスタンスにポリシーを適用する手順は、次のとおりです。 1. 次の情報を収集します。 - ポリシー GAV: - ``​: Exchange のポリシーグループ ID - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.1`​) - `"configurationData"`​: ポリシーの必須設定パラメーター + Each policy has unique configuration data fields。​`"username"`​ 項目と ​`"password"`​ 項目は一例です。ポリシーの設定データを見つけるには、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory)​を参照してください。 2. サンプルコンテンツを置き換えたら、Anypoint Platform に対して POST 要求を実行します。 ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis//policies' \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "configurationData":{ "username": "user", "password": "test" }, "pointcutData":null, "assetId": "", "assetVersion": "", "groupId": "" }' ``` ## [](#api-インスタンスの削除)API インスタンスの削除 API Manager API を使用して API インスタンスを削除するには、サンプルコンテンツを置き換えた後に、Anypoint Platform に対して DELETE 要求を実行します。 ```ssh curl --location --request DELETE 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations//environments//apis/' \ --header 'Content-Type: application/json' \ --header 'Authorization: bearer ' ``` ## [](#関連情報)関連情報 - [Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-jenkins-api) - [Anypoint 開発者 API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/) # AWS Lambda ポリシー

ポリシー名

AWS Lambda

概要

標準の HTTP 要求から AWS Lambda 関数をトリガーする

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

502 - 不正なゲートウェイ、サーキットブレーカーのアクティベーションにより要求がブロックされます
## [](#概要)概要 AWS Lambda ポリシーでは、標準の HTTP 要求から AWS Lambda 関数をトリガーします。HTTP 要求ペイロードをそのまま、またはJSON スキーマでラップして渡します。 AWS Lambda ポリシーは、Envoy に対してネイティブな AWS Lambda 検索条件の拡張機能です。AWS Lambda 検索条件についての詳細は、 [「AWS Lambda Filter (AWS Lambda 検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/aws_lambda_filter)​を参照してください。すべての AWS Lambda 検索条件パラメーターが AWS Lambda ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-aws-lambda config: arn: // REQUIRED payloadPassthrough: // REQUIRED invocationMode: // REQUIRED authenticationMode: // REQUIRED credentialProfile: // OPTIONAL credentials: accessKeyId: // OPTIONAL secretAccessKey: // OPTIONAL sessionToken: // OPTIONAL ```
パラメーター 必須または省略可能 デフォルト値 説明

arn

必須

なし

次の形式の AWS Lambda ARN: arn:<partition>:lambda:<region>:<account-number>:function:<function-name>​。

payloadPassthrough

必須

false

デフォルトでは、Flex は JSON でラップされた要求を AWS Lambda 関数に送信します。​payloadPassthrough​ が有効になっている場合、要求はそのまま送信されます。

invocationMode

必須

同期

Lambda 関数の呼び出し方法 (​sync​ または ​async​)。​sync​ の場合、Flex Gateway は AWS 応答を待機します。​async​ の場合、Flex Gateway は AWS からの応答を待機しません。

authenticationMode

必須

なし

認証のモードを決定します。オプション: ログイン情報 AWS 環境変数、AWS ログイン情報ファイル、AWS ロールを順番通りに使用する ​default​、AWS ログイン情報ファイルのプロファイルである ​profile​、ポリシーで設定されたログイン情報である ​static​。

credentialProfile

省略可能

なし

ログイン情報の ​profile​ を指定します。​profile​ 認証モード専用です。

credentials

省略可能

なし

static​ ログイン情報オブジェクトを設定します。​static​ 認証モード専用です。

credentials.accessKeyId

必須

なし

AWS アクセスキー ID

credentials.secretAccessKey

必須

なし

AWS アクセスキー

credentials.sessionToken

省略可能

なし

セッショントークン
#### [](#リソースの設定例)リソースの設定例 次の例では、レート制限を 6 秒ごとに 3 件の要求として定義しています。 ```yaml - policyRef: name: native-aws-lambda config: arn: rn:<partition>:lambda:<region>:<account-number>:function:<function-name> payloadPassthrough: true invocationMode: sync authenticationMode: static credentials: accessKeyId: id secretAccessKey: secret sessionToken: token ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 必須または省略可能 説明

The ARN of the AWS Lambda (AWS Lambda の ARN)

必須

次の形式の AWS Lambda ARN: arn:<partition>:lambda:<region>:<account-number>:function:<function-name>​。

Payload passthrough (ペイロードパススルー)

必須

デフォルトでは、Flex は JSON でラップされた要求を AWS Lambda 関数に送信します。有効になっている場合、要求はそのまま送信されます。

Determines the way to invoke the Lambda function (Lambda 関数の呼び出し方法を決定)

必須

Lambda 関数の呼び出し方法。​Sync​ の場合、Flex Gateway は AWS 応答を待機します。​Async​ の場合、Flex Gateway は AWS からの応答を待機しません。

Determines origin of credentials (ログイン情報のオリジンを決定)

必須

認証のモードを決定します。オプション: ログイン情報 AWS 環境変数、AWS ログイン情報ファイル、AWS ロールを順番通りに使用する ​Default​、AWS ログイン情報ファイルのプロファイルである ​Profile​、ポリシーで設定されたログイン情報である ​Static​。

Credentials profile (ログイン情報プロファイル)

省略可能

ログイン情報のプロファイルを指定します。​Profile​ 認証モード専用です。

ログイン情報

省略可能

静的ログイン情報を設定します。​Static​ 認証モード専用です。

AccessKeyId

必須

AWS アクセスキー ID

SecretAccessKey

必須

AWS アクセスキー

SessionToken

省略可能

セッショントークン
# AWS Lambda ポリシー

ポリシー名

AWS Lambda

概要

標準の HTTP 要求から AWS Lambda 関数をトリガーする

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

502 - 不正なゲートウェイ、サーキットブレーカーのアクティベーションにより要求がブロックされます
## [](#概要)概要 AWS Lambda ポリシーでは、標準の HTTP 要求から AWS Lambda 関数をトリガーします。HTTP 要求ペイロードをそのまま、またはJSON スキーマでラップして渡します。 AWS Lambda ポリシーは、Envoy に対してネイティブな AWS Lambda 検索条件の拡張機能です。AWS Lambda 検索条件についての詳細は、 [「AWS Lambda Filter (AWS Lambda 検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/aws_lambda_filter)​を参照してください。すべての AWS Lambda 検索条件パラメーターが AWS Lambda ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-aws-lambda config: arn: // REQUIRED payloadPassthrough: // REQUIRED invocationMode: // REQUIRED authenticationMode: // REQUIRED credentialProfile: // OPTIONAL credentials: accessKeyId: // OPTIONAL secretAccessKey: // OPTIONAL sessionToken: // OPTIONAL ```
パラメーター 必須または省略可能 デフォルト値 説明

arn

必須

なし

次の形式の AWS Lambda ARN: arn:<partition>:lambda:<region>:<account-number>:function:<function-name>​。

payloadPassthrough

必須

false

デフォルトでは、Flex は JSON でラップされた要求を AWS Lambda 関数に送信します。​payloadPassthrough​ が有効になっている場合、要求はそのまま送信されます。

invocationMode

必須

同期

Lambda 関数の呼び出し方法 (​sync​ または ​async​)。​sync​ の場合、Flex Gateway は AWS 応答を待機します。​async​ の場合、Flex Gateway は AWS からの応答を待機しません。

authenticationMode

必須

なし

認証のモードを決定します。オプション: ログイン情報 AWS 環境変数、AWS ログイン情報ファイル、AWS ロールを順番通りに使用する ​default​、AWS ログイン情報ファイルのプロファイルである ​profile​、ポリシーで設定されたログイン情報である ​static​。

credentialProfile

省略可能

なし

ログイン情報の ​profile​ を指定します。​profile​ 認証モード専用です。

credentials

省略可能

なし

static​ ログイン情報オブジェクトを設定します。​static​ 認証モード専用です。

credentials.accessKeyId

必須

なし

AWS アクセスキー ID

credentials.secretAccessKey

必須

なし

AWS アクセスキー

credentials.sessionToken

省略可能

なし

セッショントークン
#### [](#リソースの設定例)リソースの設定例 次の例では、レート制限を 6 秒ごとに 3 件の要求として定義しています。 ```yaml - policyRef: name: native-aws-lambda config: arn: rn:<partition>:lambda:<region>:<account-number>:function:<function-name> payloadPassthrough: true invocationMode: sync authenticationMode: static credentials: accessKeyId: id secretAccessKey: secret sessionToken: token ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 必須または省略可能 説明

The ARN of the AWS Lambda (AWS Lambda の ARN)

必須

次の形式の AWS Lambda ARN: arn:<partition>:lambda:<region>:<account-number>:function:<function-name>​。

Payload passthrough (ペイロードパススルー)

必須

デフォルトでは、Flex は JSON でラップされた要求を AWS Lambda 関数に送信します。有効になっている場合、要求はそのまま送信されます。

Determines the way to invoke the Lambda function (Lambda 関数の呼び出し方法を決定)

必須

Lambda 関数の呼び出し方法。​Sync​ の場合、Flex Gateway は AWS 応答を待機します。​Async​ の場合、Flex Gateway は AWS からの応答を待機しません。

Determines origin of credentials (ログイン情報のオリジンを決定)

必須

認証のモードを決定します。オプション: ログイン情報 AWS 環境変数、AWS ログイン情報ファイル、AWS ロールを順番通りに使用する ​Default​、AWS ログイン情報ファイルのプロファイルである ​Profile​、ポリシーで設定されたログイン情報である ​Static​。

Credentials profile (ログイン情報プロファイル)

省略可能

ログイン情報のプロファイルを指定します。​Profile​ 認証モード専用です。

ログイン情報

省略可能

静的ログイン情報を設定します。​Static​ 認証モード専用です。

AccessKeyId

必須

AWS アクセスキー ID

SecretAccessKey

必須

AWS アクセスキー

SessionToken

省略可能

セッショントークン
# CLI を使用したトラブルシューティング Anypoint Flex Gateway には、ゲートウェイの API インスタンス、サービス、設定、使用可能な拡張機能 (ポリシー) に関連した情報を照会できる ​`flexctl dump`​ CLI が含まれています。 たとえば、次のインラインスニペットは、デフォルトの名前空間で ​`jsonplaceholder-api`​ という単独の API インスタンスを定義します (名前空間名画明確に指定されていないため ​`default`​ のままになっています)。 また、このスニペットは ​`http-basic-authentication-flex`​ という内部ポリシーを定義しています。
Linux デプロイメントで ​flexctl dump​ を実行するには、ユーザーを ​flex​ ユーザーグループに追加するか、​sudo​ コマンドを使用して ​flexctl dump​ を実行します。詳細は、Linux 権限のトラブルシューティングを参照してください。
## [](#設定例)設定例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: jsonplaceholder-api spec: address: http://0.0.0.0:8080 services: jsonplaceholder: address: https://jsonplaceholder.typicode.com:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin ## [](#cli-を実行する)CLI を実行する 1. API インスタンス、サービス、設定、拡張機能の JSON 表現を確認するには、次のコマンドを実行します。 ```ssh flexctl dump ```

Docker または Podman コンテナで実行している場合は、このコマンドをコンテナ自身の中で実行してください。
このコマンドでは 4 つのファイルが出力されます。 - `api-instances.json` - `services.json` - `configuration.json` - `extensions.json` 2. ファイル名が続く ​`cat`​ を実行し、JSON ファイルのコンテンツを表示します。 - API インスタンス - サービス - 設定 - Extensions (拡張機能) ```ssh cat api-instances.json ``` `api-instances.json`​ ファイルのコンテンツは次のようになります。 \[ { "address":"http://0.0.0.0:8080", "kind":"ApiInstance", "name":"jsonplaceholder-api", "namespace":"default", "policies":\[ { "config":{ "password":"admin", "username":"chris" }, "extension":{ "kind":"Extension", "name":"http-basic-authentication-flex", "namespace":"default" }, "kind":"Policy", "name":"jsonplaceholder-api-http-basic-authentication-flex-1", "namespace":"default" }, { "config":{ "destinationRef":{ "kind":"Service", "name":"jsonplaceholder-api-jsonplaceholder", "namespace":"default" } } "extension":{ "kind":"Extension", "name":"route", "namespace":"default" }, "kind":"Policy", "name":"jsonplaceholder-api-jsonplaceholder-route-1", "namespace":"default", "order":50, "rules":\[ { "path":"/api(/users/.\*)" }, { "path":"/api(/comments/.\*)" } \] }, { "extension":{ "kind":"Extension", "name":"envoy.filters.http.router", "namespace":"default" }, "kind":"Policy", "name":"envoy.filters.http.router", "namespace":"default", "order":2147483647 } \] } \] ```ssh cat services.json ``` `services.json`​ ファイルのコンテンツは次のようになります。 \[ { "address":"https://jsonplaceholder.typicode.com:443/", "kind":"Service", "name":"jsonplaceholder-api-jsonplaceholder", "namespace":"default" } \] ```ssh cat configuration.json ``` `configuration.json`​ ファイルのコンテンツは次のようになります。 { "internalMetrics": { "enabled": false }, "logging": {}, "platformConnection": { "anypoint": { "url": "https://anypoint.mulesoft.com" }, "environment": { "cluster\_id": "4aa281e9-1a1d-4c56-8669-2d887b2e1938", "env\_id": "ad067f80-69ee-4abb-9d05-bec98ece1e20", "org\_id": "1caa0b9b-4f4d-43c4-a1b6-f925a8c77baa" }, "logging": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://logging.ingestion.us-east-1.msap.io/ingestion/api/v1/logging" }, "metering": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://metering.ingestion.us-east-1.msap.io/ingestion/api/v1/metering" }, "mode": "offline", "monitoring": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://monitoring.ingestion.us-east-1.msap.io/ingestion/api/v1/monitoring" }, "runtimeEvents": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://anypoint.mulesoft.com/apiruntime/v1/events" } }, "resourceLimits": { "apiInstances": 100, "policies": 400 }, "sharedStorage": {}, "version": "1.1.0" } ```ssh cat extensions.json ``` `extensions.json`​ ファイルには Flex Gateway で使用できるすべてのポリシーが含まれます。このファイルのコンテンツは次のようになります。 { "extends": \[ { "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "extension-definition", "namespace": "default" }, { "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "extension-qos", "namespace": "default" } \], "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "header-injection-definition", "namespace": "default", "properties": \[ { "name": "config", "properties": \[ { "items": { "name": "inboundHeaders", "properties": \[ { "name": "key", "type": "stringOrDataweave" }, { "name": "value", "type": "stringOrDataweave" } \], "type": "object" }, "name": "inboundHeaders", "type": "array" }, { "items": { "name": "outboundHeaders", "properties": \[ { "name": "key", "type": "stringOrDataweave" }, { "name": "value", "type": "stringOrDataweave" } \], "type": "object" }, "name": "outboundHeaders", "type": "array" } \], "type": "object" } \] } ## [](#冗長レベルの変更)冗長レベルの変更 `flexctl dump`​ CLI によって出力される情報の量を変更できます。たとえば、冗長性を ​`10`​ の値まで増やすには、次を使用して ​`flexctl dump`​ を実行します。 ```ssh flexctl dump -v 10 ``` ## [](#出力ディレクトリの変更)出力ディレクトリの変更 さらに、​`flexctl dump`​ で 4 つのファイルが出力されるディレクトリを変更できます。たとえば、​`/tmp`​ に出力するには、次を使用して ​`flexctl dump`​ を実行します。 ```ssh flexctl dump --output-directory /tmp ``` # CLI を使用したトラブルシューティング Anypoint Flex Gateway には、ゲートウェイの API インスタンス、サービス、設定、使用可能な拡張機能 (ポリシー) に関連した情報を照会できる ​`flexctl dump`​ CLI が含まれています。 たとえば、次のインラインスニペットは、デフォルトの名前空間で ​`jsonplaceholder-api`​ という単独の API インスタンスを定義します (名前空間名画明確に指定されていないため ​`default`​ のままになっています)。 また、このスニペットは ​`http-basic-authentication-flex`​ という内部ポリシーを定義しています。
Linux デプロイメントで ​flexctl dump​ を実行するには、ユーザーを ​flex​ ユーザーグループに追加するか、​sudo​ コマンドを使用して ​flexctl dump​ を実行します。詳細は、Linux 権限のトラブルシューティングを参照してください。
## [](#設定例)設定例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: jsonplaceholder-api spec: address: http://0.0.0.0:8080 services: jsonplaceholder: address: https://jsonplaceholder.typicode.com:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin ## [](#cli-を実行する)CLI を実行する 1. API インスタンス、サービス、設定、拡張機能の JSON 表現を確認するには、次のコマンドを実行します。 ```ssh flexctl dump ```

Docker または Podman コンテナで実行している場合は、このコマンドをコンテナ自身の中で実行してください。
このコマンドでは 4 つのファイルが出力されます。 - `api-instances.json` - `services.json` - `configuration.json` - `extensions.json` 2. ファイル名が続く ​`cat`​ を実行し、JSON ファイルのコンテンツを表示します。 - API インスタンス - サービス - 設定 - 拡張機能 ```ssh cat api-instances.json ``` `api-instances.json`​ ファイルのコンテンツは次のようになります。 \[ { "address":"http://0.0.0.0:8080", "kind":"ApiInstance", "name":"jsonplaceholder-api", "namespace":"default", "policies":\[ { "config":{ "password":"admin", "username":"chris" }, "extension":{ "kind":"Extension", "name":"http-basic-authentication-flex", "namespace":"default" }, "kind":"Policy", "name":"jsonplaceholder-api-http-basic-authentication-flex-1", "namespace":"default" }, { "config":{ "destinationRef":{ "kind":"Service", "name":"jsonplaceholder-api-jsonplaceholder", "namespace":"default" } } "extension":{ "kind":"Extension", "name":"route", "namespace":"default" }, "kind":"Policy", "name":"jsonplaceholder-api-jsonplaceholder-route-1", "namespace":"default", "order":50, "rules":\[ { "path":"/api(/users/.\*)" }, { "path":"/api(/comments/.\*)" } \] }, { "extension":{ "kind":"Extension", "name":"envoy.filters.http.router", "namespace":"default" }, "kind":"Policy", "name":"envoy.filters.http.router", "namespace":"default", "order":2147483647 } \] } \] ```ssh cat services.json ``` `services.json`​ ファイルのコンテンツは次のようになります。 \[ { "address":"https://jsonplaceholder.typicode.com:443/", "kind":"Service", "name":"jsonplaceholder-api-jsonplaceholder", "namespace":"default" } \] ```ssh cat configuration.json ``` `configuration.json`​ ファイルのコンテンツは次のようになります。 { "internalMetrics": { "enabled": false }, "logging": {}, "platformConnection": { "anypoint": { "url": "https://anypoint.mulesoft.com" }, "environment": { "cluster\_id": "4aa281e9-1a1d-4c56-8669-2d887b2e1938", "env\_id": "ad067f80-69ee-4abb-9d05-bec98ece1e20", "org\_id": "1caa0b9b-4f4d-43c4-a1b6-f925a8c77baa" }, "logging": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://logging.ingestion.us-east-1.msap.io/ingestion/api/v1/logging" }, "metering": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://metering.ingestion.us-east-1.msap.io/ingestion/api/v1/metering" }, "mode": "offline", "monitoring": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://monitoring.ingestion.us-east-1.msap.io/ingestion/api/v1/monitoring" }, "runtimeEvents": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://anypoint.mulesoft.com/apiruntime/v1/events" } }, "resourceLimits": { "apiInstances": 100, "policies": 400 }, "sharedStorage": {}, "version": "1.1.0" } ```ssh cat extensions.json ``` `extensions.json`​ ファイルには Flex Gateway で使用できるすべてのポリシーが含まれます。このファイルのコンテンツは次のようになります。 { "extends": \[ { "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "extension-definition", "namespace": "default" }, { "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "extension-qos", "namespace": "default" } \], "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "header-injection-definition", "namespace": "default", "properties": \[ { "name": "config", "properties": \[ { "items": { "name": "inboundHeaders", "properties": \[ { "name": "key", "type": "stringOrDataweave" }, { "name": "value", "type": "stringOrDataweave" } \], "type": "object" }, "name": "inboundHeaders", "type": "array" }, { "items": { "name": "outboundHeaders", "properties": \[ { "name": "key", "type": "stringOrDataweave" }, { "name": "value", "type": "stringOrDataweave" } \], "type": "object" }, "name": "outboundHeaders", "type": "array" } \], "type": "object" } \] } ## [](#冗長レベルの変更)冗長レベルの変更 `flexctl dump`​ CLI によって出力される情報の量を変更できます。たとえば、冗長性を ​`10`​ の値まで増やすには、次を使用して ​`flexctl dump`​ を実行します。 ```ssh flexctl dump -v 10 ``` ## [](#出力ディレクトリの変更)出力ディレクトリの変更 さらに、​`flexctl dump`​ で 4 つのファイルが出力されるディレクトリを変更できます。たとえば、​`/tmp`​ に出力するには、次を使用して ​`flexctl dump`​ を実行します。 ```ssh flexctl dump --output-directory /tmp ``` # CLI を使用したトラブルシューティング Anypoint Flex Gateway には、ゲートウェイの API インスタンス、サービス、設定、使用可能な拡張機能 (ポリシー) に関連した情報を照会できる ​`flexctl dump`​ CLI が含まれています。 たとえば、次のインラインスニペットは、デフォルトの名前空間で ​`jsonplaceholder-api`​ という単独の API インスタンスを定義します (名前空間名画明確に指定されていないため ​`default`​ のままになっています)。 また、このスニペットは ​`http-basic-authentication-flex`​ という内部ポリシーを定義しています。
Linux デプロイメントで ​flexctl dump​ を実行するには、ユーザーを ​flex​ ユーザーグループに追加するか、​sudo​ コマンドを使用して ​flexctl dump​ を実行します。詳細は、Linux 権限のトラブルシューティングを参照してください。
## [](#設定例)設定例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: jsonplaceholder-api spec: address: http://0.0.0.0:8080 services: jsonplaceholder: address: https://jsonplaceholder.typicode.com:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin ## [](#cli-を実行する)CLI を実行する 1. API インスタンス、サービス、設定、拡張機能の JSON 表現を確認するには、次のコマンドを実行します。 ```ssh flexctl dump ```

Docker または Podman コンテナで実行している場合は、このコマンドをコンテナ自身の中で実行してください。
このコマンドでは 4 つのファイルが出力されます。 - `api-instances.json` - `services.json` - `configuration.json` - `extensions.json` 2. ファイル名が続く ​`cat`​ を実行し、JSON ファイルのコンテンツを表示します。 - API インスタンス - サービス - 設定 - Extensions (拡張機能) ```ssh cat api-instances.json ``` `api-instances.json`​ ファイルのコンテンツは次のようになります。 \[ { "address":"http://0.0.0.0:8080", "kind":"ApiInstance", "name":"jsonplaceholder-api", "namespace":"default", "policies":\[ { "config":{ "password":"admin", "username":"chris" }, "extension":{ "kind":"Extension", "name":"http-basic-authentication-flex", "namespace":"default" }, "kind":"Policy", "name":"jsonplaceholder-api-http-basic-authentication-flex-1", "namespace":"default" }, { "config":{ "destinationRef":{ "kind":"Service", "name":"jsonplaceholder-api-jsonplaceholder", "namespace":"default" } } "extension":{ "kind":"Extension", "name":"route", "namespace":"default" }, "kind":"Policy", "name":"jsonplaceholder-api-jsonplaceholder-route-1", "namespace":"default", "order":50, "rules":\[ { "path":"/api(/users/.\*)" }, { "path":"/api(/comments/.\*)" } \] }, { "extension":{ "kind":"Extension", "name":"envoy.filters.http.router", "namespace":"default" }, "kind":"Policy", "name":"envoy.filters.http.router", "namespace":"default", "order":2147483647 } \] } \] ```ssh cat services.json ``` `services.json`​ ファイルのコンテンツは次のようになります。 \[ { "address":"https://jsonplaceholder.typicode.com:443/", "kind":"Service", "name":"jsonplaceholder-api-jsonplaceholder", "namespace":"default" } \] ```ssh cat configuration.json ``` `configuration.json`​ ファイルのコンテンツは次のようになります。 { "internalMetrics": { "enabled": false }, "logging": {}, "platformConnection": { "anypoint": { "url": "https://anypoint.mulesoft.com" }, "environment": { "cluster\_id": "4aa281e9-1a1d-4c56-8669-2d887b2e1938", "env\_id": "ad067f80-69ee-4abb-9d05-bec98ece1e20", "org\_id": "1caa0b9b-4f4d-43c4-a1b6-f925a8c77baa" }, "logging": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://logging.ingestion.us-east-1.msap.io/ingestion/api/v1/logging" }, "metering": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://metering.ingestion.us-east-1.msap.io/ingestion/api/v1/metering" }, "mode": "offline", "monitoring": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://monitoring.ingestion.us-east-1.msap.io/ingestion/api/v1/monitoring" }, "runtimeEvents": { "certificate": { "cert": "demo-local.pem", "key": "demo-local.key" }, "url": "https://anypoint.mulesoft.com/apiruntime/v1/events" } }, "resourceLimits": { "apiInstances": 100, "policies": 400 }, "sharedStorage": {}, "version": "1.1.0" } ```ssh cat extensions.json ``` `extensions.json`​ ファイルには Flex Gateway で使用できるすべてのポリシーが含まれます。このファイルのコンテンツは次のようになります。 { "extends": \[ { "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "extension-definition", "namespace": "default" }, { "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "extension-qos", "namespace": "default" } \], "kind": "Extension", "labels": { "flex.mulesoft.com/created-by": "flex-filesystem", "flex.mulesoft.com/managed-by": "flex-filesystem" }, "name": "header-injection-definition", "namespace": "default", "properties": \[ { "name": "config", "properties": \[ { "items": { "name": "inboundHeaders", "properties": \[ { "name": "key", "type": "stringOrDataweave" }, { "name": "value", "type": "stringOrDataweave" } \], "type": "object" }, "name": "inboundHeaders", "type": "array" }, { "items": { "name": "outboundHeaders", "properties": \[ { "name": "key", "type": "stringOrDataweave" }, { "name": "value", "type": "stringOrDataweave" } \], "type": "object" }, "name": "outboundHeaders", "type": "array" } \], "type": "object" } \] } ## [](#冗長レベルの変更)冗長レベルの変更 `flexctl dump`​ CLI によって出力される情報の量を変更できます。たとえば、冗長性を ​`10`​ の値まで増やすには、次を使用して ​`flexctl dump`​ を実行します。 ```ssh flexctl dump -v 10 ``` ## [](#出力ディレクトリの変更)出力ディレクトリの変更 さらに、​`flexctl dump`​ で 4 つのファイルが出力されるディレクトリを変更できます。たとえば、​`/tmp`​ に出力するには、次を使用して ​`flexctl dump`​ を実行します。 ```ssh flexctl dump --output-directory /tmp ``` # CloudHub 2.0 での管理 Flex Gateway の使用開始 CloudHub 2.0 で Anypoint 管理 Flex Gateway の使用を開始します。管理 Flex Gateway を作成してデプロイし、API をパブリッシュして、基本認証ポリシーで API を保護します。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、次の手順を完了してください。 - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites)を見直して、必要な管理 Flex Gateway 権限があることを確認します。 - CloudHub 2.0 に非公開スペースを作成するか、既存の非公開スペースにアクセスできることを確認します。非公開スペースを作成するには、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 ## [](#管理-flex-gateway-をデプロイする)管理 Flex Gateway をデプロイする 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. サイドバーで ​**\[Flex Gateways (Flex Gateway)\]**​ をクリックします。 3. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ をクリックします。 4. **\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ をクリックします。 5. **\[Gateway name (ゲートウェイ名)\]**​ を入力します。 6. **\[Deployment target (デプロイメント対象)\]**​ として非公開スペースを選択します。 7. **\[Advanced options (詳細オプション)\]**​ をクリックします。 8. 後でテストできるように管理 Flex Gateway 公開エンドポイントをコピーして保存します。これは ​**\[Public endpoint (公開エンドポイント)\]**​ UI ブロックに表示される HTTP または HTTPs URL です。たとえば、​`[https://my-gateway-abc123.edf456.us-east1.anypoint.mulesoft.com/](https://my-gateway-abc123.edf456.us-east1.anypoint.mulesoft.com/)`​ などです。 9. **\[Save & deploy (保存してデプロイ)\]**​ をクリックします。 UI が新しい管理 Flex Gateway のダッシュボードに戻ります。 10. ゲートウェイの ​**\[Status (状況)\]**​ が ​**\[Running (実行中)\]**​ になるまで待機します。 ## [](#シンプルな-api-のパブリッシュ)シンプルな API のパブリッシュ 1. 管理ゲートウェイのダッシュボードから、​**\[Add API instance (API インスタンスを追加)\]**​ をクリックします。 2. **\[Add API (API を追加)\]**​ ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 3. **\[Select a gateway (ゲートウェイを選択)\]**​ セクションでデプロイ済みの管理 Flex Gateway を選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. **\[Create New API (新しい API を作成)\]**​ をクリックします。 6. API 参照名を指定し、アセットタイプとして ​**\[HTTP API\]**​ を選択します。 7. **\[Next (次へ)\]**​ をクリックします。 8. ダウンストリームオプションは設定しないでください。 9. **\[Next (次へ)\]**​ をクリックします。 10. **\[Upstream (アップストリーム)\]**​ ページで次の手順を実行します。 1. 次の URL を ​**\[Upstream URL (アップストリームURL)\]**​ 項目に入力します。 ```none https://jsonplaceholder.typicode.com/ ``` 11. **\[Next (次へ)\]**​ をクリックします。 12. **\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 UI によって、新規作成した API インスタンスの ​**\[API Summary (API サマリー)\]**​ ページに移動します。 公開エンドポイントに対して行われるすべての HTTP 要求が ​`jsonplaceholder`​ サーバーにプロキシされるようになります。 13. API インスタンスをテストするには、公開エンドポイントのプレースホルダーを置き換え、新しいターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET '' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#基本認証ポリシーを使用して-api-を保護する)基本認証ポリシーを使用して API を保護する 1. **\[API Summary (API サマリー)\]**​ ページで、サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 2. **\[Policies (ポリシー)\]**​ ページで、​**\[Add inbound policy (インバウンドポリシーを追加)\]**​ をクリックします。 3. **\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ ポリシーを選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. **\[User Name (ユーザー名)\]**​ に「​`user`​」と入力します。 6. **\[User Password (ユーザーパスワード)\]**​ に「​`password`​」と入力します。 7. **\[Apply (適用)\]**​ をクリックします。 8. 認証を​_使用せずに_​ API インスタンスをテストするには、公開エンドポイントのプレースホルダーを置き換え、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET '' ``` 要求には認証コンテキストが含まれていないため、コマンドは結果として ​`401 (Unauthorized)`​ 状況コードを出力します。 9. 認証を​_使用して_​ API インスタンスをテストするには、公開エンドポイントのプレースホルダーを置き換え、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET '' -u user:password ```
user​ パラメーターと ​password​ パラメーターは、​API Manager​ 経由でポリシーを適用したときに指定した内容と一致する必要があります。
このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) # CloudHub 2.0 での管理 Flex Gateway の使用開始 CloudHub 2.0 で Anypoint 管理 Flex Gateway の使用を開始します。管理 Flex Gateway を作成してデプロイし、API をパブリッシュして、基本認証ポリシーで API を保護します。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、次の手順を完了してください。 - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites)を見直して、必要な管理 Flex Gateway 権限があることを確認します。 - CloudHub 2.0 に非公開スペースを作成するか、既存の非公開スペースにアクセスできることを確認します。非公開スペースを作成するには、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 ## [](#管理-flex-gateway-をデプロイする)管理 Flex Gateway をデプロイする 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. サイドバーで ​**\[Flex Gateways (Flex Gateway)\]**​ をクリックします。 3. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ をクリックします。 4. **\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ をクリックします。 5. **\[Gateway name (ゲートウェイ名)\]**​ を入力します。 6. **\[Deployment target (デプロイメント対象)\]**​ として非公開スペースを選択します。 7. **\[Advanced options (詳細オプション)\]**​ をクリックします。 8. 後でテストできるように管理 Flex Gateway 公開エンドポイントをコピーして保存します。これは ​**\[Public endpoint (公開エンドポイント)\]**​ UI ブロックに表示される HTTP または HTTPs URL です。たとえば、​`[https://my-gateway-abc123.edf456.us-east1.anypoint.mulesoft.com/](https://my-gateway-abc123.edf456.us-east1.anypoint.mulesoft.com/)`​ などです。 9. **\[Save & deploy (保存してデプロイ)\]**​ をクリックします。 UI が新しい管理 Flex Gateway のダッシュボードに戻ります。 10. ゲートウェイの ​**\[Status (状況)\]**​ が ​**\[Running (実行中)\]**​ になるまで待機します。 ## [](#シンプルな-api-のパブリッシュ)シンプルな API のパブリッシュ 1. 管理ゲートウェイのダッシュボードから、​**\[Add API instance (API インスタンスを追加)\]**​ をクリックします。 2. **\[Add API (API を追加)\]**​ ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 3. **\[Select a gateway (ゲートウェイを選択)\]**​ セクションでデプロイ済みの管理 Flex Gateway を選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. **\[Create New API (新しい API を作成)\]**​ をクリックします。 6. API 参照名を指定し、アセットタイプとして ​**\[HTTP API\]**​ を選択します。 7. **\[Next (次へ)\]**​ をクリックします。 8. ダウンストリームオプションは設定しないでください。 9. **\[Next (次へ)\]**​ をクリックします。 10. **\[Upstream (アップストリーム)\]**​ ページで次の手順を実行します。 1. 次の URL を ​**\[Upstream URL (アップストリームURL)\]**​ 項目に入力します。 ```none https://jsonplaceholder.typicode.com/ ``` 11. **\[Next (次へ)\]**​ をクリックします。 12. **\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 UI によって、新規作成した API インスタンスの ​**\[API Summary (API サマリー)\]**​ ページに移動します。 公開エンドポイントに対して行われるすべての HTTP 要求が ​`jsonplaceholder`​ サーバーにプロキシされるようになります。 13. API インスタンスをテストするには、公開エンドポイントのプレースホルダーを置き換え、新しいターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET '' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#基本認証ポリシーを使用して-api-を保護する)基本認証ポリシーを使用して API を保護する 1. **\[API Summary (API サマリー)\]**​ ページで、サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 2. **\[Policies (ポリシー)\]**​ ページで、​**\[Add inbound policy (インバウンドポリシーを追加)\]**​ をクリックします。 3. **\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ ポリシーを選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. **\[User Name (ユーザー名)\]**​ に「​`user`​」と入力します。 6. **\[User Password (ユーザーパスワード)\]**​ に「​`password`​」と入力します。 7. **\[Apply (適用)\]**​ をクリックします。 8. 認証を​_使用せずに_​ API インスタンスをテストするには、公開エンドポイントのプレースホルダーを置き換え、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET '' ``` 要求には認証コンテキストが含まれていないため、コマンドは結果として ​`401 (Unauthorized)`​ 状況コードを出力します。 9. 認証を​_使用して_​ API インスタンスをテストするには、公開エンドポイントのプレースホルダーを置き換え、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET '' -u user:password ```
user​ パラメーターと ​password​ パラメーターは、​API Manager​ 経由でポリシーを適用したときに指定した内容と一致する必要があります。
このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) # CloudHub 2.0 への管理 Flex Gateway のデプロイ 完全にクラウドでホストされたゲートウェイを起動するには、管理 Flex Gateway を CloudHub 2.0 非公開スペースにデプロイします。公開エンドポイントを公開して管理 Flex Gateway を非公開スペースへのイングレスとして設定するか、内部トラフィックのみを処理するようにゲートウェイを設定します。非公開スペースが共有されるそれぞれの環境に 1 つまたは複数の管理ゲートウェイを用意できます。ゲートウェイでは、ゲートウェイの同じ環境からの API または外部ネットワークの API を保護できます。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、以下を確認します。 - ゲートウェイをデプロイするビジネスグループに管理 Flex Gateway リソースがあることを確認します。管理 Flex Gateway リソースをビジネスグループに再割り当てするには、​[「既存のビジネスグループ間のリソースの再配信」](https://docs.mulesoft.com/jp/access-management/business-groups#redistribute-resources)​を参照してください。 - CloudHub 2.0 に非公開スペースを作成したか、他の誰かが作成した非公開スペースへのアクセス権があることを確認します。非公開スペースを作成するには、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 ## [](#管理-flex-gateway-をデプロイする)管理 Flex Gateway をデプロイする 1. Anypoint ユーザー名とパスワードを使用して、 [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインします。 2. **\[Runtime Manager\]**​ を選択します。 3. 管理ゲートウェイをデプロイする環境にいることを確認します。 4. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 5. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ をクリックします。 6. **\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ をクリックします。 7. **\[Gateway Name (ゲートウェイ名)\]**​ を入力します。 8. 管理 Flex Gateway をデプロイする非公開スペースを ​**\[Deployment Target (デプロイメント対象)\]**​ として選択します。 9. **\[Release Channel (リリースチャネル)\]**​ を選択します。

リリースチャネル

説明

Edge

このチャネルでは、新しいマイナーバージョンが 4 か月ごとにリリースされます。最新機能が含まれ、サポート期間が短くなっています。

Long-Term Support (長期サポート)

このチャネルでは、新しいマイナーバージョンが年に 1 回リリースされます。
リリースチャネル間の違いについての詳細は、[Flex Gateway バージョンのライフサイクル](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-version-lifecycle)を参照してください。 10. **\[Version (バージョン)\]**​ を選択します。 さらに新しいバージョンが特に必要でない限り、最新バージョンを選択してください。 11. **\[Flow Plans (フロープラン)\]**​ を選択します。

Size (サイズ)

説明

Small Managed Flex Gateway (小規模管理 Flex Gateway)

テストやステージングの目的に使用します。小規模管理 Flex Gateway では、最大 50 個の API、1 秒あたり最大 100 件の要求をデプロイできます。

Large Managed Flex Gateway (大規模管理 Flex Gateway)

本番目的に使用します。大規模管理 Flex Gateway では、最大 500 個の API、1 秒あたり最大 500 件の要求をデプロイできます。
管理 Flex Gateway についての詳細は、​[「管理 Flex Gateway の制限」](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites#managed-flex-gateway-limits)​を参照してください。 12. **\[Advanced options (詳細オプション)\]**​ を設定します。 イングレス - **Public endpoint (公開エンドポイント)**​: 1. 目的の非公開スペースの ​**\[Domain (ドメイン)\]**​ を選択します。 詳細は、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 2. **\[Host (ホスト)\]**​ を入力します。 3. **\[Add Endpoint (エンドポイントを追加)\]**​ をクリックして異なるドメインにエンドポイントをさらに追加します。 管理 Flex Gateway では非公開スペースのドメインごとに 1 つの ​**\[Public endpoint (公開エンドポイント)\]**​ がサポートされます。 - **Ingress options (イングレスオプション)**​: - **Forward SSL Session (SSL セッションを転送)**​: セッション中に SSL 転送を有効にします。 SSL は、主にクライアント認証で使用されます。詳細は、[クライアント認証の有効化](https://docs.mulesoft.com/jp/anypoint-security/enable-client-authentication)を参照してください。 SSL 転送は、HTTP リクエストヘッダーでクライアント証明書の詳細を転送して、ゲートウェイで使用できるようにします。 これらの項目は、認証済みクライアントを識別し、ゲートウェイポリシーが ID を判別して使用できるようにします。 次のヘッダーを使用できます。
ヘッダー名 値

x-ssl-client-verify

SUCCESS/FAIL

x-ssl-issuer

クライアント証明書発行者

x-ssl-client-serial

クライアント証明書シリアル番号

x-ssl-client-dn

クライアント証明書 DN 項目のコンテンツ

x-ssl-client-cert

クライアント証明書のコンテンツ
- **Last-mile Security (Last -Mile セキュリティ)** 転送された HTTPS 接続の TLS の終了と復号化がゲートウェイで行われることを指定します。 プロパティ 管理 Flex Gateway が応答またはアイドル接続を待機する期間を設定するには、タイムアウトプロパティを設定します。

パラメーター

説明

Upstream Connection Idle Timeout (アップストリーム接続アイドルタイムアウト)

アップストリーム接続がクライアント要求を受信せずにアイドル状態を続けられる時間。アップストリーム応答はこのタイムアウトに含まれません。

Upstream Response Timeout (アップストリーム応答タイムアウト)

Flex Gateway が要求を送信した時点からアップストリームサービスが応答する必要がある時間。

ストリームアイドルタイムアウト

ストリームが追加のクライアント要求またはアップストリーム応答を受信せずにアイドル状態を続けられる時間。
ログ - **Forward application logs to Anypoint Monitoring (Anypoint Monitoring にアプリケーションログを転送)**​: Anypoint Monitoring に Flex Gateway ログを転送します。無効にすると、ログは Runtime Manager のみで使用できます。 - **Additional Log Levels (追加のログレベル)**​: - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (警告)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ トレース - **Distributed tracing (分散トレース)**​: 管理 Flex Gateway の OpenTelemetry 分散トレースデータを生成できます。有効にすると、サンプリングパーセンテージを設定できます。 - **Sampling percentage (サンプリングパーセンテージ)**​: 全体の分散トレースサンプリングパーセンテージを設定します。この設定は、​`全体`​のサンプリングパーセンテージに対応します。ここでサンプリングパーセンテージを 0 以外の値に設定すると、​`クライアント`​および​`ランダム`​のサンプリングパーセンテージはデフォルトで 100% に設定されます。 トレースポリシーを使用して API ごとのサンプリングパーセンテージのみを指定する場合は、​**\[Sampling percentage (サンプリングパーセンテージ)\]**​ を 0 に設定してください。 13. **\[Save & deploy (保存してデプロイ)\]**​ をクリックします。 ## [](#管理-flex-gateway-を設定を編集する)管理 Flex Gateway を設定を編集する 管理 Flex Gateway を設定を編集する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\] > \[Flex Gateways (Flex Gateway)\]**​ を選択します。 2. 管理 Flex Gateway 名をクリックします。 3. ナビゲーションメニューで \[Settings (設定)\] をクリックします。 4. 必要な編集を行います。 5. **\[Apply changes (変更を適用)\]**​ をクリックします。 ## [](#エンドポイントを削除する)エンドポイントを削除する エンドポイントを変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\] > \[Flex Gateways (Flex Gateway)\]**​ を選択します。 2. 管理 Flex Gateway 名をクリックします。 3. ナビゲーションメニューで \[Settings (設定)\] をクリックします。 4. **\[Advanced options (詳細オプション)\]**​ をクリックします。 5. **\[Public endpoint (公開エンドポイント)\]**​ 行で、​**\[X\]**​ (削除) をクリックします。 6. **\[Apply changes (変更を適用)\]**​ をクリックします。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) # CloudHub 2.0 への管理 Flex Gateway のデプロイ 完全にクラウドでホストされたゲートウェイを起動するには、管理 Flex Gateway を CloudHub 2.0 非公開スペースにデプロイします。公開エンドポイントを公開して管理 Flex Gateway を非公開スペースへのイングレスとして設定するか、内部トラフィックのみを処理するようにゲートウェイを設定します。非公開スペースが共有されるそれぞれの環境に 1 つまたは複数の管理ゲートウェイを用意できます。ゲートウェイでは、ゲートウェイの同じ環境からの API または外部ネットワークの API を保護できます。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、以下を確認します。 - ゲートウェイをデプロイするビジネスグループに管理 Flex Gateway リソースがあることを確認します。管理 Flex Gateway リソースをビジネスグループに再割り当てするには、​[「既存のビジネスグループ間のリソースの再配信」](https://docs.mulesoft.com/jp/access-management/business-groups#redistribute-resources)​を参照してください。 - CloudHub 2.0 に非公開スペースを作成したか、他の誰かが作成した非公開スペースへのアクセス権があることを確認します。非公開スペースを作成するには、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 ## [](#管理-flex-gateway-をデプロイする)管理 Flex Gateway をデプロイする 1. Anypoint ユーザー名とパスワードを使用して、 [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインします。 2. **\[Runtime Manager\]**​ を選択します。 3. 管理ゲートウェイをデプロイする環境にいることを確認します。 4. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 5. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ をクリックします。 6. **\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ をクリックします。 7. **\[Gateway Name (ゲートウェイ名)\]**​ を入力します。 8. 管理 Flex Gateway をデプロイする非公開スペースを ​**\[Deployment Target (デプロイメント対象)\]**​ として選択します。 9. **\[Release Channel (リリースチャネル)\]**​ を選択します。

リリースチャネル

説明

Edge

このチャネルでは、新しいマイナーバージョンが 4 か月ごとにリリースされます。最新機能が含まれ、サポート期間が短くなっています。

Long-Term Support (長期サポート)

このチャネルでは、新しいマイナーバージョンが年に 1 回リリースされます。
リリースチャネル間の違いについての詳細は、[Flex Gateway バージョンのライフサイクル](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-version-lifecycle)を参照してください。 10. **\[Version (バージョン)\]**​ を選択します。 さらに新しいバージョンが特に必要でない限り、最新バージョンを選択してください。 11. **\[Flow Plans (フロープラン)\]**​ を選択します。

Size (サイズ)

説明

Small Managed Flex Gateway (小規模管理 Flex Gateway)

テストやステージングの目的に使用します。小規模管理 Flex Gateway では、最大 50 個の API、1 秒あたり最大 100 件の要求をデプロイできます。

Large Managed Flex Gateway (大規模管理 Flex Gateway)

本番目的に使用します。大規模管理 Flex Gateway では、最大 500 個の API、1 秒あたり最大 500 件の要求をデプロイできます。
管理 Flex Gateway についての詳細は、​[「管理 Flex Gateway の制限」](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites#managed-flex-gateway-limits)​を参照してください。 12. **\[Advanced options (詳細オプション)\]**​ を設定します。 イングレス - **Public endpoint (公開エンドポイント)**​: 1. 目的の非公開スペースの ​**\[Domain (ドメイン)\]**​ を選択します。 詳細は、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 2. **\[Host (ホスト)\]**​ を入力します。 3. **\[Add Endpoint (エンドポイントを追加)\]**​ をクリックして異なるドメインにエンドポイントをさらに追加します。 管理 Flex Gateway では非公開スペースのドメインごとに 1 つの ​**\[Public endpoint (公開エンドポイント)\]**​ がサポートされます。 - **Ingress options (イングレスオプション)**​: - **Forward SSL Session (SSL セッションを転送)**​: セッション中に SSL 転送を有効にします。 SSL は、主にクライアント認証で使用されます。詳細は、[クライアント認証の有効化](https://docs.mulesoft.com/jp/anypoint-security/enable-client-authentication)を参照してください。 SSL 転送は、HTTP リクエストヘッダーでクライアント証明書の詳細を転送して、ゲートウェイで使用できるようにします。 これらの項目は、認証済みクライアントを識別し、ゲートウェイポリシーが ID を判別して使用できるようにします。 次のヘッダーを使用できます。
ヘッダー名 値

x-ssl-client-verify

SUCCESS/FAIL

x-ssl-issuer

クライアント証明書発行者

x-ssl-client-serial

クライアント証明書シリアル番号

x-ssl-client-dn

クライアント証明書 DN 項目のコンテンツ

x-ssl-client-cert

クライアント証明書のコンテンツ
- **Last-mile Security (Last -Mile セキュリティ)** 転送された HTTPS 接続の TLS の終了と復号化がゲートウェイで行われることを指定します。 Properties (プロパティ) 管理 Flex Gateway が応答またはアイドル接続を待機する期間を設定するには、タイムアウトプロパティを設定します。

パラメーター

説明

Upstream Connection Idle Timeout (アップストリーム接続アイドルタイムアウト)

アップストリーム接続がクライアント要求を受信せずにアイドル状態を続けられる時間。アップストリーム応答はこのタイムアウトに含まれません。

Upstream Response Timeout (アップストリーム応答タイムアウト)

Flex Gateway が要求を送信した時点からアップストリームサービスが応答する必要がある時間。

ストリームアイドルタイムアウト

ストリームが追加のクライアント要求またはアップストリーム応答を受信せずにアイドル状態を続けられる時間。
Logging (ログ) - **Forward application logs to Anypoint Monitoring (Anypoint Monitoring にアプリケーションログを転送)**​: Anypoint Monitoring に Flex Gateway ログを転送します。無効にすると、ログは Runtime Manager のみで使用できます。 - **Additional Log Levels (追加のログレベル)**​: - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (警告)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 13. **\[Save & deploy (保存してデプロイ)\]**​ をクリックします。 ## [](#管理-flex-gateway-を設定を編集する)管理 Flex Gateway を設定を編集する 管理 Flex Gateway 設定を編集する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\] > \[Flex Gateways (Flex Gateway)\]**​ を選択します。 2. 管理 Flex Gateway 名をクリックします。 3. ナビゲーションメニューで \[Settings (設定)\] をクリックします。 4. 必要な編集を行います。 5. **\[Apply changes (変更を適用)\]**​ をクリックします。 ## [](#エンドポイントを削除する)エンドポイントを削除する エンドポイントを変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\] > \[Flex Gateways (Flex Gateway)\]**​ を選択します。 2. 管理 Flex Gateway 名をクリックします。 3. ナビゲーションメニューで \[Settings (設定)\] をクリックします。 4. **\[Advanced options (詳細オプション)\]**​ をクリックします。 5. **\[Public endpoint (公開エンドポイント)\]**​ 行で、​**\[X\]**​ (削除) をクリックします。 6. **\[Apply changes (変更を適用)\]**​ をクリックします。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) # Docker コマンドの問題のトラブルシューティング `docker`​ コマンドで返されるエラーのトラブルシューティング - [Docker が開始されない](#daemon-bad-response) - [Reg Facade エラー (400 Bad Request (400 不正な要求))](#bad-request) ## [](#daemon-bad-response)Docker が開始されない Docker が開始されていない場合、​`docker`​ コマンドで次のようなエラーメッセージが返されます。 - Error response from daemon: Bad response from Docker engine - ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? このエラーが発生した場合、Docker を開始します。 ## [](#bad-request)Reg Facade エラー (400 Bad Request (400 不正な要求)) `docker run`​ を使用してゲートウェイを登録するときに、次のエラーが発生する可能性があります。 \[flexctl\]\[error\] reg facade call returned error response: HTTP/1.1 400 Bad Request このエラーの理由は、エラーメッセージ内で確認できます。一般的な原因は次のとおりです。 - `an active target with the same name already exists in this organization and environment (同じ名前のアクティブな対象がすでにこの組織および環境に存在します)` この問題を回避するには、登録コマンドを実行するときにゲートウェイの​_一意の名前_​を指定します。その名前の前の登録が成功している場合でも、​_同じ名前を再利用することはできません_​。このエラーが発生すると、コマンドによって​_空の_​ ​`registration.yaml`​ が生成されて、再登録できなくなります。​_そのため_​、ゲートウェイをクラスターにデプロイするときにこのファイルを使用しようとすると、エラーが発生します。 - `no valid registration token was found (有効な登録トークンがありませんでした)` この問題を回避するには、Kubernetes の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページを更新して、コマンドの新しいトークンを生成し、登録コマンドを再実行します。 ## [](#関連情報)関連情報 - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-requests) - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-admin-api) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) # Docker コマンドの問題のトラブルシューティング `docker`​ コマンドで返されるエラーのトラブルシューティング - [Docker が開始されない](#daemon-bad-response) - [Reg Facade エラー (400 Bad Request (400 不正な要求))](#bad-request) ## [](#daemon-bad-response)Docker が開始されない Docker が開始されていない場合、​`docker`​ コマンドで次のようなエラーメッセージが返されます。 - Error response from daemon: Bad response from Docker engine - ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? このエラーが発生した場合、Docker を開始します。 ## [](#bad-request)Reg Facade エラー (400 Bad Request (400 不正な要求)) `docker run`​ を使用してゲートウェイを登録するときに、次のエラーが発生する可能性があります。 \[flexctl\]\[error\] reg facade call returned error response: HTTP/1.1 400 Bad Request このエラーの理由は、エラーメッセージ内で確認できます。一般的な原因は次のとおりです。 - `an active target with the same name already exists in this organization and environment (同じ名前のアクティブな対象がすでにこの組織および環境に存在します)` この問題を回避するには、登録コマンドを実行するときにゲートウェイの​_一意の名前_​を指定します。その名前の前の登録が成功している場合でも、​_同じ名前を再利用することはできません_​。このエラーが発生すると、コマンドによって​_空の_​ ​`registration.yaml`​ が生成されて、再登録できなくなります。​_そのため_​、ゲートウェイをクラスターにデプロイするときにこのファイルを使用しようとすると、エラーが発生します。 - `no valid registration token was found (有効な登録トークンがありませんでした)` この問題を回避するには、Kubernetes の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページを更新して、コマンドの新しいトークンを生成し、登録コマンドを再実行します。 ## [](#関連情報)関連情報 - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-requests) - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-admin-api) - [Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) # Docker コマンドの問題のトラブルシューティング `docker`​ コマンドで返されるエラーのトラブルシューティング - [Docker が開始されない](#daemon-bad-response) - [Reg Facade エラー (400 Bad Request (400 不正な要求))](#bad-request) ## [](#daemon-bad-response)Docker が開始されない Docker が開始されていない場合、​`docker`​ コマンドで次のようなエラーメッセージが返されます。 - Error response from daemon: Bad response from Docker engine - ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? このエラーが発生した場合、Docker を開始します。 ## [](#bad-request)Reg Facade エラー (400 Bad Request (400 不正な要求)) `docker run`​ を使用してゲートウェイを登録するときに、次のエラーが発生する可能性があります。 \[flexctl\]\[error\] reg facade call returned error response: HTTP/1.1 400 Bad Request このエラーの理由は、エラーメッセージ内で確認できます。一般的な原因は次のとおりです。 - `an active target with the same name already exists in this organization and environment (同じ名前のアクティブな対象がすでにこの組織および環境に存在します)` この問題を回避するには、登録コマンドを実行するときにゲートウェイの​_一意の名前_​を指定します。その名前の前の登録が成功している場合でも、​_同じ名前を再利用することはできません_​。このエラーが発生すると、コマンドによって​_空の_​ ​`registration.yaml`​ が生成されて、再登録できなくなります。​_そのため_​、ゲートウェイをクラスターにデプロイするときにこのファイルを使用しようとすると、エラーが発生します。 - `no valid registration token was found (有効な登録トークンがありませんでした)` この問題を回避するには、Kubernetes の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページを更新して、コマンドの新しいトークンを生成し、登録コマンドを再実行します。 ## [](#関連情報)関連情報 - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-requests) - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-admin-api) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) # Flex Gateway API アラートの使用 API アラートを使用することで、次のような API の異常動作を知らせるためのメール通知を追加して設定できます。 - 60 秒を超える API 応答時間 - 30 秒間で 1000 件を超える API 要求 下記の​[「API アラートの追加」](#add-api-alerts)​を参照してください。 ## [](#types-of-api-alerts)API アラートのタイプ 次のアラートを追加すると、それぞれの状況を通知することができます。 - Total Request Count (合計要求数): ユーザーが指定された期間で許可されている回数を超えて API にアクセスを要求する。1 ～ 999999999 の期間値を指定します。データのバーストを回避するために、期間は絶対時間 (分) 範囲ではなく、スライディングウィンドウとして実装されます。 [「スライディングウィンドウ」](https://www.techopedia.com/definition/869/sliding-window)​を参照してください。 - Average Response Time (平均応答時間): API の応答時間が指定されたタイムアウト期間を超えている。 - Response Codes (応答コード): 要求を受け取ると、API は HTTP コードの 400、401、403、404、408、500、502、503、または 3 桁のカスタムコードを返します。 - Policy Violation (ポリシー違反): API を管理するポリシーで違反が発生している。 ## [](#api-アラートの仕組み)API アラートの仕組み API アラートは以下の場合にのみトリガーされます。 - API の状態が変化した 新しく作成したアラートで状態が定義されていない場合は、最初の状態の変更が検出されない可能性があります。 - アラート条件が指定期間に渡って成立した たとえば、API が HTTP コード 500 を 10 分間に 5 回以上返した場合にトリガーされるようにアラートを設定してある場合、HTTP コード 500 が 10 分間に 1 回しか返されなかったときには、そのアラートはトリガーされません。 API アラートを設定するときには、アラートに関するメール通知を受信するビジネスグループユーザーや組織外のユーザーを選択できます。通知には、重要度レベルで指定されたようにアラートをトリガーするイベントに関する情報が含まれます。
API アラートは ​no-reply@mulesoft.com​ から送信されます。これはカスタマイズできません。
- 1 つは、アラートについて説明するメールです。 `Your API, CesarDemoAPI - Basic:151 (Environment: "NewOne"), has received greater than 2 requests within 1 consecutive periods of 1 minutes.` - もう 1 つは、アラートがいつ解決されるかを通知するメールです。 `Your API Version, jsonplaceholderapi - 1.0.development, is no longer in an alert state.The number of policy violations was not greater than 1 in the last 1 consecutive periods of 1 minutes.` API Manager は、最初の 2 件の通知メールのセットを送信した後で、次のアラート期間が始まるまでアラートのリスンを停止します。この方法で反復する通知メールが防止されます。 ## [](#始める前に)始める前に アラートを表示および削除するには、次を確認してください。 - API アラートを表示および削除するための​**「Manage Alerts (アラートの管理)」**​権限。 - アラートの表示のみを行うための​**「View Alerts (アラートの表示)」**​権限。 ## [](#add-api-alerts)API アラートの追加 API を追跡および管理するには、1 つ以上の API アラートを API インスタンスに追加できます。各自の要件に基づいて、さまざまな​[種別のアラート](#types-of-api-alerts)​を追加します。 次の表は、API インスタンスごとのアクティブなアラート数を示しています。
価格設定パッケージ アクティブなアラート

Anypoint Integration Starter

最大 6 個

Anypoint Integration Advanced

最大 10 個

Gold サブスクリプション

最大 6 個

Platinum サブスクリプション

最大 6 個

Titanium サブスクリプション

最大 10 個
すべてのサブスクリプションで、アクティブでないアラートは必要に応じて何個でも使用できます。 アクティブなアラートの最大数に達した場合は、アクティブなアラートを一時停止または削除することで、新しいアラートを作成できるようになります。 アラートは、作成時にデフォルトで有効化されます。この設定は変更できません。
自動ポリシー​で保護されている API インスタンスにはアラートを追加できません。
API アラートを追加する手順は、次のとおりです。 1. **\[API Manager\]**​ > ​**\[API Administration (API 管理)\]**​ に移動して、アラートを追加する API インスタンスをクリックします。 2. 左側のナビゲーションペインから、​**\[Alerts (アラート)\]**​ > ​**\[New alert (新規アラート)\]**​ を選択します。 3. 表示されているアラートオプションの値を指定します。 - **Name (名前)**​: アラート名を入力します (例: `trial-alert`​)。不要な場合はアラートをいつでも削除できます。 - **Severity (重要度)**​: アラートの重要度を選択します。 - **Info (情報)** トリガーされた時点で直ちに対応する必要がないアラートに割り当てます。この重要度は、メトリクスを受動的に監視する必要があることを示しています。 - **Warning (警告)** トリガーされた時点で直ちに対応する必要があるアラートに割り当てます。この重要度は、アラートを綿密に監視する必要があることを示しています。 - **Critical (重大)** トリガーされた時点で直ちに対応する必要があるアラートに割り当てます。この重要度は、アラートに直ちに対応する必要があることを示しています。 4. アラート条件を指定します。 - **Metric (メトリクス)** アラートをトリガーする条件。 - **Logic (ロジック)** **\[When number of occurrences are (発生回数)\]**​ 項目と ​**\[For at least \[number of\] minutes (\[ \] 分以上)\]**​ 項目で定義される発生率に基づいた、アラートをトリガーするタイミング。 アラート条件には最大 10 個の応答コードを選択できます。 5. メール通知を設定します。 - **Subject (件名)** アラートがトリガーされたときに送信されるアラートメールの件名。件名には変数を含めることができます。​[変数定義](#alert-variables)​を参照してください。 - **Message (メッセージ)** アラートがトリガーされたときに送信されるメールの本文テキスト。メッセージ本文には変数を含めることができます。​[変数定義](#alert-variables)​を参照してください。 - **Recipients (受信者)** アラートメールの受信者。最大 20 個のプラットフォームユーザー ID を選択し、最大 20 個のメールアドレスを入力できます。 6. **\[Create (作成)\]**​ をクリックします。 アラートの作成中は ​**\[Pending (保留中)\]**​ と表示されます。API がトラフィックを受け取ると、アラートの状態は ​**\[OK\]**​ に変わります。また、値に応じて、アラートは ​**\[OK\]**​ または ​**\[Alerting (アラート)\]**​ に移行します。 ### [](#アラートメールテンプレート)アラートメールテンプレート 基本アラートメールの ​**\[Subject (件名)\]**​ 項目と ​**\[Message (メッセージ)\]**​ 項目で次の変数を使用できます。 各変数の説明については、​[変数定義](#alert-variables)​を参照してください。
Table 1. アラートの変数
アラート 該当する変数

Total Request Count (合計要求数)​

  • ${severity}​

  • ${operator}​

  • ${threshold}​

  • ${period}​

  • ${value}​

  • ${condition}​

  • ${organization}​

  • ${environment}​

  • ${apiLink}​

  • ${dashboardLink}​

  • ${api}​

  • ${policy}​

Average Response Time (平均応答時間)

Response Codes (応答コード)

Policy Violations (ポリシー違反)​
Table 2. 変数定義
変数 定義

${apiLink}

トリガーされた API の URL。

${alertState}

アラートがトリガーされたときのアラートの状態。

使用可能な値は ​OK​ または ​Alerting​ です。

${comparison}

* Above (上回る)、Above or equal (上回るまたは等しい)、Equal (等しい)、Below or equal (下回るまたは等しい)、Below (下回る)

${condition}

アラートがトリガーされるメトリクス。

${environment}

リソースがデプロイされている環境の名前。

${operator}

< > =​ などの演算子。

${organization}

アラートを所有する組織の名前。

${period}

測定する期間。

${severity}

アラートの重要度。

${threshold}

アラートをトリガーする期間での数

${value}

アラートをトリガーするメトリクスの値。
## [](#enabling-alerts)API アラートの一時停止と編集 アラートを一時停止すると、アラートは ​**\[Paused (一時停止)\]**​ に移行します。 既存のアラートは、次の手順で編集できます。 1. API Manager の左側のナビゲーションバーで、​**\[API Administration (API 管理)\]**​ をクリックします。 2. API インスタンス、および編集するバージョンをクリックし、​**\[Alerts (アラート)\]**​ をクリックします。 3. 編集したいアラートの 3 つのドットのアイコン (​![5%](/mulesoft/current/ja-jp/gateway/1.10/_images/three-dots-menu.png)​) をクリックして、​**\[Edit (編集)\]**​ を選択します。 ![アラートの名前、基づいているメトリクス、重大度、状態、アラートが有効化されているかどうかを示すテーブル](/mulesoft/current/ja-jp/gateway/1.10/_images/flex-alerts-edit.png) ## [](#アラートの表示と削除)アラートの表示と削除 アラートを表示および削除する手順は、次のとおりです。 1. API Manager から、​**\[API Administration (API 管理)\] で API インスタンス**​をクリックし、​**\[Alerts (アラート)\]**​ を選択します。 ![「Test fail alert (テスト失敗アラート)」という名前の展開されたアラートが表示されている API サービスコントラクトアラートのテーブル](/mulesoft/current/ja-jp/gateway/1.10/_images/view-add-alert.png) 2. リスト内のアラートを展開します。 アラートのオプションに関する詳細が表示されます。 3. 削除するアラートの 3 つのドットメニュー (​![メニューとして縦に並べられた 3 つのドット](/mulesoft/current/ja-jp/gateway/1.10/_images/three-dots-menu.png)​) から ​**\[Delete (削除)\]**​ をクリックします。アラートの編集中に削除することもできます。 # Flex Gateway API アラートの使用 接続モードで Flex Gateway の API アラートを使用することで、次のような API の異常動作を知らせるためのメール通知を追加して設定できます。 - 60 秒を超える API 応答時間 - 30 秒間で 1000 件を超える API 要求 下記の​[「API アラートの追加」](#add-api-alerts)​を参照してください。 ## [](#types-of-api-alerts)API アラートのタイプ 次のアラートを追加すると、それぞれの状況を通知することができます。 - Total Request Count (合計要求数): ユーザーが指定された期間で許可されている回数を超えて API にアクセスを要求する。1 ～ 999999999 の期間値を指定します。データのバーストを回避するために、期間は絶対時間 (分) 範囲ではなく、スライディングウィンドウとして実装されます。 [「スライディングウィンドウ」](https://www.techopedia.com/definition/869/sliding-window)​を参照してください。 - Average Response Time (平均応答時間): API の応答時間が指定されたタイムアウト期間を超えている。 - Response Codes (応答コード): 要求を受け取ると、API は HTTP コードの 400、401、403、404、408、500、502、503、または 3 桁のカスタムコードを返します。 - Policy Violation (ポリシー違反): API を管理するポリシーで違反が発生している。 ## [](#api-アラートの仕組み)API アラートの仕組み API アラートは以下の場合にのみトリガーされます。 - API の状態が変化した 新しく作成したアラートで状態が定義されていない場合は、最初の状態の変更が検出されない可能性があります。 - アラート条件が指定期間に渡って成立した たとえば、API が HTTP コード 500 を 10 分間に 5 回以上返した場合にトリガーされるようにアラートを設定してある場合、HTTP コード 500 が 10 分間に 1 回しか返されなかったときには、そのアラートはトリガーされません。 API アラートを設定するときには、アラートに関するメール通知を受信するビジネスグループユーザーや組織外のユーザーを選択できます。通知には、重要度レベルで指定されたようにアラートをトリガーするイベントに関する情報が含まれます。
API アラートは ​no-reply@mulesoft.com​ から送信されます。これはカスタマイズできません。
- 1 つは、アラートについて説明するメールです。 `Your API, CesarDemoAPI - Basic:151 (Environment: "NewOne"), has received greater than 2 requests within 1 consecutive periods of 1 minutes.` - もう 1 つは、アラートがいつ解決されるかを通知するメールです。 `Your API Version, jsonplaceholderapi - 1.0.development, is no longer in an alert state.The number of policy violations was not greater than 1 in the last 1 consecutive periods of 1 minutes.` API Manager は、最初の 2 件の通知メールのセットを送信した後で、次のアラート期間が始まるまでアラートのリスンを停止します。この方法で反復する通知メールが防止されます。 ## [](#始める前に)始める前に アラートを表示および削除するには、次を確認してください。 - API アラートを表示および削除するための​**「Manage Alerts (アラートの管理)」**​権限。 - アラートの表示のみを行うための​**「View Alerts (アラートの表示)」**​権限。 ## [](#add-api-alerts)API アラートの追加 API を追跡および管理するには、1 つ以上の API アラートを API インスタンスに追加できます。各自の要件に基づいて、さまざまな​[種別のアラート](#types-of-api-alerts)​を追加します。 次の表は、API インスタンスごとのアクティブなアラート数を示しています。
価格設定パッケージ アクティブなアラート

Anypoint Integration Starter

最大 6 個

Anypoint Integration Advanced

最大 10 個

Gold サブスクリプション

最大 6 個

Platinum サブスクリプション

最大 6 個

Titanium サブスクリプション

最大 10 個
すべてのサブスクリプションで、アクティブでないアラートは必要に応じて何個でも使用できます。 アクティブなアラートの最大数に達した場合は、アクティブなアラートを一時停止または削除することで、新しいアラートを作成できるようになります。 アラートは、作成時にデフォルトで有効化されます。この設定は変更できません。
自動ポリシー​で保護されている API インスタンスにはアラートを追加できません。
API アラートを追加する手順は、次のとおりです。 1. **\[API Manager\]**​ > ​**\[API Administration (API 管理)\]**​ に移動して、アラートを追加する API インスタンスをクリックします。 2. 左側のナビゲーションペインから、​**\[Alerts (アラート)\]**​ > ​**\[New alert (新規アラート)\]**​ を選択します。 3. 表示されているアラートオプションの値を指定します。 - **Name (名前)**​: アラート名を入力します (例: `trial-alert`​)。不要な場合はアラートをいつでも削除できます。 - **Severity (重要度)**​: アラートの重要度を選択します。 - **Info (情報)** トリガーされた時点で直ちに対応する必要がないアラートに割り当てます。この重要度は、メトリクスを受動的に監視する必要があることを示しています。 - **Warning (警告)** トリガーされた時点で直ちに対応する必要があるアラートに割り当てます。この重要度は、アラートを綿密に監視する必要があることを示しています。 - **Critical (重大)** トリガーされた時点で直ちに対応する必要があるアラートに割り当てます。この重要度は、アラートに直ちに対応する必要があることを示しています。 4. アラート条件を指定します。 - **Metric (メトリクス)** アラートをトリガーする条件。 - **Logic (ロジック)** **\[When number of occurrences are (発生回数)\]**​ 項目と ​**\[For at least \[number of\] minutes (\[ \] 分以上)\]**​ 項目で定義される発生率に基づいた、アラートをトリガーするタイミング。 アラート条件には最大 10 個の応答コードを選択できます。 5. メール通知を設定します。 - **Subject (件名)** アラートがトリガーされたときに送信されるアラートメールの件名。件名には変数を含めることができます。​[変数定義](#alert-variables)​を参照してください。 - **メッセージ** アラートがトリガーされたときに送信されるメールの本文テキスト。メッセージ本文には変数を含めることができます。​[変数定義](#alert-variables)​を参照してください。 - **Recipients (受信者)** アラートメールの受信者。最大 20 個のプラットフォームユーザー ID を選択し、最大 20 個のメールアドレスを入力できます。 6. **\[Create (作成)\]**​ をクリックします。 アラートの作成中は ​**\[Pending (保留中)\]**​ と表示されます。API がトラフィックを受け取ると、アラートの状態は ​**\[OK\]**​ に変わります。また、値に応じて、アラートは ​**\[OK\]**​ または ​**\[Alerting (アラート)\]**​ に移行します。 ### [](#アラートメールテンプレート)アラートメールテンプレート 基本アラートメールの ​**\[Subject (件名)\]**​ 項目と ​**\[Message (メッセージ)\]**​ 項目で次の変数を使用できます。 各変数の説明については、​[変数定義](#alert-variables)​を参照してください。
Table 1. アラートの変数
アラート 該当する変数

Total Request Count (合計要求数)​

  • ${severity}​

  • ${operator}​

  • ${threshold}​

  • ${period}​

  • ${value}​

  • ${condition}​

  • ${organization}​

  • ${environment}​

  • ${apiLink}​

  • ${dashboardLink}​

  • ${api}​

  • ${policy}​

Average Response Time (平均応答時間)

Response Codes (応答コード)

Policy Violations (ポリシー違反)​
Table 2. 変数定義
変数 定義

${apiLink}

トリガーされた API の URL。

${alertState}

アラートがトリガーされたときのアラートの状態。

使用可能な値は ​OK​ または ​Alerting​ です。

${comparison}

* Above (上回る)、Above or equal (上回るまたは等しい)、Equal (等しい)、Below or equal (下回るまたは等しい)、Below (下回る)

${condition}

アラートがトリガーされるメトリクス。

${environment}

リソースがデプロイされている環境の名前。

${operator}

< > =​ などの演算子。

${organization}

アラートを所有する組織の名前。

${period}

測定する期間。

${severity}

アラートの重要度。

${threshold}

アラートをトリガーする期間での数

${value}

アラートをトリガーするメトリクスの値。
## [](#enabling-alerts)API アラートの一時停止と編集 アラートを一時停止すると、アラートは ​**\[Paused (一時停止)\]**​ に移行します。 既存のアラートは、次の手順で編集できます。 1. API Manager の左側のナビゲーションバーで、​**\[API Administration (API 管理)\]**​ をクリックします。 2. API インスタンス、および編集するバージョンをクリックし、​**\[Alerts (アラート)\]**​ をクリックします。 3. 編集したいアラートの 3 つのドットのアイコン (​![5%](/mulesoft/current/ja-jp/gateway/1.8/_images/three-dots-menu.png)​) をクリックして、​**\[Edit (編集)\]**​ を選択します。 ![アラートの編集](/mulesoft/current/ja-jp/gateway/1.8/_images/flex-alerts-edit.png) ## [](#api-アラートのテスト)API アラートのテスト API アラートをテストするには、まず Flex Gateway を作成します。以下の手順に従って Flex Gateway を開始してアラートをテストしてください。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) 2. Flex Gateway の登録と実行 - [接続モードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - [ローカルモードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) 3. Flex Gateway による API の管理 - [接続モードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-configure) - [ローカルモードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configure) ## [](#アラートの表示と削除)アラートの表示と削除 アラートを表示および削除する手順は、次のとおりです。 1. API Manager から、​**\[API Administration (API 管理)\] で API インスタンス**​をクリックし、​**\[Alerts (アラート)\]**​ を選択します。 ![アラートの表示と追加](/mulesoft/current/ja-jp/gateway/1.8/_images/view-add-alert.png) 2. リスト内のアラートを展開します。 アラートのオプションに関する詳細が表示されます。 3. 削除したいアラートの 3 つのドットのアイコン (​![5%](/mulesoft/current/ja-jp/gateway/1.8/_images/three-dots-menu.png)​) をクリックして、​**\[Delete (削除)\]**​ を選択します。アラートの編集中に削除することもできます。 # Flex Gateway API アラートの使用 API アラートを使用することで、次のような API の異常動作を知らせるためのメール通知を追加して設定できます。 - 60 秒を超える API 応答時間 - 30 秒間で 1000 件を超える API 要求 下記の​[「API アラートの追加」](#add-api-alerts)​を参照してください。 ## [](#types-of-api-alerts)API アラートのタイプ 次のアラートを追加すると、それぞれの状況を通知することができます。 - Total Request Count (合計要求数): ユーザーが指定された期間で許可されている回数を超えて API にアクセスを要求する。1 ～ 999999999 の期間値を指定します。データのバーストを回避するために、期間は絶対時間 (分) 範囲ではなく、スライディングウィンドウとして実装されます。 [「スライディングウィンドウ」](https://www.techopedia.com/definition/869/sliding-window)​を参照してください。 - Average Response Time (平均応答時間): API の応答時間が指定されたタイムアウト期間を超えている。 - Response Codes (応答コード): 要求を受け取ると、API は HTTP コードの 400、401、403、404、408、500、502、503、または 3 桁のカスタムコードを返します。 - Policy Violation (ポリシー違反): API を管理するポリシーで違反が発生している。 ## [](#api-アラートの仕組み)API アラートの仕組み API アラートは以下の場合にのみトリガーされます。 - API の状態が変化した 新しく作成したアラートで状態が定義されていない場合は、最初の状態の変更が検出されない可能性があります。 - アラート条件が指定期間に渡って成立した たとえば、API が HTTP コード 500 を 10 分間に 5 回以上返した場合にトリガーされるようにアラートを設定してある場合、HTTP コード 500 が 10 分間に 1 回しか返されなかったときには、そのアラートはトリガーされません。 API アラートを設定するときには、アラートに関するメール通知を受信するビジネスグループユーザーや組織外のユーザーを選択できます。通知には、重要度レベルで指定されたようにアラートをトリガーするイベントに関する情報が含まれます。
API アラートは ​no-reply@mulesoft.com​ から送信されます。これはカスタマイズできません。
- 1 つは、アラートについて説明するメールです。 `Your API, CesarDemoAPI - Basic:151 (Environment: "NewOne"), has received greater than 2 requests within 1 consecutive periods of 1 minutes.` - もう 1 つは、アラートがいつ解決されるかを通知するメールです。 `Your API Version, jsonplaceholderapi - 1.0.development, is no longer in an alert state.The number of policy violations was not greater than 1 in the last 1 consecutive periods of 1 minutes.` API Manager は、最初の 2 件の通知メールのセットを送信した後で、次のアラート期間が始まるまでアラートのリスンを停止します。この方法で反復する通知メールが防止されます。 ## [](#始める前に)始める前に アラートを表示および削除するには、次を確認してください。 - API アラートを表示および削除するための​**「Manage Alerts (アラートの管理)」**​権限。 - アラートの表示のみを行うための​**「View Alerts (アラートの表示)」**​権限。 ## [](#add-api-alerts)API アラートの追加 API を追跡および管理するには、1 つ以上の API アラートを API インスタンスに追加できます。各自の要件に基づいて、さまざまな​[種別のアラート](#types-of-api-alerts)​を追加します。 次の表は、API インスタンスごとのアクティブなアラート数を示しています。
価格設定パッケージ アクティブなアラート

Anypoint Integration Starter

最大 6 個

Anypoint Integration Advanced

最大 10 個

Gold サブスクリプション

最大 6 個

Platinum サブスクリプション

最大 6 個

Titanium サブスクリプション

最大 10 個
すべてのサブスクリプションで、アクティブでないアラートは必要に応じて何個でも使用できます。 アクティブなアラートの最大数に達した場合は、アクティブなアラートを一時停止または削除することで、新しいアラートを作成できるようになります。 アラートは、作成時にデフォルトで有効化されます。この設定は変更できません。
自動ポリシー​で保護されている API インスタンスにはアラートを追加できません。
API アラートを追加する手順は、次のとおりです。 1. **\[API Manager\]**​ > ​**\[API Administration (API 管理)\]**​ に移動して、アラートを追加する API インスタンスをクリックします。 2. 左側のナビゲーションペインから、​**\[Alerts (アラート)\]**​ > ​**\[New alert (新規アラート)\]**​ を選択します。 3. 表示されているアラートオプションの値を指定します。 - **Name (名前)**​: アラート名を入力します (例: `trial-alert`​)。不要な場合はアラートをいつでも削除できます。 - **Severity (重要度)**​: アラートの重要度を選択します。 - **Info (情報)** トリガーされた時点で直ちに対応する必要がないアラートに割り当てます。この重要度は、メトリクスを受動的に監視する必要があることを示しています。 - **Warning (警告)** トリガーされた時点で直ちに対応する必要があるアラートに割り当てます。この重要度は、アラートを綿密に監視する必要があることを示しています。 - **Critical (重大)** トリガーされた時点で直ちに対応する必要があるアラートに割り当てます。この重要度は、アラートに直ちに対応する必要があることを示しています。 4. アラート条件を指定します。 - **Metric (メトリクス)** アラートをトリガーする条件。 - **Logic (ロジック)** **\[When number of occurrences are (発生回数)\]**​ 項目と ​**\[For at least \[number of\] minutes (\[ \] 分以上)\]**​ 項目で定義される発生率に基づいた、アラートをトリガーするタイミング。 アラート条件には最大 10 個の応答コードを選択できます。 5. メール通知を設定します。 - **Subject (件名)** アラートがトリガーされたときに送信されるアラートメールの件名。件名には変数を含めることができます。​[変数定義](#alert-variables)​を参照してください。 - **Message (メッセージ)** アラートがトリガーされたときに送信されるメールの本文テキスト。メッセージ本文には変数を含めることができます。​[変数定義](#alert-variables)​を参照してください。 - **Recipients (受信者)** アラートメールの受信者。最大 20 個のプラットフォームユーザー ID を選択し、最大 20 個のメールアドレスを入力できます。 6. **\[Create (作成)\]**​ をクリックします。 アラートの作成中は ​**\[Pending (保留中)\]**​ と表示されます。API がトラフィックを受け取ると、アラートの状態は ​**\[OK\]**​ に変わります。また、値に応じて、アラートは ​**\[OK\]**​ または ​**\[Alerting (アラート)\]**​ に移行します。 ### [](#アラートメールテンプレート)アラートメールテンプレート 基本アラートメールの ​**\[Subject (件名)\]**​ 項目と ​**\[Message (メッセージ)\]**​ 項目で次の変数を使用できます。 各変数の説明については、​[変数定義](#alert-variables)​を参照してください。
Table 1. アラートの変数
アラート 該当する変数

Total Request Count (合計要求数)​

  • ${severity}​

  • ${operator}​

  • ${threshold}​

  • ${period}​

  • ${value}​

  • ${condition}​

  • ${organization}​

  • ${environment}​

  • ${apiLink}​

  • ${dashboardLink}​

  • ${api}​

  • ${policy}​

Average Response Time (平均応答時間)

Response Codes (応答コード)

Policy Violations (ポリシー違反)​
Table 2. 変数定義
変数 定義

${apiLink}

トリガーされた API の URL。

${alertState}

アラートがトリガーされたときのアラートの状態。

使用可能な値は ​OK​ または ​Alerting​ です。

${comparison}

* Above (上回る)、Above or equal (上回るまたは等しい)、Equal (等しい)、Below or equal (下回るまたは等しい)、Below (下回る)

${condition}

アラートがトリガーされるメトリクス。

${environment}

リソースがデプロイされている環境の名前。

${operator}

< > =​ などの演算子。

${organization}

アラートを所有する組織の名前。

${period}

測定する期間。

${severity}

アラートの重要度。

${threshold}

アラートをトリガーする期間での数

${value}

アラートをトリガーするメトリクスの値。
## [](#enabling-alerts)API アラートの一時停止と編集 アラートを一時停止すると、アラートは ​**\[Paused (一時停止)\]**​ に移行します。 既存のアラートは、次の手順で編集できます。 1. API Manager の左側のナビゲーションバーで、​**\[API Administration (API 管理)\]**​ をクリックします。 2. API インスタンス、および編集するバージョンをクリックし、​**\[Alerts (アラート)\]**​ をクリックします。 3. 編集したいアラートの 3 つのドットのアイコン (​![5%](/mulesoft/current/ja-jp/gateway/1.9/_images/three-dots-menu.png)​) をクリックして、​**\[Edit (編集)\]**​ を選択します。 ![アラートの名前、基づいているメトリクス、重大度、状態、アラートが有効化されているかどうかを示すテーブル](/mulesoft/current/ja-jp/gateway/1.9/_images/flex-alerts-edit.png) ## [](#アラートの表示と削除)アラートの表示と削除 アラートを表示および削除する手順は、次のとおりです。 1. API Manager から、​**\[API Administration (API 管理)\] で API インスタンス**​をクリックし、​**\[Alerts (アラート)\]**​ を選択します。 ![「Test fail alert (テスト失敗アラート)」という名前の展開されたアラートが表示されている API サービスコントラクトアラートのテーブル](/mulesoft/current/ja-jp/gateway/1.9/_images/view-add-alert.png) 2. リスト内のアラートを展開します。 アラートのオプションに関する詳細が表示されます。 3. 削除するアラートの 3 つのドットメニュー (​![メニューとして縦に並べられた 3 つのドット](/mulesoft/current/ja-jp/gateway/1.9/_images/three-dots-menu.png)​) から ​**\[Delete (削除)\]**​ をクリックします。アラートの編集中に削除することもできます。 # Flex Gateway API のパブリッシュ API をパブリッシュするには、クライアントサービスを定義し、そのサービスをバックエンドの場所にルーティングします。Flex Gateway を使用すると、API を Anypoint Platform (接続モード) または宣言型設定ファイル (ローカルモード) を介してパブリッシュできます。 接続モードで API をパブリッシュするには、[管理ゲートウェイと接続モード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-publish-apis-conn)を参照してください。 ローカルモードで API をパブリッシュするには、[ローカルモード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-publish-apis-local)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) # Flex Gateway API のパブリッシュ API をパブリッシュするには、クライアントサービスを定義し、そのサービスをバックエンドの場所にルーティングします。Flex Gateway を使用すると、API を Anypoint Platform (接続モード) または宣言型設定ファイル (ローカルモード) を介してパブリッシュできます。 接続モードで API をパブリッシュするには、[接続モードでの Flex Gateway API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-publish-apis-conn)を参照してください。 ローカルモードで API をパブリッシュするには、[ローカルモードでの Flex Gateway API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-publish-apis-local)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway API のパブリッシュ API をパブリッシュするには、クライアントサービスを定義し、そのサービスをバックエンドの場所にルーティングします。Flex Gateway を使用すると、API を Anypoint Platform (接続モード) または宣言型設定ファイル (ローカルモード) を介してパブリッシュできます。 接続モードで API をパブリッシュするには、[管理ゲートウェイと接続モード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-publish-apis-conn)を参照してください。 ローカルモードで API をパブリッシュするには、[ローカルモード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-publish-apis-local)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) # Flex Gateway API の保護と管理 ポリシーは、Flex Gateway が要求を処理するときにルールを適用し、Flex Gateway API を保護および管理できるようにします。 MuleSoft では、Anypoint Platform (接続モード) または宣言型設定ファイル (ローカルモード) を介して API に適用できるポリシーが提供されます。提供されるポリシーには、レート制限、キャッシュ、認証、承認、脅威保護、監視、ログ記録が含まれます。MuleSoft によって提供されるポリシーについての詳細は、[policies-includeed-directory.adoc](#policies-includeed-directory.adoc)を参照してください。 既存の機能を拡張したり、新しい機能を定義したりするには、特定のビジネス要件に基づいてカスタムポリシーを作成し、それらを API に適用します。カスタムポリシーの作成については、[カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-overview)を参照してください。 自動ポリシーでは、同じポリシーのセットが Flex Gateway で実行されるすべての API に適用されるため、API インスタンスを共通のセキュリティ要件とロギング要件に準拠させることができます。詳細は、[自動ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-automated-overview)を参照してください。 接続モードでポリシーを適用するには、[接続モードでの API の保護および制御](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-secure-conn)を参照してください。 ローカルモードでポリシーを適用するには、[ローカルモードでの API の保護および制御](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-secure-local)を参照してください。 ポリシーの並び替えにいついての詳細は、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.8/policies-reorder)を参照してください。 DataWeave サポートについての詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.8/policies-flex-dataweave-support)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway API の重要なメトリクスの表示 API Manager と Anypoint Monitoring は、アクティブな Flex Gateway API インスタンスでメトリクスを収集します。これらのメトリクスに関連したチャートを表示して、データを日付で絞り込むことができます。 API Manager で使用できるメトリクスは​**重要なメトリクス**​とみなされ、ここで説明されています。 **重要なメトリクス**​はすべての Anypoint Platform サブスクリプションで使用できます。​**\[Key Metrics (重要なメトリクス)\]**​ セクションに含まれないその他の Flex Gateway API メトリクスについては、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​ (Anypoint Integration Advanced パッケージまたは Titanium サブスクリプションのみ) を使用してください。Anypoint Monitoring に移動するには、Anypoint Platform から ​**\[Anypoint Monitoring\]**​ をクリックすることができます。

現在、API Manager の ​[Mule API Analytics]​ タブは Flex Gateway API では使用できません。​[Key Metrics (重要なメトリクス)]​ または Anypoint Monitoring でその他のメトリクスを使用してください。
## [](#重要なメトリクス)重要なメトリクス 1. Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のページで、​**\[API Manager\]**​ をクリックします。 **\[API Administration (API 管理)\]**​ ページが表示され、組織で使用できる API のリストが示されます。 3. API インスタンスをクリックします。 **\[API Summary (API の概要)\]**​ ページが表示され、API インスタンスの一般情報と状況が示されます。 Anypoint Monitoring で API インスタンスを表示するには、​**\[Key Metrics (重要なメトリクス)\]**​ セクションから ​**\[View more metrics in Anypoint Monitoring dashboard (Anypoint Monitoring ダッシュボードでその他のメトリクスを表示)\]**​ をクリックするか、Anypoint Monitoring に直接移動します。 **\[Key Metrics (重要なメトリクス)\]**​ セクションには 4 つのチャートがあります。API インスタンスでチャートが表示されない場合は、ブラウザーを更新してください。 ## [](#重要なメトリクスの意味)重要なメトリクスの意味 \[API Summary (API の概要)\] の ​**\[Key Metrics (重要なメトリクス)\]**​ セクションには、以下のチャートがあります。 Total Requests (要求総数) 選択された時間範囲での特定の API に対する要求数の合計。 データは 1 分ごとの増分量となります。 Total Policy Violations (ポリシー違反総数) ポリシー違反を返した要求の合計数。 データは 1 分ごとの増分量となります。 Total Errors (総エラー数) 選択された期間で発生した HTTP 応答コードの合計数。このメトリクスで数えられる応答コードは、400、401、402、403、404、405、408、409、410、411、412、413、415、416、417、420、422、429、500、502、503、504、504、510、511 です。 データは 1 分ごとの増分量となります。チャートでは、HTTP 応答コードは 4xx や 5xx のように省略して表示されます。 Average Response Time (平均応答時間) 選択された期間での特定の API に対する要求への応答時間の平均。 データは 1 分ごとの増分量となります。 ## [](#重要なメトリクスの期間の設定)重要なメトリクスの期間の設定 直前の一定期間 (過去 5 分間や過去 30 分間など) または特定の日時範囲に収集されたデータポイントを表示できます。カレンダーアイコンのドロップダウンを使用して、グラフに表示する期間を選択します。 ## [](#次のステップ)次のステップ - [API Manager のアラート機能](https://docs.mulesoft.com/jp/gateway/1.8/flex-use-api-alerts)​または ​[Anypoint Monitoring の基本アラート機能](https://docs.mulesoft.com/jp/monitoring/basic-alerts)​で、API インスタンスに関連するメトリクスを使用してアラートを作成します。 - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​ の組み込み API ダッシュボードで、追加のメトリクスの表示、日付でのデータの絞り込み、CSV 形式でのデータエクスポートを行います。 (Anypoint Integration Advanced パッケージまたは Titanium サブスクリプション限定) # Flex Gateway MCP および A2A サーバーインスタンスのパブリッシュ API インスタンスと同様に、​**API Manager**​ を使用して接続モードで実行されている管理 Flex Gateway または Flex Gateway の MCP おおよび A2A サーバーインスタンスをパブリッシュします。 詳細は、以下を参照してください。 - [api-manager::create-instance-task-mcp.adoc](#api-manager::create-instance-task-mcp.adoc) - [api-manager::create-instance-task-a2a.adoc](#api-manager::create-instance-task-a2a.adoc) ## [](#関連情報)関連情報 - [管理ゲートウェイと接続モード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-publish-apis-conn) - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) # Flex Gateway MCP および A2A サーバーインスタンスのパブリッシュ API インスタンスと同様に、​**API Manager**​ を使用して接続モードで実行されている管理 Flex Gateway または Flex Gateway の MCP おおよび A2A サーバーインスタンスをパブリッシュします。 詳細は、以下を参照してください。 - [api-manager::create-instance-task-mcp.adoc](#api-manager::create-instance-task-mcp.adoc) - [api-manager::create-instance-task-a2a.adoc](#api-manager::create-instance-task-a2a.adoc) ## [](#関連情報)関連情報 - [管理ゲートウェイと接続モード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-publish-apis-conn) - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) # Flex Gateway エージェントポリシー ポリシーは、Flex Gateway が要求を処理するときにルールを適用し、サーバーインスタンスを保護および管理できるようにします。Flex Gateway には、セキュリティを強化してエージェントインタラクションを制御する A2A および MCP 固有のポリシーが含まれます。 ポリシーを適用するには、[管理 Flex Gateway と接続モードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-secure-conn)を参照してください。 Flex Gateway MCP および A2A サーバーインスタンスでは、レート制限、認証、承認、脅威保護、監視、ログを通じてサーバーインスタンスを保護するために他の Flex Gateway ポリシーもサポートされます。MuleSoft によって提供されるポリシーについての詳細は、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) and [アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-outbound-directory)​を参照してください。 既存の機能を拡張したり、新しい機能を定義したりするには、特定のビジネス要件に基づいてカスタムポリシーを作成します。カスタムポリシーの作成については、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を参照してください。
すべてのエージェントポリシーはインバウンドポリシーであり、自動ポリシーとしてはサポートされません。
## [](#sse-ポリシー)SSE ポリシー A2A と MCP の両方で、サーバー送信イベント (SSE) ストリーミング用に次のポリシーがサポートされます。
ポリシー 概要

SSE ログ

ストリーミング中にすべての SSE イベントを記録します
## [](#a2a-ポリシー)A2A ポリシー
ポリシー 概要

A2A エージェントカード

サーバーインスタンスの公開 URL と一致するようにエージェントカード URL を書き換えます

A2A PII ディテクター

エージェントに送信される要求で個人情報 (PII) を検出します

A2A プロンプトデコレーター

プロンプトをコンテキスト情報でデコレーションします

A2A スキーマ検証

エージェント要求を検証し、A2A 仕様に準拠していることを確認します
## [](#mcp-ポリシー)MCP ポリシー
ポリシー 概要

MCP 属性ベースのアクセス制御

層、IP、ヘッダー、クレームなどのユーザー情報に基づいてツール、リソース、プロンプトへのアクセスを制御します。

MCP スキーマ検証

MCP 要求を検証して MCP 仕様に準拠していることを確認します。

MCP サポート

MCP サポートを Flex Gateway MCP サーバーインスタンスに追加します。MCP サーバーインスタンスを適切に機能させるには、このポリシーが必要です。
## [](#関連情報)関連情報 - [ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.10/policies-reorder) - [Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support) # Flex Gateway エージェントポリシー ポリシーは、Flex Gateway が要求を処理するときにルールを適用し、サーバーインスタンスを保護および管理できるようにします。Flex Gateway には、セキュリティを強化してエージェントインタラクションを制御する A2A および MCP 固有のポリシーが含まれます。 ポリシーを適用するには、[管理 Flex Gateway と接続モードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-secure-conn)を参照してください。 Flex Gateway MCP および A2A サーバーインスタンスでは、レート制限、認証、承認、脅威保護、監視、ログを通じてサーバーインスタンスを保護するために他の Flex Gateway ポリシーもサポートされます。MuleSoft によって提供されるポリシーについての詳細は、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) and [アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-outbound-directory)​を参照してください。 既存の機能を拡張したり、新しい機能を定義したりするには、特定のビジネス要件に基づいてカスタムポリシーを作成します。カスタムポリシーの作成については、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を参照してください。
すべてのエージェントポリシーはインバウンドポリシーであり、自動ポリシーとしてはサポートされません。
## [](#sse-ポリシー)SSE ポリシー A2A と MCP の両方で、サーバー送信イベント (SSE) ストリーミング用に次のポリシーがサポートされます。
ポリシー 概要

SSE ログ

ストリーミング中にすべての SSE イベントを記録します
## [](#a2a-ポリシー)A2A ポリシー
ポリシー 概要

A2A エージェントカード

サーバーインスタンスの公開 URL と一致するようにエージェントカード URL を書き換えます

A2A PII ディテクター

エージェントに送信される要求で個人情報 (PII) を検出します

A2A プロンプトデコレーター

プロンプトをコンテキスト情報でデコレーションします

A2A スキーマ検証

エージェント要求を検証し、A2A 仕様に準拠していることを確認します
## [](#mcp-ポリシー)MCP ポリシー
ポリシー 概要

MCP 属性ベースのアクセス制御

層、IP、ヘッダー、クレームなどのユーザー情報に基づいてツール、リソース、プロンプトへのアクセスを制御します。

MCP スキーマ検証

MCP 要求を検証して MCP 仕様に準拠していることを確認します。

MCP サポート

MCP サポートを Flex Gateway MCP サーバーインスタンスに追加します。MCP サーバーインスタンスを適切に機能させるには、このポリシーが必要です。
## [](#関連情報)関連情報 - [ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.9/policies-reorder) - [Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support) # Flex Gateway カスタムポリシーのパブリッシュ **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 以下の手順は、Anypoint Flex Gateway のカスタムポリシーをパブリッシュするためのワークフローの概要です。 1. ポリシー定義ファイルを作成する。 2. ポリシー定義アセットを Exchange にパブリッシュする。 3. 実装ファイルを作成する。 4. パブリッシュしたポリシー定義にポリシー実装を追加する。 ## [](#始める前に)始める前に Flex Gateway のカスタムポリシーをパブリッシュする前に、Anypoint Platform の管理者権限またはコントリビュータ権限を持っていることを確認してください。 ## [](#create-policy-definition-files)ポリシー定義ファイルの作成 ポリシー実装をアップロードする前に、JSON と YAML ポリシー定義ファイルを作成する必要があります。必要なファイルは JSON と YAML です。 JSON ファイルは、JSON スキーマ言語を使用して、ポリシーのインターフェースを指定します。API Manager は、JSON ファイルを使用して UI を表示します。 YAML ファイルは、ポリシーカテゴリ、インターフェーススコープ、必要な特性、RAML/OAS スニペットなどのポリシーに関連したメタデータを提供します。 カスタムポリシーの定義例をコピーするか、またはローカルシステムでファイルを作成してください。 ### [](#json-スキーマファイルの作成)JSON スキーマファイルの作成 JSON スキーマファイルは、ポリシーの設定で必要なプロパティやサポートされるプロパティを特定することで、ポリシーのインターフェースを指定します。また、このファイルに追加のアノテーションを含めることで、Anypoint Platform で特別な動作を実行できるようにする各プロパティの種別を絞り込みます。たとえば、Dataweave の検証やシークレットの安全な処理などです。 JSON ファイルには次の項目が含まれている必要があります。 - 最上位の @コンテキスト 追加の種別アノテーションで使用するボキャブラリーを参照します。ボキャブラリーの名前空間を指定するための別名は省略可能です。よく使用される名前としては ​`security`​ や ​`config`​ があります。 security 別名と config 別名の値は次のとおりです。 - security: `anypoint://vocabulary/policy.yaml#` - config: `` anypoint://vocabulary/policyConfigurationsForUI.yaml#` `` - 最上位のタイトル - JSON スキーマ仕様へのリンクを指定した $schema (例参照) - `object`​ のルート種別 - 最上位の説明 - 各プロパティには以下を含める必要もあります。 - タイトル タイトルは、API Manager UI が項目名を表示するのに使用します。 - 説明 説明は、API Manager UI が項目を説明するのに使用します。 - 型 プリミティブ型 (例: `integer`​、​`string`​、​`object`​、​`boolean`​、​`array`​) のみがサポートされます。 各プロパティには以下を含めることもできます。 - 形式 オプションは ​`dataweaveExpression`​ と ​`` ipRange` ``​ です。 - デフォルト UI で表示されるデフォルト値を入力することができます。 - @characteristics 配列を使用した @context 追加のアノテーションによる種別を次のオプションでさらに絞り込みます。 - `config:commaSeparatedValues` この項目の値によって配列が生成されます。 - `security:sensitive`​ API Manager UI でプロパティを入力するときにプロパティをマスクするかどうかを決定します。 基本認証 JSON スキーマのコード例を示します。 { "title": "Basic authentication - Simple", "type": "object", "description": "Enforces HTTP Basic authentication according to the details configured in the policy.", "properties": { "username": { "title": "User Name", "type": "string" }, "password": { "title": "User Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "username", "password" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "basic-authentication-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#定義メタデータ-yaml-ファイルの作成)定義メタデータ YAML ファイルの作成 YAML ファイルは、ポリシーとその要件に関する情報を提供します。YAML ファイルは、特定のランタイムやバイナリには関連付けられません。 このファイルでは以下の項目を設定する必要があります。 - ヘッダー ヘッダーは #%Policy Definition 0.1 である必要があります。 - 名前 API Manager の UI でポリシー名を表示するために使用されるわかりやすい名前。文字列値である必要があります。 - 説明 文字列値である必要があります。 - カテゴリ ポリシーが属するカテゴリ。API Manager の UI でポリシーのグループ化や絞り込みを行うために使用されます。任意の文字列値を使用できます。例: `security`​、​`quality of service`​、​`compliance`​、​`troubleshooting`​、​`transformation`​。 - 提供される特性 ポリシーで提供する特性を定義するために使用するリスト。文字列の配列である必要があります。空白のままにするには、​`providedCharacteristics: []`​ を使用します。 基本認証定義 YAML ファイルのコード例を示します。 #%Policy Definition 0.1 name: Basic authentication - Simple description: Enforces HTTP Basic authentication according to the details configured in the policy. category: Security providedCharacteristics: - Requires authentication requiredCharacteristics: \[\] interfaceScope: \["api", "resource"\] interfaceTransformation: \[\] encryptionSupported: true violationCategory: authentication ## [](#exchange-へのポリシー定義アセットのパブリッシュ)Exchange へのポリシー定義アセットのパブリッシュ 必要なポリシー定義ファイル (JSON および YAML) を作成したら、ポリシー定義アセットを Exchange にパブリッシュします。 詳細は、​[「カスタムポリシー定義アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset#create-custom-policy-definition-asset)​を参照してください。 ## [](#create-implementation-files)実装ファイルの作成 ポリシーをランタイムで使用できるようにするのに必要なポリシー実装ファイルは、メタデータファイルとバイナリファイルです。メタデータファイルは、バイナリファイルがどのランタイムバージョンからどのテクノロジーに適用されるかを記述します。メタデータファイルは、YAML ファイルである必要があります。バイナリファイルにはポリシーロジックが含まれ、ランタイムの実行を管理します。このファイルは、Anypoint Flex Gateway の場合は WebAssembly (WASM)、Mule 4 ランタイムの場合は JAR ファイルです。 ### [](#メタデータ-yaml-ファイルの作成)メタデータ YAML ファイルの作成 メタデータ YAML ファイルは、ポリシー定義の特定の実装に関する詳細を提供します。1 つのポリシー定義から複数の実装を派生させることができます。それぞれの実装は Exchange では独立したアセットになるか、または同じ Exchange アセットの異なるバージョンになります。 メタデータ YAML ファイルには次の項目が含まれている必要があります。 - ヘッダー #%Policy Implementation 1.0 - テクノロジー `mule4`​ または ​`flexGateway`​ を入力します。 - 名前 実装の名前。 - minRuntimeVersion 実装バイナリが互換性を持つ最初のランタイムバージョンを表すセマンティックバージョン。たとえば、Mule バイナリは 4.3.0 以降とのみ互換性を持ちます。 YAML ファイルには ​`Release notes`​ を含めることもできます。 実装メタデータ YAML ファイルのコード例を示します。 #%Policy Implementation 1.0 minRuntimeVersion: 4.1.1 maxRuntimeVersion: 4.4.0 technology: mule4 name: Simple Auth Mule Implementation releaseNotes: "" ### [](#実装バイナリファイルの作成)実装バイナリファイルの作成 実装バイナリファイルは、Mule 4 ポリシーの場合は JAR ファイルで、Anypoint Flex Gateway の場合は WebAssembly WASM ファイルです。これらのファイルは、すべての設定項目をサポートし、定義メタデータで記述されているように機能する必要があります。 ## [](#パブリッシュしたポリシー定義へのポリシー実装の追加)パブリッシュしたポリシー定義へのポリシー実装の追加 カスタムポリシー定義アセットを Exchange にパブリッシュしたら、次はパブリッシュしたポリシーにポリシー実装ファイルを追加します。このステップにより、ポリシーがランタイムで使用できるようになります。必要な実装ファイルは、バイナリファイル (Anypoint Flex Gateway の場合は WebAssembly (WASM)、Mule 4 ランタイムの場合は JAR) と YAML メタデータファイルです。 実装ファイルを追加する前に、ポリシーアセットが \[Stable (安定)\] 状態であることを確認してください。 ## [](#anypoint-api-manager-から-api-へのポリシーの適用)Anypoint API Manager から API へのポリシーの適用 実装ファイルをパブリッシュしたら、API Manager でポリシーを API に適用できるようになります。ポリシーの適用については、Anypoint API Manager のドキュメントを参照してください。 # Flex Gateway カスタムポリシーのパブリッシュ **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 以下の手順は、Anypoint Flex Gateway のカスタムポリシーをパブリッシュするためのワークフローの概要です。 1. ポリシー定義ファイルを作成する。 2. ポリシー定義アセットを Exchange にパブリッシュする。 3. 実装ファイルを作成する。 4. パブリッシュしたポリシー定義にポリシー実装を追加する。 ## [](#始める前に)始める前に Flex Gateway のカスタムポリシーをパブリッシュする前に、Anypoint Platform の管理者権限またはコントリビュータ権限を持っていることを確認してください。 ## [](#create-policy-definition-files)ポリシー定義ファイルの作成 ポリシー実装をアップロードする前に、JSON と YAML ポリシー定義ファイルを作成する必要があります。必要なファイルは JSON と YAML です。 JSON ファイルは、JSON スキーマ言語を使用して、ポリシーのインターフェースを指定します。API Manager は、JSON ファイルを使用して UI を表示します。 YAML ファイルは、ポリシーカテゴリ、インターフェーススコープ、必要な特性、RAML/OAS スニペットなどのポリシーに関連したメタデータを提供します。 カスタムポリシーの定義例をコピーするか、またはローカルシステムでファイルを作成してください。 ### [](#json-スキーマファイルの作成)JSON スキーマファイルの作成 JSON スキーマファイルは、ポリシーの設定で必要なプロパティやサポートされるプロパティを特定することで、ポリシーのインターフェースを指定します。また、このファイルに追加のアノテーションを含めることで、Anypoint Platform で特別な動作を実行できるようにする各プロパティの種別を絞り込みます。たとえば、Dataweave の検証やシークレットの安全な処理などです。 JSON ファイルには次の項目が含まれている必要があります。 - 最上位の @コンテキスト 追加の種別アノテーションで使用するボキャブラリーを参照します。ボキャブラリーの名前空間を指定するための別名は省略可能です。よく使用される名前としては ​`security`​ や ​`config`​ があります。 security 別名と config 別名の値は次のとおりです。 - security: `anypoint://vocabulary/policy.yaml#` - config: `` anypoint://vocabulary/policyConfigurationsForUI.yaml#` `` - 最上位のタイトル - JSON スキーマ仕様へのリンクを指定した $schema (例参照) - `object`​ のルート種別 - 最上位の説明 - 各プロパティには以下を含める必要もあります。 - タイトル タイトルは、API Manager UI が項目名を表示するのに使用します。 - 説明 説明は、API Manager UI が項目を説明するのに使用します。 - 型 プリミティブ型 (例: `integer`​、​`string`​、​`object`​、​`boolean`​、​`array`​) のみがサポートされます。 各プロパティには以下を含めることもできます。 - 形式 オプションは ​`dataweaveExpression`​ と ​`` ipRange` ``​ です。 - デフォルト UI で表示されるデフォルト値を入力することができます。 - @characteristics 配列を使用した @context 追加のアノテーションによる種別を次のオプションでさらに絞り込みます。 - `config:commaSeparatedValues` この項目の値によって配列が生成されます。 - `security:sensitive`​ API Manager UI でプロパティを入力するときにプロパティをマスクするかどうかを決定します。 基本認証 JSON スキーマのコード例を示します。 { "title": "Basic authentication - Simple", "type": "object", "description": "Enforces HTTP Basic authentication according to the details configured in the policy.", "properties": { "username": { "title": "User Name", "type": "string" }, "password": { "title": "User Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "username", "password" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "basic-authentication-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#定義メタデータ-yaml-ファイルの作成)定義メタデータ YAML ファイルの作成 YAML ファイルは、ポリシーとその要件に関する情報を提供します。YAML ファイルは、特定のランタイムやバイナリには関連付けられません。 このファイルでは以下の項目を設定する必要があります。 - ヘッダー ヘッダーは #%Policy Definition 0.1 である必要があります。 - 名前 API Manager の UI でポリシー名を表示するために使用されるわかりやすい名前。文字列値である必要があります。 - 説明 文字列値である必要があります。 - カテゴリ ポリシーが属するカテゴリ。API Manager の UI でポリシーのグループ化や絞り込みを行うために使用されます。任意の文字列値を使用できます。例: `security`​、​`quality of service`​、​`compliance`​、​`troubleshooting`​、​`transformation`​。 - 提供される特性 ポリシーで提供する特性を定義するために使用するリスト。文字列の配列である必要があります。空白のままにするには、​`providedCharacteristics: []`​ を使用します。 基本認証定義 YAML ファイルのコード例を示します。 #%Policy Definition 0.1 name: Basic authentication - Simple description: Enforces HTTP Basic authentication according to the details configured in the policy. category: Security providedCharacteristics: - Requires authentication requiredCharacteristics: \[\] interfaceScope: \["api", "resource"\] interfaceTransformation: \[\] encryptionSupported: true violationCategory: authentication ## [](#exchange-へのポリシー定義アセットのパブリッシュ)Exchange へのポリシー定義アセットのパブリッシュ 必要なポリシー定義ファイル (JSON および YAML) を作成したら、ポリシー定義アセットを Exchange にパブリッシュします。 詳細は、​[「カスタムポリシー定義アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset#create-custom-policy-definition-asset)​を参照してください。 ## [](#create-implementation-files)実装ファイルの作成 ポリシーをランタイムで使用できるようにするのに必要なポリシー実装ファイルは、メタデータファイルとバイナリファイルです。メタデータファイルは、バイナリファイルがどのランタイムバージョンからどのテクノロジーに適用されるかを記述します。メタデータファイルは、YAML ファイルである必要があります。バイナリファイルにはポリシーロジックが含まれ、ランタイムの実行を管理します。このファイルは、Anypoint Flex Gateway の場合は WebAssembly (WASM)、Mule 4 ランタイムの場合は JAR ファイルです。 ### [](#メタデータ-yaml-ファイルの作成)メタデータ YAML ファイルの作成 メタデータ YAML ファイルは、ポリシー定義の特定の実装に関する詳細を提供します。1 つのポリシー定義から複数の実装を派生させることができます。それぞれの実装は Exchange では独立したアセットになるか、または同じ Exchange アセットの異なるバージョンになります。 メタデータ YAML ファイルには次の項目が含まれている必要があります。 - ヘッダー #%Policy Implementation 1.0 - テクノロジー `mule4`​ または ​`flexGateway`​ を入力します。 - 名前 実装の名前。 - minRuntimeVersion 実装バイナリが互換性を持つ最初のランタイムバージョンを表すセマンティックバージョン。たとえば、Mule バイナリは 4.3.0 以降とのみ互換性を持ちます。 YAML ファイルには ​`Release notes`​ を含めることもできます。 実装メタデータ YAML ファイルのコード例を示します。 #%Policy Implementation 1.0 minRuntimeVersion: 4.1.1 maxRuntimeVersion: 4.4.0 technology: mule4 name: Simple Auth Mule Implementation releaseNotes: "" ### [](#実装バイナリファイルの作成)実装バイナリファイルの作成 実装バイナリファイルは、Mule 4 ポリシーの場合は JAR ファイルで、Anypoint Flex Gateway の場合は WebAssembly WASM ファイルです。これらのファイルは、すべての設定項目をサポートし、定義メタデータで記述されているように機能する必要があります。 ## [](#パブリッシュしたポリシー定義へのポリシー実装の追加)パブリッシュしたポリシー定義へのポリシー実装の追加 カスタムポリシー定義アセットを Exchange にパブリッシュしたら、次はパブリッシュしたポリシーにポリシー実装ファイルを追加します。このステップにより、ポリシーがランタイムで使用できるようになります。必要な実装ファイルは、バイナリファイル (Anypoint Flex Gateway の場合は WebAssembly (WASM)、Mule 4 ランタイムの場合は JAR) と YAML メタデータファイルです。 実装ファイルを追加する前に、ポリシーアセットが \[Stable (安定)\] 状態であることを確認してください。 ## [](#anypoint-api-manager-から-api-へのポリシーの適用)Anypoint API Manager から API へのポリシーの適用 実装ファイルをパブリッシュしたら、API Manager でポリシーを API に適用できるようになります。ポリシーの適用については、Anypoint API Manager のドキュメントを参照してください。 # Flex Gateway カスタムポリシーのパブリッシュ **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 以下の手順は、Anypoint Flex Gateway のカスタムポリシーをパブリッシュするためのワークフローの概要です。 1. ポリシー定義ファイルを作成する。 2. ポリシー定義アセットを Exchange にパブリッシュする。 3. 実装ファイルを作成する。 4. パブリッシュしたポリシー定義にポリシー実装を追加する。 ## [](#始める前に)始める前に Flex Gateway のカスタムポリシーをパブリッシュする前に、Anypoint Platform の管理者権限またはコントリビュータ権限を持っていることを確認してください。 ## [](#create-policy-definition-files)ポリシー定義ファイルの作成 ポリシー実装をアップロードする前に、JSON と YAML ポリシー定義ファイルを作成する必要があります。必要なファイルは JSON と YAML です。 JSON ファイルは、JSON スキーマ言語を使用して、ポリシーのインターフェースを指定します。API Manager は、JSON ファイルを使用して UI を表示します。 YAML ファイルは、ポリシーカテゴリ、インターフェーススコープ、必要な特性、RAML/OAS スニペットなどのポリシーに関連したメタデータを提供します。 カスタムポリシーの定義例をコピーするか、またはローカルシステムでファイルを作成してください。 ### [](#json-スキーマファイルの作成)JSON スキーマファイルの作成 JSON スキーマファイルは、ポリシーの設定で必要なプロパティやサポートされるプロパティを特定することで、ポリシーのインターフェースを指定します。また、このファイルに追加のアノテーションを含めることで、Anypoint Platform で特別な動作を実行できるようにする各プロパティの種別を絞り込みます。たとえば、Dataweave の検証やシークレットの安全な処理などです。 JSON ファイルには次の項目が含まれている必要があります。 - 最上位の @コンテキスト 追加の種別アノテーションで使用するボキャブラリーを参照します。ボキャブラリーの名前空間を指定するための別名は省略可能です。よく使用される名前としては ​`security`​ や ​`config`​ があります。 security 別名と config 別名の値は次のとおりです。 - security: `anypoint://vocabulary/policy.yaml#` - config: `` anypoint://vocabulary/policyConfigurationsForUI.yaml#` `` - 最上位のタイトル - JSON スキーマ仕様へのリンクを指定した $schema (例参照) - `object`​ のルート種別 - 最上位の説明 - 各プロパティには以下を含める必要もあります。 - タイトル タイトルは、API Manager UI が項目名を表示するのに使用します。 - 説明 説明は、API Manager UI が項目を説明するのに使用します。 - 型 プリミティブ型 (例: `integer`​、​`string`​、​`object`​、​`boolean`​、​`array`​) のみがサポートされます。 各プロパティには以下を含めることもできます。 - 形式 オプションは ​`dataweaveExpression`​ と ​`` ipRange` ``​ です。 - デフォルト UI で表示されるデフォルト値を入力することができます。 - @characteristics 配列を使用した @context 追加のアノテーションによる種別を次のオプションでさらに絞り込みます。 - `config:commaSeparatedValues` この項目の値によって配列が生成されます。 - `security:sensitive`​ API Manager UI でプロパティを入力するときにプロパティをマスクするかどうかを決定します。 基本認証 JSON スキーマのコード例を示します。 { "title": "Basic authentication - Simple", "type": "object", "description": "Enforces HTTP Basic authentication according to the details configured in the policy.", "properties": { "username": { "title": "User Name", "type": "string" }, "password": { "title": "User Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "username", "password" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "basic-authentication-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#定義メタデータ-yaml-ファイルの作成)定義メタデータ YAML ファイルの作成 YAML ファイルは、ポリシーとその要件に関する情報を提供します。YAML ファイルは、特定のランタイムやバイナリには関連付けられません。 このファイルでは以下の項目を設定する必要があります。 - ヘッダー ヘッダーは #%Policy Definition 0.1 である必要があります。 - 名前 API Manager の UI でポリシー名を表示するために使用されるわかりやすい名前。文字列値である必要があります。 - 説明 文字列値である必要があります。 - カテゴリ ポリシーが属するカテゴリ。API Manager の UI でポリシーのグループ化や絞り込みを行うために使用されます。任意の文字列値を使用できます。例: `security`​、​`quality of service`​、​`compliance`​、​`troubleshooting`​、​`transformation`​。 - 提供される特性 ポリシーで提供する特性を定義するために使用するリスト。文字列の配列である必要があります。空白のままにするには、​`providedCharacteristics: []`​ を使用します。 基本認証定義 YAML ファイルのコード例を示します。 #%Policy Definition 0.1 name: Basic authentication - Simple description: Enforces HTTP Basic authentication according to the details configured in the policy. category: Security providedCharacteristics: - Requires authentication requiredCharacteristics: \[\] interfaceScope: \["api", "resource"\] interfaceTransformation: \[\] encryptionSupported: true violationCategory: authentication ## [](#exchange-へのポリシー定義アセットのパブリッシュ)Exchange へのポリシー定義アセットのパブリッシュ 必要なポリシー定義ファイル (JSON および YAML) を作成したら、ポリシー定義アセットを Exchange にパブリッシュします。 詳細は、​[「カスタムポリシー定義アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset#create-custom-policy-definition-asset)​を参照してください。 ## [](#create-implementation-files)実装ファイルの作成 ポリシーをランタイムで使用できるようにするのに必要なポリシー実装ファイルは、メタデータファイルとバイナリファイルです。メタデータファイルは、バイナリファイルがどのランタイムバージョンからどのテクノロジーに適用されるかを記述します。メタデータファイルは、YAML ファイルである必要があります。バイナリファイルにはポリシーロジックが含まれ、ランタイムの実行を管理します。このファイルは、Anypoint Flex Gateway の場合は WebAssembly (WASM)、Mule 4 ランタイムの場合は JAR ファイルです。 ### [](#メタデータ-yaml-ファイルの作成)メタデータ YAML ファイルの作成 メタデータ YAML ファイルは、ポリシー定義の特定の実装に関する詳細を提供します。1 つのポリシー定義から複数の実装を派生させることができます。それぞれの実装は Exchange では独立したアセットになるか、または同じ Exchange アセットの異なるバージョンになります。 メタデータ YAML ファイルには次の項目が含まれている必要があります。 - ヘッダー #%Policy Implementation 1.0 - テクノロジー `mule4`​ または ​`flexGateway`​ を入力します。 - 名前 実装の名前。 - minRuntimeVersion 実装バイナリが互換性を持つ最初のランタイムバージョンを表すセマンティックバージョン。たとえば、Mule バイナリは 4.3.0 以降とのみ互換性を持ちます。 YAML ファイルには ​`Release notes`​ を含めることもできます。 実装メタデータ YAML ファイルのコード例を示します。 #%Policy Implementation 1.0 minRuntimeVersion: 4.1.1 maxRuntimeVersion: 4.4.0 technology: mule4 name: Simple Auth Mule Implementation releaseNotes: "" ### [](#実装バイナリファイルの作成)実装バイナリファイルの作成 実装バイナリファイルは、Mule 4 ポリシーの場合は JAR ファイルで、Anypoint Flex Gateway の場合は WebAssembly WASM ファイルです。これらのファイルは、すべての設定項目をサポートし、定義メタデータで記述されているように機能する必要があります。 ## [](#パブリッシュしたポリシー定義へのポリシー実装の追加)パブリッシュしたポリシー定義へのポリシー実装の追加 カスタムポリシー定義アセットを Exchange にパブリッシュしたら、次はパブリッシュしたポリシーにポリシー実装ファイルを追加します。このステップにより、ポリシーがランタイムで使用できるようになります。必要な実装ファイルは、バイナリファイル (Anypoint Flex Gateway の場合は WebAssembly (WASM)、Mule 4 ランタイムの場合は JAR) と YAML メタデータファイルです。 実装ファイルを追加する前に、ポリシーアセットが \[Stable (安定)\] 状態であることを確認してください。 ## [](#anypoint-api-manager-から-api-へのポリシーの適用)Anypoint API Manager から API へのポリシーの適用 実装ファイルをパブリッシュしたら、API Manager でポリシーを API に適用できるようになります。ポリシーの適用については、Anypoint API Manager のドキュメントを参照してください。 # Flex Gateway デプロイメントモデル Flex Gateway では、接続モードとローカルモードの両方に適用される複数のデプロイメントモデルがサポートされています。 - [スタンドアロンデプロイメント](#standalone-deployment) - [イングレスデプロイメント](#ingress-deployment) - [エグレスデプロイメント](#egress-deployment) - [サイドカーデプロイメント](#sidecar-deployment) この概要のデプロイメントモデルは、適切なネットワーク制御が適用されたすべての技術スタックに拡張できます。ルーティング設定モードについての詳細は、​[\[routing-configuration-methods\]](#routing-configuration-methods)​を参照してください。 以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。 ## [](#スタンドアロンデプロイメント)スタンドアロンデプロイメント スタンドアロンデプロイメントでは、Flex Gateway が内部トラフィックを管理して 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。 次の図で示しているように、すべてのトラフィックは組織が所有しているネットワーク内にあります。トラフィックは、コンシューマー API に到達する前に Flex Gateway を通過します。 ![スタンドアロンデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが同じネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-standalone-deployment.png) ## [](#イングレスデプロイメント)イングレスデプロイメント スタンドアロンデプロイメントと同様、イングレスデプロイメントでは、Flex Gateway が 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。ただし、イングレスデプロイメントでは、Flex Gateway が内部ネットワークに入ってくる外部トラフィックを管理します。イングレスデプロイメントは最も一般的なデプロイメントモデルです。 Flex Gateway は、イングレスゲートウェイとエグレスゲートウェイのどちらの機能も果たすことができます。 次の図で示されているように、すべての外部トラフィックは、コンシューマー API に到達する前に Flex Gateway を通過します。Flex Gateway は通常ロードバランサーの背後にデプロイされ、コンシューマーアプリケーションは Flex Gateway または API と同じネットワークには属していません。 ![イングレスデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが異なるネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-ingress-deployment.png)
イングレスデプロイメントは Kubernetes Ingress コントローラーや Ingress ​Resource​ とは異なります。ルーティング設定についての詳細は、​[routing-configuration-methods]​を参照してください。
## [](#エグレスデプロイメント)エグレスデプロイメント エグレスデプロイメントは、イングレスデプロイメントの逆のデプロイメントモデルです。Flex Gateway はやはり 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。ただし、エグレスデプロイメントでは、Flex Gateway が内部ネットワークから出る内部トラフィック (たとえば、組織が所有していない API への API 要求) を管理します。 Flex Gateway は、イングレスゲートウェイとエグレスゲートウェイのどちらの機能も果たすことができます。 次の図で示されているように、コンシューマーアプリケーションからのすべての内部トラフィックは、外部 API に到達する前に Flex Gateway を通過します。 ![プラットフォーム、Flex Gateway、API、ユーザー間のデータの流れを示す Anypoint Platform の図](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-egress-deployment.png) ## [](#サイドカーデプロイメント)サイドカーデプロイメント サイドカーデプロイメントでは、各 Flex Gateway デプロイメントはその保護対象サービスによって公開される API のみを保護します。新しい保護対象サービスごとに新しい Flex Gateway レプリカが追加されます。 次の図で示されているように、サイドカーデプロイメントのトラフィックは、Flex Gateway を通過してそれぞれのコンシューマー API に到達します。コンシューマーアプリケーションは、Flex Gateway と同じネットワークまたは外部ネットワークに属することができます。 ![サイドカーデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが同じ Kubernetes ポッドにあります。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-sidecar-deployment.png) ## [](#ルーティング設定方法)ルーティング設定方法 Flex Gateway が実行されているモードや Flex Gateway がデプロイされている技術スタックに応じて、さまざまなルーティング設定方法があります。 Flex Gateway とサービス間の接続の設定方法はデプロイメントモデルに関係ありません。 ### [](#コントロールプレーン)コントロールプレーン コントロールプレーンルーティング設定では、Flex Gateway とサービスの接続がリモートコントロールプレーンで設定されます。Flex Gateway の場合、コントロールプレーンは Anypoint Platfrom です。コントロールプレーン設定は Flex Gateway 接続モードでのみ使用できます。 ### [](#カスタムリソース定義-crd)カスタムリソース定義 (CRD) カスタムリソース定義 (CRD) ルーティング設定では、Flex Gateway とサービスの接続がカスタムリソース yaml ファイルで設定されます。 Flex Gateway の場合、CRD は ​`APIinstance`​、​`Service`​、​`PolicyBinding`​、​`Configuration`​ であり、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)で定義されています。 Flex Gateway では CRD によって接続がローカルモードで定義されますが、接続モードの一部の接続にも必要となります。 ### [](#kubernetes-ingress-リソース)Kubernetes Ingress リソース ローカルモードで実行されていて Kubernetes でデプロイされている Flex Gateway は、Kubernetes ​`Ingress`​ リソースを使用して接続ルーティングを定義できます。ルーティングが ​`Ingress`​ リソースを使用して定義されている場合、Flex Gateway はイングレスコントローラーとして機能します。 `Ingress`​ リソースは Kubernetes ローカルモードでのみ使用できます。 `Ingress`​ リソースと CRD は同時に使用できます。 イングレスコントローラーとしての Flex Gateway の設定方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ## [](#関連情報)関連情報 - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc-overview) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-shared-storage) # Flex Gateway デプロイメントモデル Flex Gateway では、接続モードとローカルモードの両方に適用される複数のデプロイメントモデルがサポートされています。 - [スタンドアロンデプロイメント](#standalone-deployment) - [イングレスデプロイメント](#ingress-deployment) - [エグレスデプロイメント](#egress-deployment) - [サイドカーデプロイメント](#sidecar-deployment) この概要のデプロイメントモデルは、適切なネットワーク制御が適用されたすべての技術スタックに拡張できます。ルーティング設定モードについての詳細は、​[\[routing-configuration-methods\]](#routing-configuration-methods)​を参照してください。 以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。 ## [](#スタンドアロンデプロイメント)スタンドアロンデプロイメント スタンドアロンデプロイメントでは、Flex Gateway が内部トラフィックを管理して 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。 次の図で示しているように、すべてのトラフィックは組織が所有しているネットワーク内にあります。トラフィックは、コンシューマー API に到達する前に Flex Gateway を通過します。 ![スタンドアロンデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが同じネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-standalone-deployment.png) ## [](#イングレスデプロイメント)イングレスデプロイメント スタンドアロンデプロイメントと同様、イングレスデプロイメントでは、Flex Gateway が 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。ただし、イングレスデプロイメントでは、Flex Gateway が内部ネットワークに入ってくる外部トラフィックを管理します。イングレスデプロイメントは最も一般的なデプロイメントモデルです。 Flex Gateway は、イングレスゲートウェイとエグレスゲートウェイのどちらの機能も果たすことができます。 次の図で示されているように、すべての外部トラフィックは、コンシューマー API に到達する前に Flex Gateway を通過します。Flex Gateway は通常ロードバランサーの背後にデプロイされ、コンシューマーアプリケーションは Flex Gateway または API と同じネットワークには属していません。 ![イングレスデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが異なるネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-ingress-deployment.png)
イングレスデプロイメントは Kubernetes Ingress コントローラーや Ingress ​Resource​ とは異なります。ルーティング設定についての詳細は、​[routing-configuration-methods]​を参照してください。
## [](#エグレスデプロイメント)エグレスデプロイメント エグレスデプロイメントは、イングレスデプロイメントの逆のデプロイメントモデルです。Flex Gateway はやはり 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。ただし、エグレスデプロイメントでは、Flex Gateway が内部ネットワークから出る内部トラフィック (たとえば、組織が所有していない API への API 要求) を管理します。 Flex Gateway は、イングレスゲートウェイとエグレスゲートウェイのどちらの機能も果たすことができます。 次の図で示されているように、コンシューマーアプリケーションからのすべての内部トラフィックは、外部 API に到達する前に Flex Gateway を通過します。 ![ad egress deployment](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-egress-deployment.png) ## [](#サイドカーデプロイメント)サイドカーデプロイメント サイドカーデプロイメントでは、各 Flex Gateway デプロイメントはその保護対象サービスによって公開される API のみを保護します。新しい保護対象サービスごとに新しい Flex Gateway レプリカが追加されます。 次の図で示されているように、サイドカーデプロイメントのトラフィックは、Flex Gateway を通過してそれぞれのコンシューマー API に到達します。コンシューマーアプリケーションは、Flex Gateway と同じネットワークまたは外部ネットワークに属することができます。 ![サイドカーデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが同じ Kubernetes ポッドにあります。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-sidecar-deployment.png) ## [](#ルーティング設定方法)ルーティング設定方法 Flex Gateway が実行されているモードや Flex Gateway がデプロイされている技術スタックに応じて、さまざまなルーティング設定方法があります。 Flex Gateway とサービス間の接続の設定方法はデプロイメントモデルに関係ありません。 ### [](#コントロールプレーン)コントロールプレーン コントロールプレーンルーティング設定では、Flex Gateway とサービスの接続がリモートコントロールプレーンで設定されます。Flex Gateway の場合、コントロールプレーンは Anypoint Platfrom です。コントロールプレーン設定は Flex Gateway 接続モードでのみ使用できます。 ### [](#カスタムリソース定義-crd)カスタムリソース定義 (CRD) カスタムリソース定義 (CRD) ルーティング設定では、Flex Gateway とサービスの接続がカスタムリソース yaml ファイルで設定されます。 Flex Gateway の場合、CRD は ​`APIinstance`​、​`Service`​、​`PolicyBinding`​、​`Configuration`​ であり、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)で定義されています。 Flex Gateway では CRD によって接続がローカルモードで定義されますが、接続モードの一部の接続にも必要となります。 ### [](#kubernetes-ingress-リソース)Kubernetes Ingress リソース ローカルモードで実行されていて Kubernetes でデプロイされている Flex Gateway は、Kubernetes ​`Ingress`​ リソースを使用して接続ルーティングを定義できます。ルーティングが ​`Ingress`​ リソースを使用して定義されている場合、Flex Gateway はイングレスコントローラーとして機能します。 `Ingress`​ リソースは Kubernetes ローカルモードでのみ使用できます。 `Ingress`​ リソースと CRD は同時に使用できます。 イングレスコントローラーとしての Flex Gateway の設定方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ## [](#関連情報)関連情報 - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc-overview) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-shared-storage) # Flex Gateway デプロイメントモデル Flex Gateway では、接続モードとローカルモードの両方に適用される複数のデプロイメントモデルがサポートされています。 - [スタンドアロンデプロイメント](#standalone-deployment) - [イングレスデプロイメント](#ingress-deployment) - [エグレスデプロイメント](#egress-deployment) - [サイドカーデプロイメント](#sidecar-deployment) この概要のデプロイメントモデルは、適切なネットワーク制御が適用されたすべての技術スタックに拡張できます。ルーティング設定モードについての詳細は、​[\[routing-configuration-methods\]](#routing-configuration-methods)​を参照してください。 以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。 ## [](#スタンドアロンデプロイメント)スタンドアロンデプロイメント スタンドアロンデプロイメントでは、Flex Gateway が内部トラフィックを管理して 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。 次の図で示しているように、すべてのトラフィックは組織が所有しているネットワーク内にあります。トラフィックは、コンシューマー API に到達する前に Flex Gateway を通過します。 ![スタンドアロンデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが同じネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-standalone-deployment.png) ## [](#イングレスデプロイメント)イングレスデプロイメント スタンドアロンデプロイメントと同様、イングレスデプロイメントでは、Flex Gateway が 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。ただし、イングレスデプロイメントでは、Flex Gateway が内部ネットワークに入ってくる外部トラフィックを管理します。イングレスデプロイメントは最も一般的なデプロイメントモデルです。 Flex Gateway は、イングレスゲートウェイとエグレスゲートウェイのどちらの機能も果たすことができます。 次の図で示されているように、すべての外部トラフィックは、コンシューマー API に到達する前に Flex Gateway を通過します。Flex Gateway は通常ロードバランサーの背後にデプロイされ、コンシューマーアプリケーションは Flex Gateway または API と同じネットワークには属していません。 ![イングレスデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが異なるネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-ingress-deployment.png)
イングレスデプロイメントは Kubernetes Ingress コントローラーや Ingress ​Resource​ とは異なります。ルーティング設定についての詳細は、​[routing-configuration-methods]​を参照してください。
## [](#エグレスデプロイメント)エグレスデプロイメント エグレスデプロイメントは、イングレスデプロイメントの逆のデプロイメントモデルです。Flex Gateway はやはり 1 つ以上のインテグレーション API フローを保護するスタンドアロンサービスとして機能します。ただし、エグレスデプロイメントでは、Flex Gateway が内部ネットワークから出る内部トラフィック (たとえば、組織が所有していない API への API 要求) を管理します。 Flex Gateway は、イングレスゲートウェイとエグレスゲートウェイのどちらの機能も果たすことができます。 次の図で示されているように、コンシューマーアプリケーションからのすべての内部トラフィックは、外部 API に到達する前に Flex Gateway を通過します。 ![プラットフォーム、Flex Gateway、API、ユーザー間のデータの流れを示す Anypoint Platform の図](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-egress-deployment.png) ## [](#サイドカーデプロイメント)サイドカーデプロイメント サイドカーデプロイメントでは、各 Flex Gateway デプロイメントはその保護対象サービスによって公開される API のみを保護します。新しい保護対象サービスごとに新しい Flex Gateway レプリカが追加されます。 次の図で示されているように、サイドカーデプロイメントのトラフィックは、Flex Gateway を通過してそれぞれのコンシューマー API に到達します。コンシューマーアプリケーションは、Flex Gateway と同じネットワークまたは外部ネットワークに属することができます。 ![サイドカーデプロイメントでは、Flex Gateway とコンシューマーアプリケーションが同じ Kubernetes ポッドにあります。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-sidecar-deployment.png) ## [](#ルーティング設定方法)ルーティング設定方法 Flex Gateway が実行されているモードや Flex Gateway がデプロイされている技術スタックに応じて、さまざまなルーティング設定方法があります。 Flex Gateway とサービス間の接続の設定方法はデプロイメントモデルに関係ありません。 ### [](#コントロールプレーン)コントロールプレーン コントロールプレーンルーティング設定では、Flex Gateway とサービスの接続がリモートコントロールプレーンで設定されます。Flex Gateway の場合、コントロールプレーンは Anypoint Platfrom です。コントロールプレーン設定は Flex Gateway 接続モードでのみ使用できます。 ### [](#カスタムリソース定義-crd)カスタムリソース定義 (CRD) カスタムリソース定義 (CRD) ルーティング設定では、Flex Gateway とサービスの接続がカスタムリソース yaml ファイルで設定されます。 Flex Gateway の場合、CRD は ​`APIinstance`​、​`Service`​、​`PolicyBinding`​、​`Configuration`​ であり、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)で定義されています。 Flex Gateway では CRD によって接続がローカルモードで定義されますが、接続モードの一部の接続にも必要となります。 ### [](#kubernetes-ingress-リソース)Kubernetes Ingress リソース ローカルモードで実行されていて Kubernetes でデプロイされている Flex Gateway は、Kubernetes ​`Ingress`​ リソースを使用して接続ルーティングを定義できます。ルーティングが ​`Ingress`​ リソースを使用して定義されている場合、Flex Gateway はイングレスコントローラーとして機能します。 `Ingress`​ リソースは Kubernetes ローカルモードでのみ使用できます。 `Ingress`​ リソースと CRD は同時に使用できます。 イングレスコントローラーとしての Flex Gateway の設定方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ## [](#関連情報)関連情報 - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc-overview) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-shared-storage) # Flex Gateway と Istio サービスメッシュの統合 Anypoint Platform コントロールプレーンから Flex Gateway のポリシー、ログ、メトリクスを活用するには、Flex Gateway を Istio サービスメッシュに統合します。Flex Gateway をイングレスゲートウェイとしてデプロイし、イングレス north-south クラスタートラフィックとクラスター内の内部 east-west トラフィックを管理します。 Flex Gateway を統合するには、次のアーキテクチャ図とチュートリアルを使用します。Flex Gateway は、 [Istio Bookinfo サンプルアプリケーション](https://istio.io/latest/docs/examples/bookinfo/)​の変更バージョンを使用して統合されます。Flex Gateway インテグレーションでは、次のようになります。 - Istio 仮想サービスがすべてのイングレス north-south トラフィックを Flex Gateway に転送します。 - `bookinfo`​ 名前空間への直接アクセスは制限されます。​`bookinfo`​ 名前空間へのすべての外部トラフィックは、​`flex`​ 名前空間から送信されている必要があります。Istio は ​`bookinfo`​ と ​`flex`​ 間の mTLS 設定を自動的に定義します。 - Flex Gateway は、API インスタンスを使用して、公開された商品ページサービスをイングレストラフィックから保護し、監視します。 - Istio サイドカーが商品ページサービスとレビューサービス間の east-west トラフィックを捕捉します。Flex Gateway は、レビューサービスへの受信トラフィックを管理するイングレスゲートウェイとして機能します。 ![Flex Gateway を Istio と統合するためのアーキテクチャを示している図](/mulesoft/current/ja-jp/gateway/1.10/_images/flex-istio-deployment.png)
この図では、Flex Gateway は接続モードで実行されています。Flex Gateway がローカルモードで実行されている場合、Anypoint Platform コントロールプレーンはありません。
このアーキテクチャを設定する手順は、次のとおりです。 1. [「始める前に」を完了します](#before-you-begin)​。 2. [環境をセットアップします](#setup-environment)​。 3. [イングレス north-south トラフィックを捕捉します](#forward-ingress-traffic)​。 4. [サービス間の east-west トラフィックを捕捉します](#create-a-service)​。 ## [](#before-you-begin)始める前に 始める前に、次の前提条件をインストールします。 - [Docker](https://docs.docker.com/get-docker/) - [Kubernetes クラスターで使用する Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install#kubernetes) - Docker の内部に Kubernetes クラスターを作成するための [K3d](https://k3d.io/v5.0.0/#installation) - Kubernetes クラスターを制御するための [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) - Flex Gateway と Istio をインストールするための [Helm](https://helm.sh/docs/intro/install/) ## [](#setup-environment)環境のセットアップ 1. このデモ用の Kubernetes クラスターを作成するか、使用するクラスターがすでにある場合はこのステップをスキップします。 ```ssh k3d cluster create demo-istio --k3s-arg "--disable=traefik@server:0" --port '80:80@server:0' --port '443:443@server:0' ``` 2. Flex Gateway と Istio の Helm リポジトリを追加します。 ```ssh helm repo add istio https://istio-release.storage.googleapis.com/charts \ && helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm \ && helm repo up ``` 3. Istio をインストールします。 1. Istio コントロールプレーンをデプロイする前にインストールする必要があるクラスター全体のカスタムリソース定義 (CRD) が含まれている Istio ベースチャートをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istio-base istio/base --version 1.21.2 --set defaultRevision=default ``` 2. `istiod`​ サービスをデプロイする Istio 検出チャートをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istiod istio/istiod --version 1.21.2 ``` 3. Istio イングレスゲートウェイをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istio-ingress istio/gateway --version 1.21.2 ``` 4. Flex Gateway をインストールします。 1. 名前空間を作成し、表示ラベルをセットアップして、サイドカーの挿入を有効にします。 ```ssh kubectl create ns flex && kubectl label ns flex istio-injection=enabled --overwrite ``` 2. Flex Gateway をインストールします。 ```ssh helm upgrade -i --wait -n flex --version 1.7.0 flex flex-gateway/flex-gateway \ --set gateway.scope=Namespace \ --set gateway.mode=connected \ --set service.type=ClusterIP \ --set service.http.port=8081 \ --set service.https.enabled=false \ --set-file registration.content=registration.yaml ``` 3. 以前に作成したすべてのサービスと API インスタンスをリストします。 ```ssh kubectl -n flex get svc ``` 5. `bookinfo`​ アプリケーションをインストールします。 1. デフォルトの名前空間で Istio 表示ラベルの挿入を有効にして、​`bookinfo`​ アプリケーションをインストールします。 ```ssh kubectl create ns bookinfo \ && kubectl label ns bookinfo istio-injection=enabled --overwrite \ && kubectl -n bookinfo apply -l version!=v2,version!=v3 -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml ``` 2. ポッドの状況を確認します。 ```ssh kubectl -n bookinfo get pods ``` 6. トラフィックをテストする ​`sleep`​ アプリケーションをインストールします。 1. `test`​ 名前空間を作成し、​`sleep`​ アプリケーションをインストールします。 ```ssh kubectl create ns test \ && kubectl label ns test istio-injection=enabled --overwrite \ && kubectl -n test apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/sleep/sleep.yaml ``` 2. ポッドの状況を確認します。 ```ssh kubectl -n test get pods ``` ## [](#forward-ingress-traffic)イングレス North-South トラフィックを捕捉します イングレス north-south トラフィックを捕捉して、サービスを外部トラフィックから保護します。 イングレス north-south トラフィックを捕捉する手順は、次のとおりです。 1. `bookinfo`​ 名前空間のすべてのイングレス north-south トラフィックを ​`productpage`​ サービスに転送する Flex Gateway イングレス API インスタンスを作成します。 - ローカルモード: ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true order: 0 EOF ``` ## [](#create-a-service)サービス間の East-West トラフィックの捕捉 Flex Gateway を使用して、サービス間の east-west トラフィックを捕捉し、ポリシーを使用してサービスを保護します。 east-west トラフィックを捕捉する手順は、次のとおりです。 1. east-west トラフィックを ​`reviews`​ サービスに転送する ​`bookinfo-reviews`​ API インスタンスを作成します。 - ローカルモード: ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true EOF ``` - 接続モード: 接続モードで API インスタンスを追加するには、[Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex)を参照してください。 次のダウンストリームパラメーターを使用して、API インスタンスを設定します。 - **Protocol (プロトコル)**​: **HTTP** - **Port (ポート)**​: `8081` - **Base Path (ベースパス)**​: `/bookinfo/reviews/` 次のアップストリームパラメーターを使用して、API インスタンスを設定します。 - **Route label (ルートの表示ラベル)**​: `reviews` - **Upstream URL (アップストリーム URL)**​: `[http://reviews.bookinfo.svc:9080](http://reviews.bookinfo.svc:9080)` 2. `productpage`​ サービスと ​`reviews`​ サービス間のトラフィックを捕捉して、​`flex`​ サービスに転送します。 1. Istio API インスタンスを作成します。 ```ssh cat < HTTP/1.1 GET localhost/ingress/productpage [flex-gateway-envoy][info] wasm log bookinfo-reviews-message-logging-flex-1.flex.bookinfo-reviews.flex.svc main: [policy: bookinfo-reviews-message-logging-flex-1.flex][api: bookinfo-reviews.flex.svc][req: b23e9c64-a2aa-4464-8984-d1dd6c18f7ea] [accessLog] > HTTP/1.1 GET reviews:9080/bookinfo/reviews/reviews/0 ```
ログをすばやく確認するには、標準出力ログを使用します。標準出力ログの表示方法は、標準出力ログの表示を参照してください。
4. レート制限ポリシーを ​`bookinfo-reviews`​ API インスタンスに適用して、​`reviews`​ サービスを保護します。 ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true order: 0 - policyRef: name: rate-limiting-flex config: rateLimits: - timePeriodInMilliseconds: 60000 maximumRequests: 2 exposeHeaders: true EOF ``` 3. `bookinfo`​ サービスへの直接アクセスを制限します。 1. アクセスを制限します。 ```ssh cat < # Flex Gateway と Istio サービスメッシュの統合 Anypoint Platform コントロールプレーンから Flex Gateway のポリシー、ログ、メトリクスを活用するには、Flex Gateway を Istio サービスメッシュに統合します。Flex Gateway をイングレスゲートウェイとしてデプロイし、イングレス north-south クラスタートラフィックとクラスター内の内部 east-west トラフィックを管理します。 Flex Gateway を統合するには、次のアーキテクチャ図とチュートリアルを使用します。Flex Gateway は、 [Istio Bookinfo サンプルアプリケーション](https://istio.io/latest/docs/examples/bookinfo/)​の変更バージョンを使用して統合されます。Flex Gateway インテグレーションでは、次のようになります。 - Istio 仮想サービスがすべてのイングレス north-south トラフィックを Flex Gateway に転送します。 - `bookinfo`​ 名前空間への直接アクセスは制限されます。​`bookinfo`​ 名前空間へのすべての外部トラフィックは、​`flex`​ 名前空間から送信されている必要があります。Istio は ​`bookinfo`​ と ​`flex`​ 間の mTLS 設定を自動的に定義します。 - Flex Gateway は、API インスタンスを使用して、公開された商品ページサービスをイングレストラフィックから保護し、監視します。 - Istio サイドカーが商品ページサービスとレビューサービス間の east-west トラフィックを捕捉します。Flex Gateway は、レビューサービスへの受信トラフィックを管理するイングレスゲートウェイとして機能します。 ![Flex Gateway を Istio と統合するためのアーキテクチャを示している図](/mulesoft/current/ja-jp/gateway/1.8/_images/flex-istio-deployment.png)
この図では、Flex Gateway は接続モードで実行されています。Flex Gateway がローカルモードで実行されている場合、Anypoint Platform コントロールプレーンはありません。
このアーキテクチャを設定する手順は、次のとおりです。 1. [「始める前に」を完了します](#before-you-begin)​。 2. [環境をセットアップします](#setup-environment)​。 3. [イングレス north-south トラフィックを捕捉します](#forward-ingress-traffic)​。 4. [サービス間の east-west トラフィックを捕捉します](#create-a-service)​。 ## [](#before-you-begin)始める前に 始める前に、次の前提条件をインストールします。 - [Docker](https://docs.docker.com/get-docker/) - [Kubernetes クラスターで使用する Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install#kubernetes) - Docker の内部に Kubernetes クラスターを作成するための [K3d](https://k3d.io/v5.0.0/#installation) - Kubernetes クラスターを制御するための [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) - Flex Gateway と Istio をインストールするための [Helm](https://helm.sh/docs/intro/install/) ## [](#setup-environment)環境のセットアップ 1. このデモ用の Kubernetes クラスターを作成するか、使用するクラスターがすでにある場合はこのステップをスキップします。 ```ssh k3d cluster create demo-istio --k3s-arg "--disable=traefik@server:0" --port '80:80@server:0' --port '443:443@server:0' ``` 2. Flex Gateway と Istio の Helm リポジトリを追加します。 ```ssh helm repo add istio https://istio-release.storage.googleapis.com/charts \ && helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm \ && helm repo up ``` 3. Istio をインストールします。 1. Istio コントロールプレーンをデプロイする前にインストールする必要があるクラスター全体のカスタムリソース定義 (CRD) が含まれている Istio ベースチャートをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istio-base istio/base --version 1.21.2 --set defaultRevision=default ``` 2. `istiod`​ サービスをデプロイする Istio 検出チャートをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istiod istio/istiod --version 1.21.2 ``` 3. Istio イングレスゲートウェイをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istio-ingress istio/gateway --version 1.21.2 ``` 4. Flex Gateway をインストールします。 1. 名前空間を作成し、表示ラベルをセットアップして、サイドカーの挿入を有効にします。 ```ssh kubectl create ns flex && kubectl label ns flex istio-injection=enabled --overwrite ``` 2. Flex Gateway をインストールします。 ```ssh helm upgrade -i --wait -n flex --version 1.7.0 flex flex-gateway/flex-gateway \ --set gateway.scope=Namespace \ --set gateway.mode=connected \ --set service.type=ClusterIP \ --set service.http.port=8081 \ --set service.https.enabled=false \ --set-file registration.content=registration.yaml ``` 3. 以前に作成したすべてのサービスと API インスタンスをリストします。 ```ssh kubectl -n flex get svc ``` 5. `bookinfo`​ アプリケーションをインストールします。 1. デフォルトの名前空間で Istio 表示ラベルの挿入を有効にして、​`bookinfo`​ アプリケーションをインストールします。 ```ssh kubectl create ns bookinfo \ && kubectl label ns bookinfo istio-injection=enabled --overwrite \ && kubectl -n bookinfo apply -l version!=v2,version!=v3 -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml ``` 2. ポッドの状況を確認します。 ```ssh kubectl -n bookinfo get pods ``` 6. トラフィックをテストする ​`sleep`​ アプリケーションをインストールします。 1. `test`​ 名前空間を作成し、​`sleep`​ アプリケーションをインストールします。 ```ssh kubectl create ns test \ && kubectl label ns test istio-injection=enabled --overwrite \ && kubectl -n test apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/sleep/sleep.yaml ``` 2. ポッドの状況を確認します。 ```ssh kubectl -n test get pods ``` ## [](#forward-ingress-traffic)イングレス North-South トラフィックを捕捉します イングレス north-south トラフィックを捕捉して、サービスを外部トラフィックから保護します。 イングレス north-south トラフィックを捕捉する手順は、次のとおりです。 1. `bookinfo`​ 名前空間のすべてのイングレス north-south トラフィックを ​`productpage`​ サービスに転送する Flex Gateway イングレス API インスタンスを作成します。 - ローカルモード: ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true order: 0 EOF ``` ## [](#create-a-service)サービス間の East-West トラフィックの捕捉 Flex Gateway を使用して、サービス間の east-west トラフィックを捕捉し、ポリシーを使用してサービスを保護します。 east-west トラフィックを捕捉する手順は、次のとおりです。 1. east-west トラフィックを ​`reviews`​ サービスに転送する ​`bookinfo-reviews`​ API インスタンスを作成します。 - ローカルモード: ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true EOF ``` - 接続モード: 接続モードで API インスタンスを追加するには、[Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex)を参照してください。 次のダウンストリームパラメーターを使用して、API インスタンスを設定します。 - **Protocol (プロトコル)**​: **HTTP** - **Port (ポート)**​: `8081` - **Base Path (ベースパス)**​: `/bookinfo/reviews/` 次のアップストリームパラメーターを使用して、API インスタンスを設定します。 - **Route label (ルートの表示ラベル)**​: `reviews` - **Upstream URL (アップストリーム URL)**​: `[http://reviews.bookinfo.svc:9080](http://reviews.bookinfo.svc:9080)` 2. `productpage`​ サービスと ​`reviews`​ サービス間のトラフィックを捕捉して、​`flex`​ サービスに転送します。 1. Istio API インスタンスを作成します。 ```ssh cat < HTTP/1.1 GET localhost/ingress/productpage [flex-gateway-envoy][info] wasm log bookinfo-reviews-message-logging-flex-1.flex.bookinfo-reviews.flex.svc main: [policy: bookinfo-reviews-message-logging-flex-1.flex][api: bookinfo-reviews.flex.svc][req: b23e9c64-a2aa-4464-8984-d1dd6c18f7ea] [accessLog] > HTTP/1.1 GET reviews:9080/bookinfo/reviews/reviews/0 ```
ログをすばやく確認するには、標準出力ログを使用します。標準出力ログの表示方法は、標準出力ログの表示を参照してください。
4. レート制限ポリシーを ​`bookinfo-reviews`​ API インスタンスに適用して、​`reviews`​ サービスを保護します。 ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true order: 0 - policyRef: name: rate-limiting-flex config: rateLimits: - timePeriodInMilliseconds: 60000 maximumRequests: 2 exposeHeaders: true EOF ``` 3. `bookinfo`​ サービスへの直接アクセスを制限します。 1. アクセスを制限します。 ```ssh cat < # Flex Gateway と Istio サービスメッシュの統合 Anypoint Platform コントロールプレーンから Flex Gateway のポリシー、ログ、メトリクスを活用するには、Flex Gateway を Istio サービスメッシュに統合します。Flex Gateway をイングレスゲートウェイとしてデプロイし、イングレス north-south クラスタートラフィックとクラスター内の内部 east-west トラフィックを管理します。 Flex Gateway を統合するには、次のアーキテクチャ図とチュートリアルを使用します。Flex Gateway は、 [Istio Bookinfo サンプルアプリケーション](https://istio.io/latest/docs/examples/bookinfo/)​の変更バージョンを使用して統合されます。Flex Gateway インテグレーションでは、次のようになります。 - Istio 仮想サービスがすべてのイングレス north-south トラフィックを Flex Gateway に転送します。 - `bookinfo`​ 名前空間への直接アクセスは制限されます。​`bookinfo`​ 名前空間へのすべての外部トラフィックは、​`flex`​ 名前空間から送信されている必要があります。Istio は ​`bookinfo`​ と ​`flex`​ 間の mTLS 設定を自動的に定義します。 - Flex Gateway は、API インスタンスを使用して、公開された商品ページサービスをイングレストラフィックから保護し、監視します。 - Istio サイドカーが商品ページサービスとレビューサービス間の east-west トラフィックを捕捉します。Flex Gateway は、レビューサービスへの受信トラフィックを管理するイングレスゲートウェイとして機能します。 ![Flex Gateway を Istio と統合するためのアーキテクチャを示している図](/mulesoft/current/ja-jp/gateway/1.9/_images/flex-istio-deployment.png)
この図では、Flex Gateway は接続モードで実行されています。Flex Gateway がローカルモードで実行されている場合、Anypoint Platform コントロールプレーンはありません。
このアーキテクチャを設定する手順は、次のとおりです。 1. [「始める前に」を完了します](#before-you-begin)​。 2. [環境をセットアップします](#setup-environment)​。 3. [イングレス north-south トラフィックを捕捉します](#forward-ingress-traffic)​。 4. [サービス間の east-west トラフィックを捕捉します](#create-a-service)​。 ## [](#before-you-begin)始める前に 始める前に、次の前提条件をインストールします。 - [Docker](https://docs.docker.com/get-docker/) - [Kubernetes クラスターで使用する Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install#kubernetes) - Docker の内部に Kubernetes クラスターを作成するための [K3d](https://k3d.io/v5.0.0/#installation) - Kubernetes クラスターを制御するための [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) - Flex Gateway と Istio をインストールするための [Helm](https://helm.sh/docs/intro/install/) ## [](#setup-environment)環境のセットアップ 1. このデモ用の Kubernetes クラスターを作成するか、使用するクラスターがすでにある場合はこのステップをスキップします。 ```ssh k3d cluster create demo-istio --k3s-arg "--disable=traefik@server:0" --port '80:80@server:0' --port '443:443@server:0' ``` 2. Flex Gateway と Istio の Helm リポジトリを追加します。 ```ssh helm repo add istio https://istio-release.storage.googleapis.com/charts \ && helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm \ && helm repo up ``` 3. Istio をインストールします。 1. Istio コントロールプレーンをデプロイする前にインストールする必要があるクラスター全体のカスタムリソース定義 (CRD) が含まれている Istio ベースチャートをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istio-base istio/base --version 1.21.2 --set defaultRevision=default ``` 2. `istiod`​ サービスをデプロイする Istio 検出チャートをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istiod istio/istiod --version 1.21.2 ``` 3. Istio イングレスゲートウェイをインストールします。 ```ssh helm upgrade -i --wait --create-namespace -n istio-system istio-ingress istio/gateway --version 1.21.2 ``` 4. Flex Gateway をインストールします。 1. 名前空間を作成し、表示ラベルをセットアップして、サイドカーの挿入を有効にします。 ```ssh kubectl create ns flex && kubectl label ns flex istio-injection=enabled --overwrite ``` 2. Flex Gateway をインストールします。 ```ssh helm upgrade -i --wait -n flex --version 1.7.0 flex flex-gateway/flex-gateway \ --set gateway.scope=Namespace \ --set gateway.mode=connected \ --set service.type=ClusterIP \ --set service.http.port=8081 \ --set service.https.enabled=false \ --set-file registration.content=registration.yaml ``` 3. 以前に作成したすべてのサービスと API インスタンスをリストします。 ```ssh kubectl -n flex get svc ``` 5. `bookinfo`​ アプリケーションをインストールします。 1. デフォルトの名前空間で Istio 表示ラベルの挿入を有効にして、​`bookinfo`​ アプリケーションをインストールします。 ```ssh kubectl create ns bookinfo \ && kubectl label ns bookinfo istio-injection=enabled --overwrite \ && kubectl -n bookinfo apply -l version!=v2,version!=v3 -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml ``` 2. ポッドの状況を確認します。 ```ssh kubectl -n bookinfo get pods ``` 6. トラフィックをテストする ​`sleep`​ アプリケーションをインストールします。 1. `test`​ 名前空間を作成し、​`sleep`​ アプリケーションをインストールします。 ```ssh kubectl create ns test \ && kubectl label ns test istio-injection=enabled --overwrite \ && kubectl -n test apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/sleep/sleep.yaml ``` 2. ポッドの状況を確認します。 ```ssh kubectl -n test get pods ``` ## [](#forward-ingress-traffic)イングレス North-South トラフィックを捕捉します イングレス north-south トラフィックを捕捉して、サービスを外部トラフィックから保護します。 イングレス north-south トラフィックを捕捉する手順は、次のとおりです。 1. `bookinfo`​ 名前空間のすべてのイングレス north-south トラフィックを ​`productpage`​ サービスに転送する Flex Gateway イングレス API インスタンスを作成します。 - ローカルモード: ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true order: 0 EOF ``` ## [](#create-a-service)サービス間の East-West トラフィックの捕捉 Flex Gateway を使用して、サービス間の east-west トラフィックを捕捉し、ポリシーを使用してサービスを保護します。 east-west トラフィックを捕捉する手順は、次のとおりです。 1. east-west トラフィックを ​`reviews`​ サービスに転送する ​`bookinfo-reviews`​ API インスタンスを作成します。 - ローカルモード: ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true EOF ``` - 接続モード: 接続モードで API インスタンスを追加するには、[Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex)を参照してください。 次のダウンストリームパラメーターを使用して、API インスタンスを設定します。 - **Protocol (プロトコル)**​: **HTTP** - **Port (ポート)**​: `8081` - **Base Path (ベースパス)**​: `/bookinfo/reviews/` 次のアップストリームパラメーターを使用して、API インスタンスを設定します。 - **Route label (ルートの表示ラベル)**​: `reviews` - **Upstream URL (アップストリーム URL)**​: `[http://reviews.bookinfo.svc:9080](http://reviews.bookinfo.svc:9080)` 2. `productpage`​ サービスと ​`reviews`​ サービス間のトラフィックを捕捉して、​`flex`​ サービスに転送します。 1. Istio API インスタンスを作成します。 ```ssh cat < HTTP/1.1 GET localhost/ingress/productpage [flex-gateway-envoy][info] wasm log bookinfo-reviews-message-logging-flex-1.flex.bookinfo-reviews.flex.svc main: [policy: bookinfo-reviews-message-logging-flex-1.flex][api: bookinfo-reviews.flex.svc][req: b23e9c64-a2aa-4464-8984-d1dd6c18f7ea] [accessLog] > HTTP/1.1 GET reviews:9080/bookinfo/reviews/reviews/0 ```
ログをすばやく確認するには、標準出力ログを使用します。標準出力ログの表示方法は、標準出力ログの表示を参照してください。
4. レート制限ポリシーを ​`bookinfo-reviews`​ API インスタンスに適用して、​`reviews`​ サービスを保護します。 ```ssh cat < ' ++ attributes.version ++ ' ' ++ attributes.method ++ ' ' ++ attributes.headers.host ++ attributes.requestUri]" level: "INFO" firstSection: true - itemName: "Response" itemData: message: "#['< Status=' ++ attributes.statusCode ++ ' Length=' ++ (attributes.headers['content-length'] default 'none') ++ ' Time=' ++ (attributes.headers['x-envoy-upstream-service-time'] default 'none')]" level: "INFO" secondSection: true order: 0 - policyRef: name: rate-limiting-flex config: rateLimits: - timePeriodInMilliseconds: 60000 maximumRequests: 2 exposeHeaders: true EOF ``` 3. `bookinfo`​ サービスへの直接アクセスを制限します。 1. アクセスを制限します。 ```ssh cat < # Flex Gateway によるエージェントインタラクションの保護 Flex Gateway では、Model Context Protocol (MCP) と Agent2Agent (A2A) プロトコルの両方がサポートされるため、エージェントとシステムを保護できます。Flex Gateway では一元的な監視、エージェントの視覚化、ログ、有益なインサイトが提供されるため、エージェントベースのアーキテクチャを効果的に管理してセキュリティを確保できます。Flex Gateway では、エージェント接続でポリシーを適用し、エージェントアクティビティを監視して視覚化を強化することで、エージェントインタラクションを保護します。 ## [](#flex-gateway-の-a2a-サポート)Flex Gateway の A2A サポート A2A はエージェントが相互にやり取りする方法を定義するオープン標準であり、異なるチームが構築し、異なるテクノロジーを使用していて異なる組織によってホストされているエージェントの相互運用性を実現します。 Flex Gateway では、エージェント要求に適切な認証および承認を必須にして、エージェントカード URL を書き換え、メッセージに含まれる機密情報を記録またはブロックし、サーバー送信イベント (SSE) コンテンツをコンプライアンス監査用に記録することで、エージェントの A2A インタラクションを保護します。受信したプロンプトを追加コンテキストで変更し、サーバーエージェントの実行を改善することにより、エージェント要求を拡張できます。 ## [](#flex-gateway-の-mcp-サポート)Flex Gateway の MCP サポート MCP はエージェントがツールや外部コンテキストとやり取りする方法を定義するオープンプロトコルであり、エージェントは必要なデータやツールに接続できます。 Flex Gateway では、MCP エンドポイントアクセスを承認済みのエージェントのみに制限し、一元化された視覚化およびすべてのインタラクションの制御を通じて管理を簡素化することにより、MCP 接続を保護します。 ## [](#ポリシーによるエージェントインタラクションの保護)ポリシーによるエージェントインタラクションの保護 Flex Gateway には、セキュリティを強化してエージェントインタラクションを制御する A2A および MCP 固有のポリシーが含まれます。Flex Gateway の A2A ポリシーにより、エージェントカード URL を書き換え、メッセージに含まれる機密情報を記録またはブロックし、プロンプトの動作を変更して、サーバー送信イベント (SSE) コンテンツをコンプライアンス監査用に記録することで、エージェントエンドポイントを保護できます。Flex Gateway の MCP ポリシーにより、属性ベースのアクセス制御を使用して MCP サーバーへのアクセスを管理できます。 Flex Gateway の MCP および A2A サーバーインスタンスでは、Flex Gateway の他のポリシーもサポートされます。たとえば、​[レート制限ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-rate-limiting) or [スパイク制御ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-spike-control)​などのポリシーを使用して MCP および A2A サーバーに対する要求数を管理したり、[メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-message-logging)を使用してエージェントインタラクションを監視したりします。 含まれている A2A および MCP ポリシーについては、[Flex Gateway エージェントポリシー](https://docs.mulesoft.com/jp/gateway/1.10/flex-agent-policies)を参照してください。 ## [](#関連情報)関連情報 - [Introducing Governance for Agent Interactions With Support for A2A & MCP (A2A および MCP のサポートによるエージェントインタラクションの管理の紹介)](https://blogs.mulesoft.com/news/mulesoft-governance-for-agent-interactions/) - [A2A プロトコルの仕様](https://google.github.io/A2A/topics/what-is-a2a/) - [MCP プロトコルの仕様](https://modelcontextprotocol.io/introduction) - [Streaming & Asynchronous Operations in A2A (A2A でのストリーミングおよび非同期操作)](https://google.github.io/A2A/topics/streaming-and-async/) # Flex Gateway によるエージェントインタラクションの保護 Flex Gateway では、Model Context Protocol (MCP) と Agent2Agent (A2A) プロトコルの両方がサポートされるため、エージェントとシステムを保護できます。Flex Gateway では一元的な監視、エージェントの視覚化、ログ、有益なインサイトが提供されるため、エージェントベースのアーキテクチャを効果的に管理してセキュリティを確保できます。Flex Gateway では、エージェント接続でポリシーを適用し、エージェントアクティビティを監視して視覚化を強化することで、エージェントインタラクションを保護します。 ## [](#flex-gateway-の-a2a-サポート)Flex Gateway の A2A サポート A2A はエージェントが相互にやり取りする方法を定義するオープン標準であり、異なるチームが構築し、異なるテクノロジーを使用していて異なる組織によってホストされているエージェントの相互運用性を実現します。 Flex Gateway では、エージェント要求に適切な認証および承認を必須にして、エージェントカード URL を書き換え、メッセージに含まれる機密情報を記録またはブロックし、サーバー送信イベント (SSE) コンテンツをコンプライアンス監査用に記録することで、エージェントの A2A インタラクションを保護します。受信したプロンプトを追加コンテキストで変更し、サーバーエージェントの実行を改善することにより、エージェント要求を拡張できます。 ## [](#flex-gateway-の-mcp-サポート)Flex Gateway の MCP サポート MCP はエージェントがツールや外部コンテキストとやり取りする方法を定義するオープンプロトコルであり、エージェントは必要なデータやツールに接続できます。 Flex Gateway では、MCP エンドポイントアクセスを承認済みのエージェントのみに制限し、一元化された視覚化およびすべてのインタラクションの制御を通じて管理を簡素化することにより、MCP 接続を保護します。 ## [](#ポリシーによるエージェントインタラクションの保護)ポリシーによるエージェントインタラクションの保護 Flex Gateway には、セキュリティを強化してエージェントインタラクションを制御する A2A および MCP 固有のポリシーが含まれます。Flex Gateway の A2A ポリシーにより、エージェントカード URL を書き換え、メッセージに含まれる機密情報を記録またはブロックし、プロンプトの動作を変更して、サーバー送信イベント (SSE) コンテンツをコンプライアンス監査用に記録することで、エージェントエンドポイントを保護できます。Flex Gateway の MCP ポリシーにより、属性ベースのアクセス制御を使用して MCP サーバーへのアクセスを管理できます。 Flex Gateway の MCP および A2A サーバーインスタンスでは、Flex Gateway の他のポリシーもサポートされます。たとえば、​[レート制限ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-rate-limiting) or [スパイク制御ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-spike-control)​などのポリシーを使用して MCP および A2A サーバーに対する要求数を管理したり、[メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-message-logging)を使用してエージェントインタラクションを監視したりします。 含まれている A2A および MCP ポリシーについては、[Flex Gateway エージェントポリシー](https://docs.mulesoft.com/jp/gateway/1.9/flex-agent-policies)を参照してください。 ## [](#関連情報)関連情報 - [Introducing Governance for Agent Interactions With Support for A2A & MCP (A2A および MCP のサポートによるエージェントインタラクションの管理の紹介)](https://blogs.mulesoft.com/news/mulesoft-governance-for-agent-interactions/) - [A2A とは?](https://a2aproject.github.io/A2A/topics/what-is-a2a/) - [A2A プロトコルの仕様](https://a2aproject.github.io/A2A/latest/specification/) - [MCP プロトコルの仕様](https://modelcontextprotocol.io/introduction) - [Streaming & Asynchronous Operations in A2A (A2A でのストリーミングおよび非同期操作)](https://a2aproject.github.io/A2A/topics/streaming-and-async/) # Flex Gateway のアップグレード Flex Gateway は、Linux サービスとして、Docker コンテナで、または Kubernetes クラスターからアップグレードできます。

20%

25%

20%

Linux サービスとしてのアップグレード

Docker コンテナでのアップグレード

Kubernetes クラスターでのアップグレード
## [](#linux)Linux サービスとしてのアップグレード Flex Gateway は、標準パッケージとして配布できます。次の手順に従って、Flex Gateway を特定のバージョンまたは最新バージョンにアップグレードしてください。 Linux サービスとして Flex Gateway をアップグレードまたはダウングレードするには、次の手順を実行します。 1. 利用可能なパッケージのリストを更新します。 ```ssh sudo apt update ``` 選択可能なバージョンをリストするには、次のコマンドを実行します。 ```ssh apt list -a flex-gateway ``` 2. Flex Gateway を更新します。 - 最新バージョンに更新する場合: ```ssh sudo apt --only-upgrade -y install flex-gateway ``` - 特定バージョンに更新する場合: ```ssh sudo apt --only-upgrade -y install flex-gateway= ``` - ダウングレードバージョンに更新する場合: ```ssh sudo apt --only-upgrade -y --allow-downgrades install flex-gateway= ``` 3. サービスを再起動します。 ```ssh sudo systemctl restart flex-gateway ``` ## [](#docker)Docker コンテナでのアップグレード Docker コンテナを更新することはできませんので、新しいバージョンが必要な場合は、新しいイメージバージョンで新しいコンテナを作成し、古いコンテナを置き換えてください。 新しいイメージバージョンは、 [mulesoft/flex-gateway](https://hub.docker.com/r/mulesoft/flex-gateway)​ のリンクから入手できます。 ## [](#kubernetes)Kubernetes クラスターでのアップグレード 1. それぞれのチャートリポジトリでチャートを更新します。 ```ssh helm repo up ``` 2. 次のコマンドを (必要な箇所を実際の情報に置き換えて) 実行し、リリースを新しいバージョンの Helm チャートに更新します。 ```ssh helm upgrade -n flex-gateway/flex-gateway --wait ``` # Flex Gateway のアップグレードと保守 Flex Gateway リリースチャネルおよび Flex Gateway 保守タスクについては、以下のトピックを参照してください。 Flex Gateway リリースケイデンスおよびサポート - [Flex Gateway バージョンのライフサイクル](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-version-lifecycle) 管理 Flex Gateway の保守 - [管理 Flex Gateway のアップグレードまたは削除](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-managed-upgrade-delete) 自己管理 Flex Gateway の保守 - [自己管理 Flex Gateway のアップグレード](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-upgrade) - [自己管理 Flex Gateway のインスタンスの削除](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-delete) - [自己管理 Flex Gateway のアンインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-uninstall) - [自己管理 Flex Gateway の登録の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-renew-certificate) # Flex Gateway のアップグレードと保守 Flex Gateway リリースチャネルおよび Flex Gateway 保守タスクについては、以下のトピックを参照してください。 Flex Gateway リリースケイデンスおよびサポート - [Flex Gateway バージョンのライフサイクル](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-version-lifecycle) 管理 Flex Gateway の保守 - [管理 Flex Gateway のアップグレードまたは削除](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-managed-upgrade-delete) 自己管理 Flex Gateway の保守 - [自己管理 Flex Gateway のアップグレード](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-upgrade) - [自己管理 Flex Gateway のインスタンスの削除](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-delete) - [自己管理 Flex Gateway のアンインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-uninstall) - [自己管理 Flex Gateway の登録の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-renew-certificate) # Flex Gateway のアンインストール Linux サービスとして実行されている Flex Gateway は、コンテナまたは Kubernetes クラスターでアンインストールできます。

20%

25%

20%

Linux サービスとして実行されている Flex Gateway のアンインストール

Docker コンテナで実行されている Flex Gateway をアンインストールする

Kubernetes クラスターで実行されている Flex Gateway をアンインストールする
## [](#linux)Linux サービスとして実行されている Flex Gateway のアンインストール Flex Gateway は他のパッケージと同じようにアンインストールできます。 ```ssh sudo apt remove -y flex-gateway ``` ## [](#docker)Docker コンテナで実行されている Flex Gateway をアンインストールする Flex Gateway をアンインストールするには、Flex Gateway コンテナを停止して削除します。 1. 実行されているすべてのコンテナをりすとして Flex Gateway コンテナ ID を判断します。 ```ssh docker ps ``` 2. コンテナのリストで、アンインストールする Flex Gateway コンテナに関連付けられたコンテナ ID をメモします。 3. Flex Gateway コンテナを停止します。 ```ssh docker stop ``` ` ``` `実行中のリリースに ​my-release​ を更新します。すべてのリリースのリストを表示するには、コマンド ​helm list -A​ を使用します。 2. リリースの名前空間が指定されている場合は削除します。 ```ssh kubectl delete namespace gateway ``` 3. カスタムリソース定義を削除します。 ```ssh kubectl delete crds \ apiinstances.gateway.mulesoft.com \ configurations.gateway.mulesoft.com \ extensions.gateway.mulesoft.com \ policybindings.gateway.mulesoft.com \ services.gateway.mulesoft.com ``` # Flex Gateway のインスタンスの削除 Runtime Manager でゲートウェイとレプリカを削除する手順は次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateway\]**​ を選択します。 3. 削除するゲートウェイのアクションメニューボタンをクリックします。 4. **\[Delete gateway (ゲートウェイを削除)\]**​ をクリックします。 削除するゲートウェイに API が関連付けられている場合は、Runtime Manager からメッセージが表示され、次のいずれかが要求されます。 - 関連付けられている API を別のゲートウェイに移動する。 - 関連付けられている API をすべて削除する。 関連付けられている API をすべて移動または削除したら、上記の手順でゲートウェイを削除して、削除を確認してください。 ## [](#flex-gateway-の状況)Flex Gateway の状況 次の表に、ゲートウェイの各状況の意味を示します。
状況名 説明

Connected (接続済み)

ゲートウェイはプラットフォームに接続済みであり、API を追加できます。

Disconnected (切断済み)

ゲートウェイはプラットフォームに接続されていません。

Deleting (削除中)

ゲートウェイに対して削除処理が実行中です。

Deleted (削除済み)

ゲートウェイはプラットフォームから削除されました。API 要求や設定の変更は受け入れず、メトリクスのレポートも停止しています。
削除済みのゲートウェイの状況は、30 日間 ​`[Deleted (削除済み)]`​ と表示された後にゲートウェイリストから削除されます。
ゲートウェイを削除すると、設定履歴が失われ、復元することはできません。
# Flex Gateway のセキュリティのベストプラクティス このページでは、Flex Gateway ランタイムデプロイメントでの業界標準への準拠を確保するためのベストプラクティスを提供します。 Flex Gateway デプロイメントはランタイムとコントロールプレーンで構成されます。設定データやログなどの情報は、mTLS 通信を介してコントロールプレーンの Anypoint Platform とランタイムプレーンの Flex Gateway 間で共有されます。ランタイムレイヤーでは、Flex Gateway によって受信トラフィックがオーケストレーションされ、アップストリームまたは API が保護されます。Flex Gateway は、YAML 登録ファイルを使用して Anypoint Platform に登録されます。Flex Gateway では Redis 共有ストレージを使用して他の Flex レプリカと通信するためのデータをキャッシュし、要求データをキャッシュします。次の図は、Flex Gateway デプロイメントを示しています。 ![security best practices](/mulesoft/current/ja-jp/gateway/1.8/_images/security-best-practices.png)
1 Anypoint Platform での Flex Gateway の保護
2 Flex Gateway の保護:

  1. Flex Gateway サービスポッドの保護

  2. Flex Gateway の更新
3 Flex Gateway 登録リソースの保護
4 Flex 証明書の更新
5 ペイロードデータの記録の回避
6 Redis 共有ストレージの保護
7 受信トラフィック (API コンシューマーから Flex Gateway) のフローの保護
8 アップストリームサービス (Flex Gateway から API プロバイダー) の保護​:

  1. Flex Gateway がローカルで使用可能なサービスの保護

  2. 外部サービスの保護
9 定期的なテストの実行
このページのガイドラインはすべての Flex Gateway ランタイム環境に適用されますが、図は Kubernetes 用にのみ提供されています。
## [](#secure-flex-gateway-in-anypoint-platform)Anypoint Platform での Flex Gateway の保護 Anypoint Platform の Flex Gateway には必ず最小権限の原理を適用してください。Flex Gateway へのアクセス権を持つユーザーは Flex Gateway の設定の詳細やログを参照できます。ランタイムを保守するユーザーのみに Flex Gateway へのアクセス権を制限するには、ユーザーとチームの権限を使用します。ゲートウェイ設定をデプロイまたは管理するユーザー以外には参照のみアクセス権を付与してください。 アクセス権を管理する方法については、[アクセス管理について](https://docs.mulesoft.com/jp/access-management/)を参照してください。 ## [](#secure-the-flex-gateway-registration-resource)Flex Gateway 登録リソースの保護 Flex Gateway では登録情報をローカルに保存します。この登録リソースには、Flex レプリカが Anypoint Platform と通信して自己認証するために使用する証明書が含まれます。Flex Gateway は mTLS を介して Anypoint Platform と通信します。 レプリカの未認証実行を防止するには、登録リソースへのアクセスを制限します。具体的には次の情報が保存されます。 - 必ず保管時のシークレットを暗号化し、登録リソースシークレットには最小権限を適用してください。 - ログイン情報や API キーなどの機密データは、AWS Secrets Manager、Azure Key Vault、HashiCorp Vault などのセキュアな Vault に保存してください。 - シークレットのハードコードは避け、環境変数は機密でない設定のみに使用してください。 - 設定ファイルの機密情報は暗号化してください。 Kubernetes デプロイメントのベストプラクティスについては、 [「Good practices for Kubernetes Secrets (Kubernetes シークレットのグッドプラクティス)」](https://kubernetes.io/docs/concepts/security/secrets-good-practices/)​を参照してください。 ## [](#renew-the-flex-certificate)Flex 証明書の更新 Anypoint Flex Gateway では、管理された PKI 証明書を使用して Anypoint Platform と通信します。この証明書は、Flex Gateway を登録するときに生成されます。有効期限より前に証明書を更新して、ランタイムがコントロールプレーンに接続できるようにしてください。 登録を更新する方法については、[Flex Gateway の登録の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-renew-certificate)を参照してください。 ## [](#update-your-flex-gateway)Flex Gateway の更新 MuleSoft では、Flex Gateway のセキュリティ更新を定期的に提供します。脆弱性を解決できるように、Flex Gateway を常に最新バージョンに更新してください。非互換性のリスクを低減するには、安全な変更プロセスに従って本番より先に Sandbox ランタイムをアップグレードしてください。 Flex Gateway の更新方法についての詳細は、[Flex Gateway のアップグレード](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-upgrade)を参照してください。 ## [](#avoid-logging-payload-data)ペイロードデータの記録の回避 ランタイムログは lex Gateway ポッドの ​`stdout`​ を介して使用でき、接続モードでは Anypoint コントロールプレーンにあります。 ランタイムログが侵害されてクライアント情報が漏洩しないように、ペイロードデータをランタイムログに記録することは避けてください。 他のサードパーティ監視および分析プラットフォームを使用している場合は、アクセスレビューにかけることを検討してください。 ## [](#secure-flex-gateway-service-pods)Flex Gateway サービスポッドの保護 権限を持たない人が Flex Gateway 設定データにアクセスしたりランタイムを改ざんしたりできないようにするには、Flex Gateway ランタイムポッドへのアクセスを制限します。 Kubernetes デプロイメントでは、Kubernetes ロールベースのアクセス制御 (RBAC) を使用してポッドでのコマンド実行へのアクセスを制限します。詳細は、 [「Using RBAC Authorization (RBAC 認証の使用)」](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​を参照してください。 Kubernetes 以外のデプロイメントでは、セッションを開くための Flex Gateway 仮想マシンへのアクセスを制限します。 ## [](#secure-redis-shared-storage)Redis 共有ストレージの保護 Flex Gateway では接続モードでのみ Redis 共有ストレージを使用して要求データやランタイム設定をキャッシュします。未認証ユーザーであっても Flex 設定や要求処理キャッシュなどのキャッシュされた設定データを取得し、ランタイムを中断できます。不正なアクセスを防止するには、Redis サービスを保護する必要があります。 Redis 共有ストレージを保護するには、 [「Redis Recommended security practices (Redis 推奨セキュリティプラクティス)」](https://redis.io/docs/latest/operate/rs/security/recommended-security-practices/)​を参照してください。アクセス制限を有効にして、Flex Gateway 以外のソースからの Redis アクセスを制限します。脆弱性をさらに制限できるように、Redis は Flex Gateway デプロイメントとできるだけ近い場所にデプロイしてください。 ## [](#protect-the-flow-of-incoming-traffic)受信トラフィック (API コンシューマーから Flex Gateway) のフローの保護 受信トラフィックのフローを外部からの攻撃から保護する方法は、受信トラフィックのソースに応じて異なります。 公開インターネットから受信する要求の場合、トラフィックが Flex Gateway に到達する前に捕捉できるように最初の防衛線システムを設定します。Flex Gateway では API レベルの保護が提供されますが、最初の防衛線に関しては他の一般的な保護に依存します。次の保護があることを確認してください。 - ACL や DNS ファイアウォールなどのネットワークレベルの保護。通常のクラウドプロバイダーやサードパーティではこれらの保護を提供しています。 - DDoS 攻撃や Web アプリケーションファイアウォールに対する脅威保護などの第一線のアプリケーションレベルの保護。
外部ソースからの受信要求の処理に関するガイドラインについては、​ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている and ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている​を参照してください。
### [](#terminate-external-tls-at-point-of-entry)エントリポイントでの外部 TLS の終了 ファイアウォールで L7 トラフィックセキュリティインスペクションを実行できるようにするには、ファイアウォールレベルで外部 TLS 接続を終了します。コンシューマーによって認識される有効な証明機関 (CA) では通常、このエントリポイントの証明書を提供しています。 ファイアウォール、Flex Gateway、インフラストラクチャのその他のサービス間の内部通信に個別の証明書のセットを使用します。この通信では、内部機関または PKI が発行する両方の証明書で mTLS セキュリティを使用します。 インターネットに公開される証明書は内部では使用されず、内部で使用される証明書はインターネットには公開されません。内部と外部の証明書を分離することで、内部証明書が漏洩するリスクを防止します。 Flex Gateway はランタイム環境イングレスレイヤーと内部環境レイヤーの両方で使用できます。イングレスレイヤーの Flex Gateway の場合、ゲートウェイのスコープを TLS の終了、ルーティング、およびその他の基本的な保護に制限します。より多くの CPU およびメモリの負荷が大きい操作を内部 Flex Gateway にプッシュします。 ### [](#protect-apis-by-using-policies)ポリシーを使用した API の保護 ポリシーを適用して API の保護を強化します。Flex Gateway では​[内部ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory)​が提供されており、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を使用してカスタムポリシーを開発できます。 ### [](#govern-apis-by-using-api-governance)API Governance を使用した API の管理 [Anypoint API Governance](https://docs.mulesoft.com/api-governance/)​ を使用して、MuleSoft、業種、組織のベストプラクティスに従って API を設計してデプロイできるようにします。 ## [](#protect-the-upstream-service)アップストリームサービス (Flex Gateway から API プロバイダー) の保護 Flex からアップストリームへのトラフィックのフローを保護する方法は、アップストリームサービスの場所に応じて異なります。 ### [](#protect-services-available-locally-to-flex-gateway)Flex Gateway がローカルで使用可能なサービスの保護 Flex Gateway と同じネットワークを共有するサービスでは、通常、セキュリティ制限が緩くなっています。 組織はプレーンまたは TLS 接続が適切であるかどうかを定義する必要があります。TLS を使用している場合は、Flex Gateway アウトバウンド TLS コンテキストを介して mTLS を設定します。TLS の設定についての詳細は、以下を参照してください。 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config) 同じネットワークの他のサービスからアップストリームサービスを保護するには、Flex Gateway からトラフィックを受け入れるようにアップストリームサービスを設定します。Kubernetes の場合は、ネットワークポリシーを使用してこれを設定します。
内部アップストリームサービスへの通信に関するガイドラインについては、​ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている and ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている​を参照してください。
### [](#protect-external-services)外部サービスの保護 同じネットワークにない外部サービスを保護する場合は、mTLS 通信を使用してサービスを接続します。ネットワーク間で非公開 VPC などの信頼済みネットワークリンクを設定し、Flex Gateway がサービスを公開インターネットに公開せずに安全にアップストリームサービスにアクセスできるようにします。
外部アップストリームサービスへの通信に関するガイドラインについては、​ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている and ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている​を参照してください。
## [](#perform-regular-testing)定期的なテストの実行 定期的な侵入および脆弱性テストを実行し、Flex Gateway デプロイメントや公開される API の新たな問題や再発した問題を特定してください。テストの際には、セキュリティに関する次の側面を考慮してください。 - Runtime Manager の Flex 登録、Anypoint Monitoring のログ、API Manager の API にアクセスできるようにする Anypoint Platform のユーザーアクセス制御。 - 機能やデータに影響するデプロイ済みの Flex Gateway へのアクセス。 - Flex ランタイム画使用する設定ファイル、特に登録ファイルへのアクセス。 - Redis 共有ストレージサービスへのアクセス。 - Flex Gateway でデプロイされる API へのアクセス。 - Flex Gateway API によって保護されるアップストリームサービスへのアクセス。 ## [](#関連情報)関連情報 - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc-overview) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-shared-storage) # Flex Gateway のセットアップ Anypoint Flex Gateway をセットアップするには、インストールと登録を行います。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Linux でインストールします。Docker または Kubernetes 用にダウンロードします。 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - Anypoint ユーザー名とパスワード、接続アプリケーション、またはトークンを使用して、接続モードで登録します。 - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) - Anypoint ユーザー名とパスワード、接続アプリケーション、またはトークンを使用して、ローカルモードで登録します。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway のダウンロード Flex Gateway を Linux サービスとしてダウンロードしてインストールするか、Flex Gateway イメージをコンテナレジストリからダウンロードします。ゲートウェイを Linux サービスとして登録して実行するか、コンテナ、Kubernetes クラスター、または OpenShift クラスターで登録して実行するには、ダウンロードが前提条件になります。 Flex Gateway を仮想マシン (VM) の内部で実行するには、Flex Gateway を Linux サービスとしてダウンロードしてインストールします。Flex Gateway をコンテナ、Kubernetes クラスター、または OpenShift クラスターで実行するには、Flex Gateway イメージをダウンロードします。

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
ハードウェア要件とソフトウェア要件についての詳細は、[Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites)を参照してください。 ## [](#linux)Linux サービスとしてのダウンロードおよびインストール Flex Gateway は、次の Linux 環境のいずれかにサービスとしてダウンロードしてインストールできます。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-ubuntu-logo.png)​ Ubuntu Ubuntu サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Ubuntu で動作します。 - Ubuntu Jammy ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) - [lsb\_release](https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html) ##### インストールコマンドの実行 Flex Gateway を Ubuntu サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - パブリックパッケージキーの取得とパッケージリポジトリの追加 - パッケージリストの更新 - `apt-get`​ の更新 - Flex Gateway パッケージのインストール ```ssh curl -XGET https://flex-packages.anypoint.mulesoft.com/ubuntu/pubkey.gpg | sudo apt-key add - echo "deb [arch=amd64] https://flex-packages.anypoint.mulesoft.com/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mulesoft.list sudo apt update sudo apt install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-debian-logo.png)​ Debian Debian サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Debian で動作します。 - Debian Bookworm ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) - [lsb\_release](https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html) ##### インストールコマンドの実行 Flex Gateway を Debian サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - パブリックパッケージキーの取得とパッケージリポジトリの追加 - パッケージリストの更新 - `apt-get`​ の更新 - Flex Gateway パッケージのインストール ```ssh curl -XGET https://flex-packages.anypoint.mulesoft.com/debian/pubkey.gpg | sudo apt-key add - echo "deb [arch=amd64] https://flex-packages.anypoint.mulesoft.com/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mulesoft.list sudo apt update sudo apt install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-amazon-linux-logo.png)​ Amazon Linux Amazon Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Amazon Linux で動作します。 - Amazon Linux 2023 ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Amazon Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/amazonlinux/2023/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/amazonlinux/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-rhel-logo.png)​ Red Hat Enterprise Linux Red Hat Enterprise Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの RHEL で動作します。 - Red Hat Enterprise Linux (9) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Red Hat Enterprise Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/rhel/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/rhel/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 #### ![6%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-rhel-ibm-logo.png)​ IBM Power の Red Hat Enterprise Linux IBM Power の Red Hat Enterprise Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Red Hat Enterprise Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/rhel/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/rhel/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-centos-logo.png)​ CentOS CentOS サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの CentOS で動作します。 - CentOS 8 ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を CentOS サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/centos/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/centos/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` CentOS パッケージマネージャーの問題により次のエラーが発生する場合があります。 Error: Failed to download metadata for repo 'AppStream': Cannot prepare internal mirrorlist: No URLs in mirrorlist このエラーが発生した場合、次のコマンドを実行します。 ```ssh sudo sed -i -e "s|mirrorlist=|#mirrorlist=|g" -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-* ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 ## [](#container)コンテナで使用する Flex Gateway のダウンロード Flex Gateway は、次のコンテナのいずれかにダウンロードしてインストールできます。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-docker-logo.png)​ Docker Docker コンテナで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Docker コンテナでゲートウェイを登録および実行するための準備を整えます。 1. Flex Gateway の Docker イメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.10/_images/install-podman-logo.png)​ Podman Podman コンテナで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Podman コンテナでゲートウェイを登録および実行するための準備を整えます。 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.10/#connected-mode-vs-local-mode)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Kubernetes クラスターでゲートウェイを登録および実行するための準備を整えます。次のコンテナランタイムを使用できます。 **Docker** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 **Podman** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 ## [](#openshift)OpenShift クラスターで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、OpenShift クラスターでゲートウェイを登録および実行するための準備を整えます。次のコンテナランタイムを使用できます。 **Docker** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 **Podman** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​で登録します。 ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) # Flex Gateway のダウンロード Flex Gateway を Linux サービスとしてダウンロードしてインストールするか、Flex Gateway イメージをコンテナレジストリからダウンロードします。ゲートウェイを Linux サービスとして登録して実行するか、コンテナ、Kubernetes クラスター、または OpenShift クラスターで登録して実行するには、ダウンロードが前提条件になります。 Flex Gateway を仮想マシン (VM) の内部で実行するには、Flex Gateway を Linux サービスとしてダウンロードしてインストールします。Flex Gateway をコンテナ、Kubernetes クラスター、または OpenShift クラスターで実行するには、Flex Gateway イメージをダウンロードします。

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
ハードウェア要件とソフトウェア要件についての詳細は、[Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.8/flex-review-prerequisites)を参照してください。 ## [](#linux)Linux サービスとしてのダウンロードおよびインストール Flex Gateway は、次の Linux 環境のいずれかにサービスとしてダウンロードしてインストールできます。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-ubuntu-logo.png)​ Ubuntu Ubuntu サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Ubuntu で動作します。 - Ubuntu (Focal, Jammy) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) - [lsb\_release](https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html) ##### インストールコマンドの実行 Flex Gateway を Ubuntu サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - パブリックパッケージキーの取得とパッケージリポジトリの追加 - パッケージリストの更新 - `apt-get`​ の更新 - Flex Gateway パッケージのインストール ```ssh curl -XGET https://flex-packages.anypoint.mulesoft.com/ubuntu/pubkey.gpg | sudo apt-key add - echo "deb [arch=amd64] https://flex-packages.anypoint.mulesoft.com/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mulesoft.list sudo apt update sudo apt install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-debian-logo.png)​ Debian Debian サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Debian で動作します。 - Debian (Bullseye, Bookworm) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) - [lsb\_release](https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html) ##### インストールコマンドの実行 Flex Gateway を Debian サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - パブリックパッケージキーの取得とパッケージリポジトリの追加 - パッケージリストの更新 - `apt-get`​ の更新 - Flex Gateway パッケージのインストール ```ssh curl -XGET https://flex-packages.anypoint.mulesoft.com/debian/pubkey.gpg | sudo apt-key add - echo "deb [arch=amd64] https://flex-packages.anypoint.mulesoft.com/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mulesoft.list sudo apt update sudo apt install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-amazon-linux-logo.png)​ Amazon Linux Amazon Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Amazon Linux で動作します。 - Amazon Linux 2023 ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Amazon Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/amazonlinux/2023/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/amazonlinux/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-rhel-logo.png)​ Red Hat Enterprise Linux Red Hat Enterprise Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの RHEL で動作します。 - Red Hat Enterprise Linux (9) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Red Hat Enterprise Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/rhel/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/rhel/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![6%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-rhel-ibm-logo.png)​ IBM Power の Red Hat Enterprise Linux IBM Power の Red Hat Enterprise Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Red Hat Enterprise Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/rhel/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/rhel/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-suse-logo.png)​ SUSE Linux Enterprise SUSE Linux Enterprise サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - SUSE Linux Enterprise (SLES 15 SP3) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を SUSE Linux Enterprise サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo rpm --import https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg sudo tee /etc/zypp/repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/suse/$releasever_major/main gpgcheck = 1 gpgkey = https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg repo_gpgcheck = 1 enabled = 1 EOF sudo zypper refresh -f flex-gateway sudo zypper install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![6%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-suse-ibm-logo.png)​ IBM Power の SUSE Linux Enterprise IBM Power の SUSE Linux Enterprise サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を IBM Power の SUSE Linux Enterprise サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo rpm --import https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg sudo tee /etc/zypp/repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/suse/$releasever_major/main gpgcheck = 1 gpgkey = https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg repo_gpgcheck = 1 enabled = 1 EOF sudo zypper refresh -f flex-gateway sudo zypper install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-centos-logo.png)​ CentOS CentOS サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの CentOS で動作します。 - CentOS 8 ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を CentOS サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/centos/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/centos/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` CentOS パッケージマネージャーの問題により次のエラーが発生する場合があります。 Error: Failed to download metadata for repo 'AppStream': Cannot prepare internal mirrorlist: No URLs in mirrorlist このエラーが発生した場合、次のコマンドを実行します。 ```ssh sudo sed -i -e "s|mirrorlist=|#mirrorlist=|g" -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-* ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 ## [](#container)コンテナで使用する Flex Gateway のダウンロード Flex Gateway は、次のコンテナのいずれかにダウンロードしてインストールできます。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-docker-logo.png)​ Docker Docker コンテナで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Docker コンテナでゲートウェイを登録および実行するための準備を整えます。 1. Flex Gateway の Docker イメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:1.8.0 ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway 1.8.0 ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.8/_images/install-podman-logo.png)​ Podman Podman コンテナで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Podman コンテナでゲートウェイを登録および実行するための準備を整えます。 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:1.8.0 ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway 1.8.0 ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.8/#connected-mode-vs-local-mode)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Kubernetes クラスターでゲートウェイを登録および実行するための準備を整えます。次のコンテナランタイムを使用できます。 **Docker** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:1.8.0 ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway 1.8.0 ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 **Podman** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:1.8.0 ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway 1.8.0 ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 ## [](#openshift)OpenShift クラスターで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、OpenShift クラスターでゲートウェイを登録および実行するための準備を整えます。次のコンテナランタイムを使用できます。 **Docker** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:1.8.0 ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway 1.8.0 ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 **Podman** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:1.8.0 ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway 1.8.0 ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​で登録します。 ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.8/flex-review-prerequisites) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) # Flex Gateway のダウンロード Flex Gateway を Linux サービスとしてダウンロードしてインストールするか、Flex Gateway イメージをコンテナレジストリからダウンロードします。ゲートウェイを Linux サービスとして登録して実行するか、コンテナ、Kubernetes クラスター、または OpenShift クラスターで登録して実行するには、ダウンロードが前提条件になります。 Flex Gateway を仮想マシン (VM) の内部で実行するには、Flex Gateway を Linux サービスとしてダウンロードしてインストールします。Flex Gateway をコンテナ、Kubernetes クラスター、または OpenShift クラスターで実行するには、Flex Gateway イメージをダウンロードします。

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
ハードウェア要件とソフトウェア要件についての詳細は、[Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites)を参照してください。 ## [](#linux)Linux サービスとしてのダウンロードおよびインストール Flex Gateway は、次の Linux 環境のいずれかにサービスとしてダウンロードしてインストールできます。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-ubuntu-logo.png)​ Ubuntu Ubuntu サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Ubuntu で動作します。 - Ubuntu (Focal, Jammy) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) - [lsb\_release](https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html) ##### インストールコマンドの実行 Flex Gateway を Ubuntu サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - パブリックパッケージキーの取得とパッケージリポジトリの追加 - パッケージリストの更新 - `apt-get`​ の更新 - Flex Gateway パッケージのインストール ```ssh curl -XGET https://flex-packages.anypoint.mulesoft.com/ubuntu/pubkey.gpg | sudo apt-key add - echo "deb [arch=amd64] https://flex-packages.anypoint.mulesoft.com/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mulesoft.list sudo apt update sudo apt install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-debian-logo.png)​ Debian Debian サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Debian で動作します。 - Debian (Bullseye, Bookworm) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) - [lsb\_release](https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/lsbrelease.html) ##### インストールコマンドの実行 Flex Gateway を Debian サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - パブリックパッケージキーの取得とパッケージリポジトリの追加 - パッケージリストの更新 - `apt-get`​ の更新 - Flex Gateway パッケージのインストール ```ssh curl -XGET https://flex-packages.anypoint.mulesoft.com/debian/pubkey.gpg | sudo apt-key add - echo "deb [arch=amd64] https://flex-packages.anypoint.mulesoft.com/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mulesoft.list sudo apt update sudo apt install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-amazon-linux-logo.png)​ Amazon Linux Amazon Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Amazon Linux で動作します。 - Amazon Linux 2023 ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Amazon Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/amazonlinux/2023/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/amazonlinux/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-rhel-logo.png)​ Red Hat Enterprise Linux Red Hat Enterprise Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの RHEL で動作します。 - Red Hat Enterprise Linux (9) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Red Hat Enterprise Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/rhel/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/rhel/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![6%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-rhel-ibm-logo.png)​ IBM Power の Red Hat Enterprise Linux IBM Power の Red Hat Enterprise Linux サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を Red Hat Enterprise Linux サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/rhel/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/rhel/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-suse-logo.png)​ SUSE Linux Enterprise SUSE Linux Enterprise サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - SUSE Linux Enterprise (SLES 15 SP3) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を SUSE Linux Enterprise サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo rpm --import https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg sudo tee /etc/zypp/repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/suse/$releasever_major/main gpgcheck = 1 gpgkey = https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg repo_gpgcheck = 1 enabled = 1 EOF sudo zypper refresh -f flex-gateway sudo zypper install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![6%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-suse-ibm-logo.png)​ IBM Power の SUSE Linux Enterprise IBM Power の SUSE Linux Enterprise サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンで動作します。 - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を IBM Power の SUSE Linux Enterprise サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo rpm --import https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg sudo tee /etc/zypp/repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/suse/$releasever_major/main gpgcheck = 1 gpgkey = https://flex-packages.anypoint.mulesoft.com/suse/pubkey.gpg repo_gpgcheck = 1 enabled = 1 EOF sudo zypper refresh -f flex-gateway sudo zypper install -y flex-gateway ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-centos-logo.png)​ CentOS CentOS サービスとして Flex Gateway をダウンロードしてインストール ##### ソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの CentOS で動作します。 - CentOS 8 ##### 始める前に 使用を開始する前に、以下の手順でインストールが完了していることを確認してください。 - [gnupg2](https://gnupg.org/) ##### インストールコマンドの実行 Flex Gateway を CentOS サービスとしてダウンロードしてインストールするには、次のアクションを実行するコマンドブロックを実行します。 - 公開キーへの参照を使用した Flex Gateway パッケージリポジトリの追加 - Flex Gateway パッケージのインストール ```ssh sudo tee /etc/yum.repos.d/flex-gateway.repo <<\EOF [flex-gateway] name = Anypoint Flex Gateway baseurl = https://flex-packages.anypoint.mulesoft.com/centos/$releasever/main gpgcheck=1 gpgkey=https://flex-packages.anypoint.mulesoft.com/centos/pubkey.gpg repo_gpgcheck=1 enabled=1 EOF sudo yum install -y flex-gateway ``` CentOS パッケージマネージャーの問題により次のエラーが発生する場合があります。 Error: Failed to download metadata for repo 'AppStream': Cannot prepare internal mirrorlist: No URLs in mirrorlist このエラーが発生した場合、次のコマンドを実行します。 ```ssh sudo sed -i -e "s|mirrorlist=|#mirrorlist=|g" -e "s|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g" /etc/yum.repos.d/CentOS-* ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 ## [](#container)コンテナで使用する Flex Gateway のダウンロード Flex Gateway は、次のコンテナのいずれかにダウンロードしてインストールできます。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-docker-logo.png)​ Docker Docker コンテナで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Docker コンテナでゲートウェイを登録および実行するための準備を整えます。 1. Flex Gateway の Docker イメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 #### ![2%](/mulesoft/current/ja-jp/gateway/1.9/_images/install-podman-logo.png)​ Podman Podman コンテナで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Podman コンテナでゲートウェイを登録および実行するための準備を整えます。 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` ダウンロードしてインストールしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 詳細は、​[「接続モードとローカルモード」](https://docs.mulesoft.com/jp/gateway/1.9/#connected-mode-vs-local-mode)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、Kubernetes クラスターでゲートウェイを登録および実行するための準備を整えます。次のコンテナランタイムを使用できます。 **Docker** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 **Podman** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 ## [](#openshift)OpenShift クラスターで使用する Flex Gateway のダウンロード Flex Gateway コンテナイメージをダウンロードし、OpenShift クラスターでゲートウェイを登録および実行するための準備を整えます。次のコンテナランタイムを使用できます。 **Docker** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh docker pull mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh docker images mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 **Podman** 1. Flex Gateway のコンテナイメージをダウンロードします。 ```ssh podman pull docker.io/mulesoft/flex-gateway:latest ``` 2. ダウンロードが成功したことを確認します。 ```ssh podman images docker.io/mulesoft/flex-gateway ``` 成功した場合、このコマンドでは Flex Gateway コンテナイメージのリストが表示されます。次に例を示します。 ```text REPOSITORY TAG mulesoft/flex-gateway latest ``` イメージをダウンロードしたら、Flex Gateway を​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​または​[ローカルモード](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​で登録します。 ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) # Flex Gateway のトラブルシューティング Anypoint Flex Gateway タスクを実行すると、問題が発生したり、エラーメッセージが表示されたりする場合があります。これらの問題を解決するための情報は、以下のトピックを参照してください。 ## [](#管理-flex-gateway-のトラブルシューティング)管理 Flex Gateway のトラブルシューティング - [管理 Flex Gateway の作成のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-managed-creation) - [管理ゲートウェイの保守のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-managed-maintenance) ## [](#自己管理-flex-gateway-のトラブルシューティング)自己管理 Flex Gateway のトラブルシューティング - [デバッグログを使用した自己管理ゲートウェイのトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-debug-logs) - [登録の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-reg) - [Linux 権限のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-linux-permissions) - [プラットフォーム接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-platform-connection) - [自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging) - [Linux サービスのトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-linux-services) - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-admin-api) - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-requests) - [Docker コマンドの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-docker) - [Helm コマンドの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-helm) # Flex Gateway のトラブルシューティング Anypoint Flex Gateway タスクを実行すると、問題が発生したり、エラーメッセージが表示されたりする場合があります。これらの問題を解決するための情報は、以下のトピックを参照してください。 ## [](#管理-flex-gateway-のトラブルシューティング)管理 Flex Gateway のトラブルシューティング - [管理 Flex Gateway の作成のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-managed-creation) - [管理ゲートウェイの保守のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-managed-maintenance) ## [](#自己管理-flex-gateway-のトラブルシューティング)自己管理 Flex Gateway のトラブルシューティング - [デバッグログを使用した自己管理ゲートウェイのトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-debug-logs) - [登録の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-reg) - [Linux 権限のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-linux-permissions) - [プラットフォーム接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-platform-connection) - [自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging) - [Linux サービスのトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-linux-services) - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-admin-api) - [SOAP API のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-soap-apis) - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-requests) - [Docker コマンドの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-docker) - [Helm コマンドの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-helm) # Flex Gateway のリソースのサイズ Flex Gateway の使用を開始する前に、最適なパフォーマンスと自動スケーリング率が得られるように分析して設定を選択します。 レプリカノードのリソースを割り当てる際には、次のことを検討してください。 - API の数 - ノードに必要なメモリ量 - ノードの処理能力 - 各 API のポリシーの数 - 各ノードで処理するトラフィック量 - ノードが要求に応答するまでに要する時間 (レイテンシー) - ノードが処理するトラフィックの種別と、トラフィック内の次の要素: - ノードが処理する 1 秒あたりの要求数 (RPS) - 各要求のサイズ (バイト) ## [](#リソース)リソース 次の表は、環境に合わせてレプリカノードに対して割り当てる必要があるリソースを示しています。
ノードサイズ CPU RAM

小

1 ～ 2 コア

2 ～ 4GB

中

2 ～ 4 コア

4 ～ 8GB

大

8 ～ 16 コア

16 ～ 32GB
IBM Power10 デプロイメントの場合、「大」ノードでは 5 ～ 16 個の CPU コアを割り当てます。
同じクラスターに属するノードは同じサイズである必要があります。
## [](#クラスターサイズ)クラスターサイズ 次の表は、適切なノードとクラスターサイズを示しています。
ノードサイズ API の数 ポリシーの数 想定されるレイテンシー 想定されるスループット 対象環境

小

< 100

4

< 30 ミリ秒

< 500 RPS

開発/テストクラスター

中

< 500

4

< 20 ミリ秒

< 2500 RPS

本番クラスター

大

> 500

4

< 10 ミリ秒

< 10000 RPS

重要性の高いクラスター
これらのサイズの数字はノードごとです。API 設定はクラスター内のすべてのノードに複製されます。たとえば、10 個の API をそれぞれ 3 個のポリシーを含めてデプロイした場合、10 個の API とそのポリシーがクラスター内の各ノードにデプロイされます。 トラフィックはクラスター内のすべてのノードに分散されます。小のクラスターノードでは 500 RPS までサポートされますが、クラスターに 2 つのノードがある場合は、クラスターで許可されるトラフィックの合計は 1000 RPS です (ノードごとに 500 RPS)。ノードあたりの推奨のトラフィックを超えると、最終的に CPU 使用量が増加することになります。この問題を回避するには、クラスター内のすべてのノードのサイズを増やすか、水平方向にスケールする必要があります。 CPU 使用量が多いと、レイテンシーが大きくなる可能性があります。このような場合は、水平スケーリングを続行するか、ノードサイズを増やしてください。 メモリ消費量が多いと、メモリ不足エラーが発生する場合があります。この問題を解決するには、メモリ割り当てまたはノードサイズを増やしてください。この状況では、水平スケーリングで問題を解決できないことがあります。まずメモリを増やして、後から水平方向にスケールする必要があります。 これらのガイドラインは、平均要求サイズが 1 KB で 4 つのポリシーが実装されているクラスターを対象としています。ユースケースに合わせてパラメーターを調整してください。 最も一般的に使用される標準ポリシーは次のとおりです。 - メッセージログ - レート制限 - JWT 検証 - ヘッダーの挿入 TLS の使用は、応答時間やプロセスの消費に影響します。 # Flex Gateway の使用開始 Flex Gateway では、Anypoint Flex Gateway をすばやく使い始めるために次のガイドが提供されています。チュートリアルでは、Flex Gateway をデプロイし、基本認証ポリシーで保護されたシンプルな API をパブリッシュする方法について説明します。目的の Flex Gateway デプロイメント種別のガイドを参照してください。 - [CloudHub 2.0 での管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-managed-getting-started) - Anypoint Platform がホストされた管理 Flex Gateway を CloudHub 2.0 にデプロイします。 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - 自己管理 Flex Gateway をローカルインフラストラクチャの Docker コンテナにデプロイします。 - [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started) - 自己管理 Flex Gateway をローカルインフラストラクチャの Kubernetes ポッドにデプロイします。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) # Flex Gateway の使用開始 このチュートリアルの目標は、Anypoint Flex Gateway をすばやく使い始めることです。このチュートリアルでは、Docker を使用して、接続モードで Flex Gateway をインストール、登録、実行する方法について説明します。さらに、基本認証ポリシーで保護された API をパブリッシュする方法についても説明します。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、次の準備が整っていることを確認します。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。まだ Anypoint Platform 組織を持っていない場合は、Anypoint Platform で [トライアル組織を作成](https://anypoint.mulesoft.com/login/signup)​してください。 - x86 プロセッサーを搭載した Linux マシン。M1 および M2 プロセッサーはサポートされていません。 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) - Docker のインストール。例については [「Docker Desktop」](https://www.docker.com/products/docker-desktop/)​を参照してください。 ## [](#flex-gateway-のダウンロード)Flex Gateway のダウンロード Flex Gateway Docker イメージをダウンロードするには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh docker pull mulesoft/flex-gateway:1.8.0 ```
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
## [](#flex-gateway-を登録する)Flex Gateway を登録する 1. 次のコマンドを実行して、新しいディレクトリを作成します。 ```ssh mkdir flex-registration ``` 2. 次のコマンドを実行して、新しいディレクトリに移動します。 ```ssh cd flex-registration ``` 3. Anypoint ユーザー名とパスワードを使用して、 [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインします。 4. **\[Runtime Manager\]**​ を選択します。 5. サイドナビゲーションパネルで,**\[Flex Gateways\]**​ タブをクリックします。 6. **\[Add Gateway (ゲートウェイを追加)\]**​ をクリックします。 7. **\[Docker\]**​ を選択します。 8. **\[Register your gateway (ゲートウェイを登録)\]**​ セクションのコードブロックをコピーします。コードブロックには、一意の組織 ID とトークンが含まれています。 次の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページのスクリーンショットでは、コピーするコードブロックが強調表示されています。 ![コピーするコードブロックが選択されている \[Add a Flex Gateway (Flex Gateway の追加)\] ページ](_images/gateway-quickstart-add-gateway.png) 9. コピーしたコードブロックをターミナルウィンドウで実行します。最初に ​``​ を ​`my-gw`​ などの名前に置き換えてください。
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
10. Runtime Manager のサイドバーナビゲーションで ​**\[Flex Gateways\]**​ を選択します。 登録した Flex Gateway がゲートウェイのリストに表示されます。 ## [](#flex-gateway-を実行する)Flex Gateway を実行する Flex Gateway を実行するには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8081:8081 \ mulesoft/flex-gateway ```
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
新しい Flex Gateway インスタンスがターミナルウィンドウで実行されます。
Flex Gateway インスタンスは、プロセスが停止されるかウィンドウが閉じられるまで、ターミナルウィンドウで実行を続けます。
## [](#シンプルな-api-のパブリッシュ)シンプルな API のパブリッシュ 1. Anypoint Platform メニューから ​**\[API Manager\]**​ を選択します。 2. **\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします: ![\[Add new API (新しい API を追加)\] が選択されている \[Add API (API を追加)\] ページ](_images/gateway-quickstart-add-new-api.png) 3. **\[Add API (API を追加)\]**​ ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 4. **\[Select a gateway (ゲートウェイを選択)\]**​ セクションで登録済みゲートウェイを選択します。 5. **\[Next (次へ)\]**​ をクリックします。 次の ​**\[Add API (API を追加)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![Flex Gateway ランタイムと my-gw ゲートウェイが選択されている \[Add API (API を追加)\]](_images/gateway-quickstart-select-gateway-for-api.png) 6. **\[Create New API (新しい API を作成)\]**​ をクリックします。 7. API 参照名を指定し、アセットタイプとして ​**\[HTTP API\]**​ を選択します。 8. **\[次へ\]**​ をクリックします。 9. **\[Endpoint (エンドポイント)\]**​ ページから、​**\[Implementation URI (実装 URI)\]**​ 項目に次の URI を入力します。 ```none https://jsonplaceholder.typicode.com/ ``` 10. **\[Port (ポート)\]**​ 項目に「​`8081`​」と入力します。 11. **\[次へ\]**​ をクリックします。 12. **\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 ゲートウェイインスタンスの Docker コンテナ内で、ポート ​`8081`​ の ​`localhost`​ に対して行われたすべての HTTP 要求が ​`jsonplaceholder`​ サービスにプロキシされるようになります。 13. API インスタンスをテストするには、新しいターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#基本認証ポリシーを使用して-api-を保護する)基本認証ポリシーを使用して API を保護する 1. **API Manager**​ を開いたまま、サイドナビゲーションパネルから ​**\[API Administration (API 管理)\]**​ を選択します。 2. 前のセクションで作成した API の名前を選択します。 3. サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 4. **\[Policies (ポリシー)\]**​ ページで、​**\[Add policy (ポリシーを追加)\]**​ をクリックします。 次の ​**\[Policies (ポリシー)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![\[Add policy (ポリシーを追加)\] ボタンのある \[Add policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-add-policy.png) 5. **\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ ポリシーを選択します。 6. **\[Next (次へ)\]**​ をクリックします。 7. **\[User Name (ユーザー名)\]**​ に「​`user`​」と入力します。 8. **\[User Password (ユーザーパスワード)\]**​ に「​`password`​」と入力します。 9. **\[Apply (適用)\]**​ をクリックします。 次の ​**\[Basic Authentication - Simple policy (基本認証 - 簡易ポリシー)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![\[User Password (ユーザーパスワード)\] 項目が選択されている \[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] ページ](_images/gateway-quickstart-config-basic-auth.png) 10. 認証を​_使用しないで_​ API インスタンスをテストするには、ターミナルウィンドウで次の ​`curl`​ コマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' ``` 要求には認証コンテキストが含まれていないため、コマンドは結果として ​`401 (Unauthorized)`​ 状況コードを出力します。 11. 認証を​_使用して_​ API インスタンスをテストするには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' -u user:password ```
user​ パラメーターと ​password​ パラメーターは、​API Manager​ 経由でポリシーを適用したときに指定した内容と一致する必要があります。
このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.8/flex-review-prerequisites) - [Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) # Flex Gateway の使用開始 Flex Gateway では、Anypoint Flex Gateway をすばやく使い始めるために次のガイドが提供されています。チュートリアルでは、Flex Gateway をデプロイし、基本認証ポリシーで保護されたシンプルな API をパブリッシュする方法について説明します。目的の Flex Gateway デプロイメント種別のガイドを参照してください。 - [CloudHub 2.0 での管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-managed-getting-started) - Anypoint Platform がホストされた管理 Flex Gateway を CloudHub 2.0 にデプロイします。 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - 自己管理 Flex Gateway をローカルインフラストラクチャの Docker コンテナにデプロイします。 - [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started) - 自己管理 Flex Gateway をローカルインフラストラクチャの Kubernetes ポッドにデプロイします。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) # Flex Gateway の概要 Anypoint Flex Gateway は、実行されている場所を問わずに API を管理して保護するように設計された、Envoy ベースの超高速かつ軽量の API ゲートウェイです。DevOps や CI/CD のワークフローとシームレスに統合できる Flex Gateway は、要求量の多いアプリケーションやマイクロサービスで求められるパフォーマンスを保証しつつ、あらゆる環境でエンタープライズセキュリティと容易な管理を実現します。 次の動画では、Flex Gateway の概要を紹介しています。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::\_partials/product-spotlight-video.html\[\] ## [](#flex-gateway-アーキテクチャ)Flex Gateway アーキテクチャ Flex Gateway は、連動して機能する次の 2 つのコンポーネントで構成されます。 - [コントロールプレーン](#control_plane) - [ランタイム](#runtime) 次の図は、これらのコンポーネント間のリレーションを示しています。 ![API のデプロイメントと管理を示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-concepts-control-plane-diagram.png) ### [](#control_plane)コントロールプレーン コントロールプレーンは、管理とオブザーバビリティを一元化する MuleSoft でホストされたプラットフォームであり、次の操作を実行できます。 - API をビルドする。 - ポリシーを追加する。 - API をランタイムにデプロイする。 - Anypoint API Manager で API を監視する。 - Anypoint Runtime Manager でランタイムを設定する。 ### [](#runtime)ランタイム ゲートウェイランタイムはコントロールプレーンからコマンドを受け取り、バックエンド API を転送して保護します。セキュリティを念頭に置いて構築された Flex Gateway は、mTLS と HTTPs を介してランタイムとコントロールプレーン間の通信を保護します。 ## [](#スケーリング)スケーリング 1 つの Flex Gateway で最大 1,000 個のバックエンド API をサポートできます。高可用性のために、並列で実行されている複数のゲートウェイをデプロイすることをお勧めします。複数のゲートウェイをデプロイすると、ゲートウェイのパフォーマンスと堅牢性が向上するため、拡張が必要な高パフォーマンスアプリケーションにお勧めします。 ## [](#api-インスタンス)API インスタンス Flex Gateway は、HTTP、SOAP、および OAS3 REST API インスタンスをサポートしています。 ## [](#デプロイメント種別)デプロイメント種別 管理または自己管理 Flex Gateway として Flex Gateway をデプロイできます。CloudHub 2.0 の管理 Flex Gateway では管理オプションが完全に提供され、自己管理 Flex Gateway ではオプションが増え、制御が強化されます。 - [管理 Flex Gateway](#managed) - [自己管理 Flex Gateway](#self_managed) ### [](#managed)管理 Flex Gateway 管理 Flex Gateway は CloudHub 2.0 の Flex Gateway の完全にホストされたバージョンであり、MuleSoft によって Anypoint Platform でホストされ、管理されます。管理 Flex Gateway では、高可用性、自動スケーリング、運用オーバーヘッドの低減、定期的な自動パッチおよびアップグレードが提供されます。ポイント & クリックでの設定や監視を通じて API ゲートウェイの運用を簡素化するように設計されており、MuleSoft が保守やインフラストラクチャを担います。 管理 Flex Gateway では、各ランタイムユニットはゲートウェイインスタンスと呼ばれます。 ### [](#self_managed)自己管理 Flex Gateway 自己管理 Flex Gateway は分散型ランタイムエンティティで、クラウドデータセンターにインストールできるほか、テスト目的でローカルのラップトップにインストールできます。自己管理 Flex Gateway では、基盤となるインフラストラクチャを自分で管理する必要があります。自己管理 Flex Gateway では、Docker コンテナのバックエンドアプリケーションに対するサイドカーとして、Kubernetes デプロイメントとして、またはさまざまな Linux 環境で、Docker コンテナなどのさまざまなインストールオプションが使用できます。 自己管理 Flex Gateway では、各ランタイムユニットはレプリカと呼ばれます。高可用性のために、自己管理 Flex Gateway をクラスターとしてデプロイして複数のレプリカを並列で実行することをお勧めします。クラスターを使用すると、ゲートウェイのパフォーマンスと堅牢性が向上するため、拡張が必要な高パフォーマンスアプリケーションにお勧めします。 自己管理 Flex Gateway に含まれる Fluent Bit の実装により、ローカルファイル、または New Relic、Sumo Logic、Splunk などのアグリゲーターへのログ出力が可能になります。分散レート制限やキャッシュで使用するために外部 REDIS ストレージを設定することもできます。ゲートウェイのレプリカではこのストレージをレート制限調整のための一時的なワークスペースとして活用しており、顧客のサービスレベル契約を遵守するうえできわめて重要です。 自己管理 Flex Gateway は次の 2 つの方法のいずれかでインストールできます。 - [接続モードの自己管理 Flex Gateway](#connected_mode) - [ローカルモードの自己管理 Flex Gateway](#local_mode) ### [](#connected_mode)接続モードの自己管理 Flex Gateway 接続モードでは、ゲートウェイは MuleSoft コントロールプレーンに完全に接続されます。この接続により、一元管理、オブザーバビリティ、セキュリティが可能になります。Anypoint API Manager を使用すると、完全な API ライフサイクル管理とポリシー設定が可能になります。Anypoint Runtime Manager を使用すると、ゲートウェイをデプロイして設定できます。 UI ベースの環境でポリシーをデプロイし、ゲートウェイを管理および監視するには、接続モードを選択します。 ### [](#local_mode)ローカルモードの自己管理 Flex Gateway コントロールプレーンからほとんど接続されていないスタンドアロンゲートウェイを設定して管理することもできます。この環境では、ローカルモードを選択します。
ローカルモードでデプロイされた Flex Gateway は、登録および使用量メトリクスの記録のためにのみコントロールプレーンに接続します。
ローカルモードでは、ローカルに保存された宣言型設定ファイルを使用して、すべての設定およびポリシーアプリケーションを管理します。 ローカルモードを使用して、アプリケーションデプロイメント用の CI/CD パイプラインを構築します。 ### [](#相違点の概要)相違点の概要 次の表に、接続モードとローカルモードの相違点の概要を示します。
接続モード ローカルモード

ユースケース

管理、オブザーバビリティ、セキュリティを一元化する。Flex Gateway はコントロールプレーンに接続します。

ほとんど接続されていない方法で、コントロールプレーンとは独立して運用する。ローカルに保存された宣言型設定ファイルを使用して管理します。CI/CD パイプラインを構築します。

ポリシーの適用

API Manager 経由

ローカルの宣言型設定ファイル経由

エアギャップされるか?

いいえ。 Flex Gateway はコントロールプレーンに接続されます。

いいえ。 Flex Gateway はローカルで管理されますが、登録および使用量メトリクスのためにのみコントロールプレーンに接続されます。
## [](#installation-options)デプロイメントとインストールのオプション ### [](#管理デプロイメントオプション)管理デプロイメントオプション CloudHub 2.0 の管理 Flex Gateway は Runtime Manager を使用してデプロイできます。詳細は、[CloudHub 2.0 への管理 Flex Gateway のデプロイ](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-managed-set-up)を参照してください。 ### [](#自己管理インストールオプション)自己管理インストールオプション 自己管理 Flex Gateway はさまざまな方法でインストールできます。 - Salesforce から Heroku にデプロイされた Docker コンテナ内のスタンドアロンランタイム 詳細は、 [「Mastering API Integration: Salesforce, Heroku, and MuleSoft Anypoint Flex Gateway (API インテグレーションの習得: Salesforce、Heroku、MuleSoft Anypoint Flex Gateway)」](https://blog.heroku.com/mastering-api-integration-salesforce-heroku-mulesoft-anypoint-flex-gateway)​を参照してください。 - Docker コンテナ内のスタンドアロンランタイム - Docker コンテナ内のバックエンドアプリケーションへのサイドカー (これにより単一バックエンドアプリケーションを保護) - 高可用性、高パフォーマンスのユースケース向けの Kubernetes ​`デプロイメント` - 高可用性、高パフォーマンスのユースケース向けの IBM Power の OpenShift ​`デプロイメント` - 次のようなさまざまな Linux 環境上のスタンドアロンの単一ランタイムまたはレプリカ。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy スタンドアロンゲートウェイはトランザクション量が低い限られた数の API を保護するのに適しています。ただし、他のシナリオや、高可用性や信頼性が重要な場合は、Kubernetes のイングレスコントローラーを使用することを検討してください。 ## [](#バージョン廃止日)バージョン廃止日 Flex Gateway バージョン廃止日についての詳細は、 [「MuleSoft Product Versioning and Back Support Policy (MuleSoft 製品のバージョン設定ポリシーとサポートポリシー)」](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf)​を参照してください。 ## [](#共有責任)共有責任 Flex Gateway が正常に動作するための責任は、お客様と MuleSoft との間で共有されます。 ### [](#mulesoft-の責任)MuleSoft の責任 MuleSoft は以下の責任を負います。 - Flex Gateway (エージェント、Envoy パッケージ、Fluent Bit パッケージを含む) の提供とサポート - Kubernetes クラスターへの Flex Gateway のインストールに必要なベース Helm チャートの提供とサポート。 - オンライン Docker イメージレジストリの提供とサポート - Linux のインストールに必要なオンラインパッケージリポジトリの提供とサポート ### [](#お客様の責任)お客様の責任 動作環境を問わず、お客様は以下の責任を負います。 - Anypoint コントロールプレーンとの接続の維持 - 通常の Flex Gateway 動作に干渉するサードパーティソフトウェア (ウイルス対策ソフトウェア、DPI、アプリケーションセキュリティシステムなど) を実行しないこと。 Kubernetes での動作時には、お客様は以下の責任を負います。 - 特定のニーズへのベース Helm チャートの適合 - Kubernetes ​`デプロイメント`​の管理。例: - 内部負荷分散 - `イングレス`​リソースに対するカスタマイズ - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - コンテナランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。以下が必要です。 - お客様の IT チームによるインフラストラクチャのプロビジョニングと管理 - お客様のネットワークチームによる許可ポートとプロキシの設定 - お客様のセキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 毎月の Flex Gateway の使用状況についての詳細は、​[「使用状況レポートの表示」](https://docs.mulesoft.com/jp/general/usage-reports)​を参照してください。 ## [](#次のステップ)次のステップ - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) # Flex Gateway の概要 Anypoint Flex Gateway は、実行されている場所を問わずに API を管理して保護するように設計された、Envoy ベースの超高速かつ軽量の API ゲートウェイです。DevOps や CI/CD のワークフローとシームレスに統合できる Flex Gateway は、要求量の多いアプリケーションやマイクロサービスで求められるパフォーマンスを保証しつつ、あらゆる環境でエンタープライズセキュリティと容易な管理を実現します。 次の動画では、Flex Gateway の概要を紹介しています。 ![](https://play.vidyard.com/3LncCho6hfvbLMKbg1AM28.jpg) ## [](#flex-gateway-アーキテクチャ)Flex Gateway アーキテクチャ Flex Gateway は、連動して機能する次の 2 つのコンポーネントで構成されます。 - [コントロールプレーン](#control_plane) - [ランタイム](#runtime) 次の図は、これらのコンポーネント間のリレーションを示しています。 ![Flex Gateway の概念図,](/mulesoft/current/ja-jp/gateway/1.8/_images/gateway-concepts-control-plane-diagram.png) ### [](#control_plane)コントロールプレーン コントロールプレーンは、管理とオブザーバビリティを一元化する MuleSoft でホストされたプラットフォームであり、次の操作を実行できます。 - API をビルドする。 - ポリシーを追加する。 - API をランタイムにデプロイする。 - Anypoint API Manager で API を監視する。 - Anypoint Runtime Manager でランタイムを設定する。 ### [](#runtime)ランタイム ゲートウェイランタイムは、顧客がホストする分散型エンティティで、クラウドデータセンターにインストールされるか、テスト目的でローカルのラップトップにインストールされます。ランタイムはコントロールプレーンからコマンドを受け取り、バックエンド API を転送して保護します。セキュリティを念頭に置いて構築された Flex Gateway は、mTLS と HTTPs を介してランタイムとコントロールプレーン間の通信を保護します。 Fluent Bit の実装により、ローカルファイル、または New Relic、Sumo Logic、Splunk などのアグリゲーターへのログ出力が可能になります。 ## [](#レプリカ)レプリカ ランタイム単位は​`レプリカ`​と呼ばれます。高可用性のために 1 つのランタイムで 600 バックエンド API をサポートできますが、Flex Gateway をクラスターとしてデプロイして複数のレプリカを並列で実行することをお勧めします。クラスターを使用すると、ゲートウェイのパフォーマンスと堅牢性が向上するため、拡張が必要な高パフォーマンスアプリケーションにお勧めします。 1 つの Flex Gateway で複数のバックエンド API をサポートできます。より多くのバックエンド API をサポートするには、複数のレプリカまたは追加の Flex Gateway をデプロイすることができます。レプリカの CPU とメモリを増加すると、スループットとパフォーマンスが向上します。 省略可能な外部 REDIS ストレージを設定して、分散レート制限や分散キャッシュなどの機能を使用できます。ゲートウェイのレプリカは、REDIS ストレージをスクラッチパッドとして使用して複数のレプリカ間でレート制限を調整するため、顧客の SLA が遵守されます。 ## [](#api-インスタンス)API インスタンス Flex Gateway は、HTTP および REST API インスタンスをサポートしています。 Flex Gateway では SOAP API がネイティブではサポートされず、XML のスキーマ検証が一切提供されません。ただし、HTTP API インスタンスをパブリッシュして HTTP プロトコルを使用する API を保護することはできます。 SOAP API をパブリッシュするには、[SOAP API のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-soap-apis)を参照してください。 ## [](#接続モードとローカルモード)接続モードとローカルモード Flex Gateway は次の 2 つの方法でデプロイできます。 - [接続モード](#connected_mode) - [ローカルモード](#local_mode) ### [](#connected_mode)接続モード 接続モードでは、ゲートウェイは MuleSoft コントロールプレーンに完全に接続されます。この接続により、一元管理、オブザーバビリティ、セキュリティが可能になります。Anypoint API Manager を使用すると、完全な API ライフサイクル管理とポリシー設定が可能になります。Anypoint Runtime Manager を使用すると、ゲートウェイをデプロイして設定できます。 UI ベースの環境でポリシーをデプロイし、ゲートウェイを管理および監視するには、接続モードを選択します。 ### [](#local_mode)ローカルモード コントロールプレーンからほとんど接続されていないスタンドアロンゲートウェイを設定して管理することもできます。この環境では、ローカルモードを選択します。
ローカルモードでデプロイされた Flex Gateway は、登録および使用量メトリクスの記録のためにのみコントロールプレーンに接続します。
ローカルモードでは、ローカルに保存された宣言型設定ファイルを使用して、すべての設定およびポリシーアプリケーションを管理します。 ローカルモードを使用して、アプリケーションデプロイメント用の CI/CD パイプラインを構築します。 ### [](#相違点の概要)相違点の概要 次の表に、接続モードとローカルモードの相違点の概要を示します。
接続モード ローカルモード

ユースケース

管理、オブザーバビリティ、セキュリティを一元化する。Flex Gateway はコントロールプレーンに接続します。

ほとんど接続されていない方法で、コントロールプレーンとは独立して運用する。ローカルに保存された宣言型設定ファイルを使用して管理します。CI/CD パイプラインを構築します。

ポリシーの適用

API Manager 経由

ローカルの宣言型設定ファイル経由

エアギャップされるか?

いいえ。 Flex Gateway はコントロールプレーンに接続されます。

いいえ。 Flex Gateway はローカルで管理されますが、登録および使用量メトリクスのためにのみコントロールプレーンに接続されます。
## [](#インストールオプション)インストールオプション Flex Gateway はさまざまな方法でインストールできます。 - Salesforce から Heroku にデプロイされた Docker コンテナ内のスタンドアロンランタイム 詳細は、 [「Mastering API Integration: Salesforce, Heroku, and MuleSoft Anypoint Flex Gateway (API インテグレーションの習得: Salesforce、Heroku、MuleSoft Anypoint Flex Gateway)」](https://blog.heroku.com/mastering-api-integration-salesforce-heroku-mulesoft-anypoint-flex-gateway)​を参照してください。 - Docker コンテナ内のスタンドアロンランタイム - Docker コンテナ内のバックエンドアプリケーションへのサイドカー (これにより単一バックエンドアプリケーションを保護) - 高可用性、高パフォーマンスのユースケース向けの Kubernetes ​`デプロイメント` - 高可用性、高パフォーマンスのユースケース向けの IBM Power の OpenShift ​`デプロイメント` - 次のようなさまざまな Linux 環境上のスタンドアロンの単一ランタイムまたはレプリカ。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) 少数の API を保護し、トランザクション数が少なく、高可用性や堅牢性への影響が最小限に抑えられる場合は、スタンドアロンゲートウェイを使用します。それ以外の場合は、Kubernetes の Ingress コントローラーを使用します。 ## [](#バージョン廃止日)バージョン廃止日 Flex Gateway バージョン廃止日についての詳細は、 [「MuleSoft Product Feature Retirements (MuleSoft 製品機能の要件)」](https://help.mulesoft.com/s/article/MuleSoft-Product-Feature-Retirements)​を参照してください。 ## [](#共有責任)共有責任 Flex Gateway が正常に動作するための責任は、お客様と MuleSoft との間で共有されます。 ### [](#mulesoft-の責任)MuleSoft の責任 MuleSoft は以下の責任を負います。 - Flex Gateway (エージェント、Envoy パッケージ、Fluent Bit パッケージを含む) の提供とサポート - Kubernetes クラスターへの Flex Gateway のインストールに必要なベース Helm チャートの提供とサポート。 - オンライン Docker イメージレジストリの提供とサポート - Linux のインストールに必要なオンラインパッケージリポジトリの提供とサポート ### [](#お客様の責任)お客様の責任 動作環境を問わず、お客様は以下の責任を負います。 - Anypoint コントロールプレーンとの接続の維持 - 通常の Flex Gateway 動作に干渉するサードパーティソフトウェア (ウイルス対策ソフトウェア、DPI、アプリケーションセキュリティシステムなど) を実行しないこと。 Kubernetes での動作時には、お客様は以下の責任を負います。 - 特定のニーズへのベース Helm チャートの適合 - Kubernetes ​`デプロイメント`​の管理。例: - 内部負荷分散 - `イングレス`​リソースに対するカスタマイズ - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - コンテナランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。以下が必要です。 - お客様の IT チームによるインフラストラクチャのプロビジョニングと管理 - お客様のネットワークチームによる許可ポートとプロキシの設定 - お客様のセキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 毎月の Flex Gateway の使用状況についての詳細は、​[「使用状況レポートの表示」](https://docs.mulesoft.com/jp/general/usage-reports)​を参照してください。 ## [](#次のステップ)次のステップ - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway の概要 Anypoint Flex Gateway は、実行されている場所を問わずに API を管理して保護するように設計された、Envoy ベースの超高速かつ軽量の API ゲートウェイです。DevOps や CI/CD のワークフローとシームレスに統合できる Flex Gateway は、要求量の多いアプリケーションやマイクロサービスで求められるパフォーマンスを保証しつつ、あらゆる環境でエンタープライズセキュリティと容易な管理を実現します。 次の動画では、Flex Gateway の概要を紹介しています。 Unresolved include directive in modules/ROOT/pages/index.adoc - include::\_partials/product-spotlight-video.html\[\] ## [](#flex-gateway-アーキテクチャ)Flex Gateway アーキテクチャ Flex Gateway は、連動して機能する次の 2 つのコンポーネントで構成されます。 - [コントロールプレーン](#control_plane) - [ランタイム](#runtime) 次の図は、これらのコンポーネント間のリレーションを示しています。 ![API のデプロイメントと管理を示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-concepts-control-plane-diagram.png) ### [](#control_plane)コントロールプレーン コントロールプレーンは、管理とオブザーバビリティを一元化する MuleSoft でホストされたプラットフォームであり、次の操作を実行できます。 - API をビルドする。 - ポリシーを追加する。 - API をランタイムにデプロイする。 - Anypoint API Manager で API を監視する。 - Anypoint Runtime Manager でランタイムを設定する。 ### [](#runtime)ランタイム ゲートウェイランタイムはコントロールプレーンからコマンドを受け取り、バックエンド API を転送して保護します。セキュリティを念頭に置いて構築された Flex Gateway は、mTLS と HTTPs を介してランタイムとコントロールプレーン間の通信を保護します。 ## [](#スケーリング)スケーリング 1 つの Flex Gateway で最大 1,000 個のバックエンド API をサポートできます。高可用性のために、並列で実行されている複数のゲートウェイをデプロイすることをお勧めします。複数のゲートウェイをデプロイすると、ゲートウェイのパフォーマンスと堅牢性が向上するため、拡張が必要な高パフォーマンスアプリケーションにお勧めします。 ## [](#api-インスタンス)API インスタンス Flex Gateway は、HTTP および REST API インスタンスをサポートしています。 Flex Gateway では SOAP API がネイティブではサポートされず、XML のスキーマ検証が一切提供されません。ただし、HTTP API インスタンスをパブリッシュして HTTP プロトコルを使用する API を保護することはできます。 SOAP API をパブリッシュするには、[SOAP API のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-soap-apis)を参照してください。 ## [](#デプロイメント種別)デプロイメント種別 管理または自己管理 Flex Gateway として Flex Gateway をデプロイできます。CloudHub 2.0 の管理 Flex Gateway では管理オプションが完全に提供され、自己管理 Flex Gateway ではオプションが増え、制御が強化されます。 - [管理 Flex Gateway](#managed) - [自己管理 Flex Gateway](#self_managed) ### [](#managed)管理 Flex Gateway 管理 Flex Gateway は CloudHub 2.0 の Flex Gateway の完全にホストされたバージョンであり、MuleSoft によって Anypoint Platform でホストされ、管理されます。管理 Flex Gateway では、高可用性、自動スケーリング、運用オーバーヘッドの低減、定期的な自動パッチおよびアップグレードが提供されます。ポイント & クリックでの設定や監視を通じて API ゲートウェイの運用を簡素化するように設計されており、MuleSoft が保守やインフラストラクチャを担います。 管理 Flex Gateway では、各ランタイムユニットはゲートウェイインスタンスと呼ばれます。 ### [](#self_managed)自己管理 Flex Gateway 自己管理 Flex Gateway は分散型ランタイムエンティティで、クラウドデータセンターにインストールできるほか、テスト目的でローカルのラップトップにインストールできます。自己管理 Flex Gateway では、基盤となるインフラストラクチャを自分で管理する必要があります。自己管理 Flex Gateway では、Docker コンテナのバックエンドアプリケーションに対するサイドカーとして、Kubernetes デプロイメントとして、またはさまざまな Linux 環境で、Docker コンテナなどのさまざまなインストールオプションが使用できます。 自己管理 Flex Gateway では、各ランタイムユニットはレプリカと呼ばれます。高可用性のために、自己管理 Flex Gateway をクラスターとしてデプロイして複数のレプリカを並列で実行することをお勧めします。クラスターを使用すると、ゲートウェイのパフォーマンスと堅牢性が向上するため、拡張が必要な高パフォーマンスアプリケーションにお勧めします。 自己管理 Flex Gateway に含まれる Fluent Bit の実装により、ローカルファイル、または New Relic、Sumo Logic、Splunk などのアグリゲーターへのログ出力が可能になります。分散レート制限やキャッシュで使用するために外部 REDIS ストレージを設定することもできます。ゲートウェイのレプリカではこのストレージをレート制限調整のための一時的なワークスペースとして活用しており、顧客のサービスレベル契約を遵守するうえできわめて重要です。 自己管理 Flex Gateway は次の 2 つの方法のいずれかでインストールできます。 - [接続モードの自己管理 Flex Gateway](#connected_mode) - [ローカルモードの自己管理 Flex Gateway](#local_mode) ### [](#connected_mode)接続モードの自己管理 Flex Gateway 接続モードでは、ゲートウェイは MuleSoft コントロールプレーンに完全に接続されます。この接続により、一元管理、オブザーバビリティ、セキュリティが可能になります。Anypoint API Manager を使用すると、完全な API ライフサイクル管理とポリシー設定が可能になります。Anypoint Runtime Manager を使用すると、ゲートウェイをデプロイして設定できます。 UI ベースの環境でポリシーをデプロイし、ゲートウェイを管理および監視するには、接続モードを選択します。 ### [](#local_mode)ローカルモードの自己管理 Flex Gateway コントロールプレーンからほとんど接続されていないスタンドアロンゲートウェイを設定して管理することもできます。この環境では、ローカルモードを選択します。
ローカルモードでデプロイされた Flex Gateway は、登録および使用量メトリクスの記録のためにのみコントロールプレーンに接続します。
ローカルモードでは、ローカルに保存された宣言型設定ファイルを使用して、すべての設定およびポリシーアプリケーションを管理します。 ローカルモードを使用して、アプリケーションデプロイメント用の CI/CD パイプラインを構築します。 ### [](#相違点の概要)相違点の概要 次の表に、接続モードとローカルモードの相違点の概要を示します。
接続モード ローカルモード

ユースケース

管理、オブザーバビリティ、セキュリティを一元化する。Flex Gateway はコントロールプレーンに接続します。

ほとんど接続されていない方法で、コントロールプレーンとは独立して運用する。ローカルに保存された宣言型設定ファイルを使用して管理します。CI/CD パイプラインを構築します。

ポリシーの適用

API Manager 経由

ローカルの宣言型設定ファイル経由

エアギャップされるか?

いいえ。 Flex Gateway はコントロールプレーンに接続されます。

いいえ。 Flex Gateway はローカルで管理されますが、登録および使用量メトリクスのためにのみコントロールプレーンに接続されます。
## [](#installation-options)デプロイメントとインストールのオプション ### [](#管理デプロイメントオプション)管理デプロイメントオプション CloudHub 2.0 の管理 Flex Gateway は Runtime Manager を使用してデプロイできます。詳細は、[CloudHub 2.0 への管理 Flex Gateway のデプロイ](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-managed-set-up)を参照してください。 ### [](#自己管理インストールオプション)自己管理インストールオプション 自己管理 Flex Gateway はさまざまな方法でインストールできます。 - Salesforce から Heroku にデプロイされた Docker コンテナ内のスタンドアロンランタイム 詳細は、 [「Mastering API Integration: Salesforce, Heroku, and MuleSoft Anypoint Flex Gateway (API インテグレーションの習得: Salesforce、Heroku、MuleSoft Anypoint Flex Gateway)」](https://blog.heroku.com/mastering-api-integration-salesforce-heroku-mulesoft-anypoint-flex-gateway)​を参照してください。 - Docker コンテナ内のスタンドアロンランタイム - Docker コンテナ内のバックエンドアプリケーションへのサイドカー (これにより単一バックエンドアプリケーションを保護) - 高可用性、高パフォーマンスのユースケース向けの Kubernetes ​`デプロイメント` - 高可用性、高パフォーマンスのユースケース向けの IBM Power の OpenShift ​`デプロイメント` - 次のようなさまざまな Linux 環境上のスタンドアロンの単一ランタイムまたはレプリカ。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) スタンドアロンゲートウェイはトランザクション量が低い限られた数の API を保護するのに適しています。ただし、他のシナリオや、高可用性や信頼性が重要な場合は、Kubernetes のイングレスコントローラーを使用することを検討してください。 ## [](#バージョン廃止日)バージョン廃止日 Flex Gateway バージョン廃止日についての詳細は、 [「MuleSoft Product Versioning and Back Support Policy (MuleSoft 製品のバージョン設定ポリシーとサポートポリシー)」](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf)​を参照してください。 ## [](#共有責任)共有責任 Flex Gateway が正常に動作するための責任は、お客様と MuleSoft との間で共有されます。 ### [](#mulesoft-の責任)MuleSoft の責任 MuleSoft は以下の責任を負います。 - Flex Gateway (エージェント、Envoy パッケージ、Fluent Bit パッケージを含む) の提供とサポート - Kubernetes クラスターへの Flex Gateway のインストールに必要なベース Helm チャートの提供とサポート。 - オンライン Docker イメージレジストリの提供とサポート - Linux のインストールに必要なオンラインパッケージリポジトリの提供とサポート ### [](#お客様の責任)お客様の責任 動作環境を問わず、お客様は以下の責任を負います。 - Anypoint コントロールプレーンとの接続の維持 - 通常の Flex Gateway 動作に干渉するサードパーティソフトウェア (ウイルス対策ソフトウェア、DPI、アプリケーションセキュリティシステムなど) を実行しないこと。 Kubernetes での動作時には、お客様は以下の責任を負います。 - 特定のニーズへのベース Helm チャートの適合 - Kubernetes ​`デプロイメント`​の管理。例: - 内部負荷分散 - `イングレス`​リソースに対するカスタマイズ - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - コンテナランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。以下が必要です。 - お客様の IT チームによるインフラストラクチャのプロビジョニングと管理 - お客様のネットワークチームによる許可ポートとプロキシの設定 - お客様のセキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 毎月の Flex Gateway の使用状況についての詳細は、​[「使用状況レポートの表示」](https://docs.mulesoft.com/jp/general/usage-reports)​を参照してください。 ## [](#次のステップ)次のステップ - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) # Flex Gateway の登録の更新 Anypoint Flex Gateway では、管理された PKI 証明書を使用して Anypoint Platform と通信します。この証明書は、Flex Gateway を接続モードまたはローカルモードで登録すると生成されます。証明書を更新すると、確実にアプリケーションを運用し続けることができます。 証明書の更新は、​`flexctl registration renew`​ コマンドを使用して登録を更新することで行います。 - `renew`​ コマンドにより、Runtime Manager を使用して既存の Flex Gateway 登録が更新されます。 - 認証では、ユーザー証明書または接続アプリケーションのログイン情報を使用して ​`renew`​ コマンドを実行します。ユーザーログイン情報を使用した認証には、​`--username`​ フラグと ​`--password`​ フラグが必要です。接続アプリケーションのログイン情報を使用した認証には、​`--client-id`​ フラグと ​`--client-secret`​ フラグが必要です。 `flexctl registration inspect`​ コマンドを使用して更新プロセスを確認します。 - `inspect`​ コマンドでは、​`renew`​ コマンドが成功したかどうかを確認するために使用できる登録情報が抽出されます。 - `inspect`​ コマンドを使用して、登録の更新が実際に必要かどうかを最初に判断することもできます。​`inspect`​ コマンドでは、証明書の有効期限が返されます。 - デフォルトの方法を使用して更新を確認 (調査) することも、既存の登録ファイルを指定することもできます。フラグを付けずに ​`inspect`​ コマンドを実行すると、このコマンドでデフォルトの方法を使用して登録状況が調査されます。 中断を回避する手順は、次のとおりです。 1. [最新バージョンの Flex Gateway をダウンロードします。](#before-you-begin) 2. Flex Gateway の登録を更新します。 2 つの方法のいずれかを選択します。 - [Anypoint Platform ユーザーログイン情報](#renew-with-user-password) - [接続アプリケーションのログイン情報](#renew-with-conn-app) 3. 更新プロセスが成功したことを確認します。 2 つの方法のいずれかを選択します。 - [デフォルトの方法](#inspect-with-custom-url) - [登録ファイル](#inspect-with-reg-file) ## [](#before-you-begin)始める前に 登録更新 ​`flexctl`​ コマンドを呼び出すには、最新バージョンの Flex Gateway をダウンロードしてください。このバージョンのゲートウェイを登録して実行する必要はありません。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) ## [](#renew-with-user-password)Anypoint Platform ユーザーログイン情報を使用して登録を更新する 1. `flex-renew-registration`​ という名前 (または同様の名前) の新しいディレクトリを作成します。この新しいディレクトリで ​`renew`​ コマンドを実行します。このコマンドは、新しい登録ファイルを作成します。

既存の登録ファイルが含まれているディレクトリで ​renew​ コマンドが実行されると、登録更新に失敗します。
2. 次のコマンドを使用します。 - Linux - Docker - Podman ```ssh flexctl registration renew --username= --password= \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/renew \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/renew \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 たとえば、​`/home/user/flex/registration.yaml`​ に現在の登録ファイルが含まれている場合は、​`/home/user/flex/`​ に移動して Anypoint Platform ログイン情報を使用して次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -u $UID -v "$(pwd)":/registration \ mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/registration/new \ /registration/registration.yaml ``` このコマンドでは、新しい登録ファイル ​`/home/user/flex/new/registration.yaml`​ が作成されます。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/renew:Z \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/renew \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。

ユーザーログイン情報を使用して ​renew​ コマンドを実行する前に、Anypoint Platform アカウントの MFA を無効にします。
3. コマンドを実行します。 出力には次のメッセージが含まれます。 ```text Registration renewal completed ``` 4. 新規作成された登録ファイルを実行時の登録ファイルの場所にコピーします。例: `/usr/local/share/mulesoft/flex-gateway/conf.d/registration.yaml` 5. Flex Gateway レプリカがすでに実行されている場合は、再起動します。 ## [](#renew-with-conn-app)接続アプリケーションのログイン情報を使用して登録を更新する 1. Anypoint Platform のユーザー名またはパスワードがない場合は、Anypoint アクセス管理から​[接続アプリケーションを設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​できます。 1. 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存してから、​`renew`​ コマンドでこれらのログイン情報を使用します。 2. `flex-renew-registration`​ という名前 (または同様の名前) の新しいディレクトリを作成します。この新しいディレクトリで ​`renew`​ コマンドを実行します。このコマンドは、新しい登録ファイルを作成します。

既存の登録ファイルが含まれているディレクトリで ​renew​ コマンドが実行されると、登録更新に失敗します。
3. 次のコマンドを使用します。 - Linux - Docker - Podman ```ssh flexctl registration renew --client-id= --client-secret= \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/renew \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/renew \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 たとえば、​`/home/user/flex/registration.yaml`​ に現在の登録ファイルが含まれている場合は、​`/home/user/flex/`​ に移動して接続アプリケーションのログイン情報を使用して次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -u $UID -v "$(pwd)":/registration \ mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/registration/new \ /registration/registration.yaml ``` このコマンドでは、新しい登録ファイル ​`/home/user/flex/new/registration.yaml`​ が作成されます。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/renew:Z \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/renew \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 4. コマンドを実行します。 出力には次のメッセージが含まれます。 ```text Registration renewal completed ``` 5. 新規作成された登録ファイルを実行時の登録ファイルの場所にコピーします。例: `/usr/local/share/mulesoft/flex-gateway/conf.d/registration.yaml` 6. Flex Gateway レプリカがすでに実行されている場合は、再起動します。 ## [](#inspect-with-custom-url)デフォルトの方法を使用した登録状況の確認 登録を調査するには、次のコマンドを実行します。 - Linux - Docker - Podman ```ssh flexctl registration inspect ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`exec`​ コマンドの一部として ​`inspect`​ を実行します。​``​ は実行中のコンテナ参照に置き換えます。 ```ssh docker exec -u $UID flexctl registration inspect ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`exec`​ コマンドの一部として ​`inspect`​ を実行します。​``​ は実行中のコンテナ参照に置き換えます。 ```ssh podman exec -u $UID flexctl registration inspect ``` 出力には証明書の有効期限の日付が含まれます。次に例を示します。 ```text {“expiration_date”: “2025-09-25 19:27:32 +0000 UTC”} ``` ## [](#inspect-with-reg-file)登録ファイルを使用した登録状況の確認 `registration.yaml`​ ファイルから情報を抽出して、登録を調査できます。パスとファイル名を指定します。 登録を調査するには、次のコマンドを実行します。 - Linux - Docker - Podman ```ssh flexctl registration inspect --file= ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`inspect`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration inspect --file= ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`inspect`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration inspect --file= ``` 出力には証明書の有効期限の日付が含まれます。 ```text {“expiration_date”: “2025-09-25 19:27:32 +0000 UTC”} ``` たとえば、現在のディレクトリに登録ファイルが含まれている場合は、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration \ -u $UID mulesoft/flex-gateway \ registration inspect --file=/registration/registration.yaml ``` ## [](#kubernetes-で実行されている-flex-gateway-の登録を確認する)Kubernetes で実行されている Flex Gateway の登録を確認する 次の例では、Flex Gateway が ​`ingress`​ リリース名を使用して ​`gateway`​ 名前空間にインストールされていて、登録が Kubernetes データベースに保存されているシナリオについて説明します。 1. 次の ​`kubectl`​ コマンドを使用して ​`registration.yaml`​ ファイルを復元します。 ```ssh kubectl -n gateway get secret "$(kubectl -n gateway get deployment ingress -o=jsonpath='{.spec.template.spec.volumes[?(@.name=="registration")].secret.secretName}')" -o=jsonpath='{.data.registration\.yaml}' | base64 --decode > registration.yaml ``` このコマンドにより、登録ファイルが ​`./registration.yaml`​ に保存されます。 2. 前のセクションで Docker について説明しているように、​`flexctl registration renew`​ コマンドを実行します。 - [Anypoint Platform ユーザーログイン情報を使用して更新する](#renew-with-user-password) - [接続アプリケーションのログイン情報を使用して更新する](#renew-with-conn-app) 3. 次の ​`helm`​ コマンドを使用して Flex Gateway をアップグレードします。 ```ssh helm get values -n gateway ingress > values.yaml \ && helm upgrade -n gateway ingress flex-gateway/flex-gateway --wait -f values.yaml --set-file registration.content=new/registration.yaml ``` ## [](#更新コマンドと検証コマンドを使用したヘルプの取得)更新コマンドと検証コマンドを使用したヘルプの取得 次の ​`help`​ コマンドを実行して使用方法に関する情報を確認できます。 - 更新 - Linux - Docker - Podman ```ssh flexctl registration renew --help ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh docker run --entrypoint flexctl mulesoft/flex-gateway registration renew --help ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh podman run --entrypoint flexctl docker.io/mulesoft/flex-gateway registration renew --help ``` - 検証 - Linux - Docker - Podman ```ssh flexctl registration inspect --help ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh docker run --entrypoint flexctl mulesoft/flex-gateway registration inspect --help ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh podman run --entrypoint flexctl docker.io/mulesoft/flex-gateway registration inspect --help ``` ## [](#期限切れの登録の更新)期限切れの登録の更新 接続モードで期限切れの証明書を使用して Flex Gateway を実行しようとすると、次の結果になります。 - 新規のレプリカは Anypoint Platform から API 設定のダウンロードに失敗するため、使用できなくなります。既存のクラスターは再読み込みに失敗します。 - ログとメトリクスは Anypoint Platform へのアップロードに失敗します。Anypoint Platform を使用したトラブルシューティングはできません。 - 測定情報 Anypoint Platform へのアップロードに失敗します。MuleSoft では使用量メトリクスの収集やレポートができません。 ローカルモードで期限切れの証明書を使用して Flex Gateway を実行しようとすると、次の結果になります。 - 測定情報 Anypoint Platform へのアップロードに失敗します。MuleSoft では使用量メトリクスの収集やレポートができません。 証明書の期限が切れていても ​`flexctl registration renew`​ を呼び出すことはでき、これによって期限切れの証明書が更新されます。 ## [](#関連情報)関連情報 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) # Flex Gateway の監視 Flex Gateway を使用すると、API とゲートウェイインスタンスの状態を監視し、重要なメトリクスを表示できます。 Flex Gateway の監視とログ記録についての詳細は、次を参照してください。 - [管理 Flex Gateway での監視](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-monitor) - [接続モードでの監視](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-monitor) - [ローカルモードでの監視](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-monitor) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) # Flex Gateway の監視 Flex Gateway を使用すると、API とゲートウェイインスタンスの状態を監視し、重要なメトリクスを表示できます。監視は、Anypoint Platform (接続モード) または宣言型設定ファイル (ローカルモード) を介して設定します。 Flex Gateway の監視とログ記録についての詳細は、次を参照してください。 - [接続モードでの監視](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-monitor) - [ローカルモードでの監視](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-monitor) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway の監視 Flex Gateway を使用すると、API とゲートウェイインスタンスの状態を監視し、重要なメトリクスを表示できます。 Flex Gateway の監視とログ記録についての詳細は、次を参照してください。 - [管理 Flex Gateway での監視](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-monitor) - [接続モードでの監視](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-monitor) - [ローカルモードでの監視](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-monitor) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) # Flex Gateway の管理 ゲートウェイ管理についての詳細は、次のタスクを参照してください。 - [Flex Gateway のアップグレード](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-upgrade) - [Flex Gateway のインスタンスの削除](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-delete) - [Flex Gateway のアンインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-uninstall) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management) - [Flex Gateway の登録の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-renew-certificate) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway の複数リージョンデプロイメント Flex Gateway を複数のリージョンにインストールして、レイテンシーを低減し、ライブフェールオーバーを確実に実行します。ほとんどの実装は、複数の Flex Gateway または複数の Flex レプリカを使用して設定できます。どちらを選択するかによって、Redis 共有ストレージ、ポリシー、ログに関する考慮事項が異なります。Flex レプリカについての詳細は、​[「Flex レプリカ」](https://docs.mulesoft.com/jp/gateway/1.10/#replicas)​を参照してください。 以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。 実装図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 ## [](#implementation-1)実装 1: 2 つの個別のリージョンで同じ API を使用する高可用性 実装 1 では、リージョン固有ではないトラフィックに対して高可用性を提供します。DNS サービスはアクティブ-アクティブフェールオーバー用に設定されます。つまり、常に各リージョンでトラフィックを処理します。 ### [](#implementation-1a)実装 1A: クロスリージョン Flex Gateway この実装では、次のようになります。 - 1 つの Flex Gateway には、複数のリージョンに分散する Flex レプリカがあります。 - Flex Gateway は Anypoint Platform に 1 回登録され、複数のリージョンと可用性ゾーンにデプロイされます。 - 各 Flex Gateway のログとメトリクスは Anypoint Platform で統合されます。 - DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。 - Gateway にデプロイされた API は、すべてのリージョンおよび可用性ゾーンで使用できます。 - アップストリームサービスやポリシーを含む API 設定はすべてのリージョンで同じです。アップストリームサービスはリージョンに依存しない必要があります。つまり、DNS がローカルであるか、DNS にリージョンへの参照がないかのいずれかです。 - Redis クラスターをリージョン間で複製する必要があります。複製しない場合、Redis 共有ストレージを使用できません。Redis の複製は、トラフィックがリージョン固有でない場合に必要です。 - 唯一のクロスリージョントラフィックは Redis 同期です。 次の図では、異なるリージョンおよび可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。 ![さまざまなリージョンにデプロイされた Flex レプリカの高可用性をサポートするために必要なサービスが含まれている実装 1A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/high-availability-1a.png) ### [](#implementation-1b)実装 1B: リージョン固有の Flex Gateway この実装では、次のようになります。 - 各リージョンに個別の Flex Gateway があり、すべてのリソースが独立したエンティティとして存在します。 - リージョンごとに個別の Flex Gateway が登録されます。 - リージョン固有の各 API インスタンスには、Anypoint Platform の個別のメトリクス、アラート、ログがあります。 - 設定がリージョン間で似ている場合でも、ポリシーはリージョン固有です。 - DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。 - API デプロイメントは Flex Gateway ごとに固有です。リージョンでサポートされる API ごとに、API インスタンスをリージョンの Flex Gateway にデプロイする必要があります。 - API グループはコントラクト (アクセス要求) をリージョン間で共有できます。設定で API グループが必要でない場合があります。 - Redis 共有ストレージでは同期は不要です。 - クロスリージョントラフィックはありません。 次の図では、すべての API が重複しているため、同一の設定は不要です。 ![リージョン固有の Flex Gateway の高可用性をサポートするために必要なサービスが含まれている実装 1B の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/high-availability-1b.png) ## [](#implementation-2)実装 2: API の障害回復 この実装は、​[実装 1A: クロスリージョン Flex Gateway](#implementation-1a)​と似ています。ただし、DNS サービスがアクティブ-パッシブのため、スタンバイリージョンは、プライマリリージョンが健全でなくなった場合のみトラフィックを受信します。この実装では、実装 1A よりも設定の複雑さが軽減されます。 フェールオーバー中のキャッシュ損失が受け入れられる場合、Redis 同期は不要です。 次の図では、異なる可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。リージョン B は高可用性を提供しますが、リージョン A が健全でない場合のみトラフィックを受信します。 ![Flex Gateway で API の障害回復を有効にするために必要なサービスが含まれている実装 2 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/high-availability-2.png) ## [](#implementation-3)実装 3: 最も近いリージョンへのトラフィックの転送 [実装 3A: 同じポリシーを使用する API へのトラフィックの転送](#implementation-3a)​と​[実装 3B: 異なるポリシーを使用する API へのトラフィックの転送](#implementation-3b)​の両方で、Flex Gateway は最も都合の良いリージョンにトラフィックを転送して、レイテンシーを低減します。ポリシー要件に従って実装を選択します。 ### [](#implementation-3a)実装 3A: 同じポリシーを使用する API へのトラフィックの転送 この実装は​[実装 1A: クロスリージョン Flex Gateway](#implementation-1a)​と似ており、考慮事項は同じです。ただし、要求が特定のリージョンに送信されるため、Redis の複製は不要です。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。 ![顧客の要求を最も近いリージョンに転送するために必要なサービスが含まれている実装 3A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/high-availability-3a.png) ### [](#implementation-3b)実装 3B: 異なるポリシーを使用する API へのトラフィックの転送 この実装は​[実装 1B: リージョン固有の Flex Gateway](#implementation-1b)​と似ており、考慮事項は同じです。リージョン固有のゲートウェイをデプロイし、必要なポリシーを各 API に適用します。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。 ![顧客の要求を最も近いリージョンに転送するために必要なサービスが含まれている実装 3B の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/high-availability-3b.png)
SLA のレート制限をすべてのリージョンに適用するには、すべてのリージョンでレート制限が同じである必要があります。コントラクトを統合するには、API グループを使用します。
# Flex Gateway の複数リージョンデプロイメント Flex Gateway を複数のリージョンにインストールして、レイテンシーを低減し、ライブフェールオーバーを確実に実行します。ほとんどの実装は、複数の Flex Gateway または複数の Flex レプリカを使用して設定できます。どちらを選択するかによって、Redis 共有ストレージ、ポリシー、ログに関する考慮事項が異なります。Flex レプリカについての詳細は、​[「Flex レプリカ」](https://docs.mulesoft.com/jp/gateway/1.8/#replicas)​を参照してください。 以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。 実装図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 ## [](#implementation-1)実装 1: 2 つの個別のリージョンで同じ API を使用する高可用性 実装 1 では、リージョン固有ではないトラフィックに対して高可用性を提供します。DNS サービスはアクティブ-アクティブフェールオーバー用に設定されます。つまり、常に各リージョンでトラフィックを処理します。 ### [](#implementation-1a)実装 1A: クロスリージョン Flex Gateway この実装では、次のようになります。 - 1 つの Flex Gateway には、複数のリージョンに分散する Flex レプリカがあります。 - Flex Gateway は Anypoint Platform に 1 回登録され、複数のリージョンと可用性ゾーンにデプロイされます。 - 各 Flex Gateway のログとメトリクスは Anypoint Platform で統合されます。 - DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。 - Gateway にデプロイされた API は、すべてのリージョンおよび可用性ゾーンで使用できます。 - アップストリームサービスやポリシーを含む API 設定はすべてのリージョンで同じです。アップストリームサービスはリージョンに依存しない必要があります。つまり、DNS がローカルであるか、DNS にリージョンへの参照がないかのいずれかです。 - Redis クラスターをリージョン間で複製する必要があります。複製しない場合、Redis 共有ストレージを使用できません。Redis の複製は、トラフィックがリージョン固有でない場合に必要です。 - 唯一のクロスリージョントラフィックは Redis 同期です。 次の図では、異なるリージョンおよび可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。 ![さまざまなリージョンにデプロイされた Flex レプリカの高可用性をサポートするために必要なサービスが含まれている実装 1A の詳細なビュー。](/mulesoft/current/ja-jp/gateway/1.8/_images/high-availability-1a.png) ### [](#implementation-1b)実装 1B: リージョン固有の Flex Gateway この実装では、次のようになります。 - 各リージョンに個別の Flex Gateway があり、すべてのリソースが独立したエンティティとして存在します。 - リージョンごとに個別の Flex Gateway が登録されます。 - リージョン固有の各 API インスタンスには、Anypoint Platform の個別のメトリクス、アラート、ログがあります。 - 設定がリージョン間で似ている場合でも、ポリシーはリージョン固有です。 - DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。 - API デプロイメントは Flex Gateway ごとに固有です。リージョンでサポートされる API ごとに、API インスタンスをリージョンの Flex Gateway にデプロイする必要があります。 - API グループはコントラクト (アクセス要求) をリージョン間で共有できます。設定で API グループが必要でない場合があります。 - Redis 共有ストレージでは同期は不要です。 - クロスリージョントラフィックはありませんん。 次の図では、すべての API が重複しているため、同一の設定は不要です。 ![リージョン固有の Flex Gateway の高可用性をサポートするために必要なサービスが含まれている実装 1B の詳細なビュー。](/mulesoft/current/ja-jp/gateway/1.8/_images/high-availability-1b.png) ## [](#implementation-2)実装 2: API の障害回復 この実装は、​[実装 1A: クロスリージョン Flex Gateway](#implementation-1a)​と似ています。ただし、DNS サービスがアクティブ-パッシブのため、スタンバイリージョンは、プライマリリージョンが健全でなくなった場合のみトラフィックを受信します。この実装では、実装 1A よりも設定の複雑さが軽減されます。 フェールオーバー中のキャッシュ損失が受け入れられる場合、Redis 同期は不要です。 次の図では、異なる可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。リージョン B は高可用性を提供しますが、リージョン A が健全でない場合のみトラフィックを受信します。 ![Flex Gateway で API の障害回復を有効にするために必要なサービスが含まれている実装 2 の詳細なビュー。](/mulesoft/current/ja-jp/gateway/1.8/_images/high-availability-2.png) ## [](#implementation-3)実装 3: 最も近いリージョンへのトラフィックの転送 [実装 3A: 同じポリシーを使用する API へのトラフィックの転送](#implementation-3a)​と​[実装 3B: 異なるポリシーを使用する API へのトラフィックの転送](#implementation-3b)​の両方で、Flex Gateway は最も都合の良いリージョンにトラフィックを転送して、レイテンシーを低減します。ポリシー要件に従って実装を選択します。 ### [](#implementation-3a)実装 3A: 同じポリシーを使用する API へのトラフィックの転送 この実装は​[実装 1A: クロスリージョン Flex Gateway](#implementation-1a)​と似ており、考慮事項は同じです。ただし、要求が特定のリージョンに送信されるため、Redis の複製は不要です。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。 ![顧客の要求を最も近いリージョンに転送するために必要なサービスが含まれている実装 3A の詳細なビュー。](/mulesoft/current/ja-jp/gateway/1.8/_images/high-availability-3a.png) ### [](#implementation-3b)実装 3B: 異なるポリシーを使用する API へのトラフィックの転送 この実装は​[実装 1B: リージョン固有の Flex Gateway](#implementation-1b)​と似ており、考慮事項は同じです。リージョン固有のゲートウェイをデプロイし、必要なポリシーを各 API に適用します。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。 ![顧客の要求を最も近いリージョンに転送するために必要なサービスが含まれている実装 3B の詳細なビュー。](/mulesoft/current/ja-jp/gateway/1.8/_images/high-availability-3b.png)
SLA のレート制限をすべてのリージョンに適用するには、すべてのリージョンでレート制限が同じである必要があります。コントラクトを統合するには、API グループを使用します。
# Flex Gateway の複数リージョンデプロイメント Flex Gateway を複数のリージョンにインストールして、レイテンシーを低減し、ライブフェールオーバーを確実に実行します。ほとんどの実装は、複数の Flex Gateway または複数の Flex レプリカを使用して設定できます。どちらを選択するかによって、Redis 共有ストレージ、ポリシー、ログに関する考慮事項が異なります。Flex レプリカについての詳細は、​[「Flex レプリカ」](https://docs.mulesoft.com/jp/gateway/1.9/#replicas)​を参照してください。 以下のすべての図は、接続モードで実行されている Flex Gateway を示しています。ローカルモードで実行されている Flex Gateway での唯一の違いは、Anypoint Platform がデプロイメントモデルに存在しないことです。これは、Flex Gateway とアップストリームおよびダウンストリームサービス間の情報の流れには影響しません。 実装図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 ## [](#implementation-1)実装 1: 2 つの個別のリージョンで同じ API を使用する高可用性 実装 1 では、リージョン固有ではないトラフィックに対して高可用性を提供します。DNS サービスはアクティブ-アクティブフェールオーバー用に設定されます。つまり、常に各リージョンでトラフィックを処理します。 ### [](#implementation-1a)実装 1A: クロスリージョン Flex Gateway この実装では、次のようになります。 - 1 つの Flex Gateway には、複数のリージョンに分散する Flex レプリカがあります。 - Flex Gateway は Anypoint Platform に 1 回登録され、複数のリージョンと可用性ゾーンにデプロイされます。 - 各 Flex Gateway のログとメトリクスは Anypoint Platform で統合されます。 - DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。 - Gateway にデプロイされた API は、すべてのリージョンおよび可用性ゾーンで使用できます。 - アップストリームサービスやポリシーを含む API 設定はすべてのリージョンで同じです。アップストリームサービスはリージョンに依存しない必要があります。つまり、DNS がローカルであるか、DNS にリージョンへの参照がないかのいずれかです。 - Redis クラスターをリージョン間で複製する必要があります。複製しない場合、Redis 共有ストレージを使用できません。Redis の複製は、トラフィックがリージョン固有でない場合に必要です。 - 唯一のクロスリージョントラフィックは Redis 同期です。 次の図では、異なるリージョンおよび可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。 ![さまざまなリージョンにデプロイされた Flex レプリカの高可用性をサポートするために必要なサービスが含まれている実装 1A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/high-availability-1a.png) ### [](#implementation-1b)実装 1B: リージョン固有の Flex Gateway この実装では、次のようになります。 - 各リージョンに個別の Flex Gateway があり、すべてのリソースが独立したエンティティとして存在します。 - リージョンごとに個別の Flex Gateway が登録されます。 - リージョン固有の各 API インスタンスには、Anypoint Platform の個別のメトリクス、アラート、ログがあります。 - 設定がリージョン間で似ている場合でも、ポリシーはリージョン固有です。 - DNS サービスはアクティブ-アクティブフェールオーバー用に設定され、常にトラフィックをいずれかのリージョンに転送します。 - API デプロイメントは Flex Gateway ごとに固有です。リージョンでサポートされる API ごとに、API インスタンスをリージョンの Flex Gateway にデプロイする必要があります。 - API グループはコントラクト (アクセス要求) をリージョン間で共有できます。設定で API グループが必要でない場合があります。 - Redis 共有ストレージでは同期は不要です。 - クロスリージョントラフィックはありませんん。 次の図では、すべての API が重複しているため、同一の設定は不要です。 ![リージョン固有の Flex Gateway の高可用性をサポートするために必要なサービスが含まれている実装 1B の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/high-availability-1b.png) ## [](#implementation-2)実装 2: API の障害回復 この実装は、​[実装 1A: クロスリージョン Flex Gateway](#implementation-1a)​と似ています。ただし、DNS サービスがアクティブ-パッシブのため、スタンバイリージョンは、プライマリリージョンが健全でなくなった場合のみトラフィックを受信します。この実装では、実装 1A よりも設定の複雑さが軽減されます。 フェールオーバー中のキャッシュ損失が受け入れられる場合、Redis 同期は不要です。 次の図では、異なる可用性ゾーンの Flex レプリカに個別の Kubernetes デプロイメントがあります。リージョン B は高可用性を提供しますが、リージョン A が健全でない場合のみトラフィックを受信します。 ![Flex Gateway で API の障害回復を有効にするために必要なサービスが含まれている実装 2 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/high-availability-2.png) ## [](#implementation-3)実装 3: 最も近いリージョンへのトラフィックの転送 [実装 3A: 同じポリシーを使用する API へのトラフィックの転送](#implementation-3a)​と​[実装 3B: 異なるポリシーを使用する API へのトラフィックの転送](#implementation-3b)​の両方で、Flex Gateway は最も都合の良いリージョンにトラフィックを転送して、レイテンシーを低減します。ポリシー要件に従って実装を選択します。 ### [](#implementation-3a)実装 3A: 同じポリシーを使用する API へのトラフィックの転送 この実装は​[実装 1A: クロスリージョン Flex Gateway](#implementation-1a)​と似ており、考慮事項は同じです。ただし、要求が特定のリージョンに送信されるため、Redis の複製は不要です。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。 ![顧客の要求を最も近いリージョンに転送するために必要なサービスが含まれている実装 3A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/high-availability-3a.png) ### [](#implementation-3b)実装 3B: 異なるポリシーを使用する API へのトラフィックの転送 この実装は​[実装 1B: リージョン固有の Flex Gateway](#implementation-1b)​と似ており、考慮事項は同じです。リージョン固有のゲートウェイをデプロイし、必要なポリシーを各 API に適用します。各リージョンの高可用性または障害回復ゾーンを設定し、API の可用性を確保します。 ![顧客の要求を最も近いリージョンに転送するために必要なサービスが含まれている実装 3B の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/high-availability-3b.png)
SLA のレート制限をすべてのリージョンに適用するには、すべてのリージョンでレート制限が同じである必要があります。コントラクトを統合するには、API グループを使用します。
# Flex Gateway の要件と制限 Anypoint Flex Gateway をダウンロードしてインストールする前に、次の要件と制限を確認してください。 ## [](#flex-gateway-の要件)Flex Gateway の要件 ### [](#権限の要件)権限の要件 Flex Gateway を使用するには、次の権限が必要です。
権限 可能な操作 注意事項

Manage Servers (サーバーの管理)

サーバーおよび Flex Gateway リソースを作成、更新、削除する。

ビジネスグループの特定の環境に割り当てられる Runtime Manager 権限。

Read Servers (サーバーの参照)

サーバーおよび Flex Gateway リソースを参照する。

ビジネスグループの特定の環境に割り当てられる Runtime Manager 権限。

Usage Viewer (使用状況閲覧者)

ゲートウェイメトリクスを参照する。

組織管理者のみがルート組織レベルで追加できる使用状況権限。
これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 ### [](#接続アプリケーションのスコープの要件)接続アプリケーションのスコープの要件 接続アプリケーションを使用して自己管理 Flex Gateway を登録するには、次のスコープが必要です。 - Manage Servers (サーバーの管理) - Read Servers (サーバーの参照) - View Organization (組織の表示) ## [](#管理-flex-gateway-リソースの要件)管理 Flex Gateway リソースの要件 管理 Flex Gateway your を使用するには、ビジネスグループに次の管理 Flex Gateway リソースの 1 つ以上が必要です。 - Large Managed Flex Gateways (大規模管理 Flex Gateway) - Small Managed Flex Gateways (小規模管理 Flex Gateway) これらのリソースは継承されません。管理 Flex Gateway リソースをビジネスグループに再配信するには、​[「既存のビジネスグループ間のリソースの再配信」](https://docs.mulesoft.com/jp/access-management/business-groups#redistribute-resources)​を参照してください。 ## [](#管理-flex-gateway-非公開スペースの要件)管理 Flex Gateway 非公開スペースの要件 管理 Flex Gateway を使用するには、CloudHub 2.0 に非公開スペースを作成したか、他の誰かが作成した非公開スペースへのアクセス権があることを確認します。 非公開スペースを作成するには、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 ## [](#自己管理-flex-gateway-のソフトウェア要件)自己管理 Flex Gateway のソフトウェア要件 Flex Gateway は Windows、または Windows で実行されている Docker ではサポートされません。 ### [](#kubernetes-および-openshift-デプロイメントのソフトウェア要件)Kubernetes および OpenShift デプロイメントのソフトウェア要件 Flex Gateway を実行するためには以下のソフトウェアが必要です。 - 少なくとも Kubernetes 1.21 または OpenShift 4.8。 - Ingress v1 (安定)。設定リソースで ​`apiVersion: networking.k8s.io/v1`​ を API バージョンとして指定する必要があります。 - プライベートクラウドまたはデータセンター。 または、次のようなクラウドプロバイダー。 - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (Amazon EKS) - Azure Kubernetes Service (AKS) - Helm バージョン 3.0.0 以降が必要です。 ### [](#linux-デプロイメントのソフトウェア要件)Linux デプロイメントのソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Flex Gateway は、クラウドネイティブなアーキテクチャで動作するように設計されています。そのため、単独の Linux VM への複数のインストールはサポートされません。Linux VM ごとにゲートウェイインスタンスを 1 つだけしかインストールできません。 ### [](#コンテナデプロイメントのソフトウェア要件)コンテナデプロイメントのソフトウェア要件 Flex Gateway では以下がサポートされます。 - Docker - Podman さらに、Flex Gateway では次のコンテナオーケストレーションサービスがサポートされます。 - Amazon Elastic Container Service (Amazon ECS) - Azure Container Service (ACS) - Google Cloud Run - AWS Fargate ## [](#自己管理-flex-gateway-のハードウェア要件)自己管理 Flex Gateway のハードウェア要件 1 つの Flex Gateway で複数のバックエンド API をサポートできます。より多くのバックエンド API をサポートするには、複数のレプリカまたは追加の Flex Gateway をデプロイすることができます。サイズについての詳細は、[自己管理 Flex Gateway のリソースのサイズ変更](https://docs.mulesoft.com/jp/gateway/1.10/flex-sizing-guide)を参照してください。 Flex Gateway には、Intel または AMD-64 プロセッサーが必要です。 ## [](#ポートipホスト名の許可リスト要件)ポート、IP、ホスト名の許可リスト要件 Flex Gateway が MuleSoft で管理されるオンライン Anypoint Platform API やサービスと通信できるようにするには、次の外部リソースのホスト名とポートを許可リストに登録する必要があります。
プレーン ホスト ポート モード 説明 プロトコル

US

anypoint.mulesoft.com

443

両方

コントロールプレーンとの接続、内部メトリクスのプッシュ、カスタムポリシーバイナリのダウンロードに必要。

HTTPS

US

arm-mcm2-service.kprod.msap.io

443

両方

トランスポートレイヤーとの通信に必要。

mTLS

US

logging.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

metering.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

monitoring.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

exchange-files.anypoint.mulesoft.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

US

exchange2-asset-manager-kprod.s3.amazonaws.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

US

configuration-resolver.prod.cloudhub.io

443

接続

ポリシーをダウンロードするのに必須。

mTLS

US

us1.ingest.mulesoft.com

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

flex-packages.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須。

HTTPS

EU

eu1.anypoint.mulesoft.com

443

両方

コントロールプレーンとの接続、内部メトリクスのプッシュ、カスタムポリシーバイナリのダウンロードに必要。

HTTPS

EU

arm-mcm2-service.kprod-eu.msap.io

443

両方

トランスポートレイヤーとの通信に必要。

mTLS

EU

logging.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

metering.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

eu1.ingest.mulesoft.com

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

monitoring.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

configuration-resolver.prod-eu.msap.io

443

接続

ポリシーをダウンロードするのに必須。

mTLS

EU

exchange-files.eu1.anypoint.mulesoft.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

EU

exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

EU

flex-packages.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須。

HTTPS

EU

flex-packages.eu1.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須。

HTTPS

ポート 9998 は内部プロセス用に予約されているため、​ApiInstance​ 定義では使用しないでください。
## [](#limits)Flex Gateway の制限
制限 値 注意事項

リクエストヘッダー

60 KB

要求がこの制限を超えると、​「431」​応答を受信します。

ペイロード

1 MB

この制限は、ペイロードのバッファ (メッセージログを使用したペイロードのログなど) のみに適用されます。ペイロードにアクセスしない場合、ペイロードサイズに制限はありません。
ペイロードがこの制限を超えると、「413」応答を受信します。

API ごとのコントラクト

1,000

この制限を超えることはサポートされていませんが、エラーは発生しません。

ゲートウェイインスタンスごとのコントラクト

10,000

この制限を超えることはサポートされていませんが、エラーは発生しません。

API ごとのアップストリーム

100

100 個のアップストリームは、さまざまなルートの組み合わせで構成できます。
詳細は、​複数のアップストリームの制限​を参照してください。

API あたりのルート数

100

ルートあたりのアップストリーム数

10
### [](#managed-flex-gateway-limits)管理 Flex Gateway の制限
制限 値 注意事項

大規模管理ゲートウェイインスタンスごとの API

500

この制限を超えることはサポートされていませんが、エラーは発生しません。

小規模管理ゲートウェイインスタンスごとの API

50

この制限を超えることはサポートされていませんが、エラーは発生しません。

大規模管理ゲートウェイの 1 秒あたりの要件

500

小規模管理ゲートウェイの 1 秒あたりの要件

100
### [](#自己管理-flex-gateway-の制限)自己管理 Flex Gateway の制限
制限 値 注意事項

リクエストヘッダー

60 KB

要求がこの制限を超えると、​「431」​応答を受信します。

自己管理ゲートウェイインスタンスごとの API

1,000

この制限を超えることはサポートされていませんが、エラーは発生しません。
## [](#flex-gateway-環境変数)Flex Gateway 環境変数
環境変数 デフォルト値 機能

FLEX_CONNECTION_IDLE_TIMEOUT_SECONDS

60

接続がタイムアウトになるまでアイドル状態を維持できる最大秒数。

FLEX_DOWNSTREAM_CONNECTION_BUFFER_LIMIT_BYTES

1048576 (1 MB)

新しい接続の読み書きバッファの最大サイズ (バイト)。

FLEX_ENVOY_HEADERS_ENABLED

false

Envoy ヘッダーを許可 (​true​) または要求から削除 (​false​) します。

FLEX_STREAM_IDLE_TIMEOUT_SECONDS

300

ストリームがインバウンド (クライアントから Flex Gateway) またはアウトバウンド (Flex Gateway からアップストリームサービス) 方向のデータを受信せずにアイドル状態を続けられる最大秒数。

FLEX_UPSTREAM_CONNECTION_IDLE_TIMEOUT_SECONDS

60

Flex Gateway とアップストリームサービス間のストリームが要求から要求までの間にアイドル状態を続けられる最大秒数。

FLEX_UPSTREAM_RESPONSE_TIMEOUT_SECONDS

15

Flex Gateway がアップストリームサービスからの応答を待機する最大秒数。
### [](#関連情報)関連情報 - [接続モードでのタイムアウトの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-timeout) - [ローカルモードでのタイムアウトの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-timeout) # Flex Gateway の要件と制限 Anypoint Flex Gateway をダウンロードしてインストールする前に、次の要件と制限を確認してください。 ## [](#権限の要件)権限の要件 Flex Gateway を実行するには以下の権限が必要です。 - Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限 これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 また、Anypoint Platform 管理者は、適切な権限を付与して接続アプリケーションを追加することもできます。 詳細は​[「接続アプリケーション」](https://docs.mulesoft.com/jp/access-management/connected-apps-overview)​を参照してください。 接続アプリケーションを使用して Flex Gateway を登録するには、次のスコープが必要です。 - サーバーの管理 - サーバーの参照 - View Organization (組織の表示) ## [](#ソフトウェア要件)ソフトウェア要件 Flex Gateway は Windows、または Windows で実行されている Docker ではサポートされません。 ### [](#kubernetes-および-openshift-デプロイメントのソフトウェア要件)Kubernetes および OpenShift デプロイメントのソフトウェア要件 Flex Gateway を実行するためには以下のソフトウェアが必要です。 - 少なくとも Kubernetes 1.21 または OpenShift 4.8。 - Ingress v1 (安定)。設定リソースで ​`apiVersion: networking.k8s.io/v1`​ を API バージョンとして指定する必要があります。 - プライベートクラウドまたはデータセンター。 または、次のようなクラウドプロバイダー。 - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (Amazon EKS) - Azure Kubernetes Service (AKS) - Helm バージョン 3.0.0 以降が必要です。 ### [](#linux-デプロイメントのソフトウェア要件)Linux デプロイメントのソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Flex Gateway は、クラウドネイティブなアーキテクチャで動作するように設計されています。したがって、Linux VM ごとにゲートウェイインスタンスを 1 つだけしかインストールできません。単独の VM に複数のインスタンスをインストールすることはできません。 ### [](#コンテナデプロイメントのソフトウェア要件)コンテナデプロイメントのソフトウェア要件 Flex Gateway では以下がサポートされます。 - Docker - Podman さらに、Flex Gateway では次のコンテナオーケストレーションサービスがサポートされます。 - Amazon Elastic Container Service (Amazon ECS) - Azure Container Service (ACS) - Google Cloud Run - AWS Fargate ## [](#ハードウェア要件)ハードウェア要件 1 つの Flex Gateway で複数のバックエンド API をサポートできます。より多くのバックエンド API をサポートするには、複数のレプリカまたは追加の Flex Gateway をデプロイすることができます。サイズについての詳細は、[Flex Gateway のリソースのサイズ](https://docs.mulesoft.com/jp/gateway/1.8/flex-sizing-guide)を参照してください。 Flex Gateway には、Intel または AMD-64 プロセッサーが必要です。 ## [](#limits)制限
Limit (制限) Value (値) 注意事項

リクエストヘッダー

60 KB

要求がこの制限を超えると、​「431」​応答を受信します。

ペイロード

1 MB

この制限は、ペイロードのバッファ (メッセージログを使用したペイロードのログなど) のみに適用されます。ペイロードにアクセスしない場合、ペイロードサイズに制限はありません。
ペイロードがこの制限を超えると、「413」応答を受信します。

ゲートウェイインスタンスごとの API

600

この制限を超えることはサポートされていませんが、エラーは発生しません。

API ごとのアップストリーム

50

この 50 件のアップストリームは、さまざまなルートの組み合わせです。
詳細は、​複数のアップストリームの制限​を参照してください。

API ごとのコントラクト

1,000

この制限を超えることはサポートされていませんが、エラーは発生しません。

ゲートウェイインスタンスごとのコントラクト

10,000

この制限を超えることはサポートされていませんが、エラーは発生しません。
## [](#ポートipホスト名の許可リスト要件)ポート、IP、ホスト名の許可リスト要件 Flex Gateway が MuleSoft で管理されるオンライン Anypoint Platform API やサービスと通信できるようにするには、以下の外部リソースのホスト名とポートを許可リストに登録する必要があります。
プレーン ホスト ポート モード 説明 プロトコル

US

anypoint.mulesoft.com

443

両方

コントロールプレーンとの接続、内部メトリクスのプッシュ、カスタムポリシーバイナリのダウンロードに必要

HTTPS

US

arm-mcm2-service.kprod.msap.io

443

両方

トランスポートレイヤーとの通信に必要

mTLS

US

logging.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

US

metering.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

US

monitoring.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

US

exchange-files.anypoint.mulesoft.com

443

接続

ポリシーをダウンロードするのに必須

HTTPS

US

exchange2-asset-manager-kprod.s3.amazonaws.com

443

接続

ポリシーをダウンロードするのに必須

HTTPS

US

configuration-resolver.prod.cloudhub.io

443

接続

ポリシーをダウンロードするのに必須

mTLS

US

us1.ingest.mulesoft.com

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

US

flex-packages.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須

HTTPS

EU

eu1.anypoint.mulesoft.com

443

両方

コントロールプレーンとの接続、内部メトリクスのプッシュ、カスタムポリシーバイナリのダウンロードに必要

HTTPS

EU

arm-mcm2-service.kprod-eu.msap.io

443

両方

トランスポートレイヤーとの通信に必要

mTLS

EU

logging.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

EU

metering.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

EU

eu1.ingest.mulesoft.com

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

EU

monitoring.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須

HTTPS

EU

configuration-resolver.prod-eu.msap.io

443

接続

ポリシーをダウンロードするのに必須

mTLS

EU

exchange-files.eu1.anypoint.mulesoft.com

443

接続

ポリシーをダウンロードするのに必須

HTTPS

EU

exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

443

接続

ポリシーをダウンロードするのに必須

HTTPS

EU

flex-packages.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須

HTTPS

EU

flex-packages.eu1.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須

HTTPS

ポート 9998 は内部プロセス用に予約されているため、​ApiInstance​ 定義では使用しないでください。
# Flex Gateway の要件と制限 Anypoint Flex Gateway をダウンロードしてインストールする前に、次の要件と制限を確認してください。 ## [](#flex-gateway-の要件)Flex Gateway の要件 ### [](#権限の要件)権限の要件 Flex Gateway を使用するには、次の権限が必要です。
権限 可能な操作 注意事項

Manage Servers (サーバーの管理)

サーバーおよび Flex Gateway リソースを作成、更新、削除する。

ビジネスグループの特定の環境に割り当てられる Runtime Manager 権限。

Read Servers (サーバーの参照)

サーバーおよび Flex Gateway リソースを参照する。

ビジネスグループの特定の環境に割り当てられる Runtime Manager 権限。

Usage Viewer (使用状況閲覧者)

ゲートウェイメトリクスを参照する。

組織管理者のみがルート組織レベルで追加できる使用状況権限。
これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 ### [](#接続アプリケーションのスコープの要件)接続アプリケーションのスコープの要件 接続アプリケーションを使用して自己管理 Flex Gateway を登録するには、次のスコープが必要です。 - Manage Servers (サーバーの管理) - Read Servers (サーバーの参照) - View Organization (組織の表示) ## [](#管理-flex-gateway-リソースの要件)管理 Flex Gateway リソースの要件 管理 Flex Gateway your を使用するには、ビジネスグループに次の管理 Flex Gateway リソースの 1 つ以上が必要です。 - Large Managed Flex Gateways (大規模管理 Flex Gateway) - Small Managed Flex Gateways (小規模管理 Flex Gateway) これらのリソースは継承されません。管理 Flex Gateway リソースをビジネスグループに再配信するには、​[「既存のビジネスグループ間のリソースの再配信」](https://docs.mulesoft.com/jp/access-management/business-groups#redistribute-resources)​を参照してください。 ## [](#管理-flex-gateway-非公開スペースの要件)管理 Flex Gateway 非公開スペースの要件 管理 Flex Gateway を使用するには、CloudHub 2.0 に非公開スペースを作成したか、他の誰かが作成した非公開スペースへのアクセス権があることを確認します。 非公開スペースを作成するには、[Creating Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-create-configure)を参照してください。 ## [](#自己管理-flex-gateway-のソフトウェア要件)自己管理 Flex Gateway のソフトウェア要件 Flex Gateway は Windows、または Windows で実行されている Docker ではサポートされません。 ### [](#kubernetes-および-openshift-デプロイメントのソフトウェア要件)Kubernetes および OpenShift デプロイメントのソフトウェア要件 Flex Gateway を実行するためには以下のソフトウェアが必要です。 - 少なくとも Kubernetes 1.21 または OpenShift 4.8。 - Ingress v1 (安定)。設定リソースで ​`apiVersion: networking.k8s.io/v1`​ を API バージョンとして指定する必要があります。 - プライベートクラウドまたはデータセンター。 または、次のようなクラウドプロバイダー。 - Google Kubernetes Engine (GKE) - Amazon Elastic Kubernetes Service (Amazon EKS) - Azure Kubernetes Service (AKS) - Helm バージョン 3.0.0 以降が必要です。 ### [](#linux-デプロイメントのソフトウェア要件)Linux デプロイメントのソフトウェア要件 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Flex Gateway は、クラウドネイティブなアーキテクチャで動作するように設計されています。そのため、単独の Linux VM への複数のインストールはサポートされません。Linux VM ごとにゲートウェイインスタンスを 1 つだけしかインストールできません。 ### [](#コンテナデプロイメントのソフトウェア要件)コンテナデプロイメントのソフトウェア要件 Flex Gateway では以下がサポートされます。 - Docker - Podman さらに、Flex Gateway では次のコンテナオーケストレーションサービスがサポートされます。 - Amazon Elastic Container Service (Amazon ECS) - Azure Container Service (ACS) - Google Cloud Run - AWS Fargate ## [](#自己管理-flex-gateway-のハードウェア要件)自己管理 Flex Gateway のハードウェア要件 1 つの Flex Gateway で複数のバックエンド API をサポートできます。より多くのバックエンド API をサポートするには、複数のレプリカまたは追加の Flex Gateway をデプロイすることができます。サイズについての詳細は、[自己管理 Flex Gateway のリソースのサイズ変更](https://docs.mulesoft.com/jp/gateway/1.9/flex-sizing-guide)を参照してください。 Flex Gateway には、Intel または AMD-64 プロセッサーが必要です。 ## [](#ポートipホスト名の許可リスト要件)ポート、IP、ホスト名の許可リスト要件 Flex Gateway が MuleSoft で管理されるオンライン Anypoint Platform API やサービスと通信できるようにするには、次の外部リソースのホスト名とポートを許可リストに登録する必要があります。
プレーン ホスト ポート モード 説明 プロトコル

US

anypoint.mulesoft.com

443

両方

コントロールプレーンとの接続、内部メトリクスのプッシュ、カスタムポリシーバイナリのダウンロードに必要。

HTTPS

US

arm-mcm2-service.kprod.msap.io

443

両方

トランスポートレイヤーとの通信に必要。

mTLS

US

logging.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

metering.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

monitoring.ingestion.us-east-1.prod.cloudhub.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

exchange-files.anypoint.mulesoft.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

US

exchange2-asset-manager-kprod.s3.amazonaws.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

US

configuration-resolver.prod.cloudhub.io

443

接続

ポリシーをダウンロードするのに必須。

mTLS

US

us1.ingest.mulesoft.com

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

US

flex-packages.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須。

HTTPS

EU

eu1.anypoint.mulesoft.com

443

両方

コントロールプレーンとの接続、内部メトリクスのプッシュ、カスタムポリシーバイナリのダウンロードに必要。

HTTPS

EU

arm-mcm2-service.kprod-eu.msap.io

443

両方

トランスポートレイヤーとの通信に必要。

mTLS

EU

logging.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

metering.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

eu1.ingest.mulesoft.com

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

monitoring.ingestion.eu-central-1.prod-eu.msap.io

443

両方

コントロールプレーンへの分析データの送信に必須。

HTTPS

EU

configuration-resolver.prod-eu.msap.io

443

接続

ポリシーをダウンロードするのに必須。

mTLS

EU

exchange-files.eu1.anypoint.mulesoft.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

EU

exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

443

接続

ポリシーをダウンロードするのに必須。

HTTPS

EU

flex-packages.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須。

HTTPS

EU

flex-packages.eu1.anypoint.mulesoft.com

443

両方

Flex Gateway をダウンロードおよびインストールするのに必須。

HTTPS

ポート 9998 は内部プロセス用に予約されているため、​ApiInstance​ 定義では使用しないでください。
## [](#limits)Flex Gateway の制限
制限 値 注意事項

リクエストヘッダー

60 KB

要求がこの制限を超えると、​「431」​応答を受信します。

ペイロード

1 MB

この制限は、ペイロードのバッファ (メッセージログを使用したペイロードのログなど) のみに適用されます。ペイロードにアクセスしない場合、ペイロードサイズに制限はありません。
ペイロードがこの制限を超えると、「413」応答を受信します。

API ごとのコントラクト

1,000

この制限を超えることはサポートされていませんが、エラーは発生しません。

ゲートウェイインスタンスごとのコントラクト

10,000

この制限を超えることはサポートされていませんが、エラーは発生しません。

API ごとのアップストリーム

100

100 個のアップストリームは、さまざまなルートの組み合わせで構成できます。
詳細は、​複数のアップストリームの制限​を参照してください。

API あたりのルート数

100

ルートあたりのアップストリーム数

10
### [](#managed-flex-gateway-limits)管理 Flex Gateway の制限
制限 値 注意事項

大規模管理ゲートウェイインスタンスごとの API

500

この制限を超えることはサポートされていませんが、エラーは発生しません。

小規模管理ゲートウェイインスタンスごとの API

50

この制限を超えることはサポートされていませんが、エラーは発生しません。

大規模管理ゲートウェイの 1 秒あたりの要件

500

小規模管理ゲートウェイの 1 秒あたりの要件

100
### [](#自己管理-flex-gateway-の制限)自己管理 Flex Gateway の制限
制限 値 注意事項

リクエストヘッダー

60 KB

要求がこの制限を超えると、​「431」​応答を受信します。

自己管理ゲートウェイインスタンスごとの API

1,000

この制限を超えることはサポートされていませんが、エラーは発生しません。
## [](#flex-gateway-環境変数)Flex Gateway 環境変数
環境変数 デフォルト値 機能

FLEX_CONNECTION_IDLE_TIMEOUT_SECONDS

60

接続がタイムアウトになるまでアイドル状態を維持できる最大秒数。

FLEX_DOWNSTREAM_CONNECTION_BUFFER_LIMIT_BYTES

1048576 (1 MB)

新しい接続の読み書きバッファの最大サイズ (バイト)。

FLEX_ENVOY_HEADERS_ENABLED

false

Envoy ヘッダーを許可 (​true​) または要求から削除 (​false​) します。

FLEX_STREAM_IDLE_TIMEOUT_SECONDS

300

ストリームがインバウンド (クライアントから Flex Gateway) またはアウトバウンド (Flex Gateway からアップストリームサービス) 方向のデータを受信せずにアイドル状態を続けられる最大秒数。

FLEX_UPSTREAM_CONNECTION_IDLE_TIMEOUT_SECONDS

60

Flex Gateway とアップストリームサービス間のストリームが要求から要求までの間にアイドル状態を続けられる最大秒数。

FLEX_UPSTREAM_RESPONSE_TIMEOUT_SECONDS

15

Flex Gateway がアップストリームサービスからの応答を待機する最大秒数。
### [](#関連情報)関連情報 - [接続モードでのタイムアウトの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-timeout) - [ローカルモードでのタイムアウトの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-timeout) # Flex Gateway の設定 Flex Gateway では、Anypoint Platform または宣言型設定ファイルを介した設定が可能です。接続モードで実行される Flex Gateway は Anypoint Platform と宣言型設定ファイルのどちらを介しても設定できますが、管理 Flex Gateway は Anypoint Platform を使用する方法のみ、ローカルモードで実行される Flex Gateway は設定ファイルを使用する方法のみで設定できます。 設定には、以下が含まれます。 - レプリカ - TLS コンテキスト - 共有ストレージ - 転送プロキシ - 自動化された Jenkins Pipeline - Kubernetes デプロイメントのノード選択 接続モードについては、[接続モードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-configure)を参照してください。 ローカルモードについては、[ローカルモードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configure)を参照してください。 ## [](#関連情報)関連情報 - [管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-configure) - [接続モードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-configure) - [ローカルモードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configure) # Flex Gateway の設定 Flex Gateway では、Anypoint Platform (接続モード) または宣言型設定ファイル (ローカルモード) を介した設定が可能です。設定には、以下が含まれます。 - レプリカ - TLS コンテキスト - 共有ストレージ - 転送プロキシ - 自動化された Jenkins Pipeline - Kubernetes デプロイメントのノード選択 接続モードについては、[接続モードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-configure)を参照してください。 ローカルモードについては、[ローカルモードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configure)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # Flex Gateway の設定 Flex Gateway では、Anypoint Platform または宣言型設定ファイルを介した設定が可能です。接続モードで実行される Flex Gateway は Anypoint Platform と宣言型設定ファイルのどちらを介しても設定できますが、管理 Flex Gateway は Anypoint Platform を使用する方法のみ、ローカルモードで実行される Flex Gateway は設定ファイルを使用する方法のみで設定できます。 設定には、以下が含まれます。 - レプリカ - TLS コンテキスト - 共有ストレージ - 転送プロキシ - 自動化された Jenkins Pipeline - Kubernetes デプロイメントのノード選択 接続モードについては、[接続モードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-configure)を参照してください。 ローカルモードについては、[ローカルモードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configure)を参照してください。 ## [](#関連情報)関連情報 - [管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-configure) - [接続モードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-configure) - [ローカルモードでの Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configure) # Flex Gateway バージョンのライフサイクル Flex Gateway 1.9 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。これらのリリースチャネルは管理 Flex Gateway と自己管理 Flex Gateway の両方に使用できます。 ## [](#flex-gateway-用の-edge-および-lts-リリース)Flex Gateway 用の Edge および LTS リリース このテーブルの情報は、要件に最適なリリースチャネルを決定する際に考慮してください。
チャネル種別 リリースケイデンス 違い サポート対象範囲

Edge​

年 3 回

  • 3 月

  • 7 月

  • 11 月

新機能が含まれる頻度が多く、各リリースのサポート期間が短くなります。

Flex Gateway 1.9 以降

  • 4 か月間の標準サポート

  • 4 か月間の延長サポート

Flex Gateway 1.8 以前

LTS​

年 1 回

  • 3 月

新機能が 1 年ごとのリリースに含まれ、各リリースのサポート期間が長くなります。

Flex Gateway 1.9 以降

  • 12 か月間の標準サポート

  • 12 か月間の延長サポート

Flex Gateway 1.8 以前
Flex Gateway 1.8 以前の詳細およびサポート期間については、 [「MuleSoft Support Policy (MuleSoft サポートポリシー)」](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/versioning-back-support-policy.pdf)​を参照してください。 ## [](#デプロイメントモデルとライフサイクル管理)デプロイメントモデルとライフサイクル管理 Flex Gateway ライフサイクル管理は、リリースチャネルやゲートウェイの種別に応じて異なります。 管理 Flex Gateway インスタンスは定期的に自動アップグレードされ、使用可能なパッチが月に 1 回適用されます。自己管理ゲートウェイは自動ではパッチ適用またはアップグレードされません。
アクション 管理ゲートウェイ 自己管理ゲートウェイ

自動アップグレード

管理ゲートウェイはそれぞれのチャネル (Edge または LTS) 内の最新のマイナーバージョンに自動アップグレードされます。

  • Edge: 年 3 回

  • LTS: 年 1 回

自動アップグレード機能なし

パッチ適用

毎月の自動パッチ適用

それぞれのチャネル (Edge または LTS) のサポート期間内の Flex Gateway バージョンで利用できます。

自己アップグレード

スケジュールされた自動アップグレードより前にリリースチャネル (Edge または LTS) に一致する最新バージョンに手動でアップグレードできます。

常に利用可能

ロールバック

まだリリースチャネルサポート期間内であれば前のバージョンに戻すことができます。

以前に使用していたバージョンに可能

再起動

常時

延長サポートの終了まで

実行維持

常時

延長サポートの終了まで

サポート可能性

標準サポート (管理ゲートウェイが常に最新の Edge または LTS バージョンになるようにする自動アップグレード)。

延長サポートの終了まで。詳細は、 「MuleSoft Support Policy (MuleSoft サポートポリシー)」​を参照してください。
パッチ適用、アップグレード、ロールバック、ゲートウェイの削除については、​[「Maintaining a Flex Gateway (Flex Gateway の保守)」](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-maintain)​を参照してください。 # Flex Gateway バージョンのライフサイクル Flex Gateway 1.9 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。これらのリリースチャネルは管理 Flex Gateway と自己管理 Flex Gateway の両方に使用できます。 ## [](#flex-gateway-用の-edge-および-lts-リリース)Flex Gateway 用の Edge および LTS リリース このテーブルの情報は、要件に最適なリリースチャネルを決定する際に考慮してください。
チャネル種別 リリースケイデンス 違い サポート対象範囲

Edge​

年 3 回

  • 3 月

  • 7 月

  • 11 月

新機能が含まれる頻度が多く、各リリースのサポート期間が短くなります。

Flex Gateway 1.9 以降

  • 4 か月間の標準サポート

  • 4 か月間の延長サポート

Flex Gateway 1.8 以前

LTS​

年 1 回

  • 3 月

新機能が 1 年ごとのリリースに含まれ、各リリースのサポート期間が長くなります。

Flex Gateway 1.9 以降

  • 12 か月間の標準サポート

  • 12 か月間の延長サポート

Flex Gateway 1.8 以前
Flex Gateway 1.8 以前の詳細およびサポート期間については、 [「MuleSoft Support Policy (MuleSoft サポートポリシー)」](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/versioning-back-support-policy.pdf)​を参照してください。 ## [](#デプロイメントモデルとライフサイクル管理)デプロイメントモデルとライフサイクル管理 Flex Gateway ライフサイクル管理は、リリースチャネルやゲートウェイの種別に応じて異なります。 管理 Flex Gateway インスタンスは定期的に自動アップグレードされ、使用可能なパッチが月に 1 回適用されます。自己管理ゲートウェイは自動ではパッチ適用またはアップグレードされません。
アクション 管理ゲートウェイ 自己管理ゲートウェイ

自動アップグレード

管理ゲートウェイはそれぞれのチャネル (Edge または LTS) 内の最新のマイナーバージョンに自動アップグレードされます。

  • Edge: 年 3 回

  • LTS: 年 1 回

自動アップグレード機能なし

パッチ適用

毎月の自動パッチ適用

それぞれのチャネル (Edge または LTS) のサポート期間内の Flex Gateway バージョンで利用できます。

自己アップグレード

スケジュールされた自動アップグレードより前にリリースチャネル (Edge または LTS) に一致する最新バージョンに手動でアップグレードできます。

常に利用可能

ロールバック

まだリリースチャネルサポート期間内であれば前のバージョンに戻すことができます。

以前に使用していたバージョンに可能

再起動

常時

延長サポートの終了まで

実行維持

常時

延長サポートの終了まで

サポート可能性

標準サポート (管理ゲートウェイが常に最新の Edge または LTS バージョンになるようにする自動アップグレード)。

延長サポートの終了まで。詳細は、 「MuleSoft Support Policy (MuleSoft サポートポリシー)」​を参照してください。
パッチ適用、アップグレード、ロールバック、ゲートウェイの削除については、​[「Maintaining a Flex Gateway (Flex Gateway の保守)」](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-maintain)​を参照してください。 # Flex Gateway ポリシーでの DataWeave のサポート [DataWeave](https://docs.mulesoft.com/dataweave/latest/)​ は、MuleSoft がデータ変換用に設計したプログラミング言語です。DataWeave を使用すると、ある形式のデータを読み込んで解析し、データを変換して、異なる形式で書き出すという、よくあるインテグレーション開発者のユースケース向けのシンプルなソリューションを構築できます。 Flex Gateway は、ポリシー設定において DataWeave 式の一部をサポートします。DataWeave は内部ポリシーと PDK を使用して作成されたカスタムポリシーでのみサポートされています。 ## [](#使用できる型)使用できる型 - [`Null`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#null) - `Boolean` - `String` - `Number`​ (64 ビット浮動小数点として処理) - [`Array`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#array-type) - [`Object`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#object-type)​ (反復キーは使用不可) ## [](#型で使用できる値コンストラクター)型で使用できる値コンストラクター - [`Boolean`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_boolean) - [`String`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) - [`Number`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_number) - [`Array`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_array) ## [](#型で使用できない値コンストラクター)型で使用できない値コンストラクター - [`Null`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_null)​ (​`null`​ リテラルの書き込みはサポートされない) - [`Object`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_object)​ (オブジェクトをリテラルとして定義することはできない) ## [](#使用できるフロー制御構造)使用できるフロー制御構造 - [`if else`](https://docs.mulesoft.com/dataweave/latest/dataweave-flow-control#control_flow_if_else) ## [](#使用できないフロー制御構造)使用できないフロー制御構造 - [`do`](https://docs.mulesoft.com/dataweave/latest/dataweave-flow-control#control_flow_do) ## [](#使用できるセレクター)使用できるセレクター - `Array[Number]` - `Array[String]` - `Object[String]` - `String[Number]` ## [](#使用できないセレクター)使用できないセレクター - `Object[Number]` ## [](#使用できる等価演算子と比較演算子)使用できる等価演算子と比較演算子 - [`==`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`!=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`>=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`<=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) ## [](#使用できる論理演算子)使用できる論理演算子 - [`not`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) - [`and`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) - [`or`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) ## [](#available-default-operators)使用できるデフォルト演算子 - [`default`](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-defaults#example-of-using-the-keyword-default-to-set-a-default-value) ## [](#使用できる関数)使用できる関数 ### [](#)`++` - [`++(Array, Array): Array`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-plusplus#plusplus1) - [`++(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-plusplus#plusplus2) ### [](#contains)`contains` - [`contains(Array, Any): Boolean`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-contains#contains1) - [`contains(String, String): Boolean`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-contains#contains2) ### [](#lower)`lower` - [`lower(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-lower#lower1) - [`lower(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-lower#lower2) ### [](#splitby)`splitBy` - [`splitBy(String, String): Array`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-splitby#splitby2) ### [](#sizeof)`sizeOf` - [`sizeOf(Array): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof1) - [`sizeOf(Object): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof2) - [`sizeOf(String): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof4) ### [](#trim)`trim` - [`trim(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-trim#trim1) - [`trim(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-trim#trim2) ### [](#upper)`upper` - [`upper(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-upper#upper1) - [`upper(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-upper#upper2) ### [](#uuid)`uuid` - [`uuid(): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-uuid#uuid1) ### [](#dwcorestringssubstringafter)`dw::core::Strings::substringAfter` - [`substringAfter(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafter#substringafter1) - [`substringAfter(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafter#substringafter2) ### [](#dwcorestringssubstringafterlast)`dw::core::Strings::substringAfterLast` - [`substringAfterLast(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafterlast#substringafterlast1) - [`substringAfterLast(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafterlast#substringafterlast2) ### [](#dwcorestringssubstringbefore)`dw::core::Strings::substringBefore` - [`substringBefore(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbefore#substringbefore1) - [`substringBefore(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbefore#substringbefore2) ### [](#dwcorestringssubstringbeforelast)`dw::core::Strings::substringBeforeLast` - [`substringBeforeLast(text: String, separator: String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbeforelast#substringbeforelast1) - [`substringBeforeLast(text: Null, separator: String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbeforelast#substringbeforelast2) ### [](#tobase64)toBase64 - [`toBase64(content: Binary): String`](https://docs.mulesoft.com/dataweave/latest/dw-binaries-functions-tobase64#tobase641) ### [](#frombase64)fromBase64 - [`fromBase64(base64String: String): Binary`](https://docs.mulesoft.com/dataweave/latest/dw-binaries-functions-frombase64#frombase641)

Flex Gateway では、バイナリ型の結果を伴う DataWeave 式はサポートされません。​dw::Binaries::fromBase64('dXNlcjpwYXNz')​ 関数を使用するには、結果を文字列に変換してください。​dw::util::Coercions::toString(binary: Binary, encoding: String): String​ 関数を使用してバイナリ出力を文字列に変換します。たとえば、​[dw::util::Coercions::toString(dw::core::Binaries::fromBase64('dXNlcjpwYXNz'), 'UTF-8')]​ となります。 デフォルトで ​[splitBy(dw::core::Binaries::fromBase64('dXNlcjpwYXNz'), ':')]​ などのバイナリを変換する別の関数を使用している場合は、バイナリの手動変換をスキップできます。
### [](#tobinary)toBinary - [`toBinary(str: String, encoding: String): Binary`](https://docs.mulesoft.com/dataweave/latest/dw-coercions-functions-tobinary#tobinary1) ### [](#tostring)toString - [`toString(binary: Binary, encoding: String): String`](https://docs.mulesoft.com/dataweave/latest/dw-coercions-functions-tostring#tostring3) ## [](#available-predefined-variables)使用できる定義済み変数 - [`attributes`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `attributes.headers` - `attributes.method`​ (要求コンテキストでのみ使用可能) - `attributes.queryParams`​ (要求コンテキストでのみ使用可能) - `attributes.queryString`​ (要求コンテキストでのみ使用可能) - `attributes.requestPath`​ (要求コンテキストでのみ使用可能) - `attributes.requestUri`​ (要求コンテキストでのみ使用可能) - `attributes.localAddress`​ (要求コンテキストでのみ使用可能) - `attributes.remoteAddress`​ (要求コンテキストでのみ使用可能) - `attributes.scheme`​ (要求コンテキストでのみ使用可能) - `attributes.version`​ (要求コンテキストでのみ使用可能) - `attributes.statusCode`​ (応答コンテキストでのみ使用可能) - [`authentication`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `authentication.clientId` - `authentication.clientName` - `authentication.principal` - `authentication.properties` - `payload` - 項目は現在のペイロードに応じて異なります。たとえば、​`#[payload]`​ はメッセージの本文を返します。 - [`vars`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - 個々のポリシーでサポートされる変数のセットは異なります。詳細は、[policies-includeed-directory.adoc](#policies-includeed-directory.adoc)にリストされたポリシーを参照してください。 # Flex Gateway ポリシーでの DataWeave のサポート [DataWeave](https://docs.mulesoft.com/dataweave/latest/)​ は、MuleSoft がデータ変換用に設計したプログラミング言語です。DataWeave を使用すると、ある形式のデータを読み込んで解析し、データを変換して、異なる形式で書き出すという、よくあるインテグレーション開発者のユースケース向けのシンプルなソリューションを構築できます。 Flex Gateway は、ポリシー設定において DataWeave 式の一部をサポートします。DataWeave は内部ポリシーと PDK を使用して作成されたカスタムポリシーでのみサポートされています。 ## [](#使用できる型)使用できる型 - [`Null`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#null) - `Boolean` - `String` - `Number`​ (64 ビット浮動小数点として処理) - [`Array`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#array-type) - [`Object`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#object-type)​ (反復キーは使用不可) ## [](#型で使用できる値コンストラクター)型で使用できる値コンストラクター - [`Boolean`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_boolean) - [`String`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) - [`Number`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_number) - [`Array`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_array) ## [](#型で使用できない値コンストラクター)型で使用できない値コンストラクター - [`Null`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_null)​ (​`null`​ リテラルの書き込みはサポートされない) - [`Object`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_object)​ (オブジェクトをリテラルとして定義することはできない) ## [](#使用できるフロー制御構造)使用できるフロー制御構造 - [`if else`](https://docs.mulesoft.com/dataweave/latest/dataweave-flow-control#control_flow_if_else) ## [](#使用できないフロー制御構造)使用できないフロー制御構造 - [`do`](https://docs.mulesoft.com/dataweave/latest/dataweave-flow-control#control_flow_do) ## [](#使用できるセレクター)使用できるセレクター - `Array[Number]` - `Array[String]` - `Object[String]` - `String[Number]` ## [](#使用できないセレクター)使用できないセレクター - `Object[Number]` ## [](#使用できる等価演算子と比較演算子)使用できる等価演算子と比較演算子 - [`==`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`!=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`>=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`<=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) ## [](#使用できる論理演算子)使用できる論理演算子 - [`not`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) - [`and`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) - [`or`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) ## [](#available-default-operators)使用できるデフォルト演算子 - [`default`](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-defaults#example-of-using-the-keyword-default-to-set-a-default-value) ## [](#使用できる関数)使用できる関数 ### [](#)`++` - [`++(Array, Array): Array`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-plusplus#plusplus1) - [`++(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-plusplus#plusplus2) ### [](#contains)`contains` - [`contains(Array, Any): Boolean`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-contains#contains1) - [`contains(String, String): Boolean`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-contains#contains2) ### [](#lower)`lower` - [`lower(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-lower#lower1) - [`lower(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-lower#lower2) ### [](#splitby)`splitBy` - [`splitBy(String, String): Array`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-splitby#splitby2) ### [](#sizeof)`sizeOf` - [`sizeOf(Array): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof1) - [`sizeOf(Object): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof2) - [`sizeOf(String): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof4) ### [](#trim)`trim` - [`trim(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-trim#trim1) - [`trim(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-trim#trim2) ### [](#upper)`upper` - [`upper(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-upper#upper1) - [`upper(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-upper#upper2) ### [](#uuid)`uuid` - [`uuid(): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-uuid#uuid1) ### [](#dwcorestringssubstringafter)`dw::core::Strings::substringAfter` - [`substringAfter(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafter#substringafter1) - [`substringAfter(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafter#substringafter2) ### [](#dwcorestringssubstringafterlast)`dw::core::Strings::substringAfterLast` - [`substringAfterLast(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafterlast#substringafterlast1) - [`substringAfterLast(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafterlast#substringafterlast2) ### [](#dwcorestringssubstringbefore)`dw::core::Strings::substringBefore` - [`substringBefore(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbefore#substringbefore1) - [`substringBefore(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbefore#substringbefore2) ### [](#dwcorestringssubstringbeforelast)`dw::core::Strings::substringBeforeLast` - [`substringBeforeLast(text: String, separator: String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbeforelast#substringbeforelast1) - [`substringBeforeLast(text: Null, separator: String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbeforelast#substringbeforelast2) ## [](#available-predefined-variables)使用できる定義済み変数 - [`attributes`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `attributes.headers` - `attributes.method`​ (要求コンテキストでのみ使用可能) - `attributes.queryParams`​ (要求コンテキストでのみ使用可能) - `attributes.queryString`​ (要求コンテキストでのみ使用可能) - `attributes.requestPath`​ (要求コンテキストでのみ使用可能) - `attributes.requestUri`​ (要求コンテキストでのみ使用可能) - `attributes.localAddress`​ (要求コンテキストでのみ使用可能) - `attributes.remoteAddress`​ (要求コンテキストでのみ使用可能) - `attributes.scheme`​ (要求コンテキストでのみ使用可能) - `attributes.version`​ (要求コンテキストでのみ使用可能) - `attributes.statusCode`​ (応答コンテキストでのみ使用可能) - [`authentication`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `authentication.clientId` - `authentication.clientName` - `authentication.principal` - `authentication.properties` - [`payload`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `payload` - [`vars`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - 個々のポリシーでサポートされる変数のセットは異なります。詳細は、[policies-includeed-directory.adoc](#policies-includeed-directory.adoc)にリストされたポリシーを参照してください。 # Flex Gateway ポリシーでの DataWeave のサポート [DataWeave](https://docs.mulesoft.com/dataweave/latest/)​ は、MuleSoft がデータ変換用に設計したプログラミング言語です。DataWeave を使用すると、ある形式のデータを読み込んで解析し、データを変換して、異なる形式で書き出すという、よくあるインテグレーション開発者のユースケース向けのシンプルなソリューションを構築できます。 Flex Gateway は、ポリシー設定において DataWeave 式の一部をサポートします。DataWeave は内部ポリシーと PDK を使用して作成されたカスタムポリシーでのみサポートされています。 ## [](#使用できる型)使用できる型 - [`Null`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#null) - `Boolean` - `String` - `Number`​ (64 ビット浮動小数点として処理) - [`Array`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#array-type) - [`Object`](https://docs.mulesoft.com/dataweave/latest/dataweave-type-system#object-type)​ (反復キーは使用不可) ## [](#型で使用できる値コンストラクター)型で使用できる値コンストラクター - [`Boolean`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_boolean) - [`String`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_string) - [`Number`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_number) - [`Array`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_array) ## [](#型で使用できない値コンストラクター)型で使用できない値コンストラクター - [`Null`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_null)​ (​`null`​ リテラルの書き込みはサポートされない) - [`Object`](https://docs.mulesoft.com/dataweave/latest/dataweave-types#dw_type_object)​ (オブジェクトをリテラルとして定義することはできない) ## [](#使用できるフロー制御構造)使用できるフロー制御構造 - [`if else`](https://docs.mulesoft.com/dataweave/latest/dataweave-flow-control#control_flow_if_else) ## [](#使用できないフロー制御構造)使用できないフロー制御構造 - [`do`](https://docs.mulesoft.com/dataweave/latest/dataweave-flow-control#control_flow_do) ## [](#使用できるセレクター)使用できるセレクター - `Array[Number]` - `Array[String]` - `Object[String]` - `String[Number]` ## [](#使用できないセレクター)使用できないセレクター - `Object[Number]` ## [](#使用できる等価演算子と比較演算子)使用できる等価演算子と比較演算子 - [`==`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`!=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`>=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) - [`<=`](https://docs.mulesoft.com/dataweave/latest/dw-operators#equality-and-relational-operators) ## [](#使用できる論理演算子)使用できる論理演算子 - [`not`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) - [`and`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) - [`or`](https://docs.mulesoft.com/dataweave/latest/dw-operators#logical_operators) ## [](#available-default-operators)使用できるデフォルト演算子 - [`default`](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-defaults#example-of-using-the-keyword-default-to-set-a-default-value) ## [](#使用できる関数)使用できる関数 ### [](#)`++` - [`++(Array, Array): Array`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-plusplus#plusplus1) - [`++(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-plusplus#plusplus2) ### [](#contains)`contains` - [`contains(Array, Any): Boolean`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-contains#contains1) - [`contains(String, String): Boolean`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-contains#contains2) ### [](#lower)`lower` - [`lower(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-lower#lower1) - [`lower(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-lower#lower2) ### [](#splitby)`splitBy` - [`splitBy(String, String): Array`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-splitby#splitby2) ### [](#sizeof)`sizeOf` - [`sizeOf(Array): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof1) - [`sizeOf(Object): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof2) - [`sizeOf(String): Number`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-sizeof#sizeof4) ### [](#trim)`trim` - [`trim(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-trim#trim1) - [`trim(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-trim#trim2) ### [](#upper)`upper` - [`upper(String): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-upper#upper1) - [`upper(Null): Null`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-upper#upper2) ### [](#uuid)`uuid` - [`uuid(): String`](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-uuid#uuid1) ### [](#dwcorestringssubstringafter)`dw::core::Strings::substringAfter` - [`substringAfter(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafter#substringafter1) - [`substringAfter(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafter#substringafter2) ### [](#dwcorestringssubstringafterlast)`dw::core::Strings::substringAfterLast` - [`substringAfterLast(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafterlast#substringafterlast1) - [`substringAfterLast(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringafterlast#substringafterlast2) ### [](#dwcorestringssubstringbefore)`dw::core::Strings::substringBefore` - [`substringBefore(String, String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbefore#substringbefore1) - [`substringBefore(Null, String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbefore#substringbefore2) ### [](#dwcorestringssubstringbeforelast)`dw::core::Strings::substringBeforeLast` - [`substringBeforeLast(text: String, separator: String): String`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbeforelast#substringbeforelast1) - [`substringBeforeLast(text: Null, separator: String): Null`](https://docs.mulesoft.com/dataweave/latest/dw-strings-functions-substringbeforelast#substringbeforelast2) ## [](#available-predefined-variables)使用できる定義済み変数 - [`attributes`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `attributes.headers` - `attributes.method`​ (要求コンテキストでのみ使用可能) - `attributes.queryParams`​ (要求コンテキストでのみ使用可能) - `attributes.queryString`​ (要求コンテキストでのみ使用可能) - `attributes.requestPath`​ (要求コンテキストでのみ使用可能) - `attributes.requestUri`​ (要求コンテキストでのみ使用可能) - `attributes.localAddress`​ (要求コンテキストでのみ使用可能) - `attributes.remoteAddress`​ (要求コンテキストでのみ使用可能) - `attributes.scheme`​ (要求コンテキストでのみ使用可能) - `attributes.version`​ (要求コンテキストでのみ使用可能) - `attributes.statusCode`​ (応答コンテキストでのみ使用可能) - [`authentication`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - `authentication.clientId` - `authentication.clientName` - `authentication.principal` - `authentication.properties` - `payload` - 要求本文を文字列として読み取るには ​`payload`​ 変数を使用します。この変数は解析できません。 - [`vars`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) - 個々のポリシーでサポートされる変数のセットは異なります。詳細は、[policies-includeed-directory.adoc](#policies-includeed-directory.adoc)にリストされたポリシーを参照してください。 # Flex Gateway レプリカの自動スケーリングおよび名前空間への追加 高可用性 (HA) 環境では、水平スケーリングにより負荷が複数の Flex Gateway インスタンスに分散されます。デフォルトでは、Flex Gateway の Helm チャートは 1 つのレプリカで設定されます。より多くの Flex Gateway レプリカを名前空間にリリースするには、次のいずれかの設定を提供します。 - [レプリカ数を設定する](#replica-count)​: 作成する Flex Gateway レプリカの固定数を設定します。 - [自動スケーリングを設定する](#autoscale)​: CPU、メモリ、およびその他の設定に基づいてレプリカを自動的に生成します。 次のいずれかの方法で、Flex Gateway (flex-gateway) のデフォルトの Helm チャート設定を見つけます。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行する (例: `helm show values flex-gateway/flex-gateway`​)。 ## [](#始める前に)始める前に 次の前提条件が準備されていることを確認します。 - Flex Gateway デプロイメントまたは登録済み Flex Gateway インスタンス (ゲートウェイ) ゲートウェイの登録およびデプロイメントプロセスについては、​[自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) or [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started)​を参照してください。 - Flex Gateway デプロイメント用の Kubernetes クラスター ## [](#replica-count)レプリカ数を設定する 必要なレプリカの数を設定して検証します。新しいレプリカで既存のレプリカは置き換えられます。Flex Gateway の新しいバージョンが使用可能な場合、このコマンドにより古いレプリカバージョンが最新バージョンに置き換えられます。 実行する手順は、Helm チャートがインストールされているかどうかにより異なります。 1. 名前空間の Helm チャートがインストールされている場合、次のコマンドを実行します。 構文: helm -n upgrade \\ / \\ --reuse-values \\ --set replicaCount= 例: ```helm helm -n gateway upgrade \ ingress flex-gateway/flex-gateway \ --reuse-values \ --set replicaCount=2 ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Apr 17 15:00:09 2023 NAMESPACE: gateway STATUS: deployed REVISION: 27 TEST SUITE: None 2. Helm チャートがインストールされていない場合、次のコマンドを実行します。 構文: helm -n \\ upgrade -i --create-namespace \\ / \\ --set-file registration.content= \\ --set replicaCount= 例: ```helm helm -n gateway \ upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml \ --set replicaCount=2 ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Apr 17 15:32:50 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 3. 次のコマンドを実行して、レプリカの作成を検証します。 構文: kubectl get rs -n 例: kubectl get rs -n gateway 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 NAME DESIRED CURRENT READY AGE ingress-5b7474b8f6 2 2 2 70s ## [](#autoscale)自動スケーリングを設定する 水平ポッド自動スケーリングでは、CPU、メモリ、および対象と動作に関するその他の設定に基づいて Flex Gateway レプリカが自動的に生成されます。これらの設定についての詳細は、​[自動スケーリングパラメーター](#autoscaling-parameters)​を参照してください。 ### [](#autoscaling-config)自動スケーリング設定を使用した Helm チャートの更新 自動スケーリングパラメーターを使用して Helm チャートを更新する手順は、次のとおりです。 1. 自動スケーリング設定を使用して YAML ファイルを作成し、要件に合わせて設定を変更します。 例: ```yaml autoscaling: enabled: true ```
この設定ファイルは最小限の自動スケーリング設定です。より詳細な自動スケーリングを設定するには、​自動スケーリングパラメーター​を参照してください。
2. 名前空間の Helm チャートがインストールされている場合、次のコマンドを実行して自動スケーリング設定を適用します。 構文: helm -n upgrade \\ / \\ --reuse-values \\ -f 例: ```helm helm -n gateway upgrade \ ingress flex-gateway/flex-gateway \ --reuse-values \ -f autoscaling.yaml ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Tue Apr 18 15:46:38 2023 NAMESPACE: gateway STATUS: deployed REVISION: 33 TEST SUITE: None 3. Helm チャートがインストールされていない場合、次のコマンドを実行して自動スケーリング設定を適用します。 構文: helm -n \\ upgrade -i --create-namespace \\ / \\ --set-file registration.content= \\ -f 例: ```helm helm -n gateway \ upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml \ -f autoscaling.yaml ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 NAME: ingress LAST DEPLOYED: Tue Apr 18 15:50:29 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 4. 次のコマンドを実行して、自動スケーリング設定を検証します。 構文: ```kubectl kubectl get hpa -n ``` 例: ```kubectl kubectl get hpa -n gateway ``` このコマンドでは次の例のような出力が印刷されます。 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE ingress Deployment/ingress 66%/50%, 5%/50% 2 11 2 59s ### [](#autoscaling-parameters)自動スケーリングパラメーター 自動スケーリングを使用するには、Horizontal Pod Autoscaler (HPA) を有効にして、自動スケーリング動作を定義するための他の Helm チャート設定を定義します。
パラメーター 説明

autoscaling.enabled

Horizontal Pod Autoscaler (HPA) が有効であるかどうかを示すブール値。デフォルトは ​false​ です。

autoscaling.minReplicas

HPA スケーラーが作成できるレプリカの最小数。デフォルトは ​2​ です。

autoscaling.maxReplicas

HPA スケーラーが作成できるレプリカの最大数。デフォルトは ​11​ です。

autoscaling.targetCPUUtilizationPercentage

デプロイされているすべてのポッドの平均 CPU 使用率を設定するリソースメトリクス。デフォルトは ​50​ です。

autoscaling.targetMemoryUtilizationPercentage

デプロイされているすべてのポッドの平均メモリ使用率を表す文字列。デフォルトは ​nil​ です。

autoscaling.behavior

Kubernetes で ​HorizontalPodAutoscaler​ (HPA) オブジェクトをサポートする設定。HPA 設定では、ワークロードの変更の割合に基づいてアプリケーションリソース数などの自動スケーリング動作を制御します。

autoscaling.behavior.scaleUp​、​autoscaling.behavior.scaleDown

HPA スケーラーでレプリカ数を増加 (​scaleUp​) または減少 (​scaleDown​) する場合の自動スケーリング動作の設定。ネストされたパラメーターを使用してスケーリング動作を定義します。

  • selectPolicy​: スケーリングが必要であることが設定済みリソースのメトリクスで示された場合、この設定でポッドをスケーリングするタイミングを決定します。ポッドにはさまざまな数のレプリカが含まれる可能性があるため、この設定が必要です。有効な値は ​Disabled (無効)​、​Min (最小)​、​Max (最大)​ です。 デフォルトは ​Max (最大)​ です。 ​Min (最小)​ と ​Max (最大)​ の値は、レプリカの最小数 (​Min​) または最大数 (​Max​) のどちらでポッドをスケーリングするかを示します。

  • stabilizationWindowSeconds​: ワークロードの変更後にアプリケーションを再スケーリングするまで待機する最小時間 (秒数)。目的は、スケーリングの頻度が高すぎる場合に HPA による過度に積極的な応答や不安定な応答を回避することです。

  • policies​: スケーリング動作を決定するポリシーのリスト。

    • type​: 特定のポリシーの値の種別 ([Percent (パーセント)] または [Pods (ポッド)])。

    • value​: 特定のポリシーの種別の値。

    • periodSeconds​: 特定のポリシーのスケーリング操作間の時間 (秒数)。
自動スケーリングについての詳細は [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​を参照してください。 # Flex Gateway レプリカの自動スケーリングおよび名前空間への追加 高可用性 (HA) 環境では、水平スケーリングにより負荷が複数の Flex Gateway インスタンスに分散されます。デフォルトでは、Flex Gateway の Helm チャートは 1 つのレプリカで設定されます。より多くの Flex Gateway レプリカを名前空間にリリースするには、次のいずれかの設定を提供します。 - [レプリカ数を設定する](#replica-count)​: 作成する Flex Gateway レプリカの固定数を設定します。 - [自動スケーリングを設定する](#autoscale)​: CPU、メモリ、およびその他の設定に基づいてレプリカを自動的に生成します。 次のいずれかの方法で、Flex Gateway (flex-gateway) のデフォルトの Helm チャート設定を見つけます。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行する (例: `helm show values flex-gateway/flex-gateway`​)。 ## [](#始める前に)始める前に 次の前提条件が準備されていることを確認します。 - Flex Gateway デプロイメントまたは登録済み Flex Gateway インスタンス (ゲートウェイ) ゲートウェイの登録およびデプロイメントプロセスについては、​[Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) or [Kubernetes クラスターでの Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-getting-started)​を参照してください。 - Flex Gateway デプロイメント用の Kubernetes クラスター ## [](#replica-count)レプリカ数を設定する 必要なレプリカの数を設定して検証します。新しいレプリカで既存のレプリカは置き換えられます。Flex Gateway の新しいバージョンが使用可能な場合、このコマンドにより古いレプリカバージョンが最新バージョンに置き換えられます。 実行する手順は、Helm チャートがインストールされているかどうかにより異なります。 1. 名前空間の Helm チャートがインストールされている場合、次のコマンドを実行します。 構文: helm -n upgrade \\ / \\ --reuse-values \\ --set replicaCount= 例: ```helm helm -n gateway upgrade \ ingress flex-gateway/flex-gateway \ --reuse-values \ --set replicaCount=2 ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Apr 17 15:00:09 2023 NAMESPACE: gateway STATUS: deployed REVISION: 27 TEST SUITE: None 2. Helm チャートがインストールされていない場合、次のコマンドを実行します。 構文: helm -n \\ upgrade -i --create-namespace \\ / \\ --set-file registration.content= \\ --set replicaCount= 例: ```helm helm -n gateway \ upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml \ --set replicaCount=2 ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Apr 17 15:32:50 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 3. 次のコマンドを実行して、レプリカの作成を検証します。 構文: kubectl get rs -n 例: kubectl get rs -n gateway 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 NAME DESIRED CURRENT READY AGE ingress-5b7474b8f6 2 2 2 70s ## [](#autoscale)自動スケーリングを設定する 水平ポッド自動スケーリングでは、CPU、メモリ、および対象と動作に関するその他の設定に基づいて Flex Gateway レプリカが自動的に生成されます。これらの設定についての詳細は、​[自動スケーリングパラメーター](#autoscaling-parameters)​を参照してください。 ### [](#autoscaling-config)自動スケーリング設定を使用した Helm チャートの更新 自動スケーリングパラメーターを使用して Helm チャートを更新する手順は、次のとおりです。 1. 自動スケーリング設定を使用して YAML ファイルを作成し、要件に合わせて設定を変更します。 例: ```yaml autoscaling: enabled: true ```
この設定ファイルは最小限の自動スケーリング設定です。より詳細な自動スケーリングを設定するには、​自動スケーリングパラメーター​を参照してください。
2. 名前空間の Helm チャートがインストールされている場合、次のコマンドを実行して自動スケーリング設定を適用します。 構文: helm -n upgrade \\ / \\ --reuse-values \\ -f 例: ```helm helm -n gateway upgrade \ ingress flex-gateway/flex-gateway \ --reuse-values \ -f autoscaling.yaml ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Tue Apr 18 15:46:38 2023 NAMESPACE: gateway STATUS: deployed REVISION: 33 TEST SUITE: None 3. Helm チャートがインストールされていない場合、次のコマンドを実行して自動スケーリング設定を適用します。 構文: helm -n \\ upgrade -i --create-namespace \\ / \\ --set-file registration.content= \\ -f 例: ```helm helm -n gateway \ upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml \ -f autoscaling.yaml ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 NAME: ingress LAST DEPLOYED: Tue Apr 18 15:50:29 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 4. 次のコマンドを実行して、自動スケーリング設定を検証します。 構文: ```kubectl kubectl get hpa -n ``` 例: ```kubectl kubectl get hpa -n gateway ``` このコマンドでは次の例のような出力が印刷されます。 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE ingress Deployment/ingress 66%/50%, 5%/50% 2 11 2 59s ### [](#autoscaling-parameters)自動スケーリングパラメーター 自動スケーリングを使用するには、Horizontal Pod Autoscaler (HPA) を有効にして、自動スケーリング動作を定義するための他の Helm チャート設定を定義します。
パラメーター 説明

autoscaling.enabled

Horizontal Pod Autoscaler (HPA) が有効であるかどうかを示すブール値。デフォルトは ​false​ です。

autoscaling.minReplicas

HPA スケーラーが作成できるレプリカの最小数。デフォルトは ​2​ です。

autoscaling.maxReplicas

HPA スケーラーが作成できるレプリカの最大数。デフォルトは ​11​ です。

autoscaling.targetCPUUtilizationPercentage

デプロイされているすべてのポッドの平均 CPU 使用率を設定するリソースメトリクス。デフォルトは ​50​ です。

autoscaling.targetMemoryUtilizationPercentage

デプロイされているすべてのポッドの平均メモリ使用率を表す文字列。デフォルトは ​nil​ です。

autoscaling.behavior

Kubernetes で ​HorizontalPodAutoscaler​ (HPA) オブジェクトをサポートする設定。HPA 設定では、ワークロードの変更の割合に基づいてアプリケーションリソース数などの自動スケーリング動作を制御します。

autoscaling.behavior.scaleUp, ​autoscaling.behavior.scaleDown

HPA スケーラーでレプリカ数を増加 (​scaleUp​) または減少 (​scaleDown​) する場合の自動スケーリング動作の設定。ネストされたパラメーターを使用してスケーリング動作を定義します。

  • selectPolicy​: スケーリングが必要であることが設定済みリソースのメトリクスで示された場合、この設定でポッドをスケーリングするタイミングを決定します。ポッドにはさまざまな数のレプリカが含まれる可能性があるため、この設定が必要です。有効な値は、​Disabled (無効)​、​Min (最小)​、​Max (最大)​ です。デフォルトは ​Max (最大)​ です。 ​Min (最小)​ と ​Max (最大)​ の値は、レプリカの最小数 (​Min​) または最大数 (​Max​) のどちらでポッドをスケーリングするかを示します。

  • stabilizationWindowSeconds​: ワークロードの変更後にアプリケーションを再スケーリングするまで待機する最小時間 (秒数)。目的は、スケーリングの頻度が高すぎる場合に HPA による過度に積極的な応答や不安定な応答を回避することです。

  • policies​: スケーリング動作を決定するポリシーのリスト。

    • type​: 特定のポリシーの値の種別 ([Percent (パーセント)] または [Pods (ポッド)])。

    • value​: 特定のポリシーの種別の値。

    • periodSeconds​: 特定のポリシーのスケーリング操作間の時間 (秒数)。
自動スケーリングについての詳細は [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​を参照してください。 # Flex Gateway レプリカの自動スケーリングおよび名前空間への追加 高可用性 (HA) 環境では、水平スケーリングにより負荷が複数の Flex Gateway インスタンスに分散されます。デフォルトでは、Flex Gateway の Helm チャートは 1 つのレプリカで設定されます。より多くの Flex Gateway レプリカを名前空間にリリースするには、次のいずれかの設定を提供します。 - [レプリカ数を設定する](#replica-count)​: 作成する Flex Gateway レプリカの固定数を設定します。 - [自動スケーリングを設定する](#autoscale)​: CPU、メモリ、およびその他の設定に基づいてレプリカを自動的に生成します。 次のいずれかの方法で、Flex Gateway (flex-gateway) のデフォルトの Helm チャート設定を見つけます。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行する (例: `helm show values flex-gateway/flex-gateway`​)。 ## [](#始める前に)始める前に 次の前提条件が準備されていることを確認します。 - Flex Gateway デプロイメントまたは登録済み Flex Gateway インスタンス (ゲートウェイ) ゲートウェイの登録およびデプロイメントプロセスについては、​[自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) or [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started)​を参照してください。 - Flex Gateway デプロイメント用の Kubernetes クラスター ## [](#replica-count)レプリカ数を設定する 必要なレプリカの数を設定して検証します。新しいレプリカで既存のレプリカは置き換えられます。Flex Gateway の新しいバージョンが使用可能な場合、このコマンドにより古いレプリカバージョンが最新バージョンに置き換えられます。 実行する手順は、Helm チャートがインストールされているかどうかにより異なります。 1. 名前空間の Helm チャートがインストールされている場合、次のコマンドを実行します。 構文: helm -n upgrade \\ / \\ --reuse-values \\ --set replicaCount= 例: ```helm helm -n gateway upgrade \ ingress flex-gateway/flex-gateway \ --reuse-values \ --set replicaCount=2 ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Apr 17 15:00:09 2023 NAMESPACE: gateway STATUS: deployed REVISION: 27 TEST SUITE: None 2. Helm チャートがインストールされていない場合、次のコマンドを実行します。 構文: helm -n \\ upgrade -i --create-namespace \\ / \\ --set-file registration.content= \\ --set replicaCount= 例: ```helm helm -n gateway \ upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml \ --set replicaCount=2 ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Apr 17 15:32:50 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 3. 次のコマンドを実行して、レプリカの作成を検証します。 構文: kubectl get rs -n 例: kubectl get rs -n gateway 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 NAME DESIRED CURRENT READY AGE ingress-5b7474b8f6 2 2 2 70s ## [](#autoscale)自動スケーリングを設定する 水平ポッド自動スケーリングでは、CPU、メモリ、および対象と動作に関するその他の設定に基づいて Flex Gateway レプリカが自動的に生成されます。これらの設定についての詳細は、​[自動スケーリングパラメーター](#autoscaling-parameters)​を参照してください。 ### [](#autoscaling-config)自動スケーリング設定を使用した Helm チャートの更新 自動スケーリングパラメーターを使用して Helm チャートを更新する手順は、次のとおりです。 1. 自動スケーリング設定を使用して YAML ファイルを作成し、要件に合わせて設定を変更します。 例: ```yaml autoscaling: enabled: true ```
この設定ファイルは最小限の自動スケーリング設定です。より詳細な自動スケーリングを設定するには、​自動スケーリングパラメーター​を参照してください。
2. 名前空間の Helm チャートがインストールされている場合、次のコマンドを実行して自動スケーリング設定を適用します。 構文: helm -n upgrade \\ / \\ --reuse-values \\ -f 例: ```helm helm -n gateway upgrade \ ingress flex-gateway/flex-gateway \ --reuse-values \ -f autoscaling.yaml ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Tue Apr 18 15:46:38 2023 NAMESPACE: gateway STATUS: deployed REVISION: 33 TEST SUITE: None 3. Helm チャートがインストールされていない場合、次のコマンドを実行して自動スケーリング設定を適用します。 構文: helm -n \\ upgrade -i --create-namespace \\ / \\ --set-file registration.content= \\ -f 例: ```helm helm -n gateway \ upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml \ -f autoscaling.yaml ``` 正常に終了すると、このコマンドでは次の例のような出力が印刷されます。 NAME: ingress LAST DEPLOYED: Tue Apr 18 15:50:29 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 4. 次のコマンドを実行して、自動スケーリング設定を検証します。 構文: ```kubectl kubectl get hpa -n ``` 例: ```kubectl kubectl get hpa -n gateway ``` このコマンドでは次の例のような出力が印刷されます。 NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE ingress Deployment/ingress 66%/50%, 5%/50% 2 11 2 59s ### [](#autoscaling-parameters)自動スケーリングパラメーター 自動スケーリングを使用するには、Horizontal Pod Autoscaler (HPA) を有効にして、自動スケーリング動作を定義するための他の Helm チャート設定を定義します。
パラメーター 説明

autoscaling.enabled

Horizontal Pod Autoscaler (HPA) が有効であるかどうかを示すブール値。デフォルトは ​false​ です。

autoscaling.minReplicas

HPA スケーラーが作成できるレプリカの最小数。デフォルトは ​2​ です。

autoscaling.maxReplicas

HPA スケーラーが作成できるレプリカの最大数。デフォルトは ​11​ です。

autoscaling.targetCPUUtilizationPercentage

デプロイされているすべてのポッドの平均 CPU 使用率を設定するリソースメトリクス。デフォルトは ​50​ です。

autoscaling.targetMemoryUtilizationPercentage

デプロイされているすべてのポッドの平均メモリ使用率を表す文字列。デフォルトは ​nil​ です。

autoscaling.behavior

Kubernetes で ​HorizontalPodAutoscaler​ (HPA) オブジェクトをサポートする設定。HPA 設定では、ワークロードの変更の割合に基づいてアプリケーションリソース数などの自動スケーリング動作を制御します。

autoscaling.behavior.scaleUp​、​autoscaling.behavior.scaleDown

HPA スケーラーでレプリカ数を増加 (​scaleUp​) または減少 (​scaleDown​) する場合の自動スケーリング動作の設定。ネストされたパラメーターを使用してスケーリング動作を定義します。

  • selectPolicy​: スケーリングが必要であることが設定済みリソースのメトリクスで示された場合、この設定でポッドをスケーリングするタイミングを決定します。ポッドにはさまざまな数のレプリカが含まれる可能性があるため、この設定が必要です。有効な値は ​Disabled (無効)​、​Min (最小)​、​Max (最大)​ です。 デフォルトは ​Max (最大)​ です。 ​Min (最小)​ と ​Max (最大)​ の値は、レプリカの最小数 (​Min​) または最大数 (​Max​) のどちらでポッドをスケーリングするかを示します。

  • stabilizationWindowSeconds​: ワークロードの変更後にアプリケーションを再スケーリングするまで待機する最小時間 (秒数)。目的は、スケーリングの頻度が高すぎる場合に HPA による過度に積極的な応答や不安定な応答を回避することです。

  • policies​: スケーリング動作を決定するポリシーのリスト。

    • type​: 特定のポリシーの値の種別 ([Percent (パーセント)] または [Pods (ポッド)])。

    • value​: 特定のポリシーの種別の値。

    • periodSeconds​: 特定のポリシーのスケーリング操作間の時間 (秒数)。
自動スケーリングについての詳細は [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​を参照してください。 # Flex Gateway 参照アーキテクチャ 次のアーキテクチャ図では、Flex Gateway の概念とデプロイメントについて説明します。 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-basic-deployments) - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc-overview) - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc4) - [Flex Gateway の複数リージョンデプロイメント](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-multi-region) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-shared-storage) # Flex Gateway 参照アーキテクチャ 次のアーキテクチャ図では、Flex Gateway の概念とデプロイメントについて説明します。 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-basic-deployments) - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc-overview) - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc4) - [Flex Gateway の複数リージョンデプロイメント](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-multi-region) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-shared-storage) # Flex Gateway 参照アーキテクチャ 次のアーキテクチャ図では、Flex Gateway の概念とデプロイメントについて説明します。 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-basic-deployments) - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc-overview) - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc4) - [Flex Gateway の複数リージョンデプロイメント](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-multi-region) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-shared-storage) # Helm コマンドの問題のトラブルシューティング Kubernetes および OpenShift クラスターの ​`helm`​ コマンドで返されるエラーのトラブルシューティング - [アップグレードに失敗する: 例外エラー](#troubleshoot-helm-yaml-empty) - [Kubernetes クラスターに到達できない](#troubleshoot-helm-cluster-unreachable) - [アップグレードに失敗する: タイムアウト](#troubleshoot-helm-upgrade-failed) - [CRD をインストールできない](#troubleshoot-helm-openshift-rbac) ## [](#troubleshoot-helm-yaml-empty)アップグレードに失敗する: 例外エラー Flex Gateway のデプロイメント中に ​`registration.yaml`​ ファイルを Helm コマンドに渡すときにこのファイルが無効であると、次のエラーになります。 Error: UPGRADE FAILED: execution error at (flex-gateway/templates/deployment.yaml:4:10): registerSecretName, registration.content or registration.secretName is required! このエラーが発生した場合は、​`registration.yaml`​ ファイルが空でないことを確認してください。ファイルが空である場合、新しい一意の名前でゲートウェイを登録して、新しい ​`registration.yaml`​ を生成し、登録ステップの手順を再実行します。登録コマンドの例については、​[「Flex Gateway を登録する」](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started#register-flex)​を参照してください。 ## [](#troubleshoot-helm-upgrade-failed)アップグレードに失敗する: タイムアウト 問題によっては、次のタイムアウトエラーが発生する前に、(コマンドの ​`--wait`​ フラグが原因で) 最大 5 分間 Helm アップグレードコマンドがハングする可能性があります。 Error: UPGRADE FAILED: timed out waiting for the condition 通常、このエラーは、クラスター設定に誤りがあるか、クラスター設定ツールでこのプロセスがサポートされていないことを意味します。原因 1 つとして、​`LoadBalancer`​ 種別の ​`Service`​ リソースの生成の失敗が考えられます。さらにトラブルシューティングするには、次のコマンドを実行します。 - ```kubectl kubectl -n gateway describe deployment ``` - ```kubectl kubectl -n gateway describe service ``` ## [](#troubleshoot-helm-cluster-unreachable)Kubernetes クラスターに到達できない `helm`​ を使用して Flex Gateway をデプロイしようとしているときに Kubernetes クラスターが実行されていない場合、次のエラーが発生する可能性があります。 Error: Kubernetes cluster unreachable: the server could not find the requested resource クラスターを実行するサービスを開始します。 次のように、Kubernetes クラスターホストでクラスターが実行されていることを確認します。 ```kubectl kubectl cluster-info ``` - クラスターが実行されている場合、コマンドで次のような結果が返されます。 Kubernetes control plane is running at https://34.30.50.119 GLBCDefaultBackend is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy - クラスターが設定されていない場合、コマンドで次のような結果が返される可能性があります。 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. error: the server doesn't have a resource type "services" ## [](#troubleshoot-helm-openshift-rbac)CRD をインストールできない ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 必要なアクセス権がない場合、次のようなエラーが発生します。 Error: failed to install CRD crds/apiinstance.yaml: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "user1" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope ## [](#関連情報)関連情報 - [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) # Helm コマンドの問題のトラブルシューティング Kubernetes および OpenShift クラスターの ​`helm`​ コマンドで返されるエラーのトラブルシューティング - [アップグレードに失敗する: 例外エラー](#troubleshoot-helm-yaml-empty) - [Kubernetes クラスターに到達できない](#troubleshoot-helm-cluster-unreachable) - [アップグレードに失敗する: タイムアウト](#troubleshoot-helm-upgrade-failed) - [CRD をインストールできない](#troubleshoot-helm-openshift-rbac) ## [](#troubleshoot-helm-yaml-empty)アップグレードに失敗する: 例外エラー Flex Gateway のデプロイメント中に ​`registration.yaml`​ ファイルを Helm コマンドに渡すときにこのファイルが無効であると、次のエラーになります。 Error: UPGRADE FAILED: execution error at (flex-gateway/templates/deployment.yaml:4:10): registerSecretName, registration.content or registration.secretName is required! このエラーが発生した場合は、​`registration.yaml`​ ファイルが空でないことを確認してください。ファイルが空である場合、新しい一意の名前でゲートウェイを登録して、新しい ​`registration.yaml`​ を生成し、登録ステップの手順を再実行します。登録コマンドの例については、​[「Flex Gateway を登録する」](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-getting-started#register-flex)​を参照してください。 ## [](#troubleshoot-helm-upgrade-failed)アップグレードに失敗する: タイムアウト 問題によっては、次のタイムアウトエラーが発生する前に、(コマンドの ​`--wait`​ フラグが原因で) 最大 5 分間 Helm アップグレードコマンドがハングする可能性があります。 Error: UPGRADE FAILED: timed out waiting for the condition 通常、このエラーは、クラスター設定に誤りがあるか、クラスター設定ツールでこのプロセスがサポートされていないことを意味します。原因 1 つとして、​`LoadBalancer`​ 種別の ​`Service`​ リソースの生成の失敗が考えられます。さらにトラブルシューティングするには、次のコマンドを実行します。 - ```kubectl kubectl -n gateway describe deployment ``` - ```kubectl kubectl -n gateway describe service ``` ## [](#troubleshoot-helm-cluster-unreachable)Kubernetes クラスターに到達できない `helm`​ を使用して Flex Gateway をデプロイしようとしているときに Kubernetes クラスターが実行されていない場合、次のエラーが発生する可能性があります。 Error: Kubernetes cluster unreachable: the server could not find the requested resource クラスターを実行するサービスを開始します。 次のように、Kubernetes クラスターホストでクラスターが実行されていることを確認します。 ```kubectl kubectl cluster-info ``` - クラスターが実行されている場合、コマンドで次のような結果が返されます。 Kubernetes control plane is running at https://34.30.50.119 GLBCDefaultBackend is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy - クラスターが設定されていない場合、コマンドで次のような結果が返される可能性があります。 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. error: the server doesn't have a resource type "services" ## [](#troubleshoot-helm-openshift-rbac)CRD をインストールできない ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 必要なアクセス権がない場合、次のようなエラーが発生します。 Error: failed to install CRD crds/apiinstance.yaml: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "user1" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope ## [](#関連情報)関連情報 - [Kubernetes クラスターでの Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-getting-started) - [Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) # Helm コマンドの問題のトラブルシューティング Kubernetes および OpenShift クラスターの ​`helm`​ コマンドで返されるエラーのトラブルシューティング - [アップグレードに失敗する: 例外エラー](#troubleshoot-helm-yaml-empty) - [Kubernetes クラスターに到達できない](#troubleshoot-helm-cluster-unreachable) - [アップグレードに失敗する: タイムアウト](#troubleshoot-helm-upgrade-failed) - [CRD をインストールできない](#troubleshoot-helm-openshift-rbac) ## [](#troubleshoot-helm-yaml-empty)アップグレードに失敗する: 例外エラー Flex Gateway のデプロイメント中に ​`registration.yaml`​ ファイルを Helm コマンドに渡すときにこのファイルが無効であると、次のエラーになります。 Error: UPGRADE FAILED: execution error at (flex-gateway/templates/deployment.yaml:4:10): registerSecretName, registration.content or registration.secretName is required! このエラーが発生した場合は、​`registration.yaml`​ ファイルが空でないことを確認してください。ファイルが空である場合、新しい一意の名前でゲートウェイを登録して、新しい ​`registration.yaml`​ を生成し、登録ステップの手順を再実行します。登録コマンドの例については、​[「Flex Gateway を登録する」](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started#register-flex)​を参照してください。 ## [](#troubleshoot-helm-upgrade-failed)アップグレードに失敗する: タイムアウト 問題によっては、次のタイムアウトエラーが発生する前に、(コマンドの ​`--wait`​ フラグが原因で) 最大 5 分間 Helm アップグレードコマンドがハングする可能性があります。 Error: UPGRADE FAILED: timed out waiting for the condition 通常、このエラーは、クラスター設定に誤りがあるか、クラスター設定ツールでこのプロセスがサポートされていないことを意味します。原因 1 つとして、​`LoadBalancer`​ 種別の ​`Service`​ リソースの生成の失敗が考えられます。さらにトラブルシューティングするには、次のコマンドを実行します。 - ```kubectl kubectl -n gateway describe deployment ``` - ```kubectl kubectl -n gateway describe service ``` ## [](#troubleshoot-helm-cluster-unreachable)Kubernetes クラスターに到達できない `helm`​ を使用して Flex Gateway をデプロイしようとしているときに Kubernetes クラスターが実行されていない場合、次のエラーが発生する可能性があります。 Error: Kubernetes cluster unreachable: the server could not find the requested resource クラスターを実行するサービスを開始します。 次のように、Kubernetes クラスターホストでクラスターが実行されていることを確認します。 ```kubectl kubectl cluster-info ``` - クラスターが実行されている場合、コマンドで次のような結果が返されます。 Kubernetes control plane is running at https://34.30.50.119 GLBCDefaultBackend is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy - クラスターが設定されていない場合、コマンドで次のような結果が返される可能性があります。 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. error: the server doesn't have a resource type "services" ## [](#troubleshoot-helm-openshift-rbac)CRD をインストールできない ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 必要なアクセス権がない場合、次のようなエラーが発生します。 Error: failed to install CRD crds/apiinstance.yaml: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "user1" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope ## [](#関連情報)関連情報 - [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) # Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新 Flex Gateway デプロイメントが含まれるポッドの要件を変更します。このガイドの例では、Flex Gateway デプロイメントの Helm チャートの次の CPU およびメモリ要件を設定します。 - `resources.limits.cpu=1500m` - `resources.limits.memory=2048Mi` - `resources.requests.cpu=260m` - `resources.requests.memory=384Mi` この例は、Flex Gateway デプロイメントの Helm チャートの値を更新するためのガイドとして使用してください。 次のいずれかの方法で、Flex Gateway のデフォルトの Helm チャート設定を見つけます。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ (例: `helm show values flex-gateway/flex-gateway`​) を実行します。 CPU およびメモリリソース設定についての詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)​を参照してください。 ## [](#始める前に)始める前に Flex Gateway を登録して Kubernetes クラスターにデプロイします。案内については、「​[自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) or [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started)​」を参照してください。 ## [](#update-cpu-memory-example)Helm チャートの現在の設定を確認する Flex Gateway デプロイメントが含まれるポッドの設定を更新する前に、ポッドの現在のデプロイメントの設定を確認します。 1. ターミナルウィンドウから次のコマンドを実行して、Helm リポジトリが稼働していて使用可能であることを確認します。 ```helm helm repo up ``` 2. 最新のデプロイメントの ​`REVISION`​ 番号を見つけます。 次の例では、​`gateway`​ 名前空間の ​`ingress`​ リリースの履歴を要求します。 ```helm helm history ingress -n gateway ``` コマンドで次のような結果が返されます。 REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Mar 27 09:36:20 2023 superseded flex-gateway-1.4.2 1.4.2 Upgrade complete 2 Mon Mar 27 11:40:56 2023 deployed flex-gateway-1.4.2 1.4.2 Upgrade complete 3. 現在デプロイされているリビジョンの ​`USER-SUPPLIED VALUES`​ 設定の ​`resources`​ を確認します。 コマンドの構文: helm get values --revision= -n 例: ```helm helm get values --revision=2 ingress -n gateway ``` 次の例は、ポッドの ​`registration`​ データの下にあるポッドの CPU およびメモリの ​`resources`​ 設定を示しています。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1000m memory: 2024Mi requests: cpu: 250m memory: 256Mi この例では、​`REVISION`​ 番号 ​`2`​ の設定が表示されています。出力には、変更された設定のみが表示されます。Helm チャートのデフォルト値が変更されていない場合、出力にリビジョンは表示​_されません_​。 4. 次のいずれかの手順を使用して、Flex Gateway デプロイメントの Helm チャートの設定を変更します。 - [Helm チャートの設定を変更する](#use-helm-set-option)​では ​`helm upgrade`​ コマンドで ​`--set`​ オプションを使用します。このコマンドでは、複数の ​`--set`​ オプションを使用できます。 - [Helm チャートの変更された設定が含まれるファイルに提供する](#use-helm-f-option)​では ​`-f`​ オプションを使用して、複数の設定が含まれる設定ファイルを ​`helm upgrade`​ に渡します。このコマンドでは、複数の ​`-f`​ オプションを使用できます。 ## [](#use-helm-set-option)Helm チャートの設定を変更する [Helm チャートの現在の設定を確認する](#update-cpu-memory-example)​の手順を実行した後に、​`--set`​ オプションを使用して、Flex Gateway デプロイメントの Helm チャートに新しい値を個別に渡します。または、​[Helm チャートの変更された設定が含まれるファイルに提供する](#use-helm-f-option)​の手順を実行します。 1. `helm upgrade`​ コマンドを使用して、​`cpu`​ および ​`memory`​ 値を変更します。 構文: helm -n upgrade \\ --wait \\ --reuse-values \\ / \\ --set = --set = ... 例: ```helm helm -n gateway upgrade ingress \ --wait \ --reuse-values \ flex-gateway/flex-gateway \ --set resources.limits.cpu=1500m \ --set resources.limits.memory=2048Mi \ --set resources.requests.cpu=260m \ --set resources.requests.memory=384Mi ``` コマンドが成功すると、次のような出力が返されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Mar 27 11:58:36 2023 NAMESPACE: gateway STATUS: deployed REVISION: 3 TEST SUITE: None 2. 次のように、新しい ​`REVISION`​ 値を使用して、​`resources`​ 設定を確認します。 ```helm helm get values --revision=3 ingress -n gateway ``` 出力には、ポッドの新しい ​`resources`​ 設定が表示されます。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi ## [](#use-helm-f-option)Helm チャートの変更された設定が含まれるファイルに提供する [Helm チャートの現在の設定を確認する](#update-cpu-memory-example)​の手順を実行した後に、​`helm upgrade`​ で ​`-f`​ オプションを使用して、Flex Gateway デプロイメントの新しい Helm チャート設定が含まれるファイルを識別します。または、​[Helm チャートの設定を変更する](#use-helm-set-option)​の手順を実行します。 1. 新しい設定が含まれる設定ファイルを作成します。 たとえば、新しい ​`cpu`​ および ​`memory`​ メモリ値が含まれる ​`my-config-file.yaml`​ という名前の YAML ファイルを作成します。 ```yaml resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi ``` 2. 次のように、設定ファイルから Helm チャートに新しい値を渡します。 構文: helm -n upgrade \\ --wait \\ --reuse-values \\ / \\ -f 例: ```helm helm -n gateway upgrade ingress \ --wait \ --reuse-values \ flex-gateway/flex-gateway \ -f my-config-file.yaml ``` コマンドが成功すると、次のような出力が返されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Mar 27 16:38:07 2023 NAMESPACE: gateway STATUS: deployed REVISION: 4 TEST SUITE: None 3. 次のように、Helm リポジトリとチャート名を使用してチャートの更新を確認します。 ```helm helm get values --revision=4 ingress -n gateway ``` 出力には、ポッドの新しい ​`resources`​ 設定が表示されます。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi # Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新 Flex Gateway デプロイメントが含まれるポッドの要件を変更します。このガイドの例では、Flex Gateway デプロイメントの Helm チャートの次の CPU およびメモリ要件を設定します。 - `resources.limits.cpu=1500m` - `resources.limits.memory=2048Mi` - `resources.requests.cpu=260m` - `resources.requests.memory=384Mi` この例は、Flex Gateway デプロイメントの Helm チャートの値を更新するためのガイドとして使用してください。 次のいずれかの方法で、Flex Gateway のデフォルトの Helm チャート設定を見つけます。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ (例: `helm show values flex-gateway/flex-gateway`​) を実行します。 CPU およびメモリリソース設定についての詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)​を参照してください。 ## [](#始める前に)始める前に Flex Gateway を登録して Kubernetes クラスターにデプロイします。案内については、「​[Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) or [Kubernetes クラスターでの Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-getting-started)​」を参照してください。 ## [](#update-cpu-memory-example)Helm チャートの現在の設定を確認する Flex Gateway デプロイメントが含まれるポッドの設定を更新する前に、ポッドの現在のデプロイメントの設定を確認します。 1. ターミナルウィンドウから次のコマンドを実行して、Helm リポジトリが稼働していて使用可能であることを確認します。 ```helm helm repo up ``` 2. 最新のデプロイメントの ​`REVISION`​ 番号を見つけます。 次の例では、​`gateway`​ 名前空間の ​`ingress`​ リリースの履歴を要求します。 ```helm helm history ingress -n gateway ``` コマンドで次のような結果が返されます。 REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Mar 27 09:36:20 2023 superseded flex-gateway-1.4.2 1.4.2 Upgrade complete 2 Mon Mar 27 11:40:56 2023 deployed flex-gateway-1.4.2 1.4.2 Upgrade complete 3. 現在デプロイされているリビジョンの ​`USER-SUPPLIED VALUES`​ 設定の ​`resources`​ を確認します。 コマンドの構文: helm get values --revision= -n 例: ```helm helm get values --revision=2 ingress -n gateway ``` 次の例は、ポッドの ​`registration`​ データの下にあるポッドの CPU およびメモリの ​`resources`​ 設定を示しています。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1000m memory: 2024Mi requests: cpu: 250m memory: 256Mi この例では、​`REVISION`​ 番号 ​`2`​ の設定が表示されています。出力には、変更された設定のみが表示されます。Helm チャートのデフォルト値が変更されていない場合、出力にリビジョンは表示​_されません_​。 4. 次のいずれかの手順を使用して、Flex Gateway デプロイメントの Helm チャートの設定を変更します。 - [Helm チャートの設定を変更する](#use-helm-set-option)​では ​`helm upgrade`​ コマンドで ​`--set`​ オプションを使用します。このコマンドでは、複数の ​`--set`​ オプションを使用できます。 - [Helm チャートの変更された設定が含まれるファイルに提供する](#use-helm-f-option)​では ​`-f`​ オプションを使用して、複数の設定が含まれる設定ファイルを ​`helm upgrade`​ に渡します。このコマンドでは、複数の ​`-f`​ オプションを使用できます。 ## [](#use-helm-set-option)Helm チャートの設定を変更する [Helm チャートの現在の設定を確認する](#update-cpu-memory-example)​の手順を実行した後に、​`--set`​ オプションを使用して、Flex Gateway デプロイメントの Helm チャートに新しい値を個別に渡します。または、​[Helm チャートの変更された設定が含まれるファイルに提供する](#use-helm-f-option)​の手順を実行します。 1. `helm upgrade`​ コマンドを使用して、​`cpu`​ および ​`memory`​ 値を変更します。 構文: helm -n upgrade \\ --wait \\ --reuse-values \\ / \\ --set = --set = ... 例: ```helm helm -n gateway upgrade ingress \ --wait \ --reuse-values \ flex-gateway/flex-gateway \ --set resources.limits.cpu=1500m \ --set resources.limits.memory=2048Mi \ --set resources.requests.cpu=260m \ --set resources.requests.memory=384Mi ``` コマンドが成功すると、次のような出力が返されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Mar 27 11:58:36 2023 NAMESPACE: gateway STATUS: deployed REVISION: 3 TEST SUITE: None 2. 次のように、新しい ​`REVISION`​ 値を使用して、​`resources`​ 設定を確認します。 ```helm helm get values --revision=3 ingress -n gateway ``` 出力には、ポッドの新しい ​`resources`​ 設定が表示されます。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi ## [](#use-helm-f-option)Helm チャートの変更された設定が含まれるファイルに提供する [Helm チャートの現在の設定を確認する](#update-cpu-memory-example)​の手順を実行した後に、​`helm upgrade`​ で ​`-f`​ オプションを使用して、Flex Gateway デプロイメントの新しい Helm チャート設定が含まれるファイルを識別します。または、​[Helm チャートの設定を変更する](#use-helm-set-option)​の手順を実行します。 1. 新しい設定が含まれる設定ファイルを作成します。 たとえば、新しい ​`cpu`​ および ​`memory`​ メモリ値が含まれる ​`my-config-file.yaml`​ という名前の YAML ファイルを作成します。 ```yaml resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi ``` 2. 次のように、設定ファイルから Helm チャートに新しい値を渡します。 構文: helm -n upgrade \\ --wait \\ --reuse-values \\ / \\ -f 例: ```helm helm -n gateway upgrade ingress \ --wait \ --reuse-values \ flex-gateway/flex-gateway \ -f my-config-file.yaml ``` コマンドが成功すると、次のような出力が返されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Mar 27 16:38:07 2023 NAMESPACE: gateway STATUS: deployed REVISION: 4 TEST SUITE: None 3. 次のように、Helm リポジトリとチャート名を使用してチャートの更新を確認します。 ```helm helm get values --revision=4 ingress -n gateway ``` 出力には、ポッドの新しい ​`resources`​ 設定が表示されます。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi # Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新 Flex Gateway デプロイメントが含まれるポッドの要件を変更します。このガイドの例では、Flex Gateway デプロイメントの Helm チャートの次の CPU およびメモリ要件を設定します。 - `resources.limits.cpu=1500m` - `resources.limits.memory=2048Mi` - `resources.requests.cpu=260m` - `resources.requests.memory=384Mi` この例は、Flex Gateway デプロイメントの Helm チャートの値を更新するためのガイドとして使用してください。 次のいずれかの方法で、Flex Gateway のデフォルトの Helm チャート設定を見つけます。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ (例: `helm show values flex-gateway/flex-gateway`​) を実行します。 CPU およびメモリリソース設定についての詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)​を参照してください。 ## [](#始める前に)始める前に Flex Gateway を登録して Kubernetes クラスターにデプロイします。案内については、「​[自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) or [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started)​」を参照してください。 ## [](#update-cpu-memory-example)Helm チャートの現在の設定を確認する Flex Gateway デプロイメントが含まれるポッドの設定を更新する前に、ポッドの現在のデプロイメントの設定を確認します。 1. ターミナルウィンドウから次のコマンドを実行して、Helm リポジトリが稼働していて使用可能であることを確認します。 ```helm helm repo up ``` 2. 最新のデプロイメントの ​`REVISION`​ 番号を見つけます。 次の例では、​`gateway`​ 名前空間の ​`ingress`​ リリースの履歴を要求します。 ```helm helm history ingress -n gateway ``` コマンドで次のような結果が返されます。 REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Mon Mar 27 09:36:20 2023 superseded flex-gateway-1.4.2 1.4.2 Upgrade complete 2 Mon Mar 27 11:40:56 2023 deployed flex-gateway-1.4.2 1.4.2 Upgrade complete 3. 現在デプロイされているリビジョンの ​`USER-SUPPLIED VALUES`​ 設定の ​`resources`​ を確認します。 コマンドの構文: helm get values --revision= -n 例: ```helm helm get values --revision=2 ingress -n gateway ``` 次の例は、ポッドの ​`registration`​ データの下にあるポッドの CPU およびメモリの ​`resources`​ 設定を示しています。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1000m memory: 2024Mi requests: cpu: 250m memory: 256Mi この例では、​`REVISION`​ 番号 ​`2`​ の設定が表示されています。出力には、変更された設定のみが表示されます。Helm チャートのデフォルト値が変更されていない場合、出力にリビジョンは表示​_されません_​。 4. 次のいずれかの手順を使用して、Flex Gateway デプロイメントの Helm チャートの設定を変更します。 - [Helm チャートの設定を変更する](#use-helm-set-option)​では ​`helm upgrade`​ コマンドで ​`--set`​ オプションを使用します。このコマンドでは、複数の ​`--set`​ オプションを使用できます。 - [Helm チャートの変更された設定が含まれるファイルに提供する](#use-helm-f-option)​では ​`-f`​ オプションを使用して、複数の設定が含まれる設定ファイルを ​`helm upgrade`​ に渡します。このコマンドでは、複数の ​`-f`​ オプションを使用できます。 ## [](#use-helm-set-option)Helm チャートの設定を変更する [Helm チャートの現在の設定を確認する](#update-cpu-memory-example)​の手順を実行した後に、​`--set`​ オプションを使用して、Flex Gateway デプロイメントの Helm チャートに新しい値を個別に渡します。または、​[Helm チャートの変更された設定が含まれるファイルに提供する](#use-helm-f-option)​の手順を実行します。 1. `helm upgrade`​ コマンドを使用して、​`cpu`​ および ​`memory`​ 値を変更します。 構文: helm -n upgrade \\ --wait \\ --reuse-values \\ / \\ --set = --set = ... 例: ```helm helm -n gateway upgrade ingress \ --wait \ --reuse-values \ flex-gateway/flex-gateway \ --set resources.limits.cpu=1500m \ --set resources.limits.memory=2048Mi \ --set resources.requests.cpu=260m \ --set resources.requests.memory=384Mi ``` コマンドが成功すると、次のような出力が返されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Mar 27 11:58:36 2023 NAMESPACE: gateway STATUS: deployed REVISION: 3 TEST SUITE: None 2. 次のように、新しい ​`REVISION`​ 値を使用して、​`resources`​ 設定を確認します。 ```helm helm get values --revision=3 ingress -n gateway ``` 出力には、ポッドの新しい ​`resources`​ 設定が表示されます。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi ## [](#use-helm-f-option)Helm チャートの変更された設定が含まれるファイルに提供する [Helm チャートの現在の設定を確認する](#update-cpu-memory-example)​の手順を実行した後に、​`helm upgrade`​ で ​`-f`​ オプションを使用して、Flex Gateway デプロイメントの新しい Helm チャート設定が含まれるファイルを識別します。または、​[Helm チャートの設定を変更する](#use-helm-set-option)​の手順を実行します。 1. 新しい設定が含まれる設定ファイルを作成します。 たとえば、新しい ​`cpu`​ および ​`memory`​ メモリ値が含まれる ​`my-config-file.yaml`​ という名前の YAML ファイルを作成します。 ```yaml resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi ``` 2. 次のように、設定ファイルから Helm チャートに新しい値を渡します。 構文: helm -n upgrade \\ --wait \\ --reuse-values \\ / \\ -f 例: ```helm helm -n gateway upgrade ingress \ --wait \ --reuse-values \ flex-gateway/flex-gateway \ -f my-config-file.yaml ``` コマンドが成功すると、次のような出力が返されます。 Release "ingress" has been upgraded. Happy Helming! NAME: ingress LAST DEPLOYED: Mon Mar 27 16:38:07 2023 NAMESPACE: gateway STATUS: deployed REVISION: 4 TEST SUITE: None 3. 次のように、Helm リポジトリとチャート名を使用してチャートの更新を確認します。 ```helm helm get values --revision=4 ingress -n gateway ``` 出力には、ポッドの新しい ​`resources`​ 設定が表示されます。 USER-SUPPLIED VALUES: registration: ... resources: limits: cpu: 1500m memory: 2048Mi requests: cpu: 260m memory: 384Mi # HTTP キャッシュポリシー

ポリシー名

HTTP キャッシュ

概要

API 実装から HTTP 応答をキャッシュする

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 HTTP キャッシュポリシーでは、HTTP 応答をキャッシュして再利用できます。これらの応答をキャッシュすると、ユーザー要求の応答時間が短縮され、バックエンドの負荷が軽減されます。たとえば、要求に対する応答が変更される可能性の低いエンドポイントをバックエンドで公開する場合、HTTP キャッシュポリシーを使用して、HTTP 応答を再利用し、バックエンド要求処理をバイパスできます。 ポリシー順序で HTTP キャッシュポリシーの後に適用されるポリシーはキャッシュによって提供される応答には適用されません。たとえば、HTTP キャッシュポリシーの後に適用されるレート制限ポリシーでは、アップストリームサービスによって提供される応答のみを制限し、キャッシュによって提供される応答は制限しません。HTTP キャッシュポリシーより前にキャッシュされた応答に必要なすべてのポリシーを適用してください。
HTTP キャッシュポリシーでは、MCP および A2A サーバーインスタンスはサポートされません。
## [](#cpp)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-caching-flex config: httpCachingKey: // REQUIRED, default: "#\[attributes.requestPath\]" maxCacheEntries: // REQUIRED, default: 10000 ttl: // REQUIRED, default: 600 useHttpCacheHeaders: // REQUIRED, default: true invalidationHeader: // OPTIONAL, default: "" requestExpression: // OPTIONAL, default: "#\[attributes.method == 'GET' or attributes.method == 'HEAD'\]" responseExpression: // OPTIONAL, default: "#\[\[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501\] contains attributes.statusCode\]" distributed: // REQUIRED, default: false persistCache: // REQUIRED, default: false
パラメーター 必須または省略可能 デフォルト値 説明

httpCachingKey

必須

#[attributes.requestPath]

DataWeave 式

maxCacheEntries

必須

10000

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。

ttl

必須

600

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。

useHttpCacheHeaders

必須

true

Cache-Control ヘッダーディレクティブの使用を有効にします。

invalidationHeader

省略可能

空の文字列

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーを指定する文字列。

requestExpression

省略可能

#[attributes.method == 'GET' or attributes.method == 'HEAD']

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。

responseExpression

省略可能

#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)

distributed

必須

false

クラスター内の各ノードでキャッシュが分散されるように設定

persistCache

必須

false

レプリカの各再起動間でキャッシュが維持されるように設定
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: http-caching-flex config: httpCachingKey: "#[attributes.requestPath]" maxCacheEntries: 10000 ttl: 500 useHttpCacheHeaders: false requestExpression: "#[attributes.method == 'GET' or attributes.method == 'HEAD']" responseExpression: "#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]" ``` #### [](#分散キャッシュリソースの設定例)分散キャッシュリソースの設定例 分散キャッシュでは、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-caching spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: http-caching-flex config: httpCachingKey: "#\[attributes.method ++ attributes.requestPath\]" useHttpCacheHeaders: true maxCacheEntries: 100 ttl: 600 distributed: true persistCache: true invalidationHeader: AGW-CACHE-CONTROL ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 Required?

HTTP Caching Key (HTTP キャッシュキー)

DataWeave 式。 デフォルト値: #[attributes.requestPath]

はい

Maximum Cache Entries (最大キャッシュエントリ)

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。 デフォルト値: 10000

はい

Entry Time To Live (エントリ存続期間)

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。 デフォルト値: 600

はい

Distributed (分散)

クラスター内の各ノードでキャッシュが分散されるように設定します。 デフォルト値: false

はい

Persistent Cache (永続キャッシュ)

Flex Gateway インスタンスの各再起動間でキャッシュが維持されるように設定します。 デフォルト値: false

はい

Follow HTTP Caching directives (HTTP キャッシュディレクティブに従う)

Cache-Control ヘッダーディレクティブの使用を有効にします。 デフォルト値: true

はい

Invalidation Header (無効化ヘッダー)

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーの名前。

いいえ

Conditional Request Caching Expression (条件付き要求キャッシュ式)

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。 デフォルト値: #[attributes.method == 'GET' or attributes.method == 'HEAD']

いいえ

Conditional Response Caching Expression (条件付き応答キャッシュ式)

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)。 デフォルト値: #[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ HTTP 要求がエンドポイントに到達した後の次の処理は、要求がまだキャッシュにないのか (キャッシュミス)、すでにあるのか (キャッシュヒット) によって決まります。 ### [](#キャッシュミス)キャッシュミス キャッシュミスの場合、HTTP キャッシュポリシーは、送信された要求に対する応答がすでにキャッシュされているかどうかをチェックします。要求がバックエンドに到達したら、キャッシュミスの場合にのみプロセスが開始されます。次の図は、このシナリオで発生するイベントのフローを示しています。 ![Web ブラウザーとバックエンドシステム間のデータフローを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/http-policy-cache-miss.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまでポリシーチェーンの他のポリシーを進みます。 3. HTTP キャッシュポリシーは、要求がすでにオブジェクトストアにあるかどうかをチェックします。ない場合は、キャッシュミスプロセスが開始されます。 4. 要求は、他の残りのポリシーのチェーンを引き続き進みます。 5. 要求がバックエンドに到達し、必要なすべての処理を実行します。 6. バックエンドが応答し、応答はポリシーチェーンを戻ります。 7. 応答が HTTP キャッシュポリシーに到達します。 8. キャッシュで再度オブジェクトストアがヒットし、後で再利用できるように要求の​[キー](#key)​を保存しようとします。 9. 応答は、ポリシーチェーンの残りのポリシーを引き続き進みます。 10. 応答がクライアントに返されます。 ### [](#キャッシュヒット)キャッシュヒット キャッシュヒットの場合、HTTP キャッシュポリシーは、オブジェクトストアのキーを検索し、要求に対する応答が​[保存済みエントリ](#stored_entry)​としてすでにキャッシュされていることを検出します。要求がバックエンドに向けてポリシーチェーンを進むことはなく、キャッシュされた応答が再利用されます。 キャッシュヒットの場合、キャッシュ後にポリシーチェーンで実行される必要のあるすべてのポリシーはそれ以降実行されません。 ![API ゲートウェイを介した Web ブラウザーからバックエンドおよびオブジェクトストアへのデータフローを示すフローチャート図](/mulesoft/current/ja-jp/gateway/1.10/_images/http-policy-cache-hit.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまで他のポリシーを通過します。 3. HTTP キャッシュポリシーは、要求がすでにキャッシュにあるかどうかを確認します。 4. オブジェクトストアで​[キー](#key)​が見つかり、保存された応答が返されます。 5. 応答は、最後のポリシーに到達するまでポリシーチェーンの残りのポリシーを引き続き進みます。 6. キャッシュされた応答がクライアントに返されます。 ### [](#stored_entry)保存済みエントリ _保存済みエントリ_​は、キャッシュされた HTTP 応答です。キャッシュには、最大 1 MB のシリアル化可能データと入力ストリームを保存できます。値がこの制限を超えると、読み取りは停止し、値は保存されません。 ### [](#key)HTTP Caching Key (HTTP キャッシュキー) キャッシュは辞書として機能し、そこではキャッシュに保存された各応答が​_キー_​と呼ばれる文字列に関連付けられます。たとえば、式 #\[attributes.headers\['key'\]\] では、​`key`​ というヘッダーがエントリキーとして使用されます。​[定義済みの DataWeave 変数](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support#available-predefined-variables)​を含めて、文字列を返す任意の DataWeave 式を使用できます。 ### [](#キャッシュサイズとエントリ有効期限)キャッシュサイズとエントリ有効期限 キャッシュには、指定された数のエントリを特定の期間保持できます。この数は、​`Maximum Cache Entries`​ プロパティを使用して設定できます。各保存済みエントリは、一定時間キャッシュメモリに保持されます。その後、エントリは期限切れになり、再度処理する必要があります。この有効期限は、​_存続期間_​ (TTL) と呼ばれます。 キャッシュが最大項目保存数に達したときもエントリの有効期限がトリガーされます。このシナリオが発生すると、FIFO (先入れ先出し) 条件を使用してエントリが削除されます。つまり、最も早くキャッシュに到達したエントリは、TTL 値にまだ達していなくても削除されます。 ### [](#分散キャッシュ)分散キャッシュ キャッシュの各エントリは、​`Distributed`​ オプション (表を参照) を使用して、クラスター内の各ノードや Runtime Manager の複数のワーカーで共有できます。このオプションが有効になっていない場合、各ノードには独自のキャッシュメモリが割り当てられます。 ### [](#永続キャッシュ)永続キャッシュ 永続キャッシュでは、Flex レプリカが再起動しても、キャッシュの保存済みエントリを保持できます。 永続的なストアを使用するように設定された HTTP キャッシュポリシーを持つインスタンスのバージョンをアップグレードすると、ポリシーは以前のバージョンで保存されたエントリを維持しようとします。ただし、最悪のシナリオでは、キャッシュ内のエントリが無効になり、新しい要求の到着時にキャッシュが再入力されます。キャッシュ内のエントリのこの操作は自動的に実行され、ユーザーが意識することはありません。 ## [](#http-キャッシュディレクティブ)HTTP キャッシュディレクティブ HTTP キャッシュポリシーは、キャッシュをより詳細に制御するために次のヘッダーを考慮に入れて [RFC-7234](https://tools.ietf.org/html/rfc7234)​ プロトコルのいくつかの HTTP ディレクティブを解釈します。 - `Cache-Control` - `Expires` - `Date` - `Age` ### [](#cache-control)Cache-Control `Cache-Control`​ ヘッダーは要求または応答に存在します。ヘッダーに対して可能な値は次のとおりです。これらの値は、カンマで区切って組み合わせることができます。 - 要求: - `no-cache` 応答は検索されませんが、キャッシュに直接保存されます。 - `no-store` 応答はキャッシュに保存されません。ただし、応答がキャッシュ内にすでに存在する場合は、ポリシーがその応答を返します。 - 応答: - `no-store`​、​`no-cache`​、​`private` どの値でも応答はキャッシュに保存されません。 - `max-age=`​、​`s-maxage=` ``​ プレースホルダーは、応答がキャッシュに残ることができる時間 (秒) を示す有効な整数に置き換える必要があります。両方のパラメーターが定義されている場合、​`max-age`​ よりも ​`s-maxage`​ が優先されます。 ポリシーでグローバル存続期間 (TTL) 値も定義されている場合、ヘッダーで指定されている時間がグローバル TTL よりも少ないと、これらのヘッダー値がポリシーで設定されているグローバル TTL よりも優先されます。 ### [](#expires-有効期限)Expires (有効期限) 存在する場合、このヘッダーでキャッシュ内のエントリの有効期限を指定します。​`max-age`​ ディレクティブまたは ​`s-maxage`​ ディレクティブが指定されている場合、このヘッダーは無視されます。ヘッダー値は [RFC-1123](https://tools.ietf.org/html/rfc1123)​ のとおりに定義する必要があります。 ### [](#date-日付)Date (日付) `date`​ ヘッダーが [RFC-1123](https://tools.ietf.org/html/rfc1123)​ に従って定義されている場合、応答の作成日時が指定されます。定義されていない場合、​`date`​ ヘッダーが要求の受信時刻で追加されます。このヘッダーは、Cache-Control ヘッダーの ​`max-age`​ および ​`s-maxage`​ ディレクティブに定義された値と一緒に使用されます。 ### [](#age-存続期間)Age (存続期間) `age`​ ヘッダーは、date ヘッダーに指定されたキャッシュされている応答の作成以降の経過時間 (秒) を示します。このヘッダーはポリシーによって計算され、キャッシュから取得された各応答に追加されます。 有効期限は、​`cache-control`​、​`date`​、​`expires`​ ヘッダーを使用して計算されます。ただし、計算された有効期限がエントリの TTL 値で指定された存続時間を超える場合、キャッシュエントリの有効期限が切れます。 ### [](#無効化)無効化 HTTP キャッシュポリシーで ​`invalidate`​ ヘッダーが設定されている場合、キャッシュ内のエントリが無効化され、要求が再度処理されます。\[Invalidation Header (無効化ヘッダー)\] 設定のヘッダーの名前を指定して、オプションを有効にします。ヘッダーの値には、​`invalidate`​ オプションのみを設定できます。 このオプションは、キーが現在の要求に一致するエントリを無効化します。 `invalidate-all`​ このオプションは、キャッシュからすべてのエントリを無効化します。 たとえば、ポリシーで要求の次の値が設定されているとします。 - `HTTP Caching Key`​ (HTTP キャッシュキー): "#\[attributes.requestPath\]" - `Invalidation header`​ (無効化ヘッダー): "myInvalidationHeader" 次のコマンドは、キャッシュからキーが "/my/policy" のエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate”` 次の要求は、キャッシュからすべてのエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate-all”` ## [](#条件付きキャッシュ)条件付きキャッシュ 条件付きキャッシュでは、エントリをキャッシュに保存するために満たす必要がある一連の条件を設定できます。条件付きキャッシュパラメーターが設定されていない場合、すべての受信要求の応答がキャッシュに保存されます。設定されている場合、各要求のパラメーターが評価されて、現在の要求の応答を保存する必要があるかどうかが判断されます。 条件付き要求式の場合、デフォルトでは、HTTP メソッドの ​`GET`​ または ​`HEAD`​ による受信要求に対する応答のみがキャッシュされます。条件付き応答式の場合、デフォルトでは、 [RFC-7231](https://tools.ietf.org/html/rfc7231#section-6.1)​ で指定された状況コードのみがキャッシュされます。 デフォルト値についての詳細は、​[「ポリシーのパラメーターの設定」](#cpp)​を参照してください。 ## [](#faq)FAQ **キーの評価がエラーになった場合はどうなりますか?** 特定の要求の式の評価がエラーになった場合、ポリシーは有効にならず、要求はポリシーチェーンの次の受け入れ先に引き続き進みます。 **このポリシーで応答の一部のみを保存できますか?** いいえ。ただし、このポリシーの前に別のポリシーを適用して、応答を変更することはできます。 **あるパラメーターではキャッシュ内で応答を検索するように設定し、別のパラメーターではその逆のアクションを実行するように設定した場合、どうなりますか?** これは、Cache-Control ヘッダーに no-store ディレクティブがある状態で応答をキャッシュに保存するように設定したときと同じになります。 この場合、応答は保存されません。キャッシュに応答を保存したり、キャッシュの応答を検索したりできるようにするには、Cache-Contro ヘッダーとキャッシュの両方を設定する必要があります。 **省略可能なパラメーターを定義しないとどうなりますか?** `invalidation`​ ヘッダーを設定していない場合、要求のキャッシュを無効化できません。 また、要求式や応答式を設定していない場合、キャッシュはすべての要求に対して使用され、すべての応答がキャッシュに保存されます (式 #\[true\])。 **\[Invalidation header (無効化ヘッダー)\] の値を変更できますか?** いいえ。変更できるのはヘッダー名のみです。 # HTTP キャッシュポリシー

ポリシー名

HTTP キャッシュ

概要

API 実装から HTTP 応答をキャッシュする

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 HTTP キャッシュポリシーでは、HTTP 応答をキャッシュして再利用できます。これらの応答をキャッシュすると、ユーザー要求の応答時間が短縮され、バックエンドの負荷が軽減されます。たとえば、要求に対する応答が変更される可能性の低いエンドポイントをバックエンドで公開する場合、HTTP キャッシュポリシーを使用して、HTTP 応答を再利用し、バックエンド要求処理をバイパスできます。

ポリシー順序で HTTP キャッシュポリシーの後に適用されるポリシーはキャッシュによって提供される応答には適用されません。たとえば、HTTP キャッシュポリシーの後に適用されるレート制限ポリシーでは、アップストリームサービスによって提供される応答のみを制限し、キャッシュによって提供される応答は制限しません。HTTP キャッシュポリシーより前にキャッシュされた応答に必要なすべてのポリシーを適用してください。
## [](#cpp)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して HTTP キャッシュポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-caching-flex config: httpCachingKey: // REQUIRED, default: "#\[attributes.requestPath\]" maxCacheEntries: // REQUIRED, default: 10000 ttl: // REQUIRED, default: 600 useHttpCacheHeaders: // REQUIRED, default: true invalidationHeader: // OPTIONAL, default: "" requestExpression: // OPTIONAL, default: "#\[attributes.method == 'GET' or attributes.method == 'HEAD'\]" responseExpression: // OPTIONAL, default: "#\[\[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501\] contains attributes.statusCode\]" distributed: // REQUIRED, default: false persistCache: // REQUIRED, default: false
パラメーター 必須または省略可能 デフォルト値 説明

httpCachingKey

必須

#[attributes.requestPath]

DataWeave 式

maxCacheEntries

必須

10000

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。

ttl

必須

600

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。

useHttpCacheHeaders

必須

true

Cache-Control ヘッダーディレクティブの使用を有効にします。

invalidationHeader

省略可能

空の文字列

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーを指定する文字列。

requestExpression

省略可能

#[attributes.method == 'GET' or attributes.method == 'HEAD']

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。

responseExpression

省略可能

#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)

distributed

必須

false

クラスター内の各ノードでキャッシュが分散されるように設定

persistCache

必須

false

レプリカの各再起動間でキャッシュが維持されるように設定
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: http-caching-flex config: httpCachingKey: "#[attributes.requestPath]" maxCacheEntries: 10000 ttl: 500 useHttpCacheHeaders: false requestExpression: "#[attributes.method == 'GET' or attributes.method == 'HEAD']" responseExpression: "#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]" ``` #### [](#分散キャッシュリソースの設定例)分散キャッシュリソースの設定例 分散キャッシュでは、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-caching spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: http-caching-flex config: httpCachingKey: "#\[attributes.method ++ attributes.requestPath\]" useHttpCacheHeaders: true maxCacheEntries: 100 ttl: 600 distributed: true persistCache: true invalidationHeader: AGW-CACHE-CONTROL ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI から HTTP キャッシュポリシーを API に適用する場合は、次のパラメーターを設定できます。
パラメーター 説明 必須?

HTTP Caching Key (HTTP キャッシュキー)

DataWeave 式。 デフォルト値: #[attributes.requestPath]

はい

Maximum Cache Entries (最大キャッシュエントリ)

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。 デフォルト値: 10000

はい

Entry Time To Live (エントリ存続期間)

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。 デフォルト値: 600

はい

Distributed (分散)

クラスター内の各ノードでキャッシュが分散されるように設定します。 デフォルト値: false

はい

Persistent Cache (永続キャッシュ)

Flex Gateway インスタンスの各再起動間でキャッシュが維持されるように設定します。 デフォルト値: false

はい

Follow HTTP Caching directives (HTTP キャッシュディレクティブに従う)

Cache-Control ヘッダーディレクティブの使用を有効にします。 デフォルト値: true

はい

Invalidation Header (無効化ヘッダー)

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーの名前。

いいえ

Conditional Request Caching Expression (条件付き要求キャッシュ式)

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。 デフォルト値: #[attributes.method == 'GET' or attributes.method == 'HEAD']

いいえ

Conditional Response Caching Expression (条件付き応答キャッシュ式)

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)。 デフォルト値: #[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ HTTP 要求がエンドポイントに到達した後の次の処理は、要求がまだキャッシュにないのか (キャッシュミス)、すでにあるのか (キャッシュヒット) によって決まります。 ### [](#キャッシュミス)キャッシュミス キャッシュミスの場合、HTTP キャッシュポリシーは、送信された要求に対する応答がすでにキャッシュされているかどうかをチェックします。要求がバックエンドに到達したら、キャッシュミスの場合にのみプロセスが開始されます。次の図は、このシナリオで発生するイベントのフローを示しています。 ![http policy cache miss](/mulesoft/current/ja-jp/gateway/1.8/_images/http-policy-cache-miss.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまでポリシーチェーンの他のポリシーを進みます。 3. HTTP キャッシュポリシーは、要求がすでにオブジェクトストアにあるかどうかをチェックします。ない場合は、キャッシュミスプロセスが開始されます。 4. 要求は、他の残りのポリシーのチェーンを引き続き進みます。 5. 要求がバックエンドに到達し、必要なすべての処理を実行します。 6. バックエンドが応答し、応答はポリシーチェーンを戻ります。 7. 応答が HTTP キャッシュポリシーに到達します。 8. キャッシュで再度オブジェクトストアがヒットし、後で再利用できるように要求の​[キー](#key)​を保存しようとします。 9. 応答は、ポリシーチェーンの残りのポリシーを引き続き進みます。 10. 応答がクライアントに返されます。 ### [](#キャッシュヒット)キャッシュヒット キャッシュヒットの場合、HTTP キャッシュポリシーは、オブジェクトストアのキーを検索し、要求に対する応答が​[保存済みエントリ](#stored_entry)​としてすでにキャッシュされていることを検出します。要求がバックエンドに向けてポリシーチェーンを進むことはなく、キャッシュされた応答が再利用されます。 キャッシュヒットの場合、キャッシュ後にポリシーチェーンで実行される必要のあるすべてのポリシーはそれ以降実行されません。 ![http policy cache hit](/mulesoft/current/ja-jp/gateway/1.8/_images/http-policy-cache-hit.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまで他のポリシーを通過します。 3. HTTP キャッシュポリシーは、要求がすでにキャッシュにあるかどうかを確認します。 4. オブジェクトストアで​[キー](#key)​が見つかり、保存された応答が返されます。 5. 応答は、最後のポリシーに到達するまでポリシーチェーンの残りのポリシーを引き続き進みます。 6. キャッシュされた応答がクライアントに返されます。 ### [](#stored_entry)保存済みエントリ _保存済みエントリ_​は、キャッシュされた HTTP 応答です。キャッシュには、最大 1 MB のシリアル化可能データと入力ストリームを保存できます。値がこの制限を超えると、読み取りは停止し、値は保存されません。 ### [](#key)HTTP Caching Key (HTTP キャッシュキー) キャッシュは辞書として機能し、そこではキャッシュに保存された各応答が​_キー_​と呼ばれる文字列に関連付けられます。たとえば、式 #\[attributes.headers\['key'\]\] では、​`key`​ というヘッダーがエントリキーとして使用されます。​[定義済みの DataWeave 変数](https://docs.mulesoft.com/jp/gateway/1.8/policies-flex-dataweave-support#available-predefined-variables)​を含めて、文字列を返す任意の DataWeave 式を使用できます。 ### [](#キャッシュサイズとエントリ有効期限)キャッシュサイズとエントリ有効期限 キャッシュには、指定された数のエントリを特定の期間保持できます。この数は、​`Maximum Cache Entries`​ プロパティを使用して設定できます。各保存済みエントリは、一定時間キャッシュメモリに保持されます。その後、エントリは期限切れになり、再度処理する必要があります。この有効期限は、​_存続期間_​ (TTL) と呼ばれます。 キャッシュが最大項目保存数に達したときもエントリの有効期限がトリガーされます。このシナリオが発生すると、FIFO (先入れ先出し) 条件を使用してエントリが削除されます。つまり、最も早くキャッシュに到達したエントリは、TTL 値にまだ達していなくても削除されます。 ### [](#分散キャッシュ)分散キャッシュ キャッシュの各エントリは、​`Distributed`​ オプション (表を参照) を使用して、クラスター内の各ノードや Runtime Manager の複数のワーカーで共有できます。このオプションが有効になっていない場合、各ノードには独自のキャッシュメモリが割り当てられます。 ### [](#永続キャッシュ)永続キャッシュ 永続キャッシュでは、Flex レプリカが再起動しても、キャッシュの保存済みエントリを保持できます。 永続的なストアを使用するように設定された HTTP キャッシュポリシーを持つインスタンスのバージョンをアップグレードすると、ポリシーは以前のバージョンで保存されたエントリを維持しようとします。ただし、最悪のシナリオでは、キャッシュ内のエントリが無効になり、新しい要求の到着時にキャッシュが再入力されます。キャッシュ内のエントリのこの操作は自動的に実行され、ユーザーが意識することはありません。 ## [](#http-キャッシュディレクティブ)HTTP キャッシュディレクティブ HTTP キャッシュポリシーは、キャッシュをより詳細に制御するために次のヘッダーを考慮に入れて [RFC-7234](https://tools.ietf.org/html/rfc7234)​ プロトコルのいくつかの HTTP ディレクティブを解釈します。 - `Cache-Control` - `Expires` - `Date` - `Age` ### [](#cache-control)Cache-Control `Cache-Control`​ ヘッダーは要求または応答に存在します。ヘッダーの使用可能な値は次のとおりです。これらの値は、カンマで区切って組み合わせることができます。 - 要求: - `no-cache` 応答は検索されませんが、キャッシュに直接保存されます。 - `no-store` 応答はキャッシュに保存されません。ただし、応答がキャッシュ内にすでに存在する場合は、ポリシーがその応答を返します。 - 応答: - `no-store`​、​`no-cache`​、​`private` どの値でも応答はキャッシュに保存されません。 - `max-age=`, ​`s-maxage=` ``​ プレースホルダーは、応答がキャッシュに残ることができる時間 (秒) を示す有効な整数に置き換える必要があります。両方のパラメーターが定義されている場合、​`max-age`​ よりも ​`s-maxage`​ が優先されます。 ポリシーでグローバル存続期間 (TTL) 値も定義されている場合、ヘッダーで指定されている時間がグローバル TTL よりも少ないと、これらのヘッダー値がポリシーで設定されているグローバル TTL よりも優先されます。 ### [](#expires-有効期限)Expires (有効期限) 存在する場合、このヘッダーでキャッシュ内のエントリの有効期限を指定します。​`max-age`​ ディレクティブまたは ​`s-maxage`​ ディレクティブが指定されている場合、このヘッダーは無視されます。ヘッダー値は [RFC-1123](https://tools.ietf.org/html/rfc1123)​ のとおりに定義する必要があります。 ### [](#date-日付)Date (日付) `date`​ ヘッダーが [RFC-1123](https://tools.ietf.org/html/rfc1123)​ に従って定義されている場合、応答の作成日時が指定されます。定義されていない場合、​`date`​ ヘッダーが要求の受信時刻で追加されます。このヘッダーは、Cache-Control ヘッダーの ​`max-age`​ および ​`s-maxage`​ ディレクティブに定義された値と一緒に使用されます。 ### [](#age-存続期間)Age (存続期間) `age`​ ヘッダーは、date ヘッダーに指定されたキャッシュされている応答の作成以降の経過時間 (秒) を示します。このヘッダーはポリシーによって計算され、キャッシュから取得された各応答に追加されます。 有効期限は、​`cache-control`​、​`date`​、​`expires`​ ヘッダーを使用して計算されます。ただし、計算された有効期限がエントリの TTL 値で指定された存続時間を超える場合、キャッシュエントリの有効期限が切れます。 ### [](#無効化)無効化 HTTP キャッシュポリシーで ​`invalidate`​ ヘッダーが設定されている場合、キャッシュ内のエントリが無効化され、要求が再度処理されます。\[Invalidation Header (無効化ヘッダー)\] 設定のヘッダーの名前を指定して、オプションを有効にします。ヘッダーの値には、​`invalidate`​ オプションのみを設定できます。 このオプションは、キーが現在の要求に一致するエントリを無効化します。 `invalidate-all`​ このオプションは、キャッシュからすべてのエントリを無効化します。 たとえば、ポリシーで要求の次の値が設定されているとします。 - `HTTP Caching Key`​ (HTTP キャッシュキー): "#\[attributes.requestPath\]" - `Invalidation header`​ (無効化ヘッダー): "myInvalidationHeader" 次のコマンドは、キャッシュからキーが "/my/policy" のエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate”` 次の要求は、キャッシュからすべてのエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate-all”` ## [](#条件付きキャッシュ)条件付きキャッシュ 条件付きキャッシュでは、エントリをキャッシュに保存するために満たす必要がある一連の条件を設定できます。条件付きキャッシュパラメーターが設定されていない場合、すべての受信要求の応答がキャッシュに保存されます。設定されている場合、各要求のパラメーターが評価されて、現在の要求の応答を保存する必要があるかどうかが判断されます。 条件付き要求式の場合、デフォルトでは、HTTP メソッドの ​`GET`​ または ​`HEAD`​ による受信要求に対する応答のみがキャッシュされます。条件付き応答式の場合、デフォルトでは、 [RFC-7231](https://tools.ietf.org/html/rfc7231#section-6.1)​ で指定された状況コードのみがキャッシュされます。 デフォルト値についての詳細は、​[「ポリシーのパラメーターの設定」](#cpp)​を参照してください。 ## [](#faq)FAQ **Postman や類似するツールを使用しているのですが、ポリシーで何もキャッシュされないのでしょうか?** **\[Follow HTTP Caching directives (HTTP キャッシュディレクティブに従う)\]**​ パラメーターが ​`true`​ の場合、ポリシーは ​`cache-control`​ ヘッダーのディレクティブに従います。デフォルトでは、Postman などのツールでは、​`cache-control=no-cache`​ ヘッダーが要求に追加されます。そのため、Postman の設定を行わないと、ポリシーでキャッシュが無視されます。 **キーの評価がエラーになった場合はどうなりますか?** 特定の要求の式の評価がエラーになった場合、ポリシーは有効にならず、要求はポリシーチェーンの次の受け入れ先に引き続き進みます。 **このポリシーで応答の一部のみを保存できますか?** いいえ。ただし、このポリシーの前に別のポリシーを適用して、応答を変更することはできます。 **あるパラメーターではキャッシュ内で応答を検索するように設定し、別のパラメーターではその逆のアクションを実行するように設定した場合、どうなりますか?** これは、Cache-Control ヘッダーに no-store ディレクティブがある状態で応答をキャッシュに保存するように設定したときと同じになります。 この場合、応答は保存されません。キャッシュに応答を保存したり、キャッシュの応答を検索したりできるようにするには、Cache-Contro ヘッダーとキャッシュの両方を設定する必要があります。 **省略可能なパラメーターを定義しないとどうなりますか?** `invalidation`​ ヘッダーを設定していない場合、要求のキャッシュを無効化できません。 また、要求式や応答式を設定していない場合、キャッシュはすべての要求に対して使用され、すべての応答がキャッシュに保存されます (式 #\[true\])。 **\[Invalidation header (無効化ヘッダー)\] の値を変更できますか?** いいえ。変更できるのはヘッダー名のみです。 # HTTP キャッシュポリシー

ポリシー名

HTTP キャッシュ

概要

API 実装から HTTP 応答をキャッシュする

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 HTTP キャッシュポリシーでは、HTTP 応答をキャッシュして再利用できます。これらの応答をキャッシュすると、ユーザー要求の応答時間が短縮され、バックエンドの負荷が軽減されます。たとえば、要求に対する応答が変更される可能性の低いエンドポイントをバックエンドで公開する場合、HTTP キャッシュポリシーを使用して、HTTP 応答を再利用し、バックエンド要求処理をバイパスできます。 ポリシー順序で HTTP キャッシュポリシーの後に適用されるポリシーはキャッシュによって提供される応答には適用されません。たとえば、HTTP キャッシュポリシーの後に適用されるレート制限ポリシーでは、アップストリームサービスによって提供される応答のみを制限し、キャッシュによって提供される応答は制限しません。HTTP キャッシュポリシーより前にキャッシュされた応答に必要なすべてのポリシーを適用してください。
HTTP キャッシュポリシーでは、MCP および A2A サーバーインスタンスはサポートされません。
## [](#cpp)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-caching-flex config: httpCachingKey: // REQUIRED, default: "#\[attributes.requestPath\]" maxCacheEntries: // REQUIRED, default: 10000 ttl: // REQUIRED, default: 600 useHttpCacheHeaders: // REQUIRED, default: true invalidationHeader: // OPTIONAL, default: "" requestExpression: // OPTIONAL, default: "#\[attributes.method == 'GET' or attributes.method == 'HEAD'\]" responseExpression: // OPTIONAL, default: "#\[\[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501\] contains attributes.statusCode\]" distributed: // REQUIRED, default: false persistCache: // REQUIRED, default: false
パラメーター 必須または省略可能 デフォルト値 説明

httpCachingKey

必須

#[attributes.requestPath]

DataWeave 式

maxCacheEntries

必須

10000

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。

ttl

必須

600

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。

useHttpCacheHeaders

必須

true

Cache-Control ヘッダーディレクティブの使用を有効にします。

invalidationHeader

省略可能

空の文字列

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーを指定する文字列。

requestExpression

省略可能

#[attributes.method == 'GET' or attributes.method == 'HEAD']

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。

responseExpression

省略可能

#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)

distributed

必須

false

クラスター内の各ノードでキャッシュが分散されるように設定

persistCache

必須

false

レプリカの各再起動間でキャッシュが維持されるように設定
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: http-caching-flex config: httpCachingKey: "#[attributes.requestPath]" maxCacheEntries: 10000 ttl: 500 useHttpCacheHeaders: false requestExpression: "#[attributes.method == 'GET' or attributes.method == 'HEAD']" responseExpression: "#[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]" ``` #### [](#分散キャッシュリソースの設定例)分散キャッシュリソースの設定例 分散キャッシュでは、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-caching spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: http-caching-flex config: httpCachingKey: "#\[attributes.method ++ attributes.requestPath\]" useHttpCacheHeaders: true maxCacheEntries: 100 ttl: 600 distributed: true persistCache: true invalidationHeader: AGW-CACHE-CONTROL ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

HTTP Caching Key (HTTP キャッシュキー)

DataWeave 式。 デフォルト値: #[attributes.requestPath]

はい

Maximum Cache Entries (最大キャッシュエントリ)

キャッシュ内に特定の期間保存できるエントリの最大数を指定します。 デフォルト値: 10000

はい

Entry Time To Live (エントリ存続期間)

キャッシュの 1 つのエントリの有効期限が切れるまでの時間 (秒) を指定します。 デフォルト値: 600

はい

Distributed (分散)

クラスター内の各ノードでキャッシュが分散されるように設定します。 デフォルト値: false

はい

Persistent Cache (永続キャッシュ)

Flex Gateway インスタンスの各再起動間でキャッシュが維持されるように設定します。 デフォルト値: false

はい

Follow HTTP Caching directives (HTTP キャッシュディレクティブに従う)

Cache-Control ヘッダーディレクティブの使用を有効にします。 デフォルト値: true

はい

Invalidation Header (無効化ヘッダー)

1 つのエントリまたはキャッシュ全体を無効化するために使用されるヘッダーの名前。

いいえ

Conditional Request Caching Expression (条件付き要求キャッシュ式)

キャッシュされる要求を決定するために使用される DataWeave 式 (応答は条件が true の場合にのみキャッシュされる)。 デフォルト値: #[attributes.method == 'GET' or attributes.method == 'HEAD']

いいえ

Conditional Response Caching Expression (条件付き応答キャッシュ式)

キャッシュされる応答を決定するために使用される DataWeave 式 (応答は条件が true の場合のみキャッシュされる)。 デフォルト値: #[[200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501] contains attributes.statusCode]

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ HTTP 要求がエンドポイントに到達した後の次の処理は、要求がまだキャッシュにないのか (キャッシュミス)、すでにあるのか (キャッシュヒット) によって決まります。 ### [](#キャッシュミス)キャッシュミス キャッシュミスの場合、HTTP キャッシュポリシーは、送信された要求に対する応答がすでにキャッシュされているかどうかをチェックします。要求がバックエンドに到達したら、キャッシュミスの場合にのみプロセスが開始されます。次の図は、このシナリオで発生するイベントのフローを示しています。 ![Web ブラウザーとバックエンドシステム間のデータフローを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/http-policy-cache-miss.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまでポリシーチェーンの他のポリシーを進みます。 3. HTTP キャッシュポリシーは、要求がすでにオブジェクトストアにあるかどうかをチェックします。ない場合は、キャッシュミスプロセスが開始されます。 4. 要求は、他の残りのポリシーのチェーンを引き続き進みます。 5. 要求がバックエンドに到達し、必要なすべての処理を実行します。 6. バックエンドが応答し、応答はポリシーチェーンを戻ります。 7. 応答が HTTP キャッシュポリシーに到達します。 8. キャッシュで再度オブジェクトストアがヒットし、後で再利用できるように要求の​[キー](#key)​を保存しようとします。 9. 応答は、ポリシーチェーンの残りのポリシーを引き続き進みます。 10. 応答がクライアントに返されます。 ### [](#キャッシュヒット)キャッシュヒット キャッシュヒットの場合、HTTP キャッシュポリシーは、オブジェクトストアのキーを検索し、要求に対する応答が​[保存済みエントリ](#stored_entry)​としてすでにキャッシュされていることを検出します。要求がバックエンドに向けてポリシーチェーンを進むことはなく、キャッシュされた応答が再利用されます。 キャッシュヒットの場合、キャッシュ後にポリシーチェーンで実行される必要のあるすべてのポリシーはそれ以降実行されません。 ![API ゲートウェイを介した Web ブラウザーからバックエンドおよびオブジェクトストアへのデータフローを示すフローチャート図](/mulesoft/current/ja-jp/gateway/1.9/_images/http-policy-cache-hit.png) 1. クライアント (ユーザー) が API に要求を送信します。 2. 要求は、HTTP キャッシュポリシーに到達するまで他のポリシーを通過します。 3. HTTP キャッシュポリシーは、要求がすでにキャッシュにあるかどうかを確認します。 4. オブジェクトストアで​[キー](#key)​が見つかり、保存された応答が返されます。 5. 応答は、最後のポリシーに到達するまでポリシーチェーンの残りのポリシーを引き続き進みます。 6. キャッシュされた応答がクライアントに返されます。 ### [](#stored_entry)保存済みエントリ _保存済みエントリ_​は、キャッシュされた HTTP 応答です。キャッシュには、最大 1 MB のシリアル化可能データと入力ストリームを保存できます。値がこの制限を超えると、読み取りは停止し、値は保存されません。 ### [](#key)HTTP Caching Key (HTTP キャッシュキー) キャッシュは辞書として機能し、そこではキャッシュに保存された各応答が​_キー_​と呼ばれる文字列に関連付けられます。たとえば、式 #\[attributes.headers\['key'\]\] では、​`key`​ というヘッダーがエントリキーとして使用されます。​[定義済みの DataWeave 変数](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support#available-predefined-variables)​を含めて、文字列を返す任意の DataWeave 式を使用できます。 ### [](#キャッシュサイズとエントリ有効期限)キャッシュサイズとエントリ有効期限 キャッシュには、指定された数のエントリを特定の期間保持できます。この数は、​`Maximum Cache Entries`​ プロパティを使用して設定できます。各保存済みエントリは、一定時間キャッシュメモリに保持されます。その後、エントリは期限切れになり、再度処理する必要があります。この有効期限は、​_存続期間_​ (TTL) と呼ばれます。 キャッシュが最大項目保存数に達したときもエントリの有効期限がトリガーされます。このシナリオが発生すると、FIFO (先入れ先出し) 条件を使用してエントリが削除されます。つまり、最も早くキャッシュに到達したエントリは、TTL 値にまだ達していなくても削除されます。 ### [](#分散キャッシュ)分散キャッシュ キャッシュの各エントリは、​`Distributed`​ オプション (表を参照) を使用して、クラスター内の各ノードや Runtime Manager の複数のワーカーで共有できます。このオプションが有効になっていない場合、各ノードには独自のキャッシュメモリが割り当てられます。 ### [](#永続キャッシュ)永続キャッシュ 永続キャッシュでは、Flex レプリカが再起動しても、キャッシュの保存済みエントリを保持できます。 永続的なストアを使用するように設定された HTTP キャッシュポリシーを持つインスタンスのバージョンをアップグレードすると、ポリシーは以前のバージョンで保存されたエントリを維持しようとします。ただし、最悪のシナリオでは、キャッシュ内のエントリが無効になり、新しい要求の到着時にキャッシュが再入力されます。キャッシュ内のエントリのこの操作は自動的に実行され、ユーザーが意識することはありません。 ## [](#http-キャッシュディレクティブ)HTTP キャッシュディレクティブ HTTP キャッシュポリシーは、キャッシュをより詳細に制御するために次のヘッダーを考慮に入れて [RFC-7234](https://tools.ietf.org/html/rfc7234)​ プロトコルのいくつかの HTTP ディレクティブを解釈します。 - `Cache-Control` - `Expires` - `Date` - `Age` ### [](#cache-control)Cache-Control `Cache-Control`​ ヘッダーは要求または応答に存在します。ヘッダーに対して可能な値は次のとおりです。これらの値は、カンマで区切って組み合わせることができます。 - 要求: - `no-cache` 応答は検索されませんが、キャッシュに直接保存されます。 - `no-store` 応答はキャッシュに保存されません。ただし、応答がキャッシュ内にすでに存在する場合は、ポリシーがその応答を返します。 - 応答: - `no-store`​、​`no-cache`​、​`private` どの値でも応答はキャッシュに保存されません。 - `max-age=`​、​`s-maxage=` ``​ プレースホルダーは、応答がキャッシュに残ることができる時間 (秒) を示す有効な整数に置き換える必要があります。両方のパラメーターが定義されている場合、​`max-age`​ よりも ​`s-maxage`​ が優先されます。 ポリシーでグローバル存続期間 (TTL) 値も定義されている場合、ヘッダーで指定されている時間がグローバル TTL よりも少ないと、これらのヘッダー値がポリシーで設定されているグローバル TTL よりも優先されます。 ### [](#expires-有効期限)Expires (有効期限) 存在する場合、このヘッダーでキャッシュ内のエントリの有効期限を指定します。​`max-age`​ ディレクティブまたは ​`s-maxage`​ ディレクティブが指定されている場合、このヘッダーは無視されます。ヘッダー値は [RFC-1123](https://tools.ietf.org/html/rfc1123)​ のとおりに定義する必要があります。 ### [](#date-日付)Date (日付) `date`​ ヘッダーが [RFC-1123](https://tools.ietf.org/html/rfc1123)​ に従って定義されている場合、応答の作成日時が指定されます。定義されていない場合、​`date`​ ヘッダーが要求の受信時刻で追加されます。このヘッダーは、Cache-Control ヘッダーの ​`max-age`​ および ​`s-maxage`​ ディレクティブに定義された値と一緒に使用されます。 ### [](#age-存続期間)Age (存続期間) `age`​ ヘッダーは、date ヘッダーに指定されたキャッシュされている応答の作成以降の経過時間 (秒) を示します。このヘッダーはポリシーによって計算され、キャッシュから取得された各応答に追加されます。 有効期限は、​`cache-control`​、​`date`​、​`expires`​ ヘッダーを使用して計算されます。ただし、計算された有効期限がエントリの TTL 値で指定された存続時間を超える場合、キャッシュエントリの有効期限が切れます。 ### [](#無効化)無効化 HTTP キャッシュポリシーで ​`invalidate`​ ヘッダーが設定されている場合、キャッシュ内のエントリが無効化され、要求が再度処理されます。\[Invalidation Header (無効化ヘッダー)\] 設定のヘッダーの名前を指定して、オプションを有効にします。ヘッダーの値には、​`invalidate`​ オプションのみを設定できます。 このオプションは、キーが現在の要求に一致するエントリを無効化します。 `invalidate-all`​ このオプションは、キャッシュからすべてのエントリを無効化します。 たとえば、ポリシーで要求の次の値が設定されているとします。 - `HTTP Caching Key`​ (HTTP キャッシュキー): "#\[attributes.requestPath\]" - `Invalidation header`​ (無効化ヘッダー): "myInvalidationHeader" 次のコマンドは、キャッシュからキーが "/my/policy" のエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate”` 次の要求は、キャッシュからすべてのエントリを無効化します。 `curl [http:///my/policy](http://\/my/policy) -H “myInvalidationHeader:invalidate-all”` ## [](#条件付きキャッシュ)条件付きキャッシュ 条件付きキャッシュでは、エントリをキャッシュに保存するために満たす必要がある一連の条件を設定できます。条件付きキャッシュパラメーターが設定されていない場合、すべての受信要求の応答がキャッシュに保存されます。設定されている場合、各要求のパラメーターが評価されて、現在の要求の応答を保存する必要があるかどうかが判断されます。 条件付き要求式の場合、デフォルトでは、HTTP メソッドの ​`GET`​ または ​`HEAD`​ による受信要求に対する応答のみがキャッシュされます。条件付き応答式の場合、デフォルトでは、 [RFC-7231](https://tools.ietf.org/html/rfc7231#section-6.1)​ で指定された状況コードのみがキャッシュされます。 デフォルト値についての詳細は、​[「ポリシーのパラメーターの設定」](#cpp)​を参照してください。 ## [](#faq)FAQ **キーの評価がエラーになった場合はどうなりますか?** 特定の要求の式の評価がエラーになった場合、ポリシーは有効にならず、要求はポリシーチェーンの次の受け入れ先に引き続き進みます。 **このポリシーで応答の一部のみを保存できますか?** いいえ。ただし、このポリシーの前に別のポリシーを適用して、応答を変更することはできます。 **あるパラメーターではキャッシュ内で応答を検索するように設定し、別のパラメーターではその逆のアクションを実行するように設定した場合、どうなりますか?** これは、Cache-Control ヘッダーに no-store ディレクティブがある状態で応答をキャッシュに保存するように設定したときと同じになります。 この場合、応答は保存されません。キャッシュに応答を保存したり、キャッシュの応答を検索したりできるようにするには、Cache-Contro ヘッダーとキャッシュの両方を設定する必要があります。 **省略可能なパラメーターを定義しないとどうなりますか?** `invalidation`​ ヘッダーを設定していない場合、要求のキャッシュを無効化できません。 また、要求式や応答式を設定していない場合、キャッシュはすべての要求に対して使用され、すべての応答がキャッシュに保存されます (式 #\[true\])。 **\[Invalidation header (無効化ヘッダー)\] の値を変更できますか?** いいえ。変更できるのはヘッダー名のみです。 # IP ブロックリストポリシー

ポリシー名

IP ブロックリスト

概要

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP ブロックリストポリシーは、単一の IP アドレスまたは IP アドレスの範囲からの設定済み API エンドポイントへのアクセスを制御します。 IP ブロックリストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、保護対象のリソースへのアクセスを禁止します。ポリシーでは、IPv4 アドレスと IPv6 アドレスの両方がサポートされています。 DataWeave 2.0 の式により、IP がポリシーで定義されている制約 IP リストに含まれているかどうかを確認するときに使用するソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ip-blocklist-flex config: ips: // REQUIRED ipExpression: // OPTIONAL, default: "#\[attributes.headers\['x-forwarded-for'\]\]"
パラメーター 必須または省略可能 デフォルト値 説明

ips

必須

なし

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

ipExpression

省略可能

#[attributes.headers['x-forwarded-for']]

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ip-blocklist-flex config: ips: - "192.168.1.1" - "192.168.3.1/30" - "192.168.2" - "192.160" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。

ブロックリスト

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーでブロックリスト登録する IP アドレスの指定 次の情報に基づいてポリシーでブロックする IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど)。 - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスをブロックリスト登録する)要求の IP アドレスに基づいてアクセスをブロックリスト登録する 次のいずれかの方法で、要求の IP アドレスに基づいてブロックリストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.0`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスをブロックリスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスをブロックリスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) をブロックリスト登録できます。 たとえば、​`192.168.2.3`​ をブロックリスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 式を使用してサービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # IP ブロックリストポリシー

ポリシー名

IP ブロックリスト

概要

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP ブロックリストポリシーは、単一の IP アドレスまたは IP アドレスの範囲からの設定済み API エンドポイントへのアクセスを制御します。 IP ブロックリストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、保護対象のリソースへのアクセスを禁止します。ポリシーでは、IPv4 アドレスと IPv6 アドレスの両方がサポートされています。 DataWeave 2.0 の式により、IP がポリシーで定義されている制約 IP リストに含まれているかどうかを確認するときに使用するソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して IP ブロックリストポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ip-blocklist-flex config: ips: // REQUIRED ipExpression: // OPTIONAL, default: "#\[attributes.headers\['x-forwarded-for'\]\]"
パラメーター 必須または省略可能 デフォルト値 説明

ips

必須

なし

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

ipExpression

省略可能

#[attributes.headers['x-forwarded-for']]

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ip-blocklist-flex config: ips: - "192.168.1.1" - "192.168.3.1/30" - "192.168.2" - "192.160" ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI から IP ブロックリスト登録済みリストポリシーを API に適用する場合は、以下のパラメーターを設定します。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。

ブロックリスト

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーでブロックリスト登録する IP アドレスの指定 次の情報に基づいてポリシーでブロックする IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど)。 - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスをブロックリスト登録する)要求の IP アドレスに基づいてアクセスをブロックリスト登録する 次のいずれかの方法で、要求の IP アドレスに基づいてブロックリストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.0`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスをブロックリスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスをブロックリスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) をブロックリスト登録できます。 たとえば、​`192.168.2.3`​ をブロックリスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 式を使用してサービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # IP ブロックリストポリシー

ポリシー名

IP ブロックリスト

概要

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP ブロックリストポリシーは、単一の IP アドレスまたは IP アドレスの範囲からの設定済み API エンドポイントへのアクセスを制御します。 IP ブロックリストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、保護対象のリソースへのアクセスを禁止します。ポリシーでは、IPv4 アドレスと IPv6 アドレスの両方がサポートされています。 DataWeave 2.0 の式により、IP がポリシーで定義されている制約 IP リストに含まれているかどうかを確認するときに使用するソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ip-blocklist-flex config: ips: // REQUIRED ipExpression: // OPTIONAL, default: "#\[attributes.headers\['x-forwarded-for'\]\]"
パラメーター 必須または省略可能 デフォルト値 説明

ips

必須

なし

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

ipExpression

省略可能

#[attributes.headers['x-forwarded-for']]

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ip-blocklist-flex config: ips: - "192.168.1.1" - "192.168.3.1/30" - "192.168.2" - "192.160" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。

ブロックリスト

API からブロックする IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。詳細は、​「ポリシーでブロックリスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーでブロックリスト登録する IP アドレスの指定 次の情報に基づいてポリシーでブロックする IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど)。 - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスをブロックリスト登録する)要求の IP アドレスに基づいてアクセスをブロックリスト登録する 次のいずれかの方法で、要求の IP アドレスに基づいてブロックリストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.0`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスをブロックリスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスをブロックリスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) をブロックリスト登録できます。 たとえば、​`192.168.2.3`​ をブロックリスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 式を使用してサービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # IP 許可リストポリシー

ポリシー名

IP 許可リスト

概要

IP アドレスのリストまたは範囲からのアクセス要求を許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP 許可リストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、指定された IP アドレスのリストまたは範囲に保護対象のリソースへのアクセスを許可します。ポリシーでは、IPv4 アドレスと IPv6 アドレスの両方がサポートされています。 DataWeave 2.0 の式により、IP がポリシーの制約 IP リストに含まれているかどうかを確認するためにポリシーで使用されるソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ip-allowlist-flex config: ips: // REQUIRED ipExpression: // OPTIONAL, default: "#\[attributes.headers\['x-forwarded-for'\]\]"
パラメーター 必須または省略可能 デフォルト値 説明

ips

必須

なし

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

ipExpression

省略可能

#[attributes.headers['x-forwarded-for']]

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ip-allowlist-flex config: ips: - "192.168.1.1" - "192.168.3.1/30" - "192.168.2" - "192.160" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0。

許可リスト

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーで許可リスト登録する IP アドレスの指定 次の情報に基づいてポリシーへのアクセスを許可する IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど) - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスを許可リストに登録する)要求の IP アドレスに基づいてアクセスを許可リストに登録する 次のいずれかの方法で、要求の IP アドレスに基づいて許可リストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを \[Allowlist (許可リスト)\] 項目に指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.01`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスを許可リスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスを許可リスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) を許可リスト登録できます。 たとえば、​`192.168.2.3`​ (非公開 IP) を許可リスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ (公開 IP) である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 式を使用してサービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # IP 許可リストポリシー

ポリシー名

IP 許可リスト

概要

IP アドレスのリストまたは範囲からのアクセス要求を許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP 許可リストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、指定された IP アドレスのリストまたは範囲に保護対象のリソースへのアクセスを許可します。ポリシーでは、IPv4 アドレスと IPv6 アドレスの両方がサポートされています。 DataWeave 2.0 の式により、IP がポリシーの制約 IP リストに含まれているかどうかを確認するためにポリシーで使用されるソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して IP 許可リストポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ip-allowlist-flex config: ips: // REQUIRED ipExpression: // OPTIONAL, default: "#\[attributes.headers\['x-forwarded-for'\]\]"
パラメーター 必須または省略可能 デフォルト値 説明

ips

必須

なし

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

ipExpression

省略可能

#[attributes.headers['x-forwarded-for']]

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ip-allowlist-flex config: ips: - "192.168.1.1" - "192.168.3.1/30" - "192.168.2" - "192.160" ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI から IP 許可リストポリシーを API に適用する場合は、以下のパラメーターを設定します。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0。

許可リスト

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーで許可リスト登録する IP アドレスの指定 次の情報に基づいてポリシーへのアクセスを許可する IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど) - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスを許可リストに登録する)要求の IP アドレスに基づいてアクセスを許可リストに登録する 次のいずれかの方法で、要求の IP アドレスに基づいて許可リストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを \[Allowlist (許可リスト)\] 項目に指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.01`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスを許可リスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスを許可リスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) を許可リスト登録できます。 たとえば、​`192.168.2.3`​ (非公開 IP) を許可リスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ (公開 IP) である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 式を使用してサービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # IP 許可リストポリシー

ポリシー名

IP 許可リスト

概要

IP アドレスのリストまたは範囲からのアクセス要求を許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 IP 許可リストポリシーは、ソース IP (ポリシーの設定時に指定します) が個別 IP のリストまたは IP 範囲と一致した場合に、指定された IP アドレスのリストまたは範囲に保護対象のリソースへのアクセスを許可します。ポリシーでは、IPv4 アドレスと IPv6 アドレスの両方がサポートされています。 DataWeave 2.0 の式により、IP がポリシーの制約 IP リストに含まれているかどうかを確認するためにポリシーで使用されるソース IP を定義します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ip-allowlist-flex config: ips: // REQUIRED ipExpression: // OPTIONAL, default: "#\[attributes.headers\['x-forwarded-for'\]\]"
パラメーター 必須または省略可能 デフォルト値 説明

ips

必須

なし

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

ipExpression

省略可能

#[attributes.headers['x-forwarded-for']]

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0 式。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ip-allowlist-flex config: ips: - "192.168.1.1" - "192.168.3.1/30" - "192.168.2" - "192.160" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

IP 式

この API 要求から IP アドレスを抽出するために使用する DataWeave 2.0。

許可リスト

API へのアクセスを許可する IP アドレスのリスト。IP または IP 範囲は一度に 1 つずつ、必要なだけ何度も定義できます。 詳細は、​「ポリシーで許可リスト登録する IP アドレスの指定」​を参照してください。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション。
## [](#specifying_ip_address)ポリシーで許可リスト登録する IP アドレスの指定 次の情報に基づいてポリシーへのアクセスを許可する IP アドレスを指定します。 - 要求の IP アドレス。 - 特定の DataWeave 式を解決することで決定される発生元 IP アドレス ( [x-Forwarded-For](https://en.wikipedia.org/wiki/X-Forwarded-For)​ ヘッダーなど) - その他のすべての発生元。 ### [](#要求の-ip-アドレスに基づいてアクセスを許可リストに登録する)要求の IP アドレスに基づいてアクセスを許可リストに登録する 次のいずれかの方法で、要求の IP アドレスに基づいて許可リストにアクセスします。 - 特定の IP アドレスを定義するには、そのアドレスのみを \[Allowlist (許可リスト)\] 項目に指定します (例: `192.168.1.1`​)。 - アドレスのサブセットを定義するには、サブセットマスクを指定します。たとえば、​`192.168.3.1/30`​ など (これには、統合範囲 ​`192.168.3.01`​ ～ ​`192.168.3.3`​ が含まれます)。 - IP アドレスの範囲全体を定義するには、許可する IP アドレスの関連オクテットを指定します。たとえば、「​`192.168`​>」と設定すると、​`192.168.0.0`​ ～ ​`192.168.255.255`​ の IP アドレスが含まれます。 ### [](#x-forwarded-for-ヘッダーの発生元-ip-アドレスに基づいてアクセスを許可リスト登録する)x-Forwarded-For ヘッダーの発生元 IP アドレスに基づいてアクセスを許可リスト登録する クライアントが HTTP プロキシまたはロードバランサーを介して API に接続している場合、要求に含まれるアドレスではなく、クライアントの特定の IP アドレス (要求の発生元 IP アドレス) を許可リスト登録できます。 たとえば、​`192.168.2.3`​ (非公開 IP) を許可リスト登録して、HTTP プロキシを介して接続しているクライアントのアドレスが ​`92.40.1.255`​ (公開 IP) である場合、クライアントの要求は、プロキシを使用した公開アドレスで表示されます。 通常、アプリケーションは ​`X-Forwarded-For`​ ヘッダーを使用して、エンドポイントにリダイレクトされた要求の発生元 IP アドレスを識別します。 ポリシーで DataWeave 2.0 式を使用してサービスに ​`x-Forwarded-For`​ ヘッダー内の IP アドレスを探すように指示できます。 ポリシーパラメーターの \[IP expression (IP 式)\] 項目で IP アドレスを指定すると、Anypoint Platform は要求の ​`x-Forwarded-For`​ ヘッダーの連結値に含まれる最初の IP アドレスを参照するように指示されます。 # Jenkins Pipeline と Anypoint CLI を使用した Flex Gateway の自動化 Jenkins Pipeline を使用して、接続モードでの Flex Gateway のワークフローを自動化できます。Jenkins Pipeline を使用すると、Flex Gateway を登録して実行し、Anypoint CLI の機能 (API インスタンスの作成やデプロイなど) を使用できます。 API Manager CLI のその他の機能を追加するには、[API Manager の CLI](https://docs.mulesoft.com/jp/anypoint-cli/latest/api-mgr)を参照してください。 このチュートリアルには、異なるコードブロックを含む異なる手順があります。手順を進めながら、コードブロックを同じ Jenkinsfile に追加します。Jenkins Pipeline で使用される構文についての詳細は、 [Jenkins Pipeline ドキュメント](https://www.jenkins.io/doc/book/pipeline/)​を参照してください。
Anypoint CLI を使用した Flex Gateway の自動化は、API Manager API を使用した Flex Gateway の自動化と多くの類似点があります。API Manger API 要求を使用して Flex Gateway を自動化するには、Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化を参照してください。
## [](#始める前に)始める前に Jenkins Pipeline をデプロイする前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)​。 2. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 1. **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]**​ および ​**\[Manage Servers (サーバーの管理)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** - 一般: **\[View Organization (組織の表示)\]** 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 3. 作成または適用する Exchange アセット (API) のグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.2`​ です。 4. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#初期設定)初期設定 API インスタンスを作成して Flex Gateway にデプロイする前に、次の手順を完了する必要があります。 1. [役立つ関数を定義する](#define-useful-functions)​。 2. [役立つパラメーターを定義する](#define-useful-parameters)​。 3. [Anypoint CLI 4.x をインストールする](#install-anypoint-cli-4-x)​。 4. [登録して実行する](#register-and-run)​。 これらの Pipeline フェーズを実装したら、API を管理するための API Manager CLI 要求を作成して Pipeline をカスタマイズできます。 ### [](#役立つ関数を定義する)役立つ関数を定義する まず、Jenkinsfile で ​`pipeline`​ ブロックの前にこれらの役立つ関数を定義します。 ```Jenkinsfile def parseYamlFile(String file) { object = readYaml file: file return object } def getAPIInstanceID(String file) { return readFile(file: file).split(' ').last().replace('\n', '').trim() } ``` ### [](#役立つパラメーターを定義する)役立つパラメーターを定義する Jenkins Pipeline のコマンドは一部のパラメーターを再利用するため、Jenkinsfile の先頭でパラメーターを定義すると役立ちます。 含まれているパラメーター定義をテンプレートとして使用して、追加の API またはポリシーに必要なパラメーターを定義することもできます。 パラメーターを定義する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: Flex ゲートウェイの名前 2. サンプルコンテンツを置き換えたら、パラメーター定義を Jenkinsfile に追加して、すべてのパラメーターが存在するかどうかを検証します。​`stages`​ ブロックの前の ​`pipeline`​ ブロックでパラメーターを定義します。 ```Jenkinsfile parameters { string(name: 'ENV_ID', defaultValue: '', description: 'Your environment id') string(name: 'ORG_ID', defaultValue: '', description: 'Your organization id') string(name: 'FLEX_VERSION', defaultValue: '', description: 'Flex version to run') string(name: 'CONNECTED_APP_CLIENT_ID', defaultValue: '', description: 'Your connected app client id') string(name: 'CONNECTED_APP_CLIENT_SECRET', defaultValue: '', description: 'The id of the http api exchange asset') string(name: 'EXCHANGE_ASSET_VERSION', defaultValue: '', description: 'The version of the http api exchange asset') string(name: 'GATEWAY_NAME', defaultValue: '', description: 'Unique gateway name') } ``` 3. Jenkinsfile で check parameters ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Check parameters') { steps { script { if (!params.ENV_ID || !params.ORG_ID || !params.GATEWAY_NAME || !params.FLEX_VERSION || !params.CONNECTED_APP_CLIENT_ID || !params.CONNECTED_APP_CLIENT_SECRET || !params.EXCHANGE_ASSET_ID || !params.EXCHANGE_ASSET_VERSION) { error("Not all parameters where specified") } } } } ``` このフェーズが失敗した場合は、不足しているパラメーターを指定して Pipeline を再実行します。 ## [](#anypoint-cli-4-x-のインストール)Anypoint CLI 4.x のインストール Anypoint CLI 4.x を Docker コンテナにインストールするには、Jenkinsfile で ​`install Anypoint CLI 4.x`​ stage を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Install anypoint-cli-v4') { steps { script { sh """ docker run --name container-anypoint-cli-v4 -d node:16 \ sh -c " npm install -g anypoint-cli-v4 ; anypoint-cli-v4 plugins:install anypoint-cli-api-mgr-plugin; \ while :; do sleep 1; done" """ sh """ docker exec container-anypoint-cli-v4 \ sh -c "while ! anypoint-cli-v4 plugins 2> /dev/null | grep -q "anypoint-cli-api-mgr-plugin"; do :; done" """ } } } ``` ### [](#登録して実行する)登録して実行する Jenkinsfile で登録フェーズと実行フェーズを ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Register flex gateway') { steps { script { sh """ docker run --entrypoint flexctl \ -v ${pwd()}:/registration -u 0 mulesoft/flex-gateway:${params.FLEX_VERSION} \ register \ --client-id=${params.CONNECTED_APP_CLIENT_ID} \ --client-secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --environment=${params.ENV_ID} \ --connected=true \ --organization=${params.ORG_ID} \ --output-directory=/registration \ ${params.GATEWAY_NAME} """ sh """ grep "name: registration" registration.yaml """ } } } stage('Run flex gateway') { steps { script { sh """ docker run --name flex-gw -d \ -v ${pwd()}:/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8082:8082 \ mulesoft/flex-gateway:${params.FLEX_VERSION} """ } } } ``` ## [](#api-インスタンスを作成する)API インスタンスを作成する Anypoint CLI 4.x をインストールしたら、API インスタンスを作成して Flex Gateway にデプロイできます。 このステップを繰り返して、複数の API インスタンスを追加できます。その他の API 設定フラグについては、​[api-mgr:api:manage コマンド](https://docs.mulesoft.com/jp/anypoint-cli/latest/api-mgr#api-mgr-api-manage)​を参照してください。 Jenkinsfile で create API instance ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Create API Instance") { steps { script { sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:api:manage ${params.EXCHANGE_ASSET_ID} ${params.EXCHANGE_ASSET_VERSION} \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --isFlex --withProxy --deploymentType=hybrid --scheme=http --port=8082 \ --uri=https://httpbin.org:443 --path=/httpbin > api-response """ } } } ```
たとえば、このフェーズでは、ポート ​8082​ および ​/httpbin​ パスでリスンし、​https://httpbin.org/443​ にプロキシする API インスタンスを作成します。
## [](#適用基本認証ポリシーを適用する)適用基本認証ポリシーを適用する API インスタンスを作成したら、その API インスタンスにポリシーを適用できます。 このフェーズは ​[基本認証: 簡易ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-basic-auth-simple) as an example, but you can apply any Connected Mode policy. To find additional policies, see [Included Policies Directory](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory)​ に適用されます。 ポリシーを適用する手順は次のとおりです。 1. 次の情報を収集します。 - ポリシー GAV - ``​: Exchange のポリシーグループ ID (例: `68ef9520-24e9-4cf2-b2f5-620025690913`​) - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.2`​) - `"configurationData"`​: ポリシー設定データ 設定データ項目はポリシーに依存します。基本認証: 簡易ポリシーでは、​`"username"`​ および ​`"password"`​ パラメーターが使用されます。 2. サンプルコンテンツを置き換えたら、Jenkinsfile で apply basic authentication policy ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Apply Basic Authentication Policy to API Instance") { steps { script { def apiInstanceId = getAPIInstanceID('api-response') sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:policy:apply ${apiInstanceId} 'http-basic-authentication' \ --policyVersion='1.3.1' --groupId '68ef9520-24e9-4cf2-b2f5-620025690913' \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ -c '{"username": "user", "password": "test"}' """ } } } ```
たとえば、このフェーズでは、基本認証: 簡易ポリシーに関連付けられたポリシー GAV および ​"configurationData"​ が使用されます。
## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API インスタンスを作成したら、そのインスタンスをデプロイできます。 新しいインスタンスをデプロイするには、Jenkinsfile で deploy API ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Deploy API") { steps { script { sleep(time:15, unit:"SECONDS") def registration_file = parseYamlFile('registration.yaml') def apiInstanceId = getAPIInstanceID('api-response') sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:api:deploy ${apiInstanceId} \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --target=${registration_file.spec.platformConnection.agentId[0]} --gatewayVersion=${params.FLEX_VERSION} """ } } } ``` ## [](#api-インスタンスがデプロイされていることを検証する)API インスタンスがデプロイされていることを検証する API インスタンスをデプロイしたら、Jenkinsfile で validate deployment ​`stage`​ を ​`stages`​ ブロックに追加して、インスタンスがデプロイされているかどうかを検証します。 ```Jenkinsfile stage("Validate Deployment") { steps { script { sleep(time:10, unit:"SECONDS") def unauthorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v", returnStdout: true).trim().toInteger() if (unauthorized_status_code != 401) { error("401 status code expected but the status code obtained is ${unauthorized_status_code}") } def authorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v -u user:test", returnStdout: true).trim().toInteger() if (authorized_status_code != 200) { error("200 status code expected but the status code obtained is ${unauthorized_status_code}") } } } } ``` ## [](#flex-gateway-を停止して登録ファイルをアーカイブする)Flex Gateway を停止して登録ファイルをアーカイブする 次のコードブロックを使用して、登録ファイルをアーカイブし、Flex Gateway を実行している Docker コンテナを削除します。​`stages`​ ブロックの後の ​`pipeline`​ ブロックに ​`post`​ ブロックを追加します。 ```Jenkinsfile post { success { script { // Archive the build output artifacts. archiveArtifacts artifacts: 'registration.yaml' } } always { script { sh(script: "docker rm -f container-anypoint-cli-v4 flex-gw") } } } ``` ## [](#関連情報)関連情報 - [Anypoint Platform CLI 4.x の使用開始](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [接続モードで接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-app)​。 - [API Manager API を使用した Flex Gateway の管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-manage-public-api) # Jenkins Pipeline と Anypoint CLI を使用した Flex Gateway の自動化 Jenkins Pipeline を使用して、接続モードでの Flex Gateway のワークフローを自動化できます。Jenkins Pipeline を使用すると、Flex Gateway を登録して実行し、Anypoint CLI の機能 (API インスタンスの作成やデプロイなど) を使用できます。 API Manager CLI のその他の機能を追加するには、[API Manager の CLI](https://docs.mulesoft.com/jp/anypoint-cli/latest/api-mgr)を参照してください。 このチュートリアルには、異なるコードブロックを含む異なる手順があります。手順を進めながら、コードブロックを同じ Jenkinsfile に追加します。Jenkins Pipeline で使用される構文についての詳細は、 [Jenkins Pipeline ドキュメント](https://www.jenkins.io/doc/book/pipeline/)​を参照してください。
Anypoint CLI を使用した Flex Gateway の自動化は、API Manager API を使用した Flex Gateway の自動化と多くの類似点があります。API Manger API 要求を使用して Flex Gateway を自動化するには、Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化を参照してください。
## [](#始める前に)始める前に Jenkins Pipeline をデプロイする前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)​。 2. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 1. **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]**​ および ​**\[Manage Servers (サーバーの管理)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** - 一般: **\[View Organization (組織の表示)\]** 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 3. 作成または適用する Exchange アセット (API) のグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.2`​ です。 4. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#初期設定)初期設定 API インスタンスを作成して Flex Gateway にデプロイする前に、次の手順を完了する必要があります。 1. [役立つ関数を定義する](#define-useful-functions)​。 2. [役立つパラメーターを定義する](#define-useful-parameters)​。 3. [Anypoint CLI 4.x をインストールする](#install-anypoint-cli-4-x)​。 4. [登録して実行する](#register-and-run)​。 これらの Pipeline フェーズを実装したら、API を管理するための API Manager CLI 要求を作成して Pipeline をカスタマイズできます。 ### [](#役立つ関数を定義する)役立つ関数を定義する まず、Jenkinsfile で ​`pipeline`​ ブロックの前にこれらの役立つ関数を定義します。 ```Jenkinsfile def parseYamlFile(String file) { object = readYaml file: file return object } def getAPIInstanceID(String file) { return readFile(file: file).split(' ').last().replace('\n', '').trim() } ``` ### [](#役立つパラメーターを定義する)役立つパラメーターを定義する Jenkins Pipeline のコマンドは一部のパラメーターを再利用するため、Jenkinsfile の先頭でパラメーターを定義すると役立ちます。 含まれているパラメーター定義をテンプレートとして使用して、追加の API またはポリシーに必要なパラメーターを定義することもできます。 パラメーターを定義する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: Flex ゲートウェイの名前 2. サンプルコンテンツを置き換えたら、パラメーター定義を Jenkinsfile に追加して、すべてのパラメーターが存在するかどうかを検証します。​`stages`​ ブロックの前の ​`pipeline`​ ブロックでパラメーターを定義します。 ```Jenkinsfile parameters { string(name: 'ENV_ID', defaultValue: '', description: 'Your environment id') string(name: 'ORG_ID', defaultValue: '', description: 'Your organization id') string(name: 'FLEX_VERSION', defaultValue: '', description: 'Flex version to run') string(name: 'CONNECTED_APP_CLIENT_ID', defaultValue: '', description: 'Your connected app client id') string(name: 'CONNECTED_APP_CLIENT_SECRET', defaultValue: '', description: 'The id of the http api exchange asset') string(name: 'EXCHANGE_ASSET_VERSION', defaultValue: '', description: 'The version of the http api exchange asset') string(name: 'GATEWAY_NAME', defaultValue: '', description: 'Unique gateway name') } ``` 3. Jenkinsfile で check parameters ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Check parameters') { steps { script { if (!params.ENV_ID || !params.ORG_ID || !params.GATEWAY_NAME || !params.FLEX_VERSION || !params.CONNECTED_APP_CLIENT_ID || !params.CONNECTED_APP_CLIENT_SECRET || !params.EXCHANGE_ASSET_ID || !params.EXCHANGE_ASSET_VERSION) { error("Not all parameters where specified") } } } } ``` このフェーズが失敗した場合は、不足しているパラメーターを指定して Pipeline を再実行します。 ## [](#anypoint-cli-4-x-のインストール)Anypoint CLI 4.x のインストール Anypoint CLI 4.x を Docker コンテナにインストールするには、Jenkinsfile で ​`install Anypoint CLI 4.x`​ stage を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Install anypoint-cli-v4') { steps { script { sh """ docker run --name container-anypoint-cli-v4 -d node:16 \ sh -c " npm install -g anypoint-cli-v4 ; anypoint-cli-v4 plugins:install anypoint-cli-api-mgr-plugin; \ while :; do sleep 1; done" """ sh """ docker exec container-anypoint-cli-v4 \ sh -c "while ! anypoint-cli-v4 plugins 2> /dev/null | grep -q "anypoint-cli-api-mgr-plugin"; do :; done" """ } } } ``` ### [](#登録して実行する)登録して実行する Jenkinsfile で登録フェーズと実行フェーズを ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Register flex gateway') { steps { script { sh """ docker run --entrypoint flexctl \ -v ${pwd()}:/registration -u 0 mulesoft/flex-gateway:${params.FLEX_VERSION} \ register \ --client-id=${params.CONNECTED_APP_CLIENT_ID} \ --client-secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --environment=${params.ENV_ID} \ --connected=true \ --organization=${params.ORG_ID} \ --output-directory=/registration \ ${params.GATEWAY_NAME} """ sh """ grep "name: registration" registration.yaml """ } } } stage('Run flex gateway') { steps { script { sh """ docker run --name flex-gw -d \ -v ${pwd()}:/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8082:8082 \ mulesoft/flex-gateway:${params.FLEX_VERSION} """ } } } ``` ## [](#api-インスタンスを作成する)API インスタンスを作成する Anypoint CLI 4.x をインストールしたら、API インスタンスを作成して Flex Gateway にデプロイできます。 このステップを繰り返して、複数の API インスタンスを追加できます。その他の API 設定フラグについては、​[api-mgr:api:manage コマンド](https://docs.mulesoft.com/jp/anypoint-cli/latest/api-mgr#api-mgr-api-manage)​を参照してください。 Jenkinsfile で create API instance ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Create API Instance") { steps { script { sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:api:manage ${params.EXCHANGE_ASSET_ID} ${params.EXCHANGE_ASSET_VERSION} \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --isFlex --withProxy --deploymentType=hybrid --scheme=http --port=8082 \ --uri=https://httpbin.org:443 --path=/httpbin > api-response """ } } } ```
たとえば、このフェーズでは、ポート ​8082​ および ​/httpbin​ パスでリスンし、​https://httpbin.org/443​ にプロキシする API インスタンスを作成します。
## [](#適用基本認証ポリシーを適用する)適用基本認証ポリシーを適用する API インスタンスを作成したら、その API インスタンスにポリシーを適用できます。 このフェーズは ​[基本認証: 簡易ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-basic-auth-simple) as an example, but you can apply any Connected Mode policy. To find additional policies, see [Included Policies Directory](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory)​ に適用されます。 ポリシーを適用する手順は次のとおりです。 1. 次の情報を収集します。 - ポリシー GAV - ``​: Exchange のポリシーグループ ID (例: `68ef9520-24e9-4cf2-b2f5-620025690913`​) - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.2`​) - `"configurationData"`​: ポリシー設定データ 設定データ項目はポリシーに依存します。基本認証: 簡易ポリシーでは、​`"username"`​ および ​`"password"`​ パラメーターが使用されます。 2. サンプルコンテンツを置き換えたら、Jenkinsfile で apply basic authentication policy ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Apply Basic Authentication Policy to API Instance") { steps { script { def apiInstanceId = getAPIInstanceID('api-response') sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:policy:apply ${apiInstanceId} 'http-basic-authentication' \ --policyVersion='1.3.1' --groupId '68ef9520-24e9-4cf2-b2f5-620025690913' \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ -c '{"username": "user", "password": "test"}' """ } } } ```
たとえば、このフェーズでは、基本認証: 簡易ポリシーに関連付けられたポリシー GAV および ​"configurationData"​ が使用されます。
## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API インスタンスを作成したら、そのインスタンスをデプロイできます。 新しいインスタンスをデプロイするには、Jenkinsfile で deploy API ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Deploy API") { steps { script { sleep(time:15, unit:"SECONDS") def registration_file = parseYamlFile('registration.yaml') def apiInstanceId = getAPIInstanceID('api-response') sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:api:deploy ${apiInstanceId} \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --target=${registration_file.spec.platformConnection.agentId[0]} --gatewayVersion=${params.FLEX_VERSION} """ } } } ``` ## [](#api-インスタンスがデプロイされていることを検証する)API インスタンスがデプロイされていることを検証する API インスタンスをデプロイしたら、Jenkinsfile で validate deployment ​`stage`​ を ​`stages`​ ブロックに追加して、インスタンスがデプロイされているかどうかを検証します。 ```Jenkinsfile stage("Validate Deployment") { steps { script { sleep(time:10, unit:"SECONDS") def unauthorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v", returnStdout: true).trim().toInteger() if (unauthorized_status_code != 401) { error("401 status code expected but the status code obtained is ${unauthorized_status_code}") } def authorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v -u user:test", returnStdout: true).trim().toInteger() if (authorized_status_code != 200) { error("200 status code expected but the status code obtained is ${unauthorized_status_code}") } } } } ``` ## [](#flex-gateway-を停止して登録ファイルをアーカイブする)Flex Gateway を停止して登録ファイルをアーカイブする 次のコードブロックを使用して、登録ファイルをアーカイブし、Flex Gateway を実行している Docker コンテナを削除します。​`stages`​ ブロックの後の ​`pipeline`​ ブロックに ​`post`​ ブロックを追加します。 ```Jenkinsfile post { success { script { // Archive the build output artifacts. archiveArtifacts artifacts: 'registration.yaml' } } always { script { sh(script: "docker rm -f container-anypoint-cli-v4 flex-gw") } } } ``` ## [](#関連情報)関連情報 - [Anypoint Platform CLI 4.x の使用開始](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [接続モードで接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-app)​。 - [API Manager API を使用した Flex Gateway の管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-manage-public-api) # Jenkins Pipeline と Anypoint CLI を使用した Flex Gateway の自動化 Jenkins Pipeline を使用して、接続モードでの Flex Gateway のワークフローを自動化できます。Jenkins Pipeline を使用すると、Flex Gateway を登録して実行し、Anypoint CLI の機能 (API インスタンスの作成やデプロイなど) を使用できます。 API Manager CLI のその他の機能を追加するには、[API Manager の CLI](https://docs.mulesoft.com/jp/anypoint-cli/latest/api-mgr)を参照してください。 このチュートリアルには、異なるコードブロックを含む異なる手順があります。手順を進めながら、コードブロックを同じ Jenkinsfile に追加します。Jenkins Pipeline で使用される構文についての詳細は、 [Jenkins Pipeline ドキュメント](https://www.jenkins.io/doc/book/pipeline/)​を参照してください。
Anypoint CLI を使用した Flex Gateway の自動化は、API Manager API を使用した Flex Gateway の自動化と多くの類似点があります。API Manger API 要求を使用して Flex Gateway を自動化するには、Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化を参照してください。
## [](#始める前に)始める前に Jenkins Pipeline をデプロイする前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)​。 2. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 1. **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]**​ および ​**\[Manage Servers (サーバーの管理)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** - 一般: **\[View Organization (組織の表示)\]** 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 3. 作成または適用する Exchange アセット (API) のグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.2`​ です。 4. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#初期設定)初期設定 API インスタンスを作成して Flex Gateway にデプロイする前に、次の手順を完了する必要があります。 1. [役立つ関数を定義する](#define-useful-functions)​。 2. [役立つパラメーターを定義する](#define-useful-parameters)​。 3. [Anypoint CLI 4.x をインストールする](#install-anypoint-cli-4-x)​。 4. [登録して実行する](#register-and-run)​。 これらの Pipeline フェーズを実装したら、API を管理するための API Manager CLI 要求を作成して Pipeline をカスタマイズできます。 ### [](#役立つ関数を定義する)役立つ関数を定義する まず、Jenkinsfile で ​`pipeline`​ ブロックの前にこれらの役立つ関数を定義します。 ```Jenkinsfile def parseYamlFile(String file) { object = readYaml file: file return object } def getAPIInstanceID(String file) { return readFile(file: file).split(' ').last().replace('\n', '').trim() } ``` ### [](#役立つパラメーターを定義する)役立つパラメーターを定義する Jenkins Pipeline のコマンドは一部のパラメーターを再利用するため、Jenkinsfile の先頭でパラメーターを定義すると役立ちます。 含まれているパラメーター定義をテンプレートとして使用して、追加の API またはポリシーに必要なパラメーターを定義することもできます。 パラメーターを定義する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: Flex ゲートウェイの名前 2. サンプルコンテンツを置き換えたら、パラメーター定義を Jenkinsfile に追加して、すべてのパラメーターが存在するかどうかを検証します。​`stages`​ ブロックの前の ​`pipeline`​ ブロックでパラメーターを定義します。 ```Jenkinsfile parameters { string(name: 'ENV_ID', defaultValue: '', description: 'Your environment id') string(name: 'ORG_ID', defaultValue: '', description: 'Your organization id') string(name: 'FLEX_VERSION', defaultValue: '', description: 'Flex version to run') string(name: 'CONNECTED_APP_CLIENT_ID', defaultValue: '', description: 'Your connected app client id') string(name: 'CONNECTED_APP_CLIENT_SECRET', defaultValue: '', description: 'The id of the http api exchange asset') string(name: 'EXCHANGE_ASSET_VERSION', defaultValue: '', description: 'The version of the http api exchange asset') string(name: 'GATEWAY_NAME', defaultValue: '', description: 'Unique gateway name') } ``` 3. Jenkinsfile で check parameters ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Check parameters') { steps { script { if (!params.ENV_ID || !params.ORG_ID || !params.GATEWAY_NAME || !params.FLEX_VERSION || !params.CONNECTED_APP_CLIENT_ID || !params.CONNECTED_APP_CLIENT_SECRET || !params.EXCHANGE_ASSET_ID || !params.EXCHANGE_ASSET_VERSION) { error("Not all parameters where specified") } } } } ``` このフェーズが失敗した場合は、不足しているパラメーターを指定して Pipeline を再実行します。 ## [](#anypoint-cli-4-x-のインストール)Anypoint CLI 4.x のインストール Anypoint CLI 4.x を Docker コンテナにインストールするには、Jenkinsfile で ​`install Anypoint CLI 4.x`​ stage を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Install anypoint-cli-v4') { steps { script { sh """ docker run --name container-anypoint-cli-v4 -d node:16 \ sh -c " npm install -g anypoint-cli-v4 ; anypoint-cli-v4 plugins:install anypoint-cli-api-mgr-plugin; \ while :; do sleep 1; done" """ sh """ docker exec container-anypoint-cli-v4 \ sh -c "while ! anypoint-cli-v4 plugins 2> /dev/null | grep -q "anypoint-cli-api-mgr-plugin"; do :; done" """ } } } ``` ### [](#登録して実行する)登録して実行する Jenkinsfile で登録フェーズと実行フェーズを ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Register flex gateway') { steps { script { sh """ docker run --entrypoint flexctl \ -v ${pwd()}:/registration -u 0 mulesoft/flex-gateway:${params.FLEX_VERSION} \ register \ --client-id=${params.CONNECTED_APP_CLIENT_ID} \ --client-secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --environment=${params.ENV_ID} \ --connected=true \ --organization=${params.ORG_ID} \ --output-directory=/registration \ ${params.GATEWAY_NAME} """ sh """ grep "name: registration" registration.yaml """ } } } stage('Run flex gateway') { steps { script { sh """ docker run --name flex-gw -d \ -v ${pwd()}:/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8082:8082 \ mulesoft/flex-gateway:${params.FLEX_VERSION} """ } } } ``` ## [](#api-インスタンスを作成する)API インスタンスを作成する Anypoint CLI 4.x をインストールしたら、API インスタンスを作成して Flex Gateway にデプロイできます。 このステップを繰り返して、複数の API インスタンスを追加できます。その他の API 設定フラグについては、​[api-mgr:api:manage コマンド](https://docs.mulesoft.com/jp/anypoint-cli/latest/api-mgr#api-mgr-api-manage)​を参照してください。 Jenkinsfile で create API instance ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Create API Instance") { steps { script { sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:api:manage ${params.EXCHANGE_ASSET_ID} ${params.EXCHANGE_ASSET_VERSION} \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --isFlex --withProxy --deploymentType=hybrid --scheme=http --port=8082 \ --uri=https://httpbin.org:443 --path=/httpbin > api-response """ } } } ```
たとえば、このフェーズでは、ポート ​8082​ および ​/httpbin​ パスでリスンし、​https://httpbin.org/443​ にプロキシする API インスタンスを作成します。
## [](#適用基本認証ポリシーを適用する)適用基本認証ポリシーを適用する API インスタンスを作成したら、その API インスタンスにポリシーを適用できます。 このフェーズは ​[基本認証: 簡易ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-basic-auth-simple) as an example, but you can apply any Connected Mode policy. To find additional policies, see [Included Policies Directory](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory)​ に適用されます。 ポリシーを適用する手順は次のとおりです。 1. 次の情報を収集します。 - ポリシー GAV - ``​: Exchange のポリシーグループ ID (例: `68ef9520-24e9-4cf2-b2f5-620025690913`​) - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.2`​) - `"configurationData"`​: ポリシー設定データ 設定データ項目はポリシーに依存します。基本認証: 簡易ポリシーでは、​`"username"`​ および ​`"password"`​ パラメーターが使用されます。 2. サンプルコンテンツを置き換えたら、Jenkinsfile で apply basic authentication policy ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Apply Basic Authentication Policy to API Instance") { steps { script { def apiInstanceId = getAPIInstanceID('api-response') sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:policy:apply ${apiInstanceId} 'http-basic-authentication' \ --policyVersion='1.3.1' --groupId '68ef9520-24e9-4cf2-b2f5-620025690913' \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ -c '{"username": "user", "password": "test"}' """ } } } ```
たとえば、このフェーズでは、基本認証: 簡易ポリシーに関連付けられたポリシー GAV および ​"configurationData"​ が使用されます。
## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API インスタンスを作成したら、そのインスタンスをデプロイできます。 新しいインスタンスをデプロイするには、Jenkinsfile で deploy API ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Deploy API") { steps { script { sleep(time:15, unit:"SECONDS") def registration_file = parseYamlFile('registration.yaml') def apiInstanceId = getAPIInstanceID('api-response') sh """ docker exec container-anypoint-cli-v4 anypoint-cli-v4 api-mgr:api:deploy ${apiInstanceId} \ --client_id=${params.CONNECTED_APP_CLIENT_ID} --client_secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --target=${registration_file.spec.platformConnection.agentId[0]} --gatewayVersion=${params.FLEX_VERSION} """ } } } ``` ## [](#api-インスタンスがデプロイされていることを検証する)API インスタンスがデプロイされていることを検証する API インスタンスをデプロイしたら、Jenkinsfile で validate deployment ​`stage`​ を ​`stages`​ ブロックに追加して、インスタンスがデプロイされているかどうかを検証します。 ```Jenkinsfile stage("Validate Deployment") { steps { script { sleep(time:10, unit:"SECONDS") def unauthorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v", returnStdout: true).trim().toInteger() if (unauthorized_status_code != 401) { error("401 status code expected but the status code obtained is ${unauthorized_status_code}") } def authorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v -u user:test", returnStdout: true).trim().toInteger() if (authorized_status_code != 200) { error("200 status code expected but the status code obtained is ${unauthorized_status_code}") } } } } ``` ## [](#flex-gateway-を停止して登録ファイルをアーカイブする)Flex Gateway を停止して登録ファイルをアーカイブする 次のコードブロックを使用して、登録ファイルをアーカイブし、Flex Gateway を実行している Docker コンテナを削除します。​`stages`​ ブロックの後の ​`pipeline`​ ブロックに ​`post`​ ブロックを追加します。 ```Jenkinsfile post { success { script { // Archive the build output artifacts. archiveArtifacts artifacts: 'registration.yaml' } } always { script { sh(script: "docker rm -f container-anypoint-cli-v4 flex-gw") } } } ``` ## [](#関連情報)関連情報 - [Anypoint Platform CLI 4.x の使用開始](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [接続モードで接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-app)​。 - [API Manager API を使用した Flex Gateway の管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-manage-public-api) # Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化 Jenkins Pipeline を使用して、接続モードでの Flex Gateway のワークフローを自動化できます。Jenkins Pipeline を使用すると、Flex Gateway を登録して実行し、API Manager API の機能 (API インスタンスの作成やデプロイなど) を使用できます。 接続モードでの Flex Gateway の自動化ワークフローは、​[「API Manager API を使用した Flex Gateway の管理」](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-manage-public-api)​チュートリアルと多くの類似点があります。Jenkins Pipeline を使用して、API Manager API に対するコールを自動化できます。 [API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​ から機能を追加するには、例として​[「API インスタンスを作成する」](#create-an-api-instance)​および​[「API ポリシーを適用する」](#apply-an-api-policy)​ Pipeline フェーズを使用します。 このチュートリアルには、異なるコードブロックを含む異なる手順があります。手順を進めながら、コードブロックを同じ Jenkinsfile に追加します。Jenkins Pipeline で使用される構文についての詳細は、 [Jenkins Pipeline ドキュメント](https://www.jenkins.io/doc/book/pipeline/)​を参照してください。
代わりに Anypoint CLI を使用して Flex Gateway を自動化するには、Jenkins Pipeline と Anypoint CLI を使用した Flex Gateway の自動化を参照してください。
## [](#始める前に)始める前に Jenkins Pipeline をデプロイする前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)​。 2. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 1. **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]**​ および ​**\[Manage Servers (サーバーの管理)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** - 一般: **\[View Organization (組織の表示)\]** 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 3. 作成または適用する Exchange アセット (API) のグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.1`​ です。 4. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#初期設定)初期設定 API インスタンスを作成して Flex Gateway にデプロイする前に、次の手順を完了する必要があります。 1. [役立つ関数を定義する](#define-useful-functions)​。 2. [役立つパラメーターを定義する](#define-useful-parameters)​。 3. [登録して実行する](#register-and-run)​。 4. [\[Access Management (アクセス管理)\] から認証トークンを取得する](#obtain-an-authorization-token-from-access-management)​。 これらの Pipeline フェーズを実装したら、API を管理するための API Manager API 要求を作成して Pipeline をカスタマイズできます。 ### [](#役立つ関数を定義する)役立つ関数を定義する まず、Jenkinsfile でこれらの役立つ関数を定義します。​`pipeline`​ ブロックの前に関数を定義します。 ```Jenkinsfile def parseYamlFile(String file) { object = readYaml file: file return object } def parseJsonFile(file) { object = readJSON file: file return object } ``` ### [](#役立つパラメーターを定義する)役立つパラメーターを定義する Jenkins Pipeline のコマンドは一部のパラメーターを再利用するため、Jenkinsfile の先頭でパラメーターを定義すると役立ちます。 含まれているパラメーター定義をテンプレートとして使用して、追加の API またはポリシーに必要なパラメーターを定義することもできます。 パラメーターを定義する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: Flex ゲートウェイの名前 2. サンプルコンテンツを置き換えたら、パラメーター定義を Jenkinsfile に追加して、すべてのパラメーターが存在するかどうかを検証します。​`stages`​ ブロックの前の ​`pipeline`​ ブロックでパラメーターを定義します。 ```Jenkinsfile parameters { string(name: 'ENV_ID', defaultValue: '', description: 'Your environment id') string(name: 'ORG_ID', defaultValue: '', description: 'Your organization id') string(name: 'FLEX_VERSION', defaultValue: '', description: 'Flex version to run') string(name: 'CONNECTED_APP_CLIENT_ID', defaultValue: '', description: 'Your connected app client id') string(name: 'CONNECTED_APP_CLIENT_SECRET', defaultValue: '', description: 'The id of the http api exchange asset') string(name: 'EXCHANGE_ASSET_VERSION', defaultValue: '', description: 'The version of the http api exchange asset') string(name: 'GATEWAY_NAME', defaultValue: '', description: 'Unique gateway name') } ``` 3. Jenkinsfile で check parameters ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Check parameters') { steps { script { if (!params.ENV_ID || !params.ORG_ID || !params.FLEX_VERSION || !params.CONNECTED_APP_CLIENT_ID || !params.CONNECTED_APP_CLIENT_SECRET || !params.EXCHANGE_ASSET_ID || !params.EXCHANGE_ASSET_VERSION || !params.GATEWAY_NAME) { error("Not all parameters where specified") } } } } ``` このフェーズが失敗した場合は、不足しているパラメーターを指定して Pipeline を再実行します。 ### [](#登録して実行する)登録して実行する Jenkinsfile で登録フェーズと実行フェーズを ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Register flex gateway') { steps { script { sh """ docker run --entrypoint flexctl \ -v "\$(pwd)":/registration -u 0 mulesoft/flex-gateway:${params.FLEX_VERSION} \ register \ --client-id=${params.CONNECTED_APP_CLIENT_ID} \ --client-secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --environment=${params.ENV_ID} \ --connected=true \ --organization=${params.ORG_ID} \ --output-directory=/registration \ ${params.GATEWAY_NAME} """ if (!fileExists('registration.yaml')) { error("Registration failed") } } } } stage('Run flex gateway') { steps { script { sh """ docker run -d \ -v "\$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8082:8082 \ mulesoft/flex-gateway:${params.FLEX_VERSION} > containerId """ } } } ``` ### [](#access-management-アクセス管理-から認証トークンを取得する)\[Access Management (アクセス管理)\] から認証トークンを取得する Flex Gateway を登録して実行したら、後続の要求を認証するために、\[Access Management (アクセス管理)\] から有効な認証トークンを取得する必要があります。 Anypoint にログインするには、Jenkinsfile で ​`stages`​ ブロックに Anypoint login ​`stage`​ を追加します。 ```Jenkinsfile stage("Anypoint login") { steps { script { def cmd = """curl -s -w "%{http_code}" --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' -o 'login-response' \ --header 'Content-Type: application/json' \ --data-raw '{"grant_type": "client_credentials", "client_id": "${params.CONNECTED_APP_CLIENT_ID}", "client_secret": "${params.CONNECTED_APP_CLIENT_SECRET}"}' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Anypoint login failed") } } } } ``` このステップで返された認証トークンは、後続の要求のために保存されます。 ## [](#api-インスタンスを作成する)API インスタンスを作成する \[Access Management (アクセス管理)\] から認証トークンを取得すると、API インスタンスを作成して Flex Gateway にデプロイできるようになります。 このステップを繰り返して、複数の API インスタンスを追加できます。 たとえば、このフェーズでは、ポート ​`8082`​ および ​`/httpbin`​ パスでリスンし、​`https://httpbin.org/`​ にプロキシする API インスタンスを作成します。 API インスタンスを作成する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: API の URI アップストリーム - ``​: API インスタンスのプロキシ URI - `"isCloudHub"`​: Cloud Hub の状況 (例: `null`​ または ​`true`​) 2. 必要に応じて、​`"endpointUri"`​ を収集するか、​`"endpointUri"`​ 項目を削除します。 - ``​: API のコンシューマーエンドポイント (例: `http://consumer-endpoint.com`​) 3. HTTP アドレスを置き換えたら、Jenkinsfile で create API instance ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Create API instance") { steps { script { def login_response = parseJsonFile('login-response') def cmd = """ curl -s -w "%{http_code}" --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis' -o 'api-response' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --header 'Content-Type: application/json' \ --data-raw '{ "spec": { "groupId": "${params.ORG_ID}", "assetId": "${params.EXCHANGE_ASSET_ID}", "version": "${params.EXCHANGE_ASSET_VERSION}" }, "endpoint": { "deploymentType": "HY", "uri": "https://httpbin.org:443", "proxyUri": "http://0.0.0.0:8082/httpbin", "isCloudHub": null }, "technology": "flexGateway" "endpointUri": "" // OPTIONAL }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to create API instance") } } } } ``` ## [](#api-ポリシーを適用する)API ポリシーを適用する API インスタンスを作成したら、そのインスタンスに接続モードポリシーを適用できます。 1. 次の情報を収集します。 - ポリシー GAV - ``​: Exchange のポリシーグループ ID - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.1`​) - `"configurationData"`​: ポリシー設定データ 設定データ項目はポリシーに依存します。​`"username"`​ パラメーターと ​`"password"`​ パラメーターは単なる例です。ポリシーの設定データを見つけるには、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory)​を参照してください。 2. サンプルコンテンツを置き換えたら、Jenkinsfile で apply policy ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Apply policy") { steps { script { def login_response = parseJsonFile('login-response') def api_response = parseJsonFile('api-response') def cmd = """ curl -s -w "%{http_code}" -o /dev/null --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis/${api_response.id}/policies' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --header 'Content-Type: application/json' \ --data-raw '{ "configurationData":{ "username": "user", "password": "test" }, "pointcutData": null, "assetId": "", "assetVersion": "", "groupId": "" }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to apply Basic Auth Policy to the API instance") } } } } ``` ## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API インスタンスを作成したら、そのインスタンスをデプロイできます。 新しいインスタンスをデプロイするには、Jenkinsfile で deploy API ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Deploy API") { steps { script { def login_response = parseJsonFile('login-response') def api_response = parseJsonFile('api-response') def registration_file = parseYamlFile('registration.yaml') def cmd = """ curl -s -w "%{http_code}" -o /dev/null --location --request POST 'https://anypoint.mulesoft.com/proxies/xapi/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis/${api_response.id}/deployments' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --data-raw '{ "type": "HY", "gatewayVersion": "${params.FLEX_VERSION}", "targetId": "${registration_file.spec.platformConnection.agentId[0]}", "environmentId": "${params.ENV_ID}" }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to deploy the API instance") } } } } ``` ## [](#api-インスタンスがデプロイされていることを検証する)API インスタンスがデプロイされていることを検証する API インスタンスをデプロイしたら、Jenkinsfile で validate deployment ​`stage`​ を ​`stages`​ ブロックに追加して、インスタンスがデプロイされているかどうかを検証します。 ```Jenkinsfile stage("Validate deployment") { steps { script { sleep(time:10, unit:"SECONDS") def unauthorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v", returnStdout: true).trim().toInteger() if (unauthorized_status_code != 401) { error("401 status code expected but the status code obtained is ${unauthorized_status_code}") } def authorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v -u user:test", returnStdout: true).trim().toInteger() if (authorized_status_code != 200) { error("200 status code expected but the status code obtained is ${unauthorized_status_code}") } } } } ``` ## [](#flex-gateway-を停止して登録ファイルをアーカイブする)Flex Gateway を停止して登録ファイルをアーカイブする 次のコードブロックを使用して、Flex Gateway を停止し、登録ファイルをアーカイブします。​`stages`​ ブロックの後の ​`pipeline`​ ブロックに ​`post`​ ブロックを追加します。 ```Jenkinsfile post { success { script { // Archive the build output artifacts. archiveArtifacts artifacts: 'registration.yaml' } } always { script { if (fileExists('containerId')) { sh(script: "docker rm -f ${readFile(file: 'containerId')}") } } } } ``` ## [](#関連情報)関連情報 - [接続モードで接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-app)​。 - [Anypoint 開発者 API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/) - [API Manager API を使用した Flex Gateway の管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-manage-public-api) # Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化 Jenkins Pipeline を使用して、接続モードでの Flex Gateway のワークフローを自動化できます。Jenkins Pipeline を使用すると、Flex Gateway を登録して実行し、API Manager API の機能 (API インスタンスの作成やデプロイなど) を使用できます。 接続モードでの Flex Gateway の自動化ワークフローは、​[「API Manager API を使用した Flex Gateway の管理」](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-manage-public-api)​チュートリアルと多くの類似点があります。Jenkins Pipeline を使用して、API Manager API に対するコールを自動化できます。 [API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​ から機能を追加するには、例として​[「API インスタンスを作成する」](#create-an-api-instance)​および​[「API ポリシーを適用する」](#apply-an-api-policy)​ Pipeline フェーズを使用します。 このチュートリアルには、異なるコードブロックを含む異なる手順があります。手順を進めながら、コードブロックを同じ Jenkinsfile に追加します。Jenkins Pipeline で使用される構文についての詳細は、 [Jenkins Pipeline ドキュメント](https://www.jenkins.io/doc/book/pipeline/)​を参照してください。
代わりに Anypoint CLI を使用して Flex Gateway を自動化するには、Jenkins Pipeline と Anypoint CLI を使用した Flex Gateway の自動化を参照してください。
## [](#始める前に)始める前に Jenkins Pipeline をデプロイする前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)​。 2. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 1. **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]**​ および ​**\[Manage Servers (サーバーの管理)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** - 一般: **\[View Organization (組織の表示)\]** 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 3. 作成または適用する Exchange アセット (API) のグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.1`​ です。 4. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#初期設定)初期設定 API インスタンスを作成して Flex Gateway にデプロイする前に、次の手順を完了する必要があります。 1. [役立つ関数を定義する](#define-useful-functions)​。 2. [役立つパラメーターを定義する](#define-useful-parameters)​。 3. [登録して実行する](#register-and-run)​。 4. [\[Access Management (アクセス管理)\] から認証トークンを取得する](#obtain-an-authorization-token-from-access-management)​。 これらの Pipeline フェーズを実装したら、API を管理するための API Manager API 要求を作成して Pipeline をカスタマイズできます。 ### [](#役立つ関数を定義する)役立つ関数を定義する まず、Jenkinsfile でこれらの役立つ関数を定義します。​`pipeline`​ ブロックの前に関数を定義します。 ```Jenkinsfile def parseYamlFile(String file) { object = readYaml file: file return object } def parseJsonFile(file) { object = readJSON file: file return object } ``` ### [](#役立つパラメーターを定義する)役立つパラメーターを定義する Jenkins Pipeline のコマンドは一部のパラメーターを再利用するため、Jenkinsfile の先頭でパラメーターを定義すると役立ちます。 含まれているパラメーター定義をテンプレートとして使用して、追加の API またはポリシーに必要なパラメーターを定義することもできます。 パラメーターを定義する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: Flex ゲートウェイの名前 2. サンプルコンテンツを置き換えたら、パラメーター定義を Jenkinsfile に追加して、すべてのパラメーターが存在するかどうかを検証します。​`stages`​ ブロックの前の ​`pipeline`​ ブロックでパラメーターを定義します。 ```Jenkinsfile parameters { string(name: 'ENV_ID', defaultValue: '', description: 'Your environment id') string(name: 'ORG_ID', defaultValue: '', description: 'Your organization id') string(name: 'FLEX_VERSION', defaultValue: '', description: 'Flex version to run') string(name: 'CONNECTED_APP_CLIENT_ID', defaultValue: '', description: 'Your connected app client id') string(name: 'CONNECTED_APP_CLIENT_SECRET', defaultValue: '', description: 'The id of the http api exchange asset') string(name: 'EXCHANGE_ASSET_VERSION', defaultValue: '', description: 'The version of the http api exchange asset') string(name: 'GATEWAY_NAME', defaultValue: '', description: 'Unique gateway name') } ``` 3. Jenkinsfile で check parameters ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Check parameters') { steps { script { if (!params.ENV_ID || !params.ORG_ID || !params.FLEX_VERSION || !params.CONNECTED_APP_CLIENT_ID || !params.CONNECTED_APP_CLIENT_SECRET || !params.EXCHANGE_ASSET_ID || !params.EXCHANGE_ASSET_VERSION || !params.GATEWAY_NAME) { error("Not all parameters where specified") } } } } ``` このフェーズが失敗した場合は、不足しているパラメーターを指定して Pipeline を再実行します。 ### [](#登録して実行する)登録して実行する Jenkinsfile で登録フェーズと実行フェーズを ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Register flex gateway') { steps { script { sh """ docker run --entrypoint flexctl \ -v "\$(pwd)":/registration -u 0 mulesoft/flex-gateway:${params.FLEX_VERSION} \ register \ --client-id=${params.CONNECTED_APP_CLIENT_ID} \ --client-secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --environment=${params.ENV_ID} \ --connected=true \ --organization=${params.ORG_ID} \ --output-directory=/registration \ ${params.GATEWAY_NAME} """ if (!fileExists('registration.yaml')) { error("Registration failed") } } } } stage('Run flex gateway') { steps { script { sh """ docker run -d \ -v "\$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8082:8082 \ mulesoft/flex-gateway:${params.FLEX_VERSION} > containerId """ } } } ``` ### [](#access-management-アクセス管理-から認証トークンを取得する)\[Access Management (アクセス管理)\] から認証トークンを取得する Flex Gateway を登録して実行したら、後続の要求を認証するために、\[Access Management (アクセス管理)\] から有効な認証トークンを取得する必要があります。 Anypoint にログインするには、Jenkinsfile で ​`stages`​ ブロックに Anypoint login ​`stage`​ を追加します。 ```Jenkinsfile stage("Anypoint login") { steps { script { def cmd = """curl -s -w "%{http_code}" --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' -o 'login-response' \ --header 'Content-Type: application/json' \ --data-raw '{"grant_type": "client_credentials", "client_id": "${params.CONNECTED_APP_CLIENT_ID}", "client_secret": "${params.CONNECTED_APP_CLIENT_SECRET}"}' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Anypoint login failed") } } } } ``` このステップで返された認証トークンは、後続の要求のために保存されます。 ## [](#api-インスタンスを作成する)API インスタンスを作成する \[Access Management (アクセス管理)\] から認証トークンを取得すると、API インスタンスを作成して Flex Gateway にデプロイできるようになります。 このステップを繰り返して、複数の API インスタンスを追加できます。 たとえば、このフェーズでは、ポート ​`8082`​ および ​`/httpbin`​ パスでリスンし、​`https://httpbin.org/`​ にプロキシする API インスタンスを作成します。 API インスタンスを作成する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: API の URI アップストリーム - ``​: API インスタンスのプロキシ URI - `"isCloudHub"`​: Cloud Hub の状況 (例: `null`​ または ​`true`​) 2. 必要に応じて、​`"endpointUri"`​ を収集するか、​`"endpointUri"`​ 項目を削除します。 - ``​: API のコンシューマーエンドポイント (例: `http://consumer-endpoint.com`​) 3. HTTP アドレスを置き換えたら、Jenkinsfile で create API instance ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Create API instance") { steps { script { def login_response = parseJsonFile('login-response') def cmd = """ curl -s -w "%{http_code}" --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis' -o 'api-response' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --header 'Content-Type: application/json' \ --data-raw '{ "spec": { "groupId": "${params.ORG_ID}", "assetId": "${params.EXCHANGE_ASSET_ID}", "version": "${params.EXCHANGE_ASSET_VERSION}" }, "endpoint": { "deploymentType": "HY", "uri": "https://httpbin.org:443", "proxyUri": "http://0.0.0.0:8082/httpbin", "isCloudHub": null }, "technology": "flexGateway" "endpointUri": "" // OPTIONAL }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to create API instance") } } } } ``` ## [](#api-ポリシーを適用する)API ポリシーを適用する API インスタンスを作成したら、そのインスタンスに接続モードポリシーを適用できます。 1. 次の情報を収集します。 - ポリシー GAV - ``​: Exchange のポリシーグループ ID - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.1`​) - `"configurationData"`​: ポリシー設定データ 設定データ項目はポリシーに依存します。​`"username"`​ パラメーターと ​`"password"`​ パラメーターは単なる例です。ポリシーの設定データを見つけるには、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory)​を参照してください。 2. サンプルコンテンツを置き換えたら、Jenkinsfile で apply policy ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Apply policy") { steps { script { def login_response = parseJsonFile('login-response') def api_response = parseJsonFile('api-response') def cmd = """ curl -s -w "%{http_code}" -o /dev/null --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis/${api_response.id}/policies' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --header 'Content-Type: application/json' \ --data-raw '{ "configurationData":{ "username": "user", "password": "test" }, "pointcutData": null, "assetId": "", "assetVersion": "", "groupId": "" }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to apply Basic Auth Policy to the API instance") } } } } ``` ## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API インスタンスを作成したら、そのインスタンスをデプロイできます。 新しいインスタンスをデプロイするには、Jenkinsfile で deploy API ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Deploy API") { steps { script { def login_response = parseJsonFile('login-response') def api_response = parseJsonFile('api-response') def registration_file = parseYamlFile('registration.yaml') def cmd = """ curl -s -w "%{http_code}" -o /dev/null --location --request POST 'https://anypoint.mulesoft.com/proxies/xapi/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis/${api_response.id}/deployments' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --data-raw '{ "type": "HY", "gatewayVersion": "${params.FLEX_VERSION}", "targetId": "${registration_file.spec.platformConnection.agentId[0]}", "environmentId": "${params.ENV_ID}" }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to deploy the API instance") } } } } ``` ## [](#api-インスタンスがデプロイされていることを検証する)API インスタンスがデプロイされていることを検証する API インスタンスをデプロイしたら、Jenkinsfile で validate deployment ​`stage`​ を ​`stages`​ ブロックに追加して、インスタンスがデプロイされているかどうかを検証します。 ```Jenkinsfile stage("Validate deployment") { steps { script { sleep(time:10, unit:"SECONDS") def unauthorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v", returnStdout: true).trim().toInteger() if (unauthorized_status_code != 401) { error("401 status code expected but the status code obtained is ${unauthorized_status_code}") } def authorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v -u user:test", returnStdout: true).trim().toInteger() if (authorized_status_code != 200) { error("200 status code expected but the status code obtained is ${unauthorized_status_code}") } } } } ``` ## [](#flex-gateway-を停止して登録ファイルをアーカイブする)Flex Gateway を停止して登録ファイルをアーカイブする 次のコードブロックを使用して、Flex Gateway を停止し、登録ファイルをアーカイブします。​`stages`​ ブロックの後の ​`pipeline`​ ブロックに ​`post`​ ブロックを追加します。 ```Jenkinsfile post { success { script { // Archive the build output artifacts. archiveArtifacts artifacts: 'registration.yaml' } } always { script { if (fileExists('containerId')) { sh(script: "docker rm -f ${readFile(file: 'containerId')}") } } } } ``` ## [](#関連情報)関連情報 - [接続モードで接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-app)​。 - [Anypoint 開発者 API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/) - [API Manager API を使用した Flex Gateway の管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-manage-public-api) # Jenkins Pipeline と API Manager API を使用した Flex Gateway の自動化 Jenkins Pipeline を使用して、接続モードでの Flex Gateway のワークフローを自動化できます。Jenkins Pipeline を使用すると、Flex Gateway を登録して実行し、API Manager API の機能 (API インスタンスの作成やデプロイなど) を使用できます。 接続モードでの Flex Gateway の自動化ワークフローは、​[「API Manager API を使用した Flex Gateway の管理」](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-manage-public-api)​チュートリアルと多くの類似点があります。Jenkins Pipeline を使用して、API Manager API に対するコールを自動化できます。 [API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/)​ から機能を追加するには、例として​[「API インスタンスを作成する」](#create-an-api-instance)​および​[「API ポリシーを適用する」](#apply-an-api-policy)​ Pipeline フェーズを使用します。 このチュートリアルには、異なるコードブロックを含む異なる手順があります。手順を進めながら、コードブロックを同じ Jenkinsfile に追加します。Jenkins Pipeline で使用される構文についての詳細は、 [Jenkins Pipeline ドキュメント](https://www.jenkins.io/doc/book/pipeline/)​を参照してください。
代わりに Anypoint CLI を使用して Flex Gateway を自動化するには、Jenkins Pipeline と Anypoint CLI を使用した Flex Gateway の自動化を参照してください。
## [](#始める前に)始める前に Jenkins Pipeline をデプロイする前に、次のタスクを完了します。 1. [Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)​。 2. [接続アプリケーションを設定します](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​。 1. **\[App acts on its behalf (client credentials) (アプリケーションが自身のために行動する (クライアントログイン情報))\]**​ 種別を使用し、以下のスコープを含めます。 - API Manager: **\[Manage API Configuration (API 設定の管理)\]**​、​**\[Manage Policies (ポリシーの管理)\]**​、​**\[View Policies (ポリシーの参照)\]**​、​**\[Deploy API Proxies (API プロキシのデプロイ)\]** - Runtime Manager: **\[Read Servers (サーバーの参照)\]**​ および ​**\[Manage Servers (サーバーの管理)\]** - Exchange: **\[Exchange Viewer (Exchange 閲覧者)\]** - 一般: **\[View Organization (組織の表示)\]** 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 3. 作成または適用する Exchange アセット (API) のグループ ID、アセット ID、およびアセットバージョン (GAV) を収集します。 Exchange から GAV を収集する手順は、次のとおりです。 1. Exchange に移動します。 2. 追加または適用するアセットを見つけます。 3. URL からグループ ID とアセット ID を収集します。 たとえば、API Manager API Exchange URL ​`https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/minor/1.0/pages/home/`​ から収集された ID は次のとおりです。 - グループ ID: `f1e97bc6-315a-4490-82a7-23abe036327` - アセット ID: `api-manager-api` 4. **\[Latest Stable (最新の安定バージョン)\]**​ からアセットのバージョンを収集します。 たとえば、API Gateway HTTP 基本認証ポリシーテンプレートから収集されたバージョンは ​`1.3.1`​ です。 4. Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 詳細は、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 詳細は、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#初期設定)初期設定 API インスタンスを作成して Flex Gateway にデプロイする前に、次の手順を完了する必要があります。 1. [役立つ関数を定義する](#define-useful-functions)​。 2. [役立つパラメーターを定義する](#define-useful-parameters)​。 3. [登録して実行する](#register-and-run)​。 4. [\[Access Management (アクセス管理)\] から認証トークンを取得する](#obtain-an-authorization-token-from-access-management)​。 これらの Pipeline フェーズを実装したら、API を管理するための API Manager API 要求を作成して Pipeline をカスタマイズできます。 ### [](#役立つ関数を定義する)役立つ関数を定義する まず、Jenkinsfile でこれらの役立つ関数を定義します。​`pipeline`​ ブロックの前に関数を定義します。 ```Jenkinsfile def parseYamlFile(String file) { object = readYaml file: file return object } def parseJsonFile(file) { object = readJSON file: file return object } ``` ### [](#役立つパラメーターを定義する)役立つパラメーターを定義する Jenkins Pipeline のコマンドは一部のパラメーターを再利用するため、Jenkinsfile の先頭でパラメーターを定義すると役立ちます。 含まれているパラメーター定義をテンプレートとして使用して、追加の API またはポリシーに必要なパラメーターを定義することもできます。 パラメーターを定義する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: Flex Gateway を実行する組織の​**組織 ID** - ``​: Flex Gateway を実行する組織の​**環境 ID** - ``​: 使用している Flex Gateway のバージョン (例: `1.4.0`​) - ``​: 接続アプリケーションの ​**ID** - ``​: 接続アプリケーションの​**シークレット**​。 - API GAV: - ``​: Exchange から取得したグループ ID - ``​: Exchange から取得した、作成する API のアセット ID - ``​: Exchange から取得した、作成する API のアセットバージョン - ``​: Flex ゲートウェイの名前 2. サンプルコンテンツを置き換えたら、パラメーター定義を Jenkinsfile に追加して、すべてのパラメーターが存在するかどうかを検証します。​`stages`​ ブロックの前の ​`pipeline`​ ブロックでパラメーターを定義します。 ```Jenkinsfile parameters { string(name: 'ENV_ID', defaultValue: '', description: 'Your environment id') string(name: 'ORG_ID', defaultValue: '', description: 'Your organization id') string(name: 'FLEX_VERSION', defaultValue: '', description: 'Flex version to run') string(name: 'CONNECTED_APP_CLIENT_ID', defaultValue: '', description: 'Your connected app client id') string(name: 'CONNECTED_APP_CLIENT_SECRET', defaultValue: '', description: 'The id of the http api exchange asset') string(name: 'EXCHANGE_ASSET_VERSION', defaultValue: '', description: 'The version of the http api exchange asset') string(name: 'GATEWAY_NAME', defaultValue: '', description: 'Unique gateway name') } ``` 3. Jenkinsfile で check parameters ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Check parameters') { steps { script { if (!params.ENV_ID || !params.ORG_ID || !params.FLEX_VERSION || !params.CONNECTED_APP_CLIENT_ID || !params.CONNECTED_APP_CLIENT_SECRET || !params.EXCHANGE_ASSET_ID || !params.EXCHANGE_ASSET_VERSION || !params.GATEWAY_NAME) { error("Not all parameters where specified") } } } } ``` このフェーズが失敗した場合は、不足しているパラメーターを指定して Pipeline を再実行します。 ### [](#登録して実行する)登録して実行する Jenkinsfile で登録フェーズと実行フェーズを ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage('Register flex gateway') { steps { script { sh """ docker run --entrypoint flexctl \ -v "\$(pwd)":/registration -u 0 mulesoft/flex-gateway:${params.FLEX_VERSION} \ register \ --client-id=${params.CONNECTED_APP_CLIENT_ID} \ --client-secret=${params.CONNECTED_APP_CLIENT_SECRET} \ --environment=${params.ENV_ID} \ --connected=true \ --organization=${params.ORG_ID} \ --output-directory=/registration \ ${params.GATEWAY_NAME} """ if (!fileExists('registration.yaml')) { error("Registration failed") } } } } stage('Run flex gateway') { steps { script { sh """ docker run -d \ -v "\$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8082:8082 \ mulesoft/flex-gateway:${params.FLEX_VERSION} > containerId """ } } } ``` ### [](#access-management-アクセス管理-から認証トークンを取得する)\[Access Management (アクセス管理)\] から認証トークンを取得する Flex Gateway を登録して実行したら、後続の要求を認証するために、\[Access Management (アクセス管理)\] から有効な認証トークンを取得する必要があります。 Anypoint にログインするには、Jenkinsfile で ​`stages`​ ブロックに Anypoint login ​`stage`​ を追加します。 ```Jenkinsfile stage("Anypoint login") { steps { script { def cmd = """curl -s -w "%{http_code}" --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' -o 'login-response' \ --header 'Content-Type: application/json' \ --data-raw '{"grant_type": "client_credentials", "client_id": "${params.CONNECTED_APP_CLIENT_ID}", "client_secret": "${params.CONNECTED_APP_CLIENT_SECRET}"}' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Anypoint login failed") } } } } ``` このステップで返された認証トークンは、後続の要求のために保存されます。 ## [](#api-インスタンスを作成する)API インスタンスを作成する \[Access Management (アクセス管理)\] から認証トークンを取得すると、API インスタンスを作成して Flex Gateway にデプロイできるようになります。 このステップを繰り返して、複数の API インスタンスを追加できます。 たとえば、このフェーズでは、ポート ​`8082`​ および ​`/httpbin`​ パスでリスンし、​`https://httpbin.org/`​ にプロキシする API インスタンスを作成します。 API インスタンスを作成する手順は、次のとおりです。 1. 次の情報を収集します。 - ``​: API の URI アップストリーム - ``​: API インスタンスのプロキシ URI - `"isCloudHub"`​: Cloud Hub の状況 (例: `null`​ または ​`true`​) 2. 必要に応じて、​`"endpointUri"`​ を収集するか、​`"endpointUri"`​ 項目を削除します。 - ``​: API のコンシューマーエンドポイント (例: `http://consumer-endpoint.com`​) 3. HTTP アドレスを置き換えたら、Jenkinsfile で create API instance ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Create API instance") { steps { script { def login_response = parseJsonFile('login-response') def cmd = """ curl -s -w "%{http_code}" --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis' -o 'api-response' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --header 'Content-Type: application/json' \ --data-raw '{ "spec": { "groupId": "${params.ORG_ID}", "assetId": "${params.EXCHANGE_ASSET_ID}", "version": "${params.EXCHANGE_ASSET_VERSION}" }, "endpoint": { "deploymentType": "HY", "uri": "https://httpbin.org:443", "proxyUri": "http://0.0.0.0:8082/httpbin", "isCloudHub": null }, "technology": "flexGateway" "endpointUri": "" // OPTIONAL }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to create API instance") } } } } ``` ## [](#api-ポリシーを適用する)API ポリシーを適用する API インスタンスを作成したら、そのインスタンスに接続モードポリシーを適用できます。 1. 次の情報を収集します。 - ポリシー GAV - ``​: Exchange のポリシーグループ ID - ``​:Exchange のポリシーアセット ID (例: `http-basic-authentication`​) - ``​: Exchange のポリシーアセットバージョン (例: `1.3.1`​) - `"configurationData"`​: ポリシー設定データ 設定データ項目はポリシーに依存します。​`"username"`​ パラメーターと ​`"password"`​ パラメーターは単なる例です。ポリシーの設定データを見つけるには、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory)​を参照してください。 2. サンプルコンテンツを置き換えたら、Jenkinsfile で apply policy ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Apply policy") { steps { script { def login_response = parseJsonFile('login-response') def api_response = parseJsonFile('api-response') def cmd = """ curl -s -w "%{http_code}" -o /dev/null --location --request POST 'https://anypoint.mulesoft.com/apimanager/api/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis/${api_response.id}/policies' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --header 'Content-Type: application/json' \ --data-raw '{ "configurationData":{ "username": "user", "password": "test" }, "pointcutData": null, "assetId": "", "assetVersion": "", "groupId": "" }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to apply Basic Auth Policy to the API instance") } } } } ``` ## [](#api-インスタンスをデプロイする)API インスタンスをデプロイする API インスタンスを作成したら、そのインスタンスをデプロイできます。 新しいインスタンスをデプロイするには、Jenkinsfile で deploy API ​`stage`​ を ​`stages`​ ブロックに追加します。 ```Jenkinsfile stage("Deploy API") { steps { script { def login_response = parseJsonFile('login-response') def api_response = parseJsonFile('api-response') def registration_file = parseYamlFile('registration.yaml') def cmd = """ curl -s -w "%{http_code}" -o /dev/null --location --request POST 'https://anypoint.mulesoft.com/proxies/xapi/v1/organizations/${params.ORG_ID}/environments/${params.ENV_ID}/apis/${api_response.id}/deployments' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ${login_response.access_token}' \ --data-raw '{ "type": "HY", "gatewayVersion": "${params.FLEX_VERSION}", "targetId": "${registration_file.spec.platformConnection.agentId[0]}", "environmentId": "${params.ENV_ID}" }' """ def status_code = sh(returnStdout: true, script: cmd).trim().toInteger() if (status_code > 399) { error("Error occurred while trying to deploy the API instance") } } } } ``` ## [](#api-インスタンスがデプロイされていることを検証する)API インスタンスがデプロイされていることを検証する API インスタンスをデプロイしたら、Jenkinsfile で validate deployment ​`stage`​ を ​`stages`​ ブロックに追加して、インスタンスがデプロイされているかどうかを検証します。 ```Jenkinsfile stage("Validate deployment") { steps { script { sleep(time:10, unit:"SECONDS") def unauthorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v", returnStdout: true).trim().toInteger() if (unauthorized_status_code != 401) { error("401 status code expected but the status code obtained is ${unauthorized_status_code}") } def authorized_status_code = sh(script: "curl -s -w \"%{http_code}\" -o /dev/null http://localhost:8082/httpbin/headers -v -u user:test", returnStdout: true).trim().toInteger() if (authorized_status_code != 200) { error("200 status code expected but the status code obtained is ${unauthorized_status_code}") } } } } ``` ## [](#flex-gateway-を停止して登録ファイルをアーカイブする)Flex Gateway を停止して登録ファイルをアーカイブする 次のコードブロックを使用して、Flex Gateway を停止し、登録ファイルをアーカイブします。​`stages`​ ブロックの後の ​`pipeline`​ ブロックに ​`post`​ ブロックを追加します。 ```Jenkinsfile post { success { script { // Archive the build output artifacts. archiveArtifacts artifacts: 'registration.yaml' } } always { script { if (fileExists('containerId')) { sh(script: "docker rm -f ${readFile(file: 'containerId')}") } } } } ``` ## [](#関連情報)関連情報 - [接続モードで接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-app)​。 - [Anypoint 開発者 API Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/api-manager-api/) - [API Manager API を使用した Flex Gateway の管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-manage-public-api) # JSON 脅威保護ポリシー

ポリシー名

JSON 脅威保護

概要

API 要求内の悪意のある JSON から保護する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

400 - Bad Request
## [](#概要)概要 JSON 要求を処理するアプリケーションは、要素とネストレベルの異常な膨張により特徴付けられる攻撃を受けやすくなっています。攻撃者は再帰的な技法を使用してメモリリソースをコンシュームします。多くの場合、アプリケーションデータのサイズが劇的に変動することは、セキュリティの問題が発生していることを示します。JSON 脅威保護ポリシーは、このような侵入からアプリケーションを保護するのに役立ちます。 Anypoint Platform 環境への攻撃の検出が困難である場合は、JSON 脅威保護に保護レイヤーを追加したサービスアーキテクチャを設計する必要があります。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: json-threat-protection-flex config: maxContainerDepth: // OPTIONAL maxObjectEntryCount: // OPTIONAL maxObjectEntryNameLength: // OPTIONAL maxArrayElementCount: // OPTIONAL maxStringValueLength: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

maxContainerDepth

省略可能

-1

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。-1 の指定は、項目値に制限がないことを意味します。

maxObjectEntryCount

省略可能

-1

オブジェクトの最大エントリ数を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxObjectEntryNameLength

省略可能

-1

オブジェクトのエントリ名の最大文字列長を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxArrayElementCount

省略可能

-1

配列の最大要素数を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxStringValueLength

省略可能

-1

最大文字列値長を指定します。-1 の指定は、項目値に制限がないことを意味します。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: json-threat-protection-flex config: maxContainerDepth: 10 maxObjectEntryCount: 10000 maxObjectEntryNameLength: 80 maxArrayElementCount: 10000 maxStringValueLength: 255 ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。

項目

説明

デフォルト

必須

Maximum Container Depth (最大コンテナ深度)

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。

-1

false

Maximum String Value Length (最大文字列値長)

文字列値の最大長を指定します。

-1

false

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

オブジェクトのエントリ名の最大文字列長を指定します

-1

false

Maximum Object Entry Count (最大オブジェクトエントリ数)

オブジェクトの最大エントリ数を指定します。

-1

false

Maximum Array Element Count (最大配列要素数)

配列の最大要素数を指定します。

-1

false

-1 の値は、項目値に制限がないことを意味します。
## [](#ペイロードの例)ペイロードの例 ペイロードに次の JSON 例が含まれているとします。 { "Players":\[ { "Name":"Sachin", "Email":"sachin.tendulkar@example.com" }, { "Name":"Suryakumar", "email":"Surya@example.com" }, { "Name":"Bhuvi", "email":"bhuvi@example.com" }, { "Name":"Jonty", "Email":"jonty@example.com" } \] } ポリシーでは、次のようにパラメーター値の例が定義されます。
パラメーター 値 説明

Maximum Container Depth (最大コンテナ深度)

3

Name​ エントリと ​Email​ エントリの深度

Maximum String Value Length (最大文字列値長)

28

sachin.tendulkar@example.com​ の長さ

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

7

Players​ オブジェクトエントリ名の長さ

Maximum Object Entry Count (最大オブジェクトエントリ数)

2

各 ​Players​ オブジェクトのエントリ数

Maximum Array Element Count (最大配列要素数)

4

Players​ 配列の要素数
# JSON 脅威保護ポリシー

ポリシー名

JSON 脅威保護

概要

API 要求内の悪意のある JSON から保護する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

400 - Bad Request
## [](#概要)概要 JSON 要求を処理するアプリケーションは、要素とネストレベルの異常な膨張により特徴付けられる攻撃を受けやすくなっています。攻撃者は再帰的な技法を使用してメモリリソースをコンシュームします。多くの場合、アプリケーションデータのサイズが劇的に変動することは、セキュリティの問題が発生していることを示します。JSON 脅威保護ポリシーは、このような侵入からアプリケーションを保護するのに役立ちます。 Anypoint Platform 環境への攻撃の検出が困難である場合は、JSON 脅威保護に保護レイヤーを追加したサービスアーキテクチャを設計する必要があります。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して JSON 脅威保護ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: json-threat-protection-flex config: maxContainerDepth: // OPTIONAL maxObjectEntryCount: // OPTIONAL maxObjectEntryNameLength: // OPTIONAL maxArrayElementCount: // OPTIONAL maxStringValueLength: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

maxContainerDepth

省略可能

-1

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。-1 の指定は、項目値に制限がないことを意味します。

maxObjectEntryCount

省略可能

-1

オブジェクトのエントリ名の最大文字列長を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxObjectEntryNameLength

省略可能

-1

オブジェクトの最大エントリ数を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxArrayElementCount

省略可能

-1

配列の最大要素数を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxStringValueLength

省略可能

-1

最大文字列値長を指定します。-1 の指定は、項目値に制限がないことを意味します。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: json-threat-protection-flex config: maxContainerDepth: 10 maxObjectEntryCount: 10000 maxObjectEntryNameLength: 80 maxArrayElementCount: 10000 maxStringValueLength: 255 ``` ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI から JSON 脅威保護ポリシーを API に適用するときに、以下のパラメーターが表示されます。

項目

説明

デフォルト

必須

Maximum Container Depth (最大コンテナ深度)

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。

-1

false

Maximum String Value Length (最大文字列値長)

文字列値の最大長を指定します。

-1

false

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

オブジェクトのエントリ名の最大文字列長を指定します

-1

false

Maximum Object Entry Count (最大オブジェクトエントリ数)

オブジェクトの最大エントリ数を指定します。

-1

false

Maximum Array Element Count (最大配列要素数)

配列の最大要素数を指定します。

-1

false

-1 の値は、項目値に制限がないことを意味します。
## [](#ペイロードの例)ペイロードの例 ペイロードに次の JSON 例が含まれているとします。 { "Players":\[ { "Name":"Sachin", "Email":"sachin.tendulkar@example.com" }, { "Name":"Suryakumar", "email":"Surya@example.com" }, { "Name":"Bhuvi", "email":"bhuvi@example.com" }, { "Name":"Jonty", "Email":"jonty@example.com" } \] } ポリシーでは、次のようにパラメーター値の例が定義されます。
パラメーター Value (値) 説明

Maximum Container Depth (最大コンテナ深度)

3

Name​ エントリと ​Email​ エントリの深度

Maximum String Value Length (最大文字列値長)

28

sachin.tendulkar@example.com​ の長さ

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

7

Players​ オブジェクトエントリ名の長さ

Maximum Object Entry Count (最大オブジェクトエントリ数)

2

各 ​Players​ オブジェクトのエントリ数

Maximum Array Element Count (最大配列要素数)

4

Players​ 配列の要素数
# JSON 脅威保護ポリシー

ポリシー名

JSON 脅威保護

概要

API 要求内の悪意のある JSON から保護する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

400 - Bad Request
## [](#概要)概要 JSON 要求を処理するアプリケーションは、要素とネストレベルの異常な膨張により特徴付けられる攻撃を受けやすくなっています。攻撃者は再帰的な技法を使用してメモリリソースをコンシュームします。多くの場合、アプリケーションデータのサイズが劇的に変動することは、セキュリティの問題が発生していることを示します。JSON 脅威保護ポリシーは、このような侵入からアプリケーションを保護するのに役立ちます。 Anypoint Platform 環境への攻撃の検出が困難である場合は、JSON 脅威保護に保護レイヤーを追加したサービスアーキテクチャを設計する必要があります。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: json-threat-protection-flex config: maxContainerDepth: // OPTIONAL maxObjectEntryCount: // OPTIONAL maxObjectEntryNameLength: // OPTIONAL maxArrayElementCount: // OPTIONAL maxStringValueLength: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

maxContainerDepth

省略可能

-1

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。-1 の指定は、項目値に制限がないことを意味します。

maxObjectEntryCount

省略可能

-1

オブジェクトの最大エントリ数を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxObjectEntryNameLength

省略可能

-1

オブジェクトのエントリ名の最大文字列長を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxArrayElementCount

省略可能

-1

配列の最大要素数を指定します。-1 の指定は、項目値に制限がないことを意味します。

maxStringValueLength

省略可能

-1

最大文字列値長を指定します。-1 の指定は、項目値に制限がないことを意味します。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: json-threat-protection-flex config: maxContainerDepth: 10 maxObjectEntryCount: 10000 maxObjectEntryNameLength: 80 maxArrayElementCount: 10000 maxStringValueLength: 255 ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。

項目

説明

デフォルト

必須

Maximum Container Depth (最大コンテナ深度)

最大ネスト深度を指定します。JSON では、コンテナ (オブジェクトおよび配列) を任意の順序で任意の深度までネストできます。

-1

false

Maximum String Value Length (最大文字列値長)

文字列値の最大長を指定します。

-1

false

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

オブジェクトのエントリ名の最大文字列長を指定します

-1

false

Maximum Object Entry Count (最大オブジェクトエントリ数)

オブジェクトの最大エントリ数を指定します。

-1

false

Maximum Array Element Count (最大配列要素数)

配列の最大要素数を指定します。

-1

false

-1 の値は、項目値に制限がないことを意味します。
## [](#ペイロードの例)ペイロードの例 ペイロードに次の JSON 例が含まれているとします。 { "Players":\[ { "Name":"Sachin", "Email":"sachin.tendulkar@example.com" }, { "Name":"Suryakumar", "email":"Surya@example.com" }, { "Name":"Bhuvi", "email":"bhuvi@example.com" }, { "Name":"Jonty", "Email":"jonty@example.com" } \] } ポリシーでは、次のようにパラメーター値の例が定義されます。
パラメーター 値 説明

Maximum Container Depth (最大コンテナ深度)

3

Name​ エントリと ​Email​ エントリの深度

Maximum String Value Length (最大文字列値長)

28

sachin.tendulkar@example.com​ の長さ

Maximum Object Entry Name Length (オブジェクトエントリ名の最大長)

7

Players​ オブジェクトエントリ名の長さ

Maximum Object Entry Count (最大オブジェクトエントリ数)

2

各 ​Players​ オブジェクトのエントリ数

Maximum Array Element Count (最大配列要素数)

4

Players​ 配列の要素数
# JWT 検証ポリシー

ポリシー名

JWT 検証

概要

JWT トークンを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - トークンが要求で提供されなかった。

401

署名が検証されなかった、または無効である。

必要ないくつかのクレームがない、またはクレームの検証に失敗した。

トークンの解析に失敗した。
## [](#概要)概要 JSON Web Token (JWT) は、2 者間で転送されるクレームを表す URL セキュアな方法です。JWT のクレームは、JSON Web Signature (JWS) のペイロードまたはプレーンテキストの JSON Web Encryption (JWE) 構造として使用される JSON オブジェクトとしてエンコードされます。これにより、クレームはデジタル署名したり、メッセージ認証コード (MAC) で整合性を保護したりできます。トークンは署名されるので、その情報と情報源を信頼できます。 JWT 検証ポリシーは、トークンの署名を検証し、JWS 形式の JWT を使用してすべての受信要求のクレームの値をアサートします。このポリシーでは、JWE を使用する JWT は検証されません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: jwt-validation-flex config:
パラメーター 必須または省略可能 デフォルト値 説明

signingMethod

省略可能

rsa

キーの署名方式を含む文字列。サポートされている値: rsa​、​hmac​、​es​、​none​

signingKeyLength

省略可能

256

キーの長さを示す数値。サポートされている値は 256、384、512 です。ES メソッドの場合、Flex Gateway は 256 キーおよび 384 キーの長さをサポートします。

textKey

省略可能

your-(256|384|512)-bit-secret/your-public-pem-certificate

jwtOrigin

省略可能

httpBearerAuthenticationHeader

jwtKeyOrigin

省略可能

text

jwksUrl

省略可能

http://your-jwks-service.example:80/base/path

署名検証用の公開キーを含む JWKS サーバーの URL。URL のカンマ区切りリストを使用して複数の JWKS サーバーを設定します。

jwksServiceTimeToLive

省略可能

60

ポリシーで JWKS が有効とみなされる時間 (分)。

jwksServiceConnectionTimeout

省略可能

10000

アクセストークン検証エンドポイントを認証するときに、各 JWKS サービスからの応答を待機する最大時間 (ミリ秒)。

validateAudClaim

省略可能

false

mandatoryAudClaim

省略可能

false

mandatoryNbfClaim

省略可能

false

mandatoryExpClaim

省略可能

false

supportedAudiences

省略可能

空の文字列

validateCustomClaim

省略可能

false

mandatoryCustomClaims

省略可能

空の配列

nonMandatoryCustomClaims

省略可能

空の配列

jwtExpression

省略可能

#[attributes.headers['jwt']]

skipClientIdValidation

必須

true

このパラメーターはローカルモードで ​true​ に設定する必要があります。

clientIdExpression

省略可能

#[vars.claimSet.client_id]
### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 例

JWT Origin (元の JWT)

要求のどこから JWT が抽出されるのかを指定します。 * HTTP ベアラー認証ヘッダー * カスタム式

この項目を ​HTTP Bearer Authentication Header​ に設定すると、JWT はベアラーと想定されます。
この項目を ​Custom Expression​ に設定する場合、トークンを返す DataWeave 式を指定します。

Token Expression (トークン式)

[JWT Origin (元の JWT)] を ​Custom Expression​ に設定した場合は、JWT を返す DataWeave 式をここに入力します。

#[attributes.headers['jwt']]
この式は、​jwt​ というヘッダー内の JWT を検索します。

JWT Signing Method (JWT 署名方法)

受信 JWT に期待される署名方法を指定します。JWT の署名方法が異なっている場合、ポリシーはトークンを拒否します。

RSA、HMAC、ES、None (なし)

JWT Signing Key Length (JWT 署名キーの長さ)

署名方法で使用されるキーの長さ (HMAC アルゴリズムの場合) またはアルゴリズム (RSA の場合) を指定します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

256、384、512。ES メソッドの場合、Flex Gateway は 256 キーまたは 384 キーの長さのみをサポートします。

JWT Key Origin (元の JWT キー)

署名検証用のキーの取得元を指定します。
[Text (テキスト)]​ オプションを選択するか、​JWKS​ から取得することで、ポリシーのキーを提供できます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

JWT Key (JWT キー)

この項目は、[JWT Key Origin (元の JWT キー)] で ​[Text (テキスト)]​ を選択した場合に表示されます。
この項目を使用して、トークンの署名を確認するために使用するキーを提供します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

HMAC の場合は 32、48、または 64 文字の文字列の共有シークレット、ES の場合は 32 文字の文字列の共有シークレット、RSA の場合はヘッダーとフッターのない PEM 公開キーを入力します。

JWKS URL

この項目は、[JWT Key Origin (元の JWT キー)] で ​[JWKS]​ を選択した場合に表示されます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

署名検証用の公開キーを含む JWKS サーバーの URL。URL のカンマ区切りリストを使用して複数の JWKS サーバーを設定します。

JWKS Caching Time To Live (JWKS キャッシュの存続時間)

JWKS が有効な時間 (分)。JWKS の有効期限が切れると、ポリシーによって各 JWKS サーバーから JWKS がもう一度取得されます。デフォルト値は 60 分です。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

この項目の入力値は、ポリシーで JWKS が有効とみなされる時間 (分) です。

JWKS サービス接続タイムアウト (ミリ秒)。

アクセストークン検証エンドポイントを認証するときに、各 JWKS サービスからの応答を待機する最大時間 (ミリ秒)。
デフォルト値は 10 秒です。

Skip Client ID Validation (クライアント ID 検証をスキップ)

この項目をオンにすると、JWT から抽出したクライアント ID が API の有効なクライアントアプリケーションと一致することの確認はされません。

Client ID Expression (クライアント ID 式)

[Skip Client ID Validation (クライアント ID 検証をスキップ)] を設定しない場合は、クライアント ID をトークンから抽出する必要があります。

デフォルトでは、この値は Oauth 2.0 トークンエクスチェンジドラフト​で指定されているように、式 ​#[vars.claimSet.client_id]​ を使用して抽出されます。

Validate Audience Claim (Audience クレームの検証)

Audience クレームの有効性を確認する必要があることを示します。​[Audience Claim Mandatory (Audience クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Expiration Claim (Expiration クレームの検証)

Expiration クレームの有効性を確認する必要があることを示します。​[Expiration Claim Mandatory (Expiration クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Not Before Claim (Not Before クレームの検証)

Not Before クレームの有効性を確認する必要があることを示します。​[Not Before Claim Mandatory (Not Before クレーム必須)]​ を選択すると、このクレームを「必須」に設定できます。

Validate Custom Claim (カスタムクレームの検証)

ポリシーでカスタム検証を使用できるようにします。すべての DataWeave 式が満たされた場合にのみ JWT が有効とみなされます。

ポリシーは、受信 JWT にあるすべてのクレームを含む ​claimSet​ 変数を提供します。次に例を示します。

foo : #[vars.claimSet.foo == 'fooValue']​

すべての DataWeave 式がブール値を返す必要があります。返さない場合は必ず式が失敗します。
## [](#ポリシーのしくみ)ポリシーのしくみ このポリシーは、このセクションで説明しているように、異なる方法でクレームと署名を検証します。 ### [](#署名の検証)署名の検証 このポリシーは、ポリシー設定で指定した値に基づいて JWT の署名を検証します。ポリシー設定で指定したアルゴリズムがトークンと一致しない場合や、トークンの署名が無効である場合、すべての JWT がポリシーで拒否されます。アルゴリズムが指定されていない場は、ポリシーは署名済みと未署名のすべてのトークンに一致します。 署名検証がサポートされているアルゴリズムは、次のとおりです。 - **対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する HMAC。 - **非対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する ES および RSA。 - **なし**​ - 署名検証なし。 JWS 構造内のアルゴリズムについての詳細は、 [JWA RFC 標準](https://tools.ietf.org/html/rfc7518#section-3.1)​を参照してください。 ### [](#クレームの検証)クレームの検証 クレーム検証では、ポリシーで受信したトークンを拒否する条件を選択できます。次の登録済みクレーム検証がデフォルトで提供されています。 - **aud:**​: Audience (オーディエンス) 検証。定義された値が少なくとも 1 つトークンに含まれていない場合、トークンを拒否しなければならないことを示す。 - **exp:**​: Expiration (有効期限) 検証。トークンの日付が検証日より後の場合、トークンを拒否しなければならないことを示す。 - **nbf**​: Not before (以降) 検証。検証日時がトークンの日時よりも前の場合、トークンを拒否しなければならないことを示す。 これらの​_提供されたクレーム_​に加え、検証で使用する他のクレームを指定することもできます。すべてのクレーム、​_登録済み_​または​_カスタム_​で、次の詳細を指定する必要があります。 - 検証するクレームの名前。 たとえば、トークンの発行者の場合は ​**iss**​。 - テストに使用する値。 リテラル値の検証のみが必要な場合は単純なリテラル値を指定し、より複雑な比較の場合は DataWeave 式を指定できます。 各クレーム検証は必須か必須でないかを定義できます。クレームを必須と定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはこのトークンを拒否します。クレームを必須でないと定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはその特定の検証ではトークンを拒否しません。 どちらも、クレームが含まれている場合、ポリシーはトークン値を検証します。検証が失敗すると、JWT は拒否されます。 ### [](#クレームの伝播)クレームの伝播 ポリシーが JWT を解析および検証したら、クレームはダウンストリームポリシーに伝播され、認証オブジェクトの ​**claims**​ プロパティを介して移動します。 クレームの値にアクセスするには、次の Dataweave 2.0 式の ​``​ をアクセス対象のクレームの名前に置き換えて使用します。 `#[authentication.properties.claims.]` JWT は下流にも伝播され、次の Dataweave 2.0 式でアクセスできます。 `#[authentication.properties.jwt]` #### [](#クライアント-id-の伝播)クライアント ID の伝播 クライアント ID 検証が有効になっていると、クライアント ID がクレームおよび予約済みの認証プロパティとして伝播されます。次の DataWeave 式を使用して、プロパティにアクセスします。 `#[authentication.clientId]` ### [](#再試行メカニズム)再試行メカニズム \[JWT Key Origin (元の JWT キー)\] として \[JSON Web Key Set (JWKS)\] を選択した場合、ポリシーは再試行メカニズムを使用して、失敗した JWKS フェッチを処理します。キャッシュされた JWKS が期限切れになるか存在せず、新しい要求がトリガーされるたびに、要求は各 JWKS サービスに送信されます。要求が失敗した場合、新しい JWKS が取得されて再度キャッシュされるまで、エクスポネンシャルバックオフ遅延のある一連の非同期要求が失敗した JWKS サービスに送信されます。 再キャッシュが完了するまで、期限切れの JWKS を使用して要求が処理され、要求が見つからない場合は ​`503`​ エラーが返されます。期限切れの JWKS を使用すると、前の要求が失敗した場合でも、今後の要求にキャッシュされた値を適用できます。 ## [](#ポリシーと互換性がある-pem-公開キーを取得する)ポリシーと互換性がある PEM 公開キーを取得する サポートされていない形式の既存の RSA キーを使用する場合、まずキーを PEM 公開キーに変換します。JWT ポリシーは、PEM 形式の公開 RSA キーを使用します。 **タスクの前提条件** 既存のキーを変換する前に次の作業を行います。 1. `public.pem`​ キーを取得します。 2. キーをポリシー設定に貼り付ける前に、​**\-----BEGIN PUBLIC KEY-----**​ ヘッダーと ​**\-----END PUBLIC KEY-----**​ フッターを削除します。 次の表に、現在の形式に基づいて既存のキーを変換する手順を示します。
開始点 手順

以前の証明書なし

  1. 非公開 RSA キーを生成します。 ​openssl genrsa -out key.pem 2048​

  2. 生成された非公開キー ​key.pem​ から、公開キーを抽出します。 ​openssl rsa -in key.pem -outform PEM -pubout -out public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。

PEM 証明書

  1. PEM 証明書から公開キーを抽出します。​openssl x509 -inform pem -in cert.pem -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

DER 証明書

  1. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

JWKS の x5c 項目

  1. チェーンから最初の証明書をコピーしてデコードします。echo <certificateString> | base64 -D > cert.crt​ (​<certificateString> をコピーした値に置き換える)

  2. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。
# JWT 検証ポリシー

ポリシー名

JWT 検証

概要

JWT トークンを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - トークンが要求で提供されなかった。

401

署名が検証されなかった、または無効である。

必要ないくつかのクレームがない、またはクレームの検証に失敗した。

トークンの解析に失敗した。
## [](#概要)概要 JSON Web Token (JWT) は、2 者間で転送されるクレームを表す URL セキュアな方法です。JWT のクレームは、JSON Web Signature (JWS) のペイロードまたはプレーンテキストの JSON Web Encryption (JWE) 構造として使用される JSON オブジェクトとしてエンコードされます。これにより、クレームはデジタル署名したり、メッセージ認証コード (MAC) で整合性を保護したりできます。トークンは署名されるので、その情報と情報源を信頼できます。 JWT 検証ポリシーは、トークンの署名を検証し、JWS 形式の JWT を使用してすべての受信要求のクレームの値をアサートします。このポリシーでは、JWE を使用する JWT は検証されません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して JWT 検証ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: jwt-validation-flex config:
パラメーター 必須または省略可能 デフォルト値 説明

signingMethod

省略可能

rsa

キーの署名方式を含む文字列。サポートされている値: rsa​、​hmac​、​es​、​none​

signingKeyLength

省略可能

256

キーの長さを示す数値。サポートされている値は 256、384、512 です。ES メソッドの場合、Flex Gateway は 256 キーおよび 384 キーの長さをサポートします。

textKey

省略可能

your-(256|384|512)-bit-secret/your-public-pem-certificate

jwtOrigin

省略可能

httpBearerAuthenticationHeader

jwtKeyOrigin

省略可能

text

jwksUrl

省略可能

http://your-jwks-service.example:80/base/path

署名検証用の公開キーを含む JWKS サーバーの URL。URL のカンマ区切りリストを使用して複数の JWKS サーバーを設定します。

jwksServiceTimeToLive

省略可能

60

ポリシーで JWKS が有効とみなされる時間 (分)。

jwksServiceConnectionTimeout

省略可能

10000

アクセストークン検証エンドポイントを認証するときに、各 JWKS サービスからの応答を待機する最大時間 (ミリ秒)。

validateAudClaim

省略可能

false

mandatoryAudClaim

省略可能

false

mandatoryNbfClaim

省略可能

false

mandatoryExpClaim

省略可能

false

supportedAudiences

省略可能

空の文字列

validateCustomClaim

省略可能

false

mandatoryCustomClaims

省略可能

空の配列

nonMandatoryCustomClaims

省略可能

空の配列

jwtExpression

省略可能

#[attributes.headers['jwt']]

skipClientIdValidation

必須

true

このパラメーターはローカルモードで ​true​ に設定する必要があります。

clientIdExpression

省略可能

#[vars.claimSet.client_id]
### [](#flex-gateway-の接続モード)Flex Gateway の接続モード #### [](#パラメーターの設定)パラメーターの設定 UI を使用してポリシーを API に適用する場合は、以下のパラメーターを設定できます。
要素 説明 例

JWT Origin (元の JWT)

要求のどこから JWT が抽出されるのかを指定します。 * HTTP ベアラー認証ヘッダー * カスタム式

この項目を ​HTTP Bearer Authentication Header​ に設定すると、JWT はベアラーと想定されます。
この項目を ​Custom Expression​ に設定する場合、トークンを返す DataWeave 式を指定します。

Token Expression (トークン式)

[JWT Origin (元の JWT)] を ​Custom Expression​ に設定した場合は、JWT を返す DataWeave 式をここに入力します。

#[attributes.headers['jwt']]
この式は、​jwt​ というヘッダー内の JWT を検索します。

JWT Signing Method (JWT 署名方法)

受信 JWT に期待される署名方法を指定します。JWT の署名方法が異なっている場合、ポリシーはトークンを拒否します。

RSA、HMAC、ES、None (なし)

JWT Signing Key Length (JWT 署名キーの長さ)

署名方法で使用されるキーの長さ (HMAC アルゴリズムの場合) またはアルゴリズム (RSA の場合) を指定します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

256、384、512。ES メソッドの場合、Flex Gateway は 256 キーまたは 384 キーの長さのみをサポートします。

JWT Key Origin (元の JWT キー)

署名検証用のキーの取得元を指定します。
[Text (テキスト)]​ オプションを選択するか、​JWKS​ から取得することで、ポリシーのキーを提供できます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

JWT Key (JWT キー)

この項目は、[JWT Key Origin (元の JWT キー)] で ​[Text (テキスト)]​ を選択した場合に表示されます。
この項目を使用して、トークンの署名を確認するために使用するキーを提供します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

HMAC の場合は 32、48、または 64 文字の文字列の共有シークレット、ES の場合は 32 文字の文字列の共有シークレット、RSA の場合はヘッダーとフッターのない PEM 公開キーを入力します。

JWKS URL

この項目は、[JWT Key Origin (元の JWT キー)] で ​[JWKS]​ を選択した場合に表示されます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

署名検証用の公開キーを含む JWKS サーバーの URL。URL のカンマ区切りリストを使用して複数の JWKS サーバーを設定します。

JWKS Caching Time To Live (JWKS キャッシュの存続時間)

JWKS が有効な時間 (分)。JWKS の有効期限が切れると、ポリシーによって各 JWKS サーバーから JWKS がもう一度取得されます。デフォルト値は 60 分です。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

この項目の入力値は、ポリシーで JWKS が有効とみなされる時間 (分) です。

JWKS サービス接続タイムアウト (ミリ秒)。

アクセストークン検証エンドポイントを認証するときに、各 JWKS サービスからの応答を待機する最大時間 (ミリ秒)。
デフォルト値は 10 秒です。

Skip Client ID Validation (クライアント ID 検証をスキップ)

この項目をオンにすると、JWT から抽出したクライアント ID が API の有効なクライアントアプリケーションと一致することの確認はされません。

Client ID Expression (クライアント ID 式)

[Skip Client ID Validation (クライアント ID 検証をスキップ)] を設定しない場合は、クライアント ID をトークンから抽出する必要があります。

デフォルトでは、この値は Oauth 2.0 トークンエクスチェンジドラフト​で指定されているように、式 ​#[vars.claimSet.client_id]​ を使用して抽出されます。

Validate Audience Claim (Audience クレームの検証)

Audience クレームの有効性を確認する必要があることを示します。​[Audience Claim Mandatory (Audience クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Expiration Claim (Expiration クレームの検証)

Expiration クレームの有効性を確認する必要があることを示します。​[Expiration Claim Mandatory (Expiration クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Not Before Claim (Not Before クレームの検証)

Not Before クレームの有効性を確認する必要があることを示します。​[Not Before Claim Mandatory (Not Before クレーム必須)]​ を選択すると、このクレームを「必須」に設定できます。

Validate Custom Claim (カスタムクレームの検証)

ポリシーでカスタム検証を使用できるようにします。すべての DataWeave 式が満たされた場合にのみ JWT が有効とみなされます。

ポリシーは、受信 JWT にあるすべてのクレームを含む ​claimSet​ 変数を提供します。次に例を示します。

foo : #[vars.claimSet.foo == 'fooValue']​

すべての DataWeave 式がブール値を返す必要があります。返さない場合は必ず式が失敗します。
#### [](#anypoint-service-mesh-非-mule-アプリケーション-のパラメーターの設定)Anypoint Service Mesh (非 Mule アプリケーション) のパラメーターの設定 Anypoint Service Mesh (非 Mule アプリケーション) の場合、JWT 検証ポリシーを同じ方法で設定しますが、次の違いがあります。 - ポリシーはクレーム検証の DataWeave 式を受け入れません。 - 次の表で説明しているように、トークン取得およびクライアント ID 検証パラメーターは異なります。
要素 説明 例

JWT Origin (元の JWT)

要求のどこから JWT を抽出するかを指定します。

  • jwt Header​: そのヘッダーから JWT を抽出する

  • HTTP Bearer Authentication Header​: ベアラーであると想定される JWT

  • Custom Header​: JWT は入力であると想定されるヘッダーの名前を取得する

Token Header (トークンヘッダー)

[JWT Origin (元の JWT)]​ を ​Custom Header​ に設定した場合は、JWT を含むヘッダーの名前を指定します。

myJwtHeader​

Client ID Claim (クライアント ID クレーム)

[Skip Client ID Validation (クライアント ID 検証をスキップ)]​ を設定しない場合、クライアント ID はトークンから抽出されます。

デフォルトでは、この値は ​client_id​ クレームから抽出されます。
## [](#ポリシーのしくみ)ポリシーのしくみ このポリシーは、このセクションで説明しているように、異なる方法でクレームと署名を検証します。 ### [](#署名の検証)署名の検証 このポリシーは、ポリシー設定で指定した値に基づいて JWT の署名を検証します。ポリシー設定で指定したアルゴリズムがトークンと一致しない場合や、トークンの署名が無効である場合、すべての JWT がポリシーで拒否されます。アルゴリズムが指定されていない場は、ポリシーは署名済みと未署名のすべてのトークンに一致します。 署名検証がサポートされているアルゴリズムは、次のとおりです。 - **対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する HMAC。 - **非対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する ES および RSA。 - **なし**​ - 署名検証なし。 JWS 構造内のアルゴリズムについての詳細は、 [JWA RFC 標準](https://tools.ietf.org/html/rfc7518#section-3.1)​を参照してください。 ### [](#クレームの検証)クレームの検証 クレーム検証では、ポリシーで受信したトークンを拒否する条件を選択できます。次の登録済みクレーム検証がデフォルトで提供されています。 - **aud:**​: Audience (オーディエンス) 検証。定義された値が少なくとも 1 つトークンに含まれていない場合、トークンを拒否しなければならないことを示す。 - **exp:**​: Expiration (有効期限) 検証。トークンの日付が検証日より後の場合、トークンを拒否しなければならないことを示す。 - **nbf**​: Not before (以降) 検証。検証日時がトークンの日時よりも前の場合、トークンを拒否しなければならないことを示す。 これらの​_提供されたクレーム_​に加え、検証で使用する他のクレームを指定することもできます。すべてのクレーム、​_登録済み_​または​_カスタム_​で、次の詳細を指定する必要があります。 - 検証するクレームの名前。 たとえば、トークンの発行者の場合は ​**iss**​。 - テストに使用する値。 リテラル値の検証のみが必要な場合は単純なリテラル値を指定し、より複雑な比較の場合は DataWeave 式を指定できます。 各クレーム検証は必須か必須でないかを定義できます。クレームを必須と定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはこのトークンを拒否します。クレームを必須でないと定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはその特定の検証ではトークンを拒否しません。 どちらも、クレームが含まれている場合、ポリシーはトークン値を検証します。検証が失敗すると、JWT は拒否されます。 ### [](#クレームの伝播)クレームの伝播 ポリシーが JWT を解析および検証したら、クレームはダウンストリームポリシーに伝播され、認証オブジェクトの ​**claims**​ プロパティを介して移動します。 クレームの値にアクセスするには、次の DataWeave 式の ​``​ をアクセス対象のクレームの名前に置き換えて使用します。 `#[authentication.properties.claims.]` JWT は下流にも伝播され、次の DataWeave 式でアクセスできます。 `#[authentication.properties.jwt]` #### [](#クライアント-id-の伝播)クライアント ID の伝播 クライアント ID 検証が有効になっていると、クライアント ID がクレームおよび予約済みの認証プロパティとして伝播されます。次の DataWeave 式を使用して、プロパティにアクセスします。 `#[authentication.clientId]` ### [](#再試行メカニズム)再試行メカニズム \[JWT Key Origin (元の JWT キー)\] として \[JSON Web Key Set (JWKS)\] を選択した場合、ポリシーは再試行メカニズムを使用して、失敗した JWKS フェッチを処理します。キャッシュされた JWKS が期限切れになるか存在せず、新しい要求がトリガーされるたびに、要求は各 JWKS サービスに送信されます。要求が失敗した場合、新しい JWKS が取得されて再度キャッシュされるまで、エクスポネンシャルバックオフ遅延のある一連の非同期要求が失敗した JWKS サービスに送信されます。 再キャッシュが完了するまで、期限切れの JWKS を使用して要求が処理され、要求が見つからない場合は ​`503`​ エラーが返されます。期限切れの JWKS を使用すると、前の要求が失敗した場合でも、今後の要求にキャッシュされた値を適用できます。 ## [](#ポリシーと互換性がある-pem-公開キーを取得する)ポリシーと互換性がある PEM 公開キーを取得する サポートされていない形式の既存の RSA キーを使用する場合、まずキーを PEM 公開キーに変換します。JWT ポリシーは、PEM 形式の公開 RSA キーを使用します。 **タスクの前提条件** 既存のキーを変換する前に次の作業を行います。 1. `public.pem`​ キーを取得します。 2. キーをポリシー設定に貼り付ける前に、​**\-----BEGIN PUBLIC KEY-----**​ ヘッダーと ​**\-----END PUBLIC KEY-----**​ フッターを削除します。 次の表に、現在の形式に基づいて既存のキーを変換する手順を示します。
開始点 手順

以前の証明書なし

  1. 非公開 RSA キーを生成します。 ​openssl genrsa -out key.pem 2048​

  2. 生成された非公開キー ​key.pem​ から、公開キーを抽出します。 ​openssl rsa -in key.pem -outform PEM -pubout -out public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。

PEM 証明書

  1. PEM 証明書から公開キーを抽出します。​openssl x509 -inform pem -in cert.pem -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

DER 証明書

  1. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

JWKS の x5c 項目

  1. チェーンから最初の証明書をコピーしてデコードします。echo <certificateString> | base64 -D > cert.crt​ (​<certificateString> をコピーした値に置き換える)

  2. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。
# JWT 検証ポリシー

ポリシー名

JWT 検証

概要

JWT トークンを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - トークンが要求で提供されなかった。

401

署名が検証されなかった、または無効である。

必要ないくつかのクレームがない、またはクレームの検証に失敗した。

トークンの解析に失敗した。
## [](#概要)概要 JSON Web Token (JWT) は、2 者間で転送されるクレームを表す URL セキュアな方法です。JWT のクレームは、JSON Web Signature (JWS) のペイロードまたはプレーンテキストの JSON Web Encryption (JWE) 構造として使用される JSON オブジェクトとしてエンコードされます。これにより、クレームはデジタル署名したり、メッセージ認証コード (MAC) で整合性を保護したりできます。トークンは署名されるので、その情報と情報源を信頼できます。 JWT 検証ポリシーは、トークンの署名を検証し、JWS 形式の JWT を使用してすべての受信要求のクレームの値をアサートします。このポリシーでは、JWE を使用する JWT は検証されません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: jwt-validation-flex config:
パラメーター 必須または省略可能 デフォルト値 説明

signingMethod

省略可能

rsa

キーの署名方式を含む文字列。サポートされている値: rsa​、​hmac​、​es​、​none​

signingKeyLength

省略可能

256

キーの長さを示す数値。サポートされている値は 256、384、512 です。ES メソッドの場合、Flex Gateway は 256 キーおよび 384 キーの長さをサポートします。

textKey

省略可能

your-(256|384|512)-bit-secret/your-public-pem-certificate

jwtOrigin

省略可能

httpBearerAuthenticationHeader

jwtKeyOrigin

省略可能

text

jwksUrl

省略可能

http://your-jwks-service.example:80/base/path

署名検証用の公開キーを含む JWKS サーバーの URL。URL のカンマ区切りリストを使用して複数の JWKS サーバーを設定します。

jwksServiceTimeToLive

省略可能

60

ポリシーで JWKS が有効とみなされる時間 (分)。

jwksServiceConnectionTimeout

省略可能

10000

アクセストークン検証エンドポイントを認証するときに、各 JWKS サービスからの応答を待機する最大時間 (ミリ秒)。

validateAudClaim

省略可能

false

mandatoryAudClaim

省略可能

false

mandatoryNbfClaim

省略可能

false

mandatoryExpClaim

省略可能

false

supportedAudiences

省略可能

空の文字列

validateCustomClaim

省略可能

false

mandatoryCustomClaims

省略可能

空の配列

nonMandatoryCustomClaims

省略可能

空の配列

jwtExpression

省略可能

#[attributes.headers['jwt']]

skipClientIdValidation

必須

true

このパラメーターはローカルモードで ​true​ に設定する必要があります。

clientIdExpression

省略可能

#[vars.claimSet.client_id]
### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 例

JWT Origin (元の JWT)

要求のどこから JWT が抽出されるのかを指定します。 * HTTP ベアラー認証ヘッダー * カスタム式

この項目を ​HTTP Bearer Authentication Header​ に設定すると、JWT はベアラーと想定されます。
この項目を ​Custom Expression​ に設定する場合、トークンを返す DataWeave 式を指定します。

Token Expression (トークン式)

[JWT Origin (元の JWT)] を ​Custom Expression​ に設定した場合は、JWT を返す DataWeave 式をここに入力します。

#[attributes.headers['jwt']]
この式は、​jwt​ というヘッダー内の JWT を検索します。

JWT Signing Method (JWT 署名方法)

受信 JWT に期待される署名方法を指定します。JWT の署名方法が異なっている場合、ポリシーはトークンを拒否します。

RSA、HMAC、ES、None (なし)

JWT Signing Key Length (JWT 署名キーの長さ)

署名方法で使用されるキーの長さ (HMAC アルゴリズムの場合) またはアルゴリズム (RSA の場合) を指定します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

256、384、512。ES メソッドの場合、Flex Gateway は 256 キーまたは 384 キーの長さのみをサポートします。

JWT Key Origin (元の JWT キー)

署名検証用のキーの取得元を指定します。
[Text (テキスト)]​ オプションを選択するか、​JWKS​ から取得することで、ポリシーのキーを提供できます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

JWT Key (JWT キー)

この項目は、[JWT Key Origin (元の JWT キー)] で ​[Text (テキスト)]​ を選択した場合に表示されます。
この項目を使用して、トークンの署名を確認するために使用するキーを提供します。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

HMAC の場合は 32、48、または 64 文字の文字列の共有シークレット、ES の場合は 32 文字の文字列の共有シークレット、RSA の場合はヘッダーとフッターのない PEM 公開キーを入力します。

JWKS URL

この項目は、[JWT Key Origin (元の JWT キー)] で ​[JWKS]​ を選択した場合に表示されます。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

署名検証用の公開キーを含む JWKS サーバーの URL。URL のカンマ区切りリストを使用して複数の JWKS サーバーを設定します。

JWKS Caching Time To Live (JWKS キャッシュの存続時間)

JWKS が有効な時間 (分)。JWKS の有効期限が切れると、ポリシーによって各 JWKS サーバーから JWKS がもう一度取得されます。デフォルト値は 60 分です。
[JWT Signing Method (JWT 署名方法)] で ​[None (なし)]​ を選択した場合は、この項目を無視します。

この項目の入力値は、ポリシーで JWKS が有効とみなされる時間 (分) です。

JWKS サービス接続タイムアウト (ミリ秒)。

アクセストークン検証エンドポイントを認証するときに、各 JWKS サービスからの応答を待機する最大時間 (ミリ秒)。
デフォルト値は 10 秒です。

Skip Client ID Validation (クライアント ID 検証をスキップ)

この項目をオンにすると、JWT から抽出したクライアント ID が API の有効なクライアントアプリケーションと一致することの確認はされません。

Client ID Expression (クライアント ID 式)

[Skip Client ID Validation (クライアント ID 検証をスキップ)] を設定しない場合は、クライアント ID をトークンから抽出する必要があります。

デフォルトでは、この値は Oauth 2.0 トークンエクスチェンジドラフト​で指定されているように、式 ​#[vars.claimSet.client_id]​ を使用して抽出されます。

Validate Audience Claim (Audience クレームの検証)

Audience クレームの有効性を確認する必要があることを示します。​[Audience Claim Mandatory (Audience クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Expiration Claim (Expiration クレームの検証)

Expiration クレームの有効性を確認する必要があることを示します。​[Expiration Claim Mandatory (Expiration クレーム必須)]​ を選択して、このクレームを「必須」に設定できます。

Validate Not Before Claim (Not Before クレームの検証)

Not Before クレームの有効性を確認する必要があることを示します。​[Not Before Claim Mandatory (Not Before クレーム必須)]​ を選択すると、このクレームを「必須」に設定できます。

Validate Custom Claim (カスタムクレームの検証)

ポリシーでカスタム検証を使用できるようにします。すべての DataWeave 式が満たされた場合にのみ JWT が有効とみなされます。

ポリシーは、受信 JWT にあるすべてのクレームを含む ​claimSet​ 変数を提供します。次に例を示します。

foo : #[vars.claimSet.foo == 'fooValue']​

すべての DataWeave 式がブール値を返す必要があります。返さない場合は必ず式が失敗します。
## [](#ポリシーのしくみ)ポリシーのしくみ このポリシーは、このセクションで説明しているように、異なる方法でクレームと署名を検証します。 ### [](#署名の検証)署名の検証 このポリシーは、ポリシー設定で指定した値に基づいて JWT の署名を検証します。ポリシー設定で指定したアルゴリズムがトークンと一致しない場合や、トークンの署名が無効である場合、すべての JWT がポリシーで拒否されます。アルゴリズムが指定されていない場は、ポリシーは署名済みと未署名のすべてのトークンに一致します。 署名検証がサポートされているアルゴリズムは、次のとおりです。 - **対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する HMAC。 - **非対称アルゴリズム**​ - SHA-256、SHA-384、SHA-512 を使用する ES および RSA。 - **なし**​ - 署名検証なし。 JWS 構造内のアルゴリズムについての詳細は、 [JWA RFC 標準](https://tools.ietf.org/html/rfc7518#section-3.1)​を参照してください。 ### [](#クレームの検証)クレームの検証 クレーム検証では、ポリシーで受信したトークンを拒否する条件を選択できます。次の登録済みクレーム検証がデフォルトで提供されています。 - **aud:**​: Audience (オーディエンス) 検証。定義された値が少なくとも 1 つトークンに含まれていない場合、トークンを拒否しなければならないことを示す。 - **exp:**​: Expiration (有効期限) 検証。トークンの日付が検証日より後の場合、トークンを拒否しなければならないことを示す。 - **nbf**​: Not before (以降) 検証。検証日時がトークンの日時よりも前の場合、トークンを拒否しなければならないことを示す。 これらの​_提供されたクレーム_​に加え、検証で使用する他のクレームを指定することもできます。すべてのクレーム、​_登録済み_​または​_カスタム_​で、次の詳細を指定する必要があります。 - 検証するクレームの名前。 たとえば、トークンの発行者の場合は ​**iss**​。 - テストに使用する値。 リテラル値の検証のみが必要な場合は単純なリテラル値を指定し、より複雑な比較の場合は DataWeave 式を指定できます。 各クレーム検証は必須か必須でないかを定義できます。クレームを必須と定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはこのトークンを拒否します。クレームを必須でないと定義し、そのクレームが受信 JWT に含まれていない場合、ポリシーはその特定の検証ではトークンを拒否しません。 どちらも、クレームが含まれている場合、ポリシーはトークン値を検証します。検証が失敗すると、JWT は拒否されます。 ### [](#クレームの伝播)クレームの伝播 ポリシーが JWT を解析および検証したら、クレームはダウンストリームポリシーに伝播され、認証オブジェクトの ​**claims**​ プロパティを介して移動します。 クレームの値にアクセスするには、次の Dataweave 2.0 式の ​``​ をアクセス対象のクレームの名前に置き換えて使用します。 `#[authentication.properties.claims.]` JWT は下流にも伝播され、次の Dataweave 2.0 式でアクセスできます。 `#[authentication.properties.jwt]` #### [](#クライアント-id-の伝播)クライアント ID の伝播 クライアント ID 検証が有効になっていると、クライアント ID がクレームおよび予約済みの認証プロパティとして伝播されます。次の DataWeave 式を使用して、プロパティにアクセスします。 `#[authentication.clientId]` ### [](#再試行メカニズム)再試行メカニズム \[JWT Key Origin (元の JWT キー)\] として \[JSON Web Key Set (JWKS)\] を選択した場合、ポリシーは再試行メカニズムを使用して、失敗した JWKS フェッチを処理します。キャッシュされた JWKS が期限切れになるか存在せず、新しい要求がトリガーされるたびに、要求は各 JWKS サービスに送信されます。要求が失敗した場合、新しい JWKS が取得されて再度キャッシュされるまで、エクスポネンシャルバックオフ遅延のある一連の非同期要求が失敗した JWKS サービスに送信されます。 再キャッシュが完了するまで、期限切れの JWKS を使用して要求が処理され、要求が見つからない場合は ​`503`​ エラーが返されます。期限切れの JWKS を使用すると、前の要求が失敗した場合でも、今後の要求にキャッシュされた値を適用できます。 ## [](#ポリシーと互換性がある-pem-公開キーを取得する)ポリシーと互換性がある PEM 公開キーを取得する サポートされていない形式の既存の RSA キーを使用する場合、まずキーを PEM 公開キーに変換します。JWT ポリシーは、PEM 形式の公開 RSA キーを使用します。 **タスクの前提条件** 既存のキーを変換する前に次の作業を行います。 1. `public.pem`​ キーを取得します。 2. キーをポリシー設定に貼り付ける前に、​**\-----BEGIN PUBLIC KEY-----**​ ヘッダーと ​**\-----END PUBLIC KEY-----**​ フッターを削除します。 次の表に、現在の形式に基づいて既存のキーを変換する手順を示します。
開始点 手順

以前の証明書なし

  1. 非公開 RSA キーを生成します。 ​openssl genrsa -out key.pem 2048​

  2. 生成された非公開キー ​key.pem​ から、公開キーを抽出します。 ​openssl rsa -in key.pem -outform PEM -pubout -out public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。

PEM 証明書

  1. PEM 証明書から公開キーを抽出します。​openssl x509 -inform pem -in cert.pem -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

DER 証明書

  1. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  2. 公開キーはファイル public.pem 内に含まれます。

JWKS の x5c 項目

  1. チェーンから最初の証明書をコピーしてデコードします。echo <certificateString> | base64 -D > cert.crt​ (​<certificateString> をコピーした値に置き換える)

  2. DER 証明書から公開キーを抽出します。​openssl x509 -inform der -in cert.crt -pubkey -noout > public.pem​

  3. 公開キーはファイル public.pem 内に含まれます。
# Kubernetes クラスターでの Flex Gateway の使用開始 Kubernetes クラスターまたは Kubernetes クラスターに基づく OpenShift クラスターで Anypoint Flex Gateway の使用を開始します。Anypoint Platform に接続する Flex Gateway デプロイメントをセットアップし、そのデプロイメントを使用してトラフィックを API にルーティングします。このガイドでは、次のタスクの概要について説明します。 - トークンを使用した​[接続モード](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-token#k8-token)​での Flex Gateway のダウンロード、登録、デプロイメント - API Manager でのゲートウェイで実行されるシンプルな API の作成 - API Manager で設定する基本認証ポリシーを使用した API の保護 Flex Gateway デプロイメントプロセスでは、自分で作成する、または Kubernetes プロフェッショナルがプロビジョニングする有効な Kubernetes クラスターが必要です。 Kubernetes クラスターのセットアップには、​_このガイドには記載されていない_​スキルや専門知識のレベルが求められます。Kubernetes のクラスター設定は、サービスプロバイダーやプラットフォームによって大きく異なります。クラスター設定に関する質問がある場合は、Kubernetes サービスプロバイダーのドキュメントを参照するか、 [Kubernetes ドキュメント](https://kubernetes.io/docs/setup/)​を使用してください。 Kubernetes クラスターはないが、クラスターを作成せずに Flex Gateway をすぐに試してみたい場合は、(Docker の) ​[「Flex Gateway の使用開始」](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started)​を参照してください。このガイドでは Docker のみを使用するため、クラスター設定は必要ありません。 ## [](#始める前に)始める前に このガイドの手順を開始する前に、次の前提条件を満たしていることを確認します。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。Anypoint Platform アカウントを持っていない場合は、Anypoint Platform で [トライアル組織を作成](https://anypoint.mulesoft.com/login/signup)​してください。 - Docker のインストール。 ターミナルウィンドウから ​`docker --version`​ を実行して、このツールがインストールされているかどうかを調べます。Docker をインストールする必要がある場合は、 [Docker Desktop](https://www.docker.com/)​ をお試しください。 - Helm バージョン 3.0.0 以降が必要です。 ターミナルウィンドウから ​`helm version`​ を実行して、このツールがインストールされているかどうかを調べ、そのバージョンを確認します。インストールまたはアップグレードするには、 [Helm](https://helm.sh/)​ Web サイトを使用します。 - Kubernetes ​`kubectl`​ コマンドラインツール。 ターミナルウィンドウから ​`kubectl version --output=yaml`​ を実行して、このツールがインストールされているかどうかを調べます。インストールされていない場合、 [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/tools/)​を参照して、使用可能なインストールツールから ​`kubectl`​ を見つけます。 - `curl`​ コマンドラインツール。 ターミナルウィンドウから ​`curl --version`​ を実行して、このツールがインストールされているかどうかを調べます。インストールされていない場合、パッケージマネージャーを使用してマシンにダウンロードします。 ## [](#kubernetes-cluster-reqs)クラスターの要件 Kubernetes クラスターのホストは、一般的なクラウドベースサービス (Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) など) を含む、いずれかの​[サポートされている Kubernetes プロバイダー](https://docs.mulesoft.com/jp/gateway/1.8/flex-review-prerequisites#software-requirements)​になります。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 このガイドの手順を完了するには、Kubernetes クラスターを作成するか、Flex Gateway デプロイメントの既存の Kubernetes クラスターを使用する必要があります。このガイドでは、Helm を使用して Flex Gateway を Kubernetes クラスターにデプロイし、Anypoint Platform に接続します。 このガイドのデモ目的で使用される小規模な Kubernetes クラスターには次の最小要件が適用されます (​_本番環境の要件には適用されません_​)。 - 1 つ以上のノード。 - `LoadBalancer`​ 種別の ​`Service`​ リソースの作成のサポート。 この要件により、このガイドの使用時にデプロイメントエラーを回避できます。ただし、ゲートウェイをデプロイするときに ​`Service`​ 種別をカスタマイズすることもできます。Flex Gateway では、​`ClusterIP`​、​`NodePort`​、​`LoadBalancer`​ (デフォルト)、​`ExternalName`​ サービスがサポートされています。 [「Helm chart for Flex Gateway (Flex Gateway の Helm チャート)」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​の ​`service.type`​ キーを参照してください。 - デプロイメント手順に必要な計算リソースが次の値 (EKS t3.micro インスタンス種別に相当) を超えることは​_ほとんどありません_​。 - vCPU: 2 vCPU - メモリ: 1 GiB - ネットワーク: 最大 5 ギガビット - 最大 ENI: 2 - 最大 IP: 4 クラスターの​[デプロイメント手順](#deploy-flex)​の準備ができているかどうかを調べるには、デプロイメントを​_開始する前_​に​[クラスターを確認する](#check-cluster)​を確認する必要があります。このチェックでは、一連の ​`kubectl`​ コマンドを実行する必要があります。 ## [](#download-flex)ステップ 1: Flex Gateway イメージをダウンロードする Docker を使用して、Docker Hub リポジトリから Flex Gateway イメージをダウンロードします。 この手順は、​[ステップ 2: Flex Gateway を登録する](#register-flex)​で Flex Gateway を Anypoint Platform に登録するための前提条件です。登録は、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Helm を介してゲートウェイをデプロイするときに行う必要があります。 1. ターミナルウィンドウで次のコマンドを実行して、Docker が実行されていることを確認します。 ```docker docker info ``` このコマンドの実行後にエラーが発生した場合は、​[Docker のトラブルシューティング](#docker-troubleshooting)​に関する情報を参照してください。 2. ターミナルウィンドウで次のコマンドを実行します。 ```docker docker pull mulesoft/flex-gateway:1.8.0 ``` このコマンドが成功すると、次のようなメッセージがターミナルウィンドウに出力されます。 latest: Pulling from mulesoft/flex-gateway Digest: sha256:e55555abcdefg1234567zxynwo33333fadjf Status: Image is up to date for mulesoft/flex-gateway:latest docker.io/mulesoft/flex-gateway:latest このコマンドの実行時に権限の問題が発生した場合は、​`sudo`​ を使用してください。 ## [](#register-flex)ステップ 2: Flex Gateway を登録する Anypoint Runtime Manager で生成された一時トークンを使用して、ターミナルウィンドウから Flex Gateway イメージを登録します。この手順では、名前付きゲートウェイの登録プロパティが含まれるローカル ​`registration.yaml`​ ファイルが生成されます。これらのプロパティは、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Helm チャートに組み込まれます。 1. ターミナルウィンドウから、Flex Gateway 登録ファイル (​`registration.yaml`​) のディレクトリを準備します。 1. ディレクトリを作成します。 ```mkdir mkdir flex-registration ``` 2. 新しいディレクトリに移動します。 ```cd cd flex-registration ``` 2. [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインし、​**\[Runtime Manager\]**​ を選択します。 3. Runtime Manager から、Flex Gateway を登録する手順を見つけます。 1. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 2. **\[Add Gateway (ゲートウェイを追加)\]**​ をクリックします。 3. 次のいずれかの環境を選択します。 - **Kubernetes**​ - **OpenShift** 4. 開いたページで、​**\[Register your gateway (ゲートウェイを登録)\]**​ セクションでコマンドを見つけます。 Kubernetes の例: ![\[Add a Flex Gateway (Flex Gateway の追加)\] ページから登録コードブロックを追加する](_images/gateway-quickstart-k8-add-gateway-rtm.png) 強調表示されたコマンドブロックには、一意の組織 ID と一時トークンが含まれています。 4. ターミナルウィンドウで、Runtime Manager から ​`./flex-registration`​ ディレクトリにコマンドブロックをコピーします。 Runtime Manager によって必要な組織およびトークン値が提供されます。 5. コマンドを実行する前に、コマンドブロックの最後の ​``​ をゲートウェイの​_一意_​の名前 (​`my-gateway`​ など) に置き換えます。 ゲートウェイに指定する名前は、Anypoint Platform 組織および環境のスコープ内で一意である必要があります。この登録ステップは一度完了すれば済みます。名前付きゲートウェイおよび組織ごとに​_複数回行う必要はありません_​。 6. ターミナルウィンドウから、編集したコマンドを実行します。 コマンドが成功すると、​`./flex-registration`​ ディレクトリに ​`registration.yaml`​ が生成され、次のメッセージがターミナルウィンドウに表示されます。 Starting registration, please be patient. Registration completed, the configuration files were written in directory "/registration". For security, modify the file permissions to restrict production scenario access to the user running flex. ターミナルウィンドウのメッセージの ​`/registration`​ は、Docker コンテナ内のディレクトリを表しています。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。コマンドを実行する前にトークンの期限が切れた場合、​`400 Bad Request (400 不正な要求)`​ エラーが発生します。その場合、\[Runtime Manager\] ページを更新して、新しいトークンを生成し、ページに表示される変更済みのコマンドを実行する必要があります。 ## [](#create-repo)ステップ 3: Helm チャートのリポジトリを追加する Flex Gateway チャートリポジトリを追加します。Flex Gateway の Helm チャートのプロパティについての詳細は、 [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ を参照してください。 1. Helm チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 ## [](#deploy-flex)ステップ 4: Flex Gateway をデプロイして接続する Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 始める前に: [クラスターを確認する](#check-cluster)​の手順に従って、Kubernetes クラスターが使用可能であることを確認します。まだ​[クラスターの要件](#kubernetes-cluster-reqs)​を確認していない場合は確認します。これらの前提条件は、デプロイメントエラーを回避するのに役立ちます。 Kubernetes クラスターの準備ができていることを確認したら、ゲートウェイをデプロイして接続します。 1. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ リリースが作成されます (これらが存在しない場合)。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。 このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 `UPGRADE FAILED`​ 応答を受信した場合は、この問題に関する​[トラブルシューティング](#troubleshoot-helm-upgrade-failed)​情報を参照してください。 2. ゲートウェイを実行するポッドの状況を確認する場合は、次の ​`kubectl`​ コマンドを実行します。 ```kubectl kubectl get pods -n gateway ``` 出力に、ポッドが ​`gateway`​ 名前空間で正常に実行されているかどうかが示されます。 NAME READY STATUS RESTARTS AGE ingress-57bc75cb46-dmkdq 1/1 Running 0 35s 3. Runtime Manager に戻ります。 1. **\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページのサイドナビゲーションパネルから ​**\[← Flex Gateway\]**​ を選択します。 ![Runtime Manager の \[Flex Gateway\] リストに戻る](_images/gateway-quickstart-k8-return-to-gateway-list.png) 2. **\[Flex Gateways\]**​ ページの登録済みゲートウェイに移動します。 ![Runtime Manager の Flex Gateway my-gateway](/mulesoft/current/ja-jp/gateway/1.8/_images/gateway-quickstart-k8-my-gateway-rtm.png) ページの検索項目を使用して、ゲートウェイのリストを絞り込むことができます。 3. ゲートウェイの状況が ​**\[Connected (接続済み)\]**​ であることを確認します。 状況は ​**\[Disconnected (切断済み)\]**​ の場合、クラスター設定が正しくないか、ネットワークの問題が発生している可能性があります。詳細は、​[トラブルシューティング](#troubleshooting-k8)​を参照してください。 ## [](#create-api)ステップ 5: シンプルな API をパブリッシュして Flex Gateway にデプロイする Anypoint API Manager でシンプルな API を作成してゲートウェイにデプロイします。 1. Runtime Manager で、ゲートウェイの ​**\[View APIs (API を表示)\]**​ メニューオプションをクリックし、その ​**\[View APIs (API を表示)\]**​ ページに移動します。 ![Flex Gateway の \[View APIs (API を表示)\] メニュー項目](_images/gateway-quickstart-k8-view-apis.png) または、Anypoint Platform メニューから API Manager に移動することもできます。 2. 開いたページから、​**\[Add API (API を追加)\]**​ をクリックし、(​**\[Add new API (新しい API を追加)\]**​ が存在する場合はそれをクリックして) API Manager の ​**\[APIs / Add API (API/API を追加)\]**​ ページに移動します。 3. **\[APIs / Add API (API/API を追加)\]**​ から、​**\[Runtime (ランタイム)\]**​ 設定から始まる API 設定の各ページを処理していき API を設定します。 ![Flex Gateway ランタイムと my-gateway が選択されている \[Add API (API を追加)\] ページ](_images/gateway-quickstart-k8-select-gateway-for-api.png) 1. **\[Runtime (ランタイム)\]**​ 設定ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 2. ページの ​**\[Select a gateway (ゲートウェイを選択)\]**​ 領域で各自のゲートウェイを見つけて選択します。 必要に応じて、検索項目を使用して見つけます。 3. **\[Next (次へ)\]**​ をクリックして ​**\[API\]**​ ページを開きます。 4. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[API\]**​ 設定ページで、API 参照名とアセットタイプを指定します。 ![\[API\] ページのスクリーンショット](_images/gateway-quickstart-k8-api-config-api.png) 1. **\[Create new API (新しい API を作成)\]**​ をクリックします。 残りの手順では、Anypoint Exchange の新しい HTTP API を作成してテストするためのステップについて説明します。ただし、このページから Exchange の既存の API を選択することもできます。そのプロセスについては、API Manager ドキュメントの​[「新しい API を追加する」](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex#add-a-new-api)​を参照してください。 2. **my-api**​ などの API 参照名を入力します。 3. アセットタイプに ​**HTTP API**​ を選択します。 4. **\[Next (次へ)\]**​ をクリックして ​**\[Endpoint (エンドポイント)\]**​ 設定ページを開きます。 5. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[Endpoint (エンドポイント)\]**​ ページで、API のエンドポイントをセットアップします。 ![\[Endpoint (エンドポイント)\] ページのスクリーンショット](_images/gateway-quickstart-k8-api-config-endpoint.png) 1. **\[Scheme (スキーム)\]**​ には、デフォルトの ​**\[HTTP\]**​ 設定を使用します。 このガイドでは、シンプルな HTTP API に焦点を絞っています。HTTPS 設定についての詳細は、[接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-tls-config)を参照してください。 2. **\[Implementation URI (実装 URI)\]**​ 項目に次の URI をコピーします。 ```none https://jsonplaceholder.typicode.com/ ``` 3. **\[Port (ポート)\]**​ 項目に​`「80」`​と入力します。 このガイドの例では、API Manager のデフォルトポート ​`8081`​ ではなく HTTP ポート ​`80`​ を使用します。これは、作成された​`サービス`​は受信ポート ​`80`​ をポッドの対象ポート ​`80`​ にマップするためです。 [「Helm chart for Flex Gateway (Flex Gateway の Helm チャート)」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​`service.http.port`​ キーを参照してください。 4. **\[Next (次へ)\]**​ をクリックして ​**\[Review (確認)\]**​ ページを開きます。 6. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[Review (確認)\]**​ ページで、次の作業を行います。 1. API 設定を確認します。 2. 必要に応じて、​**\[Edit (編集)\]**​ を使用して設定を変更します。 3. 設定が正しい場合、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 ゲートウェイ内のポート ​`80`​ のすべての受信 HTTP 要求は、​`jsonplaceholder`​ サービスにプロキシされます。 7. ターミナルウィンドウから、API インスタンスをテストします。 1. 外部 IP アドレスを取得し、それを使用して IP が​**実装 URI**​ にリダイレクトされていることを確認します。 ```kubectl kubectl -n gateway get services ``` コマンドで次の例のような結果が返されます。 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress LoadBalancer 10.100.145.109 <123456.aws.com> 80:30524/TCP,443:31710/TCP 7d7h `EXTERNAL-IP`​ 値 ​`<123456.aws.com>`​ はサンプルで、実際の値ではありません。 2. ``​ を前のステップの​_各自_​の ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功コードを出力します。 200 次のように、よりシンプルな ​`curl`​ コマンドを実行して、サービスの ​`/users`​ エンドポイントから JSON オブジェクトの配列を返すこともできます。 ```curl $ curl http://:80/users ``` ## [](#ステップ-6-基本認証ポリシーを使用して-api-を保護する)ステップ 6: 基本認証ポリシーを使用して API を保護する API Manager を使用して、基本認証ポリシーを API に追加します。 1. **API Manager**​ で、サイドナビゲーションパネルから ​**\[API Administration (API 管理)\]**​ を選択します。 2. [ステップ 5: シンプルな API をパブリッシュして Flex Gateway にデプロイする](#create-api)​で作成した API の名前 (​**my-api**​ など) を見つけてクリックします。 3. 使用する API の ​**\[Policies (ポリシー)\]**​ ページに移動します。 1. サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 2. **\[Policies (ポリシー)\]**​ ページで、​**\[Add policy (ポリシーを追加)\]**​ をクリックします。 ![\[Add policy (ポリシーを追加)\] ボタンのある \[Add policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-add-policy.png) 4. 開いたページの ​**\[Security (セキュリティ)\]**​ で ​**\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ という名前のポリシーを見つけます。 ![\[Add a policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-k8-basic-auth.png) 同様の名前の LDAP のポリシーを選択しないように注意してください。 5. **\[Next (次へ)\]**​ をクリックします。 6. 基本認証ポリシーを設定します。 ![\[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] ページのスクリーンショット](_images/gateway-quickstart-config-basic-auth.png) 1. **\[User Name (ユーザー名)\]**​ に、実際のユーザー名ではなく​`「user」`​と入力します。 項目に値が事前入力されている場合は、その値を保持することも、推奨値に変更することもできます。 2. **\[User Password (ユーザーパスワード)\]**​ に​`「pw」`​と入力します。 項目に値が事前入力されている場合は、その値を保持することも、推奨値に変更することもできます。 3. **\[Apply (適用)\]**​ をクリックします。 7. API インスタンスをテストします。 1. `kubectl`​ を使用して、次のステップで使用できるように外部 IP アドレスを再度取得します。 ```kubectl kubectl -n gateway get services ``` 2. ``​ を前のステップで返された ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを認証パラメーター​_なし_​で実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' ``` URI に認証パラメーターがないため、コマンドで ​`401`​ が返されます。 401 3. ``​ を前のステップで返された ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを認証パラメーター​_付き_​で実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' -u user:pw ``` このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 200 `user`​ パラメーターと ​`password`​ パラメーター (​`user:pw`​) は、ポリシーの適用時に指定した値と一致する必要があります。正しい認証パラメーターを入力していないと、次のエラーが発生します。 401 エラーに対処するには、正しい認証パラメーターを使用してコマンドを実行するか、API ゲートウェイの API のポリシー設定ページに戻ってポリシー設定を編集し、​`curl`​ コマンドを再実行します。 ![\[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] 編集ダイアログのスクリーンショット](_images/gateway-quickstart-k8-config-basic-auth-edit-dialogue.png) ログイン情報を編集するページは、次のようになります。 ![\[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] 設定ページのスクリーンショット](_images/gateway-quickstart-k8-config-basic-auth-edit.png) ## [](#troubleshooting-k8)トラブルシューティング コマンドの実行時にエラーが発生した場合は、トラブルシューティング情報を確認してください。 [Docker コマンドの問題](#docker-troubleshooting)​ | ​[Helm コマンドの問題](#helm-troubleshooting) ### [](#docker-troubleshooting)Docker コマンドの問題 `docker`​ コマンドで返されるエラーのトラブルシューティング - [Docker デーモンエラー](#daemon-bad-response) - [Reg Facade エラー (400 Bad Request (400 不正な要求))](#bad-request) #### [](#daemon-bad-response)Docker デーモンエラー Docker が開始されていない場合、​`docker`​ コマンドで次のようなエラーメッセージが返されます。 - Error response from daemon: Bad response from Docker engine - ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? このエラーが発生した場合、Docker を開始します。 #### [](#bad-request)Reg Facade エラー (400 Bad Request (400 不正な要求)) `docker run`​ を使用してゲートウェイを登録するときに、次のエラーが発生する可能性があります。 \[flexctl\]\[error\] reg facade call returned error response: HTTP/1.1 400 Bad Request このエラーの理由は、エラーメッセージ内で確認できます。一般的な原因は次のとおりです。 - `an active target with the same name already exists in this organization and environment (同じ名前のアクティブな対象がすでにこの組織および環境に存在します)` この問題を回避するには、登録コマンドを実行するときにゲートウェイの​_一意の名前_​を指定します。その名前の前の登録が成功している場合でも、​_同じ名前を再利用することはできません_​。このエラーが発生すると、コマンドによって​_空の_​ ​`registration.yaml`​ が生成されて、再登録できなくなります。​_そのため_​、ゲートウェイをクラスターにデプロイするときにこのファイルを使用しようとすると、エラーが発生します。 - `no valid registration token was found (有効な登録トークンがありませんでした)` この問題を回避するには、Kubernetes の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページを更新して、コマンドの新しいトークンを生成し、登録コマンドを再実行します。 ### [](#helm-troubleshooting)Helm コマンドの問題 Kubernetes および OpenShift クラスターの ​`helm`​ コマンドで返されるエラーのトラブルシューティング - [アップグレードに失敗する: 例外エラー](#troubleshoot-helm-yaml-empty) - [Kubernetes クラスターに到達できない](#troubleshoot-helm-cluster-unreachable) - [アップグレードに失敗する: タイムアウト](#troubleshoot-helm-upgrade-failed) - [CRD をインストールできない](#troubleshoot-helm-openshift-rbac) #### [](#troubleshoot-helm-yaml-empty)アップグレードに失敗する: 例外エラー Flex Gateway のデプロイメント中に ​`registration.yaml`​ ファイルを Helm コマンドに渡すときにこのファイルが無効であると、次のエラーになります。 Error: UPGRADE FAILED: execution error at (flex-gateway/templates/deployment.yaml:4:10): registerSecretName, registration.content or registration.secretName is required! このエラーが発生した場合は、​`registration.yaml`​ ファイルが空でないことを確認してください。ファイルが空である場合、新しい一意の名前でゲートウェイを登録して、新しい ​`registration.yaml`​ を生成し、登録ステップの手順を再実行します。登録コマンドの例については、​[「Flex Gateway を登録する」](#register-flex)​を参照してください。 #### [](#troubleshoot-helm-upgrade-failed)アップグレードに失敗する: タイムアウト 問題によっては、次のタイムアウトエラーが発生する前に、(コマンドの ​`--wait`​ フラグが原因で) 最大 5 分間 Helm アップグレードコマンドがハングする可能性があります。 Error: UPGRADE FAILED: timed out waiting for the condition 通常、このエラーは、クラスター設定に誤りがあるか、クラスター設定ツールでこのプロセスがサポートされていないことを意味します。原因 1 つとして、​`LoadBalancer`​ 種別の ​`Service`​ リソースの生成の失敗が考えられます。さらにトラブルシューティングするには、次のコマンドを実行します。 - ```kubectl kubectl -n gateway describe deployment ``` - ```kubectl kubectl -n gateway describe service ``` #### [](#troubleshoot-helm-cluster-unreachable)Kubernetes クラスターに到達できない `helm`​ を使用して Flex Gateway をデプロイしようとしているときに Kubernetes クラスターが実行されていない場合、次のエラーが発生する可能性があります。 Error: Kubernetes cluster unreachable: the server could not find the requested resource クラスターを実行するサービスを開始します。 次のように、Kubernetes クラスターホストでクラスターが実行されていることを確認します。 ```kubectl kubectl cluster-info ``` - クラスターが実行されている場合、コマンドで次のような結果が返されます。 Kubernetes control plane is running at https://34.30.50.119 GLBCDefaultBackend is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy - クラスターが設定されていない場合、コマンドで次のような結果が返される可能性があります。 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. error: the server doesn't have a resource type "services" 詳細は、​[クラスターの要件](#kubernetes-cluster-reqs)​を参照してください。 #### [](#troubleshoot-helm-openshift-rbac)CRD をインストールできない ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 必要なアクセス権がない場合、次のようなエラーが発生します。 Error: failed to install CRD crds/apiinstance.yaml: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "user1" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope 詳細は、​[クラスターの要件](#kubernetes-cluster-reqs)​を参照してください。 ## [](#check-cluster)クラスターを確認する [ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Flex Gateway を Kubernetes クラスターにデプロイする前に、クラスターの準備ができていることを確認します。​`kubectl`​ を使用して、クラスターをリストして選択 (使用) し、クラスターで使用されるノードのリストを取得します。このセクションのいずれかのステップが失敗すると、デプロイメントプロセスでエラーが発生する可能性があります。 このガイドの手順を実行するときの潜在的なタイムアウトや接続エラーを回避するために、クラスターで​[クラスターの要件](#kubernetes-cluster-reqs)​を満たす必要があります。 1. 次のように ​`kubectl config get-contexts`​ を実行して、クラスターをリストします。 ```kubectl kubectl config get-contexts ``` このコマンドは、複数の Kubernetes クラスターがある場合に特に役立ちます。このコマンドを使用して、正しいクラスターの名前を取得できます。たとえば、さまざまなクラスター (​`my-cluster`​、​`my-aks`​、​`my-gke`​、​`my-eks`​) があるとします。コマンドでクラスターのリストが出力されます。 次の​_例_​は、このコマンドで生成されるクラスターのリストを示しています。 CURRENT NAME CLUSTER AUTHINFO NAMESPACE my-cluster my-cluster my-cluster1 my-aks my-aks my-aks my-gke my-gke my-gke my-eks my-eks my-eks 自分のクラスターがリストされず、マシンでカスタムクラスターコンテキストファイルを使用してクラスターを接続している場合、そのファイルを参照する ​`KUBECONFIG`​ 環境変数にそのパスを追加することが必要になる可能性があります。デフォルトでは、​`kubectl`​ は ​`$HOME/.kube`​ ディレクトリの ​`config`​ という名前のファイルを検索します。そのファイルには、クラスター名、ユーザー、認証機関データなどのプロパティを提供する各​`コンテキスト`​がリストされています。 次の例のように、ターミナルウィンドウから環境変数値を出力する ​`echo $KUBECONFIG`​ を実行して確認できます。 {KUBECONFIG}:/Users/me/.kube/config:/Users/me/.kube/additional-clusters/my-gke:/Users/me/.kube/additional-clusters/my-aks:/Users/me/.kube/additional-clusters/my-eks マシンの他のクラスターコンテキストファイルにパスを追加すると、​`kubectl config get-contexts`​ コマンドでそのクラスターコンテキストをリストして使用できます。 詳細は、​`kubeconfig`​ ファイルについて [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​を参照してください。 2. ゲートウェイをデプロイするクラスターの名前を入力します。 次の例では、クラスターリストの例で特定されたクラスター ​`my-eks`​ を使用します。 kubectl config use-context my-eks このコマンドにより、選択したクラスターコンテキストに切り替わり、次のようなメッセージが出力されます。 Switched to context "my-eks". `error: no context exists with the name`​ で始まるエラーが発生した場合は、​`kubectl config get-contexts`​ でリストされたクラスターの ​`CLUSTER`​ 値ではなく ​`NAME`​ 値を使用していることを確認してください。 3. クラスターに 1 つ以上のノードがあることを確認します。 ```kubectl kubectl get nodes ``` コマンドで次のような出力が返されます。 NAME STATUS ROLES AGE VERSION ip-192-168-70-170 Ready 17h v1.x.x ip-192-168-9-230 Ready 17h v1.x.x 1 つ以上のノードが ​`Ready`​ 状況になっていることを確認します。 4. クラスターの準備ができていない場合、クラスター設定を修正します。 または、Kubernetes クラスターを使用しない Docker 専用ガイドの[Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started)を試して、次のステップをスキップします。 5. Flex Gateway セットアップ手順をまだ開始していない場合は、​[ステップ 1: Flex Gateway イメージをダウンロードする](#download-flex)​に進む前に​[クラスターの要件](#kubernetes-cluster-reqs)​を確認してください。 6. Docker でゲートウェイをダウンロードして登録し、Helm チャートのリポジトリを追加する手順をすべて完了している場合、デプロイメント手順を開始する準備ができているため、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​に進みます。 ## [](#次のステップ)次のステップ Kubernetes クラスターの Flex Gateway をセットアップおよび設定する他の方法や、他のポリシー設定オプションを確認します。 - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.8/flex-review-prerequisites) - [Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) - [Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-configure) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management) - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory) # Kubernetes クラスターでの自己管理 Flex Gateway の使用開始 Kubernetes クラスターまたは Kubernetes クラスターに基づく OpenShift クラスターで Anypoint Flex Gateway の使用を開始します。Anypoint Platform に接続する Flex Gateway デプロイメントをセットアップし、そのデプロイメントを使用してトラフィックを API にルーティングします。このガイドでは、次のタスクの概要について説明します。 - トークンを使用した​[接続モード](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-token#k8-token)​での Flex Gateway のダウンロード、登録、デプロイメント - API Manager でのゲートウェイで実行されるシンプルな API の作成 - API Manager で設定する基本認証ポリシーを使用した API の保護 Flex Gateway デプロイメントプロセスでは、自分で作成する、または Kubernetes プロフェッショナルがプロビジョニングする有効な Kubernetes クラスターが必要です。 Kubernetes クラスターのセットアップには、​_このガイドには記載されていない_​スキルや専門知識のレベルが求められます。Kubernetes のクラスター設定は、サービスプロバイダーやプラットフォームによって大きく異なります。クラスター設定に関する質問がある場合は、Kubernetes サービスプロバイダーのドキュメントを参照するか、 [Kubernetes ドキュメント](https://kubernetes.io/docs/setup/)​を使用してください。 Kubernetes クラスターはないが、クラスターを作成せずに Flex Gateway をすぐに試してみたい場合は、(Docker の) ​[「Flex Gateway の使用開始」](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started)​を参照してください。このガイドでは Docker のみを使用するため、クラスター設定は必要ありません。 ## [](#始める前に)始める前に このガイドの手順を開始する前に、次の前提条件を満たしていることを確認します。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。Anypoint Platform アカウントを持っていない場合は、Anypoint Platform で [トライアル組織を作成](https://anypoint.mulesoft.com/login/signup)​してください。 - Docker のインストール。 ターミナルウィンドウから ​`docker --version`​ を実行して、このツールがインストールされているかどうかを調べます。Docker をインストールする必要がある場合は、 [Docker Desktop](https://www.docker.com/)​ をお試しください。 - Helm バージョン 3.0.0 以降が必要です。 ターミナルウィンドウから ​`helm version`​ を実行して、このツールがインストールされているかどうかを調べ、そのバージョンを確認します。インストールまたはアップグレードするには、 [Helm](https://helm.sh/)​ Web サイトを使用します。 - Kubernetes ​`kubectl`​ コマンドラインツール。 ターミナルウィンドウから ​`kubectl version --output=yaml`​ を実行して、このツールがインストールされているかどうかを調べます。インストールされていない場合、 [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/tools/)​を参照して、使用可能なインストールツールから ​`kubectl`​ を見つけます。 - `curl`​ コマンドラインツール。 ターミナルウィンドウから ​`curl --version`​ を実行して、このツールがインストールされているかどうかを調べます。インストールされていない場合、パッケージマネージャーを使用してマシンにダウンロードします。 ## [](#kubernetes-cluster-reqs)クラスターの要件 Kubernetes クラスターのホストは、一般的なクラウドベースサービス (Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) など) を含む、いずれかの​[サポートされている Kubernetes プロバイダー](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites#software-requirements)​になります。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 このガイドの手順を完了するには、Kubernetes クラスターを作成するか、Flex Gateway デプロイメントの既存の Kubernetes クラスターを使用する必要があります。このガイドでは、Helm を使用して Flex Gateway を Kubernetes クラスターにデプロイし、Anypoint Platform に接続します。 このガイドのデモ目的で使用される小規模な Kubernetes クラスターには次の最小要件が適用されます (​_本番環境の要件には適用されません_​)。 - 1 つ以上のノード。 - `LoadBalancer`​ 種別の ​`Service`​ リソースの作成のサポート。 この要件により、このガイドの使用時にデプロイメントエラーを回避できます。ただし、ゲートウェイをデプロイするときに ​`Service`​ 種別をカスタマイズすることもできます。Flex Gateway では、​`ClusterIP`​、​`NodePort`​、​`LoadBalancer`​ (デフォルト)、​`ExternalName`​ サービスがサポートされています。 [「Helm chart for Flex Gateway (Flex Gateway の Helm チャート)」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​の ​`service.type`​ キーを参照してください。 - デプロイメント手順に必要な計算リソースが次の値 (EKS t3.micro インスタンス種別に相当) を超えることは​_ほとんどありません_​。 - vCPU: 2 vCPU - メモリ: 1 GiB - ネットワーク: 最大 5 ギガビット - 最大 ENI: 2 - 最大 IP: 4 クラスターの​[デプロイメント手順](#deploy-flex)​の準備ができているかどうかを調べるには、デプロイメントを​_開始する前_​に​[クラスターを確認する](#check-cluster)​を確認する必要があります。このチェックでは、一連の ​`kubectl`​ コマンドを実行する必要があります。 ## [](#download-flex)ステップ 1: Flex Gateway イメージをダウンロードする Docker を使用して、Docker Hub リポジトリから Flex Gateway イメージをダウンロードします。 この手順は、​[ステップ 2: Flex Gateway を登録する](#register-flex)​で Flex Gateway を Anypoint Platform に登録するための前提条件です。登録は、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Helm を介してゲートウェイをデプロイメントするときに行う必要があります。 1. ターミナルウィンドウで次のコマンドを実行して、Docker が実行されていることを確認します。 ```docker docker info ``` このコマンドの実行後にエラーが発生した場合は、​[Docker のトラブルシューティング](#docker-troubleshooting)​に関する情報を参照してください。 2. ターミナルウィンドウで次のコマンドを実行します。 ```docker docker pull mulesoft/flex-gateway:latest ``` このコマンドが成功すると、次のようなメッセージがターミナルウィンドウに出力されます。 latest: Pulling from mulesoft/flex-gateway Digest: sha256:e55555abcdefg1234567zxynwo33333fadjf Status: Image is up to date for mulesoft/flex-gateway:latest docker.io/mulesoft/flex-gateway:latest このコマンドの実行時に権限の問題が発生した場合は、​`sudo`​ を使用してください。 ## [](#register-flex)ステップ 2: Flex Gateway を登録する Anypoint Runtime Manager で生成された一時トークンを使用して、ターミナルウィンドウから Flex Gateway イメージを登録します。この手順では、名前付きゲートウェイの登録プロパティが含まれるローカル ​`registration.yaml`​ ファイルが生成されます。これらのプロパティは、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Helm チャートに組み込まれます。 1. ターミナルウィンドウから、Flex Gateway 登録ファイル (​`registration.yaml`​) のディレクトリを準備します。 1. ディレクトリを作成します。 ```mkdir mkdir flex-registration ``` 2. 新しいディレクトリに移動します。 ```cd cd flex-registration ``` 2. [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインし、​**\[Runtime Manager\]**​ を選択します。 3. Runtime Manager から、Flex Gateway を登録する手順を見つけます。 1. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 2. **\[Self-managed Flex Gateways (自己管理 Flex Gateway)\]**​ をクリックします。 3. **\[Add Managed Flex-Gateway (管理 Flex Gateway を追加)\]**​ をクリックします。 4. 次のいずれかの環境を選択します。 - **Kubernetes**​ - **OpenShift** 5. 開いたページで、​**\[Register your gateway (ゲートウェイを登録)\]**​ セクションでコマンドを見つけます。 Kubernetes の例: ![\[Add a Flex Gateway (Flex Gateway の追加)\] ページから登録コードブロックを追加する](_images/gateway-quickstart-k8-add-gateway-rtm.png) 強調表示されたコマンドブロックには、一意の組織 ID と一時トークンが含まれています。 4. ターミナルウィンドウで、Runtime Manager から ​`./flex-registration`​ ディレクトリにコマンドブロックをコピーします。 Runtime Manager によって必要な組織およびトークン値が提供されます。 5. コマンドを実行する前に、コマンドブロックの最後の ​``​ をゲートウェイの​_一意_​の名前 (​`my-gateway`​ など) に置き換えます。 ゲートウェイに指定する名前は、Anypoint Platform 組織および環境のスコープ内で一意である必要があります。この登録ステップは一度完了すれば済みます。名前付きゲートウェイおよび組織ごとに​_複数回行う必要はありません_​。 6. ターミナルウィンドウから、編集したコマンドを実行します。 コマンドが成功すると、​`./flex-registration`​ ディレクトリに ​`registration.yaml`​ が生成され、次のメッセージがターミナルウィンドウに表示されます。 Starting registration, please be patient. Registration completed, the configuration files were written in directory "/registration". For security, modify the file permissions to restrict production scenario access to the user running flex. ターミナルウィンドウのメッセージの ​`/registration`​ は、Docker コンテナ内のディレクトリを表しています。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。コマンドを実行する前にトークンの期限が切れた場合、​`400 Bad Request (400 不正な要求)`​ エラーが発生します。その場合、\[Runtime Manager\] ページを更新して、新しいトークンを生成し、ページに表示される変更済みのコマンドを実行する必要があります。 ## [](#create-repo)ステップ 3: Helm チャートのリポジトリを追加する Flex Gateway チャートリポジトリを追加します。Flex Gateway の Helm チャートのプロパティについての詳細は、 [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ を参照してください。 1. Helm チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 ## [](#deploy-flex)ステップ 4: Flex Gateway をデプロイして接続する Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 始める前に: [クラスターを確認する](#check-cluster)​の手順に従って、Kubernetes クラスターが使用可能であることを確認します。まだ​[クラスターの要件](#kubernetes-cluster-reqs)​を確認していない場合は確認します。これらの前提条件は、デプロイメントエラーを回避するのに役立ちます。 Kubernetes クラスターの準備ができていることを確認したら、ゲートウェイをデプロイして接続します。 1. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ リリースが作成されます (これらが存在しない場合)。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。 このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 `UPGRADE FAILED`​ 応答を受信した場合は、この問題に関する​[トラブルシューティング](#troubleshoot-helm-upgrade-failed)​情報を参照してください。 2. ゲートウェイを実行するポッドの状況を確認する場合は、次の ​`kubectl`​ コマンドを実行します。 ```kubectl kubectl get pods -n gateway ``` 出力に、ポッドが ​`gateway`​ 名前空間で正常に実行されているかどうかが示されます。 NAME READY STATUS RESTARTS AGE ingress-57bc75cb46-dmkdq 1/1 Running 0 35s 3. Runtime Manager に戻ります。 1. **\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページのサイドナビゲーションパネルから ​**\[← Flex Gateway\]**​ を選択します。 ![目的のオペレーティングシステムまたは環境を選択](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-return-to-gateway-list.png) 2. **\[Flex Gateways\]**​ ページの登録済みゲートウェイに移動します。 ![名前、ID、状況、最終更新タイムスタンプなどの Flex Gateway の詳細のテーブル](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-my-gateway-rtm.png) ページの検索項目を使用して、ゲートウェイのリストを絞り込むことができます。 3. ゲートウェイの状況が ​**\[Running (実行中)\]**​ であることを確認します。 状況が ​**\[Not Running (非実行中)\]**​ の場合、クラスター設定が正しくないか、ネットワークの問題が発生している可能性があります。詳細は、​[トラブルシューティング](#troubleshooting-k8)​を参照してください。 ## [](#create-api)ステップ 5: シンプルな API をパブリッシュして Flex Gateway にデプロイする Anypoint API Manager でシンプルな API を作成してゲートウェイにデプロイします。 1. Runtime Manager で、ゲートウェイの ​**\[View APIs (API を表示)\]**​ メニューオプションをクリックし、その ​**\[View APIs (API を表示)\]**​ ページに移動します。 ![Flex Gateway の \[View APIs (API を表示)\] メニュー項目](_images/gateway-quickstart-k8-view-apis.png) または、Anypoint Platform メニューから API Manager に移動することもできます。 2. 開いたページから、​**\[Add API (API を追加)\]**​ をクリックし、(​**\[Add new API (新しい API を追加)\]**​ が存在する場合はそれをクリックして) API Manager の ​**\[APIs / Add API (API/API を追加)\]**​ ページに移動します。 3. **\[APIs / Add API (API/API を追加)\]**​ から、​**\[Runtime (ランタイム)\]**​ 設定から始まる API 設定の各ページを処理していき API を設定します。 ![Flex Gateway ランタイムと my-gateway が選択されている \[Add API (API を追加)\] ページ](_images/gateway-quickstart-k8-select-gateway-for-api.png) 1. **\[Runtime (ランタイム)\]**​ 設定ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 2. ページの ​**\[Select a gateway (ゲートウェイを選択)\]**​ 領域で各自のゲートウェイを見つけて選択します。 必要に応じて、検索項目を使用して見つけます。 3. **\[Next (次へ)\]**​ をクリックして ​**\[API\]**​ ページを開きます。 4. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[API\]**​ 設定ページで、API 参照名とアセットタイプを指定します。 ![新しい API を選択または作成するためのフォーム](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-api-config-api.png) 1. **\[Create new API (新しい API を作成)\]**​ をクリックします。 残りの手順では、Anypoint Exchange の新しい HTTP API を作成してテストするためのステップについて説明します。ただし、このページから Exchange の既存の API を選択することもできます。そのプロセスについては、API Manager ドキュメントの​[「新しい API を追加する」](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex#add-a-new-api)​を参照してください。 2. **my-api**​ などの API 参照名を入力します。 3. アセットタイプに ​**HTTP API**​ を選択します。 4. **\[Next (次へ)\]**​ をクリックして ​**\[Endpoint (エンドポイント)\]**​ 設定ページを開きます。 5. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[Endpoint (エンドポイント)\]**​ ページで、API のエンドポイントをセットアップします。 ![エンドポイント設定を定義するためのフォーム](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-api-config-endpoint.png) 1. **\[Scheme (スキーム)\]**​ には、デフォルトの ​**\[HTTP\]**​ 設定を使用します。 このガイドでは、シンプルな HTTP API に焦点を絞っています。HTTPS 設定についての詳細は、[接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tls-config)を参照してください。 2. **\[Implementation URI (実装 URI)\]**​ 項目に次の URI をコピーします。 ```none https://jsonplaceholder.typicode.com/ ``` 3. **\[Port (ポート)\]**​ 項目に​`「80」`​と入力します。 このガイドの例では、API Manager のデフォルトポート ​`8081`​ ではなく HTTP ポート ​`80`​ を使用します。これは、作成された​`サービス`​は受信ポート ​`80`​ をポッドの対象ポート ​`80`​ にマップするためです。 [「Helm chart for Flex Gateway (Flex Gateway の Helm チャート)」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​`service.http.port`​ キーを参照してください。 4. **\[Next (次へ)\]**​ をクリックして ​**\[Review (確認)\]**​ ページを開きます。 6. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[Review (確認)\]**​ ページで、次の作業を行います。 1. API 設定を確認します。 2. 必要に応じて、​**\[Edit (編集)\]**​ を使用して設定を変更します。 3. 設定が正しい場合、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 ゲートウェイ内のポート ​`80`​ のすべての受信 HTTP 要求は、​`jsonplaceholder`​ サービスにプロキシされます。 7. ターミナルウィンドウから、API インスタンスをテストします。 1. 外部 IP アドレスを取得し、それを使用して IP が​**実装 URI**​ にリダイレクトされていることを確認します。 ```kubectl kubectl -n gateway get services ``` コマンドで次の例のような結果が返されます。 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress LoadBalancer 10.100.145.109 <123456.aws.com> 80:30524/TCP,443:31710/TCP 7d7h `EXTERNAL-IP`​ 値 ​`<123456.aws.com>`​ はサンプルで、実際の値ではありません。 2. ``​ を前のステップの​_各自_​の ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功コードを出力します。 200 次のように、よりシンプルな ​`curl`​ コマンドを実行して、サービスの ​`/users`​ エンドポイントから JSON オブジェクトの配列を返すこともできます。 ```curl $ curl http://:80/users ``` ## [](#ステップ-6-基本認証ポリシーを使用して-api-を保護する)ステップ 6: 基本認証ポリシーを使用して API を保護する API Manager を使用して、基本認証ポリシーを API に追加します。 1. **API Manager**​ で、サイドナビゲーションパネルから ​**\[API Administration (API 管理)\]**​ を選択します。 2. [ステップ 5: シンプルな API をパブリッシュして Flex Gateway にデプロイする](#create-api)​で作成した API の名前 (​**my-api**​ など) を見つけてクリックします。 3. 使用する API の ​**\[Policies (ポリシー)\]**​ ページに移動します。 1. サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 2. **\[Policies (ポリシー)\]**​ ページで、​**\[Add policy (ポリシーを追加)\]**​ をクリックします。 ![\[Add policy (ポリシーを追加)\] ボタンのある \[Add policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-add-policy.png) 4. 開いたページの ​**\[Security (セキュリティ)\]**​ で ​**\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ という名前のポリシーを見つけます。 ![幅広いセキュリティポリシーの中から選択できるフォーム](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-basic-auth.png) 同様の名前の LDAP のポリシーを選択しないように注意してください。 5. **\[Next (次へ)\]**​ をクリックします。 6. 基本認証ポリシーを設定します。 ![\[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] ページのスクリーンショット](_images/gateway-quickstart-config-basic-auth.png) 1. **\[User Name (ユーザー名)\]**​ に、実際のユーザー名ではなく​`「user」`​と入力します。 項目に値が事前入力されている場合は、その値を保持することも、推奨値に変更することもできます。 2. **\[User Password (ユーザーパスワード)\]**​ に​`「pw」`​と入力します。 項目に値が事前入力されている場合は、その値を保持することも、推奨値に変更することもできます。 3. **\[Apply (適用)\]**​ をクリックします。 7. API インスタンスをテストします。 1. `kubectl`​ を使用して、次のステップで使用できるように外部 IP アドレスを再度取得します。 ```kubectl kubectl -n gateway get services ``` 2. ``​ を前のステップで返された ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを認証パラメーター​_なし_​で実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' ``` URI に認証パラメーターがないため、コマンドで ​`401`​ が返されます。 401 3. ``​ を前のステップで返された ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを認証パラメーター​_付き_​で実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' -u user:pw ``` このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 200 `user`​ パラメーターと ​`password`​ パラメーター (​`user:pw`​) は、ポリシーの適用時に指定した値と一致する必要があります。正しい認証パラメーターを入力していないと、次のエラーが発生します。 401 エラーに対処するには、正しい認証パラメーターを使用してコマンドを実行するか、API ゲートウェイの API のポリシー設定ページに戻ってポリシー設定を編集し、​`curl`​ コマンドを再実行します。 ![自動化された API レベルのポリシー設定](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-config-basic-auth-edit-dialogue.png) ログイン情報を編集するページは、次のようになります。 ![ユーザー名とパスワードを入力する項目が含まれるフォーム](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-k8-config-basic-auth-edit.png) ## [](#troubleshooting-k8)トラブルシューティング コマンドの実行時にエラーが発生した場合は、トラブルシューティング情報を確認してください。 [Docker コマンドの問題](#docker-troubleshooting)​ | ​[Helm コマンドの問題](#helm-troubleshooting) ### [](#docker-troubleshooting)Docker コマンドの問題 `docker`​ コマンドで返されるエラーのトラブルシューティング - [Docker デーモンエラー](#daemon-bad-response) - [Reg Facade エラー (400 Bad Request (400 不正な要求))](#bad-request) #### [](#daemon-bad-response)Docker デーモンエラー Docker が開始されていない場合、​`docker`​ コマンドで次のようなエラーメッセージが返されます。 - Error response from daemon: Bad response from Docker engine - ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? このエラーが発生した場合、Docker を開始します。 #### [](#bad-request)Reg Facade エラー (400 Bad Request (400 不正な要求)) `docker run`​ を使用してゲートウェイを登録するときに、次のエラーが発生する可能性があります。 \[flexctl\]\[error\] reg facade call returned error response: HTTP/1.1 400 Bad Request このエラーの理由は、エラーメッセージ内で確認できます。一般的な原因は次のとおりです。 - `an active target with the same name already exists in this organization and environment (同じ名前のアクティブな対象がすでにこの組織および環境に存在します)` この問題を回避するには、登録コマンドを実行するときにゲートウェイの​_一意の名前_​を指定します。その名前の前の登録が成功している場合でも、​_同じ名前を再利用することはできません_​。このエラーが発生すると、コマンドによって​_空の_​ ​`registration.yaml`​ が生成されて、再登録できなくなります。​_そのため_​、ゲートウェイをクラスターにデプロイするときにこのファイルを使用しようとすると、エラーが発生します。 - `no valid registration token was found (有効な登録トークンがありませんでした)` この問題を回避するには、Kubernetes の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページを更新して、コマンドの新しいトークンを生成し、登録コマンドを再実行します。 ### [](#helm-troubleshooting)Helm コマンドの問題 Kubernetes および OpenShift クラスターの ​`helm`​ コマンドで返されるエラーのトラブルシューティング - [アップグレードに失敗する: 例外エラー](#troubleshoot-helm-yaml-empty) - [Kubernetes クラスターに到達できない](#troubleshoot-helm-cluster-unreachable) - [アップグレードに失敗する: タイムアウト](#troubleshoot-helm-upgrade-failed) - [CRD をインストールできない](#troubleshoot-helm-openshift-rbac) #### [](#troubleshoot-helm-yaml-empty)アップグレードに失敗する: 例外エラー Flex Gateway のデプロイメント中に ​`registration.yaml`​ ファイルを Helm コマンドに渡すときにこのファイルが無効であると、次のエラーになります。 Error: UPGRADE FAILED: execution error at (flex-gateway/templates/deployment.yaml:4:10): registerSecretName, registration.content or registration.secretName is required! このエラーが発生した場合は、​`registration.yaml`​ ファイルが空でないことを確認してください。ファイルが空である場合、新しい一意の名前でゲートウェイを登録して、新しい ​`registration.yaml`​ を生成し、登録ステップの手順を再実行します。登録コマンドの例については、​[「Flex Gateway を登録する」](#register-flex)​を参照してください。 #### [](#troubleshoot-helm-upgrade-failed)アップグレードに失敗する: タイムアウト 問題によっては、次のタイムアウトエラーが発生する前に、(コマンドの ​`--wait`​ フラグが原因で) 最大 5 分間 Helm アップグレードコマンドがハングする可能性があります。 Error: UPGRADE FAILED: timed out waiting for the condition 通常、このエラーは、クラスター設定に誤りがあるか、クラスター設定ツールでこのプロセスがサポートされていないことを意味します。原因 1 つとして、​`LoadBalancer`​ 種別の ​`Service`​ リソースの生成の失敗が考えられます。さらにトラブルシューティングするには、次のコマンドを実行します。 - ```kubectl kubectl -n gateway describe deployment ``` - ```kubectl kubectl -n gateway describe service ``` #### [](#troubleshoot-helm-cluster-unreachable)Kubernetes クラスターに到達できない `helm`​ を使用して Flex Gateway をデプロイしようとしているときに Kubernetes クラスターが実行されていない場合、次のエラーが発生する可能性があります。 Error: Kubernetes cluster unreachable: the server could not find the requested resource クラスターを実行するサービスを開始します。 次のように、Kubernetes クラスターホストでクラスターが実行されていることを確認します。 ```kubectl kubectl cluster-info ``` - クラスターが実行されている場合、コマンドで次のような結果が返されます。 Kubernetes control plane is running at https://34.30.50.119 GLBCDefaultBackend is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy - クラスターが設定されていない場合、コマンドで次のような結果が返される可能性があります。 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. error: the server doesn't have a resource type "services" 詳細は、​[クラスターの要件](#kubernetes-cluster-reqs)​を参照してください。 #### [](#troubleshoot-helm-openshift-rbac)CRD をインストールできない ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 必要なアクセス権がない場合、次のようなエラーが発生します。 Error: failed to install CRD crds/apiinstance.yaml: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "user1" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope 詳細は、​[クラスターの要件](#kubernetes-cluster-reqs)​を参照してください。 ## [](#check-cluster)クラスターを確認する [ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Flex Gateway を Kubernetes クラスターにデプロイする前に、クラスターの準備ができていることを確認します。​`kubectl`​ を使用して、クラスターをリストして選択 (使用) し、クラスターで使用されるノードのリストを取得します。このセクションのいずれかのステップが失敗すると、デプロイメントプロセスでエラーが発生する可能性があります。 このガイドの手順を実行するときの潜在的なタイムアウトや接続エラーを回避するために、クラスターで​[クラスターの要件](#kubernetes-cluster-reqs)​を満たす必要があります。 1. 次のように ​`kubectl config get-contexts`​ を実行して、クラスターをリストします。 ```kubectl kubectl config get-contexts ``` このコマンドは、複数の Kubernetes クラスターがある場合に特に役立ちます。このコマンドを使用して、正しいクラスターの名前を取得できます。たとえば、さまざまなクラスター (​`my-cluster`​、​`my-aks`​、​`my-gke`​、​`my-eks`​) があるとします。コマンドでクラスターのリストが出力されます。 次の​_例_​は、このコマンドで生成されるクラスターのリストを示しています。 CURRENT NAME CLUSTER AUTHINFO NAMESPACE my-cluster my-cluster my-cluster1 my-aks my-aks my-aks my-gke my-gke my-gke my-eks my-eks my-eks 自分のクラスターがリストされず、マシンでカスタムクラスターコンテキストファイルを使用してクラスターを接続している場合、そのファイルを参照する ​`KUBECONFIG`​ 環境変数にそのパスを追加することが必要になる可能性があります。デフォルトでは、​`kubectl`​ は ​`$HOME/.kube`​ ディレクトリの ​`config`​ という名前のファイルを検索します。そのファイルには、クラスター名、ユーザー、認証機関データなどのプロパティを提供する各​`コンテキスト`​がリストされています。 次の例のように、ターミナルウィンドウから環境変数値を出力する ​`echo $KUBECONFIG`​ を実行して確認できます。 {KUBECONFIG}:/Users/me/.kube/config:/Users/me/.kube/additional-clusters/my-gke:/Users/me/.kube/additional-clusters/my-aks:/Users/me/.kube/additional-clusters/my-eks マシンの他のクラスターコンテキストファイルにパスを追加すると、​`kubectl config get-contexts`​ コマンドでそのクラスターコンテキストをリストして使用できます。 詳細は、​`kubeconfig`​ ファイルについて [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​を参照してください。 2. ゲートウェイをデプロイするクラスターの名前を入力します。 次の例では、クラスターリストの例で特定されたクラスター ​`my-eks`​ を使用します。 kubectl config use-context my-eks このコマンドにより、選択したクラスターコンテキストに切り替わり、次のようなメッセージが出力されます。 Switched to context "my-eks". `error: no context exists with the name`​ で始まるエラーが発生した場合は、​`kubectl config get-contexts`​ でリストされたクラスターの ​`CLUSTER`​ 値ではなく ​`NAME`​ 値を使用していることを確認してください。 3. クラスターに 1 つ以上のノードがあることを確認します。 ```kubectl kubectl get nodes ``` コマンドで次のような出力が返されます。 NAME STATUS ROLES AGE VERSION ip-192-168-70-170 Ready 17h v1.x.x ip-192-168-9-230 Ready 17h v1.x.x 1 つ以上のノードが ​`Ready`​ 状況になっていることを確認します。 4. クラスターの準備ができていない場合、クラスター設定を修正します。 または、Kubernetes クラスターを使用しない Docker 専用ガイドの[自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started)を試して、次のステップをスキップします。 5. Flex Gateway セットアップ手順をまだ開始していない場合は、​[ステップ 1: Flex Gateway イメージをダウンロードする](#download-flex)​に進む前に​[クラスターの要件](#kubernetes-cluster-reqs)​を確認してください。 6. Docker でゲートウェイをダウンロードして登録し、Helm チャートのリポジトリを追加する手順をすべて完了している場合、デプロイメント手順を開始する準備ができているため、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​に進みます。 ## [](#次のステップ)次のステップ Kubernetes クラスターの Flex Gateway をセットアップおよび設定する他の方法や、他のポリシー設定オプションを確認します。 - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) - [Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-configure) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management) - [インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) # Kubernetes クラスターでの自己管理 Flex Gateway の使用開始 Kubernetes クラスターまたは Kubernetes クラスターに基づく OpenShift クラスターで Anypoint Flex Gateway の使用を開始します。Anypoint Platform に接続する Flex Gateway デプロイメントをセットアップし、そのデプロイメントを使用してトラフィックを API にルーティングします。このガイドでは、次のタスクの概要について説明します。 - トークンを使用した​[接続モード](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-token#k8-token)​での Flex Gateway のダウンロード、登録、デプロイメント - API Manager でのゲートウェイで実行されるシンプルな API の作成 - API Manager で設定する基本認証ポリシーを使用した API の保護 Flex Gateway デプロイメントプロセスでは、自分で作成する、または Kubernetes プロフェッショナルがプロビジョニングする有効な Kubernetes クラスターが必要です。 Kubernetes クラスターのセットアップには、​_このガイドには記載されていない_​スキルや専門知識のレベルが求められます。Kubernetes のクラスター設定は、サービスプロバイダーやプラットフォームによって大きく異なります。クラスター設定に関する質問がある場合は、Kubernetes サービスプロバイダーのドキュメントを参照するか、 [Kubernetes ドキュメント](https://kubernetes.io/docs/setup/)​を使用してください。 Kubernetes クラスターはないが、クラスターを作成せずに Flex Gateway をすぐに試してみたい場合は、(Docker の) ​[「Flex Gateway の使用開始」](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started)​を参照してください。このガイドでは Docker のみを使用するため、クラスター設定は必要ありません。 ## [](#始める前に)始める前に このガイドの手順を開始する前に、次の前提条件を満たしていることを確認します。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。Anypoint Platform アカウントを持っていない場合は、Anypoint Platform で [トライアル組織を作成](https://anypoint.mulesoft.com/login/signup)​してください。 - Docker のインストール。 ターミナルウィンドウから ​`docker --version`​ を実行して、このツールがインストールされているかどうかを調べます。Docker をインストールする必要がある場合は、 [Docker Desktop](https://www.docker.com/)​ をお試しください。 - Helm バージョン 3.0.0 以降が必要です。 ターミナルウィンドウから ​`helm version`​ を実行して、このツールがインストールされているかどうかを調べ、そのバージョンを確認します。インストールまたはアップグレードするには、 [Helm](https://helm.sh/)​ Web サイトを使用します。 - Kubernetes ​`kubectl`​ コマンドラインツール。 ターミナルウィンドウから ​`kubectl version --output=yaml`​ を実行して、このツールがインストールされているかどうかを調べます。インストールされていない場合、 [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/tools/)​を参照して、使用可能なインストールツールから ​`kubectl`​ を見つけます。 - `curl`​ コマンドラインツール。 ターミナルウィンドウから ​`curl --version`​ を実行して、このツールがインストールされているかどうかを調べます。インストールされていない場合、パッケージマネージャーを使用してマシンにダウンロードします。 ## [](#kubernetes-cluster-reqs)クラスターの要件 Kubernetes クラスターのホストは、一般的なクラウドベースサービス (Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) など) を含む、いずれかの​[サポートされている Kubernetes プロバイダー](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites#software-requirements)​になります。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 このガイドの手順を完了するには、Kubernetes クラスターを作成するか、Flex Gateway デプロイメントの既存の Kubernetes クラスターを使用する必要があります。このガイドでは、Helm を使用して Flex Gateway を Kubernetes クラスターにデプロイし、Anypoint Platform に接続します。 このガイドのデモ目的で使用される小規模な Kubernetes クラスターには次の最小要件が適用されます (​_本番環境の要件には適用されません_​)。 - 1 つ以上のノード。 - `LoadBalancer`​ 種別の ​`Service`​ リソースの作成のサポート。 この要件により、このガイドの使用時にデプロイメントエラーを回避できます。ただし、ゲートウェイをデプロイするときに ​`Service`​ 種別をカスタマイズすることもできます。Flex Gateway では、​`ClusterIP`​、​`NodePort`​、​`LoadBalancer`​ (デフォルト)、​`ExternalName`​ サービスがサポートされています。 [「Helm chart for Flex Gateway (Flex Gateway の Helm チャート)」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​の ​`service.type`​ キーを参照してください。 - デプロイメント手順に必要な計算リソースが次の値 (EKS t3.micro インスタンス種別に相当) を超えることは​_ほとんどありません_​。 - vCPU: 2 vCPU - メモリ: 1 GiB - ネットワーク: 最大 5 ギガビット - 最大 ENI: 2 - 最大 IP: 4 クラスターの​[デプロイメント手順](#deploy-flex)​の準備ができているかどうかを調べるには、デプロイメントを​_開始する前_​に​[クラスターを確認する](#check-cluster)​を確認する必要があります。このチェックでは、一連の ​`kubectl`​ コマンドを実行する必要があります。 ## [](#download-flex)ステップ 1: Flex Gateway イメージをダウンロードする Docker を使用して、Docker Hub リポジトリから Flex Gateway イメージをダウンロードします。 この手順は、​[ステップ 2: Flex Gateway を登録する](#register-flex)​で Flex Gateway を Anypoint Platform に登録するための前提条件です。登録は、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Helm を介してゲートウェイをデプロイメントするときに行う必要があります。 1. ターミナルウィンドウで次のコマンドを実行して、Docker が実行されていることを確認します。 ```docker docker info ``` このコマンドの実行後にエラーが発生した場合は、​[Docker のトラブルシューティング](#docker-troubleshooting)​に関する情報を参照してください。 2. ターミナルウィンドウで次のコマンドを実行します。 ```docker docker pull mulesoft/flex-gateway:latest ``` このコマンドが成功すると、次のようなメッセージがターミナルウィンドウに出力されます。 latest: Pulling from mulesoft/flex-gateway Digest: sha256:e55555abcdefg1234567zxynwo33333fadjf Status: Image is up to date for mulesoft/flex-gateway:latest docker.io/mulesoft/flex-gateway:latest このコマンドの実行時に権限の問題が発生した場合は、​`sudo`​ を使用してください。 ## [](#register-flex)ステップ 2: Flex Gateway を登録する Anypoint Runtime Manager で生成された一時トークンを使用して、ターミナルウィンドウから Flex Gateway イメージを登録します。この手順では、名前付きゲートウェイの登録プロパティが含まれるローカル ​`registration.yaml`​ ファイルが生成されます。これらのプロパティは、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Helm チャートに組み込まれます。 1. ターミナルウィンドウから、Flex Gateway 登録ファイル (​`registration.yaml`​) のディレクトリを準備します。 1. ディレクトリを作成します。 ```mkdir mkdir flex-registration ``` 2. 新しいディレクトリに移動します。 ```cd cd flex-registration ``` 2. [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインし、​**\[Runtime Manager\]**​ を選択します。 3. Runtime Manager から、Flex Gateway を登録する手順を見つけます。 1. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 2. **\[Self-managed Flex Gateways (自己管理 Flex Gateway)\]**​ をクリックします。 3. **\[Add Managed Flex-Gateway (管理 Flex Gateway を追加)\]**​ をクリックします。 4. 次のいずれかの環境を選択します。 - **Kubernetes**​ - **OpenShift** 5. 開いたページで、​**\[Register your gateway (ゲートウェイを登録)\]**​ セクションでコマンドを見つけます。 Kubernetes の例: ![\[Add a Flex Gateway (Flex Gateway の追加)\] ページから登録コードブロックを追加する](_images/gateway-quickstart-k8-add-gateway-rtm.png) 強調表示されたコマンドブロックには、一意の組織 ID と一時トークンが含まれています。 4. ターミナルウィンドウで、Runtime Manager から ​`./flex-registration`​ ディレクトリにコマンドブロックをコピーします。 Runtime Manager によって必要な組織およびトークン値が提供されます。 5. コマンドを実行する前に、コマンドブロックの最後の ​``​ をゲートウェイの​_一意_​の名前 (​`my-gateway`​ など) に置き換えます。 ゲートウェイに指定する名前は、Anypoint Platform 組織および環境のスコープ内で一意である必要があります。この登録ステップは一度完了すれば済みます。名前付きゲートウェイおよび組織ごとに​_複数回行う必要はありません_​。 6. ターミナルウィンドウから、編集したコマンドを実行します。 コマンドが成功すると、​`./flex-registration`​ ディレクトリに ​`registration.yaml`​ が生成され、次のメッセージがターミナルウィンドウに表示されます。 Starting registration, please be patient. Registration completed, the configuration files were written in directory "/registration". For security, modify the file permissions to restrict production scenario access to the user running flex. ターミナルウィンドウのメッセージの ​`/registration`​ は、Docker コンテナ内のディレクトリを表しています。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。コマンドを実行する前にトークンの期限が切れた場合、​`400 Bad Request (400 不正な要求)`​ エラーが発生します。その場合、\[Runtime Manager\] ページを更新して、新しいトークンを生成し、ページに表示される変更済みのコマンドを実行する必要があります。 ## [](#create-repo)ステップ 3: Helm チャートのリポジトリを追加する Flex Gateway チャートリポジトリを追加します。Flex Gateway の Helm チャートのプロパティについての詳細は、 [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ を参照してください。 1. Helm チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 ## [](#deploy-flex)ステップ 4: Flex Gateway をデプロイして接続する Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 始める前に: [クラスターを確認する](#check-cluster)​の手順に従って、Kubernetes クラスターが使用可能であることを確認します。まだ​[クラスターの要件](#kubernetes-cluster-reqs)​を確認していない場合は確認します。これらの前提条件は、デプロイメントエラーを回避するのに役立ちます。 Kubernetes クラスターの準備ができていることを確認したら、ゲートウェイをデプロイして接続します。 1. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ リリースが作成されます (これらが存在しない場合)。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。 このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 `UPGRADE FAILED`​ 応答を受信した場合は、この問題に関する​[トラブルシューティング](#troubleshoot-helm-upgrade-failed)​情報を参照してください。 2. ゲートウェイを実行するポッドの状況を確認する場合は、次の ​`kubectl`​ コマンドを実行します。 ```kubectl kubectl get pods -n gateway ``` 出力に、ポッドが ​`gateway`​ 名前空間で正常に実行されているかどうかが示されます。 NAME READY STATUS RESTARTS AGE ingress-57bc75cb46-dmkdq 1/1 Running 0 35s 3. Runtime Manager に戻ります。 1. **\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページのサイドナビゲーションパネルから ​**\[← Flex Gateway\]**​ を選択します。 ![目的のオペレーティングシステムまたは環境を選択](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-return-to-gateway-list.png) 2. **\[Flex Gateways\]**​ ページの登録済みゲートウェイに移動します。 ![名前、ID、状況、最終更新タイムスタンプなどの Flex Gateway の詳細のテーブル](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-my-gateway-rtm.png) ページの検索項目を使用して、ゲートウェイのリストを絞り込むことができます。 3. ゲートウェイの状況が ​**\[Running (実行中)\]**​ であることを確認します。 状況が ​**\[Not Running (非実行中)\]**​ の場合、クラスター設定が正しくないか、ネットワークの問題が発生している可能性があります。詳細は、​[トラブルシューティング](#troubleshooting-k8)​を参照してください。 ## [](#create-api)ステップ 5: シンプルな API をパブリッシュして Flex Gateway にデプロイする Anypoint API Manager でシンプルな API を作成してゲートウェイにデプロイします。 1. Runtime Manager で、ゲートウェイの ​**\[View APIs (API を表示)\]**​ メニューオプションをクリックし、その ​**\[View APIs (API を表示)\]**​ ページに移動します。 ![Flex Gateway の \[View APIs (API を表示)\] メニュー項目](_images/gateway-quickstart-k8-view-apis.png) または、Anypoint Platform メニューから API Manager に移動することもできます。 2. 開いたページから、​**\[Add API (API を追加)\]**​ をクリックし、(​**\[Add new API (新しい API を追加)\]**​ が存在する場合はそれをクリックして) API Manager の ​**\[APIs / Add API (API/API を追加)\]**​ ページに移動します。 3. **\[APIs / Add API (API/API を追加)\]**​ から、​**\[Runtime (ランタイム)\]**​ 設定から始まる API 設定の各ページを処理していき API を設定します。 ![Flex Gateway ランタイムと my-gateway が選択されている \[Add API (API を追加)\] ページ](_images/gateway-quickstart-k8-select-gateway-for-api.png) 1. **\[Runtime (ランタイム)\]**​ 設定ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 2. ページの ​**\[Select a gateway (ゲートウェイを選択)\]**​ 領域で各自のゲートウェイを見つけて選択します。 必要に応じて、検索項目を使用して見つけます。 3. **\[Next (次へ)\]**​ をクリックして ​**\[API\]**​ ページを開きます。 4. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[API\]**​ 設定ページで、API 参照名とアセットタイプを指定します。 ![新しい API を選択または作成するためのフォーム](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-api-config-api.png) 1. **\[Create new API (新しい API を作成)\]**​ をクリックします。 残りの手順では、Anypoint Exchange の新しい HTTP API を作成してテストするためのステップについて説明します。ただし、このページから Exchange の既存の API を選択することもできます。そのプロセスについては、API Manager ドキュメントの​[「新しい API を追加する」](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex#add-a-new-api)​を参照してください。 2. **my-api**​ などの API 参照名を入力します。 3. アセットタイプに ​**HTTP API**​ を選択します。 4. **\[Next (次へ)\]**​ をクリックして ​**\[Endpoint (エンドポイント)\]**​ 設定ページを開きます。 5. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[Endpoint (エンドポイント)\]**​ ページで、API のエンドポイントをセットアップします。 ![エンドポイント設定を定義するためのフォーム](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-api-config-endpoint.png) 1. **\[Scheme (スキーム)\]**​ には、デフォルトの ​**\[HTTP\]**​ 設定を使用します。 このガイドでは、シンプルな HTTP API に焦点を絞っています。HTTPS 設定についての詳細は、[接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-tls-config)を参照してください。 2. **\[Implementation URI (実装 URI)\]**​ 項目に次の URI をコピーします。 ```none https://jsonplaceholder.typicode.com/ ``` 3. **\[Port (ポート)\]**​ 項目に​`「80」`​と入力します。 このガイドの例では、API Manager のデフォルトポート ​`8081`​ ではなく HTTP ポート ​`80`​ を使用します。これは、作成された​`サービス`​は受信ポート ​`80`​ をポッドの対象ポート ​`80`​ にマップするためです。 [「Helm chart for Flex Gateway (Flex Gateway の Helm チャート)」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​`service.http.port`​ キーを参照してください。 4. **\[Next (次へ)\]**​ をクリックして ​**\[Review (確認)\]**​ ページを開きます。 6. **\[APIs / Add API (API/API を追加)\]**​ に関連付けられた ​**\[Review (確認)\]**​ ページで、次の作業を行います。 1. API 設定を確認します。 2. 必要に応じて、​**\[Edit (編集)\]**​ を使用して設定を変更します。 3. 設定が正しい場合、​**\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 ゲートウェイ内のポート ​`80`​ のすべての受信 HTTP 要求は、​`jsonplaceholder`​ サービスにプロキシされます。 7. ターミナルウィンドウから、API インスタンスをテストします。 1. 外部 IP アドレスを取得し、それを使用して IP が​**実装 URI**​ にリダイレクトされていることを確認します。 ```kubectl kubectl -n gateway get services ``` コマンドで次の例のような結果が返されます。 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ingress LoadBalancer 10.100.145.109 <123456.aws.com> 80:30524/TCP,443:31710/TCP 7d7h `EXTERNAL-IP`​ 値 ​`<123456.aws.com>`​ はサンプルで、実際の値ではありません。 2. ``​ を前のステップの​_各自_​の ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功コードを出力します。 200 次のように、よりシンプルな ​`curl`​ コマンドを実行して、サービスの ​`/users`​ エンドポイントから JSON オブジェクトの配列を返すこともできます。 ```curl $ curl http://:80/users ``` ## [](#ステップ-6-基本認証ポリシーを使用して-api-を保護する)ステップ 6: 基本認証ポリシーを使用して API を保護する API Manager を使用して、基本認証ポリシーを API に追加します。 1. **API Manager**​ で、サイドナビゲーションパネルから ​**\[API Administration (API 管理)\]**​ を選択します。 2. [ステップ 5: シンプルな API をパブリッシュして Flex Gateway にデプロイする](#create-api)​で作成した API の名前 (​**my-api**​ など) を見つけてクリックします。 3. 使用する API の ​**\[Policies (ポリシー)\]**​ ページに移動します。 1. サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 2. **\[Policies (ポリシー)\]**​ ページで、​**\[Add policy (ポリシーを追加)\]**​ をクリックします。 ![\[Add policy (ポリシーを追加)\] ボタンのある \[Add policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-add-policy.png) 4. 開いたページの ​**\[Security (セキュリティ)\]**​ で ​**\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ という名前のポリシーを見つけます。 ![幅広いセキュリティポリシーの中から選択できるフォーム](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-basic-auth.png) 同様の名前の LDAP のポリシーを選択しないように注意してください。 5. **\[Next (次へ)\]**​ をクリックします。 6. 基本認証ポリシーを設定します。 ![\[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] ページのスクリーンショット](_images/gateway-quickstart-config-basic-auth.png) 1. **\[User Name (ユーザー名)\]**​ に、実際のユーザー名ではなく​`「user」`​と入力します。 項目に値が事前入力されている場合は、その値を保持することも、推奨値に変更することもできます。 2. **\[User Password (ユーザーパスワード)\]**​ に​`「pw」`​と入力します。 項目に値が事前入力されている場合は、その値を保持することも、推奨値に変更することもできます。 3. **\[Apply (適用)\]**​ をクリックします。 7. API インスタンスをテストします。 1. `kubectl`​ を使用して、次のステップで使用できるように外部 IP アドレスを再度取得します。 ```kubectl kubectl -n gateway get services ``` 2. ``​ を前のステップで返された ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを認証パラメーター​_なし_​で実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' ``` URI に認証パラメーターがないため、コマンドで ​`401`​ が返されます。 401 3. ``​ を前のステップで返された ​`EXTERNAL-IP`​ に置き換えて、次の ​`curl`​ コマンドを認証パラメーター​_付き_​で実行します。 ```curl curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://:80/users' -u user:pw ``` このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 200 `user`​ パラメーターと ​`password`​ パラメーター (​`user:pw`​) は、ポリシーの適用時に指定した値と一致する必要があります。正しい認証パラメーターを入力していないと、次のエラーが発生します。 401 エラーに対処するには、正しい認証パラメーターを使用してコマンドを実行するか、API ゲートウェイの API のポリシー設定ページに戻ってポリシー設定を編集し、​`curl`​ コマンドを再実行します。 ![自動化された API レベルのポリシー設定](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-config-basic-auth-edit-dialogue.png) ログイン情報を編集するページは、次のようになります。 ![ユーザー名とパスワードを入力する項目が含まれるフォーム](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-k8-config-basic-auth-edit.png) ## [](#troubleshooting-k8)トラブルシューティング コマンドの実行時にエラーが発生した場合は、トラブルシューティング情報を確認してください。 [Docker コマンドの問題](#docker-troubleshooting)​ | ​[Helm コマンドの問題](#helm-troubleshooting) ### [](#docker-troubleshooting)Docker コマンドの問題 `docker`​ コマンドで返されるエラーのトラブルシューティング - [Docker デーモンエラー](#daemon-bad-response) - [Reg Facade エラー (400 Bad Request (400 不正な要求))](#bad-request) #### [](#daemon-bad-response)Docker デーモンエラー Docker が開始されていない場合、​`docker`​ コマンドで次のようなエラーメッセージが返されます。 - Error response from daemon: Bad response from Docker engine - ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? このエラーが発生した場合、Docker を開始します。 #### [](#bad-request)Reg Facade エラー (400 Bad Request (400 不正な要求)) `docker run`​ を使用してゲートウェイを登録するときに、次のエラーが発生する可能性があります。 \[flexctl\]\[error\] reg facade call returned error response: HTTP/1.1 400 Bad Request このエラーの理由は、エラーメッセージ内で確認できます。一般的な原因は次のとおりです。 - `an active target with the same name already exists in this organization and environment (同じ名前のアクティブな対象がすでにこの組織および環境に存在します)` この問題を回避するには、登録コマンドを実行するときにゲートウェイの​_一意の名前_​を指定します。その名前の前の登録が成功している場合でも、​_同じ名前を再利用することはできません_​。このエラーが発生すると、コマンドによって​_空の_​ ​`registration.yaml`​ が生成されて、再登録できなくなります。​_そのため_​、ゲートウェイをクラスターにデプロイするときにこのファイルを使用しようとすると、エラーが発生します。 - `no valid registration token was found (有効な登録トークンがありませんでした)` この問題を回避するには、Kubernetes の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページを更新して、コマンドの新しいトークンを生成し、登録コマンドを再実行します。 ### [](#helm-troubleshooting)Helm コマンドの問題 Kubernetes および OpenShift クラスターの ​`helm`​ コマンドで返されるエラーのトラブルシューティング - [アップグレードに失敗する: 例外エラー](#troubleshoot-helm-yaml-empty) - [Kubernetes クラスターに到達できない](#troubleshoot-helm-cluster-unreachable) - [アップグレードに失敗する: タイムアウト](#troubleshoot-helm-upgrade-failed) - [CRD をインストールできない](#troubleshoot-helm-openshift-rbac) #### [](#troubleshoot-helm-yaml-empty)アップグレードに失敗する: 例外エラー Flex Gateway のデプロイメント中に ​`registration.yaml`​ ファイルを Helm コマンドに渡すときにこのファイルが無効であると、次のエラーになります。 Error: UPGRADE FAILED: execution error at (flex-gateway/templates/deployment.yaml:4:10): registerSecretName, registration.content or registration.secretName is required! このエラーが発生した場合は、​`registration.yaml`​ ファイルが空でないことを確認してください。ファイルが空である場合、新しい一意の名前でゲートウェイを登録して、新しい ​`registration.yaml`​ を生成し、登録ステップの手順を再実行します。登録コマンドの例については、​[「Flex Gateway を登録する」](#register-flex)​を参照してください。 #### [](#troubleshoot-helm-upgrade-failed)アップグレードに失敗する: タイムアウト 問題によっては、次のタイムアウトエラーが発生する前に、(コマンドの ​`--wait`​ フラグが原因で) 最大 5 分間 Helm アップグレードコマンドがハングする可能性があります。 Error: UPGRADE FAILED: timed out waiting for the condition 通常、このエラーは、クラスター設定に誤りがあるか、クラスター設定ツールでこのプロセスがサポートされていないことを意味します。原因 1 つとして、​`LoadBalancer`​ 種別の ​`Service`​ リソースの生成の失敗が考えられます。さらにトラブルシューティングするには、次のコマンドを実行します。 - ```kubectl kubectl -n gateway describe deployment ``` - ```kubectl kubectl -n gateway describe service ``` #### [](#troubleshoot-helm-cluster-unreachable)Kubernetes クラスターに到達できない `helm`​ を使用して Flex Gateway をデプロイしようとしているときに Kubernetes クラスターが実行されていない場合、次のエラーが発生する可能性があります。 Error: Kubernetes cluster unreachable: the server could not find the requested resource クラスターを実行するサービスを開始します。 次のように、Kubernetes クラスターホストでクラスターが実行されていることを確認します。 ```kubectl kubectl cluster-info ``` - クラスターが実行されている場合、コマンドで次のような結果が返されます。 Kubernetes control plane is running at https://34.30.50.119 GLBCDefaultBackend is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/default-http-backend:http/proxy KubeDNS is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Metrics-server is running at https://34.30.50.119/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy - クラスターが設定されていない場合、コマンドで次のような結果が返される可能性があります。 To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. error: the server doesn't have a resource type "services" 詳細は、​[クラスターの要件](#kubernetes-cluster-reqs)​を参照してください。 #### [](#troubleshoot-helm-openshift-rbac)CRD をインストールできない ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 必要なアクセス権がない場合、次のようなエラーが発生します。 Error: failed to install CRD crds/apiinstance.yaml: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "user1" cannot create resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope 詳細は、​[クラスターの要件](#kubernetes-cluster-reqs)​を参照してください。 ## [](#check-cluster)クラスターを確認する [ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​で Flex Gateway を Kubernetes クラスターにデプロイする前に、クラスターの準備ができていることを確認します。​`kubectl`​ を使用して、クラスターをリストして選択 (使用) し、クラスターで使用されるノードのリストを取得します。このセクションのいずれかのステップが失敗すると、デプロイメントプロセスでエラーが発生する可能性があります。 このガイドの手順を実行するときの潜在的なタイムアウトや接続エラーを回避するために、クラスターで​[クラスターの要件](#kubernetes-cluster-reqs)​を満たす必要があります。 1. 次のように ​`kubectl config get-contexts`​ を実行して、クラスターをリストします。 ```kubectl kubectl config get-contexts ``` このコマンドは、複数の Kubernetes クラスターがある場合に特に役立ちます。このコマンドを使用して、正しいクラスターの名前を取得できます。たとえば、さまざまなクラスター (​`my-cluster`​、​`my-aks`​、​`my-gke`​、​`my-eks`​) があるとします。コマンドでクラスターのリストが出力されます。 次の​_例_​は、このコマンドで生成されるクラスターのリストを示しています。 CURRENT NAME CLUSTER AUTHINFO NAMESPACE my-cluster my-cluster my-cluster1 my-aks my-aks my-aks my-gke my-gke my-gke my-eks my-eks my-eks 自分のクラスターがリストされず、マシンでカスタムクラスターコンテキストファイルを使用してクラスターを接続している場合、そのファイルを参照する ​`KUBECONFIG`​ 環境変数にそのパスを追加することが必要になる可能性があります。デフォルトでは、​`kubectl`​ は ​`$HOME/.kube`​ ディレクトリの ​`config`​ という名前のファイルを検索します。そのファイルには、クラスター名、ユーザー、認証機関データなどのプロパティを提供する各​`コンテキスト`​がリストされています。 次の例のように、ターミナルウィンドウから環境変数値を出力する ​`echo $KUBECONFIG`​ を実行して確認できます。 {KUBECONFIG}:/Users/me/.kube/config:/Users/me/.kube/additional-clusters/my-gke:/Users/me/.kube/additional-clusters/my-aks:/Users/me/.kube/additional-clusters/my-eks マシンの他のクラスターコンテキストファイルにパスを追加すると、​`kubectl config get-contexts`​ コマンドでそのクラスターコンテキストをリストして使用できます。 詳細は、​`kubeconfig`​ ファイルについて [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​を参照してください。 2. ゲートウェイをデプロイするクラスターの名前を入力します。 次の例では、クラスターリストの例で特定されたクラスター ​`my-eks`​ を使用します。 kubectl config use-context my-eks このコマンドにより、選択したクラスターコンテキストに切り替わり、次のようなメッセージが出力されます。 Switched to context "my-eks". `error: no context exists with the name`​ で始まるエラーが発生した場合は、​`kubectl config get-contexts`​ でリストされたクラスターの ​`CLUSTER`​ 値ではなく ​`NAME`​ 値を使用していることを確認してください。 3. クラスターに 1 つ以上のノードがあることを確認します。 ```kubectl kubectl get nodes ``` コマンドで次のような出力が返されます。 NAME STATUS ROLES AGE VERSION ip-192-168-70-170 Ready 17h v1.x.x ip-192-168-9-230 Ready 17h v1.x.x 1 つ以上のノードが ​`Ready`​ 状況になっていることを確認します。 4. クラスターの準備ができていない場合、クラスター設定を修正します。 または、Kubernetes クラスターを使用しない Docker 専用ガイドの[自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started)を試して、次のステップをスキップします。 5. Flex Gateway セットアップ手順をまだ開始していない場合は、​[ステップ 1: Flex Gateway イメージをダウンロードする](#download-flex)​に進む前に​[クラスターの要件](#kubernetes-cluster-reqs)​を確認してください。 6. Docker でゲートウェイをダウンロードして登録し、Helm チャートのリポジトリを追加する手順をすべて完了している場合、デプロイメント手順を開始する準備ができているため、​[ステップ 4: Flex Gateway をデプロイして接続する](#deploy-flex)​に進みます。 ## [](#次のステップ)次のステップ Kubernetes クラスターの Flex Gateway をセットアップおよび設定する他の方法や、他のポリシー設定オプションを確認します。 - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) - [Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-configure) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management) - [インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) # Kubernetes クラスターのアプリケーションのドメイン名の指定 ExternalDNS を使用して、わかりにくい外部 IP やランダムなホスト名の代わりにドメイン名で Kubernetes クラスターのアプリケーションまたはサービスを公開します。 [ExternalDNS](https://github.com/kubernetes-sigs/external-dns/blob/master/README.md)​ は、多くの DNS プロバイダーの DNS 設定をサポートするオープンソースプロジェクトです。このツールは、DNS サーバーまたはプロバイダーでは​_ありません_​。代わりに、ExternalDNS は公開 DNS サーバーを介して Kubernetes リソースを検出し、サポートされている DNS プロバイダーのリソースを設定します。 このガイドでは、ExternalDNS を使用して、AWS Route 53 プロバイダー (ExternalDNS でサポートされている安定性の高いプロバイダーの 1 つ) のドメイン名を設定します。 ## [](#始める前に)始める前に 次の前提条件が準備されていることを確認します。 - AWS の Kubernetes クラスター - AWS クラスターへの Flex Gateway デプロイメントまたは登録済みの Flex Gateway インスタンス (ゲートウェイ) ゲートウェイの登録およびデプロイメントプロセスについては、​[自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) or [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started)​を参照してください。 - ExternalDNS が Amazon Route 53 リソースレコードセットとホストゾーンを更新することを許可する AWS Identity and Access Management (IAM) ポリシー 別の対象を使用したり、これらの許可で IAM ポリシーを作成したりするには、 [ExternalDNS ドキュメント](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md)​を参照してください。 ## [](#externaldns-をクラスターに追加する)ExternalDNS をクラスターに追加する ExternalDNS (​`external-dns`​) をクラスターに追加するには、次のコンテンツが含まれる YAML 設定ファイルを作成して、クラスターにデプロイします。 1. 次の設定が含まれる YAML ファイルを作成します。 ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: external-dns labels: app.kubernetes.io/name: external-dns spec: strategy: type: Recreate selector: matchLabels: app.kubernetes.io/name: external-dns template: metadata: labels: app.kubernetes.io/name: external-dns spec: containers: - name: external-dns image: registry.k8s.io/external-dns/external-dns:v0.13.1 args: - --source=service - --source=ingress - --domain-filter= # makes only hosted zones visible - --provider=aws - --policy=upsert-only # prevents record deletion - --aws-zone-type=public # public zones only - --registry=txt - --txt-owner-id=my-hostedzone-identifier env: - name: AWS_DEFAULT_REGION value: # sets the EKS region # # Uncomment the following settings when using static credentials # - name: AWS_SHARED_CREDENTIALS_FILE # value: /.aws/credentials # volumeMounts: # - name: aws-credentials # mountPath: /.aws # readOnly: true # volumes: # - name: aws-credentials # secret: # secretName: external-dns ``` 2. 新しい YAML ファイルの場合、デプロイメントで必要に応じて次のオプションを設定します。 - `args`​ オプション: - `- --domain-filter=`​: ドメインに一致するホストゾーンを ExternalDNS で参照できるようにします。すべての使用可能なホストゾーンを処理するには、このオプションを省略します。 このオプションは、​`external-dns`​ が意図したとおりに動作するために重要です。 - `- --policy=upsert-only`​: ExternalDNS でレコードが削除されないようにします。完全な同期を有効にするには、このオプションを省略します。 - `- --aws-zone-type=public`​: 公開ホストゾーンのみを参照できるようにします。有効な値は ​`public`​ または ​`private`​ です。または、両方のゾーン種別の値を指定しないこともできます。 - `env`​ オプション ​`value: `​: EKS クラスターがインストールされるリージョン (例: `us-east-1`​)。 3. 静的ログイン情報を使用する場合、非表示の ​`env`​ および ​`volumes`​ 設定が含まれる行からコメント (​`#`​) を削除します。 4. ターミナルウィンドウから次のコマンドを使用して、設定をクラスターに適用します。 ```kubctl kubectl create --filename --namespace ``` ## [](#flex-gateway-の-helm-チャートを介して-dns-名を設定する)Flex Gateway の Helm チャートを介して DNS 名を設定する `helm upgrade`​ で ​`extraAnnotations`​ パラメーターを使用して、ドメイン名を設定します。このパラメーターについては、 [「Helm chart for Flex Gateway (flex-gateway) (Flex Gateway の Helm チャート (flex-gateway))」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​を参照してください。 1. YAML 設定ファイルを作成して、ExternalDNS キーと、カンマ区切りのドメイン値のセットを指定します。 プレースホルダー値 ​`,…​,`​ を各自のドメインに置き換えます。 extraAnnotations: external-dns.alpha.kubernetes.io/hostname: ,..., 2. `-f`​ オプションを使用して、設定ファイルを ​`helm upgrade`​ コマンドに渡します。 使用するコマンドは、登録済みゲートウェイがクラスターにデプロイされているかどうかによって異なります。 1. 始めて Flex Gateway をクラスターにデプロイする場合、次のコマンドを実行します。プレースホルダー値は、各自のゲートウェイの登録 YAML ファイル (デフォルトでは ​`registration.yaml`​) へのパスとドメイン名に置き換えます。 ```helm helm -n gateway upgrade \ -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --set-file registration.content= \ -f ``` 2. アノテーションを使用して実行中のゲートウェイを更新する場合、次のコマンドを実行します。 ```helm helm -n gateway upgrade \ --wait ingress flex-gateway/flex-gateway \ --reuse-values \ -f ``` # Kubernetes クラスターのアプリケーションのドメイン名の指定 ExternalDNS を使用して、わかりにくい外部 IP やランダムなホスト名の代わりにドメイン名で Kubernetes クラスターのアプリケーションまたはサービスを公開します。 [ExternalDNS](https://github.com/kubernetes-sigs/external-dns/blob/master/README.md)​ は、多くの DNS プロバイダーの DNS 設定をサポートするオープンソースプロジェクトです。このツールは、DNS サーバーまたはプロバイダーでは​_ありません_​。代わりに、ExternalDNS は公開 DNS サーバーを介して Kubernetes リソースを検出し、サポートされている DNS プロバイダーのリソースを設定します。 このガイドでは、ExternalDNS を使用して、AWS Route 53 プロバイダー (ExternalDNS でサポートされている安定性の高いプロバイダーの 1 つ) のドメイン名を設定します。 ## [](#始める前に)始める前に 次の前提条件が準備されていることを確認します。 - AWS の Kubernetes クラスター - AWS クラスターへの Flex Gateway デプロイメントまたは登録済みの Flex Gateway インスタンス (ゲートウェイ) ゲートウェイの登録およびデプロイメントプロセスについては、​[Flex Gateway のセットアップ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-set-up) or [Kubernetes クラスターでの Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-getting-started)​を参照してください。 - ExternalDNS が Amazon Route 53 リソースレコードセットとホストゾーンを更新することを許可する AWS Identity and Access Management (IAM) ポリシー 別の対象を使用したり、これらの許可で IAM ポリシーを作成したりするには、 [ExternalDNS ドキュメント](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md)​を参照してください。 ## [](#externaldns-をクラスターに追加する)ExternalDNS をクラスターに追加する ExternalDNS (​`external-dns`​) をクラスターに追加するには、次のコンテンツが含まれる YAML 設定ファイルを作成して、クラスターにデプロイします。 1. 次の設定が含まれる YAML ファイルを作成します。 ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: external-dns labels: app.kubernetes.io/name: external-dns spec: strategy: type: Recreate selector: matchLabels: app.kubernetes.io/name: external-dns template: metadata: labels: app.kubernetes.io/name: external-dns spec: containers: - name: external-dns image: registry.k8s.io/external-dns/external-dns:v0.13.1 args: - --source=service - --source=ingress - --domain-filter= # makes only hosted zones visible - --provider=aws - --policy=upsert-only # prevents record deletion - --aws-zone-type=public # public zones only - --registry=txt - --txt-owner-id=my-hostedzone-identifier env: - name: AWS_DEFAULT_REGION value: # sets the EKS region # # Uncomment the following settings when using static credentials # - name: AWS_SHARED_CREDENTIALS_FILE # value: /.aws/credentials # volumeMounts: # - name: aws-credentials # mountPath: /.aws # readOnly: true # volumes: # - name: aws-credentials # secret: # secretName: external-dns ``` 2. 新しい YAML ファイルの場合、デプロイメントで必要に応じて次のオプションを設定します。 - `args`​ オプション: - `- --domain-filter=`​: ドメインに一致するホストゾーンを ExternalDNS で参照できるようにします。すべての使用可能なホストゾーンを処理するには、このオプションを省略します。 このオプションは、​`external-dns`​ が意図したとおりに動作するために重要です。 - `- --policy=upsert-only`​: ExternalDNS でレコードが削除されないようにします。完全な同期を有効にするには、このオプションを省略します。 - `- --aws-zone-type=public`​: 公開ホストゾーンのみを参照できるようにします。有効な値は ​`public`​ または ​`private`​ です。または、両方のゾーン種別の値を指定しないこともできます。 - `env`​ オプション ​`value: `​: EKS クラスターがインストールされるリージョン (例: `us-east-1`​)。 3. 静的ログイン情報を使用する場合、非表示の ​`env`​ および ​`volumes`​ 設定が含まれる行からコメント (​`#`​) を削除します。 4. ターミナルウィンドウから次のコマンドを使用して、設定をクラスターに適用します。 ```kubctl kubectl create --filename --namespace ``` ## [](#flex-gateway-の-helm-チャートを介して-dns-名を設定する)Flex Gateway の Helm チャートを介して DNS 名を設定する `helm upgrade`​ で ​`extraAnnotations`​ パラメーターを使用して、ドメイン名を設定します。このパラメーターについては、 [「Helm chart for Flex Gateway (flex-gateway) (Flex Gateway の Helm チャート (flex-gateway))」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​を参照してください。 1. YAML 設定ファイルを作成して、ExternalDNS キーと、カンマ区切りのドメイン値のセットを指定します。 プレースホルダー値 ​`,…​,`​ を各自のドメインに置き換えます。 extraAnnotations: external-dns.alpha.kubernetes.io/hostname: ,..., 2. `-f`​ オプションを使用して、設定ファイルを ​`helm upgrade`​ コマンドに渡します。 使用するコマンドは、登録済みゲートウェイがクラスターにデプロイされているかどうかによって異なります。 1. 始めて Flex Gateway をクラスターにデプロイする場合、次のコマンドを実行します。プレースホルダー値は、各自のゲートウェイの登録 YAML ファイル (デフォルトでは ​`registration.yaml`​) へのパスとドメイン名に置き換えます。 ```helm helm -n gateway upgrade \ -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --set-file registration.content= \ -f ``` 2. アノテーションを使用して実行中のゲートウェイを更新する場合、次のコマンドを実行します。 ```helm helm -n gateway upgrade \ --wait ingress flex-gateway/flex-gateway \ --reuse-values \ -f ``` # Kubernetes クラスターのアプリケーションのドメイン名の指定 ExternalDNS を使用して、わかりにくい外部 IP やランダムなホスト名の代わりにドメイン名で Kubernetes クラスターのアプリケーションまたはサービスを公開します。 [ExternalDNS](https://github.com/kubernetes-sigs/external-dns/blob/master/README.md)​ は、多くの DNS プロバイダーの DNS 設定をサポートするオープンソースプロジェクトです。このツールは、DNS サーバーまたはプロバイダーでは​_ありません_​。代わりに、ExternalDNS は公開 DNS サーバーを介して Kubernetes リソースを検出し、サポートされている DNS プロバイダーのリソースを設定します。 このガイドでは、ExternalDNS を使用して、AWS Route 53 プロバイダー (ExternalDNS でサポートされている安定性の高いプロバイダーの 1 つ) のドメイン名を設定します。 ## [](#始める前に)始める前に 次の前提条件が準備されていることを確認します。 - AWS の Kubernetes クラスター - AWS クラスターへの Flex Gateway デプロイメントまたは登録済みの Flex Gateway インスタンス (ゲートウェイ) ゲートウェイの登録およびデプロイメントプロセスについては、​[自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) or [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started)​を参照してください。 - ExternalDNS が Amazon Route 53 リソースレコードセットとホストゾーンを更新することを許可する AWS Identity and Access Management (IAM) ポリシー 別の対象を使用したり、これらの許可で IAM ポリシーを作成したりするには、 [ExternalDNS ドキュメント](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md)​を参照してください。 ## [](#externaldns-をクラスターに追加する)ExternalDNS をクラスターに追加する ExternalDNS (​`external-dns`​) をクラスターに追加するには、次のコンテンツが含まれる YAML 設定ファイルを作成して、クラスターにデプロイします。 1. 次の設定が含まれる YAML ファイルを作成します。 ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: external-dns labels: app.kubernetes.io/name: external-dns spec: strategy: type: Recreate selector: matchLabels: app.kubernetes.io/name: external-dns template: metadata: labels: app.kubernetes.io/name: external-dns spec: containers: - name: external-dns image: registry.k8s.io/external-dns/external-dns:v0.13.1 args: - --source=service - --source=ingress - --domain-filter= # makes only hosted zones visible - --provider=aws - --policy=upsert-only # prevents record deletion - --aws-zone-type=public # public zones only - --registry=txt - --txt-owner-id=my-hostedzone-identifier env: - name: AWS_DEFAULT_REGION value: # sets the EKS region # # Uncomment the following settings when using static credentials # - name: AWS_SHARED_CREDENTIALS_FILE # value: /.aws/credentials # volumeMounts: # - name: aws-credentials # mountPath: /.aws # readOnly: true # volumes: # - name: aws-credentials # secret: # secretName: external-dns ``` 2. 新しい YAML ファイルの場合、デプロイメントで必要に応じて次のオプションを設定します。 - `args`​ オプション: - `- --domain-filter=`​: ドメインに一致するホストゾーンを ExternalDNS で参照できるようにします。すべての使用可能なホストゾーンを処理するには、このオプションを省略します。 このオプションは、​`external-dns`​ が意図したとおりに動作するために重要です。 - `- --policy=upsert-only`​: ExternalDNS でレコードが削除されないようにします。完全な同期を有効にするには、このオプションを省略します。 - `- --aws-zone-type=public`​: 公開ホストゾーンのみを参照できるようにします。有効な値は ​`public`​ または ​`private`​ です。または、両方のゾーン種別の値を指定しないこともできます。 - `env`​ オプション ​`value: `​: EKS クラスターがインストールされるリージョン (例: `us-east-1`​)。 3. 静的ログイン情報を使用する場合、非表示の ​`env`​ および ​`volumes`​ 設定が含まれる行からコメント (​`#`​) を削除します。 4. ターミナルウィンドウから次のコマンドを使用して、設定をクラスターに適用します。 ```kubctl kubectl create --filename --namespace ``` ## [](#flex-gateway-の-helm-チャートを介して-dns-名を設定する)Flex Gateway の Helm チャートを介して DNS 名を設定する `helm upgrade`​ で ​`extraAnnotations`​ パラメーターを使用して、ドメイン名を設定します。このパラメーターについては、 [「Helm chart for Flex Gateway (flex-gateway) (Flex Gateway の Helm チャート (flex-gateway))」](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​を参照してください。 1. YAML 設定ファイルを作成して、ExternalDNS キーと、カンマ区切りのドメイン値のセットを指定します。 プレースホルダー値 ​`,…​,`​ を各自のドメインに置き換えます。 extraAnnotations: external-dns.alpha.kubernetes.io/hostname: ,..., 2. `-f`​ オプションを使用して、設定ファイルを ​`helm upgrade`​ コマンドに渡します。 使用するコマンドは、登録済みゲートウェイがクラスターにデプロイされているかどうかによって異なります。 1. 始めて Flex Gateway をクラスターにデプロイする場合、次のコマンドを実行します。プレースホルダー値は、各自のゲートウェイの登録 YAML ファイル (デフォルトでは ​`registration.yaml`​) へのパスとドメイン名に置き換えます。 ```helm helm -n gateway upgrade \ -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --set-file registration.content= \ -f ``` 2. アノテーションを使用して実行中のゲートウェイを更新する場合、次のコマンドを実行します。 ```helm helm -n gateway upgrade \ --wait ingress flex-gateway/flex-gateway \ --reuse-values \ -f ``` # Kubernetes での Flex Gateway デプロイメントのノード選択の設定 (ノードアフィニティ) Flex Gateway は、クラスターのパフォーマンスやセキュリティにとって不可欠であることが少なくないため、他のデプロイメントをホストするノードを使用する代わりに、特定の要件を満たす専用のノードでホストすることが重要です。 Kubernetes スケジューラーで、Flex Gateway が含まれるポッドの適切なホストノードを選択できるようにするには、ポッドの要件を Flex Gateway デプロイメントの Helm チャートに組み込むカスタムノードアフィニティルールを YAML 設定ファイルで設定します。ノードアフィニティについての詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)​を参照してください。 ノードアフィニティを設定するためのタスクの概要を次に示します。 1. ノードアフィニティルールおよび条件を定義するときに使用するノード表示ラベルを検索して作成する (​[ノード表示ラベルのリストおよび作成](#list_add_labels)​を参照)。 2. コンテナ化された Flex Gateway アプリケーションを使用してポッドをホストするノードの要件および設定を YAML 設定ファイルで指定する (​[Flex Gateway コンテナのポッドに対してノードを照合するルールの設定](#set_node_affinity)​を参照)。 3. YAML 設定を使用して Helm チャートをアップグレードする (​[Helm チャートのアップグレード](#upgrade_helm_chart)​を参照)。 ## [](#始める前に)始める前に [ソフトウェア要件](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites#software-requirements)​で説明されている Kubernetes および Helm の最小バージョン要件を満たします。 ## [](#list_add_labels)ノード表示ラベルのリストおよび作成 各ノードアフィニティルールでは、ノード表示ラベルのキーと 1 つ以上の表示ラベルの値が必要です。既存のノード表示ラベルを使用するか、新しいノード表示ラベルを作成できます。ノード表示ラベルは、キー-値ペアとして定義されます。 - クラスターのノードおよびノード表示ラベルをリストするには、以下を実行します。 ```kubernetes kubectl get nodes --show-labels ``` - クラスターのノードの表示ラベルを作成するには、以下を実行します。 ```kubernetes kubectl label nodes = ``` 関連する Kubernetes ドキュメントについては、 [「ラベルをノードに追加する」](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)​を参照してください。 ## [](#set_node_affinity)Flex Gateway コンテナのポッドに対してノードを照合するルールの設定 Kubernetes スケジューラーは、ノードアフィニティルールを使用して、ポッドに対してノードを照合できます。照合プロセスにより、スケジューラーはポッドにデプロイされるノードを選択できます。 ノードアフィニティルールを \[required (必須)\]、\[preferred (優先)\]、またはその両方として設定します。 - `requiredDuringSchedulingIgnoredDuringExecution`​: Kubernetes スケジューラーがこの種類の照合を適用する場合、ノードはポッドに設定されたすべてのノードアフィニティルールに一致する必要があります。それ以外の場合は、デプロイメントに失敗します。 - `preferredDuringSchedulingIgnoredDuringExecution`​: ポッドのに設定された加重設定に基づいて、Kubernetes スケジューラーは最も一致するノードを選択します。スケジューラーはノードを選択する必要があるため、設定に一致するノードがない場合は一致しないノードを選択します。 案内については、次の設定オプションを参照してください。 - [Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定](#required_node_matching) - [Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定](#preferred_node_matching) - [Flex Gateway が含まれるポッドの \[Required (必須)\] および \[Preferred (優先)\] ノード一致ルールの設定](#mixed_node_matching) ### [](#required_node_matching)Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定 \[required (必須)\] ノード一致では、ノードはポッドに設定されたすべてのノードアフィニティルールに一致する必要があります。それ以外の場合は、デプロイメントに失敗します。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other required conditions. ``` 値と条件は、ノードで必要なだけ追加できます。 ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ### [](#preferred_node_matching)Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定 \[preferred (優先)\] ノード一致では、Kubernetes スケジューラーは加重設定に基づいてノードを選択します。スケジューラーはノードを選択する必要があるため、設定に一致するノードがない場合は一致しないノードを選択します。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 また、Kubernetes スケジューラーがより重要なルールを判断して、最も一致するノードを選択できるように、​`preference`​ ごとに ​`1`​ ～ ​`100`​ の ​`weight`​ 値を指定します。照合は、ノードに適合する加重設定の合計に基づいて行われます。スケジューラーは、加重の少ない他のノードを除外して加重の合計の最も大きいノードを選択します。 ```yaml affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other values. - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other preferred conditions. # - Any any more preferred rules. ``` 任意の数の優先値、条件、ルールを追加できます。 ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ### [](#mixed_node_matching)Flex Gateway が含まれるポッドの \[Required (必須)\] および \[Preferred (優先)\] ノード一致ルールの設定 同じ YAML ファイルで両方のノードアフィニティ種別 (\[required (必須)\] および \[preferred (優先)\]) を設定できます。 この例は​[Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定](#required_node_matching)​と​[Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定](#preferred_node_matching)​の設定を組み合わせています。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 また、Kubernetes スケジューラーがより重要なルールを判断して、最も一致するノードを選択できるように、​`preference`​ ごとに ​`1`​ ～ ​`100`​ の ​`weight`​ 値を指定します。照合は、ノードに適合する加重設定の合計に基づいて行われます。スケジューラーは、加重の少ない他のノードを除外して加重の合計の最も大きいノードを選択します。 ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other conditions. preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other preferred conditions. # - Any any other preferred rules. ``` ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ## [](#upgrade_helm_chart)Helm チャートのアップグレード ノードアフィニティ設定を YAML 設定ファイルに追加したら、Kubernetes スケジューラーが設定を使用できるように、ファイルを Flex Gateway デプロイメントの Helm チャートに組み込みます。 `helm`​ コマンドを使用して、ノードアフィニティ設定を YAML 設定ファイルから Helm チャートに組み込みます。使用するコマンドは、Flex Gateway がインストールされているかどうかによって異なります。 - Flex Gateway を始めてインストールする場合、次のコマンドを使用して、すべての値をチャートに設定します。 ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ -f \ --set-file registration.content= ``` このコマンドでは、ノードアフィニティルールが含まれる YAML ファイルが渡されます。 - Flex Gateway がすでにインストールされている場合、このコマンドを使用して、チャートの既存の設定を再利用し、ノードアフィニティ設定を定義します。 ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --reuse-values -f ``` このコマンドでは、ノードアフィニティルールが含まれる YAML ファイルが渡されます。 Helm コマンドについては、 [「Helm Upgrade (Helm のアップグレード)」](https://helm.sh/docs/helm/helm_upgrade)​を参照してください。 # Kubernetes での Flex Gateway デプロイメントのノード選択の設定 (ノードアフィニティ) Flex Gateway は、クラスターのパフォーマンスやセキュリティにとって不可欠であることが少なくないため、他のデプロイメントをホストするノードを使用する代わりに、特定の要件を満たす専用のノードでホストすることが重要です。 Kubernetes スケジューラーで、Flex Gateway が含まれるポッドの適切なホストノードを選択できるようにするには、ポッドの要件を Flex Gateway デプロイメントの Helm チャートに組み込むカスタムノードアフィニティルールを YAML 設定ファイルで設定します。ノードアフィニティについての詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)​を参照してください。 ノードアフィニティを設定するためのタスクの概要を次に示します。 1. ノードアフィニティルールおよび条件を定義するときに使用するノード表示ラベルを検索して作成する (​[ノード表示ラベルのリストおよび作成](#list_add_labels)​を参照)。 2. コンテナ化された Flex Gateway アプリケーションを使用してポッドをホストするノードの要件および設定を YAML 設定ファイルで指定する (​[Flex Gateway コンテナのポッドに対してノードを照合するルールの設定](#set_node_affinity)​を参照)。 3. YAML 設定を使用して Helm チャートをアップグレードする (​[Helm チャートのアップグレード](#upgrade_helm_chart)​を参照)。 ## [](#始める前に)始める前に [ソフトウェア要件](https://docs.mulesoft.com/jp/gateway/1.8/flex-review-prerequisites#software-requirements)​で説明されている Kubernetes および Helm の最小バージョン要件を満たします。 ## [](#list_add_labels)ノード表示ラベルのリストおよび作成 各ノードアフィニティルールでは、ノード表示ラベルのキーと 1 つ以上の表示ラベルの値が必要です。既存のノード表示ラベルを使用するか、新しいノード表示ラベルを作成できます。ノード表示ラベルは、キー-値ペアとして定義されます。 - クラスターのノードおよびノード表示ラベルをリストするには、以下を実行します。 ```kubernetes kubectl get nodes --show-labels ``` - クラスターのノードの表示ラベルを作成するには、以下を実行します。 ```kubernetes kubectl label nodes = ``` 関連する Kubernetes ドキュメントについては、 [「ラベルをノードに追加する」](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)​を参照してください。 ## [](#set_node_affinity)Flex Gateway コンテナのポッドに対してノードを照合するルールの設定 Kubernetes スケジューラーは、ノードアフィニティルールを使用して、ポッドに対してノードを照合できます。照合プロセスにより、スケジューラーはポッドにデプロイされるノードを選択できます。 ノードアフィニティルールを \[required (必須)\]、\[preferred (優先)\]、またはその両方として設定します。 - `requiredDuringSchedulingIgnoredDuringExecution`​: Kubernetes スケジューラーがこの種類の照合を適用する場合、ノードはポッドに設定されたすべてのノードアフィニティルールに一致する必要があります。それ以外の場合は、デプロイメントに失敗します。 - `preferredDuringSchedulingIgnoredDuringExecution`​: ポッドのに設定された加重設定に基づいて、Kubernetes スケジューラーは最も一致するノードを選択します。スケジューラーはノードを選択する必要があるため、設定に一致するノードがない場合は一致しないノードを選択します。 案内については、次の設定オプションを参照してください。 - [Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定](#required_node_matching) - [Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定](#preferred_node_matching) - [Flex Gateway が含まれるポッドの \[Required (必須)\] および \[Preferred (優先)\] ノード一致ルールの設定](#mixed_node_matching) ### [](#required_node_matching)Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定 \[required (必須)\] ノード一致では、ノードはポッドに設定されたすべてのノードアフィニティルールに一致する必要があります。それ以外の場合は、デプロイメントに失敗します。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other required conditions. ``` 値と条件は、ノードで必要なだけ追加できます。 ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ### [](#preferred_node_matching)Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定 \[preferred (優先)\] ノード一致では、Kubernetes スケジューラーは加重設定に基づいてノードを選択します。スケジューラーはノードを選択する必要があるため、設定に一致するノードがない場合は一致しないノードを選択します。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 また、Kubernetes スケジューラーがより重要なルールを判断して、最も一致するノードを選択できるように、​`preference`​ ごとに ​`1`​ ～ ​`100`​ の ​`weight`​ 値を指定します。照合は、ノードに適合する加重設定の合計に基づいて行われます。スケジューラーは、加重の少ない他のノードを除外して加重の合計の最も大きいノードを選択します。 ```yaml affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other values. - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other preferred conditions. # - Any any more preferred rules. ``` 任意の数の優先値、条件、ルールを追加できます。 ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ### [](#mixed_node_matching)Flex Gateway が含まれるポッドの \[Required (必須)\] および \[Preferred (優先)\] ノード一致ルールの設定 同じ YAML ファイルで両方のノードアフィニティ種別 (\[required (必須)\] および \[preferred (優先)\]) を設定できます。 この例は​[Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定](#required_node_matching)​と​[Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定](#preferred_node_matching)​の設定を組み合わせています。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 また、Kubernetes スケジューラーがより重要なルールを判断して、最も一致するノードを選択できるように、​`preference`​ ごとに ​`1`​ ～ ​`100`​ の ​`weight`​ 値を指定します。照合は、ノードに適合する加重設定の合計に基づいて行われます。スケジューラーは、加重の少ない他のノードを除外して加重の合計の最も大きいノードを選択します。 ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other conditions. preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other preferred conditions. # - Any any other preferred rules. ``` ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ## [](#upgrade_helm_chart)Helm チャートのアップグレード ノードアフィニティ設定を YAML 設定ファイルに追加したら、Kubernetes スケジューラーが設定を使用できるように、ファイルを Flex Gateway デプロイメントの Helm チャートに組み込みます。 `helm`​ コマンドを使用して、ノードアフィニティ設定を YAML 設定ファイルから Helm チャートに組み込みます。使用するコマンドは、Flex Gateway がインストールされているかどうかによって異なります。 - Flex Gateway を始めてインストールする場合、次のコマンドを使用して、すべての値をチャートに設定します。 ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ -f \ --set-file registration.content= ``` このコマンドでは、ノードアフィニティルールが含まれる YAML ファイルが渡されます。 - Flex Gateway がすでにインストールされている場合、このコマンドを使用して、チャートの既存の設定を再利用し、ノードアフィニティ設定を定義します。 ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --reuse-values -f ``` このコマンドでは、ノードアフィニティルールが含まれる YAML ファイルが渡されます。 Helm コマンドについては、 [「Helm Upgrade (Helm のアップグレード)」](https://helm.sh/docs/helm/helm_upgrade)​を参照してください。 # Kubernetes での Flex Gateway デプロイメントのノード選択の設定 (ノードアフィニティ) Flex Gateway は、クラスターのパフォーマンスやセキュリティにとって不可欠であることが少なくないため、他のデプロイメントをホストするノードを使用する代わりに、特定の要件を満たす専用のノードでホストすることが重要です。 Kubernetes スケジューラーで、Flex Gateway が含まれるポッドの適切なホストノードを選択できるようにするには、ポッドの要件を Flex Gateway デプロイメントの Helm チャートに組み込むカスタムノードアフィニティルールを YAML 設定ファイルで設定します。ノードアフィニティについての詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)​を参照してください。 ノードアフィニティを設定するためのタスクの概要を次に示します。 1. ノードアフィニティルールおよび条件を定義するときに使用するノード表示ラベルを検索して作成する (​[ノード表示ラベルのリストおよび作成](#list_add_labels)​を参照)。 2. コンテナ化された Flex Gateway アプリケーションを使用してポッドをホストするノードの要件および設定を YAML 設定ファイルで指定する (​[Flex Gateway コンテナのポッドに対してノードを照合するルールの設定](#set_node_affinity)​を参照)。 3. YAML 設定を使用して Helm チャートをアップグレードする (​[Helm チャートのアップグレード](#upgrade_helm_chart)​を参照)。 ## [](#始める前に)始める前に [ソフトウェア要件](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites#software-requirements)​で説明されている Kubernetes および Helm の最小バージョン要件を満たします。 ## [](#list_add_labels)ノード表示ラベルのリストおよび作成 各ノードアフィニティルールでは、ノード表示ラベルのキーと 1 つ以上の表示ラベルの値が必要です。既存のノード表示ラベルを使用するか、新しいノード表示ラベルを作成できます。ノード表示ラベルは、キー-値ペアとして定義されます。 - クラスターのノードおよびノード表示ラベルをリストするには、以下を実行します。 ```kubernetes kubectl get nodes --show-labels ``` - クラスターのノードの表示ラベルを作成するには、以下を実行します。 ```kubernetes kubectl label nodes = ``` 関連する Kubernetes ドキュメントについては、 [「ラベルをノードに追加する」](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)​を参照してください。 ## [](#set_node_affinity)Flex Gateway コンテナのポッドに対してノードを照合するルールの設定 Kubernetes スケジューラーは、ノードアフィニティルールを使用して、ポッドに対してノードを照合できます。照合プロセスにより、スケジューラーはポッドにデプロイされるノードを選択できます。 ノードアフィニティルールを \[required (必須)\]、\[preferred (優先)\]、またはその両方として設定します。 - `requiredDuringSchedulingIgnoredDuringExecution`​: Kubernetes スケジューラーがこの種類の照合を適用する場合、ノードはポッドに設定されたすべてのノードアフィニティルールに一致する必要があります。それ以外の場合は、デプロイメントに失敗します。 - `preferredDuringSchedulingIgnoredDuringExecution`​: ポッドのに設定された加重設定に基づいて、Kubernetes スケジューラーは最も一致するノードを選択します。スケジューラーはノードを選択する必要があるため、設定に一致するノードがない場合は一致しないノードを選択します。 案内については、次の設定オプションを参照してください。 - [Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定](#required_node_matching) - [Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定](#preferred_node_matching) - [Flex Gateway が含まれるポッドの \[Required (必須)\] および \[Preferred (優先)\] ノード一致ルールの設定](#mixed_node_matching) ### [](#required_node_matching)Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定 \[required (必須)\] ノード一致では、ノードはポッドに設定されたすべてのノードアフィニティルールに一致する必要があります。それ以外の場合は、デプロイメントに失敗します。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other required conditions. ``` 値と条件は、ノードで必要なだけ追加できます。 ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ### [](#preferred_node_matching)Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定 \[preferred (優先)\] ノード一致では、Kubernetes スケジューラーは加重設定に基づいてノードを選択します。スケジューラーはノードを選択する必要があるため、設定に一致するノードがない場合は一致しないノードを選択します。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 また、Kubernetes スケジューラーがより重要なルールを判断して、最も一致するノードを選択できるように、​`preference`​ ごとに ​`1`​ ～ ​`100`​ の ​`weight`​ 値を指定します。照合は、ノードに適合する加重設定の合計に基づいて行われます。スケジューラーは、加重の少ない他のノードを除外して加重の合計の最も大きいノードを選択します。 ```yaml affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other values. - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other preferred conditions. # - Any any more preferred rules. ``` 任意の数の優先値、条件、ルールを追加できます。 ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ### [](#mixed_node_matching)Flex Gateway が含まれるポッドの \[Required (必須)\] および \[Preferred (優先)\] ノード一致ルールの設定 同じ YAML ファイルで両方のノードアフィニティ種別 (\[required (必須)\] および \[preferred (優先)\]) を設定できます。 この例は​[Flex Gateway が含まれるポッドの \[Required (必須)\] ノード一致ルールの設定](#required_node_matching)​と​[Flex Gateway が含まれるポッドの \[Preferred (優先)\] ノード一致ルールの設定](#preferred_node_matching)​の設定を組み合わせています。 Flex Gateway が含まれるポッドのノードアフィニティルールを YAML 設定ファイルで設定します。ルールの条件ごとに、ノード表示ラベル (​`key`​ として)、演算子、およびそのキーのノードを受け入れる 1 つ以上のノード表示ラベル値が必要です。​`In`​、​`NotIn`​、​`Exists`​、​`DoesNotExist`​、​`Gt`​、​`Lt`​ を演算子として使用できます。 また、Kubernetes スケジューラーがより重要なルールを判断して、最も一致するノードを選択できるように、​`preference`​ ごとに ​`1`​ ～ ​`100`​ の ​`weight`​ 値を指定します。照合は、ノードに適合する加重設定の合計に基づいて行われます。スケジューラーは、加重の少ない他のノードを除外して加重の合計の最も大きいノードを選択します。 ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other conditions. preferredDuringSchedulingIgnoredDuringExecution: - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. - weight: preference: matchExpressions: - key: operator: values: - # - Add any other node label values. # - Add any other preferred conditions. # - Any any other preferred rules. ``` ポッドの YAML 設定ファイルを設定したら、「[Helm チャートのアップグレード](#upgrade_helm_chart)」に進みます。 ## [](#upgrade_helm_chart)Helm チャートのアップグレード ノードアフィニティ設定を YAML 設定ファイルに追加したら、Kubernetes スケジューラーが設定を使用できるように、ファイルを Flex Gateway デプロイメントの Helm チャートに組み込みます。 `helm`​ コマンドを使用して、ノードアフィニティ設定を YAML 設定ファイルから Helm チャートに組み込みます。使用するコマンドは、Flex Gateway がインストールされているかどうかによって異なります。 - Flex Gateway を始めてインストールする場合、次のコマンドを使用して、すべての値をチャートに設定します。 ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ -f \ --set-file registration.content= ``` このコマンドでは、ノードアフィニティルールが含まれる YAML ファイルが渡されます。 - Flex Gateway がすでにインストールされている場合、このコマンドを使用して、チャートの既存の設定を再利用し、ノードアフィニティ設定を定義します。 ```kubernetes helm -n gateway upgrade -i --create-namespace \ --wait ingress flex-gateway/flex-gateway \ --reuse-values -f ``` このコマンドでは、ノードアフィニティルールが含まれる YAML ファイルが渡されます。 Helm コマンドについては、 [「Helm Upgrade (Helm のアップグレード)」](https://helm.sh/docs/helm/helm_upgrade)​を参照してください。 # Kubernetes デプロイメントの管理 - [Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings) - Flex Gateway を含むポッドの要件を変更します。 - [Flex Gateway レプリカの自動スケーリングおよび名前空間への追加](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-high-availability) - 固定レプリカ数または自動スケールを設定して、追加のレプリカを提供します。 - [Kubernetes での Flex Gateway デプロイメントのノード選択の設定 (ノードアフィニティ)](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-node-affinity-config) - 特定の要件を満たす特殊なノード上の Flex Gateway をホストします。 - [Kubernetes クラスターのアプリケーションのドメイン名の指定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-external-dns) - ExternalDNS を使用して、ドメイン名を介して Kubernetes クラスター上のアプリケーションまたはサービスを公開します。 - [ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class) - Flex Gateway を ​`IngressClass`​ として設定し、​`Ingress`​ リソースを管理します。 - [Flex Gateway と Istio サービスメッシュの統合](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-istio) - Flex Gateway を Istio サービスメッシュと統合し、Anypoint Platform コントロールプレーンから Flex Gateway ポリシー、ログ、メトリクスを活用します。 ## [](#関連情報)関連情報 - [Kubernetes クラスターでのアップグレード](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-upgrade#kubernetes) - [Kubernetes クラスターからのアンインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-uninstall#kubernetes) - [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-getting-started) # Kubernetes デプロイメントの管理 - [Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings) - Flex Gateway を含むポッドの要件を変更します。 - [Flex Gateway レプリカの自動スケーリングおよび名前空間への追加](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-high-availability) - 固定レプリカ数または自動スケールを設定して、追加のレプリカを提供します。 - [Kubernetes での Flex Gateway デプロイメントのノード選択の設定 (ノードアフィニティ)](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-node-affinity-config) - 特定の要件を満たす特殊なノード上の Flex Gateway をホストします。 - [Kubernetes クラスターのアプリケーションのドメイン名の指定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-external-dns) - ExternalDNS を使用して、ドメイン名を介して Kubernetes クラスター上のアプリケーションまたはサービスを公開します。 - [ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class) - Flex Gateway を ​`IngressClass`​ として設定し、​`Ingress`​ リソースを管理します。 - [Flex Gateway と Istio サービスメッシュの統合](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-istio) - Flex Gateway を Istio サービスメッシュと統合し、Anypoint Platform コントロールプレーンから Flex Gateway ポリシー、ログ、メトリクスを活用します。 ## [](#関連情報)関連情報 - [Kubernetes クラスターでのアップグレード](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-upgrade#kubernetes) - [Kubernetes クラスターからのアンインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-uninstall#kubernetes) - [Kubernetes クラスターでの Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-getting-started) # Kubernetes デプロイメントの管理 - [Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings) - Flex Gateway を含むポッドの要件を変更します。 - [Flex Gateway レプリカの自動スケーリングおよび名前空間への追加](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-high-availability) - 固定レプリカ数または自動スケールを設定して、追加のレプリカを提供します。 - [Kubernetes での Flex Gateway デプロイメントのノード選択の設定 (ノードアフィニティ)](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-node-affinity-config) - 特定の要件を満たす特殊なノード上の Flex Gateway をホストします。 - [Kubernetes クラスターのアプリケーションのドメイン名の指定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-external-dns) - ExternalDNS を使用して、ドメイン名を介して Kubernetes クラスター上のアプリケーションまたはサービスを公開します。 - [ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class) - Flex Gateway を ​`IngressClass`​ として設定し、​`Ingress`​ リソースを管理します。 - [Flex Gateway と Istio サービスメッシュの統合](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-istio) - Flex Gateway を Istio サービスメッシュと統合し、Anypoint Platform コントロールプレーンから Flex Gateway ポリシー、ログ、メトリクスを活用します。 ## [](#関連情報)関連情報 - [Kubernetes クラスターでのアップグレード](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-upgrade#kubernetes) - [Kubernetes クラスターからのアンインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-uninstall#kubernetes) - [Kubernetes クラスターでの自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-getting-started) # Linux サービスのトラブルシューティング 以下のトピックでは、サービスの問題の考えられる原因とトラブルシューティング方法について説明します。 - [Flex Gateway サービスが実行できない](#flex-gateway-service-failed-to-run) - [その他のサービスが実行できない](#other-services-failed-to-run) ## [](#flex-gateway-service-failed-to-run)Flex Gateway サービスが実行できない `systemctl list-units flex-gateway*`​ コマンドの実行後、​`flex-gateway.service`​ の状況に ​`failed`​ と表示されます。 ### [](#診断)診断 サービスの問題を診断するには、次のコマンドを実行します。 ```ssh journalctl -u flex-gateway ``` #### [](#エラー-1-panic-could-not-read-platform-configuration-パニック-プラットフォーム設定を読み込めませんでした)エラー 1: 「Panic: could not read platform configuration (パニック: プラットフォーム設定を読み込めませんでした)」 `journalctl`​ コマンドの出力には次の行が含まれます。 ```ssh flex-agent[3253]: panic: could not read platform configuration: open : no such file or directory ``` この問題は、登録時に作成されたファイルに対して ​`chmod`​ を実行することで解決できます。 ## [](#other-services-failed-to-run)その他のサービスが実行できない 該当のエラーが表示されない場合、Flex Gateway を再起動します。 ```ssh sudo ldconfig sudo systemctl restart flex-gateway ``` # Linux サービスのトラブルシューティング 以下のトピックでは、サービスの問題の考えられる原因とトラブルシューティング方法について説明します。 - [Flex Gateway サービスが実行できない](#flex-gateway-service-failed-to-run) - [その他のサービスが実行できない](#other-services-failed-to-run) ## [](#flex-gateway-service-failed-to-run)Flex Gateway サービスが実行できない `systemctl list-units flex-gateway*`​ コマンドの実行後、​`flex-gateway.service`​ の状況に ​`failed`​ と表示されます。 ### [](#診断)診断 サービスの問題を診断するには、次のコマンドを実行します。 ```ssh journalctl -u flex-gateway ``` #### [](#エラー-1-panic-could-not-read-platform-configuration-パニック-プラットフォーム設定を読み込めませんでした)エラー 1: 「Panic: could not read platform configuration (パニック: プラットフォーム設定を読み込めませんでした)」 `journalctl`​ コマンドの出力には次の行が含まれます。 ```ssh flex-agent[3253]: panic: could not read platform configuration: open : no such file or directory ``` この問題は、登録時に作成されたファイルに対して ​`chmod`​ を実行することで解決できます。 ## [](#other-services-failed-to-run)その他のサービスが実行できない 該当のエラーが表示されない場合、Flex Gateway を再起動します。 ```ssh sudo ldconfig sudo systemctl restart flex-gateway ``` # Linux サービスのトラブルシューティング 以下のトピックでは、サービスの問題の考えられる原因とトラブルシューティング方法について説明します。 - [Flex Gateway サービスが実行できない](#flex-gateway-service-failed-to-run) - [その他のサービスが実行できない](#other-services-failed-to-run) ## [](#flex-gateway-service-failed-to-run)Flex Gateway サービスが実行できない `systemctl list-units flex-gateway*`​ コマンドの実行後、​`flex-gateway.service`​ の状況に ​`failed`​ と表示されます。 ### [](#診断)診断 サービスの問題を診断するには、次のコマンドを実行します。 ```ssh journalctl -u flex-gateway ``` #### [](#エラー-1-panic-could-not-read-platform-configuration-パニック-プラットフォーム設定を読み込めませんでした)エラー 1: 「Panic: could not read platform configuration (パニック: プラットフォーム設定を読み込めませんでした)」 `journalctl`​ コマンドの出力には次の行が含まれます。 ```ssh flex-agent[3253]: panic: could not read platform configuration: open : no such file or directory ``` この問題は、登録時に作成されたファイルに対して ​`chmod`​ を実行することで解決できます。 ## [](#other-services-failed-to-run)その他のサービスが実行できない 該当のエラーが表示されない場合、Flex Gateway を再起動します。 ```ssh sudo ldconfig sudo systemctl restart flex-gateway ``` # Linux 権限のトラブルシューティング Flex Gateway に関する情報へのアクセスを制限できるように、Linux デプロイメントで次の ​`flexctl`​ コマンドはルートユーザーと ​`flex`​ ユーザーグループのユーザーしか実行できません。 - `flexctl dump` - `flexctl version` - `flexctl check connections` - `flexctl probe` - `flexctl registration inspect`​ (​`--file`​ フラグなしで実行する場合) これらのコマンドを実行するには 2 つのオプションがあります。 - [flex ユーザーグループへのユーザーの追加](#add-user-to-flex-group) - [ルートユーザーとしての実行](#run-as-root-user) ## [](#add-user-to-flex-group)flex ユーザーグループへのユーザーの追加 `flex`​ ユーザーグループへのユーザーの追加は永続的な解決策であり、ユーザーの追加後は操作が不要になります。​`flex`​ ユーザーグループに現在のユーザーを追加するには次のコマンドを実行します。 ```ssh sudo usermod -a -G flex $USER ``` コマンドの実行後に、ユーザーが ​`flexctl`​ コマンドの使用を開始するには再び VM にログインする必要があります。 ## [](#run-as-root-user)ルートユーザーとしての実行 `flexctl`​ コマンドと一緒に ​`sudo`​ コマンドを実行するのが Flex Gateway 情報に最短でアクセスする方法です。ただし、ユーザーが ​`flex`​ ユーザーグループの一員でない場合、​`flexctl`​ コマンドを実行するたびに ​`sudo`​ コマンドを実行する必要があります。 ```ssh sudo flexctl ``` `sudo flexctl dump`​ コマンドを実行すると、ルートユーザーは作成されたダンプファイルのオーナーになります。現在のユーザーがルートユーザーでない場合、そのユーザーはダンプされたファイルを表示できません。ファイルを表示するには、次のコマンドを実行してファイルのオーナーを変更します。 ```ssh sudo chown $USER *.json ``` ## [](#関連情報)関連情報 - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-admin-api) # Linux 権限のトラブルシューティング Flex Gateway に関する情報へのアクセスを制限できるように、Linux デプロイメントで次の ​`flexctl`​ コマンドはルートユーザーと ​`flex`​ ユーザーグループのユーザーしか実行できません。 - `flexctl dump` - `flexctl version` - `flexctl check connections` - `flexctl probe` - `flexctl registration inspect`​ (​`--file`​ フラグなしで実行する場合) これらのコマンドを実行するには 2 つのオプションがあります。 - [flex ユーザーグループへのユーザーの追加](#add-user-to-flex-group) - [ルートユーザーとしての実行](#run-as-root-user) ## [](#add-user-to-flex-group)flex ユーザーグループへのユーザーの追加 `flex`​ ユーザーグループへのユーザーの追加は永続的な解決策であり、ユーザーの追加後は操作が不要になります。​`flex`​ ユーザーグループに現在のユーザーを追加するには次のコマンドを実行します。 ```ssh sudo usermod -a -G flex $USER ``` コマンドの実行後に、ユーザーが ​`flexctl`​ コマンドの使用を開始するには再び VM にログインする必要があります。 ## [](#run-as-root-user)ルートユーザーとしての実行 `flexctl`​ コマンドと一緒に ​`sudo`​ コマンドを実行するのが Flex Gateway 情報に最短でアクセスする方法です。ただし、ユーザーが ​`flex`​ ユーザーグループの一員でない場合、​`flexctl`​ コマンドを実行するたびに ​`sudo`​ コマンドを実行する必要があります。 ```ssh sudo flexctl ``` `sudo flexctl dump`​ コマンドを実行すると、ルートユーザーは作成されたダンプファイルのオーナーになります。現在のユーザーがルートユーザーでない場合、そのユーザーはダンプされたファイルを表示できません。ファイルを表示するには、次のコマンドを実行してファイルのオーナーを変更します。 ```ssh sudo chown $USER *.json ``` ## [](#関連情報)関連情報 - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-admin-api) # Linux 権限のトラブルシューティング Flex Gateway に関する情報へのアクセスを制限できるように、Linux デプロイメントで次の ​`flexctl`​ コマンドはルートユーザーと ​`flex`​ ユーザーグループのユーザーしか実行できません。 - `flexctl dump` - `flexctl version` - `flexctl check connections` - `flexctl probe` - `flexctl registration inspect`​ (​`--file`​ フラグなしで実行する場合) これらのコマンドを実行するには 2 つのオプションがあります。 - [flex ユーザーグループへのユーザーの追加](#add-user-to-flex-group) - [ルートユーザーとしての実行](#run-as-root-user) ## [](#add-user-to-flex-group)flex ユーザーグループへのユーザーの追加 `flex`​ ユーザーグループへのユーザーの追加は永続的な解決策であり、ユーザーの追加後は操作が不要になります。​`flex`​ ユーザーグループに現在のユーザーを追加するには次のコマンドを実行します。 ```ssh sudo usermod -a -G flex $USER ``` コマンドの実行後に、ユーザーが ​`flexctl`​ コマンドの使用を開始するには再び VM にログインする必要があります。 ## [](#run-as-root-user)ルートユーザーとしての実行 `flexctl`​ コマンドと一緒に ​`sudo`​ コマンドを実行するのが Flex Gateway 情報に最短でアクセスする方法です。ただし、ユーザーが ​`flex`​ ユーザーグループの一員でない場合、​`flexctl`​ コマンドを実行するたびに ​`sudo`​ コマンドを実行する必要があります。 ```ssh sudo flexctl ``` `sudo flexctl dump`​ コマンドを実行すると、ルートユーザーは作成されたダンプファイルのオーナーになります。現在のユーザーがルートユーザーでない場合、そのユーザーはダンプされたファイルを表示できません。ファイルを表示するには、次のコマンドを実行してファイルのオーナーを変更します。 ```ssh sudo chown $USER *.json ``` ## [](#関連情報)関連情報 - [CLI を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-admin-api) # MCP サポートポリシー

ポリシー名

MCP サポート

Summary (概要)

MCP サポートを Flex Gateway MCP サーバーインスタンスに追加します。MCP サーバーインスタンスを適切に機能させるには、このポリシーが必要です。

カテゴリ

MCP

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

このポリシーの戻りコードは存在しません。
このポリシーでは、モデルコンテキストプロトコル (MCP) バージョン 2025-06-18 以前がサポートされます。MCP についての詳細は、 「MCP Specification (MCP 仕様)」​を参照してください。
## [](#概要)概要 MCP サポートポリシーでは、MCP サーバーインスタンスをサポートするように Flex Gateway を設定します。インスタンスを正常に機能させるには、このポリシーをすべての MCP サーバーインスタンスに適用する必要があります。このポリシーを適用しないと、Flex Gateway によってランタイムエラーがスローされる場合があります。 このポリシーの設定パラメーターはありません。
このポリシーはポリシー順序の最初に配置する必要があります。このポリシーを最初に配置しないと、Flex Gateway によってランタイムエラーがスローされる場合があります。
### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード MCP サポートポリシーはローカルモードではサポートされません。 # MCP サポートポリシー

ポリシー名

MCP サポート

Summary (概要)

MCP サポートを Flex Gateway MCP サーバーインスタンスに追加します。MCP サーバーインスタンスを適切に機能させるには、このポリシーが必要です。

カテゴリ

MCP

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 MCP サポートポリシーでは、MCP サーバーインスタンスをサポートするように Flex Gateway を設定します。インスタンスを正常に機能させるには、このポリシーをすべての MCP サーバーインスタンスに適用する必要があります。このポリシーを適用しないと、Flex Gateway によってランタイムエラーがスローされる場合があります。 このポリシーの設定パラメーターはありません。
このポリシーはポリシー順序の最初に配置する必要があります。このポリシーを最初に配置しないと、Flex Gateway によってランタイムエラーがスローされる場合があります。
### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード MCP サポートポリシーはローカルモードではサポートされません。 # MCP スキーマ検証ポリシー

ポリシー名

MCP スキーマ検証

概要

MCP 要求を検証して MCP 仕様に準拠していることを確認します。

カテゴリ

MCP

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
このポリシーでは、モデルコンテキストプロトコル (MCP) バージョン 2025-06-18 以前がサポートされます。MCP についての詳細は、 「MCP Specification (MCP 仕様)」​を参照してください。
## [](#概要)概要 MCP スキーマ検証ポリシーでは、MCP サーバーへのすべての JSON RPC 要求が MCP スキーマ (MCP ​2024\_11\_05​ 標準) に準拠していることを検証します。検証に失敗すると、ポリシー違反を報告します。 このポリシーの設定パラメーターはありません。 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード MCP スキーマ検証ポリシーはローカルモードではサポートされません。 # MCP スキーマ検証ポリシー

ポリシー名

MCP スキーマ検証

概要

MCP 要求を検証して MCP 仕様に準拠していることを確認します。

カテゴリ

MCP

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード
## [](#概要)概要 MCP スキーマ検証ポリシーでは、MCP サーバーへのすべての JSON RPC 要求が MCP スキーマ (MCP ​2024\_11\_05​ 標準) に準拠していることを検証します。検証に失敗すると、ポリシー違反を報告します。 このポリシーの設定パラメーターはありません。 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード MCP スキーマ検証ポリシーはローカルモードではサポートされません。 # MCP 属性ベースのアクセス制御ポリシー

ポリシー名

MCP 属性ベースのアクセス制御

概要

層、IP、ヘッダー、クレームなどのユーザー情報に基づいてツール、リソース、プロンプトへのアクセスを制御します。

カテゴリ

MCP

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

400 - 無効なトークン
このポリシーでは、モデルコンテキストプロトコル (MCP) バージョン 2025-06-18 以前がサポートされます。MCP についての詳細は、 「MCP Specification (MCP 仕様)」​を参照してください。
## [](#概要)概要 MCP 属性ベースのアクセス制御ポリシーでは、ランク、IP、ヘッダー、クレームなどのユーザー情報に基づいてサーバーツール、リソース、プロンプトへのアクセスを制御します。アクセスルールを定義するには [Cedar ポリシー言語](https://docs.cedarpolicy.com/)​を使用します。 このポリシーを使用するには、MCP 属性ベースのアクセス制御ポリシーの前に別の認証ポリシーを適用する必要があります。詳しい案内については、​[Cedar ルールの記述](#writing-cedar-rules)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード MCP 属性ベースのアクセス制御ポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Rules (ルール)

Cedar ポリシー言語​で記述されたツール、リソース、プロンプトへのアクセスを制御するルール。

Cedar Expression (Cedar 式)

アクセスルールを定義する Cedar 式。例: permit(principal,action == Action::"tools/call​ や ​resource == Tool::"calculator");​。要求によって提供される Cedar バインドについての詳細は、​Cedar ルールの記述​を参照してください。

認証種別

このポリシーの前に適用される認証ポリシーによって使用される認証の種別。
## [](#writing-cedar-rules)Cedar ルールの記述 MCP 属性ベースのアクセス制御ポリシーの前に、内部認証ポリシーまたはカスタム認証ポリシーを適用する必要があります。 ### [](#内部認証ポリシー)内部認証ポリシー 適用したポリシーは、使用可能な Cedar ​`principal`​ バインドに影響します。 - 複数のポリシーでクライアント ID を検証できます: - [クライアント ID 適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-client-id-enforcement) - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-rate-limiting-sla) - [OAuth 2.0 トークンイントロスペクションポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-oauth-token-introspection) (クライアント ID 適用が設定済みの場合) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-openid-token-enforcement) (クライアント ID 適用が設定済みの場合) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-jwt-validation) (クライアント ID 適用が設定済みの場合) クライアント ID を検証するポリシーでは次の Cedar バインドが提供されます: - `principal.client_name`​: コントラクトのクライアントアプリケーションの名前 - `principal.principal`​: コントラクトのクライアントアプリケーションの ID - `principal.properties.slaId`​: コントラクトに割り当てられた SLA ID - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-jwt-validation): - `principal.properties.claims.`​: JWT によって提供されるすべてのクレーム - 複数のポリシーで基本認証ログイン情報を検証します: - [基本認証: 簡易ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-basic-auth-simple) - [基本認証: LDAP ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-basic-auth-ldap) 基本認証ログイン情報を検証するポリシーでは次の Cedar バインドが提供されます: - `principal.principal`​: 基本認証ユーザーとして渡されるユーザー名 ### [](#カスタム認証ポリシー)カスタム認証ポリシー カスタム認証ポリシーでは、​`Authentication`​ injectable を使用してカスタムポリシーでの認証を行う必要があります。​`Authentication`​ injectable を設定するには、[Accessing Request Authentication Information](https://docs.mulesoft.com/pdk/latest/policies-pdk-configure-features-authentication)を参照してください。 Rust ​`AuthenticationData`​ 構造の場合: ```rust pub struct AuthenticationData { pub principal: Option, pub client_id: Option, pub client_name: Option, pub properties: Value, } ``` `AuthenticationData`​ パラメーターは次の Cedar バインドにマップします: - `principal`​: `principal.principal` - `client_name`​: `principal.client_name` - `properties`​: `principal.properties.*` # MCP 属性ベースのアクセス制御ポリシー

ポリシー名

MCP 属性ベースのアクセス制御

概要

層、IP、ヘッダー、クレームなどのユーザー情報に基づいてツール、リソース、プロンプトへのアクセスを制御します。

カテゴリ

MCP

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

400 - 無効なトークン
## [](#概要)概要 MCP 属性ベースのアクセス制御ポリシーでは、ランク、IP、ヘッダー、クレームなどのユーザー情報に基づいてサーバーツール、リソース、プロンプトへのアクセスを制御します。アクセスルールを定義するには [Cedar ポリシー言語](https://docs.cedarpolicy.com/)​を使用します。 このポリシーを使用するには、MCP 属性ベースのアクセス制御ポリシーの前に別の認証ポリシーを適用する必要があります。詳しい案内については、​[Cedar ルールの記述](#writing-cedar-rules)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード MCP 属性ベースのアクセス制御ポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

Rules (ルール)

Cedar ポリシー言語​で記述されたツール、リソース、プロンプトへのアクセスを制御するルール。

Cedar Expression (Cedar 式)

アクセスルールを定義する Cedar 式。例: permit(principal,action == Action::"tools/call​ や ​resource == Tool::"calculator");​。要求によって提供される Cedar バインドについての詳細は、​Cedar ルールの記述​を参照してください。

認証種別

このポリシーの前に適用される認証ポリシーによって使用される認証の種別。
## [](#writing-cedar-rules)Cedar ルールの記述 MCP 属性ベースのアクセス制御ポリシーの前に、内部認証ポリシーまたはカスタム認証ポリシーを適用する必要があります。 ### [](#内部認証ポリシー)内部認証ポリシー 適用したポリシーは、使用可能な Cedar ​`principal`​ バインドに影響します。 - 複数のポリシーでクライアント ID を検証できます: - [クライアント ID 適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-client-id-enforcement) - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-rate-limiting-sla) - [OAuth 2.0 トークンイントロスペクションポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-oauth-token-introspection) (クライアント ID 適用が設定済みの場合) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-openid-token-enforcement) (クライアント ID 適用が設定済みの場合) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-jwt-validation) (クライアント ID 適用が設定済みの場合) クライアント ID を検証するポリシーでは次の Cedar バインドが提供されます: - `principal.client_name`​: コントラクトのクライアントアプリケーションの名前 - `principal.principal`​: コントラクトのクライアントアプリケーションの ID - `principal.properties.slaId`​: コントラクトに割り当てられた SLA ID - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-jwt-validation): - `principal.properties.claims.`​: JWT によって提供されるすべてのクレーム - 複数のポリシーで基本認証ログイン情報を検証します: - [基本認証: 簡易ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-basic-auth-simple) - [基本認証: LDAP ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-basic-auth-ldap) 基本認証ログイン情報を検証するポリシーでは次の Cedar バインドが提供されます: - `principal.principal`​: 基本認証ユーザーとして渡されるユーザー名 ### [](#カスタム認証ポリシー)カスタム認証ポリシー カスタム認証ポリシーでは、​`Authentication`​ injectable を使用してカスタムポリシーでの認証を行う必要があります。​`Authentication`​ injectable を設定するには、[Accessing Request Authentication Information](https://docs.mulesoft.com/pdk/latest/policies-pdk-configure-features-authentication)を参照してください。 Rust ​`AuthenticationData`​ 構造の場合: ```rust pub struct AuthenticationData { pub principal: Option, pub client_id: Option, pub client_name: Option, pub properties: Value, } ``` `AuthenticationData`​ パラメーターは次の Cedar バインドにマップします: - `principal`​: `principal.principal` - `client_name`​: `principal.client_name` - `properties`​: `principal.properties.*` # OAuth 2.0 トークンイントロスペクションポリシー

ポリシー名

OAuth 2.0 トークンイントロスペクションポリシー

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.3.0

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 OAuth 2.0 トークンイントロスペクションポリシーを使用すると、Okta、AWS、Azure、Google Cloud Platform などのサードパーティの ID プロバイダー (IdP) を使用して OAuth 2.0 を設定できます。このポリシーでは、Anypoint Platform に外部 IdP サーバーを登録しなくても、OAuth 2.0 認証フレームワークに基づくトークンを認証できます。 このポリシーは、クライアントから保護された API に送信されたトークンを検証し、イントロスペクションエンドポイントがトークンを認証した場合にのみ、バックエンドサーバーへのアクセスを許可します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: oauth2-token-introspection-flex config: introspectionURL: // REQUIRED authorizationValue: // REQUIRED validatedTokenTTL: // OPTIONAL authenticationTimeout: // OPTIONAL skipClientIdValidation: // REQUIRED consumerBy: // REQUIRED exposeHeaders: // OPTIONAL scopes: // OPTIONAL scopeValidationCriteria: // OPTIONAL maxCacheEntries: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

introspectionURL

必須

サードパーティトークンイントロスペクション URL。

authorizationValue

必須

認証サービスから認証を要求する方法。​client_id​ と ​client_secret​ を使用する基本認証文字列、またはベアラートークンを指定します。

validatedTokenTTL

省略可能

600

検証済みトークンのキャッシュ制限。

authenticationTimeout

省略可能

10000

認証サービスへのデータ送信時のタイムアウト。

skipClientIdValidation

必須

false

クライアント ID 適用サポートを有効/無効にします。

consumerBy

必須

ID プロバイダーの ​username​ または ​client_id​ 応答を登録済みプラットフォームの ​client_id​ に関連付けます。​skip_client_id_validation​ が ​true​ の場合は必須です。

exposeHeaders

省略可能

false

scopes

省略可能

""

スペース区切りリスト。

scopeValidationCriteria

省略可能

"AND"

scopes​ 値に適用する条件。有効なパラメーター値は、「AND」または「OR」です。

maxCacheEntries

省略可能

1000
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: oauth2-token-introspection-flex config: introspectionURL: https://my-introspection.com/introspect authorizationValue: Basic am9obkBleGFtcGxlLmNvbTphYmMxMjM= validatedTokenTTL: 600 authenticationTimeout: 10000 skipClientIdValidation: false consumerBy: "client_id" exposeHeaders: true scopes: "profile email shopping" scopeValidationCriteria: "AND" maxCacheEntries: 1000 ``` # OAuth 2.0 トークンイントロスペクションポリシー

ポリシー名

OAuth 2.0 トークンイントロスペクションポリシー

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.3.0

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 OAuth 2.0 トークンイントロスペクションポリシーを使用すると、Okta、AWS、Azure、Google Cloud Platform などのサードパーティの ID プロバイダー (IdP) を使用して OAuth 2.0 を設定できます。このポリシーでは、Anypoint Platform に外部 IdP サーバーを登録しなくても、OAuth 2.0 認証フレームワークに基づくトークンを認証できます。 このポリシーは、クライアントから保護された API に送信されたトークンを検証し、イントロスペクションエンドポイントがトークンを認証した場合にのみ、バックエンドサーバーへのアクセスを許可します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway)Flex Gateway Flex Gateway をランタイムとして使用するときに OAuth 2.0 トークンイントロスペクションを適用するには、YAML 設定ファイルでポリシーを手動で設定する必要があります。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: oauth2-token-introspection-flex config: introspectionURL: // REQUIRED authorizationValue: // REQUIRED validatedTokenTTL: // OPTIONAL authenticationTimeout: // OPTIONAL skipClientIdValidation: // REQUIRED consumerBy: // REQUIRED exposeHeaders: // OPTIONAL scopes: // OPTIONAL scopeValidationCriteria: // OPTIONAL maxCacheEntries: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

introspectionURL

必須

サードパーティトークンイントロスペクション URL。

authorizationValue

必須

認証サービスから認証を要求する方法。​client_id​ と ​client_secret​ を使用する基本認証文字列、またはベアラートークンを指定します。

validatedTokenTTL

省略可能

600

検証済みトークンのキャッシュ制限。

authenticationTimeout

省略可能

10000

認証サービスへのデータ送信時のタイムアウト。

skipClientIdValidation

必須

false

クライアント ID 適用サポートを有効/無効にします。

consumerBy

必須

ID プロバイダーの ​username​ または ​client_id​ 応答を登録済みプラットフォームの ​client_id​ に関連付けます。​skip_client_id_validation​ が ​true​ の場合は必須です。

exposeHeaders

省略可能

false

scopes

省略可能

""

スペース区切りリスト。

scopeValidationCriteria

省略可能

"AND"

scopes​ 値に適用する条件。有効なパラメーター値は、「AND」または「OR」です。

maxCacheEntries

省略可能

1000
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: oauth2-token-introspection-flex config: introspectionURL: https://my-introspection.com/introspect authorizationValue: Basic am9obkBleGFtcGxlLmNvbTphYmMxMjM= validatedTokenTTL: 600 authenticationTimeout: 10000 skipClientIdValidation: false consumerBy: "client_id" exposeHeaders: true scopes: "profile email shopping" scopeValidationCriteria: "AND" maxCacheEntries: 1000 ``` # OAuth 2.0 トークンイントロスペクションポリシー

ポリシー名

OAuth 2.0 トークンイントロスペクションポリシー

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.3.0

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 OAuth 2.0 トークンイントロスペクションポリシーを使用すると、Okta、AWS、Azure、Google Cloud Platform などのサードパーティの ID プロバイダー (IdP) を使用して OAuth 2.0 を設定できます。このポリシーでは、Anypoint Platform に外部 IdP サーバーを登録しなくても、OAuth 2.0 認証フレームワークに基づくトークンを認証できます。 このポリシーは、クライアントから保護された API に送信されたトークンを検証し、イントロスペクションエンドポイントがトークンを認証した場合にのみ、バックエンドサーバーへのアクセスを許可します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: oauth2-token-introspection-flex config: introspectionURL: // REQUIRED authorizationValue: // REQUIRED validatedTokenTTL: // OPTIONAL authenticationTimeout: // OPTIONAL skipClientIdValidation: // REQUIRED consumerBy: // REQUIRED exposeHeaders: // OPTIONAL scopes: // OPTIONAL scopeValidationCriteria: // OPTIONAL maxCacheEntries: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

introspectionURL

必須

サードパーティトークンイントロスペクション URL。

authorizationValue

必須

認証サービスから認証を要求する方法。​client_id​ と ​client_secret​ を使用する基本認証文字列、またはベアラートークンを指定します。

validatedTokenTTL

省略可能

600

検証済みトークンのキャッシュ制限。

authenticationTimeout

省略可能

10000

認証サービスへのデータ送信時のタイムアウト。

skipClientIdValidation

必須

false

クライアント ID 適用サポートを有効/無効にします。

consumerBy

必須

ID プロバイダーの ​username​ または ​client_id​ 応答を登録済みプラットフォームの ​client_id​ に関連付けます。​skip_client_id_validation​ が ​true​ の場合は必須です。

exposeHeaders

省略可能

false

scopes

省略可能

""

スペース区切りリスト。

scopeValidationCriteria

省略可能

"AND"

scopes​ 値に適用する条件。有効なパラメーター値は、「AND」または「OR」です。

maxCacheEntries

省略可能

1000
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: oauth2-token-introspection-flex config: introspectionURL: https://my-introspection.com/introspect authorizationValue: Basic am9obkBleGFtcGxlLmNvbTphYmMxMjM= validatedTokenTTL: 600 authenticationTimeout: 10000 skipClientIdValidation: false consumerBy: "client_id" exposeHeaders: true scopes: "profile email shopping" scopeValidationCriteria: "AND" maxCacheEntries: 1000 ``` # OpenID Connect OAuth 2.0 トークン適用ポリシー

ポリシー名

OpenID Connect OAuth 2.0 トークン適用

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答
## [](#概要)概要 OpenID Connect アクセストークン適用ポリシーは、保護されたリソースへのアクセスを、API アクセス権を持つクライアントアプリケーションに属する有効な Oauth2 トークンを提供する HTTP 要求に制限します。このポリシーはトークンを生成せず、トークンを検証するだけです。 このポリシーは、​[クライアント管理ソリューション](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​として OpenID Connect 動的クライアント登録を使用するように設定されている組織でのみ使用できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: openidconnect-access-token-enforcement-flex config: authenticationTimeout: // OPTIONAL, default: 10000 scopes: // OPTIONAL, default: "" secureTrustStore: // OPTIONAL, default: false scopeValidationCriteria: // OPTIONAL, default: "AND" exposeHeaders: // OPTIONAL, default: false skipClientIdValidation: // OPTIONAL, default: true maxFederationExpirationTime: // OPTIONAL, default: -1 maxCacheSize: // OPTIONAL, default: 1000
パラメーター 必須または省略可能 デフォルト値 説明

authenticationTimeout

省略可能

10000

scopes

省略可能

空の文字列

サポートされるスコープのスペース区切りリスト: read ​write​

secureTrustStore

省略可能

false

scopeValidationCriteria

省略可能

"AND"

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。

exposeHeaders

省略可能

false

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

このパラメーターについての詳細は、​「トークン検証エンドポイント情報の活用」​を参照してください。

skipClientIdValidation

省略可能

true

クライアントアプリケーションの API コントラクト検証をスキップします。​true​ の場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

maxFederationExpirationTime

省略可能

-1

最大有効期限 (秒)。

このパラメーターの詳細は、​「トークンキャッシュ」​を参照してください。

maxCacheSize

省略可能

1000

キャッシュするトークンの数。

このパラメーターの詳細は、​「トークンキャッシュ」​を参照してください。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: openidconnect-access-token-enforcement-flex config: authenticationTimeout: 10000 scopes: read write secureTrustStore: false scopeValidationCriteria: OR exposeHeaders: true skipClientIdValidation: false ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 例

Scopes (スコープ)

サポートされるスコープのカンマ区切りリストを表示します。

READ, WRITE, READ and WRITE

Scope Validation Criteria (スコープ検証条件)

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。 この値は、​Contains all scopes​ と ​Contains any scope​ です。

[Contains all scopes (すべてのスコープを含む)] 値が選択されている場合、スコープ ​READ​ と ​WRITE​ を持つトークンが受け入れられます。[Contains any scopes (任意のスコープを含む)] 値が選択されている場合、スコープ ​READ, WRITE, and READ AND WRITE​ を持つトークンが受け入れられます。

Expose Headers (ヘッダーを公開)

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

Skip Client Id Validation (クライアント ID 検証をスキップ)

クライアントアプリケーションの API コントラクト検証をスキップします。

選択した場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

Authentication request timeout (認証要求タイムアウト)

アクセストークン検証エンドポイントを認証するときに、応答を待機する最大時間 (ミリ秒単位) を設定します。

10000
## [](#how-this-policy-works)ポリシーのしくみ 次の図は、OpenID Connect アクセストークン適用ポリシーワークフローを示しています。 ![PingFederate ポリシーを介して API とやり取りするユーザーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/open-id-policy-workflow.png) この図には次の動作が示されています。 1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。 2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。 3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。 4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。 5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。 ### [](#leveraging-TVE-information)トークン検証エンドポイント情報の活用 トークン検証エンドポイントで正常にトークンが検証されると、特定の情報 (OpenID Connect の設定可能な項目など) がポリシーに返されます。 次の例は、認証サーバーからのトークン検証応答を示しています: ```text { "uid":"john.doe", "mail":"john.doe@example.com" "token_type":"Bearer", "exp": 1516239022 "alias" : ["Jhon", "Jhonny", "Mr Doe"], "address" : { "city": "london", "road": “abbey road" } } ``` OAuth プロバイダーによって返された項目はポリシーによって処理され、フロー全体に伝播され、アクセスを要求しているアプリケーションが HTTP リクエスターを使用している場合は最終的にバックエンドに公開されます。 ### [](#token-caching)ローカルモードでのトークンキャッシュ システムがトークンを検証すると、そのトークンは (デフォルトで) 期限切れになるまでキャッシュされるため、ポリシーのパフォーマンスが向上します。失効したトークンなどの特定のケースでは、キャッシュを最小限に抑えたり無効にしたりできます。 検証エンドポイントは、トークンの有効期限などの複数のプロパティをポリシーに送信します。有効期限情報がない場合、トークンはキャッシュされません。 トークンのキャッシュにかかる時間を制御するには、トークン検証エンドポイントに対して再検証を試みる前に、宣言型設定ファイルで次のパラメーターを設定します。 - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxFederationExpirationTime: このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。 同時にキャッシュできるトークンの数を制御するには、宣言型設定ファイルで次のパラメーターを設定します。 - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxCacheSize: ### [](#token-validation-endpoint-authentication)トークン検証エンドポイント認証 指定されたトークンの検証が完了すると、ポリシーは要求を検証エンドポイントに送信します。次に、ポリシーは OAuth 2.0 認証フレームワーク仕様の「Token Introspection Client (トークンイントロスペクションクライアント)」セクションに従って、アクセス管理のクライアントプロバイダー設定からログイン情報を取得します。これらのログイン情報は、 [OAuth 2.0 認証フレームワーク仕様の「Client Authentication (クライアント認証)」セクション](https://tools.ietf.org/html/rfc6749#section-2.3)​で指定されているようにリクエストボディで送信されます。 トークン検証エンドポイントの認証方法は、現在サポートされていません。 ## [](#expose-headers-ヘッダーを公開-オプションの設定)Expose Headers (ヘッダーを公開) オプションの設定 ポリシーで ​`Expose Headers`​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。 項目ごとに、元の保護されたリソースへの要求が「X-AGW- + =」形式を使用する HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。 ```text X-AGW-uid=john.doe X-AGW-mail=john.doe@example.com X-AGW-token_type=Bearer ``` 伝播されたプロパティには、​`scope`​、​`exp`​ オブジェクトおよび配列は含まれません。 フロー内の以降の処理では、検証エンドポイントからの元の解析していない応答を使用できます。情報は認証オブジェクトに保存されます。 たとえば、​`mail`​ 項目がポリシーに返される場合、次の DataWeave 2.0 式を使用して項目の値にアクセスできます。 `#[authentication.properties.userProperties.mail]` 次の DataWeave 2.0 式を使用して、OAuth2 トークンのクライアント ID を取得できます。 `#[authentication.principal]` ## [](#faq)FAQ **API に適用するポリシーのリストに OpenID Connect アクセストークン適用ポリシーが表示されない。** ポリシーリストにポリシーが表示されない場合、アクセス管理で OpenID クライアントプロバイダーを設定していることを確認します。詳細は、​[「OpenID Connect クライアント管理を設定する」](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​を参照してください。​[複数の IDP](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)​ を使用している場合、API で OpenID Connect クライアントが正しく設定されていることを確認します。 **ポリシーで OAuth 2.0 トークンを生成できますか?** いいえ。 ポリシーはトークンの検証のみを行います。 **OAuth トークンはどのようにキャッシュされますか?** OAuth 2.0 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。 **OpenID Connect アクセストークン適用ポリシーを設定した後にレート制限 SLA ポリシーを設定できますか?** はい、できます。OpenID Connect アクセストークン適用ポリシーの後にレート制限 SLA ポリシーを適用し、次の DataWeave 2.0 式を使用して \[​`Client ID Expression`​ (クライアント ID 式)\] の値を指定します。 `#[authentication.principal]` リクエスターの ID はすでに OpenID Connect アクセストークン適用ポリシーで検証されているため、\[​`Client Secret Expression`​ (クライアントシークレット式)\] 項目は空のままにできます。 # OpenID Connect OAuth 2.0 トークン適用ポリシー

ポリシー名

OpenID Connect OAuth 2.0 トークン適用

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答
## [](#概要)概要 OpenID Connect アクセストークン適用ポリシーは、保護されたリソースへのアクセスを、API アクセス権を持つクライアントアプリケーションに属する有効な Oauth2 トークンを提供する HTTP 要求に制限します。このポリシーはトークンを生成せず、トークンを検証するだけです。 このポリシーは、​[クライアント管理ソリューション](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​として OpenID Connect 動的クライアント登録を使用するように設定されている組織でのみ使用できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して OpenID Connect アクセストークン適用ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: openidconnect-access-token-enforcement-flex config: authenticationTimeout: // OPTIONAL, default: 10000 scopes: // OPTIONAL, default: "" secureTrustStore: // OPTIONAL, default: false scopeValidationCriteria: // OPTIONAL, default: "AND" exposeHeaders: // OPTIONAL, default: false skipClientIdValidation: // OPTIONAL, default: true maxFederationExpirationTime: // OPTIONAL, default: -1 maxCacheSize: // OPTIONAL, default: 1000
パラメーター 必須または省略可能 デフォルト値 説明

authenticationTimeout

省略可能

10000

scopes

省略可能

空の文字列

サポートされるスコープのスペース区切りリスト: read ​write​

secureTrustStore

省略可能

false

scopeValidationCriteria

省略可能

"AND"

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。

exposeHeaders

省略可能

false

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

このパラメーターについての詳細は、​「トークン検証エンドポイント情報の活用」​を参照してください。

skipClientIdValidation

省略可能

true

クライアントアプリケーションの API コントラクト検証をスキップします。​true​ の場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

maxFederationExpirationTime

省略可能

-1

最大有効期限 (秒)。

このパラメーターの詳細は、​「トークンキャッシュ」​を参照してください。

maxCacheSize

省略可能

1000

キャッシュするトークンの数。

このパラメーターの詳細は、​「トークンキャッシュ」​を参照してください。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: openidconnect-access-token-enforcement-flex config: authenticationTimeout: 10000 scopes: read write secureTrustStore: false scopeValidationCriteria: OR exposeHeaders: true skipClientIdValidation: false ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からポリシーを API に適用するときに、パラメーターのリストが表示されます。 #### [](#flex-gateway-のパラメーターの設定)Flex Gateway のパラメーターの設定 次のパラメーターが表示されます。
要素 説明 例

Scopes (スコープ)

サポートされるスコープのカンマ区切りリストを表示します。

READ, WRITE, READ and WRITE

Scope Validation Criteria (スコープ検証条件)

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。 この値は、​Contains all scopes​ と ​Contains any scope​ です。

[Contains all scopes (すべてのスコープを含む)] 値が選択されている場合、スコープ ​READ​ と ​WRITE​ を持つトークンが受け入れられます。[Contains any scopes (任意のスコープを含む)] 値が選択されている場合、スコープ ​READ, WRITE, and READ AND WRITE​ を持つトークンが受け入れられます。

Expose Headers (ヘッダーを公開)

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

Skip Client Id Validation (クライアント ID 検証をスキップ)

クライアントアプリケーションの API コントラクト検証をスキップします。

選択した場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

Authentication request timeout (認証要求タイムアウト)

アクセストークン検証エンドポイントを認証するときに、応答を待機する最大時間 (ミリ秒単位) を設定します。

10000
#### [](#非-mule-アプリケーションのパラメーターの設定-anypoint-service-mesh)非 Mule アプリケーションのパラメーターの設定 (Anypoint Service Mesh) Anypoint Service Mesh によって管理される非 Mule アプリケーションの場合、次のパラメーターが表示されます。
要素 説明 例

Scopes (スコープ)

サポートされるスコープのカンマ区切りリストを表示します。

READ​、​WRITE​、​READ AND WRITE

Skip Client Id Validation (クライアント ID 検証をスキップ)

クライアントアプリケーションの API コントラクト検証をスキップします。

選択した場合、​「ポリシーのしくみ」​セクションの図のステップ 4 はスキップされます。
## [](#how-this-policy-works)ポリシーのしくみ 次の図は、OpenID Connect アクセストークン適用ポリシーワークフローを示しています。 ![OpenID Connect OAuth 2.0 トークン適用ワークフロー](/mulesoft/current/ja-jp/gateway/1.8/_images/open-id-policy-workflow.png) この図には次の動作が示されています。 1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。 2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。 3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。 4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。 5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。 ### [](#leveraging-TVE-information)トークン検証エンドポイント情報の活用 トークン検証エンドポイントで正常にトークンが検証されると、特定の情報 (OpenID Connect の設定可能な項目など) がポリシーに返されます。 次の例は、認証サーバーからのトークン検証応答を示しています: ```text { "uid":"john.doe", "mail":"john.doe@example.com" "token_type":"Bearer", "exp": 1516239022 "alias" : ["Jhon", "Jhonny", "Mr Doe"], "address" : { "city": "london", "road": “abbey road" } } ``` OAuth プロバイダーによって返された項目はポリシーによって処理され、フロー全体に伝播され、アクセスを要求しているアプリケーションが HTTP リクエスターを使用している場合は最終的にバックエンドに公開されます。 ### [](#token-caching)ローカルモードでのトークンキャッシュ システムがトークンを検証すると、そのトークンは (デフォルトで) 期限切れになるまでキャッシュされるため、ポリシーのパフォーマンスが向上します。失効したトークンなどの特定のケースでは、キャッシュを最小限に抑えたり無効にしたりできます。 検証エンドポイントは、トークンの有効期限などの複数のプロパティをポリシーに送信します。有効期限情報がない場合、トークンはキャッシュされません。 トークンのキャッシュにかかる時間を制御するには、トークン検証エンドポイントに対して再検証を試みる前に、宣言型設定ファイルで次のパラメーターを設定します。 - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxFederationExpirationTime: このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。 同時にキャッシュできるトークンの数を制御するには、宣言型設定ファイルで次のパラメーターを設定します。 - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxCacheSize: ### [](#token-validation-endpoint-authentication)トークン検証エンドポイント認証 指定されたトークンの検証が完了すると、ポリシーは要求を検証エンドポイントに送信します。次に、ポリシーは OAuth 2.0 認証フレームワーク仕様の「Token Introspection Client (トークンイントロスペクションクライアント)」セクションに従って、アクセス管理のクライアントプロバイダー設定からログイン情報を取得します。これらのログイン情報は、 [OAuth 2.0 認証フレームワーク仕様の「Client Authentication (クライアント認証)」セクション](https://tools.ietf.org/html/rfc6749#section-2.3)​で指定されているようにリクエストボディで送信されます。 トークン検証エンドポイントの認証方法は、現在サポートされていません。 ## [](#expose-headers-ヘッダーを公開-オプションの設定)Expose Headers (ヘッダーを公開) オプションの設定 ポリシーで ​`Expose Headers`​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。 項目ごとに、元の保護されたリソースへの要求が「X-AGW- + =」形式を使用する HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。 ```text X-AGW-uid=john.doe X-AGW-mail=john.doe@example.com X-AGW-token_type=Bearer ``` 伝播されたプロパティには、​`scope`​、​`exp`​ オブジェクトおよび配列は含まれません。 フロー内の以降の処理では、検証エンドポイントからの元の解析していない応答を使用できます。情報は認証オブジェクトに保存されます。 たとえば、​`mail`​ 項目がポリシーに返される場合、次の DataWeave 2.0 式を使用して項目の値にアクセスできます。 `#[authentication.properties.userProperties.mail]` 次の DataWeave 2.0 式を使用して、OAuth2 トークンのクライアント ID を取得できます。 `#[authentication.principal]` ## [](#faq)FAQ **API に適用するポリシーのリストに OpenID Connect アクセストークン適用ポリシーが表示されない。** ポリシーリストにポリシーが表示されない場合、アクセス管理で OpenID クライアントプロバイダーを設定していることを確認します。詳細は、​[「OpenID Connect クライアント管理を設定する」](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​を参照してください。​[複数の IDP](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)​ を使用している場合、API で OpenID Connect クライアントが正しく設定されていることを確認します。 **ポリシーで OAuth 2.0 トークンを生成できますか?** いいえ。 ポリシーはトークンの検証のみを行います。 **OAuth トークンはどのようにキャッシュされますか?** OAuth 2.0 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。 **OpenID Connect アクセストークン適用ポリシーを設定した後にレート制限 SLA ポリシーを設定できますか?** はい、できます。OpenID Connect アクセストークン適用ポリシーの後にレート制限 SLA ポリシーを適用し、次の DataWeave 2.0 式を使用して \[​`Client ID Expression`​ (クライアント ID 式)\] の値を指定します。 `#[authentication.principal]` リクエスターの ID はすでに OpenID Connect アクセストークン適用ポリシーで検証されているため、\[​`Client Secret Expression`​ (クライアントシークレット式)\] 項目は空のままにできます。 # OpenID Connect OAuth 2.0 トークン適用ポリシー

ポリシー名

OpenID Connect OAuth 2.0 トークン適用

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - 無効なトークン

401 - 未承認または認証サーバーへの接続時にエラー

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報

500 - 認証サーバーからの不正応答
## [](#概要)概要 OpenID Connect アクセストークン適用ポリシーは、保護されたリソースへのアクセスを、API アクセス権を持つクライアントアプリケーションに属する有効な Oauth2 トークンを提供する HTTP 要求に制限します。このポリシーはトークンを生成せず、トークンを検証するだけです。 このポリシーは、​[クライアント管理ソリューション](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​として OpenID Connect 動的クライアント登録を使用するように設定されている組織でのみ使用できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: openidconnect-access-token-enforcement-flex config: authenticationTimeout: // OPTIONAL, default: 10000 scopes: // OPTIONAL, default: "" secureTrustStore: // OPTIONAL, default: false scopeValidationCriteria: // OPTIONAL, default: "AND" exposeHeaders: // OPTIONAL, default: false skipClientIdValidation: // OPTIONAL, default: true maxFederationExpirationTime: // OPTIONAL, default: -1 maxCacheSize: // OPTIONAL, default: 1000
パラメーター 必須または省略可能 デフォルト値 説明

authenticationTimeout

省略可能

10000

scopes

省略可能

空の文字列

サポートされるスコープのスペース区切りリスト: read ​write​

secureTrustStore

省略可能

false

scopeValidationCriteria

省略可能

"AND"

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。

exposeHeaders

省略可能

false

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

このパラメーターについての詳細は、​「トークン検証エンドポイント情報の活用」​を参照してください。

skipClientIdValidation

省略可能

true

クライアントアプリケーションの API コントラクト検証をスキップします。​true​ の場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

maxFederationExpirationTime

省略可能

-1

最大有効期限 (秒)。

このパラメーターの詳細は、​「トークンキャッシュ」​を参照してください。

maxCacheSize

省略可能

1000

キャッシュするトークンの数。

このパラメーターの詳細は、​「トークンキャッシュ」​を参照してください。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: openidconnect-access-token-enforcement-flex config: authenticationTimeout: 10000 scopes: read write secureTrustStore: false scopeValidationCriteria: OR exposeHeaders: true skipClientIdValidation: false ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 例

Scopes (スコープ)

サポートされるスコープのカンマ区切りリストを表示します。

READ, WRITE, READ and WRITE

Scope Validation Criteria (スコープ検証条件)

トークンに定義済みのすべてのスコープが含まれる必要があるか、1 つのみ含まれる必要があるかを決定します。 この値は、​Contains all scopes​ と ​Contains any scope​ です。

[Contains all scopes (すべてのスコープを含む)] 値が選択されている場合、スコープ ​READ​ と ​WRITE​ を持つトークンが受け入れられます。[Contains any scopes (任意のスコープを含む)] 値が選択されている場合、スコープ ​READ, WRITE, and READ AND WRITE​ を持つトークンが受け入れられます。

Expose Headers (ヘッダーを公開)

プロキシのシナリオで、バックエンドへの要求でヘッダーを公開する必要があるかどうかを指定します。統合サーバーによって返されるユーザープロパティは、「X-AGW-」というプレフィックスが付けられ、ヘッダーとしてバックエンドに送信されます。

Skip Client Id Validation (クライアント ID 検証をスキップ)

クライアントアプリケーションの API コントラクト検証をスキップします。

選択した場合、​「ポリシーのしくみ」​セクションの図のステップ 4 がスキップされます。

Authentication request timeout (認証要求タイムアウト)

アクセストークン検証エンドポイントを認証するときに、応答を待機する最大時間 (ミリ秒単位) を設定します。

10000
## [](#how-this-policy-works)ポリシーのしくみ 次の図は、OpenID Connect アクセストークン適用ポリシーワークフローを示しています。 ![PingFederate ポリシーを介して API とやり取りするユーザーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/open-id-policy-workflow.png) この図には次の動作が示されています。 1. ユーザーが最初にポリシーで保護された API に HTTP 要求を送信します。 2. ポリシーは要求からトークンを抽出し、それを検証エンドポイントに送信して、トークンの整合性を検証します。 3. トークン検証エンドポイントは、クライアントアプリケーションのクライアント ID を含むトークンメタデータを返します。 4. ポリシーは Anypoint Platform から以前に取得したコントラクトで更新されたローカルデータベースを使用して、クライアント ID が API にアクセスできるかどうかを検証します。 5. すべての検証が正常に完了すると、要求はバックエンドに到達できます。 ### [](#leveraging-TVE-information)トークン検証エンドポイント情報の活用 トークン検証エンドポイントで正常にトークンが検証されると、特定の情報 (OpenID Connect の設定可能な項目など) がポリシーに返されます。 次の例は、認証サーバーからのトークン検証応答を示しています: ```text { "uid":"john.doe", "mail":"john.doe@example.com" "token_type":"Bearer", "exp": 1516239022 "alias" : ["Jhon", "Jhonny", "Mr Doe"], "address" : { "city": "london", "road": “abbey road" } } ``` OAuth プロバイダーによって返された項目はポリシーによって処理され、フロー全体に伝播され、アクセスを要求しているアプリケーションが HTTP リクエスターを使用している場合は最終的にバックエンドに公開されます。 ### [](#token-caching)ローカルモードでのトークンキャッシュ システムがトークンを検証すると、そのトークンは (デフォルトで) 期限切れになるまでキャッシュされるため、ポリシーのパフォーマンスが向上します。失効したトークンなどの特定のケースでは、キャッシュを最小限に抑えたり無効にしたりできます。 検証エンドポイントは、トークンの有効期限などの複数のプロパティをポリシーに送信します。有効期限情報がない場合、トークンはキャッシュされません。 トークンのキャッシュにかかる時間を制御するには、トークン検証エンドポイントに対して再検証を試みる前に、宣言型設定ファイルで次のパラメーターを設定します。 - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxFederationExpirationTime: このプロパティを設定すると、指定された時間、またはトークンが期限切れになるまでのいずれか早い方でトークンがキャッシュされます。このプロパティが有効で、検証エンドポイントが有効期限情報を送信しない場合、トークンはキャッシュされません。 同時にキャッシュできるトークンの数を制御するには、宣言型設定ファイルで次のパラメーターを設定します。 - policyRef: name: openidconnect-access-token-enforcement-flex config: ... maxCacheSize: ### [](#token-validation-endpoint-authentication)トークン検証エンドポイント認証 指定されたトークンの検証が完了すると、ポリシーは要求を検証エンドポイントに送信します。次に、ポリシーは OAuth 2.0 認証フレームワーク仕様の「Token Introspection Client (トークンイントロスペクションクライアント)」セクションに従って、アクセス管理のクライアントプロバイダー設定からログイン情報を取得します。これらのログイン情報は、 [OAuth 2.0 認証フレームワーク仕様の「Client Authentication (クライアント認証)」セクション](https://tools.ietf.org/html/rfc6749#section-2.3)​で指定されているようにリクエストボディで送信されます。 トークン検証エンドポイントの認証方法は、現在サポートされていません。 ## [](#expose-headers-ヘッダーを公開-オプションの設定)Expose Headers (ヘッダーを公開) オプションの設定 ポリシーで ​`Expose Headers`​ オプションを設定し、アプリケーション (標準のプロキシなど) が HTTP リクエスターを使用している場合、プロパティはヘッダーとしてバックエンドにリダイレクトされます。 項目ごとに、元の保護されたリソースへの要求が「X-AGW- + =」形式を使用する HTTP ヘッダーで強化されます。前のセクションの応答例では、次のヘッダーが追加されています。 ```text X-AGW-uid=john.doe X-AGW-mail=john.doe@example.com X-AGW-token_type=Bearer ``` 伝播されたプロパティには、​`scope`​、​`exp`​ オブジェクトおよび配列は含まれません。 フロー内の以降の処理では、検証エンドポイントからの元の解析していない応答を使用できます。情報は認証オブジェクトに保存されます。 たとえば、​`mail`​ 項目がポリシーに返される場合、次の DataWeave 2.0 式を使用して項目の値にアクセスできます。 `#[authentication.properties.userProperties.mail]` 次の DataWeave 2.0 式を使用して、OAuth2 トークンのクライアント ID を取得できます。 `#[authentication.principal]` ## [](#faq)FAQ **API に適用するポリシーのリストに OpenID Connect アクセストークン適用ポリシーが表示されない。** ポリシーリストにポリシーが表示されない場合、アクセス管理で OpenID クライアントプロバイダーを設定していることを確認します。詳細は、​[「OpenID Connect クライアント管理を設定する」](https://docs.mulesoft.com/jp/access-management/configure-client-management-openid-task)​を参照してください。​[複数の IDP](https://docs.mulesoft.com/jp/api-manager/latest/configure-multiple-credential-providers)​ を使用している場合、API で OpenID Connect クライアントが正しく設定されていることを確認します。 **ポリシーで OAuth 2.0 トークンを生成できますか?** いいえ。 ポリシーはトークンの検証のみを行います。 **OAuth トークンはどのようにキャッシュされますか?** OAuth 2.0 トークンはメモリにのみキャッシュされ、ディスクに書き込まれることはありません。 **OpenID Connect アクセストークン適用ポリシーを設定した後にレート制限 SLA ポリシーを設定できますか?** はい、できます。OpenID Connect アクセストークン適用ポリシーの後にレート制限 SLA ポリシーを適用し、次の DataWeave 2.0 式を使用して \[​`Client ID Expression`​ (クライアント ID 式)\] の値を指定します。 `#[authentication.principal]` リクエスターの ID はすでに OpenID Connect アクセストークン適用ポリシーで検証されているため、\[​`Client Secret Expression`​ (クライアントシークレット式)\] 項目は空のままにできます。 # Runtime Manager での Flex Gateway API 状況の表示 Flex Gateway インスタンスに関連付けられた API に関する基本情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateway\]**​ を選択します。 3. API を確認するゲートウェイの名前をクリックします。 4. **\[APIs (API)\]**​ をクリックします。 各 API について、Runtime Manager に名前、バージョン、インスタンス ID、表示ラベル、追加された日付が表示されます。 詳細情報を確認して API に対するアクションを実行するには、​**\[View details (詳細を表示)\]**​ をクリックして API Manager にリダイレクトされるようにします。 # Runtime Manager でのランタイムログの表示 Runtime Manager を使用して、Flex Gateway のランタイムログを表示します。Runtime Manager では、ログ内のキーワードを検索したり、​**\[Replica (レプリカ)\]**​、​**\[Time Range (時間範囲)\]**​、​**\[Log Level (ログレベル)\]**​ で絞り込んだりできます。 Runtime Manager は、Flex Gateway ごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、Flex Gateway ごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、Anypoint Monitoring を使用してこのログにアクセスするか (Titanium サブスクリプションが必要)、サードパーティログサービスを使用します。 Runtime Manager で Flex Gateway ランタイムログにアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateway\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Anypoint Monitoring でのランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-monitoring) - [サードパーティサービスの Flex Gateway ログ出力の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-third-party-logs-config) # Runtime Manager でのレプリカ状況の表示 Runtime Manager では、Flex レプリカのグループの状況と個々の Flex レプリカの状況を表示できます。 ## [](#flex-レプリカのグループ)Flex レプリカのグループ Flex レプリカのグループの状況に関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 デフォルトでは、すべての Flex Gateway がその状況に関係なく表示されます。状況で絞り込むには、​**\[Any Status (任意の状況)\]**​ 矢印をクリックし、絞り込む状況をクリックします。 **\[Name (名前)\]**​ 列には、名前と接続済みレプリカの数が表示されます。 **\[Status (状況)\]**​ 列には、特定のゲートウェイに関連付けられたレプリカの接続状況が表示されます。 次の表で、レプリカのグループの各状況の意味について説明します。
状況 レプリカのグループ

実行中

1 つ以上のレプリカがプラットフォームに接続されており、トラフィックを提供できます。

Not Running (非実行中)

プラットフォームに接続されたレプリカはなく、トラフィックを提供しているかどうかに関する情報はありません。
## [](#個々の-flex-レプリカ)個々の Flex レプリカ 個々のレプリカの状況に関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. 個々のレプリカの状況を表示する Flex Gateway の名前を選択します。 レプリカのリストの ​**\[Status (状況)\]**​ 列には、その特定のレプリカの接続状況が表示されます。 次の表で、単一のレプリカの各状況の意味について説明します。
状況 単一のレプリカ

実行中

レプリカはプラットフォームに接続されており、トラフィックを提供できます。

Not Running (非実行中)

レプリカはプラットフォームに接続されていません。トラフィックを提供しているかどうかに関する情報はありません。切断済みのレプリカは 7 日後に削除されます。
## [](#関連情報)関連情報 - [Runtime Manager での API 状況の表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-view-api-status) # Runtime Manager でのレプリカ状況の表示 Runtime Manager では、Flex レプリカのグループの状況と個々の Flex レプリカの状況を表示できます。 ## [](#flex-レプリカのグループ)Flex レプリカのグループ Flex レプリカのグループの状況に関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateway\]**​ を選択します。 デフォルトでは、すべての Flex Gateway がその状況に関係なく表示されます。状況で絞り込むには、​**\[Any Status (任意の状況)\]**​ 矢印をクリックし、絞り込む状況をクリックします。 **\[Name (名前)\]**​ 列には、名前と接続済みレプリカの数が表示されます。 **\[Status (状況)\]**​ 列には、特定のゲートウェイに関連付けられたレプリカの接続状況が表示されます。 次の表で、レプリカのグループの各状況の意味について説明します。
状況 レプリカのグループ

Connected (接続済み)

1 つ以上のレプリカがプラットフォームに接続されており、トラフィックを提供できます。

Disconnected (切断済み)

プラットフォームに接続されたレプリカはなく、トラフィックを提供しているかどうかに関する情報はありません。
## [](#個々の-flex-レプリカ)個々の Flex レプリカ 個々のレプリカの状況に関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateway\]**​ を選択します。 3. 個々のレプリカの状況を表示する Flex Gateway の名前を選択します。 レプリカのリストの ​**\[Status (状況)\]**​ 列には、その特定のレプリカの接続状況が表示されます。 次の表で、単一のレプリカの各状況の意味について説明します。
状況 単一のレプリカ

Connected (接続済み)

レプリカはプラットフォームに接続されており、トラフィックを提供できます。

Disconnected (切断済み)

レプリカはプラットフォームに接続されていません。トラフィックを提供しているかどうかに関する情報はありません。切断済みのレプリカは 7 日後に削除されます。
## [](#関連情報)関連情報 - [Runtime Manager での API 状況の表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-api-status) # Runtime Manager でのレプリカ状況の表示 Runtime Manager では、Flex レプリカのグループの状況と個々の Flex レプリカの状況を表示できます。 ## [](#flex-レプリカのグループ)Flex レプリカのグループ Flex レプリカのグループの状況に関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 デフォルトでは、すべての Flex Gateway がその状況に関係なく表示されます。状況で絞り込むには、​**\[Any Status (任意の状況)\]**​ 矢印をクリックし、絞り込む状況をクリックします。 **\[Name (名前)\]**​ 列には、名前と接続済みレプリカの数が表示されます。 **\[Status (状況)\]**​ 列には、特定のゲートウェイに関連付けられたレプリカの接続状況が表示されます。 次の表で、レプリカのグループの各状況の意味について説明します。
状況 レプリカのグループ

実行中

1 つ以上のレプリカがプラットフォームに接続されており、トラフィックを提供できます。

Not Running (非実行中)

プラットフォームに接続されたレプリカはなく、トラフィックを提供しているかどうかに関する情報はありません。
## [](#個々の-flex-レプリカ)個々の Flex レプリカ 個々のレプリカの状況に関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. 個々のレプリカの状況を表示する Flex Gateway の名前を選択します。 レプリカのリストの ​**\[Status (状況)\]**​ 列には、その特定のレプリカの接続状況が表示されます。 次の表で、単一のレプリカの各状況の意味について説明します。
状況 単一のレプリカ

実行中

レプリカはプラットフォームに接続されており、トラフィックを提供できます。

Not Running (非実行中)

レプリカはプラットフォームに接続されていません。トラフィックを提供しているかどうかに関する情報はありません。切断済みのレプリカは 7 日後に削除されます。
## [](#関連情報)関連情報 - [Runtime Manager での API 状況の表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-view-api-status) # Rust での Flex Gateway カスタムポリシーの実装 **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 ## [](#概要)概要 WebAssembly (WASM) 拡張機能を使用して、Envoy 上でカスタム検索条件として機能するカスタムポリシーを実装できます。これらのポリシーは、 [WebAssembly for Proxies (Rust SDK)](https://github.com/proxy-wasm/proxy-wasm-rust-sdk)​ を使用して実装します。以下の例では、Rust と関連ツールに関する知識があることを前提としています。 ## [](#ライフサイクルイベント)ライフサイクルイベント カスタムポリシーは、Envoy に依存しないイベント駆動型の L4/L7 プロキシ用ローレベルインターフェースである [proxy-wasm ABI](https://github.com/proxy-wasm/spec)​ に基づいています。このインターフェースは、WASM 拡張機能とホストがやり取りする方法を指定し、リスン可能なライフサイクルイベントである HTTP 要求ライフサイクルイベントに加えて WASM 検索条件ライフサイクルイベントも使用します。 SDK は、各ライフサイクルイベントに関連した情報を取得するためのメソッドを提供します。たとえば、​`on_http_request_headers`​ イベントから取得されるデータを使用して、関連するカスタムポリシーロジックを実行でき、その結果によって、要求を処理する必要があるかどうかをランタイムに通知できます。 ### [](#http-要求ライフサイクルイベント)HTTP 要求ライフサイクルイベント - `on_http_request_headers` エンドポイントが完全な HTTP リクエストヘッダーのセットを受け取るとトリガーされます。 - `on_http_request_body` エンドポイントが HTTP 要求の最初の数バイトを受け取るとトリガーされます。 - `on_http_response_headers` エンドポイントが完全な HTTP レスポンスヘッダーのセットを受け取るとトリガーされます。 - `on_http_response_body` エンドポイントが HTTP 応答本文の最初の数バイトを受け取るとトリガーされます。 ### [](#ライフサイクルイベントの絞り込み)ライフサイクルイベントの絞り込み - `on_configure` WASM 検索条件が使用可能な設定で開始されるとトリガーされます。 Flex Gateway は、ポリシー設定を JSON にシリアル化し、シリアル化された設定は Envoy WASM 検索条件の設定に使用されます。この JSON をカスタムポリシーで使用されるデータに非シリアル化して解析できます。 ### [](#ライフサイクルイベントの実装例)ライフサイクルイベントの実装例 次の Envoy 検索条件テンプレートは、ライフサイクルイベントの実装方法を示しています。 use proxy\_wasm::traits::\*; use proxy\_wasm::types::\*; proxy\_wasm::main! {{ proxy\_wasm::set\_log\_level(LogLevel::Trace); proxy\_wasm::set\_root\_context(|\_| -> Box { Box::new(HttpConfigHeaderRoot { header\_content: String::new(), }) }); }} struct HttpConfigHeader { header\_content: String, } impl Context for HttpConfigHeader {} impl HttpContext for HttpConfigHeader { fn on\_http\_request\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_request\_body(&mut self, \_body\_size: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_response\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_response\_body(&mut self, \_body\_size: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } } struct HttpConfigHeaderRoot { header\_content: String, } impl Context for HttpConfigHeaderRoot {} impl RootContext for HttpConfigHeaderRoot { fn on\_configure(&mut self, \_: usize) -> bool { if let Some(config\_bytes) = self.get\_plugin\_configuration() { self.header\_content = String::from\_utf8(config\_bytes).unwrap() } true } fn create\_http\_context(&self, \_: u32) -> Option> { Some(Box::new(HttpConfigHeader { header\_content: self.header\_content.clone(), })) } fn get\_type(&self) -> Option { Some(ContextType::HttpContext) } } ## [](#カスタム認証ヘッダーポリシーの例)カスタム認証ヘッダーポリシーの例 次のチュートリアルでは、すでに Exchange にパブリッシュされている​[ポリシー定義](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-flex-getting-started#create-policy-definition-files)​のポリシー実装の例を作成する方法を示しています。 このポリシー例では、​`x-custom-auth`​ ヘッダーがユーザー設定の値と一致しない要求をブロックしています。 ポリシー開発プロセスは、以下のステップで行います。 1. ポリシー定義 JSON ファイルを作成する。 2. プロジェクトをセットアップする。 3. カスタムポリシーを開発する。 ### [](#ポリシー定義-json-ファイルの作成)ポリシー定義 JSON ファイルの作成 ポリシー実装例では、ポリシー定義 JSON ファイルが必要です。Flex Gateway は、ポリシー設定をポリシー定義構造と一緒に JSON として Envoy WASM 検索条件に渡します。 認証ヘッダーポリシーの例には、ヘッダーで渡す必要のある値のパラメーターのみを使用しています。ポリシー定義 JSON ファイルは次の内容と一致している必要があります。 { "title": "Custom Auth Header", "type": "object", "description": "Enforces HTTP authentication matching x-custom-auth value to what is configured in the policy.", "properties": { "secret-value": { "title": "Custom Auth Header Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "secret-value" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "custom-auth-header-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#プロジェクトのセットアップ)プロジェクトのセットアップ 1. 次のコマンドで Rust プロジェクトを作成します。 cargo new flex\_custom\_policy\_example --lib これにより ​`flex_custom_policy_example`​ ディレクトリが作成されます。 2. 次のコンテンツを ​`flex_custom_policy_example`​ ディレクトリの ​`Cargo.toml`​ にコピーします。 \[package\] name = "flex\_custom\_policy\_example" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html \[lib\] crate-type = \["cdylib"\] name="flex\_custom\_policy\_example" path="src/lib.rs" \[dependencies\] proxy-wasm = { git = "https://github.com/proxy-wasm/proxy-wasm-rust-sdk.git", tag = "v0.2.0" } serde = { version = "1.0", features = \["derive"\] } serde\_json = "1.0" \[profile.release\] opt-level = "z" lto = "fat" ### [](#カスタムポリシーの開発)カスタムポリシーの開発 1. 次のポリシーブートストラップコードを新しい Rust ソースファイルに追加します。 use proxy\_wasm::traits::\*; use proxy\_wasm::types::\*; use serde::Deserialize; proxy\_wasm::main! {{ proxy\_wasm::set\_log\_level(LogLevel::Trace); proxy\_wasm::set\_root\_context(|\_| -> Box { Box::new(CustomAuthRootContext { config: CustomAuthConfig::default(), }) }); }} このコードは、WASM 検索条件を Envoy にデプロイするために必要です。​`main`​ ブロックは、ルートコンテキストを設定します。このルートコンテキストは、受け取った各 HTTP 要求に対して子コンテキストを生成するために使用する Envoy エンティティです。 2. 次のルートコンテキスト実装コードを追加します。 struct CustomAuthRootContext { config: CustomAuthConfig, } impl Context for CustomAuthRootContext {} impl RootContext for CustomAuthRootContext { fn create\_http\_context(&self, \_: u32) -> Option> { Some(Box::new(CustomAuthHttpContext { config: self.config.clone(), })) } fn get\_type(&self) -> Option { Some(ContextType::HttpContext) } } 各 Envoy 検索条件は、ルートコンテキスト実装を提供するために必要です。​`RootContext`​ trait には、実装可能な便利なメソッドが含まれています。この例では、Envoy が子コンテキストを生成できるように、HTTP 検索条件は ​`create_http_context`​ と ​`get_type`​ を実装しています。 3. 次の ​`Struct`​ を追加して、この JSON の解析を有効にします。 #\[derive(Default, Clone, Deserialize)\] struct CustomAuthConfig { #\[serde(alias = "secret-value")\] secret\_value: String, } Flex Gateway は、ポリシー定義で指定されている JSON を使用してポリシーを設定します。解析が必要な JSON には ​`secret-value`​ という項目が 1 つあります。 4. 設定を非シリアル化します。 基本的なポリシー設定構造を作成したら、逆シリアル化するために ​`RootContext` ​`on_configure`​ メソッドを実装する必要があります。 `CustomAuthRootContext`​ の ​`RootContext`​ の実装内で、次のスニペットのように ​`on_configure`​ メソッドを追加します。 impl RootContext for CustomAuthRootContext { fn on\_configure(&mut self, \_: usize) -> bool { if let Some(config\_bytes) = self.get\_plugin\_configuration() { self.config = serde\_json::from\_slice(config\_bytes.as\_slice()).unwrap(); } true } // Other implemented methods // ... } 5. 次の HTTP コンテキストコードを追加します。 struct CustomAuthHttpContext { pub config: CustomAuthConfig, } impl Context for CustomAuthHttpContext {} impl HttpContext for CustomAuthHttpContext {} 受け取った各要求によって新しい ​`CustomAuthHttpContext`​ が作成されます。この ​`CustomAuthHttpContext`​ は、HTTP 要求が有効である間は有効です。これにより (要求間の状態データではなく) 要求に関連した状態データを格納できます。 6. 次のコアポリシー機能ロジックを追加します。 impl HttpContext for CustomAuthHttpContext { fn on\_http\_request\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { if let Some(value) = self.get\_http\_request\_header("x-custom-auth") { if self.config.secret\_value == value { return Action::Continue; } } self.send\_http\_response(401, Vec::new(), None); Action::Pause } } `proxy-wasm`​ ABI は、受け取ったリクエストヘッダー値を取得して、値を ​`secret-value`​ と比較します。​`secret-value`​ がヘッダーと一致すると、実装は ​`Action::Continue`​ を返します。そうでない場合は ​`Action::Pause`​ を返し、検索条件自身が ​`send_http_response`​ を使用して呼び出し側のクライアントに応答を返します。 注意: Rust SDK には、​`get_http_request_header`​ を使用した非 UTF-8 値の読み込みの問題があります。この問題を回避するには、​`get_http_request_headers_bytes`​ メソッドを使用し、​`from_utf8` [メソッド](https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8)​を使用してバイトを読み取ります。次に例を示します。 let header = self.get\_http\_request\_header\_bytes("x-custom-auth").map(String::from\_utf8).and\_then(Result::ok); 7. `wasm32`​ をターゲットとして追加して、コンパイルを有効にします。 rustup target add wasm32-wasi ポリシーに含まれるすべてのサードパーティライブラリは、​`wasm32-wasi`​ Rust コンパイルターゲットと互換性がある必要があります。

一部のライブラリは wasm32-wasi ターゲットと適切に互換性があっても、Flex Gateway にデプロイすると適切に動作しないことがあります。この状況が発生した場合のデプロイメントエラーの例は次のとおりです。

  • Failed to load Wasm module due to a missing import (インポートが欠落しているため Wasm モジュールの読み込みに失敗しました)

  • Wasm VM failed to initialize Wasm code (Wasm VM が Wasm コードの初期化に失敗しました)

  • Plugin configured to fail closed failed to load (フェールクローズに設定されたプラグインの読み込みに失敗しました)

これらの問題を解決するには、サードパーティライブラリのオーナーに問い合わせるか、別のライブラリを使用してください。
8. 次のコマンドでカスタムポリシーをコンパイルします。 cargo build --target wasm32-wasi --release コンパイルにより、バイナリ ​`.wasm`​ ファイルが ​`./target/wasm32-wasi/release`​ ディレクトリに出力されます。 Exchange へのカスタムポリシーのパブリッシュついての詳細は、​[「Flex Gateway または Mule 4 カスタムポリシーのパブリッシュ」](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-flex-getting-started)​を参照してください。 # Rust での Flex Gateway カスタムポリシーの実装 **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 ## [](#概要)概要 WebAssembly (WASM) 拡張機能を使用して、Envoy 上でカスタム検索条件として機能するカスタムポリシーを実装できます。これらのポリシーは、 [WebAssembly for Proxies (Rust SDK)](https://github.com/proxy-wasm/proxy-wasm-rust-sdk)​ を使用して実装します。以下の例では、Rust と関連ツールに関する知識があることを前提としています。 ## [](#ライフサイクルイベント)ライフサイクルイベント カスタムポリシーは、Envoy に依存しないイベント駆動型の L4/L7 プロキシ用ローレベルインターフェースである [proxy-wasm ABI](https://github.com/proxy-wasm/spec)​ に基づいています。このインターフェースは、WASM 拡張機能とホストがやり取りする方法を指定し、リスン可能なライフサイクルイベントである HTTP 要求ライフサイクルイベントに加えて WASM 検索条件ライフサイクルイベントも使用します。 SDK は、各ライフサイクルイベントに関連した情報を取得するためのメソッドを提供します。たとえば、​`on_http_request_headers`​ イベントから取得されるデータを使用して、関連するカスタムポリシーロジックを実行でき、その結果によって、要求を処理する必要があるかどうかをランタイムに通知できます。 ### [](#http-要求ライフサイクルイベント)HTTP 要求ライフサイクルイベント - `on_http_request_headers` エンドポイントが完全な HTTP リクエストヘッダーのセットを受け取るとトリガーされます。 - `on_http_request_body` エンドポイントが HTTP 要求の最初の数バイトを受け取るとトリガーされます。 - `on_http_response_headers` エンドポイントが完全な HTTP レスポンスヘッダーのセットを受け取るとトリガーされます。 - `on_http_response_body` エンドポイントが HTTP レスポンスボディの最初の数バイトを受け取るとトリガーされます。 ### [](#ライフサイクルイベントの絞り込み)ライフサイクルイベントの絞り込み - `on_configure` WASM 検索条件が使用可能な設定で開始されるとトリガーされます。 Flex Gateway は、ポリシー設定を JSON にシリアル化し、シリアル化された設定は Envoy WASM 検索条件の設定に使用されます。この JSON をカスタムポリシーで使用されるデータに非シリアル化して解析できます。 ### [](#ライフサイクルイベントの実装例)ライフサイクルイベントの実装例 次の Envoy 検索条件テンプレートは、ライフサイクルイベントの実装方法を示しています。 use proxy\_wasm::traits::\*; use proxy\_wasm::types::\*; proxy\_wasm::main! {{ proxy\_wasm::set\_log\_level(LogLevel::Trace); proxy\_wasm::set\_root\_context(|\_| -> Box { Box::new(HttpConfigHeaderRoot { header\_content: String::new(), }) }); }} struct HttpConfigHeader { header\_content: String, } impl Context for HttpConfigHeader {} impl HttpContext for HttpConfigHeader { fn on\_http\_request\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_request\_body(&mut self, \_body\_size: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_response\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_response\_body(&mut self, \_body\_size: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } } struct HttpConfigHeaderRoot { header\_content: String, } impl Context for HttpConfigHeaderRoot {} impl RootContext for HttpConfigHeaderRoot { fn on\_configure(&mut self, \_: usize) -> bool { if let Some(config\_bytes) = self.get\_plugin\_configuration() { self.header\_content = String::from\_utf8(config\_bytes).unwrap() } true } fn create\_http\_context(&self, \_: u32) -> Option> { Some(Box::new(HttpConfigHeader { header\_content: self.header\_content.clone(), })) } fn get\_type(&self) -> Option { Some(ContextType::HttpContext) } } ## [](#カスタム認証ヘッダーポリシーの例)カスタム認証ヘッダーポリシーの例 次のチュートリアルでは、すでに Exchange にパブリッシュされている​[ポリシー定義](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-flex-getting-started#create-policy-definition-files)​のポリシー実装の例を作成する方法を示しています。 このポリシー例では、​`x-custom-auth`​ ヘッダーがユーザー設定の値と一致しない要求をブロックしています。 ポリシー開発プロセスは、以下のステップで行います。 1. ポリシー定義 JSON ファイルを作成する。 2. プロジェクトをセットアップする。 3. カスタムポリシーを開発する。 ### [](#ポリシー定義-json-ファイルの作成)ポリシー定義 JSON ファイルの作成 ポリシー実装例では、ポリシー定義 JSON ファイルが必要です。Flex Gateway は、ポリシー設定をポリシー定義構造と一緒に JSON として Envoy WASM 検索条件に渡します。 認証ヘッダーポリシーの例には、ヘッダーで渡す必要のある値のパラメーターのみを使用しています。ポリシー定義 JSON ファイルは次の内容と一致している必要があります。 { "title": "Custom Auth Header", "type": "object", "description": "Enforces HTTP authentication matching x-custom-auth value to what is configured in the policy.", "properties": { "secret-value": { "title": "Custom Auth Header Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "secret-value" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "custom-auth-header-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#プロジェクトのセットアップ)プロジェクトのセットアップ 1. 次のコマンドで Rust プロジェクトを作成します。 cargo new flex\_custom\_policy\_example --lib これにより ​`flex_custom_policy_example`​ ディレクトリが作成されます。 2. 次のコンテンツを ​`flex_custom_policy_example`​ ディレクトリの ​`Cargo.toml`​ にコピーします。 \[package\] name = "flex\_custom\_policy\_example" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html \[lib\] crate-type = \["cdylib"\] name="flex\_custom\_policy\_example" path="src/lib.rs" \[dependencies\] proxy-wasm = { git = "https://github.com/proxy-wasm/proxy-wasm-rust-sdk.git", tag = "v0.2.0" } serde = { version = "1.0", features = \["derive"\] } serde\_json = "1.0" \[profile.release\] opt-level = "z" lto = "fat" ### [](#カスタムポリシーの開発)カスタムポリシーの開発 1. 次のポリシーブートストラップコードを新しい Rust ソースファイルに追加します。 use proxy\_wasm::traits::\*; use proxy\_wasm::types::\*; use serde::Deserialize; proxy\_wasm::main! {{ proxy\_wasm::set\_log\_level(LogLevel::Trace); proxy\_wasm::set\_root\_context(|\_| -> Box { Box::new(CustomAuthRootContext { config: CustomAuthConfig::default(), }) }); }} このコードは、WASM 検索条件を Envoy にデプロイするために必要です。​`main`​ ブロックは、ルートコンテキストを設定します。このルートコンテキストは、受け取った各 HTTP 要求に対して子コンテキストを生成するために使用する Envoy エンティティです。 2. 次のルートコンテキスト実装コードを追加します。 struct CustomAuthRootContext { config: CustomAuthConfig, } impl Context for CustomAuthRootContext {} impl RootContext for CustomAuthRootContext { fn create\_http\_context(&self, \_: u32) -> Option> { Some(Box::new(CustomAuthHttpContext { config: self.config.clone(), })) } fn get\_type(&self) -> Option { Some(ContextType::HttpContext) } } 各 Envoy 検索条件は、ルートコンテキスト実装を提供するために必要です。​`RootContext`​ trait には、実装可能な便利なメソッドが含まれています。この例では、Envoy が子コンテキストを生成できるように、HTTP 検索条件は ​`create_http_context`​ と ​`get_type`​ を実装しています。 3. 次の ​`Struct`​ を追加して、この JSON の解析を有効にします。 #\[derive(Default, Clone, Deserialize)\] struct CustomAuthConfig { #\[serde(alias = "secret-value")\] secret\_value: String, } Flex Gateway は、ポリシー定義で指定されている JSON を使用してポリシーを設定します。解析が必要な JSON には ​`secret-value`​ という項目が 1 つあります。 4. 設定を非シリアル化します。 基本的なポリシー設定構造を作成したら、逆シリアル化するために ​`RootContext` ​`on_configure`​ メソッドを実装する必要があります。 `CustomAuthRootContext`​ の ​`RootContext`​ の実装内で、次のスニペットのように ​`on_configure`​ メソッドを追加します。 impl RootContext for CustomAuthRootContext { fn on\_configure(&mut self, \_: usize) -> bool { if let Some(config\_bytes) = self.get\_plugin\_configuration() { self.config = serde\_json::from\_slice(config\_bytes.as\_slice()).unwrap(); } true } // Other implemented methods // ... } 5. 次の HTTP コンテキストコードを追加します。 struct CustomAuthHttpContext { pub config: CustomAuthConfig, } impl Context for CustomAuthHttpContext {} impl HttpContext for CustomAuthHttpContext {} 受け取った各要求によって新しい ​`CustomAuthHttpContext`​ が作成されます。この ​`CustomAuthHttpContext`​ は、HTTP 要求が有効である間は有効です。これにより (要求間の状態データではなく) 要求に関連した状態データを格納できます。 6. 次のコアポリシー機能ロジックを追加します。 impl HttpContext for CustomAuthHttpContext { fn on\_http\_request\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { if let Some(value) = self.get\_http\_request\_header("x-custom-auth") { if self.config.secret\_value == value { return Action::Continue; } } self.send\_http\_response(401, Vec::new(), None); Action::Pause } } `proxy-wasm`​ ABI は、受け取ったリクエストヘッダー値を取得して、値を ​`secret-value`​ と比較します。​`secret-value`​ がヘッダーと一致すると、実装は ​`Action::Continue`​ を返します。そうでない場合は ​`Action::Pause`​ を返し、検索条件自身が ​`send_http_response`​ を使用して呼び出し側のクライアントに応答を返します。 注意: Rust SDK には、​`get_http_request_header`​ を使用した非 UTF-8 値の読み込みの問題があります。この問題を回避するには、​`get_http_request_headers_bytes`​ メソッドを使用し、​`from_utf8` [メソッド](https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8)​を使用してバイトを読み取ります。次に例を示します。 let header = self.get\_http\_request\_header\_bytes("x-custom-auth").map(String::from\_utf8).and\_then(Result::ok); 7. `wasm32`​ を対象として追加して、コンパイルを有効にします。 rustup target add wasm32-wasi ポリシーに含まれるすべてのサードパーティライブラリは、​`wasm32-wasi`​ Rust コンパイルターゲットと互換性がある必要があります。

一部のライブラリは wasm32-wasi ターゲットと適切に互換性があっても、Flex Gateway にデプロイすると適切に動作しないことがあります。この状況が発生した場合のデプロイメントエラーの例は次のとおりです。

  • Failed to load Wasm module due to a missing import (インポートが欠落しているため Wasm モジュールの読み込みに失敗しました)

  • Wasm VM failed to initialize Wasm code (Wasm VM が Wasm コードの初期化に失敗しました)

  • Plugin configured to fail closed failed to load (フェールクローズに設定されたプラグインの読み込みに失敗しました)

これらの問題を解決するには、サードパーティライブラリのオーナーに問い合わせるか、別のライブラリを使用してください。
8. 次のコマンドでカスタムポリシーをコンパイルします。 cargo build --target wasm32-wasi --release コンパイルにより、バイナリ ​`.wasm`​ ファイルが ​`./target/wasm32-wasi/release`​ ディレクトリに出力されます。 Exchange へのカスタムポリシーのパブリッシュついての詳細は、​[「Flex Gateway または Mule 4 カスタムポリシーのパブリッシュ」](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-flex-getting-started)​を参照してください。 # Rust での Flex Gateway カスタムポリシーの実装 **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 ## [](#概要)概要 WebAssembly (WASM) 拡張機能を使用して、Envoy 上でカスタム検索条件として機能するカスタムポリシーを実装できます。これらのポリシーは、 [WebAssembly for Proxies (Rust SDK)](https://github.com/proxy-wasm/proxy-wasm-rust-sdk)​ を使用して実装します。以下の例では、Rust と関連ツールに関する知識があることを前提としています。 ## [](#ライフサイクルイベント)ライフサイクルイベント カスタムポリシーは、Envoy に依存しないイベント駆動型の L4/L7 プロキシ用ローレベルインターフェースである [proxy-wasm ABI](https://github.com/proxy-wasm/spec)​ に基づいています。このインターフェースは、WASM 拡張機能とホストがやり取りする方法を指定し、リスン可能なライフサイクルイベントである HTTP 要求ライフサイクルイベントに加えて WASM 検索条件ライフサイクルイベントも使用します。 SDK は、各ライフサイクルイベントに関連した情報を取得するためのメソッドを提供します。たとえば、​`on_http_request_headers`​ イベントから取得されるデータを使用して、関連するカスタムポリシーロジックを実行でき、その結果によって、要求を処理する必要があるかどうかをランタイムに通知できます。 ### [](#http-要求ライフサイクルイベント)HTTP 要求ライフサイクルイベント - `on_http_request_headers` エンドポイントが完全な HTTP リクエストヘッダーのセットを受け取るとトリガーされます。 - `on_http_request_body` エンドポイントが HTTP 要求の最初の数バイトを受け取るとトリガーされます。 - `on_http_response_headers` エンドポイントが完全な HTTP レスポンスヘッダーのセットを受け取るとトリガーされます。 - `on_http_response_body` エンドポイントが HTTP 応答本文の最初の数バイトを受け取るとトリガーされます。 ### [](#ライフサイクルイベントの絞り込み)ライフサイクルイベントの絞り込み - `on_configure` WASM 検索条件が使用可能な設定で開始されるとトリガーされます。 Flex Gateway は、ポリシー設定を JSON にシリアル化し、シリアル化された設定は Envoy WASM 検索条件の設定に使用されます。この JSON をカスタムポリシーで使用されるデータに非シリアル化して解析できます。 ### [](#ライフサイクルイベントの実装例)ライフサイクルイベントの実装例 次の Envoy 検索条件テンプレートは、ライフサイクルイベントの実装方法を示しています。 use proxy\_wasm::traits::\*; use proxy\_wasm::types::\*; proxy\_wasm::main! {{ proxy\_wasm::set\_log\_level(LogLevel::Trace); proxy\_wasm::set\_root\_context(|\_| -> Box { Box::new(HttpConfigHeaderRoot { header\_content: String::new(), }) }); }} struct HttpConfigHeader { header\_content: String, } impl Context for HttpConfigHeader {} impl HttpContext for HttpConfigHeader { fn on\_http\_request\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_request\_body(&mut self, \_body\_size: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_response\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } fn on\_http\_response\_body(&mut self, \_body\_size: usize, \_end\_of\_stream: bool) -> Action { Action::Continue } } struct HttpConfigHeaderRoot { header\_content: String, } impl Context for HttpConfigHeaderRoot {} impl RootContext for HttpConfigHeaderRoot { fn on\_configure(&mut self, \_: usize) -> bool { if let Some(config\_bytes) = self.get\_plugin\_configuration() { self.header\_content = String::from\_utf8(config\_bytes).unwrap() } true } fn create\_http\_context(&self, \_: u32) -> Option> { Some(Box::new(HttpConfigHeader { header\_content: self.header\_content.clone(), })) } fn get\_type(&self) -> Option { Some(ContextType::HttpContext) } } ## [](#カスタム認証ヘッダーポリシーの例)カスタム認証ヘッダーポリシーの例 次のチュートリアルでは、すでに Exchange にパブリッシュされている​[ポリシー定義](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-flex-getting-started#create-policy-definition-files)​のポリシー実装の例を作成する方法を示しています。 このポリシー例では、​`x-custom-auth`​ ヘッダーがユーザー設定の値と一致しない要求をブロックしています。 ポリシー開発プロセスは、以下のステップで行います。 1. ポリシー定義 JSON ファイルを作成する。 2. プロジェクトをセットアップする。 3. カスタムポリシーを開発する。 ### [](#ポリシー定義-json-ファイルの作成)ポリシー定義 JSON ファイルの作成 ポリシー実装例では、ポリシー定義 JSON ファイルが必要です。Flex Gateway は、ポリシー設定をポリシー定義構造と一緒に JSON として Envoy WASM 検索条件に渡します。 認証ヘッダーポリシーの例には、ヘッダーで渡す必要のある値のパラメーターのみを使用しています。ポリシー定義 JSON ファイルは次の内容と一致している必要があります。 { "title": "Custom Auth Header", "type": "object", "description": "Enforces HTTP authentication matching x-custom-auth value to what is configured in the policy.", "properties": { "secret-value": { "title": "Custom Auth Header Password", "type": "string", "@context": { "@characteristics": \[ "security:sensitive" \] } } }, "required": \[ "secret-value" \], "unevaluatedProperties": false, "@context": { "@vocab": "anypoint://vocabulary/policy.yaml#", "security": "anypoint://vocabulary/policy.yaml#" }, "$id": "custom-auth-header-simple", "$schema": "https://json-schema.org/draft/2019-09/schema" } ### [](#プロジェクトのセットアップ)プロジェクトのセットアップ 1. 次のコマンドで Rust プロジェクトを作成します。 cargo new flex\_custom\_policy\_example --lib これにより ​`flex_custom_policy_example`​ ディレクトリが作成されます。 2. 次のコンテンツを ​`flex_custom_policy_example`​ ディレクトリの ​`Cargo.toml`​ にコピーします。 \[package\] name = "flex\_custom\_policy\_example" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html \[lib\] crate-type = \["cdylib"\] name="flex\_custom\_policy\_example" path="src/lib.rs" \[dependencies\] proxy-wasm = { git = "https://github.com/proxy-wasm/proxy-wasm-rust-sdk.git", tag = "v0.2.0" } serde = { version = "1.0", features = \["derive"\] } serde\_json = "1.0" \[profile.release\] opt-level = "z" lto = "fat" ### [](#カスタムポリシーの開発)カスタムポリシーの開発 1. 次のポリシーブートストラップコードを新しい Rust ソースファイルに追加します。 use proxy\_wasm::traits::\*; use proxy\_wasm::types::\*; use serde::Deserialize; proxy\_wasm::main! {{ proxy\_wasm::set\_log\_level(LogLevel::Trace); proxy\_wasm::set\_root\_context(|\_| -> Box { Box::new(CustomAuthRootContext { config: CustomAuthConfig::default(), }) }); }} このコードは、WASM 検索条件を Envoy にデプロイするために必要です。​`main`​ ブロックは、ルートコンテキストを設定します。このルートコンテキストは、受け取った各 HTTP 要求に対して子コンテキストを生成するために使用する Envoy エンティティです。 2. 次のルートコンテキスト実装コードを追加します。 struct CustomAuthRootContext { config: CustomAuthConfig, } impl Context for CustomAuthRootContext {} impl RootContext for CustomAuthRootContext { fn create\_http\_context(&self, \_: u32) -> Option> { Some(Box::new(CustomAuthHttpContext { config: self.config.clone(), })) } fn get\_type(&self) -> Option { Some(ContextType::HttpContext) } } 各 Envoy 検索条件は、ルートコンテキスト実装を提供するために必要です。​`RootContext`​ trait には、実装可能な便利なメソッドが含まれています。この例では、Envoy が子コンテキストを生成できるように、HTTP 検索条件は ​`create_http_context`​ と ​`get_type`​ を実装しています。 3. 次の ​`Struct`​ を追加して、この JSON の解析を有効にします。 #\[derive(Default, Clone, Deserialize)\] struct CustomAuthConfig { #\[serde(alias = "secret-value")\] secret\_value: String, } Flex Gateway は、ポリシー定義で指定されている JSON を使用してポリシーを設定します。解析が必要な JSON には ​`secret-value`​ という項目が 1 つあります。 4. 設定を非シリアル化します。 基本的なポリシー設定構造を作成したら、逆シリアル化するために ​`RootContext` ​`on_configure`​ メソッドを実装する必要があります。 `CustomAuthRootContext`​ の ​`RootContext`​ の実装内で、次のスニペットのように ​`on_configure`​ メソッドを追加します。 impl RootContext for CustomAuthRootContext { fn on\_configure(&mut self, \_: usize) -> bool { if let Some(config\_bytes) = self.get\_plugin\_configuration() { self.config = serde\_json::from\_slice(config\_bytes.as\_slice()).unwrap(); } true } // Other implemented methods // ... } 5. 次の HTTP コンテキストコードを追加します。 struct CustomAuthHttpContext { pub config: CustomAuthConfig, } impl Context for CustomAuthHttpContext {} impl HttpContext for CustomAuthHttpContext {} 受け取った各要求によって新しい ​`CustomAuthHttpContext`​ が作成されます。この ​`CustomAuthHttpContext`​ は、HTTP 要求が有効である間は有効です。これにより (要求間の状態データではなく) 要求に関連した状態データを格納できます。 6. 次のコアポリシー機能ロジックを追加します。 impl HttpContext for CustomAuthHttpContext { fn on\_http\_request\_headers(&mut self, \_num\_headers: usize, \_end\_of\_stream: bool) -> Action { if let Some(value) = self.get\_http\_request\_header("x-custom-auth") { if self.config.secret\_value == value { return Action::Continue; } } self.send\_http\_response(401, Vec::new(), None); Action::Pause } } `proxy-wasm`​ ABI は、受け取ったリクエストヘッダー値を取得して、値を ​`secret-value`​ と比較します。​`secret-value`​ がヘッダーと一致すると、実装は ​`Action::Continue`​ を返します。そうでない場合は ​`Action::Pause`​ を返し、検索条件自身が ​`send_http_response`​ を使用して呼び出し側のクライアントに応答を返します。 注意: Rust SDK には、​`get_http_request_header`​ を使用した非 UTF-8 値の読み込みの問題があります。この問題を回避するには、​`get_http_request_headers_bytes`​ メソッドを使用し、​`from_utf8` [メソッド](https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8)​を使用してバイトを読み取ります。次に例を示します。 let header = self.get\_http\_request\_header\_bytes("x-custom-auth").map(String::from\_utf8).and\_then(Result::ok); 7. `wasm32`​ をターゲットとして追加して、コンパイルを有効にします。 rustup target add wasm32-wasi ポリシーに含まれるすべてのサードパーティライブラリは、​`wasm32-wasi`​ Rust コンパイルターゲットと互換性がある必要があります。

一部のライブラリは wasm32-wasi ターゲットと適切に互換性があっても、Flex Gateway にデプロイすると適切に動作しないことがあります。この状況が発生した場合のデプロイメントエラーの例は次のとおりです。

  • Failed to load Wasm module due to a missing import (インポートが欠落しているため Wasm モジュールの読み込みに失敗しました)

  • Wasm VM failed to initialize Wasm code (Wasm VM が Wasm コードの初期化に失敗しました)

  • Plugin configured to fail closed failed to load (フェールクローズに設定されたプラグインの読み込みに失敗しました)

これらの問題を解決するには、サードパーティライブラリのオーナーに問い合わせるか、別のライブラリを使用してください。
8. 次のコマンドでカスタムポリシーをコンパイルします。 cargo build --target wasm32-wasi --release コンパイルにより、バイナリ ​`.wasm`​ ファイルが ​`./target/wasm32-wasi/release`​ ディレクトリに出力されます。 Exchange へのカスタムポリシーのパブリッシュついての詳細は、​[「Flex Gateway または Mule 4 カスタムポリシーのパブリッシュ」](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-flex-getting-started)​を参照してください。 # SOAP API のトラブルシューティング Flex Gateway では SOAP API がネイティブではサポートされず、XML のスキーマ検証が一切提供されません。ただし、HTTP API インスタンスをセキュアな SOAP アップストリームサービスにパブリッシュすることはできます。 セキュアな SOAP API アップストリームサービスに対する HTTP API インスタンスを作成するには、以下を参照してください。 - [接続モードでの Flex Gateway API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-publish-apis-conn) - [ローカルモードでの Flex Gateway API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-publish-apis-local) ## [](#soap-api-のパブリッシュ)Soap API のパブリッシュ SOAP API を HTTP API インスタンスとしてパブリッシュする方法に関する詳細情報は、次の動画を参照してください。 ![](https://play.vidyard.com/egZPDMSw2nMkfXxYPvbWUx.jpg) ## [](#soap-api-ポリシーに関する制限事項)SOAP API ポリシーに関する制限事項 Flex Gateway ポリシーでは、ポリシーが要求をブロックしたときに JSON エラーメッセージが返されます。ほとんどの SOAP クライアントは JSON メッセージを読み取ることができません。 SOAP API では、次のポリシーはサポートされていません。 - [スキーマ検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-schema-validation) - [JSON 脅威保護ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-json-threat-protection) # SOAP API のトラブルシューティング Flex Gateway では SOAP API がネイティブではサポートされず、XML のスキーマ検証が一切提供されません。ただし、HTTP API インスタンスをセキュアな SOAP アップストリームサービスにパブリッシュすることはできます。 セキュアな SOAP API アップストリームサービスに対する HTTP API インスタンスを作成するには、以下を参照してください。 - [管理ゲートウェイと接続モード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-publish-apis-conn) - [ローカルモード API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-publish-apis-local) ## [](#soap-api-のパブリッシュ)Soap API のパブリッシュ SOAP API を HTTP API インスタンスとしてパブリッシュする方法に関する詳細情報は、次の動画を参照してください。 Unresolved include directive in modules/ROOT/pages/flex-troubleshoot-soap-apis.adoc - include::\_partials/soap-api-video.html\[\] ## [](#soap-api-ポリシーに関する制限事項)SOAP API ポリシーに関する制限事項 Flex Gateway ポリシーでは、ポリシーが要求をブロックしたときに JSON エラーメッセージが返されます。ほとんどの SOAP クライアントは JSON メッセージを読み取ることができません。 SOAP API では、次のポリシーはサポートされていません。 - [スキーマ検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-schema-validation) - [JSON 脅威保護ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-json-threat-protection) # SOAP スキーマ検証ポリシー

ポリシー名

SOAP スキーマ検証

概要

指定された WSDL スキーマに対して受信トラフィックを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.10.0

返される状況コード

このポリシーでは、クライアントエラーの場合は ​400​ が、サーバーエラーの場合は ​500​ が返されます。エラーメッセージは SOAP 標準応答によって定義されます。
## [](#概要)概要
スキーマ検証ポリシーでは SOAP 1.1 および 1.2 の API のみがサポートされます。
SOAP スキーマ検証ポリシーを使用して、定義した WSDL スキーマに準拠していない受信要求をブロックします。このポリシーにより、不正な、または悪意のある SOAP メッセージがバックエンドに到達するのを防止し、クライアントとサービス間でコントラクトのコンプライアンスを適用します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: soap-validation config: wsdlUrl: // REQUIRED encoding: // REQUIRED, default 'UTF-8' serviceName: // REQUIRED servicePort: // REQUIRED スキーマがこの YAML リソースで指定されているか、Exchange の API コンテキストで指定されているか (接続モードのみ) を決定します。サポートされている値: `inline`​ または ​`context`​。ローカルモードでポリシーを設定する場合、​`inline`​ を指定する必要があります。
パラメーター 必須 デフォルト値 説明

wsdlUrl

はい

なし

WSDL にアクセスする場所の URL

encoding

はい

UTF-8

WSDL のエンコーディング

serviceName

はい

なし

要求を検証する WSDL で定義された SOAP サービス名

servicePort

はい

なし

要求を検証する WSDL で定義された SOAP ポート名
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: soap-validation config: wsdlUrl: encoding: UTF-8 serviceName: servicePort: ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
項目 説明

Service Name (サービス名)

要求を検証する WSDL で定義された SOAP サービス名

Service Port (サービスポート)

要求を検証する WSDL で定義された SOAP ポート名
## [](#関連情報)関連情報 - [XML 脅威保護ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-xml-threat-protection) # SSE ログポリシー

ポリシー名

SSE ログ

概要

ストリーミング中にすべての SSE イベントを記録します

カテゴリ

SSE

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 SSE ログポリシーにより、SSE 接続を記録できます。設定した SSE ログは Flex Gateway ログに表示されます。
このポリシーでは SSE イベントのログのみが提供されます。SSE 以外の情報を記録するには、メッセージログポリシーを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード SSE ログポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

ログ

すべての SSE イベントで実行されたログのリスト。

DataWeave expression for SSE response messages (SSE 応答メッセージの DataWeave 式)

SSE イベントから情報を抽出する DataWeave 式。イベントのペイロードには ​[payload]​ を、イベントデータには ​[vars.data]​ を、イベント ID には ​#[vars.id]​ を使用します。

Category (カテゴリ)

各ログメッセージに追加する文字列プレフィックス。

Level (レベル)

記録するメッセージのレベル (​INFO (情報)​、​WARN (警告)​、​ERROR​ (エラー)、​DEBUG (デバッグ)​) を定義します。
詳細は、​メッセージログの重要度レベル​を参照してください。
## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# SSE ログポリシー

ポリシー名

SSE ログ

概要

ストリーミング中にすべての SSE イベントを記録します

カテゴリ

SSE

使用可能な最小 Flex Gateway バージョン

v1.9.3

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 SSE ログポリシーにより、SSE 接続を記録できます。設定した SSE ログは Flex Gateway ログに表示されます。
このポリシーでは SSE イベントのログのみが提供されます。SSE 以外の情報を記録するには、メッセージログポリシーを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード SSE ログポリシーはローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明

ログ

すべての SSE イベントで実行されたログのリスト。

DataWeave expression for SSE response messages (SSE 応答メッセージの DataWeave 式)

SSE イベントから情報を抽出する DataWeave 式。イベントのペイロードには ​[payload]​ を、イベントデータには ​[vars.data]​ を、イベント ID には ​#[vars.id]​ を使用します。

Category (カテゴリ)

各ログメッセージに追加する文字列プレフィックス。

Level (レベル)

記録するメッセージのレベル (​INFO (情報)​、​WARN (警告)​、​ERROR​ (エラー)、​DEBUG (デバッグ)​) を定義します。
詳細は、​メッセージログの重要度レベル​を参照してください。
## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# Transport Layer Security ポリシー - アウトバウンド

ポリシー名

Transport Layer Security (TLS) - アウトバウンド

概要

API プロキシとアップストリームサービス間の双方向認証を有効にする

カテゴリ

セキュリティ

使用可能な最小 Flex バージョン

v1.4.0

返される状況コード

このポリシーの戻りコードは存在しません。

次のドキュメントは、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで TLS を設定するには、接続モードでの Flex Gateway の TLS コンテキストの設定を参照してください。
## [](#概要)概要 Flex Gateway では、ローカルモードでアウトバウンド TLS (Transport Layer Security) とアウトバウンド相互認証 TLS (mTLS) がサポートされます。 デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 ローカルモードでアウトバウンド TLS を適用するには、​[「ローカルモードでの Flex Gateway の TLS コンテキストの設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config)​チュートリアルを使用して、このドキュメントの次の設定ファイルを参照してください。 アウトバウンド TLS コンテキストを設定して API インスタンスとアップストリームサービス間の認証を有効にするには、TLS ポリシーをアップストリームサービスにバインドすることができます。 インバウンド TLS とは異なり、API アップストリームサービスは異なるプロバイダーから提供される可能性があるため、Flex Gateway のすべての API インスタンスに同じアウトバウンド TLS コンテキストを適用することはお勧めできません。そのため、すべてのインスタンスでのアウトバウンド TLS の設定例は提供されていません。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを適用できます。

TLS ポリシーでは、ポリシー順序はサポートされません。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 Flex Gateway をランタイムとして使用して API インスタンスとアップストリームサービス間のアウトバウンド TLS を有効にするには、YAML 設定ファイルで TLS コンテキストを手動で設定する必要があります。 以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tls-outbound config: skipValidation: // REQUIRED certificate: // OPTIONAL key: // OPTIONAL crt: // OPTIONAL alpn: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL 省略可能なパラメーターを設定ファイルに含めない場合、パラメーターのデフォルト値が TLS コンテキストに適用されます。 `ciphers`​ パラメーターを設定する場合、リストされている暗号化が API アップストリームでサポートされることを確認してください。サポートされる暗号化については、​[「Flex Gateway での TLS 暗号化のサポート」](#local-support)​を参照してください。
パラメーター 必須または省略可能 デフォルト値 説明

skipValidation

必須

false

検証をスキップすると、アウトバウンド mTLS が無効になります

trustedCA

省略可能 (​skipValidation​ が false でない場合)

なし

mTLS で使用するクライアント証明書

certificate

省略可能

なし

TLS 証明書とキーのペア。セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

certificate.key

省略可能

なし

証明書の非公開鍵部分

certificate.crt

省略可能

なし

証明書の公開鍵部分

alpn

省略可能

h2​ および ​http/1.1

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

minversion

省略可能

1.2

許容される最小 TLS バージョン

maxversion

省略可能

1.3

許容される最大 TLS バージョン

ciphers

省略可能

デフォルトおよび他のサポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。

サポートされる TLS 暗号化のリスト (IANA 形式)。
### [](#リソースの設定例)リソースの設定例 YAML ファイルを書式設定して、アップストリームサービス用に TLS または mTLS を設定できます。 **特定のアップストリームサービスのアウトバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: tls-outbound spec: targetRef: kind: Service name: ingress-test-outbound-upstream policyRef: name: tls-outbound config: skipValidation: true certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- ``` この例では、​`alpn`​、​`minversion`​、​`maxversion`​、​`ciphers`​ のデフォルト値を使用します。 **特定のアップストリームサービスのアウトバウンド mTLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: mtls-outbound spec: targetRef: kind: Service name: ingress-test-outbound-upstream policyRef: name: tls-outbound config: skipValidation: false trustedCA: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ``` ## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) # Transport Layer Security ポリシー - アウトバウンド

ポリシー名

Transport Layer Security (TLS) - アウトバウンド

概要

API プロキシとアップストリームサービス間の双方向認証を有効にする

カテゴリ

セキュリティ

使用可能な最小 Flex バージョン

v1.4.0

返される状況コード

このポリシーの戻りコードは存在しません。

次のドキュメントは、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで TLS を設定するには、接続モードでの Flex Gateway の TLS コンテキストの設定を参照してください。
## [](#概要)概要 Flex Gateway では、ローカルモードでアウトバウンド TLS (Transport Layer Security) とアウトバウンド相互認証 TLS (mTLS) がサポートされます。 デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 ローカルモードでアウトバウンド TLS を適用するには、​[「ローカルモードでの Flex Gateway の TLS コンテキストの設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config)​チュートリアルを使用して、このドキュメントの次の設定ファイルを参照してください。 アウトバウンド TLS コンテキストを設定して API インスタンスとアップストリームサービス間の認証を有効にするには、TLS ポリシーをアップストリームサービスにバインドすることができます。 インバウンド TLS とは異なり、API アップストリームサービスは異なるプロバイダーから提供される可能性があるため、Flex Gateway のすべての API インスタンスに同じアウトバウンド TLS コンテキストを適用することはお勧めできません。そのため、すべてのインスタンスでのアウトバウンド TLS の設定例は提供されていません。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを適用できます。

TLS ポリシーでは、ポリシー順序はサポートされません。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 Flex Gateway をランタイムとして使用して API インスタンスとアップストリームサービス間のアウトバウンド TLS を有効にするには、YAML 設定ファイルで TLS コンテキストを手動で設定する必要があります。 以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tls-outbound config: skipValidation: // REQUIRED certificate: // OPTIONAL key: // OPTIONAL crt: // OPTIONAL alpn: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL 省略可能なパラメーターを設定ファイルに含めない場合、パラメーターのデフォルト値が TLS コンテキストに適用されます。 `ciphers`​ パラメーターを設定する場合、リストされている暗号化が API アップストリームでサポートされることを確認してください。サポートされる暗号化については、​[「Flex Gateway での TLS 暗号化のサポート」](#local-support)​を参照してください。
パラメーター 必須または省略可能 デフォルト値 説明

skipValidation

必須

false

検証をスキップすると、アウトバウンド mTLS が無効になります

trustedCA

省略可能 (​skipValidation​ が false でない場合)

なし

mTLS で使用するクライアント証明書

certificate

省略可能

なし

TLS 証明書とキーのペア。セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

certificate.key

省略可能

なし

証明書の非公開キー部分

certificate.crt

省略可能

なし

証明書の公開キー部分

alpn

省略可能

h2​ および ​http/1.1

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

minversion

省略可能

1.2

許容される最小 TLS バージョン

maxversion

省略可能

1.3

許容される最大 TLS バージョン

ciphers

省略可能

デフォルトおよび他のサポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。

サポートされる TLS 暗号化のリスト (IANA 形式)。
### [](#リソースの設定例)リソースの設定例 YAML ファイルを書式設定して、アップストリームサービス用に TLS または mTLS を設定できます。 **特定のアップストリームサービスのアウトバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: tls-outbound spec: targetRef: kind: Service name: ingress-test-outbound-upstream policyRef: name: tls-outbound config: skipValidation: true certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- ``` この例では、​`alpn`​、​`minversion`​、​`maxversion`​、​`ciphers`​ のデフォルト値を使用します。 **特定のアップストリームサービスのアウトバウンド mTLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: mtls-outbound spec: targetRef: kind: Service name: ingress-test-outbound-upstream policyRef: name: tls-outbound config: skipValidation: false trustedCA: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ``` ## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) # Transport Layer Security ポリシー - アウトバウンド

ポリシー名

Transport Layer Security (TLS) - アウトバウンド

概要

API プロキシとアップストリームサービス間の双方向認証を有効にする

カテゴリ

セキュリティ

使用可能な最小 Flex バージョン

v1.4.0

返される状況コード

このポリシーの戻りコードは存在しません。

次のドキュメントは、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで TLS を設定するには、接続モードでの Flex Gateway の TLS コンテキストの設定を参照してください。
## [](#概要)概要 Flex Gateway では、ローカルモードでアウトバウンド TLS (Transport Layer Security) とアウトバウンド相互認証 TLS (mTLS) がサポートされます。 デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 ローカルモードでアウトバウンド TLS を適用するには、​[「ローカルモードでの Flex Gateway の TLS コンテキストの設定」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config)​チュートリアルを使用して、このドキュメントの次の設定ファイルを参照してください。 アウトバウンド TLS コンテキストを設定して API インスタンスとアップストリームサービス間の認証を有効にするには、TLS ポリシーをアップストリームサービスにバインドすることができます。 インバウンド TLS とは異なり、API アップストリームサービスは異なるプロバイダーから提供される可能性があるため、Flex Gateway のすべての API インスタンスに同じアウトバウンド TLS コンテキストを適用することはお勧めできません。そのため、すべてのインスタンスでのアウトバウンド TLS の設定例は提供されていません。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを適用できます。

TLS ポリシーでは、ポリシー順序はサポートされません。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 Flex Gateway をランタイムとして使用して API インスタンスとアップストリームサービス間のアウトバウンド TLS を有効にするには、YAML 設定ファイルで TLS コンテキストを手動で設定する必要があります。 以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tls-outbound config: skipValidation: // REQUIRED certificate: // OPTIONAL key: // OPTIONAL crt: // OPTIONAL alpn: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL 省略可能なパラメーターを設定ファイルに含めない場合、パラメーターのデフォルト値が TLS コンテキストに適用されます。 `ciphers`​ パラメーターを設定する場合、リストされている暗号化が API アップストリームでサポートされることを確認してください。サポートされる暗号化については、​[「Flex Gateway での TLS 暗号化のサポート」](#local-support)​を参照してください。
パラメーター 必須または省略可能 デフォルト値 説明

skipValidation

必須

false

検証をスキップすると、アウトバウンド mTLS が無効になります

trustedCA

省略可能 (​skipValidation​ が false でない場合)

なし

mTLS で使用するクライアント証明書

certificate

省略可能

なし

TLS 証明書とキーのペア。セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

certificate.key

省略可能

なし

証明書の非公開鍵部分

certificate.crt

省略可能

なし

証明書の公開鍵部分

alpn

省略可能

h2​ および ​http/1.1

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

minversion

省略可能

1.2

許容される最小 TLS バージョン

maxversion

省略可能

1.3

許容される最大 TLS バージョン

ciphers

省略可能

デフォルトおよび他のサポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。

サポートされる TLS 暗号化のリスト (IANA 形式)。
### [](#リソースの設定例)リソースの設定例 YAML ファイルを書式設定して、アップストリームサービス用に TLS または mTLS を設定できます。 **特定のアップストリームサービスのアウトバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: tls-outbound spec: targetRef: kind: Service name: ingress-test-outbound-upstream policyRef: name: tls-outbound config: skipValidation: true certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- ``` この例では、​`alpn`​、​`minversion`​、​`maxversion`​、​`ciphers`​ のデフォルト値を使用します。 **特定のアップストリームサービスのアウトバウンド mTLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: mtls-outbound spec: targetRef: kind: Service name: ingress-test-outbound-upstream policyRef: name: tls-outbound config: skipValidation: false trustedCA: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ``` ## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) # Transport Layer Security ポリシー - インバウンド

ポリシー名

Transport Layer Security (TLS) - インバウンド

概要

クライアントと API プロキシ間の認証を有効にする

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0 (インバウンド mTLS: v1.3.0)

返される状況コード

このポリシーの戻りコードは存在しません。

次のドキュメントは、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで TLS を設定するには、接続モードでの Flex Gateway の TLS コンテキストの設定を参照してください。
## [](#概要)概要 Flex Gateway では、ローカルモードでインバウンド TLS (Transport Layer Security) とインバウンド相互認証 TLS (mTLS) がサポートされます。 ローカルモードでインバウンド TLS を適用するには、​[「ローカルモードでの Flex Gateway の TLS コンテキストの設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config)​チュートリアルを使用して、このドキュメントの次の設定ファイルを参照してください。 インバウンド TLS コンテキストを設定してクライアントと API インスタンス間の認証 (HTTPS) を有効にするには、TLS ポリシーを対象の API インスタンスまたは Flex Gateway 内のすべてのインスタンスにバインドすることができます。 Flex Gateway はポートレベルのインバウンド TLS を実装します。つまり、他のインスタンスとポートを共有する API インスタンスにインバウンド TLS を適用すると、ポートを共有するすべてのインスタンスに同じインバウンド TLS コンテキストが適用されます。Flex Gateway は、1 つのゲートウェイで複数の TLS 証明書をサポートしますが、証明書は一意のポートに適用する必要があります。インバウンド TLS を 1 つの API インスタンスに適用する場合、そのポートを共有するインスタンスに同じインバウンド TLS コンテキストを適用する必要はありません。したがって、同じポートを共有する API インスタンスに異なるインバウンド TLS コンテキストを適用することはできません。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを適用できます。

TLS ポリシーでは、ポリシー順序はサポートされません。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 Flex Gateway をランタイムとして使用して API インスタンスを作成するときに HTTPS をスキーマとして使用するには、YAML 設定ファイルで TLS コンテキストを手動で設定する必要があります。 以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tls config: requireClientCertificate: // OPTIONAL trustedCA: // OPTIONAL certificate: // OPTIONAL key: // OPTIONAL crt: // OPTIONAL alpn: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL 省略可能なパラメーターを設定ファイルに含めない場合、パラメーターのデフォルト値が TLS コンテキストに適用されます。 `ciphers`​ パラメーターを設定する場合、サポートされる暗号化については、​[「Flex Gateway での TLS 暗号化のサポート」](#local-support)​を参照してください。
パラメーター 必須または省略可能 デフォルト値 説明

requireClientCertificate

省略可能

false

インバウンド mTLS の有効化/無効化

trustedCA

省略可能 (​requireClientCertificate​ が true でない場合)

なし

mTLS で使用するクライアント証明書

certificate

省略可能

なし

TLS 証明書とキーのペア。セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

certificate.key

省略可能

なし

証明書の非公開鍵部分

certificate.crt

省略可能

なし

証明書の公開鍵部分

alpn

省略可能

h2​ および ​http/1.1

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

minversion

省略可能

1.2

許容される最小 TLS バージョン

maxversion

省略可能

1.3

許容される最大 TLS バージョン

ciphers

省略可能

デフォルトおよび他のサポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。

サポートされる TLS 暗号化のリスト (IANA 形式)。サポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。
### [](#リソースの設定例)リソースの設定例 YAML ファイルを書式設定して、Flex Gateway で実行されている特定の API インスタンスまたはすべての API インスタンスに対して TLS または mTLS を設定できます。 #### [](#すべての-api-インスタンスに-tls-設定を適用)すべての API インスタンスに TLS 設定を適用 **この Flex Gateway で実行されているすべての API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: Selector selector: kind: ApiInstance policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ``` #### [](#特定の-api-インスタンスに-tls-設定を適用)特定の API インスタンスに TLS 設定を適用 **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ``` #### [](#特定の-api-インスタンスに-mtls-インバウンド設定を適用)特定の API インスタンスに mTLS インバウンド設定を適用 **特定の API インスタンスのインバウンド mTLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: mtls spec: targetRef: name: ingress-https policyRef: name: tls config: requireClientCertificate: true trustedCA: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- certificate: key: | # -----BEGIN RSA PRIVATE KEY----- # insert private key # -----END RSA PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- ``` この例では、​`alpn`​、​`minversion`​、​`maxversion`​、​`ciphers`​ のデフォルト値を使用します。 ## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。 ### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls-outbound) # Transport Layer Security ポリシー - インバウンド

ポリシー名

Transport Layer Security (TLS) - インバウンド

概要

クライアントと API プロキシ間の認証を有効にする

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0 (インバウンド mTLS: v1.3.0)

返される状況コード

このポリシーの戻りコードは存在しません。

次のドキュメントは、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで TLS を設定するには、接続モードでの Flex Gateway の TLS コンテキストの設定を参照してください。
## [](#概要)概要 Flex Gateway では、ローカルモードでインバウンド TLS (Transport Layer Security) とインバウンド相互認証 TLS (mTLS) がサポートされます。 ローカルモードでインバウンド TLS を適用するには、​[「ローカルモードでの Flex Gateway の TLS コンテキストの設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config)​チュートリアルを使用して、このドキュメントの次の設定ファイルを参照してください。 インバウンド TLS コンテキストを設定してクライアントと API インスタンス間の認証 (HTTPS) を有効にするには、TLS ポリシーを対象の API インスタンスまたは Flex Gateway 内のすべてのインスタンスにバインドすることができます。 Flex Gateway はポートレベルのインバウンド TLS を実装します。つまり、他のインスタンスとポートを共有する API インスタンスにインバウンド TLS を適用すると、ポートを共有するすべてのインスタンスに同じインバウンド TLS コンテキストが適用されます。Flex Gateway は、1 つのゲートウェイで複数の TLS 証明書をサポートしますが、証明書は一意のポートに適用する必要があります。インバウンド TLS を 1 つの API インスタンスに適用する場合、そのポートを共有するインスタンスに同じインバウンド TLS コンテキストを適用する必要はありません。したがって、同じポートを共有する API インスタンスに異なるインバウンド TLS コンテキストを適用することはできません。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを適用できます。

TLS ポリシーでは、ポリシー順序はサポートされません。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 Flex Gateway をランタイムとして使用して API インスタンスを作成するときに HTTPS をスキーマとして使用するには、YAML 設定ファイルで TLS コンテキストを手動で設定する必要があります。 以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tls config: requireClientCertificate: // OPTIONAL trustedCA: // OPTIONAL certificate: // OPTIONAL key: // OPTIONAL crt: // OPTIONAL alpn: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL 省略可能なパラメーターを設定ファイルに含めない場合、パラメーターのデフォルト値が TLS コンテキストに適用されます。 `ciphers`​ パラメーターを設定する場合、サポートされる暗号化については、​[「Flex Gateway での TLS 暗号化のサポート」](#local-support)​を参照してください。
パラメーター 必須または省略可能 デフォルト値 説明

requireClientCertificate

省略可能

false

インバウンド mTLS の有効化/無効化

trustedCA

省略可能 (​requireClientCertificate​ が true でない場合)

なし

mTLS で使用するクライアント証明書

certificate

省略可能

なし

TLS 証明書とキーのペア。セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

certificate.key

省略可能

なし

証明書の非公開キー部分

certificate.crt

省略可能

なし

証明書の公開キー部分

alpn

省略可能

h2​ および ​http/1.1

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

minversion

省略可能

1.2

許容される最小 TLS バージョン

maxversion

省略可能

1.3

許容される最大 TLS バージョン

ciphers

省略可能

デフォルトおよび他のサポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。

サポートされる TLS 暗号化のリスト (IANA 形式)。サポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。
### [](#リソースの設定例)リソースの設定例 YAML ファイルを書式設定して、Flex Gateway で実行されている特定の API インスタンスまたはすべての API インスタンスに対して TLS または mTLS を設定できます。 #### [](#すべての-api-インスタンスに-tls-設定を適用)すべての API インスタンスに TLS 設定を適用 **この Flex Gateway で実行されているすべての API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: Selector selector: kind: ApiInstance policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ``` #### [](#特定の-api-インスタンスに-tls-設定を適用)特定の API インスタンスに TLS 設定を適用 **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ``` #### [](#特定の-api-インスタンスに-mtls-インバウンド設定を適用)特定の API インスタンスに mTLS インバウンド設定を適用 **特定の API インスタンスのインバウンド mTLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: mtls spec: targetRef: name: ingress-https policyRef: name: tls config: requireClientCertificate: true trustedCA: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- certificate: key: | # -----BEGIN RSA PRIVATE KEY----- # insert private key # -----END RSA PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- ``` この例では、​`alpn`​、​`minversion`​、​`maxversion`​、​`ciphers`​ のデフォルト値を使用します。 ## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。 ### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls-outbound) # Transport Layer Security ポリシー - インバウンド

ポリシー名

Transport Layer Security (TLS) - インバウンド

概要

クライアントと API プロキシ間の認証を有効にする

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0 (インバウンド mTLS: v1.3.0)

返される状況コード

このポリシーの戻りコードは存在しません。

次のドキュメントは、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで TLS を設定するには、接続モードでの Flex Gateway の TLS コンテキストの設定を参照してください。
## [](#概要)概要 Flex Gateway では、ローカルモードでインバウンド TLS (Transport Layer Security) とインバウンド相互認証 TLS (mTLS) がサポートされます。 ローカルモードでインバウンド TLS を適用するには、​[「ローカルモードでの Flex Gateway の TLS コンテキストの設定」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config)​チュートリアルを使用して、このドキュメントの次の設定ファイルを参照してください。 インバウンド TLS コンテキストを設定してクライアントと API インスタンス間の認証 (HTTPS) を有効にするには、TLS ポリシーを対象の API インスタンスまたは Flex Gateway 内のすべてのインスタンスにバインドすることができます。 Flex Gateway はポートレベルのインバウンド TLS を実装します。つまり、他のインスタンスとポートを共有する API インスタンスにインバウンド TLS を適用すると、ポートを共有するすべてのインスタンスに同じインバウンド TLS コンテキストが適用されます。Flex Gateway は、1 つのゲートウェイで複数の TLS 証明書をサポートしますが、証明書は一意のポートに適用する必要があります。インバウンド TLS を 1 つの API インスタンスに適用する場合、そのポートを共有するインスタンスに同じインバウンド TLS コンテキストを適用する必要はありません。したがって、同じポートを共有する API インスタンスに異なるインバウンド TLS コンテキストを適用することはできません。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを適用できます。

TLS ポリシーでは、ポリシー順序はサポートされません。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 Flex Gateway をランタイムとして使用して API インスタンスを作成するときに HTTPS をスキーマとして使用するには、YAML 設定ファイルで TLS コンテキストを手動で設定する必要があります。 以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tls config: requireClientCertificate: // OPTIONAL trustedCA: // OPTIONAL certificate: // OPTIONAL key: // OPTIONAL crt: // OPTIONAL alpn: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL 省略可能なパラメーターを設定ファイルに含めない場合、パラメーターのデフォルト値が TLS コンテキストに適用されます。 `ciphers`​ パラメーターを設定する場合、サポートされる暗号化については、​[「Flex Gateway での TLS 暗号化のサポート」](#local-support)​を参照してください。
パラメーター 必須または省略可能 デフォルト値 説明

requireClientCertificate

省略可能

false

インバウンド mTLS の有効化/無効化

trustedCA

省略可能 (​requireClientCertificate​ が true でない場合)

なし

mTLS で使用するクライアント証明書

certificate

省略可能

なし

TLS 証明書とキーのペア。セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。

certificate.key

省略可能

なし

証明書の非公開鍵部分

certificate.crt

省略可能

なし

証明書の公開鍵部分

alpn

省略可能

h2​ および ​http/1.1

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

minversion

省略可能

1.2

許容される最小 TLS バージョン

maxversion

省略可能

1.3

許容される最大 TLS バージョン

ciphers

省略可能

デフォルトおよび他のサポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。

サポートされる TLS 暗号化のリスト (IANA 形式)。サポートされる暗号化については、​「Flex Gateway での TLS 暗号化のサポート」​を参照してください。
### [](#リソースの設定例)リソースの設定例 YAML ファイルを書式設定して、Flex Gateway で実行されている特定の API インスタンスまたはすべての API インスタンスに対して TLS または mTLS を設定できます。 #### [](#すべての-api-インスタンスに-tls-設定を適用)すべての API インスタンスに TLS 設定を適用 **この Flex Gateway で実行されているすべての API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: Selector selector: kind: ApiInstance policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ``` #### [](#特定の-api-インスタンスに-tls-設定を適用)特定の API インスタンスに TLS 設定を適用 **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ``` #### [](#特定の-api-インスタンスに-mtls-インバウンド設定を適用)特定の API インスタンスに mTLS インバウンド設定を適用 **特定の API インスタンスのインバウンド mTLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: mtls spec: targetRef: name: ingress-https policyRef: name: tls config: requireClientCertificate: true trustedCA: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- certificate: key: | # -----BEGIN RSA PRIVATE KEY----- # insert private key # -----END RSA PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- ``` この例では、​`alpn`​、​`minversion`​、​`maxversion`​、​`ciphers`​ のデフォルト値を使用します。 ## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。 ### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls-outbound) Unresolved include directive in modules/ROOT/pages/flex-gateway-release-notes.adoc - include::release-notes::partial$flex-gateway/flex-gateway-rn-landing-page.adoc\[\] Unresolved include directive in modules/ROOT/pages/flex-gateway-release-notes.adoc - include::release-notes::partial$flex-gateway/flex-gateway-rn-landing-page.adoc\[\] Unresolved include directive in modules/ROOT/pages/flex-gateway-release-notes.adoc - include::release-notes::partial$flex-gateway/flex-gateway-rn-landing-page.adoc\[\] # XML 脅威保護ポリシー

ポリシー名

XML 脅威保護

概要

API 要求内の悪意のある XML から保護する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.10.0

返される状況コード

400 - Bad Request
## [](#概要)概要 XML 要求を処理するアプリケーションは、要素、属性、および深いネストレベルの異常な膨張により特徴付けられる攻撃を受けやすくなっています。攻撃者は再帰的な技法を使用してメモリリソースをコンシュームします。多くの場合、アプリケーションデータのサイズが劇的に増加することは、セキュリティリスクが発生していることを示します。XML 脅威保護ポリシーを使用して、定義済みの予期されるサイズを超える異常な要求を拒否します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: xml-threat-protection-flex config: maxNodeDepth: // OPTIONAL, default: -1 maxAttributeCountPerElement: // OPTIONAL, default: -1 maxChildCount: // OPTIONAL, default: -1 maxTextLength: // OPTIONAL, default: -1 maxAttributeLength: // OPTIONAL, default: -1 maxCommentLength: // OPTIONAL, default: -1
パラメーターを ​-1​ として定義すると、パラメーターは無制限になります。
パラメーター 必須 デフォルト値 説明

maxNodeDepth

いいえ

-1

XML ドキュメントの最大ノード深度を指定します。

maxAttributeCountPerElement

いいえ

-1

要素の最大属性数を指定します。名前空間の定義で使用される属性は含まれません。

maxChildCount

いいえ

-1

子の最大数。XML ドキュメント内の要素の子の最大数を指定します。

maxTextLength

いいえ

-1

XML ドキュメントに含まれるテキストノードの最大文字数を指定します。

maxAttributeLength

いいえ

-1

XML ドキュメント内の属性の最大文字数を指定します。

maxCommentLength

いいえ

-1

XML ドキュメント内のコメント文字の最大数を指定します。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: xml-threat-protection-flex config: maxNodeDepth: 1 maxAttributeCountPerElement: 1 maxChildCount: 2 maxTextLength: 20 maxAttributeLength: 20 maxCommentLength: 20 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
項目 説明

Maximum Node Depth (最大ノード深度)

XML ドキュメントの最大ノード深度を指定します。

Maximum Attribute Count Per Element (要素あたりの最大属性数)

要素の最大属性数を指定します。名前空間の定義で使用される属性は含まれません。

Maximum Child Count (子の最大数)

子の最大数。XML ドキュメント内の要素の子の最大数を指定します。

Maximum Text Length (最大テキスト長)

XML ドキュメントに含まれるテキストノードの最大文字数を指定します。

Maximum Attribute Length (最大属性長)

XML ドキュメント内の属性の最大文字数を指定します。

Maximum Comment Length (最大コメント長)

XML ドキュメント内のコメント文字の最大数を指定します。
# アウトバウンドポリシーディレクトリ ## [](#flex-gateway-に含まれているアウトバウンドポリシー)Flex Gateway に含まれているアウトバウンドポリシー
ポリシー カテゴリ 概要

AWS lambda

変換

標準の HTTP 要求から AWS Lambda 関数をトリガーする

サーキットブレーカー

サービス品質

アップストリームが受信する要求または接続が多くなりすぎるのを防止する

ログイン情報挿入基本認証

セキュリティ

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

ログイン情報挿入 OAuth 2.0

セキュリティ

要求または応答にヘッダーを追加する

アップストリームアイドルタイムアウト

サービス品質

Flex Gateway とアップストリームサービス間のストリームの最大アイドル期間を設定する
## [](#関連情報)関連情報 - [ゲートウェイ別のポリシーの可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) # アウトバウンドポリシーディレクトリ ## [](#flex-gateway-に含まれているアウトバウンドポリシー)Flex Gateway に含まれているアウトバウンドポリシー
ポリシー カテゴリ 概要

AWS lambda

変換

標準の HTTP 要求から AWS Lambda 関数をトリガーする

サーキットブレーカー

サービス品質

アップストリームが受信する要求または接続が多くなりすぎるのを防止する

ログイン情報挿入基本認証

セキュリティ

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

ログイン情報挿入 OAuth 2.0

セキュリティ

要求または応答にヘッダーを追加する

アップストリームアイドルタイムアウト

サービス品質

Flex Gateway とアップストリームサービス間のストリームの最大アイドル期間を設定する
## [](#関連情報)関連情報 - [ゲートウェイ別のポリシーの可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) # アップストリームアイドルタイムアウトポリシー

ポリシー名

ストリームアイドルタイムアウト

Summary (概要)

Flex Gateway とアップストリームサービス間のストリームの最大アイドル期間を設定する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

504 - アップストリーム要求タイムアウト
## [](#概要)概要 アップストリームアイドルタイムアウトポリシーでは、Flex Gateway とアップストリームサービス間のストリームの要求から要求までの最大アイドル期間を設定できます。このポリシーを適用することにより、アイドル状態の接続によってリソースがコンシュームされるのを防止すると同時に、永続接続を開いたままにすることができます。タイムアウトは最後の要求の時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 60 秒のアップストリームタイムアウトが設定されています。このポリシーを適用すると、デフォルトのタイムアウトを上書きします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: idle-timeout-flex config: timeout: number // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

timeout

必須

60

Flex Gateway が接続を終了するまでの秒数。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: idle-timeout-flex config: timeout: 3 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Upstream idle timeout (アップストリームアイドルタイムアウト)

Flex Gateway が接続を終了するまでの秒数。

はい
# アップストリームアイドルタイムアウトポリシー

ポリシー名

ストリームアイドルタイムアウト

Summary (概要)

Flex Gateway とアップストリームサービス間のストリームの最大アイドル期間を設定する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

504 - アップストリーム要求タイムアウト
## [](#概要)概要 アップストリームアイドルタイムアウトポリシーでは、Flex Gateway とアップストリームサービス間のストリームの要求から要求までの最大アイドル期間を設定できます。このポリシーを適用することにより、アイドル状態の接続によってリソースがコンシュームされるのを防止すると同時に、永続接続を開いたままにすることができます。タイムアウトは最後の要求の時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 60 秒のアップストリームタイムアウトが設定されています。このポリシーを適用すると、デフォルトのタイムアウトを上書きします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: idle-timeout-flex config: timeout: number // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

timeout

必須

60

Flex Gateway が接続を終了するまでの秒数。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: idle-timeout-flex config: timeout: 3 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Upstream idle timeout (アップストリームアイドルタイムアウト)

Flex Gateway が接続を終了するまでの秒数。

はい
# インテグレーションユースケース 次のインテグレーションユースケースは、API プロバイダーと API コンシューマーの所有権によって決まります。各ユースケースでは、システムの必要なサービスを示す物理的なパターンを示します。 次のユースケース図では、Flex Gateway が接続モードで実行されています。ただし、Flex Gateway をローカルモードで実行したり、同じ環境または異なる環境の別々のランタイムで接続モードとローカルモードを組み合わせて使用したりすることもできます。 ユースケース図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 Flex Gateway では 4 つのユースケースがサポートされています。 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc4) ![4 つのユースケースは、ユースケースでサポートできる製品にリンクされています。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-intergration-use-cases.png) 各ユースケースでは、Flex Gateway があるネットワークに相対的な API の場所によって異なるインテグレーションパターンがサポートされています。システムの API オーナーおよびネットワークに応じて、異なるユースケースパターンを使用できます。 ユースケースごとに、3 つの異なるネットワーク分類があります。この分類は、各ネットワークと組織および Flex Gateway のあるネットワークの関係を表しています。 - 組織の内部 Flex Gateway と同じネットワークにある、組織が所有しているネットワーク - 組織の外部 Flex Gateway とは異なるネットワークにある、組織外部の信頼済みネットワーク (組織の Splunk インスタンスなど) - 組織以外の外部 Flex Gateway とは異なるネットワークにある、会社で信頼していない外部ネットワーク。API プロバイダーまたは API コンシューマーのネットワーク状況は、ネットワーク間の通信時に必要なセキュリティプロトコル (mTLS) に影響します。 組織が所有している API プロバイダーまたは API コンシューマーは、組織の内部ネットワークまたはその外部ネットワークのいずれかに属します。 次の表には、以下の内容が記載されています。 - 前述のユースケースに関連付けられたユースケースパターン - パターンに関与するネットワーク - Flex Gateway の機能 (イングレス、エグレス、またはその両方) ## [](#ユースケース-1-組織が所有している-api-が組織が所有している-api-コンシューマーに公開されている)ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 1A: 組織の内部 API が API と同じ VPC またはネットワークを使用する組織の内部コンシューマーに公開されている

組織の内部

組織の内部

イングレス

パターン 1B: 組織の内部 API が API とは異なる VPC またはネットワークを使用する組織の内部コンシューマーに公開されている

組織の内部

組織の内部

イングレス

パターン 2: 組織の内部 API が組織の外部コンシューマーに公開されている

組織の内部

組織の外部

イングレス

パターン 3: 組織の外部 API が組織の内部コンシューマーに公開されている

組織の外部

組織の内部

エグレス

パターン 4: 組織の外部 API が組織の外部コンシューマーに公開されている

組織の外部

組織の外部

イングレスとエグレス
## [](#ユースケース-2-組織が所有している-api-が組織以外が所有している-api-コンシューマーに公開されている)ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 5: 組織の内部 API が組織以外の外部コンシューマーに公開されている

組織の内部

組織以外の外部

イングレス

パターン 6: 組織の外部 API が組織以外の外部コンシューマーに公開されている

組織の外部

組織以外の外部

イングレスとエグレス
## [](#ユースケース-3-組織以外が所有している-api-が組織が所有している-api-コンシューマーに公開されている)ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 7: 組織以外の外部 API が組織の内部コンシューマーに公開されている

組織以外の外部

組織の内部

エグレス

パターン 8: 組織以外の外部 API が組織の外部コンシューマーに公開されている

組織以外の外部

組織の外部

イングレスとエグレス
## [](#ユースケース-4-組織以外が所有している-api-が組織以外が所有している外部-api-コンシューマーに公開されている)ユースケース 4: 組織以外が所有している API が組織以外が所有している外部 API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 9: 組織以外の外部 API が組織以外の外部コンシューマーに公開されている

組織以外の外部

組織以外の外部

イングレスとエグレス
## [](#インテグレーションフローに関する-mtls-の考慮事項)インテグレーションフローに関する mTLS の考慮事項 Flex Gateway では、Flex Gateway が開始および終了するすべての接続で相互トランスポートレイヤーセキュリティ (mTLS) がサポートされています。すべての通信フローで mTLS を使用することをお勧めします。 ネットワークセキュリティ境界を越えるインバウンド接続の場合、ネットワークアプリケーションファイアウォールをできる限り境界の近くで使用します。インバウンド接続では、外部 mTLS 接続がファイアウォールで終了するように設定し、ファイアウォールと Flex Gateway 間で新しい mTLS コンテキストを設定します。 ### [](#認証機関)認証機関 インテグレーションの種別に応じて、異なる認証機関 (CA) が mTLS 接続に参加します。ユースケース図では、色分けと表示ラベルで異なる mTLS コンテキストを表しています。各 mTLS コンテキストには、向こう側の証明書を検証するための CA があるトラストストアと、同じ CA で発行された証明書があるキーストアが含まれています。次の表に、考えられる 3 つの mTLS コンテキストを示します。
mTLS コンテキスト記号 認証機関 説明

組織の内部 mTLS 記号

組織の内部 mTLS

内部ネットワーク通信では、顧客組織が内部組織内でのみこれらの証明書を使用することが想定されています。

組織の外部 mTLS 記号

組織の外部 mTLS

公開インターネットを介した信頼済み関係者との外部通信では、組織は提供するサービスに外部コンシューマーまたはサードパーティがアクセスするための証明書を発行できます。

組織以外の外部 mTLS 記号

組織以外の外部 mTLS

信頼されていないエンティティとの外部通信では、サードパーティ組織が CA を制御します。サードパーティ CA は、サードパーティサービスと通信するときに組織で使用する証明書を発行します。
## [](#関連情報)関連情報 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-basic-deployments) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-shared-storage) # インテグレーションユースケース 次のインテグレーションユースケースは、API プロバイダーと API コンシューマーの所有権によって決まります。各ユースケースでは、システムの必要なサービスを示す物理的なパターンを示します。 次のユースケース図では、Flex Gateway が接続モードで実行されています。ただし、Flex Gateway をローカルモードで実行したり、同じ環境または異なる環境の別々のランタイムで接続モードとローカルモードを組み合わせて使用したりすることもできます。 ユースケース図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 Flex Gateway では 4 つのユースケースがサポートされています。 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc4) ![4 つのユースケースは、ユースケースでサポートできる製品にリンクされています。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-intergration-use-cases.png) 各ユースケースでは、Flex Gateway があるネットワークに相対的な API の場所によって異なるインテグレーションパターンがサポートされています。システムの API オーナーおよびネットワークに応じて、異なるユースケースパターンを使用できます。 ユースケースごとに、3 つの異なるネットワーク分類があります。この分類は、各ネットワークと組織および Flex Gateway のあるネットワークの関係を表しています。 - 組織の内部 Flex Gateway と同じネットワークにある、組織が所有しているネットワーク - 組織の外部 Flex Gateway とは異なるネットワークにある、組織外部の信頼済みネットワーク (組織の Splunk インスタンスなど) - 組織以外の外部 Flex Gateway とは異なるネットワークにある、会社で信頼していない外部ネットワーク。API プロバイダーまたは API コンシューマーのネットワーク状況は、ネットワーク間の通信時に必要なセキュリティプロトコル (mTLS) に影響します。 組織が所有している API プロバイダーまたは API コンシューマーは、組織の内部ネットワークまたはその外部ネットワークのいずれかに属します。 次の表には、以下の内容が記載されています。 - 前述のユースケースに関連付けられたユースケースパターン - パターンに関与するネットワーク - Flex Gateway の機能 (イングレス、エグレス、またはその両方) ## [](#ユースケース-1-組織が所有している-api-が組織が所有している-api-コンシューマーに公開されている)ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 1A: 組織の内部 API が API と同じ VPC またはネットワークを使用する組織の内部コンシューマーに公開されている

組織の内部

組織の内部

イングレス

パターン 1B: 組織の内部 API が API とは異なる VPC またはネットワークを使用する組織の内部コンシューマーに公開されている

組織の内部

組織の内部

イングレス

パターン 2: 組織の内部 API が組織の外部コンシューマーに公開されている

組織の内部

組織の外部

イングレス

パターン 3: 組織の外部 API が組織の内部コンシューマーに公開されている

組織の外部

組織の内部

エグレス

パターン 4: 組織の外部 API が組織の外部コンシューマーに公開されている

組織の外部

組織の外部

イングレスとエグレス
## [](#ユースケース-2-組織が所有している-api-が組織以外が所有している-api-コンシューマーに公開されている)ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 5: 組織の内部 API が組織以外の外部コンシューマーに公開されている

組織の内部

組織以外の外部

イングレス

パターン 6: 組織の外部 API が組織以外の外部コンシューマーに公開されている

組織の外部

組織以外の外部

イングレスとエグレス
## [](#ユースケース-3-組織以外が所有している-api-が組織が所有している-api-コンシューマーに公開されている)ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 7: 組織以外の外部 API が組織の内部コンシューマーに公開されている

組織以外の外部

組織の内部

エグレス

パターン 8: 組織以外の外部 API が組織の外部コンシューマーに公開されている

組織以外の外部

組織の外部

イングレスとエグレス
## [](#ユースケース-4-組織以外が所有している-api-が組織以外が所有している外部-api-コンシューマーに公開されている)ユースケース 4: 組織以外が所有している API が組織以外が所有している外部 API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 9: 組織以外の外部 API が組織以外の外部コンシューマーに公開されている

組織以外の外部

組織以外の外部

イングレスとエグレス
## [](#インテグレーションフローに関する-mtls-の考慮事項)インテグレーションフローに関する mTLS の考慮事項 Flex Gateway では、Flex Gateway が開始および終了するすべての接続で相互トランスポートレイヤーセキュリティ (mTLS) がサポートされています。すべての通信フローで mTLS を使用することをお勧めします。 ネットワークセキュリティ境界を越えるインバウンド接続の場合、ネットワークアプリケーションファイアウォールをできる限り境界の近くで使用します。インバウンド接続では、外部 mTLS 接続がファイアウォールで終了するように設定し、ファイアウォールと Flex Gateway 間で新しい mTLS コンテキストを設定します。 ### [](#認証機関)認証機関 インテグレーションの種別に応じて、異なる認証機関 (CA) が mTLS 接続に参加します。ユースケース図では、色分けと表示ラベルで異なる mTLS コンテキストを表しています。各 mTLS コンテキストには、向こう側の証明書を検証するための CA があるトラストストアと、同じ CA で発行された証明書があるキーストアが含まれています。次の表に、考えられる 3 つの mTLS コンテキストを示します。
mTLS コンテキスト記号 認証機関 説明

中央に mTLS と書かれた白色の六角形

組織の内部 mTLS

内部ネットワーク通信では、顧客組織が内部組織内でのみこれらの証明書を使用することが想定されています。

中央に mTLS と書かれた緑色の六角形

組織の外部 mTLS

公開インターネットを介した信頼済み関係者との外部通信では、組織は提供するサービスに外部コンシューマーまたはサードパーティがアクセスするための証明書を発行できます。

中央に mTLS と書かれた灰色の六角形

組織以外の外部 mTLS

信頼されていないエンティティとの外部通信では、サードパーティ組織が CA を制御します。サードパーティ CA は、サードパーティサービスと通信するときに組織で使用する証明書を発行します。
## [](#関連情報)関連情報 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-basic-deployments) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-shared-storage) # インテグレーションユースケース 次のインテグレーションユースケースは、API プロバイダーと API コンシューマーの所有権によって決まります。各ユースケースでは、システムの必要なサービスを示す物理的なパターンを示します。 次のユースケース図では、Flex Gateway が接続モードで実行されています。ただし、Flex Gateway をローカルモードで実行したり、同じ環境または異なる環境の別々のランタイムで接続モードとローカルモードを組み合わせて使用したりすることもできます。 ユースケース図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 Flex Gateway では 4 つのユースケースがサポートされています。 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc4) ![4 つのユースケースは、ユースケースでサポートできる製品にリンクされています。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-intergration-use-cases.png) 各ユースケースでは、Flex Gateway があるネットワークに相対的な API の場所によって異なるインテグレーションパターンがサポートされています。システムの API オーナーおよびネットワークに応じて、異なるユースケースパターンを使用できます。 ユースケースごとに、3 つの異なるネットワーク分類があります。この分類は、各ネットワークと組織および Flex Gateway のあるネットワークの関係を表しています。 - 組織の内部 Flex Gateway と同じネットワークにある、組織が所有しているネットワーク - 組織の外部 Flex Gateway とは異なるネットワークにある、組織外部の信頼済みネットワーク (組織の Splunk インスタンスなど) - 組織以外の外部 Flex Gateway とは異なるネットワークにある、会社で信頼していない外部ネットワーク。API プロバイダーまたは API コンシューマーのネットワーク状況は、ネットワーク間の通信時に必要なセキュリティプロトコル (mTLS) に影響します。 組織が所有している API プロバイダーまたは API コンシューマーは、組織の内部ネットワークまたはその外部ネットワークのいずれかに属します。 次の表には、以下の内容が記載されています。 - 前述のユースケースに関連付けられたユースケースパターン - パターンに関与するネットワーク - Flex Gateway の機能 (イングレス、エグレス、またはその両方) ## [](#ユースケース-1-組織が所有している-api-が組織が所有している-api-コンシューマーに公開されている)ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 1A: 組織の内部 API が API と同じ VPC またはネットワークを使用する組織の内部コンシューマーに公開されている

組織の内部

組織の内部

イングレス

パターン 1B: 組織の内部 API が API とは異なる VPC またはネットワークを使用する組織の内部コンシューマーに公開されている

組織の内部

組織の内部

イングレス

パターン 2: 組織の内部 API が組織の外部コンシューマーに公開されている

組織の内部

組織の外部

イングレス

パターン 3: 組織の外部 API が組織の内部コンシューマーに公開されている

組織の外部

組織の内部

エグレス

パターン 4: 組織の外部 API が組織の外部コンシューマーに公開されている

組織の外部

組織の外部

イングレスとエグレス
## [](#ユースケース-2-組織が所有している-api-が組織以外が所有している-api-コンシューマーに公開されている)ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 5: 組織の内部 API が組織以外の外部コンシューマーに公開されている

組織の内部

組織以外の外部

イングレス

パターン 6: 組織の外部 API が組織以外の外部コンシューマーに公開されている

組織の外部

組織以外の外部

イングレスとエグレス
## [](#ユースケース-3-組織以外が所有している-api-が組織が所有している-api-コンシューマーに公開されている)ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 7: 組織以外の外部 API が組織の内部コンシューマーに公開されている

組織以外の外部

組織の内部

エグレス

パターン 8: 組織以外の外部 API が組織の外部コンシューマーに公開されている

組織以外の外部

組織の外部

イングレスとエグレス
## [](#ユースケース-4-組織以外が所有している-api-が組織以外が所有している外部-api-コンシューマーに公開されている)ユースケース 4: 組織以外が所有している API が組織以外が所有している外部 API コンシューマーに公開されている
パターン プロバイダーネットワーク コンシューマーネットワーク Flex Gateway の役割

パターン 9: 組織以外の外部 API が組織以外の外部コンシューマーに公開されている

組織以外の外部

組織以外の外部

イングレスとエグレス
## [](#インテグレーションフローに関する-mtls-の考慮事項)インテグレーションフローに関する mTLS の考慮事項 Flex Gateway では、Flex Gateway が開始および終了するすべての接続で相互トランスポートレイヤーセキュリティ (mTLS) がサポートされています。すべての通信フローで mTLS を使用することをお勧めします。 ネットワークセキュリティ境界を越えるインバウンド接続の場合、ネットワークアプリケーションファイアウォールをできる限り境界の近くで使用します。インバウンド接続では、外部 mTLS 接続がファイアウォールで終了するように設定し、ファイアウォールと Flex Gateway 間で新しい mTLS コンテキストを設定します。 ### [](#認証機関)認証機関 インテグレーションの種別に応じて、異なる認証機関 (CA) が mTLS 接続に参加します。ユースケース図では、色分けと表示ラベルで異なる mTLS コンテキストを表しています。各 mTLS コンテキストには、向こう側の証明書を検証するための CA があるトラストストアと、同じ CA で発行された証明書があるキーストアが含まれています。次の表に、考えられる 3 つの mTLS コンテキストを示します。
mTLS コンテキスト記号 認証機関 説明

組織の内部 mTLS 記号

組織の内部 mTLS

内部ネットワーク通信では、顧客組織が内部組織内でのみこれらの証明書を使用することが想定されています。

組織の外部 mTLS 記号

組織の外部 mTLS

公開インターネットを介した信頼済み関係者との外部通信では、組織は提供するサービスに外部コンシューマーまたはサードパーティがアクセスするための証明書を発行できます。

組織以外の外部 mTLS 記号

組織以外の外部 mTLS

信頼されていないエンティティとの外部通信では、サードパーティ組織が CA を制御します。サードパーティ CA は、サードパーティサービスと通信するときに組織で使用する証明書を発行します。
## [](#関連情報)関連情報 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-basic-deployments) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-shared-storage) # インバウンドポリシーディレクトリ ## [](#flex-gateway-に含まれているインバウンドポリシー)Flex Gateway に含まれているインバウンドポリシー
ポリシー カテゴリ 概要

A2A エージェントカード

A2A

サーバーインスタンスの公開 URL と一致するようにエージェントカード URL を書き換えます

A2A PII ディテクター

A2A

エージェントに送信される要求で個人情報 (PII) を検出します

A2A プロンプトデコレーター

A2A

プロンプトをコンテキスト情報でデコレーションします

A2A スキーマ検証

A2A

エージェント要求を検証し、A2A 仕様に準拠していることを確認する

基本認証: LDAP

セキュリティ

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

基本認証: シンプル

セキュリティ

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

クライアント ID 適用

コンプライアンス

承認されたクライアントアプリケーションへのアクセスのみを許可する

クロスオリジンリソース共有 (CORS)

コンプライアンス

外部ドメインに存在するリソースへのアクセスを可能にする

外部認証

セキュリティ

外部 gRPC または HTTP 認証サービスを使用して要求を認証します

外部処理

変換

追加処理を行うために、受信 HTTP 要求または送信 HTTP 応答を外部 gRPC サービスに送信する

ヘッダーの挿入

変換

要求または応答にヘッダーを追加する

ヘッダーの削除

変換

要求または応答からヘッダーを削除する

状態チェック

サービス品質

特定の間隔で API アップストリームの健全性を監視する

HTTP キャッシュ

サービス品質

API 実装から HTTP 応答をキャッシュする

IP 許可リスト

セキュリティ

IP アドレスのリストまたは範囲からのアクセス要求を許可する

IP ブロックリスト

セキュリティ

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

JSON 脅威保護

セキュリティ

API 要求内の悪意のある JSON から保護する

JWT 検証

セキュリティ

JWT トークンを検証する

MCP 属性ベースのアクセス制御

MCP

層、IP、ヘッダー、クレームなどのユーザー情報に基づいてツール、リソース、プロンプトへのアクセスを制御します。

MCP スキーマ検証

MCP

MCP 要求を検証して MCP 仕様に準拠していることを確認します。

MCP サポート

MCP

MCP サポートを Flex Gateway MCP サーバーインスタンスに追加します。MCP サーバーインスタンスを適切に機能させるには、このポリシーが必要です。

メッセージログ

トラブルシューティング

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

OAuth 2.0 トークンイントロスペクション

セキュリティ

承認されたクライアントアプリケーションへのアクセスのみを許可する

OpenID Connect OAuth 2.0 アクセストークン適用

セキュリティ

承認されたクライアントアプリケーションへのアクセスのみを許可する

レート制限

サービス品質

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

レート制限: SLA ベース

サービス品質

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

応答アイドルタイムアウト

サービス品質

Flex Gateway がアップストリームサービスからの応答を待機する最大期間を設定する

スキーマ検証

セキュリティ

指定された OAS3 スキーマに対して受信トラフィックを検証する

SOAP スキーマ検証

セキュリティ

指定された WSDL スキーマに対して受信トラフィックを検証する

スパイク制御

サービス品質

API トラフィックを規制する

SSE ログ

SSE

ストリーミング中にすべての SSE イベントを記録します

ストリームアイドルタイムアウト

サービス品質

ストリームが要求または応答を受信せずにアイドル状態を続けられる最大期間を設定する

トレース

トラブルシューティング

API の OpenTelemetry 分散トレースを設定する

複数のアップストリームサービスのトラフィック管理

サービス品質

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

複数のアップストリームサービスポリシーのトラフィック管理 (加重)

サービス品質

加重率を使用して、1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

Transport Layer Security (TLS) - インバウンド

セキュリティ

クライアントと API プロキシ間の認証を有効にする

Transport Layer Security (TLS) - アウトバウンド

セキュリティ

API プロキシとアップストリームサービス間の双方向認証を有効にする

XML 脅威保護

セキュリティ

API 要求内の悪意のある XML から保護する
## [](#関連情報)関連情報 - [Mule Gateway ポリシーの概要](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-overview) - [ゲートウェイ別のポリシーの可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) # インバウンドポリシーディレクトリ ## [](#flex-gateway-に含まれているインバウンドポリシー)Flex Gateway に含まれているインバウンドポリシー
ポリシー カテゴリ 概要

A2A エージェントカード

A2A

サーバーインスタンスの公開 URL と一致するようにエージェントカード URL を書き換えます

A2A PII ディテクター

A2A

エージェントに送信される要求で個人情報 (PII) を検出します

A2A プロンプトデコレーター

A2A

プロンプトをコンテキスト情報でデコレーションします

A2A スキーマ検証

A2A

エージェント要求を検証し、A2A 仕様に準拠していることを確認する

基本認証: LDAP

セキュリティ

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

基本認証: シンプル

セキュリティ

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

クライアント ID 適用

コンプライアンス

承認されたクライアントアプリケーションへのアクセスのみを許可する

クロスオリジンリソース共有 (CORS)

コンプライアンス

外部ドメインに存在するリソースへのアクセスを可能にする

外部認証

セキュリティ

外部 gRPC または HTTP 認証サービスを使用して要求を認証します

外部処理

変換

追加処理を行うために、受信 HTTP 要求または送信 HTTP 応答を外部 gRPC サービスに送信する

ヘッダーの挿入

変換

要求または応答にヘッダーを追加する

ヘッダーの削除

変換

要求または応答からヘッダーを削除する

状態チェック

サービス品質

特定の間隔で API アップストリームの健全性を監視する

HTTP キャッシュ

サービス品質

API 実装から HTTP 応答をキャッシュする

IP 許可リスト

セキュリティ

IP アドレスのリストまたは範囲からのアクセス要求を許可する

IP ブロックリスト

セキュリティ

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

JSON 脅威保護

セキュリティ

API 要求内の悪意のある JSON から保護する

JWT 検証

セキュリティ

JWT トークンを検証する

MCP 属性ベースのアクセス制御

MCP

層、IP、ヘッダー、クレームなどのユーザー情報に基づいてツール、リソース、プロンプトへのアクセスを制御します。

MCP スキーマ検証

MCP

MCP 要求を検証して MCP 仕様に準拠していることを確認します。

MCP サポート

MCP

MCP サポートを Flex Gateway MCP サーバーインスタンスに追加します。MCP サーバーインスタンスを適切に機能させるには、このポリシーが必要です。

メッセージログ

トラブルシューティング

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

OAuth 2.0 トークンイントロスペクション

セキュリティ

承認されたクライアントアプリケーションへのアクセスのみを許可する

OpenID Connect OAuth 2.0 アクセストークン適用

セキュリティ

承認されたクライアントアプリケーションへのアクセスのみを許可する

レート制限

サービス品質

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

レート制限: SLA ベース

サービス品質

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

応答アイドルタイムアウト

サービス品質

Flex Gateway がアップストリームサービスからの応答を待機する最大期間を設定する

スキーマ検証

セキュリティ

指定された OAS3 スキーマに対して受信トラフィックを検証する

スパイク制御

サービス品質

API トラフィックを規制する

SSE ログ

SSE

ストリーミング中にすべての SSE イベントを記録します

ストリームアイドルタイムアウト

サービス品質

ストリームが要求または応答を受信せずにアイドル状態を続けられる最大期間を設定する

複数のアップストリームサービスのトラフィック管理

サービス品質

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

複数のアップストリームサービスポリシーのトラフィック管理 (加重)

サービス品質

加重率を使用して、1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

Transport Layer Security (TLS) - インバウンド

セキュリティ

クライアントと API プロキシ間の認証を有効にする

Transport Layer Security (TLS) - アウトバウンド

セキュリティ

API プロキシとアップストリームサービス間の双方向認証を有効にする
## [](#関連情報)関連情報 - [Mule Gateway ポリシーの概要](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-overview) - [ゲートウェイ別のポリシーの可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) # カスタムポリシー **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 ポリシーは、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用します。たとえば、ポリシーによって認証、アクセス、サービスレベルアクセス (SLA) を制御できます。特定のビジネス要件に基づいてカスタムポリシーを作成して API に適用することで、既存の機能を拡張したり、新しい機能を定義したりできます。 Anypoint Flex Gateway のカスタムポリシーの作成ワークフローは、Exchange で実行します。作成したポリシーは、Anypoint API Manager を使用して API に適用します。 詳細は以下を参照してください。 - [Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-flex-implement-rust) - [Flex Gateway カスタムポリシーのパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-flex-getting-started) - [ローカルモードでの Flex Gateway カスタムポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-deploy-custom-policy) # カスタムポリシー **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 ポリシーは、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用します。たとえば、ポリシーによって認証、アクセス、サービスレベルアクセス (SLA) を制御できます。特定のビジネス要件に基づいてカスタムポリシーを作成して API に適用することで、既存の機能を拡張したり、新しい機能を定義したりできます。 Anypoint Flex Gateway のカスタムポリシーの作成ワークフローは、Exchange で実行します。作成したポリシーは、Anypoint API Manager を使用して API に適用します。 詳細は以下を参照してください。 - [Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-flex-implement-rust) - [Flex Gateway カスタムポリシーのパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-flex-getting-started) - [ローカルモードでの Flex Gateway カスタムポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-deploy-custom-policy) # カスタムポリシー **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 ポリシーは、セキュリティの管理、トラフィックの制御、API の適応性の向上に役立つ規制を適用します。たとえば、ポリシーによって認証、アクセス、サービスレベルアクセス (SLA) を制御できます。特定のビジネス要件に基づいてカスタムポリシーを作成して API に適用することで、既存の機能を拡張したり、新しい機能を定義したりできます。 Anypoint Flex Gateway のカスタムポリシーの作成ワークフローは、Exchange で実行します。作成したポリシーは、Anypoint API Manager を使用して API に適用します。 詳細は以下を参照してください。 - [Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-flex-implement-rust) - [Flex Gateway カスタムポリシーのパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-flex-getting-started) - [ローカルモードでの Flex Gateway カスタムポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-deploy-custom-policy) # クライアント ID 適用ポリシー

ポリシー名

クライアント ID 適用

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

コンプライアンス

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 クライアント ID 適用ポリシーは、登録済みクライアントアプリケーションからの要求のみを許可することで、保護されたリソースへのアクセスを制限します。このポリシーは、各要求で送信されるクライアントのログイン情報が API のコンシュームを承認されていることを確認します。 クライアントアプリケーションが Anypoint Platform に登録されると、クライアント ID とクライアントシークレットで構成されるログイン情報のペアが生成されます。クライアントアプリケーションが API へのアクセスを要求したときに、アプリケーションとその API 間のコントラクトが作成されます。クライアント ID 適用ポリシーで保護されている API は、承認されたコントラクトを持つアプリケーションのみからアクセスできます。 クライアント ID 適用ポリシーを適用すると、Analytics イベントと共にクライアント ID を報告することで、API へのアクセスが追跡されます。 クライアントアプリケーションのログイン情報を内部に適用するデフォルトポリシーは次のとおりです。 - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-rate-limiting-sla) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-openid-token-enforcement) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-jwt-validation) トークン適用ポリシーは、必要に応じてクライアント検証をスキップできますが、トークンが承認されたコントラクトに関連付けられていることを確認するために検証を実施することをお勧めします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード クライアント ID 適用ポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

Credentials origin (ログイン情報の取得元)

要求のどこから値を抽出するかを指定します。

  • HTTP Basic Authentication Header (HTTP 基本認証ヘッダー): 認証ヘッダーの一部としてログイン情報が必要です。API をコンシュームするアプリケーションは、基本認証スキームを使用して要求でログイン情報を送信する必要があります。

  • Custom Expression (カスタム式): 各クライアント ID とクライアントシークレットの DataWeave 2.0 式を受け入れ、要求からログイン情報を抽出する場所を示します。ログイン情報をカスタムヘッダーまたはその他の形式で送信する場合、このオプションを使用します。クライアントシークレットの要件を省略可能として設定する場合、この項目は空白のままにできます。

いずれかのオプションを選択する必要があります。

Client ID Expression (クライアント ID 式)

API 要求からクライアント ID を取得するために使用する DataWeave 2.0 式。

はい。

Client Secret Expression (クライアントシークレット式)

API 要求からクライアントシークレットを取得するために使用する DataWeave 2.0 式。

いいえ。
## [](#ポリシーのしくみ)ポリシーのしくみ クライアントアプリケーションがクライアント ID 適用ポリシーで保護された API をコンシュームできるようになる前に、クライアントアプリケーションは API へのアクセスを要求する必要があります。クライアントアプリケーションと API 間に承認されたコントラクトが存在する場合、ポリシーの設定方法に準拠したクライアントアプリケーションのログイン情報がすべての要求に含まれている必要があります。 たとえば、クエリパラメーターとしてクライアント ID とクライアントシークレットを必要とするポリシーが設定されている場合、アプリケーションは要求でそれらのログイン情報を送信する必要があります。これを適用するには、API 仕様に ​`client-id-required`​ RAML trait を追加します。 traits: client-id-required: queryParameters: client\_id: type: string client\_secret: type: string `is`​ RAML 属性を使用して、trait をリソースまたはメソッドに適用します。 /example: get: is: \[client-id-required\] description: Example description ## [](#ポリシーがログイン情報を取得する方法の設定)ポリシーがログイン情報を取得する方法の設定 さまざまなカスタム DataWeave 2.0 式を使用して、HTTP 要求からクライアント ID とクライアントシークレットの両方、またはクライアント ID のみを抽出するようにポリシーを設定できます。次の例では、「1234」のクライアント ID と「abcd」のクライアントシークレットを使用しています。 ### [](#http-ヘッダーを使用したログイン情報の取得)HTTP ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.headers['client_id']] #[attributes.headers['client_secret']] ``` この例では、client\_id と client\_secret の 2 つのヘッダー、およびログイン情報のペアを必要とするポリシーが設定されています。このポリシーは、他の種別のヘッダーも許可する柔軟性があります。これがポリシーのデフォルト設定です。 ### [](#http-クエリパラメーターを使用したログイン情報の取得)HTTP クエリパラメーターを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource?client_id=1234&client_secret=abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.queryParams.'client_id'] #[attributes.queryParams.'client_secret'] ``` この例では、リクエスターは指定された 2 つのクエリパラメーターを要求と共に送信する必要があります。これはサポートされている設定ですが、セキュリティリスクが発生する可能性があります。ヘッダーを使用する方法をお勧めします。DataWeave 2.0 の​[一部](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support)​がサポートされています。 ### [](#http-要求ペイロードを使用したログイン情報の取得)HTTP 要求ペイロードを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -d '{"client_id":"1234", "client_secret":"abcd"}' -X POST ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[payload.client_id] #[payload.client_secret] ``` 要求ペイロードからログイン情報を取得するようにポリシーを設定できますが、この方法は API 仕様に反映させることが難しいため、お勧めしません。 ### [](#基本認証ヘッダーを使用したログイン情報の取得)基本認証ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -u 1234:abcd ``` ## [](#api-仕様の設定)API 仕様の設定 クライアント ID 適用ポリシーでは、ログイン情報の要件を実装するために API 仕様を変更する必要があります。 対応するポリシーの API 仕様に追加する必要がある RAML または OAS コードが含まれる、RAML または OAS スニペットリンクがあります。このコードには、API Manager で API 仕様の \[Policies (ポリシー)\] タブにある適用済みポリシーのリストからアクセスできます。 ## [](#ポリシーの出力)ポリシーの出力 クライアント ID 適用ポリシーが適用されていて、クライアントアプリケーションのログイン情報が無効または未承認の場合、保護されるリソースに対して HTTP 要求が実行されると、HTTP 応答に WWW Authenticate ヘッダーと次の値が含まれます。

カスタムモード

ヘッダー 'WWW-Authenticate'='Client-ID-Enforcement'

基本認証モード

ヘッダー 'WWW-Authenticate'='Basic realm="mule-realm"
SOAP アプリケーションの場合、応答は SOAP エラーです。 ## [](#関連情報)関連情報 - [API Manager における API インスタンスコントラクトの管理](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task) - [登録済みクライアントアプリケーションのクライアント ID とクライアントシークレットの取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) - [SLA 層の概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) # クライアント ID 適用ポリシー

ポリシー名

クライアント ID 適用

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

コンプライアンス

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 クライアント ID 適用ポリシーは、登録済みクライアントアプリケーションからの要求のみを許可することで、保護されたリソースへのアクセスを制限します。このポリシーは、各要求で送信されるクライアントのログイン情報が API のコンシュームを承認されていることを確認します。 クライアントアプリケーションが Anypoint Platform に登録されると、クライアント ID とクライアントシークレットで構成されるログイン情報のペアが生成されます。クライアントアプリケーションが API へのアクセスを要求したときに、アプリケーションとその API 間のコントラクトが作成されます。クライアント ID 適用ポリシーで保護されている API は、承認されたコントラクトを持つアプリケーションのみからアクセスできます。 クライアント ID 適用ポリシーを適用すると、Analytics イベントと共にクライアント ID を報告することで、API へのアクセスが追跡されます。 クライアントアプリケーションのログイン情報を内部に適用するデフォルトポリシーは次のとおりです。 - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-rate-limiting-sla) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-openid-token-enforcement) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-jwt-validation) トークン適用ポリシーは、必要に応じてクライアント検証をスキップできますが、トークンが承認されたコントラクトに関連付けられていることを確認するために検証を実施することをお勧めします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード Client ID 適用ポリシーは、ローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード #### [](#パラメーターの設定)パラメーターの設定 次のパラメーターが表示されます。
パラメーター 説明 必須

Credentials origin (ログイン情報の取得元)

要求のどこから値を抽出するかを指定します。

  • HTTP Basic Authentication Header (HTTP 基本認証ヘッダー): 認証ヘッダーの一部としてログイン情報が必要です。API をコンシュームするアプリケーションは、基本認証スキームを使用して要求でログイン情報を送信する必要があります。

  • Custom Expression (カスタム式): 各クライアント ID とクライアントシークレットの DataWeave 2.0 式を受け入れ、要求からログイン情報を抽出する場所を示します。ログイン情報をカスタムヘッダーまたはその他の形式で送信する場合、このオプションを使用します。クライアントシークレットの要件を省略可能として設定する場合、この項目は空白のままにできます。

いずれかのオプションを選択する必要があります。

Client ID Expression (クライアント ID 式)

API 要求からクライアント ID を取得するために使用する DataWeave 2.0 式。

はい。

Client Secret Expression (クライアントシークレット式)

API 要求からクライアントシークレットを取得するために使用する DataWeave 2.0 式。

いいえ。

Method & Resource conditions (メソッドとリソースの条件): Apply configurations to all API methods & resources (設定をすべての API メソッドおよびリソースに適用)

API に関連付けられたすべてのメソッドとリソースにポリシーを適用する必要がある場合、このオプションを選択します。

いずれかのオプションを選択する必要があります。

Method & Resource conditions (メソッドとリソースの条件): Apply Configurations to Specific Methods & Resources (特定のメソッドとリソースに設定を適用)

API に関連付けられた特定のメソッドとリソースにポリシーを適用する必要がある場合、このオプションを選択します。

いずれかのオプションを選択する必要があります。
#### [](#anypoint-service-mesh-非-mule-アプリケーション-のパラメーターの設定)Anypoint Service Mesh (非 Mule アプリケーション) のパラメーターの設定 Anypoint Service Mesh (非 Mule アプリケーション) の場合、クライアント ID 適用ポリシーを同じ方法で設定しますが、次の違いがあります。
要素 説明 必須

Credentials origin (ログイン情報の取得元)

要求のどこから値を抽出するかを指定します。

  • client_id​ および ​client_secret​ ヘッダー:

  • HTTP Basic Authentication Header (HTTP 基本認証ヘッダー): 認証ヘッダーの一部としてログイン情報が必要です。API をコンシュームするアプリケーションは、基本認証スキームを使用して要求でログイン情報を送信する必要があります。

  • Custom Headers (カスタムヘッダー): 各クライアント ID とクライアントシークレットのヘッダー名を受け入れ、要求からログイン情報を抽出するヘッダーを示します。ログイン情報をカスタムヘッダーに送信する場合、このオプションを使用します。

いずれかのオプションを選択する必要があります。

Client ID Header (クライアント ID ヘッダー)

API 要求からクライアント ID を抽出するために使用されるヘッダー名。

はい。

Client Secret Header (クライアントシークレットヘッダー)

API 要求からクライアントシークレットを抽出するために使用されるヘッダー名。

いいえ。
## [](#ポリシーのしくみ)ポリシーのしくみ クライアントアプリケーションがクライアント ID 適用ポリシーで保護された API をコンシュームできるようになる前に、クライアントアプリケーションは API へのアクセスを要求する必要があります。クライアントアプリケーションと API 間に承認されたコントラクトが存在する場合、ポリシーの設定方法に準拠したクライアントアプリケーションのログイン情報がすべての要求に含まれている必要があります。 たとえば、クエリパラメーターとしてクライアント ID とクライアントシークレットを必要とするポリシーが設定されている場合、アプリケーションは要求でそれらのログイン情報を送信する必要があります。これを適用するには、API 仕様に ​`client-id-required`​ RAML trait を追加します。 traits: client-id-required: queryParameters: client\_id: type: string client\_secret: type: string `is`​ RAML 属性を使用して、trait をリソースまたはメソッドに適用します。 /example: get: is: \[client-id-required\] description: Example description ## [](#ポリシーがログイン情報を取得する方法の設定)ポリシーがログイン情報を取得する方法の設定 さまざまなカスタム DataWeave 2.0 式を使用して、HTTP 要求からクライアント ID とクライアントシークレットの両方、またはクライアント ID のみを抽出するようにポリシーを設定できます。次の例では、「1234」のクライアント ID と「abcd」のクライアントシークレットを使用しています。 ### [](#http-ヘッダーを使用したログイン情報の取得)HTTP ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.headers['client_id']] #[attributes.headers['client_secret']] ``` この例では、client\_id と client\_secret の 2 つのヘッダー、およびログイン情報のペアを必要とするポリシーが設定されています。このポリシーは、他の種別のヘッダーも許可する柔軟性があります。これがポリシーのデフォルト設定です。 ### [](#http-クエリパラメーターを使用したログイン情報の取得)HTTP クエリパラメーターを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource?client_id=1234&client_secret=abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.queryParams.'client_id'] #[attributes.queryParams.'client_secret'] ``` この例では、リクエスターは指定された 2 つのクエリパラメーターを要求と共に送信する必要があります。これはサポートされている設定ですが、セキュリティリスクが発生する可能性があります。ヘッダーを使用する方法をお勧めします。DataWeave 2.0 の​[一部](https://docs.mulesoft.com/jp/gateway/1.8/policies-flex-dataweave-support)​がサポートされています。 ### [](#http-要求ペイロードを使用したログイン情報の取得)HTTP 要求ペイロードを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -d '{"client_id":"1234", "client_secret":"abcd"}' -X POST ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[payload.client_id] #[payload.client_secret] ``` 要求ペイロードからログイン情報を取得するようにポリシーを設定できますが、この方法は API 仕様に反映させることが難しいため、お勧めしません。 ### [](#基本認証ヘッダーを使用したログイン情報の取得)基本認証ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -u 1234:abcd ``` ## [](#api-仕様の設定)API 仕様の設定 クライアント ID 適用ポリシーでは、ログイン情報の要件を実装するために API 仕様を変更する必要があります。 対応するポリシーの API 仕様に追加する必要がある RAML または OAS コードが含まれる、RAML または OAS スニペットリンクがあります。このコードには、API Manager で API 仕様の \[Policies (ポリシー)\] タブにある適用済みポリシーのリストからアクセスできます。 ## [](#ポリシーの出力)ポリシーの出力 クライアント ID 適用ポリシーが適用されていて、クライアントアプリケーションのログイン情報が無効または未承認の場合、保護されるリソースに対して HTTP 要求が実行されると、HTTP 応答に WWW Authenticate ヘッダーと次の値が含まれます。

カスタムモード

ヘッダー 'WWW-Authenticate'='Client-ID-Enforcement'

基本認証モード

ヘッダー 'WWW-Authenticate'='Basic realm="mule-realm"
SOAP アプリケーションの場合、応答は SOAP エラーです。 ## [](#関連情報)関連情報 - [API Manager における API インスタンスコントラクトの管理](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task) - [登録済みクライアントアプリケーションのクライアント ID とクライアントシークレットの取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) - [SLA 層の概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) # クライアント ID 適用ポリシー

ポリシー名

クライアント ID 適用

概要

承認されたクライアントアプリケーションへのアクセスのみを許可する

カテゴリ

コンプライアンス

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報

500 - 認証サーバーからの不正応答、または WSDL SOAP 失敗エラー
## [](#概要)概要 クライアント ID 適用ポリシーは、登録済みクライアントアプリケーションからの要求のみを許可することで、保護されたリソースへのアクセスを制限します。このポリシーは、各要求で送信されるクライアントのログイン情報が API のコンシュームを承認されていることを確認します。 クライアントアプリケーションが Anypoint Platform に登録されると、クライアント ID とクライアントシークレットで構成されるログイン情報のペアが生成されます。クライアントアプリケーションが API へのアクセスを要求したときに、アプリケーションとその API 間のコントラクトが作成されます。クライアント ID 適用ポリシーで保護されている API は、承認されたコントラクトを持つアプリケーションのみからアクセスできます。 クライアント ID 適用ポリシーを適用すると、Analytics イベントと共にクライアント ID を報告することで、API へのアクセスが追跡されます。 クライアントアプリケーションのログイン情報を内部に適用するデフォルトポリシーは次のとおりです。 - [レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-rate-limiting-sla) - [OpenID Connect OAuth 2.0 トークン適用ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-openid-token-enforcement) - [JWT 検証ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-jwt-validation) トークン適用ポリシーは、必要に応じてクライアント検証をスキップできますが、トークンが承認されたコントラクトに関連付けられていることを確認するために検証を実施することをお勧めします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード クライアント ID 適用ポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

Credentials origin (ログイン情報の取得元)

要求のどこから値を抽出するかを指定します。

  • HTTP Basic Authentication Header (HTTP 基本認証ヘッダー): 認証ヘッダーの一部としてログイン情報が必要です。API をコンシュームするアプリケーションは、基本認証スキームを使用して要求でログイン情報を送信する必要があります。

  • Custom Expression (カスタム式): 各クライアント ID とクライアントシークレットの DataWeave 2.0 式を受け入れ、要求からログイン情報を抽出する場所を示します。ログイン情報をカスタムヘッダーまたはその他の形式で送信する場合、このオプションを使用します。クライアントシークレットの要件を省略可能として設定する場合、この項目は空白のままにできます。

いずれかのオプションを選択する必要があります。

Client ID Expression (クライアント ID 式)

API 要求からクライアント ID を取得するために使用する DataWeave 2.0 式。

はい。

Client Secret Expression (クライアントシークレット式)

API 要求からクライアントシークレットを取得するために使用する DataWeave 2.0 式。

いいえ。
## [](#ポリシーのしくみ)ポリシーのしくみ クライアントアプリケーションがクライアント ID 適用ポリシーで保護された API をコンシュームできるようになる前に、クライアントアプリケーションは API へのアクセスを要求する必要があります。クライアントアプリケーションと API 間に承認されたコントラクトが存在する場合、ポリシーの設定方法に準拠したクライアントアプリケーションのログイン情報がすべての要求に含まれている必要があります。 たとえば、クエリパラメーターとしてクライアント ID とクライアントシークレットを必要とするポリシーが設定されている場合、アプリケーションは要求でそれらのログイン情報を送信する必要があります。これを適用するには、API 仕様に ​`client-id-required`​ RAML trait を追加します。 traits: client-id-required: queryParameters: client\_id: type: string client\_secret: type: string `is`​ RAML 属性を使用して、trait をリソースまたはメソッドに適用します。 /example: get: is: \[client-id-required\] description: Example description ## [](#ポリシーがログイン情報を取得する方法の設定)ポリシーがログイン情報を取得する方法の設定 さまざまなカスタム DataWeave 2.0 式を使用して、HTTP 要求からクライアント ID とクライアントシークレットの両方、またはクライアント ID のみを抽出するようにポリシーを設定できます。次の例では、「1234」のクライアント ID と「abcd」のクライアントシークレットを使用しています。 ### [](#http-ヘッダーを使用したログイン情報の取得)HTTP ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.headers['client_id']] #[attributes.headers['client_secret']] ``` この例では、client\_id と client\_secret の 2 つのヘッダー、およびログイン情報のペアを必要とするポリシーが設定されています。このポリシーは、他の種別のヘッダーも許可する柔軟性があります。これがポリシーのデフォルト設定です。 ### [](#http-クエリパラメーターを使用したログイン情報の取得)HTTP クエリパラメーターを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource?client_id=1234&client_secret=abcd" ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[attributes.queryParams.'client_id'] #[attributes.queryParams.'client_secret'] ``` この例では、リクエスターは指定された 2 つのクエリパラメーターを要求と共に送信する必要があります。これはサポートされている設定ですが、セキュリティリスクが発生する可能性があります。ヘッダーを使用する方法をお勧めします。DataWeave 2.0 の​[一部](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support)​がサポートされています。 ### [](#http-要求ペイロードを使用したログイン情報の取得)HTTP 要求ペイロードを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -d '{"client_id":"1234", "client_secret":"abcd"}' -X POST ``` ポリシーの設定時に使用される DataWeave 2.0 式の例: ```text #[payload.client_id] #[payload.client_secret] ``` 要求ペイロードからログイン情報を取得するようにポリシーを設定できますが、この方法は API 仕様に反映させることが難しいため、お勧めしません。 ### [](#基本認証ヘッダーを使用したログイン情報の取得)基本認証ヘッダーを使用したログイン情報の取得 curl を使用する要求の例: ```text curl "http://localhost/myResource" -u 1234:abcd ``` ## [](#api-仕様の設定)API 仕様の設定 クライアント ID 適用ポリシーでは、ログイン情報の要件を実装するために API 仕様を変更する必要があります。 対応するポリシーの API 仕様に追加する必要がある RAML または OAS コードが含まれる、RAML または OAS スニペットリンクがあります。このコードには、API Manager で API 仕様の \[Policies (ポリシー)\] タブにある適用済みポリシーのリストからアクセスできます。 ## [](#ポリシーの出力)ポリシーの出力 クライアント ID 適用ポリシーが適用されていて、クライアントアプリケーションのログイン情報が無効または未承認の場合、保護されるリソースに対して HTTP 要求が実行されると、HTTP 応答に WWW Authenticate ヘッダーと次の値が含まれます。

カスタムモード

ヘッダー 'WWW-Authenticate'='Client-ID-Enforcement'

基本認証モード

ヘッダー 'WWW-Authenticate'='Basic realm="mule-realm"
SOAP アプリケーションの場合、応答は SOAP エラーです。 ## [](#関連情報)関連情報 - [API Manager における API インスタンスコントラクトの管理](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task) - [登録済みクライアントアプリケーションのクライアント ID とクライアントシークレットの取得](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task) - [SLA 層の概念の確認](https://docs.mulesoft.com/jp/api-manager/latest/defining-sla-tiers) # クロスオリジンリソース共有 (CORS) ポリシー

ポリシー名

クロスオリジンリソース共有 (CORS)

概要

外部ドメインに存在するリソースへのアクセスを可能にする

カテゴリ

コンプライアンス

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 CORS は、Web アプリケーションが別のドメインで定義されたリソースにアクセスできるメカニズムです。ブラウザーは、この標準をデフォルトで実装しています。CORS ポリシーは [「CORS W3C Recommendation (CORS W3C 勧告)」](https://fetch.spec.whatwg.org/)​の標準に準拠します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: cors-flex config: originGroups: // OPTIONAL, default: \[\] - origins: accessControlMaxAge: allowedMethods: methodName: - isAllowed: headers: // OPTIONAL, default: \[\] exposedHeaders: // OPTIONAL, default: \[\] publicResource: // OPTIONAL, default: true supportCredentials: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

originGroups

省略可能

空の配列

オリジングループのリスト

originGroups.origins

省略可能

空の配列

グループに含められるオリジンのリスト。例: http://www.the-origin-of-time.com​

originGroups.origins.accessControlMaxAge

省略可能

30

新しいプレフライト要求を送信することなくプレフライト応答をキャッシュに格納しておける期間

originGroups.origins.allowedMethods

省略可能

CONNECT、DELETE、GET、OPTIONS、PATCH、POST、PUT、TRACE

許可される HTTP メソッド

originGroups.origins.allowedMethods.methodName

必須

なし

Method name (メソッド名)

originGroups.origins.allowedMethods.methodName.isAllowed

必須

なし

メソッドが許可されるかどうかを示すブール値

originGroups.origins.headers

省略可能

空の配列

プレフライト要求で使用する HTTP ヘッダー

originGroups.origins.exposedHeaders

省略可能

空の配列

ブラウザーの JavaScript にアクセスを許可するヘッダー

publicResource

省略可能

true

CORS 設定を公開リソースとして適用するかどうかを示すブール値

supportCredentials

省略可能

false

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうかを示すブール値
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: cors-flex config: publicResource: false supportCredentials: true originGroups: - origins: - http://www.the-origin-of-time.com accessControlMaxAge: 30 allowedMethods: - isAllowed: true methodName: POST - isAllowed: true methodName: PUT - isAllowed: true methodName: GET - isAllowed: false methodName: CONNECT - isAllowed: false methodName: DELETE - isAllowed: false methodName: OPTIONS - isAllowed: false methodName: PATCH - isAllowed: false methodName: TRACE headers: - x-allow-origin - x-yet-another-valid-header exposedHeaders: - x-forwarded-for ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Public resource (公開リソース)

CORS 設定を公開リソースとして適用するかどうか (デフォルト)。

はい

Default group (デフォルトグループ)

CORS 設定を特定のリソースにのみ適用するかどうか (​[Public resource (公開リソース)]​ を選択解除する必要があります)

いいえ

Support credentials (ログイン情報のサポート)

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうか。

いいえ
## [](#cors-を使用する理由)CORS を使用する理由 CORS により、お使いの環境で Web ページのセキュリティと Web の整合性を実現できます。CORS ポリシーをバックエンドに適用する必要がある理由を知るには、まず​_オリジン_​と ​_Cookie_​ の働きと、これらを操作して Web ページの整合性が損なわれる仕組みについて理解する必要があります。 ### [](#origins)Web オリジンの概念 オリジンとは、フェッチを開始した要求を指定するヘッダーです。オリジンヘッダーにはサーバー名のみが含まれます (パス情報は含まれません)。非常に基本的なレベルでは、オリジンは以下から構成されます。 - URI スキーム: `http://` - ホスト名: `www.example.com` - ポート番号: `8080` 2 つの​[オリジン](#origins)​の間で要求を承認させるには、それらのオリジンが等しくなければなりません。これら 3 つのパラメーターがすべて一致した場合にのみ、オリジンは等しいと見なされます。詳細は、 [「RFC 6454 - The Web Origin Concept (Web オリジンの概念)」](https://tools.ietf.org/html/rfc6454)​を参照してください。 ### [](#http-cookie)HTTP Cookie Web サイトでは HTTP Cookie を使用してステートフルな情報を維持しています。最も一般的な例として、Web サーバーは認証 Cookie を使用して、ユーザーがログインしているかどうかと、ユーザーがログインしているアカウントを判断します。詳細は、 [RFC 6265](https://www.ietf.org/rfc/rfc6265.txt)​ を参照してください。 SOP (同一オリジンポリシー) は、1 つの Web ページから別のページを呼び出すときに悪意のある攻撃者による Cookie の不正利用を抑止します。たとえば、銀行の Web ページに Cookie を使用してログインした場合、攻撃者はその Cookie を不正に取得して、正規ユーザーになりすまして銀行の API に対してクエリを実行しようと試みます。 SOP を使用している場合、対象 Web ページのオリジンが呼び出し側の Web ページのオリジンと同じである場合にのみ、対象 Web ページのデータへのアクセスが許可されます。オリジンの詳細については、 [Wikipedia](https://en.wikipedia.org/wiki/Same-origin_policy#Origin_determination_rules)​ を参照してください。 SOP は非常に制約が厳しいため、Web ページ上では、1 つのサブオリジンから別のサブオリジンや外部のハイパーリンクにはアクセスできません。たとえば、オリジン ​`www.testapply.com`​ に 2 つのサブオリジン ​`www.eng.testapply.com`​ および ​`www.docs.testapply.com`​ がある場合、これらのサブオリジン間の通信は拒否されます。さらに、各サブオリジンから外部 Web サイトへのハイパーリンクも拒否されます。 この問題を回避するため、Web ブラウザーでは CORS 標準を実装しており、この標準に従って Web サーバーを検証し、検証に成功すれば要求を受け入れるようにしています。 たとえば、銀行のログインサーバーで CORS サーバー側プロトコルが実装されている場合は、銀行の Web ページから直接クエリを実行しなければデータにはアクセスできません。外部の (銀行以外の) ドメインからログイン API に対してクエリを実行しても拒否されます。 ## [](#cors-の仕組み)CORS の仕組み Web ページがデータを要求すると、ブラウザーは要求が同じオリジンから出されているかどうかを検出して、CORS アルゴリズムを適用するかどうかを決定します。オリジンとは違う Web ページからデータのクエリを実行した場合は、CORS ポリシーが適用されます。 CORS アルゴリズムは、情報を要求した Web ページに対して Web サーバー上とクライアント側で実行されます。CORS ポリシーのクライアント側のアルゴリズムは次のように実装されます。 - 要求が複雑 (そして潜在的に危険) であるかどうかを判断し、事前の​_プリフライト_​要求を送信して、サーバーがオリジンを受け入れるかどうかを検証する。 - 実際の要求を実行し、サーバーが正しく応答してオリジンを受け入れることを検証する。 _プリフライト_​とは Web ブラウザーからバックエンドサーバーに送信される (HTTP メソッドとして OPTIONS を使用した) 事前要求であり、要求を実行しようとしている Web ページのアイデンティティ (オリジンと他のいくつかのヘッダー) をテストします。 バックエンドがオリジンを受け入れない場合、バックエンドサーバーは特定のヘッダー (Access-Control-Allow-Origin) なしで要求に応答します。これによってクライアントは、そのサーバーではページのオリジンが許可されないことを理解して、実際の要求を実行しません。 次の図は、実際の要求を実行するかどうかを決定する JavaScript フローの XMLHttpRequest (XHR) を示しています。 ![Javascript クロスドメイン XHR コールの標準レイテンシーと追加レイテンシーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/cors-policy-xhr-diagram.png) 図に示されているように、ブラウザーとサーバーとの間の通信に基づいて要求が検証されます。 - 要求が複雑であると見なされた場合は (上記の XHR のクライアント側の図参照)、プリフライト要求が実行されます。 サーバーがプリフライトに対して適切なレスポンスヘッダーを返さない場合、クライアントライブラリ (上の例では XHR) は実際の要求を実行できません。 - プリフライトに対して正しく完全な応答が返された場合、クライアントライブラリは特定の CORS ヘッダーを含む実際の要求を実行します。 そしてクライアントライブラリは応答の CORS ヘッダーを検証します。いずれかの必須ヘッダーが欠落している場合、クライアントライブラリは再び、要求がクライアント (通常は Web ページ) に到達しないようにブロックする必要があります。 ## [](#cors-のコンポーネント)CORS のコンポーネント リクエストヘッダー、レスポンスヘッダー、公開リソースとグループ、順序、ワイルドカードなど、CORS ポリシーのさまざまなコンポーネントを設定できます。 ### [](#cors-リクエストヘッダー)CORS リクエストヘッダー - Origin: クロスオリジン要求を実行するオリジン。 - Access-Control-Request-Method: 実際の要求で呼び出されるメソッド。 このヘッダーは、プリフライト要求で送信されます。 - Access-Control-Request-Headers: 実際の要求で送信されるカスタムヘッダー。 このヘッダーは、プリフライト要求で送信されます。GET メソッドと HEAD メソッドに対しては、シンプルであるためプリフライトを必要としないヘッダーのリストが標準によって定義されています。カスタムヘッダーに対しては、GET 要求と HEAD 要求でプリフライトが実行されます (クライアントがプリフライトを実行する必要のないパスの検証については、上記の XHR の例を参照してください)。 ### [](#cors-レスポンスヘッダー)CORS レスポンスヘッダー 応答に含まれるヘッダーは、要求がプリフライトまたは実際の要求のどちらであるかによって異なります。 - `Access-Control-Allow-Origin`​: すべての応答で必須。 このヘッダーが応答に含まれていない場合、ブラウザーやクライアントライブラリは応答が Web ページに到達しないようにブロックします。ワイルドカードの「\*」を使用して任意のオリジンを表すことができます。 - `Access-Control-Allow-Methods`​: 実行が許可されているメソッド。 このヘッダーは、OPTIONS 要求で返されます。サーバーは、許可されるメソッドのリストを応答で返し、検証をクライアントに委任する場合があります。 - `Access-Control-Allow-Headers`​: 実際の要求で許可されるヘッダー。 このヘッダーは、Access-Control-Allow-Methods と同じように機能します。 - `Access-Control-Allow-Credentials`​: Cookie を使用して実際の要求を実行できるかどうかをクライアントに通知します。 `Access-Control-Allow-Credentials`​ はブール値を返します。 - `Access-Control-Expose-Headers`​: 要求を実行した Web ページがアクセスできるヘッダーのリストをブラウザーまたはクライアントライブラリに提供します。 CORS 要求を実行している HTTP ライブラリは、ヘッダーのみを Web ページに提供することで、プライバシーとセキュリティを強化します。 - `Access-Control-Max-Age`​: ブラウザーが要求に対する 2 回目のプリフライトの実行を回避できる期間 (秒数) を指定します。 ### [](#公開リソースとグループ)公開リソースとグループ ブラウザー SOP をバイパスする必要がある場合に備えて、MuleSoft では公開リソースを設定するためのオプションを用意しており、応答に含まれるプリフライトデータを API ゲートウェイポリシーに反映できるようにしています。これにより、すべての CORS ヘッダーで実際の要求が正しく更新され、ブラウザーは応答を受け入れます。 お使いの環境において、公開リソースオプションでは十分な安全性を確保できない場合には、API に対してクエリを実行する異なるオリジンに対して複数のグループを定義してください。各グループはオリジンのリストに適用され、グループごとに異なるメソッド、ヘッダー、プリフライトキャッシュ時間、ヘッダー公開設定を指定できます。 ### [](#順序)順序 CORS ポリシーは API ゲートウェイによって常に最初に適用され、その後に他のポリシーが適用できるようになります。CORS ポリシーが適用されているアプリケーションに OPTIONS を使用している保護された要求が送信された場合、要求は保護されたリソースに到達しません。 [CORS 仕様](https://fetch.spec.whatwg.org/#resource-preflight-requests)​に従い、すべての OPTIONS 要求はプリフライトとみなされます。 ### [](#設定ワイルドカード)設定ワイルドカード グループ設定のオリジンセクションとヘッダーセクションではワイルドカード (​`*`​) を使用できます。ワイルドカードは、公開リソースが必要でありながらも、受け入れられる HTTP メソッドを制限する必要がある場合に使用します。 複数のグループを設定してあり、いずれかのグループでワイルドカードを使用してオリジンを指定してある場合、ワイルドカードを使用していない設定の方がワイルドカードによる指定よりも優先されます。 ## [](#faqs)FAQs **CORS ポリシーが適用されていないようです。** curl や Postman などのツールを使用して複雑な要求の CORS ポリシーをテストすると、CORS リクエストヘッダーが追加されず、プリフライトが実行されません。 要求で CORS ヘッダーが送信されないか、不適切なヘッダーが使用されていると、API ゲートウェイ CORS ポリシーは CORS レスポンスヘッダーを追加しません。これはポリシーが適用されないことを意味します。ライブラリで環境に適した CORS プロトコルが実装されていること、または仕様で正しいヘッダーを設定していることを確認してください。 # クロスオリジンリソース共有 (CORS) ポリシー

ポリシー名

クロスオリジンリソース共有 (CORS)

概要

外部ドメインに存在するリソースへのアクセスを可能にする

カテゴリ

コンプライアンス

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 CORS は、Web アプリケーションが別のドメインで定義されたリソースにアクセスできるメカニズムです。ブラウザーは、この標準をデフォルトで実装しています。CORS ポリシーは [「CORS W3C Recommendation (CORS W3C 勧告)」](https://fetch.spec.whatwg.org/)​の標準に準拠します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して CORS ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: cors-flex config: originGroups: // OPTIONAL, default: \[\] - origins: accessControlMaxAge: allowedMethods: methodName: - isAllowed: headers: // OPTIONAL, default: \[\] exposedHeaders: // OPTIONAL, default: \[\] publicResource: // OPTIONAL, default: true supportCredentials: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

originGroups

省略可能

空の配列

オリジングループのリスト

originGroups.origins

省略可能

空の配列

グループに含められるオリジンのリスト。例: http://www.the-origin-of-time.com​

originGroups.origins.accessControlMaxAge

省略可能

30

新しいプレフライト要求を送信することなくプレフライト応答をキャッシュに格納しておける期間

originGroups.origins.allowedMethods

省略可能

CONNECT、DELETE、GET、OPTIONS、PATCH、POST、PUT、TRACE

許可される HTTP メソッド

originGroups.origins.allowedMethods.methodName

必須

なし

Method name (メソッド名)

originGroups.origins.allowedMethods.methodName.isAllowed

必須

なし

メソッドが許可されるかどうかを示すブール値

originGroups.origins.headers

省略可能

空の配列

プレフライト要求で使用する HTTP ヘッダー

originGroups.origins.exposedHeaders

省略可能

空の配列

ブラウザーの JavaScript にアクセスを許可するヘッダー

publicResource

省略可能

true

CORS 設定を公開リソースとして適用するかどうかを示すブール値

supportCredentials

省略可能

false

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうかを示すブール値
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: cors-flex config: publicResource: false supportCredentials: true originGroups: - origins: - http://www.the-origin-of-time.com accessControlMaxAge: 30 allowedMethods: - isAllowed: true methodName: POST - isAllowed: true methodName: PUT - isAllowed: true methodName: GET - isAllowed: false methodName: CONNECT - isAllowed: false methodName: DELETE - isAllowed: false methodName: OPTIONS - isAllowed: false methodName: PATCH - isAllowed: false methodName: TRACE headers: - x-allow-origin - x-yet-another-valid-header exposedHeaders: - x-forwarded-for ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
要素 説明 必須?

Public resource (公開リソース)

CORS 設定を公開リソースとして適用するかどうか (デフォルト)。

はい

Default group (デフォルトグループ)

CORS 設定を特定のリソースにのみ適用するかどうか (​[Public resource (公開リソース)]​ を選択解除する必要があります)

いいえ

Support credentials (ログイン情報のサポート)

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうか。

いいえ
## [](#cors-を使用する理由)CORS を使用する理由 CORS により、お使いの環境で Web ページのセキュリティと Web の整合性を実現できます。CORS ポリシーをバックエンドに適用する必要がある理由を知るには、まず​_オリジン_​と ​_Cookie_​ の働きと、これらを操作して Web ページの整合性が損なわれる仕組みについて理解する必要があります。 ### [](#origins)Web オリジンの概念 オリジンとは、フェッチを開始した要求を指定するヘッダーです。オリジンヘッダーにはサーバー名のみが含まれます (パス情報は含まれません)。非常に基本的なレベルでは、オリジンは以下から構成されます。 - URI スキーム: `http://` - ホスト名: `www.example.com` - ポート番号: `8080` 2 つの​[オリジン](#origins)​の間で要求を承認させるには、それらのオリジンが等しくなければなりません。これら 3 つのパラメーターがすべて一致した場合にのみ、オリジンは等しいと見なされます。詳細は、 [「RFC 6454 - The Web Origin Concept (Web オリジンの概念)」](https://tools.ietf.org/html/rfc6454)​を参照してください。 ### [](#http-cookie)HTTP Cookie Web サイトでは HTTP Cookie を使用してステートフルな情報を維持しています。最も一般的な例として、Web サーバーは認証 Cookie を使用して、ユーザーがログインしているかどうかと、ユーザーがログインしているアカウントを判断します。詳細は、 [RFC 6265](https://www.ietf.org/rfc/rfc6265.txt)​ を参照してください。 SOP (同一オリジンポリシー) は、1 つの Web ページから別のページを呼び出すときに悪意のある攻撃者による Cookie の不正利用を抑止します。たとえば、銀行の Web ページに Cookie を使用してログインした場合、攻撃者はその Cookie を不正に取得して、正規ユーザーになりすまして銀行の API に対してクエリを実行しようと試みます。 SOP を使用している場合、対象 Web ページのオリジンが呼び出し側の Web ページのオリジンと同じである場合にのみ、対象 Web ページのデータへのアクセスが許可されます。オリジンの詳細については、 [Wikipedia](https://en.wikipedia.org/wiki/Same-origin_policy#Origin_determination_rules)​ を参照してください。 SOP は非常に制約が厳しいため、Web ページ上では、1 つのサブオリジンから別のサブオリジンや外部のハイパーリンクにはアクセスできません。たとえば、オリジン ​`www.testapply.com`​ に 2 つのサブオリジン ​`www.eng.testapply.com`​ および ​`www.docs.testapply.com`​ がある場合、これらのサブオリジン間の通信は拒否されます。さらに、各サブオリジンから外部 Web サイトへのハイパーリンクも拒否されます。 この問題を回避するため、Web ブラウザーでは CORS 標準を実装しており、この標準に従って Web サーバーを検証し、検証に成功すれば要求を受け入れるようにしています。 たとえば、銀行のログインサーバーで CORS サーバー側プロトコルが実装されている場合は、銀行の Web ページから直接クエリを実行しなければデータにはアクセスできません。外部の (銀行以外の) ドメインからログイン API に対してクエリを実行しても拒否されます。 ## [](#cors-の仕組み)CORS の仕組み Web ページがデータを要求すると、ブラウザーは要求が同じオリジンから出されているかどうかを検出して、CORS アルゴリズムを適用するかどうかを決定します。オリジンとは違う Web ページからデータのクエリを実行した場合は、CORS ポリシーが適用されます。 CORS アルゴリズムは、情報を要求した Web ページに対して Web サーバー上とクライアント側で実行されます。CORS ポリシーのクライアント側のアルゴリズムは次のように実装されます。 - 要求が複雑 (そして潜在的に危険) であるかどうかを判断し、事前の​_プリフライト_​要求を送信して、サーバーがオリジンを受け入れるかどうかを検証する。 - 実際の要求を実行し、サーバーが正しく応答してオリジンを受け入れることを検証する。 _プリフライト_​とは Web ブラウザーからバックエンドサーバーに送信される (HTTP メソッドとして OPTIONS を使用した) 事前要求であり、要求を実行しようとしている Web ページのアイデンティティ (オリジンと他のいくつかのヘッダー) をテストします。 バックエンドがオリジンを受け入れない場合、バックエンドサーバーは特定のヘッダー (Access-Control-Allow-Origin) なしで要求に応答します。これによってクライアントは、そのサーバーではページのオリジンが許可されないことを理解して、実際の要求を実行しません。 次の図は、実際の要求を実行するかどうかを決定する JavaScript フローの XMLHttpRequest (XHR) を示しています。 ![cors policy xhr diagram](/mulesoft/current/ja-jp/gateway/1.8/_images/cors-policy-xhr-diagram.png) 図に示されているように、ブラウザーとサーバーとの間の通信に基づいて要求が検証されます。 - 要求が複雑であると見なされた場合は (上記の XHR のクライアント側の図参照)、プリフライト要求が実行されます。 サーバーがプリフライトに対して適切なレスポンスヘッダーを返さない場合、クライアントライブラリ (上の例では XHR) は実際の要求を実行できません。 - プリフライトに対して正しく完全な応答が返された場合、クライアントライブラリは特定の CORS ヘッダーを含む実際の要求を実行します。 そしてクライアントライブラリは応答の CORS ヘッダーを検証します。いずれかの必須ヘッダーが欠落している場合、クライアントライブラリは再び、要求がクライアント (通常は Web ページ) に到達しないようにブロックする必要があります。 ## [](#cors-のコンポーネント)CORS のコンポーネント リクエストヘッダー、レスポンスヘッダー、公開リソースとグループ、順序、ワイルドカードなど、CORS ポリシーのさまざまなコンポーネントを設定できます。 ### [](#cors-リクエストヘッダー)CORS リクエストヘッダー - Origin: クロスオリジン要求を実行するオリジン。 - Access-Control-Request-Method: 実際の要求で呼び出されるメソッド。 このヘッダーは、プリフライト要求で送信されます。 - Access-Control-Request-Headers: 実際の要求で送信されるカスタムヘッダー。 このヘッダーは、プリフライト要求で送信されます。GET メソッドと HEAD メソッドに対しては、シンプルであるためプリフライトを必要としないヘッダーのリストが標準によって定義されています。カスタムヘッダーに対しては、GET 要求と HEAD 要求でプリフライトが実行されます (クライアントがプリフライトを実行する必要のないパスの検証については、上記の XHR の例を参照してください)。 ### [](#cors-レスポンスヘッダー)CORS レスポンスヘッダー 応答に含まれるヘッダーは、要求がプリフライトまたは実際の要求のどちらであるかによって異なります。 - `Access-Control-Allow-Origin`​: すべての応答で必須。 このヘッダーが応答に含まれていない場合、ブラウザーやクライアントライブラリは応答が Web ページに到達しないようにブロックします。ワイルドカードの「\*」を使用して任意のオリジンを表すことができます。 - `Access-Control-Allow-Methods`​: 実行が許可されているメソッド。 このヘッダーは、OPTIONS 要求で返されます。サーバーは、許可されるメソッドのリストを応答で返し、検証をクライアントに委任する場合があります。 - `Access-Control-Allow-Headers`​: 実際の要求で許可されるヘッダー。 このヘッダーは、Access-Control-Allow-Methods と同じように機能します。 - `Access-Control-Allow-Credentials`​: Cookie を使用して実際の要求を実行できるかどうかをクライアントに通知します。 `Access-Control-Allow-Credentials`​ はブール値を返します。 - `Access-Control-Expose-Headers`​: 要求を実行した Web ページがアクセスできるヘッダーのリストをブラウザーまたはクライアントライブラリに提供します。 CORS 要求を実行している HTTP ライブラリは、ヘッダーのみを Web ページに提供することで、プライバシーとセキュリティを強化します。 - `Access-Control-Max-Age`​: ブラウザーが要求に対する 2 回目のプリフライトの実行を回避できる期間 (秒数) を指定します。 ### [](#公開リソースとグループ)公開リソースとグループ ブラウザー SOP をバイパスする必要がある場合に備えて、MuleSoft では公開リソースを設定するためのオプションを用意しており、応答に含まれるプリフライトデータを API ゲートウェイポリシーに反映できるようにしています。これにより、すべての CORS ヘッダーで実際の要求が正しく更新され、ブラウザーは応答を受け入れます。 お使いの環境において、公開リソースオプションでは十分な安全性を確保できない場合には、API に対してクエリを実行する異なるオリジンに対して複数のグループを定義してください。各グループはオリジンのリストに適用され、グループごとに異なるメソッド、ヘッダー、プリフライトキャッシュ時間、ヘッダー公開設定を指定できます。 ### [](#順序)順序 CORS ポリシーは API ゲートウェイによって常に最初に適用され、その後に他のポリシーが適用できるようになります。CORS ポリシーが適用されているアプリケーションに OPTIONS を使用している保護された要求が送信された場合、要求は保護されたリソースに到達しません。 [CORS 仕様](https://fetch.spec.whatwg.org/#resource-preflight-requests)​に従い、すべての OPTIONS 要求はプリフライトとみなされます。 ### [](#設定ワイルドカード)設定ワイルドカード グループ設定のオリジンセクションとヘッダーセクションではワイルドカード (​`*`​) を使用できます。ワイルドカードは、公開リソースが必要でありながらも、受け入れられる HTTP メソッドを制限する必要がある場合に使用します。 複数のグループを設定してあり、いずれかのグループでワイルドカードを使用してオリジンを指定してある場合、ワイルドカードを使用していない設定の方がワイルドカードによる指定よりも優先されます。 ## [](#faqs)FAQs **CORS ポリシーが適用されていないようです。** curl や Postman などのツールを使用して複雑な要求の CORS ポリシーをテストすると、CORS リクエストヘッダーが追加されず、プリフライトが実行されません。 要求で CORS ヘッダーが送信されないか、不適切なヘッダーが使用されていると、API ゲートウェイ CORS ポリシーは CORS レスポンスヘッダーを追加しません。これはポリシーが適用されないことを意味します。ライブラリで環境に適した CORS プロトコルが実装されていること、または仕様で正しいヘッダーを設定していることを確認してください。 # クロスオリジンリソース共有 (CORS) ポリシー

ポリシー名

クロスオリジンリソース共有 (CORS)

概要

外部ドメインに存在するリソースへのアクセスを可能にする

カテゴリ

コンプライアンス

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 CORS は、Web アプリケーションが別のドメインで定義されたリソースにアクセスできるメカニズムです。ブラウザーは、この標準をデフォルトで実装しています。CORS ポリシーは [「CORS W3C Recommendation (CORS W3C 勧告)」](https://fetch.spec.whatwg.org/)​の標準に準拠します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: cors-flex config: originGroups: // OPTIONAL, default: \[\] - origins: accessControlMaxAge: allowedMethods: methodName: - isAllowed: headers: // OPTIONAL, default: \[\] exposedHeaders: // OPTIONAL, default: \[\] publicResource: // OPTIONAL, default: true supportCredentials: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

originGroups

省略可能

空の配列

オリジングループのリスト

originGroups.origins

省略可能

空の配列

グループに含められるオリジンのリスト。例: http://www.the-origin-of-time.com​

originGroups.origins.accessControlMaxAge

省略可能

30

新しいプレフライト要求を送信することなくプレフライト応答をキャッシュに格納しておける期間

originGroups.origins.allowedMethods

省略可能

CONNECT、DELETE、GET、OPTIONS、PATCH、POST、PUT、TRACE

許可される HTTP メソッド

originGroups.origins.allowedMethods.methodName

必須

なし

Method name (メソッド名)

originGroups.origins.allowedMethods.methodName.isAllowed

必須

なし

メソッドが許可されるかどうかを示すブール値

originGroups.origins.headers

省略可能

空の配列

プレフライト要求で使用する HTTP ヘッダー

originGroups.origins.exposedHeaders

省略可能

空の配列

ブラウザーの JavaScript にアクセスを許可するヘッダー

publicResource

省略可能

true

CORS 設定を公開リソースとして適用するかどうかを示すブール値

supportCredentials

省略可能

false

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうかを示すブール値
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: cors-flex config: publicResource: false supportCredentials: true originGroups: - origins: - http://www.the-origin-of-time.com accessControlMaxAge: 30 allowedMethods: - isAllowed: true methodName: POST - isAllowed: true methodName: PUT - isAllowed: true methodName: GET - isAllowed: false methodName: CONNECT - isAllowed: false methodName: DELETE - isAllowed: false methodName: OPTIONS - isAllowed: false methodName: PATCH - isAllowed: false methodName: TRACE headers: - x-allow-origin - x-yet-another-valid-header exposedHeaders: - x-forwarded-for ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Public resource (公開リソース)

CORS 設定を公開リソースとして適用するかどうか (デフォルト)。

はい

Default group (デフォルトグループ)

CORS 設定を特定のリソースにのみ適用するかどうか (​[Public resource (公開リソース)]​ を選択解除する必要があります)

いいえ

Support credentials (ログイン情報のサポート)

ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうか。

いいえ
## [](#cors-を使用する理由)CORS を使用する理由 CORS により、お使いの環境で Web ページのセキュリティと Web の整合性を実現できます。CORS ポリシーをバックエンドに適用する必要がある理由を知るには、まず​_オリジン_​と ​_Cookie_​ の働きと、これらを操作して Web ページの整合性が損なわれる仕組みについて理解する必要があります。 ### [](#origins)Web オリジンの概念 オリジンとは、フェッチを開始した要求を指定するヘッダーです。オリジンヘッダーにはサーバー名のみが含まれます (パス情報は含まれません)。非常に基本的なレベルでは、オリジンは以下から構成されます。 - URI スキーム: `http://` - ホスト名: `www.example.com` - ポート番号: `8080` 2 つの​[オリジン](#origins)​の間で要求を承認させるには、それらのオリジンが等しくなければなりません。これら 3 つのパラメーターがすべて一致した場合にのみ、オリジンは等しいと見なされます。詳細は、 [「RFC 6454 - The Web Origin Concept (Web オリジンの概念)」](https://tools.ietf.org/html/rfc6454)​を参照してください。 ### [](#http-cookie)HTTP Cookie Web サイトでは HTTP Cookie を使用してステートフルな情報を維持しています。最も一般的な例として、Web サーバーは認証 Cookie を使用して、ユーザーがログインしているかどうかと、ユーザーがログインしているアカウントを判断します。詳細は、 [RFC 6265](https://www.ietf.org/rfc/rfc6265.txt)​ を参照してください。 SOP (同一オリジンポリシー) は、1 つの Web ページから別のページを呼び出すときに悪意のある攻撃者による Cookie の不正利用を抑止します。たとえば、銀行の Web ページに Cookie を使用してログインした場合、攻撃者はその Cookie を不正に取得して、正規ユーザーになりすまして銀行の API に対してクエリを実行しようと試みます。 SOP を使用している場合、対象 Web ページのオリジンが呼び出し側の Web ページのオリジンと同じである場合にのみ、対象 Web ページのデータへのアクセスが許可されます。オリジンの詳細については、 [Wikipedia](https://en.wikipedia.org/wiki/Same-origin_policy#Origin_determination_rules)​ を参照してください。 SOP は非常に制約が厳しいため、Web ページ上では、1 つのサブオリジンから別のサブオリジンや外部のハイパーリンクにはアクセスできません。たとえば、オリジン ​`www.testapply.com`​ に 2 つのサブオリジン ​`www.eng.testapply.com`​ および ​`www.docs.testapply.com`​ がある場合、これらのサブオリジン間の通信は拒否されます。さらに、各サブオリジンから外部 Web サイトへのハイパーリンクも拒否されます。 この問題を回避するため、Web ブラウザーでは CORS 標準を実装しており、この標準に従って Web サーバーを検証し、検証に成功すれば要求を受け入れるようにしています。 たとえば、銀行のログインサーバーで CORS サーバー側プロトコルが実装されている場合は、銀行の Web ページから直接クエリを実行しなければデータにはアクセスできません。外部の (銀行以外の) ドメインからログイン API に対してクエリを実行しても拒否されます。 ## [](#cors-の仕組み)CORS の仕組み Web ページがデータを要求すると、ブラウザーは要求が同じオリジンから出されているかどうかを検出して、CORS アルゴリズムを適用するかどうかを決定します。オリジンとは違う Web ページからデータのクエリを実行した場合は、CORS ポリシーが適用されます。 CORS アルゴリズムは、情報を要求した Web ページに対して Web サーバー上とクライアント側で実行されます。CORS ポリシーのクライアント側のアルゴリズムは次のように実装されます。 - 要求が複雑 (そして潜在的に危険) であるかどうかを判断し、事前の​_プリフライト_​要求を送信して、サーバーがオリジンを受け入れるかどうかを検証する。 - 実際の要求を実行し、サーバーが正しく応答してオリジンを受け入れることを検証する。 _プリフライト_​とは Web ブラウザーからバックエンドサーバーに送信される (HTTP メソッドとして OPTIONS を使用した) 事前要求であり、要求を実行しようとしている Web ページのアイデンティティ (オリジンと他のいくつかのヘッダー) をテストします。 バックエンドがオリジンを受け入れない場合、バックエンドサーバーは特定のヘッダー (Access-Control-Allow-Origin) なしで要求に応答します。これによってクライアントは、そのサーバーではページのオリジンが許可されないことを理解して、実際の要求を実行しません。 次の図は、実際の要求を実行するかどうかを決定する JavaScript フローの XMLHttpRequest (XHR) を示しています。 ![Javascript クロスドメイン XHR コールの標準レイテンシーと追加レイテンシーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/cors-policy-xhr-diagram.png) 図に示されているように、ブラウザーとサーバーとの間の通信に基づいて要求が検証されます。 - 要求が複雑であると見なされた場合は (上記の XHR のクライアント側の図参照)、プリフライト要求が実行されます。 サーバーがプリフライトに対して適切なレスポンスヘッダーを返さない場合、クライアントライブラリ (上の例では XHR) は実際の要求を実行できません。 - プリフライトに対して正しく完全な応答が返された場合、クライアントライブラリは特定の CORS ヘッダーを含む実際の要求を実行します。 そしてクライアントライブラリは応答の CORS ヘッダーを検証します。いずれかの必須ヘッダーが欠落している場合、クライアントライブラリは再び、要求がクライアント (通常は Web ページ) に到達しないようにブロックする必要があります。 ## [](#cors-のコンポーネント)CORS のコンポーネント リクエストヘッダー、レスポンスヘッダー、公開リソースとグループ、順序、ワイルドカードなど、CORS ポリシーのさまざまなコンポーネントを設定できます。 ### [](#cors-リクエストヘッダー)CORS リクエストヘッダー - Origin: クロスオリジン要求を実行するオリジン。 - Access-Control-Request-Method: 実際の要求で呼び出されるメソッド。 このヘッダーは、プリフライト要求で送信されます。 - Access-Control-Request-Headers: 実際の要求で送信されるカスタムヘッダー。 このヘッダーは、プリフライト要求で送信されます。GET メソッドと HEAD メソッドに対しては、シンプルであるためプリフライトを必要としないヘッダーのリストが標準によって定義されています。カスタムヘッダーに対しては、GET 要求と HEAD 要求でプリフライトが実行されます (クライアントがプリフライトを実行する必要のないパスの検証については、上記の XHR の例を参照してください)。 ### [](#cors-レスポンスヘッダー)CORS レスポンスヘッダー 応答に含まれるヘッダーは、要求がプリフライトまたは実際の要求のどちらであるかによって異なります。 - `Access-Control-Allow-Origin`​: すべての応答で必須。 このヘッダーが応答に含まれていない場合、ブラウザーやクライアントライブラリは応答が Web ページに到達しないようにブロックします。ワイルドカードの「\*」を使用して任意のオリジンを表すことができます。 - `Access-Control-Allow-Methods`​: 実行が許可されているメソッド。 このヘッダーは、OPTIONS 要求で返されます。サーバーは、許可されるメソッドのリストを応答で返し、検証をクライアントに委任する場合があります。 - `Access-Control-Allow-Headers`​: 実際の要求で許可されるヘッダー。 このヘッダーは、Access-Control-Allow-Methods と同じように機能します。 - `Access-Control-Allow-Credentials`​: Cookie を使用して実際の要求を実行できるかどうかをクライアントに通知します。 `Access-Control-Allow-Credentials`​ はブール値を返します。 - `Access-Control-Expose-Headers`​: 要求を実行した Web ページがアクセスできるヘッダーのリストをブラウザーまたはクライアントライブラリに提供します。 CORS 要求を実行している HTTP ライブラリは、ヘッダーのみを Web ページに提供することで、プライバシーとセキュリティを強化します。 - `Access-Control-Max-Age`​: ブラウザーが要求に対する 2 回目のプリフライトの実行を回避できる期間 (秒数) を指定します。 ### [](#公開リソースとグループ)公開リソースとグループ ブラウザー SOP をバイパスする必要がある場合に備えて、MuleSoft では公開リソースを設定するためのオプションを用意しており、応答に含まれるプリフライトデータを API ゲートウェイポリシーに反映できるようにしています。これにより、すべての CORS ヘッダーで実際の要求が正しく更新され、ブラウザーは応答を受け入れます。 お使いの環境において、公開リソースオプションでは十分な安全性を確保できない場合には、API に対してクエリを実行する異なるオリジンに対して複数のグループを定義してください。各グループはオリジンのリストに適用され、グループごとに異なるメソッド、ヘッダー、プリフライトキャッシュ時間、ヘッダー公開設定を指定できます。 ### [](#順序)順序 CORS ポリシーは API ゲートウェイによって常に最初に適用され、その後に他のポリシーが適用できるようになります。CORS ポリシーが適用されているアプリケーションに OPTIONS を使用している保護された要求が送信された場合、要求は保護されたリソースに到達しません。 [CORS 仕様](https://fetch.spec.whatwg.org/#resource-preflight-requests)​に従い、すべての OPTIONS 要求はプリフライトとみなされます。 ### [](#設定ワイルドカード)設定ワイルドカード グループ設定のオリジンセクションとヘッダーセクションではワイルドカード (​`*`​) を使用できます。ワイルドカードは、公開リソースが必要でありながらも、受け入れられる HTTP メソッドを制限する必要がある場合に使用します。 複数のグループを設定してあり、いずれかのグループでワイルドカードを使用してオリジンを指定してある場合、ワイルドカードを使用していない設定の方がワイルドカードによる指定よりも優先されます。 ## [](#faqs)FAQs **CORS ポリシーが適用されていないようです。** curl や Postman などのツールを使用して複雑な要求の CORS ポリシーをテストすると、CORS リクエストヘッダーが追加されず、プリフライトが実行されません。 要求で CORS ヘッダーが送信されないか、不適切なヘッダーが使用されていると、API ゲートウェイ CORS ポリシーは CORS レスポンスヘッダーを追加しません。これはポリシーが適用されないことを意味します。ライブラリで環境に適した CORS プロトコルが実装されていること、または仕様で正しいヘッダーを設定していることを確認してください。 # サーキットブレーカーポリシー

ポリシー名

サーキットブレーカー

概要

アップストリームが受信する要求または接続が多くなりすぎるのを防止する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

503 - Service Unavailable (サービスを利用できません)
## [](#概要)概要 サーキットブレーカーポリシーでは、アップストリームサービスが一度に受信する要求または接続が多くなりすぎるのを防止します。定義済みの最大数に達すると、Flex Gateway によって ​`503 - Service Unavailable (サービスを利用できません)`​ エラーが返されます。 管理 Flex Gateway または接続モードでは、同じアップストリームを要求する際に各 API インスタンスに独立した制限があるため、それぞれで最大数いっぱいまで使用できます。ローカルモードでは、制限が異なる API インスタンス間で共有されるため、すべてが同じアップストリームの最大数に従う必要があります。すべてのモードで、最大数はレプリカ間で分配されず、それぞれのゲートウェイで最大数いっぱいまで使用できます。 サーキットブレーカーポリシーは、Envoy アップストリームクラスターサーキットブレーク機能の拡張機能です。Envoy のサーキットブレークについての詳細は、Envoy ドキュメントの [「Circuit Breaking (サーキットブレーク)」](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking.html)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: upstream-policy spec: targetRef: Kind: Service name: upstream policyRef: name: circuit-breaker-flex config: thresholds: maxConnections: // OPTIONAL maxPendingRequests: // OPTIONAL maxRequests: // OPTIONAL maxRetries: // OPTIONAL maxConnectionPools: // OPTIONAL
ローカルモードでは制限が独立していないため、異なる API インスタンスでアップストリームの最大数を共有します。
パラメーター 必須または省略可能 説明

maximumConnections

省略可能

アップストリームへの API ごとの接続の最大数。

maximumPendingRequests

省略可能

接続を待機する間のキューに登録された要求の最大数。

maximumRequests

省略可能

アップストリームへの未処理要求の最大数。

maximumRetries

省略可能

未処理再試行の最大数。

maximumConnectionPools

省略可能

アップストリームへの同時に開始される接続プールの最大数。
#### [](#リソースの設定例)リソースの設定例 次の例では、一度に最大 1 つの要求をサポートするポリシーを定義します。 apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: circuit-breaker namespace: test-ns spec: circuitBreaker: thresholds: maxConnections: 1 maxPendingRequests: 1 maxRequests: 1 maxRetries: 1 maxConnectionPools: 1 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 必須または省略可能 説明

Maximum connections (最大接続数)

省略可能

アップストリームへの API ごとの接続の最大数。

Maximum pending requests (最大の保留中の要求数)

省略可能

接続を待機する間のキューに登録された要求の最大数。

Maximum requests (最大要求数)

省略可能

アップストリームへの未処理要求の最大数。

Maximum retries (最大再試行数)

省略可能

未処理再試行の最大数。

Maximum connection pools (最大接続プール数)

省略可能

アップストリームへの同時に開始される接続プールの最大数。
管理 Flex Gateway または接続モードでは、同じアップストリームを要求する際に各 API インスタンスに独立した制限があるため、それぞれで最大数いっぱいまで使用できます。
# サーキットブレーカーポリシー

ポリシー名

サーキットブレーカー

概要

アップストリームが受信する要求または接続が多くなりすぎるのを防止する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

503 - Service Unavailable (サービスを利用できません)
## [](#概要)概要 サーキットブレーカーポリシーでは、アップストリームサービスが一度に受信する要求または接続が多くなりすぎるのを防止します。定義済みの最大数に達すると、Flex Gateway によって ​`503 - Service Unavailable (サービスを利用できません)`​ エラーが返されます。 管理 Flex Gateway または接続モードでは、同じアップストリームを要求する際に各 API インスタンスに独立した制限があるため、それぞれで最大数いっぱいまで使用できます。ローカルモードでは、制限が異なる API インスタンス間で共有されるため、すべてが同じアップストリームの最大数に従う必要があります。すべてのモードで、最大数はレプリカ間で分配されず、それぞれのゲートウェイで最大数いっぱいまで使用できます。 サーキットブレーカーポリシーは、Envoy アップストリームクラスターサーキットブレーク機能の拡張機能です。Envoy のサーキットブレークについての詳細は、Envoy ドキュメントの [「Circuit Breaking (サーキットブレーク)」](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking.html)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: upstream-policy spec: targetRef: Kind: Service name: upstream policyRef: name: circuit-breaker-flex config: thresholds: maxConnections: // OPTIONAL maxPendingRequests: // OPTIONAL maxRequests: // OPTIONAL maxRetries: // OPTIONAL maxConnectionPools: // OPTIONAL
ローカルモードでは制限が独立していないため、異なる API インスタンスでアップストリームの最大数を共有します。
パラメーター 必須または省略可能 説明

maximumConnections

省略可能

アップストリームへの API ごとの接続の最大数。

maximumPendingRequests

省略可能

接続を待機する間のキューに登録された要求の最大数。

maximumRequests

省略可能

アップストリームへの未処理要求の最大数。

maximumRetries

省略可能

未処理再試行の最大数。

maximumConnectionPools

省略可能

アップストリームへの同時に開始される接続プールの最大数。
#### [](#リソースの設定例)リソースの設定例 次の例では、一度に最大 1 つの要求をサポートするポリシーを定義します。 apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: circuit-breaker namespace: test-ns spec: circuitBreaker: thresholds: maxConnections: 1 maxPendingRequests: 1 maxRequests: 1 maxRetries: 1 maxConnectionPools: 1 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 必須または省略可能 説明

Maximum connections (最大接続数)

省略可能

アップストリームへの API ごとの接続の最大数。

Maximum pending requests (最大の保留中の要求数)

省略可能

接続を待機する間のキューに登録された要求の最大数。

Maximum requests (最大要求数)

省略可能

アップストリームへの未処理要求の最大数。

Maximum retries (最大再試行数)

省略可能

未処理再試行の最大数。

Maximum connection pools (最大接続プール数)

省略可能

アップストリームへの同時に開始される接続プールの最大数。
管理 Flex Gateway または接続モードでは、同じアップストリームを要求する際に各 API インスタンスに独立した制限があるため、それぞれで最大数いっぱいまで使用できます。
# サードパーティサービスの Flex Gateway ログ出力の設定 Anypoint Flex Gatewa を使用すると、サポートされている Fluent Bit v3.2.10 出力種別にランタイムとアクセスログを配信できます。カスタム YAML ファイルを介してログ出力を設定します。さらに、アクセスログを表示するには、メッセージログポリシーも適用する必要があります。 次の設定ファイルの例は、Flex Gateway ログを出力種別 (​`File`​、​`HTTP`​、および ​`Splunk`​) に送信する方法を示しています。ただし、​`Azure Log Analytics`​、​`Amazon S3`​、​`Kafka`​ など、任意の Fluent Bit v3.2.10 出力種別を使用できます。Fluent Bit 出力種別の完全なリストについては、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 追加の Fluent Bit ログ出力種別を設定できるだけでなく、Flex Gateway はランタイムログを Runtime Manager に送信し、アクセスログを API Manager に送信します。詳細は、次を参照してください。 - [接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager) - [接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-message-log)。

20%

25%

20%

Linux サービスとして Flex Gateway のログ出力を設定する

Docker コンテナで Flex Gateway のログ出力を設定する

Kubernetes クラスターで Flex Gateway のログ出力を設定する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) さらに、出力に応じて、ログの送信先のサービスが動作していて、必要な情報が揃っていることを確認します。 - Splunk: - 実行中の [Splunk](https://www.splunk.com/)​ サービス。無料の Splunk Cloud トライアルを使用して Splunk をテストできます。 - Cloud または Enterprise Splunk サービスに HTTP イベントコレクター (HEC) データ入力を追加済み。データ入力を追加する方法と HEC トークンを作成する方法については、 [Splunk ドキュメント](https://docs.splunk.com/Documentation/Splunk/7.0.3/Data/UsetheHTTPEventCollector)​ を参照してください。 - Dynatrace: - 実行中の [Dynatrace](https://www.dynatrace.com/)​ サービス。無料の Dynatrace トライアルを使用して Dynatrace をテストできます。 - 環境 ID。Dynatrace 環境 ID の見つけ方については、 [「環境 ID」](https://www.dynatrace.com/support/help/get-started/monitoring-environment/environment-id)​を参照してください。 - アクセストークン。Dynatrace アクセストークンを生成するには、 [「アクセストークン」](https://www.dynatrace.com/support/help/manage/access-control/access-tokens)​を参照してください。トークンに ​`Ingest logs`​ トークンスコープがあることを確認します。 ## [](#ランタイムログとアクセスログ)ランタイムログとアクセスログ ランタイムログとアクセスログの両方は、同じログ出力に表示されます。ただし、両方のログをログ出力に含めるかどうかを選択できます。アクセスログを使用するには、メッセージログポリシーも適用する必要があります。 ### [](#ランタイムログ)ランタイムログ ランタイムログには、次の情報が含まれます。 - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン - デプロイされた API とポリシー - Flex Gateway の設定ミスの可能性またはその他のエラー ### [](#アクセスログ)アクセスログ アクセスログには、一定期間の Envoy との受信インタラクション、および特定の API に対する受信要求と応答が示されます。 アクセスログを有効にするには、監視する API インスタンスにメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](#configure-access-logs)​を参照してください。 ## [](#ログ設定ファイル)ログ設定ファイル `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.2.10 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
適用された値を含む設定ファイルを確認するには、次の設定ファイルの例を参照してください。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ## [](#linux)Linux サービスとして Flex Gateway のログ出力を設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/logs-config.yaml ``` 2. 次の例に示すように、目的の出力設定の詳細でファイルを更新します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging)を参照してください。 3. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#docker)Docker コンテナで Flex Gateway のログ出力を設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 次の例に示すように、目的の出力設定の詳細を含む YAML ファイルを作成して保存します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging)を参照してください。 5. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のログ出力を設定する Flex Gateway のログを設定する手順は、次のとおりです。 1. 次の例に示すように、目的の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging)を参照してください。 2. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#file-configuration-example)ファイルの設定例 書式設定されたランタイムログとアクセスログを ​`/var/log`​ ディレクトリの ​`log.txt`​ という名前のファイル (Fluent Bit の ​`File`​ 出力) に送信するように Flex Gateway を設定します。この例の定義では、​`file`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: file parameters: file: /var/log/log.txt # Docker: replace `/var/log` with the absolute path to the mounted configuration directory format: template template: | [{date}][{logger}][{level}][{kind}] {message} runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ```
Docker の場合は、​spec.logging.output.parameters.file​ の ​/var/log​ を、マウントされた設定ディレクトリへの絶対パスに置き換えてください。
## [](#http-configuration-example)HTTP の設定例 書式設定されたランタイムログとアクセスログを ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。この例の定義では、​`HTTP`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: HTTP parameters: host: collectors.au.sumologic.com port: "443" URI: /receiver/v1/http/[PrivateKey] format: json_lines json_date_key: timestamp json_date_format: iso8601 runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ``` ## [](#splunk-configuration-example)Splunk の設定例 Splunk は、このリソースを適用するとすぐにログの取り込みを開始します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: splunk-config spec: logging: outputs: - name: splunk type: splunk parameters: host: .splunkcloud.com port: "8088" splunk_token: tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: [splunk] accessLogs: outputs: [splunk] ``` ## [](#dynatrace-configuration-example)Dynatrace の設定例 書式設定されたランタイムログとアクセスログを Dynatrace 環境の ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。たとえば、次のファイルには必要な設定が含まれています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: dynatrace-config spec: logging: outputs: - name: dynatrace type: http parameters: host: .live.dynatrace.com Port: "443" allow_duplicated_headers: "false" header: - Content-Type application/json; charset=utf-8 - Authorization Api-Token URI: /api/v2/logs/ingest Format: json json_date_key: timestamp json_date_format: iso8601 tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: - dynatrace accessLogs: outputs: - dynatrace ``` 設定オプションについての詳細は、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 ## [](#configure-access-logs)アクセスログの設定 ログ出力内のアクセスログを設定するには、要求および応答データの監視の対象である API にメッセージログポリシーを適用する必要があります。すでにメッセージログポリシーを API インスタンスに割り当てている場合、別のメッセージログポリシーを設定する必要はありません。 メッセージログポリシーを設定するには、[接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-message-log)を参照してください。 メッセージログポリシーを設定すると、API Manager の ​**\[Logs (ログ)\]**​ とサードパーティログサービスの両方にアクセスログが表示されます。 アクセスログが表示されない場合、メッセージログポリシーが実行される前に、より高い実行順序を持つポリシーによってエラーが発生している可能性があります。ポリシーの実行を並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.10/policies-reorder)を参照してください。 ## [](#ログイベントの例)ログイベントの例 次のログ出力の例は、次のイベントで発生する可能性がある出力を示しています。 - [グレースフルシャットダウン](#graceful-shutdowns) - [サービス停止](#service-disconnections) - [Envoy のクラッシュ](#envoy-crash) ### [](#graceful-shutdowns)グレースフルシャットダウン \[flex-gateway-agent\]\[info\] SignalHandler: Signal terminated received \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ### [](#service-disconnections)サービス停止 \[flex-gateway-agent\]\[error\] WebSocket receiver got error: read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[warn\] Dropped connection due to error read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Reconnecting after connection was dropped \[flex-gateway-agent\]\[error\] Error connecting to Websocket Server: dial tcp: lookup arm-mcm2-service.kstg.msap.io on 192.168.65.7:53: dial udp 192.168.65.7:53: connect: network is unreachable ### [](#envoy-crash)Envoy のクラッシュ \[flex-gateway-envoy\]\[critical\] Caught Segmentation fault, suspect faulting address 0xffff87e8fb89485b \[flex-gateway-envoy\]\[critical\] Backtrace (use tools/stack\_decode.py to get line numbers): \[flex-gateway-envoy\]\[critical\] Envoy version: 36cbae1aeedd8c3b4eb88cd28268d21fe0905ce5/1.23.0/Clean/RELEASE/BoringSSL \[flex-gateway-envoy\]\[critical\] #0: \_\_restore\_rt \[0x7ff79db2f140\] \[flex-gateway-envoy\]\[critical\] #1: \[0x557dcfad249b\] \[flex-gateway-envoy\]\[critical\] #2: \[0x557dcdf35237\] \[flex-gateway-envoy\]\[critical\] #3: \[0x557dce16d49f\] \[flex-gateway-envoy\]\[critical\] #4: \[0x557dce1a8ff5\] \[flex-gateway-envoy\]\[critical\] #5: \[0x557dce1a8e47\] \[flex-gateway-envoy\]\[critical\] #6: ... \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error flex-gateway-envoy: command error: signal: segmentation fault \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ## [](#関連情報)関連情報 - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide#logging) - [接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-message-log) - [Anypoint Platform への Flex Gateway ログ出力の無効化](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-disable-logs) # サードパーティサービスの Flex Gateway ログ出力の設定 Anypoint Flex Gatewa を使用すると、サポートされている Fluent Bit v3.0 出力種別にランタイムとアクセスログを配信できます。カスタム YAML ファイルを介してログ出力を設定します。さらに、アクセスログを表示するには、メッセージログポリシーも適用する必要があります。 次の設定ファイルの例は、Flex Gateway ログを出力種別 (​`File`​、​`HTTP`​、および ​`Splunk`​) に送信する方法を示しています。ただし、​`Azure Log Analytics`​、​`Amazon S3`​、​`Kafka`​ など、任意の Fluent Bit v3.0 出力種別を使用できます。Fluent Bit 出力種別の完全なリストについては、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 追加の Fluent Bit ログ出力種別を設定できるだけでなく、Flex Gateway はランタイムログを Runtime Manager に送信し、アクセスログを API Manager に送信します。詳細は、次を参照してください。 - [Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager) - [接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-message-log)。

20%

25%

20%

Linux サービスとして Flex Gateway のログ出力を設定する

Docker コンテナで Flex Gateway のログ出力を設定する

Kubernetes クラスターで Flex Gateway のログ出力を設定する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) さらに、出力に応じて、ログの送信先のサービスが動作していて、必要な情報が揃っていることを確認します。 - Splunk: - 実行中の [Splunk](https://www.splunk.com/)​ サービス。無料の Splunk Cloud トライアルを使用して Splunk をテストできます。 - Cloud または Enterprise Splunk サービスに HTTP イベントコレクター (HEC) データ入力を追加済み。データ入力を追加する方法と HEC トークンを作成する方法については、 [Splunk ドキュメント](https://docs.splunk.com/Documentation/Splunk/7.0.3/Data/UsetheHTTPEventCollector)​ を参照してください。 - Dynatrace: - 実行中の [Dynatrace](https://www.dynatrace.com/)​ サービス。無料の Dynatrace トライアルを使用して Dynatrace をテストできます。 - 環境 ID。Dynatrace 環境 ID の見つけ方については、 [「環境 ID」](https://www.dynatrace.com/support/help/get-started/monitoring-environment/environment-id)​を参照してください。 - アクセストークン。Dynatrace アクセストークンを生成するには、 [「アクセストークン」](https://www.dynatrace.com/support/help/manage/access-control/access-tokens)​を参照してください。トークンに ​`Ingest logs`​ トークンスコープがあることを確認します。 ## [](#ランタイムログとアクセスログ)ランタイムログとアクセスログ ランタイムログとアクセスログの両方は、同じログ出力に表示されます。ただし、両方のログをログ出力に含めるかどうかを選択できます。アクセスログを使用するには、メッセージログポリシーも適用する必要があります。 ### [](#ランタイムログ)ランタイムログ ランタイムログには、次の情報が含まれます。 - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン - デプロイされた API とポリシー - Flex Gateway の設定ミスの可能性またはその他のエラー ### [](#アクセスログ)アクセスログ アクセスログには、一定期間の Envoy との受信インタラクション、および特定の API に対する受信要求と応答が示されます。 アクセスログを有効にするには、監視する API インスタンスにメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](#configure-access-logs)​を参照してください。 ## [](#ログ設定ファイル)ログ設定ファイル `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.0 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
適用された値を含む設定ファイルを確認するには、次の設定ファイルの例を参照してください。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ## [](#linux)Linux サービスとして Flex Gateway のログ出力を設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/logs-config.yaml ``` 2. 次の例に示すように、目的の出力設定の詳細でファイルを更新します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging)を参照してください。 3. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#docker)Docker コンテナで Flex Gateway のログ出力を設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 次の例に示すように、目的の出力設定の詳細を含む YAML ファイルを作成して保存します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging)を参照してください。 5. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のログ出力を設定する Flex Gateway のログを設定する手順は、次のとおりです。 1. 次の例に示すように、目的の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging)を参照してください。 2. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#file-configuration-example)ファイルの設定例 書式設定されたランタイムログとアクセスログを ​`/var/log`​ ディレクトリの ​`log.txt`​ という名前のファイル (Fluent Bit の ​`File`​ 出力) に送信するように Flex Gateway を設定します。この例の定義では、​`file`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: file parameters: file: /var/log/log.txt # Docker: replace `/var/log` with the absolute path to the mounted configuration directory format: template template: | [{date}][{logger}][{level}][{kind}] {message} runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ```
Docker の場合は、​spec.logging.output.parameters.file​ の ​/var/log​ を、マウントされた設定ディレクトリへの絶対パスに置き換えてください。
## [](#http-configuration-example)HTTP の設定例 書式設定されたランタイムログとアクセスログを ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。この例の定義では、​`HTTP`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: HTTP parameters: host: collectors.au.sumologic.com port: "443" URI: /receiver/v1/http/[PrivateKey] format: json_lines json_date_key: timestamp json_date_format: iso8601 runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ``` ## [](#splunk-configuration-example)Splunk の設定例 Splunk は、このリソースを適用するとすぐにログの取り込みを開始します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: splunk-config spec: logging: outputs: - name: splunk type: splunk parameters: host: .splunkcloud.com port: "8088" splunk_token: tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: [splunk] accessLogs: outputs: [splunk] ``` ## [](#dynatrace-configuration-example)Dynatrace の設定例 書式設定されたランタイムログとアクセスログを Dynatrace 環境の ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。たとえば、次のファイルには必要な設定が含まれています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: dynatrace-config spec: logging: outputs: - name: dynatrace type: http parameters: host: .live.dynatrace.com Port: "443" allow_duplicated_headers: "false" header: - Content-Type application/json; charset=utf-8 - Authorization Api-Token URI: /api/v2/logs/ingest Format: json json_date_key: timestamp json_date_format: iso8601 tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: - dynatrace accessLogs: outputs: - dynatrace ``` 設定オプションについての詳細は、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 ## [](#configure-access-logs)アクセスログの設定 ログ出力内のアクセスログを設定するには、要求および応答データの監視の対象である API にメッセージログポリシーを適用する必要があります。すでにメッセージログポリシーを API インスタンスに割り当てている場合、別のメッセージログポリシーを設定する必要はありません。 メッセージログポリシーを設定するには、[接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-message-log)を参照してください。 メッセージログポリシーを設定すると、API Manager の ​**\[Logs (ログ)\]**​ とサードパーティログサービスの両方にアクセスログが表示されます。 アクセスログが表示されない場合、メッセージログポリシーが実行される前に、より高い実行順序を持つポリシーによってエラーが発生している可能性があります。ポリシーの実行を並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.8/policies-reorder)を参照してください。 ## [](#ログイベントの例)ログイベントの例 次のログ出力の例は、次のイベントで発生する可能性がある出力を示しています。 - [グレースフルシャットダウン](#graceful-shutdowns) - [サービス停止](#service-disconnections) - [Envoy のクラッシュ](#envoy-crash) ### [](#graceful-shutdowns)グレースフルシャットダウン \[flex-gateway-agent\]\[info\] SignalHandler: Signal terminated received \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ### [](#service-disconnections)サービス停止 \[flex-gateway-agent\]\[error\] WebSocket receiver got error: read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[warn\] Dropped connection due to error read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Reconnecting after connection was dropped \[flex-gateway-agent\]\[error\] Error connecting to Websocket Server: dial tcp: lookup arm-mcm2-service.kstg.msap.io on 192.168.65.7:53: dial udp 192.168.65.7:53: connect: network is unreachable ### [](#envoy-crash)Envoy のクラッシュ \[flex-gateway-envoy\]\[critical\] Caught Segmentation fault, suspect faulting address 0xffff87e8fb89485b \[flex-gateway-envoy\]\[critical\] Backtrace (use tools/stack\_decode.py to get line numbers): \[flex-gateway-envoy\]\[critical\] Envoy version: 36cbae1aeedd8c3b4eb88cd28268d21fe0905ce5/1.23.0/Clean/RELEASE/BoringSSL \[flex-gateway-envoy\]\[critical\] #0: \_\_restore\_rt \[0x7ff79db2f140\] \[flex-gateway-envoy\]\[critical\] #1: \[0x557dcfad249b\] \[flex-gateway-envoy\]\[critical\] #2: \[0x557dcdf35237\] \[flex-gateway-envoy\]\[critical\] #3: \[0x557dce16d49f\] \[flex-gateway-envoy\]\[critical\] #4: \[0x557dce1a8ff5\] \[flex-gateway-envoy\]\[critical\] #5: \[0x557dce1a8e47\] \[flex-gateway-envoy\]\[critical\] #6: ... \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error flex-gateway-envoy: command error: signal: segmentation fault \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ## [](#関連情報)関連情報 - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide#logging) - [接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-message-log) - [Anypoint Platform への Flex Gateway ログ出力の無効化](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-disable-logs) # サードパーティサービスの Flex Gateway ログ出力の設定 Anypoint Flex Gatewa を使用すると、サポートされている Fluent Bit v3.0 出力種別にランタイムとアクセスログを配信できます。カスタム YAML ファイルを介してログ出力を設定します。さらに、アクセスログを表示するには、メッセージログポリシーも適用する必要があります。 次の設定ファイルの例は、Flex Gateway ログを出力種別 (​`File`​、​`HTTP`​、および ​`Splunk`​) に送信する方法を示しています。ただし、​`Azure Log Analytics`​、​`Amazon S3`​、​`Kafka`​ など、任意の Fluent Bit v3.0 出力種別を使用できます。Fluent Bit 出力種別の完全なリストについては、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 追加の Fluent Bit ログ出力種別を設定できるだけでなく、Flex Gateway はランタイムログを Runtime Manager に送信し、アクセスログを API Manager に送信します。詳細は、次を参照してください。 - [接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager) - [接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-message-log)。

20%

25%

20%

Linux サービスとして Flex Gateway のログ出力を設定する

Docker コンテナで Flex Gateway のログ出力を設定する

Kubernetes クラスターで Flex Gateway のログ出力を設定する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) さらに、出力に応じて、ログの送信先のサービスが動作していて、必要な情報が揃っていることを確認します。 - Splunk: - 実行中の [Splunk](https://www.splunk.com/)​ サービス。無料の Splunk Cloud トライアルを使用して Splunk をテストできます。 - Cloud または Enterprise Splunk サービスに HTTP イベントコレクター (HEC) データ入力を追加済み。データ入力を追加する方法と HEC トークンを作成する方法については、 [Splunk ドキュメント](https://docs.splunk.com/Documentation/Splunk/7.0.3/Data/UsetheHTTPEventCollector)​ を参照してください。 - Dynatrace: - 実行中の [Dynatrace](https://www.dynatrace.com/)​ サービス。無料の Dynatrace トライアルを使用して Dynatrace をテストできます。 - 環境 ID。Dynatrace 環境 ID の見つけ方については、 [「環境 ID」](https://www.dynatrace.com/support/help/get-started/monitoring-environment/environment-id)​を参照してください。 - アクセストークン。Dynatrace アクセストークンを生成するには、 [「アクセストークン」](https://www.dynatrace.com/support/help/manage/access-control/access-tokens)​を参照してください。トークンに ​`Ingest logs`​ トークンスコープがあることを確認します。 ## [](#ランタイムログとアクセスログ)ランタイムログとアクセスログ ランタイムログとアクセスログの両方は、同じログ出力に表示されます。ただし、両方のログをログ出力に含めるかどうかを選択できます。アクセスログを使用するには、メッセージログポリシーも適用する必要があります。 ### [](#ランタイムログ)ランタイムログ ランタイムログには、次の情報が含まれます。 - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン - デプロイされた API とポリシー - Flex Gateway の設定ミスの可能性またはその他のエラー ### [](#アクセスログ)アクセスログ アクセスログには、一定期間の Envoy との受信インタラクション、および特定の API に対する受信要求と応答が示されます。 アクセスログを有効にするには、監視する API インスタンスにメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](#configure-access-logs)​を参照してください。 ## [](#ログ設定ファイル)ログ設定ファイル `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.0 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
適用された値を含む設定ファイルを確認するには、次の設定ファイルの例を参照してください。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ## [](#linux)Linux サービスとして Flex Gateway のログ出力を設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/logs-config.yaml ``` 2. 次の例に示すように、目的の出力設定の詳細でファイルを更新します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging)を参照してください。 3. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#docker)Docker コンテナで Flex Gateway のログ出力を設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 次の例に示すように、目的の出力設定の詳細を含む YAML ファイルを作成して保存します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging)を参照してください。 5. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のログ出力を設定する Flex Gateway のログを設定する手順は、次のとおりです。 1. 次の例に示すように、目的の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway ランタイムログに設定エラーがないか確認します。 ランタイムログを表示するには、[接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager)を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging)を参照してください。 2. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#file-configuration-example)ファイルの設定例 書式設定されたランタイムログとアクセスログを ​`/var/log`​ ディレクトリの ​`log.txt`​ という名前のファイル (Fluent Bit の ​`File`​ 出力) に送信するように Flex Gateway を設定します。この例の定義では、​`file`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: file parameters: file: /var/log/log.txt # Docker: replace `/var/log` with the absolute path to the mounted configuration directory format: template template: | [{date}][{logger}][{level}][{kind}] {message} runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ```
Docker の場合は、​spec.logging.output.parameters.file​ の ​/var/log​ を、マウントされた設定ディレクトリへの絶対パスに置き換えてください。
## [](#http-configuration-example)HTTP の設定例 書式設定されたランタイムログとアクセスログを ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。この例の定義では、​`HTTP`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: HTTP parameters: host: collectors.au.sumologic.com port: "443" URI: /receiver/v1/http/[PrivateKey] format: json_lines json_date_key: timestamp json_date_format: iso8601 runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ``` ## [](#splunk-configuration-example)Splunk の設定例 Splunk は、このリソースを適用するとすぐにログの取り込みを開始します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: splunk-config spec: logging: outputs: - name: splunk type: splunk parameters: host: .splunkcloud.com port: "8088" splunk_token: tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: [splunk] accessLogs: outputs: [splunk] ``` ## [](#dynatrace-configuration-example)Dynatrace の設定例 書式設定されたランタイムログとアクセスログを Dynatrace 環境の ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。たとえば、次のファイルには必要な設定が含まれています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: dynatrace-config spec: logging: outputs: - name: dynatrace type: http parameters: host: .live.dynatrace.com Port: "443" allow_duplicated_headers: "false" header: - Content-Type application/json; charset=utf-8 - Authorization Api-Token URI: /api/v2/logs/ingest Format: json json_date_key: timestamp json_date_format: iso8601 tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: - dynatrace accessLogs: outputs: - dynatrace ``` 設定オプションについての詳細は、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 ## [](#configure-access-logs)アクセスログの設定 ログ出力内のアクセスログを設定するには、要求および応答データの監視の対象である API にメッセージログポリシーを適用する必要があります。すでにメッセージログポリシーを API インスタンスに割り当てている場合、別のメッセージログポリシーを設定する必要はありません。 メッセージログポリシーを設定するには、[接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-message-log)を参照してください。 メッセージログポリシーを設定すると、API Manager の ​**\[Logs (ログ)\]**​ とサードパーティログサービスの両方にアクセスログが表示されます。 アクセスログが表示されない場合、メッセージログポリシーが実行される前に、より高い実行順序を持つポリシーによってエラーが発生している可能性があります。ポリシーの実行を並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.9/policies-reorder)を参照してください。 ## [](#ログイベントの例)ログイベントの例 次のログ出力の例は、次のイベントで発生する可能性がある出力を示しています。 - [グレースフルシャットダウン](#graceful-shutdowns) - [サービス停止](#service-disconnections) - [Envoy のクラッシュ](#envoy-crash) ### [](#graceful-shutdowns)グレースフルシャットダウン \[flex-gateway-agent\]\[info\] SignalHandler: Signal terminated received \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ### [](#service-disconnections)サービス停止 \[flex-gateway-agent\]\[error\] WebSocket receiver got error: read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[warn\] Dropped connection due to error read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Reconnecting after connection was dropped \[flex-gateway-agent\]\[error\] Error connecting to Websocket Server: dial tcp: lookup arm-mcm2-service.kstg.msap.io on 192.168.65.7:53: dial udp 192.168.65.7:53: connect: network is unreachable ### [](#envoy-crash)Envoy のクラッシュ \[flex-gateway-envoy\]\[critical\] Caught Segmentation fault, suspect faulting address 0xffff87e8fb89485b \[flex-gateway-envoy\]\[critical\] Backtrace (use tools/stack\_decode.py to get line numbers): \[flex-gateway-envoy\]\[critical\] Envoy version: 36cbae1aeedd8c3b4eb88cd28268d21fe0905ce5/1.23.0/Clean/RELEASE/BoringSSL \[flex-gateway-envoy\]\[critical\] #0: \_\_restore\_rt \[0x7ff79db2f140\] \[flex-gateway-envoy\]\[critical\] #1: \[0x557dcfad249b\] \[flex-gateway-envoy\]\[critical\] #2: \[0x557dcdf35237\] \[flex-gateway-envoy\]\[critical\] #3: \[0x557dce16d49f\] \[flex-gateway-envoy\]\[critical\] #4: \[0x557dce1a8ff5\] \[flex-gateway-envoy\]\[critical\] #5: \[0x557dce1a8e47\] \[flex-gateway-envoy\]\[critical\] #6: ... \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error flex-gateway-envoy: command error: signal: segmentation fault \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ## [](#関連情報)関連情報 - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide#logging) - [接続モードでの Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-message-log) - [Anypoint Platform への Flex Gateway ログ出力の無効化](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-disable-logs) # スキーマ検証ポリシー

ポリシー名

スキーマ検証ポリシー

概要

指定された API スキーマに対して受信トラフィックを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

400 - 要求プロパティが API 仕様に準拠していません。
## [](#概要)概要
スキーマ検証ポリシーでは REST API のみがサポートされていて、現在のところ OpenAPI 仕様 3.0 (OAS3) スキーマ検証のみがサポートされています。
スキーマ検証ポリシーでは ​number​ スキーマデータ型について最大 64 ビットがサポートされます。
REST API 要求を処理するアプリケーションは、ヘッダー挿入やペイロード挿入などの攻撃を受けやすくなっています。また、他の脆弱性により機密情報にアクセスされる可能性があります。スキーマ検証ポリシーでは、指定された API 仕様に対してトラフィックを検証することで、このような攻撃と脆弱性から保護します。 REST API 仕様をアップロードする方法は多数ありますが、Exchange を使用する方法が最も簡単です。API 仕様を Exchange にアップロードするには、​[「Exchange アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset)​を参照してください。 Flex Gateway では、1 つのファイルに含まれている JSON または YAML で定義されたスキーマがサポートされます。 スキーマ検証ポリシーでは、リクエストヘッダー、クエリ、またはパスパラメーターが検証されます。 要求には、コンテンツタイプ ​`application/json`​ の JSON 形式のサポートのみが含まれます。 次のいずれかのアクションを実行するようにポリシーを設定します。 - 要求をブロックした後、400 エラー状況コードを返す。 - 要求を許可し、エラーを記録した後、要求の状況コードを返す。 次に対してコンテンツを検証することができます。 - すべての必須プロパティが存在すること。 - 追加プロパティの有無。 - すべてのプロパティの型。 たとえば、スキーマでプロパティが整数として指定されている場合、要求には文字列などの別の型ではなく整数が含まれている必要があります。 - プロパティの形式。 たとえば、​`pattern`​ キーワードが指定されている場合、ポリシーではプロパティが正規表現として検証されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: spec-validation-flex config: source: // REQUIRED spec: // REQUIRED apiBasePath: // OPTIONAL blockOperation: // REQUIRED strictParamsValidation: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

source

必須

context

スキーマがこの YAML リソースで指定されているか、Exchange の API コンテキストで指定されているか (接続モードのみ) を決定します。サポートされている値: inline​ または ​context​。ローカルモードでポリシーを設定する場合、​inline​ を指定する必要があります。

spec

必須

""

実際のインライン仕様。ローカルモードでポリシーを設定する場合、これを指定する必要があります。

apiBasePath

省略可能

"/"

API のベースパス。ローカルモードでポリシーを設定する場合、この値を指定する必要があります。

blockOperation

必須

true

true​ の場合、このポリシーでは無効な仕様検証がブロックされます。​false​ の場合、このポリシーではエラーのみが記録されます。

strictParamsValidation

省略可能

false

仕様で定義されていないクエリパラメーターを検証するかどうかを決定します。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: spec-validation-flex config: source: "inline" apiBasePath: "/" blockOperation: true strictParamsValidation: false spec: | { "openapi": "3.0.2", ... } ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
項目 説明 デフォルト 必須

Block request (要求をブロック)

API 仕様に準拠していない受信要求をブロックには、選択します。ブロックしないように選択すると、要求のみが記録されます。無効な要求をブロックするように選択すると、要求が無効な場合に 400 の状況が返されます。

Block enabled (ブロックが有効)

いいえ

Strict query parameters validation (クエリパラメーターの厳格な検証)

API 仕様で定義されていないクエリパラメーターからの API コールを制限します。

いいえ

いいえ

Advanced Options (詳細オプション)

Policy version (ポリシーバージョン)

適用されるポリシーのバージョン

Latest (最新)

はい

Rule of application (適用のルール)

ポリシーを適用するランタイムを設定します。現在、スキーマ検証は Flex Gateway でのみ使用できます。ポリシーをすべてのランタイムに適用しても、ポリシーは Flex Gateway API にのみ適用されます。

All runtimes (すべてのランタイム)
# スキーマ検証ポリシー

ポリシー名

スキーマ検証ポリシー

概要

指定された API スキーマに対して受信トラフィックを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

400 - 要求プロパティが API 仕様に準拠していません。
## [](#概要)概要
スキーマ検証ポリシーでは REST API のみがサポートされていて、現在のところ OpenAPI 仕様 3.0 (OAS3) スキーマ検証のみがサポートされています。
スキーマ検証ポリシーでは ​number​ スキーマデータ型について最大 64 ビットがサポートされます。
REST API 要求を処理するアプリケーションは、ヘッダー挿入やペイロード挿入などの攻撃を受けやすくなっています。また、他の脆弱性により機密情報にアクセスされる可能性があります。スキーマ検証ポリシーでは、指定された API 仕様に対してトラフィックを検証することで、このような攻撃と脆弱性から保護します。 REST API 仕様をアップロードする方法は多数ありますが、Exchange を使用する方法が最も簡単です。API 仕様を Exchange にアップロードするには、​[「Exchange アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset)​を参照してください。 Flex Gateway では、1 つのファイルに含まれている JSON または YAML で定義されたスキーマがサポートされます。 スキーマ検証ポリシーでは、リクエストヘッダー、クエリ、またはパスパラメーターが検証されます。 要求には、コンテンツタイプ ​`application/json`​ の JSON 形式のサポートのみが含まれます。 次のいずれかのアクションを実行するようにポリシーを設定します。 - 要求をブロックした後、400 エラー状況コードを返す。 - 要求を許可し、エラーを記録した後、要求の状況コードを返す。 次に対してコンテンツを検証することができます。 - すべての必須プロパティが存在すること。 - 追加プロパティの有無。 - すべてのプロパティの型。 たとえば、スキーマでプロパティが整数として指定されている場合、要求には文字列などの別の型ではなく整数が含まれている必要があります。 - プロパティの形式。 たとえば、​`pattern`​ キーワードが指定されている場合、ポリシーではプロパティが正規表現として検証されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してスキーマ検証ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: spec-validation-flex config: source: // REQUIRED spec: // REQUIRED apiBasePath: // OPTIONAL blockOperation: // REQUIRED strictParamsValidation: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

source

必須

context

スキーマがこの YAML リソースで指定されているか、Exchange の API コンテキストで指定されているか (接続モードのみ) を決定します。サポートされている値: inline​ または ​context​。ローカルモードでポリシーを設定する場合、​inline​ を指定する必要があります。

spec

必須

""

実際のインライン仕様。ローカルモードでポリシーを設定する場合、これを指定する必要があります。

apiBasePath

省略可能

"/"

API のベースパス。ローカルモードでポリシーを設定する場合、この値を指定する必要があります。

blockOperation

必須

true

true​ の場合、このポリシーでは無効な仕様検証がブロックされます。​false​ の場合、このポリシーではエラーのみが記録されます。

strictParamsValidation

省略可能

false

仕様で定義されていないクエリパラメーターを検証するかどうかを決定します。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: spec-validation-flex config: source: "inline" apiBasePath: "/" blockOperation: true strictParamsValidation: false spec: | { "openapi": "3.0.2", ... } ``` ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からスキーマ検証ポリシーを API に適用するときに、以下のパラメーターが表示されます。
項目 説明 デフォルト 必須

Block request (要求をブロック)

API 仕様に準拠していない受信要求をブロックには、選択します。ブロックしないように選択すると、要求のみが記録されます。無効な要求をブロックするように選択すると、要求が無効な場合に 400 の状況が返されます。

Block enabled (ブロックが有効)

いいえ

Strict query parameters validation (クエリパラメーターの厳格な検証)

API 仕様で定義されていないクエリパラメーターからの API コールを制限します。

いいえ

いいえ

Advanced Options (詳細オプション)

Policy version (ポリシーバージョン)

適用されるポリシーのバージョン

Latest (最新)

はい

Rule of application (適用のルール)

ポリシーを適用するランタイムを設定します。現在、スキーマ検証は Flex Gateway でのみ使用できます。ポリシーをすべてのランタイムに適用しても、ポリシーは Flex Gateway API にのみ適用されます。

All runtimes (すべてのランタイム)
# スキーマ検証ポリシー

ポリシー名

スキーマ検証ポリシー

概要

指定された API スキーマに対して受信トラフィックを検証する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

400 - 要求プロパティが API 仕様に準拠していません。
## [](#概要)概要
スキーマ検証ポリシーでは REST API のみがサポートされていて、現在のところ OpenAPI 仕様 3.0 (OAS3) スキーマ検証のみがサポートされています。
スキーマ検証ポリシーでは ​number​ スキーマデータ型について最大 64 ビットがサポートされます。
REST API 要求を処理するアプリケーションは、ヘッダー挿入やペイロード挿入などの攻撃を受けやすくなっています。また、他の脆弱性により機密情報にアクセスされる可能性があります。スキーマ検証ポリシーでは、指定された API 仕様に対してトラフィックを検証することで、このような攻撃と脆弱性から保護します。 REST API 仕様をアップロードする方法は多数ありますが、Exchange を使用する方法が最も簡単です。API 仕様を Exchange にアップロードするには、​[「Exchange アセットの作成」](https://docs.mulesoft.com/jp/exchange/to-create-an-asset)​を参照してください。 Flex Gateway では、1 つのファイルに含まれている JSON または YAML で定義されたスキーマがサポートされます。 スキーマ検証ポリシーでは、リクエストヘッダー、クエリ、またはパスパラメーターが検証されます。 要求には、コンテンツタイプ ​`application/json`​ の JSON 形式のサポートのみが含まれます。 次のいずれかのアクションを実行するようにポリシーを設定します。 - 要求をブロックした後、400 エラー状況コードを返す。 - 要求を許可し、エラーを記録した後、要求の状況コードを返す。 次に対してコンテンツを検証することができます。 - すべての必須プロパティが存在すること。 - 追加プロパティの有無。 - すべてのプロパティの型。 たとえば、スキーマでプロパティが整数として指定されている場合、要求には文字列などの別の型ではなく整数が含まれている必要があります。 - プロパティの形式。 たとえば、​`pattern`​ キーワードが指定されている場合、ポリシーではプロパティが正規表現として検証されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: spec-validation-flex config: source: // REQUIRED spec: // REQUIRED apiBasePath: // OPTIONAL blockOperation: // REQUIRED strictParamsValidation: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

source

必須

context

スキーマがこの YAML リソースで指定されているか、Exchange の API コンテキストで指定されているか (接続モードのみ) を決定します。サポートされている値: inline​ または ​context​。ローカルモードでポリシーを設定する場合、​inline​ を指定する必要があります。

spec

必須

""

実際のインライン仕様。ローカルモードでポリシーを設定する場合、これを指定する必要があります。

apiBasePath

省略可能

"/"

API のベースパス。ローカルモードでポリシーを設定する場合、この値を指定する必要があります。

blockOperation

必須

true

true​ の場合、このポリシーでは無効な仕様検証がブロックされます。​false​ の場合、このポリシーではエラーのみが記録されます。

strictParamsValidation

省略可能

false

仕様で定義されていないクエリパラメーターを検証するかどうかを決定します。
#### [](#リソースの設定例)リソースの設定例 ```yaml - policyRef: name: spec-validation-flex config: source: "inline" apiBasePath: "/" blockOperation: true strictParamsValidation: false spec: | { "openapi": "3.0.2", ... } ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
項目 説明 デフォルト 必須

Block request (要求をブロック)

API 仕様に準拠していない受信要求をブロックには、選択します。ブロックしないように選択すると、要求のみが記録されます。無効な要求をブロックするように選択すると、要求が無効な場合に 400 の状況が返されます。

Block enabled (ブロックが有効)

いいえ

Strict query parameters validation (クエリパラメーターの厳格な検証)

API 仕様で定義されていないクエリパラメーターからの API コールを制限します。

いいえ

いいえ

Advanced Options (詳細オプション)

Policy version (ポリシーバージョン)

適用されるポリシーのバージョン

Latest (最新)

はい

Rule of application (適用のルール)

ポリシーを適用するランタイムを設定します。現在、スキーマ検証は Flex Gateway でのみ使用できます。ポリシーをすべてのランタイムに適用しても、ポリシーは Flex Gateway API にのみ適用されます。

All runtimes (すべてのランタイム)
# ストリームアイドルタイムアウトポリシー

ポリシー名

ストリームアイドルタイムアウト

概要

ストリームが要求または応答を受信せずにアイドル状態を続けられる最大期間を設定する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

504 - ストリームタイムアウト
## [](#概要)概要 ストリームアイドルタイムアウトポリシーでは、ストリームがクライアントから Flex Gateway へのインバウンドまたは Flex Gateway からアップストリームサービスへのアウトバウンドのデータを受信せずにアイドル状態を続けられる最大時間を設定します。このポリシーにより、アイドル接続で不必要にリソースがコンシュームされるのを防止します。タイムアウト期間はストリームの最後のアクティビティ時に開始されます。アクティビティが要求であるか応答であるかは問いません。 デフォルトでは、すべての Flex Gateway API インスタンスに 300 秒のストリームタイムアウトが設定されています。このポリシーを適用すると、デフォルトのタイムアウトを上書きします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: stream-idle-timeout-flex config: timeout: number // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

timeout

必須

300

Flex Gateway が接続を終了するまでの秒数。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: stream-idle-timeout-flex config: timeout: 3 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Stream idle timeout (ストリームアイドルタイムアウト)

Flex Gateway が接続を終了するまでの秒数。

はい
# ストリームアイドルタイムアウトポリシー

ポリシー名

ストリームアイドルタイムアウト

概要

ストリームが要求または応答を受信せずにアイドル状態を続けられる最大期間を設定する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

504 - ストリームタイムアウト
## [](#概要)概要 ストリームアイドルタイムアウトポリシーでは、ストリームがクライアントから Flex Gateway へのインバウンドまたは Flex Gateway からアップストリームサービスへのアウトバウンドのデータを受信せずにアイドル状態を続けられる最大時間を設定します。このポリシーにより、アイドル接続で不必要にリソースがコンシュームされるのを防止します。タイムアウト期間はストリームの最後のアクティビティ時に開始されます。アクティビティが要求であるか応答であるかは問いません。 デフォルトでは、すべての Flex Gateway API インスタンスに 300 秒のストリームタイムアウトが設定されています。このポリシーを適用すると、デフォルトのタイムアウトを上書きします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: stream-idle-timeout-flex config: timeout: number // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

timeout

必須

300

Flex Gateway が接続を終了するまでの秒数。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: stream-idle-timeout-flex config: timeout: 3 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Stream idle timeout (ストリームアイドルタイムアウト)

Flex Gateway が接続を終了するまでの秒数。

はい
# スパイク制御ポリシー

ポリシー名

スパイク制御

概要

API トラフィックを規制する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

429 - HTTP API による要求の数が設定された制限を超えました。指定された再試行回数を超えると要求は拒否されます。
## [](#概要)概要 スパイク制御ポリシーは、API で処理されるメッセージ数を制限して、API 要求トラフィックを規制します。このポリシーにより、指定された時間内に処理されるメッセージ数が、設定した制限を超えなくなります。この数を超えると、要求はキューに入り、設定したポリシーに基づいて再試行されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 スパイク制御ポリシーでは、クォータの適用は実行されません。設定パラメーターは、API およびバックエンドを保護するために制限されています。そのため、パフォーマンスを最大化するには、これらのパラメーターに設定する値をできる限り小さくします。 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: spike-control-flex config: maximumRequests: // REQUIRED, default: 1 timePeriodInMilliseconds: // REQUIRED, default: 1000 delayTimeInMillis: // REQUIRED, default: 1000 delayAttempts: // REQUIRED, default: 1 queuingLimit: // OPTIONAL, default: 0 exposeHeaders: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

maximumRequests

必須

1

時間枠内で許可される要求数

timePeriodInMilliseconds

必須

1000

時間枠のサイズ

delayTimeInMillis

必須

1000

クォータが残っていない場合の再試行までの各要求の保持時間

delayAttempts

必須

1

要求が再試行される回数。これを超えると拒否されます。

queuingLimit

省略可能

0

特定の期間にキューに入れることができる要求数

exposeHeaders

省略可能

false

内部 API のみに対して有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: spike-control-flex config: queuingLimit: 0 exposeHeaders: true delayTimeInMillis: 1000 timePeriodInMilliseconds: 1000 delayAttempts: 1 maximumRequests: 100000 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Number of Reqs (要求の数)

指定されたウィンドウで許可されている要求数/ミリ秒

はい

Time Period (期間)

要求の処理する期限 (ミリ秒)

はい

Delay Time in Milliseconds (遅延時間 (ミリ秒))

クォータが残っていない場合の再試行までの各要求の保持時間 (ミリ秒)

はい

Delay Attempts (遅延試行回数)

要求が再試行される回数。これを超えると拒否されます。

はい

Queuing Limit (キュー制限)

特定の期間にキューに入れることができる要求数

いいえ

Expose Headers (ヘッダーを公開)

内部 API の場合にのみ有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。

いいえ

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

はい
要求クォータを適用する方法は、​[レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-rate-limiting-sla) and [レート制限ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-rate-limiting)​を参照してください。 ## [](#ポリシーのしくみ)ポリシーのしくみ スパイク制御ポリシーは、​_スライディングウィンドウアルゴリズム_​を使用して、トラフィックの急増を緩和し、ゲートウェイインスタンスを保護します。ウィンドウの表示サイズは、結果の推移に合わせて自己調整されます。 現在のウィンドウに要求クォータが残っていない場合は、クライアントとの接続を閉じずに、後で処理するように要求をキューに入れることができます。ポリシーで要求をキューに入れるには、次の例に示すようにポリシーパラメーターを設定する必要があります。 - `Time Period`​: 1 秒 - `Number of Reqs`​: 2 - `Delay Time in Milliseconds`​: 499 ミリ秒 - `Delay Attempts`​: 1 - `Queuing Limit`​: 5 要求をキューに入れると、スレッドと HTTP 接続を保持する必要があります。ポリシーで ​`Queuing Limit`​ パラメーターを指定すると、リソースが不足しないようにゲートウェイが保護され、攻撃を受けた場合でも API が失敗しなくなります。 ## [](#要求のタイムライン)要求のタイムライン 次の図は、前のセクションで定義された設定を使用して、アルゴリズムによって受け入れられた各要求の有効期限を示しています。 ![要求の受け入れ、拒否、キューのタイムラインを示すタイムライン](/mulesoft/current/ja-jp/gateway/1.10/_images/spike-control.png) 1. 最初の 2 つの要求が受け入れられ、使用可能なクォータが 0 になります。 要求 1 から 1 秒 (​`window size`​ 値) 経過後にクォータが 1 に増えます。 2. 要求 3 を受信します。 使用可能なクォータがないため、この要求は 499 ミリ秒間キューに入れられます。 3. 要求 4 を受信します。 まだ使用可能なクォータがないたえ、この要求は 499 ミリ秒間キューに入れられます。 4. 要求 3 を再試行する少し前に、要求 1 で 1 秒経過したため、ウィンドウの範囲外になり、クォータが解放されます。 5. クォータが 1 になり、要求 3 が正常に再処理されます。 要求 2 で 1 秒経過するまでクォータは 0 に戻ります。 6. 要求 4 の遅延が終了したため再処理が必要です。 要求 4 が拒否されます。使用できるクォータが残っていないため、要求 2 と 3 で 1 秒が経過していません。要求 4 はそれ以上遅延しません。 7. 要求 5 を受信します。 要求 2 ですでに 1 秒以上経過したので、この要求は受け入れられます。 この例は、要求の遅延と、キューに入れてトラフィックの急増を規制する方法を示しています。競合の多いシナリオでは、バックエンドが適切に機能し続けます (最後の Y ミリ秒に処理される要求数が X を超えない)。 API を照会するユーザーには、レイテンシーは長くなりますが、要求が処理中であることが表示される場合があります。ポリシーの正確な設定は API とそのスループットのみに依存します。 ## [](#faq)FAQ **このスライディングウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** アルゴリズムは、スライディングウィンドウを使用して、ポリシーで設定されている期間でトランザクションを監視します。 **クォータを使い果たすとどうなりますか?** 要求クォータを使い果たすと、スパイク制御ポリシーによって要求がキューに登録され、設定に従って再試行されます。複数回の再試行後もクォータが残っていない場合、要求は拒否されます。他の要求用のクォータは、最初の要求がポリシーで設定されている時間制限を超えてから使用可能になります。このようにして、要求が循環して処理されます。 **複数のウィンドウを設定できますか?** いいえ。 スパイク制御ポリシーにより、バックエンドサーバーが処理容量を超えた数の要求を処理しないことが保証されます。説明責任を果たす必要がある場合は、レート制限 SLA ポリシーまたはレート制限ポリシーを使用してください。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 現在使用可能なクォータ量 - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 最も古い要求がスライディングウィンドウの外に出るまでの残り時間 (ミリ秒)。 クォータがまだ使用できる場合、引き続きアルゴリズムで新しい要求を処理できるため、ヘッダーは 0 (ゼロ) に設定されます。 デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **レート制限 SLA やスパイク制御ではなくレート制限 SLA ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # スパイク制御ポリシー

ポリシー名

スパイク制御

概要

API トラフィックを規制する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

429 - HTTP API による要求の数が設定された制限を超えました。指定された再試行回数を超えると要求は拒否されます。
## [](#概要)概要 スパイク制御ポリシーは、API で処理されるメッセージ数を制限して、API 要求トラフィックを規制します。このポリシーにより、指定された時間内に処理されるメッセージ数が、設定した制限を超えなくなります。この数を超えると、要求はキューに入り、設定したポリシーに基づいて再試行されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 スパイク制御ポリシーでは、クォータの適用は実行されません。設定パラメーターは、API およびバックエンドを保護するために制限されています。そのため、パフォーマンスを最大化するには、これらのパラメーターに設定する値をできる限り小さくします。 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してスパイク制御ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: spike-control-flex config: maximumRequests: // REQUIRED, default: 1 timePeriodInMilliseconds: // REQUIRED, default: 1000 delayTimeInMillis: // REQUIRED, default: 1000 delayAttempts: // REQUIRED, default: 1 queuingLimit: // OPTIONAL, default: 0 exposeHeaders: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

maximumRequests

必須

1

時間枠内で許可される要求数

timePeriodInMilliseconds

必須

1000

時間枠のサイズ

delayTimeInMillis

必須

1000

クォータが残っていない場合の再試行までの各要求の保持時間

delayAttempts

必須

1

要求が再試行される回数。これを超えると拒否されます。

queuingLimit

省略可能

0

特定の期間にキューに入れることができる要求数

exposeHeaders

省略可能

false

内部 API のみに対して有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: spike-control-flex config: queuingLimit: 0 exposeHeaders: true delayTimeInMillis: 1000 timePeriodInMilliseconds: 1000 delayAttempts: 1 maximumRequests: 100000 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Number of Reqs (要求の数)

指定されたウィンドウで許可されている要求数/ミリ秒

はい

Time Period (期間)

要求の処理する期限 (ミリ秒)

はい

Delay Time in Milliseconds (遅延時間 (ミリ秒))

クォータが残っていない場合の再試行までの各要求の保持時間 (ミリ秒)

はい

Delay Attempts (遅延試行回数)

要求が再試行される回数。これを超えると拒否されます。

はい

Queuing Limit (キュー制限)

特定の期間にキューに入れることができる要求数

いいえ

Expose Headers (ヘッダーを公開)

内部 API の場合にのみ有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。

いいえ

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

はい
要求クォータを適用する方法は、​[レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-rate-limiting-sla) and [レート制限ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-rate-limiting)​を参照してください。 ## [](#ポリシーのしくみ)ポリシーのしくみ スパイク制御ポリシーは、​_スライディングウィンドウアルゴリズム_​を使用して、トラフィックの急増を緩和し、ゲートウェイインスタンスを保護します。ウィンドウの表示サイズは、結果の推移に合わせて自己調整されます。 現在のウィンドウに要求クォータが残っていない場合は、クライアントとの接続を閉じずに、後で処理するように要求をキューに入れることができます。ポリシーで要求をキューに入れるには、次の例に示すようにポリシーパラメーターを設定する必要があります。 - `Time Period`​: 1 秒 - `Number of Reqs`​: 2 - `Delay Time in Milliseconds`​: 499 ミリ秒 - `Delay Attempts`​: 1 - `Queuing Limit`​: 5 要求をキューに入れると、スレッドと HTTP 接続を保持する必要があります。ポリシーで ​`Queuing Limit`​ パラメーターを指定すると、リソースが不足しないようにゲートウェイが保護され、攻撃を受けた場合でも API が失敗しなくなります。 ## [](#要求のタイムライン)要求のタイムライン 次の図は、前のセクションで定義された設定を使用して、アルゴリズムによって受け入れられた各要求の有効期限を示しています。 ![要求の受け入れ、拒否、キューのタイムライン](/mulesoft/current/ja-jp/gateway/1.8/_images/spike-control.png) 1. 最初の 2 つの要求が受け入れられ、使用可能なクォータが 0 になります。 要求 1 から 1 秒 (​`window size`​ 値) 経過後にクォータが 1 に増えます。 2. 要求 3 を受信します。 使用可能なクォータがないため、この要求は 499 ミリ秒間キューに入れられます。 3. 要求 4 を受信します。 まだ使用可能なクォータがないたえ、この要求は 499 ミリ秒間キューに入れられます。 4. 要求 3 を再試行する少し前に、要求 1 で 1 秒経過したため、ウィンドウの範囲外になり、クォータが解放されます。 5. クォータが 1 になり、要求 3 が正常に再処理されます。 要求 2 で 1 秒経過するまでクォータは 0 に戻ります。 6. 要求 4 の遅延が終了したため再処理が必要です。 要求 4 が拒否されます。使用できるクォータが残っていないため、要求 2 と 3 で 1 秒が経過していません。要求 4 はそれ以上遅延しません。 7. 要求 5 を受信します。 要求 2 ですでに 1 秒以上経過したので、この要求は受け入れられます。 この例は、要求の遅延と、キューに入れてトラフィックの急増を規制する方法を示しています。競合の多いシナリオでは、バックエンドが適切に機能し続けます (最後の Y ミリ秒に処理される要求数が X を超えない)。 API を照会するユーザーには、レイテンシーは長くなりますが、要求が処理中であることが表示される場合があります。ポリシーの正確な設定は API とそのスループットのみに依存します。 ## [](#faq)FAQ **このスライディングウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** アルゴリズムは、スライディングウィンドウを使用して、ポリシーで設定されている期間でトランザクションを監視します。 **クォータを使い果たすとどうなりますか?** 要求クォータを使い果たすと、スパイク制御ポリシーによって要求がキューに登録され、設定に従って再試行されます。複数回の再試行後もクォータが残っていない場合、要求は拒否されます。他の要求用のクォータは、最初の要求がポリシーで設定されている時間制限を超えてから使用可能になります。このようにして、要求が循環して処理されます。 **複数のウィンドウを設定できますか?** いいえ。 スパイク制御ポリシーにより、バックエンドサーバーが処理容量を超えた数の要求を処理しないことが保証されます。説明責任を果たす必要がある場合は、レート制限 SLA ポリシーまたはレート制限ポリシーを使用してください。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 現在使用可能なクォータ量 - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 最も古い要求がスライディングウィンドウの外に出るまでの残り時間 (ミリ秒)。 クォータがまだ使用できる場合、引き続きアルゴリズムで新しい要求を処理できるため、ヘッダーは 0 (ゼロ) に設定されます。 デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **レート制限 SLA やスパイク制御ではなくレート制限 SLA ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # スパイク制御ポリシー

ポリシー名

スパイク制御

概要

API トラフィックを規制する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

429 - HTTP API による要求の数が設定された制限を超えました。指定された再試行回数を超えると要求は拒否されます。
## [](#概要)概要 スパイク制御ポリシーは、API で処理されるメッセージ数を制限して、API 要求トラフィックを規制します。このポリシーにより、指定された時間内に処理されるメッセージ数が、設定した制限を超えなくなります。この数を超えると、要求はキューに入り、設定したポリシーに基づいて再試行されます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 スパイク制御ポリシーでは、クォータの適用は実行されません。設定パラメーターは、API およびバックエンドを保護するために制限されています。そのため、パフォーマンスを最大化するには、これらのパラメーターに設定する値をできる限り小さくします。 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: spike-control-flex config: maximumRequests: // REQUIRED, default: 1 timePeriodInMilliseconds: // REQUIRED, default: 1000 delayTimeInMillis: // REQUIRED, default: 1000 delayAttempts: // REQUIRED, default: 1 queuingLimit: // OPTIONAL, default: 0 exposeHeaders: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

maximumRequests

必須

1

時間枠内で許可される要求数

timePeriodInMilliseconds

必須

1000

時間枠のサイズ

delayTimeInMillis

必須

1000

クォータが残っていない場合の再試行までの各要求の保持時間

delayAttempts

必須

1

要求が再試行される回数。これを超えると拒否されます。

queuingLimit

省略可能

0

特定の期間にキューに入れることができる要求数

exposeHeaders

省略可能

false

内部 API のみに対して有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: spike-control-flex config: queuingLimit: 0 exposeHeaders: true delayTimeInMillis: 1000 timePeriodInMilliseconds: 1000 delayAttempts: 1 maximumRequests: 100000 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Number of Reqs (要求の数)

指定されたウィンドウで許可されている要求数/ミリ秒

はい

Time Period (期間)

要求の処理する期限 (ミリ秒)

はい

Delay Time in Milliseconds (遅延時間 (ミリ秒))

クォータが残っていない場合の再試行までの各要求の保持時間 (ミリ秒)

はい

Delay Attempts (遅延試行回数)

要求が再試行される回数。これを超えると拒否されます。

はい

Queuing Limit (キュー制限)

特定の期間にキューに入れることができる要求数

いいえ

Expose Headers (ヘッダーを公開)

内部 API の場合にのみ有効にします。ポリシーがアルゴリズムの動作に関する情報を X-RateLimit ヘッダーで返すことができるようにします。

いいえ

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

はい
要求クォータを適用する方法は、​[レート制限: SLA ベースのポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-rate-limiting-sla) and [レート制限ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-rate-limiting)​を参照してください。 ## [](#ポリシーのしくみ)ポリシーのしくみ スパイク制御ポリシーは、​_スライディングウィンドウアルゴリズム_​を使用して、トラフィックの急増を緩和し、ゲートウェイインスタンスを保護します。ウィンドウの表示サイズは、結果の推移に合わせて自己調整されます。 現在のウィンドウに要求クォータが残っていない場合は、クライアントとの接続を閉じずに、後で処理するように要求をキューに入れることができます。ポリシーで要求をキューに入れるには、次の例に示すようにポリシーパラメーターを設定する必要があります。 - `Time Period`​: 1 秒 - `Number of Reqs`​: 2 - `Delay Time in Milliseconds`​: 499 ミリ秒 - `Delay Attempts`​: 1 - `Queuing Limit`​: 5 要求をキューに入れると、スレッドと HTTP 接続を保持する必要があります。ポリシーで ​`Queuing Limit`​ パラメーターを指定すると、リソースが不足しないようにゲートウェイが保護され、攻撃を受けた場合でも API が失敗しなくなります。 ## [](#要求のタイムライン)要求のタイムライン 次の図は、前のセクションで定義された設定を使用して、アルゴリズムによって受け入れられた各要求の有効期限を示しています。 ![要求の受け入れ、拒否、キューのタイムラインを示すタイムライン](/mulesoft/current/ja-jp/gateway/1.9/_images/spike-control.png) 1. 最初の 2 つの要求が受け入れられ、使用可能なクォータが 0 になります。 要求 1 から 1 秒 (​`window size`​ 値) 経過後にクォータが 1 に増えます。 2. 要求 3 を受信します。 使用可能なクォータがないため、この要求は 499 ミリ秒間キューに入れられます。 3. 要求 4 を受信します。 まだ使用可能なクォータがないたえ、この要求は 499 ミリ秒間キューに入れられます。 4. 要求 3 を再試行する少し前に、要求 1 で 1 秒経過したため、ウィンドウの範囲外になり、クォータが解放されます。 5. クォータが 1 になり、要求 3 が正常に再処理されます。 要求 2 で 1 秒経過するまでクォータは 0 に戻ります。 6. 要求 4 の遅延が終了したため再処理が必要です。 要求 4 が拒否されます。使用できるクォータが残っていないため、要求 2 と 3 で 1 秒が経過していません。要求 4 はそれ以上遅延しません。 7. 要求 5 を受信します。 要求 2 ですでに 1 秒以上経過したので、この要求は受け入れられます。 この例は、要求の遅延と、キューに入れてトラフィックの急増を規制する方法を示しています。競合の多いシナリオでは、バックエンドが適切に機能し続けます (最後の Y ミリ秒に処理される要求数が X を超えない)。 API を照会するユーザーには、レイテンシーは長くなりますが、要求が処理中であることが表示される場合があります。ポリシーの正確な設定は API とそのスループットのみに依存します。 ## [](#faq)FAQ **このスライディングウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** アルゴリズムは、スライディングウィンドウを使用して、ポリシーで設定されている期間でトランザクションを監視します。 **クォータを使い果たすとどうなりますか?** 要求クォータを使い果たすと、スパイク制御ポリシーによって要求がキューに登録され、設定に従って再試行されます。複数回の再試行後もクォータが残っていない場合、要求は拒否されます。他の要求用のクォータは、最初の要求がポリシーで設定されている時間制限を超えてから使用可能になります。このようにして、要求が循環して処理されます。 **複数のウィンドウを設定できますか?** いいえ。 スパイク制御ポリシーにより、バックエンドサーバーが処理容量を超えた数の要求を処理しないことが保証されます。説明責任を果たす必要がある場合は、レート制限 SLA ポリシーまたはレート制限ポリシーを使用してください。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 現在使用可能なクォータ量 - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 最も古い要求がスライディングウィンドウの外に出るまでの残り時間 (ミリ秒)。 クォータがまだ使用できる場合、引き続きアルゴリズムで新しい要求を処理できるため、ヘッダーは 0 (ゼロ) に設定されます。 デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **レート制限 SLA やスパイク制御ではなくレート制限 SLA ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # デバッグログを使用したトラブルシューティング Flex Gateway のトラブルシューティングを行う場合、ランタイムログレベルを ​`debug`​ に設定して、より詳細なランタイムログを取得します。 このページでは、デバッグランタイムログの設定方法について説明します。デバッグアクセスログを設定するには、​[メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-message-logging)​の ​`level`​ パラメーターを ​`DEBUG`​ に設定します。 ## [](#デバッグログの設定の例)デバッグログの設定の例 接続モードとローカルモードの両方で、次の YAML 設定ファイルを使用してデバッグランタイムログを設定します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: debug ``` デバッグランタイムログを設定するには、次のチュートリアルで設定の詳細が要求された場合に前述の YAML 設定ファイルを使用します。 - [接続モードでの外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-third-party-logs-config) - [ローカルモードでの外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-third-party-logs-config) ログ設定ファイルをすでに設定している場合は、現在のファイルの ​`logging.runtimeLogs.logLevel`​ を ​`debug`​ に設定して、デバッグランタイムログを有効にします。これは、ログ出力の場所やアクセスログに影響しません。 ## [](#関連情報)関連情報 - [Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager) - [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-view-logs) # デバッグログを使用した自己管理ゲートウェイのトラブルシューティング Flex Gateway のトラブルシューティングを行う場合、ランタイムログレベルを ​`debug`​ に設定して、より詳細なランタイムログを取得します。 このページでは、デバッグランタイムログの設定方法について説明します。デバッグアクセスログを設定するには、​[メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-message-logging)​の ​`level`​ パラメーターを ​`DEBUG`​ に設定します。 ## [](#デバッグログの設定の例)デバッグログの設定の例 接続モードとローカルモードの両方で、次の YAML 設定ファイルを使用してデバッグランタイムログを設定します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: debug ``` デバッグランタイムログを設定するには、次のチュートリアルで設定の詳細が要求された場合に前述の YAML 設定ファイルを使用します。 - [接続モードでの外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-third-party-logs-config) - [ローカルモードでの外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-third-party-logs-config) ログ設定ファイルをすでに設定している場合は、現在のファイルの ​`logging.runtimeLogs.logLevel`​ を ​`debug`​ に設定して、デバッグランタイムログを有効にします。これは、ログ出力の場所やアクセスログに影響しません。 ## [](#関連情報)関連情報 ランタイムログ出力を表示するには、次を参照してください。 - [接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager) - [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-view-logs) # デバッグログを使用した自己管理ゲートウェイのトラブルシューティング Flex Gateway のトラブルシューティングを行う場合、ランタイムログレベルを ​`debug`​ に設定して、より詳細なランタイムログを取得します。 このページでは、デバッグランタイムログの設定方法について説明します。デバッグアクセスログを設定するには、​[メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-message-logging)​の ​`level`​ パラメーターを ​`DEBUG`​ に設定します。 ## [](#デバッグログの設定の例)デバッグログの設定の例 接続モードとローカルモードの両方で、次の YAML 設定ファイルを使用してデバッグランタイムログを設定します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: runtimeLogs: logLevel: debug ``` デバッグランタイムログを設定するには、次のチュートリアルで設定の詳細が要求された場合に前述の YAML 設定ファイルを使用します。 - [接続モードでの外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-third-party-logs-config) - [ローカルモードでの外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-third-party-logs-config) ログ設定ファイルをすでに設定している場合は、現在のファイルの ​`logging.runtimeLogs.logLevel`​ を ​`debug`​ に設定して、デバッグランタイムログを有効にします。これは、ログ出力の場所やアクセスログに影響しません。 ## [](#関連情報)関連情報 ランタイムログ出力を表示するには、次を参照してください。 - [接続モードの Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager) - [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-view-logs) # トラブルシューティング Anypoint Flex Gateway タスクを実行すると、問題が発生したり、エラーメッセージが表示されたりする場合があります。これらの問題を解決するための情報は、以下のトピックを参照してください。 - [デバッグログを使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-debug-logs) - [登録の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-reg) - [Linux 権限のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-linux-permissions) - [プラットフォーム接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-platform-connection) - [ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging) - [Linux サービスのトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-linux-services) - [Admin API を使用したトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-admin-api) - [SOAP API のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-soap-apis) - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-requests) - [Docker コマンドの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-docker) - [Helm コマンドの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-helm) - [正規表現の互換性の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-regex) # トレースポリシー

ポリシー名

トレース

概要

グローバルトレース設定を上書きする

カテゴリ

トラブルシューティング

使用可能な最小 Flex Gateway バージョン

1.10.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 トレースポリシーにより、API のグローバル分散トレースパラメーターを上書きできます。 ## [](#始める前に)始める前に 分散トレースはこのデフォルトで無効になっています。Flex Gateway グローバル設定を使用して分散トレースを有効化した後に、このポリシーを使用して API のグローバル分散トレースパラメーターを上書きできるようになります。 分散トレースを有効にする方法についての詳細は、以下を参照してください。 - [ローカルモードでの Flex Gateway 分散トレースの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tracing-config) - [接続モードでの Flex Gateway 分散トレースの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tracing-config) - [管理 Flex Gateway の分散トレースの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-tracing-config) ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: tracing-flex config: sampling: client: number // REQUIRED random: number // REQUIRED overall: number // REQUIRED labels: // OPTIONAL, default: \[\] - name: // REQUIRED type: // REQUIRED keyName: // REQUIRED defaultValue: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

sampling.client

必須

100

x-client-trace-id​ ヘッダーが設定されている場合に強制的に追跡される要求の対象パーセンテージ。

sampling.random

必須

100

クライアントによって要求されない場合、または強制されない場合に、トレース生成にランダムに選択される要求の対象パーセンテージ。

sampling.overall

必須

100

クライアントダイレクト、強制トレース、ランダムサンプリングなど、他のすべてのサンプリングチェックが適用された後に追跡される要求の対象パーセンテージ。

labels

省略可能

空の配列

トレースデータのスパン属性として使用するためにトレースに追加される表示ラベルの配列。

labels.name

必須

なし

スパン属性名として使用される、表示ラベルの名前。

labels.type

必須

なし

表示ラベルの種別により、表示ラベルの値の取得元が指定されます。サポートされている値は、​literal​、​environment​、​requestHeader​ です。

labels.keyName

必須

なし

表示ラベルのキー名。

labels.defaultValue

必須

なし

表示ラベルのデフォルト値。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: tracing-flex config: sampling: client: 100 random: 100 overall: 100 labels: - name: c-env-tag type: environment keyName: FLEX\_NAME defaultValue: DEFAULT\_VAL - name: c-header-tag type: requestHeader keyName: :method defaultValue: DEFAULT\_METHOD - name: c-literal-tag type: literal defaultValue: the-tag ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Client Sampling (クライアントサンプリング)

x-client-trace-id​ ヘッダーが設定されている場合に強制的に追跡される要求の対象パーセンテージ。

はい

Random Sampling (ランダムサンプリング)

クライアントによって要求されない場合、または強制されない場合に、トレース生成にランダムに選択される要求の対象パーセンテージ。

はい

Overall Sampling (全体サンプリング)

クライアントダイレクト、強制トレース、ランダムサンプリングなど、他のすべてのサンプリングチェックが適用された後に追跡される要求の対象パーセンテージ。

はい

Labels (表示ラベル)

トレースデータのスパン属性として使用するためにトレースに追加される表示ラベルの配列。

省略可能

Label Name (表示ラベル名)

スパン属性名として使用される、表示ラベルの名前。

はい

Label Type (表示ラベル種別)

表示ラベルの種別により、表示ラベルの値の取得元が指定されます。サポートされている値は、​literal​、​environment​、​requestHeader​ です。

はい

Label Key Name (表示ラベルキー名)

環境変数やリクエストヘッダー名など、値の取得に使用されるキー。

はい

Label Default Value (表示ラベルのデフォルト値)

キーが見つからない場合、または取得された値が空の場合に使用するデフォルト値。

はい
# プラットフォーム接続のトラブルシューティング Flex Gateway の設定時に、Flex レプリカの ​`registration.yaml`​ が存在しない場合や、レプリカで Anypoint Platform への接続が失われる場合があります。 登録ファイルが存在するかどうか、Flex Gateway がプラットフォーム接続を行うことができるかどうかをトラブルシューティングするには、次のコマンドを使用します。 ```ssh flexctl check connections ``` `flexctl check connections`​ コマンドは、最初に ​`registration.yaml`​ ファイルが存在することを確認します。次に、レプリカが登録ファイルで定義された URL に接続できるかどうかをチェックします。​`flexctl check connections`​ コマンドは成功すると、次の ​`info`​ メッセージを返します。 $ flexctl check connections \[flexctl\]\[info\] Connection to platform endpoints successful. ## [](#登録ファイルが見つからない)登録ファイルが見つからない `registration.yaml`​ ファイルが見つからない場合、Flex Gateway によって次のエラーメッセージが返されます。 $ flexctl check connections Error: no registration config 存在しない登録ファイルをトラブルシューティングするには、Flex レプリカ設定フォルダーをチェックしてください。Flex Gateway の登録についての詳細は、関連するモードの次のセクションを参照してください。 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) ## [](#接続失敗)接続失敗 Flex Gateway で接続の問題が発生する原因としては、ゲートウェイの環境のエラーやネットワークの問題など、いくつかの原因が考えられます。エラーのトラブルシューティング方法は、返されるエラーに応じて異なります。 Flex Gateway が特定の URL に接続できない場合は、到達できなかった URL と接続試行から返されたエラーメッセージが含まれるエラーメッセージが返されます。次のエラーメッセージは、インターネット接続がないために返されるエラーの例です。 $ flexctl check connections Error: failed connecting to https://anypoint.mulesoft.com/: dial tcp 52.22.227.22:443: connect: network is unreachable ## [](#関連情報)関連情報 - [登録の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-reg) - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-requests) # プラットフォーム接続のトラブルシューティング Flex Gateway の設定時に、Flex レプリカの ​`registration.yaml`​ が存在しない場合や、レプリカで Anypoint Platform への接続が失われる場合があります。 登録ファイルが存在するかどうか、Flex Gateway がプラットフォーム接続を行うことができるかどうかをトラブルシューティングするには、次のコマンドを使用します。 ```ssh flexctl check connections ``` `flexctl check connections`​ コマンドは、最初に ​`registration.yaml`​ ファイルが存在することを確認します。次に、レプリカが登録ファイルで定義された URL に接続できるかどうかをチェックします。​`flexctl check connections`​ コマンドは成功すると、次の ​`info`​ メッセージを返します。 $ flexctl check connections \[flexctl\]\[info\] Connection to platform endpoints successful. ## [](#登録ファイルが見つからない)登録ファイルが見つからない `registration.yaml`​ ファイルが見つからない場合、Flex Gateway によって次のエラーメッセージが返されます。 $ flexctl check connections Error: no registration config 存在しない登録ファイルをトラブルシューティングするには、Flex レプリカ設定フォルダーをチェックしてください。Flex Gateway の登録についての詳細は、関連するモードの次のセクションを参照してください。 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) ## [](#接続失敗)接続失敗 Flex Gateway で接続の問題が発生する原因としては、ゲートウェイの環境のエラーやネットワークの問題など、いくつかの原因が考えられます。エラーのトラブルシューティング方法は、返されるエラーに応じて異なります。 Flex Gateway が特定の URL に接続できない場合は、到達できなかった URL と接続試行から返されたエラーメッセージが含まれるエラーメッセージが返されます。次のエラーメッセージは、インターネット接続がないために返されるエラーの例です。 $ flexctl check connections Error: failed connecting to https://anypoint.mulesoft.com/: dial tcp 52.22.227.22:443: connect: network is unreachable ## [](#関連情報)関連情報 - [登録の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-reg) - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-requests) # プラットフォーム接続のトラブルシューティング Flex Gateway の設定時に、Flex レプリカの ​`registration.yaml`​ が存在しない場合や、レプリカで Anypoint Platform への接続が失われる場合があります。 登録ファイルが存在するかどうか、Flex Gateway がプラットフォーム接続を行うことができるかどうかをトラブルシューティングするには、次のコマンドを使用します。 ```ssh flexctl check connections ``` `flexctl check connections`​ コマンドは、最初に ​`registration.yaml`​ ファイルが存在することを確認します。次に、レプリカが登録ファイルで定義された URL に接続できるかどうかをチェックします。​`flexctl check connections`​ コマンドは成功すると、次の ​`info`​ メッセージを返します。 $ flexctl check connections \[flexctl\]\[info\] Connection to platform endpoints successful. ## [](#登録ファイルが見つからない)登録ファイルが見つからない `registration.yaml`​ ファイルが見つからない場合、Flex Gateway によって次のエラーメッセージが返されます。 $ flexctl check connections Error: no registration config 存在しない登録ファイルをトラブルシューティングするには、Flex レプリカ設定フォルダーをチェックしてください。Flex Gateway の登録についての詳細は、関連するモードの次のセクションを参照してください。 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) ## [](#接続失敗)接続失敗 Flex Gateway で接続の問題が発生する原因としては、ゲートウェイの環境のエラーやネットワークの問題など、いくつかの原因が考えられます。エラーのトラブルシューティング方法は、返されるエラーに応じて異なります。 Flex Gateway が特定の URL に接続できない場合は、到達できなかった URL と接続試行から返されたエラーメッセージが含まれるエラーメッセージが返されます。次のエラーメッセージは、インターネット接続がないために返されるエラーの例です。 $ flexctl check connections Error: failed connecting to https://anypoint.mulesoft.com/: dial tcp 52.22.227.22:443: connect: network is unreachable ## [](#関連情報)関連情報 - [登録の問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-reg) - [要求接続のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-requests) # ヘッダー削除ポリシー

ポリシー名

ヘッダーの削除

概要

要求または応答からヘッダーを削除する

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 キー-値ペアを使用して、削除するヘッダーのインバウンドおよびアウトバウンドマップを指定すると、ヘッダー削除ポリシーにより、リストされたすべてのヘッダーがメッセージの要求または応答から削除されます。 ![プロキシを介して API にアクセスするクライアントのヘッダー挿入および削除ポリシーを設定するプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”`
次のヘッダーは削除できません。 accept、 host、 content-type、 content-length、 date、 transfer-encoding、 connection。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: header-removal-flex config: inboundHeaders: // OPTIONAL, default: \[\] outboundHeaders: // OPTIONAL, default: \[\]
パラメーター 必須または省略可能 デフォルト値 説明

inboundHeaders

省略可能

空の配列

メッセージ処理の先頭で削除するヘッダー名または正規表現のマップ。例: Cache-Control, Access-Control.*​

outboundHeaders

省略可能

空の配列

メッセージ処理の末尾で削除するヘッダー名または正規表現のマップ。例: Access-Control-Allow-Credentials​

inboundHeaders​ と ​outboundHeaders​ の両方を空にすることはできません。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: header-removal-flex config: inboundHeaders: - "Cache-Control" - "Access-Control.\*" outboundHeaders: - "Access-Control-Allow-Credentials" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の先頭で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Cache-Control, Access-Control.*

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の末尾で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Access-Control-Allow-Credentials

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション
## [](#ポリシーのしくみ)ポリシーのしくみ ヘッダー削除ポリシーのパラメーターに一致するすべてのヘッダーがメッセージから削除されるため、パラメーターの設定方法については注意する必要があります。 たとえば、次のパラメーター設定では、単語 ​`Access-Control`​ で始まるヘッダー (​`Access-Control-Allow-Credentials`​ ヘッダーや ​`Access-Control-Allow-Origin`​ ヘッダーなど) がメッセージから削除されます。この設定により、​`Cache-Control`​ ヘッダーも削除されます。 ![メッセージ処理の開始時に削除されるヘッダー](/mulesoft/current/ja-jp/gateway/1.10/_images/remove-inbound-header.png) Figure 1. インバウンドヘッダー # ヘッダー削除ポリシー

ポリシー名

ヘッダーの削除

概要

要求または応答からヘッダーを削除する

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 キー-値ペアを使用して、削除するヘッダーのインバウンドおよびアウトバウンドマップを指定すると、ヘッダー削除ポリシーにより、リストされたすべてのヘッダーがメッセージの要求または応答から削除されます。 ![header inject remove diagram](/mulesoft/current/ja-jp/gateway/1.8/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”`
次のヘッダーは削除できません。 accept、 host、 content-type、 content-length、 date、 transfer-encoding、 connection。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してヘッダーの削除ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: header-removal-flex config: inboundHeaders: // OPTIONAL, default: \[\] outboundHeaders: // OPTIONAL, default: \[\]
パラメーター 必須または省略可能 デフォルト値 説明

inboundHeaders

省略可能

空の配列

メッセージ処理の先頭で削除するヘッダー名または正規表現のマップ。例: Cache-Control, Access-Control.*​

outboundHeaders

省略可能

空の配列

メッセージ処理の末尾で削除するヘッダー名または正規表現のマップ。例: Access-Control-Allow-Credentials​

inboundHeaders​ と ​outboundHeaders​ の両方を空にすることはできません。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: header-removal-flex config: inboundHeaders: - "Cache-Control" - "Access-Control.\*" outboundHeaders: - "Access-Control-Allow-Credentials" ### [](#flex-gateway-の接続モードと-mule-ゲートウェイ)Flex Gateway の接続モードと Mule ゲートウェイ UI からヘッダー削除ポリシーを API に適用する場合、次のパラメーターを設定できます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の先頭で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Cache-Control, Access-Control.*

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の末尾で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Access-Control-Allow-Credentials

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション
## [](#ポリシーのしくみ)ポリシーのしくみ ヘッダー削除ポリシーのパラメーターに一致するすべてのヘッダーがメッセージから削除されるため、パラメーターの設定方法については注意する必要があります。 たとえば、次のパラメーター設定では、単語 ​`Access-Control`​ で始まるヘッダー (​`Access-Control-Allow-Credentials`​ ヘッダーや ​`Access-Control-Allow-Origin`​ ヘッダーなど) がメッセージから削除されます。この設定により、​`Cache-Control`​ ヘッダーも削除されます。 ![remove inbound header](/mulesoft/current/ja-jp/gateway/1.8/_images/remove-inbound-header.png) Figure 1. インバウンドヘッダー # ヘッダー削除ポリシー

ポリシー名

ヘッダーの削除

概要

要求または応答からヘッダーを削除する

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 キー-値ペアを使用して、削除するヘッダーのインバウンドおよびアウトバウンドマップを指定すると、ヘッダー削除ポリシーにより、リストされたすべてのヘッダーがメッセージの要求または応答から削除されます。 ![プロキシを介して API にアクセスするクライアントのヘッダー挿入および削除ポリシーを設定するプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”`
次のヘッダーは削除できません。 accept、 host、 content-type、 content-length、 date、 transfer-encoding、 connection。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: header-removal-flex config: inboundHeaders: // OPTIONAL, default: \[\] outboundHeaders: // OPTIONAL, default: \[\]
パラメーター 必須または省略可能 デフォルト値 説明

inboundHeaders

省略可能

空の配列

メッセージ処理の先頭で削除するヘッダー名または正規表現のマップ。例: Cache-Control, Access-Control.*​

outboundHeaders

省略可能

空の配列

メッセージ処理の末尾で削除するヘッダー名または正規表現のマップ。例: Access-Control-Allow-Credentials​

inboundHeaders​ と ​outboundHeaders​ の両方を空にすることはできません。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: header-removal-flex config: inboundHeaders: - "Cache-Control" - "Access-Control.\*" outboundHeaders: - "Access-Control-Allow-Credentials" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の先頭で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Cache-Control, Access-Control.*

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の末尾で削除するヘッダー名または正規表現のリスト (カンマ区切り)。例: Access-Control-Allow-Credentials

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション
## [](#ポリシーのしくみ)ポリシーのしくみ ヘッダー削除ポリシーのパラメーターに一致するすべてのヘッダーがメッセージから削除されるため、パラメーターの設定方法については注意する必要があります。 たとえば、次のパラメーター設定では、単語 ​`Access-Control`​ で始まるヘッダー (​`Access-Control-Allow-Credentials`​ ヘッダーや ​`Access-Control-Allow-Origin`​ ヘッダーなど) がメッセージから削除されます。この設定により、​`Cache-Control`​ ヘッダーも削除されます。 ![メッセージ処理の開始時に削除されるヘッダー](/mulesoft/current/ja-jp/gateway/1.9/_images/remove-inbound-header.png) Figure 1. インバウンドヘッダー # ヘッダー挿入ポリシー

ポリシー名

ヘッダーの挿入

Summary (概要)

要求または応答にヘッダーを追加します。

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 ヘッダー挿入ポリシーでは、メッセージの要求または応答に HTTP ヘッダーが追加されます。API でこのポリシーを設定する場合、メッセージ処理に追加するヘッダーのインバウンドおよびアウトバウンドマップをキー-値ペアの形式で指定する必要があります。 ![プロキシを介して API にアクセスするクライアントのヘッダー挿入および削除ポリシーを設定するプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値または名前に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”` 挿入されるヘッダーがすでにメッセージ属性に存在する場合、ポリシーは既存のヘッダーの値を上書きせずに新しいヘッダーを作成します。

複数の値のサポートは特定のヘッダーにのみ限定され、これらのヘッダーは設定された値を使用して上書きされます。これらのヘッダーは、​access-control-allow-origin​、​content-type​、​content-length​、​transfer-encoding​ です。

既存の他のメッセージヘッダーを上書きするには、ヘッダーを追加する前に既存のヘッダーを削除してください。​「ヘッダー削除​ポリシー」を参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: header-injection-flex config: inboundHeaders: // OPTIONAL, default: \[\] - key: // REQUIRED value: // REQUIRED outboundHeaders: // OPTIONAL, default: \[\] - key: // REQUIRED value: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

inboundHeaders

省略可能

空の配列

メッセージ処理の最初に挿入されるヘッダーのリスト。

inboundHeaders.key

必須

なし

ヘッダー名の文字列または DataWeave 式

inboundHeaders.value

必須

なし

ヘッダー値の文字列または DataWeave 式

outboundHeaders

省略可能

空の配列

メッセージ処理の最後に挿入されるヘッダーのリスト。

outboundHeaders.key

必須

なし

ヘッダー名の文字列または DataWeave 式

outboundHeaders.value

必須

なし

ヘッダー値の文字列または DataWeave 式

inboundHeaders​ と ​outboundHeaders​ の両方を空にすることはできません。
#### [](#リソースの設定例)リソースの設定例 次の例では、設定されている ​`#[attributes.requestPath]`​ 式に一致するすべてのヘッダーがメッセージに挿入されます。 \- policyRef: name: header-injection-flex config: inboundHeaders: - key: "new-inbound-header" value: "#\[attributes.requestPath\]" outboundHeaders: - key: "new-outbound-header" value: "#\[attributes.requestPath\]" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の最初に挿入されるヘッダーのリスト。

インバウンドヘッダーキー

メッセージの先頭でヘッダー名として使用する文字列または DataWeave 式。

インバウンドヘッダー値

メッセージの先頭でヘッダー値として使用する文字列または DataWeave 式。

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の最後に挿入されるヘッダーのリスト。

アウトバウンドヘッダーキー

メッセージ処理の最後にヘッダー名使用する文字列または DataWeave 式。

アウトバウンドヘッダー値

メッセージ処理の最後にヘッダー値として使用する文字列または DataWeave 式。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

ヘッダーキーは、 HTTP 1.1​ 標準に準拠している必要があります。
# ヘッダー挿入ポリシー

ポリシー名

ヘッダーの挿入

Summary (概要)

要求または応答にヘッダーを追加します。

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 ヘッダー挿入ポリシーでは、メッセージの要求または応答に HTTP ヘッダーが追加されます。API でこのポリシーを設定する場合、メッセージ処理に追加するヘッダーのインバウンドおよびアウトバウンドマップをキー-値ペアの形式で指定する必要があります。 ![header inject remove diagram](/mulesoft/current/ja-jp/gateway/1.8/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値または名前に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”` 挿入されるヘッダーがメッセージ属性に存在する場合、ポリシーは既存のヘッダーの値を上書きせずに新しいヘッダーを作成します。ただし、​`host`​ ヘッダーを上書きまたは挿入することはできません。

複数の値のサポートは特定のヘッダーにのみ限定され、これらのヘッダーは設定された値を使用して上書きされます。これらのヘッダーは、​access-control-allow-origin​、​content-type​、​content-length​、​transfer-encoding​ です。

既存の他のメッセージヘッダーを上書きするには、ヘッダーを追加する前に既存のヘッダーを削除してください。​「ヘッダー削除​ポリシー」を参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してヘッダーの挿入ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: header-injection-flex config: inboundHeaders: // OPTIONAL, default: \[\] - key: // REQUIRED value: // REQUIRED outboundHeaders: // OPTIONAL, default: \[\] - key: // REQUIRED value: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

inboundHeaders

省略可能

空の配列

メッセージ処理の最初に挿入されるヘッダーのリスト。

inboundHeaders.key

必須

なし

ヘッダー名の文字列または DataWeave 式

inboundHeaders.value

必須

なし

ヘッダー値の文字列または DataWeave 式

outboundHeaders

省略可能

空の配列

メッセージ処理の最後に挿入されるヘッダーのリスト。

outboundHeaders.key

必須

なし

ヘッダー名の文字列または DataWeave 式

outboundHeaders.value

必須

なし

ヘッダー値の文字列または DataWeave 式

inboundHeaders​ と ​outboundHeaders​ の両方を空にすることはできません。
#### [](#リソースの設定例)リソースの設定例 次の例では、設定されている ​`#[attributes.requestPath]`​ 式に一致するすべてのヘッダーがメッセージに挿入されます。 \- policyRef: name: header-injection-flex config: inboundHeaders: - key: "new-inbound-header" value: "#\[attributes.requestPath\]" outboundHeaders: - key: "new-outbound-header" value: "#\[attributes.requestPath\]" ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の最初に挿入されるヘッダーのリスト。

インバウンドヘッダーキー

メッセージの先頭でヘッダー名として使用する文字列または DataWeave 式。

インバウンドヘッダー値

メッセージの先頭でヘッダー値として使用する文字列または DataWeave 式。

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の最後に挿入されるヘッダーのリスト。

アウトバウンドヘッダーキー

メッセージ処理の最後にヘッダー名使用する文字列または DataWeave 式。

アウトバウンドヘッダー値

メッセージ処理の最後にヘッダー値として使用する文字列または DataWeave 式。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

ヘッダーキーは、 HTTP 1.1​ 標準に準拠している必要があります。
# ヘッダー挿入ポリシー

ポリシー名

ヘッダーの挿入

Summary (概要)

要求または応答にヘッダーを追加します。

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

500 - 評価されなかった式が設定に含まれる。
## [](#概要)概要 ヘッダー挿入ポリシーでは、メッセージの要求または応答に HTTP ヘッダーが追加されます。API でこのポリシーを設定する場合、メッセージ処理に追加するヘッダーのインバウンドおよびアウトバウンドマップをキー-値ペアの形式で指定する必要があります。 ![プロキシを介して API にアクセスするクライアントのヘッダー挿入および削除ポリシーを設定するプロセスを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/header-inject-remove-diagram.png) 必要に応じて、ヘッダーの値または名前に DataWeave 式を含めることができます。この例では、設定されている次の式に一致するすべてのヘッダーがメッセージに挿入されます。 `“#[attributes.requestPath]”` 挿入されるヘッダーがすでにメッセージ属性に存在する場合、ポリシーは既存のヘッダーの値を上書きせずに新しいヘッダーを作成します。

複数の値のサポートは特定のヘッダーにのみ限定され、これらのヘッダーは設定された値を使用して上書きされます。これらのヘッダーは、​access-control-allow-origin​、​content-type​、​content-length​、​transfer-encoding​ です。

既存の他のメッセージヘッダーを上書きするには、ヘッダーを追加する前に既存のヘッダーを削除してください。​「ヘッダー削除​ポリシー」を参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: header-injection-flex config: inboundHeaders: // OPTIONAL, default: \[\] - key: // REQUIRED value: // REQUIRED outboundHeaders: // OPTIONAL, default: \[\] - key: // REQUIRED value: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

inboundHeaders

省略可能

空の配列

メッセージ処理の最初に挿入されるヘッダーのリスト。

inboundHeaders.key

必須

なし

ヘッダー名の文字列または DataWeave 式

inboundHeaders.value

必須

なし

ヘッダー値の文字列または DataWeave 式

outboundHeaders

省略可能

空の配列

メッセージ処理の最後に挿入されるヘッダーのリスト。

outboundHeaders.key

必須

なし

ヘッダー名の文字列または DataWeave 式

outboundHeaders.value

必須

なし

ヘッダー値の文字列または DataWeave 式

inboundHeaders​ と ​outboundHeaders​ の両方を空にすることはできません。
#### [](#リソースの設定例)リソースの設定例 次の例では、設定されている ​`#[attributes.requestPath]`​ 式に一致するすべてのヘッダーがメッセージに挿入されます。 \- policyRef: name: header-injection-flex config: inboundHeaders: - key: "new-inbound-header" value: "#\[attributes.requestPath\]" outboundHeaders: - key: "new-outbound-header" value: "#\[attributes.requestPath\]" ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

Inbound Header Map (インバウンドヘッダーマップ)

メッセージ処理の最初に挿入されるヘッダーのリスト。

インバウンドヘッダーキー

メッセージの先頭でヘッダー名として使用する文字列または DataWeave 式。

インバウンドヘッダー値

メッセージの先頭でヘッダー値として使用する文字列または DataWeave 式。

Outbound Header Map (アウトバウンドヘッダーマップ)

メッセージ処理の最後に挿入されるヘッダーのリスト。

アウトバウンドヘッダーキー

メッセージ処理の最後にヘッダー名使用する文字列または DataWeave 式。

アウトバウンドヘッダー値

メッセージ処理の最後にヘッダー値として使用する文字列または DataWeave 式。

Method & Resource conditions (メソッドとリソースの条件)

API の一部またはすべてのメソッドおよびリソースに設定を追加するオプション

ヘッダーキーは、 HTTP 1.1​ 標準に準拠している必要があります。
# ポリシーの適用 接続モードで実行されている Flex Gateway では、API Manager を介して内部ポリシーを適用します。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを適用する API の名前をクリックします。 3. 左側のナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 5. 適用するポリシーを選択します。 6. 必須の設定パラメーターを設定します。 ポリシー設定パラメーターについては、​[「内部ポリシーディレクトリ」](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory)​を参照してください。 7. **\[Apply (適用)\]**​ をクリックします。 ポリシーは、API 全体 (デフォルト) または API の特定のメソッドやリソースに適用できます。 # ポリシーの順序付け 特定のポリシーをその他のポリシーより前に実行するには、内部ポリシーとカスタムポリシーの実行順序を設定します。 自動ポリシー、API レベルのポリシー、またはアップストリームレベルのポリシーとして実行されるように内部ポリシーとカスタムポリシーの両方を設定できます。自動ポリシーとは、Flex レプリカにデプロイされたすべての API インスタンスに適用され、API レベルのポリシーの前に実行されるポリシーです。API レベルのポリシーとは、特定の API インスタンスのみに適用されるインバウンドポリシーです。アップストリームレベルのポリシーは、特定のアップストリームに適用されるアウトバウンドポリシーです。 接続モードで実行されている Flex Gateway では、API Manager を使用してポリシーを並び替えます。ローカルモードで実行されている Flex Gateway では、​`PolicyBinding`​ YAML リソースを使用してポリシーを並び替えます。
クロスオリジンリソース共有 (CORS) ポリシー​の実行順序を設定することはできません。CORS ポリシーは自動ポリシーおよび API レベルポリシーより前に実行されます。
## [](#ポリシーの実行順序)ポリシーの実行順序 ポリシーは、API 要求、API 応答、またはその両方で実行できます。ポリシーは、API 要求時には順序どおりに、API 応答時には逆の順序で実行されます。ポリシーが特定の方向では実行されない場合、Flex Gateway ではその方向ではそのポリシーをスキップします。API 要求では、ポリシーは自動ポリシー、API レベルのポリシー、アウトバウンドポリシーの順で実行されます。応答ではこの順序が逆になります。 たとえば、次の順序で並んでいるポリシーがあるとします。 1. 自動ポリシー 1 2. 自動ポリシー 2 3. API レベルのポリシー 1 4. API レベルのポリシー 2 5. アップストリームレベルのポリシー 1 6. アップストリームレベルのポリシー 2 ポリシーは、応答では次の順序で実行されます。 1. アップストリームレベルのポリシー 2 2. アップストリームレベルのポリシー 1 3. API レベルのポリシー 2 4. API レベルのポリシー 1 5. 自動ポリシー 2 6. 自動ポリシー 1 ## [](#接続モードでの自動ポリシーの並び替え)接続モードでの自動ポリシーの並び替え API Manager で自動ポリシーの順序を設定することはできません。自動ポリシーは、API インスタンスに適用された順序で実行されます。自動ポリシーは実行する順序で適用してください。 ## [](#ローカルモードでの自動ポリシーの並び替え)ローカルモードでの自動ポリシーの並び替え ローカルモードで実行されている Flex Gateway に自動ポリシーを適用するには、リソースレベルのポリシーを適用する必要があります。これにより、同じポリシーを Flex レプリカで実行されているすべての API インスタンスに適用できます。 リソースレベルのポリシーをすべての API インスタンスに適用するには、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-secure-api-with-auto-policy)を参照してください。 リソースレベルの自動ポリシーを並び替えるには、ポリシーを実行するタイミングに一致するように ​`order`​ パラメーターを編集します。この順序が他のポリシーの順序と競合しないことを確認してください。たとえば、​`order: 1`​ と ​`order: 2`​ を使用して 2 つのリソースレベルの自動ポリシーを適用する場合、API レベルのポリシーはいずれも ​`order: 3`​ で始まる必要があります。 ## [](#管理-flex-gateway-と接続モードのインバウンド-api-レベルのポリシーを並び替える)管理 Flex Gateway と接続モードのインバウンド API レベルのポリシーを並び替える API レベルのポリシーを並び替える手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを並び替える API インスタンスの名前をクリックします。 3. 左側のナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. 適用済みポリシーのリストの最上部で、​**\[Reorder policies (ポリシーを並び替え)\]**​ をクリックします。 5. **\[Reorder Applied Policies (適用済みポリシーの並び替え)\]**​ セクションで、上矢印と下矢印を使用して、ポリシーの順序を再編成します。 6. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#管理-flex-gateway-と接続モードのアウトバウンドポリシーを並び替える)管理 Flex Gateway と接続モードのアウトバウンドポリシーを並び替える アウトバウンドポリシーを並び替える手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを並び替える API インスタンスの名前をクリックします。 3. サイドナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[Outbound policies (アウトバウンドポリシー)\]**​ タブをクリックします。 5. ポリシーを並び替えるアップストリームサービスのその他のオプションボタン (​![1%](/mulesoft/current/ja-jp/gateway/1.10/_images/more-options-menu.png)​)。 6. 上矢印と下矢印を使用して、ポリシーの順序を再編成します。 7. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#ローカルモードでのポリシーの並び替え)ローカルモードでのポリシーの並び替え ローカルモードで実行されている Flex Gateway では、​`PolicyBinding`​ YAML リソースを介してポリシーの順序を設定します。 `PolicyBinding`​ YAML リソースを使用してポリシーを定義する場合、ポリシーを実行するタイミングに一致するように ​`order`​ パラメーターを編集します。同じ順序番号を別のポリシーに割り当てないでください。 ローカルモードのポリシー順序については、​[「宣言型設定リファレンスガイド」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide#policy-binding)​を参照してください。 ## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) # ポリシーの順序付け 特定のポリシーをその他のポリシーより前に実行するには、内部ポリシーとカスタムポリシーの実行順序を設定します。 自動ポリシーまたは API レベルのポリシーとして実行されるように内部ポリシーとカスタムポリシーの両方を設定できます。自動ポリシーとは、Flex レプリカにデプロイされたすべての API インスタンスに適用され、API レベルのポリシーの前に実行されるポリシーです。API レベルのポリシーとは、特定の API インスタンスのみに適用されるポリシーです。 接続モードで実行されている Flex Gateway では、API Manager を使用してポリシーを並び替えます。ローカルモードで実行されている Flex Gateway では、​`PolicyBinding`​ YAML リソースを使用してポリシーを並び替えます。
クロスオリジンリソース共有 (CORS) ポリシー​の実行順序を設定することはできません。CORS ポリシーは自動ポリシーおよび API レベルポリシーより前に実行されます。
## [](#ポリシーの実行順序)ポリシーの実行順序 ポリシーは、API 要求、API 応答、またはその両方で実行できます。ポリシーは、API 要求時には順序どおりに、API 応答時には逆の順序で実行されます。ポリシーが特定の方向では実行されない場合、Flex Gateway ではその方向ではそのポリシーをスキップします。 たとえば、4 つのポリシーが次の順序になっているとします。 1. 自動ポリシー 1 2. 自動ポリシー 2 3. API レベルのポリシー 1 4. API レベルのポリシー 2 ポリシーは、応答では次の順序で実行されます。 1. API レベルのポリシー 2 2. API レベルのポリシー 1 3. 自動ポリシー 2 4. 自動ポリシー 1 ## [](#接続モードでの自動ポリシーの並び替え)接続モードでの自動ポリシーの並び替え API Manager で自動ポリシーの順序を設定することはできません。自動ポリシーは、API インスタンスに適用された順序で実行されます。自動ポリシーは実行する順序で適用してください。 ## [](#ローカルモードでの自動ポリシーの並び替え)ローカルモードでの自動ポリシーの並び替え ローカルモードで実行されている Flex Gateway に自動ポリシーを適用するには、リソースレベルのポリシーを適用する必要があります。これにより、同じポリシーを Flex レプリカで実行されているすべての API インスタンスに適用できます。 リソースレベルのポリシーをすべての API インスタンスに適用するには、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-secure-api-with-auto-policy)を参照してください。 リソースレベルの自動ポリシーを並び替えるには、ポリシーを実行するタイミングに一致するように ​`order`​ パラメーターを編集します。この順序が他のポリシーの順序と競合しないことを確認してください。たとえば、​`order: 1`​ と ​`order: 2`​ を使用して 2 つのリソースレベルの自動ポリシーを適用する場合、API レベルのポリシーはいずれも ​`order: 3`​ で始まる必要があります。 ## [](#接続モードで-api-レベルのポリシーを並び替える)接続モードで API レベルのポリシーを並び替える 接続モードで実行されている Flex Gateway で API レベルのポリシーを並び替える手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを並び替える API インスタンスの名前をクリックします。 3. 左側のナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. 適用済みポリシーのリストの最上部で、​**\[Reorder policies (ポリシーを並び替え)\]**​ をクリックします。 5. **\[Reorder Applied Policies (適用済みポリシーの並び替え)\]**​ セクションで、上矢印と下矢印を使用して、ポリシーの順序を再編成します。 6. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#ローカルモードでの-api-レベルのポリシーの並び替え)ローカルモードでの API レベルのポリシーの並び替え ローカルモードで実行されている Flex Gateway では、​`PolicyBinding`​ YAML リソースを介してポリシーの順序を設定します。 `PolicyBinding`​ YAML リソースを使用してポリシーを定義する場合、ポリシーを実行するタイミングに一致するように ​`order`​ パラメーターを編集します。同じ順序番号を別のポリシーに割り当てないでください。 ローカルモードのポリシー順序については、​[「宣言型設定リファレンスガイド」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide#policy-binding)​を参照してください。 ## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory) # ポリシーの順序付け 特定のポリシーをその他のポリシーより前に実行するには、内部ポリシーとカスタムポリシーの実行順序を設定します。 自動ポリシー、API レベルのポリシー、またはアップストリームレベルのポリシーとして実行されるように内部ポリシーとカスタムポリシーの両方を設定できます。自動ポリシーとは、Flex レプリカにデプロイされたすべての API インスタンスに適用され、API レベルのポリシーの前に実行されるポリシーです。API レベルのポリシーとは、特定の API インスタンスのみに適用されるインバウンドポリシーです。アップストリームレベルのポリシーは、特定のアップストリームに適用されるアウトバウンドポリシーです。 接続モードで実行されている Flex Gateway では、API Manager を使用してポリシーを並び替えます。ローカルモードで実行されている Flex Gateway では、​`PolicyBinding`​ YAML リソースを使用してポリシーを並び替えます。
クロスオリジンリソース共有 (CORS) ポリシー​の実行順序を設定することはできません。CORS ポリシーは自動ポリシーおよび API レベルポリシーより前に実行されます。
## [](#ポリシーの実行順序)ポリシーの実行順序 ポリシーは、API 要求、API 応答、またはその両方で実行できます。ポリシーは、API 要求時には順序どおりに、API 応答時には逆の順序で実行されます。ポリシーが特定の方向では実行されない場合、Flex Gateway ではその方向ではそのポリシーをスキップします。API 要求では、ポリシーは自動ポリシー、API レベルのポリシー、アウトバウンドポリシーの順で実行されます。応答ではこの順序が逆になります。 たとえば、次の順序で並んでいるポリシーがあるとします。 1. 自動ポリシー 1 2. 自動ポリシー 2 3. API レベルのポリシー 1 4. API レベルのポリシー 2 5. アップストリームレベルのポリシー 1 6. アップストリームレベルのポリシー 2 ポリシーは、応答では次の順序で実行されます。 1. アップストリームレベルのポリシー 2 2. アップストリームレベルのポリシー 1 3. API レベルのポリシー 2 4. API レベルのポリシー 1 5. 自動ポリシー 2 6. 自動ポリシー 1 ## [](#接続モードでの自動ポリシーの並び替え)接続モードでの自動ポリシーの並び替え API Manager で自動ポリシーの順序を設定することはできません。自動ポリシーは、API インスタンスに適用された順序で実行されます。自動ポリシーは実行する順序で適用してください。 ## [](#ローカルモードでの自動ポリシーの並び替え)ローカルモードでの自動ポリシーの並び替え ローカルモードで実行されている Flex Gateway に自動ポリシーを適用するには、リソースレベルのポリシーを適用する必要があります。これにより、同じポリシーを Flex レプリカで実行されているすべての API インスタンスに適用できます。 リソースレベルのポリシーをすべての API インスタンスに適用するには、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-secure-api-with-auto-policy)を参照してください。 リソースレベルの自動ポリシーを並び替えるには、ポリシーを実行するタイミングに一致するように ​`order`​ パラメーターを編集します。この順序が他のポリシーの順序と競合しないことを確認してください。たとえば、​`order: 1`​ と ​`order: 2`​ を使用して 2 つのリソースレベルの自動ポリシーを適用する場合、API レベルのポリシーはいずれも ​`order: 3`​ で始まる必要があります。 ## [](#管理-flex-gateway-と接続モードのインバウンド-api-レベルのポリシーを並び替える)管理 Flex Gateway と接続モードのインバウンド API レベルのポリシーを並び替える API レベルのポリシーを並び替える手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを並び替える API インスタンスの名前をクリックします。 3. 左側のナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. 適用済みポリシーのリストの最上部で、​**\[Reorder policies (ポリシーを並び替え)\]**​ をクリックします。 5. **\[Reorder Applied Policies (適用済みポリシーの並び替え)\]**​ セクションで、上矢印と下矢印を使用して、ポリシーの順序を再編成します。 6. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#管理-flex-gateway-と接続モードのアウトバウンドポリシーを並び替える)管理 Flex Gateway と接続モードのアウトバウンドポリシーを並び替える アウトバウンドポリシーを並び替える手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを並び替える API インスタンスの名前をクリックします。 3. サイドナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[Outbound policies (アウトバウンドポリシー)\]**​ タブをクリックします。 5. ポリシーを並び替えるアップストリームサービスのその他のオプションボタン (​![1%](/mulesoft/current/ja-jp/gateway/1.9/_images/more-options-menu.png)​)。 6. 上矢印と下矢印を使用して、ポリシーの順序を再編成します。 7. **\[Apply order (順序を適用)\]**​ をクリックします。 ## [](#ローカルモードでのポリシーの並び替え)ローカルモードでのポリシーの並び替え ローカルモードで実行されている Flex Gateway では、​`PolicyBinding`​ YAML リソースを介してポリシーの順序を設定します。 `PolicyBinding`​ YAML リソースを使用してポリシーを定義する場合、ポリシーを実行するタイミングに一致するように ​`order`​ パラメーターを編集します。同じ順序番号を別のポリシーに割り当てないでください。 ローカルモードのポリシー順序については、​[「宣言型設定リファレンスガイド」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide#policy-binding)​を参照してください。 ## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) # ポリシーを使用した Flex Gateway API の保護 ポリシーは、Flex Gateway が要求を処理するときにルールを適用し、Flex Gateway API を保護および管理できるようにします。 MuleSoft では、Anypoint Platform または宣言型設定ファイルを介して API に適用できるポリシーが提供されます。提供されるポリシーには、レート制限、キャッシュ、認証、承認、脅威保護、監視、ログ記録が含まれます。MuleSoft によって提供されるポリシーについての詳細は、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) and [アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-outbound-directory)​を参照してください。 既存の機能を拡張したり、新しい機能を定義したりするには、特定のビジネス要件に基づいてカスタムポリシーを作成し、それらを API に適用します。カスタムポリシーの作成については、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を参照してください。 自動ポリシーでは、同じポリシーのセットが Flex Gateway で実行されるすべての API に適用されるため、API インスタンスを共通のセキュリティ要件とロギング要件に準拠させることができます。詳細は、[自動ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-automated-overview)を参照してください。 管理 Flex Gateway または接続モードでポリシーを適用するには、[管理 Flex Gateway と接続モードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-secure-conn)を参照してください。 ローカルモードでポリシーを適用するには、[ローカルモードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-secure-local)を参照してください。 ポリシーの並び替えにいついての詳細は、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.10/policies-reorder)を参照してください。 DataWeave サポートについての詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started-overview) # ポリシーを使用した Flex Gateway API の保護 ポリシーは、Flex Gateway が要求を処理するときにルールを適用し、Flex Gateway API を保護および管理できるようにします。 MuleSoft では、Anypoint Platform または宣言型設定ファイルを介して API に適用できるポリシーが提供されます。提供されるポリシーには、レート制限、キャッシュ、認証、承認、脅威保護、監視、ログ記録が含まれます。MuleSoft によって提供されるポリシーについての詳細は、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) and [アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-outbound-directory)​を参照してください。 既存の機能を拡張したり、新しい機能を定義したりするには、特定のビジネス要件に基づいてカスタムポリシーを作成し、それらを API に適用します。カスタムポリシーの作成については、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を参照してください。 自動ポリシーでは、同じポリシーのセットが Flex Gateway で実行されるすべての API に適用されるため、API インスタンスを共通のセキュリティ要件とロギング要件に準拠させることができます。詳細は、[自動ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-automated-overview)を参照してください。 管理 Flex Gateway または接続モードでポリシーを適用するには、[管理 Flex Gateway と接続モードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-secure-conn)を参照してください。 ローカルモードでポリシーを適用するには、[ローカルモードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-secure-local)を参照してください。 ポリシーの並び替えにいついての詳細は、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.9/policies-reorder)を参照してください。 DataWeave サポートについての詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started-overview) # メッセージログポリシー

ポリシー名

メッセージログ

概要

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

カテゴリ

トラブルシューティング

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 メッセージログポリシーは、受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録します。 ## [](#前提条件)前提条件 Anypoint Platform 組織のシステム管理者ロールか、API を作成または管理するための権限が必要です。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: message-logging-flex config: loggingConfiguration: - itemName: // REQUIRED itemData: //REQUIRED message: // REQUIRED conditional: // OPTIONAL category: // OPTIONAL level: // REQUIRED firstSection: // OPTIONAL secondSection: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

loggingConfiguration

必須

なし

設定の配列

loggingConfiguration.itemName

必須

なし

設定名。

loggingConfiguration.itemData.message

必須

なし

メッセージログに解決される DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

loggingConfiguration.itemData.conditional

省略可能

true

メッセージをログに記録するかどうかに解決される DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

loggingConfiguration.itemData.category

省略可能

デフォルトカテゴリ

ログが実行されたパッケージとクラスを示すログメッセージプレフィックス。

loggingConfiguration.itemData.level

必須

なし

記録するメッセージのレベル (​INFO (情報)​、​WARN (警告)​、​ERROR​ (エラー)、​DEBUG (デバッグ)​) を定義します。
詳細は、​メッセージログの重要度レベル​を参照してください。

loggingConfiguration.itemData.firstSection

省略可能

false

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージが記録されるかどうかを示す Boolean (ブール)。

loggingConfiguration.itemData.secondSection

省略可能

false

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するかどうかを示す Boolean (ブール)。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: message-logging-flex config: loggingConfiguration: - itemName: "Config 1" itemData: message: "#\[payload\]" conditional: "#\[attributes.queryParams\['QueryParam'\]=='someValue'\]" level: "ERROR" firstSection: true - itemName: "Config 2" itemData: message: "#\['literal string'\]" level: "WARN" secondSection: true firstSection: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。 ![新しいログ設定を定義するためのテキスト項目とチェックボックスが含まれるフォーム](/mulesoft/current/ja-jp/gateway/1.10/_images/apim-message-logging-policy-ui.png)
パラメーター 説明 必須

Message (メッセージ)

ログに記録するメッセージを抽出する DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

必須

Conditional (条件付き)

メッセージをログに記録するかどうかを指定する DataWeave ブール式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

省略可能

Category (カテゴリ)

ログが実行されたパッケージとクラスを示すログメッセージのプレフィックス。

省略可能

Level (レベル)

記録するメッセージのレベル (INFO (情報)、WARN (警告)、ERROR (エラー)、DEBUG (デバッグ))。
詳細は、​メッセージログの重要度レベル​を参照してください。

必須

Before Calling API (API のコール前)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージを記録するようにログポリシーを設定します。

省略可能

After Calling API (API のコール後)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するようにログポリシーを設定します。

省略可能
#### [](#ui-から設定するメッセージログポリシーの例)UI から設定するメッセージログポリシーの例 メッセージログポリシーの使用方法をよく理解できるように、Les Vetments という架空の洋品小売業者を考えてみましょう。E コマースポータルを正常に運営するため、Les Vetments は Web サイト上で実行された要求の状況コードを監査する必要があります。 たとえば、顧客が商品を購入または返品したり、会社がカタログの商品を追加または削除したりした場合には、トランザクションを記録する必要があります。Les Vetments の IT マネージャーは、会社の API にメッセージログポリシーを適用して、コードを変更することなくあらゆるデータやトランザクションの変更を記録して表示できるようにします。 受信および送信 HTTP メッセージの属性を記録するため、Les Vetments では、次の UI 設定でメッセージログポリシーを API に適用します。 - **Message (メッセージ)**​: #\[属性\] ペイロード中の属性を記録する必要があります。 - **Conditional (条件)**​: 空白 Les Vetments ではすべての属性を必要とするため、メッセージを絞り込むための式は指定しません。 - **Category (カテゴリ)**​: 空白 ログ文ではプレフィックスは不要です。 - **Level (レベル)**​: Info (情報) すべての種別のメッセージを記録します。Info (情報) ログレベルには、Warn (警告)、Error (エラー)、Debug (デバッグ) ログメッセージも含まれます。 - **Before Calling API (API のコール前)**​: オン API のコール前に発生したすべてのトランザクションが記録されます。 - **After Calling API (API のコール後)**​: オン API のコール後に発生したすべてのトランザクションが記録されます。 この設定後は、顧客が Les Vetments のカタログにアクセスしたり、カートの商品を追加または削除したり、Les Vetments のカタログの商品が追加または削除されたりするたびに、ログが生成されます。 ```text ********************************************************************** * Policy: message-logging-1351146-proxy * * OS encoding: UTF-8, Mule encoding: UTF-8 * * * ********************************************************************** 21:56:50.147 11/30/2020 Worker-0 [MuleRuntime].uber.06: [message-logging-771181-proxy].771181-message-logging.CPU_LITE @71625864 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpRequestAttributes { Request path=/proxy/1 Raw request path=/proxy/1 Method=GET Listener path=/proxy/* Local Address=/172.25.159.101:8081 Query String= Relative Path=/proxy/1 Masked Request Path=/1 Remote Address=/18.191.37.179:21836 Request Uri=/proxy/1 Raw request Uri=/proxy/1 Scheme=http Version=HTTP/1.1 Headers=[ host=logging-policy.us-e2.cloudhub.io x-real-ip=204.14.236.154 accept=*/* user-agent=curl/7.54.0 x-forwarded-for=204.14.236.154 x-forwarded-port=80 x-forwarded-proto=http x-sigsci-agentresponse=200 x-sigsci-mac=7caf3820a5c07d06ef827f1565678167 ] Query Parameters=[] URI Parameters=[] } 21:56:50.254 11/30/2020 Worker-0 [MuleRuntime].uber.07: [logging-policy].proxy.CPU_LITE @f0ce617 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpResponseAttributes { Status Code=200 Reason Phrase=OK Headers=[ date=Tue, 01 Dec 2020 00:56:50 GMT content-type=application/json; charset=utf-8 set-cookie=__cfduid=d8afa23a4627ebef39cbc54fea223cb231606784210; expires=Thu, 31-Dec-20 00:56:50 GMT; path=/; domain=.typicode.com; HttpOnly; SameSite=Lax x-powered-by=Express x-ratelimit-limit=1000 x-ratelimit-remaining=999 x-ratelimit-reset=1606784265 vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=max-age=43200 pragma=no-cache expires=-1 x-content-type-options=nosniff etag=W/"53-hfEnumeNh6YirfjyjaujcOPPT+s" via=1.1 vegur cf-cache-status=MISS accept-ranges=bytes cf-request-id=06bd666d0a0000386b7a1fc000000001 expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to={"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=qUAIXoQ7qqqvFzjcwGrmK2r2PcSfDZ75jFJd0Gi0BLBUMHAcnC9wJ9I%2FEHJtk%2Bra%2FXWqkA%2F5%2FlzoWoC6YS2Lew%2BqKgjhaphHqx5WrZ0CKHMalhcM9it%2Fks0qzQGwbsRzQg%3D%3D"}],"group":"cf-nel","max_age":604800} nel={"report_to":"cf-nel","max_age":604800} cf-ray=5fa8d9c1a8c6386b-IAD ] } 12:18:31.770 11/18/2020 Worker-0 agw-policy-set-deployment.01 INFO Applied policy message-logging-1351146 version 1.0.0 to API testLoggingNew-v1-v1:16481163 (16481163) in application messagelog ``` ヘッダーを記録するため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#[attributes.headers]` イベントや実行したアクションに基づいてログメッセージをカスタマイズするため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#['User ' authentication.clientId ' performed action ' attributes.method ' on ' attributes.requestPath ' with Payload: ' ++ payload]` ## [](#dataweave-support)DataWeave 式のサポート メッセージログポリシーでは、​[Flex Gateway でサポートされる標準の DataWeave 式](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support)​と次に挙げた追加の ​[`vars`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ DataWeave 式がサポートされています。以下の式の形式は ​`[vars.]`​ (例: `[vars.orgId]`​) となります。 - `orgId` - `masterOrgId` - `envId` - `apiId` - `apiName` - `apiInstanceName` - `apiVersion` - `receivedTs`​ (rfc3339) - `repliedTs`​ (rfc3339、要求コンテキストでのみ使用可能) - `runtimeVersion`​ (例: `v1.7.0`​) - `hostId`​ (例: `my-host`​) - `reqId`​ (Flex Gateway ログでは ​`traceId`​) - `requestDisposition`​ (​`PROCESSED`​ または ​`VIOLATION`​、要求コンテキストでのみ使用可能) - `request.remoteAddress` - `request.method` - `request.requestPath` - `request.headers`​ (すべてのリクエストヘッダー) - `violation.clientId`​ (応答コンテキストでのみ使用可能) - `violation.clientName`​ (応答コンテキストでのみ使用可能) - `violation.policyName`​ (応答コンテキストでのみ使用可能) - `violation.violationType`​ (​`VIOLATION`​ または ​`ERROR`​、応答コンテキストでのみ使用可能) ## [](#ポリシーのしくみ)ポリシーのしくみ ポリシーのログ記録は次の順序で実行されます。 1. 要求が API に送信されます。 2. 次の条件を満たす場合は、メッセージがログに記録されます。 - ポリシーに定義されているログのレベルとカテゴリが、設定ファイルに定義されたロガーに含まれている。 - ポリシーの \[Conditional (条件付き)\] 項目が設定されていないか、または設定されている条件が満たされた。 3. API 応答が返されます。メッセージログポリシーは、ポリシーやフローの実行に干渉しません。 4. メッセージがアプリケーションログに表示されます。 ## [](#ログ形式について)ログ形式について メッセージログの形式は次のとおりです。 ` [flex-gateway-envoy][] wasm log .default..default.svc main: [req: ] [accessLog] ` - `policy-name`​: ポリシーバインドの名前を表示します。 - `api-name`​: API インスタンスの名前を表示します。 - `request uuid`​: メッセージをトリガーした要求の一意の識別子を表示します。 ## [](#イベント中の状態の記録)イベント中の状態の記録 メッセージのログは、要求フロー中に特定の間隔で発生します。 - API フローをログに記録する前: ![API フローをログに記録する前の状態](/mulesoft/current/ja-jp/gateway/1.10/_images/apim-message-logging-policy-states-1.png) - API フローをログに記録した後: ![API フローをログに記録した後の状態](/mulesoft/current/ja-jp/gateway/1.10/_images/apim-message-logging-policy-states-2.png) - API フローの後のエラーハンドラー: ![エラーハンドラー実行後の状態](/mulesoft/current/ja-jp/gateway/1.10/_images/apim-message-logging-policy-states-3.png) ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# メッセージログポリシー

ポリシー名

メッセージログ

概要

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

カテゴリ

トラブルシューティング

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 メッセージログポリシーは、受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録します。 ## [](#前提条件)前提条件 Anypoint Platform 組織のシステム管理者ロールか、API を作成または管理するための権限が必要です。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してメッセージログポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: message-logging-flex config: loggingConfiguration: - itemName: // REQUIRED itemData: //REQUIRED message: // REQUIRED conditional: // OPTIONAL category: // OPTIONAL level: // REQUIRED firstSection: // OPTIONAL secondSection: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

loggingConfiguration

必須

なし

設定の配列

loggingConfiguration.itemName

必須

なし

設定名。

loggingConfiguration.itemData.message

必須

なし

メッセージログに解決される DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

loggingConfiguration.itemData.conditional

省略可能

true

メッセージをログに記録するかどうかに解決される DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

loggingConfiguration.itemData.category

省略可能

デフォルトカテゴリ

ログが実行されたパッケージとクラスを示すログメッセージプレフィックス。

loggingConfiguration.itemData.level

必須

なし

記録するメッセージのレベル (​INFO (情報)​、​WARN (警告)​、​ERROR​ (エラー)、​DEBUG (デバッグ)​) を定義します。
詳細は、​メッセージログの重要度レベル​を参照してください。

loggingConfiguration.itemData.firstSection

省略可能

false

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージが記録されるかどうかを示す Boolean (ブール)。

loggingConfiguration.itemData.secondSection

省略可能

false

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するかどうかを示す Boolean (ブール)。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: message-logging-flex config: loggingConfiguration: - itemName: "Config 1" itemData: message: "#\[payload\]" conditional: "#\[attributes.queryParams\['QueryParam'\]=='someValue'\]" level: "ERROR" firstSection: true - itemName: "Config 2" itemData: message: "#\['literal string'\]" level: "WARN" secondSection: true firstSection: true ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI を使用してメッセージログポリシーを API に適用する場合は、以下のパラメーターを設定できます。 ![メッセージログポリシー UI](/mulesoft/current/ja-jp/gateway/1.8/_images/apim-message-logging-policy-ui.png)
パラメーター 説明 必須?

Message (メッセージ)

ログに記録するメッセージを抽出する DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

必須

Conditional (条件付き)

メッセージをログに記録するかどうかを指定する DataWeave ブール式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

省略可能

Category (カテゴリ)

ログが実行されたパッケージとクラスを示すログメッセージのプレフィックス。

省略可能

Level (レベル)

記録するメッセージのレベル (INFO (情報)、WARN (警告)、ERROR (エラー)、DEBUG (デバッグ))。
詳細は、​メッセージログの重要度レベル​を参照してください。

必須

Before Calling API (API のコール前)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージを記録するようにログポリシーを設定します。

省略可能

After Calling API (API のコール後)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するようにログポリシーを設定します。

省略可能
#### [](#ui-から設定するメッセージログポリシーの例)UI から設定するメッセージログポリシーの例 メッセージログポリシーの使用方法をよく理解できるように、Les Vetments という架空の洋品小売業者を考えてみましょう。E コマースポータルを正常に運営するため、Les Vetments は Web サイト上で実行された要求の状況コードを監査する必要があります。 たとえば、顧客が商品を購入または返品したり、会社がカタログの商品を追加または削除したりした場合には、トランザクションを記録する必要があります。Les Vetments の IT マネージャーは、会社の API にメッセージログポリシーを適用して、コードを変更することなくあらゆるデータやトランザクションの変更を記録して表示できるようにします。 受信および送信 HTTP メッセージの属性を記録するため、Les Vetments では、次の UI 設定でメッセージログポリシーを API に適用します。 - **Message (メッセージ)**​: #\[属性\] ペイロード中の属性を記録する必要があります。 - **Conditional (条件)**​: 空白 Les Vetments ではすべての属性を必要とするため、メッセージを絞り込むための式は指定しません。 - **Category (カテゴリ)**​: 空白 ログ文ではプレフィックスは不要です。 - **Level (レベル)**​: Info (情報) すべての種別のメッセージを記録します。Info (情報) ログレベルには、Warn (警告)、Error (エラー)、Debug (デバッグ) ログメッセージも含まれます。 - **Before Calling API (API のコール前)**​: オン API のコール前に発生したすべてのトランザクションが記録されます。 - **After Calling API (API のコール後)**​: オン API のコール後に発生したすべてのトランザクションが記録されます。 この設定後は、顧客が Les Vetments のカタログにアクセスしたり、カートの商品を追加または削除したり、Les Vetments のカタログの商品が追加または削除されたりするたびに、ログが生成されます。 ```text ********************************************************************** * Policy: message-logging-1351146-proxy * * OS encoding: UTF-8, Mule encoding: UTF-8 * * * ********************************************************************** 21:56:50.147 11/30/2020 Worker-0 [MuleRuntime].uber.06: [message-logging-771181-proxy].771181-message-logging.CPU_LITE @71625864 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpRequestAttributes { Request path=/proxy/1 Raw request path=/proxy/1 Method=GET Listener path=/proxy/* Local Address=/172.25.159.101:8081 Query String= Relative Path=/proxy/1 Masked Request Path=/1 Remote Address=/18.191.37.179:21836 Request Uri=/proxy/1 Raw request Uri=/proxy/1 Scheme=http Version=HTTP/1.1 Headers=[ host=logging-policy.us-e2.cloudhub.io x-real-ip=204.14.236.154 accept=*/* user-agent=curl/7.54.0 x-forwarded-for=204.14.236.154 x-forwarded-port=80 x-forwarded-proto=http x-sigsci-agentresponse=200 x-sigsci-mac=7caf3820a5c07d06ef827f1565678167 ] Query Parameters=[] URI Parameters=[] } 21:56:50.254 11/30/2020 Worker-0 [MuleRuntime].uber.07: [logging-policy].proxy.CPU_LITE @f0ce617 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpResponseAttributes { Status Code=200 Reason Phrase=OK Headers=[ date=Tue, 01 Dec 2020 00:56:50 GMT content-type=application/json; charset=utf-8 set-cookie=__cfduid=d8afa23a4627ebef39cbc54fea223cb231606784210; expires=Thu, 31-Dec-20 00:56:50 GMT; path=/; domain=.typicode.com; HttpOnly; SameSite=Lax x-powered-by=Express x-ratelimit-limit=1000 x-ratelimit-remaining=999 x-ratelimit-reset=1606784265 vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=max-age=43200 pragma=no-cache expires=-1 x-content-type-options=nosniff etag=W/"53-hfEnumeNh6YirfjyjaujcOPPT+s" via=1.1 vegur cf-cache-status=MISS accept-ranges=bytes cf-request-id=06bd666d0a0000386b7a1fc000000001 expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to={"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=qUAIXoQ7qqqvFzjcwGrmK2r2PcSfDZ75jFJd0Gi0BLBUMHAcnC9wJ9I%2FEHJtk%2Bra%2FXWqkA%2F5%2FlzoWoC6YS2Lew%2BqKgjhaphHqx5WrZ0CKHMalhcM9it%2Fks0qzQGwbsRzQg%3D%3D"}],"group":"cf-nel","max_age":604800} nel={"report_to":"cf-nel","max_age":604800} cf-ray=5fa8d9c1a8c6386b-IAD ] } 12:18:31.770 11/18/2020 Worker-0 agw-policy-set-deployment.01 INFO Applied policy message-logging-1351146 version 1.0.0 to API testLoggingNew-v1-v1:16481163 (16481163) in application messagelog ``` ヘッダーを記録するため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#[attributes.headers]` イベントや実行したアクションに基づいてログメッセージをカスタマイズするため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#['User ' authentication.clientId ' performed action ' attributes.method ' on ' attributes.requestPath ' with Payload: ' ++ payload]` ## [](#dataweave-support)DataWeave 式のサポート メッセージログポリシーでは、​[Flex Gateway でサポートされる標準の DataWeave 式](https://docs.mulesoft.com/jp/gateway/1.8/policies-flex-dataweave-support)​と次に挙げた追加の ​[`vars`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ DataWeave 式がサポートされています。以下の式の形式は ​`[vars.]`​ (例: `[vars.orgId]`​) となります。 - `orgId` - `masterOrgId` - `envId` - `apiId` - `apiName` - `apiInstanceName` - `apiVersion` - `receivedTs`​ (rfc3339) - `repliedTs`​ (rfc3339、要求コンテキストでのみ使用可能) - `runtimeVersion`​ (例: `v1.7.0`​) - `hostId`​ (例: `my-host`​) - `reqId`​ (Flex Gateway ログでは ​`traceId`​) - `requestDisposition`​ (​`PROCESSED`​ または ​`VIOLATION`​、要求コンテキストでのみ使用可能) - `request.remoteAddress` - `request.method` - `request.requestPath` - `request.headers`​ (すべてのリクエストヘッダー) - `violation.clientId`​ (応答コンテキストでのみ使用可能) - `violation.clientName`​ (応答コンテキストでのみ使用可能) - `violation.policyName`​ (応答コンテキストでのみ使用可能) - `violation.violationType`​ (​`VIOLATION`​ または ​`ERROR`​、応答コンテキストでのみ使用可能) ## [](#ポリシーのしくみ)ポリシーのしくみ ポリシーのログ記録は次の順序で実行されます。 1. 要求が API に送信されます。 2. 次の条件を満たす場合は、メッセージがログに記録されます。 - ポリシーに定義されているログのレベルとカテゴリが、設定ファイルに定義されたロガーに含まれている。 - ポリシーの \[Conditional (条件付き)\] 項目が設定されていないか、または設定されている条件が満たされた。 3. API 応答が返されます。メッセージログポリシーは、ポリシーやフローの実行に干渉しません。 4. メッセージがアプリケーションログに表示されます。 ## [](#ログ形式について)ログ形式について メッセージログの形式は次のとおりです。 ` [flex-gateway-envoy][] wasm log .default..default.svc main: [req: ] [accessLog] ` - `policy-name`​: ポリシーバインドの名前を表示します。 - `api-name`​: API インスタンスの名前を表示します。 - `request uuid`​: メッセージをトリガーした要求の一意の識別子を表示します。 ## [](#イベント中の状態の記録)イベント中の状態の記録 メッセージのログは、要求フロー中に特定の間隔で発生します。 - API フローをログに記録する前: ![API フローをログに記録する前の状態](/mulesoft/current/ja-jp/gateway/1.8/_images/apim-message-logging-policy-states-1.png) - API フローをログに記録した後: ![API フローをログに記録した後の状態](/mulesoft/current/ja-jp/gateway/1.8/_images/apim-message-logging-policy-states-2.png) - API フローの後のエラーハンドラー: ![エラーハンドラー実行後の状態](/mulesoft/current/ja-jp/gateway/1.8/_images/apim-message-logging-policy-states-3.png) ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# メッセージログポリシー

ポリシー名

メッセージログ

概要

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

カテゴリ

トラブルシューティング

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません
## [](#概要)概要 メッセージログポリシーは、受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録します。 ## [](#前提条件)前提条件 Anypoint Platform 組織のシステム管理者ロールか、API を作成または管理するための権限が必要です。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: message-logging-flex config: loggingConfiguration: - itemName: // REQUIRED itemData: //REQUIRED message: // REQUIRED conditional: // OPTIONAL category: // OPTIONAL level: // REQUIRED firstSection: // OPTIONAL secondSection: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

loggingConfiguration

必須

なし

設定の配列

loggingConfiguration.itemName

必須

なし

設定名。

loggingConfiguration.itemData.message

必須

なし

メッセージログに解決される DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

loggingConfiguration.itemData.conditional

省略可能

true

メッセージをログに記録するかどうかに解決される DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

loggingConfiguration.itemData.category

省略可能

デフォルトカテゴリ

ログが実行されたパッケージとクラスを示すログメッセージプレフィックス。

loggingConfiguration.itemData.level

必須

なし

記録するメッセージのレベル (​INFO (情報)​、​WARN (警告)​、​ERROR​ (エラー)、​DEBUG (デバッグ)​) を定義します。
詳細は、​メッセージログの重要度レベル​を参照してください。

loggingConfiguration.itemData.firstSection

省略可能

false

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージが記録されるかどうかを示す Boolean (ブール)。

loggingConfiguration.itemData.secondSection

省略可能

false

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するかどうかを示す Boolean (ブール)。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: message-logging-flex config: loggingConfiguration: - itemName: "Config 1" itemData: message: "#\[payload\]" conditional: "#\[attributes.queryParams\['QueryParam'\]=='someValue'\]" level: "ERROR" firstSection: true - itemName: "Config 2" itemData: message: "#\['literal string'\]" level: "WARN" secondSection: true firstSection: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。 ![新しいログ設定を定義するためのテキスト項目とチェックボックスが含まれるフォーム](/mulesoft/current/ja-jp/gateway/1.9/_images/apim-message-logging-policy-ui.png)
パラメーター 説明 必須

Message (メッセージ)

ログに記録するメッセージを抽出する DataWeave 式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

必須

Conditional (条件付き)

メッセージをログに記録するかどうかを指定する DataWeave ブール式。サポートされる DataWeave 式についての詳細は、​DataWeave 式のサポート​を参照してください。

省略可能

Category (カテゴリ)

ログが実行されたパッケージとクラスを示すログメッセージのプレフィックス。

省略可能

Level (レベル)

記録するメッセージのレベル (INFO (情報)、WARN (警告)、ERROR (エラー)、DEBUG (デバッグ))。
詳細は、​メッセージログの重要度レベル​を参照してください。

必須

Before Calling API (API のコール前)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされる前にメッセージを記録するようにログポリシーを設定します。

省略可能

After Calling API (API のコール後)

このポリシーが適用される順序を考慮して、API エンドポイントがコールされた後にメッセージを記録するようにログポリシーを設定します。

省略可能
#### [](#ui-から設定するメッセージログポリシーの例)UI から設定するメッセージログポリシーの例 メッセージログポリシーの使用方法をよく理解できるように、Les Vetments という架空の洋品小売業者を考えてみましょう。E コマースポータルを正常に運営するため、Les Vetments は Web サイト上で実行された要求の状況コードを監査する必要があります。 たとえば、顧客が商品を購入または返品したり、会社がカタログの商品を追加または削除したりした場合には、トランザクションを記録する必要があります。Les Vetments の IT マネージャーは、会社の API にメッセージログポリシーを適用して、コードを変更することなくあらゆるデータやトランザクションの変更を記録して表示できるようにします。 受信および送信 HTTP メッセージの属性を記録するため、Les Vetments では、次の UI 設定でメッセージログポリシーを API に適用します。 - **Message (メッセージ)**​: #\[属性\] ペイロード中の属性を記録する必要があります。 - **Conditional (条件)**​: 空白 Les Vetments ではすべての属性を必要とするため、メッセージを絞り込むための式は指定しません。 - **Category (カテゴリ)**​: 空白 ログ文ではプレフィックスは不要です。 - **Level (レベル)**​: Info (情報) すべての種別のメッセージを記録します。Info (情報) ログレベルには、Warn (警告)、Error (エラー)、Debug (デバッグ) ログメッセージも含まれます。 - **Before Calling API (API のコール前)**​: オン API のコール前に発生したすべてのトランザクションが記録されます。 - **After Calling API (API のコール後)**​: オン API のコール後に発生したすべてのトランザクションが記録されます。 この設定後は、顧客が Les Vetments のカタログにアクセスしたり、カートの商品を追加または削除したり、Les Vetments のカタログの商品が追加または削除されたりするたびに、ログが生成されます。 ```text ********************************************************************** * Policy: message-logging-1351146-proxy * * OS encoding: UTF-8, Mule encoding: UTF-8 * * * ********************************************************************** 21:56:50.147 11/30/2020 Worker-0 [MuleRuntime].uber.06: [message-logging-771181-proxy].771181-message-logging.CPU_LITE @71625864 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpRequestAttributes { Request path=/proxy/1 Raw request path=/proxy/1 Method=GET Listener path=/proxy/* Local Address=/172.25.159.101:8081 Query String= Relative Path=/proxy/1 Masked Request Path=/1 Remote Address=/18.191.37.179:21836 Request Uri=/proxy/1 Raw request Uri=/proxy/1 Scheme=http Version=HTTP/1.1 Headers=[ host=logging-policy.us-e2.cloudhub.io x-real-ip=204.14.236.154 accept=*/* user-agent=curl/7.54.0 x-forwarded-for=204.14.236.154 x-forwarded-port=80 x-forwarded-proto=http x-sigsci-agentresponse=200 x-sigsci-mac=7caf3820a5c07d06ef827f1565678167 ] Query Parameters=[] URI Parameters=[] } 21:56:50.254 11/30/2020 Worker-0 [MuleRuntime].uber.07: [logging-policy].proxy.CPU_LITE @f0ce617 INFO event:184152a0-3370-11eb-b732-0a8c1820c088 org.mule.extension.http.api.HttpResponseAttributes { Status Code=200 Reason Phrase=OK Headers=[ date=Tue, 01 Dec 2020 00:56:50 GMT content-type=application/json; charset=utf-8 set-cookie=__cfduid=d8afa23a4627ebef39cbc54fea223cb231606784210; expires=Thu, 31-Dec-20 00:56:50 GMT; path=/; domain=.typicode.com; HttpOnly; SameSite=Lax x-powered-by=Express x-ratelimit-limit=1000 x-ratelimit-remaining=999 x-ratelimit-reset=1606784265 vary=Origin, Accept-Encoding access-control-allow-credentials=true cache-control=max-age=43200 pragma=no-cache expires=-1 x-content-type-options=nosniff etag=W/"53-hfEnumeNh6YirfjyjaujcOPPT+s" via=1.1 vegur cf-cache-status=MISS accept-ranges=bytes cf-request-id=06bd666d0a0000386b7a1fc000000001 expect-ct=max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to={"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=qUAIXoQ7qqqvFzjcwGrmK2r2PcSfDZ75jFJd0Gi0BLBUMHAcnC9wJ9I%2FEHJtk%2Bra%2FXWqkA%2F5%2FlzoWoC6YS2Lew%2BqKgjhaphHqx5WrZ0CKHMalhcM9it%2Fks0qzQGwbsRzQg%3D%3D"}],"group":"cf-nel","max_age":604800} nel={"report_to":"cf-nel","max_age":604800} cf-ray=5fa8d9c1a8c6386b-IAD ] } 12:18:31.770 11/18/2020 Worker-0 agw-policy-set-deployment.01 INFO Applied policy message-logging-1351146 version 1.0.0 to API testLoggingNew-v1-v1:16481163 (16481163) in application messagelog ``` ヘッダーを記録するため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#[attributes.headers]` イベントや実行したアクションに基づいてログメッセージをカスタマイズするため、Les Vetments では ​**\[Message (メッセージ)\]**​ 項目で次のコードスニペットを使用します。 `#['User ' authentication.clientId ' performed action ' attributes.method ' on ' attributes.requestPath ' with Payload: ' ++ payload]` ## [](#dataweave-support)DataWeave 式のサポート メッセージログポリシーでは、​[Flex Gateway でサポートされる標準の DataWeave 式](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support)​と次に挙げた追加の ​[`vars`](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context)​ DataWeave 式がサポートされています。以下の式の形式は ​`[vars.]`​ (例: `[vars.orgId]`​) となります。 - `orgId` - `masterOrgId` - `envId` - `apiId` - `apiName` - `apiInstanceName` - `apiVersion` - `receivedTs`​ (rfc3339) - `repliedTs`​ (rfc3339、要求コンテキストでのみ使用可能) - `runtimeVersion`​ (例: `v1.7.0`​) - `hostId`​ (例: `my-host`​) - `reqId`​ (Flex Gateway ログでは ​`traceId`​) - `requestDisposition`​ (​`PROCESSED`​ または ​`VIOLATION`​、要求コンテキストでのみ使用可能) - `request.remoteAddress` - `request.method` - `request.requestPath` - `request.headers`​ (すべてのリクエストヘッダー) - `violation.clientId`​ (応答コンテキストでのみ使用可能) - `violation.clientName`​ (応答コンテキストでのみ使用可能) - `violation.policyName`​ (応答コンテキストでのみ使用可能) - `violation.violationType`​ (​`VIOLATION`​ または ​`ERROR`​、応答コンテキストでのみ使用可能) ## [](#ポリシーのしくみ)ポリシーのしくみ ポリシーのログ記録は次の順序で実行されます。 1. 要求が API に送信されます。 2. 次の条件を満たす場合は、メッセージがログに記録されます。 - ポリシーに定義されているログのレベルとカテゴリが、設定ファイルに定義されたロガーに含まれている。 - ポリシーの \[Conditional (条件付き)\] 項目が設定されていないか、または設定されている条件が満たされた。 3. API 応答が返されます。メッセージログポリシーは、ポリシーやフローの実行に干渉しません。 4. メッセージがアプリケーションログに表示されます。 ## [](#ログ形式について)ログ形式について メッセージログの形式は次のとおりです。 ` [flex-gateway-envoy][] wasm log .default..default.svc main: [req: ] [accessLog] ` - `policy-name`​: ポリシーバインドの名前を表示します。 - `api-name`​: API インスタンスの名前を表示します。 - `request uuid`​: メッセージをトリガーした要求の一意の識別子を表示します。 ## [](#イベント中の状態の記録)イベント中の状態の記録 メッセージのログは、要求フロー中に特定の間隔で発生します。 - API フローをログに記録する前: ![API フローをログに記録する前の状態](/mulesoft/current/ja-jp/gateway/1.9/_images/apim-message-logging-policy-states-1.png) - API フローをログに記録した後: ![API フローをログに記録した後の状態](/mulesoft/current/ja-jp/gateway/1.9/_images/apim-message-logging-policy-states-2.png) - API フローの後のエラーハンドラー: ![エラーハンドラー実行後の状態](/mulesoft/current/ja-jp/gateway/1.9/_images/apim-message-logging-policy-states-3.png) ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている ユースケース 1 では、信頼済み組織の API が信頼済み組織の API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。 ## [](#パターン-1-組織の内部-api-が組織の内部コンシューマーに公開されている)パターン 1: 組織の内部 API が組織の内部コンシューマーに公開されている パターンの例: - セールスアプリケーションがカスタマーサービス API にアクセスし、セールスサービスとカスタマーサービスの両方が顧客組織の内部領域である - コールセンターアプリケーションが顧客ドメインで公開された API をコールして顧客情報を取得する - モバイルバンクがカスタマーサービスやアカウントサービスをコールして、アカウントの概要画面をエンドコンシューマーに表示する ### [](#pattern-1a)パターン 1A: 組織の内部 API が同じ VPC またはネットワークを使用する組織の内部コンシューマーに公開されている このユースケースパターンでは、両方のサービスが同じインフラストラクチャ (同じ公開クラウド VPC、データセンター、Kubernetes クラスターなど) で使用できます。サイドカーゲートウェイまたはスタンドアロンゲートウェイとして Flex Gateway をデプロイできます。 ![スタンドアロンモードとサイドカーモードの両方で、Flex Gateway と API は同じ内部ネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-1a.png) 次の図は、接続モードで実行されているスタンドアロン Flex Gateway の物理的な実装を示しています。ネットワークポリシー (Netpol) では、Flex Gateway からのイングレスアクセスのみが許可されます。Flex Gateway およびプロバイダーサービスと同じ名前空間または異なる名前空間にコンシューマーアプリケーションを設定できます。 ![ロードバランサーと Netpol 保護が含まれている UC1 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-1a-physical.png) API プロバイダーが Flex Gateway およびコンシューマーアプリケーションとは異なる Kubernetes クラスターにある場合、次のいずれかを実行できます。 - パターン 1B のように各クラスターに Flex Gateway ランタイムをデプロイする。 - 次の図に示すように、クラスター間に安全なチャネルでネットワーク制限を確立し、Flex Gateway をそのいずれかのみにデプロイする。2 番目のクラスターでは、イングレスコントローラーとして機能する Flex Gateway からの接続のみを許可します。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 1A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-1b-separate-clusters.png) ### [](#pattern-1b)パターン 1B: 組織の内部 API が異なる VPC またはネットワークを使用する組織の内部コンシューマーに公開されている このパターンでは、API プロバイダーが API コンシューマーから分離されます。ただし、2 つのネットワーク間では安全な通信チャネルを使用できます。 トラフィックがプロバイダーの場所の外部とみなされるため、Flex Gateway をイングレスとしてファイアウォールの背後にデプロイします。Flex Gateway は、受信トラフィックを受信して処理します。 必要に応じて、Flex Gateway を使用して TLS または mTLS 接続を終了できます。 ![信頼済みネットワークから、Flex Gateway が含まれる内部ネットワークに情報が送信されます。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-1b.png) 次の図は、Kubernetes の物理的な実装を示しています。 ![前のネットワークは Kubernetes クラスターになり、Flex Gateway から API を分離するロードバランサーがあります。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-1b-physical.png) ## [](#pattern-2)パターン 2: 組織の内部 API が組織の外部コンシューマーに公開されている パターン 2 では、組織が所有している API が組織が所有している API コンシューマーと分離されます。たとえば、ユーザーインターフェースからアクセスするパッケージ配信追跡 API などがこれに該当します。コンシューマーは、インターネット経由でのみ公開 API にアクセスできます。このユースケースでは、Flex Gateway をイングレスとしてデプロイします。 ![コンシューマーアプリケーションの要求は、Flex Gateway に到達する前にインターネットとファイアウォールを通過します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-2.png) このパターンは、パターン 1B と似ています。ただし、このパターンでは、トラフィックが非公開チャネルではなく公開インターネットからきます。トラフィックが公開インターネットからくるので、通信セキュリティを強化するための制御を Flex Gateway に到達する前に追加する必要があります。 次の図は、Kubernetes で組織の内部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![前のネットワークは Kubernetes クラスターになり、Flex Gateway から API を分離するロードバランサーと、外部ネットワークへの mTLS 接続があります。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-2-physical.png) ## [](#pattern-3)パターン 3: 組織の外部 API が組織の内部コンシューマーに公開されている パターン 3 では、API コンシューマーが Flex Gateway と同じネットワークにあります。Flex Gateway を使用して、外部サービスへのフローを監視、制御、強化できます。たとえば、Flex Gateway では、外部アクセストラフィックのレート制限や、この外部サービス接続のメトリクスおよび分析の追跡を行うことができます。 パターンの例: - 支払サービスが外部サービスプロバイダーから換算レートを取得する必要がある。 - 内部 API コンシューマーが組織の外部 ServiceNow インスタンス (SaaS サービス) にアクセスする。 パターン 3 では、エグレスコンテナとして機能するスタンドアロンゲートウェイとして Flex Gateway をデプロイします。 ![Flex Gateway は、外部 API からの受信トラフィックを監視するエグレスとしてデプロイされます。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-3.png) 次の図は、Kubernetes で組織の外部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![前のネットワークは kubernetes クラスターになり、](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-3-physical.png) ## [](#pattern-4)パターン 4: 組織の外部 API が組織の外部コンシューマーに公開されている パターン 4 では、Flex Gateway が 2 つの組織の外部エンティティ間の仲介役として機能します。たとえば、組織の WorkDay インスタンス (SaaS サービス) が組織の ServiceNow インスタンス (SaaS サービス) にアクセスする場合などがこれに該当します。このパターンでは、安全な通信とポリシーを適用するイングレスおよびエグレスとして Flex Gateway が実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織の外部 API が組織の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが組織の外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 4 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-4-physical.png) ## [](#関連情報)関連情報 - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc4) # ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている ユースケース 1 では、信頼済み組織の API が信頼済み組織の API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。 ## [](#パターン-1-組織の内部-api-が組織の内部コンシューマーに公開されている)パターン 1: 組織の内部 API が組織の内部コンシューマーに公開されている パターンの例: - セールスアプリケーションがカスタマーサービス API にアクセスし、セールスサービスとカスタマーサービスの両方が顧客組織の内部領域である - コールセンターアプリケーションが顧客ドメインで公開された API をコールして顧客情報を取得する - モバイルバンクがカスタマーサービスやアカウントサービスをコールして、アカウントの概要画面をエンドコンシューマーに表示する ### [](#pattern-1a)パターン 1A: 組織の内部 API が同じ VPC またはネットワークを使用する組織の内部コンシューマーに公開されている このユースケースパターンでは、両方のサービスが同じインフラストラクチャ (同じ公開クラウド VPC、データセンター、Kubernetes クラスターなど) で使用できます。サイドカーゲートウェイまたはスタンドアロンゲートウェイとして Flex Gateway をデプロイできます。 ![スタンドアロンモードとサイドカーモードの両方で、Flex Gateway と API は同じ内部ネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-1a.png) 次の図は、接続モードで実行されているスタンドアロン Flex Gateway の物理的な実装を示しています。ネットワークポリシー (Netpol) では、Flex Gateway からのイングレスアクセスのみが許可されます。Flex Gateway およびプロバイダーサービスと同じ名前空間または異なる名前空間にコンシューマーアプリケーションを設定できます。 ![ロードバランサーと Netpol 保護が含まれている UC1 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-1a-physical.png) API プロバイダーが Flex Gateway およびコンシューマーアプリケーションとは異なる Kubernetes クラスターにある場合、次のいずれかを実行できます。 - パターン 1B のように各クラスターに Flex Gateway ランタイムをデプロイする。 - 次の図に示すように、クラスター間に安全なチャネルでネットワーク制限を確立し、Flex Gateway をそのいずれかのみにデプロイする。2 番目のクラスターでは、イングレスコントローラーとして機能する Flex Gateway からの接続のみを許可します。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 1A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-1b-separate-clusters.png) ### [](#pattern-1b)パターン 1B: 組織の内部 API が異なる VPC またはネットワークを使用する組織の内部コンシューマーに公開されている このパターンでは、API プロバイダーが API コンシューマーから分離されます。ただし、2 つのネットワーク間では安全な通信チャネルを使用できます。 トラフィックがプロバイダーの場所の外部とみなされるため、Flex Gateway をイングレスとしてファイアウォールの背後にデプロイします。Flex Gateway は、受信トラフィックを受信して処理します。 必要に応じて、Flex Gateway を使用して TLS または mTLS 接続を終了できます。 ![信頼済みネットワークから、Flex Gateway が含まれる内部ネットワークに情報が送信されます。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-1b.png) 次の図は、Kubernetes の物理的な実装を示しています。 ![前のネットワークは Kubernetes クラスターになり、Flex Gateway から API を分離するロードバランサーがあります。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-1b-physical.png) ## [](#pattern-2)パターン 2: 組織の内部 API が組織の外部コンシューマーに公開されている パターン 2 では、組織が所有している API が組織が所有している API コンシューマーと分離されます。たとえば、ユーザーインターフェースからアクセスするパッケージ配信追跡 API などがこれに該当します。コンシューマーは、インターネット経由でのみ公開 API にアクセスできます。このユースケースでは、Flex Gateway をイングレスとしてデプロイします。 ![コンシューマーアプリケーションの要求は、Flex Gateway に到達する前にインターネットとファイアウォールを通過します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-2.png) このパターンは、パターン 1B と似ています。ただし、このパターンでは、トラフィックが非公開チャネルではなく公開インターネットからきます。トラフィックが公開インターネットからくるので、通信セキュリティを強化するための制御を Flex Gateway に到達する前に追加する必要があります。 次の図は、Kubernetes で組織の内部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![前のネットワークは Kubernetes クラスターになり、Flex Gateway から API を分離するロードバランサーと、外部ネットワークへの mTLS 接続があります。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-2-physical.png) ## [](#pattern-3)パターン 3: 組織の外部 API が組織の内部コンシューマーに公開されている パターン 3 では、API コンシューマーが Flex Gateway と同じネットワークにあります。Flex Gateway を使用して、外部サービスへのフローを監視、制御、強化できます。たとえば、Flex Gateway では、外部アクセストラフィックのレート制限や、この外部サービス接続のメトリクスおよび分析の追跡を行うことができます。 パターンの例: - 支払サービスが外部サービスプロバイダーから換算レートを取得する必要がある。 - 内部 API コンシューマーが組織の外部 ServiceNow インスタンス (SaaS サービス) にアクセスする。 パターン 3 では、エグレスコンテナとして機能するスタンドアロンゲートウェイとして Flex Gateway をデプロイします。 ![Flex Gateway は、外部 API からの受信トラフィックを監視するエグレスとしてデプロイされます。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-3.png) 次の図は、Kubernetes で組織の外部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![前のネットワークは kubernetes クラスターになり、](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-3-physical.png) ## [](#pattern-4)パターン 4: 組織の外部 API が組織の外部コンシューマーに公開されている パターン 4 では、Flex Gateway が 2 つの組織の外部エンティティ間の仲介役として機能します。たとえば、組織の WorkDay インスタンス (SaaS サービス) が組織の ServiceNow インスタンス (SaaS サービス) にアクセスする場合などがこれに該当します。このパターンでは、安全な通信とポリシーを適用するイングレスおよびエグレスとして Flex Gateway が実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織の外部 API が組織の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが組織の外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 4 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-4-physical.png) ## [](#関連情報)関連情報 - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc4) # ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている ユースケース 1 では、信頼済み組織の API が信頼済み組織の API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。 ## [](#パターン-1-組織の内部-api-が組織の内部コンシューマーに公開されている)パターン 1: 組織の内部 API が組織の内部コンシューマーに公開されている パターンの例: - セールスアプリケーションがカスタマーサービス API にアクセスし、セールスサービスとカスタマーサービスの両方が顧客組織の内部領域である - コールセンターアプリケーションが顧客ドメインで公開された API をコールして顧客情報を取得する - モバイルバンクがカスタマーサービスやアカウントサービスをコールして、アカウントの概要画面をエンドコンシューマーに表示する ### [](#pattern-1a)パターン 1A: 組織の内部 API が同じ VPC またはネットワークを使用する組織の内部コンシューマーに公開されている このユースケースパターンでは、両方のサービスが同じインフラストラクチャ (同じ公開クラウド VPC、データセンター、Kubernetes クラスターなど) で使用できます。サイドカーゲートウェイまたはスタンドアロンゲートウェイとして Flex Gateway をデプロイできます。 ![スタンドアロンモードとサイドカーモードの両方で、Flex Gateway と API は同じ内部ネットワークにあります。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-1a.png) 次の図は、接続モードで実行されているスタンドアロン Flex Gateway の物理的な実装を示しています。ネットワークポリシー (Netpol) では、Flex Gateway からのイングレスアクセスのみが許可されます。Flex Gateway およびプロバイダーサービスと同じ名前空間または異なる名前空間にコンシューマーアプリケーションを設定できます。 ![ロードバランサーと Netpol 保護が含まれている UC1 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-1a-physical.png) API プロバイダーが Flex Gateway およびコンシューマーアプリケーションとは異なる Kubernetes クラスターにある場合、次のいずれかを実行できます。 - パターン 1B のように各クラスターに Flex Gateway ランタイムをデプロイする。 - 次の図に示すように、クラスター間に安全なチャネルでネットワーク制限を確立し、Flex Gateway をそのいずれかのみにデプロイする。2 番目のクラスターでは、イングレスコントローラーとして機能する Flex Gateway からの接続のみを許可します。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 1A の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-1b-separate-clusters.png) ### [](#pattern-1b)パターン 1B: 組織の内部 API が異なる VPC またはネットワークを使用する組織の内部コンシューマーに公開されている このパターンでは、API プロバイダーが API コンシューマーから分離されます。ただし、2 つのネットワーク間では安全な通信チャネルを使用できます。 トラフィックがプロバイダーの場所の外部とみなされるため、Flex Gateway をイングレスとしてファイアウォールの背後にデプロイします。Flex Gateway は、受信トラフィックを受信して処理します。 必要に応じて、Flex Gateway を使用して TLS または mTLS 接続を終了できます。 ![信頼済みネットワークから、Flex Gateway が含まれる内部ネットワークに情報が送信されます。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-1b.png) 次の図は、Kubernetes の物理的な実装を示しています。 ![前のネットワークは Kubernetes クラスターになり、Flex Gateway から API を分離するロードバランサーがあります。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-1b-physical.png) ## [](#pattern-2)パターン 2: 組織の内部 API が組織の外部コンシューマーに公開されている パターン 2 では、組織が所有している API が組織が所有している API コンシューマーと分離されます。たとえば、ユーザーインターフェースからアクセスするパッケージ配信追跡 API などがこれに該当します。コンシューマーは、インターネット経由でのみ公開 API にアクセスできます。このユースケースでは、Flex Gateway をイングレスとしてデプロイします。 ![コンシューマーアプリケーションの要求は、Flex Gateway に到達する前にインターネットとファイアウォールを通過します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-2.png) このパターンは、パターン 1B と似ています。ただし、このパターンでは、トラフィックが非公開チャネルではなく公開インターネットからきます。トラフィックが公開インターネットからくるので、通信セキュリティを強化するための制御を Flex Gateway に到達する前に追加する必要があります。 次の図は、Kubernetes で組織の内部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![前のネットワークは Kubernetes クラスターになり、Flex Gateway から API を分離するロードバランサーと、外部ネットワークへの mTLS 接続があります。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-2-physical.png) ## [](#pattern-3)パターン 3: 組織の外部 API が組織の内部コンシューマーに公開されている パターン 3 では、API コンシューマーが Flex Gateway と同じネットワークにあります。Flex Gateway を使用して、外部サービスへのフローを監視、制御、強化できます。たとえば、Flex Gateway では、外部アクセストラフィックのレート制限や、この外部サービス接続のメトリクスおよび分析の追跡を行うことができます。 パターンの例: - 支払サービスが外部サービスプロバイダーから換算レートを取得する必要がある。 - 内部 API コンシューマーが組織の外部 ServiceNow インスタンス (SaaS サービス) にアクセスする。 パターン 3 では、エグレスコンテナとして機能するスタンドアロンゲートウェイとして Flex Gateway をデプロイします。 ![Flex Gateway は、外部 API からの受信トラフィックを監視するエグレスとしてデプロイされます。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-3.png) 次の図は、Kubernetes で組織の外部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![前のネットワークは kubernetes クラスターになり、](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-3-physical.png) ## [](#pattern-4)パターン 4: 組織の外部 API が組織の外部コンシューマーに公開されている パターン 4 では、Flex Gateway が 2 つの組織の外部エンティティ間の仲介役として機能します。たとえば、組織の WorkDay インスタンス (SaaS サービス) が組織の ServiceNow インスタンス (SaaS サービス) にアクセスする場合などがこれに該当します。このパターンでは、安全な通信とポリシーを適用するイングレスおよびエグレスとして Flex Gateway が実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織の外部 API が組織の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが組織の外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 4 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-4-physical.png) ## [](#関連情報)関連情報 - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc4) # ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている ユースケース 2 では、組織が所有している API が組織以外が所有している API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。たとえば、ユーザーが公開 API に対して要求する場合などがこれに該当します。 ## [](#pattern-5)パターン 5: 組織の内部 API が組織以外の外部コンシューマーに公開されている パターン 5 では、組織が所有している API のインフラストラクチャが API コンシューマーから分離されます。コンシューマーは、インターネット経由でのみ公開 API にアクセスできます。このユースケースでは、Flex Gateway をイングレスとしてデプロイします。 ![コンシューマーアプリケーションの要求は、Flex Gateway に到達する前にインターネットとファイアウォールを通過します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-2.png) 次の図は、Kubernetes で組織が所有している内部 API が組織以外が所有している外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 5 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-2-p-5-physical.png) ## [](#pattern-6)パターン 6: 組織の外部 API が組織以外の外部コンシューマーに公開されている パターン 6 では、Flex Gateway が 2 つの外部ネットワークエンティティ間の仲介役として機能します。Flex Gateway は安全な通信とポリシーを適用するイングレスおよびエグレスとして実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織の外部 API が組織以外の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 6 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-2-p-6-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc1) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc4) # ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている ユースケース 2 では、組織が所有している API が組織以外が所有している API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。たとえば、ユーザーが公開 API に対して要求する場合などがこれに該当します。 ## [](#pattern-5)パターン 5: 組織の内部 API が組織以外の外部コンシューマーに公開されている パターン 5 では、組織が所有している API のインフラストラクチャが API コンシューマーから分離されます。コンシューマーは、インターネット経由でのみ公開 API にアクセスできます。このユースケースでは、Flex Gateway をイングレスとしてデプロイします。 ![コンシューマーアプリケーションの要求は、Flex Gateway に到達する前にインターネットとファイアウォールを通過します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-2.png) 次の図は、Kubernetes で組織が所有している内部 API が組織以外が所有している外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 5 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-2-p-5-physical.png) ## [](#pattern-6)パターン 6: 組織の外部 API が組織以外の外部コンシューマーに公開されている パターン 6 では、Flex Gateway が 2 つの外部ネットワークエンティティ間の仲介役として機能します。Flex Gateway は安全な通信とポリシーを適用するイングレスおよびエグレスとして実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織の外部 API が組織以外の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 6 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-2-p-6-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc1) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc4) # ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている ユースケース 2 では、組織が所有している API が組織以外が所有している API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。たとえば、ユーザーが公開 API に対して要求する場合などがこれに該当します。 ## [](#pattern-5)パターン 5: 組織の内部 API が組織以外の外部コンシューマーに公開されている パターン 5 では、組織が所有している API のインフラストラクチャが API コンシューマーから分離されます。コンシューマーは、インターネット経由でのみ公開 API にアクセスできます。このユースケースでは、Flex Gateway をイングレスとしてデプロイします。 ![コンシューマーアプリケーションの要求は、Flex Gateway に到達する前にインターネットとファイアウォールを通過します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-2.png) 次の図は、Kubernetes で組織が所有している内部 API が組織以外が所有している外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 5 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-2-p-5-physical.png) ## [](#pattern-6)パターン 6: 組織の外部 API が組織以外の外部コンシューマーに公開されている パターン 6 では、Flex Gateway が 2 つの外部ネットワークエンティティ間の仲介役として機能します。Flex Gateway は安全な通信とポリシーを適用するイングレスおよびエグレスとして実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織の外部 API が組織以外の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 6 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-2-p-6-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc1) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc3) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc4) # ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている ユースケース 3 では、組織以外が所有している API が組織が所有している API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。 ユースケースの例: - 支払サービスが外部サービスプロバイダーから換算レートを取得する必要がある。 - 内部 API コンシューマーが組織の外部 ServiceNow インスタンス (SaaS サービス) にアクセスする。 ## [](#pattern-7)パターン 7: 組織以外の外部 API が組織の内部コンシューマーに公開されている パターン A では、Flex Gateway をエグレスとしてデプロイします。Flex Gateway を使用して、外部サービスへのフローを監視、制御、強化できます。また、外部アクセスのレート制限やメトリクスおよび分析の追跡を行うこともできます。 ![Flex Gateway は、外部 API からの受信トラフィックを監視するエグレスとして機能します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-3.png) 次の図は、Kubernetes で組織以外の外部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが組織以外の外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターンの詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-3-p-7-physical.png) ## [](#pattern-8)パターン 8: 組織以外の外部 API が組織の外部コンシューマーに公開されている パターン 8 では、Flex Gateway が 2 つの組織の外部エンティティ間の仲介役として機能します。Flex Gateway は安全な通信とポリシーを適用するイングレスおよびエグレスとして実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織以外の外部 API が組織の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 8 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-3-p-8-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc2) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc4) # ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている ユースケース 3 では、組織以外が所有している API が組織が所有している API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。 ユースケースの例: - 支払サービスが外部サービスプロバイダーから換算レートを取得する必要がある。 - 内部 API コンシューマーが組織の外部 ServiceNow インスタンス (SaaS サービス) にアクセスする。 ## [](#pattern-7)パターン 7: 組織以外の外部 API が組織の内部コンシューマーに公開されている パターン A では、Flex Gateway をエグレスとしてデプロイします。Flex Gateway を使用して、外部サービスへのフローを監視、制御、強化できます。また、外部アクセスのレート制限やメトリクスおよび分析の追跡を行うこともできます。 ![Flex Gateway は、外部 API からの受信トラフィックを監視するエグレスとして機能します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-3.png) 次の図は、Kubernetes で組織以外の外部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが組織以外の外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターンの詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-3-p-7-physical.png) ## [](#pattern-8)パターン 8: 組織以外の外部 API が組織の外部コンシューマーに公開されている パターン 8 では、Flex Gateway が 2 つの組織の外部エンティティ間の仲介役として機能します。Flex Gateway は安全な通信とポリシーを適用するイングレスおよびエグレスとして実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織以外の外部 API が組織の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 8 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-3-p-8-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc2) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc4) # ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている ユースケース 3 では、組織以外が所有している API が組織が所有している API コンシューマーに公開されているシナリオのすべてのパターンをカバーしています。 ユースケースの例: - 支払サービスが外部サービスプロバイダーから換算レートを取得する必要がある。 - 内部 API コンシューマーが組織の外部 ServiceNow インスタンス (SaaS サービス) にアクセスする。 ## [](#pattern-7)パターン 7: 組織以外の外部 API が組織の内部コンシューマーに公開されている パターン A では、Flex Gateway をエグレスとしてデプロイします。Flex Gateway を使用して、外部サービスへのフローを監視、制御、強化できます。また、外部アクセスのレート制限やメトリクスおよび分析の追跡を行うこともできます。 ![Flex Gateway は、外部 API からの受信トラフィックを監視するエグレスとして機能します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-3.png) 次の図は、Kubernetes で組織以外の外部 API が組織の内部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが組織以外の外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターンの詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-3-p-7-physical.png) ## [](#pattern-8)パターン 8: 組織以外の外部 API が組織の外部コンシューマーに公開されている パターン 8 では、Flex Gateway が 2 つの組織の外部エンティティ間の仲介役として機能します。Flex Gateway は安全な通信とポリシーを適用するイングレスおよびエグレスとして実行されます。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織以外の外部 API が組織の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 8 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-3-p-8-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc2) - [ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc4) # ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている ユースケース 4 には、組織以外の API が組織以外の API コンシューマーに公開されているシナリオをサポートする 1 つのパターンがあります。 ## [](#pattern-9)パターン 9: 組織以外の外部 API が組織以外の外部コンシューマーに公開されている パターン 9 では、Flex Gateway が 2 つの外部エンティティ間の仲介役として機能します。たとえば、外部顧客が外部の航空会社から提供される旅行情報サービスをコンシュームする場合などがこれに該当します。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織以外の外部 API が組織以外の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 9 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.10/_images/ad-uc-4-p-9-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc3) # ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている ユースケース 4 には、組織以外の API が組織以外の API コンシューマーに公開されているシナリオをサポートする 1 つのパターンがあります。 ## [](#pattern-9)パターン 9: 組織以外の外部 API が組織以外の外部コンシューマーに公開されている パターン 9 では、Flex Gateway が 2 つの外部エンティティ間の仲介役として機能します。たとえば、外部顧客が外部の航空会社から提供される旅行情報サービスをコンシュームする場合などがこれに該当します。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織以外の外部 API が組織以外の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 9 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.8/_images/ad-uc-4-p-9-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc3) # ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている ユースケース 4 には、組織以外の API が組織以外の API コンシューマーに公開されているシナリオをサポートする 1 つのパターンがあります。 ## [](#pattern-9)パターン 9: 組織以外の外部 API が組織以外の外部コンシューマーに公開されている パターン 9 では、Flex Gateway が 2 つの外部エンティティ間の仲介役として機能します。たとえば、外部顧客が外部の航空会社から提供される旅行情報サービスをコンシュームする場合などがこれに該当します。 ![Flex Gateway は、外部アプリケーションと外部 API 間の仲介役として機能します。](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-1-p-4.png) 次の図は、Kubernetes で組織以外の外部 API が組織以外の外部コンシューマーに公開されているシナリオの物理的な実装を示しています。この図では、ファイアウォールが外部 mTLS 受信接続を終了することを前提としています。 ![Flex Gateway をサポートするために必要なサービスが含まれているパターン 9 の詳細なビュー](/mulesoft/current/ja-jp/gateway/1.9/_images/ad-uc-4-p-9-physical.png) ## [](#関連情報)関連情報 - [ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc1) - [ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc2) - [ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc3) # リソースレベルのポリシー 他の設定を行わない限り、ポリシーはデフォルトでは API 全体に適用されます。ただし、条件に基づいてアクセスが制御されるポリシーの粒度レベルを追加して実装できます。この粒度のポリシーは​_リソースレベルポリシー_​と呼ばれます。 粒度のリソースレベルでは、ポリシーは条件に一致する要求のみに適用されます。 クロスオリジンリソース共有 (CORS) ポリシーを除くすべてのポリシーは、リソースレベルです。 接続モードで実行されている Flex Gateway では、API Manager でリソースレベルのポリシーを設定します。 ローカルモードで実行されている Flex Gateway のリソースレベルのポリシーの設定については、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-secure-api-with-auto-policy)を参照してください。 # リソースレベルのポリシー 他の設定を行わない限り、ポリシーはデフォルトでは API 全体に適用されます。ただし、条件に基づいてアクセスが制御されるポリシーの粒度レベルを追加して実装できます。この粒度のポリシーは​_リソースレベルポリシー_​と呼ばれます。 粒度のリソースレベルでは、ポリシーは条件に一致する要求のみに適用されます。 クロスオリジンリソース共有 (CORS) ポリシーを除くすべてのポリシーは、リソースレベルです。 接続モードで実行されている Flex Gateway では、API Manager でリソースレベルのポリシーを設定します。 ローカルモードで実行されている Flex Gateway のリソースレベルのポリシーの設定については、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-secure-api-with-auto-policy)を参照してください。 # リソースレベルのポリシー 他の設定を行わない限り、ポリシーはデフォルトでは API 全体に適用されます。ただし、条件に基づいてアクセスが制御されるポリシーの粒度レベルを追加して実装できます。この粒度のポリシーは​_リソースレベルポリシー_​と呼ばれます。 粒度のリソースレベルでは、ポリシーは条件に一致する要求のみに適用されます。 クロスオリジンリソース共有 (CORS) ポリシーを除くすべてのポリシーは、リソースレベルです。 接続モードで実行されている Flex Gateway では、API Manager でリソースレベルのポリシーを設定します。 ローカルモードで実行されている Flex Gateway のリソースレベルのポリシーの設定については、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-secure-api-with-auto-policy)を参照してください。 # リソースレベルの自動ポリシーを使用した API の保護 ローカルモードで Flex Gateway の背後で実行されている API をパブリッシュすることで、YAML 設定データを変更する方法について説明します。 - Linux および Docker: `.yaml`​ ファイル 下記の手順は、自動リソースレベル認証ポリシーによって保護されている複数のアップストリームサービスを使用した API のシンプルなリソースベースの YAML 設定を適用する方法を示しています。 詳細は、​[「自動ポリシー」](https://docs.mulesoft.com/jp/gateway/1.10/policies-automated-overview)​と​[「リソースレベルのポリシー」](https://docs.mulesoft.com/jp/gateway/1.10/policies-resource-level-overview)​を参照してください。

自動ポリシーは、リソースベースの設定でのみ定義できます。インライン設定モデルはサポートされません。リソースベースとインラインの設定モデルの違いについては、​「宣言型設定リファレンスガイド」​を参照してください。

20%

25%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ​

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ​
## [](#linux-で-flex-gateway-の背後で実行されている-api-のパブリッシュ)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の 2 つの ​`ApiInstance`​ リソースをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: users-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8081 services: users: address: https://:/ routes: - rules: - path: /api/users(/.\*) 3. 次の ​`PolicyBinding`​ リソースを ​`ApiInstance`​ リソースの後に追加して、自動​[基本認証ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-basic-auth-simple)​を定義します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin 自動ポリシーを複数の API インスタンスに適用するには、ポリシーバインドで ​`Selector` ​`kind`​ を指定する必要があります。サンプル ​`PolicyBinding`​ リソースでは、​`spec.targetRef.kind`​ の値が ​`Selector`​、​`spec.targetRef.selector.kind`​ の値が ​`ApiInstance`​ に設定されています。 また、サンプルリソースでは基本認証ポリシーを 2 つの API インスタンスに適用しています。また、​`secured-by-automated-policy`​ ラベルを ​`spec.targetRef.selector.labels`​ で定義しています (ラベル名はカスタマイズ可能です)。このラベルは、自動ポリシーをラベルのリソースに関連付ける ​`ApiInstance` ​`metadata.labels`​ プロパティで定義されているラベルと一致します。 ラベルを省略することで、自動ポリシーをすべての API インスタンスに適用することができます。 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/products-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc00004f750} => {Kind:Service Name:products-api-products Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/users-api http://0.0.0.0:8081 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0061823f0} => {Kind:Service Name:users-api-users Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/products-api-products https://:/ \[agent\]\[debug\] generating service products-api-products.default.svc hostname: https:// port: \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/users-api-users https://:/ \[agent\]\[debug\] generating service users-api-users.default.svc hostname: https:// port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 3 cluster(s) \[envoy\]\[info\] cds: added/updated 0 cluster(s), skipped 2 unmodified cluster(s) 6. `curl`​ などのツールで認証ログイン情報を指定して API をテストします。自動認証ポリシーは、両方の API を保護します。 7. `PolicyBinding`​ リソースを以下に置き換えることで、リソースレベルの粒度を自動認証ポリシーに適用します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin rules: - methods: GET この例では、​`spec.rules`​ で指定されているように、自動認証ポリシーは ​`GET`​ メソッドリソースにのみ適用されます。 8. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 自動リソースレベル認証ポリシーで保護された 2 つの API が Flex Gateway の背後で実行されています。 ## [](#docker-コンテナで-flex-gateway-の背後で実行されている-api-のパブリッシュ)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の 2 つの ​`ApiInstance`​ リソースをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: users-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8081 services: users: address: https://:/ routes: - rules: - path: /api/users(/.\*) 4. 次の ​`PolicyBinding`​ リソースを ​`ApiInstance`​ リソースの後に追加して、自動基本認証ポリシーを定義します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin 自動ポリシーを複数の API インスタンスに適用するには、ポリシーバインドで ​`Selector` ​`kind`​ を指定する必要があります。サンプル ​`PolicyBinding`​ リソースでは、​`spec.targetRef.kind`​ の値が ​`Selector`​、​`spec.targetRef.selector.kind`​ の値が ​`ApiInstance`​ に設定されています。 また、サンプルリソースでは基本認証ポリシーを 2 つの API インスタンスに適用しています。また、​`secured-by-automated-policy`​ ラベルを ​`spec.targetRef.selector.labels`​ で定義しています (ラベル名はカスタマイズ可能です)。このラベルは、自動ポリシーをラベルのリソースに関連付ける ​`ApiInstance` ​`metadata.labels`​ プロパティで定義されているラベルと一致します。 ラベルを省略することで、自動ポリシーをすべての API インスタンスに適用することができます。 5. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 6. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/products-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc00004f750} => {Kind:Service Name:products-api-products Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/users-api http://0.0.0.0:8081 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0061823f0} => {Kind:Service Name:users-api-users Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/products-api-products https://:/ \[agent\]\[debug\] generating service products-api-products.default.svc hostname: https:// port: \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/users-api-users https://:/ \[agent\]\[debug\] generating service users-api-users.default.svc hostname: https:// port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 3 cluster(s) \[envoy\]\[info\] cds: added/updated 0 cluster(s), skipped 2 unmodified cluster(s) 7. `curl`​ などのツールで認証ログイン情報を指定して API をテストします。自動認証ポリシーは、両方の API を保護します。 8. `PolicyBinding`​ リソースを以下に置き換えることで、リソースレベルの粒度を自動認証ポリシーに適用します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin rules: - methods: GET この例では、​`spec.rules`​ で指定されているように、自動認証ポリシーは ​`GET`​ メソッドリソースにのみ適用されます。 9. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 自動リソースレベル認証ポリシーで保護された 2 つの API が Flex Gateway の背後で実行されています。 ## [](#関連情報)関連情報 - [インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) # リソースレベルの自動ポリシーを使用した API の保護 ローカルモードで Flex Gateway の背後で実行されている API をパブリッシュすることで、YAML 設定データを変更する方法について説明します。 - Linux および Docker: `.yaml`​ ファイル 下記の手順は、自動リソースレベル認証ポリシーによって保護されている複数のアップストリームサービスを使用した API のシンプルなリソースベースの YAML 設定を適用する方法を示しています。 詳細は、​[「自動ポリシー」](https://docs.mulesoft.com/jp/gateway/1.8/policies-automated-overview)​と​[「リソースレベルのポリシー」](https://docs.mulesoft.com/jp/gateway/1.8/policies-resource-level-overview)​を参照してください。

自動ポリシーは、リソースベースの設定でのみ定義できます。インライン設定モデルはサポートされません。リソースベースとインラインの設定モデルの違いについては、​「宣言型設定リファレンスガイド」​を参照してください。

20%

25%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ​

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ​
## [](#linux-で-flex-gateway-の背後で実行されている-api-のパブリッシュ)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の 2 つの ​`ApiInstance`​ リソースをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: users-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8081 services: users: address: https://:/ routes: - rules: - path: /api/users(/.\*) 3. 次の ​`PolicyBinding`​ リソースを ​`ApiInstance`​ リソースの後に追加して、自動​[基本認証ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-basic-auth-simple)​を定義します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin 自動ポリシーを複数の API インスタンスに適用するには、ポリシーバインドで ​`Selector` ​`kind`​ を指定する必要があります。サンプル ​`PolicyBinding`​ リソースでは、​`spec.targetRef.kind`​ の値が ​`Selector`​、​`spec.targetRef.selector.kind`​ の値が ​`ApiInstance`​ に設定されています。 また、サンプルリソースでは基本認証ポリシーを 2 つの API インスタンスに適用しています。また、​`secured-by-automated-policy`​ ラベルを ​`spec.targetRef.selector.labels`​ で定義しています (ラベル名はカスタマイズ可能です)。このラベルは、自動ポリシーをラベルのリソースに関連付ける ​`ApiInstance` ​`metadata.labels`​ プロパティで定義されているラベルと一致します。 ラベルを省略することで、自動ポリシーをすべての API インスタンスに適用することができます。 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/products-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc00004f750} => {Kind:Service Name:products-api-products Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/users-api http://0.0.0.0:8081 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0061823f0} => {Kind:Service Name:users-api-users Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/products-api-products https://:/ \[agent\]\[debug\] generating service products-api-products.default.svc hostname: https:// port: \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/users-api-users https://:/ \[agent\]\[debug\] generating service users-api-users.default.svc hostname: https:// port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 3 cluster(s) \[envoy\]\[info\] cds: added/updated 0 cluster(s), skipped 2 unmodified cluster(s) 6. `curl`​ などのツールで認証ログイン情報を指定して API をテストします。自動認証ポリシーは、両方の API を保護します。 7. `PolicyBinding`​ リソースを以下に置き換えることで、リソースレベルの粒度を自動認証ポリシーに適用します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin rules: - methods: GET この例では、​`spec.rules`​ で指定されているように、自動認証ポリシーは ​`GET`​ メソッドリソースにのみ適用されます。 8. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 自動リソースレベル認証ポリシーで保護された 2 つの API が Flex Gateway の背後で実行されています。 ## [](#docker-コンテナで-flex-gateway-の背後で実行されている-api-のパブリッシュ)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の 2 つの ​`ApiInstance`​ リソースをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: users-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8081 services: users: address: https://:/ routes: - rules: - path: /api/users(/.\*) 4. 次の ​`PolicyBinding`​ リソースを ​`ApiInstance`​ リソースの後に追加して、自動基本認証ポリシーを定義します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin 自動ポリシーを複数の API インスタンスに適用するには、ポリシーバインドで ​`Selector` ​`kind`​ を指定する必要があります。サンプル ​`PolicyBinding`​ リソースでは、​`spec.targetRef.kind`​ の値が ​`Selector`​、​`spec.targetRef.selector.kind`​ の値が ​`ApiInstance`​ に設定されています。 また、サンプルリソースでは基本認証ポリシーを 2 つの API インスタンスに適用しています。また、​`secured-by-automated-policy`​ ラベルを ​`spec.targetRef.selector.labels`​ で定義しています (ラベル名はカスタマイズ可能です)。このラベルは、自動ポリシーをラベルのリソースに関連付ける ​`ApiInstance` ​`metadata.labels`​ プロパティで定義されているラベルと一致します。 ラベルを省略することで、自動ポリシーをすべての API インスタンスに適用することができます。 5. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 6. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/products-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc00004f750} => {Kind:Service Name:products-api-products Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/users-api http://0.0.0.0:8081 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0061823f0} => {Kind:Service Name:users-api-users Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/products-api-products https://:/ \[agent\]\[debug\] generating service products-api-products.default.svc hostname: https:// port: \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/users-api-users https://:/ \[agent\]\[debug\] generating service users-api-users.default.svc hostname: https:// port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 3 cluster(s) \[envoy\]\[info\] cds: added/updated 0 cluster(s), skipped 2 unmodified cluster(s) 7. `curl`​ などのツールで認証ログイン情報を指定して API をテストします。自動認証ポリシーは、両方の API を保護します。 8. `PolicyBinding`​ リソースを以下に置き換えることで、リソースレベルの粒度を自動認証ポリシーに適用します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin rules: - methods: GET この例では、​`spec.rules`​ で指定されているように、自動認証ポリシーは ​`GET`​ メソッドリソースにのみ適用されます。 9. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 自動リソースレベル認証ポリシーで保護された 2 つの API が Flex Gateway の背後で実行されています。 ## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory) # リソースレベルの自動ポリシーを使用した API の保護 ローカルモードで Flex Gateway の背後で実行されている API をパブリッシュすることで、YAML 設定データを変更する方法について説明します。 - Linux および Docker: `.yaml`​ ファイル 下記の手順は、自動リソースレベル認証ポリシーによって保護されている複数のアップストリームサービスを使用した API のシンプルなリソースベースの YAML 設定を適用する方法を示しています。 詳細は、​[「自動ポリシー」](https://docs.mulesoft.com/jp/gateway/1.9/policies-automated-overview)​と​[「リソースレベルのポリシー」](https://docs.mulesoft.com/jp/gateway/1.9/policies-resource-level-overview)​を参照してください。

自動ポリシーは、リソースベースの設定でのみ定義できます。インライン設定モデルはサポートされません。リソースベースとインラインの設定モデルの違いについては、​「宣言型設定リファレンスガイド」​を参照してください。

20%

25%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ​

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ​
## [](#linux-で-flex-gateway-の背後で実行されている-api-のパブリッシュ)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の 2 つの ​`ApiInstance`​ リソースをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: users-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8081 services: users: address: https://:/ routes: - rules: - path: /api/users(/.\*) 3. 次の ​`PolicyBinding`​ リソースを ​`ApiInstance`​ リソースの後に追加して、自動​[基本認証ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-basic-auth-simple)​を定義します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin 自動ポリシーを複数の API インスタンスに適用するには、ポリシーバインドで ​`Selector` ​`kind`​ を指定する必要があります。サンプル ​`PolicyBinding`​ リソースでは、​`spec.targetRef.kind`​ の値が ​`Selector`​、​`spec.targetRef.selector.kind`​ の値が ​`ApiInstance`​ に設定されています。 また、サンプルリソースでは基本認証ポリシーを 2 つの API インスタンスに適用しています。また、​`secured-by-automated-policy`​ ラベルを ​`spec.targetRef.selector.labels`​ で定義しています (ラベル名はカスタマイズ可能です)。このラベルは、自動ポリシーをラベルのリソースに関連付ける ​`ApiInstance` ​`metadata.labels`​ プロパティで定義されているラベルと一致します。 ラベルを省略することで、自動ポリシーをすべての API インスタンスに適用することができます。 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/products-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc00004f750} => {Kind:Service Name:products-api-products Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/users-api http://0.0.0.0:8081 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0061823f0} => {Kind:Service Name:users-api-users Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/products-api-products https://:/ \[agent\]\[debug\] generating service products-api-products.default.svc hostname: https:// port: \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/users-api-users https://:/ \[agent\]\[debug\] generating service users-api-users.default.svc hostname: https:// port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 3 cluster(s) \[envoy\]\[info\] cds: added/updated 0 cluster(s), skipped 2 unmodified cluster(s) 6. `curl`​ などのツールで認証ログイン情報を指定して API をテストします。自動認証ポリシーは、両方の API を保護します。 7. `PolicyBinding`​ リソースを以下に置き換えることで、リソースレベルの粒度を自動認証ポリシーに適用します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin rules: - methods: GET この例では、​`spec.rules`​ で指定されているように、自動認証ポリシーは ​`GET`​ メソッドリソースにのみ適用されます。 8. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 自動リソースレベル認証ポリシーで保護された 2 つの API が Flex Gateway の背後で実行されています。 ## [](#docker-コンテナで-flex-gateway-の背後で実行されている-api-のパブリッシュ)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の 2 つの ​`ApiInstance`​ リソースをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: users-api labels: secured-by-automated-policy: yes spec: address: http://0.0.0.0:8081 services: users: address: https://:/ routes: - rules: - path: /api/users(/.\*) 4. 次の ​`PolicyBinding`​ リソースを ​`ApiInstance`​ リソースの後に追加して、自動基本認証ポリシーを定義します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin 自動ポリシーを複数の API インスタンスに適用するには、ポリシーバインドで ​`Selector` ​`kind`​ を指定する必要があります。サンプル ​`PolicyBinding`​ リソースでは、​`spec.targetRef.kind`​ の値が ​`Selector`​、​`spec.targetRef.selector.kind`​ の値が ​`ApiInstance`​ に設定されています。 また、サンプルリソースでは基本認証ポリシーを 2 つの API インスタンスに適用しています。また、​`secured-by-automated-policy`​ ラベルを ​`spec.targetRef.selector.labels`​ で定義しています (ラベル名はカスタマイズ可能です)。このラベルは、自動ポリシーをラベルのリソースに関連付ける ​`ApiInstance` ​`metadata.labels`​ プロパティで定義されているラベルと一致します。 ラベルを省略することで、自動ポリシーをすべての API インスタンスに適用することができます。 5. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 6. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/products-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc00004f750} => {Kind:Service Name:products-api-products Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding ApiInstance default/users-api http://0.0.0.0:8081 \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/security-protection \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0061823f0} => {Kind:Service Name:users-api-users Namespace:default} \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/products-api-products https://:/ \[agent\]\[debug\] generating service products-api-products.default.svc hostname: https:// port: \[agent\]\[info\] Gateway default/21cf4286e38f: Adding Service default/users-api-users https://:/ \[agent\]\[debug\] generating service users-api-users.default.svc hostname: https:// port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 3 cluster(s) \[envoy\]\[info\] cds: added/updated 0 cluster(s), skipped 2 unmodified cluster(s) 7. `curl`​ などのツールで認証ログイン情報を指定して API をテストします。自動認証ポリシーは、両方の API を保護します。 8. `PolicyBinding`​ リソースを以下に置き換えることで、リソースレベルの粒度を自動認証ポリシーに適用します。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: security-protection spec: targetRef: kind: Selector selector: kind: ApiInstance labels: secured-by-automated-policy: yes policyRef: name: http-basic-authentication-flex config: username: chris password: admin rules: - methods: GET この例では、​`spec.rules`​ で指定されているように、自動認証ポリシーは ​`GET`​ メソッドリソースにのみ適用されます。 9. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 自動リソースレベル認証ポリシーで保護された 2 つの API が Flex Gateway の背後で実行されています。 ## [](#関連情報)関連情報 - [インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) # レート制限: SLA ベースのポリシー

ポリシー名

レート制限 SLA

概要

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

401 - 指定されたクライアントログイン情報 (クライアント ID またはクライアントシークレット) が無効であるため、要求がブロックされました。

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。
## [](#概要)概要 レート制限サービスレベル契約 (SLA) ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。期間が終了する前にこの制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限 SLA ポリシーを API に適用するには、先にその API と登録済みクライアントアプリケーションとの間でコントラクトを作成する必要があります。特定の期間中に API が受け取ることのできる要求の数は、API Manager の ​[\[contracts (コントラクト)](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task)\]​ セクションで定義します。 各要求は、クライアント ID と (ポリシー設定によって) 省略可能なクライアントシークレットによって識別される必要があります。登録済みクライアントアプリケーションのクライアントログイン情報の取得方法は、​[「登録済みクライアントアプリケーションのクライアントログイン情報の取得」](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task)​を参照してください。

Flex Gateway API に適用されるレート制限 SLA ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード レート制限 SLA ポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 例

Client ID Expression (クライアント ID 式)

API のコントラクトについてクライアントアプリケーションの ID を解決する DataWeave 式

レート制限アルゴリズムは、ID ごとに 1 つだけ作成されます。 ​#[attributes.headers['client_id']]​ この例では、‘client_id’ という HTTP ヘッダーを探して、その値を使用しています。

Client Secret Expression (クライアントシークレット式)

API のコントラクトについてクライアントアプリケーションのクライアントシークレットを解決する DataWeave 式

省略可能な値です。 例: #[attributes.headers['client_secret']]

Distributed (分散)

有効にすると、クォータが Flex レプリカ間で共有されます

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義する

オンまたはオフ

Block on unknown quota (不明なクォータでブロック)

分散レート制限を使用するポリシーでは、ポリシーが共有ストレージからのクォータを取得できない場合に要求をブロックします。有効でない場合、クォータを取得できなければ、レート制限は適用されません。

オンまたはオフ
## [](#共有ストレージの有効化)共有ストレージの有効化 分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、[接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config)を参照してください。 ## [](#ポリシーのしくみ)ポリシーのしくみ レート制限 SLA ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ウィンドウで使用可能なクォータはクライアントごとに別々に定義されるため、クライアントアプリケーションは API との間で SLA (コントラクト) を定義する必要があります。したがって、要求が SLA の制限内にあるかどうかを検証するには、要求からクライアント ID と必要に応じてクライアントシークレットを取得する手段を定義する必要があります。 クライアントアプリケーションと API との間でコントラクトを作成すると、API ゲートウェイは API Manager 設定を監視することで、自動的にこれらのコントラクトを管理します。さらに API ゲートウェイは、Anypoint Platform 管理プレーンで予期しないダウンタイムが発生した場合に備えて、高可用性戦略を実装します。 レート制限 SLA ポリシーの仕組みをわかりやすくするため、ID が「ID#1」のクライアントについて 10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![指定された時間枠内の受け入れられたクライアント要求と拒否されたクライアント要求の両方を示すタイムラインチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/rate-limiting-sla-general.png) この例では、次のようになります。 - ID が「ID#1」のクライアントの要求: 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていません。このウィンドウは終了したため、残りのクォータは未使用となります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は ​`429 status for HTTP`​ (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 - ID が「ID#2」のクライアントの要求: このクライアントは API との間で定義されているコントラクトを持たないため、すべての要求が拒否され、要求は 1 つも許可されません。 1 つの API は、それぞれ SLA が異なる複数のコントラクトを持つことができます。レート制限 SLA ポリシーは、コントラクトごとに 1 つのレート制限アルゴリズムを作成することで、各クライアントの使用可能なクォータ (およびウィンドウ) を別々に監視します。API に最初の要求が送られた時点で、​_遅延作成_​戦略によってアルゴリズムが作成されます。 ## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限 SLA ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **SLA で複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。

分散モードでは、X-Ratelimit-Remaining ヘッダーがすべてのレプリカと完全には同期されません。 分散モードで複数のレプリカがある場合、X-Ratelimit-Remaining ヘッダーはレプリカ自体で使用できるクォータの量の推定となります。API に使用できる残りのクォータの実際の値が表示されるわけではありません。

有効なシナリオを次に示します。

  • 「10 分ごとに 999999999 件の要求」のレート制限がある SLA 層の名前「Titanium」を作成した

  • 1 件の要求を replica 1 → x-ratelimit-remaining : 999999998 に送信した

  • 1 件の要求を replica 2 → x-ratelimit-remaining : 899999998 に送信した

これは、クォータを超えるという意味ではありません。
**レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # レート制限: SLA ベースのポリシー

ポリシー名

レート制限 SLA

概要

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

401 - 指定されたクライアントログイン情報 (クライアント ID またはクライアントシークレット) が無効であるため、要求がブロックされました。

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。
## [](#概要)概要 レート制限サービスレベル契約 (SLA) ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。期間が終了する前にこの制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限 SLA ポリシーを API に適用するには、先にその API と登録済みクライアントアプリケーションとの間でコントラクトを作成する必要があります。特定の期間中に API が受け取ることのできる要求の数は、API Manager の ​[\[contracts (コントラクト)](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task)\]​ セクションで定義します。 各要求は、クライアント ID と (ポリシー設定によって) 省略可能なクライアントシークレットによって識別される必要があります。登録済みクライアントアプリケーションのクライアントログイン情報の取得方法は、​[「登録済みクライアントアプリケーションのクライアントログイン情報の取得」](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task)​を参照してください。

Flex Gateway API に適用されるレート制限 SLA ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード レート制限 SLA ポリシーは、ローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からポリシーを API に適用するときに、パラメーターのリストが表示されます。 ### [](#ポリシーのパラメーターの設定-2)ポリシーのパラメーターの設定
パラメーター 説明 例

Client ID Expression (クライアント ID 式)

API のコントラクトについてクライアントアプリケーションの ID を解決する DataWeave 式

レート制限アルゴリズムは、ID ごとに 1 つだけ作成されます。 ​#[attributes.headers['client_id']]​ この例では、‘client_id’ という HTTP ヘッダーを探して、その値を使用しています。

Client Secret Expression (クライアントシークレット式)

API のコントラクトについてクライアントアプリケーションのクライアントシークレットを解決する DataWeave 式

省略可能な値です。 例: #[attributes.headers['client_secret']]

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます

Expose Headers (ヘッダーを公開)
#### [](#分散レート制限-sla-リソースの設定例)分散レート制限 SLA リソースの設定例 分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-shared-storage-config)​を参照してください。 ### [](#anypoint-service-mesh-非-mule-アプリケーション-のポリシーパラメーターの設定)Anypoint Service Mesh (非 Mule アプリケーション) のポリシーパラメーターの設定 レート制限 SLA ポリシーは、次の違いを除き、Anypoint Service Mesh (Mule 以外のアプリケーション) と同様に機能します。 - このポリシーでは、ヘッダーを公開するオプションが提供されない - 次の表で説明しているように、パラメーターを取得するクライアント ID とクライアントシークレットが異なる。
要素 説明 必須

Credentials Origin (ログイン情報の取得元)

クライアント ID とクライアントシークレットのログイン情報の取得元:

  • client_id​ および ​client_secret​ ヘッダー

  • カスタムヘッダー

はい

Client ID Header (クライアント ID ヘッダー)

API 要求のクライアント ID を抽出するヘッダー名

はい ([Credentials origin (ログイン情報の取得元)] を ​[Custom ヘッダー (カスタムヘッダー)]​ に設定する場合)

Client Secret Header (クライアントシークレットヘッダー)

API 要求のクライアントシークレットを抽出するヘッダー名

いいえ
## [](#ポリシーのしくみ)ポリシーのしくみ レート制限 SLA ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ウィンドウで使用可能なクォータはクライアントごとに別々に定義されるため、クライアントアプリケーションは API との間で SLA (コントラクト) を定義する必要があります。したがって、要求が SLA の制限内にあるかどうかを検証するには、要求からクライアント ID と必要に応じてクライアントシークレットを取得する手段を定義する必要があります。 クライアントアプリケーションと API との間でコントラクトを作成すると、API ゲートウェイは API Manager 設定を監視することで、自動的にこれらのコントラクトを管理します。さらに API ゲートウェイは、Anypoint Platform 管理プレーンで予期しないダウンタイムが発生した場合に備えて、高可用性戦略を実装します。 レート制限 SLA ポリシーの仕組みをわかりやすくするため、ID が「ID#1」のクライアントについて 10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![レート制限 SLA ポリシー](/mulesoft/current/ja-jp/gateway/1.8/_images/rate-limiting-sla-general.png) この例では、次のようになります。 - ID が「ID#1」のクライアントの要求: 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていません。このウィンドウは終了したため、残りのクォータは未使用となります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は ​`429 status for HTTP`​ (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 - ID が「ID#2」のクライアントの要求: このクライアントは API との間で定義されているコントラクトを持たないため、すべての要求が拒否され、要求は 1 つも許可されません。 1 つの API は、それぞれ SLA が異なる複数のコントラクトを持つことができます。レート制限 SLA ポリシーは、コントラクトごとに 1 つのレート制限アルゴリズムを作成することで、各クライアントの使用可能なクォータ (およびウィンドウ) を別々に監視します。API に最初の要求が送られた時点で、​_遅延作成_​戦略によってアルゴリズムが作成されます。 ## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限 SLA ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **SLA で複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。

分散モードでは、X-Ratelimit-Remaining ヘッダーがすべてのレプリカと完全には同期されません。 分散モードで複数のレプリカがある場合、X-Ratelimit-Remaining ヘッダーはレプリカ自体で使用できるクォータの量の推定となります。API に使用できる残りのクォータの実際の値が表示されるわけではありません。

有効なシナリオを次に示します。

  • 「10 分ごとに 999999999 件の要求」のレート制限がある SLA 層の名前「Titanium」を作成した

  • 1 件の要求を replica 1 → x-ratelimit-remaining : 999999998 に送信した

  • 1 件の要求を replica 2 → x-ratelimit-remaining : 899999998 に送信した

これは、クォータを超えるという意味ではありません。
**レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # レート制限: SLA ベースのポリシー

ポリシー名

レート制限 SLA

概要

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

401 - 指定されたクライアントログイン情報 (クライアント ID またはクライアントシークレット) が無効であるため、要求がブロックされました。

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。
## [](#概要)概要 レート制限サービスレベル契約 (SLA) ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。期間が終了する前にこの制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限 SLA ポリシーを API に適用するには、先にその API と登録済みクライアントアプリケーションとの間でコントラクトを作成する必要があります。特定の期間中に API が受け取ることのできる要求の数は、API Manager の ​[\[contracts (コントラクト)](https://docs.mulesoft.com/jp/api-manager/latest/manage-client-apps-latest-task)\]​ セクションで定義します。 各要求は、クライアント ID と (ポリシー設定によって) 省略可能なクライアントシークレットによって識別される必要があります。登録済みクライアントアプリケーションのクライアントログイン情報の取得方法は、​[「登録済みクライアントアプリケーションのクライアントログイン情報の取得」](https://docs.mulesoft.com/jp/api-manager/latest/access-client-app-id-task)​を参照してください。

Flex Gateway API に適用されるレート制限 SLA ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード レート制限 SLA ポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 例

Client ID Expression (クライアント ID 式)

API のコントラクトについてクライアントアプリケーションの ID を解決する DataWeave 式

レート制限アルゴリズムは、ID ごとに 1 つだけ作成されます。 ​#[attributes.headers['client_id']]​ この例では、‘client_id’ という HTTP ヘッダーを探して、その値を使用しています。

Client Secret Expression (クライアントシークレット式)

API のコントラクトについてクライアントアプリケーションのクライアントシークレットを解決する DataWeave 式

省略可能な値です。 例: #[attributes.headers['client_secret']]

Distributed (分散)

有効にすると、クォータが Flex レプリカ間で共有されます

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義する

オンまたはオフ
## [](#共有ストレージの有効化)共有ストレージの有効化 分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、[接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config)を参照してください。 ## [](#ポリシーのしくみ)ポリシーのしくみ レート制限 SLA ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ウィンドウで使用可能なクォータはクライアントごとに別々に定義されるため、クライアントアプリケーションは API との間で SLA (コントラクト) を定義する必要があります。したがって、要求が SLA の制限内にあるかどうかを検証するには、要求からクライアント ID と必要に応じてクライアントシークレットを取得する手段を定義する必要があります。 クライアントアプリケーションと API との間でコントラクトを作成すると、API ゲートウェイは API Manager 設定を監視することで、自動的にこれらのコントラクトを管理します。さらに API ゲートウェイは、Anypoint Platform 管理プレーンで予期しないダウンタイムが発生した場合に備えて、高可用性戦略を実装します。 レート制限 SLA ポリシーの仕組みをわかりやすくするため、ID が「ID#1」のクライアントについて 10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![指定された時間枠内の受け入れられたクライアント要求と拒否されたクライアント要求の両方を示すタイムラインチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/rate-limiting-sla-general.png) この例では、次のようになります。 - ID が「ID#1」のクライアントの要求: 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていません。このウィンドウは終了したため、残りのクォータは未使用となります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は ​`429 status for HTTP`​ (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 - ID が「ID#2」のクライアントの要求: このクライアントは API との間で定義されているコントラクトを持たないため、すべての要求が拒否され、要求は 1 つも許可されません。 1 つの API は、それぞれ SLA が異なる複数のコントラクトを持つことができます。レート制限 SLA ポリシーは、コントラクトごとに 1 つのレート制限アルゴリズムを作成することで、各クライアントの使用可能なクォータ (およびウィンドウ) を別々に監視します。API に最初の要求が送られた時点で、​_遅延作成_​戦略によってアルゴリズムが作成されます。 ## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限 SLA ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **SLA で複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。

分散モードでは、X-Ratelimit-Remaining ヘッダーがすべてのレプリカと完全には同期されません。 分散モードで複数のレプリカがある場合、X-Ratelimit-Remaining ヘッダーはレプリカ自体で使用できるクォータの量の推定となります。API に使用できる残りのクォータの実際の値が表示されるわけではありません。

有効なシナリオを次に示します。

  • 「10 分ごとに 999999999 件の要求」のレート制限がある SLA 層の名前「Titanium」を作成した

  • 1 件の要求を replica 1 → x-ratelimit-remaining : 999999998 に送信した

  • 1 件の要求を replica 2 → x-ratelimit-remaining : 899999998 に送信した

これは、クォータを超えるという意味ではありません。
**レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。 # レート制限ポリシー

ポリシー名

レート制限

概要

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。
## [](#概要)概要 レート制限ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。この制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限ポリシーを設定するときには、クォータ (要求数) と時間ウィンドウ (期間) の値を自由に組み合わせて指定できます。

Flex Gateway API に適用されるレート制限ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: rate-limiting-flex config: rateLimits: // REQUIRED - maximumRequests: // REQUIRED timePeriodInMilliseconds: // REQUIRED keySelector: // OPTIONAL exposeHeaders: // OPTIONAL, default: false clusterizable: // OPTIONAL, default: true
パラメーター 必須または省略可能 デフォルト値 説明

rateLimits

必須

なし

1 つ以上のレート制限仕様を含むマップ

rateLimits.maximumRequests

必須

なし

ウィンドウで使用可能なクォータ値

rateLimits.timePeriodInMilliseconds

必須

なし

クォータが適用される時間 (数値)

keySelector

省略可能

なし

DataWeave 式で解決される各値の独立したカウンターでグループを作成するセレクターキー文字列。

たとえば、​#[attributes.queryParams['identifier']]​ は、​identifier​ クエリパラメーターを含む要求ごとに独立したカウンターグループを作成します。

exposeHeaders

省略可能

false

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するブール値オプション

clusterizable

省略可能

true

Distributed (分散): このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます

blockOnUnknownQuota

省略可能

true

分散レート制限 (​clusterizable​) を使用するポリシーでは、ポリシーが共有ストレージからのクォータを取得できない場合に要求をブロックします。​false​ の場合、クォータを取得できなければ、レート制限は適用されません。
#### [](#リソースの設定例)リソースの設定例 次の例では、レート制限を 6 秒ごとに 3 件の要求として定義しています。 \- policyRef: name: rate-limiting-flex config: rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.method\]" exposeHeaders: true clusterizable: false `#[attributes.method]`​ DataWeave 式は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。 #### [](#分散レート制限リソースの設定例)分散レート制限リソースの設定例 分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- - policyRef: name: rate-limiting-flex config: rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.method\]" exposeHeaders: true clusterizable: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 例

Identifier (識別子)

DataWeave または正規文字列を使用したセレクターキー

#[attributes.method]​ は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。

Number of Reqs (要求の数)

ウィンドウで使用可能なクォータ

正の数

Time Period (期間)

クォータが適用される時間

正の数

Time Unit (時間単位)

時間の単位 (ミリ秒、秒、分、時)

Minutes (分)

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます。

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するオプション

オンまたはオフ
## [](#ポリシーのしくみ)ポリシーのしくみ レート制限ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ポリシー設定で識別子を使用することで、複数の要求グループに対してポリシーを設定できます。各グループは、それぞれのウィンドウで別々の使用可能なクォータを持ちます。 レート制限ポリシーの仕組みをわかりやすくするため、10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![2 つの時間枠での受け入れられた要求と拒否された要求のタイムライン](/mulesoft/current/ja-jp/gateway/1.10/_images/rate-limiting-generic-example.png) 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていないため、ウィンドウが終了しても、残りのクォータは少なくなります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 ## [](#例)例 上記の 10 秒ごとに 3 件の要求という設定で、レート制限ポリシーがクラスター用に設定され、識別子を使用する場合を考えてみましょう。 ### [](#正規文字列を使用した識別子の設定)正規文字列を使用した識別子の設定 UI を使用してポリシー設定に識別子を追加することで、要求のグループを定義できます。設定された制限は、各グループに別々に適用されます。レート制限ポリシー設定では、HTTP メソッドごとに 1 つのバケットに対して識別子 ​`#[attributes.method]`​ を使用できます。 UI の ​`Identifier`​ は非必須パラメーターです。デフォルトでは ​`Identifier`​ は値を持ちません。デフォルトを使用するか、または値を指定するかにより、ポリシーは次のように機能します。 - 未設定 (デフォルト) レート制限は、バケットまたはグループごとにすべての要求に適用されます。 - 必須 HTTP ヘッダーを使用するように設定 各ヘッダーには個別のクォータが割り当てられます。ヘッダー値では大文字と小文字が区別されます。クォータは​_遅延作成_​を使用して作成されます。 - 非必須 HTTP ヘッダーを使用するように設定 カスタムヘッダー、ペイロード、クエリパラメーター、または式の値には、個別のクォータが割り当てられます。 識別子が要求で送信されない場合、デフォルトで空の値に設定され、独自のクォータが使用されます。この動作では、未制御のクライアントによってコンシュームされる API にレート制限ポリシーを適用できると同時に、識別子を送信するクライアントの特別なバケットに対応します。 次の例は、10 秒おきに 3 つの要求の設定で識別子 ​`#[attributes.method]`​ を使用した場合に、一定期間に発生するイベントの順序を示しています。 ![経時的な GET 要求と POST 要求の受け入れと拒否を示す折れ線チャート](/mulesoft/current/ja-jp/gateway/1.10/_images/rate-limiting-configure-identifiers-example.png) この例では、次のようになります。 - すべての HTTP メソッドでは 10 秒おきに 3 つの要求が許可されます (この例では、API に対して GET 要求と POST 要求のみが実行されています)。 - レート制限ポリシーは、固定されたウィンドウで機能します。 詳細は、図中のウィンドウサイズの括弧を参照してください。 - ウィンドウの開始時間は独立しています。 - エンジンはメソッドの最初の要求を受信するとレート制限アルゴリズムをスプールする​_遅延作成_​戦略を使用します。 ### [](#dataweave-式を使用した識別子の設定)DataWeave 式を使用した識別子の設定 レート制限エンジンは HTTP に依存せず、DataWeave 式の解決のみに左右されます。複雑なレート制限シナリオに対応するために UI の ​`Identifier`​ 式を変更することができます。 たとえば、すべてのクラス A およびクラス C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。次の画像は前の文の 2 つ目のバケットを示し、DataWeave 式 ​`#[attributes.queryParam[‘customIdentifier’]]`​ をポリシー識別子として使用する 10 秒ごとに 3 件のクォータに相当します。 ![時間間隔で整理された受け入れられた要求と拒否された要求の両方を示すタイムライン](/mulesoft/current/ja-jp/gateway/1.10/_images/rate-limiting-configure-identifiers-dataweave.png) この例では、次のようになります。 - 識別子のない要求はすべて空の識別子に解決されます。したがって、1 つのレート制限アルゴリズムを使用します。 - 識別子ごとに異なるバケットが使用され、各バケットには独立したクォータが割り当てられます。 この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。​`false`​ 値と ​`true`​ 値は、HTTP ではなくブール値のドメインに対応します。 いずれにせよ、エンジンは解決された式を文字列として扱うため、ポリシーは正常に機能します。この場合、値は自動的にブールから文字列にキャストされます。スクリプトに ​`output text/plain ---`​ を追加することで、DataWeave でキャストを明示的に定義できます。

HTTP RFC のヘッダー名では、大文字と小文字は区別されません。MuleSoft HTTP 用 Anypoint Connector は、ヘッダー名を小文字に変換します。ただし、DataWeave キーでは大文字と小文字が区別されます。したがって、​Identifier​ 式を作成するときには、小文字のヘッダーを参照するようにしてください。
### [](#無制限の識別子セットの設定)無制限の識別子セットの設定 すべての識別子結果では 1 つのアルゴリズムが使用されます。DataWeave 式が無制限の (非常に大規模な) 共用ドメインを返さないように注意して作成してください。このようなドメインが返されると、同じ数のアルゴリズムをメモリ内でホストしなければならなくなります (アルゴリズムが​_遅延作成_​戦略で作成されるため、可能なすべての識別子に対して最低 1 つの要求を実行する必要があります)。 たとえば、DataWeave 式で、インターネットに公開された Flex Gateway インスタンスでの識別子として IP アドレスを使用するとします。インターネット上のすべての公開 IPv4 IP がこのインスタンスに対して要求を実行すると、1 つのインスタンスで 3,706,452,992 件のアルゴリズムが実行されます。 アルゴリズムの平均サイズが 250 バイトであれば、レート制限アルゴリズムのサイズは約 1 テラバイトになります。そのため、有限数の識別子に解決される DataWeave 式を使用することで、結果のセットをできるだけ小さくしてください。 ## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限ポリシーと​**レート制限 SLA**​ ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (​**レート制限 SLA**​ を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりに​**スパイク制御**​を使用してください。 # レート制限ポリシー

ポリシー名

レート制限

概要

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。
## [](#概要)概要 レート制限ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。この制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限ポリシーを設定するときには、クォータ (要求数) と時間ウィンドウ (期間) の値を自由に組み合わせて指定できます。

Flex Gateway API に適用されるレート制限ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してレート制限ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: rate-limiting-flex config: rateLimits: // REQUIRED - maximumRequests: // REQUIRED timePeriodInMilliseconds: // REQUIRED keySelector: // OPTIONAL exposeHeaders: // OPTIONAL, default: false clusterizable: // OPTIONAL, default: true
パラメーター 必須または省略可能 デフォルト値 説明

rateLimits

必須

なし

1 つ以上のレート制限仕様を含むマップ

rateLimits.maximumRequests

必須

なし

ウィンドウで使用可能なクォータ値

rateLimits.timePeriodInMilliseconds

必須

なし

クォータが適用される時間 (数値)

keySelector

省略可能

なし

DataWeave 式で解決される各値の独立したカウンターでグループを作成するセレクターキー文字列。

たとえば、​#[attributes.queryParams['identifier']]​ は、​identifier​ クエリパラメーターを含む要求ごとに独立したカウンターグループを作成します。

exposeHeaders

省略可能

false

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するブール値オプション

clusterizable

省略可能

true

Distributed (分散): このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます
#### [](#リソースの設定例)リソースの設定例 次の例では、レート制限を 6 秒ごとに 3 件の要求として定義しています。 \- policyRef: name: rate-limiting-flex config: rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.method\]" exposeHeaders: true clusterizable: false `#[attributes.method]`​ DataWeave 式は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。 #### [](#分散レート制限リソースの設定例)分散レート制限リソースの設定例 分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- - policyRef: name: rate-limiting-flex config: rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.method\]" exposeHeaders: true clusterizable: true ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からレート制限ポリシーを API に適用する場合は、次のパラメーターを設定できます。
パラメーター 説明 例

Identifier (識別子)

DataWeave または正規文字列を使用したセレクターキー

#[attributes.method]​ は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。

Number of Reqs (要求の数)

ウィンドウで使用可能なクォータ

正の数

Time Period (期間)

クォータが適用される時間

正の数

Time Unit (時間単位)

時間の単位 (ミリ秒、秒、分、時)

Minutes (分)

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます。

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するオプション

オンまたはオフ
## [](#ポリシーのしくみ)ポリシーのしくみ レート制限ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ポリシー設定で識別子を使用することで、複数の要求グループに対してポリシーを設定できます。各グループは、それぞれのウィンドウで別々の使用可能なクォータを持ちます。 レート制限ポリシーの仕組みをわかりやすくするため、10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![レート制限ポリシーの例](/mulesoft/current/ja-jp/gateway/1.8/_images/rate-limiting-generic-example.png) 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていないため、ウィンドウが終了しても、残りのクォータは少なくなります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 ## [](#例)例 上記の 10 秒ごとに 3 件の要求という設定で、レート制限ポリシーがクラスター用に設定され、識別子を使用する場合を考えてみましょう。 ### [](#正規文字列を使用した識別子の設定)正規文字列を使用した識別子の設定 UI を使用してポリシー設定に識別子を追加することで、要求のグループを定義できます。設定された制限は、各グループに別々に適用されます。レート制限ポリシー設定では、HTTP メソッドごとに 1 つのバケットに対して識別子 ​`#[attributes.method]`​ を使用できます。 UI の ​`Identifier`​ は非必須パラメーターです。デフォルトでは ​`Identifier`​ は値を持ちません。デフォルトを使用するか、または値を指定するかにより、ポリシーは次のように機能します。 - 未設定 (デフォルト) レート制限は、バケットまたはグループごとにすべての要求に適用されます。 - 必須 HTTP ヘッダーを使用するように設定 各ヘッダーには個別のクォータが割り当てられます。ヘッダー値では大文字と小文字が区別されます。クォータは​_遅延作成_​を使用して作成されます。 - 非必須 HTTP ヘッダーを使用するように設定 カスタムヘッダー、ペイロード、クエリパラメーター、または式の値には、個別のクォータが割り当てられます。 識別子が要求で送信されない場合、デフォルトで空の値に設定され、独自のクォータが使用されます。この動作では、未制御のクライアントによってコンシュームされる API にレート制限ポリシーを適用できると同時に、識別子を送信するクライアントの特別なバケットに対応します。 次の例は、10 秒おきに 3 つの要求の設定で識別子 ​`#[attributes.method]`​ を使用した場合に、一定期間に発生するイベントの順序を示しています。 ![レート制限の識別子設定例](/mulesoft/current/ja-jp/gateway/1.8/_images/rate-limiting-configure-identifiers-example.png) この例では、 - すべての HTTP メソッドでは 10 秒おきに 3 つの要求が許可されます (この例では、API に対して GET 要求と POST 要求のみが実行されています)。 - レート制限ポリシーは、固定されたウィンドウで機能します。 詳細は、図中のウィンドウサイズの括弧を参照してください。 - ウィンドウの開始時間は独立しています。 - エンジンはメソッドの最初の要求を受信するとレート制限アルゴリズムをスプールする​_遅延作成_​戦略を使用します。 ### [](#dataweave-式を使用した識別子の設定)DataWeave 式を使用した識別子の設定 レート制限エンジンは HTTP に依存せず、DataWeave 式の解決のみに左右されます。複雑なレート制限シナリオに対応するために UI の ​`Identifier`​ 式を変更することができます。 たとえば、すべてのクラス A およびクラス C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。次の画像は前の文の 2 つ目のバケットを示し、DataWeave 式 ​`#[attributes.queryParam[‘customIdentifier’]]`​ をポリシー識別子として使用する 10 秒ごとに 3 件のクォータに相当します。 ![DataWeave によるレート制限の識別子設定例](/mulesoft/current/ja-jp/gateway/1.8/_images/rate-limiting-configure-identifiers-dataweave.png) この例では、 - 識別子のない要求はすべて空の識別子に解決されます。したがって、1 つのレート制限アルゴリズムを使用します。 - 識別子ごとに異なるバケットが使用され、各バケットには独立したクォータが割り当てられます。 この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。​`false`​ 値と ​`true`​ 値は、HTTP ではなくブール値のドメインに対応します。 いずれにせよ、エンジンは解決された式を文字列として扱うため、ポリシーは正常に機能します。この場合、値は自動的にブールから文字列にキャストされます。スクリプトに ​`output text/plain ---`​ を追加することで、DataWeave でキャストを明示的に定義できます。

HTTP RFC のヘッダー名では、大文字と小文字は区別されません。MuleSoft HTTP 用 Anypoint Connector は、ヘッダー名を小文字に変換します。ただし、DataWeave キーでは大文字と小文字が区別されます。したがって、​Identifier​ 式を作成するときには、小文字のヘッダーを参照するようにしてください。
### [](#無制限の識別子セットの設定)無制限の識別子セットの設定 すべての識別子結果では 1 つのアルゴリズムが使用されます。DataWeave 式が無制限の (非常に大規模な) 共用ドメインを返さないように注意して作成してください。このようなドメインが返されると、同じ数のアルゴリズムをメモリ内でホストしなければならなくなります (アルゴリズムが​_遅延作成_​戦略で作成されるため、可能なすべての識別子に対して最低 1 つの要求を実行する必要があります)。 たとえば、DataWeave 式で、インターネットに公開された Flex Gateway インスタンスでの識別子として IP アドレスを使用するとします。インターネット上のすべての公開 IPv4 IP がこのインスタンスに対して要求を実行すると、1 つのインスタンスで 3,706,452,992 件のアルゴリズムが実行されます。 アルゴリズムの平均サイズが 250 バイトであれば、レート制限アルゴリズムのサイズは約 1 テラバイトになります。そのため、有限数の識別子に解決される DataWeave 式を使用することで、結果のセットをできるだけ小さくしてください。 ## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限ポリシーと​**レート制限 SLA**​ ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (​**レート制限 SLA**​ を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりに​**スパイク制御**​を使用してください。 # レート制限ポリシー

ポリシー名

レート制限

概要

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。
## [](#概要)概要 レート制限ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。この制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。 レート制限ポリシーを設定するときには、クォータ (要求数) と時間ウィンドウ (期間) の値を自由に組み合わせて指定できます。

Flex Gateway API に適用されるレート制限ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: rate-limiting-flex config: rateLimits: // REQUIRED - maximumRequests: // REQUIRED timePeriodInMilliseconds: // REQUIRED keySelector: // OPTIONAL exposeHeaders: // OPTIONAL, default: false clusterizable: // OPTIONAL, default: true
パラメーター 必須または省略可能 デフォルト値 説明

rateLimits

必須

なし

1 つ以上のレート制限仕様を含むマップ

rateLimits.maximumRequests

必須

なし

ウィンドウで使用可能なクォータ値

rateLimits.timePeriodInMilliseconds

必須

なし

クォータが適用される時間 (数値)

keySelector

省略可能

なし

DataWeave 式で解決される各値の独立したカウンターでグループを作成するセレクターキー文字列。

たとえば、​#[attributes.queryParams['identifier']]​ は、​identifier​ クエリパラメーターを含む要求ごとに独立したカウンターグループを作成します。

exposeHeaders

省略可能

false

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するブール値オプション

clusterizable

省略可能

true

Distributed (分散): このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます
#### [](#リソースの設定例)リソースの設定例 次の例では、レート制限を 6 秒ごとに 3 件の要求として定義しています。 \- policyRef: name: rate-limiting-flex config: rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.method\]" exposeHeaders: true clusterizable: false `#[attributes.method]`​ DataWeave 式は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。 #### [](#分散レート制限リソースの設定例)分散レート制限リソースの設定例 分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​[「接続モードでの Flex Gateway の共有ストレージの設定」](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config)​を参照してください。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis:6379 user: user password: pass DB: 1 --- - policyRef: name: rate-limiting-flex config: rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.method\]" exposeHeaders: true clusterizable: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 例

Identifier (識別子)

DataWeave または正規文字列を使用したセレクターキー

#[attributes.method]​ は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。

Number of Reqs (要求の数)

ウィンドウで使用可能なクォータ

正の数

Time Period (期間)

クォータが適用される時間

正の数

Time Unit (時間単位)

時間の単位 (ミリ秒、秒、分、時)

Minutes (分)

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます。

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するオプション

オンまたはオフ
## [](#ポリシーのしくみ)ポリシーのしくみ レート制限ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。 ポリシー設定で識別子を使用することで、複数の要求グループに対してポリシーを設定できます。各グループは、それぞれのウィンドウで別々の使用可能なクォータを持ちます。 レート制限ポリシーの仕組みをわかりやすくするため、10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。 ![2 つの時間枠での受け入れられた要求と拒否された要求のタイムライン](/mulesoft/current/ja-jp/gateway/1.9/_images/rate-limiting-generic-example.png) 最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていないため、ウィンドウが終了しても、残りのクォータは少なくなります。 受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。 ## [](#例)例 上記の 10 秒ごとに 3 件の要求という設定で、レート制限ポリシーがクラスター用に設定され、識別子を使用する場合を考えてみましょう。 ### [](#正規文字列を使用した識別子の設定)正規文字列を使用した識別子の設定 UI を使用してポリシー設定に識別子を追加することで、要求のグループを定義できます。設定された制限は、各グループに別々に適用されます。レート制限ポリシー設定では、HTTP メソッドごとに 1 つのバケットに対して識別子 ​`#[attributes.method]`​ を使用できます。 UI の ​`Identifier`​ は非必須パラメーターです。デフォルトでは ​`Identifier`​ は値を持ちません。デフォルトを使用するか、または値を指定するかにより、ポリシーは次のように機能します。 - 未設定 (デフォルト) レート制限は、バケットまたはグループごとにすべての要求に適用されます。 - 必須 HTTP ヘッダーを使用するように設定 各ヘッダーには個別のクォータが割り当てられます。ヘッダー値では大文字と小文字が区別されます。クォータは​_遅延作成_​を使用して作成されます。 - 非必須 HTTP ヘッダーを使用するように設定 カスタムヘッダー、ペイロード、クエリパラメーター、または式の値には、個別のクォータが割り当てられます。 識別子が要求で送信されない場合、デフォルトで空の値に設定され、独自のクォータが使用されます。この動作では、未制御のクライアントによってコンシュームされる API にレート制限ポリシーを適用できると同時に、識別子を送信するクライアントの特別なバケットに対応します。 次の例は、10 秒おきに 3 つの要求の設定で識別子 ​`#[attributes.method]`​ を使用した場合に、一定期間に発生するイベントの順序を示しています。 ![経時的な GET 要求と POST 要求の受け入れと拒否を示す折れ線チャート](/mulesoft/current/ja-jp/gateway/1.9/_images/rate-limiting-configure-identifiers-example.png) この例では、次のようになります。 - すべての HTTP メソッドでは 10 秒おきに 3 つの要求が許可されます (この例では、API に対して GET 要求と POST 要求のみが実行されています)。 - レート制限ポリシーは、固定されたウィンドウで機能します。 詳細は、図中のウィンドウサイズの括弧を参照してください。 - ウィンドウの開始時間は独立しています。 - エンジンはメソッドの最初の要求を受信するとレート制限アルゴリズムをスプールする​_遅延作成_​戦略を使用します。 ### [](#dataweave-式を使用した識別子の設定)DataWeave 式を使用した識別子の設定 レート制限エンジンは HTTP に依存せず、DataWeave 式の解決のみに左右されます。複雑なレート制限シナリオに対応するために UI の ​`Identifier`​ 式を変更することができます。 たとえば、すべてのクラス A およびクラス C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。次の画像は前の文の 2 つ目のバケットを示し、DataWeave 式 ​`#[attributes.queryParam[‘customIdentifier’]]`​ をポリシー識別子として使用する 10 秒ごとに 3 件のクォータに相当します。 ![時間間隔で整理された受け入れられた要求と拒否された要求の両方を示すタイムライン](/mulesoft/current/ja-jp/gateway/1.9/_images/rate-limiting-configure-identifiers-dataweave.png) この例では、次のようになります。 - 識別子のない要求はすべて空の識別子に解決されます。したがって、1 つのレート制限アルゴリズムを使用します。 - 識別子ごとに異なるバケットが使用され、各バケットには独立したクォータが割り当てられます。 この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。​`false`​ 値と ​`true`​ 値は、HTTP ではなくブール値のドメインに対応します。 いずれにせよ、エンジンは解決された式を文字列として扱うため、ポリシーは正常に機能します。この場合、値は自動的にブールから文字列にキャストされます。スクリプトに ​`output text/plain ---`​ を追加することで、DataWeave でキャストを明示的に定義できます。

HTTP RFC のヘッダー名では、大文字と小文字は区別されません。MuleSoft HTTP 用 Anypoint Connector は、ヘッダー名を小文字に変換します。ただし、DataWeave キーでは大文字と小文字が区別されます。したがって、​Identifier​ 式を作成するときには、小文字のヘッダーを参照するようにしてください。
### [](#無制限の識別子セットの設定)無制限の識別子セットの設定 すべての識別子結果では 1 つのアルゴリズムが使用されます。DataWeave 式が無制限の (非常に大規模な) 共用ドメインを返さないように注意して作成してください。このようなドメインが返されると、同じ数のアルゴリズムをメモリ内でホストしなければならなくなります (アルゴリズムが​_遅延作成_​戦略で作成されるため、可能なすべての識別子に対して最低 1 つの要求を実行する必要があります)。 たとえば、DataWeave 式で、インターネットに公開された Flex Gateway インスタンスでの識別子として IP アドレスを使用するとします。インターネット上のすべての公開 IPv4 IP がこのインスタンスに対して要求を実行すると、1 つのインスタンスで 3,706,452,992 件のアルゴリズムが実行されます。 アルゴリズムの平均サイズが 250 バイトであれば、レート制限アルゴリズムのサイズは約 1 テラバイトになります。そのため、有限数の識別子に解決される DataWeave 式を使用することで、結果のセットをできるだけ小さくしてください。 ## [](#faq)FAQ **このウィンドウはいつ開始されますか?** このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。 **アルゴリズムが使用するウィンドウの種別は?** 固定ウィンドウです。 **クォータを使い果たすとどうなりますか?** アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。 要求クォータを使い果たすと、レート制限ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。 **複数の制限を定義するとどうなりますか?** ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。 **各レスポンスヘッダーの意味は?** 各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。 - X-Ratelimit-Remaining: 使用可能な要求クォータ - X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数 - X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒) デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​**\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 **レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?** レート制限ポリシーと​**レート制限 SLA**​ ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (​**レート制限 SLA**​ を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりに​**スパイク制御**​を使用してください。 # ローカルモード API のパブリッシュ ローカルモードで実行されている Flex Gateway では、​[ローカルの宣言型設定ファイル](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)​を使用して API をパブリッシュします。最初に Flex Gateway を実行するときに、この設定ファイルの場所を指定します。 ゲートウェイの実行方法についての詳細は、[ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)を参照してください。 ローカルモードで API をパブリッシュする方法の例は、次のチュートリアルを参照してください。 - [ローカルモードでのシンプルな API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-simple-api) - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-api-multiple-services) # ローカルモード API のパブリッシュ ローカルモードで実行されている Flex Gateway では、​[ローカルの宣言型設定ファイル](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)​を使用して API をパブリッシュします。最初に Flex Gateway を実行するときに、この設定ファイルの場所を指定します。 ゲートウェイの実行方法についての詳細は、[ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)を参照してください。 ローカルモードで API をパブリッシュする方法の例は、次のチュートリアルを参照してください。 - [ローカルモードでのシンプルな API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-simple-api) - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-api-multiple-services) # ローカルモードでトークンを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する Anypoint Platform 環境の登録​**トークン** Runtime Manager に移動して、左側のナビゲーションにある ​**\[Flex Gateways (Flex Gateway)\]**​ を選択し、​**\[Add Gateway (ゲートウェイを追加)\]**​ をクリックして、登録トークンを使用したコマンドブロックを含む命令セットを生成します。 ## [](#linux)トークンを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --token= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)トークンを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)トークンを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)トークンを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)トークンを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)トークンを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) # ローカルモードでトークンを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する Anypoint Platform 環境の登録​**トークン** Runtime Manager に移動して、左側のナビゲーションにある ​**\[Flex Gateway\]**​ を選択し、​**\[Add Gateway (ゲートウェイを追加)\]**​ をクリックして、登録トークンを使用したコマンドブロックを含む命令セットを生成します。 ## [](#linux)トークンを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --token= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)トークンを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)トークンを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)トークンを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)トークンを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)トークンを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) # ローカルモードでトークンを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する Anypoint Platform 環境の登録​**トークン** Runtime Manager に移動して、左側のナビゲーションにある ​**\[Flex Gateways (Flex Gateway)\]**​ を選択し、​**\[Add Gateway (ゲートウェイを追加)\]**​ をクリックして、登録トークンを使用したコマンドブロックを含む命令セットを生成します。 ## [](#linux)トークンを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --token= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)トークンを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)トークンを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)トークンを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)トークンを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)トークンを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) # ローカルモードでの API の保護および制御 ローカルモードで実行されている Flex Gateway では、​[ローカルの宣言型設定ファイル](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)​を使用して API ポリシーを適用します。最初に Flex Gateway を実行するときに、この設定ファイルの場所を指定します。 ゲートウェイの開始方法についての詳細は、[ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)を参照してください。 ローカルモードで API にポリシーを適用する方法の例は、次のチュートリアルを参照してください。 - [基本認証とレート制限を使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-secure-api-with-basic-auth-policy) - [リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-secure-api-with-auto-policy) - [カスタムポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-deploy-custom-policy) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) # ローカルモードでの Flex Gateway API のパブリッシュ ローカルモードで実行されている Flex Gateway では、​[ローカルの宣言型設定ファイル](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)​を使用して API をパブリッシュします。最初に Flex Gateway を実行するときに、この設定ファイルの場所を指定します。 ゲートウェイの実行方法についての詳細は、[ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)を参照してください。 ローカルモードで API をパブリッシュする方法の例は、次のチュートリアルを参照してください。 - [ローカルモードでのシンプルな API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-simple-api) - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-api-multiple-services) # ローカルモードでの Flex Gateway の TLS コンテキストの設定 Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。ローカルモードの Flex Gateway をランタイムとして使用して API インスタンスを作成するときに TLS を使用するには、​`PolicyBinding`​ YAML 設定ファイルで TLS コンテキストを設定する必要があります。 TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。 Flex Gateway では以下がサポートされます。 - クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる) - API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる) - インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS) デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 次のチュートリアルは、設定済みの ​`PolicyBinding`​ リソースの適用方法を示しています。リソースの設定方法については、ポリシー設定のページを参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls-outbound) インバウンド TLS の場合は、ポリシーリソースを API インスタンスにバインドします。アウトバウンド TLS の場合は、ポリシーリソースをアップストリームサービスにバインドします。 Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の TLS コンテキストを設定できます。

20%

25%

20%

Linux サービスとして Flex Gateway の TLS コンテキストを設定する

Docker コンテナで Flex Gateway の TLS コンテキストを設定する

Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する
## [](#始める前に)始める前に Flex Gateway の TLS コンテキストを設定する前に、次のタスクを完了する必要があります。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の TLS コンテキストを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml ``` 2. TLS コンテキスト設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml ``` 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
3. ポリシーが正しく適用されていることを確認します。 次のサンプル ​`curl`​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。 ```ssh curl https://:/get --cacert -v ``` コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​`200`​ が返されることを確認してください。 \* TLSv1.3 (OUT), TLS handshake, Client hello (1): \* TLSv1.3 (IN), TLS handshake, Server hello (2): \* TLSv1.2 (IN), TLS handshake, Certificate (11): \* TLSv1.2 (IN), TLS handshake, Server key exchange (12): \* TLSv1.2 (IN), TLS handshake, Server finished (14): \* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): \* TLSv1.2 (OUT), TLS change cipher, Client hello (1): \* TLSv1.2 (OUT), TLS handshake, Finished (20): \* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 \* ALPN, server did not agree to a protocol ... > HTTP/1.1 200 OK インバウンド mTLS の場合、次の例の ​`curl`​ コマンドは、ベースパスが ​`/`​である API プロキシを要求します。 ```ssh curl https://:/get \ --cert \ --key \ --cacert \ --resolve ::127.0.0.1 -v ```

設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
## [](#docker)Docker コンテナで Flex Gateway の TLS コンテキストを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、TLS コンテキストの詳細を使用して ​`app`​ フォルダーに保存します。 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
5. ポリシーが正しく適用されていることを確認します。 次のサンプル ​`curl`​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。 ```ssh curl https://:/get --cacert -v ``` コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​`200`​ が返されることを確認してください。 \* TLSv1.3 (OUT), TLS handshake, Client hello (1): \* TLSv1.3 (IN), TLS handshake, Server hello (2): \* TLSv1.2 (IN), TLS handshake, Certificate (11): \* TLSv1.2 (IN), TLS handshake, Server key exchange (12): \* TLSv1.2 (IN), TLS handshake, Server finished (14): \* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): \* TLSv1.2 (OUT), TLS change cipher, Client hello (1): \* TLSv1.2 (OUT), TLS handshake, Finished (20): \* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 \* ALPN, server did not agree to a protocol ... > HTTP/1.1 200 OK インバウンド mTLS の場合、次の例の ​`curl`​ コマンドは、ベースパスが ​`/`​である API プロキシを要求します。 ```ssh curl https://:/get \ --cert \ --key \ --cacert \ --resolve ::127.0.0.1 -v ```

設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
## [](#kubernetes)Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する Flex Gateway の TLS コンテキストを設定するには、YAML 設定ファイルと TLS コンテキストの詳細を使用して新しいリソースを作成します。 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls-outbound) # ローカルモードでの Flex Gateway の TLS コンテキストの設定 Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。ローカルモードの Flex Gateway をランタイムとして使用して API インスタンスを作成するときに TLS を使用するには、​`PolicyBinding`​ YAML 設定ファイルで TLS コンテキストを設定する必要があります。 TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。 Flex Gateway では以下がサポートされます。 - クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる) - API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる) - インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS) デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 次のチュートリアルは、設定済みの ​`PolicyBinding`​ リソースの適用方法を示しています。リソースの設定方法については、ポリシー設定のページを参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls-outbound) インバウンド TLS の場合は、ポリシーリソースを API インスタンスにバインドします。アウトバウンド TLS の場合は、ポリシーリソースをアップストリームサービスにバインドします。 Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の TLS コンテキストを設定できます。

20%

25%

20%

Linux サービスとして Flex Gateway の TLS コンテキストを設定する

Docker コンテナで Flex Gateway の TLS コンテキストを設定する

Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する
## [](#始める前に)始める前に Flex Gateway の TLS コンテキストを設定する前に、次のタスクを完了する必要があります。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の TLS コンテキストを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml ``` 2. TLS コンテキスト設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml ``` 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
3. ポリシーが正しく適用されていることを確認します。 次のサンプル ​`curl`​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。 ```ssh curl https://:/get --cacert -v ``` コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​`200`​ が返されることを確認してください。 \* TLSv1.3 (OUT), TLS handshake, Client hello (1): \* TLSv1.3 (IN), TLS handshake, Server hello (2): \* TLSv1.2 (IN), TLS handshake, Certificate (11): \* TLSv1.2 (IN), TLS handshake, Server key exchange (12): \* TLSv1.2 (IN), TLS handshake, Server finished (14): \* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): \* TLSv1.2 (OUT), TLS change cipher, Client hello (1): \* TLSv1.2 (OUT), TLS handshake, Finished (20): \* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 \* ALPN, server did not agree to a protocol ... > HTTP/1.1 200 OK インバウンド mTLS の場合、次の例の ​`curl`​ コマンドは、ベースパスが ​`/`​である API プロキシを要求します。 ```ssh curl https://:/get \ --cert \ --key \ --cacert \ --resolve ::127.0.0.1 -v ```

設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
## [](#docker)Docker コンテナで Flex Gateway の TLS コンテキストを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、TLS コンテキストの詳細を使用して ​`app`​ フォルダーに保存します。 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
5. ポリシーが正しく適用されていることを確認します。 次のサンプル ​`curl`​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。 ```ssh curl https://:/get --cacert -v ``` コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​`200`​ が返されることを確認してください。 \* TLSv1.3 (OUT), TLS handshake, Client hello (1): \* TLSv1.3 (IN), TLS handshake, Server hello (2): \* TLSv1.2 (IN), TLS handshake, Certificate (11): \* TLSv1.2 (IN), TLS handshake, Server key exchange (12): \* TLSv1.2 (IN), TLS handshake, Server finished (14): \* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): \* TLSv1.2 (OUT), TLS change cipher, Client hello (1): \* TLSv1.2 (OUT), TLS handshake, Finished (20): \* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 \* ALPN, server did not agree to a protocol ... > HTTP/1.1 200 OK インバウンド mTLS の場合、次の例の ​`curl`​ コマンドは、ベースパスが ​`/`​である API プロキシを要求します。 ```ssh curl https://:/get \ --cert \ --key \ --cacert \ --resolve ::127.0.0.1 -v ```

設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
## [](#kubernetes)Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する Flex Gateway の TLS コンテキストを設定するには、YAML 設定ファイルと TLS コンテキストの詳細を使用して新しいリソースを作成します。 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls-outbound) # ローカルモードでの Flex Gateway の TLS コンテキストの設定 Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。ローカルモードの Flex Gateway をランタイムとして使用して API インスタンスを作成するときに TLS を使用するには、​`PolicyBinding`​ YAML 設定ファイルで TLS コンテキストを設定する必要があります。 TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。 Flex Gateway では以下がサポートされます。 - クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる) - API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる) - インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS) デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 次のチュートリアルは、設定済みの ​`PolicyBinding`​ リソースの適用方法を示しています。リソースの設定方法については、ポリシー設定のページを参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls-outbound) インバウンド TLS の場合は、ポリシーリソースを API インスタンスにバインドします。アウトバウンド TLS の場合は、ポリシーリソースをアップストリームサービスにバインドします。 Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の TLS コンテキストを設定できます。

20%

25%

20%

Linux サービスとして Flex Gateway の TLS コンテキストを設定する

Docker コンテナで Flex Gateway の TLS コンテキストを設定する

Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する
## [](#始める前に)始める前に Flex Gateway の TLS コンテキストを設定する前に、次のタスクを完了する必要があります。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の TLS コンテキストを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml ``` 2. TLS コンテキスト設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /usr/local/share/mulesoft/flex-gateway/conf.d/tls-config.yaml ``` 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
3. ポリシーが正しく適用されていることを確認します。 次のサンプル ​`curl`​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。 ```ssh curl https://:/get --cacert -v ``` コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​`200`​ が返されることを確認してください。 \* TLSv1.3 (OUT), TLS handshake, Client hello (1): \* TLSv1.3 (IN), TLS handshake, Server hello (2): \* TLSv1.2 (IN), TLS handshake, Certificate (11): \* TLSv1.2 (IN), TLS handshake, Server key exchange (12): \* TLSv1.2 (IN), TLS handshake, Server finished (14): \* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): \* TLSv1.2 (OUT), TLS change cipher, Client hello (1): \* TLSv1.2 (OUT), TLS handshake, Finished (20): \* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 \* ALPN, server did not agree to a protocol ... > HTTP/1.1 200 OK インバウンド mTLS の場合、次の例の ​`curl`​ コマンドは、ベースパスが ​`/`​である API プロキシを要求します。 ```ssh curl https://:/get \ --cert \ --key \ --cacert \ --resolve ::127.0.0.1 -v ```

設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
## [](#docker)Docker コンテナで Flex Gateway の TLS コンテキストを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、TLS コンテキストの詳細を使用して ​`app`​ フォルダーに保存します。 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
5. ポリシーが正しく適用されていることを確認します。 次のサンプル ​`curl`​ コマンドは、ポリシーバインド設定リソースで指定されている証明書と一致する証明書を使用して、HTTPS エンドポイントをテストします。 ```ssh curl https://:/get --cacert -v ``` コマンドから、TLS ハンドシェイクに関する情報と、エンドポイントの HTTP 状態として ​`200`​ が返されることを確認してください。 \* TLSv1.3 (OUT), TLS handshake, Client hello (1): \* TLSv1.3 (IN), TLS handshake, Server hello (2): \* TLSv1.2 (IN), TLS handshake, Certificate (11): \* TLSv1.2 (IN), TLS handshake, Server key exchange (12): \* TLSv1.2 (IN), TLS handshake, Server finished (14): \* TLSv1.2 (OUT), TLS handshake, Client key exchange (16): \* TLSv1.2 (OUT), TLS change cipher, Client hello (1): \* TLSv1.2 (OUT), TLS handshake, Finished (20): \* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 \* ALPN, server did not agree to a protocol ... > HTTP/1.1 200 OK インバウンド mTLS の場合、次の例の ​`curl`​ コマンドは、ベースパスが ​`/`​である API プロキシを要求します。 ```ssh curl https://:/get \ --cert \ --key \ --cacert \ --resolve ::127.0.0.1 -v ```

設定の ​key​ と ​crt​ の値が正しくインデントされていない場合、エンドポイントをテストしようとすると、​curl​ は次のエラーを返します。

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
## [](#kubernetes)Kubernetes クラスターで Flex Gateway の TLS コンテキストを設定する Flex Gateway の TLS コンテキストを設定するには、YAML 設定ファイルと TLS コンテキストの詳細を使用して新しいリソースを作成します。 次の設定ファイルは、インバウンド TLS を 1 つの API インスタンスにのみ適用します。mTLS やアウトバウンド TLS などのすべての設定ファイルオプションについては、以下を参照してください。 - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls-outbound) **特定の API インスタンスのインバウンド TLS コンテキストを追加するためのサンプル設定:** ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-https-tls spec: targetRef: kind: ApiInstance name: ingress-https policyRef: name: tls config: certificate: key: | # -----BEGIN PRIVATE KEY----- # insert certificate key # -----END PRIVATE KEY----- crt: | # -----BEGIN CERTIFICATE----- # insert certificate # -----END CERTIFICATE----- alpn: - http/1.1 - h2 minversion: "1.1" maxversion: "1.3" ciphers: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA ```

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
## [](#local-support)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合、設定ファイルにリストされている暗号化に関係なく、TLS 1.3 のデフォルトの暗号化がすべてサポートされます。TLS 1.3 をサポートしない場合、これらの暗号化は含まれません。 TLS 1.2 の場合、暗号化をリストすると、TLS 1.2 のデフォルトの暗号化が上書きされます。デフォルトの TLS 1.2 暗号化以外の暗号化をリストする場合は、サポートするデフォルトの暗号化を含め、サポートするすべての暗号化をリストする必要があります。サポートされる暗号化のリストからデフォルトの暗号化を除外すると、それらの暗号化はサポートされなくなります。デフォルトの暗号化のみをサポートする場合は、暗号化リストを空白のままにします。暗号化をリストしても、デフォルトの TLS 1.3 暗号化には影響しません。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートするには、サポートする暗号化をリストする必要があります。TLS 1.1 および TLS 1.2 をサポートする場合、TLS 1.1 暗号をリストすると、TLS 1.2 のデフォルトが上書きされます。これらのバージョンの両方をサポートするには、サポートするすべての暗号化をリストします。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンがアップストリームサービスでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS_AES_128_GCM_SHA256

1.3

はい

セキュア

TLS_AES_256_GCM_SHA384

1.3

はい

セキュア

TLS_CHACHA20_POLY1305_SHA256

1.3

はい

セキュア

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

1.2

はい

推奨

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

推奨

TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

1.2

いいえ

推奨

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

1.2

はい

セキュア

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

1.2

はい

セキュア

TLS_RSA_WITH_AES_128_GCM_SHA256

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_GCM_SHA384

1.2

いいえ

脆弱

TLS_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

1.1、1.2

いいえ

脆弱

TLS_RSA_WITH_3DES_EDE_CBC_SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) - [Transport Layer Security ポリシー - アウトバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls-outbound) # ローカルモードでの Flex Gateway のカスタムポリシーのデプロイ **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 WebAssembly (WASM) 拡張機能を使用して、Envoy 上でカスタム検索条件として機能するカスタムポリシーを実装できます。次の手順は、ローカルモードで実行されている API にカスタム検索条件 (ポリシー) をデプロイおよび適用する方法を示しています。 1. 設定 YAML ファイルを作成します。 2. ファイルを Flex Gateway 設定ディレクトリに保存します。 3. 拡張機能定義を作成します。 4. `base64`​ を使用して、カスタムポリシー WASM 実装をエンコードします。 5. 拡張機能定義をカスタムポリシー WASM バイナリ実装にリンクします。 6. カスタムポリシーを API インスタンスにリンクします。 7. リソースを Flex Gateway インスタンスに適用します。 ## [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。例については、[ローカルモードでのシンプルな API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-simple-api)を参照してください。 - カスタムポリシーが実装およびコンパイルされている。[Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-flex-implement-rust)を参照してください。 ## [](#カスタムポリシーのデプロイ)カスタムポリシーのデプロイ 1. `custom-policy-example.yaml`​ という設定ファイルを作成します。 2. ファイルを Flex Gateway 設定ディレクトリに保存します。次に例を示します。 - `/etc/mulesoft/flex-gateway/conf.d/policies` 3. 拡張機能定義を作成します。 次の YAML スニペットをコピーして、新しい設定ファイルに貼り付けます。YAML は、カスタムポリシーの設定とメタデータプロパティを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-definition spec: extends: - name: extension-authentication - name: extension-definition properties: secret-value: type: string required: - secret-value ``` - `metadata.name`​ 値には、拡張機能名が含まれます。 - `Extension`​ は、他の定義済み拡張機能からプロパティを継承します。たとえば、​`spec.extends`​ は、拡張機能が ​`extension-definition`​ であり、​`authentication`​ カテゴリ (​`extension-authentication`​) に属していることを指定します。 - `spec.properties`​ 値は、カスタムポリシーインスタンスを設定するプロパティを定義します。 - `spec.required`​ 値は、必要なプロパティを指定します。 4. `base64`​ を使用して、カスタムポリシー WASM バイナリ実装をエンコードします。 次のコマンドを実行して、カスタムポリシー WASM バイナリ実装をエンコードします。 ```ssh base64 .wasm | tr -d '\n\r' > policy ``` このコマンドは、エンコードデータを ​`policy`​ というファイルに送信します。次のステップで、​``​ をこのエンコードデータに置き換えます。

wasm32-unknown-unknown​ の対象を使用してポリシーをコンパイルした場合、​./target/wasm32-unknown-unknown/release​ にバイナリがあります。

wasm32-wasi​ の対象を使用してポリシーをコンパイルした場合、​./target/wasm32-wasi/release​ にバイナリがあります。
5. 拡張機能定義をカスタムポリシー WASM バイナリ実装にリンクします。 `custom-policy-example.yaml`​ で、ポリシー実装を含む別のリソースを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-flex spec: extends: - name: custom-local-example-definition - name: envoy-filter - name: proxy-wasm-filter properties: rootId: type: string default: main implementation: type: string default: base64:// ``` - `metadata.name`​ 値にはポリシー名が含まれます。これは、定義で指定された名前とは異なる必要があります。 - `spec.extends`​ 値は、継承元のリソース定義を指定します。たとえば、​`custom-local-example-definition`​ は以前に定義されたリソースです。 - `spec.properties.implementation.default`​ の ​``​ 値を、以前に生成した ​`base64`​ エンコード WASM バイナリデータに置き換えます。

ポリシー定義と実装を同じ ​Extension​ リソースに含めることができますが、これにより、それらの間の結合がより緊密になります。したがって、その 2 つは別のリソースに分離することをお勧めします。
6. カスタムポリシーを API インスタンスにリンクします。 `custom-policy-example.yaml`​ で、ポリシーを API インスタンスにリンクする別のリソースを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: custom-local-example spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: custom-local-example-flex config: secret-value: "an-example-value" ``` - `metadata.name`​ 値には、カスタムポリシーインスタンス名が含まれます。 - `spec.targetRef.name`​ 値には、カスタムポリシーを適用する API インスタンスの名前が含まれます。API インスタンスはすでに定義済みで、適用されている必要があります。 - `spec.policyRef.name`​ 値には、適用するカスタムポリシー実装が含まれます。 - `spec.config`​ 値には、ポリシー設定データが含まれます。 7. リソースを Flex Gateway インスタンスに適用します。 完全な ​`custom-policy-example.yaml`​ ファイルに次の内容が含まれるようになります。 ```yaml --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-definition spec: extends: - name: extension-authentication - name: extension-definition properties: secret-value: type: string required: - secret-value --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-flex spec: extends: - name: custom-local-example-definition - name: envoy-filter - name: proxy-wasm-filter properties: rootId: type: string default: main implementation: type: string default: base64:// --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: custom-local-example spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: custom-local-example-flex config: secret-value: "an-example-value" ``` ファイルを Flex Gateway 設定ディレクトリに保存します。次に例を示します。 - `/etc/mulesoft/flex-gateway/conf.d/policies` これで、カスタムポリシーが ​`ingress-http`​ という API インスタンスに適用されます。 ## [](#関連情報)関連情報 - [Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-flex-implement-rust) - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide) # ローカルモードでの Flex Gateway のカスタムポリシーのデプロイ **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 WebAssembly (WASM) 拡張機能を使用して、Envoy 上でカスタム検索条件として機能するカスタムポリシーを実装できます。次の手順は、ローカルモードで実行されている API にカスタム検索条件 (ポリシー) をデプロイおよび適用する方法を示しています。 1. 設定 YAML ファイルを作成します。 2. ファイルを Flex Gateway 設定ディレクトリに保存します。 3. 拡張機能定義を作成します。 4. `base64`​ を使用して、カスタムポリシー WASM 実装をエンコードします。 5. 拡張機能定義をカスタムポリシー WASM バイナリ実装にリンクします。 6. カスタムポリシーを API インスタンスにリンクします。 7. リソースを Flex Gateway インスタンスに適用します。 ## [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。例については、[ローカルモードでのシンプルな API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-simple-api)を参照してください。 - カスタムポリシーが実装およびコンパイルされている。[Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-flex-implement-rust)を参照してください。 ## [](#カスタムポリシーのデプロイ)カスタムポリシーのデプロイ 1. `custom-policy-example.yaml`​ という設定ファイルを作成します。 2. ファイルを Flex Gateway 設定ディレクトリに保存します。次に例を示します。 - `/etc/mulesoft/flex-gateway/conf.d/policies` 3. 拡張機能定義を作成します。 次の YAML スニペットをコピーして、新しい設定ファイルに貼り付けます。YAML は、カスタムポリシーの設定とメタデータプロパティを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-definition spec: extends: - name: extension-authentication - name: extension-definition properties: secret-value: type: string required: - secret-value ``` - `metadata.name`​ 値には、拡張機能名が含まれます。 - `Extension`​ は、他の定義済み拡張機能からプロパティを継承します。たとえば、​`spec.extends`​ は、拡張機能が ​`extension-definition`​ であり、​`authentication`​ カテゴリ (​`extension-authentication`​) に属していることを指定します。 - `spec.properties`​ 値は、カスタムポリシーインスタンスを設定するプロパティを定義します。 - `spec.required`​ 値は、必要なプロパティを指定します。 4. `base64`​ を使用して、カスタムポリシー WASM バイナリ実装をエンコードします。 次のコマンドを実行して、カスタムポリシー WASM バイナリ実装をエンコードします。 ```ssh base64 .wasm | tr -d '\n\r' > policy ``` このコマンドは、エンコードデータを ​`policy`​ というファイルに送信します。次のステップで、​``​ をこのエンコードデータに置き換えます。

wasm32-unknown-unknown​ の対象を使用してポリシーをコンパイルした場合、​./target/wasm32-unknown-unknown/release​ にバイナリがあります。

wasm32-wasi​ の対象を使用してポリシーをコンパイルした場合、​./target/wasm32-wasi/release​ にバイナリがあります。
5. 拡張機能定義をカスタムポリシー WASM バイナリ実装にリンクします。 `custom-policy-example.yaml`​ で、ポリシー実装を含む別のリソースを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-flex spec: extends: - name: custom-local-example-definition - name: envoy-filter - name: proxy-wasm-filter properties: rootId: type: string default: main implementation: type: string default: base64:// ``` - `metadata.name`​ 値にはポリシー名が含まれます。これは、定義で指定された名前とは異なる必要があります。 - `spec.extends`​ 値は、継承元のリソース定義を指定します。たとえば、​`custom-local-example-definition`​ は以前に定義されたリソースです。 - `spec.properties.implementation.default`​ の ​``​ 値を、以前に生成した ​`base64`​ エンコード WASM バイナリデータに置き換えます。

ポリシー定義と実装を同じ ​Extension​ リソースに含めることができますが、これにより、それらの間の結合がより緊密になります。したがって、その 2 つは別のリソースに分離することをお勧めします。
6. カスタムポリシーを API インスタンスにリンクします。 `custom-policy-example.yaml`​ で、ポリシーを API インスタンスにリンクする別のリソースを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: custom-local-example spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: custom-local-example-flex config: secret-value: "an-example-value" ``` - `metadata.name`​ 値には、カスタムポリシーインスタンス名が含まれます。 - `spec.targetRef.name`​ 値には、カスタムポリシーを適用する API インスタンスの名前が含まれます。API インスタンスはすでに定義済みで、適用されている必要があります。 - `spec.policyRef.name`​ 値には、適用するカスタムポリシー実装が含まれます。 - `spec.config`​ 値には、ポリシー設定データが含まれます。 7. リソースを Flex Gateway インスタンスに適用します。 完全な ​`custom-policy-example.yaml`​ ファイルに次の内容が含まれるようになります。 ```yaml --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-definition spec: extends: - name: extension-authentication - name: extension-definition properties: secret-value: type: string required: - secret-value --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-flex spec: extends: - name: custom-local-example-definition - name: envoy-filter - name: proxy-wasm-filter properties: rootId: type: string default: main implementation: type: string default: base64:// --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: custom-local-example spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: custom-local-example-flex config: secret-value: "an-example-value" ``` ファイルを Flex Gateway 設定ディレクトリに保存します。次に例を示します。 - `/etc/mulesoft/flex-gateway/conf.d/policies` これで、カスタムポリシーが ​`ingress-http`​ という API インスタンスに適用されます。 ## [](#関連情報)関連情報 - [Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-flex-implement-rust) - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide) # ローカルモードでの Flex Gateway のカスタムポリシーのデプロイ **新機能があります**​: この製品機能は最新ではなく、既存のカスタムポリシーのためにのみ提供されています。新しいカスタムポリシーを作成するには、​[Flex Gateway Policy Development Kit (PDK)](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)​ を使用してください。 WebAssembly (WASM) 拡張機能を使用して、Envoy 上でカスタム検索条件として機能するカスタムポリシーを実装できます。次の手順は、ローカルモードで実行されている API にカスタム検索条件 (ポリシー) をデプロイおよび適用する方法を示しています。 1. 設定 YAML ファイルを作成します。 2. ファイルを Flex Gateway 設定ディレクトリに保存します。 3. 拡張機能定義を作成します。 4. `base64`​ を使用して、カスタムポリシー WASM 実装をエンコードします。 5. 拡張機能定義をカスタムポリシー WASM バイナリ実装にリンクします。 6. カスタムポリシーを API インスタンスにリンクします。 7. リソースを Flex Gateway インスタンスに適用します。 ## [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。例については、[ローカルモードでのシンプルな API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-simple-api)を参照してください。 - カスタムポリシーが実装およびコンパイルされている。[Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-flex-implement-rust)を参照してください。 ## [](#カスタムポリシーのデプロイ)カスタムポリシーのデプロイ 1. `custom-policy-example.yaml`​ という設定ファイルを作成します。 2. ファイルを Flex Gateway 設定ディレクトリに保存します。次に例を示します。 - `/etc/mulesoft/flex-gateway/conf.d/policies` 3. 拡張機能定義を作成します。 次の YAML スニペットをコピーして、新しい設定ファイルに貼り付けます。YAML は、カスタムポリシーの設定とメタデータプロパティを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-definition spec: extends: - name: extension-authentication - name: extension-definition properties: secret-value: type: string required: - secret-value ``` - `metadata.name`​ 値には、拡張機能名が含まれます。 - `Extension`​ は、他の定義済み拡張機能からプロパティを継承します。たとえば、​`spec.extends`​ は、拡張機能が ​`extension-definition`​ であり、​`authentication`​ カテゴリ (​`extension-authentication`​) に属していることを指定します。 - `spec.properties`​ 値は、カスタムポリシーインスタンスを設定するプロパティを定義します。 - `spec.required`​ 値は、必要なプロパティを指定します。 4. `base64`​ を使用して、カスタムポリシー WASM バイナリ実装をエンコードします。 次のコマンドを実行して、カスタムポリシー WASM バイナリ実装をエンコードします。 ```ssh base64 .wasm | tr -d '\n\r' > policy ``` このコマンドは、エンコードデータを ​`policy`​ というファイルに送信します。次のステップで、​``​ をこのエンコードデータに置き換えます。

wasm32-unknown-unknown​ の対象を使用してポリシーをコンパイルした場合、​./target/wasm32-unknown-unknown/release​ にバイナリがあります。

wasm32-wasi​ の対象を使用してポリシーをコンパイルした場合、​./target/wasm32-wasi/release​ にバイナリがあります。
5. 拡張機能定義をカスタムポリシー WASM バイナリ実装にリンクします。 `custom-policy-example.yaml`​ で、ポリシー実装を含む別のリソースを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-flex spec: extends: - name: custom-local-example-definition - name: envoy-filter - name: proxy-wasm-filter properties: rootId: type: string default: main implementation: type: string default: base64:// ``` - `metadata.name`​ 値にはポリシー名が含まれます。これは、定義で指定された名前とは異なる必要があります。 - `spec.extends`​ 値は、継承元のリソース定義を指定します。たとえば、​`custom-local-example-definition`​ は以前に定義されたリソースです。 - `spec.properties.implementation.default`​ の ​``​ 値を、以前に生成した ​`base64`​ エンコード WASM バイナリデータに置き換えます。

ポリシー定義と実装を同じ ​Extension​ リソースに含めることができますが、これにより、それらの間の結合がより緊密になります。したがって、その 2 つは別のリソースに分離することをお勧めします。
6. カスタムポリシーを API インスタンスにリンクします。 `custom-policy-example.yaml`​ で、ポリシーを API インスタンスにリンクする別のリソースを定義します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: custom-local-example spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: custom-local-example-flex config: secret-value: "an-example-value" ``` - `metadata.name`​ 値には、カスタムポリシーインスタンス名が含まれます。 - `spec.targetRef.name`​ 値には、カスタムポリシーを適用する API インスタンスの名前が含まれます。API インスタンスはすでに定義済みで、適用されている必要があります。 - `spec.policyRef.name`​ 値には、適用するカスタムポリシー実装が含まれます。 - `spec.config`​ 値には、ポリシー設定データが含まれます。 7. リソースを Flex Gateway インスタンスに適用します。 完全な ​`custom-policy-example.yaml`​ ファイルに次の内容が含まれるようになります。 ```yaml --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-definition spec: extends: - name: extension-authentication - name: extension-definition properties: secret-value: type: string required: - secret-value --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Extension metadata: name: custom-local-example-flex spec: extends: - name: custom-local-example-definition - name: envoy-filter - name: proxy-wasm-filter properties: rootId: type: string default: main implementation: type: string default: base64:// --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: custom-local-example spec: targetRef: kind: ApiInstance name: ingress-http policyRef: kind: Extension name: custom-local-example-flex config: secret-value: "an-example-value" ``` ファイルを Flex Gateway 設定ディレクトリに保存します。次に例を示します。 - `/etc/mulesoft/flex-gateway/conf.d/policies` これで、カスタムポリシーが ​`ingress-http`​ という API インスタンスに適用されます。 ## [](#関連情報)関連情報 - [Rust での Flex Gateway カスタムポリシーの実装](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-flex-implement-rust) - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide) # ローカルモードでの Flex Gateway のレプリカの設定

20%

25%

Linux サービスとしての Flex レプリカの追加

Docker コンテナでの Flex レプリカの追加
## [](#flex-レプリカ)Flex レプリカ Flex レプリカとは、Flex Gateway のインスタンスです。複数の Flex Gateway レプリカでゲートウェイレイヤーをセットアップすることにより、Flex Gateway にデプロイされる API は多くのトラフィックを処理できるようになります。 Flex Gateway を使用して本番環境で API を管理する場合は、単一障害点を回避するために、複数の Flex レプリカを設定します。複数の Flex レプリカを実行することで、API サービスが大量のトラフィックを受け取った場合でも高いパフォーマンスを維持できます。 ## [](#始める前に)始める前に 開始する前に、以下のタスクが完了していることを確認してください。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [ローカルモードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) ## [](#linux-サービスとしての-flex-レプリカの追加)Linux サービスとしての Flex レプリカの追加 Flex レプリカを Linux サービスとして追加するには、以下のタスクを実行します。 - Linux マシンまたは VM への登録時に作成された登録ファイルをコピーして貼り付ける。 - Flex Gateway の開始コマンドを実行する。 ### [](#登録ファイルのコピー)登録ファイルのコピー Linux マシンまたは VM の次の場所に ​`registration.yaml`​ ファイルをコピーします。 - `/usr/local/share/mulesoft/flex-gateway/conf.d` ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#docker)Docker コンテナでの Flex レプリカの追加 Docker コンテナで Flex レプリカを追加するには、登録時に作成したのと同じ ​`registration.yaml`​ ファイルを使用して、Flex Gateway を開始するためのコマンドを実行する必要があります。コンテナをローカルに実行している場合は、別のポートを使用する必要もあります。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
# ローカルモードでの Flex Gateway のレプリカの設定

20%

25%

Linux サービスとしての Flex レプリカの追加

Docker コンテナでの Flex レプリカの追加
## [](#flex-レプリカ)Flex レプリカ Flex レプリカとは、Flex Gateway のインスタンスです。複数の Flex Gateway レプリカでゲートウェイレイヤーをセットアップすることにより、Flex Gateway にデプロイされる API は多くのトラフィックを処理できるようになります。 Flex Gateway を使用して本番環境で API を管理する場合は、単一障害点を回避するために、複数の Flex レプリカを設定します。複数の Flex レプリカを実行することで、API サービスが大量のトラフィックを受け取った場合でも高いパフォーマンスを維持できます。 ## [](#始める前に)始める前に 開始する前に、以下のタスクが完了していることを確認してください。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [ローカルモードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) ## [](#linux-サービスとしての-flex-レプリカの追加)Linux サービスとしての Flex レプリカの追加 Flex レプリカを Linux サービスとして追加するには、以下のタスクを実行します。 - Linux マシンまたは VM への登録時に作成された登録ファイルをコピーして貼り付ける。 - Flex Gateway の開始コマンドを実行する。 ### [](#登録ファイルのコピー)登録ファイルのコピー Linux マシンまたは VM の次の場所に ​`registration.yaml`​ ファイルをコピーします。 - `/usr/local/share/mulesoft/flex-gateway/conf.d` ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#docker)Docker コンテナでの Flex レプリカの追加 Docker コンテナで Flex レプリカを追加するには、登録時に作成したのと同じ ​`registration.yaml`​ ファイルを使用して、Flex Gateway を開始するためのコマンドを実行する必要があります。コンテナをローカルに実行している場合は、別のポートを使用する必要もあります。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
# ローカルモードでの Flex Gateway のレプリカの設定

20%

25%

Linux サービスとしての Flex レプリカの追加

Docker コンテナでの Flex レプリカの追加
## [](#flex-レプリカ)Flex レプリカ Flex レプリカとは、Flex Gateway のインスタンスです。複数の Flex Gateway レプリカでゲートウェイレイヤーをセットアップすることにより、Flex Gateway にデプロイされる API は多くのトラフィックを処理できるようになります。 Flex Gateway を使用して本番環境で API を管理する場合は、単一障害点を回避するために、複数の Flex レプリカを設定します。複数の Flex レプリカを実行することで、API サービスが大量のトラフィックを受け取った場合でも高いパフォーマンスを維持できます。 ## [](#始める前に)始める前に 開始する前に、以下のタスクが完了していることを確認してください。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [ローカルモードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) ## [](#linux-サービスとしての-flex-レプリカの追加)Linux サービスとしての Flex レプリカの追加 Flex レプリカを Linux サービスとして追加するには、以下のタスクを実行します。 - Linux マシンまたは VM への登録時に作成された登録ファイルをコピーして貼り付ける。 - Flex Gateway の開始コマンドを実行する。 ### [](#登録ファイルのコピー)登録ファイルのコピー Linux マシンまたは VM の次の場所に ​`registration.yaml`​ ファイルをコピーします。 - `/usr/local/share/mulesoft/flex-gateway/conf.d` ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#docker)Docker コンテナでの Flex レプリカの追加 Docker コンテナで Flex レプリカを追加するには、登録時に作成したのと同じ ​`registration.yaml`​ ファイルを使用して、Flex Gateway を開始するためのコマンドを実行する必要があります。コンテナをローカルに実行している場合は、別のポートを使用する必要もあります。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
# ローカルモードでの Flex Gateway の共有ストレージの設定

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
分散キャッシュ、ゲートウェイ設定コーチング (接続モード)、レート制限ポリシーの共有ストレージを有効にします。Redis では、キャッシュ用の追加メモリも提供されます。 本番ワークフローでは [Redis](https://redis.io/)​ を使用する必要があります。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。分散ポリシーでデータを共有するように Redis を設定する必要があります。その他のすべてのポリシーでは、ストレージにレプリカメモリを使用します。 カスタム YAML ファイルを介して共有ストレージを設定します。 次の手順は、Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の Redis ベースのストレージサポートを示しています。 Redis Sentinel、または Redis 共有ストレージへの TLS 接続を設定するには、以下を参照してください。 - [Redis Sentinel の設定](#redis-sentinel) - [Redis ベースの共有ストレージ用の TLS の設定](#redis-tls)

20%

25%

20%

Linux サービスとして Flex Gateway の共有ストレージを設定する

Docker コンテナで Flex Gateway の共有ストレージを設定する

Kubernetes クラスターで Flex Gateway の共有ストレージを設定する
## [](#始める前に)始める前に Flex Gateway の共有ストレージを設定する前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の共有ストレージを設定する 1. `/etc/mulesoft/flex-gateway/conf.d`​ ディレクトリにフォルダーを作成し、​`custom`​ という名前を付けます。 ```ssh sudo mkdir /etc/mulesoft/flex-gateway/conf.d/custom ``` 2. `custom`​ フォルダーに YAML 設定ファイルを作成します。 ```ssh sudo touch /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` 3. Redis ストレージ設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#docker)Docker コンテナで Flex Gateway の共有ストレージを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Flex Gateway とすべてのレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、共有ストレージの詳細を使用して ​`app`​ フォルダーに保存します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の共有ストレージを設定する Flex Gateway の共有ストレージを設定するには、YAML 設定ファイルとストレージの詳細を使用して新しいリソースを作成します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#redis-sentinel)Redis Sentinel の設定 Redis Sentinel では、Redis 共有ストレージ用の高可用性が提供されます。Redis Sentinel についての詳細は、 [「Redis Sentinel」](https://redis.io/docs/management/sentinel/)​を参照してください。 前のセクションで説明した手順を使用して Redis Sentinel を設定します。 Redis Sentinel を追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage namespace: test-ns spec: sharedStorage: redis: username: "user" password: "pass" sentinel: addresses: - internal.redis.com:6379 masterName: "name" password: "pass" db: 0 ``` ## [](#redis-tls)Redis ベースの共有ストレージ用の TLS の設定 TLS と Redis を使用して、Flex Gateway と Redis インスタンス間のデータセキュリティを確保します。TLS を設定することで、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。さらに、TLS を設定すれば、組織はコンプライアンス要件を満たしてユーザーの信頼を築きやすくなります。 TLS は Redis と Redis Sentinel の両方と連携します。 前のセクションで説明した手順を使用して Redis ベースの共有ストレージ用に TLS を設定します。 TLS を使用して Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` パラメーターの設定については、​[「Declarative Configuration Reference (Shared Storage) (宣言型設定リファレンス (共有ストレージ))」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide#shared-storage)​を参照してください。 ## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config) - [宣言型設定リファレンス](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide#shared-storage) # ローカルモードでの Flex Gateway の共有ストレージの設定

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。Redis では、キャッシュ用の追加メモリも提供されます。 本番ワークフローでは [Redis](https://redis.io/)​ を使用する必要があります。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。分散ポリシーでデータを共有するように Redis を設定する必要があります。その他のすべてのポリシーでは、ストレージにレプリカメモリを使用します。 カスタム YAML ファイルを介して共有ストレージを設定します。 次の手順は、Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の Redis ベースのストレージサポートを示しています。 Redis Sentinel、または Redis 共有ストレージへの TLS 接続を設定するには、以下を参照してください。 - [Redis Sentinel の設定](#redis-sentinel) - [Redis ベースの共有ストレージ用の TLS の設定](#redis-tls)

20%

25%

20%

Linux サービスとして Flex Gateway の共有ストレージを設定する

Docker コンテナで Flex Gateway の共有ストレージを設定する

Kubernetes クラスターで Flex Gateway の共有ストレージを設定する
## [](#始める前に)始める前に Flex Gateway の共有ストレージを設定する前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の共有ストレージを設定する 1. `/etc/mulesoft/flex-gateway/conf.d`​ ディレクトリにフォルダーを作成し、​`custom`​ という名前を付けます。 ```ssh sudo mkdir /etc/mulesoft/flex-gateway/conf.d/custom ``` 2. `custom`​ フォルダーに YAML 設定ファイルを作成します。 ```ssh sudo touch /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` 3. Redis ストレージ設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#docker)Docker コンテナで Flex Gateway の共有ストレージを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Flex Gateway とすべてのレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、共有ストレージの詳細を使用して ​`app`​ フォルダーに保存します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の共有ストレージを設定する Flex Gateway の共有ストレージを設定するには、YAML 設定ファイルとストレージの詳細を使用して新しいリソースを作成します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#redis-sentinel)Redis Sentinel の設定 Redis Sentinel では、Redis 共有ストレージ用の高可用性が提供されます。Redis Sentinel についての詳細は、 [「Redis Sentinel」](https://redis.io/docs/management/sentinel/)​を参照してください。 前のセクションで説明した手順を使用して Redis Sentinel を設定します。 Redis Sentinel を追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage namespace: test-ns spec: sharedStorage: redis: username: "user" password: "pass" sentinel: addresses: - internal.redis.com:6379 masterName: "name" password: "pass" db: 0 ``` ## [](#redis-tls)Redis ベースの共有ストレージ用の TLS の設定 TLS と Redis を使用して、Flex Gateway と Redis インスタンス間のデータセキュリティを確保します。TLS を設定することで、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。さらに、TLS を設定すれば、組織はコンプライアンス要件を満たしてユーザーの信頼を築きやすくなります。 TLS は Redis と Redis Sentinel の両方と連携します。 前のセクションで説明した手順を使用して Redis ベースの共有ストレージ用に TLS を設定します。 TLS を使用して Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` パラメーターの設定については、​[「Declarative Configuration Reference (Shared Storage) (宣言型設定リファレンス (共有ストレージ))」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide#shared-storage)​を参照してください。 ## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-shared-storage-config) - [宣言型設定リファレンス](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide#shared-storage) # ローカルモードでの Flex Gateway の共有ストレージの設定

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
分散キャッシュ、ゲートウェイ設定コーチング (接続モード)、レート制限ポリシーの共有ストレージを有効にします。Redis では、キャッシュ用の追加メモリも提供されます。 本番ワークフローでは [Redis](https://redis.io/)​ を使用する必要があります。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。分散ポリシーでデータを共有するように Redis を設定する必要があります。その他のすべてのポリシーでは、ストレージにレプリカメモリを使用します。 カスタム YAML ファイルを介して共有ストレージを設定します。 次の手順は、Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の Redis ベースのストレージサポートを示しています。 Redis Sentinel、または Redis 共有ストレージへの TLS 接続を設定するには、以下を参照してください。 - [Redis Sentinel の設定](#redis-sentinel) - [Redis ベースの共有ストレージ用の TLS の設定](#redis-tls)

20%

25%

20%

Linux サービスとして Flex Gateway の共有ストレージを設定する

Docker コンテナで Flex Gateway の共有ストレージを設定する

Kubernetes クラスターで Flex Gateway の共有ストレージを設定する
## [](#始める前に)始める前に Flex Gateway の共有ストレージを設定する前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の共有ストレージを設定する 1. `/etc/mulesoft/flex-gateway/conf.d`​ ディレクトリにフォルダーを作成し、​`custom`​ という名前を付けます。 ```ssh sudo mkdir /etc/mulesoft/flex-gateway/conf.d/custom ``` 2. `custom`​ フォルダーに YAML 設定ファイルを作成します。 ```ssh sudo touch /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` 3. Redis ストレージ設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#docker)Docker コンテナで Flex Gateway の共有ストレージを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Flex Gateway とすべてのレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、共有ストレージの詳細を使用して ​`app`​ フォルダーに保存します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の共有ストレージを設定する Flex Gateway の共有ストレージを設定するには、YAML 設定ファイルとストレージの詳細を使用して新しいリソースを作成します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#redis-sentinel)Redis Sentinel の設定 Redis Sentinel では、Redis 共有ストレージ用の高可用性が提供されます。Redis Sentinel についての詳細は、 [「Redis Sentinel」](https://redis.io/docs/management/sentinel/)​を参照してください。 前のセクションで説明した手順を使用して Redis Sentinel を設定します。 Redis Sentinel を追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage namespace: test-ns spec: sharedStorage: redis: username: "user" password: "pass" sentinel: addresses: - internal.redis.com:6379 masterName: "name" password: "pass" db: 0 ``` ## [](#redis-tls)Redis ベースの共有ストレージ用の TLS の設定 TLS と Redis を使用して、Flex Gateway と Redis インスタンス間のデータセキュリティを確保します。TLS を設定することで、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。さらに、TLS を設定すれば、組織はコンプライアンス要件を満たしてユーザーの信頼を築きやすくなります。 TLS は Redis と Redis Sentinel の両方と連携します。 前のセクションで説明した手順を使用して Redis ベースの共有ストレージ用に TLS を設定します。 TLS を使用して Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` パラメーターの設定については、​[「Declarative Configuration Reference (Shared Storage) (宣言型設定リファレンス (共有ストレージ))」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide#shared-storage)​を参照してください。 ## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config) - [宣言型設定リファレンス](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide#shared-storage) # ローカルモードでの Flex Gateway の外部ログの設定 Anypoint Flex Gatewa を使用すると、サポートされている Fluent Bit v3.2.10 出力種別にランタイムとアクセスログを配信できます。カスタム YAML ファイルを介してログ出力を設定します。さらに、アクセスログを表示するには、メッセージログポリシーも適用する必要があります。 次の設定ファイルの例は、Flex Gateway ログを出力種別 (​`File`​、​`HTTP`​、および ​`Splunk`​) に送信する方法を示しています。ただし、​`Azure Log Analytics`​、​`Amazon S3`​、​`Kafka`​ など、任意の Fluent Bit v3.2.10 出力種別を使用できます。Fluent Bit 出力種別の完全なリストについては、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 追加の Fluent Bit ログ出力種別を設定できるだけでなく、Flex Gateway は標準出力ログを維持します。追加のログ出力が必要ない場合は、標準出力ログを簡単なチェックに使用します。標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/gateway/latest/local-view-logs)​を参照してください。ランタイムログとアクセスログの両方は、標準出力ログに表示されます。ただし、アクセスログはメッセージログポリシーを適用した場合にのみ存在します。

20%

25%

20%

Linux サービスとして Flex Gateway のログ出力を設定する

Docker コンテナで Flex Gateway のログ出力を設定する

Kubernetes クラスターで Flex Gateway のログ出力を設定する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) さらに、出力に応じて、ログの送信先のサービスが動作していて、必要な情報が揃っていることを確認します。 - Splunk: - 実行中の [Splunk](https://www.splunk.com/)​ サービス。無料の Splunk Cloud トライアルを使用して Splunk をテストできます。 - Cloud または Enterprise Splunk サービスに HTTP イベントコレクター (HEC) データ入力を追加済み。データ入力を追加する方法と HEC トークンを作成する方法については、 [Splunk ドキュメント](https://docs.splunk.com/Documentation/Splunk/7.0.3/Data/UsetheHTTPEventCollector)​ を参照してください。 - Dynatrace: - 実行中の [Dynatrace](https://www.dynatrace.com/)​ サービス。無料の Dynatrace トライアルを使用して Dynatrace をテストできます。 - 環境 ID。Dynatrace 環境 ID の見つけ方については、 [「環境 ID」](https://www.dynatrace.com/support/help/get-started/monitoring-environment/environment-id)​を参照してください。 - アクセストークン。Dynatrace アクセストークンを生成するには、 [「アクセストークン」](https://www.dynatrace.com/support/help/manage/access-control/access-tokens)​を参照してください。トークンに ​`Ingest logs`​ トークンスコープがあることを確認します。 ## [](#ランタイムログとアクセスログ)ランタイムログとアクセスログ ランタイムログとアクセスログの両方は、同じログ出力に表示されます。ただし、両方のログをログ出力に含めるかどうかを選択できます。アクセスログを使用するには、メッセージログポリシーも適用する必要があります。 ### [](#ランタイムログ)ランタイムログ ランタイムログには、次の情報が含まれます。 - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン - デプロイされた API とポリシー - Flex Gateway の設定ミスの可能性またはその他のエラー ### [](#アクセスログ)アクセスログ アクセスログには、一定期間の Envoy との受信インタラクション、および特定の API に対する受信要求と応答が示されます。 アクセスログを有効にするには、監視する API インスタンスにメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](#configure-access-logs)​を参照してください。 ## [](#ログ設定ファイル)ログ設定ファイル `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.2.10 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
適用された値を含む設定ファイルを確認するには、次の設定ファイルの例を参照してください。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ## [](#linux)Linux サービスとして Flex Gateway のログ出力を設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/logs-config.yaml ``` 2. 次の例に示すように、目的の出力設定の詳細でファイルを更新します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging)を参照してください。 3. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#docker)Docker コンテナで Flex Gateway のログ出力を設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 次の例に示すように、目的の出力設定の詳細を含む YAML ファイルを作成して保存します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging)を参照してください。 5. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のログ出力を設定する Flex Gateway のログを設定する手順は、次のとおりです。 1. 次の例に示すように、目的の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.10/flex-troubleshoot-logging)を参照してください。 2. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#file-configuration-example)ファイルの設定例 書式設定されたランタイムログとアクセスログを ​`/var/log`​ ディレクトリの ​`log.txt`​ という名前のファイル (Fluent Bit の ​`File`​ 出力) に送信するように Flex Gateway を設定します。この例の定義では、​`file`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: file parameters: file: /var/log/log.txt # Docker: replace `/var/log` with the absolute path to the mounted configuration directory format: template template: | [{date}][{logger}][{level}][{kind}] {message} runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ```
Docker の場合は、​spec.logging.output.parameters.file​ の ​/var/log​ を、マウントされた設定ディレクトリへの絶対パスに置き換えてください。
## [](#http-configuration-example)HTTP の設定例 書式設定されたランタイムログとアクセスログを ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。この例の定義では、​`HTTP`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: HTTP parameters: host: collectors.au.sumologic.com port: "443" URI: /receiver/v1/http/[PrivateKey] format: json_lines json_date_key: timestamp json_date_format: iso8601 runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ``` ## [](#splunk-configuration-example)Splunk の設定例 Splunk は、このリソースを適用するとすぐにログの取り込みを開始します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: splunk-config spec: logging: outputs: - name: splunk type: splunk parameters: host: .splunkcloud.com port: "8088" splunk_token: tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: [splunk] accessLogs: outputs: [splunk] ``` ## [](#dynatrace-configuration-example)Dynatrace の設定例 書式設定されたランタイムログとアクセスログを Dynatrace 環境の ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。たとえば、次のファイルには必要な設定が含まれています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: dynatrace-config spec: logging: outputs: - name: dynatrace type: http parameters: host: .live.dynatrace.com Port: "443" allow_duplicated_headers: "false" header: - Content-Type application/json; charset=utf-8 - Authorization Api-Token URI: /api/v2/logs/ingest Format: json json_date_key: timestamp json_date_format: iso8601 tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: - dynatrace accessLogs: outputs: - dynatrace ``` 設定オプションについての詳細は、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 ## [](#configure-access-logs)アクセスログの設定 ログ出力内のアクセスログを設定するには、要求および応答データの監視の対象である API にメッセージログポリシーを適用する必要があります。すでにメッセージログポリシーを API インスタンスに割り当てている場合、別のメッセージログポリシーを設定する必要はありません。 メッセージログポリシーを設定すると、アクセスログを標準出力ログとサードパーティログサービスの両方に表示できます。 メッセージログポリシーを適用するには、「​[ローカルモードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-secure-local) and use the [Message Logging Configuration Parameters](https://docs.mulesoft.com/gateway/latest/policies-included-message-logging)​」を参照してください。 アクセスログが表示されない場合、メッセージログポリシーが実行される前に、より高い実行順序を持つポリシーによってエラーが発生している可能性があります。ポリシーの実行を並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.10/policies-reorder)を参照してください。 ## [](#ログイベントの例)ログイベントの例 次のログ出力の例は、次のイベントで発生する可能性がある出力を示しています。 - [グレースフルシャットダウン](#graceful-shutdowns) - [サービス停止](#service-disconnections) - [Envoy のクラッシュ](#envoy-crash) ### [](#graceful-shutdowns)グレースフルシャットダウン \[flex-gateway-agent\]\[info\] SignalHandler: Signal terminated received \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ### [](#service-disconnections)サービス停止 \[flex-gateway-agent\]\[error\] WebSocket receiver got error: read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[warn\] Dropped connection due to error read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Reconnecting after connection was dropped \[flex-gateway-agent\]\[error\] Error connecting to Websocket Server: dial tcp: lookup arm-mcm2-service.kstg.msap.io on 192.168.65.7:53: dial udp 192.168.65.7:53: connect: network is unreachable ### [](#envoy-crash)Envoy のクラッシュ \[flex-gateway-envoy\]\[critical\] Caught Segmentation fault, suspect faulting address 0xffff87e8fb89485b \[flex-gateway-envoy\]\[critical\] Backtrace (use tools/stack\_decode.py to get line numbers): \[flex-gateway-envoy\]\[critical\] Envoy version: 36cbae1aeedd8c3b4eb88cd28268d21fe0905ce5/1.23.0/Clean/RELEASE/BoringSSL \[flex-gateway-envoy\]\[critical\] #0: \_\_restore\_rt \[0x7ff79db2f140\] \[flex-gateway-envoy\]\[critical\] #1: \[0x557dcfad249b\] \[flex-gateway-envoy\]\[critical\] #2: \[0x557dcdf35237\] \[flex-gateway-envoy\]\[critical\] #3: \[0x557dce16d49f\] \[flex-gateway-envoy\]\[critical\] #4: \[0x557dce1a8ff5\] \[flex-gateway-envoy\]\[critical\] #5: \[0x557dce1a8e47\] \[flex-gateway-envoy\]\[critical\] #6: ... \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error flex-gateway-envoy: command error: signal: segmentation fault \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ## [](#関連情報)関連情報 - [メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-message-logging) # ローカルモードでの Flex Gateway の外部ログの設定 Anypoint Flex Gatewa を使用すると、サポートされている Fluent Bit v3.0 出力種別にランタイムとアクセスログを配信できます。カスタム YAML ファイルを介してログ出力を設定します。さらに、アクセスログを表示するには、メッセージログポリシーも適用する必要があります。 次の設定ファイルの例は、Flex Gateway ログを出力種別 (​`File`​、​`HTTP`​、および ​`Splunk`​) に送信する方法を示しています。ただし、​`Azure Log Analytics`​、​`Amazon S3`​、​`Kafka`​ など、任意の Fluent Bit v3.0 出力種別を使用できます。Fluent Bit 出力種別の完全なリストについては、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 追加の Fluent Bit ログ出力種別を設定できるだけでなく、Flex Gateway は標準出力ログを維持します。追加のログ出力が必要ない場合は、標準出力ログを簡単なチェックに使用します。標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/gateway/latest/local-view-logs)​を参照してください。ランタイムログとアクセスログの両方は、標準出力ログに表示されます。ただし、アクセスログはメッセージログポリシーを適用した場合にのみ存在します。

20%

25%

20%

Linux サービスとして Flex Gateway のログ出力を設定する

Docker コンテナで Flex Gateway のログ出力を設定する

Kubernetes クラスターで Flex Gateway のログ出力を設定する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) さらに、出力に応じて、ログの送信先のサービスが動作していて、必要な情報が揃っていることを確認します。 - Splunk: - 実行中の [Splunk](https://www.splunk.com/)​ サービス。無料の Splunk Cloud トライアルを使用して Splunk をテストできます。 - Cloud または Enterprise Splunk サービスに HTTP イベントコレクター (HEC) データ入力を追加済み。データ入力を追加する方法と HEC トークンを作成する方法については、 [Splunk ドキュメント](https://docs.splunk.com/Documentation/Splunk/7.0.3/Data/UsetheHTTPEventCollector)​ を参照してください。 - Dynatrace: - 実行中の [Dynatrace](https://www.dynatrace.com/)​ サービス。無料の Dynatrace トライアルを使用して Dynatrace をテストできます。 - 環境 ID。Dynatrace 環境 ID の見つけ方については、 [「環境 ID」](https://www.dynatrace.com/support/help/get-started/monitoring-environment/environment-id)​を参照してください。 - アクセストークン。Dynatrace アクセストークンを生成するには、 [「アクセストークン」](https://www.dynatrace.com/support/help/manage/access-control/access-tokens)​を参照してください。トークンに ​`Ingest logs`​ トークンスコープがあることを確認します。 ## [](#ランタイムログとアクセスログ)ランタイムログとアクセスログ ランタイムログとアクセスログの両方は、同じログ出力に表示されます。ただし、両方のログをログ出力に含めるかどうかを選択できます。アクセスログを使用するには、メッセージログポリシーも適用する必要があります。 ### [](#ランタイムログ)ランタイムログ ランタイムログには、次の情報が含まれます。 - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン - デプロイされた API とポリシー - Flex Gateway の設定ミスの可能性またはその他のエラー ### [](#アクセスログ)アクセスログ アクセスログには、一定期間の Envoy との受信インタラクション、および特定の API に対する受信要求と応答が示されます。 アクセスログを有効にするには、監視する API インスタンスにメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](#configure-access-logs)​を参照してください。 ## [](#ログ設定ファイル)ログ設定ファイル `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.0 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
適用された値を含む設定ファイルを確認するには、次の設定ファイルの例を参照してください。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ## [](#linux)Linux サービスとして Flex Gateway のログ出力を設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/logs-config.yaml ``` 2. 次の例に示すように、目的の出力設定の詳細でファイルを更新します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging)を参照してください。 3. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#docker)Docker コンテナで Flex Gateway のログ出力を設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 次の例に示すように、目的の出力設定の詳細を含む YAML ファイルを作成して保存します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging)を参照してください。 5. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のログ出力を設定する Flex Gateway のログを設定する手順は、次のとおりです。 1. 次の例に示すように、目的の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[ログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.8/flex-troubleshoot-logging)を参照してください。 2. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#file-configuration-example)ファイルの設定例 書式設定されたランタイムログとアクセスログを ​`/var/log`​ ディレクトリの ​`log.txt`​ という名前のファイル (Fluent Bit の ​`File`​ 出力) に送信するように Flex Gateway を設定します。この例の定義では、​`file`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: file parameters: file: /var/log/log.txt # Docker: replace `/var/log` with the absolute path to the mounted configuration directory format: template template: | [{date}][{logger}][{level}][{kind}] {message} runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ```
Docker の場合は、​spec.logging.output.parameters.file​ の ​/var/log​ を、マウントされた設定ディレクトリへの絶対パスに置き換えてください。
## [](#http-configuration-example)HTTP の設定例 書式設定されたランタイムログとアクセスログを ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。この例の定義では、​`HTTP`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: HTTP parameters: host: collectors.au.sumologic.com port: "443" URI: /receiver/v1/http/[PrivateKey] format: json_lines json_date_key: timestamp json_date_format: iso8601 runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ``` ## [](#splunk-configuration-example)Splunk の設定例 Splunk は、このリソースを適用するとすぐにログの取り込みを開始します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: splunk-config spec: logging: outputs: - name: splunk type: splunk parameters: host: .splunkcloud.com port: "8088" splunk_token: tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: [splunk] accessLogs: outputs: [splunk] ``` ## [](#dynatrace-configuration-example)Dynatrace の設定例 書式設定されたランタイムログとアクセスログを Dynatrace 環境の ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。たとえば、次のファイルには必要な設定が含まれています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: dynatrace-config spec: logging: outputs: - name: dynatrace type: http parameters: host: .live.dynatrace.com Port: "443" allow_duplicated_headers: "false" header: - Content-Type application/json; charset=utf-8 - Authorization Api-Token URI: /api/v2/logs/ingest Format: json json_date_key: timestamp json_date_format: iso8601 tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: - dynatrace accessLogs: outputs: - dynatrace ``` 設定オプションについての詳細は、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 ## [](#configure-access-logs)アクセスログの設定 ログ出力内のアクセスログを設定するには、要求および応答データの監視の対象である API にメッセージログポリシーを適用する必要があります。すでにメッセージログポリシーを API インスタンスに割り当てている場合、別のメッセージログポリシーを設定する必要はありません。 メッセージログポリシーを設定すると、アクセスログを標準出力ログとサードパーティログサービスの両方に表示できます。 メッセージログポリシーを適用するには、「​[ポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-apply) and use the [Message Logging Configuration Parameters](https://docs.mulesoft.com/gateway/latest/policies-included-message-logging)​」を参照してください。 アクセスログが表示されない場合、メッセージログポリシーが実行される前に、より高い実行順序を持つポリシーによってエラーが発生している可能性があります。ポリシーの実行を並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.8/policies-reorder)を参照してください。 ## [](#ログイベントの例)ログイベントの例 次のログ出力の例は、次のイベントで発生する可能性がある出力を示しています。 - [グレースフルシャットダウン](#graceful-shutdowns) - [サービス停止](#service-disconnections) - [Envoy のクラッシュ](#envoy-crash) ### [](#graceful-shutdowns)グレースフルシャットダウン \[flex-gateway-agent\]\[info\] SignalHandler: Signal terminated received \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ### [](#service-disconnections)サービス停止 \[flex-gateway-agent\]\[error\] WebSocket receiver got error: read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[warn\] Dropped connection due to error read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Reconnecting after connection was dropped \[flex-gateway-agent\]\[error\] Error connecting to Websocket Server: dial tcp: lookup arm-mcm2-service.kstg.msap.io on 192.168.65.7:53: dial udp 192.168.65.7:53: connect: network is unreachable ### [](#envoy-crash)Envoy のクラッシュ \[flex-gateway-envoy\]\[critical\] Caught Segmentation fault, suspect faulting address 0xffff87e8fb89485b \[flex-gateway-envoy\]\[critical\] Backtrace (use tools/stack\_decode.py to get line numbers): \[flex-gateway-envoy\]\[critical\] Envoy version: 36cbae1aeedd8c3b4eb88cd28268d21fe0905ce5/1.23.0/Clean/RELEASE/BoringSSL \[flex-gateway-envoy\]\[critical\] #0: \_\_restore\_rt \[0x7ff79db2f140\] \[flex-gateway-envoy\]\[critical\] #1: \[0x557dcfad249b\] \[flex-gateway-envoy\]\[critical\] #2: \[0x557dcdf35237\] \[flex-gateway-envoy\]\[critical\] #3: \[0x557dce16d49f\] \[flex-gateway-envoy\]\[critical\] #4: \[0x557dce1a8ff5\] \[flex-gateway-envoy\]\[critical\] #5: \[0x557dce1a8e47\] \[flex-gateway-envoy\]\[critical\] #6: ... \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error flex-gateway-envoy: command error: signal: segmentation fault \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ## [](#関連情報)関連情報 - [メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-message-logging) # ローカルモードでの Flex Gateway の外部ログの設定 Anypoint Flex Gatewa を使用すると、サポートされている Fluent Bit v3.0 出力種別にランタイムとアクセスログを配信できます。カスタム YAML ファイルを介してログ出力を設定します。さらに、アクセスログを表示するには、メッセージログポリシーも適用する必要があります。 次の設定ファイルの例は、Flex Gateway ログを出力種別 (​`File`​、​`HTTP`​、および ​`Splunk`​) に送信する方法を示しています。ただし、​`Azure Log Analytics`​、​`Amazon S3`​、​`Kafka`​ など、任意の Fluent Bit v3.0 出力種別を使用できます。Fluent Bit 出力種別の完全なリストについては、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 追加の Fluent Bit ログ出力種別を設定できるだけでなく、Flex Gateway は標準出力ログを維持します。追加のログ出力が必要ない場合は、標準出力ログを簡単なチェックに使用します。標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/gateway/latest/local-view-logs)​を参照してください。ランタイムログとアクセスログの両方は、標準出力ログに表示されます。ただし、アクセスログはメッセージログポリシーを適用した場合にのみ存在します。

20%

25%

20%

Linux サービスとして Flex Gateway のログ出力を設定する

Docker コンテナで Flex Gateway のログ出力を設定する

Kubernetes クラスターで Flex Gateway のログ出力を設定する
## [](#始める前に)始める前に Flex Gateway ログ出力を設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) さらに、出力に応じて、ログの送信先のサービスが動作していて、必要な情報が揃っていることを確認します。 - Splunk: - 実行中の [Splunk](https://www.splunk.com/)​ サービス。無料の Splunk Cloud トライアルを使用して Splunk をテストできます。 - Cloud または Enterprise Splunk サービスに HTTP イベントコレクター (HEC) データ入力を追加済み。データ入力を追加する方法と HEC トークンを作成する方法については、 [Splunk ドキュメント](https://docs.splunk.com/Documentation/Splunk/7.0.3/Data/UsetheHTTPEventCollector)​ を参照してください。 - Dynatrace: - 実行中の [Dynatrace](https://www.dynatrace.com/)​ サービス。無料の Dynatrace トライアルを使用して Dynatrace をテストできます。 - 環境 ID。Dynatrace 環境 ID の見つけ方については、 [「環境 ID」](https://www.dynatrace.com/support/help/get-started/monitoring-environment/environment-id)​を参照してください。 - アクセストークン。Dynatrace アクセストークンを生成するには、 [「アクセストークン」](https://www.dynatrace.com/support/help/manage/access-control/access-tokens)​を参照してください。トークンに ​`Ingest logs`​ トークンスコープがあることを確認します。 ## [](#ランタイムログとアクセスログ)ランタイムログとアクセスログ ランタイムログとアクセスログの両方は、同じログ出力に表示されます。ただし、両方のログをログ出力に含めるかどうかを選択できます。アクセスログを使用するには、メッセージログポリシーも適用する必要があります。 ### [](#ランタイムログ)ランタイムログ ランタイムログには、次の情報が含まれます。 - Flex Gateway、Fluent Bit、および Envoy の起動とシャットダウン - デプロイされた API とポリシー - Flex Gateway の設定ミスの可能性またはその他のエラー ### [](#アクセスログ)アクセスログ アクセスログには、一定期間の Envoy との受信インタラクション、および特定の API に対する受信要求と応答が示されます。 アクセスログを有効にするには、監視する API インスタンスにメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](#configure-access-logs)​を参照してください。 ## [](#ログ設定ファイル)ログ設定ファイル `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.0 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
適用された値を含む設定ファイルを確認するには、次の設定ファイルの例を参照してください。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ## [](#linux)Linux サービスとして Flex Gateway のログ出力を設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/logs-config.yaml ``` 2. 次の例に示すように、目的の出力設定の詳細でファイルを更新します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging)を参照してください。 3. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#docker)Docker コンテナで Flex Gateway のログ出力を設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 次の例に示すように、目的の出力設定の詳細を含む YAML ファイルを作成して保存します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging)を参照してください。 5. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のログ出力を設定する Flex Gateway のログを設定する手順は、次のとおりです。 1. 次の例に示すように、目的の出力設定の詳細を含む YAML 設定ファイルを使用して、新しいリソースを作成します。 - [ファイルの設定例](#file-configuration-example) - [HTTP の設定例](#http-configuration-example) - [Splunk の設定例](#splunk-configuration-example) - [Dynatrace の設定例](#dynatrace-configuration-example) ログ出力にイベントが表示されない場合は、Flex Gateway 標準出力ログに設定エラーがないか確認します。 標準出力ログを表示するには、​[「ログの表示」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-view-logs)​を参照してください。 追加のトラブルシューティングヘルプは、[自己管理ゲートウェイのログの問題のトラブルシューティング](https://docs.mulesoft.com/jp/gateway/1.9/flex-troubleshoot-logging)を参照してください。 2. アクセスログを設定する場合、​[「アクセスログの設定」](#access-logs)​を参照してメッセージログポリシーを適用します。 ## [](#file-configuration-example)ファイルの設定例 書式設定されたランタイムログとアクセスログを ​`/var/log`​ ディレクトリの ​`log.txt`​ という名前のファイル (Fluent Bit の ​`File`​ 出力) に送信するように Flex Gateway を設定します。この例の定義では、​`file`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: file parameters: file: /var/log/log.txt # Docker: replace `/var/log` with the absolute path to the mounted configuration directory format: template template: | [{date}][{logger}][{level}][{kind}] {message} runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ```
Docker の場合は、​spec.logging.output.parameters.file​ の ​/var/log​ を、マウントされた設定ディレクトリへの絶対パスに置き換えてください。
## [](#http-configuration-example)HTTP の設定例 書式設定されたランタイムログとアクセスログを ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。この例の定義では、​`HTTP`​ の値として ​`spec.logging.outputs.type`​ が指定されています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging-config spec: logging: outputs: - name: default type: HTTP parameters: host: collectors.au.sumologic.com port: "443" URI: /receiver/v1/http/[PrivateKey] format: json_lines json_date_key: timestamp json_date_format: iso8601 runtimeLogs: logLevel: info outputs: - default accessLogs: outputs: - default ``` ## [](#splunk-configuration-example)Splunk の設定例 Splunk は、このリソースを適用するとすぐにログの取り込みを開始します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: splunk-config spec: logging: outputs: - name: splunk type: splunk parameters: host: .splunkcloud.com port: "8088" splunk_token: tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: [splunk] accessLogs: outputs: [splunk] ``` ## [](#dynatrace-configuration-example)Dynatrace の設定例 書式設定されたランタイムログとアクセスログを Dynatrace 環境の ​`HTTP`​ 出力に送信するように Flex Gateway を設定できます。たとえば、次のファイルには必要な設定が含まれています。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: dynatrace-config spec: logging: outputs: - name: dynatrace type: http parameters: host: .live.dynatrace.com Port: "443" allow_duplicated_headers: "false" header: - Content-Type application/json; charset=utf-8 - Authorization Api-Token URI: /api/v2/logs/ingest Format: json json_date_key: timestamp json_date_format: iso8601 tls: "on" tls.verify: "off" runtimeLogs: logLevel: info outputs: - dynatrace accessLogs: outputs: - dynatrace ``` 設定オプションについての詳細は、対象の Fluent Bit バージョンの [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual)​を参照してください。 ## [](#configure-access-logs)アクセスログの設定 ログ出力内のアクセスログを設定するには、要求および応答データの監視の対象である API にメッセージログポリシーを適用する必要があります。すでにメッセージログポリシーを API インスタンスに割り当てている場合、別のメッセージログポリシーを設定する必要はありません。 メッセージログポリシーを設定すると、アクセスログを標準出力ログとサードパーティログサービスの両方に表示できます。 メッセージログポリシーを適用するには、「​[ローカルモードでのポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-secure-local) and use the [Message Logging Configuration Parameters](https://docs.mulesoft.com/gateway/latest/policies-included-message-logging)​」を参照してください。 アクセスログが表示されない場合、メッセージログポリシーが実行される前に、より高い実行順序を持つポリシーによってエラーが発生している可能性があります。ポリシーの実行を並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.9/policies-reorder)を参照してください。 ## [](#ログイベントの例)ログイベントの例 次のログ出力の例は、次のイベントで発生する可能性がある出力を示しています。 - [グレースフルシャットダウン](#graceful-shutdowns) - [サービス停止](#service-disconnections) - [Envoy のクラッシュ](#envoy-crash) ### [](#graceful-shutdowns)グレースフルシャットダウン \[flex-gateway-agent\]\[info\] SignalHandler: Signal terminated received \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ### [](#service-disconnections)サービス停止 \[flex-gateway-agent\]\[error\] WebSocket receiver got error: read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[warn\] Dropped connection due to error read tcp 172.17.0.2:60780->100.64.1.37:443: i/o timeout \[flex-gateway-agent\]\[info\] Reconnecting after connection was dropped \[flex-gateway-agent\]\[error\] Error connecting to Websocket Server: dial tcp: lookup arm-mcm2-service.kstg.msap.io on 192.168.65.7:53: dial udp 192.168.65.7:53: connect: network is unreachable ### [](#envoy-crash)Envoy のクラッシュ \[flex-gateway-envoy\]\[critical\] Caught Segmentation fault, suspect faulting address 0xffff87e8fb89485b \[flex-gateway-envoy\]\[critical\] Backtrace (use tools/stack\_decode.py to get line numbers): \[flex-gateway-envoy\]\[critical\] Envoy version: 36cbae1aeedd8c3b4eb88cd28268d21fe0905ce5/1.23.0/Clean/RELEASE/BoringSSL \[flex-gateway-envoy\]\[critical\] #0: \_\_restore\_rt \[0x7ff79db2f140\] \[flex-gateway-envoy\]\[critical\] #1: \[0x557dcfad249b\] \[flex-gateway-envoy\]\[critical\] #2: \[0x557dcdf35237\] \[flex-gateway-envoy\]\[critical\] #3: \[0x557dce16d49f\] \[flex-gateway-envoy\]\[critical\] #4: \[0x557dce1a8ff5\] \[flex-gateway-envoy\]\[critical\] #5: \[0x557dce1a8e47\] \[flex-gateway-envoy\]\[critical\] #6: ... \[flex-gateway-agent\]\[error\] flex-gateway-envoy: Stopped with error flex-gateway-envoy: command error: signal: segmentation fault \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[error\] flex-gateway-fluent: Stopped with error context canceled \[flex-gateway-agent\]\[info\] FilesystemWatcher(/etc/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] FilesystemWatcher(/usr/local/share/mulesoft/flex-gateway/conf.d): Stopping with context done \[flex-gateway-agent\]\[info\] XdsService: Stopping with context done \[flex-gateway-agent\]\[info\] Server dropped connection \[flex-gateway-agent\]\[info\] Agent communication closed ## [](#関連情報)関連情報 - [メッセージログポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-message-logging) # ローカルモードでの Flex Gateway の登録と実行 Flex Gateway を使用して API インスタンスを設定するには、ゲートウェイを登録して開始する必要があります。 Flex Gateway をローカルモードで登録するには、次の 3 つのオプションがあります。 - [ユーザー名とパスワードを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run-up)​: Anypoint Platform のユーザー名とパスワードを持っている場合は、これらのログイン情報を使用して Flex Gateway を登録できます。 - [接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run-app)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、接続アプリケーションのログイン情報を使用して Flex Gateway を登録できます。 - [トークンを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run-token)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、Runtime Manager UI が生成する登録トークンを使用できます。トークンは 4 時間有効です。 # ローカルモードでの Flex Gateway の登録と実行 Flex Gateway を使用して API インスタンスを設定するには、ゲートウェイを登録して開始する必要があります。 Flex Gateway をローカルモードで登録するには、次の 3 つのオプションがあります。 - [ユーザー名とパスワードを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run-up)​: Anypoint Platform のユーザー名とパスワードを持っている場合は、これらのログイン情報を使用して Flex Gateway を登録できます。 - [接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run-app)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、接続アプリケーションのログイン情報を使用して Flex Gateway を登録できます。 - [トークンを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run-token)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、Runtime Manager UI が生成する登録トークンを使用できます。トークンは 4 時間有効です。 # ローカルモードでの Flex Gateway の登録と実行 Flex Gateway を使用して API インスタンスを設定するには、ゲートウェイを登録して開始する必要があります。 Flex Gateway をローカルモードで登録するには、次の 3 つのオプションがあります。 - [ユーザー名とパスワードを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run-up)​: Anypoint Platform のユーザー名とパスワードを持っている場合は、これらのログイン情報を使用して Flex Gateway を登録できます。 - [接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run-app)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、接続アプリケーションのログイン情報を使用して Flex Gateway を登録できます。 - [トークンを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run-token)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、Runtime Manager UI が生成する登録トークンを使用できます。トークンは 4 時間有効です。 # ローカルモードでの Flex Gateway の設定 - [レプリカの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-rep-run)​ - Anypoint Flex Gateway では、Flex Gateway のインスタンスであるレプリカを作成できます。デフォルトでは、Flex Gateway は単一のレプリカとして実行します。複数のレプリカを実行することにより、スケーリング、ロードバランシング、高可用性を実現できます。 - [TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config)​ - Flex Gateway では、インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。 - [共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-shared-storage-config)​ - Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。 - [転送プロキシの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-forward-proxy)​ - Flex Gateway では、プロキシ接続経由で外部 HTTP 接続をルーティングするように転送プロキシを設定できます。 - [ライブネスチェックの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-readiness-liveness)​ - Flex Gateway では、ライブネスチェックコマンドを実行して、ゲートウェイの健全性をテストできます。さらに、Kubernetes にデプロイされた Flex Gateway には、指定された回数のチェックが失敗した後にポッドを自動的に再起動するライブネスプローブが含まれています。 - [PROXY プロトコルの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-proxy-protocol)​ - Flex Gateway では、マルチレイヤー接続を提供しているときにクライアント IP アドレスを保持するための PROXY プロトコルがサポートされています。 - [分散トレースの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tracing-config)​ - Flex Gateway では、API の分散とレースを設定できます。 宣言型設定ファイルを介した Flex Gateway の設定についての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 # ローカルモードでの Flex Gateway の設定 - [レプリカの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-rep-run)​ - Anypoint Flex Gateway では、Flex Gateway のインスタンスであるレプリカを作成できます。デフォルトでは、Flex Gateway は単一のレプリカとして実行します。複数のレプリカを実行することにより、スケーリング、ロードバランシング、高可用性を実現できます。 - [TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config)​ - Flex Gateway では、インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。 - [共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-shared-storage-config)​ - Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。 - [転送プロキシの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-forward-proxy)​ - Flex Gateway では、プロキシ接続経由で外部 HTTP 接続をルーティングするように転送プロキシを設定できます。 - [ライブネスチェックの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-readiness-liveness)​ - Flex Gateway では、ライブネスチェックコマンドを実行して、ゲートウェイの健全性をテストできます。さらに、Kubernetes にデプロイされた Flex Gateway には、指定された回数のチェックが失敗した後にポッドを自動的に再起動するライブネスプローブが含まれています。 - [PROXY プロトコルの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-proxy-protocol)​ - Flex Gateway では、マルチレイヤー接続を提供しているときにクライアント IP アドレスを保持するための PROXY プロトコルがサポートされています。 宣言型設定ファイルを介した Flex Gateway の設定についての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 # ローカルモードでの Flex Gateway の設定 - [レプリカの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-rep-run)​ - Anypoint Flex Gateway では、Flex Gateway のインスタンスであるレプリカを作成できます。デフォルトでは、Flex Gateway は単一のレプリカとして実行します。複数のレプリカを実行することにより、スケーリング、ロードバランシング、高可用性を実現できます。 - [TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config)​ - Flex Gateway では、インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。 - [共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-shared-storage-config)​ - Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。 - [転送プロキシの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-forward-proxy)​ - Flex Gateway では、プロキシ接続経由で外部 HTTP 接続をルーティングするように転送プロキシを設定できます。 - [ライブネスチェックの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-readiness-liveness)​ - Flex Gateway では、ライブネスチェックコマンドを実行して、ゲートウェイの健全性をテストできます。さらに、Kubernetes にデプロイされた Flex Gateway には、指定された回数のチェックが失敗した後にポッドを自動的に再起動するライブネスプローブが含まれています。 - [PROXY プロトコルの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-proxy-protocol)​ - Flex Gateway では、マルチレイヤー接続を提供しているときにクライアント IP アドレスを保持するための PROXY プロトコルがサポートされています。 宣言型設定ファイルを介した Flex Gateway の設定についての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 # ローカルモードでの Flex Gateway の転送プロキシの設定 Squid などの転送プロキシを使用すると、プロキシ接続経由で外部 HTTP Flex Gateway 接続をルーティングできます。 接続モードとローカルモードの両方で、YAML 設定ファイルを使用して転送プロキシを設定します。 次の図は、内部ネットワークが転送プロキシを使用して外部ネットワークと通信する方法を示しています。 ![アプリケーションからデータベース、さらにクラウドへ、またその逆のデータのジャーニーを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/forward-proxy-diagram.png) この図のように、転送プロキシを使用している場合、内部ネットワークからの HTTP 通信は転送プロキシを通過する必要があります。 この例では、すべての HTTP API アップストリーム通信も転送プロキシを通過する必要があります。一部の接続が転送プロキシを使用せずに直接通信できるようにする方法についての詳細は、​[「noProxy パラメーター」](#noproxy-parameter)​を参照してください。

20%

25%

20%

Linux サービスとして Flex Gateway の転送プロキシを設定する

Docker コンテナで Flex Gateway の転送プロキシを設定する

Kubernetes クラスターでの Flex Gateway の転送プロキシの設定
## [](#転送プロキシ接続)転送プロキシ接続 HTTP 接続のみが転送プロキシ経由でルーティングされます。 次の接続が転送プロキシ経由でルーティングされます。 - Anypoint Platform への接続 - アウトバウンドポリシー接続 - アップストリームサービスへの接続 - HTTP (Fluent Bit) ログ接続 `noProxy`​ パラメーターを使用すると、転送プロキシを使用せずに直接接続するように HTTP および HTTPS 接続を設定できます。 転送プロキシを設定しても、次の接続は変更されません。 - 共有ストレージへの接続 - Lightweight Directory Access Protocol (LDAP) 接続 - 非 HTTP ログ接続 ## [](#noproxy-パラメーター)noProxy パラメーター `noProxy`​ パラメーターを追加すると、信頼する HTTP サービスが転送プロキシを使用せずに通信できるようになります。 たとえば、​`noProxy`​ を有効にすると、HTTP ログ接続とアップストリームサービスへの接続をリストして、それらを Flex Gateway に直接接続させることができます。 YAML 設定ファイルで ​`noProxy`​ パラメーターを使用して HTTP ログと通信している場合、正確なドメイン名をリストする必要があります。ドメインサフィックス (​`.svc.cluster.local`​ など) をリストすることはできません。すべての HTTP ログ接続に対して完全なドメイン名、​`.svc.cluster.local`​ をリストする必要があります。 次の図は、noProxy を使用した通信での違いを示しています。 ![「noProxy」が有効または無効になっている場合の内部接続間の違いを示しています](/mulesoft/current/ja-jp/gateway/1.10/_images/no-proxy-diagram.png) この図では、​`noProxy`​ を有効にしない場合、Flex Gateway は転送プロキシを使用して内部 API エンドポイントと通信します。​`noProxy`​ を有効にして API アップストリームドメインをリストした場合、Flex Gateway は内部 API エンドポイントと直接通信します。 ## [](#転送プロキシパラメーターの設定)転送プロキシパラメーターの設定 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: forward-proxy spec: forwardProxy: https: address: http://proxy:8888 basicAuth: username: password: noProxy: - fluentd - .svc.cluster.local ```
パラメーター 必須または省略可能 説明

https.address

必須

プロキシアドレス。

basicAuth

省略可能

認証ユーザー名とパスワードを指定する。

basicAuth.username

basicAuth​ が設定されている場合は必須

認証ユーザー名

basicAuth.Password

basicAuth​ が設定されている場合は必須

認証パスワード。

noProxy

省略可能

転送プロキシを使用せずに通信するドメイン名または IP アドレスを含む配列。各 IP アドレスは配列でリストされている必要があります。​noProxy​ では、CIDR ブロックはサポートされません。
## [](#linux)Linux サービスとして Flex Gateway の転送プロキシを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/forward-config.yaml ``` 2. 目的の転送プロキシ設定の詳細を使用してファイルを更新します。 3. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#docker)Docker コンテナで Flex Gateway の転送プロキシを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 目的の転送プロキシ設定の詳細を使用して YAML ファイルを作成して保存します。 5. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターでの Flex Gateway の転送プロキシの設定 Flex Gateway の転送プロキシを設定するには、転送プロキシの詳細を使用して新しい YAML 設定リソースを作成します。 Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#proxy-registration)転送プロキシ Flex Gateway の登録 Flex Gateway が、すべてのインターネット接続が転送プロキシを通過する内部ネットワークにある場合は、​[Flex Gateway を登録](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​するときに ​`--https-proxy`​ フラグを追加する必要があります。 `--https-proxy`​ フラグをプロキシの ​`address`​ パラメーターと共に追加します。 \--https-proxy=http://proxy:8888 `basicAuth`​ を有効にする場合は、​`username`​ パラメーターと ​`password`​ パラメーターを指定します。 \--https-proxy=http://:@proxy:8888 次のサンプル登録コマンドは、フラグの配置を示しています。 ```ssh flexctl register \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ --https-proxy=http://:@proxy:8888 \ my-gateway ```
Flex Gateway デプロイメントには関連する登録コマンドを使用してください。
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) # ローカルモードでの Flex Gateway の転送プロキシの設定 Squid などの転送プロキシを使用すると、プロキシ接続経由で外部 HTTP Flex Gateway 接続をルーティングできます。 接続モードとローカルモードの両方で、YAML 設定ファイルを使用して転送プロキシを設定します。 次の図は、内部ネットワークが転送プロキシを使用して外部ネットワークと通信する方法を示しています。 ![これは、Flex Gateway へのすべての接続が最初に転送プロキシを通過する画像です](/mulesoft/current/ja-jp/gateway/1.8/_images/forward-proxy-diagram.png) この図のように、転送プロキシを使用している場合、内部ネットワークからの HTTP 通信は転送プロキシを通過する必要があります。 この例では、すべての HTTP API アップストリーム通信も転送プロキシを通過する必要があります。一部の接続が転送プロキシを使用せずに直接通信できるようにする方法についての詳細は、​[「noProxy パラメーター」](#noproxy-parameter)​を参照してください。

20%

25%

20%

Linux サービスとして Flex Gateway の転送プロキシを設定する

Docker コンテナで Flex Gateway の転送プロキシを設定する

Kubernetes クラスターでの Flex Gateway の転送プロキシの設定
## [](#転送プロキシ接続)転送プロキシ接続 HTTP 接続のみが転送プロキシ経由でルーティングされます。 次の接続が転送プロキシ経由でルーティングされます。 - Anypoint Platform への接続 - アウトバウンドポリシー接続 - アップストリームサービスへの接続 - HTTP (Fluent Bit) ログ接続 `noProxy`​ パラメーターを使用すると、転送プロキシを使用せずに直接接続するように HTTP および HTTPS 接続を設定できます。 転送プロキシを設定しても、次の接続は変更されません。 - 共有ストレージへの接続 - Lightweight Directory Access Protocol (LDAP) 接続 - 非 HTTP ログ接続 ## [](#noproxy-パラメーター)noProxy パラメーター `noProxy`​ パラメーターを追加すると、信頼する HTTP サービスが転送プロキシを使用せずに通信できるようになります。 たとえば、​`noProxy`​ を有効にすると、HTTP ログ接続とアップストリームサービスへの接続をリストして、それらを Flex Gateway に直接接続させることができます。 YAML 設定ファイルで ​`noProxy`​ パラメーターを使用して HTTP ログと通信している場合、正確なドメイン名をリストする必要があります。ドメインサフィックス (​`.svc.cluster.local`​ など) をリストすることはできません。すべての HTTP ログ接続に対して完全なドメイン名、​`.svc.cluster.local`​ をリストする必要があります。 次の図は、noProxy を使用した通信での違いを示しています。 ![これは、noProxy を有効にした場合としなかった場合の内部接続の違いを示す画像です](/mulesoft/current/ja-jp/gateway/1.8/_images/no-proxy-diagram.png) この図では、​`noProxy`​ を有効にしない場合、Flex Gateway は転送プロキシを使用して内部 API エンドポイントと通信します。​`noProxy`​ を有効にして API アップストリームドメインをリストした場合、Flex Gateway は内部 API エンドポイントと直接通信します。 ## [](#転送プロキシパラメーターの設定)転送プロキシパラメーターの設定 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: forward-proxy spec: forwardProxy: https: address: http://proxy:8888 basicAuth: username: password: noProxy: - fluentd - .svc.cluster.local ```
パラメーター 必須または省略可能 説明

https.address

必須

プロキシアドレス

basicAuth

省略可能

認証ユーザー名とパスワードを指定する

basicAuth.username

basicAuth​ が設定されている場合は必須

認証ユーザー名

basicAuth.Password

basicAuth​ が設定されている場合は必須

認証パスワード

noProxy

省略可能

転送プロキシを使用せずに通信するドメイン名を含む配列
## [](#linux)Linux サービスとして Flex Gateway の転送プロキシを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/forward-config.yaml ``` 2. 目的の転送プロキシ設定の詳細を使用してファイルを更新します。 3. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#docker)Docker コンテナで Flex Gateway の転送プロキシを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 目的の転送プロキシ設定の詳細を使用して YAML ファイルを作成して保存します。 5. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターでの Flex Gateway の転送プロキシの設定 Flex Gateway の転送プロキシを設定するには、転送プロキシの詳細を使用して新しい YAML 設定リソースを作成します。 Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#proxy-registration)転送プロキシ Flex Gateway の登録 Flex Gateway が、すべてのインターネット接続が転送プロキシを通過する内部ネットワークにある場合は、​[Flex Gateway を登録](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​するときに ​`--https-proxy`​ フラグを追加する必要があります。 `--https-proxy`​ フラグをプロキシの ​`address`​ パラメーターと共に追加します。 \--https-proxy=http://proxy:8888 `basicAuth`​ を有効にする場合は、​`username`​ パラメーターと ​`password`​ パラメーターを指定します。 \--https-proxy=http://:@proxy:8888 次のサンプル登録コマンドは、フラグの配置を示しています。 ```ssh flexctl register \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ --https-proxy=http://:@proxy:8888 \ my-gateway ```
Flex Gateway デプロイメントには関連する登録コマンドを使用してください。
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) # ローカルモードでの Flex Gateway の転送プロキシの設定 Squid などの転送プロキシを使用すると、プロキシ接続経由で外部 HTTP Flex Gateway 接続をルーティングできます。 接続モードとローカルモードの両方で、YAML 設定ファイルを使用して転送プロキシを設定します。 次の図は、内部ネットワークが転送プロキシを使用して外部ネットワークと通信する方法を示しています。 ![アプリケーションからデータベース、さらにクラウドへ、またその逆のデータのジャーニーを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/forward-proxy-diagram.png) この図のように、転送プロキシを使用している場合、内部ネットワークからの HTTP 通信は転送プロキシを通過する必要があります。 この例では、すべての HTTP API アップストリーム通信も転送プロキシを通過する必要があります。一部の接続が転送プロキシを使用せずに直接通信できるようにする方法についての詳細は、​[「noProxy パラメーター」](#noproxy-parameter)​を参照してください。

20%

25%

20%

Linux サービスとして Flex Gateway の転送プロキシを設定する

Docker コンテナで Flex Gateway の転送プロキシを設定する

Kubernetes クラスターでの Flex Gateway の転送プロキシの設定
## [](#転送プロキシ接続)転送プロキシ接続 HTTP 接続のみが転送プロキシ経由でルーティングされます。 次の接続が転送プロキシ経由でルーティングされます。 - Anypoint Platform への接続 - アウトバウンドポリシー接続 - アップストリームサービスへの接続 - HTTP (Fluent Bit) ログ接続 `noProxy`​ パラメーターを使用すると、転送プロキシを使用せずに直接接続するように HTTP および HTTPS 接続を設定できます。 転送プロキシを設定しても、次の接続は変更されません。 - 共有ストレージへの接続 - Lightweight Directory Access Protocol (LDAP) 接続 - 非 HTTP ログ接続 ## [](#noproxy-パラメーター)noProxy パラメーター `noProxy`​ パラメーターを追加すると、信頼する HTTP サービスが転送プロキシを使用せずに通信できるようになります。 たとえば、​`noProxy`​ を有効にすると、HTTP ログ接続とアップストリームサービスへの接続をリストして、それらを Flex Gateway に直接接続させることができます。 YAML 設定ファイルで ​`noProxy`​ パラメーターを使用して HTTP ログと通信している場合、正確なドメイン名をリストする必要があります。ドメインサフィックス (​`.svc.cluster.local`​ など) をリストすることはできません。すべての HTTP ログ接続に対して完全なドメイン名、​`.svc.cluster.local`​ をリストする必要があります。 次の図は、noProxy を使用した通信での違いを示しています。 ![「noProxy」が有効または無効になっている場合の内部接続間の違いを示しています](/mulesoft/current/ja-jp/gateway/1.9/_images/no-proxy-diagram.png) この図では、​`noProxy`​ を有効にしない場合、Flex Gateway は転送プロキシを使用して内部 API エンドポイントと通信します。​`noProxy`​ を有効にして API アップストリームドメインをリストした場合、Flex Gateway は内部 API エンドポイントと直接通信します。 ## [](#転送プロキシパラメーターの設定)転送プロキシパラメーターの設定 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: forward-proxy spec: forwardProxy: https: address: http://proxy:8888 basicAuth: username: password: noProxy: - fluentd - .svc.cluster.local ```
パラメーター 必須または省略可能 説明

https.address

必須

プロキシアドレス。

basicAuth

省略可能

認証ユーザー名とパスワードを指定する。

basicAuth.username

basicAuth​ が設定されている場合は必須

認証ユーザー名

basicAuth.Password

basicAuth​ が設定されている場合は必須

認証パスワード。

noProxy

省略可能

転送プロキシを使用せずに通信するドメイン名または IP アドレスを含む配列。各 IP アドレスは配列でリストされている必要があります。​noProxy​ では、CIDR ブロックはサポートされません。
## [](#linux)Linux サービスとして Flex Gateway の転送プロキシを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/forward-config.yaml ``` 2. 目的の転送プロキシ設定の詳細を使用してファイルを更新します。 3. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#docker)Docker コンテナで Flex Gateway の転送プロキシを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 目的の転送プロキシ設定の詳細を使用して YAML ファイルを作成して保存します。 5. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターでの Flex Gateway の転送プロキシの設定 Flex Gateway の転送プロキシを設定するには、転送プロキシの詳細を使用して新しい YAML 設定リソースを作成します。 Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#proxy-registration)転送プロキシ Flex Gateway の登録 Flex Gateway が、すべてのインターネット接続が転送プロキシを通過する内部ネットワークにある場合は、​[Flex Gateway を登録](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​するときに ​`--https-proxy`​ フラグを追加する必要があります。 `--https-proxy`​ フラグをプロキシの ​`address`​ パラメーターと共に追加します。 \--https-proxy=http://proxy:8888 `basicAuth`​ を有効にする場合は、​`username`​ パラメーターと ​`password`​ パラメーターを指定します。 \--https-proxy=http://:@proxy:8888 次のサンプル登録コマンドは、フラグの配置を示しています。 ```ssh flexctl register \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ --https-proxy=http://:@proxy:8888 \ my-gateway ```
Flex Gateway デプロイメントには関連する登録コマンドを使用してください。
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) # ローカルモードでの Flex Gateway 分散トレースの設定 OpenTelemetry により、分散システムでテレメトリーデータを計測、生成、収集、エクスポートするための統合された基準が提供されます。Flex Gateway では OpenTelemetry をサポートしているため、ゲートウェイで管理するすべての API トラフィックの分散トレースデータの生成を設定できます。このインテグレーションにより、API 要求フローをより詳しく視覚化できるため、システムの動作をより簡単に分析し、問題をトラブルシューティングして、Flex Gateway API と外部サービス間のインタラクションを理解できます。 Anypoint Monitoring Telemetry Exporter を使用することで、Flex Gateway トレースデータを Azure Monitor や Splunk HEC のほか、OpenTelemetry 互換ツールなどのサードパーティオブザーバビリティおよび分析プラットフォームに送信できます。この機能によって、エンドツーエンドオブザーバビリティを活用し、API トレースを他のシステムのデータと相関させ、環境の包括的なビューを構築できます。 ## [](#始める前に)始める前に Flex Gateway で OpenTelemetry を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 ## [](#flex-gateway-api-の分散トレースの設定)Flex Gateway API の分散トレースの設定 トレースにより、Flex Gateway API のインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れる API 要求を追跡し、API の実行の包括的なビューを提供します。 ## [](#yaml-設定リソースを使用した分散トレースの有効化と設定)YAML 設定リソースを使用した分散トレースの有効化と設定 この設定リソースを編集してから適用し、分散トレースを有効にします。この設定リソースは、すべての API インスタンスに適用されます。 次の例では、すべてのトレースのサンプリングを 0% に設定し、サンプリングはポリシーを使用して API ごとに設定されます。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: tracing namespace: test-ns spec: tracing: provider: type: anypoint properties: timeout: 10s # sampling: # Set all sampling to 0% - this example shows enabling samping for the gateway, but only generating trace data for sampling on a per-API basis using the Tracing policy. client: 0 random: 0 overall: 0 # # Add labels such as these example labels, if you want to configure labels globally. You can also configure labels on a per-API basis by using the Tracing policy. labels: - name: c-env-tag type: environment keyName: FLEX_NAME defaultValue: DEFAULT_VAL - name: c-header-tag type: requestHeader keyName: :method defaultValue: DEFAULT_METHOD - name: c-literal-tag type: literal defaultValue: the-tag ``` ## [](#特定の-api-の分散トレースの設定)特定の API の分散トレースの設定 特定の API にトレースポリシーを適用することで、グローバルに設定された分散トレース設定を上書きできます。まずゲートウェイの分散トレースを有効にして設定する必要があります。その後、次のポリシーを計測する API に適用できます。 - [トレースポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tracing) # ローカルモードでの PROXY プロトコルの設定 ロードバランサーまたは他のプロキシサービスの背後に Flex Gateway がデプロイされるユースケースの場合、NAT または TCP プロキシの複数のレイヤーでクライアント IP アドレスが保持されるように PROXY プロトコルを設定します。 プロキシプロトコルでは、ロードバランサーまたは他のプロキシサービスは、クライアントアドレスと追加情報が含まれるプロキシプロトコルヘッダーを Flex Gateway に送信します。プロキシプロトコルについての詳細は、 [HAProxy の仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)​を参照してください。 プロキシプロトコルを有効にすると、Flex Gateway はプロキシプロトコルヘッダーの受信しかできなくなります。ヘッダーを送信するには、ロードバランサーまたは他のプロキシサービスでプロキシプロトコルがサポートされている必要があります。

20%

25%

20%

Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする

Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする

Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする
## [](#始める前に)始める前に Flex Gateway のプロキシプロトコルを有効にする前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml ``` 2. プロキシプロトコル設定ファイルを使用してファイルを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#docker)Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、プロキシプロトコル設定の詳細を使用して ​`app`​ フォルダーに保存します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする Flex Gateway のプロキシプロトコルを設定するには、YAML 設定ファイルとプロキシプロトコルの詳細を使用して新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#関連情報)関連情報 - [HAProxy 仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) # ローカルモードでの PROXY プロトコルの設定 ロードバランサーまたは他のプロキシサービスの背後に Flex Gateway がデプロイされるユースケースの場合、NAT または TCP プロキシの複数のレイヤーでクライアント IP アドレスが保持されるように PROXY プロトコルを設定します。 プロキシプロトコルでは、ロードバランサーまたは他のプロキシサービスは、クライアントアドレスと追加情報が含まれるプロキシプロトコルヘッダーを Flex Gateway に送信します。プロキシプロトコルについての詳細は、 [HAProxy の仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)​を参照してください。 プロキシプロトコルを有効にすると、Flex Gateway はプロキシプロトコルヘッダーの受信しかできなくなります。ヘッダーを送信するには、ロードバランサーまたは他のプロキシサービスでプロキシプロトコルがサポートされている必要があります。

20%

25%

20%

Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする

Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする

Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする
## [](#始める前に)始める前に Flex Gateway のプロキシプロトコルを有効にする前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml ``` 2. プロキシプロトコル設定ファイルを使用してファイルを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#docker)Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、プロキシプロトコル設定の詳細を使用して ​`app`​ フォルダーに保存します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする Flex Gateway のプロキシプロトコルを設定するには、YAML 設定ファイルとプロキシプロトコルの詳細を使用して新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#関連情報)関連情報 - [HAProxy 仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) # ローカルモードでの PROXY プロトコルの設定 ロードバランサーまたは他のプロキシサービスの背後に Flex Gateway がデプロイされるユースケースの場合、NAT または TCP プロキシの複数のレイヤーでクライアント IP アドレスが保持されるように PROXY プロトコルを設定します。 プロキシプロトコルでは、ロードバランサーまたは他のプロキシサービスは、クライアントアドレスと追加情報が含まれるプロキシプロトコルヘッダーを Flex Gateway に送信します。プロキシプロトコルについての詳細は、 [HAProxy の仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)​を参照してください。 プロキシプロトコルを有効にすると、Flex Gateway はプロキシプロトコルヘッダーの受信しかできなくなります。ヘッダーを送信するには、ロードバランサーまたは他のプロキシサービスでプロキシプロトコルがサポートされている必要があります。

20%

25%

20%

Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする

Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする

Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする
## [](#始める前に)始める前に Flex Gateway のプロキシプロトコルを有効にする前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) ## [](#linux)Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml ``` 2. プロキシプロトコル設定ファイルを使用してファイルを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#docker)Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、プロキシプロトコル設定の詳細を使用して ​`app`​ フォルダーに保存します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする Flex Gateway のプロキシプロトコルを設定するには、YAML 設定ファイルとプロキシプロトコルの詳細を使用して新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#関連情報)関連情報 - [HAProxy 仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) # ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定 通常、ローカルモードの Kubernetes デプロイメントでは、Flex Gateway は Kubernetes クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。 デフォルトでは、ローカルモードで Kubernetes にデプロイされた Flex Gateway はイングレスコントローラーとして設定され、​`Ingress`​ リソースをコンシュームできます。イングレスコントローラーの設定は、Flex Gateway Helm チャートの ​`IngressClass`​ リソースパラメーターで定義されます。 Kubernetes 用語では、​`IngressClass`​ リソースでゲートウェイをイングレスコントローラーとして設定し、​`Ingress`​ リソースでイングレスコントローラーと、イングレスコントローラーで制御する Kubernetes サービス間のルーティングを設定します。Kubernetes の ​`IngressClass`​ リソースと ​`Ingress`​ リソースについての詳細は、 [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)​ を参照してください。 Helm チャートでは、​`IngressClass`​ 設定を編集したり、イングレスコントローラーの機能を無効にしたりできます。 ## [](#始める前に)始める前に 1. [Kubernetes クラスターで使用する Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.10/flex-install#kubernetes)​。 2. [ローカルモードの Kubernetes クラスターで Flex Gateway を登録して実行します](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​。 ## [](#イングレスクラスパラメーター)イングレスクラスパラメーター Helm チャートには次のデフォルトの ​`IngressClass`​ パラメーターと値が含まれます。 ```helm ingressClass.enabled: true ingressClass.name: "{releaseName}-{namespace}" ingressClass.setAsDefault: false ```

パラメーター

説明

可能な値

ingressClass.enabled

Flex Gateway を ​IngressClass​ リソースとして有効化する

true​ または ​false

ingressClass.name

IngressClass​ の名前

任意の文字列

ingressClass.setAsDefault

Flex Gateway をデフォルトの ​IngressClass​ として設定する

true​ または ​false
`ingressClass.setAsDefault: true`​ の設定により、Flex Gateway インスタンスがクラスターのデフォルトの ​`IngressClass`​ リソースとして定義されます。デフォルトの ​`IngressClass`​ は、クラスターに作成するすべての ​`Ingress`​ リソースのデフォルトのイングレスコントローラーになります。 デフォルトの ​`IngressClass`​ がない場合や、デフォルトの ​`IngressClass`​ リソースを特定のリソースのイングレスコントローラーとすることができない場合、​`Ingress`​ リソースでイングレスコントローラーを手動で定義する必要があります。 デフォルトの ​`IngressClass`​ パラメーターは、Helm チャートの初期インストール中または初期インストール後に変更することができます。Helm チャートを変更する方法についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings)を参照してください。 ## [](#イングレスリソースの作成)イングレスリソースの作成 [Helm チャートを名前空間にインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run-up#kubernetes)​したら、次のコマンドを実行して新しい ​`IngressClass`​ リソースを検証できます。 ```helm kubectl get ingressclasses ``` イングレスルーティングを作成する手順は、次のとおりです。 1. [ローカルモードで API をパブリッシュします](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-simple-api#kubernetes)​。 2. 新しい API を Kubernetes サービスとして定義します。 Kubernetes サービス定義についての詳細は、 [「Defining a Service (サービスの定義)」](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)​を参照してください。 3. `kubectl apply`​ を使用して、​`IngressClass`​ Flex Gateway と新しい Kubernetes サービス間のルーティングルールを定義する ​`Ingress`​ リソースを作成します。 ```ssh cat < annotations: flex-gateway.ingress.kubernetes.io/api-instance: . spec: ingressClassName: rules: - http: ... EOF ``` `annotations`​ 項目値は、API の定義時に指定した API インスタンス名および名前空間に一致する必要があります。 ゲートウェイインスタンスをデフォルトのイングレスコントローラーとして設定している場合、​`ingressClassName`​ 項目を省略します。 `Ingress`​ リソースについての詳細は、 [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)​を参照してください。 ## [](#関連情報)関連情報 - [Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management) # ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定 通常、ローカルモードの Kubernetes デプロイメントでは、Flex Gateway は Kubernetes クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。 デフォルトでは、ローカルモードで Kubernetes にデプロイされた Flex Gateway はイングレスコントローラーとして設定され、​`Ingress`​ リソースをコンシュームできます。イングレスコントローラーの設定は、Flex Gateway Helm チャートの ​`IngressClass`​ リソースパラメーターで定義されます。 Kubernetes 用語では、​`IngressClass`​ リソースでゲートウェイをイングレスコントローラーとして設定し、​`Ingress`​ リソースでイングレスコントローラーと、イングレスコントローラーで制御する Kubernetes サービス間のルーティングを設定します。Kubernetes の ​`IngressClass`​ リソースと ​`Ingress`​ リソースについての詳細は、 [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)​ を参照してください。 Helm チャートでは、​`IngressClass`​ 設定を編集したり、イングレスコントローラーの機能を無効にしたりできます。 ## [](#始める前に)始める前に 1. [Kubernetes クラスターで使用する Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.8/flex-install#kubernetes)​。 2. [ローカルモードの Kubernetes クラスターで Flex Gateway を登録して実行します](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​。 ## [](#イングレスクラスパラメーター)イングレスクラスパラメーター Helm チャートには次のデフォルトの ​`IngressClass`​ パラメーターと値が含まれます。 ```helm ingressClass.enabled: true ingressClass.name: "{releaseName}-{namespace}" ingressClass.setAsDefault: false ```

パラメーター

説明

可能な値

ingressClass.enabled

Flex Gateway を ​IngressClass​ リソースとして有効化する

true​ または ​false

ingressClass.name

IngressClass​ の名前

任意の文字列

ingressClass.setAsDefault

Flex Gateway をデフォルトの ​IngressClass​ として設定する

true​ または ​false
`ingressClass.setAsDefault: true`​ の設定により、Flex Gateway インスタンスがクラスターのデフォルトの ​`IngressClass`​ リソースとして定義されます。デフォルトの ​`IngressClass`​ は、クラスターに作成するすべての ​`Ingress`​ リソースのデフォルトのイングレスコントローラーになります。 デフォルトの ​`IngressClass`​ がない場合や、デフォルトの ​`IngressClass`​ リソースを特定のリソースのイングレスコントローラーとすることができない場合、​`Ingress`​ リソースでイングレスコントローラーを手動で定義する必要があります。 デフォルトの ​`IngressClass`​ パラメーターは、Helm チャートの初期インストール中または初期インストール後に変更することができます。Helm チャートを変更する方法についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings)を参照してください。 ## [](#イングレスリソースの作成)イングレスリソースの作成 [Helm チャートを名前空間にインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run-up#kubernetes)​したら、次のコマンドを実行して新しい ​`IngressClass`​ リソースを検証できます。 ```helm kubectl get ingressclasses ``` イングレスルーティングを作成する手順は、次のとおりです。 1. [ローカルモードで API をパブリッシュします](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-simple-api#kubernetes)​。 2. 新しい API を Kubernetes サービスとして定義します。 Kubernetes サービス定義についての詳細は、 [「Defining a Service (サービスの定義)」](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)​を参照してください。 3. `kubectl apply`​ を使用して、​`IngressClass`​ Flex Gateway と新しい Kubernetes サービス間のルーティングルールを定義する ​`Ingress`​ リソースを作成します。 ```ssh cat < annotations: flex-gateway.ingress.kubernetes.io/api-instance: . spec: ingressClassName: rules: - http: ... EOF ``` `annotations`​ 項目値は、API の定義時に指定した API インスタンス名および名前空間に一致する必要があります。 ゲートウェイインスタンスをデフォルトのイングレスコントローラーとして設定している場合、​`ingressClassName`​ 項目を省略します。 `Ingress`​ リソースについての詳細は、 [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)​を参照してください。 ## [](#関連情報)関連情報 - [Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management) # ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定 通常、ローカルモードの Kubernetes デプロイメントでは、Flex Gateway は Kubernetes クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。 デフォルトでは、ローカルモードで Kubernetes にデプロイされた Flex Gateway はイングレスコントローラーとして設定され、​`Ingress`​ リソースをコンシュームできます。イングレスコントローラーの設定は、Flex Gateway Helm チャートの ​`IngressClass`​ リソースパラメーターで定義されます。 Kubernetes 用語では、​`IngressClass`​ リソースでゲートウェイをイングレスコントローラーとして設定し、​`Ingress`​ リソースでイングレスコントローラーと、イングレスコントローラーで制御する Kubernetes サービス間のルーティングを設定します。Kubernetes の ​`IngressClass`​ リソースと ​`Ingress`​ リソースについての詳細は、 [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)​ を参照してください。 Helm チャートでは、​`IngressClass`​ 設定を編集したり、イングレスコントローラーの機能を無効にしたりできます。 ## [](#始める前に)始める前に 1. [Kubernetes クラスターで使用する Flex Gateway をダウンロードします](https://docs.mulesoft.com/jp/gateway/1.9/flex-install#kubernetes)​。 2. [ローカルモードの Kubernetes クラスターで Flex Gateway を登録して実行します](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​。 ## [](#イングレスクラスパラメーター)イングレスクラスパラメーター Helm チャートには次のデフォルトの ​`IngressClass`​ パラメーターと値が含まれます。 ```helm ingressClass.enabled: true ingressClass.name: "{releaseName}-{namespace}" ingressClass.setAsDefault: false ```

パラメーター

説明

可能な値

ingressClass.enabled

Flex Gateway を ​IngressClass​ リソースとして有効化する

true​ または ​false

ingressClass.name

IngressClass​ の名前

任意の文字列

ingressClass.setAsDefault

Flex Gateway をデフォルトの ​IngressClass​ として設定する

true​ または ​false
`ingressClass.setAsDefault: true`​ の設定により、Flex Gateway インスタンスがクラスターのデフォルトの ​`IngressClass`​ リソースとして定義されます。デフォルトの ​`IngressClass`​ は、クラスターに作成するすべての ​`Ingress`​ リソースのデフォルトのイングレスコントローラーになります。 デフォルトの ​`IngressClass`​ がない場合や、デフォルトの ​`IngressClass`​ リソースを特定のリソースのイングレスコントローラーとすることができない場合、​`Ingress`​ リソースでイングレスコントローラーを手動で定義する必要があります。 デフォルトの ​`IngressClass`​ パラメーターは、Helm チャートの初期インストール中または初期インストール後に変更することができます。Helm チャートを変更する方法についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings)を参照してください。 ## [](#イングレスリソースの作成)イングレスリソースの作成 [Helm チャートを名前空間にインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run-up#kubernetes)​したら、次のコマンドを実行して新しい ​`IngressClass`​ リソースを検証できます。 ```helm kubectl get ingressclasses ``` イングレスルーティングを作成する手順は、次のとおりです。 1. [ローカルモードで API をパブリッシュします](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-simple-api#kubernetes)​。 2. 新しい API を Kubernetes サービスとして定義します。 Kubernetes サービス定義についての詳細は、 [「Defining a Service (サービスの定義)」](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)​を参照してください。 3. `kubectl apply`​ を使用して、​`IngressClass`​ Flex Gateway と新しい Kubernetes サービス間のルーティングルールを定義する ​`Ingress`​ リソースを作成します。 ```ssh cat < annotations: flex-gateway.ingress.kubernetes.io/api-instance: . spec: ingressClassName: rules: - http: ... EOF ``` `annotations`​ 項目値は、API の定義時に指定した API インスタンス名および名前空間に一致する必要があります。 ゲートウェイインスタンスをデフォルトのイングレスコントローラーとして設定している場合、​`ingressClassName`​ 項目を省略します。 `Ingress`​ リソースについての詳細は、 [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)​を参照してください。 ## [](#関連情報)関連情報 - [Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings) - [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management) # ローカルモードでのシンプルな API のパブリッシュ ローカルモードで Flex Gateway の背後で実行されているシンプルな API をパブリッシュすることで、YAML 設定データを変更する方法をいくつか説明します。 - Linux および Docker: `.yaml`​ ファイル - Kubernetes: `kubectl apply` 下記の手順は、単独のアップストリームサービスを使用した保護されていない API のシンプルな YAML 設定を適用する方法を示しています。

20%

25%

20%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ

Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ
## [](#linux)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`orders-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: orders-api spec: address: http://0.0.0.0:8080 services: orders: address: https://:/ routes: - rules: - path: /api/orders(/.\*) 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/animal-facts-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/orders(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:orders-api-orders Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/orders-api-orders https://:/ \[agent\]\[debug\] generating service orders-api-orders.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) シンプルな API は Flex Gateway の背後で実行されています。 ## [](#docker)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`orders-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: orders-api spec: address: http://0.0.0.0:8080 services: orders: address: https://:/ routes: - rules: - path: /api/orders(/.\*) 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/animal-facts-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/orders(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:orders-api-orders Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/orders-api-orders https://:/ \[agent\]\[debug\] generating service orders-api-orders.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) シンプルな API は Flex Gateway の背後で実行されています。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-3)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Docker リポジトリに Docker イメージが保存されている。次の例では架空の ​`orders-api`​ というアプリケーションを参照していますが、​`Deployment`​ 設定リソース (​`spec.spec.image`​ 内) には実際の Docker リポジトリと Docker イメージを指定することができます。 アップストリームサービスとして [Kubernetes サービス](https://kubernetes.io/docs/concepts/services-networking/service/)​を使用しているか、Kubernetes サービスに対する要求を行うポリシーを適用する場合は、​`service`​ リソースで次のパラメーターを設定します。 - `spec.ports[].protocol`​ を ​`TCP`​ に - `spec.ports[].name` `spec.ports[].name`​ サービスは ​`[-]`​ 構造に準拠している必要があります。 `[-]`​ は省略可能であり、​``​ の有効なオプションは次のとおりです。 - HTTP - H2 - HTTPS ### [](#api-のパブリッシュ-3)API のパブリッシュ 1. `kubectl apply`​ コマンドを使用して、特定のリポジトリから「orders-api」という名前の Docker イメージをインストールします。 次の YAML スニペットでは、​`Service`​ と ​`Deployment`​ という 2 つの設定リソースを定義しています。​`Service`​ リソースは ​`orders-api`​ サービスを宣言します。​`Deployment`​ リソースは、作成するレプリカ数やサイドローディングする Docker イメージなどの情報を指定することで、目的のデプロイメント状態を宣言します。 cat </ imagePullPolicy: IfNotPresent name: orders-api ports: - name: http containerPort: 3000 resources: limits: cpu: 100m memory: 64Mi EOF 2. 再び ​`kubectl apply`​ を使用して、トラフィックをルーティングするイングレスを作成します。 次の YAML 例では、​`Ingress`​ という設定リソースを定義しています。 cat < # ローカルモードでのシンプルな API のパブリッシュ ローカルモードで Flex Gateway の背後で実行されているシンプルな API をパブリッシュすることで、YAML 設定データを変更する方法をいくつか説明します。 - Linux および Docker: `.yaml`​ ファイル - Kubernetes: `kubectl apply` 下記の手順は、単独のアップストリームサービスを使用した保護されていない API のシンプルな YAML 設定を適用する方法を示しています。

20%

25%

20%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ

Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ
## [](#linux)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`orders-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: orders-api spec: address: http://0.0.0.0:8080 services: orders: address: https://:/ routes: - rules: - path: /api/orders(/.\*) 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/animal-facts-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/orders(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:orders-api-orders Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/orders-api-orders https://:/ \[agent\]\[debug\] generating service orders-api-orders.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) シンプルな API は Flex Gateway の背後で実行されています。 ## [](#docker)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`orders-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: orders-api spec: address: http://0.0.0.0:8080 services: orders: address: https://:/ routes: - rules: - path: /api/orders(/.\*) 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/animal-facts-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/orders(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:orders-api-orders Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/orders-api-orders https://:/ \[agent\]\[debug\] generating service orders-api-orders.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) シンプルな API は Flex Gateway の背後で実行されています。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-3)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Docker リポジトリに Docker イメージが保存されている。次の例では架空の ​`orders-api`​ というアプリケーションを参照していますが、​`Deployment`​ 設定リソース (​`spec.spec.image`​ 内) には実際の Docker リポジトリと Docker イメージを指定することができます。 アップストリームサービスとして [Kubernetes サービス](https://kubernetes.io/docs/concepts/services-networking/service/)​を使用しているか、Kubernetes サービスに対する要求を行うポリシーを適用する場合は、​`service`​ リソースで次のパラメーターを設定します。 - `spec.ports[].protocol`​ を ​`TCP`​ に - `spec.ports[].name` `spec.ports[].name`​ サービスは ​`[-]`​ 構造に準拠している必要があります。 `[-]`​ は省略可能であり、​``​ の有効なオプションは次のとおりです。 - HTTP - H2 - HTTPS ### [](#api-のパブリッシュ-3)API のパブリッシュ 1. `kubectl apply`​ コマンドを使用して、特定のリポジトリから「orders-api」という名前の Docker イメージをインストールします。 次の YAML スニペットでは、​`Service`​ と ​`Deployment`​ という 2 つの設定リソースを定義しています。​`Service`​ リソースは ​`orders-api`​ サービスを宣言します。​`Deployment`​ リソースは、作成するレプリカ数やサイドローディングする Docker イメージなどの情報を指定することで、目的のデプロイメント状態を宣言します。 cat </ imagePullPolicy: IfNotPresent name: orders-api ports: - name: http containerPort: 3000 resources: limits: cpu: 100m memory: 64Mi EOF 2. 再び ​`kubectl apply`​ を使用して、トラフィックをルーティングするイングレスを作成します。 次の YAML 例では、​`Ingress`​ という設定リソースを定義しています。 cat < # ローカルモードでのシンプルな API のパブリッシュ ローカルモードで Flex Gateway の背後で実行されているシンプルな API をパブリッシュすることで、YAML 設定データを変更する方法をいくつか説明します。 - Linux および Docker: `.yaml`​ ファイル - Kubernetes: `kubectl apply` 下記の手順は、単独のアップストリームサービスを使用した保護されていない API のシンプルな YAML 設定を適用する方法を示しています。

20%

25%

20%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ

Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ
## [](#linux)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`orders-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: orders-api spec: address: http://0.0.0.0:8080 services: orders: address: https://:/ routes: - rules: - path: /api/orders(/.\*) 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/animal-facts-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/orders(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:orders-api-orders Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/orders-api-orders https://:/ \[agent\]\[debug\] generating service orders-api-orders.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) シンプルな API は Flex Gateway の背後で実行されています。 ## [](#docker)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`orders-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: orders-api spec: address: http://0.0.0.0:8080 services: orders: address: https://:/ routes: - rules: - path: /api/orders(/.\*) 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/animal-facts-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/orders(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:orders-api-orders Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/orders-api-orders https://:/ \[agent\]\[debug\] generating service orders-api-orders.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) シンプルな API は Flex Gateway の背後で実行されています。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-3)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Docker リポジトリに Docker イメージが保存されている。次の例では架空の ​`orders-api`​ というアプリケーションを参照していますが、​`Deployment`​ 設定リソース (​`spec.spec.image`​ 内) には実際の Docker リポジトリと Docker イメージを指定することができます。 アップストリームサービスとして [Kubernetes サービス](https://kubernetes.io/docs/concepts/services-networking/service/)​を使用しているか、Kubernetes サービスに対する要求を行うポリシーを適用する場合は、​`service`​ リソースで次のパラメーターを設定します。 - `spec.ports[].protocol`​ を ​`TCP`​ に - `spec.ports[].name` `spec.ports[].name`​ サービスは ​`[-]`​ 構造に準拠している必要があります。 `[-]`​ は省略可能であり、​``​ の有効なオプションは次のとおりです。 - HTTP - H2 - HTTPS ### [](#api-のパブリッシュ-3)API のパブリッシュ 1. `kubectl apply`​ コマンドを使用して、特定のリポジトリから「orders-api」という名前の Docker イメージをインストールします。 次の YAML スニペットでは、​`Service`​ と ​`Deployment`​ という 2 つの設定リソースを定義しています。​`Service`​ リソースは ​`orders-api`​ サービスを宣言します。​`Deployment`​ リソースは、作成するレプリカ数やサイドローディングする Docker イメージなどの情報を指定することで、目的のデプロイメント状態を宣言します。 cat </ imagePullPolicy: IfNotPresent name: orders-api ports: - name: http containerPort: 3000 resources: limits: cpu: 100m memory: 64Mi EOF 2. 再び ​`kubectl apply`​ を使用して、トラフィックをルーティングするイングレスを作成します。 次の YAML 例では、​`Ingress`​ という設定リソースを定義しています。 cat < # ローカルモードでのタイムアウトの設定 Flex Gateway では、サービス品質を改善して計算リソースの無駄を減らせるように次のタイムアウトが提供されます。 - **ストリームアイドルタイムアウト**​ ストリームアイドルタイムアウトでは、ストリームがインバウンド (クライアントから Flex Gateway) またはアウトバウンド (Flex Gateway からアップストリームサービス) 方向のデータを受信せずにアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 300 秒のストリームタイムアウトが設定されています。 - **アップストリームアイドルタイムアウト**​ アップストリームアイドルタイムアウトでは、Flex Gateway とアップストリームサービス間のストリームが要求から要求までの間にアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 60 秒のアップストリームタイムアウトが設定されています。 - **Response Timeout (応答タイムアウト)**​ 応答タイムアウトでは、Flex Gateway がアップストリームサービスからの応答を待機する最大時間を設定できます。タイムアウトの時間は Flex Gateway によって最後の要求が送信された時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 15 秒の応答タイムアウトが設定されています。 これらのタイムアウトは以下によって設定できます。 - 環境変数: すべての API インスタンスが適用され、最も永続的な設定オプションです。 - 設定 YAML ファイル: すべての API インスタンスが適用され、調整が簡単です。 - ポリシー: 1 つの API インスタンスまたはアップストリームのみが適用され、きめ細かく設定でき、調整が簡単です。 ## [](#環境変数を使用したタイムアウトの設定)環境変数を使用したタイムアウトの設定 次の環境変数を使用してタイムアウトを設定します。 FLEX\_STREAM\_IDLE\_TIMEOUT\_SECONDS: 300 FLEX\_UPSTREAM\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS/FLEX\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS: 60 FLEX\_UPSTREAM\_RESPONSE\_TIMEOUT\_SECONDS: 15 目的の設定を使用して変数を編集します。 ## [](#yaml-設定リソースを使用したタイムアウトの設定)YAML 設定リソースを使用したタイムアウトの設定 この設定リソースを編集してから適用し、タイムアウトを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: timeouts-config spec: timeouts: upstreamConnectionIdleSeconds: 300 upstreamResponseSeconds: 15 streamIdleSeconds: 60 ``` ## [](#ポリシーを使用したタイムアウトの設定)ポリシーを使用したタイムアウトの設定 このポリシーを API インスタンスまたはアップストリームサービスに適用します。 - [ストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-stream-idle-timeout) - [アップストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-outbound-upstream-idle-timeout) - [応答タイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-response-timeout) # ローカルモードでのタイムアウトの設定 Flex Gateway では、サービス品質を改善して計算リソースの無駄を減らせるように次のタイムアウトが提供されます。 - **ストリームアイドルタイムアウト**​ ストリームアイドルタイムアウトでは、ストリームがインバウンド (クライアントから Flex Gateway) またはアウトバウンド (Flex Gateway からアップストリームサービス) 方向のデータを受信せずにアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 300 秒のストリームタイムアウトが設定されています。 - **アップストリームアイドルタイムアウト**​ アップストリームアイドルタイムアウトでは、Flex Gateway とアップストリームサービス間のストリームが要求から要求までの間にアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 60 秒のアップストリームタイムアウトが設定されています。 - **Response Timeout (応答タイムアウト)**​ 応答タイムアウトでは、Flex Gateway がアップストリームサービスからの応答を待機する最大時間を設定できます。タイムアウトの時間は Flex Gateway によって最後の要求が送信された時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 15 秒の応答タイムアウトが設定されています。 これらのタイムアウトは以下によって設定できます。 - 環境変数: すべての API インスタンスが適用され、最も永続的な設定オプションです。 - 設定 YAML ファイル: すべての API インスタンスが適用され、調整が簡単です。 - ポリシー: 1 つの API インスタンスまたはアップストリームのみが適用され、きめ細かく設定でき、調整が簡単です。 ## [](#環境変数を使用したタイムアウトの設定)環境変数を使用したタイムアウトの設定 次の環境変数を使用してタイムアウトを設定します。 FLEX\_STREAM\_IDLE\_TIMEOUT\_SECONDS: 300 FLEX\_UPSTREAM\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS/FLEX\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS: 60 FLEX\_UPSTREAM\_RESPONSE\_TIMEOUT\_SECONDS: 15 目的の設定を使用して変数を編集します。 ## [](#yaml-設定リソースを使用したタイムアウトの設定)YAML 設定リソースを使用したタイムアウトの設定 この設定リソースを編集してから適用し、タイムアウトを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: timeouts-config spec: timeouts: upstreamConnectionIdleSeconds: 300 upstreamResponseSeconds: 15 streamIdleSeconds: 60 ``` ## [](#ポリシーを使用したタイムアウトの設定)ポリシーを使用したタイムアウトの設定 このポリシーを API インスタンスまたはアップストリームサービスに適用します。 - [ストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-stream-idle-timeout) - [アップストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-outbound-upstream-idle-timeout) - [応答タイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-response-timeout) # ローカルモードでのポリシーの適用 ローカルモードで実行されている Flex Gateway では、​[ローカルの宣言型設定ファイル](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)​を使用して API ポリシーを適用します。最初に Flex Gateway を実行するときに、この設定ファイルの場所を指定します。 ゲートウェイの開始方法についての詳細は、[ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)を参照してください。 ローカルモードで API にポリシーを適用する方法の例は、次のチュートリアルを参照してください。 - [基本認証とレート制限を使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-secure-api-with-basic-auth-policy) - [リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-secure-api-with-auto-policy) - [カスタムポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-deploy-custom-policy) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) # ローカルモードでのポリシーの適用 ローカルモードで実行されている Flex Gateway では、​[ローカルの宣言型設定ファイル](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)​を使用して API ポリシーを適用します。最初に Flex Gateway を実行するときに、この設定ファイルの場所を指定します。 ゲートウェイの開始方法についての詳細は、[ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)を参照してください。 ローカルモードで API にポリシーを適用する方法の例は、次のチュートリアルを参照してください。 - [基本認証とレート制限を使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-secure-api-with-basic-auth-policy) - [リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-secure-api-with-auto-policy) - [カスタムポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-deploy-custom-policy) ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) # ローカルモードでの監視 ローカルモードで実行されている Flex Gateway を使用すると、Anypoint Platform とは関係なく API を監視できます。宣言型設定ファイルを使用して、ログをさまざまな Fluent Bit 出力に配信するように Flex Gateway を設定します。 ローカルモードでの監視についての詳細は、次のタスクを参照してください。 - [ローカルモードでの Flex Gateway の外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-third-party-logs-config)​ - Fluent Bit 出力種別のログ出力を設定します。出力種別には、​`[File (ファイル)]`​、​`[HTTP]`​、​`[Splunk]`​ があります。 - [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-view-logs)​ - Flex Gateway 標準出力ログを表示します。外部サービスと API 要求の状況をすばやく検証します。 # ローカルモードでの監視 ローカルモードで実行されている Flex Gateway を使用すると、Anypoint Platform とは関係なく API を監視できます。宣言型設定ファイルを使用して、ログをさまざまな Fluent Bit 出力に配信するように Flex Gateway を設定します。 ローカルモードでの監視についての詳細は、次のタスクを参照してください。 - [ローカルモードでの Flex Gateway の外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-third-party-logs-config)​ - Fluent Bit 出力種別のログ出力を設定します。出力種別には、​`[File (ファイル)]`​、​`[HTTP]`​、​`[Splunk]`​ があります。 - [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-view-logs)​ - Flex Gateway 標準出力ログを表示します。外部サービスと API 要求の状況をすばやく検証します。 # ローカルモードでの監視 ローカルモードで実行されている Flex Gateway を使用すると、Anypoint Platform とは関係なく API を監視できます。宣言型設定ファイルを使用して、ログをさまざまな Fluent Bit 出力に配信するように Flex Gateway を設定します。 ローカルモードでの監視についての詳細は、次のタスクを参照してください。 - [ローカルモードでの Flex Gateway の外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-third-party-logs-config)​ - Fluent Bit 出力種別のログ出力を設定します。出力種別には、​`[File (ファイル)]`​、​`[HTTP]`​、​`[Splunk]`​ があります。 - [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-view-logs)​ - Flex Gateway 標準出力ログを表示します。外部サービスと API 要求の状況をすばやく検証します。 # ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ ローカルモードで実行されている Flex Gateway は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスをサポートしています。 Flex Gateway は、定義済みのルート順になっている複数のルートと個別のルールセットを使用してトラフィックを異なるセットのアップストリームサービスに転送することで、トラフィックを管理します。各 API インスタンスでは、トラフィックを複数のアップストリームサービスに転送できる複数のルートがサポートされます。 ローカルモードで実行されている Flex Gateway では、複数のアップストリームサービスがある API インスタンスは ​`ApiInstance`​ および ​`PolicyBinding`​ YAML 設定リソースを使用して設定されます。​`ApiInstance`​ リソースでは API インスタンスが定義され、​`route-weighted`​ ポリシーリソースでは 1 つ以上のアップストリームサービスへの 1 つのルートが定義されます。ルートをさらに追加するには、複数の ​`route-weighted`​ リソースを追加します。 次のチュートリアルでは、事前設定済みの ​`route-weighted`​ ポリシーリソースを使用しています。リソースの設定方法については、[複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-traffic-management)を参照してください。

20%

25%

20%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ

Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ
## [](#linux)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、設定項目値を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 複数のアップストリームサービスを使用した API は Flex Gateway の背後で実行されるようになりました。 ## [](#docker)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、設定項目を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 複数のアップストリームサービスを使用した API は Flex Gateway の背後で実行されています。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-3)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 アップストリームサービスとして [Kubernetes サービス](https://kubernetes.io/docs/concepts/services-networking/service/)​を使用しているか、Kubernetes サービスに対する要求を行うポリシーを適用する場合は、​`service`​ リソースで次のパラメーターを設定します。 - `spec.ports[].protocol`​ を ​`TCP`​ に - `spec.ports[].name` `spec.ports[].name`​ サービスは ​`[-]`​ 構造に準拠している必要があります。 `[-]`​ は省略可能であり、​``​ の有効なオプションは次のとおりです。 - HTTP - H2 - HTTPS ### [](#api-のパブリッシュ-3)API のパブリッシュ 1. `kubectl apply`​ コマンドを使用して次の ​`.yaml`​ 設定ファイルを適用し、設定項目値を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 2. 次のコマンドを入力してポッドログを表示し、API が正常に作成されたことを確認します。 kubectl logs -f # ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ ローカルモードで実行されている Flex Gateway は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスをサポートしています。 Flex Gateway は、定義済みのルート順になっている複数のルートと個別のルールセットを使用してトラフィックを異なるセットのアップストリームサービスに転送することで、トラフィックを管理します。各 API インスタンスでは、トラフィックを複数のアップストリームサービスに転送できる複数のルートがサポートされます。 ローカルモードで実行されている Flex Gateway では、複数のアップストリームサービスがある API インスタンスは ​`ApiInstance`​ および ​`PolicyBinding`​ YAML 設定リソースを使用して設定されます。​`ApiInstance`​ リソースでは API インスタンスが定義され、​`route-weighted`​ ポリシーリソースでは 1 つ以上のアップストリームサービスへの 1 つのルートが定義されます。ルートをさらに追加するには、複数の ​`route-weighted`​ リソースを追加します。 次のチュートリアルでは、事前設定済みの ​`route-weighted`​ ポリシーリソースを使用しています。リソースの設定方法については、[複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-traffic-management)を参照してください。

20%

25%

20%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ

Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ
## [](#linux)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、設定項目値を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 複数のアップストリームサービスを使用した API は Flex Gateway の背後で実行されるようになりました。 ## [](#docker)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、設定項目を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 複数のアップストリームサービスを使用した API は Flex Gateway の背後で実行されています。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-3)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 アップストリームサービスとして [Kubernetes サービス](https://kubernetes.io/docs/concepts/services-networking/service/)​を使用しているか、Kubernetes サービスに対する要求を行うポリシーを適用する場合は、​`service`​ リソースで次のパラメーターを設定します。 - `spec.ports[].protocol`​ を ​`TCP`​ に - `spec.ports[].name` `spec.ports[].name`​ サービスは ​`[-]`​ 構造に準拠している必要があります。 `[-]`​ は省略可能であり、​``​ の有効なオプションは次のとおりです。 - HTTP - H2 - HTTPS ### [](#api-のパブリッシュ-3)API のパブリッシュ 1. `kubectl apply`​ コマンドを使用して次の ​`.yaml`​ 設定ファイルを適用し、設定項目値を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 2. 次のコマンドを入力してポッドログを表示し、API が正常に作成されたことを確認します。 kubectl logs -f # ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ ローカルモードで実行されている Flex Gateway は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスをサポートしています。 Flex Gateway は、定義済みのルート順になっている複数のルートと個別のルールセットを使用してトラフィックを異なるセットのアップストリームサービスに転送することで、トラフィックを管理します。各 API インスタンスでは、トラフィックを複数のアップストリームサービスに転送できる複数のルートがサポートされます。 ローカルモードで実行されている Flex Gateway では、複数のアップストリームサービスがある API インスタンスは ​`ApiInstance`​ および ​`PolicyBinding`​ YAML 設定リソースを使用して設定されます。​`ApiInstance`​ リソースでは API インスタンスが定義され、​`route-weighted`​ ポリシーリソースでは 1 つ以上のアップストリームサービスへの 1 つのルートが定義されます。ルートをさらに追加するには、複数の ​`route-weighted`​ リソースを追加します。 次のチュートリアルでは、事前設定済みの ​`route-weighted`​ ポリシーリソースを使用しています。リソースの設定方法については、[複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-traffic-management)を参照してください。

20%

25%

20%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ

Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ
## [](#linux)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、設定項目値を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 複数のアップストリームサービスを使用した API は Flex Gateway の背後で実行されるようになりました。 ## [](#docker)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、設定項目を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 複数のアップストリームサービスを使用した API は Flex Gateway の背後で実行されています。 ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-3)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がダウンロード済みである。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Flex Gateway が登録済みで、ローカルモードで実行されている。詳細は、​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。 アップストリームサービスとして [Kubernetes サービス](https://kubernetes.io/docs/concepts/services-networking/service/)​を使用しているか、Kubernetes サービスに対する要求を行うポリシーを適用する場合は、​`service`​ リソースで次のパラメーターを設定します。 - `spec.ports[].protocol`​ を ​`TCP`​ に - `spec.ports[].name` `spec.ports[].name`​ サービスは ​`[-]`​ 構造に準拠している必要があります。 `[-]`​ は省略可能であり、​``​ の有効なオプションは次のとおりです。 - HTTP - H2 - HTTPS ### [](#api-のパブリッシュ-3)API のパブリッシュ 1. `kubectl apply`​ コマンドを使用して次の ​`.yaml`​ 設定ファイルを適用し、設定項目値を適切な値に変更します。 次のスニペットでは架空の ​`products-api`​ と ​`products-api-beta`​ というサービスと架空の ​`json-http`​ API インスタンスを使用しています。各自の API 参照名と各自のサービスの詳細を指定してください。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-http spec: address: http://0.0.0.0:8080/json ​ --- ​ apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: weight-routing-test spec: targetRef: name: json-http policyRef: name: route-weighted config: routes: - weight: 75 # max\_value=100, min\_value=1 destinationPath: /posts/ destinationRef: name: products-api - weight: 25 destinationPath: /posts/ destinationRef: name: products-api-beta rules: - path: (.\*) methods: POST headers: x-test: true host: test.com - methods: GET|POST headers: x-test: true y-test: false host: test.com 2. 次のコマンドを入力してポッドログを表示し、API が正常に作成されたことを確認します。 kubectl logs -f # ローカルモードでユーザー名とパスワードを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーの​**ユーザー名**​と​**パスワード** ## [](#linux)ユーザー名とパスワードを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)ユーザー名とパスワードを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)ユーザー名とパスワードを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)ユーザー名とパスワードを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)ユーザー名とパスワードを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)ユーザー名とパスワードを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) # ローカルモードでユーザー名とパスワードを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーの​**ユーザー名**​と​**パスワード** ## [](#linux)ユーザー名とパスワードを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)ユーザー名とパスワードを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)ユーザー名とパスワードを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)ユーザー名とパスワードを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)ユーザー名とパスワードを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)ユーザー名とパスワードを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) # ローカルモードでユーザー名とパスワードを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーの​**ユーザー名**​と​**パスワード** ## [](#linux)ユーザー名とパスワードを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)ユーザー名とパスワードを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)ユーザー名とパスワードを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)ユーザー名とパスワードを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)ユーザー名とパスワードを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)ユーザー名とパスワードを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) # ローカルモードで接続アプリケーションを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [接続アプリケーションの設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app) - 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#linux)接続アプリケーションを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)接続アプリケーションを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)接続アプリケーションを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)接続アプリケーションを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)接続アプリケーションを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)接続アプリケーションを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) # ローカルモードで接続アプリケーションを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [接続アプリケーションの設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app) - 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#linux)接続アプリケーションを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)接続アプリケーションを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)接続アプリケーションを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)接続アプリケーションを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)接続アプリケーションを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)接続アプリケーションを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) # ローカルモードで接続アプリケーションを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [接続アプリケーションの設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app) - 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#linux)接続アプリケーションを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` ## [](#container)接続アプリケーションを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)接続アプリケーションを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ### [](#podman)接続アプリケーションを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
#### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
出力ログには次の行が含まれます。 ```ssh [flex-gateway-envoy][info] all dependencies initialized. starting workers ``` ## [](#kubernetes)接続アプリケーションを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)接続アプリケーションを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイします。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、ローカルモードの Flex Gateway は、クラスターへの外部アクセスを管理するイングレスコントローラーとして機能します。Flex Gateway は、内部 (east-west) トラフィックのスタンドアロンゲートウェイとして機能することもできます。 このモードを使用する場合、作成および適用するリソースを把握して、​`kubectl apply`​ を使用して Kubernetes 対象およびリソース (API、ポリシー、Flex Gateway 関連のリソース) をゲートウェイにデプロイする必要があります。 `Ingress`​ リソースを適用してゲートウェイルーティングルールを設定すると、Flex Gateway はイングレスコントローラーとして機能します。YAML ファイルを介してこの設定を行います。このファイルでは、ロードバランサーまたはプロキシサーバー、および HTTP と HTTPS トラフィックを転送する​`ルール`​を設定するための他のプロパティ (​`apiVersion`​、​`kind`​、​`metadata`​、​`spec`​ など) がサポートされています。Flex Gateway での ​`Ingress`​ リソースの管理方法についての詳細は、[ローカルモードでのイングレスコントローラーとしての Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-ingress-class)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
**Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. ローカルモードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 ### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) # ログイン情報挿入 OAuth 2.0 ポリシー

ポリシー名

ログイン情報挿入 OAuth 2.0

概要

発信要求に OAuth 2.0 認証ヘッダーを挿入する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

このポリシーの戻りコードは存在しません。アップストリームサービスからエラーコードが返されます。
## [](#概要)概要 ログイン情報挿入 OAuth 2.0 ポリシーでは、OAuth 2.0 サービスから取得した ​`Authorization`​ トークンをヘッダーとして要求に挿入します。Okta、AWS、Azure、Google Cloud Platform などのサードパーティ OAuth 2.0 ID プロバイダー (IdP) を使用できます。このポリシーでは、Anypoint Platform に外部 IdP サーバーを登録しなくても、OAuth 2.0 認証フレームワークに基づくトークンを要求に挿入できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: credential-injection-oauth2-flex config: oauthService: // REQUIRED clientId: // REQUIRED clientSecret: // REQUIRED scope: - // OPTIONAL overwrite: // OPTIONAL tokenFetchTimeout: // OPTIONAL allowRequestWithoutCredential: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

oauthService

必須

https://oauth-server/tokens

OAuth 2.0 サービスの URL。

clientId

必須

なし

クライアント ID。

clientSecret

必須

なし

クライアントシークレット。

scope

省略可能

なし

トークンに含めるスコープ。

overwrite

省略可能

true

有効になっていると、ヘッダーが存在する場合に、新しい認証トークンを使用してこのポリシーで ​Authorization​ ヘッダーを上書きします。

tokenFetchTimeout

必須

10

サービスがトークンを返すまでに待機する秒数。

allowRequestWithoutCredential

必須

false

有効になっていると、ポリシーがトークンを取得できない場合でも Flex Gateway は要求を送信します。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: credential-injection-oauth2-flex config: oauthService: clientId: id clientSecret: secret scope: - user tokenFetchTimeout: 20 allowRequestWithoutCredential: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

OAuth 2.0 service URL (OAuth 2.0 サービス URL)

OAuth 2.0 サービスの URL。

必須

Client ID (クライアント ID)

クライアント ID。

必須

Client secret (クライアントシークレット)

クライアントシークレット。

必須

Scope (スコープ)

トークンに含めるスコープ。

省略可能

Overwrite header (ヘッダーを上書き)

有効になっていると、ヘッダーが存在する場合に、新しい認証トークンを使用してこのポリシーで ​Authorization​ ヘッダーを上書きします。

必須

Token fetch timeout (トークン取得タイムアウト)

サービスがトークンを返すまでに待機する秒数。

必須

Allow request without credential (ログイン情報のない要求を許可)

有効になっていると、ポリシーがトークンを取得できない場合でも Flex Gateway は要求を送信します。

必須
# ログイン情報挿入 OAuth 2.0 ポリシー

ポリシー名

ログイン情報挿入 OAuth 2.0

概要

発信要求に OAuth 2.0 認証ヘッダーを挿入する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

このポリシーの戻りコードは存在しません。アップストリームサービスからエラーコードが返されます。
## [](#概要)概要 ログイン情報挿入 OAuth 2.0 ポリシーでは、OAuth 2.0 サービスから取得した ​`Authorization`​ トークンをヘッダーとして要求に挿入します。Okta、AWS、Azure、Google Cloud Platform などのサードパーティ OAuth 2.0 ID プロバイダー (IdP) を使用できます。このポリシーでは、Anypoint Platform に外部 IdP サーバーを登録しなくても、OAuth 2.0 認証フレームワークに基づくトークンを要求に挿入できます。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: credential-injection-oauth2-flex config: oauthService: // REQUIRED clientId: // REQUIRED clientSecret: // REQUIRED scope: - // OPTIONAL overwrite: // OPTIONAL tokenFetchTimeout: // OPTIONAL allowRequestWithoutCredential: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

oauthService

必須

https://oauth-server/tokens

OAuth 2.0 サービスの URL。

clientId

必須

なし

クライアント ID。

clientSecret

必須

なし

クライアントシークレット。

scope

省略可能

なし

トークンに含めるスコープ。

overwrite

省略可能

true

有効になっていると、ヘッダーが存在する場合に、新しい認証トークンを使用してこのポリシーで ​Authorization​ ヘッダーを上書きします。

tokenFetchTimeout

必須

10

サービスがトークンを返すまでに待機する秒数。

allowRequestWithoutCredential

必須

false

有効になっていると、ポリシーがトークンを取得できない場合でも Flex Gateway は要求を送信します。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: credential-injection-oauth2-flex config: oauthService: clientId: id clientSecret: secret scope: - user tokenFetchTimeout: 20 allowRequestWithoutCredential: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

OAuth 2.0 service URL (OAuth 2.0 サービス URL)

OAuth 2.0 サービスの URL。

必須

Client ID (クライアント ID)

クライアント ID。

必須

Client secret (クライアントシークレット)

クライアントシークレット。

必須

Scope (スコープ)

トークンに含めるスコープ。

省略可能

Overwrite header (ヘッダーを上書き)

有効になっていると、ヘッダーが存在する場合に、新しい認証トークンを使用してこのポリシーで ​Authorization​ ヘッダーを上書きします。

必須

Token fetch timeout (トークン取得タイムアウト)

サービスがトークンを返すまでに待機する秒数。

必須

Allow request without credential (ログイン情報のない要求を許可)

有効になっていると、ポリシーがトークンを取得できない場合でも Flex Gateway は要求を送信します。

必須
# ログイン情報挿入基本認証ポリシー

ポリシー名

ログイン情報挿入基本認証

概要

発信要求に基本認証ヘッダーを挿入する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

このポリシーの戻りコードは存在しません。アップストリームサービスからエラーコードが返されます。
## [](#概要)概要 ログイン情報挿入基本認証ポリシーでは、ユーザー名とパスワードが含まれる ​`Authorization`​ ヘッダーを発信要求に挿入します。このポリシーにより、Flex Gateway からアップストリームサービスに送信される要求に必ず適切な認証ヘッダーが含まれるようになります。認証ヘッダーの形式は ​`Authorization: Basic `​ です。 このポリシーは、 [基本 HTTP 認証標準](https://tools.ietf.org/html/rfc7617)​に準拠します。 エラーが発生すると、このポリシーは ​`WWW-Authenticate`​ HTTP ヘッダー項目を返します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: credential-injection-basic-auth-flex config: username: // OPTIONAL password: // OPTIONAL overwrite: // OPTIONAL customHeader: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

username

省略可能

なし

基本認証ログイン情報に使用するユーザー名。

password

省略可能

なし

基本認証ログイン情報に使用するパスワード。

overwrite

省略可能

true

有効になっていると、​Authorization​ ヘッダーが存在する場合に、設定済みのログイン情報を使用してこのポリシーで上書きします。

customHeader

省略可能

なし

設定されている場合、​Authorization​ ヘッダーではなくカスタムヘッダーが挿入されます。​[Overwrite header (ヘッダーを上書き)]​ が有効になっていると、このポリシーにより、​Authorization​ ヘッダーではなくカスタムヘッダーを上書きします (存在する場合)。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

Username (ユーザー名)

基本認証ログイン情報に使用するユーザー名。

省略可能

Password (パスワード)

基本認証ログイン情報に使用するパスワード。

省略可能

Overwrite header (ヘッダーを上書き)

有効になっていると、​Authorization​ ヘッダーが存在する場合に、設定済みのログイン情報を使用してこのポリシーで上書きします。

省略可能

カスタムヘッダー

設定されている場合、​Authorization​ ヘッダーではなくカスタムヘッダーが挿入されます。​[Overwrite header (ヘッダーを上書き)]​ が有効になっていると、このポリシーにより、​Authorization​ ヘッダーではなくカスタムヘッダーを上書きします (存在する場合)。

省略可能
# ログイン情報挿入基本認証ポリシー

ポリシー名

ログイン情報挿入基本認証

概要

発信要求に基本認証ヘッダーを挿入する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

このポリシーの戻りコードは存在しません。アップストリームサービスからエラーコードが返されます。
## [](#概要)概要 ログイン情報挿入基本認証ポリシーでは、ユーザー名とパスワードが含まれる ​`Authorization`​ ヘッダーを発信要求に挿入します。このポリシーにより、Flex Gateway からアップストリームサービスに送信される要求に必ず適切な認証ヘッダーが含まれるようになります。認証ヘッダーの形式は ​`Authorization: Basic `​ です。 このポリシーは、 [基本 HTTP 認証標準](https://tools.ietf.org/html/rfc7617)​に準拠します。 エラーが発生すると、このポリシーは ​`WWW-Authenticate`​ HTTP ヘッダー項目を返します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: credential-injection-basic-auth-flex config: username: // OPTIONAL password: // OPTIONAL overwrite: // OPTIONAL customHeader: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

username

省略可能

なし

基本認証ログイン情報に使用するユーザー名。

password

省略可能

なし

基本認証ログイン情報に使用するパスワード。

overwrite

省略可能

true

有効になっていると、​Authorization​ ヘッダーが存在する場合に、設定済みのログイン情報を使用してこのポリシーで上書きします。

customHeader

省略可能

なし

設定されている場合、​Authorization​ ヘッダーではなくカスタムヘッダーが挿入されます。​[Overwrite header (ヘッダーを上書き)]​ が有効になっていると、このポリシーにより、​Authorization​ ヘッダーではなくカスタムヘッダーを上書きします (存在する場合)。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明 必須

Username (ユーザー名)

基本認証ログイン情報に使用するユーザー名。

省略可能

Password (パスワード)

基本認証ログイン情報に使用するパスワード。

省略可能

Overwrite header (ヘッダーを上書き)

有効になっていると、​Authorization​ ヘッダーが存在する場合に、設定済みのログイン情報を使用してこのポリシーで上書きします。

省略可能

カスタムヘッダー

設定されている場合、​Authorization​ ヘッダーではなくカスタムヘッダーが挿入されます。​[Overwrite header (ヘッダーを上書き)]​ が有効になっていると、このポリシーにより、​Authorization​ ヘッダーではなくカスタムヘッダーを上書きします (存在する場合)。

省略可能
# ログの問題のトラブルシューティング Anypoint Flex Gateway のログを設定しているときに、正しくないディレクトリ権限などによるログの問題が発生することがあります。以下のトピックでは、ログの問題の考えられる原因とトラブルシューティング方法について説明します。 - [ログがサードパーティログサービスに表示されない](#third-party-service) - [VM での動作中にログが表示されない](#incorrect-permissions) ## [](#third-party-service)ログがサードパーティログサービスに表示されない ログ設定 YAML ファイルを適用すると、数分以内にログが表示され始めます。ログがサードパーティログサービスに表示されない場合は、次の手順を実行してください。 1. サードパーティサービスが実行されていることを確認します。 2. サービスが実行されている場合は、ランタイムログで設定エラーがないか確認します。 [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-view-logs). Additionally, for Flex Gateways running in Connected Mode, you can [view runtime logs in Runtime Manager](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager)​ の手順に従い、接続モードとローカルモードのどちらで実行されている Flex Gateway のランタイムログでも表示できます。 潜在的な設定エラーは、次のように表示されます。 \[flex-gateway-fluent\] \[2023/09/07 20:17:49\] \[error\] \[output:http:http.1\] hzk83039.live.dynatrace.com:443, HTTP status=401 \[flex-gateway-fluent\] {"error":{"code":401,"message":"Missing authorization parameter."}} \[flex-gateway-fluent\] \[2023/09/07 20:17:49\] \[ warn\] \[engine\] failed to flush chunk '20-1694117863.683606251.flb', retry in 7 seconds: task\_id=2, input=emitter\_for\_rewrite\_tag.11 > output=http.1 (out\_id=1) 3. 設定エラーがランタイムログに表示されているかどうかに関係なく、/var/tmp/mulesoft/flex-gateway/fluent-bit.conf ファイルを参照して設定値が正しいことを確認してください。 ## [](#incorrect-permissions)VM での動作中にログが表示されない アクセスログポリシーで対象ログディレクトリを指定した後で、ログファイルが表示されません。ログディレクトリの例は ​`/var/log`​ などです。 ### [](#原因)原因 ログ出力ディレクトリに ​`write`​ 権限が付与されていません。 ### [](#解決策)解決策 この問題を解決するには、出力ディレクトリに ​`write`​ 権限を付与する必要があります。 # 共有ストレージモデル 共有ストレージを設定する場合、できる限り Flex Gateway の近くに Redis 共有ストレージサービスを配置することをお勧めします。 Redis 共有ストレージサービスが同じクラスターまたは Virtual Private Cloud (VPC) 内でローカルに使用できる場合、相互認証トランスポートレイヤーセキュリティ (mTLS) 接続がなくても、共有ストレージと通信できます。 Flex Gateway と共有ストレージサービス間の接続を設定するには、以下を参照してください。 - [接続モードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config) - [ローカルモードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-shared-storage-config) 次の図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 Redis 共有ストレージを同じ Kubernetes クラスター内に Flex Gateway として配置することも、同じ VPC 内で Flex Gateway としてインスタンス化することもできます。 ## [](#同じクラスター内の共有ストレージ)同じクラスター内の共有ストレージ ![Redis 共有ストレージは、Flex Gateway レプリカとして同じクラスター内にあります](/mulesoft/current/ja-jp/gateway/1.10/_images/redis-same-cluster.png) ## [](#同じ-vpc-内の共有ストレージ)同じ VPC 内の共有ストレージ ![Redis 共有ストレージは、Flex Gateway レプリカとして同じ VPC 内にありますが、同じクラスター内にはありません](/mulesoft/current/ja-jp/gateway/1.10/_images/redis-same-vpc.png) ## [](#関連情報)関連情報 - [接続モードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config) - [ローカルモードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-shared-storage-config) - [接続モードでの Flex Gateway 設定キャッシュの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-replica-caching) # 共有ストレージモデル 共有ストレージを設定する場合、できる限り Flex Gateway の近くに Redis 共有ストレージサービスを配置することをお勧めします。 Redis 共有ストレージサービスが同じクラスターまたは Virtual Private Cloud (VPC) 内でローカルに使用できる場合、相互認証トランスポートレイヤーセキュリティ (mTLS) 接続がなくても、共有ストレージと通信できます。 Flex Gateway と共有ストレージサービス間の接続を設定するには、以下を参照してください。 - [接続モードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-shared-storage-config) - [ローカルモードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-shared-storage-config) 次の図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 Redis 共有ストレージを同じ Kubernetes クラスター内に Flex Gateway として配置することも、同じ VPC 内で Flex Gateway としてインスタンス化することもできます。 ## [](#同じクラスター内の共有ストレージ)同じクラスター内の共有ストレージ ![Redis 共有ストレージは、Flex Gateway レプリカとして同じクラスター内にあります。](/mulesoft/current/ja-jp/gateway/1.8/_images/redis-same-cluster.png) ## [](#同じ-vpc-内の共有ストレージ)同じ VPC 内の共有ストレージ ![Redis 共有ストレージは、Flex Gateway レプリカとして同じ VPC 内にありますが、同じクラスター内にはありません。](/mulesoft/current/ja-jp/gateway/1.8/_images/redis-same-vpc.png) ## [](#関連情報)関連情報 - [Flex Gateway デプロイメントモデル](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-basic-deployments) - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.8/flex-architecture-uc-overview) # 共有ストレージモデル 共有ストレージを設定する場合、できる限り Flex Gateway の近くに Redis 共有ストレージサービスを配置することをお勧めします。 Redis 共有ストレージサービスが同じクラスターまたは Virtual Private Cloud (VPC) 内でローカルに使用できる場合、相互認証トランスポートレイヤーセキュリティ (mTLS) 接続がなくても、共有ストレージと通信できます。 Flex Gateway と共有ストレージサービス間の接続を設定するには、以下を参照してください。 - [接続モードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config) - [ローカルモードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-shared-storage-config) 次の図では、Kubernetes の用語が使用されていますが、このアーキテクチャは、適切なネットワーク制御が適用された他の技術スタックに拡張できます。 Redis 共有ストレージを同じ Kubernetes クラスター内に Flex Gateway として配置することも、同じ VPC 内で Flex Gateway としてインスタンス化することもできます。 ## [](#同じクラスター内の共有ストレージ)同じクラスター内の共有ストレージ ![Redis 共有ストレージは、Flex Gateway レプリカとして同じクラスター内にあります](/mulesoft/current/ja-jp/gateway/1.9/_images/redis-same-cluster.png) ## [](#同じ-vpc-内の共有ストレージ)同じ VPC 内の共有ストレージ ![Redis 共有ストレージは、Flex Gateway レプリカとして同じ VPC 内にありますが、同じクラスター内にはありません](/mulesoft/current/ja-jp/gateway/1.9/_images/redis-same-vpc.png) ## [](#関連情報)関連情報 - [接続モードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config) - [ローカルモードで共有ストレージを設定する](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-shared-storage-config) - [接続モードでの Flex Gateway 設定キャッシュの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-replica-caching) # 内部ポリシーディレクトリ ## [](#flex-gateway-に含まれているポリシー)Flex Gateway に含まれているポリシー
ポリシー カテゴリ 概要

基本認証: LDAP

セキュリティ

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

基本認証: シンプル

セキュリティ

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

クライアント ID 適用

コンプライアンス

承認されたクライアントアプリケーションへのアクセスのみを許可する

クロスオリジンリソース共有 (CORS)

コンプライアンス

外部ドメインに存在するリソースへのアクセスを可能にする

外部認証

セキュリティ

外部 gRPC または HTTP 認証サービスを使用して要求を認証します

外部処理

変換

追加処理を行うために、受信 HTTP 要求または送信 HTTP 応答を外部 gRPC サービスに送信する

ヘッダーの挿入

変換

要求または応答にヘッダーを追加する

ヘッダーの削除

変換

要求または応答からヘッダーを削除する

状態チェック

サービス品質

特定の間隔で API アップストリームの健全性を監視する

HTTP キャッシュ

サービス品質

API 実装から HTTP 応答をキャッシュする

IP 許可リスト

セキュリティ

IP アドレスのリストまたは範囲からのアクセス要求を許可する

IP ブロックリスト

セキュリティ

単一の IP アドレスまたは IP アドレスの範囲からの API エンドポイントへのアクセスをブロックする

JSON 脅威保護

セキュリティ

API 要求内の悪意のある JSON から保護する

JWT 検証

セキュリティ

JWT トークンを検証する

メッセージログ

トラブルシューティング

受信した要求からの情報、バックエンドからの応答、または同じ API エンドポイントに適用されている他のポリシーからの情報を使用してカスタムメッセージを記録する

OAuth 2.0 トークンイントロスペクション

セキュリティ

承認されたクライアントアプリケーションへのアクセスのみを許可する

OpenID Connect OAuth 2.0 アクセストークン適用

セキュリティ

承認されたクライアントアプリケーションへのアクセスのみを許可する

レート制限

サービス品質

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

レート制限: SLA ベース

サービス品質

SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。

スキーマ検証

セキュリティ

指定された OAS3 スキーマに対して受信トラフィックを検証する

スパイク制御

サービス品質

API トラフィックを規制する

複数のアップストリームサービスのトラフィック管理

サービス品質

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

複数のアップストリームサービスポリシーのトラフィック管理 (加重)

サービス品質

加重率を使用して、1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

Transport Layer Security (TLS) - インバウンド

セキュリティ

クライアントと API プロキシ間の認証を有効にする

Transport Layer Security (TLS) - アウトバウンド

セキュリティ

API プロキシとアップストリームサービス間の双方向認証を有効にする
## [](#関連情報)関連情報 - [Mule Gateway ポリシーの概要](https://docs.mulesoft.com/jp/mule-gateway/policies-policy-overview) - [ゲートウェイ別のポリシーの可用性](https://docs.mulesoft.com/jp/policies/policies-availability-by-gateway) # 基本認証: LDAP ポリシー

ポリシー名

基本認証: LDAP

概要

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.1.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 Lightweight Directory Access Protocol (LDAP) 認証ポリシーは、LDAP 認証メカニズムを使用して API へのアクセスを制限する方法を指定します。 エラーに遭遇すると、基本認証 - LDAP ポリシーは ​`WWW-Authenticate: Basic realm="mule-realm"`​ の形式で「WWW-Authenticate」 HTTP ヘッダー項目を返します。 LDAP は上下反転した木であり、それぞれの葉にユーザー名-パスワードのペアおよび関連付けられたメタデータがあります。各レベルは木の枝のように分かれています。LDAP の詳細については、 [「LDAP^ について」](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ldap-authentication-flex config: ldapServerURL: // OPTIONAL, default: "ldap://127.0.0.1:389" ldapServerUserDn: // REQUIRED ldapServerUserPassword: // REQUIRED ldapSearchBase: // REQUIRED ldapSearchFilter: // OPTIONAL, default: "(uid={0})" ldapSearchInSubtree: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

ldapServerURL

省略可能

ldap://127.0.0.1:389

LDAP サーバーへの場所のアドレスとポート

ldapServerUserDn

必須

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前

ldapServerUserPassword

必須

ユーザーまたはユーザーグループのパスワード

ldapSearchBase

必須

LDAP 検索を開始する場所

ldapSearchFilter

必須

Active Directory または OpenLDAP モデルの検索条件

ldapSearchInSubtree

省略可能

false

ベース DN の下のサブツリーを調べて、ベース DN レベルを含めるかどうか。これにより、パフォーマンスが影響を受けます。それ以外の場合、1 レベルのスコープが使用され、ベース DN のすぐ下のレベルのみが調べられます。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ldap-authentication-flex config: dapServerURL: "ldap://localhost:369" ldapServerUserDn: "cn=admin,dc=example,dc=org" ldapServerUserPassword: "admin" ldapSearchBase: "dc=example,dc=org" ldapSearchFilter: "(uid={0})" ldapSearchInSubtree: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

LDAP Server URL (LDAP サーバー URL)

ポート番号を含む、LDAP または LDAPS サーバーの URL。

LDAP User DN (LDAP ユーザー DN)

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前。

LDAP User Password (LDAP ユーザーパスワード)

ユーザーまたはユーザーグループのパスワード。パスワードはセキュアな値でなければなりません。これは、指定すると表示または再取得できなくなる値です。

LDAP Search Base (LDAP 検索ベース)

ディレクトリツリー内の検索の開始点。

LDAP Search Filter (LDAP 検索条件)

Active Directory または OpenLDAP モデルの検索条件。例を参照してください。
LDAP または Active Directory に正常に接続するには、すべてのパラメーターが必要です。
## [](#active-directory-の設定例)Active Directory の設定例 以下の値を設定することで、Active Directory の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

CN=Administrator,CN=Users,DC=my-company,DC=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

CN=Users,DC=my-company,DC=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(sAMAccountName={0})

${ldap.search.filter}
例の検索条件文字列は Active Directory アプリケーションに固有です。 ## [](#openldap-の設定例)OpenLDAP の設定例 以下の値を設定することで、OpenLDAP の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

cn=Manager,dc=my-company,dc=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

ou=people,dc=my-company,dc=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(uid={0})

${ldap.search.filter}
例の検索条件文字列は OpenLDAP アプリケーションに固有です。 ## [](#ポリシーのしくみ)ポリシーのしくみ 基本認証 - LDAP ポリシーは、保護されているリソースに対する要求を捕捉して、​`Authorization`​ HTTP ヘッダーを確認します。 そして、Base64 でエンコードされているユーザー名とパスワードを抽出して、設定されている LDAP インスタンスに対して、提供されている LDAP コンテキストにおいてユーザーのログイン情報が正しいかどうかを判断するように要求します。 ログイン情報に対する基本認証: LDAP ポリシーは、以下の方法を使用して設定できます。 - 指定されているレベルでユーザー名とパスワードのペアを検索する。 - 指定されているレベルとその下位レベルでユーザー名とパスワードのペアを検索する。ただし、この検索オプションは包括的であるため、パフォーマンスが低下することがあります。 ### [](#検索スコープ)検索スコープ 検索スコープオプションは、使用しているポリシーバージョンによって異なります。検索スコープオプションは、LDAP 1.0.0 では 1 レベル、LDAP 1.1.0 では 2 レベル (サブツリー) となります。 `one level`​ または ​`subtree`​ の検索スコープは、​`LDAP Search in subtree`​ オプションを使用して選択します。 `LDAP search base`​ は、ディレクトリ内の検索の開始点です。 ### [](#1-レベル検索スコープ)1 レベル検索スコープ このオプションを使用すると、検索条件は ​`LDAP search base`​ 直下のオブジェクトのみに影響しますが、​`LDAP search base`​ 自身は含まれません。 次の例では、第 1 レベルに 4 つのエントリ (2 つのユーザーと 2 つのグループ) があります。検索にはこれらのエントリのみが含まれます。 ![階層的な組織構造の図](/mulesoft/current/ja-jp/gateway/1.10/_images/search-scope.png) 検索条件を ​`(uid={0})`​ に設定した場合、​`Jane`​ と ​`Paul`​ のみが見つかります。グループエントリは考慮されません。 #### [](#サブツリー検索スコープ)サブツリー検索スコープ このオプションを使用すると、基本認証 - LDAP ポリシーは ​`LDAP search base`​ の下のサブツリーも調べ、​`LDAP search base`​ レベルも含めます。ただし、この動作によりパフォーマンスが影響を受けます。 上の例では、分析される領域には組織全体が含まれます。組織のすべてのレベルでグループエントリとユーザーエントリが考慮されます。 ![組織構造の例を示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/search-scope2.png) ## [](#基本認証ポリシーが適用された-api-への要求の作成)基本認証ポリシーが適用された API への要求の作成 基本認証 - LDAP ポリシーを API に適用した後は、その API への要求には次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` LDAP は ​`username`​ と検索条件から登録済みユーザーを見つけた後に、ログイン情報を検証します。有効な結果が返されます。 ![こちらは、LDAP サーバーを介したクライアント認証のメッセージフローを示すシーケンス図です](/mulesoft/current/ja-jp/gateway/1.10/_images/ldap-verification.png) 無効な要求の例を下図に示します。 ![認証のメッセージフローを示すシーケンス図](/mulesoft/current/ja-jp/gateway/1.10/_images/ldap-verification-invalid.png) 基本認証 - LDAP ポリシーは HTTP 401 状況コードをスローします。これは、認証ヘッダーが不正である、提供されていない、または無効であることを示します。 # 基本認証: LDAP ポリシー

ポリシー名

基本認証: LDAP

概要

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.1.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 Lightweight Directory Access Protocol (LDAP) 認証ポリシーは、LDAP 認証メカニズムを使用して API へのアクセスを制限する方法を指定します。 エラーに遭遇すると、基本認証 - LDAP ポリシーは ​`WWW-Authenticate: Basic realm="mule-realm"`​ の形式で「WWW-Authenticate」 HTTP ヘッダー項目を返します。 LDAP は上下反転した木であり、それぞれの葉にユーザー名-パスワードのペアおよび関連付けられたメタデータがあります。各レベルは木の枝のように分かれています。LDAP の詳細については、 [「LDAP^ について」](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用して LDAP ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ldap-authentication-flex config: ldapServerURL: // OPTIONAL, default: "ldap://127.0.0.1:389" ldapServerUserDn: // REQUIRED ldapServerUserPassword: // REQUIRED ldapSearchBase: // REQUIRED ldapSearchFilter: // OPTIONAL, default: "(uid={0})" ldapSearchInSubtree: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

ldapServerURL

省略可能

ldap://127.0.0.1:389

LDAP サーバーへの場所のアドレスとポート

ldapServerUserDn

必須

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前

ldapServerUserPassword

必須

ユーザーまたはユーザーグループのパスワード

ldapSearchBase

必須

LDAP 検索を開始する場所

ldapSearchFilter

必須

Active Directory または OpenLDAP モデルの検索条件

ldapSearchInSubtree

省略可能

false

ベース DN の下のサブツリーを調べて、ベース DN レベルを含めるかどうか。これにより、パフォーマンスが影響を受けます。それ以外の場合、1 レベルのスコープが使用され、ベース DN のすぐ下のレベルのみが調べられます。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ldap-authentication-flex config: dapServerURL: "ldap://localhost:369" ldapServerUserDn: "cn=admin,dc=example,dc=org" ldapServerUserPassword: "admin" ldapSearchBase: "dc=example,dc=org" ldapSearchFilter: "(uid={0})" ldapSearchInSubtree: true ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI から基本認証 - LDAP ポリシーを API に適用する場合は、LDAP または Active Directory に接続するための以下のパラメーターを設定できます。
パラメーター 説明

LDAP Server URL (LDAP サーバー URL)

ポート番号を含む、LDAP または LDAPS サーバーの URL。

LDAP User DN (LDAP ユーザー DN)

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前。

LDAP User Password (LDAP ユーザーパスワード)

ユーザーまたはユーザーグループのパスワード。パスワードはセキュアな値でなければなりません。これは、指定すると表示または再取得できなくなる値です。

LDAP Search Base (LDAP 検索ベース)

ディレクトリツリー内の検索の開始点。

LDAP Search Filter (LDAP 検索条件)

Active Directory または OpenLDAP モデルの検索条件。例を参照してください。
LDAP または Active Directory に正常に接続するには、すべてのパラメーターが必要です。 ## [](#active-directory-の設定例)Active Directory の設定例 以下の値を設定することで、Active Directory の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

CN=Administrator,CN=Users,DC=my-company,DC=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

CN=Users,DC=my-company,DC=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(sAMAccountName={0})

${ldap.search.filter}
例の検索条件文字列は Active Directory アプリケーションに固有です。 ## [](#openldap-の設定例)OpenLDAP の設定例 以下の値を設定することで、OpenLDAP の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

cn=Manager,dc=my-company,dc=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

ou=people,dc=my-company,dc=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(uid={0})

${ldap.search.filter}
例の検索条件文字列は OpenLDAP アプリケーションに固有です。 ## [](#ポリシーのしくみ)ポリシーのしくみ 基本認証 - LDAP ポリシーは、保護されているリソースに対する要求を捕捉して、​`Authorization`​ HTTP ヘッダーを確認します。 そして、Base64 でエンコードされているユーザー名とパスワードを抽出して、設定されている LDAP インスタンスに対して、提供されている LDAP コンテキストにおいてユーザーのログイン情報が正しいかどうかを判断するように要求します。 ログイン情報に対する基本認証: LDAP ポリシーは、以下の方法を使用して設定できます。 - 指定されているレベルでユーザー名とパスワードのペアを検索する。 - 指定されているレベルとその下位レベルでユーザー名とパスワードのペアを検索する。ただし、この検索オプションは包括的であるため、パフォーマンスが低下することがあります。 ### [](#検索スコープ)検索スコープ 検索スコープオプションは、使用しているポリシーバージョンによって異なります。検索スコープオプションは、LDAP 1.0.0 では 1 レベル、LDAP 1.1.0 では 2 レベル (サブツリー) となります。 `one level`​ または ​`subtree`​ の検索スコープは、​`LDAP Search in subtree`​ オプションを使用して選択します。 `LDAP search base`​ は、ディレクトリ内の検索の開始点です。 ### [](#1-レベル検索スコープ)1 レベル検索スコープ このオプションを使用すると、検索条件は ​`LDAP search base`​ 直下のオブジェクトのみに影響しますが、​`LDAP search base`​ 自身は含まれません。 次の例では、第 1 レベルに 4 つのエントリ (2 つのユーザーと 2 つのグループ) があります。検索にはこれらのエントリのみが含まれます。 ![search scope](/mulesoft/current/ja-jp/gateway/1.8/_images/search-scope.png) 検索条件を ​`(uid={0})`​ に設定した場合、​`Jane`​ と ​`Paul`​ のみが見つかります。グループエントリは考慮されません。 #### [](#サブツリー検索スコープ)サブツリー検索スコープ このオプションを使用すると、基本認証 - LDAP ポリシーは ​`LDAP search base`​ の下のサブツリーも調べ、​`LDAP search base`​ レベルも含めます。ただし、この動作によりパフォーマンスが影響を受けます。 上の例では、分析される領域には組織全体が含まれます。組織のすべてのレベルでグループエントリとユーザーエントリが考慮されます。 ![search scope2](/mulesoft/current/ja-jp/gateway/1.8/_images/search-scope2.png) ## [](#基本認証ポリシーが適用された-api-への要求の作成)基本認証ポリシーが適用された API への要求の作成 基本認証 - LDAP ポリシーを API に適用した後は、その API への要求には次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` LDAP は ​`username`​ と検索条件から登録済みユーザーを見つけた後に、ログイン情報を検証します。有効な結果が返されます。 ![ldap verification](/mulesoft/current/ja-jp/gateway/1.8/_images/ldap-verification.png) 無効な要求の例を下図に示します。 ![ldap verification invalid](/mulesoft/current/ja-jp/gateway/1.8/_images/ldap-verification-invalid.png) 基本認証 - LDAP ポリシーは HTTP 401 状況コードをスローします。これは、認証ヘッダーが不正である、提供されていない、または無効であることを示します。 # 基本認証: LDAP ポリシー

ポリシー名

基本認証: LDAP

概要

LDAP で定義されたユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.1.0

返される状況コード

401 - 未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 Lightweight Directory Access Protocol (LDAP) 認証ポリシーは、LDAP 認証メカニズムを使用して API へのアクセスを制限する方法を指定します。 エラーに遭遇すると、基本認証 - LDAP ポリシーは ​`WWW-Authenticate: Basic realm="mule-realm"`​ の形式で「WWW-Authenticate」 HTTP ヘッダー項目を返します。 LDAP は上下反転した木であり、それぞれの葉にユーザー名-パスワードのペアおよび関連付けられたメタデータがあります。各レベルは木の枝のように分かれています。LDAP の詳細については、 [「LDAP^ について」](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)​を参照してください。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: ldap-authentication-flex config: ldapServerURL: // OPTIONAL, default: "ldap://127.0.0.1:389" ldapServerUserDn: // REQUIRED ldapServerUserPassword: // REQUIRED ldapSearchBase: // REQUIRED ldapSearchFilter: // OPTIONAL, default: "(uid={0})" ldapSearchInSubtree: // OPTIONAL, default: false
パラメーター 必須または省略可能 デフォルト値 説明

ldapServerURL

省略可能

ldap://127.0.0.1:389

LDAP サーバーへの場所のアドレスとポート

ldapServerUserDn

必須

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前

ldapServerUserPassword

必須

ユーザーまたはユーザーグループのパスワード

ldapSearchBase

必須

LDAP 検索を開始する場所

ldapSearchFilter

必須

Active Directory または OpenLDAP モデルの検索条件

ldapSearchInSubtree

省略可能

false

ベース DN の下のサブツリーを調べて、ベース DN レベルを含めるかどうか。これにより、パフォーマンスが影響を受けます。それ以外の場合、1 レベルのスコープが使用され、ベース DN のすぐ下のレベルのみが調べられます。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: ldap-authentication-flex config: dapServerURL: "ldap://localhost:369" ldapServerUserDn: "cn=admin,dc=example,dc=org" ldapServerUserPassword: "admin" ldapSearchBase: "dc=example,dc=org" ldapSearchFilter: "(uid={0})" ldapSearchInSubtree: true ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

LDAP Server URL (LDAP サーバー URL)

ポート番号を含む、LDAP または LDAPS サーバーの URL。

LDAP User DN (LDAP ユーザー DN)

LDAP のユーザーをトラバースおよびリストするためのアクセス権を持つユーザーまたはユーザーグループの名前。

LDAP User Password (LDAP ユーザーパスワード)

ユーザーまたはユーザーグループのパスワード。パスワードはセキュアな値でなければなりません。これは、指定すると表示または再取得できなくなる値です。

LDAP Search Base (LDAP 検索ベース)

ディレクトリツリー内の検索の開始点。

LDAP Search Filter (LDAP 検索条件)

Active Directory または OpenLDAP モデルの検索条件。例を参照してください。
LDAP または Active Directory に正常に接続するには、すべてのパラメーターが必要です。
## [](#active-directory-の設定例)Active Directory の設定例 以下の値を設定することで、Active Directory の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

CN=Administrator,CN=Users,DC=my-company,DC=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

CN=Users,DC=my-company,DC=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(sAMAccountName={0})

${ldap.search.filter}
例の検索条件文字列は Active Directory アプリケーションに固有です。 ## [](#openldap-の設定例)OpenLDAP の設定例 以下の値を設定することで、OpenLDAP の LDAP 認証を設定できます。
項目 リテラル文字列値の例 セキュアプロパティプレースホルダーの例

LDAP Server URL (LDAP サーバー URL)

ldap://174.19.33.17:389/

${ldap.server.url}

LDAP Secure Server URL (SSL) (LDAP セキュアサーバー URL (SSL))

ldaps://my-company-ldap.cloudhub.io:1010/

${ldap.server.url}

LDAP Server User DN (LDAP サーバーユーザー DN)

cn=Manager,dc=my-company,dc=com

${ldap.user.dn}

LDAP User Password (LDAP ユーザーパスワード)

somePassword

${ldap.password}

LDAP Search Base (LDAP 検索ベース)

ou=people,dc=my-company,dc=com

${ldap.search.base}

LDAP Search Filter (LDAP 検索条件)

(uid={0})

${ldap.search.filter}
例の検索条件文字列は OpenLDAP アプリケーションに固有です。 ## [](#ポリシーのしくみ)ポリシーのしくみ 基本認証 - LDAP ポリシーは、保護されているリソースに対する要求を捕捉して、​`Authorization`​ HTTP ヘッダーを確認します。 そして、Base64 でエンコードされているユーザー名とパスワードを抽出して、設定されている LDAP インスタンスに対して、提供されている LDAP コンテキストにおいてユーザーのログイン情報が正しいかどうかを判断するように要求します。 ログイン情報に対する基本認証: LDAP ポリシーは、以下の方法を使用して設定できます。 - 指定されているレベルでユーザー名とパスワードのペアを検索する。 - 指定されているレベルとその下位レベルでユーザー名とパスワードのペアを検索する。ただし、この検索オプションは包括的であるため、パフォーマンスが低下することがあります。 ### [](#検索スコープ)検索スコープ 検索スコープオプションは、使用しているポリシーバージョンによって異なります。検索スコープオプションは、LDAP 1.0.0 では 1 レベル、LDAP 1.1.0 では 2 レベル (サブツリー) となります。 `one level`​ または ​`subtree`​ の検索スコープは、​`LDAP Search in subtree`​ オプションを使用して選択します。 `LDAP search base`​ は、ディレクトリ内の検索の開始点です。 ### [](#1-レベル検索スコープ)1 レベル検索スコープ このオプションを使用すると、検索条件は ​`LDAP search base`​ 直下のオブジェクトのみに影響しますが、​`LDAP search base`​ 自身は含まれません。 次の例では、第 1 レベルに 4 つのエントリ (2 つのユーザーと 2 つのグループ) があります。検索にはこれらのエントリのみが含まれます。 ![階層的な組織構造の図](/mulesoft/current/ja-jp/gateway/1.9/_images/search-scope.png) 検索条件を ​`(uid={0})`​ に設定した場合、​`Jane`​ と ​`Paul`​ のみが見つかります。グループエントリは考慮されません。 #### [](#サブツリー検索スコープ)サブツリー検索スコープ このオプションを使用すると、基本認証 - LDAP ポリシーは ​`LDAP search base`​ の下のサブツリーも調べ、​`LDAP search base`​ レベルも含めます。ただし、この動作によりパフォーマンスが影響を受けます。 上の例では、分析される領域には組織全体が含まれます。組織のすべてのレベルでグループエントリとユーザーエントリが考慮されます。 ![組織構造の例を示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/search-scope2.png) ## [](#基本認証ポリシーが適用された-api-への要求の作成)基本認証ポリシーが適用された API への要求の作成 基本認証 - LDAP ポリシーを API に適用した後は、その API への要求には次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` LDAP は ​`username`​ と検索条件から登録済みユーザーを見つけた後に、ログイン情報を検証します。有効な結果が返されます。 ![こちらは、LDAP サーバーを介したクライアント認証のメッセージフローを示すシーケンス図です](/mulesoft/current/ja-jp/gateway/1.9/_images/ldap-verification.png) 無効な要求の例を下図に示します。 ![認証のメッセージフローを示すシーケンス図](/mulesoft/current/ja-jp/gateway/1.9/_images/ldap-verification-invalid.png) 基本認証 - LDAP ポリシーは HTTP 401 状況コードをスローします。これは、認証ヘッダーが不正である、提供されていない、または無効であることを示します。 # 基本認証: 簡易ポリシー

ポリシー名

基本認証: シンプル

概要

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - SOAP 1.2 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報

401 - HTTP または RAML API での未承認または無効なクライアントアプリケーションのログイン情報

500 - SOAP 1.1 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 基本認証: 簡易ポリシーは、要求を出すアプリケーションに対してユーザー名とパスワードを強制的に提供させることで API を保護します。 このポリシーは、 [基本 HTTP 認証標準](https://tools.ietf.org/html/rfc7617)​に準拠します。 エラーに遭遇すると、このポリシーは「WWW-Authenticate」 HTTP ヘッダー項目を返します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-basic-authentication-flex config: username: // REQUIRED password: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

username

必須

なし

base-64 でエンコードされた文字列

password

必須

なし

base-64 でエンコードされた文字列
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード 基本認証: 簡易ポリシーを API に適用した後は、その API への要求に次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` # 基本認証: 簡易ポリシー

ポリシー名

基本認証: シンプル

概要

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - SOAP 1.2 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報

401 - HTTP または RAML API での未承認または無効なクライアントアプリケーションのログイン情報

500 - SOAP 1.1 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 基本認証: 簡易ポリシーは、要求を出すアプリケーションに対してユーザー名とパスワードを強制的に提供させることで API を保護します。 このポリシーは、 [基本 HTTP 認証標準](https://tools.ietf.org/html/rfc7617)​に準拠します。 エラーに遭遇すると、このポリシーは「WWW-Authenticate」 HTTP ヘッダー項目を返します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード Flex Gateway のローカルモードでは、宣言型の設定ファイルを使用して基本認証: 簡易ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-basic-authentication-flex config: username: // REQUIRED password: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

username

必須

なし

base-64 でエンコードされた文字列

password

必須

なし

base-64 でエンコードされた文字列
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード 基本認証: 簡易ポリシーを API に適用した後は、その API への要求に次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` # 基本認証: 簡易ポリシー

ポリシー名

基本認証: シンプル

概要

1 つのユーザー-パスワードを使用して基本認証メカニズムに基づいてアクセスを許可する

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

400 - SOAP 1.2 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報

401 - HTTP または RAML API での未承認または無効なクライアントアプリケーションのログイン情報

500 - SOAP 1.1 を使用した WSDL API での未承認または無効なクライアントアプリケーションのログイン情報
## [](#概要)概要 基本認証: 簡易ポリシーは、要求を出すアプリケーションに対してユーザー名とパスワードを強制的に提供させることで API を保護します。 このポリシーは、 [基本 HTTP 認証標準](https://tools.ietf.org/html/rfc7617)​に準拠します。 エラーに遭遇すると、このポリシーは「WWW-Authenticate」 HTTP ヘッダー項目を返します。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: http-basic-authentication-flex config: username: // REQUIRED password: // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

username

必須

なし

base-64 でエンコードされた文字列

password

必須

なし

base-64 でエンコードされた文字列
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード 基本認証: 簡易ポリシーを API に適用した後は、その API への要求に次のヘッダーを含める必要があります。 Authorization: Basic `username:password`​ の値は Base64 でエンコードされた文字列である必要があります。たとえば、Mac OS X や Linux システムでは、ユーザー名とパスワードの要件は次のように実装されます。 `echo -n ':' | base64` # 基本認証とレート制限を使用した API の保護 ローカルモードで Flex Gateway の背後で実行されている API をパブリッシュすることで、YAML 設定データを変更する方法について説明します。 - Linux および Docker: `.yaml`​ ファイル 下記の手順は、​[基本認証](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-basic-auth-simple)​と​[レート制限](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-rate-limiting)​によって保護されている複数のアップストリームサービスを使用した API のシンプルな YAML 設定を適用する方法を示しています。

20%

25%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ​

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ​
## [](#linux-で-flex-gateway-の背後で実行されている-api-のパブリッシュ)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-users-api spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api users: address: https://:/ routes: - rules: - path: /api/users(/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin - policyRef: name: rate-limiting-flex config: exposeHeaders: true rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.queryParams\['identifier'\]\]" 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-http-basic-authentication-flex-1 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-rate-limiting-flex-2 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 基本認証とレート制限によって保護された API が Flex Gateway の背後で実行されています。 ## [](#docker-コンテナで-flex-gateway-の背後で実行されている-api-のパブリッシュ)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-users-api spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /api/products(/.\*) - path: /api/products-featured(/.\*) config: destinationPath: /api users: address: https://:/ routes: - rules: - path: /api/users(/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin - policyRef: name: rate-limiting-flex config: exposeHeaders: true rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.queryParams\['identifier'\]\]" 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-http-basic-authentication-flex-1 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-rate-limiting-flex-2 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 基本認証とレート制限によって保護された API が Flex Gateway の背後で実行されています。 ## [](#関連情報)関連情報 - [インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) # 基本認証とレート制限を使用した API の保護 ローカルモードで Flex Gateway の背後で実行されている API をパブリッシュすることで、YAML 設定データを変更する方法について説明します。 - Linux および Docker: `.yaml`​ ファイル 下記の手順は、​[基本認証](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-basic-auth-simple)​と​[レート制限](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-rate-limiting)​によって保護されている複数のアップストリームサービスを使用した API のシンプルな YAML 設定を適用する方法を示しています。

20%

25%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ​

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ​
## [](#linux-で-flex-gateway-の背後で実行されている-api-のパブリッシュ)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-users-api spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api users: address: https://:/ routes: - rules: - path: /api/users(/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin - policyRef: name: rate-limiting-flex config: exposeHeaders: true rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.queryParams\['identifier'\]\]" 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-http-basic-authentication-flex-1 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-rate-limiting-flex-2 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 基本認証とレート制限によって保護された API が Flex Gateway の背後で実行されています。 ## [](#docker-コンテナで-flex-gateway-の背後で実行されている-api-のパブリッシュ)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-users-api spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /api/products(/.\*) - path: /api/products-featured(/.\*) config: destinationPath: /api users: address: https://:/ routes: - rules: - path: /api/users(/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin - policyRef: name: rate-limiting-flex config: exposeHeaders: true rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.queryParams\['identifier'\]\]" 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-http-basic-authentication-flex-1 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-rate-limiting-flex-2 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 基本認証とレート制限によって保護された API が Flex Gateway の背後で実行されています。 ## [](#関連情報)関連情報 - [内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory) # 基本認証とレート制限を使用した API の保護 ローカルモードで Flex Gateway の背後で実行されている API をパブリッシュすることで、YAML 設定データを変更する方法について説明します。 - Linux および Docker: `.yaml`​ ファイル 下記の手順は、​[基本認証](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-basic-auth-simple)​と​[レート制限](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-rate-limiting)​によって保護されている複数のアップストリームサービスを使用した API のシンプルな YAML 設定を適用する方法を示しています。

20%

25%

Linux で Flex Gateway の背後で実行されている API のパブリッシュ​

Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ​
## [](#linux-で-flex-gateway-の背後で実行されている-api-のパブリッシュ)Linux で Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされていてローカルモードで実行されている。ゲートウェイのインストールと実行についての詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ)API のパブリッシュ 1. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを Flex Gateway の設定ディレクトリ ​`/etc/mulesoft/flex-gateway/conf.d/custom`​ に保存します。このディレクトリには複数の設定ファイルを保存できます。 2. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-users-api spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /products(/.\*) - path: /products-featured(/.\*) config: destinationPath: /api users: address: https://:/ routes: - rules: - path: /api/users(/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin - policyRef: name: rate-limiting-flex config: exposeHeaders: true rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.queryParams\['identifier'\]\]" 3. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 4. 次のコマンドを実行してログを表示します。 journalctl -u flex-gateway-\* 応答は次のようになります。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-http-basic-authentication-flex-1 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-rate-limiting-flex-2 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 基本認証とレート制限によって保護された API が Flex Gateway の背後で実行されています。 ## [](#docker-コンテナで-flex-gateway-の背後で実行されている-api-のパブリッシュ)Docker コンテナで Flex Gateway の背後で実行されている API のパブリッシュ ### [](#始める前に-2)始める前に 始める前に、次の準備が整っていることを確認します。 - Flex Gateway がインストールされている。詳細は、[Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install)を参照してください。 - Flex Gateway がローカルモードで登録されて実行されている。詳細は​[「ローカルモードでの登録と実行」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run)​を参照してください。 - アップストリームサービスの URL が用意されている。次の例では架空の ​`products-api`​ と ​`users-api`​ というサービスを使用していますが、​`metadata.name`​ には実際の API 名、​`spec.services`​ にはサービスの詳細を指定することができます。 ### [](#api-のパブリッシュ-2)API のパブリッシュ 1. ターミナルを開いて、Flex Gateway 設定ファイルが保存されているディレクトリに移動します。このディレクトリは、Flex Gateway を起動したときに指定されています。 2. `.yaml`​ ファイル拡張子で設定ファイルを作成します。 1. ファイルにカスタム名を付けます。 2. ファイルを保存します。 3. 次の YAML スニペットをコピーしてファイルに貼り付け、必要な箇所を適切な値に変更します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: products-users-api spec: address: http://0.0.0.0:8080 services: products: address: https://:/ routes: - rules: - path: /api/products(/.\*) - path: /api/products-featured(/.\*) config: destinationPath: /api users: address: https://:/ routes: - rules: - path: /api/users(/.\*) policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin - policyRef: name: rate-limiting-flex config: exposeHeaders: true rateLimits: - maximumRequests: 3 timePeriodInMilliseconds: 6000 keySelector: "#\[attributes.queryParams\['identifier'\]\]" 4. ファイルを保存します。ゲートウェイによって設定が自動的に更新されます。 5. Docker コンテナログを表示します。内容は次のようになっています。 \[agent\]\[info\] Generating config \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding ApiInstance default/products-users-api http://0.0.0.0:8080 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-http-basic-authentication-flex-1 \[agent\]\[info\] Gateway default/4191c977e1ce: Adding Policy default/products-users-api-users-rate-limiting-flex-2 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/products(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-products Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Route: &{host: path:/api/users(/.\*) methods: headerConditions:\[\] profile:0xc0030529f0} => {Kind:Service Name:products-users-api-users Namespace:default} \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Policy default/envoy.filters.http.router \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/monitoring\_metrics http://0.0.0.0:9881 \[agent\]\[debug\] generating service monitoring\_metrics.default.svc hostname: 0.0.0.0 port: 9881 \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-products https://:/ \[agent\]\[info\] Gateway default/18b4e890fe7d: Adding Service default/products-users-api-users https://:/ \[agent\]\[debug\] generating service products-users-api-products.default.svc hostname: port: \[agent\]\[debug\] generating service products-users-api-users.default.svc hostname: port: \[agent\]\[info\] Writing envoy bootstrap configuration to /tmp/envoy.json \[envoy\]\[info\] cds: add 2 cluster(s), remove 2 cluster(s) \[envoy\]\[info\] cds: added/updated 1 cluster(s), skipped 1 unmodified cluster(s) 基本認証とレート制限によって保護された API が Flex Gateway の背後で実行されています。 ## [](#関連情報)関連情報 - [インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) # 外部処理ポリシー

ポリシー名

外部処理

Summary (概要)

追加処理を行うために、受信 HTTP 要求または送信 HTTP 応答要求を外部 gRPC サービスに送信します

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.6.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 外部処理ポリシーでは、ヘッダー、トレーラー、本文、またはこの 3 つのいずれかの組み合わせを変更するために、受信 HTTP 要求または送信 HTTP 応答を外部 gRPC サービスに転送します。要求、応答、またはその両方を処理するようにこのポリシーを設定することもできます。 さらに、外部処理サービスでは最初の gRPC 要求が Flex Gateway によって外部処理サーバーに送信された後に HTTP 要求または応答の別の部分を要求できます。これにより、必要最小限の量のデータを送信できます。たとえば、Flex Gateway では最初に HTTP リクエストヘッダーのみを送信できます。その後、何らかの処理を行った後で、外部プロセッサーが Flex Gateway からの HTTP 要求の本文またはトレーラーを要求できます。 HTTP ヘッダー、トレーラー、本文について設定するパラメーターでは、最初に送信される内容のみが設定されます。外部処理サービスは、設定ないように関係なく、HTTP 要求または応答のすべての部分にアクセスできます。処理サービスがすべての受信 HTTP 要求または応答に必要なすべての情報を送信するようにパラメーターを設定します。たとえば、処理サービスにすべてのリクエストヘッダーが必要だが一部の要求の本文しか必要ない場合は、ヘッダーで確認できる情報に応じて、ヘッダーを送信するパラメーターのみを設定します。 外部処理ポリシーは、Envoy に対してネイティブな外部処理検索条件の拡張機能です。外部処理検索条件に付いての詳細は、 [「External Processing Filter (外部処理検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto)​を参照してください。すべての外部処理検索条件パラメーターが外部処理ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。
他のポリシーで HTTP 要求または応答が変更される場合は、要求が処理サービスまたはアップストリームサービスに送信されるときにこれらの変更が存在している必要があるかどうかに応じて確実にポリシーを並び替えてください。ポリシーの並び替えについての詳細は、ポリシーの順序付けを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-ext-proc-flex config: uri: // REQUIRED messageTimeout: // OPTIONAL, default: 1000 requestHeaderMode: // OPTIONAL, default: "send" responseHeaderMode: // OPTIONAL, default: "send" requestBodyMode: // OPTIONAL, default: "none" responseBodyMode: // OPTIONAL, default: "none" requestTrailerMode: // OPTIONAL, default: "skip" responseTrailerMode: // OPTIONAL, default: "skip" failureModeAllow: // OPTIONAL, default: false maxMessageTimeout: // OPTIONAL, default: 0 allowModeOverride: // OPTIONAL, default: true ```
パラメーター 必須または省略可能 デフォルト値 説明

uri

必須

なし

外部処理サーバー URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

messageTimeout

省略可能

1000

処理サーバーのメッセージタイムアウト (ミリ秒)。

maxMessageTimeout

省略可能

0

処理サーバーが ​messageTimeout​ を上書きできる上限を指定します。

failureModeAllow

省略可能

false

true​ の場合、gRPC ストリームが早期に終了するか、開始できないと、要求の処理がエラーなしで続行されます。

allowModeOverride

省略可能

true

処理サーバーがポリシー設定を上書きできるようにします。​true​ の場合、サーバーが ​requestHeaderMode​、​responseHeaderMode​、​requestBodyMode​、​responseBodyMode​、​requestTrailerMode​、​responseTrailerMode​ パラメーターの設定を上書きできます。

observabilityMode

省略可能

false

true​ の場合、設定されたヘッダー、本文、トレーラーが外部処理サーバーに送信され、Flex Gateway は処理サーバーからの応答を待ちません。

requestHeaderMode

省略可能

send

HTTP リクエストヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

responseHeaderMode

省略可能

send

HTTP レスポンスヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

requestBodyMode

省略可能

none

HTTP 要求の本文が送信されるモード。 サポートされている値は、​none​、​streamed​、​buffered​、​bufferedPartial​ です。​none​ を選択すると、リクエストボディが送信されません。

responseBodyMode

省略可能

none

HTTP 応答の本文が送信されるモード。 サポートされている値は、​none​、​streamed​、​buffered​、​bufferedPartial​ です。​none​ を選択すると、リクエストボディが送信されません。

requestTrailerMode

省略可能

skip

HTTP 要求のトレーラーヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

responseTrailerMode

省略可能

skip

HTTP 応答のトレーラーヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。
値を空白のままにすると、パラメーターがデフォルト値を使用して設定されます。必須パラメーターにデフォルト値が設定されていない場合、パラメーターを設定する必要があります。
#### [](#リソースの設定例)リソースの設定例 次の設定では、リクエストヘッダー、トレーラー、本文が外部処理サーバーに送信されます。次の設定では、応答はどの部分も外部処理サーバーに送信されません。 ```yaml - policyRef: name: native-ext-proc-flex config: uri: h2://: messageTimeout: // OPTIONAL responseHeaderMode: skip requestBodyMode: streamed responseTrailerMode: skip ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

External processing server URI (外部処理サーバー URI)

外部処理サーバー URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

Message timeout (メッセージタイムアウト)

処理サーバーのメッセージタイムアウト (ミリ秒)。

Max message timeout (最大メッセージタイムアウト)

処理サーバーが ​[Message timeout (メッセージタイムアウト)]​ を上書きできる上限を指定します。

Failure mode allow (障害モードの許可)

true​ の場合、gRPC ストリームが早期に終了するか、開始できないと、要求の処理がエラーなしで続行されます。

Allow mode override (モードの上書きを許可)

処理サーバーがポリシー設定を上書きできるようにします。​true​ の場合、サーバーは ​[Request header processing mode (リクエストヘッダーの処理モード)]​、​[Response header processing mode (レスポンスヘッダーの処理モード)]​、​[Request body processing mode (リクエストボディの処理モード)]​、​[Response body processing mode (レスポンスボディの処理モード)]​、​[Request trailer processing mode (リクエストトレーラーの処理モード)]​、​[Response trailer processing mode (レスポンストレーラーの処理モード)]​ パラメーターの設定を上書きできます。

Observability mode (オブザーバビリティモード)

有効にすると、設定されたヘッダー、本文、トレーラーが外部処理サーバーに送信され、Flex Gateway は処理サーバーからの応答を待機しません。

Request header processing mode (リクエストヘッダーの処理モード)

リクエストヘッダーが処理サービスに送信されるかどうか。

Response header processing mode (レスポンスヘッダーの処理モード)

レスポンスヘッダーが処理サービスに送信されるかどうか。

Request body processing mode (要求の本文の処理モード)

要求の本文が送信されるモード。

Response body processing mode (応答の本文の処理モード)

応答の本文が送信されるモード。

Request trailer processing mode (要求のトレーラーの処理モード)

要求のトレーラーが処理サービスに送信されるかどうか。

Response trailer processing mode (応答のトレーラーの処理モード)

応答のトレーラーが処理サービスに送信されるかどうか。
値を空白のままにすると、パラメーターがデフォルト値を使用して設定されます。必須パラメーターにデフォルト値が設定されていない場合、パラメーターを設定する必要があります。
## [](#ポリシーのしくみ)ポリシーのしくみ 次の図は、外部処理ポリシーを適用した場合の要求と応答のフローの順序を示しています。 ![API インタラクションを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/ext-processing-policy.png) 1. クライアントが Flex Gateway に対する HTTP 要求を行います。 2. Flex Gateway が設定済みのクライアント HTTP 要求の最初の部分を外部処理サービスに転送します。​**\[Observability mode (オブザーバビリティモード)\]**​ が有効になっていると、次のステップはスキップされます。 3. Flex Gateway は変更されたクライアント HTTP 要求を待機します。​**\[Allow mode override (モードの上書きを許可)\]**​ が有効になっていると、外部処理サービスは要求の追加の部分を要求できます。 4. Flex Gateway はクライアント HTTP 要求をアップストリーム API サービスに送信し、HTTP 応答を待機します。 5. Flex Gateway が設定済みの HTTP 応答の最初の部分を外部処理サービスに転送します。​**\[Observability mode (オブザーバビリティモード)\]**​ が有効になっていると、次のステップはスキップされます。 6. Flex Gateway は変更された HTTP 応答を待機します。​**\[Allow mode override (モードの上書きを許可)\]**​ が有効になっていると、外部処理サービスは HTTP 応答の追加の部分を要求できます。 7. Flex Gateway が外部処理サービスからクライアントに変更済みの HTTP 応答を返します。 デフォルトでは、Flex Gateway が gRPC サービスへの接続を確立できない場合、または gRPC サービスでエラーが返される場合は、ポリシーが失敗します。接続やエラー状況に関係なく要求を転送するには、​**\[Failure mode allow (障害モードの許可)\]**​ パラメーターを有効にします。 # 外部処理ポリシー

ポリシー名

外部処理

Summary (概要)

追加処理を行うために、受信 HTTP 要求または送信 HTTP 応答要求を外部 gRPC サービスに送信します

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.6.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 外部処理ポリシーでは、ヘッダー、トレーラー、本文、またはこの 3 つのいずれかの組み合わせを変更するために、受信 HTTP 要求または送信 HTTP 応答を外部 gRPC サービスに転送します。要求、応答、またはその両方を処理するようにこのポリシーを設定することもできます。 さらに、外部処理サービスでは最初の gRPC 要求が Flex Gateway によって外部処理サーバーに送信された後に HTTP 要求または応答の別の部分を要求できます。これにより、必要最小限の量のデータを送信できます。たとえば、Flex Gateway では最初に HTTP リクエストヘッダーのみを送信できます。その後、何らかの処理を行った後で、外部プロセッサーが Flex Gateway からの HTTP リクエストボディまたはトレーラーを要求できます。 HTTP ヘッダー、トレーラー、本文について設定するパラメーターでは、最初に送信される内容のみが設定されます。外部処理サービスは、設定ないように関係なく、HTTP 要求または応答のすべての部分にアクセスできます。処理サービスがすべての受信 HTTP 要求または応答に必要なすべての情報を送信するようにパラメーターを設定します。たとえば、処理サービスにすべてのリクエストヘッダーが必要だが一部のリクエストボディしか必要ない場合は、ヘッダーで確認できる情報に応じて、ヘッダーを送信するパラメーターのみを設定します。 外部処理ポリシーは、Envoy に対してネイティブな外部処理検索条件の拡張機能です。外部処理検索条件に付いての詳細は、 [「External Processing Filter (外部処理検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto)​を参照してください。すべての外部処理検索条件パラメーターが外部処理ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。
他のポリシーで HTTP 要求または応答が変更される場合は、要求が処理サービスまたはアップストリームサービスに送信されるときにこれらの変更が存在している必要があるかどうかに応じて確実にポリシーを並び替えてください。ポリシーの並び替えについての詳細は、ポリシーの順序付けを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード ローカルモードでは、宣言型設定ファイルを使用して外部処理ポリシーを API インスタンスに適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-ext-proc-flex config: uri: // REQUIRED messageTimeout: // OPTIONAL, default: 1000 requestHeaderMode: // OPTIONAL, default: "send" responseHeaderMode: // OPTIONAL, default: "send" requestBodyMode: // OPTIONAL, default: "none" responseBodyMode: // OPTIONAL, default: "none" requestTrailerMode: // OPTIONAL, default: "skip" responseTrailerMode: // OPTIONAL, default: "skip" failureModeAllow: // OPTIONAL, default: false maxMessageTimeout: // OPTIONAL, default: 0 allowModeOverride: // OPTIONAL, default: true ```
パラメーター 必須または省略可能 デフォルト値 説明

uri

必須

なし

外部処理サーバー URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

messageTimeout

省略可能

1000

処理サーバーのメッセージタイムアウト (ミリ秒)。

requestHeaderMode

省略可能

send

HTTP リクエストヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

responseHeaderMode

省略可能

send

HTTP レスポンスヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

requestBodyMode

省略可能

none

HTTP リクエストボディが送信されるモード。 サポートされている値は、​none​、​streamed​、​buffered​、​bufferedPartial​ です。​none​ を選択すると、リクエストボディが送信されません。

responseBodyMode

省略可能

none

HTTP レスポンスボディが送信されるモード。 サポートされている値は、​none​、​streamed​、​buffered​、​bufferedPartial​ です。​none​ を選択すると、リクエストボディが送信されません。

requestTrailerMode

省略可能

skip

HTTP 要求のトレーラーヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

responseTrailerMode

省略可能

skip

HTTP 応答のトレーラーヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

failureModeAllow

省略可能

false

true​ の場合、gRPC ストリームが早期に終了するか、開始できないと、要求の処理がエラーなしで続行されます。

maxMessageTimeout

省略可能

0

処理サーバーが ​messageTimeout​ を上書きできる上限を指定します。

allowModeOverride

省略可能

true

処理サーバーがポリシー設定を上書きできるようにします。​true​ の場合、サーバーが ​requestHeaderMode​、​responseHeaderMode​、​requestBodyMode​、​responseBodyMode​、​requestTrailerMode​、​responseTrailerMode​ パラメーターの設定を上書きできます。
値を空白のままにすると、パラメーターがデフォルト値を使用して設定されます。必須パラメーターにデフォルト値が設定されていない場合、パラメーターを設定する必要があります。
#### [](#リソースの設定例)リソースの設定例 次の設定では、リクエストヘッダー、トレーラー、本文が外部処理サーバーに送信されます。次の設定では、応答はどの部分も外部処理サーバーに送信されません。 ```yaml - policyRef: name: native-ext-proc-flex config: uri: h2://: messageTimeout: // OPTIONAL responseHeaderMode: skip requestBodyMode: streamed responseTrailerMode: skip ``` ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI から外部処理ポリシーを API に適用する場合は、以下のパラメーターを設定します。
パラメーター 説明

External processing server URI (外部処理サーバー URI)

外部処理サーバー URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

Message timeout (メッセージタイムアウト)

処理サーバーのメッセージタイムアウト (ミリ秒)。

Request header processing mode (リクエストヘッダーの処理モード)

リクエストヘッダーが処理サービスに送信されるかどうか。

Response header processing mode (レスポンスヘッダーの処理モード)

レスポンスヘッダーが処理サービスに送信されるかどうか。

Request body processing mode (リクエストボディの処理モード)

リクエストボディが送信されるモード。

Response body processing mode (レスポンスボディの処理モード)

レスポンスボディが送信されるモード。

Request trailer processing mode (要求のトレーラーの処理モード)

要求のトレーラーが処理サービスに送信されるかどうか。

Response trailer processing mode (応答のトレーラーの処理モード)

応答のトレーラーが処理サービスに送信されるかどうか。

Failure mode allow (障害モードの許可)

true​ の場合、gRPC ストリームが早期に終了するか、開始できないと、要求の処理がエラーなしで続行されます。

Max message timeout (最大メッセージタイムアウト)

処理サーバーが ​[Message timeout (メッセージタイムアウト)]​ を上書きできる上限を指定します。

Allow mode override (モードの上書きを許可)

処理サーバーがポリシー設定を上書きできるようにします。​true​ の場合、サーバーは ​[Request header processing mode (リクエストヘッダーの処理モード)]​、​[Response header processing mode (レスポンスヘッダーの処理モード)]​、​[Request body processing mode (リクエストボディの処理モード)]​、​[Response body processing mode (レスポンスボディの処理モード)]​、​[Request trailer processing mode (リクエストトレーラーの処理モード)]​、​[Response trailer processing mode (レスポンストレーラーの処理モード)]​ パラメーターの設定を上書きできます。
値を空白のままにすると、パラメーターがデフォルト値を使用して設定されます。必須パラメーターにデフォルト値が設定されていない場合、パラメーターを設定する必要があります。
## [](#ポリシーのしくみ)ポリシーのしくみ 次の図は、外部処理ポリシーを適用した場合の要求と応答のフローの順序を示しています。 ![80%](/mulesoft/current/ja-jp/gateway/1.8/_images/ext-processing-policy.png) 1. クライアントが Flex Gateway に対する HTTP 要求を行います。 2. Flex Gateway が設定済みのクライアント HTTP 要求の最初の部分を外部処理サービスに転送します。​**\[Allow mode override (モードの上書きを許可)\]**​ が有効になっている場合、この時点で外部処理サービスは要求の追加の部分を要求できます。 3. Flex Gateway が変更された HTTP 要求を受信すると、Flex Gateway は HTTP 要求をアップストリーム API サービスに送信します。 4. Flex Gateway がアップストリーム API サービスから HTTP 応答を受信し、設定済みの HTTP 応答の最初の部分を外部処理サービスに転送します。この時点で、外部処理サービスは HTTP 応答の追加の部分を要求できます。 5. Flex Gateway が外部処理サービスからクライアントに変更済みの HTTP 応答を返します。 デフォルトでは、Flex Gateway が gRPC サービスへの接続を確立できない場合、または gRPC サービスでエラーが返される場合は、ポリシーが失敗します。接続やエラー状況に関係なく要求を転送するには、​**\[Failure mode allow (障害モードの許可)\]**​ パラメーターを有効にします。 # 外部処理ポリシー

ポリシー名

外部処理

Summary (概要)

追加処理を行うために、受信 HTTP 要求または送信 HTTP 応答要求を外部 gRPC サービスに送信します

カテゴリ

変換

使用可能な最小 Flex Gateway バージョン

v1.6.0

返される状況コード

403 - IP は拒否されました
## [](#概要)概要 外部処理ポリシーでは、ヘッダー、トレーラー、本文、またはこの 3 つのいずれかの組み合わせを変更するために、受信 HTTP 要求または送信 HTTP 応答を外部 gRPC サービスに転送します。要求、応答、またはその両方を処理するようにこのポリシーを設定することもできます。 さらに、外部処理サービスでは最初の gRPC 要求が Flex Gateway によって外部処理サーバーに送信された後に HTTP 要求または応答の別の部分を要求できます。これにより、必要最小限の量のデータを送信できます。たとえば、Flex Gateway では最初に HTTP リクエストヘッダーのみを送信できます。その後、何らかの処理を行った後で、外部プロセッサーが Flex Gateway からの HTTP 要求の本文またはトレーラーを要求できます。 HTTP ヘッダー、トレーラー、本文について設定するパラメーターでは、最初に送信される内容のみが設定されます。外部処理サービスは、設定ないように関係なく、HTTP 要求または応答のすべての部分にアクセスできます。処理サービスがすべての受信 HTTP 要求または応答に必要なすべての情報を送信するようにパラメーターを設定します。たとえば、処理サービスにすべてのリクエストヘッダーが必要だが一部の要求の本文しか必要ない場合は、ヘッダーで確認できる情報に応じて、ヘッダーを送信するパラメーターのみを設定します。 外部処理ポリシーは、Envoy に対してネイティブな外部処理検索条件の拡張機能です。外部処理検索条件に付いての詳細は、 [「External Processing Filter (外部処理検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ext_proc/v3/ext_proc.proto)​を参照してください。すべての外部処理検索条件パラメーターが外部処理ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。
他のポリシーで HTTP 要求または応答が変更される場合は、要求が処理サービスまたはアップストリームサービスに送信されるときにこれらの変更が存在している必要があるかどうかに応じて確実にポリシーを並び替えてください。ポリシーの並び替えについての詳細は、ポリシーの順序付けを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-ext-proc-flex config: uri: // REQUIRED messageTimeout: // OPTIONAL, default: 1000 requestHeaderMode: // OPTIONAL, default: "send" responseHeaderMode: // OPTIONAL, default: "send" requestBodyMode: // OPTIONAL, default: "none" responseBodyMode: // OPTIONAL, default: "none" requestTrailerMode: // OPTIONAL, default: "skip" responseTrailerMode: // OPTIONAL, default: "skip" failureModeAllow: // OPTIONAL, default: false maxMessageTimeout: // OPTIONAL, default: 0 allowModeOverride: // OPTIONAL, default: true ```
パラメーター 必須または省略可能 デフォルト値 説明

uri

必須

なし

外部処理サーバー URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

messageTimeout

省略可能

1000

処理サーバーのメッセージタイムアウト (ミリ秒)。

maxMessageTimeout

省略可能

0

処理サーバーが ​messageTimeout​ を上書きできる上限を指定します。

failureModeAllow

省略可能

false

true​ の場合、gRPC ストリームが早期に終了するか、開始できないと、要求の処理がエラーなしで続行されます。

allowModeOverride

省略可能

true

処理サーバーがポリシー設定を上書きできるようにします。​true​ の場合、サーバーが ​requestHeaderMode​、​responseHeaderMode​、​requestBodyMode​、​responseBodyMode​、​requestTrailerMode​、​responseTrailerMode​ パラメーターの設定を上書きできます。

observabilityMode

省略可能

false

true​ の場合、設定されたヘッダー、本文、トレーラーが外部処理サーバーに送信され、Flex Gateway は処理サーバーからの応答を待ちません。

requestHeaderMode

省略可能

send

HTTP リクエストヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

responseHeaderMode

省略可能

send

HTTP レスポンスヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

requestBodyMode

省略可能

none

HTTP 要求の本文が送信されるモード。 サポートされている値は、​none​、​streamed​、​buffered​、​bufferedPartial​ です。​none​ を選択すると、リクエストボディが送信されません。

responseBodyMode

省略可能

none

HTTP 応答の本文が送信されるモード。 サポートされている値は、​none​、​streamed​、​buffered​、​bufferedPartial​ です。​none​ を選択すると、リクエストボディが送信されません。

requestTrailerMode

省略可能

skip

HTTP 要求のトレーラーヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。

responseTrailerMode

省略可能

skip

HTTP 応答のトレーラーヘッダーが処理サービスに送信されるかどうか。サポートされている値は ​send​ と ​skip​ です。
値を空白のままにすると、パラメーターがデフォルト値を使用して設定されます。必須パラメーターにデフォルト値が設定されていない場合、パラメーターを設定する必要があります。
#### [](#リソースの設定例)リソースの設定例 次の設定では、リクエストヘッダー、トレーラー、本文が外部処理サーバーに送信されます。次の設定では、応答はどの部分も外部処理サーバーに送信されません。 ```yaml - policyRef: name: native-ext-proc-flex config: uri: h2://: messageTimeout: // OPTIONAL responseHeaderMode: skip requestBodyMode: streamed responseTrailerMode: skip ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

External processing server URI (外部処理サーバー URI)

外部処理サーバー URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

Message timeout (メッセージタイムアウト)

処理サーバーのメッセージタイムアウト (ミリ秒)。

Max message timeout (最大メッセージタイムアウト)

処理サーバーが ​[Message timeout (メッセージタイムアウト)]​ を上書きできる上限を指定します。

Failure mode allow (障害モードの許可)

true​ の場合、gRPC ストリームが早期に終了するか、開始できないと、要求の処理がエラーなしで続行されます。

Allow mode override (モードの上書きを許可)

処理サーバーがポリシー設定を上書きできるようにします。​true​ の場合、サーバーは ​[Request header processing mode (リクエストヘッダーの処理モード)]​、​[Response header processing mode (レスポンスヘッダーの処理モード)]​、​[Request body processing mode (リクエストボディの処理モード)]​、​[Response body processing mode (レスポンスボディの処理モード)]​、​[Request trailer processing mode (リクエストトレーラーの処理モード)]​、​[Response trailer processing mode (レスポンストレーラーの処理モード)]​ パラメーターの設定を上書きできます。

Observability mode (オブザーバビリティモード)

有効にすると、設定されたヘッダー、本文、トレーラーが外部処理サーバーに送信され、Flex Gateway は処理サーバーからの応答を待機しません。

Request header processing mode (リクエストヘッダーの処理モード)

リクエストヘッダーが処理サービスに送信されるかどうか。

Response header processing mode (レスポンスヘッダーの処理モード)

レスポンスヘッダーが処理サービスに送信されるかどうか。

Request body processing mode (要求の本文の処理モード)

要求の本文が送信されるモード。

Response body processing mode (応答の本文の処理モード)

応答の本文が送信されるモード。

Request trailer processing mode (要求のトレーラーの処理モード)

要求のトレーラーが処理サービスに送信されるかどうか。

Response trailer processing mode (応答のトレーラーの処理モード)

応答のトレーラーが処理サービスに送信されるかどうか。
値を空白のままにすると、パラメーターがデフォルト値を使用して設定されます。必須パラメーターにデフォルト値が設定されていない場合、パラメーターを設定する必要があります。
## [](#ポリシーのしくみ)ポリシーのしくみ 次の図は、外部処理ポリシーを適用した場合の要求と応答のフローの順序を示しています。 ![API インタラクションを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/ext-processing-policy.png) 1. クライアントが Flex Gateway に対する HTTP 要求を行います。 2. Flex Gateway が設定済みのクライアント HTTP 要求の最初の部分を外部処理サービスに転送します。​**\[Observability mode (オブザーバビリティモード)\]**​ が有効になっていると、次のステップはスキップされます。 3. Flex Gateway は変更されたクライアント HTTP 要求を待機します。​**\[Allow mode override (モードの上書きを許可)\]**​ が有効になっていると、外部処理サービスは要求の追加の部分を要求できます。 4. Flex Gateway はクライアント HTTP 要求をアップストリーム API サービスに送信し、HTTP 応答を待機します。 5. Flex Gateway が設定済みの HTTP 応答の最初の部分を外部処理サービスに転送します。​**\[Observability mode (オブザーバビリティモード)\]**​ が有効になっていると、次のステップはスキップされます。 6. Flex Gateway は変更された HTTP 応答を待機します。​**\[Allow mode override (モードの上書きを許可)\]**​ が有効になっていると、外部処理サービスは HTTP 応答の追加の部分を要求できます。 7. Flex Gateway が外部処理サービスからクライアントに変更済みの HTTP 応答を返します。 デフォルトでは、Flex Gateway が gRPC サービスへの接続を確立できない場合、または gRPC サービスでエラーが返される場合は、ポリシーが失敗します。接続やエラー状況に関係なく要求を転送するには、​**\[Failure mode allow (障害モードの許可)\]**​ パラメーターを有効にします。 # 外部認証ポリシー

ポリシー名

外部認証

Summary (概要)

外部 gRPC または HTTP 認証サービスを使用して要求を認証します

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.6.0

返される状況コード

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報
## [](#概要)概要 外部認証ポリシーでは、受信クライアント HTTP 要求を外部 gRPC または HTTP 認証サービスに転送してクライアント HTTP 要求がアップストリームサービスへのアクセスを承認されるかどうかを判断します。要求が承認されると、Flex Gateway では要求がアップストリームサービスに渡されることを許可します。不正なアクセスでは、Flex Gateway では ​`403`​ 禁止要求エラーを返します。 認証トークンヘッダーなどのリクエストヘッダーをクライアント HTTP 要求から認証サービスに転送するには、​**\[Allowed Headers (許可されるヘッダー)\]**​ パラメーターを設定します。さらに、HTTP 認証サーバーの場合は、​**\[Headers to add (追加するヘッダー)\]**​ パラメーターを使用して新しいヘッダーを認証要求に挿入します。

Flex Gateway によってヘッダーがバイト単位でエンコードされ、認証サービスに送信されます。utf8 でエンコードされたヘッダーを送信するには、環境変数 ​FLEX_HEADER_RAW_VALUE_ENABLE=false​ を設定します。
外部認証ポリシーでは、認証サービスから返された追加情報を使用してクライアント HTTP リクエストおよびレスポンスヘッダーを変更することもできます。たとえば、承認済みのユーザーがユーザー名に対応するアクセストークンヘッダーを使用して要求を行うと、認証サービスでは Flex Gateway がクライアント HTTP 要求を追加できるように ​`username`​ ヘッダーを返す場合があります。 gRPC 認証サーバーの場合は、認証サービスが認証応答を含めてヘッダーを返す場合、Flex Gateway ではこれらのヘッダーをクライアント HTTP 要求に追加するか、クライアント要求に存在する場合はヘッダーを上書きします。 HTTP 認証サーバーの場合は、追加、上書き、または無視するヘッダーを設定できます。HTTP サーバーが設定されているポリシーでも、アップストリームサービスから返されるクライアント応答を変更できます。 外部認証ポリシーは、Envoy に対してネイティブな外部認証検索条件の拡張機能です。外部認証検索条件に付いての詳細は、 [「External Authorization Filter (外部認証検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter)​を参照してください。すべての外部認証検索条件パラメーターが外部認証ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。
他のポリシーで受信 HTTP 要求が変更される場合は、要求を認証サービスに送信する前にこれらの変更が存在している必要があるかどうかに応じて確実にポリシーを並び替えてください。ポリシーの並び替えについての詳細は、ポリシーの順序付けを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ポリシーパラメーターを設定するには、Flex Gateway が実行されているモードに関する次のパラメーターリファレンスを参照してください。 - [Flex Gateway のローカルモード](#local-mode) - [管理 Flex Gateway および Flex Gateway の接続モード](#connected-mode) ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-ext-authz-flex config: uri: // REQUIRED serverType: // REQUIRED, default "grpc" serverApiVersion: // REQUIRED, default `v3` serviceRequestHeadersToAdd: // OPTIONAL - key: value: serviceResponseUpstreamHeaders: // OPTIONAL serviceResponseUpstreamHeadersToAppend: // OPTIONAL serviceResponseClientHeaders: // OPTIONAL serviceResponseClientHeadersOnSuccess: // OPTIONAL pathPrefix: // OPTIONAL requestTimeout: // REQUIRED, default `5000` includePeerCertificate: // REQUIRED, default `false` allowedHeaders: // OPTIONAL ```
パラメーター 必須または省略可能 デフォルト値 説明

uri

必須

なし

外部認証サービス URI。gRPC 種別のサーバーでは、次の形式を使用して URI を定義します: h2://<ext.authz.com>:<port>​。

serverType

必須

grpc

外部サーバーの種別。サポートされている値は ​grpc​ と ​http​ です。

serverApiVersion

省略可能

v3

トランスポートプロトコル API バージョン。サポートされている値は ​v3​ と ​v2​ です。

includePeerCertificate

省略可能

false

true​ の場合、認証サーバー要求にピア証明書が含まれます。サポートされている値は ​true​ と ​false​ です。

serviceRequestHeadersToAdd

省略可能

なし

認証サービス要求に挿入するカスタムヘッダーとその値が定義されます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceRequestHeadersToAdd.key

省略可能

なし

追加する新しいヘッダーの名前。

serviceRequestHeadersToAdd.value

省略可能

なし

追加する新しいヘッダーの値。

serviceResponseUpstreamHeaders

省略可能

なし

アップストリームサービスへのクライアント要求に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって共存するヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseUpstreamHeadersToAppend

省略可能

なし

アップストリームサービスへのクライアント要求に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって共存するヘッダーが追加されます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseClientHeaders

省略可能

なし

アップストリームサービスから返されるクライアント応答に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって既存のヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseClientHeadersOnSuccess

省略可能

なし

要求が正常に認証された場合にアップストリームサービスから返されるクライアント応答に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって既存のヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

pathPrefix

省略可能

なし

Path​ 認証リクエストヘッダーが存在する場合はその値に対するプレフィックスを設定します。

requestTimeout

省略可能

5000

ポリシーが認証サービスからの応答を待機する最大時間 (ミリ秒)。

allowedHeaders

省略可能

なし

認証要求に伝播するクライアント HTTP 要求からのヘッダーが指定されます。デフォルトでは、gRPC サーバーに送信される要求にはすべてのクライアントヘッダーが含まれます。HTTP サーバーに送信される要求にはクライアントヘッダーが含まれません。各サーバー種別の許可されるヘッダーをリストする場合は、要求にリストされたヘッダーのみが含まれます。
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
### [](#リソースの設定例)リソースの設定例 次の設定では、gRPC 認証サービスがピア証明書と認証トークンヘッダーが含まれる要求を受信します。 ```yaml - policyRef: name: native-ext-authz-flex config: uri: h2://ext-authz-grpc-service:9001 serverType: "grpc" includePeerCertificate: "true" allowedHeaders: - access-token ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

External authorization service URI (外部認証サービス URI)

外部認証サービス URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

External authorization server type (外部認証サーバー種別)

外部サーバーの種別。

Server API version (サーバー API バージョン)

トランスポートプロトコル API バージョン。

Include peer certificates in the authorization server request (認証サーバー要求にピア証明書が含まれる)

認証サーバー要求にピア証明書が含まれます。

Path prefix (パスプレフィックス)

Path​ 認証リクエストヘッダーが存在する場合はその値に対するプレフィックスを設定します。

Request Timeout (要求タイムアウト)

ポリシーが認証サービスからの応答を待機する最大時間 (ミリ秒)。デフォルトでは、要求タイムアウトは 5000 ミリ秒です。

Allowed headers (許可されるヘッダー)

デフォルトでは、gRPC サーバーに送信される要求にはすべてのクライアントヘッダーが含まれ、HTTP サーバーに送信される要求にはクライアントヘッダーが含まれません。各サーバー種別の許可されるヘッダーをリストする場合は、要求にリストされたヘッダーのみが含まれます。
## [](#ポリシーのしくみ)ポリシーのしくみ 次の図は、外部認証ポリシー実行時の要求と応答のフローの順序を示しています。 ![ユーザー、API ゲートウェイ、データベース、API 間のインタラクションを示すシーケンス図](/mulesoft/current/ja-jp/gateway/1.10/_images/ext-auth-policy.png) 1. クライアントが Flex Gateway によって公開される API インスタンスに対する HTTP 要求を行います。 2. Flex Gateway がクライアントの要求とヘッダーで構成される要求を認証サービスに転送します。 3. 認証サービスが認証応答を Flex Gateway に送信し返します。 - 要求が認証されない場合、Flex Gateway では必要なヘッダーを追加し、​`403`​ 禁止アクセスコードをクライアントに返します。 - 要求が承認されると、Flex Gateway では必要に応じてヘッダーデータをクライアント要求に追加して、要求がアップストリームサービスに渡されることを許可します。 4. Flex Gateway は必要なヘッダーを追加し、通常どおりに応答を返します。 # 外部認証ポリシー

ポリシー名

外部認証

Summary (概要)

外部 gRPC または HTTP 認証サービスを使用して要求を認証します

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.6.0

返される状況コード

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報
## [](#概要)概要 外部認証ポリシーでは、受信クライアント HTTP 要求を外部 gRPC または HTTP 認証サービスに転送してクライアント HTTP 要求がアップストリームサービスへのアクセスを承認されるかどうかを判断します。要求が承認されると、Flex Gateway では要求がアップストリームサービスに渡されることを許可します。不正なアクセスでは、Flex Gateway では ​`403`​ 禁止要求エラーを返します。 認証トークンヘッダーなどのリクエストヘッダーをクライアント HTTP 要求から認証サービスに転送するには、​**\[Allowed Headers (許可されるヘッダー)\]**​ パラメーターを設定します。さらに、HTTP 認証サーバーの場合は、​**\[Headers to add (追加するヘッダー)\]**​ パラメーターを使用して新しいヘッダーを認証要求に挿入します。

Flex Gateway によってヘッダーがバイト単位でエンコードされ、認証サービスに送信されます。utf8 でエンコードされたヘッダーを送信するには、環境変数 ​FLEX_HEADER_RAW_VALUE_ENABLE=false​ を設定します。
外部認証ポリシーでは、認証サービスから返された追加情報を使用してクライアント HTTP リクエストおよびレスポンスヘッダーを変更することもできます。たとえば、承認済みのユーザーがユーザー名に対応するアクセストークンヘッダーを使用して要求を行うと、認証サービスでは Flex Gateway がクライアント HTTP 要求を追加できるように ​`username`​ ヘッダーを返す場合があります。 gRPC 認証サーバーの場合は、認証サービスが認証応答を含めてヘッダーを返す場合、Flex Gateway ではこれらのヘッダーをクライアント HTTP 要求に追加するか、クライアント要求に存在する場合はヘッダーを上書きします。 HTTP 認証サーバーの場合は、追加、上書き、または無視するヘッダーを設定できます。HTTP サーバーが設定されているポリシーでも、アップストリームサービスから返されるクライアント応答を変更できます。 外部認証ポリシーは、Envoy に対してネイティブな外部認証検索条件の拡張機能です。外部認証検索条件に付いての詳細は、 [「External Authorization Filter (外部認証検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter)​を参照してください。すべての外部認証検索条件パラメーターが外部認証ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。
他のポリシーで受信 HTTP 要求が変更される場合は、要求を認証サービスに送信する前にこれらの変更が存在している必要があるかどうかに応じて確実にポリシーを並び替えてください。ポリシーの並び替えについての詳細は、ポリシーの順序付けを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ポリシーパラメーターを設定するには、Flex Gateway が実行されているモードに関する次のパラメーターリファレンスを参照してください。 - [Flex Gateway のローカルモード](#local-mode) - [Flex Gateway の接続モード](#connected-mode) ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、YAML 設定ファイルを使用して外部認証ポリシーを API インスタンスに適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-ext-authz-flex config: uri: // REQUIRED serverType: // REQUIRED, default "grpc" serverApiVersion: // REQUIRED, default `v3` serviceRequestHeadersToAdd: // OPTIONAL - key: value: serviceResponseUpstreamHeaders: // OPTIONAL serviceResponseUpstreamHeadersToAppend: // OPTIONAL serviceResponseClientHeaders: // OPTIONAL serviceResponseClientHeadersOnSuccess: // OPTIONAL pathPrefix: // OPTIONAL requestTimeout: // REQUIRED, default `5000` includePeerCertificate: // REQUIRED, default `false` allowedHeaders: // OPTIONAL ```
パラメーター 必須または省略可能 デフォルト値 説明

uri

必須

なし

外部認証サービス URI。gRPC 種別のサーバーでは、次の形式を使用して URI を定義します: h2://<ext.authz.com>:<port>​。

serverType

必須

grpc

外部サーバーの種別。サポートされている値は ​grpc​ と ​http​ です。

serverApiVersion

省略可能

v3

トランスポートプロトコル API バージョン。サポートされている値は ​v3​ と ​v2​ です。

includePeerCertificate

省略可能

false

true​ の場合、認証サーバー要求にピア証明書が含まれます。サポートされている値は ​true​ と ​false​ です。

serviceRequestHeadersToAdd

省略可能

なし

認証サービス要求に挿入するカスタムヘッダーとその値が定義されます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceRequestHeadersToAdd.key

省略可能

なし

追加する新しいヘッダーの名前。

serviceRequestHeadersToAdd.value

省略可能

なし

追加する新しいヘッダーの値。

serviceResponseUpstreamHeaders

省略可能

なし

アップストリームサービスへのクライアント要求に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって共存するヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseUpstreamHeadersToAppend

省略可能

なし

アップストリームサービスへのクライアント要求に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって共存するヘッダーが追加されます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseClientHeaders

省略可能

なし

アップストリームサービスから返されるクライアント応答に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって既存のヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseClientHeadersOnSuccess

省略可能

なし

要求が正常に認証された場合にアップストリームサービスから返されるクライアント応答に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって既存のヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

pathPrefix

省略可能

なし

Path​ 認証リクエストヘッダーが存在する場合はその値に対するプレフィックスを設定します。

requestTimeout

省略可能

5000

ポリシーが認証サービスからの応答を待機する最大時間 (ミリ秒)。

allowedHeaders

省略可能

なし

認証要求に伝播するクライアント HTTP 要求からのヘッダーが指定されます。デフォルトでは、gRPC サーバーに送信される要求にはすべてのクライアントヘッダーが含まれます。HTTP サーバーに送信される要求にはクライアントヘッダーが含まれません。各サーバー種別の許可されるヘッダーをリストする場合は、要求にリストされたヘッダーのみが含まれます。
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
### [](#リソースの設定例)リソースの設定例 次の設定では、gRPC 認証サービスがピア証明書と認証トークンヘッダーが含まれる要求を受信します。 ```yaml - policyRef: name: native-ext-authz-flex config: uri: h2://ext-authz-grpc-service:9001 serverType: "grpc" includePeerCertificate: "true" allowedHeaders: - access-token ``` ### [](#connected-mode)Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

External authorization service URI (外部認証サービス URI)

外部認証サービス URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

External authorization server type (外部認証サーバー種別)

外部サーバーの種別。

Server API version (サーバー API バージョン)

トランスポートプロトコル API バージョン。

Include peer certificates in the authorization server request (認証サーバー要求にピア証明書が含まれる)

認証サーバー要求にピア証明書が含まれます。

Path prefix (パスプレフィックス)

Path​ 認証リクエストヘッダーが存在する場合はその値に対するプレフィックスを設定します。

Request Timeout (要求タイムアウト)

ポリシーが認証サービスからの応答を待機する最大時間 (ミリ秒)。デフォルトでは、要求タイムアウトは 5000 ミリ秒です。

Allowed headers (許可されるヘッダー)

デフォルトでは、gRPC サーバーに送信される要求にはすべてのクライアントヘッダーが含まれ、HTTP サーバーに送信される要求にはクライアントヘッダーが含まれません。各サーバー種別の許可されるヘッダーをリストする場合は、要求にリストされたヘッダーのみが含まれます。
## [](#ポリシーのしくみ)ポリシーのしくみ 次の図は、外部認証ポリシー実行時の要求と応答のフローの順序を示しています。 ![80%](/mulesoft/current/ja-jp/gateway/1.8/_images/ext-auth-policy.png) 1. クライアントが Flex Gateway によって公開される API インスタンスに対する HTTP 要求を行います。 2. Flex Gateway がクライアントの要求とヘッダーで構成される要求を認証サービスに転送します。 3. 認証サービスが認証応答を Flex Gateway に送信し返します。 - 要求が認証されない場合、Flex Gateway では必要なヘッダーを追加し、​`403`​ 禁止アクセスコードをクライアントに返します。 - 要求が承認されると、Flex Gateway では必要に応じてヘッダーデータをクライアント要求に追加して、要求がアップストリームサービスに渡されることを許可します。 4. Flex Gateway は必要なヘッダーを追加し、通常どおりに応答を返します。 # 外部認証ポリシー

ポリシー名

外部認証

Summary (概要)

外部 gRPC または HTTP 認証サービスを使用して要求を認証します

カテゴリ

セキュリティ

使用可能な最小 Flex Gateway バージョン

v1.6.0

返される状況コード

403 - アクセス拒否、無効なクライアントアプリケーションログイン情報
## [](#概要)概要 外部認証ポリシーでは、受信クライアント HTTP 要求を外部 gRPC または HTTP 認証サービスに転送してクライアント HTTP 要求がアップストリームサービスへのアクセスを承認されるかどうかを判断します。要求が承認されると、Flex Gateway では要求がアップストリームサービスに渡されることを許可します。不正なアクセスでは、Flex Gateway では ​`403`​ 禁止要求エラーを返します。 認証トークンヘッダーなどのリクエストヘッダーをクライアント HTTP 要求から認証サービスに転送するには、​**\[Allowed Headers (許可されるヘッダー)\]**​ パラメーターを設定します。さらに、HTTP 認証サーバーの場合は、​**\[Headers to add (追加するヘッダー)\]**​ パラメーターを使用して新しいヘッダーを認証要求に挿入します。

Flex Gateway によってヘッダーがバイト単位でエンコードされ、認証サービスに送信されます。utf8 でエンコードされたヘッダーを送信するには、環境変数 ​FLEX_HEADER_RAW_VALUE_ENABLE=false​ を設定します。
外部認証ポリシーでは、認証サービスから返された追加情報を使用してクライアント HTTP リクエストおよびレスポンスヘッダーを変更することもできます。たとえば、承認済みのユーザーがユーザー名に対応するアクセストークンヘッダーを使用して要求を行うと、認証サービスでは Flex Gateway がクライアント HTTP 要求を追加できるように ​`username`​ ヘッダーを返す場合があります。 gRPC 認証サーバーの場合は、認証サービスが認証応答を含めてヘッダーを返す場合、Flex Gateway ではこれらのヘッダーをクライアント HTTP 要求に追加するか、クライアント要求に存在する場合はヘッダーを上書きします。 HTTP 認証サーバーの場合は、追加、上書き、または無視するヘッダーを設定できます。HTTP サーバーが設定されているポリシーでも、アップストリームサービスから返されるクライアント応答を変更できます。 外部認証ポリシーは、Envoy に対してネイティブな外部認証検索条件の拡張機能です。外部認証検索条件に付いての詳細は、 [「External Authorization Filter (外部認証検索条件)」](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/ext_authz_filter)​を参照してください。すべての外部認証検索条件パラメーターが外部認証ポリシーで使用できるとは限りません。設定可能なパラメーターを確認するには、​[「ポリシーのパラメーターの設定」](#configuring-policy-parameters)​を参照してください。
他のポリシーで受信 HTTP 要求が変更される場合は、要求を認証サービスに送信する前にこれらの変更が存在している必要があるかどうかに応じて確実にポリシーを並び替えてください。ポリシーの並び替えについての詳細は、ポリシーの順序付けを参照してください。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ポリシーパラメーターを設定するには、Flex Gateway が実行されているモードに関する次のパラメーターリファレンスを参照してください。 - [Flex Gateway のローカルモード](#local-mode) - [管理 Flex Gateway および Flex Gateway の接続モード](#connected-mode) ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 ```yaml - policyRef: name: native-ext-authz-flex config: uri: // REQUIRED serverType: // REQUIRED, default "grpc" serverApiVersion: // REQUIRED, default `v3` serviceRequestHeadersToAdd: // OPTIONAL - key: value: serviceResponseUpstreamHeaders: // OPTIONAL serviceResponseUpstreamHeadersToAppend: // OPTIONAL serviceResponseClientHeaders: // OPTIONAL serviceResponseClientHeadersOnSuccess: // OPTIONAL pathPrefix: // OPTIONAL requestTimeout: // REQUIRED, default `5000` includePeerCertificate: // REQUIRED, default `false` allowedHeaders: // OPTIONAL ```
パラメーター 必須または省略可能 デフォルト値 説明

uri

必須

なし

外部認証サービス URI。gRPC 種別のサーバーでは、次の形式を使用して URI を定義します: h2://<ext.authz.com>:<port>​。

serverType

必須

grpc

外部サーバーの種別。サポートされている値は ​grpc​ と ​http​ です。

serverApiVersion

省略可能

v3

トランスポートプロトコル API バージョン。サポートされている値は ​v3​ と ​v2​ です。

includePeerCertificate

省略可能

false

true​ の場合、認証サーバー要求にピア証明書が含まれます。サポートされている値は ​true​ と ​false​ です。

serviceRequestHeadersToAdd

省略可能

なし

認証サービス要求に挿入するカスタムヘッダーとその値が定義されます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceRequestHeadersToAdd.key

省略可能

なし

追加する新しいヘッダーの名前。

serviceRequestHeadersToAdd.value

省略可能

なし

追加する新しいヘッダーの値。

serviceResponseUpstreamHeaders

省略可能

なし

アップストリームサービスへのクライアント要求に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって共存するヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseUpstreamHeadersToAppend

省略可能

なし

アップストリームサービスへのクライアント要求に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって共存するヘッダーが追加されます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseClientHeaders

省略可能

なし

アップストリームサービスから返されるクライアント応答に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって既存のヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

serviceResponseClientHeadersOnSuccess

省略可能

なし

要求が正常に認証された場合にアップストリームサービスから返されるクライアント応答に追加する認証応答からのヘッダーが指定されます。Flex Gateway によって既存のヘッダーが上書きされます。このパラメーターは ​HTTP​ 種別のサーバーで使用できます。

pathPrefix

省略可能

なし

Path​ 認証リクエストヘッダーが存在する場合はその値に対するプレフィックスを設定します。

requestTimeout

省略可能

5000

ポリシーが認証サービスからの応答を待機する最大時間 (ミリ秒)。

allowedHeaders

省略可能

なし

認証要求に伝播するクライアント HTTP 要求からのヘッダーが指定されます。デフォルトでは、gRPC サーバーに送信される要求にはすべてのクライアントヘッダーが含まれます。HTTP サーバーに送信される要求にはクライアントヘッダーが含まれません。各サーバー種別の許可されるヘッダーをリストする場合は、要求にリストされたヘッダーのみが含まれます。
必須の値を空白のままにすると、パラメーターがデフォルト値として設定されます。省略可能な値を空白のままにした場合は、値が設定されません。
### [](#リソースの設定例)リソースの設定例 次の設定では、gRPC 認証サービスがピア証明書と認証トークンヘッダーが含まれる要求を受信します。 ```yaml - policyRef: name: native-ext-authz-flex config: uri: h2://ext-authz-grpc-service:9001 serverType: "grpc" includePeerCertificate: "true" allowedHeaders: - access-token ``` ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
パラメーター 説明

External authorization service URI (外部認証サービス URI)

外部認証サービス URI。gRPC 種別のサーバーでは、​\h2://<ext.authz.com>:<port>​ として URI を定義します。

External authorization server type (外部認証サーバー種別)

外部サーバーの種別。

Server API version (サーバー API バージョン)

トランスポートプロトコル API バージョン。

Include peer certificates in the authorization server request (認証サーバー要求にピア証明書が含まれる)

認証サーバー要求にピア証明書が含まれます。

Path prefix (パスプレフィックス)

Path​ 認証リクエストヘッダーが存在する場合はその値に対するプレフィックスを設定します。

Request Timeout (要求タイムアウト)

ポリシーが認証サービスからの応答を待機する最大時間 (ミリ秒)。デフォルトでは、要求タイムアウトは 5000 ミリ秒です。

Allowed headers (許可されるヘッダー)

デフォルトでは、gRPC サーバーに送信される要求にはすべてのクライアントヘッダーが含まれ、HTTP サーバーに送信される要求にはクライアントヘッダーが含まれません。各サーバー種別の許可されるヘッダーをリストする場合は、要求にリストされたヘッダーのみが含まれます。
## [](#ポリシーのしくみ)ポリシーのしくみ 次の図は、外部認証ポリシー実行時の要求と応答のフローの順序を示しています。 ![ユーザー、API ゲートウェイ、データベース、API 間のインタラクションを示すシーケンス図](/mulesoft/current/ja-jp/gateway/1.9/_images/ext-auth-policy.png) 1. クライアントが Flex Gateway によって公開される API インスタンスに対する HTTP 要求を行います。 2. Flex Gateway がクライアントの要求とヘッダーで構成される要求を認証サービスに転送します。 3. 認証サービスが認証応答を Flex Gateway に送信し返します。 - 要求が認証されない場合、Flex Gateway では必要なヘッダーを追加し、​`403`​ 禁止アクセスコードをクライアントに返します。 - 要求が承認されると、Flex Gateway では必要に応じてヘッダーデータをクライアント要求に追加して、要求がアップストリームサービスに渡されることを許可します。 4. Flex Gateway は必要なヘッダーを追加し、通常どおりに応答を返します。 # 宣言型設定リファレンスガイド ローカルモードで実行される Anypoint Flex Gateway は、2 つの設定モデルをサポートします。 - Kubernetes で一般的なリソースベースモデルは、詳細な定義に適しています。各リソースは、設定の ​`kind`​ の値が次のいずれかになります。 - `ApiInstance` - `Service` - `PolicyBinding` - `Configuration` - インラインモデルは簡潔な定義に適していますが、汎用性が低くなります (たとえば、自動ポリシーはリソースベース定義でしか適用できません)。 インライン定義では、設定の ​`kind`​ の値は ​`ApiInstance`​ のみとなり、この下でサービスとポリシーの両方を定義します。 ![API インスタンス、サービス、ポリシーバインドの構造の図](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-configuration-models.png) それぞれの例は​[「例」](#examples)​セクションを参照してください。 このリファレンスガイドでは、リソースベース設定またはインライン設定に適用可能なリソースについて説明します。 ## [](#api-instance)API インスタンス apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: namespace: # optional namespace name spec: address: services: # optional map of upstream services : address: routes: # optional array of routes to service - config: # optional route configuration destinationPath: rules: # optional route rules policies: # optional array of policies - policyRef: name: namespace: config: # optional policy configuration rules: # optional policy rules
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

他のリソース (ポリシーバインドなど) の対象リファレンスとして使用される API インスタンス識別子。

metadata.namespace

省略可能

default

spec.address

必須

なし

プロトコル、ホスト、ポート、パス (省略可能) を含むプロキシアドレス URL。ベースパスを指定する場合は、どの ​rules.path​ 属性にも指定されていないパスでなければなりません。サポートされる形式: protocol://host:port/path​ (​path​ は省略可能で、​protocol​ は ​http​ または ​https​)。

spec.services

省略可能

空

指定されたサービスとルートのマップ。

spec.services[name].address

必須

なし

サービスアドレス (およびポート)。サポートされる形式: protocol://host:port​ (​protocol​ は ​http​ または ​https​)。

spec.services[name].routes

省略可能

空

この API インスタンスに設定されているサービスへのルートの配列。空である場合は、サービスへのデフォルトルートが確立され、すべてのトラフィックがルーティングされます。

spec.services[name].routes[#].config

省略可能

空

このルートの設定。空の場合は、空の ​destinationPath​ でデフォルトの設定が適用されます。

spec.services[name].routes[#].config.destinationPath

省略可能

空

アップストリームサービスに要求を転送するために先頭に追加するパス。たとえば、「destinationPath: /api/v1」と指定した場合、この API インスタンスへの要求で「/orders」のようなパスを指定すると、要求は「/api/v1/orders」のように上流にルーティングされます。

spec.services[name].routes[#].rules

省略可能

空

このルートのルールの配列。「ポリシーバインド」の「​spec.rules​」を参照してください。

spec.policies

省略可能

空

この API インスタンスに適用するポリシーの配列。

spec.policies[#].policyRef.name

必須

なし

ポリシー名。

spec.policies[#].policyRef.namespace

省略可能

metadata.namespace​ の値

ポリシーが定義される名前空間。提供ポリシーの場合、この項目の値は ​default​ である必要があります。

spec.policies[#].config

省略可能

空

ポリシーの設定。「ポリシーバインド」の「​spec.config​」を参照してください。​policies[#].config​ 項目で環境変数を使用するには、​ポリシーバインドの環境変数​を参照してください。

spec.policies[#].rules

省略可能

空

このポリシーを API インスタンスに適用するためのルールの配列。 「ポリシーバインド」の「​spec.rules​」を参照してください。
### [](#api-インスタンスの例)API インスタンスの例 次のリソースは、インスタンス識別子を記述するメタデータを使用して ​`ApiInstance`​ を指定しています。​`metadata.name`​ 値は、他のリソース (ポリシーバインドなど) の対象リファレンスとして使用されます。​`spec.services.routes.config.destinationPath`​ 値は、​`rules`​ の下に指定されているパスの先頭に ​`/v1/apps`​ を追加し、ベースパスのように機能します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: hello-flex-gateway-instance spec: address: http://0.0.0.0:8080 services: json: address: https://:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) config: destinationPath: /v1/apps #### [](#ポート共有)ポート共有 次の ​`ApiInstance`​ リソースは、2 つの異なる API インスタンスがポート 8080 でリスンする API ポート共有を示しています。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: httpbin-example spec: address: http://0.0.0.0:8080/api/httpbin/ services: upstream: address: https://:443 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-example spec: address: http://0.0.0.0:8080/api/json/ services: upstream: address: https://:443 両方のサービスはポート 8080 でリスンします。次に例を示します。 curl http://localhost:8080/api/httpbin/get -v curl http://localhost:8080/api/json/users/1 -v

ポートを共有する API のベースパスは競合しない必要があります。たとえば、次のパスの組み合わせは許可されません。

http://0.0.0.0:8080/cats
http://0.0.0.0:8080/cats/dogs

ポートには TLS が適用されます。そのため、ポートを共有するすべての API インスタンスに同じ TLS ポリシーが適用されます。
## [](#policy-binding)ポリシーバインド apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: namespace: spec: targetRef: name: namespace: policyRef: name: namespace: config: # optional policy configuration order: # optional policy read order rules: # optional policy rules - path: methods: host: headers: :
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

ポリシーバインドの識別子。

metadata.namespace

省略可能

default

spec.targetRef.name

必須

なし

ポリシーがバインドされる API インスタンスまたはアップストリームサービスの識別子。

spec.targetRef.namespace

省略可能

metadata.namespace​ の値

対象が定義される名前空間。

spec.policyRef.name

必須

なし

ポリシー名。利用可能なポリシーのリストを参照してください。

spec.policyRef.namespace

省略可能

metadata.namespace​ の値

ポリシーが定義される名前空間。提供ポリシーの場合、この項目の値は ​default​ である必要があります。

spec.config

省略可能

空

ポリシーの設定。この項目のコンテンツは、指定されたポリシーに依存します。利用可能なポリシーのリストを参照してください。​config​ 項目で環境変数を使用するには、​ポリシーバインドの環境変数​を参照してください。

spec.order

省略可能

50

ポリシー実行チェーン全体におけるポリシーの読み取り順序。

spec.rules

省略可能

空

ポリシーが特定の要求に適用されるかどうかを決定するためのルールの配列。これらのルールは OR 形式でチェックされます。最初に True となったルールに従ってポリシーを要求に適合します。各ルールの属性は、AND 形式で適用されます。パスとホストが定義されている場合は、両方が一致しなければルールは True にはなりません。

spec.rules[#].path

省略可能

.*

要求のパスと一致する正規表現。

要求を上流にルーティングする場合は、この正規表現のキャプチャグループを使用して、パスを置き換えます。

「path: /api(/.*)」と指定すると、/api/orders というパスが指定された要求は、/orders として上流にルーティングされます。

複数のキャプチャグループを指定でき、その場合は、取得されたすべてのサブ文字列が連結されてパスが置き換えられます。

spec.rules[#].host

省略可能

.*

要求のホストと一致する正規表現。

spec.rules[#].methods

省略可能

.*

要求のメソッドと一致する正規表現。

spec.rules[#].headers

省略可能

空

ヘッダー名と要求に含まれる必要がある値の正規表現のマップ。

各エントリのキーは想定されるヘッダー名で、値はヘッダー値と一致する正規表現です。
### [](#ポリシーバインドの例)ポリシーバインドの例 次のリソースは、​`route`​ ポリシーを API インスタンスにバインドして、​`rules`​ で指定されたトラフィックを ​`Service`​ 設定スニペットで指定されたプロキシアドレスにルーティングします。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: hello-flex-gateway-route namespace: e-commerce spec: targetRef: name: hello-flex-gateway-instance policyRef: name: route namespace: default config: destinationRef: name: json namespace: e-commerce rules: - path: /api/json(/.\*) 次のリソースは、​`http-basic-authentication-flex`​ ポリシーを API インスタンスにバインドし、要求に ​`config.username`​ と ​`config.password`​ で定義されている基本ログイン情報を含めることを必須にします。このポリシーには読み取り順序に ​`2`​ の値が与えられます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: hello-flex-gateway-auth namespace: e-commerce spec: targetRef: name: hello-flex-gateway-instance namespace: e-commerce policyRef: name: http-basic-authentication-flex namespace: default config: username: chris password: admin order: 2 ### [](#environment-variables)ポリシーバインドの環境変数 ポリシーバインドリソースとインラインポリシーバインドの両方で ​`config`​ 項目の環境変数がサポートされます。使用可能な環境変数は環境に応じて異なります。 環境変数を参照するには、次のようにプレフィックス ​`$`​ を付けて環境変数を指定します。 \- policyRef: name: http-basic-authentication-flex config: username: $USERNAME password: $PASSWORD ## [](#サービス)サービス apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: namespace: spec: address:
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

サービス識別子。

metadata.namespace

省略可能

default

spec.address

必須

なし

プロトコル、ホスト、ポートを含むサービスアドレス URL。サポートされる形式: protocol://host:port​ (​protocol​ は ​http​ または ​https​)。
### [](#サービスの例)サービスの例 次のリソースは、サービス識別子を記述するメタデータを使用して ​`Service`​ を定義しています。​`metadata.namespace`​ 値は ​`ApiInstance`​ 設定で指定されている名前空間と一致します。​`spec.address`​ は、API 実装のアドレスです。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: json-example namespace: e-commerce spec: address: https://:443/ ## [](#設定)設定 `Configuration`​ エンティティを作成することによって目的のゲートウェイ状態を定義します。 `Configuration`​ エンティティは、Flex Gateway 自身のいくつかのランタイム設定 (​[ログ](#logging)​や​[共有ストレージ](#shared-storage)​など) を指定します。定義には以下が含まれます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: # logging configuration sharedStorage: # shared storage configuration
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

設定エンティティ。

metadata.namespace

省略可能

default

設定エンティティを特定するための名前空間値。

spec

必須

なし

ゲートウェイの特性を定義する設定オブジェクト。オブジェクトには ​logging​、​sharedStorage​、​tls​ があります。
### [](#logging)ログ記録 `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.2.10 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
#### [](#ログの例)ログの例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging spec: logging: outputs: - name: log-to-file type: file parameters: path: /var/log file: log.txt format: template template: | \[{date}\]\[{logger}\]\[{level}\]\[{kind}\] {message} runtimeLogs: logLevel: info outputs: - log-to-file accessLogs: outputs: - log-to-file ### [](#shared-storage)共有ストレージ `sharedStorage`​ オブジェクトは、共有ストレージのゲートウェイを設定します。本番ワークフローでは [Redis](https://redis.io/)​ (最小バージョン 4.0.0) を使用する必要がありますが、その定義は省略可能です。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。 必要に応じて、Redis とトランスポート層セキュリティ (TLS) を使用して、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: // REQUIRED username: // OPTIONAL password: // OPTIONAL db: // OPTIONAL tls: // OPTIONAL trustedCA: // OPTIONAL certificate: // OPTIONAL keyPassphrase // OPTIONAL key: // REQUIRED crt: // REQUIRED alpn: // OPTIONAL skipValidation: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

sharedStorage.redis.address

必須

なし

host:port​ 形式の Redis インスタンスアドレス。

sharedStorage.redis.username

省略可能

空

Redis ユーザー名

sharedStorage.redis.password

省略可能

空

Redis ユーザーパスワード

sharedStorage.redis.db

省略可能

0

使用する Redis データベース番号

sharedStorage.redis.tls

省略可能

空

Redis TLS 設定

sharedStorage.redis.tls.trustedCA

省略可能

なし

サーバー証明書を確認する時に使用するルート認証機関

sharedStorage.redis.tls.certificate

省略可能

なし

サーバーに提供するクライアント証明書

sharedStorage.redis.tls.keyPassphrase

省略可能

none

証明書鍵パスフレーズ。指定された場合、DEK-Info ヘッダーが含まれる非公開鍵形式を使用します。未指定の場合、非公開鍵は暗号化できません。

sharedStorage.redis.tls.certificate.key

必須

なし

証明書の非公開鍵部分

sharedStorage.redis.tls.certificate.crt

必須

なし

証明書の公開鍵部分

sharedStorage.redis.tls.skipValidation

省略可能

false

true の場合、サーバーによって提供されたすべての証明書が受け入れられます。

sharedStorage.redis.tls.minversion

省略可能

1.2

許容される最小 TLS バージョン

sharedStorage.redis.tls.maxversion

省略可能

1.3

許容される最大 TLS バージョン

sharedStorage.redis.tls.alpn

省略可能

空のリスト

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

sharedStorage.redis.tls.ciphers

省略可能

TLS/Redis では、以下を除いて ​TLS ポリシー​と同じ暗号化がサポートされます。

  • TLS_RSA_WITH_NULL_SHA

  • TLS_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
**Redis 共有ストレージ例** Redis ストレージサービスは、オブジェクトストアインターフェースと Redis バックエンド間のブリッジとして機能する、REST API オブジェクトストアの実装です。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` **Redis と TLS の共有ストレージ例** 必要に応じて、Redis と TLS を使用してデータを保護し、安全な通信を確保できます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` **ローカル共有ストレージの例** ローカルストレージサービスは、データをメモリに保存する REST API オブジェクトストアの実装です。Flex Gateway を停止または再起動すると、すべてのデータが失われます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: rtm-config namespace: sales spec: sharedStorage: local: enabled: true ``` ## [](#examples)例 ### [](#インライン設定の例)インライン設定の例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: api-example spec: address: http://0.0.0.0:8080 services: api-example: address: https://:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) config: destinationPath: /v1/apps policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#リソースベース設定の例)リソースベース設定の例 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: ingress-http spec: address: http://0.0.0.0:8080 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: json spec: address: https://:443/ --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-route spec: targetRef: name: ingress-http policyRef: name: route config: destinationRef: name: json rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-authentication spec: targetRef: name: ingress-http policyRef: name: http-basic-authentication-flex config: username: chris password: admin # 宣言型設定リファレンスガイド ローカルモードで実行される Anypoint Flex Gateway は、2 つの設定モデルをサポートします。 - Kubernetes で一般的なリソースベースモデルは、詳細な定義に適しています。各リソースは、設定の ​`kind`​ の値が次のいずれかになります。 - `ApiInstance` - `Service` - `PolicyBinding` - `Configuration` - インラインモデルは簡潔な定義に適していますが、汎用性が低くなります (たとえば、自動ポリシーはリソースベース定義でしか適用できません)。 インライン定義では、設定の ​`kind`​ の値は ​`ApiInstance`​ のみとなり、この下でサービスとポリシーの両方を定義します。 ![gateway configuration models](/mulesoft/current/ja-jp/gateway/1.8/_images/gateway-configuration-models.png) それぞれの例は​[「例」](#examples)​セクションを参照してください。 このリファレンスガイドでは、リソースベース設定またはインライン設定に適用可能なリソースについて説明します。 ## [](#api-instance)API インスタンス apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: namespace: # optional namespace name spec: address: services: # optional map of upstream services : address: routes: # optional array of routes to service - config: # optional route configuration destinationPath: rules: # optional route rules policies: # optional array of policies - policyRef: name: namespace: config: # optional policy configuration rules: # optional policy rules
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

他のリソース (ポリシーバインドなど) の対象リファレンスとして使用される API インスタンス識別子。

metadata.namespace

省略可能

default

spec.address

必須

なし

プロトコル、ホスト、ポート、パス (省略可能) を含むプロキシアドレス URL。ベースパスを指定する場合は、どの ​rules.path​ 属性にも指定されていないパスでなければなりません。サポートされる形式: protocol://host:port/path​ (​path​ は省略可能で、​protocol​ は ​http​ または ​https​)。

spec.services

省略可能

空

指定されたサービスとルートのマップ。

spec.services[name].address

必須

なし

サービスアドレス (およびポート)。サポートされる形式: protocol://host:port​ (​protocol​ は ​http​ または ​https​)。

spec.services[name].routes

省略可能

空

この API インスタンスに設定されているサービスへのルートの配列。空である場合は、サービスへのデフォルトルートが確立され、すべてのトラフィックがルーティングされます。

spec.services[name].routes[#].config

省略可能

空

このルートの設定。空の場合は、空の ​destinationPath​ でデフォルトの設定が適用されます。

spec.services[name].routes[#].config.destinationPath

省略可能

空

アップストリームサービスに要求を転送するために先頭に追加するパス。たとえば、「destinationPath: /api/v1」と指定した場合、この API インスタンスへの要求で「/orders」のようなパスを指定すると、要求は「/api/v1/orders」のように上流にルーティングされます。

spec.services[name].routes[#].rules

省略可能

空

このルートのルールの配列。「ポリシーバインド」の「​spec.rules​」を参照してください。

spec.policies

省略可能

空

この API インスタンスに適用するポリシーの配列。

spec.policies[#].policyRef.name

必須

なし

ポリシー名。

spec.policies[#].policyRef.namespace

省略可能

metadata.namespace​ の値

ポリシーが定義される名前空間。提供ポリシーの場合、この項目の値は ​default​ である必要があります。

spec.policies[#].config

省略可能

空

ポリシーの設定。「ポリシーバインド」の「​spec.config​」を参照してください。​policies[#].config​ 項目で環境変数を使用するには、​ポリシーバインドの環境変数​を参照してください。

spec.policies[#].rules

省略可能

空

このポリシーを API インスタンスに適用するためのルールの配列。 「ポリシーバインド」の「​spec.rules​」を参照してください。
### [](#api-インスタンスの例)API インスタンスの例 次のリソースは、インスタンス識別子を記述するメタデータを使用して ​`ApiInstance`​ を指定しています。​`metadata.name`​ 値は、他のリソース (ポリシーバインドなど) の対象リファレンスとして使用されます。​`spec.services.routes.config.destinationPath`​ 値は、​`rules`​ の下に指定されているパスの先頭に ​`/v1/apps`​ を追加し、ベースパスのように機能します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: hello-flex-gateway-instance spec: address: http://0.0.0.0:8080 services: json: address: https://:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) config: destinationPath: /v1/apps #### [](#ポート共有)ポート共有 次の ​`ApiInstance`​ リソースは、2 つの異なる API インスタンスがポート 8080 でリスンする API ポート共有を示しています。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: httpbin-example spec: address: http://0.0.0.0:8080/api/httpbin/ services: upstream: address: https://:443 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-example spec: address: http://0.0.0.0:8080/api/json/ services: upstream: address: https://:443 両方のサービスはポート 8080 でリスンします。次に例を示します。 curl http://localhost:8080/api/httpbin/get -v curl http://localhost:8080/api/json/users/1 -v

ポートを共有する API のベースパスは競合しない必要があります。たとえば、次のパスの組み合わせは許可されません。

http://0.0.0.0:8080/cats
http://0.0.0.0:8080/cats/dogs

ポートには TLS が適用されます。そのため、ポートを共有するすべての API インスタンスに同じ TLS ポリシーが適用されます。
## [](#policy-binding)ポリシーバインド apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: namespace: spec: targetRef: name: namespace: policyRef: name: namespace: config: # optional policy configuration order: # optional policy read order rules: # optional policy rules - path: methods: host: headers: :
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

ポリシーバインドの識別子。

metadata.namespace

省略可能

default

spec.targetRef.name

必須

なし

ポリシーがバインドされる API インスタンスまたはアップストリームサービスの識別子。

spec.targetRef.namespace

省略可能

metadata.namespace​ の値

対象が定義される名前空間。

spec.policyRef.name

必須

なし

ポリシー名。利用可能なポリシーのリストを参照してください。

spec.policyRef.namespace

省略可能

metadata.namespace​ の値

ポリシーが定義される名前空間。提供ポリシーの場合、この項目の値は ​default​ である必要があります。

spec.config

省略可能

空

ポリシーの設定。この項目のコンテンツは、指定されたポリシーに依存します。​利用可能なポリシーのリスト​を参照してください。​config​ 項目で環境変数を使用するには、​ポリシーバインドの環境変数​を参照してください。

spec.order

省略可能

50

ポリシー実行チェーン全体におけるポリシーの読み取り順序。

spec.rules

省略可能

空

ポリシーが特定の要求に適用されるかどうかを決定するためのルールの配列。これらのルールは OR 形式でチェックされます。最初に True となったルールに従ってポリシーを要求に適合します。各ルールの属性は、AND 形式で適用されます。パスとホストが定義されている場合は、両方が一致しなければルールは True にはなりません。

spec.rules[#].path

省略可能

.*

要求のパスと一致する正規表現。

要求を上流にルーティングする場合は、この正規表現のキャプチャグループを使用して、パスを置き換えます。

「path: /api(/.*)」と指定すると、/api/orders というパスが指定された要求は、/orders として上流にルーティングされます。

複数のキャプチャグループを指定でき、その場合は、取得されたすべてのサブ文字列が連結されてパスが置き換えられます。

spec.rules[#].host

省略可能

.*

要求のホストと一致する正規表現。

spec.rules[#].methods

省略可能

.*

要求のメソッドと一致する正規表現。

spec.rules[#].headers

省略可能

空

ヘッダー名と要求に含まれる必要がある値の正規表現のマップ。

各エントリのキーは想定されるヘッダー名で、値はヘッダー値と一致する正規表現です。
### [](#ポリシーバインドの例)ポリシーバインドの例 次のリソースは、​`route`​ ポリシーを API インスタンスにバインドして、​`rules`​ で指定されたトラフィックを ​`Service`​ 設定スニペットで指定されたプロキシアドレスにルーティングします。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: hello-flex-gateway-route namespace: e-commerce spec: targetRef: name: hello-flex-gateway-instance policyRef: name: route namespace: default config: destinationRef: name: json namespace: e-commerce rules: - path: /api/json(/.\*) 次のリソースは、​`http-basic-authentication-flex`​ ポリシーを API インスタンスにバインドし、要求に ​`config.username`​ と ​`config.password`​ で定義されている基本ログイン情報を含めることを必須にします。このポリシーには読み取り順序に ​`2`​ の値が与えられます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: hello-flex-gateway-auth namespace: e-commerce spec: targetRef: name: hello-flex-gateway-instance namespace: e-commerce policyRef: name: http-basic-authentication-flex namespace: default config: username: chris password: admin order: 2 ### [](#environment-variables)ポリシーバインドの環境変数 ポリシーバインドリソースとインラインポリシーバインドの両方で ​`config`​ 項目の環境変数がサポートされます。使用可能な環境変数は環境に応じて異なります。 環境変数を参照するには、次のようにプレフィックス ​`$`​ を付けて環境変数を指定します。 \- policyRef: name: http-basic-authentication-flex config: username: $USERNAME password: $PASSWORD ## [](#サービス)サービス apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: namespace: spec: address:
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

サービス識別子。

metadata.namespace

省略可能

default

spec.address

必須

なし

プロトコル、ホスト、ポートを含むサービスアドレス URL。サポートされる形式: protocol://host:port​ (​protocol​ は ​http​ または ​https​)。
### [](#サービスの例)サービスの例 次のリソースは、サービス識別子を記述するメタデータを使用して ​`Service`​ を定義しています。​`metadata.namespace`​ 値は ​`ApiInstance`​ 設定で指定されている名前空間と一致します。​`spec.address`​ は、API 実装のアドレスです。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: json-example namespace: e-commerce spec: address: https://:443/ ## [](#設定)設定 `Configuration`​ エンティティを作成することによって目的のゲートウェイ状態を定義します。 `Configuration`​ エンティティは、Flex Gateway 自身のいくつかのランタイム設定 (​[ログ](#logging)​や​[共有ストレージ](#shared-storage)​など) を指定します。定義には以下が含まれます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: # logging configuration sharedStorage: # shared storage configuration
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

設定エンティティ。

metadata.namespace

省略可能

default

設定エンティティを特定するための名前空間値。

spec

必須

なし

ゲートウェイの特性を定義する設定オブジェクト。オブジェクトには ​logging​、​sharedStorage​、​tls​ があります。
### [](#logging)ログ記録 `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.0 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
#### [](#ログの例)ログの例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging spec: logging: outputs: - name: log-to-file type: file parameters: path: /var/log file: log.txt format: template template: | \[{date}\]\[{logger}\]\[{level}\]\[{kind}\] {message} runtimeLogs: logLevel: info outputs: - log-to-file accessLogs: outputs: - log-to-file ### [](#shared-storage)共有ストレージ `sharedStorage`​ オブジェクトは、共有ストレージのゲートウェイを設定します。本番ワークフローでは [Redis](https://redis.io/)​ (最小バージョン 4.0.0) を使用する必要がありますが、その定義は省略可能です。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。 必要に応じて、Redis とトランスポート層セキュリティ (TLS) を使用して、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: // REQUIRED username: // OPTIONAL password: // OPTIONAL db: // OPTIONAL tls: // OPTIONAL trustedCA: // OPTIONAL certificate: // OPTIONAL keyPassphrase // OPTIONAL key: // REQUIRED crt: // REQUIRED alpn: // OPTIONAL skipValidation: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

sharedStorage.redis.address

必須

なし

host:port​ 形式の Redis インスタンスアドレス。

sharedStorage.redis.username

省略可能

空

Redis ユーザー名

sharedStorage.redis.password

省略可能

空

Redis ユーザーパスワード

sharedStorage.redis.db

省略可能

0

使用する Redis データベース番号

sharedStorage.redis.tls

省略可能

空

Redis TLS 設定

sharedStorage.redis.tls.trustedCA

省略可能

なし

サーバー証明書を確認する時に使用するルート認証機関

sharedStorage.redis.tls.certificate

省略可能

なし

サーバーに提供するクライアント証明書

sharedStorage.redis.tls.keyPassphrase

省略可能

none

証明書鍵パスフレーズ。指定された場合、DEK-Info ヘッダーが含まれる非公開鍵形式を使用します。未指定の場合、非公開鍵は暗号化できません。

sharedStorage.redis.tls.certificate.key

必須

なし

証明書の非公開鍵部分

sharedStorage.redis.tls.certificate.crt

必須

なし

証明書の公開鍵部分

sharedStorage.redis.tls.skipValidation

省略可能

false

true の場合、サーバーによって提供されたすべての証明書が受け入れられます。

sharedStorage.redis.tls.minversion

省略可能

1.2

許容される最小 TLS バージョン

sharedStorage.redis.tls.maxversion

省略可能

1.3

許容される最大 TLS バージョン

sharedStorage.redis.tls.alpn

省略可能

空のリスト

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

sharedStorage.redis.tls.ciphers

省略可能

TLS/Redis では、以下を除いて ​TLS ポリシー​と同じ暗号化がサポートされます。

  • TLS_RSA_WITH_NULL_SHA

  • TLS_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
**Redis 共有ストレージ例** Redis ストレージサービスは、オブジェクトストアインターフェースと Redis バックエンド間のブリッジとして機能する、REST API オブジェクトストアの実装です。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` **Redis と TLS の共有ストレージ例** 必要に応じて、Redis と TLS を使用してデータを保護し、安全な通信を確保できます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` **ローカル共有ストレージの例** ローカルストレージサービスは、データをメモリに保存する REST API オブジェクトストアの実装です。Flex Gateway を停止または再起動すると、すべてのデータが失われます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: rtm-config namespace: sales spec: sharedStorage: local: enabled: true ``` ## [](#examples)例 ### [](#インライン設定の例)インライン設定の例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: api-example spec: address: http://0.0.0.0:8080 services: api-example: address: https://:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) config: destinationPath: /v1/apps policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#リソースベース設定の例)リソースベース設定の例 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: ingress-http spec: address: http://0.0.0.0:8080 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: json spec: address: https://:443/ --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-route spec: targetRef: name: ingress-http policyRef: name: route config: destinationRef: name: json rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-authentication spec: targetRef: name: ingress-http policyRef: name: http-basic-authentication-flex config: username: chris password: admin # 宣言型設定リファレンスガイド ローカルモードで実行される Anypoint Flex Gateway は、2 つの設定モデルをサポートします。 - Kubernetes で一般的なリソースベースモデルは、詳細な定義に適しています。各リソースは、設定の ​`kind`​ の値が次のいずれかになります。 - `ApiInstance` - `Service` - `PolicyBinding` - `Configuration` - インラインモデルは簡潔な定義に適していますが、汎用性が低くなります (たとえば、自動ポリシーはリソースベース定義でしか適用できません)。 インライン定義では、設定の ​`kind`​ の値は ​`ApiInstance`​ のみとなり、この下でサービスとポリシーの両方を定義します。 ![API インスタンス、サービス、ポリシーバインドの構造の図](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-configuration-models.png) それぞれの例は​[「例」](#examples)​セクションを参照してください。 このリファレンスガイドでは、リソースベース設定またはインライン設定に適用可能なリソースについて説明します。 ## [](#api-instance)API インスタンス apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: namespace: # optional namespace name spec: address: services: # optional map of upstream services : address: routes: # optional array of routes to service - config: # optional route configuration destinationPath: rules: # optional route rules policies: # optional array of policies - policyRef: name: namespace: config: # optional policy configuration rules: # optional policy rules
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

他のリソース (ポリシーバインドなど) の対象リファレンスとして使用される API インスタンス識別子。

metadata.namespace

省略可能

default

spec.address

必須

なし

プロトコル、ホスト、ポート、パス (省略可能) を含むプロキシアドレス URL。ベースパスを指定する場合は、どの ​rules.path​ 属性にも指定されていないパスでなければなりません。サポートされる形式: protocol://host:port/path​ (​path​ は省略可能で、​protocol​ は ​http​ または ​https​)。

spec.services

省略可能

空

指定されたサービスとルートのマップ。

spec.services[name].address

必須

なし

サービスアドレス (およびポート)。サポートされる形式: protocol://host:port​ (​protocol​ は ​http​ または ​https​)。

spec.services[name].routes

省略可能

空

この API インスタンスに設定されているサービスへのルートの配列。空である場合は、サービスへのデフォルトルートが確立され、すべてのトラフィックがルーティングされます。

spec.services[name].routes[#].config

省略可能

空

このルートの設定。空の場合は、空の ​destinationPath​ でデフォルトの設定が適用されます。

spec.services[name].routes[#].config.destinationPath

省略可能

空

アップストリームサービスに要求を転送するために先頭に追加するパス。たとえば、「destinationPath: /api/v1」と指定した場合、この API インスタンスへの要求で「/orders」のようなパスを指定すると、要求は「/api/v1/orders」のように上流にルーティングされます。

spec.services[name].routes[#].rules

省略可能

空

このルートのルールの配列。「ポリシーバインド」の「​spec.rules​」を参照してください。

spec.policies

省略可能

空

この API インスタンスに適用するポリシーの配列。

spec.policies[#].policyRef.name

必須

なし

ポリシー名。

spec.policies[#].policyRef.namespace

省略可能

metadata.namespace​ の値

ポリシーが定義される名前空間。提供ポリシーの場合、この項目の値は ​default​ である必要があります。

spec.policies[#].config

省略可能

空

ポリシーの設定。「ポリシーバインド」の「​spec.config​」を参照してください。​policies[#].config​ 項目で環境変数を使用するには、​ポリシーバインドの環境変数​を参照してください。

spec.policies[#].rules

省略可能

空

このポリシーを API インスタンスに適用するためのルールの配列。 「ポリシーバインド」の「​spec.rules​」を参照してください。
### [](#api-インスタンスの例)API インスタンスの例 次のリソースは、インスタンス識別子を記述するメタデータを使用して ​`ApiInstance`​ を指定しています。​`metadata.name`​ 値は、他のリソース (ポリシーバインドなど) の対象リファレンスとして使用されます。​`spec.services.routes.config.destinationPath`​ 値は、​`rules`​ の下に指定されているパスの先頭に ​`/v1/apps`​ を追加し、ベースパスのように機能します。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: hello-flex-gateway-instance spec: address: http://0.0.0.0:8080 services: json: address: https://:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) config: destinationPath: /v1/apps #### [](#ポート共有)ポート共有 次の ​`ApiInstance`​ リソースは、2 つの異なる API インスタンスがポート 8080 でリスンする API ポート共有を示しています。 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: httpbin-example spec: address: http://0.0.0.0:8080/api/httpbin/ services: upstream: address: https://:443 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: json-example spec: address: http://0.0.0.0:8080/api/json/ services: upstream: address: https://:443 両方のサービスはポート 8080 でリスンします。次に例を示します。 curl http://localhost:8080/api/httpbin/get -v curl http://localhost:8080/api/json/users/1 -v

ポートを共有する API のベースパスは競合しない必要があります。たとえば、次のパスの組み合わせは許可されません。

http://0.0.0.0:8080/cats
http://0.0.0.0:8080/cats/dogs

ポートには TLS が適用されます。そのため、ポートを共有するすべての API インスタンスに同じ TLS ポリシーが適用されます。
## [](#policy-binding)ポリシーバインド apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: namespace: spec: targetRef: name: namespace: policyRef: name: namespace: config: # optional policy configuration order: # optional policy read order rules: # optional policy rules - path: methods: host: headers: :
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

ポリシーバインドの識別子。

metadata.namespace

省略可能

default

spec.targetRef.name

必須

なし

ポリシーがバインドされる API インスタンスまたはアップストリームサービスの識別子。

spec.targetRef.namespace

省略可能

metadata.namespace​ の値

対象が定義される名前空間。

spec.policyRef.name

必須

なし

ポリシー名。利用可能なポリシーのリストを参照してください。

spec.policyRef.namespace

省略可能

metadata.namespace​ の値

ポリシーが定義される名前空間。提供ポリシーの場合、この項目の値は ​default​ である必要があります。

spec.config

省略可能

空

ポリシーの設定。この項目のコンテンツは、指定されたポリシーに依存します。利用可能なポリシーのリストを参照してください。​config​ 項目で環境変数を使用するには、​ポリシーバインドの環境変数​を参照してください。

spec.order

省略可能

50

ポリシー実行チェーン全体におけるポリシーの読み取り順序。

spec.rules

省略可能

空

ポリシーが特定の要求に適用されるかどうかを決定するためのルールの配列。これらのルールは OR 形式でチェックされます。最初に True となったルールに従ってポリシーを要求に適合します。各ルールの属性は、AND 形式で適用されます。パスとホストが定義されている場合は、両方が一致しなければルールは True にはなりません。

spec.rules[#].path

省略可能

.*

要求のパスと一致する正規表現。

要求を上流にルーティングする場合は、この正規表現のキャプチャグループを使用して、パスを置き換えます。

「path: /api(/.*)」と指定すると、/api/orders というパスが指定された要求は、/orders として上流にルーティングされます。

複数のキャプチャグループを指定でき、その場合は、取得されたすべてのサブ文字列が連結されてパスが置き換えられます。

spec.rules[#].host

省略可能

.*

要求のホストと一致する正規表現。

spec.rules[#].methods

省略可能

.*

要求のメソッドと一致する正規表現。

spec.rules[#].headers

省略可能

空

ヘッダー名と要求に含まれる必要がある値の正規表現のマップ。

各エントリのキーは想定されるヘッダー名で、値はヘッダー値と一致する正規表現です。
### [](#ポリシーバインドの例)ポリシーバインドの例 次のリソースは、​`route`​ ポリシーを API インスタンスにバインドして、​`rules`​ で指定されたトラフィックを ​`Service`​ 設定スニペットで指定されたプロキシアドレスにルーティングします。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: hello-flex-gateway-route namespace: e-commerce spec: targetRef: name: hello-flex-gateway-instance policyRef: name: route namespace: default config: destinationRef: name: json namespace: e-commerce rules: - path: /api/json(/.\*) 次のリソースは、​`http-basic-authentication-flex`​ ポリシーを API インスタンスにバインドし、要求に ​`config.username`​ と ​`config.password`​ で定義されている基本ログイン情報を含めることを必須にします。このポリシーには読み取り順序に ​`2`​ の値が与えられます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: hello-flex-gateway-auth namespace: e-commerce spec: targetRef: name: hello-flex-gateway-instance namespace: e-commerce policyRef: name: http-basic-authentication-flex namespace: default config: username: chris password: admin order: 2 ### [](#environment-variables)ポリシーバインドの環境変数 ポリシーバインドリソースとインラインポリシーバインドの両方で ​`config`​ 項目の環境変数がサポートされます。使用可能な環境変数は環境に応じて異なります。 環境変数を参照するには、次のようにプレフィックス ​`$`​ を付けて環境変数を指定します。 \- policyRef: name: http-basic-authentication-flex config: username: $USERNAME password: $PASSWORD ## [](#サービス)サービス apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: namespace: spec: address:
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

サービス識別子。

metadata.namespace

省略可能

default

spec.address

必須

なし

プロトコル、ホスト、ポートを含むサービスアドレス URL。サポートされる形式: protocol://host:port​ (​protocol​ は ​http​ または ​https​)。
### [](#サービスの例)サービスの例 次のリソースは、サービス識別子を記述するメタデータを使用して ​`Service`​ を定義しています。​`metadata.namespace`​ 値は ​`ApiInstance`​ 設定で指定されている名前空間と一致します。​`spec.address`​ は、API 実装のアドレスです。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: json-example namespace: e-commerce spec: address: https://:443/ ## [](#設定)設定 `Configuration`​ エンティティを作成することによって目的のゲートウェイ状態を定義します。 `Configuration`​ エンティティは、Flex Gateway 自身のいくつかのランタイム設定 (​[ログ](#logging)​や​[共有ストレージ](#shared-storage)​など) を指定します。定義には以下が含まれます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: # logging configuration sharedStorage: # shared storage configuration
パラメーター 必須または省略可能 デフォルト値 説明

metadata.name

必須

なし

設定エンティティ。

metadata.namespace

省略可能

default

設定エンティティを特定するための名前空間値。

spec

必須

なし

ゲートウェイの特性を定義する設定オブジェクト。オブジェクトには ​logging​、​sharedStorage​、​tls​ があります。
### [](#logging)ログ記録 `logging`​ オブジェクトは、メッセージログポリシーを介してランタイムおよびアクセスログの配信を設定します。ログは、サポートされている Fluent Bit v3.0 出力に配信されます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: namespace: spec: logging: outputs: - name: type: parameters: : runtimeLogs: logLevel: outputs: accessLogs: outputs: ```
パラメーター 必須または省略可能 デフォルト値 説明

logging.outputs[#].name

必須

なし

後でランタイムとアクセスログの設定で参照する、この出力の名前。

logging.outputs[#].type

必須

なし

Fluent Bit でサポートされる出力種別。Fluent Bit 出力種別については、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.outputs[#].parameters

必須

なし

特定の Fluent Bit 出力種別のパラメーターのマップ。Fluent Bit 出力種別のパラメーターについては、対象の Fluent Bit バージョンの Fluent Bit のドキュメント​を参照してください。

logging.accessLogs.outputs

省略可能

空

アクセスログをリダイレクトする出力名のリスト。

logging.runtimeLogs.logLevel

省略可能

info

ログの詳細を指定するパラメーター。サポートされる ​logLevel​ の種別は冗長レベルの高い順にリストされており、​debug​、​info​、​warn​、​error​、​fatal​ です。

logging.runtimeLogs.outputs

省略可能

空

ランタイムログをリダイレクトする出力名のリスト。
値を空白のままにすると、デフォルト値が設定に適用されます。 上記のパラメーターに加えて、Flex Gateway にはログ出力用の変数が用意されています。設定されている場合、変数はログ内のそれぞれの出力の 1 つとして表示されます。
変数 説明 出力

date

ログに記録されたイベントの日時

特定の時刻 (例: 17/11/2022-09:48:27AM​)

logger

ログに記録されたイベントが発生した Flex Gateway サービス

flex-gateway-agent​、​flex-gateway-envoy​、または ​flex-gateway-fluent

level

ログに記録されたイベントの ​Loglevel

debug​、​info​、​warn​、​error​、または ​fatal

kind

ログ種別

runtimeLog​ または ​accessLog
#### [](#ログの例)ログの例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: logging spec: logging: outputs: - name: log-to-file type: file parameters: path: /var/log file: log.txt format: template template: | \[{date}\]\[{logger}\]\[{level}\]\[{kind}\] {message} runtimeLogs: logLevel: info outputs: - log-to-file accessLogs: outputs: - log-to-file ### [](#shared-storage)共有ストレージ `sharedStorage`​ オブジェクトは、共有ストレージのゲートウェイを設定します。本番ワークフローでは [Redis](https://redis.io/)​ (最小バージョン 4.0.0) を使用する必要がありますが、その定義は省略可能です。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。 必要に応じて、Redis とトランスポート層セキュリティ (TLS) を使用して、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。 apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: // REQUIRED username: // OPTIONAL password: // OPTIONAL db: // OPTIONAL tls: // OPTIONAL trustedCA: // OPTIONAL certificate: // OPTIONAL keyPassphrase // OPTIONAL key: // REQUIRED crt: // REQUIRED alpn: // OPTIONAL skipValidation: // OPTIONAL minversion: // OPTIONAL maxversion: // OPTIONAL ciphers: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

sharedStorage.redis.address

必須

なし

host:port​ 形式の Redis インスタンスアドレス。

sharedStorage.redis.username

省略可能

空

Redis ユーザー名

sharedStorage.redis.password

省略可能

空

Redis ユーザーパスワード

sharedStorage.redis.db

省略可能

0

使用する Redis データベース番号

sharedStorage.redis.tls

省略可能

空

Redis TLS 設定

sharedStorage.redis.tls.trustedCA

省略可能

なし

サーバー証明書を確認する時に使用するルート認証機関

sharedStorage.redis.tls.certificate

省略可能

なし

サーバーに提供するクライアント証明書

sharedStorage.redis.tls.keyPassphrase

省略可能

none

証明書鍵パスフレーズ。指定された場合、DEK-Info ヘッダーが含まれる非公開鍵形式を使用します。未指定の場合、非公開鍵は暗号化できません。

sharedStorage.redis.tls.certificate.key

必須

なし

証明書の非公開鍵部分

sharedStorage.redis.tls.certificate.crt

必須

なし

証明書の公開鍵部分

sharedStorage.redis.tls.skipValidation

省略可能

false

true の場合、サーバーによって提供されたすべての証明書が受け入れられます。

sharedStorage.redis.tls.minversion

省略可能

1.2

許容される最小 TLS バージョン

sharedStorage.redis.tls.maxversion

省略可能

1.3

許容される最大 TLS バージョン

sharedStorage.redis.tls.alpn

省略可能

空のリスト

サポートされているアプリケーションレベルプロトコルの優先リスト (h2、http/1.1 など)。

sharedStorage.redis.tls.ciphers

省略可能

TLS/Redis では、以下を除いて ​TLS ポリシー​と同じ暗号化がサポートされます。

  • TLS_RSA_WITH_NULL_SHA

  • TLS_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
**Redis 共有ストレージ例** Redis ストレージサービスは、オブジェクトストアインターフェースと Redis バックエンド間のブリッジとして機能する、REST API オブジェクトストアの実装です。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` **Redis と TLS の共有ストレージ例** 必要に応じて、Redis と TLS を使用してデータを保護し、安全な通信を確保できます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` **ローカル共有ストレージの例** ローカルストレージサービスは、データをメモリに保存する REST API オブジェクトストアの実装です。Flex Gateway を停止または再起動すると、すべてのデータが失われます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: rtm-config namespace: sales spec: sharedStorage: local: enabled: true ``` ## [](#examples)例 ### [](#インライン設定の例)インライン設定の例 apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: api-example spec: address: http://0.0.0.0:8080 services: api-example: address: https://:443/ routes: - rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) config: destinationPath: /v1/apps policies: - policyRef: name: http-basic-authentication-flex config: username: chris password: admin ### [](#リソースベース設定の例)リソースベース設定の例 \--- apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: ingress-http spec: address: http://0.0.0.0:8080 --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: json spec: address: https://:443/ --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-route spec: targetRef: name: ingress-http policyRef: name: route config: destinationRef: name: json rules: - path: /api(/users/.\*) - path: /api(/comments/.\*) --- apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-http-authentication spec: targetRef: name: ingress-http policyRef: name: http-basic-authentication-flex config: username: chris password: admin # 応答タイムアウトポリシー

ポリシー名

応答タイムアウト

Summary (概要)

Flex Gateway がアップストリームサービスからの応答を待機する最大期間を設定する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

504 - アップストリーム要求タイムアウト
## [](#概要)概要 応答タイムアウトポリシーでは、Flex Gateway がアップストリームサービスからの応答を待機する最大期間を設定できます。タイムアウトの時間は Flex Gateway によって最後の要求が送信された時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 15 秒の応答タイムアウトが設定されています。このポリシーを適用すると、デフォルトのタイムアウトを上書きします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: response-timeout-flex config: timeout: number // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

timeout

必須

15

Flex Gateway が応答を待機する秒数。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: response-timeout-flex config: timeout: 3 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Response timeout (応答タイムアウト)

Flex Gateway が応答を待機する秒数。

はい
# 応答タイムアウトポリシー

ポリシー名

応答タイムアウト

Summary (概要)

Flex Gateway がアップストリームサービスからの応答を待機する最大期間を設定する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.9.0

返される状況コード

504 - アップストリーム要求タイムアウト
## [](#概要)概要 応答タイムアウトポリシーでは、Flex Gateway がアップストリームサービスからの応答を待機する最大期間を設定できます。タイムアウトの時間は Flex Gateway によって最後の要求が送信された時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 15 秒の応答タイムアウトが設定されています。このポリシーを適用すると、デフォルトのタイムアウトを上書きします。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#local-mode)Flex Gateway のローカルモード ローカルモードでは、宣言型の設定ファイルを使用してポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。 \- policyRef: name: response-timeout-flex config: timeout: number // REQUIRED
パラメーター 必須または省略可能 デフォルト値 説明

timeout

必須

15

Flex Gateway が応答を待機する秒数。
#### [](#リソースの設定例)リソースの設定例 \- policyRef: name: response-timeout-flex config: timeout: 3 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Response timeout (応答タイムアウト)

Flex Gateway が応答を待機する秒数。

はい
# 接続モードでトークンを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する Anypoint Platform 環境の登録​**トークン** Runtime Manager に移動して、左側のナビゲーションにある ​**\[Flex Gateways (Flex Gateway)\]**​ を選択し、​**\[Add Gateway (ゲートウェイを追加)\]**​ をクリックして、登録トークンを使用したコマンドブロックを含む命令セットを生成します。 ## [](#linux)トークンを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)トークンを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)トークンを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)トークンを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)トークンを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)トークンを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) # 接続モードでトークンを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する Anypoint Platform 環境の登録​**トークン** Runtime Manager に移動して、左側のナビゲーションにある ​**\[Flex Gateway\]**​ を選択し、​**\[Add Gateway (ゲートウェイを追加)\]**​ をクリックして、登録トークンを使用したコマンドブロックを含む命令セットを生成します。 ## [](#linux)トークンを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)トークンを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)トークンを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)トークンを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)トークンを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)トークンを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) # 接続モードでトークンを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する Anypoint Platform 環境の登録​**トークン** Runtime Manager に移動して、左側のナビゲーションにある ​**\[Flex Gateways (Flex Gateway)\]**​ を選択し、​**\[Add Gateway (ゲートウェイを追加)\]**​ をクリックして、登録トークンを使用したコマンドブロックを含む命令セットを生成します。 ## [](#linux)トークンを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 ### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)トークンを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)トークンを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)トークンを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-3)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)トークンを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)トークンを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--token`​ = Anypoint Platform の環境の登録トークン - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --token= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) # 接続モードでの API の保護および制御 接続モードで実行されている Flex Gateway では、​**API Manager**​ を使用して API ポリシーを適用します。詳細は、[ポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-apply)を参照してください。 また、基本認証ポリシーを適用するには、[Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started)を参照してください。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) # 接続モードでの Flex Gateway API のパブリッシュ 接続モードで実行されている Flex Gateway では、​**API Manager**​ を使用して単独のアップストリームサービスが使用されている API インスタンスと複数のアップストリームサービスが使用されている API インスタンスの両方をパブリッシュします。 詳細は、[Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex)を参照してください。 また、[Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started)に従ってシンプルな API をパブリッシュすることもできます。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.8/) # 接続モードでの Flex Gateway の TLS コンテキストの設定 Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。​[シークレットグループを作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task)​したら、TLS コンテキストまたは相互認証 TLS (mTLS) コンテキストを追加し、その TLS コンテキストを API Manager で API インスタンスに適用して、インバウンドトラフィックとアウトバウンドトラフィックを暗号化できます。 TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。 Flex Gateway では以下がサポートされます。 - クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる) - API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる) - インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS) デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 Flex Gateway は、ポートレベルでインバウンド TLS を実装します。つまり、API インスタンスに適用されるインバウンド TLS コンテキストは、同じポートを共有する他のすべてのインスタンスにも適用されます。TLS コンテキストがポート間で共有される方法についての詳細は、​[「共有ポートに適用されるインバウンド TLS コンテキスト」](#tls-context-applied-to-shared-ports)​を参照してください。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを選択できます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#始める前に)始める前に Flex Gateway 接続モードの TLS コンテキストを設定する前に、次のタスクを完了してください。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) - 次の権限が有効になっていることの確認 - シークレットマネージャーの​_「Grant access to secrets (シークレットへのアクセス権の付与)」_ - API Manager の​_「Deploy API Proxies (API プロキシのデプロイ)」_ これらの権限は、Anypoint Platform 管理者がアクセス管理で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 - [シークレットグループの作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) シークレットグループを追加する場合、​[「TLS 設定オプション」](#tls-configuration-options)​を参照してください。 目的の設定に応じて、次のいずれかを実行します。 - [キーストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-keystore) - [トラストストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-truststore)
キーストアまたはトラストストアには、Privacy Enhanced Mail (PEM) 種別が必要です。
## [](#tls-configuration-options)TLS 設定オプション インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。必要な設定に応じて、異なる証明書ファイルをシークレットグループに追加し、異なる TLS コンテキスト設定オプションを選択する必要があります。 [「TLS コンテキストを追加する」](#add-a-tls-context)​ステップで必要な TLS コンテキスト設定については、次の相互参照テーブルを参照してください。
パラメーター インバウンド TLS インバウンド mTLS アウトバウンド TLS アウトバウンド mTLS

Keystore (キーストア)

必須

必須

未使用

必須

Truststore (トラストストア)

未使用

必須

[Skip server certificate validation (サーバー証明書の検証をスキップ)] が選択されていない場合は必須

アップストリーム証明書を検証する場合は必須

Validate Client certificate (クライアント証明書を検証)

未選択

選択

未使用

未使用

Skip server certificate validation (サーバー証明書の検証をスキップ)

未使用

未使用

両方

未選択
設定のパラメーターが「未使用」の場合、その状況は設定に影響しないことを意味します。 設定を簡素化するために、API インスタンスの異なるトラフィック方向に対して異なる TLS コンテキストを作成できます。ただし、同じ TLS コンテキストを使用して異なるトラフィック方向をサポートすることもできますが、同じコンテキストを使用して同じ方向の TLS と mTLS をサポートすることはできません。異なる方向に同じ TLS コンテキストを使用する場合は、両方向に必要なパラメーターを含めてください。 ## [](#add-a-tls-context)Flex Gateway の TLS コンテキストを追加する TLS コンテキストをシークレットグループに追加するには、名前、対象、バージョン、キーストアまたはトラストストアを指定する必要があります。必要に応じて、コンテキストの有効期限と ALPN プロトコルを追加し、インバウンド設定とアウトバウンド設定を定義できます。

現在 API インスタンスに適用されている TLS コンテキストを含むシークレットグループを編集する場合は、API インスタンスを再デプロイして変更を適用する必要があります。変更の影響を受けるすべてのインスタンスを個別に再デプロイする必要があります。API インスタンスを再デプロイするには、​「API インスタンスを再デプロイする」​を参照してください。
TLS コンテキストを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[Secrets Manager (シークレットマネージャー)\]**​ に移動します。 2. シークレットグループがダウンロード可能であることを確認します。これにより、TLS コンテキストを API インスタンスに適用できるようになります。 シークレットグループがダウンロード可能であることを確認する手順は、次のとおりです。 1. シークレットグループの名前の横にある鉛筆アイコンをクリックします。 2. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されている場合は、​**\[Cancel (キャンセル)\]**​ をクリックします。 3. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されていない場合は、それを選択して ​**\[Save (保存)\]**​ をクリックします。 3. **\[Secret Groups (シークレットグループ)\]**​ リストビューで、シークレットグループの ​**\[Edit (編集)\]**​ ボタンをクリックして TLS コンテキストを追加します。 4. 左側のメニューで ​**\[TLS Context (TLS コンテキスト)\]**​ を選択し、​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 5. \[Create TLS Context (TLS コンテキストを作成)\] 画面で、必要な情報を追加します。 - **Name (名前)**​ TLS コンテキストの名前を入力します。 - **Target (対象)**​ **\[Flex Gateway\]**​ を選択し、TLS コンテキストを Flex Gateway API の SSL 検証として使用します。 - **\[Min TLS Version (最小 TLS バージョン)\]**​ と ​**\[Max TLS Version (最大 TLS バージョン)\]**​ さまざまな TLS バージョンをサポートするように選択したり、最小と最大の両方に同じバージョンを選択することで単一バージョンをサポートするように選択したりできます。 - **Keystore (キーストア)**​ 設定に必要な場合は、TLS コンテキストに保存するキーストアをドロップダウンリストから選択します。PEM 種別のキーストアのみが表示されます。キーストアには、Flex Gateway がインバウンド TLS とアウトバウンド TLS の両方に対してリモートパーティに提示する証明書が含まれます。

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
- **Truststore (トラストストア)**​ 設定に必要な場合は、クライアントによって信頼される証明書を保存するトラストストアをドロップダウンリストから選択します。PEM 種別のトラストストアのみが表示されます。トラストストアには、Flex がインバウンド TLS とアウトバウンド TLS の両方のリモートパーティ証明書を検証するために使用する CA パスが含まれます。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。
- **Expiration Date (有効期限 (日))**​ 必要に応じて、TLS コンテキストの有効期限を入力します。 - **ALPN Protocols (ALPN プロトコル)**​ デフォルトでは、​**H2 - HTTP/1.1**​ が ALPN プロトコルとして選択されます。異なるプロトコルをサポートするには、この値を変更します。 - **Inbound Settings (インバウンド設定)**​ インバウンドトラフィックで mTLS をサポートする場合は、​**\[Validate Client certificate (クライアント証明書を検証)\]**​ を選択します。 - **Outbound Settings (アウトバウンド設定)**​ アウトバウンドトラフィックで mTLS をサポートしない場合は、​**\[Skip server certificate validation (サーバー証明書の検証をスキップ)\]**​ を選択します。 6. TLS コンテキストの暗号化サポートをカスタマイズする場合は、​[暗号化を選択します](#select-ciphers)​。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 7. **\[Save (保存)\]**​ をクリックします。 ## [](#tls-コンテキストを-api-に適用する)TLS コンテキストを API に適用する 新しいインスタンスの作成時に、または既存のインスタンスを編集して、TLS コンテキストを API インスタンスに適用できます。 API インスタンス設定にはダウンストリーム設定とアップストリーム設定の 2 つの部分があります。インバウンド TLS コンテキストはダウンストリーム設定オプションで、アウトバウンド TLS コンテキストはアップストリーム設定オプションです。新しい API インスタンスを追加する場合は、ダウンストリーム設定とアップストリーム設定は別々のページに配置されます。API インスタンスを編集する場合は、ダウンストリーム設定オプションとアップストリーム設定オプションは同じページに表示されますが、別のセクションに配置されます。 それぞれのオプションについては、関連するチュートリアルを参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [API インスタンスの編集](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task) TLS コンテキストを適用する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 次のいずれかへ移動します。 - 新しい API インスタンスを追加する場合は、アップストリームまたはダウンストリーム設定ページ。 - 既存の API インスタンスを編集する場合は、​**\[Settings (設定)\]**​ ページ。 3. インバウンド TLS コンテキストを設定する場合は、​**\[Protocol (プロトコル)\]**​ 設定項目の ​**\[HTTPS\]**​ を選択します。 4. **\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. **\[Secret Group (シークレットグループ)\]**​ を選択します。 2. **\[TLS Context (TLS コンテキスト)\]**​ を選択します。 3. **\[Ok\]**​ をクリックします。 5. API インスタンスの作成を完了するか、設定の編集を保存します。 ## [](#tls-context-applied-to-shared-ports)共有ポートに適用されるインバウンド TLS コンテキスト インバウンド TLS コンテキストを適用するにはポートに API インスタンスが必要ですが、インバウンド TLS コンテキストは API インスタンスではなくポートに適用されます。 ポートを他のインスタンスと共有する API インスタンスにインバウンド TLS コンテキストを適用すると、ポートを共有するすべてのインスタンスにインバウンド TLS コンテキストが適用されます。 ポートを共有する API インスタンスのインバウンド TLS コンテキストを適用、編集、または削除すると、ポートを共有するインスタンスのリストと共に警告が API Manager に表示されます。その後、リストされた API インスタンスのインバウンド TLS コンテキストの上書きを選択できます。ポートを共有する API インスタンスの TLS コンテキストを上書きすると、インバウンド TLS コンテキストがインスタンスに適用され、インスタンスが再デプロイされます。 デプロイされた API インスタンスのインバウンド TLS コンテキストを上書きすると、インスタンスが再デプロイされます。再デプロイすると、API インスタンスで短期間のダウンタイムが発生します。 以前にポートおよびインバウンド TLS コンテキストを他のインスタンスと共有していた API インスタンスのポートを編集した場合、インバウンド TLS コンテキストは以前のポートのインスタンスに適用されたままになります。 ## [](#redeploy-api-instance)シークレットグループを編集して API インスタンスを再デプロイする シークレットグループを編集するには、​[「シークレットグループを編集する」](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#edit-a-secret-group)​を参照してください。 現在 API インスタンスに適用されているシークレットグループを編集し、その変更を API インスタンスに適用する場合は、変更が影響するすべてのインスタンスを個別に再デプロイする必要があります。 API インスタンスを再デプロイする手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 再デプロイする API インスタンスの名前をクリックします。 3. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Apply (保存して適用)\]**​ をクリックします。 ## [](#select-ciphers)暗号化の選択 TLS コンテキストを設定すると、シークレットマネージャーによって、選択した TLS バージョンに基づいてデフォルトの暗号化が適用されます。デフォルトに加えて、選択した TLS バージョンで使用する他の暗号化を選択できます。各 TLS コンテキストに複数の暗号化を含めることができます。 暗号化を選択する手順は、次のとおりです。 1. **\[Ciphers (暗号化)\]**​ をクリックして使用可能な暗号化を表示します。 2. 暗号化を選択します。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 3. **\[Save (保存)\]**​ をクリックします。 ## [](#flex-gateway-での-tls-暗号化のサポート)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合は、TLS 1.3 のデフォルトの暗号化をサポートする必要があります。 TLS 1.2 をサポートする場合は、TLS 1.2 のデフォルトの暗号化が選択されます。ただし、TLS 1.3 とは異なり、さまざまな TLS 1.2 暗号化をカスタマイズできます。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートすることを選択した場合は、サポートする暗号化を選択する必要があります。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンが API アップストリームでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS AES 128 GCM SHA256

1.3

はい

セキュア

TLS AES 256 GCM SHA384

1.3

はい

セキュア

TLS CHACHA20 POLY1305 SHA256

1.3

はい

セキュア

TLS ECDHE ECDSA WITH AES 128 GCM SHA256

1.2

はい

推奨

TLS ECDHE ECDSA WITH AES 256 GCM SHA384

1.2

はい

推奨

TLS ECDHE ECDSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

推奨

TLS ECDHE PSK WITH CHACHA20 POLY1305 SHA256

1.2

いいえ

推奨

TLS ECDHE RSA WITH AES 128 GCM SHA256

1.2

はい

セキュア

TLS ECDHE RSA WITH AES 256 GCM SHA384

1.2

はい

セキュア

TLS ECDHE RSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

セキュア

TLS RSA WITH AES 128 GCM SHA256

1.2

いいえ

脆弱

TLS RSA WITH AES 256 GCM SHA384

1.2

いいえ

脆弱

TLS RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH 3DES EDE CBC SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config) - [Transport Layer Security ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) # 接続モードでの Flex Gateway の TLS コンテキストの設定 Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。​[シークレットグループを作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task)​したら、TLS コンテキストまたは相互認証 TLS (mTLS) コンテキストを追加し、その TLS コンテキストを API Manager で API インスタンスに適用して、インバウンドトラフィックとアウトバウンドトラフィックを暗号化できます。 TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。 Flex Gateway では以下がサポートされます。 - クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる) - API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる) - インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS) デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 Flex Gateway は、ポートレベルでインバウンド TLS を実装します。つまり、API インスタンスに適用されるインバウンド TLS コンテキストは、同じポートを共有する他のすべてのインスタンスにも適用されます。TLS コンテキストがポート間で共有される方法についての詳細は、​[「共有ポートに適用されるインバウンド TLS コンテキスト」](#tls-context-applied-to-shared-ports)​を参照してください。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを選択できます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#始める前に)始める前に Flex Gateway 接続モードの TLS コンテキストを設定する前に、次のタスクを完了してください。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - 次の権限が有効になっていることの確認 - シークレットマネージャーの​_「Grant access to secrets (シークレットへのアクセス権の付与)」_ - API Manager の​_「Deploy API Proxies (API プロキシのデプロイ)」_ これらの権限は、Anypoint Platform 管理者がアクセス管理で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 - [シークレットグループの作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) シークレットグループを追加する場合、​[「TLS 設定オプション」](#tls-configuration-options)​を参照してください。 目的の設定に応じて、次のいずれかを実行します。 - [キーストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-keystore) - [トラストストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-truststore)
キーストアまたはトラストストアには、Privacy Enhanced Mail (PEM) 種別が必要です。
## [](#tls-configuration-options)TLS 設定オプション インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。必要な設定に応じて、異なる証明書ファイルをシークレットグループに追加し、異なる TLS コンテキスト設定オプションを選択する必要があります。 [「TLS コンテキストを追加する」](#add-a-tls-context)​ステップで必要な TLS コンテキスト設定については、次の相互参照テーブルを参照してください。
パラメーター インバウンド TLS インバウンド mTLS アウトバウンド TLS アウトバウンド mTLS

Keystore (キーストア)

必須

必須

未使用

必須

Truststore (トラストストア)

未使用

必須

[Skip server certificate validation (サーバー証明書の検証をスキップ)] が選択されていない場合は必須

アップストリーム証明書を検証する場合は必須

Validate Client certificate (クライアント証明書を検証)

未選択

選択

未使用

未使用

Skip server certificate validation (サーバー証明書の検証をスキップ)

未使用

未使用

両方

未選択
設定のパラメーターが「未使用」の場合、その状況は設定に影響しないことを意味します。 設定を簡素化するために、API インスタンスの異なるトラフィック方向に対して異なる TLS コンテキストを作成できます。ただし、同じ TLS コンテキストを使用して異なるトラフィック方向をサポートすることもできますが、同じコンテキストを使用して同じ方向の TLS と mTLS をサポートすることはできません。異なる方向に同じ TLS コンテキストを使用する場合は、両方向に必要なパラメーターを含めてください。 ## [](#add-a-tls-context)Flex Gateway の TLS コンテキストを追加する TLS コンテキストをシークレットグループに追加するには、名前、対象、バージョン、キーストアまたはトラストストアを指定する必要があります。必要に応じて、コンテキストの有効期限と ALPN プロトコルを追加し、インバウンド設定とアウトバウンド設定を定義できます。

現在 API インスタンスに適用されている TLS コンテキストを含むシークレットグループを編集する場合は、API インスタンスを再デプロイして変更を適用する必要があります。変更の影響を受けるすべてのインスタンスを個別に再デプロイする必要があります。API インスタンスを再デプロイするには、​「API インスタンスを再デプロイする」​を参照してください。
TLS コンテキストを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[Secrets Manager (シークレットマネージャー)\]**​ に移動します。 2. シークレットグループがダウンロード可能であることを確認します。これにより、TLS コンテキストを API インスタンスに適用できるようになります。 シークレットグループがダウンロード可能であることを確認する手順は、次のとおりです。 1. シークレットグループの名前の横にある鉛筆アイコンをクリックします。 2. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されている場合は、​**\[Cancel (キャンセル)\]**​ をクリックします。 3. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されていない場合は、それを選択して ​**\[Save (保存)\]**​ をクリックします。 3. **\[Secret Groups (シークレットグループ)\]**​ リストビューで、シークレットグループの ​**\[Edit (編集)\]**​ ボタンをクリックして TLS コンテキストを追加します。 4. 左側のメニューで ​**\[TLS Context (TLS コンテキスト)\]**​ を選択し、​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 5. \[Create TLS Context (TLS コンテキストを作成)\] 画面で、必要な情報を追加します。 - **Name (名前)**​ TLS コンテキストの名前を入力します。 - **Target (対象)**​ **\[Flex Gateway\]**​ を選択し、TLS コンテキストを Flex Gateway API の SSL 検証として使用します。 - **\[Min TLS Version (最小 TLS バージョン)\]**​ と ​**\[Max TLS Version (最大 TLS バージョン)\]**​ さまざまな TLS バージョンをサポートするように選択したり、最小と最大の両方に同じバージョンを選択することで単一バージョンをサポートするように選択したりできます。 - **Keystore (キーストア)**​ 設定に必要な場合は、TLS コンテキストに保存するキーストアをドロップダウンリストから選択します。PEM 種別のキーストアのみが表示されます。キーストアには、Flex Gateway がインバウンド TLS とアウトバウンド TLS の両方に対してリモートパーティに提示する証明書が含まれます。

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
- **Truststore (トラストストア)**​ 設定に必要な場合は、クライアントによって信頼される証明書を保存するトラストストアをドロップダウンリストから選択します。PEM 種別のトラストストアのみが表示されます。トラストストアには、Flex がインバウンド TLS とアウトバウンド TLS の両方のリモートパーティ証明書を検証するために使用する CA パスが含まれます。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。
- **Expiration Date (有効期限)**​ 必要に応じて、TLS コンテキストの有効期限を入力します。 - **ALPN Protocols (ALPN プロトコル)**​ デフォルトでは、​**H2 - HTTP/1.1**​ が ALPN プロトコルとして選択されます。異なるプロトコルをサポートするには、この値を変更します。 - **Inbound Settings (インバウンド設定)**​ インバウンドトラフィックで mTLS をサポートする場合は、​**\[Validate Client certificate (クライアント証明書を検証)\]**​ を選択します。 - **Outbound Settings (アウトバウンド設定)**​ アウトバウンドトラフィックで mTLS をサポートしない場合は、​**\[Skip server certificate validation (サーバー証明書の検証をスキップ)\]**​ を選択します。 6. TLS コンテキストの暗号化サポートをカスタマイズする場合は、​[暗号化を選択します](#select-ciphers)​。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 7. **\[Save (保存)\]**​ をクリックします。 ## [](#tls-コンテキストを-api-に適用する)TLS コンテキストを API に適用する 新しいインスタンスの作成時に、または既存のインスタンスを編集して、TLS コンテキストを API インスタンスに適用できます。 API インスタンス設定にはダウンストリーム設定とアップストリーム設定の 2 つの部分があります。インバウンド TLS コンテキストはダウンストリーム設定オプションで、アウトバウンド TLS コンテキストはアップストリーム設定オプションです。新しい API インスタンスを追加する場合は、ダウンストリーム設定とアップストリーム設定は別々のページに配置されます。API インスタンスを編集する場合は、ダウンストリーム設定オプションとアップストリーム設定オプションは同じページに表示されますが、別のセクションに配置されます。 それぞれのオプションについては、関連するチュートリアルを参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [API インスタンスの編集](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task) TLS コンテキストを適用する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 次のいずれかへ移動します。 - 新しい API インスタンスを追加する場合は、アップストリームまたはダウンストリーム設定ページ。 - 既存の API インスタンスを編集する場合は、​**\[Settings (設定)\]**​ ページ。 3. インバウンド TLS コンテキストを設定する場合は、​**\[Protocol (プロトコル)\]**​ 設定項目の ​**\[HTTPS\]**​ を選択します。 4. **\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. **\[Secret Group (シークレットグループ)\]**​ を選択します。 2. **\[TLS Context (TLS コンテキスト)\]**​ を選択します。 3. **\[Ok\]**​ をクリックします。 5. API インスタンスの作成を完了するか、設定の編集を保存します。 ## [](#tls-context-applied-to-shared-ports)共有ポートに適用されるインバウンド TLS コンテキスト インバウンド TLS コンテキストを適用するにはポートに API インスタンスが必要ですが、インバウンド TLS コンテキストは API インスタンスではなくポートに適用されます。 ポートを他のインスタンスと共有する API インスタンスにインバウンド TLS コンテキストを適用すると、ポートを共有するすべてのインスタンスにインバウンド TLS コンテキストが適用されます。 ポートを共有する API インスタンスのインバウンド TLS コンテキストを適用、編集、または削除すると、ポートを共有するインスタンスのリストと共に警告が API Manager に表示されます。その後、リストされた API インスタンスのインバウンド TLS コンテキストの上書きを選択できます。ポートを共有する API インスタンスの TLS コンテキストを上書きすると、インバウンド TLS コンテキストがインスタンスに適用され、インスタンスが再デプロイされます。 デプロイされた API インスタンスのインバウンド TLS コンテキストを上書きすると、インスタンスが再デプロイされます。再デプロイすると、API インスタンスで短期間のダウンタイムが発生します。 以前にポートおよびインバウンド TLS コンテキストを他のインスタンスと共有していた API インスタンスのポートを編集した場合、インバウンド TLS コンテキストは以前のポートのインスタンスに適用されたままになります。 ## [](#redeploy-api-instance)シークレットグループを編集して API インスタンスを再デプロイする シークレットグループを編集するには、​[「シークレットグループを編集する」](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#edit-a-secret-group)​を参照してください。 現在 API インスタンスに適用されているシークレットグループを編集し、その変更を API インスタンスに適用する場合は、変更が影響するすべてのインスタンスを個別に再デプロイする必要があります。 API インスタンスを再デプロイする手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 再デプロイする API インスタンスの名前をクリックします。 3. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Apply (保存して適用)\]**​ をクリックします。 ## [](#select-ciphers)暗号化の選択 TLS コンテキストを設定すると、シークレットマネージャーによって、選択した TLS バージョンに基づいてデフォルトの暗号化が適用されます。デフォルトに加えて、選択した TLS バージョンで使用する他の暗号化を選択できます。各 TLS コンテキストに複数の暗号化を含めることができます。 暗号化を選択する手順は、次のとおりです。 1. **\[Ciphers (暗号化)\]**​ をクリックして使用可能な暗号化を表示します。 2. 暗号化を選択します。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 3. **\[Save (保存)\]**​ をクリックします。 ## [](#flex-gateway-での-tls-暗号化のサポート)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合は、TLS 1.3 のデフォルトの暗号化をサポートする必要があります。 TLS 1.2 をサポートする場合は、TLS 1.2 のデフォルトの暗号化が選択されます。ただし、TLS 1.3 とは異なり、さまざまな TLS 1.2 暗号化をカスタマイズできます。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートすることを選択した場合は、サポートする暗号化を選択する必要があります。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンが API アップストリームでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS AES 128 GCM SHA256

1.3

はい

セキュア

TLS AES 256 GCM SHA384

1.3

はい

セキュア

TLS CHACHA20 POLY1305 SHA256

1.3

はい

セキュア

TLS ECDHE ECDSA WITH AES 128 GCM SHA256

1.2

はい

推奨

TLS ECDHE ECDSA WITH AES 256 GCM SHA384

1.2

はい

推奨

TLS ECDHE ECDSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

推奨

TLS ECDHE PSK WITH CHACHA20 POLY1305 SHA256

1.2

いいえ

推奨

TLS ECDHE RSA WITH AES 128 GCM SHA256

1.2

はい

セキュア

TLS ECDHE RSA WITH AES 256 GCM SHA384

1.2

はい

セキュア

TLS ECDHE RSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

セキュア

TLS RSA WITH AES 128 GCM SHA256

1.2

いいえ

脆弱

TLS RSA WITH AES 256 GCM SHA384

1.2

いいえ

脆弱

TLS RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH 3DES EDE CBC SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-tls-config) - [Transport Layer Security ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-tls) # 接続モードでの Flex Gateway の TLS コンテキストの設定 Transport Layer Security (TLS) ポリシーは暗号化を使用して、クライアント、API インスタンス、およびアップストリームサービス間の通信を保護します。​[シークレットグループを作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task)​したら、TLS コンテキストまたは相互認証 TLS (mTLS) コンテキストを追加し、その TLS コンテキストを API Manager で API インスタンスに適用して、インバウンドトラフィックとアウトバウンドトラフィックを暗号化できます。 TLS コンテキストを追加するときに、TLS コンテキストで使用する暗号化を選択し、異なるインバウンドおよびアウトバウンド検証設定を定義することもできます。 Flex Gateway では以下がサポートされます。 - クライアントと API インスタンス (HTTPS) 間の通常の TLS (インバウンド TLS と呼ばれる) - API インスタンスとアップストリームサービス間の通常の TLS (アウトバウンド TLS と呼ばれる) - インバウンド方向とアウトバウンド方向の両方での相互認証 TLS (mTLS) デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。 Flex Gateway は、ポートレベルでインバウンド TLS を実装します。つまり、API インスタンスに適用されるインバウンド TLS コンテキストは、同じポートを共有する他のすべてのインスタンスにも適用されます。TLS コンテキストがポート間で共有される方法についての詳細は、​[「共有ポートに適用されるインバウンド TLS コンテキスト」](#tls-context-applied-to-shared-ports)​を参照してください。 ポート共有はアウトバウンド TLS では懸念になりません。アップストリームサービスごとにアウトバウンド TLS コンテキストを選択できます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#始める前に)始める前に Flex Gateway 接続モードの TLS コンテキストを設定する前に、次のタスクを完了してください。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) - 次の権限が有効になっていることの確認 - シークレットマネージャーの​_「Grant access to secrets (シークレットへのアクセス権の付与)」_ - API Manager の​_「Deploy API Proxies (API プロキシのデプロイ)」_ これらの権限は、Anypoint Platform 管理者がアクセス管理で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 - [シークレットグループの作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) シークレットグループを追加する場合、​[「TLS 設定オプション」](#tls-configuration-options)​を参照してください。 目的の設定に応じて、次のいずれかを実行します。 - [キーストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-keystore) - [トラストストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-truststore)
キーストアまたはトラストストアには、Privacy Enhanced Mail (PEM) 種別が必要です。
## [](#tls-configuration-options)TLS 設定オプション インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。必要な設定に応じて、異なる証明書ファイルをシークレットグループに追加し、異なる TLS コンテキスト設定オプションを選択する必要があります。 [「TLS コンテキストを追加する」](#add-a-tls-context)​ステップで必要な TLS コンテキスト設定については、次の相互参照テーブルを参照してください。
パラメーター インバウンド TLS インバウンド mTLS アウトバウンド TLS アウトバウンド mTLS

Keystore (キーストア)

必須

必須

未使用

必須

Truststore (トラストストア)

未使用

必須

[Skip server certificate validation (サーバー証明書の検証をスキップ)] が選択されていない場合は必須

アップストリーム証明書を検証する場合は必須

Validate Client certificate (クライアント証明書を検証)

未選択

選択

未使用

未使用

Skip server certificate validation (サーバー証明書の検証をスキップ)

未使用

未使用

両方

未選択
設定のパラメーターが「未使用」の場合、その状況は設定に影響しないことを意味します。 設定を簡素化するために、API インスタンスの異なるトラフィック方向に対して異なる TLS コンテキストを作成できます。ただし、同じ TLS コンテキストを使用して異なるトラフィック方向をサポートすることもできますが、同じコンテキストを使用して同じ方向の TLS と mTLS をサポートすることはできません。異なる方向に同じ TLS コンテキストを使用する場合は、両方向に必要なパラメーターを含めてください。 ## [](#add-a-tls-context)Flex Gateway の TLS コンテキストを追加する TLS コンテキストをシークレットグループに追加するには、名前、対象、バージョン、キーストアまたはトラストストアを指定する必要があります。必要に応じて、コンテキストの有効期限と ALPN プロトコルを追加し、インバウンド設定とアウトバウンド設定を定義できます。

現在 API インスタンスに適用されている TLS コンテキストを含むシークレットグループを編集する場合は、API インスタンスを再デプロイして変更を適用する必要があります。変更の影響を受けるすべてのインスタンスを個別に再デプロイする必要があります。API インスタンスを再デプロイするには、​「API インスタンスを再デプロイする」​を参照してください。
TLS コンテキストを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[Secrets Manager (シークレットマネージャー)\]**​ に移動します。 2. シークレットグループがダウンロード可能であることを確認します。これにより、TLS コンテキストを API インスタンスに適用できるようになります。 シークレットグループがダウンロード可能であることを確認する手順は、次のとおりです。 1. シークレットグループの名前の横にある鉛筆アイコンをクリックします。 2. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されている場合は、​**\[Cancel (キャンセル)\]**​ をクリックします。 3. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されていない場合は、それを選択して ​**\[Save (保存)\]**​ をクリックします。 3. **\[Secret Groups (シークレットグループ)\]**​ リストビューで、シークレットグループの ​**\[Edit (編集)\]**​ ボタンをクリックして TLS コンテキストを追加します。 4. 左側のメニューで ​**\[TLS Context (TLS コンテキスト)\]**​ を選択し、​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 5. \[Create TLS Context (TLS コンテキストを作成)\] 画面で、必要な情報を追加します。 - **Name (名前)**​ TLS コンテキストの名前を入力します。 - **Target (対象)**​ **\[Flex Gateway\]**​ を選択し、TLS コンテキストを Flex Gateway API の SSL 検証として使用します。 - **\[Min TLS Version (最小 TLS バージョン)\]**​ と ​**\[Max TLS Version (最大 TLS バージョン)\]**​ さまざまな TLS バージョンをサポートするように選択したり、最小と最大の両方に同じバージョンを選択することで単一バージョンをサポートするように選択したりできます。 - **Keystore (キーストア)**​ 設定に必要な場合は、TLS コンテキストに保存するキーストアをドロップダウンリストから選択します。PEM 種別のキーストアのみが表示されます。キーストアには、Flex Gateway がインバウンド TLS とアウトバウンド TLS の両方に対してリモートパーティに提示する証明書が含まれます。

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
- **Truststore (トラストストア)**​ 設定に必要な場合は、クライアントによって信頼される証明書を保存するトラストストアをドロップダウンリストから選択します。PEM 種別のトラストストアのみが表示されます。トラストストアには、Flex がインバウンド TLS とアウトバウンド TLS の両方のリモートパーティ証明書を検証するために使用する CA パスが含まれます。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。
- **Expiration Date (有効期限 (日))**​ 必要に応じて、TLS コンテキストの有効期限を入力します。 - **ALPN Protocols (ALPN プロトコル)**​ デフォルトでは、​**H2 - HTTP/1.1**​ が ALPN プロトコルとして選択されます。異なるプロトコルをサポートするには、この値を変更します。 - **Inbound Settings (インバウンド設定)**​ インバウンドトラフィックで mTLS をサポートする場合は、​**\[Validate Client certificate (クライアント証明書を検証)\]**​ を選択します。 - **Outbound Settings (アウトバウンド設定)**​ アウトバウンドトラフィックで mTLS をサポートしない場合は、​**\[Skip server certificate validation (サーバー証明書の検証をスキップ)\]**​ を選択します。 6. TLS コンテキストの暗号化サポートをカスタマイズする場合は、​[暗号化を選択します](#select-ciphers)​。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 7. **\[Save (保存)\]**​ をクリックします。 ## [](#tls-コンテキストを-api-に適用する)TLS コンテキストを API に適用する 新しいインスタンスの作成時に、または既存のインスタンスを編集して、TLS コンテキストを API インスタンスに適用できます。 API インスタンス設定にはダウンストリーム設定とアップストリーム設定の 2 つの部分があります。インバウンド TLS コンテキストはダウンストリーム設定オプションで、アウトバウンド TLS コンテキストはアップストリーム設定オプションです。新しい API インスタンスを追加する場合は、ダウンストリーム設定とアップストリーム設定は別々のページに配置されます。API インスタンスを編集する場合は、ダウンストリーム設定オプションとアップストリーム設定オプションは同じページに表示されますが、別のセクションに配置されます。 それぞれのオプションについては、関連するチュートリアルを参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [API インスタンスの編集](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task) TLS コンテキストを適用する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 次のいずれかへ移動します。 - 新しい API インスタンスを追加する場合は、アップストリームまたはダウンストリーム設定ページ。 - 既存の API インスタンスを編集する場合は、​**\[Settings (設定)\]**​ ページ。 3. インバウンド TLS コンテキストを設定する場合は、​**\[Protocol (プロトコル)\]**​ 設定項目の ​**\[HTTPS\]**​ を選択します。 4. **\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. **\[Secret Group (シークレットグループ)\]**​ を選択します。 2. **\[TLS Context (TLS コンテキスト)\]**​ を選択します。 3. **\[Ok\]**​ をクリックします。 5. API インスタンスの作成を完了するか、設定の編集を保存します。 ## [](#tls-context-applied-to-shared-ports)共有ポートに適用されるインバウンド TLS コンテキスト インバウンド TLS コンテキストを適用するにはポートに API インスタンスが必要ですが、インバウンド TLS コンテキストは API インスタンスではなくポートに適用されます。 ポートを他のインスタンスと共有する API インスタンスにインバウンド TLS コンテキストを適用すると、ポートを共有するすべてのインスタンスにインバウンド TLS コンテキストが適用されます。 ポートを共有する API インスタンスのインバウンド TLS コンテキストを適用、編集、または削除すると、ポートを共有するインスタンスのリストと共に警告が API Manager に表示されます。その後、リストされた API インスタンスのインバウンド TLS コンテキストの上書きを選択できます。ポートを共有する API インスタンスの TLS コンテキストを上書きすると、インバウンド TLS コンテキストがインスタンスに適用され、インスタンスが再デプロイされます。 デプロイされた API インスタンスのインバウンド TLS コンテキストを上書きすると、インスタンスが再デプロイされます。再デプロイすると、API インスタンスで短期間のダウンタイムが発生します。 以前にポートおよびインバウンド TLS コンテキストを他のインスタンスと共有していた API インスタンスのポートを編集した場合、インバウンド TLS コンテキストは以前のポートのインスタンスに適用されたままになります。 ## [](#redeploy-api-instance)シークレットグループを編集して API インスタンスを再デプロイする シークレットグループを編集するには、​[「シークレットグループを編集する」](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#edit-a-secret-group)​を参照してください。 現在 API インスタンスに適用されているシークレットグループを編集し、その変更を API インスタンスに適用する場合は、変更が影響するすべてのインスタンスを個別に再デプロイする必要があります。 API インスタンスを再デプロイする手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 再デプロイする API インスタンスの名前をクリックします。 3. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Apply (保存して適用)\]**​ をクリックします。 ## [](#select-ciphers)暗号化の選択 TLS コンテキストを設定すると、シークレットマネージャーによって、選択した TLS バージョンに基づいてデフォルトの暗号化が適用されます。デフォルトに加えて、選択した TLS バージョンで使用する他の暗号化を選択できます。各 TLS コンテキストに複数の暗号化を含めることができます。 暗号化を選択する手順は、次のとおりです。 1. **\[Ciphers (暗号化)\]**​ をクリックして使用可能な暗号化を表示します。 2. 暗号化を選択します。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 3. **\[Save (保存)\]**​ をクリックします。 ## [](#flex-gateway-での-tls-暗号化のサポート)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合は、TLS 1.3 のデフォルトの暗号化をサポートする必要があります。 TLS 1.2 をサポートする場合は、TLS 1.2 のデフォルトの暗号化が選択されます。ただし、TLS 1.3 とは異なり、さまざまな TLS 1.2 暗号化をカスタマイズできます。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートすることを選択した場合は、サポートする暗号化を選択する必要があります。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンが API アップストリームでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS AES 128 GCM SHA256

1.3

はい

セキュア

TLS AES 256 GCM SHA384

1.3

はい

セキュア

TLS CHACHA20 POLY1305 SHA256

1.3

はい

セキュア

TLS ECDHE ECDSA WITH AES 128 GCM SHA256

1.2

はい

推奨

TLS ECDHE ECDSA WITH AES 256 GCM SHA384

1.2

はい

推奨

TLS ECDHE ECDSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

推奨

TLS ECDHE PSK WITH CHACHA20 POLY1305 SHA256

1.2

いいえ

推奨

TLS ECDHE RSA WITH AES 128 GCM SHA256

1.2

はい

セキュア

TLS ECDHE RSA WITH AES 256 GCM SHA384

1.2

はい

セキュア

TLS ECDHE RSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

セキュア

TLS RSA WITH AES 128 GCM SHA256

1.2

いいえ

脆弱

TLS RSA WITH AES 256 GCM SHA384

1.2

いいえ

脆弱

TLS RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH 3DES EDE CBC SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config) - [Transport Layer Security ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) # 接続モードでの Flex Gateway のメッセージログの設定 API Manager の API インスタンスにメッセージログポリシーを適用すると、API Manager 内で Flex Gateway によって管理される API の基本的なログ (インバウンド/アウトバウンドコールおよびヘッダーなど) を表示できます。API インスタンスのログは、メッセージログポリシーを設定して適用した場合にのみ発生します。 API Manager で要求総数、ポリシー違反総数、総エラー数、平均応答時間などのメトリクスを表示するには、[接続モードでの Flex Gateway 向け API Manager の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-view-api-metrics)を参照してください。 ## [](#メッセージログの制限と機能)メッセージログの制限と機能 API Manager は、API インスタンスごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、API インスタンスごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、サードパーティサービス (ポリシーで設定) を使用するか、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションにサインアップできます。 基本的なログで、ポリシーを通じて設定された各 API インスタンスの次の情報が報告されます。 - インバウンドおよびアウトバウンド API コール、およびパケットコンテンツ - 要求内のヘッダーおよびその他の情報 API Manager でメッセージログを表示するには、次の権限のいずれかが必要です。 - API Manager Environment Administrator (API Manager 環境システム管理者) - API Manager Deploy API Proxies (API Manager API プロキシのデプロイ) - General Organization Administration (一般組織のシステム管理者) [Anypoint Platform で使用可能な権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product)を参照してください。 ## [](#接続モードでメッセージログを設定する)接続モードでメッセージログを設定する 1. API Manager の \[API Administration (API 管理)\] で、API インスタンスの名前を選択します。 2. **\[Policies (ポリシー)\]**​ をクリックします。 3. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 4. **\[Troubleshooting (トラブルシューティング)\]**​ カテゴリで ​**\[Message Logging (メッセージログ)\]**​ をクリックします。 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[+ Add (+ 追加)\]**​ をクリックします。 7. **\[Configuration Name (設定名)\]**​ に名前を入力します (「Info messages before calling API (API をコールする前の情報メッセージ)」など)。 8. 表示する情報を選択する DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']]`​ はメッセージのヘッダーから ID を抽出します。詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support)を参照してください。 9. ログメッセージを絞り込む場合は、DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']==1]`​ はヘッダーの ID が 1 のログメッセージを表示します。 10. ログにプレフィックスを付ける場合は、​**\[Category (カテゴリ)\]**​ に入力します。 11. 重要度レベルを入力します。 入力できるレベルは 1 つのみです。各重要度レベルとレベルの階層の説明については、​[「メッセージログの重要度レベル」](#severity-levels)​を参照してください。 12. API がコールされた後のメッセージが必要な場合は、​**\[After Calling API (API のコール後)\]**​ を選択します。 13. 設定をさらに追加する場合は、​**\[+ Add (+ 追加)\]**​ をクリックします。 14. **\[Save (保存)\]**​ をクリックします。 その後、API インスタンスの ​**\[Message Log (メッセージログ)\]**​ オプションが表示されます。 検索項目を使用して、時間とログの重要度 (INFO (情報)、ERROR (エラー)、WARN (警告)、DEBUG (デバッグ)) に基づいて特定のログを検索します。これらのログをダウンロードして、さらに分析できます。 ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# 接続モードでの Flex Gateway のメッセージログの設定 API Manager の API インスタンスにメッセージログポリシーを適用すると、API Manager 内で Flex Gateway によって管理される API の基本的なログ (インバウンド/アウトバウンドコールおよびヘッダーなど) を表示できます。API インスタンスのログは、メッセージログポリシーを設定して適用した場合にのみ発生します。 API Manager で要求総数、ポリシー違反総数、総エラー数、平均応答時間などのメトリクスを表示するには、[Flex Gateway API の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-api-metrics)を参照してください。 ## [](#メッセージログの制限と機能)メッセージログの制限と機能 API Manager は、API インスタンスごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、API インスタンスごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、サードパーティサービス (ポリシーで設定) を使用するか、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションにサインアップできます。 ポリシーを使用して設定された各 API インスタンスでは、基本的なログに次の内容が報告されます。 - インバウンドおよびアウトバウンド API コール、およびパケットコンテンツ - 要求内のヘッダーおよびその他の情報 API Manager でメッセージログを表示するには、次の権限のいずれかが必要です。 - API Manager Environment Administrator (API Manager 環境システム管理者) - API Manager Deploy API Proxies (API Manager API プロキシのデプロイ) - General Organization Administration (一般組織のシステム管理者) [Anypoint Platform で使用可能な権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product)を参照してください。 ## [](#始める前に)始める前に Flex Gateway のメッセージログを設定する前に、次のタスクを完了します。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) - [API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) ## [](#接続モードでメッセージログを設定する)接続モードでメッセージログを設定する 1. API Manager の \[API Administration (API 管理)\] で、API インスタンスの名前を選択します。 2. **\[Policies (ポリシー)\]**​ をクリックします。 3. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 4. **\[Troubleshooting (トラブルシューティング)\]**​ カテゴリで、​**\[Message Logging (メッセージログ)\]**​ をクリックします。 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[+ Add (+ 追加)\]**​ をクリックします。 7. **\[Configuration Name (設定名)\]**​ に名前を入力します (API をコールする前の情報メッセージなど)。 8. 表示する情報を選択する DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']]`​ はメッセージのヘッダーから ID を抽出します。詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.8/policies-flex-dataweave-support)を参照してください。 9. ログメッセージを絞り込む場合は、DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']==1]`​ はヘッダーの ID が 1 のログメッセージを表示します。 10. ログにプレフィックスを付ける場合は、​**\[Category (カテゴリ)\]**​ に入力します。 11. 重要度レベルを入力します。 入力できるレベルは 1 つのみです。各重要度レベルとレベルの階層の説明については、​[「メッセージログの重要度レベル」](#severity-levels)​を参照してください。 12. API がコールされた後のメッセージが必要な場合は、​**\[After Calling API (API のコール後)\]**​ を選択します。 13. 設定をさらに追加する場合は、​**\[+ Add (+ 追加)\]**​ をクリックします。 14. **\[Save (保存)\]**​ をクリックします。 その後、API インスタンスの ​**\[Message Log (メッセージログ)\]**​ オプションが表示されます。 検索項目を使用して、時間とログの重要度 (INFO (情報)、ERROR (エラー)、WARN (警告)、DEBUG (デバッグ)) に基づいて特定のログを検索します。これらのログをダウンロードして、さらに分析できます。 ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# 接続モードでの Flex Gateway のメッセージログの設定 API Manager の API インスタンスにメッセージログポリシーを適用すると、API Manager 内で Flex Gateway によって管理される API の基本的なログ (インバウンド/アウトバウンドコールおよびヘッダーなど) を表示できます。API インスタンスのログは、メッセージログポリシーを設定して適用した場合にのみ発生します。 API Manager で要求総数、ポリシー違反総数、総エラー数、平均応答時間などのメトリクスを表示するには、[接続モードでの Flex Gateway 向け API Manager の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-view-api-metrics)を参照してください。 ## [](#メッセージログの制限と機能)メッセージログの制限と機能 API Manager は、API インスタンスごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、API インスタンスごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、サードパーティサービス (ポリシーで設定) を使用するか、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションにサインアップできます。 基本的なログで、ポリシーを通じて設定された各 API インスタンスの次の情報が報告されます。 - インバウンドおよびアウトバウンド API コール、およびパケットコンテンツ - 要求内のヘッダーおよびその他の情報 API Manager でメッセージログを表示するには、次の権限のいずれかが必要です。 - API Manager Environment Administrator (API Manager 環境システム管理者) - API Manager Deploy API Proxies (API Manager API プロキシのデプロイ) - General Organization Administration (一般組織のシステム管理者) [Anypoint Platform で使用可能な権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product)を参照してください。 ## [](#接続モードでメッセージログを設定する)接続モードでメッセージログを設定する 1. API Manager の \[API Administration (API 管理)\] で、API インスタンスの名前を選択します。 2. **\[Policies (ポリシー)\]**​ をクリックします。 3. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 4. **\[Troubleshooting (トラブルシューティング)\]**​ カテゴリで ​**\[Message Logging (メッセージログ)\]**​ をクリックします。 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[+ Add (+ 追加)\]**​ をクリックします。 7. **\[Configuration Name (設定名)\]**​ に名前を入力します (「Info messages before calling API (API をコールする前の情報メッセージ)」など)。 8. 表示する情報を選択する DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']]`​ はメッセージのヘッダーから ID を抽出します。詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support)を参照してください。 9. ログメッセージを絞り込む場合は、DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']==1]`​ はヘッダーの ID が 1 のログメッセージを表示します。 10. ログにプレフィックスを付ける場合は、​**\[Category (カテゴリ)\]**​ に入力します。 11. 重要度レベルを入力します。 入力できるレベルは 1 つのみです。各重要度レベルとレベルの階層の説明については、​[「メッセージログの重要度レベル」](#severity-levels)​を参照してください。 12. API がコールされた後のメッセージが必要な場合は、​**\[After Calling API (API のコール後)\]**​ を選択します。 13. 設定をさらに追加する場合は、​**\[+ Add (+ 追加)\]**​ をクリックします。 14. **\[Save (保存)\]**​ をクリックします。 その後、API インスタンスの ​**\[Message Log (メッセージログ)\]**​ オプションが表示されます。 検索項目を使用して、時間とログの重要度 (INFO (情報)、ERROR (エラー)、WARN (警告)、DEBUG (デバッグ)) に基づいて特定のログを検索します。これらのログをダウンロードして、さらに分析できます。 ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# 接続モードでの Flex Gateway のレプリカの設定

20%

25%

Linux サービスとしての Flex レプリカの追加

Docker コンテナでの Flex レプリカの追加
## [](#flex-レプリカ)Flex レプリカ Flex レプリカとは、Flex Gateway のインスタンスです。複数の Flex Gateway レプリカでゲートウェイレイヤーをセットアップすることにより、Flex Gateway にデプロイされる API は多くのトラフィックを処理できるようになります。 Flex Gateway を使用して本番環境で API を管理する場合は、単一障害点を回避するために、複数の Flex レプリカを設定します。複数の Flex レプリカを実行することで、API サービスが大量のトラフィックを受け取った場合でも高いパフォーマンスを維持できます。 ## [](#始める前に)始める前に 開始する前に、以下のタスクが完了していることを確認してください。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [接続モードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) ## [](#linux-サービスとしての-flex-レプリカの追加)Linux サービスとしての Flex レプリカの追加 Flex レプリカを Linux サービスとして追加するには、以下のタスクを実行します。 - Linux マシンまたは VM への登録時に作成された登録ファイルをコピーして貼り付ける。 - Flex Gateway の開始コマンドを実行する。 ### [](#登録ファイルのコピー)登録ファイルのコピー Linux マシンまたは VM の次の場所に ​`registration.yaml`​ ファイルをコピーします。 - `/usr/local/share/mulesoft/flex-gateway/conf.d` ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` 左側のナビゲーションで ​**\[Flex Gateway\]**​ をクリックすると、Flex Gateway に追加のレプリカが表示されます。ページの更新が必要な場合もあります。 ## [](#docker)Docker コンテナでの Flex レプリカの追加 Docker コンテナで Flex レプリカを追加するには、登録時に作成したのと同じ ​`registration.yaml`​ ファイルを使用して、Flex Gateway を開始するためのコマンドを実行する必要があります。コンテナをローカルに実行している場合は、別のポートを使用する必要もあります。 ### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
左側のナビゲーションで ​**\[Flex Gateway\]**​ をクリックすると、Flex Gateway に追加のレプリカが表示されます。ページの更新が必要な場合もあります。 # 接続モードでの Flex Gateway のレプリカの設定

20%

25%

Linux サービスとしての Flex レプリカの追加

Docker コンテナでの Flex レプリカの追加
## [](#flex-レプリカ)Flex レプリカ Flex レプリカとは、Flex Gateway のインスタンスです。複数の Flex Gateway レプリカでゲートウェイレイヤーをセットアップすることにより、Flex Gateway にデプロイされる API は多くのトラフィックを処理できるようになります。 Flex Gateway を使用して本番環境で API を管理する場合は、単一障害点を回避するために、複数の Flex レプリカを設定します。複数の Flex レプリカを実行することで、API サービスが大量のトラフィックを受け取った場合でも高いパフォーマンスを維持できます。 ## [](#始める前に)始める前に 開始する前に、以下のタスクが完了していることを確認してください。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - [接続モードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) ## [](#linux-サービスとしての-flex-レプリカの追加)Linux サービスとしての Flex レプリカの追加 Flex レプリカを Linux サービスとして追加するには、以下のタスクを実行します。 - Linux マシンまたは VM への登録時に作成された登録ファイルをコピーして貼り付ける。 - Flex Gateway の開始コマンドを実行する。 ### [](#登録ファイルのコピー)登録ファイルのコピー Linux マシンまたは VM の次の場所に ​`registration.yaml`​ ファイルをコピーします。 - `/usr/local/share/mulesoft/flex-gateway/conf.d` ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` 左側のナビゲーションで ​**\[Flex Gateway\]**​ をクリックすると、Flex Gateway に追加のレプリカが表示されます。ページの更新が必要な場合もあります。 ## [](#docker)Docker コンテナでの Flex レプリカの追加 Docker コンテナで Flex レプリカを追加するには、登録時に作成したのと同じ ​`registration.yaml`​ ファイルを使用して、Flex Gateway を開始するためのコマンドを実行する必要があります。コンテナをローカルに実行している場合は、別のポートを使用する必要もあります。 ### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
左側のナビゲーションで ​**\[Flex Gateway\]**​ をクリックすると、Flex Gateway に追加のレプリカが表示されます。ページの更新が必要な場合もあります。 # 接続モードでの Flex Gateway のレプリカの設定

20%

25%

Linux サービスとしての Flex レプリカの追加

Docker コンテナでの Flex レプリカの追加
## [](#flex-レプリカ)Flex レプリカ Flex レプリカとは、Flex Gateway のインスタンスです。複数の Flex Gateway レプリカでゲートウェイレイヤーをセットアップすることにより、Flex Gateway にデプロイされる API は多くのトラフィックを処理できるようになります。 Flex Gateway を使用して本番環境で API を管理する場合は、単一障害点を回避するために、複数の Flex レプリカを設定します。複数の Flex レプリカを実行することで、API サービスが大量のトラフィックを受け取った場合でも高いパフォーマンスを維持できます。 ## [](#始める前に)始める前に 開始する前に、以下のタスクが完了していることを確認してください。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [接続モードでの登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) ## [](#linux-サービスとしての-flex-レプリカの追加)Linux サービスとしての Flex レプリカの追加 Flex レプリカを Linux サービスとして追加するには、以下のタスクを実行します。 - Linux マシンまたは VM への登録時に作成された登録ファイルをコピーして貼り付ける。 - Flex Gateway の開始コマンドを実行する。 ### [](#登録ファイルのコピー)登録ファイルのコピー Linux マシンまたは VM の次の場所に ​`registration.yaml`​ ファイルをコピーします。 - `/usr/local/share/mulesoft/flex-gateway/conf.d` ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` 左側のナビゲーションで ​**\[Flex Gateway\]**​ をクリックすると、Flex Gateway に追加のレプリカが表示されます。ページの更新が必要な場合もあります。 ## [](#docker)Docker コンテナでの Flex レプリカの追加 Docker コンテナで Flex レプリカを追加するには、登録時に作成したのと同じ ​`registration.yaml`​ ファイルを使用して、Flex Gateway を開始するためのコマンドを実行する必要があります。コンテナをローカルに実行している場合は、別のポートを使用する必要もあります。 ### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
左側のナビゲーションで ​**\[Flex Gateway\]**​ をクリックすると、Flex Gateway に追加のレプリカが表示されます。ページの更新が必要な場合もあります。 # 接続モードでの Flex Gateway の共有ストレージの設定

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
分散キャッシュ、ゲートウェイ設定コーチング (接続モード)、レート制限ポリシーの共有ストレージを有効にします。Redis では、キャッシュ用の追加メモリも提供されます。 本番ワークフローでは [Redis](https://redis.io/)​ を使用する必要があります。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。分散ポリシーでデータを共有するように Redis を設定する必要があります。その他のすべてのポリシーでは、ストレージにレプリカメモリを使用します。 カスタム YAML ファイルを介して共有ストレージを設定します。 次の手順は、Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の Redis ベースのストレージサポートを示しています。 Redis Sentinel、または Redis 共有ストレージへの TLS 接続を設定するには、以下を参照してください。 - [Redis Sentinel の設定](#redis-sentinel) - [Redis ベースの共有ストレージ用の TLS の設定](#redis-tls)

20%

25%

20%

Linux サービスとして Flex Gateway の共有ストレージを設定する

Docker コンテナで Flex Gateway の共有ストレージを設定する

Kubernetes クラスターで Flex Gateway の共有ストレージを設定する
## [](#始める前に)始める前に Flex Gateway の共有ストレージを設定する前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の共有ストレージを設定する 1. `/etc/mulesoft/flex-gateway/conf.d`​ ディレクトリにフォルダーを作成し、​`custom`​ という名前を付けます。 ```ssh sudo mkdir /etc/mulesoft/flex-gateway/conf.d/custom ``` 2. `custom`​ フォルダーに YAML 設定ファイルを作成します。 ```ssh sudo touch /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` 3. Redis ストレージ設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#docker)Docker コンテナで Flex Gateway の共有ストレージを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Flex Gateway とすべてのレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、共有ストレージの詳細を使用して ​`app`​ フォルダーに保存します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の共有ストレージを設定する Flex Gateway の共有ストレージを設定するには、YAML 設定ファイルとストレージの詳細を使用して新しいリソースを作成します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#redis-sentinel)Redis Sentinel の設定 Redis Sentinel では、Redis 共有ストレージ用の高可用性が提供されます。Redis Sentinel についての詳細は、 [「Redis Sentinel」](https://redis.io/docs/management/sentinel/)​を参照してください。 前のセクションで説明した手順を使用して Redis Sentinel を設定します。 Redis Sentinel を追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage namespace: test-ns spec: sharedStorage: redis: username: "user" password: "pass" sentinel: addresses: - internal.redis.com:6379 masterName: "name" password: "pass" db: 0 ``` ## [](#redis-tls)Redis ベースの共有ストレージ用の TLS の設定 TLS と Redis を使用して、Flex Gateway と Redis インスタンス間のデータセキュリティを確保します。TLS を設定することで、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。さらに、TLS を設定すれば、組織はコンプライアンス要件を満たしてユーザーの信頼を築きやすくなります。 TLS は Redis と Redis Sentinel の両方と連携します。 前のセクションで説明した手順を使用して Redis ベースの共有ストレージ用に TLS を設定します。 TLS を使用して Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` パラメーターの設定については、​[「Declarative Configuration Reference (Shared Storage) (宣言型設定リファレンス (共有ストレージ))」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide#shared-storage)​を参照してください。 ## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-shared-storage-config) - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide#shared-storage) # 接続モードでの Flex Gateway の共有ストレージの設定

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Anypoint Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。Redis では、キャッシュ用の追加メモリも提供されます。 本番ワークフローでは [Redis](https://redis.io/)​ を使用する必要があります。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。分散ポリシーでデータを共有するように Redis を設定する必要があります。その他のすべてのポリシーでは、ストレージにレプリカメモリを使用します。 カスタム YAML ファイルを介して共有ストレージを設定します。 次の手順は、Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の Redis ベースのストレージサポートを示しています。 Redis Sentinel、または Redis 共有ストレージへの TLS 接続を設定するには、以下を参照してください。 - [Redis Sentinel の設定](#redis-sentinel) - [Redis ベースの共有ストレージ用の TLS の設定](#redis-tls)

20%

25%

20%

Linux サービスとして Flex Gateway の共有ストレージを設定する

Docker コンテナで Flex Gateway の共有ストレージを設定する

Kubernetes クラスターで Flex Gateway の共有ストレージを設定する
## [](#始める前に)始める前に Flex Gateway の共有ストレージを設定する前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の共有ストレージを設定する 1. `/etc/mulesoft/flex-gateway/conf.d`​ ディレクトリにフォルダーを作成し、​`custom`​ という名前を付けます。 ```ssh sudo mkdir /etc/mulesoft/flex-gateway/conf.d/custom ``` 2. `custom`​ フォルダーに YAML 設定ファイルを作成します。 ```ssh sudo touch /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` 3. Redis ストレージ設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#docker)Docker コンテナで Flex Gateway の共有ストレージを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Flex Gateway とすべてのレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、共有ストレージの詳細を使用して ​`app`​ フォルダーに保存します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の共有ストレージを設定する Flex Gateway の共有ストレージを設定するには、YAML 設定ファイルとストレージの詳細を使用して新しいリソースを作成します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#redis-sentinel)Redis Sentinel の設定 Redis Sentinel では、Redis 共有ストレージ用の高可用性が提供されます。Redis Sentinel についての詳細は、 [「Redis Sentinel」](https://redis.io/docs/management/sentinel/)​を参照してください。 前のセクションで説明した手順を使用して Redis Sentinel を設定します。 Redis Sentinel を追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage namespace: test-ns spec: sharedStorage: redis: username: "user" password: "pass" sentinel: addresses: - internal.redis.com:6379 masterName: "name" password: "pass" db: 0 ``` ## [](#redis-tls)Redis ベースの共有ストレージ用の TLS の設定 TLS と Redis を使用して、Flex Gateway と Redis インスタンス間のデータセキュリティを確保します。TLS を設定することで、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。さらに、TLS を設定すれば、組織はコンプライアンス要件を満たしてユーザーの信頼を築きやすくなります。 TLS は Redis と Redis Sentinel の両方と連携します。 前のセクションで説明した手順を使用して Redis ベースの共有ストレージ用に TLS を設定します。 TLS を使用して Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` パラメーターの設定については、​[「Declarative Configuration Reference (Shared Storage) (宣言型設定リファレンス (共有ストレージ))」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide#shared-storage)​を参照してください。 ## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-shared-storage-config) - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide#shared-storage) # 接続モードでの Flex Gateway の共有ストレージの設定

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
分散キャッシュ、ゲートウェイ設定コーチング (接続モード)、レート制限ポリシーの共有ストレージを有効にします。Redis では、キャッシュ用の追加メモリも提供されます。 本番ワークフローでは [Redis](https://redis.io/)​ を使用する必要があります。Redis が定義されていない場合、ポート 4000 の共有ストレージサービスを引き続き使用できますが、メモリ内実装が使用されます。分散ポリシーでデータを共有するように Redis を設定する必要があります。その他のすべてのポリシーでは、ストレージにレプリカメモリを使用します。 カスタム YAML ファイルを介して共有ストレージを設定します。 次の手順は、Linux サービスまたは Kubernetes クラスターとして、Docker コンテナで実行されている Flex Gateway の Redis ベースのストレージサポートを示しています。 Redis Sentinel、または Redis 共有ストレージへの TLS 接続を設定するには、以下を参照してください。 - [Redis Sentinel の設定](#redis-sentinel) - [Redis ベースの共有ストレージ用の TLS の設定](#redis-tls)

20%

25%

20%

Linux サービスとして Flex Gateway の共有ストレージを設定する

Docker コンテナで Flex Gateway の共有ストレージを設定する

Kubernetes クラスターで Flex Gateway の共有ストレージを設定する
## [](#始める前に)始める前に Flex Gateway の共有ストレージを設定する前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) ## [](#linux)Linux サービスとして Flex Gateway の共有ストレージを設定する 1. `/etc/mulesoft/flex-gateway/conf.d`​ ディレクトリにフォルダーを作成し、​`custom`​ という名前を付けます。 ```ssh sudo mkdir /etc/mulesoft/flex-gateway/conf.d/custom ``` 2. `custom`​ フォルダーに YAML 設定ファイルを作成します。 ```ssh sudo touch /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` 3. Redis ストレージ設定の詳細を使用してファイルを更新します。次に例を示します。 ```ssh sudo vi /etc/mulesoft/flex-gateway/conf.d/custom/shared-storage-config.yaml ``` Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#docker)Docker コンテナで Flex Gateway の共有ストレージを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Flex Gateway とすべてのレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、共有ストレージの詳細を使用して ​`app`​ フォルダーに保存します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway の共有ストレージを設定する Flex Gateway の共有ストレージを設定するには、YAML 設定ファイルとストレージの詳細を使用して新しいリソースを作成します。 Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: redis.e-commerce.svc:6379 username: ecomm-user password: ecomm-pwd-123 DB: 7 ``` ## [](#redis-sentinel)Redis Sentinel の設定 Redis Sentinel では、Redis 共有ストレージ用の高可用性が提供されます。Redis Sentinel についての詳細は、 [「Redis Sentinel」](https://redis.io/docs/management/sentinel/)​を参照してください。 前のセクションで説明した手順を使用して Redis Sentinel を設定します。 Redis Sentinel を追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage namespace: test-ns spec: sharedStorage: redis: username: "user" password: "pass" sentinel: addresses: - internal.redis.com:6379 masterName: "name" password: "pass" db: 0 ``` ## [](#redis-tls)Redis ベースの共有ストレージ用の TLS の設定 TLS と Redis を使用して、Flex Gateway と Redis インスタンス間のデータセキュリティを確保します。TLS を設定することで、機密データを保護し、不正なアクセスを防止して、サービスの信頼性を維持できます。さらに、TLS を設定すれば、組織はコンプライアンス要件を満たしてユーザーの信頼を築きやすくなります。 TLS は Redis と Redis Sentinel の両方と連携します。 前のセクションで説明した手順を使用して Redis ベースの共有ストレージ用に TLS を設定します。 TLS を使用して Redis ベースの共有ストレージを追加するためのサンプル設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: shared-storage-redis spec: sharedStorage: redis: address: internal.redis.com:6379 tls: skipValidation: false minVersion: "1.1" maxVersion: "1.3" alpn: - h2 - http/1.1 ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_RSA_WITH_3DES_EDE_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_128_CBC_SHA256 - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 trustedCA: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- certificate: keyPassphrase: "****" key: | -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- crt: | -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- ``` パラメーターの設定については、​[「Declarative Configuration Reference (Shared Storage) (宣言型設定リファレンス (共有ストレージ))」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide#shared-storage)​を参照してください。 ## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-shared-storage-config) - [宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide#shared-storage) # 接続モードでの Flex Gateway の登録と実行 Flex Gateway を使用して API インスタンスを設定するには、ゲートウェイを登録して開始する必要があります。 Flex Gateway を接続モードで登録するには、次の 3 つの方法があります。 - [ユーザー名とパスワードを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-up)​: Anypoint Platform のユーザー名とパスワードを持っている場合は、これらのログイン情報を使用して Flex Gateway を登録できます。 - [接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-app)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、接続アプリケーションのログイン情報を使用して Flex Gateway を登録できます。 - [トークンを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run-token)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、Runtime Manager UI が生成する登録トークンを使用できます。トークンは 4 時間有効です。 # 接続モードでの Flex Gateway の登録と実行 Flex Gateway を使用して API インスタンスを設定するには、ゲートウェイを登録して開始する必要があります。 Flex Gateway を接続モードで登録するには、次の 3 つの方法があります。 - [ユーザー名とパスワードを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-up)​: Anypoint Platform のユーザー名とパスワードを持っている場合は、これらのログイン情報を使用して Flex Gateway を登録できます。 - [接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-app)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、接続アプリケーションのログイン情報を使用して Flex Gateway を登録できます。 - [トークンを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run-token)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、Runtime Manager UI が生成する登録トークンを使用できます。トークンは 4 時間有効です。 # 接続モードでの Flex Gateway の登録と実行 Flex Gateway を使用して API インスタンスを設定するには、ゲートウェイを登録して開始する必要があります。 Flex Gateway を接続モードで登録するには、次の 3 つの方法があります。 - [ユーザー名とパスワードを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-up)​: Anypoint Platform のユーザー名とパスワードを持っている場合は、これらのログイン情報を使用して Flex Gateway を登録できます。 - [接続アプリケーションを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-app)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、接続アプリケーションのログイン情報を使用して Flex Gateway を登録できます。 - [トークンを使用した登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run-token)​: Anypoint Platform のユーザー名とパスワードを持っていない場合は、Runtime Manager UI が生成する登録トークンを使用できます。トークンは 4 時間有効です。 # 接続モードでの Flex Gateway の設定 - [レプリカの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-rep-run)​ - Anypoint Flex Gateway では、Flex Gateway のインスタンスであるレプリカを作成できます。デフォルトでは、Flex Gateway は単一のレプリカとして実行します。複数のレプリカを実行することにより、スケーリング、ロードバランシング、高可用性を実現できます。 - [TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tls-config)​ - Flex Gateway では、インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。 - [共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config)​ - Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。 - [転送プロキシの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-forward-proxy)​ - Flex Gateway では、プロキシ接続経由で外部 HTTP 接続をルーティングするように転送プロキシを設定できます。 - [API Manager API ツールを使用した設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-manage-public-api)​ - Flex Gateway では、API Manager との通信に使用するコマンドラインツールである API Manager API ツールを介して、Flex Gateway を設定および管理できます。 - [ライブネスチェックの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-readiness-liveness)​ - Flex Gateway では、ライブネスチェックコマンドを実行して、ゲートウェイの健全性をテストできます。さらに、Kubernetes にデプロイされた Flex Gateway には、指定された回数のチェックが失敗した後にポッドを自動的に再起動するライブネスプローブが含まれています。 - [PROXY プロトコルの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-proxy-protocol)​ - Flex Gateway では、マルチレイヤー接続を提供しているときにクライアント IP アドレスを保持するための PROXY プロトコルがサポートされています。 - [Anypoint CLI を使用した Jenkins Pipeline での Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-jenkins-cli)​ - Flex Gateway では、Anypoint CLI を使用して Jenkins Pipeline を作成し、ワークフローを自動化できます。 - [API Manager API を使用した Jenkins Pipeline での Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-jenkins-api)​ - Flex Gateway では、API Manager API を使用して Jenkins Pipeline を作成し、ワークフローを自動化できます。 - [分散トレースの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tracing-config)​ - Flex Gateway では、API の分散とレースを設定できます。 # 接続モードでの Flex Gateway の設定 - [レプリカの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-rep-run)​ - Anypoint Flex Gateway では、Flex Gateway のインスタンスであるレプリカを作成できます。デフォルトでは、Flex Gateway は単一のレプリカとして実行します。複数のレプリカを実行することにより、スケーリング、ロードバランシング、高可用性を実現できます。 - [TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-tls-config)​ - Flex Gateway では、インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。 - [共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-shared-storage-config)​ - Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。 - [転送プロキシの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-forward-proxy)​ - Flex Gateway では、プロキシ接続経由で外部 HTTP 接続をルーティングするように転送プロキシを設定できます。 - [API Manager API ツールを使用した設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-manage-public-api)​ - Flex Gateway では、API Manager との通信に使用するコマンドラインツールである API Manager API ツールを介して、Flex Gateway を設定および管理できます。 - [ライブネスチェックの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-readiness-liveness)​ - Flex Gateway では、ライブネスチェックコマンドを実行して、ゲートウェイの健全性をテストできます。さらに、Kubernetes にデプロイされた Flex Gateway には、指定された回数のチェックが失敗した後にポッドを自動的に再起動するライブネスプローブが含まれています。 - [PROXY プロトコルの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-proxy-protocol)​ - Flex Gateway では、マルチレイヤー接続を提供しているときにクライアント IP アドレスを保持するための PROXY プロトコルがサポートされています。 - [Anypoint CLI を使用した Jenkins Pipeline での Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-jenkins-cli)​ - Flex Gateway では、Anypoint CLI を使用して Jenkins Pipeline を作成し、ワークフローを自動化できます。 - [API Manager API を使用した Jenkins Pipeline での Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-jenkins-api)​ - Flex Gateway では、API Manager API を使用して Jenkins Pipeline を作成し、ワークフローを自動化できます。 # 接続モードでの Flex Gateway の設定 - [レプリカの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-rep-run)​ - Anypoint Flex Gateway では、Flex Gateway のインスタンスであるレプリカを作成できます。デフォルトでは、Flex Gateway は単一のレプリカとして実行します。複数のレプリカを実行することにより、スケーリング、ロードバランシング、高可用性を実現できます。 - [TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-tls-config)​ - Flex Gateway では、インバウンド方向とアウトバウンド方向の両方で通常の TLS および mTLS をサポートするように TLS コンテキストを設定できます。 - [共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config)​ - Flex Gateway では、分散キャッシュおよびレート制限ポリシーの共有ストレージを設定できます。 - [転送プロキシの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-forward-proxy)​ - Flex Gateway では、プロキシ接続経由で外部 HTTP 接続をルーティングするように転送プロキシを設定できます。 - [API Manager API ツールを使用した設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-manage-public-api)​ - Flex Gateway では、API Manager との通信に使用するコマンドラインツールである API Manager API ツールを介して、Flex Gateway を設定および管理できます。 - [ライブネスチェックの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-readiness-liveness)​ - Flex Gateway では、ライブネスチェックコマンドを実行して、ゲートウェイの健全性をテストできます。さらに、Kubernetes にデプロイされた Flex Gateway には、指定された回数のチェックが失敗した後にポッドを自動的に再起動するライブネスプローブが含まれています。 - [PROXY プロトコルの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-proxy-protocol)​ - Flex Gateway では、マルチレイヤー接続を提供しているときにクライアント IP アドレスを保持するための PROXY プロトコルがサポートされています。 - [Anypoint CLI を使用した Jenkins Pipeline での Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-jenkins-cli)​ - Flex Gateway では、Anypoint CLI を使用して Jenkins Pipeline を作成し、ワークフローを自動化できます。 - [API Manager API を使用した Jenkins Pipeline での Flex Gateway の自動化](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-jenkins-api)​ - Flex Gateway では、API Manager API を使用して Jenkins Pipeline を作成し、ワークフローを自動化できます。 # 接続モードでの Flex Gateway の転送プロキシの設定 Squid などの転送プロキシを使用すると、プロキシ接続経由で外部 HTTP Flex Gateway 接続をルーティングできます。 接続モードとローカルモードの両方で、YAML 設定ファイルを使用して転送プロキシを設定します。 次の図は、内部ネットワークが転送プロキシを使用して外部ネットワークと通信する方法を示しています。 ![アプリケーションからデータベース、さらにクラウドへ、またその逆のデータのジャーニーを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.10/_images/forward-proxy-diagram.png) この図のように、転送プロキシを使用している場合、内部ネットワークからの HTTP 通信は転送プロキシを通過する必要があります。 この例では、すべての HTTP API アップストリーム通信も転送プロキシを通過する必要があります。一部の接続が転送プロキシを使用せずに直接通信できるようにする方法についての詳細は、​[「noProxy パラメーター」](#noproxy-parameter)​を参照してください。

20%

25%

20%

Linux サービスとして Flex Gateway の転送プロキシを設定する

Docker コンテナで Flex Gateway の転送プロキシを設定する

Kubernetes クラスターでの Flex Gateway の転送プロキシの設定
## [](#転送プロキシ接続)転送プロキシ接続 HTTP 接続のみが転送プロキシ経由でルーティングされます。 次の接続が転送プロキシ経由でルーティングされます。 - Anypoint Platform への接続 - アウトバウンドポリシー接続 - アップストリームサービスへの接続 - HTTP (Fluent Bit) ログ接続 `noProxy`​ パラメーターを使用すると、転送プロキシを使用せずに直接接続するように HTTP および HTTPS 接続を設定できます。 転送プロキシを設定しても、次の接続は変更されません。 - 共有ストレージへの接続 - Lightweight Directory Access Protocol (LDAP) 接続 - 非 HTTP ログ接続 ## [](#noproxy-パラメーター)noProxy パラメーター `noProxy`​ パラメーターを追加すると、信頼する HTTP サービスが転送プロキシを使用せずに通信できるようになります。 たとえば、​`noProxy`​ を有効にすると、HTTP ログ接続とアップストリームサービスへの接続をリストして、それらを Flex Gateway に直接接続させることができます。 YAML 設定ファイルで ​`noProxy`​ パラメーターを使用して HTTP ログと通信している場合、正確なドメイン名をリストする必要があります。ドメインサフィックス (​`.svc.cluster.local`​ など) をリストすることはできません。すべての HTTP ログ接続に対して完全なドメイン名、​`.svc.cluster.local`​ をリストする必要があります。 次の図は、noProxy を使用した通信での違いを示しています。 ![「noProxy」が有効または無効になっている場合の内部接続間の違いを示しています](/mulesoft/current/ja-jp/gateway/1.10/_images/no-proxy-diagram.png) この図では、​`noProxy`​ を有効にしない場合、Flex Gateway は転送プロキシを使用して内部 API エンドポイントと通信します。​`noProxy`​ を有効にして API アップストリームドメインをリストした場合、Flex Gateway は内部 API エンドポイントと直接通信します。 ## [](#転送プロキシパラメーターの設定)転送プロキシパラメーターの設定 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: forward-proxy spec: forwardProxy: https: address: http://proxy:8888 basicAuth: username: password: noProxy: - fluentd - .svc.cluster.local ```
パラメーター 必須または省略可能 説明

https.address

必須

プロキシアドレス。

basicAuth

省略可能

認証ユーザー名とパスワードを指定する。

basicAuth.username

basicAuth​ が設定されている場合は必須

認証ユーザー名

basicAuth.Password

basicAuth​ が設定されている場合は必須

認証パスワード。

noProxy

省略可能

転送プロキシを使用せずに通信するドメイン名または IP アドレスを含む配列。各 IP アドレスは配列でリストされている必要があります。​noProxy​ では、CIDR ブロックはサポートされません。
## [](#linux)Linux サービスとして Flex Gateway の転送プロキシを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/forward-config.yaml ``` 2. 目的の転送プロキシ設定の詳細を使用してファイルを更新します。 3. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#docker)Docker コンテナで Flex Gateway の転送プロキシを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 目的の転送プロキシ設定の詳細を使用して YAML ファイルを作成して保存します。 5. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターでの Flex Gateway の転送プロキシの設定 Flex Gateway の転送プロキシを設定するには、転送プロキシの詳細を使用して新しい YAML 設定リソースを作成します。 Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#proxy-registration)転送プロキシ Flex Gateway の登録 Flex Gateway が、すべてのインターネット接続が転送プロキシを通過する内部ネットワークにある場合は、​[Flex Gateway を登録](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run)​するときに ​`--https-proxy`​ フラグを追加する必要があります。 `--https-proxy`​ フラグをプロキシの ​`address`​ パラメーターと共に追加します。 \--https-proxy=http://proxy:8888 `basicAuth`​ を有効にする場合は、​`username`​ パラメーターと ​`password`​ パラメーターを指定します。 \--https-proxy=http://:@proxy:8888 次のサンプル登録コマンドは、フラグの配置を示しています。 ```ssh flexctl register \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ --https-proxy=http://:@proxy:8888 \ my-gateway ```
Flex Gateway デプロイメントには関連する登録コマンドを使用してください。
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) # 接続モードでの Flex Gateway の転送プロキシの設定 Squid などの転送プロキシを使用すると、プロキシ接続経由で外部 HTTP Flex Gateway 接続をルーティングできます。 接続モードとローカルモードの両方で、YAML 設定ファイルを使用して転送プロキシを設定します。 次の図は、内部ネットワークが転送プロキシを使用して外部ネットワークと通信する方法を示しています。 ![これは、Flex Gateway へのすべての接続が最初に転送プロキシを通過する画像です](/mulesoft/current/ja-jp/gateway/1.8/_images/forward-proxy-diagram.png) この図のように、転送プロキシを使用している場合、内部ネットワークからの HTTP 通信は転送プロキシを通過する必要があります。 この例では、すべての HTTP API アップストリーム通信も転送プロキシを通過する必要があります。一部の接続が転送プロキシを使用せずに直接通信できるようにする方法についての詳細は、​[「noProxy パラメーター」](#noproxy-parameter)​を参照してください。

20%

25%

20%

Linux サービスとして Flex Gateway の転送プロキシを設定する

Docker コンテナで Flex Gateway の転送プロキシを設定する

Kubernetes クラスターでの Flex Gateway の転送プロキシの設定
## [](#転送プロキシ接続)転送プロキシ接続 HTTP 接続のみが転送プロキシ経由でルーティングされます。 次の接続が転送プロキシ経由でルーティングされます。 - Anypoint Platform への接続 - アウトバウンドポリシー接続 - アップストリームサービスへの接続 - HTTP (Fluent Bit) ログ接続 `noProxy`​ パラメーターを使用すると、転送プロキシを使用せずに直接接続するように HTTP および HTTPS 接続を設定できます。 転送プロキシを設定しても、次の接続は変更されません。 - 共有ストレージへの接続 - Lightweight Directory Access Protocol (LDAP) 接続 - 非 HTTP ログ接続 ## [](#noproxy-パラメーター)noProxy パラメーター `noProxy`​ パラメーターを追加すると、信頼する HTTP サービスが転送プロキシを使用せずに通信できるようになります。 たとえば、​`noProxy`​ を有効にすると、HTTP ログ接続とアップストリームサービスへの接続をリストして、それらを Flex Gateway に直接接続させることができます。 YAML 設定ファイルで ​`noProxy`​ パラメーターを使用して HTTP ログと通信している場合、正確なドメイン名をリストする必要があります。ドメインサフィックス (​`.svc.cluster.local`​ など) をリストすることはできません。すべての HTTP ログ接続に対して完全なドメイン名、​`.svc.cluster.local`​ をリストする必要があります。 次の図は、noProxy を使用した通信での違いを示しています。 ![これは、noProxy を有効にした場合としなかった場合の内部接続の違いを示す画像です](/mulesoft/current/ja-jp/gateway/1.8/_images/no-proxy-diagram.png) この図では、​`noProxy`​ を有効にしない場合、Flex Gateway は転送プロキシを使用して内部 API エンドポイントと通信します。​`noProxy`​ を有効にして API アップストリームドメインをリストした場合、Flex Gateway は内部 API エンドポイントと直接通信します。 ## [](#転送プロキシパラメーターの設定)転送プロキシパラメーターの設定 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: forward-proxy spec: forwardProxy: https: address: http://proxy:8888 basicAuth: username: password: noProxy: - fluentd - .svc.cluster.local ```
パラメーター 必須または省略可能 説明

https.address

必須

プロキシアドレス

basicAuth

省略可能

認証ユーザー名とパスワードを指定する

basicAuth.username

basicAuth​ が設定されている場合は必須

認証ユーザー名

basicAuth.Password

basicAuth​ が設定されている場合は必須

認証パスワード

noProxy

省略可能

転送プロキシを使用せずに通信するドメイン名を含む配列
## [](#linux)Linux サービスとして Flex Gateway の転送プロキシを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/forward-config.yaml ``` 2. 目的の転送プロキシ設定の詳細を使用してファイルを更新します。 3. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#docker)Docker コンテナで Flex Gateway の転送プロキシを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 目的の転送プロキシ設定の詳細を使用して YAML ファイルを作成して保存します。 5. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターでの Flex Gateway の転送プロキシの設定 Flex Gateway の転送プロキシを設定するには、転送プロキシの詳細を使用して新しい YAML 設定リソースを作成します。 Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#proxy-registration)転送プロキシ Flex Gateway の登録 Flex Gateway が、すべてのインターネット接続が転送プロキシを通過する内部ネットワークにある場合は、​[Flex Gateway を登録](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run)​するときに ​`--https-proxy`​ フラグを追加する必要があります。 `--https-proxy`​ フラグをプロキシの ​`address`​ パラメーターと共に追加します。 \--https-proxy=http://proxy:8888 `basicAuth`​ を有効にする場合は、​`username`​ パラメーターと ​`password`​ パラメーターを指定します。 \--https-proxy=http://:@proxy:8888 次のサンプル登録コマンドは、フラグの配置を示しています。 ```ssh flexctl register \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ --https-proxy=http://:@proxy:8888 \ my-gateway ```
Flex Gateway デプロイメントには関連する登録コマンドを使用してください。
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) # 接続モードでの Flex Gateway の転送プロキシの設定 Squid などの転送プロキシを使用すると、プロキシ接続経由で外部 HTTP Flex Gateway 接続をルーティングできます。 接続モードとローカルモードの両方で、YAML 設定ファイルを使用して転送プロキシを設定します。 次の図は、内部ネットワークが転送プロキシを使用して外部ネットワークと通信する方法を示しています。 ![アプリケーションからデータベース、さらにクラウドへ、またその逆のデータのジャーニーを示すフローチャート](/mulesoft/current/ja-jp/gateway/1.9/_images/forward-proxy-diagram.png) この図のように、転送プロキシを使用している場合、内部ネットワークからの HTTP 通信は転送プロキシを通過する必要があります。 この例では、すべての HTTP API アップストリーム通信も転送プロキシを通過する必要があります。一部の接続が転送プロキシを使用せずに直接通信できるようにする方法についての詳細は、​[「noProxy パラメーター」](#noproxy-parameter)​を参照してください。

20%

25%

20%

Linux サービスとして Flex Gateway の転送プロキシを設定する

Docker コンテナで Flex Gateway の転送プロキシを設定する

Kubernetes クラスターでの Flex Gateway の転送プロキシの設定
## [](#転送プロキシ接続)転送プロキシ接続 HTTP 接続のみが転送プロキシ経由でルーティングされます。 次の接続が転送プロキシ経由でルーティングされます。 - Anypoint Platform への接続 - アウトバウンドポリシー接続 - アップストリームサービスへの接続 - HTTP (Fluent Bit) ログ接続 `noProxy`​ パラメーターを使用すると、転送プロキシを使用せずに直接接続するように HTTP および HTTPS 接続を設定できます。 転送プロキシを設定しても、次の接続は変更されません。 - 共有ストレージへの接続 - Lightweight Directory Access Protocol (LDAP) 接続 - 非 HTTP ログ接続 ## [](#noproxy-パラメーター)noProxy パラメーター `noProxy`​ パラメーターを追加すると、信頼する HTTP サービスが転送プロキシを使用せずに通信できるようになります。 たとえば、​`noProxy`​ を有効にすると、HTTP ログ接続とアップストリームサービスへの接続をリストして、それらを Flex Gateway に直接接続させることができます。 YAML 設定ファイルで ​`noProxy`​ パラメーターを使用して HTTP ログと通信している場合、正確なドメイン名をリストする必要があります。ドメインサフィックス (​`.svc.cluster.local`​ など) をリストすることはできません。すべての HTTP ログ接続に対して完全なドメイン名、​`.svc.cluster.local`​ をリストする必要があります。 次の図は、noProxy を使用した通信での違いを示しています。 ![「noProxy」が有効または無効になっている場合の内部接続間の違いを示しています](/mulesoft/current/ja-jp/gateway/1.9/_images/no-proxy-diagram.png) この図では、​`noProxy`​ を有効にしない場合、Flex Gateway は転送プロキシを使用して内部 API エンドポイントと通信します。​`noProxy`​ を有効にして API アップストリームドメインをリストした場合、Flex Gateway は内部 API エンドポイントと直接通信します。 ## [](#転送プロキシパラメーターの設定)転送プロキシパラメーターの設定 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: forward-proxy spec: forwardProxy: https: address: http://proxy:8888 basicAuth: username: password: noProxy: - fluentd - .svc.cluster.local ```
パラメーター 必須または省略可能 説明

https.address

必須

プロキシアドレス。

basicAuth

省略可能

認証ユーザー名とパスワードを指定する。

basicAuth.username

basicAuth​ が設定されている場合は必須

認証ユーザー名

basicAuth.Password

basicAuth​ が設定されている場合は必須

認証パスワード。

noProxy

省略可能

転送プロキシを使用せずに通信するドメイン名または IP アドレスを含む配列。各 IP アドレスは配列でリストされている必要があります。​noProxy​ では、CIDR ブロックはサポートされません。
## [](#linux)Linux サービスとして Flex Gateway の転送プロキシを設定する 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/forward-config.yaml ``` 2. 目的の転送プロキシ設定の詳細を使用してファイルを更新します。 3. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#docker)Docker コンテナで Flex Gateway の転送プロキシを設定する
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、YAML ファイルの作成と保存のステップに進みます。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. 目的の転送プロキシ設定の詳細を使用して YAML ファイルを作成して保存します。 5. Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#kubernetes)Kubernetes クラスターでの Flex Gateway の転送プロキシの設定 Flex Gateway の転送プロキシを設定するには、転送プロキシの詳細を使用して新しい YAML 設定リソースを作成します。 Flex Gateway に直接のインターネットアクセスがない場合は、​[「転送プロキシ Flex Gateway の登録」](#proxy-registration)​を参照してください。 ## [](#proxy-registration)転送プロキシ Flex Gateway の登録 Flex Gateway が、すべてのインターネット接続が転送プロキシを通過する内部ネットワークにある場合は、​[Flex Gateway を登録](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run)​するときに ​`--https-proxy`​ フラグを追加する必要があります。 `--https-proxy`​ フラグをプロキシの ​`address`​ パラメーターと共に追加します。 \--https-proxy=http://proxy:8888 `basicAuth`​ を有効にする場合は、​`username`​ パラメーターと ​`password`​ パラメーターを指定します。 \--https-proxy=http://:@proxy:8888 次のサンプル登録コマンドは、フラグの配置を示しています。 ```ssh flexctl register \ --username= \ --password= \ --environment= \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ --https-proxy=http://:@proxy:8888 \ my-gateway ```
Flex Gateway デプロイメントには関連する登録コマンドを使用してください。
## [](#関連情報)関連情報 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) # 接続モードでの Flex Gateway 分散トレースの設定 OpenTelemetry により、分散システムでテレメトリーデータを計測、生成、収集、エクスポートするための統合された基準が提供されます。Flex Gateway では OpenTelemetry をサポートしているため、ゲートウェイで管理するすべての API トラフィックの分散トレースデータの生成を設定できます。このインテグレーションにより、API 要求フローをより詳しく視覚化できるため、システムの動作をより簡単に分析し、問題をトラブルシューティングして、Flex Gateway API と外部サービス間のインタラクションを理解できます。 Anypoint Monitoring Telemetry Exporter を使用することで、Flex Gateway トレースデータを Azure Monitor や Splunk HEC のほか、OpenTelemetry 互換ツールなどのサードパーティオブザーバビリティおよび分析プラットフォームに送信できます。この機能によって、エンドツーエンドオブザーバビリティを活用し、API トレースを他のシステムのデータと相関させ、環境の包括的なビューを構築できます。 ## [](#始める前に)始める前に Flex Gateway で OpenTelemetry を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 ## [](#flex-gateway-api-の分散トレースの設定)Flex Gateway API の分散トレースの設定 トレースにより、Flex Gateway API のインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れる API 要求を追跡し、API の実行の包括的なビューを提供します。 ## [](#yaml-設定リソースを使用した分散トレースの有効化と設定)YAML 設定リソースを使用した分散トレースの有効化と設定 この設定リソースを編集してから適用し、分散トレースを有効にします。この設定リソースは、すべての API インスタンスに適用されます。 次の例では、すべてのトレースのサンプリングを 0% に設定し、サンプリングはポリシーを使用して API ごとに設定されます。 ```yaml apiVersion: gateway.mulesoft.com/v1beta1 kind: Configuration metadata: name: tracing namespace: test-ns spec: tracing: provider: type: anypoint properties: timeout: 10s # sampling: # Set all sampling to 0% - this example shows enabling samping for the gateway, but only generating trace data for sampling on a per-API basis using the Tracing policy. client: 0 random: 0 overall: 0 # # Add labels such as these example labels, if you want to configure labels globally. You can also configure labels on a per-API basis by using the Tracing policy. labels: - name: c-env-tag type: environment keyName: FLEX_NAME defaultValue: DEFAULT_VAL - name: c-header-tag type: requestHeader keyName: :method defaultValue: DEFAULT_METHOD - name: c-literal-tag type: literal defaultValue: the-tag ``` ## [](#特定の-api-の分散トレースの設定)特定の API の分散トレースの設定 特定の API にトレースポリシーを適用することで、グローバルに設定された分散トレース設定を上書きできます。まずゲートウェイの分散トレースを有効にして設定する必要があります。その後、次のポリシーを計測する API に適用できます。 - [トレースポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tracing) # 接続モードでの Flex Gateway 向け API Manager の重要なメトリクスの表示 API Manager と Anypoint Monitoring は、アクティブな Flex Gateway API インスタンスでメトリクスを収集します。これらのメトリクスに関連したチャートを表示して、データを日付で絞り込むことができます。 API Manager で使用できるメトリクスは​**重要なメトリクス**​とみなされ、ここで説明されています。 **重要なメトリクス**​はすべての Anypoint Platform サブスクリプションで使用できます。​**\[Key Metrics (重要なメトリクス)\]**​ セクションに含まれないその他の Flex Gateway API メトリクスについては、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​ (Anypoint Integration Advanced パッケージまたは Titanium サブスクリプションのみ) を使用してください。Anypoint Monitoring に移動するには、Anypoint Platform から ​**\[Anypoint Monitoring\]**​ をクリックすることができます。

現在、API Manager の ​[Mule API Analytics]​ タブは Flex Gateway API では使用できません。​[Key Metrics (重要なメトリクス)]​ または Anypoint Monitoring でその他のメトリクスを使用してください。
## [](#重要なメトリクス)重要なメトリクス 1. Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のページで、​**\[API Manager\]**​ をクリックします。 **\[API Administration (API 管理)\]**​ ページが表示され、組織で使用できる API のリストが示されます。 3. API インスタンスをクリックします。 **\[API Summary (API の概要)\]**​ ページが表示され、API インスタンスの一般情報と状況が示されます。 Anypoint Monitoring で API インスタンスを表示するには、​**\[Key Metrics (重要なメトリクス)\]**​ セクションから ​**\[View more metrics in Anypoint Monitoring dashboard (Anypoint Monitoring ダッシュボードでその他のメトリクスを表示)\]**​ をクリックするか、Anypoint Monitoring に直接移動します。 **\[Key Metrics (重要なメトリクス)\]**​ セクションには 4 つのチャートがあります。API インスタンスでチャートが表示されない場合は、ブラウザーを更新してください。 ## [](#重要なメトリクスの意味)重要なメトリクスの意味 \[API Summary (API の概要)\] の ​**\[Key Metrics (重要なメトリクス)\]**​ セクションには、以下のチャートがあります。 Total Requests (要求総数) 選択された時間範囲での特定の API に対する要求数の合計。 データは 1 分ごとの増分量となります。 Total Policy Violations (ポリシー違反総数) ポリシー違反を返した要求の合計数。 データは 1 分ごとの増分量となります。 Total Errors (総エラー数) 選択された期間で発生した HTTP 応答コードの合計数。このメトリクスで数えられる応答コードは、400、401、402、403、404、405、408、409、410、411、412、413、415、416、417、420、422、429、500、502、503、504、504、510、511 です。 データは 1 分ごとの増分量となります。チャートでは、HTTP 応答コードは 4xx や 5xx のように省略して表示されます。 Average Response Time (平均応答時間) 選択された期間での特定の API に対する要求への応答時間の平均。 データは 1 分ごとの増分量となります。 ## [](#重要なメトリクスの期間の設定)重要なメトリクスの期間の設定 直前の一定期間 (過去 5 分間や過去 30 分間など) または特定の日時範囲に収集されたデータポイントを表示できます。カレンダーアイコンのドロップダウンを使用して、グラフに表示する期間を選択します。 ## [](#関連情報)関連情報 - [Flex Gateway API アラートの使用](https://docs.mulesoft.com/jp/gateway/1.10/flex-use-api-alerts) - [Anypoint Monitoring の基本アラートのセットアップ](https://docs.mulesoft.com/jp/monitoring/basic-alerts)。 - [組み込み API ダッシュボードの使用](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard) # 接続モードでの Flex Gateway 向け API Manager の重要なメトリクスの表示 API Manager と Anypoint Monitoring は、アクティブな Flex Gateway API インスタンスでメトリクスを収集します。これらのメトリクスに関連したチャートを表示して、データを日付で絞り込むことができます。 API Manager で使用できるメトリクスは​**重要なメトリクス**​とみなされ、ここで説明されています。 **重要なメトリクス**​はすべての Anypoint Platform サブスクリプションで使用できます。​**\[Key Metrics (重要なメトリクス)\]**​ セクションに含まれないその他の Flex Gateway API メトリクスについては、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​ (Anypoint Integration Advanced パッケージまたは Titanium サブスクリプションのみ) を使用してください。Anypoint Monitoring に移動するには、Anypoint Platform から ​**\[Anypoint Monitoring\]**​ をクリックすることができます。

現在、API Manager の ​[Mule API Analytics]​ タブは Flex Gateway API では使用できません。​[Key Metrics (重要なメトリクス)]​ または Anypoint Monitoring でその他のメトリクスを使用してください。
## [](#重要なメトリクス)重要なメトリクス 1. Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のページで、​**\[API Manager\]**​ をクリックします。 **\[API Administration (API 管理)\]**​ ページが表示され、組織で使用できる API のリストが示されます。 3. API インスタンスをクリックします。 **\[API Summary (API の概要)\]**​ ページが表示され、API インスタンスの一般情報と状況が示されます。 Anypoint Monitoring で API インスタンスを表示するには、​**\[Key Metrics (重要なメトリクス)\]**​ セクションから ​**\[View more metrics in Anypoint Monitoring dashboard (Anypoint Monitoring ダッシュボードでその他のメトリクスを表示)\]**​ をクリックするか、Anypoint Monitoring に直接移動します。 **\[Key Metrics (重要なメトリクス)\]**​ セクションには 4 つのチャートがあります。API インスタンスでチャートが表示されない場合は、ブラウザーを更新してください。 ## [](#重要なメトリクスの意味)重要なメトリクスの意味 \[API Summary (API の概要)\] の ​**\[Key Metrics (重要なメトリクス)\]**​ セクションには、以下のチャートがあります。 Total Requests (要求総数) 選択された時間範囲での特定の API に対する要求数の合計。 データは 1 分ごとの増分量となります。 Total Policy Violations (ポリシー違反総数) ポリシー違反を返した要求の合計数。 データは 1 分ごとの増分量となります。 Total Errors (総エラー数) 選択された期間で発生した HTTP 応答コードの合計数。このメトリクスで数えられる応答コードは、400、401、402、403、404、405、408、409、410、411、412、413、415、416、417、420、422、429、500、502、503、504、504、510、511 です。 データは 1 分ごとの増分量となります。チャートでは、HTTP 応答コードは 4xx や 5xx のように省略して表示されます。 Average Response Time (平均応答時間) 選択された期間での特定の API に対する要求への応答時間の平均。 データは 1 分ごとの増分量となります。 ## [](#重要なメトリクスの期間の設定)重要なメトリクスの期間の設定 直前の一定期間 (過去 5 分間や過去 30 分間など) または特定の日時範囲に収集されたデータポイントを表示できます。カレンダーアイコンのドロップダウンを使用して、グラフに表示する期間を選択します。 ## [](#関連情報)関連情報 - [Flex Gateway API アラートの使用](https://docs.mulesoft.com/jp/gateway/1.9/flex-use-api-alerts) - [Anypoint Monitoring の基本アラートのセットアップ](https://docs.mulesoft.com/jp/monitoring/basic-alerts)。 - [組み込み API ダッシュボードの使用](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard) # 接続モードでの Flex Gateway 向け Runtime Manager の API 状況の表示 Flex Gateway インスタンスに関連付けられた API に関する基本情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. API を確認するゲートウェイの名前をクリックします。 4. **\[APIs (API)\]**​ をクリックします。 各 API について、Runtime Manager に名前、バージョン、インスタンス ID、表示ラベル、追加された日付が表示されます。 詳細情報を確認して API に対するアクションを実行するには、​**\[View details (詳細を表示)\]**​ をクリックして API Manager にリダイレクトされるようにします。 # 接続モードでの Flex Gateway 向け Runtime Manager の API 状況の表示 Flex Gateway インスタンスに関連付けられた API に関する基本情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. API を確認するゲートウェイの名前をクリックします。 4. **\[APIs (API)\]**​ をクリックします。 各 API について、Runtime Manager に名前、バージョン、インスタンス ID、表示ラベル、追加された日付が表示されます。 詳細情報を確認して API に対するアクションを実行するには、​**\[View details (詳細を表示)\]**​ をクリックして API Manager にリダイレクトされるようにします。 # 接続モードでの Flex Gateway 設定キャッシュの設定 スケールアップ時間を短縮して弾力性を高められるように、Flex Gateway ではそのゲートウェイ設定を Redis 共有ストレージにキャッシュできます。Flex レプリカでは、レプリカごとに Anypoint Platform から設定を直接ダウンロードするのではなく、キャッシュされたゲートウェイ設定を使用します。デフォルトでは、設定キャッシュは有効になっていません。 Flex Gateway 設定キャッシュは次のように動作します。 1. 最初の Flex レプリカの開始後に、レプリカが Anypoint Platform から設定をダウンロードし、設定を暗号化して、Redis に保存します。 2. 後続のレプリカの開始後は、Anypoint Platform からダウンロードするのではなく、ローカルにキャッシュされた設定を使用します。 3. Anypoint Platform で Flex Gateway 設定が変更されると、レプリカは Anypoint Platform から必要な設定をダウンロードし、他のレプリカですぐに使用できるように Redis に保存します。 キャッシュが設定されていて Redis エラーが発生した場合、レプリカごとに Anypoint Platform から設定を直接ダウンロードします。Flex Gateway が Anypoint Platform から切断されている場合、Flex Gateway では接続が回復されるまでキャッシュされた設定を使用します。 ## [](#flex-gateway-設定キャッシュを有効化する)Flex Gateway 設定キャッシュを有効化する 1. Redis 共有ストレージが設定されていることを確認します。 詳細は、[接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-shared-storage-config)を参照してください。 2. `FLEX_DATASOURCE_CONTROL_NODE_ENABLED=true`​ 環境変数を有効にします。 # 接続モードでの Flex Gateway 設定キャッシュの設定 スケールアップ時間を短縮して弾力性を高められるように、Flex Gateway ではそのゲートウェイ設定を Redis 共有ストレージにキャッシュできます。Flex レプリカでは、レプリカごとに Anypoint Platform から設定を直接ダウンロードするのではなく、キャッシュされたゲートウェイ設定を使用します。デフォルトでは、設定キャッシュは有効になっていません。 Flex Gateway 設定キャッシュは次のように動作します。 1. 最初の Flex レプリカの開始後に、レプリカが Anypoint Platform から設定をダウンロードし、設定を暗号化して、Redis に保存します。 2. 後続のレプリカの開始後は、Anypoint Platform からダウンロードするのではなく、ローカルにキャッシュされた設定を使用します。 3. Anypoint Platform で Flex Gateway 設定が変更されると、レプリカは Anypoint Platform から必要な設定をダウンロードし、他のレプリカですぐに使用できるように Redis に保存します。 キャッシュが設定されていて Redis エラーが発生した場合、レプリカごとに Anypoint Platform から設定を直接ダウンロードします。Flex Gateway が Anypoint Platform から切断されている場合、Flex Gateway では接続が回復されるまでキャッシュされた設定を使用します。 ## [](#flex-gateway-設定キャッシュを有効化する)Flex Gateway 設定キャッシュを有効化する 1. Redis 共有ストレージが設定されていることを確認します。 詳細は、[接続モードでの Flex Gateway の共有ストレージの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-shared-storage-config)を参照してください。 2. `FLEX_DATASOURCE_CONTROL_NODE_ENABLED=true`​ 環境変数を有効にします。 # 接続モードでのタイムアウトの設定 Flex Gateway では、サービス品質を改善して計算リソースの無駄を減らせるように次のタイムアウトが提供されます。 - **ストリームアイドルタイムアウト**​ ストリームアイドルタイムアウトでは、ストリームがインバウンド (クライアントから Flex Gateway) またはアウトバウンド (Flex Gateway からアップストリームサービス) 方向のデータを受信せずにアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 300 秒のストリームタイムアウトが設定されています。 - **アップストリームアイドルタイムアウト**​ アップストリームアイドルタイムアウトでは、Flex Gateway とアップストリームサービス間のストリームが要求から要求までの間にアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 60 秒のアップストリームタイムアウトが設定されています。 - **Response Timeout (応答タイムアウト)**​ 応答タイムアウトでは、Flex Gateway がアップストリームサービスからの応答を待機する最大時間を設定できます。タイムアウトの時間は Flex Gateway によって最後の要求が送信された時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 15 秒の応答タイムアウトが設定されています。 これらのタイムアウトは以下によって設定できます。 - 環境変数: すべての API インスタンスが適用され、最も永続的な設定オプションです。 - 設定 YAML ファイル: すべての API インスタンスが適用され、調整が簡単です。 - ポリシー: 1 つの API インスタンスまたはアップストリームのみが適用され、きめ細かく設定でき、調整が簡単です。 ## [](#環境変数を使用したタイムアウトの設定)環境変数を使用したタイムアウトの設定 次の環境変数を使用してタイムアウトを設定します。 FLEX\_STREAM\_IDLE\_TIMEOUT\_SECONDS: 300 FLEX\_UPSTREAM\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS/FLEX\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS: 60 FLEX\_UPSTREAM\_RESPONSE\_TIMEOUT\_SECONDS: 15 目的の設定を使用して変数を編集します。 ## [](#yaml-設定リソースを使用したタイムアウトの設定)YAML 設定リソースを使用したタイムアウトの設定 この設定リソースを編集してから適用し、タイムアウトを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: timeouts-config spec: timeouts: upstreamConnectionIdleSeconds: 300 upstreamResponseSeconds: 15 streamIdleSeconds: 60 ``` ## [](#ポリシーを使用したタイムアウトの設定)ポリシーを使用したタイムアウトの設定 このポリシーを API インスタンスまたはアップストリームサービスに適用します。 - [ストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-stream-idle-timeout) - [アップストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-outbound-upstream-idle-timeout) - [応答タイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-response-timeout) # 接続モードでのタイムアウトの設定 Flex Gateway では、サービス品質を改善して計算リソースの無駄を減らせるように次のタイムアウトが提供されます。 - **ストリームアイドルタイムアウト**​ ストリームアイドルタイムアウトでは、ストリームがインバウンド (クライアントから Flex Gateway) またはアウトバウンド (Flex Gateway からアップストリームサービス) 方向のデータを受信せずにアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 300 秒のストリームタイムアウトが設定されています。 - **アップストリームアイドルタイムアウト**​ アップストリームアイドルタイムアウトでは、Flex Gateway とアップストリームサービス間のストリームが要求から要求までの間にアイドル状態を続けられる最大時間を設定できます。 デフォルトでは、すべての Flex Gateway API インスタンスに 60 秒のアップストリームタイムアウトが設定されています。 - **Response Timeout (応答タイムアウト)**​ 応答タイムアウトでは、Flex Gateway がアップストリームサービスからの応答を待機する最大時間を設定できます。タイムアウトの時間は Flex Gateway によって最後の要求が送信された時点で開始されます。 デフォルトでは、すべての Flex Gateway API インスタンスに 15 秒の応答タイムアウトが設定されています。 これらのタイムアウトは以下によって設定できます。 - 環境変数: すべての API インスタンスが適用され、最も永続的な設定オプションです。 - 設定 YAML ファイル: すべての API インスタンスが適用され、調整が簡単です。 - ポリシー: 1 つの API インスタンスまたはアップストリームのみが適用され、きめ細かく設定でき、調整が簡単です。 ## [](#環境変数を使用したタイムアウトの設定)環境変数を使用したタイムアウトの設定 次の環境変数を使用してタイムアウトを設定します。 FLEX\_STREAM\_IDLE\_TIMEOUT\_SECONDS: 300 FLEX\_UPSTREAM\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS/FLEX\_CONNECTION\_IDLE\_TIMEOUT\_SECONDS: 60 FLEX\_UPSTREAM\_RESPONSE\_TIMEOUT\_SECONDS: 15 目的の設定を使用して変数を編集します。 ## [](#yaml-設定リソースを使用したタイムアウトの設定)YAML 設定リソースを使用したタイムアウトの設定 この設定リソースを編集してから適用し、タイムアウトを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: timeouts-config spec: timeouts: upstreamConnectionIdleSeconds: 300 upstreamResponseSeconds: 15 streamIdleSeconds: 60 ``` ## [](#ポリシーを使用したタイムアウトの設定)ポリシーを使用したタイムアウトの設定 このポリシーを API インスタンスまたはアップストリームサービスに適用します。 - [ストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-stream-idle-timeout) - [アップストリームアイドルタイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-outbound-upstream-idle-timeout) - [応答タイムアウトポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-response-timeout) # 接続モードでのプロキシプロトコルの設定 ロードバランサーまたは他のプロキシサービスの背後に Flex Gateway がデプロイされるユースケースの場合、NAT または TCP プロキシの複数のレイヤーでクライアント IP アドレスが保持されるように PROXY プロトコルを設定します。 プロキシプロトコルでは、ロードバランサーまたは他のプロキシサービスは、クライアントアドレスと追加情報が含まれるプロキシプロトコルヘッダーを Flex Gateway に送信します。プロキシプロトコルについての詳細は、 [HAProxy の仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)​を参照してください。 プロキシプロトコルを有効にすると、Flex Gateway はプロキシプロトコルヘッダーの受信しかできなくなります。ヘッダーを送信するには、ロードバランサーまたは他のプロキシサービスでプロキシプロトコルがサポートされている必要があります。

20%

25%

20%

Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする

Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする

Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする
## [](#始める前に)始める前に Flex Gateway のプロキシプロトコルを有効にする前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) ## [](#linux)Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml ``` 2. プロキシプロトコル設定ファイルを使用してファイルを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#docker)Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、プロキシプロトコル設定の詳細を使用して ​`app`​ フォルダーに保存します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする Flex Gateway のプロキシプロトコルを設定するには、YAML 設定ファイルとプロキシプロトコルの詳細を使用して新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#関連情報)関連情報 - [HAProxy 仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) # 接続モードでのプロキシプロトコルの設定 ロードバランサーまたは他のプロキシサービスの背後に Flex Gateway がデプロイされるユースケースの場合、NAT または TCP プロキシの複数のレイヤーでクライアント IP アドレスが保持されるように PROXY プロトコルを設定します。 プロキシプロトコルでは、ロードバランサーまたは他のプロキシサービスは、クライアントアドレスと追加情報が含まれるプロキシプロトコルヘッダーを Flex Gateway に送信します。プロキシプロトコルについての詳細は、 [HAProxy の仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)​を参照してください。 プロキシプロトコルを有効にすると、Flex Gateway はプロキシプロトコルヘッダーの受信しかできなくなります。ヘッダーを送信するには、ロードバランサーまたは他のプロキシサービスでプロキシプロトコルがサポートされている必要があります。

20%

25%

20%

Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする

Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする

Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする
## [](#始める前に)始める前に Flex Gateway のプロキシプロトコルを有効にする前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-reg-run) ## [](#linux)Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml ``` 2. プロキシプロトコル設定ファイルを使用してファイルを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#docker)Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、プロキシプロトコル設定の詳細を使用して ​`app`​ フォルダーに保存します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする Flex Gateway のプロキシプロトコルを設定するには、YAML 設定ファイルとプロキシプロトコルの詳細を使用して新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#関連情報)関連情報 - [HAProxy 仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) # 接続モードでのプロキシプロトコルの設定 ロードバランサーまたは他のプロキシサービスの背後に Flex Gateway がデプロイされるユースケースの場合、NAT または TCP プロキシの複数のレイヤーでクライアント IP アドレスが保持されるように PROXY プロトコルを設定します。 プロキシプロトコルでは、ロードバランサーまたは他のプロキシサービスは、クライアントアドレスと追加情報が含まれるプロキシプロトコルヘッダーを Flex Gateway に送信します。プロキシプロトコルについての詳細は、 [HAProxy の仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)​を参照してください。 プロキシプロトコルを有効にすると、Flex Gateway はプロキシプロトコルヘッダーの受信しかできなくなります。ヘッダーを送信するには、ロードバランサーまたは他のプロキシサービスでプロキシプロトコルがサポートされている必要があります。

20%

25%

20%

Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする

Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする

Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする
## [](#始める前に)始める前に Flex Gateway のプロキシプロトコルを有効にする前に、次のタスクを完了します。 1. [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) 2. [Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) ## [](#linux)Linux サービスとして Flex Gateway のプロキシプロトコルを有効にする 1. Flex Gateway 設定ディレクトリに YAML 設定ファイルを作成します。 ```ssh sudo touch /usr/local/share/mulesoft/flex-gateway/conf.d/proxy-protocol-config.yaml ``` 2. プロキシプロトコル設定ファイルを使用してファイルを更新します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#docker)Docker コンテナで Flex Gateway のプロキシプロトコルを有効にする
Flex Gateway 設定ファイルを含むフォルダーのボリュームをすでに追加している場合、最後のステップまでスキップします。
1. Ctrl+C を押して、Flex Gateway とレプリカを停止します。 2. Flex Gateway 設定ファイルを含むディレクトリに ​`app`​ という名前のフォルダーを作成します。 3. 新しい ​`app`​ ディレクトリの追加ボリュームで Flex Gateway を再起動します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
4. YAML 設定ファイルを作成し、プロキシプロトコル設定の詳細を使用して ​`app`​ フォルダーに保存します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#kubernetes)Kubernetes クラスターで Flex Gateway のプロキシプロトコルを有効にする Flex Gateway のプロキシプロトコルを設定するには、YAML 設定ファイルとプロキシプロトコルの詳細を使用して新しいリソースを作成します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: config spec: proxyProtocol: enabled: true ``` ## [](#関連情報)関連情報 - [HAProxy 仕様](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) # 接続モードでの監視 接続モードで実行されている Flex Gateway では、Anypoint Platform を介して API を監視できます。Anypoint Platform を使用して、ログの設定や重要なメトリクスおよび分析の表示を行うことができます。 接続モードでの監視についての詳細は、次のタスクを参照してください。 - [メッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-message-log)​ - API Manager を介してメッセージログポリシーを API インスタンスに適用します。このポリシーにより、Flex Gateway API の基本的なログを表示できます。 - [API アラートの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-use-api-alerts)​ - 異常な API 動作を知らせるためのメール通知を受信するように API アラートを設定します。 - [サードパーティサービスの Flex Gateway ログ出力の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-third-party-logs-config)​ - Splunk などのサードパーティサービスによるコンシュームのログ出力を設定します。 - [Flex Gateway API の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-view-api-metrics)​ -API Manager を介してアクティブな Flex Gateway API のメトリクスを収集します。チャートを表示して、データを日付で絞り込むことができます。 - [Runtime Manager でのレプリカの状況の表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-replica-status)​ - Runtime Manager から Flex レプリカの接続状況を表示します。 - [Runtime Manager での Flex Gateway API の状況の表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-view-api-status)​ - Runtime Manager から Flex Gateway API の状況を表示します。 - [Runtime Manage でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager)​ - Runtime Manager から Flex Gateway ログの詳細を表示します。 - [Anypoint Monitoring でのログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-monitoring)​ - Anypoint Monitoring UI 内から Flex Gateway ログの詳細を表示します。 - [Flex Gateway ログ出力の無効化](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-disable-logs)​ - ローカル宣言型設定ファイルを使用して Anypoint Platform へのログ出力を無効化します。 # 接続モードでの監視 接続モードで実行されている Flex Gateway では、Anypoint Platform を介して API を監視できます。Anypoint Platform を使用して、ログの設定や重要なメトリクスおよび分析の表示を行うことができます。 接続モードでの監視についての詳細は、次のタスクを参照してください。 - [メッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-message-log)​ - API Manager を介してメッセージログポリシーを API インスタンスに適用します。このポリシーにより、Flex Gateway API の基本的なログを表示できます。 - [API アラートの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-use-api-alerts)​ - 異常な API 動作を知らせるためのメール通知を受信するように API アラートを設定します。 - [サードパーティサービスの Flex Gateway ログ出力の設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-third-party-logs-config)​ - Splunk などのサードパーティサービスによるコンシュームのログ出力を設定します。 - [Flex Gateway API の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-api-metrics)​ -API Manager を介してアクティブな Flex Gateway API のメトリクスを収集します。チャートを表示して、データを日付で絞り込むことができます。 - [Runtime Manager でのレプリカの状況の表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-replica-status)​ - Runtime Manager UI 内から Flex レプリカの接続状況を表示します。 - [Runtime Manager での Flex Gateway API の状況の表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-api-status)​ - Runtime Manager UI 内から Flex Gateway API の状況を表示します。 - [Runtime Manage でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-runtime-manager)​ - Runtime Manager UI 内から Flex Gateway ログの詳細を表示します。 - [Anypoint Monitoring でのログの表示](https://docs.mulesoft.com/jp/gateway/1.8/flex-view-logs-in-monitoring)​ - Anypoint Monitoring UI 内から Flex Gateway ログの詳細を表示します。 - [Flex Gateway ログ出力の無効化](https://docs.mulesoft.com/jp/gateway/1.8/flex-conn-disable-logs)​ - ローカル宣言型設定ファイルを使用して Anypoint Platform へのログ出力を無効化します。 # 接続モードでの監視 接続モードで実行されている Flex Gateway では、Anypoint Platform を介して API を監視できます。Anypoint Platform を使用して、ログの設定や重要なメトリクスおよび分析の表示を行うことができます。 接続モードでの監視についての詳細は、次のタスクを参照してください。 - [メッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-message-log)​ - API Manager を介してメッセージログポリシーを API インスタンスに適用します。このポリシーにより、Flex Gateway API の基本的なログを表示できます。 - [API アラートの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-use-api-alerts)​ - 異常な API 動作を知らせるためのメール通知を受信するように API アラートを設定します。 - [サードパーティサービスの Flex Gateway ログ出力の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-third-party-logs-config)​ - Splunk などのサードパーティサービスによるコンシュームのログ出力を設定します。 - [Flex Gateway API の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-view-api-metrics)​ -API Manager を介してアクティブな Flex Gateway API のメトリクスを収集します。チャートを表示して、データを日付で絞り込むことができます。 - [Runtime Manager でのレプリカの状況の表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-replica-status)​ - Runtime Manager から Flex レプリカの接続状況を表示します。 - [Runtime Manager での Flex Gateway API の状況の表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-view-api-status)​ - Runtime Manager から Flex Gateway API の状況を表示します。 - [Runtime Manage でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager)​ - Runtime Manager から Flex Gateway ログの詳細を表示します。 - [Anypoint Monitoring でのログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-monitoring)​ - Anypoint Monitoring UI 内から Flex Gateway ログの詳細を表示します。 - [Flex Gateway ログ出力の無効化](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-disable-logs)​ - ローカル宣言型設定ファイルを使用して Anypoint Platform へのログ出力を無効化します。 # 接続モードでユーザー名とパスワードを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーの​**ユーザー名**​と​**パスワード** ## [](#linux)ユーザー名とパスワードを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)ユーザー名とパスワードを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)ユーザー名とパスワードを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)ユーザー名とパスワードを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)ユーザー名とパスワードを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)ユーザー名とパスワードを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) # 接続モードでユーザー名とパスワードを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーの​**ユーザー名**​と​**パスワード** ## [](#linux)ユーザー名とパスワードを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)ユーザー名とパスワードを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)ユーザー名とパスワードを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)ユーザー名とパスワードを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)ユーザー名とパスワードを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)ユーザー名とパスワードを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) # 接続モードでユーザー名とパスワードを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 - Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーの​**ユーザー名**​と​**パスワード** ## [](#linux)ユーザー名とパスワードを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)ユーザー名とパスワードを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)ユーザー名とパスワードを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)ユーザー名とパスワードを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)ユーザー名とパスワードを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)ユーザー名とパスワードを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--username`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのユーザー名 - `--password`​ = Runtime Manager で​_「Read Servers (サーバーの参照)」_​権限と​_「Manage Servers (サーバーの管理)」_​権限を持つユーザーのパスワード - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --username= \ --password= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) # 接続モードで接続アプリケーションを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [接続アプリケーションの設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app) - 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#linux)接続アプリケーションを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)接続アプリケーションを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)接続アプリケーションを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)接続アプリケーションを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)接続アプリケーションを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)接続アプリケーションを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) # 接続モードで接続アプリケーションを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [接続アプリケーションの設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app) - 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.8/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#linux)接続アプリケーションを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)接続アプリケーションを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)接続アプリケーションを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)接続アプリケーションを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)接続アプリケーションを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)接続アプリケーションを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Disconnected (切断済み)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Connected (接続済み)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-reg-run) # 接続モードで接続アプリケーションを使用した登録と実行

20%

25%

20%

20%

Linux

コンテナ

Kubernetes

OpenShift
## [](#prereqs)始める前に Flex Gateway を登録する前に、以下のタスクを完了する必要があります。 - [接続アプリケーションの設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app) - 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) - 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存します。 - [Flex Gateway のインストール](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Anypoint Platform 管理者に Runtime Manager での​_「Manage Servers (サーバーの管理)」_​権限と​_「Read Servers (サーバーの参照)」_​権限を要求します。 - Anypoint Platform インスタンスから以下の情報を収集します。 - Flex Gateway を実行する組織の​**組織 ID** 組織 ID の見つけ方については、​[「組織 ID を見つける」](https://docs.mulesoft.com/jp/access-management/organization#find-your-organization-id)​を参照してください。 - Flex Gateway を実行する環境の​**環境 ID** 環境 ID の見つけ方については、​[「API Manager の外観」](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept#what-api-manager-looks-like)​を参照してください。 ## [](#linux)接続アプリケーションを使用した Linux サービスとしての登録と実行 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#flex-gateway-を登録する)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 ```ssh flexctl registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/usr/local/share/mulesoft/flex-gateway/conf.d \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#開始コマンド)開始コマンド 次のコマンドで Flex Gateway を開始します。 ```ssh sudo systemctl start flex-gateway ``` Flex Gateway サービスが正常に実行されていることを確認します。 ```ssh systemctl list-units flex-gateway* ``` `flex-gateway.service`​ の状況が ​`[active (アクティブ)]`​ である場合、Flex Gateway は正常に実行されています。 ```text UNIT LOAD ACTIVE SUB DESCRIPTION flex-gateway.service loaded active running Application ``` UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#container)接続アプリケーションを使用したコンテナでの登録と実行 Flex Gateway は、次のいずれかのコンテナで使用するために登録して実行できます。

15%

12%

Docker

Podman
### [](#docker)接続アプリケーションを使用した Docker コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-2)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-2)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#podman)接続アプリケーションを使用した Podman コンテナでの登録と実行 Anypoint Platform で Flex Gateway を登録するには、登録コマンドに続いて開始コマンドを入力する必要があります。各コマンドには、Anypoint Platform インスタンスに特有の情報が含まれ、​**実行前に更新する必要**​があります。必要な情報の見つけ方については、始める前に​[\[Before You Begin\]](<#Before You Begin>)​を参照してください。 #### [](#登録データの収集-2)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 #### [](#flex-gateway-を登録する-3)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。
flex-registration​ という名前 (または同様の名前) の新しいディレクトリを作成し、この新しいディレクトリで登録コマンドを実行します。コマンドにより、この場所に登録ファイルが作成されます。
```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 #### [](#開始コマンド-3)開始コマンド 登録コマンドを実行したディレクトリで、次の開始コマンドを実行します。 ```ssh podman run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8080:8080 \ docker.io/mulesoft/flex-gateway ```
-e ​FLEX_NAME​=<name-for-flex-replica> \ を含めて、Flex レプリカに割り当てる名前 (省略可能) を指定します。
UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
## [](#kubernetes)接続アプリケーションを使用した Kubernetes クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 次の手順を実行します。 1. [登録データの収集](#options-k8s) 2. [Flex Gateway を登録する](#reg-k8s) 3. [名前空間への Helm チャートのインストール](#deploy-k8s) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-k8s)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-k8s)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-k8s)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-k8s)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-k8s)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#openshift)接続アプリケーションを使用した OpenShift クラスターでの登録と実行 Flex Gateway を登録し、Helm を使用して Flex Gateway をクラスターのノードにデプロイし、Anypoint Platform に接続します。デプロイしたら、Runtime Manager を使用して、ゲートウェイが存在していて、Anypoint Platform に接続されていることを確認します。 ロールベースのアクセス制御 (RBAC) を有効にする Kubernetes クラスターに Flex Gateway をデプロイする場合、Flex Gateway で使用されるカスタムリソース定義 (CRD) のインストールを許可するクラスターレベルの権限が必要です。 OpenShift では、​`cluster-admin`​ ロールによってこのレベルのアクセスが提供されます。 コマンドラインからの OpenShift の手順と Kubernetes の手順は同じです。 次の手順を実行します。 1. [登録データの収集](#options-openshift) 2. [Flex Gateway を登録する](#reg-openshift) 3. [名前空間への Helm チャートのインストール](#deploy-openshift) 通常、接続モードの Flex Gateway は、クラスター外からのトラフィックを受信するイングレスまたはエッジ API ゲートウェイとして機能します。Flex Gateway は、内部 (east-west) サービスのスタンドアロンゲートウェイとして機能することもできます。 大部分の管理は、Anypoint Platform 内で行われます。 - API をクラスターにデプロイする。 - ポリシーと他の設定を適用する。 - リソース (設定とサービス​_以外_​) を作成する。 接続モードでは、​`kubectl apply`​ でリソースを作成できますが、次のリソース種別に限定されます。 ​`tls`​、​`tls-inbound`​、​`tls-outbound`​ 種別の Configuration、Service、Extension、PolicyBinding。リソースについての詳細は、[宣言型設定リファレンスガイド](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-configuration-reference-guide)を参照してください。 ### [](#options-openshift)登録データの収集 Flex Gateway インスタンスを登録する前に、次の登録コマンドオプションの情報を収集します。 - `--client-id`​ = Access Management で設定した接続アプリケーションの ID - `--client-secret`​ = Access Management で設定した接続アプリケーションのシークレット - `--environment`​ = Flex Gateway を実行する Anypoint Platform の環境の環境 ID - `--organization`​ = Anypoint Platform の組織 ID - `--split`​ (省略可能) = 登録情報を複数のファイルに分割するかどうかを決定するフラグ。デフォルト値は ​`false`​ です。 `split`​ が ​`true`​ に設定されている場合、登録情報は ​`registration.yaml`​ と ​`certificate.yaml`​ の 2 つのファイルに分割されます。​`false`​ の場合、すべての登録情報は 1 つの ​`registration.yaml`​ ファイルに含まれます。 - `--output-directory`​ (省略可能) = 登録情報を出力するディレクトリ - `my-gateway`​ = ゲートウェイクラスターに割り当てる名前 ### [](#reg-openshift)Flex Gateway を登録する コマンドオプションについて収集したデータを使用して、Flex Gateway インスタンスを登録します。 次のいずれかのコンテナランタイムを使用して登録できます。 **Docker** Docker を使用して登録するには、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration -u $UID mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 **Podman** Podman を使用して登録するには、次のコマンドを実行します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/registration:Z -u $UID docker.io/mulesoft/flex-gateway \ registration create \ --client-id= \ --client-secret= \ --environment= \ --connected=true \ --organization= \ --output-directory=/registration \ my-gateway ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。
欧州では、​--anypoint-url=https://eu1.anypoint.mulesoft.com​ フラグをコマンドに追加する必要があります。
出力ディレクトリに次の新しい登録ファイルが含まれます。 - `registration.yaml` - `certificate.yaml`​ (​`split`​ 登録パラメーターが ​`true`​ に設定されている場合にのみ生成。それ以外の場合、証明書情報は ​`registration.yaml`​ に含まれる)
生成されるこれらのファイルは、Flex Gateway を接続するためのログイン情報です。これらのファイルを消失すると、Flex Gateway を接続できなくなります。
UI でゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの状況が ​**\[Not Running (停止中)\]**​ であることを確認します。必要に応じて、ページを更新します。 ### [](#deploy-openshift)名前空間への Helm チャートのインストール Helm チャートで Flex Gateway、監視ツール、アプリケーションをインストールします。 Helm バージョン 3.0.0 以降が必要です。 設定オプションについては、​[Helm チャート設定](#helm-options-openshift)​を参照してください。 1. チャートの ​`flex-gateway`​ という名前の Helm リポジトリを追加します。 ```helm helm repo add flex-gateway https://flex-packages.anypoint.mulesoft.com/helm ``` このコマンドにより、リポジトリが追加されます。その名前の Helm リポジトリがすでにマシンに存在する場合はこのプロセスはスキップされます。 - 新しいリポジトリの場合、コマンドで次のメッセージが返されます。 "flex-gateway" has been added to your repositories - リポジトリがすでに存在する場合、コマンドで次のメッセージが返されます。 "flex-gateway" already exists with the same configuration, skipping 2. `helm repo up`​ を実行します。 コマンドで次のメッセージが返されます。 Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "flex-gateway" chart repository Update Complete. ⎈Happy Helming!⎈ マシンに複数の Helm リポジトリがある場合、ターミナルウィンドウのメッセージにすべてのリポジトリがリストされます。 3. 接続モードでゲートウェイをデプロイするための Helm コマンドを実行します。 ```helm helm -n gateway upgrade -i --create-namespace \ ingress flex-gateway/flex-gateway \ --set gateway.mode=connected \ --set-file registration.content=registration.yaml ``` このコマンドにより、​`gateway`​ 名前空間と ​`ingress`​ という名前のリリースが作成されます (これらが存在しない場合)。名前空間とリリースには、任意の名前を使用できます。Helm リポジトリ名と Helm チャート名のコマンド構文は、​`/`​ です。 Helm チャートのデフォルトのデフォルトはローカルモードであるため、コマンドで ​`--set gateway.mode=connected`​ を使用します。 Flex Gateway をインストールすると、デフォルトでサービス種別 ​`LoadBalancer`​ が作成されます。クラウドでロードバランサーを作成するには適切な権限が割り当てられている必要があります。ロードバランサーがプロビジョニングされないか、プロビジョニングプロセスで問題が発生する場合は、インストール時に ​`service.type`​ プロパティを変更して別の種別を選択する必要があります。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
このコマンドが成功すると、​`ingress`​ リリースへのアップグレードを示すメッセージが出力されます。 Release "ingress" does not exist. Installing it now. NAME: ingress LAST DEPLOYED: Mon Mar 20 21:36:19 2023 NAMESPACE: gateway STATUS: deployed REVISION: 1 TEST SUITE: None 同じ名前空間、リポジトリ、チャート名でこのコマンドを実行するたびに、​`ingress`​ リリースの ​`REVISION`​ 値が ​`1`​ ずつ増加します。たとえば、2 回コマンドを実行すると、新しいリビジョン番号が表示されます (​`REVISION: 2`​)。​`LAST DEPLOYED`​ には、そのリビジョンの日付が反映されます。 UI で新しいゲートウェイを検索するには、Runtime Manager の左側のナビゲーションで ​**\[← Flex Gateway\]**​ をクリックします。ゲートウェイの現在の状況が ​**\[Running (実行中)\]**​ であることを確認します。必要に応じて、ページを更新します。
30 日経過すると、停止または削除されたゲートウェイが Runtime Manager UI から削除されます。それまでは、実行または接続されていなくても UI にゲートウェイが引き続きリストされます。
### [](#helm-options-openshift)Helm チャート設定 新しい値でデフォルトの Helm 設定 (CPU やメモリ設定の ​`resource`​ 値など) を変更するには、「​[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings). For additional Helm chart configurations, see [Kubernetes デプロイメントの管理](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-management)​」を参照してください。 Flex Gateway デプロイメントの Helm チャートを変更する前に、デフォルトの Helm チャート設定を確認してください。 - [ArtifactHUB](https://artifacthub.io/packages/helm/flex-gateway/flex-gateway)​ の ​**flex-gateway**​ ページを開く - ターミナルウィンドウから ​`helm show values /`​ を実行します。 例: ```kubernetes helm show values flex-gateway/flex-gateway ``` この例では、同じ名前のリポジトリおよびチャートの​_デフォルト_​値を返します。 Helm チャートの ​`README`​ を表示するには、ターミナルウィンドウから ​`helm show readme /`​ を実行します。 例: ```kubernetes helm show readme flex-gateway/flex-gateway ``` ## [](#関連情報)関連情報 - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) # 接続モードの Runtime Manager でのランタイムログの表示 Runtime Manager を使用して、Flex Gateway のランタイムログを表示します。Runtime Manager では、ログ内のキーワードを検索したり、​**\[Replica (レプリカ)\]**​、​**\[Time Range (時間範囲)\]**​、​**\[Log Level (ログレベル)\]**​ で絞り込んだりできます。 Runtime Manager は、Flex Gateway ごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、Flex Gateway ごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、Anypoint Monitoring を使用してこのログにアクセスするか (Titanium サブスクリプションが必要)、サードパーティログサービスを使用します。 Runtime Manager で Flex Gateway ランタイムログにアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Anypoint Monitoring での自己管理ランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-monitoring) - [サードパーティサービスの Flex Gateway ログ出力の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-third-party-logs-config) # 接続モードの Runtime Manager でのランタイムログの表示 Runtime Manager を使用して、Flex Gateway のランタイムログを表示します。Runtime Manager では、ログ内のキーワードを検索したり、​**\[Replica (レプリカ)\]**​、​**\[Time Range (時間範囲)\]**​、​**\[Log Level (ログレベル)\]**​ で絞り込んだりできます。 Runtime Manager は、Flex Gateway ごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、Flex Gateway ごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、Anypoint Monitoring を使用してこのログにアクセスするか (Titanium サブスクリプションが必要)、サードパーティログサービスを使用します。 Runtime Manager で Flex Gateway ランタイムログにアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Anypoint Monitoring での自己管理ランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-monitoring) - [サードパーティサービスの Flex Gateway ログ出力の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-third-party-logs-config) # 標準出力ログの表示 Flex Gateway ではレプリカごとに標準出力ログが維持されます。外部サービスがいつ実行されているかや、API 要求が Flex Gateway にいつ到着しているかなどの確認で追加のログ出力が不要な場合は標準出力ログを使用してすばやくログを確認します。 標準出力ログを表示するためにログ出力を設定する必要はありません。ただし、アクセスログを標準出力ログに表示するには、監視対象の API にメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-third-party-logs-config#configure-access-logs)​を参照してください。 追加の Fluent Bit を設定して、カスタムログ出力を有効にしてログレベル情報をカスタマイズすることもできます。追加のログを設定するには、[ローカルモードでの Flex Gateway の外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-third-party-logs-config)を参照してください。 追加のログ出力を表示するには、そのログ出力を表示するための適切な方法を見つけます。次のコマンドでは、標準出力ログのみが表示されます。 ## [](#ログの表示)ログの表示 レプリカの標準出力ログを表示するには、次のいずれかのコマンドを実行します。 Linux: ```ssh journalctl -u flex-gateway* ``` Docker: ```ssh docker logs -f ``` Kubernetes: ```ssh kubectl logs -f ``` ## [](#関連情報)関連情報 - [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual) # 標準出力ログの表示 Flex Gateway ではレプリカごとに標準出力ログが維持されます。外部サービスがいつ実行されているかや、API 要求が Flex Gateway にいつ到着しているかなどの確認で追加のログ出力が不要な場合は標準出力ログを使用してすばやくログを確認します。 標準出力ログを表示するためにログ出力を設定する必要はありません。ただし、アクセスログを標準出力ログに表示するには、監視対象の API にメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-third-party-logs-config#configure-access-logs)​を参照してください。 追加の Fluent Bit を設定して、カスタムログ出力を有効にしてログレベル情報をカスタマイズすることもできます。追加のログを設定するには、[ローカルモードでの Flex Gateway の外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-third-party-logs-config)を参照してください。 追加のログ出力を表示するには、そのログ出力を表示するための適切な方法を見つけます。次のコマンドでは、標準出力ログのみが表示されます。 ## [](#ログの表示)ログの表示 レプリカの標準出力ログを表示するには、次のいずれかのコマンドを実行します。 Linux: ```ssh journalctl -u flex-gateway* ``` Docker: ```ssh docker logs -f ``` Kubernetes: ```ssh kubectl logs -f ``` ## [](#関連情報)関連情報 - [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual) # 標準出力ログの表示 Flex Gateway ではレプリカごとに標準出力ログが維持されます。外部サービスがいつ実行されているかや、API 要求が Flex Gateway にいつ到着しているかなどの確認で追加のログ出力が不要な場合は標準出力ログを使用してすばやくログを確認します。 標準出力ログを表示するためにログ出力を設定する必要はありません。ただし、アクセスログを標準出力ログに表示するには、監視対象の API にメッセージログポリシーを適用する必要があります。メッセージログポリシーを適用するには、​[「アクセスログの設定」](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-third-party-logs-config#configure-access-logs)​を参照してください。 追加の Fluent Bit を設定して、カスタムログ出力を有効にしてログレベル情報をカスタマイズすることもできます。追加のログを設定するには、[ローカルモードでの Flex Gateway の外部ログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-third-party-logs-config)を参照してください。 追加のログ出力を表示するには、そのログ出力を表示するための適切な方法を見つけます。次のコマンドでは、標準出力ログのみが表示されます。 ## [](#ログの表示)ログの表示 レプリカの標準出力ログを表示するには、次のいずれかのコマンドを実行します。 Linux: ```ssh journalctl -u flex-gateway* ``` Docker: ```ssh docker logs -f ``` Kubernetes: ```ssh kubectl logs -f ``` ## [](#関連情報)関連情報 - [Fluent Bit のドキュメント](https://docs.fluentbit.io/manual) # 正規表現の互換性の問題のトラブルシューティング 正規表現を使用した場合に発生する互換性の問題をトラブルシューティングします。 - [否定先読み](#troubleshoot-negative-lookaheads) ## [](#troubleshoot-negative-lookaheads)否定先読み Flex Gateway は、否定先読みがサポートされていない [Google RE2 正規表現構文](https://github.com/google/re2/wiki/Syntax)​に準拠します。 # 正規表現の互換性の問題のトラブルシューティング 正規表現を使用した場合に発生する互換性の問題をトラブルシューティングします。 - [否定先読み](#troubleshoot-negative-lookaheads) ## [](#troubleshoot-negative-lookaheads)否定先読み Flex Gateway は、否定先読みがサポートされていない [Google RE2 正規表現構文](https://github.com/google/re2/wiki/Syntax)​に準拠します。 # 正規表現の互換性の問題のトラブルシューティング 正規表現を使用した場合に発生する互換性の問題をトラブルシューティングします。 - [否定先読み](#troubleshoot-negative-lookaheads) ## [](#troubleshoot-negative-lookaheads)否定先読み Flex Gateway は、否定先読みがサポートされていない [Google RE2 正規表現構文](https://github.com/google/re2/wiki/Syntax)​に準拠します。 # 準備状況プローブまたはライブネスプローブの設定 Flex Gateway では、信頼性と効率を確保するための 2 つの方法がサポートされます。 - 準備状況プローブでは、ゲートウェイインスタンスが正しく設定され、受信トラフィックへの準備が整っているかどうかをテストします。これにより、部分的に設定された API によってエンドユーザーが影響を受けないようにします。詳細は、​[準備状況プローブの設定](#configure-a-readiness-probe)​を参照してください。 - ライブネスプローブでは、ゲートウェイインスタンスが稼働可能かどうかをテストします。これにより、クラッシュや他の障害によるダウンタイムを最小限に抑えます。詳細は、​[ライブネスプローブの設定](#configure-a-liveness-probe)​を参照してください。 ## [](#configure-a-readiness-probe)準備状況プローブの設定 Flex Gateway インスタンスで受信トラフィックへの準備が整っているかどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=readiness ``` Flex Gateway インスタンスで受信トラフィックを受信する準備が整っている場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 Flex Gateway が開始されると、その準備状況は ​`false`​ になります。この状況は、次の条件が満たされると ​`true`​ に変わります。 - API インスタンスがデプロイされた (1 つ以上の API が設定されている必要があります) - ポリシーが初期化された 設定の変更を実行中のゲートウェイに適用しても、準備状況に影響はありません。これにより、インスタンスは、設定の更新中であってもトラフィックを継続的に受信することができます。 特定の環境での準備状況プローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定された準備状況プローブが含まれています。準備状況プローブは ​`flexctl probe --check=readiness --allow-api-errors --allow-envoy-errors --allow-policy-errors`​ を 10 秒間隔で自動的に実行します。 準備状況プローブには、次のデフォルト値があります。 ```helm readinessProbe: exec: command: - flexctl - probe - --check=readiness - --allow-api-errors - --allow-envoy-errors - --allow-policy-errors initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 2 timeoutSeconds: 5 ```

パラメーター

説明

exec.command

準備状況プローブコマンド

--allow-api-errors

API インスタンスでのエラーを許可するフラグ

--allow-envoy-errors

Envoy 設定エラーを許可するフラグ

--allow-policy-errors

ポリシー設定エラーを許可するフラグ

initialDelaySeconds

起動後、最初の準備状況プローブを実行するまで待機する時間 (秒単位)

periodSeconds

各準備状況プローブ間の間隔 (秒単位)

failureThreshold

Kubernetes 準備状況を ​false​ に設定するまでの失敗した準備状況プローブ数

timeoutSeconds

準備状況プローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings)を参照してください。 デフォルトの Kubernetes 準備状況プローブは、エラーを許容するように設定されています。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。エラーの許容範囲についての詳細は、​[エラーの許容範囲の設定](#configure-error-tolerance)​を参照してください。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトの準備状況プローブは含まれません。ただし、準備状況プローブコマンドを手動で実行したり、外部サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes 準備状況プローブ以外では、MuleSoft はサードパーティの準備状況プローブのサポートを提供しません。 ### [](#外部コンポーネントの設定)外部コンポーネントの設定 準備状況を照会するように外部コンポーネントを設定します。たとえば、ロードバランサーの背後で実行される AWS 仮想マシンでは、準備状況クエリを状態チェックとして設定します。準備状況 API を外部コンポーネントに公開するには、次の設定を Flex Gateway インスタンスに適用します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: probe spec: probe: enabled: true port: 3000 ``` YAML 設定スニペットを適用すると、準備状況 API で ​`GET`​ 要求に応答することができます。 `http://:/probes/readiness?allowEnvoyErrors=&allowAPIErrors=&allowPolicyErrors=` ### [](#configure-error-tolerance)エラーの許容範囲の設定 エラーを許容しないまたは許容するように準備状況プローブを設定できます。エラーを許容しない場合、誤って設定されたゲートウェイインスタンスでは、準備状況が ​`true`​ に達することはありません。エラーを許容するデプロイメントでは、設定エラーが発生した (たとえば、ポリシーを誤って設定した) 場合、API インスタンスおよびポリシーがデプロイされた後も準備状況は ​`true`​ のままです。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。 準備状況 CLI コマンドでは、エラーの許容範囲を設定する次のフラグが提供されます。 - `--allow-api-errors` - `--allow-envoy-errors` - `--allow-policy-errors` 準備状況 API への HTTP 要求を介して準備状況を照会するデプロイメントでは、次のクエリパラメーターを使用します。 - `allowEnvoyErrors=false` - `allowAPIErrors=false` - `allowPolicyErrors=false` ### [](#シャットダウン中の準備状況のプローブ)シャットダウン中の準備状況のプローブ ゲートウェイで ​`Connection: close`​ ヘッダーが送信された場合、準備状況はシャットダウン中もプローブされます。​`SIGTERM`​ シグナルでは、ダウンストリーム接続に再接続の信号を送信することで、ダウンストリーム接続のドレーンを開始します。デフォルトのドレーン期間は 25 秒で、その後、Flex Gateway は適切に終了します。 ドレーン期間を変更するには、Docker および Linux では ​`FLEX_SERVICE_ENVOY_DRAIN_TIME`​ 環境変数、Kubernetes Helm チャートでは ​`gateway.drainSeconds`​ オプションを使用できます。 Flex Gateway では、ドレーン期間よりも 5 秒長い 30 秒のグレースフルシャットガウンが事前設定されています。ドレーン期間を増加する場合は、​`TimeoutStopSec`​ (Linux) または ​`terminationGracePeriodSeconds`​ (Kubernetes) を使用してシャットダウン期間も増加します。シャットダウン期間はドレーン期間を超える必要があります。 Kubernetes のデフォルトの準備状況プローブは、失敗しきい値 2 で 10 秒ごとに実行され、20 秒以内にシャットダウンを検出できます。これにより、シャットダウン中のインスタンスに新しいトラフィックは送信されなくなります。AWS ロードバランサーなどの他の環境で準備状況プローブの同様の設定を使用します。 ## [](#configure-a-liveness-probe)ライブネスプローブの設定 Flex Gateway インスタンスが稼働可能かどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=liveness ``` Flex Gateway インスタンスが稼働可能な場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 ライブネスプローブコマンドを手動で実行することも、自動的に実行されるようにコマンドを設定することもできます。デフォルトでは、Flex Gateway の Kubernetes デプロイメントには自動ライブネスプローブが設定されています。デフォルトのプローブは、ライブネスプローブコマンドを定期的に実行し、指定された回数の失敗の後に Flex Gateway ポッドを自動的に再起動します。 特定の環境でのライブネスプローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定されたライブネスプローブが含まれています。ライブネスプローブは、​`flexctl probe --check=liveness`​ を 10 秒間隔で自動的に実行し、テストが 5 回失敗した後に稼働していないポッドを再起動します。 ライブネスプローブはデフォルトで次の値で設定されています。 ```helm livenessProbe: exec: command: - flexctl - probe - --check=liveness initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 5 timeoutSeconds: 1 ```

パラメーター

説明

exec.command

ライブネスプローブコマンド

initialDelaySeconds

起動後、最初のライブネスプローブを実行するまで待機する時間 (秒単位)

periodSeconds

各ライブネスプローブ間の間隔 (秒単位)

failureThreshold

Kubernetes ポッドが再起動されるまでの失敗したライブネスプローブ数

timeoutSeconds

ライブネスプローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings)を参照してください。 Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトのライブネスプローブは含まれません。ただし、ライブネスプローブコマンドを手動で実行したり、サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes ライブネスプローブ以外では、MuleSoft はサードパーティのライブネスプローブのサポートを提供しません。 Docker でライブネスプローブコマンドを実行する 1 つの方法は、​`docker run`​ コマンドで ​`HEALTHCHECK`​ を設定することです。詳細は、 [「Docker run HEALTHCHECK」](https://docs.docker.com/engine/reference/run/#healthcheck)​を参照してください。 ## [](#関連情報)関連情報 - [Liveness Probe、Readiness Probe および Startup Probe を使用する](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)​。 - [状態チェックポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-health-check) # 準備状況プローブまたはライブネスプローブの設定 Flex Gateway では、信頼性と効率を確保するための 2 つの方法がサポートされます。 - 準備状況プローブでは、ゲートウェイインスタンスが正しく設定され、受信トラフィックへの準備が整っているかどうかをテストします。これにより、部分的に設定された API によってエンドユーザーが影響を受けないようにします。詳細は、​[準備状況プローブの設定](#configure-a-readiness-probe)​を参照してください。 - ライブネスプローブでは、ゲートウェイインスタンスが稼働可能かどうかをテストします。これにより、クラッシュや他の障害によるダウンタイムを最小限に抑えます。詳細は、​[ライブネスプローブの設定](#configure-a-liveness-probe)​を参照してください。 ## [](#configure-a-readiness-probe)準備状況プローブの設定 Flex Gateway インスタンスで受信トラフィックへの準備が整っているかどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=readiness ``` Flex Gateway インスタンスで受信トラフィックを受信する準備が整っている場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 Flex Gateway が開始されると、その準備状況は ​`false`​ になります。この状況は、次の条件が満たされると ​`true`​ に変わります。 - API インスタンスがデプロイされた (1 つ以上の API が設定されている必要があります) - ポリシーが初期化された 設定の変更を実行中のゲートウェイに適用しても、準備状況に影響はありません。これにより、インスタンスは、設定の更新中であってもトラフィックを継続的に受信することができます。 特定の環境での準備状況プローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定された準備状況プローブが含まれています。準備状況プローブは ​`flexctl probe --check=readiness --allow-api-errors --allow-envoy-errors --allow-policy-errors`​ を 10 秒間隔で自動的に実行します。 準備状況プローブには、次のデフォルト値があります。 ```helm readinessProbe: exec: command: - flexctl - probe - --check=readiness - --allow-api-errors - --allow-envoy-errors - --allow-policy-errors initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 2 timeoutSeconds: 5 ```

パラメーター

説明

exec.command

準備状況プローブコマンド

--allow-api-errors

API インスタンスでのエラーを許可するフラグ

--allow-envoy-errors

Envoy 設定エラーを許可するフラグ

--allow-policy-errors

ポリシー設定エラーを許可するフラグ

initialDelaySeconds

起動後、最初の準備状況プローブを実行するまで待機する時間 (秒単位)

periodSeconds

各準備状況プローブ間の間隔 (秒単位)

failureThreshold

Kubernetes 準備状況を ​false​ に設定するまでの失敗した準備状況プローブ数

timeoutSeconds

準備状況プローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings)を参照してください。 デフォルトの Kubernetes 準備状況プローブは、エラーを許容するように設定されています。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。エラーの許容範囲についての詳細は、​[エラーの許容範囲の設定](#configure-error-tolerance)​を参照してください。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトの準備状況プローブは含まれません。ただし、準備状況プローブコマンドを手動で実行したり、外部サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes 準備状況プローブ以外では、MuleSoft はサードパーティの準備状況プローブのサポートを提供しません。 ### [](#外部コンポーネントの設定)外部コンポーネントの設定 準備状況を照会するように外部コンポーネントを設定します。たとえば、ロードバランサーの背後で実行される AWS 仮想マシンでは、準備状況クエリを状態チェックとして設定します。準備状況 API を外部コンポーネントに公開するには、次の設定を Flex Gateway インスタンスに適用します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: probe spec: probe: enabled: true port: 3000 ``` YAML 設定スニペットを適用すると、準備状況 API で ​`GET`​ 要求に応答することができます。 `http://:/probes/readiness?allowEnvoyErrors=&allowAPIErrors=&allowPolicyErrors=` ### [](#configure-error-tolerance)エラーの許容範囲の設定 エラーを許容しないまたは許容するように準備状況プローブを設定できます。エラーを許容しない場合、誤って設定されたゲートウェイインスタンスでは、準備状況が ​`true`​ に達することはありません。エラーを許容するデプロイメントでは、設定エラーが発生した (たとえば、ポリシーを誤って設定した) 場合、API インスタンスおよびポリシーがデプロイされた後も準備状況は ​`true`​ のままです。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。 準備状況 CLI コマンドでは、エラーの許容範囲を設定する次のフラグが提供されます。 - `--allow-api-errors` - `--allow-envoy-errors` - `--allow-policy-errors` 準備状況 API への HTTP 要求を介して準備状況を照会するデプロイメントでは、次のクエリパラメーターを使用します。 - `allowEnvoyErrors=false` - `allowAPIErrors=false` - `allowPolicyErrors=false` ### [](#シャットダウン中の準備状況のプローブ)シャットダウン中の準備状況のプローブ ゲートウェイで ​`Connection: close`​ ヘッダーが送信された場合、準備状況はシャットダウン中もプローブされます。​`SIGTERM`​ シグナルでは、ダウンストリーム接続に再接続の信号を送信することで、ダウンストリーム接続のドレーンを開始します。デフォルトのドレーン期間は 25 秒で、その後、Flex Gateway は適切に終了します。 ドレーン期間を変更するには、Docker および Linux では ​`FLEX_SERVICE_ENVOY_DRAIN_TIME`​ 環境変数、Kubernetes Helm チャートでは ​`gateway.drainSeconds`​ オプションを使用できます。 Flex Gateway では、ドレーン期間よりも 5 秒長い 30 秒のグレースフルシャットガウンが事前設定されています。ドレーン期間を増加する場合は、​`TimeoutStopSec`​ (Linux) または ​`terminationGracePeriodSeconds`​ (Kubernetes) を使用してシャットダウン期間も増加します。シャットダウン期間はドレーン期間を超える必要があります。 Kubernetes のデフォルトの準備状況プローブは、失敗しきい値 2 で 10 秒ごとに実行され、20 秒以内にシャットダウンを検出できます。これにより、シャットダウン中のインスタンスに新しいトラフィックは送信されなくなります。AWS ロードバランサーなどの他の環境で準備状況プローブの同様の設定を使用します。 ## [](#configure-a-liveness-probe)ライブネスプローブの設定 Flex Gateway インスタンスが稼働可能かどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=liveness ``` Flex Gateway インスタンスが稼働可能な場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 ライブネスプローブコマンドを手動で実行することも、自動的に実行されるようにコマンドを設定することもできます。デフォルトでは、Flex Gateway の Kubernetes デプロイメントには自動ライブネスプローブが設定されています。デフォルトのプローブは、ライブネスプローブコマンドを定期的に実行し、指定された回数の失敗の後に Flex Gateway ポッドを自動的に再起動します。 特定の環境でのライブネスプローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定されたライブネスプローブが含まれています。ライブネスプローブは、​`flexctl probe --check=liveness`​ を 10 秒間隔で自動的に実行し、テストが 5 回失敗した後に稼働していないポッドを再起動します。 ライブネスプローブはデフォルトで次の値で設定されています。 ```helm livenessProbe: exec: command: - flexctl - probe - --check=liveness initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 5 timeoutSeconds: 1 ```

パラメーター

説明

exec.command

ライブネスプローブコマンド

initialDelaySeconds

起動後、最初のライブネスプローブを実行するまで待機する時間 (秒単位)

periodSeconds

各ライブネスプローブ間の間隔 (秒単位)

failureThreshold

Kubernetes ポッドが再起動されるまでの失敗したライブネスプローブ数

timeoutSeconds

ライブネスプローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-k8-change-helm-settings)を参照してください。 Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトのライブネスプローブは含まれません。ただし、ライブネスプローブコマンドを手動で実行したり、サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes ライブネスプローブ以外では、MuleSoft はサードパーティのライブネスプローブのサポートを提供しません。 Docker でライブネスプローブコマンドを実行する 1 つの方法は、​`docker run`​ コマンドで ​`HEALTHCHECK`​ を設定することです。詳細は、 [「Docker run HEALTHCHECK」](https://docs.docker.com/engine/reference/run/#healthcheck)​を参照してください。 ## [](#関連情報)関連情報 - [Liveness Probe、Readiness Probe および Startup Probe を使用する](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)​。 - [状態チェックポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-health-check) # 準備状況プローブまたはライブネスプローブの設定 Flex Gateway では、信頼性と効率を確保するための 2 つの方法がサポートされます。 - 準備状況プローブでは、ゲートウェイインスタンスが正しく設定され、受信トラフィックへの準備が整っているかどうかをテストします。これにより、部分的に設定された API によってエンドユーザーが影響を受けないようにします。詳細は、​[準備状況プローブの設定](#configure-a-readiness-probe)​を参照してください。 - ライブネスプローブでは、ゲートウェイインスタンスが稼働可能かどうかをテストします。これにより、クラッシュや他の障害によるダウンタイムを最小限に抑えます。詳細は、​[ライブネスプローブの設定](#configure-a-liveness-probe)​を参照してください。 ## [](#configure-a-readiness-probe)準備状況プローブの設定 Flex Gateway インスタンスで受信トラフィックへの準備が整っているかどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=readiness ``` Flex Gateway インスタンスで受信トラフィックを受信する準備が整っている場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 Flex Gateway が開始されると、その準備状況は ​`false`​ になります。この状況は、次の条件が満たされると ​`true`​ に変わります。 - API インスタンスがデプロイされた (1 つ以上の API が設定されている必要があります) - ポリシーが初期化された 設定の変更を実行中のゲートウェイに適用しても、準備状況に影響はありません。これにより、インスタンスは、設定の更新中であってもトラフィックを継続的に受信することができます。 特定の環境での準備状況プローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定された準備状況プローブが含まれています。準備状況プローブは ​`flexctl probe --check=readiness --allow-api-errors --allow-envoy-errors --allow-policy-errors`​ を 10 秒間隔で自動的に実行します。 準備状況プローブには、次のデフォルト値があります。 ```helm readinessProbe: exec: command: - flexctl - probe - --check=readiness - --allow-api-errors - --allow-envoy-errors - --allow-policy-errors initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 2 timeoutSeconds: 5 ```

パラメーター

説明

exec.command

準備状況プローブコマンド

--allow-api-errors

API インスタンスでのエラーを許可するフラグ

--allow-envoy-errors

Envoy 設定エラーを許可するフラグ

--allow-policy-errors

ポリシー設定エラーを許可するフラグ

initialDelaySeconds

起動後、最初の準備状況プローブを実行するまで待機する時間 (秒単位)

periodSeconds

各準備状況プローブ間の間隔 (秒単位)

failureThreshold

Kubernetes 準備状況を ​false​ に設定するまでの失敗した準備状況プローブ数

timeoutSeconds

準備状況プローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings)を参照してください。 デフォルトの Kubernetes 準備状況プローブは、エラーを許容するように設定されています。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。エラーの許容範囲についての詳細は、​[エラーの許容範囲の設定](#configure-error-tolerance)​を参照してください。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトの準備状況プローブは含まれません。ただし、準備状況プローブコマンドを手動で実行したり、外部サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes 準備状況プローブ以外では、MuleSoft はサードパーティの準備状況プローブのサポートを提供しません。 ### [](#外部コンポーネントの設定)外部コンポーネントの設定 準備状況を照会するように外部コンポーネントを設定します。たとえば、ロードバランサーの背後で実行される AWS 仮想マシンでは、準備状況クエリを状態チェックとして設定します。準備状況 API を外部コンポーネントに公開するには、次の設定を Flex Gateway インスタンスに適用します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: probe spec: probe: enabled: true port: 3000 ``` YAML 設定スニペットを適用すると、準備状況 API で ​`GET`​ 要求に応答することができます。 `http://:/probes/readiness?allowEnvoyErrors=&allowAPIErrors=&allowPolicyErrors=` ### [](#configure-error-tolerance)エラーの許容範囲の設定 エラーを許容しないまたは許容するように準備状況プローブを設定できます。エラーを許容しない場合、誤って設定されたゲートウェイインスタンスでは、準備状況が ​`true`​ に達することはありません。エラーを許容するデプロイメントでは、設定エラーが発生した (たとえば、ポリシーを誤って設定した) 場合、API インスタンスおよびポリシーがデプロイされた後も準備状況は ​`true`​ のままです。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。 準備状況 CLI コマンドでは、エラーの許容範囲を設定する次のフラグが提供されます。 - `--allow-api-errors` - `--allow-envoy-errors` - `--allow-policy-errors` 準備状況 API への HTTP 要求を介して準備状況を照会するデプロイメントでは、次のクエリパラメーターを使用します。 - `allowEnvoyErrors=false` - `allowAPIErrors=false` - `allowPolicyErrors=false` ### [](#シャットダウン中の準備状況のプローブ)シャットダウン中の準備状況のプローブ ゲートウェイで ​`Connection: close`​ ヘッダーが送信された場合、準備状況はシャットダウン中もプローブされます。​`SIGTERM`​ シグナルでは、ダウンストリーム接続に再接続の信号を送信することで、ダウンストリーム接続のドレーンを開始します。デフォルトのドレーン期間は 25 秒で、その後、Flex Gateway は適切に終了します。 ドレーン期間を変更するには、Docker および Linux では ​`FLEX_SERVICE_ENVOY_DRAIN_TIME`​ 環境変数、Kubernetes Helm チャートでは ​`gateway.drainSeconds`​ オプションを使用できます。 Flex Gateway では、ドレーン期間よりも 5 秒長い 30 秒のグレースフルシャットガウンが事前設定されています。ドレーン期間を増加する場合は、​`TimeoutStopSec`​ (Linux) または ​`terminationGracePeriodSeconds`​ (Kubernetes) を使用してシャットダウン期間も増加します。シャットダウン期間はドレーン期間を超える必要があります。 Kubernetes のデフォルトの準備状況プローブは、失敗しきい値 2 で 10 秒ごとに実行され、20 秒以内にシャットダウンを検出できます。これにより、シャットダウン中のインスタンスに新しいトラフィックは送信されなくなります。AWS ロードバランサーなどの他の環境で準備状況プローブの同様の設定を使用します。 ## [](#configure-a-liveness-probe)ライブネスプローブの設定 Flex Gateway インスタンスが稼働可能かどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=liveness ``` Flex Gateway インスタンスが稼働可能な場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 ライブネスプローブコマンドを手動で実行することも、自動的に実行されるようにコマンドを設定することもできます。デフォルトでは、Flex Gateway の Kubernetes デプロイメントには自動ライブネスプローブが設定されています。デフォルトのプローブは、ライブネスプローブコマンドを定期的に実行し、指定された回数の失敗の後に Flex Gateway ポッドを自動的に再起動します。 特定の環境でのライブネスプローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定されたライブネスプローブが含まれています。ライブネスプローブは、​`flexctl probe --check=liveness`​ を 10 秒間隔で自動的に実行し、テストが 5 回失敗した後に稼働していないポッドを再起動します。 ライブネスプローブはデフォルトで次の値で設定されています。 ```helm livenessProbe: exec: command: - flexctl - probe - --check=liveness initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 5 timeoutSeconds: 1 ```

パラメーター

説明

exec.command

ライブネスプローブコマンド

initialDelaySeconds

起動後、最初のライブネスプローブを実行するまで待機する時間 (秒単位)

periodSeconds

各ライブネスプローブ間の間隔 (秒単位)

failureThreshold

Kubernetes ポッドが再起動されるまでの失敗したライブネスプローブ数

timeoutSeconds

ライブネスプローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings)を参照してください。 Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトのライブネスプローブは含まれません。ただし、ライブネスプローブコマンドを手動で実行したり、サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes ライブネスプローブ以外では、MuleSoft はサードパーティのライブネスプローブのサポートを提供しません。 Docker でライブネスプローブコマンドを実行する 1 つの方法は、​`docker run`​ コマンドで ​`HEALTHCHECK`​ を設定することです。詳細は、 [「Docker run HEALTHCHECK」](https://docs.docker.com/engine/reference/run/#healthcheck)​を参照してください。 ## [](#関連情報)関連情報 - [Liveness Probe、Readiness Probe および Startup Probe を使用する](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)​。 - [状態チェックポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-health-check) # 準備状況プローブまたはライブネスプローブの設定 Flex Gateway では、信頼性と効率を確保するための 2 つの方法がサポートされます。 - 準備状況プローブでは、ゲートウェイインスタンスが正しく設定され、受信トラフィックへの準備が整っているかどうかをテストします。これにより、部分的に設定された API によってエンドユーザーが影響を受けないようにします。詳細は、​[準備状況プローブの設定](#configure-a-readiness-probe)​を参照してください。 - ライブネスプローブでは、ゲートウェイインスタンスが稼働可能かどうかをテストします。これにより、クラッシュや他の障害によるダウンタイムを最小限に抑えます。詳細は、​[ライブネスプローブの設定](#configure-a-liveness-probe)​を参照してください。 ## [](#configure-a-readiness-probe)準備状況プローブの設定 Flex Gateway インスタンスで受信トラフィックへの準備が整っているかどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=readiness ``` Flex Gateway インスタンスで受信トラフィックを受信する準備が整っている場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 Flex Gateway が開始されると、その準備状況は ​`false`​ になります。この状況は、次の条件が満たされると ​`true`​ に変わります。 - API インスタンスがデプロイされた (1 つ以上の API が設定されている必要があります) - ポリシーが初期化された 設定の変更を実行中のゲートウェイに適用しても、準備状況に影響はありません。これにより、インスタンスは、設定の更新中であってもトラフィックを継続的に受信することができます。 特定の環境での準備状況プローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定された準備状況プローブが含まれています。準備状況プローブは ​`flexctl probe --check=readiness --allow-api-errors --allow-envoy-errors --allow-policy-errors`​ を 10 秒間隔で自動的に実行します。 準備状況プローブには、次のデフォルト値があります。 ```helm readinessProbe: exec: command: - flexctl - probe - --check=readiness - --allow-api-errors - --allow-envoy-errors - --allow-policy-errors initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 2 timeoutSeconds: 5 ```

パラメーター

説明

exec.command

準備状況プローブコマンド

--allow-api-errors

API インスタンスでのエラーを許可するフラグ

--allow-envoy-errors

Envoy 設定エラーを許可するフラグ

--allow-policy-errors

ポリシー設定エラーを許可するフラグ

initialDelaySeconds

起動後、最初の準備状況プローブを実行するまで待機する時間 (秒単位)

periodSeconds

各準備状況プローブ間の間隔 (秒単位)

failureThreshold

Kubernetes 準備状況を ​false​ に設定するまでの失敗した準備状況プローブ数

timeoutSeconds

準備状況プローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings)を参照してください。 デフォルトの Kubernetes 準備状況プローブは、エラーを許容するように設定されています。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。エラーの許容範囲についての詳細は、​[エラーの許容範囲の設定](#configure-error-tolerance)​を参照してください。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトの準備状況プローブは含まれません。ただし、準備状況プローブコマンドを手動で実行したり、外部サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes 準備状況プローブ以外では、MuleSoft はサードパーティの準備状況プローブのサポートを提供しません。 ### [](#外部コンポーネントの設定)外部コンポーネントの設定 準備状況を照会するように外部コンポーネントを設定します。たとえば、ロードバランサーの背後で実行される AWS 仮想マシンでは、準備状況クエリを状態チェックとして設定します。準備状況 API を外部コンポーネントに公開するには、次の設定を Flex Gateway インスタンスに適用します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: probe spec: probe: enabled: true port: 3000 ``` YAML 設定スニペットを適用すると、準備状況 API で ​`GET`​ 要求に応答することができます。 `http://:/probes/readiness?allowEnvoyErrors=&allowAPIErrors=&allowPolicyErrors=` ### [](#configure-error-tolerance)エラーの許容範囲の設定 エラーを許容しないまたは許容するように準備状況プローブを設定できます。エラーを許容しない場合、誤って設定されたゲートウェイインスタンスでは、準備状況が ​`true`​ に達することはありません。エラーを許容するデプロイメントでは、設定エラーが発生した (たとえば、ポリシーを誤って設定した) 場合、API インスタンスおよびポリシーがデプロイされた後も準備状況は ​`true`​ のままです。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。 準備状況 CLI コマンドでは、エラーの許容範囲を設定する次のフラグが提供されます。 - `--allow-api-errors` - `--allow-envoy-errors` - `--allow-policy-errors` 準備状況 API への HTTP 要求を介して準備状況を照会するデプロイメントでは、次のクエリパラメーターを使用します。 - `allowEnvoyErrors=false` - `allowAPIErrors=false` - `allowPolicyErrors=false` ### [](#シャットダウン中の準備状況のプローブ)シャットダウン中の準備状況のプローブ ゲートウェイで ​`Connection: close`​ ヘッダーが送信された場合、準備状況はシャットダウン中もプローブされます。​`SIGTERM`​ シグナルでは、ダウンストリーム接続に再接続の信号を送信することで、ダウンストリーム接続のドレーンを開始します。デフォルトのドレーン期間は 25 秒で、その後、Flex Gateway は適切に終了します。 ドレーン期間を変更するには、Docker および Linux では ​`FLEX_SERVICE_ENVOY_DRAIN_TIME`​ 環境変数、Kubernetes Helm チャートでは ​`gateway.drainSeconds`​ オプションを使用できます。 Flex Gateway では、ドレーン期間よりも 5 秒長い 30 秒のグレースフルシャットガウンが事前設定されています。ドレーン期間を増加する場合は、​`TimeoutStopSec`​ (Linux) または ​`terminationGracePeriodSeconds`​ (Kubernetes) を使用してシャットダウン期間も増加します。シャットダウン期間はドレーン期間を超える必要があります。 Kubernetes のデフォルトの準備状況プローブは、失敗しきい値 2 で 10 秒ごとに実行され、20 秒以内にシャットダウンを検出できます。これにより、シャットダウン中のインスタンスに新しいトラフィックは送信されなくなります。AWS ロードバランサーなどの他の環境で準備状況プローブの同様の設定を使用します。 ## [](#configure-a-liveness-probe)ライブネスプローブの設定 Flex Gateway インスタンスが稼働可能かどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=liveness ``` Flex Gateway インスタンスが稼働可能な場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 ライブネスプローブコマンドを手動で実行することも、自動的に実行されるようにコマンドを設定することもできます。デフォルトでは、Flex Gateway の Kubernetes デプロイメントには自動ライブネスプローブが設定されています。デフォルトのプローブは、ライブネスプローブコマンドを定期的に実行し、指定された回数の失敗の後に Flex Gateway ポッドを自動的に再起動します。 特定の環境でのライブネスプローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定されたライブネスプローブが含まれています。ライブネスプローブは、​`flexctl probe --check=liveness`​ を 10 秒間隔で自動的に実行し、テストが 5 回失敗した後に稼働していないポッドを再起動します。 ライブネスプローブはデフォルトで次の値で設定されています。 ```helm livenessProbe: exec: command: - flexctl - probe - --check=liveness initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 5 timeoutSeconds: 1 ```

パラメーター

説明

exec.command

ライブネスプローブコマンド

initialDelaySeconds

起動後、最初のライブネスプローブを実行するまで待機する時間 (秒単位)

periodSeconds

各ライブネスプローブ間の間隔 (秒単位)

failureThreshold

Kubernetes ポッドが再起動されるまでの失敗したライブネスプローブ数

timeoutSeconds

ライブネスプローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.8/flex-gateway-k8-change-helm-settings)を参照してください。 Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトのライブネスプローブは含まれません。ただし、ライブネスプローブコマンドを手動で実行したり、サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes ライブネスプローブ以外では、MuleSoft はサードパーティのライブネスプローブのサポートを提供しません。 Docker でライブネスプローブコマンドを実行する 1 つの方法は、​`docker run`​ コマンドで ​`HEALTHCHECK`​ を設定することです。詳細は、 [「Docker run HEALTHCHECK」](https://docs.docker.com/engine/reference/run/#healthcheck)​を参照してください。 ## [](#関連情報)関連情報 - [Liveness Probe、Readiness Probe および Startup Probe を使用する](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)​。 - [状態チェックポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-health-check) # 準備状況プローブまたはライブネスプローブの設定 Flex Gateway では、信頼性と効率を確保するための 2 つの方法がサポートされます。 - 準備状況プローブでは、ゲートウェイインスタンスが正しく設定され、受信トラフィックへの準備が整っているかどうかをテストします。これにより、部分的に設定された API によってエンドユーザーが影響を受けないようにします。詳細は、​[準備状況プローブの設定](#configure-a-readiness-probe)​を参照してください。 - ライブネスプローブでは、ゲートウェイインスタンスが稼働可能かどうかをテストします。これにより、クラッシュや他の障害によるダウンタイムを最小限に抑えます。詳細は、​[ライブネスプローブの設定](#configure-a-liveness-probe)​を参照してください。 ## [](#configure-a-readiness-probe)準備状況プローブの設定 Flex Gateway インスタンスで受信トラフィックへの準備が整っているかどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=readiness ``` Flex Gateway インスタンスで受信トラフィックを受信する準備が整っている場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 Flex Gateway が開始されると、その準備状況は ​`false`​ になります。この状況は、次の条件が満たされると ​`true`​ に変わります。 - API インスタンスがデプロイされた (1 つ以上の API が設定されている必要があります) - ポリシーが初期化された 設定の変更を実行中のゲートウェイに適用しても、準備状況に影響はありません。これにより、インスタンスは、設定の更新中であってもトラフィックを継続的に受信することができます。 特定の環境での準備状況プローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定された準備状況プローブが含まれています。準備状況プローブは ​`flexctl probe --check=readiness --allow-api-errors --allow-envoy-errors --allow-policy-errors`​ を 10 秒間隔で自動的に実行します。 準備状況プローブには、次のデフォルト値があります。 ```helm readinessProbe: exec: command: - flexctl - probe - --check=readiness - --allow-api-errors - --allow-envoy-errors - --allow-policy-errors initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 2 timeoutSeconds: 5 ```

パラメーター

説明

exec.command

準備状況プローブコマンド

--allow-api-errors

API インスタンスでのエラーを許可するフラグ

--allow-envoy-errors

Envoy 設定エラーを許可するフラグ

--allow-policy-errors

ポリシー設定エラーを許可するフラグ

initialDelaySeconds

起動後、最初の準備状況プローブを実行するまで待機する時間 (秒単位)

periodSeconds

各準備状況プローブ間の間隔 (秒単位)

failureThreshold

Kubernetes 準備状況を ​false​ に設定するまでの失敗した準備状況プローブ数

timeoutSeconds

準備状況プローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings)を参照してください。 デフォルトの Kubernetes 準備状況プローブは、エラーを許容するように設定されています。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。エラーの許容範囲についての詳細は、​[エラーの許容範囲の設定](#configure-error-tolerance)​を参照してください。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトの準備状況プローブは含まれません。ただし、準備状況プローブコマンドを手動で実行したり、外部サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes 準備状況プローブ以外では、MuleSoft はサードパーティの準備状況プローブのサポートを提供しません。 ### [](#外部コンポーネントの設定)外部コンポーネントの設定 準備状況を照会するように外部コンポーネントを設定します。たとえば、ロードバランサーの背後で実行される AWS 仮想マシンでは、準備状況クエリを状態チェックとして設定します。準備状況 API を外部コンポーネントに公開するには、次の設定を Flex Gateway インスタンスに適用します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: probe spec: probe: enabled: true port: 3000 ``` YAML 設定スニペットを適用すると、準備状況 API で ​`GET`​ 要求に応答することができます。 `http://:/probes/readiness?allowEnvoyErrors=&allowAPIErrors=&allowPolicyErrors=` ### [](#configure-error-tolerance)エラーの許容範囲の設定 エラーを許容しないまたは許容するように準備状況プローブを設定できます。エラーを許容しない場合、誤って設定されたゲートウェイインスタンスでは、準備状況が ​`true`​ に達することはありません。エラーを許容するデプロイメントでは、設定エラーが発生した (たとえば、ポリシーを誤って設定した) 場合、API インスタンスおよびポリシーがデプロイされた後も準備状況は ​`true`​ のままです。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。 準備状況 CLI コマンドでは、エラーの許容範囲を設定する次のフラグが提供されます。 - `--allow-api-errors` - `--allow-envoy-errors` - `--allow-policy-errors` 準備状況 API への HTTP 要求を介して準備状況を照会するデプロイメントでは、次のクエリパラメーターを使用します。 - `allowEnvoyErrors=false` - `allowAPIErrors=false` - `allowPolicyErrors=false` ### [](#シャットダウン中の準備状況のプローブ)シャットダウン中の準備状況のプローブ ゲートウェイで ​`Connection: close`​ ヘッダーが送信された場合、準備状況はシャットダウン中もプローブされます。​`SIGTERM`​ シグナルでは、ダウンストリーム接続に再接続の信号を送信することで、ダウンストリーム接続のドレーンを開始します。デフォルトのドレーン期間は 25 秒で、その後、Flex Gateway は適切に終了します。 ドレーン期間を変更するには、Docker および Linux では ​`FLEX_SERVICE_ENVOY_DRAIN_TIME`​ 環境変数、Kubernetes Helm チャートでは ​`gateway.drainSeconds`​ オプションを使用できます。 Flex Gateway では、ドレーン期間よりも 5 秒長い 30 秒のグレースフルシャットガウンが事前設定されています。ドレーン期間を増加する場合は、​`TimeoutStopSec`​ (Linux) または ​`terminationGracePeriodSeconds`​ (Kubernetes) を使用してシャットダウン期間も増加します。シャットダウン期間はドレーン期間を超える必要があります。 Kubernetes のデフォルトの準備状況プローブは、失敗しきい値 2 で 10 秒ごとに実行され、20 秒以内にシャットダウンを検出できます。これにより、シャットダウン中のインスタンスに新しいトラフィックは送信されなくなります。AWS ロードバランサーなどの他の環境で準備状況プローブの同様の設定を使用します。 ## [](#configure-a-liveness-probe)ライブネスプローブの設定 Flex Gateway インスタンスが稼働可能かどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=liveness ``` Flex Gateway インスタンスが稼働可能な場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 ライブネスプローブコマンドを手動で実行することも、自動的に実行されるようにコマンドを設定することもできます。デフォルトでは、Flex Gateway の Kubernetes デプロイメントには自動ライブネスプローブが設定されています。デフォルトのプローブは、ライブネスプローブコマンドを定期的に実行し、指定された回数の失敗の後に Flex Gateway ポッドを自動的に再起動します。 特定の環境でのライブネスプローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定されたライブネスプローブが含まれています。ライブネスプローブは、​`flexctl probe --check=liveness`​ を 10 秒間隔で自動的に実行し、テストが 5 回失敗した後に稼働していないポッドを再起動します。 ライブネスプローブはデフォルトで次の値で設定されています。 ```helm livenessProbe: exec: command: - flexctl - probe - --check=liveness initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 5 timeoutSeconds: 1 ```

パラメーター

説明

exec.command

ライブネスプローブコマンド

initialDelaySeconds

起動後、最初のライブネスプローブを実行するまで待機する時間 (秒単位)

periodSeconds

各ライブネスプローブ間の間隔 (秒単位)

failureThreshold

Kubernetes ポッドが再起動されるまでの失敗したライブネスプローブ数

timeoutSeconds

ライブネスプローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings)を参照してください。 Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトのライブネスプローブは含まれません。ただし、ライブネスプローブコマンドを手動で実行したり、サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes ライブネスプローブ以外では、MuleSoft はサードパーティのライブネスプローブのサポートを提供しません。 Docker でライブネスプローブコマンドを実行する 1 つの方法は、​`docker run`​ コマンドで ​`HEALTHCHECK`​ を設定することです。詳細は、 [「Docker run HEALTHCHECK」](https://docs.docker.com/engine/reference/run/#healthcheck)​を参照してください。 ## [](#関連情報)関連情報 - [Liveness Probe、Readiness Probe および Startup Probe を使用する](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)​。 - [状態チェックポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-health-check) # 準備状況プローブまたはライブネスプローブの設定 Flex Gateway では、信頼性と効率を確保するための 2 つの方法がサポートされます。 - 準備状況プローブでは、ゲートウェイインスタンスが正しく設定され、受信トラフィックへの準備が整っているかどうかをテストします。これにより、部分的に設定された API によってエンドユーザーが影響を受けないようにします。詳細は、​[準備状況プローブの設定](#configure-a-readiness-probe)​を参照してください。 - ライブネスプローブでは、ゲートウェイインスタンスが稼働可能かどうかをテストします。これにより、クラッシュや他の障害によるダウンタイムを最小限に抑えます。詳細は、​[ライブネスプローブの設定](#configure-a-liveness-probe)​を参照してください。 ## [](#configure-a-readiness-probe)準備状況プローブの設定 Flex Gateway インスタンスで受信トラフィックへの準備が整っているかどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=readiness ``` Flex Gateway インスタンスで受信トラフィックを受信する準備が整っている場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 Flex Gateway が開始されると、その準備状況は ​`false`​ になります。この状況は、次の条件が満たされると ​`true`​ に変わります。 - API インスタンスがデプロイされた (1 つ以上の API が設定されている必要があります) - ポリシーが初期化された 設定の変更を実行中のゲートウェイに適用しても、準備状況に影響はありません。これにより、インスタンスは、設定の更新中であってもトラフィックを継続的に受信することができます。 特定の環境での準備状況プローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定された準備状況プローブが含まれています。準備状況プローブは ​`flexctl probe --check=readiness --allow-api-errors --allow-envoy-errors --allow-policy-errors`​ を 10 秒間隔で自動的に実行します。 準備状況プローブには、次のデフォルト値があります。 ```helm readinessProbe: exec: command: - flexctl - probe - --check=readiness - --allow-api-errors - --allow-envoy-errors - --allow-policy-errors initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 2 timeoutSeconds: 5 ```

パラメーター

説明

exec.command

準備状況プローブコマンド

--allow-api-errors

API インスタンスでのエラーを許可するフラグ

--allow-envoy-errors

Envoy 設定エラーを許可するフラグ

--allow-policy-errors

ポリシー設定エラーを許可するフラグ

initialDelaySeconds

起動後、最初の準備状況プローブを実行するまで待機する時間 (秒単位)

periodSeconds

各準備状況プローブ間の間隔 (秒単位)

failureThreshold

Kubernetes 準備状況を ​false​ に設定するまでの失敗した準備状況プローブ数

timeoutSeconds

準備状況プローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings)を参照してください。 デフォルトの Kubernetes 準備状況プローブは、エラーを許容するように設定されています。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。エラーの許容範囲についての詳細は、​[エラーの許容範囲の設定](#configure-error-tolerance)​を参照してください。
デフォルトでは、Kubernetes または Openshift で実行されている Flex Gateway は準備状況プローブを使用します。Flex Gateway インスタンスにデプロイされた API がない場合、準備状況は ​false​ になります。これは、カスタム準備状況プローブ設定では問題にはなりません。
Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトの準備状況プローブは含まれません。ただし、準備状況プローブコマンドを手動で実行したり、外部サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes 準備状況プローブ以外では、MuleSoft はサードパーティの準備状況プローブのサポートを提供しません。 ### [](#外部コンポーネントの設定)外部コンポーネントの設定 準備状況を照会するように外部コンポーネントを設定します。たとえば、ロードバランサーの背後で実行される AWS 仮想マシンでは、準備状況クエリを状態チェックとして設定します。準備状況 API を外部コンポーネントに公開するには、次の設定を Flex Gateway インスタンスに適用します。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Configuration metadata: name: probe spec: probe: enabled: true port: 3000 ``` YAML 設定スニペットを適用すると、準備状況 API で ​`GET`​ 要求に応答することができます。 `http://:/probes/readiness?allowEnvoyErrors=&allowAPIErrors=&allowPolicyErrors=` ### [](#configure-error-tolerance)エラーの許容範囲の設定 エラーを許容しないまたは許容するように準備状況プローブを設定できます。エラーを許容しない場合、誤って設定されたゲートウェイインスタンスでは、準備状況が ​`true`​ に達することはありません。エラーを許容するデプロイメントでは、設定エラーが発生した (たとえば、ポリシーを誤って設定した) 場合、API インスタンスおよびポリシーがデプロイされた後も準備状況は ​`true`​ のままです。これにより、設定エラーの可能性があっても Flex Gateway を拡張できます。 準備状況 CLI コマンドでは、エラーの許容範囲を設定する次のフラグが提供されます。 - `--allow-api-errors` - `--allow-envoy-errors` - `--allow-policy-errors` 準備状況 API への HTTP 要求を介して準備状況を照会するデプロイメントでは、次のクエリパラメーターを使用します。 - `allowEnvoyErrors=false` - `allowAPIErrors=false` - `allowPolicyErrors=false` ### [](#シャットダウン中の準備状況のプローブ)シャットダウン中の準備状況のプローブ ゲートウェイで ​`Connection: close`​ ヘッダーが送信された場合、準備状況はシャットダウン中もプローブされます。​`SIGTERM`​ シグナルでは、ダウンストリーム接続に再接続の信号を送信することで、ダウンストリーム接続のドレーンを開始します。デフォルトのドレーン期間は 25 秒で、その後、Flex Gateway は適切に終了します。 ドレーン期間を変更するには、Docker および Linux では ​`FLEX_SERVICE_ENVOY_DRAIN_TIME`​ 環境変数、Kubernetes Helm チャートでは ​`gateway.drainSeconds`​ オプションを使用できます。 Flex Gateway では、ドレーン期間よりも 5 秒長い 30 秒のグレースフルシャットガウンが事前設定されています。ドレーン期間を増加する場合は、​`TimeoutStopSec`​ (Linux) または ​`terminationGracePeriodSeconds`​ (Kubernetes) を使用してシャットダウン期間も増加します。シャットダウン期間はドレーン期間を超える必要があります。 Kubernetes のデフォルトの準備状況プローブは、失敗しきい値 2 で 10 秒ごとに実行され、20 秒以内にシャットダウンを検出できます。これにより、シャットダウン中のインスタンスに新しいトラフィックは送信されなくなります。AWS ロードバランサーなどの他の環境で準備状況プローブの同様の設定を使用します。 ## [](#configure-a-liveness-probe)ライブネスプローブの設定 Flex Gateway インスタンスが稼働可能かどうかをテストするには、次の CLI コマンドを使用します。 ```ssh flexctl probe --check=liveness ``` Flex Gateway インスタンスが稼働可能な場合、このコマンドは終了コード ​`0`​ を返します。それ以外の場合、このコマンドは終了コード ​`1`​ を返します。 ライブネスプローブコマンドを手動で実行することも、自動的に実行されるようにコマンドを設定することもできます。デフォルトでは、Flex Gateway の Kubernetes デプロイメントには自動ライブネスプローブが設定されています。デフォルトのプローブは、ライブネスプローブコマンドを定期的に実行し、指定された回数の失敗の後に Flex Gateway ポッドを自動的に再起動します。 特定の環境でのライブネスプローブの設定についての詳細は、次を参照してください。 - Kubernetes と OpenShift - Docker、Podman、Linux デフォルトでは、Kubernetes で実行されている Flex Gateway には、Helm チャートで設定されたライブネスプローブが含まれています。ライブネスプローブは、​`flexctl probe --check=liveness`​ を 10 秒間隔で自動的に実行し、テストが 5 回失敗した後に稼働していないポッドを再起動します。 ライブネスプローブはデフォルトで次の値で設定されています。 ```helm livenessProbe: exec: command: - flexctl - probe - --check=liveness initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 5 timeoutSeconds: 1 ```

パラメーター

説明

exec.command

ライブネスプローブコマンド

initialDelaySeconds

起動後、最初のライブネスプローブを実行するまで待機する時間 (秒単位)

periodSeconds

各ライブネスプローブ間の間隔 (秒単位)

failureThreshold

Kubernetes ポッドが再起動されるまでの失敗したライブネスプローブ数

timeoutSeconds

ライブネスプローブがタイムアウトになるまでの時間 (秒単位)
デフォルトのパラメーターを変更するには、Helm チャートを更新します。これらのパラメーターは、Helm チャートの初回インストール中またはインストール後に変更できます。Helm チャートの更新についての詳細は、[Helm チャートを介した Flex Gateway デプロイメントのポッド設定の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-k8-change-helm-settings)を参照してください。 Docker および Linux デプロイメントの場合、Flex Gateway には、事前設定済みのデフォルトのライブネスプローブは含まれません。ただし、ライブネスプローブコマンドを手動で実行したり、サードパーティサービスで自動的に使用するように設定したりすることはできます。Kubernetes ライブネスプローブ以外では、MuleSoft はサードパーティのライブネスプローブのサポートを提供しません。 Docker でライブネスプローブコマンドを実行する 1 つの方法は、​`docker run`​ コマンドで ​`HEALTHCHECK`​ を設定することです。詳細は、 [「Docker run HEALTHCHECK」](https://docs.docker.com/engine/reference/run/#healthcheck)​を参照してください。 ## [](#関連情報)関連情報 - [Liveness Probe、Readiness Probe および Startup Probe を使用する](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)​。 - [状態チェックポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-health-check) # 状態チェックポリシー

ポリシー名

状態チェック

Summary (概要)

特定の間隔で API アップストリームの健全性を監視する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 状態チェックポリシーを使用すると、アップストリームサービスへの API インスタンスの接続を監視でき、接続状況が変わった場合にメールアラートが送信されます。状態チェックポリシーでは、アップストリームサービスの状態が監視され、API インスタンスや Flex Gateway の状態は監視されません。 状態チェックポリシーでは、指定されたアップストリームのベースパスに対して GET 要求を実行することで API を監視します。GET 要求でベースパスを指定する必要があります。要求は最初の要求を含めて固定されたスケジュールで 1 分ごとに実行されます。最初の要求はポリシーが適用されてから 1 分後に実行されます。状態チェックポリシーによって行われた要求は、価格設定を目的として Flex Gateway API コールに含まれません。 状態チェックを設定する場合、健全な接続を示す GET 要求の応答コードを指定します。たとえば、アクティブな API の状況コードでは 200 が返されます。これは、API で接続を受信できることを示します。状況コードが 200 以外の場合、プラットフォームによりメールアラートが送信されます。状態チェックでは応答コードのみを検証するため、エンドポイントに何が返されるかは重要ではありません。 健全な応答についてはログイベントが表示されません。Flex Gateway では、健全でない応答のみが記録されます。 1xx、2xx、3xx、4xx、または 5xx の任意の応答コードを使用できます。ただし、エンドポイントへの正常な接続が想定される場合は、2xx の応答コードを使用することをお勧めします。数値の応答コードのみが受け入れられます。 状態チェックポリシーのアラートを作成する必要があります。ポリシーを適用すると、\[Create Alert (アラートを作成)\] ページに移動します。ここで、アラートを作成する必要があります。アラートの設定方法についての詳細は、​[「Flex Gateway API アラートの使用」](https://docs.mulesoft.com/jp/gateway/1.10/flex-use-api-alerts)​にアクセスしてください。
状態チェックポリシーを、アウトバウンド TLS コンテキストも適用されている API インスタンスに適用すると、状態チェックポリシーでは健全ではない接続が返されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード 状態チェックポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Upstream URL (アップストリーム URL)

監視している API アップストリームの完全な URL

はい

Base Path (ベースパス)

状態チェック中に要求される GET メソッドの HTTP パス。

はい

Response code (応答コード)

ベースパスで指定された GET 要求の想定される状況コード。数値の応答コードのみが受け入れられます。

はい
# 状態チェックポリシー

ポリシー名

状態チェック

Summary (概要)

特定の間隔で API アップストリームの健全性を監視する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 状態チェックポリシーを使用すると、アップストリームサービスへの API インスタンスの接続を監視でき、接続状況が変わった場合にメールアラートが送信されます。状態チェックポリシーでは、アップストリームサービスの状態が監視され、API インスタンスや Flex Gateway の状態は監視されません。 状態チェックポリシーでは、指定されたアップストリームのベースパスに対して GET 要求を実行することで API を監視します。GET 要求でベースパスを指定する必要があります。要求は最初の要求を含めて固定されたスケジュールで 1 分ごとに実行されます。最初の要求はポリシーが適用されてから 1 分後に実行されます。状態チェックポリシーによって行われた要求は、価格設定を目的として Flex Gateway API コールに含まれません。 状態チェックを設定する場合、健全な接続を示す GET 要求の応答コードを指定します。たとえば、アクティブな API の状況コードでは 200 が返されます。これは、API で接続を受信できることを示します。状況コードが 200 以外の場合、プラットフォームによりメールアラートが送信されます。状態チェックでは応答コードのみを検証するため、エンドポイントに何が返されるかは重要ではありません。 健全な応答についてはログイベントが表示されません。Flex Gateway では、健全でない応答のみが記録されます。 1xx、2xx、3xx、4xx、または 5xx の任意の応答コードを使用できます。ただし、エンドポイントへの正常な接続が想定される場合は、2xx の応答コードを使用することをお勧めします。数値の応答コードのみが受け入れられます。 状態チェックポリシーのアラートを作成する必要があります。ポリシーを適用すると、\[Create Alert (アラートを作成)\] ページに移動します。ここで、アラートを作成する必要があります。アラートの設定方法についての詳細は、​[「Flex Gateway API アラートの使用」](https://docs.mulesoft.com/jp/gateway/1.8/flex-use-api-alerts)​にアクセスしてください。
状態チェックポリシーを、アウトバウンド TLS コンテキストも適用されている API インスタンスに適用すると、状態チェックポリシーでは健全ではない接続が返されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード 状態チェックポリシーは、ローカルモードではサポートされません。 ### [](#flex-gateway-の接続モード)Flex Gateway の接続モード UI からポリシーを API に適用するときに、パラメーターのリストが表示されます。
要素 説明 必須?

Upstream URL (アップストリーム URL)

監視している API アップストリームの完全な URL

はい

Base Path (ベースパス)

状態チェック中に要求される GET メソッドの HTTP パス。

はい

Response code (応答コード)

ベースパスで指定された GET 要求の想定される状況コード。数値の応答コードのみが受け入れられます。

はい
# 状態チェックポリシー

ポリシー名

状態チェック

Summary (概要)

特定の間隔で API アップストリームの健全性を監視する

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.4.0

返される状況コード

このポリシーの戻りコードは存在しません。
## [](#概要)概要 状態チェックポリシーを使用すると、アップストリームサービスへの API インスタンスの接続を監視でき、接続状況が変わった場合にメールアラートが送信されます。状態チェックポリシーでは、アップストリームサービスの状態が監視され、API インスタンスや Flex Gateway の状態は監視されません。 状態チェックポリシーでは、指定されたアップストリームのベースパスに対して GET 要求を実行することで API を監視します。GET 要求でベースパスを指定する必要があります。要求は最初の要求を含めて固定されたスケジュールで 1 分ごとに実行されます。最初の要求はポリシーが適用されてから 1 分後に実行されます。状態チェックポリシーによって行われた要求は、価格設定を目的として Flex Gateway API コールに含まれません。 状態チェックを設定する場合、健全な接続を示す GET 要求の応答コードを指定します。たとえば、アクティブな API の状況コードでは 200 が返されます。これは、API で接続を受信できることを示します。状況コードが 200 以外の場合、プラットフォームによりメールアラートが送信されます。状態チェックでは応答コードのみを検証するため、エンドポイントに何が返されるかは重要ではありません。 健全な応答についてはログイベントが表示されません。Flex Gateway では、健全でない応答のみが記録されます。 1xx、2xx、3xx、4xx、または 5xx の任意の応答コードを使用できます。ただし、エンドポイントへの正常な接続が想定される場合は、2xx の応答コードを使用することをお勧めします。数値の応答コードのみが受け入れられます。 状態チェックポリシーのアラートを作成する必要があります。ポリシーを適用すると、\[Create Alert (アラートを作成)\] ページに移動します。ここで、アラートを作成する必要があります。アラートの設定方法についての詳細は、​[「Flex Gateway API アラートの使用」](https://docs.mulesoft.com/jp/gateway/1.9/flex-use-api-alerts)​にアクセスしてください。
状態チェックポリシーを、アウトバウンド TLS コンテキストも適用されている API インスタンスに適用すると、状態チェックポリシーでは健全ではない接続が返されます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 ### [](#flex-gateway-のローカルモード)Flex Gateway のローカルモード 状態チェックポリシーは、ローカルモードではサポートされません。 ### [](#connected-mode)管理 Flex Gateway および Flex Gateway の接続モード UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
要素 説明 必須

Upstream URL (アップストリーム URL)

監視している API アップストリームの完全な URL

はい

Base Path (ベースパス)

状態チェック中に要求される GET メソッドの HTTP パス。

はい

Response code (応答コード)

ベースパスで指定された GET 要求の想定される状況コード。数値の応答コードのみが受け入れられます。

はい
# 登録の問題のトラブルシューティング Anypoint Flex Gateway を登録しているときに、正しくないアクセス権などによる問題が発生することがあります。以下のトピックでは、登録の問題の考えられる原因とトラブルシューティング方法について説明します。 - [必要なアクセス権のないユーザーとして登録を実行](#no-permissions) ## [](#no-permissions)必要なアクセス権のないユーザーとして登録を実行 正しい権限を持たずに登録コマンドを実行すると、エラーとなります。 Couldn't execute register command successfully: rpc error: code = Internal desc = handler returned neither error nor response message ### [](#原因)原因 この問題は、登録時に指定したログイン情報に必要な権限が付与されていない場合に発生します。 ### [](#解決策)解決策 このエラーを解決するには、次の手順を実行します。 1. 組織のシステム管理者として ​**\[Access Management (アクセス管理)\]**​ に移動します。 2. メインメニューから ​**\[Users (ユーザー)\]**​ を選択します。 3. 対象となる組織のユーザーを ​**\[Users (ユーザー)\]**​ メニューから選択します。 4. **\[Permissions (権限)\]**​ タブから、​**\[Runtime Manager\]**​ を選択します。 5. 権限を適用する環境を指定します。 6. **\[Select access (アクセスを選択)\]**​ ドロップダウンメニューから以下を選択します。 - _Manage Servers (サーバーの管理)_ - _Read Servers (サーバーの参照)_ 7. **\[+\]**​ ボタンをクリックします。 登録コマンドを再び実行して、正常に完了することを確認します。 # 登録の問題のトラブルシューティング Anypoint Flex Gateway を登録しているときに、正しくないアクセス権などによる問題が発生することがあります。以下のトピックでは、登録の問題の考えられる原因とトラブルシューティング方法について説明します。 - [必要なアクセス権のないユーザーとして登録を実行](#no-permissions) ## [](#no-permissions)必要なアクセス権のないユーザーとして登録を実行 正しい権限を持たずに登録コマンドを実行すると、エラーとなります。 Couldn't execute register command successfully: rpc error: code = Internal desc = handler returned neither error nor response message ### [](#原因)原因 この問題は、登録時に指定したログイン情報に必要な権限が付与されていない場合に発生します。 ### [](#解決策)解決策 このエラーを解決するには、次の手順を実行します。 1. 組織のシステム管理者として ​**\[Access Management (アクセス管理)\]**​ に移動します。 2. メインメニューから ​**\[Users (ユーザー)\]**​ を選択します。 3. 対象となる組織のユーザーを ​**\[Users (ユーザー)\]**​ メニューから選択します。 4. **\[Permissions (権限)\]**​ タブから、​**\[Runtime Manager\]**​ を選択します。 5. 権限を適用する環境を指定します。 6. **\[Select access (アクセスを選択)\]**​ ドロップダウンメニューから以下を選択します。 - **Manage servers (サーバーの管理)** - **Read servers (サーバーの参照)** 7. **\[+\]**​ ボタンをクリックします。 登録コマンドを再び実行して、正常に完了することを確認します。 # 登録の問題のトラブルシューティング Anypoint Flex Gateway を登録しているときに、正しくないアクセス権などによる問題が発生することがあります。以下のトピックでは、登録の問題の考えられる原因とトラブルシューティング方法について説明します。 - [必要なアクセス権のないユーザーとして登録を実行](#no-permissions) ## [](#no-permissions)必要なアクセス権のないユーザーとして登録を実行 正しい権限を持たずに登録コマンドを実行すると、エラーとなります。 Couldn't execute register command successfully: rpc error: code = Internal desc = handler returned neither error nor response message ### [](#原因)原因 この問題は、登録時に指定したログイン情報に必要な権限が付与されていない場合に発生します。 ### [](#解決策)解決策 このエラーを解決するには、次の手順を実行します。 1. 組織のシステム管理者として ​**\[Access Management (アクセス管理)\]**​ に移動します。 2. メインメニューから ​**\[Users (ユーザー)\]**​ を選択します。 3. 対象となる組織のユーザーを ​**\[Users (ユーザー)\]**​ メニューから選択します。 4. **\[Permissions (権限)\]**​ タブから、​**\[Runtime Manager\]**​ を選択します。 5. 権限を適用する環境を指定します。 6. **\[Select access (アクセスを選択)\]**​ ドロップダウンメニューから以下を選択します。 - _Manage Servers (サーバーの管理)_ - _Read Servers (サーバーの参照)_ 7. **\[+\]**​ ボタンをクリックします。 登録コマンドを再び実行して、正常に完了することを確認します。 # 管理 Flex Gateway での監視 管理 Flex Gateway により、ログにアクセスして重要なメトリクスを表示できます。 管理 Flex Gateway の監視についての詳細は、次のトピックを参照してください。 - [管理 Flex Gateway メトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-status) - [管理 Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-message-log) - [管理 Flex Gateway 向け API Manager の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-api-metrics) - [管理 Flex Gateway 向け Runtime Manager の API 状況の表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-api-status) - [管理 Flex Gateway 向け Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-logs-in-runtime-manager) - [Anypoint Monitoring での管理 Flex Gateway ランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-logs-in-monitoring) # 管理 Flex Gateway での監視 管理 Flex Gateway により、ログにアクセスして重要なメトリクスを表示できます。 管理 Flex Gateway の監視についての詳細は、次のトピックを参照してください。 - [管理 Flex Gateway メトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-status) - [管理 Flex Gateway のメッセージログの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-message-log) - [管理 Flex Gateway 向け API Manager の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-api-metrics) - [管理 Flex Gateway 向け Runtime Manager の API 状況の表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-api-status) - [管理 Flex Gateway 向け Runtime Manager でのランタイムログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-logs-in-runtime-manager) - [Anypoint Monitoring での管理 Flex Gateway ランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-logs-in-monitoring) # 管理 Flex Gateway と接続モードでのポリシーの適用 管理 Flex Gateway と接続モードで実行されている Flex Gateway では、​**API Manager**​ を使用してインバウンドおよびアウトバウンドポリシーを適用します。Flex Gateway によって提供されるポリシーについては、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) and [アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-outbound-directory)​を参照してください。 ## [](#インバウンドポリシーを適用する)インバウンドポリシーを適用する 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを適用する API の名前をクリックします。 3. サイドナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 5. 適用するポリシーを選択します。 6. 必須のパラメーターを設定します。 ポリシー設定パラメーターについては、[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory)を参照してください。 7. 必要に応じて、​**\[Advanced options (詳細オプション)\]**​ を設定します。 8. **\[Apply (適用)\]**​ をクリックします。 ポリシーは、デフォルトで API 全体に適用することも、API 内の特定のメソッドやリソースに適用することもできます。 ## [](#アウトバウンドポリシーを適用する)アウトバウンドポリシーを適用する 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを適用する API の名前をクリックします。 3. サイドナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[Outbound policies (アウトバウンドポリシー)\]**​ タブをクリックします。 5. **\[+ Add outbound policy (+ アウトバウンドポリシーを追加)\]**​ をクリックします。 6. ポリシーを適用する ​**\[Upstream (アップストリーム)\]**​ を選択します。 7. 追加のアップストリームにポリシーを適用するには、​**\[Add upstream (アップストリームを追加)\]**​ をクリックして追加のアップストリームを選択します。ポリシーを適用するすべてのアップストリームでこの手順を繰り返します。 8. **\[Next (次へ)\]**​ をクリックします。 9. 適用するポリシーを選択します。 10. 必須のパラメーターを設定します。 ポリシー設定パラメーターについては、[アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-outbound-directory)を参照してください。 11. 必要に応じて、​**\[Advanced options (詳細オプション)\]**​ を設定します。 12. **\[Apply (適用)\]**​ をクリックします。 ポリシーは、デフォルトでアップストリーム全体に適用することも、アップストリームの特定のメソッドやリソースに適用することもできます。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) # 管理 Flex Gateway と接続モードでのポリシーの適用 管理 Flex Gateway と接続モードで実行されている Flex Gateway では、​**API Manager**​ を使用してインバウンドおよびアウトバウンドポリシーを適用します。Flex Gateway によって提供されるポリシーについては、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) and [アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-outbound-directory)​を参照してください。 ## [](#インバウンドポリシーを適用する)インバウンドポリシーを適用する 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを適用する API の名前をクリックします。 3. サイドナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 5. 適用するポリシーを選択します。 6. 必須のパラメーターを設定します。 ポリシー設定パラメーターについては、[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory)を参照してください。 7. 必要に応じて、​**\[Advanced options (詳細オプション)\]**​ を設定します。 8. **\[Apply (適用)\]**​ をクリックします。 ポリシーは、デフォルトで API 全体に適用することも、API 内の特定のメソッドやリソースに適用することもできます。 ## [](#アウトバウンドポリシーを適用する)アウトバウンドポリシーを適用する 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. **\[API Administration (API 管理)\]**​ で、ポリシーを適用する API の名前をクリックします。 3. サイドナビゲーションメニューから、​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[Outbound policies (アウトバウンドポリシー)\]**​ タブをクリックします。 5. **\[+ Add outbound policy (+ アウトバウンドポリシーを追加)\]**​ をクリックします。 6. ポリシーを適用する ​**\[Upstream (アップストリーム)\]**​ を選択します。 7. 追加のアップストリームにポリシーを適用するには、​**\[Add upstream (アップストリームを追加)\]**​ をクリックして追加のアップストリームを選択します。ポリシーを適用するすべてのアップストリームでこの手順を繰り返します。 8. **\[Next (次へ)\]**​ をクリックします。 9. 適用するポリシーを選択します。 10. 必須のパラメーターを設定します。 ポリシー設定パラメーターについては、[アウトバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-outbound-directory)を参照してください。 11. 必要に応じて、​**\[Advanced options (詳細オプション)\]**​ を設定します。 12. **\[Apply (適用)\]**​ をクリックします。 ポリシーは、デフォルトでアップストリーム全体に適用することも、アップストリームの特定のメソッドやリソースに適用することもできます。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) # 管理 Flex Gateway のアウトバウンド TLS の設定 アウトバウンド Transport Layer Security (TLS) では、Flex Gateway とアップストリームサービス間の通信を暗号化します。

アウトバウンド TLS 設定は接続モードで実行されている管理 Flex Gateway と自己管理 Flex Gateway で同じです。両方のモードで同じ TLS コンテキストを使用できます。
[シークレットグループを作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task)​したら、TLS コンテキストまたは相互認証 TLS (mTLS) コンテキストを追加し、その TLS コンテキストを API Manager でアップストリームに適用して、アウトバウンドトラフィックを暗号化できます。 デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#始める前に)始める前に 管理 Flex Gateway のアウトバウンド TLS コンテキストを設定する前に、次のタスクを完了してください。 - [シークレットグループの作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) シークレットグループを追加する場合、​[「TLS 設定オプション」](#tls-configuration-options)​を参照してください。 目的の設定に応じて、次のいずれかを実行します。 - [キーストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-keystore) - [トラストストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-truststore)
キーストアまたはトラストストアには、Privacy Enhanced Mail (PEM) 種別が必要です。
## [](#tls-configuration-options)アウトバウンド TLS 設定オプション 通常の TLS または mTLS をサポートするようにアウトバウンド TLS コンテキストを設定できます。 [「TLS コンテキストを追加する」](#add-a-tls-context)​ステップで必要な TLS コンテキスト設定については、次の相互参照テーブルを参照してください。
パラメーター アウトバウンド TLS アウトバウンド mTLS

Keystore (キーストア)

未使用

必須

Truststore (トラストストア)

[Skip server certificate validation (サーバー証明書の検証をスキップ)] が選択されていない場合は必須

アップストリーム証明書を検証する場合は必須

Validate Client certificate (クライアント証明書を検証)

未使用

未使用

Skip server certificate validation (サーバー証明書の検証をスキップ)

両方

未選択
設定のパラメーターが「未使用」の場合、その状況は設定に影響しないことを意味します。 設定を簡素化するために、API インスタンスの異なるトラフィック方向に対して異なる TLS コンテキストを作成します。同じ TLS コンテキストを使用して異なるトラフィック方向をサポートすることもできますが、同じコンテキストを使用して同じ方向の TLS と mTLS をサポートすることはできません。異なる方向に同じ TLS コンテキストを使用する場合は、両方向に必要なパラメーターを含めてください。 ## [](#add-a-tls-context)Flex Gateway の TLS コンテキストを追加する TLS コンテキストをシークレットグループに追加するには、名前、対象、バージョン、キーストアまたはトラストストアを指定する必要があります。コンテキストの有効期限と ALPN プロトコルを追加し、アウトバウンド設定を定義することもできます。

現在 API インスタンスに適用されている TLS コンテキストを含むシークレットグループを編集する場合は、各 API インスタンスを再デプロイして変更を適用する必要があります。API インスタンスを再デプロイするには、​「API インスタンスを再デプロイする」​を参照してください。
TLS コンテキストを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[Secrets Manager (シークレットマネージャー)\]**​ に移動します。 2. TLS コンテキストを API インスタンスに適用するには、シークレットグループをダウンロード可能にしてください。 シークレットグループをダウンロード可能にする手順は、次のとおりです。 1. シークレットグループの名前の横にある鉛筆アイコンをクリックします。 2. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されている場合は、​**\[Cancel (キャンセル)\]**​ をクリックします。 3. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されていない場合は、それを選択して ​**\[Save (保存)\]**​ をクリックします。 3. **\[Secret Groups (シークレットグループ)\]**​ リストビューで、シークレットグループの ​**\[Edit (編集)\]**​ ボタンをクリックして TLS コンテキストを追加します。 4. 左側のメニューで ​**\[TLS Context (TLS コンテキスト)\]**​ を選択してから、​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 5. \[Create TLS Context (TLS コンテキストを作成)\] 画面で、必要な情報を追加します。 - **Name (名前)**​ TLS コンテキストの名前を入力します。 - **Target (対象)**​ **\[Flex Gateway\]**​ を選択し、TLS コンテキストを Flex Gateway API の SSL 検証として使用します。 - **\[Min TLS Version (最小 TLS バージョン)\]**​ と ​**\[Max TLS Version (最大 TLS バージョン)\]**​ さまざまな TLS バージョンをサポートするか、最小と最大に同じバージョンを選択することで単一バージョンをサポートすします。 - **Keystore (キーストア)**​ 設定に必要な場合は、TLS コンテキストに保存する PEM 種別のキーストアを選択します。キーストアには、Flex Gateway がアウトバウンド TLS のリモートパーティに提示する証明書が含まれます。

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
- **Truststore (トラストストア)**​ 設定に必要な場合は、クライアントによって信頼される証明書を保存する PEM 種別のトラストストアを選択します。トラストストアには、Flex がアウトバウンド TLS のリモートパーティ証明書を検証するために使用する CA パスが含まれます。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。
- **Expiration Date (有効期限 (日))**​ 必要に応じて、TLS コンテキストの有効期限を入力します。 - **ALPN Protocols (ALPN プロトコル)**​ デフォルトでは、​**H2 - HTTP/1.1**​ が ALPN プロトコルとして選択されます。異なるプロトコルをサポートするには、この値を変更します。 - **Outbound Settings (アウトバウンド設定)**​ アウトバウンドトラフィックで mTLS をサポートしない場合は、​**\[Skip server certificate validation (サーバー証明書の検証をスキップ)\]**​ を選択します。 6. TLS コンテキストの暗号化サポートをカスタマイズする場合は、​[暗号化を選択します](#select-ciphers)​。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 7. **\[Save (保存)\]**​ をクリックします。 ## [](#tls-コンテキストを-api-に適用する)TLS コンテキストを API に適用する 新しい API インスタンスのアップストリーム設定の定義時に、または既存のインスタンスのアップストリーム設定を編集して、TLS コンテキストをアップストリームサービスに適用できます。 それぞれのオプションについては、関連するチュートリアルを参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [API インスタンスの編集](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task) TLS コンテキストをアップストリームサービスに適用する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 次のいずれかへ移動します。 - 新しい API インスタンスを追加する場合は、ダウンストリーム設定ページ。 - 既存の API インスタンスを編集する場合は、​**\[Settings (設定)\]**​ ページ。 3. 新しい API インスタンスを追加する場合は、アップストリームサービスを設定します。 4. **\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. **\[Secret Group (シークレットグループ)\]**​ を選択します。 2. **\[TLS Context (TLS コンテキスト)\]**​ を選択します。 3. **\[Ok\]**​ をクリックします。 5. API インスタンスの作成を完了するか、設定の編集を保存します。 ## [](#redeploy-api-instance)シークレットグループを編集して API インスタンスを再デプロイする シークレットグループを編集するには、​[「シークレットグループを編集する」](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#edit-a-secret-group)​を参照してください。 現在 API インスタンスに適用されているシークレットグループを編集し、その変更を API インスタンスに適用する場合は、変更が影響するすべてのインスタンスを個別に再デプロイする必要があります。 API インスタンスを再デプロイする手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 再デプロイする API インスタンスの名前をクリックします。 3. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Apply (保存して適用)\]**​ をクリックします。 ## [](#select-ciphers)暗号化の選択 TLS コンテキストを設定すると、シークレットマネージャーによって、選択した TLS バージョンに基づいてデフォルトの暗号化が適用されます。デフォルトに加えて、選択した TLS バージョンで使用する他の暗号化を選択できます。各 TLS コンテキストに複数の暗号化を含めることができます。 暗号化を選択する手順は、次のとおりです。 1. **\[Ciphers (暗号化)\]**​ をクリックして使用可能な暗号化を表示します。 2. 暗号化を選択します。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 3. **\[Save (保存)\]**​ をクリックします。 ## [](#flex-gateway-での-tls-暗号化のサポート)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合は、TLS 1.3 のデフォルトの暗号化をサポートする必要があります。 TLS 1.2 をサポートする場合は、TLS 1.2 のデフォルトの暗号化が選択されます。ただし、TLS 1.3 とは異なり、さまざまな TLS 1.2 暗号化をカスタマイズできます。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートすることを選択した場合は、サポートする暗号化を選択する必要があります。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンが API アップストリームでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS AES 128 GCM SHA256

1.3

はい

セキュア

TLS AES 256 GCM SHA384

1.3

はい

セキュア

TLS CHACHA20 POLY1305 SHA256

1.3

はい

セキュア

TLS ECDHE ECDSA WITH AES 128 GCM SHA256

1.2

はい

推奨

TLS ECDHE ECDSA WITH AES 256 GCM SHA384

1.2

はい

推奨

TLS ECDHE ECDSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

推奨

TLS ECDHE PSK WITH CHACHA20 POLY1305 SHA256

1.2

いいえ

推奨

TLS ECDHE RSA WITH AES 128 GCM SHA256

1.2

はい

セキュア

TLS ECDHE RSA WITH AES 256 GCM SHA384

1.2

はい

セキュア

TLS ECDHE RSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

セキュア

TLS RSA WITH AES 128 GCM SHA256

1.2

いいえ

脆弱

TLS RSA WITH AES 256 GCM SHA384

1.2

いいえ

脆弱

TLS RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH 3DES EDE CBC SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tls) # 管理 Flex Gateway のアウトバウンド TLS の設定 アウトバウンド Transport Layer Security (TLS) では、Flex Gateway とアップストリームサービス間の通信を暗号化します。

アウトバウンド TLS 設定は接続モードで実行されている管理 Flex Gateway と自己管理 Flex Gateway で同じです。両方のモードで同じ TLS コンテキストを使用できます。
[シークレットグループを作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task)​したら、TLS コンテキストまたは相互認証 TLS (mTLS) コンテキストを追加し、その TLS コンテキストを API Manager でアップストリームに適用して、アウトバウンドトラフィックを暗号化できます。 デフォルトでは、Flex Gateway はアウトバウンド TLS をサポートし、安全な通信チャネルを必要とするアップストリームサービスと通信します。デフォルトのアウトバウンド通信では、Flex Gateway は TLS 1.2 のみを使用します。デフォルトの TLS 1.2 暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。暗号化を見つけるには、​[Flex Gateway でサポートされる暗号化](#supported-ciphers)​を参照してください。TLS コンテキストをアップストリームに適用すると、そのアップストリームのデフォルトの TLS コンテキストが上書きされます。デフォルトの暗号化は以降の Flex Gateway バージョンでは変更される可能性があるため、TLS コンテキストをアップストリームに適用して同じ暗号化を維持することができます。

アウトバウンド TLS コンテキストを設定する際には、Authority Information Access (AIA) 証明書拡張機能はサポートされません。
## [](#始める前に)始める前に 管理 Flex Gateway のアウトバウンド TLS コンテキストを設定する前に、次のタスクを完了してください。 - [シークレットグループの作成](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task) シークレットグループを追加する場合、​[「TLS 設定オプション」](#tls-configuration-options)​を参照してください。 目的の設定に応じて、次のいずれかを実行します。 - [キーストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-keystore) - [トラストストアを追加する](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#adding-a-truststore)
キーストアまたはトラストストアには、Privacy Enhanced Mail (PEM) 種別が必要です。
## [](#tls-configuration-options)アウトバウンド TLS 設定オプション 通常の TLS または mTLS をサポートするようにアウトバウンド TLS コンテキストを設定できます。 [「TLS コンテキストを追加する」](#add-a-tls-context)​ステップで必要な TLS コンテキスト設定については、次の相互参照テーブルを参照してください。
パラメーター アウトバウンド TLS アウトバウンド mTLS

Keystore (キーストア)

未使用

必須

Truststore (トラストストア)

[Skip server certificate validation (サーバー証明書の検証をスキップ)] が選択されていない場合は必須

アップストリーム証明書を検証する場合は必須

Validate Client certificate (クライアント証明書を検証)

未使用

未使用

Skip server certificate validation (サーバー証明書の検証をスキップ)

両方

未選択
設定のパラメーターが「未使用」の場合、その状況は設定に影響しないことを意味します。 設定を簡素化するために、API インスタンスの異なるトラフィック方向に対して異なる TLS コンテキストを作成します。同じ TLS コンテキストを使用して異なるトラフィック方向をサポートすることもできますが、同じコンテキストを使用して同じ方向の TLS と mTLS をサポートすることはできません。異なる方向に同じ TLS コンテキストを使用する場合は、両方向に必要なパラメーターを含めてください。 ## [](#add-a-tls-context)Flex Gateway の TLS コンテキストを追加する TLS コンテキストをシークレットグループに追加するには、名前、対象、バージョン、キーストアまたはトラストストアを指定する必要があります。コンテキストの有効期限と ALPN プロトコルを追加し、アウトバウンド設定を定義することもできます。

現在 API インスタンスに適用されている TLS コンテキストを含むシークレットグループを編集する場合は、各 API インスタンスを再デプロイして変更を適用する必要があります。API インスタンスを再デプロイするには、​「API インスタンスを再デプロイする」​を参照してください。
TLS コンテキストを追加する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[Secrets Manager (シークレットマネージャー)\]**​ に移動します。 2. TLS コンテキストを API インスタンスに適用するには、シークレットグループをダウンロード可能にしてください。 シークレットグループをダウンロード可能にする手順は、次のとおりです。 1. シークレットグループの名前の横にある鉛筆アイコンをクリックします。 2. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されている場合は、​**\[Cancel (キャンセル)\]**​ をクリックします。 3. **\[Secret Group Downloadable (シークレットグループをダウンロード可能)\]**​ が選択されていない場合は、それを選択して ​**\[Save (保存)\]**​ をクリックします。 3. **\[Secret Groups (シークレットグループ)\]**​ リストビューで、シークレットグループの ​**\[Edit (編集)\]**​ ボタンをクリックして TLS コンテキストを追加します。 4. 左側のメニューで ​**\[TLS Context (TLS コンテキスト)\]**​ を選択してから、​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 5. \[Create TLS Context (TLS コンテキストを作成)\] 画面で、必要な情報を追加します。 - **Name (名前)**​ TLS コンテキストの名前を入力します。 - **Target (対象)**​ **\[Flex Gateway\]**​ を選択し、TLS コンテキストを Flex Gateway API の SSL 検証として使用します。 - **\[Min TLS Version (最小 TLS バージョン)\]**​ と ​**\[Max TLS Version (最大 TLS バージョン)\]**​ さまざまな TLS バージョンをサポートするか、最小と最大に同じバージョンを選択することで単一バージョンをサポートすします。 - **Keystore (キーストア)**​ 設定に必要な場合は、TLS コンテキストに保存する PEM 種別のキーストアを選択します。キーストアには、Flex Gateway がアウトバウンド TLS のリモートパーティに提示する証明書が含まれます。

セキュリティ標準に準拠するには、すべての証明書が 2048 ビット以上である必要があります。
- **Truststore (トラストストア)**​ 設定に必要な場合は、クライアントによって信頼される証明書を保存する PEM 種別のトラストストアを選択します。トラストストアには、Flex がアウトバウンド TLS のリモートパーティ証明書を検証するために使用する CA パスが含まれます。

アップストリーム証明書にはサブジェクト代替名 (SAN) 拡張機能を含める必要があります。共通名 (CN) 項目は非推奨です。

Flex Gateway では、​dNSName​ 種別の SAN 拡張機能がサポートされます。
- **Expiration Date (有効期限 (日))**​ 必要に応じて、TLS コンテキストの有効期限を入力します。 - **ALPN Protocols (ALPN プロトコル)**​ デフォルトでは、​**H2 - HTTP/1.1**​ が ALPN プロトコルとして選択されます。異なるプロトコルをサポートするには、この値を変更します。 - **Outbound Settings (アウトバウンド設定)**​ アウトバウンドトラフィックで mTLS をサポートしない場合は、​**\[Skip server certificate validation (サーバー証明書の検証をスキップ)\]**​ を選択します。 6. TLS コンテキストの暗号化サポートをカスタマイズする場合は、​[暗号化を選択します](#select-ciphers)​。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 7. **\[Save (保存)\]**​ をクリックします。 ## [](#tls-コンテキストを-api-に適用する)TLS コンテキストを API に適用する 新しい API インスタンスのアップストリーム設定の定義時に、または既存のインスタンスのアップストリーム設定を編集して、TLS コンテキストをアップストリームサービスに適用できます。 それぞれのオプションについては、関連するチュートリアルを参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [API インスタンスの編集](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task) TLS コンテキストをアップストリームサービスに適用する手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 次のいずれかへ移動します。 - 新しい API インスタンスを追加する場合は、ダウンストリーム設定ページ。 - 既存の API インスタンスを編集する場合は、​**\[Settings (設定)\]**​ ページ。 3. 新しい API インスタンスを追加する場合は、アップストリームサービスを設定します。 4. **\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. **\[Secret Group (シークレットグループ)\]**​ を選択します。 2. **\[TLS Context (TLS コンテキスト)\]**​ を選択します。 3. **\[Ok\]**​ をクリックします。 5. API インスタンスの作成を完了するか、設定の編集を保存します。 ## [](#redeploy-api-instance)シークレットグループを編集して API インスタンスを再デプロイする シークレットグループを編集するには、​[「シークレットグループを編集する」](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#edit-a-secret-group)​を参照してください。 現在 API インスタンスに適用されているシークレットグループを編集し、その変更を API インスタンスに適用する場合は、変更が影響するすべてのインスタンスを個別に再デプロイする必要があります。 API インスタンスを再デプロイする手順は、次のとおりです。 1. **\[Anypoint Platform\] > \[API Manager\]**​ に移動します。 2. 再デプロイする API インスタンスの名前をクリックします。 3. **\[Runtime & Endpoint Configuration (ランタイムとエンドポイント設定)\] > \[Save & Apply (保存して適用)\]**​ をクリックします。 ## [](#select-ciphers)暗号化の選択 TLS コンテキストを設定すると、シークレットマネージャーによって、選択した TLS バージョンに基づいてデフォルトの暗号化が適用されます。デフォルトに加えて、選択した TLS バージョンで使用する他の暗号化を選択できます。各 TLS コンテキストに複数の暗号化を含めることができます。 暗号化を選択する手順は、次のとおりです。 1. **\[Ciphers (暗号化)\]**​ をクリックして使用可能な暗号化を表示します。 2. 暗号化を選択します。 TLS バージョン 1.3 のみをサポートしている場合、暗号化は選択できません。 3. **\[Save (保存)\]**​ をクリックします。 ## [](#flex-gateway-での-tls-暗号化のサポート)Flex Gateway での TLS 暗号化のサポート Flex は、TLS 1.1 ～ TLS 1.3 の範囲の TLS バージョンをサポートでき、サポートする暗号化の一部をカスタマイズすることもできます。 TLS 1.3 暗号化のリストをカスタマイズすることはできません。TLS 1.3 をサポートする場合は、TLS 1.3 のデフォルトの暗号化をサポートする必要があります。 TLS 1.2 をサポートする場合は、TLS 1.2 のデフォルトの暗号化が選択されます。ただし、TLS 1.3 とは異なり、さまざまな TLS 1.2 暗号化をカスタマイズできます。 TLS 1.1 にはデフォルトの暗号化がありません。TLS 1.1 をサポートすることを選択した場合は、サポートする暗号化を選択する必要があります。
アウトバウンド TLS コンテキストの場合、選択した暗号化とバージョンが API アップストリームでサポートされることを確認してください。
### [](#supported-ciphers)Flex Gateway でサポートされる暗号化 Flex Gateway では、接続モードとローカルモードで次の TLS 暗号化がサポートされます。
暗号化 TLS バージョン デフォルト アドバイス

TLS AES 128 GCM SHA256

1.3

はい

セキュア

TLS AES 256 GCM SHA384

1.3

はい

セキュア

TLS CHACHA20 POLY1305 SHA256

1.3

はい

セキュア

TLS ECDHE ECDSA WITH AES 128 GCM SHA256

1.2

はい

推奨

TLS ECDHE ECDSA WITH AES 256 GCM SHA384

1.2

はい

推奨

TLS ECDHE ECDSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

推奨

TLS ECDHE PSK WITH CHACHA20 POLY1305 SHA256

1.2

いいえ

推奨

TLS ECDHE RSA WITH AES 128 GCM SHA256

1.2

はい

セキュア

TLS ECDHE RSA WITH AES 256 GCM SHA384

1.2

はい

セキュア

TLS ECDHE RSA WITH CHACHA20 POLY1305 SHA256

1.2

はい

セキュア

TLS RSA WITH AES 128 GCM SHA256

1.2

いいえ

脆弱

TLS RSA WITH AES 256 GCM SHA384

1.2

いいえ

脆弱

TLS RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE ECDSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE RSA WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 128 CBC SHA

1.1、1.2

いいえ

脆弱

TLS ECDHE PSK WITH AES 256 CBC SHA

1.1、1.2

いいえ

脆弱

TLS RSA WITH 3DES EDE CBC SHA

1.1

いいえ

脆弱
## [](#関連情報)関連情報 - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config) - [Transport Layer Security ポリシー - インバウンド](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-tls) # 管理 Flex Gateway のアップグレードまたは削除 Anypoint Runtime Manager を使用して管理 Flex Gateway をアップグレードまたは削除できます。 管理 Flex Gateways は、ゲートウェイリリースチャネル (LTS または Edge) に応じて定期的に自動アップグレードされます。 詳細は、[Flex Gateway バージョンのライフサイクル](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-version-lifecycle)を参照してください。 新規リリース日から自動アップグレード日までの間に、管理 Flex Gateway は定期的にスケジュールされたアップグレードまたはパッチプロセスより早くアップグレードできます。 組織にとってより都合の良いタイミングを選択できます。 ## [](#管理-flex-gateway-を早期アップグレードする-省略可能)管理 Flex Gateway を早期アップグレードする (省略可能) 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ タブを選択します。 4. アップグレードするゲートウェイの名前をクリックします。 5. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 6. 新しいバージョンが利用可能になると、​**\[Version (バージョン)\]**​ 項目に ​**\[Update available (更新が使用可能)\]**​ タグが表示されます。 7. バージョンと ​**\[Update available (更新が使用可能)\]**​ タグの横にある南京錠の記号をクリックします。 8. **\[Apply Changes (変更を適用)\]**​ ボタンをクリックします。 アップグレードの適用中は状況メッセージ (​**「Your gateway is being updated (ゲートウェイを更新しています)」**​) が表示されます。アップグレードが完了すると成功メッセージ (​**「Your gateway has been successfully updated (ゲートウェイが正常に更新されました)」**​) が表示されます。 9. ゲートウェイの状況を表示するにはナビゲーションメニューの ​**\[Dashboard (ダッシュボード)\]**​ をクリックします。 ## [](#管理-flex-gateway-を削除する)管理 Flex Gateway を削除する Anypoint Runtime Manager を使用して管理 Flex Gateway を削除できます。 ### [](#始める前に)始める前に 削除するゲートウェイに API が関連付けられている場合は、API を別のゲートウェイに移動するか、API を削除する必要があります。関連付けられている API をすべて移動または削除したら、次の手順に従ってゲートウェイを削除して、削除を確認してください。 ### [](#ゲートウェイを削除する)ゲートウェイを削除する 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ タブを選択します。 4. 削除するゲートウェイの名前をクリックします。 5. アクションメニューボタンに​**「Delete Gateway (ゲートウェイを削除)」**​と表示されていることを確認します。​**「Stop Gateway (ゲートウェイを停止)」**​と表示されている場合は、このボタンの下矢印部分をクリックし、​**\[Delete Gateway (ゲートウェイを削除)\]**​ を選択してアクションを変更します。 6. アクションメニューボタンの ​**\[Delete Gateway (ゲートウェイを削除)\]**​ をクリックします。 7. 確認ダイアログで正しいゲートウェイを削除することを確認します。 8. **\[Yes, Delete (はい、削除します)\]**​ をクリックします。 アクションの適用中は状況メッセージ (​**「Your gateway is being deleted (ゲートウェイを削除しています)」**​) が表示されます。アクションが完了すると成功メッセージ (​**「Your gateway has been successfully deleted (ゲートウェイが正常に削除されました)」**​) が表示されます。
ゲートウェイを削除すると、設定履歴が失われます。
# 管理 Flex Gateway のアップグレードまたは削除 Anypoint Runtime Manager を使用して管理 Flex Gateway をアップグレードまたは削除できます。 管理 Flex Gateways は、ゲートウェイリリースチャネル (LTS または Edge) に応じて定期的に自動アップグレードされます。 詳細は、[Flex Gateway バージョンのライフサイクル](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-version-lifecycle)を参照してください。 新規リリース日から自動アップグレード日までの間に、管理 Flex Gateway は定期的にスケジュールされたアップグレードまたはパッチプロセスより早くアップグレードできます。 組織にとってより都合の良いタイミングを選択できます。 ## [](#管理-flex-gateway-を早期アップグレードする-省略可能)管理 Flex Gateway を早期アップグレードする (省略可能) 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ タブを選択します。 4. アップグレードするゲートウェイの名前をクリックします。 5. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 6. 新しいバージョンが利用可能になると、​**\[Version (バージョン)\]**​ 項目に ​**\[Update available (更新が使用可能)\]**​ タグが表示されます。 7. バージョンと ​**\[Update available (更新が使用可能)\]**​ タグの横にある南京錠の記号をクリックします。 8. **\[Apply Changes (変更を適用)\]**​ ボタンをクリックします。 アップグレードの適用中は状況メッセージ (​**「Your gateway is being updated (ゲートウェイを更新しています)」**​) が表示されます。アップグレードが完了すると成功メッセージ (​**「Your gateway has been successfully updated (ゲートウェイが正常に更新されました)」**​) が表示されます。 9. ゲートウェイの状況を表示するにはナビゲーションメニューの ​**\[Dashboard (ダッシュボード)\]**​ をクリックします。 ## [](#管理-flex-gateway-を削除する)管理 Flex Gateway を削除する Anypoint Runtime Manager を使用して管理 Flex Gateway を削除できます。 ### [](#始める前に)始める前に 削除するゲートウェイに API が関連付けられている場合は、API を別のゲートウェイに移動するか、API を削除する必要があります。関連付けられている API をすべて移動または削除したら、次の手順に従ってゲートウェイを削除して、削除を確認してください。 ### [](#ゲートウェイを削除する)ゲートウェイを削除する 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. **\[Managed Flex Gateway (管理 Flex Gateway)\]**​ タブを選択します。 4. 削除するゲートウェイの名前をクリックします。 5. アクションメニューボタンに​**「Delete Gateway (ゲートウェイを削除)」**​と表示されていることを確認します。​**「Stop Gateway (ゲートウェイを停止)」**​と表示されている場合は、このボタンの下矢印部分をクリックし、​**\[Delete Gateway (ゲートウェイを削除)\]**​ を選択してアクションを変更します。 6. アクションメニューボタンの ​**\[Delete Gateway (ゲートウェイを削除)\]**​ をクリックします。 7. 確認ダイアログで正しいゲートウェイを削除することを確認します。 8. **\[Yes, Delete (はい、削除します)\]**​ をクリックします。 アクションの適用中は状況メッセージ (​**「Your gateway is being deleted (ゲートウェイを削除しています)」**​) が表示されます。アクションが完了すると成功メッセージ (​**「Your gateway has been successfully deleted (ゲートウェイが正常に削除されました)」**​) が表示されます。
ゲートウェイを削除すると、設定履歴が失われます。
# 管理 Flex Gateway のインバウンド TLS の設定 CloudHub 2.0 でデプロイされた管理 Flex Gateway では、CloudHub 2.0 非公開スペースでインバウンド TLS を管理します。 管理 Flex Gateway をデプロイする非公開スペースの TLS コンテキストを設定するには、[Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains)を参照してください。 非公開スペースの TLS コンテキストを設定すると、非公開スペースの管理 Flex Gateway にデプロイされたすべての API が HTTPS およびセキュアになります。 アウトバウンド TLS コンテキストを設定するには、[管理 Flex Gateway のアウトバウンド TLS の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-outbound-tls-config)を参照してください。 # 管理 Flex Gateway のインバウンド TLS の設定 CloudHub 2.0 でデプロイされた管理 Flex Gateway では、CloudHub 2.0 非公開スペースでインバウンド TLS を管理します。 管理 Flex Gateway をデプロイする非公開スペースの TLS コンテキストを設定するには、[Configuring Domains and Certificates (TLS Context) for a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-domains)を参照してください。 非公開スペースの TLS コンテキストを設定すると、非公開スペースの管理 Flex Gateway にデプロイされたすべての API が HTTPS およびセキュアになります。 アウトバウンド TLS コンテキストを設定するには、[管理 Flex Gateway のアウトバウンド TLS の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-outbound-tls-config)を参照してください。 # 管理 Flex Gateway のメッセージログの設定 API Manager の API インスタンスにメッセージログポリシーを適用すると、API Manager 内で Flex Gateway によって管理される API の基本的なログ (インバウンド/アウトバウンドコールおよびヘッダーなど) を表示できます。API インスタンスのログは、メッセージログポリシーを設定して適用した場合にのみ発生します。 API Manager で要求総数、ポリシー違反総数、総エラー数、平均応答時間などのメトリクスを表示するには、[接続モードでの Flex Gateway 向け API Manager の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-view-api-metrics)を参照してください。 ## [](#メッセージログの制限と機能)メッセージログの制限と機能 API Manager は、API インスタンスごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、API インスタンスごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、サードパーティサービス (ポリシーで設定) を使用するか、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションにサインアップできます。 基本的なログで、ポリシーを通じて設定された各 API インスタンスの次の情報が報告されます。 - インバウンドおよびアウトバウンド API コール、およびパケットコンテンツ - 要求内のヘッダーおよびその他の情報 API Manager でメッセージログを表示するには、次の権限のいずれかが必要です。 - API Manager Environment Administrator (API Manager 環境システム管理者) - API Manager Deploy API Proxies (API Manager API プロキシのデプロイ) - General Organization Administration (一般組織のシステム管理者) [Anypoint Platform で使用可能な権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product)を参照してください。 ## [](#接続モードでメッセージログを設定する)接続モードでメッセージログを設定する 1. API Manager の \[API Administration (API 管理)\] で、API インスタンスの名前を選択します。 2. **\[Policies (ポリシー)\]**​ をクリックします。 3. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 4. **\[Troubleshooting (トラブルシューティング)\]**​ カテゴリで ​**\[Message Logging (メッセージログ)\]**​ をクリックします。 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[+ Add (+ 追加)\]**​ をクリックします。 7. **\[Configuration Name (設定名)\]**​ に名前を入力します (「Info messages before calling API (API をコールする前の情報メッセージ)」など)。 8. 表示する情報を選択する DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']]`​ はメッセージのヘッダーから ID を抽出します。詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.10/policies-flex-dataweave-support)を参照してください。 9. ログメッセージを絞り込む場合は、DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']==1]`​ はヘッダーの ID が 1 のログメッセージを表示します。 10. ログにプレフィックスを付ける場合は、​**\[Category (カテゴリ)\]**​ に入力します。 11. 重要度レベルを入力します。 入力できるレベルは 1 つのみです。各重要度レベルとレベルの階層の説明については、​[「メッセージログの重要度レベル」](#severity-levels)​を参照してください。 12. API がコールされた後のメッセージが必要な場合は、​**\[After Calling API (API のコール後)\]**​ を選択します。 13. 設定をさらに追加する場合は、​**\[+ Add (+ 追加)\]**​ をクリックします。 14. **\[Save (保存)\]**​ をクリックします。 その後、API インスタンスの ​**\[Message Log (メッセージログ)\]**​ オプションが表示されます。 検索項目を使用して、時間とログの重要度 (INFO (情報)、ERROR (エラー)、WARN (警告)、DEBUG (デバッグ)) に基づいて特定のログを検索します。これらのログをダウンロードして、さらに分析できます。 ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# 管理 Flex Gateway のメッセージログの設定 API Manager の API インスタンスにメッセージログポリシーを適用すると、API Manager 内で Flex Gateway によって管理される API の基本的なログ (インバウンド/アウトバウンドコールおよびヘッダーなど) を表示できます。API インスタンスのログは、メッセージログポリシーを設定して適用した場合にのみ発生します。 API Manager で要求総数、ポリシー違反総数、総エラー数、平均応答時間などのメトリクスを表示するには、[接続モードでの Flex Gateway 向け API Manager の重要なメトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-view-api-metrics)を参照してください。 ## [](#メッセージログの制限と機能)メッセージログの制限と機能 API Manager は、API インスタンスごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、API インスタンスごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、サードパーティサービス (ポリシーで設定) を使用するか、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションにサインアップできます。 基本的なログで、ポリシーを通じて設定された各 API インスタンスの次の情報が報告されます。 - インバウンドおよびアウトバウンド API コール、およびパケットコンテンツ - 要求内のヘッダーおよびその他の情報 API Manager でメッセージログを表示するには、次の権限のいずれかが必要です。 - API Manager Environment Administrator (API Manager 環境システム管理者) - API Manager Deploy API Proxies (API Manager API プロキシのデプロイ) - General Organization Administration (一般組織のシステム管理者) [Anypoint Platform で使用可能な権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product)を参照してください。 ## [](#接続モードでメッセージログを設定する)接続モードでメッセージログを設定する 1. API Manager の \[API Administration (API 管理)\] で、API インスタンスの名前を選択します。 2. **\[Policies (ポリシー)\]**​ をクリックします。 3. **\[+ Add policy (+ ポリシーを追加)\]**​ をクリックします。 4. **\[Troubleshooting (トラブルシューティング)\]**​ カテゴリで ​**\[Message Logging (メッセージログ)\]**​ をクリックします。 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[+ Add (+ 追加)\]**​ をクリックします。 7. **\[Configuration Name (設定名)\]**​ に名前を入力します (「Info messages before calling API (API をコールする前の情報メッセージ)」など)。 8. 表示する情報を選択する DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']]`​ はメッセージのヘッダーから ID を抽出します。詳細は、[Flex Gateway ポリシーでの DataWeave のサポート](https://docs.mulesoft.com/jp/gateway/1.9/policies-flex-dataweave-support)を参照してください。 9. ログメッセージを絞り込む場合は、DataWeave 式を入力します。 たとえば、​`#[attributes.headers['id']==1]`​ はヘッダーの ID が 1 のログメッセージを表示します。 10. ログにプレフィックスを付ける場合は、​**\[Category (カテゴリ)\]**​ に入力します。 11. 重要度レベルを入力します。 入力できるレベルは 1 つのみです。各重要度レベルとレベルの階層の説明については、​[「メッセージログの重要度レベル」](#severity-levels)​を参照してください。 12. API がコールされた後のメッセージが必要な場合は、​**\[After Calling API (API のコール後)\]**​ を選択します。 13. 設定をさらに追加する場合は、​**\[+ Add (+ 追加)\]**​ をクリックします。 14. **\[Save (保存)\]**​ をクリックします。 その後、API インスタンスの ​**\[Message Log (メッセージログ)\]**​ オプションが表示されます。 検索項目を使用して、時間とログの重要度 (INFO (情報)、ERROR (エラー)、WARN (警告)、DEBUG (デバッグ)) に基づいて特定のログを検索します。これらのログをダウンロードして、さらに分析できます。 ## [](#severity-levels)メッセージログの重要度レベル API インスタンスのメッセージログポリシーを設定するときに、重要度レベルを割り当てることができます。ログレポートの各重要度レベルには、特定の情報セットが含まれます。 ログレポートには、選択した重要度レベルと階層の下位のレベルが含まれます。 たとえば、\[DEBUG (デバッグ)\] を選択した場合、ログレポートには \[DEBUG (デバッグ)\] 重要度レベルに加えて、\[INFO (情報)\]、\[WARN (警告)\]、\[ERROR (エラー)\] の重要度レベルが含まれます。ただし、\[ERROR (エラー)\] を選択した場合、ログレポートにはエラーメッセージのみが含まれます。次の表で、各重要度レベルのログに含まれる情報の種別について説明します。
ログの重要度レベル 説明

DEBUG

アプリケーション開発者が使用するトレース情報。

INFO

アプリケーションの進行状況を強調する情報メッセージ。

WARN

潜在的な問題を示す、有害な可能性がある状況。

ERROR

通常のプログラムの実行は妨げられ、アプリケーションの実行は継続できる可能性があるイベント。
# 管理 Flex Gateway の作成のトラブルシューティング 管理 Flex Gateway インスタンスを作成してデプロイするときに、問題が発生する可能性があります。可能な原因と解決策については、以下のトピックを確認してください。 - [\[Add Managed Flex Gateway (管理 Flex Gateway を追加)](#add-button-missing) ボタンがない\] - [\[Add Managed Flex Gateway Button (管理 Flex Gateway を追加)](#add-button-disabled) ボタンが無効\] - [非公開スペースが使用できない](#private-space) ## [](#add-button-missing)\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\] ボタンがない 選択したビジネスグループに管理 Flex Gateway リソースがないため Runtime Manager の ​**\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ ボタンがない場合があります。代わりに、「Start protecting your APIs with Managed Flex Gateways (管理 Flex Gateway を使用して API の保護を開始)」メッセージと ​**\[Create a Self-Managed Flex Gateway (自己管理 Flex Gateway を作成)\]**​ ボタンが表示されます。 ビジネスグループの管理 Flex Gateway リソースを確認する 1. **\[Access Management\] > \[Subscription (サブスクリプション)\] > \[Runtime Manage Subscription (ランタイム管理サブスクリプション)\]**​ に移動します。サブスクリプションランクに ​**\[Small Managed Flex Gateways (小規模管理 Flex Gateway)\]**​ および ​**\[Large Managed Flex Gateways (大規模管理 Flex Gateway)\]**​ リソースが含まれていない場合は、MuleSoft 担当者に連絡して詳細をご確認ください。 2. ビジネスグループで数量 ​**\[0/0 in use (0/0 が使用中)\]**​ が表示されているか、​**\[Small Managed Flex Gateways (小規模管理 Flex Gateway)\]**​ または ​**\[Large Managed Flex Gateways (大規模管理 Flex Gateway)\]**​ について ​**\[Reassigned (未割り当て)\]**​ と表示されている場合、1 つの組織またはビジネスグループから選択したビジネスグループへの管理 Flex Gateway リソースの再配信をお試しください。​[「既存のビジネスグループ間のリソースの再配信」](https://docs.mulesoft.com/jp/access-management/business-groups#redistribute-resources)​を参照してください。 ## [](#add-button-disabled)\[Add Managed Flex Gateway Button (管理 Flex Gateway を追加)\] ボタンが無効 クォータの制限または不十分な権限が原因で Runtime Manager の ​**\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ ボタンが無効になる可能性があります。この問題は、組織のすべてのサイズに許容されている管理 Flex Gateway の最大数に達した場合、または必要な​_「Manage Servers (サーバーを管理)」_​および​_「Read Servers (サーバーを参照)」_​ Runtime Manager 権限がない場合に発生します。 組織の管理 Flex Gateway クォータを確認する 1. Anypoint Platform で、​**\[Access Management\]**​ に移動します。 2. サイドナビゲーションパネルで、​**\[Subscription (サブスクリプション)\]**​ の ​**\[Runtime Manager\]**​ をクリックします。 3. 管理ゲートウェイのクォータを確認し、すべての管理 Flex Gateway サイズでクォータの上限に達したかどうかを判断します。 管理 Flex Gateway をさらにデプロイするには、既存のゲートウェイを削除するか、よりクォータの高いサブスクリプションプランにアップグレードします。 権限の確認 Access Management で、必要な​_「Manage Servers (サーバーを管理)」_​および​_「Read Servers (サーバーを参照)」_​ Runtime Manager 権限があることを確認します。 これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 ## [](#private-space)非公開スペースが使用できない 新しい管理 Flex Gateway を作成しているときに目的の非公開スペースが ​**\[Deployment Target (デプロイメント対象)\]**​ リストに表示されない場合は、その非公開スペースに必要な権限がない場合があります。 非公開スペース権限を確認する 1. Runtime Manager で、使用しようとしている非公開スペースの詳細にアクセスします。 2. **\[Environments (環境)\]**​ タブに移動します。 3. 対象の組織および環境がその非公開スペースの許可された環境内にあることを確認します。 必要に応じて、対象の組織および環境が含まれるように非公開スペースの \[Environments (環境)\] 設定を更新します。 1. 対象の組織および環境が含まれるように非公開スペースの ​**\[Environments (環境)\]**​ 設定を変更します。 2. 変更が伝播され、​**\[Deployment Target (デプロイメント対象)\]**​ リストで反映されるまで数分待ちます。 # 管理 Flex Gateway の作成のトラブルシューティング 管理 Flex Gateway インスタンスを作成してデプロイするときに、問題が発生する可能性があります。可能な原因と解決策については、以下のトピックを確認してください。 - [\[Add Managed Flex Gateway (管理 Flex Gateway を追加)](#add-button-missing) ボタンがない\] - [\[Add Managed Flex Gateway Button (管理 Flex Gateway を追加)](#add-button-disabled) ボタンが無効\] - [非公開スペースが使用できない](#private-space) ## [](#add-button-missing)\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\] ボタンがない 選択したビジネスグループに管理 Flex Gateway リソースがないため Runtime Manager の ​**\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ ボタンがない場合があります。代わりに、「Start protecting your APIs with Managed Flex Gateways (管理 Flex Gateway を使用して API の保護を開始)」メッセージと ​**\[Create a Self-Managed Flex Gateway (自己管理 Flex Gateway を作成)\]**​ ボタンが表示されます。 ビジネスグループの管理 Flex Gateway リソースを確認する 1. **\[Access Management\] > \[Subscription (サブスクリプション)\] > \[Runtime Manage Subscription (ランタイム管理サブスクリプション)\]**​ に移動します。サブスクリプションランクに ​**\[Small Managed Flex Gateways (小規模管理 Flex Gateway)\]**​ および ​**\[Large Managed Flex Gateways (大規模管理 Flex Gateway)\]**​ リソースが含まれていない場合は、MuleSoft 担当者に連絡して詳細をご確認ください。 2. ビジネスグループで数量 ​**\[0/0 in use (0/0 が使用中)\]**​ が表示されているか、​**\[Small Managed Flex Gateways (小規模管理 Flex Gateway)\]**​ または ​**\[Large Managed Flex Gateways (大規模管理 Flex Gateway)\]**​ について ​**\[Reassigned (未割り当て)\]**​ と表示されている場合、1 つの組織またはビジネスグループから選択したビジネスグループへの管理 Flex Gateway リソースの再配信をお試しください。​[「既存のビジネスグループ間のリソースの再配信」](https://docs.mulesoft.com/jp/access-management/business-groups#redistribute-resources)​を参照してください。 ## [](#add-button-disabled)\[Add Managed Flex Gateway Button (管理 Flex Gateway を追加)\] ボタンが無効 クォータの制限または不十分な権限が原因で Runtime Manager の ​**\[Add Managed Flex Gateway (管理 Flex Gateway を追加)\]**​ ボタンが無効になる可能性があります。この問題は、組織のすべてのサイズに許容されている管理 Flex Gateway の最大数に達した場合、または必要な​_「Manage Servers (サーバーを管理)」_​および​_「Read Servers (サーバーを参照)」_​ Runtime Manager 権限がない場合に発生します。 組織の管理 Flex Gateway クォータを確認する 1. Anypoint Platform で、​**\[Access Management\]**​ に移動します。 2. サイドナビゲーションパネルで、​**\[Subscription (サブスクリプション)\]**​ の ​**\[Runtime Manager\]**​ をクリックします。 3. 管理ゲートウェイのクォータを確認し、すべての管理 Flex Gateway サイズでクォータの上限に達したかどうかを判断します。 管理 Flex Gateway をさらにデプロイするには、既存のゲートウェイを削除するか、よりクォータの高いサブスクリプションプランにアップグレードします。 権限の確認 Access Management で、必要な​_「Manage Servers (サーバーを管理)」_​および​_「Read Servers (サーバーを参照)」_​ Runtime Manager 権限があることを確認します。 これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 ## [](#private-space)非公開スペースが使用できない 新しい管理 Flex Gateway を作成しているときに目的の非公開スペースが ​**\[Deployment Target (デプロイメント対象)\]**​ リストに表示されない場合は、その非公開スペースに必要な権限がない場合があります。 非公開スペース権限を確認する 1. Runtime Manager で、使用しようとしている非公開スペースの詳細にアクセスします。 2. **\[Environments (環境)\]**​ タブに移動します。 3. 対象の組織および環境がその非公開スペースの許可された環境内にあることを確認します。 必要に応じて、対象の組織および環境が含まれるように非公開スペースの \[Environments (環境)\] 設定を更新します。 1. 対象の組織および環境が含まれるように非公開スペースの ​**\[Environments (環境)\]**​ 設定を変更します。 2. 変更が伝播され、​**\[Deployment Target (デプロイメント対象)\]**​ リストで反映されるまで数分待ちます。 # 管理 Flex Gateway の分散トレースの設定 OpenTelemetry により、分散システムでテレメトリーデータを計測、生成、収集、エクスポートするための統合された基準が提供されます。Flex Gateway では OpenTelemetry をサポートしているため、ゲートウェイで管理するすべての API トラフィックの分散トレースデータの生成を設定できます。このインテグレーションにより、API 要求フローをより詳しく視覚化できるため、システムの動作をより簡単に分析し、問題をトラブルシューティングして、Flex Gateway API と外部サービス間のインタラクションを理解できます。 Anypoint Monitoring Telemetry Exporter を使用することで、Flex Gateway トレースデータを Azure Monitor や Splunk HEC のほか、OpenTelemetry 互換ツールなどのサードパーティオブザーバビリティおよび分析プラットフォームに送信できます。この機能によって、エンドツーエンドオブザーバビリティを活用し、API トレースを他のシステムのデータと相関させ、環境の包括的なビューを構築できます。 ## [](#始める前に)始める前に Flex Gateway で OpenTelemetry を使用するには、以下に精通している必要があります。 - 分散トレースの概念 (トレースやスパンなど)。 分散トレースや OpenTelemetry を初めて使用する場合、 [「OpenTelemetry とは」](https://opentelemetry.io/docs/concepts/what-is-opentelemetry/)​および [「分散トレースを理解する」](https://opentelemetry.io/docs/concepts/observability-primer/#understanding-distributed-tracing)​から始めることをお勧めします。 - [テレメトリーデータをサードパーティ監視システムにエクスポートする方法](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​。 ## [](#flex-gateway-api-の分散トレースの設定)Flex Gateway API の分散トレースの設定 トレースにより、Flex Gateway API のインタラクションを追跡できます。複数のシステムおよびサービスが関連する場合、分散トレースで分散環境に流れる API 要求を追跡し、API の実行の包括的なビューを提供します。 ## [](#管理-flex-gateway-の分散トレースを有効化して設定する)管理 Flex Gateway の分散トレースを有効化して設定する 管理 Flex Gateway の分散トレースを有効化する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\] > \[Flex Gateways (Flex Gateway)\]**​ を選択します。 2. 管理 Flex Gateway 名をクリックします。 3. ナビゲーションメニューで \[Settings (設定)\] をクリックします。 4. **\[Advanced options (詳細オプション)\]**​ をクリックします。 5. **\[Tracing (トレース)\]**​ をクリックします。 6. **\[Distributed tracing (分散トレース)\]**​ を有効化します。 7. **\[Sampling percentage (サンプリングパーセンテージ)\]**​ をトレースするトランザクションのパーセンテージに設定します。 - この設定は、​`全体`​のサンプリングパーセンテージに対応します。ここでサンプリングパーセンテージを 0 以外の値に設定すると、​`クライアント`​および​`ランダム`​のサンプリングパーセンテージはデフォルトで 100% に設定されます。 - トレースポリシーを使用して API ごとのサンプリングパーセンテージのみを指定する場合は、​**\[Sampling percentage (サンプリングパーセンテージ)\]**​ を 0 に設定してください。 8. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#特定の-api-の分散トレースの設定)特定の API の分散トレースの設定 特定の API にトレースポリシーを適用することで、グローバルに設定された分散トレース設定を上書きできます。まずゲートウェイの分散トレースを有効にして設定する必要があります。その後、次のポリシーを計測する API に適用できます。 - [トレースポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-tracing) # 管理 Flex Gateway の設定 - [管理 Flex Gateway のインバウンド TLS の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-inbound-tls-config) - CloudHub 2.0 非公開スペースにより、インバウンド TLS および mTLS を使用して API インスタンスを保護できます。 - [管理 Flex Gateway のアウトバウンド TLS の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-outbound-tls-config) - CloudHub 2.0 の管理 Flex Gateway により、各アップストリームの TLS および mTLS コンテキストを設定できます。 - [管理 Flex Gateway の分散トレースの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-tracing-config) - CloudHub 2.0 の管理 Flex Gateway により、分散トレースを設定できます。 # 管理 Flex Gateway の設定 - [管理 Flex Gateway のインバウンド TLS の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-inbound-tls-config) - CloudHub 2.0 非公開スペースにより、インバウンド TLS および mTLS を使用して API インスタンスを保護できます。 - [管理 Flex Gateway のアウトバウンド TLS の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-outbound-tls-config) - CloudHub 2.0 の管理 Flex Gateway により、各アップストリームの TLS および mTLS コンテキストを設定できます。 # 管理 Flex Gateway メトリクスの表示 ## [](#runtime-manager-で管理-flex-gateway-メトリクスを表示する)Runtime Manager で管理 Flex Gateway メトリクスを表示する Runtime Manager の管理 Flex Gateway ダッシュボードにはゲートウェイの包括的なビューが表示され、その状況、エンドポイント、非公開スペース、API 利用可能数、要求量、データ消費量、平均 CPU およびメモリ使用量が詳しく示されます。さらに、徹底的に監視できるようにレイテンシーやエラー数に関するメトリクスが提供されます。 管理 Flex Gateway インスタンスに関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. 状況を表示する管理 Flex Gateway の名前を選択します。 # 管理 Flex Gateway メトリクスの表示 ## [](#runtime-manager-で管理-flex-gateway-メトリクスを表示する)Runtime Manager で管理 Flex Gateway メトリクスを表示する Runtime Manager の管理 Flex Gateway ダッシュボードにはゲートウェイの包括的なビューが表示され、その状況、エンドポイント、非公開スペース、API 利用可能数、要求量、データ消費量、平均 CPU およびメモリ使用量が詳しく示されます。さらに、徹底的に監視できるようにレイテンシーやエラー数に関するメトリクスが提供されます。 管理 Flex Gateway インスタンスに関する情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. 状況を表示する管理 Flex Gateway の名前を選択します。 # 管理 Flex Gateway 向け API Manager の重要なメトリクスの表示 API Manager と Anypoint Monitoring は、アクティブな Flex Gateway API インスタンスでメトリクスを収集します。これらのメトリクスに関連したチャートを表示して、データを日付で絞り込むことができます。 API Manager で使用できるメトリクスは​**重要なメトリクス**​とみなされ、ここで説明されています。 **重要なメトリクス**​はすべての Anypoint Platform サブスクリプションで使用できます。​**\[Key Metrics (重要なメトリクス)\]**​ セクションに含まれないその他の Flex Gateway API メトリクスについては、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​ (Anypoint Integration Advanced パッケージまたは Titanium サブスクリプションのみ) を使用してください。Anypoint Monitoring に移動するには、Anypoint Platform から ​**\[Anypoint Monitoring\]**​ をクリックすることができます。

現在、API Manager の ​[Mule API Analytics]​ タブは Flex Gateway API では使用できません。​[Key Metrics (重要なメトリクス)]​ または Anypoint Monitoring でその他のメトリクスを使用してください。
## [](#重要なメトリクス)重要なメトリクス 1. Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のページで、​**\[API Manager\]**​ をクリックします。 **\[API Administration (API 管理)\]**​ ページが表示され、組織で使用できる API のリストが示されます。 3. API インスタンスをクリックします。 **\[API Summary (API の概要)\]**​ ページが表示され、API インスタンスの一般情報と状況が示されます。 Anypoint Monitoring で API インスタンスを表示するには、​**\[Key Metrics (重要なメトリクス)\]**​ セクションから ​**\[View more metrics in Anypoint Monitoring dashboard (Anypoint Monitoring ダッシュボードでその他のメトリクスを表示)\]**​ をクリックするか、Anypoint Monitoring に直接移動します。 **\[Key Metrics (重要なメトリクス)\]**​ セクションには 4 つのチャートがあります。API インスタンスでチャートが表示されない場合は、ブラウザーを更新してください。 ## [](#重要なメトリクスの意味)重要なメトリクスの意味 \[API Summary (API の概要)\] の ​**\[Key Metrics (重要なメトリクス)\]**​ セクションには、以下のチャートがあります。 Total Requests (要求総数) 選択された時間範囲での特定の API に対する要求数の合計。 データは 1 分ごとの増分量となります。 Total Policy Violations (ポリシー違反総数) ポリシー違反を返した要求の合計数。 データは 1 分ごとの増分量となります。 Total Errors (総エラー数) 選択された期間で発生した HTTP 応答コードの合計数。このメトリクスで数えられる応答コードは、400、401、402、403、404、405、408、409、410、411、412、413、415、416、417、420、422、429、500、502、503、504、504、510、511 です。 データは 1 分ごとの増分量となります。チャートでは、HTTP 応答コードは 4xx や 5xx のように省略して表示されます。 Average Response Time (平均応答時間) 選択された期間での特定の API に対する要求への応答時間の平均。 データは 1 分ごとの増分量となります。 ## [](#重要なメトリクスの期間の設定)重要なメトリクスの期間の設定 直前の一定期間 (過去 5 分間や過去 30 分間など) または特定の日時範囲に収集されたデータポイントを表示できます。カレンダーアイコンのドロップダウンを使用して、グラフに表示する期間を選択します。 ## [](#関連情報)関連情報 - [管理 Flex Gateway メトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-status) - [組み込み API ダッシュボードの使用](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard) # 管理 Flex Gateway 向け API Manager の重要なメトリクスの表示 API Manager と Anypoint Monitoring は、アクティブな Flex Gateway API インスタンスでメトリクスを収集します。これらのメトリクスに関連したチャートを表示して、データを日付で絞り込むことができます。 API Manager で使用できるメトリクスは​**重要なメトリクス**​とみなされ、ここで説明されています。 **重要なメトリクス**​はすべての Anypoint Platform サブスクリプションで使用できます。​**\[Key Metrics (重要なメトリクス)\]**​ セクションに含まれないその他の Flex Gateway API メトリクスについては、​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard)​ (Anypoint Integration Advanced パッケージまたは Titanium サブスクリプションのみ) を使用してください。Anypoint Monitoring に移動するには、Anypoint Platform から ​**\[Anypoint Monitoring\]**​ をクリックすることができます。

現在、API Manager の ​[Mule API Analytics]​ タブは Flex Gateway API では使用できません。​[Key Metrics (重要なメトリクス)]​ または Anypoint Monitoring でその他のメトリクスを使用してください。
## [](#重要なメトリクス)重要なメトリクス 1. Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のページで、​**\[API Manager\]**​ をクリックします。 **\[API Administration (API 管理)\]**​ ページが表示され、組織で使用できる API のリストが示されます。 3. API インスタンスをクリックします。 **\[API Summary (API の概要)\]**​ ページが表示され、API インスタンスの一般情報と状況が示されます。 Anypoint Monitoring で API インスタンスを表示するには、​**\[Key Metrics (重要なメトリクス)\]**​ セクションから ​**\[View more metrics in Anypoint Monitoring dashboard (Anypoint Monitoring ダッシュボードでその他のメトリクスを表示)\]**​ をクリックするか、Anypoint Monitoring に直接移動します。 **\[Key Metrics (重要なメトリクス)\]**​ セクションには 4 つのチャートがあります。API インスタンスでチャートが表示されない場合は、ブラウザーを更新してください。 ## [](#重要なメトリクスの意味)重要なメトリクスの意味 \[API Summary (API の概要)\] の ​**\[Key Metrics (重要なメトリクス)\]**​ セクションには、以下のチャートがあります。 Total Requests (要求総数) 選択された時間範囲での特定の API に対する要求数の合計。 データは 1 分ごとの増分量となります。 Total Policy Violations (ポリシー違反総数) ポリシー違反を返した要求の合計数。 データは 1 分ごとの増分量となります。 Total Errors (総エラー数) 選択された期間で発生した HTTP 応答コードの合計数。このメトリクスで数えられる応答コードは、400、401、402、403、404、405、408、409、410、411、412、413、415、416、417、420、422、429、500、502、503、504、504、510、511 です。 データは 1 分ごとの増分量となります。チャートでは、HTTP 応答コードは 4xx や 5xx のように省略して表示されます。 Average Response Time (平均応答時間) 選択された期間での特定の API に対する要求への応答時間の平均。 データは 1 分ごとの増分量となります。 ## [](#重要なメトリクスの期間の設定)重要なメトリクスの期間の設定 直前の一定期間 (過去 5 分間や過去 30 分間など) または特定の日時範囲に収集されたデータポイントを表示できます。カレンダーアイコンのドロップダウンを使用して、グラフに表示する期間を選択します。 ## [](#関連情報)関連情報 - [管理 Flex Gateway メトリクスの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-status) - [組み込み API ダッシュボードの使用](https://docs.mulesoft.com/jp/monitoring/api-analytics-dashboard) # 管理 Flex Gateway 向け Runtime Manager でのランタイムログの表示 Runtime Manager を使用して、Flex Gateway のランタイムログを表示します。Runtime Manager では、ログ内のキーワードを検索したり、​**\[Replica (レプリカ)\]**​、​**\[Time Range (時間範囲)\]**​、​**\[Log Level (ログレベル)\]**​ で絞り込んだりできます。 Runtime Manager は、Flex Gateway ごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、Flex Gateway ごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、Anypoint Monitoring を使用してこのログにアクセスするか (Titanium サブスクリプションが必要)、サードパーティログサービスを使用します。 Runtime Manager で Flex Gateway ランタイムログにアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Anypoint Monitoring での管理 Flex Gateway ランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-managed-view-logs-in-monitoring) # 管理 Flex Gateway 向け Runtime Manager でのランタイムログの表示 Runtime Manager を使用して、Flex Gateway のランタイムログを表示します。Runtime Manager では、ログ内のキーワードを検索したり、​**\[Replica (レプリカ)\]**​、​**\[Time Range (時間範囲)\]**​、​**\[Log Level (ログレベル)\]**​ で絞り込んだりできます。 Runtime Manager は、Flex Gateway ごとに最大 100 MB のログを 30 日間保存します。Runtime Manager は、Flex Gateway ごとに 100 MB を超えるログを自動的にパージします。より多くのストレージが必要な場合は、Anypoint Monitoring を使用してこのログにアクセスするか (Titanium サブスクリプションが必要)、サードパーティログサービスを使用します。 Runtime Manager で Flex Gateway ランタイムログにアクセスする手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. ログを参照する Flex Gateway の名前をクリックします。 4. **\[Logs (ログ)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [Anypoint Monitoring での管理 Flex Gateway ランタイムログとアクセスログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-managed-view-logs-in-monitoring) # 管理 Flex Gateway 向け Runtime Manager の API 状況の表示 Flex Gateway インスタンスに関連付けられた API に関する基本情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. API を確認するゲートウェイの名前をクリックします。 4. **\[APIs (API)\]**​ をクリックします。 各 API について、Runtime Manager に名前、バージョン、インスタンス ID、表示ラベル、追加された日付が表示されます。 詳細情報を確認して API に対するアクションを実行するには、​**\[View details (詳細を表示)\]**​ をクリックして API Manager にリダイレクトされるようにします。 # 管理 Flex Gateway 向け Runtime Manager の API 状況の表示 Flex Gateway インスタンスに関連付けられた API に関する基本情報を表示する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. API を確認するゲートウェイの名前をクリックします。 4. **\[APIs (API)\]**​ をクリックします。 各 API について、Runtime Manager に名前、バージョン、インスタンス ID、表示ラベル、追加された日付が表示されます。 詳細情報を確認して API に対するアクションを実行するには、​**\[View details (詳細を表示)\]**​ をクリックして API Manager にリダイレクトされるようにします。 # 管理ゲートウェイと接続モード API のパブリッシュ 管理 Flex Gateway または接続モードで実行されている Flex Gateway では、​**API Manager**​ を使用して単独のアップストリームサービスが使用されている API インスタンス、複数のアップストリームサービスが使用されている API インスタンス、MCP サーバーインスタンス、A2A サーバーインスタンスをパブリッシュします。 詳細は、以下を参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [api-manager::create-instance-task-mcp.adoc](#api-manager::create-instance-task-mcp.adoc) - [api-manager::create-instance-task-a2a.adoc](#api-manager::create-instance-task-a2a.adoc) また、​[CloudHub 2.0 での管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-managed-getting-started) or [Getting Started with Self-Managed Flex Gateway in Connected Mode](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started)​に従ってシンプルな API をパブリッシュすることもできます。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) # 管理ゲートウェイと接続モード API のパブリッシュ 管理 Flex Gateway または接続モードで実行されている Flex Gateway では、​**API Manager**​ を使用して単独のアップストリームサービスが使用されている API インスタンス、複数のアップストリームサービスが使用されている API インスタンス、MCP サーバーインスタンス、A2A サーバーインスタンスをパブリッシュします。 詳細は、以下を参照してください。 - [Flex Gateway API インスタンスの追加](https://docs.mulesoft.com/jp/api-manager/latest/create-instance-task-flex) - [api-manager::create-instance-task-mcp.adoc](#api-manager::create-instance-task-mcp.adoc) - [api-manager::create-instance-task-a2a.adoc](#api-manager::create-instance-task-a2a.adoc) また、​[CloudHub 2.0 での管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-managed-getting-started) or [Getting Started with Self-Managed Flex Gateway in Connected Mode](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started)​に従ってシンプルな API をパブリッシュすることもできます。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) # 管理ゲートウェイの保守のトラブルシューティング Anypoint 管理 Flex Gateway インスタンスを表示または保守するときに、問題が発生する可能性があります。可能な原因と解決策については、以下のトピックを確認してください。 - [ゲートウェイメトリクスの欠落](#gateway-metrics-not-showing) - [ゲートウェイプロパティが編集不可](#cant-change-gateway-properties) - [更新の待機中のタイムアウト](#timeout-while-waiting-for-update) - [ゲートウェイの欠落または無効](#gateway-missing-disabled) - [API パスの競合](#same-path-error) ## [](#gateway-metrics-not-showing)ゲートウェイメトリクスの欠落 Runtime Manager で、\[Managed Flex Gateway (管理 Flex Gateway)\] ダッシュボードからゲートウェイのメトリクスを参照できない場合は、​_「Usage Viewer (使用状況閲覧者)」_​権限を持っていることを確認してください。 権限の確認 Access Management で割り当てられているロールと権限を確認し、必要な​_「Usage Viewer (使用状況閲覧者)」_​ Runtime Manager 権限を持っていることを確認します。 これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 ## [](#cant-change-gateway-properties)ゲートウェイプロパティが変更不可 ゲートウェイインスタンスの作成後は、​**\[Gateway Name (ゲートウェイ名)\]**​、​**\[Deployment Target (デプロイメント対象)\]**​、​**\[Flow plans (フロープラン)\]**​ などの一部の管理 Flex Gateway プロパティを編集できません。これらのプロパティを変更するには、管理 Flex Gateway を削除し、目的の値で再作成する必要があります。 ## [](#timeout-while-waiting-for-update)更新の待機中のタイムアウト 管理 Flex Gateway の更新または削除が保留されている場合は、状況を更新して数分待ってからもう一度確認してください。遅延は Anypoint Platform が大量のトラフィックを処理している場合に発生することがあります。 ## [](#gateway-missing-disabled)API Manager でのゲートウェイの欠落または無効 API インスタンスをゲートウェイに追加する際に、管理 Flex Gateway が API Manager の ​**\[Select a gateway (ゲートウェイを選択)\]**​ リストに見つからないか管理 Flex Gateway が無効になっている場合は、Runtime Manager でゲートウェイの状況を参照してゲートウェイが実行中であることを確認してください。ゲートウェイの状況が ​**\[Running (実行中)\]**​ でない場合は、Runtime Manager から問題を修正します。ゲートウェイの状況が ​**\[Running (実行中)\]**​ であっても API Manager で選択できない場合は、クラスターの問題がある可能性があるため、MuleSoft サポートに問い合わせる必要があります。 ## [](#same-path-error)API パスの競合 管理 Flex Gateway への API の際に API Manager で​**「This path conflicts with another API (このパスは別の API と競合しています)」**​エラーが表示される場合は、別のベースパスを選択する必要があります。Flex Gateway の各 API インスタンスはゲートウェイ内で一意である必要があります。この問題を修正するには、API パスを一意の値に変更するか、もう一方の API インスタンスのパスを編集します。エラーメッセージの ​**\[API\]**​ をクリックして、パスが競合している API インスタンスを参照して編集します。 # 管理ゲートウェイの保守のトラブルシューティング Anypoint 管理 Flex Gateway インスタンスを表示または保守するときに、問題が発生する可能性があります。可能な原因と解決策については、以下のトピックを確認してください。 - [ゲートウェイメトリクスの欠落](#gateway-metrics-not-showing) - [ゲートウェイプロパティが編集不可](#cant-change-gateway-properties) - [更新の待機中のタイムアウト](#timeout-while-waiting-for-update) - [ゲートウェイの欠落または無効](#gateway-missing-disabled) - [API パスの競合](#same-path-error) ## [](#gateway-metrics-not-showing)ゲートウェイメトリクスの欠落 Runtime Manager で、\[Managed Flex Gateway (管理 Flex Gateway)\] ダッシュボードからゲートウェイのメトリクスを参照できない場合は、​_「Usage Viewer (使用状況閲覧者)」_​権限を持っていることを確認してください。 権限の確認 Access Management で割り当てられているロールと権限を確認し、必要な​_「Usage Viewer (使用状況閲覧者)」_​ Runtime Manager 権限を持っていることを確認します。 これらの権限は、Anypoint Platform 管理者が Access Management で追加できます。 詳細は、​[「チーム権限の管理」](https://docs.mulesoft.com/jp/access-management/configure-teams#manage-team-permissions)​を参照してください。 ## [](#cant-change-gateway-properties)ゲートウェイプロパティが変更不可 ゲートウェイインスタンスの作成後は、​**\[Gateway Name (ゲートウェイ名)\]**​、​**\[Deployment Target (デプロイメント対象)\]**​、​**\[Flow plans (フロープラン)\]**​ などの一部の管理 Flex Gateway プロパティを編集できません。これらのプロパティを変更するには、管理 Flex Gateway を削除し、目的の値で再作成する必要があります。 ## [](#timeout-while-waiting-for-update)更新の待機中のタイムアウト 管理 Flex Gateway の更新または削除が保留されている場合は、状況を更新して数分待ってからもう一度確認してください。遅延は Anypoint Platform が大量のトラフィックを処理している場合に発生することがあります。 ## [](#gateway-missing-disabled)API Manager でのゲートウェイの欠落または無効 API インスタンスをゲートウェイに追加する際に、管理 Flex Gateway が API Manager の ​**\[Select a gateway (ゲートウェイを選択)\]**​ リストに見つからないか管理 Flex Gateway が無効になっている場合は、Runtime Manager でゲートウェイの状況を参照してゲートウェイが実行中であることを確認してください。ゲートウェイの状況が ​**\[Running (実行中)\]**​ でない場合は、Runtime Manager から問題を修正します。ゲートウェイの状況が ​**\[Running (実行中)\]**​ であっても API Manager で選択できない場合は、クラスターの問題がある可能性があるため、MuleSoft サポートに問い合わせる必要があります。 ## [](#same-path-error)API パスの競合 管理 Flex Gateway への API の際に API Manager で​**「This path conflicts with another API (このパスは別の API と競合しています)」**​エラーが表示される場合は、別のベースパスを選択する必要があります。Flex Gateway の各 API インスタンスはゲートウェイ内で一意である必要があります。この問題を修正するには、API パスを一意の値に変更するか、もう一方の API インスタンスのパスを編集します。エラーメッセージの ​**\[API\]**​ をクリックして、パスが競合している API インスタンスを参照して編集します。 # 自動インバウンドポリシーの適用 「​**組織の管理者**​」または「​**環境管理者**​」のユーザー、あるいは環境内の「​**ポリシーの管理**​」ロールを持つユーザーは、自動ポリシーの作成、編集、削除ができます。
自動ポリシーはインバウンド方向でのみサポートされます。
## [](#接続モードで自動ポリシーを適用する)接続モードで自動ポリシーを適用する 自動ポリシーを適用する手順は次のとおりです。 1. \[API Manager\] の左ナビゲーションメニューで ​**\[Automated Policies (自動ポリシー)\]**​ を選択します。 2. **\[Apply new automated policy (新しい自動ポリシーを割り当て)\]**​ をクリックします。 3. 提供ポリシーとして設定する提供ポリシーを選択します。 任意の内部ポリシーを自動ポリシーとして設定できます。 この作成方法については、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory) to learn how to configure each one of them, or [カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-overview)​を参照してください。 設定しているポリシーの種別が、アプリケーションのルールの影響を受ける API プロキシに提供ポリシーとしても存在する場合、続行する前に競合を解決する必要があります。解決方法についての詳細は、以下の​[\[Conflict Management\]](<#Conflict Management>)​セクションを参照してください。 4. **\[Apply (適用)\]**​ をクリックします。
自動ポリシーを本番環境に適用する前に下位の環境に適用し、自動ポリシーが既存の API コントラクトに影響しないことを確認することをお勧めします。
### [](#競合管理)競合管理 自動ポリシーは API レベルのポリシーよりも優先されるため、API レベルのポリシーとしてすでに適用されている自動ポリシーを追加すると、選択されたランタイム範囲を使用してデプロイされた API では、競合が発生します。 競合が検出された場合、競合する API のリストを含むポップアップが表示されます。メッセージが表示され、競合する最初の 10 個の API と合計数が示されます。次のエンドポイントを使用して、すべての API のリストにアクセスできます。 ```CURL curl -X GET \ https://anypoint.mulesoft.com/xapi/v1/automated-policies/{groupId}/{assetId}/conflicting-apis \ -H 'Authorization: Bearer {token}' ``` 競合を解決するには、設定済みの API のリストから API を選択し、競合するポリシーを手動で無効化または削除するか、設定済みの API に対してすべての競合するポリシーを上書きするように選択します。この最後のオプションを選択した場合、API の競合するポリシーは無効化されます。自動ポリシーを削除すると、API のポリシーは自動的に再有効化されます。 ### [](#新しい-api-のデプロイ)新しい API のデプロイ 新しい API を管理する場合、環境に適用された自動ポリシーの状況に関する情報を ​**\[Policies (ポリシー)\]**​ タブで参照できます。自動ポリシーは、アプリケーションが \[Active (アクティブ)\] の状況になるまで表示されません。 アプリケーションがデプロイされると、適用された自動ポリシーのリストが API の ​**\[Policies (ポリシー)\]**​ タブに表示されます。 環境に対する​**「ポリシーの参照」**​ロールを持つユーザーは、適用された自動ポリシーのリストを参照できます。 ### [](#カバー率の状況を表示する)カバー率の状況を表示する 自動ポリシーで API インスタンスがカバーされるかどうか、またはなぜカバーされないかを確認するには、API インスタンスの ​**\[Coverage status (カバー率の状況)\]**​ を参照します。通常、インスタンスがカバーされない原因はランタイム種別またはランタイムバージョンです。 自動ポリシーでカバーされる API インスタンスを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. \[API Administration (API 管理)\] で、​**\[Automated Policies (自動ポリシー)\]**​ をクリックします。 3. カバー率を表示するポリシーのその他のオプションボタン (​!["\[More Options (その他のオプション)](/mulesoft/current/ja-jp/gateway/1.10/_images/more-options-menu.png) メニューを表す横に表示された 3 つの円",1%,1%\]​) をクリックし、​**\[See covered APIs (カバーされる API を確認)\]**​ をクリックします。 4. **\[Coverage status (カバー率の状況)\]**​ 列で API インスタンスのカバー率の状況を参照します。
カバー率の状況で絞り込むには、カバー率の状況ドロップダウンをクリックして、カバー率の状況オプションを選択します。
### [](#適用されたポリシーの監査)適用されたポリシーの監査 自動ポリシーの影響を受けたすべての API のリストを監査し、取得することができます。レポートはランタイムバージョンおよび操作により絞り込むことができます。 環境内のすべての自動ポリシーのリストを取得する方法 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies?environmentId={envId} \ -H 'Authorization: Bearer {token}' ``` 自動ポリシーの範囲に含まれる API、または自動ポリシーが適用されない API のリストを取得する方法。 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies/{automatedPolicyId}/apis \ -H 'Authorization: Bearer {token}' ``` ## [](#ローカルモードで自動ポリシーを適用する)ローカルモードで自動ポリシーを適用する ローカルモードで実行されている Flex Gateway の自動ポリシーの適用については、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-secure-api-with-auto-policy)を参照してください。 ## [](#関連情報)関連情報 - [自動ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-automated-overview) # 自動インバウンドポリシーの適用 「​**組織の管理者**​」または「​**環境管理者**​」のユーザー、あるいは環境内の「​**ポリシーの管理**​」ロールを持つユーザーは、自動ポリシーの作成、編集、削除ができます。
自動ポリシーはインバウンド方向でのみサポートされます。
## [](#接続モードで自動ポリシーを適用する)接続モードで自動ポリシーを適用する 自動ポリシーを適用する手順は次のとおりです。 1. \[API Manager\] の左ナビゲーションメニューで ​**\[Automated Policies (自動ポリシー)\]**​ を選択します。 2. **\[Apply new automated policy (新しい自動ポリシーを割り当て)\]**​ をクリックします。 3. 提供ポリシーとして設定する提供ポリシーを選択します。 任意の内部ポリシーを自動ポリシーとして設定できます。 この作成方法については、​[インバウンドポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory) to learn how to configure each one of them, or [カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-overview)​を参照してください。 設定しているポリシーの種別が、アプリケーションのルールの影響を受ける API プロキシに提供ポリシーとしても存在する場合、続行する前に競合を解決する必要があります。解決方法についての詳細は、以下の​[\[Conflict Management\]](<#Conflict Management>)​セクションを参照してください。 4. **\[Apply (適用)\]**​ をクリックします。
自動ポリシーを本番環境に適用する前に下位の環境に適用し、自動ポリシーが既存の API コントラクトに影響しないことを確認することをお勧めします。
### [](#競合管理)競合管理 自動ポリシーは API レベルのポリシーよりも優先されるため、API レベルのポリシーとしてすでに適用されている自動ポリシーを追加すると、選択されたランタイム範囲を使用してデプロイされた API では、競合が発生します。 競合が検出された場合、競合する API のリストを含むポップアップが表示されます。メッセージが表示され、競合する最初の 10 個の API と合計数が示されます。次のエンドポイントを使用して、すべての API のリストにアクセスできます。 ```CURL curl -X GET \ https://anypoint.mulesoft.com/xapi/v1/automated-policies/{groupId}/{assetId}/conflicting-apis \ -H 'Authorization: Bearer {token}' ``` 競合を解決するには、設定済みの API のリストから API を選択し、競合するポリシーを手動で無効化または削除するか、設定済みの API に対してすべての競合するポリシーを上書きするように選択します。この最後のオプションを選択した場合、API の競合するポリシーは無効化されます。自動ポリシーを削除すると、API のポリシーは自動的に再有効化されます。 ### [](#新しい-api-のデプロイ)新しい API のデプロイ 新しい API を管理する場合、環境に適用された自動ポリシーの状況に関する情報を ​**\[Policies (ポリシー)\]**​ タブで参照できます。自動ポリシーは、アプリケーションが \[Active (アクティブ)\] の状況になるまで表示されません。 アプリケーションがデプロイされると、適用された自動ポリシーのリストが API の ​**\[Policies (ポリシー)\]**​ タブに表示されます。 環境に対する​**「ポリシーの参照」**​ロールを持つユーザーは、適用された自動ポリシーのリストを参照できます。 ### [](#カバー率の状況を表示する)カバー率の状況を表示する 自動ポリシーで API インスタンスがカバーされるかどうか、またはなぜカバーされないかを確認するには、API インスタンスの ​**\[Coverage status (カバー率の状況)\]**​ を参照します。通常、インスタンスがカバーされない原因はランタイム種別またはランタイムバージョンです。 自動ポリシーでカバーされる API インスタンスを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. \[API Administration (API 管理)\] で、​**\[Automated Policies (自動ポリシー)\]**​ をクリックします。 3. カバー率を表示するポリシーのその他のオプションボタン (​!["\[More Options (その他のオプション)](/mulesoft/current/ja-jp/gateway/1.9/_images/more-options-menu.png) メニューを表す横に表示された 3 つの円",1%,1%\]​) をクリックし、​**\[See covered APIs (カバーされる API を確認)\]**​ をクリックします。 4. **\[Coverage status (カバー率の状況)\]**​ 列で API インスタンスのカバー率の状況を参照します。
カバー率の状況で絞り込むには、カバー率の状況ドロップダウンをクリックして、カバー率の状況オプションを選択します。
### [](#適用されたポリシーの監査)適用されたポリシーの監査 自動ポリシーの影響を受けたすべての API のリストを監査し、取得することができます。レポートはランタイムバージョンおよび操作により絞り込むことができます。 環境内のすべての自動ポリシーのリストを取得する方法 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies?environmentId={envId} \ -H 'Authorization: Bearer {token}' ``` 自動ポリシーの範囲に含まれる API、または自動ポリシーが適用されない API のリストを取得する方法。 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies/{automatedPolicyId}/apis \ -H 'Authorization: Bearer {token}' ``` ## [](#ローカルモードで自動ポリシーを適用する)ローカルモードで自動ポリシーを適用する ローカルモードで実行されている Flex Gateway の自動ポリシーの適用については、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-secure-api-with-auto-policy)を参照してください。 ## [](#関連情報)関連情報 - [自動ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-automated-overview) # 自動ポリシー 自動ポリシーを使用して、Flex Gateway で実行されるすべての API に同じポリシーを適用することで、セキュリティ要件とロギング要件を強化します。ポリシーの自動化により、安全で一貫した API をすばやく設計、構築してデプロイできます。 自動ポリシーを使用すると、対象環境で重要なポリシーが自動的に適用され、エラーが減少するため、確信を持って API をデプロイできます。システム管理者は、ポリシーを忘れずに手動で挿入して共通の標準を適用する必要がなくなります。 すべての​[内部ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory)​と​[カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-custom-overview)​を自動ポリシーとして設定でき、それらを、環境下で実行されている API に適用できます。

自動ポリシーで保護されている API インスタンスには​アラート​を追加できません。
## [](#関連情報)関連情報 - [自動インバウンドポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.10/policies-automated-applying) # 自動ポリシー 自動ポリシーを使用して、Flex Gateway で実行されるすべての API に同じポリシーを適用することで、セキュリティ要件とロギング要件を強化します。ポリシーの自動化により、安全で一貫した API をすばやく設計、構築してデプロイできます。 自動ポリシーを使用すると、対象環境で重要なポリシーが自動的に適用され、エラーが減少するため、確信を持って API をデプロイできます。システム管理者は、ポリシーを忘れずに手動で挿入して共通の標準を適用する必要がなくなります。 すべての​[内部ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory)​と​[カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-overview)​を自動ポリシーとして設定でき、それらを、環境下で実行されている API に適用できます。

自動ポリシーで保護されている API インスタンスには​アラート​を追加できません。
## [](#関連情報)関連情報 - [自動ポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.8/policies-automated-applying) # 自動ポリシー 自動ポリシーを使用して、Flex Gateway で実行されるすべての API に同じポリシーを適用することで、セキュリティ要件とロギング要件を強化します。ポリシーの自動化により、安全で一貫した API をすばやく設計、構築してデプロイできます。 自動ポリシーを使用すると、対象環境で重要なポリシーが自動的に適用され、エラーが減少するため、確信を持って API をデプロイできます。システム管理者は、ポリシーを忘れずに手動で挿入して共通の標準を適用する必要がなくなります。 すべての​[内部ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory)​と​[カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-custom-overview)​を自動ポリシーとして設定でき、それらを、環境下で実行されている API に適用できます。

自動ポリシーで保護されている API インスタンスには​アラート​を追加できません。
## [](#関連情報)関連情報 - [自動インバウンドポリシーの適用](https://docs.mulesoft.com/jp/gateway/1.9/policies-automated-applying) # 自動ポリシーの適用 「​**組織の管理者**​」または「​**環境管理者**​」のユーザー、あるいは環境内の「​**ポリシーの管理**​」ロールを持つユーザーは、自動ポリシーの作成、編集、削除ができます。 ## [](#接続モードで自動ポリシーを適用する)接続モードで自動ポリシーを適用する 自動ポリシーを適用する手順は次のとおりです。 1. \[API Manager\] の左ナビゲーションメニューで ​**\[Automated Policies (自動ポリシー)\]**​ を選択します。 2. **\[Apply new automated policy (新しい自動ポリシーを割り当て)\]**​ をクリックします。 3. 提供ポリシーとして設定する提供ポリシーを選択します。 任意の内部ポリシーを自動ポリシーとして設定できます。 この作成方法については、​[内部ポリシーディレクトリ](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-directory) to learn how to configure each one of them, or [カスタムポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-custom-overview)​を参照してください。 設定しているポリシーの種別が、アプリケーションのルールの影響を受ける API プロキシに提供ポリシーとしても存在する場合、続行する前に競合を解決する必要があります。解決方法についての詳細は、以下の​[\[Conflict Management\]](<#Conflict Management>)​セクションを参照してください。 4. **\[Apply (適用)\]**​ をクリックします。
自動ポリシーを本番環境に適用する前に下位の環境に適用し、自動ポリシーが既存の API コントラクトに影響しないことを確認することをお勧めします。
### [](#競合管理)競合管理 自動ポリシーは API レベルのポリシーよりも優先されるため、API レベルのポリシーとしてすでに適用されている自動ポリシーを追加すると、選択されたランタイム範囲を使用してデプロイされた API では、競合が発生します。 競合が検出された場合、競合する API のリストを含むポップアップが表示されます。メッセージが表示され、競合する最初の 10 個の API と合計数が示されます。次のエンドポイントを使用して、すべての API のリストにアクセスできます。 ```CURL curl -X GET \ https://anypoint.mulesoft.com/xapi/v1/automated-policies/{groupId}/{assetId}/conflicting-apis \ -H 'Authorization: Bearer {token}' ``` 競合を解決するには、設定済みの API のリストから API を選択し、競合するポリシーを手動で無効化または削除するか、設定済みの API に対してすべての競合するポリシーを上書きするように選択します。この最後のオプションを選択した場合、API の競合するポリシーは無効化されます。自動ポリシーを削除すると、API のポリシーは自動的に再有効化されます。 ### [](#新しい-api-のデプロイ)新しい API のデプロイ 新しい API を管理する場合、環境に適用された自動ポリシーの状況に関する情報を ​**\[Policies (ポリシー)\]**​ タブで参照できます。自動ポリシーは、アプリケーションが \[Active (アクティブ)\] の状況になるまで表示されません。 アプリケーションがデプロイされると、適用された自動ポリシーのリストが API の ​**\[Policies (ポリシー)\]**​ タブに表示されます。 環境に対する​**「ポリシーの参照」**​ロールを持つユーザーは、適用された自動ポリシーのリストを参照できます。 ### [](#カバー率の状況を表示する)カバー率の状況を表示する 自動ポリシーで API インスタンスがカバーされるかどうか、またはなぜカバーされないかを確認するには、API インスタンスの ​**\[Coverage status (カバー率の状況)\]**​ を参照します。通常、インスタンスがカバーされない原因はランタイム種別またはランタイムバージョンです。 自動ポリシーでカバーされる API インスタンスを表示する手順は、次のとおりです。 1. **\[Anypoint Platform\]**​ > ​**\[API Manager\]**​ に移動します。 2. \[API Administration (API 管理)\] で、​**\[Automated Policies (自動ポリシー)\]**​ をクリックします。 3. カバー率を表示するポリシーのその他のオプションボタン (​![1%](/mulesoft/current/ja-jp/gateway/1.8/_images/more-options-menu.png)​) をクリックし、​**\[See covered APIs (カバーされる API を確認)\]**​ をクリックします。 4. **\[Coverage status (カバー率の状況)\]**​ 列で API インスタンスのカバー率の状況を参照します。
カバー率の状況で絞り込むには、カバー率の状況ドロップダウンをクリックして、カバー率の状況オプションを選択します。
### [](#適用されたポリシーの監査)適用されたポリシーの監査 自動ポリシーの影響を受けたすべての API のリストを監査し、取得することができます。レポートはランタイムバージョンおよび操作により絞り込むことができます。 環境内のすべての自動ポリシーのリストを取得する方法 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies?environmentId={envId} \ -H 'Authorization: Bearer {token}' ``` 自動ポリシーの範囲に含まれる API、または自動ポリシーが適用されない API のリストを取得する方法。 ```curl curl -X GET \ https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies/{automatedPolicyId}/apis \ -H 'Authorization: Bearer {token}' ``` ## [](#ローカルモードで自動ポリシーを適用する)ローカルモードで自動ポリシーを適用する ローカルモードで実行されている Flex Gateway の自動ポリシーの適用については、[リソースレベルの自動ポリシーを使用した API の保護](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-secure-api-with-auto-policy)を参照してください。 ## [](#関連情報)関連情報 - [自動ポリシー](https://docs.mulesoft.com/jp/gateway/1.8/policies-automated-overview) # 自己管理 Flex Gateway のアップグレード Flex Gateway は、Linux サービスとして、Docker コンテナで、または Kubernetes クラスターからアップグレードできます。

20%

25%

20%

Linux サービスとしてのアップグレード

Docker コンテナでのアップグレード

Kubernetes クラスターでのアップグレード
## [](#linux)Linux サービスとしてのアップグレード Flex Gateway は、標準パッケージとして配布できます。次の手順に従って、Flex Gateway を特定のバージョンまたは最新バージョンにアップグレードしてください。 Linux サービスとして Flex Gateway をアップグレードまたはダウングレードするには、次の手順を実行します。 1. 利用可能なパッケージのリストを更新します。 ```ssh sudo apt update ``` 選択可能なバージョンをリストするには、次のコマンドを実行します。 ```ssh apt list -a flex-gateway ``` 2. Flex Gateway を更新します。 - 最新バージョンに更新する場合: ```ssh sudo apt --only-upgrade -y install flex-gateway ``` - 特定バージョンに更新する場合: ```ssh sudo apt --only-upgrade -y install flex-gateway= ``` - ダウングレードバージョンに更新する場合: ```ssh sudo apt --only-upgrade -y --allow-downgrades install flex-gateway= ``` 3. サービスを再起動します。 ```ssh sudo systemctl restart flex-gateway ``` ## [](#docker)Docker コンテナでのアップグレード Docker コンテナを更新することはできませんので、新しいバージョンが必要な場合は、新しいイメージバージョンで新しいコンテナを作成し、古いコンテナを置き換えてください。 新しいイメージバージョンは、 [mulesoft/flex-gateway](https://hub.docker.com/r/mulesoft/flex-gateway)​ のリンクから入手できます。 ## [](#kubernetes)Kubernetes クラスターでのアップグレード 1. それぞれのチャートリポジトリでチャートを更新します。 ```ssh helm repo up ``` 2. 次のコマンドを (必要な箇所を実際の情報に置き換えて) 実行し、リリースを新しいバージョンの Helm チャートに更新します。 ```ssh helm upgrade -n flex-gateway/flex-gateway --wait ``` # 自己管理 Flex Gateway のアップグレード Flex Gateway は、Linux サービスとして、Docker コンテナで、または Kubernetes クラスターからアップグレードできます。

20%

25%

20%

Linux サービスとしてのアップグレード

Docker コンテナでのアップグレード

Kubernetes クラスターでのアップグレード
## [](#linux)Linux サービスとしてのアップグレード Flex Gateway は、標準パッケージとして配布できます。次の手順に従って、Flex Gateway を特定のバージョンまたは最新バージョンにアップグレードしてください。 Linux サービスとして Flex Gateway をアップグレードまたはダウングレードするには、次の手順を実行します。 1. 利用可能なパッケージのリストを更新します。 ```ssh sudo apt update ``` 選択可能なバージョンをリストするには、次のコマンドを実行します。 ```ssh apt list -a flex-gateway ``` 2. Flex Gateway を更新します。 - 最新バージョンに更新する場合: ```ssh sudo apt --only-upgrade -y install flex-gateway ``` - 特定バージョンに更新する場合: ```ssh sudo apt --only-upgrade -y install flex-gateway= ``` - ダウングレードバージョンに更新する場合: ```ssh sudo apt --only-upgrade -y --allow-downgrades install flex-gateway= ``` 3. サービスを再起動します。 ```ssh sudo systemctl restart flex-gateway ``` ## [](#docker)Docker コンテナでのアップグレード Docker コンテナを更新することはできませんので、新しいバージョンが必要な場合は、新しいイメージバージョンで新しいコンテナを作成し、古いコンテナを置き換えてください。 新しいイメージバージョンは、 [mulesoft/flex-gateway](https://hub.docker.com/r/mulesoft/flex-gateway)​ のリンクから入手できます。 ## [](#kubernetes)Kubernetes クラスターでのアップグレード 1. それぞれのチャートリポジトリでチャートを更新します。 ```ssh helm repo up ``` 2. 次のコマンドを (必要な箇所を実際の情報に置き換えて) 実行し、リリースを新しいバージョンの Helm チャートに更新します。 ```ssh helm upgrade -n flex-gateway/flex-gateway --wait ``` # 自己管理 Flex Gateway のアンインストール Linux サービスとして実行されている Flex Gateway は、コンテナまたは Kubernetes クラスターでアンインストールできます。

20%

25%

20%

Linux サービスとして実行されている Flex Gateway のアンインストール

Docker コンテナで実行されている Flex Gateway をアンインストールする

Kubernetes クラスターで実行されている Flex Gateway をアンインストールする
## [](#linux)Linux サービスとして実行されている Flex Gateway のアンインストール Flex Gateway は他のパッケージと同じようにアンインストールできます。 ```ssh sudo apt remove -y flex-gateway ``` ## [](#docker)Docker コンテナで実行されている Flex Gateway をアンインストールする Flex Gateway をアンインストールするには、Flex Gateway コンテナを停止して削除します。 1. 実行されているすべてのコンテナをりすとして Flex Gateway コンテナ ID を判断します。 ```ssh docker ps ``` 2. コンテナのリストで、アンインストールする Flex Gateway コンテナに関連付けられたコンテナ ID をメモします。 3. Flex Gateway コンテナを停止します。 ```ssh docker stop ``` ` ``` `実行中のリリースに ​my-release​ を更新します。すべてのリリースのリストを表示するには、コマンド ​helm list -A​ を使用します。 2. リリースの名前空間が指定されている場合は削除します。 ```ssh kubectl delete namespace gateway ``` 3. カスタムリソース定義を削除します。 ```ssh kubectl delete crds \ apiinstances.gateway.mulesoft.com \ configurations.gateway.mulesoft.com \ extensions.gateway.mulesoft.com \ policybindings.gateway.mulesoft.com \ services.gateway.mulesoft.com ``` # 自己管理 Flex Gateway のアンインストール Linux サービスとして実行されている Flex Gateway は、コンテナまたは Kubernetes クラスターでアンインストールできます。

20%

25%

20%

Linux サービスとして実行されている Flex Gateway のアンインストール

Docker コンテナで実行されている Flex Gateway をアンインストールする

Kubernetes クラスターで実行されている Flex Gateway をアンインストールする
## [](#linux)Linux サービスとして実行されている Flex Gateway のアンインストール Flex Gateway は他のパッケージと同じようにアンインストールできます。 ```ssh sudo apt remove -y flex-gateway ``` ## [](#docker)Docker コンテナで実行されている Flex Gateway をアンインストールする Flex Gateway をアンインストールするには、Flex Gateway コンテナを停止して削除します。 1. 実行されているすべてのコンテナをりすとして Flex Gateway コンテナ ID を判断します。 ```ssh docker ps ``` 2. コンテナのリストで、アンインストールする Flex Gateway コンテナに関連付けられたコンテナ ID をメモします。 3. Flex Gateway コンテナを停止します。 ```ssh docker stop ``` ` ``` `実行中のリリースに ​my-release​ を更新します。すべてのリリースのリストを表示するには、コマンド ​helm list -A​ を使用します。 2. リリースの名前空間が指定されている場合は削除します。 ```ssh kubectl delete namespace gateway ``` 3. カスタムリソース定義を削除します。 ```ssh kubectl delete crds \ apiinstances.gateway.mulesoft.com \ configurations.gateway.mulesoft.com \ extensions.gateway.mulesoft.com \ policybindings.gateway.mulesoft.com \ services.gateway.mulesoft.com ``` # 自己管理 Flex Gateway のインスタンスの削除 Runtime Manager でゲートウェイとレプリカを削除する手順は次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. 削除するゲートウェイのアクションメニューボタンをクリックします。 4. **\[Delete gateway (ゲートウェイを削除)\]**​ をクリックします。 削除するゲートウェイに API が関連付けられている場合は、Runtime Manager からメッセージが表示され、次のいずれかが要求されます。 - 関連付けられている API を別のゲートウェイに移動する。 - 関連付けられている API をすべて削除する。 関連付けられている API をすべて移動または削除したら、上記の手順でゲートウェイを削除して、削除を確認してください。 ## [](#flex-gateway-の状況)Flex Gateway の状況 次の表に、ゲートウェイの各状況の意味を示します。
状況名 説明

実行中

ゲートウェイはプラットフォームに接続済みであり、API を追加できます。

Not Running (非実行中)

ゲートウェイはプラットフォームに接続されていません。

Deleting (削除中)

ゲートウェイに対して削除処理が実行中です。

Deleted (削除済み)

ゲートウェイはプラットフォームから削除されました。API 要求や設定の変更は受け入れず、メトリクスのレポートも停止しています。
削除済みのゲートウェイの状況は、30 日間 ​`[Deleted (削除済み)]`​ と表示された後にゲートウェイリストから削除されます。
ゲートウェイを削除すると、設定履歴が失われ、復元することはできません。
# 自己管理 Flex Gateway のインスタンスの削除 Runtime Manager でゲートウェイとレプリカを削除する手順は次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Flex Gateways (Flex Gateway)\]**​ を選択します。 3. 削除するゲートウェイのアクションメニューボタンをクリックします。 4. **\[Delete gateway (ゲートウェイを削除)\]**​ をクリックします。 削除するゲートウェイに API が関連付けられている場合は、Runtime Manager からメッセージが表示され、次のいずれかが要求されます。 - 関連付けられている API を別のゲートウェイに移動する。 - 関連付けられている API をすべて削除する。 関連付けられている API をすべて移動または削除したら、上記の手順でゲートウェイを削除して、削除を確認してください。 ## [](#flex-gateway-の状況)Flex Gateway の状況 次の表に、ゲートウェイの各状況の意味を示します。
状況名 説明

実行中

ゲートウェイはプラットフォームに接続済みであり、API を追加できます。

Not Running (非実行中)

ゲートウェイはプラットフォームに接続されていません。

Deleting (削除中)

ゲートウェイに対して削除処理が実行中です。

Deleted (削除済み)

ゲートウェイはプラットフォームから削除されました。API 要求や設定の変更は受け入れず、メトリクスのレポートも停止しています。
削除済みのゲートウェイの状況は、30 日間 ​`[Deleted (削除済み)]`​ と表示された後にゲートウェイリストから削除されます。
ゲートウェイを削除すると、設定履歴が失われ、復元することはできません。
# 自己管理 Flex Gateway のセキュリティのベストプラクティス このページでは、Flex Gateway ランタイムデプロイメントでの業界標準への準拠を確保するためのベストプラクティスを提供します。 Flex Gateway デプロイメントはランタイムとコントロールプレーンで構成されます。設定データやログなどの情報は、mTLS 通信を介してコントロールプレーンの Anypoint Platform とランタイムプレーンの Flex Gateway 間で共有されます。ランタイムレイヤーでは、Flex Gateway によって受信トラフィックがオーケストレーションされ、アップストリームまたは API が保護されます。Flex Gateway は、YAML 登録ファイルを使用して Anypoint Platform に登録されます。Flex Gateway では Redis 共有ストレージを使用して他の Flex レプリカと通信するためのデータをキャッシュし、要求データをキャッシュします。次の図は、Flex Gateway デプロイメントを示しています。 ![security best practices](/mulesoft/current/ja-jp/gateway/1.10/_images/security-best-practices.png)
1 Anypoint Platform での Flex Gateway の保護
2 Flex Gateway の保護:

  1. Flex Gateway サービスポッドの保護

  2. Flex Gateway の更新
3 Flex Gateway 登録リソースの保護
4 Flex 証明書の更新
5 ペイロードデータの記録の回避
6 Redis 共有ストレージの保護
7 受信トラフィック (API コンシューマーから Flex Gateway) のフローの保護
8 アップストリームサービス (Flex Gateway から API プロバイダー) の保護​:

  1. Flex Gateway がローカルで使用可能なサービスの保護

  2. 外部サービスの保護
9 定期的なテストの実行
このページのガイドラインはすべての Flex Gateway ランタイム環境に適用されますが、図は Kubernetes 用にのみ提供されています。
## [](#secure-flex-gateway-in-anypoint-platform)Anypoint Platform での Flex Gateway の保護 Anypoint Platform の Flex Gateway には必ず最小権限の原理を適用してください。Flex Gateway へのアクセス権を持つユーザーは Flex Gateway の設定の詳細やログを参照できます。ランタイムを保守するユーザーのみに Flex Gateway へのアクセス権を制限するには、ユーザーとチームの権限を使用します。ゲートウェイ設定をデプロイまたは管理するユーザー以外には参照のみアクセス権を付与してください。 アクセス権を管理する方法については、[アクセス管理について](https://docs.mulesoft.com/jp/access-management/)を参照してください。 ## [](#secure-the-flex-gateway-registration-resource)Flex Gateway 登録リソースの保護 Flex Gateway では登録情報をローカルに保存します。この登録リソースには、Flex レプリカが Anypoint Platform と通信して自己認証するために使用する証明書が含まれます。Flex Gateway は mTLS を介して Anypoint Platform と通信します。 レプリカの未認証実行を防止するには、登録リソースへのアクセスを制限します。具体的には次の情報が保存されます。 - 必ず保管時のシークレットを暗号化し、登録リソースシークレットには最小権限を適用してください。 - ログイン情報や API キーなどの機密データは、AWS Secrets Manager、Azure Key Vault、HashiCorp Vault などのセキュアな Vault に保存してください。 - シークレットのハードコードは避け、環境変数は機密でない設定のみに使用してください。 - 設定ファイルの機密情報は暗号化してください。 Kubernetes デプロイメントのベストプラクティスについては、 [「Good practices for Kubernetes Secrets (Kubernetes シークレットのグッドプラクティス)」](https://kubernetes.io/docs/concepts/security/secrets-good-practices/)​を参照してください。 ## [](#renew-the-flex-certificate)Flex 証明書の更新 Anypoint Flex Gateway では、管理された PKI 証明書を使用して Anypoint Platform と通信します。この証明書は、Flex Gateway を登録するときに生成されます。有効期限より前に証明書を更新して、ランタイムがコントロールプレーンに接続できるようにしてください。 登録を更新する方法については、[自己管理 Flex Gateway の登録の更新](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-renew-certificate)を参照してください。 ## [](#update-your-flex-gateway)Flex Gateway の更新 MuleSoft では、Flex Gateway のセキュリティ更新を定期的に提供します。脆弱性を解決できるように、Flex Gateway を常に最新バージョンに更新してください。非互換性のリスクを低減するには、安全な変更プロセスに従って本番より先に Sandbox ランタイムをアップグレードしてください。 Flex Gateway の更新方法についての詳細は、[自己管理 Flex Gateway のアップグレード](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-upgrade)を参照してください。 ## [](#avoid-logging-payload-data)ペイロードデータの記録の回避 ランタイムログは lex Gateway ポッドの ​`stdout`​ を介して使用でき、接続モードでは Anypoint コントロールプレーンにあります。 ランタイムログが侵害されてクライアント情報が漏洩しないように、ペイロードデータをランタイムログに記録することは避けてください。 他のサードパーティ監視および分析プラットフォームを使用している場合は、アクセスレビューにかけることを検討してください。 ## [](#secure-flex-gateway-service-pods)Flex Gateway サービスポッドの保護 権限を持たない人が Flex Gateway 設定データにアクセスしたりランタイムを改ざんしたりできないようにするには、Flex Gateway ランタイムポッドへのアクセスを制限します。 Kubernetes デプロイメントでは、Kubernetes ロールベースのアクセス制御 (RBAC) を使用してポッドでのコマンド実行へのアクセスを制限します。詳細は、 [「Using RBAC Authorization (RBAC 認証の使用)」](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​を参照してください。 Kubernetes 以外のデプロイメントでは、セッションを開くための Flex Gateway 仮想マシンへのアクセスを制限します。 ## [](#secure-redis-shared-storage)Redis 共有ストレージの保護 Flex Gateway では接続モードでのみ Redis 共有ストレージを使用して要求データやランタイム設定をキャッシュします。未認証ユーザーであっても Flex 設定や要求処理キャッシュなどのキャッシュされた設定データを取得し、ランタイムを中断できます。不正なアクセスを防止するには、Redis サービスを保護する必要があります。 Redis 共有ストレージを保護するには、 [「Redis Recommended security practices (Redis 推奨セキュリティプラクティス)」](https://redis.io/docs/latest/operate/rs/security/recommended-security-practices/)​を参照してください。アクセス制限を有効にして、Flex Gateway 以外のソースからの Redis アクセスを制限します。脆弱性をさらに制限できるように、Redis は Flex Gateway デプロイメントとできるだけ近い場所にデプロイしてください。 ## [](#protect-the-flow-of-incoming-traffic)受信トラフィック (API コンシューマーから Flex Gateway) のフローの保護 受信トラフィックのフローを外部からの攻撃から保護する方法は、受信トラフィックのソースに応じて異なります。 公開インターネットから受信する要求の場合、トラフィックが Flex Gateway に到達する前に捕捉できるように最初の防衛線システムを設定します。Flex Gateway では API レベルの保護が提供されますが、最初の防衛線に関しては他の一般的な保護に依存します。次の保護があることを確認してください。 - ACL や DNS ファイアウォールなどのネットワークレベルの保護。通常のクラウドプロバイダーやサードパーティではこれらの保護を提供しています。 - DDoS 攻撃や Web アプリケーションファイアウォールに対する脅威保護などの第一線のアプリケーションレベルの保護。
外部ソースからの受信要求の処理に関するガイドラインについては、​ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている and ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている​を参照してください。
### [](#terminate-external-tls-at-point-of-entry)エントリポイントでの外部 TLS の終了 ファイアウォールで L7 トラフィックセキュリティインスペクションを実行できるようにするには、ファイアウォールレベルで外部 TLS 接続を終了します。コンシューマーによって認識される有効な証明機関 (CA) では通常、このエントリポイントの証明書を提供しています。 ファイアウォール、Flex Gateway、インフラストラクチャのその他のサービス間の内部通信に個別の証明書のセットを使用します。この通信では、内部機関または PKI が発行する両方の証明書で mTLS セキュリティを使用します。 インターネットに公開される証明書は内部では使用されず、内部で使用される証明書はインターネットには公開されません。内部と外部の証明書を分離することで、内部証明書が漏洩するリスクを防止します。 Flex Gateway はランタイム環境イングレスレイヤーと内部環境レイヤーの両方で使用できます。イングレスレイヤーの Flex Gateway の場合、ゲートウェイのスコープを TLS の終了、ルーティング、およびその他の基本的な保護に制限します。より多くの CPU およびメモリの負荷が大きい操作を内部 Flex Gateway にプッシュします。 ### [](#protect-apis-by-using-policies)ポリシーを使用した API の保護 ポリシーを適用して API の保護を強化します。Flex Gateway では​[内部ポリシー](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-directory)​が提供されており、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を使用してカスタムポリシーを開発できます。 ### [](#govern-apis-by-using-api-governance)API Governance を使用した API の管理 [Anypoint API Governance](https://docs.mulesoft.com/api-governance/)​ を使用して、MuleSoft、業種、組織のベストプラクティスに従って API を設計してデプロイできるようにします。 ## [](#protect-the-upstream-service)アップストリームサービス (Flex Gateway から API プロバイダー) の保護 Flex からアップストリームへのトラフィックのフローを保護する方法は、アップストリームサービスの場所に応じて異なります。 ### [](#protect-services-available-locally-to-flex-gateway)Flex Gateway がローカルで使用可能なサービスの保護 Flex Gateway と同じネットワークを共有するサービスでは、通常、セキュリティ制限が緩くなっています。 組織はプレーンまたは TLS 接続が適切であるかどうかを定義する必要があります。TLS を使用している場合は、Flex Gateway アウトバウンド TLS コンテキストを介して mTLS を設定します。TLS の設定についての詳細は、以下を参照してください。 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-tls-config) 同じネットワークの他のサービスからアップストリームサービスを保護するには、Flex Gateway からトラフィックを受け入れるようにアップストリームサービスを設定します。Kubernetes の場合は、ネットワークポリシーを使用してこれを設定します。
内部アップストリームサービスへの通信に関するガイドラインについては、​ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている and ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている​を参照してください。
### [](#protect-external-services)外部サービスの保護 同じネットワークにない外部サービスを保護する場合は、mTLS 通信を使用してサービスを接続します。ネットワーク間で非公開 VPC などの信頼済みネットワークリンクを設定し、Flex Gateway がサービスを公開インターネットに公開せずに安全にアップストリームサービスにアクセスできるようにします。
外部アップストリームサービスへの通信に関するガイドラインについては、​ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている and ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている​を参照してください。
## [](#perform-regular-testing)定期的なテストの実行 定期的な侵入および脆弱性テストを実行し、Flex Gateway デプロイメントや公開される API の新たな問題や再発した問題を特定してください。テストの際には、セキュリティに関する次の側面を考慮してください。 - Runtime Manager の Flex 登録、Anypoint Monitoring のログ、API Manager の API にアクセスできるようにする Anypoint Platform のユーザーアクセス制御。 - 機能やデータに影響するデプロイ済みの Flex Gateway へのアクセス。 - Flex ランタイム画使用する設定ファイル、特に登録ファイルへのアクセス。 - Redis 共有ストレージサービスへのアクセス。 - Flex Gateway でデプロイされる API へのアクセス。 - Flex Gateway API によって保護されるアップストリームサービスへのアクセス。 ## [](#関連情報)関連情報 - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-uc-overview) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.10/flex-architecture-shared-storage) # 自己管理 Flex Gateway のセキュリティのベストプラクティス このページでは、Flex Gateway ランタイムデプロイメントでの業界標準への準拠を確保するためのベストプラクティスを提供します。 Flex Gateway デプロイメントはランタイムとコントロールプレーンで構成されます。設定データやログなどの情報は、mTLS 通信を介してコントロールプレーンの Anypoint Platform とランタイムプレーンの Flex Gateway 間で共有されます。ランタイムレイヤーでは、Flex Gateway によって受信トラフィックがオーケストレーションされ、アップストリームまたは API が保護されます。Flex Gateway は、YAML 登録ファイルを使用して Anypoint Platform に登録されます。Flex Gateway では Redis 共有ストレージを使用して他の Flex レプリカと通信するためのデータをキャッシュし、要求データをキャッシュします。次の図は、Flex Gateway デプロイメントを示しています。 ![security best practices](/mulesoft/current/ja-jp/gateway/1.9/_images/security-best-practices.png)
1 Anypoint Platform での Flex Gateway の保護
2 Flex Gateway の保護:

  1. Flex Gateway サービスポッドの保護

  2. Flex Gateway の更新
3 Flex Gateway 登録リソースの保護
4 Flex 証明書の更新
5 ペイロードデータの記録の回避
6 Redis 共有ストレージの保護
7 受信トラフィック (API コンシューマーから Flex Gateway) のフローの保護
8 アップストリームサービス (Flex Gateway から API プロバイダー) の保護​:

  1. Flex Gateway がローカルで使用可能なサービスの保護

  2. 外部サービスの保護
9 定期的なテストの実行
このページのガイドラインはすべての Flex Gateway ランタイム環境に適用されますが、図は Kubernetes 用にのみ提供されています。
## [](#secure-flex-gateway-in-anypoint-platform)Anypoint Platform での Flex Gateway の保護 Anypoint Platform の Flex Gateway には必ず最小権限の原理を適用してください。Flex Gateway へのアクセス権を持つユーザーは Flex Gateway の設定の詳細やログを参照できます。ランタイムを保守するユーザーのみに Flex Gateway へのアクセス権を制限するには、ユーザーとチームの権限を使用します。ゲートウェイ設定をデプロイまたは管理するユーザー以外には参照のみアクセス権を付与してください。 アクセス権を管理する方法については、[アクセス管理について](https://docs.mulesoft.com/jp/access-management/)を参照してください。 ## [](#secure-the-flex-gateway-registration-resource)Flex Gateway 登録リソースの保護 Flex Gateway では登録情報をローカルに保存します。この登録リソースには、Flex レプリカが Anypoint Platform と通信して自己認証するために使用する証明書が含まれます。Flex Gateway は mTLS を介して Anypoint Platform と通信します。 レプリカの未認証実行を防止するには、登録リソースへのアクセスを制限します。具体的には次の情報が保存されます。 - 必ず保管時のシークレットを暗号化し、登録リソースシークレットには最小権限を適用してください。 - ログイン情報や API キーなどの機密データは、AWS Secrets Manager、Azure Key Vault、HashiCorp Vault などのセキュアな Vault に保存してください。 - シークレットのハードコードは避け、環境変数は機密でない設定のみに使用してください。 - 設定ファイルの機密情報は暗号化してください。 Kubernetes デプロイメントのベストプラクティスについては、 [「Good practices for Kubernetes Secrets (Kubernetes シークレットのグッドプラクティス)」](https://kubernetes.io/docs/concepts/security/secrets-good-practices/)​を参照してください。 ## [](#renew-the-flex-certificate)Flex 証明書の更新 Anypoint Flex Gateway では、管理された PKI 証明書を使用して Anypoint Platform と通信します。この証明書は、Flex Gateway を登録するときに生成されます。有効期限より前に証明書を更新して、ランタイムがコントロールプレーンに接続できるようにしてください。 登録を更新する方法については、[自己管理 Flex Gateway の登録の更新](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-renew-certificate)を参照してください。 ## [](#update-your-flex-gateway)Flex Gateway の更新 MuleSoft では、Flex Gateway のセキュリティ更新を定期的に提供します。脆弱性を解決できるように、Flex Gateway を常に最新バージョンに更新してください。非互換性のリスクを低減するには、安全な変更プロセスに従って本番より先に Sandbox ランタイムをアップグレードしてください。 Flex Gateway の更新方法についての詳細は、[自己管理 Flex Gateway のアップグレード](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-upgrade)を参照してください。 ## [](#avoid-logging-payload-data)ペイロードデータの記録の回避 ランタイムログは lex Gateway ポッドの ​`stdout`​ を介して使用でき、接続モードでは Anypoint コントロールプレーンにあります。 ランタイムログが侵害されてクライアント情報が漏洩しないように、ペイロードデータをランタイムログに記録することは避けてください。 他のサードパーティ監視および分析プラットフォームを使用している場合は、アクセスレビューにかけることを検討してください。 ## [](#secure-flex-gateway-service-pods)Flex Gateway サービスポッドの保護 権限を持たない人が Flex Gateway 設定データにアクセスしたりランタイムを改ざんしたりできないようにするには、Flex Gateway ランタイムポッドへのアクセスを制限します。 Kubernetes デプロイメントでは、Kubernetes ロールベースのアクセス制御 (RBAC) を使用してポッドでのコマンド実行へのアクセスを制限します。詳細は、 [「Using RBAC Authorization (RBAC 認証の使用)」](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​を参照してください。 Kubernetes 以外のデプロイメントでは、セッションを開くための Flex Gateway 仮想マシンへのアクセスを制限します。 ## [](#secure-redis-shared-storage)Redis 共有ストレージの保護 Flex Gateway では接続モードでのみ Redis 共有ストレージを使用して要求データやランタイム設定をキャッシュします。未認証ユーザーであっても Flex 設定や要求処理キャッシュなどのキャッシュされた設定データを取得し、ランタイムを中断できます。不正なアクセスを防止するには、Redis サービスを保護する必要があります。 Redis 共有ストレージを保護するには、 [「Redis Recommended security practices (Redis 推奨セキュリティプラクティス)」](https://redis.io/docs/latest/operate/rs/security/recommended-security-practices/)​を参照してください。アクセス制限を有効にして、Flex Gateway 以外のソースからの Redis アクセスを制限します。脆弱性をさらに制限できるように、Redis は Flex Gateway デプロイメントとできるだけ近い場所にデプロイしてください。 ## [](#protect-the-flow-of-incoming-traffic)受信トラフィック (API コンシューマーから Flex Gateway) のフローの保護 受信トラフィックのフローを外部からの攻撃から保護する方法は、受信トラフィックのソースに応じて異なります。 公開インターネットから受信する要求の場合、トラフィックが Flex Gateway に到達する前に捕捉できるように最初の防衛線システムを設定します。Flex Gateway では API レベルの保護が提供されますが、最初の防衛線に関しては他の一般的な保護に依存します。次の保護があることを確認してください。 - ACL や DNS ファイアウォールなどのネットワークレベルの保護。通常のクラウドプロバイダーやサードパーティではこれらの保護を提供しています。 - DDoS 攻撃や Web アプリケーションファイアウォールに対する脅威保護などの第一線のアプリケーションレベルの保護。
外部ソースからの受信要求の処理に関するガイドラインについては、​ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている and ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている​を参照してください。
### [](#terminate-external-tls-at-point-of-entry)エントリポイントでの外部 TLS の終了 ファイアウォールで L7 トラフィックセキュリティインスペクションを実行できるようにするには、ファイアウォールレベルで外部 TLS 接続を終了します。コンシューマーによって認識される有効な証明機関 (CA) では通常、このエントリポイントの証明書を提供しています。 ファイアウォール、Flex Gateway、インフラストラクチャのその他のサービス間の内部通信に個別の証明書のセットを使用します。この通信では、内部機関または PKI が発行する両方の証明書で mTLS セキュリティを使用します。 インターネットに公開される証明書は内部では使用されず、内部で使用される証明書はインターネットには公開されません。内部と外部の証明書を分離することで、内部証明書が漏洩するリスクを防止します。 Flex Gateway はランタイム環境イングレスレイヤーと内部環境レイヤーの両方で使用できます。イングレスレイヤーの Flex Gateway の場合、ゲートウェイのスコープを TLS の終了、ルーティング、およびその他の基本的な保護に制限します。より多くの CPU およびメモリの負荷が大きい操作を内部 Flex Gateway にプッシュします。 ### [](#protect-apis-by-using-policies)ポリシーを使用した API の保護 ポリシーを適用して API の保護を強化します。Flex Gateway では​[内部ポリシー](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-directory)​が提供されており、[Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview)を使用してカスタムポリシーを開発できます。 ### [](#govern-apis-by-using-api-governance)API Governance を使用した API の管理 [Anypoint API Governance](https://docs.mulesoft.com/api-governance/)​ を使用して、MuleSoft、業種、組織のベストプラクティスに従って API を設計してデプロイできるようにします。 ## [](#protect-the-upstream-service)アップストリームサービス (Flex Gateway から API プロバイダー) の保護 Flex からアップストリームへのトラフィックのフローを保護する方法は、アップストリームサービスの場所に応じて異なります。 ### [](#protect-services-available-locally-to-flex-gateway)Flex Gateway がローカルで使用可能なサービスの保護 Flex Gateway と同じネットワークを共有するサービスでは、通常、セキュリティ制限が緩くなっています。 組織はプレーンまたは TLS 接続が適切であるかどうかを定義する必要があります。TLS を使用している場合は、Flex Gateway アウトバウンド TLS コンテキストを介して mTLS を設定します。TLS の設定についての詳細は、以下を参照してください。 - [接続モードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-tls-config) - [ローカルモードでの Flex Gateway の TLS コンテキストの設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-tls-config) 同じネットワークの他のサービスからアップストリームサービスを保護するには、Flex Gateway からトラフィックを受け入れるようにアップストリームサービスを設定します。Kubernetes の場合は、ネットワークポリシーを使用してこれを設定します。
内部アップストリームサービスへの通信に関するガイドラインについては、​ユースケース 1: 組織が所有している API が組織が所有している API コンシューマーに公開されている and ユースケース 3: 組織以外が所有している API が組織が所有している API コンシューマーに公開されている​を参照してください。
### [](#protect-external-services)外部サービスの保護 同じネットワークにない外部サービスを保護する場合は、mTLS 通信を使用してサービスを接続します。ネットワーク間で非公開 VPC などの信頼済みネットワークリンクを設定し、Flex Gateway がサービスを公開インターネットに公開せずに安全にアップストリームサービスにアクセスできるようにします。
外部アップストリームサービスへの通信に関するガイドラインについては、​ユースケース 2: 組織が所有している API が組織以外が所有している API コンシューマーに公開されている and ユースケース 4: 組織以外が所有している API が組織以外が所有している API コンシューマーに公開されている​を参照してください。
## [](#perform-regular-testing)定期的なテストの実行 定期的な侵入および脆弱性テストを実行し、Flex Gateway デプロイメントや公開される API の新たな問題や再発した問題を特定してください。テストの際には、セキュリティに関する次の側面を考慮してください。 - Runtime Manager の Flex 登録、Anypoint Monitoring のログ、API Manager の API にアクセスできるようにする Anypoint Platform のユーザーアクセス制御。 - 機能やデータに影響するデプロイ済みの Flex Gateway へのアクセス。 - Flex ランタイム画使用する設定ファイル、特に登録ファイルへのアクセス。 - Redis 共有ストレージサービスへのアクセス。 - Flex Gateway でデプロイされる API へのアクセス。 - Flex Gateway API によって保護されるアップストリームサービスへのアクセス。 ## [](#関連情報)関連情報 - [インテグレーションユースケース](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-uc-overview) - [共有ストレージモデル](https://docs.mulesoft.com/jp/gateway/1.9/flex-architecture-shared-storage) # 自己管理 Flex Gateway のリソースのサイズ変更 Flex Gateway の使用を開始する前に、最適なパフォーマンスと自動スケーリング率が得られるように分析して設定を選択します。 レプリカノードのリソースを割り当てる際には、次のことを検討してください。 - API の数 - ノードに必要なメモリ量 - ノードの処理能力 - 各 API のポリシーの数 - 各ノードで処理するトラフィック量 - ノードが要求に応答するまでに要する時間 (レイテンシー) - ノードが処理するトラフィックの種別と、トラフィック内の次の要素: - ノードが処理する 1 秒あたりの要求数 (RPS) - 各要求のサイズ (バイト) ## [](#リソース)リソース 次の表は、環境に合わせてレプリカノードに対して割り当てる必要があるリソースを示しています。
ノードサイズ CPU RAM

小

1 ～ 2 コア

2 ～ 4 GB

中

2 ～ 4 コア

4 ～ 8 GB

大

8 ～ 16 コア

16 ～ 32 GB
IBM Power10 デプロイメントの場合、「大」ノードでは 5 ～ 16 個の CPU コアを割り当てます。
同じクラスターに属するノードは同じサイズである必要があります。
## [](#クラスターサイズ)クラスターサイズ 次の表は、適切なノードとクラスターサイズを示しています。
ノードサイズ API の数 ポリシーの数 予期されるレイテンシー 予期されるスループット 対象環境

小

< 100

4

< 30 ミリ秒

< 500 RPS

開発/テストクラスター

中

< 500

4

< 20 ミリ秒

< 2500 RPS

本番クラスター

大

> 500

4

< 10 ミリ秒

< 10000 RPS

重要性の高いクラスター
これらのサイズの数字はノードごとです。API 設定はクラスター内のすべてのノードに複製されます。たとえば、10 個の API をそれぞれ 3 個のポリシーを含めてデプロイした場合、10 個の API とそのポリシーがクラスター内の各ノードにデプロイされます。 トラフィックはクラスター内のすべてのノードに分散されます。小のクラスターノードでは 500 RPS までサポートされますが、クラスターに 2 つのノードがある場合は、クラスターで許可されるトラフィックの合計は 1000 RPS です (ノードごとに 500 RPS)。ノードあたりの推奨のトラフィックを超えると、最終的に CPU 使用量が増加することになります。この問題を回避するには、クラスター内のすべてのノードのサイズを増やすか、水平方向にスケールする必要があります。 CPU 使用量が多いと、レイテンシーが大きくなる可能性があります。このような場合は、水平スケーリングを続行するか、ノードサイズを増やしてください。 メモリ消費量が多いと、メモリ不足エラーが発生する場合があります。この問題を解決するには、メモリ割り当てまたはノードサイズを増やしてください。この状況では、水平スケーリングで問題を解決できないことがあります。まずメモリを増やして、後から水平方向にスケールする必要があります。 これらのガイドラインは、平均要求サイズが 1 KB で 4 つのポリシーが実装されているクラスターを対象としています。ユースケースに合わせてパラメーターを調整してください。 最も一般的に使用される標準ポリシーは次のとおりです。 - メッセージログ - レート制限 - JWT 検証 - ヘッダーの挿入 TLS の使用は、応答時間やプロセスの消費に影響します。 # 自己管理 Flex Gateway のリソースのサイズ変更 Flex Gateway の使用を開始する前に、最適なパフォーマンスと自動スケーリング率が得られるように分析して設定を選択します。 レプリカノードのリソースを割り当てる際には、次のことを検討してください。 - API の数 - ノードに必要なメモリ量 - ノードの処理能力 - 各 API のポリシーの数 - 各ノードで処理するトラフィック量 - ノードが要求に応答するまでに要する時間 (レイテンシー) - ノードが処理するトラフィックの種別と、トラフィック内の次の要素: - ノードが処理する 1 秒あたりの要求数 (RPS) - 各要求のサイズ (バイト) ## [](#リソース)リソース 次の表は、環境に合わせてレプリカノードに対して割り当てる必要があるリソースを示しています。
ノードサイズ CPU RAM

小

1 ～ 2 コア

2 ～ 4 GB

中

2 ～ 4 コア

4 ～ 8 GB

大

8 ～ 16 コア

16 ～ 32 GB
IBM Power10 デプロイメントの場合、「大」ノードでは 5 ～ 16 個の CPU コアを割り当てます。
同じクラスターに属するノードは同じサイズである必要があります。
## [](#クラスターサイズ)クラスターサイズ 次の表は、適切なノードとクラスターサイズを示しています。
ノードサイズ API の数 ポリシーの数 予期されるレイテンシー 予期されるスループット 対象環境

小

< 100

4

< 30 ミリ秒

< 500 RPS

開発/テストクラスター

中

< 500

4

< 20 ミリ秒

< 2500 RPS

本番クラスター

大

> 500

4

< 10 ミリ秒

< 10000 RPS

重要性の高いクラスター
これらのサイズの数字はノードごとです。API 設定はクラスター内のすべてのノードに複製されます。たとえば、10 個の API をそれぞれ 3 個のポリシーを含めてデプロイした場合、10 個の API とそのポリシーがクラスター内の各ノードにデプロイされます。 トラフィックはクラスター内のすべてのノードに分散されます。小のクラスターノードでは 500 RPS までサポートされますが、クラスターに 2 つのノードがある場合は、クラスターで許可されるトラフィックの合計は 1000 RPS です (ノードごとに 500 RPS)。ノードあたりの推奨のトラフィックを超えると、最終的に CPU 使用量が増加することになります。この問題を回避するには、クラスター内のすべてのノードのサイズを増やすか、水平方向にスケールする必要があります。 CPU 使用量が多いと、レイテンシーが大きくなる可能性があります。このような場合は、水平スケーリングを続行するか、ノードサイズを増やしてください。 メモリ消費量が多いと、メモリ不足エラーが発生する場合があります。この問題を解決するには、メモリ割り当てまたはノードサイズを増やしてください。この状況では、水平スケーリングで問題を解決できないことがあります。まずメモリを増やして、後から水平方向にスケールする必要があります。 これらのガイドラインは、平均要求サイズが 1 KB で 4 つのポリシーが実装されているクラスターを対象としています。ユースケースに合わせてパラメーターを調整してください。 最も一般的に使用される標準ポリシーは次のとおりです。 - メッセージログ - レート制限 - JWT 検証 - ヘッダーの挿入 TLS の使用は、応答時間やプロセスの消費に影響します。 # 自己管理 Flex Gateway の使用開始 このチュートリアルの目標は、Anypoint Flex Gateway をすばやく使い始めることです。このチュートリアルでは、Docker を使用して、接続モードで Flex Gateway をインストール、登録、実行する方法について説明します。さらに、基本認証ポリシーで保護された API をパブリッシュする方法についても説明します。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、次の準備が整っていることを確認します。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。まだ Anypoint Platform 組織を持っていない場合は、Anypoint Platform で [トライアル組織を作成](https://anypoint.mulesoft.com/login/signup)​してください。 - x86 プロセッサーを搭載した Linux マシン。M1 および M2 プロセッサーはサポートされていません。 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian Bookworm - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - Ubuntu Jammy - Docker のインストール。例については [「Docker Desktop」](https://www.docker.com/products/docker-desktop/)​を参照してください。 ## [](#flex-gateway-のダウンロード)Flex Gateway のダウンロード Flex Gateway Docker イメージをダウンロードするには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh docker pull mulesoft/flex-gateway:latest ```
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
## [](#flex-gateway-を登録する)Flex Gateway を登録する 1. 次のコマンドを実行して、新しいディレクトリを作成します。 ```ssh mkdir flex-registration ``` 2. 次のコマンドを実行して、新しいディレクトリに移動します。 ```ssh cd flex-registration ``` 3. Anypoint ユーザー名とパスワードを使用して、 [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインします。 4. **\[Runtime Manager\]**​ を選択します。 5. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 6. **\[Self-managed Flex Gateways (自己管理 Flex Gateway)\]**​ をクリックします。 7. **\[Add Gateway (ゲートウェイを追加)\]**​ をクリックします。 8. **\[Docker\]**​ を選択します。 9. **\[Register your gateway (ゲートウェイを登録)\]**​ セクションのコードブロックをコピーします。コードブロックには、一意の組織 ID とトークンが含まれています。 次の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページのスクリーンショットでは、コピーするコードブロックが強調表示されています。 ![Anypoint Platform を使用して Flex Gateway を登録するコマンドが含まれるコードブロック](/mulesoft/current/ja-jp/gateway/1.10/_images/gateway-quickstart-add-gateway.png) 10. コピーしたコードブロックをターミナルウィンドウで実行します。最初に ​``​ を ​`my-gw`​ などの名前に置き換えてください。
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
11. Runtime Manager のサイドバーナビゲーションで ​**\[Flex Gateways\]**​ を選択します。 登録した Flex Gateway がゲートウェイのリストに表示されます。 ## [](#flex-gateway-を実行する)Flex Gateway を実行する Flex Gateway を実行するには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8081:8081 \ mulesoft/flex-gateway ```
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
新しい Flex Gateway インスタンスがターミナルウィンドウで実行されます。
Flex Gateway インスタンスは、プロセスが停止されるかウィンドウが閉じられるまで、ターミナルウィンドウで実行を続けます。
## [](#シンプルな-api-のパブリッシュ)シンプルな API のパブリッシュ 1. Anypoint Platform メニューから ​**\[API Manager\]**​ を選択します。 2. **\[Add API (API を追加)\]**​ > ​**\[Add new API (新しい API を追加)\]**​ をクリックします。 3. **\[Add API (API を追加)\]**​ ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 4. **\[Select a gateway (ゲートウェイを選択)\]**​ セクションで登録済みゲートウェイを選択します。 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[Create New API (新しい API を作成)\]**​ をクリックします。 7. API 参照名を指定し、アセットタイプとして ​**\[HTTP API\]**​ を選択します。 8. **\[Next (次へ)\]**​ をクリックします。 9. **\[Endpoint (エンドポイント)\]**​ ページから、​**\[Implementation URI (実装 URI)\]**​ 項目に次の URI を入力します。 ```none https://jsonplaceholder.typicode.com/ ``` 10. **\[Port (ポート)\]**​ 項目に「​`8081`​」と入力します。 11. **\[Next (次へ)\]**​ をクリックします。 12. **\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 ゲートウェイインスタンスの Docker コンテナ内で、ポート ​`8081`​ の ​`localhost`​ に対して行われたすべての HTTP 要求が ​`jsonplaceholder`​ サービスにプロキシされるようになります。 13. API インスタンスをテストするには、新しいターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#基本認証ポリシーを使用して-api-を保護する)基本認証ポリシーを使用して API を保護する 1. **API Manager**​ を開いたまま、サイドナビゲーションパネルから ​**\[API Administration (API 管理)\]**​ を選択します。 2. 前のセクションで作成した API の名前を選択します。 3. サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 4. **\[Policies (ポリシー)\]**​ ページで、​**\[Add policy (ポリシーを追加)\]**​ をクリックします。 次の ​**\[Policies (ポリシー)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![\[Add policy (ポリシーを追加)\] ボタンのある \[Add policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-add-policy.png) 5. **\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ ポリシーを選択します。 6. **\[Next (次へ)\]**​ をクリックします。 7. **\[User Name (ユーザー名)\]**​ に「​`user`​」と入力します。 8. **\[User Password (ユーザーパスワード)\]**​ に「​`password`​」と入力します。 9. **\[Apply (適用)\]**​ をクリックします。 次の ​**\[Basic Authentication - Simple policy (基本認証 - 簡易ポリシー)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![\[User Password (ユーザーパスワード)\] 項目が選択されている \[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] ページ](_images/gateway-quickstart-config-basic-auth.png) 10. 認証を​_使用しないで_​ API インスタンスをテストするには、ターミナルウィンドウで次の ​`curl`​ コマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' ``` 要求には認証コンテキストが含まれていないため、コマンドは結果として ​`401 (Unauthorized)`​ 状況コードを出力します。 11. 認証を​_使用して_​ API インスタンスをテストするには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' -u user:password ```
user​ パラメーターと ​password​ パラメーターは、​API Manager​ 経由でポリシーを適用したときに指定した内容と一致する必要があります。
このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.10/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-set-up) # 自己管理 Flex Gateway の使用開始 このチュートリアルの目標は、Anypoint Flex Gateway をすばやく使い始めることです。このチュートリアルでは、Docker を使用して、接続モードで Flex Gateway をインストール、登録、実行する方法について説明します。さらに、基本認証ポリシーで保護された API をパブリッシュする方法についても説明します。 ## [](#始める前に)始める前に Flex Gateway の使用を始める前に、次の準備が整っていることを確認します。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。まだ Anypoint Platform 組織を持っていない場合は、Anypoint Platform で [トライアル組織を作成](https://anypoint.mulesoft.com/login/signup)​してください。 - x86 プロセッサーを搭載した Linux マシン。M1 および M2 プロセッサーはサポートされていません。 Flex Gateway は、以下の Long Term Support (LTS) バージョンの Linux で動作します。 - Amazon Linux 2023 - CentOS 8 - Debian (Bullseye, Bookworm) - Red Hat Enterprise Linux (9) - IBM Power (ppc64le) の Red Hat Enterprise Linux (9) - SUSE Linux Enterprise (SLES 15 SP3) - IBM Power (ppc64le) の SUSE Linux Enterprise (SLES 15 SP3) - Ubuntu (Focal, Jammy) - Docker のインストール。例については [「Docker Desktop」](https://www.docker.com/products/docker-desktop/)​を参照してください。 ## [](#flex-gateway-のダウンロード)Flex Gateway のダウンロード Flex Gateway Docker イメージをダウンロードするには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh docker pull mulesoft/flex-gateway:latest ```
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
## [](#flex-gateway-を登録する)Flex Gateway を登録する 1. 次のコマンドを実行して、新しいディレクトリを作成します。 ```ssh mkdir flex-registration ``` 2. 次のコマンドを実行して、新しいディレクトリに移動します。 ```ssh cd flex-registration ``` 3. Anypoint ユーザー名とパスワードを使用して、 [Anypoint Platform](https://anypoint.mulesoft.com/login/)​ にログインします。 4. **\[Runtime Manager\]**​ を選択します。 5. サイドナビゲーションパネルで、​**\[Flex Gateways\]**​ をクリックします。 6. **\[Self-managed Flex Gateways (自己管理 Flex Gateway)\]**​ をクリックします。 7. **\[Add Gateway (ゲートウェイを追加)\]**​ をクリックします。 8. **\[Docker\]**​ を選択します。 9. **\[Register your gateway (ゲートウェイを登録)\]**​ セクションのコードブロックをコピーします。コードブロックには、一意の組織 ID とトークンが含まれています。 次の ​**\[Add a Flex Gateway (Flex Gateway の追加)\]**​ ページのスクリーンショットでは、コピーするコードブロックが強調表示されています。 ![Anypoint Platform を使用して Flex Gateway を登録するコマンドが含まれるコードブロック](/mulesoft/current/ja-jp/gateway/1.9/_images/gateway-quickstart-add-gateway.png) 10. コピーしたコードブロックをターミナルウィンドウで実行します。最初に ​``​ を ​`my-gw`​ などの名前に置き換えてください。
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
11. Runtime Manager のサイドバーナビゲーションで ​**\[Flex Gateways\]**​ を選択します。 登録した Flex Gateway がゲートウェイのリストに表示されます。 ## [](#flex-gateway-を実行する)Flex Gateway を実行する Flex Gateway を実行するには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh docker run --rm \ -v "$(pwd)":/usr/local/share/mulesoft/flex-gateway/conf.d \ -p 8081:8081 \ mulesoft/flex-gateway ```
このコマンドの実行時にファイル権限の問題が発生した場合は、​sudo​ を使用してください。
新しい Flex Gateway インスタンスがターミナルウィンドウで実行されます。
Flex Gateway インスタンスは、プロセスが停止されるかウィンドウが閉じられるまで、ターミナルウィンドウで実行を続けます。
## [](#シンプルな-api-のパブリッシュ)シンプルな API のパブリッシュ 1. Anypoint Platform メニューから ​**\[API Manager\]**​ を選択します。 2. **\[Add API (API を追加)\]**​ をクリックし、​**\[Add new API (新しい API を追加)\]**​ をクリックします: ![\[Add new API (新しい API を追加)\] が選択されている \[Add API (API を追加)\] ページ](_images/gateway-quickstart-add-new-api.png) 3. **\[Add API (API を追加)\]**​ ページから、ランタイムとして ​**\[Flex Gateway\]**​ を選択します。 4. **\[Select a gateway (ゲートウェイを選択)\]**​ セクションで登録済みゲートウェイを選択します。 5. **\[Next (次へ)\]**​ をクリックします。 次の ​**\[Add API (API を追加)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![Flex Gateway ランタイムと my-gw ゲートウェイが選択されている \[Add API (API を追加)\]](_images/gateway-quickstart-select-gateway-for-api.png) 6. **\[Create New API (新しい API を作成)\]**​ をクリックします。 7. API 参照名を指定し、アセットタイプとして ​**\[HTTP API\]**​ を選択します。 8. **\[Next (次へ)\]**​ をクリックします。 9. **\[Endpoint (エンドポイント)\]**​ ページから、​**\[Implementation URI (実装 URI)\]**​ 項目に次の URI を入力します。 ```none https://jsonplaceholder.typicode.com/ ``` 10. **\[Port (ポート)\]**​ 項目に「​`8081`​」と入力します。 11. **\[Next (次へ)\]**​ をクリックします。 12. **\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 ゲートウェイインスタンスの Docker コンテナ内で、ポート ​`8081`​ の ​`localhost`​ に対して行われたすべての HTTP 要求が ​`jsonplaceholder`​ サービスにプロキシされるようになります。 13. API インスタンスをテストするには、新しいターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' ``` このコマンドは API への ​`GET`​ 要求を実行し、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#基本認証ポリシーを使用して-api-を保護する)基本認証ポリシーを使用して API を保護する 1. **API Manager**​ を開いたまま、サイドナビゲーションパネルから ​**\[API Administration (API 管理)\]**​ を選択します。 2. 前のセクションで作成した API の名前を選択します。 3. サイドナビゲーションパネルから ​**\[Policies (ポリシー)\]**​ を選択します。 4. **\[Policies (ポリシー)\]**​ ページで、​**\[Add policy (ポリシーを追加)\]**​ をクリックします。 次の ​**\[Policies (ポリシー)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![\[Add policy (ポリシーを追加)\] ボタンのある \[Add policy (ポリシーを追加)\] ページ](_images/gateway-quickstart-add-policy.png) 5. **\[Basic Authentication - Simple (基本認証 - シンプル)\]**​ ポリシーを選択します。 6. **\[Next (次へ)\]**​ をクリックします。 7. **\[User Name (ユーザー名)\]**​ に「​`user`​」と入力します。 8. **\[User Password (ユーザーパスワード)\]**​ に「​`password`​」と入力します。 9. **\[Apply (適用)\]**​ をクリックします。 次の ​**\[Basic Authentication - Simple policy (基本認証 - 簡易ポリシー)\]**​ ページのスクリーンショットでは、指定されたオプションが強調表示されています。 ![\[User Password (ユーザーパスワード)\] 項目が選択されている \[Configure Basic Authentication - Simple policy (基本認証 - 簡易ポリシーを設定)\] ページ](_images/gateway-quickstart-config-basic-auth.png) 10. 認証を​_使用しないで_​ API インスタンスをテストするには、ターミナルウィンドウで次の ​`curl`​ コマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' ``` 要求には認証コンテキストが含まれていないため、コマンドは結果として ​`401 (Unauthorized)`​ 状況コードを出力します。 11. 認証を​_使用して_​ API インスタンスをテストするには、ターミナルウィンドウで次のコマンドを実行します。 ```ssh curl -s -o /dev/null -w "%{http_code}\n" --request GET 'http://localhost:8081/' -u user:password ```
user​ パラメーターと ​password​ パラメーターは、​API Manager​ 経由でポリシーを適用したときに指定した内容と一致する必要があります。
このコマンドは、結果として成功を示す ​`200`​ 状況コードを出力します。 ## [](#次のステップ)次のステップ - [Flex Gateway の要件と制限](https://docs.mulesoft.com/jp/gateway/1.9/flex-review-prerequisites) - [自己管理 Flex Gateway の設定](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-set-up) # 自己管理 Flex Gateway の登録の更新 Anypoint Flex Gateway では、管理された PKI 証明書を使用して Anypoint Platform と通信します。この証明書は、Flex Gateway を接続モードまたはローカルモードで登録すると生成されます。証明書を更新すると、確実にアプリケーションを運用し続けることができます。 証明書の更新は、​`flexctl registration renew`​ コマンドを使用して登録を更新することで行います。 - `renew`​ コマンドにより、Runtime Manager を使用して既存の Flex Gateway 登録が更新されます。 - 認証では、ユーザー証明書または接続アプリケーションのログイン情報を使用して ​`renew`​ コマンドを実行します。ユーザーログイン情報を使用した認証には、​`--username`​ フラグと ​`--password`​ フラグが必要です。接続アプリケーションのログイン情報を使用した認証には、​`--client-id`​ フラグと ​`--client-secret`​ フラグが必要です。 `flexctl registration inspect`​ コマンドを使用して更新プロセスを確認します。 - `inspect`​ コマンドでは、​`renew`​ コマンドが成功したかどうかを確認するために使用できる登録情報が抽出されます。 - `inspect`​ コマンドを使用して、登録の更新が実際に必要かどうかを最初に判断することもできます。​`inspect`​ コマンドでは、証明書の有効期限が返されます。 - デフォルトの方法を使用して更新を確認 (調査) することも、既存の登録ファイルを指定することもできます。フラグを付けずに ​`inspect`​ コマンドを実行すると、このコマンドでデフォルトの方法を使用して登録状況が調査されます。 中断を回避する手順は、次のとおりです。 1. [最新バージョンの Flex Gateway をダウンロードします。](#before-you-begin) 2. Flex Gateway の登録を更新します。 2 つの方法のいずれかを選択します。 - [Anypoint Platform ユーザーログイン情報](#renew-with-user-password) - [接続アプリケーションのログイン情報](#renew-with-conn-app) 3. 更新プロセスが成功したことを確認します。 2 つの方法のいずれかを選択します。 - [デフォルトの方法](#inspect-with-custom-url) - [登録ファイル](#inspect-with-reg-file) ## [](#before-you-begin)始める前に 登録更新 ​`flexctl`​ コマンドを呼び出すには、最新バージョンの Flex Gateway をダウンロードしてください。このバージョンのゲートウェイを登録して実行する必要はありません。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) ## [](#renew-with-user-password)Anypoint Platform ユーザーログイン情報を使用して登録を更新する 1. `flex-renew-registration`​ という名前 (または同様の名前) の新しいディレクトリを作成します。この新しいディレクトリで ​`renew`​ コマンドを実行します。このコマンドは、新しい登録ファイルを作成します。

既存の登録ファイルが含まれているディレクトリで ​renew​ コマンドが実行されると、登録更新に失敗します。
2. 次のコマンドを使用します。 - Linux - Docker - Podman ```ssh flexctl registration renew --username= --password= \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/renew \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/renew \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 たとえば、​`/home/user/flex/registration.yaml`​ に現在の登録ファイルが含まれている場合は、​`/home/user/flex/`​ に移動して Anypoint Platform ログイン情報を使用して次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -u $UID -v "$(pwd)":/registration \ mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/registration/new \ /registration/registration.yaml ``` このコマンドでは、新しい登録ファイル ​`/home/user/flex/new/registration.yaml`​ が作成されます。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/renew:Z \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/renew \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。

ユーザーログイン情報を使用して ​renew​ コマンドを実行する前に、Anypoint Platform アカウントの MFA を無効にします。
3. コマンドを実行します。 出力には次のメッセージが含まれます。 ```text Registration renewal completed ``` 4. 新規作成された登録ファイルを実行時の登録ファイルの場所にコピーします。例: `/usr/local/share/mulesoft/flex-gateway/conf.d/registration.yaml` 5. Flex Gateway レプリカがすでに実行されている場合は、再起動します。 ## [](#renew-with-conn-app)接続アプリケーションのログイン情報を使用して登録を更新する 1. Anypoint Platform のユーザー名またはパスワードがない場合は、Anypoint アクセス管理から​[接続アプリケーションを設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​できます。 1. 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存してから、​`renew`​ コマンドでこれらのログイン情報を使用します。 2. `flex-renew-registration`​ という名前 (または同様の名前) の新しいディレクトリを作成します。この新しいディレクトリで ​`renew`​ コマンドを実行します。このコマンドは、新しい登録ファイルを作成します。

既存の登録ファイルが含まれているディレクトリで ​renew​ コマンドが実行されると、登録更新に失敗します。
3. 次のコマンドを使用します。 - Linux - Docker - Podman ```ssh flexctl registration renew --client-id= --client-secret= \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/renew \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/renew \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 たとえば、​`/home/user/flex/registration.yaml`​ に現在の登録ファイルが含まれている場合は、​`/home/user/flex/`​ に移動して接続アプリケーションのログイン情報を使用して次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -u $UID -v "$(pwd)":/registration \ mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/registration/new \ /registration/registration.yaml ``` このコマンドでは、新しい登録ファイル ​`/home/user/flex/new/registration.yaml`​ が作成されます。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/renew:Z \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/renew \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 4. コマンドを実行します。 出力には次のメッセージが含まれます。 ```text Registration renewal completed ``` 5. 新規作成された登録ファイルを実行時の登録ファイルの場所にコピーします。例: `/usr/local/share/mulesoft/flex-gateway/conf.d/registration.yaml` 6. Flex Gateway レプリカがすでに実行されている場合は、再起動します。 ## [](#inspect-with-custom-url)デフォルトの方法を使用した登録状況の確認 登録を調査するには、次のコマンドを実行します。 - Linux - Docker - Podman ```ssh flexctl registration inspect ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`exec`​ コマンドの一部として ​`inspect`​ を実行します。​``​ は実行中のコンテナ参照に置き換えます。 ```ssh docker exec -u $UID flexctl registration inspect ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`exec`​ コマンドの一部として ​`inspect`​ を実行します。​``​ は実行中のコンテナ参照に置き換えます。 ```ssh podman exec -u $UID flexctl registration inspect ``` 出力には証明書の有効期限の日付が含まれます。次に例を示します。 ```text {“expiration_date”: “2025-09-25 19:27:32 +0000 UTC”} ``` ## [](#inspect-with-reg-file)登録ファイルを使用した登録状況の確認 `registration.yaml`​ ファイルから情報を抽出して、登録を調査できます。パスとファイル名を指定します。 登録を調査するには、次のコマンドを実行します。 - Linux - Docker - Podman ```ssh flexctl registration inspect --file= ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`inspect`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration inspect --file= ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`inspect`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration inspect --file= ``` 出力には証明書の有効期限の日付が含まれます。 ```text {“expiration_date”: “2025-09-25 19:27:32 +0000 UTC”} ``` たとえば、現在のディレクトリに登録ファイルが含まれている場合は、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration \ -u $UID mulesoft/flex-gateway \ registration inspect --file=/registration/registration.yaml ``` ## [](#kubernetes-で実行されている-flex-gateway-の登録を確認する)Kubernetes で実行されている Flex Gateway の登録を確認する 次の例では、Flex Gateway が ​`ingress`​ リリース名を使用して ​`gateway`​ 名前空間にインストールされていて、登録が Kubernetes データベースに保存されているシナリオについて説明します。 1. 次の ​`kubectl`​ コマンドを使用して ​`registration.yaml`​ ファイルを復元します。 ```ssh kubectl -n gateway get secret "$(kubectl -n gateway get deployment ingress -o=jsonpath='{.spec.template.spec.volumes[?(@.name=="registration")].secret.secretName}')" -o=jsonpath='{.data.registration\.yaml}' | base64 --decode > registration.yaml ``` このコマンドにより、登録ファイルが ​`./registration.yaml`​ に保存されます。 2. 前のセクションで Docker について説明しているように、​`flexctl registration renew`​ コマンドを実行します。 - [Anypoint Platform ユーザーログイン情報を使用して更新する](#renew-with-user-password) - [接続アプリケーションのログイン情報を使用して更新する](#renew-with-conn-app) 3. 次の ​`helm`​ コマンドを使用して Flex Gateway をアップグレードします。 ```ssh helm get values -n gateway ingress > values.yaml \ && helm upgrade -n gateway ingress flex-gateway/flex-gateway --wait -f values.yaml --set-file registration.content=new/registration.yaml ``` ## [](#更新コマンドと検証コマンドを使用したヘルプの取得)更新コマンドと検証コマンドを使用したヘルプの取得 次の ​`help`​ コマンドを実行して使用方法に関する情報を確認できます。 - 更新 - Linux - Docker - Podman ```ssh flexctl registration renew --help ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh docker run --entrypoint flexctl mulesoft/flex-gateway registration renew --help ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh podman run --entrypoint flexctl docker.io/mulesoft/flex-gateway registration renew --help ``` - 検証 - Linux - Docker - Podman ```ssh flexctl registration inspect --help ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh docker run --entrypoint flexctl mulesoft/flex-gateway registration inspect --help ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh podman run --entrypoint flexctl docker.io/mulesoft/flex-gateway registration inspect --help ``` ## [](#期限切れの登録の更新)期限切れの登録の更新 接続モードで期限切れの証明書を使用して Flex Gateway を実行しようとすると、次の結果になります。 - 新規のレプリカは Anypoint Platform から API 設定のダウンロードに失敗するため、使用できなくなります。既存のクラスターは再読み込みに失敗します。 - ログとメトリクスは Anypoint Platform へのアップロードに失敗します。Anypoint Platform を使用したトラブルシューティングはできません。 - 測定情報 Anypoint Platform へのアップロードに失敗します。MuleSoft では使用量メトリクスの収集やレポートができません。 ローカルモードで期限切れの証明書を使用して Flex Gateway を実行しようとすると、次の結果になります。 - 測定情報 Anypoint Platform へのアップロードに失敗します。MuleSoft では使用量メトリクスの収集やレポートができません。 証明書の期限が切れていても ​`flexctl registration renew`​ を呼び出すことはでき、これによって期限切れの証明書が更新されます。 ## [](#関連情報)関連情報 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) # 自己管理 Flex Gateway の登録の更新 Anypoint Flex Gateway では、管理された PKI 証明書を使用して Anypoint Platform と通信します。この証明書は、Flex Gateway を接続モードまたはローカルモードで登録すると生成されます。証明書を更新すると、確実にアプリケーションを運用し続けることができます。 証明書の更新は、​`flexctl registration renew`​ コマンドを使用して登録を更新することで行います。 - `renew`​ コマンドにより、Runtime Manager を使用して既存の Flex Gateway 登録が更新されます。 - 認証では、ユーザー証明書または接続アプリケーションのログイン情報を使用して ​`renew`​ コマンドを実行します。ユーザーログイン情報を使用した認証には、​`--username`​ フラグと ​`--password`​ フラグが必要です。接続アプリケーションのログイン情報を使用した認証には、​`--client-id`​ フラグと ​`--client-secret`​ フラグが必要です。 `flexctl registration inspect`​ コマンドを使用して更新プロセスを確認します。 - `inspect`​ コマンドでは、​`renew`​ コマンドが成功したかどうかを確認するために使用できる登録情報が抽出されます。 - `inspect`​ コマンドを使用して、登録の更新が実際に必要かどうかを最初に判断することもできます。​`inspect`​ コマンドでは、証明書の有効期限が返されます。 - デフォルトの方法を使用して更新を確認 (調査) することも、既存の登録ファイルを指定することもできます。フラグを付けずに ​`inspect`​ コマンドを実行すると、このコマンドでデフォルトの方法を使用して登録状況が調査されます。 中断を回避する手順は、次のとおりです。 1. [最新バージョンの Flex Gateway をダウンロードします。](#before-you-begin) 2. Flex Gateway の登録を更新します。 2 つの方法のいずれかを選択します。 - [Anypoint Platform ユーザーログイン情報](#renew-with-user-password) - [接続アプリケーションのログイン情報](#renew-with-conn-app) 3. 更新プロセスが成功したことを確認します。 2 つの方法のいずれかを選択します。 - [デフォルトの方法](#inspect-with-custom-url) - [登録ファイル](#inspect-with-reg-file) ## [](#before-you-begin)始める前に 登録更新 ​`flexctl`​ コマンドを呼び出すには、最新バージョンの Flex Gateway をダウンロードしてください。このバージョンのゲートウェイを登録して実行する必要はありません。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) ## [](#renew-with-user-password)Anypoint Platform ユーザーログイン情報を使用して登録を更新する 1. `flex-renew-registration`​ という名前 (または同様の名前) の新しいディレクトリを作成します。この新しいディレクトリで ​`renew`​ コマンドを実行します。このコマンドは、新しい登録ファイルを作成します。

既存の登録ファイルが含まれているディレクトリで ​renew​ コマンドが実行されると、登録更新に失敗します。
2. 次のコマンドを使用します。 - Linux - Docker - Podman ```ssh flexctl registration renew --username= --password= \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/renew \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/renew \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 たとえば、​`/home/user/flex/registration.yaml`​ に現在の登録ファイルが含まれている場合は、​`/home/user/flex/`​ に移動して Anypoint Platform ログイン情報を使用して次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -u $UID -v "$(pwd)":/registration \ mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/registration/new \ /registration/registration.yaml ``` このコマンドでは、新しい登録ファイル ​`/home/user/flex/new/registration.yaml`​ が作成されます。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/renew:Z \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration renew \ --username= \ --password= \ --output-directory=/renew \ ``` ``​ と ​``​ は Anypoint Platform ユーザーログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。

ユーザーログイン情報を使用して ​renew​ コマンドを実行する前に、Anypoint Platform アカウントの MFA を無効にします。
3. コマンドを実行します。 出力には次のメッセージが含まれます。 ```text Registration renewal completed ``` 4. 新規作成された登録ファイルを実行時の登録ファイルの場所にコピーします。例: `/usr/local/share/mulesoft/flex-gateway/conf.d/registration.yaml` 5. Flex Gateway レプリカがすでに実行されている場合は、再起動します。 ## [](#renew-with-conn-app)接続アプリケーションのログイン情報を使用して登録を更新する 1. Anypoint Platform のユーザー名またはパスワードがない場合は、Anypoint アクセス管理から​[接続アプリケーションを設定](https://docs.mulesoft.com/jp/access-management/connected-apps-developers#create-a-connected-app)​できます。 1. 以下のスコープを含めます。 - Read Servers (サーバーの参照) - Manage Servers (サーバーの管理) - View Organization (組織の表示) 2. 設定する接続アプリケーションの ​**ID**​ と​**シークレット**​を保存してから、​`renew`​ コマンドでこれらのログイン情報を使用します。 2. `flex-renew-registration`​ という名前 (または同様の名前) の新しいディレクトリを作成します。この新しいディレクトリで ​`renew`​ コマンドを実行します。このコマンドは、新しい登録ファイルを作成します。

既存の登録ファイルが含まれているディレクトリで ​renew​ コマンドが実行されると、登録更新に失敗します。
3. 次のコマンドを使用します。 - Linux - Docker - Podman ```ssh flexctl registration renew --client-id= --client-secret= \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。 このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/renew \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/renew \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 たとえば、​`/home/user/flex/registration.yaml`​ に現在の登録ファイルが含まれている場合は、​`/home/user/flex/`​ に移動して接続アプリケーションのログイン情報を使用して次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -u $UID -v "$(pwd)":/registration \ mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/registration/new \ /registration/registration.yaml ``` このコマンドでは、新しい登録ファイル ​`/home/user/flex/new/registration.yaml`​ が作成されます。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`renew`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v "$(pwd)":/renew:Z \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration renew \ --client-id= \ --client-secret= \ --output-directory=/renew \ ``` ``​ と ​``​ は接続アプリケーションのログイン情報に置き換えます。 ``​ は既存の ​`registration.yaml`​ ファイルのパスとファイル名に置き換えます。コンテナファイルシステムでファイルを指定する必要があります。この場合は ​`/registration/registration.yaml`​ です。 4. コマンドを実行します。 出力には次のメッセージが含まれます。 ```text Registration renewal completed ``` 5. 新規作成された登録ファイルを実行時の登録ファイルの場所にコピーします。例: `/usr/local/share/mulesoft/flex-gateway/conf.d/registration.yaml` 6. Flex Gateway レプリカがすでに実行されている場合は、再起動します。 ## [](#inspect-with-custom-url)デフォルトの方法を使用した登録状況の確認 登録を調査するには、次のコマンドを実行します。 - Linux - Docker - Podman ```ssh flexctl registration inspect ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`exec`​ コマンドの一部として ​`inspect`​ を実行します。​``​ は実行中のコンテナ参照に置き換えます。 ```ssh docker exec -u $UID flexctl registration inspect ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`exec`​ コマンドの一部として ​`inspect`​ を実行します。​``​ は実行中のコンテナ参照に置き換えます。 ```ssh podman exec -u $UID flexctl registration inspect ``` 出力には証明書の有効期限の日付が含まれます。次に例を示します。 ```text {“expiration_date”: “2025-09-25 19:27:32 +0000 UTC”} ``` ## [](#inspect-with-reg-file)登録ファイルを使用した登録状況の確認 `registration.yaml`​ ファイルから情報を抽出して、登録を調査できます。パスとファイル名を指定します。 登録を調査するには、次のコマンドを実行します。 - Linux - Docker - Podman ```ssh flexctl registration inspect --file= ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`inspect`​ を呼び出します。 ```ssh docker run --entrypoint flexctl \ -v :/registration \ -u $UID mulesoft/flex-gateway \ registration inspect --file= ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`inspect`​ を呼び出します。 ```ssh podman run --entrypoint flexctl --userns=keep-id \ -v :/registration:Z \ -u $UID docker.io/mulesoft/flex-gateway \ registration inspect --file= ``` 出力には証明書の有効期限の日付が含まれます。 ```text {“expiration_date”: “2025-09-25 19:27:32 +0000 UTC”} ``` たとえば、現在のディレクトリに登録ファイルが含まれている場合は、次のコマンドを実行します。 ```ssh docker run --entrypoint flexctl \ -v "$(pwd)":/registration \ -u $UID mulesoft/flex-gateway \ registration inspect --file=/registration/registration.yaml ``` ## [](#kubernetes-で実行されている-flex-gateway-の登録を確認する)Kubernetes で実行されている Flex Gateway の登録を確認する 次の例では、Flex Gateway が ​`ingress`​ リリース名を使用して ​`gateway`​ 名前空間にインストールされていて、登録が Kubernetes データベースに保存されているシナリオについて説明します。 1. 次の ​`kubectl`​ コマンドを使用して ​`registration.yaml`​ ファイルを復元します。 ```ssh kubectl -n gateway get secret "$(kubectl -n gateway get deployment ingress -o=jsonpath='{.spec.template.spec.volumes[?(@.name=="registration")].secret.secretName}')" -o=jsonpath='{.data.registration\.yaml}' | base64 --decode > registration.yaml ``` このコマンドにより、登録ファイルが ​`./registration.yaml`​ に保存されます。 2. 前のセクションで Docker について説明しているように、​`flexctl registration renew`​ コマンドを実行します。 - [Anypoint Platform ユーザーログイン情報を使用して更新する](#renew-with-user-password) - [接続アプリケーションのログイン情報を使用して更新する](#renew-with-conn-app) 3. 次の ​`helm`​ コマンドを使用して Flex Gateway をアップグレードします。 ```ssh helm get values -n gateway ingress > values.yaml \ && helm upgrade -n gateway ingress flex-gateway/flex-gateway --wait -f values.yaml --set-file registration.content=new/registration.yaml ``` ## [](#更新コマンドと検証コマンドを使用したヘルプの取得)更新コマンドと検証コマンドを使用したヘルプの取得 次の ​`help`​ コマンドを実行して使用方法に関する情報を確認できます。 - 更新 - Linux - Docker - Podman ```ssh flexctl registration renew --help ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh docker run --entrypoint flexctl mulesoft/flex-gateway registration renew --help ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh podman run --entrypoint flexctl docker.io/mulesoft/flex-gateway registration renew --help ``` - 検証 - Linux - Docker - Podman ```ssh flexctl registration inspect --help ``` このコマンドの実行時にファイル権限の問題が発生した場合は、​`sudo`​ を使用してください。 コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh docker run --entrypoint flexctl mulesoft/flex-gateway registration inspect --help ``` コンテナで実行されている Flex Gateway の場合、コンテナの ​`run`​ コマンドの一部として ​`help`​ を呼び出します。 ```ssh podman run --entrypoint flexctl docker.io/mulesoft/flex-gateway registration inspect --help ``` ## [](#期限切れの登録の更新)期限切れの登録の更新 接続モードで期限切れの証明書を使用して Flex Gateway を実行しようとすると、次の結果になります。 - 新規のレプリカは Anypoint Platform から API 設定のダウンロードに失敗するため、使用できなくなります。既存のクラスターは再読み込みに失敗します。 - ログとメトリクスは Anypoint Platform へのアップロードに失敗します。Anypoint Platform を使用したトラブルシューティングはできません。 - 測定情報 Anypoint Platform へのアップロードに失敗します。MuleSoft では使用量メトリクスの収集やレポートができません。 ローカルモードで期限切れの証明書を使用して Flex Gateway を実行しようとすると、次の結果になります。 - 測定情報 Anypoint Platform へのアップロードに失敗します。MuleSoft では使用量メトリクスの収集やレポートができません。 証明書の期限が切れていても ​`flexctl registration renew`​ を呼び出すことはでき、これによって期限切れの証明書が更新されます。 ## [](#関連情報)関連情報 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) # 自己管理 Flex Gateway の設定 Anypoint Flex Gateway をセットアップするには、インストールと登録を行います。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.10/flex-install) - Linux でインストールします。Docker または Kubernetes 用にダウンロードします。 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-conn-reg-run) - Anypoint ユーザー名とパスワード、接続アプリケーション、またはトークンを使用して、接続モードで登録します。 - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-reg-run) - Anypoint ユーザー名とパスワード、接続アプリケーション、またはトークンを使用して、ローカルモードで登録します。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.10/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.10/flex-gateway-getting-started) # 自己管理 Flex Gateway の設定 Anypoint Flex Gateway をセットアップするには、インストールと登録を行います。 - [Flex Gateway のダウンロード](https://docs.mulesoft.com/jp/gateway/1.9/flex-install) - Linux でインストールします。Docker または Kubernetes 用にダウンロードします。 - [接続モードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-conn-reg-run) - Anypoint ユーザー名とパスワード、接続アプリケーション、またはトークンを使用して、接続モードで登録します。 - [ローカルモードでの Flex Gateway の登録と実行](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-reg-run) - Anypoint ユーザー名とパスワード、接続アプリケーション、またはトークンを使用して、ローカルモードで登録します。 ## [](#関連情報)関連情報 - [Flex Gateway の概要](https://docs.mulesoft.com/jp/gateway/1.9/) - [自己管理 Flex Gateway の使用開始](https://docs.mulesoft.com/jp/gateway/1.9/flex-gateway-getting-started) # 自己管理ゲートウェイのログの問題のトラブルシューティング Anypoint Flex Gateway のログを設定しているときに、正しくないディレクトリ権限などによるログの問題が発生することがあります。以下のトピックでは、ログの問題の考えられる原因とトラブルシューティング方法について説明します。 - [ログがサードパーティログサービスに表示されない](#third-party-service) - [VM での動作中にログが表示されない](#incorrect-permissions) ## [](#third-party-service)ログがサードパーティログサービスに表示されない ログ設定 YAML ファイルを適用すると、数分以内にログが表示され始めます。ログがサードパーティログサービスに表示されない場合は、次の手順を実行してください。 1. サードパーティサービスが実行されていることを確認します。 2. サービスが実行されている場合は、ランタイムログで設定エラーがないか確認します。 [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-view-logs). Additionally, for Flex Gateways running in Connected Mode, you can [view runtime logs in Runtime Manager](https://docs.mulesoft.com/jp/gateway/1.10/flex-view-logs-in-runtime-manager)​ の手順に従い、接続モードとローカルモードのどちらで実行されている Flex Gateway のランタイムログでも表示できます。 潜在的な設定エラーは、次のように表示されます。 \[flex-gateway-fluent\] \[2023/09/07 20:17:49\] \[error\] \[output:http:http.1\] hzk83039.live.dynatrace.com:443, HTTP status=401 \[flex-gateway-fluent\] {"error":{"code":401,"message":"Missing authorization parameter."}} \[flex-gateway-fluent\] \[2023/09/07 20:17:49\] \[ warn\] \[engine\] failed to flush chunk '20-1694117863.683606251.flb', retry in 7 seconds: task\_id=2, input=emitter\_for\_rewrite\_tag.11 > output=http.1 (out\_id=1) 3. 設定エラーがランタイムログに表示されているかどうかに関係なく、/var/tmp/mulesoft/flex-gateway/fluent-bit.conf ファイルを参照して設定値が正しいことを確認してください。 ## [](#incorrect-permissions)VM での動作中にログが表示されない アクセスログポリシーで対象ログディレクトリを指定した後で、ログファイルが表示されません。ログディレクトリの例は ​`/var/log`​ などです。 ### [](#原因)原因 ログ出力ディレクトリに ​`write`​ 権限が付与されていません。 ### [](#解決策)解決策 この問題を解決するには、出力ディレクトリに ​`write`​ 権限を付与する必要があります。 # 自己管理ゲートウェイのログの問題のトラブルシューティング Anypoint Flex Gateway のログを設定しているときに、正しくないディレクトリ権限などによるログの問題が発生することがあります。以下のトピックでは、ログの問題の考えられる原因とトラブルシューティング方法について説明します。 - [ログがサードパーティログサービスに表示されない](#third-party-service) - [VM での動作中にログが表示されない](#incorrect-permissions) ## [](#third-party-service)ログがサードパーティログサービスに表示されない ログ設定 YAML ファイルを適用すると、数分以内にログが表示され始めます。ログがサードパーティログサービスに表示されない場合は、次の手順を実行してください。 1. サードパーティサービスが実行されていることを確認します。 2. サービスが実行されている場合は、ランタイムログで設定エラーがないか確認します。 [標準出力ログの表示](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-view-logs). Additionally, for Flex Gateways running in Connected Mode, you can [view runtime logs in Runtime Manager](https://docs.mulesoft.com/jp/gateway/1.9/flex-view-logs-in-runtime-manager)​ の手順に従い、接続モードとローカルモードのどちらで実行されている Flex Gateway のランタイムログでも表示できます。 潜在的な設定エラーは、次のように表示されます。 \[flex-gateway-fluent\] \[2023/09/07 20:17:49\] \[error\] \[output:http:http.1\] hzk83039.live.dynatrace.com:443, HTTP status=401 \[flex-gateway-fluent\] {"error":{"code":401,"message":"Missing authorization parameter."}} \[flex-gateway-fluent\] \[2023/09/07 20:17:49\] \[ warn\] \[engine\] failed to flush chunk '20-1694117863.683606251.flb', retry in 7 seconds: task\_id=2, input=emitter\_for\_rewrite\_tag.11 > output=http.1 (out\_id=1) 3. 設定エラーがランタイムログに表示されているかどうかに関係なく、/var/tmp/mulesoft/flex-gateway/fluent-bit.conf ファイルを参照して設定値が正しいことを確認してください。 ## [](#incorrect-permissions)VM での動作中にログが表示されない アクセスログポリシーで対象ログディレクトリを指定した後で、ログファイルが表示されません。ログディレクトリの例は ​`/var/log`​ などです。 ### [](#原因)原因 ログ出力ディレクトリに ​`write`​ 権限が付与されていません。 ### [](#解決策)解決策 この問題を解決するには、出力ディレクトリに ​`write`​ 権限を付与する必要があります。 # 複数のアップストリームサービスのトラフィック管理

ポリシー名

複数のアップストリームサービスのトラフィック管理

概要

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません。

次の情報は、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで実行されている Flex Gateway 用に複数のアップストリームサービスを設定するには、​「Multiple Upstream Services for Flex Gateway Running in Connected Mode (接続モードで実行されている Flex Gateway 用の複数のアップストリームサービス)」​を参照してください。
## [](#概要)概要 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。加重率の追加については、[複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-traffic-management)を参照してください。 `ApiInstance`​ に ​`spec.services`​ が含まれていない場合に要求を ​`Service`​ に転送できるようにするには、複数のアップストリームサービスポリシーのトラフィック管理 (​`route`​) ポリシーを使用して ​`PolicyBinding`​ 設定を定義する必要があります。カスタムポリシーで要求を管理している場合は、​`route`​ ポリシーを設定する必要はありません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 以下のポリシー定義とパラメーターの表を参照してください。 policyRef: name: route config: destinationPath: // OPTIONAL, default: "/" destinationRef: name: // REQUIRED kind: // OPTIONAL, default: "Service" namespace: // OPTIONAL, default: "" rules: - path: // OPTIONAL, Example: (.\*) methods: // OPTIONAL, Example: GET|POST headers: : // OPTIONAL host: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

destinationPath

省略可能

"/"

アップストリームサービスのパス

destinationRef.name

必須

なし

Service​ 設定リソースで定義されているアップストリームサービスの名前

destinationRef.kind

省略可能

"Service"

destinationRef.namespace

省略可能

""

rules

省略可能

空

このルートのルールセットの配列。
各ルートで複数のルールセットをサポートできます。

rules.path

省略可能

空

ルートがサービスできる要求パス。
ルールセットごとに 1 つの「URI テンプレート正規表現」パスしか定義できません。定義済みのパスがある要求しかこのルートには送信できません。

rules.methods

省略可能

空

ルートがサービスできる要求メソッドの種別を定義する配列。
ルールセットごとに複数のメソッドを選択できます。定義済みのメソッドのいずれかである要求しかこのルートには送信できません。サポートされている値は ​GET​、​POST​、​PUT​、​PATCH​、​DELETE​、​OPTIONS​、​HEAD​、​TRACE​、​CONNECT​ です。

rules.headers

省略可能

空

このルートが要求をサービスするために存在している必要があるヘッダーと正規表現を定義する配列。
指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。

rules.host

省略可能

空

ルートがサービスできる要求ホスト URL。
ルールセットごとに 1 つのホスト URL しか定義できません。定義済みのホストから行われる要求しかこのルートには送信できません。
### [](#リソースの設定例)リソースの設定例 `spec.services`​ パラメーターが含まれない ​`ApiInstance`​ 設定を定義できます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: ingress-http spec: address: http://0.0.0.0:8080/api ``` `spec.services`​ パラメーターがない場合、​`PolicyBinding`​ 設定で ​`route`​ ポリシーを定義する必要があります。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-httpbin-route spec: targetRef: name: ingress-http policyRef: name: route config: destinationPath: /orders destinationRef: name: orders-svc rules: - path: /foo(/.*) ``` 関連する ​`Service`​ 設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: orders-svc spec: address: https://orders.svc.local:443/ ``` ## [](#要求パスの決定)要求パスの決定 次の表で、ルーティングと要求のパスの想定される変換を決定する属性の例を使用して、考えられるすべてのパラメーターの組み合わせを示しています。列は、前の設定例の属性のデータ値を参照しています。
ApiInstance .address .path PolicyBinding(route) .rules .path PolicyBinding(route) .config .destinationPath Input Path (入力パス) Output Path (出力パス)

<empty>

/api/.*

<empty>

/api/foo/bar

/api/foo/bar

<empty>

/api(/.*)

<empty>

/api/foo/bar

/foo/bar

<empty>

/api/.*

/orders

/api/foo/bar

/orders/api/foo/bar

<empty>

/api(/.*)

/orders

/api/foo/bar

/orders/foo/bar

/api

/foo/.*

<empty>

/api/foo/bar

/foo/bar

/api

/foo(/.*)

<empty>

/api/foo/bar

/bar

/api

/foo/.*

/orders

/api/foo/bar

/orders/foo/bar

/api

/foo(/.*)

/orders

/api/foo/bar

/orders/bar

/api

/api/foo/.*

/orders

/api/foo/bar

<no match> (/api/api/foo/bar などのパスを想定)

/api

/foo(/.)/bar(/.)

<empty>

/api/foo/abc/bar/def

/abc/def

/api

/foo(/.)/bar(/.)

/orders

/api/foo/abc/bar/def

/orders/abc/def
## [](#関連情報)関連情報 - [複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-traffic-management) - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-api-multiple-services) # 複数のアップストリームサービスのトラフィック管理

ポリシー名

複数のアップストリームサービスのトラフィック管理

概要

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません。

次の情報は、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで実行されている Flex Gateway 用に複数のアップストリームサービスを設定するには、​「Multiple Upstream Services for Flex Gateway Running in Connected Mode (接続モードで実行されている Flex Gateway 用の複数のアップストリームサービス)」​を参照してください。
## [](#概要)概要 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。加重率の追加については、[複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-traffic-management)を参照してください。 `ApiInstance`​ に ​`spec.services`​ が含まれていない場合に要求を ​`Service`​ に転送できるようにするには、複数のアップストリームサービスポリシーのトラフィック管理 (​`route`​) ポリシーを使用して ​`PolicyBinding`​ 設定を定義する必要があります。カスタムポリシーで要求を管理している場合は、​`route`​ ポリシーを設定する必要はありません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 以下のポリシー定義とパラメーターの表を参照してください。 policyRef: name: route config: destinationPath: // OPTIONAL, default: "/" destinationRef: name: // REQUIRED kind: // OPTIONAL, default: "Service" namespace: // OPTIONAL, default: "" rules: - path: // OPTIONAL, Example: (.\*) methods: // OPTIONAL, Example: GET|POST headers: : // OPTIONAL host: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

destinationPath

省略可能

"/"

アップストリームサービスのパス

destinationRef.name

必須

なし

Service​ 設定リソースで定義されているアップストリームサービスの名前

destinationRef.kind

省略可能

"Service"

destinationRef.namespace

省略可能

""

rules

省略可能

空

このルートのルールセットの配列。
各ルートで複数のルールセットをサポートできます。

rules.path

省略可能

空

ルートがサービスできる要求パス。
ルールセットごとに 1 つの「URI テンプレート正規表現」パスしか定義できません。定義済みのパスがある要求しかこのルートには送信できません。

rules.methods

省略可能

空

ルートがサービスできる要求メソッドの種別を定義する配列。
ルールセットごとに複数のメソッドを選択できます。定義済みのメソッドのいずれかである要求しかこのルートには送信できません。サポートされている値は ​GET​、​POST​、​PUT​、​PATCH​、​DELETE​、​OPTIONS​、​HEAD​、​TRACE​、​CONNECT​ です。

rules.headers

省略可能

空

このルートが要求をサービスするために存在している必要があるヘッダーと正規表現を定義する配列。
指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。

rules.host

省略可能

空

ルートがサービスできる要求ホスト URL。
ルールセットごとに 1 つのホスト URL しか定義できません。定義済みのホストから行われる要求しかこのルートには送信できません。
### [](#リソースの設定例)リソースの設定例 `spec.services`​ パラメーターが含まれない ​`ApiInstance`​ 設定を定義できます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: ingress-http spec: address: http://0.0.0.0:8080/api ``` `spec.services`​ パラメーターがない場合、​`PolicyBinding`​ 設定で ​`route`​ ポリシーを定義する必要があります。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-httpbin-route spec: targetRef: name: ingress-http policyRef: name: route config: destinationPath: /orders destinationRef: name: orders-svc rules: - path: /foo(/.*) ``` 関連する ​`Service`​ 設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: orders-svc spec: address: https://orders.svc.local:443/ ``` ## [](#要求パスの決定)要求パスの決定 次の表で、ルーティングと要求のパスの想定される変換を決定する属性の例を使用して、考えられるすべてのパラメーターの組み合わせを示しています。列は、前の設定例の属性のデータ値を参照しています。
ApiInstance .address .path PolicyBinding(route) .rules .path PolicyBinding(route) .config .destinationPath Input Path (入力パス) Output Path (出力パス)

<empty>

/api/.*

<empty>

/api/foo/bar

/api/foo/bar

<empty>

/api(/.*)

<empty>

/api/foo/bar

/foo/bar

<empty>

/api/.*

/orders

/api/foo/bar

/orders/api/foo/bar

<empty>

/api(/.*)

/orders

/api/foo/bar

/orders/foo/bar

/api

/foo/.*

<empty>

/api/foo/bar

/foo/bar

/api

/foo(/.*)

<empty>

/api/foo/bar

/bar

/api

/foo/.*

/orders

/api/foo/bar

/orders/foo/bar

/api

/foo(/.*)

/orders

/api/foo/bar

/orders/bar

/api

/api/foo/.*

/orders

/api/foo/bar

<no match> (/api/api/foo/bar などのパスを想定)

/api

/foo(/.)/bar(/.)

<empty>

/api/foo/abc/bar/def

/abc/def

/api

/foo(/.)/bar(/.)

/orders

/api/foo/abc/bar/def

/orders/abc/def
## [](#関連情報)関連情報 - [複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-traffic-management) - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-api-multiple-services) # 複数のアップストリームサービスのトラフィック管理

ポリシー名

複数のアップストリームサービスのトラフィック管理

概要

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの API インスタンストラフィックを管理する

使用可能な最小 Flex Gateway バージョン

v1.0.0

返される状況コード

このポリシーの戻りコードは存在しません。

次の情報は、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで実行されている Flex Gateway 用に複数のアップストリームサービスを設定するには、​「Multiple Upstream Services for Flex Gateway Running in Connected Mode (接続モードで実行されている Flex Gateway 用の複数のアップストリームサービス)」​を参照してください。
## [](#概要)概要 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。加重率の追加については、[複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-traffic-management)を参照してください。 `ApiInstance`​ に ​`spec.services`​ が含まれていない場合に要求を ​`Service`​ に転送できるようにするには、複数のアップストリームサービスポリシーのトラフィック管理 (​`route`​) ポリシーを使用して ​`PolicyBinding`​ 設定を定義する必要があります。カスタムポリシーで要求を管理している場合は、​`route`​ ポリシーを設定する必要はありません。 ## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 以下のポリシー定義とパラメーターの表を参照してください。 policyRef: name: route config: destinationPath: // OPTIONAL, default: "/" destinationRef: name: // REQUIRED kind: // OPTIONAL, default: "Service" namespace: // OPTIONAL, default: "" rules: - path: // OPTIONAL, Example: (.\*) methods: // OPTIONAL, Example: GET|POST headers: : // OPTIONAL host: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

destinationPath

省略可能

"/"

アップストリームサービスのパス

destinationRef.name

必須

なし

Service​ 設定リソースで定義されているアップストリームサービスの名前

destinationRef.kind

省略可能

"Service"

destinationRef.namespace

省略可能

""

rules

省略可能

空

このルートのルールセットの配列。
各ルートで複数のルールセットをサポートできます。

rules.path

省略可能

空

ルートがサービスできる要求パス。
ルールセットごとに 1 つの「URI テンプレート正規表現」パスしか定義できません。定義済みのパスがある要求しかこのルートには送信できません。

rules.methods

省略可能

空

ルートがサービスできる要求メソッドの種別を定義する配列。
ルールセットごとに複数のメソッドを選択できます。定義済みのメソッドのいずれかである要求しかこのルートには送信できません。サポートされている値は ​GET​、​POST​、​PUT​、​PATCH​、​DELETE​、​OPTIONS​、​HEAD​、​TRACE​、​CONNECT​ です。

rules.headers

省略可能

空

このルートが要求をサービスするために存在している必要があるヘッダーと正規表現を定義する配列。
指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。

rules.host

省略可能

空

ルートがサービスできる要求ホスト URL。
ルールセットごとに 1 つのホスト URL しか定義できません。定義済みのホストから行われる要求しかこのルートには送信できません。
### [](#リソースの設定例)リソースの設定例 `spec.services`​ パラメーターが含まれない ​`ApiInstance`​ 設定を定義できます。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: ApiInstance metadata: name: ingress-http spec: address: http://0.0.0.0:8080/api ``` `spec.services`​ パラメーターがない場合、​`PolicyBinding`​ 設定で ​`route`​ ポリシーを定義する必要があります。 ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: PolicyBinding metadata: name: ingress-httpbin-route spec: targetRef: name: ingress-http policyRef: name: route config: destinationPath: /orders destinationRef: name: orders-svc rules: - path: /foo(/.*) ``` 関連する ​`Service`​ 設定: ```yaml apiVersion: gateway.mulesoft.com/v1alpha1 kind: Service metadata: name: orders-svc spec: address: https://orders.svc.local:443/ ``` ## [](#要求パスの決定)要求パスの決定 次の表で、ルーティングと要求のパスの想定される変換を決定する属性の例を使用して、考えられるすべてのパラメーターの組み合わせを示しています。列は、前の設定例の属性のデータ値を参照しています。
ApiInstance .address .path PolicyBinding(route) .rules .path PolicyBinding(route) .config .destinationPath Input Path (入力パス) Output Path (出力パス)

<empty>

/api/.*

<empty>

/api/foo/bar

/api/foo/bar

<empty>

/api(/.*)

<empty>

/api/foo/bar

/foo/bar

<empty>

/api/.*

/orders

/api/foo/bar

/orders/api/foo/bar

<empty>

/api(/.*)

/orders

/api/foo/bar

/orders/foo/bar

/api

/foo/.*

<empty>

/api/foo/bar

/foo/bar

/api

/foo(/.*)

<empty>

/api/foo/bar

/bar

/api

/foo/.*

/orders

/api/foo/bar

/orders/foo/bar

/api

/foo(/.*)

/orders

/api/foo/bar

/orders/bar

/api

/api/foo/.*

/orders

/api/foo/bar

<no match> (/api/api/foo/bar などのパスを想定)

/api

/foo(/.)/bar(/.)

<empty>

/api/foo/abc/bar/def

/abc/def

/api

/foo(/.)/bar(/.)

/orders

/api/foo/abc/bar/def

/orders/abc/def
## [](#関連情報)関連情報 - [複数のアップストリームサービスポリシーのトラフィック管理 (加重)](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-traffic-management) - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-api-multiple-services) # 複数のアップストリームサービスポリシーのトラフィック管理 (加重)

ポリシー名

複数のアップストリームサービスポリシーのトラフィック管理 (加重)

概要

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの加重 API インスタンストラフィックを管理します

使用可能な最小 Flex Gateway バージョン

v1.5.0

返される状況コード

このポリシーの戻りコードは存在しません。

次の情報は、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで実行されている Flex Gateway 用に複数のアップストリームサービスを設定するには、​「Multiple Upstream Services for Flex Gateway Running in Connected Mode (接続モードで実行されている Flex Gateway 用の複数のアップストリームサービス)」​を参照してください。
## [](#概要)概要 ローカルモードで実行されている Flex Gateway は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスをサポートしています。 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。加重されていないトラフィックの設定については、[複数のアップストリームサービスのトラフィック管理](https://docs.mulesoft.com/jp/gateway/1.10/policies-included-traffic-management-route)を参照してください。 ローカルモードで複数のアップストリームサービスがある API インスタンスは、​`PolicyBinding`​ YAML 設定リソースを使用して設定されます。各 ​`route-weighted`​ リソースで 1 つのルートが定義されます。ルートをさらに追加するには、複数の ​`route-weighted`​ リソースを追加します。 このポリシーが適用された API インスタンスをパブリッシュする方法に関するチュートリアルは、[ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-api-multiple-services)を参照してください。
複数のアップストリームサービスがある API をデプロイしても、​アウトバウンド Transport Layer Security ポリシー​には影響しません。各アップストリームサービスにアウトバウンド TLS ポリシーを適用できます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 以下のポリシー定義とパラメーターの表を参照してください。 policyRef: name: route-weighted config: routes: - weight: // REQUIRED, max\_value=100, min\_value=1 destinationPath: // OPTIONAL, default: "/" destinationRef: name: // REQUIRED rules: - path: // OPTIONAL, Example: (.\*) methods: // OPTIONAL, Example: GET|POST headers: : // OPTIONAL host: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

routes

必須

空

API アップストリームサービスの配列。
少なくとも 1 つのアップストリームが必要です。

routes.weight

必須

なし

このアップストリームサービスに送信される要求の合計の重み。
そのアップストリームサービスに送信されるトラフィックの割合は、アップストリームサービスの重みをすべてのアップストリームサービスの重みの合計で除算したものです。

routes.destinationPath

必須

なし

アップストリームサービスのパス

routes.destinationRef.name

必須

なし

Service​ 設定リソースで定義されているアップストリームサービスの名前

rules

省略可能

空

このルートのルールセットの配列。
各ルートで複数のルールセットをサポートできます。

rules.path

省略可能

空

ルートがサービスできる要求パス。
ルールセットごとに 1 つの「URI テンプレート正規表現」パスしか定義できません。定義済みのパスがある要求しかこのルートには送信できません。

rules.methods

省略可能

空

ルートがサービスできる要求メソッドの種別を定義する配列。
ルールセットごとに複数のメソッドを選択できます。定義済みのメソッドのいずれかである要求しかこのルートには送信できません。サポートされている値は ​GET​、​POST​、​PUT​、​PATCH​、​DELETE​、​OPTIONS​、​HEAD​、​TRACE​、​CONNECT​ です。

rules.headers

省略可能

空

このルートが要求をサービスするために存在している必要があるヘッダーと正規表現を定義する配列。
指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。

rules.host

省略可能

空

ルートがサービスできる要求ホスト URL。
ルールセットごとに 1 つのホスト URL しか定義できません。定義済みのホストから行われる要求しかこのルートには送信できません。
## [](#ポリシーのしくみ)ポリシーのしくみ トラフィック管理ポリシーでは、定義済みのルート順になっている複数のルートと個別のルールセットを使用してトラフィックを異なるセットのアップストリームサービスに転送することで、トラフィックをさまざまなセットのアップストリームサービスに転送します。 次の図では、さまざまなルートでフライト情報データベースへの要求やカスタマーサービスアプリケーションへの要求を管理しています。ルート 1 では 2 つのアップストリームサービスが定義されており、要求の 70% を安定データベースに、要求の 30% をベータデータベースに転送します。 ![Flex Gateway によって複数のアップストリームサービスへのトラフィックが管理されます](/mulesoft/current/ja-jp/gateway/1.10/_images/multiple-upstreams.png) この設定を実現するには、2 つの ​`route-weighted`​ リソースを公開された API インスタンスにバインドします。1 つの ​`route-weighted`​ リソースはトラフィックをフライト情報データベースに転送し、もう 1 つの ​`route-weighted`​ リソースはトラフィックをカスタマーサービスアプリケーションに転送します。 ### [](#アップストリームサービス)アップストリームサービス 1 つのルートで複数のアップストリームサービスを使用し、要求を似たサービスに転送できます。たとえば、すべてのトラフィックを新しいサービスに送信せずに新しいベータアップストリームサービスのパフォーマンスをテストするには、半分のトラフィックを安定アップストリームサービスに転送し、半分を新しいアップストリームサービスに転送できます。 それぞれの要求が送信されるルート内のアップストリームサービスはランダムであり、前の要求とは無関係です。​`routes.weight`​ 値により、要求が特定のアップストリームサービスに送信される確率が定義されます。そのアップストリームサービスに送信されるトラフィックの割合は、アップストリームの ​`routes.weight`​ をすべてのアップストリームサービスの重みの合計で除算したものです。たとえば、重みが ​`1`​ のアップストリームサービスが 2 つある場合、それぞれのアップストリームサービスはそのルートへのトラフィックの 50% を受信します。重みの値が ​`1`​ と ​`3`​ の場合、1 つのルートはトラフィックの 25% を、もう 1 つは 75% を受信します。 ルート内のアップストリームサービスはどの要求でも受信できるため、同じルート内のすべてのアップストリームサービスは同じ API コントラクトに準拠している必要があります。 ### [](#ルートルール)ルートルール ルートルールを使用して、要求をさまざまなルートに転送できます。要求は、ルートのいずれか 1 つのルールセットのみのルールを満たしている必要があります。 ルールセットでは、次の 4 つのルールの任意の組み合わせを参照します: `path`​、​`method`​、​`headers`​、​`host`​。複数のルールセットを使用してさまざまな組み合わせのルールをサポートできます。 すべてのルールは省略可能です。ルールがルールセットに含まれていない場合、そのルールは無視されます。たとえば、ホストを指定しないと、要求が他のルートルールを満たす場合にルートは任意のホストをサービスできます。ルールを定義しないと、ルートはすべての要求をサービスできます。 要求がどのルートのルールも満たさないと、Flex Gateway によって ​`404`​ エラーコードが返されます。 ### [](#ルート順序)ルート順序 ルートルールの使用に加えて、ポリシー順序を使用して要求をさまざまなルートに転送できます。 ポリシーを並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.10/policies-reorder)を参照してください。 ポリシー順序を設定すると、トラフィックがルートに転送される順序が設定されます。要求がいずれかのルートルールセットを満たす場合、Flex Gateway は要求を最初のルートに転送します。したがって、要求が複数のルートのルートルールを満たす可能性がある場合、ルート順序は非常に重要です。 たとえば、ルート 1 でルールとして ​`GET`​ メソッドが定義されていて、ルート 2 でルートルールが定義されていない場合、すべての ​`GET`​ 要求はルート 1 に送信され、他のすべての要求はルート 2 に送信されます。ルート順序が逆で、ルート 1 にルートルールがなかったとしたら、Flex Gateway は ​`GET`​ 要求がルート 2 に達する前にすべての要求をルート 1 に転送します。 ## [](#関連情報)関連情報 - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.10/flex-local-publish-api-multiple-services) # 複数のアップストリームサービスポリシーのトラフィック管理 (加重)

ポリシー名

複数のアップストリームサービスポリシーのトラフィック管理 (加重)

概要

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの加重 API インスタンストラフィックを管理します

使用可能な最小 Flex Gateway バージョン

v1.5.0

返される状況コード

このポリシーの戻りコードは存在しません。

次の情報は、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで実行されている Flex Gateway 用に複数のアップストリームサービスを設定するには、​「Multiple Upstream Services for Flex Gateway Running in Connected Mode (接続モードで実行されている Flex Gateway 用の複数のアップストリームサービス)」​を参照してください。
## [](#概要)概要 ローカルモードで実行されている Flex Gateway は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスをサポートしています。 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。加重されていないトラフィックの設定については、[複数のアップストリームサービスのトラフィック管理](https://docs.mulesoft.com/jp/gateway/1.8/policies-included-traffic-management-route)を参照してください。 ローカルモードで複数のアップストリームサービスがある API インスタンスは、​`PolicyBinding`​ YAML 設定リソースを使用して設定されます。各 ​`route-weighted`​ リソースで 1 つのルートが定義されます。ルートをさらに追加するには、複数の ​`route-weighted`​ リソースを追加します。 このポリシーが適用された API インスタンスをパブリッシュする方法に関するチュートリアルは、[ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-api-multiple-services)を参照してください。
複数のアップストリームサービスがある API をデプロイしても、​アウトバウンド Transport Layer Security ポリシー​には影響しません。各アップストリームサービスにアウトバウンド TLS ポリシーを適用できます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 以下のポリシー定義とパラメーターの表を参照してください。 policyRef: name: route-weighted config: routes: - weight: // REQUIRED, max\_value=100, min\_value=1 destinationPath: // OPTIONAL, default: "/" destinationRef: name: // REQUIRED rules: - path: // OPTIONAL, Example: (.\*) methods: // OPTIONAL, Example: GET|POST headers: : // OPTIONAL host: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

routes

必須

空

API アップストリームサービスの配列。
少なくとも 1 つのアップストリームが必要です。

routes.weight

必須

なし

このアップストリームサービスに送信される要求の合計の重み。
そのアップストリームサービスに送信されるトラフィックの割合は、アップストリームサービスの重みをすべてのアップストリームサービスの重みの合計で除算したものです。

routes.destinationPath

必須

なし

アップストリームサービスのパス

routes.destinationRef.name

必須

なし

Service​ 設定リソースで定義されているアップストリームサービスの名前

rules

省略可能

空

このルートのルールセットの配列。
各ルートで複数のルールセットをサポートできます。

rules.path

省略可能

空

ルートがサービスできる要求パス。
ルールセットごとに 1 つの「URI テンプレート正規表現」パスしか定義できません。定義済みのパスがある要求しかこのルートには送信できません。

rules.methods

省略可能

空

ルートがサービスできる要求メソッドの種別を定義する配列。
ルールセットごとに複数のメソッドを選択できます。定義済みのメソッドのいずれかである要求しかこのルートには送信できません。サポートされている値は ​GET​、​POST​、​PUT​、​PATCH​、​DELETE​、​OPTIONS​、​HEAD​、​TRACE​、​CONNECT​ です。

rules.headers

省略可能

空

このルートが要求をサービスするために存在している必要があるヘッダーと正規表現を定義する配列。
指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。

rules.host

省略可能

空

ルートがサービスできる要求ホスト URL。
ルールセットごとに 1 つのホスト URL しか定義できません。定義済みのホストから行われる要求しかこのルートには送信できません。
## [](#ポリシーのしくみ)ポリシーのしくみ トラフィック管理ポリシーでは、定義済みのルート順になっている複数のルートと個別のルールセットを使用してトラフィックを異なるセットのアップストリームサービスに転送することで、トラフィックをさまざまなセットのアップストリームサービスに転送します。 次の図では、さまざまなルートでフライト情報データベースへの要求やカスタマーサービスアプリケーションへの要求を管理しています。ルート 1 では 2 つのアップストリームサービスが定義されており、要求の 70% を安定データベースに、要求の 30% をベータデータベースに転送します。 ![Flex Gateway によって複数のアップストリームサービスへのトラフィックが管理されます。](/mulesoft/current/ja-jp/gateway/1.8/_images/multiple-upstreams.png) この設定を実現するには、2 つの ​`route-weighted`​ リソースを公開された API インスタンスにバインドします。1 つの ​`route-weighted`​ リソースはトラフィックをフライト情報データベースに転送し、もう 1 つの ​`route-weighted`​ リソースはトラフィックをカスタマーサービスアプリケーションに転送します。 ### [](#アップストリームサービス)アップストリームサービス 1 つのルートで複数のアップストリームサービスを使用し、要求を似たサービスに転送できます。たとえば、すべてのトラフィックを新しいサービスに送信せずに新しいベータアップストリームサービスのパフォーマンスをテストするには、半分のトラフィックを安定アップストリームサービスに転送し、半分を新しいアップストリームサービスに転送できます。 それぞれの要求が送信されるルート内のアップストリームサービスはランダムであり、前の要求とは無関係です。​`routes.weight`​ 値により、要求が特定のアップストリームサービスに送信される確率が定義されます。そのアップストリームサービスに送信されるトラフィックの割合は、アップストリームの ​`routes.weight`​ をすべてのアップストリームサービスの重みの合計で除算したものです。たとえば、重みが ​`1`​ のアップストリームサービスが 2 つある場合、それぞれのアップストリームサービスはそのルートへのトラフィックの 50% を受信します。重みの値が ​`1`​ と ​`3`​ の場合、1 つのルートはトラフィックの 25% を、もう 1 つは 75% を受信します。 ルート内のアップストリームサービスはどの要求でも受信できるため、同じルート内のすべてのアップストリームサービスは同じ API コントラクトに準拠している必要があります。 ### [](#ルートルール)ルートルール ルートルールを使用して、要求をさまざまなルートに転送できます。要求は、ルートのいずれか 1 つのルールセットのみのルールを満たしている必要があります。 ルールセットでは、次の 4 つのルールの任意の組み合わせを参照します: `path`​、​`method`​、​`headers`​、​`host`​。複数のルールセットを使用してさまざまな組み合わせのルールをサポートできます。 すべてのルールは省略可能です。ルールがルールセットに含まれていない場合、そのルールは無視されます。たとえば、ホストを指定しないと、要求が他のルートルールを満たす場合にルートは任意のホストをサービスできます。ルールを定義しないと、ルートはすべての要求をサービスできます。 要求がどのルートのルールも満たさないと、Flex Gateway によって ​`404`​ エラーコードが返されます。 ### [](#ルート順序)ルート順序 ルートルールの使用に加えて、ポリシー順序を使用して要求をさまざまなルートに転送できます。 ポリシーを並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.8/policies-reorder)を参照してください。 ポリシー順序を設定すると、トラフィックがルートに転送される順序が設定されます。要求がいずれかのルートルールセットを満たす場合、Flex Gateway は要求を最初のルートに転送します。したがって、要求が複数のルートのルートルールを満たす可能性がある場合、ルート順序は非常に重要です。 たとえば、ルート 1 でルールとして ​`GET`​ メソッドが定義されていて、ルート 2 でルートルールが定義されていない場合、すべての ​`GET`​ 要求はルート 1 に送信され、他のすべての要求はルート 2 に送信されます。ルート順序が逆で、ルート 1 にルートルールがなかったとしたら、Flex Gateway は ​`GET`​ 要求がルート 2 に達する前にすべての要求をルート 1 に転送します。 ## [](#関連情報)関連情報 - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.8/flex-local-publish-api-multiple-services) # 複数のアップストリームサービスポリシーのトラフィック管理 (加重)

ポリシー名

複数のアップストリームサービスポリシーのトラフィック管理 (加重)

概要

1 つのコンシューマーエンドポイントから複数のアップストリームサービスへの加重 API インスタンストラフィックを管理します

使用可能な最小 Flex Gateway バージョン

v1.5.0

返される状況コード

このポリシーの戻りコードは存在しません。

次の情報は、ローカルモードで実行されている Flex Gateway にのみ適用されます。接続モードで実行されている Flex Gateway 用に複数のアップストリームサービスを設定するには、​「Multiple Upstream Services for Flex Gateway Running in Connected Mode (接続モードで実行されている Flex Gateway 用の複数のアップストリームサービス)」​を参照してください。
## [](#概要)概要 ローカルモードで実行されている Flex Gateway は、1 つのコンシューマーエンドポイントを通じて複数のアップストリームサービスを公開する API インスタンスをサポートしています。 Flex Gateway は、トラフィックを複数のアップストリームサービスに転送できるさまざまなルートを使用して要求トラフィックを管理します。Flex Gateway はルート順と各ルートのルールを使用してトラフィックをルートに転送します。さらに、ルート内の各アップストリームサービスに加重率を追加してアップストリームサービスに送信される要求の割合を管理できます。加重されていないトラフィックの設定については、[複数のアップストリームサービスのトラフィック管理](https://docs.mulesoft.com/jp/gateway/1.9/policies-included-traffic-management-route)を参照してください。 ローカルモードで複数のアップストリームサービスがある API インスタンスは、​`PolicyBinding`​ YAML 設定リソースを使用して設定されます。各 ​`route-weighted`​ リソースで 1 つのルートが定義されます。ルートをさらに追加するには、複数の ​`route-weighted`​ リソースを追加します。 このポリシーが適用された API インスタンスをパブリッシュする方法に関するチュートリアルは、[ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-api-multiple-services)を参照してください。
複数のアップストリームサービスがある API をデプロイしても、​アウトバウンド Transport Layer Security ポリシー​には影響しません。各アップストリームサービスにアウトバウンド TLS ポリシーを適用できます。
## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定 以下のポリシー定義とパラメーターの表を参照してください。 policyRef: name: route-weighted config: routes: - weight: // REQUIRED, max\_value=100, min\_value=1 destinationPath: // OPTIONAL, default: "/" destinationRef: name: // REQUIRED rules: - path: // OPTIONAL, Example: (.\*) methods: // OPTIONAL, Example: GET|POST headers: : // OPTIONAL host: // OPTIONAL
パラメーター 必須または省略可能 デフォルト値 説明

routes

必須

空

API アップストリームサービスの配列。
少なくとも 1 つのアップストリームが必要です。

routes.weight

必須

なし

このアップストリームサービスに送信される要求の合計の重み。
そのアップストリームサービスに送信されるトラフィックの割合は、アップストリームサービスの重みをすべてのアップストリームサービスの重みの合計で除算したものです。

routes.destinationPath

必須

なし

アップストリームサービスのパス

routes.destinationRef.name

必須

なし

Service​ 設定リソースで定義されているアップストリームサービスの名前

rules

省略可能

空

このルートのルールセットの配列。
各ルートで複数のルールセットをサポートできます。

rules.path

省略可能

空

ルートがサービスできる要求パス。
ルールセットごとに 1 つの「URI テンプレート正規表現」パスしか定義できません。定義済みのパスがある要求しかこのルートには送信できません。

rules.methods

省略可能

空

ルートがサービスできる要求メソッドの種別を定義する配列。
ルールセットごとに複数のメソッドを選択できます。定義済みのメソッドのいずれかである要求しかこのルートには送信できません。サポートされている値は ​GET​、​POST​、​PUT​、​PATCH​、​DELETE​、​OPTIONS​、​HEAD​、​TRACE​、​CONNECT​ です。

rules.headers

省略可能

空

このルートが要求をサービスするために存在している必要があるヘッダーと正規表現を定義する配列。
指定されたすべてのヘッダー要件を満たす要求しかこのルートには送信できません。ルールで特に定義されていない要求に存在する追加のヘッダーは無視されます。

rules.host

省略可能

空

ルートがサービスできる要求ホスト URL。
ルールセットごとに 1 つのホスト URL しか定義できません。定義済みのホストから行われる要求しかこのルートには送信できません。
## [](#ポリシーのしくみ)ポリシーのしくみ トラフィック管理ポリシーでは、定義済みのルート順になっている複数のルートと個別のルールセットを使用してトラフィックを異なるセットのアップストリームサービスに転送することで、トラフィックをさまざまなセットのアップストリームサービスに転送します。 次の図では、さまざまなルートでフライト情報データベースへの要求やカスタマーサービスアプリケーションへの要求を管理しています。ルート 1 では 2 つのアップストリームサービスが定義されており、要求の 70% を安定データベースに、要求の 30% をベータデータベースに転送します。 ![Flex Gateway によって複数のアップストリームサービスへのトラフィックが管理されます](/mulesoft/current/ja-jp/gateway/1.9/_images/multiple-upstreams.png) この設定を実現するには、2 つの ​`route-weighted`​ リソースを公開された API インスタンスにバインドします。1 つの ​`route-weighted`​ リソースはトラフィックをフライト情報データベースに転送し、もう 1 つの ​`route-weighted`​ リソースはトラフィックをカスタマーサービスアプリケーションに転送します。 ### [](#アップストリームサービス)アップストリームサービス 1 つのルートで複数のアップストリームサービスを使用し、要求を似たサービスに転送できます。たとえば、すべてのトラフィックを新しいサービスに送信せずに新しいベータアップストリームサービスのパフォーマンスをテストするには、半分のトラフィックを安定アップストリームサービスに転送し、半分を新しいアップストリームサービスに転送できます。 それぞれの要求が送信されるルート内のアップストリームサービスはランダムであり、前の要求とは無関係です。​`routes.weight`​ 値により、要求が特定のアップストリームサービスに送信される確率が定義されます。そのアップストリームサービスに送信されるトラフィックの割合は、アップストリームの ​`routes.weight`​ をすべてのアップストリームサービスの重みの合計で除算したものです。たとえば、重みが ​`1`​ のアップストリームサービスが 2 つある場合、それぞれのアップストリームサービスはそのルートへのトラフィックの 50% を受信します。重みの値が ​`1`​ と ​`3`​ の場合、1 つのルートはトラフィックの 25% を、もう 1 つは 75% を受信します。 ルート内のアップストリームサービスはどの要求でも受信できるため、同じルート内のすべてのアップストリームサービスは同じ API コントラクトに準拠している必要があります。 ### [](#ルートルール)ルートルール ルートルールを使用して、要求をさまざまなルートに転送できます。要求は、ルートのいずれか 1 つのルールセットのみのルールを満たしている必要があります。 ルールセットでは、次の 4 つのルールの任意の組み合わせを参照します: `path`​、​`method`​、​`headers`​、​`host`​。複数のルールセットを使用してさまざまな組み合わせのルールをサポートできます。 すべてのルールは省略可能です。ルールがルールセットに含まれていない場合、そのルールは無視されます。たとえば、ホストを指定しないと、要求が他のルートルールを満たす場合にルートは任意のホストをサービスできます。ルールを定義しないと、ルートはすべての要求をサービスできます。 要求がどのルートのルールも満たさないと、Flex Gateway によって ​`404`​ エラーコードが返されます。 ### [](#ルート順序)ルート順序 ルートルールの使用に加えて、ポリシー順序を使用して要求をさまざまなルートに転送できます。 ポリシーを並び替えるには、[ポリシーの順序付け](https://docs.mulesoft.com/jp/gateway/1.9/policies-reorder)を参照してください。 ポリシー順序を設定すると、トラフィックがルートに転送される順序が設定されます。要求がいずれかのルートルールセットを満たす場合、Flex Gateway は要求を最初のルートに転送します。したがって、要求が複数のルートのルートルールを満たす可能性がある場合、ルート順序は非常に重要です。 たとえば、ルート 1 でルールとして ​`GET`​ メソッドが定義されていて、ルート 2 でルートルールが定義されていない場合、すべての ​`GET`​ 要求はルート 1 に送信され、他のすべての要求はルート 2 に送信されます。ルート順序が逆で、ルート 1 にルートルールがなかったとしたら、Flex Gateway は ​`GET`​ 要求がルート 2 に達する前にすべての要求をルート 1 に転送します。 ## [](#関連情報)関連情報 - [ローカルモードでの複数のアップストリームサービスを使用した API のパブリッシュ](https://docs.mulesoft.com/jp/gateway/1.9/flex-local-publish-api-multiple-services) # 要求接続のトラブルシューティング Flex Gateway を設定して実行するときに、接続の問題が発生する可能性があります。 これらの問題のトラブルシューティングを行うには、​`flexctl check http`​ コマンドを使用します。このコマンドは、アップストリームサービスと Flex Gateway 間のアウトバウンド接続と、Flex Gateway とクライアント間のインバウンド接続の両方に対する直接要求を行います。直接要求を実行すると、Flex Gateway 接続が分離され、問題の原因を特定できます。 次の図は、インバウンド要求とアウトバウンド要求の違いを示しています。 ![インバウンド接続はクライアントと Flex Gateway 間で行われ、アウトバウンド接続は Flex Gateway とアップストリームサービス間で行われます](/mulesoft/current/ja-jp/gateway/1.10/_images/flex-inbound-outbound-requests.png) ## [](#flex-gateway-とアップストリームサービス間のアウトバウンド要求)Flex Gateway とアップストリームサービス間のアウトバウンド要求 アップストリームサービスと Flex Gateway 間の接続を分離すると、この 2 つの間の接続をテストできます。 アップストリームサービスへの直接アウトバウンド要求を実行する手順は、次のとおりです。 1. Flex Gateway コンテナまたは VM にログインします。 - Linux: ```ssh ssh [-i sshkey.pem] @ ``` - Docker: ```ssh docker exec -it bash ``` - Kubernetes: ```ssh kubectl -n exec -it -- bash ``` 2. アップストリームサービスへの要求を実行します。 ```ssh flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' ``` ## [](#クライアントと-flex-gateway-間のインバウンド要求)クライアントと Flex Gateway 間のインバウンド要求 Flex Gateway とクライアント間の接続を分離すると、接続の問題の原因がロードバランサーであるか、または Flex Gateway とクライアント間に追加された別のシステムによるものであるかをテストできます。 クライアントへの直接インバウンド要求を実行する手順は、次のとおりです。 1. Flex Gateway コンテナまたは VM にログインします。 - Linux: ```ssh ssh [-i sshkey.pem] @ ``` - Docker: ```ssh docker exec -it bash ``` - Kubernetes: ```ssh kubectl -n exec -it -- bash ``` 2. Flex Gateway への要求を実行します。 ```ssh flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' http://localhost:/ ``` # 要求接続のトラブルシューティング Flex Gateway を設定して実行するときに、接続の問題が発生する可能性があります。 これらの問題のトラブルシューティングを行うには、​`flexctl check http`​ コマンドを使用します。このコマンドは、アップストリームサービスと Flex Gateway 間のアウトバウンド接続と、Flex Gateway とクライアント間のインバウンド接続の両方に対する直接要求を行います。直接要求を実行すると、Flex Gateway 接続が分離され、問題の原因を特定できます。 次の図は、インバウンド要求とアウトバウンド要求の違いを示しています。 ![インバウンド接続はクライアントと Flex Gateway 間で行われ、アウトバウンド接続は Flex Gateway とアップストリームサービス間で行われます](/mulesoft/current/ja-jp/gateway/1.8/_images/flex-inbound-outbound-requests.png) ## [](#flex-gateway-とアップストリームサービス間のアウトバウンド要求)Flex Gateway とアップストリームサービス間のアウトバウンド要求 アップストリームサービスと Flex Gateway 間の接続を分離すると、この 2 つの間の接続をテストできます。 アップストリームサービスへの直接アウトバウンド要求を実行する手順は、次のとおりです。 1. Flex Gateway コンテナまたは VM にログインします。 - Linux: ```ssh ssh [-i sshkey.pem] @ ``` - Docker: ```ssh docker exec -it bash ``` - Kubernetes: ```ssh kubectl -n exec -it -- bash ``` 2. アップストリームサービスへの要求を実行します。 ```ssh flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' ``` ## [](#クライアントと-flex-gateway-間のインバウンド要求)クライアントと Flex Gateway 間のインバウンド要求 Flex Gateway とクライアント間の接続を分離すると、接続の問題の原因がロードバランサーであるか、または Flex Gateway とクライアント間に追加された別のシステムによるものであるかをテストできます。 クライアントへの直接インバウンド要求を実行する手順は、次のとおりです。 1. Flex Gateway コンテナまたは VM にログインします。 - Linux: ```ssh ssh [-i sshkey.pem] @ ``` - Docker: ```ssh docker exec -it bash ``` - Kubernetes: ```ssh kubectl -n exec -it -- bash ``` 2. Flex Gateway への要求を実行します。 ```ssh flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' http://localhost:/ ``` # 要求接続のトラブルシューティング Flex Gateway を設定して実行するときに、接続の問題が発生する可能性があります。 これらの問題のトラブルシューティングを行うには、​`flexctl check http`​ コマンドを使用します。このコマンドは、アップストリームサービスと Flex Gateway 間のアウトバウンド接続と、Flex Gateway とクライアント間のインバウンド接続の両方に対する直接要求を行います。直接要求を実行すると、Flex Gateway 接続が分離され、問題の原因を特定できます。 次の図は、インバウンド要求とアウトバウンド要求の違いを示しています。 ![インバウンド接続はクライアントと Flex Gateway 間で行われ、アウトバウンド接続は Flex Gateway とアップストリームサービス間で行われます](/mulesoft/current/ja-jp/gateway/1.9/_images/flex-inbound-outbound-requests.png) ## [](#flex-gateway-とアップストリームサービス間のアウトバウンド要求)Flex Gateway とアップストリームサービス間のアウトバウンド要求 アップストリームサービスと Flex Gateway 間の接続を分離すると、この 2 つの間の接続をテストできます。 アップストリームサービスへの直接アウトバウンド要求を実行する手順は、次のとおりです。 1. Flex Gateway コンテナまたは VM にログインします。 - Linux: ```ssh ssh [-i sshkey.pem] @ ``` - Docker: ```ssh docker exec -it bash ``` - Kubernetes: ```ssh kubectl -n exec -it -- bash ``` 2. アップストリームサービスへの要求を実行します。 ```ssh flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' ``` ## [](#クライアントと-flex-gateway-間のインバウンド要求)クライアントと Flex Gateway 間のインバウンド要求 Flex Gateway とクライアント間の接続を分離すると、接続の問題の原因がロードバランサーであるか、または Flex Gateway とクライアント間に追加された別のシステムによるものであるかをテストできます。 クライアントへの直接インバウンド要求を実行する手順は、次のとおりです。 1. Flex Gateway コンテナまたは VM にログインします。 - Linux: ```ssh ssh [-i sshkey.pem] @ ``` - Docker: ```ssh docker exec -it bash ``` - Kubernetes: ```ssh kubectl -n exec -it -- bash ``` 2. Flex Gateway への要求を実行します。 ```ssh flexctl check http -X=POST -d='{\"key\": \"value\"}' -H='Authorization:token' http://localhost:/ ```