# mulesoft Runtime Fabric - Full Documentation # Anypoint CLI を使用した Runtime Fabric への Mule アプリケーションのデプロイ これらの Anypoint Platform CLI コマンドを使用して、Runtime Fabric でアプリケーションをデプロイおよび管理します。CLI は、対話型シェルと標準 CLI モードの両方をサポートしています。 Runtime Fabric は現在、Anypoint CLI バージョン 3.x のみをサポートしています。 始める前に、​[Anypoint CLI の前提条件と、インストールと認証の手順](https://docs.mulesoft.com/jp/anypoint-cli/3.x/)​を確認しておいてください。

Mule 4.5 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。新しいリリースチャネルの Mule Runtime バージョン設定スキーマは次のとおりです。

メジャー[数値] .マイナー[数値] . パッチ[数値] : ビルド[数値] チャネル[Edge の場合は e、LTS の場合はなし]

これらの値の例としては、Edge の場合は ​4.5.0:1e​、LTS の場合は ​4.6.0:1​ となります。

詳細は、Edge and LTS Releases for Muleを参照してください。
コマンド 説明

runtime-mgr application delete

アプリケーションを削除する

runtime-mgr application deploy

Exchange アプリケーションを使用して指定された対象にアプリケーションをデプロイし、指定されたランタイムバージョンを実行する

runtime-mgr application describe

アプリケーションの情報を表示する

runtime-mgr application describe-json

未加工の JSON 応答でアプリケーションの情報を表示する

runtime-mgr application download-logs

仕様のアプリケーションのログを指定されたディレクトリにダウンロードする

runtime-mgr application list

組織内のすべてのアプリケーションをリストする

runtime-mgr application modify

デプロイ済みのアプリケーションを修正する

runtime-mgr application start

停止中のアプリケーションを開始する

runtime-mgr application stop

アプリケーションの実行を停止する

runtime-mgr application tail-logs

仕様のアプリケーションのログを追跡する
## [](#runtime-mgr-application-delete)runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-deploy)runtime-mgr application deploy \> runtime-mgr application deploy \[options\] ``​ で指定されたアプリケーションを、次のオプションを使用して指定されたデプロイメント対象にデプロイします。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションのアーティファクト ID。

mule-test-plugin

deploymentTargetID

デプロイメント対象の ID。
この ID は、Runtime Manager から直接取得できます。

app.runetime

name

デプロイするアプリケーションの名前。

testCloudhub2app

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1​
このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト:.disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID

org.mule.test

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example:/status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate
## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs)runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 \[\[runtime-mgr-application-delete\]\] == runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start-2)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop-2)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs-2)runtime-mgr application tail-logs \> runtime-mgr application tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-rtf-list)runtime-mgr rtf list \> runtime-mgr rtf list \[options\] このコマンドは、使用可能な Runtime Fabric インスタンスをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 コマンドラインを使用した Runtime Fabric インスタンスの管理については、​[「サポートされている rtfctl コマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands)​を参照してください。 # Anypoint CLI を使用した Runtime Fabric への Mule アプリケーションのデプロイ これらの Anypoint Platform CLI コマンドを使用して、Runtime Fabric でアプリケーションをデプロイおよび管理します。CLI は、対話型シェルと標準 CLI モードの両方をサポートしています。 Runtime Fabric は現在、Anypoint CLI バージョン 3.x のみをサポートしています。 始める前に、​[Anypoint CLI の前提条件と、インストールと認証の手順](https://docs.mulesoft.com/jp/anypoint-cli/3.x/)​を確認しておいてください。

Mule 4.5 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。新しいリリースチャネルの Mule Runtime バージョン設定スキーマは次のとおりです。

メジャー[数値] .マイナー[数値] . パッチ[数値] : ビルド[数値] チャネル[Edge の場合は e、LTS の場合はなし]

これらの値の例としては、Edge の場合は ​4.5.0:1e​、LTS の場合は ​4.6.0:1​ となります。

詳細は、Edge and LTS Releases for Muleを参照してください。
コマンド 説明

runtime-mgr application delete

アプリケーションを削除する

runtime-mgr application deploy

Exchange アプリケーションを使用して指定された対象にアプリケーションをデプロイし、指定されたランタイムバージョンを実行する

runtime-mgr application describe

アプリケーションの情報を表示する

runtime-mgr application describe-json

未加工の JSON 応答でアプリケーションの情報を表示する

runtime-mgr application download-logs

仕様のアプリケーションのログを指定されたディレクトリにダウンロードする

runtime-mgr application list

組織内のすべてのアプリケーションをリストする

runtime-mgr application modify

デプロイ済みのアプリケーションを修正する

runtime-mgr application start

停止中のアプリケーションを開始する

runtime-mgr application stop

アプリケーションの実行を停止する

runtime-mgr application tail-logs

仕様のアプリケーションのログを追跡する
## [](#runtime-mgr-application-delete)runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-deploy)runtime-mgr application deploy \> runtime-mgr application deploy \[options\] ``​ で指定されたアプリケーションを、次のオプションを使用して指定されたデプロイメント対象にデプロイします。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションのアーティファクト ID。

mule-test-plugin

deploymentTargetID

デプロイメント対象の ID。
この ID は、Runtime Manager から直接取得できます。

app.runetime

name

デプロイするアプリケーションの名前。

testCloudhub2app

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1​
このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト:.disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID

org.mule.test

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example:/status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate
## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs)runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 \[\[runtime-mgr-application-delete\]\] == runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start-2)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop-2)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs-2)runtime-mgr application tail-logs \> runtime-mgr application tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-rtf-list)runtime-mgr rtf list \> runtime-mgr rtf list \[options\] このコマンドは、使用可能な Runtime Fabric インスタンスをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 コマンドラインを使用した Runtime Fabric インスタンスの管理については、​[「サポートされている rtfctl コマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands)​を参照してください。 # Anypoint CLI を使用した Runtime Fabric への Mule アプリケーションのデプロイ これらの Anypoint Platform CLI コマンドを使用して、Runtime Fabric でアプリケーションをデプロイおよび管理します。CLI は、対話型シェルと標準 CLI モードの両方をサポートしています。 Runtime Fabric は現在、Anypoint CLI バージョン 3.x のみをサポートしています。 始める前に、​[Anypoint CLI の前提条件と、インストールと認証の手順](https://docs.mulesoft.com/jp/anypoint-cli/3.x/)​を確認しておいてください。

Mule 4.5 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。新しいリリースチャネルの Mule Runtime バージョン設定スキーマは次のとおりです。

メジャー[数値] .マイナー[数値] . パッチ[数値] : ビルド[数値] チャネル[Edge の場合は e、LTS の場合はなし]

これらの値の例としては、Edge の場合は ​4.5.0:1e​、LTS の場合は ​4.6.0:1​ となります。

詳細は、Edge and LTS Releases for Muleを参照してください。
コマンド 説明

runtime-mgr application delete

アプリケーションを削除する

runtime-mgr application deploy

Exchange アプリケーションを使用して指定された対象にアプリケーションをデプロイし、指定されたランタイムバージョンを実行する

runtime-mgr application describe

アプリケーションの情報を表示する

runtime-mgr application describe-json

未加工の JSON 応答でアプリケーションの情報を表示する

runtime-mgr application download-logs

仕様のアプリケーションのログを指定されたディレクトリにダウンロードする

runtime-mgr application list

組織内のすべてのアプリケーションをリストする

runtime-mgr application modify

デプロイ済みのアプリケーションを修正する

runtime-mgr application start

停止中のアプリケーションを開始する

runtime-mgr application stop

アプリケーションの実行を停止する

runtime-mgr application tail-logs

仕様のアプリケーションのログを追跡する
## [](#runtime-mgr-application-delete)runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-deploy)runtime-mgr application deploy \> runtime-mgr application deploy \[options\] ``​ で指定されたアプリケーションを、次のオプションを使用して指定されたデプロイメント対象にデプロイします。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションのアーティファクト ID。

mule-test-plugin

deploymentTargetID

デプロイメント対象の ID。
この ID は、Runtime Manager から直接取得できます。

app.runetime

name

デプロイするアプリケーションの名前。

testCloudhub2app

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1​
このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト:.disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID

org.mule.test

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example:/status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate
## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs)runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 \[\[runtime-mgr-application-delete\]\] == runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start-2)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop-2)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs-2)runtime-mgr application tail-logs \> runtime-mgr application tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-rtf-list)runtime-mgr rtf list \> runtime-mgr rtf list \[options\] このコマンドは、使用可能な Runtime Fabric インスタンスをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 コマンドラインを使用した Runtime Fabric インスタンスの管理については、​[「サポートされている rtfctl コマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands)​を参照してください。 # Anypoint Monitoring の使用 Runtime Fabric にデプロイされた Mule アプリケーションと API ゲートウェイには、Anypoint Platform 内のメトリクスを表示できる Anypoint Monitoring のネイティブサポートが含まれます。 ## [](#anypoint-monitoring)Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ には、Mule アプリケーションネットワークの Mule フローとコンポーネントからのフィードバックを提供するツールがあります。Anypoint Monitoring は、アプリケーションデプロイメント内でサイドカーとして実行され、Runtime Fabric にデプロイされた Mule アプリケーションや API ゲートウェイのメトリクスを収集します。Titanium プランのユーザーは、アプリケーションログの取得や検索などの追加機能にアクセスできます。 ## [](#anypoint-monitoring-の有効化)Anypoint Monitoring の有効化 デフォルトでは、Runtime Fabric は、アプリケーションメトリクスを Anypoint Monitoring に送信するように設定されています。データは相互 TLS 暗号化を使用してセキュアに送信されます。メトリクスとログを Anypoint Monitoring に送信するには、アウトバウンドネットワーク接続を使用できる必要があります。 アウトバウンドプロキシが必要な場合、​[「Runtime Fabric でのプロキシの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-proxy-self)​の手順に従って、SOCKS5 プロキシを使用するように Anypoint Runtime Fabric を設定します。 Anypoint Runtime Fabric バージョン 1.8.50 以降でアウトバウンドネットワーク接続を検証するには、Runtime Fabric の各ノードがポート 443 を使用して次のドメインにアウトバウンド TCP (Lumberjack) 通信を送信できることを確認します。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com`

1.8.50 より前のバージョンの Anypoint Runtime Fabric を使用している場合、ポート 443 の代わりにポート 5044 を使用します。次のドメインを使用します。

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io
Anypoint Monitoring エンドポイントについての詳細は、​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed-network-configuration)​を参照してください。 ## [](#メトリクス)メトリクス 各 Mule アプリケーションと API ゲートウェイのレプリカは、メトリクスデータを収集してセキュアな相互 TLS 暗号化を通じて Anypoint Monitoring に送信するメトリクスエージェントを実行します。各レプリカは最大 100 メガバイトのメトリクスをキャッシュできます。その後メトリクスデータを循環し、最新のデータのストレージを提供します。メトリクスを Anypoint Monitoring に送信できない場合、通常はレプリカごとに少なくとも 4 日分のストレージが提供されます。カスタムメトリクスにはより多くのストレージがコンシュームされる場合があります。 次の Anypoint Runtime Fabric 更新によって、Runtime Fabric にデプロイされたアプリケーションの監視メトリクスが影響を受けたり復元されたりすることはありません。 - Runtime Fabric のバックアップと復元 - Runtime Fabric のアップグレード - Runtime Fabric ノードの OS パッチ適用 ## [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 各 Mule アプリケーションと API ゲートウェイのレプリカは、最大 450 メガバイトのログデータをディスクに保存できます。その後ログデータを循環し、最新のログデータのストレージを提供します。 Mule アプリケーションと API ゲートウェイの各レプリカによって生成されたログが収集され、それらが実行されているワーカーノードのディスクに書き込まれます。各ワーカーノードは 1 つのログ転送エージェントを実行します。そのエージェントがこの場所を監視し、ログデータを Anypoint Monitoring に送信します。 ログ転送エージェントは、1 秒あたり最大 300 キロバイトのログデータを送信できます。ワーカーノードごとにデプロイするレプリカは 50 個以内にしてください。 場合によって、複数の行を含むログが Anypoint Monitoring に完全に送信されないことがあります。これは、複数行のログ出力が Runtime Fabric 内の循環によって 2 つのファイルに分割された場合に発生する可能性があります。 [Runtime Manager でアプリケーションをデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric#configure-logging-and-log-levels)​するときにログ転送を有効にしてログレベルを設定できます。 ### [](#anypoint-monitoring-エージェントのリソースと権限の要件)Anypoint Monitoring エージェントのリソースと権限の要件 MuleSoft は Mule アプリケーションと一緒に、テレメトリーを Anypoint コントロールプレーンに送信するための Anypoint Monitoring エージェントを実行します。 Runtime Fabric エージェントバージョン 2.5.x 以降を使用してデプロイまたは管理される Mule アプリケーションには、次のように 2 つの異なるエージェントが使用されます。 - ログを Anypoint Monitoring コントロールプレーンに転送するために、基盤ノードごとに 1 つの DaemonSet。 - メトリクスを Anypoint Monitoring コントロールプレーンに転送するために、アプリケーションレプリカごとに 1 つのサイドカー。 daemonset を最適に機能させるには、次の前提条件に従います。 1. アプリケーションコンテナが次の場所にログを書き込むことを確認します。 - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. DaemonSet がホストパス ​`/var/lib/filebeat-data`​ で作成と書き込みを行うことを確認します。 3. Docker デーモン設定に ​`json-file`​ ログドライバーが含まれていることを確認します。 4. Anypoint Monitoring ログフォワーダー DaemonSet コンテナに、ホストパス ​`/var/lib/filebeat-data`​ のホストへの書き込みアクセス権があることを確認します。 Runtime Fabric バージョン 2.6.x 以上を使用してデプロイまたは管理されるアプリケーションの場合、テレメトリーの転送はアプリケーションレプリカごとに 1 つのサイドカーにまとめられます。 使用する機能に応じて、サイドカーエージェントは最適なパフォーマンスに対応するリソースをコンシュームします。 - デフォルトの Anypoint メトリクスを有効にするには、サイドカーエージェント (アプリケーションレプリカごと) に 0.05vCPU、または CPU 割り当てのコアと 90MiB のメモリ割り当てが必要です。 - [アプリケーションログを Anypoint Monitoring に転送](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric#configure-logging-and-log-levels)​する場合は、サイドカーエージェント (アプリケーションレプリカごと) にアプリケーションレプリカに設定された CPU 制限の最大 30% と最大 150MiB のメモリ割り当てが必要です。 - Mule アプリケーションのデータ生成を追跡する場合は、サイドカーエージェント (アプリケーションレプリカごと) にアプリケーションレプリカに設定された CPU 制限の最大 30% と最大 240MB のメモリ割り当てが必要です。
アプリケーションデプロイメントの失敗を避けるため、基盤となるクラスターに適切な容量を割り当ててください。
### [](#省略可能-runtime-fabric-バージョン-2-6-x-以降のログフォワーダー-deamonset-の無効化)(省略可能) Runtime Fabric バージョン 2.6.x 以降のログフォワーダー DeamonSet の無効化 Runtime Fabric エージェントをバージョン 2.6.0 以降にアップグレードすると、すべてのデプロイメントでメトリクスおよびログ転送に 1 つのサイドカーのみが使用されます。 以前のエージェントで実行されている Mule アプリケーションがある場合、再デプロイして、新しいログ転送メカニズムの使用を開始します。コントロールプレーンで更新を実行すると、再デプロイメントがトリガーされます。 すべてのデプロイメントで新しいサイドカーコンテナが使用されるようになると、​`am-log-forwarder`​ DaemonSet がアイドル状態になります。 DeamonSet を完全に削除するには、対応する [Anypoint Platform API コール](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/)​を使用して次のようなペイロードを送信し、Anypoint Monitoring ログ転送を無効にします。 \[source,json { "anypointMonitoring": false } この無効化は、サイドカーを介した Anypoint Monitoring へのログ転送には影響しません。 ## [](#anypoint-visualizer)Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/)​ には、アプリケーションネットワークグラフのさまざまな側面のビューが表示されます。 グラフを使用してアプリケーションネットワークを調査し、問題を特定して、決定を下すことができます。

デフォルトでは、アプリケーションを Mule Runtime 4.x にデプロイすると、Anypoint Visualizer は無効になります。 詳細は、​「ヘッダー挿入の有効化」​を参照してください。 パフォーマンスへの影響のため、0.2 個未満の vCPU を使用するアプリケーションデプロイメントで Anypoint Visualizer を有効にすることはサポートされません。
## [](#省略可能-mule-アプリケーションの-anypoint-monitoring-の無効化)(省略可能) Mule アプリケーションの Anypoint Monitoring の無効化 Runtime Fabric に Mule アプリケーションをデプロイすると、デフォルトで Anypoint Monitoring が有効になります。Anypoint Monitoring を無効にするには、Mule アプリケーションをデプロイするときに次のカスタムプロパティを渡します。 ```copy anypoint.platform.config.analytics.agent.enabled=false ```
コンプライアンスや地域固有の要件によってチームや組織がメトリクスを Anypoint コントロールプレーンに送信できない場合、それらのメトリクスを Anypoint の使用や請求のために送信することが契約で義務付けられていなければ、Anypoint メトリクスを無効にできます。
## [](#enable-trace-data)トレースデータ収集の有効化
この機能は、組織に Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションがある場合にのみ利用できます。詳細は、​価格設定およびパッケージ​のドキュメントを参照してください。
トレースを行うと、API コールやアプリケーショントランザクションの実行パスを完全に把握できるため、MuleSoft エコシステム内でのトランザクションのパスを理解できます。 アプリケーションのトレースデータ収集を有効にすると、Anypoint Platform によって Mule Runtime Engine からのトレース情報が OpenTelemetry 標準で収集、公開されるため、Anypoint Monitoring ​[Telemetry Exporter](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​ を使用してその情報をエクスポートできます。 - トレースデータ収集は、Mule バージョン 4.6 以降を実行する Runtime Fabric アプリケーションで有効にすることができます。必要な最小 Runtime Fabric エージェントバージョンは 2.6.31 以上です。 - トレースデータ収集は Runtime Manager UI と API のみを使用して有効にすることができ、Mule Maven プラグイン、Anypoint CLI、または Anypoint Studio を使用してトレースデータ収集を有効にすることはできません。 アプリケーションのトレースデータ収集を有効にする手順は次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. **\[Enable tracing (トレースを有効化する)\]**​ チェックボックスをオンにします。 3. 新しいデプロイメントでこの機能を有効にする場合には、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。既存のアプリケーションを編集している場合は ​**\[Apply Changes (変更を適用)\]**​ をクリックします。 トレースを有効にしてアプリケーションを再デプロイすると、Runtime Manager バックエンドによってアプリケーションのトレース計測が開始されます。 # Anypoint Monitoring の使用 Runtime Fabric にデプロイされた Mule アプリケーションと API ゲートウェイには、Anypoint Platform 内のメトリクスを表示できる Anypoint Monitoring のネイティブサポートが含まれます。 ## [](#anypoint-monitoring)Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ には、Mule アプリケーションネットワークの Mule フローとコンポーネントからのフィードバックを提供するツールがあります。Anypoint Monitoring は、アプリケーションデプロイメント内でサイドカーとして実行され、Runtime Fabric にデプロイされた Mule アプリケーションや API ゲートウェイのメトリクスを収集します。Titanium プランのユーザーは、アプリケーションログの取得や検索などの追加機能にアクセスできます。 ## [](#anypoint-monitoring-の有効化)Anypoint Monitoring の有効化 デフォルトでは、Runtime Fabric は、アプリケーションメトリクスを Anypoint Monitoring に送信するように設定されています。データは相互 TLS 暗号化を使用してセキュアに送信されます。メトリクスとログを Anypoint Monitoring に送信するには、アウトバウンドネットワーク接続を使用できる必要があります。 アウトバウンドプロキシが必要な場合、​[「Runtime Fabric でのプロキシの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-proxy-self)​の手順に従って、SOCKS5 プロキシを使用するように Anypoint Runtime Fabric を設定します。 Anypoint Runtime Fabric バージョン 1.8.50 以降でアウトバウンドネットワーク接続を検証するには、Runtime Fabric の各ノードがポート 443 を使用して次のドメインにアウトバウンド TCP (Lumberjack) 通信を送信できることを確認します。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com`

1.8.50 より前のバージョンの Anypoint Runtime Fabric を使用している場合、ポート 443 の代わりにポート 5044 を使用します。次のドメインを使用します。

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io
Anypoint Monitoring エンドポイントについての詳細は、​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed-network-configuration)​を参照してください。 ## [](#メトリクス)メトリクス 各 Mule アプリケーションと API ゲートウェイのレプリカは、メトリクスデータを収集してセキュアな相互 TLS 暗号化を通じて Anypoint Monitoring に送信するメトリクスエージェントを実行します。各レプリカは最大 100 メガバイトのメトリクスをキャッシュできます。その後メトリクスデータを循環し、最新のデータのストレージを提供します。メトリクスを Anypoint Monitoring に送信できない場合、通常はレプリカごとに少なくとも 4 日分のストレージが提供されます。カスタムメトリクスにはより多くのストレージがコンシュームされる場合があります。 次の Anypoint Runtime Fabric 更新によって、Runtime Fabric にデプロイされたアプリケーションの監視メトリクスが影響を受けたり復元されたりすることはありません。 - Runtime Fabric のバックアップと復元 - Runtime Fabric のアップグレード - Runtime Fabric ノードの OS パッチ適用 ## [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 各 Mule アプリケーションと API ゲートウェイのレプリカは、最大 450 メガバイトのログデータをディスクに保存できます。その後ログデータを循環し、最新のログデータのストレージを提供します。 Mule アプリケーションと API ゲートウェイの各レプリカによって生成されたログが収集され、それらが実行されているワーカーノードのディスクに書き込まれます。各ワーカーノードは 1 つのログ転送エージェントを実行します。そのエージェントがこの場所を監視し、ログデータを Anypoint Monitoring に送信します。 ログ転送エージェントは、1 秒あたり最大 300 キロバイトのログデータを送信できます。ワーカーノードごとにデプロイするレプリカは 50 個以内にしてください。 場合によって、複数の行を含むログが Anypoint Monitoring に完全に送信されないことがあります。これは、複数行のログ出力が Runtime Fabric 内の循環によって 2 つのファイルに分割された場合に発生する可能性があります。 [Runtime Manager でアプリケーションをデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric#configure-logging-and-log-levels)​するときにログ転送を有効にしてログレベルを設定できます。 ### [](#anypoint-monitoring-エージェントのリソースと権限の要件)Anypoint Monitoring エージェントのリソースと権限の要件 MuleSoft は Mule アプリケーションと一緒に、テレメトリーを Anypoint コントロールプレーンに送信するための Anypoint Monitoring エージェントを実行します。 Runtime Fabric エージェントバージョン 2.5.x 以降を使用してデプロイまたは管理される Mule アプリケーションには、次のように 2 つの異なるエージェントが使用されます。 - ログを Anypoint Monitoring コントロールプレーンに転送するために、基盤ノードごとに 1 つの DaemonSet。 - メトリクスを Anypoint Monitoring コントロールプレーンに転送するために、アプリケーションレプリカごとに 1 つのサイドカー。 daemonset を最適に機能させるには、次の前提条件に従います。 1. アプリケーションコンテナが次の場所にログを書き込むことを確認します。 - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. DaemonSet がホストパス ​`/var/lib/filebeat-data`​ で作成と書き込みを行うことを確認します。 3. Docker デーモン設定に ​`json-file`​ ログドライバーが含まれていることを確認します。 4. Anypoint Monitoring ログフォワーダー DaemonSet コンテナに、ホストパス ​`/var/lib/filebeat-data`​ のホストへの書き込みアクセス権があることを確認します。 Runtime Fabric バージョン 2.6.x 以上を使用してデプロイまたは管理されるアプリケーションの場合、テレメトリーの転送はアプリケーションレプリカごとに 1 つのサイドカーにまとめられます。 使用する機能に応じて、サイドカーエージェントは最適なパフォーマンスに対応するリソースをコンシュームします。 - デフォルトの Anypoint メトリクスを有効にするには、サイドカーエージェント (アプリケーションレプリカごと) に 0.05vCPU、または CPU 割り当てのコアと 90MiB のメモリ割り当てが必要です。 - [アプリケーションログを Anypoint Monitoring に転送](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric#configure-logging-and-log-levels)​する場合は、サイドカーエージェント (アプリケーションレプリカごと) にアプリケーションレプリカに設定された CPU 制限の最大 30% と最大 150MiB のメモリ割り当てが必要です。 - Mule アプリケーションのデータ生成を追跡する場合は、サイドカーエージェント (アプリケーションレプリカごと) にアプリケーションレプリカに設定された CPU 制限の最大 30% と最大 240MB のメモリ割り当てが必要です。
アプリケーションデプロイメントの失敗を避けるため、基盤となるクラスターに適切な容量を割り当ててください。
### [](#省略可能-runtime-fabric-バージョン-2-6-x-以降のログフォワーダー-deamonset-の無効化)(省略可能) Runtime Fabric バージョン 2.6.x 以降のログフォワーダー DeamonSet の無効化 Runtime Fabric エージェントをバージョン 2.6.0 以降にアップグレードすると、すべてのデプロイメントでメトリクスおよびログ転送に 1 つのサイドカーのみが使用されます。 以前のエージェントで実行されている Mule アプリケーションがある場合、再デプロイして、新しいログ転送メカニズムの使用を開始します。コントロールプレーンで更新を実行すると、再デプロイメントがトリガーされます。 すべてのデプロイメントで新しいサイドカーコンテナが使用されるようになると、​`am-log-forwarder`​ DaemonSet がアイドル状態になります。 DeamonSet を完全に削除するには、対応する [Anypoint Platform API コール](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/)​を使用して次のようなペイロードを送信し、Anypoint Monitoring ログ転送を無効にします。 \[source,json { "anypointMonitoring": false } この無効化は、サイドカーを介した Anypoint Monitoring へのログ転送には影響しません。 ## [](#anypoint-visualizer)Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/)​ には、アプリケーションネットワークグラフのさまざまな側面のビューが表示されます。 グラフを使用してアプリケーションネットワークを調査し、問題を特定して、決定を下すことができます。

デフォルトでは、アプリケーションを Mule Runtime 4.x にデプロイすると、Anypoint Visualizer は無効になります。 詳細は、​「ヘッダー挿入の有効化」​を参照してください。 パフォーマンスへの影響のため、0.2 個未満の vCPU を使用するアプリケーションデプロイメントで Anypoint Visualizer を有効にすることはサポートされません。
## [](#省略可能-mule-アプリケーションの-anypoint-monitoring-の無効化)(省略可能) Mule アプリケーションの Anypoint Monitoring の無効化 Runtime Fabric に Mule アプリケーションをデプロイすると、デフォルトで Anypoint Monitoring が有効になります。Anypoint Monitoring を無効にするには、Mule アプリケーションをデプロイするときに次のカスタムプロパティを渡します。 ```copy anypoint.platform.config.analytics.agent.enabled=false ```
コンプライアンスや地域固有の要件によってチームや組織がメトリクスを Anypoint コントロールプレーンに送信できない場合、それらのメトリクスを Anypoint の使用や請求のために送信することが契約で義務付けられていなければ、Anypoint メトリクスを無効にできます。
## [](#enable-trace-data)トレースデータ収集の有効化
この機能は、組織に Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションがある場合にのみ利用できます。詳細は、​価格設定およびパッケージ​のドキュメントを参照してください。
トレースを行うと、API コールやアプリケーショントランザクションの実行パスを完全に把握できるため、MuleSoft エコシステム内でのトランザクションのパスを理解できます。 アプリケーションのトレースデータ収集を有効にすると、Anypoint Platform によって Mule Runtime Engine からのトレース情報が OpenTelemetry 標準で収集、公開されるため、Anypoint Monitoring ​[Telemetry Exporter](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​ を使用してその情報をエクスポートできます。 - トレースデータ収集は、Mule バージョン 4.6 以降を実行する Runtime Fabric アプリケーションで有効にすることができます。必要な最小 Runtime Fabric エージェントバージョンは 2.6.31 以上です。 - トレースデータ収集は Runtime Manager UI と API のみを使用して有効にすることができ、Mule Maven プラグイン、Anypoint CLI、または Anypoint Studio を使用してトレースデータ収集を有効にすることはできません。 アプリケーションのトレースデータ収集を有効にする手順は次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. **\[Enable tracing (トレースを有効化する)\]**​ チェックボックスをオンにします。 3. 新しいデプロイメントでこの機能を有効にする場合には、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。既存のアプリケーションを編集している場合は ​**\[Apply Changes (変更を適用)\]**​ をクリックします。 トレースを有効にしてアプリケーションを再デプロイすると、Runtime Manager バックエンドによってアプリケーションのトレース計測が開始されます。 # Anypoint Monitoring の使用 Runtime Fabric にデプロイされた Mule アプリケーションと API ゲートウェイには、Anypoint Platform 内のメトリクスを表示できる Anypoint Monitoring のネイティブサポートが含まれます。 ## [](#anypoint-monitoring)Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ には、Mule アプリケーションネットワークの Mule フローとコンポーネントからのフィードバックを提供するツールがあります。Anypoint Monitoring は、アプリケーションデプロイメント内でサイドカーとして実行され、Runtime Fabric にデプロイされた Mule アプリケーションや API ゲートウェイのメトリクスを収集します。Titanium プランのユーザーは、アプリケーションログの取得や検索などの追加機能にアクセスできます。 ## [](#anypoint-monitoring-の有効化)Anypoint Monitoring の有効化 デフォルトでは、Runtime Fabric は、アプリケーションメトリクスを Anypoint Monitoring に送信するように設定されています。データは相互 TLS 暗号化を使用してセキュアに送信されます。メトリクスとログを Anypoint Monitoring に送信するには、アウトバウンドネットワーク接続を使用できる必要があります。 アウトバウンドプロキシが必要な場合、​[「Runtime Fabric でのプロキシの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-proxy-self)​の手順に従って、SOCKS5 プロキシを使用するように Anypoint Runtime Fabric を設定します。 Anypoint Runtime Fabric バージョン 1.8.50 以降でアウトバウンドネットワーク接続を検証するには、Runtime Fabric の各ノードがポート 443 を使用して次のドメインにアウトバウンド TCP (Lumberjack) 通信を送信できることを確認します。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com`

1.8.50 より前のバージョンの Anypoint Runtime Fabric を使用している場合、ポート 443 の代わりにポート 5044 を使用します。次のドメインを使用します。

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io
Anypoint Monitoring エンドポイントについての詳細は、​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed-network-configuration)​を参照してください。 ## [](#メトリクス)メトリクス 各 Mule アプリケーションと API ゲートウェイのレプリカは、メトリクスデータを収集してセキュアな相互 TLS 暗号化を通じて Anypoint Monitoring に送信するメトリクスエージェントを実行します。各レプリカは最大 100 メガバイトのメトリクスをキャッシュできます。その後メトリクスデータを循環し、最新のデータのストレージを提供します。メトリクスを Anypoint Monitoring に送信できない場合、通常はレプリカごとに少なくとも 4 日分のストレージが提供されます。カスタムメトリクスにはより多くのストレージがコンシュームされる場合があります。 次の Anypoint Runtime Fabric 更新によって、Runtime Fabric にデプロイされたアプリケーションの監視メトリクスが影響を受けたり復元されたりすることはありません。 - Runtime Fabric のバックアップと復元 - Runtime Fabric のアップグレード - Runtime Fabric ノードの OS パッチ適用 ## [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 各 Mule アプリケーションと API ゲートウェイのレプリカは、最大 450 メガバイトのログデータをディスクに保存できます。その後ログデータを循環し、最新のログデータのストレージを提供します。 Mule アプリケーションと API ゲートウェイの各レプリカによって生成されたログが収集され、それらが実行されているワーカーノードのディスクに書き込まれます。各ワーカーノードは 1 つのログ転送エージェントを実行します。そのエージェントがこの場所を監視し、ログデータを Anypoint Monitoring に送信します。 ログ転送エージェントは、1 秒あたり最大 300 キロバイトのログデータを送信できます。ワーカーノードごとにデプロイするレプリカは 50 個以内にしてください。 場合によって、複数の行を含むログが Anypoint Monitoring に完全に送信されないことがあります。これは、複数行のログ出力が Runtime Fabric 内の循環によって 2 つのファイルに分割された場合に発生する可能性があります。 [Runtime Manager でアプリケーションをデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric#configure-logging-and-log-levels)​するときにログ転送を有効にしてログレベルを設定できます。 ### [](#anypoint-monitoring-エージェントのリソースと権限の要件)Anypoint Monitoring エージェントのリソースと権限の要件 MuleSoft は Mule アプリケーションと一緒に、テレメトリーを Anypoint コントロールプレーンに送信するための Anypoint Monitoring エージェントを実行します。 Runtime Fabric エージェントバージョン 2.5.x 以降を使用してデプロイまたは管理される Mule アプリケーションには、次のように 2 つの異なるエージェントが使用されます。 - ログを Anypoint Monitoring コントロールプレーンに転送するために、基盤ノードごとに 1 つの DaemonSet。 - メトリクスを Anypoint Monitoring コントロールプレーンに転送するために、アプリケーションレプリカごとに 1 つのサイドカー。 daemonset を最適に機能させるには、次の前提条件に従います。 1. アプリケーションコンテナが次の場所にログを書き込むことを確認します。 - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` 2. DaemonSet がホストパス ​`/var/lib/filebeat-data`​ で作成と書き込みを行うことを確認します。 3. Docker デーモン設定に ​`json-file`​ ログドライバーが含まれていることを確認します。 4. Anypoint Monitoring ログフォワーダー DaemonSet コンテナに、ホストパス ​`/var/lib/filebeat-data`​ のホストへの書き込みアクセス権があることを確認します。 Runtime Fabric バージョン 2.6.x 以上を使用してデプロイまたは管理されるアプリケーションの場合、テレメトリーの転送はアプリケーションレプリカごとに 1 つのサイドカーにまとめられます。 使用する機能に応じて、サイドカーエージェントは最適なパフォーマンスに対応するリソースをコンシュームします。 - デフォルトの Anypoint メトリクスを有効にするには、サイドカーエージェント (アプリケーションレプリカごと) に 0.05vCPU、または CPU 割り当てのコアと 90MiB のメモリ割り当てが必要です。 - [アプリケーションログを Anypoint Monitoring に転送](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric#configure-logging-and-log-levels)​する場合は、サイドカーエージェント (アプリケーションレプリカごと) にアプリケーションレプリカに設定された CPU 制限の最大 30% と最大 150MiB のメモリ割り当てが必要です。 - Mule アプリケーションのデータ生成を追跡する場合は、サイドカーエージェント (アプリケーションレプリカごと) にアプリケーションレプリカに設定された CPU 制限の最大 30% と最大 240MB のメモリ割り当てが必要です。
アプリケーションデプロイメントの失敗を避けるため、基盤となるクラスターに適切な容量を割り当ててください。
### [](#省略可能-runtime-fabric-バージョン-2-6-x-以降のログフォワーダー-deamonset-の無効化)(省略可能) Runtime Fabric バージョン 2.6.x 以降のログフォワーダー DeamonSet の無効化 Runtime Fabric エージェントをバージョン 2.6.0 以降にアップグレードすると、すべてのデプロイメントでメトリクスおよびログ転送に 1 つのサイドカーのみが使用されます。 以前のエージェントで実行されている Mule アプリケーションがある場合、再デプロイして、新しいログ転送メカニズムの使用を開始します。コントロールプレーンで更新を実行すると、再デプロイメントがトリガーされます。 すべてのデプロイメントで新しいサイドカーコンテナが使用されるようになると、​`am-log-forwarder`​ DaemonSet がアイドル状態になります。 DeamonSet を完全に削除するには、対応する [Anypoint Platform API コール](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/runtime-fabric/minor/1.0/console/method/%232251/)​を使用して次のようなペイロードを送信し、Anypoint Monitoring ログ転送を無効にします。 \[source,json { "anypointMonitoring": false } この無効化は、サイドカーを介した Anypoint Monitoring へのログ転送には影響しません。 ## [](#anypoint-visualizer)Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/)​ には、アプリケーションネットワークグラフのさまざまな側面のビューが表示されます。 グラフを使用してアプリケーションネットワークを調査し、問題を特定して、決定を下すことができます。

デフォルトでは、アプリケーションを Mule Runtime 4.x にデプロイすると、Anypoint Visualizer は無効になります。 詳細は、​「ヘッダー挿入の有効化」​を参照してください。 パフォーマンスへの影響のため、0.2 個未満の vCPU を使用するアプリケーションデプロイメントで Anypoint Visualizer を有効にすることはサポートされません。
## [](#省略可能-mule-アプリケーションの-anypoint-monitoring-の無効化)(省略可能) Mule アプリケーションの Anypoint Monitoring の無効化 Runtime Fabric に Mule アプリケーションをデプロイすると、デフォルトで Anypoint Monitoring が有効になります。Anypoint Monitoring を無効にするには、Mule アプリケーションをデプロイするときに次のカスタムプロパティを渡します。 ```copy anypoint.platform.config.analytics.agent.enabled=false ```
コンプライアンスや地域固有の要件によってチームや組織がメトリクスを Anypoint コントロールプレーンに送信できない場合、それらのメトリクスを Anypoint の使用や請求のために送信することが契約で義務付けられていなければ、Anypoint メトリクスを無効にできます。
## [](#enable-trace-data)トレースデータ収集の有効化
この機能は、組織に Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションがある場合にのみ利用できます。詳細は、​価格設定およびパッケージ​のドキュメントを参照してください。
トレースを行うと、API コールやアプリケーショントランザクションの実行パスを完全に把握できるため、MuleSoft エコシステム内でのトランザクションのパスを理解できます。 アプリケーションのトレースデータ収集を有効にすると、Anypoint Platform によって Mule Runtime Engine からのトレース情報が OpenTelemetry 標準で収集、公開されるため、Anypoint Monitoring ​[Telemetry Exporter](https://docs.mulesoft.com/jp/monitoring/telemetry-exporter)​ を使用してその情報をエクスポートできます。 - トレースデータ収集は、Mule バージョン 4.6 以降を実行する Runtime Fabric アプリケーションで有効にすることができます。必要な最小 Runtime Fabric エージェントバージョンは 2.6.31 以上です。 - トレースデータ収集は Runtime Manager UI と API のみを使用して有効にすることができ、Mule Maven プラグイン、Anypoint CLI、または Anypoint Studio を使用してトレースデータ収集を有効にすることはできません。 アプリケーションのトレースデータ収集を有効にする手順は次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. **\[Enable tracing (トレースを有効化する)\]**​ チェックボックスをオンにします。 3. 新しいデプロイメントでこの機能を有効にする場合には、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。既存のアプリケーションを編集している場合は ​**\[Apply Changes (変更を適用)\]**​ をクリックします。 トレースを有効にしてアプリケーションを再デプロイすると、Runtime Manager バックエンドによってアプリケーションのトレース計測が開始されます。 # Anypoint Platform との相互認証の設定

Runtime Fabric バージョン 1.6.45 以降では Runtime Fabric と Anypoint Platform コントロールプレーンを接続するための相互認証がデフォルトで有効になっています。相互認証を有効にするための次の手順は、1.6.45 より前のバージョンにのみ適用されます。
相互認証により Runtime Fabric と Anypoint Platform 間の通信のセキュリティが向上するため、相互認証を強くお勧めします。 バージョン 1.6.45 より前の Runtime Fabric では、Runtime Fabric API を使用して相互認証を有効にします。バージョン 1.3.60 以降の Runtime Fabric では、Runtime Manager を使用して相互認証を有効にします。 ## [](#始める前に)始める前に 相互認証を有効化する前に、次のエンドポイントとポートにすべての Runtime Fabric コントローラーノードとワーカーノードからアクセスできることを確認します。 - US コントロールプレーン: - `configuration-resolver.prod.cloudhub.io:443` - EU コントロールプレーン: - `configuration-resolver.prod-eu.msap.io:443` 相互認証を有効化する前に上記の要件を満たしておかないと、Runtime Fabric でアプリケーションデプロイメントを作成/管理するときにエラーが発生します。 [rtfctl](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​ ユーティリティの最新バージョンを使用すると、すべての必要なエンドポイントに各 Runtime Fabric コントローラーノードからアクセスできることを検証できます。 cd /opt/anypoint/runtimefabric ./rtfctl update ./rtfctl test outbound-network --mutual-tls-check ## [](#runtime-manager-からの相互認証の有効化)Runtime Manager からの相互認証の有効化 1. Runtime Manager で適切な環境を選択し、​**\[Runtime Fabrics\]**​ をクリックします。 2. Runtime Fabric を選択します。 3. **\[Enable mutual authentication with Anypoint Platform connectivity (Anypoint Platform 接続との相互認証を有効にする)\]**​ の切替を ​**\[On (オン)\]**​ に設定します。 ## [](#runtime-fabric-api-を使用した相互認証の有効化)Runtime Fabric API を使用した相互認証の有効化 Runtime Fabric ワークステーションで、次の cURL コマンドを実行します。 curl --location --request PATCH 'https://\[eu1\]anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/' --header 'Content-Type: application/json' --header 'Authorization: Bearer ' --data-raw '{"features": {"enhancedSecurity": true}}' プレースホルダーを固有の値に置き換えます。 - - - # Anypoint Runtime Fabric セキュリティアーキテクチャ Anypoint Runtime Fabric は、Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供し、データの送信元と送信先を確実に所有して管理できるようにします。 MuleSoft のアーキテクチャモデルにより、Runtime Fabric はどこにでもインストールでき、Anypoint Platform のクラウドベースの Anypoint Management Center (Anypoint Runtime Manager、Anypoint API Manager、Anypoint Monitoring、アクセス管理を含む) から一元管理できます。このモデルでは、すべてのデータフローは Runtime Fabric のインストール場所で制御され、Anypoint Management Center に保存されるメタデータとメトリクスは制限されます。このメタデータは、Runtime Fabric、インテグレーションランタイム、API の管理、監視、トラブルシューティングを支援します。 このモデルは、Runtime Fabric エージェントと呼ばれる Runtime Fabric クラスターで実行されるコンポーネントによって提供されます。Runtime Fabric エージェントは、Anypoint Management Center への接続を確立します。また、Runtime Fabric (Kubernetes など) と Anypoint Management Center を提供する内部コンポーネント間の橋渡しとしても機能します。 ## [](#runtime-fabric-のデータフロー)Runtime Fabric のデータフロー 下図は、Runtime Fabric のデータフローを示しています。 ![Runtime Fabric データフローの図](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-security-data-flow.png) ### [](#アクティベーションフロー)アクティベーションフロー アクティベーションフロープロセスの手順は次のとおりです。 1. 認証済みの顧客として、Anypoint コントロールプレーンで実行されている Runtime Fabric Manager から Runtime Fabric アクティベーショントークンを取得します。 2. このアクティベーショントークンは、Runtime Fabric の作成中に Runtime Fabric Manager に渡します。 3. Runtime Fabric Manager は、TLS 証明書、CA チェーン、および Runtime Fabric コンテナレジストリへのログイン情報 (参照のみ) を返します。 4. Runtime Fabric エージェントは、証明書と CA チェーンを Kubernetes シークレットに保存します。 5. Runtime Fabric エージェントは、Docker レジストリへのログイン情報 (参照のみ) を Kubernetes シークレットに保存します。 6. Runtime Fabric エージェントは、TLS 証明書と CA チェーンを使用して、Anypoint Management Center との相互 TLS (mTLS) 接続を確立し、Anypoint Runtime Manager と通信します。 7. コンテナレジストリへのログイン情報は、Runtime Fabric コンテナレジストリから Mule Runtime イメージを取得するために使用されます。 ### [](#管理フロー)管理フロー 管理フロープロセスの手順は次のとおりです。 1. mTLS トンネルは、Anypoint Management Center と Runtime Fabric の間のすべてのメタデータを保護します。このトンネルは、Runtime Fabric エージェントが開始して制御します。 2. アプリケーションデプロイメントメッセージには、アプリケーションとその連動関係を記述したメタデータと、Mule アプリケーションバンドルと設定を取得するための Anypoint Management Center 設定リゾルバーへのリンクが含まれています。設定リゾルバーの通信も、同じ mTLS ログイン情報で保護されます。 3. Anypoint Runtime Manager を使用して、Runtime Fabric クラスターのアプリケーションを管理および監視できます。 ![実行中のアプリケーション状況が表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-security-runtime-manager.png) - 管理機能: Mule アプリケーションの起動、停止、更新 - 監視機能: CPU、メモリ、および Mule アプリケーションメトリクスの監視 ![アプリケーションの監視ビューとメトリクスが表示された Anypoint Monitoring UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-security-anypoint-monitoring.png) 4. Anypoint Analytics を使用して、API の使用状況とパフォーマンスに関するインサイトを取得できます。このサービスは、このメトリクスデータを一方向の TLS 接続を介して Analytics API に直接送信します。​[「Mule API Analytics」](https://docs.mulesoft.com/jp/api-manager/latest/analytics-landing-page)​を参照してください。これらのメトリクスは、要求ごとに固有のデータで構成されます。 ![API の日付別要求数が表示された Anypoint Platform UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric エージェント、Mule アプリケーション、API ゲートウェイは別々のプロセスです。Runtime Fabric エージェントの動作が停止したり、Anypoint Management Center との接続が失われたりしても、Mule アプリケーションと API ゲートウェイは動作を続行します。 6. Mule アプリケーションと API ゲートウェイは Mule フローで定義されたとおりに動作し、顧客データは Anypoint Management Center へトラバースしません。データフローは、ビルドされてランタイムにデプロイされたアプリケーションに固有です。 ### [](#mtls-証明書の更新フロー)mTLS 証明書の更新フロー mTLS 証明書の更新フロープロセスは次のとおりです。 1. mTLS 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい TLS 証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Runtime Fabric エージェントは、再起動して新しい証明書で mTLS トンネルを再確立します。 ### [](#anypoint-monitoring-証明書の更新フロー)Anypoint Monitoring 証明書の更新フロー Anypoint Monitoring 証明書の更新フロープロセスは次のとおりです。 1. Anypoint Monitoring 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Anypoint Monitoring コンテナは新しい証明書で接続を再確立します。 ### [](#mulesoft-イメージの管理)MuleSoft イメージの管理 イメージの管理プロセスは次のとおりです。 - ビルドプロセス中に脆弱性スキャンを実行し、SONAR Quality Gates を設定します。 - 新しいイメージの取得は、すべて顧客によってのみトリガーされます。 - MuleSoft はコンテナイメージを修復し、通常の修復ケイデンスに従って利用可能なパッチを適用します。 - 重大な脆弱性は 30 日以内 - 高度の脆弱性は 90 日以内 - 中程度の脆弱性は 180 日以内 - 低度の脆弱性は 360 日以内 ### [](#コンテナ権限の管理)コンテナ権限の管理 コンテナ権限の管理プロセスは次のとおりです。 1. どのコンテナも Runtime Fabric で root として実行する必要はありません。 2. コンテナ内での権限は極限まで切り詰めます。 3. どのアプリケーションコンテナにも Kubernetes サービスアカウントを添付しません。 Runtime Fabric エージェントと Mule クラスター IP サービスは Kubernetes コントロールプレーンとやり取りします。これらのコンポーネントが何らかのアクションを実行するには、クラスターのすべてのリソースに対してすべての権限を持っている必要があります。 ## [](#クラウドに保存されるメタデータ型)クラウドに保存されるメタデータ型 クラウドには、次のメタデータ型が保存されます。 - Runtime Fabric Runtime Fabric クラスターに関する情報。具体的には次の情報が保存されます。 - 名前 - リージョン - クラスターのバージョン - Runtime Fabric エージェントのバージョン - 関連付けられている環境 - ノード、CPU、メモリ容量、Kubernetes バージョン、Docker バージョン、Kubernetes 健全性警告 - Mule アプリケーション Anypoint Studio を使用して作成するフローアーキテクチャ。このフローアーキテクチャは API に関するメタデータで、Runtime Manager にアップロードされます。その後、Mule アプリケーションが指定された Runtime Fabric にデプロイされます。 - 監視メトリクス (必要に応じて) ランタイムで設定されたポーリングで収集される基本的なランタイムの状況に関するメトリクス。具体的には次の情報が保存されます。 - CPU Usage - Past Hour, Current Time (CPU 使用率 - 過去 1 時間、現在時刻) - Memory Usage - Past Hour, Current Time (メモリ使用量 - 過去 1 時間、現在時刻) - Memory Total - Past Hour, Current Time (メモリ合計 - 過去 1 時間、現在の時刻) - Message Count - Past Hour, Current Time (メッセージ数 - 過去 1 時間、現在の時刻) - Response Time - Past Hour, Current Time (応答時間 - 過去 1 時間、現在の時刻) - Error Count - Past Hour, Current Time (エラー数 - 過去 1 時間、現在の時刻) - 分析メトリクス (必要に応じて) 分析メトリクスを有効にすることで、API がどのように使用され、どの程度のパフォーマンスを実現しているかを把握することができます。これらのメトリクスを設定して、結果を最大 90 日間保存できます。次のメトリクスを取得できます。 - API name (API 参照名) - API version (API バージョン) - Application (アプリケーション) - Browser (ブラウザー) - City (市区郡) - Client IP (クライアント IP) - Continent (大陸) - Country (国) - Hardware platform (ハードウェアプラットフォーム) - OS family (OS ファミリー) - OS major Version (OS メジャーバージョン) - OS minor Version (OS マイナーバージョン) - OS version (OS バージョン) - Postal code (郵便番号) - Resource path (リソースパス) - Status code (状況コード) - Timezone (タイムゾーン) - User agent type (ユーザーエージェント種別) - User agent version (ユーザーエージェントバージョン) - Verb (動詞) - Violated policy name (違反ポリシー名) - Advanced capabilities (高度な機能) このモデルの高度な機能を使用して、ペイロード情報をクラウドに送信できます。これらはデフォルトでは有効化されていないため、使用するには高度な設定で有効化する必要があります。この機能の例としては ​[Runtime Manager Insight](https://docs.mulesoft.com/jp/runtime-manager/insight)​ [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight) があります。 # Anypoint Runtime Fabric セキュリティアーキテクチャ Anypoint Runtime Fabric は、Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供し、データの送信元と送信先を確実に所有して管理できるようにします。 MuleSoft のアーキテクチャモデルにより、Runtime Fabric はどこにでもインストールでき、Anypoint Platform のクラウドベースの Anypoint Management Center (Anypoint Runtime Manager、Anypoint API Manager、Anypoint Monitoring、アクセス管理を含む) から一元管理できます。このモデルでは、すべてのデータフローは Runtime Fabric のインストール場所で制御され、Anypoint Management Center に保存されるメタデータとメトリクスは制限されます。このメタデータは、Runtime Fabric、インテグレーションランタイム、API の管理、監視、トラブルシューティングを支援します。 このモデルは、Runtime Fabric エージェントと呼ばれる Runtime Fabric クラスターで実行されるコンポーネントによって提供されます。Runtime Fabric エージェントは、Anypoint Management Center への接続を確立します。また、Runtime Fabric (Kubernetes など) と Anypoint Management Center を提供する内部コンポーネント間の橋渡しとしても機能します。 ## [](#runtime-fabric-のデータフロー)Runtime Fabric のデータフロー 下図は、Runtime Fabric のデータフローを示しています。 ![Runtime Fabric データフローの図](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-security-data-flow.png) ### [](#アクティベーションフロー)アクティベーションフロー アクティベーションフロープロセスの手順は次のとおりです。 1. 認証済みの顧客として、Anypoint コントロールプレーンで実行されている Runtime Fabric Manager から Runtime Fabric アクティベーショントークンを取得します。 2. このアクティベーショントークンは、Runtime Fabric の作成中に Runtime Fabric Manager に渡します。 3. Runtime Fabric Manager は、TLS 証明書、CA チェーン、および Runtime Fabric コンテナレジストリへのログイン情報 (参照のみ) を返します。 4. Runtime Fabric エージェントは、証明書と CA チェーンを Kubernetes シークレットに保存します。 5. Runtime Fabric エージェントは、Docker レジストリへのログイン情報 (参照のみ) を Kubernetes シークレットに保存します。 6. Runtime Fabric エージェントは、TLS 証明書と CA チェーンを使用して、Anypoint Management Center との相互 TLS (mTLS) 接続を確立し、Anypoint Runtime Manager と通信します。 7. コンテナレジストリへのログイン情報は、Runtime Fabric コンテナレジストリから Mule Runtime イメージを取得するために使用されます。 ### [](#管理フロー)管理フロー 管理フロープロセスの手順は次のとおりです。 1. mTLS トンネルは、Anypoint Management Center と Runtime Fabric の間のすべてのメタデータを保護します。このトンネルは、Runtime Fabric エージェントが開始して制御します。 2. アプリケーションデプロイメントメッセージには、アプリケーションとその連動関係を記述したメタデータと、Mule アプリケーションバンドルと設定を取得するための Anypoint Management Center 設定リゾルバーへのリンクが含まれています。設定リゾルバーの通信も、同じ mTLS ログイン情報で保護されます。 3. Anypoint Runtime Manager を使用して、Runtime Fabric クラスターのアプリケーションを管理および監視できます。 ![実行中のアプリケーション状況が表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-security-runtime-manager.png) - 管理機能: Mule アプリケーションの起動、停止、更新 - 監視機能: CPU、メモリ、および Mule アプリケーションメトリクスの監視 ![アプリケーションの監視ビューとメトリクスが表示された Anypoint Monitoring UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-security-anypoint-monitoring.png) 4. Anypoint Analytics を使用して、API の使用状況とパフォーマンスに関するインサイトを取得できます。このサービスは、このメトリクスデータを一方向の TLS 接続を介して Analytics API に直接送信します。​[「Mule API Analytics」](https://docs.mulesoft.com/jp/api-manager/latest/analytics-landing-page)​を参照してください。これらのメトリクスは、要求ごとに固有のデータで構成されます。 ![API の日付別要求数が表示された Anypoint Platform UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric エージェント、Mule アプリケーション、API ゲートウェイは別々のプロセスです。Runtime Fabric エージェントの動作が停止したり、Anypoint Management Center との接続が失われたりしても、Mule アプリケーションと API ゲートウェイは動作を続行します。 6. Mule アプリケーションと API ゲートウェイは Mule フローで定義されたとおりに動作し、顧客データは Anypoint Management Center へトラバースしません。データフローは、ビルドされてランタイムにデプロイされたアプリケーションに固有です。 ### [](#mtls-証明書の更新フロー)mTLS 証明書の更新フロー mTLS 証明書の更新フロープロセスは次のとおりです。 1. mTLS 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい TLS 証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Runtime Fabric エージェントは、再起動して新しい証明書で mTLS トンネルを再確立します。 ### [](#anypoint-monitoring-証明書の更新フロー)Anypoint Monitoring 証明書の更新フロー Anypoint Monitoring 証明書の更新フロープロセスは次のとおりです。 1. Anypoint Monitoring 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Anypoint Monitoring コンテナは新しい証明書で接続を再確立します。 ### [](#mulesoft-イメージの管理)MuleSoft イメージの管理 イメージの管理プロセスは次のとおりです。 - ビルドプロセス中に脆弱性スキャンを実行し、SONAR Quality Gates を設定します。 - 新しいイメージの取得は、すべて顧客によってのみトリガーされます。 - MuleSoft はコンテナイメージを修復し、通常の修復ケイデンスに従って利用可能なパッチを適用します。 - 重大な脆弱性は 30 日以内 - 高度の脆弱性は 90 日以内 - 中程度の脆弱性は 180 日以内 - 低度の脆弱性は 360 日以内 ### [](#コンテナ権限の管理)コンテナ権限の管理 コンテナ権限の管理プロセスは次のとおりです。 1. どのコンテナも Runtime Fabric で root として実行する必要はありません。 2. コンテナ内での権限は極限まで切り詰めます。 3. どのアプリケーションコンテナにも Kubernetes サービスアカウントを添付しません。 Runtime Fabric エージェントと Mule クラスター IP サービスは Kubernetes コントロールプレーンとやり取りします。これらのコンポーネントが何らかのアクションを実行するには、クラスターのすべてのリソースに対してすべての権限を持っている必要があります。 ## [](#クラウドに保存されるメタデータ型)クラウドに保存されるメタデータ型 クラウドには、次のメタデータ型が保存されます。 - Runtime Fabric Runtime Fabric クラスターに関する情報。具体的には次の情報が保存されます。 - 名前 - リージョン - クラスターのバージョン - Runtime Fabric エージェントのバージョン - 関連付けられている環境 - ノード、CPU、メモリ容量、Kubernetes バージョン、Docker バージョン、Kubernetes 健全性警告 - Mule アプリケーション Anypoint Studio を使用して作成するフローアーキテクチャ。このフローアーキテクチャは API に関するメタデータで、Runtime Manager にアップロードされます。その後、Mule アプリケーションが指定された Runtime Fabric にデプロイされます。 - 監視メトリクス (必要に応じて) ランタイムで設定されたポーリングで収集される基本的なランタイムの状況に関するメトリクス。具体的には次の情報が保存されます。 - CPU Usage - Past Hour, Current Time (CPU 使用率 - 過去 1 時間、現在時刻) - Memory Usage - Past Hour, Current Time (メモリ使用量 - 過去 1 時間、現在時刻) - Memory Total - Past Hour, Current Time (メモリ合計 - 過去 1 時間、現在の時刻) - Message Count - Past Hour, Current Time (メッセージ数 - 過去 1 時間、現在の時刻) - Response Time - Past Hour, Current Time (応答時間 - 過去 1 時間、現在の時刻) - Error Count - Past Hour, Current Time (エラー数 - 過去 1 時間、現在の時刻) - 分析メトリクス (必要に応じて) 分析メトリクスを有効にすることで、API がどのように使用され、どの程度のパフォーマンスを実現しているかを把握することができます。これらのメトリクスを設定して、結果を最大 90 日間保存できます。次のメトリクスを取得できます。 - API name (API 参照名) - API バージョン - アプリケーション - Browser (ブラウザー) - City (市区郡) - Client IP (クライアント IP) - Continent (大陸) - Country (国) - Hardware platform (ハードウェアプラットフォーム) - OS family (OS ファミリー) - OS major Version (OS メジャーバージョン) - OS minor Version (OS マイナーバージョン) - OS version (OS バージョン) - Postal code (郵便番号) - Resource path (リソースパス) - Status code (状況コード) - Timezone (タイムゾーン) - User agent type (ユーザーエージェント種別) - User agent version (ユーザーエージェントバージョン) - Verb (動詞) - Violated policy name (違反ポリシー名) - Advanced capabilities (高度な機能) このモデルの高度な機能を使用して、ペイロード情報をクラウドに送信できます。これらはデフォルトでは有効化されていないため、使用するには高度な設定で有効化する必要があります。この機能の例としては ​[Runtime Manager Insight](https://docs.mulesoft.com/jp/runtime-manager/insight)​ [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight) があります。 # Anypoint Runtime Fabric セキュリティアーキテクチャ Anypoint Runtime Fabric は、Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供し、データの送信元と送信先を確実に所有して管理できるようにします。 MuleSoft のアーキテクチャモデルにより、Runtime Fabric はどこにでもインストールでき、Anypoint Platform のクラウドベースの Anypoint Management Center (Anypoint Runtime Manager、Anypoint API Manager、Anypoint Monitoring、アクセス管理を含む) から一元管理できます。このモデルでは、すべてのデータフローは Runtime Fabric のインストール場所で制御され、Anypoint Management Center に保存されるメタデータとメトリクスは制限されます。このメタデータは、Runtime Fabric、インテグレーションランタイム、API の管理、監視、トラブルシューティングを支援します。 このモデルは、Runtime Fabric エージェントと呼ばれる Runtime Fabric クラスターで実行されるコンポーネントによって提供されます。Runtime Fabric エージェントは、Anypoint Management Center への接続を確立します。また、Runtime Fabric (Kubernetes など) と Anypoint Management Center を提供する内部コンポーネント間の橋渡しとしても機能します。 ## [](#runtime-fabric-のデータフロー)Runtime Fabric のデータフロー 下図は、Runtime Fabric のデータフローを示しています。 ![Runtime Fabric データフローの図](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-security-data-flow.png) ### [](#アクティベーションフロー)アクティベーションフロー アクティベーションフロープロセスの手順は次のとおりです。 1. 認証済みの顧客として、Anypoint コントロールプレーンで実行されている Runtime Fabric Manager から Runtime Fabric アクティベーショントークンを取得します。 2. このアクティベーショントークンは、Runtime Fabric の作成中に Runtime Fabric Manager に渡します。 3. Runtime Fabric Manager は、TLS 証明書、CA チェーン、および Runtime Fabric コンテナレジストリへのログイン情報 (参照のみ) を返します。 4. Runtime Fabric エージェントは、証明書と CA チェーンを Kubernetes シークレットに保存します。 5. Runtime Fabric エージェントは、Docker レジストリへのログイン情報 (参照のみ) を Kubernetes シークレットに保存します。 6. Runtime Fabric エージェントは、TLS 証明書と CA チェーンを使用して、Anypoint Management Center との相互 TLS (mTLS) 接続を確立し、Anypoint Runtime Manager と通信します。 7. コンテナレジストリへのログイン情報は、Runtime Fabric コンテナレジストリから Mule Runtime イメージを取得するために使用されます。 ### [](#管理フロー)管理フロー 管理フロープロセスの手順は次のとおりです。 1. mTLS トンネルは、Anypoint Management Center と Runtime Fabric の間のすべてのメタデータを保護します。このトンネルは、Runtime Fabric エージェントが開始して制御します。 2. アプリケーションデプロイメントメッセージには、アプリケーションとその連動関係を記述したメタデータと、Mule アプリケーションバンドルと設定を取得するための Anypoint Management Center 設定リゾルバーへのリンクが含まれています。設定リゾルバーの通信も、同じ mTLS ログイン情報で保護されます。 3. Anypoint Runtime Manager を使用して、Runtime Fabric クラスターのアプリケーションを管理および監視できます。 ![実行中のアプリケーション状況が表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-security-runtime-manager.png) - 管理機能: Mule アプリケーションの起動、停止、更新 - 監視機能: CPU、メモリ、および Mule アプリケーションメトリクスの監視 ![アプリケーションの監視ビューとメトリクスが表示された Anypoint Monitoring UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-security-anypoint-monitoring.png) 4. Anypoint Analytics を使用して、API の使用状況とパフォーマンスに関するインサイトを取得できます。このサービスは、このメトリクスデータを一方向の TLS 接続を介して Analytics API に直接送信します。​[「Mule API Analytics」](https://docs.mulesoft.com/jp/api-manager/latest/analytics-landing-page)​を参照してください。これらのメトリクスは、要求ごとに固有のデータで構成されます。 ![API の日付別要求数が表示された Anypoint Platform UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric エージェント、Mule アプリケーション、API ゲートウェイは別々のプロセスです。Runtime Fabric エージェントの動作が停止したり、Anypoint Management Center との接続が失われたりしても、Mule アプリケーションと API ゲートウェイは動作を続行します。 6. Mule アプリケーションと API ゲートウェイは Mule フローで定義されたとおりに動作し、顧客データは Anypoint Management Center へトラバースしません。データフローは、ビルドされてランタイムにデプロイされたアプリケーションに固有です。 ### [](#mtls-証明書の更新フロー)mTLS 証明書の更新フロー mTLS 証明書の更新フロープロセスは次のとおりです。 1. mTLS 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい TLS 証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Runtime Fabric エージェントは、再起動して新しい証明書で mTLS トンネルを再確立します。 ### [](#anypoint-monitoring-証明書の更新フロー)Anypoint Monitoring 証明書の更新フロー Anypoint Monitoring 証明書の更新フロープロセスは次のとおりです。 1. Anypoint Monitoring 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Anypoint Monitoring コンテナは新しい証明書で接続を再確立します。 ### [](#mulesoft-イメージの管理)MuleSoft イメージの管理 イメージの管理プロセスは次のとおりです。 - ビルドプロセス中に脆弱性スキャンを実行し、SONAR Quality Gates を設定します。 - 新しいイメージの取得は、すべて顧客によってのみトリガーされます。 - MuleSoft はコンテナイメージを修復し、通常の修復ケイデンスに従って利用可能なパッチを適用します。 - 重大な脆弱性は 30 日以内 - 高度の脆弱性は 90 日以内 - 中程度の脆弱性は 180 日以内 - 低度の脆弱性は 360 日以内 ### [](#コンテナ権限の管理)コンテナ権限の管理 コンテナ権限の管理プロセスは次のとおりです。 1. どのコンテナも Runtime Fabric で root として実行する必要はありません。 2. コンテナ内での権限は極限まで切り詰めます。 3. どのアプリケーションコンテナにも Kubernetes サービスアカウントを添付しません。 Runtime Fabric エージェントと Mule クラスター IP サービスは Kubernetes コントロールプレーンとやり取りします。これらのコンポーネントが何らかのアクションを実行するには、クラスターのすべてのリソースに対してすべての権限を持っている必要があります。 ## [](#クラウドに保存されるメタデータ型)クラウドに保存されるメタデータ型 クラウドには、次のメタデータ型が保存されます。 - Runtime Fabric Runtime Fabric クラスターに関する情報。具体的には次の情報が保存されます。 - 名前 - リージョン - クラスターのバージョン - Runtime Fabric エージェントのバージョン - 関連付けられている環境 - ノード、CPU、メモリ容量、Kubernetes バージョン、Docker バージョン、Kubernetes 健全性警告 - Mule アプリケーション Anypoint Studio を使用して作成するフローアーキテクチャ。このフローアーキテクチャは API に関するメタデータで、Runtime Manager にアップロードされます。その後、Mule アプリケーションが指定された Runtime Fabric にデプロイされます。 - 監視メトリクス (必要に応じて) ランタイムで設定されたポーリングで収集される基本的なランタイムの状況に関するメトリクス。具体的には次の情報が保存されます。 - CPU Usage - Past Hour, Current Time (CPU 使用率 - 過去 1 時間、現在時刻) - Memory Usage - Past Hour, Current Time (メモリ使用量 - 過去 1 時間、現在時刻) - Memory Total - Past Hour, Current Time (メモリ合計 - 過去 1 時間、現在の時刻) - Message Count - Past Hour, Current Time (メッセージ数 - 過去 1 時間、現在の時刻) - Response Time - Past Hour, Current Time (応答時間 - 過去 1 時間、現在の時刻) - Error Count - Past Hour, Current Time (エラー数 - 過去 1 時間、現在の時刻) - 分析メトリクス (必要に応じて) 分析メトリクスを有効にすることで、API がどのように使用され、どの程度のパフォーマンスを実現しているかを把握することができます。これらのメトリクスを設定して、結果を最大 90 日間保存できます。次のメトリクスを取得できます。 - API name (API 参照名) - API バージョン - アプリケーション - Browser (ブラウザー) - City (市区郡) - Client IP (クライアント IP) - Continent (大陸) - Country (国) - Hardware platform (ハードウェアプラットフォーム) - OS family (OS ファミリー) - OS major Version (OS メジャーバージョン) - OS minor Version (OS マイナーバージョン) - OS version (OS バージョン) - Postal code (郵便番号) - Resource path (リソースパス) - Status code (状況コード) - Timezone (タイムゾーン) - User agent type (ユーザーエージェント種別) - User agent version (ユーザーエージェントバージョン) - Verb (動詞) - Violated policy name (違反ポリシー名) - Advanced capabilities (高度な機能) このモデルの高度な機能を使用して、ペイロード情報をクラウドに送信できます。これらはデフォルトでは有効化されていないため、使用するには高度な設定で有効化する必要があります。この機能の例としては ​[Runtime Manager Insight](https://docs.mulesoft.com/jp/runtime-manager/insight)​ [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight) があります。 # Anypoint Runtime Fabric セキュリティアーキテクチャ Anypoint Runtime Fabric は、Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供し、データの送信元と送信先を確実に所有して管理できるようにします。 MuleSoft のアーキテクチャモデルにより、Runtime Fabric はどこにでもインストールでき、Anypoint Platform のクラウドベースの Anypoint Management Center (Anypoint Runtime Manager、Anypoint API Manager、Anypoint Monitoring、アクセス管理を含む) から一元管理できます。このモデルでは、すべてのデータフローは Runtime Fabric のインストール場所で制御され、Anypoint Management Center に保存されるメタデータとメトリクスは制限されます。このメタデータは、Runtime Fabric、インテグレーションランタイム、API の管理、監視、トラブルシューティングを支援します。 このモデルは、Runtime Fabric エージェントと呼ばれる Runtime Fabric クラスターで実行されるコンポーネントによって提供されます。Runtime Fabric エージェントは、Anypoint Management Center への接続を確立します。また、Runtime Fabric (Kubernetes など) と Anypoint Management Center を提供する内部コンポーネント間の橋渡しとしても機能します。 ## [](#security-diagram)Runtime Fabric セキュリティアーキテクチャ 次の図は、顧客の Kubernetes クラスターで実行されている Runtime Fabric のアーキテクチャを示しています。さまざまな Runtime Fabric コアコンポーネント間の通信と MuleSoft Anypoint コントロールプレーンとのやりとりが強調表示されています。すべてのアウトバウンド通信が mTLS で保護されています。 ![rtf security architecture diagram](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-security-architecture-diagram.png) ## [](#runtime-fabric-のデータフロー)Runtime Fabric のデータフロー 下図は、Runtime Fabric のデータフローを示しています。 ![Runtime Fabric データフローの図](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-security-data-flow.png) ### [](#アクティベーションフロー)アクティベーションフロー アクティベーションフロープロセスの手順は次のとおりです。 1. 認証済みの顧客として、Anypoint コントロールプレーンで実行されている Runtime Fabric Manager から Runtime Fabric アクティベーショントークンを取得します。 2. このアクティベーショントークンは、Runtime Fabric の作成中に Runtime Fabric Manager に渡します。 3. Runtime Fabric Manager は、TLS 証明書、CA チェーン、および Runtime Fabric コンテナレジストリへのログイン情報 (参照のみ) を返します。 4. Runtime Fabric エージェントは、証明書と CA チェーンを Kubernetes シークレットに保存します。 5. Runtime Fabric エージェントは、Docker レジストリへのログイン情報 (参照のみ) を Kubernetes シークレットに保存します。 6. Runtime Fabric エージェントは、TLS 証明書と CA チェーンを使用して、Anypoint Management Center との相互 TLS (mTLS) 接続を確立し、Anypoint Runtime Manager と通信します。 7. コンテナレジストリへのログイン情報は、Runtime Fabric コンテナレジストリから Mule Runtime イメージを取得するために使用されます。 ### [](#管理フロー)管理フロー 管理フロープロセスの手順は次のとおりです。 1. mTLS トンネルは、Anypoint Management Center と Runtime Fabric の間のすべてのメタデータを保護します。このトンネルは、Runtime Fabric エージェントが開始して制御します。 2. アプリケーションデプロイメントメッセージには、アプリケーションとその連動関係を記述したメタデータと、Mule アプリケーションバンドルと設定を取得するための Anypoint Management Center 設定リゾルバーへのリンクが含まれています。設定リゾルバーの通信も、同じ mTLS ログイン情報で保護されます。 3. Anypoint Runtime Manager を使用して、Runtime Fabric クラスターのアプリケーションを管理および監視できます。 ![実行中のアプリケーション状況が表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-security-runtime-manager.png) - 管理機能: Mule アプリケーションの起動、停止、更新 - 監視機能: CPU、メモリ、および Mule アプリケーションメトリクスの監視 ![アプリケーションの監視ビューとメトリクスが表示された Anypoint Monitoring UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-security-anypoint-monitoring.png) 4. Anypoint Analytics を使用して、API の使用状況とパフォーマンスに関するインサイトを取得できます。このサービスは、このメトリクスデータを一方向の TLS 接続を介して Analytics API に直接送信します。​[「Mule API Analytics」](https://docs.mulesoft.com/jp/api-manager/latest/analytics-landing-page)​を参照してください。これらのメトリクスは、要求ごとに固有のデータで構成されます。 ![API の日付別要求数が表示された Anypoint Platform UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-security-anypoint-platform.png) 5. Runtime Fabric エージェント、Mule アプリケーション、API ゲートウェイは別々のプロセスです。Runtime Fabric エージェントの動作が停止したり、Anypoint Management Center との接続が失われたりしても、Mule アプリケーションと API ゲートウェイは動作を続行します。 6. Mule アプリケーションと API ゲートウェイは Mule フローで定義されたとおりに動作し、顧客データは Anypoint Management Center へトラバースしません。データフローは、ビルドされてランタイムにデプロイされたアプリケーションに固有です。 ### [](#mtls-証明書の更新フロー)mTLS 証明書の更新フロー mTLS 証明書の更新フロープロセスは次のとおりです。 1. mTLS 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい TLS 証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Runtime Fabric エージェントは、再起動して新しい証明書で mTLS トンネルを再確立します。 ### [](#anypoint-monitoring-証明書の更新フロー)Anypoint Monitoring 証明書の更新フロー Anypoint Monitoring 証明書の更新フロープロセスは次のとおりです。 1. Anypoint Monitoring 証明書の有効期限が近づくと、Runtime Fabric エージェントは既存の mTLS トンネルを介して Anypoint Management Center に新しい証明書を要求します。 2. Anypoint Management Center は新しい証明書を返します。 3. Runtime Fabric エージェントは既存の証明書を新しい証明書で上書きします。 4. Anypoint Monitoring コンテナは新しい証明書で接続を再確立します。 ### [](#mulesoft-イメージの管理)MuleSoft イメージの管理 イメージの管理プロセスは次のとおりです。 - ビルドプロセス中に脆弱性スキャンを実行し、SONAR Quality Gates を設定します。 - 新しいイメージの取得は、すべて顧客によってのみトリガーされます。 - MuleSoft はコンテナイメージを修復し、通常の修復ケイデンスに従って利用可能なパッチを適用します。 - 重大な脆弱性は 30 日以内 - 高度の脆弱性は 90 日以内 - 中程度の脆弱性は 180 日以内 - 低度の脆弱性は 360 日以内 ### [](#コンテナ権限の管理)コンテナ権限の管理 コンテナ権限の管理プロセスは次のとおりです。 1. どのコンテナも Runtime Fabric で root として実行する必要はありません。 2. コンテナ内での権限は極限まで切り詰めます。 3. どのアプリケーションコンテナにも Kubernetes サービスアカウントを添付しません。 Runtime Fabric エージェントと Mule クラスター IP サービスは Kubernetes コントロールプレーンとやり取りします。これらのコンポーネントが何らかのアクションを実行するには、クラスターのすべてのリソースに対してすべての権限を持っている必要があります。 ## [](#クラウドに保存されるメタデータ型)クラウドに保存されるメタデータ型 クラウドには、次のメタデータ型が保存されます。 - Runtime Fabric Runtime Fabric クラスターに関する情報。具体的には次の情報が保存されます。 - 名前 - リージョン - クラスターのバージョン - Runtime Fabric エージェントのバージョン - 関連付けられている環境 - ノード、CPU、メモリ容量、Kubernetes バージョン、Docker バージョン、Kubernetes 健全性警告 - Mule アプリケーション Anypoint Studio を使用して作成するフローアーキテクチャ。このフローアーキテクチャは API に関するメタデータで、Runtime Manager にアップロードされます。その後、Mule アプリケーションが指定された Runtime Fabric にデプロイされます。 - 監視メトリクス (必要に応じて) ランタイムで設定されたポーリングで収集される基本的なランタイムの状況に関するメトリクス。具体的には次の情報が保存されます。 - CPU Usage - Past Hour, Current Time (CPU 使用率 - 過去 1 時間、現在時刻) - Memory Usage - Past Hour, Current Time (メモリ使用量 - 過去 1 時間、現在時刻) - Memory Total - Past Hour, Current Time (メモリ合計 - 過去 1 時間、現在の時刻) - Message Count - Past Hour, Current Time (メッセージ数 - 過去 1 時間、現在の時刻) - Response Time - Past Hour, Current Time (応答時間 - 過去 1 時間、現在の時刻) - Error Count - Past Hour, Current Time (エラー数 - 過去 1 時間、現在の時刻) - 分析メトリクス (必要に応じて) 分析メトリクスを有効にすることで、API がどのように使用され、どの程度のパフォーマンスを実現しているかを把握することができます。これらのメトリクスを設定して、結果を最大 90 日間保存できます。次のメトリクスを取得できます。 - API name (API 参照名) - API バージョン - アプリケーション - Browser (ブラウザー) - City (市区郡) - Client IP (クライアント IP) - Continent (大陸) - Country (国) - Hardware platform (ハードウェアプラットフォーム) - OS family (OS ファミリー) - OS major Version (OS メジャーバージョン) - OS minor Version (OS マイナーバージョン) - OS version (OS バージョン) - Postal code (郵便番号) - Resource path (リソースパス) - Status code (状況コード) - Timezone (タイムゾーン) - User agent type (ユーザーエージェント種別) - User agent version (ユーザーエージェントバージョン) - Verb (動詞) - Violated policy name (違反ポリシー名) - Advanced capabilities (高度な機能) このモデルの高度な機能を使用して、ペイロード情報をクラウドに送信できます。これらはデフォルトでは有効化されていないため、使用するには高度な設定で有効化する必要があります。この機能の例としては ​[Runtime Manager Insight](https://docs.mulesoft.com/jp/runtime-manager/insight)​ [https://docs.mulesoft.com/runtime-manager/insight](https://docs.mulesoft.com/runtime-manager/insight) があります。 # Anypoint Runtime Fabric でのインバウンドトラフィックの有効化 (VM/ベアメタル) VM/ベアメタルの Runtime Fabric は、Mule アプリケーションや API プロキシへのインバウンドトラフィックを管理するための負荷分散を提供します。ネットワークトラフィックは、アプリケーションの複数のレプリカで分散されます。デフォルトでは、レプリカは異なるワーカー VM にデプロイされます。 複数の環境で Runtime Fabric インスタンスを共有できます。インストール後、各 Runtime Fabric インスタンスの 1 つ以上の環境を設定して、アプリケーションデプロイメントを有効にします。Mule アプリケーションや API ゲートウェイをデプロイするには、1 つ以上の環境を各 Runtime Fabric インスタンスに関連付けます。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションとは異なる VM/ベアメタルの Runtime Fabric のインスタンスにデプロイされる必要があります。 デフォルトでは、不要なリソースをコンシュームしないようにインバウンドトラフィックが無効になっています。Mule アプリケーションや API ゲートウェイでインバウンド接続をリスンできるようにするには、インバウンドトラフィックを有効にする必要があります。 ## [](#インバウンドトラフィックを有効にする準備)インバウンドトラフィックを有効にする準備 VM/ベアメタルの Runtime Fabric のインバウンドトラフィックを有効にする前に、次のことに対応済みであることを確認してください。 - VM/ベアメタルの Runtime Fabric で実行されるアプリケーションへのトラフィックを管理するための外部 TCP ロードバランサーの設定など、​[「インフラストラクチャ要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs#infrastructure-requirements)​で挙げられている前提となるネットワーク関連タスクを完了します。 - 外部 TCP ロードバランサーが接続できるコントローラーノードまたは専用ノード (インストール時に設定した選択によって異なります) のすべての IP アドレスを集めます。これらの IP アドレスは、VM/ベアメタルの Runtime Fabric のインストールが完了するまでわからない場合もあります。 - 内部ロードバランサーの共有モードと専用モードのどちらを使用するかを決定します。デフォルトでは、インバウンドロードバランサーは VM/ベアメタルの Runtime Fabric で設定された各コントローラーノードで実行されます。 トラフィック負荷が小さい場合は、コントローラーノードをクラスター管理とインバウンドトラフィック TLS 終端の両方に使用できます。 トラフィック負荷が大きい場合は専用トラフィックを使用してください。詳細は、​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 インバウンドトラフィックのレプリカの数をコントローラーノードの数 (共有モードの場合) または専用の内部ロードバランサーノードの数 (専用モードの場合) に合わせて設定します。これらのノードのすべての IP アドレスを外部ロードバランサーまたは DNS 解決に含めます。そうしないと、トラフィックをロードバランサーから Runtime Fabric に転送できません。 - トラフィックをアプリケーションに転送するために使用する 1 つ以上のドメインの情報を集めます。 - TLS 証明書で署名されたドメインを外部ロードバランサーが提供する 1 つ以上の IP アドレスに関連付けるように DNS 設定を定義します。 ## [](#インバウンドトラフィックを有効にする)インバウンドトラフィックを有効にする VM/ベアメタルの Anypoint Runtime Fabric のインバウンドトラフィックを有効にするには、次のタスクを実行します。 1. Anypoint Runtime Manager を使用してインバウンドトラフィックを設定します。 2. HTTPS のトランスポートレイヤーセキュリティ (TLS) コンテキストを設定します。 3. 必要に応じて、セキュリティポリシーを選択します。 4. 必要に応じて、詳細オプションを選択します。 5. 必要に応じて、内部ロードバランサーのログを設定します。 6. インバウンドトラフィックが有効になっていることを確認します。 7. 外部ロードバランサーを設定します。 8. アプリケーションをデプロイします。 ### [](#anypoint-runtime-manager-を使用してインバウンドトラフィックを設定する)Anypoint Runtime Manager を使用してインバウンドトラフィックを設定する インバウンドトラフィックを設定する手順は次のとおりです。 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric インスタンスの名前を選択して、管理ページを開きます。 3. **\[Associated Environments (関連付けられた環境)\]**​ タブで、Runtime Fabric インスタンスがアプリケーションをデプロイする環境に関連付けられていることを確認します。 4. **\[Inbound Traffic (インバウンドトラフィック)\]**​ を選択し、​**\[Enable inbound traffic (インバウンドトラフィックを有効化)\]**​ を選択します。 5. **\[Resource Allocation (リソース割り当て)\]**​ セクションで、​**\[Shared Mode (共有モード)\]**​ または ​**\[Dedicated Mode (専用モード)\]**​ を選択します。 6. 内部ロードバランサーの各コントローラーノードに割り当てるコアの最小数を指定します。 7. 内部ロードバランサーの各コントローラーノードに割り当てる最小メモリを指定します。 8. **\[Protocol (プロトコル)\]**​ セクションで次のいずれかのプロトコルオプションを選択します。 - **Accept HTTPS requests…​ (HTTPS 要求を受け入れる…​)** 次のオプションのいずれかを選択します。 - **HTTP から HTTPS にリダイレクトする** インバウンドトラフィックが有効になると、VM/ベアメタルの Runtime Fabric に送信される HTTP 要求は、301 応答を受信して、ポート 443 で HTTPS にリダイレクトします。 - **HTTP 要求も受け入れる** VM/ベアメタルの Runtime Fabric に送信された HTTP 要求はポート 80 で受信されます。 - **HTTP 要求を削除する** VM/ベアメタルの Runtime Fabric に送信された HTTP 要求は無視されます。 - **Accept HTTP requests only (HTTP 要求のみを受け入れる)** この場合は証明書を使用しないため、​**\[Add Domain (ドメインを追加)\]**​ をクリックして要求をアプリケーションに転送するためのドメインを手動で入力します。
[Accept HTTP requests only (HTTP 要求のみを受け入れる)]​ は、外部接続用の安全なオプションではありません。このオプションは、外部ロードバランサーがすでに安全な TLS 接続を終端している状態で VM/ベアメタルの Runtime Fabric に HTTP 経由でトラフィックを転送するネットワーク接続で使用してください。
### [](#https-の-tls-コンテキストを設定する)HTTPS の TLS コンテキストを設定する **\[Protocol (プロトコル)\]**​ セクションで ​**\[Accept HTTPS requests…​ (HTTPS 要求を受け入れる…​)\]**​ を選択した場合は、Anypoint Runtime Fabric が受信するすべてのインバウンドトラフィックは TLS で暗号化されます。この場合、インバウンドトラフィックを有効化すると、最大 10 件の証明書を提供できますが、最低 1 件の有効な TLS 証明書が必要です。詳細は、​[「鍵と証明書の CPU 要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#cpu_cert_req)​を参照してください。 TLS をセットアップするときには次のいずれかを使用します。 - 公開証明書、非公開キー、CA パス 公開証明書と非公開キーは Privacy-Enhanced Mail (PEM) 形式にして、TLS のデフォルト値を使用する必要があります。PEM ファイルは ​`.cer`​、​`.crt`​、または ​`.pem`​ 拡張子の Base64 でエンコードされた ASCII ファイルです。CA パスには、証明書からルートへのパスを提供する中間証明書とルート証明書が含まれます。このファイルは、証明書に署名した CA からダウンロードできます。この項目にエントリを入力すると、すべての接続における VM/ベアメタルの Runtime Fabric のロードバランサーは証明書とクライアントへのパスの両方を送信します。多くのクライアントでは、証明書を検証できるように、サーバーが CA パスを送信する必要があります。 このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。これは、VM/ベアメタルの Runtime Fabric 用に TLS コンテキストが存在しない場合のデフォルトのオプションです。 - Java Keystore (JKS) ファイル JKS ファイルは認証用のリポジトリまたは公開キー証明書であり、秘密鍵は保存されません。このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。 - シークレットマネージャーからインポートされた TLS コンテキスト このオプションは高度なユーザーのみが使用してください。シークレットマネージャーから TLS コンテキストをインポートし、TLS コンテキストの作成、相互認証、暗号化の選択、TLS バージョンの選択などの高度な設定をサポートしています。 所有している Runtime Fabric インスタンスの TLS 設定とポリシーのみを変更できます。継承された Runtime Fabric インスタンスの場合、TLS 設定は参照のみです。 TLS の終端は計算コストが高くなるため、十分な量の CPU を割り当ててスループットを増やし、レイテンシーを減らしてください。TLS 非公開キーの種類とサイズが与える影響を含め、CPU 割り当ておよびスループットについての詳細は、​[「内部ロードバランサーのメモリ割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer-memory-allocation)​を参照してください。 1. Runtime Manager で ​**\[Add Certificate (証明書を追加)\]**​ を選択します。 2. HTTPS の TLS コンテキストを設定するには、適切なオプションを選択します。 - オプション 1: **\[Upload PEM (JKS をアップロード)\]** 1. **\[Public certificate (公開証明書)\]**​ には、インバウンドトラフィックサーバーの公開証明書を指定します。​**\[Domains (ドメイン)\]**​ 項目には、​**\[Application url (アプリケーション URL)\]**​ に使用できるドメインがリストされます。最初のドメインがデフォルトです。その他の値は ​**\[Applications (アプリケーション)\]→\[Ingress (イングレス)\]**​ ページで選択できます。 証明書はパスフレーズと、Runtime Fabric にデプロイされている各アプリケーションのドメインを指定する共通名 (CN) を使用して設定されている必要があります。 - 共通名にワイルドカードが含まれている場合、デプロイされている各アプリケーションのエンドポイントの形式は ​`{app-name}.{common-name}`​ のようになります。 - 共通名にワイルドカードが含まれていない場合、エンドポイントの形式は ​`{common-name}/{app-name}`​ のようになります。 2. **\[Private key (非公開キー)\]**​ の値を指定します。これは、証明書の非公開キーを含む PEM 形式のファイルです。 鍵が暗号化されていない場合は (推奨されません)、​**\[Key password (キーパスワード)\]**​ 項目を空白のままにします。 3. **\[CA path certificate File (Optional) (CA パス証明書ファイル (省略可能))\]**​ の値を指定します。 4. **\[Add certificate (証明書を追加)\]**​ を選択します。​**\[Key password (キーパスワード)\]**​ 項目はセキュリティ上の理由から無効になっています。 公開証明書、非公開キー、キーパスコードはシークレットマネージャーに保存されます。 - オプション 2: **\[Upload JKS (JKS をアップロード)\]** 1. **\[Keystore File (キーストアファイル)\]**​ の値を指定します。少なくとも、キーストアファイルには公開証明書と非公開キーが含まれています。 2. **\[Keystore Password (キーストアパスワード)\]**​ の値を指定します。 3. **\[Select alias from keystore (キーストアから別名を選択)\]**​ ウィンドウで、​**\[Alias (別名)\]**​ に値を指定します。別名は、特定のキーペアを選択するために使用されます。 4. **\[Add certificate (証明書を追加)\]**​ を選択します。​**\[Keystore Passcode (キーストアパスコード)\]**​ 項目と ​**\[Key Passcode (キーパスコード)\]**​ 項目はセキュリティ上の理由から無効になっています。 JKS ファイルの情報は組織のグローバルシークレットグループに保存されます。 - オプション 3: **\[Import from Secrets Manager (シークレットマネージャーからインポート)\]**​ [「シークレットマネージャーからの TLS コンテキストのインポート (高度なユーザー向け)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-adv-tls-context)​の手順を参照してください。
シークレットマネージャーで TLS コンテキストを変更しても、インバウンドトラフィック設定には自動的に適用されません。変更後に ​[Inbound Traffic (インバウンドトラフィック)]​ タブに移動して、​[Save and Deploy (保存してデプロイ)]​ をクリックしてください。
## [](#省略可能-セキュリティポリシーを選択する)(省略可能) セキュリティポリシーを選択する セキュリティポリシーを追加する必要がある場合は、まずセキュリティポリシーを定義する必要があります。定義すると、​**\[HTTP Limits (HTTP 制限)\]**​、​**\[Web Application Firewall (WAF) (Web アプリケーションファイアウォール (WAF))\]**​、​**\[IP Whitelist (IP ホワイトリスト)\]**​、または ​**\[Denial of Service (DoS) (サービス拒否 (DoS))\]**​ ドロップダウンリストのオプションとして表示されます。 複数の FQDN を使用して VM/ベアメタルの Runtime Fabric インスタンスにアクセスするには、サブジェクト代替名 (SAN) 証明書プロパティに FQDN エントリを追加します。証明書の SAN プロパティに複数の FQDN エントリが登録されている場合、アプリケーションをデプロイすると、利用できる URL のリストが ​**\[Applications (アプリケーション)\] → \[Ingress (イングレス)\]**​ セクションに表示されます。URL は優先度の順にリストされているわけではなく、最初の URL がデフォルトというわけでもありません。
Anypoint Security でセキュリティポリシーを定義するには、Anypoint Platform アカウントの「Anypoint Security - Edge」エンタイトルメントが必要です。​[Management Center]​ で ​[Security (セキュリティ)]​ がリストされていない場合は、アカウントで Anypoint Security を有効にするようにカスタマーサクセスマネージャーに依頼してください。詳細は、​「Edge の Anypoint Security ポリシー」​を参照してください。
## [](#省略可能-詳細オプションを選択する)(省略可能) 詳細オプションを選択する 次の表では、環境で設定する場合がある追加の設定オプションについて説明します。 この表では、​**「Source IP (送信元 IP)」**​は要求を行っているクライアントを指します。
値 説明

Max Connections (最大接続数)

最大許容同時接続数。

デフォルト値​: 512 接続

Max Requests per Connection (接続あたりの最大要求数)

接続あたりの最大許容要求数。
この値の範囲は 1 ～ 4194304 です。
この値により、接続でどれぐらいの再利用が許可されるのかが決まるため、この値を低くする場合、TLS で暗号化された接続を終了および再確立するのに必要な CPU の量を考慮してください。

最大許容値​: 接続あたり 1000 要求

デフォルト値​: 1000。この値で、セキュリティとパフォーマンスのバランスを取ります。詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。

Connection Idle Time-out (接続アイドルタイムアウト)

アイドル接続を許可する最大時間。
この値は、アイドル接続を終了してリソースを解放するのに役立ちます。
この値は、常に ​[Read Request Time-out (読み取り要求タイムアウト)]​ よりも高くする必要があります。

デフォルト値​: 15 秒

Read Request Time-out (読み取り要求タイムアウト)

要求の読み取りに費やすことができる最大時間。この時間を超えると終了します。
この値により、大きなペイロードの要求や低速なクライアントを終了して、リソースを使用できる状態を維持できます。これは、応答の送信後に接続を終了しないクライアントや低速な要求によって接続プールが枯渇することを回避するのに役立ちます。

たとえば、Mule アプリケーションの応答時間がこの値よりも長くなると、接続が自動的に終了します。
この値は、常に上記で設定される ​[Connection Idle Time-out (接続アイドルタイムアウト)]​ の値よりも低くする必要があります。

デフォルト値​: 10 秒

Read Response Time-out (読み取り応答タイムアウト)

応答の開始に費やすことができる最大時間。この時間を超えると接続が終了します。
この値により、大きなペイロードの要求を終了して、リソースを使用できる状態を維持できます。

デフォルト値​: 300 秒

Write Response Time-out (書き込み応答タイムアウト)

リクエストヘッダーの読み取りの終了から応答の書き込みの終了までに費やすことができる最大時間。この時間を超えると要求が終了します。

デフォルト値​: 10 秒

Max Pipeline Depth (最大パイプライン深度)

同じクライアントからの最大許容要求数。
この値は、クライアントが送信できる同時要求数を定義します。
クライアントがこの数値を超えると、キューの要求が応答を受信するまで超過要求が読み取られなくなります。

デフォルト値​: クライアントあたり 10 要求

[Source IP header name (送信元 IP ヘッダー名)]​ と ​[enable proxy protocol (プロキシプロトコルを有効化)]

適用されるシナリオに基づいて次の値を設定します。

  1. VM/ベアメタルの Runtime Fabric がロードバランサーの背後にデプロイされていない。
    次の値を設定する必要はありません。

    Source IP header name (送信元 IP ヘッダー名)​: 空白
    Enable proxy protocol (プロキシプロトコルを有効化)​: オフ

  2. VM/ベアメタルの Runtime Fabric がプロキシプロトコルが設定された AWS ロードバランサーの背後にデプロイされている。
    ​[enable proxy protocol (プロキシプロトコルを有効化)]​ オプションをオンにする必要があります。

    Source IP header name (送信元 IP ヘッダー名)​: 空白
    Enable proxy protocol (プロキシプロトコルを有効化)​: オン

  3. VM/ベアメタルの Runtime Fabric が AWS 以外のロードバランサーの背後にある。
    VM/ベアメタルの Runtime Fabric が別の種別のロードバランサー (F5 や NGINX など) の背後にデプロイされている場合、[HTTP Header (HTTP ヘッダー)] 項目で送信元 IP アドレスを指定できます。この場合、送信元 IP ヘッダーが含まれる HTTP ヘッダー名を入力します。

    このヘッダー項目が含まれていない HTTP メッセージは拒否されます。送信元 IP アドレスに使用される 2 つの共通の HTTP ヘッダー名は次のとおりです。

    • Forwarded: RFC7239 準拠の IP ヘッダー。

    • X-Forwarded-For: ロードバランサーの 1 つ以上の IP (「192.16.23.34、172.16.21.36」など) が含まれる 2014 年以前の非標準ヘッダー

      Source IP header name (送信元 IP ヘッダー名)​: 空白以外
      Enable proxy protocol (プロキシプロトコルを有効化)​: オフ

デフォルト値​: 空白とオフ。
WebSockets を使用している場合は、次の手順を実行します。 - HTTP 接続を WebSockets にアップグレードするための正しいリクエストヘッダーを提供します。 - [WebSockets リスナーを使用して Mule Runtime Engine を設定します](https://docs.mulesoft.com/mule-runtime/latest/mule-server-notifications)​。 - `Connection Idle Time-out`​ の値を 900 秒 (15 分) に増加して、WebSockets Mule アプリケーションのデフォルト値との一貫性を確保します。 ## [](#省略可能-内部ロードバランサーログを設定する)(省略可能) 内部ロードバランサーログを設定する 内部ロードバランサーのログレベルを定義できます。Runtime Fabric では、次のログレベル (詳細度の昇順で記載) がサポートされています。 - FATAL - ERROR - WARNING - INFO - VERBOSE - DEBUG - TRACE ログレベルが詳細になるほど (WARNING、INFO、VERBOSE、DEBUG、TRACE など)、各要求でコンシュームする CPU リソースが増えます。ログレベルを調整したり、内部ロードバランサーのリソースを割り当てたりする場合、この点を考慮してください。 デフォルトでは、エンドポイントの背後にあるすべての IP アドレスのアクティビティが記録されます。より詳細なログレベルを使用する場合、CPU 消費量を減らすには、IP 検索条件を追加して特定の IP アドレスのみを記録します。また、この機能を使用して、特定の IP アドレスまたは限られた数の IP アドレスの接続をデバッグすると、ログの数量が減少します。 1. **\[Inbound Traffic (インバウンドトラフィック)\]**​ タブから、​**\[Logs (ログ)\]**​ を選択します。 2. **\[Add Filter (検索条件を追加)\]**​ を選択します。 3. **\[IP\]**​ 項目で、CIDR 表記を使用して 1 つの IP アドレスまたはアドレスのサブセットを入力します。 4. この IP 検索条件に適用するログレベルを選択します。 5. **\[OK\]**​ を選択します。 6. **\[Save and Deploy (保存してデプロイ)\]**​ を選択して内部ロードバランサーをデプロイします。 デプロイメントが完了するまでには、最大 1 分かかる場合があります。 検証エラーが発生すると、エラーメッセージが返されます。検証に成功すると、ページの右下にメッセージが緑色のテキストで表示され、デプロイメント要求が受け入れられたことを示します。デプロイメントの状況は、ページの一番上で確認できます。 ## [](#インバウンドトラフィックが有効になっていることを確認する)インバウンドトラフィックが有効になっていることを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```none curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```none curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#外部ロードバランサーを設定する)外部ロードバランサーを設定する インバウンドトラフィックを有効にしたら、クライアントがデプロイされたアプリケーションに要求を送信できるように、有効になっている各アプリケーションに受信トラフィックをルーティングするよう VM/ベアメタルの Runtime Fabric を設定する必要があります。 HTTPS 要求の場合は、VM/ベアメタルの Runtime Fabric の各コントローラー VM で HTTPS トラフィックを負荷分散するように外部ロードバランサーを設定する必要があります。コントローラー VM は、Anypoint Runtime Fabric を強化するコンポーネントを実行する専用の仮想マシンです。各コントローラー VM は、内部ロードバランサーのレプリカを実行し、ポート 443 でリスンするように設定されています。 インストール時に指定した IP の VM/ベアメタルの Runtime Fabric コントローラーノードまたは専用ノードにトラフィックを転送するように、外部 TCP ロードバランサーをプロビジョニングします。 ### [](#外部ロードバランサーの要件)外部ロードバランサーの要件 複数のコントローラー VM を実行する場合、各コントローラー VM に直面する VM/ベアメタルの Runtime Fabric 外に外部ロードバランサーが必要になります。 外部ロードバランサーは TCP 負荷分散をサポートしている必要があり、各コントローラー VM の IP アドレスが含まれるサーバープールを使用して設定されている必要があります。また、外部ロードバランサーには、ポート 443 をリスンする状態チェックも設定されている必要があります。 この外部ロードバランサーの設定では、次のことを実現できます。 - 高可用性 - 障害からの保護 - 内部ロードバランサーのレプリカが再起動するか、削除されて別のコントローラー VM で再スケジュールされた場合の自動フェールオーバー 外部ロードバランサーを設定する手順は、次のとおりです。 1. 外部ロードバランサーを追加するときは、​**「詳細オプション」**​で説明している情報を確認してください。 2. TLS 証明書から取得される共通名を使用する前に DNS を設定します。DNS は、Runtime Fabric にデプロイされているアプリケーションや API ゲートウェイに要求を送信するために必要になります。共通名を外部ロードバランサーまたはコントローラー VM の IP アドレスにマップするために「A レコード」を DNS プロバイダーに追加します。 ## [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができたら、以下の手順を実行します。 1. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric)​の手順に従ってください。 2. アプリケーションの URL を確認します。 **\[Ingress (イングレス)\]**​ タブでは、アプリケーション要求の設定を更新できます。インバウンドトラフィックを有効にすると、デフォルトの動作は新しいアプリケーションのデプロイメントを許可するように変更されます。インバウンドトラフィックを有効にする前に Runtime Fabric にデプロイされたアプリケーションがある場合、この設定が有効になるまでそれらはインバウンド要求を受信しません。 アプリケーションの URL には、アプリケーションのルーティングパスが含まれています。アプリケーションのドメインをデフォルトドメイン以外に設定する場合は、​**\[Domain (ドメイン)\]**​ ドロップダウンからドメインを選択します。 ## [](#tls-証明書を表示する)TLS 証明書を表示する 既存のデプロイメントの TLS 証明書を表示するには、次の手順を実行します。 1. Runtime Fabric インスタンスの ​**\[Inbound Traffic (インバウンドトラフィック)\]**​ タブを選択します。 2. **\[Domains (ドメイン)\]**​ セクションまでスクロールします。 3. **\[…\]**​ を選択します。 4. **\[View details (詳細を詳細)\]**​ を選択します。 ## [](#tls-証明書を更新または削除する)TLS 証明書を更新または削除する TLS 証明書の情報を更新または削除するには、次の手順を実行します。 1. Runtime Manager で、​**\[Inbound Traffic (インバウンドトラフィック)\]**​ タブを選択します。 2. **\[Domains (ドメイン)\]**​ セクションまでスクロールします。 3. **\[…\]**​ を選択します。 4. **\[Delete (削除)\]**​ を選択します。 5. 更新された証明書の情報を追加するには、​**\[Add certificate (証明書を追加)\]**​ を選択して、ステップ 1 の手順に従って新しい証明書を設定します。 ## [](#共有モードと専用モードの切り替え)共有モードと専用モードの切り替え 共有モードと専用モードを切り替える必要がある場合、次の点を確認します。 - 変更の前に、共有 IP アドレスまたは専用 IP アドレスがロードバランサーまたは DNS 解決に含まれない場合、すべてのインバウンドトラフィックが失われます。 - **共有モードから専用モード**​に変更する場合、コントローラーノードの IP アドレスの代わりに専用の内部ロードバランサーノードの IP アドレスを外部ロードバランサーに含める必要があります。インバウンド要求を転送するまではコントローラーノードと専用の内部ロードバランサーノードの両方を一時的に含めます。 - **専用モードから共有モード**​に変更する場合、デプロイメントに合わせて ​**\[CPU Cores (CPU コア)\]**​ および ​**\[Memory (メモリ)\]**​ 項目を適切に設定します。使用可能なリソースの量は、すべてのノードリソースをコンシュームできる専用モードと共有モードでは大幅に異なる可能性があります。 ## [](#アップグレードの変更点)アップグレードの変更点 Runtime Fabric バージョン 1.5.0 以降の場合、内部ロードバランサーは Runtime Fabric コンポーネントのアップグレードプロセス中にアップグレードされます。 ## [](#テストのために-tls-証明書を生成する)テストのために TLS 証明書を生成する テスト目的で、次の手順を使用して証明書と鍵のペアを生成できます。 1. マシンで次のコマンドを実行して証明書と鍵のペアを生成します。 openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 2. 鍵のパスフレーズを入力します。 3. 必要な情報を入力します。共通名を求められた場合、Runtime Fabric で使用するドメインを入力します。 共通名にワイルドカード (​`*.example.com`​ など) を使用する場合、アプリケーション URL では ​`{app-name}.example.com`​ の形式が使用されます。使用しない場合、アプリケーション URL では ​`example.com/{app-name}`​ の形式が使用されます。 ## [](#tls-証明書の期限切れ)TLS 証明書の期限切れ 証明書 (自己署名と CA 署名の両方) には必ず有効期限があります。デフォルトでは、証明書は作成されてから 1 年後に有効期限が切れます。 30 日以内に期限が切れる証明書については次の警告が表示され、証明書の期限が切れる前に新しい証明書と鍵のペアをアップロードするよう促されます。 - **\[Runtime Fabrics\]**​ ページでは、TLS 証明書が 30 日以内に期限切れになる場合、​`TLS Expiring`​ が ​**\[Inbound traffic (インバウンドトラフィック)\]**​ 列に表示されます。 - **\[Runtime Fabrics\]**​ ページでは、TLS 証明書が期限切れになると、警告がその Runtime Fabric インスタンスの ​**\[Inbound traffic (インバウンドトラフィック)\]**​ 列に表示されます。 - **\[Inbound Traffic (インバウンドトラフィック)\]**​ タブでは、TLS 証明書が 30 に以内に期限切れになる場合、警告が表示されます。TLS 証明書が期限切れになると、有効期限情報で ​**\[Certificate File (証明書ファイル)\]**​ 項目に赤い警告が含まれます。 ## [](#関連情報)関連情報 - [Anypoint Runtime Fabric でのリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation) - [Anypoint Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) # Anypoint Runtime Fabric の概要 Anypoint Runtime Fabric は、Anypoint Platform を介した集中管理を使用して、あらゆる環境で Mule アプリケーション、複合 API、および API ゲートウェイを実行できるコンテナサービスです。 Anypoint Runtime Fabric のいくつかの機能を次に示します。 - アプリケーションサーバーごとに個別の Mule Runtime サーバーを実行することによるアプリケーション間の分離。 - 同じ一連のリソースで複数のバージョンの Mule Runtime サーバーを実行する機能。 - 複数のレプリカにわたるアプリケーションのスケーリング。 - 自動化されたアプリケーションフェールオーバー。 - Anypoint Runtime Manager を使用したアプリケーション管理。
アカウントで Anypoint Runtime Fabric を有効にする方法については、カスタマーサクセスマネージャーにお問い合わせください。
Anypoint Runtime Fabric には、次の 2 つの管理オプションがあります。 - **自己管理型 Kubernetes の Runtime Fabric**​: 運用および管理する既存の Kubernetes 環境にインストールする Runtime Fabric のバージョン。このバージョンでは、Amazon Elastic Kubernetes Service (Amazon EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) がサポートされます。 - **VM/ベアメタルの Runtime Fabric**​: MuleSoft が必要なソフトウェアインフラストラクチャコンポーネント (Docker や Kubernetes など) を提供する Runtime Fabric のバージョン。このバージョンは、運用および管理する仮想マシンにインストールします。 これらの各オプションには、独自のシステム要件とインストール手順があります。各オプションについての詳細は、​[「自己管理型 Kubernetes の Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​および​[「VM/ベアメタルの Anypoint Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal)​を参照してください。
Runtime Fabric オプション IT 管理者 MuleSoft 組織のシステム管理者

自己管理型 Kubernetes

IT 管理者は Amazon EKS、AKS、または GKE で Kubernetes クラスターを作成および設定する必要があります。この役割は、Runtime Fabric のインストールと Kubernetes の管理も担当します。

Anypoint Platform 内で Runtime Fabric を作成し、アプリケーションをデプロイし、その他のタスクを実行します。

VM/ベアメタル

Runtime Fabric を実行するインフラストラクチャを作成および設定します。この役割は、Runtime Fabric をインストールし、その運用中に基盤となるインフラストラクチャを管理する責任もあります。

Anypoint Platform 内で Runtime Fabric を作成し、アプリケーションをデプロイし、その他のタスクを実行します。
## [](#自己管理型-kubernetes-の-runtime-fabric-と-vmベアメタルの-runtime-fabric-の機能サポートマトリックス)自己管理型 Kubernetes の Runtime Fabric と VM/ベアメタルの Runtime Fabric の機能サポートマトリックス
Table 1. 自己管理型 Kubernetes の Runtime Fabric と VM/ベアメタルの Runtime Fabric でサポートされる機能
自己管理型 Kubernetes の Runtime Fabric VM/ベアメタルの Runtime Fabric

Mules および API ゲートウェイのデプロイのサポート

サポート

サポート

Kubernetes と Docker

含まれない。
Kubernetes および Docker のインスタンスを Amazon EKS、AKS、または GKE クラスター経由で提供します。

Included (インクルード)

Linux ディストリビューションでのインストール

サポート

RHEL および CentOS のみでサポート

ノードの自動スケーリング

AWS、Azure、または Google Cloud の機能を使用してサポート

サポート対象外

外部ログ転送

外部ログ転送サービスを提供する必要があります。

Included (インクルード)

内部ロードバランサー

内部ロードバランサー (イングレスコントローラー) を提供する必要があります。

Included (インクルード)

Anypoint Security Edge

サポート対象外

サポート

Anypoint Security トークナイゼーション

サポート対象外

サポート

オペレーションセンター

含まれない
AWS、Azure、または Google Cloud で監視とアラートを有効にできます。

Included (インクルード)
## [](#anypoint-runtime-fabric-とスタンドアロン-mule-runtime-ハイブリッドデプロイメント)Anypoint Runtime Fabric とスタンドアロン Mule Runtime (ハイブリッドデプロイメント) Mule アプリケーションのハイブリッドデプロイメントでは、Mule Runtime の 1 つのバージョンをサーバーにインストールし、1 つ以上のアプリケーションをサーバーにデプロイする必要があります。各アプリケーションは、Mule Runtime サーバーとそれに割り当てられたリソースを共有します。証明書やデータベース接続などの他のリソースも、ドメインを使用して共有される場合があります。 Anypoint Runtime Fabric は、異なる方法でリソースをプロビジョニングします。各 Mule アプリケーションや API ゲートウェイは、独自の Mule Runtime およびコンテナ内で実行されます。コンテナで使用できるリソースは、Mule アプリケーションや API プロキシのデプロイ時に指定します。これにより、Mule アプリケーションは他の連動関係を使用せずに複数のノードにわたって水平方向にスケールできます。また、同じノードのリソースに対して異なるアプリケーションが相互に競合しないようになります。 ## [](#関連情報)関連情報 - [自己管理型 Kubernetes の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed) - [VM/ベアメタルの Anypoint Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal) # Anypoint Runtime Fabric の概要 Anypoint Runtime Fabric を使用すると、作成、設定、管理する Kubernetes クラスターに Mule アプリケーションおよび API プロキシをデプロイできます。 公開クラウドで作業をしていて、Kubernetes クラスターの管理についてある程度の専門知識がある場合、Runtime Fabric は以下をサポートします。 - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) 公開 K8s ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes エンジン (RKE)](https://rke.docs.rancher.com/) - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://tanzu.vmware.com/kubernetes-grid#:~:text=Tanzu%20Kubernetes%20Grid%20is%20an,any%20app%20on%20any%20cloud.&text=Run%20the%20same%20Kubernetes%20across,workloads%20properly%20isolated%20and%20secure) Anypoint Runtime Fabric のいくつかの機能を次に示します。 - アプリケーションサーバーごとに個別の Mule Runtime サーバーを実行することによるアプリケーション間の分離。 - 同じ一連のリソースで複数のバージョンの Mule Runtime サーバーを実行する機能。 - 複数のレプリカにわたるアプリケーションのスケーリング。 - 自動化されたアプリケーションフェールオーバー。 - Anypoint Runtime Manager を使用したアプリケーション管理。 Anypoint コントロールプレーン機能、Anypoint CLI、Mule Maven プラグインは、すべてのパートナーで広く利用できます。ランタイムプレーンでは、Helm ベースの Runtime Fabric 管理と機能のみが VMWare Tanzu、Alibaba ACK、および Rancher でサポートされています。各プラットフォームでの機能のサポート状況を下表に示します。
ユースケースのサポート状況 AWS EKS および AWS EKS-A IBM Openshift 製品 AKS & GKE VMWare Tanzu、Alibaba ACK、Rancher

Runtime Manager、アクセス管理、Anypoint Monitoring など、Anypoint コントロールプレーンへのアクセスと使用。

はい

はい

はい

はい

Mule Maven Plugin、Runtime Fabric API、Anypoint CLI などの自動化ツール。

はい

はい

はい

はい

互換性のある K8s バージョンでの Runtime Fabric 機能のサポート。

はい

はい

はい

はい

Runtime Fabric コアソフトウェアおよび Mule Runtime Engine イメージのセキュリティ更新。

はい

はい

はい

はい

Helm​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

はい

はい

はい

Helm​ による CRD を使用したアプリケーションワークロードのカスタマイズ。

はい

はい

はい

はい

アプリケーション監視のための Log4j サポート

はい

はい

はい

はい

rtfctl report​ コマンドによるトラブルシューティング。

はい

はい

はい

はい

Operator​ による Runtime Fabric ソフトウェアのライフサイクル管理。

-

はい

-

-

FIPS モードの有効化によるセキュリティの強化。

はい

-

はい

-

コントロールプレーンによる Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ を使用したセキュアプロパティの設定。

はい

-

はい

-

rtfctl​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ によるフルバックアップ/復元。

はい

-

はい

-

リファレンス実装 (テンプレート) - パフォーマンスチューニング、CRD 設定 K8s のベストプラクティス、推奨クラスターサイジング、ネットワーク設定。

はい

-

-

-
## [](#共有責任としての-anypoint-runtime-fabric)共有責任としての Anypoint Runtime Fabric Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が提供して管理する領域と MuleSoft によって提供される領域を理解することが重要です。 Anypoint Runtime Fabric インスタンスにおける MuleSoft とお客様の異なる共有責任を下図に示します。 ![Anypoint Runtime Fabric の共有責任の図](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-shared-responsibility.png) ### [](#mulesoft-によって提供される内容)MuleSoft によって提供される内容 MuleSoft は、Runtime Fabric エージェント、Mule Runtime Engine (Mule)、および Mule アプリケーションのデプロイに使用されるその他の連動関係を提供します。Runtime Fabric エージェントは、デプロイメント、ポッド、レプリカセット、イングレスリソースなどの Kubernetes リソースを生成して更新することで Mule アプリケーションをデプロイして管理します。 #### [](#runtime-fabric-コアサービス)Runtime Fabric コアサービス Anypoint Runtime Fabric とその基盤となるコンポーネントは、EKS、AKS、GKE、または RedHat OpenShift 環境で Kubernetes デプロイメントオブジェクトとして実行されます。これらのオブジェクトは Anypoint Platform を通じて管理します。 Linux ベースのオペレーティングシステムは、Kubernetes クラスターで Runtime Fabric コンポーネントを実行するすべてのノードに必要です。 - Runtime Fabric エージェント Runtime Fabric エージェントはポッドとしてクラスターにデプロイされ、起動時に確立される mTLS アウトバウンド接続を介してコントロールプレーンと通信します。 エージェントはイベント駆動型です。アプリケーションの状態変更により Kubernetes イベントが生成されると、エージェントはアプリケーションの現在の状態を説明するメタデータをコントロールプレーンに送信します。Kubernetes イベントにはアプリケーションポッドの起動、更新、または再起動が含まれます。 エージェントはコントロールプレーンからの受信要求もリスンします。エージェントがコントロールプレーンからメッセージを受信すると、エージェントはメッセージで指定された Kubernetes リソースに変更を加えます。このような変更には、新しいアプリケーションの作成、既存のアプリケーションの更新、アプリケーションの削除などがあります。 - Mule クラスター IP サービス Mule アプリケーションがクラスター内でピアを発見するために使用する API を提供します。 - リソースキャッシュ アプリケーション連動関係のクラスター-ローカルキャッシュを提供します。 これらのサービスは、コア Runtime Fabric インストールの名前空間とレプリカ内で分離されています。これらのサービスはアプリケーションまたはノードの増加に伴って増加しません。 #### [](#アプリケーションサービス)アプリケーションサービス Runtime Fabric によって次のアプリケーションサービスがインストールされるのは、ユーザーが設定した場合のみです。 - 永続性ゲートウェイ: Mule アプリケーション (ユーザーが設定した複製) への永続性 ObjectStore v2 インターフェースを提供します。 - Anypoint Monitoring サイドカー: 監視およびログ記録用 (アプリケーションレプリカごとに 1 つのサイドカーがデプロイされる) ### [](#お客様による管理)お客様による管理 お客様は、Runtime Fabric に使用される Kubernetes クラスターのプロビジョニング、設定、管理の責任を負います。下記のような、Kubernetes クラスターで機能をセットアップまたは有効化するために使用される追加の設定も、お客様が管理する責任を負います。 - イングレスコントローラーと​[イングレスリソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​ - 内部負荷分散 - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - ホストランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。これには、組織内の次のチームの支援が必要です - IT チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 ## [](#anypoint-runtime-fabric-でのアプリケーションデプロイメントの動作)Anypoint Runtime Fabric でのアプリケーションデプロイメントの動作 Anypoint Runtime Fabric にアプリケーションをデプロイするときは、次の動作が起こります。 1. Runtime Manager を使用してアプリケーションデプロイメントをトリガーします。 2. 対象クラスターの Runtime Fabric エージェントがアプリケーションをデプロイする要求を受信します。 3. Runtime Fabric によってアプリケーションが既存の名前空間に割り当てられるか、必要な場合は新しい名前空間が作成されます。 4. Runtime Fabric によってデプロイメント、ConfigMap、シークレット、サービス、イングレスなど、適切な Kubernetes リソースが生成されます。 5. Kubernetes デプロイメントリソースに init コンテナが含まれている場合は、Runtime Fabric リソースキャッシュから連動関係が取得されます。 6. リソースキャッシュに必須の連動関係が含まれていない場合、Runtime Fabric によってコントロールプレーンから取得され、リソースキャッシュに追加されます。 ![Runtime Fabric のアプリケーションデプロイメントワークフロー](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-app-deployment.png) ### [](#anypoint-runtime-fabric-で名前空間を割り当てる)Anypoint Runtime Fabric で名前空間を割り当てる 各アプリケーションはアプリケーションの環境に基づいて Kubernetes 名前空間にデプロイされます。 1. Runtime Fabric によって表示ラベルが ​`rtf.mulesoft.com/envId=`​ の名前空間が検索されます。 2. Runtime Fabric によってその表示ラベルを見つけられなかった場合は、名前が ​``​ の名前空間が検索されます。 3. Runtime Fabric によってその名前空間が見つけられなかった場合、​``​ という名前の新しい名前空間が作成されます。 ![アプリケーション名前空間の割り当てフローチャート](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-namespace-flow.png) ### [](#アプリケーションデプロイメントの監視)アプリケーションデプロイメントの監視 Runtime Fabric エージェントでは、​`rtf.mulesoft.com/id`​ という表示ラベルの付いた Kubernetes デプロイメントを監視します。Kubernetes によってデプロイメントの状態が更新されると、エージェントによってその更新がコントロールプレーンに送信されます。詳細は、​[「ログ」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/limitations-self#logs)​と​[「監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/limitations-self#monitoring)​を参照してください。 ## [](#runtime-fabric-の機能サポートリスト)Runtime Fabric の機能サポートリスト 次の表に、サポートされる機能とサポートされない機能を示します。
機能 状況

Mules および API ゲートウェイのデプロイのサポート

サポート

Kubernetes と Docker

含まれない。

Kubernetes および Docker のインスタンスを Amazon EKS、AKS、または GKE クラスター経由で提供します。

Linux ディストリビューションでのインストール

サポート

ノードの自動スケーリング

AWS、Azure、Google Cloud、または RedHat OpenShift の機能を使用してサポート

外部ログ転送

ログを外部システムに転送するように Log4j をセットアップできます。

内部ロードバランサー

内部ロードバランサー (イングレスコントローラー) を提供する必要があります。

Anypoint Security Edge

サポート対象外

Anypoint Security トークナイゼーション

サポート対象外

オペレーションセンター

含まれない
AWS、Azure、Google Cloud、または RedHat OpenShift で監視とアラートを有効にできます。
## [](#anypoint-runtime-fabric-とスタンドアロン-mule-runtime-ハイブリッドデプロイメント)Anypoint Runtime Fabric とスタンドアロン Mule Runtime (ハイブリッドデプロイメント) Mule アプリケーションのハイブリッドデプロイメントでは、Mule Runtime の 1 つのバージョンをサーバーにインストールし、1 つ以上のアプリケーションをサーバーにデプロイする必要があります。各アプリケーションは、Mule Runtime サーバーとそれに割り当てられたリソースを共有します。証明書やデータベース接続などの他のリソースも、ドメインを使用して共有される場合があります。 Anypoint Runtime Fabric は、異なる方法でリソースをプロビジョニングします。各 Mule アプリケーションや API ゲートウェイは、独自の Mule Runtime およびコンテナ内で実行されます。コンテナで使用できるリソースは、Mule アプリケーションや API プロキシのデプロイ時に指定します。これにより、Mule アプリケーションは他の連動関係を使用せずに複数のノードにわたって水平方向にスケールできます。また、同じノードのリソースに対して異なるアプリケーションが相互に競合しないようになります。 # Anypoint Runtime Fabric の概要 Anypoint Runtime Fabric を使用すると、作成、設定、管理する Kubernetes クラスターに Mule アプリケーションおよび API プロキシをデプロイできます。 公開クラウドで作業をしていて、Kubernetes クラスターの管理についてある程度の専門知識がある場合、Runtime Fabric は以下をサポートします。 - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) 公開 K8s ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes エンジン (RKE)](https://rke.docs.rancher.com/) - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://tanzu.vmware.com/kubernetes-grid#:~:text=Tanzu%20Kubernetes%20Grid%20is%20an,any%20app%20on%20any%20cloud.&text=Run%20the%20same%20Kubernetes%20across,workloads%20properly%20isolated%20and%20secure) Anypoint Runtime Fabric のいくつかの機能を次に示します。 - アプリケーションサーバーごとに個別の Mule Runtime サーバーを実行することによるアプリケーション間の分離。 - 同じ一連のリソースで複数のバージョンの Mule Runtime サーバーを実行する機能。 - 複数のレプリカにわたるアプリケーションのスケーリング。 - 自動化されたアプリケーションフェールオーバー。 - Anypoint Runtime Manager を使用したアプリケーション管理。 Anypoint コントロールプレーン機能、Anypoint CLI、Mule Maven プラグインは、すべてのパートナーで広く利用できます。ランタイムプレーンでは、Helm ベースの Runtime Fabric 管理と機能のみが VMWare Tanzu、Alibaba ACK、および Rancher でサポートされています。各プラットフォームでの機能のサポート状況を下表に示します。
ユースケースのサポート状況 AWS EKS および AWS EKS-A IBM Openshift 製品 AKS & GKE VMWare Tanzu、Alibaba ACK、Rancher

Runtime Manager、アクセス管理、Anypoint Monitoring など、Anypoint コントロールプレーンへのアクセスと使用。

はい

はい

はい

はい

Mule Maven Plugin、Runtime Fabric API、Anypoint CLI などの自動化ツール。

はい

はい

はい

はい

互換性のある K8s バージョンでの Runtime Fabric 機能のサポート。

はい

はい

はい

はい

Runtime Fabric コアソフトウェアおよび Mule Runtime Engine イメージのセキュリティ更新。

はい

はい

はい

はい

Helm​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

はい

はい

はい

Helm​ による CRD を使用したアプリケーションワークロードのカスタマイズ。

はい

はい

はい

はい

アプリケーション監視のための Log4j サポート

はい

はい

はい

はい

rtfctl report​ コマンドによるトラブルシューティング。

はい

はい

はい

はい

Operator​ による Runtime Fabric ソフトウェアのライフサイクル管理。

-

はい

-

-

FIPS モードの有効化によるセキュリティの強化。

はい

-

はい

-

コントロールプレーンによる Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ を使用したセキュアプロパティのセットアップ。

はい

-

はい

-

rtfctl​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ によるフルバックアップ/復元。

はい

-

はい

-

リファレンス実装 (テンプレート) - パフォーマンスチューニング、CRD 設定 K8s のベストプラクティス、推奨クラスターサイジング、ネットワーク設定。

はい

-

-

-
## [](#共有責任としての-anypoint-runtime-fabric)共有責任としての Anypoint Runtime Fabric Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が提供して管理する領域と MuleSoft によって提供される領域を理解することが重要です。 Anypoint Runtime Fabric インスタンスにおける MuleSoft とお客様の異なる共有責任を下図に示します。 ![Anypoint Runtime Fabric の共有責任の図](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-shared-responsibility.png) ### [](#mulesoft-によって提供される内容)MuleSoft によって提供される内容 MuleSoft は、Runtime Fabric エージェント、Mule Runtime Engine (Mule)、および Mule アプリケーションのデプロイに使用されるその他の連動関係を提供します。Runtime Fabric エージェントは、デプロイメント、ポッド、レプリカセット、イングレスリソースなどの Kubernetes リソースを生成して更新することで Mule アプリケーションをデプロイして管理します。 #### [](#runtime-fabric-コアサービス)Runtime Fabric コアサービス Anypoint Runtime Fabric とその基盤となるコンポーネントは、EKS、AKS、GKE、または RedHat OpenShift 環境で Kubernetes デプロイメントオブジェクトとして実行されます。これらのオブジェクトは Anypoint Platform を通じて管理します。 Linux ベースのオペレーティングシステムは、Kubernetes クラスターで Runtime Fabric コンポーネントを実行するすべてのノードに必要です。 - Runtime Fabric エージェント Runtime Fabric エージェントはポッドとしてクラスターにデプロイされ、起動時に確立される mTLS アウトバウンド接続を介してコントロールプレーンと通信します。 エージェントはイベント駆動型です。アプリケーションの状態変更により Kubernetes イベントが生成されると、エージェントはアプリケーションの現在の状態を説明するメタデータをコントロールプレーンに送信します。Kubernetes イベントにはアプリケーションポッドの起動、更新、または再起動が含まれます。 エージェントはコントロールプレーンからの受信要求もリスンします。エージェントがコントロールプレーンからメッセージを受信すると、エージェントはメッセージで指定された Kubernetes リソースに変更を加えます。このような変更には、新しいアプリケーションの作成、既存のアプリケーションの更新、アプリケーションの削除などがあります。 - Mule クラスター IP サービス Mule アプリケーションがクラスター内でピアを発見するために使用する API を提供します。 - リソースキャッシュ アプリケーション連動関係のクラスター-ローカルキャッシュを提供します。 これらのサービスは、コア Runtime Fabric インストールの名前空間とレプリカ内で分離されています。これらのサービスはアプリケーションまたはノードの増加に伴って増加しません。 #### [](#アプリケーションサービス)アプリケーションサービス Runtime Fabric によって次のアプリケーションサービスがインストールされるのは、ユーザーが設定した場合のみです。 - 永続性ゲートウェイ: Mule アプリケーション (ユーザーが設定した複製) への永続性 ObjectStore v2 インターフェースを提供します。 - Anypoint Monitoring サイドカー: 監視およびログ記録用 (アプリケーションレプリカごとに 1 つのサイドカーがデプロイされる) ### [](#お客様による管理)お客様による管理 お客様は、Runtime Fabric に使用される Kubernetes クラスターのプロビジョニング、設定、管理の責任を負います。下記のような、Kubernetes クラスターで機能をセットアップまたは有効化するために使用される追加の設定も、お客様が管理する責任を負います。 - イングレスコントローラーと​[イングレスリソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​ - 内部負荷分散 - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - ホストランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。これには、組織内の次のチームの支援が必要です - IT チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 ## [](#anypoint-runtime-fabric-でのアプリケーションデプロイメントの動作)Anypoint Runtime Fabric でのアプリケーションデプロイメントの動作 Anypoint Runtime Fabric にアプリケーションをデプロイするときは、次の動作が起こります。 1. Runtime Manager を使用してアプリケーションデプロイメントをトリガーします。 2. 対象クラスターの Runtime Fabric エージェントがアプリケーションをデプロイする要求を受信します。 3. Runtime Fabric によってアプリケーションが既存の名前空間に割り当てられるか、必要な場合は新しい名前空間が作成されます。 4. Runtime Fabric によってデプロイメント、ConfigMap、シークレット、サービス、イングレスなど、適切な Kubernetes リソースが生成されます。 5. Kubernetes デプロイメントリソースに init コンテナが含まれている場合は、Runtime Fabric リソースキャッシュから連動関係が取得されます。 6. リソースキャッシュに必須の連動関係が含まれていない場合、Runtime Fabric によってコントロールプレーンから取得され、リソースキャッシュに追加されます。 ![Runtime Fabric のアプリケーションデプロイメントワークフロー](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-app-deployment.png) ### [](#anypoint-runtime-fabric-で名前空間を割り当てる)Anypoint Runtime Fabric で名前空間を割り当てる 各アプリケーションはアプリケーションの環境に基づいて Kubernetes 名前空間にデプロイされます。 1. Runtime Fabric によって表示ラベルが ​`rtf.mulesoft.com/envId=`​ の名前空間が検索されます。 2. Runtime Fabric によってその表示ラベルを見つけられなかった場合は、名前が ​``​ の名前空間が検索されます。 3. Runtime Fabric によってその名前空間が見つけられなかった場合、​``​ という名前の新しい名前空間が作成されます。 ![アプリケーション名前空間の割り当てフローチャート](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-namespace-flow.png) ### [](#アプリケーションデプロイメントの監視)アプリケーションデプロイメントの監視 Runtime Fabric エージェントでは、​`rtf.mulesoft.com/id`​ という表示ラベルの付いた Kubernetes デプロイメントを監視します。Kubernetes によってデプロイメントの状態が更新されると、エージェントによってその更新がコントロールプレーンに送信されます。詳細は、​[「ログ」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/limitations-self#logs)​と​[「監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/limitations-self#monitoring)​を参照してください。 ## [](#runtime-fabric-の機能サポートリスト)Runtime Fabric の機能サポートリスト 次の表に、サポートされる機能とサポートされない機能を示します。
機能 状況

Mules および API ゲートウェイのデプロイのサポート

サポート

Kubernetes と Docker

含まれない。

Kubernetes および Docker のインスタンスを Amazon EKS、AKS、または GKE クラスター経由で提供します。

Linux ディストリビューションでのインストール

サポート

ノードの自動スケーリング

AWS、Azure、Google Cloud、または RedHat OpenShift の機能を使用してサポート

外部ログ転送

ログを外部システムに転送するように Log4j をセットアップできます。

内部ロードバランサー

内部ロードバランサー (イングレスコントローラー) を提供する必要があります。

Anypoint Security Edge

サポート対象外

Anypoint Security トークナイゼーション

サポート対象外

オペレーションセンター

含まれない
AWS、Azure、Google Cloud、または RedHat OpenShift で監視とアラートを有効にできます。
## [](#anypoint-runtime-fabric-とスタンドアロン-mule-runtime-ハイブリッドデプロイメント)Anypoint Runtime Fabric とスタンドアロン Mule Runtime (ハイブリッドデプロイメント) Mule アプリケーションのハイブリッドデプロイメントでは、Mule Runtime の 1 つのバージョンをサーバーにインストールし、1 つ以上のアプリケーションをサーバーにデプロイする必要があります。各アプリケーションは、Mule Runtime サーバーとそれに割り当てられたリソースを共有します。証明書やデータベース接続などの他のリソースも、ドメインを使用して共有される場合があります。 Anypoint Runtime Fabric は、異なる方法でリソースをプロビジョニングします。各 Mule アプリケーションや API ゲートウェイは、独自の Mule Runtime およびコンテナ内で実行されます。コンテナで使用できるリソースは、Mule アプリケーションや API プロキシのデプロイ時に指定します。これにより、Mule アプリケーションは他の連動関係を使用せずに複数のノードにわたって水平方向にスケールできます。また、同じノードのリソースに対して異なるアプリケーションが相互に競合しないようになります。 # Anypoint Runtime Fabric の概要 Anypoint Runtime Fabric を使用すると、作成、設定、管理する Kubernetes クラスターに Mule アプリケーションおよび API プロキシをデプロイできます。 公開クラウドで作業をしていて、Kubernetes クラスターの管理についてある程度の専門知識がある場合、Runtime Fabric は以下をサポートします。 - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) 公開 K8s ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes エンジン (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-with-tanzu-tkg/GUID-2005FFCD-07F4-450E-BAE5-445BE9D629AE.html) Anypoint Runtime Fabric のいくつかの機能を次に示します。 - アプリケーションサーバーごとに個別の Mule Runtime サーバーを実行することによるアプリケーション間の分離。 - 同じ一連のリソースで複数のバージョンの Mule Runtime サーバーを実行する機能。 - 複数のレプリカにわたるアプリケーションのスケーリング。 - 自動化されたアプリケーションフェールオーバー。 - Anypoint Runtime Manager を使用したアプリケーション管理。 Anypoint コントロールプレーン機能、Anypoint CLI、Mule Maven プラグインは、すべてのパートナーで広く利用できます。ランタイムプレーンでは、Helm ベースの Runtime Fabric 管理と機能のみが VMWare Tanzu、Alibaba ACK、および Rancher でサポートされています。各プラットフォームでの機能のサポート状況を下表に示します。
ユースケースのサポート状況 AWS EKS および AWS EKS-A IBM Openshift 製品 AKS & GKE VMWare Tanzu、Alibaba ACK、Rancher

Runtime Manager、アクセス管理、Anypoint Monitoring など、Anypoint コントロールプレーンへのアクセスと使用。

はい

はい

はい

はい

Mule Maven Plugin、Runtime Fabric API、Anypoint CLI などの自動化ツール。

はい

はい

はい

はい

互換性のある K8s バージョンでの Runtime Fabric 機能のサポート。

はい

はい

はい

はい

Runtime Fabric コアソフトウェアおよび Mule Runtime Engine イメージのセキュリティ更新。

はい

はい

はい

はい

Helm​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

はい

はい

はい

Helm​ による CRD を使用したアプリケーションワークロードのカスタマイズ。

はい

はい

はい

はい

アプリケーション監視のための Log4j サポート

はい

はい

はい

はい

rtfctl report​ コマンドによるトラブルシューティング。

はい

はい

はい

はい

Operator​ による Runtime Fabric ソフトウェアのライフサイクル管理。

-

はい

-

-

コントロールプレーンによる Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ を使用したセキュアプロパティのセットアップ。

はい

-

はい

-

rtfctl​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ によるフルバックアップ/復元。

はい

-

はい

-

リファレンス実装 (テンプレート) - パフォーマンスチューニング、CRD 設定 K8s のベストプラクティス、推奨クラスターサイジング、ネットワーク設定。

はい

-

-

-
## [](#共有責任としての-anypoint-runtime-fabric)共有責任としての Anypoint Runtime Fabric Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が提供して管理する領域と MuleSoft によって提供される領域を理解することが重要です。 Anypoint Runtime Fabric インスタンスにおける MuleSoft とお客様の異なる共有責任を下図に示します。 ![Anypoint Runtime Fabric の共有責任の図](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-shared-responsibility.png) ### [](#mulesoft-によって提供される内容)MuleSoft によって提供される内容 MuleSoft は、Runtime Fabric エージェント、Mule Runtime Engine (Mule)、および Mule アプリケーションのデプロイに使用されるその他の連動関係を提供します。Runtime Fabric エージェントは、デプロイメント、ポッド、レプリカセット、イングレスリソースなどの Kubernetes リソースを生成して更新することで Mule アプリケーションをデプロイして管理します。 #### [](#runtime-fabric-コアサービス)Runtime Fabric コアサービス Anypoint Runtime Fabric とその基盤となるコンポーネントは、EKS、AKS、GKE、または RedHat OpenShift 環境で Kubernetes デプロイメントオブジェクトとして実行されます。これらのオブジェクトは Anypoint Platform を通じて管理します。 Linux ベースのオペレーティングシステムは、Kubernetes クラスターで Runtime Fabric コンポーネントを実行するすべてのノードに必要です。 - Runtime Fabric エージェント Runtime Fabric エージェントはポッドとしてクラスターにデプロイされ、起動時に確立される mTLS アウトバウンド接続を介してコントロールプレーンと通信します。 エージェントはイベント駆動型です。アプリケーションの状態変更により Kubernetes イベントが生成されると、エージェントはアプリケーションの現在の状態を説明するメタデータをコントロールプレーンに送信します。Kubernetes イベントにはアプリケーションポッドの起動、更新、または再起動が含まれます。 エージェントはコントロールプレーンからの受信要求もリスンします。エージェントがコントロールプレーンからメッセージを受信すると、エージェントはメッセージで指定された Kubernetes リソースに変更を加えます。このような変更には、新しいアプリケーションの作成、既存のアプリケーションの更新、アプリケーションの削除などがあります。 - Mule クラスター IP サービス Mule アプリケーションがクラスター内でピアを発見するために使用する API を提供します。 - リソースキャッシュ アプリケーション連動関係のクラスター-ローカルキャッシュを提供します。 これらのサービスは、コア Runtime Fabric インストールの名前空間とレプリカ内で分離されています。これらのサービスはアプリケーションまたはノードの増加に伴って増加しません。 #### [](#アプリケーションサービス)アプリケーションサービス Runtime Fabric によって次のアプリケーションサービスがインストールされるのは、ユーザーが設定した場合のみです。 - 永続性ゲートウェイ: Mule アプリケーション (ユーザーが設定した複製) への永続性 ObjectStore v2 インターフェースを提供します。 - Anypoint Monitoring サイドカー: 監視およびログ記録用 (アプリケーションレプリカごとに 1 つのサイドカーがデプロイされる) ### [](#お客様による管理)お客様による管理 お客様は、Runtime Fabric に使用される Kubernetes クラスターのプロビジョニング、設定、管理の責任を負います。下記のような、Kubernetes クラスターで機能をセットアップまたは有効化するために使用される追加の設定も、お客様が管理する責任を負います。 - イングレスコントローラーと​[イングレスリソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​ - 内部負荷分散 - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - ホストランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。これには、組織内の次のチームの支援が必要です - IT チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 ## [](#anypoint-runtime-fabric-でのアプリケーションデプロイメントの動作)Anypoint Runtime Fabric でのアプリケーションデプロイメントの動作 Anypoint Runtime Fabric にアプリケーションをデプロイするときは、次の動作が起こります。 1. Runtime Manager を使用してアプリケーションデプロイメントをトリガーします。 2. 対象クラスターの Runtime Fabric エージェントがアプリケーションをデプロイする要求を受信します。 3. Runtime Fabric によってアプリケーションが既存の名前空間に割り当てられるか、必要な場合は新しい名前空間が作成されます。 4. Runtime Fabric によってデプロイメント、ConfigMap、シークレット、サービス、イングレスなど、適切な Kubernetes リソースが生成されます。 5. Kubernetes デプロイメントリソースに init コンテナが含まれている場合は、Runtime Fabric リソースキャッシュから連動関係が取得されます。 6. リソースキャッシュに必須の連動関係が含まれていない場合、Runtime Fabric によってコントロールプレーンから取得され、リソースキャッシュに追加されます。 ![Runtime Fabric のアプリケーションデプロイメントワークフロー](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-app-deployment.png) ### [](#anypoint-runtime-fabric-で名前空間を割り当てる)Anypoint Runtime Fabric で名前空間を割り当てる 各アプリケーションはアプリケーションの環境に基づいて Kubernetes 名前空間にデプロイされます。 1. Runtime Fabric によって表示ラベルが ​`rtf.mulesoft.com/envId=`​ の名前空間が検索されます。 2. Runtime Fabric によってその表示ラベルを見つけられなかった場合は、名前が ​``​ の名前空間が検索されます。 3. Runtime Fabric によってその名前空間が見つけられなかった場合、​``​ という名前の新しい名前空間が作成されます。 ![アプリケーション名前空間の割り当てフローチャート](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-namespace-flow.png) ### [](#アプリケーションデプロイメントの監視)アプリケーションデプロイメントの監視 Runtime Fabric エージェントでは、​`rtf.mulesoft.com/id`​ という表示ラベルの付いた Kubernetes デプロイメントを監視します。Kubernetes によってデプロイメントの状態が更新されると、エージェントによってその更新がコントロールプレーンに送信されます。詳細は、​[「ログ」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/limitations-self#logs)​と​[「監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/limitations-self#monitoring)​を参照してください。 ## [](#runtime-fabric-の機能サポートリスト)Runtime Fabric の機能サポートリスト 次の表に、サポートされる機能とサポートされない機能を示します。
機能 状況

Mules および API ゲートウェイのデプロイのサポート

サポート

Kubernetes と Docker

含まれない。

Kubernetes および Docker のインスタンスを Amazon EKS、AKS、または GKE クラスター経由で提供します。

Linux ディストリビューションでのインストール

サポート

ノードの自動スケーリング

AWS、Azure、Google Cloud、または RedHat OpenShift の機能を使用してサポート

外部ログ転送

ログを外部システムに転送するように Log4j をセットアップできます。

内部ロードバランサー

内部ロードバランサー (イングレスコントローラー) を提供する必要があります。

Anypoint Security Edge

サポート対象外

Anypoint Security トークナイゼーション

サポート対象外

オペレーションセンター

含まれない
AWS、Azure、Google Cloud、または RedHat OpenShift で監視とアラートを有効にできます。
## [](#anypoint-runtime-fabric-とスタンドアロン-mule-runtime-ハイブリッドデプロイメント)Anypoint Runtime Fabric とスタンドアロン Mule Runtime (ハイブリッドデプロイメント) Mule アプリケーションのハイブリッドデプロイメントでは、Mule Runtime の 1 つのバージョンをサーバーにインストールし、1 つ以上のアプリケーションをサーバーにデプロイする必要があります。各アプリケーションは、Mule Runtime サーバーとそれに割り当てられたリソースを共有します。証明書やデータベース接続などの他のリソースも、ドメインを使用して共有される場合があります。 Anypoint Runtime Fabric は、異なる方法でリソースをプロビジョニングします。各 Mule アプリケーションや API ゲートウェイは、独自の Mule Runtime およびコンテナ内で実行されます。コンテナで使用できるリソースは、Mule アプリケーションや API プロキシのデプロイ時に指定します。これにより、Mule アプリケーションは他の連動関係を使用せずに複数のノードにわたって水平方向にスケールできます。また、同じノードのリソースに対して異なるアプリケーションが相互に競合しないようになります。 # Anypoint Runtime Fabric の概要 Anypoint Runtime Fabric を使用すると、作成、設定、管理する Kubernetes クラスターに Mule アプリケーションおよび API プロキシをデプロイできます。 公開クラウドで作業をしていて、Kubernetes クラスターの管理についてある程度の専門知識がある場合、Runtime Fabric は以下をサポートします。 - [Amazon Elastics Kubernetes Service (EKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [Google Kubernetes Engine (GKE)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - [Microsoft Azure Kubernetes Service (AKS)](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat OpenShift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - [Alibaba Cloud Container Service for Kubernetes (ACK)](https://www.google.com/url?q=https://www.alibabacloud.com/product/kubernetes&sa=D&source=docs&ust=1695253295782775&usg=AOvVaw1HvpOJ2m_H7JOIZzcIbyym) 公開 K8s ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Amazon EKS Anywhere (EKS-A)](https://aws.amazon.com/eks/eks-anywhere/) - [Rancher Kubernetes エンジン (RKE2)](https://docs.rke2.io/) - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - [VMware Tanzu Kubernetes Grid](https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-with-tanzu-tkg/GUID-2005FFCD-07F4-450E-BAE5-445BE9D629AE.html) Anypoint Runtime Fabric のいくつかの機能を次に示します。 - アプリケーションサーバーごとに個別の Mule Runtime サーバーを実行することによるアプリケーション間の分離。 - 同じ一連のリソースで複数のバージョンの Mule Runtime サーバーを実行する機能。 - 複数のレプリカにわたるアプリケーションのスケーリング。 - 自動化されたアプリケーションフェールオーバー。 - Anypoint Runtime Manager を使用したアプリケーション管理。 Anypoint コントロールプレーン機能、Anypoint CLI、Mule Maven プラグインは、すべてのパートナーで広く利用できます。ランタイムプレーンでは、Helm ベースの Runtime Fabric 管理と機能のみが VMWare Tanzu、Alibaba ACK、および Rancher でサポートされています。各プラットフォームでの機能のサポート状況を下表に示します。
ユースケースのサポート状況 AWS EKS および AWS EKS-A IBM Openshift 製品 AKS & GKE VMWare Tanzu、Alibaba ACK、Rancher

Runtime Manager、アクセス管理、Anypoint Monitoring など、Anypoint コントロールプレーンへのアクセスと使用。

はい

はい

はい

はい

Mule Maven Plugin、Runtime Fabric API、Anypoint CLI などの自動化ツール。

はい

はい

はい

はい

互換性のある K8s バージョンでの Runtime Fabric 機能のサポート。

はい

はい

はい

はい

Runtime Fabric コアソフトウェアおよび Mule Runtime Engine イメージのセキュリティ更新。

はい

はい

はい

はい

Helm​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

はい

はい

はい

Helm​ による CRD を使用したアプリケーションワークロードのカスタマイズ。

はい

はい

はい

はい

アプリケーション監視のための Log4j サポート

はい

はい

はい

はい

rtfctl report​ コマンドによるトラブルシューティング。

はい

はい

はい

はい

Operator​ による Runtime Fabric ソフトウェアのライフサイクル管理。

-

はい

-

-

コントロールプレーンによる Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ を使用したセキュアプロパティのセットアップ。

はい

-

はい

-

rtfctl​ による Runtime Fabric ソフトウェアのライフサイクル管理。

はい

-

はい

-

rtfctl​ によるフルバックアップ/復元。

はい

-

はい

-

リファレンス実装 (テンプレート) - パフォーマンスチューニング、CRD 設定 K8s のベストプラクティス、推奨クラスターサイジング、ネットワーク設定。

はい

-

-

-
## [](#共有責任としての-anypoint-runtime-fabric)共有責任としての Anypoint Runtime Fabric Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が提供して管理する領域と MuleSoft によって提供される領域を理解することが重要です。 Anypoint Runtime Fabric インスタンスにおける MuleSoft とお客様の異なる共有責任を下図に示します。 ![Anypoint Runtime Fabric の共有責任の図](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-shared-responsibility.png) ### [](#mulesoft-によって提供される内容)MuleSoft によって提供される内容 MuleSoft は、Runtime Fabric エージェント、Mule Runtime Engine (Mule)、および Mule アプリケーションのデプロイに使用されるその他の連動関係を提供します。Runtime Fabric エージェントは、デプロイメント、ポッド、レプリカセット、イングレスリソースなどの Kubernetes リソースを生成して更新することで Mule アプリケーションをデプロイして管理します。 #### [](#runtime-fabric-コアサービス)Runtime Fabric コアサービス Anypoint Runtime Fabric とその基盤となるコンポーネントは、EKS、AKS、GKE、または RedHat OpenShift 環境で Kubernetes デプロイメントオブジェクトとして実行されます。これらのオブジェクトは Anypoint Platform を通じて管理します。 Linux ベースのオペレーティングシステムは、Kubernetes クラスターで Runtime Fabric コンポーネントを実行するすべてのノードに必要です。 - Runtime Fabric エージェント Runtime Fabric エージェントはポッドとしてクラスターにデプロイされ、起動時に確立される mTLS アウトバウンド接続を介してコントロールプレーンと通信します。 エージェントはイベント駆動型です。アプリケーションの状態変更により Kubernetes イベントが生成されると、エージェントはアプリケーションの現在の状態を説明するメタデータをコントロールプレーンに送信します。Kubernetes イベントにはアプリケーションポッドの起動、更新、または再起動が含まれます。 エージェントはコントロールプレーンからの受信要求もリスンします。エージェントがコントロールプレーンからメッセージを受信すると、エージェントはメッセージで指定された Kubernetes リソースに変更を加えます。このような変更には、新しいアプリケーションの作成、既存のアプリケーションの更新、アプリケーションの削除などがあります。 - Mule クラスター IP サービス Mule アプリケーションがクラスター内でピアを発見するために使用する API を提供します。 - リソースキャッシュ アプリケーション連動関係のクラスター-ローカルキャッシュを提供します。 これらのサービスは、コア Runtime Fabric インストールの名前空間とレプリカ内で分離されています。これらのサービスはアプリケーションまたはノードの増加に伴って増加しません。 詳細は、​[Runtime Fabric セキュリティアーキテクチャ](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture#security-diagram)​の図を確認してください。 #### [](#アプリケーションサービス)アプリケーションサービス Runtime Fabric によって次のアプリケーションサービスがインストールされるのは、ユーザーが設定した場合のみです。 - 永続性ゲートウェイ: Mule アプリケーション (ユーザーが設定した複製) への永続性 ObjectStore v2 インターフェースを提供します。 - Anypoint Monitoring サイドカー: 監視およびログ記録用 (アプリケーションレプリカごとに 1 つのサイドカーがデプロイされる) ### [](#お客様による管理)お客様による管理 お客様は、Runtime Fabric に使用される Kubernetes クラスターのプロビジョニング、設定、管理の責任を負います。下記のような、Kubernetes クラスターで機能をセットアップまたは有効化するために使用される追加の設定も、お客様が管理する責任を負います。 - イングレスコントローラーと​[イングレスリソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​ - 内部負荷分散 - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - ホストランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。これには、組織内の次のチームの支援が必要です - IT チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 ## [](#anypoint-runtime-fabric-でのアプリケーションデプロイメントの動作)Anypoint Runtime Fabric でのアプリケーションデプロイメントの動作 Anypoint Runtime Fabric にアプリケーションをデプロイするときは、次の動作が起こります。 1. Runtime Manager を使用してアプリケーションデプロイメントをトリガーします。 2. 対象クラスターの Runtime Fabric エージェントがアプリケーションをデプロイする要求を受信します。 3. Runtime Fabric によってアプリケーションが既存の名前空間に割り当てられるか、必要な場合は新しい名前空間が作成されます。 4. Runtime Fabric によってデプロイメント、ConfigMap、シークレット、サービス、イングレスなど、適切な Kubernetes リソースが生成されます。 5. Kubernetes デプロイメントリソースに init コンテナが含まれている場合は、Runtime Fabric リソースキャッシュから連動関係が取得されます。 6. リソースキャッシュに必須の連動関係が含まれていない場合、Runtime Fabric によってコントロールプレーンから取得され、リソースキャッシュに追加されます。 ![Runtime Fabric のアプリケーションデプロイメントワークフロー](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-app-deployment.png) ### [](#anypoint-runtime-fabric-で名前空間を割り当てる)Anypoint Runtime Fabric で名前空間を割り当てる 各アプリケーションはアプリケーションの環境に基づいて Kubernetes 名前空間にデプロイされます。 1. Runtime Fabric によって表示ラベルが ​`rtf.mulesoft.com/envId=`​ の名前空間が検索されます。 2. Runtime Fabric によってその表示ラベルを見つけられなかった場合は、名前が ​``​ の名前空間が検索されます。 3. Runtime Fabric によってその名前空間が見つけられなかった場合、​``​ という名前の新しい名前空間が作成されます。 ![アプリケーション名前空間の割り当てフローチャート](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-namespace-flow.png) ### [](#アプリケーションデプロイメントの監視)アプリケーションデプロイメントの監視 Runtime Fabric エージェントでは、​`rtf.mulesoft.com/id`​ という表示ラベルの付いた Kubernetes デプロイメントを監視します。Kubernetes によってデプロイメントの状態が更新されると、エージェントによってその更新がコントロールプレーンに送信されます。詳細は、​[「ログ」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/limitations-self#logs)​と​[「監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/limitations-self#monitoring)​を参照してください。 ## [](#runtime-fabric-の機能サポートリスト)Runtime Fabric の機能サポートリスト 次の表に、サポートされる機能とサポートされない機能を示します。
機能 状況

Mules および API ゲートウェイのデプロイのサポート

サポート

Kubernetes と Docker

含まれない。

Kubernetes および Docker のインスタンスを Amazon EKS、AKS、または GKE クラスター経由で提供します。

Linux ディストリビューションでのインストール

サポート

ノードの自動スケーリング

AWS、Azure、Google Cloud、または RedHat OpenShift の機能を使用してサポート

外部ログ転送

ログを外部システムに転送するように Log4j をセットアップできます。

内部ロードバランサー

内部ロードバランサー (イングレスコントローラー) を提供する必要があります。

Anypoint Security Edge

サポート対象外

Anypoint Security トークナイゼーション

サポート対象外

オペレーションセンター

含まれない
AWS、Azure、Google Cloud、または RedHat OpenShift で監視とアラートを有効にできます。
## [](#anypoint-runtime-fabric-とスタンドアロン-mule-runtime-ハイブリッドデプロイメント)Anypoint Runtime Fabric とスタンドアロン Mule Runtime (ハイブリッドデプロイメント) Mule アプリケーションのハイブリッドデプロイメントでは、Mule Runtime の 1 つのバージョンをサーバーにインストールし、1 つ以上のアプリケーションをサーバーにデプロイする必要があります。各アプリケーションは、Mule Runtime サーバーとそれに割り当てられたリソースを共有します。証明書やデータベース接続などの他のリソースも、ドメインを使用して共有される場合があります。 Anypoint Runtime Fabric は、異なる方法でリソースをプロビジョニングします。各 Mule アプリケーションや API ゲートウェイは、独自の Mule Runtime およびコンテナ内で実行されます。コンテナで使用できるリソースは、Mule アプリケーションや API プロキシのデプロイ時に指定します。これにより、Mule アプリケーションは他の連動関係を使用せずに複数のノードにわたって水平方向にスケールできます。また、同じノードのリソースに対して異なるアプリケーションが相互に競合しないようになります。 # Anypoint Runtime Fabric ワークフロー このトピックでは、Anypoint Runtime Fabric をインストール、設定、使用するためのワークフローの概要について説明します。Anypoint Runtime Fabric を初めて使用する場合は、このトピックを参照してください。 Runtime Fabric を設定するには、次の手順に従います。 1. インフラストラクチャをプロビジョニングし、設定する 2. Runtime Fabric をインストールし、アクティブ化する 3. [ログ転送を設定する](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) 4. [アラートを設定する](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) 5. [環境に Runtime Fabric を関連付ける](https://docs.mulesoft.com/jp/runtime-fabric/1.13/associate-environments) 6. [インバウンドトラフィックを有効にする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic) 7. [永続性ゲートウェイを設定する](https://docs.mulesoft.com/jp/runtime-fabric/1.13/persistence-gateway#Configure-Persistence-Gateway) ## [](#システムおよびネットワーク要件の確認)システムおよびネットワーク要件の確認 Anypoint Runtime Fabric を使用する前に、環境のリソース要件について、意思決定を行う必要があります。また、環境内でさまざまなポートをどのように設定する必要があるかについても理解する必要があります。 サポートされる設定、必要なリソース、および Runtime Fabric のインストールと実行に必要なポートに関する情報についての詳細は、​[「Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​を参照してください。 ## [](#runtime-manager-での-runtime-fabric-の作成)Runtime Manager での Runtime Fabric の作成 Anypoint Runtime Fabric のインストールを開始する前に、Runtime Manager を使用して Runtime Fabric を作成する必要があります。​[「Runtime Manager を使用した Runtime Fabric の作成」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-create-rtf-arm)​を参照してください。Runtime Fabric を作成したら、次の操作を実行する必要があります。 - インストールスクリプトを含む ZIP ファイルをダウンロードします。ZIP ファイルには、インフラストラクチャプロバイダーに固有のスクリプトが含まれます。 - Runtime Fabric のアクティベーションデータを記録します。 環境に Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これにより、次のことができます。 - Runtime Fabric の名前を指定します。 - インストールスクリプトをダウンロードします。 - インストール中に使用された Runtime Fabric のアクティベーションデータを記録します。 ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール リソース要件を決定し、Runtime Manager で Runtime Fabric を作成したら、リソースをプロビジョニングし、Runtime Fabric をインストールします。次の環境がサポートされています。 - [AWS での Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-aws) - [Azure での Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-azure) - [Runtime Fabric の手動インストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-manual) ## [](#runtime-fabric-の設定)Runtime Fabric の設定 Runtime Fabric をインストールしたら、次のトピックの説明に従って、追加の設定手順を実行します。 - [Anypoint Runtime Fabric のインバウンドトラフィックの有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic) - [Anypoint Runtime Fabric でのログ転送のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) - [Anypoint Runtime Fabric でのアラートのセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) - [Anypoint Runtime Fabric でのオペレーションセンターへのアクセス](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter) - [永続性ゲートウェイの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/persistence-gateway#Configure-Persistence-Gateway) ## [](#アプリケーションをデプロイする)アプリケーションをデプロイする Runtime Fabric をインストールし、設定したら、Mule アプリケーションを環境にデプロイします。 - [「Runtime Fabric でのアプリケーションリソース割り当ての決定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation)​では、アプリケーションで必要なリソースを決定する方法について説明します。 - [「Runtime Fabric への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric)​では、Runtime Fabric にアプリケーションをデプロイする方法について説明します。 このトピックでは、Anypoint Runtime Fabric インストールプロセスの概要と、インストーラーの機能について説明します。 Anypoint Runtime Fabric は、一連の VM で Mule アプリケーションと API ゲートウェイを実行するために作成されたコンテナサービスです。Anypoint Runtime Fabric インストーラーは、必要なユーザー操作を最小限にするように最適化されています。ただし、インストール後に完了する重要な設定手順があります。 # AWS での Runtime Fabric のインストール このトピックでは、AWS アカウントで VM/ベアメタルの Anypoint Runtime Fabric をインストールする方法について説明します。AWS EKS を使用して​[自己管理型 Kubernetes の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ をインストールすることもできます。

Runtime Fabric をインストールする前に、​「VM/ベアメタルの Runtime Fabric の共有責任」​を参照してください。インフラストラクチャがハードウェア、オペレーティングシステム、ネットワークの最小要件を満たしていない場合、VM/ベアメタルの Runtime Fabric は正常に動作しません。

組織の運用チーム、ネットワークチーム、セキュリティチームが関与する必要があります。​「Anypoint Runtime Fabric インストールの前提条件」​を参照してください。
## [](#始める前に)始める前に AWS で VM/ベアメタルの Anypoint Runtime Fabric をインストールするには、次の要件を満たしていることを確認してください。 - [Runtime Manager で Runtime Fabric を作成](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-create-rtf-arm)​している。 - Anypoint Platform ユーザーアカウントに「​**Manage Runtime Fabrics (Runtime Fabric の管理)**​」権限がある。 - マシンで Terraform を実行できる。 - AWS ユーザーに EC2 インスタンス、ディスク、VPC、セキュリティグループを作成するためのアクセス権がある。 詳細は、​ [「IAM ポリシーシミュレーターを使用した IAM ポリシーのテスト」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)​を参照してください。 - AWS アカウントに Anypoint Runtime Fabric を実行するのに必要なインフラストラクチャの十分なクォータがある。これには、追加の VPC、EC2 インスタンス、ディスク、セキュリティグループ、および他の必要なリソースを作成する容量があることも含まれます。 - 仮想マシンをプロビジョニングするのに必要な [AWS キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)​がある。このキーペアは、SSH (Secure Shell) を介した VM へのセキュアなアクセスを有効にするのに必要です。 - AWS 固有の環境変数 (​`AWS_ACCESS_KEY_ID`​、​`AWS_SECRET_ACCESS_KEY`​、​`AWS_SESSION_TOKEN`​、​`AWS_REGION`​、​`AWS_DEFAULT_REGION`​) へのアクセス権がある。これらは、Terraform スクリプトを実行するのに必要です。これらの値がわからない場合は、AWS 管理者にお問い合わせください。 - 環境で実行されているすべてのウイルス対策エージェント (McAfee など) が無効化されている。 ## [](#mule-ライセンスキーの-base64-でのエンコード)Mule ライセンスキーの Base64 でのエンコード Runtime Fabric をインストールするには、Mule ライセンスキーが Base64 でエンコードされている必要があります。組織の Mule Enterprise ライセンスキーファイル (​`license.lic`​) を見つけ、オペレーティングシステムに応じて以下を実行します。 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -b0 license.lic) - Unix では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -w0 license.lic) - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 $BASE64\_ENCODED\_LICENSE=\[convert\]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ## [](#terraform-のインストール)Terraform のインストール MuleSoft には、必要な AWS リソースをプロビジョニングするために実行する Terraform スクリプトが用意されています。プロビジョニングスクリプトは、自分のインストールに合わせて修正できます。たとえば、ディスクの暗号化や EBS ボリュームの暗号化を有効化できます。VM/ベアメタルの Runtime Fabric は、​[「VM/ベアメタルの Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​の最小要件以上が提供されている限りサポートされます。 次のいずれかの方法で Terraform スクリプトを実行できます。 - [Terraform](https://terraform.io/)​ をダウンロードして手動でマシンにインストールする。ターミナルで ​`terraform --version`​ を実行して、インストールされた Terraform のバージョンが ​`0.12.6`​ 以降であることを確認します。 - Docker 内で Terraform を使用する。 ### [](#terraform-スクリプトをダウンロードする)Terraform スクリプトをダウンロードする 1. Anypoint Platform にサインインし、\[Runtime Manager\] に移動します。 2. 左側のナビゲーションペインで、​**Runtime Fabric**​ を選択します。 3. Runtime Fabric の名前をクリックします。その状態は \[Activating (有効化中)\] になっている必要があります。 4. **\[Download files (ファイルをダウンロード)\]**​ をクリックします。 5. ダウンロードが完了したら、​`rtf-install-scripts.zip`​ ファイルを展開します。 ## [](#vmベアメタルの-runtime-fabric-のコンテンツ)VM/ベアメタルの Runtime Fabric のコンテンツ `rtf-install-scripts`​ フォルダー内には、以下が含まれる ​`aws`​ フォルダーがあります。 - `fabric.tf`​: AWS アカウントでインフラストラクチャをプロビジョニングする Terraform スクリプト。 - `network_ingress.tf`​: ネットワークイングレスに使用されるセキュリティグループルールを含む Terraform スクリプト。 - `network_egress.tf`​: ネットワークエグレスに使用されるセキュリティグループルールを含む Terraform スクリプト。 - `installer_env.sh`​: インストール中にリーダーとして機能するコントローラー VM に追加される環境変数のシェルスクリプト。 - `controller_env.sh`​: 他のコントローラー VM に追加される環境変数のシェルスクリプト。 - `worker_env.sh`​: ワーカー VM に追加される環境変数のシェルスクリプト。 - `README.md`​: インストール手順が含まれるマークダウンファイル。 ## [](#fabric-tf-スクリプトの変更)`fabric.tf`​ スクリプトの変更 Terraform を実行する前に、特定の環境が反映されるように ​`fabric.tf`​ スクリプトを変更します。次の表には、必須の環境変数と省略可能な環境変数が記載されています。

環境に応じて、以下の表に記載されていない、​fabric.tf​ 内で指定される環境変数を変更することが必要になる場合もあります。これは、既存の AWS リソース (既存の VPC など) を使用する必要がある場合に多くみられます。

VM/ベアメタルの Runtime Fabric では、インバウンドロードバランサーは共有モードまたは専用モードで実行されます。

  • [Shared Mode (共有モード)]​ では、内部ロードバランサーの CPU コア数とメモリ量を指定できます。共有モードでは、内部ロードバランサーはコントローラーノード全体に分散されます。 [Shared Mode (共有モード)]​ はデフォルトの設定です。

  • [Dedicated Mode (専用モード)]​ では、すべての使用可能なリソースが内部ロードバランサー専用であることが指定されます。このため、CPU コア数およびメモリ量を選択することはできません。専用モードでは、内部ロードバランサーは専用の内部ロードバランサーノードにデプロイされます。

詳細は、​「Runtime Fabric の管理」​を参照してください。
### [](#必須の環境変数)必須の環境変数
変数 説明 例

activation_data

エンコードされた Runtime Fabric アクティベーションデータ。このデータにアクセスするには、Runtime Manager で Runtime Fabric を表示します。

NzdlMzU1YTktMzAxMC00OGE0LWJlMGQtMDdxxxx

key_pair

デプロイ先の AWS リージョンのキーペアの名前。

my-keypair

enable_public_ips

インストーラーで各 VM の公開 IP アドレスを作成するかどうかを指定します。公開 IP を使用すると、ネットワークから直接 VM に ​ssh​ で接続できます。この値が ​false​ (デフォルト) に設定されている場合、各 VM はその VPC で設定されたプライベートネットワークにしかアクセスできません。​false​ を指定する場合、VM へのシェル/SSH アクセス権を取得する方法についてネットワーク管理者と相談していることを確認してください。

true

controllers

プロビジョニングするコントローラー VM の数。

3

workers

プロビジョニングするワーカー VM の数。

3

mule_license

組織の Mule Enterprise ライセンスキー (​license.lic​) を Base64 でエンコードしたコンテンツ。
### [](#省略可能な環境変数)省略可能な環境変数
変数 説明 例

block_aws_metadata_svc

ホストのオペレーティングシステムで AWS メタデータサービスをブロックするブール変数。デフォルト値は ​false​ です。

true

controllers

プロビジョニングするコントローラーマシンの数。デフォルト値は ​3​ です。

5

disable_selinux

ホストのオペレーティングシステムで SELinux を無効化/有効化するブール変数。デフォルト値は ​true​ で、SELinux を無効にします。

ホストオペレーティングシステムが RHEL 8 の場合、インストールに失敗するため、​false​ に設定しないでください。

true

enable_public_ips

公開 IP アドレスを指定する必要があるかどうかを示すブール変数。デフォルト値は ​false​ です。

true

existing_subnet_ids

AWS 内の既存のサブネット ID のリスト。既存のネットワークにインストールする場合に必要になります。インストーラーは、新しいサブネットを作成せずにこれらのサブネットを使用します。

existing_vpc_id

既存の AWS Virtual Private Cloud (VPC) の VPC ID。既存の VPC にインストールする場合に必要になります。インストーラーは、新しい VPC を作成せずにこの VPC を使用します。

http_proxy

アウトバウンド HTTP 要求を転送する HTTP プロキシサーバーのホスト名およびポート。

1.1.1.1:80

installer_url

Runtime Fabric インストーラーパッケージの URL。

kubernetes_api_cidr_blocks

Kubernetes API へのアクセスを可能にする CIDR 範囲。デフォルトは空の配列 ​[]​ です。

monitoring_proxy

SOCKS5 プロキシサーバーがメトリクスとログを Anypoint Monitoring に転送するためのホスト名とポート、および省略可能なユーザー名とパスワード。

user:pass@1.1.1.2:800

mule_license

Mule ライセンスの base64 コンテンツ。

no_proxy

プロキシをバイパスする必要があるホストのカンマ区切りリスト。

1.1.1.1,no-proxy.com

ops_center_cidr_blocks

オペレーションセンター UI へのアクセスを可能にする CIDR 範囲。デフォルトは空の配列 ​[]​ です。

pod_network_cidr_block

カスタムポッド CIDR ブロックのサポートを提供します。

10.244.0.0/16

service_cidr_block

カスタムサービス CIDR ブロックのサポートを提供します。

10.100.0.0/16

service_uid

各 Runtime Fabric サービスを実行するユーザー ID を表す整数。「planet」という名前のユーザーを作成するデフォルトの動作を上書きします。

1000

service_gid

各 Runtime Fabric サービスを実行するときに使用されるグループ ID を表す整数。「planet」という名前のグループを作成するデフォルトの動作を上書きします。

900

workers

プロビジョニングするワーカーマシンの数。デフォルト値は ​3​ です。

5

private_interface

非公開 IP アドレスがネットワークインターフェースから検出されることを許可します。

eth0
## [](#aws-にアクセスする環境の設定)AWS にアクセスする環境の設定 Terraform スクリプトを実行するには、ターミナルで AWS API アクセスを設定する必要があります。​`AWS_ACCESS_KEY_ID`​、​`AWS_SECRET_ACCESS_KEY`​、および他の環境変数 (​`AWS_SESSION_TOKEN`​、​`AWS_REGION`​、​`AWS_DEFAULT_REGION`​ など) の値を定義します。これらは、アカウントの AWS API にアクセスするのに必要です。 これらが正しく設定されていることを確認するには、​`aws-cli`​ ツールを実行できる必要があります (マシンにインストールされている場合)。 ## [](#terraform-スクリプトの実行)Terraform スクリプトの実行 AWS 環境が反映されるように ​`fabric.tf`​ を変更したら、Terraform スクリプトを実行して VM/ベアメタルの Runtime Fabric をインストールします。 内部ロードバランサーは、共有モードの場合はコントローラーノード全体に分散され、専用モードの場合は内部ロードバランサーノードにデプロイされます。 ### [](#terraform-の状態ファイル)Terraform の状態ファイル Terraform は、実行時に状態ファイルを生成して、デプロイメントの詳細を取得します。以下の例では、状態ファイルが ​`tf-data/rtf.tfstate`​ にあります。Runtime Fabric インフラストラクチャを作成するたびに、個別の状態ファイルを作成および維持する必要があります。
状態ファイルは安全な場所に保管してください。このファイルは、このデプロイメントを変更する場合 (ワーカーまたはコントローラー VM の数をスケールする場合など) に必要になります。
### [](#ネイティブ-terraform-を使用して実行する)ネイティブ Terraform を使用して実行する 1. `../rtf-install-scripts/aws/`​ ディレクトリに移動します。このディレクトリから Terraform を実行する必要があります。 2. Terraform を初期化します (これを 1 回のみ実行します)。 terraform init 3. 次のスクリプトをテキストエディターをコピーします。 terraform apply \\ -var activation\_data='' \\ -var key\_pair='' \\ -var enable\_public\_ips='' \\ -var controllers='3' \\ -var workers='3' \\ -var mule\_license='' \\ -state=tf-data/rtf.tfstate 4. 上記の環境変数の表のデータを使用して、これを変更します。 5. ターミナルに上記の必須の AWS 固有の環境変数へのアクセス権があることを確認します。 AWS 認証に関するエラーが発生した場合、変数の確認と Terraform コマンドの実行で同じターミナルウィンドウを使用していることを確認してください。 6. スクリプトを実行します。 Terraform スクリプトは、インフラストラクチャをプロビジョニングして、各 VM でインストールスクリプトを実行します。インストールスクリプトが完了すると、Runtime Manager の Runtime Fabric の状況が ​**\[Active (アクティブ)\]**​ に更新されます。
このステップにより、クラスターを形成するすべてのサーバーに VM/ベアメタルの Runtime Fabric がインストールされます。完了するまでに 15 ～ 25 分以上かかることがあります。
### [](#docker-内での-terraform-の実行)Docker 内での Terraform の実行 1. `../rtf-install-scripts/`​ ディレクトリに移動します。このディレクトリから Terraform を実行する必要があります。​`dir`​ または ​`ls`​ コマンドを実行すると、​`aws`​ ディレクトリが他のディレクトリ (​`azure`​ や ​`manual`​ など) と共にリストされます。 2. Terraform を初期化します (これを 1 回のみ実行する必要があります)。 docker run -v $(pwd):/src -w /src/aws \\ -e AWS\_ACCESS\_KEY\_ID -e AWS\_SECRET\_ACCESS\_KEY -e AWS\_SESSION\_TOKEN \\ hashicorp/terraform:0.12.6 init 3. 以下をテキストエディターをコピーします。 -var activation\_data='' \\ -var key\_pair='' \\ -var enable\_public\_ips='' \\ -var controllers='3' \\ -var workers='3' \\ -var mule\_license='' \\ -state=tf-data/rtf.tfstate 4. 前記の環境変数の表のデータを使用して、この情報を変更します。 5. Terraform スクリプトを実行します。 docker run -it -v $(pwd):/src -w /src/aws \\ -e AWS\_ACCESS\_KEY\_ID -e AWS\_SECRET\_ACCESS\_KEY -e AWS\_SESSION\_TOKEN \\ hashicorp/terraform:0.12.6 apply \\ -var activation\_data='' \\ -var key\_pair='' \\ -var enable\_public\_ips='' \\ -var controllers='3' \\ -var workers='3' \\ -var mule\_license='' \\ -state=tf-data/rtf.tfstate - Terraform スクリプトは、インフラストラクチャをプロビジョニングして、各 VM でインストールスクリプトを実行します。インストールが完了すると、Runtime Manager に Runtime Fabric が ​**\[Active (アクティブ)\]**​ の状況で表示されます。
このステップにより、クラスターを形成するすべてのサーバーに VM/ベアメタルの Runtime Fabric がインストールされます。完了するまでに 15 ～ 25 分以上かかることがあります。
## [](#インストールの進行状況の監視)インストールの進行状況の監視 インストール中に進行状況を参照するには、各 VM の出力ログを確認します。 1. 最初のコントローラー VM へのシェル (SSH セッション) を開きます。 2. 次のコマンドを使用して、​`/var/log/rtf-init.log`​ にある出力ログを確認します。 tail -f /var/log/rtf-init.log
各 VM の同じログを確認して、その進行状況を参照できます。
インストールが正常に完了したら、インストーラーによって ​`/opt/anypoint/runtimefabric/.state/init-complete`​ ファイルが作成されます。 ## [](#オペレーションセンターへのアクセス)オペレーションセンターへのアクセス インストールが正常に完了したら、オペレーションセンターにログインして Runtime Fabric インフラストラクチャの状況を表示します。オペレーションセンターへのアクセスとオペレーションセンターのユーザー名とパスワードの決定については、​[「Anypoint Runtime Fabric でのオペレーションセンターの使用」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter)​を参照してください。
デフォルトでは、Terraform スクリプトでは、オペレーションセンターポートをインターネットに公開しないように AWS セキュリティグループが設定されています。 公開 IP を使用してオペレーションセンターでクラスターを管理するには、​enable_public_ips​ 変数を使用して公開 IP でコントローラーノードをプロビジョニングする必要があります。セキュリティグループを調整して、 0.ポート 32009 での TCP 接続に対して 0.0.0.0 インターネットアクセスを許可する必要があります。
## [](#インストール後の設定)インストール後の設定 Anypoint Runtime Fabric にアプリケーションをデプロイする前に、次の手順を実行する必要があります。 - [Anypoint Runtime Fabric でのビジネスグループと環境の関連付け](https://docs.mulesoft.com/jp/runtime-fabric/1.13/associate-environments) - [Anypoint Runtime Fabric でのインバウンドトラフィックの有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic) - [Anypoint Runtime Fabric でのログ転送の設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) - [Anypoint Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) # Azure での Runtime Fabric のインストール このトピックでは、Azure アカウントで VM/ベアメタルの Anypoint Runtime Fabric をインストールする方法について説明します。Amazon Elastic Kubernetes Service (Amazon EKS)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) を使用して​[自己管理型 Kubernetes の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ をインストールすることもできます。 ## [](#始める前に)始める前に Azure で VM/ベアメタルの Anypoint Runtime Fabric をインストールするには、次の要件を満たしていることを確認してください。 - [Runtime Manager で Runtime Fabric を作成](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-create-rtf-arm)​している。 - [「VM/ベアメタルの Runtime Fabric の共有責任」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/#shared-responsibility-for-on-premises-runtime-fabric)​ドキュメントを確認済みである。インフラストラクチャがハードウェア、オペレーティングシステム、ネットワークの最小要件を満たしていない場合、Runtime Fabric は正常に動作できません。 - 組織の運用チーム、ネットワークチーム、セキュリティチームが参加している。​[「Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​を参照してください。 - Anypoint ユーザーアカウントに「​**Manage Runtime Fabrics (Runtime Fabric の管理)**​」権限がある。 - Azure ユーザーに VM、ディスク、仮想ネットワーク、ネットワークセキュリティグループを作成するためのアクセス権がある。 - Azure アカウントにインフラストラクチャをプロビジョニングする十分なクォータがある。 - VM の公開 IP を使用することが組織で許可されていない場合、既存の仮想ネットワークを使用することが必要になる場合もあります。 既存の仮想ネットワークを参照するように Azure Resource Manager テンプレートを変更します。 - 環境で実行されているすべてのウイルス対策エージェント (McAfee など) が無効化されている。 - Azure ベアメタル上では Runtime Fabric は論理ボリュームマネージャー (LVM) を使用する RHEL のインスタンスのみをサポートします。Azure ベアメタル上の LVM を使用しない RHEL インスタンスはサポートされません。 ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール インストールパッケージの一部として提供される Azure Resource Manager テンプレートは参照のみを目的とするものであり、これを、本番以外または本番の Runtime Fabric インストールでそのまま使用しないでください。このテンプレートを確認し、ニーズを満たすようにカスタマイズする必要があります。VM/ベアメタルの Runtime Fabric は、​[「Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​の最小要件以上が提供されている限りサポートされます。 助言が必要な場合は、MuleSoft 担当者までお問い合わせください。 VM/ベアメタルの Runtime Fabric をインストールする前に、Runtime Manager から Azure Resource Manager テンプレートをダウンロードします。 1. Anypoint Platform から \[Runtime Manager\] に移動します。 2. **\[Runtime Fabric\]**​ を選択します。 3. 作成した Runtime Fabric をクリックします。その状態は \[​`Activating`​ (有効化中)\] になっている必要があります。 4. **\[Download files (ファイルをダウンロード)\]**​ リンクをクリックします。 5. ファイルがダウンロードされたら、​`rtf-install-scripts.zip`​ ファイルを展開します。 `rtf-install-scripts\azure`​ ディレクトリには、以下のインストールファイルが含まれます。 - `ARM-template-dev.template`​: 開発設定に必要なインフラストラクチャを記述するサンプル Azure Resource Manager テンプレート。 - `ARM-template-prod.template`​: 本番設定に必要なインフラストラクチャを記述するサンプル Azure Resource Manager テンプレート。 - `generate-templates.sh`​: Mule Enterprise ライセンスダイジェストと初期化スクリプトを Azure Resource Manager テンプレートに挿入するために使用されるシェルスクリプト。このスクリプトは、Azure にデプロイするときに使用する JSON テンプレートを出力します。 提供されたサンプルテンプレートをコピーして、対象のトポロジーとインフラストラクチャ要件に基づいて変更します。 ## [](#mule-ライセンスキーの-base64-でのエンコード)Mule ライセンスキーの Base64 でのエンコード `generate-templates.sh`​ スクリプトを実行して、Azure Resource Manager テンプレートに Mule Enterprise ライセンスキーを追加します。 これらのテンプレートは、必要なインフラストラクチャをプロビジョニングするために使用されます。
Windows の場合、シェルターミナルエミュレーター (cygwin など) や Unix ベースのコンピューターが必要です。
1. 組織の Mule Enterprise ライセンスキーファイル (​`license.lic`​) を見つけ、必要に応じて Unix 環境に転送します。 2. ターミナル・シェルを開き、​`azure`​ サブディレクトリに移動します。 3. 以下をテキストエディターをコピーします。 RTF\_MULE\_LICENSE='' \\ ./generate-templates.sh 4. ターミナルを使用して、Mule Enterprise ライセンスキーを base64 にエンコードし、コンテンツを ​`RTF_MULE_LICENSE`​ の値としてテキストエディターに貼り付けます。 base64 -w0 license.lic # Linux base64 -b0 license.lic # OSX / MacOS 5. テキストエディターからコマンドをコピーし、​`azure`​ ディレクトリを参照するターミナルで実行します。 6. `azure`​ ディレクトリの ​`ARM-template-dev.json`​ および ​`ARM-template-prod.json`​ ファイルの生成された出力を確認します。 ## [](#arm-テンプレートをデプロイする)ARM テンプレートをデプロイする 生成された ARM テンプレートを実行して、Azure アカウントでインフラストラクチャをプロビジョニングします。次の手順では、Azure Portal を介してテンプレートを実行する方法について説明します。
VM をプロビジョニングするには、PEM ファイルとして非公開キーと公開キーが必要です。これは、SSH (Secure Shell) を介した VM へのセキュアなアクセスを有効にするのに必要です。
1. [Azure Portal](https://portal.azure.com)​ にログインします。 2. **\[リソースの作成\]**​ に移動します。 3. \[​**Marketplace を検索**​\] 検索バーから「​**テンプレートのデプロイ**​」と入力します。 4. ウィンドウの下部で ​**\[作成\]**​ をクリックします。 5. **\[エディターで独自のテンプレートをビルド\]**​ を選択します。 6. エディターの上部のバーで、​**\[ファイルの読み込み\]**​ をクリックし、​`azure`​ ディレクトリから目的の Azure Resource Manager を選択します。JSON ファイルを選択する必要があります。 7. エディターにファイルのコンテンツが表示されたら、​**\[保存\]**​ をクリックします。 8. サブスクリプションの選択内容、リソースグループ、および環境のリージョンを確認します。通常、個別のリソースグループを作成する必要があります。 9. **\[設定\]**​ で、以下を入力します。
Table 1. Azure 設定
変数 説明 例

Public Key

公開キーの文字列が含まれます。これにより、関連付けられている非公開キーを使用して各 VM に SSH で接続できます。

ssh rsa …​

Anypoint Activation Data

エンコードされた Runtime Fabric アクティベーションデータを指定します。このデータにアクセスするには、Runtime Manager で Runtime Fabric を表示します。

NzdlMzU1YTktMzAxMC00OGE0LWJlMGQtMDdxxxx

SSH User Name

各 VM への SSH 接続を確立するときに使用するユーザー名を指定します。

rtf-user

Controller Instance Type

コントローラー VM ごとにプロビジョニングする Azure マシン種別を指定します。デフォルトは 2 コア、8 GB メモリです。

Standard_D2s_v3

Worker Instance Type

ワーカー VM ごとにプロビジョニングする Azure マシン種別を指定します。デフォルトは 2 コア、16 GB メモリです。

Standard_E2s_v3

Virtual Network CIDR

仮想ネットワークに指定するアドレス範囲を指定します。必要に応じて、ネットワークスペシャリストにお問い合わせください。

172.31.0.0/16

Virtual Network Subnet

仮想ネットワーク内で使用するサブネットのアドレス範囲を指定します。必要に応じて、システム管理者にお問い合わせください。

172.31.3.0/28

Installer IP Address

インストーラー VM として機能するコントローラー VM を割り当てる IP アドレスを指定します。これは、指定されたサブネット範囲内の使用可能なアドレスである必要があります。

172.31.3.4

Availability Set Update Domains

選択された Azure リージョンでサポートされる更新ドメインの数を指定します。

3

Availability Set Fault Domains

選択された Azure リージョンでサポートされる障害ドメインの数を指定します。

3

Pod Network CIDR

ポッドネットワークに使用するカスタム CIDR ブロックを指定します。

10.244.0.0/16

Service CIDR

サービスネットワークに使用するカスタム CIDR ブロックを指定します。

10.100.0.0/16

disable_selinux

ホストのオペレーティングシステムで SELinux を無効化/有効化するブール変数。デフォルト値は ​true​ で、SELinux を無効にします。

ホストオペレーティングシステムが RHEL 8 の場合、インストールに失敗するため、​false​ に設定しないでください。

true
VM/ベアメタルの Runtime Fabric では、インバウンドロードバランサーは共有モードまたは専用モードで実行されます。 - **\[Shared Mode (共有モード)\]**​ では、内部ロードバランサーの CPU コア数とメモリ量を指定できます。共有モードでは、内部ロードバランサーはコントローラーノード全体に分散されます。 **\[Shared Mode (共有モード)\]**​ はデフォルトの設定です。 - **\[Dedicated Mode (専用モード)\]**​ では、すべての使用可能なリソースが内部ロードバランサー専用であることが指定されます。このため、CPU コア数およびメモリ量を選択することはできません。専用モードでは、内部ロードバランサーは専用の内部ロードバランサーノードにデプロイされます。 詳細は、​[「Runtime Fabric の管理」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-index)​を参照してください。 10. ページの下部で ​**\[使用条件\]**​ を確認して選択し、​**\[購入\]**​ をクリックします。 クラスターを形成するすべてのサーバーに VM/ベアメタルの Runtime Fabric がインストールされます。このプロセスは完了するまでに時間がかかります。完了すると、Runtime Manager に表示される Runtime Fabric の状況が \[​`Active`​ (アクティブ)\] に代わります。

  • デフォルトでは、ARM テンプレートは各 VM の公開 IP アドレスを定義するように設定されています。必要に応じて、テンプレートを変更して ​publicIPAddresses​ を削除します。

  • 内部ロードバランサーは、共有モードの場合はコントローラーノード全体に分散され、専用モードの場合は内部ロードバランサーノードにデプロイされます。
## [](#インストールの進行状況の監視)インストールの進行状況の監視 Azure プロビジョニングプロセスを実行するには、次の手順に従います。 1. Azure Portal の左側のナビゲーションバーで、​**\[リソース グループ\]**​ をクリックします。 2. Runtime Fabric インフラストラクチャをプロビジョニングするために使用するリソースグループを選択します。 3. **\[デプロイ\]**​ の ​**\[概要\]**​ ペインで、下のリンクをクリックします。このリンクは、​`1 Deploying`​ のように表示されます。 4. デプロイメント名 ​**\[Microsoft.Template\]**​ をクリックします。 インフラストラクチャとその状況のリストが表示されます。​**\[更新\]**​ ボタンをクリックして、ペインと状況を更新します。 インストール中に進行状況を参照するには、各 VM の出力ログを確認します。 1. VM へのシェル (SSH セッション) を開きます。 2. `/var/log/rtf-init.log`​ にある出力ログを確認します。 tail -f /var/log/rtf-init.log 各 VM の同じログを確認して、その進行状況を参照できます。 インストールが正常に完了したら、​`/opt/anypoint/runtimefabric/.state/init-complete`​ ファイルが作成されます。 ## [](#一般的なエラー)一般的なエラー Azure アカウントで設定されているポリシーや定義されているクォータによっては、プロビジョニングプロセスでエラーが発生することがあります。ARM テンプレートは、組織で設定されているポリシーに合わせて変更できます。 必要に応じて、ネットワーク管理者にお問い合わせください。 - **最大コアクォータの超過:**​ Azure サポートにチケットを登録して、デプロイメントリージョンのクォータを増やします。十分なクォータがあると思われる場合、増加しているクォータで正しいリージョンが選択されていることを確認します。または、アカウントに固有になるようにリソースグループ名を変更します。 - **ネットワークポリシー違反:**​ デフォルトでは、Azure リソーステンプレートで定義されるネットワークセキュリティグループは、サブネットレベルおよび各 VM の NIC で関連付けられます。会社のポリシーによっては、テンプレートを調整して関連付けを削除することが必要になる場合もあります。 ## [](#オペレーションセンターへのアクセス)オペレーションセンターへのアクセス インストールが正常に完了したら、オペレーションセンターにログインして Runtime Fabric インフラストラクチャの状況を表示します。オペレーションセンターへのアクセスとオペレーションセンターのユーザー名とパスワードの決定については、​[「Anypoint Runtime Fabric でのオペレーションセンターの使用」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter)​を参照してください。
デフォルトでは、Resource Manager スクリプトでは、オペレーションセンターポートをインターネットに公開しないように Azure ネットワークセキュリティグループが設定されています。公開 IP を使用してオペレーションセンターでクラスターを管理するには、公開 IP でコントローラーノードをプロビジョニングする必要があります。ポート 32009 での TCP 接続に対して 0.0.0.0 インターネットアクセスを許可するようにネットワークセキュリティグループを更新します。
## [](#インストール後の設定)インストール後の設定 Anypoint Runtime Fabric にアプリケーションをデプロイする前に、次の手順を実行する必要があります。 - [Anypoint Runtime Fabric でのビジネスグループと環境の関連付け](https://docs.mulesoft.com/jp/runtime-fabric/1.13/associate-environments) - [Anypoint Runtime Fabric でのインバウンドトラフィックの有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic) - [Anypoint Runtime Fabric でのログ転送の設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) - [Anypoint Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) # CLI を使用した Runtime Fabric でのアプリケーションのデプロイと管理 これらの Anypoint Platform CLI コマンドを使用して、Runtime Fabric でアプリケーションをデプロイおよび管理します。CLI は、対話型シェルと標準 CLI モードの両方をサポートしています。 Runtime Fabric は現在、Anypoint CLI バージョン 3.x のみをサポートしています。 始める前に、​[Anypoint CLI の前提条件と、インストールと認証の手順](https://docs.mulesoft.com/jp/anypoint-cli/3.x/)​を確認しておいてください。

Mule 4.5 以降、MuleSoft は Edge と長期サポート (LTS) という 2 つの新しいリリースチャネルを導入します。新しいリリースチャネルの Mule Runtime バージョン設定スキーマは次のとおりです。

メジャー[数値] .マイナー[数値] . パッチ[数値] : ビルド[数値] チャネル[Edge の場合は e、LTS の場合はなし]

これらの値の例としては、Edge の場合は ​4.5.0:1e​、LTS の場合は ​4.6.0:1​ となります。

詳細は、Edge and LTS Releases for Muleを参照してください。
コマンド 説明

runtime-mgr application delete

アプリケーションを削除する

runtime-mgr application deploy

Exchange アプリケーションを使用して指定された対象にアプリケーションをデプロイし、指定されたランタイムバージョンを実行する

runtime-mgr application describe

アプリケーションの情報を表示する

runtime-mgr application describe-json

未加工の JSON 応答でアプリケーションの情報を表示する

runtime-mgr application download-logs

仕様のアプリケーションのログを指定されたディレクトリにダウンロードする

runtime-mgr application list

組織内のすべてのアプリケーションをリストする

runtime-mgr application modify

デプロイ済みのアプリケーションを修正する

runtime-mgr application start

停止中のアプリケーションを開始する

runtime-mgr application stop

アプリケーションの実行を停止する

runtime-mgr application tail-logs

仕様のアプリケーションのログを追跡する
## [](#runtime-mgr-application-delete)runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-deploy)runtime-mgr application deploy \> runtime-mgr application deploy \[options\] ``​ で指定されたアプリケーションを、次のオプションを使用して指定されたデプロイメント対象にデプロイします。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションのアーティファクト ID。

mule-test-plugin

deploymentTargetID

デプロイメント対象の ID。
この ID は、Runtime Manager から直接取得できます。

app.runetime

name

デプロイするアプリケーションの名前。

testCloudhub2app

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1​
このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト:.disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID

org.mule.test

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example:/status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate
## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs)runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 \[\[runtime-mgr-application-delete\]\] == runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start-2)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop-2)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs-2)runtime-mgr application tail-logs \> runtime-mgr application tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-rtf-list)runtime-mgr rtf list \> runtime-mgr rtf list \[options\] このコマンドは、使用可能な Runtime Fabric インスタンスをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 コマンドラインを使用した Runtime Fabric インスタンスの管理については、​[「サポートされている rtfctl コマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands)​を参照してください。 # CLI を使用した Runtime Fabric でのアプリケーションの管理 これらの Anypoint Platform CLI コマンドを使用して、Runtime Fabric でアプリケーションをデプロイおよび管理します。CLI は、対話型シェルと標準 CLI モードの両方をサポートしています。 始める前に、​[Anypoint CLI の前提条件と、インストールと認証の手順](https://docs.mulesoft.com/jp/anypoint-cli/3.x/)​を確認しておいてください。
コマンド 説明

runtime-mgr application delete

アプリケーションを削除する

runtime-mgr application deploy

Exchange アプリケーションを使用して指定された対象にアプリケーションをデプロイし、指定されたランタイムバージョンを実行する

runtime-mgr application describe

アプリケーションの情報を表示する

runtime-mgr application describe-json

未加工の JSON 応答でアプリケーションの情報を表示する

runtime-mgr application download-logs

仕様のアプリケーションのログを指定されたディレクトリにダウンロードする

runtime-mgr application list

組織内のすべてのアプリケーションをリストする

runtime-mgr application modify

デプロイ済みのアプリケーションを修正する

runtime-mgr application start

停止中のアプリケーションを開始する

runtime-mgr application stop

アプリケーションの実行を停止する

runtime-mgr application tail-logs

仕様のアプリケーションのログを追跡する
## [](#runtime-mgr-application-delete)runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-deploy)runtime-mgr application deploy \> runtime-mgr application deploy \[options\] ``​ で指定されたアプリケーションを、次のオプションを使用して指定されたデプロイメント対象にデプロイします。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションのアーティファクト ID。

mule-test-plugin

deploymentTargetID

デプロイメント対象の ID。
この ID は、Runtime Manager から直接取得できます。

app.runetime

name

デプロイするアプリケーションの名前。

testCloudhub2app

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1​
このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト:.disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID

org.mule.test

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example:/status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate
## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs)runtime-mgr application tail-logs \> runtime-mgr:application:tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 \[\[runtime-mgr-application-delete\]\] == runtime-mgr application delete \> runtime-mgr application delete \[options\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe)runtime-mgr application describe \> runtime-mgr application describe \[options\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe-json)runtime-mgr application describe-json \> runtime-mgr application describe-json \[options\] ``​ で指定されたアプリケーションから未加工の JSON 応答を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-download-logs)runtime-mgr application download-logs \> runtime-mgr application download-logs \[options\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr application list \> runtime-mgr application list \[options\] 組織内のすべてのアプリケーションをリストします。 このコマンドでは、デフォルトのオプション ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr application modify \> runtime-mgr application modify \[options\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​ オプション以外に次のオプションも使用できます。
値 説明 例

ArtifactId

Exchange から取得したアプリケーションの ID。

mule-maven-plugin

assetVersion

使用する Exchange アプリケーションのバージョン。
デフォルト: 最新のアプリケーションバージョン

2.0.4

clustered

クラスタリングされたノードを有効にします。少なくとも 2 つのレプリカが必要です。
デフォルト: disabled
サポートされている値: true​、​false

false

disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled
サポートされている値: true​、​false

true

forwardSslSession

SSL セッション転送を有効にします。
デフォルト: disabled
値: true​、​false

false

groupId

デプロイするアセットの ID。
デフォルト: 選択済み組織 ID。

org.mule.testgroup

lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled
サポートされている値: true​、​false

true

pathRewrite

アプリケーションの HTTP リスナーで要求されるベースパスを提供します。
形式: /​ で始まる必要があります

/http://localhost:3000​.

property

プロパティを設定します。
形式: name:value

testproperty:true

propertiesFile

すべてのプロパティを選択済みファイルの値に置き換えます。
形式: 1 行以上の ​name:value​ 形式

/Users/mule/Documents/properties.txt

publicEndpoints

公開インターネット経由で到達するエンドポイントを提供します。
形式: カンマ区切りでスペースなし

my-superapp-example: /status?limit=10

replicas

レプリカの数。​0​ より大きい必要があります。
デフォルト: 1

2

replicaSize

vCore のレプリカのサイズ。
デフォルト: 0.1

0.5

runtimeVersion

デプロイメント対象のランタイムバージョン。

1.0.1

scopeLoggingConfig

スコープログ記録を定義します。
形式: scopeName: logLevel​、カンマ区切りでスペースなし

testscope1:WARN,testscope2:DEBUG

scopeLoggingConfigFile

ファイルをアップロードしてスコープログ記録を定義します。
形式: 1 行に 1 タプル、スタイル: {scope: scopeName, logLevel: logLevelType}​ を ​{} ​()​ または ​[]​ で囲む

/Users/mule/Documents/cert.txt

updateStrategy

使用される戦略を更新します。
デフォルト: rolling

recreate​
## [](#runtime-mgr-application-start-2)runtime-mgr application start \> runtime-mgr application start \[options\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-stop-2)runtime-mgr application stop \> runtime-mgr application stop \[options\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-application-tail-logs-2)runtime-mgr application tail-logs \> runtime-mgr application tail-logs \[options\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 ## [](#runtime-mgr-rtf-list)runtime-mgr rtf list \> runtime-mgr rtf list \[options\] このコマンドは、使用可能な Runtime Fabric インスタンスをリストします。 このコマンドはデフォルトのオプション ​`--help`​、​`-f`​/​`--fields`​、​`-o`​/​`--output`​ のみを受け入れます。 コマンドラインを使用した Runtime Fabric インスタンスの管理については、​[「サポートされている rtfctl コマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#supported-commands)​を参照してください。 # firewalld を使用する場合の転送の有効化 `firewalld`​ は、iptables を補うファイアウォール管理ツールであり、永続的なネットワークトラフィックルールを定義できます。 Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、docker0 デバイスで転送を有効化する必要があります。 また、10.0.0.0/8 サブネットとの間でやり取りしているすべてのパケットを転送する必要もあります。 ## [](#firewalld-を使用しているかどうかを確認する方法)firewalld を使用しているかどうかを確認する方法 システムで firewalld を使用しているかどうかを確認するには、次のコマンドを実行します。 systemctl status firewalld.service firewalld がインストールされている場合は以下の内容が返されます。 $ sudo systemctl status firewalld.service \* firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) firewalld がインストールされていない場合は、エラーメッセージが返されます。 ## [](#転送の有効化)転送の有効化 docker0 デバイスで転送を有効化するには、次のコマンドを実行します。 firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" 10.0.0.0/8 サブネットで転送を有効化するには、次のコマンドを実行します。 firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ## [](#転送の確認)転送の確認 転送ルールが設定されていることを確認するには、次のコマンドを実行します。 firewall-cmd --permanent --direct --get-all-rules 出力は次の例のようになります。 ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet'
これらのルールはノードレベルです。つまり、firewalld がアクティブな場合に Runtime Fabric が正しく機能するようにするには、すべてのノード (コントローラーノードとワーカーノードの両方) でルールを実行して確認する必要があります。
# firewalld を使用する場合の転送の有効化 `firewalld`​ は、iptables を補うファイアウォール管理ツールであり、永続的なネットワークトラフィックルールを定義できます。 Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、docker0 デバイスで転送を有効化する必要があります。 また、10.0.0.0/8 サブネットとの間でやり取りしているすべてのパケットを転送する必要もあります。 ## [](#firewalld-を使用しているかどうかを確認する方法)firewalld を使用しているかどうかを確認する方法 システムで firewalld を使用しているかどうかを確認するには、次のコマンドを実行します。 ```copy systemctl status firewalld.service ``` firewalld がインストールされている場合は以下の内容が返されます。 ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` firewalld がインストールされていない場合は、エラーメッセージが返されます。 ## [](#転送の有効化)転送の有効化 docker0 デバイスで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` 10.0.0.0/8 サブネットで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## [](#転送の確認)転送の確認 転送ルールが設定されていることを確認するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --get-all-rules ``` 出力は次の例のようになります。 ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet'
これらのルールはノードレベルです。つまり、firewalld がアクティブな場合に Runtime Fabric が正しく機能するようにするには、すべてのノード (コントローラーノードとワーカーノードの両方) でルールを実行して確認する必要があります。
# firewalld を使用する場合の転送の有効化 `firewalld`​ は、iptables を補うファイアウォール管理ツールであり、永続的なネットワークトラフィックルールを定義できます。 Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、docker0 デバイスで転送を有効化する必要があります。 また、10.0.0.0/8 サブネットとの間でやり取りしているすべてのパケットを転送する必要もあります。 ## [](#firewalld-を使用しているかどうかを確認する方法)firewalld を使用しているかどうかを確認する方法 システムで firewalld を使用しているかどうかを確認するには、次のコマンドを実行します。 ```copy systemctl status firewalld.service ``` firewalld がインストールされている場合は以下の内容が返されます。 ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` firewalld がインストールされていない場合は、エラーメッセージが返されます。 ## [](#転送の有効化)転送の有効化 docker0 デバイスで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` 10.0.0.0/8 サブネットで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## [](#転送の確認)転送の確認 転送ルールが設定されていることを確認するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --get-all-rules ``` 出力は次の例のようになります。 ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet'
これらのルールはノードレベルです。つまり、firewalld がアクティブな場合に Runtime Fabric が正しく機能するようにするには、すべてのノード (コントローラーノードとワーカーノードの両方) でルールを実行して確認する必要があります。
# firewalld を使用する場合の転送の有効化 `firewalld`​ は、iptables を補うファイアウォール管理ツールであり、永続的なネットワークトラフィックルールを定義できます。 Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、docker0 デバイスで転送を有効化する必要があります。 また、10.0.0.0/8 サブネットとの間でやり取りしているすべてのパケットを転送する必要もあります。 ## [](#firewalld-を使用しているかどうかを確認する方法)firewalld を使用しているかどうかを確認する方法 システムで firewalld を使用しているかどうかを確認するには、次のコマンドを実行します。 ```copy systemctl status firewalld.service ``` firewalld がインストールされている場合は以下の内容が返されます。 ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` firewalld がインストールされていない場合は、エラーメッセージが返されます。 ## [](#転送の有効化)転送の有効化 docker0 デバイスで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` 10.0.0.0/8 サブネットで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## [](#転送の確認)転送の確認 転送ルールが設定されていることを確認するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --get-all-rules ``` 出力は次の例のようになります。 ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet'
これらのルールはノードレベルです。つまり、firewalld がアクティブな場合に Runtime Fabric が正しく機能するようにするには、すべてのノード (コントローラーノードとワーカーノードの両方) でルールを実行して確認する必要があります。
# firewalld を使用する場合の転送の有効化 `firewalld`​ は、iptables を補うファイアウォール管理ツールであり、永続的なネットワークトラフィックルールを定義できます。 Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、docker0 デバイスで転送を有効化する必要があります。 また、10.0.0.0/8 サブネットとの間でやり取りしているすべてのパケットを転送する必要もあります。 ## [](#firewalld-を使用しているかどうかを確認する方法)firewalld を使用しているかどうかを確認する方法 システムで firewalld を使用しているかどうかを確認するには、次のコマンドを実行します。 ```copy systemctl status firewalld.service ``` firewalld がインストールされている場合は以下の内容が返されます。 ```copy $ sudo systemctl status firewalld.service * firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) ``` firewalld がインストールされていない場合は、エラーメッセージが返されます。 ## [](#転送の有効化)転送の有効化 docker0 デバイスで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` 10.0.0.0/8 サブネットで転送を有効化するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment "docker subnet" ``` ## [](#転送の確認)転送の確認 転送ルールが設定されていることを確認するには、次のコマンドを実行します。 ```copy firewall-cmd --permanent --direct --get-all-rules ``` 出力は次の例のようになります。 ipv4 filter FORWARD 1 -o docker0 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter FORWARD 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -s 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet' ipv4 filter INPUT 1 -d 10.0.0.0/8 -j ACCEPT -m comment --comment 'docker subnet'
これらのルールはノードレベルです。つまり、firewalld がアクティブな場合に Runtime Fabric が正しく機能するようにするには、すべてのノード (コントローラーノードとワーカーノードの両方) でルールを実行して確認する必要があります。
# Helm を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境でアップグレードできます。 `rtfctl`​ コマンドラインツールを使用してインストールした場合は、Helm を使用したアップグレードは行えません。 Helm を使用して Runtime Fabric をアップグレードすると、Runtime Manager はアップグレードの実行に必要な Helm コマンドを提供します。

Runtime Manager から提供されるアップグレードコマンドでは、Runtime Fabric をインストールしたときに Helm に追加したのと同じパラメーターと値を使用します。これらの値 (プロキシ値など) をインストール後に変更してあり、アップグレード後も同じ値を使用したい場合は、アップグレードを実行する前に、値をアップグレードコマンドに追加する必要があります。
Helm を使用して Runtime Fabric をアップグレードする手順は次のとおりです。 1. Runtime Manager の \[Runtime Fabrics\] タブで自分の Runtime Fabric を選択して、Runtime Fabric に移動します。 2. **\[Upgrade (アップグレード…)\]**​ をクリックします。 3. Runtime Manager から提供されたコマンドを実行し、既存のインストールに基づいた ​`values.yml`​ ファイルを生成します。 4. 画面の指示に従って ​`values.yml`​ ファイルを生成してダウンロードします。 5. 必要に応じて省略可能なパラメーターを ​`values.yml`​ ファイルに追加します。 省略可能なパラメーターと必須パラメーターのリストは、インストールドキュメントの​[「​`values.yml`​ リファレンス」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-helm#values-yml-reference)​を参照してください。 6. Helm リポジトリを更新して、Runtime Fabric エージェントチャートが最新であることを確認します。 ```copy helm repo update ``` 7. アップグレードを完了するには、次のコマンドを実行します。 ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` # Helm を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境でアップグレードできます。 `rtfctl`​ コマンドラインツールを使用してインストールした場合は、Helm を使用したアップグレードは行えません。 Helm を使用して Runtime Fabric をアップグレードすると、Runtime Manager はアップグレードの実行に必要な Helm コマンドを提供します。

Runtime Manager から提供されるアップグレードコマンドでは、Runtime Fabric をインストールしたときに Helm に追加したのと同じパラメーターと値を使用します。これらの値 (プロキシ値など) をインストール後に変更してあり、アップグレード後も同じ値を使用したい場合は、アップグレードを実行する前に、値をアップグレードコマンドに追加する必要があります。
Helm を使用して Runtime Fabric をアップグレードする手順は次のとおりです。 1. Runtime Manager の \[Runtime Fabrics\] タブで自分の Runtime Fabric を選択して、Runtime Fabric に移動します。 2. **\[Upgrade (アップグレード…)\]**​ をクリックします。 3. Runtime Manager から提供されたコマンドを実行し、既存のインストールに基づいた ​`values.yml`​ ファイルを生成します。 4. 画面の指示に従って ​`values.yml`​ ファイルを生成してダウンロードします。 5. 必要に応じて省略可能なパラメーターを ​`values.yml`​ ファイルに追加します。 省略可能なパラメーターと必須パラメーターのリストは、インストールドキュメントの​[「​`values.yml`​ リファレンス」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-helm#values-yml-reference)​を参照してください。 6. Helm リポジトリを更新して、Runtime Fabric エージェントチャートが最新であることを確認します。 ```copy helm repo update ``` 7. アップグレードを完了するには、次のコマンドを実行します。 ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` # Helm を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境でアップグレードできます。 `rtfctl`​ コマンドラインツールを使用してインストールした場合は、Helm を使用したアップグレードは行えません。 Helm を使用して Runtime Fabric をアップグレードすると、Runtime Manager はアップグレードの実行に必要な Helm コマンドを提供します。

Runtime Manager から提供されるアップグレードコマンドでは、Runtime Fabric をインストールしたときに Helm に追加したのと同じパラメーターと値を使用します。これらの値 (プロキシ値など) をインストール後に変更してあり、アップグレード後も同じ値を使用したい場合は、アップグレードを実行する前に、値をアップグレードコマンドに追加する必要があります。
Helm を使用して Runtime Fabric をアップグレードする手順は次のとおりです。 1. Runtime Manager の \[Runtime Fabrics\] タブで自分の Runtime Fabric を選択して、Runtime Fabric に移動します。 2. **\[Upgrade (アップグレード…)\]**​ をクリックします。 3. Runtime Manager から提供されたコマンドを実行し、既存のインストールに基づいた ​`values.yml`​ ファイルを生成します。 4. 画面の指示に従って ​`values.yml`​ ファイルを生成してダウンロードします。 5. 必要に応じて省略可能なパラメーターを ​`values.yml`​ ファイルに追加します。 省略可能なパラメーターと必須パラメーターのリストは、インストールドキュメントの​[「​`values.yml`​ リファレンス」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-helm#values-yml-reference)​を参照してください。 6. Helm リポジトリを更新して、Runtime Fabric エージェントチャートが最新であることを確認します。 ```copy helm repo update ``` 7. アップグレードを完了するには、次のコマンドを実行します。 ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` # Helm を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境でアップグレードできます。 `rtfctl`​ コマンドラインツールを使用してインストールした場合は、Helm を使用したアップグレードは行えません。 Helm を使用して Runtime Fabric をアップグレードすると、Runtime Manager はアップグレードの実行に必要な Helm コマンドを提供します。

Runtime Manager から提供されるアップグレードコマンドでは、Runtime Fabric をインストールしたときに Helm に追加したのと同じパラメーターと値を使用します。これらの値 (プロキシ値など) をインストール後に変更してあり、アップグレード後も同じ値を使用したい場合は、アップグレードを実行する前に、値をアップグレードコマンドに追加する必要があります。
Helm を使用して Runtime Fabric をアップグレードする手順は次のとおりです。 1. Runtime Manager の \[Runtime Fabrics\] タブで自分の Runtime Fabric を選択して、Runtime Fabric に移動します。 2. **\[Upgrade (アップグレード…)\]**​ をクリックします。 3. Runtime Manager から提供されたコマンドを実行し、既存のインストールに基づいた ​`values.yml`​ ファイルを生成します。 4. 画面の指示に従って ​`values.yml`​ ファイルを生成してダウンロードします。 5. 必要に応じて省略可能なパラメーターを ​`values.yml`​ ファイルに追加します。 省略可能なパラメーターと必須パラメーターのリストは、インストールドキュメントの​[「​`values.yml`​ リファレンス」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm#values-yml-reference)​を参照してください。 6. Helm リポジトリを更新して、Runtime Fabric エージェントチャートが最新であることを確認します。 ```copy helm repo update ``` 7. アップグレードを完了するには、次のコマンドを実行します。 ```copy helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` # Helm を使用した Runtime Fabric のインストール Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE)、または VMware Tanzu Kubernetes Grid 環境に Anypoint Runtime Fabric をインストールできます。 ## [](#helm-を使用して-runtime-fabric-をインストールする手順)Helm を使用して Runtime Fabric をインストールする手順 Helm を使用して Runtime Fabric をインストールする手順は次のとおりです。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の ​`rtf`​ 名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、追加の承認済み名前空間を設定します。 5. Runtime Fabric Helm リポジトリを追加します。 6. `values.yml`​ ファイルをダウンロードして Runtime Fabric をインストールします。 7. インストール手順を完了します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric の概要」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/)​で説明されているアーキテクチャと要件を確認した。 - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed-network-configuration)​。 - Kubernetes 環境を次のようにインストールして設定してある。 - ACK、AKS、EKS、EKS-A、GKE、RKE、または VMware Tanzu Kubernetes 環境を実行している。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョンを実行している。 - イングレスコントローラーを実行して外部要求をアプリケーションに送信している。 - Helm 3 以降をインストールして、特権ユーザー権限を持っている。

  • Helm を使用して Runtime Fabric のインストールを管理する場合は、後で ​rtfctl​ コマンドラインユーティリティを使用して Mule ライセンスキーとプロキシを管理できます。ただし、​更新ドキュメント​に説明されているように、インストール後の変更をすべて追跡する必要があります。
### [](#helm-のサポート)Helm のサポート Runtime Fabric は、Helm バージョン 1.13 以降を使用したインストール、アップグレード、ロールバックをサポートしています。 ## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Helm を使用して Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. \[Helm\] をクリックします。

Helm を使用したインストールプロセスの残りの手順では、プレースホルダー値を参照します。実際の値は、Runtime Fabric インスタンスを作成するときに Runtime Manager から取得できます。
## [](#runtime-fabric-用の-rtf-名前空間を作成する)Runtime Fabric 用の rtf 名前空間を作成する Kubernetes のクラスターで、​`rtf`​ という名前の名前空間を作成する必要があります。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy kubectl create ns rtf ``` 名前空間としての ​`rtf`​ の使用は、単一クラスターまたは単一インスタンスの場合のみ適用されます。 ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#runtime-fabric-helm-リポジトリを追加する)Runtime Fabric Helm リポジトリを追加する 作成した名前空間に Runtime Fabric Helm リポジトリを追加する必要があります。Runtime Fabric Helm リポジトリには、Runtime Fabric をインストールするのに必要なチャートが入っています。 Helm リポジトリを追加するには、次のコマンドを実行します。 ```copy helm repo add --username --password ```

すでに Helm リポジトリが追加されていて、Runtime Fabric がリポジトリの追加をスキップしたという結果が返された場合は、新しい Runtime Fabric バージョンをインストール (またはそのバージョンにアップグレード) する前に ​helm repo update​ を実行してください。
## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.5/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy kubectl apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 認証済み名前空間モードでクラスター化アプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 1. `rtf`​ 名前空間で、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy kubectl -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Fabric をインストールするには、Runtime Manager から供給された ​`values.yml`​ ファイルを使用してください。 1. `values.yml`​ ファイルをダウンロードします。 2. 必要に応じて省略可能なパラメーターを追加します。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 3. 次のコマンドを実行します。 ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## [](#values-yml-reference)values.yml リファレンス 次に ​`values.yml`​ ファイルの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ```
EU コントロールプレーンを使用して Runtime Fabric BYOK を設定する場合は、​「ホスト名設定」​の変更点を確認して、正しく設定してください。特に、​rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io​ プロパティに注意してください。
### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターが作成されて ​`values.yml`​ に追加されます。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター Runtime Fabric をインストールする前に、必要に応じて次の省略可能なパラメーターを ​`values.yml`​ で設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false

crds.install

カードのインストールの有効化

crds.install: true​ (最初の Runtime Fabric のインストール)、false (以降のインストール)

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods

nodeWatcherEnabled

クラスターのノードウォッチャーの有効化または無効化

nodeWatcherEnabled:true​、デフォルト値は ​true

deploymentRateLimitPerSecond

1 秒ごとのデプロイメントレート制限の設定

deploymentRateLimitPerSecond: 1​、デフォルト値は ​1
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 Helm を使用して Runtime Fabric の以前のバージョンにロールバックするには、 [Helm rollback](https://helm.sh/docs/helm/helm_rollback/)​ のドキュメントにあるコマンドの説明を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric) # Helm を使用した Runtime Fabric のインストール Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE)、または VMware Tanzu Kubernetes Grid 環境に Anypoint Runtime Fabric をインストールできます。 ## [](#helm-を使用して-runtime-fabric-をインストールする手順)Helm を使用して Runtime Fabric をインストールする手順 Helm を使用して Runtime Fabric をインストールする手順は次のとおりです。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の ​`rtf`​ 名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、追加の承認済み名前空間を設定します。 5. Runtime Fabric Helm リポジトリを追加します。 6. `values.yml`​ ファイルをダウンロードして Runtime Fabric をインストールします。 7. インストール手順を完了します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric の概要」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/)​で説明されているアーキテクチャと要件を確認した。 - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed-network-configuration)​。 - Kubernetes 環境を次のようにインストールして設定してある。 - ACK、AKS、EKS、EKS-A、GKE、RKE、または VMware Tanzu Kubernetes 環境を実行している。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョンを実行している。 - イングレスコントローラーを実行して外部要求をアプリケーションに送信している。 - Helm 3 以降をインストールして、特権ユーザー権限を持っている。

  • Helm を使用して Runtime Fabric のインストールを管理する場合は、後で ​rtfctl​ コマンドラインユーティリティを使用して Mule ライセンスキーとプロキシを管理できます。ただし、​更新ドキュメント​に説明されているように、インストール後の変更をすべて追跡する必要があります。
### [](#helm-のサポート)Helm のサポート Runtime Fabric は、Helm バージョン 1.13 以降を使用したインストール、アップグレード、ロールバックをサポートしています。 ## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Helm を使用して Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. \[Helm\] をクリックします。

Helm を使用したインストールプロセスの残りの手順では、プレースホルダー値を参照します。実際の値は、Runtime Fabric インスタンスを作成するときに Runtime Manager から取得できます。
## [](#runtime-fabric-用の-rtf-名前空間を作成する)Runtime Fabric 用の rtf 名前空間を作成する Kubernetes のクラスターで、​`rtf`​ という名前の名前空間を作成する必要があります。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy kubectl create ns rtf ``` 名前空間としての ​`rtf`​ の使用は、単一クラスターまたは単一インスタンスの場合のみ適用されます。 ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#runtime-fabric-helm-リポジトリを追加する)Runtime Fabric Helm リポジトリを追加する 作成した名前空間に Runtime Fabric Helm リポジトリを追加する必要があります。Runtime Fabric Helm リポジトリには、Runtime Fabric をインストールするのに必要なチャートが入っています。 Helm リポジトリを追加するには、次のコマンドを実行します。 ```copy helm repo add --username --password ```

すでに Helm リポジトリが追加されていて、Runtime Fabric がリポジトリの追加をスキップしたという結果が返された場合は、新しい Runtime Fabric バージョンをインストール (またはそのバージョンにアップグレード) する前に ​helm repo update​ を実行してください。
## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.6/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy kubectl apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 認証済み名前空間モードでクラスター化アプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 1. `rtf`​ 名前空間で、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy kubectl -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Fabric をインストールするには、Runtime Manager から供給された ​`values.yml`​ ファイルを使用してください。 1. `values.yml`​ ファイルをダウンロードします。 2. 必要に応じて省略可能なパラメーターを追加します。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 3. 次のコマンドを実行します。 ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## [](#values-yml-reference)values.yml リファレンス 次に ​`values.yml`​ ファイルの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ```
EU コントロールプレーンを使用して Runtime Fabric BYOK を設定する場合は、​「ホスト名設定」​の変更点を確認して、正しく設定してください。特に、​rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io​ プロパティに注意してください。
### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターが作成されて ​`values.yml`​ に追加されます。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター Runtime Fabric をインストールする前に、必要に応じて次の省略可能なパラメーターを ​`values.yml`​ で設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false

crds.install

カードのインストールの有効化

crds.install: true​ (最初の Runtime Fabric のインストール)、false (以降のインストール)

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods

nodeWatcherEnabled

クラスターのノードウォッチャーの有効化または無効化

nodeWatcherEnabled:true​、デフォルト値は ​true

deploymentRateLimitPerSecond

1 秒ごとのデプロイメントレート制限の設定

deploymentRateLimitPerSecond: 1​、デフォルト値は ​1
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 Helm を使用して Runtime Fabric の以前のバージョンにロールバックするには、 [Helm rollback](https://helm.sh/docs/helm/helm_rollback/)​ のドキュメントにあるコマンドの説明を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric) # Helm を使用した Runtime Fabric のインストール Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE)、または VMware Tanzu Kubernetes Grid 環境に Anypoint Runtime Fabric をインストールできます。 ## [](#helm-を使用して-runtime-fabric-をインストールする手順)Helm を使用して Runtime Fabric をインストールする手順 Helm を使用して Runtime Fabric をインストールする手順は次のとおりです。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の ​`rtf`​ 名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、追加の承認済み名前空間を設定します。 5. Runtime Fabric Helm リポジトリを追加します。 6. `values.yml`​ ファイルをダウンロードして Runtime Fabric をインストールします。 7. インストール手順を完了します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric の概要」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/)​で説明されているアーキテクチャと要件を確認した。 - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed-network-configuration)​。 - Kubernetes 環境を次のようにインストールして設定してある。 - ACK、AKS、EKS、EKS-A、GKE、RKE、または VMware Tanzu Kubernetes 環境を実行している。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョンを実行している。 - イングレスコントローラーを実行して外部要求をアプリケーションに送信している。 - Helm 3 以降をインストールして、特権ユーザー権限を持っている。

  • Helm を使用して Runtime Fabric のインストールを管理する場合は、後で ​rtfctl​ コマンドラインユーティリティを使用して Mule ライセンスキーとプロキシを管理できます。ただし、​更新ドキュメント​に説明されているように、インストール後の変更をすべて追跡する必要があります。
### [](#helm-のサポート)Helm のサポート Runtime Fabric は、Helm バージョン 1.13 以降を使用したインストール、アップグレード、ロールバックをサポートしています。 ## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Helm を使用して Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. \[Helm\] をクリックします。

Helm を使用したインストールプロセスの残りの手順では、プレースホルダー値を参照します。実際の値は、Runtime Fabric インスタンスを作成するときに Runtime Manager から取得できます。
## [](#runtime-fabric-用の-rtf-名前空間を作成する)Runtime Fabric 用の rtf 名前空間を作成する Kubernetes のクラスターで、​`rtf`​ という名前の名前空間を作成する必要があります。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy kubectl create ns rtf ``` 名前空間としての ​`rtf`​ の使用は、単一クラスターまたは単一インスタンスの場合のみ適用されます。 ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#runtime-fabric-helm-リポジトリを追加する)Runtime Fabric Helm リポジトリを追加する 作成した名前空間に Runtime Fabric Helm リポジトリを追加する必要があります。Runtime Fabric Helm リポジトリには、Runtime Fabric をインストールするのに必要なチャートが入っています。 Helm リポジトリを追加するには、次のコマンドを実行します。 ```copy helm repo add --username --password ```

すでに Helm リポジトリが追加されていて、Runtime Fabric がリポジトリの追加をスキップしたという結果が返された場合は、新しい Runtime Fabric バージョンをインストール (またはそのバージョンにアップグレード) する前に ​helm repo update​ を実行してください。
## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.7/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy kubectl apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 認証済み名前空間モードでクラスタリングアプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 1. `rtf`​ 名前空間で、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy kubectl -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Fabric をインストールするには、Runtime Manager から供給された ​`values.yml`​ ファイルを使用してください。 1. `values.yml`​ ファイルをダウンロードします。 2. 必要に応じて省略可能なパラメーターを追加します。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 3. 次のコマンドを実行します。 ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## [](#values-yml-reference)values.yml リファレンス 次に ​`values.yml`​ ファイルの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ```
EU コントロールプレーンを使用して Runtime Fabric BYOK を設定する場合は、​「ホスト名設定」​の変更点を確認して、正しく設定してください。特に、​rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io​ プロパティに注意してください。
### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターが作成されて ​`values.yml`​ に追加されます。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター Runtime Fabric をインストールする前に、必要に応じて次の省略可能なパラメーターを ​`values.yml`​ で設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false

crds.install

カードのインストールの有効化

crds.install: true​ (最初の Runtime Fabric のインストール)、false (以降のインストール)

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods

nodeWatcherEnabled

クラスターのノードウォッチャーの有効化または無効化

nodeWatcherEnabled:true​、デフォルト値は ​true

deploymentRateLimitPerSecond

1 秒ごとのデプロイメントレート制限の設定

deploymentRateLimitPerSecond: 1​、デフォルト値は ​1
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 Helm を使用して Runtime Fabric の以前のバージョンにロールバックするには、 [Helm rollback](https://helm.sh/docs/helm/helm_rollback/)​ のドキュメントにあるコマンドの説明を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric) # Helm を使用した Runtime Fabric のインストール Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE)、または VMware Tanzu Kubernetes Grid 環境に Anypoint Runtime Fabric をインストールできます。 ## [](#helm-を使用して-runtime-fabric-をインストールする手順)Helm を使用して Runtime Fabric をインストールする手順 Helm を使用して Runtime Fabric をインストールする手順は次のとおりです。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の ​`rtf`​ 名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、追加の承認済み名前空間を設定します。 5. Runtime Fabric Helm リポジトリを追加します。 6. `values.yml`​ ファイルをダウンロードして Runtime Fabric をインストールします。 7. インストール手順を完了します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric の概要」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/)​で説明されているアーキテクチャと要件を確認した。 - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed-network-configuration)​。 - Kubernetes 環境を次のようにインストールして設定してある。 - ACK、AKS、EKS、EKS-A、GKE、RKE、または VMware Tanzu Kubernetes 環境を実行している。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョンを実行している。 - イングレスコントローラーを実行して外部要求をアプリケーションに送信している。 - Helm 3 以降をインストールして、特権ユーザー権限を持っている。

  • Helm を使用して Runtime Fabric のインストールを管理する場合は、後で ​rtfctl​ コマンドラインユーティリティを使用して Mule ライセンスキーとプロキシを管理できます。ただし、​更新ドキュメント​に説明されているように、インストール後の変更をすべて追跡する必要があります。
### [](#helm-のサポート)Helm のサポート Runtime Fabric は、Helm バージョン 1.13 以降を使用したインストール、アップグレード、ロールバックをサポートしています。 ## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Helm を使用して Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. \[Helm\] をクリックします。 Runtime Fabric を作成すると、選択したビジネスユニットはオーナーのビジネスユニットとして設定されます。このビジネスユニットは、割り当てられたクラスター容量を報告する使用状況レポートで参照されます。インストール時に正しいビジネスユニットを選択していることを確認してください。

Helm を使用したインストールプロセスの残りの手順では、プレースホルダー値を参照します。実際の値は、Runtime Fabric インスタンスを作成するときに Runtime Manager から取得できます。
## [](#runtime-fabric-用の-rtf-名前空間を作成する)Runtime Fabric 用の rtf 名前空間を作成する Kubernetes のクラスターで、​`rtf`​ という名前の名前空間を作成する必要があります。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy kubectl create ns rtf ``` 名前空間としての ​`rtf`​ の使用は、単一クラスターまたは単一インスタンスの場合のみ適用されます。 ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#runtime-fabric-helm-リポジトリを追加する)Runtime Fabric Helm リポジトリを追加する 作成した名前空間に Runtime Fabric Helm リポジトリを追加する必要があります。Runtime Fabric Helm リポジトリには、Runtime Fabric をインストールするのに必要なチャートが入っています。 Helm リポジトリを追加するには、次のコマンドを実行します。 ```copy helm repo add --username --password ```

すでに Helm リポジトリが追加されていて、Runtime Fabric がリポジトリの追加をスキップしたという結果が返された場合は、新しい Runtime Fabric バージョンをインストール (またはそのバージョンにアップグレード) する前に ​helm repo update​ を実行してください。
## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.8/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy kubectl apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 認証済み名前空間モードでクラスタリングアプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` 1. `rtf`​ 名前空間で、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: ADDITIONAL_NAMESPACE_1: "additional-namespace1" ADDITIONAL_NAMESPACE_2: "additional-namespace2" ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy kubectl -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Fabric をインストールするには、Runtime Manager から供給された ​`values.yml`​ ファイルを使用してください。 1. `values.yml`​ ファイルをダウンロードします。 2. 必要に応じて省略可能なパラメーターを追加します。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 3. 次のコマンドを実行します。 ```copy helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ``` ## [](#values-yml-reference)values.yml リファレンス 次に ​`values.yml`​ ファイルの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: muleLicense: customLog4jEnabled: false global: nodeWatcherEnabled: true deploymentRateLimitPerSecond: 1 authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kqa.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ```
EU コントロールプレーンを使用して Runtime Fabric BYOK を設定する場合は、​「ホスト名設定」​の変更点を確認して、正しく設定してください。特に、​rtfRegistry: rtf-runtime-registry.kprod-eu.msap.io​ プロパティに注意してください。
### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターが作成されて ​`values.yml`​ に追加されます。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター Runtime Fabric をインストールする前に、必要に応じて次の省略可能なパラメーターを ​`values.yml`​ で設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false

crds.install

カードのインストールの有効化

crds.install: true​ (最初の Runtime Fabric のインストール)、false (以降のインストール)

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods

nodeWatcherEnabled

クラスターのノードウォッチャーの有効化または無効化

nodeWatcherEnabled:true​、デフォルト値は ​true

deploymentRateLimitPerSecond

1 秒ごとのデプロイメントレート制限の設定

deploymentRateLimitPerSecond: 1​、デフォルト値は ​1

fipsEnabled

Helm 管理 Runtime Fabric の FIPS を有効にします。

fipsEnabled: true​、デフォルト値は ​false
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 Helm を使用して Runtime Fabric の以前のバージョンにロールバックするには、 [Helm rollback](https://helm.sh/docs/helm/helm_rollback/)​ のドキュメントにあるコマンドの説明を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) # Helm を使用した自己管理型 Kubernetes の Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境でアップグレードできます。 `rtfctl`​ コマンドラインツールを使用してインストールした場合は、Helm を使用したアップグレードは行えません。 Helm を使用して Runtime Fabric をアップグレードすると、Runtime Manager はアップグレードの実行に必要な Helm コマンドを提供します。

Runtime Manager から提供されるアップグレードコマンドでは、Runtime Fabric をインストールしたときに Helm に追加したのと同じパラメーターと値を使用します。これらの値 (プロキシ値など) をインストール後に変更してあり、アップグレード後も同じ値を使用したい場合は、アップグレードを実行する前に、値をアップグレードコマンドに追加する必要があります。
Helm を使用して Runtime Fabric をアップグレードする手順は次のとおりです。 1. Runtime Manager の \[Runtime Fabrics\] タブで自分の Runtime Fabric を選択して、Runtime Fabric に移動します。 2. **\[Upgrade (アップグレード…)\]**​ をクリックします。 3. Runtime Manager から提供されたコマンドを実行し、既存のインストールに基づいた ​`values.yml`​ ファイルを生成します。 4. 画面の指示に従って ​`values.yml`​ ファイルを生成してダウンロードします。 5. 必要に応じて省略可能なパラメーターを ​`values.yml`​ ファイルに追加します。 省略可能なパラメーターと必須パラメーターのリストは、インストールドキュメントの​[「​`values.yml`​ リファレンス」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-helm#values-yml-reference)​を参照してください。 6. Helm リポジトリを更新して、Runtime Fabric エージェントチャートが最新であることを確認します。 helm update repo 7. アップグレードを完了するには、次のコマンドを実行します。 helm upgrade --install runtime-fabric rtf/rtf-agent --version -f values.yaml -n # Helm を使用した自己管理型 Kubernetes の Runtime Fabric のインストール

自己管理型 Kubernetes の Runtime Fabric のインストールでは、IT 管理者と MuleSoft 組織システム管理者の両方が必須タスクを実行する必要があります。
Anypoint Runtime Fabric は、Helm を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境にインストールできます。 ## [](#helm-を使用して-runtime-fabric-をインストールする手順)Helm を使用して Runtime Fabric をインストールする手順 Helm を使用して Runtime Fabric をインストールする手順は次のとおりです。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の ​`rtf`​ 名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. Runtime Fabric Helm リポジトリを追加します。 5. `values.yml`​ ファイルをダウンロードして Runtime Fabric をインストールします。 6. インストール手順を完了します。 ## [](#始める前に)始める前に 自己管理型 Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「自己管理型 Kubernetes の Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​で説明されているアーキテクチャと要件を確認した。 - [自己管理型 Kubernetes の Runtime Fabric をサポートするようにネットワークを設定してある](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed-network-configuration)​。 - Kubernetes 環境を次のようにインストールして設定してある。 - EKS、AKS、または GKE Kubernetes 環境を実行している。その他の Kubernetes 環境はサポートされていません。 - [サポートされている Kubernetes バージョン](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed#kubernetes-support)​を実行している。 - イングレスコントローラーを実行して外部要求をアプリケーションに送信している。 - Helm 3 以降をインストールして、特権ユーザー権限を持っている。

Helm を使用して Runtime Fabric のインストールを管理する場合は、後で ​rtfctl​ コマンドラインユーティリティを使用して Mule ライセンスキーとプロキシを管理できます。ただし、​更新ドキュメント​に説明されているように、インストール後の変更をすべて追跡する必要があります。
### [](#helm-のサポート)Helm のサポート Runtime Fabric は、Helm バージョン 1.13 以降を使用したインストール、アップグレード、ロールバックをサポートしています。 ## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Helm を使用して自己管理型 Kubernetes の Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. \[Helm\] をクリックします。

Helm を使用したインストールプロセスの残りの手順では、プレースホルダー値を参照します。実際の値は、Runtime Fabric インスタンスを作成するときに Runtime Manager から取得できます。
## [](#runtime-fabric-用の-rtf-名前空間を作成する)Runtime Fabric 用の rtf 名前空間を作成する Kubernetes のクラスターで、​`rtf`​ という名前の名前空間を作成する必要があります。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 kubectl create ns rtf ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 kubectl create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ## [](#runtime-fabric-helm-リポジトリを追加する)Runtime Fabric Helm リポジトリを追加する 作成した名前空間に Runtime Fabric Helm リポジトリを追加する必要があります。Runtime Fabric Helm リポジトリには、Runtime Fabric をインストールするのに必要なチャートが入っています。 Helm リポジトリを追加するには、次のコマンドを実行します。 helm repo add --username --password

すでに Helm リポジトリが追加されていて、Runtime Fabric がリポジトリの追加をスキップしたという結果が返された場合は、新しい Runtime Fabric バージョンをインストール (またはそのバージョンにアップグレード) する前に ​helm repo update​ を実行してください。
## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Fabric をインストールするには、Runtime Manager から供給された ​`values.yml`​ ファイルを使用してください。 1. `values.yml`​ ファイルをダウンロードします。 2. 必要に応じて省略可能なパラメーターを追加します。 3. 次のコマンドを実行します。 helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## [](#values-yml-reference)values.yml リファレンス 次に ​`values.yml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: customLog4jEnabled: true muleLicense: global: image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターが作成されて ​`values.yml`​ に追加されます。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター Runtime Fabric をインストールする前に、必要に応じて次の省略可能なパラメーターを ​`values.yml`​ で設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: false

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods
## [](#mule-ライセンスキーを挿入する)Mule ライセンスキーを挿入する

このセクション内の手順は、IT 管理者が実行する必要があります。
インストールが正常に完了したら、Mule ライセンスキーを挿入します。 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -b0 license.lic) - Unix では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -w0 license.lic) - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 $BASE64\_ENCODED\_LICENSE=\[convert\]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) 2. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、​`rtfctl`​ ユーティリティをライセンスキーの Base64 値と共に使用します。 rtfctl apply mule-license $BASE64\_ENCODED\_LICENSE 3. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 rtfctl get mule-license ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定

このセクション内の手順は、IT 管理者が実行する必要があります。
イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する

このセクション内の手順は、IT 管理者が実行する必要があります。
インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#関連情報)関連情報 - [自己管理型 Kubernetes の Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) # Helm 管理 Runtime Fabric への移行 [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed)​ を使用してインストールされた Runtime Fabric を ​[Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm)​ ネイティブに移行できます。 ## [](#始める前に)始める前に 移行を実施する前に、次の点を考慮する必要があります。 - この移行は、​`rtfctl`​ を使用してインストールされ、Helm 管理に移行する BYOK クラスターに適用されます。 - クラスターは ​`rtf-agent`​ v2.2.5 以上で構築されている必要があります。移行を開始する前に、エージェントを必要なバージョンにアップグレードしておく必要があります。 さらに、次の詳細が必要です。 - organizationId - fabricId - **ファブリックの管理**​権限を持つ Anypoint ユーザーアカウント用のベアラートークン - ダウンロード済みの rtfctl バージョン v1.0.10 以降 ## [](#rtfctl-から-helm-に移行する)rtfctl から Helm に移行する Runtime Fabric を rtfctl から Helm に移行するには、次のコマンドを実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` このコマンドを実行すると、次のアクションが実行されます。 - 現在の Runtime Fabric のインストールをバックアップし、入力ファイル名で tarball を作成します。 - 現在の Runtime Fabric のインストールをアンインストールします。このコマンドを実行しても、Mule アプリケーションのデプロイメントは更新されず、rtf 名前空間に適用された設定や rtf 名前空間は削除されず、rtf 名前空間以外の名前空間には影響しません。古い Runtime Fabric Helm チャートのみをアンインストールします。 - 指定された fabricId のアクティベーションデータを再生成します。 - Helm 管理 rtf は Helm チャートの値を使用してシークレットを再作成するため、rtf 名前空間の custom-properties シークレットを削除します。 - Helm のコマンドで Runtime Fabric をインストールし、Runtime Fabric の Helm チャートを再レンダリングします。 コマンドを実行しても、Runtime Fabric は既存のインストールバージョン以外のバージョンにはアップグレードされません。 ### [](#コマンドの成功)コマンドの成功 コマンドの実行に成功した場合は: - Runtime Fabric が Anypoint Runtime Manager UI で Helm 管理されていることを確認できます。 - 移行前に適用したイングレステンプレート、永続性ゲートウェイ、カスタムリソース、プロキシ値などの構成が変更されていないことを確認できます。 ### [](#コマンドの失敗)コマンドの失敗 コマンドの実行に失敗した場合は: 1. バックアップを使用して ​`rftctl restore`​ コマンドを実行します。 ```copy rtfctl restore ``` 2. `rfctl migrate`​ コマンドを再実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## [](#コマンドのヘルプ)コマンドのヘルプ コマンドのヘルプを表示するには、次のコマンドを実行します。 ```copy rtfctl migrate –help ``` # Helm 管理 Runtime Fabric への移行 [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed)​ を使用してインストールされた Runtime Fabric を ​[Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm)​ ネイティブに移行できます。 ## [](#始める前に)始める前に 移行を実施する前に、次の点を考慮する必要があります。 - この移行は、​`rtfctl`​ を使用してインストールされ、Helm 管理に移行する BYOK クラスターに適用されます。 - クラスターは ​`rtf-agent`​ v2.2.5 以上で構築されている必要があります。移行を開始する前に、エージェントを必要なバージョンにアップグレードしておく必要があります。 さらに、次の詳細が必要です。 - organizationId - fabricId - **ファブリックの管理**​権限を持つ Anypoint ユーザーアカウント用のベアラートークン - ダウンロード済みの rtfctl バージョン v1.0.10 以降 ## [](#rtfctl-から-helm-に移行する)rtfctl から Helm に移行する Runtime Fabric を rtfctl から Helm に移行するには、次のコマンドを実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` このコマンドを実行すると、次のアクションが実行されます。 - 現在の Runtime Fabric のインストールをバックアップし、入力ファイル名で tarball を作成します。 - 現在の Runtime Fabric のインストールをアンインストールします。このコマンドを実行しても、Mule アプリケーションのデプロイメントは更新されず、rtf 名前空間に適用された設定や rtf 名前空間は削除されず、rtf 名前空間以外の名前空間には影響しません。古い Runtime Fabric Helm チャートのみをアンインストールします。 - 指定された fabricId のアクティベーションデータを再生成します。 - Helm 管理 rtf は Helm チャートの値を使用してシークレットを再作成するため、rtf 名前空間の custom-properties シークレットを削除します。 - Helm のコマンドで Runtime Fabric をインストールし、Runtime Fabric の Helm チャートを再レンダリングします。 コマンドを実行しても、Runtime Fabric は既存のインストールバージョン以外のバージョンにはアップグレードされません。 ### [](#コマンドの成功)コマンドの成功 コマンドの実行に成功した場合は: - Runtime Fabric が Anypoint Runtime Manager UI で Helm 管理されていることを確認できます。 - 移行前に適用したイングレステンプレート、永続性ゲートウェイ、カスタムリソース、プロキシ値などの構成が変更されていないことを確認できます。 ### [](#コマンドの失敗)コマンドの失敗 コマンドの実行に失敗した場合は: 1. バックアップを使用して ​`rftctl restore`​ コマンドを実行します。 ```copy rtfctl restore ``` 2. `rfctl migrate`​ コマンドを再実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## [](#コマンドのヘルプ)コマンドのヘルプ コマンドのヘルプを表示するには、次のコマンドを実行します。 ```copy rtfctl migrate –help ``` # Helm 管理 Runtime Fabric への移行 [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed)​ を使用してインストールされた Runtime Fabric を ​[Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm)​ ネイティブに移行できます。 ## [](#始める前に)始める前に 移行を実施する前に、次の点を考慮する必要があります。 - この移行は、​`rtfctl`​ を使用してインストールされ、Helm 管理に移行する BYOK クラスターに適用されます。 - クラスターは ​`rtf-agent`​ v2.2.5 以上で構築されている必要があります。移行を開始する前に、エージェントを必要なバージョンにアップグレードしておく必要があります。 さらに、次の詳細が必要です。 - organizationId - fabricId - **ファブリックの管理**​権限を持つ Anypoint ユーザーアカウント用のベアラートークン - ダウンロード済みの rtfctl バージョン v1.0.10 以降 ## [](#rtfctl-から-helm-に移行する)rtfctl から Helm に移行する Runtime Fabric を rtfctl から Helm に移行するには、次のコマンドを実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` このコマンドを実行すると、次のアクションが実行されます。 - 現在の Runtime Fabric のインストールをバックアップし、入力ファイル名で tarball を作成します。 - 現在の Runtime Fabric のインストールをアンインストールします。このコマンドを実行しても、Mule アプリケーションのデプロイメントは更新されず、rtf 名前空間に適用された設定や rtf 名前空間は削除されず、rtf 名前空間以外の名前空間には影響しません。古い Runtime Fabric Helm チャートのみをアンインストールします。 - 指定された fabricId のアクティベーションデータを再生成します。 - Helm 管理 rtf は Helm チャートの値を使用してシークレットを再作成するため、rtf 名前空間の custom-properties シークレットを削除します。 - Helm のコマンドで Runtime Fabric をインストールし、Runtime Fabric の Helm チャートを再レンダリングします。 コマンドを実行しても、Runtime Fabric は既存のインストールバージョン以外のバージョンにはアップグレードされません。 ### [](#コマンドの成功)コマンドの成功 コマンドの実行に成功した場合は: - Runtime Fabric が Anypoint Runtime Manager UI で Helm 管理されていることを確認できます。 - 移行前に適用したイングレステンプレート、永続性ゲートウェイ、カスタムリソース、プロキシ値などの構成が変更されていないことを確認できます。 ### [](#コマンドの失敗)コマンドの失敗 コマンドの実行に失敗した場合は: 1. バックアップを使用して ​`rftctl restore`​ コマンドを実行します。 ```copy rtfctl restore ``` 2. `rfctl migrate`​ コマンドを再実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## [](#コマンドのヘルプ)コマンドのヘルプ コマンドのヘルプを表示するには、次のコマンドを実行します。 ```copy rtfctl migrate –help ``` # Helm 管理 Runtime Fabric への移行 [rtfctl](https://docs.mulesoft.com/runtime-fabric/latest/install-self-managed)​ を使用してインストールされた Runtime Fabric を ​[Helm](https://docs.mulesoft.com/runtime-fabric/latest/install-helm)​ ネイティブに移行できます。 ## [](#始める前に)始める前に 移行を実施する前に、次の点を考慮する必要があります。 - この移行は、​`rtfctl`​ を使用してインストールされ、Helm 管理に移行する BYOK クラスターに適用されます。 - クラスターは ​`rtf-agent`​ v2.2.5 以上で構築されている必要があります。移行を開始する前に、エージェントを必要なバージョンにアップグレードしておく必要があります。 さらに、次の詳細が必要です。 - organizationId - fabricId - **ファブリックの管理**​権限を持つ Anypoint ユーザーアカウント用のベアラートークン - ダウンロード済みの rtfctl バージョン v1.0.10 以降 ## [](#rtfctl-から-helm-に移行する)rtfctl から Helm に移行する Runtime Fabric を rtfctl から Helm に移行するには、次のコマンドを実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` このコマンドを実行すると、次のアクションが実行されます。 - 現在の Runtime Fabric のインストールをバックアップし、入力ファイル名で tarball を作成します。 - 現在の Runtime Fabric のインストールをアンインストールします。このコマンドを実行しても、Mule アプリケーションのデプロイメントは更新されず、rtf 名前空間に適用された設定や rtf 名前空間は削除されず、rtf 名前空間以外の名前空間には影響しません。古い Runtime Fabric Helm チャートのみをアンインストールします。 - 指定された fabricId のアクティベーションデータを再生成します。 - Helm 管理 rtf は Helm チャートの値を使用してシークレットを再作成するため、rtf 名前空間の custom-properties シークレットを削除します。 - Helm のコマンドで Runtime Fabric をインストールし、Runtime Fabric の Helm チャートを再レンダリングします。 コマンドを実行しても、Runtime Fabric は既存のインストールバージョン以外のバージョンにはアップグレードされません。 ### [](#コマンドの成功)コマンドの成功 コマンドの実行に成功した場合は: - Runtime Fabric が Anypoint Runtime Manager UI で Helm 管理されていることを確認できます。 - 移行前に適用したイングレステンプレート、永続性ゲートウェイ、カスタムリソース、プロキシ値などの構成が変更されていないことを確認できます。 ### [](#コマンドの失敗)コマンドの失敗 コマンドの実行に失敗した場合は: 1. バックアップを使用して ​`rftctl restore`​ コマンドを実行します。 ```copy rtfctl restore ``` 2. `rfctl migrate`​ コマンドを再実行します。 ```copy rtfctl migrate previous-rtf-bkp.tar.gz --organizationId --fabricId --token --host anypoint.mulesoft.com --confirm ``` ## [](#コマンドのヘルプ)コマンドのヘルプ コマンドのヘルプを表示するには、次のコマンドを実行します。 ```copy rtfctl migrate –help ``` ## [](#アノテーションや表示ラベルを追加する)アノテーションや表示ラベルを追加する 移行後にアノテーションまたは表示ラベルを追加するには、次のコマンドを実行します。 アノテーションの場合: ```copy kubectl annotate secret rtf-muleruntime-license -n rtf \ meta.helm.sh/release-name=runtime-fabric \ meta.helm.sh/release-namespace=rtf --overwrite ``` 表示ラベルの場合: ```copy kubectl label secret rtf-muleruntime-license -n rtf \ app.kubernetes.io/managed-by=Helm --overwrite ``` # Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール 次のプラットフォームでは、Anypoint Runtime Fabric を Kubernetes (K8s) オペレーターとしてインストールできます。 - AWS の Red Hat OpenShift サービス - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - IBM Cloud の Red Hat OpenShift - 自己管理型 Red Hat OpenShift エディション (Performance Plus、OCP、Kubernetes エンジン) ## [](#red-hat-openshift-への-runtime-fabric-のインストール)Red Hat OpenShift への Runtime Fabric のインストール Red Hat OpenShift に Runtime Fabric をインストールするときは、次の操作を実行します。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、共有テナントを設定します。 5. Runtime Fabric Operator をインストールして設定します。 6. 残りのインストール手順を完了して、Runtime Fabric を検証してイングレスを設定します。 Runtime Fabric では OpenShift ルートもサポートされています。​[「OpenShift ルートを設定する」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/configure-openshift-routes)​ドキュメントを参照してください。 ## [](#始める前に)始める前に Red Hat OpenShift に Runtime Fabric をインストールする前に、次のことを確認してください。 - 「自己管理型 Kubernetes の Runtime Fabric」で説明されているアーキテクチャと要件を確認した - ネットワーク要件を確認した - サポートされている Red Hat OpenShift Kubernetes 環境を次のようにインストールして設定している: - サポートされている Kubernetes バージョン - 外部要求をアプリケーションに送信するためのイングレスコントローラー - インストールプロセスを完了する特権ユーザー権限を持っている - Red Hat OpenShift レジストリに必要な次の URL へのアクセス権を持っている: - `registry.connect.redhat.com`​ ( [「Red Hat Container Registry Authentication (Red Hat コンテナレジストリ認証)」](https://access.redhat.com/RegistryAuthentication)​を参照) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## [](#runtime-manager-を使用して-runtime-fabric-を作成します)Runtime Manager を使用して Runtime Fabric を作成します。 Red Hat OpenShift に Runtime Fabric をインストールする前に、まず Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、Red Hat OpenShift オプションを選択します。 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. **\[Operator\]**​ をクリックします。 7. アクティベーションデータをコピーします。 ## [](#runtime-fabric-用の名前空間を作成する)Runtime Fabric 用の名前空間を作成する Kubernetes クラスターで、Runtime Fabric をインストールするための名前空間を作成します。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy oc create ns ``` ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.5/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 認証済み名前空間モードでクラスター化アプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 1. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#runtime-fabric-operator-を設定する)Runtime Fabric Operator を設定する Runtime Fabric Operator を設定するには、要求されたら必要な値を指定します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。

インスタンスの名前は変更しないでください。名前を変更すると、インストールエラーが発生する場合があります。
4. 必須のパラメーターを追加します。案内については、「インストールパラメーターリファレンス」を参照してください。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 5. **\[Create (作成)\]**​ をクリックします。 ## [](#インストールパラメーターリファレンス)インストールパラメーターリファレンス 次に、インストールパラメーターの YAML ビューの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false =======

authorizedNamespaces

承認済み名前空間の有効化

authorizedNamespaces:true

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#openshift-コンソールからライセンスキーを適用する)OpenShift コンソールからライセンスキーを適用する OpenShift コンソールからライセンスキーを適用する手順は、次のとおりです。 1. Runtime Fabric Operator に移動します。 2. Runtime Fabric インスタンスがインストールされている名前空間を選択します。 3. **\[Runtime Fabric\]**​ タブをクリックします。 4. **runtime-fabric**​ インスタンスのリンクをクリックします。 ![runtime-fabric インスタンスが選択されている Runtime Fabric Operator](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-license-operator-1.png) 5. `muleLicense`​ を追加して、Runtime Fabric インスタンスの CR .yaml ファイルを更新します。 ![mulelicense が追加された Runtime Fabric インスタンス](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-license-operator-2.png) ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#mule-アプリケーションを-red-hat-openshift-にデプロイする準備をする)Mule アプリケーションを Red Hat OpenShift にデプロイする準備をする Mule アプリケーションを Red Hat OpenShift クラスターにデプロイする前に Mule ライセンスキーをインストールしていることを確認してから、次の手順を実行してください。 また、Mule アプリケーションのデプロイを試みる前に、Mule ライセンスキーをインストールしていることを確認してください。 1. Mule アプリケーションデプロイメントの名前空間を作成します。​[「アプリケーションデプロイメント用の名前空間の作成」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/create-custom-namespace)​を参照してください。 2. Runtime Manager から、名前空間を使用して Mule アプリケーションをデプロイします。手順は、​[「Runtime Fabric への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric)​を参照してください。 # Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール 次のプラットフォームでは、Anypoint Runtime Fabric を Kubernetes (K8s) オペレーターとしてインストールできます。 - AWS の Red Hat OpenShift サービス - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - IBM Cloud の Red Hat OpenShift - 自己管理型 Red Hat OpenShift エディション (Platform Plus、OCP、Kubernetes エンジン) ## [](#red-hat-openshift-への-runtime-fabric-のインストール)Red Hat OpenShift への Runtime Fabric のインストール Red Hat OpenShift に Runtime Fabric をインストールするときは、次の操作を実行します。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、共有テナントを設定します。 5. Runtime Fabric Operator をインストールして設定します。 6. 残りのインストール手順を完了して、Runtime Fabric を検証してイングレスを設定します。 Runtime Fabric では OpenShift ルートもサポートされています。​[「OpenShift ルートを設定する」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configure-openshift-routes)​ドキュメントを参照してください。 ## [](#始める前に)始める前に Red Hat OpenShift に Runtime Fabric をインストールする前に、次のことを確認してください。 - 「自己管理型 Kubernetes の Runtime Fabric」で説明されているアーキテクチャと要件を確認した - ネットワーク要件を確認した - サポートされている Red Hat OpenShift Kubernetes 環境を次のようにインストールして設定している: - サポートされている Kubernetes バージョン - 外部要求をアプリケーションに送信するためのイングレスコントローラー - インストールプロセスを完了する特権ユーザー権限を持っている - Red Hat OpenShift レジストリに必要な次の URL へのアクセス権を持っている: - `registry.connect.redhat.com`​ ( [「Red Hat Container Registry Authentication (Red Hat コンテナレジストリ認証)」](https://access.redhat.com/RegistryAuthentication)​を参照) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## [](#runtime-manager-を使用して-runtime-fabric-を作成します)Runtime Manager を使用して Runtime Fabric を作成します。 Red Hat OpenShift に Runtime Fabric をインストールする前に、まず Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、Red Hat OpenShift オプションを選択します。 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. **\[Operator\]**​ をクリックします。 7. アクティベーションデータをコピーします。 ## [](#runtime-fabric-用の名前空間を作成する)Runtime Fabric 用の名前空間を作成する Kubernetes クラスターで、Runtime Fabric をインストールするための名前空間を作成します。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy oc create ns ``` ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.6/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 認証済み名前空間モードでクラスター化アプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 1. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#runtime-fabric-operator-を設定する)Runtime Fabric Operator を設定する Runtime Fabric Operator を設定するには、要求されたら必要な値を指定します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。

インスタンスの名前は変更しないでください。名前を変更すると、インストールエラーが発生する場合があります。
4. 必須のパラメーターを追加します。案内については、「インストールパラメーターリファレンス」を参照してください。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 5. **\[Create (作成)\]**​ をクリックします。 ## [](#インストールパラメーターリファレンス)インストールパラメーターリファレンス 次に、インストールパラメーターの YAML ビューの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false =======

authorizedNamespaces

承認済み名前空間の有効化

authorizedNamespaces:true

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#openshift-コンソールからライセンスキーを適用する)OpenShift コンソールからライセンスキーを適用する OpenShift コンソールからライセンスキーを適用する手順は、次のとおりです。 1. Runtime Fabric Operator に移動します。 2. Runtime Fabric インスタンスがインストールされている名前空間を選択します。 3. **\[Runtime Fabric\]**​ タブをクリックします。 4. **runtime-fabric**​ インスタンスのリンクをクリックします。 ![runtime-fabric インスタンスが選択されている Runtime Fabric Operator](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-license-operator-1.png) 5. `muleLicense`​ を追加して、Runtime Fabric インスタンスの CR .yaml ファイルを更新します。 ![mulelicense が追加された Runtime Fabric インスタンス](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-license-operator-2.png) ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#mule-アプリケーションを-red-hat-openshift-にデプロイする準備をする)Mule アプリケーションを Red Hat OpenShift にデプロイする準備をする Mule アプリケーションを Red Hat OpenShift クラスターにデプロイする前に Mule ライセンスキーをインストールしていることを確認してから、次の手順を実行してください。 また、Mule アプリケーションのデプロイを試みる前に、Mule ライセンスキーをインストールしていることを確認してください。 1. Mule アプリケーションデプロイメントの名前空間を作成します。​[「アプリケーションデプロイメント用の名前空間の作成」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/create-custom-namespace)​を参照してください。 2. Runtime Manager から、名前空間を使用して Mule アプリケーションをデプロイします。手順は、​[「Runtime Fabric への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric)​を参照してください。 # Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール 次のプラットフォームでは、Anypoint Runtime Fabric を Kubernetes (K8s) オペレーターとしてインストールできます。 - AWS の Red Hat OpenShift サービス - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - IBM Cloud の Red Hat OpenShift - 自己管理型 Red Hat OpenShift エディション (Platform Plus、OCP、Kubernetes エンジン) ## [](#red-hat-openshift-への-runtime-fabric-のインストール)Red Hat OpenShift への Runtime Fabric のインストール Red Hat OpenShift に Runtime Fabric をインストールするときは、次の操作を実行します。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、共有テナントを設定します。 5. Runtime Fabric Operator をインストールして設定します。 6. 残りのインストール手順を完了して、Runtime Fabric を検証してイングレスを設定します。 Runtime Fabric では OpenShift ルートもサポートされています。​[「OpenShift ルートを設定する」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configure-openshift-routes)​ドキュメントを参照してください。 ## [](#始める前に)始める前に Red Hat OpenShift に Runtime Fabric をインストールする前に、次のことを確認してください。 - 「自己管理型 Kubernetes の Runtime Fabric」で説明されているアーキテクチャと要件を確認した - ネットワーク要件を確認した - サポートされている Red Hat OpenShift Kubernetes 環境を次のようにインストールして設定している: - サポートされている Kubernetes バージョン - 外部要求をアプリケーションに送信するためのイングレスコントローラー - インストールプロセスを完了する特権ユーザー権限を持っている - Red Hat OpenShift レジストリに必要な次の URL へのアクセス権を持っている: - `registry.connect.redhat.com`​ ( [「Red Hat Container Registry Authentication (Red Hat コンテナレジストリ認証)」](https://access.redhat.com/RegistryAuthentication)​を参照) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## [](#runtime-manager-を使用して-runtime-fabric-を作成します)Runtime Manager を使用して Runtime Fabric を作成します。 Red Hat OpenShift に Runtime Fabric をインストールする前に、まず Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、Red Hat OpenShift オプションを選択します。 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. **\[Operator\]**​ をクリックします。 7. アクティベーションデータをコピーします。 ## [](#runtime-fabric-用の名前空間を作成する)Runtime Fabric 用の名前空間を作成する Kubernetes クラスターで、Runtime Fabric をインストールするための名前空間を作成します。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy oc create ns ``` ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.7/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 認証済み名前空間モードでクラスタリングアプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 1. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#runtime-fabric-operator-を設定する)Runtime Fabric Operator を設定する Runtime Fabric Operator を設定するには、要求されたら必要な値を指定します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。

インスタンスの名前は変更しないでください。名前を変更すると、インストールエラーが発生する場合があります。
4. 必須のパラメーターを追加します。案内については、「インストールパラメーターリファレンス」を参照してください。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 5. **\[Create (作成)\]**​ をクリックします。 ## [](#インストールパラメーターリファレンス)インストールパラメーターリファレンス 次に、インストールパラメーターの YAML ビューの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false =======

authorizedNamespaces

承認済み名前空間の有効化

authorizedNamespaces:true

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#openshift-コンソールからライセンスキーを適用する)OpenShift コンソールからライセンスキーを適用する OpenShift コンソールからライセンスキーを適用する手順は、次のとおりです。 1. Runtime Fabric Operator に移動します。 2. Runtime Fabric インスタンスがインストールされている名前空間を選択します。 3. **\[Runtime Fabric\]**​ タブをクリックします。 4. **runtime-fabric**​ インスタンスのリンクをクリックします。 ![runtime-fabric インスタンスが選択されている Runtime Fabric Operator](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-license-operator-1.png) 5. `muleLicense`​ を追加して、Runtime Fabric インスタンスの CR .yaml ファイルを更新します。 ![mulelicense が追加された Runtime Fabric インスタンス](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-license-operator-2.png) ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#mule-アプリケーションを-red-hat-openshift-にデプロイする準備をする)Mule アプリケーションを Red Hat OpenShift にデプロイする準備をする Mule アプリケーションを Red Hat OpenShift クラスターにデプロイする前に Mule ライセンスキーをインストールしていることを確認してから、次の手順を実行してください。 また、Mule アプリケーションのデプロイを試みる前に、Mule ライセンスキーをインストールしていることを確認してください。 1. Mule アプリケーションデプロイメントの名前空間を作成します。​[「アプリケーションデプロイメント用の名前空間の作成」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/create-custom-namespace)​を参照してください。 2. Runtime Manager から、名前空間を使用して Mule アプリケーションをデプロイします。手順は、​[「Runtime Fabric への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric)​を参照してください。 # Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール 次のプラットフォームでは、Anypoint Runtime Fabric を Kubernetes (K8s) オペレーターとしてインストールできます。 - AWS の Red Hat OpenShift サービス - Microsoft Azure Red Hat OpenShift - Red Hat OpenShift Dedicated - IBM Cloud の Red Hat OpenShift - 自己管理型 Red Hat OpenShift エディション (Platform Plus、OCP、Kubernetes エンジン) ## [](#red-hat-openshift-への-runtime-fabric-のインストール)Red Hat OpenShift への Runtime Fabric のインストール Red Hat OpenShift に Runtime Fabric をインストールするときは、次の操作を実行します。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. Runtime Fabric 用の名前空間を作成します。 3. Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 4. 必要に応じて、共有テナントを設定します。 5. Runtime Fabric Operator をインストールして設定します。 6. 残りのインストール手順を完了して、Runtime Fabric を検証してイングレスを設定します。 Runtime Fabric では OpenShift ルートもサポートされています。​[「OpenShift ルートを設定する」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configure-openshift-routes)​ドキュメントを参照してください。 ## [](#始める前に)始める前に Red Hat OpenShift に Runtime Fabric をインストールする前に、次のことを確認してください。 - 「自己管理型 Kubernetes の Runtime Fabric」で説明されているアーキテクチャと要件を確認した - ネットワーク要件を確認した - サポートされている Red Hat OpenShift Kubernetes 環境を次のようにインストールして設定している: - サポートされている Kubernetes バージョン - 外部要求をアプリケーションに送信するためのイングレスコントローラー - インストールプロセスを完了する特権ユーザー権限を持っている - Red Hat OpenShift レジストリに必要な次の URL へのアクセス権を持っている: - `registry.connect.redhat.com`​ ( [「Red Hat Container Registry Authentication (Red Hat コンテナレジストリ認証)」](https://access.redhat.com/RegistryAuthentication)​を参照) - `[https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com](https://rhc4tp-prod-z8cxf-image-registry-us-east-1-evenkyleffocxqvofrk.s3.dualstack.us-east-1.amazonaws.com)` ## [](#runtime-manager-を使用して-runtime-fabric-を作成します)Runtime Manager を使用して Runtime Fabric を作成します。 Red Hat OpenShift に Runtime Fabric をインストールする前に、まず Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、Red Hat OpenShift オプションを選択します。 5. サポート責任の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 6. **\[Operator\]**​ をクリックします。 7. アクティベーションデータをコピーします。 Runtime Fabric を作成すると、選択したビジネスユニットはオーナーのビジネスユニットとして設定されます。このビジネスユニットは、割り当てられたクラスター容量を報告する使用状況レポートで参照されます。インストール時に正しいビジネスユニットを選択していることを確認してください。 ## [](#runtime-fabric-用の名前空間を作成する)Runtime Fabric 用の名前空間を作成する Kubernetes クラスターで、Runtime Fabric をインストールするための名前空間を作成します。この名前空間に Runtime Fabric コンポーネントをインストールします。 名前空間を作成するには、次のコマンドを実行します。 ```copy oc create ns ``` ## [](#docker-プルシークレットを作成する)Docker プルシークレットを作成する 名前空間を作成したら、Runtime Fabric のインストールと実行に必要な Docker イメージを取得できるように、プルシークレットを作成します。 デフォルトのレジストリ URL は ​`rtf-runtime-registry.kprod.msap.io`​ です。ローカルレジストリを使用している場合は、ここで値を指定してください。 プルシークレットを作成するには、次のコマンドを実行します。 ```copy oc create secret docker-registry --namespace rtf --docker-server= --docker-username= --docker-password= ``` ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.8/authorized-namespaces)​を設定できます。 ### [](#始める前に-2)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: # If using persistence gateway uncomment and provide the following. Ref: https://docs.mulesoft.com/runtime-fabric/latest/persistence-gateway#persistence-gateway-with-authorized-namespaces # subjects: # - kind: ServiceAccount # name: rtf-persistence-gateway # namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 認証済み名前空間モードでクラスタリングアプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service- apiGroup: rbac.authorization.k8s.io ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: - kind: ServiceAccount name: rtf-certificate-renewal namespace: ``` 1. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 2. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#runtime-fabric-operator-を設定する)Runtime Fabric Operator を設定する Runtime Fabric Operator を設定するには、要求されたら必要な値を指定します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。

インスタンスの名前は変更しないでください。名前を変更すると、インストールエラーが発生する場合があります。
4. 必須のパラメーターを追加します。案内については、「インストールパラメーターリファレンス」を参照してください。 承認済み名前空間を使用している場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 5. **\[Create (作成)\]**​ をクリックします。 ## [](#インストールパラメーターリファレンス)インストールパラメーターリファレンス 次に、インストールパラメーターの YAML ビューの例を示します。 ```yaml activationData: proxy: http_proxy: http_no_proxy: monitoring_proxy: custom_log4j_enabled: true muleLicense: global: authorizedNamespaces: false image: rtfRegistry: pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ``` ### [](#必須パラメーター)必須パラメーター Runtime Manager で Runtime Fabric を作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

rtf-runtime-registry.kprod.msap.io

pullSecretName

レジストリシークレット

<pull_secret>

muleLicense

アプリケーションの Mule ライセンス

<mule_license_key>​。Base64 エンコードである必要があります。
### [](#省略可能なパラメーター)省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 値 例

customLog4jEnabled

カスタム Log4j 設定を有効化または無効化

customLog4jEnabled: true​、デフォルトは ​false

authorizedNamespaces

追加の名前空間の有効化または無効化

authorizedNamespaces: true​、デフォルトは false =======

authorizedNamespaces

承認済み名前空間の有効化

authorizedNamespaces:true

  • proxy.http_proxy​

  • proxy.http_no_proxy

プロキシ値と no_proxy 値

proxy.monitoring_proxy

Anypoint Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

  • /var/lib/docker/​

  • /var/log/containers​

  • /var/log/pods
## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#openshift-コンソールからライセンスキーを適用する)OpenShift コンソールからライセンスキーを適用する OpenShift コンソールからライセンスキーを適用する手順は、次のとおりです。 1. Runtime Fabric Operator に移動します。 2. Runtime Fabric インスタンスがインストールされている名前空間を選択します。 3. **\[Runtime Fabric\]**​ タブをクリックします。 4. **runtime-fabric**​ インスタンスのリンクをクリックします。 ![runtime-fabric インスタンスが選択されている Runtime Fabric Operator](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-license-operator-1.png) 5. `muleLicense`​ を追加して、Runtime Fabric インスタンスの CR .yaml ファイルを更新します。 ![mulelicense が追加された Runtime Fabric インスタンス](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-license-operator-2.png) ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#mule-アプリケーションを-red-hat-openshift-にデプロイする準備をする)Mule アプリケーションを Red Hat OpenShift にデプロイする準備をする Mule アプリケーションを Red Hat OpenShift クラスターにデプロイする前に Mule ライセンスキーをインストールしていることを確認してから、次の手順を実行してください。 また、Mule アプリケーションのデプロイを試みる前に、Mule ライセンスキーをインストールしていることを確認してください。 1. Mule アプリケーションデプロイメントの名前空間を作成します。​[「アプリケーションデプロイメント用の名前空間の作成」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/create-custom-namespace)​を参照してください。 2. Runtime Manager から、名前空間を使用して Mule アプリケーションをデプロイします。手順は、​[「Runtime Fabric への Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric)​を参照してください。 # Kubernetes 強化ガイド MuleSoft は、Mule アプリケーションデプロイメントのセキュリティと信頼性を最高レベルまで高めるための努力を続けています。その一環として、MuleSoft は Kubernetes 強化ガイドラインを推奨事項として提供するだけでなく、自社のデプロイメントにおいてもこれらのガイドラインを真摯に遵守しています。MuleSoft は、Kubernetes 強化ガイドラインに厳格に従うことで、自社のアプリケーションとインフラストラクチャの保護を強化し、潜在的な脅威や脆弱性からこれらを保護するとともに、お客様と社内業務の両方の環境の堅牢性とセキュリティを維持しています。 MuleSoft は、NSA (米国家安全保障局) の強化ガイドに触発され、Runtime Fabric 上で詳細なセキュリティ制御を実現しています。下記のガイドでは、ガイドラインに基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかについて説明しています。完全なガイダンスについては、 [「Kubernetes Hardening Guide (Kubernetes 強化ガイド)^」](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF)​を参照してください。 次のセキュリティコントロールで Runtime Fabric エージェントを設定すると、エージェントは [CIS (Center for Internet Security) の Kubernetes ベンチマーク](https://downloads.cisecurity.org/#/)​のポリシーセクションに完全に準拠します。 ## [](#k8s-クラスターにおける一般的なセキュリティ上の懸念事項)K8s クラスターにおける一般的なセキュリティ上の懸念事項 次の一般的な危急化の原因を確認してください。 - サプライチェーンのリスク: - コンテナビルドサイクル - インフラストラクチャの取得 - 悪意のある脅威の実行者: - 脆弱性と設定ミスの悪用 - 内部の脅威: - 管理者、ユーザー、またはクラウドプロバイダーによる権限の乱用 ## [](#runtime-fabric-環境の保護)Runtime Fabric 環境の保護 Runtime Fabric を使用すると、上記の懸念から環境を保護することができます。 - コンテナとポッドの脆弱性や設定ミスをスキャンするためにローカルレジストリを有効にします。 - [セキュリティアーキテクチャ](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture)​と​[認証済み名前空間](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces)​のコンテナとポッドが可能な限り最小限の権限に抑えられているかを確認します。 - ネットワークの分離と安全な接続のために、セキュリティアーキテクチャを見直します。 - ファイアウォールを使用して不要なネットワーク接続を制限し、暗号化を使用して機密性を保証します。 - 強力な認証と認証を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象を限定します。 - システム管理者が潜在的な悪意のある活動を事前に把握できるように、監査ログを取得して監視します。 - 定期的にすべての K8s の設定を見直し、脆弱性スキャンを使用して、リスクが適切に特定され、セキュリティパッチが適用されていることを確認します。 ## [](#推奨事項と実装)推奨事項と実装 - Kubernetes ポッドのセキュリティ: - 非 root ユーザーとしてアプリケーションを実行するようにビルドされたコンテナを使用します。 - コンテナイメージは、非 root ユーザーと非 root グループでアプリケーションを実行する必要があります。 - K8s では、​`SecurityContext:runAsUser`​で非 0 ユーザーを指定することで、非ルートコンテナを適用します。 - アプリケーション固有のディレクトリでのみ読み書き可能なファイルシステムをマウントすることで、不変のコンテナファイルシステムを使用します。 - 技術的なコントロールを使用して、次のような最低限のセキュリティを適用します。 - 特権コンテナの禁止 - hostPID、hostIPC、hostNetwork、allowedHostPathなど、すり抜けに悪用されやすいコンテナの機能の拒否 - root ユーザーとして実行したり root への昇格を許可したりするコンテナの拒否 - 安全なコンテナイメージの構築: - 信頼できるリポジトリのみを使用します。 - イメージの脆弱性や設定ミスをスキャンします。スキャナーは偽陽性を無視できます。 - ポッドサービスアカウントトークンの保護: - すべてのポッドにデフォルトでマウントされるサービスアカウントトークンを設定します。 - `automountServiceAccountToken:false`​ で無効にできます。 - インスタンスが外部サービスに認証するためにトークンが必要な場合は、RBAC を使用してクラスター内のポッドの権限を制限します。 - 認証および承認: - ユーザー、管理者、開発者、サービスアカウント、インフラストラクチャチームにそれぞれ別々のロールを割り当てる RBAC ポリシーを作成します。 - 監査ログと脅威検出: - ノード、ポッド、コンテナレベルで障害が発生した場合でも可用性が確保されるように、ログを維持します。 - クラスター外部のログを集約します。 - ネットワークの分離と強化: - デフォルトの名前空間は分離されていませんが、RBAC、ネットワークポリシー、リソースポリシーによるルールの適用が可能です。 - アップグレードとセキュリティ対策: - セキュリティパッチと更新を迅速に適用します。 - 未使用のコンポーネントを環境からアンインストールして削除します。 Mule アプリケーションのデプロイメントにセキュリティ設定を適用するには、​[「Mule アプリケーション Kubernetes リソースのカスタマイズ」](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd)​ドキュメントのガイドラインに従ってください。 # Kubernetes 強化ガイド MuleSoft は、Mule アプリケーションデプロイメントのセキュリティと信頼性を最高レベルまで高めるための努力を続けています。その一環として、MuleSoft は Kubernetes 強化ガイドラインを推奨事項として提供するだけでなく、自社のデプロイメントにおいてもこれらのガイドラインを真摯に遵守しています。MuleSoft は、Kubernetes 強化ガイドラインに厳格に従うことで、自社のアプリケーションとインフラストラクチャの保護を強化し、潜在的な脅威や脆弱性からこれらを保護するとともに、お客様と社内業務の両方の環境の堅牢性とセキュリティを維持しています。 MuleSoft は、NSA (米国家安全保障局) の強化ガイドに触発され、Runtime Fabric 上で詳細なセキュリティ制御を実現しています。下記のガイドでは、ガイドラインに基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかについて説明しています。完全な案内については、 [「Kubernetes Hardening Guide (Kubernetes 強化ガイド)」](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF)​を参照してください。 次のセキュリティコントロールで Runtime Fabric エージェントを設定すると、エージェントは [CIS (Center for Internet Security) の Kubernetes ベンチマーク](https://downloads.cisecurity.org/#/)​のポリシーセクションに完全に準拠します。 ## [](#k8s-クラスターにおける一般的なセキュリティ上の懸念事項)K8s クラスターにおける一般的なセキュリティ上の懸念事項 次の一般的な危急化の原因を確認してください。 - サプライチェーンのリスク: - コンテナビルドサイクル - インフラストラクチャの取得 - 悪意のある脅威の実行者: - 脆弱性と設定ミスの悪用 - 内部の脅威: - 管理者、ユーザー、またはクラウドプロバイダーによる権限の乱用 ## [](#runtime-fabric-環境の保護)Runtime Fabric 環境の保護 Runtime Fabric を使用すると、上記の懸念から環境を保護することができます。 - コンテナとポッドの脆弱性や設定ミスをスキャンするためにローカルレジストリを有効にします。 - [セキュリティアーキテクチャ](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture)​と​[認証済み名前空間](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces)​のコンテナとポッドが可能な限り最小限の権限に抑えられているかを確認します。 - ネットワークの分離と安全な接続のために、セキュリティアーキテクチャを見直します。 - ファイアウォールを使用して不要なネットワーク接続を制限し、暗号化を使用して機密性を保証します。 - 強力な認証と認証を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象を限定します。 - システム管理者が潜在的な悪意のある活動を事前に把握できるように、監査ログを取得して監視します。 - 定期的にすべての K8s の設定を見直し、脆弱性スキャンを使用して、リスクが適切に特定され、セキュリティパッチが適用されていることを確認します。 ## [](#推奨事項と実装)推奨事項と実装 - Kubernetes ポッドのセキュリティ: - 非 root ユーザーとしてアプリケーションを実行するようにビルドされたコンテナを使用します。 - コンテナイメージは、非 root ユーザーと非 root グループでアプリケーションを実行する必要があります。 - K8s では、​`SecurityContext:runAsUser`​ で非 0 ユーザーを指定することで、非ルートコンテナを適用します。 - アプリケーション固有のディレクトリでのみ読み書き可能なファイルシステムをマウントすることで、不変のコンテナファイルシステムを使用します。 - 技術的なコントロールを使用して、次のような最低限のセキュリティを適用します。 - 特権コンテナの禁止 - hostPID、hostIPC、hostNetwork、allowedHostPathなど、すり抜けに悪用されやすいコンテナの機能の拒否 - root ユーザーとして実行したり root への昇格を許可したりするコンテナの拒否 - 安全なコンテナイメージの構築: - 信頼できるリポジトリのみを使用します。 - イメージの脆弱性や設定ミスをスキャンします。スキャナーは偽陽性を無視できます。 - ポッドサービスアカウントトークンの保護: - すべてのポッドにデフォルトでマウントされるサービスアカウントトークンを設定します。 - `automountServiceAccountToken:false`​ で無効にできます。 - インスタンスが外部サービスに認証するためにトークンが必要な場合は、RBAC を使用してクラスター内のポッドの権限を制限します。 - 認証および承認: - ユーザー、管理者、開発者、サービスアカウント、インフラストラクチャチームにそれぞれ別々のロールを割り当てる RBAC ポリシーを作成します。 - 監査ログと脅威検出: - ノード、ポッド、コンテナレベルで障害が発生した場合でも可用性が確保されるように、ログを維持します。 - クラスター外部のログを集約します。 - ネットワークの分離と強化: - デフォルトの名前空間は分離されていませんが、RBAC、ネットワークポリシー、リソースポリシーによるルールの適用が可能です。 - アップグレードとセキュリティ対策: - セキュリティパッチと更新を迅速に適用します。 - 未使用のコンポーネントを環境からアンインストールして削除します。 Mule アプリケーションのデプロイメントにセキュリティ設定を適用するには、​[「Mule アプリケーション Kubernetes リソースのカスタマイズ」](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd)​ドキュメントのガイドラインに従ってください。 # Kubernetes 強化ガイド MuleSoft は、Mule アプリケーションデプロイメントのセキュリティと信頼性を最高レベルまで高めるための努力を続けています。その一環として、MuleSoft は Kubernetes 強化ガイドラインを推奨事項として提供するだけでなく、自社のデプロイメントにおいてもこれらのガイドラインを真摯に遵守しています。MuleSoft は、Kubernetes 強化ガイドラインに厳格に従うことで、自社のアプリケーションとインフラストラクチャの保護を強化し、潜在的な脅威や脆弱性からこれらを保護するとともに、お客様と社内業務の両方の環境の堅牢性とセキュリティを維持しています。 MuleSoft は、NSA (米国家安全保障局) の強化ガイドに触発され、Runtime Fabric 上で詳細なセキュリティ制御を実現しています。下記のガイドでは、ガイドラインに基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかについて説明しています。完全な案内については、 [「Kubernetes Hardening Guide (Kubernetes 強化ガイド)」](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF)​を参照してください。 次のセキュリティコントロールで Runtime Fabric エージェントを設定すると、エージェントは [CIS (Center for Internet Security) の Kubernetes ベンチマーク](https://downloads.cisecurity.org/#/)​のポリシーセクションに完全に準拠します。 ## [](#k8s-クラスターにおける一般的なセキュリティ上の懸念事項)K8s クラスターにおける一般的なセキュリティ上の懸念事項 次の一般的な危急化の原因を確認してください。 - サプライチェーンのリスク: - コンテナビルドサイクル - インフラストラクチャの取得 - 悪意のある脅威の実行者: - 脆弱性と設定ミスの悪用 - 内部の脅威: - 管理者、ユーザー、またはクラウドプロバイダーによる権限の乱用 ## [](#runtime-fabric-環境の保護)Runtime Fabric 環境の保護 Runtime Fabric を使用すると、上記の懸念から環境を保護することができます。 - コンテナとポッドの脆弱性や設定ミスをスキャンするためにローカルレジストリを有効にします。 - [セキュリティアーキテクチャ](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture)​と​[認証済み名前空間](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces)​のコンテナとポッドが可能な限り最小限の権限に抑えられているかを確認します。 - ネットワークの分離と安全な接続のために、セキュリティアーキテクチャを見直します。 - ファイアウォールを使用して不要なネットワーク接続を制限し、暗号化を使用して機密性を保証します。 - 強力な認証と認証を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象を限定します。 - システム管理者が潜在的な悪意のある活動を事前に把握できるように、監査ログを取得して監視します。 - 定期的にすべての K8s の設定を見直し、脆弱性スキャンを使用して、リスクが適切に特定され、セキュリティパッチが適用されていることを確認します。 ## [](#推奨事項と実装)推奨事項と実装 - Kubernetes ポッドのセキュリティ: - 非 root ユーザーとしてアプリケーションを実行するようにビルドされたコンテナを使用します。 - コンテナイメージは、非 root ユーザーと非 root グループでアプリケーションを実行する必要があります。 - K8s では、​`SecurityContext:runAsUser`​ で非 0 ユーザーを指定することで、非ルートコンテナを適用します。 - アプリケーション固有のディレクトリでのみ読み書き可能なファイルシステムをマウントすることで、不変のコンテナファイルシステムを使用します。 - 技術的なコントロールを使用して、次のような最低限のセキュリティを適用します。 - 特権コンテナの禁止 - hostPID、hostIPC、hostNetwork、allowedHostPath など、すり抜けに悪用されやすいコンテナの機能の拒否 - root ユーザーとして実行したり root への昇格を許可したりするコンテナの拒否 - 安全なコンテナイメージの構築: - 信頼できるリポジトリのみを使用します。 - イメージの脆弱性や設定ミスをスキャンします。スキャナーは偽陽性を無視できます。 - ポッドサービスアカウントトークンの保護: - すべてのポッドにデフォルトでマウントされるサービスアカウントトークンを設定します。 - `automountServiceAccountToken:false`​ で無効にできます。 - インスタンスが外部サービスに認証するためにトークンが必要な場合は、RBAC を使用してクラスター内のポッドの権限を制限します。 - 認証および承認: - ユーザー、管理者、開発者、サービスアカウント、インフラストラクチャチームにそれぞれ別々のロールを割り当てる RBAC ポリシーを作成します。 - 監査ログと脅威検出: - ノード、ポッド、コンテナレベルで障害が発生した場合でも可用性が確保されるように、ログを維持します。 - クラスター外部のログを集約します。 - ネットワークの分離と強化: - デフォルトの名前空間は分離されていませんが、RBAC、ネットワークポリシー、リソースポリシーによるルールの適用が可能です。 - アップグレードとセキュリティ対策: - セキュリティパッチと更新を迅速に適用します。 - 未使用のコンポーネントを環境からアンインストールして削除します。 Mule アプリケーションのデプロイメントにセキュリティ設定を適用するには、​[「Mule アプリケーション Kubernetes リソースのカスタマイズ」](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd)​ドキュメントのガイドラインに従ってください。 # Kubernetes 強化ガイド MuleSoft は、Mule アプリケーションデプロイメントのセキュリティと信頼性を最高レベルまで高めるための努力を続けています。その一環として、MuleSoft は Kubernetes 強化ガイドラインを推奨事項として提供するだけでなく、自社のデプロイメントにおいてもこれらのガイドラインを真摯に遵守しています。MuleSoft は、Kubernetes 強化ガイドラインに厳格に従うことで、自社のアプリケーションとインフラストラクチャの保護を強化し、潜在的な脅威や脆弱性からこれらを保護するとともに、お客様と社内業務の両方の環境の堅牢性とセキュリティを維持しています。 MuleSoft は、NSA (米国家安全保障局) の強化ガイドに触発され、Runtime Fabric 上で詳細なセキュリティ制御を実現しています。下記のガイドでは、ガイドラインに基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかについて説明しています。完全な案内については、 [「Kubernetes Hardening Guide (Kubernetes 強化ガイド)」](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF)​を参照してください。 次のセキュリティコントロールで Runtime Fabric エージェントを設定すると、エージェントは [CIS (Center for Internet Security) の Kubernetes ベンチマーク](https://downloads.cisecurity.org/#/)​のポリシーセクションに完全に準拠します。 ## [](#k8s-クラスターにおける一般的なセキュリティ上の懸念事項)K8s クラスターにおける一般的なセキュリティ上の懸念事項 次の一般的な危急化の原因を確認してください。 - サプライチェーンのリスク: - コンテナビルドサイクル - インフラストラクチャの取得 - 悪意のある脅威の実行者: - 脆弱性と設定ミスの悪用 - 内部の脅威: - 管理者、ユーザー、またはクラウドプロバイダーによる権限の乱用 ## [](#runtime-fabric-環境の保護)Runtime Fabric 環境の保護 Runtime Fabric を使用すると、上記の懸念から環境を保護することができます。 - コンテナとポッドの脆弱性や設定ミスをスキャンするためにローカルレジストリを有効にします。 - [セキュリティアーキテクチャ](https://docs.mulesoft.com/runtime-fabric/latest/security-architecture)​と​[認証済み名前空間](https://docs.mulesoft.com/runtime-fabric/latest/authorized-namespaces)​のコンテナとポッドが可能な限り最小限の権限に抑えられているかを確認します。 - ネットワークの分離と安全な接続のために、セキュリティアーキテクチャを見直します。 - ファイアウォールを使用して不要なネットワーク接続を制限し、暗号化を使用して機密性を保証します。 - 強力な認証と認証を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象を限定します。 - システム管理者が潜在的な悪意のある活動を事前に把握できるように、監査ログを取得して監視します。 - 定期的にすべての K8s の設定を見直し、脆弱性スキャンを使用して、リスクが適切に特定され、セキュリティパッチが適用されていることを確認します。 ## [](#推奨事項と実装)推奨事項と実装 - Kubernetes ポッドのセキュリティ: - 非 root ユーザーとしてアプリケーションを実行するようにビルドされたコンテナを使用します。 - コンテナイメージは、非 root ユーザーと非 root グループでアプリケーションを実行する必要があります。 - K8s では、​`SecurityContext:runAsUser`​ で非 0 ユーザーを指定することで、非ルートコンテナを適用します。 - アプリケーション固有のディレクトリでのみ読み書き可能なファイルシステムをマウントすることで、不変のコンテナファイルシステムを使用します。 - 技術的なコントロールを使用して、次のような最低限のセキュリティを適用します。 - 特権コンテナの禁止 - hostPID、hostIPC、hostNetwork、allowedHostPath など、すり抜けに悪用されやすいコンテナの機能の拒否 - root ユーザーとして実行したり root への昇格を許可したりするコンテナの拒否 - 安全なコンテナイメージの構築: - 信頼できるリポジトリのみを使用します。 - イメージの脆弱性や設定ミスをスキャンします。スキャナーは偽陽性を無視できます。 - ポッドサービスアカウントトークンの保護: - すべてのポッドにデフォルトでマウントされるサービスアカウントトークンを設定します。 - `automountServiceAccountToken:false`​ で無効にできます。 - インスタンスが外部サービスに認証するためにトークンが必要な場合は、RBAC を使用してクラスター内のポッドの権限を制限します。 - 認証および承認: - ユーザー、管理者、開発者、サービスアカウント、インフラストラクチャチームにそれぞれ別々のロールを割り当てる RBAC ポリシーを作成します。 - 監査ログと脅威検出: - ノード、ポッド、コンテナレベルで障害が発生した場合でも可用性が確保されるように、ログを維持します。 - クラスター外部のログを集約します。 - ネットワークの分離と強化: - デフォルトの名前空間は分離されていませんが、RBAC、ネットワークポリシー、リソースポリシーによるルールの適用が可能です。 - アップグレードとセキュリティ対策: - セキュリティパッチと更新を迅速に適用します。 - 未使用のコンポーネントを環境からアンインストールして削除します。 Mule アプリケーションのデプロイメントにセキュリティ設定を適用するには、​[「Mule アプリケーション Kubernetes リソースのカスタマイズ」](https://docs.mulesoft.com/runtime-fabric/latest/customize-kubernetes-crd)​ドキュメントのガイドラインに従ってください。 # Log4j を使用したログシステムとのインテグレーション Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合できます。 任意の Log4j アペンダーを使用できます。​`log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 ## [](#要件と制限事項)要件と制限事項 - Log4j アペンダーと外部ログ転送を同時に使用すると、ログコレクションが重複する可能性もあります。どちらか一方を使用してください。 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、支援しません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 非同期ログアペンダーのみを使用してください。 - FileAppender、RollingFileAppender、AnypointMonitoringFileAppender、RandomAccessFileAppender などのファイルアペンダーは自動的に削除されます。 - カスタム Log4j 設定を使用する場合、Mule Runtime Engine とアプリケーションログの両方を Anypoint Monitoring で引き続き使用できます。 ## [](#log4j-の有効化)Log4j の有効化 カスタム Log4j 設定はデフォルトで有効化されています。Runtime Fabric をインストールすると、パラメーターは ​`Values.yaml`​ で有効化されます。この値が ​`true`​ に設定されていたとしても、アペンダーを追加する必要があります。Log4j を無効化するには、値を ​`false`​ に設定します。 ## [](#例-splunk-を使用して-log4j-設定を作成する)例: Splunk を使用して Log4j 設定を作成する ログを Runtime Fabric で表示可能にし、Splunk に送信するには、​`SplunkHttp`​ Log4j アペンダーを設定します。 Log4j アペンダーを有効にする手順は、次のとおりです。 1. `log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、​`SplunkHttp`​ Log4j アペンダーを含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 ```xml ``` 1. 設定に Splunk 連動関係が含まれていることを確認します。 ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` Splunk の最新バージョンについては、 [GitHub](https://github.com/splunk/splunk-library-javalogging/tags)​ を参照してください。 アプリケーションが起動すると、カスタム Log4j アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [MDC ログ](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) # Log4j を使用したログシステムとのインテグレーション Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合できます。 任意の Log4j アペンダーを使用できます。​`log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 ## [](#要件と制限事項)要件と制限事項 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、支援しません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 非同期ログアペンダーのみを使用してください。 - FileAppender、RollingFileAppender、AnypointMonitoringFileAppender、RandomAccessFileAppender などのファイルアペンダーは自動的に削除されます。 - カスタム Log4j 設定を使用する場合、Mule Runtime Engine とアプリケーションログの両方を Anypoint Monitoring で引き続き使用できます。 ## [](#log4j-の有効化)Log4j の有効化 カスタム Log4j 設定はデフォルトで無効化されています。Runtime Fabric をインストールすると、パラメーターは ​`Values.yaml`​ で無効化 (​`false`​ に設定) されます。この値を ​`true`​ に設定する必要があります。 また、次の手順でカスタム Log4j 設定を有効化することもできます。 1. クラスター内から次を実行します。 kubectl -nrtf patch secret custom-properties -p '{"data":{"CUSTOM\_LOG4J\_ENABLED":"dHJ1ZQ=="}}' 2. Runtime Fabric エージェントポッドを再起動します。 3. カスタム Log4j 設定に関連付けられているアプリケーションを再起動します。
カスタム Log4j は、Mule バージョン 4.3.0 以降の Mule Runtime エンジンインスタンスで動作している Mule アプリケーションでのみサポートされます。Mule イメージは、2022 年 11 月 17 日より後にビルドされている必要があります。詳細は、​「Runtime Fabric リリースノート」​を参照してください。
## [](#例-splunk-を使用して-log4j-設定を作成する)例: Splunk を使用して Log4j 設定を作成する ログを Runtime Fabric で表示可能にし、Splunk に送信するには、​`SplunkHttp`​ Log4j アペンダーを設定します。 Log4j アペンダーを有効にする手順は、次のとおりです。 1. `log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、​`SplunkHttp`​ Log4j アペンダーを含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 ```xml ``` 1. 設定に Splunk 連動関係が含まれていることを確認します。 ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` Splunk の最新バージョンについては、 [GitHub](https://github.com/splunk/splunk-library-javalogging/tags)​ を参照してください。 アプリケーションが起動すると、カスタム Log4j アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [MDC ログ](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) # Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 3) Runtime Fabric は、Mule Maven プラグイン 2.3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 3.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 3.x を使用して Mule 4 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-maven-4.x)​を参照してください。 ## [](#前提条件)前提条件 - アプリケーションは Exchange でパブリッシュされる必要があります。 - Studio からこの作業を行うには、​[「Exchange へのプロジェクトのパブリッシュ」](https://docs.mulesoft.com/studio/export-to-exchange-task)​を参照してください。 - Maven を使用してこの作業を行うには、​[「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。
Studio では、アプリケーションを Exchange にアップロードするときに 2 つのプロジェクトタイプ (​example​ と ​template​) のみを選択できます。別のプロジェクトタイプを指定するには、Maven を使用してアプリケーションをパブリッシュしてください。
## [](#mule-maven-プラグインを-mule-プロジェクトに追加する)Mule Maven プラグインを Mule プロジェクトに追加する Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 2.3.3 true ```
拡張機能を有効にします。​<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。 ## [](#デプロイメントとリファレンス情報)デプロイメントとリファレンス情報。 Mule Maven プラグイン 2.3.x を使用したデプロイメント手順と完全なリファレンス情報については、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](#3.9@mule-runtime::mule-maven-plugin.adoc#deploying-to-rtf)​を参照してください。 Mule Maven プラグイン 2.2.x 以前を使用している場合は、​[「Mule Maven プラグイン 2.2.x」](#3.9@mule-runtime::mule-maven-plugin-v2.2.adoc)​を参照してください。 # Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 3) Runtime Fabric は、Mule Maven プラグイン 2.3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 3.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 3.x を使用して Mule 4 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-maven-4.x)​を参照してください。 ## [](#前提条件)前提条件 - アプリケーションは Exchange でパブリッシュされる必要があります。 - Studio からこの作業を行うには、​[「Exchange へのプロジェクトのパブリッシュ」](https://docs.mulesoft.com/studio/export-to-exchange-task)​を参照してください。 - Maven を使用してこの作業を行うには、​[「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。
Studio では、アプリケーションを Exchange にアップロードするときに 2 つのプロジェクトタイプ (​example​ と ​template​) のみを選択できます。別のプロジェクトタイプを指定するには、Maven を使用してアプリケーションをパブリッシュしてください。
## [](#mule-maven-プラグインを-mule-プロジェクトに追加する)Mule Maven プラグインを Mule プロジェクトに追加する Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 2.3.3 true ```
拡張機能を有効にします。​<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。 ## [](#デプロイメントとリファレンス情報)デプロイメントとリファレンス情報。 Mule Maven プラグイン 2.3.x を使用したデプロイメント手順と完全なリファレンス情報については、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](#3.9@mule-runtime::mule-maven-plugin.adoc#deploying-to-rtf)​を参照してください。 Mule Maven プラグイン 2.2.x 以前を使用している場合は、​[「Mule Maven プラグイン 2.2.x」](#3.9@mule-runtime::mule-maven-plugin-v2.2.adoc)​を参照してください。 # Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 3) Runtime Fabric は、Mule Maven プラグイン 2.3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 3.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 3.x を使用して Mule 4 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-maven-4.x)​を参照してください。 ## [](#前提条件)前提条件 - アプリケーションは Exchange でパブリッシュされる必要があります。 - Studio からこの作業を行うには、​[「Exchange へのプロジェクトのパブリッシュ」](https://docs.mulesoft.com/studio/export-to-exchange-task)​を参照してください。 - Maven を使用してこの作業を行うには、​[「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。
Studio では、アプリケーションを Exchange にアップロードするときに 2 つのプロジェクトタイプ (​example​ と ​template​) のみを選択できます。別のプロジェクトタイプを指定するには、Maven を使用してアプリケーションをパブリッシュしてください。
## [](#mule-maven-プラグインを-mule-プロジェクトに追加する)Mule Maven プラグインを Mule プロジェクトに追加する Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 2.3.3 true ```
拡張機能を有効にします。​<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。 ## [](#デプロイメントとリファレンス情報)デプロイメントとリファレンス情報。 Mule Maven プラグイン 2.3.x を使用したデプロイメント手順と完全なリファレンス情報については、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](#3.9@mule-runtime::mule-maven-plugin.adoc#deploying-to-rtf)​を参照してください。 Mule Maven プラグイン 2.2.x 以前を使用している場合は、​[「Mule Maven プラグイン 2.2.x」](#3.9@mule-runtime::mule-maven-plugin-v2.2.adoc)​を参照してください。 # Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 4) Runtime Fabric は、Mule Maven プラグイン 3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 4.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 2.x を使用して Mule 3 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3)」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-maven-3.x)​を参照してください。 Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 4) Runtime Fabric は、Mule Maven プラグイン 3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 4.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 2.x を使用して Mule 3 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3)」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-maven-3.x)​を参照してください。 Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 4) Runtime Fabric は、Mule Maven プラグイン 3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 4.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 2.x を使用して Mule 3 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3)」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-maven-3.x)​を参照してください。 Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3) Runtime Fabric は、Mule Maven プラグイン 2.3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 3.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 3.x を使用して Mule 4 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-maven-4.x)​を参照してください。 ## [](#前提条件)前提条件 - アプリケーションは Exchange でパブリッシュされる必要があります。 - Studio からこの作業を行うには、​[「Exchange へのプロジェクトのパブリッシュ」](https://docs.mulesoft.com/studio/export-to-exchange-task)​を参照してください。 - Maven を使用してこの作業を行うには、​[「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。
Studio では、アプリケーションを Exchange にアップロードするときに 2 つのプロジェクトタイプ (​example​ と ​template​) のみを選択できます。別のプロジェクトタイプを指定するには、Maven を使用してアプリケーションをパブリッシュしてください。
## [](#mule-maven-プラグインを-mule-プロジェクトに追加する)Mule Maven プラグインを Mule プロジェクトに追加する Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 2.3.3 true ```
拡張機能を有効にします。​<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。 ## [](#デプロイメントとリファレンス情報)デプロイメントとリファレンス情報。 Mule Maven プラグイン 2.3.x を使用したデプロイメント手順と完全なリファレンス情報については、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](#3.9@mule-runtime::mule-maven-plugin.adoc#deploying-to-rtf)​を参照してください。 Mule Maven プラグイン 2.2.x 以前を使用している場合は、​[「Mule Maven プラグイン 2.2.x」](#3.9@mule-runtime::mule-maven-plugin-v2.2.adoc)​を参照してください。 # Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3) Runtime Fabric は、Mule Maven プラグイン 2.3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 3.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 3.x を使用して Mule 4 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-maven-4.x)​を参照してください。 ## [](#前提条件)前提条件 - アプリケーションは Exchange でパブリッシュされる必要があります。 - Studio からこの作業を行うには、​[「Exchange へのプロジェクトのパブリッシュ」](https://docs.mulesoft.com/studio/export-to-exchange-task)​を参照してください。 - Maven を使用してこの作業を行うには、​[「Maven を使用した Exchange アセットのパブリッシュとデプロイ」](https://docs.mulesoft.com/jp/exchange/to-publish-assets-maven)​を参照してください。
Studio では、アプリケーションを Exchange にアップロードするときに 2 つのプロジェクトタイプ (​example​ と ​template​) のみを選択できます。別のプロジェクトタイプを指定するには、Maven を使用してアプリケーションをパブリッシュしてください。
## [](#mule-maven-プラグインを-mule-プロジェクトに追加する)Mule Maven プラグインを Mule プロジェクトに追加する Mule Maven プラグインを追加するには、その Maven 連動関係をプロジェクトに追加する必要があります。 ```xml org.mule.tools.maven mule-maven-plugin 2.3.3 true ```
拡張機能を有効にします。​<extensions>true</extensions>​ が存在しない場合、プラグインは機能しません。
このリポジトリから: ```xml mule-public https://repository.mulesoft.org/nexus/content/repositories/releases ``` これにより、プロジェクトで Mule Maven プラグインが有効になります。 ## [](#デプロイメントとリファレンス情報)デプロイメントとリファレンス情報。 Mule Maven プラグイン 2.3.x を使用したデプロイメント手順と完全なリファレンス情報については、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](#3.9@mule-runtime::mule-maven-plugin.adoc#deploying-to-rtf)​を参照してください。 Mule Maven プラグイン 2.2.x 以前を使用している場合は、​[「Mule Maven プラグイン 2.2.x」](#3.9@mule-runtime::mule-maven-plugin-v2.2.adoc)​を参照してください。 # Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4) Runtime Fabric は、Mule Maven プラグイン 3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 4.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 2.x を使用して Mule 3 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-maven-3.x)​を参照してください。 Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4) Runtime Fabric は、Mule Maven プラグイン 3.x を使用した Mule アプリケーションの管理およびデプロイをサポートしています。このトピックの情報は、Mule Runtime Engine 4.x への Mule アプリケーションのデプロイに固有のものです。 Mule Maven プラグイン 2.x を使用して Mule 3 アプリケーションをデプロイするには、​[「Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3)」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-maven-3.x)​を参照してください。 Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#add-mmp)Mule Maven プラグインを Mule プロジェクトに追加する Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-concept.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] Unresolved include directive in modules/ROOT/pages/deploy-maven-4.x.adoc - include::mule-runtime::partial$mmp-deploy-to-rtf.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # Mule アプリケーション Kubernetes リソースのカスタマイズ Anypoint Runtime Fabric では、カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズできます。 `kubernetestemplate`​ リソースに ​`mule-application`​ という名前を付けます。テンプレートは 2 つの異なる名前空間で定義できます。 - アプリケーション名前空間 テンプレートは、指定された名前空間にデプロイされたすべての Mule アプリケーションに適用されます。 - Runtime Fabric エージェント名前空間 テンプレートは、指定された Runtime Fabric エージェントによって管理されるすべての Mule アプリケーションに適用されます。 `kubernetestemplate`​ リソースは、リソースが作成された後に作成される Mule アプリケーションデプロイメントにのみ適用されます。既存のデプロイメントには影響しません。​`kubernetestemplate`​ を作成または更新した後に Mule アプリケーションを再デプロイすると、テンプレートが適用されます。 `kubernetestemplate`​ リソースを使用すると、アプリケーションのポッド、デプロイメント、およびサービスオブジェクトで次の要素を設定できます。 - ポッド - [アノテーション](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [表示ラベル](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [ノードセレクター](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [アフィニティ](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [セキュリティコンテキスト](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [揮発ストレージ制限](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [許容範囲](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [トポロジー拡散制約](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) セキュリティコンテキストポッドの場合、使用するキーは ​`containerSecurityContext`​ です。 - デプロイメント - アノテーション - Labels (ラベル) - サービス - アノテーション - Labels (ラベル) Runtime Fabric ですでに定義されている設定要素は、テンプレートで定義した設定要素より優先されます。 テンプレートに設定できるキー要素の CRD を取得するには、次のコマンドを実行することで Kubernetes の仕様を取得します。 ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## [](#例)例 `ポッド`​、​`デプロイ`​、​`サービス`​オブジェクトでの​`表示ラベル`​の設定 ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` `ポッド`​オブジェクトの下にある ​`containerSecurityContext`​ のランタイムデフォルト ​`seccompProfile`​ の設定: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` 設定できるすべてのキーを示した別の例: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4gb nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: {{ .Values.id }} ``` CRD を使用して上書きできないキー要素: - デプロイメント - labels (表示ラベル) - 環境 - 組織 - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - ポッド - アノテーション - fluentbit.io/exclude - mulesoft.com/resources - labels (表示ラベル) - app - 環境 - am-org-id - root-org-id - 組織 - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - リソース - ephemeral-storage (env.resources で設定されていないか、またはクラスターフレーバーが rtfc である場合) - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity (アフィニティ) - podAntiAffinity - サービス - labels (表示ラベル) - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization # Mule アプリケーション Kubernetes リソースのカスタマイズ Anypoint Runtime Fabric では、カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズできます。 `kubernetestemplate`​ リソースに ​`mule-application`​ という名前を付けます。テンプレートは 2 つの異なる名前空間で定義できます。 - アプリケーション名前空間 テンプレートは、指定された名前空間にデプロイされたすべての Mule アプリケーションに適用されます。 - Runtime Fabric エージェント名前空間 テンプレートは、指定された Runtime Fabric エージェントによって管理されるすべての Mule アプリケーションに適用されます。 `kubernetestemplate`​ リソースは、リソースが作成された後に作成される Mule アプリケーションデプロイメントにのみ適用されます。既存のデプロイメントには影響しません。​`kubernetestemplate`​ を作成または更新した後に Mule アプリケーションを再デプロイすると、テンプレートが適用されます。 `kubernetestemplate`​ リソースを使用すると、アプリケーションのポッド、デプロイメント、およびサービスオブジェクトで次の要素を設定できます。 - ポッド - [アノテーション](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [表示ラベル](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [ノードセレクター](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [アフィニティ](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [セキュリティコンテキスト](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [揮発ストレージ制限](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [許容範囲](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [トポロジー拡散制約](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [サービスアカウントトークン](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) - [環境変数](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) セキュリティコンテキストポッドの場合、使用するキーは ​`containerSecurityContext`​ です。 - デプロイメント - アノテーション - 表示ラベル - サービス - アノテーション - 表示ラベル Runtime Fabric ですでに定義されている設定要素は、テンプレートで定義した設定要素より優先されます。 テンプレートに設定できるキー要素の CRD を取得するには、次のコマンドを実行することで Kubernetes の仕様を取得します。 ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## [](#例)例 `ポッド`​、​`デプロイ`​、​`サービス`​オブジェクトでの​`表示ラベル`​の設定 ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` `ポッド`​オブジェクトの下にある ​`containerSecurityContext`​ のランタイムデフォルト ​`seccompProfile`​ の設定: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` 設定できるすべてのキーを示した別の例: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4gb nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" ``` CRD を使用して上書きできないキー要素: - デプロイメント - labels (表示ラベル) - 環境 - 組織 - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - ポッド - アノテーション - fluentbit.io/exclude - mulesoft.com/resources - labels (表示ラベル) - app - 環境 - am-org-id - root-org-id - 組織 - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - リソース - ephemeral-storage (env.resources で設定されていないか、またはクラスターフレーバーが rtfc である場合) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity (アフィニティ) - podAntiAffinity - サービス - labels (表示ラベル) - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## [](#enable-console-logging)コンソールログの有効化 デフォルトでは、Mule アプリケーションで他のソースを 1 つ以上ログに記録していることが検出されると、コンソールログは無効になります。このデフォルトの動作は Kubernetes テンプレートを使用して、クラスターレベルでルート Kubernetes テンプレートを使用するか、Mule アプリケーションの名前空間レベルで上書きできます。 Kubernetes テンプレートを使用してコンソールログを有効にするには、​`env`​ セクションの ​`ENABLE_CONSOLE_LOG`​ 変数を設定します。 ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ```
stdout​ を使用してログを転送するクラスターの場合、ログ転送機能に影響する可能性があります。Kubernetes チームと協力して、必要に応じてログ転送設定を調整し、ログの監視と収集を継続的に行うことができるようにしてください。
# Mule アプリケーション Kubernetes リソースのカスタマイズ Anypoint Runtime Fabric では、カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズできます。 `kubernetestemplate`​ リソースに ​`mule-application`​ という名前を付けます。テンプレートは 2 つの異なる名前空間で定義できます。 - アプリケーション名前空間 テンプレートは、指定された名前空間にデプロイされたすべての Mule アプリケーションに適用されます。 - Runtime Fabric エージェント名前空間 テンプレートは、指定された Runtime Fabric エージェントによって管理されるすべての Mule アプリケーションに適用されます。 `kubernetestemplate`​ リソースは、リソースが作成された後に作成される Mule アプリケーションデプロイメントにのみ適用されます。既存のデプロイメントには影響しません。​`kubernetestemplate`​ を作成または更新した後に Mule アプリケーションを再デプロイすると、テンプレートが適用されます。 `kubernetestemplate`​ リソースを使用すると、アプリケーションのポッド、デプロイメント、およびサービスオブジェクトで次の要素を設定できます。 - ポッド - [アノテーション](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [表示ラベル](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [ノードセレクター](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [アフィニティ](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [セキュリティコンテキスト](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [揮発ストレージ制限](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [許容範囲](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [トポロジー拡散制約](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [サービスアカウントトークン](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) 環境変数のカスタマイズはサポートされていません。 - [環境変数](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) 環境変数でサポートされるのは、​[「コンソールログの有効化」](#enable-console-logging)​と​[「サービスアカウントの無効化」](#disable-service-account)​に対応するキーワードのみです。 セキュリティコンテキストポッドの場合、使用するキーは ​`containerSecurityContext`​ です。 - デプロイメント - アノテーション - 表示ラベル - サービス - アノテーション - 表示ラベル Runtime Fabric ですでに定義されている設定要素は、テンプレートで定義した設定要素より優先されます。 テンプレートに設定できるキー要素の CRD を取得するには、次のコマンドを実行することで Kubernetes の仕様を取得します。 ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## [](#例)例 `ポッド`​、​`デプロイ`​、​`サービス`​オブジェクトでの​`表示ラベル`​の設定 ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` `ポッド`​オブジェクトの下にある ​`containerSecurityContext`​ のランタイムデフォルト ​`seccompProfile`​ の設定: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` 設定できるすべてのキーを示した別の例: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" ``` CRD を使用して上書きできないキー要素: - デプロイメント - labels (表示ラベル) - 環境 - 組織 - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - ポッド - アノテーション - fluentbit.io/exclude - mulesoft.com/resources - labels (表示ラベル) - app - 環境 - am-org-id - root-org-id - 組織 - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - リソース - ephemeral-storage (env.resources で設定されていないか、またはクラスターフレーバーが rtfc である場合) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity (アフィニティ) - podAntiAffinity - サービス - labels (表示ラベル) - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## [](#enable-console-logging)コンソールログの有効化 デフォルトでは、Mule アプリケーションで他のソースを 1 つ以上ログに記録していることが検出されると、コンソールログは無効になります。このデフォルトの動作は Kubernetes テンプレートを使用して、クラスターレベルでルート Kubernetes テンプレートを使用するか、Mule アプリケーションの名前空間レベルで上書きできます。 Kubernetes テンプレートを使用してコンソールログを有効にするには、​`env`​ セクションの ​`ENABLE_CONSOLE_LOG`​ 変数を設定します。 ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ```
stdout​ を使用してログを転送するクラスターの場合、ログ転送機能に影響する可能性があります。Kubernetes チームと協力して、必要に応じてログ転送設定を調整し、ログの監視と収集を継続的に行うことができるようにしてください。
Anypoint Monitoring (AMLogFwdingAppender を含む) のサイドカーコンテナを使用する場合、コンソールログも無効化されます。 ## [](#disable-service-account)アプリケーションごとのサービスアカウントの無効化 デフォルトでは、Mule アプリケーションデプロイメントごとに [サービスアカウント](https://kubernetes.io/docs/concepts/security/service-accounts/)​が作成されます。このデフォルトの動作は Kubernetes テンプレートを使用して、クラスターレベルでルート Kubernetes テンプレートを使用するか、Mule アプリケーションの名前空間レベルで上書きできます。 無効になっている場合、Mule アプリケーションデプロイメントで [デフォルトのサービスアカウント](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts)​が使用されます。 Kubernetes テンプレートを使用して Mule アプリケーションごとのサービスアカウントの作成を無効にするには、​`env`​ セクションの ​`DISABLE_PER_APP_SA`​ 変数を設定します。 ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` # Mule アプリケーション Kubernetes リソースのカスタマイズ Anypoint Runtime Fabric では、カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズできます。 `kubernetestemplate`​ リソースに ​`mule-application`​ という名前を付けます。テンプレートは 2 つの異なる名前空間で定義できます。 - アプリケーション名前空間 テンプレートは、指定された名前空間にデプロイされたすべての Mule アプリケーションに適用されます。 - Runtime Fabric エージェント名前空間 テンプレートは、指定された Runtime Fabric エージェントによって管理されるすべての Mule アプリケーションに適用されます。 `kubernetestemplate`​ リソースは、リソースが作成された後に作成される Mule アプリケーションデプロイメントにのみ適用されます。既存のデプロイメントには影響しません。​`kubernetestemplate`​ を作成または更新した後に Mule アプリケーションを再デプロイすると、テンプレートが適用されます。 `kubernetestemplate`​ リソースを使用すると、アプリケーションのポッド、デプロイメント、およびサービスオブジェクトで次の要素を設定できます。 - ポッド - [アノテーション](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) - [表示ラベル](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) - [ノードセレクター](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [アフィニティ](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/) - [セキュリティコンテキスト](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) - [揮発ストレージ制限](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) - [許容範囲](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) - [トポロジー拡散制約](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) - [サービスアカウントトークン](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting/) 環境変数のカスタマイズはサポートされていません。 - [環境変数](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) 環境変数でサポートされるのは、​[「コンソールログの有効化」](#enable-console-logging)​と​[「サービスアカウントの無効化」](#disable-service-account)​に対応するキーワードのみです。 セキュリティコンテキストポッドの場合、使用するキーは ​`containerSecurityContext`​ です。 - デプロイメント - アノテーション - 表示ラベル - サービス - アノテーション - 表示ラベル Runtime Fabric ですでに定義されている設定要素は、テンプレートで定義した設定要素より優先されます。 テンプレートに設定できるキー要素の CRD を取得するには、次のコマンドを実行することで Kubernetes の仕様を取得します。 ```copy kubectl get crd kubernetestemplates.rtf.mulesoft.com -o yaml ``` ## [](#例)例 `ポッド`​、​`デプロイ`​、​`サービス`​オブジェクトでの​`表示ラベル`​の設定 ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: deployment: metadata: labels: deploymentLabel: value service: metadata: labels: serviceLabel: value pod: metadata: labels: podLabel: value ``` `ポッド`​オブジェクトの下にある ​`containerSecurityContext`​ のランタイムデフォルト ​`seccompProfile`​ の設定: ```copy apiVersion: rtf.mulesoft.com/v1 kind: KubernetesTemplate metadata: name: mule-application namespace: rtf spec: pod: containerSecurityContext: seccompProfile: type: RuntimeDefault ``` 設定できるすべてのキーを示した別の例: ```copy apiVersion: "rtf.mulesoft.com/v1" kind: KubernetesTemplate metadata: name: mule-application namespace: rtf labels: spec: deployment: metadata: labels: annotations: service: metadata: labels: annotations: pod: metadata: labels: annotations: env: ENABLE_CONSOLE_LOG: "true" automountServiceAccountToken: true containerSecurityContext: seccompProfile: type: RuntimeDefault tolerations: - key: "example-key" operator: "Exists" effect: "NoSchedule" ephemeralStorageLimit: 4Gi nodeSelector: region: us-east affinity: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" ``` CRD を使用して上書きできないキー要素: - デプロイメント - labels (表示ラベル) - 環境 - 組織 - type - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtfc.mulesoft.com/egress-ruleset (if set in deployment values) - rtf.mulesoft.com/desiredStatus - rtf.mulesoft.com/replicas - rtf.mulesoft.com/version - ポッド - アノテーション - fluentbit.io/exclude - mulesoft.com/resources - labels (表示ラベル) - app - 環境 - am-org-id - root-org-id - 組織 - rtf.mulesoft.com/id - rtf.mulesoft.com/generation - type - rtf.mulesoft.com/disableAmLogForwarding - name - リソース - ephemeral-storage (env.resources で設定されていないか、またはクラスターフレーバーが rtfc である場合) - ServiceAccountToken - automountServiceAccountToken - SecurityContext - runAsUser - runAsGroup - allowPrivilageEscalation - capabilities - privileged - readOnlyRootFilesystem - NodeSelector - kubernetes.io/os - kubernetes.io/arch - beta.kubernetes.io/os - beta.kubernetes.io/arch - RTF.DeploymentNodeSelector - Affinity (アフィニティ) - podAntiAffinity - サービス - labels (表示ラベル) - ingress.rtf.mulesoft.com/bind - rtf.mulesoft.com/id - rtf.mulesoft.com/version - rtf.mulesoft.com/agentNamespace - アノテーション - rtf.mulesoft.com/merge-policy - rtf.mulesoft.com/environment - rtf.mulesoft.com/organization ## [](#enable-console-logging)コンソールログの有効化 デフォルトでは、Mule アプリケーションで他のソースを 1 つ以上ログに記録していることが検出されると、コンソールログは無効になります。このデフォルトの動作は Kubernetes テンプレートを使用して、クラスターレベルでルート Kubernetes テンプレートを使用するか、Mule アプリケーションの名前空間レベルで上書きできます。 Kubernetes テンプレートを使用してコンソールログを有効にするには、​`env`​ セクションの ​`ENABLE_CONSOLE_LOG`​ 変数を設定します。 ```copy pod: env: ENABLE_CONSOLE_LOG: "true" ```
stdout​ を使用してログを転送するクラスターの場合、ログ転送機能に影響する可能性があります。Kubernetes チームと協力して、必要に応じてログ転送設定を調整し、ログの監視と収集を継続的に行うことができるようにしてください。
Anypoint Monitoring (AMLogFwdingAppender を含む) のサイドカーコンテナを使用する場合、コンソールログも無効化されます。 ## [](#disable-service-account)アプリケーションごとのサービスアカウントの無効化 デフォルトでは、Mule アプリケーションデプロイメントごとに [サービスアカウント](https://kubernetes.io/docs/concepts/security/service-accounts/)​が作成されます。このデフォルトの動作は Kubernetes テンプレートを使用して、クラスターレベルでルート Kubernetes テンプレートを使用するか、Mule アプリケーションの名前空間レベルで上書きできます。 無効になっている場合、Mule アプリケーションデプロイメントで [デフォルトのサービスアカウント](https://kubernetes.io/docs/concepts/security/service-accounts/#default-service-accounts)​が使用されます。 Kubernetes テンプレートを使用して Mule アプリケーションごとのサービスアカウントの作成を無効にするには、​`env`​ セクションの ​`DISABLE_PER_APP_SA`​ 変数を設定します。 ```copy pod: env: DISABLE_PER_APP_SA: "true" ``` # Mule アプリケーションでの FIPS 140-2 の有効化 Runtime Fabric は、FIPS 140-2 コンプライアンスモードでアプリケーションコンテナを実行するように設定できます。 以降の手順では、読者が [FIPS 140-2](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。 ## [](#fips-140-2-コンプライアンスモードを有効化する)FIPS 140-2 コンプライアンスモードを有効化する 1. `kubectl`​ を使用して、​`FIPS_ENABLED`​ キーを ​`true`​ に設定して ​`rtf`​ 名前空間で ​`custom-properties`​ シークレットをパッチ適用します。 ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` この変更を行った後で、新規アプリケーションをデプロイするか既存のアプリケーションを再起動すると、そのコンテナが FIPS 140-2 コンプライアンスモードで実行されます。 2. アプリケーションが FIPS 140-2 コンプライアンスモードで実行されていることを確認するには、アプリケーションの起動ログを確認します。 ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` # Mule アプリケーションでの FIPS 140-2 の有効化 Runtime Fabric は、FIPS 140-2 コンプライアンスモードでアプリケーションコンテナを実行するように設定できます。 以降の手順では、読者が [FIPS 140-2](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。 ## [](#fips-140-2-コンプライアンスモードを有効化する)FIPS 140-2 コンプライアンスモードを有効化する 1. `kubectl`​ を使用して、​`FIPS_ENABLED`​ キーを ​`true`​ に設定して ​`rtf`​ 名前空間で ​`custom-properties`​ シークレットをパッチ適用します。 ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` この変更を行った後で、新規アプリケーションをデプロイするか既存のアプリケーションを再起動すると、そのコンテナが FIPS 140-2 コンプライアンスモードで実行されます。 2. アプリケーションが FIPS 140-2 コンプライアンスモードで実行されていることを確認するには、アプリケーションの起動ログを確認します。 ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` # Mule アプリケーションでの FIPS 140-2 の有効化 FIPS 140-2 コンプライアンスモードで実行されるように Mule アプリケーションコンテナを設定できます。 以降の手順では、読者が [FIPS 140-2](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。 ## [](#fips-140-2-コンプライアンスモードを有効化する)FIPS 140-2 コンプライアンスモードを有効化する 1. `kubectl`​ を使用して、​`FIPS_ENABLED`​ キーを ​`true`​ に設定して ​`rtf`​ 名前空間で ​`custom-properties`​ シークレットをパッチ適用します。 ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` この変更を行った後で、新規アプリケーションをデプロイするか既存のアプリケーションを再起動すると、そのコンテナが FIPS 140-2 コンプライアンスモードで実行されます。 2. アプリケーションが FIPS 140-2 コンプライアンスモードで実行されていることを確認するには、アプリケーションの起動ログを確認します。 ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` # Mule アプリケーションでの FIPS 140-2 の有効化 FIPS 140-2 コンプライアンスモードで実行されるように Mule アプリケーションコンテナを設定できます。 以降の手順では、読者が [FIPS 140-2](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。 ## [](#fips-140-2-コンプライアンスモードを有効化する)FIPS 140-2 コンプライアンスモードを有効化する 1. `kubectl`​ を使用して、​`FIPS_ENABLED`​ キーを ​`true`​ に設定して ​`rtf`​ 名前空間で ​`custom-properties`​ シークレットをパッチ適用します。 ```copy # kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS_ENABLED": "true"}}' ``` この変更を行った後で、新規アプリケーションをデプロイするか既存のアプリケーションを再起動すると、そのコンテナが FIPS 140-2 コンプライアンスモードで実行されます。 2. アプリケーションが FIPS 140-2 コンプライアンスモードで実行されていることを確認するには、アプリケーションの起動ログを確認します。 ```copy # kubectl logs -n -c app -f| grep -i fips Running in FIPS mode * Security model: fips140-2 * * - mule.security.model = fips140-2 ``` # Mule アプリケーションのスケジュールの管理 Anypoint Runtime Manager を使用して、実行中のアプリケーションを変更することなく、デプロイされたアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 たとえば、アプリケーションのうちの 1 つがメンテナンス中である間に、スケジュールされたジョブを無効にすることができます。 **\[Schedules (スケジュール)\]**​ タブでは以下を行うことができます。 - 実行中のアプリケーションでスケジュールを表示する。 - アプリケーションでスケジュールを変更する。 - スケジュールを変更せずに、スケジュールされたジョブを直ちに実行する。 - フローのスケジュールを無効または有効にする。 定期的な間隔でトリガーする​_一定間隔_​、または指定した Cron 式に基づいた日時にトリガーする ​_Cron_​ として、Scheduler コンポーネントの種類を設定します。
スケジュールタイプを (一定間隔から Cron、またはその逆に) 変更するには、アプリケーションを更新して再デプロイする必要があります。 デプロイされたアプリケーションのスケジュールタイプを変更することはできません。
この機能を使用するための必要な最小 Mule Runtime Engine バージョンは 4.1.2 以降であり、最小 Runtime Fabric Agent バージョンは 2.0.0 以降です。
## [](#design-schedule)スケジュールの設計に関する考慮事項 スケジュールを設計するときには、次の点を考慮してください。 - Runtime Fabric スケジューラーは、毎回の実行時にジョブ設定を読み取ります。 スケジューラー設定を更新した場合、次回スケジューラーが実行されるときに変更が有効になります。 - スケジュールを変更すると、アプリケーションが再デプロイされます。 - アプリケーションが実行されていないためにスケジュールされたジョブがトリガーされない場合は、アプリケーションが再起動すると、Runtime Fabric はすぐにジョブをトリガーします。 - スケジュールは、スケジューラーの定義されたタイムゾーンに基づきます。 - 複数のレプリカがあるアプリケーションの場合、Runtime Fabric はスケジュールされたジョブをすべてのレプリカで実行します。 **\[Run (実行)\]**​ をクリックしてスケジュールされたジョブを直ちに実行する場合、スケジューラーは 1 つのレプリカで実行されます。 Runtime Fabric は、レプリカ全体に複数の同時スケジューラーを分散します。 - スクリプトを使用して Runtime Fabric のスケジュールを管理することはできません。 Runtime Fabric のスケジュールを管理するには、​**\[Schedules (スケジュール)\]**​ タブまたは Runtime Fabric API を使用してください。 - フロー名には、文字、数字、ハイフン (​`-`​)、アンダースコア (​`_`​)、ピリオド (​`.`​) のみを含めることができます。文字 ​`/`​、​`[`​、​`]`​、​`{`​、​`}`​、​`#`​ は無効です。 - プレースホルダーのあるスケジューラーを使用してスケジュールを作成する場合、スケジュールの作成時に表示される値は、プレースホルダーがいつ検出されるかによって異なります。次に例を示します。 - アプリケーションがデプロイされる前に値が使用可能な場合、その値が表示されます。 - 値がデプロイメントの前に使用可能で、デプロイメントのプロパティに依存する場合、推定値が表示されます。 - 値がデプロイメント時に提供されるプレースホルダー (​`${cronExpression}`​ など) である場合、プレースホルダーの正確な値はユーザーインターフェースに表示されません。 - Runtime Fabric ではデフォルト値の ​`60000`​ が使用されます。 - スケジューラーに変更を加えた場合は、アプリケーションを Exchange に再アップロードして、スケジューラーが期待どおりに動作するようにする必要があります。 ## [](#始める前に)始める前に Runtime Manager のスケジュール機能を使用するには、Anypoint Studio 7.13 を使用して 1 つ以上の Scheduler 要素を含むアプリケーションをデプロイします。 ![Anypoint Studio キャンバスの Scheduler コンポーネント](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/ch2-scheduler-studio.png) アプリケーションをデプロイしたら、Runtime Manager でスケジュールを管理できます。 アプリケーションが実行されている必要はありません。 Runtime Manager UI にスケジュールを表示するには、Mule Maven Facade v3 を使用して Maven 経由で Runtime Fabric にデプロイしてください。 ## [](#runtime-manager-でアプリケーションを表示して管理する)Runtime Manager でアプリケーションを表示して管理する アプリケーションを Runtime Fabric にデプロイしたら、Runtime Manager で Scheduler 要素を表示して管理します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 Runtime Manager では、Scheduler 要素がアプリケーションに表示される順序でリストされます。 ![「Schedules (スケジュール)」 ページの (1) フロー名と (2) 頻度リンク。](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/ch2-scheduler-rtm.png) - **\[Name (名前)\]**​ 列には、Scheduler 要素を含むフローの名前 (1) が表示されます。 - **\[Schedule (スケジュール)\]**​ 列の頻度リンク (2) には、要素のスケジュールが表示されます。 4. ジョブが開始および終了した日時の詳細を確認する場合は、ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 ![ナビゲーションメニューの \[Logs (ログ)\] オプション。](_images/ch2-logs-rtm.png) 5. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 表示されるスケジュールエディターは、スケジュールタイプによって異なります。 - [一定間隔](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-fixed-frequency-schedule)一定間隔スケジュールを変更する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![一定間隔スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/ch2-scheduler-fixed-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 ![一定間隔スケジュール設定](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/ch2-scheduler-editor-fixed.png) 頻度には、ミリ秒、秒、分、時間、または日を指定できます。 コール間の最小の推奨頻度は 10 秒です。 Unresolved include directive in modules/ROOT/pages/manage-schedules.adoc - include::cloudhub::partial$ch-app-schedule-freq.adoc\[\] 6. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-cron-schedule)Cron スケジュールを変更する Cron 式を使用すると、「毎週金曜日の午前 9 時 00 分から午前 10 時 00 分まで 5 分おき」といった複雑なスケジュール頻度を作成できます。 Cron スケジュールタイプの頻度を変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![Cron スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/ch2-scheduler-cron-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ (1) チェックボックスをオフにしてスケジュールを無効にします。 ![(1) \[Enabled (有効)\] オプションと (2) \[Quick reference (クイックリファレンス)\] リンクを含む Cron スケジュール設定](_images/ch2-scheduler-editor-cron.png) 6. スケジュールエディターで ​**\[Quick reference (クイックリファレンス)\]**​ (2) をクリックして、必須項目と許可される値のテーブルを展開するか折りたたみます。 この例の Cron 式は、10 秒間隔のスケジュールを設定しています。 Cron トリガーの作成についての詳細は、次の方法で確認できます。 1. [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation)​を参照します。 2. バージョンを選択し、​**\[Documentation (ドキュメント)\] > \[User’s Guide (ユーザーガイド)\] > \[Tutorial (チュートリアル)\]**​ をクリックして、​**\[CronTrigger\]**​ レッスンをクリックします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#run-immediately)スケジュールされたジョブの即時実行 毎晩実行するジョブを今すぐデバッグする場合は、アプリケーションでスケジュールを更新しなくても、実行中のジョブをトリガーできます。実行中のスケジューラーのインスタンス間でジョブをトリガーすると、指定された期間のタイマーがリセットされます。
スケジュールされたジョブを直ちに実行する場合、複数のレプリカがあるアプリケーションの場合でも、スケジューラーは 1 つのレプリカで実行されます。
スケジュールを上書きしてジョブを直ちに実行する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Run (実行)\]**​ をクリックします。 ## [](#disable-enable-scheduler)Scheduler 要素の無効化または有効化 接続しているアプリケーションがメンテナンス中である間に、スケジュールされたジョブを無効にし、メンテナンスの完了後に再度有効にすることができます。 スケジューラーを再度有効にするまで、Runtime Fabric はスケジュールされたジョブを実行しません。 **既知の問題**​: スケジューラーを無効にしても、スケジューラーはアプリケーションの起動時に実行されます。スケジューラーが実行されないようにする場合は、Anypoint Studio を使用してアプリケーションで ​`startdelay`​ プロパティを 5 秒に設定します。 Scheduler 要素を無効にする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Disable (無効化)\]**​ をクリックします。 スケジュールエディターで ​**\[Enabled (有効)\]**​ を選択解除または選択して、スケジュールを無効または有効にすることもできます。 ![スケジュールエディターので \[Enabled (有効)\] 切り替え](_images/ch2-scheduler-enable.png) ## [](#関連情報)関連情報 - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation) - [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) # Mule アプリケーションのスケジュールの管理 Anypoint Runtime Manager を使用して、実行中のアプリケーションを変更することなく、デプロイされたアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 たとえば、アプリケーションのうちの 1 つがメンテナンス中である間に、スケジュールされたジョブを無効にすることができます。 **\[Schedules (スケジュール)\]**​ タブでは以下を行うことができます。 - 実行中のアプリケーションでスケジュールを表示する。 - アプリケーションでスケジュールを変更する。 - スケジュールを変更せずに、スケジュールされたジョブを直ちに実行する。 - フローのスケジュールを無効または有効にする。 定期的な間隔でトリガーする​_一定間隔_​、または指定した Cron 式に基づいた日時にトリガーする ​_Cron_​ として、Scheduler コンポーネントの種類を設定します。
スケジュールタイプを (一定間隔から Cron、またはその逆に) 変更するには、アプリケーションを更新して再デプロイする必要があります。 デプロイされたアプリケーションのスケジュールタイプを変更することはできません。
この機能を使用するための必要な最小 Mule Runtime Engine バージョンは 4.1.2 以降であり、最小 Runtime Fabric Agent バージョンは 2.0.0 以降です。
## [](#design-schedule)スケジュールの設計に関する考慮事項 スケジュールを設計するときには、次の点を考慮してください。 - Runtime Fabric スケジューラーは、毎回の実行時にジョブ設定を読み取ります。 スケジューラー設定を更新した場合、次回スケジューラーが実行されるときに変更が有効になります。 - スケジュールを変更すると、アプリケーションが再デプロイされます。 - アプリケーションが実行されていないためにスケジュールされたジョブがトリガーされない場合は、アプリケーションが再起動すると、Runtime Fabric はすぐにジョブをトリガーします。 - スケジュールは、スケジューラーの定義されたタイムゾーンに基づきます。 - 複数のレプリカがあるアプリケーションの場合、Runtime Fabric はスケジュールされたジョブをすべてのレプリカで実行します。 **\[Run (実行)\]**​ をクリックしてスケジュールされたジョブを直ちに実行する場合、スケジューラーは 1 つのレプリカで実行されます。 Runtime Fabric は、レプリカ全体に複数の同時スケジューラーを分散します。 - スクリプトを使用して Runtime Fabric のスケジュールを管理することはできません。 Runtime Fabric のスケジュールを管理するには、​**\[Schedules (スケジュール)\]**​ タブまたは Runtime Fabric API を使用してください。 - フロー名には、文字、数字、ハイフン (​`-`​)、アンダースコア (​`_`​)、ピリオド (​`.`​) のみを含めることができます。文字 ​`/`​、​`[`​、​`]`​、​`{`​、​`}`​、​`#`​ は無効です。 - プレースホルダーのあるスケジューラーを使用してスケジュールを作成する場合、スケジュールの作成時に表示される値は、プレースホルダーがいつ検出されるかによって異なります。次に例を示します。 - アプリケーションがデプロイされる前に値が使用可能な場合、その値が表示されます。 - 値がデプロイメントの前に使用可能で、デプロイメントのプロパティに依存する場合、推定値が表示されます。 - 値がデプロイメント時に提供されるプレースホルダー (​`${cronExpression}`​ など) である場合、プレースホルダーの正確な値はユーザーインターフェースに表示されません。 - Runtime Fabric ではデフォルト値の ​`60000`​ が使用されます。 - スケジューラーに変更を加えた場合は、アプリケーションを Exchange に再アップロードして、スケジューラーが期待どおりに動作するようにする必要があります。 ## [](#始める前に)始める前に Runtime Manager のスケジュール機能を使用するには、Anypoint Studio 7.13 を使用して 1 つ以上の Scheduler 要素を含むアプリケーションをデプロイします。 ![Anypoint Studio キャンバスの Scheduler コンポーネント](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/ch2-scheduler-studio.png) アプリケーションをデプロイしたら、Runtime Manager でスケジュールを管理できます。 アプリケーションが実行されている必要はありません。 Runtime Manager UI にスケジュールを表示するには、Mule Maven Facade v3 を使用して Maven 経由で Runtime Fabric にデプロイしてください。 ## [](#runtime-manager-でアプリケーションを表示して管理する)Runtime Manager でアプリケーションを表示して管理する アプリケーションを Runtime Fabric にデプロイしたら、Runtime Manager で Scheduler 要素を表示して管理します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 Runtime Manager では、Scheduler 要素がアプリケーションに表示される順序でリストされます。 ![「Schedules (スケジュール)」 ページの (1) フロー名と (2) 頻度リンク。](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/ch2-scheduler-rtm.png) - **\[Name (名前)\]**​ 列には、Scheduler 要素を含むフローの名前 (1) が表示されます。 - **\[Schedule (スケジュール)\]**​ 列の頻度リンク (2) には、要素のスケジュールが表示されます。 4. ジョブが開始および終了した日時の詳細を確認する場合は、ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 ![ナビゲーションメニューの \[Logs (ログ)\] オプション。](_images/ch2-logs-rtm.png) 5. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 表示されるスケジュールエディターは、スケジュールタイプによって異なります。 - [一定間隔](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-fixed-frequency-schedule)一定間隔スケジュールを変更する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![一定間隔スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/ch2-scheduler-fixed-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 ![一定間隔スケジュール設定](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/ch2-scheduler-editor-fixed.png) 頻度には、ミリ秒、秒、分、時間、または日を指定できます。 コール間の最小の推奨頻度は 10 秒です。 Unresolved include directive in modules/ROOT/pages/manage-schedules.adoc - include::cloudhub::partial$ch-app-schedule-freq.adoc\[\] 6. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-cron-schedule)Cron スケジュールを変更する Cron 式を使用すると、「毎週金曜日の午前 9 時 00 分から午前 10 時 00 分まで 5 分おき」といった複雑なスケジュール頻度を作成できます。 Cron スケジュールタイプの頻度を変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![Cron スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/ch2-scheduler-cron-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ (1) チェックボックスをオフにしてスケジュールを無効にします。 ![(1) \[Enabled (有効)\] オプションと (2) \[Quick reference (クイックリファレンス)\] リンクを含む Cron スケジュール設定](_images/ch2-scheduler-editor-cron.png) 6. スケジュールエディターで ​**\[Quick reference (クイックリファレンス)\]**​ (2) をクリックして、必須項目と許可される値のテーブルを展開するか折りたたみます。 この例の Cron 式は、10 秒間隔のスケジュールを設定しています。 Cron トリガーの作成についての詳細は、次の方法で確認できます。 1. [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation)​を参照します。 2. バージョンを選択し、​**\[Documentation (ドキュメント)\] > \[User’s Guide (ユーザーガイド)\] > \[Tutorial (チュートリアル)\]**​ をクリックして、​**\[CronTrigger\]**​ レッスンをクリックします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#run-immediately)スケジュールされたジョブの即時実行 毎晩実行するジョブを今すぐデバッグする場合は、アプリケーションでスケジュールを更新しなくても、実行中のジョブをトリガーできます。実行中のスケジューラーのインスタンス間でジョブをトリガーすると、指定された期間のタイマーがリセットされます。
スケジュールされたジョブを直ちに実行する場合、複数のレプリカがあるアプリケーションの場合でも、スケジューラーは 1 つのレプリカで実行されます。
スケジュールを上書きしてジョブを直ちに実行する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Run (実行)\]**​ をクリックします。 ## [](#disable-enable-scheduler)Scheduler 要素の無効化または有効化 接続しているアプリケーションがメンテナンス中である間に、スケジュールされたジョブを無効にし、メンテナンスの完了後に再度有効にすることができます。 スケジューラーを再度有効にするまで、Runtime Fabric はスケジュールされたジョブを実行しません。 **既知の問題**​: スケジューラーを無効にしても、スケジューラーはアプリケーションの起動時に実行されます。スケジューラーが実行されないようにする場合は、Anypoint Studio を使用してアプリケーションで ​`startdelay`​ プロパティを 5 秒に設定します。 Scheduler 要素を無効にする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Disable (無効化)\]**​ をクリックします。 スケジュールエディターで ​**\[Enabled (有効)\]**​ を選択解除または選択して、スケジュールを無効または有効にすることもできます。 ![スケジュールエディターので \[Enabled (有効)\] 切り替え](_images/ch2-scheduler-enable.png) ## [](#関連情報)関連情報 - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation) - [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) # Mule アプリケーションのスケジュールの管理 Anypoint Runtime Manager を使用して、実行中のアプリケーションを変更することなく、デプロイされたアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 たとえば、アプリケーションのうちの 1 つがメンテナンス中である間に、スケジュールされたジョブを無効にすることができます。 **\[Schedules (スケジュール)\]**​ タブでは以下を行うことができます。 - 実行中のアプリケーションでスケジュールを表示する。 - アプリケーションでスケジュールを変更する。 - スケジュールを変更せずに、スケジュールされたジョブを直ちに実行する。 - フローのスケジュールを無効または有効にする。 定期的な間隔でトリガーする​_一定間隔_​、または指定した Cron 式に基づいた日時にトリガーする ​_Cron_​ として、Scheduler コンポーネントの種類を設定します。
スケジュールタイプを (一定間隔から Cron、またはその逆に) 変更するには、アプリケーションを更新して再デプロイする必要があります。 デプロイされたアプリケーションのスケジュールタイプを変更することはできません。
この機能を使用するための必要な最小 Mule Runtime Engine バージョンは 4.1.2 以降であり、最小 Runtime Fabric Agent バージョンは 2.0.0 以降です。
## [](#design-schedule)スケジュールの設計に関する考慮事項 スケジュールを設計するときには、次の点を考慮してください。 - Runtime Fabric スケジューラーは、毎回の実行時にジョブ設定を読み取ります。 スケジューラー設定を更新した場合、次回スケジューラーが実行されるときに変更が有効になります。 - スケジュールを変更すると、アプリケーションが再デプロイされます。 - アプリケーションが実行されていないためにスケジュールされたジョブがトリガーされない場合は、アプリケーションが再起動すると、Runtime Fabric はすぐにジョブをトリガーします。 - スケジュールは、スケジューラーの定義されたタイムゾーンに基づきます。 - 複数のレプリカがあるアプリケーションの場合、Runtime Fabric はスケジュールされたジョブをすべてのレプリカで実行します。 **\[Run (実行)\]**​ をクリックしてスケジュールされたジョブを直ちに実行する場合、スケジューラーは 1 つのレプリカで実行されます。 Runtime Fabric は、レプリカ全体に複数の同時スケジューラーを分散します。 - スクリプトを使用して Runtime Fabric のスケジュールを管理することはできません。 Runtime Fabric のスケジュールを管理するには、​**\[Schedules (スケジュール)\]**​ タブまたは Runtime Fabric API を使用してください。 - フロー名には、文字、数字、ハイフン (​`-`​)、アンダースコア (​`_`​)、ピリオド (​`.`​) のみを含めることができます。文字 ​`/`​、​`[`​、​`]`​、​`{`​、​`}`​、​`#`​ は無効です。 - プレースホルダーのあるスケジューラーを使用してスケジュールを作成する場合、スケジュールの作成時に表示される値は、プレースホルダーがいつ検出されるかによって異なります。次に例を示します。 - アプリケーションがデプロイされる前に値が使用可能な場合、その値が表示されます。 - 値がデプロイメントの前に使用可能で、デプロイメントのプロパティに依存する場合、推定値が表示されます。 - 値がデプロイメント時に提供されるプレースホルダー (​`${cronExpression}`​ など) である場合、プレースホルダーの正確な値はユーザーインターフェースに表示されません。 - Runtime Fabric ではデフォルト値の ​`60000`​ が使用されます。 - スケジューラーに変更を加えた場合は、アプリケーションを Exchange に再アップロードして、スケジューラーが期待どおりに動作するようにする必要があります。 ## [](#始める前に)始める前に Runtime Manager のスケジュール機能を使用するには、Anypoint Studio 7.13 を使用して 1 つ以上の Scheduler 要素を含むアプリケーションをデプロイします。 ![Anypoint Studio キャンバスの Scheduler コンポーネント](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ch2-scheduler-studio.png) アプリケーションをデプロイしたら、Runtime Manager でスケジュールを管理できます。 アプリケーションが実行されている必要はありません。 Runtime Manager UI にスケジュールを表示するには、Mule Maven Facade v3 を使用して Maven 経由で Runtime Fabric にデプロイしてください。 ## [](#runtime-manager-でアプリケーションを表示して管理する)Runtime Manager でアプリケーションを表示して管理する アプリケーションを Runtime Fabric にデプロイしたら、Runtime Manager で Scheduler 要素を表示して管理します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 Runtime Manager では、Scheduler 要素がアプリケーションに表示される順序でリストされます。 ![「Schedules (スケジュール)」 ページの (1) フロー名と (2) 頻度リンク。](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ch2-scheduler-rtm.png) - **\[Name (名前)\]**​ 列には、Scheduler 要素を含むフローの名前 (1) が表示されます。 - **\[Schedule (スケジュール)\]**​ 列の頻度リンク (2) には、要素のスケジュールが表示されます。 4. ジョブが開始および終了した日時の詳細を確認する場合は、ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 ![ナビゲーションメニューの \[Logs (ログ)\] オプション。](_images/ch2-logs-rtm.png) 5. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 表示されるスケジュールエディターは、スケジュールタイプによって異なります。 - [一定間隔](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-fixed-frequency-schedule)一定間隔スケジュールを変更する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![一定間隔スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ch2-scheduler-fixed-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 ![一定間隔スケジュール設定](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ch2-scheduler-editor-fixed.png) 頻度には、ミリ秒、秒、分、時間、または日を指定できます。 コール間の最小の推奨頻度は 10 秒です。 Unresolved include directive in modules/ROOT/pages/manage-schedules.adoc - include::cloudhub::partial$ch-app-schedule-freq.adoc\[\] 6. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-cron-schedule)Cron スケジュールを変更する Cron 式を使用すると、「毎週金曜日の午前 9 時 00 分から午前 10 時 00 分まで 5 分おき」といった複雑なスケジュール頻度を作成できます。 Cron スケジュールタイプの頻度を変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![Cron スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ch2-scheduler-cron-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ (1) チェックボックスをオフにしてスケジュールを無効にします。 ![(1) \[Enabled (有効)\] オプションと (2) \[Quick reference (クイックリファレンス)\] リンクを含む Cron スケジュール設定](_images/ch2-scheduler-editor-cron.png) 6. スケジュールエディターで ​**\[Quick reference (クイックリファレンス)\]**​ (2) をクリックして、必須項目と許可される値のテーブルを展開するか折りたたみます。 この例の Cron 式は、10 秒間隔のスケジュールを設定しています。 Cron トリガーの作成についての詳細は、次の方法で確認できます。 1. [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation)​を参照します。 2. バージョンを選択し、​**\[Documentation (ドキュメント)\] > \[User’s Guide (ユーザーガイド)\] > \[Tutorial (チュートリアル)\]**​ をクリックして、​**\[CronTrigger\]**​ レッスンをクリックします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#run-immediately)スケジュールされたジョブの即時実行 毎晩実行するジョブを今すぐデバッグする場合は、アプリケーションでスケジュールを更新しなくても、実行中のジョブをトリガーできます。実行中のスケジューラーのインスタンス間でジョブをトリガーすると、指定された期間のタイマーがリセットされます。
スケジュールされたジョブを直ちに実行する場合、複数のレプリカがあるアプリケーションの場合でも、スケジューラーは 1 つのレプリカで実行されます。
スケジュールを上書きしてジョブを直ちに実行する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Run (実行)\]**​ をクリックします。 ## [](#disable-enable-scheduler)Scheduler 要素の無効化または有効化 接続しているアプリケーションがメンテナンス中である間に、スケジュールされたジョブを無効にし、メンテナンスの完了後に再度有効にすることができます。 スケジューラーを再度有効にするまで、Runtime Fabric はスケジュールされたジョブを実行しません。 **既知の問題**​: スケジューラーを無効にしても、スケジューラーはアプリケーションの起動時に実行されます。スケジューラーが実行されないようにする場合は、Anypoint Studio を使用してアプリケーションで ​`startdelay`​ プロパティを 5 秒に設定します。 Scheduler 要素を無効にする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Disable (無効化)\]**​ をクリックします。 スケジュールエディターで ​**\[Enabled (有効)\]**​ を選択解除または選択して、スケジュールを無効または有効にすることもできます。 ![スケジュールエディターので \[Enabled (有効)\] 切り替え](_images/ch2-scheduler-enable.png) ## [](#関連情報)関連情報 - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation) - [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) # Mule ライセンスキーの置き換え Mule ライセンスの期限が切れた場合、Mule ライセンスキーを置き換える必要があります。また、インストール中に正しくないライセンスキーを入力した場合もこの手順を使用します。 インストールを開始するために使用したコントローラーノードで次の手順を実行します。Azure および AWS インストールでは、このノードの名前はデフォルトで ​`rtf-controller-1`​ に設定されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の Mule ライセンスキーを置き換えるには、​`rtfctl`​ ユーティリティが必要です。続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​する手順を実行します。 VM/ベアメタルの Runtime Fabric の場合、​`rtfctl`​ バイナリは ​`/opt/anypoint/runtimefabric/`​ ディレクトリにあります。現在の作業ディレクトリも ​`/opt/anypoint/runtimefabric/`​ であることを確認します。 自己管理型 Kubernetes の Runtime Fabric の場合、​`rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 ## [](#手順)手順 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -b0 license.lic) - Unix では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -w0 license.lic) - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 $BASE64\_ENCODED\_LICENSE=\[convert\]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) 2. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、​`rtfctl`​ ユーティリティをライセンスキーの Base64 値と共に使用します。​`rtfctl`​ コマンドについての詳細は、​[「rtfctl のコマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands)​を参照してください。 rtfctl apply mule-license $BASE64\_ENCODED\_LICENSE 3. Mule ライセンスキーが正しく適用されたことを確認するには、​`rtfctl`​ ユーティリティを使用してコンテンツを取得します。 rtfctl get mule-license ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) # Mule ライセンスキーの置き換え Mule ライセンスの期限が切れた場合、Mule ライセンスキーを置き換える必要があります。また、インストール中に正しくないライセンスキーを入力した場合もこの手順を使用します。 インストールを開始するために使用したコントローラーノードで次の手順を実行します。Azure および AWS インストールでは、このノードの名前はデフォルトで ​`rtf-controller-1`​ に設定されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の Mule ライセンスキーを置き換えるには、​`rtfctl`​ ユーティリティが必要です。続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​する手順を実行します。 `rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 ## [](#手順)手順 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - Unix では、次のコマンドを実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. `rtfctl`​ ユーティリティを使用して、ライセンスキーの Base64 値を適用します。​`rtfctl`​ コマンドについての詳細は、​[「rtfctl のコマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands)​を参照してください。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. Mule ライセンスキーが正しく適用されたことを確認するには、​`rtfctl`​ ユーティリティを使用してコンテンツを取得します。 ```copy rtfctl get mule-license ```
最新の変更済みライセンスを取得するには、Runtime Fabric Mule アプリケーションを再起動する必要があります。
## [](#ライセンスの有効期限の取得)ライセンスの有効期限の取得 `GET`​ fabric API ​`(/organizations/{organizationId}/fabrics/{id})`​ の応答には、省略可能な ​`licenseExpiryDate`​ 項目が含まれます。 { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } Runtime Fabric の ​**\[Mule License Expiry Date (Mule ライセンス有効期限)\]**​ は Runtime Manager UI でも公開され、​**\[License is expiring soon (ライセンスの有効期限がもうすぐ切れます)\]**​ という警告通知が伴います。 ![「Mule License Expiry Date (Mule ライセンス有効期限)」 の警告通知が含まれる Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-license-expiring.png) ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) # Mule ライセンスキーの置き換え Mule ライセンスの期限が切れた場合、Mule ライセンスキーを置き換える必要があります。また、インストール中に正しくないライセンスキーを入力した場合もこの手順を使用します。 インストールを開始するために使用したコントローラーノードで次の手順を実行します。Azure および AWS インストールでは、このノードの名前はデフォルトで ​`rtf-controller-1`​ に設定されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の Mule ライセンスキーを置き換えるには、​`rtfctl`​ ユーティリティが必要です。続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl)​する手順を実行します。 `rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 ## [](#手順)手順 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - Unix では、次のコマンドを実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. `rtfctl`​ ユーティリティを使用して、ライセンスキーの Base64 値を適用します。​`rtfctl`​ コマンドについての詳細は、​[「rtfctl のコマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands)​を参照してください。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. Mule ライセンスキーが正しく適用されたことを確認するには、​`rtfctl`​ ユーティリティを使用してコンテンツを取得します。 ```copy rtfctl get mule-license ```
最新の変更済みライセンスを取得するには、Runtime Fabric Mule アプリケーションを再起動する必要があります。
## [](#ライセンスの有効期限の取得)ライセンスの有効期限の取得 `GET`​ fabric API ​`(/organizations/{organizationId}/fabrics/{id})`​ の応答には、省略可能な ​`licenseExpiryDate`​ 項目が含まれます。 { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } Runtime Fabric の ​**\[Mule License Expiry Date (Mule ライセンス有効期限)\]**​ は Runtime Manager UI でも公開され、​**\[License is expiring soon (ライセンスの有効期限がもうすぐ切れます)\]**​ という警告通知が伴います。 ![「Mule License Expiry Date (Mule ライセンス有効期限)」 の警告通知が含まれる Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-license-expiring.png) ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) # Mule ライセンスキーの置き換え Mule ライセンスの期限が切れた場合、Mule ライセンスキーを置き換える必要があります。また、インストール中に正しくないライセンスキーを入力した場合もこの手順を使用します。 インストールを開始するために使用したコントローラーノードで次の手順を実行します。Azure および AWS インストールでは、このノードの名前はデフォルトで ​`rtf-controller-1`​ に設定されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の Mule ライセンスキーを置き換えるには、​`rtfctl`​ ユーティリティが必要です。続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl)​する手順を実行します。 `rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 ## [](#手順)手順 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - Unix では、次のコマンドを実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. `rtfctl`​ ユーティリティを使用して、ライセンスキーの Base64 値を適用します。​`rtfctl`​ コマンドについての詳細は、​[「rtfctl のコマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands)​を参照してください。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. Mule ライセンスキーが正しく適用されたことを確認するには、​`rtfctl`​ ユーティリティを使用してコンテンツを取得します。 ```copy rtfctl get mule-license ```
最新の変更済みライセンスを取得するには、Runtime Fabric Mule アプリケーションを再起動する必要があります。
## [](#ライセンスの有効期限の取得)ライセンスの有効期限の取得 `GET`​ fabric API ​`(/organizations/{organizationId}/fabrics/{id})`​ の応答には、省略可能な ​`licenseExpiryDate`​ 項目が含まれます。 { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } Runtime Fabric の ​**\[Mule License Expiry Date (Mule ライセンス有効期限)\]**​ は Runtime Manager UI でも公開され、​**\[License is expiring soon (ライセンスの有効期限がもうすぐ切れます)\]**​ という警告通知が伴います。 ![「Mule License Expiry Date (Mule ライセンス有効期限)」 の警告通知が含まれる Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-license-expiring.png) ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) # Mule ライセンスキーの置き換え Mule ライセンスの期限が切れた場合、Mule ライセンスキーを置き換える必要があります。また、インストール中に正しくないライセンスキーを入力した場合もこの手順を使用します。 インストールを開始するために使用したコントローラーノードで次の手順を実行します。Azure および AWS インストールでは、このノードの名前はデフォルトで ​`rtf-controller-1`​ に設定されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の Mule ライセンスキーを置き換えるには、​`rtfctl`​ ユーティリティが必要です。続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl)​する手順を実行します。 `rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 ## [](#手順)手順 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -b0 -i license.lic) ``` - Unix では、次のコマンドを実行します。 ```copy BASE64_ENCODED_LICENSE=$(base64 -w0 license.lic) ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` 2. `rtfctl`​ ユーティリティを使用して、ライセンスキーの Base64 値を適用します。​`rtfctl`​ コマンドについての詳細は、​[「rtfctl のコマンド」](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl#list-supported-commands)​を参照してください。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` 3. Mule ライセンスキーが正しく適用されたことを確認するには、​`rtfctl`​ ユーティリティを使用してコンテンツを取得します。 ```copy rtfctl get mule-license ```
最新の変更済みライセンスを取得するには、Runtime Fabric Mule アプリケーションを再起動する必要があります。
## [](#ライセンスの有効期限の取得)ライセンスの有効期限の取得 `GET`​ fabric API ​`(/organizations/{organizationId}/fabrics/{id})`​ の応答には、省略可能な ​`licenseExpiryDate`​ 項目が含まれます。 { "id": "fabric\_id", "name": "anna-qa-gke-rtf-1", "region": "us-east-1", "vendor": "gke", "vendorMetadata": {}, "organizationId": "organization\_id", "version": "2.2.9", "status": "Active", "desiredVersion": "2.2.9", "availableUpgradeVersion": "2.2.29", "createdAt": 1679684859167, "secondsSinceHeartbeat": 192, "kubernetesVersion": "v1.24.11-gke.1000", "licenseExpiryDate": 1653523200000, "isManaged": false, "isHelmManaged": true, "clusterConfigurationLevel": "production", "features": { "enhancedSecurity": true, "persistentStore": false }, "ingress": { "domains": \[\] } } Runtime Fabric の ​**\[Mule License Expiry Date (Mule ライセンス有効期限)\]**​ は Runtime Manager UI でも公開され、​**\[License is expiring soon (ライセンスの有効期限がもうすぐ切れます)\]**​ という警告通知が伴います。 ![「Mule License Expiry Date (Mule ライセンス有効期限)」 の警告通知が含まれる Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-license-expiring.png) ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/runtime-fabric/latest/install-rtfctl) # Red Hat OpenShift での Runtime Fabric のアップグレード Red Hat OpenShift コンソールでは、自動 (デフォルト) または手動でアップグレードを実行できます。この設定は Runtime Fabric Operator の ​**\[Subscription (サブスクリプション)\]**​ タブで変更できます。 Runtime Fabric エージェントバージョン 2.4.0 以降では、新しい Mule アプリケーションをデプロイするには、2023 年 8 月 8 日以降にビルドされた Mule Runtime イメージを使用する必要があります。 Red Hat OpenShift で Runtime Fabric をアップグレードするには、Red Hat OpenShift コンソールで Runtime Fabric Operator を使用します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. Runtime Fabric Operator を選択します。 3. **\[Upgrade (アップグレード)\]**​ をクリックします。 # Red Hat OpenShift での Runtime Fabric のアップグレード Red Hat OpenShift コンソールでは、自動 (デフォルト) または手動でアップグレードを実行できます。この設定は Runtime Fabric Operator の ​**\[Subscription (サブスクリプション)\]**​ タブで変更できます。 Runtime Fabric エージェントバージョン 2.4.0 以降では、新しい Mule アプリケーションをデプロイするには、2023 年 8 月 8 日以降にビルドされた Mule Runtime イメージを使用する必要があります。 Red Hat OpenShift で Runtime Fabric をアップグレードするには、Red Hat OpenShift コンソールで Runtime Fabric Operator を使用します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. Runtime Fabric Operator を選択します。 3. **\[Upgrade (アップグレード)\]**​ をクリックします。 # Red Hat OpenShift での Runtime Fabric のアップグレード Red Hat OpenShift コンソールでは、自動 (デフォルト) または手動でアップグレードを実行できます。この設定は Runtime Fabric Operator の ​**\[Subscription (サブスクリプション)\]**​ タブで変更できます。 Runtime Fabric エージェントバージョン 2.4.0 以降では、新しい Mule アプリケーションをデプロイするには、2023 年 8 月 8 日以降にビルドされた Mule Runtime イメージを使用する必要があります。 Red Hat OpenShift で Runtime Fabric をアップグレードするには、Red Hat OpenShift コンソールで Runtime Fabric Operator を使用します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. Runtime Fabric Operator を選択します。 3. **\[Upgrade (アップグレード)\]**​ をクリックします。 # Red Hat OpenShift での Runtime Fabric のアップグレード Red Hat OpenShift コンソールでは、自動 (デフォルト) または手動でアップグレードを実行できます。この設定は Runtime Fabric Operator の ​**\[Subscription (サブスクリプション)\]**​ タブで変更できます。 Runtime Fabric エージェントバージョン 2.4.0 以降では、新しい Mule アプリケーションをデプロイするには、2023 年 8 月 8 日以降にビルドされた Mule Runtime イメージを使用する必要があります。 ## [](#red-hat-openshift-で-runtime-fabric-をアップグレードする)Red Hat OpenShift で Runtime Fabric をアップグレードする Red Hat OpenShift で Runtime Fabric をアップグレードするには、Red Hat OpenShift コンソールで Runtime Fabric Operator を使用します。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\] > \[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. Runtime Fabric Operator を選択します。 3. **\[Upgrade (アップグレード)\]**​ をクリックします。 ## [](#red-hat-openshift-で中間-runtime-fabric-にアップグレードする)Red Hat OpenShift で中間 Runtime Fabric にアップグレードする 中間 Runtime Fabric OpenShift Operator にアップグレードするには、以前のバージョンをアンインストールさいて、中間バージョンをインストールする必要があります。 1. OpenShift コンソールから、Runtime Fabric インスタンスまたはクラスターの削除やアンインストールは行わず Runtime Fabric Operator をアンインストールします。 2. OpenShift コンソールの \[Operator Hub (オペレーターハブ)\] で Runtime Fabric Operator を見つけて、目的のバージョンをインストールします。 これにより、既存の Runtime Fabric インスタンスのアップグレードが自動的にトリガーされます。 ## [](#関連情報)関連情報 - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-index) # RTFCTL Kubernetes の権限 `rtfctl`​ コマンドを正常に実行するには、Kubernetes リソースに対する特定のロール権限を理解して有効にする必要があります。 Kubernetes (K8s) の RBAC ( [ロールベースのアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​) を使用して設定する権限を次の表に示します。
rtfctl コマンド 名前空間 API グループ Kubernetes リソース 動詞

apply​

rtf

configmaps

create、get、patch、update

pods

deletecollection

<app-namespace>

secrets

get、list、watch

namespaces

get、list、watch

secrets

create、get、patch、update

update​

rtf

configmaps、secrets

get

wait​

rtf

configmaps、secret

get

apps

daemonsets、deployments

get、list、watch

install​

rtf

configmaps、pods/log

get

pods

get、list、watch

secrets

create、get

serviceaccounts

create

バッチ

jobs

create、get

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create

backup​

configmaps、namespaces、secrets、serviceaccounts、services

get、list、watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets、deployments

get、list、watch

バッチ

cronjobs

get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

clusterrolebindings、clusterroles、rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways

get、list、watch

scheduling.k8s.io

priorityclasses

get

restore​

rtf

apps

daemonsets

create、get、patch、update

バッチ

cronjobs

create、get、patch、update

rtf.mulesoft.com

persistencegateways

get、list、watch

configmaps、namespaces、secrets、serviceaccounts、services

create、get、patch、update

apiextensions.k8s.io

customresourcedefinitions

get、patch、update

apps

deployments

create、get、patch、update

networking.k8s.io

ingresses

create、get、patch、update

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、get、patch、update

scheduling.k8s.io

priorityclasses

create、get、patch、update

validate​

rtf

configmaps

get

pods

deletecollection

secrets

delete、get

バッチ

jobs

delete

rtf-validate

namespaces

delete、get

pods/log

get

secrets、serviceaccounts

create

バッチ

jobs

create、get

namespaces

create

nodes、pods

get、list、watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、delete

version​

rtf

configmaps、secrets

get

delete​

<app-namespace>

pods

get、list、watch

secrets

get、list、patch、update、watch

rtf

configmaps、secrets

get

describe​

<app-namespace>

pods

get、list、watch

rtf

configmaps、secrets

get

apps

deployments

get、list、watch

disk​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

memory​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

package​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

restart​

<app-namespace>

pods

delete、get、list、watch

rtf

configmaps、secrets

get

heapdump​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

threaddump​

<app-namespace>

secrets

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

get​

<app-namespace>

secrets

get、list、watch

rtf

configmaps、secrets

get

apps

deployments

get、list、watch

report​

rtf

configmaps、limitranges、resourcequotas、secrets、serviceaccounts、services

get、list、watch

endpoints、pods/log

get

apps

daemonsets、deployments、replicasets

get、list、watch

バッチ

cronjobs

get、list、watch

バッチ

jobs

create、delete、get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

roldebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways

get、list、watch

kube-node-lease

coordination.k8s.io

leases

get

events、namespaces、nodes、pods

get、list、watch

status​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

test​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

nodes

get、list、watch
- 名前空間 権限はロールベースまたはクラスターロールベースです。 - ロールベース: 名前空間は rtf、、rtf-validate、または kube-node-lease です。 - クラスターロールベース: クラスター全体に適用されるため、名前空間項目は存在せず、テーブルでは空白になっています。 - apiGroups K8s リソースの API グループです。ロールを作成すると、各 K8s リソースはその API グループを宣言するか、API グループが指定されていない場合はコア API グループを使用します。詳細は、 [「API グループ^」](https://kubernetes.io/docs/reference/using-api/#api-groups)​を参照してください。 - Kubernetes リソース 権限が適用される Kubernetes リソースの種類 (​`ポッド`​、​`サービス`​、​`シークレット`​など)。 - 動詞 指定した Kubernetes リソースで許可されるアクション。 # RTFCTL Kubernetes の権限 `rtfctl`​ コマンドを正常に実行するには、Kubernetes リソースに対する特定のロール権限を理解して有効にする必要があります。 Kubernetes (K8s) の RBAC ( [ロールベースのアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​) を使用して設定する権限を次の表に示します。
rtfctl コマンド 名前空間 API グループ Kubernetes リソース 動詞

apply​

rtf

configmaps

create、get、patch、update

pods

deletecollection

<app-namespace>

secrets

get、list、watch

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

secrets

create、get、patch、update

update​

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

wait​

rtf

configmaps、secret

get

rtfctl-audit

secrets

create、get、patch、update

apps

daemonsets、deployments

get、list、watch

namespaces

create

install​

rtf

configmaps、pods/log

get

pods

get、list、watch

secrets

create、get

serviceaccounts

create

バッチ

jobs

create、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create

backup​

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

configmaps、namespaces、secrets、serviceaccounts、services

get、list、watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets、deployments

get、list、watch

バッチ

cronjobs

get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

clusterrolebindings、clusterroles、rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways

get、list、watch

scheduling.k8s.io

priorityclasses

get

restore​

rtf

apps

daemonsets

create、get、patch、update

バッチ

cronjobs

create、get、patch、update

rtf.mulesoft.com

persistencegateways

get、list、watch

rtfctl-audit

secrets

create、get、patch、update

configmaps、namespaces、secrets、serviceaccounts、services

create、get、patch、update

apiextensions.k8s.io

customresourcedefinitions

get、patch、update

apps

deployments

create、get、patch、update

networking.k8s.io

ingresses

create、get、patch、update

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、get、patch、update

scheduling.k8s.io

priorityclasses

create、get、patch、update

validate​

rtf

configmaps

get

pods

deletecollection

secrets

delete、get

バッチ

jobs

delete

rtf-validate

namespaces

delete、get

pods/log

get

secrets、serviceaccounts

create

バッチ

jobs

create、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

nodes、pods

get、list、watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、delete

version​

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

delete​

<app-namespace>

pods

get、list、watch

secrets

get、list、patch、update、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

describe​

<app-namespace>

pods

get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

apps

deployments

get、list、watch

disk​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

memory​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

package​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

restart​

<app-namespace>

pods

delete、get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

heapdump​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

threaddump​

<app-namespace>

secrets

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

get​

<app-namespace>

secrets

get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

apps

deployments

get、list、watch

report​

rtf

configmaps、limitranges、resourcequotas、secrets、serviceaccounts、services

get、list、watch

endpoints、pods/log

get

apps

daemonsets、deployments、replicasets

get、list、watch

バッチ

cronjobs

get、list、watch

バッチ

jobs

create、delete、get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways

get、list、watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

events、nodes、pods

get、list、watch

status​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

test​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

rtfctl-audit

secrets

create、get、patch、update

nodes

get、list、watch

namespaces

create
- 名前空間 権限はロールベースまたはクラスターロールベースです。 - ロールベース: 名前空間は rtf、、rtf-validate、または kube-node-lease です。 - クラスターロールベース: クラスター全体に適用されるため、名前空間項目は存在せず、テーブルでは空白になっています。 - apiGroups K8s リソースの API グループです。ロールを作成すると、各 K8s リソースはその API グループを宣言するか、API グループが指定されていない場合はコア API グループを使用します。詳細は、 [「API グループ」](https://kubernetes.io/docs/reference/using-api/#api-groups)​を参照してください。 - Kubernetes リソース 権限が適用される Kubernetes リソースの種類 (​`ポッド`​、​`サービス`​、​`シークレット`​など)。 - 動詞 指定した Kubernetes リソースで許可されるアクション。 ## [](#関連情報)関連情報 - [Runtime Fabric コアソフトウェアの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-permissions) - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-mule-app-permissions) # RTFCTL Kubernetes の権限 `rtfctl`​ コマンドを正常に実行するには、Kubernetes リソースに対する特定のロール権限を理解して有効にする必要があります。 Kubernetes (K8s) の RBAC ( [ロールベースのアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​) を使用して設定する権限を次の表に示します。
rtfctl コマンド 名前空間 API グループ Kubernetes リソース 動詞

apply​

rtf

configmaps

create、get、patch、update

pods

deletecollection

<app-namespace>

secrets

get、list、watch

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

secrets

create、get、patch、update

update​

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

wait​

rtf

configmaps、secret

get

rtfctl-audit

secrets

create、get、patch、update

apps

daemonsets、deployments

get、list、watch

namespaces

create

install​

rtf

configmaps、pods/log

get

pods

get、list、watch

secrets

create、get

serviceaccounts

create

バッチ

jobs

create、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create

backup​

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

configmaps、namespaces、secrets、serviceaccounts、services

get、list、watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets、deployments

get、list、watch

バッチ

cronjobs

get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

clusterrolebindings、clusterroles、rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways

get、list、watch

scheduling.k8s.io

priorityclasses

get

restore​

rtf

apps

daemonsets

create、get、patch、update

バッチ

cronjobs

create、get、patch、update

rtf.mulesoft.com

persistencegateways

get、list、watch

rtfctl-audit

secrets

create、get、patch、update

configmaps、namespaces、secrets、serviceaccounts、services

create、get、patch、update

apiextensions.k8s.io

customresourcedefinitions

get、patch、update

apps

deployments

create、get、patch、update

networking.k8s.io

ingresses

create、get、patch、update

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、get、patch、update

scheduling.k8s.io

priorityclasses

create、get、patch、update

validate​

rtf

configmaps

get

pods

deletecollection

secrets

delete、get

バッチ

jobs

delete

rtf-validate

namespaces

delete、get

pods/log

get

secrets、serviceaccounts

create

バッチ

jobs

create、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

nodes、pods

get、list、watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、delete

version​

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

delete​

<app-namespace>

pods

get、list、watch

secrets

get、list、patch、update、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

describe​

<app-namespace>

pods

get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

apps

deployments

get、list、watch

disk​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

memory​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

package​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

restart​

<app-namespace>

pods

delete、get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

heapdump​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

threaddump​

<app-namespace>

secrets

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

get​

<app-namespace>

secrets

get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

apps

deployments

get、list、watch

report​

rtf

configmaps、limitranges、resourcequotas、secrets、serviceaccounts、services

get、list、watch

endpoints、pods/log

get

apps

daemonsets、deployments、replicasets

get、list、watch

バッチ

cronjobs

get、list、watch

バッチ

jobs

create、delete、get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways、kubernetestemplates

get、list、watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

events、nodes、pods

get、list、watch

status​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

test​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

rtfctl-audit

secrets

create、get、patch、update

nodes

get、list、watch

namespaces

create
- 名前空間 権限はロールベースまたはクラスターロールベースです。 - ロールベース: 名前空間は rtf、、rtf-validate、または kube-node-lease です。 - クラスターロールベース: クラスター全体に適用されるため、名前空間項目は存在せず、テーブルでは空白になっています。 - apiGroups K8s リソースの API グループです。ロールを作成すると、各 K8s リソースはその API グループを宣言するか、API グループが指定されていない場合はコア API グループを使用します。詳細は、 [「API グループ」](https://kubernetes.io/docs/reference/using-api/#api-groups)​を参照してください。 - Kubernetes リソース 権限が適用される Kubernetes リソースの種類 (​`ポッド`​、​`サービス`​、​`シークレット`​など)。 - 動詞 指定した Kubernetes リソースで許可されるアクション。 ## [](#関連情報)関連情報 - [Runtime Fabric コアソフトウェアの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-permissions) - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-mule-app-permissions) # RTFCTL Kubernetes の権限 `rtfctl`​ コマンドを正常に実行するには、Kubernetes リソースに対する特定のロール権限を理解して有効にする必要があります。 Kubernetes (K8s) の RBAC ( [ロールベースのアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)​) を使用して設定する権限を次の表に示します。
rtfctl コマンド 名前空間 API グループ Kubernetes リソース 動詞

apply​

rtf

configmaps

create、get、patch、update

pods

deletecollection

<app-namespace>

secrets

get、list、watch

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

secrets

create、get、patch、update

update​

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

wait​

rtf

configmaps、secret

get

rtfctl-audit

secrets

create、get、patch、update

apps

daemonsets、deployments

get、list、watch

namespaces

create

install​

rtf

configmaps、pods/log

get

pods

get、list、watch

secrets

create、get

serviceaccounts

create

バッチ

jobs

create、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create

backup​

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

configmaps、namespaces、secrets、serviceaccounts、services

get、list、watch

apiextensions.k8s.io

customresourcedefinitions

get

apps

daemonsets、deployments

get、list、watch

バッチ

cronjobs

get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

clusterrolebindings、clusterroles、rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways

get、list、watch

scheduling.k8s.io

priorityclasses

get

restore​

rtf

apps

daemonsets

create、get、patch、update

バッチ

cronjobs

create、get、patch、update

rtf.mulesoft.com

persistencegateways

get、list、watch

rtfctl-audit

secrets

create、get、patch、update

configmaps、namespaces、secrets、serviceaccounts、services

create、get、patch、update

apiextensions.k8s.io

customresourcedefinitions

get、patch、update

apps

deployments

create、get、patch、update

networking.k8s.io

ingresses

create、get、patch、update

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、get、patch、update

scheduling.k8s.io

priorityclasses

create、get、patch、update

validate​

rtf

configmaps

get

pods

deletecollection

secrets

delete、get

バッチ

jobs

delete

rtf-validate

namespaces

delete、get

pods/log

get

secrets、serviceaccounts

create

バッチ

jobs

create、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

nodes、pods

get、list、watch

authorization.k8s.io

selfsubjectaccessreviews

create

rbac.authorization.k8s.io

clusterrolebindings、clusterroles

create、delete

version​

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

delete​

<app-namespace>

pods

get、list、watch

secrets

get、list、patch、update、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

describe​

<app-namespace>

pods

get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

apps

deployments

get、list、watch

disk​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

memory​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

package​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

restart​

<app-namespace>

pods

delete、get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

heapdump​

<app-namespace>

pods

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

threaddump​

<app-namespace>

secrets

get、list、watch

pods/exec

create

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

get​

<app-namespace>

secrets

get、list、watch

rtf

configmaps、secrets

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

apps

deployments

get、list、watch

report​

rtf

configmaps、limitranges、resourcequotas、secrets、serviceaccounts、services

get、list、watch

endpoints、pods/log

get

apps

daemonsets、deployments、replicasets

get、list、watch

バッチ

cronjobs

get、list、watch

バッチ

jobs

create、delete、get、list、watch

networking.k8s.io

ingresses

get、list、watch

rbac.authorization.k8s.io

rolebindings、roles

get、list、watch

rtf.mulesoft.com

persistencegateways、kubernetestemplates

get、list、watch

kube-node-lease

coordination.k8s.io

leases

get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create、get、list、watch

events、nodes、pods

get、list、watch

status​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

rtfctl-audit

secrets

create、get、patch、update

namespaces

create

test​

rtf

configmaps、pods/log、secrets

get

pods

create、delete、get、list、watch

バッチ

jobs

create、delete、get

rtfctl-audit

secrets

create、get、patch、update

nodes

get、list、watch

namespaces

create
- 名前空間 権限はロールベースまたはクラスターロールベースです。 - ロールベース: 名前空間は rtf、、rtf-validate、または kube-node-lease です。 - クラスターロールベース: クラスター全体に適用されるため、名前空間項目は存在せず、テーブルでは空白になっています。 - apiGroups K8s リソースの API グループです。ロールを作成すると、各 K8s リソースはその API グループを宣言するか、API グループが指定されていない場合はコア API グループを使用します。詳細は、 [「API グループ」](https://kubernetes.io/docs/reference/using-api/#api-groups)​を参照してください。 - Kubernetes リソース 権限が適用される Kubernetes リソースの種類 (​`ポッド`​、​`サービス`​、​`シークレット`​など)。 - 動詞 指定した Kubernetes リソースで許可されるアクション。 ## [](#関連情報)関連情報 - [Runtime Fabric コアソフトウェアの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-permissions) - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-mule-app-permissions) # RTFCTL ツールの使用の概要 `rtfctl`​ コマンドラインツールをインストールすると、Runtime Fabric をローカルで管理できます。​`rtfctl`​ を使用して次のアクションを実行できます。 - Runtime Fabric の状況を取得する - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する - 実行中のアプリケーションのメモリ使用量を表示する - プロキシ設定を管理する - セキュアプロパティを管理する - Mule ライセンスを管理する - アラート送信者メールアドレスを管理する ## [](#rtfctl-の使用を始める前に)RTFCTL の使用を始める前に `rtfctl`​ の使用を始める前に、次のトピックを参照して ​`rtfctl`​ の Kubernetes 権限を有効にし、​`rtfctl`​ コマンドラインツールをインストールしてください。 - [RTFCTL のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/setting-up-rtfctl) ## [](#次のステップ)次のステップ コマンドラインツールのインストール後、​`rtfctl`​ コマンドを使用して Runtime Fabric のインストールと管理を行ったり、Runtime Fabric にデプロイされた Mule アプリケーションを管理したりできるようになります。 - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/using-rtfctl-rtf) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/using-rtfctl-mule-apps) ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl) # RTFCTL ツールの使用の概要 `rtfctl`​ コマンドラインツールをインストールすると、Runtime Fabric をローカルで管理できます。​`rtfctl`​ を使用して次のアクションを実行できます。 - Runtime Fabric の状況を取得する - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する - 実行中のアプリケーションのメモリ使用量を表示する - プロキシ設定を管理する - セキュアプロパティを管理する - Mule ライセンスを管理する - アラート送信者メールアドレスを管理する ## [](#rtfctl-の使用を始める前に)RTFCTL の使用を始める前に `rtfctl`​ の使用を始める前に、次のトピックを参照して ​`rtfctl`​ の Kubernetes 権限を有効にし、​`rtfctl`​ コマンドラインツールをインストールしてください。 - [RTFCTL のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/setting-up-rtfctl) ## [](#次のステップ)次のステップ コマンドラインツールのインストール後、​`rtfctl`​ コマンドを使用して Runtime Fabric のインストールと管理を行ったり、Runtime Fabric にデプロイされた Mule アプリケーションを管理したりできるようになります。 - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/using-rtfctl-rtf) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/using-rtfctl-mule-apps) ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl) # RTFCTL ツールの使用の概要 `rtfctl`​ コマンドラインツールをインストールすると、Runtime Fabric をローカルで管理できます。​`rtfctl`​ を使用して次のアクションを実行できます。 - Runtime Fabric の状況を取得する - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する - 実行中のアプリケーションのメモリ使用量を表示する - プロキシ設定を管理する - セキュアプロパティを管理する - Mule ライセンスを管理する - アラート送信者メールアドレスを管理する ## [](#rtfctl-の使用を始める前に)RTFCTL の使用を始める前に `rtfctl`​ の使用を始める前に、次のトピックを参照して ​`rtfctl`​ の Kubernetes 権限を有効にし、​`rtfctl`​ コマンドラインツールをインストールしてください。 - [RTFCTL のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/setting-up-rtfctl) ## [](#次のステップ)次のステップ コマンドラインツールのインストール後、​`rtfctl`​ コマンドを使用して Runtime Fabric のインストールと管理を行ったり、Runtime Fabric にデプロイされた Mule アプリケーションを管理したりできるようになります。 - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/using-rtfctl-rtf) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/using-rtfctl-mule-apps) ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl) # RTFCTL のセットアップ 次のトピックは、​`rtfctl`​ の Kubernetes 権限を有効にして、​`rtfctl`​ コマンドラインツールをインストールするのに役立ちます。 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtfctl-permissions) `rtfctl`​ コマンドを正常に実行するために、Kubernetes リソースに対する特定のロール権限を有効にします。 - [RTFCTL ツールのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#install-rtfctl) Runtime Fabric をローカルで管理するために、​`rtfctl`​ コマンドラインツールをインストールします。 ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl) - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/using-rtfctl-rtf) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/using-rtfctl-mule-apps) # RTFCTL のセットアップ 次のトピックは、​`rtfctl`​ の Kubernetes 権限を有効にして、​`rtfctl`​ コマンドラインツールをインストールするのに役立ちます。 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtfctl-permissions) `rtfctl`​ コマンドを正常に実行するために、Kubernetes リソースに対する特定のロール権限を有効にします。 - [RTFCTL ツールのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#install-rtfctl) Runtime Fabric をローカルで管理するために、​`rtfctl`​ コマンドラインツールをインストールします。 ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl) - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/using-rtfctl-rtf) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/using-rtfctl-mule-apps) # RTFCTL のセットアップ 次のトピックは、​`rtfctl`​ の Kubernetes 権限を有効にして、​`rtfctl`​ コマンドラインツールをインストールするのに役立ちます。 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtfctl-permissions) `rtfctl`​ コマンドを正常に実行するために、Kubernetes リソースに対する特定のロール権限を有効にします。 - [RTFCTL ツールのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#install-rtfctl) Runtime Fabric をローカルで管理するために、​`rtfctl`​ コマンドラインツールをインストールします。 ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl) - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/using-rtfctl-rtf) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/using-rtfctl-mule-apps) # RTFCTL を使用した Mule アプリケーションプロパティ値の保護 セキュアなアプリケーションプロパティは、Runtime Fabric クラスターのローカルに追加され、安全に保存され、環境ごとにスコープ設定されます。これらのプロパティには、スコープ設定された環境にカスタムプロパティとしてデプロイされた Mule アプリケーションから暗号化されていない形式でアクセスできます。 Runtime Fabric の保護されたプロパティは、アプリケーションレベルのプロパティよりも常に優先されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の保護されたプロパティをローカルで管理するには、​`rtfctl`​ ユーティリティが必要です。セキュアプロパティの管理を続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl)​する手順を実行します。 ## [](#セキュアプロパティを設定する)セキュアプロパティを設定する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric にセキュアプロパティを設定します。 ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****​: Mule アプリケーションで値を参照するために使用されるセキュアプロパティのキー。 - ****​: 保存するセキュアプロパティの値。 - ****​: このセキュアプロパティをスコープ設定する Anypoint 環境。この環境にデプロイされたアプリケーションのみがこのセキュアプロパティにアクセスできます。 - ****​:システムの名前空間スコープで、デフォルトは ​`rtf`​ です。 ## [](#セキュアプロパティを表示する)セキュアプロパティを表示する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric に適用されるセキュアプロパティを表示します。 ```copy sudo ./rtfctl get secure-properties -n ``` - ****​: セキュアプロパティを表示する Anypoint 環境 ID。 ## [](#セキュアプロパティへのアクセス)セキュアプロパティへのアクセス `${my.property.name}`​ を使用して、Mule アプリケーション内からセキュアプロパティにアクセスできます。 ## [](#セキュアプロパティを削除する)セキュアプロパティを削除する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、特定の名前空間で Runtime Fabric からセキュアプロパティを削除します。 ```copy sudo ./rtfctl delete secure-property -n ``` - ****​: セキュアプロパティを参照するために Mule アプリケーションで使用されるキー。 - ****​: セキュアプロパティが適用される名前空間。 ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl) - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-proxy-self) # RTFCTL を使用した Mule アプリケーションプロパティ値の保護 セキュアなアプリケーションプロパティは、Runtime Fabric クラスターのローカルに追加され、安全に保存され、環境ごとにスコープ設定されます。これらのプロパティには、スコープ設定された環境にカスタムプロパティとしてデプロイされた Mule アプリケーションから暗号化されていない形式でアクセスできます。 Runtime Fabric の保護されたプロパティは、アプリケーションレベルのプロパティよりも常に優先されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の保護されたプロパティをローカルで管理するには、​`rtfctl`​ ユーティリティが必要です。セキュアプロパティの管理を続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl)​する手順を実行します。 ## [](#セキュアプロパティを設定する)セキュアプロパティを設定する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric にセキュアプロパティを設定します。 ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****​: Mule アプリケーションで値を参照するために使用されるセキュアプロパティのキー。 - ****​: 保存するセキュアプロパティの値。 - ****​: このセキュアプロパティをスコープ設定する Anypoint 環境。この環境にデプロイされたアプリケーションのみがこのセキュアプロパティにアクセスできます。 - ****​:システムの名前空間スコープで、デフォルトは ​`rtf`​ です。 ## [](#セキュアプロパティを表示する)セキュアプロパティを表示する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric に適用されるセキュアプロパティを表示します。 ```copy sudo ./rtfctl get secure-properties -n ``` - ****​: セキュアプロパティを表示する Anypoint 環境 ID。 ## [](#セキュアプロパティへのアクセス)セキュアプロパティへのアクセス `${my.property.name}`​ を使用して、Mule アプリケーション内からセキュアプロパティにアクセスできます。 ## [](#セキュアプロパティを削除する)セキュアプロパティを削除する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、特定の名前空間で Runtime Fabric からセキュアプロパティを削除します。 ```copy sudo ./rtfctl delete secure-property -n ``` - ****​: セキュアプロパティを参照するために Mule アプリケーションで使用されるキー。 - ****​: セキュアプロパティが適用される名前空間。 ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl) - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-proxy-self) # RTFCTL を使用した Mule アプリケーションプロパティ値の保護 セキュアなアプリケーションプロパティは、Runtime Fabric クラスターのローカルに追加され、安全に保存され、環境ごとにスコープ設定されます。これらのプロパティには、スコープ設定された環境にカスタムプロパティとしてデプロイされた Mule アプリケーションから暗号化されていない形式でアクセスできます。 Runtime Fabric の保護されたプロパティは、アプリケーションレベルのプロパティよりも常に優先されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の保護されたプロパティをローカルで管理するには、​`rtfctl`​ ユーティリティが必要です。セキュアプロパティの管理を続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl)​する手順を実行します。 ## [](#セキュアプロパティを設定する)セキュアプロパティを設定する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric にセキュアプロパティを設定します。 ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****​: Mule アプリケーションで値を参照するために使用されるセキュアプロパティのキー。 - ****​: 保存するセキュアプロパティの値。 - ****​: このセキュアプロパティをスコープ設定する Anypoint 環境。この環境にデプロイされたアプリケーションのみがこのセキュアプロパティにアクセスできます。 - ****​:システムの名前空間スコープで、デフォルトは ​`rtf`​ です。 ## [](#セキュアプロパティを表示する)セキュアプロパティを表示する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric に適用されるセキュアプロパティを表示します。 ```copy sudo ./rtfctl get secure-properties -n ``` - ****​: セキュアプロパティを表示する Anypoint 環境 ID。 ## [](#セキュアプロパティへのアクセス)セキュアプロパティへのアクセス `${my.property.name}`​ を使用して、Mule アプリケーション内からセキュアプロパティにアクセスできます。 ## [](#セキュアプロパティを削除する)セキュアプロパティを削除する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、特定の名前空間で Runtime Fabric からセキュアプロパティを削除します。 ```copy sudo ./rtfctl delete secure-property -n ``` - ****​: セキュアプロパティを参照するために Mule アプリケーションで使用されるキー。 - ****​: セキュアプロパティが適用される名前空間。 ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl) - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-proxy-self) # rtfctl を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Runtime Fabric コマンドラインツール ​`rtfctl`​ を使用して、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) でアップグレードできます。 ## [](#コンポーネントのアップグレードについて)コンポーネントのアップグレードについて Runtime Fabric コンポーネントをアップグレードする場合、次の機能を提供するサービスをアップグレードします。 - コントロールプレーンとの通信を容易にする - 負荷分散を行う - メトリクスを記録して転送する コンポーネントのアップグレードが可能な場合、アップグレードが利用可能になったときに表示されるボタンを使用して Runtime Manager 内でアップグレードを適用します。 Runtime Fabric コンポーネントのアップグレードでは、ノードの追加は不要です。 ### [](#使用しているコンポーネントバージョンの確認)使用しているコンポーネントバージョンの確認 `Kubeconfig`​ ファイルがあり、Kubernetes にアクセスできるローカルワークステーション、またはサポート拠点から、次のコマンドを実行します。 ```copy .rtfctl version ``` 出力は次のようになります。 ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - `rtfctl`​ 項目に ​`rtfctl`​ コマンドラインユーティリティバージョンが表示されます。 - `agent`​ 項目に Runtime Fabric コンポーネントバージョンが表示されます。
使用中の Runtime Fabric コンポーネントとバージョンは Runtime Manager の ​[Runtime Fabric]​ タブにも表示されます。アップグレードが使用できる場合は、Runtime Manager に ​[Upgrade to vx.x (vx.x にアップグレード)]​ メッセージが表示されます。
## [](#rtfctl-コマンドラインユーティリティのアップグレードについて)rtfctl コマンドラインユーティリティのアップグレードについて `rtfctl`​ コマンドラインユーティリティを使用して、Runtime Fabric を管理し、アップグレードを実行します。 コマンドラインから ​`rtfctl`​ ユーティリティをアップグレードします。 最新機能を使用できるように、必ず ​`rtfctl`​ コマンドラインユーティリティの最新バージョンを使用してください。 ## [](#アップグレードの適用)アップグレードの適用 Anypoint Runtime Fabric をアップグレードする手順は、次のとおりです。 1. Runtime Fabric コンポーネントのアップグレード 2. `rtfctl`​ コマンドラインユーティリティをアップグレードします。 本番環境をアップグレードする前に、本番以外の Runtime Fabric インスタンスで次の手順を実行し、環境との互換性を確認します。チームが新しいアプリケーションをデプロイしていないときや Runtime Fabric で既存のアプリケーションを管理していないときにアップグレードを計画します。本番以外のアップグレードが成功したら、本番環境で次の手順を実行します。 ### [](#runtime-fabric-コンポーネントのアップグレード)Runtime Fabric コンポーネントのアップグレード 最新のコンポーネントバージョンに関する情報については、​[「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​の情報を確認します。 1. Runtime Manager の ​**\[Runtime Fabric\]**​ タブで Runtime Fabric を選択し、Runtime Fabric に移動します。 2. **\[Upgrade to vx.x (vx.x にアップグレード)\]**​ を選択します。Runtime Fabric の状況が更新され、アップグレード手順が進行中であることが示されます。 3. 状況が ​**\[Active (アクティブ)\]**​ に移行するまで待ちます。 ほとんどの場合、アップグレードにかかる時間は 10 分未満です。状況が ​**\[Active (アクティブ)\]**​ に移行し、Runtime Fabric のバージョンが新しいバージョンを反映したら、コンポーネントのアップグレードは完了です。 Runtime Fabric と Runtime Manager の接続がアップグレード中に切断された場合、アップグレード完了後に接続が復元されます。 アップグレード後、通常は Runtime Fabric で数分間「低下」とレポートされます。これは、コントロールプレーンと同期するためです。この状態は、約 5 分後に自動的に解決されます。 ### [](#rtfctl-コマンドラインユーティリティをアップグレードする)`rtfctl`​ コマンドラインユーティリティをアップグレードする 1. ターミナルから、次のコマンドを実行します。 ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ バイナリのファイル権限を変更します。 ```copy chmod +x rtfctl ``` 3. または、​`rtfctl`​ バイナリを所有するユーザーの代わりに ​`rtfctl`​ を更新するには、次のコマンドを実行します。 ```copy `rtfctl update` ``` # RTFCTL を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Runtime Fabric コマンドラインツール ​`rtfctl`​ を使用して、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) でアップグレードできます。 ## [](#コンポーネントのアップグレードについて)コンポーネントのアップグレードについて Runtime Fabric コンポーネントをアップグレードする場合、次の機能を提供するサービスをアップグレードします。 - コントロールプレーンとの通信を容易にする - 負荷分散を行う - メトリクスを記録して転送する コンポーネントのアップグレードが可能な場合、アップグレードが利用可能になったときに表示されるボタンを使用して Runtime Manager 内でアップグレードを適用します。 Runtime Fabric コンポーネントのアップグレードでは、ノードの追加は不要です。 ### [](#使用しているコンポーネントバージョンの確認)使用しているコンポーネントバージョンの確認 `Kubeconfig`​ ファイルがあり、Kubernetes にアクセスできるローカルワークステーション、またはサポート拠点から、次のコマンドを実行します。 ```copy .rtfctl version ``` 出力は次のようになります。 ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - `rtfctl`​ 項目に ​`rtfctl`​ コマンドラインユーティリティバージョンが表示されます。 - `agent`​ 項目に Runtime Fabric コンポーネントバージョンが表示されます。
使用中の Runtime Fabric コンポーネントとバージョンは Runtime Manager の ​[Runtime Fabric]​ タブにも表示されます。アップグレードが使用できる場合は、Runtime Manager に ​[Upgrade to vx.x (vx.x にアップグレード)]​ メッセージが表示されます。
## [](#rtfctl-コマンドラインユーティリティのアップグレードについて)rtfctl コマンドラインユーティリティのアップグレードについて `rtfctl`​ コマンドラインユーティリティを使用して、Runtime Fabric を管理し、アップグレードを実行します。 コマンドラインから ​`rtfctl`​ ユーティリティをアップグレードします。 最新機能を使用できるように、必ず ​`rtfctl`​ コマンドラインユーティリティの最新バージョンを使用してください。 ## [](#アップグレードの適用)アップグレードの適用 Anypoint Runtime Fabric をアップグレードする手順は、次のとおりです。 1. Runtime Fabric コンポーネントのアップグレード 2. `rtfctl`​ コマンドラインユーティリティをアップグレードします。 本番環境をアップグレードする前に、本番以外の Runtime Fabric インスタンスで次の手順を実行し、環境との互換性を確認します。チームが新しいアプリケーションをデプロイしていないときや Runtime Fabric で既存のアプリケーションを管理していないときにアップグレードを計画します。本番以外のアップグレードが成功したら、本番環境で次の手順を実行します。 ### [](#runtime-fabric-コンポーネントのアップグレード)Runtime Fabric コンポーネントのアップグレード 最新のコンポーネントバージョンに関する情報については、​[「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​の情報を確認します。 1. Runtime Manager の ​**\[Runtime Fabric\]**​ タブで Runtime Fabric を選択し、Runtime Fabric に移動します。 2. **\[Upgrade to vx.x (vx.x にアップグレード)\]**​ を選択します。Runtime Fabric の状況が更新され、アップグレード手順が進行中であることが示されます。 3. 状況が ​**\[Active (アクティブ)\]**​ に移行するまで待ちます。 ほとんどの場合、アップグレードにかかる時間は 10 分未満です。状況が ​**\[Active (アクティブ)\]**​ に移行し、Runtime Fabric のバージョンが新しいバージョンを反映したら、コンポーネントのアップグレードは完了です。 Runtime Fabric と Runtime Manager の接続がアップグレード中に切断された場合、アップグレード完了後に接続が復元されます。 アップグレード後、通常は Runtime Fabric で数分間「低下」とレポートされます。これは、コントロールプレーンと同期するためです。この状態は、約 5 分後に自動的に解決されます。 ### [](#rtfctl-コマンドラインユーティリティをアップグレードする)`rtfctl`​ コマンドラインユーティリティをアップグレードする 1. ターミナルから、次のコマンドを実行します。 ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ バイナリのファイル権限を変更します。 ```copy chmod +x rtfctl ``` 3. または、​`rtfctl`​ バイナリを所有するユーザーの代わりに ​`rtfctl`​ を更新するには、次のコマンドを実行します。 ```copy `rtfctl update` ``` # RTFCTL を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Runtime Fabric コマンドラインツール ​`rtfctl`​ を使用して、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) でアップグレードできます。 ## [](#コンポーネントのアップグレードについて)コンポーネントのアップグレードについて Runtime Fabric コンポーネントをアップグレードする場合、次の機能を提供するサービスをアップグレードします。 - コントロールプレーンとの通信を容易にする - 負荷分散を行う - メトリクスを記録して転送する コンポーネントのアップグレードが可能な場合、アップグレードが利用可能になったときに表示されるボタンを使用して Runtime Manager 内でアップグレードを適用します。 Runtime Fabric コンポーネントのアップグレードでは、ノードの追加は不要です。 ### [](#使用しているコンポーネントバージョンの確認)使用しているコンポーネントバージョンの確認 `Kubeconfig`​ ファイルがあり、Kubernetes にアクセスできるローカルワークステーション、またはサポート拠点から、次のコマンドを実行します。 ```copy .rtfctl version ``` 出力は次のようになります。 ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - `rtfctl`​ 項目に ​`rtfctl`​ コマンドラインユーティリティバージョンが表示されます。 - `agent`​ 項目に Runtime Fabric コンポーネントバージョンが表示されます。
使用中の Runtime Fabric コンポーネントとバージョンは Runtime Manager の ​[Runtime Fabric]​ タブにも表示されます。アップグレードが使用できる場合は、Runtime Manager に ​[Upgrade to vx.x (vx.x にアップグレード)]​ メッセージが表示されます。
## [](#rtfctl-コマンドラインユーティリティのアップグレードについて)rtfctl コマンドラインユーティリティのアップグレードについて `rtfctl`​ コマンドラインユーティリティを使用して、Runtime Fabric を管理し、アップグレードを実行します。 コマンドラインから ​`rtfctl`​ ユーティリティをアップグレードします。 最新機能を使用できるように、必ず ​`rtfctl`​ コマンドラインユーティリティの最新バージョンを使用してください。 ## [](#アップグレードの適用)アップグレードの適用 Anypoint Runtime Fabric をアップグレードする手順は、次のとおりです。 1. Runtime Fabric コンポーネントのアップグレード 2. `rtfctl`​ コマンドラインユーティリティをアップグレードします。 本番環境をアップグレードする前に、本番以外の Runtime Fabric インスタンスで次の手順を実行し、環境との互換性を確認します。チームが新しいアプリケーションをデプロイしていないときや Runtime Fabric で既存のアプリケーションを管理していないときにアップグレードを計画します。本番以外のアップグレードが成功したら、本番環境で次の手順を実行します。 ### [](#runtime-fabric-コンポーネントのアップグレード)Runtime Fabric コンポーネントのアップグレード 最新のコンポーネントバージョンに関する情報については、​[「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​の情報を確認します。 1. Runtime Manager の ​**\[Runtime Fabric\]**​ タブで Runtime Fabric を選択し、Runtime Fabric に移動します。 2. **\[Upgrade to vx.x (vx.x にアップグレード)\]**​ を選択します。Runtime Fabric の状況が更新され、アップグレード手順が進行中であることが示されます。 3. 状況が ​**\[Active (アクティブ)\]**​ に移行するまで待ちます。 ほとんどの場合、アップグレードにかかる時間は 10 分未満です。状況が ​**\[Active (アクティブ)\]**​ に移行し、Runtime Fabric のバージョンが新しいバージョンを反映したら、コンポーネントのアップグレードは完了です。 Runtime Fabric と Runtime Manager の接続がアップグレード中に切断された場合、アップグレード完了後に接続が復元されます。 アップグレード後、通常は Runtime Fabric で数分間「低下」とレポートされます。これは、コントロールプレーンと同期するためです。この状態は、約 5 分後に自動的に解決されます。 ### [](#rtfctl-コマンドラインユーティリティをアップグレードする)`rtfctl`​ コマンドラインユーティリティをアップグレードする 1. ターミナルから、次のコマンドを実行します。 ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ バイナリのファイル権限を変更します。 ```copy chmod +x rtfctl ``` 3. または、​`rtfctl`​ バイナリを所有するユーザーの代わりに ​`rtfctl`​ を更新するには、次のコマンドを実行します。 ```copy `rtfctl update` ``` # RTFCTL を使用した Runtime Fabric のアップグレード Anypoint Runtime Fabric は、Runtime Fabric コマンドラインツール ​`rtfctl`​ を使用して、Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) でアップグレードできます。 ## [](#コンポーネントのアップグレードについて)コンポーネントのアップグレードについて Runtime Fabric コンポーネントをアップグレードする場合、次の機能を提供するサービスをアップグレードします。 - コントロールプレーンとの通信を容易にする - 負荷分散を行う - メトリクスを記録して転送する コンポーネントのアップグレードが可能な場合、アップグレードが利用可能になったときに表示されるボタンを使用して Runtime Manager 内でアップグレードを適用します。 Runtime Fabric コンポーネントのアップグレードでは、ノードの追加は不要です。 ### [](#使用しているコンポーネントバージョンの確認)使用しているコンポーネントバージョンの確認 `Kubeconfig`​ ファイルがあり、Kubernetes にアクセスできるローカルワークステーション、またはサポート拠点から、次のコマンドを実行します。 ```copy .rtfctl version ``` 出力は次のようになります。 ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - `rtfctl`​ 項目に ​`rtfctl`​ コマンドラインユーティリティバージョンが表示されます。 - `agent`​ 項目に Runtime Fabric コンポーネントバージョンが表示されます。
使用中の Runtime Fabric コンポーネントとバージョンは Runtime Manager の ​[Runtime Fabric]​ タブにも表示されます。アップグレードが使用できる場合は、Runtime Manager に ​[Upgrade to vx.x (vx.x にアップグレード)]​ メッセージが表示されます。
## [](#rtfctl-コマンドラインユーティリティのアップグレードについて)rtfctl コマンドラインユーティリティのアップグレードについて `rtfctl`​ コマンドラインユーティリティを使用して、Runtime Fabric を管理し、アップグレードを実行します。 コマンドラインから ​`rtfctl`​ ユーティリティをアップグレードします。 最新機能を使用できるように、必ず ​`rtfctl`​ コマンドラインユーティリティの最新バージョンを使用してください。 ## [](#アップグレードの適用)アップグレードの適用 Anypoint Runtime Fabric をアップグレードする手順は、次のとおりです。 1. Runtime Fabric コンポーネントのアップグレード 2. `rtfctl`​ コマンドラインユーティリティをアップグレードします。 本番環境をアップグレードする前に、本番以外の Runtime Fabric インスタンスで次の手順を実行し、環境との互換性を確認します。チームが新しいアプリケーションをデプロイしていないときや Runtime Fabric で既存のアプリケーションを管理していないときにアップグレードを計画します。本番以外のアップグレードが成功したら、本番環境で次の手順を実行します。 ### [](#runtime-fabric-コンポーネントのアップグレード)Runtime Fabric コンポーネントのアップグレード 最新のコンポーネントバージョンに関する情報については、​[「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​の情報を確認します。 1. Runtime Manager の ​**\[Runtime Fabric\]**​ タブで Runtime Fabric を選択し、Runtime Fabric に移動します。 2. **\[Upgrade to vx.x (vx.x にアップグレード)\]**​ を選択します。Runtime Fabric の状況が更新され、アップグレード手順が進行中であることが示されます。 3. 状況が ​**\[Active (アクティブ)\]**​ に移行するまで待ちます。 ほとんどの場合、アップグレードにかかる時間は 10 分未満です。状況が ​**\[Active (アクティブ)\]**​ に移行し、Runtime Fabric のバージョンが新しいバージョンを反映したら、コンポーネントのアップグレードは完了です。 Runtime Fabric と Runtime Manager の接続がアップグレード中に切断された場合、アップグレード完了後に接続が復元されます。 アップグレード後、通常は Runtime Fabric で数分間「低下」とレポートされます。これは、コントロールプレーンと同期するためです。この状態は、約 5 分後に自動的に解決されます。 ### [](#rtfctl-コマンドラインユーティリティをアップグレードする)`rtfctl`​ コマンドラインユーティリティをアップグレードする 1. ターミナルから、次のコマンドを実行します。 ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ バイナリのファイル権限を変更します。 ```copy chmod +x rtfctl ``` 3. または、​`rtfctl`​ バイナリを所有するユーザーの代わりに ​`rtfctl`​ を更新するには、次のコマンドを実行します。 ```copy `rtfctl update` ``` # rtfctl を使用した Runtime Fabric のインストール Runtime Fabric のコマンドラインツールである ​`rtfctl`​ を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE) 環境に Anypoint Runtime Fabric をインストールできます。
複数のインスタンスをサポートする Runtime Fabric バージョン 2.2.5 以降には ​rtfctl​ バージョン 0.4.1 以降が必要です。
rtfctl​ は常に最新バージョンの Runtime Fabric エージェントをインストールします。
`rtfctl`​ ベースのデプロイメントの制限事項を確認するには、​[「拡張性ベンチマーク」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/rtf-scale)​を参照してください。大規模なデプロイメントの場合は、最適なパフォーマンスを得るために追加リソースをエージェントに割り当てられるように、Helm ベースの Runtime Fabric デプロイメントを使用します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/)​で説明されているアーキテクチャと要件を確認した - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed-network-configuration) - Kubernetes 環境を次のようにインストールして設定している: - ACK、AKS、EKS、EKS-A、GKE、または RKE Kubernetes 環境。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョン。 - 外部要求をアプリケーションに送信するためのイングレスコントローラー。 - 利用可能な最新の Runtime Fabric エージェントバージョンを使用してクラスターを作成します。最新バージョンを使用できない場合は、 [「How to Specify the RTF Agent Version in Upgrades^ (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​を参照してください。
## [](#rtfctl-バージョンの互換性)RTFCTL バージョンの互換性 Runtime Fabric アプライアンス 1.x.x エージェントバージョンおよび Runtime Fabric 自己管理型 2.x.x エージェントバージョンとの ​`rtfctl`​ バージョンの互換性を次の表に示します。 ### [](#runtime-fabric-アプライアンス-1-x-x)Runtime Fabric アプライアンス 1.x.x 次の ​`rtfctl`​ バージョンは、アプライアンスクラスター上でサポートされているすべての Runtime Fabric エージェントと互換性があります。
RTF アプライアンス 1.x.x エージェントバージョン rtfctl​ バージョン

すべてのバージョン

0.6.0-2.release-gravity

すべてのバージョン

0.5.2-4.release-gravity

すべてのバージョン

0.3.87 から 0.4.22
### [](#runtime-fabric-自己管理型-byok-2-x-x)Runtime Fabric 自己管理型 (BYOK) 2.x.x 次の ​`rtfctl`​ バージョンは、自己管理型 Kubernetes クラスターの Runtime Fabric エージェントと互換性があります。
RTF 自己管理型 2.x.x エージェントバージョン rtfctl​ バージョン

2.4.0

0.4.1 以降

2.3.34

0.4.1 以降

2.3.1

0.4.1 以降

2.2.5

0.4.1 以降

2.1.30

0.3.87 から 1.0.12

2.1.0

0.3.87 から 1.0.12

2.0.0

0.3.87 から 1.0.12
## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[rtfctl\]**​ をクリックします。 7. **サポート責任**​の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 Runtime Manager で Runtime Fabric を作成し、\[Activation State (アクティベーション状態)\] ページを表示します。このページには、Kubernetes サービスの Runtime Fabric をインストールするために使用されるアクティベーションデータが表示されます。次のセクションで使用するために、このデータをクリップボードにコピーします。 ## [](#rtfctl-ユーティリティをダウンロードする)rtfctl ユーティリティをダウンロードする Runtime Fabric は、インストールおよび管理タスクに ​`rtfctl`​ コマンドラインユーティリティを使用します。​[「Runtime Fabric コマンドラインツールのインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​を参照してください。 1. `rtfctl`​ コマンドラインユーティリティをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ コマンドラインユーティリティのファイル権限を変更します。 ```copy sudo chmod +x rtfctl ``` ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Manager で Runtime Fabric を作成し、アクティベーションデータを取得したら、​`rtfctl`​ コマンドラインユーティリティを使用して Runtime Fabric を Kubernetes サービスにインストールします。 Kubernetes 設定が ​`\~/.kube/config`​ ディレクトリにない場合は、​`rtfctl`​ を実行する前に ​`KUBECONFIG`​ 環境変数を設定します。 ```copy export KUBECONFIG= ``` 1. Kubernetes 環境のインストールの準備が整っていることを確認します。 ```copy rtfctl validate ``` `validate`​ オプションで次のことを確認します。 - Kubernetes 環境が実行中。 - すべての必須コンポーネントが存在する。 - すべての必須サービスが使用可能。 `rtfctl`​ コマンドラインユーティリティは、Kubernetes 環境との非互換性を出力します。 2. Runtime Fabric をインストールします。 ```copy rtfctl install ``` ``​ は、Runtime Manager を使用して Runtime Fabric を作成した後に取得されたアクティベーションデータです。インストール中、​`rtfctl`​ ユーティリティには発生したエラーが表示されます。 プライベートレジストリのインストールでは、​`--cluster-ops-image`​ フラグを追加して、インストールするエージェントバージョンのリリースノートの説明に従ってイメージバージョンを選択します。 ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 アップグレードが失敗した場合に、自動的にトリガーされた以前のバージョンの Runtime Fabric にロールバックするには、ナレッジベース記事の [「How to Specify the RTF Agent Version in Upgrades (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​ナレッジベース記事を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric の概要](https://docs.mulesoft.com/jp/runtime-fabric/2.5/) - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric) # RTFCTL を使用した Runtime Fabric のインストール Runtime Fabric のコマンドラインツールである ​`rtfctl`​ を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE) 環境に Anypoint Runtime Fabric をインストールできます。
複数のインスタンスをサポートする Runtime Fabric バージョン 2.2.5 以降には ​rtfctl​ バージョン 0.4.1 以降が必要です。
rtfctl​ は常に最新バージョンの Runtime Fabric エージェントをインストールします。
`rtfctl`​ ベースのデプロイメントの制限事項を確認するには、​[「拡張性ベンチマーク」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-scale)​を参照してください。大規模なデプロイメントの場合は、最適なパフォーマンスを得るために追加リソースをエージェントに割り当てられるように、Helm ベースの Runtime Fabric デプロイメントを使用します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/)​で説明されているアーキテクチャと要件を確認した - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed-network-configuration) - Kubernetes 環境を次のようにインストールして設定している: - ACK、AKS、EKS、EKS-A、GKE、または RKE Kubernetes 環境。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョン。 - 外部要求をアプリケーションに送信するためのイングレスコントローラー。 - 利用可能な最新の Runtime Fabric エージェントバージョンを使用してクラスターを作成します。最新バージョンを使用できない場合は、 [「How to Specify the RTF Agent Version in Upgrades^ (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​を参照してください。
## [](#rtfctl-バージョンの互換性)RTFCTL バージョンの互換性 Runtime Fabric アプライアンス 1.x.x エージェントバージョンおよび Runtime Fabric 自己管理型 2.x.x エージェントバージョンとの ​`rtfctl`​ バージョンの互換性を次の表に示します。 ### [](#runtime-fabric-アプライアンス-1-x-x)Runtime Fabric アプライアンス 1.x.x 次の ​`rtfctl`​ バージョンは、アプライアンスクラスター上でサポートされているすべての Runtime Fabric エージェントと互換性があります。
RTF アプライアンス 1.x.x エージェントバージョン rtfctl​ バージョン

すべてのバージョン

0.6.0-2.release-gravity

すべてのバージョン

0.5.2-4.release-gravity

すべてのバージョン

0.3.87 から 0.4.22
### [](#runtime-fabric-自己管理型-byok-2-x-x)Runtime Fabric 自己管理型 (BYOK) 2.x.x 次の ​`rtfctl`​ バージョンは、自己管理型 Kubernetes クラスターの Runtime Fabric エージェントと互換性があります。
RTF 自己管理型 2.x.x エージェントバージョン rtfctl​ バージョン

2.6.2

0.4.1 以降

2.5.0

0.4.1 以降

2.4.0

0.4.1 以降

2.3.34

0.4.1 以降

2.3.1

0.4.1 以降

2.2.5

0.4.1 以降

2.1.30

0.3.87 から 1.0.12

2.1.0

0.3.87 から 1.0.12

2.0.0

0.3.87 から 1.0.12
## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[rtfctl\]**​ をクリックします。 7. **サポート責任**​の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 Runtime Manager で Runtime Fabric を作成し、\[Activation State (アクティベーション状態)\] ページを表示します。このページには、Kubernetes サービスの Runtime Fabric をインストールするために使用されるアクティベーションデータが表示されます。次のセクションで使用するために、このデータをクリップボードにコピーします。 ## [](#rtfctl-ユーティリティをダウンロードする)rtfctl ユーティリティをダウンロードする Runtime Fabric は、インストールおよび管理タスクに ​`rtfctl`​ コマンドラインユーティリティを使用します。​[「Runtime Fabric コマンドラインツールのインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl)​を参照してください。 1. `rtfctl`​ コマンドラインユーティリティをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ コマンドラインユーティリティのファイル権限を変更します。 ```copy sudo chmod +x rtfctl ``` ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Manager で Runtime Fabric を作成し、アクティベーションデータを取得したら、​`rtfctl`​ コマンドラインユーティリティを使用して Runtime Fabric を Kubernetes サービスにインストールします。 Kubernetes 設定が ​`\~/.kube/config`​ ディレクトリにない場合は、​`rtfctl`​ を実行する前に ​`KUBECONFIG`​ 環境変数を設定します。 ```copy export KUBECONFIG= ``` 1. Kubernetes 環境のインストールの準備が整っていることを確認します。 ```copy rtfctl validate ``` `validate`​ オプションで次のことを確認します。 - Kubernetes 環境が実行中。 - すべての必須コンポーネントが存在する。 - すべての必須サービスが使用可能。 `rtfctl`​ コマンドラインユーティリティは、Kubernetes 環境との非互換性を出力します。 2. Runtime Fabric をインストールします。 ```copy rtfctl install ``` ``​ は、Runtime Manager を使用して Runtime Fabric を作成した後に取得されたアクティベーションデータです。インストール中、​`rtfctl`​ ユーティリティには発生したエラーが表示されます。 プライベートレジストリのインストールでは、​`--cluster-ops-image`​ フラグを追加して、インストールするエージェントバージョンのリリースノートの説明に従ってイメージバージョンを選択します。 ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 アップグレードが失敗した場合に、自動的にトリガーされた以前のバージョンの Runtime Fabric にロールバックするには、ナレッジベース記事の [「How to Specify the RTF Agent Version in Upgrades (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​ナレッジベース記事を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric の概要](https://docs.mulesoft.com/jp/runtime-fabric/2.6/) - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric) # RTFCTL を使用した Runtime Fabric のインストール Runtime Fabric のコマンドラインツールである ​`rtfctl`​ を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE) 環境に Anypoint Runtime Fabric をインストールできます。
複数のインスタンスをサポートする Runtime Fabric バージョン 2.2.5 以降には ​rtfctl​ バージョン 0.4.1 以降が必要です。
rtfctl​ は常に最新バージョンの Runtime Fabric エージェントをインストールします。
`rtfctl`​ ベースのデプロイメントの制限事項を確認するには、​[「拡張性ベンチマーク」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-scale)​を参照してください。大規模なデプロイメントの場合は、最適なパフォーマンスを得るために追加リソースをエージェントに割り当てられるように、Helm ベースの Runtime Fabric デプロイメントを使用します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/)​で説明されているアーキテクチャと要件を確認した - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed-network-configuration) - Kubernetes 環境を次のようにインストールして設定している: - ACK、AKS、EKS、EKS-A、GKE、または RKE Kubernetes 環境。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョン。 - 外部要求をアプリケーションに送信するためのイングレスコントローラー。 - 利用可能な最新の Runtime Fabric エージェントバージョンを使用してクラスターを作成します。最新バージョンを使用できない場合は、 [「How to Specify the RTF Agent Version in Upgrades^ (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​を参照してください。
## [](#rtfctl-バージョンの互換性)RTFCTL バージョンの互換性 Runtime Fabric アプライアンス 1.x.x エージェントバージョンおよび Runtime Fabric 自己管理型 2.x.x エージェントバージョンとの ​`rtfctl`​ バージョンの互換性を次の表に示します。 ### [](#runtime-fabric-アプライアンス-1-x-x)Runtime Fabric アプライアンス 1.x.x 次の ​`rtfctl`​ バージョンは、アプライアンスクラスター上でサポートされているすべての Runtime Fabric エージェントと互換性があります。
RTF アプライアンス 1.x.x エージェントバージョン rtfctl​ バージョン

すべてのバージョン

0.6.0-2.release-gravity

すべてのバージョン

0.5.2-4.release-gravity

すべてのバージョン

0.3.87 から 0.4.22
### [](#runtime-fabric-自己管理型-byok-2-x-x)Runtime Fabric 自己管理型 (BYOK) 2.x.x 次の ​`rtfctl`​ バージョンは、自己管理型 Kubernetes クラスターの Runtime Fabric エージェントと互換性があります。
RTF 自己管理型 2.x.x エージェントバージョン rtfctl​ バージョン

2.7.0

1.0.79 以降

2.6.52

0.4.1 以降

2.6.42

0.4.1 以降

2.6.23

0.4.1 以降

2.6.22

0.4.1 以降

2.6.2

0.4.1 以降

2.5.0

0.4.1 以降

2.4.45

0.4.1 以降

2.4.0

0.4.1 以降

2.3.34

0.4.1 以降

2.3.1

0.4.1 以降

2.2.5

0.4.1 以降

2.1.30

0.3.87 から 1.0.12

2.1.0

0.3.87 から 1.0.12

2.0.0

0.3.87 から 1.0.12
## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[rtfctl\]**​ をクリックします。 7. **サポート責任**​の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 Runtime Manager で Runtime Fabric を作成し、\[Activation State (アクティベーション状態)\] ページを表示します。このページには、Kubernetes サービスの Runtime Fabric をインストールするために使用されるアクティベーションデータが表示されます。次のセクションで使用するために、このデータをクリップボードにコピーします。 ## [](#rtfctl-ユーティリティをダウンロードする)rtfctl ユーティリティをダウンロードする Runtime Fabric は、インストールおよび管理タスクに ​`rtfctl`​ コマンドラインユーティリティを使用します。​[「Runtime Fabric コマンドラインツールのインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl)​を参照してください。 1. `rtfctl`​ コマンドラインユーティリティをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ コマンドラインユーティリティのファイル権限を変更します。 ```copy sudo chmod +x rtfctl ``` ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Manager で Runtime Fabric を作成し、アクティベーションデータを取得したら、​`rtfctl`​ コマンドラインユーティリティを使用して Runtime Fabric を Kubernetes サービスにインストールします。 Kubernetes 設定が ​`\~/.kube/config`​ ディレクトリにない場合は、​`rtfctl`​ を実行する前に ​`KUBECONFIG`​ 環境変数を設定します。 ```copy export KUBECONFIG= ``` 1. Kubernetes 環境のインストールの準備が整っていることを確認します。 ```copy rtfctl validate ``` `validate`​ オプションで次のことを確認します。 - Kubernetes 環境が実行中。 - すべての必須コンポーネントが存在する。 - すべての必須サービスが使用可能。 `rtfctl`​ コマンドラインユーティリティは、Kubernetes 環境との非互換性を出力します。 2. Runtime Fabric をインストールします。 ```copy rtfctl install ``` ``​ は、Runtime Manager を使用して Runtime Fabric を作成した後に取得されたアクティベーションデータです。インストール中、​`rtfctl`​ ユーティリティには発生したエラーが表示されます。 プライベートレジストリのインストールでは、​`--cluster-ops-image`​ フラグを追加して、インストールするエージェントバージョンのリリースノートの説明に従ってイメージバージョンを選択します。 ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 アップグレードが失敗した場合に、自動的にトリガーされた以前のバージョンの Runtime Fabric にロールバックするには、ナレッジベース記事の [「How to Specify the RTF Agent Version in Upgrades (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​ナレッジベース記事を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric の概要](https://docs.mulesoft.com/jp/runtime-fabric/2.7/) - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric) # RTFCTL を使用した Runtime Fabric のインストール Runtime Fabric のコマンドラインツールである ​`rtfctl`​ を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Kubernetes Service Anywhere (Amazon EKS-A)、Azure Kubernetes Service (AKS)、Alibaba Cloud Container Service for Kubernetes (ACK)、Google Kubernetes Engine (GKE)、Rancher Kubernetes Engine (RKE) 環境に Anypoint Runtime Fabric をインストールできます。
複数のインスタンスをサポートする Runtime Fabric バージョン 2.2.5 以降には ​rtfctl​ バージョン 0.4.1 以降が必要です。
rtfctl​ は常に最新バージョンの Runtime Fabric エージェントをインストールします。
`rtfctl`​ ベースのデプロイメントの制限事項を確認するには、​[「拡張性ベンチマーク」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-scale)​を参照してください。大規模なデプロイメントの場合は、最適なパフォーマンスを得るために追加リソースをエージェントに割り当てられるように、Helm ベースの Runtime Fabric デプロイメントを使用します。 ## [](#始める前に)始める前に Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/)​で説明されているアーキテクチャと要件を確認した - [Runtime Fabric をサポートするようにネットワークを設定した](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed-network-configuration) - Kubernetes 環境を次のようにインストールして設定している: - ACK、AKS、EKS、EKS-A、GKE、または RKE Kubernetes 環境。その他の Kubernetes 環境はサポートされていません。 - サポートされている Kubernetes バージョン。 - 外部要求をアプリケーションに送信するためのイングレスコントローラー。 - 利用可能な最新の Runtime Fabric エージェントバージョンを使用してクラスターを作成します。最新バージョンを使用できない場合は、 [「How to Specify the RTF Agent Version in Upgrades^ (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​を参照してください。
## [](#rtfctl-バージョンの互換性)RTFCTL バージョンの互換性 Runtime Fabric アプライアンス 1.x.x エージェントバージョンおよび Runtime Fabric 自己管理型 2.x.x エージェントバージョンとの ​`rtfctl`​ バージョンの互換性を次の表に示します。 ### [](#runtime-fabric-アプライアンス-1-x-x)Runtime Fabric アプライアンス 1.x.x 次の ​`rtfctl`​ バージョンは、アプライアンスクラスター上でサポートされているすべての Runtime Fabric エージェントと互換性があります。
RTF アプライアンス 1.x.x エージェントバージョン rtfctl​ バージョン

すべてのバージョン

0.6.0-2.release-gravity

すべてのバージョン

0.5.2-4.release-gravity

すべてのバージョン

0.3.87 から 0.4.22
### [](#runtime-fabric-自己管理型-byok-2-x-x)Runtime Fabric 自己管理型 (BYOK) 2.x.x 次の ​`rtfctl`​ バージョンは、自己管理型 Kubernetes クラスターの Runtime Fabric エージェントと互換性があります。
RTF 自己管理型 2.x.x エージェントバージョン rtfctl​ バージョン

2.7.0

1.0.79 以降

2.6.52

0.4.1 以降

2.6.42

0.4.1 以降

2.6.23

0.4.1 以降

2.6.22

0.4.1 以降

2.6.2

0.4.1 以降

2.5.0

0.4.1 以降

2.4.45

0.4.1 以降

2.4.0

0.4.1 以降

2.3.34

0.4.1 以降

2.3.1

0.4.1 以降

2.2.5

0.4.1 以降

2.1.30

0.3.87 から 1.0.12

2.1.0

0.3.87 から 1.0.12

2.0.0

0.3.87 から 1.0.12
## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[rtfctl\]**​ をクリックします。 7. **サポート責任**​の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 Runtime Manager で Runtime Fabric を作成し、\[Activation State (アクティベーション状態)\] ページを表示します。このページには、Kubernetes サービスの Runtime Fabric をインストールするために使用されるアクティベーションデータが表示されます。次のセクションで使用するために、このデータをクリップボードにコピーします。 Runtime Fabric を作成すると、選択したビジネスユニットはオーナーのビジネスユニットとして設定されます。このビジネスユニットは、割り当てられたクラスター容量を報告する使用状況レポートで参照されます。インストール時に正しいビジネスユニットを選択していることを確認してください。 ## [](#rtfctl-ユーティリティをダウンロードする)rtfctl ユーティリティをダウンロードする Runtime Fabric は、インストールおよび管理タスクに ​`rtfctl`​ コマンドラインユーティリティを使用します。​[「Runtime Fabric コマンドラインツールのインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl)​を参照してください。 1. `rtfctl`​ コマンドラインユーティリティをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe ``` - MacOS (Darwin) ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl ``` - Linux ```copy curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl ``` 2. `rtfctl`​ コマンドラインユーティリティのファイル権限を変更します。 ```copy sudo chmod +x rtfctl ``` ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Manager で Runtime Fabric を作成し、アクティベーションデータを取得したら、​`rtfctl`​ コマンドラインユーティリティを使用して Runtime Fabric を Kubernetes サービスにインストールします。 Kubernetes 設定が ​`\~/.kube/config`​ ディレクトリにない場合は、​`rtfctl`​ を実行する前に ​`KUBECONFIG`​ 環境変数を設定します。 ```copy export KUBECONFIG= ``` 1. Kubernetes 環境のインストールの準備が整っていることを確認します。 ```copy rtfctl validate ``` `validate`​ オプションで次のことを確認します。 - Kubernetes 環境が実行中。 - すべての必須コンポーネントが存在する。 - すべての必須サービスが使用可能。 `rtfctl`​ コマンドラインユーティリティは、Kubernetes 環境との非互換性を出力します。 2. Runtime Fabric をインストールします。 ```copy rtfctl install ``` ``​ は、Runtime Manager を使用して Runtime Fabric を作成した後に取得されたアクティベーションデータです。インストール中、​`rtfctl`​ ユーティリティには発生したエラーが表示されます。 プライベートレジストリのインストールでは、​`--cluster-ops-image`​ フラグを追加して、インストールするエージェントバージョンのリリースノートの説明に従ってイメージバージョンを選択します。 ```copy rtfctl install --cluster-ops-image /mulesoft/rtf-cluster-ops: ``` ## [](#mule-ライセンスキーの挿入)Mule ライセンスキーの挿入 インストール中に Mule ライセンスキーを追加しなかった場合は、​`rtfctl`​ コマンドラインユーティリティまたは Helm を使用して追加できます。 ライセンスキーをインストールする前に Base64 形式にエンコードしてください。 ### [](#ライセンスキーのエンコード)ライセンスキーのエンコード - MacOS では、次のコマンドを実行します。 ```copy base64 -b 0 -i ``` - Unix では、次のコマンドを実行します。 ```copy base64 -w0 ``` - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 ```copy $BASE64_ENCODED_LICENSE=[convert]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ``` ### [](#rtfctl-を使用してライセンスキーを適用する)rtfctl を使用してライセンスキーを適用する 1. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、次のコマンドを実行します。 ```copy rtfctl apply mule-license $BASE64_ENCODED_LICENSE ``` ファイルパスを直接指定する Mule ライセンスを適用することもできます。 ```copy rtfctl apply mule-license --file /path/to/license.lic ```
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
2. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 ```copy rtfctl get mule-license ``` ### [](#helm-を使用したライセンスキーの適用)Helm を使用したライセンスキーの適用 Helm を使用してライセンスを適用するには、次のコマンドを実行します。 ```copy helm upgrade runtime-fabric rtf/rtf-agent --set muleLicense=$BASE64_ENCODED_LICENSE -n rtf --reuse-values --version ``` ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定 イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#ロールバックの実行)ロールバックの実行 アップグレードが失敗した場合に、自動的にトリガーされた以前のバージョンの Runtime Fabric にロールバックするには、ナレッジベース記事の [「How to Specify the RTF Agent Version in Upgrades (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​ナレッジベース記事を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric の概要](https://docs.mulesoft.com/jp/runtime-fabric/2.8/) - [Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) # rtfctl を使用したアプリケーションプロパティ値の保護 セキュアなアプリケーションプロパティは、Runtime Fabric クラスターのローカルに追加され、安全に保存され、環境ごとにスコープ設定されます。これらのプロパティには、スコープ設定された環境にカスタムプロパティとしてデプロイされた Mule アプリケーションから暗号化されていない形式でアクセスできます。 Runtime Fabric の保護されたプロパティは、アプリケーションレベルのプロパティよりも常に優先されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric の保護されたプロパティをローカルで管理するには、​`rtfctl`​ ユーティリティが必要です。セキュアプロパティの管理を続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​する手順を実行します。 ## [](#セキュアプロパティを設定する)セキュアプロパティを設定する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric にセキュアプロパティを設定します。 ```copy rtfctl apply secure-property --key --value --app-namespace --namespace ``` - ****​: Mule アプリケーションで値を参照するために使用されるセキュアプロパティのキー。 - ****​: 保存するセキュアプロパティの値。 - ****​: このセキュアプロパティをスコープ設定する Anypoint 環境。この環境にデプロイされたアプリケーションのみがこのセキュアプロパティにアクセスできます。 - ****​:システムの名前空間スコープで、デフォルトは ​`rtf`​ です。 ## [](#セキュアプロパティを表示する)セキュアプロパティを表示する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric に適用されるセキュアプロパティを表示します。 ```copy sudo ./rtfctl get secure-properties -n ``` - ****​: セキュアプロパティを表示する Anypoint 環境 ID。 ## [](#セキュアプロパティへのアクセス)セキュアプロパティへのアクセス `${my.property.name}`​ を使用して、Mule アプリケーション内からセキュアプロパティにアクセスできます。 ## [](#セキュアプロパティを削除する)セキュアプロパティを削除する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、特定の名前空間で Runtime Fabric からセキュアプロパティを削除します。 ```copy sudo ./rtfctl delete secure-property -n ``` - ****​: セキュアプロパティを参照するために Mule アプリケーションで使用されるキー。 - ****​: セキュアプロパティが適用される名前空間。 ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl) - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-proxy-self) # rtfctl を使用したセキュアプロパティの管理 セキュアプロパティは、Runtime Fabric クラスターのローカルに追加され、安全に保存され、環境ごとにスコープ設定されます。セキュアプロパティには、スコープ設定された環境にカスタムプロパティとしてデプロイされた Mule アプリケーションから暗号化されていない形式でアクセスできます。 Runtime Fabric のセキュアプロパティは、アプリケーションレベルのプロパティよりも常に優先されます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のセキュアプロパティをローカルで管理するには、​`rtfctl`​ ユーティリティが必要です。セキュアプロパティの管理を続行する前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​する手順を実行します。 ## [](#セキュアプロパティを設定する)セキュアプロパティを設定する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric にセキュアプロパティを設定します。 sudo ./rtfctl apply secure-property --key --value -n - ****​: Mule アプリケーションで値を参照するために使用されるセキュアプロパティのキー。 - ****​: 保存するセキュアプロパティの値。 - ****​: このセキュアプロパティをスコープ設定する Anypoint 環境 ID。この環境にデプロイされたアプリケーションのみがこのセキュアプロパティにアクセスできます。 ## [](#セキュアプロパティを表示する)セキュアプロパティを表示する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドのプレースホルダー項目を置き換えて実行し、特定の環境で Runtime Fabric に適用されるセキュアプロパティを表示します。 sudo ./rtfctl get secure-properties -n - ****​: セキュアプロパティを表示する Anypoint 環境 ID。 ## [](#セキュアプロパティへのアクセス)セキュアプロパティへのアクセス `${my.property.name}`​ を使用して、Mule アプリケーション内からセキュアプロパティにアクセスできます。 ## [](#セキュアプロパティを削除する)セキュアプロパティを削除する 1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、特定の名前空間で Runtime Fabric からセキュアプロパティを削除します。 sudo ./rtfctl delete secure-property -n - ****​: セキュアプロパティを参照するために Mule アプリケーションで使用されるキー。 - ****​: セキュアプロパティが適用される名前空間。 ## [](#関連情報)関連情報 - [rtfctl のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl) - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-proxy) # rtfctl を使用した自己管理型 Kubernetes の Runtime Fabric のアップグレード 自己管理型 Kubernetes の Anypoint Runtime Fabric をアップグレードするには、Runtime Fabric コンポーネントおよび ​`rtfctl`​ コマンドラインユーティリティをアップグレードします。 ## [](#コンポーネントのアップグレードについて)コンポーネントのアップグレードについて Runtime Fabric コンポーネントをアップグレードする場合、次の機能を提供するサービスをアップグレードします。 - コントロールプレーンとの通信を容易にする - 負荷分散を行う - メトリクスを記録して転送する コンポーネントのアップグレードが可能な場合、アップグレードが利用可能になったときに表示されるボタンを使用して Runtime Manager 内でアップグレードを適用します。 Runtime Fabric コンポーネントのアップグレードでは、ノードの追加は不要です。 ### [](#使用しているコンポーネントバージョンの確認)使用しているコンポーネントバージョンの確認 `Kubeconfig`​ ファイルがあり、Kubernetes にアクセスできるローカルワークステーション、またはサポート拠点から、次のコマンドを実行します。 ```none .rtfctl version ``` 出力は次のようになります。 ```none $ ./rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.6 kubernetes 1.19.6-eks-49a6c0 ``` - `rtfctl`​ 項目に ​`rtfctl`​ コマンドラインユーティリティバージョンが表示されます。 - `agent`​ 項目に Runtime Fabric コンポーネントバージョンが表示されます。
使用中の Runtime Fabric コンポーネントとバージョンは Runtime Manager の ​[Runtime Fabric]​ タブにも表示されます。アップグレードが使用できる場合は、Runtime Manager に ​[Upgrade to vx.x (vx.x にアップグレード)]​ メッセージが表示されます。
## [](#rtfctl-コマンドラインユーティリティのアップグレードについて)rtfctl コマンドラインユーティリティのアップグレードについて `rtfctl`​ コマンドラインユーティリティを使用して、Runtime Fabric を管理し、アップグレードを実行します。 コマンドラインから ​`rtfctl`​ ユーティリティをアップグレードします。 最新機能を使用できるように、必ず ​`rtfctl`​ コマンドラインユーティリティの最新バージョンを使用してください。 ## [](#アップグレードの適用)アップグレードの適用 自己管理型 Kubernetes の Anypoint Runtime Fabric をアップグレードするには、次の手順を実行します。 1. Runtime Fabric コンポーネントのアップグレード 2. `rtfctl`​ コマンドラインユーティリティをアップグレードします。 本番環境をアップグレードする前に、本番以外の Runtime Fabric インスタンスで次の手順を実行し、環境との互換性を確認します。チームが新しいアプリケーションをデプロイしていないときや Runtime Fabric で既存のアプリケーションを管理していないときにアップグレードを計画します。本番以外のアップグレードが成功したら、本番環境で次の手順を実行します。 [「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes)​の情報を確認します。 ### [](#runtime-fabric-コンポーネントのアップグレード)Runtime Fabric コンポーネントのアップグレード 最新のコンポーネントバージョンに関する情報については、​[「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes)​の情報を確認します。 1. Runtime Manager の ​**\[Runtime Fabric\]**​ タブで Runtime Fabric を選択し、Runtime Fabric に移動します。 2. **\[Upgrade to vx.x (vx.x にアップグレード)\]**​ を選択します。Runtime Fabric の状況が更新され、アップグレード手順が進行中であることが示されます。 3. 状況が ​**\[Active (アクティブ)\]**​ に移行するまで待ちます。 ほとんどの場合、アップグレードにかかる時間は 10 分未満です。状況が ​**\[Active (アクティブ)\]**​ に移行し、Runtime Fabric のバージョンが新しいバージョンを反映したら、コンポーネントのアップグレードは完了です。 Runtime Fabric と Runtime Manager の接続がアップグレード中に切断された場合、アップグレード完了後に接続が復元されます。 アップグレード後、通常は Runtime Fabric で数分間「低下」とレポートされます。これは、コントロールプレーンと同期するためです。この状態は、約 5 分後に自動的に解決されます。 ### [](#rtfctl-コマンドラインユーティリティをアップグレードする)`rtfctl`​ コマンドラインユーティリティをアップグレードする 1. ターミナルから、次のコマンドを実行します。 curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ バイナリのファイル権限を変更します。 chmod +x rtfctl 3. または、​`rtfctl`​ バイナリを所有するユーザーの代わりに ​`rtfctl`​ を更新するには、次のコマンドを実行します。 \`rtfctl update\` # Runtime Fabric Release Notes - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Runtime Fabric Release Notes - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Runtime Fabric Release Notes - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Runtime Fabric Release Notes - Runtime Fabric - [Runtime Fabric 3.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-3.x.x) - [Runtime Fabric 2.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x) - [Runtime Fabric 1.x.x Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes) - Runtime Fabric Appliance - [Runtime Fabric Installer Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-installer-release-notes) - [Runtime Fabric Install Scripts Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-install-scripts-release-notes) - [Runtime Fabric Command Line Tool (rtfctl) Release Notes](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-command-line-tool-release-notes-appliance) - Mule Runtime Engine Patch Updates - [Mule Runtime Patch Updates Release Notes for Runtime Fabric](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) - Runtime Fabric Mule Action Image - [Runtime Fabric Mule Action Image](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-rtf-mule-action) For versions of Runtime Fabric that have reached [end of life](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf), see the [Anypoint Runtime Fabric Release Notes Archive](https://archive.docs.mulesoft.com/release-notes/runtime-fabric/runtime-fabric-release-notes) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # Runtime Fabric コアソフトウェアの Kubernetes 権限 次の表は、Runtime Fabric エージェントに必要な Kubernetes アクセス権限のリストです。 これらのアクセス権限は Runtime Fabric Helm チャートの一部であり、インストールまたはアップグレード中に自動的に適用されます。
いずれのコアソフトウェアアクセス権限も拡張または変更できません。その代わり、Runtime Fabric 承認済み名前空間のユースケース向けに ​ClusterRole​ と ​Rolebindings​ を作成して適用します。Runtime Fabric での承認済み名前空間の設定を参照してください。
名前空間 API グループ Kubernetes リソース 動詞

<rtf-namespace>

extensions、apps

deployments、deployments/scale、daemonsets、replicasets

*

“”

pods、pods/log、pods/portforward、pods/exec、configmaps、secrets、services、namespaces、nodes、serviceaccounts、resourcequotas、events、limitranges

*

バッチ

jobs、cronjobs

*

拡張機能

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings、clusterroles、clusterrolebindings、roles

*

extensions、networking.k8s.io

ingresses、networkpolicies

*

rtf.mulesoft.com

persistencegateways、kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*
## [](#関連情報)関連情報 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtfctl-permissions) - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-mule-app-permissions) # Runtime Fabric コアソフトウェアの Kubernetes 権限 次の表は、Runtime Fabric エージェントに必要な Kubernetes アクセス権限のリストです。 これらのアクセス権限は Runtime Fabric Helm チャートの一部であり、インストールまたはアップグレード中に自動的に適用されます。
いずれのコアソフトウェアアクセス権限も拡張または変更できません。その代わり、Runtime Fabric 承認済み名前空間のユースケース向けに ​ClusterRole​ と ​Rolebindings​ を作成して適用します。Runtime Fabric での承認済み名前空間の設定を参照してください。
名前空間 API グループ Kubernetes リソース 動詞

<rtf-namespace>

extensions、apps

deployments、deployments/scale、daemonsets、replicasets

*

“”

pods、pods/log、pods/portforward、pods/exec、configmaps、secrets、services、namespaces、nodes、serviceaccounts、resourcequotas、events、limitranges

*

バッチ

jobs、cronjobs

*

拡張機能

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings、clusterroles、clusterrolebindings、roles

*

extensions、networking.k8s.io

ingresses、networkpolicies

*

rtf.mulesoft.com

persistencegateways、kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*
## [](#関連情報)関連情報 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtfctl-permissions) - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-mule-app-permissions) # Runtime Fabric コアソフトウェアの Kubernetes 権限 次の表は、Runtime Fabric エージェントに必要な Kubernetes アクセス権限のリストです。 これらのアクセス権限は Runtime Fabric Helm チャートの一部であり、インストールまたはアップグレード中に自動的に適用されます。
いずれのコアソフトウェアアクセス権限も拡張または変更できません。その代わり、Runtime Fabric 承認済み名前空間のユースケース向けに ​ClusterRole​ と ​Rolebindings​ を作成して適用します。Runtime Fabric での承認済み名前空間の設定を参照してください。
名前空間 API グループ Kubernetes リソース 動詞

<rtf-namespace>

extensions、apps

deployments、deployments/scale、daemonsets、replicasets

*

“”

pods、pods/log、pods/portforward、pods/exec、configmaps、secrets、services、namespaces、nodes、serviceaccounts、resourcequotas、events、limitranges

*

バッチ

jobs、cronjobs

*

拡張機能

jobs

*

networking.k8s.io

networkpolicies

*

rbac.authorization.k8s.io

rolebindings、clusterroles、clusterrolebindings、roles

*

extensions、networking.k8s.io

ingresses、networkpolicies

*

rtf.mulesoft.com

persistencegateways、kubernetestemplates

*

autoscaling

horizontalpodautoscalers

*
## [](#関連情報)関連情報 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtfctl-permissions) - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-mule-app-permissions) # Runtime Fabric コマンドラインツールの使用 Runtime Fabric をローカルで管理するには、​`rtfctl`​ コマンドラインツールをインストールして使用します。​`rtfctl`​ ツールでは次のアクションがサポートされています。 - Runtime Fabric の状況を取得する。 - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する。 - 実行中のアプリケーションのメモリ使用量を表示する。 - プロキシ設定を管理する。 - セキュアプロパティを管理する。 - Mule ライセンスを管理する。 - アラート送信者メールアドレスを管理します。 ## [](#rtfctl-のインストール)rtfctl のインストール

このセクション内のタスクは、IT 管理者が実行する必要があります。

AKS 用に自己管理型 Kubernetes の Runtime Fabric を使用していて、AKS で管理される Azure AD インテグレーションが有効になっている場合、次のコマンドで rtfctl コマンドを実行するために必要なログイン情報が返されます。

az aks get-credentials --name <NAME> --resource-group <RESOURCE_GROUP> --admin
自己管理型 Kubernetes の Runtime Fabric の場合: 1. `rtfctl`​ コマンドラインツールをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ コマンドラインツールのファイル権限を変更します。 sudo chmod +x rtfctl Runtime Fabric アプライアンスの場合: 1. `rtfctl`​ コマンドラインツールをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-appliance-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-appliance-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-appliance/latest -o rtfctl 2. `rtfctl`​ コマンドラインツールのファイル権限を変更します。 sudo chmod +x rtfctl ### [](#コマンドの実行)コマンドの実行 VM/ベアメタルの Runtime Fabric の場合、コントローラーノードから ​`rtfctl`​ を実行する必要があります。ディレクトリ ​`` /opt/anypoint/runtimefabric/` ``​ の ​`rtfctl`​ バイナリ。現在の作業ディレクトリも ​`/opt/anypoint/runtimefabric/`​ であることを確認します。ツールでは、クラスターを管理するための必須設定が検出されます。 自己管理型 Kubernetes の Runtime Fabric の場合、 [「Organizing Cluster Access Using kubeconfig Files (kubeconfig を使用したクラスターアクセスの整理)」](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​で説明されているように ​`rtfctl`​ で kubeconfig ファイルがコンシュームされます。この方法を使用して、管理するクラスターを設定します。​`rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 - 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 - サポートされているすべてのコマンドのリストを表示するには、​`rtfctl -h`​ を実行します。 - 特定のコマンドの詳細については、​`rtfctl -h`​ を実行します。 ### [](#プロキシ設定の確認)プロキシ設定の確認 コマンドを実行すると、​`rtfctl`​ は環境にプロキシ設定があるかどうかを確認します。このツールは ​`NO_PROXY`​ キー (大文字) を探して、​`NO_PROXY`​ が使用されていない場合は ​`no_proxy`​ キー (小文字) を受け入れます。両方のキーがある場合、​`rtfctl`​ は ​`NO_PROXY`​ を使用します。​`rtfctl`​ ツールは、プロキシ設定に従うようにローカルの Kubernetes コンテキスト内でキーを設定します。 ## [](#runtime-fabric-アプライアンスを管理するコマンド)Runtime Fabric アプライアンスを管理するコマンド Runtime Fabric アプライアンスを管理するには次のコマンドを使用します。
ここに挙げたコマンドは VM/ベアメタルの Runtime Fabric のみで使用できます。
### [](#appliance)`appliance` Runtime Fabric アプライアンスで操作を実行します。 - アラート送信者メールを適用する rtfctl appliance apply alert-smtp-from "@.com" - 証明書バンドルをダウンロードすることによって期限切れのクライアント証明書を更新する rtfctl appliance renew-expired-client-cert --auth 'Bearer ' --url 'https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//certificate-bundle' - 事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する rtfctl appliance renew-expired-client-cert --file - 最新のスクリプトを使用して Runtime Fabric コンポーネントを再インストールする rtfctl appliance reinstall - 最新のスクリプトをダウンロードせずに Runtime Fabric コンポーネントを再インストールする rtfctl appliance reinstall --skip-download - アプライアンス診断レポートを生成する rtfctl appliance report --file .tar.gz - アプライアンスのアップグレードが失敗した後に既存のバージョンへのロールバックを実行する rtfctl appliance rollback - ロールバックを実行せずにロールバックのステップを表示する rtfctl appliance rollback --dry-run - アプライアンスのアップグレードが失敗した後に確認を促さずに既存のバージョンへのロールバックを実行する rtfctl appliance rollback --confirm - 事前ダウンロード済みパッケージを使用してクラスターをアップグレードする rtfctl appliance upgrade --file runtimefabric-.tar.gz - パッケージをダウンロードすることによってクラスターをアップグレードする rtfctl appliance upgrade --url https:/// ## [](#runtime-fabric-を設定するコマンド)Runtime Fabric を設定するコマンド Runtime Fabric を設定するには次のコマンドを使用します。
コマンド 説明

apply

Runtime Fabric 設定に変更を適用する

update

rtfctl を更新する

wait

Runtime Fabric コンポーネントが準備完了になるのを待機する
### [](#apply)`apply` Runtime Fabric 設定に変更を適用します。 - HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: - プロキシをバイパスするホスト名を指定して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --no-proxy "DOMAIN.com,DOMAIN2.com" - 認証を使用して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://username:password@.com: - HTTP プロキシ設定をクリアする rtfctl apply http-proxy "" --no-proxy "" - 特定のポッドにイングレス configMap を適用する

自己管理型 Kubernetes の Runtime Fabric バージョン 1.8 および 1.9 のみ
rtfctl apply ingress-configmap "//"\` - セキュアプロパティを適用する rtfctl apply secure-property --key --value -n - ホストノードにシステム設定を適用する rtfctl apply system-configuration - 最新のスクリプトをダウンロードせずにホストノードにシステム設定を適用する rtfctl apply system-configuration --skip-download - Mule ライセンスを適用する rtfctl apply mule-license '' - 監視プロキシを適用する rtfctl apply monitoring-proxy "socks5://:@:"\` - 監視プロキシ設定をクリアする rtfctl apply monitoring-proxy "" ### [](#update)`update` `rtfctl`​ を更新します。 - US コントロールプレーンから更新する rtfctl update - EU コントロールプレーンから ​`rtfctl`​ を更新する rtfctl update --host eu1.anypoint.mulesoft.com ### [](#wait)`wait`​ Runtime Fabric コンポーネントが準備完了になるのを待機する - 待機する秒数を指定する rtfctl wait - 待機をタイムアウトするまでの秒数を指定する (デフォルトは 600 秒) rtfctl wait --timeout ## [](#runtime-fabric-のインストールとアップグレードを行うコマンド)Runtime Fabric のインストールとアップグレードを行うコマンド Runtime Fabric のインストールやアップグレード、またはバックアップや復元を実行するときには次のコマンドを使用します。
コマンド 説明

install

Runtime Fabric をインストールする

backup

ローカルの Runtime Fabric の状態をバックアップする

restore

ローカルの Runtime Fabric の状態をバックアップから復元する

validate

Runtime Fabric インストールのクラスターを検証する

version

Runtime Fabric のバージョン情報を表示する
### [](#install)`install` - Runtime Fabric をインストールする rtfctl install - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl install --image-pull-registry --image-pull-secret ### [](#backup)`backup`​ ローカルの Runtime Fabric の状態をバックアップする。 rtfctl backup /var/backups/.tar.gz ### [](#restore)`restore`​ ローカルの Runtime Fabric の状態をバックアップから復元する rtfctl restore /var/backups/.tar.gz ### [](#validate)`validate`​ Runtime Fabric インストールのクラスターを検証する - 検証チェックを実行する rtfctl validate - 検証チェックを実行し、プロキシ設定を含む ​`fabric.tf`​ 設定ファイルを渡す rtfctl validate -f プロキシを使用してインストールを検証するには、​`settings`​ ファイル内でプロキシ設定を指定する必要があります。 MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://proxy-domain.com: ### [](#version)`version`​ Runtime Fabric のバージョン情報を表示する rtfctl version ## [](#runtime-fabric-上のアプリケーションを管理するコマンド)Runtime Fabric 上のアプリケーションを管理するコマンド Runtime Fabric にデプロイされたアプリケーションを管理するには次のコマンドを使用します。
コマンド 説明

delete

セキュアプロパティを削除する

describe

アプリケーションの詳細を表示する

disk

アプリケーションのディスク使用量を表示する

memory

ポッド内の JVM メモリ使用量を表示する

package

アプリケーションのデバッグ情報パッケージを作成する

restart

アプリケーションを再起動する

heapdump

JVM ヒープダンプを取得する

threaddump

JVM スレッドダンプを取得する
### [](#delete)`delete`​ セキュアプロパティを削除する rtfctl delete secure-property -n ### [](#describe)`describe`​ 特定の名前空間でのアプリケーションの詳細を表示する rtfctl describe app --namespace ### [](#disk)`disk` アプリケーションのディスク使用量を表示する - デフォルトである最初のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk - 特定のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --details --pod ### [](#memory)`memory`​ ポッド内の JVM メモリ使用量を表示する - 各レプリカの JVM メモリを取得する rtfctl memory - 特定のレプリカの JVM メモリを取得する rtfctl memory --pod -pod-1 ### [](#package)`package`​ アプリケーションのデバッグ情報パッケージを作成する - デフォルトである最初のポッドを使用してアプリケーションのパッケージを作成する rtfctl package - アプリケーション、ポリシー、​`.mule`​ ディレクトリを含むアプリケーションのパッケージを作成する rtfctl package --apps --policies --dotmule - ヒープダンプを含むアプリケーションのパッケージを作成する rtfctl package --heap-dump ### [](#restart)`restart`​ アプリケーションを再起動する rtfctl restart my-app ### [](#heapdump)`heapdump`​ JVM ヒープダンプをトリガーする - デフォルトである最初のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`` `/tmp/dump.hprof ``​ として保存する rtfctl heapdump /tmp/dump.hprof - 特定のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`/tmp/dump.hprof`​ として保存する rtfctl heapdump /tmp/dump.hprof --pod ### [](#threaddump)`threaddump`​ JVM スレッドダンプをトリガーする - デフォルトである最初のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump - 特定のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump p --pod ## [](#runtime-fabric-のトラブルシューティングを行うコマンド)Runtime Fabric のトラブルシューティングを行うコマンド Runtime Fabric のトラブルシューティングを行うには次のコマンドを使用します。
コマンド 説明

get

1 つ以上のリソースを表示する

ping

ネットワーク接続をテストする

report

診断レポートを生成する

status

Runtime Fabric の状況を表示する

test

Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する
### [](#get)`get` 1 つ以上のリソースを表示する - すべての環境のすべてのアプリケーションのリストを出力する rtfctl get apps - 特定の環境のすべてのアプリケーションのリストを出力する rtfctl get apps --namespace - HTTP プロキシ設定を表示する rtfctl get http-proxy - 監視プロキシ設定を表示する rtfctl get monitoring-proxy - セキュアプロパティを表示する rtfctl get secure-properties - Mule ライセンスを表示する rtfctl get mule-license - Runtime Fabric レジストリのログイン情報を表示する rtfctl get registry-credentials ### [](#ping)`ping`​ ネットワーク接続をテストする - デフォルトである最初のレプリカを使用してアプリケーション内部から example.com に ping する rtfctl ping example.com - デフォルトである最初のレプリカを使用してアプリケーション内部からポート ​`12345`​ 上で example.com への接続を試みる rtfctl ping --port 12345 ### [](#report)`report`​ ​`rtf-report.tar.gz`​ に診断レポートを生成する rtfctl report --file .tar.gz ### [](#status)`status` Runtime Fabric の状況を表示する - JSON で状況出力を表示する rtfctl status --output json - Kubernetes DNS の健全性を確認する rtfctl status dns-check -- ":" ### [](#test)`test`​ Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する。 - 任意のノードでのチェックをスケジュールする rtfctl test outbound-network - `node-label`​ パラメーターを満たすノードでのチェックをスケジュールする rtfctl test outbound-network -- ":" - すべてのノードでのチェックをスケジュールする rtfctl test outbound-network --all ## [](#使用方法)使用方法 ### [](#mule-ライセンスのインストール)Mule ライセンスのインストール 1. [「Mule ライセンスキーの Base64 でのエンコード」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-manual#base64-encode-your-mule-license-key)​の手順に従って、必ずライセンスを Base64 でエンコードします。 2. 次のコマンドを実行します。 $ sudo ./rtfctl apply mule-license '' Updating rtf namespace... OK ### [](#ヒープダンプの取得)ヒープダンプの取得 $ sudo /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof 追加の情報については、​`rtfctl heapdump -h`​ コマンドを実行します。 ### [](#複数のレプリカとの連携)複数のレプリカとの連携 `--pod`​ フラグを受け入れるアプリケーション管理コマンドの場合、​`describe`​ コマンドを使用してレプリカのリストを取得できます。 $ sudo ./rtfctl describe apps hello-world --namespace bed42b62-XXXX Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status ---- ------ hello-world-77f5897949-z54gb Pending ## [](#rtfctl-出力の理解)rtfctl 出力の理解 `rtfctl`​ コマンドラインツールでは通常、他のアプリケーションやシステムツールを呼び出し、これらの呼び出しの出力は標準出力および標準エラー出力に送信されます。この出力は実行される各操作のコンテキストで記述されます。 操作が成功したか失敗したかを明確にするために、​`rtfctl`​ コマンドラインツールには最も詳細なコマンドの最後の出力行が含まれます。通常の操作には、停止しているシステムユニットをもう一度停止しようとした場合など、中間の​_失敗_​メッセージが含まれる場合があります。 メッセージが問題を示しているかどうか疑わしい場合は、システム管理者と話し合うか、MuleSoft サポートにお問い合わせください。 ## [](#関連情報)関連情報 - [VM/ベアメタルの Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-proxy) - [自己管理型 Kubernetes の Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-proxy-self) - [Runtime Fabric でのセキュアプロパティの管理](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-secure-properties) # Runtime Fabric コマンドラインツールの使用 Runtime Fabric をローカルで管理するには、​`rtfctl`​ コマンドラインツールをインストールして使用します。​`rtfctl`​ ツールでは次のアクションがサポートされています。 - Runtime Fabric の状況を取得する。 - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する。 - 実行中のアプリケーションのメモリ使用量を表示する。 - プロキシ設定を管理する。 - セキュアプロパティを管理する。 - Mule ライセンスを管理する。 - アラート送信者メールアドレスを管理します。 デフォルトの名前空間 (rtf) を使用している場合は、追加のフラグ ​`--namespace `​ を指定する必要はありません。このフラグは rtfctl バージョン 0.4.1 以降のみで導入されています。 ## [](#rtfctl-のインストール)rtfctl のインストール

このセクション内のタスクは、IT 管理者が実行する必要があります。

AKS 用に Runtime Fabric を使用していて、AKS で管理される Azure AD インテグレーションが有効になっている場合、次のコマンドで rtfctl コマンドを実行するために必要なログイン情報が返されます。

az aks get-credentials --name <NAME> --resource-group <RESOURCE_GROUP> --admin
1. `rtfctl`​ コマンドラインツールをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ コマンドラインツールのファイル権限を変更します。 chmod +x rtfctl ### [](#コマンドの実行)コマンドの実行 [「Organizing Cluster Access Using kubeconfig Files (kubeconfig を使用したクラスターアクセスの整理)」](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​で説明されているように ​`rtfctl`​ コマンドラインツールで kubeconfig ファイルがコンシュームされます。この方法を使用して、管理するクラスターを設定します。​`rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 - 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 - サポートされているすべてのコマンドのリストを表示するには、​`rtfctl -h`​ を実行します。 - 特定のコマンドの詳細については、​`rtfctl -h`​ を実行します。 ### [](#プロキシ設定の確認)プロキシ設定の確認 コマンドを実行すると、​`rtfctl`​ は環境にプロキシ設定があるかどうかを確認します。このツールは ​`NO_PROXY`​ キー (大文字) を探して、​`NO_PROXY`​ が使用されていない場合は ​`no_proxy`​ キー (小文字) を受け入れます。両方のキーがある場合、​`rtfctl`​ は ​`NO_PROXY`​ を使用します。​`rtfctl`​ ツールは、プロキシ設定に従うようにローカルの Kubernetes コンテキスト内でキーを設定します。 ## [](#runtime-fabric-を設定するコマンド)Runtime Fabric を設定するコマンド Runtime Fabric を設定するには次のコマンドを使用します。
コマンド 説明

apply

Runtime Fabric 設定に変更を適用する

update

rtfctl を更新する

wait

Runtime Fabric コンポーネントが準備完了になるのを待機する
### [](#apply)`apply` Runtime Fabric 設定に変更を適用します。
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
- HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --namespace - プロキシをバイパスするホスト名を指定して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - 認証を使用して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://:@: --namespace - HTTP プロキシ設定をクリアする rtfctl apply http-proxy "" --no-proxy "" --namespace - セキュアプロパティを適用する rtfctl apply secure-property --key --value --app-namespace --namespace - ホストノードにシステム設定を適用する rtfctl apply system-configuration - 最新のスクリプトをダウンロードせずにホストノードにシステム設定を適用する rtfctl apply system-configuration --skip-download - Mule ライセンスを適用する rtfctl apply mule-license --namespace - 監視プロキシを適用する rtfctl apply monitoring-proxy http://: --namespace - 監視プロキシ設定をクリアする rtfctl apply monitoring-proxy "" --namespace ### [](#update)`update` `rtfctl`​ を更新します。 - US コントロールプレーンから更新する rtfctl update - EU コントロールプレーンから ​`rtfctl`​ を更新する rtfctl update --host eu1.anypoint.mulesoft.com ### [](#wait)`wait`​ Runtime Fabric コンポーネントが準備完了になるのを待機する - 待機する秒数を指定する rtfctl wait --namespace - 待機をタイムアウトするまでの秒数を指定する (デフォルトは 600 秒) rtfctl wait --timeout --namespace ## [](#runtime-fabric-のインストールとアップグレードを行うコマンド)Runtime Fabric のインストールとアップグレードを行うコマンド Runtime Fabric のインストールやアップグレード、またはバックアップや復元を実行するときには次のコマンドを使用します。
コマンド 説明

install

Runtime Fabric をインストールする

backup

ローカルの Runtime Fabric の状態をバックアップする

restore

ローカルの Runtime Fabric の状態をバックアップから復元する

validate

Runtime Fabric インストールのクラスターを検証する

version

Runtime Fabric のバージョン情報を表示する
### [](#install)`install` - Runtime Fabric をインストールする rtfctl install - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl install --image-pull-registry --image-pull-secret ### [](#backup)`backup`​ ローカルの Runtime Fabric の状態をバックアップする。 rtfctl backup .tar.gz --namespace ### [](#restore)`restore`​ ローカルの Runtime Fabric の状態をバックアップから復元する rtfctl restore .tar.gz --namespace ### [](#validate)`validate`​ Runtime Fabric インストールのクラスターを検証する - 検証チェックを実行する rtfctl validate - 検証チェックを実行し、プロキシ設定を含む ​`fabric.tf`​ 設定ファイルを渡す rtfctl validate -f プロキシを使用してインストールを検証するには、​`settings`​ ファイル内でプロキシ設定を指定する必要があります。 MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl validate --image-pull-registry --image-pull-secret ### [](#version)`version`​ Runtime Fabric のバージョン情報を表示する rtfctl version --namespace ## [](#runtime-fabric-上のアプリケーションを管理するコマンド)Runtime Fabric 上のアプリケーションを管理するコマンド Runtime Fabric にデプロイされたアプリケーションを管理するには次のコマンドを使用します。
コマンド 説明

delete

セキュアプロパティを削除する

describe

アプリケーションの詳細を表示する

disk

アプリケーションのディスク使用量を表示する

memory

ポッド内の JVM メモリ使用量を表示する

package

アプリケーションのデバッグ情報パッケージを作成する

restart

アプリケーションを再起動する

heapdump

JVM ヒープダンプを取得する

threaddump

JVM スレッドダンプを取得する
### [](#delete)`delete`​ セキュアプロパティを削除する rtfctl delete secure-property -n ### [](#describe)`describe`​ 特定の名前空間でのアプリケーションの詳細を表示する rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ### [](#disk)`disk` アプリケーションのディスク使用量を表示する - デフォルトである最初のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --app-namespace --namespace - 特定のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --details --pod --app-namespace --namespace ### [](#memory)`memory`​ ポッド内の JVM メモリ使用量を表示する - 各レプリカの JVM メモリを取得する rtfctl memory --app-namespace --namespace - 特定のレプリカの JVM メモリを取得する rtfctl memory --pod --app-namespace --namespace ### [](#package)`package`​ アプリケーションのデバッグ情報パッケージを作成する - デフォルトである最初のポッドを使用してアプリケーションのパッケージを作成する rtfctl package --app-namespace --namespace - アプリケーション、ポリシー、​`.mule`​ ディレクトリを含むアプリケーションのパッケージを作成する rtfctl package --apps --policies --dotmule --app-namespace --namespace - ヒープダンプを含むアプリケーションのパッケージを作成する rtfctl package --heap-dump --app-namespace --namespace ### [](#restart)`restart`​ アプリケーションを再起動する rtfctl restart --app-namespace --namespace ### [](#heapdump)`heapdump`​ JVM ヒープダンプをトリガーする - デフォルトである最初のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`` `/tmp/dump.hprof ``​ として保存する rtfctl heapdump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`/tmp/dump.hprof`​ として保存する rtfctl heapdump --pod --app-namespace --namespace ### [](#threaddump)`threaddump`​ JVM スレッドダンプをトリガーする - デフォルトである最初のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --pod --app-namespace --namespace ## [](#runtime-fabric-のトラブルシューティングを行うコマンド)Runtime Fabric のトラブルシューティングを行うコマンド Runtime Fabric のトラブルシューティングを行うには次のコマンドを使用します。
コマンド 説明

get

1 つ以上のリソースを表示する

ping

ネットワーク接続をテストする

report

診断レポートを生成する

status

Runtime Fabric の状況を表示する

test

Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する
### [](#get)`get` 1 つ以上のリソースを表示する - すべての環境のすべてのアプリケーションのリストを出力する rtfctl get apps --namespace - 特定の環境のすべてのアプリケーションのリストを出力する rtfctl get apps --app-namespace --namespace - HTTP プロキシ設定を表示する rtfctl get http-proxy --namespace - 監視プロキシ設定を表示する rtfctl get monitoring-proxy --namespace - セキュアプロパティを表示する rtfctl get secure-properties --app-namespace --namespace - Mule ライセンスを表示する rtfctl get mule-license --namespace - Runtime Fabric レジストリのログイン情報を表示する rtfctl get registry-credentials ### [](#ping)`ping`​ ネットワーク接続をテストする - デフォルトである最初のレプリカを使用してアプリケーション内部から example.com に ping する rtfctl ping --app-namespace --namespace - デフォルトである最初のレプリカを使用してアプリケーション内部からポート ​`12345`​ 上で example.com への接続を試みる rtfctl ping --port --app-namespace --namespace ### [](#report)`report`​ ​`rtf-report.tar.gz`​ に診断レポートを生成する rtfctl report --namespace 並列で実行されるタスクの数を制御する ​`workers`​ フラグを使用して、rtfctl report タスクを並列で実行します。デフォルト値は 10 です。 rtfctl report --workers `rtfctl report`​ と ​`--use-fast-compression`​ フラグによって生成される tarball の圧縮を高速化します。デフォルト値は false です。 rtfctl report --use-fast-compression=true `--namespaces`​ フラグを使用して、インストールの名前空間の他にレポートに含めるアプリケーションの名前空間を選択します。このフラグにより、レポートに含める内容が制御され、選択した名前空間のみがレポートされる場合は収集が高速化される可能性があります。 # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all ### [](#status)`status` Runtime Fabric の状況を表示する - JSON で状況出力を表示する rtfctl status --output json --namespace - Kubernetes DNS の健全性を確認する rtfctl status dns-check --node-label ":" ### [](#test)`test`​ Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する。 - 任意のノードでのチェックをスケジュールする rtfctl test outbound-network --namespace - `node-label`​ パラメーターを満たすノードでのチェックをスケジュールする rtfctl test outbound-network --node-label ":" --namespace - すべてのノードでのチェックをスケジュールする rtfctl test outbound-network --all --namespace ## [](#使用方法)使用方法 ### [](#mule-ライセンスのインストール)Mule ライセンスのインストール 1. 必ずライセンスを Base64 でエンコードしてください。 2. 次のコマンドを実行します。 $ sudo ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### [](#ヒープダンプの取得)ヒープダンプの取得 $ sudo /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof 追加の情報については、​`rtfctl heapdump -h`​ コマンドを実行します。 ### [](#複数のレプリカとの連携)複数のレプリカとの連携 `--pod`​ フラグを受け入れるアプリケーション管理コマンドの場合、​`describe`​ コマンドを使用してレプリカのリストを取得できます。 $ sudo ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status ---- ------ hello-world-77f5897949-z54gb Pending ## [](#auditing)rtfctl 操作の監査 `rtfct`​l コマンドラインツール (v1.0.29 以降) は、クラスター上の ​`rtfctl`​ 操作を監査し、Runtime Fabric コアソフトウェアに影響を与える操作の追跡を支援します。 以下の点に留意してください。 - 監査ログは ​`rtfctl-audit`​ 名前空間の Kubernetes シークレットに保存されます。 - 監査ログはクラスターにスコープ設定され、Runtime Fabric コアソフトウェアのライフサイクルには添付されません。 - 監査プロセスが操作の監査に失敗しても、コマンド実行は操作可能な状態を維持します。 操作を監査するには、次のコマンドを実行します。 $ sudo ./rtfctl audit-logs 出力例: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\]
現在、監査ログのロールオーバーや循環はサポートされていません。
## [](#rtfctl-出力の理解)rtfctl 出力の理解 `rtfctl`​ コマンドラインツールでは通常、他のアプリケーションやシステムツールを呼び出し、これらの呼び出しの出力は標準出力および標準エラー出力に送信されます。この出力は実行される各操作のコンテキストで記述されます。 操作が成功したか失敗したかを明確にするために、​`rtfctl`​ コマンドラインツールには最も詳細なコマンドの最後の出力行が含まれます。通常の操作には、停止しているシステムユニットをもう一度停止しようとした場合など、中間の​_失敗_​メッセージが含まれる場合があります。 メッセージが問題を示しているかどうか疑わしい場合は、システム管理者と話し合うか、MuleSoft サポートにお問い合わせください。 ## [](#以前の-rtfctl-cli-バージョンのダウンロード)以前の rtfctl CLI バージョンのダウンロード 次の REST API コールを使用して、さまざまな rtfctl ツールの CLI バージョンをダウンロードできます。 curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## [](#関連情報)関連情報 - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-proxy-self) - [Runtime Fabric でのセキュアプロパティの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-secure-properties) # Runtime Fabric コマンドラインツールの使用 Runtime Fabric をローカルで管理するには、​`rtfctl`​ コマンドラインツールをインストールして使用します。​`rtfctl`​ ツールでは次のアクションがサポートされています。 - Runtime Fabric の状況を取得する。 - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する。 - 実行中のアプリケーションのメモリ使用量を表示する。 - プロキシ設定を管理する。 - セキュアプロパティを管理する。 - Mule ライセンスを管理する。 - アラート送信者メールアドレスを管理します。 デフォルトの名前空間 (rtf) を使用している場合は、追加のフラグ ​`--namespace `​ を指定する必要はありません。このフラグは rtfctl バージョン 0.4.1 以降のみで導入されています。 ## [](#install-rtfctl)rtfctl のインストール

このセクション内のタスクは、IT 管理者が実行する必要があります。

AKS 用に Runtime Fabric を使用していて、AKS で管理される Azure AD インテグレーションが有効になっている場合、次のコマンドで rtfctl コマンドを実行するために必要なログイン情報が返されます。

az aks get-credentials --name <NAME> --resource-group <RESOURCE_GROUP> --admin
1. `rtfctl`​ コマンドラインツールをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ コマンドラインツールのファイル権限を変更します。 chmod +x rtfctl ### [](#コマンドの実行)コマンドの実行 [「Organizing Cluster Access Using kubeconfig Files (kubeconfig を使用したクラスターアクセスの整理)」](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​で説明されているように ​`rtfctl`​ コマンドラインツールで kubeconfig ファイルがコンシュームされます。この方法を使用して、管理するクラスターを設定します。​`rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 - 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 - サポートされているすべてのコマンドのリストを表示するには、​`rtfctl -h`​ を実行します。 - 特定のコマンドの詳細については、​`rtfctl -h`​ を実行します。 ### [](#プロキシ設定の確認)プロキシ設定の確認 コマンドを実行すると、​`rtfctl`​ は環境にプロキシ設定があるかどうかを確認します。このツールは ​`NO_PROXY`​ キー (大文字) を探して、​`NO_PROXY`​ が使用されていない場合は ​`no_proxy`​ キー (小文字) を受け入れます。両方のキーがある場合、​`rtfctl`​ は ​`NO_PROXY`​ を使用します。​`rtfctl`​ ツールは、プロキシ設定に従うようにローカルの Kubernetes コンテキスト内でキーを設定します。 ## [](#configure-rtfctl)Runtime Fabric を設定するコマンド Runtime Fabric を設定するには次のコマンドを使用します。
コマンド 説明

apply

Runtime Fabric 設定に変更を適用する

update

rtfctl を更新する

wait

Runtime Fabric コンポーネントが準備完了になるのを待機する

renew-expired-client-cert

事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する
### [](#apply)`apply` Runtime Fabric 設定に変更を適用します。
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
- HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --namespace - プロキシをバイパスするホスト名を指定して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - 認証を使用して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://:@: --namespace - HTTP プロキシ設定をクリアする rtfctl apply http-proxy "" --no-proxy "" --namespace - セキュアプロパティを適用する rtfctl apply secure-property --key --value --app-namespace --namespace - ホストノードにシステム設定を適用する rtfctl apply system-configuration - 最新のスクリプトをダウンロードせずにホストノードにシステム設定を適用する rtfctl apply system-configuration --skip-download - Mule ライセンスを適用する rtfctl apply mule-license --namespace Runtime Fabric が Helm を介してインストールされている場合、Helm 値の ​`mule-license`​ プロパティを更新する必要があります。 - 監視プロキシを適用する rtfctl apply monitoring-proxy http://: --namespace - 監視プロキシ設定をクリアする rtfctl apply monitoring-proxy "" --namespace ### [](#update)`update` `rtfctl`​ を更新します。 - US コントロールプレーンから更新する rtfctl update - EU コントロールプレーンから ​`rtfctl`​ を更新する rtfctl update --host eu1.anypoint.mulesoft.com ### [](#wait)`wait` Runtime Fabric コンポーネントが準備完了になるのを待機する - 待機する秒数を指定する rtfctl wait --namespace - 待機をタイムアウトするまでの秒数を指定する (デフォルトは 600 秒) rtfctl wait --timeout --namespace ### [](#renew)`renew` 事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する rtfctl renew-expired-client-cert ## [](#runtime-fabric-のインストールとアップグレードを行うコマンド)Runtime Fabric のインストールとアップグレードを行うコマンド Runtime Fabric のインストールやアップグレード、またはバックアップや復元を実行するときには次のコマンドを使用します。
コマンド 説明

install

Runtime Fabric をインストールする

backup

ローカルの Runtime Fabric の状態をバックアップする

restore

ローカルの Runtime Fabric の状態をバックアップから復元する

validate

Runtime Fabric インストールのクラスターを検証する

version

Runtime Fabric のバージョン情報を表示する
### [](#install)`install` - Runtime Fabric をインストールする rtfctl install - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl install --image-pull-registry --image-pull-secret ### [](#backup)`backup` ローカルの Runtime Fabric の状態をバックアップします。 rtfctl backup .tar.gz --namespace ### [](#restore)`restore` ローカルの Runtime Fabric の状態をバックアップから復元します。 rtfctl restore .tar.gz --namespace ### [](#validate)`validate` Runtime Fabric インストールのクラスターを検証します。 - 検証チェックを実行する rtfctl validate - 検証チェックを実行し、プロキシ設定を含む ​`fabric.tf`​ 設定ファイルを渡す rtfctl validate -f プロキシを使用してインストールを検証するには、​`settings`​ ファイル内でプロキシ設定を指定する必要があります。 MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl validate --image-pull-registry --image-pull-secret ### [](#version)`version` Runtime Fabric のバージョン情報を表示する rtfctl version --namespace ## [](#manage-rtfctl-apps)Runtime Fabric 上のアプリケーションを管理するコマンド Runtime Fabric にデプロイされたアプリケーションを管理するには次のコマンドを使用します。
コマンド 説明

delete

セキュアプロパティを削除する

describe

アプリケーションの詳細を表示する

disk

アプリケーションのディスク使用量を表示する

memory

ポッド内の JVM メモリ使用量を表示する

package

アプリケーションのデバッグ情報パッケージを作成する

restart

アプリケーションを再起動する

heapdump

JVM ヒープダンプを取得する

threaddump

JVM スレッドダンプを取得する
### [](#delete)`delete` セキュアプロパティを削除する rtfctl delete secure-property -n ### [](#describe)`describe` 特定の名前空間でのアプリケーションの詳細を表示する rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ### [](#disk)`disk` アプリケーションのディスク使用量を表示する - デフォルトである最初のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --app-namespace --namespace - 特定のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --details --pod --app-namespace --namespace ### [](#memory)`memory` ポッド内の JVM メモリ使用量を表示する - 各レプリカの JVM メモリを取得する rtfctl memory --app-namespace --namespace - 特定のレプリカの JVM メモリを取得する rtfctl memory --pod --app-namespace --namespace ### [](#package)`package` アプリケーションのデバッグ情報パッケージを作成する - デフォルトである最初のポッドを使用してアプリケーションのパッケージを作成する rtfctl package --app-namespace --namespace - アプリケーション、ポリシー、​`.mule`​ ディレクトリを含むアプリケーションのパッケージを作成する rtfctl package --apps --policies --dotmule --app-namespace --namespace - ヒープダンプを含むアプリケーションのパッケージを作成する rtfctl package --heap-dump --app-namespace --namespace ### [](#restart)`restart` アプリケーションを再起動する rtfctl restart --app-namespace --namespace ### [](#heapdump)`heapdump` JVM ヒープダンプをトリガーします。 - デフォルトである最初のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`` `/tmp/dump.hprof ``​ として保存する rtfctl heapdump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`/tmp/dump.hprof`​ として保存する rtfctl heapdump --pod --app-namespace --namespace ### [](#threaddump)`threaddump` JVM スレッドダンプをトリガーします。 - デフォルトである最初のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --pod --app-namespace --namespace ## [](#troubleshooting-rtfctl)Runtime Fabric のトラブルシューティングを行うコマンド Runtime Fabric のトラブルシューティングを行うには次のコマンドを使用します。
コマンド 説明

get

1 つ以上のリソースを表示する

ping

ネットワーク接続をテストする

report

診断レポートを生成する

status

Runtime Fabric の状況を表示する

test

Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する
### [](#get)`get` 1 つ以上のリソースを表示する - すべての環境のすべてのアプリケーションのリストを出力する rtfctl get apps --namespace - 特定の環境のすべてのアプリケーションのリストを出力する rtfctl get apps --app-namespace --namespace - HTTP プロキシ設定を表示する rtfctl get http-proxy --namespace - 監視プロキシ設定を表示する rtfctl get monitoring-proxy --namespace - セキュアプロパティを表示する rtfctl get secure-properties --app-namespace --namespace - Mule ライセンスを表示する rtfctl get mule-license --namespace - Runtime Fabric レジストリのログイン情報を表示する rtfctl get registry-credentials ### [](#ping)`ping` ネットワーク接続をテストする - デフォルトである最初のレプリカを使用してアプリケーション内部から example.com に ping する rtfctl ping --app-namespace --namespace - デフォルトである最初のレプリカを使用してアプリケーション内部からポート ​`12345`​ 上で example.com への接続を試みる rtfctl ping --port --app-namespace --namespace ### [](#report)`report` `rtf-report.tar.gz`​ に診断レポートを生成する rtfctl report --namespace 並列で実行されるタスクの数を制御する ​`workers`​ フラグを使用して、rtfctl report タスクを並列で実行します。デフォルト値は 10 です。 rtfctl report --workers `rtfctl report`​ と ​`--use-fast-compression`​ フラグによって生成される tarball の圧縮を高速化します。デフォルト値は false です。 rtfctl report --use-fast-compression=true `--namespaces`​ フラグを使用して、インストールの名前空間の他にレポートに含めるアプリケーションの名前空間を選択します。このフラグにより、レポートに含める内容が制御され、選択した名前空間のみがレポートされる場合は収集が高速化される可能性があります。 # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all カスタムリリース名を使用したインストールをサポートするには、Helm リリースの名前を指定します。 rtfctl report --release-name ### [](#status)`status` Runtime Fabric の状況を表示する - JSON で状況出力を表示する rtfctl status --output json --namespace - Kubernetes DNS の健全性を確認する rtfctl status dns-check --node-label ":" ### [](#test)`test` Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証します。 - 任意のノードでのチェックをスケジュールする rtfctl test outbound-network --namespace - `node-label`​ パラメーターを満たすノードでのチェックをスケジュールする rtfctl test outbound-network --node-label ":" --namespace - すべてのノードでのチェックをスケジュールする rtfctl test outbound-network --all --namespace ## [](#使用方法)使用方法 ### [](#mule-ライセンスのインストール)Mule ライセンスのインストール 1. 必ずライセンスを Base64 でエンコードしてください。 2. 次のコマンドを実行します。 $ sudo ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### [](#ヒープダンプの取得)ヒープダンプの取得 $ sudo /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof 追加の情報については、​`rtfctl heapdump -h`​ コマンドを実行します。 ### [](#複数のレプリカとの連携)複数のレプリカとの連携 `--pod`​ フラグを受け入れるアプリケーション管理コマンドの場合、​`describe`​ コマンドを使用してレプリカのリストを取得できます。 $ sudo ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status ---- ------ hello-world-77f5897949-z54gb Pending ## [](#auditing)rtfctl 操作の監査 `rtfct`​l コマンドラインツール (v1.0.29 以降) は、クラスター上の ​`rtfctl`​ 操作を監査し、Runtime Fabric コアソフトウェアに影響を与える操作の追跡を支援します。 以下の点に留意してください。 - 監査ログは ​`rtfctl-audit`​ 名前空間の Kubernetes シークレットに保存されます。 - 監査ログはクラスターにスコープ設定され、Runtime Fabric コアソフトウェアのライフサイクルには添付されません。 - 監査プロセスが操作の監査に失敗しても、コマンド実行は操作可能な状態を維持します。 操作を監査するには、次のコマンドを実行します。 $ sudo ./rtfctl audit-logs 出力例: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\]
現在、監査ログのロールオーバーや循環はサポートされていません。
## [](#rtfctl-出力の理解)rtfctl 出力の理解 `rtfctl`​ コマンドラインツールでは通常、他のアプリケーションやシステムツールを呼び出し、これらの呼び出しの出力は標準出力および標準エラー出力に送信されます。この出力は実行される各操作のコンテキストで記述されます。 操作が成功したか失敗したかを明確にするために、​`rtfctl`​ コマンドラインツールには最も詳細なコマンドの最後の出力行が含まれます。通常の操作には、停止しているシステムユニットをもう一度停止しようとした場合など、中間の​_失敗_​メッセージが含まれる場合があります。 メッセージが問題を示しているかどうか疑わしい場合は、システム管理者と話し合うか、MuleSoft サポートにお問い合わせください。 ## [](#以前の-rtfctl-cli-バージョンのダウンロード)以前の rtfctl CLI バージョンのダウンロード 次の REST API コールを使用して、さまざまな rtfctl ツールの CLI バージョンをダウンロードできます。 curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## [](#関連情報)関連情報 - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-proxy-self) - [Runtime Fabric でのセキュアプロパティの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-secure-properties) # Runtime Fabric コマンドラインツールの使用 Runtime Fabric をローカルで管理するには、​`rtfctl`​ コマンドラインツールをインストールして使用します。​`rtfctl`​ ツールでは次のアクションがサポートされています。 - Runtime Fabric の状況を取得する。 - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する。 - 実行中のアプリケーションのメモリ使用量を表示する。 - プロキシ設定を管理する。 - セキュアプロパティを管理する。 - Mule ライセンスを管理する。 - アラート送信者メールアドレスを管理します。 デフォルトの名前空間 (rtf) を使用している場合は、追加のフラグ ​`--namespace `​ を指定する必要はありません。このフラグは rtfctl バージョン 0.4.1 以降のみで導入されています。 ## [](#install-rtfctl)rtfctl のインストール

このセクション内のタスクは、IT 管理者が実行する必要があります。

AKS 用に Runtime Fabric を使用していて、AKS で管理される Azure AD インテグレーションが有効になっている場合、次のコマンドで rtfctl コマンドを実行するために必要なログイン情報が返されます。

az aks get-credentials --name <NAME> --resource-group <RESOURCE_GROUP> --admin
1. `rtfctl`​ コマンドラインツールをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ コマンドラインツールのファイル権限を変更します。 chmod +x rtfctl ### [](#コマンドの実行)コマンドの実行 [「Organizing Cluster Access Using kubeconfig Files (kubeconfig を使用したクラスターアクセスの整理)」](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​で説明されているように ​`rtfctl`​ コマンドラインツールで kubeconfig ファイルがコンシュームされます。この方法を使用して、管理するクラスターを設定します。​`rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 - 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 - サポートされているすべてのコマンドのリストを表示するには、​`rtfctl -h`​ を実行します。 - 特定のコマンドの詳細については、​`rtfctl -h`​ を実行します。 ### [](#プロキシ設定の確認)プロキシ設定の確認 コマンドを実行すると、​`rtfctl`​ は環境にプロキシ設定があるかどうかを確認します。このツールは ​`NO_PROXY`​ キー (大文字) を探して、​`NO_PROXY`​ が使用されていない場合は ​`no_proxy`​ キー (小文字) を受け入れます。両方のキーがある場合、​`rtfctl`​ は ​`NO_PROXY`​ を使用します。​`rtfctl`​ ツールは、プロキシ設定に従うようにローカルの Kubernetes コンテキスト内でキーを設定します。 ## [](#configure-rtfctl)Runtime Fabric を設定するコマンド Runtime Fabric を設定するには次のコマンドを使用します。
コマンド 説明

apply

Runtime Fabric 設定に変更を適用する

update

rtfctl を更新する

wait

Runtime Fabric コンポーネントが準備完了になるのを待機する

renew-expired-client-cert

事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する
### [](#apply)`apply` Runtime Fabric 設定に変更を適用します。
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
- HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --namespace - プロキシをバイパスするホスト名を指定して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - 認証を使用して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://:@: --namespace - HTTP プロキシ設定をクリアする rtfctl apply http-proxy "" --no-proxy "" --namespace - セキュアプロパティを適用する rtfctl apply secure-property --key --value --app-namespace --namespace - ホストノードにシステム設定を適用する rtfctl apply system-configuration - 最新のスクリプトをダウンロードせずにホストノードにシステム設定を適用する rtfctl apply system-configuration --skip-download - Mule ライセンスを適用する rtfctl apply mule-license --namespace Runtime Fabric が Helm を介してインストールされている場合、Helm 値の ​`mule-license`​ プロパティを更新する必要があります。 - 監視プロキシを適用する rtfctl apply monitoring-proxy http://: --namespace - 監視プロキシ設定をクリアする rtfctl apply monitoring-proxy "" --namespace ### [](#update)`update` `rtfctl`​ を更新します。 - US コントロールプレーンから更新する rtfctl update - EU コントロールプレーンから ​`rtfctl`​ を更新する rtfctl update --host eu1.anypoint.mulesoft.com ### [](#wait)`wait` Runtime Fabric コンポーネントが準備完了になるのを待機する - 待機する秒数を指定する rtfctl wait --namespace - 待機をタイムアウトするまでの秒数を指定する (デフォルトは 600 秒) rtfctl wait --timeout --namespace ### [](#renew)`renew` 事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する rtfctl renew-expired-client-cert ## [](#runtime-fabric-のインストールとアップグレードを行うコマンド)Runtime Fabric のインストールとアップグレードを行うコマンド Runtime Fabric のインストールやアップグレード、またはバックアップや復元を実行するときには次のコマンドを使用します。
コマンド 説明

install

Runtime Fabric をインストールする

backup

ローカルの Runtime Fabric の状態をバックアップする

restore

ローカルの Runtime Fabric の状態をバックアップから復元する

validate

Runtime Fabric インストールのクラスターを検証する

version

Runtime Fabric のバージョン情報を表示する
### [](#install)`install` - Runtime Fabric をインストールする rtfctl install - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl install --image-pull-registry --image-pull-secret ### [](#backup)`backup` ローカルの Runtime Fabric の状態をバックアップします。 rtfctl backup .tar.gz --namespace ### [](#restore)`restore` ローカルの Runtime Fabric の状態をバックアップから復元します。 rtfctl restore .tar.gz --namespace ### [](#validate)`validate` Runtime Fabric インストールのクラスターを検証します。 - 検証チェックを実行する rtfctl validate - 検証チェックを実行し、プロキシ設定を含む ​`fabric.tf`​ 設定ファイルを渡す rtfctl validate -f プロキシを使用してインストールを検証するには、​`settings`​ ファイル内でプロキシ設定を指定する必要があります。 MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl validate --image-pull-registry --image-pull-secret ### [](#version)`version` Runtime Fabric のバージョン情報を表示する rtfctl version --namespace ## [](#manage-rtfctl-apps)Runtime Fabric 上のアプリケーションを管理するコマンド Runtime Fabric にデプロイされたアプリケーションを管理するには次のコマンドを使用します。
コマンド 説明

delete

セキュアプロパティを削除する

describe

アプリケーションの詳細を表示する

disk

アプリケーションのディスク使用量を表示する

memory

ポッド内の JVM メモリ使用量を表示する

package

アプリケーションのデバッグ情報パッケージを作成する

restart

アプリケーションを再起動する

heapdump

JVM ヒープダンプを取得する

threaddump

JVM スレッドダンプを取得する
### [](#delete)`delete` セキュアプロパティを削除する rtfctl delete secure-property -n ### [](#describe)`describe` 特定の名前空間でのアプリケーションの詳細を表示する rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ### [](#disk)`disk` アプリケーションのディスク使用量を表示する - デフォルトである最初のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --app-namespace --namespace - 特定のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --details --pod --app-namespace --namespace ### [](#memory)`memory` ポッド内の JVM メモリ使用量を表示する - 各レプリカの JVM メモリを取得する rtfctl memory --app-namespace --namespace - 特定のレプリカの JVM メモリを取得する rtfctl memory --pod --app-namespace --namespace ### [](#package)`package` アプリケーションのデバッグ情報パッケージを作成する - デフォルトである最初のポッドを使用してアプリケーションのパッケージを作成する rtfctl package --app-namespace --namespace - アプリケーション、ポリシー、​`.mule`​ ディレクトリを含むアプリケーションのパッケージを作成する rtfctl package --apps --policies --dotmule --app-namespace --namespace - ヒープダンプを含むアプリケーションのパッケージを作成する rtfctl package --heap-dump --app-namespace --namespace ### [](#restart)`restart` アプリケーションを再起動する rtfctl restart --app-namespace --namespace ### [](#heapdump)`heapdump` JVM ヒープダンプをトリガーします。 - デフォルトである最初のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`` `/tmp/dump.hprof ``​ として保存する rtfctl heapdump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`/tmp/dump.hprof`​ として保存する rtfctl heapdump --pod --app-namespace --namespace ### [](#threaddump)`threaddump` JVM スレッドダンプをトリガーします。 - デフォルトである最初のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --pod --app-namespace --namespace ## [](#troubleshooting-rtfctl)Runtime Fabric のトラブルシューティングを行うコマンド Runtime Fabric のトラブルシューティングを行うには次のコマンドを使用します。
コマンド 説明

get

1 つ以上のリソースを表示する

ping

ネットワーク接続をテストする

report

診断レポートを生成する

status

Runtime Fabric の状況を表示する

test

Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する
### [](#get)`get` 1 つ以上のリソースを表示する - すべての環境のすべてのアプリケーションのリストを出力する rtfctl get apps --namespace - 特定の環境のすべてのアプリケーションのリストを出力する rtfctl get apps --app-namespace --namespace - HTTP プロキシ設定を表示する rtfctl get http-proxy --namespace - 監視プロキシ設定を表示する rtfctl get monitoring-proxy --namespace - セキュアプロパティを表示する rtfctl get secure-properties --app-namespace --namespace - Mule ライセンスを表示する rtfctl get mule-license --namespace - Runtime Fabric レジストリのログイン情報を表示する rtfctl get registry-credentials ### [](#ping)`ping` ネットワーク接続をテストする - デフォルトである最初のレプリカを使用してアプリケーション内部から example.com に ping する rtfctl ping --app-namespace --namespace - デフォルトである最初のレプリカを使用してアプリケーション内部からポート ​`12345`​ 上で example.com への接続を試みる rtfctl ping --port --app-namespace --namespace ### [](#report)`report` `rtf-report.tar.gz`​ に診断レポートを生成する rtfctl report --namespace 並列で実行されるタスクの数を制御する ​`workers`​ フラグを使用して、rtfctl report タスクを並列で実行します。デフォルト値は 10 です。 rtfctl report --workers `rtfctl report`​ と ​`--use-fast-compression`​ フラグによって生成される tarball の圧縮を高速化します。デフォルト値は false です。 rtfctl report --use-fast-compression=true `--namespaces`​ フラグを使用して、インストールの名前空間の他にレポートに含めるアプリケーションの名前空間を選択します。このフラグにより、レポートに含める内容が制御され、選択した名前空間のみがレポートされる場合は収集が高速化される可能性があります。 # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all カスタムリリース名を使用したインストールをサポートするには、Helm リリースの名前を指定します。 rtfctl report --release-name ### [](#status)`status` Runtime Fabric の状況を表示する - JSON で状況出力を表示する rtfctl status --output json --namespace - Kubernetes DNS の健全性を確認する rtfctl status dns-check --node-label ":" ### [](#test)`test` Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証します。 - 任意のノードでのチェックをスケジュールする rtfctl test outbound-network --namespace - `node-label`​ パラメーターを満たすノードでのチェックをスケジュールする rtfctl test outbound-network --node-label ":" --namespace - すべてのノードでのチェックをスケジュールする rtfctl test outbound-network --all --namespace ## [](#使用方法)使用方法 ### [](#mule-ライセンスのインストール)Mule ライセンスのインストール 1. 必ずライセンスを Base64 でエンコードしてください。 2. 次のコマンドを実行します。 $ sudo ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### [](#ヒープダンプの取得)ヒープダンプの取得 $ sudo /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof 追加の情報については、​`rtfctl heapdump -h`​ コマンドを実行します。 ### [](#複数のレプリカとの連携)複数のレプリカとの連携 `--pod`​ フラグを受け入れるアプリケーション管理コマンドの場合、​`describe`​ コマンドを使用してレプリカのリストを取得できます。 $ sudo ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status ---- ------ hello-world-77f5897949-z54gb Pending ## [](#auditing)rtfctl 操作の監査 `rtfct`​l コマンドラインツール (v1.0.29 以降) は、クラスター上の ​`rtfctl`​ 操作を監査し、Runtime Fabric コアソフトウェアに影響を与える操作の追跡を支援します。 以下の点に留意してください。 - 監査ログは ​`rtfctl-audit`​ 名前空間の Kubernetes シークレットに保存されます。 - 監査ログはクラスターにスコープ設定され、Runtime Fabric コアソフトウェアのライフサイクルには添付されません。 - 監査プロセスが操作の監査に失敗しても、コマンド実行は操作可能な状態を維持します。 操作を監査するには、次のコマンドを実行します。 $ sudo ./rtfctl audit-logs 出力例: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\]
現在、監査ログのロールオーバーや循環はサポートされていません。
## [](#rtfctl-出力の理解)rtfctl 出力の理解 `rtfctl`​ コマンドラインツールでは通常、他のアプリケーションやシステムツールを呼び出し、これらの呼び出しの出力は標準出力および標準エラー出力に送信されます。この出力は実行される各操作のコンテキストで記述されます。 操作が成功したか失敗したかを明確にするために、​`rtfctl`​ コマンドラインツールには最も詳細なコマンドの最後の出力行が含まれます。通常の操作には、停止しているシステムユニットをもう一度停止しようとした場合など、中間の​_失敗_​メッセージが含まれる場合があります。 メッセージが問題を示しているかどうか疑わしい場合は、システム管理者と話し合うか、MuleSoft サポートにお問い合わせください。 ## [](#以前の-rtfctl-cli-バージョンのダウンロード)以前の rtfctl CLI バージョンのダウンロード 次の REST API コールを使用して、さまざまな rtfctl ツールの CLI バージョンをダウンロードできます。 curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## [](#関連情報)関連情報 - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-proxy-self) - [Runtime Fabric でのセキュアプロパティの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-secure-properties) # Runtime Fabric コマンドラインツールの使用 Runtime Fabric をローカルで管理するには、​`rtfctl`​ コマンドラインツールをインストールして使用します。​`rtfctl`​ ツールでは次のアクションがサポートされています。 - Runtime Fabric の状況を取得する。 - 実行中のアプリケーションのヒープダンプまたはスレッドダンプを実行する。 - 実行中のアプリケーションのメモリ使用量を表示する。 - プロキシ設定を管理する。 - セキュアプロパティを管理する。 - Mule ライセンスを管理する。 - アラート送信者メールアドレスを管理します。 デフォルトの名前空間 (rtf) を使用している場合は、追加のフラグ ​`--namespace `​ を指定する必要はありません。このフラグは rtfctl バージョン 0.4.1 以降のみで導入されています。 ## [](#install-rtfctl)rtfctl のインストール

このセクション内のタスクは、IT 管理者が実行する必要があります。

AKS 用に Runtime Fabric を使用していて、AKS で管理される Azure AD インテグレーションが有効になっている場合、次のコマンドで rtfctl コマンドを実行するために必要なログイン情報が返されます。

az aks get-credentials --name <NAME> --resource-group <RESOURCE_GROUP> --admin
1. `rtfctl`​ コマンドラインツールをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ コマンドラインツールのファイル権限を変更します。 chmod +x rtfctl ### [](#コマンドの実行)コマンドの実行 [「Organizing Cluster Access Using kubeconfig Files (kubeconfig を使用したクラスターアクセスの整理)」](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)​で説明されているように ​`rtfctl`​ コマンドラインツールで kubeconfig ファイルがコンシュームされます。この方法を使用して、管理するクラスターを設定します。​`rtfctl`​ バイナリが現在の作業ディレクトリとユーザーの ​`$PATH`​ に存在することを確認します。 - 特権ユーザーとして ​`rtfctl`​ コマンドを実行します。 - サポートされているすべてのコマンドのリストを表示するには、​`rtfctl -h`​ を実行します。 - 特定のコマンドの詳細については、​`rtfctl -h`​ を実行します。 ### [](#プロキシ設定の確認)プロキシ設定の確認 コマンドを実行すると、​`rtfctl`​ は環境にプロキシ設定があるかどうかを確認します。このツールは ​`NO_PROXY`​ キー (大文字) を探して、​`NO_PROXY`​ が使用されていない場合は ​`no_proxy`​ キー (小文字) を受け入れます。両方のキーがある場合、​`rtfctl`​ は ​`NO_PROXY`​ を使用します。​`rtfctl`​ ツールは、プロキシ設定に従うようにローカルの Kubernetes コンテキスト内でキーを設定します。 ## [](#configure-rtfctl)Runtime Fabric を設定するコマンド Runtime Fabric を設定するには次のコマンドを使用します。
コマンド 説明

apply

Runtime Fabric 設定に変更を適用する

update

rtfctl を更新する

wait

Runtime Fabric コンポーネントが準備完了になるのを待機する

renew-expired-client-cert

事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する
### [](#apply)`apply` Runtime Fabric 設定に変更を適用します。
rtfcl apply​ と一緒に値を使用しても、OpenShift では機能しません。OpenShift コンソールで値を更新する必要があります。
- HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --namespace - プロキシをバイパスするホスト名を指定して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://: --no-proxy "DOMAIN1.com,DOMAIN2.com" --namespace - 認証を使用して HTTP プロキシ設定を適用する rtfctl apply http-proxy http://:@: --namespace - HTTP プロキシ設定をクリアする rtfctl apply http-proxy "" --no-proxy "" --namespace - セキュアプロパティを適用する rtfctl apply secure-property --key --value --app-namespace --namespace - ホストノードにシステム設定を適用する rtfctl apply system-configuration - 最新のスクリプトをダウンロードせずにホストノードにシステム設定を適用する rtfctl apply system-configuration --skip-download - Mule ライセンスを適用する rtfctl apply mule-license --namespace Runtime Fabric が Helm を介してインストールされている場合、Helm 値の ​`mule-license`​ プロパティを更新する必要があります。 - 監視プロキシを適用する rtfctl apply monitoring-proxy http://: --namespace - 監視プロキシ設定をクリアする rtfctl apply monitoring-proxy "" --namespace ### [](#update)`update` `rtfctl`​ を更新します。 - US コントロールプレーンから更新する rtfctl update - EU コントロールプレーンから ​`rtfctl`​ を更新する rtfctl update --host eu1.anypoint.mulesoft.com ### [](#wait)`wait` Runtime Fabric コンポーネントが準備完了になるのを待機する - 待機する秒数を指定する rtfctl wait --namespace - 待機をタイムアウトするまでの秒数を指定する (デフォルトは 600 秒) rtfctl wait --timeout --namespace ### [](#renew)`renew` 事前ダウンロード済みパッケージを使用して期限切れのクライアント証明書を更新する rtfctl renew-expired-client-cert ## [](#runtime-fabric-のインストールとアップグレードを行うコマンド)Runtime Fabric のインストールとアップグレードを行うコマンド Runtime Fabric のインストールやアップグレード、またはバックアップや復元を実行するときには次のコマンドを使用します。
コマンド 説明

install

Runtime Fabric をインストールする

backup

ローカルの Runtime Fabric の状態をバックアップする

restore

ローカルの Runtime Fabric の状態をバックアップから復元する

validate

Runtime Fabric インストールのクラスターを検証する

version

Runtime Fabric のバージョン情報を表示する
### [](#install)`install` - Runtime Fabric をインストールする rtfctl install - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl install --image-pull-registry --image-pull-secret ### [](#backup)`backup` ローカルの Runtime Fabric の状態をバックアップします。 rtfctl backup .tar.gz --namespace ### [](#restore)`restore` ローカルの Runtime Fabric の状態をバックアップから復元します。 rtfctl restore .tar.gz --namespace ### [](#validate)`validate` Runtime Fabric インストールのクラスターを検証します。 - 検証チェックを実行する rtfctl validate - 検証チェックを実行し、プロキシ設定を含む ​`fabric.tf`​ 設定ファイルを渡す rtfctl validate -f プロキシを使用してインストールを検証するには、​`settings`​ ファイル内でプロキシ設定を指定する必要があります。 MULE\_LICENSE= ACTIVATION\_DATA= HTTP\_PROXY=http://.com: - Docker イメージレジストリ URL およびシークレットを上書きする rtfctl validate --image-pull-registry --image-pull-secret ### [](#version)`version` Runtime Fabric のバージョン情報を表示する rtfctl version --namespace ## [](#manage-rtfctl-apps)Runtime Fabric 上のアプリケーションを管理するコマンド Runtime Fabric にデプロイされたアプリケーションを管理するには次のコマンドを使用します。
コマンド 説明

delete

セキュアプロパティを削除する

describe

アプリケーションの詳細を表示する

disk

アプリケーションのディスク使用量を表示する

memory

ポッド内の JVM メモリ使用量を表示する

package

アプリケーションのデバッグ情報パッケージを作成する

restart

アプリケーションを再起動する

heapdump

JVM ヒープダンプを取得する

threaddump

JVM スレッドダンプを取得する
### [](#delete)`delete` セキュアプロパティを削除する rtfctl delete secure-property -n ### [](#describe)`describe` 特定の名前空間でのアプリケーションの詳細を表示する rtfctl describe apps --namespace rtfctl describe apps --app-namespace --namespace ### [](#disk)`disk` アプリケーションのディスク使用量を表示する - デフォルトである最初のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --app-namespace --namespace - 特定のレプリカを使用してアプリケーションのディスク使用量を表示する rtfctl disk --details --pod --app-namespace --namespace ### [](#memory)`memory` ポッド内の JVM メモリ使用量を表示する - 各レプリカの JVM メモリを取得する rtfctl memory --app-namespace --namespace - 特定のレプリカの JVM メモリを取得する rtfctl memory --pod --app-namespace --namespace ### [](#package)`package` アプリケーションのデバッグ情報パッケージを作成する - デフォルトである最初のポッドを使用してアプリケーションのパッケージを作成する rtfctl package --app-namespace --namespace - アプリケーション、ポリシー、​`.mule`​ ディレクトリを含むアプリケーションのパッケージを作成する rtfctl package --apps --policies --dotmule --app-namespace --namespace - ヒープダンプを含むアプリケーションのパッケージを作成する rtfctl package --heap-dump --app-namespace --namespace ### [](#restart)`restart` アプリケーションを再起動する rtfctl restart --app-namespace --namespace ### [](#heapdump)`heapdump` JVM ヒープダンプをトリガーします。 - デフォルトである最初のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`` `/tmp/dump.hprof ``​ として保存する rtfctl heapdump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM ヒープダンプを実行し、​`/tmp/dump.hprof`​ として保存する rtfctl heapdump --pod --app-namespace --namespace ### [](#threaddump)`threaddump` JVM スレッドダンプをトリガーします。 - デフォルトである最初のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --app-namespace --namespace - 特定のレプリカを使用してアプリケーションの JVM スレッドダンプを実行する rtfctl threaddump --pod --app-namespace --namespace ## [](#troubleshooting-rtfctl)Runtime Fabric のトラブルシューティングを行うコマンド Runtime Fabric のトラブルシューティングを行うには次のコマンドを使用します。
コマンド 説明

get

1 つ以上のリソースを表示する

ping

ネットワーク接続をテストする

report

診断レポートを生成する

status

Runtime Fabric の状況を表示する

test

Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証する
### [](#get)`get` 1 つ以上のリソースを表示する - すべての環境のすべてのアプリケーションのリストを出力する rtfctl get apps --namespace - 特定の環境のすべてのアプリケーションのリストを出力する rtfctl get apps --app-namespace --namespace - HTTP プロキシ設定を表示する rtfctl get http-proxy --namespace - 監視プロキシ設定を表示する rtfctl get monitoring-proxy --namespace - セキュアプロパティを表示する rtfctl get secure-properties --app-namespace --namespace - Mule ライセンスを表示する rtfctl get mule-license --namespace - Runtime Fabric レジストリのログイン情報を表示する rtfctl get registry-credentials ### [](#ping)`ping` ネットワーク接続をテストする - デフォルトである最初のレプリカを使用してアプリケーション内部から example.com に ping する rtfctl ping --app-namespace --namespace - デフォルトである最初のレプリカを使用してアプリケーション内部からポート ​`12345`​ 上で example.com への接続を試みる rtfctl ping --port --app-namespace --namespace ### [](#report)`report` `rtf-report.tar.gz`​ に診断レポートを生成する rtfctl report --namespace 並列で実行されるタスクの数を制御する ​`workers`​ フラグを使用して、rtfctl report タスクを並列で実行します。デフォルト値は 10 です。 rtfctl report --workers `rtfctl report`​ と ​`--use-fast-compression`​ フラグによって生成される tarball の圧縮を高速化します。デフォルト値は false です。 rtfctl report --use-fast-compression=true `--namespaces`​ フラグを使用して、インストールの名前空間の他にレポートに含めるアプリケーションの名前空間を選択します。このフラグにより、レポートに含める内容が制御され、選択した名前空間のみがレポートされる場合は収集が高速化される可能性があります。 # Reports rtf installation default namespace (rtf) rtfctl report # Reports only rtfctl report -n # Reports for and application namespaces that belong to rtfctl report -n --app-namespaces , rtfctl report -n --app-namespaces --app-namespaces # Report for all application namespaces that belong to rtfctl report -n --app-namespaces all カスタムリリース名を使用したインストールをサポートするには、Helm リリースの名前を指定します。 rtfctl report --release-name ### [](#status)`status` Runtime Fabric の状況を表示する - JSON で状況出力を表示する rtfctl status --output json --namespace - Kubernetes DNS の健全性を確認する rtfctl status dns-check --node-label ":" ### [](#test)`test` Runtime Fabric コントロールプレーンへのアウトバウンドネットワーク接続を検証します。 - 任意のノードでのチェックをスケジュールする rtfctl test outbound-network --namespace - `node-label`​ パラメーターを満たすノードでのチェックをスケジュールする rtfctl test outbound-network --node-label ":" --namespace - すべてのノードでのチェックをスケジュールする rtfctl test outbound-network --all --namespace ## [](#使用方法)使用方法 ### [](#mule-ライセンスのインストール)Mule ライセンスのインストール 1. 必ずライセンスを Base64 でエンコードしてください。 2. 次のコマンドを実行します。 $ sudo ./rtfctl apply mule-license '' --namespace rtf1 Updating rtf namespace... OK ### [](#ヒープダンプの取得)ヒープダンプの取得 $ sudo /usr/local/bin/rtfctl heapdump hello-world /tmp/dump.hprof --app-namespace bed42b62-XXXX --namespace rtf1 Dumping heap for hello-world-f76484d8-l44qv... Heap dump written to /tmp/dump.hprof 追加の情報については、​`rtfctl heapdump -h`​ コマンドを実行します。 ### [](#複数のレプリカとの連携)複数のレプリカとの連携 `--pod`​ フラグを受け入れるアプリケーション管理コマンドの場合、​`describe`​ コマンドを使用してレプリカのリストを取得できます。 $ sudo ./rtfctl describe apps hello-world --app-namespace bed42b62-XXXX --namespace rtf1 Name: hello-world Namespace: bed42b62-XXXX Status: PROGRESSING Runtime: 2 ID: Version: Organization ID: d30f74c0-XXXX Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable Name Status ---- ------ hello-world-77f5897949-z54gb Pending ## [](#auditing)rtfctl 操作の監査 `rtfct`​l コマンドラインツール (v1.0.29 以降) は、クラスター上の ​`rtfctl`​ 操作を監査し、Runtime Fabric コアソフトウェアに影響を与える操作の追跡を支援します。 以下の点に留意してください。 - 監査ログは ​`rtfctl-audit`​ 名前空間の Kubernetes シークレットに保存されます。 - 監査ログはクラスターにスコープ設定され、Runtime Fabric コアソフトウェアのライフサイクルには添付されません。 - 監査プロセスが操作の監査に失敗しても、コマンド実行は操作可能な状態を維持します。 操作を監査するには、次のコマンドを実行します。 $ sudo ./rtfctl audit-logs 出力例: \[{"timestamp":"2023-10-26 00:52:24.446 +0000 UTC","kubeContext":"test-k8scontext","command":\["./rtfctl","restart","test-application","--app-namespace","8456f9c7-2149-4983-b02b-6b18ddd28efe","--namespace","rtf"\]}\]
現在、監査ログのロールオーバーや循環はサポートされていません。
## [](#rtfctl-出力の理解)rtfctl 出力の理解 `rtfctl`​ コマンドラインツールでは通常、他のアプリケーションやシステムツールを呼び出し、これらの呼び出しの出力は標準出力および標準エラー出力に送信されます。この出力は実行される各操作のコンテキストで記述されます。 操作が成功したか失敗したかを明確にするために、​`rtfctl`​ コマンドラインツールには最も詳細なコマンドの最後の出力行が含まれます。通常の操作には、停止しているシステムユニットをもう一度停止しようとした場合など、中間の​_失敗_​メッセージが含まれる場合があります。 メッセージが問題を示しているかどうか疑わしい場合は、システム管理者と話し合うか、MuleSoft サポートにお問い合わせください。 ## [](#以前の-rtfctl-cli-バージョンのダウンロード)以前の rtfctl CLI バージョンのダウンロード 次の REST API コールを使用して、さまざまな rtfctl ツールの CLI バージョンをダウンロードできます。 curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/{version} -o rtfctl ## [](#関連情報)関連情報 - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-proxy-self) - [Runtime Fabric でのセキュアプロパティの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-secure-properties) # Runtime Fabric での Mule Runtime の強化 仕様として、Runtime Fabric では Mule アプリケーションの強化対策が自動的に適用されて有効になります。コンテナリゼーションのベストプラクティスに従って、Mule およびアプリケーションレベルの分離がデフォルトで実行されます。 次の強化チェックリストには、Runtime Fabric を使用した Mule の強化に関する追加情報とベストプラクティスが記載されています。 ## [](#強化チェックリスト)強化チェックリスト
Table 1. Mule の強化手順
強化ステップ 必要なアクション

Mule を非特権ユーザーとして実行します。

この機能は、Runtime Fabric が提供します。

Mule をサービスとしてインストールします

Runtime Fabric は、独自のコンテナ内でアプリケーションごとに Mule Runtime Engine をデプロイすることでこの機能を提供します。

ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。

この機能は、Runtime Fabric が提供します。 Mule は、アプリケーションの終了時に削除される一時ファイルシステムに書き込みます。監視情報は、メトリクスが出力されて保存されるディスクの特定の場所のサイドカーエージェントから収集します。ログは、標準出力ストリームから収集されます。

一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。

証明書をキーストアファイルで管理します。

これは Runtime Fabric でサポートされていますが、証明書をキーストアにインポートする必要があります。また、Runtime Fabric にはロードバランサーがあり、ロードバランサー内にデプロイされているすべての Mule Runtime Engine の SSL 終了を処理できます。

個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。
# Runtime Fabric での Mule Runtime の強化 仕様として、Runtime Fabric では Mule アプリケーションの強化対策が自動的に適用されて有効になります。コンテナリゼーションのベストプラクティスに従って、Mule およびアプリケーションレベルの分離がデフォルトで実行されます。 次の強化チェックリストには、Runtime Fabric を使用した Mule の強化に関する追加情報とベストプラクティスが記載されています。 ## [](#強化チェックリスト)強化チェックリスト
Table 1. Mule の強化手順
強化ステップ 必要なアクション

Mule を非特権ユーザーとして実行します。

この機能は、Runtime Fabric が提供します。

Mule をサービスとしてインストールします

Runtime Fabric は、独自のコンテナ内でアプリケーションごとに Mule Runtime Engine をデプロイすることでこの機能を提供します。

ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。

この機能は、Runtime Fabric が提供します。 Mule は、アプリケーションの終了時に削除される一時ファイルシステムに書き込みます。監視情報は、メトリクスが出力されて保存されるディスクの特定の場所のサイドカーエージェントから収集します。ログは、標準出力ストリームから収集されます。

一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。

証明書をキーストアファイルで管理します。

これは Runtime Fabric でサポートされていますが、証明書をキーストアにインポートする必要があります。

個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。
# Runtime Fabric での Mule Runtime の強化 仕様として、Runtime Fabric では Mule アプリケーションの強化対策が自動的に適用されて有効になります。コンテナリゼーションのベストプラクティスに従って、Mule およびアプリケーションレベルの分離がデフォルトで実行されます。 次の強化チェックリストには、Runtime Fabric を使用した Mule の強化に関する追加情報とベストプラクティスが記載されています。 ## [](#強化チェックリスト)強化チェックリスト
Table 1. Mule の強化手順
強化ステップ 必要なアクション

Mule を非特権ユーザーとして実行します。

この機能は、Runtime Fabric が提供します。

Mule をサービスとしてインストールします

Runtime Fabric は、独自のコンテナ内でアプリケーションごとに Mule Runtime Engine をデプロイすることでこの機能を提供します。

ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。

この機能は、Runtime Fabric が提供します。 Mule は、アプリケーションの終了時に削除される一時ファイルシステムに書き込みます。監視情報は、メトリクスが出力されて保存されるディスクの特定の場所のサイドカーエージェントから収集します。ログは、標準出力ストリームから収集されます。

一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。

証明書をキーストアファイルで管理します。

これは Runtime Fabric でサポートされていますが、証明書をキーストアにインポートする必要があります。

個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。
# Runtime Fabric での Mule Runtime の強化 仕様として、Runtime Fabric では Mule アプリケーションの強化対策が自動的に適用されて有効になります。コンテナリゼーションのベストプラクティスに従って、Mule およびアプリケーションレベルの分離がデフォルトで実行されます。 次の強化チェックリストには、Runtime Fabric を使用した Mule の強化に関する追加情報とベストプラクティスが記載されています。 ## [](#強化チェックリスト)強化チェックリスト
Table 1. Mule の強化手順
強化ステップ 必要なアクション

Mule を非特権ユーザーとして実行します。

この機能は、Runtime Fabric が提供します。

Mule をサービスとしてインストールします

Runtime Fabric は、独自のコンテナ内でアプリケーションごとに Mule Runtime Engine をデプロイすることでこの機能を提供します。

ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。

この機能は、Runtime Fabric が提供します。 Mule は、アプリケーションの終了時に削除される一時ファイルシステムに書き込みます。監視情報は、メトリクスが出力されて保存されるディスクの特定の場所のサイドカーエージェントから収集します。ログは、標準出力ストリームから収集されます。

一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。

証明書をキーストアファイルで管理します。

これは Runtime Fabric でサポートされていますが、証明書をキーストアにインポートする必要があります。

個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。
# Runtime Fabric での Mule Runtime の強化 仕様として、Runtime Fabric では Mule アプリケーションの強化対策が自動的に適用されて有効になります。コンテナリゼーションのベストプラクティスに従って、Mule およびアプリケーションレベルの分離がデフォルトで実行されます。 次の強化チェックリストには、Runtime Fabric を使用した Mule の強化に関する追加情報とベストプラクティスが記載されています。 ## [](#強化チェックリスト)強化チェックリスト
Table 1. Mule の強化手順
強化ステップ 必要なアクション

Mule を非特権ユーザーとして実行します。

この機能は、Runtime Fabric が提供します。

Mule をサービスとしてインストールします

Runtime Fabric は、独自のコンテナ内でアプリケーションごとに Mule Runtime Engine をデプロイすることでこの機能を提供します。

ログまたは一時ファイルを適切な場所内に書き込むように Mule を設定します。ログ、パスワード、およびキーストアのファイルを設定します。

この機能は、Runtime Fabric が提供します。 Mule は、アプリケーションの終了時に削除される一時ファイルシステムに書き込みます。監視情報は、メトリクスが出力されて保存されるディスクの特定の場所のサイドカーエージェントから収集します。ログは、標準出力ストリームから収集されます。

一部の状況では、ユーザー名、パスワード、およびキーストアを Mule で設定する必要があります。通常は、これらの設定を外部で使用できるようにして、DevOps が設定を変更できるようにします。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。

証明書をキーストアファイルで管理します。

これは Runtime Fabric でサポートされていますが、証明書をキーストアにインポートする必要があります。

個別のプロパティファイルを使用してユーザー名とパスワードを保存し、ファイルシステムの権限を使用してそのファイルを保護します。

この機能は、Runtime Fabric が提供します。詳細は、​「Runtime Fabric でのセキュアプロパティの管理」​を参照してください。
# Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限 Runtime Fabric プラットフォームにデプロイされた Mule アプリケーションは基盤となる Kubernetes API サーバーにはアクセスしません。デフォルトで、Mule アプリケーションデプロイメントには RBAC 設定 (​`Role`​ と ​`Rolebindings`​) がありません。 ただし、Mule アプリケーションのユースケースに K8s (Kubernetes) API アクセスが必要な場合、カスタマイズ CRD (カスタムリソース定義) を使用して ​`automountserviceaccounttoken`​ を有効化し、​`Role`​ (お客様所有) と ​`Rolebinding`​ (お客様所有) を Runtime Fabric コアソフトウェアがデプロイメントごとに作成するサービスアカウントにアタッチすることで、この動作を上書きできます。[Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/customize-kubernetes-crd)を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のコントロールプレーン権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-permissions) - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtfctl-permissions) - [Runtime Fabric 向けの Kubernetes の設定](#) # Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限 Runtime Fabric プラットフォームにデプロイされた Mule アプリケーションは基盤となる Kubernetes API サーバーにはアクセスしません。デフォルトで、Mule アプリケーションデプロイメントには RBAC 設定 (​`Role`​ と ​`Rolebindings`​) がありません。 ただし、Mule アプリケーションのユースケースに K8s (Kubernetes) API アクセスが必要な場合、カスタマイズ CRD (カスタムリソース定義) を使用して ​`automountserviceaccounttoken`​ を有効化し、​`Role`​ (お客様所有) と ​`Rolebinding`​ (お客様所有) を Runtime Fabric コアソフトウェアがデプロイメントごとに作成するサービスアカウントにアタッチすることで、この動作を上書きできます。[Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/customize-kubernetes-crd)を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のコントロールプレーン権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-permissions) - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtfctl-permissions) - [Runtime Fabric 向けの Kubernetes の設定](#) # Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限 Runtime Fabric プラットフォームにデプロイされた Mule アプリケーションは基盤となる Kubernetes API サーバーにはアクセスしません。デフォルトで、Mule アプリケーションデプロイメントには RBAC 設定 (​`Role`​ と ​`Rolebindings`​) がありません。 ただし、Mule アプリケーションのユースケースに K8s (Kubernetes) API アクセスが必要な場合、カスタマイズ CRD (カスタムリソース定義) を使用して ​`automountserviceaccounttoken`​ を有効化し、​`Role`​ (お客様所有) と ​`Rolebinding`​ (お客様所有) を Runtime Fabric コアソフトウェアがデプロイメントごとに作成するサービスアカウントにアタッチすることで、この動作を上書きできます。[Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/customize-kubernetes-crd)を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric のコントロールプレーン権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-permissions) - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtfctl-permissions) - [Runtime Fabric 向けの Kubernetes の設定](#) # Runtime Fabric での Mule アプリケーションのバージョン管理の確認 アプリケーションが Runtime Fabric にデプロイされると、Runtime Manager は自動的にアプリケーションとその設定をバージョン管理します。アプリケーションのバージョン管理により、次のことができます。 - アプリケーションの設定変更履歴を表示する。 - 現在適用されている設定に問題がある場合や不安定な場合に、設定を以前のバージョンにロールバックする。 - アプリケーションの状況を表示する。可能な値: - Running (実行中): 少なくとも 1 つのレプリカがトラフィックを受信中 (開始状態) です。 - Not running (停止中): どのレプリカもトラフィックを受信していません。 - Unknown (不明): 対象が切断されています。 - 次のようなデプロイされたアプリケーションの設定を更新する。 - アプリケーションのパッケージ。 - アプリケーションデプロイメントのパッケージバージョン。 - ランタイムバージョン、レプリカ数、アプリケーションがクラスターモードで実行されているかどうかなどのデプロイメント対象設定。 - リソース割り当て (コア数とメモリ割り当てを含む)。 - イングレスおよびプロパティ値。 ## [](#アプリケーションの設定ページにアクセスする)アプリケーションの設定ページにアクセスする 1. Anypoint Platform にサインインし、​**\[Runtime Manager\]**​ に移動します。 **\[Applications (アプリケーション)\]**​ ページが表示されます。 2. **\[Applications (アプリケーション)\]**​ ページから、Runtime Fabric にデプロイするアプリケーションを選択します。 3. 右側で管理パネルを開きます。 4. 管理パネルで、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 **\[Settings (設定)\]**​ ページに、アプリケーションの状況に関する情報、設定履歴、およびアプリケーションに関するその他の役立つ情報が表示されます。 アプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Config changes (設定の変更)\]**​ タブで、Runtime Fabric の正常にデプロイされたアプリケーション設定に対する各変更が表示されます。 最後の 10 個の設定デプロイメントがそれぞれの設定日順に表示されます。履歴内の各設定には、それを識別する一意のハッシュがあります。 ![アプリケーションファイル、バージョン、デプロイメント対象、ランタイムバージョン、レプリカが表示されている Runtime Fabric アプリケーションの設定ページ](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/app-versioning.png)
設定履歴には、作成日順に最新の 10 件の設定デプロイメントが表示されます。
**\[All changes (すべての変更)\]**​ タブには、設定デプロイメントから作成されたバージョンの履歴、および各バージョンで実行されたアクションが表示されます。 ## [](#設定の変更を適用する)設定の変更を適用する 1. アプリケーションの ​**\[Settings (設定)\]**​ ページで、デプロイされた設定に次の変更を加えることができます。 - 新しいアプリケーションパッケージをアップロードする。 - デプロイメント対象とリソース割り当てを変更する。 - **\[Ingress (イングレス)\]**​ および ​**\[Properties (プロパティ)\]**​ の値を変更する。 2. 変更したら、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 **\[Settings (設定)\]**​ ページの上部に、ステータスバーが表示されます。 !["Runtime Manager UI の Mule アプリケーションの \[Applying (適用中)](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/app-versioning-applying-config.png) 設定状況"\] 3. **\[View Status (状況を表示)\]**​ をクリックし、デプロイメントの各レプリカの状況を表示します。 \[Replica (レプリカ)\] の状況は次のとおりです。 - Started (開始済み): レプリカはトラフィックを受信中です。 - Pending (待機中): レプリカは開始を待機中です。 - Starting (開始中): レプリカは開始中です。 - Deleting (削除中): レプリカの削除が進行中です。 - Deleted (削除済み): レプリカは削除されました。 - Stopping (停止中): レプリカは停止中です。 - Stopped (停止済み): レプリカが停止しました (トラフィックを受信していません)。 - Failed (失敗): 設定のデプロイメントが失敗しました。 - Recovering (回復中): レプリカは終了後に再起動しようとしています。 最後に正常にデプロイされた設定は、新しい (目的の) 設定が正常にデプロイされるまで保持されます。 新しい設定は「ローリング更新」として適用されます。 次に例を示します。 - レプリカが目的の設定で作成されます。 - その設定が正常に適用されると、古い設定のレプリカは削除されます。 - このプロセスがデプロイメント内の各レプリカで繰り返されます。 このモデルは、更新がアプリケーションに適用されている間のダウンタイムがゼロであることを意味します。
更新はローリング更新として適用されるため、更新が完了するまで異なるバージョンのアプリケーションが同時に実行されることになります。そのため、アプリケーションが複数のバージョンを並行して実行できることを確認してください。
![Runtime Manager UI の Mule アプリケーションのレプリカ状況](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/app-versioning-replica-status.png) 設定が正常に適用されてデプロイされると、ページの上部にメッセージが表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定が正常に適用された状況](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/app-versioning-config-applied-success.png) 状況ボックスのアプリケーションの状況、設定識別子、日付、その他の情報が更新されます。 ​**\[Config changes (設定の変更)\]**​ リストの上部に、それが最後に正常にデプロイされた設定であることを示す ​**\[Last successful (最終成功)\]**​ 表示ラベルと共に新しい設定が表示されます。 設定への更新のデプロイが失敗した場合、\[​`Desired configuration wasn’t applied`​ (目的の設定は適用されませんでした)\] メッセージが表示され、​**\[Configuration (設定)\]**​ 状況に \[​`Update failed`​ (更新失敗)\] 表示ラベルが表示されます。​**\[Config changes (設定の変更)\]**​ 履歴には設定が表示ラベルなしで表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定を適用できなかった状況](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/app-versioning-update-failed.png) 失敗した場合、デプロイメントは最後に成功したバージョンの設定にロールバックしようとしますが、特定の状況ではロールバックが成功しないことがあります。その設定の状況は \[​`Update failed`​ (更新失敗)\] と表示されます。 それがアプリケーションの最初のデプロイメントである場合、ロールバックバージョンは定義されず、失敗したデプロイメントは失敗状況のままになります。 ## [](#ステートフル-mule-アプリケーションをデプロイする場合の推奨事項)ステートフル Mule アプリケーションをデプロイする場合の推奨事項 - MuleSoft は共有ストレージを必要とするアプリケーションの高可用性のために​[永続性ゲートウェイ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/persistence-gateway)​をサポートしています。 - Mule ​[クラスタリング](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters)​を使用している場合、Hazelcast バージョンの変更を含む Mule Runtime バージョンのローリング更新を行うと、特定の時点でクラスターに異なる Hazelcast バージョンを持つ複数のメンバーが存在するというシナリオが発生します。その結果、Hazelcast バージョンに互換性がない場合、Hazelcast のシリアル化エラーによってアプリケーションが失敗することがあります。 このようなエラーを防ぐには、再作成更新戦略を使用します。 ## [](#以前に成功した設定にロールバックする)以前に成功した設定にロールバックする 問題がある設定をデプロイした場合、以前に成功したバージョンの設定にロールバックできます。 1. **\[Config changes (設定の変更)\]**​ 履歴で、ロールバックするバージョンを選択します。 2. **\[Deploy (デプロイ)\]**​ をクリックします。 設定が ​**\[Config changes (設定の変更)\]**​ 履歴のリストの一番上に移動し、新しいデプロイメント日が表示されます。その元の識別ハッシュが保持されます。 # Runtime Fabric での Mule アプリケーションのバージョン管理の確認 アプリケーションが Runtime Fabric にデプロイされると、Runtime Manager は自動的にアプリケーションとその設定をバージョン管理します。アプリケーションのバージョン管理により、次のことができます。 - アプリケーションの設定変更履歴を表示する。 - 現在適用されている設定に問題がある場合や不安定な場合に、設定を以前のバージョンにロールバックする。 - アプリケーションの状況を表示する。可能な値: - Running (実行中): 少なくとも 1 つのレプリカがトラフィックを受信中 (開始状態) です。 - Not running (停止中): どのレプリカもトラフィックを受信していません。 - Unknown (不明): 対象が切断されています。 - 次のようなデプロイされたアプリケーションの設定を更新する。 - アプリケーションのパッケージ。 - アプリケーションデプロイメントのパッケージバージョン。 - ランタイムバージョン、レプリカ数、アプリケーションがクラスターモードで実行されているかどうかなどのデプロイメント対象設定。 - リソース割り当て (コア数とメモリ割り当てを含む)。 - イングレスおよびプロパティ値。 ## [](#アプリケーションの設定ページにアクセスする)アプリケーションの設定ページにアクセスする 1. Anypoint Platform にサインインし、​**\[Runtime Manager\]**​ に移動します。 **\[Applications (アプリケーション)\]**​ ページが表示されます。 2. **\[Applications (アプリケーション)\]**​ ページから、Runtime Fabric にデプロイするアプリケーションを選択します。 3. 右側で管理パネルを開きます。 4. 管理パネルで、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 **\[Settings (設定)\]**​ ページに、アプリケーションの状況に関する情報、設定履歴、およびアプリケーションに関するその他の役立つ情報が表示されます。 アプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Config changes (設定の変更)\]**​ タブで、Runtime Fabric の正常にデプロイされたアプリケーション設定に対する各変更が表示されます。 最後の 10 個の設定デプロイメントがそれぞれの設定日順に表示されます。履歴内の各設定には、それを識別する一意のハッシュがあります。 ![アプリケーションファイル、バージョン、デプロイメント対象、ランタイムバージョン、レプリカが表示されている Runtime Fabric アプリケーションの設定ページ](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/app-versioning.png)
設定履歴には、作成日順に最新の 10 件の設定デプロイメントが表示されます。
**\[All changes (すべての変更)\]**​ タブには、設定デプロイメントから作成されたバージョンの履歴、および各バージョンで実行されたアクションが表示されます。 ## [](#設定の変更を適用する)設定の変更を適用する 1. アプリケーションの ​**\[Settings (設定)\]**​ ページで、デプロイされた設定に次の変更を加えることができます。 - 新しいアプリケーションパッケージをアップロードする。 - デプロイメント対象とリソース割り当てを変更する。 - **\[Ingress (イングレス)\]**​ および ​**\[Properties (プロパティ)\]**​ の値を変更する。 2. 変更したら、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 **\[Settings (設定)\]**​ ページの上部に、ステータスバーが表示されます。 !["Runtime Manager UI の Mule アプリケーションの \[Applying (適用中)](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/app-versioning-applying-config.png) 設定状況"\] 3. **\[View Status (状況を表示)\]**​ をクリックし、デプロイメントの各レプリカの状況を表示します。 \[Replica (レプリカ)\] の状況は次のとおりです。 - Started (開始済み): レプリカはトラフィックを受信中です。 - Pending (待機中): レプリカは開始を待機中です。 - Starting (開始中): レプリカは開始中です。 - Deleting (削除中): レプリカの削除が進行中です。 - Deleted (削除済み): レプリカは削除されました。 - Stopping (停止中): レプリカは停止中です。 - Stopped (停止済み): レプリカが停止しました (トラフィックを受信していません)。 - Failed (失敗): 設定のデプロイメントが失敗しました。 - Recovering (回復中): レプリカは終了後に再起動しようとしています。 最後に正常にデプロイされた設定は、新しい (目的の) 設定が正常にデプロイされるまで保持されます。 新しい設定は「ローリング更新」として適用されます。 次に例を示します。 - レプリカが目的の設定で作成されます。 - その設定が正常に適用されると、古い設定のレプリカは削除されます。 - このプロセスがデプロイメント内の各レプリカで繰り返されます。 このモデルは、更新がアプリケーションに適用されている間のダウンタイムがゼロであることを意味します。
更新はローリング更新として適用されるため、更新が完了するまで異なるバージョンのアプリケーションが同時に実行されることになります。そのため、アプリケーションが複数のバージョンを並行して実行できることを確認してください。
![Runtime Manager UI の Mule アプリケーションのレプリカ状況](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/app-versioning-replica-status.png) 設定が正常に適用されてデプロイされると、ページの上部にメッセージが表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定が正常に適用された状況](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/app-versioning-config-applied-success.png) 状況ボックスのアプリケーションの状況、設定識別子、日付、その他の情報が更新されます。 ​**\[Config changes (設定の変更)\]**​ リストの上部に、それが最後に正常にデプロイされた設定であることを示す ​**\[Last successful (最終成功)\]**​ 表示ラベルと共に新しい設定が表示されます。 設定への更新のデプロイが失敗した場合、\[​`Desired configuration wasn’t applied`​ (目的の設定は適用されませんでした)\] メッセージが表示され、​**\[Configuration (設定)\]**​ 状況に \[​`Update failed`​ (更新失敗)\] 表示ラベルが表示されます。​**\[Config changes (設定の変更)\]**​ 履歴には設定が表示ラベルなしで表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定を適用できなかった状況](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/app-versioning-update-failed.png) 失敗した場合、デプロイメントは最後に成功したバージョンの設定にロールバックしようとしますが、特定の状況ではロールバックが成功しないことがあります。その設定の状況は \[​`Update failed`​ (更新失敗)\] と表示されます。 それがアプリケーションの最初のデプロイメントである場合、ロールバックバージョンは定義されず、失敗したデプロイメントは失敗状況のままになります。 ## [](#ステートフル-mule-アプリケーションをデプロイする場合の推奨事項)ステートフル Mule アプリケーションをデプロイする場合の推奨事項 - MuleSoft は共有ストレージを必要とするアプリケーションの高可用性のために​[永続性ゲートウェイ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/persistence-gateway)​をサポートしています。 - Mule ​[クラスタリング](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters)​を使用している場合、Hazelcast バージョンの変更を含む Mule Runtime バージョンのローリング更新を行うと、特定の時点でクラスターに異なる Hazelcast バージョンを持つ複数のメンバーが存在するというシナリオが発生します。その結果、Hazelcast バージョンに互換性がない場合、Hazelcast のシリアル化エラーによってアプリケーションが失敗することがあります。 このようなエラーを防ぐには、再作成更新戦略を使用します。 ## [](#以前に成功した設定にロールバックする)以前に成功した設定にロールバックする 問題がある設定をデプロイした場合、以前に成功したバージョンの設定にロールバックできます。 1. **\[Config changes (設定の変更)\]**​ 履歴で、ロールバックするバージョンを選択します。 2. **\[Deploy (デプロイ)\]**​ をクリックします。 設定が ​**\[Config changes (設定の変更)\]**​ 履歴のリストの一番上に移動し、新しいデプロイメント日が表示されます。その元の識別ハッシュが保持されます。 # Runtime Fabric での Mule アプリケーションのバージョン管理の確認 アプリケーションが Runtime Fabric にデプロイされると、Runtime Manager は自動的にアプリケーションとその設定をバージョン管理します。アプリケーションのバージョン管理により、次のことができます。 - アプリケーションの設定変更履歴を表示する。 - 現在適用されている設定に問題がある場合や不安定な場合に、設定を以前のバージョンにロールバックする。 - アプリケーションの状況を表示する。可能な値: - Running (実行中): 少なくとも 1 つのレプリカがトラフィックを受信中 (開始状態) です。 - Not running (停止中): どのレプリカもトラフィックを受信していません。 - Unknown (不明): 対象が切断されています。 - 次のようなデプロイされたアプリケーションの設定を更新する。 - アプリケーションのパッケージ。 - アプリケーションデプロイメントのパッケージバージョン。 - ランタイムバージョン、レプリカ数、アプリケーションがクラスターモードで実行されているかどうかなどのデプロイメント対象設定。 - リソース割り当て (コア数とメモリ割り当てを含む)。 - イングレスおよびプロパティ値。 ## [](#アプリケーションの設定ページにアクセスする)アプリケーションの設定ページにアクセスする 1. Anypoint Platform にサインインし、​**\[Runtime Manager\]**​ に移動します。 **\[Applications (アプリケーション)\]**​ ページが表示されます。 2. **\[Applications (アプリケーション)\]**​ ページから、Runtime Fabric にデプロイするアプリケーションを選択します。 3. 右側で管理パネルを開きます。 4. 管理パネルで、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 **\[Settings (設定)\]**​ ページに、アプリケーションの状況に関する情報、設定履歴、およびアプリケーションに関するその他の役立つ情報が表示されます。 アプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Config changes (設定の変更)\]**​ タブで、Runtime Fabric の正常にデプロイされたアプリケーション設定に対する各変更が表示されます。 最後の 10 個の設定デプロイメントがそれぞれの設定日順に表示されます。履歴内の各設定には、それを識別する一意のハッシュがあります。 ![アプリケーションファイル、バージョン、デプロイメント対象、ランタイムバージョン、レプリカが表示されている Runtime Fabric アプリケーションの設定ページ](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/app-versioning.png)
設定履歴には、作成日順に最新の 10 件の設定デプロイメントが表示されます。
**\[All changes (すべての変更)\]**​ タブには、設定デプロイメントから作成されたバージョンの履歴、および各バージョンで実行されたアクションが表示されます。 ## [](#設定の変更を適用する)設定の変更を適用する 1. アプリケーションの ​**\[Settings (設定)\]**​ ページで、デプロイされた設定に次の変更を加えることができます。 - 新しいアプリケーションパッケージをアップロードする。 - デプロイメント対象とリソース割り当てを変更する。 - **\[Ingress (イングレス)\]**​ および ​**\[Properties (プロパティ)\]**​ の値を変更する。 2. 変更したら、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 **\[Settings (設定)\]**​ ページの上部に、ステータスバーが表示されます。 !["Runtime Manager UI の Mule アプリケーションの \[Applying (適用中)](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/app-versioning-applying-config.png) 設定状況"\] 3. **\[View Status (状況を表示)\]**​ をクリックし、デプロイメントの各レプリカの状況を表示します。 \[Replica (レプリカ)\] の状況は次のとおりです。 - Started (開始済み): レプリカはトラフィックを受信中です。 - Pending (待機中): レプリカは開始を待機中です。 - Starting (開始中): レプリカは開始中です。 - Deleting (削除中): レプリカの削除が進行中です。 - Deleted (削除済み): レプリカは削除されました。 - Stopping (停止中): レプリカは停止中です。 - Stopped (停止済み): レプリカが停止しました (トラフィックを受信していません)。 - Failed (失敗): 設定のデプロイメントが失敗しました。 - Recovering (回復中): レプリカは終了後に再起動しようとしています。 最後に正常にデプロイされた設定は、新しい (目的の) 設定が正常にデプロイされるまで保持されます。 新しい設定は「ローリング更新」として適用されます。 次に例を示します。 - レプリカが目的の設定で作成されます。 - その設定が正常に適用されると、古い設定のレプリカは削除されます。 - このプロセスがデプロイメント内の各レプリカで繰り返されます。 このモデルは、更新がアプリケーションに適用されている間のダウンタイムがゼロであることを意味します。
更新はローリング更新として適用されるため、更新が完了するまで異なるバージョンのアプリケーションが同時に実行されることになります。そのため、アプリケーションが複数のバージョンを並行して実行できることを確認してください。
![Runtime Manager UI の Mule アプリケーションのレプリカ状況](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/app-versioning-replica-status.png) 設定が正常に適用されてデプロイされると、ページの上部にメッセージが表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定が正常に適用された状況](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/app-versioning-config-applied-success.png) 状況ボックスのアプリケーションの状況、設定識別子、日付、その他の情報が更新されます。 ​**\[Config changes (設定の変更)\]**​ リストの上部に、それが最後に正常にデプロイされた設定であることを示す ​**\[Last successful (最終成功)\]**​ 表示ラベルと共に新しい設定が表示されます。 設定への更新のデプロイが失敗した場合、\[​`Desired configuration wasn’t applied`​ (目的の設定は適用されませんでした)\] メッセージが表示され、​**\[Configuration (設定)\]**​ 状況に \[​`Update failed`​ (更新失敗)\] 表示ラベルが表示されます。​**\[Config changes (設定の変更)\]**​ 履歴には設定が表示ラベルなしで表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定を適用できなかった状況](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/app-versioning-update-failed.png) 失敗した場合、デプロイメントは最後に成功したバージョンの設定にロールバックしようとしますが、特定の状況ではロールバックが成功しないことがあります。その設定の状況は \[​`Update failed`​ (更新失敗)\] と表示されます。 それがアプリケーションの最初のデプロイメントである場合、ロールバックバージョンは定義されず、失敗したデプロイメントは失敗状況のままになります。 ## [](#ステートフル-mule-アプリケーションをデプロイする場合の推奨事項)ステートフル Mule アプリケーションをデプロイする場合の推奨事項 - MuleSoft は共有ストレージを必要とするアプリケーションの高可用性のために​[永続性ゲートウェイ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/persistence-gateway)​をサポートしています。 - Mule ​[クラスタリング](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters)​を使用している場合、Hazelcast バージョンの変更を含む Mule Runtime バージョンのローリング更新を行うと、特定の時点でクラスターに異なる Hazelcast バージョンを持つ複数のメンバーが存在するというシナリオが発生します。その結果、Hazelcast バージョンに互換性がない場合、Hazelcast のシリアル化エラーによってアプリケーションが失敗することがあります。 このようなエラーを防ぐには、再作成更新戦略を使用します。 ## [](#以前に成功した設定にロールバックする)以前に成功した設定にロールバックする 問題がある設定をデプロイした場合、以前に成功したバージョンの設定にロールバックできます。 1. **\[Config changes (設定の変更)\]**​ 履歴で、ロールバックするバージョンを選択します。 2. **\[Deploy (デプロイ)\]**​ をクリックします。 設定が ​**\[Config changes (設定の変更)\]**​ 履歴のリストの一番上に移動し、新しいデプロイメント日が表示されます。その元の識別ハッシュが保持されます。 # Runtime Fabric での Mule アプリケーションのプロパティ値の保護 Anypoint Runtime Fabric を使用すると、Anypoint Runtime Manager でプロパティ名を表示してその値は表示しないことで、アプリケーションのプロパティ値を保護できます。 さらに、保護された値はどのユーザーも表示または取得できません。Runtime Fabric は、実行時にプロパティを内部的に解決します。これらの保護されたアプリケーション値は暗号化され、Anypoint Security シークレットマネージャーに保存されます。その後、ユーザー組織ごとに暗号化されます。 保護されたプロパティ値は、セキュアな設定ファイルに保存される暗号化された Mule アプリケーションのプロパティとは別のものです。​[「セキュア設定プロパティ」](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties)​を参照してください。

Runtime Manager では、API プロキシまたはゲートウェイの保護されたプロパティの追加はサポートされません。代わりに、API Manager を使用してください。

現在、Runtime Fabric では、API または Anypoint Runtime Manager UI を使用して、API Gateway のクライアント ID とシークレット ID を保護できます。
## [](#runtime-manager-でプロパティ値を保護する)Runtime Manager でプロパティ値を保護する テーブルビューを介して保護されたプロパティを設定し、各プロパティと値を詳細に制御します。 1 つのプロパティを複数回保護しようとすることはできますが、Runtime Manager によって警告が発行され、そのプロパティの最後のインスタンスのみが保護されます。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. 左側のメニューから ​**\[Applications (アプリケーション)\]**​ をクリックします。 3. アプリケーション名をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. 一度に保護するプロパティの数に応じて、次のいずれかのアクションを実行します。 - プロパティを 1 つずつ保護するには、​**\[Table view (テーブルビュー)\]**​ をクリックします。 - 複数のプロパティを保護するには、​**\[Text view (テキストビュー)\]**​ を使用してキー-値ペアを追加し、​**\[Table view (テーブルビュー)\]**​ に切り替えてから、ステップ 8 に進みます。 6. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 7. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 ![テーブルビューでのプロパティの追加](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-add-protected-properties.png) 8. **\[Protect (保護)\]**​ > ​**\[Protect value (値を保護)\]**​ をクリックして確認します。 9. 次のいずれかを選択します。 - このアプリケーションがすでにデプロイされている場合、​**\[Apply changes (変更を適用)\]**​ をクリックします。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Properties (プロパティ)\]**​ タブで、ここで保護したプロパティの値は自分にも他のユーザーにも表示されなくなります。 次の例では、​`dbPassword`​ の値は保護されますが、​`dbUsername`​ と ​`environment`​ の値は保護されません。 ![dbpassword の値が保護と表示](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-view-protected-properties.png) 値をコミットし、アプリケーションをデプロイしたら、保護されたプロパティの値はコンソールに表示されなくなります。また、コンソールと Runtime Manager の間で送受信されることもありません。 ## [](#保護されたプロパティ値を置き換える)保護されたプロパティ値を置き換える プロパティ値を保護した後は、その値は取得できません。ただし、保護されたプロパティ値を新しい保護された値に置き換えることができます。 1. テーブルビューで、置き換える保護された値の横にあるアイコンをクリックします。 2. 値の横にあるメニューアイコンをクリックし、​**\[Replace protected value (保護された値を置換)\]**​ をクリックします。 3. 項目に新しい値を入力します。 4. **\[Apply (適用)\]**​ > ​**\[Apply changes (変更を適用)\]**​ をクリックします。 # Runtime Fabric での Mule アプリケーションのプロパティ値の保護 Anypoint Runtime Fabric を使用すると、Anypoint Runtime Manager でプロパティ名を表示してその値は表示しないことで、アプリケーションのプロパティ値を保護できます。 さらに、保護された値はどのユーザーも表示または取得できません。Runtime Fabric は、実行時にプロパティを内部的に解決します。これらの保護されたアプリケーション値は暗号化され、Anypoint Security シークレットマネージャーに保存されます。その後、ユーザー組織ごとに暗号化されます。 保護されたプロパティ値は、セキュアな設定ファイルに保存される暗号化された Mule アプリケーションのプロパティとは別のものです。​[「セキュア設定プロパティ」](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties)​を参照してください。

Runtime Manager では、API プロキシまたはゲートウェイの保護されたプロパティの追加はサポートされません。代わりに、API Manager を使用してください。

現在、Runtime Fabric では、API または Anypoint Runtime Manager UI を使用して、API Gateway のクライアント ID とシークレット ID を保護できます。
## [](#runtime-manager-でプロパティ値を保護する)Runtime Manager でプロパティ値を保護する テーブルビューを介して保護されたプロパティを設定し、各プロパティと値を詳細に制御します。 1 つのプロパティを複数回保護しようとすることはできますが、Runtime Manager によって警告が発行され、そのプロパティの最後のインスタンスのみが保護されます。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. 左側のメニューから ​**\[Applications (アプリケーション)\]**​ をクリックします。 3. アプリケーション名をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. 一度に保護するプロパティの数に応じて、次のいずれかのアクションを実行します。 - プロパティを 1 つずつ保護するには、​**\[Table view (テーブルビュー)\]**​ をクリックします。 - 複数のプロパティを保護するには、​**\[Text view (テキストビュー)\]**​ を使用してキー-値ペアを追加し、​**\[Table view (テーブルビュー)\]**​ に切り替えてから、ステップ 8 に進みます。 6. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 7. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 ![テーブルビューでのプロパティの追加](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-add-protected-properties.png) 8. **\[Protect (保護)\]**​ > ​**\[Protect value (値を保護)\]**​ をクリックして確認します。 9. 次のいずれかを選択します。 - このアプリケーションがすでにデプロイされている場合、​**\[Apply changes (変更を適用)\]**​ をクリックします。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Properties (プロパティ)\]**​ タブで、ここで保護したプロパティの値は自分にも他のユーザーにも表示されなくなります。 次の例では、​`dbPassword`​ の値は保護されますが、​`dbUsername`​ と ​`environment`​ の値は保護されません。 ![dbpassword の値が保護と表示](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-view-protected-properties.png) 値をコミットし、アプリケーションをデプロイしたら、保護されたプロパティの値はコンソールに表示されなくなります。また、コンソールと Runtime Manager の間で送受信されることもありません。 ## [](#保護されたプロパティ値を置き換える)保護されたプロパティ値を置き換える プロパティ値を保護した後は、その値は取得できません。ただし、保護されたプロパティ値を新しい保護された値に置き換えることができます。 1. テーブルビューで、置き換える保護された値の横にあるアイコンをクリックします。 2. 値の横にあるメニューアイコンをクリックし、​**\[Replace protected value (保護された値を置換)\]**​ をクリックします。 3. 項目に新しい値を入力します。 4. **\[Apply (適用)\]**​ > ​**\[Apply changes (変更を適用)\]**​ をクリックします。 # Runtime Fabric での Mule アプリケーションのプロパティ値の保護 Anypoint Runtime Fabric を使用すると、Anypoint Runtime Manager でプロパティ名を表示してその値は表示しないことで、アプリケーションのプロパティ値を保護できます。 さらに、保護された値はどのユーザーも表示または取得できません。Runtime Fabric は、実行時にプロパティを内部的に解決します。これらの保護されたアプリケーション値は暗号化され、Anypoint Security シークレットマネージャーに保存されます。その後、ユーザー組織ごとに暗号化されます。 保護されたプロパティ値は、セキュアな設定ファイルに保存される暗号化された Mule アプリケーションのプロパティとは別のものです。​[「セキュア設定プロパティ」](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties)​を参照してください。

Runtime Manager では、API プロキシまたはゲートウェイの保護されたプロパティの追加はサポートされません。代わりに、API Manager を使用してください。

現在、Runtime Fabric では、API または Anypoint Runtime Manager UI を使用して、API Gateway のクライアント ID とシークレット ID を保護できます。
## [](#runtime-manager-でプロパティ値を保護する)Runtime Manager でプロパティ値を保護する テーブルビューを介して保護されたプロパティを設定し、各プロパティと値を詳細に制御します。 1 つのプロパティを複数回保護しようとすることはできますが、Runtime Manager によって警告が発行され、そのプロパティの最後のインスタンスのみが保護されます。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. 左側のメニューから ​**\[Applications (アプリケーション)\]**​ をクリックします。 3. アプリケーション名をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. 一度に保護するプロパティの数に応じて、次のいずれかのアクションを実行します。 - プロパティを 1 つずつ保護するには、​**\[Table view (テーブルビュー)\]**​ をクリックします。 - 複数のプロパティを保護するには、​**\[Text view (テキストビュー)\]**​ を使用してキー-値ペアを追加し、​**\[Table view (テーブルビュー)\]**​ に切り替えてから、ステップ 8 に進みます。 6. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 7. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 ![テーブルビューでのプロパティの追加](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-add-protected-properties.png) 8. **\[Protect (保護)\]**​ > ​**\[Protect value (値を保護)\]**​ をクリックして確認します。 9. 次のいずれかを選択します。 - このアプリケーションがすでにデプロイされている場合、​**\[Apply changes (変更を適用)\]**​ をクリックします。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Properties (プロパティ)\]**​ タブで、ここで保護したプロパティの値は自分にも他のユーザーにも表示されなくなります。 次の例では、​`dbPassword`​ の値は保護されますが、​`dbUsername`​ と ​`environment`​ の値は保護されません。 ![dbpassword の値が保護と表示](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-view-protected-properties.png) 値をコミットし、アプリケーションをデプロイしたら、保護されたプロパティの値はコンソールに表示されなくなります。また、コンソールと Runtime Manager の間で送受信されることもありません。 ## [](#保護されたプロパティ値を置き換える)保護されたプロパティ値を置き換える プロパティ値を保護した後は、その値は取得できません。ただし、保護されたプロパティ値を新しい保護された値に置き換えることができます。 1. テーブルビューで、置き換える保護された値の横にあるアイコンをクリックします。 2. 値の横にあるメニューアイコンをクリックし、​**\[Replace protected value (保護された値を置換)\]**​ をクリックします。 3. 項目に新しい値を入力します。 4. **\[Apply (適用)\]**​ > ​**\[Apply changes (変更を適用)\]**​ をクリックします。 # Runtime Fabric での Red Hat OpenShift ルートの設定 Runtime Fabric では、Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定できます。 ## [](#始める前に)始める前に Runtime Fabric でのルートの設定は、イングレスリソースの設定と密接に連携しています。ルートを作成する前に、以下を確認してください。 - [Runtime Fabric でのイングレスリソーステンプレートの動作](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [イングレスリソーステンプレートの例](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration#example-ingress-resource-templates) - [イングレスオブジェクトを経由するルートの作成](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​. ## [](#red-hat-openshift-ルート用のイングレスリソーステンプレートの例)Red Hat OpenShift ルート用のイングレスリソーステンプレートの例 次の例では、networking.k8s.io/v1 API 用の Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName​ は、​rtf-​ のプレフィックスを付けて、​rtf-openshift​ に設定する必要があります。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。​spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。イングレスコントローラーでは、ベンダー固有の名前 (​openshift​ など) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。テンプレートで指定した場合、​route.openshift.io/termination:​ アノテーションを設定しない限り、Runtime Fabric はデフォルトでエッジ終端のルートを作成します。
4 アプリケーションをデプロイすると、Runtime Fabric は ​app-name​ プレースホルダーのパラメーターを実際のアプリケーション名に置き換えます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 Runtime Fabric は、Mule アプリケーションのイングレスを設定するときに [Path (パス)] 項目に追加した値で ​path​ パラメーター値を置き換えます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
省略可能なプレースホルダー値のリストは、​[「テンプレートのプレースホルダー」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration#template-placeholders)​を参照してください。 ## [](#runtime-fabric-でのルートの設定)Runtime Fabric でのルートの設定 ルートを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-template-for-a-red-hat-openshift-route)​を使用してルート用のイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 アプリケーションをデプロイすると Runtime Manager は、アプリケーションにトラフィックを転送するルートを、指定されたテンプレートに従って作成します。 ## [](#パススルー-tls-終端を設定する)パススルー TLS 終端を設定する パススルー TLS 終端を含めるようにイングレスリソーステンプレートを設定できます。 パススルー TLS 終端を使用するパスの設定については、 [Red Hat OpenShift ドキュメント](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​を参照してください。 イングレスリソーステンプレートを作成する手順は、次のとおりです。 1. テンプレートで、次のアノテーションを追加します。 route.openshift.io/termination: passthrough 2. テンプレートで、次のパラメーター値を設定します。 - `path: ''`​ (空の文字列) - `pathType: ImplementationSpecific` 3. Runtime Manager で、Mule アプリケーション用のイングレスを設定するときに、​**Path**​ 項目に ​`/`​ を含めます。 アプリケーションエンドポイントに、パススルー TLS 終端の HTTPS が表示されます。 ## [](#再暗号化の終了を設定する)再暗号化の終了を設定する `route.openshift.io/termination:reencrypt`​ アノテーションをテンプレートに追加することで、ingress リソーステンプレートに再暗号化の終了を含めるように設定できます。 再暗号化の終了を設定する手順は、次のとおりです。 1. 対象 CA 証明書 (自己署名証明書またはチェーン) を保持するシークレットオブジェクトを作成します。 次の mule-app.cert ファイルには、対象 Mule アプリケーションのキーストアで使用されるリーフ証明書を PEM エンコードした証明書 (チェーンまたは自己署名証明書) が含まれています。 kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. シークレットに表示ラベルを追加して、Mule アプリケーションの名前空間に伝搬させます。 kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. `route.openshift.io/destination-ca-certificate-secret:`​ アノテーションを追加して、Runtime Fabric 名前空間にイングレステンプレートを作成するか、または一度削除して再作成します。 \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. \[Runtime Manager\] > \[Application settings (アプリケーションの設定)\]で、イングレスエンドポイントを選択します。同じ名前のイングレスエンドポイントがすでに存在する場合は、削除してから変更を適用し、新しいイングレスエンドポイントを選択して、再び変更を適用します。 5. Mule アプリケーションの名前空間にイングレス、シークレット、ルートが存在することを確認します。これで要求は成功するはずです。 kubectl -n get ingress kubectl -n get routes kubectl -n get secret 例: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque 1 52m ah-tls kubernetes.io/tls 2 131m # Runtime Fabric での Red Hat OpenShift ルートの設定 Runtime Fabric では、Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定できます。 ## [](#始める前に)始める前に Runtime Fabric でのルートの設定は、イングレスリソースの設定と密接に連携しています。ルートを作成する前に、以下を確認してください。 - [Runtime Fabric でのイングレスリソーステンプレートの動作](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [イングレスリソーステンプレートの例](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration#example-ingress-resource-templates) - [イングレスオブジェクトを経由するルートの作成](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​。 ## [](#red-hat-openshift-ルートのイングレスリソーステンプレートの例)Red Hat OpenShift ルートのイングレスリソーステンプレートの例 次の例では、networking.k8s.io/v1 API の Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName​ は、​rtf-​ のプレフィックスを付けて、​rtf-openshift​ に設定する必要があります。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。​spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。イングレスコントローラーでは、ベンダー固有の名前 (​openshift​ など) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。テンプレートで指定した場合、​route.openshift.io/termination:​ アノテーションを設定しない限り、Runtime Fabric はデフォルトでエッジ終端のルートを作成します。
4 アプリケーションをデプロイすると、Runtime Fabric は ​app-name​ プレースホルダーのパラメーターを実際のアプリケーション名に置き換えます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 Runtime Fabric は、Mule アプリケーションのイングレスを設定するときに [Path (パス)] 項目に追加した値で ​path​ パラメーター値を置き換えます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
省略可能なプレースホルダー値のリストは、​[「テンプレートのプレースホルダー」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration#template-placeholders)​を参照してください。 ## [](#runtime-fabric-でのルートの設定)Runtime Fabric でのルートの設定 ルートを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-template-for-a-red-hat-openshift-route)​を使用してルート用のイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 アプリケーションをデプロイすると Runtime Manager は、アプリケーションにトラフィックを転送するルートを、指定されたテンプレートに従って作成します。 ## [](#パススルー-tls-終端を設定する)パススルー TLS 終端を設定する パススルー TLS 終端を含めるようにイングレスリソーステンプレートを設定できます。 パススルー TLS 終端を使用するパスの設定については、 [Red Hat OpenShift ドキュメント](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​を参照してください。 イングレスリソーステンプレートを作成する手順は、次のとおりです。 1. テンプレートで、次のアノテーションを追加します。 route.openshift.io/termination: passthrough 2. テンプレートで、次のパラメーター値を設定します。 - `path: ''`​ (空の文字列) - `pathType: ImplementationSpecific` 3. Runtime Manager で、Mule アプリケーション用のイングレスを設定するときに、​**Path**​ 項目に ​`/`​ を含めます。 アプリケーションエンドポイントに、パススルー TLS 終端の HTTPS が表示されます。 ## [](#再暗号化の終了を設定する)再暗号化の終了を設定する `route.openshift.io/termination:reencrypt`​ アノテーションをテンプレートに追加することで、ingress リソーステンプレートに再暗号化の終了を含めるように設定できます。 再暗号化の終了を設定する手順は、次のとおりです。 1. 対象 CA 証明書 (自己署名証明書またはチェーン) を保持するシークレットオブジェクトを作成します。 次の mule-app.cert ファイルには、対象 Mule アプリケーションのキーストアで使用されるリーフ証明書を PEM エンコードした証明書 (チェーンまたは自己署名証明書) が含まれています。 kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. シークレットに表示ラベルを追加して、Mule アプリケーションの名前空間に伝搬させます。 kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. `route.openshift.io/destination-ca-certificate-secret:`​ アノテーションを追加して、Runtime Fabric 名前空間にイングレステンプレートを作成するか、または一度削除して再作成します。 \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. \[Runtime Manager\] > \[Application settings (アプリケーションの設定)\] で、イングレスエンドポイントを選択します。同じ名前のイングレスエンドポイントがすでに存在する場合は、削除してから変更を適用し、新しいイングレスエンドポイントを選択して、再び変更を適用します。 5. Mule アプリケーションの名前空間にイングレス、シークレット、ルートが存在することを確認します。これで要求は成功するはずです。 kubectl -n get ingress kubectl -n get routes kubectl -n get secret 例: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque 1 52m ah-tls kubernetes.io/tls 2 131m # Runtime Fabric での Red Hat OpenShift ルートの設定 Runtime Fabric では、Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定できます。 ## [](#始める前に)始める前に Runtime Fabric でのルートの設定は、イングレスリソースの設定と密接に連携しています。ルートを作成する前に、以下を確認してください。 - [Runtime Fabric でのイングレスリソーステンプレートの動作](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [イングレスリソーステンプレートの例](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration#example-ingress-resource-templates) - [イングレスオブジェクトを経由するルートの作成](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​。 ## [](#red-hat-openshift-ルートのイングレスリソーステンプレートの例)Red Hat OpenShift ルートのイングレスリソーステンプレートの例 次の例では、networking.k8s.io/v1 API の Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName​ は、​rtf-​ のプレフィックスを付けて、​rtf-openshift​ に設定する必要があります。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。​spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。イングレスコントローラーでは、ベンダー固有の名前 (​openshift​ など) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。テンプレートで指定した場合、​route.openshift.io/termination:​ アノテーションを設定しない限り、Runtime Fabric はデフォルトでエッジ終端のルートを作成します。
4 アプリケーションをデプロイすると、Runtime Fabric は ​app-name​ プレースホルダーのパラメーターを実際のアプリケーション名に置き換えます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 Runtime Fabric は、Mule アプリケーションのイングレスを設定するときに [Path (パス)] 項目に追加した値で ​path​ パラメーター値を置き換えます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
省略可能なプレースホルダー値のリストは、​[「テンプレートのプレースホルダー」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration#template-placeholders)​を参照してください。 ## [](#runtime-fabric-でのルートの設定)Runtime Fabric でのルートの設定 ルートを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-template-for-a-red-hat-openshift-route)​を使用してルート用のイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 アプリケーションをデプロイすると Runtime Manager は、アプリケーションにトラフィックを転送するルートを、指定されたテンプレートに従って作成します。 ## [](#パススルー-tls-終端を設定する)パススルー TLS 終端を設定する パススルー TLS 終端を含めるようにイングレスリソーステンプレートを設定できます。 パススルー TLS 終端を使用するパスの設定については、 [Red Hat OpenShift ドキュメント](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​を参照してください。 イングレスリソーステンプレートを作成する手順は、次のとおりです。 1. テンプレートで、次のアノテーションを追加します。 route.openshift.io/termination: passthrough 2. テンプレートで、次のパラメーター値を設定します。 - `path: ''`​ (空の文字列) - `pathType: ImplementationSpecific` 3. Runtime Manager で、Mule アプリケーション用のイングレスを設定するときに、​**Path**​ 項目に ​`/`​ を含めます。 アプリケーションエンドポイントに、パススルー TLS 終端の HTTPS が表示されます。 ## [](#再暗号化の終了を設定する)再暗号化の終了を設定する `route.openshift.io/termination:reencrypt`​ アノテーションをテンプレートに追加することで、ingress リソーステンプレートに再暗号化の終了を含めるように設定できます。 再暗号化の終了を設定する手順は、次のとおりです。 1. 対象 CA 証明書 (自己署名証明書またはチェーン) を保持するシークレットオブジェクトを作成します。 次の mule-app.cert ファイルには、対象 Mule アプリケーションのキーストアで使用されるリーフ証明書を PEM エンコードした証明書 (チェーンまたは自己署名証明書) が含まれています。 kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. シークレットに表示ラベルを追加して、Mule アプリケーションの名前空間に伝搬させます。 kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. `route.openshift.io/destination-ca-certificate-secret:`​ アノテーションを追加して、Runtime Fabric 名前空間にイングレステンプレートを作成するか、または一度削除して再作成します。 \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. \[Runtime Manager\] > \[Application settings (アプリケーションの設定)\] で、イングレスエンドポイントを選択します。同じ名前のイングレスエンドポイントがすでに存在する場合は、削除してから変更を適用し、新しいイングレスエンドポイントを選択して、再び変更を適用します。 5. Mule アプリケーションの名前空間にイングレス、シークレット、ルートが存在することを確認します。これで要求は成功するはずです。 kubectl -n get ingress kubectl -n get routes kubectl -n get secret 例: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque 1 52m ah-tls kubernetes.io/tls 2 131m # Runtime Fabric での Red Hat OpenShift ルートの設定 Runtime Fabric では、Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定できます。 ## [](#始める前に)始める前に Runtime Fabric でのルートの設定は、イングレスリソースの設定と密接に連携しています。ルートを作成する前に、以下を確認してください。 - [Runtime Fabric でのイングレスリソーステンプレートの動作](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration#how-ingress-resources-templates-work-in-runtime-fabric) - [イングレスリソーステンプレートの例](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration#example-ingress-resource-templates) - [イングレスオブジェクトを経由するルートの作成](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​。 ## [](#red-hat-openshift-ルートのイングレスリソーステンプレートの例)Red Hat OpenShift ルートのイングレスリソーステンプレートの例 次の例では、networking.k8s.io/v1 API の Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf #(1) labels: spec: ingressClassName: rtf-openshift #(2) tls: #(3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com #(4) http: paths: #(5) - pathType: Prefix path: / #(6) backend: #(7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName​ は、​rtf-​ のプレフィックスを付けて、​rtf-openshift​ に設定する必要があります。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。​spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。イングレスコントローラーでは、ベンダー固有の名前 (​openshift​ など) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。テンプレートで指定した場合、​route.openshift.io/termination:​ アノテーションを設定しない限り、Runtime Fabric はデフォルトでエッジ終端のルートを作成します。
4 アプリケーションをデプロイすると、Runtime Fabric は ​app-name​ プレースホルダーのパラメーターを実際のアプリケーション名に置き換えます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 Runtime Fabric は、Mule アプリケーションのイングレスを設定するときに [Path (パス)] 項目に追加した値で ​path​ パラメーター値を置き換えます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
省略可能なプレースホルダー値のリストは、​[「テンプレートのプレースホルダー」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration#template-placeholders)​を参照してください。 ## [](#runtime-fabric-でのルートの設定)Runtime Fabric でのルートの設定 ルートを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-template-for-a-red-hat-openshift-route)​を使用してルート用のイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 アプリケーションをデプロイすると Runtime Manager は、アプリケーションにトラフィックを転送するルートを、指定されたテンプレートに従って作成します。 ## [](#パススルー-tls-終端を設定する)パススルー TLS 終端を設定する パススルー TLS 終端を含めるようにイングレスリソーステンプレートを設定できます。 パススルー TLS 終端を使用するパスの設定については、 [Red Hat OpenShift ドキュメント](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration)​を参照してください。 イングレスリソーステンプレートを作成する手順は、次のとおりです。 1. テンプレートで、次のアノテーションを追加します。 route.openshift.io/termination: passthrough 2. テンプレートで、次のパラメーター値を設定します。 - `path: ''`​ (空の文字列) - `pathType: ImplementationSpecific` 3. Runtime Manager で、Mule アプリケーション用のイングレスを設定するときに、​**Path**​ 項目に ​`/`​ を含めます。 アプリケーションエンドポイントに、パススルー TLS 終端の HTTPS が表示されます。 ## [](#再暗号化の終了を設定する)再暗号化の終了を設定する `route.openshift.io/termination:reencrypt`​ アノテーションをテンプレートに追加することで、ingress リソーステンプレートに再暗号化の終了を含めるように設定できます。 再暗号化の終了を設定する手順は、次のとおりです。 1. 対象 CA 証明書 (自己署名証明書またはチェーン) を保持するシークレットオブジェクトを作成します。 次の mule-app.cert ファイルには、対象 Mule アプリケーションのキーストアで使用されるリーフ証明書を PEM エンコードした証明書 (チェーンまたは自己署名証明書) が含まれています。 kubectl -nrtf create secret generic ah-destination-tls \\ --from-file=tls.crt=mule-app.cert 2. シークレットに表示ラベルを追加して、Mule アプリケーションの名前空間に伝搬させます。 kubectl -n rtf label secret ah-destination-tls "rtf.mulesoft.com/synchronized=true"" 3. `route.openshift.io/destination-ca-certificate-secret:`​ アノテーションを追加して、Runtime Fabric 名前空間にイングレステンプレートを作成するか、または一度削除して再作成します。 \> cat ingress-reencrypt.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: "ah-destination-tls" name: rtf-ingress namespace: rtf labels: spec: ingressClassName: rtf-openshift tls: - hosts: - app-name.andrew.com secretName: ah-tls rules: - host: app-name.andrew.com http: paths: - path: / pathType: Prefix backend: service: name: service-name port: name: service-port 4. \[Runtime Manager\] > \[Application settings (アプリケーションの設定)\] で、イングレスエンドポイントを選択します。同じ名前のイングレスエンドポイントがすでに存在する場合は、削除してから変更を適用し、新しいイングレスエンドポイントを選択して、再び変更を適用します。 5. Mule アプリケーションの名前空間にイングレス、シークレット、ルートが存在することを確認します。これで要求は成功するはずです。 kubectl -n get ingress kubectl -n get routes kubectl -n get secret 例: \> kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get ingress NAME CLASS HOSTS ADDRESS PORTS AGE ah-app-1-rtf-ingress ah-app-1.andrew.com router-default.apps.ah-rtf-rosa-1.9esk.p1.openshiftapps.com 80, 443 7m30s > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD ah-app-1-rtf-ingress-6vhpq ah-app-1.andrew.com / ah-app-1 http reencrypt/Redirect None > kubectl -n 82e05f0d-21d7-4808-8088-2dd132095326 get secret | grep -i tls ah-destination-tls Opaque 1 52m ah-tls kubernetes.io/tls 2 131m # Runtime Fabric でのアプリケーションのバージョン管理の確認 アプリケーションが Runtime Fabric にデプロイされると、Runtime Manager は自動的にアプリケーションとその設定をバージョン管理します。アプリケーションのバージョン管理により、次のことができます。 - アプリケーションの設定変更履歴を表示する。 - 現在適用されている設定に問題がある場合や不安定な場合に、設定を以前のバージョンにロールバックする。 - アプリケーションの状況を表示する。可能な値: - Running (実行中): 少なくとも 1 つのレプリカがトラフィックを受信中 (開始状態) です。 - Not running (停止中): どのレプリカもトラフィックを受信していません。 - Unknown (不明): 対象が切断されています。 - 次のようなデプロイされたアプリケーションの設定を更新する。 - アプリケーションのパッケージ。 - アプリケーションデプロイメントのパッケージバージョン。 - ランタイムバージョン、レプリカ数、アプリケーションがクラスターモードで実行されているかどうかなどのデプロイメント対象設定。 - リソース割り当て (コア数とメモリ割り当てを含む)。 - イングレスおよびプロパティ値。 ## [](#アプリケーションの設定ページにアクセスする)アプリケーションの設定ページにアクセスする 1. Anypoint Platform にサインインし、​**\[Runtime Manager\]**​ に移動します。 **\[Applications (アプリケーション)\]**​ ページが表示されます。 2. **\[Applications (アプリケーション)\]**​ ページから、Runtime Fabric にデプロイするアプリケーションを選択します。 3. 右側で管理パネルを開きます。 4. 管理パネルで、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 **\[Settings (設定)\]**​ ページに、アプリケーションの状況に関する情報、設定履歴、およびアプリケーションに関するその他の役立つ情報が表示されます。 アプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Config changes (設定の変更)\]**​ タブで、Runtime Fabric の正常にデプロイされたアプリケーション設定に対する各変更が表示されます。 最後の 10 個の設定デプロイメントがそれぞれの設定日順に表示されます。履歴内の各設定には、それを識別する一意のハッシュがあります。 ![アプリケーションファイル、バージョン、デプロイメント対象、ランタイムバージョン、レプリカが表示されている Runtime Fabric アプリケーションの設定ページ](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/app-versioning.png)
設定履歴には、作成日順に最新の 10 件の設定デプロイメントが表示されます。
**\[All changes (すべての変更)\]**​ タブには、設定デプロイメントから作成されたバージョンの履歴、および各バージョンで実行されたアクションが表示されます。 ## [](#設定の変更を適用する)設定の変更を適用する 1. アプリケーションの ​**\[Settings (設定)\]**​ ページで、デプロイされた設定に次の変更を加えることができます。 - 新しいアプリケーションパッケージをアップロードする。 - デプロイメント対象とリソース割り当てを変更する。 - **\[Ingress (イングレス)\]**​ および ​**\[Properties (プロパティ)\]**​ の値を変更する。 2. 変更したら、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 **\[Settings (設定)\]**​ ページの上部に、ステータスバーが表示されます。 !["Runtime Manager UI の Mule アプリケーションの \[Applying (適用中)](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/app-versioning-applying-config.png) 設定状況"\] 3. **\[View Status (状況を表示)\]**​ をクリックし、デプロイメントの各レプリカの状況を表示します。 \[Replica (レプリカ)\] の状況は次のとおりです。 - Started (開始済み): レプリカはトラフィックを受信中です。 - Pending (待機中): レプリカは開始を待機中です。 - Starting (開始中): レプリカは開始中です。 - Deleting (削除中): レプリカの削除が進行中です。 - Deleted (削除済み): レプリカは削除されました。 - Stopping (停止中): レプリカは停止中です。 - Stopped (停止済み): レプリカが停止しました (トラフィックを受信していません)。 - Failed (失敗): 設定のデプロイメントが失敗しました。 - Recovering (回復中): レプリカは終了後に再起動しようとしています。 最後に正常にデプロイされた設定は、新しい (目的の) 設定が正常にデプロイされるまで保持されます。 新しい設定は「ローリング更新」として適用されます。 次に例を示します。 - レプリカが目的の設定で作成されます。 - その設定が正常に適用されると、古い設定のレプリカは削除されます。 - このプロセスがデプロイメント内の各レプリカで繰り返されます。 このモデルは、更新がアプリケーションに適用されている間のダウンタイムがゼロであることを意味します。
更新はローリング更新として適用されるため、更新が完了するまで異なるバージョンのアプリケーションが同時に実行されることになります。そのため、アプリケーションが複数のバージョンを並行して実行できることを確認してください。
![Runtime Manager UI の Mule アプリケーションのレプリカの状況](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/app-versioning-replica-status.png) 設定が正常に適用されてデプロイされると、ページの上部にメッセージが表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定が正常に適用された状況](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/app-versioning-config-applied-success.png) 状況ボックスのアプリケーションの状況、設定識別子、日付、その他の情報が更新されます。 ​**\[Config changes (設定の変更)\]**​ リストの上部に、それが最後に正常にデプロイされた設定であることを示す ​**\[Last successful (最終成功)\]**​ 表示ラベルと共に新しい設定が表示されます。 設定への更新のデプロイが失敗した場合、\[​`Desired configuration wasn’t applied`​ (目的の設定は適用されませんでした)\] メッセージが表示され、​**\[Configuration (設定)\]**​ 状況に \[​`Update failed`​ (更新失敗)\] 表示ラベルが表示されます。​**\[Config changes (設定の変更)\]**​ 履歴には設定が表示ラベルなしで表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定を適用できなかった状況](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/app-versioning-update-failed.png) 失敗した場合、デプロイメントは最後に成功したバージョンの設定にロールバックしようとしますが、特定の状況ではロールバックが成功しないことがあります。その設定の状況は \[​`Update failed`​ (更新失敗)\] と表示されます。 それがアプリケーションの最初のデプロイメントである場合、ロールバックバージョンは定義されず、失敗したデプロイメントは失敗状況のままになります。 ## [](#以前に成功した設定にロールバックする)以前に成功した設定にロールバックする 問題がある設定をデプロイした場合、以前に成功したバージョンの設定にロールバックできます。 1. **\[Config changes (設定の変更)\]**​ 履歴で、ロールバックするバージョンを選択します。 2. **\[Deploy (デプロイ)\]**​ をクリックします。 設定が ​**\[Config changes (設定の変更)\]**​ 履歴のリストの一番上に移動し、新しいデプロイメント日が表示されます。その元の識別ハッシュが保持されます。 # Runtime Fabric でのアプリケーションのバージョン管理の確認 アプリケーションが Runtime Fabric にデプロイされると、Runtime Manager は自動的にアプリケーションとその設定をバージョン管理します。アプリケーションのバージョン管理により、次のことができます。 - アプリケーションの設定変更履歴を表示する。 - 現在適用されている設定に問題がある場合や不安定な場合に、設定を以前のバージョンにロールバックする。 - アプリケーションの状況を表示する。可能な値: - Running (実行中): 少なくとも 1 つのレプリカがトラフィックを受信中 (開始状態) です。 - Not running (停止中): どのレプリカもトラフィックを受信していません。 - Unknown (不明): 対象が切断されています。 - 次のようなデプロイされたアプリケーションの設定を更新する。 - アプリケーションのパッケージ。 - アプリケーションデプロイメントのパッケージバージョン。 - ランタイムバージョン、レプリカ数、アプリケーションがクラスターモードで実行されているかどうかなどのデプロイメント対象設定。 - リソース割り当て (コア数とメモリ割り当てを含む)。 - イングレスおよびプロパティ値。 ## [](#アプリケーションの設定ページにアクセスする)アプリケーションの設定ページにアクセスする 1. Anypoint Platform にサインインし、​**\[Runtime Manager\]**​ に移動します。 **\[Applications (アプリケーション)\]**​ ページが表示されます。 2. **\[Applications (アプリケーション)\]**​ ページから、Runtime Fabric にデプロイするアプリケーションを選択します。 3. 右側で管理パネルを開きます。 4. 管理パネルで、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 **\[Settings (設定)\]**​ ページに、アプリケーションの状況に関する情報、設定履歴、およびアプリケーションに関するその他の役立つ情報が表示されます。 アプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Config changes (設定の変更)\]**​ タブに、正常にデプロイされたアプリケーション設定に対する各変更が表示されます。 最後の 10 個の設定デプロイメントがそれぞれの設定日順に表示されます。履歴内の各設定には、それを識別する一意のハッシュがあります。 ![アプリケーションファイル、バージョン、デプロイメント対象、ランタイムバージョン、レプリカが表示されている Runtime Fabric アプリケーションの設定ページ](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/app-versioning.png)
設定履歴には、作成日順に最新の 10 件の設定デプロイメントが表示されます。
**\[All changes (すべての変更)\]**​ タブには、設定デプロイメントから作成されたバージョンの履歴、および各バージョンで実行されたアクションが表示されます。 ## [](#設定の変更を適用する)設定の変更を適用する 1. アプリケーションの ​**\[Settings (設定)\]**​ ページで、デプロイされた設定に次の変更を加えることができます。 - 新しいアプリケーションパッケージをアップロードする。 - デプロイメント対象とリソース割り当てを変更する。 - **\[Ingress (イングレス)\]**​ および ​**\[Properties (プロパティ)\]**​ の値を変更する。 2. 変更したら、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 **\[Settings (設定)\]**​ ページの上部に、ステータスバーが表示されます。 !["Runtime Manager UI の Mule アプリケーションの \[Applying (適用中)](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/app-versioning-applying-config.png) 設定状況"\] 3. **\[View Status (状況を表示)\]**​ をクリックし、デプロイメントの各レプリカの状況を表示します。 \[Replica (レプリカ)\] の状況は次のとおりです。 - Started (開始済み): レプリカはトラフィックを受信中です。 - Pending (保留中): レプリカは開始を待機中です。 - Starting (開始中): レプリカは開始中です。 - Deleting (削除中): レプリカの削除が進行中です。 - Deleted (削除済み): レプリカは削除されました。 - Stopping (停止中): レプリカは停止中です。 - Stopped (停止済み): レプリカが停止しました (トラフィックを受信していません)。 - Failed (失敗): 設定のデプロイメントが失敗しました。 - Recovering (回復中): レプリカは終了後に再起動しようとしています。 最後に正常にデプロイされた設定は、新しい (目的の) 設定が正常にデプロイされるまで保持されます。 新しい設定は「ローリング更新」として適用されます。 例: - レプリカが目的の設定で作成されます。 - その設定が正常に適用されると、古い設定のレプリカは削除されます。 - このプロセスがデプロイメント内の各レプリカで繰り返されます。 このモデルは、更新がアプリケーションに適用されている間のダウンタイムがゼロであることを意味します。
更新はローリング更新として適用されるため、更新が完了するまで異なるバージョンのアプリケーションが同時に実行されることになります。そのため、アプリケーションが複数のバージョンを並行して実行できることを確認してください。
![Runtime Manager UI の Mule アプリケーションのレプリカの状況](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/app-versioning-replica-status.png) 設定が正常に適用されてデプロイされると、ページの上部にメッセージが表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定が正常に適用された状況](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/app-versioning-config-applied-success.png) 状況ボックスのアプリケーションの状況、設定識別子、日付、その他の情報が更新されます。 ​**\[Config changes (設定の変更)\]**​ リストの上部に、それが最後に正常にデプロイされた設定であることを示す ​**\[Last successful (最終成功)\]**​ 表示ラベルと共に新しい設定が表示されます。 設定への更新のデプロイが失敗した場合、\[​`Desired configuration wasn’t applied`​ (目的の設定は適用されませんでした)\] メッセージが表示され、​**\[Configuration (設定)\]**​ 状況に \[​`Update failed`​ (更新失敗)\] 表示ラベルが表示されます。​**\[Config changes (設定の変更)\]**​ 履歴には設定が表示ラベルなしで表示されます。 ![Runtime Manager UI の Mule アプリケーションの設定を適用できなかった状況](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/app-versioning-update-failed.png) 失敗した場合、デプロイメントは最後に成功したバージョンの設定にロールバックしようとしますが、特定の状況ではロールバックが成功しないことがあります。その設定の状況は \[​`Update failed`​ (更新失敗)\] と表示されます。 それがアプリケーションの最初のデプロイメントである場合、ロールバックバージョンは定義されず、失敗したデプロイメントは失敗状況のままになります。 ## [](#以前に成功した設定にロールバックする)以前に成功した設定にロールバックする 問題がある設定をデプロイした場合、以前に成功したバージョンの設定にロールバックできます。 1. **\[Config changes (設定の変更)\]**​ 履歴で、ロールバックするバージョンを選択します。 2. **\[Deploy (デプロイ)\]**​ をクリックします。 設定が ​**\[Config changes (設定の変更)\]**​ 履歴のリストの一番上に移動し、新しいデプロイメント日が表示されます。その元の識別ハッシュが保持されます。 # Runtime Fabric でのアプリケーションのプロパティ値の保護 Runtime Fabric を使用すると、Anypoint Runtime Manager でプロパティ名を表示してその値は表示しないことで、アプリケーションのプロパティ値を保護できます。 さらに、保護された値はどのユーザーも表示または取得できません。Runtime Fabric は、実行時にプロパティを内部的に解決します。これらの保護されたアプリケーション値は暗号化され、Anypoint Security シークレットマネージャーに保存されます。その後、ユーザー組織ごとに暗号化されます。 保護されたプロパティ値は、セキュアな設定ファイルに保存される暗号化された Mule アプリケーションのプロパティとは別のものです。​[「セキュア設定プロパティ」](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties)​を参照してください。

Runtime Manager では、API プロキシまたはゲートウェイの保護されたプロパティの追加はサポートされません。代わりに、API Manager を使用してください。

現在、Runtime Fabric では、API または Anypoint Runtime Manager UI を使用して、API Gateway のクライアント ID とシークレット ID を保護できます。
## [](#runtime-manager-でプロパティ値を保護する)Runtime Manager でプロパティ値を保護する テーブルビューを介して保護されたプロパティを設定し、各プロパティと値を詳細に制御します。 1 つのプロパティを複数回保護しようとすることはできますが、Runtime Manager によって警告が発行され、そのプロパティの最後のインスタンスのみが保護されます。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. 左側のメニューから ​**\[Applications (アプリケーション)\]**​ をクリックします。 3. アプリケーション名をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. 一度に保護するプロパティの数に応じて、次のいずれかのアクションを実行します。 - プロパティを 1 つずつ保護するには、​**\[Table view (テーブルビュー)\]**​ をクリックします。 - 複数のプロパティを保護するには、​**\[Text view (テキストビュー)\]**​ を使用してキー-値ペアを追加し、​**\[Table view (テーブルビュー)\]**​ に切り替えてから、ステップ 8 に進みます。 6. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 7. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 ![テーブルビューでのプロパティの追加](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-add-protected-properties.png) 8. **\[Protect (保護)\]**​ > ​**\[Protect value (値を保護)\]**​ をクリックして確認します。 9. 次のいずれかを選択します。 - このアプリケーションがすでにデプロイされている場合、​**\[Apply changes (変更を適用)\]**​ をクリックします。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Properties (プロパティ)\]**​ タブで、ここで保護したプロパティの値は自分にも他のユーザーにも表示されなくなります。 次の例では、​`dbPassword`​ の値は保護されますが、​`dbUsername`​ と ​`environment`​ の値は保護されません。 ![dbpassword の値が保護と表示](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-view-protected-properties.png) 値をコミットし、アプリケーションをデプロイしたら、保護されたプロパティの値はコンソールに表示されなくなります。また、コンソールと Runtime Manager の間で送受信されることもありません。 ## [](#保護されたプロパティ値を置き換える)保護されたプロパティ値を置き換える プロパティ値を保護した後は、その値は取得できません。ただし、保護されたプロパティ値を新しい保護された値に置き換えることができます。 1. テーブルビューで、置き換える保護された値の横にあるアイコンをクリックします。 2. 値の横にあるメニューアイコンをクリックし、​**\[Replace protected value (保護された値を置換)\]**​ をクリックします。 3. 項目に新しい値を入力します。 4. **\[Apply (適用)\]**​ > ​**\[Apply changes (変更を適用)\]**​ をクリックします。 # Runtime Fabric でのアラートの設定 VM/ベアメタルの Runtime Fabric では、既存の SMTP サーバーを介してアラートを送信できます。VM/ベアメタルの Runtime Fabric には、システムの健全性が低下したときに通知を送信するアラート機能があります。 ## [](#組み込みアラート)組み込みアラート 次の表では、VM/ベアメタルの Anypoint Runtime Fabric によって提供されるデフォルトのアラートを示しています。
アラート 説明

docker

Docker デーモンがダウンしたときにエラーを送信します。

etcd

etcd リーダーが 5 分以上アクセスできない場合または etcd クラスターがダウンしている場合にエラーを送信します。

etcd_latency_batch

フォロワーとリーダーのレイテンシーが 500 ミリ秒を超えたときに警告を送信し、1 分間で 1 秒を超えたときにエラーをトリガーします。

filesystem

容量の使用量が 80% に達したときに警告を送信します。使用量が 90% を超えたときに重大なエラーをトリガーします。inode 容量の使用量が 90% に達したときに警告を送信します。使用量が 95% を超えたときに重大なエラーをトリガーします。

high-cpu

容量の使用量が 75% に達したときに警告を送信します。使用量が 90% を超えたときに重大なエラーをトリガーします。

high_memory

メモリの使用量が 80% に達したときに警告を送信します。使用量が 90% を超えたときに重大なエラーをトリガーします。

influxdb_health_batch

InfluxDB がダウンしたか Kapacitor と InfluxDB の間に接続がないときにエラーをトリガーします。

ingress

ポッドの CPU 容量の使用量が 80% を超えたときに重大なエラーをトリガーします。ポッドのメモリ容量の使用量が 80% を超えたときに重大なエラーをトリガーします。

kubernetes_node

ノードが 5 分以上準備完了と報告されていないときに警告を送信します。

muleapps

CPU の使用量が 90% を超えたときに重大なエラーをトリガーします。ポッドのメモリの使用量が 90% を超えたときに重大なエラーをトリガーします。

network_params

ノードでネットワーキングが無効になっているときに重大なエラーをトリガーします。

uptime

システムが 5 分以上アクセスできないときにエラーを送信します。
## [](#アラートの設定)アラートの設定 SMTP サーバー経由で指定されたアラート送信者メールアドレスから Runtime Fabric アラートを送信できます。アラートにつき設定できるメール受信者は 1 人のみです。 1. `rtfctl`​ をインストールします。 Runtime Fabric のアラート送信者メールを管理するには、​`rtfctl`​ ユーティリティが必要です。次の手順を実行する前に、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​の手順を実行します。 2. ターミナルを使用して、コントローラー VM へのシェル/SSH 接続を開きます。 3. 次の内容が含まれる ​`alert-smtp.yaml`​ という名前のファイルを作成します。 kind: smtp version: v2 metadata: name: smtp spec: host: port: username: password: --- kind: alerttarget version: v2 metadata: name: email-alerts spec: email: 4. 環境に固有の次の値を使用して、​`alert-smtp.yaml`​ のコンテンツを変更します。
Table 1. 環境変数
キー 説明

<smtp host>

SMTP サーバーのエンドポイント。

<smtp port>

SMTP サーバーに接続するために使用されるポート。(デフォルトは 465)。

<username>

SMTP サーバーに接続するときに使用するユーザー名。

<password>

SMTP サーバーに接続するときに使用するパスワード。

<email>

受信者のメールアドレス。
5. コントローラー VM で次のコマンドを実行します。 $ sudo gravity resource create -f alert-smtp.yaml 6. `rtfctl`​ ユーティリティを使用して、SMTP ドメインが含まれるアラート送信者メールアドレスを設定します。アラートをトリガーするクラスターを識別するには、各クラスターに区別しやすいメールアドレスを使用します。 $ sudo ./rtfctl appliance apply alert-smtp-from "sender@example.com" ## [](#メールアラートのコンテンツを変更する)メールアラートのコンテンツを変更する 必要に応じて、Runtime Fabric から送信されるメールアラートのコンテンツを変更できます。アラートは TICKscript で記述されます。

いずれかの Runtime Fabric メールアラートをカスタマイズした場合、アプライアンスのアップグレードにより、カスタマイズが上書きされます。
1. Ops Center に移動します。 2. Ops Center メニューから ​**\[Configuration (設定)\]**​ をクリックします。 3. **\[Config maps (設定マップ)\]**​ ドロップダウンメニューから ​**\[kapacitor-alerts\]**​ を選択します。 4. **\[Namespace (名前空間)\]**​ ドロップダウンメニューから ​**\[monitoring\]**​ を選択します。 5. 目的のアラートを選択して変更を行います。 6. 完了したら、​**\[Apply (適用)\]**​ をクリックします。 7. SSH または Ops Center を使用していずれかのコントローラーノードにログインします。 8. kapacitor ポッド名を取得します。 kubectl -n monitoring get pod -l component=kapacitor 名前は ​`kapacitor-xxxxxxxxxx-xxxx`​ のようになります。 9. 設定済みアラートのリストを取得します。 kubectl -n monitoring exec -c alert-loader -- kapacitor -url http://localhost:9092 list tasks 10. 変更したアラートを削除します。 kubectl -n monitoring exec -c alert-loader -- kapacitor -url http://localhost:9092 delete tasks 11. アラートが再作成され、\[Status (状況)\] の値が ​`enabled`​、\[Executing (実行中)\] の値が ​`true`​ であることを確認します。 kubectl -n monitoring exec -c alert-loader -- kapacitor -url http://localhost:9092 list tasks 結果にアラートのリストが表示されます。 ID Type Status Executing Databases and Retention Policies stream enabled true \["k8s"."default"\] ... 12. 新しいアラートのコンテンツを確認します。 kubectl -n monitoring exec kapacitor-85c9d79c9b-ttkdn -c alert-loader -- kapacitor -url http://localhost:9092 show 結果は次のようになります。 ID: Error: Template: Type: stream Status: enabled Executing: true ... ## [](#関連情報)関連情報 - [Anypoint Runtime Fabric でのログ転送の設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) - [rtfctl のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl) # Runtime Fabric でのプロキシの管理 Runtime Fabric は、アプリケーションを実行およびホストするときに 2 種類のプロキシを使用します。 - システムプロキシ: Docker デーモンやその他の内部コンポーネントを含む、Kubernetes クラスターサービス間の接続を可能にするプロキシが含まれます。Runtime Fabric を使用する場合は、システムプロキシを設定および管理する必要があります。 - アプリケーションプロキシ: Runtime Fabric で実行されているアプリケーションへの接続を可能にするプロキシが含まれます。 インターネットへの Runtime Fabric アウトバウンド接続で使用するプロキシ設定を設定できます。これには、Anypoint コントロールプレーンに接続するための HTTP プロキシと、メトリクスとログを Anypoint Monitoring に送信するための SOCKS5 プロキシの両方が含まれます。アプリケーションのプロキシを設定することもできます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のプロキシ設定を管理するには、​`rtfctl`​ コマンドラインツールが必要です。プロキシ設定を行う前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​する手順を実行します。

Helm を使用してインストールする場合は、Runtime Fabric のインストール中にプロキシ設定を適用できます。詳細は、​「Helm を使用した Runtime Fabric のインストール」​を参照してください。
## [](#anypoint-monitoring-プロキシを設定する)Anypoint Monitoring プロキシを設定する 監視エージェントは SOCKS5 プロキシを使用するため、Anypoint Monitoring を使用する場合は 2 つのプロキシ種別が必要です。 SOCKS5 プロキシは、次のエンドポイントで TCP 経由で Anypoint Monitoring に接続する必要があります。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****​: SOCKS5 プロキシの認証に必要なユーザー名。 - ****​: SOCKS5 プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.2>**​: SOCKS5 プロキシへのアクセスに使用される IP アドレスまたはホスト名。 - **<8080>**​: SOCKS5 プロキシが要求をリスンするホストのポート。 1. 変更が成功したことを確認するには、次のコマンドを実行して、監視プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` 出力は期待される値と一致する必要があります。 ## [](#runtime-fabric-のサービス用に-http-プロキシを設定する)Runtime Fabric のサービス用に HTTP プロキシを設定する アウトバウンドコンポーネントがコントロールプレーンと通信できるように HTTP プロキシと HTTPS プロキシを設定できます。 HTTP プロキシを更新すると、クラスター内の各マシンは、マシンで実行されているすべてのポッドを再起動します。複数のレプリカを実行している場合、ダウンタイムは発生しませんが、メンテナンスウィンドウ中に HTTP プロキシの更新を実行する必要があります。 - Runtime Fabric 内で実行されているサービスにプロキシの値を適用する。 - Runtime Fabric インストーラー 1.0.x を使用している場合は、Runtime Fabric の各ノードでスクリプトを実行してクラスターを更新する。 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****​: HTTP プロキシの認証に必要なユーザー名。 - ****​: HTTP プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.1>**​: HTTP プロキシにアクセスするための IP アドレスまたはホスト名を指定します。 - **<8080>**​: HTTP プロキシが要求をリスンするホストのポートを指定します。 - **<1.1.1.1:8888,2.2.2.2:9999>**​: カンマで区切られた ​`RTF_NO_PROXY`​ ホストとポートを指定します。 - (省略可能) ​`--confirm`​: 変更の手動の肯定応答をスキップします。指定しなかった場合、​`rtfctl apply proxy`​ コマンドでは、続行する前に変更を確認することが求められます。 1. 変更が成功したことを確認するには、次のコマンドを実行して、HTTP プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシ値を削除するには、次のコマンドを実行します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` ### [](#http_proxy-環境変数について)HTTP\_PROXY​ 環境変数について Runtime Fabric のサービスにプロキシを適用したら、次のような警告が表示される場合があります。 Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric で [この警告](https://help.mulesoft.com/s/article/Warning-Proxy-configurations-in-the-environment-HTTP-PROXY-does-not-match-configurations-in-Runtime-Fabric)​が生成されるのは、​`HTTP_PROXY`​ 環境変数を設定していないこと、または変数が Runtime Fabric サービスに使用される値と一致しないことを知らせるためです。これらの設定は必ずしも一致している必要はありませんが、Runtime Fabric ではサービスが影響を受ける可能性もあることを知らせるために警告が生成されます。 多くの Linux ツールでは ​`HTTP_PROXY`​ 環境変数を使用してそのプロキシ設定を提供しています。環境にインターネットアクセス用のプロキシが必要な場合、インターネットアクセスが必要なコマンド用に ​`HTTP_PROXY`​ 環境変数を設定する必要がある可能性が高くなります。 これにより、​`kubectl`​ のように HTTP または HTTPS 操作を使用するがインターネットアクセスが不要な他のツールに影響する可能性もあります。​`NO_PROXY`​ 環境変数を使用して、プロキシする必要がない接続を確立できます。 環境変数によるそのプロキシの動作に対する影響に関する詳細は、Linux ツールのドキュメントを参照してください。 ### [](#no_proxy-環境変数について)NO\_PROXY​ 環境変数について デフォルトでは、​`NO_PROXY`​ は ​`0.0.0.0/0`​ と ​`.local`​ に設定されます。これらの設定により、プロキシで IPV4 宛先アドレスが転送されなくなります。 ## [](#api-manager-エージェントのプロキシを設定する)API Manager エージェントのプロキシを設定する プロキシを使用して、API Manager で管理する Mule アプリケーション用の通信を確立できます。すべてのアプリケーションに同じ設定を使用している場合でも、このプロキシ設定は各 Mule アプリケーションで定義する必要があります。この設定はアプリケーションが他の外部エンドポイントと通信するために使用するアプリケーションレベルのプロキシとは無関係です。 API Manager エージェントのプロキシを設定するには、次のプロパティをアプリケーションに追加します。 anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## [](#mule-アプリケーション用のプロキシの設定)Mule アプリケーション用のプロキシの設定 Runtime Fabric でデプロイされるアプリケーションは、Runtime Fabric クラスターからプロキシ設定を継承します。各アプリケーションでプロキシを設定することもできます。 各コネクタ (HTTP リクエスターなど) でプロキシを設定するか、または次の例に示すようにアプリケーションのプロパティでプロキシを設定することができます。アプリケーションで多くのコネクタを使用する場合は、アプリケーションのプロパティでプロキシを設定した方が楽です。 http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true # Runtime Fabric でのプロキシの設定 Anypoint Runtime Fabric は、アプリケーションを実行およびホストするときに 2 種類のプロキシを使用します。 - システムプロキシ: Docker デーモンやその他の内部コンポーネントを含む、Kubernetes クラスターサービス間の接続を可能にするプロキシが含まれます。Runtime Fabric を使用する場合は、システムプロキシを設定および管理する必要があります。 - アプリケーションプロキシ: Runtime Fabric で実行されているアプリケーションへの接続を可能にするプロキシが含まれます。 インターネットへの Runtime Fabric アウトバウンド接続で使用するプロキシ設定を設定できます。これには、Anypoint コントロールプレーンに接続するための HTTP プロキシと、メトリクスとログを Anypoint Monitoring に送信するための SOCKS5 プロキシの両方が含まれます。アプリケーションのプロキシを設定することもできます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のプロキシ設定を管理するには、​`rtfctl`​ コマンドラインツールが必要です。プロキシ設定を行う前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl)​する手順を実行します。

Helm を使用してインストールする場合は、Runtime Fabric のインストール中にプロキシ設定を適用できます。詳細は、​「Helm を使用した Runtime Fabric のインストール」​を参照してください。
## [](#anypoint-monitoring-プロキシを設定する)Anypoint Monitoring プロキシを設定する 監視エージェントは SOCKS5 プロキシを使用するため、Anypoint Monitoring を使用する場合は 2 つのプロキシ種別が必要です。
Runtime Fabric バージョン 2.6.22 以降、Anypoint Monitoring サイドカーまたはエージェントにも次の HTTP プロキシが必要です。SOCK5 プロキシは、バージョン 2.6.22 以降の Runtime Fabric にデプロイされた Mule アプリケーションには必要ありません。
SOCKS5 プロキシは、次のエンドポイントで TCP 経由で Anypoint Monitoring に接続する必要があります。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****​: SOCKS5 プロキシの認証に必要なユーザー名。 - ****​: SOCKS5 プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.2>**​: SOCKS5 プロキシへのアクセスに使用される IP アドレスまたはホスト名。 - **<8080>**​: SOCKS5 プロキシが要求をリスンするホストのポート。 1. 変更が成功したことを確認するには、次のコマンドを実行して、監視プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシをセットアップした後に、​`rtfctl validate`​ コマンドを実行してセットアップを検証します。​[「rtfctl Validate」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#validate)​ドキュメントを参照してください。 ## [](#runtime-fabric-のサービス用に-http-プロキシを設定する)Runtime Fabric のサービス用に HTTP プロキシを設定する アウトバウンドコンポーネントがコントロールプレーンと通信できるように HTTP プロキシを設定できます。
Runtime Fabric バージョン 2.6.22 以降、Anypoint Monitoring サイドカーまたはエージェントにも次の HTTP プロキシが必要です。SOCK5 プロキシは、バージョン 2.6.22 以降の Runtime Fabric にデプロイされた Mule アプリケーションには必要ありません。
HTTP プロキシを更新すると、クラスター内の各マシンは、マシンで実行されているすべてのポッドを再起動します。複数のレプリカを実行している場合、ダウンタイムは発生しませんが、メンテナンスウィンドウ中に HTTP プロキシの更新を実行する必要があります。 - Runtime Fabric 内で実行されているサービスにプロキシの値を適用する。 - Runtime Fabric インストーラー 1.0.x を使用している場合は、Runtime Fabric の各ノードでスクリプトを実行してクラスターを更新する。 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****​: HTTP プロキシの認証に必要なユーザー名。 - ****​: HTTP プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.1>**​: HTTP プロキシにアクセスするための IP アドレスまたはホスト名を指定します。 - **<8080>**​: HTTP プロキシが要求をリスンするホストのポートを指定します。 - **<1.1.1.1:8888,2.2.2.2:9999>**​: カンマで区切られた ​`RTF_NO_PROXY`​ ホストとポートを指定します。 - (省略可能) ​`--confirm`​: 変更の手動の肯定応答をスキップします。指定しなかった場合、​`rtfctl apply proxy`​ コマンドでは、続行する前に変更を確認することが求められます。 1. 変更が成功したことを確認するには、次のコマンドを実行して、HTTP プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシ値を削除するには、次のコマンドを実行します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. プロキシをセットアップした後に、​`rtfctl validate`​ コマンドを実行してセットアップを検証します。​[「rtfctl Validate」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#validate)​ドキュメントを参照してください。 ### [](#http_proxy-環境変数について)HTTP\_PROXY​ 環境変数について Runtime Fabric のサービスにプロキシを適用したら、次のような警告が表示される場合があります。 Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric で [この警告](https://help.mulesoft.com/s/article/Warning-Proxy-configurations-in-the-environment-HTTP-PROXY-does-not-match-configurations-in-Runtime-Fabric)​が生成されるのは、​`HTTP_PROXY`​ 環境変数を設定していないこと、または変数が Runtime Fabric サービスに使用される値と一致しないことを知らせるためです。これらの設定は必ずしも一致している必要はありませんが、Runtime Fabric ではサービスが影響を受ける可能性もあることを知らせるために警告が生成されます。 多くの Linux ツールでは ​`HTTP_PROXY`​ 環境変数を使用してそのプロキシ設定を提供しています。環境にインターネットアクセス用のプロキシが必要な場合、インターネットアクセスが必要なコマンド用に ​`HTTP_PROXY`​ 環境変数を設定する必要がある可能性が高くなります。 これにより、​`kubectl`​ のように HTTP または HTTPS 操作を使用するがインターネットアクセスが不要な他のツールに影響する可能性もあります。​`NO_PROXY`​ 環境変数を使用して、プロキシする必要がない接続を確立できます。 環境変数によるそのプロキシの動作に対する影響に関する詳細は、Linux ツールのドキュメントを参照してください。 ### [](#no_proxy-環境変数について)NO\_PROXY​ 環境変数について デフォルトでは、​`NO_PROXY`​ は ​`0.0.0.0/0`​ と ​`.local`​ に設定されます。これらの設定により、プロキシで IPV4 宛先アドレスが転送されなくなります。 ## [](#api-manager-エージェントのプロキシを設定する)API Manager エージェントのプロキシを設定する プロキシを使用して、API Manager で管理する Mule アプリケーション用の通信を確立できます。すべてのアプリケーションに同じ設定を使用している場合でも、このプロキシ設定は各 Mule アプリケーションで定義する必要があります。この設定はアプリケーションが他の外部エンドポイントと通信するために使用するアプリケーションレベルのプロキシとは無関係です。 API Manager エージェントのプロキシを設定するには、次のプロパティをアプリケーションに追加します。 anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## [](#mule-アプリケーション用のプロキシの設定)Mule アプリケーション用のプロキシの設定 Runtime Fabric でデプロイされるアプリケーションは、Runtime Fabric クラスターからプロキシ設定を継承します。各アプリケーションでプロキシを設定することもできます。 各コネクタ (HTTP リクエスターなど) でプロキシをセットアップするか、または次の例に示すようにアプリケーションのプロパティでプロキシをセットアップすることができます。アプリケーションで多くのコネクタを使用する場合は、アプリケーションのプロパティでプロキシを設定した方が楽です。 http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true # Runtime Fabric でのプロキシの設定 Anypoint Runtime Fabric は、アプリケーションを実行およびホストするときに 2 種類のプロキシを使用します。 - システムプロキシ: Docker デーモンやその他の内部コンポーネントを含む、Kubernetes クラスターサービス間の接続を可能にするプロキシが含まれます。Runtime Fabric を使用する場合は、システムプロキシを設定および管理する必要があります。 - アプリケーションプロキシ: Runtime Fabric で実行されているアプリケーションへの接続を可能にするプロキシが含まれます。 インターネットへの Runtime Fabric アウトバウンド接続で使用するプロキシ設定を設定できます。これには、Anypoint コントロールプレーンに接続するための HTTP プロキシと、メトリクスとログを Anypoint Monitoring に送信するための SOCKS5 プロキシの両方が含まれます。アプリケーションのプロキシを設定することもできます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のプロキシ設定を管理するには、​`rtfctl`​ コマンドラインツールが必要です。プロキシ設定を行う前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl)​する手順を実行します。

Helm を使用してインストールする場合は、Runtime Fabric のインストール中にプロキシ設定を適用できます。詳細は、​「Helm を使用した Runtime Fabric のインストール」​を参照してください。
## [](#anypoint-monitoring-プロキシを設定する)Anypoint Monitoring プロキシを設定する 監視エージェントは SOCKS5 プロキシを使用するため、Anypoint Monitoring を使用する場合は 2 つのプロキシ種別が必要です。
Runtime Fabric バージョン 2.6.22 以降、Anypoint Monitoring サイドカーまたはエージェントにも次の HTTP プロキシが必要です。SOCK5 プロキシは、バージョン 2.6.22 以降の Runtime Fabric にデプロイされた Mule アプリケーションには必要ありません。
SOCKS5 プロキシは、次のエンドポイントで TCP 経由で Anypoint Monitoring に接続する必要があります。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****​: SOCKS5 プロキシの認証に必要なユーザー名。 - ****​: SOCKS5 プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.2>**​: SOCKS5 プロキシへのアクセスに使用される IP アドレスまたはホスト名。 - **<8080>**​: SOCKS5 プロキシが要求をリスンするホストのポート。 1. 変更が成功したことを確認するには、次のコマンドを実行して、監視プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシをセットアップした後に、​`rtfctl validate`​ コマンドを実行してセットアップを検証します。​[「rtfctl Validate」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#validate)​ドキュメントを参照してください。 ## [](#runtime-fabric-のサービス用に-http-プロキシを設定する)Runtime Fabric のサービス用に HTTP プロキシを設定する アウトバウンドコンポーネントがコントロールプレーンと通信できるように HTTP プロキシを設定できます。
Runtime Fabric バージョン 2.6.22 以降、Anypoint Monitoring サイドカーまたはエージェントにも次の HTTP プロキシが必要です。SOCK5 プロキシは、バージョン 2.6.22 以降の Runtime Fabric にデプロイされた Mule アプリケーションには必要ありません。
HTTP プロキシを更新すると、クラスター内の各マシンは、マシンで実行されているすべてのポッドを再起動します。複数のレプリカを実行している場合、ダウンタイムは発生しませんが、メンテナンスウィンドウ中に HTTP プロキシの更新を実行する必要があります。 - Runtime Fabric 内で実行されているサービスにプロキシの値を適用する。 - Runtime Fabric インストーラー 1.0.x を使用している場合は、Runtime Fabric の各ノードでスクリプトを実行してクラスターを更新する。 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****​: HTTP プロキシの認証に必要なユーザー名。 - ****​: HTTP プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.1>**​: HTTP プロキシにアクセスするための IP アドレスまたはホスト名を指定します。 - **<8080>**​: HTTP プロキシが要求をリスンするホストのポートを指定します。 - **<1.1.1.1:8888,2.2.2.2:9999>**​: カンマで区切られた ​`RTF_NO_PROXY`​ ホストとポートを指定します。 - (省略可能) ​`--confirm`​: 変更の手動の肯定応答をスキップします。指定しなかった場合、​`rtfctl apply proxy`​ コマンドでは、続行する前に変更を確認することが求められます。 1. 変更が成功したことを確認するには、次のコマンドを実行して、HTTP プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシ値を削除するには、次のコマンドを実行します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. プロキシをセットアップした後に、​`rtfctl validate`​ コマンドを実行してセットアップを検証します。​[「rtfctl Validate」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#validate)​ドキュメントを参照してください。 ### [](#http_proxy-環境変数について)HTTP\_PROXY​ 環境変数について Runtime Fabric のサービスにプロキシを適用したら、次のような警告が表示される場合があります。 Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric で [この警告](https://help.mulesoft.com/s/article/Warning-Proxy-configurations-in-the-environment-HTTP-PROXY-does-not-match-configurations-in-Runtime-Fabric)​が生成されるのは、​`HTTP_PROXY`​ 環境変数を設定していないこと、または変数が Runtime Fabric サービスに使用される値と一致しないことを知らせるためです。これらの設定は必ずしも一致している必要はありませんが、Runtime Fabric ではサービスが影響を受ける可能性もあることを知らせるために警告が生成されます。 多くの Linux ツールでは ​`HTTP_PROXY`​ 環境変数を使用してそのプロキシ設定を提供しています。環境にインターネットアクセス用のプロキシが必要な場合、インターネットアクセスが必要なコマンド用に ​`HTTP_PROXY`​ 環境変数を設定する必要がある可能性が高くなります。 これにより、​`kubectl`​ のように HTTP または HTTPS 操作を使用するがインターネットアクセスが不要な他のツールに影響する可能性もあります。​`NO_PROXY`​ 環境変数を使用して、プロキシする必要がない接続を確立できます。 環境変数によるそのプロキシの動作に対する影響に関する詳細は、Linux ツールのドキュメントを参照してください。 ### [](#no_proxy-環境変数について)NO\_PROXY​ 環境変数について デフォルトでは、​`NO_PROXY`​ は ​`0.0.0.0/0`​ と ​`.local`​ に設定されます。これらの設定により、プロキシで IPV4 宛先アドレスが転送されなくなります。 ## [](#api-manager-エージェントのプロキシを設定する)API Manager エージェントのプロキシを設定する プロキシを使用して、API Manager で管理する Mule アプリケーション用の通信を確立できます。すべてのアプリケーションに同じ設定を使用している場合でも、このプロキシ設定は各 Mule アプリケーションで定義する必要があります。この設定はアプリケーションが他の外部エンドポイントと通信するために使用するアプリケーションレベルのプロキシとは無関係です。 API Manager エージェントのプロキシを設定するには、次のプロパティをアプリケーションに追加します。 anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## [](#mule-アプリケーション用のプロキシの設定)Mule アプリケーション用のプロキシの設定 Runtime Fabric でデプロイされるアプリケーションは、Runtime Fabric クラスターからプロキシ設定を継承します。各アプリケーションでプロキシを設定することもできます。 各コネクタ (HTTP リクエスターなど) でプロキシをセットアップするか、または次の例に示すようにアプリケーションのプロパティでプロキシをセットアップすることができます。アプリケーションで多くのコネクタを使用する場合は、アプリケーションのプロパティでプロキシを設定した方が楽です。 http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true # Runtime Fabric でのプロキシの設定 Anypoint Runtime Fabric は、アプリケーションを実行およびホストするときに 2 種類のプロキシを使用します。 - システムプロキシ: Docker デーモンやその他の内部コンポーネントを含む、Kubernetes クラスターサービス間の接続を可能にするプロキシが含まれます。Runtime Fabric を使用する場合は、システムプロキシを設定および管理する必要があります。 - アプリケーションプロキシ: Runtime Fabric で実行されているアプリケーションへの接続を可能にするプロキシが含まれます。 インターネットへの Runtime Fabric アウトバウンド接続で使用するプロキシ設定を設定できます。これには、Anypoint コントロールプレーンに接続するための HTTP プロキシと、メトリクスとログを Anypoint Monitoring に送信するための SOCKS5 プロキシの両方が含まれます。アプリケーションのプロキシを設定することもできます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のプロキシ設定を管理するには、​`rtfctl`​ コマンドラインツールが必要です。プロキシ設定を行う前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl)​する手順を実行します。

Helm を使用してインストールする場合は、Runtime Fabric のインストール中にプロキシ設定を適用できます。詳細は、​「Helm を使用した Runtime Fabric のインストール」​を参照してください。
## [](#anypoint-monitoring-プロキシを設定する)Anypoint Monitoring プロキシを設定する 監視エージェントは SOCKS5 プロキシを使用するため、Anypoint Monitoring を使用する場合は 2 つのプロキシ種別が必要です。
Runtime Fabric バージョン 2.6.22 以降、Anypoint Monitoring サイドカーまたはエージェントにも次の HTTP プロキシが必要です。SOCK5 プロキシは、バージョン 2.6.22 以降の Runtime Fabric にデプロイされた Mule アプリケーションには必要ありません。
SOCKS5 プロキシは、次のエンドポイントで TCP 経由で Anypoint Monitoring に接続する必要があります。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` `us1.ingest.mulesoft.com` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io` `eu1.ingest.mulesoft.com` 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" ``` - ****​: SOCKS5 プロキシの認証に必要なユーザー名。 - ****​: SOCKS5 プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.2>**​: SOCKS5 プロキシへのアクセスに使用される IP アドレスまたはホスト名。 - **<8080>**​: SOCKS5 プロキシが要求をリスンするホストのポート。 1. 変更が成功したことを確認するには、次のコマンドを実行して、監視プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシをセットアップした後に、​`rtfctl validate`​ コマンドを実行してセットアップを検証します。​[「rtfctl Validate」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#validate)​ドキュメントを参照してください。 ## [](#runtime-fabric-のサービス用に-http-プロキシを設定する)Runtime Fabric のサービス用に HTTP プロキシを設定する アウトバウンドコンポーネントがコントロールプレーンと通信できるように HTTP プロキシを設定できます。
Runtime Fabric バージョン 2.6.22 以降、Anypoint Monitoring サイドカーまたはエージェントにも次の HTTP プロキシが必要です。SOCK5 プロキシは、バージョン 2.6.22 以降の Runtime Fabric にデプロイされた Mule アプリケーションには必要ありません。
`rtf-agent`​ ポッドと、プロキシを必要とする Mule アプリケーションを再起動する必要があります。複数のレプリカを実行している場合、ダウンタイムは発生しませんが、メンテナンスウィンドウ中に HTTP プロキシの更新を実行する必要があります。 - Runtime Fabric 内で実行されているサービスにプロキシの値を適用する。 - Runtime Fabric インストーラー 1.0.x を使用している場合は、Runtime Fabric の各ノードでスクリプトを実行してクラスターを更新する。 1. `rtfctl`​ がインストールされているノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" ``` - ****​: HTTP プロキシの認証に必要なユーザー名。 - ****​: HTTP プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.1>**​: HTTP プロキシにアクセスするための IP アドレスまたはホスト名を指定します。 - **<8080>**​: HTTP プロキシが要求をリスンするホストのポートを指定します。 - **<1.1.1.1:8888,2.2.2.2:9999>**​: カンマで区切られた ​`RTF_NO_PROXY`​ ホストとポートを指定します。 - (省略可能) ​`--confirm`​: 変更の手動の肯定応答をスキップします。指定しなかった場合、​`rtfctl apply proxy`​ コマンドでは、続行する前に変更を確認することが求められます。 1. 変更が成功したことを確認するには、次のコマンドを実行して、HTTP プロキシの現在の値を出力します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl get http-proxy ``` 出力は期待される値と一致する必要があります。 2. プロキシ値を削除するには、次のコマンドを実行します。 ```copy sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ``` 3. プロキシをセットアップした後に、​`rtfctl validate`​ コマンドを実行してセットアップを検証します。​[「rtfctl Validate」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#validate)​ドキュメントを参照してください。 ### [](#http_proxy-環境変数について)HTTP\_PROXY​ 環境変数について Runtime Fabric のサービスにプロキシを適用したら、次のような警告が表示される場合があります。 Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric で [この警告](https://help.mulesoft.com/s/article/Warning-Proxy-configurations-in-the-environment-HTTP-PROXY-does-not-match-configurations-in-Runtime-Fabric)​が生成されるのは、​`HTTP_PROXY`​ 環境変数を設定していないこと、または変数が Runtime Fabric サービスに使用される値と一致しないことを知らせるためです。これらの設定は必ずしも一致している必要はありませんが、Runtime Fabric ではサービスが影響を受ける可能性もあることを知らせるために警告が生成されます。 多くの Linux ツールでは ​`HTTP_PROXY`​ 環境変数を使用してそのプロキシ設定を提供しています。環境にインターネットアクセス用のプロキシが必要な場合、インターネットアクセスが必要なコマンド用に ​`HTTP_PROXY`​ 環境変数を設定する必要がある可能性が高くなります。 これにより、​`kubectl`​ のように HTTP または HTTPS 操作を使用するがインターネットアクセスが不要な他のツールに影響する可能性もあります。​`NO_PROXY`​ 環境変数を使用して、プロキシする必要がない接続を確立できます。 環境変数によるそのプロキシの動作に対する影響に関する詳細は、Linux ツールのドキュメントを参照してください。 ### [](#no_proxy-環境変数について)NO\_PROXY​ 環境変数について デフォルトでは、​`NO_PROXY`​ は ​`0.0.0.0/0`​ と ​`.local`​ に設定されます。これらの設定により、プロキシで IPV4 宛先アドレスが転送されなくなります。 ## [](#api-manager-エージェントのプロキシを設定する)API Manager エージェントのプロキシを設定する プロキシを使用して、API Manager で管理する Mule アプリケーション用の通信を確立できます。すべてのアプリケーションに同じ設定を使用している場合でも、このプロキシ設定は各 Mule アプリケーションで定義する必要があります。この設定はアプリケーションが他の外部エンドポイントと通信するために使用するアプリケーションレベルのプロキシとは無関係です。 API Manager エージェントのプロキシを設定するには、次のプロパティをアプリケーションに追加します。 anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## [](#mule-アプリケーション用のプロキシの設定)Mule アプリケーション用のプロキシの設定 Runtime Fabric でデプロイされるアプリケーションは、Runtime Fabric クラスターからプロキシ設定を継承します。各アプリケーションでプロキシを設定することもできます。 各コネクタ (HTTP リクエスターなど) でプロキシをセットアップするか、または次の例に示すようにアプリケーションのプロパティでプロキシをセットアップすることができます。アプリケーションで多くのコネクタを使用する場合は、アプリケーションのプロパティでプロキシを設定した方が楽です。 http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true # Runtime Fabric でのローカルレジストリの使用 Runtime Fabric では、独自のレジストリを使用して Runtime Fabric をインストールして管理し、Kubernetes でアプリケーションを実行するために必要な Docker イメージを保存します。セキュリティポリシーで、自分で管理しているレジストリから Docker イメージを取得することが要求されている場合は、これらの Docker イメージを取得して保存するようにローカルレジストリをセットアップできます。 ## [](#ローカルレジストリのサポートに関する制限事項)ローカルレジストリのサポートに関する制限事項 ローカルレジストリのサポートに関する次の制限事項を確認してください。
OpenShift オペレーターのインストール中にローカルレジストリを使用することはできません。ただし、Mule アプリケーションを実行するために、OpenShift RTF でローカルレジストリを使用して、Mule Docker イメージを保存し、Runtime Fabric をインストールして管理することはできます。
- [Runtime Fabric コマンドラインユーティリティ (​`rtfctl`​)](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​ バージョン 0.3.150 以降を使用する必要があります。​`rtfctl`​ を使用すると、デフォルトで最新のバージョンに Runtime Fabric エージェントがインストールされます。 - ローカルレジストリを使用できるのは、バージョン 1.12.0 以降の新しい Runtime Fabric インスタンスを作成する場合のみです。 ローカルレジストリをセットアップする場合は、Runtime Fabric を再インストールせずに 1.12.0 より後のバージョンにアップグレードできます。 そのインストールを 1.12.0 以降にアップグレードする場合でも、ローカルレジストリを任意のバージョンの既存の Runtime Fabric インスタンスに追加することはできません。 - ローカルレジストリで使用するために Runtime Fabric インスタンスを作成した場合、​`rtf-runtime-registry`​ エンドポイントを使用するように後から再設定することはできません。​`rtf-runtime-registry`​ エンドポイントを使用するには、標準のインストール手順に従って新しい Runtime Fabric インスタンスをインストールする必要があります。 - レジストリと Runtime Fabric レジストリ間の同期については各自が責任を負うことになります。MuleSoft では、レジストリ間でイメージを同期するための追加のソフトウェアを提供していません。インストールを始める前に、ご使用のバージョンのすべての連動関係イメージをローカルレジストリにプッシュしてください。ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。 - 認証が必要なローカルレジストリを使用している場合、異なる名前空間の間でのプルシークレットの同期と伝播は各自の責任となります。または、シークレットで次の表示ラベルを使用している場合は、Runtime Fabric により異なる名前空間の間でプルシークレットを同期できます。 labels: rtf.mulesoft.com/synchronized: "true" - ローカルレジストリへのアクセス権を認証する必要がある場合は、 [対応するログイン情報が ​`rtf`​ 名前空間で Kubernetes シークレットとして設定されていること](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)​を確認してください。Runtime Fabric をインストールするときに設定済みのシークレットの名前が必要になります。 - また、アプリケーションのデプロイメントに使用する Mule Runtime バージョンをレジストリ内で同期する必要もあります。最新の Mule Runtime パッチバージョンに関する情報については、​[「Runtime Fabric Patch Update Release Notes (Runtime Fabric パッチ更新リリースノート)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。イメージの場所は次の形式に従います: `rtf-runtime-registry.kqa.msap.io/mulesoft/poseidon-runtime-4.4.0:`​。 ## [](#runtime-fabric-で使用するローカルレジストリをセットアップする)Runtime Fabric で使用するローカルレジストリをセットアップする ローカルレジストリをセットアップするには、レジストリを同期するために必要なログイン情報を収集して追加する必要があります。 ### [](#始める前に)始める前に 次の作業を必ず実行しておいてください。 1. 非公開の Docker イメージレジストリをセットアップ、設定、およびテストします。 2. Runtime Fabric のインストールに必要なすべての Docker イメージをローカルレジストリに同期します。 ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。
連動関係バージョンは Runtime Fabric バージョンに固有です。
3. [`rtfctl`​ コマンドラインユーティリティ](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed#step-3-download-the-rtfctl-utility)​バージョン 0.3.150 以降をダウンロードしてインストールします。 4. [Runtime Manager を使用して Runtime Fabric を作成](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed#step-3-download-the-rtfctl-utility)​してアクティベーションデータを収集します。 ### [](#ローカルレジストリを設定して-runtime-fabric-をインストールする)ローカルレジストリを設定して Runtime Fabric をインストールする 1. `rtf-runtime-registry`​ ログイン情報を取得します。 ```copy # rtfctl get registry-credentials ``` このコマンドにより、現在のシェル環境で ​`RTF_IMAGE_REGISTRY_ENDPOINT`​、​`RTF_IMAGE_REGISTRY_USER`​、​`RTF_IMAGE_REGISTRY_PASSWORD`​ が設定されます。 2. 次のコマンドを実行して、​`rtf-runtime-registry`​ への Docker ログインが成功することを確認します。 ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` ログインが成功したというメッセージが表示されます。 3. イメージを取得して同期するには、自分の非公開コンテナレジストリにログインして次のコマンドを実行します。​``​ は適宜置き換えてください。 US コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` EU コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` 4. Runtime Fabric リリースノートでパブリッシュされているバージョンに基づいて、他のすべての連動関係イメージ (resourceFetcher、clusterOps など) でステップ 3 を繰り返します。 5. レジストリへのアクセスに認証を使用している場合は、rtf 名前空間で必須のシークレットを作成します。 ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 6. Runtime Fabric インストールを最終処理して、ローカルレジストリから取得するように設定します。 ```copy # rtfctl install ‘’ --image-pull-registry ``` または、レジストリへのアクセスに認証を使用している場合は、次のコマンドを使用します。 ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` このコマンドにより、Runtime Fabric でローカルレジストリ URL と ​`image-pull-secret`​ 値の必要なオーバーライドが作成され、Runtime Fabric がアップグレード後も引き続きローカルレジストリからイメージを取得するようになります。 7. レジストリへのアクセスに認証を使用している場合は、インストールの完了後に、RTF 名前空間とアプリケーションをデプロイする他の名前空間でプルシークレットを再作成する必要があります。 8. Mule ライセンスキーの挿入などの追加の手順については、​[インストール手順](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed)​を参照してください。 `rtfctl uninstall`​ コマンドにより、インストール中に指定したプルシークレットが削除されます。 `rtfctl`​ を使用してバックアップと復元の手順を実行するときに、バックアップはローカルレジストリ URL とプルシークレットを参照します。 # Runtime Fabric でのローカルレジストリの使用 Runtime Fabric では、独自のレジストリを使用して Runtime Fabric をインストールして管理し、Kubernetes でアプリケーションを実行するために必要な Docker イメージを保存します。セキュリティポリシーで、自分で管理しているレジストリから Docker イメージを取得することが要求されている場合は、これらの Docker イメージを取得して保存するようにローカルレジストリをセットアップできます。 ## [](#ローカルレジストリのサポートに関する制限事項)ローカルレジストリのサポートに関する制限事項 Mule Docker イメージ (アプリケーションデプロイメントの管理用) と Runtime Fabric ソフトウェアイメージ (Runtime Fabric ソフトウェアの更新またはインストール用) を保存するために、すべての Runtime Fabric サポート対象プラットフォームベンダーにわたってローカルレジストリを設定できます。次の詳細と制限事項は、Mule Docker イメージと Runtime Fabric ソフトウェアイメージの両方に適用されます。
OpenShift 上の Runtime Fabric Operator のインストールまたは管理にローカルレジストリを使用することはできません。
- [Runtime Fabric コマンドラインユーティリティ (​`rtfctl`​)](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl)​ バージョン 0.3.150 以降を使用できます。 `rtfctl`​ を使用すると、デフォルトで最新のバージョンに Runtime Fabric エージェントがインストールされます。 - Runtime Fabric のインストールとローカルレジストリの設定には Helm を使用できます。 - ローカルレジストリを使用できるのは、バージョン 1.12.0 以降の新しい Runtime Fabric インスタンスを作成する場合のみです。 ローカルレジストリをセットアップする場合は、Runtime Fabric を再インストールせずに 1.12.0 より後のバージョンにアップグレードできます。 既存の Runtime Fabric インスタンスにローカルレジストリを追加するには、インストールが Helm ベースの[Helm 管理 Runtime Fabric への移行](https://docs.mulesoft.com/jp/runtime-fabric/2.6/migrate-helm)であることを確認し、次のセクションのステップを実行してローカルレジストリを追加します。 - ローカルレジストリで使用するために Runtime Fabric インスタンスを作成した場合、​`rtf-runtime-registry`​ エンドポイントを使用するように後から再設定することはできません。​`rtf-runtime-registry`​ エンドポイントを使用するには、標準のインストール手順に従って新しい Runtime Fabric インスタンスをインストールする必要があります。 - お客様はローカルレジストリを必要な連動関係と同期する責任を負います。 - [Runtime Fabric コアソフトウェアイメージまたは連動関係の自動同期](#synch-rtf) - [Mule Runtime イメージまたは連動関係の手動同期](#synch-runtime) - アプリケーションに必要なサードパーティ連動関係を同期します。 MuleSoft では、サードパーティの連動関係とイメージを同期するための追加のソフトウェアを提供していません。デプロイメントを始める前に、Mule アプリケーションのすべての連動関係イメージをローカルレジストリにプッシュしてください。 - 認証が必要なローカルレジストリを使用している場合、異なる名前空間の間でのプルシークレットの同期と伝播は各自の責任となります。または、シークレットで次の表示ラベルを使用している場合は、Runtime Fabric により異なる名前空間の間でプルシークレットを同期できます。 labels: rtf.mulesoft.com/synchronized: "true" - ローカルレジストリへのアクセス権を認証する必要がある場合は、 [対応するログイン情報が ​`rtf`​ 名前空間で Kubernetes シークレットとして設定されていること](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)​を確認してください。Runtime Fabric をインストールするときに設定済みのシークレットの名前が必要になります。 ## [](#synch-runtime)ローカルレジストリへの Mule Runtime の連動関係とイメージの同期 アプリケーションのデプロイメントに使用する Mule Runtime バージョンをレジストリ内で同期するには、​[「Mule runtime patch updates for Runtime Fabric Release Notes (Runtime Fabric リリースノートの Mule Runtime パッチ更新)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。イメージの場所は次の形式に従います: `rtf-runtime-registry.kprod.msap.io/mulesoft/`​。 ## [](#synch-rtf)ローカルレジストリへの Runtime Fabric コアソフトウェアの連動関係とイメージの同期 Runtime Fabric をインストールするには、まず連動関係イメージをローカルレジストリに同期する必要があります。同期を実行するには自動的にスクリプトを実行するか手動でコマンドを実行します。 - 自動同期 - 手動同期 連動関係イメージを自動的に同期するには、​`docker`​、​`curl`​、​`jq`​ ツールを使用する bash スクリプトを実行します。
自動レジストリ同期は、Runtime Fabric バージョン 2.6.0 以降で使用できます。このスクリプトを使用して以前の連動関係を取得することはできません。
[Runtime Manager のアクセス管理権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product#runtime-manager)​が ​**\[Read Runtime Fabric (Runtime Fabric の読み取り)\]**​ に設定されていることを確認します。この設定により、組織内で Runtime Fabric を照会できます。 1. Unix シェルで、次のスクリプトを実行します。​`agent-version`​、​`authorization-token`​、​`mulesoft-docker-server`​、およびその他のパラメーター値は適宜置き換えます。 ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. スクリプトパラメーター
パラメーター 説明

platform-url

Anypoint Platform の URL。​https://anypoint.mulesoft.com または https://eu1.anypoint.mulesoft.com など。

agent-version

同期に必要な Runtime Fabric エージェントのリリースバージョン。

authorization-token

同期を実行するために接続アプリケーションを使用するのに必要な認証トークン。このトークンを使用すると、リンクは接続アプリケーションページにリダイレクトします。

mulesoft-docker-server

同期に必要な MuleSoft Docker サーバー。
US コントロールプレーン: rtf-runtime-registry.kprod.msap.io
EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io
連動関係イメージを手動で同期する手順は次のとおりです。 1. 自分の非公開コンテナレジストリにログインして次のコマンドを実行します。​`docker-server`​ は適宜置き換えます。 US コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` EU コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## [](#runtime-fabric-向けのローカルレジストリの設定)Runtime Fabric 向けのローカルレジストリの設定 ローカルレジストリをセットアップするには、レジストリを同期するために必要なログイン情報を収集して追加する必要があります。 ### [](#始める前に)始める前に 次の作業を必ず実行しておいてください。 1. 非公開の Docker イメージレジストリをセットアップ、設定、およびテストします。 2. Runtime Fabric のインストールに必要なすべての Docker イメージをローカルレジストリに​[同期します](#synch-rtf)​。 ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。
連動関係バージョンは Runtime Fabric バージョンに固有です。
`rtfctl`​ または ​`helm`​ とローカルレジストリを使用して Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - RTFCTL - Helm 1. [`rtfctl`​ コマンドラインユーティリティ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed#step-3-download-the-rtfctl-utility)​バージョン 0.3.150 以降をダウンロードしてインストールします。 2. `rtf-runtime-registry`​ ログイン情報を取得します。 ```copy # rtfctl get registry-credentials ``` このコマンドにより、現在のシェル環境で ​`RTF_IMAGE_REGISTRY_ENDPOINT`​、​`RTF_IMAGE_REGISTRY_USER`​、​`RTF_IMAGE_REGISTRY_PASSWORD`​ が設定されます。 3. 次のコマンドを実行して、​`rtf-runtime-registry`​ への Docker ログインが成功することを確認します。 ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` ログインが成功したというメッセージが表示されます。 4. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 5. Runtime Fabric リリースノートでパブリッシュされているバージョンに基づいて、他のすべての連動関係イメージ (resourceFetcher、clusterOps など) でステップ 3 を繰り返します。 6. レジストリへのアクセスに認証を使用している場合は、rtf 名前空間で必須のシークレットを作成します。 ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Runtime Fabric インストールを最終処理して、ローカルレジストリから取得するように設定します。 ```copy # rtfctl install ‘’ --image-pull-registry ``` または、レジストリへのアクセスに認証を使用している場合は、次のコマンドを使用します。 ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` このコマンドにより、Runtime Fabric でローカルレジストリ URL と ​`image-pull-secret`​ 値の必要なオーバーライドが作成され、Runtime Fabric がアップグレード後も引き続きローカルレジストリからイメージを取得するようになります。 8. レジストリへのアクセスに認証を使用している場合は、インストールの完了後に、RTF 名前空間とアプリケーションをデプロイする他の名前空間でプルシークレットを再作成する必要があります。 9. Mule ライセンスキーの挿入などの追加の手順については、​[インストール手順](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed)​を参照してください。 `rtfctl uninstall`​ コマンドにより、インストール中に指定したプルシークレットが削除されます。 `rtfctl`​ を使用してバックアップと復元の手順を実行するときに、バックアップはローカルレジストリ URL とプルシークレットを参照します。 1. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 2. [Runtime Manager を使用して Runtime Fabric を作成します](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-helm#create-a-runtime-fabric-using-runtime-manager)​。 3. Runtime Manager で、​**Helm**​ パスを選択し、画面プラットフォーム上の手順に従います。 4. 非公開の ​`docker-server`​、​`docker-username`​、​`docker-password`​ を取得します。 5. Runtime Manager で ​**Helm**​ パスの手順に従って Unix シェルで次のコマンドを実行して Docker サーバーの名前、ユーザー名、パスワードを使用したシークレットを作成します。 ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 1. **Helm**​ パスの手順に従って ​`values.yml`​ ファイルをダウンロードし、その値を変更できるようにします。非公開のレジストリ設定の場合、ローカル Docker サーバーを使用して ​`rtfRegistry`​ を更新し、​`pullSecretName`​ パラメーターを更新します。 2. **Helm**​ パスの手順を続行し、Kubernetes クラスターに Runtime Fabric をインストールします。 ## [](#関連情報)関連情報 - [values.yml の設定リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-helm#values-yml-reference) # Runtime Fabric でのローカルレジストリの使用 Runtime Fabric では、独自のレジストリを使用して Runtime Fabric をインストールして管理し、Kubernetes でアプリケーションを実行するために必要な Docker イメージを保存します。セキュリティポリシーで、自分で管理しているレジストリから Docker イメージを取得することが要求されている場合は、これらの Docker イメージを取得して保存するようにローカルレジストリをセットアップできます。 ## [](#ローカルレジストリのサポートに関する制限事項)ローカルレジストリのサポートに関する制限事項 Mule Docker イメージ (アプリケーションデプロイメントの管理用) と Runtime Fabric ソフトウェアイメージ (Runtime Fabric ソフトウェアの更新またはインストール用) を保存するために、すべての Runtime Fabric サポート対象プラットフォームベンダーにわたってローカルレジストリを設定できます。次の詳細と制限事項は、Mule Docker イメージと Runtime Fabric ソフトウェアイメージの両方に適用されます。
OpenShift 上の Runtime Fabric Operator のインストールまたは管理にローカルレジストリを使用することはできません。
- [Runtime Fabric コマンドラインユーティリティ (​`rtfctl`​)](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl)​ バージョン 0.3.150 以降を使用できます。 `rtfctl`​ を使用すると、デフォルトで最新のバージョンに Runtime Fabric エージェントがインストールされます。 - Runtime Fabric のインストールとローカルレジストリの設定には Helm を使用できます。 - ローカルレジストリを使用できるのは、バージョン 1.12.0 以降の新しい Runtime Fabric インスタンスを作成する場合のみです。 ローカルレジストリをセットアップする場合は、Runtime Fabric を再インストールせずに 1.12.0 より後のバージョンにアップグレードできます。 既存の Runtime Fabric インスタンスにローカルレジストリを追加するには、インストールが Helm ベースの[Helm 管理 Runtime Fabric への移行](https://docs.mulesoft.com/jp/runtime-fabric/2.7/migrate-helm)であることを確認し、次のセクションのステップを実行してローカルレジストリを追加します。 - ローカルレジストリで使用するために Runtime Fabric インスタンスを作成した場合、​`rtf-runtime-registry`​ エンドポイントを使用するように後から再設定することはできません。​`rtf-runtime-registry`​ エンドポイントを使用するには、標準のインストール手順に従って新しい Runtime Fabric インスタンスをインストールする必要があります。 - お客様はローカルレジストリを必要な連動関係と同期する責任を負います。 - [Runtime Fabric コアソフトウェアイメージまたは連動関係の自動同期](#synch-rtf) - [Mule Runtime イメージまたは連動関係の手動同期](#synch-runtime) - アプリケーションに必要なサードパーティ連動関係を同期します。 MuleSoft では、サードパーティの連動関係とイメージを同期するための追加のソフトウェアを提供していません。デプロイメントを始める前に、Mule アプリケーションのすべての連動関係イメージをローカルレジストリにプッシュしてください。 - 認証が必要なローカルレジストリを使用している場合、異なる名前空間の間でのプルシークレットの同期と伝播は各自の責任となります。または、シークレットで次の表示ラベルを使用している場合は、Runtime Fabric により異なる名前空間の間でプルシークレットを同期できます。 labels: rtf.mulesoft.com/synchronized: "true" - ローカルレジストリへのアクセス権を認証する必要がある場合は、 [対応するログイン情報が ​`rtf`​ 名前空間で Kubernetes シークレットとして設定されていること](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)​を確認してください。Runtime Fabric をインストールするときに設定済みのシークレットの名前が必要になります。 ## [](#synch-runtime)ローカルレジストリへの Mule Runtime の連動関係とイメージの同期 アプリケーションのデプロイメントに使用する Mule Runtime バージョンをレジストリ内で同期するには、​[「Mule runtime patch updates for Runtime Fabric Release Notes (Runtime Fabric リリースノートの Mule Runtime パッチ更新)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。イメージの場所は次の形式に従います: `rtf-runtime-registry.kprod.msap.io/mulesoft/`​。 ## [](#synch-rtf)ローカルレジストリへの Runtime Fabric コアソフトウェアの連動関係とイメージの同期 Runtime Fabric をインストールするには、まず連動関係イメージをローカルレジストリに同期する必要があります。同期を実行するには自動的にスクリプトを実行するか手動でコマンドを実行します。 - 自動同期 - 手動同期 連動関係イメージを自動的に同期するには、​`docker`​、​`curl`​、​`jq`​ ツールを使用する bash スクリプトを実行します。
自動レジストリ同期は、Runtime Fabric バージョン 2.6.0 以降で使用できます。このスクリプトを使用して以前の連動関係を取得することはできません。
[Runtime Manager のアクセス管理権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product#runtime-manager)​が ​**\[Read Runtime Fabric (Runtime Fabric の読み取り)\]**​ に設定されていることを確認します。この設定により、組織内で Runtime Fabric を照会できます。 1. Unix シェルで、次のスクリプトを実行します。​`agent-version`​、​`authorization-token`​、​`mulesoft-docker-server`​、およびその他のパラメーター値は適宜置き換えます。 ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. スクリプトパラメーター
パラメーター 説明

platform-url

Anypoint Platform の URL。​https://anypoint.mulesoft.com または https://eu1.anypoint.mulesoft.com など。

agent-version

同期に必要な Runtime Fabric エージェントのリリースバージョン。

authorization-token

同期を実行するために接続アプリケーションを使用するのに必要な認証トークン。このトークンを使用すると、リンクは接続アプリケーションページにリダイレクトします。

mulesoft-docker-server

同期に必要な MuleSoft Docker サーバー。
US コントロールプレーン: rtf-runtime-registry.kprod.msap.io
EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io
連動関係イメージを手動で同期する手順は次のとおりです。 1. 自分の非公開コンテナレジストリにログインして次のコマンドを実行します。​`docker-server`​ は適宜置き換えます。 US コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` EU コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## [](#runtime-fabric-向けのローカルレジストリの設定)Runtime Fabric 向けのローカルレジストリの設定 ローカルレジストリをセットアップするには、レジストリを同期するために必要なログイン情報を収集して追加する必要があります。 ### [](#始める前に)始める前に 次の作業を必ず実行しておいてください。 1. 非公開の Docker イメージレジストリをセットアップ、設定、およびテストします。 2. Runtime Fabric のインストールに必要なすべての Docker イメージをローカルレジストリに​[同期します](#synch-rtf)​。 ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。
連動関係バージョンは Runtime Fabric バージョンに固有です。
`rtfctl`​ または ​`helm`​ とローカルレジストリを使用して Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - RTFCTL - Helm 1. [`rtfctl`​ コマンドラインユーティリティ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed#step-3-download-the-rtfctl-utility)​バージョン 0.3.150 以降をダウンロードしてインストールします。 2. `rtf-runtime-registry`​ ログイン情報を取得します。 ```copy # rtfctl get registry-credentials ``` このコマンドにより、現在のシェル環境で ​`RTF_IMAGE_REGISTRY_ENDPOINT`​、​`RTF_IMAGE_REGISTRY_USER`​、​`RTF_IMAGE_REGISTRY_PASSWORD`​ が設定されます。 3. 次のコマンドを実行して、​`rtf-runtime-registry`​ への Docker ログインが成功することを確認します。 ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` ログインが成功したというメッセージが表示されます。 4. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 5. Runtime Fabric リリースノートでパブリッシュされているバージョンに基づいて、他のすべての連動関係イメージ (resourceFetcher、clusterOps など) でステップ 3 を繰り返します。 6. レジストリへのアクセスに認証を使用している場合は、rtf 名前空間で必須のシークレットを作成します。 ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Runtime Fabric インストールを最終処理して、ローカルレジストリから取得するように設定します。 ```copy # rtfctl install ‘’ --image-pull-registry ``` または、レジストリへのアクセスに認証を使用している場合は、次のコマンドを使用します。 ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` このコマンドにより、Runtime Fabric でローカルレジストリ URL と ​`image-pull-secret`​ 値の必要なオーバーライドが作成され、Runtime Fabric がアップグレード後も引き続きローカルレジストリからイメージを取得するようになります。 8. レジストリへのアクセスに認証を使用している場合は、インストールの完了後に、RTF 名前空間とアプリケーションをデプロイする他の名前空間でプルシークレットを再作成する必要があります。 9. Mule ライセンスキーの挿入などの追加の手順については、​[インストール手順](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed)​を参照してください。 `rtfctl uninstall`​ コマンドにより、インストール中に指定したプルシークレットが削除されます。 `rtfctl`​ を使用してバックアップと復元の手順を実行するときに、バックアップはローカルレジストリ URL とプルシークレットを参照します。 1. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 2. [Runtime Manager を使用して Runtime Fabric を作成します](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-helm#create-a-runtime-fabric-using-runtime-manager)​。 3. Runtime Manager で、​**Helm**​ パスを選択し、画面プラットフォーム上の手順に従います。 4. 非公開の ​`docker-server`​、​`docker-username`​、​`docker-password`​ を取得します。 5. Runtime Manager で ​**Helm**​ パスの手順に従って Unix シェルで次のコマンドを実行して Docker サーバーの名前、ユーザー名、パスワードを使用したシークレットを作成します。 ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 1. **Helm**​ パスの手順に従って ​`values.yml`​ ファイルをダウンロードし、その値を変更できるようにします。非公開のレジストリ設定の場合、ローカル Docker サーバーを使用して ​`rtfRegistry`​ を更新し、​`pullSecretName`​ パラメーターを更新します。 2. **Helm**​ パスの手順を続行し、Kubernetes クラスターに Runtime Fabric をインストールします。 ## [](#関連情報)関連情報 - [values.yml の設定リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-helm#values-yml-reference) # Runtime Fabric でのローカルレジストリの使用 Runtime Fabric では、独自のレジストリを使用して Runtime Fabric をインストールして管理し、Kubernetes でアプリケーションを実行するために必要な Docker イメージを保存します。セキュリティポリシーで、自分で管理しているレジストリから Docker イメージを取得することが要求されている場合は、これらの Docker イメージを取得して保存するようにローカルレジストリをセットアップできます。 ## [](#ローカルレジストリのサポートに関する制限事項)ローカルレジストリのサポートに関する制限事項 Mule Docker イメージ (アプリケーションデプロイメントの管理用) と Runtime Fabric ソフトウェアイメージ (Runtime Fabric ソフトウェアの更新またはインストール用) を保存するために、すべての Runtime Fabric サポート対象プラットフォームベンダーにわたってローカルレジストリを設定できます。次の詳細と制限事項は、Mule Docker イメージと Runtime Fabric ソフトウェアイメージの両方に適用されます。
OpenShift 上の Runtime Fabric Operator のインストールまたは管理にローカルレジストリを使用することはできません。
- [Runtime Fabric コマンドラインユーティリティ (​`rtfctl`​)](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl)​ バージョン 0.3.150 以降を使用できます。 `rtfctl`​ を使用すると、デフォルトで最新のバージョンに Runtime Fabric エージェントがインストールされます。 - Runtime Fabric のインストールとローカルレジストリの設定には Helm を使用できます。 - ローカルレジストリを使用できるのは、バージョン 1.12.0 以降の新しい Runtime Fabric インスタンスを作成する場合のみです。 ローカルレジストリをセットアップする場合は、Runtime Fabric を再インストールせずに 1.12.0 より後のバージョンにアップグレードできます。 既存の Runtime Fabric インスタンスにローカルレジストリを追加するには、インストールが Helm ベースの[Helm 管理 Runtime Fabric への移行](https://docs.mulesoft.com/jp/runtime-fabric/2.8/migrate-helm)であることを確認し、次のセクションのステップを実行してローカルレジストリを追加します。 - ローカルレジストリで使用するために Runtime Fabric インスタンスを作成した場合、​`rtf-runtime-registry`​ エンドポイントを使用するように後から再設定することはできません。​`rtf-runtime-registry`​ エンドポイントを使用するには、標準のインストール手順に従って新しい Runtime Fabric インスタンスをインストールする必要があります。 - お客様はローカルレジストリを必要な連動関係と同期する責任を負います。 - [Runtime Fabric コアソフトウェアイメージまたは連動関係の自動同期](#synch-rtf) - [Mule Runtime イメージまたは連動関係の手動同期](#synch-runtime) - アプリケーションに必要なサードパーティ連動関係を同期します。 MuleSoft では、サードパーティの連動関係とイメージを同期するための追加のソフトウェアを提供していません。デプロイメントを始める前に、Mule アプリケーションのすべての連動関係イメージをローカルレジストリにプッシュしてください。 - 認証が必要なローカルレジストリを使用している場合、異なる名前空間の間でのプルシークレットの同期と伝播は各自の責任となります。または、シークレットで次の表示ラベルを使用している場合は、Runtime Fabric により異なる名前空間の間でプルシークレットを同期できます。 labels: rtf.mulesoft.com/synchronized: "true" - ローカルレジストリへのアクセス権を認証する必要がある場合は、 [対応するログイン情報が ​`rtf`​ 名前空間で Kubernetes シークレットとして設定されていること](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)​を確認してください。Runtime Fabric をインストールするときに設定済みのシークレットの名前が必要になります。 ## [](#synch-runtime)ローカルレジストリへの Mule Runtime の連動関係とイメージの同期 アプリケーションのデプロイメントに使用する Mule Runtime バージョンをレジストリ内で同期するには、​[「Mule runtime patch updates for Runtime Fabric Release Notes (Runtime Fabric リリースノートの Mule Runtime パッチ更新)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。イメージの場所は次の形式に従います: `rtf-runtime-registry.kprod.msap.io/mulesoft/`​。 ## [](#synch-rtf)ローカルレジストリへの Runtime Fabric コアソフトウェアの連動関係とイメージの同期 Runtime Fabric をインストールするには、まず連動関係イメージをローカルレジストリに同期する必要があります。同期を実行するには自動的にスクリプトを実行するか手動でコマンドを実行します。 - 自動同期 - 手動同期 連動関係イメージを自動的に同期するには、​`docker`​、​`curl`​、​`jq`​ ツールを使用する bash スクリプトを実行します。
自動レジストリ同期は、Runtime Fabric バージョン 2.6.0 以降で使用できます。このスクリプトを使用して以前の連動関係を取得することはできません。
[Runtime Manager のアクセス管理権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product#runtime-manager)​が ​**\[Read Runtime Fabric (Runtime Fabric の読み取り)\]**​ に設定されていることを確認します。この設定により、組織内で Runtime Fabric を照会できます。 1. Unix シェルで、次のスクリプトを実行します。​`agent-version`​、​`authorization-token`​、​`mulesoft-docker-server`​、およびその他のパラメーター値は適宜置き換えます。 OpenShift 以外の環境の場合: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("generic")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ``` OpenShift 環境の場合: ```copy ##!/usr/bin/env bash dependencies=$(curl /runtimefabric/api/agentmanifests/ -H 'Authorization: bearer ' | jq -c '.dependencies |.[] | select(.provider | contains("openshift")) | "\(.artifact):\(.version)"' | sed 's/"//g') for i in $dependencies do echo "Processing $i" docker pull /mulesoft/$i docker tag /mulesoft/$i /mulesoft/$i docker push /mulesoft/$i done ```
Table 1. スクリプトパラメーター
パラメーター 説明

platform-url

Anypoint Platform の URL。​https://anypoint.mulesoft.com または https://eu1.anypoint.mulesoft.com など。

agent-version

同期に必要な Runtime Fabric エージェントのリリースバージョン。

authorization-token

同期を実行するために接続アプリケーションを使用するのに必要な認証トークン。このトークンを使用すると、リンクは接続アプリケーションページにリダイレクトします。

mulesoft-docker-server

同期に必要な MuleSoft Docker サーバー。
US コントロールプレーン: rtf-runtime-registry.kprod.msap.io
EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io
連動関係イメージを手動で同期する手順は次のとおりです。 1. 自分の非公開コンテナレジストリにログインして次のコマンドを実行します。​`docker-server`​ は適宜置き換えます。 US コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 ``` EU コントロールプレーンの場合: ```copy # docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 ``` ## [](#runtime-fabric-向けのローカルレジストリの設定)Runtime Fabric 向けのローカルレジストリの設定 ローカルレジストリをセットアップするには、レジストリを同期するために必要なログイン情報を収集して追加する必要があります。 ### [](#始める前に)始める前に 次の作業を必ず実行しておいてください。 1. 非公開の Docker イメージレジストリをセットアップ、設定、およびテストします。 2. Runtime Fabric のインストールに必要なすべての Docker イメージをローカルレジストリに​[同期します](#synch-rtf)​。 ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。
連動関係バージョンは Runtime Fabric バージョンに固有です。
`rtfctl`​ または ​`helm`​ とローカルレジストリを使用して Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - RTFCTL - Helm - OpenShift 1. [`rtfctl`​ コマンドラインユーティリティ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed#step-3-download-the-rtfctl-utility)​バージョン 0.3.150 以降をダウンロードしてインストールします。 2. `rtf-runtime-registry`​ ログイン情報を取得します。 ```copy # rtfctl get registry-credentials ``` このコマンドにより、現在のシェル環境で ​`RTF_IMAGE_REGISTRY_ENDPOINT`​、​`RTF_IMAGE_REGISTRY_USER`​、​`RTF_IMAGE_REGISTRY_PASSWORD`​ が設定されます。 3. 次のコマンドを実行して、​`rtf-runtime-registry`​ への Docker ログインが成功することを確認します。 ```copy # eval $(rtfctl get registry-credentials ) # docker login $RTF_IMAGE_REGISTRY_ENDPOINT --username $RTF_IMAGE_REGISTRY_USER --password $RTF_IMAGE_REGISTRY_PASSWORD ``` ログインが成功したというメッセージが表示されます。 4. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 5. Runtime Fabric リリースノートでパブリッシュされているバージョンに基づいて、他のすべての連動関係イメージ (resourceFetcher、clusterOps など) でステップ 3 を繰り返します。 6. レジストリへのアクセスに認証を使用している場合は、rtf 名前空間で必須のシークレットを作成します。 ```copy # kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf ``` 7. Runtime Fabric インストールを最終処理して、ローカルレジストリから取得するように設定します。 ```copy # rtfctl install ‘’ --image-pull-registry ``` または、レジストリへのアクセスに認証を使用している場合は、次のコマンドを使用します。 ```copy # rtfctl install ‘’ --image-pull-registry --image-pull-secret ``` このコマンドにより、Runtime Fabric でローカルレジストリ URL と ​`image-pull-secret`​ 値の必要なオーバーライドが作成され、Runtime Fabric がアップグレード後も引き続きローカルレジストリからイメージを取得するようになります。 8. レジストリへのアクセスに認証を使用している場合は、インストールの完了後に、RTF 名前空間とアプリケーションをデプロイする他の名前空間でプルシークレットを再作成する必要があります。 9. Mule ライセンスキーの挿入などの追加の手順については、​[インストール手順](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed)​を参照してください。 `rtfctl uninstall`​ コマンドにより、インストール中に指定したプルシークレットが削除されます。 `rtfctl`​ を使用してバックアップと復元の手順を実行するときに、バックアップはローカルレジストリ URL とプルシークレットを参照します。 1. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 2. [Runtime Manager を使用して Runtime Fabric を作成します](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm#create-a-runtime-fabric-using-runtime-manager)​。 3. Runtime Manager で、​**Helm**​ パスを選択し、画面プラットフォーム上の手順に従います。 4. 非公開の ​`docker-server`​、​`docker-username`​、​`docker-password`​ を取得します。 5. Runtime Manager で ​**Helm**​ パスの手順に従って Unix シェルで次のコマンドを実行して Docker サーバーの名前、ユーザー名、パスワードを使用したシークレットを作成します。 ```copy kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 1. **Helm**​ パスの手順に従って ​`values.yml`​ ファイルをダウンロードし、その値を変更できるようにします。非公開のレジストリ設定の場合、ローカル Docker サーバーを使用して ​`rtfRegistry`​ を更新し、​`pullSecretName`​ パラメーターを更新します。 2. **Helm**​ パスの手順を続行し、Kubernetes クラスターに Runtime Fabric をインストールします。 1. ローカルレジストリに​[コンテナイメージを同期します](#synch-rtf)​。 2. [Runtime Manager を使用して Runtime Fabric を作成します](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm#create-a-runtime-fabric-using-runtime-manager)​。 3. Runtime Manager で、画面プラットフォーム上の手順に従います。 4. 非公開の ​`docker-server`​、​`docker-username`​、​`docker-password`​ を取得します。 5. Runtime Manager で手順に従って Unix シェルで次のコマンドを実行して Docker サーバーの名前、ユーザー名、パスワードを使用したシークレットを作成します。 ```copy oc create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-email= ``` 1. OpenShift フォームビューで、rtfRegistry 値を設定してローカルレジストリを設定します。 ![rtfRegistry の値を追加する OpenShift フォームビュー](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ocp-local-registry.png) 1. OpenShift のインストールを続行します。 ## [](#関連情報)関連情報 - [values.yml の設定リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm#values-yml-reference) # Runtime Fabric でのログの表示と設定 Runtime Fabric では、次に関するログファイルが生成されます。 - デプロイされた Mule アプリケーション - デプロイされた API プロキシ - Runtime Fabric サービス - Kubernetes サービス ## [](#ログレベル)ログレベル Runtime Fabric では、ログファイルに書き込まれるメッセージの重要度レベルを指定できます。 Runtime Fabric では、カスタムログカテゴリがサポートされていません。
Table 1. Runtime Fabric ログレベル
値 説明 コマンド

すべての優先度

すべてのメッセージをリストします。

なし

ERROR

例外が発生した場合のエラーメッセージのみをリストします。

priority:ERROR

FATAL

アプリケーションが失敗した場合に致命的なメッセージのみをリストします。

priority:FATAL

INFO

有益情報のメッセージをリストします。

priority:INFO

SYSTEM

アプリケーションとワーカーのスタートアップに関するメッセージをリストします。

priority:SYSTEM

CONSOLE

オブジェクトストアの設定など、コンソールイベントに関するメッセージをリストします。

priority:CONSOLE

WARN

警告メッセージをリストします。

priority:WARN

DEBUG

デバッグメッセージをリストします。

priority:DEBUG
ログレベルは、デプロイ中に Mule アプリケーションまたは API プロキシごとに指定します。 ## [](#アプリケーションのログレベルを変更する)アプリケーションのログレベルを変更する アプリケーションのログレベルを変更するには、Anypoint Runtime Manager を使用して ​`logging.level.=LEVEL`​ プロパティを設定します。 1. Runtime Manager で、アプリケーションの ​**\[Settings (設定)\]**​ ページに移動します。 2. **\[Properties (プロパティ)\]**​ タブをクリックします。 3. **\[Table view (テーブルビュー)\]**​ を選択します。 4. **\[New Key (新しいキー)\]**​ 項目で、​`logging.level.`​ プロパティを追加します。 5. **\[New Value (新しい値)\]**​ 項目で、目的のログレベルを追加します。 たとえば、キー ​`logging.level.org.mule.service.http.impl.service.HttpMessageLogger`​ と ​`DEBUG`​ の値を追加した場合、​`DEBUG`​ レベルのログ情報が ​`HttpMessageLogger`​ から生成されます。 ## [](#アプリケーションからのログの表示)アプリケーションからのログの表示 オペレーションセンターには、VM/ベアメタルの Runtime Fabric で実行されているアプリケーションとサービスから生成されたログのストリームが表示されます。これは、ログ転送を設定していない場合に便利です。 1. オペレーションセンターから ​**\[Logging (ログ)\]**​ に移動します。 2. **\[Kubernetes\]**​ を選択します。 3. **\[Pods (ポッド)\]**​ タブを選択します。 4. 検索入力領域の横にあるドロップダウンリストで、アプリケーションがデプロイされている環境の ID を選択します。 5. 対象のアプリケーションの名前で始まるポッド名を見つけます。 6. そのポッド名を選択して、​**\[Logs (ログ)\]**​ を選択します。 対象のアプリケーションに検索条件が適用された ​**\[Logs (ログ)\]**​ タブが表示されます。
最新のログを表示するには、​[Refresh (更新)]​ を選択します。
### [](#絞り込み)絞り込み ログ内をドリルダウンするための 2 つの絞り込みレベルがあります。 - `_Containers_`​ 検索条件では、コンテナ名で絞り込みます。 - `_Pods_`​ 検索条件では、ポッド名で絞り込みます。 これは、アプリケーション名の後にワイルドカード (​`%`​) を続けて指定する場合に役立ちます。 ## [](#外部サービスへのログの転送)外部サービスへのログの転送 VM/ベアメタルの Runtime Fabric は、次の場所へのログ転送をサポートします。 - Anypoint Monitoring - ログ転送出力プラグインを使用するサードパーティのログソリューション。 - Azure Log Analytics - Elasticsearch - Graylog Extended Log Format (GELF) - Splunk - CloudWatch - Syslog - Datadog - `rsyslog`​ クライアントサービスを使用する外部サービス。 ### [](#外部ログ転送に関する制限事項)外部ログ転送に関する制限事項 - [Log4j アペンダー](https://docs.mulesoft.com/jp/runtime-fabric/1.13/use-log4j-appender)​と外部ログ転送を同時に使用すると、ログコレクションが重複する可能性もあります。どちらか一方を使用してください。 - 一度に 1 つの外部ログ転送設定のみがサポートされます。ただし、Anypoint Platform ログ転送と外部ログ転送サービスは同時に有効化できます。 - 現在、外部ログ転送では、Runtime Fabric クラスター用に設定されたプロキシはサポートされていません。外部ログ転送サービスのアウトバウンド IP アドレスとポートを許可するファイアウォールルールを明示的に設定する必要があります。 - 現在、外部ログ転送では、複数行のログエントリが結合されません。 - Runtime Fabric では、一方向の TLS (クライアントからサーバー) 検証のみがサポートされています。 - 外部ログ転送は Syslog プロトコル RFC5424 に準拠するため、ホスト名、アプリケーション名、プロセス ID が自動的にログエントリにマッピングされません。これらの項目は、​[ログを他の外部サービスに転送](#forward-logs-to-other-external-services)​するときにマッピングされます。 ### [](#ログ転送の有効化)ログ転送の有効化 1. 適用可能なサードパーティログソリューションをインストールおよび設定します。必要なリソースを割り当てていることを確認します。詳細は、サードパーティログソリューションのドキュメントを参照してください。 2. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 3. サイドバーナビゲーションで ​**\[Runtime Fabric\]**​ を選択します。 4. インストール中に使用された名前に基づいて、適用可能な Runtime Fabric を選択します。 5. **\[Logs (ログ)\]**​ タブを選択します。 6. Titanium サブスクリプションがあり、ログを Anypoint Monitoring に転送する場合、​**\[Forward application logs to Anypoint Monitoring (Requires Titanium) (Anypoint Monitoring にアプリケーションログを転送 (Titanium が必要))\]**​ チェックボックスを選択します。 7. ログ転送出力プラグインを使用してログを転送するには、​**\[Forward application logs to an external service (外部サービスにアプリケーションログを転送)\]**​ チェックボックスを選択します。 1. **\[Connects to (接続先)\]**​ ドロップダウンリストで、適用可能なサードパーティログ転送ソリューションを選択します。 2. 次のセクションに示すように、サードパーティログソリューションの設定情報を入力します。 - [Azure Log Analytics 設定パラメーター](#azure-log-analytics-設定パラメーター) - [Elasticsearch 設定パラメーター](#elasticsearch-設定パラメーター) - [GELF 設定パラメーター](#gelf-設定パラメーター) - [Splunk 設定パラメーター](#splunk-設定パラメーター) - [Syslog 設定パラメーター](#Syslog) - [Datadog 設定パラメーター](#Datadog) 8. ログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (重要)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 9. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 10. **\[Apply changes (変更を適用)\]**​ を選択します。 11. 正常にログ転送されたことを確認するには、外部ログ転送サービスを使用してログを手動で確認します。 #### [](#azure-log-analytics-設定パラメーター)Azure Log Analytics 設定パラメーター
Table 2. Azure Log Analytics 設定パラメーター
キー 説明 必須 デフォルト値

Customer ID (顧客 ID)

顧客 ID またはワークスペース ID の文字列を指定します。

はい

Shared Key (共有キー)

プライマリとセカンダリの接続元クライアント認証キーを指定します。

はい

Log Type (ログ種別)

イベント種別名を指定します。

いいえ

runtime_fabric
出力プラグインの設定の例: ```none [OUTPUT] Name azure Customer_ID id Shared_Key key ``` #### [](#elasticsearch-設定パラメーター)Elasticsearch 設定パラメーター

Runtime Fabric 1.10.26 以降では外部ログ転送に Fluent Bit 1.8.3 を使用します。ログを Elasticsearch に転送する場合、設定パラメーター ​Generate_ID​ を ​On​ に設定する必要があります。デフォルトでは、Fluent Bit ではこのパラメーターが ​Off​ に設定されます。
Table 3. Elasticsearch 設定パラメーター
キー 説明 必須 デフォルト値

Host (ホスト)

対象の Elasticsearch インスタンスの IP アドレスまたはホスト名を指定します。

はい

127.0.0.1

Port (ポート)

対象の Elasticsearch インスタンスの TCP ポートを指定します。

はい

9200

Index (インデックス)

インデックス名を指定します。

はい

runtime_fabric

Path (パス)

Elasticsearch は HTTP クエリパス ​/_bulk​ で新しいデータを受け入れます。ただし、Elasticsearch をサブパスのリバースプロキシの背後で提供することもできます。このオプションでは、出力プラグイン側のこのパスを定義します。これにより、パスプレフィックスがインデックス付け HTTP POST URI に追加されます。

いいえ

空の文字列

Buffer Size (バッファサイズ)

Elasticsearch HTTP サービスからの応答を読み取るために使用するバッファサイズを指定します。このオプションは、デバッグ目的で完全な応答の読み取りが必要な場合に役立ちます。応答のサイズは、挿入されたレコード数に応じて増大します。無制限のメモリ量を指定するには、この値を ​False​ に設定します。それ以外の場合は、ユニットサイズ仕様に従って値を設定します。

いいえ

4 KB

HTTP User (HTTP ユーザー)

Elastic X-Pack アクセス用の省略可能なユーザー名ログイン情報を指定します。

いいえ

HTTP Passwd (HTTP パスワード)

[HTTP User (HTTP ユーザー)]​ で定義したユーザーのパスワードを指定します。

いいえ

Type (型)

種別名を指定します。

いいえ

runtime_fabric

Logstash Format (Logstash 形式)

Logstash 形式互換を有効にします。このオプションはブール値 (​True​、​False​、​On​、または ​Off​) を使用します。

いいえ

Logstash Prefix (Logstash プレフィックス)

Logstash Format​ が有効になっている場合、​Index​ 名はプレフィックスと日付で構成されます。たとえば、​Logstash Prefix​ が ​mydata​ に設定されている場合、インデックスは ​mydata-YYYY.MM.DD​ になります。追加される最後の文字列は、データが生成された日付に属します。

いいえ

logstash

Logstash DateFormat (Logstash 日付形式)

Index​ 名の 2 番目の部分の生成で使用される時間形式 (​strftime​ に基づく) を指定します。

いいえ

%Y.%m.%d

Time Key (時間キー)

Logstash Format​ が有効になっている場合、各レコードに新しいタイムスタンプ項目が割り当てられます。この項目の名前は ​Time Key​ プロパティで定義されます。

いいえ

@timestamp

Time Key Format (時間キー形式)

Logstash Format​ が有効になっている場合、このプロパティでタイムスタンプの形式を定義します。

いいえ

%Y-%m-%dT%H:%M:%S

Include Tag Key (タグキーを含む)

有効になっている場合、レコードにタグ名が追加されます。

いいえ

Off (オフ)

Tag Key (タグキー)

Include Tag Key​ が有効になっている場合、このプロパティでタグのキー名を定義します。

いいえ

Generate ID (ID を生成)

有効になっている場合、送信レコードの ​_id​ 値が生成されます。これにより、ES を再試行するときに重複レコードが回避されます。

いいえ

Off (オフ)

Replace Dots (ドットを置換)

有効になっている場合、項目名のドット (「.」) をアンダースコア (「_」) に置き換えます。アンダースコアは Elasticsearch 2.0 ～ 2.3 では必須です。

いいえ

Off (オフ)

Trace Output (出力をトレース)

有効になっている場合、Elasticsearch API コールを stdout に出力します (診断用)。

いいえ

Off (オフ)

Trace Error (エラーをトレース)

有効になっている場合、Elasticsearch でエラーが返されたときに Elasticsearch API コールを stdout に出力します。

いいえ

Off (オフ)

Current Time Index (現在時刻のインデックス)

メッセージレコードの情報ではなく現在時刻をインデックスの生成で使用することを指定します。

いいえ

Off (オフ)

Logstash Prefix Key (Logstash プレフィックスキー)

この文字列を使用してキーにプレフィックスを付けます。

いいえ

TLS

TLS サポートを有効または無効にします。

いいえ

Off (オフ)

CA Path Certificate File (CA パス証明書ファイル)

アップロードする CA 証明書ファイルを指定します。このオプションは、TLS が有効になっている場合のみ使用できます。

いいえ
出力プラグインの設定の例: ```none [OUTPUT] Name es Host 192.168.2.3 Port 9200 Index my_index Type my_type ``` #### [](#gelf-設定パラメーター)GELF 設定パラメーター
Table 4. GELF 設定パラメーター
キー 説明 必須 デフォルト値

Match (一致)

このプラグインで出力するログタグに一致するパターンを指定します。

はい

Host (ホスト)

対象の Graylog サーバーの IP アドレスまたはホスト名を指定します。

はい

127.0.0.1

Port (ポート)

Graylog GELF 入力がリスンするポートを指定します。

はい

12201

Mode (モード)

使用するプロトコルを指定します (​tls​、​tcp​、または ​udp​)。

はい

udp

Gelf Short_Message Key (Gelf Short_Message キー)

短い説明メッセージを指定します (これを GELF で設定する必要があります)。

はい

log

Gelf Timestamp Key (Gelf タイムスタンプキー)

ログのタイムスタンプを指定します (これを GELF で設定する必要があります)。

いいえ

timestamp (タイムスタンプ)

Gelf Host Key (Gelf ホストキー)

メッセージを送信するホスト、送信元、またはアプリケーションの名前として使用する値のキーを指定します。(これを GELF で設定する必要があります)。

いいえ

host (ホスト)

Gelf Full Message Key (Gelf 完全メッセージキー)

バックトレースを含むことができる長いメッセージとして使用するキーを指定します。(これは GELF では省略可能です)。

いいえ

full_message

Gelf Level Key (Gelf レベルキー)

ログレベルとして使用するキーを指定します。この値は標準の syslog レベル (0 ～ 7) である必要があります。

いいえ

level (レベル)

Packet Size (パケットサイズ)

トランスポートプロトコルが ​udp​ に設定されている場合、送信するパケットのサイズを指定します。

いいえ

1420

Compress (圧縮)

トランスポートプロトコルが ​udp​ に設定されている場合、UDP パケットの圧縮を指定します。

いいえ

true

TLS

TLS サポートを有効または無効にします。

いいえ

Off (オフ)

CA Path Certificate File (CA パス証明書ファイル)

アップロードする CA 証明書ファイルを指定します。このオプションは、TLS が有効になっている場合のみ使用できます。

いいえ
出力プラグインの設定の例: ```none [OUTPUT] Name gelf Match kube.* Host Port 12201 Mode tcp Gelf_Short_Message_Key log ``` #### [](#splunk-設定パラメーター)Splunk 設定パラメーター
Table 5. Splunk 設定パラメーター
キー 説明 必須 デフォルト値

Host (ホスト)

対象の Splunk サービスの IP アドレスまたはホスト名を指定します。

はい

127.0.0.1

Port (ポート)

対象の Splunk サービスの TCP ポートを指定します。

はい

8088

Splunk Token (Splunk トークン)

HTTP イベントコレクターインターフェースの認証トークンを指定します。

はい

HTTP User (HTTP ユーザー)

HTTP イベントコレクターの基本認証用の省略可能なユーザー名を指定します。

いいえ

HTTP Passwd (HTTP パスワード)

[HTTP User (HTTP ユーザー)]​ で定義したユーザーのパスワードを指定します。

いいえ

TLS

TLS サポートを有効または無効にします。

いいえ

Off (オフ)

CA Path Certificate File (CA パス証明書ファイル)

アップロードする CA 証明書ファイルを指定します。このオプションは、TLS が有効になっている場合のみ使用できます。

いいえ
出力プラグインの設定の例: ```none [OUTPUT] Name splunk Host 127.0.0.1 Port 8088 Splunk_Token xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx Tls On ``` #### [](#cloudwatch-設定パラメーター)CloudWatch 設定パラメーター
Table 6. CloudWatch 設定パラメーター
キー 説明 必須 デフォルト値

Region (リージョン)

AWS リージョンを指定します。

はい

Aws Access Key Id (AWS アクセスキー ID)

IAM ユーザーのアクセスキー ID を指定します。

はい

Aws Secret Access Key (AWS シークレットアクセスキー)

IAM ユーザーの AWS シークレットアクセスキーを指定します。

はい

Log Group Name (ロググループ名)

ログレコードを送信する CloudWatch ロググループの名前を指定します。

はい

runtime_fabric_cloudwatch

Log Stream Name (ログストリーム名)

ログレコードを送信する CloudWatch ログストリームの名前を指定します。

はい

Log Stream Prefix (ログストリームプレフィックス)

ログストリーム名のプレフィックスを指定します。プレフィックスにタグが付加されて、完全なログストリーム名が作成されます。​Log Stream Name​ オプションとの互換性はありません。

いいえ

Role Arn (ロール ARN)

想定する IAM ロールの ARN を指定します (クロスアカウントアクセス用)。

いいえ

Auto Create Group (グループの自動作成)

ロググループを自動的に作成します。有効な値は「On (オン)」または「Off (オフ)」です (大文字と小文字が区別されます)。

いいえ

Off (オフ)
注意: `Log Stream Name`​ または ​`Log Stream Prefix`​ のどちらかを指定する必要がありますが、両方は指定できません。 出力プラグインの設定の例: ```none [OUTPUT] Name cloudwatch_logs region us-east-1 aws_access_key_id aws_secret_access_key log_group_name runtime_fabric_cloudwatch log_stream_prefix my_stream auto_create_group On ``` #### [](#Syslog)Syslog 設定パラメーター
Table 7. Syslog 設定パラメーター
キー 説明 必須 デフォルト値

Host (ホスト)

リモート Syslog サーバーのホスト名または IP アドレス

はい

Port (ポート)

リモート Syslog サーバーの TCP または UDP ポート

はい

514

Mode (モード)

トランスポート種別のモード

はい

udp

Syslog format (Syslog 形式)

Syslog プロトコル形式

いいえ

rfc5424

Syslog Maxsize (Syslog 最大サイズ)

メッセージあたりの最大バイト数を設定する整数値

いいえ

rfc3164 の場合は 1024、rfc5424 の場合は 2048
出力プラグインの設定の例: ```none [OUTPUT] Name syslog Host 127.0.0.1 Port 514 Mode udp Syslog_Format rfc5424 Syslog_Maxsize 2048 ``` #### [](#Datadog)Datadog 設定パラメーター
Table 8. Datadog 設定パラメーター
キー 説明 必須 デフォルト値

Host (ホスト)

リモート Datadog サーバーのホスト名。

はい

Api Key (API キー)

Datadog API キー。

はい

Compress (圧縮)

ペイロードを GZIP 形式で圧縮します。Datadog では、これを ​gzip​ に設定することが推奨されています。

いいえ

gzip

Datadog Service (Datadog サービス)

ログを生成するサービスの名前。(例: runtime_fabric​)。

いいえ

Datadog Source (Datadog ソース)

サービスの種別。例: postgres​ や ​nginx​。

いいえ

Datadog Tags (Datadog タグ)

Datadog のログに割り当てられたタグ。

いいえ

TLS

エンドツーエンドでセキュアな通信プロトコルサポート。DataDog では CA 証明書ファイルはサポートされていません。

いいえ

Off (オフ)
出力プラグインの設定の例: ```none [OUTPUT] Name datadog Host http-intake.logs.datadoghq.com apikey TLS on compress gzip dd_service dd_source dd_tags team:logs,foo:bar ``` #### [](#ログ転送の設定)ログ転送の設定 次の設定オプションがあります。 - Mule Applications (Mule アプリケーション): Mule アプリケーションからログを転送します。 - Internal load balancer and components (内部ロードバランサーおよびコンポーネント): Runtime Fabric コンポーネントと内部ロードバランサーからログを転送します。 - Runtime Fabric appliance (Runtime Fabric アプライアンス): 監視およびアプライアンスサービスからログを転送します。

  • すべてのオプションはデフォルトで有効化されています。

  • Mule アプリケーションのログ転送を無効化することはできません。ログ転送は、デプロイメント中にアプリケーションごとに無効化できます。
### [](#kubernetes-メタデータ)Kubernetes メタデータ ログを外部サービスに転送する場合、一部のプロバイダーでは追加のメタデータを使用できることがあります。検索を実行する場合、ユーザーは次のメタデータの表示ラベルを活用することで、検索結果を絞り込み、重要なコンテナからのログのみに集中できます。
Table 9. Kubernetes メタデータ
キー 説明 サンプル値

container_name

コンテナの名前を指定します。

アプリケーション

container_image

コンテナ画像の完全名を指定します。

000.dkr.ecr.us-east-1.amazonaws.com/mulesoft/poseidon-runtime-4.3.0:v1.0.0

container_hash

コンテナ画像の名前を指定し、不変の識別子 (SHA256 値) を含めます。

000.dkr.ecr.us-east-1.amazonaws.com/mulesoft/poseidon-runtime-4.3.0@sha256:866daf14a55da1db21c562ddc09487bbb8ffae1dd4cc80b4dc5c64e0ac9c124b

docker_id

Docker 内のコンテナの ID を指定します。

a54a0bf80400b6cd44cae53b9705f5b6330ce4e8efb85c92b3f9c1709829c6fa

host (ホスト)

ポッドが実行されているノードの IP を指定します。

10.0.178.87

namespace_name

ポッドの Kubernetes 名前空間を指定します。

rtf

pod_id

ポッドの ID を指定します。

118cff63-a5ac-11ea-8414-0e281fcb2861

pod_name

ポッドの名前を指定します。

testapp-5789f9774-6lxv7

labels_app

ポッドがサポートしているアプリケーションの表示ラベルを指定します。

testapp

labels_environment

アプリケーションがデプロイされている環境の Anypoint 環境 ID を指定します。

24166311-4e5e-4091-b417-42307747267e

labels_organization

アプリケーションがデプロイされている組織の Anypoint 組織 ID を指定します。

24166311-4e5e-4091-b417-42307747267e

labels_rtf_mulesoft_com_id

Anypoint Platform のアプリケーションデプロイメントの ID を指定します。

194a32bf-bf7e-4c91-aa4e-44132e5aa76d

labels_rtf_mulesoft_com_version

Anypoint Platform のアプリケーションデプロイメントの仕様バージョン ID を指定します。

194a32bf-bf7e-4c91-aa4e-44132e5aa76d

labels_type

ポッドが実行されているデプロイメントの種別を指定します。

MuleApplication
## [](#テストメッセージの送信)テストメッセージの送信 テストメッセージを送信して、VM/ベアメタルの Runtime Fabric と外部ログ転送ソリューション間の接続を検証できます。 1. Runtime Manager のサイドバーナビゲーションで ​**\[Runtime Fabric\]**​ を選択します。 2. インストール中に使用された名前に基づいて、適用可能な Runtime Fabric を選択します。 3. **\[Log Forwarding (ログ転送)\]**​ タブを選択します。 4. **\[Forward application logs to an external service (外部サービスにアプリケーションログを転送)\]**​ を選択します。 5. サービスを選択し、ログ転送ソリューションで必要とされる項目を設定します。 6. 変更を保存して、設定を Runtime Fabric クラスターに適用します。 7. ログ転送ソリューションの設定とログ転送ソリューションへのアクセスをテストする手順は、次のとおりです。 1. 選択したサービスのテストメッセージをトリガーします。 2. ログ転送ソリューションに転送されたテキストを確認します。 ## [](#アプリケーションごとの-anypoint-monitoring-または外部ログ転送の無効化)アプリケーションごとの Anypoint Monitoring または外部ログ転送の無効化 1. \[Runtime Manager\] に移動し、​**\[Applications (アプリケーション)\]**​ を選択します。 2. ログ転送の無効化の対象であるアプリケーションを選択します。 3. **\[Logs (ログ)\]**​ タブを選択します。 4. 該当するログ転送オプションを選択解除します。 - **Forward logs to Anypoint Monitoring (Anypoint Monitoring にログを転送)** - **Forward logs to (<サードパーティサービス> にログを転送)** 5. **\[Deploy (デプロイ)\]**​ を選択してアプリケーションを再デプロイします。 ## [](#他の外部サービスへのログの転送)他の外部サービスへのログの転送 VM/ベアメタルの Anypoint Runtime Fabric では、ログ転送出力プラグインを使用して、サポートされるサードパーティソリューション以外の外部のログソリューションにアプリケーションとクラスターのログを転送することもできます。Runtime Fabric に組み込まれたログ転送機能 (​`rsyslog`​ クライアントサービス) を使用すると、ログデータを TCP または UDP 経由で ​`rsyslog`​ サーバーに送信し、その場所で一元的にログの参照、保持、アラートの受信ができます。Logstash などのログソリューションでは、​`rsyslog`​ クライアントからログデータを受信するためのメソッドが提供されます。

複数行のログを有効にするには、ログエントリを左角括弧 ​[​ で開始する必要があります。
1. ターミナルを使用して、コントローラー VM へのシェル/SSH 接続を開きます。 2. `log-forwarder.yaml`​ という名前のファイルを作成します。 3. 以下の表に基づいてカスタマイズした後、このファイルに次のコンテンツを追加します。 kind: logforwarder version: v2 metadata: name: log-forwarder spec: address: 192.168.100.1:514 protocol: udp 環境に応じて次の値を使用します。
キー 説明

name

ログ転送ルールの名前を指定します。

address

ログデータを転送するエンドポイントとポートを指定します。

protocol

データの送信先のプロトコルを指定します。サポートされるプロトコルは TCP または UDP です。
4. コントローラー VM で次のコマンドを実行し、以前に作成したファイルを参照します。 gravity resource create log-forwarder.yaml ログが外部のログソリューションに転送されます。 ## [](#ログ転送の問題のトラブルシューティング)ログ転送の問題のトラブルシューティング ログ転送の問題が発生した場合、次の手順を実行します。 - ログ転送設定でホストとポートの正しい情報が指定されていることを確認します。 - サーバー側の設定 (ネットワークなど) が正しいこと、およびサーバーにアクセスできることを確認します。 - ログ転送状況を確認します。 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric の名前を選択して、管理ページを開きます。 3. **\[Health Details (健全性の詳細)\]**​ タブを選択します。 4. 必要に応じて、次の情報を確認します。 - **\[Forwarding Logs To External Provider (外部プロバイダーにログを転送)\]**​ の状況が ​`Healthy`​ である。 - **\[Forwarding Logs to Anypoint Monitoring (Anypoint Monitoring にログを転送)\]**​ の状況が ​`Healthy`​ である。 - RTF クラスター内で次のコマンドを実行します。 - `kubectl -nrtf get pods -lapp=external-log-forwarder`​: すべての外部ログ転送ポッドのリストを確認します。これらのポッドの状態が ​`Running`​ であることを確認します。 - `kubectl -nrtf logs -l app=external-log-forwarder`​: 外部ログ転送ポッドのログを参照します。 ## [](#関連情報)関連情報 - [Anypoint Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) # Runtime Fabric での承認済み名前空間の設定 承認済み名前空間を使用して、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできます。クラスター内の権限を制限することで、Runtime Fabric に割り当てられた名前空間内のみのリソースへのアクセスを Runtime Fabric に許可できます。 承認済み名前空間を使用すれば、次の Runtime Fabric リソースの作成を制御できます。 - 名前空間 - RoleBindings - ServiceAccounts ## [](#承認済み名前空間の仕組み)承認済み名前空間の仕組み インストール時に、名前空間、ServiceAccounts、ClusterRoles/Roles、RoleBindings で構成される設定ファイルを指定します。 Runtime Fabric により Runtime Fabric エージェント (rtf-agent) が Runtime Fabric 名前空間にインストールされ、承認済み名前空間リストで指定した追加の名前空間に Runtime Fabric がアクセスできるようになります。 ### [](#例)例 次に、エージェントがクラスターのすべての名前空間のすべての cron ジョブを制御できる Runtime Fabric エージェントの ClusterRole の例を示します。 ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric により、対応する ServiceAccount が 2 つの名前空間の cron ジョブでさまざまなアクション (動詞) を実行できるようにする ClusterRole rtf:agent を使用する必須の RoleBinding オブジェクトが作成されます。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` 認証済み名前空間モードでクラスター化アプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## [](#承認済み名前空間の設定)承認済み名前空間の設定 承認済み名前空間は、Runtime Fabric をインストールするときに設定します。適切なインストール手順を参照してください。 - [Helm を使用した EKS、AKS、GKE への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-helm) - [Red Hat OpenShift への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-openshift) # Runtime Fabric での承認済み名前空間の設定 承認済み名前空間を使用して、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできます。クラスター内の権限を制限することで、Runtime Fabric に割り当てられた名前空間内のみのリソースへのアクセスを Runtime Fabric に許可できます。 承認済み名前空間を使用すれば、次の Runtime Fabric リソースの作成を制御できます。 - 名前空間 - RoleBindings - ServiceAccounts ## [](#承認済み名前空間の仕組み)承認済み名前空間の仕組み インストール時に、名前空間、ServiceAccounts、ClusterRoles/Roles、RoleBindings で構成される設定ファイルを指定します。 Runtime Fabric により Runtime Fabric エージェント (rtf-agent) が Runtime Fabric 名前空間にインストールされ、承認済み名前空間リストで指定した追加の名前空間に Runtime Fabric がアクセスできるようになります。 ### [](#例)例 次に、エージェントがクラスターのすべての名前空間のすべての cron ジョブを制御できる Runtime Fabric エージェントの ClusterRole の例を示します。 ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric により、対応する ServiceAccount が 2 つの名前空間の cron ジョブでさまざまなアクション (動詞) を実行できるようにする ClusterRole rtf:agent を使用する必須の RoleBinding オブジェクトが作成されます。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` 認証済み名前空間モードでクラスター化アプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## [](#承認済み名前空間の設定)承認済み名前空間の設定 承認済み名前空間は、Runtime Fabric をインストールするときに設定します。適切なインストール手順を参照してください。 - [Helm を使用した EKS、AKS、GKE への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-helm) - [Red Hat OpenShift への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-openshift) ## [](#新しい名前空間の追加)新しい名前空間の追加 authorized-namespaces ConfigMap を新しい名前空間で更新する場合、次のコマンドを使用して Runtime Fabric エージェントデプロイメントを再起動する必要があります。 `kubectl rollout restart deployment/agent` # Runtime Fabric での承認済み名前空間の設定 承認済み名前空間を使用して、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできます。クラスター内の権限を制限することで、Runtime Fabric に割り当てられた名前空間内のみのリソースへのアクセスを Runtime Fabric に許可できます。 承認済み名前空間を使用すれば、次の Runtime Fabric リソースの作成を制御できます。 - 名前空間 - RoleBindings - ServiceAccounts ## [](#承認済み名前空間の仕組み)承認済み名前空間の仕組み インストール時に、名前空間、ServiceAccounts、ClusterRoles/Roles、RoleBindings で構成される設定ファイルを指定します。 Runtime Fabric により Runtime Fabric エージェント (rtf-agent) が Runtime Fabric 名前空間にインストールされ、承認済み名前空間リストで指定した追加の名前空間に Runtime Fabric がアクセスできるようになります。 ### [](#例)例 次に、エージェントがクラスターのすべての名前空間のすべての cron ジョブを制御できる Runtime Fabric エージェントの ClusterRole の例を示します。 ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric により、対応する ServiceAccount が 2 つの名前空間の cron ジョブでさまざまなアクション (動詞) を実行できるようにする ClusterRole rtf:agent を使用する必須の RoleBinding オブジェクトが作成されます。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` 認証済み名前空間モードでクラスタリングアプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## [](#承認済み名前空間の設定)承認済み名前空間の設定 承認済み名前空間は、Runtime Fabric をインストールするときに設定します。適切なインストール手順を参照してください。 - [Helm を使用した EKS、AKS、GKE への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-helm) - [Red Hat OpenShift への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-openshift) ## [](#新しい名前空間の追加)新しい名前空間の追加 authorized-namespaces ConfigMap を新しい名前空間で更新する場合、次のコマンドを使用して Runtime Fabric エージェントデプロイメントを再起動する必要があります。 `kubectl rollout restart deployment/agent` # Runtime Fabric での承認済み名前空間の設定 承認済み名前空間を使用して、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできます。クラスター内の権限を制限することで、Runtime Fabric に割り当てられた名前空間内のみのリソースへのアクセスを Runtime Fabric に許可できます。 承認済み名前空間を使用すれば、次の Runtime Fabric リソースの作成を制御できます。 - 名前空間 - RoleBindings - ServiceAccounts ## [](#承認済み名前空間の仕組み)承認済み名前空間の仕組み インストール時に、名前空間、ServiceAccounts、ClusterRoles/Roles、RoleBindings で構成される設定ファイルを指定します。 Runtime Fabric により Runtime Fabric エージェント (rtf-agent) が Runtime Fabric 名前空間にインストールされ、承認済み名前空間リストで指定した追加の名前空間に Runtime Fabric がアクセスできるようになります。 ### [](#例)例 次に、エージェントがクラスターのすべての名前空間のすべての cron ジョブを制御できる Runtime Fabric エージェントの ClusterRole の例を示します。 ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: rtf:agent rules: - apiGroups: - batch resources: - cronjobs verbs: - create - delete - deletecollection - get - list - patch - update - watch ``` Runtime Fabric により、対応する ServiceAccount が 2 つの名前空間の cron ジョブでさまざまなアクション (動詞) を実行できるようにする ClusterRole rtf:agent を使用する必須の RoleBinding オブジェクトが作成されます。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-1 namespace: namespace1 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf:agent-2 namespace: namespace2 roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: rtf:agent subjects: - kind: ServiceAccount name: rtf-agent-sa namespace: default ``` 認証済み名前空間モードでクラスタリングアプリケーションを使用するには、次の RoleBinding を作成する必要があります。 ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf-mule-clusterip-service namespace: subjects: - kind: ServiceAccount name: mule-clusterip-service namespace: roleRef: kind: ClusterRole name: rtf:mule-clusterip-service apiGroup: rbac.authorization.k8s.io ``` ## [](#承認済み名前空間の設定)承認済み名前空間の設定 承認済み名前空間は、Runtime Fabric をインストールするときに設定します。適切なインストール手順を参照してください。 - [Helm を使用した EKS、AKS、GKE への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm) - [Red Hat OpenShift への Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-openshift) ## [](#新しい名前空間の追加)新しい名前空間の追加 authorized-namespaces ConfigMap を新しい名前空間で更新する場合、次のコマンドを使用して Runtime Fabric エージェントデプロイメントを再起動する必要があります。 `kubectl rollout restart deployment/agent` # Runtime Fabric での永続性ゲートウェイの使用 Anypoint Runtime Fabric で提供される永続性ゲートウェイにより、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。

Mule Maven プラグインバージョン 3.5.4 以降を使用して Runtime Fabric デプロイメント用の永続的なオブジェクトストアを有効にすることもできます。
## [](#mule-アプリケーションでの永続性ゲートウェイの使用)Mule アプリケーションでの永続性ゲートウェイの使用 Anypoint Runtime Fabric で永続性ゲートウェイを設定したら、Mule Runtime Engine バージョン 4.2.1 以降にデプロイされた Mule アプリケーションで使用できるようになります。設定すると、ユーザーは Runtime Manager を使用してアプリケーションをデプロイするときに ​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択できます。詳細は、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric)​を参照してください。 Mule アプリケーションでは Object Store Connector を通じて Object Store v2 REST API を使用して永続性ゲートウェイに接続します。これにより、Mule アプリケーションを変更することなく、Anypoint Runtime Fabric と CloudHub の両方をデプロイできます。

アプリケーションを削除しても、すぐには永続データが削除されない場合があります。Runtime Fabric は 60 分ごとに永続データをクリーンアップします。
## [](#永続性ゲートウェイの制限事項)永続性ゲートウェイの制限事項 次の表に、永続性ゲートウェイによって保存されるデータに関する制限事項を示します。
Limit (制限) 説明

最大 TTL。

データが永続性ゲートウェイに保存される期間。値は 30 日に設定されます。
## [](#始める前に)始める前に 永続性ゲートウェイを有効化する前に、次の準備が整っていることを確認します。 - 永続性ゲートウェイによって保存されるデータのデータソースとなる PostgreSQL データベースを作成してある。このデータベースは ​`partition`​ キーワードが予約されていない [PostgresSQL のサポート対象バージョン](https://www.postgresql.org/support/versioning/)​と互換性がある必要があります。 - PostgreSQL ユーザーに CREATE、INSERT、SELECT、UPDATE、DELETE 権限を付与してある。

データベースへのプレーンテキスト接続のみがサポートされています。
## [](#Configure-Persistence-Gateway)永続性ゲートウェイの設定 設定中に、永続性ゲートウェイによって必要なデータベーススキーマが作成されます。その後、Runtime Fabric にデプロイされたアプリケーションが永続オブジェクトストレージを使用するように設定されると、永続性ゲートウェイによってデータベースに必要な行が書き込まれます。 永続性ゲートウェイを設定するには、クラスターが永続性データストアに接続するための Kubernetes カスタムリソースを作成する必要があります。 1. Kubernetes シークレットを作成します。 kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename'
2. データストアのカスタムリソースを作成します。 1. カスタムリソーステンプレートを ​[Kubernetes カスタムリソーステンプレート](#k8-custom-resource-template)​ から ​`custom-resource.yaml`​ という名前のファイルにコピーします。 2. `secretRef: name`​ の値が Kubernetes シークレットファイルで定義された ​`name`​ 項目に一致することを確認します。 3. 環境で必要に応じてカスタムリソーステンプレートのその他の項目を変更します。 4. `kubectl apply -f custom-resource.yaml`​ を実行します。 VM/ベアメタルの Runtime Fabric を使用している場合は、このコマンドをコントローラーノードから実行します。 3. 永続性ゲートウェイポッドのログをチェックして、データベースと通信できることを確認します。 kubectl get pods -n rtf 名前にプレフィックス ​`persistence-gateway`​ が付いたポッドを見つけます。 kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -nrtf このコマンドの出力は次のようになります。 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## [](#k8-custom-resource-template)Kubernetes カスタムリソーステンプレート 下のテンプレート例を使用して、Kubernetes カスタムリソースを作成します。このカスタムリソースにより、Kubernetes クラスターがデータストアに接続できます。 apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi 環境に基づいて次の項目を変更します。
項目 説明 デフォルト値

kind

カスタムリソースの種別。サポートされる値は ​PersistenceGateway​ のみです。

PersistenceGateway

metadata.name

このカスタムリソースの内部識別子。この項目の値は ​default​ である必要があります。

default

metadata.namespace

シークレットが適用される名前空間。サポートされる値は ​rtf​ です。

rtf

spec.objectStore.backendDriver

データストアで使用するドライバー。​postgresql​ のみがサポートされています。

postgresql

spec.objectStore.maxBackendConnectionPool

データストアに対して同時に開いている最大接続数。

20

spec.objectStore.replicas

永続性ゲートウェイのレプリカの数。

2

spec.objectStore.resources.limits.cpu

永続性ゲートウェイポッドの CPU リソースの制限。

250m

spec.objectStore.resources.limits.memory

永続性ゲートウェイポッドのメモリリソースの制限。

150Mi

spec.objectStore.resources.requests.cpu

永続性ゲートウェイポッドの CPU リソース要求。

200m

spec.objectStore.resources.requests.memory

永続性ゲートウェイポッドのメモリリソース要求。

75Mi

spec.objectStore.secretRef.name

Kubernetes シークレットファイルで定義された永続性ゲートウェイのログイン情報の名前。

persistence-gateway-creds

デフォルトの CPU、メモリ、制限の値は少数のデプロイ済み Mule アプリケーションに基づきます。環境の要求に基づいてこれらの値を変更してください。
## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) - [Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) # Runtime Fabric での永続性ゲートウェイの使用 Anypoint Runtime Fabric で提供される永続性ゲートウェイにより、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。

Mule Maven プラグインバージョン 3.5.4 以降を使用して Runtime Fabric デプロイメント用の永続的なオブジェクトストアを有効にすることもできます。
## [](#mule-アプリケーションでの永続性ゲートウェイの使用)Mule アプリケーションでの永続性ゲートウェイの使用 Anypoint Runtime Fabric で永続性ゲートウェイを設定したら、Mule Runtime Engine バージョン 4.2.1 以降にデプロイされた Mule アプリケーションで使用できるようになります。設定すると、ユーザーは Runtime Manager を使用してアプリケーションをデプロイするときに ​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択できます。詳細は、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric)​を参照してください。 Mule アプリケーションでは Object Store Connector を通じて Object Store v2 REST API を使用して永続性ゲートウェイに接続します。これにより、Mule アプリケーションを変更することなく、Anypoint Runtime Fabric と CloudHub の両方をデプロイできます。

アプリケーションを削除しても、すぐには永続データが削除されない場合があります。Runtime Fabric は 60 分ごとに永続データをクリーンアップします。
## [](#永続性ゲートウェイの制限事項)永続性ゲートウェイの制限事項 次の表に、永続性ゲートウェイによって保存されるデータに関する制限事項を示します。
Limit (制限) 説明

最大 TTL。

データが永続性ゲートウェイに保存される期間。値は 30 日に設定されます。
## [](#始める前に)始める前に 永続性ゲートウェイを有効化する前に、次の準備が整っていることを確認します。 - 永続性ゲートウェイによって保存されるデータのデータソースとなる PostgreSQL データベースを作成してある。このデータベースは ​`partition`​ キーワードが予約されていない [PostgresSQL のサポート対象バージョン](https://www.postgresql.org/support/versioning/)​と互換性がある必要があります。 - PostgreSQL ユーザーに CREATE、INSERT、SELECT、UPDATE、DELETE 権限を付与してある。

データベースへのプレーンテキスト接続のみがサポートされています。
## [](#Configure-Persistence-Gateway)永続性ゲートウェイの設定 設定中に、永続性ゲートウェイによって必要なデータベーススキーマが作成されます。その後、Runtime Fabric にデプロイされたアプリケーションが永続オブジェクトストレージを使用するように設定されると、永続性ゲートウェイによってデータベースに必要な行が書き込まれます。 永続性ゲートウェイを設定するには、クラスターが永続性データストアに接続するための Kubernetes カスタムリソースを作成する必要があります。 1. Kubernetes シークレットを作成します。 kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename'
2. データストアのカスタムリソースを作成します。 1. カスタムリソーステンプレートを ​[Kubernetes カスタムリソーステンプレート](#k8-custom-resource-template)​ から ​`custom-resource.yaml`​ という名前のファイルにコピーします。 2. `secretRef: name`​ の値が Kubernetes シークレットファイルで定義された ​`name`​ 項目に一致することを確認します。 3. 環境で必要に応じてカスタムリソーステンプレートのその他の項目を変更します。 4. `kubectl apply -f custom-resource.yaml`​ を実行します。 3. 永続性ゲートウェイポッドのログをチェックして、データベースと通信できることを確認します。 ```copy kubectl get pods -n rtf ``` 名前にプレフィックス ​`persistence-gateway`​ が付いたポッドを見つけます。 ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` このコマンドの出力は次のようになります。 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## [](#認証済みの名前空間での永続性ゲートウェイの使用)認証済みの名前空間での永続性ゲートウェイの使用 [認証済みの名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-helm#optional-configure-authorized-namespaces)​で永続性ゲートウェイを使用する場合は、新しい ​`rtf-persistence-gateway`​ サブジェクトを追加して RoleBinding を編集します。 ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## [](#k8-custom-resource-template)Kubernetes カスタムリソーステンプレート 下のテンプレート例を使用して、Kubernetes カスタムリソースを作成します。このカスタムリソースにより、Kubernetes クラスターがデータストアに接続できます。 ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` 環境に基づいて次の項目を変更します。
項目 説明 デフォルト値

kind

カスタムリソースの種別。サポートされる値は ​PersistenceGateway​ のみです。

PersistenceGateway

metadata.name

このカスタムリソースの内部識別子。この項目の値は ​default​ である必要があります。

default

metadata.namespace

シークレットが適用される名前空間。サポートされる値は ​rtf​ です。

rtf

spec.objectStore.backendDriver

データストアで使用するドライバー。​postgresql​ のみがサポートされています。

postgresql

spec.objectStore.maxBackendConnectionPool

データストアに対して同時に開いている最大接続数。

20

spec.objectStore.replicas

永続性ゲートウェイのレプリカの数。

2

spec.objectStore.resources.limits.cpu

永続性ゲートウェイポッドの CPU リソースの制限。

250m

spec.objectStore.resources.limits.memory

永続性ゲートウェイポッドのメモリリソースの制限。

150Mi

spec.objectStore.resources.requests.cpu

永続性ゲートウェイポッドの CPU リソース要求。

200m

spec.objectStore.resources.requests.memory

永続性ゲートウェイポッドのメモリリソース要求。

75Mi

spec.objectStore.secretRef.name

Kubernetes シークレットファイルで定義された永続性ゲートウェイのログイン情報の名前。

persistence-gateway-creds

デフォルトの CPU、メモリ、制限の値は少数のデプロイ済み Mule アプリケーションに基づきます。環境の要求に基づいてこれらの値を変更してください。
## [](#persistence-gateway-のアプリケーションデータ)Persistence Gateway のアプリケーションデータ Persistence Gateway は次の 2 つのテーブルを使用してアプリケーションデータを保存します。 ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ;` ``` 永続的なデータをクラスター間で移行する場合は、これらの 2 つのテーブルをソースクラスターから完全にバックアップして、移行先のデータベースで再作成してください。予期しない結果を防ぐため、両方のクラスターでこのプロセスが実行されている間は、アプリケーションをデプロイしないでください。 ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric) - [Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) # Runtime Fabric での永続性ゲートウェイの設定 Anypoint Runtime Fabric で提供される永続性ゲートウェイにより、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。

Mule Maven プラグインバージョン 3.5.4 以降を使用して Runtime Fabric デプロイメント用の永続的なオブジェクトストアを有効にすることもできます。
## [](#mule-アプリケーションでの永続性ゲートウェイの使用)Mule アプリケーションでの永続性ゲートウェイの使用 Anypoint Runtime Fabric で永続性ゲートウェイを設定したら、Mule Runtime Engine バージョン 4.2.1 以降にデプロイされた Mule アプリケーションで使用できるようになります。設定すると、ユーザーは Runtime Manager を使用してアプリケーションをデプロイするときに ​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択できます。詳細は、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric)​を参照してください。 Mule アプリケーションでは Object Store Connector を通じて Object Store v2 REST API を使用して永続性ゲートウェイに接続します。これにより、Mule アプリケーションを変更することなく、Anypoint Runtime Fabric と CloudHub の両方をデプロイできます。

アプリケーションを削除しても、すぐには永続データが削除されない場合があります。Runtime Fabric は 60 分ごとに永続データをクリーンアップします。
## [](#永続性ゲートウェイの制限事項)永続性ゲートウェイの制限事項 次の表に、永続性ゲートウェイによって保存されるデータに関する制限事項を示します。
Limit (制限) 説明

最大 TTL。

データが永続性ゲートウェイに保存される期間。値は 30 日に設定されます。
## [](#始める前に)始める前に 永続性ゲートウェイを有効化する前に、次の準備が整っていることを確認します。 - 永続性ゲートウェイによって保存されるデータのデータソースとなる PostgreSQL データベースを作成してある。このデータベースは ​`partition`​ キーワードが予約されていない [PostgresSQL のサポート対象バージョン](https://www.postgresql.org/support/versioning/)​と互換性がある必要があります。 - PostgreSQL ユーザーに CREATE、INSERT、SELECT、UPDATE、DELETE 権限を付与してある。

データベースへのプレーンテキスト接続のみがサポートされています。
## [](#Configure-Persistence-Gateway)永続性ゲートウェイの設定 設定中に、永続性ゲートウェイによって必要なデータベーススキーマが作成されます。その後、Runtime Fabric にデプロイされたアプリケーションが永続オブジェクトストレージを使用するように設定されると、永続性ゲートウェイによってデータベースに必要な行が書き込まれます。 永続性ゲートウェイを設定するには、クラスターが永続性データストアに接続するための Kubernetes カスタムリソースを作成する必要があります。 1. Kubernetes シークレットを作成します。 kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename'
2. データストアのカスタムリソースを作成します。 1. カスタムリソーステンプレートを ​[Kubernetes カスタムリソーステンプレート](#k8-custom-resource-template)​ から ​`custom-resource.yaml`​ という名前のファイルにコピーします。 2. `secretRef: name`​ の値が Kubernetes シークレットファイルで定義された ​`name`​ 項目に一致することを確認します。 3. 環境で必要に応じてカスタムリソーステンプレートのその他の項目を変更します。 4. `kubectl apply -f custom-resource.yaml`​ を実行します。 3. 永続性ゲートウェイポッドのログをチェックして、データベースと通信できることを確認します。 ```copy kubectl get pods -n rtf ``` 名前にプレフィックス ​`persistence-gateway`​ が付いたポッドを見つけます。 ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` このコマンドの出力は次のようになります。 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## [](#認証済みの名前空間での永続性ゲートウェイの使用)認証済みの名前空間での永続性ゲートウェイの使用 [認証済みの名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-helm#optional-configure-authorized-namespaces)​で永続性ゲートウェイを使用する場合は、新しい ​`rtf-persistence-gateway`​ サブジェクトを追加して RoleBinding を編集します。 ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## [](#k8-custom-resource-template)Kubernetes カスタムリソーステンプレート 下のテンプレート例を使用して、Kubernetes カスタムリソースを作成します。このカスタムリソースにより、Kubernetes クラスターがデータストアに接続できます。 ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` 環境に基づいて次の項目を変更します。
項目 説明 デフォルト値

kind

カスタムリソースの種別。サポートされる値は ​PersistenceGateway​ のみです。

PersistenceGateway

metadata.name

このカスタムリソースの内部識別子。この項目の値は ​default​ である必要があります。

default

metadata.namespace

シークレットが適用される名前空間。サポートされる値は ​rtf​ です。

rtf

spec.objectStore.backendDriver

データストアで使用するドライバー。​postgresql​ のみがサポートされています。

postgresql

spec.objectStore.maxBackendConnectionPool

データストアに対して同時に開いている最大接続数。

20

spec.objectStore.replicas

永続性ゲートウェイのレプリカの数。

2

spec.objectStore.resources.limits.cpu

永続性ゲートウェイポッドの CPU リソースの制限。

250m

spec.objectStore.resources.limits.memory

永続性ゲートウェイポッドのメモリリソースの制限。

150Mi

spec.objectStore.resources.requests.cpu

永続性ゲートウェイポッドの CPU リソース要求。

200m

spec.objectStore.resources.requests.memory

永続性ゲートウェイポッドのメモリリソース要求。

75Mi

spec.objectStore.secretRef.name

Kubernetes シークレットファイルで定義された永続性ゲートウェイのログイン情報の名前。

persistence-gateway-creds

デフォルトの CPU、メモリ、制限の値は少数のデプロイ済み Mule アプリケーションに基づきます。環境の要求に基づいてこれらの値を変更してください。
## [](#persistence-gateway-のアプリケーションデータ)Persistence Gateway のアプリケーションデータ Persistence Gateway は次の 2 つのテーブルを使用してアプリケーションデータを保存します。 ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ;` ``` 永続的なデータをクラスター間で移行する場合は、これらの 2 つのテーブルをソースクラスターから完全にバックアップして、移行先のデータベースで再作成してください。予期しない結果を防ぐため、両方のクラスターでこのプロセスが実行されている間は、アプリケーションをデプロイしないでください。 ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric) - [Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) # Runtime Fabric での永続性ゲートウェイの設定 Anypoint Runtime Fabric で提供される永続性ゲートウェイにより、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。

Mule Maven プラグインバージョン 3.5.4 以降を使用して Runtime Fabric デプロイメント用の永続的なオブジェクトストアを有効にすることもできます。
## [](#mule-アプリケーションでの永続性ゲートウェイの使用)Mule アプリケーションでの永続性ゲートウェイの使用 Anypoint Runtime Fabric で永続性ゲートウェイを設定したら、Mule Runtime Engine バージョン 4.2.1 以降にデプロイされた Mule アプリケーションで使用できるようになります。設定すると、ユーザーは Runtime Manager を使用してアプリケーションをデプロイするときに ​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択できます。詳細は、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric)​を参照してください。 Mule アプリケーションでは Object Store Connector を通じて Object Store v2 REST API を使用して永続性ゲートウェイに接続します。これにより、Mule アプリケーションを変更することなく、Anypoint Runtime Fabric と CloudHub の両方をデプロイできます。

アプリケーションを削除しても、すぐには永続データが削除されない場合があります。Runtime Fabric は 60 分ごとに永続データをクリーンアップします。
## [](#永続性ゲートウェイの制限事項)永続性ゲートウェイの制限事項 次の表に、永続性ゲートウェイによって保存されるデータに関する制限事項を示します。
Limit (制限) 説明

最大 TTL。

データが永続性ゲートウェイに保存される期間。値は 30 日に設定されます。
## [](#始める前に)始める前に 永続性ゲートウェイを有効化する前に、次の準備が整っていることを確認します。 - 永続性ゲートウェイによって保存されるデータのデータソースとなる PostgreSQL データベースを作成してある。このデータベースは ​`partition`​ キーワードが予約されていない [PostgresSQL のサポート対象バージョン](https://www.postgresql.org/support/versioning/)​と互換性がある必要があります。 - PostgreSQL ユーザーに CREATE、INSERT、SELECT、UPDATE、DELETE 権限を付与してある。

データベースへのプレーンテキスト接続のみがサポートされています。
## [](#Configure-Persistence-Gateway)永続性ゲートウェイの設定 設定中に、永続性ゲートウェイによって必要なデータベーススキーマが作成されます。その後、Runtime Fabric にデプロイされたアプリケーションが永続オブジェクトストレージを使用するように設定されると、永続性ゲートウェイによってデータベースに必要な行が書き込まれます。 永続性ゲートウェイを設定するには、クラスターが永続性データストアに接続するための Kubernetes カスタムリソースを作成する必要があります。 1. Kubernetes シークレットを作成します。 kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename'
2. データストアのカスタムリソースを作成します。 1. カスタムリソーステンプレートを ​[Kubernetes カスタムリソーステンプレート](#k8-custom-resource-template)​ から ​`custom-resource.yaml`​ という名前のファイルにコピーします。 2. `secretRef: name`​ の値が Kubernetes シークレットファイルで定義された ​`name`​ 項目に一致することを確認します。 3. 環境で必要に応じてカスタムリソーステンプレートのその他の項目を変更します。 4. `kubectl apply -f custom-resource.yaml`​ を実行します。 3. 永続性ゲートウェイポッドのログをチェックして、データベースと通信できることを確認します。 ```copy kubectl get pods -n rtf ``` 名前にプレフィックス ​`persistence-gateway`​ が付いたポッドを見つけます。 ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` このコマンドの出力は次のようになります。 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## [](#認証済みの名前空間での永続性ゲートウェイの使用)認証済みの名前空間での永続性ゲートウェイの使用 [認証済みの名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-helm#optional-configure-authorized-namespaces)​で永続性ゲートウェイを使用する場合は、新しい ​`rtf-persistence-gateway`​ サブジェクトを追加して RoleBinding を編集します。 ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## [](#k8-custom-resource-template)Kubernetes カスタムリソーステンプレート 下のテンプレート例を使用して、Kubernetes カスタムリソースを作成します。このカスタムリソースにより、Kubernetes クラスターがデータストアに接続できます。 ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` 環境に基づいて次の項目を変更します。
項目 説明 デフォルト値

kind

カスタムリソースの種別。サポートされる値は ​PersistenceGateway​ のみです。

PersistenceGateway

metadata.name

このカスタムリソースの内部識別子。この項目の値は ​default​ である必要があります。

default

metadata.namespace

シークレットが適用される名前空間。サポートされる値は ​rtf​ です。

rtf

spec.objectStore.backendDriver

データストアで使用するドライバー。​postgresql​ のみがサポートされています。

postgresql

spec.objectStore.maxBackendConnectionPool

データストアに対して同時に開いている最大接続数。

20

spec.objectStore.replicas

永続性ゲートウェイのレプリカの数。

2

spec.objectStore.resources.limits.cpu

永続性ゲートウェイポッドの CPU リソースの制限。

250m

spec.objectStore.resources.limits.memory

永続性ゲートウェイポッドのメモリリソースの制限。

150Mi

spec.objectStore.resources.requests.cpu

永続性ゲートウェイポッドの CPU リソース要求。

200m

spec.objectStore.resources.requests.memory

永続性ゲートウェイポッドのメモリリソース要求。

75Mi

spec.objectStore.secretRef.name

Kubernetes シークレットファイルで定義された永続性ゲートウェイのログイン情報の名前。

persistence-gateway-creds

デフォルトの CPU、メモリ、制限の値は少数のデプロイ済み Mule アプリケーションに基づきます。環境の要求に基づいてこれらの値を変更してください。
## [](#persistence-gateway-のアプリケーションデータ)Persistence Gateway のアプリケーションデータ Persistence Gateway は次の 2 つのテーブルを使用してアプリケーションデータを保存します。 ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ;` ``` 永続的なデータをクラスター間で移行する場合は、これらの 2 つのテーブルをソースクラスターから完全にバックアップして、移行先のデータベースで再作成してください。予期しない結果を防ぐため、両方のクラスターでこのプロセスが実行されている間は、アプリケーションをデプロイしないでください。 ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric) - [Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) # Runtime Fabric での永続性ゲートウェイの設定 Anypoint Runtime Fabric で提供される永続性ゲートウェイにより、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。

Mule Maven プラグインバージョン 3.5.4 以降を使用して Runtime Fabric デプロイメント用の永続的なオブジェクトストアを有効にすることもできます。
## [](#mule-アプリケーションでの永続性ゲートウェイの使用)Mule アプリケーションでの永続性ゲートウェイの使用 Anypoint Runtime Fabric で永続性ゲートウェイを設定したら、Mule Runtime Engine バージョン 4.2.1 以降にデプロイされた Mule アプリケーションで使用できるようになります。設定すると、ユーザーは Runtime Manager を使用してアプリケーションをデプロイするときに ​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択できます。詳細は、​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric)​を参照してください。 Mule アプリケーションでは Object Store Connector を通じて Object Store v2 REST API を使用して永続性ゲートウェイに接続します。これにより、Mule アプリケーションを変更することなく、Anypoint Runtime Fabric と CloudHub の両方をデプロイできます。

アプリケーションを削除しても、すぐには永続データが削除されない場合があります。Runtime Fabric は 60 分ごとに永続データをクリーンアップします。
## [](#永続性ゲートウェイの制限事項)永続性ゲートウェイの制限事項 次の表に、永続性ゲートウェイによって保存されるデータに関する制限事項を示します。
Limit (制限) 説明

最大 TTL。

データが永続性ゲートウェイに保存される期間。値は 30 日に設定されます。
## [](#始める前に)始める前に 永続性ゲートウェイを有効化する前に、次の準備が整っていることを確認します。 - 永続性ゲートウェイによって保存されるデータのデータソースとなる PostgreSQL データベースを作成してある。このデータベースは ​`partition`​ キーワードが予約されていない [PostgresSQL のサポート対象バージョン](https://www.postgresql.org/support/versioning/)​と互換性がある必要があります。 - PostgreSQL ユーザーに CREATE、INSERT、SELECT、UPDATE、DELETE 権限を付与してある。

データベースへのプレーンテキスト接続のみがサポートされています。
## [](#Configure-Persistence-Gateway)永続性ゲートウェイの設定 設定中に、永続性ゲートウェイによって必要なデータベーススキーマが作成されます。その後、Runtime Fabric にデプロイされたアプリケーションが永続オブジェクトストレージを使用するように設定されると、永続性ゲートウェイによってデータベースに必要な行が書き込まれます。 永続性ゲートウェイを設定するには、クラスターが永続性データストアに接続するための Kubernetes カスタムリソースを作成する必要があります。 1. Kubernetes シークレットを作成します。 kubectl create secret generic -n rtf --from-literal=persistence-gateway-creds='postgres://username:pass@host:port/databasename'
2. データストアのカスタムリソースを作成します。 1. カスタムリソーステンプレートを ​[Kubernetes カスタムリソーステンプレート](#k8-custom-resource-template)​ から ​`custom-resource.yaml`​ という名前のファイルにコピーします。 2. `secretRef: name`​ の値が Kubernetes シークレットファイルで定義された ​`name`​ 項目に一致することを確認します。 3. 環境で必要に応じてカスタムリソーステンプレートのその他の項目を変更します。 4. `kubectl apply -f custom-resource.yaml`​ を実行します。 3. 永続性ゲートウェイポッドのログをチェックして、データベースと通信できることを確認します。 ```copy kubectl get pods -n rtf ``` 名前にプレフィックス ​`persistence-gateway`​ が付いたポッドを見つけます。 ```copy kubectl logs -f persistence-gateway-6dfb98949c-7xns9 -n rtf ``` このコマンドの出力は次のようになります。 2021/04/09 16:35:31 Connecting to PostgreSQL backend... 2021/04/09 16:35:32 Starting watcher for /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:32 Watching for changes on /var/run/secrets/rtf-object-store/persistence-gateway-creds 2021/04/09 16:35:35 Successfully connected to the PostgreSQL backend. 192.168.2.101 - - \[09/Apr/2021:16:35:55 +0000\] "GET /api/v1/status/ready HTTP/1.1" 200 2 "" "kube-probe/1.18+" ## [](#認証済みの名前空間での永続性ゲートウェイの使用)認証済みの名前空間での永続性ゲートウェイの使用 [認証済みの名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm#optional-configure-authorized-namespaces)​で永続性ゲートウェイを使用する場合は、新しい ​`rtf-persistence-gateway`​ サブジェクトを追加して RoleBinding を編集します。 ```copy subjects: - kind: ServiceAccount name: rtf-persistence-gateway namespace: ``` ## [](#k8-custom-resource-template)Kubernetes カスタムリソーステンプレート 下のテンプレート例を使用して、Kubernetes カスタムリソースを作成します。このカスタムリソースにより、Kubernetes クラスターがデータストアに接続できます。 ```yaml apiVersion: rtf.mulesoft.com/v1 kind: PersistenceGateway metadata: name: default namespace: rtf spec: objectStore: backendDriver: postgresql maxBackendConnectionPool: 20 replicas: 2 secretRef: name: persistence-gateway-creds resources: limits: cpu: 250m memory: 250Mi requests: cpu: 200m memory: 75Mi ``` 環境に基づいて次の項目を変更します。
項目 説明 デフォルト値

kind

カスタムリソースの種別。サポートされる値は ​PersistenceGateway​ のみです。

PersistenceGateway

metadata.name

このカスタムリソースの内部識別子。この項目の値は ​default​ である必要があります。

default

metadata.namespace

シークレットが適用される名前空間。サポートされる値は ​rtf​ です。

rtf

spec.objectStore.backendDriver

データストアで使用するドライバー。​postgresql​ のみがサポートされています。

postgresql

spec.objectStore.maxBackendConnectionPool

データストアに対して同時に開いている最大接続数。

20

spec.objectStore.replicas

永続性ゲートウェイのレプリカの数。

2

spec.objectStore.resources.limits.cpu

永続性ゲートウェイポッドの CPU リソースの制限。

250m

spec.objectStore.resources.limits.memory

永続性ゲートウェイポッドのメモリリソースの制限。

150Mi

spec.objectStore.resources.requests.cpu

永続性ゲートウェイポッドの CPU リソース要求。

200m

spec.objectStore.resources.requests.memory

永続性ゲートウェイポッドのメモリリソース要求。

75Mi

spec.objectStore.secretRef.name

Kubernetes シークレットファイルで定義された永続性ゲートウェイのログイン情報の名前。

persistence-gateway-creds

デフォルトの CPU、メモリ、制限の値は少数のデプロイ済み Mule アプリケーションに基づきます。環境の要求に基づいてこれらの値を変更してください。
## [](#persistence-gateway-のアプリケーションデータ)Persistence Gateway のアプリケーションデータ Persistence Gateway は次の 2 つのテーブルを使用してアプリケーションデータを保存します。 ```copy CREATE TABLE IF NOT EXISTS stores ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL, org_id VARCHAR(255) NOT NULL, env_id VARCHAR(255) NOT NULL, default_ttl_seconds int NOT NULL, is_fixed_ttl bool NOT NULL, CONSTRAINT UK_stores UNIQUE (name, org_id, env_id) ); CREATE TABLE IF NOT EXISTS items ( id SERIAL PRIMARY KEY, store_id INT NOT NULL REFERENCES stores(id), key VARCHAR(255) NOT NULL, partition VARCHAR(255) NOT NULL, value_type VARCHAR(10) NOT NULL, number_value integer, string_value text, binary_value bytea, last_updated timestamp, is_fixed_ttl bool NOT NULL, ttl timestamp NOT NULL, CONSTRAINT UK_items UNIQUE (key, store_id, partition) ); CREATE INDEX IF NOT EXISTS IDX_items_ttl ON items(ttl) ;` ``` 永続的なデータをクラスター間で移行する場合は、これらの 2 つのテーブルをソースクラスターから完全にバックアップして、移行先のデータベースで再作成してください。予期しない結果を防ぐため、両方のクラスターでこのプロセスが実行されている間は、アプリケーションをデプロイしないでください。 ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) - [Mule Maven プラグインを使用した Runtime Fabric へのアプリケーションのデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) # Runtime Fabric デプロイメントの水平ポッド自動スケーリング (HPA) の設定 Runtime Fabric インスタンスでは、CPU 使用量をシグナルとして、それに応じて追加レプリカの作成や不要なレプリカの削除を行うことで、Mule アプリケーションデプロイメントの水平スケーリングをサポートしています。 MuleSoft は Kubernetes (K8s) ランタイム側の CPU 使用量に反応する Mule アプリケーションの設定をサポートしています。Runtime Manager アプリケーションデプロイメントページで、CPU ベースの水平自動スケーリングを有効にできます。これにより、必要に応じてデプロイメントレプリカが自動的にスケールアップまたはスケールダウンされます。 Kubernetes では、水平ポッド自動スケーリング (HPA) により、需要に合わせてワークロードを自動的にスケーリングするために、ワークロードリソースが自動的に更新されます。水平スケーリングとは、負荷の増加に対応してより多くのポッドをデプロイするという意味です。
HPA は Runtime Fabric エージェントバージョン 2.6.22 以降でのみサポートされています。
この機能の対象は、新しい価格設定およびパッケージモデルにオプトインしている一部のお客様のみです。詳細は、[Anypoint Platform 価格設定](https://docs.mulesoft.com/jp/general/pricing)を参照してください。 ## [](#始める前に)始める前に 自動スケーリングを設定するには、クラスター管理者は、管理対象の K8s API サーバー上で [メトリクス API のサポート](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)​を有効にする必要があります。 メトリクス API サーバーをインストールまたは有効化する方法は、管理対象のベンダードキュメントを参照してください。 ## [](#クラスター自動スケーリングの推奨事項)クラスター自動スケーリングの推奨事項 次の推奨事項は、クラスターの自動スケーリングを設定するインフラストラクチャチーム向けのものです。 ### [](#ノードグループの設定)ノードグループの設定 可用性ゾーンごとに 1 つのノードグループを設定し、ノードグループには 1 つ以上のノードを含めます。 これにより、Kubernetes がクラスター内のすべての可用性ゾーンの情報を持ち、ゾーントポロジーのスケジュール不可ポッドがスケールアウト topologySpread predicate チェックに失敗するという問題を避けることができます。 すべてのノードグループのノードの表示ラベルが全く同じであることを確認します。ただし、一般表示ラベルと固有のクラウドプロバイダー表示ラベルは例外で、デフォルトでノードや可用性ゾーン間で異なります。 ノード間で異なるカスタム表示ラベル (一般表示ラベルまたは固有のクラウドプロバイダー表示ラベルではない) は類似するノードグループを評価するときにクラスター自動スケーラーから除外する必要があります。 次のような管理 EKS 表示ラベルでの参照 eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### [](#クラスター自動スケーラーフラグの設定)クラスター自動スケーラーフラグの設定 フラグ ​`--balance-similar-node-groups=true`​ を使用してクラスター自動スケーラーを起動し、フラグ ​`--balancing-ignore-label`​ を使用してノードグループセクション内の前述したカスタム表示ラベルを除外します。 これらのフラグを使用することで、クラスター自動スケーラーは可用性ゾーン間のノード数のバランスを取ります。 管理 EKS クラスターでの参照では、次のノード表示ラベルはノードグループ間で異なります。 k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig そのため、クラスター自動スケーラーの起動時に次のように指定します。 \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig このような設定の推奨事項はガイドラインとして使用できます。ただし、クラスター自動スケーラー (CA) の実際の設定は使用するクラウドまたはインフラストラクチャのプロバイダー (ベンダー) や関連するトポロジーの考慮事項によって異なります。CA を適切に設定する必要があります。 ### [](#オーバープロビジョニングノードの設定)オーバープロビジョニングノードの設定 可用性ゾーンごとに 1 つ以上のオーバープロビジョニングノードを設定します。各オーバープロビジョニングノードは 1 つのリソースを保持し、リソースは 3 つの Mule アプリケーションに対応できます。これにより、新しいノードが必要な場合のパフォーマンスが向上します。
クラスター自動スケーリングのベストプラクティスとオーバープロビジョニング設定についての詳細は、管理対象のベンダードキュメントを参照してください。
### [](#トポロジー拡散制約の設定)トポロジー拡散制約の設定 自動スケーリングによって有効になった Mule アプリケーションデプロイメントでは、ポッド仕様内で ​**whenUnsatisfiable**​ 項目を ​`DoNotSchedule`​ に更新することによって、トポロジー拡散制約のために Kubernetes リソースをカスタマイズする必要があります。 この設定により、高可用性のために自動スケーリングレプリカがゾーン間に均等に拡散されます。 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" `whenUnsatisfiable: DoNotSchedule`​ を使用すると、ポッドが可用性ゾーン間に均等に拡散されることが保証されます。この設定を変更するには、K8S テンプレート CRD を使用し、HPA を使用しているデプロイメントを ​`whenUnsatisfiable: DoNotSchedule`​ にします。また、専用の名前空間 (環境) を使用して、自動スケーリングのワークロードを従来のものと分離することもできます。この変更を行わない場合は、​`whenUnsatisfiable: ScheduleAnyway`​ を使用します。 設定についての詳細は、[Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/customize-kubernetes-crd)ドキュメントを参照してください。
可用性ゾーンあたりのノードグループ、クラスター自動スケーラー、オーバープロビジョニングの推奨される設定を使用せずに ​whenUnsatisfiable: DoNotSchedule​ を使用してトポロジー拡散をカスタマイズすると、​待機中状態​エラーが発生し、K8s がレプリカのスケジュールに失敗することがあります。
### [](#cpu-ベースの自動スケーリングポリシーの理解)CPU ベースの自動スケーリングポリシーの理解 MuleSoft は、お客様の Mule アプリケーションデプロイメントの [自動スケーリング](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​ポリシーを所有し、適用します。 次の例は、Runtime Fabric インスタンスにデプロイされた Mule アプリケーションに使用される CPU ベースの HPA ポリシーを示しています。​`minReplicas`​ 値と ​`maxReplicas`​ 値は Runtime Manager インターフェースから選択できます。 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app 考慮すべき点をいくつか挙げます。 スケールアップは最長 180 秒おきに実行されます。各期間に、設定された最大レプリカ数に達するまで、現在実行中のレプリカの最大 100% を追加できます。スケールアップの場合は安定化期間はありません。対象をスケールアップする必要があることをメトリクスが示すと、対象はすぐにスケールアップされます。 スケールダウンは最長 15 秒おきに実行されます。各期間に、現在実行中のレプリカの最大 100% を削除できます。つまり、スケーリング対象は許容される最小レプリカ数までスケールダウンできます。削除されるレプリカ数は、過去 1800 秒間の安定化期間に集計された計算に基づきます。 最小レプリカ数 - 任意の時点で実行が保証されるレプリカの最小数。 - スケールダウンポリシーによって、この数を下回るまでレプリカが削除されることはありません。 最大レプリカ数 - スケールアップでそれ以上はレプリカが追加されない上限となるレプリカの最大数。 - スケールアップポリシーによってこの数を超えてレプリカが追加されることはありません。 HPA を有効にすると、アプリケーションが水平にスケーリングされるときにお客様に追加のフロー使用量が発生することがあります。予期しないスケーリングによる超過を避けるため、購入したフロー制限内に収まるように最大レプリカ数は慎重に設定してください。発生したフロー使用量は​[使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports)​で追跡できます。 HPA の CPU 使用率は平均 70% です。 HPA は [リソース要求](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work)​に基づいています。 When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. 期間内 (スケールアップの期間は 180 秒に設定されています) のポッドの平均使用率が 70% より高い場合、HPA はスケールアップします。詳細は Kubernetes のドキュメントを参照してください。 ## [](#パフォーマンスに関する考慮事項と制限事項)パフォーマンスに関する考慮事項と制限事項 Mule アプリケーションの水平自動スケーリングを成功させるために、パフォーマンスに関する次の考慮事項を確認してください。 - Runtime Fabric で、使用されるポリシーが Mule アプリケーションに対して評価され、予約済み CPU: 0.45vCpu、vCPU 制限: 0.55vCpu となりました。これは次の設定に対応します。 resources: limits: cpu: 550m requests: cpu: 450m - CPU 使用量に基づいてスケーリングされる Mule アプリケーションは CPU ベースの HPA に適しています。次に例を示します。 - 非同期要求を使用する HTTP/HTTPS - リバースプロキシ - 低レイテンシー + 高スループットのアプリケーション - DataWeave 変換 - APIkit ルーティング - ポリシーを使用する API ゲートウェイ - バッチジョブなどの並列処理が組み込まれていない非リエントラントアプリケーション、リエントランシーやアプリケーション間の重複スケジューリングがないスケジューラーアプリケーション、大きな要求を使用する低スループット高レイテンシーアプリケーションなどは、CPU ベースの HPA に適していません。 - スケールアップとスケールダウンのパフォーマンスはレプリカサイズとアプリケーション種別に応じて異なります。 - ポリシーは 850m より小さいレプリカサイズに対して最適化されています。レプリカサイズがそれよりも大きい場合は、スケーリングに時間がかかる可能性があります。HPA は、平均使用量が 0.2vCPU の小さな CPU アプリケーションにのみお勧めします。 ### [](#制限事項)制限事項 次の制限事項を考慮してください。 - CPU は水平自動スケーリングの唯一のリソースです。 ## [](#水平ポッド自動スケーリングの設定)水平ポッド自動スケーリングの設定 Runtime Fabric にデプロイされた Mule アプリケーションの水平自動スケーリングを設定する手順は次のとおりです。 1. 管理対象の K8s API サーバー上で [メトリクス API のサポート](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)​を有効にします。 2. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Runtime (ランタイム)\]**​ タブで、​**\[Enable Autoscaling (自動スケーリングを有効化)\]**​ ボックスをオンにします。 5. 最小と最大の ​**\[Replica Count (レプリカ数)\]**​ を設定します。 6. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ![「Enable Autoscaling (自動スケーリングを有効化)」 項目がオンになっている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-autoscaling.png) ## [](#自動スケーリングの状況とログ)自動スケーリングの状況とログ 自動スケーリングイベントが発生し、水平自動スケーリングを設定している Mule アプリケーションがスケールアップされたら、Runtime Manager UI のアプリケーションの詳細ウィンドウで ​**\[View status (状況を表示)\]**​ をクリックして、​**\[Scaling (スケーリング)\]**​ 状況を確認できます。 ![Mule アプリケーションとスケーリング状況が表示されている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-hpa-rtm.png) また、アクセス管理の ​**\[Audit logs (監査ログ)\]**​ では、自動スケーリングイベントがいつ発生したかを追跡できます。アプリケーションデプロイメントのスケーリングが発生するたびに、製品 ​**\[Runtime Manager\]**​ の下に ​**\[Anypoint Staff\]**​ ユーザーによる監査ログがパブリッシュされます。このログでは、​**\[Action (アクション)\]**​ は ​`[Scaling (スケーリング)]`​ に設定され、​**\[Object (オブジェクト)\]**​ はアプリケーション ID に設定されています。 ![監査ログとスケーリング状況が表示されている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-hpa-rtm-2.png) 次に、ログペイロードの例を示します。 ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` さらに、ターミナルで次の ​`kubectl`​ コマンドを実行することで、スケールアップされたレプリカの起動と Mule アプリケーションのレプリカ数を追跡できます。 ```console kubectl get events | grep HorizontalPodAutoscaler ``` クラスター内で発生したイベントを取得するには、Kubernetes で ​`kubectl get events`​ コマンドを使用します。このコマンドを実行すると、ポッドの作成、削除、その他の重要なイベントなど、クラスター内で実行されるさまざまなアクティビティや変更に関する情報が表示されます。 `grep`​ コマンドを使用すると、​`kubectl get events`​ の出力を文字列 ​`HorizontalPodAutoscaler`​ を含む行に絞り込むことができます。次の例は、​`HorizontalPodAutoscaler`​ に関するイベントを含むコマンド出力を示しています。HPA によってトリガーされた再スケーリング操作の成功に関する情報が表示されています。 ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` # Runtime Fabric デプロイメントの水平ポッド自動スケーリング (HPA) の設定 Runtime Fabric インスタンスでは、CPU 使用量をシグナルとして、それに応じて追加レプリカの作成や不要なレプリカの削除を行うことで、Mule アプリケーションデプロイメントの水平スケーリングをサポートしています。 MuleSoft は Kubernetes (K8s) ランタイム側の CPU 使用量に反応する Mule アプリケーションの設定をサポートしています。Runtime Manager アプリケーションデプロイメントページで、CPU ベースの水平自動スケーリングを有効にできます。これにより、必要に応じてデプロイメントレプリカが自動的にスケールアップまたはスケールダウンされます。 Kubernetes では、水平ポッド自動スケーリング (HPA) により、需要に合わせてワークロードを自動的にスケーリングするために、ワークロードリソースが自動的に更新されます。水平スケーリングとは、負荷の増加に対応してより多くのポッドをデプロイするという意味です。
HPA は Runtime Fabric エージェントバージョン 2.6.22 以降でのみサポートされています。
この機能の対象は、新しい価格設定およびパッケージモデルにオプトインしている一部のお客様のみです。詳細は、[Anypoint Platform 価格設定](https://docs.mulesoft.com/jp/general/pricing)を参照してください。 ## [](#始める前に)始める前に 自動スケーリングを設定するには、クラスター管理者は、管理対象の K8s API サーバー上で [メトリクス API のサポート](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)​を有効にする必要があります。 メトリクス API サーバーをインストールまたは有効化する方法は、管理対象のベンダードキュメントを参照してください。 ## [](#クラスター自動スケーリングの推奨事項)クラスター自動スケーリングの推奨事項 次の推奨事項は、クラスターの自動スケーリングを設定するインフラストラクチャチーム向けのものです。 ### [](#ノードグループの設定)ノードグループの設定 可用性ゾーンごとに 1 つのノードグループを設定し、ノードグループには 1 つ以上のノードを含めます。 これにより、Kubernetes がクラスター内のすべての可用性ゾーンの情報を持ち、ゾーントポロジーのスケジュール不可ポッドがスケールアウト topologySpread predicate チェックに失敗するという問題を避けることができます。 すべてのノードグループのノードの表示ラベルが全く同じであることを確認します。ただし、一般表示ラベルと固有のクラウドプロバイダー表示ラベルは例外で、デフォルトでノードや可用性ゾーン間で異なります。 ノード間で異なるカスタム表示ラベル (一般表示ラベルまたは固有のクラウドプロバイダー表示ラベルではない) は類似するノードグループを評価するときにクラスター自動スケーラーから除外する必要があります。 次のような管理 EKS 表示ラベルでの参照 eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### [](#クラスター自動スケーラーフラグの設定)クラスター自動スケーラーフラグの設定 フラグ ​`--balance-similar-node-groups=true`​ を使用してクラスター自動スケーラーを起動し、フラグ ​`--balancing-ignore-label`​ を使用してノードグループセクション内の前述したカスタム表示ラベルを除外します。 これらのフラグを使用することで、クラスター自動スケーラーは可用性ゾーン間のノード数のバランスを取ります。 管理 EKS クラスターでの参照では、次のノード表示ラベルはノードグループ間で異なります。 k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig そのため、クラスター自動スケーラーの起動時に次のように指定します。 \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig このような設定の推奨事項はガイドラインとして使用できます。ただし、クラスター自動スケーラー (CA) の実際の設定は使用するクラウドまたはインフラストラクチャのプロバイダー (ベンダー) や関連するトポロジーの考慮事項によって異なります。CA を適切に設定する必要があります。 ### [](#オーバープロビジョニングノードの設定)オーバープロビジョニングノードの設定 可用性ゾーンごとに 1 つ以上のオーバープロビジョニングノードを設定します。各オーバープロビジョニングノードは 1 つのリソースを保持し、リソースは 3 つの Mule アプリケーションに対応できます。これにより、新しいノードが必要な場合のパフォーマンスが向上します。
クラスター自動スケーリングのベストプラクティスとオーバープロビジョニング設定についての詳細は、管理対象のベンダードキュメントを参照してください。
### [](#トポロジー拡散制約の設定)トポロジー拡散制約の設定 自動スケーリングによって有効になった Mule アプリケーションデプロイメントでは、ポッド仕様内で ​**whenUnsatisfiable**​ 項目を ​`DoNotSchedule`​ に更新することによって、トポロジー拡散制約のために Kubernetes リソースをカスタマイズする必要があります。 この設定により、高可用性のために自動スケーリングレプリカがゾーン間に均等に拡散されます。 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" `whenUnsatisfiable: DoNotSchedule`​ を使用すると、ポッドが可用性ゾーン間に均等に拡散されることが保証されます。この設定を変更するには、K8S テンプレート CRD を使用し、HPA を使用しているデプロイメントを ​`whenUnsatisfiable: DoNotSchedule`​ にします。また、専用の名前空間 (環境) を使用して、自動スケーリングのワークロードを従来のものと分離することもできます。この変更を行わない場合は、​`whenUnsatisfiable: ScheduleAnyway`​ を使用します。 設定についての詳細は、[Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/customize-kubernetes-crd)ドキュメントを参照してください。
可用性ゾーンあたりのノードグループ、クラスター自動スケーラー、オーバープロビジョニングの推奨される設定を使用せずに ​whenUnsatisfiable: DoNotSchedule​ を使用してトポロジー拡散をカスタマイズすると、​待機中状態​エラーが発生し、K8s がレプリカのスケジュールに失敗することがあります。
### [](#cpu-ベースの自動スケーリングポリシーの理解)CPU ベースの自動スケーリングポリシーの理解 MuleSoft は、お客様の Mule アプリケーションデプロイメントの [自動スケーリング](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​ポリシーを所有し、適用します。 次の例は、Runtime Fabric インスタンスにデプロイされた Mule アプリケーションに使用される CPU ベースの HPA ポリシーを示しています。​`minReplicas`​ 値と ​`maxReplicas`​ 値は Runtime Manager インターフェースから選択できます。 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app 考慮すべき点をいくつか挙げます。 スケールアップは最長 180 秒おきに実行されます。各期間に、設定された最大レプリカ数に達するまで、現在実行中のレプリカの最大 100% を追加できます。スケールアップの場合は安定化期間はありません。対象をスケールアップする必要があることをメトリクスが示すと、対象はすぐにスケールアップされます。 スケールダウンは最長 15 秒おきに実行されます。各期間に、現在実行中のレプリカの最大 100% を削除できます。つまり、スケーリング対象は許容される最小レプリカ数までスケールダウンできます。削除されるレプリカ数は、過去 1800 秒間の安定化期間に集計された計算に基づきます。 最小レプリカ数 - 任意の時点で実行が保証されるレプリカの最小数。 - スケールダウンポリシーによって、この数を下回るまでレプリカが削除されることはありません。 最大レプリカ数 - スケールアップでそれ以上はレプリカが追加されない上限となるレプリカの最大数。 - スケールアップポリシーによってこの数を超えてレプリカが追加されることはありません。 HPA を有効にすると、アプリケーションが水平にスケーリングされるときにお客様に追加のフロー使用量が発生することがあります。予期しないスケーリングによる超過を避けるため、購入したフロー制限内に収まるように最大レプリカ数は慎重に設定してください。発生したフロー使用量は​[使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports)​で追跡できます。 HPA の CPU 使用率は平均 70% です。 HPA は [リソース要求](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work)​に基づいています。 When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. 期間内 (スケールアップの期間は 180 秒に設定されています) のポッドの平均使用率が 70% より高い場合、HPA はスケールアップします。詳細は Kubernetes のドキュメントを参照してください。 ## [](#パフォーマンスに関する考慮事項と制限事項)パフォーマンスに関する考慮事項と制限事項 Mule アプリケーションの水平自動スケーリングを成功させるために、パフォーマンスに関する次の考慮事項を確認してください。 - Runtime Fabric で、使用されるポリシーが Mule アプリケーションに対して評価され、予約済み CPU: 0.45vCpu、vCPU 制限: 0.55vCpu となりました。これは次の設定に対応します。 resources: limits: cpu: 550m requests: cpu: 450m - CPU 使用量に基づいてスケーリングされる Mule アプリケーションは CPU ベースの HPA に適しています。次に例を示します。 - 非同期要求を使用する HTTP/HTTPS - リバースプロキシ - 低レイテンシー + 高スループットのアプリケーション - DataWeave 変換 - APIkit ルーティング - ポリシーを使用する API ゲートウェイ - バッチジョブなどの並列処理が組み込まれていない非リエントラントアプリケーション、リエントランシーやアプリケーション間の重複スケジューリングがないスケジューラーアプリケーション、大きな要求を使用する低スループット高レイテンシーアプリケーションなどは、CPU ベースの HPA に適していません。 - スケールアップとスケールダウンのパフォーマンスはレプリカサイズとアプリケーション種別に応じて異なります。 - ポリシーは 850m より小さいレプリカサイズに対して最適化されています。レプリカサイズがそれよりも大きい場合は、スケーリングに時間がかかる可能性があります。HPA は、平均使用量が 0.2vCPU の小さな CPU アプリケーションにのみお勧めします。 ### [](#制限事項)制限事項 次の制限事項を考慮してください。 - CPU は水平自動スケーリングの唯一のリソースです。 ## [](#水平ポッド自動スケーリングの設定)水平ポッド自動スケーリングの設定 Runtime Fabric にデプロイされた Mule アプリケーションの水平自動スケーリングを設定する手順は次のとおりです。 1. 管理対象の K8s API サーバー上で [メトリクス API のサポート](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)​を有効にします。 2. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Runtime (ランタイム)\]**​ タブで、​**\[Enable Autoscaling (自動スケーリングを有効化)\]**​ ボックスをオンにします。 5. 最小と最大の ​**\[Replica Count (レプリカ数)\]**​ を設定します。 6. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ![「Enable Autoscaling (自動スケーリングを有効化)」 項目がオンになっている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-autoscaling.png) ## [](#自動スケーリングの状況とログ)自動スケーリングの状況とログ 自動スケーリングイベントが発生し、水平自動スケーリングを設定している Mule アプリケーションがスケールアップされたら、Runtime Manager UI のアプリケーションの詳細ウィンドウで ​**\[View status (状況を表示)\]**​ をクリックして、​**\[Scaling (スケーリング)\]**​ 状況を確認できます。 ![Mule アプリケーションとスケーリング状況が表示されている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-hpa-rtm.png) また、アクセス管理の ​**\[Audit logs (監査ログ)\]**​ では、自動スケーリングイベントがいつ発生したかを追跡できます。アプリケーションデプロイメントのスケーリングが発生するたびに、製品 ​**\[Runtime Manager\]**​ の下に ​**\[Anypoint Staff\]**​ ユーザーによる監査ログがパブリッシュされます。このログでは、​**\[Action (アクション)\]**​ は ​`[Scaling (スケーリング)]`​ に設定され、​**\[Object (オブジェクト)\]**​ はアプリケーション ID に設定されています。 ![監査ログとスケーリング状況が表示されている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-hpa-rtm-2.png) 次に、ログペイロードの例を示します。 ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` さらに、ターミナルで次の ​`kubectl`​ コマンドを実行することで、スケールアップされたレプリカの起動と Mule アプリケーションのレプリカ数を追跡できます。 ```console kubectl get events | grep HorizontalPodAutoscaler ``` クラスター内で発生したイベントを取得するには、Kubernetes で ​`kubectl get events`​ コマンドを使用します。このコマンドを実行すると、ポッドの作成、削除、その他の重要なイベントなど、クラスター内で実行されるさまざまなアクティビティや変更に関する情報が表示されます。 `grep`​ コマンドを使用すると、​`kubectl get events`​ の出力を文字列 ​`HorizontalPodAutoscaler`​ を含む行に絞り込むことができます。次の例は、​`HorizontalPodAutoscaler`​ に関するイベントを含むコマンド出力を示しています。HPA によってトリガーされた再スケーリング操作の成功に関する情報が表示されています。 ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` # Runtime Fabric デプロイメントの水平ポッド自動スケーリング (HPA) の設定 Runtime Fabric インスタンスでは、CPU 使用量をシグナルとして、それに応じて追加レプリカの作成や不要なレプリカの削除を行うことで、Mule アプリケーションデプロイメントの水平スケーリングをサポートしています。 MuleSoft は Kubernetes (K8s) ランタイム側の CPU 使用量に反応する Mule アプリケーションの設定をサポートしています。Runtime Manager アプリケーションデプロイメントページで、CPU ベースの水平自動スケーリングを有効にできます。これにより、必要に応じてデプロイメントレプリカが自動的にスケールアップまたはスケールダウンされます。 Kubernetes では、水平ポッド自動スケーリング (HPA) により、需要に合わせてワークロードを自動的にスケーリングするために、ワークロードリソースが自動的に更新されます。水平スケーリングとは、負荷の増加に対応してより多くのポッドをデプロイするという意味です。
HPA は Runtime Fabric エージェントバージョン 2.6.22 以降でのみサポートされています。
この機能の対象は、新しい価格設定およびパッケージモデルにオプトインしている一部のお客様のみです。詳細は、[Anypoint Platform 価格設定](https://docs.mulesoft.com/jp/general/pricing)を参照してください。 ## [](#始める前に)始める前に 自動スケーリングを設定するには、クラスター管理者は、管理対象の K8s API サーバー上で [メトリクス API のサポート](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)​を有効にする必要があります。 メトリクス API サーバーをインストールまたは有効化する方法は、管理対象のベンダードキュメントを参照してください。 ## [](#クラスター自動スケーリングの推奨事項)クラスター自動スケーリングの推奨事項 次の推奨事項は、クラスターの自動スケーリングを設定するインフラストラクチャチーム向けのものです。 ### [](#ノードグループの設定)ノードグループの設定 可用性ゾーンごとに 1 つのノードグループを設定し、ノードグループには 1 つ以上のノードを含めます。 これにより、Kubernetes がクラスター内のすべての可用性ゾーンの情報を持ち、ゾーントポロジーのスケジュール不可ポッドがスケールアウト topologySpread predicate チェックに失敗するという問題を避けることができます。 すべてのノードグループのノードの表示ラベルが全く同じであることを確認します。ただし、一般表示ラベルと固有のクラウドプロバイダー表示ラベルは例外で、デフォルトでノードや可用性ゾーン間で異なります。 ノード間で異なるカスタム表示ラベル (一般表示ラベルまたは固有のクラウドプロバイダー表示ラベルではない) は類似するノードグループを評価するときにクラスター自動スケーラーから除外する必要があります。 次のような管理 EKS 表示ラベルでの参照 eks.amazonaws.com/nodegroup failure-domain.beta.kubernetes.io/region failure-domain.beta.kubernetes.io/zone kubernetes.io/hostname topology.kubernetes.io/region topology.kubernetes.io/zone ### [](#クラスター自動スケーラーフラグの設定)クラスター自動スケーラーフラグの設定 フラグ ​`--balance-similar-node-groups=true`​ を使用してクラスター自動スケーラーを起動し、フラグ ​`--balancing-ignore-label`​ を使用してノードグループセクション内の前述したカスタム表示ラベルを除外します。 これらのフラグを使用することで、クラスター自動スケーラーは可用性ゾーン間のノード数のバランスを取ります。 管理 EKS クラスターでの参照では、次のノード表示ラベルはノードグループ間で異なります。 k8s.amazonaws.com/eniConfigCustom vpc.amazonaws.com/eniConfig そのため、クラスター自動スケーラーの起動時に次のように指定します。 \- --balancing-ignore-label=k8s.amazonaws.com/eniConfigCustom - --balancing-ignore-label=vpc.amazonaws.com/eniConfig このような設定の推奨事項はガイドラインとして使用できます。ただし、クラスター自動スケーラー (CA) の実際の設定は使用するクラウドまたはインフラストラクチャのプロバイダー (ベンダー) や関連するトポロジーの考慮事項によって異なります。CA を適切に設定する必要があります。 ### [](#オーバープロビジョニングノードの設定)オーバープロビジョニングノードの設定 可用性ゾーンごとに 1 つ以上のオーバープロビジョニングノードを設定します。各オーバープロビジョニングノードは 1 つのリソースを保持し、リソースは 3 つの Mule アプリケーションに対応できます。これにより、新しいノードが必要な場合のパフォーマンスが向上します。
クラスター自動スケーリングのベストプラクティスとオーバープロビジョニング設定についての詳細は、管理対象のベンダードキュメントを参照してください。
### [](#トポロジー拡散制約の設定)トポロジー拡散制約の設定 自動スケーリングによって有効になった Mule アプリケーションデプロイメントでは、ポッド仕様内で ​**whenUnsatisfiable**​ 項目を ​`DoNotSchedule`​ に更新することによって、トポロジー拡散制約のために Kubernetes リソースをカスタマイズする必要があります。 この設定により、高可用性のために自動スケーリングレプリカがゾーン間に均等に拡散されます。 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: rtf.mulesoft.com/id: "{{ .Values.id }}" `whenUnsatisfiable: DoNotSchedule`​ を使用すると、ポッドが可用性ゾーン間に均等に拡散されることが保証されます。この設定を変更するには、K8S テンプレート CRD を使用し、HPA を使用しているデプロイメントを ​`whenUnsatisfiable: DoNotSchedule`​ にします。また、専用の名前空間 (環境) を使用して、自動スケーリングのワークロードを従来のものと分離することもできます。この変更を行わない場合は、​`whenUnsatisfiable: ScheduleAnyway`​ を使用します。 設定についての詳細は、[Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/customize-kubernetes-crd)ドキュメントを参照してください。
可用性ゾーンあたりのノードグループ、クラスター自動スケーラー、オーバープロビジョニングの推奨される設定を使用せずに ​whenUnsatisfiable: DoNotSchedule​ を使用してトポロジー拡散をカスタマイズすると、​待機中状態​エラーが発生し、K8s がレプリカのスケジュールに失敗することがあります。
### [](#cpu-ベースの自動スケーリングポリシーの理解)CPU ベースの自動スケーリングポリシーの理解 MuleSoft は、お客様の Mule アプリケーションデプロイメントの [自動スケーリング](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​ポリシーを所有し、適用します。 次の例は、Runtime Fabric インスタンスにデプロイされた Mule アプリケーションに使用される CPU ベースの HPA ポリシーを示しています。​`minReplicas`​ 値と ​`maxReplicas`​ 値は Runtime Manager インターフェースから選択できます。 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-app namespace: app-namespace spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 1800 scaleUp: policies: - periodSeconds: 180 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 maxReplicas: metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app 考慮すべき点をいくつか挙げます。 スケールアップは最長 180 秒おきに実行されます。各期間に、設定された最大レプリカ数に達するまで、現在実行中のレプリカの最大 100% を追加できます。スケールアップの場合は安定化期間はありません。対象をスケールアップする必要があることをメトリクスが示すと、対象はすぐにスケールアップされます。 スケールダウンは最長 15 秒おきに実行されます。各期間に、現在実行中のレプリカの最大 100% を削除できます。つまり、スケーリング対象は許容される最小レプリカ数までスケールダウンできます。削除されるレプリカ数は、過去 1800 秒間の安定化期間に集計された計算に基づきます。 最小レプリカ数 - 任意の時点で実行が保証されるレプリカの最小数。 - スケールダウンポリシーによって、この数を下回るまでレプリカが削除されることはありません。 最大レプリカ数 - スケールアップでそれ以上はレプリカが追加されない上限となるレプリカの最大数。 - スケールアップポリシーによってこの数を超えてレプリカが追加されることはありません。 HPA を有効にすると、アプリケーションが水平にスケーリングされるときにお客様に追加のフロー使用量が発生することがあります。予期しないスケーリングによる超過を避けるため、購入したフロー制限内に収まるように最大レプリカ数は慎重に設定してください。発生したフロー使用量は​[使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports)​で追跡できます。 HPA の CPU 使用率は平均 70% です。 HPA は [リソース要求](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#how-does-a-horizontalpodautoscaler-work)​に基づいています。 When target utilization value is set, the controller calculates the utilization value as a percentage of the equivalent resource request on the containers in each pod. 期間内 (スケールアップの期間は 180 秒に設定されています) のポッドの平均使用率が 70% より高い場合、HPA はスケールアップします。詳細は Kubernetes のドキュメントを参照してください。 ## [](#パフォーマンスに関する考慮事項と制限事項)パフォーマンスに関する考慮事項と制限事項 Mule アプリケーションの水平自動スケーリングを成功させるために、パフォーマンスに関する次の考慮事項を確認してください。 - Runtime Fabric で、使用されるポリシーが Mule アプリケーションに対して評価され、予約済み CPU: 0.45vCpu、vCPU 制限: 0.55vCpu となりました。これは次の設定に対応します。 resources: limits: cpu: 550m requests: cpu: 450m - CPU 使用量に基づいてスケーリングされる Mule アプリケーションは CPU ベースの HPA に適しています。次に例を示します。 - 非同期要求を使用する HTTP/HTTPS - リバースプロキシ - 低レイテンシー + 高スループットのアプリケーション - DataWeave 変換 - APIkit ルーティング - ポリシーを使用する API ゲートウェイ - バッチジョブなどの並列処理が組み込まれていない非リエントラントアプリケーション、リエントランシーやアプリケーション間の重複スケジューリングがないスケジューラーアプリケーション、大きな要求を使用する低スループット高レイテンシーアプリケーションなどは、CPU ベースの HPA に適していません。 - スケールアップとスケールダウンのパフォーマンスはレプリカサイズとアプリケーション種別に応じて異なります。 - ポリシーは 850m より小さいレプリカサイズに対して最適化されています。レプリカサイズがそれよりも大きい場合は、スケーリングに時間がかかる可能性があります。HPA は、平均使用量が 0.2vCPU の小さな CPU アプリケーションにのみお勧めします。 ### [](#制限事項)制限事項 次の制限事項を考慮してください。 - CPU は水平自動スケーリングの唯一のリソースです。 ## [](#水平ポッド自動スケーリングの設定)水平ポッド自動スケーリングの設定 Runtime Fabric にデプロイされた Mule アプリケーションの水平自動スケーリングを設定する手順は次のとおりです。 1. 管理対象の K8s API サーバー上で [メトリクス API のサポート](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)​を有効にします。 2. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Runtime (ランタイム)\]**​ タブで、​**\[Enable Autoscaling (自動スケーリングを有効化)\]**​ ボックスをオンにします。 5. 最小と最大の ​**\[Replica Count (レプリカ数)\]**​ を設定します。 6. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ![「Enable Autoscaling (自動スケーリングを有効化)」 項目がオンになっている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-autoscaling.png) ## [](#自動スケーリングの状況とログ)自動スケーリングの状況とログ 自動スケーリングイベントが発生し、水平自動スケーリングを設定している Mule アプリケーションがスケールアップされたら、Runtime Manager UI のアプリケーションの詳細ウィンドウで ​**\[View status (状況を表示)\]**​ をクリックして、​**\[Scaling (スケーリング)\]**​ 状況を確認できます。 ![Mule アプリケーションとスケーリング状況が表示されている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-hpa-rtm.png) また、アクセス管理の ​**\[Audit logs (監査ログ)\]**​ では、自動スケーリングイベントがいつ発生したかを追跡できます。アプリケーションデプロイメントのスケーリングが発生するたびに、製品 ​**\[Runtime Manager\]**​ の下に ​**\[Anypoint Staff\]**​ ユーザーによる監査ログがパブリッシュされます。このログでは、​**\[Action (アクション)\]**​ は ​`[Scaling (スケーリング)]`​ に設定され、​**\[Object (オブジェクト)\]**​ はアプリケーション ID に設定されています。 ![監査ログとスケーリング状況が表示されている Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-hpa-rtm-2.png) 次に、ログペイロードの例を示します。 ```console {"properties":{"organizationId":"my-orgID-abc","environmentId":"my-envID-xyz","response":{"message":{"message":"Application id:my-appID-123 scaled DOWN from 3 to 2 replicas.","logLevel":"INFO","context":{"logger":"Runtime Manager"},"timestamp":1700234556678}},"deploymentId":"my-appID-123","initialRequest":"/organizations/my-orgID-abc/environments/my-envID-xyz/deployments/my-appID-123/specs/my-specID-456"},"subaction":"Scaling"} ``` さらに、ターミナルで次の ​`kubectl`​ コマンドを実行することで、スケールアップされたレプリカの起動と Mule アプリケーションのレプリカ数を追跡できます。 ```console kubectl get events | grep HorizontalPodAutoscaler ``` クラスター内で発生したイベントを取得するには、Kubernetes で ​`kubectl get events`​ コマンドを使用します。このコマンドを実行すると、ポッドの作成、削除、その他の重要なイベントなど、クラスター内で実行されるさまざまなアクティビティや変更に関する情報が表示されます。 `grep`​ コマンドを使用すると、​`kubectl get events`​ の出力を文字列 ​`HorizontalPodAutoscaler`​ を含む行に絞り込むことができます。次の例は、​`HorizontalPodAutoscaler`​ に関するイベントを含むコマンド出力を示しています。HPA によってトリガーされた再スケーリング操作の成功に関する情報が表示されています。 ```console # kubectl get events | grep HorizontalPodAutoscaler 5m20s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 4; reason: cpu resource utilization (percentage of request) above target 5m5s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 8; reason: cpu resource utilization (percentage of request) above target 4m50s Normal SuccessfulRescale HorizontalPodAutoscaler New size: 10; reason: ``` # Runtime Fabric にデプロイされた Mule アプリケーションの強化 Anypoint Runtime Fabric にデプロイされた Mule アプリケーションのセキュリティを強化して脆弱性を減らすには、次のトピックを確認します。 - [Runtime Manager を使用した Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.6/protect-app-properties) Anypoint Runtime Manager を使用して、プロパティ名を表示してその値は表示しないことで、Mule アプリケーションのプロパティ値を保護します。 - [RTFCTL を使用した Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-secure-properties) `rtfctl`​ コマンドラインツールを使用して Mule アプリケーションのプロパティ値を保護します。 ## [](#関連情報)関連情報 - [Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-index) - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/managing-apps-deployed-runtime-fabric) # Runtime Fabric にデプロイされた Mule アプリケーションの強化 Anypoint Runtime Fabric にデプロイされた Mule アプリケーションのセキュリティを強化して脆弱性を減らすには、次のトピックを確認します。 - [Runtime Manager を使用した Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.7/protect-app-properties) Anypoint Runtime Manager を使用して、プロパティ名を表示してその値は表示しないことで、Mule アプリケーションのプロパティ値を保護します。 - [RTFCTL を使用した Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-secure-properties) `rtfctl`​ コマンドラインツールを使用して Mule アプリケーションのプロパティ値を保護します。 ## [](#関連情報)関連情報 - [Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-index) - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/managing-apps-deployed-runtime-fabric) # Runtime Fabric にデプロイされた Mule アプリケーションの強化 Anypoint Runtime Fabric にデプロイされた Mule アプリケーションのセキュリティを強化して脆弱性を減らすには、次のトピックを確認します。 - [Runtime Manager を使用した Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.8/protect-app-properties) Anypoint Runtime Manager を使用して、プロパティ名を表示してその値は表示しないことで、Mule アプリケーションのプロパティ値を保護します。 - [RTFCTL を使用した Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-secure-properties) `rtfctl`​ コマンドラインツールを使用して Mule アプリケーションのプロパティ値を保護します。 ## [](#関連情報)関連情報 - [Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-index) - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/managing-apps-deployed-runtime-fabric) # Runtime Fabric にデプロイされた Mule アプリケーションの管理 Anypoint Runtime Fabric にデプロイされた Mule アプリケーションを管理するには、次のトピックを確認します。 - [Runtime Fabric にデプロイされた Mule アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-monitor-applications) Anypoint Monitoring を使用して、Runtime Fabric にデプロイされた Mule アプリケーションのメトリクスとログを表示します。さらに、Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされた Mule アプリケーションと統合することで、テレメトリーを外部にエクスポートできます。 - [RTFCTL を使用した Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#manage-rtfctl-apps) `rtfctl delete`​、​`describe`​、​`disk`​、​`memory`​、​`package`​、​`restart`​、​`heapdump`​、​`threaddump`​ コマンドを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理します。 - [アプリケーション間の要求の送信](https://docs.mulesoft.com/jp/runtime-fabric/2.6/app-to-app-requests) Mule アプリケーション名と環境 ID を使用して、クラスター内で 1 つの Mule アプリケーションから別のアプリケーションに要求を送信します。 - [Mule アプリケーションのバージョン管理の確認](https://docs.mulesoft.com/jp/runtime-fabric/2.6/app-versioning) デプロイ済み Mule アプリケーションのバージョン管理を確認し、設定変更履歴を理解し、設定をロールバックし、デプロイ済み Mule アプリケーションの設定を更新します。 - [Mule アプリケーションのスケジュールの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-schedules) Runtime Manager を使用して、デプロイ済みアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 - [Mule Runtime パッチ更新の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/runtime-patch-updates) Runtime Fabric の Mule Runtime Engine パッチ更新と Mule リリースチャネルを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-index) - [Runtime Fabric にデプロイされた Mule アプリケーションの強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-apps-deployed-runtime-fabric) # Runtime Fabric にデプロイされた Mule アプリケーションの管理 Anypoint Runtime Fabric にデプロイされた Mule アプリケーションを管理するには、次のトピックを確認します。 - [Runtime Fabric にデプロイされた Mule アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-monitor-applications) Anypoint Monitoring を使用して、Runtime Fabric にデプロイされた Mule アプリケーションのメトリクスとログを表示します。さらに、Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされた Mule アプリケーションと統合することで、テレメトリーを外部にエクスポートできます。 - [RTFCTL を使用した Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#manage-rtfctl-apps) `rtfctl delete`​、​`describe`​、​`disk`​、​`memory`​、​`package`​、​`restart`​、​`heapdump`​、​`threaddump`​ コマンドを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理します。 - [アプリケーション間の要求の送信](https://docs.mulesoft.com/jp/runtime-fabric/2.7/app-to-app-requests) Mule アプリケーション名と環境 ID を使用して、クラスター内で 1 つの Mule アプリケーションから別のアプリケーションに要求を送信します。 - [Mule アプリケーションのバージョン管理の確認](https://docs.mulesoft.com/jp/runtime-fabric/2.7/app-versioning) デプロイ済み Mule アプリケーションのバージョン管理を確認し、設定変更履歴を理解し、設定をロールバックし、デプロイ済み Mule アプリケーションの設定を更新します。 - [Mule アプリケーションのスケジュールの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-schedules) Runtime Manager を使用して、デプロイ済みアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 - [Mule Runtime パッチ更新の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/runtime-patch-updates) Runtime Fabric の Mule Runtime Engine パッチ更新と Mule リリースチャネルを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-index) - [Runtime Fabric にデプロイされた Mule アプリケーションの強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-apps-deployed-runtime-fabric) # Runtime Fabric にデプロイされた Mule アプリケーションの管理 Anypoint Runtime Fabric にデプロイされた Mule アプリケーションを管理するには、次のトピックを確認します。 - [Runtime Fabric にデプロイされた Mule アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-monitor-applications) Anypoint Monitoring を使用して、Runtime Fabric にデプロイされた Mule アプリケーションのメトリクスとログを表示します。さらに、Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされた Mule アプリケーションと統合することで、テレメトリーを外部にエクスポートできます。 - [RTFCTL を使用した Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#manage-rtfctl-apps) `rtfctl delete`​、​`describe`​、​`disk`​、​`memory`​、​`package`​、​`restart`​、​`heapdump`​、​`threaddump`​ コマンドを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理します。 - [アプリケーション間の要求の送信](https://docs.mulesoft.com/jp/runtime-fabric/2.8/app-to-app-requests) Mule アプリケーション名と環境 ID を使用して、クラスター内で 1 つの Mule アプリケーションから別のアプリケーションに要求を送信します。 - [Mule アプリケーションのバージョン管理の確認](https://docs.mulesoft.com/jp/runtime-fabric/2.8/app-versioning) デプロイ済み Mule アプリケーションのバージョン管理を確認し、設定変更履歴を理解し、設定をロールバックし、デプロイ済み Mule アプリケーションの設定を更新します。 - [Mule アプリケーションのスケジュールの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-schedules) Runtime Manager を使用して、デプロイ済みアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 - [Mule Runtime パッチ更新の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/runtime-patch-updates) Runtime Fabric の Mule Runtime Engine パッチ更新と Mule リリースチャネルを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-index) - [Runtime Fabric にデプロイされた Mule アプリケーションの強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-apps-deployed-runtime-fabric) # Runtime Fabric にデプロイされた Mule アプリケーションへの RTFCTL の使用 `rtfctl`​ コマンドラインツールを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理できます。 - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#manage-rtfctl-apps) `rtfctl delete`​、​`describe`​、​`disk`​、​`memory`​、​`package`​、​`restart`​、​`heapdump`​、​`threaddump`​ コマンドを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理します。 - [Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-secure-properties) `rtfctl apply`​、​`get`​、​`delete`​ コマンドを使用して、Mule アプリケーションのプロパティ値を保護できます。 ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl) - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/using-rtfctl-rtf) # Runtime Fabric にデプロイされた Mule アプリケーションへの RTFCTL の使用 `rtfctl`​ コマンドラインツールを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理できます。 - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#manage-rtfctl-apps) `rtfctl delete`​、​`describe`​、​`disk`​、​`memory`​、​`package`​、​`restart`​、​`heapdump`​、​`threaddump`​ コマンドを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理します。 - [Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-secure-properties) `rtfctl apply`​、​`get`​、​`delete`​ コマンドを使用して、Mule アプリケーションのプロパティ値を保護できます。 ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl) - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/using-rtfctl-rtf) # Runtime Fabric にデプロイされた Mule アプリケーションへの RTFCTL の使用 `rtfctl`​ コマンドラインツールを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理できます。 - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#manage-rtfctl-apps) `rtfctl delete`​、​`describe`​、​`disk`​、​`memory`​、​`package`​、​`restart`​、​`heapdump`​、​`threaddump`​ コマンドを使用して、Runtime Fabric にデプロイされた Mule アプリケーションを管理します。 - [Mule アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-secure-properties) `rtfctl apply`​、​`get`​、​`delete`​ コマンドを使用して、Mule アプリケーションのプロパティ値を保護できます。 ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl) - [Runtime Fabric への RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/using-rtfctl-rtf) # Runtime Fabric にデプロイされたアプリケーションの監視 Runtime Fabric にデプロイされたアプリケーションと API ゲートウェイには、Anypoint Platform 内のメトリクスを表示できる Anypoint Monitoring のネイティブサポートが含まれます。
Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。
## [](#anypoint-monitoring)Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ には、アプリケーションネットワークの Mule フローとコンポーネントからのフィードバックを提供するツールがあります。Anypoint Monitoring は、アプリケーションデプロイメント内でサイドカーとして実行され、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスを収集します。 Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 ### [](#anypoint-monitoring-の有効化)Anypoint Monitoring の有効化 デフォルトでは、Runtime Fabric は、アプリケーションメトリクスを Anypoint Monitoring に送信するように設定されています。データは相互 TLS 暗号化を使用してセキュアに送信されます。メトリクスとログを Anypoint Monitoring に送信するには、アウトバウンドネットワーク接続を使用できる必要があります。 アウトバウンドプロキシが必要な場合、​[「Runtime Fabric で使用されるプロキシの管理」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-proxy)​の手順に従って、SOCKS5 プロキシを使用するように Anypoint Runtime Fabric を設定します。 Anypoint Runtime Fabric バージョン 1.8.50 以降でアウトバウンドネットワーク接続を検証するには、Runtime Fabric の各ノードがポート 443 を使用して次のドメインにアウトバウンド TCP (Lumberjack) 通信を送信できることを確認します。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io`

1.8.50 より前のバージョンの Anypoint Runtime Fabric を使用している場合、ポート 443 の代わりにポート 5044 を使用します。次のドメインを使用します。

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io
### [](#アプリケーションの-anypoint-monitoring-の無効化)アプリケーションの Anypoint Monitoring の無効化 Runtime Fabric にアプリケーションをデプロイすると、デフォルトで Anypoint Monitoring が有効になります。Anypoint Monitoring を無効にするには、アプリケーションをデプロイするときに次のカスタムプロパティを渡します。 anypoint.platform.config.analytics.agent.enabled=false
場合によって、複数の行を含むログが Anypoint Monitoring に完全に送信されないことがあります。これは、複数行のログ出力が Runtime Fabric 内の循環によって 2 つのファイルに分割された場合に発生する可能性があります。
### [](#メトリクス)メトリクス 各 Mule アプリケーションと API ゲートウェイのレプリカは、メトリクスデータを収集してセキュアな相互 TLS 暗号化を通じて Anypoint Monitoring に送信するメトリクスエージェントを実行します。各レプリカは最大 100 メガバイトのメトリクスをキャッシュできます。その後メトリクスデータを循環し、最新のデータのストレージを提供します。メトリクスを Anypoint Monitoring に送信できない場合、通常はレプリカごとに少なくとも 4 日分のストレージが提供されます。カスタムメトリクスにはより多くのストレージがコンシュームされる場合があります。

次のことを実行した後に、アプリケーション監視メトリクスは復元されません。

  • Runtime Fabric のバックアップと復元

  • Runtime Fabric のアップグレード

  • Runtime Fabric ノードの OS パッチ適用
### [](#ログ-titanium)ログ (Titanium) Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 各 Mule アプリケーションと API ゲートウェイのレプリカは、最大 450 メガバイトのログデータをディスクに保存できます。その後ログデータを循環し、最新のログデータのストレージを提供します。 Mule アプリケーションと API ゲートウェイの各レプリカによって生成されたログが収集され、それらが実行されているワーカーノードのディスクに書き込まれます。各ワーカーノードは 1 つのログ転送エージェントを実行します。そのエージェントがこの場所を監視し、ログデータを Anypoint Monitoring に送信します。

  • ログ転送エージェントは、1 秒あたり最大 300 キロバイトのログデータを送信できます。ワーカーノードごとにデプロイするレプリカは 50 個以内にしてください。

  • アプリケーションログの転送をアプリケーションレベルで Runtime Fabric v1.5.25 バージョン以降から Anypoint Monitoring に切り替えることができます。
## [](#anypoint-visualizer)Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/)​ には、アプリケーションネットワークグラフのさまざまな側面のビューが表示されます。 グラフを使用してアプリケーションネットワークを調査し、問題を特定して、決定を下すことができます。

デフォルトでは、アプリケーションを Mule Runtime 4.x にデプロイすると、Anypoint Visualizer は無効になります。 詳細は、​「ヘッダー挿入の有効化」​を参照してください。

パフォーマンスへの影響のため、0.2 個未満の vCPU を使用するアプリケーションデプロイメントで Anypoint Visualizer を有効にすることはサポートされません。
# Runtime Fabric にデプロイされたアプリケーションの監視 Runtime Fabric にデプロイされたアプリケーションと API ゲートウェイには、Anypoint Platform 内のメトリクスを表示できる Anypoint Monitoring のネイティブサポートが含まれます。
Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。
## [](#anypoint-monitoring)Anypoint Monitoring [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ には、アプリケーションネットワークの Mule フローとコンポーネントからのフィードバックを提供するツールがあります。Anypoint Monitoring は、アプリケーションデプロイメント内でサイドカーとして実行され、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスを収集します。 Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 ## [](#anypoint-monitoring-の有効化)Anypoint Monitoring の有効化 デフォルトでは、Runtime Fabric は、アプリケーションメトリクスを Anypoint Monitoring に送信するように設定されています。データは相互 TLS 暗号化を使用してセキュアに送信されます。メトリクスとログを Anypoint Monitoring に送信するには、アウトバウンドネットワーク接続を使用できる必要があります。 アウトバウンドプロキシが必要な場合、​[「Runtime Fabric で使用されるプロキシの管理」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-proxy-self)​の手順に従って、SOCKS5 プロキシを使用するように Anypoint Runtime Fabric を設定します。 Anypoint Runtime Fabric バージョン 1.8.50 以降でアウトバウンドネットワーク接続を検証するには、Runtime Fabric の各ノードがポート 443 を使用して次のドメインにアウトバウンド TCP (Lumberjack) 通信を送信できることを確認します。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io`

1.8.50 より前のバージョンの Anypoint Runtime Fabric を使用している場合、ポート 443 の代わりにポート 5044 を使用します。次のドメインを使用します。

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io
## [](#アプリケーションの-anypoint-monitoring-の無効化)アプリケーションの Anypoint Monitoring の無効化 Runtime Fabric にアプリケーションをデプロイすると、デフォルトで Anypoint Monitoring が有効になります。Anypoint Monitoring を無効にするには、アプリケーションをデプロイするときに次のカスタムプロパティを渡します。 ```copy anypoint.platform.config.analytics.agent.enabled=false ```
場合によって、複数の行を含むログが Anypoint Monitoring に完全に送信されないことがあります。これは、複数行のログ出力が Runtime Fabric 内の循環によって 2 つのファイルに分割された場合に発生する可能性があります。
anypoint.platform.config.analytics.agent.enabled​ が false に設定されていたとしても、Anypoint Monitoring サイドカーコンテナはゼロにはなりません。
## [](#メトリクス)メトリクス 各 Mule アプリケーションと API ゲートウェイのレプリカは、メトリクスデータを収集してセキュアな相互 TLS 暗号化を通じて Anypoint Monitoring に送信するメトリクスエージェントを実行します。各レプリカは最大 100 メガバイトのメトリクスをキャッシュできます。その後メトリクスデータを循環し、最新のデータのストレージを提供します。メトリクスを Anypoint Monitoring に送信できない場合、通常はレプリカごとに少なくとも 4 日分のストレージが提供されます。カスタムメトリクスにはより多くのストレージがコンシュームされる場合があります。

次のことを実行した後に、アプリケーション監視メトリクスは復元されません。

  • Runtime Fabric のバックアップと復元

  • Runtime Fabric のアップグレード

  • Runtime Fabric ノードの OS パッチ適用
## [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 各 Mule アプリケーションと API ゲートウェイのレプリカは、最大 450 メガバイトのログデータをディスクに保存できます。その後ログデータを循環し、最新のログデータのストレージを提供します。 Mule アプリケーションと API ゲートウェイの各レプリカによって生成されたログが収集され、それらが実行されているワーカーノードのディスクに書き込まれます。各ワーカーノードは 1 つのログ転送エージェントを実行します。そのエージェントがこの場所を監視し、ログデータを Anypoint Monitoring に送信します。

ログ転送エージェントは、1 秒あたり最大 300 キロバイトのログデータを送信できます。ワーカーノードごとにデプロイするレプリカは 50 個以内にしてください。
[Runtime Manager でアプリケーションをデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric#configure-logging-and-log-levels)​するときにログ転送を有効にしてログレベルを設定できます。 ### [](#anypoint-monitoring-ログ転送の前提条件)Anypoint Monitoring ログ転送の前提条件 ログを Anypoint Monitoring に転送する daemon-set では、アプリケーションコンテナが次の場所にログを書き込むことを想定しています。 - `/var/log/pods` - `/var/log/containers` - `/var/lib/docker/containers` daemon-set により、ホストパス ​`/var/lib/filebeat-data`​ での作成および書き込みも行われます。ログ転送を正常に機能させるには、次のことを確認してください。 - Docker デーモン設定に ​`json-file`​ ログドライバーが含まれている。 - Anypoint Monitoring ログフォワーダー daemon-set コンテナに、ホストパス ​`/var/lib/filebeat-data`​ のホストへの書き込みアクセス権がある。 ## [](#anypoint-visualizer)Anypoint Visualizer [Anypoint Visualizer](https://docs.mulesoft.com/visualizer/)​ には、アプリケーションネットワークグラフのさまざまな側面のビューが表示されます。 グラフを使用してアプリケーションネットワークを調査し、問題を特定して、決定を下すことができます。

デフォルトでは、アプリケーションを Mule Runtime 4.x にデプロイすると、Anypoint Visualizer は無効になります。 詳細は、​「ヘッダー挿入の有効化」​を参照してください。

パフォーマンスへの影響のため、0.2 個未満の vCPU を使用するアプリケーションデプロイメントで Anypoint Visualizer を有効にすることはサポートされません。
# Runtime Fabric にデプロイされたアプリケーションの監視 Anypoint Runtime Fabric では、お客様のニーズに応じてさまざまなオブザーバビリティソリューションが提供されます。 ## [](#anypoint-monitoring)Anypoint Monitoring Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 メトリクスとログを Anypoint Monitoring に送信するには、[Anypoint Monitoring の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/use-anypoint-monitoring)で説明されているように、アウトバウンドネットワーク接続を使用できる必要があります。 ## [](#外部へのテレメトリーのエクスポート)外部へのテレメトリーのエクスポート Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合することで、テレメトリーを外部にエクスポートできます。​`log4j2.xml`​ の設定についての詳細は、​[「Log4j アペンダーの使用」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/use-log4j-appender)​ドキュメントを参照してください。 # Runtime Fabric にデプロイされたアプリケーションの監視 Anypoint Runtime Fabric では、お客様のニーズに応じてさまざまなオブザーバビリティソリューションが提供されます。 ## [](#anypoint-monitoring)Anypoint Monitoring Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 メトリクスとログを Anypoint Monitoring に送信するには、[Anypoint Monitoring の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/use-anypoint-monitoring)で説明されているように、アウトバウンドネットワーク接続を使用できる必要があります。 ## [](#外部へのテレメトリーのエクスポート)外部へのテレメトリーのエクスポート Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合することで、テレメトリーを外部にエクスポートできます。​`log4j2.xml`​ の設定についての詳細は、​[「Log4j アペンダーの使用」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/use-log4j-appender)​ドキュメントを参照してください。 # Runtime Fabric にデプロイされたアプリケーションの監視 Anypoint Runtime Fabric では、お客様のニーズに応じてさまざまなオブザーバビリティソリューションが提供されます。 ## [](#anypoint-monitoring)Anypoint Monitoring Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 メトリクスとログを Anypoint Monitoring に送信するには、[Anypoint Monitoring の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/use-anypoint-monitoring)で説明されているように、アウトバウンドネットワーク接続を使用できる必要があります。 ## [](#外部へのテレメトリーのエクスポート)外部へのテレメトリーのエクスポート Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合することで、テレメトリーを外部にエクスポートできます。​`log4j2.xml`​ の設定についての詳細は、​[「Log4j アペンダーの使用」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/use-log4j-appender)​ドキュメントを参照してください。 # Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス Runtime Fabric に関する次の Kubernetes (K8s) のベストプラクティスを確認してください。Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照して詳細を確認できます。 - [拡張性ベンチマーク](https://docs.mulesoft.com/jp/runtime-fabric/2.5/rtf-scale) これらのスケールリミットにより、Runtime Fabric あたりのノード数とデプロイメントが定義されます。これらの制限は、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。 - [クラスター設定](https://docs.mulesoft.com/jp/runtime-fabric/2.5/rtf-cluster-config) これらのクラスター設定は、Runtime Fabric 用のクラスターをセットアップするのに役立ちます。 # Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス Runtime Fabric に関する次の Kubernetes (K8s) のベストプラクティスを確認してください。Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照して詳細を確認できます。 - [拡張性ベンチマーク](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-scale) これらのスケールリミットにより、Runtime Fabric あたりのノード数とデプロイメントが定義されます。これらの制限は、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。 - [クラスター設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-cluster-config) これらのクラスター設定は、Runtime Fabric 用のクラスターをセットアップするのに役立ちます。 # Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス Runtime Fabric に関する次の Kubernetes (K8s) のベストプラクティスを確認してください。Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照して詳細を確認できます。 - [拡張性ベンチマーク](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-scale) これらのスケールリミットにより、Runtime Fabric あたりのノード数とデプロイメントが定義されます。これらの制限は、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。 - [クラスター設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-cluster-config) これらのクラスター設定は、Runtime Fabric 用のクラスターをセットアップするのに役立ちます。 # Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス Runtime Fabric に関する次の Kubernetes (K8s) のベストプラクティスを確認してください。Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照して詳細を確認できます。 - [拡張性ベンチマーク](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-scale) これらのスケールリミットにより、Runtime Fabric あたりのノード数とデプロイメントが定義されます。これらの制限は、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。 - [クラスター設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-cluster-config) これらのクラスター設定は、Runtime Fabric 用のクラスターをセットアップするのに役立ちます。 # Runtime Fabric の FIPS 140-2 コンプライアンスモードの有効化 Runtime Fabric は、FIPS 140-2 コンプライアンスモードでアプリケーションコンテナを実行するように設定できます。 以降の手順では、読者が [FIPS 140-2](https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf)​ に精通していることを前提としています。FIPS 140-2 は、米国政府のセキュリティ標準で、準拠者は NIST によって認証された暗号化アルゴリズムおよび手法のみを使用することが求められます。 ## [](#fips-140-2-コンプライアンスモードを有効化する)FIPS 140-2 コンプライアンスモードを有効化する 1. `kubectl`​ を使用して、​`FIPS_ENABLED`​ キーを ​`true`​ に設定して ​`rtf`​ 名前空間で ​`custom-properties`​ シークレットをパッチ適用します。 \# kubectl patch secret custom-properties -n rtf -p='{"stringData":{"FIPS\_ENABLED": "true"}}' この変更を行った後で、新規アプリケーションをデプロイするか既存のアプリケーションを再起動すると、そのコンテナが FIPS 140-2 コンプライアンスモードで実行されます。 2. アプリケーションが FIPS 140-2 コンプライアンスモードで実行されていることを確認するには、アプリケーションの起動ログを確認します。 \# kubectl logs -n -c app -f| grep -i fips Running in FIPS mode \* Security model: fips140-2 \* \* - mule.security.model = fips140-2 # Runtime Fabric の Kubernetes 権限 Runtime Fabric の Kubernetes 権限を有効にするには、次のトピックを確認します。 - [Runtime Fabric コアソフトウェアの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-permissions) Runtime Fabric エージェントに必要な Kubernetes リソースアクセス権限を確認します。 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtfctl-permissions) `rtfctl`​ コマンドを正常に実行するために、Kubernetes リソースに対する特定のロール権限を有効にします。 - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-mule-app-permissions) Mule アプリケーションデプロイメントの Kubernetes 権限設定を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric 向けの Kubernetes の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-mule-app-permissions) # Runtime Fabric の Kubernetes 権限 Runtime Fabric の Kubernetes 権限を有効にするには、次のトピックを確認します。 - [Runtime Fabric コアソフトウェアの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-permissions) Runtime Fabric エージェントに必要な Kubernetes リソースアクセス権限を確認します。 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtfctl-permissions) `rtfctl`​ コマンドを正常に実行するために、Kubernetes リソースに対する特定のロール権限を有効にします。 - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-mule-app-permissions) Mule アプリケーションデプロイメントの Kubernetes 権限設定を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric 向けの Kubernetes の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-mule-app-permissions) # Runtime Fabric の Kubernetes 権限 Runtime Fabric の Kubernetes 権限を有効にするには、次のトピックを確認します。 - [Runtime Fabric コアソフトウェアの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-permissions) Runtime Fabric エージェントに必要な Kubernetes リソースアクセス権限を確認します。 - [RTFCTL の Kubernetes 権限の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtfctl-permissions) `rtfctl`​ コマンドを正常に実行するために、Kubernetes リソースに対する特定のロール権限を有効にします。 - [Runtime Fabric での Mule アプリケーションデプロイメントの Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-mule-app-permissions) Mule アプリケーションデプロイメントの Kubernetes 権限設定を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric 向けの Kubernetes の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-mule-app-permissions) # Runtime Fabric の Mule Runtime パッチ更新の管理 以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新に関する重要な情報を提供します。 ## [](#月-1-回の日付パッチ更新)月 1 回の日付パッチ更新 月 1 回、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 これらの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ - ​_日付_​ パッチ日付が含まれるバージョン番号の例を示します。 `4.3.0:20210101` 月 1 回のパッチでは、アプリケーションが最新の日付のパッチのみに更新されます。ランタイムバージョンは変更されません。 ## [](#runtime-fabric-のランタイムパッチ更新スケジュール)Runtime Fabric のランタイムパッチ更新スケジュール Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。 1. 月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。 2. 次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは​_猶予期間_​と呼ばれます。 3. 月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。
猶予期間中は、前の日付のパッチバージョンが使用できなくなるまで、これを選択できます。前の日付のパッチを選択し、それ以降にそのアプリケーションに変更を加えた場合、その日付のパッチバージョンを以降のリリースに更新する必要がある場合もあります。
## [](#1-つのアプリケーションの最新のランタイムパッチリリースへの更新)1 つのアプリケーションの最新のランタイムパッチリリースへの更新 本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。 アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。 1. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. **\[Deployment Target (デプロイメント対象)\]**​ の ​**\[Runtime version (ランタイムバージョン)\]**​ リストから、​`new`​ とタグ付けされたバージョンを選択します。 ![新しいランタイムバージョンが選択されています。](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-runtime-select-version.png) 更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。 ![日付で示されている最新のランタイムバージョン。](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-runtime-select-latest-version.png) 3. バージョンの詳細を確認するには、​**\[Read release notes (リリースノートを読む)\]**​ リンクをクリックします。 4. **\[Apply Changes (変更を適用)\]**​ をクリックしてアプリケーションを更新します。 Runtime Fabric により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。 5. アプリケーションを再デプロイします。 Runtime Fabric の Mule デプロイメントには、自動的にパッチが適用されません。最新の日付のパッチ更新を適用するにはアプリケーションを再デプロイする必要があります。 ## [](#関連情報)関連情報 - [Runtime Fabric ランタイムリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) # Runtime Fabric のアップグレード Runtime Fabric をアップグレードするには、次のいずれかのオプションを選択します。 - [rtfctl を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.5/upgrade-self-managed) - [Helm を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.5/upgrade-helm) - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.5/upgrade-openshift) # Runtime Fabric のアップグレード Anypoint Runtime Fabric をアップグレードするには、次のいずれかのオプションを確認します。 - [RTFCTL を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-self-managed) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric をアップグレードします。 - [Helm を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-helm) Helm パッケージマネージャーを使用して Runtime Fabric をアップグレードします。 - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-openshift) Red Hat OpenShift コンソールを使用して Red Hat OpenShift 上で Runtime Fabric をアップグレードします。 ## [](#関連情報)関連情報 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-index) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configuring-runtime-fabric) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/uninstall-self) # Runtime Fabric のアップグレード Anypoint Runtime Fabric をアップグレードするには、次のいずれかのオプションを確認します。 - [RTFCTL を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-self-managed) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric をアップグレードします。 - [Helm を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-helm) Helm パッケージマネージャーを使用して Runtime Fabric をアップグレードします。 - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-openshift) Red Hat OpenShift コンソールを使用して Red Hat OpenShift 上で Runtime Fabric をアップグレードします。 - [アップグレードの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-pre-requisites) `rtfd`​ コンテナ値を更新します。 ## [](#関連情報)関連情報 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-index) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configuring-runtime-fabric) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/uninstall-self) # Runtime Fabric のアップグレード Anypoint Runtime Fabric をアップグレードするには、次のいずれかのオプションを確認します。 - [RTFCTL を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-self-managed) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric をアップグレードします。 - [Helm を使用した Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-helm) Helm パッケージマネージャーを使用して Runtime Fabric をアップグレードします。 - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-openshift) Red Hat OpenShift コンソールを使用して Red Hat OpenShift 上で Runtime Fabric をアップグレードします。 - [アップグレードの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-pre-requisites) `rtfd`​ コンテナ値を更新します。 ## [](#関連情報)関連情報 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-index) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configuring-runtime-fabric) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/uninstall-self) # Runtime Fabric のアンインストール インストール方法に応じて、Runtime Fabric コマンドラインツール (​`rtfctl`​) または Helm を使用して Runtime Fabric をアンインストールできます。 ## [](#rtfctl-を使用して-runtime-fabric-をアンインストールする)rtfctl を使用して Runtime Fabric をアンインストールする `rtfctl`​ を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. `rtfctl uninstall`​ コマンドを実行して、Kubernetes クラスターから Runtime Fabric サービスをアンインストールします。 5. `rtfctl uninstall --confirm`​ コマンドを実行して、アンインストール操作を確認します。 6. アンインストールコマンドが終了したら、クラスターで Runtime Fabric アプリケーションまたはサービスが実行されていないことを確認します。 ## [](#helm-を使用して-runtime-fabric-をアンインストールする)Helm を使用して Runtime Fabric をアンインストールする Helm を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. 次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf ``` インストールプロセス中のエラー (例: インストールが正常に完了しなかった) によってアンインストールが必要になった場合は、次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## [](#red-hat-openshift-での-runtime-fabric-のアンインストール)Red Hat OpenShift での Runtime Fabric のアンインストール Red Hat OpenShift で Runtime Fabric をアンインストールするには、次の手順を実行します。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. すべての関連付けられた環境からすべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 5. Runtime Fabric Operator を選択します。 6. **\[Uninstall (アンインストール)\]**​ をクリックします。 7. 次の Helm コマンドを使用して、クラスターから Runtime Fabric をアンインストールします。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. クラスターから ​`rtf`​ 名前空間を削除します。 ```copy oc delete ns rtf ``` ### [](#rtf-名前空間の削除のトラブルシューティング)rtf 名前空間の削除のトラブルシューティング `rtf`​ 名前空間を削除するコマンドが機能しない場合、次の手順を実行してください。 1. 次のコマンドを実行します。 ```copy oc get ns rtf -o json > rtf.json ``` 2. `rtf.json`​ を編集して ​`kubernetes`​ を ​`finalizer`​ 配列から削除します。 3. 次のコマンドを実行します。 ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. `rtf`​ 名前空間が存在しなくなったことを確認します。 # Runtime Fabric のアンインストール インストール方法に応じて、Runtime Fabric コマンドラインツール (​`rtfctl`​) または Helm を使用して Runtime Fabric をアンインストールできます。 ## [](#unistall-rtfctl-rtf)rtfctl を使用して Runtime Fabric をアンインストールする `rtfctl`​ を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. `rtfctl uninstall`​ コマンドを実行して、Kubernetes クラスターから Runtime Fabric サービスをアンインストールします。 5. `rtfctl uninstall --confirm`​ コマンドを実行して、アンインストール操作を確認します。 6. アンインストールコマンドが終了したら、クラスターで Runtime Fabric アプリケーションまたはサービスが実行されていないことを確認します。 ## [](#helm-を使用して-runtime-fabric-をアンインストールする)Helm を使用して Runtime Fabric をアンインストールする Helm を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. 次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf ``` インストールプロセス中のエラー (例: インストールが正常に完了しなかった) によってアンインストールが必要になった場合は、次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## [](#red-hat-openshift-での-runtime-fabric-のアンインストール)Red Hat OpenShift での Runtime Fabric のアンインストール Red Hat OpenShift で Runtime Fabric をアンインストールするには、次の手順を実行します。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. すべての関連付けられた環境からすべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 5. Runtime Fabric Operator を選択します。 6. **\[Uninstall (アンインストール)\]**​ をクリックします。 7. 次の Helm コマンドを使用して、クラスターから Runtime Fabric をアンインストールします。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. クラスターから ​`rtf`​ 名前空間を削除します。 ```copy oc delete ns rtf ``` ### [](#rtf-名前空間の削除のトラブルシューティング)rtf 名前空間の削除のトラブルシューティング `rtf`​ 名前空間を削除するコマンドが機能しない場合、次の手順を実行してください。 1. 次のコマンドを実行します。 ```copy oc get ns rtf -o json > rtf.json ``` 2. `rtf.json`​ を編集して ​`kubernetes`​ を ​`finalizer`​ 配列から削除します。 3. 次のコマンドを実行します。 ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. `rtf`​ 名前空間が存在しなくなったことを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-index) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configuring-runtime-fabric) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-index) # Runtime Fabric のアンインストール インストール方法に応じて、Runtime Fabric コマンドラインツール (​`rtfctl`​) または Helm を使用して Runtime Fabric をアンインストールできます。 ## [](#unistall-rtfctl-rtf)rtfctl を使用して Runtime Fabric をアンインストールする `rtfctl`​ を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. `rtfctl uninstall`​ コマンドを実行して、Kubernetes クラスターから Runtime Fabric サービスをアンインストールします。 5. `rtfctl uninstall --confirm`​ コマンドを実行して、アンインストール操作を確認します。 6. アンインストールコマンドが終了したら、クラスターで Runtime Fabric アプリケーションまたはサービスが実行されていないことを確認します。 ## [](#helm-を使用して-runtime-fabric-をアンインストールする)Helm を使用して Runtime Fabric をアンインストールする Helm を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. 次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf ``` インストールプロセス中のエラー (例: インストールが正常に完了しなかった) によってアンインストールが必要になった場合は、次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## [](#red-hat-openshift-での-runtime-fabric-のアンインストール)Red Hat OpenShift での Runtime Fabric のアンインストール Red Hat OpenShift で Runtime Fabric をアンインストールするには、次の手順を実行します。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. すべての関連付けられた環境からすべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 5. Runtime Fabric Operator を選択します。 6. **\[Uninstall (アンインストール)\]**​ をクリックします。 7. 次の Helm コマンドを使用して、クラスターから Runtime Fabric をアンインストールします。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. クラスターから ​`rtf`​ 名前空間を削除します。 ```copy oc delete ns rtf ``` ### [](#rtf-名前空間の削除のトラブルシューティング)rtf 名前空間の削除のトラブルシューティング `rtf`​ 名前空間を削除するコマンドが機能しない場合、次の手順を実行してください。 1. 次のコマンドを実行します。 ```copy oc get ns rtf -o json > rtf.json ``` 2. `rtf.json`​ を編集して ​`kubernetes`​ を ​`finalizer`​ 配列から削除します。 3. 次のコマンドを実行します。 ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. `rtf`​ 名前空間が存在しなくなったことを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-index) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configuring-runtime-fabric) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-index) # Runtime Fabric のアンインストール インストール方法に応じて、Runtime Fabric コマンドラインツール (​`rtfctl`​) または Helm を使用して Runtime Fabric をアンインストールできます。 ## [](#unistall-rtfctl-rtf)rtfctl を使用して Runtime Fabric をアンインストールする `rtfctl`​ を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. `rtfctl uninstall`​ コマンドを実行して、Kubernetes クラスターから Runtime Fabric サービスをアンインストールします。 5. `rtfctl uninstall --confirm`​ コマンドを実行して、アンインストール操作を確認します。 6. アンインストールコマンドが終了したら、クラスターで Runtime Fabric アプリケーションまたはサービスが実行されていないことを確認します。 ## [](#helm-を使用して-runtime-fabric-をアンインストールする)Helm を使用して Runtime Fabric をアンインストールする Helm を使用して Runtime Fabric をアンインストールする手順は、次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. 次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf ``` インストールプロセス中のエラー (例: インストールが正常に完了しなかった) によってアンインストールが必要になった場合は、次のコマンドを実行します。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` ## [](#red-hat-openshift-での-runtime-fabric-のアンインストール)Red Hat OpenShift での Runtime Fabric のアンインストール Red Hat OpenShift で Runtime Fabric をアンインストールするには、次の手順を実行します。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. すべての関連付けられた環境からすべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 5. Runtime Fabric Operator を選択します。 6. **\[Uninstall (アンインストール)\]**​ をクリックします。 7. 次の Helm コマンドを使用して、クラスターから Runtime Fabric をアンインストールします。 ```copy helm uninstall runtime-fabric -n rtf --no-hooks ``` 8. クラスターから ​`rtf`​ 名前空間を削除します。 ```copy oc delete ns rtf ``` ### [](#rtf-名前空間の削除のトラブルシューティング)rtf 名前空間の削除のトラブルシューティング `rtf`​ 名前空間を削除するコマンドが機能しない場合、次の手順を実行してください。 1. 次のコマンドを実行します。 ```copy oc get ns rtf -o json > rtf.json ``` 2. `rtf.json`​ を編集して ​`kubernetes`​ を ​`finalizer`​ 配列から削除します。 3. 次のコマンドを実行します。 ```copy oc replace --raw "/api/v1/namespaces/rtf/finalize" -f ./rtf.json oc get ns ``` 4. `rtf`​ 名前空間が存在しなくなったことを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-index) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configuring-runtime-fabric) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-index) # Runtime Fabric のイングレスの設定

このコンテンツでは、バージョン 1.10 以降の Runtime Fabric でのイングレスの設定について説明します。以前のイングレスの設定手順については、バージョン 1.8 または 1.9 のドキュメントを参照してください。
Anypoint Runtime Fabric では、イングレスリソーステンプレートを使用してカスタムイングレス設定を指定できます。テンプレートでは、 [Kubernetes イングレス仕様](https://kubernetes.io/docs/concepts/services-networking/ingress/)​と同様、アノテーション、イングレスクラス名、および HTTP および HTTPS ルールを指定できます。 アプリケーションのイングレスリソーステンプレートを適用しない場合、デプロイしたときにイングレスエンドポイントを追加できません。

デフォルトでは、Google Kubernetes Engine (GKE) と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、 「Default Ingress Controller Behavior with Runtime Fabric on GKE (GKE での Runtime Fabric を使用したデフォルトのイングレスコントローラーの動作)」​を参照してください。

AWS アプリケーションのロードバランサーでは、​group.name​ アノテーションを使用しない限り同様の動作になります。詳細は、 「Application load balancing on Amazon EKS (Amazon EKS でのアプリケーションの負荷分散)」​を参照してください。
## [](#カスタムイングレスリソーステンプレートの利点)カスタムイングレスリソーステンプレートの利点 Runtime Fabric でカスタムイングレスリソーステンプレートを使用すれば、以下に対するサポートを含めてネイティブ Kubernetes イングレス設定機能を活用できます。 - アプリケーションごとに複数のイングレス設定 - 同じ Runtime Fabric インスタンス内の複数のイングレスコントローラー - TLS および HTTPS 設定 - カスタム URL 名前付け - URL パラメーターのプレースホルダー ## [](#runtime-fabric-でのイングレスリソーステンプレートの動作)Runtime Fabric でのイングレスリソーステンプレートの動作 次の図では、Runtime Fabric でイングレスリソーステンプレートを使用する方法の概要を示しています。 ![Runtime Fabric でのイングレステンプレートワークフローを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/ingress-diagram.png) 1. IT 管理者がイングレスコントローラーを設定します。 2. IT 管理者が必須パラメーターを使用してイングレスリソーステンプレートを作成または変更します。イングレスコントローラーの動作はそれぞれ異なります。イングレスコントローラーのドキュメントを確認して、アノテーションを調整してください。 3. IT 管理者が ​`kubectl apply`​ コマンドを使用してテンプレートを適用します。 4. 適用されたテンプレートから、Runtime Fabric によってプレースホルダーの URI ドメインが作成され、すべてのアプリケーションデプロイメントのテンプレートとして Anypoint Runtime Manager でイングレス設定が伝播されます。 5. Mule アプリケーション開発者が Runtime Manager を使用して、イングレステンプレートで指定されているように、使用可能なホスト、省略可能なサブドメイン、およびパスの組み合わせを選択することでデプロイメントのアプリケーションを設定します。 6. Runtime Fabric によってアプリケーションデプロイメント要求が受信され、テンプレートのイングレス設定を使用してクラスターで対応するイングレスオブジェクトが作成されます。 ## [](#イングレスリソーステンプレートの例)イングレスリソーステンプレートの例 次の例では、Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 お使いの Kubernetes バージョンに適した API バージョンを使用してください。 - Kubernetes v1.19 以降: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 Kubernetes v1.22 以降では、​`extensions/v1beta1`​ および ​`networking.k8s.io/v1beta1`​ API バージョンのイングレスは使用できません。 - Kubernetes v1.18 以前: - networking.k8s.io/v1beta1 のみ ### [](#networking-k8s-iov1)networking.k8s.io/v1

このテンプレートは設定の簡略化バージョンです。テンプレートの最終的な設定は、使用しているコントローラーおよびイングレスのルーティングルールに応じて異なる場合があります。お使いのイングレスコントローラーのドキュメントを慎重にお読みください。
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#networking-k8s-iov1beta1)networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。 Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#テンプレートのプレースホルダー)テンプレートのプレースホルダー 次のプレースホルダーは省略可能です。プレースホルダーを使用する場合、テンプレートの適切な場所で置き換えてください。プレースホルダーは小文字にしてください。
プレースホルダーの名前 場所 値の例

business-group-id

path​、​host​、​annotation、labels

 
labels:
  business:
  business-group-id

environment-id

path​、​host​、​annotation、labels

 
labels:
  environment:
  environment-id

unique-id

path​、​annotation、labels

 
path: /app-name-unique-id.com
`unique-id`​ プレースホルダーを使用して一意のアプリケーション URL を作成します。この方法は、異なるビジネスグループから同じ名前を持つ 2 つのアプリケーションをデプロイする場合に便利です。たとえば、イングレステンプレートの ​`path`​ セクションで ​`app-name-unique-id.com`​ を使用する場合、生成されるエンドポイントは ​`app-name-7jkbic.com`​ のようになります。

unique-id​ プレースホルダーは Runtime Fabric バージョン 1.12.28 以降で使用できます。
## [](#イングレステンプレートでの-tls-の使用)イングレステンプレートでの TLS の使用 イングレステンプレートで TLS を使用するには、TLS シークレットを作成する必要があります。詳細は、 [Kubernetes TLS のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)​を参照してください。 `rtf.mulesoft.com/synchronized=true`​ 表示ラベルを使用して、たとえば次のように、TLS シークレットの更新をすべてのアプリケーション名前空間に同期するように Runtime Fabric を設定できます。 ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized=true data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` この表示ラベルをシークレットに適用すると、イングレスコントローラーで更新済みの TLS 素材をアプリケーション名前空間にすぐに適用できるようになります。この表示ラベルを追加しない場合は、各名前空間でシークレットを手動で更新する必要があります。
同期メカニズムを使用して、デプロイ時に Runtime Fabric エージェントの名前空間のシークレットをアプリケーションの名前空間に複製できます。
## [](#既存のイングレステンプレートを変更する)既存のイングレステンプレートを変更する 既存のイングレステンプレートは、すでにアプリケーションのデプロイで使用されている場合でも修正できます。 テンプレートを変更しても、このテンプレートに基づいてすでに作成されているイングレスオブジェクトは更新されません。 テンプレートの変更を反映して既存のイングレスを更新するには、Mule アプリケーションを再デプロイする必要があります。 たとえば、ベースドメインを更新してイングレステンプレートのエンドポイントの変更が必要になった場合は、古いエンドポイントを削除して、アプリケーションの再デプロイ時に新しいエンドポイントを追加します。 ## [](#runtime-fabric-で-mule-アプリケーションデプロイメント用のイングレスを設定する)Runtime Fabric で Mule アプリケーションデプロイメント用のイングレスを設定する イングレスを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#始める前に)始める前に Runtime Fabric でイングレスをセットアップする前に、イングレスコントローラーを設定する必要があります。イングレスコントローラーのリストについては、 [Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)​を参照してください。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-templates)​のいずれかを使用してイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#既存のイングレス設定のアップグレード後の変換)既存のイングレス設定のアップグレード後の変換 Runtime Fabric バージョン 1.10 にアップグレードする場合、アップグレードプロセスでアノテーション、パス、名前空間、ホストパラメーターを含む既存のイングレスの ConfigMaps が自動的にイングレスリソーステンプレート形式に変換されます。次の表を確認して、アップグレード後にアクションが必要かどうかを判断してください。
アップグレード前の Runtime Fabric アップグレード後の Runtime Fabric 必要なアクション TLS サポート

ドメインは設定されず、ingress-ConfigMap は適用されない

アップグレード後にテンプレートが自動的に生成されない

テンプレートを作成する。​イングレスリソーステンプレートを作成してクラスターで適用する​を参照してください。

-

ドメインは設定されないが、有効な ingress-ConfigMap が適用される

生成されたテンプレートにホストの ​*​ が含まれ、以前の ingress-ConfigMap のパスおよびアノテーションが含まれる

生成されたテンプレートで ​host​ 項目を編集し、Runtime Manager でアプリケーションをデプロイするための有効なホスト/ドメインを指定する

デフォルトでは TLS セクションは追加されない

有効なドメインが設定されるが、ingress-ConfigMap は適用されない

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、各テンプレートのパスに ​/app-name​ が含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる

有効なドメインが設定され、有効な ingress-ConfigMap が適用される

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、以前の ingress-ConfigMap のパスおよびアノテーションがすべて含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる
## [](#イングレスの問題のトラブルシューティング)イングレスの問題のトラブルシューティング Runtime Fabric にイングレスを使用しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#mule-アプリケーションをデプロイしたがそのエンドポイントにアクセスできない)Mule アプリケーションをデプロイしたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager で Mule アプリケーションを正常にデプロイしましたが、アプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. アプリケーションがポート 8081 でリスンしていることを確認します。 ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. アプリケーションが実行されていて HTTP 要求に応答していることを確認します。 ```copy curl -v \http://127.0.0.1:8081/ ``` これにより、API アクセスの問題が Mule アプリケーション自体にあるかどうかを判断できます。 3. そのアプリケーションサービスのイングレスリソースが存在することを検証します。 ```copy kubectl get ingress -n [NAMESPACE] ``` 4. サービスが作成されたことを検証します。 ```copy kubectl get svc -n [NAMESPACE] ``` 作成されなかった場合は、Runtime Fabric エージェントのログを確認します。 + ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` サービスおよびイングレスオブジェクトに問題がないように思われる場合は、その他のトラブルシューティングタスクを確認してください。 ### [](#イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない)イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager ではクラスターでイングレスリソースが正常に作成されましたが、404 エラーのためにアプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. イングレスとサービスのリソースを確認します。 ```copy kubectl get ingress -n kubectl get svc -n ``` 次のような結果が返されます。 \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. アプリケーションのイングレスリソースを確認して、リソース、アノテーション、ホストの HTTP パスが正常に表示されることを確認します。 ```copy kubectl get ing -n -oyaml ``` 次のような結果が返されます。 ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. アプリケーションポッドログを確認して、適切なリスニングポートを設定していることを確認します。 ```copy kubectl logs -f -n -c app ``` 次のような結果が返されます。 \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. ログで、リスナーポートがステップ 1 で検出されたサービスポートに一致することを確認します。 5. ポートが正しい場合、アプリケーションログを確認してアプリケーションがイングレスコントローラーからの要求を受信していることを確認します。 ### [](#イングレスリソースが-aws-アプリケーションのロードバランサーによって認識されない)イングレスリソースが AWS アプリケーションのロードバランサーによって認識されない シナリオ: AWS ALB を使用している場合、アプリケーションおよびエンドポイントを正常にデプロイした場合でもアプリケーションのエンドポイントにアクセスできません。 イングレスに AWS ロードバランサーコントローラーを使用している場合、​`ingressClassName: rtf-alb` ​_ではなく_​テンプレートで ​`kubernetes.io/ingress.class: rtf-alb`​ アノテーションを指定する必要があります。AWS ロードバランサーコントローラーがこれらのアノテーションのためにデプロイされたイングレスリソース用の L7 ロードバランサーを検出して作成するには、​`ingress.class`​ アノテーションが必要です。 # Runtime Fabric のイングレスの設定

このコンテンツでは、バージョン 1.10 以降の Runtime Fabric でのイングレスの設定について説明します。以前のイングレスの設定手順については、バージョン 1.8 または 1.9 のドキュメントを参照してください。
Anypoint Runtime Fabric では、イングレスリソーステンプレートを使用してカスタムイングレス設定を指定できます。テンプレートでは、 [Kubernetes イングレス仕様](https://kubernetes.io/docs/concepts/services-networking/ingress/)​と同様、アノテーション、イングレスクラス名、および HTTP および HTTPS ルールを指定できます。 アプリケーションのイングレスリソーステンプレートを適用しない場合、デプロイしたときにイングレスエンドポイントを追加できません。

デフォルトでは、Google Kubernetes Engine (GKE) と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、 「Default Ingress Controller Behavior with Runtime Fabric on GKE (GKE での Runtime Fabric を使用したデフォルトのイングレスコントローラーの動作)」​を参照してください。

AWS アプリケーションのロードバランサーでは、​group.name​ アノテーションを使用しない限り同様の動作になります。詳細は、 「Application load balancing on Amazon EKS (Amazon EKS でのアプリケーションの負荷分散)」​を参照してください。
## [](#カスタムイングレスリソーステンプレートの利点)カスタムイングレスリソーステンプレートの利点 Runtime Fabric でカスタムイングレスリソーステンプレートを使用すれば、以下に対するサポートを含めてネイティブ Kubernetes イングレス設定機能を活用できます。 - アプリケーションごとに複数のイングレス設定 - 同じ Runtime Fabric インスタンス内の複数のイングレスコントローラー - TLS および HTTPS 設定 - カスタム URL 名前付け - URL パラメーターのプレースホルダー ## [](#runtime-fabric-でのイングレスリソーステンプレートの動作)Runtime Fabric でのイングレスリソーステンプレートの動作 次の図では、Runtime Fabric でイングレスリソーステンプレートを使用する方法の概要を示しています。 ![Runtime Fabric でのイングレステンプレートワークフローを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/ingress-diagram.png) 1. IT 管理者がイングレスコントローラーを設定します。 2. IT 管理者が必須パラメーターを使用してイングレスリソーステンプレートを作成または変更します。イングレスコントローラーの動作はそれぞれ異なります。イングレスコントローラーのドキュメントを確認して、アノテーションを調整してください。 3. IT 管理者が ​`kubectl apply`​ コマンドを使用してテンプレートを適用します。 4. 適用されたテンプレートから、Runtime Fabric によってプレースホルダーの URI ドメインが作成され、すべてのアプリケーションデプロイメントのテンプレートとして Anypoint Runtime Manager でイングレス設定が伝播されます。 5. Mule アプリケーション開発者が Runtime Manager を使用して、イングレステンプレートで指定されているように、使用可能なホスト、省略可能なサブドメイン、およびパスの組み合わせを選択することでデプロイメントのアプリケーションを設定します。 6. Runtime Fabric によってアプリケーションデプロイメント要求が受信され、テンプレートのイングレス設定を使用してクラスターで対応するイングレスオブジェクトが作成されます。 ## [](#イングレスリソーステンプレートの例)イングレスリソーステンプレートの例 次の例では、Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 お使いの Kubernetes バージョンに適した API バージョンを使用してください。 - Kubernetes v1.19 以降: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 Kubernetes v1.22 以降では、​`extensions/v1beta1`​ および ​`networking.k8s.io/v1beta1`​ API バージョンのイングレスは使用できません。 - Kubernetes v1.18 以前: - networking.k8s.io/v1beta1 のみ ### [](#networking-k8s-iov1)networking.k8s.io/v1

このテンプレートは設定の簡略化バージョンです。テンプレートの最終的な設定は、使用しているコントローラーおよびイングレスのルーティングルールに応じて異なる場合があります。お使いのイングレスコントローラーのドキュメントを慎重にお読みください。
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#networking-k8s-iov1beta1)networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。 Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#テンプレートのプレースホルダー)テンプレートのプレースホルダー 次のプレースホルダーは省略可能です。プレースホルダーを使用する場合、テンプレートの適切な場所で置き換えてください。プレースホルダーは小文字にしてください。
プレースホルダーの名前 場所 値の例

business-group-id

path​、​host​、​annotation、labels

 
labels:
  business:
  business-group-id

environment-id

path​、​host​、​annotation、labels

 
labels:
  environment:
  environment-id

unique-id

path​、​annotation、labels

 
path: /app-name-unique-id.com
`unique-id`​ プレースホルダーを使用して一意のアプリケーション URL を作成します。この方法は、異なるビジネスグループから同じ名前を持つ 2 つのアプリケーションをデプロイする場合に便利です。たとえば、イングレステンプレートの ​`path`​ セクションで ​`app-name-unique-id.com`​ を使用する場合、生成されるエンドポイントは ​`app-name-7jkbic.com`​ のようになります。

unique-id​ プレースホルダーは Runtime Fabric バージョン 1.12.28 以降で使用できます。
## [](#イングレステンプレートでの-tls-の使用)イングレステンプレートでの TLS の使用 イングレステンプレートで TLS を使用するには、TLS シークレットを作成する必要があります。詳細は、 [Kubernetes TLS のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)​を参照してください。 `rtf.mulesoft.com/synchronized=true`​ 表示ラベルを使用して、たとえば次のように、TLS シークレットの更新をすべてのアプリケーション名前空間に同期するように Runtime Fabric を設定できます。 ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized=true data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` この表示ラベルをシークレットに適用すると、イングレスコントローラーで更新済みの TLS 素材をアプリケーション名前空間にすぐに適用できるようになります。この表示ラベルを追加しない場合は、各名前空間でシークレットを手動で更新する必要があります。
同期メカニズムを使用して、デプロイ時に Runtime Fabric エージェントの名前空間のシークレットをアプリケーションの名前空間に複製できます。
## [](#既存のイングレステンプレートを変更する)既存のイングレステンプレートを変更する 既存のイングレステンプレートは、すでにアプリケーションのデプロイで使用されている場合でも修正できます。 テンプレートを変更しても、このテンプレートに基づいてすでに作成されているイングレスオブジェクトは更新されません。 テンプレートの変更を反映して既存のイングレスを更新するには、Mule アプリケーションを再デプロイする必要があります。 たとえば、ベースドメインを更新してイングレステンプレートのエンドポイントの変更が必要になった場合は、古いエンドポイントを削除して、アプリケーションの再デプロイ時に新しいエンドポイントを追加します。 `ServiceResourceWatcher`​ (Runtime Fabric エージェントのコンポーネント) がイングレステンプレートの変更を検出した後で既存のサービスを処理すると、他の変更が有効になります。そのため、すべてのサービスが調整されるように、イングレステンプレートの変更直後に Runtime Fabric エージェントを再起動します。 ## [](#runtime-fabric-で-mule-アプリケーションデプロイメント用のイングレスを設定する)Runtime Fabric で Mule アプリケーションデプロイメント用のイングレスを設定する イングレスを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#始める前に)始める前に Runtime Fabric でイングレスをセットアップする前に、イングレスコントローラーを設定する必要があります。イングレスコントローラーのリストについては、 [Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)​を参照してください。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-templates)​のいずれかを使用してイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#既存のイングレス設定のアップグレード後の変換)既存のイングレス設定のアップグレード後の変換 Runtime Fabric バージョン 1.10 にアップグレードする場合、アップグレードプロセスでアノテーション、パス、名前空間、ホストパラメーターを含む既存のイングレスの ConfigMaps が自動的にイングレスリソーステンプレート形式に変換されます。次の表を確認して、アップグレード後にアクションが必要かどうかを判断してください。
アップグレード前の Runtime Fabric アップグレード後の Runtime Fabric 必要なアクション TLS サポート

ドメインは設定されず、ingress-ConfigMap は適用されない

アップグレード後にテンプレートが自動的に生成されない

テンプレートを作成する。​[Create an Ingress Resource Template and Apply it in the Cluster]​を参照してください。

-

ドメインは設定されないが、有効な ingress-ConfigMap が適用される

生成されたテンプレートにホストの ​*​ が含まれ、以前の ingress-ConfigMap のパスおよびアノテーションが含まれる

生成されたテンプレートで ​host​ 項目を編集し、Runtime Manager でアプリケーションをデプロイするための有効なホスト/ドメインを指定する

デフォルトでは TLS セクションは追加されない

有効なドメインが設定されるが、ingress-ConfigMap は適用されない

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、各テンプレートのパスに ​/app-name​ が含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる

有効なドメインが設定され、有効な ingress-ConfigMap が適用される

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、以前の ingress-ConfigMap のパスおよびアノテーションがすべて含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる
## [](#イングレスの問題のトラブルシューティング)イングレスの問題のトラブルシューティング Runtime Fabric にイングレスを使用しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#mule-アプリケーションをデプロイしたがそのエンドポイントにアクセスできない)Mule アプリケーションをデプロイしたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager で Mule アプリケーションを正常にデプロイしましたが、アプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. アプリケーションがポート 8081 でリスンしていることを確認します。 ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. アプリケーションが実行されていて HTTP 要求に応答していることを確認します。 ```copy curl -v \http://127.0.0.1:8081/ ``` これにより、API アクセスの問題が Mule アプリケーション自体にあるかどうかを判断できます。 3. そのアプリケーションサービスのイングレスリソースが存在することを検証します。 ```copy kubectl get ingress -n [NAMESPACE] ``` 4. サービスが作成されたことを検証します。 ```copy kubectl get svc -n [NAMESPACE] ``` 作成されなかった場合は、Runtime Fabric エージェントのログを確認します。 + ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` サービスおよびイングレスオブジェクトに問題がないように思われる場合は、その他のトラブルシューティングタスクを確認してください。 ### [](#イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない)イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager ではクラスターでイングレスリソースが正常に作成されましたが、404 エラーのためにアプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. イングレスとサービスのリソースを確認します。 ```copy kubectl get ingress -n kubectl get svc -n ``` 次のような結果が返されます。 \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. アプリケーションのイングレスリソースを確認して、リソース、アノテーション、ホストの HTTP パスが正常に表示されることを確認します。 ```copy kubectl get ing -n -oyaml ``` 次のような結果が返されます。 ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. アプリケーションポッドログを確認して、適切なリスニングポートを設定していることを確認します。 ```copy kubectl logs -f -n -c app ``` 次のような結果が返されます。 \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. ログで、リスナーポートがステップ 1 で検出されたサービスポートに一致することを確認します。 5. ポートが正しい場合、アプリケーションログを確認してアプリケーションがイングレスコントローラーからの要求を受信していることを確認します。 ### [](#イングレスリソースが-aws-アプリケーションのロードバランサーによって認識されない)イングレスリソースが AWS アプリケーションのロードバランサーによって認識されない シナリオ: AWS ALB を使用している場合、アプリケーションおよびエンドポイントを正常にデプロイした場合でもアプリケーションのエンドポイントにアクセスできません。 イングレスに AWS ロードバランサーコントローラーを使用している場合、​`ingressClassName: rtf-alb` ​_ではなく_​テンプレートで ​`kubernetes.io/ingress.class: rtf-alb`​ アノテーションを指定する必要があります。AWS ロードバランサーコントローラーがこれらのアノテーションのためにデプロイされたイングレスリソース用の L7 ロードバランサーを検出して作成するには、​`ingress.class`​ アノテーションが必要です。 # Runtime Fabric のイングレスの設定

このコンテンツでは、バージョン 1.10 以降の Runtime Fabric でのイングレスの設定について説明します。以前のイングレスの設定手順については、バージョン 1.8 または 1.9 のドキュメントを参照してください。
Anypoint Runtime Fabric では、イングレスリソーステンプレートを使用してカスタムイングレス設定を指定できます。テンプレートでは、 [Kubernetes イングレス仕様](https://kubernetes.io/docs/concepts/services-networking/ingress/)​と同様、アノテーション、イングレスクラス名、および HTTP および HTTPS ルールを指定できます。 アプリケーションのイングレスリソーステンプレートを適用しない場合、デプロイしたときにイングレスエンドポイントを追加できません。

デフォルトでは、Google Kubernetes Engine (GKE) と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、 「Default Ingress Controller Behavior with Runtime Fabric on GKE (GKE での Runtime Fabric を使用したデフォルトのイングレスコントローラーの動作)」​を参照してください。

AWS アプリケーションのロードバランサーでは、​group.name​ アノテーションを使用しない限り同様の動作になります。詳細は、 「Application load balancing on Amazon EKS (Amazon EKS でのアプリケーションの負荷分散)」​を参照してください。
## [](#カスタムイングレスリソーステンプレートの利点)カスタムイングレスリソーステンプレートの利点 Runtime Fabric でカスタムイングレスリソーステンプレートを使用すれば、以下に対するサポートを含めてネイティブ Kubernetes イングレス設定機能を活用できます。 - アプリケーションごとに複数のイングレス設定 - 同じ Runtime Fabric インスタンス内の複数のイングレスコントローラー - TLS および HTTPS 設定 - カスタム URL 名前付け - URL パラメーターのプレースホルダー ## [](#runtime-fabric-でのイングレスリソーステンプレートの動作)Runtime Fabric でのイングレスリソーステンプレートの動作 次の図では、Runtime Fabric でイングレスリソーステンプレートを使用する方法の概要を示しています。 ![Runtime Fabric でのイングレステンプレートワークフローを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/ingress-diagram.png) 1. IT 管理者がイングレスコントローラーを設定します。 2. IT 管理者が必須パラメーターを使用してイングレスリソーステンプレートを作成または変更します。イングレスコントローラーの動作はそれぞれ異なります。イングレスコントローラーのドキュメントを確認して、アノテーションを調整してください。 3. IT 管理者が ​`kubectl apply`​ コマンドを使用してテンプレートを適用します。 4. 適用されたテンプレートから、Runtime Fabric によってプレースホルダーの URI ドメインが作成され、すべてのアプリケーションデプロイメントのテンプレートとして Anypoint Runtime Manager でイングレス設定が伝播されます。 5. Mule アプリケーション開発者が Runtime Manager を使用して、イングレステンプレートで指定されているように、使用可能なホスト、省略可能なサブドメイン、およびパスの組み合わせを選択することでデプロイメントのアプリケーションを設定します。 6. Runtime Fabric によってアプリケーションデプロイメント要求が受信され、テンプレートのイングレス設定を使用してクラスターで対応するイングレスオブジェクトが作成されます。 ## [](#イングレスリソーステンプレートの例)イングレスリソーステンプレートの例 次の例では、Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 お使いの Kubernetes バージョンに適した API バージョンを使用してください。 - Kubernetes v1.19 以降: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 Kubernetes v1.22 以降では、​`extensions/v1beta1`​ および ​`networking.k8s.io/v1beta1`​ API バージョンのイングレスは使用できません。 - Kubernetes v1.18 以前: - networking.k8s.io/v1beta1 のみ ### [](#networking-k8s-iov1)networking.k8s.io/v1

このテンプレートは設定の簡略化バージョンです。テンプレートの最終的な設定は、使用しているコントローラーおよびイングレスのルーティングルールに応じて異なる場合があります。お使いのイングレスコントローラーのドキュメントを慎重にお読みください。
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#networking-k8s-iov1beta1)networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。 Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#テンプレートのプレースホルダー)テンプレートのプレースホルダー 次のプレースホルダーは省略可能です。プレースホルダーを使用する場合、テンプレートの適切な場所で置き換えてください。プレースホルダーは小文字にしてください。
プレースホルダーの名前 場所 値の例

business-group-id

path​、​host​、​annotation、labels

 
labels:
  business:
  business-group-id

environment-id

path​、​host​、​annotation、labels

 
labels:
  environment:
  environment-id

unique-id

path​、​annotation、labels

 
path: /app-name-unique-id.com
`unique-id`​ プレースホルダーを使用して一意のアプリケーション URL を作成します。この方法は、異なるビジネスグループから同じ名前を持つ 2 つのアプリケーションをデプロイする場合に便利です。たとえば、イングレステンプレートの ​`path`​ セクションで ​`app-name-unique-id.com`​ を使用する場合、生成されるエンドポイントは ​`app-name-7jkbic.com`​ のようになります。

unique-id​ プレースホルダーは Runtime Fabric バージョン 1.12.28 以降で使用できます。
## [](#イングレステンプレートでの-tls-の使用)イングレステンプレートでの TLS の使用 イングレステンプレートで TLS を使用するには、TLS シークレットを作成する必要があります。詳細は、 [Kubernetes TLS のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)​を参照してください。 `rtf.mulesoft.com/synchronized: "true"`​ 表示ラベルを使用して、たとえば次のように、TLS シークレットの更新をすべてのアプリケーション名前空間に同期するように Runtime Fabric を設定できます。 ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` この表示ラベルをシークレットに適用すると、イングレスコントローラーで更新済みの TLS 素材をアプリケーション名前空間にすぐに適用できるようになります。この表示ラベルを追加しない場合は、各名前空間でシークレットを手動で更新する必要があります。
同期メカニズムを使用して、デプロイ時に Runtime Fabric エージェントの名前空間のシークレットをアプリケーションの名前空間に複製できます。
## [](#既存のイングレステンプレートを変更する)既存のイングレステンプレートを変更する 既存のイングレステンプレートは、すでにアプリケーションのデプロイで使用されている場合でも修正できます。 テンプレートを変更しても、このテンプレートに基づいてすでに作成されているイングレスオブジェクトは更新されません。 テンプレートの変更を反映して既存のイングレスを更新するには、Mule アプリケーションを再デプロイする必要があります。 たとえば、ベースドメインを更新してイングレステンプレートのエンドポイントの変更が必要になった場合は、古いエンドポイントを削除して、アプリケーションの再デプロイ時に新しいエンドポイントを追加します。 ## [](#runtime-fabric-で-mule-アプリケーションデプロイメント用のイングレスを設定する)Runtime Fabric で Mule アプリケーションデプロイメント用のイングレスを設定する イングレスを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#始める前に)始める前に Runtime Fabric でイングレスをセットアップする前に、イングレスコントローラーを設定する必要があります。イングレスコントローラーのリストについては、 [Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)​を参照してください。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-templates)​のいずれかを使用してイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#既存のイングレス設定のアップグレード後の変換)既存のイングレス設定のアップグレード後の変換 Runtime Fabric バージョン 1.10 にアップグレードする場合、アップグレードプロセスでアノテーション、パス、名前空間、ホストパラメーターを含む既存のイングレスの ConfigMaps が自動的にイングレスリソーステンプレート形式に変換されます。次の表を確認して、アップグレード後にアクションが必要かどうかを判断してください。
アップグレード前の Runtime Fabric アップグレード後の Runtime Fabric 必要なアクション TLS サポート

ドメインは設定されず、ingress-ConfigMap は適用されない

アップグレード後にテンプレートが自動的に生成されない

テンプレートを作成する。​[Create an Ingress Resource Template and Apply it in the Cluster]​を参照してください。

-

ドメインは設定されないが、有効な ingress-ConfigMap が適用される

生成されたテンプレートにホストの ​*​ が含まれ、以前の ingress-ConfigMap のパスおよびアノテーションが含まれる

生成されたテンプレートで ​host​ 項目を編集し、Runtime Manager でアプリケーションをデプロイするための有効なホスト/ドメインを指定する

デフォルトでは TLS セクションは追加されない

有効なドメインが設定されるが、ingress-ConfigMap は適用されない

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、各テンプレートのパスに ​/app-name​ が含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる

有効なドメインが設定され、有効な ingress-ConfigMap が適用される

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、以前の ingress-ConfigMap のパスおよびアノテーションがすべて含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる
## [](#イングレスの問題のトラブルシューティング)イングレスの問題のトラブルシューティング Runtime Fabric にイングレスを使用しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#mule-アプリケーションをデプロイしたがそのエンドポイントにアクセスできない)Mule アプリケーションをデプロイしたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager で Mule アプリケーションを正常にデプロイしましたが、アプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. アプリケーションがポート 8081 でリスンしていることを確認します。 ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. アプリケーションが実行されていて HTTP 要求に応答していることを確認します。 ```copy curl -v \http://127.0.0.1:8081/ ``` これにより、API アクセスの問題が Mule アプリケーション自体にあるかどうかを判断できます。 3. そのアプリケーションサービスのイングレスリソースが存在することを検証します。 ```copy kubectl get ingress -n [NAMESPACE] ``` 4. サービスが作成されたことを検証します。 ```copy kubectl get svc -n [NAMESPACE] ``` 作成されなかった場合は、Runtime Fabric エージェントのログを確認します。 + ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` サービスおよびイングレスオブジェクトに問題がないように思われる場合は、その他のトラブルシューティングタスクを確認してください。 ### [](#イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない)イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager ではクラスターでイングレスリソースが正常に作成されましたが、404 エラーのためにアプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. イングレスとサービスのリソースを確認します。 ```copy kubectl get ingress -n kubectl get svc -n ``` 次のような結果が返されます。 \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. アプリケーションのイングレスリソースを確認して、リソース、アノテーション、ホストの HTTP パスが正常に表示されることを確認します。 ```copy kubectl get ing -n -oyaml ``` 次のような結果が返されます。 ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. アプリケーションポッドログを確認して、適切なリスニングポートを設定していることを確認します。 ```copy kubectl logs -f -n -c app ``` 次のような結果が返されます。 \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. ログで、リスナーポートがステップ 1 で検出されたサービスポートに一致することを確認します。 5. ポートが正しい場合、アプリケーションログを確認してアプリケーションがイングレスコントローラーからの要求を受信していることを確認します。 ### [](#イングレスリソースが-aws-アプリケーションのロードバランサーによって認識されない)イングレスリソースが AWS アプリケーションのロードバランサーによって認識されない シナリオ: AWS ALB を使用している場合、アプリケーションおよびエンドポイントを正常にデプロイした場合でもアプリケーションのエンドポイントにアクセスできません。 イングレスに AWS ロードバランサーコントローラーを使用している場合、​`ingressClassName: rtf-alb` ​_ではなく_​テンプレートで ​`kubernetes.io/ingress.class: rtf-alb`​ アノテーションを指定する必要があります。AWS ロードバランサーコントローラーがこれらのアノテーションのためにデプロイされたイングレスリソース用の L7 ロードバランサーを検出して作成するには、​`ingress.class`​ アノテーションが必要です。 # Runtime Fabric のイングレスの設定

このコンテンツでは、バージョン 1.10 以降の Runtime Fabric でのイングレスの設定について説明します。以前のイングレスの設定手順については、バージョン 1.8 または 1.9 のドキュメントを参照してください。
Anypoint Runtime Fabric では、イングレスリソーステンプレートを使用してカスタムイングレス設定を指定できます。テンプレートでは、 [Kubernetes イングレス仕様](https://kubernetes.io/docs/concepts/services-networking/ingress/)​と同様、アノテーション、イングレスクラス名、および HTTP および HTTPS ルールを指定できます。 アプリケーションのイングレスリソーステンプレートを適用しない場合、デプロイしたときにイングレスエンドポイントを追加できません。

デフォルトでは、Google Kubernetes Engine (GKE) と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、 「Default Ingress Controller Behavior with Runtime Fabric on GKE (GKE での Runtime Fabric を使用したデフォルトのイングレスコントローラーの動作)」​を参照してください。

AWS アプリケーションのロードバランサーでは、​group.name​ アノテーションを使用しない限り同様の動作になります。詳細は、 「Application load balancing on Amazon EKS (Amazon EKS でのアプリケーションの負荷分散)」​を参照してください。
## [](#カスタムイングレスリソーステンプレートの利点)カスタムイングレスリソーステンプレートの利点 Runtime Fabric でカスタムイングレスリソーステンプレートを使用すれば、以下に対するサポートを含めてネイティブ Kubernetes イングレス設定機能を活用できます。 - アプリケーションごとに複数のイングレス設定 - 同じ Runtime Fabric インスタンス内の複数のイングレスコントローラー - TLS および HTTPS 設定 - カスタム URL 名前付け - URL パラメーターのプレースホルダー ## [](#runtime-fabric-でのイングレスリソーステンプレートの動作)Runtime Fabric でのイングレスリソーステンプレートの動作 次の図では、Runtime Fabric でイングレスリソーステンプレートを使用する方法の概要を示しています。 ![Runtime Fabric でのイングレステンプレートワークフローを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/ingress-diagram.png) 1. IT 管理者がイングレスコントローラーを設定します。 2. IT 管理者が必須パラメーターを使用してイングレスリソーステンプレートを作成または変更します。イングレスコントローラーの動作はそれぞれ異なります。イングレスコントローラーのドキュメントを確認して、アノテーションを調整してください。 3. IT 管理者が ​`kubectl apply`​ コマンドを使用してテンプレートを適用します。 4. 適用されたテンプレートから、Runtime Fabric によってプレースホルダーの URI ドメインが作成され、すべてのアプリケーションデプロイメントのテンプレートとして Anypoint Runtime Manager でイングレス設定が伝播されます。 5. Mule アプリケーション開発者が Runtime Manager を使用して、イングレステンプレートで指定されているように、使用可能なホスト、省略可能なサブドメイン、およびパスの組み合わせを選択することでデプロイメントのアプリケーションを設定します。 6. Runtime Fabric によってアプリケーションデプロイメント要求が受信され、テンプレートのイングレス設定を使用してクラスターで対応するイングレスオブジェクトが作成されます。 ## [](#イングレスリソーステンプレートの例)イングレスリソーステンプレートの例 次の例では、Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 お使いの Kubernetes バージョンに適した API バージョンを使用してください。 - Kubernetes v1.19 以降: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 Kubernetes v1.22 以降では、​`extensions/v1beta1`​ および ​`networking.k8s.io/v1beta1`​ API バージョンのイングレスは使用できません。 - Kubernetes v1.18 以前: - networking.k8s.io/v1beta1 のみ ### [](#networking-k8s-iov1)networking.k8s.io/v1

このテンプレートは設定の簡略化バージョンです。テンプレートの最終的な設定は、使用しているコントローラーおよびイングレスのルーティングルールに応じて異なる場合があります。お使いのイングレスコントローラーのドキュメントを慎重にお読みください。
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#networking-k8s-iov1beta1)networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。 Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#テンプレートのプレースホルダー)テンプレートのプレースホルダー 次のプレースホルダーは省略可能です。プレースホルダーを使用する場合、テンプレートの適切な場所で置き換えてください。プレースホルダーは小文字にしてください。
プレースホルダーの名前 場所 値の例

business-group-id

path​、​host​、​annotation、labels

 
labels:
  business:
  business-group-id

environment-id

path​、​host​、​annotation、labels

 
labels:
  environment:
  environment-id

unique-id

path​、​annotation、labels

 
path: /app-name-unique-id.com
`unique-id`​ プレースホルダーを使用して一意のアプリケーション URL を作成します。この方法は、異なるビジネスグループから同じ名前を持つ 2 つのアプリケーションをデプロイする場合に便利です。たとえば、イングレステンプレートの ​`path`​ セクションで ​`app-name-unique-id.com`​ を使用する場合、生成されるエンドポイントは ​`app-name-7jkbic.com`​ のようになります。

unique-id​ プレースホルダーは Runtime Fabric バージョン 1.12.28 以降で使用できます。
## [](#イングレステンプレートでの-tls-の使用)イングレステンプレートでの TLS の使用 イングレステンプレートで TLS を使用するには、TLS シークレットを作成する必要があります。詳細は、 [Kubernetes TLS のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)​を参照してください。 `rtf.mulesoft.com/synchronized: "true"`​ 表示ラベルを使用して、たとえば次のように、TLS シークレットの更新をすべてのアプリケーション名前空間に同期するように Runtime Fabric を設定できます。 ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: labels: rtf.mulesoft.com/synchronized: "true" data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` この表示ラベルをシークレットに適用すると、イングレスコントローラーで更新済みの TLS 素材をアプリケーション名前空間にすぐに適用できるようになります。この表示ラベルを追加しない場合は、各名前空間でシークレットを手動で更新する必要があります。
同期メカニズムを使用して、デプロイ時に Runtime Fabric エージェントの名前空間のシークレットをアプリケーションの名前空間に複製できます。
## [](#既存のイングレステンプレートを変更する)既存のイングレステンプレートを変更する 既存のイングレステンプレートは、すでにアプリケーションのデプロイで使用されている場合でも修正できます。 テンプレートを変更しても、このテンプレートに基づいてすでに作成されているイングレスオブジェクトは更新されません。 テンプレートの変更を反映して既存のイングレスを更新するには、Mule アプリケーションを再デプロイする必要があります。 たとえば、ベースドメインを更新してイングレステンプレートのエンドポイントの変更が必要になった場合は、古いエンドポイントを削除して、アプリケーションの再デプロイ時に新しいエンドポイントを追加します。 ## [](#runtime-fabric-で-mule-アプリケーションデプロイメント用のイングレスを設定する)Runtime Fabric で Mule アプリケーションデプロイメント用のイングレスを設定する イングレスを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#始める前に)始める前に Runtime Fabric でイングレスをセットアップする前に、イングレスコントローラーを設定する必要があります。イングレスコントローラーのリストについては、 [Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)​を参照してください。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-templates)​のいずれかを使用してイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 ```copy kubectl apply -f ``` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 ```copy kubectl describe ingress [Ingress Name] -n rtf ``` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#既存のイングレス設定のアップグレード後の変換)既存のイングレス設定のアップグレード後の変換 Runtime Fabric バージョン 1.10 にアップグレードする場合、アップグレードプロセスでアノテーション、パス、名前空間、ホストパラメーターを含む既存のイングレスの ConfigMaps が自動的にイングレスリソーステンプレート形式に変換されます。次の表を確認して、アップグレード後にアクションが必要かどうかを判断してください。
アップグレード前の Runtime Fabric アップグレード後の Runtime Fabric 必要なアクション TLS サポート

ドメインは設定されず、ingress-ConfigMap は適用されない

アップグレード後にテンプレートが自動的に生成されない

テンプレートを作成する。​[Create an Ingress Resource Template and Apply it in the Cluster]​を参照してください。

-

ドメインは設定されないが、有効な ingress-ConfigMap が適用される

生成されたテンプレートにホストの ​*​ が含まれ、以前の ingress-ConfigMap のパスおよびアノテーションが含まれる

生成されたテンプレートで ​host​ 項目を編集し、Runtime Manager でアプリケーションをデプロイするための有効なホスト/ドメインを指定する

デフォルトでは TLS セクションは追加されない

有効なドメインが設定されるが、ingress-ConfigMap は適用されない

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、各テンプレートのパスに ​/app-name​ が含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる

有効なドメインが設定され、有効な ingress-ConfigMap が適用される

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、以前の ingress-ConfigMap のパスおよびアノテーションがすべて含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる
## [](#イングレスの問題のトラブルシューティング)イングレスの問題のトラブルシューティング Runtime Fabric にイングレスを使用しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#mule-アプリケーションをデプロイしたがそのエンドポイントにアクセスできない)Mule アプリケーションをデプロイしたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager で Mule アプリケーションを正常にデプロイしましたが、アプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. アプリケーションがポート 8081 でリスンしていることを確認します。 ```copy kubectl port-forward -n [NAMESPACE] svc/ 8081:8081 ``` 2. アプリケーションが実行されていて HTTP 要求に応答していることを確認します。 ```copy curl -v \http://127.0.0.1:8081/ ``` これにより、API アクセスの問題が Mule アプリケーション自体にあるかどうかを判断できます。 3. そのアプリケーションサービスのイングレスリソースが存在することを検証します。 ```copy kubectl get ingress -n [NAMESPACE] ``` 4. サービスが作成されたことを検証します。 ```copy kubectl get svc -n [NAMESPACE] ``` 作成されなかった場合は、Runtime Fabric エージェントのログを確認します。 + ```copy kubectl logs -n rtf [AGENT_POD_NAME] -f ``` サービスおよびイングレスオブジェクトに問題がないように思われる場合は、その他のトラブルシューティングタスクを確認してください。 ### [](#イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない)イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager ではクラスターでイングレスリソースが正常に作成されましたが、404 エラーのためにアプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. イングレスとサービスのリソースを確認します。 ```copy kubectl get ingress -n kubectl get svc -n ``` 次のような結果が返されます。 \# kubectl get ingress -n NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s # kubectl get svc -n NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. アプリケーションのイングレスリソースを確認して、リソース、アノテーション、ホストの HTTP パスが正常に表示されることを確認します。 ```copy kubectl get ing -n -oyaml ``` 次のような結果が返されます。 ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. アプリケーションポッドログを確認して、適切なリスニングポートを設定していることを確認します。 ```copy kubectl logs -f -n -c app ``` 次のような結果が返されます。 \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. ログで、リスナーポートがステップ 1 で検出されたサービスポートに一致することを確認します。 5. ポートが正しい場合、アプリケーションログを確認してアプリケーションがイングレスコントローラーからの要求を受信していることを確認します。 ### [](#イングレスリソースが-aws-アプリケーションのロードバランサーによって認識されない)イングレスリソースが AWS アプリケーションのロードバランサーによって認識されない シナリオ: AWS ALB を使用している場合、アプリケーションおよびエンドポイントを正常にデプロイした場合でもアプリケーションのエンドポイントにアクセスできません。 イングレスに AWS ロードバランサーコントローラーを使用している場合、​`ingressClassName: rtf-alb` ​_ではなく_​テンプレートで ​`kubernetes.io/ingress.class: rtf-alb`​ アノテーションを指定する必要があります。AWS ロードバランサーコントローラーがこれらのアノテーションのためにデプロイされたイングレスリソース用の L7 ロードバランサーを検出して作成するには、​`ingress.class`​ アノテーションが必要です。 # Runtime Fabric のインストール Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - [rtfctl を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed) - [Helm を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-helm) - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-openshift) # Runtime Fabric のインストール Anypoint Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - [RTFCTL を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric をインストールします。 - [Helm を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-helm) Kubernetes 向け Helm パッケージマネージャーを使用して Runtime Fabric をインストールします。 - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-openshift) Kubernetes オペレーターとして Runtime Fabric をインストールします。 - [単一クラスターへの複数のインスタンスのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-multiple-instances) Runtime Fabric の複数のインスタンスをインストールして、複数の Runtime Fabric で同じクラスターを共有します。 - [単一 OpenShift クラスターへの複数のインスタンスのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-multiple-instances-openshift) Runtime Fabric の複数のインスタンスをインストールして、複数の Runtime Fabric で同じ OpenShift クラスターを共有します。 ## [](#関連情報)関連情報 - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configuring-runtime-fabric) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/uninstall-self) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-index) # Runtime Fabric のインストール Anypoint Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - [RTFCTL を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric をインストールします。 - [Helm を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-helm) Kubernetes 向け Helm パッケージマネージャーを使用して Runtime Fabric をインストールします。 - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-openshift) Kubernetes オペレーターとして Runtime Fabric をインストールします。 - [単一クラスターへの複数のインスタンスのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-multiple-instances) Runtime Fabric の複数のインスタンスをインストールして、複数の Runtime Fabric で同じクラスターを共有します。 - [単一 OpenShift クラスターへの複数のインスタンスのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-multiple-instances-openshift) Runtime Fabric の複数のインスタンスをインストールして、複数の Runtime Fabric で同じ OpenShift クラスターを共有します。 ## [](#関連情報)関連情報 - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configuring-runtime-fabric) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/uninstall-self) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-index) # Runtime Fabric のインストール Anypoint Runtime Fabric をインストールするには、次のいずれかのオプションを選択します。 - [RTFCTL を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric をインストールします。 - [Helm を使用した Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-helm) Kubernetes 向け Helm パッケージマネージャーを使用して Runtime Fabric をインストールします。 - [Kubernetes (K8s) オペレーターとしての Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-openshift) Kubernetes オペレーターとして Runtime Fabric をインストールします。 - [単一クラスターへの複数のインスタンスのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-multiple-instances) Runtime Fabric の複数のインスタンスをインストールして、複数の Runtime Fabric で同じクラスターを共有します。 - [単一 OpenShift クラスターへの複数のインスタンスのインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-multiple-instances-openshift) Runtime Fabric の複数のインスタンスをインストールして、複数の Runtime Fabric で同じ OpenShift クラスターを共有します。 ## [](#関連情報)関連情報 - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configuring-runtime-fabric) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/uninstall-self) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-index) # Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備 MuleSoft では、Kubernetes (K8s) の重大度の高い脆弱性に対する迅速なパッチの提供と、MuleSoft で既存の K8s への投資や運用実績をさらに活用するための方法を求めるフィードバックをお客様から頂いています。ご要望に応えるため、MuleSoft は、AWS、Microsoft、Google、IBM といった業界をリードする管理 K8s プラットフォームベンダーと提携しました。その結果、MuleSoft は、これらのベンダーが開発した安全で可用性の高い管理 K8s プラットフォーム経由での K8s の提供に積極的に移行しつつあり、可視性や拡張性に限界がある Runtime Fabric アプライアンスのブラックボックスアプローチへの投資を終了します。 Runtime Fabric は、AWS、Google、Microsoft、そして IBM の RedHat Openshift ソリューションとの互換性があります。これらのソリューションでは、一貫したセキュリティパッチが迅速に提供されます。これらのインテグレーションにより、Kubernetes エコシステムへのこれまでの投資を容易に活用できます。 パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の自己管理 Red Hat OpenShift 製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) これらのいずれかのソリューションを利用してクラスター上で K8s を設定したら、Runtime Fabric のインストールセクションに進んで、AKS や EKS へのインストールと同じように Runtime Fabric を設定してください。 ## [](#アプライアンスユーザー向けの変更)アプライアンスユーザー向けの変更 既存のアプライアンスユーティリティユーザーは、現在 Runtime Fabric アプライアンスデプロイメントに割り当てられているライセンス済みのコア容量を、公開クラウド上の Runtime Fabric、OpenShift、Mule Runtime Standalone など、お客様がホストする任意のデプロイメントに移行できます。Flexible Hybrid Deployment 権を持つお客様は、vCore を使用するようにコアを変換して、この容量を CloudHub 2.0 上で利用することもできます。 ## [](#選択可能な移行オプション)選択可能な移行オプション - サービスとしてのインテグレーションプラットフォームを探しているのであれば、 [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration)​ をお勧めします。この MuleSoft のフラッグシップ製品は、運用オーバーヘッドを最小限に抑えています。 - 公開クラウドの知識と Kubernetes クラスターの管理についてある程度の専門知識がある場合は、​[公開クラウドの Kubernetes クラスター上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ に移行してください。Runtime Fabric は以下のクラウドでサポートされます。 - [AWS Elastic Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [AWS EKS-Anywhere 上の Runtime Fabric](https://aws.amazon.com/eks/eks-anywhere/) - [Google Kubernetes Engine 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Microsoft Azure Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - 公開 Kubernetes ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、 [IBM OpenShift 製品でサポートされる Runtime Fabric](https://www.youtube.com/watch?v=MYOeX5qjYew)​ の説明に従ってください。次の 7 つの製品には、事前作成された認定済みアセット、コネクタ、オペレーターが含まれているため、オンプレミスと公開クラウドのベアメタルソリューションの両方を実装できます。 - 管理クラウドサービス - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - 自己管理型サービス - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - Kubernetes に投資しておらず、自社でホストしている環境を使い続ける場合は、Mule Runtime Standalone を利用できます。このデプロイメントモデルは、ランタイムの弾力性と過剰な管理オーバーヘッドを抑えています。 ## [](#ユーザーが利用できるアクションアプライアンス)ユーザーが利用できるアクションアプライアンス EOL 期日までに上記のいずれかのオプションを選択して移行を済ませてください。 標準サポート、拡張サポート、EOL サポートの詳細は、 [「バージョン設定ポリシーとサポートポリシー」](https://www.mulesoft.com/legal/versioning-back-support-policy#support-matrix)​を参照してください。 # Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備 MuleSoft では、Kubernetes (K8s) の重大度の高い脆弱性に対する迅速なパッチの提供と、MuleSoft で既存の K8s への投資や運用実績をさらに活用するための方法を求めるフィードバックをお客様から頂いています。ご要望に応えるため、MuleSoft は、AWS、Microsoft、Google、IBM といった業界をリードする管理 K8s プラットフォームベンダーと提携しました。その結果、MuleSoft は、これらのベンダーが開発した安全で可用性の高い管理 K8s プラットフォーム経由での K8s の提供に積極的に移行しつつあり、可視性や拡張性に限界がある Runtime Fabric アプライアンスのブラックボックスアプローチへの投資を終了します。 Runtime Fabric は、AWS、Google、Microsoft、そして IBM の RedHat Openshift ソリューションとの互換性があります。これらのソリューションでは、一貫したセキュリティパッチが迅速に提供されます。これらのインテグレーションにより、Kubernetes エコシステムへのこれまでの投資を容易に活用できます。 パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の自己管理 Red Hat OpenShift 製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) これらのいずれかのソリューションを利用してクラスター上で K8s をセットアップしたら、Runtime Fabric のインストールセクションに進んで、AKS や EKS へのインストールと同じように Runtime Fabric を設定してください。 ## [](#アプライアンスユーザー向けの変更)アプライアンスユーザー向けの変更 既存のアプライアンスユーティリティユーザーは、現在 Runtime Fabric アプライアンスデプロイメントに割り当てられているライセンス済みのコア容量を、公開クラウド上の Runtime Fabric、OpenShift、Mule Runtime Standalone など、お客様がホストする任意のデプロイメントに移行できます。Flexible Hybrid Deployment 権を持つお客様は、vCore を使用するようにコアを変換して、この容量を CloudHub 2.0 上で利用することもできます。 ## [](#選択可能な移行オプション)選択可能な移行オプション - サービスとしてのインテグレーションプラットフォームを探しているのであれば、 [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration)​ をお勧めします。この MuleSoft のフラッグシップ製品は、運用オーバーヘッドを最小限に抑えています。 - 公開クラウドの知識と Kubernetes クラスターの管理についてある程度の専門知識がある場合は、​[公開クラウドの Kubernetes クラスター上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ に移行してください。Runtime Fabric は以下のクラウドでサポートされます。 - [AWS Elastic Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [AWS EKS-Anywhere 上の Runtime Fabric](https://aws.amazon.com/eks/eks-anywhere/) - [Google Kubernetes Engine 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Microsoft Azure Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - 公開 Kubernetes ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、 [IBM OpenShift 製品でサポートされる Runtime Fabric](https://www.youtube.com/watch?v=MYOeX5qjYew)​ の説明に従ってください。次の 7 つの製品には、事前作成された認定済みアセット、コネクタ、オペレーターが含まれているため、オンプレミスと公開クラウドのベアメタルソリューションの両方を実装できます。 - 管理クラウドサービス - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - 自己管理型サービス - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - Kubernetes に投資しておらず、自社でホストしている環境を使い続ける場合は、Mule Runtime Standalone を利用できます。このデプロイメントモデルは、ランタイムの弾力性と過剰な管理オーバーヘッドを抑えています。 ## [](#ユーザーが利用できるアクションアプライアンス)ユーザーが利用できるアクションアプライアンス EOL 期日までに上記のいずれかのオプションを選択して移行を済ませてください。 標準サポート、拡張サポート、EOL サポートの詳細は、 [「バージョン設定ポリシーとサポートポリシー」](https://www.mulesoft.com/legal/versioning-back-support-policy#support-matrix)​を参照してください。 # Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備 MuleSoft では、Kubernetes (K8s) の重大度の高い脆弱性に対する迅速なパッチの提供と、MuleSoft で既存の K8s への投資や運用実績をさらに活用するための方法を求めるフィードバックをお客様から頂いています。ご要望に応えるため、MuleSoft は、AWS、Microsoft、Google、IBM といった業界をリードする管理 K8s プラットフォームベンダーと提携しました。その結果、MuleSoft は、これらのベンダーが開発した安全で可用性の高い管理 K8s プラットフォーム経由での K8s の提供に積極的に移行しつつあり、可視性や拡張性に限界がある Runtime Fabric アプライアンスのブラックボックスアプローチへの投資を終了します。 Runtime Fabric は、AWS、Google、Microsoft、そして IBM の RedHat Openshift ソリューションとの互換性があります。これらのソリューションでは、一貫したセキュリティパッチが迅速に提供されます。これらのインテグレーションにより、Kubernetes エコシステムへのこれまでの投資を容易に活用できます。 パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の自己管理 Red Hat OpenShift 製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) これらのいずれかのソリューションを利用してクラスター上で K8s をセットアップしたら、Runtime Fabric のインストールセクションに進んで、AKS や EKS へのインストールと同じように Runtime Fabric を設定してください。 ## [](#アプライアンスユーザー向けの変更)アプライアンスユーザー向けの変更 既存のアプライアンスユーティリティユーザーは、現在 Runtime Fabric アプライアンスデプロイメントに割り当てられているライセンス済みのコア容量を、公開クラウド上の Runtime Fabric、OpenShift、Mule Runtime Standalone など、お客様がホストする任意のデプロイメントに移行できます。Flexible Hybrid Deployment 権を持つお客様は、vCore を使用するようにコアを変換して、この容量を CloudHub 2.0 上で利用することもできます。 ## [](#選択可能な移行オプション)選択可能な移行オプション - サービスとしてのインテグレーションプラットフォームを探しているのであれば、 [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration)​ をお勧めします。この MuleSoft のフラッグシップ製品は、運用オーバーヘッドを最小限に抑えています。 - 公開クラウドの知識と Kubernetes クラスターの管理についてある程度の専門知識がある場合は、​[公開クラウドの Kubernetes クラスター上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ に移行してください。Runtime Fabric は以下のクラウドでサポートされます。 - [AWS Elastic Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [AWS EKS-Anywhere 上の Runtime Fabric](https://aws.amazon.com/eks/eks-anywhere/) - [Google Kubernetes Engine 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Microsoft Azure Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - 公開 Kubernetes ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、 [IBM OpenShift 製品でサポートされる Runtime Fabric](https://www.youtube.com/watch?v=MYOeX5qjYew)​ の説明に従ってください。次の 7 つの製品には、事前作成された認定済みアセット、コネクタ、オペレーターが含まれているため、オンプレミスと公開クラウドのベアメタルソリューションの両方を実装できます。 - 管理クラウドサービス - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - 自己管理型サービス - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - Kubernetes に投資しておらず、自社でホストしている環境を使い続ける場合は、Mule Runtime Standalone を利用できます。このデプロイメントモデルは、ランタイムの弾力性と過剰な管理オーバーヘッドを抑えています。 ## [](#ユーザーが利用できるアクションアプライアンス)ユーザーが利用できるアクションアプライアンス EOL 期日までに上記のいずれかのオプションを選択して移行を済ませてください。 標準サポート、拡張サポート、EOL サポートの詳細は、 [「バージョン設定ポリシーとサポートポリシー」](https://www.mulesoft.com/legal/versioning-back-support-policy#support-matrix)​を参照してください。 # Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備 MuleSoft では、Kubernetes (K8s) の重大度の高い脆弱性に対する迅速なパッチの提供と、MuleSoft で既存の K8s への投資や運用実績をさらに活用するための方法を求めるフィードバックをお客様から頂いています。ご要望に応えるため、MuleSoft は、AWS、Microsoft、Google、IBM といった業界をリードする管理 K8s プラットフォームベンダーと提携しました。その結果、MuleSoft は、これらのベンダーが開発した安全で可用性の高い管理 K8s プラットフォーム経由での K8s の提供に積極的に移行しつつあり、可視性や拡張性に限界がある Runtime Fabric アプライアンスのブラックボックスアプローチへの投資を終了します。 Runtime Fabric は、AWS、Google、Microsoft、そして IBM の RedHat Openshift ソリューションとの互換性があります。これらのソリューションでは、一貫したセキュリティパッチが迅速に提供されます。これらのインテグレーションにより、Kubernetes エコシステムへのこれまでの投資を容易に活用できます。 パブリッククラウドとのアフィニティと組織内の Kubernetes の専門知識に応じて、以下の自己管理 Red Hat OpenShift 製品を利用して、オンプレミスと公開クラウドのベアメタルソリューションを実装できます。 - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) これらのいずれかのソリューションを利用してクラスター上で K8s をセットアップしたら、Runtime Fabric のインストールセクションに進んで、AKS や EKS へのインストールと同じように Runtime Fabric を設定してください。 ## [](#アプライアンスユーザー向けの変更)アプライアンスユーザー向けの変更 既存のアプライアンスユーティリティユーザーは、現在 Runtime Fabric アプライアンスデプロイメントに割り当てられているライセンス済みのコア容量を、公開クラウド上の Runtime Fabric、OpenShift、Mule Runtime Standalone など、お客様がホストする任意のデプロイメントに移行できます。Flexible Hybrid Deployment 権を持つお客様は、vCore を使用するようにコアを変換して、この容量を CloudHub 2.0 上で利用することもできます。 ## [](#選択可能な移行オプション)選択可能な移行オプション - サービスとしてのインテグレーションプラットフォームを探しているのであれば、 [Cloudhub 2.0](https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-based-integration)​ をお勧めします。この MuleSoft のフラッグシップ製品は、運用オーバーヘッドを最小限に抑えています。 - 公開クラウドの知識と Kubernetes クラスターの管理についてある程度の専門知識がある場合は、​[公開クラウドの Kubernetes クラスター上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ に移行してください。Runtime Fabric は以下のクラウドでサポートされます。 - [AWS Elastic Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-aws-elastic-kubernetes-service/) - [AWS EKS-Anywhere 上の Runtime Fabric](https://aws.amazon.com/eks/eks-anywhere/) - [Google Kubernetes Engine 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-azure-kubernetes-service/) - [Microsoft Azure Kubernetes Service 上の Runtime Fabric](https://developer.mulesoft.com/tutorials-and-howtos/runtime-fabric/runtime-fabric-google-kubernetes-engine/) - 公開 Kubernetes ディストリビューションを使用して自社のベアメタルソリューションを標準化する場合は、 [IBM OpenShift 製品でサポートされる Runtime Fabric](https://www.youtube.com/watch?v=MYOeX5qjYew)​ の説明に従ってください。次の 7 つの製品には、事前作成された認定済みアセット、コネクタ、オペレーターが含まれているため、オンプレミスと公開クラウドのベアメタルソリューションの両方を実装できます。 - 管理クラウドサービス - [AWS の Red Hat OpenShift サービス (ROSA)](https://aws.amazon.com/rosa/) - [Azure Red Hat Openshift (ARO)](https://azure.microsoft.com/en-us/products/openshift/) - [GCP の Red Hat OpenShift Dedicated](https://cloud.google.com/blog/products/gcp/red-hats-openshift-dedicated-now-generally-available-on-google-cloud) - [IBM Cloud の Red Hat OpenShift](https://www.ibm.com/cloud/openshift) - 自己管理型サービス - [Red Hat OpenShift Kubernetes エンジン (エントリレベル)](https://www.redhat.com/en/technologies/cloud-computing/openshift/kubernetes-engine) - [Red Hat OpenShift Container Platform (OCP)](https://www.redhat.com/en/technologies/cloud-computing/openshift/container-platform) - [Red Hat OpenShift Platform Plus](https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-plus) - Kubernetes に投資しておらず、自社でホストしている環境を使い続ける場合は、Mule Runtime Standalone を利用できます。このデプロイメントモデルは、ランタイムの弾力性と過剰な管理オーバーヘッドを抑えています。 ## [](#ユーザーが利用できるアクションアプライアンス)ユーザーが利用できるアクションアプライアンス EOL 期日までに上記のいずれかのオプションを選択して移行を済ませてください。 標準サポート、拡張サポート、EOL サポートの詳細は、 [「バージョン設定ポリシーとサポートポリシー」](https://www.mulesoft.com/legal/versioning-back-support-policy#support-matrix)​を参照してください。 # Runtime Fabric のセットアップ 次のトピックは、Anypoint Runtime Fabric のインストール、設定、アンインストール、アップグレードに役立ちます。 - [Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備](https://docs.mulesoft.com/jp/runtime-fabric/2.6/index-vm-bare-metal) VM/ベアメタルクラスターの基盤インフラストラクチャが、Runtime Fabric を効果的にインストールするために必要なハードウェアおよびネットワークの要件を満たしていることを確認します。 - [ネットワークの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed-network-configuration) Runtime Fabric をインストールする前にポートとホスト名を正しく設定します。 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-index) `rtfctl`​ や Helm を使用して Runtime Fabric をインストールするか、Kubernetes (K8s) オペレーターとしてインストールするか、Runtime Fabric の複数のインスタンスをインストールします。 - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configuring-runtime-fabric) ネットワーク接続、イングレス、Red Hat OpenShift ルート、永続性ゲートウェイ、プロキシを設定し、ビジネスグループと環境を関連付けます。さらに、​`rtfctl`​ を使用して Runtime Fabric を設定できます。 - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/uninstall-self) `rtfctl`​ または Helm を使用するか、Red Hat OpenShift 上で Runtime Fabric をアンインストールします。 - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-index) `rtfctl`​ または Helm を使用するか、Kubernetes (K8s) オペレーターとして Runtime Fabric をアップグレードします。 ## [](#関連情報)関連情報 - [Runtime Fabric の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-index) - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-runtime-fabric) # Runtime Fabric のセットアップ 次のトピックは、Anypoint Runtime Fabric のインストール、設定、アンインストール、アップグレードに役立ちます。 - [Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備](https://docs.mulesoft.com/jp/runtime-fabric/2.7/index-vm-bare-metal) VM/ベアメタルクラスターの基盤インフラストラクチャが、Runtime Fabric を効果的にインストールするために必要なハードウェアおよびネットワークの要件を満たしていることを確認します。 - [ネットワークの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed-network-configuration) Runtime Fabric をインストールする前にポートとホスト名を正しく設定します。 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-index) `rtfctl`​ や Helm を使用して Runtime Fabric をインストールするか、Kubernetes (K8s) オペレーターとしてインストールするか、Runtime Fabric の複数のインスタンスをインストールします。 - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configuring-runtime-fabric) ネットワーク接続、イングレス、Red Hat OpenShift ルート、永続性ゲートウェイ、プロキシを設定し、ビジネスグループと環境を関連付けます。さらに、​`rtfctl`​ を使用して Runtime Fabric を設定できます。 - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/uninstall-self) `rtfctl`​ または Helm を使用するか、Red Hat OpenShift 上で Runtime Fabric をアンインストールします。 - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-index) `rtfctl`​ または Helm を使用するか、Kubernetes (K8s) オペレーターとして Runtime Fabric をアップグレードします。 ## [](#関連情報)関連情報 - [Runtime Fabric の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-index) - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-runtime-fabric) # Runtime Fabric のセットアップ 次のトピックは、Anypoint Runtime Fabric のインストール、設定、アンインストール、アップグレードに役立ちます。 - [Runtime Fabric のインストールに向けた VM/ベアメタルクラスターの準備](https://docs.mulesoft.com/jp/runtime-fabric/2.8/index-vm-bare-metal) VM/ベアメタルクラスターの基盤インフラストラクチャが、Runtime Fabric を効果的にインストールするために必要なハードウェアおよびネットワークの要件を満たしていることを確認します。 - [ネットワークの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed-network-configuration) Runtime Fabric をインストールする前にポートとホスト名を正しく設定します。 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-index) `rtfctl`​ や Helm を使用して Runtime Fabric をインストールするか、Kubernetes (K8s) オペレーターとしてインストールするか、Runtime Fabric の複数のインスタンスをインストールします。 - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configuring-runtime-fabric) ネットワーク接続、イングレス、Red Hat OpenShift ルート、永続性ゲートウェイ、プロキシを設定し、ビジネスグループと環境を関連付けます。さらに、​`rtfctl`​ を使用して Runtime Fabric を設定できます。 - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/uninstall-self) `rtfctl`​ または Helm を使用するか、Red Hat OpenShift 上で Runtime Fabric をアンインストールします。 - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-index) `rtfctl`​ または Helm を使用するか、Kubernetes (K8s) オペレーターとして Runtime Fabric をアップグレードします。 ## [](#関連情報)関連情報 - [Runtime Fabric の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-index) - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-runtime-fabric) # Runtime Fabric のデプロイメント状況メッセージ Runtime Manager は、Mule アプリケーションを初めてデプロイしたときや、Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたときに、デプロイメント状況メッセージを表示します。 - [アプリケーションのデプロイメント状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#application_deploy_states) これらの状況は、Deleted (削除)、Applying (適用中)、Applied (適用済み)、Failed (失敗)、Unknown (不明) メッセージなど、一般的なアプリケーションデプロイメントに関連しています。 - [レプリカの状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#replica_status_states) これらの状況は、新規設定または変更した設定をデプロイ済みの Mule アプリケーションに適用する場合に表示されます。 - [警告メッセージ状況の状態](#warning-status)​ これらの状況は、デプロイメントの進行中に警告メッセージを受信した場合に表示されます。 - [アプリケーション名前空間状況の状態](#app-namespaces-status-states)​ これらの状況は、デプロイメント中にアプリケーションの名前空間に問題がある場合に表示されます。 ## [](#warning-status)警告メッセージの状況状態 Mule アプリケーションをデプロイしたり、または Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたりすると、Runtime Manager は少し待ってから、報告されたレプリカの状況を能動的にチェックし始めます。状況が STARTED または STOPPED 以外の場合は、警告メッセージが表示されます。 警告メッセージは、Mule アプリケーションやクラスターに何か問題があることを意味しているとは限りません。警告メッセージには一時的な障害と永続的な障害を通知するものがあるため、メッセージの意味を理解することが重要です。 警告メッセージは​`「1 or more replicas in unexpected state: (1 つ以上のレプリカが想定外の状態にあります)」`​で始まり、その後に具体的な説明が続きます。例: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing`
警告メッセージが表示されたままで、問題が自動的に解決しない場合は、IT 部門や開発者チームと協力して、デプロイメントとポッドの状態を確認してトラブルシューティングを実施してください。
## [](#永続的な警告メッセージと一時的な警告メッセージ)永続的な警告メッセージと一時的な警告メッセージ 通常、永続な警告メッセージでは問題を修正するためのアクションが必要です。一方、一時的な警告メッセージはしばらくすると消えます。警告メッセージが適切な時間で消えない場合は、Kubernetes 管理者に連絡してください。 たとえば、ノードが動作を停止した場合、いくつかのポッドが一時的に保留される可能性があります。Kubernetes 管理者がそのノードを手動で再起動する必要があったり、再起動に時間がかかったりすることもあります。 Mule アプリケーションのデプロイ時にデータベースや JMS サーバーなどの外部連動関係が停止していると Mule アプリケーションが起動できないため、CrashLoopBackOff 警告が返されることがあります。この警告メッセージは、必要なサービスが起動すれば自動的に消えます。ただし、デプロイメントアーティファクトに何か問題がある場合には、この警告メッセージは表示されたままになります。 ## [](#警告メッセージの説明)警告メッセージの説明 次の表で、さまざまな種類の警告メッセージの一部を説明しています。警告メッセージの完全なリストは、Kubernetes のドキュメントを参照してください。
警告の状況 種類 説明 例

PodInitializing

通常は一時的

Mule アプリケーションのポッドに含まれる一部のコンテナの準備ができていないため、ポッドの初期化が遅れています。通常は、ポッドが初期化されるまで待てば解決します。デプロイメントに本質的な問題がある場合は、別の警告に変わります。

Link

CrashLoopBackOff

通常は永続的

Mule アプリケーションのイメージに問題があり、アプリケーションがクラッシュします。

Link

スケジュール不可

通常は一時的

要求されたレプリカを実行できるノードがありません。理由は次のとおりです。

* メンテナンスのためにノードが停止している。
* ノードでデプロイメントに割り当てられるリソースが不足している。
* Runtime Manager の ​[Deployments Target (デプロイメント対象)]​ タブで ​[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイを適用)]​ オプションが有効になっているが、必要なレプリカ数に対して利用可能なノードの数が不足している。

Link
ポッドの状況の詳細については、 [Kubernetes 公式ドキュメント](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime)​を参照してください。Kubernetes 管理者に連絡して、状態が深刻であるかどうかを確認し、必要であればトラブルシューティングの方法について助言を求めてください。 ## [](#警告メッセージの例)警告メッセージの例 ### [](#link-example-1)PodInitializing の例 次の例では、ポッドの準備はできていますが、初期化待ちであるため、警告メッセージが表示されています。 ![Runtime Manager UI の PodInitializing の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-deployment-example-1.png) ### [](#link-example-2)CrashLoopBackOff の例 次の例の警告メッセージは、破損したアーティファクトがアップロードされ、デプロイ中に Mule アプリケーションがクラッシュしたため、Mule アプリケーションのイメージに問題があることを示しています。 ![Runtime Manager UI での CrashLoopBackOff の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### [](#link-example-3)スケジュール不可の例 次の例では、3 つのノードが利用できないためにスケジュール不可であることを示す警告メッセージが表示されています。 ![Runtime Manager の UI でスケジュール不可の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## [](#アプリケーション名前空間状況の状態)アプリケーション名前空間状況の状態 次の表は、アプリケーションと認証済みの名前空間に問題がある場合に表示される状況の一覧です。これらの状況の先頭には ​`[Runtime Fabric]`​ が付けられます。
状況と説明 種類

現在の環境 <env_id> には既存の名前空間 <app_namespace> があります。このデプロイを続行するには、必要な表示ラベルを使用してカスタム名前空間を作成してください。カスタム名前空間の作成の詳細については、ドキュメントを参照してください。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> および rtf.mulesoft.com/agentNamespace=<agent_namespace> アノテーションを持つ複数の名前空間 <namespaces name> が見つかりました。単一の名前空間は、指定された環境 ID と RTF 名前空間のペアでアノテーションできます。

Permanent (永続的)

環境 '%s' に対応するアプリケーション名前空間が見つかりません。正しいアプリケーション名前空間で ConfigMap を更新してください。認証済みの名前空間の 設定については、ドキュメントを参照してください。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、rtf.mulesoft.com/agentNamespace=<agent_namespace> で表示ラベルを付ける必要があります。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、適切な rtf.mulesoft.com/envId で表示ラベルを付ける必要があります (空白でした)。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> アノテーションを持つ複数の名前空間が見つかりました。単一の名前空間には、任意の環境 ID でアノテーションできます。

Permanent (永続的)
## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションのバージョン管理の確認](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager 状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#status_states) # Runtime Fabric のデプロイメント状況メッセージ Runtime Manager は、Mule アプリケーションを初めてデプロイしたときや、Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたときに、デプロイメント状況メッセージを表示します。 - [アプリケーションのデプロイメント状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#application_deploy_states) これらの状況は、Deleted (削除)、Applying (適用中)、Applied (適用済み)、Failed (失敗)、Unknown (不明) メッセージなど、一般的なアプリケーションデプロイメントに関連しています。 - [レプリカの状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#replica_status_states) これらの状況は、新規設定または変更した設定をデプロイ済みの Mule アプリケーションに適用する場合に表示されます。 - [警告メッセージの状況状態](#warning-status)​ これらの状況は、デプロイメントの進行中に警告メッセージを受信した場合に表示されます。 - [アプリケーション名前空間の状況状態](#app-namespaces-status-states)​ これらの状況は、デプロイメント中にアプリケーションの名前空間に問題がある場合に表示されます。 ## [](#warning-status)警告メッセージの状況状態 Mule アプリケーションをデプロイしたり、または Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたりすると、Runtime Manager は少し待ってから、報告されたレプリカの状況を能動的にチェックし始めます。状況が STARTED または STOPPED 以外の場合は、警告メッセージが表示されます。 警告メッセージは、Mule アプリケーションやクラスターに何か問題があることを意味しているとは限りません。警告メッセージには一時的な障害と永続的な障害を通知するものがあるため、メッセージの意味を理解することが重要です。 警告メッセージは​`「1 or more replicas in unexpected state: (1 つ以上のレプリカが想定外の状態にあります)」`​で始まり、その後に具体的な説明が続きます。例: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing`
警告メッセージが表示されたままで、問題が自動的に解決しない場合は、IT 部門や開発者チームと協力して、デプロイメントとポッドの状態を確認してトラブルシューティングを実施してください。
## [](#永続的な警告メッセージと一時的な警告メッセージ)永続的な警告メッセージと一時的な警告メッセージ 通常、永続な警告メッセージでは問題を修正するためのアクションが必要です。一方、一時的な警告メッセージはしばらくすると消えます。警告メッセージが適切な時間で消えない場合は、Kubernetes 管理者に連絡してください。 たとえば、ノードが動作を停止した場合、いくつかのポッドが一時的に保留される可能性があります。Kubernetes 管理者がそのノードを手動で再起動する必要があったり、再起動に時間がかかったりすることもあります。 Mule アプリケーションのデプロイ時にデータベースや JMS サーバーなどの外部連動関係が停止していると Mule アプリケーションが起動できないため、CrashLoopBackOff 警告が返されることがあります。この警告メッセージは、必要なサービスが起動すれば自動的に消えます。ただし、デプロイメントアーティファクトに何か問題がある場合には、この警告メッセージは表示されたままになります。 ## [](#警告メッセージの説明)警告メッセージの説明 次の表で、さまざまな種類の警告メッセージの一部を説明しています。警告メッセージの完全なリストは、Kubernetes のドキュメントを参照してください。
警告の状況 型 説明 例

PodInitializing

通常は一時的

Mule アプリケーションのポッドに含まれる一部のコンテナの準備ができていないため、ポッドの初期化が遅れています。通常は、ポッドが初期化されるまで待てば解決します。デプロイメントに本質的な問題がある場合は、別の警告に変わります。

リンク

CrashLoopBackOff

通常は永続的

Mule アプリケーションのイメージに問題があり、アプリケーションがクラッシュします。

リンク

スケジュール不可

通常は一時的

要求されたレプリカを実行できるノードがありません。理由は次のとおりです。

* メンテナンスのためにノードが停止している。
* ノードでデプロイメントに割り当てられるリソースが不足している。
* Runtime Manager の ​[Deployments Target (デプロイメント対象)]​ タブで ​[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイを適用)]​ オプションが有効になっているが、必要なレプリカ数に対して利用可能なノードの数が不足している。

リンク
ポッドの状況の詳細については、 [Kubernetes 公式ドキュメント](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime)​を参照してください。Kubernetes 管理者に連絡して、状態が深刻であるかどうかを確認し、必要であればトラブルシューティングの方法について助言を求めてください。 ## [](#警告メッセージの例)警告メッセージの例 ### [](#link-example-1)PodInitializing の例 次の例では、ポッドの準備はできていますが、初期化待ちであるため、警告メッセージが表示されています。 ![Runtime Manager UI の PodInitializing の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-deployment-example-1.png) ### [](#link-example-2)CrashLoopBackOff の例 次の例の警告メッセージは、破損したアーティファクトがアップロードされ、デプロイ中に Mule アプリケーションがクラッシュしたため、Mule アプリケーションのイメージに問題があることを示しています。 ![Runtime Manager UI での CrashLoopBackOff の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### [](#link-example-3)スケジュール不可の例 次の例では、3 つのノードが利用できないためにスケジュール不可であることを示す警告メッセージが表示されています。 ![Runtime Manager の UI でスケジュール不可の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## [](#アプリケーション名前空間状況の状態)アプリケーション名前空間状況の状態 次の表は、アプリケーションと認証済みの名前空間に問題がある場合に表示される状況の一覧です。これらの状況の先頭には ​`[Runtime Fabric]`​ が付けられます。
状況と説明 型

現在の環境 <env_id> には既存の名前空間 <app_namespace> があります。このデプロイを続行するには、必要な表示ラベルを使用してカスタム名前空間を作成してください。カスタム名前空間の作成の詳細については、ドキュメントを参照してください。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> および rtf.mulesoft.com/agentNamespace=<agent_namespace> アノテーションを持つ複数の名前空間 <namespaces name> が見つかりました。単一の名前空間は、指定された環境 ID と RTF 名前空間のペアでアノテーションできます。

Permanent (永続的)

環境 '%s' に対応するアプリケーション名前空間が見つかりません。正しいアプリケーション名前空間で ConfigMap を更新してください。認証済みの名前空間の 設定については、ドキュメントを参照してください。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、rtf.mulesoft.com/agentNamespace=<agent_namespace> で表示ラベルを付ける必要があります。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、適切な rtf.mulesoft.com/envId で表示ラベルを付ける必要があります (空白でした)。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> アノテーションを持つ複数の名前空間が見つかりました。単一の名前空間には、任意の環境 ID でアノテーションできます。

Permanent (永続的)
## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションのバージョン管理の確認](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager 状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#status_states) # Runtime Fabric のデプロイメント状況メッセージ Runtime Manager は、Mule アプリケーションを初めてデプロイしたときや、Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたときに、デプロイメント状況メッセージを表示します。 - [アプリケーションのデプロイメント状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#application_deploy_states) これらの状況は、Deleted (削除)、Applying (適用中)、Applied (適用済み)、Failed (失敗)、Unknown (不明) メッセージなど、一般的なアプリケーションデプロイメントに関連しています。 - [レプリカの状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#replica_status_states) これらの状況は、新規設定または変更した設定をデプロイ済みの Mule アプリケーションに適用する場合に表示されます。 - [警告メッセージの状況状態](#warning-status)​ これらの状況は、デプロイメントの進行中に警告メッセージを受信した場合に表示されます。 - [アプリケーション名前空間の状況状態](#app-namespaces-status-states)​ これらの状況は、デプロイメント中にアプリケーションの名前空間に問題がある場合に表示されます。 ## [](#warning-status)警告メッセージの状況状態 Mule アプリケーションをデプロイしたり、または Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたりすると、Runtime Manager は少し待ってから、報告されたレプリカの状況を能動的にチェックし始めます。状況が STARTED または STOPPED 以外の場合は、警告メッセージが表示されます。 警告メッセージは、Mule アプリケーションやクラスターに何か問題があることを意味しているとは限りません。警告メッセージには一時的な障害と永続的な障害を通知するものがあるため、メッセージの意味を理解することが重要です。 警告メッセージは​`「1 or more replicas in unexpected state: (1 つ以上のレプリカが想定外の状態にあります)」`​で始まり、その後に具体的な説明が続きます。例: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing`
警告メッセージが表示されたままで、問題が自動的に解決しない場合は、IT 部門や開発者チームと協力して、デプロイメントとポッドの状態を確認してトラブルシューティングを実施してください。
## [](#永続的な警告メッセージと一時的な警告メッセージ)永続的な警告メッセージと一時的な警告メッセージ 通常、永続な警告メッセージでは問題を修正するためのアクションが必要です。一方、一時的な警告メッセージはしばらくすると消えます。警告メッセージが適切な時間で消えない場合は、Kubernetes 管理者に連絡してください。 たとえば、ノードが動作を停止した場合、いくつかのポッドが一時的に保留される可能性があります。Kubernetes 管理者がそのノードを手動で再起動する必要があったり、再起動に時間がかかったりすることもあります。 Mule アプリケーションのデプロイ時にデータベースや JMS サーバーなどの外部連動関係が停止していると Mule アプリケーションが起動できないため、CrashLoopBackOff 警告が返されることがあります。この警告メッセージは、必要なサービスが起動すれば自動的に消えます。ただし、デプロイメントアーティファクトに何か問題がある場合には、この警告メッセージは表示されたままになります。 ## [](#警告メッセージの説明)警告メッセージの説明 次の表で、さまざまな種類の警告メッセージの一部を説明しています。警告メッセージの完全なリストは、Kubernetes のドキュメントを参照してください。
警告の状況 型 説明 例

PodInitializing

通常は一時的

Mule アプリケーションのポッドに含まれる一部のコンテナの準備ができていないため、ポッドの初期化が遅れています。通常は、ポッドが初期化されるまで待てば解決します。デプロイメントに本質的な問題がある場合は、別の警告に変わります。

リンク

CrashLoopBackOff

通常は永続的

Mule アプリケーションのイメージに問題があり、アプリケーションがクラッシュします。

リンク

スケジュール不可

通常は一時的

要求されたレプリカを実行できるノードがありません。理由は次のとおりです。

* メンテナンスのためにノードが停止している。
* ノードでデプロイメントに割り当てられるリソースが不足している。
* Runtime Manager の ​[Deployments Target (デプロイメント対象)]​ タブで ​[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイを適用)]​ オプションが有効になっているが、必要なレプリカ数に対して利用可能なノードの数が不足している。

リンク
ポッドの状況の詳細については、 [Kubernetes 公式ドキュメント](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime)​を参照してください。Kubernetes 管理者に連絡して、状態が深刻であるかどうかを確認し、必要であればトラブルシューティングの方法について助言を求めてください。 ## [](#警告メッセージの例)警告メッセージの例 ### [](#link-example-1)PodInitializing の例 次の例では、ポッドの準備はできていますが、初期化待ちであるため、警告メッセージが表示されています。 ![Runtime Manager UI の PodInitializing の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-deployment-example-1.png) ### [](#link-example-2)CrashLoopBackOff の例 次の例の警告メッセージは、破損したアーティファクトがアップロードされ、デプロイ中に Mule アプリケーションがクラッシュしたため、Mule アプリケーションのイメージに問題があることを示しています。 ![Runtime Manager UI での CrashLoopBackOff の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### [](#link-example-3)スケジュール不可の例 次の例では、3 つのノードが利用できないためにスケジュール不可であることを示す警告メッセージが表示されています。 ![Runtime Manager の UI でスケジュール不可の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## [](#アプリケーション名前空間状況の状態)アプリケーション名前空間状況の状態 次の表は、アプリケーションと認証済みの名前空間に問題がある場合に表示される状況の一覧です。これらの状況の先頭には ​`[Runtime Fabric]`​ が付けられます。
状況と説明 型

現在の環境 <env_id> には既存の名前空間 <app_namespace> があります。このデプロイを続行するには、必要な表示ラベルを使用してカスタム名前空間を作成してください。カスタム名前空間の作成の詳細については、ドキュメントを参照してください。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> および rtf.mulesoft.com/agentNamespace=<agent_namespace> アノテーションを持つ複数の名前空間 <namespaces name> が見つかりました。単一の名前空間は、指定された環境 ID と RTF 名前空間のペアでアノテーションできます。

Permanent (永続的)

環境 '%s' に対応するアプリケーション名前空間が見つかりません。正しいアプリケーション名前空間で ConfigMap を更新してください。認証済みの名前空間の 設定については、ドキュメントを参照してください。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、rtf.mulesoft.com/agentNamespace=<agent_namespace> で表示ラベルを付ける必要があります。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、適切な rtf.mulesoft.com/envId で表示ラベルを付ける必要があります (空白でした)。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> アノテーションを持つ複数の名前空間が見つかりました。単一の名前空間には、任意の環境 ID でアノテーションできます。

Permanent (永続的)
## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションのバージョン管理の確認](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager 状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#status_states) # Runtime Fabric のデプロイメント状況メッセージ Runtime Manager は、Mule アプリケーションを初めてデプロイしたときや、Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたときに、デプロイメント状況メッセージを表示します。 - [アプリケーションのデプロイメント状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#application_deploy_states) これらの状況は、Deleted (削除)、Applying (適用中)、Applied (適用済み)、Failed (失敗)、Unknown (不明) メッセージなど、一般的なアプリケーションデプロイメントに関連しています。 - [レプリカの状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#replica_status_states) これらの状況は、新規設定または変更した設定をデプロイ済みの Mule アプリケーションに適用する場合に表示されます。 - [警告メッセージの状況状態](#warning-status)​ これらの状況は、デプロイメントの進行中に警告メッセージを受信した場合に表示されます。 - [アプリケーション名前空間の状況状態](#app-namespaces-status-states)​ これらの状況は、デプロイメント中にアプリケーションの名前空間に問題がある場合に表示されます。 ## [](#warning-status)警告メッセージの状況状態 Mule アプリケーションをデプロイしたり、または Runtime Fabric にデプロイされている既存の Mule アプリケーションに変更を加えたりすると、Runtime Manager は少し待ってから、報告されたレプリカの状況を能動的にチェックし始めます。状況が STARTED または STOPPED 以外の場合は、警告メッセージが表示されます。 警告メッセージは、Mule アプリケーションやクラスターに何か問題があることを意味しているとは限りません。警告メッセージには一時的な障害と永続的な障害を通知するものがあるため、メッセージの意味を理解することが重要です。 警告メッセージは​`「1 or more replicas in unexpected state: (1 つ以上のレプリカが想定外の状態にあります)」`​で始まり、その後に具体的な説明が続きます。例: `1 or more replicas in unexpected state: [Kubernetes] Container "any point-monitoring" - PodInitializing`
警告メッセージが表示されたままで、問題が自動的に解決しない場合は、IT 部門や開発者チームと協力して、デプロイメントとポッドの状態を確認してトラブルシューティングを実施してください。
## [](#永続的な警告メッセージと一時的な警告メッセージ)永続的な警告メッセージと一時的な警告メッセージ 通常、永続な警告メッセージでは問題を修正するためのアクションが必要です。一方、一時的な警告メッセージはしばらくすると消えます。警告メッセージが適切な時間で消えない場合は、Kubernetes 管理者に連絡してください。 たとえば、ノードが動作を停止した場合、いくつかのポッドが一時的に保留される可能性があります。Kubernetes 管理者がそのノードを手動で再起動する必要があったり、再起動に時間がかかったりすることもあります。 Mule アプリケーションのデプロイ時にデータベースや JMS サーバーなどの外部連動関係が停止していると Mule アプリケーションが起動できないため、CrashLoopBackOff 警告が返されることがあります。この警告メッセージは、必要なサービスが起動すれば自動的に消えます。ただし、デプロイメントアーティファクトに何か問題がある場合には、この警告メッセージは表示されたままになります。 ## [](#警告メッセージの説明)警告メッセージの説明 次の表で、さまざまな種類の警告メッセージの一部を説明しています。警告メッセージの完全なリストは、Kubernetes のドキュメントを参照してください。
警告の状況 型 説明 例

PodInitializing

通常は一時的

Mule アプリケーションのポッドに含まれる一部のコンテナの準備ができていないため、ポッドの初期化が遅れています。通常は、ポッドが初期化されるまで待てば解決します。デプロイメントに本質的な問題がある場合は、別の警告に変わります。

リンク

CrashLoopBackOff

通常は永続的

Mule アプリケーションのイメージに問題があり、アプリケーションがクラッシュします。

リンク

スケジュール不可

通常は一時的

要求されたレプリカを実行できるノードがありません。理由は次のとおりです。

* メンテナンスのためにノードが停止している。
* ノードでデプロイメントに割り当てられるリソースが不足している。
* Runtime Manager の ​[Deployments Target (デプロイメント対象)]​ タブで ​[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイを適用)]​ オプションが有効になっているが、必要なレプリカ数に対して利用可能なノードの数が不足している。

リンク
ポッドの状況の詳細については、 [Kubernetes 公式ドキュメント](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-lifetime)​を参照してください。Kubernetes 管理者に連絡して、状態が深刻であるかどうかを確認し、必要であればトラブルシューティングの方法について助言を求めてください。 ## [](#警告メッセージの例)警告メッセージの例 ### [](#link-example-1)PodInitializing の例 次の例では、ポッドの準備はできていますが、初期化待ちであるため、警告メッセージが表示されています。 ![Runtime Manager UI の PodInitializing の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-deployment-example-1.png) ### [](#link-example-2)CrashLoopBackOff の例 次の例の警告メッセージは、破損したアーティファクトがアップロードされ、デプロイ中に Mule アプリケーションがクラッシュしたため、Mule アプリケーションのイメージに問題があることを示しています。 ![Runtime Manager UI での CrashLoopBackOff の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text ➜ ~ kubectl get deployments,pods --namespace 788a26d2-a837-4336-aa7b-1f367cf70d7d NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 20m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-78b7ffd454-h5x5n 1/2 CrashLoopBackOff 8 (2m57s ago) 20m ``` ### [](#link-example-3)スケジュール不可の例 次の例では、3 つのノードが利用できないためにスケジュール不可であることを示す警告メッセージが表示されています。 ![Runtime Manager の UI でスケジュール不可の警告状況](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-deployment-example-2.png) Kubernetes 管理者は、コマンドラインインターフェースで次のコマンドを実行することで、エラーや警告の状況も取得できます。 `kubectl get deployments,pods --namespace ` 例: ```text NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/omg-s1-now 0/1 1 0 170m NAME READY STATUS RESTARTS AGE pod/omg-s1-now-58dd54d9f-xt569 0/2 Pending 0 4s pod/omg-s1-now-6c5c5d987c-fbmbl 0/2 Pending 0 50m ``` ## [](#アプリケーション名前空間状況の状態)アプリケーション名前空間状況の状態 次の表は、アプリケーションと認証済みの名前空間に問題がある場合に表示される状況の一覧です。これらの状況の先頭には ​`[Runtime Fabric]`​ が付けられます。
状況と説明 型

現在の環境 <env_id> には既存の名前空間 <app_namespace> があります。このデプロイを続行するには、必要な表示ラベルを使用してカスタム名前空間を作成してください。カスタム名前空間の作成の詳細については、ドキュメントを参照してください。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> および rtf.mulesoft.com/agentNamespace=<agent_namespace> アノテーションを持つ複数の名前空間 <namespaces name> が見つかりました。単一の名前空間は、指定された環境 ID と RTF 名前空間のペアでアノテーションできます。

Permanent (永続的)

環境 '%s' に対応するアプリケーション名前空間が見つかりません。正しいアプリケーション名前空間で ConfigMap を更新してください。認証済みの名前空間の 設定については、ドキュメントを参照してください。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、rtf.mulesoft.com/agentNamespace=<agent_namespace> で表示ラベルを付ける必要があります。

Permanent (永続的)

アプリケーション名前空間 <app_namespace> に正しい表示ラベルが付けられていません。現在のエージェントデプロイメントの名前空間は、適切な rtf.mulesoft.com/envId で表示ラベルを付ける必要があります (空白でした)。

Permanent (永続的)

名前空間の選択に失敗しました。同じ rtf.mulesoft.com/envId=<env_id> アノテーションを持つ複数の名前空間が見つかりました。単一の名前空間には、任意の環境 ID でアノテーションできます。

Permanent (永続的)
## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションのバージョン管理の確認](https://docs.mulesoft.com/runtime-fabric/latest/app-versioning) - [Runtime Manager 状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#status_states) # Runtime Fabric のバックアップと復元 Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。 Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。 VM/ベアメタルの Runtime Fabric の場合、バックアップと復元のプロセスには logforwarder や smtp などのアプライアンス関連のカスタムリソースのバックアップと復元が含まれます。バックアップと復元のプロセスには、アプリケーションによって生成された InfluxDB に保存されたメトリクスデータのバックアップは含まれません。
バックアップと復元のプロセスを使用して、VM/ベアメタル上の Runtime Fabric から自己管理型 Kubernetes 上の Runtime Fabric に移行することはできません。
## [](#バックアップと復元のプロセスを使用する状況)バックアップと復元のプロセスを使用する状況 バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。 - Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。 - VM/ベアメタルの Runtime Fabric をアップグレードする。場合によっては、クラスターをバックアップし、新しい Runtime Fabric バージョンを使用して同じクラスターに新しいクラスターをインストールしてから、そのクラスターにバックアップを復元する必要があることがあります。 - スタンバイクラスターへのフェールオーバーを実行する。

バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。
## [](#バックアップされるデータ)バックアップされるデータ Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。 バックアップされる内容は次のとおりです。 - コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細 - クラスターレベルのセキュアプロパティ - デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ - 現在の ​`rtfctl`​ バージョン - 現在の Runtime Fabric エージェントバージョン - 次のようなアプリケーション詳細: - ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定 - Runtime Manager で設定されているアプリケーションプロパティ - 次のような他の MuleSoft 設定のデータ - オブジェクトストア - Edge - Anypoint Monitoring と外部ログフォワーダー ## [](#バックアップされないデータ)バックアップされないデータ - アプリケーションの状態に関するデータ - Ops Center のデータ - コントロールプレーンのデータ ### [](#バックアップ実行後の変更内容が復元されない)バックアップ実行後の変更内容が復元されない バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には ​**\[applying (適用中)\]**​ として表示されます。 バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。 - アプリケーションの作成 - アプリケーションの削除 - アプリケーション設定の更新 - エージェントのアップグレード バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。 ## [](#バックアップを作成する)バックアップを作成する バックアップを作成するに、次の準備をしてください。 - Runtime Fabric が正しくインストールおよび設定されていることを確認します。 - `rtfctl`​ コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで ​`rtfctl version`​ を実行します。

  • VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ./rtfctl backup このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 - VM/ベアメタルの Runtime Fabric の場合、​`rtfctl`​ バイナリは ​`/opt/anypoint/runtimefabric/`​ ディレクトリにあります。クラスター内のコントローラーノードで特権ユーザーとしてバックアップコマンドを実行していることを確認します。後で復元するためにバックアップを使用するには、バックアップファイルを Runtime Fabric に含まれていない別のマシン上のセキュアなストレージにコピーします。 たとえば、次のコマンドでは ​`scp`​ を使用してバックアップを別のドライブにコピーします。 scp your\_username@remotehost:/opt/anypoint/runtimefabric/backup.tar.gz /backup-path/to-restore.tar.gz - 自己管理型 Kubernetes の Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、ユーザーの ​`$PATH`​ に ​`kubectl`​ が存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。 ## [](#復元を実行する)復元を実行する

クラスターを復元する前に、次の情報を確認してください。

  • Runtime Manager にリストされているのと同じ Runtime Fabric クラスター (コントロールプレーン内の同じクラスター) 上で復元を実行する必要があります。

  • バックアップ後に行われたデプロイ済みのアプリケーションおよび管理サービスに対する設定変更は復元されません。

  • アプリケーション監視メトリクスは復元されません。

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。

  • 自己管理型 Kubernetes 上の Runtime Fabric では、復元にコントロールプレーンは必要ありません。VM/ベアメタル上の Runtime Fabric では、最初にアプライアンスをインとする必要があるため、コントロールプレーンとの接続が必要です。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Vm/ベアメタル上で Runtime Fabric アプライアンスを復元するには、Runtime Fabric アクティベーションデータを​**指定せずに**​ Runtime Fabric インストールスクリプトを実行します。インストールスクリプトを実行したら、復元プロセスを完了します。 自己管理型 Kubernetes 上の Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 - VM/ベアメタルの Runtime Fabric の場合、圧縮されたバックアップファイルを、復元する環境のコントローラーノードのディレクトリにコピーします。たとえば、このファイルは次のコマンドを使用して安全に転送できます。 scp /backup-path/to-restore.tar.gz your\_username@remotehost:/opt/anypoint/runtimefabric/ 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 kubectl scale --replicas=0 -n rtf deployment.apps/agent 5. バックアップからクラスターを復元します。 ./rtfctl restore \+ このプロセスは、完了するまで数分かかる場合があります。 自己管理型 Kubernetes の Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric からのノードの追加または削除](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-nodes) - [Anypoint Runtime Fabric インストールの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs) # Runtime Fabric のバックアップと復元 Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。 Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。 ## [](#バックアップと復元のプロセスを使用する状況)バックアップと復元のプロセスを使用する状況 バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。 - Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。 - Runtime Fabric クラスターをオンプレミスからクラウドに移行したり、1 つのクラウドプロバイダーから別のクラウドプロバイダーに移行したりする。 - スタンバイクラスターへのフェールオーバーを実行する。

バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。
## [](#バックアップされるデータ)バックアップされるデータ Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。 通常の Kubernetes クラスターの場合、以下がバックアップされます。 - コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細 - クラスターレベルのセキュアプロパティ - デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ - 現在の ​`rtfctl`​ バージョン - 現在の Runtime Fabric エージェントバージョン - 次のようなアプリケーション詳細: - ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定 - Runtime Manager で設定されているアプリケーションプロパティ - 次のような他の MuleSoft 設定のデータ - オブジェクトストア - Edge - Anypoint Monitoring と外部ログフォワーダー OpenShift クラスターの場合、以下がバックアップされます。 - カスタムリソース - アプリケーションの名前空間と、それぞれの名前空間に関する次の情報: - シークレット - サービスアカウント - ConfigMap - サービス - CronJobs - DaemonSets - デプロイメント - イングレス - ロール - ロールバインディング - Runtime Fabric 名前空間からのイングレス ## [](#バックアップされないデータ)バックアップされないデータ - アプリケーションの状態に関するデータ - Ops Center のデータ - コントロールプレーンのデータ ### [](#バックアップ実行後の変更内容が復元されない)バックアップ実行後の変更内容が復元されない バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には ​**\[applying (適用中)\]**​ として表示されます。 バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。 - アプリケーションの作成 - アプリケーションの削除 - アプリケーション設定の更新 - エージェントのアップグレード バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。 ## [](#バックアップを作成する)バックアップを作成する バックアップを作成するに、次の準備をしてください。 - Runtime Fabric が正しくインストールおよび設定されていることを確認します。 - `rtfctl`​ コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで ​`rtfctl version`​ を実行します。 - `rtfctl`​ バイナリが現在のディレクトリに存在し、​`kubectl`​ がユーザーの ​`$PATH`​ に存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。

VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ```copy ./rtfctl backup ``` このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 ## [](#復元を実行する)復元を実行する

クラスターを復元する前に、次の情報を確認してください。

  • Runtime Manager にリストされているのと同じ Runtime Fabric クラスター (コントロールプレーン内の同じクラスター) 上で復元を実行する必要があります。

  • バックアップ後に行われたデプロイ済みのアプリケーションおよび管理サービスに対する設定変更は復元されません。

  • アプリケーション監視メトリクスは復元されません。

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. バックアップからクラスターを復元します。 ./rtfctl restore このプロセスは、完了するまで数分かかる場合があります。 Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#openshift-クラスターのバックアップを作成して復元する)OpenShift クラスターのバックアップを作成して復元する 次の例の Runtime Fabric には、OpenShift クラスター内のクラスター (​`cluster-1`​) にデプロイされた Mule アプリケーションと設定のセットがあります。バックアップを作成して復元を実行する手順は、次のとおりです。 1. Backup コマンドを実行します。 ```copy ./rtfctl backup -n ```
MuleSoft は、検出されたクラスターに基づいてバックアップを実行します。ただし、​--backup-type​ フラグを使用して、実行するバックアップの種別を手動で指定することもできます。フラグのオプションは ​auto​、​openshift​、​full​ です。デフォルトの ​auto​ フラグオプションを使用すると、MuleSoft は自動的にインフラストラクチャクラスタープロバイダーを検出してバックアップを実行します。
2. `cluster-1`​ をシャットダウンします。 3. 次のコマンドを実行して、すべての Mule アプリケーションのデプロイメントを削除します。 ```copy kubectl delete ns ``` Runtime Manager UI からアプリケーションを削除しないでください。 4. Runtime Fabric をアンインストールします。 5. OpenShift クラスターから Runtime Fabric Operator を削除します (省略可能)。 6. 管理プレーン API エンドポイントに ​`curl`​ コマンドを送信して、アクティベーション ID を再生成します。 Runtime Fabric のアクティベーションの準備ができていることが表示されます。新しい OpenShift クラスターに Runtime Fabric を再度インストールしてアクティベーションすることができます。 ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. 再生成されたアクティベーションデータ ID を使用して、​`cluster-2`​ に Runtime Fabric Operator をインストールします。 インストールは同じ Runtime Fabric 名前空間で行う必要があります。バックアップのすべての表示ラベルは、そのインストールを指し示しています。 8. restore コマンドを実行してリソースのセットを選択し、クラスターに復元します。 ```copy ./rtfctl restore -n ``` 9. Runtime Fabric デプロイメントの状況を確認します。 # Runtime Fabric のバックアップと復元 Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。 Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。 `rtfctl`​ バージョン 1.0.70 以降、rtf-agent バージョン 2.6.52 以降を使用すると、​`rtfctl`​ バックアップバンドルに Mule アプリケーションデプロイメントが含まれません。デプロイメントは復元時に Runtime Manager UI から同期されます。 ## [](#バックアップと復元のプロセスを使用する状況)バックアップと復元のプロセスを使用する状況 バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。 - Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。 - Runtime Fabric クラスターをオンプレミスからクラウドに移行したり、1 つのクラウドプロバイダーから別のクラウドプロバイダーに移行したりする。 - スタンバイクラスターへのフェールオーバーを実行する。

バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。
## [](#バックアップされるデータ)バックアップされるデータ Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。 通常の Kubernetes クラスターの場合、以下がバックアップされます。 - コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細 - クラスターレベルのセキュアプロパティ - デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ - 現在の ​`rtfctl`​ バージョン - 現在の Runtime Fabric エージェントバージョン - 次のようなアプリケーション詳細: - ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定 - Runtime Manager で設定されているアプリケーションプロパティ - 次のような他の MuleSoft 設定のデータ - オブジェクトストア - Edge - Anypoint Monitoring と外部ログフォワーダー OpenShift クラスターの場合、以下がバックアップされます。 - カスタムリソース - アプリケーションの名前空間と、それぞれの名前空間に関する次の情報: - シークレット - サービスアカウント - ConfigMap - サービス - CronJobs - DaemonSets - デプロイメント - イングレス - ロール - ロールバインディング - Runtime Fabric 名前空間からのイングレス ## [](#バックアップされないデータ)バックアップされないデータ - アプリケーションの状態に関するデータ - Ops Center のデータ - コントロールプレーンのデータ ### [](#バックアップ実行後の変更内容が復元されない)バックアップ実行後の変更内容が復元されない バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には ​**\[applying (適用中)\]**​ として表示されます。 バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。 - アプリケーションの作成 - アプリケーションの削除 - アプリケーション設定の更新 - エージェントのアップグレード バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。 ## [](#バックアップを作成する)バックアップを作成する バックアップを作成するに、次の準備をしてください。 - Runtime Fabric が正しくインストールおよび設定されていることを確認します。 - `rtfctl`​ コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで ​`rtfctl version`​ を実行します。 - `rtfctl`​ バイナリが現在のディレクトリに存在し、​`kubectl`​ がユーザーの ​`$PATH`​ に存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。

VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ```copy ./rtfctl backup ``` このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 ## [](#復元を実行する)復元を実行する

クラスターを復元する前に、次の情報を確認してください。

  • Runtime Manager にリストされているのと同じ Runtime Fabric クラスター (コントロールプレーン内の同じクラスター) 上で復元を実行する必要があります。

  • バックアップ後に行われたデプロイ済みのアプリケーションおよび管理サービスに対する設定変更は復元されません。

  • アプリケーション監視メトリクスは復元されません。

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. バックアップからクラスターを復元します。 ./rtfctl restore このプロセスは、完了するまで数分かかる場合があります。 Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#openshift-クラスターのバックアップを作成して復元する)OpenShift クラスターのバックアップを作成して復元する 次の例の Runtime Fabric には、OpenShift クラスター内のクラスター (​`cluster-1`​) にデプロイされた Mule アプリケーションと設定のセットがあります。バックアップを作成して復元を実行する手順は、次のとおりです。 1. Backup コマンドを実行します。 ```copy ./rtfctl backup -n ```
MuleSoft は、検出されたクラスターに基づいてバックアップを実行します。ただし、​--backup-type​ フラグを使用して、実行するバックアップの種別を手動で指定することもできます。フラグのオプションは ​auto​、​openshift​、​full​ です。デフォルトの ​auto​ フラグオプションを使用すると、MuleSoft は自動的にインフラストラクチャクラスタープロバイダーを検出してバックアップを実行します。
2. `cluster-1`​ をシャットダウンします。 3. 次のコマンドを実行して、すべての Mule アプリケーションのデプロイメントを削除します。 ```copy kubectl delete ns ``` Runtime Manager UI からアプリケーションを削除しないでください。 4. Runtime Fabric をアンインストールします。 5. OpenShift クラスターから Runtime Fabric Operator を削除します (省略可能)。 6. 管理プレーン API エンドポイントに ​`curl`​ コマンドを送信して、アクティベーション ID を再生成します。 Runtime Fabric のアクティベーションの準備ができていることが表示されます。新しい OpenShift クラスターに Runtime Fabric を再度インストールしてアクティベーションすることができます。 ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. 再生成されたアクティベーションデータ ID を使用して、​`cluster-2`​ に Runtime Fabric Operator をインストールします。 インストールは同じ Runtime Fabric 名前空間で行う必要があります。バックアップのすべての表示ラベルは、そのインストールを指し示しています。 8. restore コマンドを実行してリソースのセットを選択し、クラスターに復元します。 ```copy ./rtfctl restore -n ``` 9. Runtime Fabric デプロイメントの状況を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-runtime-fabric) # Runtime Fabric のバックアップと復元 Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。 Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。 `rtfctl`​ バージョン 1.0.70 以降、rtf-agent バージョン 2.6.52 以降を使用すると、​`rtfctl`​ バックアップバンドルに Mule アプリケーションデプロイメントが含まれません。デプロイメントは復元時に Runtime Manager UI から同期されます。 ## [](#バックアップと復元のプロセスを使用する状況)バックアップと復元のプロセスを使用する状況 バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。 - Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。 - Runtime Fabric クラスターをオンプレミスからクラウドに移行したり、1 つのクラウドプロバイダーから別のクラウドプロバイダーに移行したりする。 - スタンバイクラスターへのフェールオーバーを実行する。

バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。
## [](#バックアップされるデータ)バックアップされるデータ Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。 通常の Kubernetes クラスターの場合、以下がバックアップされます。 - コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細 - クラスターレベルのセキュアプロパティ - デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ - 現在の ​`rtfctl`​ バージョン - 現在の Runtime Fabric エージェントバージョン - 次のようなアプリケーション詳細: - ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定 - Runtime Manager で設定されているアプリケーションプロパティ - 次のような他の MuleSoft 設定のデータ - オブジェクトストア - Edge - Anypoint Monitoring と外部ログフォワーダー OpenShift クラスターの場合、以下がバックアップされます。 - カスタムリソース - アプリケーションの名前空間と、それぞれの名前空間に関する次の情報: - シークレット - サービスアカウント - ConfigMap - サービス - CronJobs - DaemonSets - デプロイメント - イングレス - ロール - ロールバインディング - Runtime Fabric 名前空間からのイングレス ## [](#バックアップされないデータ)バックアップされないデータ - アプリケーションの状態に関するデータ - Ops Center のデータ - コントロールプレーンのデータ ### [](#バックアップ実行後の変更内容が復元されない)バックアップ実行後の変更内容が復元されない バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には ​**\[applying (適用中)\]**​ として表示されます。 バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。 - アプリケーションの作成 - アプリケーションの削除 - アプリケーション設定の更新 - エージェントのアップグレード バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。 ## [](#バックアップを作成する)バックアップを作成する バックアップを作成するに、次の準備をしてください。 - Runtime Fabric が正しくインストールおよび設定されていることを確認します。 - `rtfctl`​ コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで ​`rtfctl version`​ を実行します。 - `rtfctl`​ バイナリが現在のディレクトリに存在し、​`kubectl`​ がユーザーの ​`$PATH`​ に存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。

VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ```copy ./rtfctl backup ``` このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 ## [](#復元を実行する)復元を実行する

クラスターを復元する前に、次の情報を確認してください。

  • Runtime Manager にリストされているのと同じ Runtime Fabric クラスター (コントロールプレーン内の同じクラスター) 上で復元を実行する必要があります。

  • バックアップ後に行われたデプロイ済みのアプリケーションおよび管理サービスに対する設定変更は復元されません。

  • アプリケーション監視メトリクスは復元されません。

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. バックアップからクラスターを復元します。 ./rtfctl restore このプロセスは、完了するまで数分かかる場合があります。 Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#openshift-クラスターのバックアップを作成して復元する)OpenShift クラスターのバックアップを作成して復元する 次の例の Runtime Fabric には、OpenShift クラスター内のクラスター (​`cluster-1`​) にデプロイされた Mule アプリケーションと設定のセットがあります。バックアップを作成して復元を実行する手順は、次のとおりです。 1. Backup コマンドを実行します。 ```copy ./rtfctl backup -n ```
MuleSoft は、検出されたクラスターに基づいてバックアップを実行します。ただし、​--backup-type​ フラグを使用して、実行するバックアップの種別を手動で指定することもできます。フラグのオプションは ​auto​、​openshift​、​full​ です。デフォルトの ​auto​ フラグオプションを使用すると、MuleSoft は自動的にインフラストラクチャクラスタープロバイダーを検出してバックアップを実行します。
2. `cluster-1`​ をシャットダウンします。 3. 次のコマンドを実行して、すべての Mule アプリケーションのデプロイメントを削除します。 ```copy kubectl delete ns ``` Runtime Manager UI からアプリケーションを削除しないでください。 4. Runtime Fabric をアンインストールします。 5. OpenShift クラスターから Runtime Fabric Operator を削除します (省略可能)。 6. 管理プレーン API エンドポイントに ​`curl`​ コマンドを送信して、アクティベーション ID を再生成します。 Runtime Fabric のアクティベーションの準備ができていることが表示されます。新しい OpenShift クラスターに Runtime Fabric を再度インストールしてアクティベーションすることができます。 ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. 再生成されたアクティベーションデータ ID を使用して、​`cluster-2`​ に Runtime Fabric Operator をインストールします。 インストールは同じ Runtime Fabric 名前空間で行う必要があります。バックアップのすべての表示ラベルは、そのインストールを指し示しています。 8. restore コマンドを実行してリソースのセットを選択し、クラスターに復元します。 ```copy ./rtfctl restore -n ``` 9. Runtime Fabric デプロイメントの状況を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-runtime-fabric) # Runtime Fabric のバックアップと復元 Runtime Fabric サービスと、すべてのデプロイされたアプリケーションとその設定に必要な状態をバックアップして復元するには、次の手順を実行します。 Runtime Fabric の状態に関するデータは Kubernetes クラスターで分散されます。万一システム障害が発生してもアプリケーションが保持されるように、Runtime Fabric が自動的にバックアップされることを確認します。バックアップをスケジュールするときは、1 時間ごとのバックアップを設定してベストプラクティスに従ってください。Runtime Fabric クラスターの外部にある外部ストレージにバックアップを保存します。 `rtfctl`​ バージョン 1.0.70 以降、rtf-agent バージョン 2.6.52 以降を使用すると、​`rtfctl`​ バックアップバンドルに Mule アプリケーションデプロイメントが含まれません。デプロイメントは復元時に Runtime Manager UI から同期されます。 ## [](#バックアップと復元のプロセスを使用する状況)バックアップと復元のプロセスを使用する状況 バックアップと復元のプロセスを使用する一般的なシナリオには次のものがあります。 - Runtime Fabric クラスターのノードをオペレーティングシステムの新しいバージョンに移行するなど、インフラストラクチャの大きなアップグレードを実行する。 - Runtime Fabric クラスターをオンプレミスからクラウドに移行したり、1 つのクラウドプロバイダーから別のクラウドプロバイダーに移行したりする。 - スタンバイクラスターへのフェールオーバーを実行する。

バックアップと復元のプロセスを使用して Runtime Fabric の同時実行インスタンスを作成しないでください。つまり、Runtime Fabric A をバックアップし、Runtime Fabric A がまだアクティブな間にそのバックアップを使用して新しい Runtime Fabric B を作成して、それらを同時に実行しないでください。これにより、アプリケーションデプロイメントの問題が発生します。
## [](#バックアップされるデータ)バックアップされるデータ Runtime Fabric のバックアッププロセスは Runtime Fabric クラスターにのみ影響します。コントロールプレーンのデータはバックアップされません。 通常の Kubernetes クラスターの場合、以下がバックアップされます。 - コントローラーやワーカーノードの設定など、Runtime Fabric クラスターの詳細 - クラスターレベルのセキュアプロパティ - デプロイメント、サービス、サービスアカウント、シークレット、イングレスリソース、ロールバインド、クラスターロール設定、ConfigMap 設定のデータなど、Runtime Fabric とアプリケーション名前空間のすべてのデータ - 現在の ​`rtfctl`​ バージョン - 現在の Runtime Fabric エージェントバージョン - 次のようなアプリケーション詳細: - ポッド、レプリカセット、アプリケーションメタデータ、テンプレートのアプリケーション設定 - Runtime Manager で設定されているアプリケーションプロパティ - 次のような他の MuleSoft 設定のデータ - オブジェクトストア - Edge - Anypoint Monitoring と外部ログフォワーダー OpenShift クラスターの場合、以下がバックアップされます。 - カスタムリソース - アプリケーションの名前空間と、それぞれの名前空間に関する次の情報: - シークレット - サービスアカウント - ConfigMap - サービス - CronJobs - DaemonSets - デプロイメント - イングレス - ロール - ロールバインディング - Runtime Fabric 名前空間からのイングレス ## [](#バックアップされないデータ)バックアップされないデータ - アプリケーションの状態に関するデータ - Ops Center のデータ - コントロールプレーンのデータ ### [](#バックアップ実行後の変更内容が復元されない)バックアップ実行後の変更内容が復元されない バックアップを実行した後の変更は、そのバックアップからクラスターを復元すると存在しなくなります。たとえば、バックアップを実行し、アプリケーションを削除した後、そのバックアップから復元した場合、削除したアプリケーションはクラスターに再作成されますが、Runtime Manager では削除済みとしてマークされています。この結果、アプリケーションの状況は Runtime Manager には ​**\[applying (適用中)\]**​ として表示されます。 バックアップを取った後で変更を行った場合、Runtime Fabric では次のコントロールプレーンの変更は復元されません。 - アプリケーションの作成 - アプリケーションの削除 - アプリケーション設定の更新 - エージェントのアップグレード バックアップを実行した後の変更はコントロールプレーンから再適用できないため、その変更を手動で再適用して不整合を解決する必要があります。 ## [](#バックアップを作成する)バックアップを作成する バックアップを作成するに、次の準備をしてください。 - Runtime Fabric が正しくインストールおよび設定されていることを確認します。 - `rtfctl`​ コマンドラインツールがバージョン 0.3.102 以降にアップグレードされていることを確認します。バージョンを確認するには、任意の Runtime Fabric ノードで ​`rtfctl version`​ を実行します。 - `rtfctl`​ バイナリが現在のディレクトリに存在し、​`kubectl`​ がユーザーの ​`$PATH`​ に存在することを確認します。さらに、Kubernetes (​`kubectl`​) コンテキストが目的のバックアップクラスターに設定されていることを確認します。

VM スナップショットを使用するなど、ノードごとのバックアップの作成はサポートされていません。
バックアップを作成するには、次のコマンドを実行します。 ```copy ./rtfctl backup ``` このコマンドにより、現在のシステム状態のバックアップが ​``​ に作成されます。このパスには、書き込みアクセス権のあるファイルシステム内の任意のパスを指定できます (例: `/opt/anypoint/runtimefabric/backup.tar.gz`​)。 ## [](#復元を実行する)復元を実行する

クラスターを復元する前に、次の情報を確認してください。

  • Runtime Manager にリストされているのと同じ Runtime Fabric クラスター (コントロールプレーン内の同じクラスター) 上で復元を実行する必要があります。

  • バックアップ後に行われたデプロイ済みのアプリケーションおよび管理サービスに対する設定変更は復元されません。

  • アプリケーション監視メトリクスは復元されません。

  • 既存の Runtime Fabric クラスターで復元するには、バックアップを作成するために使用したのと同じバージョンの ​rftctl​ コマンドラインユーティリティを使用します。
Runtime Fabric では、バックアップからクラスターを復元するときに 2 つの対象のオプションが用意されています。 - 既存の Runtime Fabric クラスターを使用する。 - バックアップクラスターと同じ設定で新規の Kubernetes クラスターを作成する。これには、同じ数のサーバーやディスクなどが含まれます。 Runtime Fabric でクラスターを復元する場合は、​`rtfctl`​ インストールコマンドを実行​**せずに**​クラスターを作成してください。クラスターを作成したら、復元プロセスを完了します。 1. クラスターを復元するための対象オプションを選択します。 2. クラスターに ​`rftctl`​ がインストールされていることを確認します。 3. 作成してあるバックアップファイルをコピーして、​`rtfctl`​ で使用できるようにします。 4. Kubernetes (kubectl) コンテキストがバックアップしたクラスターに設定されていることを確認し、元のバックアップしたクラスターですべての Runtime Fabric コンポーネントをスケールダウンします。 ```copy kubectl scale --replicas=0 -n rtf deployment.apps/agent ``` 5. バックアップからクラスターを復元します。 ./rtfctl restore このプロセスは、完了するまで数分かかる場合があります。 Runtime Fabric の場合、​`rtfctl`​ バイナリが現在のディレクトリに存在し、Kubernetes (kubectl) コンテキストが復元先のクラスターに設定されていることを確認します。 ## [](#openshift-クラスターのバックアップを作成して復元する)OpenShift クラスターのバックアップを作成して復元する 次の例の Runtime Fabric には、OpenShift クラスター内のクラスター (​`cluster-1`​) にデプロイされた Mule アプリケーションと設定のセットがあります。バックアップを作成して復元を実行する手順は、次のとおりです。 1. Backup コマンドを実行します。 ```copy ./rtfctl backup -n ```
MuleSoft は、検出されたクラスターに基づいてバックアップを実行します。ただし、​--backup-type​ フラグを使用して、実行するバックアップの種別を手動で指定することもできます。フラグのオプションは ​auto​、​openshift​、​full​ です。デフォルトの ​auto​ フラグオプションを使用すると、MuleSoft は自動的にインフラストラクチャクラスタープロバイダーを検出してバックアップを実行します。
2. `cluster-1`​ をシャットダウンします。 3. 次のコマンドを実行して、すべての Mule アプリケーションのデプロイメントを削除します。 ```copy kubectl delete ns ``` Runtime Manager UI からアプリケーションを削除しないでください。 4. Runtime Fabric をアンインストールします。 5. OpenShift クラスターから Runtime Fabric Operator を削除します (省略可能)。 6. 管理プレーン API エンドポイントに ​`curl`​ コマンドを送信して、アクティベーション ID を再生成します。 Runtime Fabric のアクティベーションの準備ができていることが表示されます。新しい OpenShift クラスターに Runtime Fabric を再度インストールしてアクティベーションすることができます。 ```copy curl --location --request PATCH 'https://anypoint.mulesoft.com/runtimefabric/api/organizations/{org-id}/fabrics/{fabric-id}/regenerateActivationData' \ --header 'Authorization: Bearer {bearer-token} ``` 7. 再生成されたアクティベーションデータ ID を使用して、​`cluster-2`​ に Runtime Fabric Operator をインストールします。 インストールは同じ Runtime Fabric 名前空間で行う必要があります。バックアップのすべての表示ラベルは、そのインストールを指し示しています。 8. restore コマンドを実行してリソースのセットを選択し、クラスターに復元します。 ```copy ./rtfctl restore -n ``` 9. Runtime Fabric デプロイメントの状況を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-runtime-fabric) # Runtime Fabric のリソース割り当てとパフォーマンス Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。 Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。 次のパフォーマンス情報は、カスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを使用するコントローラーノードのクラスターに基づきます。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。負荷ジェネレーターは、同じリージョンの別のクラスターでホストされます。 アプリケーションのデプロイ時に次のリソースを割り当てることができます。 - vCPU コア - `Reserved vCPU` アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。 - `vCPU Limit` アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。 - Memory (メモリ) ## [](#mulesoft-ライセンスコンプライアンス)MuleSoft ライセンスコンプライアンス お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。 1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。 2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。 ## [](#vcpu-の割り当て)vCPU の割り当て \[​`Reserved vCPU`​ (予約済み vCPU)\] と \[​`vCPU Limit`​ (vCPU 制限)\] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。 CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。 \[​`vCPU Limit`​ (vCPU 制限)\] の値が \[​`Reserved vCPU`​ (予約済み vCPU)\] の値よりも高く設定されていると、アプリケーションは、\[vCPU limit (vCPU 制限)\] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。 ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。 ## [](#cpu-バースト)CPU バースト CPU バーストを使用するときは、次の要素を考慮する必要があります。 - 最小予約済み vCPU: 0.02 vCPU。 - vCPU の下限: 0.07 vCPU。 大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。 - CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。 - 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。 - Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。 - 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 50Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。 - 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。 - アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。 どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。 ## [](#メモリの割り当て)メモリの割り当て Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。 - 0.7 GB メモリ (Mule 4) - 0.5 GB メモリ (Mule 3) Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。 ## [](#cloudhub-および-runtime-fabric-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。Anypoint Platform は、デプロイされたアプリケーションへのネイティブメモリの割り当てを JVM を介して、Java メモリ管理の標準プラクティスを考慮して実行します。 CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。 - Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。 使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。 - CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。 ## [](#アプリケーションの起動時間)アプリケーションの起動時間 Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。
vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分
## [](#アプリケーションのパフォーマンス)アプリケーションのパフォーマンス Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。
vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。
## [](#キーと証明書の-cpu-要件)キーと証明書の CPU 要件 最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。
コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8
## [](#キー種別)キー種別 RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。 - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (prime256v1 (P-256) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.5/view-health) # Runtime Fabric の保護 Anypoint Runtime Fabric を保護するには、次のトピックを確認します。 - [Runtime Fabric セキュリティアーキテクチャ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/security-architecture) Runtime Fabric が Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供するしくみを理解します。 - [承認済み名前空間の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/authorized-namespaces) 他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイするために承認済み名前空間を設定します。 - [FIPS 140-2 コンプライアンスモードの有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/enable-fips-140-2-compliance) Runtime Fabric が FIPS 140-2 コンプライアンスモードでアプリケーションコンテナを実行するように設定します。 - [ローカルレジストリの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configure-local-registry) ローカルレジストリを使用して Docker イメージを取得して保存します。 - [Mule Runtime の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configure-hardening) Runtime Fabric を使用して Mule Runtime Engine を強化するためのベストプラクティスを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-runtime-fabric) # Runtime Fabric の保護 Anypoint Runtime Fabric を保護するには、次のトピックを確認します。 - [Runtime Fabric セキュリティアーキテクチャ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/security-architecture) Runtime Fabric が Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供するしくみを理解します。 - [承認済み名前空間の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/authorized-namespaces) 他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイするために承認済み名前空間を設定します。 - [FIPS 140-2 コンプライアンスモードの有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/enable-fips-140-2-compliance) Runtime Fabric が FIPS 140-2 コンプライアンスモードでアプリケーションコンテナを実行するように設定します。 - [ローカルレジストリの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configure-local-registry) ローカルレジストリを使用して Docker イメージを取得して保存します。 - [Mule Runtime の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configure-hardening) Runtime Fabric を使用して Mule Runtime Engine を強化するためのベストプラクティスを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-runtime-fabric) # Runtime Fabric の保護 Anypoint Runtime Fabric を保護するには、次のトピックを確認します。 - [Runtime Fabric セキュリティアーキテクチャ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/security-architecture) Runtime Fabric が Runtime Fabric にデプロイされた MuleSoft アプリケーションと API ゲートウェイを安全に管理する方法を提供するしくみを理解します。 - [承認済み名前空間の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/authorized-namespaces) 他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイするために承認済み名前空間を設定します。 - [FIPS 140-2 コンプライアンスモードの有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/enable-fips-140-2-compliance) Runtime Fabric が FIPS 140-2 コンプライアンスモードでアプリケーションコンテナを実行するように設定します。 - [ローカルレジストリの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configure-local-registry) ローカルレジストリを使用して Docker イメージを取得して保存します。 - [Mule Runtime の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configure-hardening) Runtime Fabric を使用して Mule Runtime Engine を強化するためのベストプラクティスを確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-runtime-fabric) # Runtime Fabric の健全性詳細の表示 Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示できます。 ## [](#健全性の詳細)健全性の詳細 Runtime Fabric バージョン 1.5 以降: 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric クラスターの名前を選択して、管理ページを開きます。 3. **\[Health Details (健全性の詳細)\]**​ を選択します。 **\[Health Details (健全性の詳細)\]**​ セクションには、Runtime Fabric クラスター設定が本番環境や開発環境の要件を満たしているか、あるいはどちらの要件も満たしていないかが表示されます。設定が本番環境と開発環境のどちらの最小要件も満たしていない場合は ​`Not supported`​ と表示されます。 VM/ベアメタルの Runtime Fabric を使用している場合、オペレーションセンターを使用して、パフォーマンスや Runtime Fabric クラスターの健全性に関する追加の情報を表示できます。詳細は、​[「オペレーションセンターを使用した Runtime Fabric の監視」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter)​を参照してください。 # Runtime Fabric の健全性詳細の表示 Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示できます。 ## [](#健全性の詳細)健全性の詳細 Runtime Fabric バージョン 1.5 以降: 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric クラスターの名前を選択して、管理ページを開きます。 3. **\[Health Details (健全性の詳細)\]**​ を選択します。 **\[Health Details (健全性の詳細)\]**​ セクションには、Runtime Fabric クラスター設定が本番環境や開発環境の要件を満たしているか、あるいはどちらの要件も満たしていないかが表示されます。設定が本番環境と開発環境のどちらの最小要件も満たしていない場合は ​`Not supported`​ と表示されます。 # Runtime Fabric の健全性詳細の表示 Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示できます。 ## [](#健全性の詳細)健全性の詳細 Runtime Fabric バージョン 1.5 以降: 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric クラスターの名前を選択して、管理ページを開きます。 3. **\[Health Details (健全性の詳細)\]**​ を選択します。 **\[Health Details (健全性の詳細)\]**​ セクションには、Runtime Fabric クラスター設定が本番環境や開発環境の要件を満たしているか、あるいはどちらの要件も満たしていないかが表示されます。設定が本番環境と開発環境のどちらの最小要件も満たしていない場合は ​`Not supported`​ と表示されます。 # Runtime Fabric の健全性詳細の表示 Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示できます。 ## [](#健全性の詳細)健全性の詳細 Runtime Fabric バージョン 1.5 以降: 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric クラスターの名前を選択して、管理ページを開きます。 3. **\[Health Details (健全性の詳細)\]**​ を選択します。 **\[Health Details (健全性の詳細)\]**​ セクションには、Runtime Fabric クラスター設定が本番環境や開発環境の要件を満たしているか、あるいはどちらの要件も満たしていないかが表示されます。設定が本番環境と開発環境のどちらの最小要件も満たしていない場合は ​`Not supported`​ と表示されます。 # Runtime Fabric の健全性詳細の表示 Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示できます。 ## [](#健全性の詳細)健全性の詳細 Runtime Fabric バージョン 1.5 以降: 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric クラスターの名前を選択して、管理ページを開きます。 3. **\[Health Details (健全性の詳細)\]**​ を選択します。 **\[Health Details (健全性の詳細)\]**​ セクションには、Runtime Fabric クラスター設定が本番環境や開発環境の要件を満たしているか、あるいはどちらの要件も満たしていないかが表示されます。設定が本番環境と開発環境のどちらの最小要件も満たしていない場合は ​`Not supported`​ と表示されます。 # Runtime Fabric の強化 Anypoint Runtime Fabric のセキュリティを強化して脆弱性を減らすには、次のトピックを確認します。 - [Runtime Fabric の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.6/secure-runtime-fabric) Runtime Fabric のセキュリティアーキテクチャについて学び、承認済み名前空間を設定し、ローカルレジストリを使用して FIPS 140-2 を有効にし、Runtime Fabric 向け Mule Runtime を強化することによって Runtime Fabric を保護します。 - [Runtime Fabric 向けの Kubernetes の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configure-kubernetes) 拡張性ベンチマークやクラスター設定などの Kubernetes (K8s) のベストプラクティスを確認します。さらに、​`rtfctl`​ Kubernetes 権限をチェックし、「Kubernetes 強化ガイド」を確認し、Mule アプリケーションの Kubernetes リソースをカスタマイズします。 - [Runtime Fabric のバックアップと復元](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-backup-restore) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric サービスのバックアップや復元を実行します。 ## [](#関連情報)関連情報 - [Runtime Fabric のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/setting-up-runtime-fabric) - [Runtime Fabric の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-index) # Runtime Fabric の強化 Anypoint Runtime Fabric のセキュリティを強化して脆弱性を減らすには、次のトピックを確認します。 - [Runtime Fabric の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.7/secure-runtime-fabric) Runtime Fabric のセキュリティアーキテクチャについて学び、承認済み名前空間を設定し、ローカルレジストリを使用して FIPS 140-2 を有効にし、Runtime Fabric 向け Mule Runtime を強化することによって Runtime Fabric を保護します。 - [Runtime Fabric 向けの Kubernetes の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configure-kubernetes) 拡張性ベンチマークやクラスター設定などの Kubernetes (K8s) のベストプラクティスを確認します。さらに、​`rtfctl`​ Kubernetes 権限をチェックし、「Kubernetes 強化ガイド」を確認し、Mule アプリケーションの Kubernetes リソースをカスタマイズします。 - [Runtime Fabric のバックアップと復元](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-backup-restore) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric サービスのバックアップや復元を実行します。 ## [](#関連情報)関連情報 - [Runtime Fabric のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/setting-up-runtime-fabric) - [Runtime Fabric の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-index) # Runtime Fabric の強化 Anypoint Runtime Fabric のセキュリティを強化して脆弱性を減らすには、次のトピックを確認します。 - [Runtime Fabric の保護](https://docs.mulesoft.com/jp/runtime-fabric/2.8/secure-runtime-fabric) Runtime Fabric のセキュリティアーキテクチャについて学び、承認済み名前空間を設定し、ローカルレジストリを使用して FIPS 140-2 を有効にし、Runtime Fabric 向け Mule Runtime を強化することによって Runtime Fabric を保護します。 - [Runtime Fabric 向けの Kubernetes の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configure-kubernetes) 拡張性ベンチマークやクラスター設定などの Kubernetes (K8s) のベストプラクティスを確認します。さらに、​`rtfctl`​ Kubernetes 権限をチェックし、「Kubernetes 強化ガイド」を確認し、Mule アプリケーションの Kubernetes リソースをカスタマイズします。 - [Runtime Fabric のバックアップと復元](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-backup-restore) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric サービスのバックアップや復元を実行します。 ## [](#関連情報)関連情報 - [Runtime Fabric のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/setting-up-runtime-fabric) - [Runtime Fabric の管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-index) # Runtime Fabric の手動インストール このトピックでは、データセンターでホストする VM に VM/ベアメタルの Anypoint Runtime Fabric を手動でインストールする方法について説明します。

VM/ベアメタルの Runtime Fabric をインストールする前に、​「VM/ベアメタルの Runtime Fabric の共有責任」​を参照してください。インフラストラクチャがハードウェア、オペレーティングシステム、ネットワークの最小要件を満たしていない場合、VM/ベアメタルの Runtime Fabric は正常に動作しません。

組織の運用チーム、ネットワークチーム、セキュリティチームが関与する必要があります。​「Anypoint Runtime Fabric インストールの前提条件」​を参照してください。
## [](#始める前に)始める前に インストールを開始する前に次の条件が満たされていることを確認します。 - [Runtime Manager で Runtime Fabric を作成](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-create-rtf-arm)​している。 - [「VM/ベアメタルの Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​で示されているとおりに、必要なハードウェアがプロビジョニングされている。 - 必要なディスクが各 VM のブロックデバイスとしてリストされている。ディスクをマウントまたはフォーマットしないでください。 - [「VM/ベアメタルの Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​で示されているとおりに、必要なポートが開いており、ホスト名が許可リストに追加されている。 - 環境で実行されているすべてのウイルス対策エージェント (McAfee など) が無効化されている。 - 負荷分散の要件を確認済みである。VM/ベアメタルの Runtime Fabric では、インバウンドロードバランサーは共有モードまたは専用モードで実行されます。 - **\[Shared Mode (共有モード)\]**​ では、内部ロードバランサーの CPU コア数とメモリ量を指定できます。共有モードでは、内部ロードバランサーはコントローラーノード全体に分散されます。 **\[Shared Mode (共有モード)\]**​ はデフォルトの設定です。 - **\[Dedicated Mode (専用モード)\]**​ では、すべての使用可能なリソースが内部ロードバランサー専用であることが指定されます。このため、CPU コア数およびメモリ量を選択することはできません。専用モードでは、内部ロードバランサーは専用の内部ロードバランサーノードにデプロイされます。 詳細は、​[「Runtime Fabric の管理」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-index)​を参照してください。 ## [](#インストール中に実行される操作)インストール中に実行される操作 インストールでは各 VM で次のアクションが実行されます。 - 専用ディスクをフォーマットします。 - 専用ディスクを適切なパスにマウントします。 - iptables ルールを設定します。 - 必要なカーネルモジュールを有効にします。 - システムサービスを有効にして、再読み込みします。 ## [](#mule-ライセンスキーの-base64-でのエンコード)Mule ライセンスキーの Base64 でのエンコード Runtime Fabric をインストールするには、Mule ライセンスキーが Base64 でエンコードされている必要があります。ライセンスファイル (​`license.lic`​) をインストーラーノードにコピーします。 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドをターミナルで実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -b0 license.lic) - Unix では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -w0 license.lic) - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (​`C:\Program Files\Git\usr\bin`​) と一緒に含まれている ​`base64.exe`​ プログラムを使用します。 - 次の Powershell コマンドを使用します。 $BASE64\_ENCODED\_LICENSE=\[convert\]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) ### [](#windows)Windows Windows でライセンスファイルをエンコードするには、シェルターミナルエミュレーター (cygwin など) や Unix ベースのコンピューターを使用して、次の手順を実行します。 1. 組織の Mule Enterprise ライセンスキーファイル (​`license.lic`​) を見つけ、必要に応じて Unix 環境に転送します。 2. 次のコマンドを実行して、ライセンスキーを Base64 でエンコードします。 base64 -w0 license.lic ## [](#インストールスクリプトのダウンロード)インストールスクリプトのダウンロード インストールでリーダーとして機能するコントローラー VM にスクリプト ZIP ファイルをダウンロードします。

VM/ベアメタルの Runtime Fabric の特定のバージョンをインストールするには、インストール時にリーダーとして機能するコントローラー VM のパス ​/opt/anypoint/runtimefabric/installer.tar.gz​ にインストールパッケージを転送します。これは、Anypoint コントロールプレーンからの最新パッケージのダウンロードをスキップします。
1. Anypoint Platform にサインインし、\[Runtime Manager\] に移動します。 2. 左側のナビゲーションペインで、​**Runtime Fabric**​ を選択します。 3. 作成した Runtime Fabric をクリックします。その状態は \[Activating (有効化中)\] になっている必要があります。 4. **\[Download files (ファイルをダウンロード)\]**​ ボタンを右クリックし、\[Copy link location (リンクの場所をコピー)\] を選択します。 5. コントローラー VM にファイルをダウンロードします。 1. コントローラー VM へのシェル (SSH セッション) を開きます。 2. ファイル ​`curl -L {INSTALLER_URL} --output rtf-install-scripts.zip`​ をダウンロードします。 6. ダウンロードしたら、​`rtf-install-scripts.zip`​ ファイルを別のディレクトリに展開します。 mkdir -p ./rtf-install-scripts && unzip rtf-install-scripts.zip -d ./rtf-install-scripts `rtf-install-scripts/`​ ディレクトリ内に、次を含む ​`manual`​ という名前のサブディレクトリがあります。 - `generate-configs.sh`​: 各 VM の環境変数の生成に役立つスクリプト。 - `README.md`​: インストールをサポートする手順を含むマークダウンファイル。 ## [](#インストール用変数の生成とインストールスクリプトの実行)インストール用変数の生成とインストールスクリプトの実行

インストールスクリプトは Bash シェルから実行する必要があります。
1. [インストールで必要な変数](#variables-to-define)​を理解します。 2. `./generate-configs.sh`​ スクリプトを使用して、VM ごとに環境変数を生成します。 3. 以下のコマンドをテキストエディターにコピーして、一重引用符内の各変数の値を入力します。必要に応じて、​[省略可能な変数](#optional-variables)​を追加して定義します。一般的な例は、アウトバウンドインターネット接続に HTTP プロキシが必要な場合です。 RTF\_CONTROLLER\_IPS='' \\ RTF\_WORKER\_IPS='' \\ RTF\_DOCKER\_DEVICE='' \\ RTF\_ETCD\_DEVICE='' \\ RTF\_ACTIVATION\_DATA='' \\ RTF\_MULE\_LICENSE='' \\ ./generate-configs.sh 4. コントローラー VM でシェル/SSH を開き、展開したディレクトリから ​`manual`​ サブディレクトリに移動します。 5. テキストエディターからコマンドをコピーし、ターミナルに貼り付けて、コントローラー VM でコマンドを実行します。このスクリプトは、各 VM で実行する一連の手順とスクリプトを各 VM の IP アドレスで分類して出力します。出力された手順を表示するには、上へのスクロールが必要な場合があります。 1. 各 VM でその IP アドレスに基づいてスニペットを実行し、必要な環境変数を適用します。 2. 各 VM で ​`./scripts/init.sh`​ ファイルを ​`/opt/anypoint/runtimefabric`​ にコピーして、スクリプトが実行可能であることを確認します。以下のスクリプトは、現在の作業ディレクトリに、展開されたディレクトリ ​`rtf-install-scripts`​ が含まれることを前提とします。 mkdir -p /opt/anypoint/runtimefabric && cp ./rtf-install-scripts/scripts/init.sh /opt/anypoint/runtimefabric/init.sh && chmod +x /opt/anypoint/runtimefabric/init.sh 6. コントローラー VM で特権モードで ​`init.sh`​ スクリプトを実行します。

init.sh​ スクリプトを実行するには、ルート権限が必要です。
sudo /opt/anypoint/runtimefabric/init.sh 7. インストールで事前チェックが完了するまで待機します。出力は「​**Execute preflight checks (事前チェックを実行)**​」メッセージを過ぎても継続し、チェックが合格したことを示す必要があります。 ... Tue Aug 14 02:28:54 UTC Starting the installation Tue Aug 14 02:28:56 UTC Operation has been created Tue Aug 14 02:28:57 UTC Execute preflight checks Tue Aug 14 02:29:48 UTC Configure packages for all nodes Tue Aug 14 02:29:59 UTC Bootstrap all nodes ... 8. 他のすべての VM で特権モードで ​`init.sh`​ スクリプトを実行します。このステップは各 VM で同時に実行できます。 sudo /opt/anypoint/runtimefabric/init.sh 9. インストールプロセスでエラーが発生した場合、エラーの解決方法を示すメッセージを出力してプロセスは終了します。多くの場合、1 つまたは複数の変数を有効な値に更新し、​`init.sh`​ スクリプトを再実行することで、エラーを解決できます。

このステップにより、クラスターを形成するすべての VM に VM/ベアメタルの Runtime Fabric がインストールされます。完了するまでに 15 ～ 25 分以上かかることがあります。

インストールが正常に完了すると、ファイル ​/opt/anypoint/runtimefabric/.state/init-complete​ が作成されます。

内部ロードバランサーは、共有モードの場合はコントローラーノード全体に分散され、専用モードの場合は内部ロードバランサーノードにデプロイされます。
## [](#定義する変数)定義する変数 Rutime Fabric をインストールするには次の必須の変数を使用します。
Table 1. 必須のインストール変数
パラメーター 説明 例

RTF_CONTROLLER_IPS

空白で区切られた、コントローラー VM の IP アドレス。1 番目の IP アドレスは、インストールのリーダーである必要があります。

"10.3.0.4 10.3.0.5 10.3.0.6"

RTF_WORKER_IPS

空白で区切られた、ワーカー VM の IP アドレス。

"10.3.0.11 10.3.0.12 10.3.0.13"

RTF_DOCKER_DEVICE

プロビジョニングされた 1000 IOPS をサポートする Docker 専用のディスクのブロックデバイスのフルパス。

/dev/xvdc

RTF_ETCD_DEVICE

プロビジョニングされた 3000 IOPS をサポートする etcd 専用のディスクのブロックデバイスのフルパス。

/dev/xvdb

RTF_ACTIVATION_DATA

エンコードされた Runtime Fabric アクティベーションデータ。このデータにアクセスするには、Runtime Manager で Runtime Fabric を表示します。

NzdlMzU1YTktMzAxMC00OGE0LWJlMGQtMDdxxxx

RTF_MULE_LICENSE

組織の Mule Enterprise ライセンスキー (​license.lic​) を Base64 でエンコードしたコンテンツ。

==ABCD12934…​
ディスクへのブロックデバイスのパスを特定するには、VM で ​lsblk​ コマンドを使用します。 Mule ライセンスキーを Base64 でエンコードするには、上記の「Mule ライセンスキーの Base64 でのエンコード」の手順を参照してください。
### [](#省略可能な変数)省略可能な変数 次の変数は、組織の要件に基づいて定義できます。
Table 2. 省略可能なインストール変数
パラメーター 説明 例

RTF_HTTP_PROXY

アウトバウンド HTTP 要求を転送する HTTP プロキシサーバーのホスト名およびポート。

http://1.1.1.1:80

RTF_MONITORING_PROXY

SOCKS5 プロキシサーバーがメトリクスとログを Anypoint Monitoring に転送するためのホスト名とポート、および省略可能なユーザー名とパスワード。

socks5://user:pass@1.1.1.2:800

RTF_NO_PROXY

プロキシをバイパスする必要があるホストのカンマ区切りリスト。

1.1.1.1,no-proxy.com

RTF_SERVICE_UID

各 Runtime Fabric サービスを実行するユーザー ID を表す整数。「planet」という名前のユーザーを作成するデフォルトの動作を上書きします。

1000

RTF_SERVICE_GID

各 Runtime Fabric サービスを実行するときに使用されるグループ ID を表す整数。「planet」という名前のグループを作成するデフォルトの動作を上書きします。

900

POD_NETWORK_CIDR

カスタムポッド CIDR ブロックをサポートします。

10.244.0.0/16

SERVICE_CIDR

カスタムサービス CIDR ブロックをサポートします。

10.100.0.0/16

disable_selinux

ホストのオペレーティングシステムで SELinux を無効化/有効化するブール変数。デフォルト値は ​true​ で、SELinux を無効にします。

ホストオペレーティングシステムが RHEL 8 の場合、インストールに失敗するため、​false​ に設定しないでください。

true

RTF_PRIVATE_INTERFACE

非公開 IP アドレスがネットワークインターフェースから検出されることを許可します。

eth0
## [](#インストールの進行状況の監視)インストールの進行状況の監視 `init.sh`​ スクリプトの実行時に ​`forground`​ パラメーターが渡された場合、インストールログがターミナルに出力されます。それ以外の場合、インストール中に進行状況を参照するには、各 VM の出力ログを確認します。 1. VM への別のシェル (SSH セッション) を開きます。 2. `/var/log/rtf-init.log`​ にある出力ログを確認します。 tail -f /var/log/rtf-init.log
各 VM の同じログを確認して、その進行状況を参照できます。
インストールが正常に完了すると、ファイル ​`/opt/anypoint/runtimefabric/.state/init-complete`​ が作成されます。 ## [](#オペレーションセンターへのアクセス)オペレーションセンターへのアクセス インストールが正常に完了したら、オペレーションセンターにログインして Runtime Fabric インフラストラクチャの状況を表示します。オペレーションセンターへのアクセスとオペレーションセンターのユーザー名とパスワードの決定については、​[「Anypoint Runtime Fabric でのオペレーションセンターの使用」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter)​を参照してください。 ## [](#一般的なエラー)一般的なエラー インストールプロセスでエラーが発生した場合、エラーの解決方法を示すメッセージを出力してプロセスは終了します。多くの場合、​`/opt/anypoint/runtimefabric/env`​ ファイルの 1 つまたは複数の値を正しい値に更新し、​`init.sh`​ スクリプトを再実行することで、エラーを解決できます。 ## [](#次のステップ)次のステップ Anypoint Runtime Fabric にアプリケーションをデプロイする前に、次の手順を実行する必要があります。 - [Anypoint Runtime Fabric でのビジネスグループと環境の関連付け](https://docs.mulesoft.com/jp/runtime-fabric/1.13/associate-environments) - [Anypoint Runtime Fabric でのインバウンドトラフィックの有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic) - [Runtime Fabric で使用されるプロキシの管理](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-proxy) - [Anypoint Runtime Fabric でのログ転送の設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) - [Anypoint Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) # Runtime Fabric の管理 Anypoint Runtime Fabric をインストールして設定し、Mule アプリケーションと API プロキシをデプロイメントした後で、追加のタスクが必要になる場合があります。 - 監視とビュー - Runtime Fabric の状況を表示します。 [「Runtime Fabric の健全性詳細の表示」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/view-health)​を参照してください。 - Anypoint Monitoring および Anypoint Visualizer を使用して、Runtime Fabric にデプロイされたアプリケーションを監視します。 [「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-monitor-applications)​を参照してください。 - Runtime Fabric インストールのパフォーマンスと健全性を監視します。 [「Anypoint Runtime Fabric でのオペレーションセンターの使用」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter)​を参照してください。 - 更新 - rtfctl をインストールして Runtime Fabric の設定を管理します。 [「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​を参照してください。 - Runtime Fabric にパッチをインストールして、他の定期メンテナンスを実行します。 [「定期メンテナンスの実行」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-patches)​を参照してください。 - Mule ライセンスキーを置き換えます。 [「Mule ライセンスキーの置き換え」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/replace-license-key)​を参照してください。 - メンテナンス - Runtime Fabric アウトバウンド接続で使用されるプロキシ設定を設定します。 [「Runtime Fabric で使用されるプロキシの管理」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-proxy)​を参照してください。 - Runtime Fabric のセキュアプロパティを管理します。 [「Runtime Fabric でのセキュアプロパティの管理」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-secure-properties)​を参照してください。 - 相互認証の有効化。 [「Anypoint Platform との相互認証の設定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/config-mutual-auth)​を参照してください。 - クラスターのノードを追加または削除して、クラスターの健全性を維持したり、アップグレードを実行したりします。 [「Runtime Fabric へのノードの追加または削除」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-nodes)​を参照してください。 - Runtime Fabric を停止して再起動します。 そのためには、各インスタンスを停止して再起動する必要があります。 - Runtime Fabric のバックアップ。 [「Runtime Fabric のバックアップと復元」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-backup-restore)​を参照してください。 - Runtime Fabric を手動でアンインストールします。 [「Runtime Fabric の手動アンインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/uninstall-manual)​を参照してください。 - インストールのエラーまたはインストール後のエラーのトラブルシューティングを行います。 [「Runtime Fabric のトラブルシューティング」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/troubleshoot-guide)​を参照してください。 ## [](#関連情報)関連情報 - [Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) # Runtime Fabric の管理 Anypoint Runtime Fabric をインストールして設定し、Mule アプリケーションと API プロキシをデプロイメントした後で、追加のタスクが必要になる場合があります。 - 監視とビュー - Runtime Fabric の状況を表示します。 [「Runtime Fabric の健全性詳細の表示」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/view-health)​を参照してください。 - Anypoint Monitoring および Anypoint Visualizer を使用して、Runtime Fabric にデプロイされたアプリケーションを監視します。 [「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-monitor-applications)​を参照してください。 - Runtime Fabric インストールのパフォーマンスと健全性を監視します。 - 更新 - rtfctl をインストールして Runtime Fabric の設定を管理します。 [「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​を参照してください。 - Runtime Fabric にパッチをインストールして、他の定期メンテナンスを実行します。 - Mule ライセンスキーを置き換えます。 [「Mule ライセンスキーの置き換え」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/replace-license-key)​を参照してください。 - メンテナンス - Runtime Fabric アウトバウンド接続で使用されるプロキシ設定を設定します。 [「Runtime Fabric で使用されるプロキシの管理」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-proxy-self)​を参照してください。 - Runtime Fabric のセキュアプロパティを管理します。 [「Runtime Fabric でのセキュアプロパティの管理」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-secure-properties)​を参照してください。 - 相互認証の有効化。 - Runtime Fabric のバックアップ。 [「Runtime Fabric のバックアップと復元」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-backup-restore)​を参照してください。 - Runtime Fabric を手動でアンインストールします。 [「Runtime Fabric のアンインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/uninstall-self)​を参照してください。 # Runtime Fabric の管理 Anypoint Runtime Fabric を管理するには、次のトピックを確認します。 - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.6/view-health) Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示します。 - [RTFCTL ツールの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric のインストール、設定、アップグレード、アンインストール、トラブルシューティング、バックアップ、復元を行います。さらに、デプロイ済み Mule アプリケーションの管理、Mule アプリケーションの値の保護、Mule ライセンスキーのインストールや置換を行うこともできます。 - [Mule ライセンスキーの置き換え](https://docs.mulesoft.com/jp/runtime-fabric/2.6/replace-license-key) `rtfctl`​ コマンドラインツールを使用して期限切れの Mule ライセンスキーを置き換えます。 - [Runtime Fabric バージョンのダウングレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/downgrade-runtime-fabric) `rtfctl`​ コマンドラインツールまたは Helm を使用して Runtime Fabric のバージョンをダウングレードします。 - [Helm 管理 Runtime Fabric への移行](https://docs.mulesoft.com/jp/runtime-fabric/2.6/migrate-helm) `rtfctl`​ を使用してインストールされた Runtime Fabric を Helm ネイティブに移行します。 - [firewalld を使用する場合の転送の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/prereq-firewalld-forwarding) Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、Docker デバイスで転送を有効にします。 ## [](#関連情報)関連情報 - [Runtime Fabric のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/setting-up-runtime-fabric) - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-runtime-fabric) # Runtime Fabric の管理 Anypoint Runtime Fabric を管理するには、次のトピックを確認します。 - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.7/view-health) Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示します。 - [RTFCTL ツールの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric のインストール、設定、アップグレード、アンインストール、トラブルシューティング、バックアップ、復元を行います。さらに、デプロイ済み Mule アプリケーションの管理、Mule アプリケーションの値の保護、Mule ライセンスキーのインストールや置換を行うこともできます。 - [Mule ライセンスキーの置き換え](https://docs.mulesoft.com/jp/runtime-fabric/2.7/replace-license-key) `rtfctl`​ コマンドラインツールを使用して期限切れの Mule ライセンスキーを置き換えます。 - [Runtime Fabric バージョンのダウングレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/downgrade-runtime-fabric) `rtfctl`​ コマンドラインツールまたは Helm を使用して Runtime Fabric のバージョンをダウングレードします。 - [Helm 管理 Runtime Fabric への移行](https://docs.mulesoft.com/jp/runtime-fabric/2.7/migrate-helm) `rtfctl`​ を使用してインストールされた Runtime Fabric を Helm ネイティブに移行します。 - [firewalld を使用する場合の転送の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/prereq-firewalld-forwarding) Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、Docker デバイスで転送を有効にします。 ## [](#関連情報)関連情報 - [Runtime Fabric のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/setting-up-runtime-fabric) - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-runtime-fabric) # Runtime Fabric の管理 Anypoint Runtime Fabric を管理するには、次のトピックを確認します。 - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.8/view-health) Anypoint Runtime Manager を使用して、Anypoint Runtime Fabric クラスターの健全性を表示します。 - [RTFCTL ツールの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl) `rtfctl`​ コマンドラインツールを使用して Runtime Fabric のインストール、設定、アップグレード、アンインストール、トラブルシューティング、バックアップ、復元を行います。さらに、デプロイ済み Mule アプリケーションの管理、Mule アプリケーションの値の保護、Mule ライセンスキーのインストールや置換を行うこともできます。 - [Mule ライセンスキーの置き換え](https://docs.mulesoft.com/jp/runtime-fabric/2.8/replace-license-key) `rtfctl`​ コマンドラインツールを使用して期限切れの Mule ライセンスキーを置き換えます。 - [Runtime Fabric バージョンのダウングレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/downgrade-runtime-fabric) `rtfctl`​ コマンドラインツールまたは Helm を使用して Runtime Fabric のバージョンをダウングレードします。 - [Helm 管理 Runtime Fabric への移行](https://docs.mulesoft.com/jp/runtime-fabric/2.8/migrate-helm) `rtfctl`​ を使用してインストールされた Runtime Fabric を Helm ネイティブに移行します。 - [firewalld を使用する場合の転送の有効化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/prereq-firewalld-forwarding) Red Hat Enterprise Linux (RHEL) 7.x オペレーティングシステムで ​`firewalld`​ を使用している場合は、Docker デバイスで転送を有効にします。 ## [](#関連情報)関連情報 - [Runtime Fabric のセットアップ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/setting-up-runtime-fabric) - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-runtime-fabric) # Runtime Fabric の要件と制限事項 Anypoint Runtime Fabric のインストール、設定、管理を行う前に、次の要件と制限事項を確認してください。 ## [](#制限事項)制限事項 Runtime Fabric の制限事項を次の表に示します。
制限事項 説明

ノード種別

VM ベースのノードが必要です。たとえば、Fargate はサポートされていません。

アプリケーションあたりのレプリカ数

アプリケーションあたりのレプリカの最大数は 8 です。

Runtime Fabric あたりの関連付けられた環境数

Runtime Fabric は任意のビジネスグループの最大 200 個の環境に関連付けることができます。たとえば、開発環境および本番環境を組織 A に関連付けて別の開発環境を組織 B に関連付けた場合、3 つの環境の関連付けがあることになります。

ビジネスグループ

ビジネスグループの組織あたり最大 50 個の Runtime Fabric を作成できます。サブ組織には、別のサブ組織と共有される Runtime Fabric に加えて、最大 50 個の Runtime Fabric を含めることができます。たとえば、親組織 A とその子組織 B の場合、組織 A に 50 個の Runtime Fabric、組織 B に 50 個の Runtime Fabric を含めることができます。 組織 A の 50 個の Runtime Fabric をすべて組織 B と共有することもでき、その結果、組織 B のリストビューには合計 100 個の Runtime Fabric が表示されます。
## [](#runtime-fabric-k8s-クラスター内でのサードパーティ製ソフトウェアの使用)Runtime Fabric K8s クラスター内でのサードパーティ製ソフトウェアの使用 サードパーティソフトウェアと Runtime Fabric ソフトウェアまたは Mule デプロイメントとの間の分離を確実にするために、認証済みの名前空間機能を使用することが想定されています。サードパーティソフトウェアは、rtf 固有ではない名前空間にインストールして、Runtime Fabric や Mule Runtime Engine の機能に干渉しないようにしてください。 ## [](#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響 Anypoint Runtime Fabric には特定のハードウェアおよび OS の要件があります。MuleSoft サポートでは、​[Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/2.5/)​ のインストールの前提条件で指定された要件の検証および認証に基づいてサポート SLA および重要度レベルを提供しています。 一部のサードパーティソフトウェアでは、ホストへのルートアクセス権が必要です。このようなソフトウェア (ウイルス対策ソフトウェアおよび DPI ソフトウェアを含むがこれに限定されない) が Runtime Fabric の動作および要件と干渉することがわかっています。MuleSoft サポートがウイルス対策ソフトウェアを検出した多くのサポートケースで、ポートのブロック、ノード間通信のブロック、Docker のデフォルトブリッジの削除、ファイルシステムへのアクセスの問題など、Runtime Fabric のインストール、アップグレード、通常の操作と干渉する問題が確認されています。 Runtime Fabric で異常な動作が見つかった場合は、サードパーティソフトウェア (ウイルス対策ソフトウェアや DPI ソフトウェアを含む) がその動作の原因となっているかを判断するため、これらのソフトウェアを無効にするよう要求される場合があります。これらのソフトウェアを無効にすることで適切な Runtime Fabric の機能が回復する場合には、そのソフトウェアパッケージと Runtime Fabric 間で互換性がないことを暗に示していると思われるため、サポートケースは解決済みであるとみなされます。 Runtime Fabric の特定のコンポーネントと干渉する従来のセキュリティツールを実行することが厳密に要求される場合は、この要件を満たせるように Kubernetes をサポートするベンダーおよびセキュリティエキスパートにサポートを依頼できます。クラウドプラットフォームベンダーでは多くの場合、 [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)​ などのよく知られたセキュリティベンチマークと一貫性があるクラウド中心のコントロールが追加されます。 ## [](#runtime-fabric-の要件)Runtime Fabric の要件 以降の説明で、Anypoint Runtime Fabric を実行するための全般的な要件を示します。 ### [](#kubernetes-のサポート)Kubernetes のサポート Runtime Fabric には、プロビジョニングされ運用可能な Kubernetes クラスターが必要です。​`rtfctl`​ コマンドラインユーティリティを使用して、環境が正しく設定されているかどうかを確認します。​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed)​を参照してください。 お使いの Runtime Fabric にサポートされている Kubernetes バージョンのリストについては、​[リリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。 ### [](#サポート対象のアーキテクチャ)サポート対象のアーキテクチャ Anypoint Runtime Fabric には、x86-64 アーキテクチャを使用するワーカーノードが必要です。ARM ベースのノードはサポートされていません。 ### [](#オペレーティングシステム)オペレーティングシステム Anypoint Runtime Fabric は、Amazon EKS、AKS、GKE、または RedHat OpenShift でサポートされる Linux ディストリビューションで動作します。 ### [](#ノードおよびリソース)ノードおよびリソース 一般に、Kubernetes ベンダーによって提供されるベストプラクティスに従って、可用性を確保し、インフラストラクチャの管理を簡略化します。 パフォーマンスを最適にするには、Runtime Fabric のインストールにはそれぞれの次が備わっている 2 つ以上のノードが必要です。 - 少なくとも 2 つの CPU コア - 少なくとも 15 GiB の RAM - 少なくとも 250 GiB の空きディスク容量 各 Anypoint Runtime Fabric インスタンスで実行するワークロードの量と種別に応じて、割り当てられるノード数とリソース量を調整します。 ### [](#runtime-fabric-kubernetes-のロール)Runtime Fabric Kubernetes のロール 次の Runtime Fabric Cluster のロールにより、Kubernetes シークレットに保存されるデータが管理されます。 - `am-log-forwarder` - `rtf:agent`​ - `rtf:certificate-renewal` - `rtf-restricted`​ - `rtf:cluster-status`​ - `rtf:install`​ - `rtf:persistence-gateway-clro-read-only`​ - `rtf:upgrade` - `rtf:mule-clusterip-service` RTF エージェントなどの Runtime Fabric コンポーネントには、Runtime Fabric 機能の実行に関連する Kubernetes リソースを監視または更新するために、コンポーネントが実行されているクラスターから Kube API をコンシュームする正当なユースケースがあります。 ### [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 Anypoint Runtime Fabric を適切に使用するには、Anypoint Platform アカウントに次の権限が必要です。 - Anypoint Platform ユーザーの権限を管理するには、​[Anypoint Access Management](https://docs.mulesoft.com/jp/access-management/)​ を使用するための権限が必要です。 - アプリケーションをデプロイおよび管理するには、次の権限を持っていることを確認してください。 - Anypoint Runtime Manager を使用する権限 - Anypoint Platform アカウントで有効になっている Exchange コントリビューター権限 - Runtime Manager の \[Applications (アプリケーション)\] ページでアプリケーションを表示するために必要な、アプリケーションと Runtime Fabric インスタンスに対する参照権限 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」権限または「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ### [](#ネットワーク設定)ネットワーク設定 Anypoint Runtime Fabric では、ネットワークポート、ホスト名、証明書を正しく機能するように IT 管理者が設定する必要があります。​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-self-managed-network-configuration)​を参照してください。 ### [](#イングレスコントローラー)イングレスコントローラー Runtime Fabric では、Kubernetes 環境で十分に動作するすべてのイングレスコントローラーがサポートされます。アプリケーションごとに専用のイングレスがあるデプロイメントモデルもサポートされます。既製のイングレスコントローラーのほとんどではこのモデルがサポートされています。

GKE と一緒に含まれているイングレスコントローラーのデフォルトの動作では、アプリケーションごとに個別の HTTP ロードバランサーを提供します。この動作が望ましくないと思われる場合は、可能な解決策を探すか、別のイングレスコントローラーを使用することを検討してください。詳細は、次の KB 記事​を参照してください。
### [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 Runtime Fabric にデプロイされたアプリケーションでは、​`stdout`​ に直接ログを記録するのが一般的な方法です。コンテナランタイムでは、ディスクのファイルにコンソールログを保存します。このファイルの保存場所はコンテナランタイムと設定によって異なります。詳細は Kubernetes 環境のドキュメントを参照してください。 ### [](#外部ログ転送)外部ログ転送 Anypoint Runtime Fabric では、ログを外部システムに転送しません。自分でこの設定をインストールして管理する必要があります。Amazon EKS、AKS、または GKE で実行される Kubernetes 環境と互換性のある任意の外部ログ転送エージェントを使用できます。次のような一般的に使用されるログ転送エージェントがあります。 - Splunk Connect for Kubernetes - Fluentbit Runtime Fabric では Log4j アペンダーがサポートされています。 ### [](#監視)監視 [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ では、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスが提供されます。 メトリクスを収集するために、Anypoint Monitoring では Runtime Fabric の各アプリケーションデプロイメントの一部としてサイドカーコンテナを使用します。監視を管理する方法など、詳細は​[「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/manage-monitor-applications)​を参照してください。 Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。 # Runtime Fabric の要件と制限事項 Anypoint Runtime Fabric のインストール、設定、管理を行う前に、次の要件と制限事項を確認してください。 ## [](#license-compliance)MuleSoft ライセンスコンプライアンス お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。 1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。 2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。 ## [](#制限事項)制限事項 Runtime Fabric の制限事項を次の表に示します。
制限事項 説明

ノード種別

VM ベースのノードが必要です。たとえば、Fargate はサポートされていません。

アプリケーションあたりのレプリカ数

アプリケーションあたりのレプリカの最大数は 16 です。

Runtime Fabric あたりの関連付けられた環境数

Runtime Fabric は任意のビジネスグループの最大 200 個の環境に関連付けることができます。たとえば、開発環境および本番環境を組織 A に関連付けて別の開発環境を組織 B に関連付けた場合、3 つの環境の関連付けがあることになります。

ビジネスグループ

ビジネスグループの組織あたり最大 50 個の Runtime Fabric を作成できます。サブ組織には、別のサブ組織と共有される Runtime Fabric に加えて、最大 50 個の Runtime Fabric を含めることができます。たとえば、親組織 A とその子組織 B の場合、組織 A に 50 個の Runtime Fabric、組織 B に 50 個の Runtime Fabric を含めることができます。 組織 A の 50 個の Runtime Fabric をすべて組織 B と共有することもでき、その結果、組織 B のリストビューには合計 100 個の Runtime Fabric が表示されます。
## [](#runtime-fabric-k8s-クラスター内でのサードパーティ製ソフトウェアの使用)Runtime Fabric K8s クラスター内でのサードパーティ製ソフトウェアの使用 サードパーティソフトウェアと Runtime Fabric ソフトウェアまたは Mule デプロイメントとの間の分離を確実にするために、認証済みの名前空間機能を使用することが想定されています。サードパーティソフトウェアは、rtf 固有ではない名前空間にインストールして、Runtime Fabric や Mule Runtime Engine の機能に干渉しないようにしてください。 ## [](#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響 Anypoint Runtime Fabric には特定のハードウェアおよび OS の要件があります。MuleSoft サポートでは、​[Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/2.6/)​ のインストールの前提条件で指定された要件の検証および認証に基づいてサポート SLA および重要度レベルを提供しています。 一部のサードパーティソフトウェアでは、ホストへのルートアクセス権が必要です。このようなソフトウェア (ウイルス対策ソフトウェアおよび DPI ソフトウェアを含むがこれに限定されない) が Runtime Fabric の動作および要件と干渉することがわかっています。MuleSoft サポートがウイルス対策ソフトウェアを検出した多くのサポートケースで、ポートのブロック、ノード間通信のブロック、Docker のデフォルトブリッジの削除、ファイルシステムへのアクセスの問題など、Runtime Fabric のインストール、アップグレード、通常の操作と干渉する問題が確認されています。 Runtime Fabric で異常な動作が見つかった場合は、サードパーティソフトウェア (ウイルス対策ソフトウェアや DPI ソフトウェアを含む) がその動作の原因となっているかを判断するため、これらのソフトウェアを無効にするよう要求される場合があります。これらのソフトウェアを無効にすることで適切な Runtime Fabric の機能が回復する場合には、そのソフトウェアパッケージと Runtime Fabric 間で互換性がないことを暗に示していると思われるため、サポートケースは解決済みであるとみなされます。 Runtime Fabric の特定のコンポーネントと干渉する従来のセキュリティツールを実行することが厳密に要求される場合は、この要件を満たせるように Kubernetes をサポートするベンダーおよびセキュリティエキスパートにサポートを依頼できます。クラウドプラットフォームベンダーでは多くの場合、 [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)​ などのよく知られたセキュリティベンチマークと一貫性があるクラウド中心のコントロールが追加されます。 ## [](#runtime-fabric-の要件)Runtime Fabric の要件 以降の説明で、Anypoint Runtime Fabric を実行するための全般的な要件を示します。 ### [](#kubernetes-のサポート)Kubernetes のサポート Runtime Fabric には、プロビジョニングされ運用可能な Kubernetes クラスターが必要です。​`rtfctl`​ コマンドラインユーティリティを使用して、環境が正しく設定されているかどうかを確認します。​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed)​を参照してください。 お使いの Runtime Fabric にサポートされている Kubernetes バージョンのリストについては、​[リリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。 ### [](#サポート対象のアーキテクチャ)サポート対象のアーキテクチャ Anypoint Runtime Fabric には、x86-64 アーキテクチャを使用するワーカーノードが必要です。ARM ベースのノードはサポートされていません。 ### [](#オペレーティングシステム)オペレーティングシステム Anypoint Runtime Fabric は、Amazon EKS、AKS、GKE、または RedHat OpenShift でサポートされる Linux ディストリビューションで動作します。 ### [](#ノードおよびリソース)ノードおよびリソース 一般に、Kubernetes ベンダーによって提供されるベストプラクティスに従って、可用性を確保し、インフラストラクチャの管理を簡略化します。 パフォーマンスを最適にするには、Runtime Fabric のインストールにはそれぞれの次が備わっている 2 つ以上のノードが必要です。 - 少なくとも 2 つの CPU コア - 少なくとも 15 GiB の RAM - 少なくとも 250 GiB の空きディスク容量 各 Anypoint Runtime Fabric インスタンスで実行するワークロードの量と種別に応じて、割り当てられるノード数とリソース量を調整します。 ### [](#runtime-fabric-kubernetes-のロール)Runtime Fabric Kubernetes のロール 次の Runtime Fabric Cluster のロールにより、Kubernetes シークレットに保存されるデータが管理されます。 - `am-log-forwarder` - `rtf:agent`​ - `rtf:certificate-renewal` - `rtf-restricted`​ - `rtf:cluster-status`​ - `rtf:install`​ - `rtf:persistence-gateway-clro-read-only`​ - `rtf:upgrade` - `rtf:mule-clusterip-service` RTF エージェントなどの Runtime Fabric コンポーネントには、Runtime Fabric 機能の実行に関連する Kubernetes リソースを監視または更新するために、コンポーネントが実行されているクラスターから Kube API をコンシュームする正当なユースケースがあります。 ### [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 Anypoint Runtime Fabric を適切に使用するには、Anypoint Platform アカウントに次の権限が必要です。 - Anypoint Platform ユーザーの権限を管理するには、​[Anypoint Access Management](https://docs.mulesoft.com/jp/access-management/)​ を使用するための権限が必要です。 - アプリケーションをデプロイおよび管理するには、次の権限を持っていることを確認してください。 - Anypoint Runtime Manager を使用する権限 - Anypoint Platform アカウントで有効になっている Exchange コントリビューター権限 - Runtime Manager の \[Applications (アプリケーション)\] ページでアプリケーションを表示するために必要な、アプリケーションと Runtime Fabric インスタンスに対する参照権限 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」権限または「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ### [](#ネットワーク設定)ネットワーク設定 Anypoint Runtime Fabric では、ネットワークポート、ホスト名、証明書を正しく機能するように IT 管理者が設定する必要があります。​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed-network-configuration)​を参照してください。 ### [](#イングレスコントローラー)イングレスコントローラー Runtime Fabric では、Kubernetes 環境で十分に動作するすべてのイングレスコントローラーがサポートされます。アプリケーションごとに専用のイングレスがあるデプロイメントモデルもサポートされます。既製のイングレスコントローラーのほとんどではこのモデルがサポートされています。

GKE と一緒に含まれているイングレスコントローラーのデフォルトの動作では、アプリケーションごとに個別の HTTP ロードバランサーを提供します。この動作が望ましくないと思われる場合は、可能な解決策を探すか、別のイングレスコントローラーを使用することを検討してください。詳細は、次の KB 記事​を参照してください。
### [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 Runtime Fabric にデプロイされたアプリケーションでは、​`stdout`​ に直接ログを記録するのが一般的な方法です。コンテナランタイムでは、ディスクのファイルにコンソールログを保存します。このファイルの保存場所はコンテナランタイムと設定によって異なります。詳細は Kubernetes 環境のドキュメントを参照してください。 ### [](#外部ログ転送)外部ログ転送 Anypoint Runtime Fabric では、ログを外部システムに転送しません。自分でこの設定をインストールして管理する必要があります。Amazon EKS、AKS、または GKE で実行される Kubernetes 環境と互換性のある任意の外部ログ転送エージェントを使用できます。次のような一般的に使用されるログ転送エージェントがあります。 - Fluentbit Runtime Fabric では Log4j アペンダーがサポートされています。 ### [](#監視)監視 [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ では、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスが提供されます。 メトリクスを収集するために、Anypoint Monitoring では Runtime Fabric の各アプリケーションデプロイメントの一部としてサイドカーコンテナを使用します。監視を管理する方法など、詳細は​[「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-monitor-applications)​を参照してください。 Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。 # Runtime Fabric の要件と制限事項 Anypoint Runtime Fabric のインストール、設定、管理を行う前に、次の要件と制限事項を確認してください。 ## [](#license-compliance)MuleSoft ライセンスコンプライアンス お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。 1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。 2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。 ## [](#制限事項)制限事項 Runtime Fabric の制限事項を次の表に示します。
制限事項 説明

ノード種別

VM ベースのノードが必要です。たとえば、Fargate はサポートされていません。

アプリケーションあたりのレプリカ数

アプリケーションあたりのレプリカの最大数は 16 です。*

Runtime Fabric あたりの関連付けられた環境数

Runtime Fabric は任意のビジネスグループの最大 200 個の環境に関連付けることができます。たとえば、開発環境および本番環境を組織 A に関連付けて別の開発環境を組織 B に関連付けた場合、3 つの環境の関連付けがあることになります。

ビジネスグループ

ビジネスグループの組織あたり最大 50 個の Runtime Fabric を作成できます。サブ組織には、別のサブ組織と共有される Runtime Fabric に加えて、最大 50 個の Runtime Fabric を含めることができます。たとえば、親組織 A とその子組織 B の場合、組織 A に 50 個の Runtime Fabric、組織 B に 50 個の Runtime Fabric を含めることができます。 組織 A の 50 個の Runtime Fabric をすべて組織 B と共有することもでき、その結果、組織 B のリストビューには合計 100 個の Runtime Fabric が表示されます。
Runtime Fabric では、すべてのフォームでアプリケーションあたり最大 16 個のレプリカがサポートされます。ただし、使用状況価格設定と水平ポッド自動スケーリング機能を使用している場合はこの限りではありません。その場合、アプリケーションあたりのレプリカの最大数は 8 のままです。 ## [](#runtime-fabric-k8s-クラスター内でのサードパーティ製ソフトウェアの使用)Runtime Fabric K8s クラスター内でのサードパーティ製ソフトウェアの使用 サードパーティソフトウェアと Runtime Fabric ソフトウェアまたは Mule デプロイメントとの間の分離を確実にするために、認証済みの名前空間機能を使用することが想定されています。サードパーティソフトウェアは、rtf 固有ではない名前空間にインストールして、Runtime Fabric や Mule Runtime Engine の機能に干渉しないようにしてください。 ## [](#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響 Anypoint Runtime Fabric には特定のハードウェアおよび OS の要件があります。MuleSoft サポートでは、​[Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/2.7/)​ のインストールの前提条件で指定された要件の検証および認証に基づいてサポート SLA および重要度レベルを提供しています。 一部のサードパーティソフトウェアでは、ホストへのルートアクセス権が必要です。このようなソフトウェア (ウイルス対策ソフトウェアおよび DPI ソフトウェアを含むがこれに限定されない) が Runtime Fabric の動作および要件と干渉することがわかっています。MuleSoft サポートがウイルス対策ソフトウェアを検出した多くのサポートケースで、ポートのブロック、ノード間通信のブロック、Docker のデフォルトブリッジの削除、ファイルシステムへのアクセスの問題など、Runtime Fabric のインストール、アップグレード、通常の操作と干渉する問題が確認されています。 Runtime Fabric で異常な動作が見つかった場合は、サードパーティソフトウェア (ウイルス対策ソフトウェアや DPI ソフトウェアを含む) がその動作の原因となっているかを判断するため、これらのソフトウェアを無効にするよう要求される場合があります。これらのソフトウェアを無効にすることで適切な Runtime Fabric の機能が回復する場合には、そのソフトウェアパッケージと Runtime Fabric 間で互換性がないことを暗に示していると思われるため、サポートケースは解決済みであるとみなされます。 Runtime Fabric の特定のコンポーネントと干渉する従来のセキュリティツールを実行することが厳密に要求される場合は、この要件を満たせるように Kubernetes をサポートするベンダーおよびセキュリティエキスパートにサポートを依頼できます。クラウドプラットフォームベンダーでは多くの場合、 [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)​ などのよく知られたセキュリティベンチマークと一貫性があるクラウド中心のコントロールが追加されます。 ## [](#runtime-fabric-の要件)Runtime Fabric の要件 以降の説明で、Anypoint Runtime Fabric を実行するための全般的な要件を示します。 ### [](#kubernetes-のサポート)Kubernetes のサポート Runtime Fabric には、プロビジョニングされ運用可能な Kubernetes クラスターが必要です。​`rtfctl`​ コマンドラインユーティリティを使用して、環境が正しく設定されているかどうかを確認します。​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed)​を参照してください。 お使いの Runtime Fabric にサポートされている Kubernetes バージョンのリストについては、​[リリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。 ### [](#サポート対象のアーキテクチャ)サポート対象のアーキテクチャ Anypoint Runtime Fabric には、x86-64 アーキテクチャを使用するワーカーノードが必要です。ARM ベースのノードはサポートされていません。 ### [](#オペレーティングシステム)オペレーティングシステム Anypoint Runtime Fabric は、Amazon EKS、AKS、GKE、または RedHat OpenShift でサポートされる Linux ディストリビューションで動作します。 ### [](#ノードおよびリソース)ノードおよびリソース 一般に、Kubernetes ベンダーによって提供されるベストプラクティスに従って、可用性を確保し、インフラストラクチャの管理を簡略化します。 パフォーマンスを最適にするには、Runtime Fabric のインストールにはそれぞれの次が備わっている 2 つ以上のノードが必要です。 - 少なくとも 2 つの CPU コア - 少なくとも 15 GiB の RAM - 少なくとも 250 GiB の空きディスク容量 各 Anypoint Runtime Fabric インスタンスで実行するワークロードの量と種別に応じて、割り当てられるノード数とリソース量を調整します。 ### [](#runtime-fabric-kubernetes-のロール)Runtime Fabric Kubernetes のロール 次の Runtime Fabric Cluster のロールにより、Kubernetes シークレットに保存されるデータが管理されます。 - `am-log-forwarder` - `rtf:agent`​ - `rtf:certificate-renewal` - `rtf-restricted`​ - `rtf:cluster-status`​ - `rtf:install`​ - `rtf:persistence-gateway-clro-read-only`​ - `rtf:upgrade` - `rtf:mule-clusterip-service` RTF エージェントなどの Runtime Fabric コンポーネントには、Runtime Fabric 機能の実行に関連する Kubernetes リソースを監視または更新するために、コンポーネントが実行されているクラスターから Kube API をコンシュームする正当なユースケースがあります。 ### [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 Anypoint Runtime Fabric を適切に使用するには、Anypoint Platform アカウントに次の権限が必要です。 - Anypoint Platform ユーザーの権限を管理するには、​[Anypoint Access Management](https://docs.mulesoft.com/jp/access-management/)​ を使用するための権限が必要です。 - アプリケーションをデプロイおよび管理するには、次の権限を持っていることを確認してください。 - Anypoint Runtime Manager を使用する権限 - Anypoint Platform アカウントで有効になっている Exchange コントリビュータ権限 - Runtime Manager の \[Applications (アプリケーション)\] ページでアプリケーションを表示するために必要な、アプリケーションと Runtime Fabric インスタンスに対する参照権限 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」権限または「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ### [](#ネットワーク設定)ネットワーク設定 Anypoint Runtime Fabric では、ネットワークポート、ホスト名、証明書を正しく機能するように IT 管理者が設定する必要があります。​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed-network-configuration)​を参照してください。 ### [](#イングレスコントローラー)イングレスコントローラー Runtime Fabric では、Kubernetes 環境で十分に動作するすべてのイングレスコントローラーがサポートされます。アプリケーションごとに専用のイングレスがあるデプロイメントモデルもサポートされます。既製のイングレスコントローラーのほとんどではこのモデルがサポートされています。

GKE と一緒に含まれているイングレスコントローラーのデフォルトの動作では、アプリケーションごとに個別の HTTP ロードバランサーを提供します。この動作が望ましくないと思われる場合は、可能な解決策を探すか、別のイングレスコントローラーを使用することを検討してください。詳細は、次の KB 記事​を参照してください。
### [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 Runtime Fabric にデプロイされたアプリケーションでは、​`stdout`​ に直接ログを記録するのが一般的な方法です。コンテナランタイムでは、ディスクのファイルにコンソールログを保存します。このファイルの保存場所はコンテナランタイムと設定によって異なります。詳細は Kubernetes 環境のドキュメントを参照してください。 ### [](#外部ログ転送)外部ログ転送 Anypoint Runtime Fabric では、ログを外部システムに転送しません。自分でこの設定をインストールして管理する必要があります。Amazon EKS、AKS、または GKE で実行される Kubernetes 環境と互換性のある任意の外部ログ転送エージェントを使用できます。次のような一般的に使用されるログ転送エージェントがあります。 - Fluentbit Runtime Fabric では Log4j アペンダーがサポートされています。 ### [](#監視)監視 [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ では、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスが提供されます。 メトリクスを収集するために、Anypoint Monitoring では Runtime Fabric の各アプリケーションデプロイメントの一部としてサイドカーコンテナを使用します。監視を管理する方法など、詳細は​[「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-monitor-applications)​を参照してください。 Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。 # Runtime Fabric の要件と制限事項 Anypoint Runtime Fabric のインストール、設定、管理を行う前に、次の要件と制限事項を確認してください。 ## [](#license-compliance)MuleSoft ライセンスコンプライアンス お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。 1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。 2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。 Runtime Fabric 使用状況レポートについては、​[「Runtime Fabric Compliance Tracking (Runtime Fabric コンプライアンス追跡)」](https://docs.mulesoft.com/jp/general/usage-metrics#rtf-compliance-tracking)​を参照してください。 ## [](#制限事項)制限事項 Runtime Fabric の制限事項を次の表に示します。
制限事項 説明

ノード種別

VM ベースのノードが必要です。たとえば、Fargate はサポートされていません。

アプリケーションあたりのレプリカ数

アプリケーションあたりのレプリカの最大数は 16 です。*

Runtime Fabric あたりの関連付けられた環境数

Runtime Fabric は任意のビジネスグループの最大 200 個の環境に関連付けることができます。たとえば、開発環境および本番環境を組織 A に関連付けて別の開発環境を組織 B に関連付けた場合、3 つの環境の関連付けがあることになります。

ビジネスグループ

ビジネスグループの組織あたり最大 50 個の Runtime Fabric を作成できます。サブ組織には、別のサブ組織と共有される Runtime Fabric に加えて、最大 50 個の Runtime Fabric を含めることができます。たとえば、親組織 A とその子組織 B の場合、組織 A に 50 個の Runtime Fabric、組織 B に 50 個の Runtime Fabric を含めることができます。 組織 A の 50 個の Runtime Fabric をすべて組織 B と共有することもでき、その結果、組織 B のリストビューには合計 100 個の Runtime Fabric が表示されます。
Runtime Fabric では、すべてのフォームでアプリケーションあたり最大 16 個のレプリカがサポートされます。ただし、使用状況価格設定と水平ポッド自動スケーリング機能を使用している場合はこの限りではありません。その場合、アプリケーションあたりのレプリカの最大数は 8 のままです。 ## [](#runtime-fabric-k8s-クラスター内でのサードパーティ製ソフトウェアの使用)Runtime Fabric K8s クラスター内でのサードパーティ製ソフトウェアの使用 サードパーティソフトウェアと Runtime Fabric ソフトウェアまたは Mule デプロイメントとの間の分離を確実にするために、認証済みの名前空間機能を使用することが想定されています。サードパーティソフトウェアは、rtf 固有ではない名前空間にインストールして、Runtime Fabric や Mule Runtime Engine の機能に干渉しないようにしてください。 ## [](#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響 Anypoint Runtime Fabric には特定のハードウェアおよび OS の要件があります。MuleSoft サポートでは、​[Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/2.8/)​ のインストールの前提条件で指定された要件の検証および認証に基づいてサポート SLA および重要度レベルを提供しています。 一部のサードパーティソフトウェアでは、ホストへのルートアクセス権が必要です。このようなソフトウェア (ウイルス対策ソフトウェアおよび DPI ソフトウェアを含むがこれに限定されない) が Runtime Fabric の動作および要件と干渉することがわかっています。MuleSoft サポートがウイルス対策ソフトウェアを検出した多くのサポートケースで、ポートのブロック、ノード間通信のブロック、Docker のデフォルトブリッジの削除、ファイルシステムへのアクセスの問題など、Runtime Fabric のインストール、アップグレード、通常の操作と干渉する問題が確認されています。 Runtime Fabric で異常な動作が見つかった場合は、サードパーティソフトウェア (ウイルス対策ソフトウェアや DPI ソフトウェアを含む) がその動作の原因となっているかを判断するため、これらのソフトウェアを無効にするよう要求される場合があります。これらのソフトウェアを無効にすることで適切な Runtime Fabric の機能が回復する場合には、そのソフトウェアパッケージと Runtime Fabric 間で互換性がないことを暗に示していると思われるため、サポートケースは解決済みであるとみなされます。 Runtime Fabric の特定のコンポーネントと干渉する従来のセキュリティツールを実行することが厳密に要求される場合は、この要件を満たせるように Kubernetes をサポートするベンダーおよびセキュリティエキスパートにサポートを依頼できます。クラウドプラットフォームベンダーでは多くの場合、 [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)​ などのよく知られたセキュリティベンチマークと一貫性があるクラウド中心のコントロールが追加されます。 ## [](#runtime-fabric-の要件)Runtime Fabric の要件 以降の説明で、Anypoint Runtime Fabric を実行するための全般的な要件を示します。 ### [](#kubernetes-のサポート)Kubernetes のサポート Runtime Fabric には、プロビジョニングされ運用可能な Kubernetes クラスターが必要です。​`rtfctl`​ コマンドラインユーティリティを使用して、環境が正しく設定されているかどうかを確認します。​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed)​を参照してください。 お使いの Runtime Fabric にサポートされている Kubernetes バージョンのリストについては、​[リリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes-2.x.x)​を参照してください。 ### [](#サポート対象のアーキテクチャ)サポート対象のアーキテクチャ Anypoint Runtime Fabric には、x86-64 アーキテクチャを使用するワーカーノードが必要です。ARM ベースのノードはサポートされていません。 ### [](#オペレーティングシステム)オペレーティングシステム Anypoint Runtime Fabric は、Amazon EKS、AKS、GKE、または RedHat OpenShift でサポートされる Linux ディストリビューションで動作します。 ### [](#ノードおよびリソース)ノードおよびリソース 一般に、Kubernetes ベンダーによって提供されるベストプラクティスに従って、可用性を確保し、インフラストラクチャの管理を簡略化します。 パフォーマンスを最適にするには、Runtime Fabric のインストールにはそれぞれの次が備わっている 2 つ以上のノードが必要です。 - 少なくとも 2 つの CPU コア - 少なくとも 15 GiB の RAM - 少なくとも 250 GiB の空きディスク容量 各 Anypoint Runtime Fabric インスタンスで実行するワークロードの量と種別に応じて、割り当てられるノード数とリソース量を調整します。 ### [](#runtime-fabric-kubernetes-のロール)Runtime Fabric Kubernetes のロール 次の Runtime Fabric Cluster のロールにより、Kubernetes シークレットに保存されるデータが管理されます。 - `am-log-forwarder` - `rtf:agent`​ - `rtf:certificate-renewal` - `rtf-restricted`​ - `rtf:cluster-status`​ - `rtf:install`​ - `rtf:persistence-gateway-clro-read-only`​ - `rtf:upgrade` - `rtf:mule-clusterip-service` RTF エージェントなどの Runtime Fabric コンポーネントには、Runtime Fabric 機能の実行に関連する Kubernetes リソースを監視または更新するために、コンポーネントが実行されているクラスターから Kube API をコンシュームする正当なユースケースがあります。 ### [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 Anypoint Runtime Fabric を適切に使用するには、Anypoint Platform アカウントに次の権限が必要です。 - Anypoint Platform ユーザーの権限を管理するには、​[Anypoint Access Management](https://docs.mulesoft.com/jp/access-management/)​ を使用するための権限が必要です。 - アプリケーションをデプロイおよび管理するには、次の権限を持っていることを確認してください。 - Anypoint Runtime Manager を使用する権限 - Anypoint Platform アカウントで有効になっている Exchange コントリビュータ権限 - Runtime Manager の \[Applications (アプリケーション)\] ページでアプリケーションを表示するために必要な、アプリケーションと Runtime Fabric インスタンスに対する参照権限 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」権限または「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ### [](#ネットワーク設定)ネットワーク設定 Anypoint Runtime Fabric では、ネットワークポート、ホスト名、証明書を正しく機能するように IT 管理者が設定する必要があります。​[「Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed-network-configuration)​を参照してください。 ### [](#イングレスコントローラー)イングレスコントローラー Runtime Fabric では、Kubernetes 環境で十分に動作するすべてのイングレスコントローラーがサポートされます。アプリケーションごとに専用のイングレスがあるデプロイメントモデルもサポートされます。既製のイングレスコントローラーのほとんどではこのモデルがサポートされています。

GKE と一緒に含まれているイングレスコントローラーのデフォルトの動作では、アプリケーションごとに個別の HTTP ロードバランサーを提供します。この動作が望ましくないと思われる場合は、可能な解決策を探すか、別のイングレスコントローラーを使用することを検討してください。詳細は、次の KB 記事​を参照してください。
### [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 Runtime Fabric にデプロイされたアプリケーションでは、​`stdout`​ に直接ログを記録するのが一般的な方法です。コンテナランタイムでは、ディスクのファイルにコンソールログを保存します。このファイルの保存場所はコンテナランタイムと設定によって異なります。詳細は Kubernetes 環境のドキュメントを参照してください。 ### [](#外部ログ転送)外部ログ転送 Anypoint Runtime Fabric では、ログを外部システムに転送しません。自分でこの設定をインストールして管理する必要があります。Amazon EKS、AKS、または GKE で実行される Kubernetes 環境と互換性のある任意の外部ログ転送エージェントを使用できます。次のような一般的に使用されるログ転送エージェントがあります。 - Fluentbit Runtime Fabric では Log4j アペンダーがサポートされています。 ### [](#監視)監視 [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ では、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスが提供されます。 メトリクスを収集するために、Anypoint Monitoring では Runtime Fabric の各アプリケーションデプロイメントの一部としてサイドカーコンテナを使用します。監視を管理する方法など、詳細は​[「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-monitor-applications)​を参照してください。 Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。 # Runtime Fabric の設定 Anypoint Runtime Fabric を設定するには、次のトピックを確認します。 - [ビジネスグループと環境の関連付け](https://docs.mulesoft.com/jp/runtime-fabric/2.6/associate-environments) Mule アプリケーションまたは API プロキシをデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付けます。 - [RTFCTL を使用した Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#configure-rtfctl) `rtfctl apply`​、​`update`​、​`wait`​ コマンドを使用して Runtime Fabric を設定します。 - [イングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration) イングレスリソーステンプレートを使用してイングレス設定をカスタマイズします。 - [Red Hat OpenShift ルートの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configure-openshift-routes) Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定します。 - [永続性ゲートウェイの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/persistence-gateway) 永続性ゲートウェイを使用すると、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。 - [プロキシの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-proxy-self) Runtime Fabric にデプロイされた Mule アプリケーションを実行およびホストする場合にプロキシを設定します。 - [水平ポッド自動スケーリング (HPA) の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/configure-horizontal-autoscaling) CPU 使用量をシグナルとして、それに応じて追加レプリカの作成や不要なレプリカの削除を行うことで、Mule アプリケーションデプロイメントの水平スケーリングを設定します。 # Runtime Fabric の設定 Anypoint Runtime Fabric を設定するには、次のトピックを確認します。 - [ビジネスグループと環境の関連付け](https://docs.mulesoft.com/jp/runtime-fabric/2.7/associate-environments) Mule アプリケーションまたは API プロキシをデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付けます。 - [RTFCTL を使用した Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#configure-rtfctl) `rtfctl apply`​、​`update`​、​`wait`​ コマンドを使用して Runtime Fabric を設定します。 - [イングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration) イングレスリソーステンプレートを使用してイングレス設定をカスタマイズします。 - [Red Hat OpenShift ルートの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configure-openshift-routes) Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定します。 - [永続性ゲートウェイの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/persistence-gateway) 永続性ゲートウェイを使用すると、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。 - [プロキシの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-proxy-self) Runtime Fabric にデプロイされた Mule アプリケーションを実行およびホストする場合にプロキシを設定します。 - [水平ポッド自動スケーリング (HPA) の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/configure-horizontal-autoscaling) CPU 使用量をシグナルとして、それに応じて追加レプリカの作成や不要なレプリカの削除を行うことで、Mule アプリケーションデプロイメントの水平スケーリングを設定します。 # Runtime Fabric の設定 Anypoint Runtime Fabric を設定するには、次のトピックを確認します。 - [ビジネスグループと環境の関連付け](https://docs.mulesoft.com/jp/runtime-fabric/2.8/associate-environments) Mule アプリケーションまたは API プロキシをデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付けます。 - [RTFCTL を使用した Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#configure-rtfctl) `rtfctl apply`​、​`update`​、​`wait`​ コマンドを使用して Runtime Fabric を設定します。 - [イングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration) イングレスリソーステンプレートを使用してイングレス設定をカスタマイズします。 - [Red Hat OpenShift ルートの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configure-openshift-routes) Mule アプリケーションのイングレスエンドポイントを作成するための Red Hat OpenShift ルートを設定します。 - [永続性ゲートウェイの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/persistence-gateway) 永続性ゲートウェイを使用すると、Mule Runtime インスタンスにデプロイされた Mule アプリケーションではアプリケーションレプリカと再起動でデータを保存して共有できます。 - [プロキシの設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-proxy-self) Runtime Fabric にデプロイされた Mule アプリケーションを実行およびホストする場合にプロキシを設定します。 - [水平ポッド自動スケーリング (HPA) の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/configure-horizontal-autoscaling) CPU 使用量をシグナルとして、それに応じて追加レプリカの作成や不要なレプリカの削除を行うことで、Mule アプリケーションデプロイメントの水平スケーリングを設定します。 # Runtime Fabric バージョンのダウングレード Runtime Fabric バージョン 2.6.x をダウングレードする必要がある場合、Runtime Fabric を下位バージョンにパッチ適用することで、バージョンをダウングレードする必要があります。 - RTFCTL - Helm `rtfctl`​ を使用してインストールされた Runtime Fabric の場合、次の PATCH 要求を使用してダウングレードするエージェントバージョンを指定します。 curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' Helm を使用してインストールされた Runtime Fabric の場合、次の Helm コマンドを使用します。 helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x AM ログ転送を使用している場合、次のステップを追加で実行する必要があります。 1. 次の API をコールして daemon-set ログ転送を有効にします (ベアラートークンが必要です)。 curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. 必要に応じて、am-log-forwarder の daemon-set が稼働中でない場合は、次のいずれかのオプションを使用してサービスを開始します。 - Anypoint Monitoring UI (​**RuntimeFabrics -→ Fabric -→ LogForwarding**​) で、​**\[Show logs in Anypoint Monitoring (Anypoint Monitoring でログを表示する)\]**​ をオンにします。 - または API 要求を送信します。 curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}'
Runtime Fabric エージェントバージョンが 2.6.x であるときに再デプロイされた Mule アプリケーションは、ダウングレードされた rtf-agent バージョンに応じてリソース割り当てを減らすために再デプロイする必要があります。
# Runtime Fabric バージョンのダウングレード Runtime Fabric バージョン 2.6.x をダウングレードする必要がある場合、Runtime Fabric を下位バージョンにパッチ適用することで、バージョンをダウングレードする必要があります。 - RTFCTL - Helm `rtfctl`​ を使用してインストールされた Runtime Fabric の場合、次の PATCH 要求を使用してダウングレードするエージェントバージョンを指定します。 curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' Helm を使用してインストールされた Runtime Fabric の場合、次の Helm コマンドを使用します。 helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x AM ログ転送を使用している場合、次のステップを追加で実行する必要があります。 1. 次の API をコールして daemon-set ログ転送を有効にします (ベアラートークンが必要です)。 curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. 必要に応じて、am-log-forwarder の daemon-set が稼働中でない場合は、次のいずれかのオプションを使用してサービスを開始します。 - Anypoint Monitoring UI (​**RuntimeFabrics -→ Fabric -→ LogForwarding**​) で、​**\[Show logs in Anypoint Monitoring (Anypoint Monitoring でログを表示する)\]**​ をオンにします。 - または API 要求を送信します。 curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}'
Runtime Fabric エージェントバージョンが 2.6.x であるときに再デプロイされた Mule アプリケーションは、ダウングレードされた rtf-agent バージョンに応じてリソース割り当てを減らすために再デプロイする必要があります。
# Runtime Fabric バージョンのダウングレード Runtime Fabric バージョン 2.6.x をダウングレードする必要がある場合、Runtime Fabric を下位バージョンにパッチ適用することで、バージョンをダウングレードする必要があります。 - RTFCTL - Helm `rtfctl`​ を使用してインストールされた Runtime Fabric の場合、次の PATCH 要求を使用してダウングレードするエージェントバージョンを指定します。 curl -X PATCH -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics/ --data-binary '{"version":"x.x.x"}' Helm を使用してインストールされた Runtime Fabric の場合、次の Helm コマンドを使用します。 helm upgrade --install runtime-fabric rtf/rtf-agent -f values.yaml -n --version x.x.x AM ログ転送を使用している場合、次のステップを追加で実行する必要があります。 1. 次の API をコールして daemon-set ログ転送を有効にします (ベアラートークンが必要です)。 curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding/appScoped?enabled=false 2. 必要に応じて、am-log-forwarder の daemon-set が稼働中でない場合は、次のいずれかのオプションを使用してサービスを開始します。 - Anypoint Monitoring UI (​**RuntimeFabrics -→ Fabric -→ LogForwarding**​) で、​**\[Show logs in Anypoint Monitoring (Anypoint Monitoring でログを表示する)\]**​ をオンにします。 - または API 要求を送信します。 curl -X PATCH -H 'Authorization: Bearer ' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, \*/\*' \\ https://anypoint.mulesoft.com/runtimefabric/api/organizations//fabrics//logforwarding -d '{"anypointMonitoring": true}'
Runtime Fabric エージェントバージョンが 2.6.x であるときに再デプロイされた Mule アプリケーションは、ダウングレードされた rtf-agent バージョンに応じてリソース割り当てを減らすために再デプロイする必要があります。
# Runtime Fabric への API プロキシのデプロイ Runtime Fabric では、API プロキシを Mule Runtime にデプロイできます。 ## [](#始める前に)始める前に API プロキシを Mule Runtime にデプロイするには、アカウントに次の権限が必要です。 - 「Manage APIs Configuration (API 設定の管理)」権限 - 「Deploy API Proxies (API プロキシのデプロイ)」権限 API Gateway バージョン 3.8.7、3.9.1、または 4.1.2 を使用していることを確認する必要があります。 API を Mule 4 環境にデプロイしていて HTTPS 要求をサポートするためにプロキシを有効にする場合は、最初に​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 デフォルトでは、次のリソースがプロキシアプリケーションに割り当てられます。 - CPU: 0.2 vCore - メモリ: 1.024 GB リソース割り当ての設定は、Runtime Manager のアプリケーションの ​**\[Settings (設定)\]**​ ページで更新できます。 ## [](#api-プロキシをデプロイする)API プロキシをデプロイする 1. Anypoint Platform から、​**\[API Manager\]**​ > ​**\[Manage API (API を管理)\]**​ > ​**\[Manage API From Exchange (Exchange から API を管理)\]**​ を選択します。 2. **\[API Name (API 参照名)\]**​ で、Exchange に保存されたアセットの名前を検索します。 API の ​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ 項目は、Exchang から自動的に入力されます。 3. **\[Managing type (管理種別)\]**​ に、​**\[Endpoint with Proxy (プロキシを使用したエンドポイント)\]**​ を選択します。 4. **\[Proxy deployment target (プロキシデプロイメント対象)\]**​ に、\[Runtime Fabric\] を選択します。 5. Mule バージョンを選択します。 6. **\[Implementation URI (実装 URI)\]**​ に、プロキシにアクセスするベース URL パスを指定します。 7. 必要に応じて、​**\[Path (パス)\]**​ を指定します。 8. **\[Advanced options (詳細オプション)\]**​ をクリックして必要に応じて ​**\[TLS context for outbound traffic (アウトバウンドトラフィックの TLS コンテキスト)\]**​ (HTTPS の場合)、​**\[Proxy version (プロキシバージョン)\]**​、​**\[Validations (検証)\]**​、​**\[Response timeout (応答タイムアウト)\]**​、​**\[Port (ポート)\]**​ などの高度なパラメーターを指定します。 9. **\[Save (保存)\]**​ をクリックします。 設定情報が保存され、API Manager に ​**\[Deployment Configuration (デプロイメント設定)\]**​ セクションが表示されます。 10. **\[Deployment Configuration (デプロイメント設定)\]**​ セクションで、次の設定を定義します。 - **\[Runtime Fabric target (Runtime Fabric 対象)\]**​ を選択します。 - **\[Runtime version (ランタイムバージョン)\]**​ を選択します。 - プロキシアプリケーションの名前を入力します。 API Manager は API プロキシを Runtime Fabric にデプロイします。デプロイ中は、次の情報を示すデプロイメントの状況ダイアログが表示されます。 1. **プロキシのデプロイ**​。 2. **アプリケーションの起動**​。 3. **デプロイメント成功**​。 デプロイ後は、デプロイした API プロキシを Runtime Manager から管理できます。 ## [](#https-プロキシの有効化)HTTPS プロキシの有効化 HTTPS 要求をサポートするようにプロキシを有効化する方法 1. [「API プロキシのダウンロード」](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​の手順を使用して、API ゲートウェイをダウンロードし、API Manager からデプロイします。 2. [「Anypoint Studio を使用して TLS を設定する」](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls)​の手順を使用して、Anypoint Studio でゲートウェイを開き、キーストア (SSL 証明書) を挿入します。 3. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric)​の手順に従って、Runtime Manager を使用してゲートウェイをエクスポートおよびデプロイします。 4. [「How to enable last-mile security in Runtime Fabric (RTF) (Runtime Fabric (RTF) で Last Mile セキュリティを有効化する方法)」](https://help.mulesoft.com/s/article/How-to-enable-last-mile-security-in-Runtime-Fabric-RTF)​の手順を使用して、アプリケーションの Last Mile セキュリティを有効にします。 ## [](#関連リソース)関連リソース - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) # Runtime Fabric への API プロキシのデプロイ Runtime Fabric では、API プロキシを Mule Runtime にデプロイできます。 ## [](#始める前に)始める前に API プロキシを Mule Runtime にデプロイするには、アカウントに次の権限が必要です。 - 「Manage APIs Configuration (API 設定の管理)」権限 - 「Deploy API Proxies (API プロキシのデプロイ)」権限 API Gateway バージョン 3.8.7、3.9.1、または 4.1.2 を使用していることを確認する必要があります。 API を Mule 4 環境にデプロイしていて HTTPS 要求をサポートするためにプロキシを有効にする場合は、最初に​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 デフォルトでは、次のリソースがプロキシアプリケーションに割り当てられます。 - CPU: 0.2 vCore - メモリ: 1.024 GB リソース割り当ての設定は、Runtime Manager のアプリケーションの ​**\[Settings (設定)\]**​ ページで更新できます。 ## [](#api-プロキシをデプロイする)API プロキシをデプロイする API Manager を使用してプロキシを Runtime Fabric にデプロイします。HTTP または HTTPS 経由でのインバウンド要求とアウトバウンド要求をサポートするようにプロキシを有効化できます。 プロキシで HTTPS をサポートする必要がある場合、使用を開始する前に追加の要件について API Manager ドキュメントの​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 1. Anypoint Platform から、​**\[API Manager\]**​ > ​**\[Manage API (API を管理)\]**​ > ​**\[Manage API From Exchange (Exchange から API を管理)\]**​ を選択します。 2. **\[API Name (API 参照名)\]**​ で、Exchange に保存されたアセットの名前を検索します。 API の ​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ 項目は、Exchang から自動的に入力されます。 3. **\[Managing type (管理種別)\]**​ に、​**\[Endpoint with Proxy (プロキシを使用したエンドポイント)\]**​ を選択します。 4. **\[Proxy deployment target (プロキシデプロイメント対象)\]**​ に、\[Runtime Fabric\] を選択します。 5. Mule バージョンを選択します。 6. **\[Implementation URI (実装 URI)\]**​ に、プロキシにアクセスするベース URL パスを指定します。 7. 必要に応じて、​**\[Path (パス)\]**​ を指定します。 8. インバウンドトラフィックで SSL を有効にする場合は、次の手順を実行します。 1. **\[Scheme (スキーム)\]**​ で ​**\[HTTPS\]**​ を選択します。 **\[TLS Context for Inbound Traffic (インバウンドトラフィックの TLS コンテキスト)\]**​ 項目が有効になります。 2. **\[Add TLS Context (TLS コンテキストを追加)\]**​ を選択します。 3. TLS コンテキストをホストしたシークレットグループを ​**\[Secret group (シークレットグループ)\]**​ ドロップダウンから選択します。 4. HTTPS API プロキシの TLS コンテキストを ​**\[TLS Context (TLS コンテキスト)\]**​ ドロップダウンから選択します。 9. API プロキシの​**ポート**​番号を入力します。 10. **\[Client Provider (クライアントプロバイダー)\]**​ を選択します。 11. **\[Advanced Options (詳細オプション)\]**​ をクリックします。 12. **\[Proxy Version (プロキシバージョン)\]**​ で、​**\[latest (最新)\]**​ を選択します。 この値を選択すると、API プロキシで最新リリースのプロキシバージョンが使用されます。 13. **\[TLS Context for Outbound traffic (アウトバウンドトラフィックの TLS コンテキスト)\]**​ で ​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. TLS コンテキストをホストしたシークレットグループを ​**\[Secret Group (シークレットグループ)\]**​ ドロップダウンリストから選択します。 2. HTTPS API プロキシの TLS コンテキストを ​**\[TLS コンテキスト\]**​ ドロップダウンから選択します。 14. **\[Save (保存)\]**​ をクリックします。 設定情報が保存され、API Manager に ​**\[Deployment Configuration (デプロイメント設定)\]**​ セクションが表示されます。 15. **\[Deployment Configuration (デプロイメント設定)\]**​ セクションで、次の設定を定義します。 1. **\[Runtime Fabric target (Runtime Fabric 対象)\]**​ を選択します。 2. **\[Runtime version (ランタイムバージョン)\]**​ を選択します。 3. プロキシアプリケーションの名前を入力します。 API Manager は API プロキシを Runtime Fabric にデプロイします。デプロイ中は、次の情報を示すデプロイメントの状況ダイアログが表示されます。 1. **プロキシのデプロイ**​。 2. **アプリケーションの起動**​。 3. **デプロイメント成功**​。 デプロイ後は、デプロイした API プロキシを Runtime Manager から管理できます。 ## [](#anypoint-studio-を使用して-https-プロキシを有効にする)Anypoint Studio を使用して HTTPS プロキシを有効にする Anypoint Studio を使用して HTTPS 要求をサポートするようにプロキシを有効化できます。 1. [「API プロキシのダウンロード」](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​の手順を使用して、API ゲートウェイをダウンロードし、API Manager からデプロイします。 2. [「Anypoint Studio を使用して TLS を設定する」](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls)​の手順を使用して、Anypoint Studio でゲートウェイを開き、キーストア (SSL 証明書) を挿入します。 3. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric)​の手順に従って、Runtime Manager を使用してゲートウェイをエクスポートおよびデプロイします。 4. [「How to enable last-mile security in Runtime Fabric (RTF) (Runtime Fabric (RTF) で Last Mile セキュリティを有効化する方法)」](https://help.mulesoft.com/s/article/How-to-enable-last-mile-security-in-Runtime-Fabric-RTF)​の手順を使用して、アプリケーションの Last Mile セキュリティを有効にします。 ## [](#関連リソース)関連リソース - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric) # Runtime Fabric への API プロキシのデプロイ Anypoint Runtime Fabric では、API プロキシを Mule Runtime にデプロイできます。 ## [](#始める前に)始める前に API プロキシを Mule Runtime にデプロイするには、アカウントに次の権限が必要です。 - 「Manage APIs Configuration (API 設定の管理)」権限 - 「Deploy API Proxies (API プロキシのデプロイ)」権限 API Gateway バージョン 3.8.7、3.9.1、または 4.1.2 を使用していることを確認する必要があります。 API を Mule 4 環境にデプロイしていて HTTPS 要求をサポートするためにプロキシを有効にする場合は、最初に​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 デフォルトでは、次のリソースがプロキシアプリケーションに割り当てられます。 - CPU: 0.2 vCore - メモリ: 1.024 GB リソース割り当ての設定は、Runtime Manager のアプリケーションの ​**\[Settings (設定)\]**​ ページで更新できます。 ## [](#api-プロキシをデプロイする)API プロキシをデプロイする API Manager を使用してプロキシを Runtime Fabric にデプロイします。HTTP または HTTPS 経由でのインバウンド要求とアウトバウンド要求をサポートするようにプロキシを有効化できます。 プロキシで HTTPS をサポートする必要がある場合、使用を開始する前に追加の要件について API Manager ドキュメントの​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 1. Anypoint Platform から、​**\[API Manager\]**​ > ​**\[Manage API (API を管理)\]**​ > ​**\[Manage API From Exchange (Exchange から API を管理)\]**​ を選択します。 2. **\[API Name (API 参照名)\]**​ で、Exchange に保存されたアセットの名前を検索します。 API の ​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ 項目は、Exchang から自動的に入力されます。 3. **\[Managing type (管理種別)\]**​ に、​**\[Endpoint with Proxy (プロキシを使用したエンドポイント)\]**​ を選択します。 4. **\[Proxy deployment target (プロキシデプロイメント対象)\]**​ に、\[Runtime Fabric\] を選択します。 5. Mule バージョンを選択します。 6. **\[Implementation URI (実装 URI)\]**​ に、プロキシにアクセスするベース URL パスを指定します。 7. 必要に応じて、​**\[Path (パス)\]**​ を指定します。 8. インバウンドトラフィックで SSL を有効にする場合は、次の手順を実行します。 1. **\[Scheme (スキーム)\]**​ で ​**\[HTTPS\]**​ を選択します。 **\[TLS Context for Inbound Traffic (インバウンドトラフィックの TLS コンテキスト)\]**​ 項目が有効になります。 2. **\[Add TLS Context (TLS コンテキストを追加)\]**​ を選択します。 3. TLS コンテキストをホストしたシークレットグループを ​**\[Secret group (シークレットグループ)\]**​ ドロップダウンから選択します。 4. HTTPS API プロキシの TLS コンテキストを ​**\[TLS Context (TLS コンテキスト)\]**​ ドロップダウンから選択します。 9. API プロキシの​**ポート**​番号を入力します。 10. **\[Client Provider (クライアントプロバイダー)\]**​ を選択します。 11. **\[Advanced Options (詳細オプション)\]**​ をクリックします。 12. **\[Proxy Version (プロキシバージョン)\]**​ で、​**\[latest (最新)\]**​ を選択します。 この値を選択すると、API プロキシで最新リリースのプロキシバージョンが使用されます。 13. **\[TLS Context for Outbound traffic (アウトバウンドトラフィックの TLS コンテキスト)\]**​ で ​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. TLS コンテキストをホストしたシークレットグループを ​**\[Secret Group (シークレットグループ)\]**​ ドロップダウンリストから選択します。 2. HTTPS API プロキシの TLS コンテキストを ​**\[TLS コンテキスト\]**​ ドロップダウンから選択します。 14. **\[Save (保存)\]**​ をクリックします。 設定情報が保存され、API Manager に ​**\[Deployment Configuration (デプロイメント設定)\]**​ セクションが表示されます。 15. **\[Deployment Configuration (デプロイメント設定)\]**​ セクションで、次の設定を定義します。 1. **\[Runtime Fabric target (Runtime Fabric 対象)\]**​ を選択します。 2. **\[Runtime version (ランタイムバージョン)\]**​ を選択します。 3. プロキシアプリケーションの名前を入力します。 API Manager は API プロキシを Runtime Fabric にデプロイします。デプロイ中は、次の情報を示すデプロイメントの状況ダイアログが表示されます。 1. **プロキシのデプロイ**​。 2. **アプリケーションの起動**​。 3. **デプロイメント成功**​。 デプロイ後は、デプロイした API プロキシを Runtime Manager から管理できます。 ## [](#anypoint-studio-を使用して-https-プロキシを有効にする)Anypoint Studio を使用して HTTPS プロキシを有効にする Anypoint Studio を使用して HTTPS 要求をサポートするようにプロキシを有効化できます。 1. [「API プロキシのダウンロード」](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​の手順を使用して、API ゲートウェイをダウンロードし、API Manager からデプロイします。 2. [「Anypoint Studio を使用して TLS を設定する」](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls)​の手順を使用して、Anypoint Studio でゲートウェイを開き、キーストア (SSL 証明書) を挿入します。 3. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric)​の手順に従って、Runtime Manager を使用してゲートウェイをエクスポートおよびデプロイします。 4. [「How to enable last-mile security in Runtime Fabric (RTF) (Runtime Fabric (RTF) で Last Mile セキュリティを有効化する方法)」](https://help.mulesoft.com/s/article/How-to-enable-last-mile-security-in-Runtime-Fabric-RTF)​の手順を使用して、アプリケーションの Last Mile セキュリティを有効にします。 ## [](#関連リソース)関連リソース - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric) # Runtime Fabric への API プロキシのデプロイ Anypoint Runtime Fabric では、API プロキシを Mule Runtime にデプロイできます。 ## [](#始める前に)始める前に API プロキシを Mule Runtime にデプロイするには、アカウントに次の権限が必要です。 - 「Manage APIs Configuration (API 設定の管理)」権限 - 「Deploy API Proxies (API プロキシのデプロイ)」権限 API Gateway バージョン 3.8.7、3.9.1、または 4.1.2 を使用していることを確認する必要があります。 API を Mule 4 環境にデプロイしていて HTTPS 要求をサポートするためにプロキシを有効にする場合は、最初に​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 デフォルトでは、次のリソースがプロキシアプリケーションに割り当てられます。 - CPU: 0.2 vCore - メモリ: 1.024 GB リソース割り当ての設定は、Runtime Manager のアプリケーションの ​**\[Settings (設定)\]**​ ページで更新できます。 ## [](#api-プロキシをデプロイする)API プロキシをデプロイする API Manager を使用してプロキシを Runtime Fabric にデプロイします。HTTP または HTTPS 経由でのインバウンド要求とアウトバウンド要求をサポートするようにプロキシを有効化できます。 プロキシで HTTPS をサポートする必要がある場合、使用を開始する前に追加の要件について API Manager ドキュメントの​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 1. Anypoint Platform から、​**\[API Manager\]**​ > ​**\[Manage API (API を管理)\]**​ > ​**\[Manage API From Exchange (Exchange から API を管理)\]**​ を選択します。 2. **\[API Name (API 参照名)\]**​ で、Exchange に保存されたアセットの名前を検索します。 API の ​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ 項目は、Exchang から自動的に入力されます。 3. **\[Managing type (管理種別)\]**​ に、​**\[Endpoint with Proxy (プロキシを使用したエンドポイント)\]**​ を選択します。 4. **\[Proxy deployment target (プロキシデプロイメント対象)\]**​ に、\[Runtime Fabric\] を選択します。 5. Mule バージョンを選択します。 6. **\[Implementation URI (実装 URI)\]**​ に、プロキシにアクセスするベース URL パスを指定します。 7. 必要に応じて、​**\[Path (パス)\]**​ を指定します。 8. インバウンドトラフィックで SSL を有効にする場合は、次の手順を実行します。 1. **\[Scheme (スキーム)\]**​ で ​**\[HTTPS\]**​ を選択します。 **\[TLS Context for Inbound Traffic (インバウンドトラフィックの TLS コンテキスト)\]**​ 項目が有効になります。 2. **\[Add TLS Context (TLS コンテキストを追加)\]**​ を選択します。 3. TLS コンテキストをホストしたシークレットグループを ​**\[Secret group (シークレットグループ)\]**​ ドロップダウンから選択します。 4. HTTPS API プロキシの TLS コンテキストを ​**\[TLS Context (TLS コンテキスト)\]**​ ドロップダウンから選択します。 9. API プロキシの​**ポート**​番号を入力します。 10. **\[Client Provider (クライアントプロバイダー)\]**​ を選択します。 11. **\[Advanced Options (詳細オプション)\]**​ をクリックします。 12. **\[Proxy Version (プロキシバージョン)\]**​ で、​**\[latest (最新)\]**​ を選択します。 この値を選択すると、API プロキシで最新リリースのプロキシバージョンが使用されます。 13. **\[TLS Context for Outbound traffic (アウトバウンドトラフィックの TLS コンテキスト)\]**​ で ​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. TLS コンテキストをホストしたシークレットグループを ​**\[Secret Group (シークレットグループ)\]**​ ドロップダウンリストから選択します。 2. HTTPS API プロキシの TLS コンテキストを ​**\[TLS コンテキスト\]**​ ドロップダウンから選択します。 14. **\[Save (保存)\]**​ をクリックします。 設定情報が保存され、API Manager に ​**\[Deployment Configuration (デプロイメント設定)\]**​ セクションが表示されます。 15. **\[Deployment Configuration (デプロイメント設定)\]**​ セクションで、次の設定を定義します。 1. **\[Runtime Fabric target (Runtime Fabric 対象)\]**​ を選択します。 2. **\[Runtime version (ランタイムバージョン)\]**​ を選択します。 3. プロキシアプリケーションの名前を入力します。 API Manager は API プロキシを Runtime Fabric にデプロイします。デプロイ中は、次の情報を示すデプロイメントの状況ダイアログが表示されます。 1. **プロキシのデプロイ**​。 2. **アプリケーションの起動**​。 3. **デプロイメント成功**​。 デプロイ後は、デプロイした API プロキシを Runtime Manager から管理できます。 ## [](#anypoint-studio-を使用して-https-プロキシを有効にする)Anypoint Studio を使用して HTTPS プロキシを有効にする Anypoint Studio を使用して HTTPS 要求をサポートするようにプロキシを有効化できます。 1. [「API プロキシのダウンロード」](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​の手順を使用して、API ゲートウェイをダウンロードし、API Manager からデプロイします。 2. [「Anypoint Studio を使用して TLS を設定する」](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls)​の手順を使用して、Anypoint Studio でゲートウェイを開き、キーストア (SSL 証明書) を挿入します。 3. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric)​の手順に従って、Runtime Manager を使用してゲートウェイをエクスポートおよびデプロイします。 4. [「How to enable last-mile security in Runtime Fabric (RTF) (Runtime Fabric (RTF) で Last Mile セキュリティを有効化する方法)」](https://help.mulesoft.com/s/article/How-to-enable-last-mile-security-in-Runtime-Fabric-RTF)​の手順を使用して、アプリケーションの Last Mile セキュリティを有効にします。 ## [](#関連リソース)関連リソース - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric) # Runtime Fabric への API プロキシのデプロイ Anypoint Runtime Fabric では、API プロキシを Mule Runtime にデプロイできます。 ## [](#始める前に)始める前に API プロキシを Mule Runtime にデプロイするには、アカウントに次の権限が必要です。 - 「Manage APIs Configuration (API 設定の管理)」権限 - 「Deploy API Proxies (API プロキシのデプロイ)」権限 API Gateway バージョン 3.8.7、3.9.1、または 4.1.2 を使用していることを確認する必要があります。 API を Mule 4 環境にデプロイしていて HTTPS 要求をサポートするためにプロキシを有効にする場合は、最初に​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 デフォルトでは、次のリソースがプロキシアプリケーションに割り当てられます。 - CPU: 0.2 vCore - メモリ: 1.024 GB リソース割り当ての設定は、Runtime Manager のアプリケーションの ​**\[Settings (設定)\]**​ ページで更新できます。 ## [](#api-プロキシをデプロイする)API プロキシをデプロイする API Manager を使用してプロキシを Runtime Fabric にデプロイします。HTTP または HTTPS 経由でのインバウンド要求とアウトバウンド要求をサポートするようにプロキシを有効化できます。 プロキシで HTTPS をサポートする必要がある場合、使用を開始する前に追加の要件について API Manager ドキュメントの​[「HTTPS API プロキシの構築」](https://docs.mulesoft.com/jp/api-manager/latest/building-https-proxy)​を参照してください。 1. Anypoint Platform から、​**\[API Manager\]**​ > ​**\[Manage API (API を管理)\]**​ > ​**\[Manage API From Exchange (Exchange から API を管理)\]**​ を選択します。 2. **\[API Name (API 参照名)\]**​ で、Exchange に保存されたアセットの名前を検索します。 API の ​**\[Asset type (アセットタイプ)\]**​、​**\[API version (API バージョン)\]**​、および ​**\[Asset version (アセットバージョン)\]**​ 項目は、Exchang から自動的に入力されます。 3. **\[Managing type (管理種別)\]**​ に、​**\[Endpoint with Proxy (プロキシを使用したエンドポイント)\]**​ を選択します。 4. **\[Proxy deployment target (プロキシデプロイメント対象)\]**​ に、\[Runtime Fabric\] を選択します。 5. Mule バージョンを選択します。 6. **\[Implementation URI (実装 URI)\]**​ に、プロキシにアクセスするベース URL パスを指定します。 7. 必要に応じて、​**\[Path (パス)\]**​ を指定します。 8. インバウンドトラフィックで SSL を有効にする場合は、次の手順を実行します。 1. **\[Scheme (スキーム)\]**​ で ​**\[HTTPS\]**​ を選択します。 **\[TLS Context for Inbound Traffic (インバウンドトラフィックの TLS コンテキスト)\]**​ 項目が有効になります。 2. **\[Add TLS Context (TLS コンテキストを追加)\]**​ を選択します。 3. TLS コンテキストをホストしたシークレットグループを ​**\[Secret group (シークレットグループ)\]**​ ドロップダウンから選択します。 4. HTTPS API プロキシの TLS コンテキストを ​**\[TLS Context (TLS コンテキスト)\]**​ ドロップダウンから選択します。 9. API プロキシの​**ポート**​番号を入力します。 10. **\[Client Provider (クライアントプロバイダー)\]**​ を選択します。 11. **\[Advanced Options (詳細オプション)\]**​ をクリックします。 12. **\[Proxy Version (プロキシバージョン)\]**​ で、​**\[latest (最新)\]**​ を選択します。 この値を選択すると、API プロキシで最新リリースのプロキシバージョンが使用されます。 13. **\[TLS Context for Outbound traffic (アウトバウンドトラフィックの TLS コンテキスト)\]**​ で ​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 1. TLS コンテキストをホストしたシークレットグループを ​**\[Secret Group (シークレットグループ)\]**​ ドロップダウンリストから選択します。 2. HTTPS API プロキシの TLS コンテキストを ​**\[TLS コンテキスト\]**​ ドロップダウンから選択します。 14. **\[Save (保存)\]**​ をクリックします。 設定情報が保存され、API Manager に ​**\[Deployment Configuration (デプロイメント設定)\]**​ セクションが表示されます。 15. **\[Deployment Configuration (デプロイメント設定)\]**​ セクションで、次の設定を定義します。 1. **\[Runtime Fabric target (Runtime Fabric 対象)\]**​ を選択します。 2. **\[Runtime version (ランタイムバージョン)\]**​ を選択します。 3. プロキシアプリケーションの名前を入力します。 API Manager は API プロキシを Runtime Fabric にデプロイします。デプロイ中は、次の情報を示すデプロイメントの状況ダイアログが表示されます。 1. **プロキシのデプロイ**​。 2. **アプリケーションの起動**​。 3. **デプロイメント成功**​。 デプロイ後は、デプロイした API プロキシを Runtime Manager から管理できます。 ## [](#anypoint-studio-を使用して-https-プロキシを有効にする)Anypoint Studio を使用して HTTPS プロキシを有効にする Anypoint Studio を使用して HTTPS 要求をサポートするようにプロキシを有効化できます。 1. [「API プロキシのダウンロード」](https://docs.mulesoft.com/jp/api-manager/latest/download-proxy-task)​の手順を使用して、API ゲートウェイをダウンロードし、API Manager からデプロイします。 2. [「Anypoint Studio を使用して TLS を設定する」](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#use-anypoint-studio-to-configure-tls)​の手順を使用して、Anypoint Studio でゲートウェイを開き、キーストア (SSL 証明書) を挿入します。 3. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/runtime-fabric/latest/deploy-to-runtime-fabric)​の手順に従って、Runtime Manager を使用してゲートウェイをエクスポートおよびデプロイします。 4. [「How to enable last-mile security in Runtime Fabric (RTF) (Runtime Fabric (RTF) で Last Mile セキュリティを有効化する方法)」](https://help.mulesoft.com/s/article/How-to-enable-last-mile-security-in-Runtime-Fabric-RTF)​の手順を使用して、アプリケーションの Last Mile セキュリティを有効にします。 ## [](#関連リソース)関連リソース - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) # Runtime Fabric への Mule アプリケーションのデプロイ Mule アプリケーションを Anypoint Runtime Fabric の Mule Runtime サーバーにデプロイします。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションから分離された Runtime Fabric のインスタンスにデプロイされる必要があります。 アプリケーションをデプロイしたら、デプロイされたアプリケーションのインバウンドトラフィックをテストできます。 ## [](#runtime-fabric-に-mule-アプリケーションをデプロイする)Runtime Fabric に Mule アプリケーションをデプロイする デプロイメントプロセス全体には次の手順が含まれます。 1. アプリケーションとデプロイメント対象を選択する 2. デプロイメント対象を設定する 3. アプリケーションの公開エンドポイントを設定する (自己管理型 Kubernetes の場合) (自己管理型 Kubernetes の Runtime Fabric のみ) 4. アプリケーションのネットワーク設定を指定する (VM/ベアメタルの Runtime Fabric のみ) 5. 複製をセットアップする 6. (省略可能) TLSv1 および TLSv1.1 を有効にする 7. アプリケーションプロパティを設定する 8. アプリケーションをデプロイする ### [](#前提条件)前提条件 アプリケーションを Anypoint Runtime Fabric にデプロイする前に、次のことを実行します。 - Anypoint Runtime Fabric をインストールして設定する。詳細は、​[VM/ベアメタル上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-create-rtf-arm)​ または​[自己管理型 Kubernetes 上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed)​ のインストール手順を参照してください。 - Runtime Fabric が環境に関連付けられていることを確認する。​[「ビジネスグループと環境の Anypoint Runtime Fabric への関連付け」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/associate-environments)​を参照してください。 - アプリケーションのリソース割り当て要件を決定する。詳細は、​[「Runtime Fabric でのアプリケーションリソース割り当ての決定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation)​を参照してください。 - Runtime Fabric にアプリケーションをデプロイするために「​**Exchange Contributors (Exchange コントリビューター)**​」権限が必要かどうかを確認する。 - アプリケーションを特定のドメイン (エンドポイント) にデプロイするには、環境にドメイン (エンドポイント) がセットアップされていることを確認する。​[「自己管理型 Kubernetes の Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration)​または​[「Anypoint Runtime Fabric でのインバウンドトラフィックの有効化 (VM/ベアメタル)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic)​を参照してください。 ### [](#アプリケーションとデプロイメント対象を選択する)アプリケーションとデプロイメント対象を選択する 1. [Anypoint Platform](https://anypoint.mulesoft.com)​ にサインインします。 2. **\[Runtime Manager\]**​ に移動し、​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Application Name (アプリケーション名)\]**​ 項目で、アプリケーションに名前を付けます。 名前に使用できるのは、小文字の英数字、ハイフン、およびアンダースコアのみです。 5. **\[Choose File (ファイルを選択)\]**​ をクリックしてデプロイするアプリケーションを選択し、次のいずれかのオプションを選択します。 - **Import file from Exchange (Exchange からファイルをインポート)**​: Anypoint Exchange に保存されている Mule アプリケーションを選択します。 - **Upload file (ファイルをアップロード)**​: ファイルシステムから Mule アプリケーションファイルを選択します。 6. **\[Deployment Target (デプロイメント対象)\]**​ ドロップダウンリストから、Runtime Fabric の名前を選択します。 7. **\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンリストから、Mule Runtime エンジンバージョンを選択します。 **\[Deployment Target (デプロイメント対象)\]**​ タブ、​**\[Ingress (イングレス)\]**​ タブ、​**\[Properties (プロパティ)\]**​ タブ、​**\[Logs (ログ)\]**​ タブ、​**\[JVM\]**​ タブが表示されます。これらのタブを使用して、アプリケーションの追加設定情報を入力します。 ### [](#アプリケーションの公開エンドポイントを設定する-自己管理型-kubernetes-の場合)アプリケーションの公開エンドポイントを設定する (自己管理型 Kubernetes の場合) 自己管理型 Kubernetes の Runtime Fabric にデプロイされたアプリケーションの公開エンドポイントを設定する手順は次のとおりです。 アプリケーションに使用可能なドメインおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。詳細は、​[「Use Custom Ingress Resource Templates in Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric でのカスタムイングレスリソーステンプレートの使用)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration)​を参照してください。
ドメインを選択しない場合、アプリケーションは空のドメインにデプロイされます。
1. **\[Ingress (イングレス)\]**​ を選択します。 2. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 3. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 4. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![アプリケーションのエンドポイントのホストとパスが設定されます。](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-ingress-endpoint.png) 5. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 6. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 ### [](#アプリケーションの公開エンドポイントを設定する-vmベアメタルの場合)アプリケーションの公開エンドポイントを設定する (VM/ベアメタルの場合) VM/ベアメタルの Runtime Fabric にデプロイされたアプリケーションの公開エンドポイントとネットワーク設定を定義する手順は次のとおりです。 まず​[インバウンドトラフィックを手動で有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic)​する必要があります。アプリケーションがポート 8081 で接続を受け入れるように設定されていることを確認します。
複数の FQDN を使用して Runtime Fabric インスタンスにアクセスするには、​subjectAltName​ 証明書プロパティに DNS エントリを追加します。証明書の ​subjectAltName​ プロパティに複数の DNS エントリが指定されている場合は、​[Public endpoint (公開エンドポイント)]​ セクションに利用できる URL のリストが表示されます。デプロイされた各アプリケーションのアドレスに使用できる FQDN は 1 つのみです。
1. **\[Ingress (イングレス)\]**​ を選択します。 イングレスは新規のアプリケーションデプロイメントで自動的に有効になります。 2. イングレスを有効なままにするには、​**\[Domain (ドメイン)\]**​ ドロップダウンリストから適切なドメインを選択します。 または、既存のアプリケーションのインバウンドトラフィックを有効化するには、適切なドメインを選択します。 3. 新規アプリケーションのインバウンドトラフィックを無効化するには、ドメイン選択をクリアします。 選択をクリアするには、ドメイン名を強調表示し、\[Delete (削除)\] を押します。 4. 必要に応じて次のオプションを有効または無効にします。 - **Last-Mile security (Last-Mile セキュリティ)**​: 転送された HTTPS 接続の TLS の終了と復号化がアプリケーションで行われる。このオプションでは Mule アプリケーションに SSL 証明書が含まれている必要があり、より多くの CPU リソースも必要です。 - **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 項目のコンテンツ。
### [](#複製およびストレージをセットアップする)複製およびストレージをセットアップする アプリケーションのエンドポイントを設定した後で、複製をセットアップしてデプロイするアプリケーションインスタンス数を設定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Mule アプリケーションのレプリカと再起動でデータの永続性を有効にするためにストレージに対するオブジェクトをセットアップします。 このオプションは、Mule Runtime Engine バージョン 4.2.1 以降でのみ使用できます。このオプションが使用できない場合は、IT 管理者にお問い合わせください。詳細は、​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/persistence-gateway)​を参照してください。 1. **\[Deployment Target (デプロイメント対象)\]**​ タブを選択します。 このタブには、以前に選択したデプロイメント対象の名前と種別が表示されます。 2. デプロイするアプリケーションのレプリカまたはインスタンスの数を選択します。 3. アプリケーションの各レプリカで Mule のクラスター化を有効にするには、​**\[Run in Runtime Clustering Mode (ランタイムのクラスター化モードで実行)\]**​ を有効にします。 4. 異なるノード間でレプリカのデプロイメントを適用するには、​**\[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)\]**​ を選択します。

ワーカーノードの数、または各レプリカをデプロイするために必要なワーカーノードで使用できるリソースが不十分な場合は、デプロイメントの一部のレプリカが ​[Pending (保留中)]​ 状況のままになります。異なるワーカーノードにすべてのレプリカがデプロイされると、デプロイメントの状況は ​[Running (実行中)]​ に移行します。
5. データの永続性を有効にするには、​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択します。 6. **\[Cores (コア)\]**​ の数と ​**\[Memory (メモリ)\]**​ の量を指定し、スライダーを適切な値に調整してアプリケーションの各レプリカに割り当てます。 必要に応じて、Runtime Fabric にデプロイするアプリケーションの​[リソース割り当てを決定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation)​する方法を確認してください。 ### [](#省略可能-tlsv1-および-tlsv1-1-を有効にする)(省略可能) TLSv1 および TLSv1.1 を有効にする [2021 年 8 月 3 日のパッチリリース](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021)​以降、Mule Runtime ではすべてのランタイムバージョンで TLS v1 および TLS v1.1 がデフォルトで無効になります。アプリケーションを Runtime Fabric にデプロイするときに、JVM 引数を使用して TLS v1 または TLS v1.1 を有効にできます。 1. **\[JVM\]**​ タブをクリックします。 2. **\[Java Virtual Machine arguments (Java 仮想マシン引数)\]**​ 項目で、次のいずれかの引数を追加します。 - TLSv1.0 および TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.0+` - TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.1` ### [](#アプリケーションプロパティを設定する)アプリケーションプロパティを設定する Runtime Manager を使用して、環境を指定したりパスワードとユーザー名を設定したりするなど、アプリケーションプロパティ値を設定します。 Runtime Fabric によって機密情報を公開することなくプロパティが実行時に解決されます。 1. **\[Properties (プロパティ)\]**​ タブをクリックします。 2. **\[Table view (テーブルビュー)\]**​ をクリックします。 3. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 4. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 5. 必要に応じて、プロパティを追加します。 ### [](#ログ記録とログレベルを設定する)ログ記録とログレベルを設定する Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Enable application logs (アプリケーションログを有効化)\]**​ オプションを選択します。 3. 追加のログレベルを設定するには、ドロップダウンリストを使用してログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (警告)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 4. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ### [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができました。 1. アプリケーションをデプロイするには、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ボタンが無効な場合、有効な Mule アプリケーションファイルをアップロードしていることを確認します。また、選択した Mule Runtime エンジンのバージョンがアプリケーションで使用されているバージョンと同じであることも確認します。 _結果_​: Runtime Manager にアプリケーションのデプロイメントを確認する状況メッセージが表示されます。デプロイメントが開始されると、デプロイメントの状況を参照できるアプリケーションリストページが表示されます。 新しくデプロイされたアプリケーションの場合、最初の状況は ​**\[Starting (開始中)\]**​ と表示されます。アプリケーションが成功した場合、状況は ​**\[Started (開始済み)\]**​ に更新されます。アプリケーションの状況を監視し、正常に開始されたことを確認します。 ## [](#デプロイされたアプリケーションのインバウンドトラフィックを確認する)デプロイされたアプリケーションのインバウンドトラフィックを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```none curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```none curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#継続的デプロイメントの設定)継続的デプロイメントの設定 Runtime Fabric でオンプレミスアプリケーションデプロイメントのワークフローをセットアップする方法は、​[「オンプレミス Runtime Fabric のワークフロー」](https://docs.mulesoft.com/jp/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc)​を参照してください。 ## [](#一般的な問題)一般的な問題 アプリケーションをデプロイするときに、次の問題が発生する場合があります。 - アプリケーションが数分間 ​**\[Starting (開始中)\]**​ 状況のままの場合、指定したリソース量が少なすぎることが原因の可能性があります。0.3 コア以下を選択した場合、アプリケーションの起動に数分かかることは一般的です。 - 起動時にアプリケーションでエラーが発生した場合、デプロイメントが停止し、状況は ​**\[Failed (失敗)\]**​ に更新されます。アプリケーションをクリックして右サイドバーを表示すると、エラーメッセージのプレビューが表示されます。メッセージ全体を表示するには、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 - VM/ベアメタルの Runtime Fabric を使用している場合、オペレーションセンターまたはサードパーティのログプロバイダーでアプリケーションログを表示して、詳細を確認します。 - Runtime Fabric にデプロイメントで使用可能な CPU コアまたはメモリがない場合、​`insufficient resources`​ を示すエラーメッセージが返されます。複数のレプリカを選択する場合、指定されたコアとメモリが​_各_​レプリカに適用されることを理解することが重要です。 - 既存の実行中のアプリケーションへの再デプロイメントが失敗した場合、以前のアプリケーションは実行中でアクティブなままになります。この動作により、ダウンタイムゼロのアプリケーションの再デプロイメントが可能になります。Runtime Manager では、失敗の解決に役立つ失敗したデプロイメントの詳細と状況が報告されます。 ## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation) - [CloudHub に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [ハイブリッド環境への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) # Runtime Fabric への Mule アプリケーションのデプロイ Mule アプリケーションを Anypoint Runtime Fabric の Mule Runtime サーバーにデプロイします。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションから分離された Runtime Fabric のインスタンスにデプロイされる必要があります。 アプリケーションをデプロイしたら、デプロイされたアプリケーションのインバウンドトラフィックをテストできます。 ## [](#runtime-fabric-に-mule-アプリケーションをデプロイする)Runtime Fabric に Mule アプリケーションをデプロイする デプロイメントプロセス全体には次の手順が含まれます。 1. アプリケーションとデプロイメント対象を選択する 2. デプロイメント対象を設定する 3. アプリケーションの公開エンドポイントを設定する 4. 複製をセットアップする 5. (省略可能) TLSv1 および TLSv1.1 を有効にする 6. アプリケーションプロパティを設定する 7. アプリケーションをデプロイする ### [](#前提条件)前提条件 アプリケーションを Anypoint Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric にアプリケーションをデプロイするのに必要な ​[Anypoint Platform のロールと権限](https://docs.mulesoft.com/jp/runtime-fabric/2.5/#anypoint-platform-roles-and-permissions)​を確認する。 - Runtime Fabric が環境に関連付けられていることを確認する。​[「ビジネスグループと環境の Anypoint Runtime Fabric への関連付け」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/associate-environments)​を参照してください。 - アプリケーションのリソース割り当て要件を決定する。詳細は、​[「Runtime Fabric でのアプリケーションリソース割り当ての決定」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-resource-allocation-self-managed)​を参照してください。 - アプリケーションを特定のドメイン (エンドポイント) にデプロイするには、環境にドメイン (エンドポイント) がセットアップされていることを確認する。​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​を参照してください。 - Red Hat OpenShift で Runtime Fabric を使用している場合は、​[「Prepare for Deploying Mule Apps to Red Hat OpenShift (Red Hat OpenShift に Mule アプリケーションをデプロイする準備をする)」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift)​の手順に従ってアプリケーションのデプロイメントを有効にしてください。 ### [](#アプリケーションとデプロイメント対象を選択する)アプリケーションとデプロイメント対象を選択する 1. [Anypoint Platform](https://anypoint.mulesoft.com)​ にサインインします。 2. **\[Runtime Manager\]**​ に移動し、​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Application Name (アプリケーション名)\]**​ 項目で、アプリケーションに名前を付けます。 名前に使用できるのは、小文字の英数字、ハイフン、およびアンダースコアのみです。 5. **\[Choose File (ファイルを選択)\]**​ をクリックしてデプロイするアプリケーションを選択し、次のいずれかのオプションを選択します。 - **Import file from Exchange (Exchange からファイルをインポート)**​: Anypoint Exchange に保存されている Mule アプリケーションを選択します。 - **Upload file (ファイルをアップロード)**​: ファイルシステムから Mule アプリケーションファイルを選択します。 6. **\[Deployment Target (デプロイメント対象)\]**​ ドロップダウンリストから、Runtime Fabric の名前を選択します。 7. **\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンリストから、Mule Runtime エンジンバージョンを選択します。 ![Mule Edge リリースドロップダウンウィンドウが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-rtm-mule-cadence.png) **\[Deployment Target (デプロイメント対象)\]**​ タブ、​**\[Ingress (イングレス)\]**​ タブ、​**\[Properties (プロパティ)\]**​ タブ、​**\[Logs (ログ)\]**​ タブ、​**\[JVM\]**​ タブが表示されます。これらのタブを使用して、アプリケーションの追加設定情報を入力します。 Runtime Fabric でサポートされる Mule Runtime バージョンについての詳細は、​[「Anypoint Runtime Fabric Patch Update Release Notes (Anypoint Runtime Fabric パッチ更新リリースノート)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 Mule アプリケーションは、標準サポートまたは延長サポート期間中の Mule Runtime Engine バージョンでデプロイできます。API または Runtime Manager UI でバージョンを指定します。EOL (サポート終了) 状態の Mule Runtime Engine バージョンでは、Mule アプリケーションを再デプロイして再起動することはできますが、新しい Mule アプリケーションをデプロイすることはできません。 ### [](#アプリケーションの公開エンドポイントを設定する)アプリケーションの公開エンドポイントを設定する Runtime Fabric にデプロイされたアプリケーションの公開エンドポイントを設定する手順は次のとおりです。 アプリケーションに使用可能なドメインおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。詳細は、​[「Use Custom Ingress Resource Templates in Runtime Fabric (Runtime Fabric でのカスタムイングレスリソーステンプレートの使用)」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​を参照してください。
ドメインを選択しない場合、アプリケーションは空のドメインにデプロイされます。
1. **\[Ingress (イングレス)\]**​ を選択します。 2. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 3. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 4. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![アプリケーションのエンドポイントのホストとパスが設定されます。](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-ingress-endpoint.png) 5. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 6. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 ### [](#複製およびストレージをセットアップする)複製およびストレージをセットアップする アプリケーションのエンドポイントを設定した後で、複製をセットアップしてデプロイするアプリケーションインスタンス数を設定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Mule アプリケーションのレプリカと再起動でデータの永続性を有効にするためにストレージに対するオブジェクトをセットアップします。 このオプションは、Mule Runtime Engine バージョン 4.2.1 以降でのみ使用できます。このオプションが使用できない場合は、IT 管理者にお問い合わせください。詳細は、​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/persistence-gateway)​を参照してください。 1. **\[Deployment Target (デプロイメント対象)\]**​ タブを選択します。 このタブには、以前に選択したデプロイメント対象の名前と種別が表示されます。 2. デプロイするアプリケーションのレプリカまたはインスタンスの数を選択します。 3. アプリケーションの各レプリカで Mule のクラスター化を有効にするには、​**\[Run in Runtime Clustering Mode (ランタイムのクラスター化モードで実行)\]**​ を有効にします。 4. 異なるノード間でレプリカのデプロイメントを適用するには、​**\[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)\]**​ を選択します。

ワーカーノードの数、または各レプリカをデプロイするために必要なワーカーノードで使用できるリソースが不十分な場合は、デプロイメントの一部のレプリカが ​[Pending (保留中)]​ 状況のままになります。異なるワーカーノードにすべてのレプリカがデプロイされると、デプロイメントの状況は ​[Running (実行中)]​ に移行します。
5. データの永続性を有効にするには、​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択します。 6. **\[Cores (コア)\]**​ の数と ​**\[Memory (メモリ)\]**​ の量を指定し、スライダーを適切な値に調整してアプリケーションの各レプリカに割り当てます。 必要に応じて、Runtime Fabric にデプロイするアプリケーションの​[リソース割り当てを決定](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-resource-allocation-self-managed)​する方法を確認してください。 ### [](#省略可能-tlsv1-および-tlsv1-1-を有効にする)(省略可能) TLSv1 および TLSv1.1 を有効にする [2021 年 8 月 3 日のパッチリリース](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021)​以降、Mule Runtime ではすべてのランタイムバージョンで TLS v1 および TLS v1.1 がデフォルトで無効になります。アプリケーションを Runtime Fabric にデプロイするときに、JVM 引数を使用して TLS v1 または TLS v1.1 を有効にできます。 1. **\[JVM\]**​ タブをクリックします。 2. **\[Java Virtual Machine arguments (Java 仮想マシン引数)\]**​ 項目で、次のいずれかの引数を追加します。 - TLSv1.0 および TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.0+` - TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.1` ### [](#アプリケーションプロパティを設定する)アプリケーションプロパティを設定する

アプリケーションのプロパティ値を保護する手順については、​「Runtime Fabric でのアプリケーションのプロパティ値の保護」​を参照してください。
Runtime Manager を使用して、環境を指定したりパスワードとユーザー名を設定したりするなど、アプリケーションプロパティ値を設定します。 Runtime Fabric によって機密情報を公開することなくプロパティが実行時に解決されます。 1. **\[Properties (プロパティ)\]**​ タブをクリックします。 2. **\[Table view (テーブルビュー)\]**​ をクリックします。 3. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 4. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 5. 必要に応じて、プロパティを追加します。 ### [](#ログ記録とログレベルを設定する)ログ記録とログレベルを設定する Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションのログデータへのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Enable application logs (アプリケーションログを有効化)\]**​ オプションを選択します。 3. ドロップダウンリストからログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (重要)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 4. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ### [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができました。 1. アプリケーションをデプロイするには、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ボタンが無効な場合、有効な Mule アプリケーションファイルをアップロードしていることを確認します。また、選択した Mule Runtime エンジンのバージョンがアプリケーションで使用されているバージョンと同じであることも確認します。 _結果_​: Runtime Manager にアプリケーションのデプロイメントを確認する状況メッセージが表示されます。デプロイメントが開始されると、デプロイメントの状況を参照できるアプリケーションリストページが表示されます。 新しくデプロイされたアプリケーションの場合、最初の状況は ​**\[Starting (開始中)\]**​ と表示されます。アプリケーションが成功した場合、状況は ​**\[Started (開始済み)\]**​ に更新されます。アプリケーションの状況を監視し、正常に開始されたことを確認します。 ## [](#デプロイされたアプリケーションのインバウンドトラフィックを確認する)デプロイされたアプリケーションのインバウンドトラフィックを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```copy curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#継続的デプロイメントの設定)継続的デプロイメントの設定 Runtime Fabric でオンプレミスアプリケーションデプロイメントのワークフローをセットアップする方法は、​[「オンプレミス Runtime Fabric のワークフロー」](https://docs.mulesoft.com/jp/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc)​を参照してください。 ## [](#一般的な問題)一般的な問題 アプリケーションをデプロイするときに、次の問題が発生する場合があります。 - アプリケーションが数分間 ​**\[Starting (開始中)\]**​ 状況のままの場合、指定したリソース量が少なすぎることが原因の可能性があります。0.3 コア以下を選択した場合、アプリケーションの起動に数分かかることは一般的です。 - 起動時にアプリケーションでエラーが発生した場合、デプロイメントが停止し、状況は ​**\[Failed (失敗)\]**​ に更新されます。アプリケーションをクリックして右サイドバーを表示すると、エラーメッセージのプレビューが表示されます。メッセージ全体を表示するには、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 - Runtime Fabric にデプロイメントで使用可能な CPU コアまたはメモリがない場合、​`insufficient resources`​ を示すエラーメッセージが返されます。複数のレプリカを選択する場合、指定されたコアとメモリが​_各_​レプリカに適用されることを理解することが重要です。 - 既存の実行中のアプリケーションへの再デプロイメントが失敗した場合、以前のアプリケーションは実行中でアクティブなままになります。この動作により、ダウンタイムゼロのアプリケーションの再デプロイメントが可能になります。Runtime Manager では、失敗の解決に役立つ失敗したデプロイメントの詳細と状況が報告されます。 ## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-resource-allocation-self-managed) - [CloudHub に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [ハイブリッド環境への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) # Runtime Fabric への Mule アプリケーションのデプロイ Anypoint Runtime Fabric では、Runtime Fabric で管理された Mule Runtime Engine に Mule アプリケーションと API プロキシをデプロイできます。 ## [](#サポート対象の-mule-runtime-サーバーバージョン)サポート対象の Mule Runtime サーバーバージョン サポート対象の Mule Runtime サーバーのバージョンについては、​[「Anypoint Runtime Fabric ランタイムリリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#mule-アプリケーションのデプロイを開始する前に)Mule アプリケーションのデプロイを開始する前に Mule アプリケーションまたは API プロキシを Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric をインストールして設定する。 - [「アプリケーションデプロイのリソース割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-resource-allocation-self-managed)​で説明されているリソースが割り当てられる方法を理解する。 - Mule アプリケーションまたは API プロキシを Exchange にパブリッシュする。
Mule アプリケーションと API プロキシを Runtime Fabric にデプロイする前に、それらを Exchange にパブリッシュする必要があります。Mule アプリケーションと API プロキシを Runtime Manager からデプロイすると、それらは自動的に Exchange にパブリッシュされます。
## [](#デプロイメントオプション)デプロイメントオプション 次のいずれかのオプションを使用して、Mule アプリケーションを Runtime Fabric にデプロイします。 - [Runtime Manager を使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric) Runtime Manager を使用して、Mule アプリケーションと API プロキシを手動でデプロイします。 - [Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 4)](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-maven-4.x) - [Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 3.x)](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-maven-3.x) Maven を使用して Mule アプリケーションまたは API プロキシの管理とデプロイを行います。 - [CLI を使用した Runtime Fabric でのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-rtf-cli) Anypoint Platform CLI を使用した Mule アプリケーションのデプロイ ## [](#デプロイメントの考慮事項)デプロイメントの考慮事項 ### [](#最終的な一貫性)最終的な一貫性 Runtime Fabric は、最終的に一貫性が確保される自己修復プラットフォームです。Runtime Fabric デプロイメントの CI パイプラインを構築する場合、最終的な一貫性を考慮する必要があります。デプロイメントをトリガーすると、アプリケーションの状況が ​`RUNNING`​ になります。アプリケーションの状況が ​`RUNNING`​ にならない場合、アプリケーションが ​`RUNNING`​ にならない理由を示す ​`state`​ および ​`reason`​ がレプリカに含まれます。 ### [](#アプリケーションデプロイメント)アプリケーションデプロイメント アプリケーションがデプロイされると、次のイベントが発生します。 - アプリケーションの想定される状態 (アプリケーションバンドルやレプリカの数など) が保存される。 - アプリケーションレプリカの状況が ​`PENDING`​ として表示される。 - 十分な計算リソースとメモリリソースを使用できる場合、各レプリカがノードに接続される。 - Mule Runtime バージョンに対応する Docker イメージがダウンロードされる (まだ存在していない場合)。 - レプリカの状況が ​`STARTING`​ として表示される。 - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 ### [](#アプリケーションの失敗)アプリケーションの失敗 メモリ不足などが原因でアプリケーションが失敗すると、次のイベントが発生します。 - レプリカの状況が ​`TERMINATED`​ として表示される。 - Runtime Fabric がすぐにレプリカを再起動しようとする。 - レプリカの状況が ​`RECOVERING`​ として表示される。 - レプリカを再起動できる場合: - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 - 最初にレプリカを再起動できない場合 (一時的に使用できなくなっているネットワークリソースをレプリカが利用している場合など)、次のイベントが発生します。 - 「CrashLoopBackoff」を示すメッセージと共に、レプリカの状況が ​`PENDING`​ として表示される。Runtime Fabric は、過剰な数の再起動が試行されないようにエクスポネンシャルバックオフを使用してレプリカを再起動しようとします。 - 正常な再起動が妨げている問題が解決するまで、レプリカが ​`RECOVERING`​ と ​`PENDING`​ の状況を繰り返す。 - レプリカがアプリケーションを読み込む。 - 正常に再起動すると、レプリカが ​`STARTED`​ として表示され、作業を実行できるようになる。 ## [](#関連情報)関連情報 - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.6/managing-apps-deployed-runtime-fabric) - [Runtime Fabric にデプロイされた Mule アプリケーションの強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-apps-deployed-runtime-fabric) # Runtime Fabric への Mule アプリケーションのデプロイ Anypoint Runtime Fabric では、Runtime Fabric で管理された Mule Runtime Engine に Mule アプリケーションと API プロキシをデプロイできます。 ## [](#サポート対象の-mule-runtime-サーバーバージョン)サポート対象の Mule Runtime サーバーバージョン サポート対象の Mule Runtime サーバーのバージョンについては、​[「Anypoint Runtime Fabric ランタイムリリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#mule-アプリケーションのデプロイを開始する前に)Mule アプリケーションのデプロイを開始する前に Mule アプリケーションまたは API プロキシを Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric をインストールして設定する。 - [「アプリケーションデプロイのリソース割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-resource-allocation-self-managed)​で説明されているリソースが割り当てられる方法を理解する。 - Mule アプリケーションまたは API プロキシを Exchange にパブリッシュする。
Mule アプリケーションと API プロキシを Runtime Fabric にデプロイする前に、それらを Exchange にパブリッシュする必要があります。Mule アプリケーションと API プロキシを Runtime Manager からデプロイすると、それらは自動的に Exchange にパブリッシュされます。
## [](#デプロイメントオプション)デプロイメントオプション 次のいずれかのオプションを使用して、Mule アプリケーションを Runtime Fabric にデプロイします。 - [Runtime Manager を使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric) Runtime Manager を使用して、Mule アプリケーションと API プロキシを手動でデプロイします。 - [Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 4)](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-maven-4.x) - [Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 3.x)](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-maven-3.x) Maven を使用して Mule アプリケーションまたは API プロキシの管理とデプロイを行います。 - [CLI を使用した Runtime Fabric でのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-rtf-cli) Anypoint Platform CLI を使用した Mule アプリケーションのデプロイ ## [](#デプロイメントの考慮事項)デプロイメントの考慮事項 ### [](#最終的な一貫性)最終的な一貫性 Runtime Fabric は、最終的に一貫性が確保される自己修復プラットフォームです。Runtime Fabric デプロイメントの CI パイプラインを構築する場合、最終的な一貫性を考慮する必要があります。デプロイメントをトリガーすると、アプリケーションの状況が ​`RUNNING`​ になります。アプリケーションの状況が ​`RUNNING`​ にならない場合、アプリケーションが ​`RUNNING`​ にならない理由を示す ​`state`​ および ​`reason`​ がレプリカに含まれます。 ### [](#アプリケーションデプロイメント)アプリケーションデプロイメント アプリケーションがデプロイされると、次のイベントが発生します。 - アプリケーションの想定される状態 (アプリケーションバンドルやレプリカの数など) が保存される。 - アプリケーションレプリカの状況が ​`PENDING`​ として表示される。 - 十分な計算リソースとメモリリソースを使用できる場合、各レプリカがノードに接続される。 - Mule Runtime バージョンに対応する Docker イメージがダウンロードされる (まだ存在していない場合)。 - レプリカの状況が ​`STARTING`​ として表示される。 - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 ### [](#アプリケーションの失敗)アプリケーションの失敗 メモリ不足などが原因でアプリケーションが失敗すると、次のイベントが発生します。 - レプリカの状況が ​`TERMINATED`​ として表示される。 - Runtime Fabric がすぐにレプリカを再起動しようとする。 - レプリカの状況が ​`RECOVERING`​ として表示される。 - レプリカを再起動できる場合: - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 - 最初にレプリカを再起動できない場合 (一時的に使用できなくなっているネットワークリソースをレプリカが利用している場合など)、次のイベントが発生します。 - 「CrashLoopBackoff」を示すメッセージと共に、レプリカの状況が ​`PENDING`​ として表示される。Runtime Fabric は、過剰な数の再起動が試行されないようにエクスポネンシャルバックオフを使用してレプリカを再起動しようとします。 - 正常な再起動が妨げている問題が解決するまで、レプリカが ​`RECOVERING`​ と ​`PENDING`​ の状況を繰り返す。 - レプリカがアプリケーションを読み込む。 - 正常に再起動すると、レプリカが ​`STARTED`​ として表示され、作業を実行できるようになる。 ## [](#関連情報)関連情報 - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.7/managing-apps-deployed-runtime-fabric) - [Runtime Fabric にデプロイされた Mule アプリケーションの強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-apps-deployed-runtime-fabric) # Runtime Fabric への Mule アプリケーションのデプロイ Anypoint Runtime Fabric では、Runtime Fabric で管理された Mule Runtime Engine に Mule アプリケーションと API プロキシをデプロイできます。 ## [](#サポート対象の-mule-runtime-サーバーバージョン)サポート対象の Mule Runtime サーバーバージョン サポート対象の Mule Runtime サーバーのバージョンについては、​[「Anypoint Runtime Fabric ランタイムリリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#mule-アプリケーションのデプロイを開始する前に)Mule アプリケーションのデプロイを開始する前に Mule アプリケーションまたは API プロキシを Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric をインストールして設定する。 - [「アプリケーションデプロイのリソース割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-resource-allocation-self-managed)​で説明されているリソースが割り当てられる方法を理解する。 - Mule アプリケーションまたは API プロキシを Exchange にパブリッシュする。
Mule アプリケーションと API プロキシを Runtime Fabric にデプロイする前に、それらを Exchange にパブリッシュする必要があります。Mule アプリケーションと API プロキシを Runtime Manager からデプロイすると、それらは自動的に Exchange にパブリッシュされます。
## [](#デプロイメントオプション)デプロイメントオプション 次のいずれかのオプションを使用して、Mule アプリケーションを Runtime Fabric にデプロイします。 - [Runtime Manager を使用した Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) Runtime Manager を使用して、Mule アプリケーションと API プロキシを手動でデプロイします。 - [Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 4)](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-maven-4.x) - [Maven を使用した Runtime Fabric への Mule アプリケーションのデプロイ (Mule 3.x)](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-maven-3.x) Maven を使用して Mule アプリケーションまたは API プロキシの管理とデプロイを行います。 - [CLI を使用した Runtime Fabric でのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-rtf-cli) Anypoint Platform CLI を使用した Mule アプリケーションのデプロイ ## [](#デプロイメントの考慮事項)デプロイメントの考慮事項 ### [](#最終的な一貫性)最終的な一貫性 Runtime Fabric は、最終的に一貫性が確保される自己修復プラットフォームです。Runtime Fabric デプロイメントの CI パイプラインを構築する場合、最終的な一貫性を考慮する必要があります。デプロイメントをトリガーすると、アプリケーションの状況が ​`RUNNING`​ になります。アプリケーションの状況が ​`RUNNING`​ にならない場合、アプリケーションが ​`RUNNING`​ にならない理由を示す ​`state`​ および ​`reason`​ がレプリカに含まれます。 ### [](#アプリケーションデプロイメント)アプリケーションデプロイメント アプリケーションがデプロイされると、次のイベントが発生します。 - アプリケーションの想定される状態 (アプリケーションバンドルやレプリカの数など) が保存される。 - アプリケーションレプリカの状況が ​`PENDING`​ として表示される。 - 十分な計算リソースとメモリリソースを使用できる場合、各レプリカがノードに接続される。 - Mule Runtime バージョンに対応する Docker イメージがダウンロードされる (まだ存在していない場合)。 - レプリカの状況が ​`STARTING`​ として表示される。 - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 ### [](#アプリケーションの失敗)アプリケーションの失敗 メモリ不足などが原因でアプリケーションが失敗すると、次のイベントが発生します。 - レプリカの状況が ​`TERMINATED`​ として表示される。 - Runtime Fabric がすぐにレプリカを再起動しようとする。 - レプリカの状況が ​`RECOVERING`​ として表示される。 - レプリカを再起動できる場合: - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 - 最初にレプリカを再起動できない場合 (一時的に使用できなくなっているネットワークリソースをレプリカが利用している場合など)、次のイベントが発生します。 - 「CrashLoopBackoff」を示すメッセージと共に、レプリカの状況が ​`PENDING`​ として表示される。Runtime Fabric は、過剰な数の再起動が試行されないようにエクスポネンシャルバックオフを使用してレプリカを再起動しようとします。 - 正常な再起動が妨げている問題が解決するまで、レプリカが ​`RECOVERING`​ と ​`PENDING`​ の状況を繰り返す。 - レプリカがアプリケーションを読み込む。 - 正常に再起動すると、レプリカが ​`STARTED`​ として表示され、作業を実行できるようになる。 ## [](#関連情報)関連情報 - [Runtime Fabric にデプロイされた Mule アプリケーションの管理](https://docs.mulesoft.com/jp/runtime-fabric/2.8/managing-apps-deployed-runtime-fabric) - [Runtime Fabric にデプロイされた Mule アプリケーションの強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-apps-deployed-runtime-fabric) # Runtime Fabric への Mule アプリケーションのデプロイと管理 Anypoint Runtime Fabric では、Runtime Fabric で管理された Mule Runtime Engine に Mule アプリケーションと API プロキシをデプロイできます。 ## [](#サポート対象の-mule-runtime-サーバーバージョン)サポート対象の Mule Runtime サーバーバージョン サポート対象の Mule Runtime サーバーのバージョンについては、​[「Anypoint Runtime Fabric ランタイムリリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#前提条件)前提条件 Mule アプリケーションまたは API プロキシを Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric をインストールして設定する。 - [「Anypoint Runtime Fabric でのリソース割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-resource-allocation-self-managed)​で説明されているリソースが割り当てられる方法を理解する。 - Mule アプリケーションまたは API プロキシを Exchange にパブリッシュする。
Mule アプリケーションと API プロキシを Runtime Fabric にデプロイする前に、それらを Exchange にパブリッシュする必要があります。Mule アプリケーションと API プロキシを Runtime Manager からデプロイすると、それらは自動的に Exchange にパブリッシュされます。
## [](#runtime-manager-を使用したデプロイ)Runtime Manager を使用したデプロイ Runtime Manager を使用して、Mule アプリケーションと API プロキシを手動でデプロイできます。​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-runtime-fabric)​を参照してください。 Anypoint Platform CLI を使用して Mule アプリケーションをデプロイすることもできます。​[「CLI を使用した Runtime Fabric でのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-to-rtf-cli)​を参照してください。 ## [](#maven-を使用したデプロイ)Maven を使用したデプロイ Runtime Fabric は、Maven による Mule アプリケーションまたは API プロキシの管理およびデプロイをサポートしています。 Maven を使用して Mule アプリケーションと API プロキシをデプロイするには、Mule バージョンに固有のトピックを参照してください。 - [Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-maven-4.x) - [Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3.x)](https://docs.mulesoft.com/jp/runtime-fabric/2.5/deploy-maven-3.x) ## [](#デプロイメントの考慮事項)デプロイメントの考慮事項 ### [](#最終的な一貫性)最終的な一貫性 Runtime Fabric は、最終的に一貫性が確保される自己修復プラットフォームです。Runtime Fabric デプロイメントの CI パイプラインを構築する場合、最終的な一貫性を考慮する必要があります。デプロイメントをトリガーすると、アプリケーションの状況が ​`RUNNING`​ になります。アプリケーションの状況が ​`RUNNING`​ にならない場合、アプリケーションが ​`RUNNING`​ にならない理由を示す ​`state`​ および ​`reason`​ がレプリカに含まれます。 ### [](#アプリケーションのデプロイメント)アプリケーションのデプロイメント アプリケーションがデプロイされると、次のイベントが発生します。 - アプリケーションの想定される状態 (アプリケーションバンドルやレプリカの数など) が保存される。 - アプリケーションレプリカの状況が ​`PENDING`​ として表示される。 - 十分な計算リソースとメモリリソースを使用できる場合、各レプリカがノードに接続される。 - Mule Runtime バージョンに対応する Docker イメージがダウンロードされる (まだ存在していない場合)。 - レプリカの状況が ​`STARTING`​ として表示される。 - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 ### [](#アプリケーションの失敗)アプリケーションの失敗 メモリ不足などが原因でアプリケーションが失敗すると、次のイベントが発生します。 - レプリカの状況が ​`TERMINATED`​ として表示される。 - Runtime Fabric がすぐにレプリカを再起動しようとする。 - レプリカの状況が ​`RECOVERING`​ として表示される。 - レプリカを再起動できる場合: - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 - 最初にレプリカを再起動できない場合 (一時的に使用できなくなっているネットワークリソースをレプリカが利用している場合など)、次のイベントが発生します。 - 「CrashLoopBackoff」を示すメッセージと共に、レプリカの状況が ​`PENDING`​ として表示される。Runtime Fabric は、過剰な数の再起動が試行されないようにエクスポネンシャルバックオフを使用してレプリカを再起動しようとします。 - 正常な再起動が妨げている問題が解決するまで、レプリカが ​`RECOVERING`​ と ​`PENDING`​ の状況を繰り返す。 - レプリカがアプリケーションを読み込む。 - 正常に再起動すると、レプリカが ​`STARTED`​ として表示され、作業を実行できるようになる。 # Runtime Fabric への RTFCTL の使用 `rtfctl`​ コマンドラインツールのセットアップ後、​`rtfctl`​ コマンドを使用して Runtime Fabric のインストール、設定、アップグレード、アンインストール、トラブルシューティング、バックアップ、復元を行います。また、Mule ライセンスキーを置き換えることもできます。 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-self-managed) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#configure-rtfctl) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/uninstall-self#unistall-rtfctl-rtf) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.6/upgrade-self-managed) - [Runtime Fabric のバックアップと復元](https://docs.mulesoft.com/jp/runtime-fabric/2.6/manage-backup-restore) - [Runtime Fabric のトラブルシューティング](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl#troubleshooting-rtfctl) - [Mule ライセンスキーの置き換え](https://docs.mulesoft.com/jp/runtime-fabric/2.6/replace-license-key) ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.6/using-rtfctl-mule-apps) # Runtime Fabric への RTFCTL の使用 `rtfctl`​ コマンドラインツールのセットアップ後、​`rtfctl`​ コマンドを使用して Runtime Fabric のインストール、設定、アップグレード、アンインストール、トラブルシューティング、バックアップ、復元を行います。また、Mule ライセンスキーを置き換えることもできます。 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-self-managed) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#configure-rtfctl) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/uninstall-self#unistall-rtfctl-rtf) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.7/upgrade-self-managed) - [Runtime Fabric のバックアップと復元](https://docs.mulesoft.com/jp/runtime-fabric/2.7/manage-backup-restore) - [Runtime Fabric のトラブルシューティング](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl#troubleshooting-rtfctl) - [Mule ライセンスキーの置き換え](https://docs.mulesoft.com/jp/runtime-fabric/2.7/replace-license-key) ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.7/using-rtfctl-mule-apps) # Runtime Fabric への RTFCTL の使用 `rtfctl`​ コマンドラインツールのセットアップ後、​`rtfctl`​ コマンドを使用して Runtime Fabric のインストール、設定、アップグレード、アンインストール、トラブルシューティング、バックアップ、復元を行います。また、Mule ライセンスキーを置き換えることもできます。 - [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-self-managed) - [Runtime Fabric の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#configure-rtfctl) - [Runtime Fabric のアンインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/uninstall-self#unistall-rtfctl-rtf) - [Runtime Fabric のアップグレード](https://docs.mulesoft.com/jp/runtime-fabric/2.8/upgrade-self-managed) - [Runtime Fabric のバックアップと復元](https://docs.mulesoft.com/jp/runtime-fabric/2.8/manage-backup-restore) - [Runtime Fabric のトラブルシューティング](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl#troubleshooting-rtfctl) - [Mule ライセンスキーの置き換え](https://docs.mulesoft.com/jp/runtime-fabric/2.8/replace-license-key) ## [](#関連情報)関連情報 - [RTFCTL リファレンス](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl) - [デプロイ済み Mule アプリケーションへの RTFCTL の使用](https://docs.mulesoft.com/jp/runtime-fabric/2.8/using-rtfctl-mule-apps) # Runtime Fabric へのアプリケーションおよび API プロキシのデプロイ Anypoint Runtime Fabric では、Runtime Fabric で管理された Mule Runtime Engine に Mule アプリケーションと API プロキシをデプロイできます。 ## [](#サポート対象の-mule-runtime-サーバーバージョン)サポート対象の Mule Runtime サーバーバージョン サポート対象の Mule Runtime サーバーのバージョンについては、​[「Anypoint Runtime Fabric ランタイムリリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#前提条件)前提条件 Mule アプリケーションまたは API プロキシを Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric をインストールして設定する。 - [「Anypoint Runtime Fabric でのリソース割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation)​で説明されているリソースが割り当てられる方法を理解する。 - Mule アプリケーションまたは API プロキシを Exchange にパブリッシュする。
Mule アプリケーションと API プロキシを Runtime Fabric にデプロイする前に、それらを Exchange にパブリッシュする必要があります。Mule アプリケーションと API プロキシを Runtime Manager からデプロイすると、それらは自動的に Exchange にパブリッシュされます。
## [](#runtime-manager-を使用したデプロイ)Runtime Manager を使用したデプロイ Runtime Manager を使用して、Mule アプリケーションと API プロキシを手動でデプロイできます。​[「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric)​を参照してください。 Anypoint Platform CLI を使用して Mule アプリケーションをデプロイすることもできます。​[「CLI を使用した Runtime Fabric でのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-rtf-cli)​を参照してください。 ## [](#maven-を使用したデプロイ)Maven を使用したデプロイ Runtime Fabric は、Maven による Mule アプリケーションまたは API プロキシの管理およびデプロイをサポートしています。 Maven を使用して Mule アプリケーションと API プロキシをデプロイするには、Mule バージョンに固有のトピックを参照してください。 - [Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 4)](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-maven-4.x) - [Maven を使用した Runtime Fabric へのアプリケーションのデプロイ (Mule 3.x)](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-maven-3.x) ## [](#デプロイメントの考慮事項)デプロイメントの考慮事項 ### [](#最終的な一貫性)最終的な一貫性 Runtime Fabric は、最終的に一貫性が確保される自己修復プラットフォームです。Runtime Fabric デプロイメントの CI パイプラインを構築する場合、最終的な一貫性を考慮する必要があります。デプロイメントをトリガーすると、アプリケーションの状況が ​`RUNNING`​ になります。アプリケーションの状況が ​`RUNNING`​ にならない場合、アプリケーションが ​`RUNNING`​ にならない理由を示す ​`state`​ および ​`reason`​ がレプリカに含まれます。 ### [](#アプリケーションデプロイメント)アプリケーションデプロイメント アプリケーションがデプロイされると、次のイベントが発生します。 - アプリケーションの想定される状態 (アプリケーションバンドルやレプリカの数など) が保存される。 - アプリケーションレプリカの状況が ​`PENDING`​ として表示される。 - 十分な計算リソースとメモリリソースを使用できる場合、各レプリカがノードに接続される。 - Mule Runtime バージョンに対応する Docker イメージがダウンロードされる (まだ存在していない場合)。 - レプリカの状況が ​`STARTING`​ として表示される。 - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 ### [](#アプリケーションの失敗)アプリケーションの失敗 メモリ不足などが原因でアプリケーションが失敗すると、次のイベントが発生します。 - レプリカの状況が ​`TERMINATED`​ として表示される。 - Runtime Fabric がすぐにレプリカを再起動しようとする。 - レプリカの状況が ​`RECOVERING`​ として表示される。 - レプリカを再起動できる場合: - レプリカがアプリケーションの読み込みを完了する。 - レプリカの状況が ​`STARTED`​ として表示され、作業を実行できるようになる。 - 最初にレプリカを再起動できない場合 (一時的に使用できなくなっているネットワークリソースをレプリカが利用している場合など)、次のイベントが発生します。 - 「CrashLoopBackoff」を示すメッセージと共に、レプリカの状況が ​`PENDING`​ として表示される。Runtime Fabric は、過剰な数の再起動が試行されないようにエクスポネンシャルバックオフを使用してレプリカを再起動しようとします。 - 正常な再起動が妨げている問題が解決するまで、レプリカが ​`RECOVERING`​ と ​`PENDING`​ の状況を繰り返す。 - レプリカがアプリケーションを読み込む。 - 正常に再起動すると、レプリカが ​`STARTED`​ として表示され、作業を実行できるようになる。 # Runtime Fabric へのアプリケーションデプロイメント用のリソースの割り当て Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。 Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。 次のパフォーマンス情報は、カスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを使用するコントローラーノードのクラスターに基づきます。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。負荷ジェネレーターは、同じリージョンの別のクラスターでホストされます。 アプリケーションのデプロイ時に次のリソースを割り当てることができます。 - vCPU コア - `Reserved vCPU` アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。 - `vCPU Limit` アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。 - Memory (メモリ) Runtime Fabric インスタンスにデプロイするアプリケーションの ​[Mulesoft ライセンス要件](https://docs.mulesoft.com/jp/runtime-fabric/2.6/limitations-self#license-compliance)​を確認します。 ## [](#vcpu-の割り当て)vCPU の割り当て \[​`Reserved vCPU`​ (予約済み vCPU)\] と \[​`vCPU Limit`​ (vCPU 制限)\] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。 CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。 \[​`vCPU Limit`​ (vCPU 制限)\] の値が \[​`Reserved vCPU`​ (予約済み vCPU)\] の値よりも高く設定されていると、アプリケーションは、\[vCPU limit (vCPU 制限)\] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。 ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。 ## [](#cpu-バースト)CPU バースト CPU バーストを使用するときは、次の要素を考慮する必要があります。 - 最小予約済み vCPU: 0.02 vCPU。 - vCPU の下限: 0.07 vCPU。 大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。 - CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。 - 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。 - Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。 - 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 150Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。 - 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。 - アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。 どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。 ## [](#メモリの割り当て)メモリの割り当て Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。 - 0.7 GB メモリ (Mule 4) - 0.5 GB メモリ (Mule 3) Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。 ## [](#cloudhub-および-runtime-fabric-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。Anypoint Platform は、デプロイされたアプリケーションへのネイティブメモリの割り当てを JVM を介して、Java メモリ管理の標準プラクティスを考慮して実行します。 CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。 - Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。 使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。 - CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。 ## [](#アプリケーションの起動時間)アプリケーションの起動時間 Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。
vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分
## [](#アプリケーションのパフォーマンス)アプリケーションのパフォーマンス Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。
vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。
## [](#キーと証明書の-cpu-要件)キーと証明書の CPU 要件 最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。
コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8
## [](#キー種別)キー種別 RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。 - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (prime256v1 (P-256) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.6/view-health) # Runtime Fabric へのアプリケーションデプロイメント用のリソースの割り当て Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。 Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。 次のパフォーマンス情報は、カスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを使用するコントローラーノードのクラスターに基づきます。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。負荷ジェネレーターは、同じリージョンの別のクラスターでホストされます。 アプリケーションのデプロイ時に次のリソースを割り当てることができます。 - vCPU コア - `Reserved vCPU` アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。 - `vCPU Limit` アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。 - Memory (メモリ) Runtime Fabric インスタンスにデプロイするアプリケーションの ​[Mulesoft ライセンス要件](https://docs.mulesoft.com/jp/runtime-fabric/2.7/limitations-self#license-compliance)​を確認します。 ## [](#vcpu-の割り当て)vCPU の割り当て \[​`Reserved vCPU`​ (予約済み vCPU)\] と \[​`vCPU Limit`​ (vCPU 制限)\] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。 CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。 \[​`vCPU Limit`​ (vCPU 制限)\] の値が \[​`Reserved vCPU`​ (予約済み vCPU)\] の値よりも高く設定されていると、アプリケーションは、\[vCPU limit (vCPU 制限)\] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。 ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。 ## [](#cpu-バースト)CPU バースト CPU バーストを使用するときは、次の要素を考慮する必要があります。 - 最小予約済み vCPU: 0.02 vCPU。 - vCPU の下限: 0.07 vCPU。 大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。 - CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。 - 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。 - Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。 - 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 150Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。 - 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。 - アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。 どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。 ## [](#メモリの割り当て)メモリの割り当て Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。 - 0.7 GB メモリ (Mule 4) - 0.5 GB メモリ (Mule 3) Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。 ## [](#cloudhub-および-runtime-fabric-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。Anypoint Platform は、デプロイされたアプリケーションへのネイティブメモリの割り当てを JVM を介して、Java メモリ管理の標準プラクティスを考慮して実行します。 CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。 - Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。 使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。 - CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。 ## [](#アプリケーションの起動時間)アプリケーションの起動時間 Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。
vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分
## [](#アプリケーションのパフォーマンス)アプリケーションのパフォーマンス Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。
vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。
## [](#キーと証明書の-cpu-要件)キーと証明書の CPU 要件 最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。
コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8
## [](#キー種別)キー種別 RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。 - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (prime256v1 (P-256) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.7/view-health) # Runtime Fabric へのアプリケーションデプロイメント用のリソースの割り当て Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。 Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。 次のパフォーマンス情報は、カスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを使用するコントローラーノードのクラスターに基づきます。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。負荷ジェネレーターは、同じリージョンの別のクラスターでホストされます。 アプリケーションのデプロイ時に次のリソースを割り当てることができます。 - vCPU コア - `Reserved vCPU` アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。 - `vCPU Limit` アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。 - Memory (メモリ) Runtime Fabric インスタンスにデプロイするアプリケーションの ​[Mulesoft ライセンス要件](https://docs.mulesoft.com/jp/runtime-fabric/2.8/limitations-self#license-compliance)​を確認します。 ## [](#vcpu-の割り当て)vCPU の割り当て \[​`Reserved vCPU`​ (予約済み vCPU)\] と \[​`vCPU Limit`​ (vCPU 制限)\] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。 CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。 \[​`vCPU Limit`​ (vCPU 制限)\] の値が \[​`Reserved vCPU`​ (予約済み vCPU)\] の値よりも高く設定されていると、アプリケーションは、\[vCPU limit (vCPU 制限)\] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。 ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。 ## [](#cpu-バースト)CPU バースト CPU バーストを使用するときは、次の要素を考慮する必要があります。 - 最小予約済み vCPU: 0.02 vCPU。 - vCPU の下限: 0.07 vCPU。 大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。 - CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。 - 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。 - Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。 - 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 150Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。 - 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。 - アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。 どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。 ## [](#メモリの割り当て)メモリの割り当て Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。 - 0.7 GB メモリ (Mule 4) - 0.5 GB メモリ (Mule 3) Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。 ## [](#cloudhub-および-runtime-fabric-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。Anypoint Platform は、デプロイされたアプリケーションへのネイティブメモリの割り当てを JVM を介して、Java メモリ管理の標準プラクティスを考慮して実行します。 CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。 - Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。 使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。 - CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。 ## [](#アプリケーションの起動時間)アプリケーションの起動時間 Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。
vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分
## [](#アプリケーションのパフォーマンス)アプリケーションのパフォーマンス Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。
vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。
## [](#キーと証明書の-cpu-要件)キーと証明書の CPU 要件 最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。
コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8
## [](#キー種別)キー種別 RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。 - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (prime256v1 (P-256) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/2.8/view-health) # Runtime Fabric をサポートするためのネットワークの設定

ネットワーク設定は IT 管理者が実行する必要があります。
Runtime Fabric をインストールまたは使用する前に、次のポートとホスト名が正しく設定されていることを確認します。 ## [](#ポート設定)ポート設定 Runtime Fabric をインストールまたは実行するには、Kubernetes インストールで次のポートが設定されていることを確認します。 プロトコル対応のファイアウォールの場合は、次のポートトラフィックに Websockets 経由の AMQP (Advanced Message Queuing Protocol) を許可することを検討してください。

次の表には、Anypoint Platform のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​Anypoint Mule ゲートウェイのドキュメント​を参照してください。
ポート レイヤー 4 プロトコル レイヤー 5 プロトコル ソース 宛先 説明

443

TCP

HTTPS

API コンシューマー

すべてのノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

すべてのノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer
## [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/persistence-gateway)​を参照してください。 ## [](#ホスト名設定)ホスト名設定 Runtime Fabric を正しく機能させるには、次のホスト名設定が必要です。
ポート プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-router.us-east-1.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io​

  • EU コントロールプレーン: dias-ingestor-router.eu-central-1.prod-eu.msap.io

Runtime Fabric 用の Anypoint Monitoring エージェント。

5044 (従来)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io

Runtime Fabric 用の Anypoint Monitoring エージェント。

Runtime Fabric バージョン 1.8.50 以降では、このポートは厳密には要求されません。このポートは将来廃止される予定です。​ 問題が発生した場合は、 「ERROR in sidecar logs (サイドカーログのエラー)」​ナレッジベース記事を参照してください。

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com​、​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com​、​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​、​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​、​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​

  • EU コントロールプレーン: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
## [](#アウトバウンド接続の確認)アウトバウンド接続の確認 すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。 `rtfctl`​ を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認できます。各ノードで、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-rtfctl)​の手順に従って ​`rtfctl`​ をインストールします。 必要なアウトバウンド接続を検証するには、クラスターのすべてのコントローラーとワーカーノードで次のコマンドを実行します。 sudo ./rtfctl test outbound-network サンプル出力: \[root@rtf-controller-1 runtimefabric\]# sudo ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して、ポートの設定セクションで説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。 ## [](#証明書設定)証明書設定 異なるエンドポイントが相互 TLS 認証を使用して接続を確立できるようにするには、次の証明書を許可するための SSL パススルーを設定する必要があります。
コントロールプレーン 証明書

US コントロールプレーン

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU コントロールプレーン

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io
# Runtime Fabric をサポートするためのネットワークの設定

ネットワーク設定は IT 管理者が実行する必要があります。
Runtime Fabric をインストールまたは使用する前に、次のポートとホスト名が正しく設定されていることを確認します。 ## [](#ポート設定)ポート設定 Runtime Fabric をインストールまたは実行するには、Kubernetes インストールで次のポートが設定されていることを確認します。 プロトコル対応のファイアウォールの場合は、次のポートトラフィックに Websockets 経由の AMQP (Advanced Message Queuing Protocol) を許可することを検討してください。

次の表には、Anypoint Platform のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​Anypoint Mule ゲートウェイのドキュメント​を参照してください。
ポート レイヤー 4 プロトコル レイヤー 5 プロトコル ソース 宛先 説明

443

TCP

HTTPS

API コンシューマー

すべてのノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

すべてのノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer
## [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/persistence-gateway)​を参照してください。 ## [](#ホスト名設定)ホスト名設定 Runtime Fabric を正しく機能させるには、次のホスト名設定が必要です。
ポート プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU コントロールプレーン:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Runtime Fabric 用の ​Anypoint Monitoring​ エージェント。

5044 (従来)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io

Runtime Fabric 用の ​Anypoint Monitoring​ エージェント。

Runtime Fabric バージョン 1.8.50 以降では、このポートは厳密には要求されません。このポートは将来廃止される予定です。​ 問題が発生した場合は、 「ERROR in sidecar logs (サイドカーログのエラー)」​ナレッジベース記事を参照してください。

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com​、​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com​、​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​、​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​、​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​

  • EU コントロールプレーン: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
## [](#アウトバウンド接続の確認)アウトバウンド接続の確認 すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。 `rtfctl`​ を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認できます。各ノードで、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-rtfctl)​の手順に従って ​`rtfctl`​ をインストールします。 必要なアウトバウンド接続を検証するには、クラスターのすべてのコントローラーとワーカーノードで次のコマンドを実行します。 sudo ./rtfctl test outbound-network サンプル出力: \[root@rtf-controller-1 runtimefabric\]# sudo ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して、ポートの設定セクションで説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。 ## [](#証明書設定)証明書設定 異なるエンドポイントが相互 TLS 認証を使用して接続を確立できるようにするには、次の証明書を許可するための SSL パススルーを設定する必要があります。
コントロールプレーン 証明書

US コントロールプレーン

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU コントロールプレーン

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io
# Runtime Fabric をサポートするためのネットワークの設定

ネットワーク設定は IT 管理者が実行する必要があります。
Runtime Fabric をインストールまたは使用する前に、次のポートとホスト名が正しく設定されていることを確認します。 ## [](#ポート設定)ポート設定 Runtime Fabric をインストールまたは実行するには、Kubernetes インストールで次のポートが設定されていることを確認します。 プロトコル対応のファイアウォールの場合は、次のポートトラフィックに Websockets 経由の AMQP (Advanced Message Queuing Protocol) を許可することを検討してください。

次の表には、Anypoint Platform のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​Anypoint Mule ゲートウェイのドキュメント​を参照してください。
ポート レイヤー 4 プロトコル レイヤー 5 プロトコル ソース 宛先 説明

443

TCP

HTTPS

API コンシューマー

すべてのノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

すべてのノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer
## [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/persistence-gateway)​を参照してください。 ## [](#ホスト名設定)ホスト名設定 Runtime Fabric を正しく機能させるには、次のホスト名設定が必要です。
ポート プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU コントロールプレーン:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Runtime Fabric 用の ​Anypoint Monitoring​ エージェント。

5044 (従来)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io

Runtime Fabric 用の ​Anypoint Monitoring​ エージェント。

Runtime Fabric バージョン 1.8.50 以降では、このポートは厳密には要求されません。このポートは将来廃止される予定です。​ 問題が発生した場合は、 「ERROR in sidecar logs (サイドカーログのエラー)」​ナレッジベース記事を参照してください。

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com​、​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com​、​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​、​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​、​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​

  • EU コントロールプレーン: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
## [](#アウトバウンド接続の確認)アウトバウンド接続の確認 すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。 `rtfctl`​ を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認できます。各ノードで、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-rtfctl)​の手順に従って ​`rtfctl`​ をインストールします。 必要なアウトバウンド接続を検証するには、クラスターのすべてのコントローラーとワーカーノードで次のコマンドを実行します。 sudo ./rtfctl test outbound-network サンプル出力: \[root@rtf-controller-1 runtimefabric\]# sudo ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して、ポートの設定セクションで説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。 ## [](#証明書設定)証明書設定 異なるエンドポイントが相互 TLS 認証を使用して接続を確立できるようにするには、次の証明書を許可するための SSL パススルーを設定する必要があります。
コントロールプレーン 証明書

US コントロールプレーン

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU コントロールプレーン

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io
# Runtime Fabric をサポートするためのネットワークの設定

ネットワーク設定は IT 管理者が実行する必要があります。
Runtime Fabric をインストールまたは使用する前に、次のポートとホスト名が正しく設定されていることを確認します。 クラスター内のすべての内部通信 (ポッドとサービス間) を許可する必要があります。 ## [](#ポート設定)ポート設定 Runtime Fabric をインストールまたは実行するには、Kubernetes インストールで次のポートが設定されていることを確認します。 プロトコル対応のファイアウォールの場合は、次のポートトラフィックに Websockets 経由の AMQP (Advanced Message Queuing Protocol) を許可することを検討してください。

次の表には、Anypoint Platform のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​Anypoint Mule ゲートウェイのドキュメント​を参照してください。
ポート レイヤー 4 プロトコル レイヤー 7 プロトコル ソース 宛先 説明

443

TCP

HTTPS

API コンシューマー

すべてのノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

すべてのノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer
## [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/persistence-gateway)​を参照してください。 ## [](#ホスト名エンドポイント設定)ホスト名エンドポイント設定 Runtime Fabric を正しく機能させるには、次のホスト名エンドポイント設定が必要です。インフラストラクチャ内のこれらのエンドポイントへのアクセス権を付与して、インストールやデプロイメントの問題を回避します。
ポート プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン:
    dias-ingestor-router.us-east-1.prod.cloudhub.io
    us1.ingest.mulesoft.com

  • EU コントロールプレーン:
    dias-ingestor-router.eu-central-1.prod-eu.msap.io
    eu1.ingest.mulesoft.com

Runtime Fabric 用の ​Anypoint Monitoring​ エージェント。

5044 (従来)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io

Runtime Fabric 用の ​Anypoint Monitoring​ エージェント。

Runtime Fabric バージョン 1.8.50 以降では、このポートは厳密には要求されません。このポートは将来廃止される予定です。​ 問題が発生した場合は、 「ERROR in sidecar logs (サイドカーログのエラー)」​ナレッジベース記事を参照してください。

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com​、​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com​、​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​、​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​、​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​

  • EU コントロールプレーン: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
## [](#アウトバウンド接続の確認)アウトバウンド接続の確認 すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。 `rtfctl`​ を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認できます。各ノードで、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-rtfctl)​の手順に従って ​`rtfctl`​ をインストールします。 必要なアウトバウンド接続を検証するには、クラスターのすべてのコントローラーとワーカーノードで次のコマンドを実行します。 sudo ./rtfctl test outbound-network サンプル出力: \[root@rtf-controller-1 runtimefabric\]# sudo ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して、ポートの設定セクションで説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。 ## [](#証明書設定)証明書設定 異なるエンドポイントが相互 TLS 認証を使用して接続を確立できるようにするには、次の証明書を許可するための SSL パススルーを設定する必要があります。
コントロールプレーン 証明書

US コントロールプレーン

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io
us1.ingest.mulesoft.com

EU コントロールプレーン

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io
# Runtime Fabric 上のアプリケーションの Mule Runtime パッチ更新の管理 以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新と Mule Runtime Engine リリースチャネルに関する重要な情報を提供します。 ## [](#バージョンの書き換え)バージョンの書き換え バージョンの書き換えは、デプロイメント要求で指定されたビルドタグがサポート終了または無効だった場合に、そのビルドタグを上書きするために使用されます。2023 年 10 月 3 日以降、バージョン書き換えは、どのバージョンでも指定されたタグを上書きしません。ただし、ビルドタグなしで Mule アプリケーションが API 経由でデプロイされた場合は、最新のビルドが自動的に選択されます。 ## [](#月-1-回の日付パッチ更新)月 1 回の日付パッチ更新 月 1 回、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 これらの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ - ​_日付_​ [Mule Runtime バージョンの命名の変更](#mule-runtime-version) パッチ日付が含まれるバージョン番号の例を示します。 `4.3.0:20210101` 月 1 回のパッチでは、アプリケーションが最新の日付のパッチのみに更新されます。ランタイムバージョンは変更されません。 ### [](#runtime-fabric-の-mule-runtime-パッチ更新スケジュール)Runtime Fabric の Mule Runtime パッチ更新スケジュール Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。 1. 月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。 2. 次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは​_猶予期間_​と呼ばれます。 3. 月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。 Mule Runtime Engine のバージョン 4.5 から、バージョンのピン留めに必要なタグを渡すことで、再デプロイ時に Mule アプリケーションの自動アップグレードを無効にできます。 猶予期間中は、前の日付のパッチバージョンが Runtime Manager UI で使用できなくなるまで、これらのバージョンを選択できます (その後も API 経由であれば使用できます)。この動作は、Edge および LTS チャネルリリースの Mule Runtime Engine バージョン 4.5 から変更されます。すべてのビルドタグは、Runtime Manager UI および API で利用できます。 ### [](#1-つのアプリケーションの最新のランタイムパッチリリースへの更新)1 つのアプリケーションの最新のランタイムパッチリリースへの更新 本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。 アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。 1. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. **\[Deployment Target (デプロイメント対象)\]**​ の ​**\[Runtime version (ランタイムバージョン)\]**​ リストから、​`new`​ とタグ付けされたバージョンを選択します。 ![新しいランタイムバージョンが選択されています。](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-runtime-select-version.png) 更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。 ![日付で示されている最新のランタイムバージョン。](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-runtime-select-latest-version.png) 3. バージョンの詳細を確認するには、​**\[Read release notes (リリースノートを読む)\]**​ リンクをクリックします。 4. **\[Apply Changes (変更を適用)\]**​ をクリックしてアプリケーションを更新します。 Runtime Fabric により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。 5. アプリケーションを再デプロイします。 Runtime Fabric の Mule デプロイメントには、自動的にパッチが適用されません。最新の日付のパッチ更新を適用するにはアプリケーションを再デプロイする必要があります。 ## [](#mule-用の-edge-および-lts-リリース)Mule 用の Edge および LTS リリース Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel Type Release Cadence Differentiators Support Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support
If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).
For information about the monthly patch update process, see Update Patches to Mule.
## [](#edge_channel)Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## [](#lts_channel)LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## [](#switch-from-an-edge-version-to-an-lts-version)Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## [](#mule-runtime-release-cadence-support)Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule Version Release Date Java Version End of Standard Support End of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.
## [](#deployment-models-and-application-lifecycle-management)Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
アクション Runtime Fabric

新規アプリケーションのデプロイ

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

自動アップグレード

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

自己アップグレード

Always available

ロールバック

Available to the previously used version

アプリケーションの再起動

Always

アプリケーションの実行維持

Always

延長サポートの終了

Cannot deploy new apps

廃止

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

サポート可能性

Supported while Mule apps are within the assigned support period.
## [](#mule-runtime-version)Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric の要件 regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid Standalone CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)
The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. Runtime Manager UI で ​**\[Use Edge Release Channel (Edge リリースチャネルを使用)\]**​ オプションを選択すると、プラットフォームには Edge チャネルと LTS チャネルのすべてのビルドタグが表示されます。このビルドタグにより、指定した Mule Runtime バージョンでイメージを複数回ビルドできるため、このビルドタグは Runtime Manager と CloudHub 2.0 に固有となっています。 Runtime Manager UI には Mule Runtime Engine のバージョン 4.5 以前用のビルドタグは表示されませんが、API 経由で任意のビルドを使用できます。 ## [](#関連情報)関連情報 - [Runtime Fabric ランタイムリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) # Runtime Fabric 上のアプリケーションの Mule Runtime パッチ更新の管理 以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新と Mule Runtime Engine リリースチャネルに関する重要な情報を提供します。 パッチ更新のリストについては、​[「Runtime Fabric の Mule Runtime パッチ更新」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#バージョンの書き換え)バージョンの書き換え バージョンの書き換えは、デプロイメント要求で指定されたビルドタグがサポート終了または無効だった場合に、そのビルドタグを上書きするために使用されます。2023 年 10 月 3 日以降、バージョン書き換えは、どのバージョンでも指定されたタグを上書きしません。ただし、ビルドタグなしで Mule アプリケーションが API 経由でデプロイされた場合は、最新のビルドが自動的に選択されます。 ## [](#月-1-回の日付パッチ更新)月 1 回の日付パッチ更新 月 1 回、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 これらの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ - ​_日付_​ [Mule Runtime バージョンの命名の変更](#mule-runtime-version) パッチ日付が含まれるバージョン番号の例を示します。 `4.3.0:20210101` 月 1 回のパッチでは、アプリケーションが最新の日付のパッチのみに更新されます。ランタイムバージョンは変更されません。 ### [](#runtime-fabric-の-mule-runtime-パッチ更新スケジュール)Runtime Fabric の Mule Runtime パッチ更新スケジュール Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。 1. 月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。 2. 次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは​_猶予期間_​と呼ばれます。 3. 月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。 Mule Runtime Engine のバージョン 4.5 から、バージョンのピン留めに必要なタグを渡すことで、再デプロイ時に Mule アプリケーションの自動アップグレードを無効にできます。 猶予期間中は、前の日付のパッチバージョンが Runtime Manager UI で使用できなくなるまで、これらのバージョンを選択できます (その後も API 経由であれば使用できます)。この動作は、Edge および LTS チャネルリリースの Mule Runtime Engine バージョン 4.5 から変更されます。すべてのビルドタグは、Runtime Manager UI および API で利用できます。 ### [](#1-つのアプリケーションの最新のランタイムパッチリリースへの更新)1 つのアプリケーションの最新のランタイムパッチリリースへの更新 本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。 アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。 1. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. **\[Deployment Target (デプロイメント対象)\]**​ の ​**\[Runtime version (ランタイムバージョン)\]**​ リストから、​`new`​ とタグ付けされたバージョンを選択します。 ![新しいランタイムバージョンが選択されています。](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-runtime-select-version.png) 更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。 ![日付で示されている最新のランタイムバージョン。](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-runtime-select-latest-version.png) 3. バージョンの詳細を確認するには、​**\[Read release notes (リリースノートを読む)\]**​ リンクをクリックします。 4. **\[Apply Changes (変更を適用)\]**​ をクリックしてアプリケーションを更新します。 Runtime Fabric により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。 5. アプリケーションを再デプロイします。 Runtime Fabric の Mule デプロイメントには、自動的にパッチが適用されません。最新の日付のパッチ更新を適用するにはアプリケーションを再デプロイする必要があります。 ## [](#mule-用の-edge-および-lts-リリース)Mule 用の Edge および LTS リリース Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel Type Release Cadence Differentiators Support Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support
If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).
For information about the monthly patch update process, see Update Patches to Mule.
## [](#edge_channel)Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## [](#lts_channel)LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## [](#switch-from-an-edge-version-to-an-lts-version)Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## [](#mule-runtime-release-cadence-support)Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule Version Release Date Java Version End of Standard Support End of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.
## [](#deployment-models-and-application-lifecycle-management)Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
アクション Runtime Fabric

新規アプリケーションのデプロイ

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

自動アップグレード

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

自己アップグレード

Always available

ロールバック

Available to the previously used version

アプリケーションの再起動

Always

アプリケーションの実行維持

Always

延長サポートの終了

Cannot deploy new apps

廃止

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

サポート可能性

Supported while Mule apps are within the assigned support period.
## [](#mule-runtime-version)Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric の要件 regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid Standalone CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)
The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. Runtime Manager UI で ​**\[Use Edge Release Channel (Edge リリースチャネルを使用)\]**​ オプションを選択すると、プラットフォームには Edge チャネルと LTS チャネルのすべてのビルドタグが表示されます。このビルドタグにより、指定した Mule Runtime バージョンでイメージを複数回ビルドできるため、このビルドタグは Runtime Manager と CloudHub 2.0 に固有となっています。 Runtime Manager UI には Mule Runtime Engine のバージョン 4.5 以前用のビルドタグは表示されませんが、API 経由で任意のビルドを使用できます。 ## [](#関連情報)関連情報 - [Runtime Fabric ランタイムリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) # Runtime Fabric 上のアプリケーションの Mule Runtime パッチ更新の管理 以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新と Mule Runtime Engine リリースチャネルに関する重要な情報を提供します。 パッチ更新のリストについては、​[「Runtime Fabric の Mule Runtime パッチ更新」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#バージョンの書き換え)バージョンの書き換え バージョンの書き換えは、デプロイメント要求で指定されたビルドタグがサポート終了または無効だった場合に、そのビルドタグを上書きするために使用されます。2023 年 10 月 3 日以降、バージョン書き換えは、どのバージョンでも指定されたタグを上書きしません。ただし、ビルドタグなしで Mule アプリケーションが API 経由でデプロイされた場合は、最新のビルドが自動的に選択されます。 ## [](#月-1-回の日付パッチ更新)月 1 回の日付パッチ更新 月 1 回、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 これらの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ - ​_日付_​ [Mule Runtime バージョンの命名の変更](#mule-runtime-version) パッチ日付が含まれるバージョン番号の例を示します。 `4.3.0:20210101` 月 1 回のパッチでは、アプリケーションが最新の日付のパッチのみに更新されます。ランタイムバージョンは変更されません。 ### [](#runtime-fabric-の-mule-runtime-パッチ更新スケジュール)Runtime Fabric の Mule Runtime パッチ更新スケジュール Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。 1. 月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。 2. 次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは​_猶予期間_​と呼ばれます。 3. 月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。 Mule Runtime Engine のバージョン 4.5 から、バージョンのピン留めに必要なタグを渡すことで、再デプロイ時に Mule アプリケーションの自動アップグレードを無効にできます。 猶予期間中は、前の日付のパッチバージョンが Runtime Manager UI で使用できなくなるまで、これらのバージョンを選択できます (その後も API 経由であれば使用できます)。この動作は、Edge および LTS チャネルリリースの Mule Runtime Engine バージョン 4.5 から変更されます。すべてのビルドタグは、Runtime Manager UI および API で利用できます。 ### [](#1-つのアプリケーションの最新のランタイムパッチリリースへの更新)1 つのアプリケーションの最新のランタイムパッチリリースへの更新 本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。 アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。 1. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. **\[Deployment Target (デプロイメント対象)\]**​ の ​**\[Runtime version (ランタイムバージョン)\]**​ リストから、​`new`​ とタグ付けされたバージョンを選択します。 ![新しいランタイムバージョンが選択されています。](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-runtime-select-version.png) 更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。 ![日付で示されている最新のランタイムバージョン。](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-runtime-select-latest-version.png) 3. バージョンの詳細を確認するには、​**\[Read release notes (リリースノートを読む)\]**​ リンクをクリックします。 4. **\[Apply Changes (変更を適用)\]**​ をクリックしてアプリケーションを更新します。 Runtime Fabric により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。 5. アプリケーションを再デプロイします。 Runtime Fabric の Mule デプロイメントには、自動的にパッチが適用されません。最新の日付のパッチ更新を適用するにはアプリケーションを再デプロイする必要があります。 ## [](#mule-用の-edge-および-lts-リリース)Mule 用の Edge および LTS リリース Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel Type Release Cadence Differentiators Support Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support
If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).
For information about the monthly patch update process, see Update Patches to Mule.
## [](#edge_channel)Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## [](#lts_channel)LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## [](#switch-from-an-edge-version-to-an-lts-version)Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## [](#mule-runtime-release-cadence-support)Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule Version Release Date Java Version End of Standard Support End of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.
## [](#deployment-models-and-application-lifecycle-management)Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
アクション Runtime Fabric

新規アプリケーションのデプロイ

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

自動アップグレード

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

自己アップグレード

Always available

ロールバック

Available to the previously used version

アプリケーションの再起動

Always

アプリケーションの実行維持

Always

延長サポートの終了

Cannot deploy new apps

廃止

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

サポート可能性

Supported while Mule apps are within the assigned support period.
## [](#mule-runtime-version)Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric の要件 regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid Standalone CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)
The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. Runtime Manager UI で ​**\[Use Edge Release Channel (Edge リリースチャネルを使用)\]**​ オプションを選択すると、プラットフォームには Edge チャネルと LTS チャネルのすべてのビルドタグが表示されます。このビルドタグにより、指定した Mule Runtime バージョンでイメージを複数回ビルドできるため、このビルドタグは Runtime Manager と CloudHub 2.0 に固有となっています。 Runtime Manager UI には Mule Runtime Engine のバージョン 4.5 以前用のビルドタグは表示されませんが、API 経由で任意のビルドを使用できます。 ## [](#関連情報)関連情報 - [Runtime Fabric ランタイムリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) # Runtime Fabric 上のアプリケーションの Mule Runtime パッチ更新の管理 以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新と Mule Runtime Engine リリースチャネルに関する重要な情報を提供します。 パッチ更新のリストについては、​[「Runtime Fabric の Mule Runtime パッチ更新」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 ## [](#バージョンの書き換え)バージョンの書き換え バージョンの書き換えは、デプロイメント要求で指定されたビルドタグがサポート終了または無効だった場合に、そのビルドタグを上書きするために使用されます。2023 年 10 月 3 日以降、バージョン書き換えは、どのバージョンでも指定されたタグを上書きしません。ただし、ビルドタグなしで Mule アプリケーションが API 経由でデプロイされた場合は、最新のビルドが自動的に選択されます。 ## [](#月-1-回の日付パッチ更新)月 1 回の日付パッチ更新 月 1 回、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 これらの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ - ​_日付_​ [Mule Runtime バージョンの命名の変更](#mule-runtime-version) パッチ日付が含まれるバージョン番号の例を示します。 `4.3.0:20210101` 月 1 回のパッチでは、アプリケーションが最新の日付のパッチのみに更新されます。ランタイムバージョンは変更されません。 ### [](#runtime-fabric-の-mule-runtime-パッチ更新スケジュール)Runtime Fabric の Mule Runtime パッチ更新スケジュール Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。 1. 月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。 2. 次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは​_猶予期間_​と呼ばれます。 3. 月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。 Mule Runtime Engine のバージョン 4.5 から、バージョンのピン留めに必要なタグを渡すことで、再デプロイ時に Mule アプリケーションの自動アップグレードを無効にできます。 猶予期間中は、前の日付のパッチバージョンが Runtime Manager UI で使用できなくなるまで、これらのバージョンを選択できます (その後も API 経由であれば使用できます)。この動作は、Edge および LTS チャネルリリースの Mule Runtime Engine バージョン 4.5 から変更されます。すべてのビルドタグは、Runtime Manager UI および API で利用できます。 ### [](#1-つのアプリケーションの最新のランタイムパッチリリースへの更新)1 つのアプリケーションの最新のランタイムパッチリリースへの更新 本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。 アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。 1. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. **\[Deployment Target (デプロイメント対象)\]**​ の ​**\[Runtime version (ランタイムバージョン)\]**​ リストから、​`new`​ とタグ付けされたバージョンを選択します。 ![新しいランタイムバージョンが選択されています。](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-runtime-select-version.png) 更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。 ![日付で示されている最新のランタイムバージョン。](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-runtime-select-latest-version.png) 3. バージョンの詳細を確認するには、​**\[Read release notes (リリースノートを読む)\]**​ リンクをクリックします。 4. **\[Apply Changes (変更を適用)\]**​ をクリックしてアプリケーションを更新します。 Runtime Fabric により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。 5. アプリケーションを再デプロイします。 Runtime Fabric の Mule デプロイメントには、自動的にパッチが適用されません。最新の日付のパッチ更新を適用するにはアプリケーションを再デプロイする必要があります。 ## [](#mule-用の-edge-および-lts-リリース)Mule 用の Edge および LTS リリース Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-Term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Release cadence refers to new Mule runtime versions. Patch updates for supported versions continue to follow the monthly patch update schedule. Consider these factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel Type Release Cadence Differentiators Support Coverage

Edge

Up to three times per year

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions aren’t FedRAMP approved.

For versions 4.9 and later:

  • Standard Support until one month after the next Edge version is released

  • 3 months of Extended Support

For version 4.8:

  • 5 months of Standard Support

  • 3 months of Extended Support

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

LTS

Periodic (Scheduled for February)

  • Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

For version 4.6 and later:

  • A minimum of 18 months of Standard Support

  • A minimum of 6 months of Extended Support
If an LTS version is released in February, both Edge and LTS share the same underlying version, including the same minor Mule runtime version and new features. To review the new support policy that aligns with the new release periods and types of releases, see [MuleSoft Support Policy](https://www.salesforce.com/en-us/wp-content/uploads/sites/4/documents/legal/Agreements/versioning-back-support-policy.pdf).
For information about the monthly patch update process, see Update Patches to Mule.
## [](#edge_channel)Edge Channel Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform. ## [](#lts_channel)LTS Channel Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions periodically, scheduled for February. If you’re on Mule 4.4, you aren’t required to upgrade to Mule 4.6. However, because Mule 4.5 was released in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the end of Extended Support in October 2025. Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases. ## [](#switch-from-an-edge-version-to-an-lts-version)Switch from an Edge Version to an LTS Version You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version. ## [](#mule-runtime-release-cadence-support)Mule Runtime Release Cadence Support This table shows the Mule runtime release cadence support for each channel:
Mule Version Release Date Java Version End of Standard Support End of Extended Support

4.13 Edge

October 2026

17

March 2027

June 2027

4.12 Edge

June 2026

17

November 2026

February 2027

4.11 Edge

February 2026

17

July 2026

October 2026

4.10 Edge

October 2025

17

March 2026

June 2026

4.9 LTS

February 2025

17

August 2027

February 2028

4.9 Edge

February 2025

17

November 2025

February 2026

4.8 Edge

October 2024

8, 11, and 17

March 2025

June 2025

4.7 Edge

June 2024

8, 11, and 17

October 2024

February 2025

4.6 LTS

February 2024

8, 11, and 17

August 2026

February 2027

4.6 Edge

February 2024

8, 11, and 17

June 2024

October 2024

4.5 Edge

October 2023

8 and 11

February 2024

June 2024
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.
## [](#deployment-models-and-application-lifecycle-management)Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
アクション Runtime Fabric

新規アプリケーションのデプロイ

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

自動アップグレード

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

自己アップグレード

Always available

ロールバック

Available to the previously used version

アプリケーションの再起動

Always

アプリケーションの実行維持

Always

延長サポートの終了

Cannot deploy new apps

廃止

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

サポート可能性

Supported while Mule apps are within the assigned support period.
## [](#mule-runtime-version)Mule Runtime Version Naming Changes The version naming convention depends on the deployment model you’re using. A version increments: - MAJOR when a release includes features that introduce breaking changes and backward incompatibility. - MINOR when a release includes all new features keeping backward compatibility with previous minors. - PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test. - BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes. The Mule runtime versioning schema for the new release channels is: _Major\[numeric\] . Minor\[numeric\] . Patch\[numeric\] : Build\[numeric\] Channel\[e for edge, nothing for LTS\]_ Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they’re represented as: - Edge: 4.6.0:1e - LTS: 4.6.0:1 Runtime Fabric の要件 regular OS updates, hence the addition of the build enumeration in the full runtime version schema. Here are examples of the version numbers: - Edge: 4.5.0:1e - Edge: 4.6.0:1e - LTS: 4.6.0:1 Mule runtime does not introduce a semVer increment if there is a month with no fixes. Here is an example of the versioning schema using different patch and builds:
Hybrid Standalone CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

Not Available

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

Not Available

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

4.6.0:1e (Edge) / 4.6.0:1 (LTS)
The Mule runtime versioning schema uses these conventions: - Patch number in schema - In the schema `4.5.X:2e`, the patch number is the X. - The patch number starts from `0`, introducing a new minor version. - The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes. - Build number in schema - In the schema `4.5.1:Ye`, the build number is Y. - The build number starts from `1`, introducing the first AMI or Docker image build of the patch. - The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime. Runtime Manager UI で ​**\[Use Edge Release Channel (Edge リリースチャネルを使用)\]**​ オプションを選択すると、プラットフォームには Edge チャネルと LTS チャネルのすべてのビルドタグが表示されます。このビルドタグにより、指定した Mule Runtime バージョンでイメージを複数回ビルドできるため、このビルドタグは Runtime Manager と CloudHub 2.0 に固有となっています。 Runtime Manager UI には Mule Runtime Engine のバージョン 4.5 以前用のビルドタグは表示されませんが、API 経由で任意のビルドを使用できます。 ## [](#関連情報)関連情報 - [Runtime Fabric ランタイムリリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes) # Runtime Fabric 向けの Kubernetes の設定 Anypoint Runtime Fabric 向けに Kubernetes を設定するには、次のトピックを確認します。 - [Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-k8s-practices) 拡張性ベンチマークとクラスター設定のベストプラクティスを確認します。 - [Kubernetes 強化ガイド](https://docs.mulesoft.com/jp/runtime-fabric/2.6/kubernetes-hardening-guide) 『Kubernetes 強化ガイド』に基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかを確認します。 - [Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.6/customize-kubernetes-crd) カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズします。 - [Runtime Fabric の Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/rtf-kubernetes-permissions) Runtime Fabric 用に Kubernetes の権限を設定します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.6/hardening-runtime-fabric) # Runtime Fabric 向けの Kubernetes の設定 Anypoint Runtime Fabric 向けに Kubernetes を設定するには、次のトピックを確認します。 - [Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-k8s-practices) 拡張性ベンチマークとクラスター設定のベストプラクティスを確認します。 - [Kubernetes 強化ガイド](https://docs.mulesoft.com/jp/runtime-fabric/2.7/kubernetes-hardening-guide) 『Kubernetes 強化ガイド』に基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかを確認します。 - [Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.7/customize-kubernetes-crd) カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズします。 - [Runtime Fabric の Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/rtf-kubernetes-permissions) Runtime Fabric 用に Kubernetes の権限を設定します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.7/hardening-runtime-fabric) # Runtime Fabric 向けの Kubernetes の設定 Anypoint Runtime Fabric 向けに Kubernetes を設定するには、次のトピックを確認します。 - [Runtime Fabric に関する Kubernetes (K8s) のベストプラクティス](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-k8s-practices) 拡張性ベンチマークとクラスター設定のベストプラクティスを確認します。 - [Kubernetes 強化ガイド](https://docs.mulesoft.com/jp/runtime-fabric/2.8/kubernetes-hardening-guide) 『Kubernetes 強化ガイド』に基づいて Kubernetes クラスターをセットアップして、どのようにセキュリティを強化できるかを確認します。 - [Mule アプリケーション Kubernetes リソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/2.8/customize-kubernetes-crd) カスタムリソース ​`kubernetestemplates.rtf.mulesoft.com`​ テンプレートを使用して Mule アプリケーション Kubernetes リソースをカスタマイズします。 - [Runtime Fabric の Kubernetes 権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/rtf-kubernetes-permissions) Runtime Fabric 用に Kubernetes の権限を設定します。 ## [](#関連情報)関連情報 - [Runtime Fabric の強化](https://docs.mulesoft.com/jp/runtime-fabric/2.8/hardening-runtime-fabric) # Runtime Manager を使用した Runtime Fabric への Mule アプリケーションのデプロイ Mule アプリケーションを Anypoint Runtime Fabric の Mule Runtime サーバーにデプロイします。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションから分離された Runtime Fabric のインスタンスにデプロイされる必要があります。 アプリケーションをデプロイしたら、デプロイされたアプリケーションのインバウンドトラフィックをテストできます。 ## [](#runtime-fabric-に-mule-アプリケーションをデプロイする)Runtime Fabric に Mule アプリケーションをデプロイする デプロイメントプロセス全体には次の手順が含まれます。 1. アプリケーションとデプロイメント対象を選択する 2. デプロイメント対象を設定する 3. アプリケーションの公開エンドポイントを設定する 4. 複製をセットアップする 5. (省略可能) TLSv1 および TLSv1.1 を有効にする 6. アプリケーションプロパティを設定する 7. アプリケーションをデプロイする ### [](#前提条件)前提条件 アプリケーションを Anypoint Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric にアプリケーションをデプロイするのに必要な ​[Anypoint Platform のロールと権限](https://docs.mulesoft.com/jp/runtime-fabric/2.6/#anypoint-platform-roles-and-permissions)​を確認する。 - Runtime Fabric が環境に関連付けられていることを確認する。​[「ビジネスグループと環境の Anypoint Runtime Fabric への関連付け」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/associate-environments)​を参照してください。 - アプリケーションのリソース割り当て要件を決定する。詳細は、​[「Runtime Fabric でのアプリケーションリソース割り当ての決定」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-resource-allocation-self-managed)​を参照してください。 - アプリケーションを特定のドメイン (エンドポイント) にデプロイするには、環境にドメイン (エンドポイント) がセットアップされていることを確認する。​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​を参照してください。 - Red Hat OpenShift で Runtime Fabric を使用している場合は、​[「Prepare for Deploying Mule Apps to Red Hat OpenShift (Red Hat OpenShift に Mule アプリケーションをデプロイする準備をする)」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift)​の手順に従ってアプリケーションのデプロイメントを有効にしてください。 ### [](#アプリケーションとデプロイメント対象を選択する)アプリケーションとデプロイメント対象を選択する 1. [Anypoint Platform](https://anypoint.mulesoft.com)​ にサインインします。 2. **\[Runtime Manager\]**​ に移動し、​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Application Name (アプリケーション名)\]**​ 項目で、アプリケーションに名前を付けます。 名前に使用できるのは、小文字の英数字、ハイフン、およびアンダースコアのみです。 5. **\[Choose File (ファイルを選択)\]**​ をクリックしてデプロイするアプリケーションを選択し、次のいずれかのオプションを選択します。 - **Import file from Exchange (Exchange からファイルをインポート)**​: Anypoint Exchange に保存されている Mule アプリケーションを選択します。 - **Upload file (ファイルをアップロード)**​: ファイルシステムから Mule アプリケーションファイルを選択します。 6. **\[Deployment Target (デプロイメント対象)\]**​ ドロップダウンリストから、Runtime Fabric の名前を選択します。 7. **\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンリストから、Mule Runtime エンジンバージョンを選択します。 ![Mule Edge リリースドロップダウンウィンドウが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-rtm-mule-cadence.png) **\[Deployment Target (デプロイメント対象)\]**​ タブ、​**\[Ingress (イングレス)\]**​ タブ、​**\[Properties (プロパティ)\]**​ タブ、​**\[Logs (ログ)\]**​ タブ、​**\[JVM\]**​ タブが表示されます。これらのタブを使用して、アプリケーションの追加設定情報を入力します。 Runtime Fabric でサポートされる Mule Runtime バージョンについての詳細は、​[「Anypoint Runtime Fabric Patch Update Release Notes (Anypoint Runtime Fabric パッチ更新リリースノート)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 Mule アプリケーションは、標準サポートまたは延長サポート期間中の Mule Runtime Engine バージョンでデプロイできます。API または Runtime Manager UI でバージョンを指定します。EOL (サポート終了) 状態の Mule Runtime Engine バージョンでは、Mule アプリケーションを再デプロイして再起動することはできますが、新しい Mule アプリケーションをデプロイすることはできません。 ### [](#アプリケーションの公開エンドポイントを設定する)アプリケーションの公開エンドポイントを設定する Runtime Fabric にデプロイされたアプリケーションの公開エンドポイントを設定する手順は次のとおりです。 アプリケーションに使用可能なドメインおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。詳細は、​[「Use Custom Ingress Resource Templates in Runtime Fabric (Runtime Fabric でのカスタムイングレスリソーステンプレートの使用)」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​を参照してください。
ドメインを選択しない場合、アプリケーションは空のドメインにデプロイされます。
1. **\[Ingress (イングレス)\]**​ を選択します。 2. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 3. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 4. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![アプリケーションのエンドポイントのホストとパスが設定されます。](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-ingress-endpoint.png) 5. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 6. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 ### [](#複製およびストレージをセットアップする)複製およびストレージをセットアップする アプリケーションのエンドポイントを設定した後で、複製をセットアップしてデプロイするアプリケーションインスタンス数を設定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Mule アプリケーションのレプリカと再起動でデータの永続性を有効にするためにストレージに対するオブジェクトをセットアップします。 このオプションは、Mule Runtime Engine バージョン 4.2.1 以降でのみ使用できます。このオプションが使用できない場合は、IT 管理者にお問い合わせください。詳細は、​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/persistence-gateway)​を参照してください。 1. **\[Deployment Target (デプロイメント対象)\]**​ タブを選択します。 このタブには、以前に選択したデプロイメント対象の名前と種別が表示されます。 2. デプロイするアプリケーションのレプリカまたはインスタンスの数を選択します。 3. アプリケーションの各レプリカで Mule のクラスター化を有効にするには、​**\[Run in Runtime Clustering Mode (ランタイムのクラスター化モードで実行)\]**​ を有効にします。 4. 異なるノード間でレプリカのデプロイメントを適用するには、​**\[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)\]**​ を選択します。

ワーカーノードの数、または各レプリカをデプロイするために必要なワーカーノードで使用できるリソースが不十分な場合は、デプロイメントの一部のレプリカが ​[Pending (保留中)]​ 状況のままになります。異なるワーカーノードにすべてのレプリカがデプロイされると、デプロイメントの状況は ​[Running (実行中)]​ に移行します。
5. データの永続性を有効にするには、​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択します。 6. **\[Cores (コア)\]**​ の数と ​**\[Memory (メモリ)\]**​ の量を指定し、スライダーを適切な値に調整してアプリケーションの各レプリカに割り当てます。 必要に応じて、Runtime Fabric にデプロイするアプリケーションの​[リソース割り当てを決定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-resource-allocation-self-managed)​する方法を確認してください。 ### [](#省略可能-tlsv1-および-tlsv1-1-を有効にする)(省略可能) TLSv1 および TLSv1.1 を有効にする [2021 年 8 月 3 日のパッチリリース](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021)​以降、Mule Runtime ではすべてのランタイムバージョンで TLS v1 および TLS v1.1 がデフォルトで無効になります。アプリケーションを Runtime Fabric にデプロイするときに、JVM 引数を使用して TLS v1 または TLS v1.1 を有効にできます。 1. **\[JVM\]**​ タブをクリックします。 2. **\[Java Virtual Machine arguments (Java 仮想マシン引数)\]**​ 項目で、次のいずれかの引数を追加します。 - TLSv1.0 および TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.0+` - TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.1` ### [](#アプリケーションプロパティを設定する)アプリケーションプロパティを設定する

アプリケーションのプロパティ値を保護する手順については、​「Runtime Fabric でのアプリケーションのプロパティ値の保護」​を参照してください。
Runtime Manager を使用して、環境を指定したりパスワードとユーザー名を設定したりするなど、アプリケーションプロパティ値を設定します。 Runtime Fabric によって機密情報を公開することなくプロパティが実行時に解決されます。 1. **\[Properties (プロパティ)\]**​ タブをクリックします。 2. **\[Table view (テーブルビュー)\]**​ をクリックします。 3. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 4. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 5. 必要に応じて、プロパティを追加します。 ### [](#ログ記録とログレベルを設定する)ログ記録とログレベルを設定する Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションのログデータへのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Enable application logs (アプリケーションログを有効化)\]**​ オプションを選択します。 3. ドロップダウンリストからログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (警告)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 4. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ### [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができました。 1. アプリケーションをデプロイするには、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ボタンが無効な場合、有効な Mule アプリケーションファイルをアップロードしていることを確認します。また、選択した Mule Runtime エンジンのバージョンがアプリケーションで使用されているバージョンと同じであることも確認します。 _結果_​: Runtime Manager にアプリケーションのデプロイメントを確認する状況メッセージが表示されます。デプロイメントが開始されると、デプロイメントの状況を参照できるアプリケーションリストページが表示されます。 新しくデプロイされたアプリケーションの場合、最初の状況は ​**\[Starting (開始中)\]**​ と表示されます。アプリケーションが成功した場合、状況は ​**\[Started (開始済み)\]**​ に更新されます。アプリケーションの状況を監視し、正常に開始されたことを確認します。 ## [](#デプロイされたアプリケーションのインバウンドトラフィックを確認する)デプロイされたアプリケーションのインバウンドトラフィックを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```copy curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#継続的デプロイメントの設定)継続的デプロイメントの設定 Runtime Fabric でオンプレミスアプリケーションデプロイメントのワークフローをセットアップする方法は、​[「オンプレミス Runtime Fabric のワークフロー」](https://docs.mulesoft.com/jp/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc)​を参照してください。 ## [](#一般的な問題)一般的な問題 アプリケーションをデプロイするときに、次の問題が発生する場合があります。 - アプリケーションが数分間 ​**\[Starting (開始中)\]**​ 状況のままの場合、指定したリソース量が少なすぎることが原因の可能性があります。0.3 コア以下を選択した場合、アプリケーションの起動に数分かかることは一般的です。 - 起動時にアプリケーションでエラーが発生した場合、デプロイメントが停止し、状況は ​**\[Failed (失敗)\]**​ に更新されます。アプリケーションをクリックして右サイドバーを表示すると、エラーメッセージのプレビューが表示されます。メッセージ全体を表示するには、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 - Runtime Fabric にデプロイメントで使用可能な CPU コアまたはメモリがない場合、​`insufficient resources`​ を示すエラーメッセージが返されます。複数のレプリカを選択する場合、指定されたコアとメモリが​_各_​レプリカに適用されることを理解することが重要です。 - 既存の実行中のアプリケーションへの再デプロイメントが失敗した場合、以前のアプリケーションは実行中でアクティブなままになります。この動作により、ダウンタイムゼロのアプリケーションの再デプロイメントが可能になります。Runtime Manager では、失敗の解決に役立つ失敗したデプロイメントの詳細と状況が報告されます。 ## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/2.6/deploy-resource-allocation-self-managed) - [CloudHub に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [ハイブリッド環境への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) # Runtime Manager を使用した Runtime Fabric への Mule アプリケーションのデプロイ Mule アプリケーションを Anypoint Runtime Fabric の Mule Runtime サーバーにデプロイします。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションから分離された Runtime Fabric のインスタンスにデプロイされる必要があります。 アプリケーションをデプロイしたら、デプロイされたアプリケーションのインバウンドトラフィックをテストできます。 ## [](#runtime-fabric-に-mule-アプリケーションをデプロイする)Runtime Fabric に Mule アプリケーションをデプロイする デプロイメントプロセス全体には次の手順が含まれます。 1. アプリケーションとデプロイメント対象を選択する 2. デプロイメント対象を設定する 3. アプリケーションの公開エンドポイントを設定する 4. 複製をセットアップする 5. (省略可能) TLSv1 および TLSv1.1 を有効にする 6. アプリケーションプロパティを設定する 7. アプリケーションをデプロイする ### [](#前提条件)前提条件 アプリケーションを Anypoint Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric にアプリケーションをデプロイするのに必要な ​[Anypoint Platform のロールと権限](https://docs.mulesoft.com/jp/runtime-fabric/2.7/#anypoint-platform-roles-and-permissions)​を確認する。 - Runtime Fabric が環境に関連付けられていることを確認する。​[「ビジネスグループと環境の Anypoint Runtime Fabric への関連付け」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/associate-environments)​を参照してください。 - アプリケーションのリソース割り当て要件を決定する。詳細は、​[「Runtime Fabric でのアプリケーションリソース割り当ての決定」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-resource-allocation-self-managed)​を参照してください。 - アプリケーションを特定のドメイン (エンドポイント) にデプロイするには、環境にドメイン (エンドポイント) がセットアップされていることを確認する。​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​を参照してください。 - Red Hat OpenShift で Runtime Fabric を使用している場合は、​[「Prepare for Deploying Mule Apps to Red Hat OpenShift (Red Hat OpenShift に Mule アプリケーションをデプロイする準備をする)」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift)​の手順に従ってアプリケーションのデプロイメントを有効にしてください。 ### [](#アプリケーションとデプロイメント対象を選択する)アプリケーションとデプロイメント対象を選択する 1. [Anypoint Platform](https://anypoint.mulesoft.com)​ にサインインします。 2. **\[Runtime Manager\]**​ に移動し、​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Application Name (アプリケーション名)\]**​ 項目で、アプリケーションに名前を付けます。 名前に使用できるのは、小文字の英数字、ハイフン、およびアンダースコアのみです。 5. **\[Choose File (ファイルを選択)\]**​ をクリックしてデプロイするアプリケーションを選択し、次のいずれかのオプションを選択します。 - **Import file from Exchange (Exchange からファイルをインポート)**​: Anypoint Exchange に保存されている Mule アプリケーションを選択します。 - **Upload file (ファイルをアップロード)**​: ファイルシステムから Mule アプリケーションファイルを選択します。 6. **\[Deployment Target (デプロイメント対象)\]**​ ドロップダウンリストから、Runtime Fabric の名前を選択します。 7. **\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンリストから、Mule Runtime エンジンバージョンを選択します。 ![Mule Edge リリースドロップダウンウィンドウが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-rtm-mule-cadence.png) **\[Deployment Target (デプロイメント対象)\]**​ タブ、​**\[Ingress (イングレス)\]**​ タブ、​**\[Properties (プロパティ)\]**​ タブ、​**\[Logs (ログ)\]**​ タブ、​**\[JVM\]**​ タブが表示されます。これらのタブを使用して、アプリケーションの追加設定情報を入力します。 Runtime Fabric でサポートされる Mule Runtime バージョンについての詳細は、​[「Anypoint Runtime Fabric Patch Update Release Notes (Anypoint Runtime Fabric パッチ更新リリースノート)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 Mule アプリケーションは、標準サポートまたは延長サポート期間中の Mule Runtime Engine バージョンでデプロイできます。API または Runtime Manager UI でバージョンを指定します。EOL (サポート終了) 状態の Mule Runtime Engine バージョンでは、Mule アプリケーションを再デプロイして再起動することはできますが、新しい Mule アプリケーションをデプロイすることはできません。 ### [](#アプリケーションの公開エンドポイントを設定する)アプリケーションの公開エンドポイントを設定する Runtime Fabric にデプロイされたアプリケーションの公開エンドポイントを設定する手順は次のとおりです。 アプリケーションに使用可能なドメインおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。詳細は、​[「Use Custom Ingress Resource Templates in Runtime Fabric (Runtime Fabric でのカスタムイングレスリソーステンプレートの使用)」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​を参照してください。
ドメインを選択しない場合、アプリケーションは空のドメインにデプロイされます。
1. **\[Ingress (イングレス)\]**​ を選択します。 2. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 3. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 4. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![アプリケーションのエンドポイントのホストとパスが設定されます。](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-ingress-endpoint.png) 5. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 6. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 ### [](#複製およびストレージをセットアップする)複製およびストレージをセットアップする アプリケーションのエンドポイントを設定した後で、複製をセットアップしてデプロイするアプリケーションインスタンス数を設定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Mule アプリケーションのレプリカと再起動でデータの永続性を有効にするためにストレージに対するオブジェクトをセットアップします。 このオプションは、Mule Runtime Engine バージョン 4.2.1 以降でのみ使用できます。このオプションが使用できない場合は、IT 管理者にお問い合わせください。詳細は、​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/persistence-gateway)​を参照してください。 1. **\[Deployment Target (デプロイメント対象)\]**​ タブを選択します。 このタブには、以前に選択したデプロイメント対象の名前と種別が表示されます。 2. デプロイするアプリケーションのレプリカまたはインスタンスの数を選択します。 3. アプリケーションの各レプリカで Mule のクラスタリングを有効にするには、​**\[Run in Runtime Clustering Mode (ランタイムのクラスタリングモードで実行)\]**​ を有効にします。 4. 異なるノード間でレプリカのデプロイメントを適用するには、​**\[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)\]**​ を選択します。

ワーカーノードの数、または各レプリカをデプロイするために必要なワーカーノードで使用できるリソースが不十分な場合は、デプロイメントの一部のレプリカが ​[Pending (保留中)]​ 状況のままになります。異なるワーカーノードにすべてのレプリカがデプロイされると、デプロイメントの状況は ​[Running (実行中)]​ に移行します。
5. データの永続性を有効にするには、​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択します。 6. **\[Cores (コア)\]**​ の数と ​**\[Memory (メモリ)\]**​ の量を指定し、スライダーを適切な値に調整してアプリケーションの各レプリカに割り当てます。 必要に応じて、Runtime Fabric にデプロイするアプリケーションの​[リソース割り当てを決定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-resource-allocation-self-managed)​する方法を確認してください。 ### [](#省略可能-tlsv1-および-tlsv1-1-を有効にする)(省略可能) TLSv1 および TLSv1.1 を有効にする [2021 年 8 月 3 日のパッチリリース](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021)​以降、Mule Runtime ではすべてのランタイムバージョンで TLS v1 および TLS v1.1 がデフォルトで無効になります。アプリケーションを Runtime Fabric にデプロイするときに、JVM 引数を使用して TLS v1 または TLS v1.1 を有効にできます。 1. **\[JVM\]**​ タブをクリックします。 2. **\[Java Virtual Machine arguments (Java 仮想マシン引数)\]**​ 項目で、次のいずれかの引数を追加します。 - TLSv1.0 および TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.0+` - TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.1` ### [](#アプリケーションプロパティを設定する)アプリケーションプロパティを設定する

アプリケーションのプロパティ値を保護する手順については、​「Runtime Fabric でのアプリケーションのプロパティ値の保護」​を参照してください。
Runtime Manager を使用して、環境を指定したりパスワードとユーザー名を設定したりするなど、アプリケーションプロパティ値を設定します。 Runtime Fabric によって機密情報を公開することなくプロパティが実行時に解決されます。 1. **\[Properties (プロパティ)\]**​ タブをクリックします。 2. **\[Table view (テーブルビュー)\]**​ をクリックします。 3. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 4. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 5. 必要に応じて、プロパティを追加します。 ### [](#ログ記録とログレベルを設定する)ログ記録とログレベルを設定する Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションのログデータへのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Enable application logs (アプリケーションログを有効化)\]**​ オプションを選択します。 3. ドロップダウンリストからログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 4. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ### [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができました。 1. アプリケーションをデプロイするには、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ボタンが無効な場合、有効な Mule アプリケーションファイルをアップロードしていることを確認します。また、選択した Mule Runtime エンジンのバージョンがアプリケーションで使用されているバージョンと同じであることも確認します。 _結果_​: Runtime Manager にアプリケーションのデプロイメントを確認する状況メッセージが表示されます。デプロイメントが開始されると、デプロイメントの状況を参照できるアプリケーションリストページが表示されます。 新しくデプロイされたアプリケーションの場合、最初の状況は ​**\[Starting (開始中)\]**​ と表示されます。アプリケーションが成功した場合、状況は ​**\[Started (開始済み)\]**​ に更新されます。アプリケーションの状況を監視し、正常に開始されたことを確認します。 ## [](#デプロイされたアプリケーションのインバウンドトラフィックを確認する)デプロイされたアプリケーションのインバウンドトラフィックを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```copy curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#継続的デプロイメントの設定)継続的デプロイメントの設定 Runtime Fabric でオンプレミスアプリケーションデプロイメントのワークフローをセットアップする方法は、​[「オンプレミス Runtime Fabric のワークフロー」](https://docs.mulesoft.com/jp/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc)​を参照してください。 ## [](#一般的な問題)一般的な問題 アプリケーションをデプロイするときに、次の問題が発生する場合があります。 - アプリケーションが数分間 ​**\[Starting (開始中)\]**​ 状況のままの場合、指定したリソース量が少なすぎることが原因の可能性があります。0.3 コア以下を選択した場合、アプリケーションの起動に数分かかることは一般的です。 - 起動時にアプリケーションでエラーが発生した場合、デプロイメントが停止し、状況は ​**\[Failed (失敗)\]**​ に更新されます。アプリケーションをクリックして右サイドバーを表示すると、エラーメッセージのプレビューが表示されます。メッセージ全体を表示するには、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 - Runtime Fabric にデプロイメントで使用可能な CPU コアまたはメモリがない場合、​`insufficient resources`​ を示すエラーメッセージが返されます。複数のレプリカを選択する場合、指定されたコアとメモリが​_各_​レプリカに適用されることを理解することが重要です。 - 既存の実行中のアプリケーションへの再デプロイメントが失敗した場合、以前のアプリケーションは実行中でアクティブなままになります。この動作により、ダウンタイムゼロのアプリケーションの再デプロイメントが可能になります。Runtime Manager では、失敗の解決に役立つ失敗したデプロイメントの詳細と状況が報告されます。 ## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/2.7/deploy-resource-allocation-self-managed) - [CloudHub に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [ハイブリッド環境への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) # Runtime Manager を使用した Runtime Fabric への Mule アプリケーションのデプロイ Mule アプリケーションを Anypoint Runtime Fabric の Mule Runtime サーバーにデプロイします。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションから分離された Runtime Fabric のインスタンスにデプロイされる必要があります。 アプリケーションをデプロイしたら、デプロイされたアプリケーションのインバウンドトラフィックをテストできます。
Unresolved include directive in modules/ROOT/pages/deploy-to-runtime-fabric.adoc - include::cloudhub-2::partial$caveats.adoc[]
## [](#runtime-fabric-に-mule-アプリケーションをデプロイする)Runtime Fabric に Mule アプリケーションをデプロイする デプロイメントプロセス全体には次の手順が含まれます。 1. アプリケーションとデプロイメント対象を選択する 2. デプロイメント対象を設定する 3. アプリケーションの公開エンドポイントを設定する 4. 複製をセットアップする 5. (省略可能) TLSv1 および TLSv1.1 を有効にする 6. アプリケーションプロパティを設定する 7. アプリケーションをデプロイする ### [](#前提条件)前提条件 アプリケーションを Anypoint Runtime Fabric にデプロイする前に、次のことを実行します。 - Runtime Fabric にアプリケーションをデプロイするのに必要な ​[Anypoint Platform のロールと権限](https://docs.mulesoft.com/jp/runtime-fabric/2.8/#anypoint-platform-roles-and-permissions)​を確認する。 - Runtime Fabric が環境に関連付けられていることを確認する。​[「ビジネスグループと環境の Anypoint Runtime Fabric への関連付け」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/associate-environments)​を参照してください。 - アプリケーションのリソース割り当て要件を決定する。詳細は、​[「Runtime Fabric でのアプリケーションリソース割り当ての決定」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-resource-allocation-self-managed)​を参照してください。 - アプリケーションを特定のドメイン (エンドポイント) にデプロイするには、環境にドメイン (エンドポイント) がセットアップされていることを確認する。​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​を参照してください。 - Red Hat OpenShift で Runtime Fabric を使用している場合は、​[「Prepare for Deploying Mule Apps to Red Hat OpenShift (Red Hat OpenShift に Mule アプリケーションをデプロイする準備をする)」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-openshift#prepare-for-deploying-mule-apps-to-red-hat-openshift)​の手順に従ってアプリケーションのデプロイメントを有効にしてください。 ### [](#アプリケーションとデプロイメント対象を選択する)アプリケーションとデプロイメント対象を選択する 1. [Anypoint Platform](https://anypoint.mulesoft.com)​ にサインインします。 2. **\[Runtime Manager\]**​ に移動し、​**\[Applications (アプリケーション)\]**​ を選択します。 3. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 4. **\[Application Name (アプリケーション名)\]**​ 項目で、アプリケーションに名前を付けます。 名前に使用できるのは、小文字の英数字、ハイフン、およびアンダースコアのみです。 5. **\[Choose File (ファイルを選択)\]**​ をクリックしてデプロイするアプリケーションを選択し、次のいずれかのオプションを選択します。 - **Import file from Exchange (Exchange からファイルをインポート)**​: Anypoint Exchange に保存されている Mule アプリケーションを選択します。 - **Upload file (ファイルをアップロード)**​: ファイルシステムから Mule アプリケーションファイルを選択します。 6. **\[Deployment Target (デプロイメント対象)\]**​ ドロップダウンリストから、Runtime Fabric の名前を選択します。 7. **\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンリストから、Mule Runtime エンジンバージョンを選択します。 ![Mule Edge リリースドロップダウンウィンドウが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-rtm-mule-cadence.png) **\[Deployment Target (デプロイメント対象)\]**​ タブ、​**\[Ingress (イングレス)\]**​ タブ、​**\[Properties (プロパティ)\]**​ タブ、​**\[Logs (ログ)\]**​ タブ、​**\[JVM\]**​ タブが表示されます。これらのタブを使用して、アプリケーションの追加設定情報を入力します。 Runtime Fabric でサポートされる Mule Runtime バージョンについての詳細は、​[「Anypoint Runtime Fabric Patch Update Release Notes (Anypoint Runtime Fabric パッチ更新リリースノート)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。 Mule アプリケーションは、標準サポートまたは延長サポート期間中の Mule Runtime Engine バージョンでデプロイできます。API または Runtime Manager UI でバージョンを指定します。EOL (サポート終了) 状態の Mule Runtime Engine バージョンでは、Mule アプリケーションを再デプロイして再起動することはできますが、新しい Mule アプリケーションをデプロイすることはできません。 ### [](#アプリケーションの公開エンドポイントを設定する)アプリケーションの公開エンドポイントを設定する Runtime Fabric にデプロイされたアプリケーションの公開エンドポイントを設定する手順は次のとおりです。 アプリケーションに使用可能なドメインおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。詳細は、​[「Use Custom Ingress Resource Templates in Runtime Fabric (Runtime Fabric でのカスタムイングレスリソーステンプレートの使用)」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​を参照してください。
ドメインを選択しない場合、アプリケーションは空のドメインにデプロイされます。
1. **\[Ingress (イングレス)\]**​ を選択します。 2. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 3. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 4. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![アプリケーションのエンドポイントのホストとパスが設定されます。](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-ingress-endpoint.png) 5. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 6. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 ### [](#複製およびストレージをセットアップする)複製およびストレージをセットアップする アプリケーションのエンドポイントを設定した後で、複製をセットアップしてデプロイするアプリケーションインスタンス数を設定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Mule アプリケーションのレプリカと再起動でデータの永続性を有効にするためにストレージに対するオブジェクトをセットアップします。 このオプションは、Mule Runtime Engine バージョン 4.2.1 以降でのみ使用できます。このオプションが使用できない場合は、IT 管理者にお問い合わせください。詳細は、​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/persistence-gateway)​を参照してください。 1. **\[Deployment Target (デプロイメント対象)\]**​ タブを選択します。 このタブには、以前に選択したデプロイメント対象の名前と種別が表示されます。 2. デプロイするアプリケーションのレプリカまたはインスタンスの数を選択します。 3. アプリケーションの各レプリカで Mule のクラスタリングを有効にするには、​**\[Run in Runtime Clustering Mode (ランタイムのクラスタリングモードで実行)\]**​ を有効にします。 4. 異なるノード間でレプリカのデプロイメントを適用するには、​**\[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)\]**​ を選択します。

ワーカーノードの数、または各レプリカをデプロイするために必要なワーカーノードで使用できるリソースが不十分な場合は、デプロイメントの一部のレプリカが ​[Pending (保留中)]​ 状況のままになります。異なるワーカーノードにすべてのレプリカがデプロイされると、デプロイメントの状況は ​[Running (実行中)]​ に移行します。
5. データの永続性を有効にするには、​**\[Use Persistent Object Storage (永続オブジェクトストレージを使用)\]**​ を選択します。 6. **\[Cores (コア)\]**​ の数と ​**\[Memory (メモリ)\]**​ の量を指定し、スライダーを適切な値に調整してアプリケーションの各レプリカに割り当てます。 必要に応じて、Runtime Fabric にデプロイするアプリケーションの​[リソース割り当てを決定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-resource-allocation-self-managed)​する方法を確認してください。 ### [](#省略可能-tlsv1-および-tlsv1-1-を有効にする)(省略可能) TLSv1 および TLSv1.1 を有効にする [2021 年 8 月 3 日のパッチリリース](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes#august-3-2021)​以降、Mule Runtime ではすべてのランタイムバージョンで TLS v1 および TLS v1.1 がデフォルトで無効になります。アプリケーションを Runtime Fabric にデプロイするときに、JVM 引数を使用して TLS v1 または TLS v1.1 を有効にできます。 1. **\[JVM\]**​ タブをクリックします。 2. **\[Java Virtual Machine arguments (Java 仮想マシン引数)\]**​ 項目で、次のいずれかの引数を追加します。 - TLSv1.0 および TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.0+` - TLSv1.1 を有効にする: `-Drtf.allow.TLSv1.1` ### [](#アプリケーションプロパティを設定する)アプリケーションプロパティを設定する

アプリケーションのプロパティ値を保護する手順については、​「Runtime Fabric でのアプリケーションのプロパティ値の保護」​を参照してください。
Runtime Manager を使用して、環境を指定したりパスワードとユーザー名を設定したりするなど、アプリケーションプロパティ値を設定します。 Runtime Fabric によって機密情報を公開することなくプロパティが実行時に解決されます。 1. **\[Properties (プロパティ)\]**​ タブをクリックします。 2. **\[Table view (テーブルビュー)\]**​ をクリックします。 3. **\[New Key (新しいキー)\]**​ 項目で、保護するプロパティを追加します。 4. **\[New Value (新しい値)\]**​ 項目で、値を追加します。 5. 必要に応じて、プロパティを追加します。 ### [](#ログ記録とログレベルを設定する)ログ記録とログレベルを設定する Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションのログデータへのアクセスが提供されます。Anypoint Monitoring を使用してログにアクセスするには、 [Titanium サブスクリプション](https://www.mulesoft.com/anypoint-pricing)​が必要です。 Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Enable application logs (アプリケーションログを有効化)\]**​ オプションを選択します。 3. ドロップダウンリストからログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 4. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ### [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができました。 1. アプリケーションをデプロイするには、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ボタンが無効な場合、有効な Mule アプリケーションファイルをアップロードしていることを確認します。また、選択した Mule Runtime エンジンのバージョンがアプリケーションで使用されているバージョンと同じであることも確認します。 _結果_​: Runtime Manager にアプリケーションのデプロイメントを確認する状況メッセージが表示されます。デプロイメントが開始されると、デプロイメントの状況を参照できるアプリケーションリストページが表示されます。 新しくデプロイされたアプリケーションの場合、最初の状況は ​**\[Starting (開始中)\]**​ と表示されます。アプリケーションが成功した場合、状況は ​**\[Started (開始済み)\]**​ に更新されます。アプリケーションの状況を監視し、正常に開始されたことを確認します。 ## [](#デプロイされたアプリケーションのインバウンドトラフィックを確認する)デプロイされたアプリケーションのインバウンドトラフィックを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```copy curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```copy curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#継続的デプロイメントの設定)継続的デプロイメントの設定 Runtime Fabric でオンプレミスアプリケーションデプロイメントのワークフローをセットアップする方法は、​[「オンプレミス Runtime Fabric のワークフロー」](https://docs.mulesoft.com/jp/runtime-manager/continuous-deployment#workflow-for-on-premises-runtime-fabric.adoc)​を参照してください。 ## [](#一般的な問題)一般的な問題 アプリケーションをデプロイするときに、次の問題が発生する場合があります。 - アプリケーションが数分間 ​**\[Starting (開始中)\]**​ 状況のままの場合、指定したリソース量が少なすぎることが原因の可能性があります。0.3 コア以下を選択した場合、アプリケーションの起動に数分かかることは一般的です。 - 起動時にアプリケーションでエラーが発生した場合、デプロイメントが停止し、状況は ​**\[Failed (失敗)\]**​ に更新されます。アプリケーションをクリックして右サイドバーを表示すると、エラーメッセージのプレビューが表示されます。メッセージ全体を表示するには、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックします。 - Runtime Fabric にデプロイメントで使用可能な CPU コアまたはメモリがない場合、​`insufficient resources`​ を示すエラーメッセージが返されます。複数のレプリカを選択する場合、指定されたコアとメモリが​_各_​レプリカに適用されることを理解することが重要です。 - 既存の実行中のアプリケーションへの再デプロイメントが失敗した場合、以前のアプリケーションは実行中でアクティブなままになります。この動作により、ダウンタイムゼロのアプリケーションの再デプロイメントが可能になります。Runtime Manager では、失敗の解決に役立つ失敗したデプロイメントの詳細と状況が報告されます。 ## [](#関連情報)関連情報 - [Runtime Fabric でのアプリケーションリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/2.8/deploy-resource-allocation-self-managed) - [CloudHub に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/cloudhub/developing-applications-for-cloudhub) - [ハイブリッド環境への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers) # VM/ベアメタルの Runtime Fabric VM/ベアメタルの Anypoint Runtime Fabric は、クラスターを形成する一連の VM で構成されます。各 VM サービスは、コントローラーノードまたはワーカーノードのいずれかとして機能します。 ![2 つのワーカーにリンクされたコントローラーの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-controller-worker.png) - コントローラー: オーケストレーションサービス、分散型データベース、負荷分散、および Anypoint Platform からクラスターを管理できるサービスを含む、Runtime Fabric の運用専用の VM。 - ワーカー: Mule アプリケーションと API ゲートウェイの実行専用の VM。Mule アプリケーションと API プロキシはワーカーで動作します。 この責務の分離により、Mule アプリケーションの数に基づいてワーカーノードを拡張できます。また、デプロイメントの頻度、アプリケーションの状態の変化、およびインバウンドトラフィックの量に基づいて、コントローラーノードを拡張することもできます。ハードウェア障害が発生した場合にリソースを使用可能にしてアプリケーションを再スケジュールおよび再デプロイするため、ワーカーノードの数を多めにプロビジョニングすることをお勧めします。 デフォルトでは、Runtime Fabric を運用するサービスは、システム内で障害が 1 か所に集中することを防ぐためにコントローラーノード全体にデプロイされます。 VM/ベアメタルの Anypoint Runtime Fabric は、Mule Runtime で適切に動作するように調整された一連のテクノロジー (Docker や Kubernetes など) を使用します。Mule を Runtime Fabric にデプロイしたり管理したりするために、これらのテクノロジーに関する知識は必要ありません。Runtime Fabric の管理には、あらゆる規模のシステムをサポートするために必要な運用レベルおよびインフラストラクチャレベルの経験が必要です。予期せぬ障害に備えて、ベストプラクティスに従い、制御された環境で演習シナリオを実行することをお勧めします。
Anypoint Runtime Fabric での Mule が提供していないアプリケーションやゲートウェイのデプロイメントはサポートされていません。
## [](#開発設定と本番設定)開発設定と本番設定 VM/ベアメタルの Anypoint Runtime Fabric は、開発設定と本番設定をサポートしています。これらのサポート対象設定で、最小限必要なノードとリソースを指定します。 ### [](#開発設定)開発設定 開発設定はテストのみを目的としています。少なくとも 1 つのコントローラーと 2 つのワーカーノードが必要です。コントローラーノードは、Anypoint Platform への接続に使用される内部ロードバランサーとエージェントを実行します。エージェントと Anypoint Platform 間の通信は常にアウトバウンドです。アプリケーションの複数のレプリカを複数のワーカーで実行できます。 ![コントローラー (内部ロードバランサーやエージェントなど) とワーカーが含まれる MuleSoft コントロールプレーンのネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-development.png) ### [](#本番設定)本番設定 ![コントロールプレーン、コントローラー (内部ロードバランサーやエージェントなど)、ワーカー、TCP ロードバランサーが含まれる Mule 開発の図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-production.png) コントローラーのみが、Anypoint Platform への接続に使用される内部ロードバランサーとエージェントを実行します。 エージェントは任意のコントローラーで実行できます。エージェントの通信は常にアウトバウンドです。 最小要件は、3 つのコントローラーと 3 つのワーカーノードです。3 つのコントローラーにより、1 つのコントローラーが失われた場合のフォールトトレランスが可能になります。2 つのコントローラーが失われた場合のフォールトトレランスを可能にするには、合計 5 つのコントローラーを設定する必要があります。 Mule アプリケーションはワーカーで実行されます。アプリケーションの複数のレプリカを複数のワーカーで実行できます。 ## [](#ネットワークアーキテクチャ)ネットワークアーキテクチャ 次の図は、VM/ベアメタルの Runtime Fabric の一般的なネットワークアーキテクチャを示しています。 ![コントローラーの内部ロードバランサーとワーカーが含まれる Runtime Fabric と TCP ロードバランサーの接続のネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-network.png) この図は、コントローラーで実行される内部ロードバランサー間で要求を負荷分散するために使用される、TCP ロードバランサーを示しています。また、ワーカーで実行される Mule アプリケーションの各レプリカに要求を分散する内部ロードバランサーも示しています。 内部ロードバランサーを有効化すると、次のモードがサポートされます。 - **共有モード** VM/ベアメタルの Runtime Fabric で専用の内部ロードバランサーノードを追加していない場合のデフォルト設定です。このモードでは、内部ロードバランサーは指定された量の CPU およびメモリを備えたすべてのコントローラーノードで実行されます。 - **Dedicated Mode (専用モード)** VM/ベアメタルの Runtime Fabric で専用の内部ロードバランサーノードが 1 個以上使用可能な場合のみ有効になります。専用の内部ロードバランサーノードでは、内部ロードバランサーを実行するためにすべての使用可能なリソースが使用されるため、CPU コアとメモリの量を指定できません。 インバウンドトラフィック負荷が高い場合は専用ノードが必要です。自分の環境で専用ノードが必要であるかどうかを判断するには、​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 ![要求 ping が含まれる Runtime Fabric と TCP ロードバランサーの接続のネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-network2.png) 1. 受信 HTTP 要求は外部 TCP ロードバランサーに転送されます。 2. TCP ロードバランサーは、Runtime Fabric で使用可能な内部ロードバランサーに要求を転送します。 3. 内部ロードバランサーは要求を復号化し、上の図の Mule アプリケーション (app2) の使用可能なレプリカに転送します。 4. アプリケーションはリクエスターに返送される応答を送信します。 ## [](#runtime-fabric-と他の-paas-プロバイダー)Runtime Fabric と他の PaaS プロバイダー VM/ベアメタルの Anypoint Runtime Fabric には、必要なすべてのコンポーネントが含まれています。これらのコンポーネント (Docker や Kubernetes など) は、Mule Runtime や他の MuleSoft サービスと効率的に連携するように最適化されています。
既存の Kubernetes ベースの PaaS 内で VM/ベアメタルの Anypoint Runtime Fabric をインストールすることはできません。この状況では、​自己管理型 Kubernetes の Runtime Fabric ​を使用することを検討してください。
PaaS ソリューションをすでに使用している場合、PaaS と平行して VM/ベアメタルの Runtime Fabric をデプロイすることをお勧めします。これにより、Anypoint Platform のすべての利点を活用できます。 ## [](#vmベアメタルの-anypoint-runtime-fabric-の共有責任)VM/ベアメタルの Anypoint Runtime Fabric の共有責任 VM/ベアメタルの Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が管理する必要のある領域と MuleSoft によって管理される領域を理解することが重要です。Runtime Fabric は、必要なインフラストラクチャとメンテナンスが確保された場合にのみ正常に機能します。 オンプレミスの Runtime Fabric インスタンスにおける MuleSoft とお客様の共有責任の様子を下図に示します。 ![Runtime Fabric の共有責任](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/runtimefabricresponsibility.png) - MuleSoft の責任: MuleSoft は、Runtime Fabric アプライアンスを管理し、提供されたコンポーネント、Runtime Fabric アプライアンス、Runtime Fabric エージェント、Mule Runtime Engine、および Mule アプリケーションの他の連動関係に対する責任を負います。 - お客様の責任: お客様は、VM/ベアメタルの Runtime Fabric で必要なインフラストラクチャのプロビジョニング、設定、管理の責任を負います。 - インフラストラクチャには如何含まれます。 - VM リソース (CPU、メモリ) - ディスクのパフォーマンスと容量 - オペレーティングシステムとカーネルのパッチ - ネットワークポート - すべての VM 間のシステム時間の同期 - インフラストラクチャのプロビジョニングと管理では、組織の次のチームによる補助が必要になります。 - DevOps チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 詳細は、​[「VM/ベアメタルの Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​を参照してください。 ## [](#anypoint-management-center-への-runtime-fabric-の接続)Anypoint Management Center への Runtime Fabric の接続 Anypoint Runtime Fabric では、次の操作がサポートされています。 - Anypoint Runtime Manager からアプリケーションをデプロイする。 - API Manager を使用して API ゲートウェイのポリシーの更新をデプロイする。 - Anypoint Exchange でアセットを保存および取得する。 Anypoint Management Center とのインテグレーションを有効にするには、Runtime Fabric にポート 443 での Anypoint Platform へのアウトバウンドアクセス権が必要です。この接続は、相互 TLS を使用して保護されます。コントローラー VM で実行される一連のサービスは、アウトバウンド接続を開始して、アプリケーションをデプロイするために必要なメタデータとアセットを取得します。次に、これらのサービスは他の内部サービスを解釈してそれらと通信し、アセットをローカルにキャッシュしてアプリケーションをデプロイします。
組織のネットワークから必要なアウトバウンド接続を有効にする方法については、ネットワーク管理者にお問い合わせください。
# VM/ベアメタルの Runtime Fabric インストールの前提条件 VM/ベアメタルの Runtime Fabric をインストールする前に、このトピックの情報を参照してインストールする準備が整っていることを確認します。 ## [](#始める前に)始める前に
VM/ベアメタルの Runtime Fabric でのインストールの問題のほとんどは、不適切なインフラストラクチャのプロビジョニングまたは設定が原因です。
VM/ベアメタルの Runtime Fabric をインストールする前に、以下を完了してください。 - [「VM/ベアメタルの Runtime Fabric の共有責任」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal#shared-responsibility-for-on-premises-runtime-fabric)​を参照する。 インフラストラクチャがハードウェア、オペレーティングシステム、ネットワークの最小要件を満たしていない場合、Runtime Fabric は正常に動作できません。 - VM/ベアメタルの Runtime Fabric で次のメンバーがタスクを実行する。 - DevOps チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによるポートの許可リストへの追加とプロキシの設定 - セキュリティチームによるコンプライアンスの確認とセキュリティ証明書の取得 組織のこれらのチームと共同で作業を行うことにより、インストールを成功に導き、パフォーマンスや密集の問題を回避することができます。 - VM/ベアメタルの Runtime Fabric をインストールする前に、このトピックの要件を確認して、すべての前提条件が満たされていることを確認する。 最小要件が満たされていない場合、インストールプロセスは失敗します。 開発設定と本番設定の説明は、​[「VM/ベアメタルの Anypoint Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal)​を参照してください。 必要に応じて、MuleSoft の担当者に連絡してサポートを要求してください。 ## [](#一般的なインストール要件)一般的なインストール要件 VM/ベアメタルの Runtime Fabric をインストールするには、次の分野の知識が必要です。 - Linux システムコマンド - ルートアクセス権による Linux の操作。インストールには、環境内のすべてのサーバーでルートアクセス (​`sudo`​ コマンドを実行するための権限) が必要です - Terraform の操作 (Amazon Web Services (AWS) で実行する場合) - SSL や SSH などのリモート接続メカニズム 以下を計画します。 - 本番と本番以外のアプリケーションで別々の Runtime Fabric を作成する - DMZ と非公開ネットワークなど、環境のネットワークスコープに基づいて別々の Runtime Fabric を作成する - Runtime Fabric のデフォルトのポッドおよびサービスの CIDR ブロックがリージョンネットワークに干渉しないようにする ## [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 Runtime Fabric を適切に使用するには、Anypoint Platform アカウントで次のロールと権限が有効になっている必要があります。 - アプリケーションをデプロイして管理するには、Anypoint Runtime Manager を使用するための権限が必要です。アプリケーションをデプロイするには、Anypoint Platform アカウントで「Exchange Contributors (Exchange コントリビュータ)」ロールも有効にする必要があります。 - Anypoint Platform ユーザーの権限を管理するには、Anypoint Access Management を使用するための権限が必要です。 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」ロールまたは「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ## [](#インフラストラクチャ要件)インフラストラクチャ要件 次のアクションを実行します。 - スワップメモリを無効化します。 - chrony (システムクロック) 状況が同期していることを確認します。 - ウイルス対策アプリケーションやディープパケットインスペクション (DPI) ソフトウェアなどの特定のサードパーティソフトウェアパッケージを使用すると、Runtime Fabric アプライアンスの特定の機能に影響する可能性があります。詳細は、​[「ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-limitations#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)​を参照してください。 - 必要なハードウェアをプロビジョニングするか、インフラストラクチャプロバイダーを使用して必要なハードウェアを作成するのに十分なクォータを確保します。 - x86 または x64 アーキテクチャ。x86 および x64 アーキテクチャのみがサポートされています。 - 仮想マシン - プロビジョニングされた IOPS を備えるディスク - 仮想ネットワーク - ファイアウォールおよびセキュリティグループ - ロードバランサー - AWS または Azure を使用してハードウェアをプロビジョニングする場合、必要なリソースを作成するための適切な権限が必要です。
最適なパフォーマンスを確保するには、専用ディスクが必要です。必要なディスクはインストール中に VM/ベアメタルの Runtime Fabric インストーラーによってフォーマットおよびマウントされます。
AWS および Azure プロビジョニングスクリプトのデフォルトの動作では、最小要件によって定義された一連の仮想マシンとディスクが作成されます。また、必要なネットワークポートが設定されたプライベートネットワークも作成されます。これは、プライマリネットワーク内に統合する前に VM/ベアメタルの Runtime Fabric を評価する場合に最適です。デフォルトの動作に互換性があるかどうかを判断するには、ネットワーク管理者にお問い合わせください。組織の要件に合わせてプロビジョニングスクリプトの変更が必要な場合があります。 - ログを組織のログプロバイダーに転送する方法を理解します。 - アラートを設定できるように組織の SMTP プロバイダーの情報を取得します。 - 次のネットワーク項目を確認します。 - アウトバウンド接続がプロキシにルーティングされる。 - アウトバウンドアクセスは、Anypoint Platform に対して websockets (ポート 443 経由) を使用して許可される。 - 組織のネットワークおよびセキュリティポリシー (以下を含む) - CIDR 表記の内部ネットワーク IP アドレス範囲 - Runtime Fabric で使用される CIDR 表記のサブネット範囲 - 公開 IP アドレス (仮想マシンが許可されている場合) - 各 VM へのシェルアクセスの取得方法 - 組織の Mule アプリケーションの機能に応じて、VM/ベアメタルの Runtime Fabric でインバウンドトラフィックを有効化するかどうかを決めます。 インバウンドトラフィックを有効化する場合は、ネットワークのトラフィックを評価して、インバウンドロードバランサー用に専用ノードを設定する必要があるかどうかを決めてください。詳細は、​[「ネットワーク設定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal#network-architecture)​と​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 ## [](#オペレーティングシステム要件)オペレーティングシステム要件 各 Runtime Fabric ノードで同じオペレーティングシステムを使用します。別のオペレーティングシステムバージョンまたはディストリビューションに VM/ベアメタルの Runtime Fabric をインストールしようとすると、インストーラーは失敗します。 VM/ベアメタルの Runtime Fabric には、次のいずれかのオペレーティングシステムが必要です。 - Red Hat (RHEL) - v7.4 ～ v7.9 - v8.0 ～ v8.3 - v8.4 (Runtime Fabric アプライアンスバージョン 1.1.1636064094-8b70d2d 以降を使用) - v8.6 (Runtime Fabric アプライアンスバージョン 1.1.1660253001-ab8f5e5 以降を使用) - CentOS - v7.4 ～ v7.9

CentOS 8 は サービス終了​になっています。代替のオペレーティングシステムを使用することを検討してください。
- Ubuntu v18.04 (Runtime Fabric アプライアンスバージョン 1.1.1625094374-7058b20 以降を使用) - Ubuntu 20.04

コントロールグループ (cgroups) のメモリリークに関する既知の問題があり、その問題により RHEL や CentOS 7 でポッドの作成が失敗したりノードが誤動作したりする可能性があります。詳細は、 ナレッジベース記事​を参照してください。

この問題を回避するには、VM/ベアメタルの Runtime Fabric インストールで RHEL または CentOS 8.x を使用してください。
## [](#ネットワークおよびポートの要件)ネットワークおよびポートの要件 VM/ベアメタルの Runtime Fabric のインストールと操作には、特定のネットワークとポート設定が必要です。

VM/ベアメタルの Runtime Fabric では、クロスリージョンデプロイメントはサポートされていません。各ノード間のネットワークレイテンシーによりクラスターの健全性の問題が発生する可能性があります。
### [](#帯域幅要件)帯域幅要件 高帯域幅ネットワークが必要であり、VM/ベアメタルの Runtime Fabric を操作する各ノード間には 1 GBps 以上の接続、インターネットへのアウトバウンド接続には 100 MBps 以上が必要です。 Runtime Fabric と Anypoint コントロールプレーン間のトラフィックボリュームの例については、次の点を考慮してください。 - Mule Runtime 4.3.0 のイメージは 740 MB です。 - Runtime Fabric アプライアンスのアップグレードには 1.5 GB が必要です。アプライアンスのアップグレードプロセスには、本番サイズのクラスター (3 つのコントローラーと 3 つのワーカー) の場合、約 30 分かかります。 ### [](#必須のポート設定)必須のポート設定 以下のセクションで、VM/ベアメタルの Runtime Fabric の TCP および UDP ネットワークポートの要件を示します。 #### [](#インストール中に使用するポート)インストール中に使用するポート 次の表に、すべてのノードでアクセスできる必要があるポートを示します。これらのポートは、インストール中にノード間の内部通信で使用されます。インストールが完了したら、これらのポートを安全に無効にできます。
Table 1. インストールで必要なポート
ポート プロトコル 説明

4242

TCP

帯域幅チェッカー

61008-61010

TCP

インストール中に使用

61022-61024

TCP

インストーラーエージェントのポート
#### [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/persistence-gateway)​を参照してください。 #### [](#ネットワーク-tcp-および-udp-ポート)ネットワーク TCP および UDP ポート 次の表に、開く必要があるすべてのポートと、使用されるそれぞれのプロトコルおよび要求の実行元と宛先を示します。
Table 2. TCP と UDP で必要なポート
ポート レイヤー 4 プロトコル レイヤー 5 プロトコル ソース 宛先 説明

123

UDP

NTP

すべてのノード

インターネット

ネットワークタイムプロトコルを介した時計の同期

443

TCP

HTTPS

API コンシューマー

コントローラーノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

コントローラーノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer

5044 (非推奨)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer

このポートとホスト名は Anypoint Runtime Fabric のバージョン 1.8.50 以降で非推奨になっています。​

以前のバージョンの Anypoint Runtime Fabric を使用している場合、このポートとホスト名を許可リストに追加する必要があります。それより新しいバージョンを使用している場合は、上で指定したポートとホスト名を使用してください。これは、US と EU の両方のクラウドのエンドポイントに適用されます。

53

TCP

DNS

localhost

localhost

内部クラスター DNS

2379、2380、4001、7001

TCP

HTTPS

すべてのノード

コントローラーノード

etcd サーバー通信

3008、3010、3011、3012

TCP

HTTPS/gRPC

すべてのノード

すべてのノード

Anypoint Runtime Fabric 内部サービス

3009

TCP

HTTPS

すべてのノード

内部ネットワーク

Anypoint Runtime Fabric 内部オペレーションセンター

3022 ～ 3025

TCP

SSH

すべてのノード

すべてのノード

内部 SSH コントロールサービス

3080

TCP

HTTPS

すべてのノード

コントローラーノード

Anypoint Runtime Fabric 内部オペレーションセンター

5000

TCP

HTTPS

すべてのノード

コントローラーノード

内部コンテナレジストリ

6060

TCP

HTTPS/gRPC

すべてのノード

すべてのノード

Anypoint Runtime Fabric 内部サービス

6443、8080

TCP

HTTPS/HTTP

すべてのノード

コントローラーノード

Kubernetes API サーバー

7373

TCP

RPC

localhost

localhost

ピアツーピア接続用の Serf RPC

7496

TCP

HTTPS

すべてのノード

すべてのノード

Serf (状態チェックエージェント)/ピアツーピア接続

7575

TCP

gRPC

すべてのノード

すべてのノード

クラスターの状況 API

10248-10250

TCP

HTTPS

すべてのノード

すべてのノード

Kubernetes コンポーネント

10255

TCP

HTTPS

すべてのノード

すべてのノード

Kubernetes コンポーネント

30000-32767

TCP

アプリケーション固有

すべてのノード

すべてのノード

要求をアプリケーションにルーティングするために使用される内部サービスポート範囲

32009

TCP

HTTPS

内部ネットワーク

コントローラーノード

Anypoint Runtime Fabric オペレーションセンター

32009

TCP

HTTPS

コントローラーノード

すべてのノード

オペレーションセンター内部 API

53

UDP

DNS

localhost

localhost

内部クラスター DNS

7496

UDP

HTTPS

すべてのノード

すべてのノード

Serf (状態チェックエージェント)/ピアツーピア接続

8472

UDP

VXLAN

すべてのノード

すべてのノード

オーバーレイネットワーク

30000-32767

UDP

アプリケーション固有

すべてのノード

すべてのノード

要求をアプリケーションにルーティングするために使用される内部サービスポート範囲
### [](#port-ip-addresses-and-hostnames-to-add-to-the-allowlist)ポートの IP アドレスとホスト名の許可リストへの追加 ネットワーク設定で、Anypoint Platform コンポーネントとサービスのホスト名とポートを許可リストに追加し、Anypoint Runtime Fabric がそれらと通信できるようにする必要があります。これは、インストールおよびアップグレード中に連動関係をダウンロードするためにも必要になります。 次の表に、Anypoint Runtime Fabric と Anypoint Platform 間の通信を許可するための許可リストに追加するポートとホスト名を示します。

次の表には、API Manager のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​API Manager のドキュメント​を参照してください。
次のエンドポイントは相互 TLS 認証を使用しているため、接続を確立するためには、次の証明書を許可するための SSL パススルーを設定する必要があります。 - US コントロールプレーン - `transport-layer.prod.cloudhub.io` - `configuration-resolver.prod.cloudhub.io` - EU コントロールプレーン - `transport-layer.prod-eu.msap.io` - `configuration-resolver.prod-eu.msap.io`
ポート プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-router.us-east-1.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-router.eu-central-1.prod-eu.msap.io

Runtime Fabric 用の Anypoint Monitoring エージェント。

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

kubernetes-charts.storage.googleapis.com

Kubernetes ベースチャートリポジトリ。

443

HTTPS

docker-images-prod.s3.amazonaws.com

Kubernetes ベースチャートリポジトリ。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com ​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com ​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: ecr.us-east-1.amazonaws.com​

  • EU コントロールプレーン: ecr.eu-central-1.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​。

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: api.ecr.us-east-1.amazonaws.com​

  • EU コントロールプレーン: api.ecr.eu-central-1.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​ または ​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​ または ​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​。

  • EU コントロールプレーン: runtime-fabric-eu.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
### [](#必須のネットワーク設定)必須のネットワーク設定 前述のポート要件に加えて、VM/ベアメタルの Runtime Fabric を操作するには次のネットワーク設定が必要です。 - 他の VM を VM/ベアメタルの Runtime Fabric に追加するための割り当て可能な十分な IP アドレスを持つサブネット。
ポッドの CIDR ブロックが、ポッドまたはサービスが通信のために使用する IP アドレスと重複することはできません。クラスター内のサービスまたはノードにインストールしたサービスが、ポッドまたはサービスの CIDR ブロックと重複する IP 範囲を使用して通信する必要がある場合、競合が発生する可能性があります。CIDR ブロックが使用中であり、その IP アドレスをポッドまたはサービスが通信のために使用していない場合、競合はありません。複数のクラスターをデプロイする場合、各クラスターで同じ IP 範囲を再利用できます。これは、そのアドレスがクラスターノード内に存在し、クラスター間の通信が外部インターフェースで中継されるためです。
- VM/ベアメタルの Runtime Fabric をインストールするために使用する各 VM へのシェル/SSH アクセス。 - 各 VM に割り当てられた静的な非公開 IPv4 アドレス。再起動間で保持されます。 - 内部 Kubernetes 負荷分散を有効にするカーネル IP 転送。インストール中、各 VM で IPv4 転送が有効になります。 - ホスト Linux カーネルがホストされているコンテナとの間でパケットを双方向に変換できるようにするブリッジネット検索条件。このカーネルモジュールは、インストール中に各 VM で有効になります。 - VM/ベアメタルの Runtime Fabric によってトリガーされるメールアラートを管理する SMTP サーバーへのアクセス。 - 各コントローラー VM で実行されている内部ロードバランサーへの外部要求のバランスを取る外部ロードバランサー - インターネットへの発信要求をプロキシ経由でルーティングする必要がある場合、環境の HTTP プロキシ設定 - インターネットへの発信要求をプロキシ経由でルーティングする必要がある場合、Anypoint Monitoring および Visualizer の SOCKS5 プロキシのサポート
VMWare を使用していて、既存のアプリケーションに接続できないまたは新規アプリケーションをデプロイできない場合、MuleSoft ナレッジベースで 「RTF Networking Issues with VMware (VMware での RTF ネットワークの問題)」​を参照してください。
## [](#mule-ライセンス)Mule ライセンス Mule アプリケーションや API プロキシをデプロイするには、組織の ​[Mule ライセンスファイル](https://docs.mulesoft.com/on-premises/latest/installing-an-enterprise-license)​へのアクセス権が必要です。 ## [](#インストール要件)インストール要件 インストール中、インストールパッケージはインストールのリーダーとして機能するコントローラー VM にダウンロードされます。 VM/ベアメタルの Runtime Fabric は、複数の仮想マシンにわたるクラスターとして実行するように設定されています。各 VM は、次のロールのいずれかとして動作します。 - コントローラー VM。Runtime Fabric サービスの運用および実行専用です。内部ロードバランサーはコントローラー VM 内で実行されます。 - ワーカー VM。Mule アプリケーションの実行専用です。 1 つのコントローラー VM がインストール中にリーダーとして機能します。この VM は、インストーラーをダウンロードし、ポート 32009 で他の各 VM にアクセスできるようにします。他の VM はリーダーからインストーラーファイルをコピーしてインストールを実行し、リーダーに参加してクラスターを形成します。 インストール中、一連のプリフライトチェックが実行され、Runtime Fabric のハードウェア、オペレーティングシステム、およびネットワークの最小要件が検証されます。これらの要件が満たされていない場合、インストーラーは失敗します。 インストールプロセスは、次の手順の組み合わせです。 - AWS および Azure の場合、システム要件に従ってインフラストラクチャをプロビジョニングする - VM 全体で Runtime Fabric をインストールする - Anypoint 組織で Runtime Fabric をアクティブ化する。 - 組織の Mule Enterprise ライセンスをインストールする 前記の手順を完了するには、インストールの開始時に各 VM の環境変数を指定します。Mule ライセンスをアクティブ化して追加するには、リーダーに追加の変数が必要です。スクリプトが各 VM で実行され、次のアクションが実行されます。 - 各専用ディスクをフォーマットしてマウントする。 - 各ディスクのマウントエントリを ​`/etc/fstab`​ に追加する。 - iptable ルールを追加する。 - 必要なカーネルモジュールを有効にする。 - インストールを開始する。 インストールのリーダーであるコントローラー VM で次のアクションが実行されます。 - インストール後にアクティベーションスクリプトを実行する。 - 登録後に Mule ライセンス挿入スクリプトを実行する。 ## [](#本番設定要件)本番設定要件 VM/ベアメタルの Runtime Fabric の本番設定では、次の図で示すように少なくとも 6 個のノードが必要です。 ![コントロールプレーン、コントローラー (内部ロードバランサーやエージェントなど)、ワーカー、TCP ロードバランサーが含まれる Mule 開発の図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-production.png) 以下のセクションでは、本番設定でのコントローラーノードとワーカーノードの最小システム要件について説明します。
VM/ベアメタルの Runtime Fabric では、バースト可能な VM を使用したコントローラーノードの実行はサポートされません。アプリケーションをワーカーノードにデプロイする場合、バースト用に vCPU を割り当てることができます。詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。
### [](#コントローラーノード)コントローラーノード 本番環境で必要なコントローラーノードの最小数は 3 です。この要件は、高可用性を維持し、システムパフォーマンスを確保するための最小要件を反映しています。 フォールトトレランスを確保するには、奇数のコントローラーノードが必要です。偶数個のコントローラーノードはサポートされていません。 サポートされるコントローラーノードの最大数は 5 です。 各コントローラーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 8 GiB のメモリ。 コントローラーノードのサイズを変更する場合、内部ロードバランサーに必要なリソース量を検討する必要があります。詳細は、​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​のリソースの割り当てを参照してください。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - etcd 分散型データベースを実行するためにプロビジョニングされた最小 3000 IOPS を備えた最小 60 GiB の専用ディスク。これは、最小で 12 メガバイト/秒 (MBps) のディスクの読み書きパフォーマンスに変換されます。 - このディスクは、​`etcd`​ デバイスと呼ばれます。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた 1000 IOPS を備えた最小 250 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 - このディスクは、​`docker`​ デバイスと呼ばれます。 #### [](#スケーリングの考慮事項)スケーリングの考慮事項 次のような状況では、コントローラーノードの数をスケールすることを検討してください。 - コントローラーノードのハードウェア障害の影響を軽減するためにフォールトトレランスが必要である。3 つのコントローラーノードを最小要件とすることで、1 つのコントローラーが失われた場合のフォールトトレランスが可能になります。2 つのコントローラーが失われた場合のフォールトトレランスを可能にするには、合計 5 つのコントローラーを設定する必要があります。 - VM/ベアメタルの Runtime Fabric で実行されているアプリケーションで本番トラフィックが処理されている。 ### [](#ワーカーノード)ワーカーノード VM/ベアメタルの Runtime Fabric は、Mule アプリケーションと API ゲートウェイを実行するために少なくとも 3 個のワーカーノードを必要とします。 サポートされるワーカーノードの最大数は 16 です。 ノードが使用できなくなった場合 (フォールトトレランス) や、再起動を必要とするメンテナンス操作中 (OS パッチの適用など) にアップタイムを維持するには、1 つ以上の追加のワーカーノードをプロビジョニングします。 これにより、ワーカーノードをクラスターから安全に削除して、アプリケーションの可用性に影響を及ぼすことなくアップグレードを適用できます。

Runtime Fabric は、内部サービス用としてワーカーノードごとに最大 0.5 個のコアを予約できます。これは、必要な CPU コアおよびワーカーノードの量を決定する場合に重要です。

たとえば、Runtime Fabric で 3 個のワーカーノードとそれぞれのワーカーノードについて 2 個の CPU コアを使用することもできます。Runtime Fabric でワーカーノードあたり 0.3 個のコア、合計 0.9 個のコアを予約している場合、Runtime Manager に表示される使用可能なコア数は 6 個の vCPU ではなく 5.1 個の vCPU です。
各ワーカーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 15 GiB のメモリ。 Runtime Fabric で実行する Mule およびトークナイザーの数や、デプロイするためにどのようなライセンスを付与するのかを検討する必要があります。オーバーヘッドのためにワーカーノードあたり約 0.5 コアを計画します。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた最小 1000 IOPS を備えた最小 250 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 250 GiB あれば、アプリケーションを実行し、Docker イメージをキャッシュして、アプリケーションを実行するための一時ストレージを提供し、ログストレージを提供するのに十分な領域を確保できます。 ### [](#本番環境の追加のリソース要件)本番環境の追加のリソース要件 VM/ベアメタルの Runtime Fabric を本番環境で使用する場合: - 各コントローラー VM で実行されている内部ロードバランサーに外部要求の負荷を分散するように外部ロードバランサーを設定し、TCP ポート 443 の状態チェックを設定する必要があります。各コントローラーノードで構成されるサーバープールを使用した TCP ロードバランサーで十分です。 - 可用性を維持するため、内部ロードバランサーを 3 個以上のレプリカで実行します。 - インバウンド要求を処理するアプリケーションは 2 個以上のレプリカに拡大する必要があります。 ## [](#開発設定要件)開発設定要件 開発環境では、VM/ベアメタルの Runtime Fabric は、次の図で示すように最小 3 個のノードを必要とします。 ![コントローラー (内部ロードバランサーやエージェントなど) とワーカーが含まれる MuleSoft コントロールプレーンのネットワーク開発アーキテクチャの図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/architecture-development.png)
VM/ベアメタルの Runtime Fabric では、バースト可能な VM を使用したコントローラーノードの実行はサポートされません。アプリケーションをワーカーノードにデプロイする場合、バースト用に vCPU を割り当てることができます。 詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。
以下のセクションでは、開発設定での各コントローラーノードとワーカーノードの最小システム要件について説明します。 ### [](#コントローラーノード-2)コントローラーノード 本番以外の環境で必要なコントローラーノードの最小数は 1 です。偶数個のコントローラーはサポートされていません。1 つのコントローラーのクラスターでは、etcd データベースが破損したときに復元できません。たとえば、 [このナレッジ記事](https://help.salesforce.com/s/articleView?id=001121251&type=1)​に記載された問題がそれに該当します。 サポートされるコントローラーノードの最大数は 5 です。 各コントローラーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 8 GiB のメモリ。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - etcd 用にプロビジョニングされた 3000 IOPS を備えた最小 60 GiB の専用ディスク。これは、最小で 12 メガバイト/秒 (MBps) のディスクの読み書きパフォーマンスに変換されます。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた 1000 IOPS を備えた最小 100 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 ### [](#ワーカーノード-2)ワーカーノード VM/ベアメタルの Runtime Fabric は、Mule アプリケーションと API ゲートウェイを実行するために少なくとも 2 個のワーカーノードを必要とします。 サポートされるワーカーノードの最大数は 16 です。 ノードが使用できなくなった場合 (フォールトトレランス) や、再起動を必要とするメンテナンス操作中 (OS パッチの適用など) にアップタイムを維持するには、1 つ以上の追加のワーカーノードをプロビジョニングします。 これにより、ワーカーノードをクラスターから安全に削除して、アプリケーションの可用性に影響を及ぼすことなくアップグレードを適用できます。

Runtime Fabric は、内部サービス用としてワーカーノードごとに最大 0.5 個のコアを予約できます。これは、必要な CPU コアおよびワーカーノードの量を決定する場合に重要です。

たとえば、Runtime Fabric で 3 個のワーカーノードとそれぞれのワーカーノードについて 2 個の CPU コアを使用することもできます。Runtime Fabric でワーカーノードあたり 0.3 個のコア、合計 0.9 個のコアを予約している場合、Runtime Manager に表示される使用可能なコア数は 6 個の vCPU ではなく 5.1 個の vCPU です。
各ワーカーノードには以下のリソースが必要です。 - 最小 2 個の専用コア。 - 最小 15 GiB のメモリ。 - 最小 80 GiB のオペレーティングシステム専用ディスク。 - `/tmp`​ ディレクトリ用に最小 20 GiB。​`/tmp`​ ディレクトリには参照、書き込み、実行可能権限が必要です。 - `/opt/anypoint/runtimefabric`​ ディレクトリ用に最小 8 GiB。 - `/var/log/`​ ディレクトリ用に最小 1 GiB。 - Docker オーバーレイおよびその他の内部サービス用にプロビジョニングされた最小 1000 IOPS を備えた最小 100 GiB の専用ディスク。これは、最小で 4 MBps のディスクの読み書きパフォーマンスに変換されます。 100 GiB あれば、アプリケーションを実行し、Docker イメージをキャッシュして、アプリケーションを実行するための一時ストレージを提供し、ログストレージを提供するのに十分な領域を確保できます。 # VM/ベアメタルの Runtime Fabric からのノード追加または削除 VM/ベアメタルの Runtime Fabric を使用する場合、Runtime Fabric からノードを追加および削除できます。ノードの追加または削除が必要になる場合があるシナリオを以下に示します。 - ノードを追加して Runtime Fabric をスケールアップする。 - ノードを削除または追加して、Runtime Fabric の健全性と安定性を確保する。 - ノードを削除し、OS パッチを実行した後、ノードを Runtime Fabric に再度追加する。
オペレーションセンター UI からのノードの追加はサポートされていません。Runtime Fabric 似新しいノードを追加するには、次の手順を使用してください。
## [](#runtime-fabric-へのノードの追加)Runtime Fabric へのノードの追加 ノードを追加する前に、新しいノードのインフラストラクチャをプロビジョニングします。クラスターに参加できるようにするには、新しいノードが Runtime Fabric インストールと同じネットワーク上に存在する必要があります。 ### [](#始める前に)始める前に 新しいノードを追加する前に、次を確認してください。 - [「Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​で示されているとおりに、必要なハードウェアをプロビジョニングしている。 - 必要なディスクを各 VM のブロックデバイスとしてリストしている。ディスクをマウントまたはフォーマットしないでください。 完全なディスク要件については、​[「本番設定要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs#production-configuration-requirements)​または​[「開発設定要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs#development-configuration-requirements)​を参照してください。 - [「ネットワークおよびポートの要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs#network-and-port-requirements)​で示されているとおりに、必要なポートを開いてホスト名を許可リストに追加している。 - 環境で実行されているすべてのウイルス対策エージェント (McAfee など) を無効にしている。 新しいノードを追加する手順は、次のとおりです。 1. 新しいノードの仮想マシンで ​`/opt/anypoint/runtimefabric`​ ディレクトリを作成します。 mkdir -p /opt/anypoint/runtimefabric 2. `init.sh`​ インストールスクリプトを新しいノードの ​`/opt/anypoint/runtimefabric`​ ディレクトリの下にコピーします。 このスクリプトは、Runtime Fabric のインストール時にダウンロードしたファイルに含まれます。 3. 環境ファイルを既存のノードの ​`/opt/anypoint/runtimefabric`​ ディレクトリから新しいノードの同じディレクトリにコピーします。 環境ファイルを正しいノード種別 (コントローラーまたはワーカー) からコピーしたことを確認します。 4. 正しいノード種別で必要とされるパラメーターのみを含めるように、コピーした環境ファイルを変更します。 - ワーカーノードパラメーター 次の例は、ワーカーノードで必要とされる環境パラメーターを示しています。コピーしたファイルの ​`RTF_DOCKER_DEVICE_SIZE`​、​`RTF_TOKEN`​、および ​`RTF_INSTALLER_IP`​ の値を使用します。​`RTF_DOCKER_DEVICE`​ では、​`device_name`​ を適切な値に置き換えます。 - `RTF_NODE_ROLE=worker_node` - `RTF_INSTALL_ROLE=joiner` - `RTF_DOCKER_DEVICE=/dev/device_name` - `RTF_TOKEN="R6J4UR6J4UR6J4UO"` - `RTF_INSTALLER_IP="10.0.42.86"` - RTF\_ACTIVATION\_DATA​ が存在する場合は削除する。 - コントローラーノードパラメーター 次の例は、コントローラーノードで必要とされる環境パラメーターを示しています。コピーしたファイルの ​`RTF_DOCKER_DEVICE_SIZE`​、​`RTF_TOKEN`​、および ​`RTF_ETCD_DEVICE`​ の値を使用します。​`RTF_DOCKER_DEVICE`​ では、​`device_name`​ を適切な値に置き換えます。​`RTF_INSTALLER_IP`​ では、リードコントローラーノードの IP アドレスを指定します。 - `RTF_NODE_ROLE=controller_node` - `RTF_INSTALL_ROLE=joiner` - `RTF_DOCKER_DEVICE=/dev/device_name` - `RTF_TOKEN="R6J4UR6J4UR6J4UO"` - `RTF_ETCD_DEVICE=/dev/etcd_device` - `RTF_INSTALLER_IP="10.1.255.93"` - RTF\_ACTIVATION\_DATA​ が存在する場合は削除する - 専用ノードパラメーター 次の例は、ロードバランサーノードで必要とされる環境パラメーターを示しています。環境ファイルをコントローラーノードからコピーした場合、例に示されている行を除き、ファイルのすべての行を削除します。コピーしたファイルの ​`RTF_DOCKER_DEVICE_SIZE`​ および ​`RTF_TOKEN`​ の値を使用します。​`RTF_DOCKER_DEVICE`​ では、​`device_name`​ を適切な値に置き換えます。​`RTF_INSTALLER_IP`​ では、リードコントローラーノードの IP アドレスを指定します。 - `RTF_NODE_ROLE=dedicated_ingress_node` - `RTF_INSTALL_ROLE=joiner` - `RTF_DOCKER_DEVICE=/dev/device_name` - `RTF_DOCKER_DEVICE_SIZE=50G` - `RTF_TOKEN="R6J4UR6J4UR6J4Uy"` - `RTF_INSTALLER_IP="10.1.255.93"` 5. 新しいノードで特権ユーザーとして ​`init.sh`​ スクリプトを実行します。このスクリプトを実行する場合、実行可能権限の追加が必要になる場合があります。 sudo chmod +x ./init.sh このスクリプトにより、新しいノードが Runtime Fabric クラスターに参加します。 6. 新しいノードが Runtime Fabric に追加されたことを確認します。 sudo gravity status 専用の内部ロードバランサーノードがクラスターに追加されている場合、インバウンドトラフィックを有効にすると、専用ノードを指定するオプションが提供されます。専用ノードでは、CPU コアおよびメモリの量を指定できません。 ## [](#runtime-fabric-からのノードの削除)Runtime Fabric からのノードの削除 Runtime Fabric クラスターから​**コントローラー**​ノードを削除するには、次のコマンドを実行します。 sudo kubectl drain sudo gravity leave Runtime Fabric クラスターから​**ワーカー**​ノードを削除するには、次のコマンドを実行します。 sudo gravity leave このコマンドは、ノードで実行されているすべての Runtime Fabric サービスをシャットダウンします。また、すべてのソフトウェアとデータが削除されます。 成功した場合、このコマンドは、開始された削除操作の ID を出力します。次のコマンドを使用して、このコマンドの進行状況を監視できます。 gravity status `sudo gravity leave`​ を使用してノードを削除できない場合、​`--force`​ オプションを使用してコマンドを再度実行することが必要になる場合があります。次のコマンドを実行して、ノードをリモートで削除することもできます。 sudo kubectl drain sudo gravity remove ``​ は、削除するノードを示します。これには、ノードに割り当てられたホスト名またはその IP アドレスのいずれかを指定できます。 # VM/ベアメタルの Runtime Fabric でのプロキシの管理 Anypoint Runtime Fabric クラスターは、Anypoint Platform コントロールプレーンおよびイメージリポジトリと継続的に通信します。クラスターにデプロイされているアプリケーションも、外部エンドポイントと通信できます。 インターネットへの Runtime Fabric アウトバウンド接続で使用するプロキシ設定を設定できます。これには、Anypoint コントロールプレーンに接続するための HTTP プロキシと、メトリクスとログを Anypoint Monitoring に送信するための SOCKS5 プロキシの両方が含まれます。アプリケーションのプロキシを設定することもできます。 Runtime Fabric で使用するプロキシは、インストール中またはインストール後に ​`rtfctl`​ ユーティリティを使用して設定できます。アプリケーションプロキシは、アプリケーションのデプロイ中に設定します。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のプロキシ設定を管理するには、​`rtfctl`​ コマンドラインツールが必要です。プロキシ設定を行う前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​する手順を実行します。

rtfctl apply proxy​ コマンドを実行する前に Runtime Fabric をインストールする必要があります。
## [](#configure-proxy)Anypoint Monitoring プロキシを設定する 監視エージェントは SOCKS5 プロキシを使用するため、Anypoint Monitoring を使用する場合は 2 つのプロキシ種別が必要です。 SOCKS5 プロキシは、次のエンドポイントで TCP 経由で Anypoint Monitoring に接続する必要があります。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io`
このステップは、コントローラーノードで 1 回だけ実行します。
1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 sudo /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" - ****​: SOCKS5 プロキシの認証に必要なユーザー名。 - ****​: SOCKS5 プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.2>**​: SOCKS5 プロキシへのアクセスに使用される IP アドレスまたはホスト名。 - **<8080>**​: SOCKS5 プロキシが要求をリスンするホストのポート。 3. 変更が成功したことを確認するには、次のコマンドを実行して、監視プロキシの現在の値を出力します。 sudo /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy 出力は期待される値と一致する必要があります。 ## [](#configure-http-proxy)Runtime Fabric のサービス用に HTTP プロキシを設定する アウトバウンドコンポーネントがコントロールプレーンと通信できるように HTTP プロキシと HTTPS プロキシを設定できます。 HTTP プロキシを更新すると、クラスター内の各マシンは、マシンで実行されているすべてのポッドを再起動します。複数のレプリカを実行している場合、ダウンタイムは発生しませんが、メンテナンスウィンドウ中に HTTP プロキシの更新を実行する必要があります。 - Runtime Fabric 内で実行されているサービスにプロキシの値を適用する。 - Runtime Fabric インストーラー 1.0.x を使用している場合は、Runtime Fabric の各ノードでスクリプトを実行してクラスターを更新する。
これらのステップは、1 つのコントローラーノードで 1 回実行します。
1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" - ****​: HTTP プロキシの認証に必要なユーザー名。 - ****​: HTTP プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.1>**​: HTTP プロキシにアクセスするための IP アドレスまたはホスト名を指定します。 - **<8080>**​: HTTP プロキシが要求をリスンするホストのポートを指定します。 - **<1.1.1.1:8888,2.2.2.2:9999>**​: カンマで区切られた ​`RTF_NO_PROXY`​ ホストとポートを指定します。 - (省略可能) ​`--confirm`​: 変更の手動の肯定応答をスキップします。指定しなかった場合、​`rtfctl apply proxy`​ コマンドでは、続行する前に変更を確認することが求められます。 3. 変更が成功したことを確認するには、次のコマンドを実行して、HTTP プロキシの現在の値を出力します。 sudo /opt/anypoint/runtimefabric/rtfctl get http-proxy 出力は期待される値と一致する必要があります。 4. プロキシ値を削除するには、次のコマンドを実行します。 sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ### [](#http_proxy-環境変数について)HTTP\_PROXY​ 環境変数について Runtime Fabric のサービスにプロキシを適用したら、次のような警告が表示される場合があります。 Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric で [この警告](https://help.mulesoft.com/s/article/Warning-Proxy-configurations-in-the-environment-HTTP-PROXY-does-not-match-configurations-in-Runtime-Fabric)​が生成されるのは、​`HTTP_PROXY`​ 環境変数を設定していないこと、または変数が Runtime Fabric サービスに使用される値と一致しないことを知らせるためです。これらの設定は必ずしも一致している必要はありませんが、Runtime Fabric ではサービスが影響を受ける可能性もあることを知らせるために警告が生成されます。 多くの Linux ツールでは ​`HTTP_PROXY`​ 環境変数を使用してそのプロキシ設定を提供しています。環境にインターネットアクセス用のプロキシが必要な場合、インターネットアクセスが必要なコマンド用に ​`HTTP_PROXY`​ 環境変数を設定する必要がある可能性が高くなります。 これにより、​`kubectl`​ のように HTTP または HTTPS 操作を使用するがインターネットアクセスが不要な他のツールに影響する可能性もあります。​`NO_PROXY`​ 環境変数を使用して、プロキシする必要がない接続を確立できます。 環境変数によるそのプロキシの動作に対する影響に関する詳細は、Linux ツールのドキュメントを参照してください。 ### [](#no_proxy-環境変数について)NO\_PROXY​ 環境変数について デフォルトでは、​`NO_PROXY`​ は ​`0.0.0.0/0`​ と ​`.local`​ に設定されます。これらの設定により、プロキシで IPV4 宛先アドレスが転送されなくなります。 ## [](#configure-proxy-api)API Manager エージェントのプロキシを設定する プロキシを使用して、API Manager で管理する Mule アプリケーション用の通信を確立できます。すべてのアプリケーションに同じ設定を使用している場合でも、このプロキシ設定は各 Mule アプリケーションで定義する必要があります。この設定はアプリケーションが他の外部エンドポイントと通信するために使用するアプリケーションレベルのプロキシとは無関係です。 API Manager エージェントのプロキシを設定するには、次のプロパティをアプリケーションに追加します。 anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## [](#configure-proxy-mule-app)Mule アプリケーション用のプロキシの設定 Runtime Fabric でデプロイされるアプリケーションは、Runtime Fabric クラスターからプロキシ設定を継承しません。各アプリケーションでプロキシを設定する必要があります。 各コネクタ (HTTP リクエスターなど) でプロキシをセットアップするか、または次の例に示すようにアプリケーションのプロパティでプロキシをセットアップすることができます。アプリケーションで多くのコネクタを使用する場合は、アプリケーションのプロパティでプロキシを設定した方が楽です。 http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true ## [](#関連情報)関連情報 - [Runtime Fabric コマンドラインツールの使用](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl) - [Anypoint Runtime Fabric インストールの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs) # VM/ベアメタルの Runtime Fabric でのリソース割り当てとパフォーマンス Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。 Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。 このトピックで提供されるパフォーマンス情報は、AWS EC2 M4 インスタンスを使用するコントローラーノードが含まれる Runtime Fabric クラスターに基づきます。クラスターは、3 個の m4.large コントローラーノードと 3 個の r4.large ワーカーノードを使用して設定されています。M4 インスタンスは EC2 専用に最適化されたカスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを搭載しています。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。使用される負荷ジェネレーターは、同じリージョンの別の AWS インスタンスでホストされます。 アプリケーションのデプロイ時に次のリソースを割り当てることができます。 - vCPU コア - `Reserved vCPU` アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。 - `vCPU Limit` アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。 - Memory (メモリ) ## [](#mulesoft-ライセンスコンプライアンス)MuleSoft ライセンスコンプライアンス お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。 1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。 2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。 予約済み vCPU と vCPU 制限を追跡する方法は、 [「How to Get Runtime Fabric (RTF) CPU Reserved and Limit for Self Managed Kubernetes and RTF Appliance (自己管理型 Kubernetes と RTF アプライアンスでの予約済み Runtime Fabric (RTF) CPU および制限の取得方法)」](https://help.mulesoft.com/s/article/How-to-Get-Runtime-Fabric-RTF-CPU-Reserved-and-Limit-for-Self-Managed-Kubernetes-and-RTF-Appliance)​を参照してください。 使用状況を監視して、使用量がライセンス量を超えた場合にアラートを受け取る方法は、 [MuleSoft ナレッジベースの「Cronjob Script to Monitor RTF Appliance CPU of Mule Apps (Mule アプリケーションの RTF アプライアンス CPU を監視するための Cronjob スクリプト)」](https://help.mulesoft.com/s/article/Cronjob-Script-to-Monitor-RTF-Appliance-CPU-of-Mule-Apps)​を参照してください。 ## [](#vcpu-の割り当て)vCPU の割り当て \[​`Reserved vCPU`​ (予約済み vCPU)\] と \[​`vCPU Limit`​ (vCPU 制限)\] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。 CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。 \[​`vCPU Limit`​ (vCPU 制限)\] の値が \[​`Reserved vCPU`​ (予約済み vCPU)\] の値よりも高く設定されていると、アプリケーションは、\[vCPU limit (vCPU 制限)\] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。 ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。これらのコアとメモリの割り当ては Mule のライセンスには使用されません。 ## [](#cpu-バースト)CPU バースト CPU バーストを使用するときは、次の要素を考慮する必要があります。 - 最小予約済み vCPU: 0.02 vCPU。 - vCPU の下限: 0.07 vCPU。 大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。 - CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。 - 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。 - Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。 - 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 50Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。 - 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。 - アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。 どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。 ## [](#メモリの割り当て)メモリの割り当て Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。 - 0.7 GB メモリ (Mule 4) - 0.5 GB メモリ (Mule 3) Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。 ## [](#cloudhub-および-runtime-fabric-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。 CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。 - Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。 使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。 - CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。 ## [](#アプリケーションの起動時間)アプリケーションの起動時間 Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。
vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分
## [](#アプリケーションのパフォーマンス)アプリケーションのパフォーマンス Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。
vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。
## [](#内部ロードバランサーのメモリの割り当て)内部ロードバランサーのメモリの割り当て 内部ロードバランサーのメモリ要件は、スレッド数、応答時間のレイテンシー、およびメッセージサイズの影響を受けます。メモリを割り当てる場合は次のガイドラインを使用してください。 - .5 GB (デフォルト): アクティブな同時接続数が 500 件未満の場合。 - 1.5 GB (大): 次のいずれかまたは両方のシナリオの場合。 - アクティブな同時接続数が 500 件以上。 - セキュリティポリシーが有効になっている。
これは一般的なガイドラインであり、個々の環境で調整が必要になる場合があります。
## [](#内部ロードバランサー)内部ロードバランサー インバウンドトラフィックは、Anypoint Runtime Fabric によって管理される内部ロードバランサーを使用して処理されます。このロードバランサーは TLS の終了を担当するため、必要なリソースの数は受信接続の数と各要求の平均ペイロードサイズに基づいて調整されます。 パフォーマンステストの結果は、AWS EC2 M4 インスタンスを使用するコントローラーノードが含まれる Runtime Fabric クラスターに基づきます。クラスターは、3 個の m4.large コントローラーノードと 3 個の r4.large ワーカーノードを使用して設定されています。パフォーマンステストで使用された負荷ジェネレーターは、同じリージョンの別の AWS インスタンスでホストされました。M4 インスタンスは EC2 専用に最適化されたカスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを搭載しており、2.4 GHz のベースクロックレートで実行されました。Intel Turbo Boost を使用すると、クロックレートが 3.0 GHz まで上昇しました。 SSL 接続の効率がより高い C++ ベースの負荷ジェネレーターを使用して、最大のスループットを実現しました。 次の表には、CPU コアの数に基づいて、内部ロードバランサーの 1 つのレプリカで処理できるおおよその要求数 (平均 10 KB) がまとめられています。ほとんどの場合、Elliptical Curve Digital Signature Algorithm (ECDSA) のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、secp521r1 (P-521)、secp384r1 (P-384)、secp256r1 (prime256v1 (P-256) とも呼ばれる) です。
Key Type (キー種別) CPU TLS (接続の再利用なし) TLS (接続の再利用あり)

RSA 2K

0.25

94 メッセージ/秒

1100 メッセージ/秒

RSA 2K

0.5

189 メッセージ/秒

2250 メッセージ/秒

RSA 2K

1

380 メッセージ/秒

4000 メッセージ/秒

RSA 4K*

0.25

14 メッセージ/秒

1048 メッセージ/秒

RSA 4K*

0.5

30 メッセージ/秒

2087 メッセージ/秒

RSA 4K*

1

59 メッセージ/秒

3700 メッセージ/秒

ECDSA P-256

0.25

234 メッセージ/秒

1150 メッセージ/秒

ECDSA P-256

0.5

451 メッセージ/秒

2257 メッセージ/秒

ECDSA P-256

1

860 メッセージ/秒

4100 メッセージ/秒
\*RSA キーの長さを 2 倍にすると、パフォーマンスが 6 倍以上低下します。
内部ロードバランサーは、Runtime Fabric のコントローラー VM で実行されます。インバウンドトラフィックの量と種別に基づいて、VM のサイズを設定します。内部ロードバランサーに割り当てることができるのは、各 VM で使用可能な CPU コアの半分のみです。
## [](#キーと証明書の-cpu-要件)キーと証明書の CPU 要件 最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。
コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8
## [](#キー種別)キー種別 RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。 - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (prime256v1 (P-256) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/1.13/view-health) # VM/ベアメタルの Runtime Fabric のアップグレード

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
VM/ベアメタルの Anypoint Runtime Fabric をアップグレードするには、Runtime Fabric アプライアンス、コンポーネント、​`rtfctl`​ コマンドラインユーティリティ、ノード設定をアップグレードします。 ## [](#アプライアンスのアップグレードについて)アプライアンスのアップグレードについて アプライアンスのアップグレードは、Docker、Kubernetes、オペレーションセンターを含むプラットフォームレイヤーコンポーネントに影響します。このプラットフォームレイヤーコンポーネントは、クラスターのノードとして機能する仮想マシン (VM) またはベアメタルサーバーにインストールされます。 アプライアンスのアップグレードは、​`rtfctl`​ コマンドラインユーティリティを使用して適用されます。 アプライアンスのアップグレードは 1 ノードずつ各ノードに適用されます。この​_ローリングアップグレード_​プロセスにより、3 個以上のコントローラーノードをアクティブなままにしてクラスターの可用性を確実に維持することで、実行中のアプリケーションへの影響を最小限に抑えます。また、このプロセスにより、各ワーカーノードをオフラインにしてアップグレードするときにアプリケーションを再デプロイできるように、少なくとも 1 つのワーカーノードに相当する未使用のリソースを使用できるようにもします。 ## [](#コンポーネントのアップグレードについて)コンポーネントのアップグレードについて Runtime Fabric コンポーネントをアップグレードする場合、次の機能を提供するサービスをアップグレードします。 - コントロールプレーンとの通信を容易にする - 負荷分散を行う - メトリクスを記録して転送する コンポーネントのアップグレードが可能な場合、アップグレードが利用可能になったときに表示されるボタンを使用して Runtime Manager 内でアップグレードを適用します。最新のコンポーネントバージョンに関する情報については、​[「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes)​の情報を確認します。 Runtime Fabric コンポーネントのアップグレードでは、ノードの追加は不要です。
アップグレード後に、アプリケーション監視メトリクスは復元されません。
### [](#使用しているコンポーネントバージョンの確認)使用しているコンポーネントバージョンの確認 Runtime Fabric コントローラーノードで、次のコマンドを実行します。 ```none /opt/anypoint/runtimefabric/rtfctl version ``` 出力は次のようになります。 次に例を示します。 ```none [root@ip-10-0-245-74 /]# /opt/anypoint/runtimefabric/rtfctl version COMPONENT VERSION rtfctl 0.3.122 agent 1.9.3 appliance 1.1.1719717580-73a133d kubernetes 1.17 ``` - `rtfctl`​ 項目に ​`rtfctl`​ コマンドラインユーティリティのバージョン - `appliance`​ 項目にアプライアンスコンポーネントのバージョン - `agent`​ 項目に Runtime Fabric コンポーネントのバージョン
使用中の Runtime Fabric コンポーネントとアプライアンスのバージョンは Runtime Manager の ​[Runtime Fabric]​ タブにも表示されます。アップグレードが利用可能な場合は、[Upgrade to vx.x (vx.x にアップグレード)] メッセージが表示されます。
## [](#rtfctl-コマンドラインユーティリティのアップグレードについて)`rtfctl`​ コマンドラインユーティリティのアップグレードについて `rtfctl`​ コマンドラインユーティリティを使用して、Runtime Fabric を管理し、アプライアンスとノード設定のアップグレードを実行します。 コマンドラインから ​`rtfctl`​ ユーティリティをアップグレードします。 `rtfctl`​ コマンドラインユーティリティの最新バージョンを使用することが重要です。 ## [](#ノード設定のアップグレードについて)ノード設定のアップグレードについて ノード設定のアップグレードには、AWS および Azure インフラストラクチャのプロビジョニング、各ノードの準備、新しい Runtime Fabric のブートストラップ、オペレーティングシステムの制限の調整、およびシステムリソースをクリーンアップするためのジョブの実行を行うスクリプトが含まれます。 ノード設定のアップグレードは、Runtime Manager の ​**\[Runtime Fabric downloads (Runtime Fabric ダウンロード)\]**​ ページを使用して、更新されたインストールスクリプトバージョンとして配信されます。
更新されたインストールスクリプトを使用してノードの設定をアップグレードする場合、アプライアンスの最新バージョンが自動的にダウンロードされ、使用されます。
## [](#アップグレードプロセスのしくみ)アップグレードプロセスのしくみ VM/ベアメタルの Anypoint Runtime Fabric をアップグレードするには、次のタスクを実行します。 1. `rtfctl`​ コマンドラインユーティリティをアップグレードします。 2. Runtime Fabric が健全であることを確認します。 3. Runtime Fabric コンポーネントをアップグレードします。 4. Runtime Fabric アプライアンスをアップグレードします。 5. クラスターでアップグレードを実行します。 6. ノード設定をアップグレードします。 7. Runtime Fabric で実行されている Mule デプロイメントを最新のパッチバージョンに更新します。 ### [](#アップグレードプロセスを実行する前に)アップグレードプロセスを実行する前に - 本番環境をアップグレードする前に、本番以外の Runtime Fabric インスタンスで次の手順を実行し、環境との互換性を確認します。チームが新しいアプリケーションをデプロイしていないときや Runtime Fabric で既存のアプリケーションを管理していないときにアップグレードを計画します。本番以外のアップグレードが成功したら、本番環境で次の手順を実行します。 [「Anypoint Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes)​の情報を確認します。 - 必要に応じて追加のワーカーノードをプロビジョニングし、アプライアンスのアップグレードを適用するときのアプリケーションの可用性を維持します。 アプリケーションデプロイメントで使用できるリソースの量が 1 つのワーカーノードのリソースに満たない場合、同じ量の CPU、メモリ、およびディスクリソースを備えた別のワーカーノードを Runtime Fabric に追加します。 [Runtime Fabric へのノードの追加方法](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-nodes)​を参照してください。 - MuleSoft ナレッジベースで [「What Items to Check Before an RTF Appliance Upgrade (RTF アプライアンスのアップグレード前に確認する項目)」](https://help.mulesoft.com/s/article/What-items-to-Check-Before-an-RTF-Appliance-Upgrade)​を参照してください。 ## [](#rtfctl-コマンドラインユーティリティをアップグレードする)`rtfctl`​ コマンドラインユーティリティをアップグレードする アップグレードプロセスのいくつかのステップでは、​`rtfctl`​ コマンドラインユーティリティを使用します。 1. `rtfctl`​ コマンドユーティリティの最新バージョンを使用していない場合は、次のコマンドを使用して最新バージョンをダウンロードします。 cd /opt/anypoint/runtimefabric sudo curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ バイナリのファイル権限を変更します。 sudo chmod +x rtfctl 3. `rtfctl`​ バイナリを所有するユーザーの場合は、新しいバージョンをダウンロードすることなく ​`rtfctl`​ を更新できます。これを行うには、次のコマンドを実行します。 \`rtfctl update\` ## [](#runtime-fabric-が健全であることを確認する)Runtime Fabric が健全であることを確認する アップグレードを実行する前に、クラスターがアクティブで健全であることを確認します。 1. Web ブラウザーを使用して、Runtime Manager の ​**\[Runtime Fabric\]**​ タブに移動し、Runtime Fabric の状況が ​**\[Active (アクティブ)\]**​ として報告されていることを確認します。 2. Runtime Fabric コントローラーノードのターミナルを開きます。 3. `/opt/anypoint/runtimefabric/rtfctl status`​ を実行し、クラスターの状況が健全であることを確認します。 4. ブラウザーセッションを開いたままにして、アップグレードのサブタスクの残りを実行します。 ## [](#runtime-fabric-コンポーネントのアップグレード)Runtime Fabric コンポーネントのアップグレード Runtime Fabric プロセスの最初のステップは Runtime Fabric コンポーネントをアップグレードすることです。 ### [](#runtime-fabric-コンポーネントをアップグレードする前に)Runtime Fabric コンポーネントをアップグレードする前に - 次のエンドポイントをポート 443 で許可リストに登録していることを確認します。このエンドポイントは runtime-registry がアプリケーションデプロイメントの Docker コンテナを取得するために使用されます。 - US コントロールプレーン: `rtf-runtime-registry.kprod.msap.io` - EU コントロールプレーン: `rtf-runtime-registry.kprod-eu.msap.io` - [Anypoint Platform コントロールプレーンと Runtime Fabric との間の相互トランスポートレイヤーセキュリティ (mTLS)](https://docs.mulesoft.com/jp/runtime-fabric/1.13/config-mutual-auth)​ に使用されるエンドポイントを許可リストに登録していることを確認します。

Runtime Fabric にアップグレードした後に、アプリケーションを再起動して、runtime-registry エンドポイントのデプロイメントマニフェストが更新されるようにします。
1. Runtime Manager の ​**\[Runtime Fabric\]**​ タブで Runtime Fabric を選択し、Runtime Fabric に移動します。 2. **\[Upgrade to vx.x (vx.x にアップグレード)\]**​ をクリックします。 3. **\[Run Network Test (ネットワークテストを実行)\]**​ をクリックしてネットワークチェックを実行することで、Anypoint コントロールプレーンを使用してランタイムレジストリと mTLS の適切なエンドポイントを許可リストに登録したことを確認します。 エンドポイントを許可リストに登録していない場合は、続行する前に登録する必要があります。 ネットワークテストは、完了するまで数分かかる場合があります。エラーが発生した場合は、​[「ネットワークテストのエラー」](#network-test-errors)​を参照してください。 4. ネットワークテストが完了したら、​**\[Apply Upgrade (アップグレードを適用)\]**​ をクリックします。 Runtime Fabric の状況が更新され、アップグレード手順が進行中であることが示されます。 5. 状況が ​**\[Active (アクティブ)\]**​ に移行するまで待ちます。 ほとんどの場合、アップグレードにかかる時間は 10 分未満です。状況が ​**\[Active (アクティブ)\]**​ に移行し、Runtime Fabric のバージョンが新しいバージョンを反映したら、コンポーネントのアップグレードは完了です。 Runtime Fabric と Runtime Manager の接続がアップグレード中に切断された場合、アップグレード完了後に接続が復元されます。 6. ブラウザーセッションを開いたままにして、アップグレードのサブタスクの残りを実行します。 ## [](#runtime-fabric-アプライアンスをアップグレードする)Runtime Fabric アプライアンスをアップグレードする Runtime Fabric コンポーネントをアップグレードした後に、Runtime Fabric アプライアンスをアップグレードできます。 ### [](#runtime-fabric-アプライアンスをアップグレードする前に)Runtime Fabric アプライアンスをアップグレードする前に - `/opt/anypoint/runtimefabric/installer`​ ディレクトリに、使用可能なディスク領域が 4 GiB 以上あることを確認します。 - ルート権限があることを確認します。 - 環境に以下が含まれていることを確認します。 - 可用性を維持するため、3 個以上のレプリカで内部ロードバランサーが実行されている。より新しいバージョンの Runtime Fabric では、内部ロードバランサーはデフォルトですべてのコントローラーノードで実行されます。 - コントローラーノードに受信要求の負荷を分散するように外部ロードバランサーが設定されていて、TCP ポート 443 の状態チェックが設定されている。 - 1 個以上の追加のワーカーノード用の CPU およびメモリリソースをクラスターで使用できる。 これにより、ワーカーノードをクラスターから安全に削除して、アプリケーションの可用性に影響を及ぼすことなくアップグレードを適用できます。 - インバウンド要求を処理するアプリケーションが 2 個以上のレプリカに拡大されている。 - Runtime Fabric アラートをカスタマイズした場合、アプライアンスのアップグレードによってカスタマイズが上書きされます。変更の再作成の手順については、​[「メールアラートのコンテンツを変更する」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting#modify-email-alert-contents)​を参照してください。 Runtime Fabric アプライアンスをアップグレードする手順は、次のとおりです。 1. Web ブラウザーを使用して、Runtime Manager に移動して ​**\[Runtime Fabric\]**​ タブを選択し、Runtime Fabric インスタンスのリストを表示します。 2. アップグレードする Runtime Fabric インスタンスを選択します。 3. アプライアンスバージョンの横にある ​**\[Upgrade Available (使用可能なインスタンスをアップグレード)\]**​ をクリックします。 4. **\[Installer package (インストーラーパッケージ)\]**​ の横にある ​**\[Copy Link (リンクをコピー)\]**​ アイコンを選択して、次の例のようにコードスニペットをコピーします。 ```none rtfctl appliance upgrade --url https:// ``` 5. コードスニペットをテキストエディターに貼り付けて参照します。 ## [](#クラスターでのアップグレードの実行)クラスターでのアップグレードの実行 アップグレードが完了するまで 1 時間以上かかる可能性があります。 アップグレード手順中に Runtime Fabric と Runtime Manager 間の接続が複数回切断される可能性があります。アップグレードが完了すると、接続は復元されます。 このアップグレード手順は、一度に 1 つのノードに変更を適用してデプロイ済みアプリケーションの実行を維持し、デプロイ済みアプリケーションが要求を継続的に処理できるように設計されています。 1. アップグレードを適用するノードが手順により選択されます。 2. 選択されたノードで実行されているアプリケーションが別のノードに再デプロイされます。 3. 選択されたノードがクラスターから削除されます。 4. 選択されたノードでアップグレードが適用されます。 5. アップグレード後、選択されたノードがクラスターに追加されます。 アップグレードを実行する手順は、次のとおりです。 1. コントローラーノード上で開いているターミナルを使用して、ルートユーザーに切り替えます。 2. ステップ 5 の「Runtime Fabric アプライアンスをアップグレードする」でコピーしたコマンドを貼り付けます。 sudo /opt/anypoint/runtimefabric/rtfctl appliance upgrade --url アップグレードがバックグラウンドで実行されていることを示す確認が表示されます。 3. ノードで ​`sudo gravity status`​ を実行し、クラスターの状況が \[updating (更新中)\] であることを確認します。 4. アップグレード手順の進捗状況を監視するには、コントローラーノードでターミナルを使用して、次のコマンドを実行します。 sudo /opt/anypoint/runtimefabric/installer/gravity plan 5. アップグレードが正常に完了したことを確認するには、次のコマンドを実行します。 sudo gravity status 6. クラスターの状況が ​**\[Updating (更新中)\]**​ から ​**\[Active (アクティブ)\]**​ に移行したことを確認します。 7. アップグレード前の Runtime Fabric クラスターバージョンが 1.0.x であり、HTTP プロキシを使用している場合、次のコマンドを使用して HTTP プロキシ設定を適用します。 sudo ./rtfctl apply http-proxy --confirm existing ## [](#ノード設定をアップグレードする)ノード設定をアップグレードする すべてのノードで次の手順を実行し、システム設定が最新であることを確認します。 1. Runtime Fabric コントローラーまたはワーカーノードのターミナルを開きます。 2. `rtfctl`​ で ​`apply system-configurations`​ コマンドを実行します。 sudo ./rtfctl apply system-configuration --force または、EU コントロールプレーンを使用している場合は、次のコマンドを実行します。 sudo ./rtfctl apply system-configuration --force --control-plane eu

ワーカーノードで ​apply system-configuration​ コマンドを実行すると、次のようなエラーが表示される場合があります。

Warning: Agent pod is not running.Warning: Failed to get agent version from chartWarning: Failed to get agent version from podDownloading latest scripts (警告: エージェントポッドが実行されていません。警告: チャットからのエージェントバージョンの取得に失敗しました。警告: ポッド空のエージェントバージョンの取得に失敗しました。最新のスクリプトをダウンロードしています)

この警告は無視しても問題ありません。
## [](#runtime-fabric-で実行されている-mule-デプロイメントを最新のパッチバージョンに更新する)Runtime Fabric で実行されている Mule デプロイメントを最新のパッチバージョンに更新する Runtime Fabric アプライアンスおよびコンポーネントをアップグレードしたら、Runtime Fabric でデプロイされた Mule アプリケーションを最新の日付のパッチバージョンに更新します。 1. Web ブラウザーを使用して、Runtime Manager の ​**\[Applications (アプリケーション)\]**​ タブに移動します。 2. アプリケーションを選択し、​**\[Manage Application (アプリケーションを管理)\]**​ を選択します。 3. **\[Runtime version (Runtime バージョン)\]**​ 項目の値で更新が使用可能であることを示されていることを確認し、選択します。 4. **\[Deploy (デプロイ)\]**​ を選択し、更新された Mule Runtime Engine バージョンでアプリケーションを再デプロイします。 5. この Runtime Fabric インスタンスで実行されている各アプリケーションでこれを繰り返します。 ## [](#アプライアンスのアップグレードの再開)アプライアンスのアップグレードの再開 アプライアンス (インストーラーパッケージ) のアップグレードが失敗した場合、アップグレードを再開します。 再開したアップグレードはターミナルセッションに接続されるため、アップグレードを再開する前に、安定した接続があることを確認します。 1. アップグレードを開始するために使用したコントローラーノード上で開いているターミナルで、次の例のように、インストーラーバンドルファイルを含むディレクトリに移動します。 cd /opt/anypoint/runtimefabric/installer 2. アップグレードを再開するには、次のコマンドを実行します。 sudo /opt/anypoint/runtimefabric/installer/gravity upgrade --resume 3. アップグレード手順の出力がターミナルセッションにストリーミングされます。以前のエラーが再度発生した場合、次のセクションで説明されているトラブルシューティング手順を実行します。 ## [](#runtime-fabric-アップグレードエラーのトラブルシューティング)Runtime Fabric アップグレードエラーのトラブルシューティング Runtime Fabric をアップグレードしようとしたときにアップグレードエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#ネットワークテストのエラー)ネットワークテストのエラー Runtime Fabric コンポーネントを v1.11 以降にアップグレードする場合は、ネットワークテスト中に次のエラーが発生することがあります。 - `mTLS handshake error: check certs` このエラーは、証明書が最新でない場合に発生する可能性があります。証明書を更新して、アップグレードをもう一度実行してください。 - `ConnectionRefused:check port’s open` このエラーは、必要なアウトバウンドポートがクラスターで使用できない場合に発生します。Runtime Fabric コンポーネントのアップグレード手順を確認し、必要なポートを使用可能にしたことを確認してください。 - `Connection timed out` このエラーは、必要なエンドポイントがクラスターで許可リストに登録されていない場合に発生します。Runtime Fabric コンポーネントのアップグレード手順を確認し、必要なエンドポイントを許可リストに登録したことを確認してください。 - ネットワークテストに 5 分以上かかる ネットワークの問題やローカルホストネットワークの問題のために必要な Docker イメージの取得に時間がかかりすぎると、タイムアウトが発生する場合があります。 ### [](#troubleshooting-appliance-upgrade-errors)アプライアンスのアップグレードエラー アプライアンス (インストーラーパッケージ) のアップグレード中は特定の順序の一連の手順が実行されます。エラーが発生した場合、アップグレードは一時停止し、エラーが表示されます。ほとんどの場合、本番の Runtime Fabric 設定で各アプリケーションの複数のレプリカを実行しているときは、実行中のアプリケーションの可用性に影響はありません。 ほとんどのエラーは、コントローラーノードで実行されている ​`etcd`​ ブロックデバイスのディスクパフォーマンスが不十分であることが原因で発生します。 コマンドエラーを解決するには、次の手順を実行します。 1. `gravity plan`​ コマンドを使用して、アップグレードが一時停止したフェーズを特定します。 sudo /opt/anypoint/runtimefabric/installer/gravity plan 次の部分的なリストは、アップグレードフェーズの例を示しています。 \* init \* checks \* bootstrap \* node-1 \* masters \* node-1 \* drain \* system-upgrade \* taint ... \* runtime \* rbac-app \* site \* kubernetes \* app \* telekube 2. エラーが発生したフェーズと ​`--debug`​ フラグを使用してアップグレードを再開します。 次の例では、​`masters/node-1/drain`​ フェーズを再起動することでアップグレードを再開します。 sudo /opt/anypoint/runtimefabric/installer/gravity upgrade --phase=/masters/node-1/drain --force --debug 3. コマンドが実行されるまで待機します。コマンドがエラーで終了しない場合、次のコマンドを使用してアップグレードを再開します。 sudo /opt/anypoint/runtimefabric/installer/gravity plan resume 4. アップグレードがエラーで再度終了した場合、次の手順を実行します。 1. ログを参照して、修正が必要なノードを特定します。 2. 詳細なサポートが必要な場合は、MuleSoft サポートにチケットを申請してください。 5. エラーログで特定した Runtime Fabric ノードの別のターミナルを開きます。 6. アップグレードを実行しているコントローラーノードで、失敗したフェーズを手動で実行します。 sudo /opt/anypoint/runtimefabric/installer/gravity plan execute --phase=< insert phase > --force --debug このコマンドでエラーが返される場合は、数分待って上のステップを繰り返します。 トラブルシューティングの詳細は、 [「How to Troubleshoot RTF Appliance Upgrade (RTF アプライアンスのアップグレードのトラブルシューティング方法)」](https://help.mulesoft.com/s/article/How-to-Troubleshoot-RTF-Appliance-Upgrade?)​を参照してください。 ## [](#アプライアンスのアップグレードのロールバック)アプライアンスのアップグレードのロールバック アップグレードの問題を解決できない場合、次のいずれかのオプションを使用してアップグレードをロールバックできます。 - 単一コマンドによる自動ロールバック - 手動ロールバック ### [](#単一コマンドによる自動ロールバック)単一コマンドによる自動ロールバック 次のコマンドを実行します。 ```none rtfctl appliance rollback ```
このオプションは、新しいアプライアンスバージョンでのみサポートされます。コマンド出力で ​rtfctl appliance rollback​ コマンドがサポートされないと表示された場合は、手動ロールバックを実行してください。
### [](#手動ロールバック)手動ロールバック 実行したアップグレードステップを手動でロールバックするには、次の手順を実行します。 1. `gravity plan`​ コマンドを使用して、アップグレードがどのフェーズで一時停止したかを特定します。 sudo /opt/anypoint/runtimefabric/installer/gravity plan 次の部分的なリストは、アップグレードフェーズの例を示しています。 \* init \* checks \* bootstrap \* node-1 \* masters \* node-1 \* drain \* system-upgrade \* taint ... \* runtime \* rbac-app \* site \* kubernetes \* app \* telekube 2. 次の例のように、完了したステップを逆の順序でロールバックします。 $ sudo gravity plan rollback --phase=/masters/node-1/taint $ sudo gravity plan rollback --phase=/masters/node-1/system-upgrade $ sudo gravity plan rollback --phase=/masters/node-1/drain ... 一連のステップをロールバックする方法: $ sudo /opt/anypoint/runtimefabric/installer/gravity plan rollback --phase=/masters 3. すべてのステップがロールバックされたら、計画の状況を更新し、完全にロールバック済みとしてアップグレードをマークします。 $ sudo gravity plan complete # VM/ベアメタルの Runtime Fabric のアンインストール

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
Runtime Fabric をアンインストールして gravity クラスターを完全に削除するか、gravity クラスターを削除せずに Runtime Fabric をアンインストールすることができます。 ## [](#runtime-fabric-のアンインストールと-gravity-クラスターの削除)Runtime Fabric のアンインストールと gravity クラスターの削除 Runtime Fabric をアンインストールし、VM から gravity クラスターを完全に削除するには、次の手順を実行します。 最初の 2 つのステップを実行して Runtime Manager ですべてのアプリケーションと Runtime Fabric を削除し、VM ディスクのイメージを再適用することで残りのステップをスキップすることもできます。
この手順を正常に実行するには、すべてのノードを実行し、クラスターに参加させておく必要があります。
1. Runtime Manager を使用して、Runtime Fabric で実行されているすべての Mule アプリケーションを削除します。 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 2. Runtime Manager を使用して、Runtime Fabric を削除します。 3. 各ワーカー VM で次のコマンドを実行し、確認メッセージが表示されたら「yes」を入力して確認します。 sudo gravity leave --force 4. 他の任意のノードで ​`gravity status`​ を実行します。​`gravity status`​ を実行してノードが表示されなくなるまでこれを続けます。 5. 各ワーカー VM で次のコマンドを順次実行します。 sudo umount /var/lib/gravity/planet/etcd sudo umount /var/lib/gravity sudo rm -rf /opt/anypoint/runtimefabric /root/.gravity /home/rtf-user/.gravity /var/lib/gravity /tmp/gravity /tmp/gravity-wizard\* sudo rm /etc/systemd/system/install-teleport-\*.service /etc/systemd/system/install-planet-\*.service /etc/systemd/system/shrink-\*.service /etc/systemd/system/gravity\_\_gravitational.io\_\_teleport\_\_\*.service /etc/systemd/system/gravity\_\_gravitational.io\_\_planet-\*.service 6. `/etc/fstab`​ ファイルで、コメント ​`# Added by RTF`​ が付加されている行を削除します。 7. VM を再起動します。 8. 各コントローラー VM でステップ 3 ～ 7 を繰り返します。 9. 前述の手順が失敗した場合は、次のコマンドを順次実行して手動クリーンアップを実行します。 sudo systemctl stop gravity\_\_gravitational.io\_\_planet-\*.service sudo systemctl stop gravity\_\_gravitational.io\_\_teleport\*.service sudo systemctl disable gravity\_\_gravitational.io\_\_teleport\_\_2.4.7.service sudo systemctl disable gravity\_\_gravitational.io\_\_planet-master\_\_5.0.8-1906.service sudo gravity system uninstall --confirm sudo umount /var/lib/gravity/planet/etcd sudo umount /var/lib/gravity sudo rm -rf /opt/anypoint/runtimefabric /root/.gravity /rtf-user/.gravity /var/lib/gravity /tmp/gravity /tmp/assets393106389 /tmp/gravity-wizard167466702 ## [](#gravity-クラスターを削除しない-runtime-fabric-のアンインストール)gravity クラスターを削除しない Runtime Fabric のアンインストール Runtime Fabric をアンインストールし、gravity クラスターはそのままにしておくことができます。これは、Runtime Fabric を同じクラスターに再インストールする場合に便利です。これを実行するには、1 つのコントローラーノードで次のコマンドを実行します。 rtfctl uninstall --confirm rtfctl install # VM/ベアメタルの Runtime Fabric のインストールの開始 VM/ベアメタルの Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。 ## [](#始める前に)始める前に VM/ベアメタルに Anypoint Runtime Fabric をインストールする前に、次のトピックを確認してください。 - [VM/ベアメタルの Anypoint Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-vm-bare-metal) - [Anypoint Runtime Fabric インストールの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs) - [制限事項](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-limitations) 次の点にも注意してください。 - 以下のように Runtime Manager に ​**\[Runtime Fabric\]**​ タブが表示されない場合、各自のアカウントで Anypoint Runtime Fabric が有効になるようにカスタマーサクセスマネージャーに依頼してください。 - 利用可能な最新の Runtime Fabric エージェントバージョンを使用してクラスターを作成してください。最新バージョンを使用できない場合は、 [「How to Specify the RTF Agent Version in Upgrades^ (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​を参照してください。 ## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. Runtime Fabric の名前を指定します。 5. \[VMs or bare metal (VM またはベアメタル)\] オプションを選択します。 6. **\[Next (次へ)\]**​ をクリックします。 7. Runtime Fabric の作成後、Runtime Manager には、対応するアクティベーションデータが表示されます。このデータを記録して、VM/ベアメタルインストーラーで Runtime Fabric を実行するときに使用します。 Runtime Manager の初期設定では、Runtime Fabric がアクティベーション状態であることが示されます。これは、VM/ベアメタルの Runtime Fabric がインストールされて、Runtime Manager に接続されると変わります。 ## [](#vmベアメタルの-runtime-fabric-のインストール)VM/ベアメタルの Runtime Fabric のインストール Runtime Manager で Runtime Fabric を作成したら、Anypoint Runtime Fabric をインフラストラクチャにインストールします。各自のインフラストラクチャに対応する次のリンクをクリックしてください。 - [AWS での Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-aws) - [Azure での Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-azure) - [Runtime Fabric の手動インストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-manual) # VM/ベアメタルの Runtime Fabric のトラブルシューティング このトピックでは、VM/ベアメタルの Anypoint Runtime Fabric をインストールおよび管理するときの一般的なエラーとその解決手順について説明します。 ## [](#完全なネットワーク評価の取得)完全なネットワーク評価の取得 ネットワークの全体的な健全性評価を取得するには、次のコマンドを実行します。 ```none /opt/anypoint/runtimefabric/rtfctl status ``` ## [](#rtfctl-を使用したネットワーク接続のトラブルシューティング)rtfctl を使用したネットワーク接続のトラブルシューティング すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。 `rtfctl`​ を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認するだけでなく、接続に関する問題をトラブルシューティングすることができます。 ### [](#アウトバウンド接続の確認)アウトバウンド接続の確認 各ノードで、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​の手順に従って ​`rtfctl`​ をインストールします。 クラスターのすべてのコントローラーノードとワーカーノードで次のコマンドを実行し、必要なアウトバウンド接続を確認します。 ```none sudo ./rtfctl test outbound-network ``` サンプル出力: ```none [root@rtf-controller-1 runtimefabric]# sudo ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ ``` アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して​[「ポートの IP アドレスとホスト名の許可リストへの追加」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs#port-ip-addresses-and-hostnames-to-add-to-the-allowlist)​で説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。 ### [](#未知の証明書機関エラーのトラブルシューティング)未知の証明書機関エラーのトラブルシューティング アウトバウンド接続を検証するためのネットワークテストを実行すると、​`x509: certificate signed by unknown authority`​ エラーが返されることがあります。 このエラーは、Runtime Fabric がサポートしていない独自のルート CA を使用しているファイアウォールまたはプロキシによってトラフィックが捕捉されたことによって発生します。 証明書の発行者を確認するには、次のコマンドを実行します。 curl -v https://rtf-runtime-registry.kprod.msap.io Amazon が発行者としてリストされていることを確認します。 Server certificate: subject: CN=\*.prod.cloudhub.io start date: Nov 12 00:00:00 2021 GMT expire date: Dec 10 23:59:59 2022 GMT subjectAltName: host "rtf-runtime-registry.kprod.msap.io" matched cert's "\*.kprod.msap.io" issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon SSL certificate verify ok. 他の発行者がリストされている場合は、トラフィックが捕捉されていることを意味します。 ## [](#アプリケーションポッド用の-anypoint-monitoring-サイドカーコンテナの接続の問題のトラブルシューティング)アプリケーションポッド用の Anypoint Monitoring サイドカーコンテナの接続の問題のトラブルシューティング アプリケーションデプロイメントポッドのサイドカーコンテナを監視しているときに接続の問題が発生した場合は、​[ネットワークポートの前提条件](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed-network-configuration#port-configuration)​を確認して、必須ポートのブロックをすべて解除してください。Anypoint Monitoring を許可しない場合は、機能に問題がなくても Anypoint Visualizer ポート 5044 からエラーが報告される場合があります。詳細は、 [「"Failed to connect to failover" ERROR logs in RTF application pod sidecar container^ (RTF アプリケーションポッドのサイドカーコンテナに「Failed to connect to failover」エラーが記録される)」](https://help.mulesoft.com/s/article/Failed-to-connect-to-failover-ERROR-logs-in-RTF-application-pod-sidecar-container)​を参照してください。 ## [](#chrony-同期チェックエラーのトラブルシューティング)chrony 同期チェックエラーのトラブルシューティング Runtime Fabric の時間同期デーモンでは chrony が必要です。​`init.sh`​ インストールスクリプトで chrony が見つからないと、Runtime Fabric のインストールは次のエラーで失敗します。 ```none ============================================================================================ 1 / 10: Install required packages ================================================ chrony-3.4-1.el7.x86_64 Checking chrony sync status...Retrying in 30 seconds... Retrying in 30 seconds... Error: chrony sync check failed 3 times, giving up. *********************************************************** ** Oh no! Your installation has stopped due to an error. ** *********************************************************** 1. Visit the troubleshooting guide for help: xref:runtime-fabric::troubleshoot-guide.adoc#troubleshoot-install-package-issues[Troubleshoot Install Package Issues]. 2. Resume installation by running /opt/anypoint/runtimefabric/init.sh Additional information: Error code: 1; Step: install_required_packages; Line: -; ``` この問題を解決するには、次の手順を実行します。 1. chrony が有効化されていることを確認します。 `systemctl enable chronyd` 2. Network Time Protocol (NTP) が無効化されていて動作していないことを確認します。 `systemctl stop ntpd; systemctl disable ntpd` 3. ネットワークチームに連絡して、​`/etc/chrony.conf`​ のタイムサーバーが到達可能であることを確認するように依頼します。 4. chrony が接続元と同期していることを確認します。 ```none chronyc sourcestats -v Number of sources = 4 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== ns3.turbodns.co.uk 16 12 58m -0.006 0.014 +370us 14us test.diarizer.com 16 9 327m -0.184 0.144 -1618us 799us ntp1.vmar.se 6 3 21m +0.117 0.074 +228us 10us time.cloudflare.com 6 5 86m +0.014 0.214 +2040ns 94us ``` 5. `chronyc`​ 追跡の ​`Leap status`​ 値が ​`Normal`​ であることを確認します。 ```none chronyc tracking Reference ID : A29FC87B (time.cloudflare.com) Stratum : 4 Ref time (UTC) : Mon Jul 20 15:42:57 2020 System time : 0.000000003 seconds slow of NTP time Last offset : +0.000344024 seconds RMS offset : 0.000172783 seconds Frequency : 2.265 ppm slow Residual freq : +0.149 ppm Skew : 0.124 ppm Root delay : 0.003362593 seconds Root dispersion : 0.000759320 seconds Update interval : 1031.1 seconds Leap status : Normal ``` 6. `init.sh`​ を実行してインストールを再試行します。 ## [](#クラスターの問題のトラブルシューティング)クラスターの問題のトラブルシューティング サポートケースを入力するときに、サポートチームから次のコマンドのいずれかまたは両方を実行してデバッグ情報を生成するよう要求される場合があります。 - Kubernetes オブジェクトおよびログのみが含まれるアーカイブを生成する ​`rtfctl report`​ コマンド。 - すべてのクラスターノードから診断を収集する ​`rtfctl appliance report`​ コマンド。 サポートチームから、​[「デバッグ情報のダウンロード」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/using-opscenter#download-debug-info)​で説明されているようにオペレーションセンターから情報をダウンロードするよう要求される場合があります。 ## [](#クラスターの縮小または拡張エラーのトラブルシューティング)クラスターの縮小または拡張エラーのトラブルシューティング Runtime Fabric からクラスターのノードを追加または削除 (クラスターを拡張または縮小) した直後に新しいノードを追加しようとすると、​`クラスター状況の「縮小中」`​エラーまたは​`クラスター状況の「拡張中」`​エラーが返される場合があります。この場合は、4 分以上待ってから新しいノードを追加してください。 ## [](#アプリケーションデプロイメントの問題のトラブルシューティング)アプリケーションデプロイメントの問題のトラブルシューティング ### [](#anypoint-monitoring-エージェントの問題)Anypoint Monitoring エージェントの問題 まれに、Anypoint Monitoring エージェントが原因でアプリケーションがデプロイされないこともあります。このような状況では、次のメッセージが表示される場合があります。 - アプリケーションが ​`Deploying`​ 状態のままになる - `Error starting monitoring agent (code -1)` この場合、アプリケーションを再デプロイし、次のカスタムプロパティを設定します。 anypoint.platform.config.analytics.agent.enabled=false Anypoint Monitoring エージェントによって、デプロイされたアプリケーションの状態が変更されることもあります。次のいずれかの現象が発生した場合、 - アプリケーションが ​`Running`​ から ​`Applying`​ に移行 - `Monitoring agent has exited with code -1` これはエージェントが再起動していることを示します。実行中のアプリケーションへの影響はありません。アプリケーションメトリクスはキューに追加され、エージェントの再起動後に再度収集されます。 ### [](#vmware-vmxnet-generation-3-の問題)VMware VMXNET Generation 3 の問題 Runtime Fabric アプライアンスを VMware 環境でホストしていてアプリケーションをデプロイできない場合は、 [RTF Networking Issues with VMware and "\[Runtime Fabric\]​ java.net.UnknownHostException:" Errors](https://help.mulesoft.com/s/article/RTF-Networking-Issues-with-VMware) (VMware の RTF ネットワーキングの問題と「\[Runtime Fabric\] java.net.UnknownHostException:」エラー) の MuleSoft ナレッジベース記事を参照してください。 ### [](#crashloopbackoff-couldnt-initialize-inotify-crashloopbackoff-inotify-を初期化できませんでしたエラーのトラブルシューティング)「CrashLoopBackOff - Couldn’t initialize inotify (CrashLoopBackOff - inotify を初期化できませんでした)」エラーのトラブルシューティング inotify 値が環境で低すぎると、次のエラーメッセージが表示されることがあります。 \[Kubernetes\] Container "anypoint-monitoring" - CrashLoopBackOff - Couldn't initialize inotify また、​`gravity status`​ コマンドの出力で次のアラートが表示されることもあります。 \* rtf-worker-1 (172.31.3.5, worker\_node) Status: degraded \[×\] Unable to initialize inotify (too many open files) Remote access: online 2 つの Linux カーネル値で inotify の使用を制御します。 - `inotify.max_user_watches` - `inotify.max_user_instances` `inotify.max_user_watches`​ 設定は ​`1048576`​ に設定する必要があります。Runtime Fabric インストーラーでは自動的にこの設定が実行されるため、原因として最も可能性が高いのは別のプロセスまたはユーザーによってこの設定が低い値に変更されたことです。 この設定を修正するには、次のコマンドを実行します。 $ sysctl -w fs.inotify.max\_user\_watches=1048576 ノードが再起動されても影響がないようにこの変更を永続的なものにするには、例えば次のように、​`/etc/sysctl.d`​ ディレクトリ内のファイルで設定を定義します。 $ cat /etc/sysctl.d/inotify.conf fs.inotify.max\_user\_watches=1048576 ほとんどの OS ディストリビューションでは ​`inotify.max_user_instances`​ がデフォルトで ​`128`​ に設定されます。この値は多くのアプリケーションのデプロイやレプリカのワーカーノードには低すぎます。このエラーが表示された場合は、上記の手順に従って ​`inotify.max_user_instances`​ の値を増やしてください。 いずれの場合も、システム管理者と一緒にこの状況を確認し、これらの値が使用状況に適していて、将来減らされることがないことを確認してください。 ## [](#アプリケーションのランタイムの問題のトラブルシューティング)アプリケーションのランタイムの問題のトラブルシューティング 次のいずれかの Runtime Fabric アラートメッセージが報告された場合、1 つ以上のコントローラーノードの回復が必要になる場合があります。 Management plane is unreachable InfluxDB is down or no connection between Kapacitor and InfluxDB Node is down CRITICAL / Kubernetes node is not ready: CRITICAL / etcd: cluster is unhealthy ターミナルを開き、​`gravity status`​ コマンドを実行して、クラスターおよび個々のコンポーネントの健全性状況を取得します。 ノードを回復するには、​[「Runtime Fabric からのノードの追加または削除」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-nodes)​で提供されている手順に従います。 ## [](#環境変数の問題のトラブルシューティング)環境変数の問題のトラブルシューティング この手順では、インストールプロセスで手順を実行するために必要な変数を検出します。この変数をインストールに提供する方法は、インストールを実行する場所により異なります。 - AWS の場合、変数は terraform スクリプトで設定され、​`/opt/anypoint/runtimefabric/env`​ に配置されているファイルに出力されます。 - Azure の場合、変数は ARM テンプレートの実行時に設定され、仮想マシンインスタンスでタグとして取得されます。 - 手動インストールの場合、ユーザーが ​`/opt/anypoint/runtimefabric/env`​ にある値を使用してファイルを作成します。 このプロパティを取得したら、Anypoint Platform に接続して ​`RTF_ACTIVATION_DATA`​ 値に基づいて追加の値を取得するための手順が実行されます。 ### [](#一般的なエラー)一般的なエラー アクティベーションデータ値に問題がある場合や、インスタンスでのインターネットアクセスに問題がある場合、次のエラーが発生することがあります。 curl: (7) Failed connect to anypoint.mulesoft.com:443; Operation now in progress Error: Failed to fetch registration properties. (000). Please check your token is valid ============ Error ============ Exit code: 1 Line: このエラーが確認された場合、次の操作を実行してください。 - インスタンスにアウトバウンドインターネット接続があることを確認します。簡単な検証方法は、次のコマンドを実行し、301 応答が返されることを確認することです。 curl https://anypoint.mulesoft.com - ネットワーク接続の初期化が完了しなかった場合は、インストール手順を再度実行します。 - Azure では、スクリプトは ​`/opt/anypoint/runtimefabric/script.sh foreground`​ にあります。 - AWS および手動インストールでは、スクリプトは ​`/opt/anypoint/runtimefabric/init.sh foreground`​ にあります。 - Anypoint Runtime Manager で作成された Runtime Fabric と比較することで、アクティベーションデータ値が正しいことを検証します。 問題が引き続き発生する場合は、サポートチケットを申請して詳細なサポートを要求してください。 ## [](#失敗したインストールの再開)失敗したインストールの再開 init スクリプトを実行することで、インストールが失敗した時点からそのインストールを再開できます。 - AWS および手動インストール: /opt/anypoint/runtimefabric/init.sh - Azure インストール: /opt/anypoint/runtimefabric/script.sh ## [](#インストールパッケージの問題のトラブルシューティング)インストールパッケージの問題のトラブルシューティング この手順では、必要なパッケージをインスタンスにインストールします。​`yum`​ パッケージリポジトリを使用して、必要なパッケージのダウンロードとインストールを行います。 ### [](#一般的なエラー-2)一般的なエラー この手順でエラーがある場合、以下を確認します。 - インスタンスにアウトバウンドインターネット接続があることを確認します。簡単な検証方法は、次のコマンドを実行し、301 応答が返されることを確認することです。 curl https://anypoint.mulesoft.com - 手動インストールを実行している場合、​`init.sh`​ スクリプトがルート権限で実行されていることを確認します。 sudo ./init.sh foreground - 必要なパッケージの 1 つを手動でインストールし、インストールスクリプト以外でインストールが成功するかどうかを確認します。 sudo yum install -y chrony - 成功しない場合、運用チームに問い合わせて、サポートを要求してください。インスタンスへの昇格したアクセス権の要求が必要になる場合があります。 パッケージの手動インストールが成功した場合や、引き続きサポートが必要な場合は、サポートチケットを申請してください。 ## [](#ディスクのフォーマットおよびマウント)ディスクのフォーマットおよびマウント この手順では、​`RTF_DOCKER_DEVICE`​ または ​`RTF_ETCD_DEVICE`​ 変数が提供されているブロックデバイスまたはディスクに対して次のタスクを実行します。 1. インスタンスで使用可能なブロックデバイスに値がマップされていることを確認するチェックを実行します。 2. ディスクがすでにマウントされている場合は、マウント解除します。 3. ディスクをフォーマットします。 4. マウントエントリを ​`/etc/fstab`​ ファイルに追加します。 5. `$DOCKER_MOUNT`​ または ​`$ETCD_MOUNT`​ の値に基づいてディレクトリを作成します。 6. 上記で作成した予期されるディレクトリにディスクをマウントします。 ### [](#rtf-コンポーネントのインストール)RTF コンポーネントのインストール この手順では、Anypoint Platform に接続し、Runtime Fabric コンポーネントをクラスターにダウンロードしてインストールします。 デプロイメントが時間制限内に完了できない場合、この手順でエラーが返されることがあります。 ... \[OK\] Installing Runtime Fabric Agent. This may take several minutes... configmap "grafana-dashboards" deleted configmap "kapacitor-alerts" deleted Release "runtime-fabric" does not exist. Installing it now. The following deployments failed to become ready within the time limit: monitor --- Name: monitor-79c7564b77-wb9c6 Namespace: rtf Node: 10.165.12.87/10.165.12.87 Start Time: Thu, 13 Dec 2018 20:23:59 +0000 Labels: app=monitor pod-template-hash=3573120633 Annotations: checksum/config=4c4aac48d9cc8b24828b38ba0eb587840bc17b2449a54d593f74e2d58e5c12ae kubernetes.io/psp=privileged seccomp.security.alpha.kubernetes.io/pod=docker/default Status: Running IP: 10.244.82.17 Controlled By: ReplicaSet/monitor-79c7564b77 Containers: ... << More information displayed that describes the deployment manifest and stack trace >> このエラーが確認された場合、次の操作を実行してください。 - アウトバウンド TCP ポート 5672 がインターネットに対して開かれていることを確認します。内部ネットワークで実行されているコントローラー VM からインターネット上のこのホスト名への接続が許可されている必要があります。 - インターネットへの接続を確立するには、TCP プロキシが必要になる場合があります。必要に応じて、ネットワークチームと連携して検証と確認を行ってください。​[「Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​を参照してください。 ## [](#期限切れのクライアント証明書のトラブルシューティング)期限切れのクライアント証明書のトラブルシューティング クラスターで ​[Anypoint Platform との相互認証](https://docs.mulesoft.com/jp/runtime-fabric/1.13/config-mutual-auth)​を使用する場合は、​`rtf`​ 名前空間の ​`certificate-renewal`​ という名前の cron ジョブにより、クライアント証明書が定期的に更新されます。このジョブは証明書の期限切れ前に実行され、証明書が期限切れになる前に更新します。予期せぬ状況により、証明書が更新されずに期限切れになることがあります。そのような場合、​`certificate-renewal`​ ジョブで次のエラーが記録されます。 time="2020-03-11T12:42:05Z" level=warning msg="{\\"timestamp\\":\\"2020-03-11T12:42:05.035+00:00\\",\\"status\\":409,\\"error\\":\\"Conflict\\",\\"message\\":\\"Certificate was already exipired, please renew cert!\\",\\"path\\":\\"/api/v1/organizations/4d70ccf6f0ce/agents/74f0df29/renew\\"}" 証明書を更新するには、​`rtfctl appliance renew-expired-client-cert`​ コマンドを使用します。詳細は以下を参照してください。 - [Runtime Fabric アプライアンスを管理するコマンド](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl#commands-for-managing-the-runtime-fabric-appliance) - [Rtfctl Client Certificate Expiration Warning (Rtfctl クライアント証明書期限切れ警告)](https://help.mulesoft.com/s/article/Rtfctl-Client-Certificate-Expiration-Warning) ## [](#runtime-fabric-のバックアップと復元後の不整合のトラブルシューティング)Runtime Fabric のバックアップと復元後の不整合のトラブルシューティング クラスターをバックアップから復元した後に、Runtime Manager で次のような不整合が見られることがあります。 - 削除したアプリケーションが実行中と表示される - 最近デプロイされたアプリケーションが 0 個のレプリカとリストされる - デプロイメントのレプリカ数が Runtime Manager で指定したレプリカ数と一致しない これらのそれぞれの状況では、デプロイメントの状況が​**適用中**​と表示されることと、対応する API コールで ​`status`​ 項目と ​`desiredState`​ 項目が一致しないことが明らかになることを確認してください。根本原因の説明については、​[「The Back Up and Restore Process Does Not Affect the Control Plane (バックアップと復元プロセスがコントロールプレーンに影響しない)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-backup-restore#back-up-and-restore-process-does-not-affect-the-control-plane)​を参照してください。 これらの競合を解決するには、クラスターに必要な変更を手動で適用し、予期される状況を照合する必要があります。これらの変更は自動的に再同期することも、新しい変更で上書きすることもできません。クラスターの現在の状況が予期される値に一致してからでないと、コントロールプレーンから追加の変更を適用することはできません。バックアップを作成した後に適用した変更を確認する必要がある場合は、​[監査ログ](https://docs.mulesoft.com/jp/access-management/audit-logging)​を使用してください。 ## [](#オペレーションセンターの監視およびログの問題のトラブルシューティング)オペレーションセンターの監視およびログの問題のトラブルシューティング 1 つ以上のノードの再起動後にオペレーションセンターの監視およびログの再起動に失敗した場合、すべての VM でポート転送ルールが適用されており、VM で実行されている Kubernetes ポッドにトラフィックを伝送できることを確認します。詳細は、​[「firewalld を使用する場合の転送の有効化」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/prereq-firewalld-forwarding)​を参照してください。 ## [](#ops-center-メトリクスダッシュボードにアプリケーションが表示されない場合のトラブルシューティング)Ops Center メトリクスダッシュボードにアプリケーションが表示されない場合のトラブルシューティング シナリオ: Ops Center メトリクスダッシュボードで次の現象が起きています。 1. メトリクスデータに想定外のスパイクが頻繁に示される 2. ドロップダウンメニューにアプリケーションが表示されない 3. InfluxDB ログに ​`max-series-per-database limit exceeded`​ エラーが含まれる。

influxdb_pod_name を取得するには、​kubectl -n monitoring get pod -lcomponent=influxdb​ を実行します。
このシナリオは、エントリ数が事前設定されている 100 万件の制限に達すると発生することがあります。 この問題を解決するには、シリーズ制限を 1000 万以上に増やします。 1. 設定マップを編集します。 kubectl edit cm influxdb -n monitoring 2. `max-series-per-database`​ 値を 1000 万に変更します。 max-series-per-database = 10000000 3. 変更を保存します。 4. InfluxDB ポッドを再起動して変更を適用します。 kubectl -n monitoring delete pod データベースシリーズを削除してログに記録されるデータを変更するには、 [「RTF - Error Reporting Heap Metrics: InfluxDBException: partial write: max-series-per-database limit exceeded^ (RTF - ヒープメトリクスレポートエラー: InfluxDBException: 部分的な書き込み: max-series-per-database 制限を超えました)」](https://help.mulesoft.com/s/article/RTF-Error-Reporting-Heap-Metrics-InfluxDBException-partial-write-max-series-per-database-limit-exceeded)​の手順に従ってください。 ## [](#エージェントバージョンの不一致のトラブルシューティング)エージェントバージョンの不一致のトラブルシューティング シナリオ: Runtime Fabric のアップグレード後に、Runtime Manager で次のエラー状況が発生します。​`Degraded: Runtime Fabric agent version mismatch detected from control plane. (Degraded: コントロールプレーンで Runtime Fabric エージェントバージョンの不一致が検出されました。)`​このエラーは、Anypoint Platform に保存されているクラスターの Runtime Fabric エージェントバージョンと、エージェント状況プローブから報告されたバージョンが一致しない場合に発生します。 この問題の一般的な原因は次のとおりです。 - Runtime Fabric エージェントのアップグレードが失敗した、またはロールバックされた - アップグレード前のバックアップが復元された - 相互認証が無効化されている ### [](#エージェントアップグレードが失敗した)エージェントアップグレードが失敗した この状況では、Runtime Fabric エージェントのアップグレードが失敗してロールバックされているものの、目的の (アップグレード後の) バージョンが Anypoint Platform にリストされています。この問題を解決するには、 [「Degraded Status as Runtime Fabric Agent Version Mismatch Detected^ (Runtime Fabric エージェントバージョンの不一致が検出された場合の状況の低下)」](https://help.mulesoft.com/s/article/Degrade-Status-as-Runtime-Fabric-Agent-Version-Mismatch-Detected)​を参照してください。 ### [](#アップグレード前のバックアップが復元された)アップグレード前のバックアップが復元された コントロールプレーンから適用された最新バージョンよりも前の Runtime Fabric バージョンで作成されたバックアップを復元した場合は、アップグレードをやり直す必要があります。詳細は、​[「バックアップ実行後の変更内容が復元されない」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-backup-restore#changes-made-after-performing-a-backup-are-not-restored)​を参照してください。 ### [](#相互認証が無効化されている)相互認証が無効化されている Runtime Fabric バージョン 1.11 以降では相互認証が必要です。相互認証が有効化されていない状態で 1.11 より前のバージョンから 1.11 以降にアップグレードすると、このエラーメッセージが返される場合があります。この問題を解決するには、​[相互認証を有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/config-mutual-auth)​してからアップグレードを再び実行します。 ## [](#エージェントポッドのトラブルシューティング)エージェントポッドのトラブルシューティング 1 つ以上の Runtime Fabric エージェントポッドコンテナでログを確認せず、エントリと一致するエラーメッセージを検索していない場合は、トラブルシューティングシナリオを実行していない次のメトリクスサーバーを確認します。 rtfd コンテナが試行のたびにクラッシュする場合は、次のエラーメッセージが返されることがあります。 2023/02/23 16:35:20 instantiating client: fetching server resource preferences: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request このエラーは、Kubernetes メトリクスサーバーがインストールされているのに実行されていないために発生します。 Runtime Fabric アプライアンスバージョン 1.1.1636064094-8b70d2d 以降には、\[monitoring\] 名前空間でのデプロイとしてメトリクスサーバーが含まれています。 さらにトラブルシューティングするには、このデプロイおよび関連付けられているポッドのイベントとログを調査する必要があります。メトリクスサーバーが起動して動作状態になれば、rtfd は想定通りに機能します。 メトリクスサーバーの復旧に関して支援が必要であれば、完全なアプライアンスレポートを沿えて MuleSoft サポートまでご連絡ください。 ## [](#メールアラートのカスタマイズが消えた場合のトラブルシューティング)メールアラートのカスタマイズが消えた場合のトラブルシューティング シナリオ: アプライアンスのアップグレード後に、メールアラートのカスタマイズ内容が失われます。 これは VM/ベアメタル上での Runtime Fabric の制限であり、​[Runtime Fabric アプライアンスのアップグレード前](https://docs.mulesoft.com/jp/runtime-fabric/1.13/upgrade-index#before-you-upgrade-the-runtime-fabric-appliance)​のドキュメントに記載されています。推奨される対策は、アップグレード前にカスタマイズ内容をすべてバックアップしておき、アップグレードの完了後に再び適用することです。 ## [](#外部ログ転送のトラブルシューティング)外部ログ転送のトラブルシューティング ### [](#ログアグリゲーターでは-tls-v1-2-の使用が必須)ログアグリゲーターでは TLS v1.2 の使用が必須 Runtime Fabric の外部ログ転送ライブラリでは TLS v1.3 がサポートされていません。 ログアグリゲーターで TLS v1.2 を使用していないと、ログが転送されず、外部ログ転送ポッドに次のような警告が表示されます。 \[ warn\] \[engine\] failed to flush chunk '8-1652967809.949249428.flb', retry in 10 seconds: task\_id=5, input=tail.0 > output=es.0 (out\_id=0) \[ warn\] \[engine\] chunk '8-1652967799.665591977.flb' cannot be retried: task\_id=1, input=tail.0 > output=es.0 ログアグリゲーターで、次のようなエラーメッセージが表示される場合があります。 \[WARN \]\[o.e.h.AbstractHttpServerTransport\] \[\] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=0.0.0.0/0.0.0.0:9200, remoteAddress=/\*.\*.\*.\*:1787} io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context ... Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context このような場合は、TLSv v1.2 を有効にするか、中間ノードで TLS v1.2 セッションを終了して最終的な宛先までの新しい TLS v1.3 セッションを作成するようにネットワーキングインフラストラクチャを設定してください。 # VM/ベアメタルの Runtime Fabric の制限事項 次の情報は、VM/ベアメタルの Anypoint Runtime Fabric のインストール、設定、管理を行うときに重要です。 ## [](#ノード環境グループの制限事項)ノード、環境、グループの制限事項 次の表では、Runtime Fabric の設定に関する重要な制限事項を示しています。
コンポーネント 制限事項

コントローラーノード

コントローラーノードの最大数は 5 です。

ワーカーノード

ワーカーノードの最大数は 16 です。

アプリケーションあたりのレプリカ数

アプリケーションあたりのレプリカの最大数は 8 です。

ワーカーノードあたりのレプリカ数

ワーカーノードあたりのデプロイできるレプリカの最大数は 40 です。

バースティングの必要が生じた場合にレプリカ間でのコアを共有できるようにするために、実行する​レプリカの数はコアあたり​ 20 ～ 25 個までにしてください。これにより、レプリカが多すぎるために各ワーカーノードで実行されている Runtime Fabric の内部コンポーネントがオーバーロードになる事態を防ぐことができます。

Runtime Fabric あたりの関連付けられた環境数

Runtime Fabric あたりの環境の最大数は 50 です。

ビジネスグループ

ビジネスグループの組織あたり最大 50 個の Runtime Fabric を作成できます。サブ組織には、別のサブ組織で共有される Runtime Fabric に加えて、最大 50 個の Runtime Fabric を含めることができます。たとえば、親組織 A とその子組織 B がある場合、組織 A に 50 個の Runtime Fabric、組織 B に 50 個の Runtime Fabric を含めることができます。 組織 A の 50 個の Runtime Fabric をすべて組織 B と共有することもでき、その結果、組織 B のリストビューには合計 100 個の Runtime Fabric が表示されます。

オブジェクトストアの永続性

Mule アプリケーションのレプリカと再起動でデータの永続性に対処するために、Anypoint Runtime Fabric では永続性ゲートウェイを使用します。​「永続性ゲートウェイ」​を参照してください。
## [](#内部ロードバランサーのリソース割り当てとパフォーマンス)内部ロードバランサーのリソース割り当てとパフォーマンス 次の表は、CPU コアの数に基づいて、内部ロードバランサーの 1 つのレプリカで処理できるおおよその要求数 (平均 10 KB) を示しています。この情報は、​[「VM/ベアメタルの Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​で説明されているパフォーマンステスト結果に基づいています。
vCPU コア 1 秒あたりの最大要求数 (接続を再利用) 1 秒あたりの最大要求数 (接続の再利用なし)

1.00

2000

175

0.75

1500

100

0.50

1000

50

0.25

100

10
内部ロードバランサーは、VM/ベアメタルの Runtime Fabric のコントローラーノードで実行されます。インバウンドトラフィックの量と種別に基づいて、VM のサイズを設定します。内部ロードバランサーに割り当てることができるのは、各 VM で使用可能な CPU コアの半分のみです。 詳細は、​[「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 ## [](#オペレーティングシステムの制限事項)オペレーティングシステムの制限事項 次の表では、Runtime Fabric のホストオペレーティングシステムに関する既知の制限事項を示しています。
オペレーティングシステム 制限事項

RHEL 8

  • インストールに失敗するため、​fabric.tf​ で省略可能な環境変数 ​disable_selinux​ を ​false​ に設定しないでください。

  • SELinux を適用モードに設定しないでください。

RHEL 7

  • SELinux を有効にした場合、ホストで実行されているサードパーティソフトウェアでポリシー設定が SELinux から変更される場合があります。

  • デフォルトのポリシーを変更しない場合は、SELinux を適用モードに設定しても問題ありません。

RHEL

Azure ベアメタル上では Runtime Fabric は論理ボリュームマネージャー (LVM) を使用する RHEL のインスタンスのみをサポートしています。Azure ベアメタル上の LVM を使用しない RHEL インスタンスはサポートされません。
## [](#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響 Anypoint Runtime Fabric には特定のハードウェアおよび OS の要件があります。MuleSoft サポートでは、​[VM/ベアメタル上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​ と​[自己管理型 Kubernetes 上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ のインストールの前提条件で指定されている要件の検証と認証に基づいて、サポート SLA と重要度レベルを提供しています。 一部のサードパーティソフトウェアでは、ホストへのルートアクセス権が必要です。このようなソフトウェア (ウイルス対策ソフトウェアおよび DPI ソフトウェアを含むがこれに限定されない) が Runtime Fabric の動作および要件と干渉することがわかっています。MuleSoft サポートがウイルス対策ソフトウェアを検出した多くのサポートケースで、ポートのブロック、ノード間通信のブロック、Docker のデフォルトブリッジの削除、ファイルシステムへのアクセスの問題など、Runtime Fabric のインストール、アップグレード、通常の操作と干渉する問題が確認されています。 Runtime Fabric で異常な動作が見つかった場合は、サードパーティソフトウェア (ウイルス対策ソフトウェアや DPI ソフトウェアを含む) がその動作の原因となっているかを判断するため、これらのソフトウェアを無効にするよう要求される場合があります。これらのソフトウェアを無効にすることで適切な Runtime Fabric の機能が回復する場合には、そのソフトウェアパッケージと Runtime Fabric 間で互換性がないことを暗に示していると思われるため、サポートケースは解決済みであるとみなされます。 Runtime Fabric の特定のコンポーネントと干渉する従来のセキュリティツールを実行することが厳密に要求される場合は、この要件を満たせるように Kubernetes をサポートするベンダーおよびセキュリティエキスパートにサポートを依頼できます。クラウドプラットフォームベンダーでは多くの場合、 [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)​ などのよく知られたセキュリティベンチマークと一貫性があるクラウド中心のコントロールが追加されます。 # VM/ベアメタルの Runtime Fabric の定期メンテナンスの実行

可能な場合は、Equality の会社の値に一致するように、含めない用語を変更しました。顧客の実装に対する影響を回避するために、一部の用語は変更されていません。
VM/ベアメタルの Runtime Fabric を使用する場合、次の手順を使用して定期メンテナンスを実行できます。これには、OS パッチとセキュリティの更新の適用が含まれます。 ## [](#コントローラーノードのメンテナンス)コントローラーノードのメンテナンス コントローラーノードは、Runtime Fabric クラスターのエントリポイントであり、アプリケーションワークロードは実行しません。 1 台ずつ、すべてのコントローラーノードを更新します。 1. 上流の TCP ロードバランサーで、負荷分散プールからコントローラーノードを削除します。 2. 必要なパッチを適用してからノードを再起動します。 3. コントローラーノードで更新が完了したら、ノードをクラスターに戻して、次のノードを更新します。 ## [](#ワーカーノードのメンテナンス)ワーカーノードのメンテナンス ワーカーノードを更新するには、次の手順を実行します。 1. コントローラーノードで、​`gravity shell`​ コマンドを実行します。 2. すべてのノードの状況が ​`READY`​ であることを確認します。 ```none $ kubectl get nodes NAME STATUS ROLES AGE VERSION 172.31.0.9 Ready node 1d v1.x.x 172.31.0.8 Ready master 1d v1.x.x ``` 3. アプリケーション名前空間 (環境 ID) を取得します。 ```none $ kubectl get ns NAME STATUS AGE default Active 1d fff5df7b-c49d-48c9-967d-0071412722x4 Active 1d kube-node-lease Active 1d kube-public Active 1d kube-system Active 1d monitoring Active 1d rtf Active 1d ``` コマンド出力において、アプリケーション名前空間は長い文字列として表されます。上の例では、アプリケーション名前空間は ​`fff5df7b-c49d-48c9-967d-0071412722x4`​ です。 Runtime Fabric クラスターが複数の環境に関連付けられている場合は、複数のアプリケーション名前空間の値が表示されます。 4. 名前空間でポッドとノードが実行中であることを確認します。 ```none $ kubectl -n get pod -owide ``` コマンド出力では、​`READY`​ 列に ​`Running`​ と表示されています。 ```none NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES my-app-name-1-84f95cb7c9-glktk 2/2 Running 0 9m27s 10.244.88.29 172.31.0.9 ``` 複数の環境を使用している場合は、以下のステップを各環境で実行する必要があります。 5. 更新が必要な各ワーカーノードに対して次の手順を実行します。 1. ノードをドレーンします。 ```none $ kubectl drain --ignore-daemonsets --delete-local-data ``` ノードをドレーンすると、次のアクションが実行されます。 - アプリケーションが別のノード上でスケジュールされてから削除されます。 - ノードの状況が ​`SchedulingDisabled`​ に変更されます。
アプリケーションのレプリカが最低 2 つ実行されていて、アプリケーションのデプロイ時に ​[Enforce deploying replicas across nodes (ノード間でレプリカのデプロイメントを適用)]​ が指定されていない限り、ドレーン処理中はサービスが中断します。
2. ノードの状況が ​`Ready,SchedulingDisabled`​ であることを確認します。 ```none $ kubectl get node NAME STATUS ROLES AGE VERSION 172.31.0.9 Ready,SchedulingDisabled node 1d v1.x.x ``` 3. ドレーン済みのノードでアプリケーションポッドが実行中ではないことを確認します。 ```none $ kubectl get pod -n -owide ``` `NODE`​ 列に表示されるコマンド出力に、ドレーン済みのノードでアプリケーションポッドが実行中ではないことが表示されていることを確認してください。 4. OS パッチを適用してからノードを再起動します。 5. 再起動の完了後、ノードでスケジューリングを再び有効化します。 ```none $ kubectl uncordon 172.31.0.9 node/172.31.0.9 uncordoned $ kubectl get node NAME STATUS ROLES AGE VERSION 172.31.0.9 Ready node 1d v1.x.x ``` # アップグレードの前提条件 OpenShift をバージョン 2.6.52 以前からバージョン 2.7.0 以降にアップグレードする場合、手動で ​`rtfd`​ コンテナリソースを目的の値に増やす必要があります。​`rtfd`​ コンテナリソース値の案内については、​[「拡張性ベンチマーク」](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale)​を参照してください。 `rtfd`​ コンテナリソースを更新する手順は、次のとおりです。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. **Runtime Fabric**​ Operator を選択し、Runtime Fabric インスタンスの ​`.yaml`​ ファイルを開きます。 ![Runtime Fabric インスタンスの .yaml ファイル。](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/runtime-fabric-yaml.png) 3. `.yaml`​ ファイルで、​`spec:`​ > ​`agent:`​ > ​`rtfd:`​ に移動し、リソース割り当てを推奨値に更新します。 ![rtfd リソース割り当てを推奨値に更新します。](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtfd-change-values.png) 4. **\[Save (保存)\]**​ をクリックします。
Helm ベースのアップグレードではプレリリースの手動上書きが考慮されるため、Helm ベースのインストールで ​values.yaml​ ファイルの ​rtfd​ コンテナリソースが以前に上書きされている場合、拡張性ガイドラインに従って手動で割り当てを増やす必要があります。
# アップグレードの前提条件 OpenShift をバージョン 2.6.52 以前からバージョン 2.7.0 以降にアップグレードする場合、手動で ​`rtfd`​ コンテナリソースを目的の値に増やす必要があります。​`rtfd`​ コンテナリソース値の案内については、​[「拡張性ベンチマーク」](https://docs.mulesoft.com/runtime-fabric/latest/rtf-scale)​を参照してください。 `rtfd`​ コンテナリソースを更新する手順は、次のとおりです。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. **Runtime Fabric**​ Operator を選択し、Runtime Fabric インスタンスの ​`.yaml`​ ファイルを開きます。 ![Runtime Fabric インスタンスの .yaml ファイル。](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/runtime-fabric-yaml.png) 3. `.yaml`​ ファイルで、​`spec:`​ > ​`agent:`​ > ​`rtfd:`​ に移動し、リソース割り当てを推奨値に更新します。 ![rtfd リソース割り当てを推奨値に更新します。](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtfd-change-values.png) 4. **\[Save (保存)\]**​ をクリックします。
Helm ベースのアップグレードではプレリリースの手動上書きが考慮されるため、Helm ベースのインストールで ​values.yaml​ ファイルの ​rtfd​ コンテナリソースが以前に上書きされている場合、拡張性ガイドラインに従って手動で割り当てを増やす必要があります。
# アプリケーションスケジュールの管理 Runtime Manager を使用して、実行中のアプリケーションを変更することなく、デプロイされたアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 たとえば、アプリケーションのうちの 1 つがメンテナンス中である間に、スケジュールされたジョブを無効にすることができます。 **\[Schedules (スケジュール)\]**​ タブでは以下を行うことができます。 - 実行中のアプリケーションでスケジュールを表示する。 - アプリケーションでスケジュールを変更する。 - スケジュールを変更せずに、スケジュールされたジョブを直ちに実行する。 - フローのスケジュールを無効または有効にする。 定期的な間隔でトリガーする​_一定間隔_​、または指定した Cron 式に基づいた日時にトリガーする ​_Cron_​ として、Scheduler コンポーネントの種類を設定します。
スケジュールタイプを (一定間隔から Cron、またはその逆に) 変更するには、アプリケーションを更新して再デプロイする必要があります。 デプロイされたアプリケーションのスケジュールタイプを変更することはできません。
この機能を使用するための必要な最小 Mule Runtime Engine バージョンは 4.1.2 以降であり、最小 Runtime Fabric Agent バージョンは 2.0.0 以降です。
## [](#design-schedule)スケジュールの設計に関する考慮事項 スケジュールを設計するときには、次の点を考慮してください。 - Runtime Fabric スケジューラーは、毎回の実行時にジョブ設定を読み取ります。 スケジューラー設定を更新した場合、次回スケジューラーが実行されるときに変更が有効になります。 - スケジュールを変更すると、アプリケーションが再デプロイされます。 - アプリケーションが実行されていないためにスケジュールされたジョブがトリガーされない場合は、アプリケーションが再起動すると、Runtime Fabric はすぐにジョブをトリガーします。 - スケジュールは、スケジューラーの定義されたタイムゾーンに基づきます。 - 複数のレプリカがあるアプリケーションの場合、Runtime Fabric はスケジュールされたジョブをすべてのレプリカで実行します。 **\[Run (実行)\]**​ をクリックしてスケジュールされたジョブを直ちに実行する場合、スケジューラーは 1 つのレプリカで実行されます。 Runtime Fabric は、レプリカ全体に複数の同時スケジューラーを分散します。 - スクリプトを使用して Runtime Fabric のスケジュールを管理することはできません。 Runtime Fabric のスケジュールを管理するには、​**\[Schedules (スケジュール)\]**​ タブまたは Runtime Fabric API を使用してください。 - フロー名には、文字、数字、ハイフン (​`-`​)、アンダースコア (​`_`​)、ピリオド (​`.`​) のみを含めることができます。文字 ​`/`​、​`[`​、​`]`​、​`{`​、​`}`​、​`#`​ は無効です。 - プレースホルダーのあるスケジューラーを使用してスケジュールを作成する場合、スケジュールの作成時に表示される値は、プレースホルダーがいつ検出されるかによって異なります。例: - アプリケーションがデプロイされる前に値が使用可能な場合、その値が表示されます。 - 値がデプロイメントの前に使用可能で、デプロイメントのプロパティに依存する場合、推定値が表示されます。 - 値がデプロイメント時に提供されるプレースホルダー (​`${cronExpression}`​ など) である場合、プレースホルダーの正確な値はユーザーインターフェースに表示されません。 - Runtime Fabric ではデフォルト値の ​`60000`​ が使用されます。 - スケジューラーに変更を加えた場合は、アプリケーションを Exchange に再アップロードして、スケジューラーが期待どおりに動作するようにする必要があります。 ## [](#始める前に)始める前に Runtime Manager のスケジュール機能を使用するには、Anypoint Studio 7.13 を使用して 1 つ以上の Scheduler 要素を含むアプリケーションをデプロイします。 ![Anypoint Studio キャンバスの Scheduler コンポーネント](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/ch2-scheduler-studio.png) アプリケーションをデプロイしたら、Runtime Manager でスケジュールを管理できます。 アプリケーションが実行されている必要はありません。 Runtime Manager UI にスケジュールを表示するには、Mule Maven Facade v3 を使用して Maven 経由で Runtime Fabric にデプロイしてください。 ## [](#runtime-manager-でアプリケーションを表示して管理する)Runtime Manager でアプリケーションを表示して管理する アプリケーションを Runtime Fabric にデプロイしたら、Runtime Manager で Scheduler 要素を表示して管理します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 Runtime Manager では、Scheduler 要素がアプリケーションに表示される順序でリストされます。 ![「Schedules (スケジュール)」 ページの (1) フロー名と (2) 頻度リンク。](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/ch2-scheduler-rtm.png) - **\[Name (名前)\]**​ 列には、Scheduler 要素を含むフローの名前 (1) が表示されます。 - **\[Schedule (スケジュール)\]**​ 列の頻度リンク (2) には、要素のスケジュールが表示されます。 4. ジョブが開始および終了した日時の詳細を確認する場合は、ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 ![ナビゲーションメニューの \[Logs (ログ)\] オプション。](_images/ch2-logs-rtm.png) 5. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 表示されるスケジュールエディターは、スケジュールタイプによって異なります。 - [Fixed frequency (一定間隔)](#change-fixed-frequency-schedule) - [Cron](#change-cron-schedule) 6. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-fixed-frequency-schedule)一定間隔スケジュールを変更する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![一定間隔スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/ch2-scheduler-fixed-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 ![一定間隔スケジュール設定](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/ch2-scheduler-editor-fixed.png) 頻度には、ミリ秒、秒、分、時間、または日を指定できます。 コール間の最小の推奨頻度は 10 秒です。 6. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ### [](#change-cron-schedule)Cron スケジュールを変更する Cron 式を使用すると、「毎週金曜日の午前 9 時 00 分から午前 10 時 00 分まで 5 分おき」といった複雑なスケジュール頻度を作成できます。 Cron スケジュールタイプの頻度を変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 **\[Schedule (スケジュール)\]**​ 列には、要素のスケジュールが表示されます。 ![Cron スケジュールタイプ](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/ch2-scheduler-cron-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ (1) チェックボックスをオフにしてスケジュールを無効にします。 ![(1) \[Enabled (有効)\] オプションと (2) \[Quick reference (クイックリファレンス)\] リンクを含む Cron スケジュール設定](_images/ch2-scheduler-editor-cron.png) 6. スケジュールエディターで ​**\[Quick reference (クイックリファレンス)\]**​ (2) をクリックして、必須項目と許可される値のテーブルを展開するか折りたたみます。 この例の Cron 式は、10 秒間隔のスケジュールを設定しています。 Cron トリガーの作成についての詳細は、次の方法で確認できます。 1. [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation)​を参照します。 2. バージョンを選択し、​**\[Documentation (ドキュメント)\] > \[User’s Guide (ユーザーガイド)\] > \[Tutorial (チュートリアル)\]**​ をクリックして、​**\[CronTrigger\]**​ レッスンをクリックします。 7. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#run-immediately)スケジュールされたジョブの即時実行 毎晩実行するジョブを今すぐデバッグする場合は、アプリケーションでスケジュールを更新しなくても、実行中のジョブをトリガーできます。実行中のスケジューラーのインスタンス間でジョブをトリガーすると、指定された期間のタイマーがリセットされます。
スケジュールされたジョブを直ちに実行する場合、複数のレプリカがあるアプリケーションの場合でも、スケジューラーは 1 つのレプリカで実行されます。
スケジュールを上書きしてジョブを直ちに実行する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Run (実行)\]**​ をクリックします。 ## [](#disable-enable-scheduler)Scheduler 要素の無効化または有効化 接続しているアプリケーションがメンテナンス中である間に、スケジュールされたジョブを無効にし、メンテナンスの完了後に再度有効にすることができます。 スケジューラーを再度有効にするまで、Runtime Fabric はスケジュールされたジョブを実行しません。 **既知の問題**​: スケジューラーを無効にしても、スケジューラーはアプリケーションの起動時に実行されます。スケジューラーが実行されないようにする場合は、Anypoint Studio を使用してアプリケーションで ​`startdelay`​ プロパティを 5 秒に設定します。 Scheduler 要素を無効にする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Disable (無効化)\]**​ をクリックします。 スケジュールエディターで ​**\[Enabled (有効)\]**​ を選択解除または選択して、スケジュールを無効または有効にすることもできます。 ![スケジュールエディターので \[Enabled (有効)\] 切り替え](_images/ch2-scheduler-enable.png) ## [](#関連情報)関連情報 - [Scheduler Endpoint (Trigger)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation) - [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) # アプリケーションデプロイメント用の名前空間の作成 Anypoint Runtime Fabric バージョン 1.12 以降では、アプリケーションデプロイメント用に独自の名前空間を作成できます。 アプリケーションを Anypoint Platform 環境にデプロイすると、Runtime Fabric によって環境の識別子を使用して新しいデフォルトの名前空間が作成されます。ただし、適切な Kubernetes 表示ラベルを使用して名前空間を作成または変更できる場合、Runtime Fabric によってアプリケーションがデフォルトの名前空間ではなくその名前空間にデプロイされます。 ## [](#名前空間を作成する)名前空間を作成する 1. 名前空間を作成する権限を持つユーザーとして Kubernetes ワークステーションにログインします。 2. 次のコマンドを実行します。 kubectl create ns kubectl label ns rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= - ``​ を名前空間の名前に置き換えます。 - ``​ を環境の正しい ID に置き換えます。 これらのコマンドを実行した後で、​``​ によって識別される Anypoint Platform 環境にデプロイされるアプリケーションが ​``​ 名前空間内に作成されます。 . アプリケーションを新しい名前空間にデプロイする前に、自動生成された名前空間とその中にあり新しい名前空間と同じ環境 ID を使用するアプリケーションをすべて削除します。 ## [](#カスタム名前空間のトラブルシューティング)カスタム名前空間のトラブルシューティング Runtime Fabric 用の名前空間を作成しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#複数の名前空間で同じ環境-id-を使用)複数の名前空間で同じ環境 ID を使用 次の例で示しているように、同じ環境 ID を使用する名前空間を複数作成したとしましょう。 $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers このような場合、Runtime Fabric はデプロイメントに失敗し、Runtime Manager でエラーメッセージが作成されます。 名前空間を削除する前に、本番アプリケーションをその名前空間にデプロイしていないことを確認してください。 # アプリケーションデプロイメント用の名前空間の作成 Anypoint Runtime Fabric バージョン 1.12 以降では、アプリケーションデプロイメント用に独自の名前空間を作成できます。 アプリケーションを Anypoint Platform 環境にデプロイすると、Runtime Fabric によって環境の識別子を使用して新しいデフォルトの名前空間が作成されます。ただし、適切な Kubernetes 表示ラベルを使用して名前空間を作成または変更できる場合、Runtime Fabric によってアプリケーションがデフォルトの名前空間ではなくその名前空間にデプロイされます。 ## [](#名前空間を作成する)名前空間を作成する 1. 名前空間を作成する権限を持つユーザーとして Kubernetes ワークステーションにログインします。 2. 次のコマンドを実行します。 ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - ``​ を名前空間の名前に置き換えます。 - ``​ を RTF エージェントが含まれる名前空間の名前に置き換えます。 - ``​ を環境の正しい ID に置き換えます。 - ``​ をビジネスグループの正しい ID に置き換えます。 これらのコマンドを実行した後で、​``​ と ​``​ によって識別される Anypoint Platform 環境にデプロイされるアプリケーションが ​``​ で実行される RTF エージェントによって ​``​ 名前空間内に作成されます。アプリケーションを新しい名前空間にデプロイする前に、自動生成された名前空間とその中にあり新しい名前空間と同じ環境 ID を使用するアプリケーションをすべて削除します。 ## [](#カスタム名前空間のトラブルシューティング)カスタム名前空間のトラブルシューティング Runtime Fabric 用の名前空間を作成しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#複数の名前空間で同じ環境-id-を使用)複数の名前空間で同じ環境 ID を使用 次の例で示しているように、同じ環境 ID を使用する名前空間を複数作成したとしましょう。 ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` このような場合、Runtime Fabric はデプロイメントに失敗し、Runtime Manager でエラーメッセージが作成されます。 名前空間を削除する前に、本番アプリケーションをその名前空間にデプロイしていないことを確認してください。 # アプリケーションデプロイメント用の名前空間の作成 Anypoint Runtime Fabric バージョン 1.12 以降では、アプリケーションデプロイメント用に独自の名前空間を作成できます。 アプリケーションを Anypoint Platform 環境にデプロイすると、Runtime Fabric によって環境の識別子を使用して新しいデフォルトの名前空間が作成されます。ただし、適切な Kubernetes 表示ラベルを使用して名前空間を作成または変更できる場合、Runtime Fabric によってアプリケーションがデフォルトの名前空間ではなくその名前空間にデプロイされます。 ## [](#名前空間を作成する)名前空間を作成する 1. 名前空間を作成する権限を持つユーザーとして Kubernetes ワークステーションにログインします。 2. 次のコマンドを実行します。 ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - ``​ を名前空間の名前に置き換えます。 - ``​ を RTF エージェントが含まれる名前空間の名前に置き換えます。 - ``​ を環境の正しい ID に置き換えます。 - ``​ をビジネスグループの正しい ID に置き換えます。 これらのコマンドを実行した後で、​``​ と ​``​ によって識別される Anypoint Platform 環境にデプロイされるアプリケーションが ​``​ で実行される RTF エージェントによって ​``​ 名前空間内に作成されます。アプリケーションを新しい名前空間にデプロイする前に、自動生成された名前空間とその中にあり新しい名前空間と同じ環境 ID を使用するアプリケーションをすべて削除します。 ## [](#カスタム名前空間のトラブルシューティング)カスタム名前空間のトラブルシューティング Runtime Fabric 用の名前空間を作成しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#複数の名前空間で同じ環境-id-を使用)複数の名前空間で同じ環境 ID を使用 次の例で示しているように、同じ環境 ID を使用する名前空間を複数作成したとしましょう。 ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` このような場合、Runtime Fabric はデプロイメントに失敗し、Runtime Manager でエラーメッセージが作成されます。 名前空間を削除する前に、本番アプリケーションをその名前空間にデプロイしていないことを確認してください。 # アプリケーションデプロイメント用の名前空間の作成 Anypoint Runtime Fabric バージョン 1.12 以降では、アプリケーションデプロイメント用に独自の名前空間を作成できます。 アプリケーションを Anypoint Platform 環境にデプロイすると、Runtime Fabric によって環境の識別子を使用して新しいデフォルトの名前空間が作成されます。ただし、適切な Kubernetes 表示ラベルを使用して名前空間を作成または変更できる場合、Runtime Fabric によってアプリケーションがデフォルトの名前空間ではなくその名前空間にデプロイされます。 ## [](#名前空間を作成する)名前空間を作成する 1. 名前空間を作成する権限を持つユーザーとして Kubernetes ワークステーションにログインします。 2. 次のコマンドを実行します。 ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - ``​ を名前空間の名前に置き換えます。 - ``​ を RTF エージェントが含まれる名前空間の名前に置き換えます。 - ``​ を環境の正しい ID に置き換えます。 - ``​ をビジネスグループの正しい ID に置き換えます。 これらのコマンドを実行した後で、​``​ と ​``​ によって識別される Anypoint Platform 環境にデプロイされるアプリケーションが ​``​ で実行される RTF エージェントによって ​``​ 名前空間内に作成されます。アプリケーションを新しい名前空間にデプロイする前に、自動生成された名前空間とその中にあり新しい名前空間と同じ環境 ID を使用するアプリケーションをすべて削除します。 ## [](#カスタム名前空間のトラブルシューティング)カスタム名前空間のトラブルシューティング Runtime Fabric 用の名前空間を作成しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#複数の名前空間で同じ環境-id-を使用)複数の名前空間で同じ環境 ID を使用 次の例で示しているように、同じ環境 ID を使用する名前空間を複数作成したとしましょう。 ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` このような場合、Runtime Fabric はデプロイメントに失敗し、Runtime Manager でエラーメッセージが作成されます。 名前空間を削除する前に、本番アプリケーションをその名前空間にデプロイしていないことを確認してください。 # アプリケーションデプロイメント用の名前空間の作成 Anypoint Runtime Fabric バージョン 1.12 以降では、アプリケーションデプロイメント用に独自の名前空間を作成できます。 アプリケーションを Anypoint Platform 環境にデプロイすると、Runtime Fabric によって環境の識別子を使用して新しいデフォルトの名前空間が作成されます。ただし、適切な Kubernetes 表示ラベルを使用して名前空間を作成または変更できる場合、Runtime Fabric によってアプリケーションがデフォルトの名前空間ではなくその名前空間にデプロイされます。 ## [](#名前空間を作成する)名前空間を作成する 1. 名前空間を作成する権限を持つユーザーとして Kubernetes ワークステーションにログインします。 2. 次のコマンドを実行します。 ```copy kubectl create ns kubectl label ns rtf.mulesoft.com/agentNamespace= rtf.mulesoft.com/role=workers rtf.mulesoft.com/envId= rtf.mulesoft.com/org= ``` - ``​ を名前空間の名前に置き換えます。 - ``​ を RTF エージェントが含まれる名前空間の名前に置き換えます。 - ``​ を環境の正しい ID に置き換えます。 - ``​ をビジネスグループの正しい ID に置き換えます。 これらのコマンドを実行した後で、​``​ と ​``​ によって識別される Anypoint Platform 環境にデプロイされるアプリケーションが ​``​ で実行される RTF エージェントによって ​``​ 名前空間内に作成されます。アプリケーションを新しい名前空間にデプロイする前に、自動生成された名前空間とその中にあり新しい名前空間と同じ環境 ID を使用するアプリケーションをすべて削除します。 ## [](#カスタム名前空間のトラブルシューティング)カスタム名前空間のトラブルシューティング Runtime Fabric 用の名前空間を作成しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#複数の名前空間で同じ環境-id-を使用)複数の名前空間で同じ環境 ID を使用 次の例で示しているように、同じ環境 ID を使用する名前空間を複数作成したとしましょう。 ```copy $ kubectl get ns custom-namespace-1 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc $ kubectl get ns custom-namespace-2 -oyaml labels: rtf.mulesoft.com/envId: b164ad54-7e15-4c8b-a7ab-18011a361d81 rtf.mulesoft.com/role: workers rtf.mulesoft.com/agentNamespace=rtf rtf.mulesoft.com/org=70be136d-28ec-4395-883f-e5b777a00abc ``` このような場合、Runtime Fabric はデプロイメントに失敗し、Runtime Manager でエラーメッセージが作成されます。 名前空間を削除する前に、本番アプリケーションをその名前空間にデプロイしていないことを確認してください。 # オペレーションセンターを使用した VM/ベアメタルの Runtime Fabric の監視 組み込みオペレーションセンターを使用すると、VM/ベアメタルクラスターの Runtime Fabric で実行されるアプリケーションの一部のメトリクスを監視できます。 オペレーションセンターの機能は限定的です。次のようなことを行う必要がある場合は、Anypoint Platform で適切な機能を使用してください。 - [SSO の統合](https://docs.mulesoft.com/jp/access-management/external-identity) - [Anypoint Monitoring を使用した詳細なアプリケーション監視](https://docs.mulesoft.com/jp/monitoring/) - [Runtime Fabric の詳細な健全性レポート](https://docs.mulesoft.com/runtime-fabric/latest/view-health) ## [](#オペレーションセンターへのアクセス)オペレーションセンターへのアクセス Anypoint Runtime Fabric 内でオペレーションセンターを使用して、ダッシュボードの監視、ログの表示、デバッグ情報のダウンロードを行うことができます。 Runtime Fabric のインストールプロセス中に、ログへの最新の出力の 1 つに、オペレーションセンターへのログインに必要な次の情報が含まれます。 Ops Center access: URL: https://:32009/web User: admin@runtime-fabric Password: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
インストーラーノードのログからオペレーションセンター URL を取得する必要があります。ログファイルはクラスターのすべてのノードで使用できますが、オペレーションセンターの URL とログイン情報があるのはインストーラーノードのみです。
1. ターミナルを使用して、インストーラー VM へのシェル/SSH 接続を開きます。 2. 次のコマンドを使用してログファイルを開き、ログイン情報を検索します。 cat /var/log/rtf-init.log | grep -B 1 -A 3 "Ops Center" 3. 詳細を安全な場所に保存します。 4. Web ブラウザーを開き、該当の URL に移動します (​``​ は、任意のコントローラー VM の公開または非公開 IP アドレスで置き換えます)。 5. ログから取得したログイン情報を使用して、Runtime Fabric のオペレーションセンターにログインします。
ポート 32009 が開いており、セキュリティグループ、ネットワークセキュリティグループ、またはファイアウォールルール内でそのポートにアクセスできることを確認します。 非公開 IP アドレスを使用する場合、VM が存在しているネットワークと同じ内部ネットワークにアクセスできることを確認します。
## [](#オペレーションセンターへのアクセスをもう一度取得する)オペレーションセンターへのアクセスをもう一度取得する インストールログが失われた場合、次の手順を実行します。 1. いずれかのコントロールノードにターミナルを開きます。 2. SSH ターミナルから、次のコマンドを実行して、オペレーションセンターにログインするための管理者権限を持つ新規ユーザーを作成します。​`--email`​ と ​`--password`​ について適切な値を入力します。 sudo gravity planet enter -- --notty /usr/bin/gravity -- user create --ops-url=https://gravity-site.kube-system.svc.cluster.local:3009 --insecure --email=username@myorganization.com --password=myNewPassword --type=admin ## [](#ダッシュボードの表示)ダッシュボードの表示 オペレーションセンターにログインしたら、ページの左にタブのリストが表示されます。\[Monitoring (監視)\] に移動すると、表示可能なダッシュボードが表示されます。 ダッシュボードは次のカテゴリに分割されます。 - **\[Applications (アプリケーション)\]**​ には、アプリケーションデプロイメントのすべてのレプリカのメトリクスが表示されます。 - 検索条件には、アプリケーションがデプロイされる環境 ID、およびアプリケーションデプロイメント名が含まれます。 - **\[Cluster (クラスター)\]**​ には、Runtime Fabric クラスター全体のメトリクスが表示され、Kubernetes クラスターのマシンレベルの概要が提供されます。ノードの制限は、そのノードでスケジュールされた個別のポッドのすべての制限の合計です。イングレスなどの無制限ポッドは制限されていないため、制限に含まれません。このダッシュボードにはイングレス固有のデータは表示されませんが、すべてのポッドのマシンレベルのデータが表示されます。 - 検索条件には ​`nodename`​ が含まれており、これを使用して、特定の VM で絞り込むことができます。 - **\[CPU Core Usage (CPU コア使用量)\]**​ には、Mule アプリケーションの CPU 使用量のみが表示されます。 - **\[Ingress (イングレス)\]**​ には、内部ロードバランサーを実行しているすべてのレプリカのメトリクスが表示されます。 - **\[Pods (ポッド)\]**​ には、Runtime Fabric クラスター内で実行されている各サービスのメトリクスが表示されます。 - 検索条件には ​`namespace`​ と ​`podname`​ が含まれており、これを使用して、監視する特定のサービスを指定できます。 - `namespace`​ を選択すると、ダッシュボードにはアプリケーションがデプロイされている Anypoint 環境 ID に対応する GUID が表示されます。 - `podname`​ を選択すると、ダッシュボードにはアプリケーション名のプレフィックスが付けられた値が表示されます。これは、各アプリケーションデプロイメントのレプリカを参照します。 ## [](#アプリケーションからのメトリクスの表示)アプリケーションからのメトリクスの表示 オペレーションセンターから、デプロイされたアプリケーションのメトリクスを表示できます。 1. オペレーションセンターの左サイドバーで \* ​**\[Monitoring (監視)\]**​ をクリックします。 2. **\[Cluster (クラスター)\]**​ タブをクリックしてダッシュボードペインを開き、​**\[Applications (アプリケーション)\]**​ をクリックします。 3. \[Environment (環境)\] ドロップダウンで、アプリケーションがデプロイされた環境 ID を選択します。 4. \[Application (アプリケーション)\] ドロップダウンで、アプリケーション名を選択します。 ダッシュボードにアプリケーションのメトリクスが取り込まれます。デフォルトでは、オペレーションセンターには CPU、JVM ヒープメモリ、合計メモリ、ネットワーク、およびファイルシステムの使用量を示す一連のグラフが表示されます。 JVM ヒープメモリは Anypoint Monitoring にも表示されます。 ## [](#ログの表示)ログの表示 [「Runtime Fabric でのログの表示および設定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs)​を参照してください。 ## [](#デバッグ情報のダウンロード)デバッグ情報のダウンロード Runtime Fabric の問題が発生した場合、MuleSoft サポートチームが、デバッグ情報を含むパッケージ化ファイルを要求することがあります。以下の手順に従って、デバッグ情報パッケージを生成してください。 1. オペレーションセンターから、ページの左側にある ​**\[Admin (管理)\]**​ リンクをクリックします。 2. ページの右上にある ​**\[Download Debug Info (デバッグ情報をダウンロード)\]**​ をクリックします。 Runtime Fabric が要求を処理している間、新しいタブが開く場合があります。このファイルの生成には数分かかることがあります。 オペレーションセンターによって ​`report.tar.gz`​ という名前のファイルがダウンロードされます。 ## [](#cli-からの-kapacitor-ポッドの監視)CLI からの Kapacitor ポッドの監視 オペレーションセンターでは、Kapacitor ポッドへのアクセスで SSH がサポートされていません。代わりに、Kubernetes CLI を使用してこれらのポッドを監視することができます。 そのためには、Kubernetes にアクセスできるノードから次のコマンドを実行します。 \+ `kubectl exec -it -n monitoring -c kapacitor – sh` ## [](#関連情報)関連情報 - [Anypoint Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) - [Anypoint Runtime Fabric でのログ転送の設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) # クラスター設定 Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照してください。使用を開始するには、次の推奨設定を使用してクラスターを設定してください。
設定の種別 EKS-A EKS アプライアンス MuleSoft の要件

Infrastructure (インフラストラクチャ)

Vsphere/ベアメタル

AWS

事前プロビジョニングされたホスト

-

イングレス

Emissary​、Nginx イングレス、またはその他の使用可能なイングレスオプション。

Nginx イングレス

Nginx イングレス

顧客管理コンポーネント設定

ロードバランサー

MetalLB

ELB

-

顧客管理コンポーネント設定

監視

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Runtime Fabric の​要件と制限事項​の確認

ローカルクラスターレジストリ

Harbor​ またはその他の準拠する実装

ECR

クラスター内で実行される Docker レジストリ

クラスターサイズの制限

Kubernetes によって課されるクラスターサイズの制限。

1000 個の管理ノード

合計 21 個 (5 個のコントロールプレーンノード + 16 個のワーカーノード)

-

CK8s distro

EKS-D

EKS-D

カスタム distro (planet)

Runtime Fabric の​要件と制限事項​の確認

クラスター管理ツール

eksctl​ または ​eksctl-anywhere

eksctl

カスタムユーティリティ (rtfctl)

Runtime Fabric の​要件と制限事項​の確認
# クラスター設定 Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照してください。使用を開始するには、次の推奨設定を使用してクラスターをセットアップしてください。
設定の種別 EKS-A EKS アプライアンス MuleSoft の要件

Infrastructure (インフラストラクチャ)

Vsphere/ベアメタル

AWS

事前プロビジョニングされたホスト

-

イングレス

Emissary​、Nginx イングレス、またはその他の使用可能なイングレスオプション。

Nginx イングレス

Nginx イングレス

顧客管理コンポーネント設定

ロードバランサー

MetalLB

ELB

-

顧客管理コンポーネント設定

監視

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Runtime Fabric の​要件と制限事項​の確認

ローカルクラスターレジストリ

Harbor​ またはその他の準拠する実装

ECR

クラスター内で実行される Docker レジストリ

クラスターサイズの制限

Kubernetes によって課されるクラスターサイズの制限。

1000 個の管理ノード

合計 21 個 (5 個のコントロールプレーンノード + 16 個のワーカーノード)

-

CK8s distro

EKS-D

EKS-D

カスタム distro (planet)

Runtime Fabric の​要件と制限事項​の確認

クラスター管理ツール

eksctl​ または ​eksctl-anywhere

eksctl

カスタムユーティリティ (rtfctl)

Runtime Fabric の​要件と制限事項​の確認
# クラスター設定 Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照してください。使用を開始するには、次の推奨設定を使用してクラスターをセットアップしてください。
設定の種別 EKS-A EKS アプライアンス MuleSoft の要件

Infrastructure (インフラストラクチャ)

Vsphere/ベアメタル

AWS

事前プロビジョニングされたホスト

-

イングレス

Emissary​、Nginx イングレス、またはその他の使用可能なイングレスオプション。

Nginx イングレス

Nginx イングレス

顧客管理コンポーネント設定

ロードバランサー

MetalLB

ELB

-

顧客管理コンポーネント設定

監視

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Runtime Fabric の​要件と制限事項​の確認

ローカルクラスターレジストリ

Harbor​ またはその他の準拠する実装

ECR

クラスター内で実行される Docker レジストリ

クラスターサイズの制限

Kubernetes によって課されるクラスターサイズの制限。

1000 個の管理ノード

合計 21 個 (5 個のコントロールプレーンノード + 16 個のワーカーノード)

-

CK8s distro

EKS-D

EKS-D

カスタム distro (planet)

Runtime Fabric の​要件と制限事項​の確認

クラスター管理ツール

eksctl​ または ​eksctl-anywhere

eksctl

カスタムユーティリティ (rtfctl)

Runtime Fabric の​要件と制限事項​の確認
# クラスター設定 Runtime Fabric を最大限に活用するには、それぞれの Kubernetes (K8s) プロバイダーの設定仕様を参照してください。使用を開始するには、次の推奨設定を使用してクラスターをセットアップしてください。
設定の種別 EKS-A EKS アプライアンス MuleSoft の要件

Infrastructure (インフラストラクチャ)

Vsphere/ベアメタル

AWS

事前プロビジョニングされたホスト

-

イングレス

Emissary​、Nginx イングレス、またはその他の使用可能なイングレスオプション。

Nginx イングレス

Nginx イングレス

顧客管理コンポーネント設定

ロードバランサー

MetalLB

ELB

-

顧客管理コンポーネント設定

監視

Grafana/Prometheus

CloudWatch

Grafana/Prometheus

Runtime Fabric の​要件と制限事項​の確認

ローカルクラスターレジストリ

Harbor​ またはその他の準拠する実装

ECR

クラスター内で実行される Docker レジストリ

クラスターサイズの制限

Kubernetes によって課されるクラスターサイズの制限。

1000 個の管理ノード

合計 21 個 (5 個のコントロールプレーンノード + 16 個のワーカーノード)

-

CK8s distro

EKS-D

EKS-D

カスタム distro (planet)

Runtime Fabric の​要件と制限事項​の確認

クラスター管理ツール

eksctl​ または ​eksctl-anywhere

eksctl

カスタムユーティリティ (rtfctl)

Runtime Fabric の​要件と制限事項​の確認
# シークレットマネージャーからの TLS コンテキストのインポート (高度なユーザー向け) 環境に特有のセキュリティ要件がある場合や、特定の暗号化または TLS スイートの選択もしくは証明書のピン留めといった詳細な設定が必要な場合は、シークレットマネージャーから TLS コンテキストをインポートできます。 ## [](#前提条件)前提条件 シークレットマネージャーから TLS コンテキストをインポートするには、次の権限が必要です。 - Grant access to secrets (シークレットへのアクセス権の付与) - Manage Secret Groups (シークレットグループの管理) - Read secrets metadata (シークレットメタデータの読み取り) - Write secrets (シークレットの作成) これらの権限は、Anypoint アクセス管理の ​**\[Secrets Manager (シークレットマネージャー)\]**​ タブを使用して設定されます。 1. Anypoint Platform から ​**\[Access Management (アクセス管理)\]**​ を選択します。 アクセスできる場合、次のステップを実行して権限を追加します。 2. **\[Users (ユーザー)\]**​ を選択します。 3. ユーザー名が含まれる行を見つけ、​**\[Username (ユーザー名)\]**​ 列のリンクを選択します。 4. **\[Secrets Manager (シークレットマネージャー)\]**​ タブで次の操作を行います。 1. **\[Environment (環境)\]**​ を選択して、ドロップダウンリストから自分の環境を選択します。 2. **\[Permission(s) (権限)\]**​ を選択して ​**\[Select Access (アクセス権を選択)\]**​ を選択します。 3. **\[Select all (全て選択)\]**​ を選択します。
追加した権限が伝播されるまで最大 5 分ほどかかることがあります。
## [](#シークレットグループへの-tls-コンテキストの追加)シークレットグループへの TLS コンテキストの追加 シークレットマネージャーから TLS コンテキストをインポートする前に、TLS コンテキストを追加する必要があります。 TLS コンテキストをシークレットグループに追加するには、名前、対象、セキュリティ情報、バージョン、キーストア、および必要に応じてトラストストアを指定します。 1. **\[Secret Groups (シークレットグループ)\]**​ リストで、TLS コンテキストを追加するシークレットグループを選択します。 2. 左側のメニューで ​**\[TLS Context (TLS コンテキスト)\]**​ を選択し、​**\[Add TLS Context (TLS コンテキストを追加)\]**​ をクリックします。 3. **\[Create TLS Context (TLS コンテキストを作成)\]**​ ウィンドウで、必要な情報を追加します。 - **Name (名前)**​ TLS コンテキストの名前を入力します。 - **Target (対象)**​ Runtime Fabric の SSL ハンドシェイクを検証するため、​**\[Anypoint Security\]**​ を選択します。 - **TLS Version (TLS バージョン)**​ デフォルトでは、TLS 1.2 と TLS 1.3 が選択されています。 TLS 1.3 の利点についての詳細は、​[「Anypoint Runtime Fabric での TLS サポート」](https://docs.mulesoft.com/jp/anypoint-security/cipher-suites#tls-support-on-anypoint-runtime-fabric)​を参照してください。 - **Keystore (キーストア)**​ ドロップダウンリストから、TLS コンテキストを保存するキーストアを選択します。 シークレットマネージャーへのキーストアの追加についての詳細は、​[「シークレットグループの作成」](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-group-creation-task#add_keystore.adoc)​を参照してください。 PEM または非 PEM 種別のキーストアを選択できます。 - 必要に応じて、クライアントが信頼する証明書を保存するためにトラストストアを使用している場合、TLS コンテキストを追加するトラストストアを選択します。 クライアント認証を有効にする場合は、トラストストアが必要です。 - **Expiration Date (有効期限 (日))**​ 必要に応じて、証明書の有効期限を選択します。 4. 必要に応じて、​[クライアント認証を有効化](https://docs.mulesoft.com/jp/anypoint-security/enable-client-authentication)​します。 5. 必要に応じて、​[暗号化を選択](https://docs.mulesoft.com/jp/anypoint-security/cipher-suites)​します。 6. **\[Add certificate (証明書を追加)\]**​ をクリックします。 ## [](#import_tls_rtf)Runtime Fabric に TLS コンテキストをインポートする 1. **\[Runtime Manager\] > \[Runtime Fabrics\] > \[Inbound Traffic (インバウンドトラフィック)\] > \[Add certificates (証明書を追加)\]**​ で ​**\[Import from Secrets Manager (シークレットマネージャーからインポート)\]**​ を選択します。 このオプションはシークレットマネージャーから TLS コンテキストをインポートし、クライアント認証 (相互認証) の作成、暗号化の選択、TLS バージョンの選択などの高度な設定をサポートしています。 2. TLS コンテキストを含むシークレットグループが関連付けられている環境を選択します。 3. TLS コンテキストが設定されているシークレットグループを選択します。 4. Runtime Fabric に使用する TLS コンテキストを選択します。 5. 必要に応じて、​**\[View Details (詳細を表示)\]**​ をクリックすると、インポートする TLS コンテキストの詳細が表示されます。 ## [](#tls_support_rtf)関連情報 - [クライアント認証の有効化](https://docs.mulesoft.com/jp/anypoint-security/enable-client-authentication) - [暗号化スイート](https://docs.mulesoft.com/jp/anypoint-security/cipher-suites) - [サポート対象シークレット種別](https://docs.mulesoft.com/jp/anypoint-security/asm-secret-type-support-reference) # セキュア Runtime Fabric Anypoint Runtime Fabric 保護する方法については、以下を参照してください。 - [承認済み名前空間の設定](https://docs.mulesoft.com/jp/runtime-fabric/2.5/authorized-namespaces) - [ローカルレジストリの使用](https://docs.mulesoft.com/jp/runtime-fabric/2.5/configure-local-registry) - [MuleSoft Anypoint Runtime Fabric セキュリティアーキテクチャ](https://docs.mulesoft.com/jp/runtime-fabric/2.5/security-architecture) - [Kubernetes 強化ガイド](https://docs.mulesoft.com/jp/runtime-fabric/2.5/kubernetes-hardening-guide) # ビジネスグループと環境の Runtime Fabric への関連付け アプリケーションまたは API ゲートウェイを Anypoint Runtime Fabric にデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付ける必要があります。デプロイする環境でこの手順を実行するまで、Mule アプリケーションをデプロイするときに、デプロイメント対象として Runtime Fabric を選択することはできません。 環境を Runtime Fabric に関連付ける手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ セクションを選択します。 3. インストール中に使用された名前に基づいて、Runtime Fabric を選択します。 4. **\[Associated Environments (関連付けられた環境)\]**​ タブから、この Runtime Fabric に関連付ける環境を選択します。 5. **\[Apply (適用)\]**​ をクリックして変更を確認します。 ## [](#本番設定)本番設定 本番環境を選択すると、Runtime Fabric が本番設定で動作するように設定されていることを確認するダイアログが表示されます。これには、適切なハードウェア設定、ログ転送、アラート、および考えられる障害モードに関する情報が含まれます。 サポートされない設定で Runtime Fabric が実行されている場合、または Runtime Fabric が本番環境の要件を満たさない場合、次のいずれかのメッセージが表示されます。 - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` 詳細は、​[「Anypoint Runtime Fabric インストールの前提条件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​を参照してください。 Runtime Fabric で本番アプリケーションを運用およびデプロイする前に、適切な設定が完了している必要があります。 ## [](#ビジネスグループ全体で共有する)ビジネスグループ全体で共有する Runtime Fabric を組織のビジネスグループと共有できます。これにより、他のビジネスグループが 1 つの Runtime Fabric にアプリケーションをデプロイできます。この機能を使用するには、Runtime Fabric が登録されている組織のスコープにビジネスグループが含まれている必要があります。 ビジネスグループ全体で Runtime Fabric を共有する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ タブを選択します。 3. 管理する Runtime Fabric を選択します。 4. **\[Associated Environments (関連付けられた環境)\]**​ タブで、​**\[Add business group (ビジネスグループを追加)\]**​ をクリックします。 5. この Runtime Fabric と共有するビジネスグループを選択します。 ビジネスグループの環境のリストが表示されます。 6. この Runtime Fabric に関連付けるビジネスグループの環境を選択します。 7. **\[Apply (適用)\]**​ をクリックして変更を確認します。 ## [](#関連情報)関連情報 - [Runtime Fabric へのインバウンドトラフィックの有効化](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic) - [Anypoint Runtime Fabric でのログ転送の設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/runtime-fabric-logs) - [Anypoint Runtime Fabric でのアラートの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-alerting) # ビジネスグループと環境の Runtime Fabric への関連付け アプリケーションまたは API ゲートウェイを Anypoint Runtime Fabric にデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付ける必要があります。デプロイする環境でこの手順を実行するまで、Mule アプリケーションをデプロイするときに、デプロイメント対象として Runtime Fabric を選択することはできません。
Runtime Fabric アプライアンスはこの機能をサポートしていません。
## [](#ビジネスグループを関連付ける)ビジネスグループを関連付ける Runtime Fabric を組織のビジネスグループと共有できます。これにより、他のビジネスグループが 1 つの Runtime Fabric にアプリケーションをデプロイできます。この機能を使用するには、Runtime Fabric が登録されている組織のスコープにビジネスグループが含まれている必要があります。 ビジネスグループ全体で Runtime Fabric を関連付ける手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ タブを選択します。 3. 管理する Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブで、​**\[Add business group (ビジネスグループを追加)\]**​ をクリックします。 5. ドロップダウンリストからビジネスグループを選択します。 - **This business group and its children (このビジネスグループとその子)** このオプションでは、選択したビジネスグループおよびその全ての子のすべての環境、すべての Sandbox 環境、またはすべての本番環境のいずれかを選択できます。 - **Selected business groups (選択したビジネスグループ)**​ **\[Add business group (ビジネスグループを追加)\]**​ 項目にビジネスグループ名を入力し、リストから選択します。このオプションを使用すると、ルート組織とその子組織の環境を選択できます。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Business Groups (ビジネスグループ)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-associate-business-groups.png) ## [](#環境を関連付ける)環境を関連付ける 環境を Runtime Fabric に関連付ける手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ セクションを選択します。 3. インストール中に使用された名前に基づいて、Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブをクリックします。 5. ドロップダウンリストから環境を選択します。 - **All Environment (すべての環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境と本番環境に Runtime Fabric を関連付けます。 - **All Sandbox Environments (すべての Sandbox 環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境にのみ Runtime Fabric を関連付けます。 - **All Production Environments (すべての本番環境)** ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての本番環境にのみ Runtime Fabric を関連付けます。 - **Select Environments Manually (手動で環境を選択)** 特定の子ビジネスグループの特定の環境に Runtime Fabric を関連付けることができます。 - 特定の子ビジネス組織のすべての Sandbox 環境またはすべての本番環境を一括選択するには、​**\[Sandbox\]**​ または ​**\[Production (本番)\]**​ のチェックボックスをオンにします。 - 特定の子ビジネス組織で必要な環境を個別に選択するには、それぞれのサブ環境のチェックボックスをオンにします。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Environments (環境)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-associate-environments.png) ### [](#本番環境)本番環境 本番環境を選択すると、Runtime Fabric が本番設定で動作するように設定されていることを確認するダイアログが表示されます。これには、適切なハードウェア設定、ログ転送、アラート、および考えられる障害モードに関する情報が含まれます。 サポートされない設定で Runtime Fabric が実行されている場合、または Runtime Fabric が本番環境の要件を満たさない場合、次のいずれかのメッセージが表示されます。 - `This Runtime Fabric is not supported for any workloads. Learn more. (この Runtime Fabric はどのワークロードでもサポートされていません。詳細はこちら。)` - `This Runtime Fabric is suitable for non-production workloads only. Learn more. (この Runtime Fabric は非本番ワークロードにのみ適しています。詳細はこちら。)` 詳細は、​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-index)​を参照してください。 Runtime Fabric で本番アプリケーションを運用およびデプロイする前に、適切な設定が完了している必要があります。 # ビジネスグループと環境の Runtime Fabric への関連付け アプリケーションまたは API ゲートウェイを Anypoint Runtime Fabric にデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付ける必要があります。デプロイする環境でこの手順を実行するまで、Mule アプリケーションをデプロイするときに、デプロイメント対象として Runtime Fabric を選択することはできません。
Runtime Fabric アプライアンスはこの機能をサポートしていません。
## [](#ビジネスグループを関連付ける)ビジネスグループを関連付ける Runtime Fabric を組織のビジネスグループと共有できます。これにより、他のビジネスグループが 1 つの Runtime Fabric にアプリケーションをデプロイできます。この機能を使用するには、Runtime Fabric が登録されている組織の範囲にビジネスグループが含まれている必要があります。 ビジネスグループ全体で Runtime Fabric を関連付ける手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ タブを選択します。 3. 管理する Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブで、​**\[Add business group (ビジネスグループを追加)\]**​ をクリックします。 5. ドロップダウンリストからビジネスグループを選択します。 - **This business group and its children (このビジネスグループとその子)** このオプションでは、選択したビジネスグループおよびそのすべての子のすべての環境、すべての Sandbox 環境、またはすべての本番環境のいずれかを選択できます。 - **Selected business groups (選択したビジネスグループ)**​ **\[Add business group (ビジネスグループを追加)\]**​ 項目にビジネスグループ名を入力し、リストから選択します。このオプションを使用すると、ルート組織とその子組織の環境を選択できます。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Business Groups (ビジネスグループ)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-associate-business-groups.png) ## [](#環境を関連付ける)環境を関連付ける 環境を Runtime Fabric に関連付ける手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ セクションを選択します。 3. インストール中に使用された名前に基づいて、Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブをクリックします。 5. ドロップダウンリストから環境を選択します。 - **All Environment (すべての環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境と本番環境に Runtime Fabric を関連付けます。 - **All Sandbox Environments (すべての Sandbox 環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境にのみ Runtime Fabric を関連付けます。 - **All Production Environments (すべての本番環境)** ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての本番環境にのみ Runtime Fabric を関連付けます。 - **Select Environments Manually (手動で環境を選択)** 特定の子ビジネスグループの特定の環境に Runtime Fabric を関連付けることができます。 - 特定の子ビジネス組織のすべての Sandbox 環境またはすべての本番環境を一括選択するには、​**\[Sandbox\]**​ または ​**\[Production (本番)\]**​ のチェックボックスをオンにします。 - 特定の子ビジネス組織で必要な環境を個別に選択するには、それぞれのサブ環境のチェックボックスをオンにします。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Environments (環境)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-associate-environments.png) ### [](#本番設定)本番設定 本番環境を選択すると、Runtime Fabric が本番設定で動作するように設定されていることを確認するダイアログが表示されます。これには、適切なハードウェア設定、ログ転送、アラート、および考えられる障害モードに関する情報が含まれます。 サポートされない設定で Runtime Fabric が実行されている場合、または Runtime Fabric が本番環境の要件を満たさない場合、次のいずれかのメッセージが表示されます。 - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` 詳細は、​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-index)​を参照してください。 Runtime Fabric で本番アプリケーションを運用およびデプロイする前に、適切な設定が完了している必要があります。 # ビジネスグループと環境の Runtime Fabric への関連付け アプリケーションまたは API ゲートウェイを Anypoint Runtime Fabric にデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付ける必要があります。デプロイする環境でこの手順を実行するまで、Mule アプリケーションをデプロイするときに、デプロイメント対象として Runtime Fabric を選択することはできません。
Runtime Fabric アプライアンスはこの機能をサポートしていません。
## [](#ビジネスグループを関連付ける)ビジネスグループを関連付ける Runtime Fabric を組織のビジネスグループと共有できます。これにより、他のビジネスグループが 1 つの Runtime Fabric にアプリケーションをデプロイできます。この機能を使用するには、Runtime Fabric が登録されている組織のスコープにビジネスグループが含まれている必要があります。 ビジネスグループ全体で Runtime Fabric を関連付ける手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ タブを選択します。 3. 管理する Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブで、​**\[Add business group (ビジネスグループを追加)\]**​ をクリックします。 5. ドロップダウンリストからビジネスグループを選択します。 - **This business group and its children (このビジネスグループとその子)** このオプションでは、選択したビジネスグループおよびそのすべての子のすべての環境、すべての Sandbox 環境、またはすべての本番環境のいずれかを選択できます。 - **Selected business groups (選択したビジネスグループ)**​ **\[Add business group (ビジネスグループを追加)\]**​ 項目にビジネスグループ名を入力し、リストから選択します。このオプションを使用すると、ルート組織とその子組織の環境を選択できます。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Business Groups (ビジネスグループ)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-associate-business-groups.png) ## [](#環境を関連付ける)環境を関連付ける 環境を Runtime Fabric に関連付ける手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ セクションを選択します。 3. インストール中に使用された名前に基づいて、Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブをクリックします。 5. ドロップダウンリストから環境を選択します。 - **All Environment (すべての環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境と本番環境に Runtime Fabric を関連付けます。 - **All Sandbox Environments (すべての Sandbox 環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境にのみ Runtime Fabric を関連付けます。 - **All Production Environments (すべての本番環境)** ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての本番環境にのみ Runtime Fabric を関連付けます。 - **Select Environments Manually (手動で環境を選択)** 特定の子ビジネスグループの特定の環境に Runtime Fabric を関連付けることができます。 - 特定の子ビジネス組織のすべての Sandbox 環境またはすべての本番環境を一括選択するには、​**\[Sandbox\]**​ または ​**\[Production (本番)\]**​ のチェックボックスをオンにします。 - 特定の子ビジネス組織で必要な環境を個別に選択するには、それぞれのサブ環境のチェックボックスをオンにします。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Environments (環境)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-associate-environments.png) ### [](#本番設定)本番設定 本番環境を選択すると、Runtime Fabric が本番設定で動作するように設定されていることを確認するダイアログが表示されます。これには、適切なハードウェア設定、ログ転送、アラート、および考えられる障害モードに関する情報が含まれます。 サポートされない設定で Runtime Fabric が実行されている場合、または Runtime Fabric が本番環境の要件を満たさない場合、次のいずれかのメッセージが表示されます。 - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` 詳細は、​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-index)​を参照してください。 Runtime Fabric で本番アプリケーションを運用およびデプロイする前に、適切な設定が完了している必要があります。 # ビジネスグループと環境の Runtime Fabric への関連付け アプリケーションまたは API ゲートウェイを Anypoint Runtime Fabric にデプロイする前に、Runtime Fabric を 1 つ以上の Anypoint Platform 環境に関連付ける必要があります。デプロイする環境でこの手順を実行するまで、Mule アプリケーションをデプロイするときに、デプロイメント対象として Runtime Fabric を選択することはできません。
Runtime Fabric アプライアンスはこの機能をサポートしていません。
## [](#ビジネスグループを関連付ける)ビジネスグループを関連付ける Runtime Fabric を組織のビジネスグループと共有できます。これにより、他のビジネスグループが 1 つの Runtime Fabric にアプリケーションをデプロイできます。この機能を使用するには、Runtime Fabric が登録されている組織のスコープにビジネスグループが含まれている必要があります。 ビジネスグループ全体で Runtime Fabric を関連付ける手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ タブを選択します。 3. 管理する Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブで、​**\[Add business group (ビジネスグループを追加)\]**​ をクリックします。 5. ドロップダウンリストからビジネスグループを選択します。 - **This business group and its children (このビジネスグループとその子)** このオプションでは、選択したビジネスグループおよびそのすべての子のすべての環境、すべての Sandbox 環境、またはすべての本番環境のいずれかを選択できます。 - **Selected business groups (選択したビジネスグループ)**​ **\[Add business group (ビジネスグループを追加)\]**​ 項目にビジネスグループ名を入力し、リストから選択します。このオプションを使用すると、ルート組織とその子組織の環境を選択できます。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Business Groups (ビジネスグループ)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-associate-business-groups.png) ## [](#環境を関連付ける)環境を関連付ける 環境を Runtime Fabric に関連付ける手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. 左サイドバーで、​**\[Runtime Fabric\]**​ セクションを選択します。 3. インストール中に使用された名前に基づいて、Runtime Fabric を選択します。 4. **\[Environments (環境)\]**​ タブをクリックします。 5. ドロップダウンリストから環境を選択します。 - **All Environment (すべての環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境と本番環境に Runtime Fabric を関連付けます。 - **All Sandbox Environments (すべての Sandbox 環境)**​ ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての Sandbox 環境にのみ Runtime Fabric を関連付けます。 - **All Production Environments (すべての本番環境)** ビジネスグループとそのすべての子、または特定の子ビジネス組織のすべての本番環境にのみ Runtime Fabric を関連付けます。 - **Select Environments Manually (手動で環境を選択)** 特定の子ビジネスグループの特定の環境に Runtime Fabric を関連付けることができます。 - 特定の子ビジネス組織のすべての Sandbox 環境またはすべての本番環境を一括選択するには、​**\[Sandbox\]**​ または ​**\[Production (本番)\]**​ のチェックボックスをオンにします。 - 特定の子ビジネス組織で必要な環境を個別に選択するには、それぞれのサブ環境のチェックボックスをオンにします。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![「Environments (環境)」 ドロップダウンメニューと選択できるオプションが表示された Runtime Manager UI](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-associate-environments.png) ### [](#本番設定)本番設定 本番環境を選択すると、Runtime Fabric が本番設定で動作するように設定されていることを確認するダイアログが表示されます。これには、適切なハードウェア設定、ログ転送、アラート、および考えられる障害モードに関する情報が含まれます。 サポートされない設定で Runtime Fabric が実行されている場合、または Runtime Fabric が本番環境の要件を満たさない場合、次のいずれかのメッセージが表示されます。 - `This Runtime Fabric is not supported for any workloads. Learn more.` - `This Runtime Fabric is suitable for non-production workloads only. Learn more.` 詳細は、​[「Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-index)​を参照してください。 Runtime Fabric で本番アプリケーションを運用およびデプロイする前に、適切な設定が完了している必要があります。 # 単一 OpenShift クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 ## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの OpenShift クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.5/authorized-namespaces)​を設定できます。 ### [](#始める前に)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#values-yaml-ファイルの必須パラメーター)values.yaml ファイルの必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yml-リファレンス)values.yml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#runtime-fabric-の複数のインスタンスのインストール)Runtime Fabric の複数のインスタンスのインストール 2 つ目移行の Runtime Fabric for OpenShift のインスタンスをインストールするには、前回の手順を繰り返します。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\] > \[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。 4. values.yaml の必須パラメーターを追加します。 5. 認証済みの名前空間を使用する場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 6. `crds.install`​ の値を ​`false`​ に設定します。 7. **\[Create (作成)\]**​ をクリックします。 ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-index) # 単一 OpenShift クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 ## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの OpenShift クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.6/authorized-namespaces)​を設定できます。 ### [](#始める前に)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#values-yaml-の必須パラメーター)Values.yaml の必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)Values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yaml-リファレンス)Values.yaml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#runtime-fabric-の複数のインスタンスのインストール)Runtime Fabric の複数のインスタンスのインストール 2 つ目移行の Runtime Fabric for OpenShift のインスタンスをインストールするには、前回の手順を繰り返します。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\] > \[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。 4. values.yaml の必須パラメーターを追加します。 5. 認証済みの名前空間を使用する場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 6. `crds.install`​ の値を ​`false`​ に設定します。 7. **\[Create (作成)\]**​ をクリックします。 ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-index) # 単一 OpenShift クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 ## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの OpenShift クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.7/authorized-namespaces)​を設定できます。 ### [](#始める前に)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#values-yaml-の必須パラメーター)Values.yaml の必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
Key (キー) 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)Values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
Key (キー) 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yaml-リファレンス)Values.yaml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#runtime-fabric-の複数のインスタンスのインストール)Runtime Fabric の複数のインスタンスのインストール 2 つ目移行の Runtime Fabric for OpenShift のインスタンスをインストールするには、前回の手順を繰り返します。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\] > \[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. コンソールで ​**\[Create Instance (インスタンスを作成)\]**​ をクリックし、​**\[Configure via form view (フォームビューを通じて設定)\]**​ を選択します。 4. values.yaml の必須パラメーターを追加します。 5. 認証済みの名前空間を使用する場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 6. `crds.install`​ の値を ​`false`​ に設定します。 7. **\[Create (作成)\]**​ をクリックします。 ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-index) # 単一 OpenShift クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 ## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの OpenShift クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= ## [](#values-yaml-リファレンス)Values.yaml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#runtime-fabric-の複数のインスタンスのインストール)Runtime Fabric の複数のインスタンスのインストール 2 つ目移行の Runtime Fabric for OpenShift のインスタンスをインストールするには、前回の手順を繰り返します。 1. Runtime Manager for OpenShift を使用して Runtime Fabric を作成します。 2. Runtime Fabric をインストールするためのカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\] > \[Installed Operators (インストール済み Operator)\]**​ に移動します。 2. コンソールで、​**\[Project (プロジェクト)\]**​ の値を Runtime Fabric のインストール用に作成した名前空間に切り替えます。 3. 追加の必須パラメーターで ​`values.yaml`​ ファイルを更新します。 4. 認証済みの名前空間を使用する場合は、​`authorizedNamespaces`​ を ​`true`​ に設定します。 5. `crds.install`​ を ​`false`​ に設定します。 6. **\[Create (作成)\]**​ をクリックします。 ## [](#省略可能-承認済み名前空間を設定する)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする​[承認済み名前空間](https://docs.mulesoft.com/jp/runtime-fabric/2.8/authorized-namespaces)​を設定できます。 ### [](#始める前に)始める前に 承認済み名前空間を設定する前に、次の点に注意してください。 - Runtime Fabric をインストールする​_前_​に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、ConfigMap には ​`authorized-namespaces`​ という名前を付ける必要があります。 - `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] 1. クラスターで、アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加します。そのためには、次のコンテンツで YAML ファイルを作成します。 ```copy apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers ``` 2. ここで作成したファイルを適用します。 ```copy oc apply -f .yaml ``` 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. Runtime Fabric エージェント ServiceAccount が含まれる Runtime Fabric エージェント ClusterRole の RoleBinding を作成します。そのためには、追加の名前空間で次の設定を適用します。 ```copy kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ``` 5. 次の RoleBinding テンプレートを rtf 名前空間と他の追加の名前空間に適用します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` ``​ でも、同じテンプレートを指定します。 ```copy apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: rtf namespace: roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:openshift:scc:anyuid subjects: - kind: ServiceAccount name: rtf-agent namespace: - kind: ServiceAccount name: mule-clusterip-service namespace: - kind: ServiceAccount name: resource-cache namespace: - kind: ServiceAccount name: rtf-persistence-gateway namespace: - kind: ServiceAccount name: cluster-status namespace: - kind: ServiceAccount name: am-log-forwarder namespace: ``` 6. クラスターで、​`authorized-namespaces`​ という名前の ConfigMap ファイルを作成し、追加の名前空間があればリストします。追加の名前空間のマッピングキーは、標準 K8s リソース (ConfigMap) を使用するため、一意である必要があります。キー名は、一意でさえあれば、形式については特に要件はありません。 ```copy apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION_NAMESPACE_1: "" APPLICATION_NAMESPACE_2: " ``` 7. Runtime Fabric のインストールが完了した後に ConfigMap で名前空間の追加または削除を行う場合は、Runtime Fabric エージェントポッドを再起動する必要があります。これを行うには、次のコマンドを実行します。 ```copy oc -nrtf delete po -l app=agent ``` ポッドを削除すると、Kubernetes によって新しいポッドが開始されます。 ### [](#red-hat-openshift-runtime-fabric-operator-をインストールする)Red Hat OpenShift Runtime Fabric Operator をインストールする OperatorHub から Runtime Fabric Operator (​`rtf-agent-operator`​) をインストールします。 1. Red Hat OpenShift コンソールで、​**\[Operators (Operator)\]**​ > ​**\[OperatorHub\]**​ に移動します。 2. \[OperatorHub\] 検索項目で、Runtime Fabric Operator を検索します。 3. rtf-agent-operator ダイアログで、​**\[Install (インストール)\]**​ をクリックします。
Runtime Fabric Operator をインストールするには手動で承認を行う必要があり、完了まで数分かかる場合があります。
## [](#values-yaml-の必須パラメーター)Values.yaml の必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
Key (キー) 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)Values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
Key (キー) 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-index) # 単一クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 - この機能を使用するには、複数のインスタンスがサポートされる 2.2.5 以上のバージョンの Runtime Fabric エージェントにアップグレードする必要があります。 - エージェントの名前空間はアプリケーションの名前空間に 1 対 1 でマップされます。同じクラスターの複数のインスタンスの Runtime Fabric 間でアプリケーションの名前空間を共有することはできません。 - Hazelcast クラスタリングはまだ複数のインスタンスではサポートされていません。
複数のインスタンスがある場合、最初の Runtime Fabric エージェントのインストールにより、​persistencegateways.rtf.mulesoft.com​ のカスタムリソース定義 (CRD) と優先度クラスの ​rtf-components-high-priority​ リソースが作成されます。エージェントをアンインストールしても、Runtime Fabric エージェントではこれらのリソースがクリーンアップされません。
## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの BYOK (Bring Your Own Kubernetes) クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. 前のステップで作成した Fabric をインストールするカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Runtime Fabric Helm リポジトリを追加します。 helm repo add --username --password 5. 必要に応じて、共有テナントを設定できます。詳細は、​[「承認済み名前空間の設定」](#configure-namespaces)​を参照してください。 6. Anypoint Platform UI から ​`values.yaml`​ ファイルをダウンロードして設定します。 7. `values.yaml`​ ファイルの​[必須パラメーター](#required-parameters)​を設定します。 8. クラスターに Runtime Fabric をインストールします。 helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## [](#values-yaml-ファイルの必須パラメーター)values.yaml ファイルの必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
キー 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
キー 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yml-リファレンス)values.yml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#mule-アプリケーションのデプロイ)Mule アプリケーションのデプロイ 1. Mule アプリケーションをデプロイするには、インストールするエージェントごとに ​`app-namespace`​ を作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 新しい ​``​ でイングレスを作成します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port ``​ ごとに異なるホスト名を使用してください。複数のイングレスで同じホストについて異なるパスを定義すると、イングレスコントローラーによって定義がマージされます。 結果として、同じ名前の, Mule アプリケーションにアクセスできなくなり、Runtime Fabric の問題ではなく k8s の問題が発生することになります。 ## [](#configure-namespaces)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする承認済み名前空間を設定できます。 Runtime Fabric をインストールする前に Runtime Fabric 名前空間用に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、​`ConfigMap`​ には ​`authorized-namespaces`​ という名前を付ける必要があります。​`ConfigMap`​ ファイルの例を示します。 apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 ClusterRole ロールの例を示します。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### [](#追加の名前空間を設定する)追加の名前空間を設定する アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加するには、次の手順に従ってください。 1. 次のコンテンツで YAML ファイルを作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 以前に作成したファイルを適用します。 kubectl apply -f .yaml 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. 追加の名前空間で次の設定を適用することにより、Runtime Fabric エージェント ​`ServiceAccount`​ が含まれる Runtime Fabric エージェント ​`ClusterRole`​ の ​`RoleBinding`​ を作成します。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.5/install-index) # 単一クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 - この機能を使用するには、複数のインスタンスがサポートされる 2.2.5 以上のバージョンの Runtime Fabric エージェントにアップグレードする必要があります。 - エージェントの名前空間はアプリケーションの名前空間に 1 対 1 でマップされます。同じクラスターの複数のインスタンスの Runtime Fabric 間でアプリケーションの名前空間を共有することはできません。
複数のインスタンスがある場合、最初の Runtime Fabric エージェントのインストールにより、​persistencegateways.rtf.mulesoft.com​ のカスタムリソース定義 (CRD) と優先度クラスの ​rtf-components-high-priority​ リソースが作成されます。エージェントをアンインストールしても、Runtime Fabric エージェントではこれらのリソースがクリーンアップされません。
## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの BYOK (Bring Your Own Kubernetes) クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. 前のステップで作成した Fabric をインストールするカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Runtime Fabric Helm リポジトリを追加します。 helm repo add --username --password 5. 必要に応じて、共有テナントを設定できます。詳細は、​[承認済み名前空間の設定](#configure-namespaces)​を参照してください。 6. Anypoint Platform UI から ​`values.yaml`​ ファイルをダウンロードして設定します。 7. `values.yaml`​ ファイルの​[必須パラメーター](#required-parameters)​を設定します。 8. クラスターに Runtime Fabric をインストールします。 helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## [](#values-yaml-の必須パラメーター)Values.yaml の必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
Key (キー) 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)Values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
Key (キー) 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yaml-リファレンス)Values.yaml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#mule-アプリケーションのデプロイ)Mule アプリケーションのデプロイ 1. Mule アプリケーションをデプロイするには、インストールするエージェントごとに ​`app-namespace`​ を作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 新しい ​``​ でイングレスを作成します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port ``​ ごとに異なるホスト名を使用してください。複数のイングレスで同じホストについて異なるパスを定義すると、イングレスコントローラーによって定義がマージされます。 結果として、同じ名前の, Mule アプリケーションにアクセスできなくなり、Runtime Fabric の問題ではなく k8s の問題が発生することになります。 ## [](#configure-namespaces)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする承認済み名前空間を設定できます。 Runtime Fabric をインストールする前に Runtime Fabric 名前空間用に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、​`ConfigMap`​ には ​`authorized-namespaces`​ という名前を付ける必要があります。​`ConfigMap`​ ファイルの例を示します。 apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 ClusterRole ロールの例を示します。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### [](#追加の名前空間を設定する)追加の名前空間を設定する アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加するには、次の手順に従ってください。 1. 次のコンテンツで YAML ファイルを作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 以前に作成したファイルを適用します。 kubectl apply -f .yaml 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. 追加の名前空間で次の設定を適用することにより、Runtime Fabric エージェント ​`ServiceAccount`​ が含まれる Runtime Fabric エージェント ​`ClusterRole`​ の ​`RoleBinding`​ を作成します。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.6/install-index) # 単一クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 - この機能を使用するには、複数のインスタンスがサポートされる 2.2.5 以上のバージョンの Runtime Fabric エージェントにアップグレードする必要があります。 - エージェントの名前空間はアプリケーションの名前空間に 1 対 1 でマップされます。同じクラスターの複数のインスタンスの Runtime Fabric 間でアプリケーションの名前空間を共有することはできません。
複数のインスタンスがある場合、最初の Runtime Fabric エージェントのインストールにより、​persistencegateways.rtf.mulesoft.com​ のカスタムリソース定義 (CRD) と優先度クラスの ​rtf-components-high-priority​ リソースが作成されます。エージェントをアンインストールしても、Runtime Fabric エージェントではこれらのリソースがクリーンアップされません。
## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの BYOK (Bring Your Own Kubernetes) クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. 前のステップで作成した Fabric をインストールするカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Runtime Fabric Helm リポジトリを追加します。 helm repo add --username --password 5. 必要に応じて、共有テナントを設定できます。詳細は、​[承認済み名前空間の設定](#configure-namespaces)​を参照してください。 6. Anypoint Platform UI から ​`values.yaml`​ ファイルをダウンロードして設定します。 7. `values.yaml`​ ファイルの​[必須パラメーター](#required-parameters)​を設定します。 8. クラスターに Runtime Fabric をインストールします。 helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## [](#values-yaml-の必須パラメーター)Values.yaml の必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
Key (キー) 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)Values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
Key (キー) 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yaml-リファレンス)Values.yaml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#mule-アプリケーションのデプロイ)Mule アプリケーションのデプロイ 1. Mule アプリケーションをデプロイするには、インストールするエージェントごとに ​`app-namespace`​ を作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 新しい ​``​ でイングレスを作成します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port ``​ ごとに異なるホスト名を使用してください。複数のイングレスで同じホストについて異なるパスを定義すると、イングレスコントローラーによって定義がマージされます。 結果として、同じ名前の, Mule アプリケーションにアクセスできなくなり、Runtime Fabric の問題ではなく k8s の問題が発生することになります。 ## [](#configure-namespaces)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする承認済み名前空間を設定できます。 Runtime Fabric をインストールする前に Runtime Fabric 名前空間用に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、​`ConfigMap`​ には ​`authorized-namespaces`​ という名前を付ける必要があります。​`ConfigMap`​ ファイルの例を示します。 apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 ClusterRole ロールの例を示します。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### [](#追加の名前空間を設定する)追加の名前空間を設定する アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加するには、次の手順に従ってください。 1. 次のコンテンツで YAML ファイルを作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 以前に作成したファイルを適用します。 kubectl apply -f .yaml 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. 追加の名前空間で次の設定を適用することにより、Runtime Fabric エージェント ​`ServiceAccount`​ が含まれる Runtime Fabric エージェント ​`ClusterRole`​ の ​`RoleBinding`​ を作成します。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.7/install-index) # 単一クラスターへの Runtime Fabric の複数のインスタンスのインストール 複数のインスタンスの Anypoint Runtime Fabric をインストールすることで、複数の Runtime Fabrics 間で同じクラスターを共有し、効率的にリソースを使用することができます。 - この機能を使用するには、複数のインスタンスがサポートされる 2.2.5 以上のバージョンの Runtime Fabric エージェントにアップグレードする必要があります。 - エージェントの名前空間はアプリケーションの名前空間に 1 対 1 でマップされます。同じクラスターの複数のインスタンスの Runtime Fabric 間でアプリケーションの名前空間を共有することはできません。
複数のインスタンスがある場合、最初の Runtime Fabric エージェントのインストールにより、​persistencegateways.rtf.mulesoft.com​ のカスタムリソース定義 (CRD) と優先度クラスの ​rtf-components-high-priority​ リソースが作成されます。エージェントをアンインストールしても、Runtime Fabric エージェントではこれらのリソースがクリーンアップされません。
## [](#複数のインスタンスの-runtime-fabric-をインストールする)複数のインスタンスの Runtime Fabric をインストールする 1 つの BYOK (Bring Your Own Kubernetes) クラスターに複数のインスタンスの Anypoint Runtime Fabric をインストールするには、次の手順に従ってください。 1. Runtime Manager を使用して Runtime Fabric を作成します。 2. 前のステップで作成した Fabric をインストールするカスタム名前空間を作成します。 kubectl create ns 3. 前に作成した名前空間の Runtime Fabric コンポーネントイメージを取得するための Docker プルシークレットを作成します。 kubectl create secret docker-registry rtf-pull-secret --namespace --docker-server= --docker-username= --docker-password= 4. Runtime Fabric Helm リポジトリを追加します。 helm repo add --username --password 5. 必要に応じて、共有テナントを設定できます。詳細は、​[承認済み名前空間の設定](#configure-namespaces)​を参照してください。 6. Anypoint Platform UI から ​`values.yaml`​ ファイルをダウンロードして設定します。 7. `values.yaml`​ ファイルの​[必須パラメーター](#required-parameters)​を設定します。 8. クラスターに Runtime Fabric をインストールします。 helm install runtime-fabric rtf/rtf-agent --version -f values.yaml -n ## [](#values-yaml-の必須パラメーター)Values.yaml の必須パラメーター Runtime Manager で Runtime Fabric インスタンスを作成すると、次の必須パラメーターの値が設定されます。ローカルレジストリを使用していない場合は、レジストリ URL とプルシークレットのデフォルト値を使用してください。
Key (キー) 値 例

activationData

アクティベーションデータ

YW55cG9pbnQubXVsZXNvZnQuY29tOjBmODdmYzYzLTM3MWUtNDU2Yy1iODg5LTU5NTkyNjYyZjUxZQ==

rtfRegistry

レジストリ URL

US rtf-runtime-registry.kprod.msap.io

EU rtf-runtime-registry.kprod-eu.msap.io

pullSecretName

レジストリプルシークレット

rtf-pull-secret

muleLicense

アプリケーションの Mule ライセンス

Mule ライセンスキー (Base64 でエンコードされている必要があります)
## [](#required-parameters)Values.yaml の省略可能なパラメーター 必要に応じて次の省略可能なパラメーターを設定します。
Key (キー) 説明 例

authorizedNamespaces

共有テナントを有効にする

authorizedNamespaces=true

crds.install

Crds と PriorityClass のインストールを有効にする

install=true

proxy.http.proxy
proxy.http.no_proxy​ `

プロキシ値と no_proxy 値

- http://<user>:<pass>@<10.0.0.1>:<8080>​
- <1.1.1.1:8888,2.2.2.2:9999>

proxy.monitoring.proxy

Monitoring のプロキシ値

socks5://<user>:<pass>@<10.0.0.2>:<8080>

global.containerLogPaths

Filebeat の読み取りパス

- /var/lib/docker/
- /var/log/containers
- /var/log/pods
最初のエージェントをクラスターにインストールするには、​crds.install​ の値を ​true​ に設定します。
同じクラスターの以降のすべてのエージェントインストールでは ​crds.install​ を ​false​ に設定します。
## [](#values-yaml-リファレンス)Values.yaml リファレンス 次に ​`values.yaml`​ ファイルの例を示します。 activationData: proxy: http\_proxy: http\_no\_proxy: monitoring\_proxy: custom\_log4j\_enabled: true muleLicense: global: crds: install: true authorizedNamespaces: false image: rtfRegistry: rtf-runtime-registry.kprod.msap.io pullSecretName: rtf-pull-secret containerLogPaths: - /var/lib/docker/containers - /var/log/containers - /var/log/pods ## [](#mule-アプリケーションのデプロイ)Mule アプリケーションのデプロイ 1. Mule アプリケーションをデプロイするには、インストールするエージェントごとに ​`app-namespace`​ を作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 新しい ​``​ でイングレスを作成します。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: rtf-ingress namespace: annotations: nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: ingressClassName: rtf-nginx rules: - host: "testrtf.com" http: paths: - pathType: Prefix path: "/app-name(/|$)(.\*)" backend: service: name: service port: name: service-port ``​ ごとに異なるホスト名を使用してください。複数のイングレスで同じホストについて異なるパスを定義すると、イングレスコントローラーによって定義がマージされます。 結果として、同じ名前の, Mule アプリケーションにアクセスできなくなり、Runtime Fabric の問題ではなく k8s の問題が発生することになります。 ## [](#configure-namespaces)(省略可能) 承認済み名前空間を設定する 必要に応じて、他のサービスと一緒に Runtime Fabric を Kubernetes クラスターにデプロイできるようにする承認済み名前空間を設定できます。 Runtime Fabric をインストールする前に Runtime Fabric 名前空間用に ​`authorized-namespaces`​ ConfigMap ファイルを作成する必要があります。さらに、​`ConfigMap`​ には ​`authorized-namespaces`​ という名前を付ける必要があります。​`ConfigMap`​ ファイルの例を示します。 apiVersion: v1 kind: ConfigMap metadata: name: authorized-namespaces namespace: data: APPLICATION\_NAMESPACE\_1: "" APPLICATION\_NAMESPACE\_2: " `rtf:resource-metrics-collector`​ ClusterRole にはノード、ポッド、名前空間を ​`get`​ および ​`list`​ するクラスター全体の権限があり、ノードに対する ​`watch`​ 権限があります。ロール ClusterRole は次のように定義されます。 ClusterRole ロールの例を示します。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: rtf:resource-metrics-collector labels: {{- include "labels.standard" . | nindent 4 }} rules: - apiGroups: \[""\] resources: \["nodes", "pods", "namespaces"\] verbs: \["list", "get"\] - apiGroups: \[""\] resources: \["nodes"\] verbs: \["watch"\] ### [](#追加の名前空間を設定する)追加の名前空間を設定する アプリケーションデプロイメント用の追加の名前空間を作成し、必要な表示ラベルを名前空間に追加するには、次の手順に従ってください。 1. 次のコンテンツで YAML ファイルを作成します。 apiVersion: v1 kind: Namespace metadata: name: labels: rtf.mulesoft.com/agentNamespace: rtf.mulesoft.com/envId: rtf.mulesoft.com/org: rtf.mulesoft.com/role: workers 2. 以前に作成したファイルを適用します。 kubectl apply -f .yaml 3. ステップ 1 と 2 を繰り返して、必要な数の名前空間を追加します。 4. 追加の名前空間で次の設定を適用することにより、Runtime Fabric エージェント ​`ServiceAccount`​ が含まれる Runtime Fabric エージェント ​`ClusterRole`​ の ​`RoleBinding`​ を作成します。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: namespace: subjects: - kind: ServiceAccount name: rtf-agent namespace: roleRef: kind: ClusterRole name: rtf:agent- apiGroup: rbac.authorization.k8s.io ## [](#関連情報)関連情報 [Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/2.8/install-index) # 同じクラスター内でのアプリケーション間の要求の送信 Anypoint Runtime Fabric クラスターでは、すべてのアプリケーションレプリカがクラスター内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。外部要求を処理し、ロードバランサーを設定する方法についての詳細は、​[「Anypoint Runtime Fabric でのインバウンドトラフィックの有効化」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic)​を参照してください。 クラスター内でアプリケーションから別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID を使用します。 クラスターの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`hello-world`​ の DNS レコードは次のとおりです。 ```none hello-world.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じクラスター内の別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://hello-world:8081/api ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。 次の例では、1 つのアプリケーションから別の名前空間のアプリケーションに要求を送信しています。この例では、​`1abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ は同じ Runtime Fabric クラスター内の別の環境のため、その環境 ID がアプリケーション名に追加されています。 ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` # 同じクラスター内でのアプリケーション間の要求の送信 Anypoint Runtime Fabric クラスターでは、すべてのアプリケーションレプリカがクラスター内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。外部要求の処理についての詳細は、​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.5/custom-ingress-configuration)​を参照してください。 クラスター内でアプリケーションから別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID を使用します。 クラスターの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`hello-world`​ の DNS レコードは次のとおりです。 ```none hello-world.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じクラスター内の別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://hello-world:8081/api ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。 次の例では、1 つのアプリケーションから別の名前空間のアプリケーションに要求を送信しています。この例では、​`1abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ は同じ Runtime Fabric クラスター内の別の環境のため、その環境 ID がアプリケーション名に追加されています。 ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` # 同じクラスター内でのアプリケーション間の要求の送信 Anypoint Runtime Fabric クラスターでは、すべてのアプリケーションレプリカがクラスター内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。外部要求の処理についての詳細は、​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.6/custom-ingress-configuration)​を参照してください。 クラスター内でアプリケーションから別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID を使用します。 クラスターの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`hello-world`​ の DNS レコードは次のとおりです。 ```none hello-world.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じクラスター内の別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://hello-world:8081/api ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。 次の例では、1 つのアプリケーションから別の名前空間のアプリケーションに要求を送信しています。この例では、​`1abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ は同じ Runtime Fabric クラスター内の別の環境のため、その環境 ID がアプリケーション名に追加されています。 ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` # 同じクラスター内でのアプリケーション間の要求の送信 Anypoint Runtime Fabric クラスターでは、すべてのアプリケーションレプリカがクラスター内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。外部要求の処理についての詳細は、​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.7/custom-ingress-configuration)​を参照してください。 クラスター内でアプリケーションから別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID を使用します。 クラスターの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`hello-world`​ の DNS レコードは次のとおりです。 ```none hello-world.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じクラスター内の別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://hello-world:8081/api ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。 次の例では、1 つのアプリケーションから別の名前空間のアプリケーションに要求を送信しています。この例では、​`1abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ は同じ Runtime Fabric クラスター内の別の環境のため、その環境 ID がアプリケーション名に追加されています。 ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` # 同じクラスター内でのアプリケーション間の要求の送信 Anypoint Runtime Fabric クラスターでは、すべてのアプリケーションレプリカがクラスター内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。外部要求の処理についての詳細は、​[「Runtime Fabric のイングレスの設定」](https://docs.mulesoft.com/jp/runtime-fabric/2.8/custom-ingress-configuration)​を参照してください。 クラスター内でアプリケーションから別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID を使用します。 クラスターの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`hello-world`​ の DNS レコードは次のとおりです。 ```none hello-world.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じクラスター内の別のアプリケーションに要求を送信するには、アプリケーション名と環境 ID のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://hello-world:8081/api ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。 次の例では、1 つのアプリケーションから別の名前空間のアプリケーションに要求を送信しています。この例では、​`1abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ は同じ Runtime Fabric クラスター内の別の環境のため、その環境 ID がアプリケーション名に追加されています。 ```none http://hello-world.1abc2ce6-cce6-463b-afaa-a1979e3xxxxx:8081/api ``` # 外部へのテレメトリーのエクスポート Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合することで、テレメトリーを外部にエクスポートできます。 任意の Log4j アペンダーを使用できます。​`log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 ## [](#要件と制限事項)要件と制限事項 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、支援しません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 非同期ログアペンダーのみを使用してください。 - FileAppender、RollingFileAppender、AnypointMonitoringFileAppender、RandomAccessFileAppender などのファイルアペンダーは自動的に削除されます。 - カスタム Log4j 設定を使用する場合、Mule Runtime Engine とアプリケーションログの両方を Anypoint Monitoring で引き続き使用できます。 ## [](#log4j-の有効化)Log4j の有効化 カスタム Log4j 設定はデフォルトで無効化されています。Runtime Fabric をインストールすると、パラメーターは ​`Values.yaml`​ で無効化 (​`false`​ に設定) されます。この値を ​`true`​ に設定する必要があります。 また、次の手順でカスタム Log4j 設定を有効化することもできます。 1. クラスター内から次を実行します。 kubectl -nrtf patch secret custom-properties -p '{"data":{"CUSTOM\_LOG4J\_ENABLED":"dHJ1ZQ=="}}' 2. Runtime Fabric エージェントポッドを再起動します。 3. カスタム Log4j 設定に関連付けられているアプリケーションを再起動します。
カスタム Log4j は、Mule バージョン 4.3.0 以降の Mule Runtime エンジンインスタンスで動作している Mule アプリケーションでのみサポートされます。Mule イメージは、2022 年 11 月 17 日より後にビルドされている必要があります。詳細は、​「Runtime Fabric リリースノート」​を参照してください。
## [](#例-splunk-を使用して-log4j-設定を作成する)例: Splunk を使用して Log4j 設定を作成する ログを Runtime Fabric で表示可能にし、Splunk に送信するには、​`SplunkHttp`​ Log4j アペンダーを設定します。 Log4j アペンダーを有効にする手順は、次のとおりです。 1. `log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、​`SplunkHttp`​ Log4j アペンダーを含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 ```xml ``` 1. 設定に Splunk 連動関係が含まれていることを確認します。 ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` Splunk の最新バージョンについては、 [GitHub](https://github.com/splunk/splunk-library-javalogging/tags)​ を参照してください。 アプリケーションが起動すると、カスタム Log4j アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [MDC ログ](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) # 外部へのテレメトリーのエクスポート Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合することで、テレメトリーを外部にエクスポートできます。 任意の Log4j アペンダーを使用できます。​`log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 ## [](#要件と制限事項)要件と制限事項 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、支援しません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 非同期ログアペンダーのみを使用してください。 - FileAppender、RollingFileAppender、AnypointMonitoringFileAppender、RandomAccessFileAppender などのファイルアペンダーは自動的に削除されます。 - カスタム Log4j 設定を使用する場合、Mule Runtime Engine とアプリケーションログの両方を Anypoint Monitoring で引き続き使用できます。 ## [](#log4j-の有効化)Log4j の有効化 カスタム Log4j 設定はデフォルトで無効化されています。Runtime Fabric をインストールすると、パラメーターは ​`Values.yaml`​ で無効化 (​`false`​ に設定) されます。この値を ​`true`​ に設定する必要があります。 また、次の手順でカスタム Log4j 設定を有効化することもできます。 1. クラスター内から次を実行します。 kubectl -nrtf patch secret custom-properties -p '{"data":{"CUSTOM\_LOG4J\_ENABLED":"dHJ1ZQ=="}}' 2. Runtime Fabric エージェントポッドを再起動します。 3. カスタム Log4j 設定に関連付けられているアプリケーションを再起動します。
カスタム Log4j は、Mule バージョン 4.3.0 以降の Mule Runtime エンジンインスタンスで動作している Mule アプリケーションでのみサポートされます。Mule イメージは、2022 年 11 月 17 日より後にビルドされている必要があります。詳細は、​「Runtime Fabric リリースノート」​を参照してください。
## [](#例-splunk-を使用して-log4j-設定を作成する)例: Splunk を使用して Log4j 設定を作成する ログを Runtime Fabric で表示可能にし、Splunk に送信するには、​`SplunkHttp`​ Log4j アペンダーを設定します。 Log4j アペンダーを有効にする手順は、次のとおりです。 1. `log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、​`SplunkHttp`​ Log4j アペンダーを含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 ```xml ``` 1. 設定に Splunk 連動関係が含まれていることを確認します。 ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` Splunk の最新バージョンについては、 [GitHub](https://github.com/splunk/splunk-library-javalogging/tags)​ を参照してください。 アプリケーションが起動すると、カスタム Log4j アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [MDC ログ](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) # 外部へのテレメトリーのエクスポート Log4j アペンダーを使用して、ログシステムを Runtime Fabric にデプロイされたアプリケーションと統合することで、テレメトリーを外部にエクスポートできます。 任意の Log4j アペンダーを使用できます。​`log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 ## [](#要件と制限事項)要件と制限事項 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、支援しません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 - コンソールアペンダーまたは Anypoint Monitoring アペンダーでは何も変更しないでください。 非同期ログアペンダーのみを使用してください。 - FileAppender、RollingFileAppender、AnypointMonitoringFileAppender、RandomAccessFileAppender などのファイルアペンダーは自動的に削除されます。 - カスタム Log4j 設定を使用する場合、Mule Runtime Engine とアプリケーションログの両方を Anypoint Monitoring で引き続き使用できます。 ## [](#log4j-の有効化)Log4j の有効化 カスタム Log4j 設定はデフォルトで無効化されています。Runtime Fabric をインストールすると、パラメーターは ​`Values.yaml`​ で無効化 (​`false`​ に設定) されます。この値を ​`true`​ に設定する必要があります。 また、次の手順でカスタム Log4j 設定を有効化することもできます。 1. クラスター内から次を実行します。 kubectl -nrtf patch secret custom-properties -p '{"data":{"CUSTOM\_LOG4J\_ENABLED":"dHJ1ZQ=="}}' 2. Runtime Fabric エージェントポッドを再起動します。 3. カスタム Log4j 設定に関連付けられているアプリケーションを再起動します。
カスタム Log4j は、Mule バージョン 4.3.0 以降の Mule Runtime エンジンインスタンスで動作している Mule アプリケーションでのみサポートされます。Mule イメージは、2022 年 11 月 17 日より後にビルドされている必要があります。詳細は、​「Runtime Fabric リリースノート」​を参照してください。
## [](#例-splunk-を使用して-log4j-設定を作成する)例: Splunk を使用して Log4j 設定を作成する ログを Runtime Fabric で表示可能にし、Splunk に送信するには、​`SplunkHttp`​ Log4j アペンダーを設定します。 Log4j アペンダーを有効にする手順は、次のとおりです。 1. `log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、​`SplunkHttp`​ Log4j アペンダーを含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 ```xml ``` 1. 設定に Splunk 連動関係が含まれていることを確認します。 ```xml com.splunk.logging splunk-library-javalogging x.x.x ********* ****************** splunk-artifactory Splunk Releases https://splunk.jfrog.io/splunk/ext-releases-local; ``` Splunk の最新バージョンについては、 [GitHub](https://github.com/splunk/splunk-library-javalogging/tags)​ を参照してください。 アプリケーションが起動すると、カスタム Log4j アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [MDC ログ](https://docs.mulesoft.com/mule-runtime/latest/logging-mdc) # 拡張性ベンチマーク Runtime Fabric は中核となる Kubernetes (K8s) ソフトウェアであり、Runtime Fabric のハードウェアとソフトウェアの要件に準拠するすべての K8s 環境で同じように動作します。次のスケールリミットは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。
制限事項 説明 Runtime Fabric による適用

ノード数

ノードの最大数は 400 です。

推奨

Runtime Fabric でのデプロイメント

最適なパフォーマンスを保証するため、任意のインスタンスにおいて Runtime Fabric が管理するデプロイメントの最大数は 8000 を超えないようにしてください。

推奨
Runtime Fabric の機能やアプリケーションデプロイメントの管理は以下に左右されません。 - 各アプリケーションのサイズ - ワーカーノードのサイズ - ワーカーノードあたりの実行されているポッド数 Runtime Fabric は K8s ベースであり、クラウドネイティブのオーケストレーションプリンシパルを使用しているため、指定されたデプロイメントの設定に従って動作します。 次の評価されたメトリクスを確認して、ほぼ空のクラスターと 8000 個のデプロイを実行しているクラスターを比較した場合のさまざまな管理メトリクスを把握してください。使用されているクラスター設定は、AWS EKS クラスター上の Runtime Fabric です。
設定 説明

VPC とノードグループ

eksctl から実行されるデフォルトの設定。3 つのサブネット (ノードグループごとに 1 つのサブネット)、NAT ゲートウェイ。

AWS NLB

Nginx 作成時に Helm チャートを介して装備。

ノードの自動スケーラー

推奨 3 GB (メモリ)/200m vCore (要求==上限)

ワーカー

m5.4x の大きさ、ワーカーノードグループ

監視

固定、1 つのノード、Prometheus、監視ノードグループ、m5.2x の大きさ

イングレス

固定、2 つのノード、Nginx、イングレスノードグループ、m5.4x の大きさ
次の画像は、顧客またはクラスターのアップグレードによって呼び出された場合に Runtime Fabric エージェントが再起動に要する時間を示しています。 ![ほぼ空のクラスターと負荷ありのクラスターの再起動のレイテンシーを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.5/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric は、デプロイメントの量に関係なくアプリケーションの作成に約 190 秒を要します。 次の表に、Mule アプリケーションの起動、停止、削除に要する時間を示します。
アプリケーション操作 ほぼ空のクラスター 負荷あり

起動のレイテンシー

~110 秒

158 秒

停止のレイテンシー

~10 秒

20 秒

削除のレイテンシー

~9 秒

~28 秒
次の表に、不正なノードがある場合に node cordon 操作を再開するのに要する時間を示しています。
ノード操作 空のクラスター 負荷ありのクラスター

Cordon

~2 秒

~2 秒

Drain process

~4 秒

~35 秒
考慮すべき側面: - Runtime Fabric エージェントは大規模なデプロイメントのクラスターを管理する場合に必要なメモリや CPU の量がデフォルトよりも多くなり、これらの値は次の表の情報を使用して変更できます。8000 件のデプロイメントがあるクラスターでは、少なくとも次の量を使用してください。
クラスターの推奨 デフォルト 200 個のノード/8000 個のアプリケーションリソース設定

エージェントリソース

メモリは 200 mb を要求、500 mb が上限。CPU は 100m を要求、1vCore が上限。

3 GB (メモリ)/2vCore (要求 == 上限)
- Helm では、大規模の操作を行う場合、ノードウォッチャー ​`nodeWatcherEnabled`​ を明示的に無効にする必要があります。ノードウォッチャーは必ずデフォルトで有効になっています (​`nodeWatcherEnabled: true`​)。 - Runtime Fabric を使用した大規模のデプロイメントのオーケストレーションのパフォーマンスはデプロイメントの量に反比例します。 - RTFCTL クラスターは特定のベンチマークに対してのみサポートされています。 - Helm を使用すると、クラスターのサイズのために Runtime Fabric エージェントにカスタマイズされたリソースが必要な任意のクラスターを管理できます。 # 拡張性ベンチマーク Runtime Fabric は中核となる Kubernetes (K8s) ソフトウェアであり、Runtime Fabric のハードウェアとソフトウェアの要件に準拠するすべての K8s 環境で同じように動作します。次のスケールリミットは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。
制限事項 説明 Runtime Fabric による適用

Runtime Fabric でのデプロイメント

最適なパフォーマンスを保証するため、任意のインスタンスにおいて Runtime Fabric が管理するデプロイメントの最大数は 8000 を超えないようにしてください。

推奨

水平ポッド自動スケーリング (HPA)

Amazon EKS で Runtime Fabric を使用する場合、レプリカ数を 1 から 8 にスケーリングすると、トラフィック障害が発生する可能性が約 0.09% あります。このようなエラーはポッドスケーリング期間に固有のものであるため、スケーリング操作中にトラフィック障害が発生する可能性があります。
Runtime Fabric の機能やアプリケーションデプロイメントの管理は以下に左右されません。 - 各アプリケーションのサイズ - ワーカーノードのサイズ - ワーカーノードあたりの実行されているポッド数 Runtime Fabric は K8s ベースであり、クラウドネイティブのオーケストレーションプリンシパルを使用しているため、指定されたデプロイメントの設定に従って動作します。 次の評価されたメトリクスを確認して、ほぼ空のクラスターと 8000 個のデプロイを実行しているクラスターを比較した場合のさまざまな管理メトリクスを把握してください。使用されているクラスター設定は、AWS EKS クラスター上の Runtime Fabric です。
設定 説明

VPC とノードグループ

eksctl から実行されるデフォルトの設定。3 つのサブネット (ノードグループごとに 1 つのサブネット)、NAT ゲートウェイ。

AWS NLB

Nginx 作成時に Helm チャートを介して装備。

ノードの自動スケーラー

推奨 3 GB (メモリ)/200m vCore (要求==上限)

ワーカー

m5.4x の大きさ、ワーカーノードグループ

監視

固定、1 つのノード、Prometheus、監視ノードグループ、m5.2x の大きさ

イングレス

固定、2 つのノード、Nginx、イングレスノードグループ、m5.4x の大きさ
次の画像は、顧客またはクラスターのアップグレードによって呼び出された場合に Runtime Fabric エージェントが再起動に要する時間を示しています。 ![ほぼ空のクラスターと負荷ありのクラスターの再起動のレイテンシーを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.6/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric は、デプロイメントの量に関係なくアプリケーションの作成に約 190 秒を要します。 次の表に、Mule アプリケーションの起動、停止、削除に要する時間を示します。
アプリケーション操作 ほぼ空のクラスター 負荷あり

起動のレイテンシー

~110 秒

158 秒

停止のレイテンシー

~10 秒

20 秒

削除のレイテンシー

~9 秒

~28 秒
次の表に、不正なノードがある場合に node cordon 操作を再開するのに要する時間を示しています。
ノード操作 空のクラスター 負荷ありのクラスター

Cordon

~2 秒

~2 秒

Drain process

~4 秒

~35 秒
考慮すべき側面: - Runtime Fabric エージェントは大規模なデプロイメントのクラスターを管理する場合に必要なメモリや CPU の量がデフォルトよりも多くなり、これらの値は次の表の情報を使用して変更できます。8000 件のデプロイメントがあるクラスターでは、少なくとも次の量を使用してください。
クラスターの推奨 デフォルト 200 個のノード/8000 個のアプリケーションリソース設定

エージェントリソース

メモリは 200 mb を要求、500 mb が上限。CPU は 100m を要求、1vCore が上限。

3 GB (メモリ)/2vCore (要求 == 上限)
- Helm では、大規模の操作を行う場合、ノードウォッチャー ​`nodeWatcherEnabled`​ を明示的に無効にする必要があります。ノードウォッチャーは必ずデフォルトで有効になっています (​`nodeWatcherEnabled: true`​)。 - Runtime Fabric を使用した大規模のデプロイメントのオーケストレーションのパフォーマンスはデプロイメントの量に反比例します。 - RTFCTL クラスターは特定のベンチマークに対してのみサポートされています。 - Helm を使用すると、クラスターのサイズのために Runtime Fabric エージェントにカスタマイズされたリソースが必要な任意のクラスターを管理できます。 - Runtime Fabric エージェントのリソース制限をスケールアップする場合、必要に応じて要求を増やすことを検討してください。 - 制限を完全に削除してコンテナを無制限に実行することは避けてください。OpenShift Operator の場合、制限を削除すると、エージェントの制限設定がデフォルトに設定されます。 # 拡張性ベンチマーク Runtime Fabric は中核となる Kubernetes (K8s) ソフトウェアであり、Runtime Fabric のハードウェアとソフトウェアの要件に準拠するすべての K8s 環境で同じように動作します。
これらの拡張性ベンチマークは、Runtime Fabric 2.7.0 以降に適用されます。
## [](#スケールリミット)スケールリミット 次のスケールリミットは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。
制限事項 説明 Runtime Fabric による適用

Runtime Fabric でのデプロイメント

最適なパフォーマンスを保証するため、任意のインスタンスにおいて Runtime Fabric が管理するデプロイメントの最大数は 8000 を超えないようにしてください。

推奨

水平ポッド自動スケーリング (HPA)

Amazon EKS で Runtime Fabric を使用する場合、レプリカ数を 1 から 8 にスケーリングすると、トラフィック障害が発生する可能性が約 0.09% あります。このようなエラーはポッドスケーリング期間に固有のものであるため、スケーリング操作中にトラフィック障害が発生する可能性があります。
Runtime Fabric の機能やアプリケーションデプロイメントの管理は以下に左右されません。 - 各アプリケーションのサイズ - ワーカーノードのサイズ - ワーカーノードあたりの実行されているポッド数 Runtime Fabric は K8s ベースであり、クラウドネイティブのオーケストレーションプリンシパルを使用しているため、指定されたデプロイメントの設定に従って動作します。 ## [](#評価されたメトリクス)評価されたメトリクス 次の評価されたメトリクスを確認して、ほぼ空のクラスターと 8000 個のデプロイを実行しているクラスターを比較した場合のさまざまな管理メトリクスを把握してください。使用されているクラスター設定は、AWS EKS クラスター上の Runtime Fabric です。
設定 説明

VPC とノードグループ

eksctl から実行されるデフォルトの設定。3 つのサブネット (ノードグループごとに 1 つのサブネット)、NAT ゲートウェイ。

AWS NLB

Nginx 作成時に Helm チャートを介して装備。

ノードの自動スケーラー

推奨 3 GB (メモリ)/200m vCore (要求==上限)

ワーカー

m5.4x の大きさ、ワーカーノードグループ

監視

固定、1 つのノード、Prometheus、監視ノードグループ、m5.2x の大きさ

イングレス

固定、2 つのノード、Nginx、イングレスノードグループ、m5.4x の大きさ
## [](#runtime-fabric-の再起動レイテンシー)Runtime Fabric の再起動レイテンシー 次の画像は、顧客またはクラスターのアップグレードによって呼び出された場合に Runtime Fabric エージェントが再起動に要する時間を示しています。 ![ほぼ空のクラスターと負荷ありのクラスターの再起動のレイテンシーを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.7/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric は、デプロイメントの量に関係なくアプリケーションの作成に約 190 秒を要します。 次の表に、Mule アプリケーションの起動、停止、削除に要する時間を示します。
アプリケーション操作 ほぼ空のクラスター 負荷あり

起動のレイテンシー

~110 秒

158 秒

停止のレイテンシー

~10 秒

20 秒

削除のレイテンシー

~9 秒

~28 秒
次の表に、不正なノードがある場合に node cordon 操作を再開するのに要する時間を示しています。
ノード操作 空のクラスター 負荷ありのクラスター

Cordon

~2 秒

~2 秒

Drain process

~4 秒

~35 秒
## [](#考慮事項)考慮事項 次のスケールの考慮事項を確認してください。 - Runtime Fabric エージェントは大規模なデプロイメントのクラスターを管理する場合に必要なメモリや CPU の量がデフォルトよりも多くなり、これらの値は次の表の情報を使用して変更できます。8000 件のデプロイメントがあるクラスターでは、少なくとも次の量を使用してください。
クラスターの推奨 デフォルト 200 個のノード/8000 個のアプリケーションリソース設定

エージェントリソース

メモリは 200Mi を要求、500Mi が上限。CPU は 100m を要求、1vCore が上限。

1000Mi (メモリ)/1vCore (要求 == 上限)

デーモンリソース

メモリは 200Mi を要求、300Mi が上限。CPU は 150m を要求、200m が上限。

1200Mi (メモリ)/500m (要求 == 上限)
- Runtime Fabric を使用した大規模のデプロイメントのオーケストレーションのパフォーマンスはデプロイメントの量に反比例します。 - RTFCTL クラスターは特定のベンチマークに対してのみサポートされています。 - Helm を使用すると、クラスターのサイズのために Runtime Fabric エージェントにカスタマイズされたリソースが必要な任意のクラスターを管理できます。 - Runtime Fabric エージェントのリソース制限をスケールアップする場合、必要に応じて要求を増やすことを検討してください。 - 制限を完全に削除してコンテナを無制限に実行することは避けてください。OpenShift Operator の場合、制限を削除すると、エージェントの制限設定がデフォルトに設定されます。 - `resource-cache`​ および ​`mule-clusterip-service`​ サービスはステートレスであるため、水平方向にスケールできます。 # 拡張性ベンチマーク Runtime Fabric は中核となる Kubernetes (K8s) ソフトウェアであり、Runtime Fabric のハードウェアとソフトウェアの要件に準拠するすべての K8s 環境で同じように動作します。 ## [](#スケールリミット)スケールリミット 次のスケールリミットは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターで評価されています。
制限事項 説明 Runtime Fabric による適用

Runtime Fabric でのデプロイメント

最適なパフォーマンスを保証するため、任意のインスタンスにおいて Runtime Fabric が管理するデプロイメントの最大数は 8000 を超えないようにしてください。

推奨

水平ポッド自動スケーリング (HPA)

Amazon EKS で Runtime Fabric を使用する場合、レプリカ数を 1 から 8 にスケーリングすると、トラフィック障害が発生する可能性が約 0.09% あります。このようなエラーはポッドスケーリング期間に固有のものであるため、スケーリング操作中にトラフィック障害が発生する可能性があります。
Runtime Fabric の機能やアプリケーションデプロイメントの管理は以下に左右されません。 - 各アプリケーションのサイズ - ワーカーノードのサイズ - ワーカーノードあたりの実行されているポッド数 Runtime Fabric は K8s ベースであり、クラウドネイティブのオーケストレーションプリンシパルを使用しているため、指定されたデプロイメントの設定に従って動作します。 ## [](#評価されたメトリクス)評価されたメトリクス 次の評価されたメトリクスを確認して、ほぼ空のクラスターと 8000 個のデプロイを実行しているクラスターを比較した場合のさまざまな管理メトリクスを把握してください。使用されているクラスター設定は、AWS EKS クラスター上の Runtime Fabric です。
設定 説明

VPC とノードグループ

eksctl から実行されるデフォルトの設定。3 つのサブネット (ノードグループごとに 1 つのサブネット)、NAT ゲートウェイ。

AWS NLB

Nginx 作成時に Helm チャートを介して装備。

ノードの自動スケーラー

推奨 3 GB (メモリ)/200m vCore (要求==上限)

ワーカー

m5.4x の大きさ、ワーカーノードグループ

監視

固定、1 つのノード、Prometheus、監視ノードグループ、m5.2x の大きさ

イングレス

固定、2 つのノード、Nginx、イングレスノードグループ、m5.4x の大きさ
## [](#runtime-fabric-の再起動レイテンシー)Runtime Fabric の再起動レイテンシー 次の画像は、顧客またはクラスターのアップグレードによって呼び出された場合に Runtime Fabric エージェントが再起動に要する時間を示しています。 ![ほぼ空のクラスターと負荷ありのクラスターの再起動のレイテンシーを示す図](/mulesoft/current/ja-jp/runtime-fabric/2.8/_images/rtf-scale-cluster-upgrade.png) Runtime Fabric は、デプロイメントの量に関係なくアプリケーションの作成に約 190 秒を要します。 次の表に、Mule アプリケーションの起動、停止、削除に要する時間を示します。
アプリケーション操作 ほぼ空のクラスター 負荷あり

起動のレイテンシー

~110 秒

158 秒

停止のレイテンシー

~10 秒

20 秒

削除のレイテンシー

~9 秒

~28 秒
次の表に、不正なノードがある場合に node cordon 操作を再開するのに要する時間を示しています。
ノード操作 空のクラスター 負荷ありのクラスター

Cordon

~2 秒

~2 秒

Drain process

~4 秒

~35 秒
## [](#考慮事項)考慮事項 次のスケールの考慮事項を確認してください。 - Runtime Fabric エージェントは大規模なデプロイメントのクラスターを管理する場合に必要なメモリや CPU の量がデフォルトよりも多くなり、これらの値は次の表の情報を使用して変更できます。8000 件のデプロイメントがあるクラスターでは、少なくとも次の量を使用してください。
クラスターの推奨 デフォルト 200 個のノード/8000 個のアプリケーションリソース設定

エージェントリソース

メモリは 200Mi を要求、500Mi が上限。CPU は 100m を要求、1vCore が上限。

1000Mi (メモリ)/1vCore (要求 == 上限)

デーモンリソース

メモリは 200Mi を要求、300Mi が上限。CPU は 150m を要求、200m が上限。

1200Mi (メモリ)/500m (要求 == 上限)
- デフォルトのリソース割り当てでは、最大 2,000 個のアプリケーション/75 個のノードがサポートされています。 - Runtime Fabric を使用した大規模のデプロイメントのオーケストレーションのパフォーマンスはデプロイメントの量に反比例します。 - RTFCTL クラスターは特定のベンチマークに対してのみサポートされています。 - Helm を使用すると、クラスターのサイズのために Runtime Fabric エージェントにカスタマイズされたリソースが必要な任意のクラスターを管理できます。 - Runtime Fabric エージェントのリソース制限をスケールアップする場合、必要に応じて要求を増やすことを検討してください。 - 制限を完全に削除してコンテナを無制限に実行することは避けてください。OpenShift Operator の場合、制限を削除すると、エージェントの制限設定がデフォルトに設定されます。 - `resource-cache`​ および ​`mule-clusterip-service`​ サービスはステートレスであるため、水平方向にスケールできます。 # 自己管理型 Kubernetes の Anypoint Runtime Fabric 自己管理型 Kubernetes の Anypoint Runtime Fabric を使用すると、作成、設定、管理する Kubernetes クラスターに Mule アプリケーションおよび API プロキシをデプロイできます。自己管理型 Kubernetes の Anypoint Runtime Fabric は既存の Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境のサービスとして実行されます。 ## [](#自己管理型-kubernetes-の-anypoint-runtime-fabric-のコアコンポーネント)自己管理型 Kubernetes の Anypoint Runtime Fabric のコアコンポーネント 自己管理型 Kubernetes の Anypoint Runtime Fabric とその基盤となるコンポーネントは、EKS、AKS、または GKE 環境で Kubernetes デプロイメントオブジェクトとして実行されます。これらのオブジェクトは Anypoint Platform を通じて管理します。 Linux ベースのオペレーティングシステムは、自己管理型 Kubernetes クラスターで Runtime Fabric コンポーネントを実行するすべてのノードに必要です。 ### [](#runtime-fabric-エージェント)Runtime Fabric エージェント Runtime Fabric エージェントはポッドとしてクラスターにデプロイされ、起動時に確立される mTLS アウトバウンド接続を介してコントロールプレーンと通信します。 エージェントはイベント駆動型です。アプリケーションの状態変更により Kubernetes イベントが生成されると、エージェントはアプリケーションの現在の状態を説明するメタデータをコントロールプレーンに送信します。Kubernetes イベントにはアプリケーションポッドの起動、更新、または再起動が含まれます。 エージェントはコントロールプレーンからの受信要求もリスンします。エージェントがコントロールプレーンからメッセージを受信すると、エージェントはメッセージで指定された Kubernetes リソースに変更を加えます。このような変更には、新しいアプリケーションの作成、既存のアプリケーションの更新、アプリケーションの削除などがあります。 ### [](#追加のクラスターコンポーネント)追加のクラスターコンポーネント 次の Runtime Fabric コンポーネントも Kubernetes クラスター内で実行されます。 - Mule クラスター IP サービス: Mule アプリケーションがクラスター内でピアを発見するために使用する API を提供します。 - リソースキャッシュ: アプリケーション連動関係のクラスター-ローカルキャッシュを提供します。 - 永続性ゲートウェイ: Mule アプリケーションへの永続性 ObjectStore インターフェースを提供します。 ### [](#コンポーネントのインストールとアップグレードについて)コンポーネントのインストールとアップグレードについて 自己管理型 Kubernetes の Anypoint Runtime Fabric を Kubernetes クラスターにインストールすると、コマンドラインユーティリティ (​`rtfctl`​) によってアクティベーションデータトークンが一連のアクティベーションプロパティにスワップされます。プロパティには Runtime Fabric Docker レジストリにアクセスするためのログイン情報と Anypoint Platform への mTLS 接続を確立するためのログイン情報が含まれます。続いて、ユーティリティでインストールを実行するための Helm が呼び出されます。 クラスターでの自己管理型 Kubernetes の Anypoint Runtime Fabric コンポーネントへのアップグレードは、Anypoint Platform コントロールプレーンから、具体的には Runtime Manager からトリガーします。アップグレードをトリガーすると、アップグレードメッセージが対象クラスター内で処理され、​`rtfctl`​ でコンポーネントのソフトウェアバージョンをアップグレードするための Helm が呼び出されます。アップグレード中に問題が発生した場合、​`rtfctl`​ を使用して Helm ロールバックを呼び出し、クラスターを安定状態に復元できます。ロールバックにより、コントロールプレーンにレポートが作成されます。 ## [](#自己管理型-kubernetes-の-anypoint-runtime-fabric-でのアプリケーションデプロイメントの動作)自己管理型 Kubernetes の Anypoint Runtime Fabric でのアプリケーションデプロイメントの動作 自己管理型 Kubernetes の Anypoint Runtime Fabric にアプリケーションをデプロイするときは、次の動作が起こります。 1. Runtime Manager を使用してアプリケーションデプロイメントをトリガーします。 2. 対象クラスターの Runtime Fabric エージェントがアプリケーションをデプロイする要求を受信します。 3. Runtime Fabric によってアプリケーションが既存の名前空間に割り当てられるか、必要な場合は新しい名前空間が作成されます。 4. Runtime Fabric によってデプロイメント、ConfigMap、シークレット、サービス、イングレスなど、適切な Kubernetes リソースが生成されます。 5. Kubernetes デプロイメントリソースに init コンテナが含まれている場合は、Runtime Fabric リソースキャッシュから連動関係が取得されます。 6. リソースキャッシュに必須の連動関係が含まれていない場合、Runtime Fabric によってコントロールプレーンから取得され、リソースキャッシュに追加されます。 ![自己管理型 Kubernetes の Anypoint Runtime Fabric のアプリケーションデプロイメントワークフロー](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-app-deployment.png) ### [](#自己管理型-kubernetes-の-anypoint-runtime-fabric-で名前空間を割り当てる)自己管理型 Kubernetes の Anypoint Runtime Fabric で名前空間を割り当てる 各アプリケーションはアプリケーションの環境に基づいて Kubernetes 名前空間にデプロイされます。 1. Runtime Fabric によって表示ラベルが ​`rtf.mulesoft.com/envId=`​ の名前空間が検索されます。 2. Runtime Fabric によってその表示ラベルを見つけられなかった場合は、名前が ​``​ の名前空間が検索されます。 3. Runtime Fabric によってその名前空間が見つけられなかった場合、​``​ という名前の新しい名前空間が作成されます。 ![アプリケーション名前空間の割り当てフローチャート](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-namespace-flow.png) ### [](#アプリケーションデプロイメントの監視)アプリケーションデプロイメントの監視 Runtime Fabric エージェントでは、​`rtf.mulesoft.com/id`​ という表示ラベルの付いた Kubernetes デプロイメントを監視します。Kubernetes によってデプロイメントの状態が更新されると、エージェントによってその更新がコントロールプレーンに送信されます。詳細は、​[「ログ」](#logs)​と​[「監視」](#monitoring)​を参照してください。 ## [](#共有責任としての自己管理型-kubernetes-の-anypoint-runtime-fabric)共有責任としての自己管理型 Kubernetes の Anypoint Runtime Fabric 自己管理型 Kubernetes で Anypoint Runtime Fabric が正常に動作するかどうかは共有責任となります。お客様が提供して管理する領域と MuleSoft によって提供される領域を理解することが重要です。 自己管理型 Kubernetes の Anypoint Runtime Fabric インスタンスにおける MuleSoft とお客様の異なる共有責任を下図に示します。 ![自己管理型 Kubernetes の Anypoint Runtime Fabric の共有責任の図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-shared-responsibility.png) ### [](#mulesoft-によって提供される内容)MuleSoft によって提供される内容 MuleSoft は、Runtime Fabric エージェント、Mule Runtime Engine (Mule)、および Mule アプリケーションのデプロイに使用されるその他の連動関係を提供します。Runtime Fabric エージェントは、デプロイメント、ポッド、レプリカセット、イングレスリソースなどの Kubernetes リソースを生成して更新することで Mule アプリケーションをデプロイして管理します。 #### [](#runtime-fabric-コアサービス)Runtime Fabric コアサービス Runtime Fabric により、次のコアサービスがインストールされます。 - Runtime Fabric エージェント - Mule クラスター IP サービス - リソースキャッシュ これらのサービスは、コア Runtime Fabric インストールの名前空間とレプリカ内で分離されています。これらのサービスはアプリケーションの増加に伴って増加しません。 #### [](#アプリケーションサービス)アプリケーションサービス Runtime Fabric によって次のアプリケーションサービスがインストールされるのは、ユーザーが設定した場合のみです。 - 永続性ゲートウェイ: Object Store v2 接続用 (ユーザーが設定した複製) - Anypoint Monitoring サイドカー: 監視およびログ記録用 (アプリケーションレプリカごとに 1 つのサイドカーがデプロイされる) ### [](#お客様による管理)お客様による管理 お客様は、自己管理型 Kubernetes の Anypoint Runtime Fabric に使用される Kubernetes のプロビジョニング、設定、管理の責任を負います。下記のような、Kubernetes クラスターで機能をセットアップまたは有効化するために使用される追加の設定も、お客様が管理する責任を負います。 - イングレスコントローラーと​[イングレスリソースのカスタマイズ](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration)​ - 内部負荷分散 - ログ転送 - 監視 - ネットワークポート、NAT ゲートウェイ、プロキシ - ホストランタイムとネットワーク - Kubernetes 環境のプロビジョニングと管理。これには、組織内の次のチームの支援が必要です - IT チームによるインフラストラクチャのプロビジョニングと管理 - ネットワークチームによる許可ポートの指定とプロキシの設定 - セキュリティチームによるコンプライアンスの検証とセキュリティ証明書の取得 ## [](#自己管理型-kubernetes-の-runtime-fabric-の要件)自己管理型 Kubernetes の Runtime Fabric の要件 以降の説明で、自己管理型 Kubernetes の Anypoint Runtime Fabric を実行するための全般的な要件を示します。 ### [](#kubernetes-のサポート)Kubernetes のサポート 自己管理型 Kubernetes の Runtime Fabric には、プロビジョニングされ運用可能な専用クラスターが必要です。​`rtfctl`​ コマンドラインユーティリティを使用して、環境が正しく設定されているかどうかを確認します。​[「自己管理型 Kubernetes の Runtime Fabric のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed)​を参照してください。 サポートされている Kubernetes バージョンについては、メジャーおよびマイナーバージョンの Runtime Fabric の​[リリースノート](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes)​を参照してください。 ### [](#サポート対象のアーキテクチャ)サポート対象のアーキテクチャ 自己管理型 Kubernetes の Anypoint Runtime Fabric には、x86/x64 アーキテクチャを使用するワーカーノードが必要です。ARM ベースのアーキテクチャはサポートされていません。 ### [](#オペレーティングシステム)オペレーティングシステム 自己管理型 Kubernetes の Anypoint Runtime Fabric では、Amazon EKS、AKS、または GKE でサポートされる Linux ベースのオペレーティングシステムがサポートされています。 ### [](#ノードおよびリソース)ノードおよびリソース 一般に、Kubernetes ベンダーによって提供されるベストプラクティスに従って、可用性を確保し、インフラストラクチャの管理を簡略化します。 それぞれが次のリソースを使用する少なくとも 2 つのノードがある環境で、自己管理型 Kubernetes の Runtime Fabric をインストールして、ベストプラクティスに従ってください。 - 少なくとも 2 つの CPU コア - 少なくとも 15 GiB の RAM - 少なくとも 250 GiB の空きディスク容量 自己管理型 Kubernetes の Anypoint Runtime Fabric の各インスタンスで実行するワークロードの量と種別に応じて、割り当てられるノード数とリソース量を調整します。 ### [](#anypoint-platform-のロールと権限)Anypoint Platform のロールと権限 自己管理型 Kubernetes の Anypoint Runtime Fabric を適切に使用するには、Anypoint Platform アカウントで次の権限が有効になっている必要があります。 - Anypoint Platform ユーザーの権限を管理するには、​[Anypoint Access Management](https://docs.mulesoft.com/jp/access-management/)​ を使用するための権限が必要です。 - アプリケーションをデプロイして管理するには、Anypoint Runtime Manager を使用するための権限が必要です。アプリケーションをデプロイするには、Anypoint Platform アカウントの「Exchange Contributors (Exchange コントリビューター)」権限を有効にする必要があります。 - Runtime Fabric を使用するには、対応する環境の「Organization Administrators (組織のシステム管理者)」権限または「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 - Runtime Fabric インスタンスを削除するには、システム管理者に組織レベルの「Manage Runtime Fabrics (Runtime Fabric の管理)」権限が必要です。 ### [](#ネットワーク設定)ネットワーク設定 自己管理型 Kubernetes の Anypoint Runtime Fabric では、ネットワークポート、ホスト名、証明書を正しく機能するように IT 管理者が設定する必要があります。​[「自己管理型 Kubernetes の Runtime Fabric をサポートするためのネットワークの設定」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed-network-configuration)​を参照してください。 ### [](#イングレスコントローラー)イングレスコントローラー 自己管理型 Kubernetes の Runtime Fabric では、Kubernetes 環境と互換性があるすべてのイングレスコントローラーがサポートされ、アプリケーションデプロイメントごとに個別のイングレスリソースが作成されるデプロイメントモデルがサポートされています。一般に、既製のイングレスコントローラーのほとんどではこのモデルがサポートされています。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。GKE によって提供されるイングレスコントローラーを使用する前に、その動作についての詳細を確認して回避策を調べ、この動作が望ましくない場合は別のイングレスコントローラーを使用してください。詳細は、KB 記事​を参照してください。
### [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 自己管理型 Kubernetes の Runtime Fabric にデプロイされたアプリケーションでは、ログが ​`stdout`​ に転送されます。コンテナランタイムはログを収集してファイルに書き込みます。このファイルの保存場所はコンテナランタイムと設定によって異なります。詳細は Kubernetes 環境のドキュメントを参照してください。 ### [](#外部ログ転送)外部ログ転送 自己管理型 Kubernetes の Anypoint Runtime Fabric では、外部ログ転送はサポートされていません。お客様は、外部ログフォワーダーをインストール、設定、管理する責任を負います。Amazon EKS、AKS、または GKE で実行される Kubernetes 環境と互換性のある任意の外部ログ転送エージェントを使用できます。次のような一般的ログ転送エージェントがあります。 - Splunk Connect for Kubernetes - Fluentbit Titanium のお客様の場合、自己管理型 Kubernetes の Anypoint Runtime Fabric では Anypoint Monitoring を使用したログがサポートされています。詳細は、​[「Anypoint Monitoring のログ」](https://docs.mulesoft.com/jp/monitoring/logs)​を参照してください。 ### [](#監視)監視 [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ では、Runtime Fabric にデプロイされたアプリケーションや API ゲートウェイのメトリクスが提供されます。 メトリクスを収集するために、Runtime Fabric にデプロイされたすべてのアプリケーションで Anypoint Monitoring サイドカーが実行されます。監視を有効または無効にする方法など、詳細は​[「Runtime Fabric にデプロイされたアプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/manage-monitor-applications)​を参照してください。 Runtime Fabric ではサードパーティ監視ソリューションの統合はサポートされていません。 ## [](#関連情報)関連情報 - [自己管理型 Kubernetes の Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed) # 自己管理型 Kubernetes の Runtime Fabric でのプロキシの管理 自己管理型 Kubernetes の Runtime Fabric は、アプリケーションを実行およびホストするときに 2 種類のプロキシを使用します。 - システムプロキシ: Docker デーモンやその他の内部コンポーネントを含む、Kubernetes クラスターサービス間の接続を可能にするプロキシが含まれます。自己管理型 Kubernetes の Runtime Fabric を使用する場合は、システムプロキシを設定および管理する必要があります。 - アプリケーションプロキシ: Runtime Fabric で実行されているアプリケーションへの接続を可能にするプロキシが含まれます。 インターネットへの Runtime Fabric アウトバウンド接続で使用するプロキシ設定を設定できます。これには、Anypoint コントロールプレーンに接続するための HTTP プロキシと、メトリクスとログを Anypoint Monitoring に送信するための SOCKS5 プロキシの両方が含まれます。アプリケーションのプロキシを設定することもできます。 ## [](#rtfctl-のインストール)rtfctl のインストール Runtime Fabric のプロキシ設定を管理するには、​`rtfctl`​ コマンドラインツールが必要です。プロキシ設定を行う前に、​[rtfctl をインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​する手順を実行します。

Helm を使用してインストールする場合は、自己管理型 Kubernetes への Runtime Fabric のインストール中にプロキシ設定を適用できます。詳細は、​「Helm を使用した自己管理型 Kubernetes の Runtime Fabric のインストール」​を参照してください。
## [](#configure-proxy)Anypoint Monitoring プロキシを設定する 監視エージェントは SOCKS5 プロキシを使用するため、Anypoint Monitoring を使用する場合は 2 つのプロキシ種別が必要です。 SOCKS5 プロキシは、次のエンドポイントで TCP 経由で Anypoint Monitoring に接続する必要があります。 - US コントロールプレーン: `dias-ingestor-router.us-east-1.prod.cloudhub.io` - EU コントロールプレーン: `dias-ingestor-router.eu-central-1.prod-eu.msap.io`
このステップは、コントローラーノードで 1 回だけ実行します。
1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 sudo /opt/anypoint/runtimefabric/rtfctl apply monitoring-proxy "socks5://:@<10.0.0.2>:<8080>" - ****​: SOCKS5 プロキシの認証に必要なユーザー名。 - ****​: SOCKS5 プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.2>**​: SOCKS5 プロキシへのアクセスに使用される IP アドレスまたはホスト名。 - **<8080>**​: SOCKS5 プロキシが要求をリスンするホストのポート。 3. 変更が成功したことを確認するには、次のコマンドを実行して、監視プロキシの現在の値を出力します。 sudo /opt/anypoint/runtimefabric/rtfctl get monitoring-proxy 出力は期待される値と一致する必要があります。 ## [](#configure-http-proxy)Runtime Fabric のサービス用に HTTP プロキシを設定する アウトバウンドコンポーネントがコントロールプレーンと通信できるように HTTP プロキシと HTTPS プロキシを設定できます。 HTTP プロキシを更新すると、クラスター内の各マシンは、マシンで実行されているすべてのポッドを再起動します。複数のレプリカを実行している場合、ダウンタイムは発生しませんが、メンテナンスウィンドウ中に HTTP プロキシの更新を実行する必要があります。 - Runtime Fabric 内で実行されているサービスにプロキシの値を適用する。 - Runtime Fabric インストーラー 1.0.x を使用している場合は、Runtime Fabric の各ノードでスクリプトを実行してクラスターを更新する。
これらのステップは、1 つのコントローラーノードで 1 回実行します。
1. `rtfctl`​ がインストールされているコントローラーノードにログインします。 2. 次のコマンドを実行し、プレースホルダーの値を次の値に置き換えます。 sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy "http://:@<10.0.0.1>:<8080>" --no-proxy "<1.1.1.1:8888,2.2.2.2:9999>" - ****​: HTTP プロキシの認証に必要なユーザー名。 - ****​: HTTP プロキシの認証に必要なパスワード。
パスワードは URL にエンコードされている必要があります。
- **<10.0.0.1>**​: HTTP プロキシにアクセスするための IP アドレスまたはホスト名を指定します。 - **<8080>**​: HTTP プロキシが要求をリスンするホストのポートを指定します。 - **<1.1.1.1:8888,2.2.2.2:9999>**​: カンマで区切られた ​`RTF_NO_PROXY`​ ホストとポートを指定します。 - (省略可能) ​`--confirm`​: 変更の手動の肯定応答をスキップします。指定しなかった場合、​`rtfctl apply proxy`​ コマンドでは、続行する前に変更を確認することが求められます。 3. 変更が成功したことを確認するには、次のコマンドを実行して、HTTP プロキシの現在の値を出力します。 sudo /opt/anypoint/runtimefabric/rtfctl get http-proxy 出力は期待される値と一致する必要があります。 4. プロキシ値を削除するには、次のコマンドを実行します。 sudo /opt/anypoint/runtimefabric/rtfctl apply http-proxy '' --no-proxy '' ### [](#http_proxy-環境変数について)HTTP\_PROXY​ 環境変数について Runtime Fabric のサービスにプロキシを適用したら、次のような警告が表示される場合があります。 Warning: Proxy configurations in the environment "HTTP\_PROXY: " does not match configurations in Runtime Fabric "YOUR\_PROXY" Runtime Fabric で [この警告](https://help.mulesoft.com/s/article/Warning-Proxy-configurations-in-the-environment-HTTP-PROXY-does-not-match-configurations-in-Runtime-Fabric)​が生成されるのは、​`HTTP_PROXY`​ 環境変数を設定していないこと、または変数が Runtime Fabric サービスに使用される値と一致しないことを知らせるためです。これらの設定は必ずしも一致している必要はありませんが、Runtime Fabric ではサービスが影響を受ける可能性もあることを知らせるために警告が生成されます。 多くの Linux ツールでは ​`HTTP_PROXY`​ 環境変数を使用してそのプロキシ設定を提供しています。環境にインターネットアクセス用のプロキシが必要な場合、インターネットアクセスが必要なコマンド用に ​`HTTP_PROXY`​ 環境変数を設定する必要がある可能性が高くなります。 これにより、​`kubectl`​ のように HTTP または HTTPS 操作を使用するがインターネットアクセスが不要な他のツールに影響する可能性もあります。​`NO_PROXY`​ 環境変数を使用して、プロキシする必要がない接続を確立できます。 環境変数によるそのプロキシの動作に対する影響に関する詳細は、Linux ツールのドキュメントを参照してください。 ### [](#no_proxy-環境変数について)NO\_PROXY​ 環境変数について デフォルトでは、​`NO_PROXY`​ は ​`0.0.0.0/0`​ と ​`.local`​ に設定されます。これらの設定により、プロキシで IPV4 宛先アドレスが転送されなくなります。 ## [](#configure-proxy-api)API Manager エージェントのプロキシを設定する プロキシを使用して、API Manager で管理する Mule アプリケーション用の通信を確立できます。すべてのアプリケーションに同じ設定を使用している場合でも、このプロキシ設定は各 Mule アプリケーションで定義する必要があります。この設定はアプリケーションが他の外部エンドポイントと通信するために使用するアプリケーションレベルのプロキシとは無関係です。 API Manager エージェントのプロキシを設定するには、次のプロパティをアプリケーションに追加します。 anypoint.platform.proxy\_host=hostname anypoint.platform.proxy\_port=port anypoint.platform.proxy\_username=username anypoint.platform.proxy\_password=password ## [](#configure-proxy-mule-app)Mule アプリケーション用のプロキシの設定 Runtime Fabric でデプロイされるアプリケーションは、Runtime Fabric クラスターからプロキシ設定を継承しません。各アプリケーションでプロキシを設定する必要があります。 各コネクタ (HTTP リクエスターなど) でプロキシをセットアップするか、または次の例に示すようにアプリケーションのプロパティでプロキシをセットアップすることができます。アプリケーションで多くのコネクタを使用する場合は、アプリケーションのプロパティでプロキシを設定した方が楽です。 http.nonProxyHosts=localhost|\*.svc.cluster.local|\*.monitoring.svc.cluster.local http.proxyHost=172.19.0.23 http.proxyPort=3128 https.proxyHost=172.19.0.23 https.proxyPort=3128 java.net.useSystemProxies=false com.ning.http.client.AsyncHttpClientConfig.useProxySelector=false com.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true ## [](#関連情報)関連情報 - [自己管理型 Kubernetes の Runtime Fabric のインストール](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed) # 自己管理型 Kubernetes の Runtime Fabric でのローカルレジストリの使用 Runtime Fabric では、独自のレジストリを使用して Runtime Fabric をインストールして管理し、Kubernetes でアプリケーションを実行するために必要な Docker イメージを保存します。セキュリティポリシーで、自分で管理しているレジストリから Docker イメージを取得することが要求されている場合は、これらの Docker イメージを取得して保存するようにローカルレジストリをセットアップできます。 ## [](#ローカルレジストリのサポートに関する制限事項)ローカルレジストリのサポートに関する制限事項 ローカルレジストリのサポートに関する次の制限事項を確認してください。 - Runtime Fabric は自己管理型 Kubernetes のローカルレジストリのみをサポートします。 - [Runtime Fabric コマンドラインユーティリティ (​`rtfctl`​)](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​ バージョン 0.3.150 以降を使用する必要があります。 - ローカルレジストリを使用できるのは、バージョン 1.12.0 以降の新しい Runtime Fabric インスタンスを作成する場合のみです。 ローカルレジストリをセットアップする場合は、Runtime Fabric を再インストールせずに 1.12.0 より後のバージョンにアップグレードできます。 そのインストールを 1.12.0 以降にアップグレードする場合でも、ローカルレジストリを任意のバージョンの既存の Runtime Fabric インスタンスに追加することはできません。 - ローカルレジストリで使用するために Runtime Fabric インスタンスを作成した場合、​`rtf-runtime-registry`​ エンドポイントを使用するように後から再設定することはできません。​`rtf-runtime-registry`​ エンドポイントを使用するには、標準のインストール手順に従って新しい Runtime Fabric インスタンスをインストールする必要があります。 - レジストリと Runtime Fabric レジストリ間の同期については各自が責任を負うことになります。MuleSoft では、レジストリ間でイメージを同期するための追加のソフトウェアを提供していません。インストールを始める前に、ご使用のバージョンのすべての連動関係イメージをローカルレジストリにプッシュしてください。ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes)​を参照してください。 - 認証が必要なローカルレジストリを使用している場合、異なる名前空間の間でのプルシークレットの同期と伝播は各自の責任となります。または、シークレットで次の表示ラベルを使用している場合は、Runtime Fabric により異なる名前空間の間でプルシークレットを同期できます。 labels: rtf.mulesoft.com/synchronized: "true" - ローカルレジストリへのアクセス権を認証する必要がある場合は、 [対応するログイン情報が ​`rtf`​ 名前空間で Kubernetes シークレットとして設定されていること](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials)​を確認してください。Runtime Fabric をインストールするときに設定済みのシークレットの名前が必要になります。 - また、アプリケーションのデプロイメントに使用する Mule Runtime バージョンをレジストリ内で同期する必要もあります。最新の Mule Runtime パッチバージョンに関する情報については、​[「Runtime Fabric Patch Update Release Notes (Runtime Fabric パッチ更新リリースノート)」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-runtimes-release-notes)​を参照してください。イメージの場所は次の形式に従います: rtf-runtime-registry.kqa.msap.io/mulesoft/poseidon-runtime-4.4.0: ## [](#runtime-fabric-で使用するローカルレジストリをセットアップする)Runtime Fabric で使用するローカルレジストリをセットアップする ローカルレジストリをセットアップするには、レジストリを同期するために必要なログイン情報を収集して追加する必要があります。 ### [](#始める前に)始める前に 次の作業を必ず実行しておいてください。 1. 非公開の Docker イメージレジストリをセットアップ、設定、およびテストします。 2. Runtime Fabric のインストールに必要なすべての Docker イメージをローカルレジストリに同期します。 ご使用の Runtime Fabric バージョンの必須の連動関係については、​[「Runtime Fabric リリースノート」](https://docs.mulesoft.com/jp/release-notes/runtime-fabric/runtime-fabric-release-notes#1120)​を参照してください。
連動関係バージョンは Runtime Fabric バージョンに固有です。
3. [`rtfctl`​ コマンドラインユーティリティ](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed#step-3-download-the-rtfctl-utility)​バージョン 0.3.150 以降をダウンロードしてインストールします。 4. [Runtime Manager を使用して Runtime Fabric を作成](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed#step-3-download-the-rtfctl-utility)​してアクティベーションデータを収集します。 ### [](#ローカルレジストリを設定して-runtime-fabric-をインストールする)ローカルレジストリを設定して Runtime Fabric をインストールする 1. `rtf-runtime-registry`​ ログイン情報を取得します。 \# rtfctl get registry-credentials このコマンドにより、現在のシェル環境で ​`RTF_IMAGE_REGISTRY_ENDPOINT`​、​`RTF_IMAGE_REGISTRY_USER`​、​`RTF_IMAGE_REGISTRY_PASSWORD`​ が設定されます。 2. 次のコマンドを実行して、​`rtf-runtime-registry`​ への Docker ログインが成功することを確認します。 \# eval $(rtfctl get docker-registry-login ) # docker login $RTF\_IMAGE\_REGISTRY\_ENDPOINT --username $RTF\_IMAGE\_REGISTRY\_USER --password $RTF\_IMAGE\_REGISTRY\_PASSWORD ログインが成功したというメッセージが表示されます。 3. イメージを取得して同期するには、自分の非公開コンテナレジストリにログインして次のコマンドを実行します。​``​ は適宜置き換えてください。 US コントロールプレーンの場合: \# docker pull rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push /mulesoft/rtf-agent:v1.12.0 EU コントロールプレーンの場合: \# docker pull rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 # docker tag rtf-runtime-registry.kprod-eu.msap.io/mulesoft/rtf-agent:v1.12.0 /mulesoft/rtf-agent:v1.12.0 # docker push :5000/mulesoft/rtf-agent:v1.12.0 4. Runtime Fabric リリースノートでパブリッシュされているバージョンに基づいて、他のすべての連動関係イメージ (resourceFetcher、clusterOps など) でステップ 3 を繰り返します。 5. レジストリへのアクセスに認証を使用している場合は、rtf 名前空間で必須のシークレットを作成します。 \# kubectl create namespace rtf # kubectl create secret docker-registry regcred --namespace=rtf --docker-server= --docker-username= --docker-email= --docker-password= # kubectl label secret regcred rtf.mulesoft.com/synchronized=true -n rtf 6. Runtime Fabric インストールを最終処理して、ローカルレジストリから取得するように設定します。 \# rtfctl install ‘’ --image-pull-registry または、レジストリへのアクセスに認証を使用している場合は、次のコマンドを使用します。 \# rtfctl install ‘’ --image-pull-registry --image-pull-secret このコマンドにより、Runtime Fabric でローカルレジストリ URL と ​`image-pull-secret`​ 値の必要なオーバーライドが作成され、Runtime Fabric がアップグレード後も引き続きローカルレジストリからイメージを取得するようになります。 7. レジストリへのアクセスに認証を使用している場合は、インストールの完了後に、RTF 名前空間とアプリケーションをデプロイする他の名前空間でプルシークレットを再作成する必要があります。 8. Mule ライセンスキーの挿入などの追加の手順については、​[インストール手順](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed)​を参照してください。 `rtfctl uninstall`​ コマンドにより、インストール中に指定したプルシークレットが削除されます。 `rtfctl`​ を使用してバックアップと復元の手順を実行するときに、バックアップはローカルレジストリ URL とプルシークレットを参照します。 # 自己管理型 Kubernetes の Runtime Fabric のアンインストール インストール方法に応じて、Runtime Fabric コマンドラインツール (​`rtfctl`​) または Helm を使用して Runtime Fabric をアンインストールできます。 ## [](#rtfctl-を使用して-runtime-fabric-をアンインストールする)rtfctl を使用して Runtime Fabric をアンインストールする `rtfctl`​ を使用して自己管理型 Kubernetes 上の Runtime Fabric をアンインストールする手順は次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. `rtfctl uninstall`​ コマンドを実行して、Kubernetes クラスターから Runtime Fabric サービスをアンインストールします。 5. `rtfctl uninstall --confirm`​ コマンドを実行して、アンインストール操作を確認します。 6. アンインストールコマンドが終了したら、クラスターで Runtime Fabric アプリケーションまたはサービスが実行されていないことを確認します。 ## [](#helm-を使用して-runtime-fabric-をアンインストールする)Helm を使用して Runtime Fabric をアンインストールする Helm を使用して自己管理型 Kubernetes 上の Runtime Fabric をアンインストールする手順は次のとおりです。 1. Runtime Manager を使用して、Runtime Fabric でデプロイされたすべての Mule アプリケーションと API ゲートウェイを削除します。 2. 関連するすべての環境で、すべてのアプリケーションを削除したことを確認します。 3. Runtime Manager を使用して、Runtime Fabric を削除します。 4. 次のコマンドを実行します。 helm uninstall runtime-fabric -n rtf インストールプロセス中のエラー (例: インストールが正常に完了しなかった) によってアンインストールが必要になった場合は、次のコマンドを実行します。 + helm uninstall runtime-fabric -n rtf --no-hooks # 自己管理型 Kubernetes の Runtime Fabric のイングレスの設定

このコンテンツでは、バージョン 1.10 以降の Runtime Fabric でのイングレスの設定について説明します。以前のイングレスの設定手順については、バージョン 1.8 または 1.9 のドキュメントを参照してください。
自己管理型 Kubernetes の Anypoint Runtime Fabric では、イングレスリソーステンプレートを使用してカスタムイングレス設定を指定できます。テンプレートでは、 [Kubernetes イングレス仕様](https://kubernetes.io/docs/concepts/services-networking/ingress/)​と同様、アノテーション、イングレスクラス名、および HTTP および HTTPS ルールを指定できます。 アプリケーションのイングレスリソーステンプレートを適用しない場合、デプロイしたときにイングレスエンドポイントを追加できません。

デフォルトでは、Google Kubernetes Engine (GKE) と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、 「Default Ingress Controller Behavior with Runtime Fabric on GKE (GKE での Runtime Fabric を使用したデフォルトのイングレスコントローラーの動作)」​を参照してください。

AWS アプリケーションのロードバランサーでは、​group.name​ アノテーションを使用しない限り同様の動作になります。詳細は、 「Application load balancing on Amazon EKS (Amazon EKS でのアプリケーションの負荷分散)」​を参照してください。
## [](#カスタムイングレスリソーステンプレートの利点)カスタムイングレスリソーステンプレートの利点 Runtime Fabric でカスタムイングレスリソーステンプレートを使用すれば、以下に対するサポートを含めてネイティブ Kubernetes イングレス設定機能を活用できます。 - アプリケーションごとに複数のイングレス設定 - 同じ Runtime Fabric インスタンス内の複数のイングレスコントローラー - TLS および HTTPS 設定 - カスタム URL 名前付け - URL パラメーターのプレースホルダー ## [](#runtime-fabric-でのイングレスリソーステンプレートの動作)Runtime Fabric でのイングレスリソーステンプレートの動作 次の図では、Runtime Fabric でイングレスリソーステンプレートを使用する方法の概要を示しています。 ![Runtime Fabric でのイングレステンプレートワークフローを示す図](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/ingress-diagram.png) 1. IT 管理者がイングレスコントローラーを設定します。 2. IT 管理者が必須パラメーターを使用してイングレスリソーステンプレートを作成または変更します。イングレスコントローラーの動作はそれぞれ異なります。イングレスコントローラーのドキュメントを確認して、アノテーションを調整してください。 3. IT 管理者が ​`kubectl apply`​ コマンドを使用してテンプレートを適用します。 4. 適用されたテンプレートから、Runtime Fabric によってプレースホルダーの URI ドメインが作成され、すべてのアプリケーションデプロイメントのテンプレートとして Anypoint Runtime Manager でイングレス設定が伝播されます。 5. Mule アプリケーション開発者が Runtime Manager を使用して、イングレステンプレートで指定されているように、使用可能なホスト、省略可能なサブドメイン、およびパスの組み合わせを選択することでデプロイメントのアプリケーションを設定します。 6. Runtime Fabric によってアプリケーションデプロイメント要求が受信され、テンプレートのイングレス設定を使用してクラスターで対応するイングレスオブジェクトが作成されます。 ## [](#イングレスリソーステンプレートの例)イングレスリソーステンプレートの例 次の例では、Runtime Fabric イングレスリソーステンプレートを作成するために Kubernetes イングレス仕様を変更する方法を示しています。 お使いの Kubernetes バージョンに適した API バージョンを使用してください。 - Kubernetes v1.19 以降: - networking.k8s.io/v1 - networking.k8s.io/v1beta1 Kubernetes v1.22 以降では、​`extensions/v1beta1`​ および ​`networking.k8s.io/v1beta1`​ API バージョンのイングレスは使用できません。 - Kubernetes v1.18 以前: - networking.k8s.io/v1beta1 のみ ### [](#networking-k8s-iov1)networking.k8s.io/v1

このテンプレートは設定の簡略化バージョンです。テンプレートの最終的な設定は、使用しているコントローラーおよびイングレスのルーティングルールに応じて異なる場合があります。お使いのイングレスコントローラーのドキュメントを慎重にお読みください。
```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - pathType: Prefix path: / (6) backend: (7) service: name: service-name port: name: service-port ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#networking-k8s-iov1beta1)networking.k8s.io/v1beta1 ```yaml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: example-rtf-ingress namespace: rtf (1) labels: spec: ingressClassName: rtf-nginx (2) tls: (3) - hosts: - app-name.example.com secretName: example-tls rules: - host: app-name.example.com (4) http: paths: (5) - path: / (6) pathType: backend: (7) serviceName: service-name servicePort: 80 ``` この例について、次の点に注意してください。
1 このテンプレートは ​rtf​ 名前空間に配置する必要があります。
2 ingressClassName には ​rtf-​ のプレフィックスを付ける必要があります (たとえば、​rtf-nginx​)。

Runtime Fabric では ​rtf-​ プレフィックスを使用してオブジェクトをテンプレートとして認識します。 spec.ingressClassName​ 項目または ​kubernetes.io/ingress.class​ アノテーションの ​rtf-​ プレフィックスが付いたテンプレートは、Runtime Fabric エージェントのみにコンシュームされ、実際のイングレスコントローラーにはコンシュームされません。 イングレスコントローラーでは、ベンダー固有の名前 (たとえば、​nginx​ や ​haproxy​) を使用する ​spec.ingressClassName​ 値が含まれるリソースのみを検出します。
3 TLS は省略可能です。

secretName​ 属性が含まれる TLS セクションを追加する場合、必ず ​rtf​ 名前空間で参照される TLS シークレットを作成する必要もあります。
4 アプリケーションをデプロイすると、​app-name​ プレースホルダーのパラメーターは実際のアプリケーション名に置き換えられます。これにより、サブドメインにワイルドカードが含まれない場合に各エンドポイント名を一意にすることができます。
5 テンプレートにはホストの複数のパスを含めることができますが、Runtime Manager にはホストの最初のパスルールのみが表示されます。
6 path​ パラメーター値は、​Mule アプリケーションのイングレスを設定​するときに ​[Path (パス)]​ 項目に追加した値で置き換えられます。​path​ はプレースホルダーではありません。
7 これらのプレースホルダー値は Kubernetes 検証に必須ですが、実際の値は Runtime Fabric によって使用されません。
パスベースのルーティングイングレステンプレートの場合、イングレスコントローラーのドキュメントを参照してから設定してください。 Nginx の使用例については、 [「Path-based Nginx Ingress Routing Example for Runtime Fabric on Self-Managed Kubernetes (自己管理型 Kubernetes の Runtime Fabric のパスベースの Nginx イングレスルーティングの例)」](https://help.mulesoft.com/s/article/Path-based-Nginx-Ingress-Routing-Example-for-Runtime-Fabric-on-Self-Managed-Kubernetes)​を参照してください。 ### [](#テンプレートのプレースホルダー)テンプレートのプレースホルダー 次のプレースホルダーは省略可能です。プレースホルダーを使用する場合、テンプレートの適切な場所で置き換えてください。プレースホルダーは小文字にしてください。
プレースホルダーの名前 場所 値の例。

business-group-id

path​、​host​、​annotation, labels

 
labels:
  business:
  business-group-id

environment-id

path​、​host​、​annotation, labels

 
labels:
  environment:
  environment-id

unique-id

path​、​annotation、labels

 
path: /app-name-unique-id.com
`unique-id`​ プレースホルダーを使用して一意のアプリケーション URL を作成します。この方法は、異なるビジネスグループから同じ名前を持つ 2 つのアプリケーションをデプロイする場合に便利です。たとえば、イングレステンプレートの ​`path`​ セクションで ​`app-name-unique-id.com`​ を使用する場合、生成されるエンドポイントは ​`app-name-7jkbic.com`​ のようになります。

unique-id​ プレースホルダーは Runtime Fabric バージョン 1.12.28 以降で使用できます。
## [](#イングレステンプレートでの-tls-の使用)イングレステンプレートでの TLS の使用 イングレステンプレートで TLS を使用するには、TLS シークレットを作成する必要があります。詳細は、 [Kubernetes TLS のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)​を参照してください。 `rtf.mulesoft.com/synchronized=true`​ 表示ラベルを使用して、たとえば次のように、TLS シークレットの更新をすべてのアプリケーション名前空間に同期するように Runtime Fabric を設定できます。 ```none apiVersion: v1 kind: Secret metadata: name: testsecret-tls namespace: default labels: rtf.mulesoft.com/synchronized=true data: tls.crt: base64 encoded cert tls.key: base64 encoded key type: kubernetes.io/tls ``` この表示ラベルをシークレットに適用すると、イングレスコントローラーで更新済みの TLS 素材をアプリケーション名前空間にすぐに適用できるようになります。この表示ラベルを追加しない場合は、各名前空間でシークレットを手動で更新する必要があります。 ## [](#runtime-fabric-で-mule-アプリケーションデプロイメント用のイングレスを設定する)Runtime Fabric で Mule アプリケーションデプロイメント用のイングレスを設定する イングレスを設定するには、次のタスクを実行します。 1. イングレスリソーステンプレートを作成してクラスターで適用します。 2. Mule アプリケーションのイングレスを設定します。 ### [](#始める前に)始める前に Runtime Fabric でイングレスをセットアップする前に、イングレスコントローラーを設定する必要があります。イングレスコントローラーのリストについては、 [Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/)​を参照してください。 ### [](#イングレスリソーステンプレートを作成してクラスターで適用する)イングレスリソーステンプレートを作成してクラスターで適用する [テンプレート例](#example-ingress-resource-templates)​のいずれかを使用してイングレスリソースを作成します。 1. テンプレート例を新しいファイルにコピーして、コメントに変更します。 2. ファイル名に ​`.yaml`​ 拡張子を含めます。 3. イングレステンプレートを適用するには、次のコマンドを実行します。 `kubectl apply -f ` テンプレートに問題がある場合、Kubernetes ​`api-server`​ によってエラーが返され、コマンドは失敗します。 テンプレートを正常に適用したら、次のコマンドを使用して表示できます。 `kubectl describe ingress [Ingress Name] -n rtf` ### [](#mule-アプリケーションのイングレスを設定する)Mule アプリケーションのイングレスを設定する Runtime Manager を使用して Runtime Fabric にデプロイするときに、アプリケーションのイングレスを設定します。アプリケーションに使用可能なホストおよびパスは、Runtime Fabric システム管理者が設定したイングレスリソーステンプレートから取得されます。 この手順を使用してテストアプリケーションをデプロイし、イングレスリソーステンプレートを検証することもできます。

次に、アプリケーションのイングレスを設定する方法の概要を示します。 完全なデプロイメント手順については、​「Runtime Fabric に Mule アプリケーションをデプロイする」​を参照してください。 Mule Maven プラグインを使用してアプリケーションを Runtime Fabric にデプロイする場合、ブロック ​http​ のデプロイメント設定パラメーター ​publicUrl​ で複数のエンドポイントのカンマ区切り文字列を受け入れることができます。 詳細は、​「deploymentSettings パラメーターリファレンス」​を参照してください。
1. \[Runtime Manager\] に移動し、ドキュメントに従ってアプリケーションを Runtime Fabric にデプロイします。 2. **\[Ingress (イングレス)\]**​ を選択します。 3. **\[Host (ホスト)\]**​ ドロップダウンリストからアプリケーションのホストを選択します。 4. ホスト名にワイルドカードが使用されている場合、​**\[Subdomain (サブドメイン)\]**​ 項目でサブドメインを追加します。 **\[Subdomain (サブドメイン)\]**​ 項目はホスト名にワイルドカードが使用されている場合のみ使用できます。 5. **\[Path (パス)\]**​ 項目で、アプリケーションのエンドポイントに URL パスを追加します。 ![エンドポイントのホスト項目とパス項目が入力されます](/mulesoft/current/ja-jp/runtime-fabric/1.13/_images/rtf-ingress-endpoint.png) 6. エンドポイントをプレビューするには、生成されたプレビューリンクをクリックします。 7. 別のエンドポイントを追加するには、​**\[+ Add Endpoint (+ エンドポイントを追加)\]**​ をクリックします。 8. 準備ができたら、​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#既存のイングレス設定のアップグレード後の変換)既存のイングレス設定のアップグレード後の変換 Runtime Fabric バージョン 1.10 にアップグレードする場合、アップグレードプロセスでアノテーション、パス、名前空間、ホストパラメーターを含む既存のイングレスの ConfigMaps が自動的にイングレスリソーステンプレート形式に変換されます。下の表を確認して、アップグレード後にアクションが必要かどうかを判断してください。
アップグレード前の Runtime Fabric アップグレード後の Runtime Fabric 必要なアクション TLS サポート

ドメインは設定されず、ingress-ConfigMap は適用されない

アップグレード後にテンプレートが自動的に生成されない

テンプレートを作成する。​[Create an Ingress Resource Template and Apply it in the Cluster]​を参照してください。

-

ドメインは設定されないが、有効な ingress-ConfigMap が適用される

生成されたテンプレートにホストの ​*​ が含まれ、以前の ingress-ConfigMap のパスおよびアノテーションが含まれる

生成されたテンプレートで ​host​ 項目を編集し、Runtime Manager でアプリケーションをデプロイするための有効なホスト/ドメインを指定する

デフォルトでは TLS セクションは追加されない

有効なドメインが設定されるが、ingress-ConfigMap は適用されない

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、各テンプレートのパスに ​/app-name​ が含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる

有効なドメインが設定され、有効な ingress-ConfigMap が適用される

生成されたテンプレートにテンプレートあたり 1 つのドメインにつき 1 つのホストが含まれ、以前の ingress-ConfigMap のパスおよびアノテーションがすべて含まれる

ドメインで ​https://​ が使用されていない限り、直ちにアクションは必要ない。使用されている場合は、HTTPS ドメインに対応するテンプレートで TLS シークレットを設定します

https://​ があるドメインでは、そのドメインに対応するテンプレートにシークレット属性のない TLS セクションが含まれる
## [](#イングレスの問題のトラブルシューティング)イングレスの問題のトラブルシューティング Runtime Fabric にイングレスを使用しようとしたときにエラーが発生した場合、次のようにトラブルシューティングしてください。 ### [](#mule-アプリケーションをデプロイしたがそのエンドポイントにアクセスできない)Mule アプリケーションをデプロイしたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager で Mule アプリケーションを正常にデプロイしましたが、アプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. アプリケーションがポート 8081 でリスンしていることを確認します。 `kubectl port-forward -n [NAMESPACE] svc/ 8081:8081` 2. アプリケーションが実行されていて HTTP 要求に応答していることを確認します。 `curl -v http://127.0.0.1:8081/` これにより、API アクセスの問題が Mule アプリケーション自体にあるかどうかを判断できます。 3. そのアプリケーションサービスのイングレスリソースが存在することを検証します。 `kubectl get ingress -n [NAMESPACE]` 4. サービスが作成されたことを検証します。 `kubectl get svc -n [NAMESPACE]` 作成されなかった場合は、Runtime Fabric エージェントのログを確認します。 `kubectl logs -n rtf [AGENT_POD_NAME] -f` サービスおよびイングレスオブジェクトに問題がないように思われる場合は、その他のトラブルシューティングタスクを確認してください。 ### [](#イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない)イングレスリソースがクラスターで作成されたがそのエンドポイントにアクセスできない シナリオ: Runtime Manager ではクラスターでイングレスリソースが正常に作成されましたが、404 エラーのためにアプリケーションのエンドポイントにアクセスできません。 この問題をトラブルシューティングする手順は、次のとおりです。 1. イングレスとサービスのリソースを確認します。 kubectl get ingress -n kubectl get svc -n 次のような結果が返されます。 \# kubectl get ingress -n< NAME CLASS HOSTS ADDRESS PORTS AGE .com 80, 443 7m3s #kubectl get svc -n< NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ClusterIP 8081/TCP,8082/TCP,5701/TCP 8m5s 2. アプリケーションのイングレスリソースを確認して、リソース、アノテーション、ホストの HTTP パスが正常に表示されることを確認します。 `kubectl get ing -n -oyaml` 次のような結果が返されます。 ```yaml # kubectl get ing -n -oyaml apiVersion: extensions/v1beta1 kind: Ingress metadata: labels: ingress.rtf.mulesoft.com/svcName: ingress.rtf.mulesoft.com/svcVersion: … … spec: ingressClassName: rules: - host: myapp.example.com http: paths: - backend: serviceName: myapp servicePort: 8081 path: / pathType: Prefix tls: - hosts: myapp.example.com secretName: example-tls status: loadBalancer: ingress: - hostname: ``` 3. アプリケーションポッドログを確認して、適切なリスニングポートを設定していることを確認します。 `kubectl logs -f -n -c app` 次のような結果が返されます。 \# kubectl logs -f -n< -c app ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Starting app '' + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Starting ResourceManager \[2021-07-29 21:22:37.842\] INFO QueueXaResourceManager \[ArtifactDeployer.start.01\] \[event: \]: Started ResourceManager \[2021-07-29 21:22:37.846\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: org.mule.runtime.module.extension.internal.runtime.config.ConfigurationProviderToolingAdapter-HTTP\_Listener\_config \[2021-07-29 21:22:37.859\] INFO GrizzlyHttpServer \[ArtifactDeployer.start.01\] \[event: \]: Listening for connections on 'http://0.0.0.0:8081' \[2021-07-29 21:22:37.874\] INFO FlowConstructLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting flow: sample-json-backendFlow \[2021-07-29 21:22:38.171\] INFO AbstractLifecycleManager \[ArtifactDeployer.start.01\] \[event: \]: Starting Bean: listener \[2021-07-29 21:22:38.178\] INFO LogUtil \[ArtifactDeployer.start.01\]: 4. ログで、リスナーポートがステップ 1 で検出されたサービスポートに一致することを確認します。 5. ポートが正しい場合、アプリケーションログを確認してアプリケーションがイングレスコントローラーからの要求を受信していることを確認します。 ### [](#イングレスリソースが-aws-アプリケーションのロードバランサーによって認識されない)イングレスリソースが AWS アプリケーションのロードバランサーによって認識されない シナリオ: AWS ALB を使用している場合、アプリケーションおよびエンドポイントを正常にデプロイした場合でもアプリケーションのエンドポイントにアクセスできません。 イングレスに AWS ロードバランサーコントローラーを使用している場合、​`ingressClassName: rtf-alb` ​_ではなく_​テンプレートで ​`kubernetes.io/ingress.class: rtf-alb`​ アノテーションを指定する必要があります。AWS ロードバランサーコントローラーがこれらのアノテーションのためにデプロイされたイングレスリソース用の L7 ロードバランサーを検出して作成するには、​`ingress.class`​ アノテーションが必要です。 # 自己管理型 Kubernetes の Runtime Fabric のインストール Runtime Fabric のコマンドラインツールである ​`rtfctl`​ を使用して、管理している Amazon Elastic Kubernetes Service (Amazon EKS)、Azure Kubernetes Service (AKS)、または Google Kubernetes Engine (GKE) 環境に Anypoint Runtime Fabric をインストールできます。 ## [](#始める前に)始める前に 自己管理型 Kubernetes 環境に Anypoint Runtime Fabric をインストールする前に、次のことを確認してください。 - [「自己管理型 Kubernetes の Runtime Fabric」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​で説明されているアーキテクチャと要件を確認した - [自己管理型 Kubernetes の Runtime Fabric をサポートするようにネットワークを設定してある](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-self-managed-network-configuration) - Kubernetes 環境を次のようにインストールして設定している: - EKS、AKS、または GKE Kubernetes 環境。その他の Kubernetes 環境はサポートされていません。 - [サポートされている Kubernetes バージョン](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed#kubernetes-support) - 外部要求をアプリケーションに送信するためのイングレスコントローラー。 - 利用可能な最新の Runtime Fabric エージェントバージョンを使用してクラスターを作成します。最新バージョンを使用できない場合は、 [「How to Specify the RTF Agent Version in Upgrades^ (アップグレード時に RTF エージェントバージョンを指定する方法)」](https://help.mulesoft.com/s/article/RTF-Agent-upgrade-path)​を参照してください。

Runtime Fabric でローカルレジストリを使用する場合は、​「自己管理型 Kubernetes の Runtime Fabric でのローカルレジストリの使用」​のインストール手順に従ってください。インストール中にローカルレジストリをセットアップする必要があります。
## [](#runtime-manager-を使用して-runtime-fabric-を作成する)Runtime Manager を使用して Runtime Fabric を作成する 自己管理型 Kubernetes の Runtime Fabric をインストールする前に、Runtime Manager を使用して Runtime Fabric を作成します。これは、インストール中に必要なアクティベーションデータを取得するために必要です。 1. Anypoint Platform から \[Runtime Manager\] を選択します。 2. **\[Runtime Fabric\]**​ をクリックします。 3. **\[Create Runtime Fabric (Runtime Fabric を作成)\]**​ をクリックします。 4. 新しい Runtime Fabric の名前を入力し、次のいずれかのオプションを選択します。 - Amazon Elastic Kubernetes Service - Azure Kubernetes Service - Google Kubernetes Engine 5. **\[Next (次へ)\]**​ をクリックします。 6. **\[rtfctl\]**​ をクリックします。 7. **サポート責任**​の免責事項を確認し、同意する場合は ​**\[Accept (同意)\]**​ をクリックします。 Runtime Manager で Runtime Fabric を作成し、\[Activation State (アクティベーション状態)\] ページを表示します。このページには、Kubernetes サービスの Runtime Fabric をインストールするために使用されるアクティベーションデータが表示されます。次のセクションで使用するために、このデータをクリップボードにコピーします。 ## [](#rtfctl-ユーティリティをダウンロードする)rtfctl ユーティリティをダウンロードする 自己管理型 Kubernetes の Runtime Fabric は、インストールおよび管理タスクに ​`rtfctl`​ コマンドラインユーティリティを使用します。​[「Runtime Fabric コマンドラインツールのインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​を参照してください。 1. `rtfctl`​ コマンドラインユーティリティをダウンロードします。 `rtfctl`​ は、Windows、MacOS (Darwin)、および Linux でサポートされています。適切な方法を選択してください。 - Windows curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-windows/latest -o rtfctl.exe - MacOS (Darwin) curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl-darwin/latest -o rtfctl - Linux curl -L https://anypoint.mulesoft.com/runtimefabric/api/download/rtfctl/latest -o rtfctl 2. `rtfctl`​ コマンドラインユーティリティのファイル権限を変更します。 sudo chmod +x rtfctl ## [](#runtime-fabric-のインストール)Runtime Fabric のインストール Runtime Manager で Runtime Fabric を作成し、アクティベーションデータを取得したら、​`rtfctl`​ コマンドラインユーティリティを使用して Runtime Fabric を Kubernetes サービスにインストールします。 Kubernetes 設定が ​`\~/.kube/config`​ ディレクトリにない場合は、​`rtfctl`​ を実行する前に ​`KUBECONFIG`​ 環境変数を設定します。 export KUBECONFIG= 1. Kubernetes 環境のインストールの準備が整っていることを確認します。 rtfctl validate `validate`​ オプションで次のことを確認します。 - Kubernetes 環境が実行中。 - すべての必須コンポーネントが存在する。 - すべての必須サービスが使用可能。 `rtfctl`​ コマンドラインユーティリティは、Kubernetes 環境との非互換性を出力します。 2. Runtime Fabric をインストールします。 rtfctl install ``​ は、Runtime Manager を使用して Runtime Fabric を作成した後に取得されたアクティベーションデータです。インストール中、​`rtfctl`​ ユーティリティには発生したエラーが表示されます。 ## [](#mule-ライセンスキーを挿入する)Mule ライセンスキーを挿入する

このセクション内の手順は、IT 管理者が実行する必要があります。
インストールが正常に完了したら、Mule ライセンスキーを挿入します。 1. MuleSoft から提供された新しい Mule ​`.lic`​ ライセンスファイルを Base64 でエンコードします。 - MacOS では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -b0 license.lic) - Unix では、次のコマンドを実行します。 BASE64\_ENCODED\_LICENSE=$(base64 -w0 license.lic) - Windows では、次のいずれかを選択します。 - base64 ツールが含まれる WSL または Cygwin シェルを使用し、上記の Unix コマンドを使用します。 - Windows git (C:\\Program Files\\Git\\usr\\bin) と一緒に含まれている base64.exe プログラムを使用します。 - 次の Powershell コマンドを使用します。 $BASE64\_ENCODED\_LICENSE=\[convert\]::ToBase64String((Get-Content -path "license.lic" -Encoding byte)) 2. インストール中にリーダーとして機能するコントローラーノード (インストーラーノード) で、​`rtfctl`​ ユーティリティをライセンスキーの Base64 値と共に使用します。 rtfctl apply mule-license $BASE64\_ENCODED\_LICENSE 3. Mule ライセンスキーが適切に適用されていることを確認するには、次のコマンドを実行します。 rtfctl get mule-license ## [](#イングレスリソーステンプレートの設定)イングレスリソーステンプレートの設定

このセクション内の手順は、IT 管理者が実行する必要があります。
イングレスコントローラーにカスタムアノテーションとイングレスクラス定義が必要な場合は、​[「カスタムイングレス設定の定義」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration)​の手順に従います。

GKE のお客様の場合、デフォルトで GKE と一緒に含まれているイングレスコントローラーによってアプリケーションごとに個別の HTTP ロードバランサーがプロビジョニングされます。詳細は、こちらの KB 記事​を参照してください。
## [](#runtime-fabric-を検証する)Runtime Fabric を検証する

このセクション内の手順は、IT 管理者が実行する必要があります。
インストールが完了したら、Anypoint 組織内で Runtime Fabric をアクティブ化する必要があります。インストールを検証するには、Anypoint Runtime Manager に移動し、Runtime Fabric の状況が ​`[Active (アクティブ)]`​ であることを確認します。 アプリケーションを Runtime Fabric にデプロイする前に、次の手順を実行します。 1. Runtime Fabric を少なくとも 1 つの Anypoint 環境に関連付けます。 2. Kubernetes 環境に基づいてインバウンドトラフィック設定を確認および更新します。 3. アプリケーションをデプロイして、Runtime Fabric が正しくインストールおよび設定されていることを確認します。 ## [](#関連情報)関連情報 - [自己管理型 Kubernetes の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed) - [自己管理型 Kubernetes の Runtime Fabric のイングレスの設定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/custom-ingress-configuration) - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) # 自己管理型 Kubernetes の Runtime Fabric のリソース割り当てとパフォーマンス Mule アプリケーションを Anypoint Runtime Fabric にデプロイする前に、適切な割り当てリソース数を決定します。リソース割り当ての決定は、Anypoint Runtime Fabric で内部ロードバランサーを設定するときにも重要です。 Mule アプリケーションが Runtime Fabric にデプロイされるときに、そのアプリケーションは独自の Mule Runtime Engine (Mule) と共にデプロイされます。レプリカの数、またはそのアプリケーションとランタイムのインスタンスも指定されます。各レプリカに使用できるリソースは、アプリケーションのデプロイ時に設定した値によって決まります。 このトピックで提供されるパフォーマンス情報は、AWS EC2 M4 インスタンスを使用するコントローラーノードが含まれる Runtime Fabric クラスターに基づきます。クラスターは、3 個の m4.large コントローラーノードと 3 個の r4.large ワーカーノードを使用して設定されています。M4 インスタンスは EC2 専用に最適化されたカスタム Intel Xeon E5-2676 v3 Haswell プロセッサーを搭載しています。プロセッサーは 2.4 GHz のベースクロックレートで実行され、Intel Turbo Boost を使用すると 3.0 GHz まで上昇します。使用される負荷ジェネレーターは、同じリージョンの別の AWS インスタンスでホストされます。 アプリケーションのデプロイ時に次のリソースを割り当てることができます。 - vCPU コア - `Reserved vCPU` アプリケーションに対して保証されていて、アプリケーションで使用するために予約されている vCPU の数。 - `vCPU Limit` アプリケーションで使用できる vCPU の最大数 (アプリケーションでバーストできるレベル)。これは、ワーカーノードで共有される CPU です。 - Memory (メモリ) ## [](#mulesoft-ライセンスコンプライアンス)MuleSoft ライセンスコンプライアンス お客様は、常に MuleSoft のライセンス規約に準拠する必要があります。準拠の条件は以下のいずれかになります。 1. 各 Mule アプリケーションレプリカに割り当てられている CPU 制限の合計がライセンスされている合計数量以下である。 2. Mule アプリケーションを実行している Runtime Fabric ワーカーノードによって提供されている合計 CPU 容量がライセンスされている数量以下である。 予約済み vCPU と vCPU 制限を追跡する方法は、 [「How to Get Runtime Fabric (RTF) CPU Reserved and Limit for Self Managed Kubernetes and RTF Appliance (自己管理型 Kubernetes と RTF アプライアンスでの予約済み Runtime Fabric (RTF) CPU および制限の取得方法)」](https://help.mulesoft.com/s/article/How-to-Get-Runtime-Fabric-RTF-CPU-Reserved-and-Limit-for-Self-Managed-Kubernetes-and-RTF-Appliance)​を参照してください。 ## [](#vcpu-の割り当て)vCPU の割り当て \[​`Reserved vCPU`​ (予約済み vCPU)\] と \[​`vCPU Limit`​ (vCPU 制限)\] が等しい場合、保証されたモデルでワーカーノードの CPU が割り当てられます。コンテナでは、常に指定された数の CPU を使用できます。vCPU は、アプリケーションの各レプリカ用に予約されており、Runtime Fabric で他に何が実行されていても保証されます。 CPU の割り当てが保証されていると、他のアプリケーションとの CPU 競合がなくなり、アプリケーションの実行の一貫性が確保されます。すべてのケースでパフォーマンスが保証されます。 \[​`vCPU Limit`​ (vCPU 制限)\] の値が \[​`Reserved vCPU`​ (予約済み vCPU)\] の値よりも高く設定されていると、アプリケーションは、\[vCPU limit (vCPU 制限)\] の値またはワーカーノードの予約されていない vCPU の数のいずれか少ない方までバーストできます。 ワーカーノードに必要な CPU とメモリを見積もる場合、Anypoint Monitoring エージェントには Anypoint Monitoring 用に 0.05 以上の vCPU コアと 50 Mi 以上のメモリが必要です。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするために使用され、無効にできません。これらのコアとメモリの割り当ては Mule のライセンスには使用されません。 ## [](#cpu-バースト)CPU バースト CPU バーストを使用するときは、次の要素を考慮する必要があります。 - 最小予約済み vCPU: 0.02 vCPU。 - vCPU の下限: 0.07 vCPU。 大量のリソースを消費するアプリケーションでは、CPU 容量の追加が必要になる場合があります。アプリケーションデプロイメントで vCPU 下限量を使用していない場合は、vCPU 下限値を大きくしてからアプリケーションを再デプロイしてください。 - CPU 制限の上限は、ワーカーノードで提供される CPU コアによって決まります。 - 簡単なアプリケーションおよび API ゲートウェイの CPU コアごとの使用数は最大 20 ～ 25 個にすることをお勧めします。使用量の大きいより複雑なアプリケーションでは、より多くの容量が必要になる場合があります。 - Runtime Fabric では、ワーカーノードで少数のサービスが実行されます。これらのサービスは、Anypoint Monitoring でログ転送が有効になっているかどうかに応じて 0.3 ～ 0.5 vCPU をコンシュームします。 - 各アプリケーションのレプリカでは、Anypoint Monitoring を実行するコンテナ用に 50m の CPU と 50Mi のメモリを予約する必要があります。このコンテナは、アプリケーションメトリクスをコントロールプレーンにストリーミングするため、無効にできません。 - アプリケーションは、ワーカーノードの残りの未割り当て CPU を求めて競合します。ワーカーノードにデプロイされているアプリケーションが多いほど、他のアプリケーションと共有できる未割り当て CPU が少なくなり、パフォーマンスが低下する可能性があります。アプリケーションとの CPU 競合を最小限に抑えるために、次の戦略を検討してください。 - 日中に負荷がピークになる他のアプリケーションと共に夜間パッチアプリケーションをデプロイします。 - アプリケーションの複数のレプリカをデプロイし、ワーカーノードで分散されるようにして、未割り当て CPU の表面積を最大化します。 どのアプローチを選択する場合でも、テストを実行してパフォーマンスを検証します。 ## [](#メモリの割り当て)メモリの割り当て Mule アプリケーションまたは API ゲートウェイの各レプリカに割り当てられるメモリの量の最小値は、次のとおりです。 - 0.7 GB メモリ (Mule 4) - 0.5 GB メモリ (Mule 3) Anypoint Monitoring を有効化すると、Anypoint Monitoring サイドバーコンテナ用に 50MB のメモリが予約され、デプロイされた各アプリケーションがメトリクスを処理する際に最大 70MB を消費します。 ## [](#cloudhub-および-runtime-fabric-のメモリ割り当ての計算)CloudHub および Runtime Fabric のメモリ割り当ての計算 Anypoint Platform は、デプロイされたアプリケーションにネイティブメモリとヒープメモリを割り当てます。ヒープメモリは、Mule Runtime とアプリケーションで使用可能な合計メモリの一部です。ヒープメモリはペイロードの処理などのタスクに使用されます。 CloudHub と Anypoint Runtime Fabric とも、両方の種別のメモリを割り当てます。ただし、各メモリ種別のメモリ割り当てが計算される方法は異なります。 - Runtime Fabric は、アプリケーションで使用可能な合計メモリを表示する。 使用可能なヒープメモリは、アプリケーションに割り当てられる合計メモリの約半分です。 - CloudHub は、アプリケーションで使用可能なヒープメモリの観点から最小メモリ要件を表す。 ## [](#アプリケーションの起動時間)アプリケーションの起動時間 Mule アプリケーションの起動時間は、そのアプリケーションがアクセスできる vCPU コアの総数と相関しています。次の表では、ペイロードで処理を実行する単純な Mule プロキシアプリケーションのおおよその起動時間を示しています。
vCPU コア おおよその起動時間

1.00

1 分未満

0.50

2 分未満

0.10

6 ～ 8 分

0.07

10 ～ 14 分
## [](#アプリケーションのパフォーマンス)アプリケーションのパフォーマンス Mule アプリケーションに割り当てられたリソースによって、アプリケーションのパフォーマンスが決まります。次の表では、10-KB ペイロードで簡単な処理を実行する 1 つの Mule アプリケーションに割り当てられた vCPU コアの総数に基づく、スループットのおおよその値を次に示します。
vCPU コア 同時接続 平均応答時間 (ミリ秒)

1.00

10

15

0.50

5

15

0.10

1

25

0.07

1

78
Mule アプリケーションでパフォーマンステストと負荷テストを実行し、割り当てるリソースの数を決定します。
## [](#キーと証明書の-cpu-要件)キーと証明書の CPU 要件 最小 10 個の PEM/P12 または 8 個の JKS/JCEKS 証明書をサポートするのに十分な CPU リソースを割り当てていることを確認します。推奨されるコアの数は次のとおりです。
コア PEM/P12 JKS/JCEKS

0.25

8

2

0.5

10

4

0.75

10

6

<= 1

10

8
## [](#キー種別)キー種別 RSA キーは最も一般的なキー種別です。2K の長さの RSA キーは、セキュリティとパフォーマンスの最適なバランスを実現します。
2K よりも長い RSA キーは、ブルートフォースクラッキングを防ぎ、有効期限が何年もある証明書に適しています。ただし、2k から 4k のようにキーの長さが 2 倍になると、パフォーマンスが 6 倍以上低下します。
ECDSA キーもサポートされています。ほとんどの場合、ECDSA のパフォーマンスは、2K RSA キーの 2 倍になります。サポートされている曲線は、次のとおりです。 - secp521r1 (P-521) - secp384r1 (P-384) - secp256r1 (prime256v1 (P-256) とも呼ばれる) ## [](#関連情報)関連情報 - [Runtime Fabric に Mule アプリケーションをデプロイする](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric) - [Runtime Fabric の健全性詳細の表示](https://docs.mulesoft.com/jp/runtime-fabric/1.13/view-health) # 自己管理型 Kubernetes の Runtime Fabric の制限事項 次の情報は、自己管理型 Kubernetes の Anypoint Runtime Fabric のインストール、設定、管理を行うときに重要です。
制限事項 説明 Runtime Fabric による適用

ノード数

ノードの最大数は 400 です。

推奨

ノード種別

VM ベースのノードが必要です。たとえば、Fargate はサポートされていません。

はい

アプリケーションあたりのレプリカ数

アプリケーションあたりのレプリカの最大数は 8 です。

はい

ノードあたりのレプリカ数

ノードあたりのデプロイできるレプリカの最大数は 40 です。

バースティングの必要が生じた場合にレプリカ間でのコアを共有できるようにするために、実行するレプリカの数はコアあたり 20 ～ 25 個まで、ノードあたり最大 40 個までにしてください。これにより、レプリカが多すぎるために各ワーカーノードで実行されている Runtime Fabric の内部コンポーネントがオーバーロードになる事態を防ぐことができます。

推奨

Runtime Fabric あたりの関連付けられた環境数

Runtime Fabric は任意のビジネスグループの最大 100 個の環境に関連付けることができます。たとえば、開発環境および本番環境を組織 A に関連付けて開発環境を組織 B に関連付けた場合、3 つの環境の関連付けがあることになります。

はい

ビジネスグループ

ビジネスグループの組織あたり最大 50 個の Runtime Fabric を作成できます。サブ組織には、別のサブ組織で共有される Runtime Fabric に加えて、最大 50 個の Runtime Fabric を含めることができます。たとえば、親組織 A とその子組織 B がある場合、組織 A に 50 個の Runtime Fabric、組織 B に 50 個の Runtime Fabric を含めることができます。 組織 A の 50 個の Runtime Fabric をすべて組織 B と共有することもでき、その結果、組織 B のリストビューには合計 100 個の Runtime Fabric が表示されます。

はい
## [](#how-antivirus-and-dpi-software-impacts-runtime-fabric-functionality)ウイルス対策ソフトウェアと DPI ソフトウェアの Runtime Fabric の機能への影響 Anypoint Runtime Fabric には特定のハードウェアおよび OS の要件があります。MuleSoft サポートでは、​[VM/ベアメタル上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs)​ と​[自己管理型 Kubernetes 上の Runtime Fabric](https://docs.mulesoft.com/jp/runtime-fabric/1.13/index-self-managed)​ のインストールの前提条件で指定されている要件の検証と認証に基づいて、サポート SLA と重要度レベルを提供しています。 一部のサードパーティソフトウェアでは、ホストへのルートアクセス権が必要です。このようなソフトウェア (ウイルス対策ソフトウェアおよび DPI ソフトウェアを含むがこれに限定されない) が Runtime Fabric の動作および要件と干渉することがわかっています。MuleSoft サポートがウイルス対策ソフトウェアを検出した多くのサポートケースで、ポートのブロック、ノード間通信のブロック、Docker のデフォルトブリッジの削除、ファイルシステムへのアクセスの問題など、Runtime Fabric のインストール、アップグレード、通常の操作と干渉する問題が確認されています。 Runtime Fabric で異常な動作が見つかった場合は、サードパーティソフトウェア (ウイルス対策ソフトウェアや DPI ソフトウェアを含む) がその動作の原因となっているかを判断するため、これらのソフトウェアを無効にするよう要求される場合があります。これらのソフトウェアを無効にすることで適切な Runtime Fabric の機能が回復する場合には、そのソフトウェアパッケージと Runtime Fabric 間で互換性がないことを暗に示していると思われるため、サポートケースは解決済みであるとみなされます。 Runtime Fabric の特定のコンポーネントと干渉する従来のセキュリティツールを実行することが厳密に要求される場合は、この要件を満たせるように Kubernetes をサポートするベンダーおよびセキュリティエキスパートにサポートを依頼できます。クラウドプラットフォームベンダーでは多くの場合、 [Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)​ などのよく知られたセキュリティベンチマークと一貫性があるクラウド中心のコントロールが追加されます。 ## [](#ログ)ログ Anypoint Monitoring では、Runtime Fabric にデプロイされたアプリケーションの​[ログデータ](https://docs.mulesoft.com/jp/monitoring/logs)​へのアクセスが提供されます。Anypoint Monitoring でログにアクセスするには、Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションが必要です。 # 自己管理型 Kubernetes の Runtime Fabric をサポートするためのネットワークの設定

ネットワーク設定は IT 管理者が実行する必要があります。
自己管理型 Kubernetes の Runtime Fabric をインストールまたは使用する前に、次のポートとホスト名が正しく設定されていることを確認します。 ## [](#ポート設定)ポート設定 Runtime Fabric をインストールまたは実行するには、Kubernetes インストールで次のポートが設定されていることを確認します。 プロトコル対応のファイアウォールの場合は、次のポートトラフィックに Websockets 経由の AMQP (Advanced Message Queuing Protocol) を許可することを検討してください。

次の表には、Anypoint Platform のポートおよびホスト名は含まれていませんが、これらの許可する必要がある可能性があります。追加のポートおよびホスト名のリストについては、​Anypoint Mule ゲートウェイのドキュメント​を参照してください。
ポート レイヤー 4 プロトコル レイヤー 5 プロトコル ソース 宛先 説明

443

TCP

HTTPS

API コンシューマー

すべてのノード

イングレスコントローラーへのインバウンド API 要求を許可

443

TCP

WebSockets 経由の AMQP

すべてのノード

インターネット

Anypoint Platform 管理サービス

443

TCP

HTTPS

すべてのノード

インターネット

API Manager のポリシーの更新、API Analytics の取り込み、リソースの取得 (アプリケーションファイル、コンテナ画像)。

443 (v1.8.50 以降)

TCP

Lumberjack

すべてのノード

インターネット

Anypoint Monitoring、Anypoint Visualizer
## [](#永続性ゲートウェイで使用するポート)永続性ゲートウェイで使用するポート 永続性ゲートウェイには、Mule アプリケーションレプリカに永続データを保存するために Postgres 準拠のデータベースが必要です。Kubernetes クラスターがこのデータベースとポートにアクセスできることを確認してください。​[「永続性ゲートウェイ」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/persistence-gateway)​を参照してください。 ## [](#ホスト名設定)ホスト名設定 自己管理型 Kubernetes の Runtime Fabric を正しく機能させるには、次のホスト名設定が必要です。
Port (ポート) プロトコル ホスト名 説明

443

WebSockets 経由の AMQP

  • US コントロールプレーン: transport-layer.prod.cloudhub.io​

  • EU コントロールプレーン: transport-layer.prod-eu.msap.io

コントロールプレーンとやりとりするための Runtime Fabric メッセージブローカー。

443 (v1.8.50 以降)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-router.us-east-1.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io

Runtime Fabric 用の Anypoint Monitoring エージェント。

5044 (レガシー)

TCP (Lumberjack)

  • US コントロールプレーン: dias-ingestor-nginx.prod.cloudhub.io​

  • EU コントロールプレーン: dias-ingestor-nginx.prod-eu.msap.io

Runtime Fabric 用の Anypoint Monitoring エージェント。

Runtime Fabric バージョン 1.8.50 以降では、このポートは厳密には要求されません。このポートは将来廃止される予定です。​

443

HTTPS

anypoint.mulesoft.com

アセットを取得するための Anypoint Platform。

443

HTTPS

kubernetes-charts.storage.googleapis.com

Kubernetes ベースチャートリポジトリ。

443

HTTPS

docker-images-prod.s3.amazonaws.com

Kubernetes ベースチャートリポジトリ。

443

HTTPS

  • US コントロールプレーン: worker-cloud-helm-prod.s3.amazonaws.com​

  • EU コントロールプレーン: worker-cloud-helm-prod-eu-rt.s3.amazonaws.com​、​worker-cloud-helm-prod-eu-rt.s3.eu-central-1.amazonaws.com

Runtime Fabric バージョンリポジトリ。Runtime Fabric インストールでは、インストールおよびアップグレード時にこのリポジトリからのソフトウェアが使用されます。

443

HTTPS

  • US コントロールプレーン: exchange2-asset-manager-kprod.s3.amazonaws.com​

  • EU コントロールプレーン: exchange2-asset-manager-kprod-eu.s3.amazonaws.com​、​exchange2-asset-manager-kprod-eu.s3.eu-central-1.amazonaws.com

アプリケーションアセット用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: exchange-files.anypoint.mulesoft.com​

  • EU コントロールプレーン: exchange-files.eu1.anypoint.mulesoft.com

アプリケーションファイル用の Anypoint Exchange。

443

HTTPS

  • US コントロールプレーン: rtf-runtime-registry.kprod.msap.io​

  • EU コントロールプレーン: rtf-runtime-registry.kprod-eu.msap.io

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: prod-us-east-1-starport-layer-bucket.s3.amazonaws.com​、​prod-us-east-1-starport-layer-bucket.s3.us-east-1.amazonaws.com​

  • EU コントロールプレーン: prod-eu-central-1-starport-layer-bucket.s3.amazonaws.com​、​prod-eu-central-1-starport-layer-bucket.s3.eu-central-1.amazonaws.com

Runtime Fabric Docker イメージの配信。

443

HTTPS

  • US コントロールプレーン: runtime-fabric.s3.amazonaws.com​

  • EU コントロールプレーン: runtime-fabric-eu.s3.amazonaws.com

Runtime Fabric Docker リポジトリ。

443

HTTPS

  • US コントロールプレーン: configuration-resolver.prod.cloudhub.io​

  • EU コントロールプレーン: configuration-resolver.prod-eu.msap.io

Anypoint 設定リゾルバー。
## [](#アウトバウンド接続の確認)アウトバウンド接続の確認 すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。 `rtfctl`​ を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認できます。各ノードで、​[「rtfctl のインストール」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-rtfctl)​の手順に従って ​`rtfctl`​ をインストールします。 必要なアウトバウンド接続を検証するには、クラスターのすべてのコントローラーとワーカーノードで次のコマンドを実行します。 sudo ./rtfctl test outbound-network サンプル出力: \[root@rtf-controller-1 runtimefabric\]# sudo ./rtfctl test outbound-network Using proxy configuration from Runtime Fabric (proxy "", no proxy "") Using 'US' region transport-layer.prod.cloudhub.io:443 ✔ https://anypoint.mulesoft.com ✔ https://worker-cloud-helm-prod.s3.amazonaws.com ✔ https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔ https://ecr.us-east-1.amazonaws.com ✔ https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔ https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔ https://runtime-fabric.s3.amazonaws.com ✔ tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔ アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して、ポートの設定セクションで説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。 ## [](#証明書設定)証明書設定 異なるエンドポイントが相互 TLS 認証を使用して接続を確立できるようにするには、次の証明書を許可するための SSL パススルーを設定する必要があります。
コントロールプレーン 証明書

US コントロールプレーン

transport-layer.prod.cloudhub.io
configuration-resolver.prod.cloudhub.io

EU コントロールプレーン

transport-layer.prod-eu.msap.io
configuration-resolver.prod-eu.msap.io