# mulesoft CloudHub 2.0 (cloudhub-2) - Full Documentation # Anypoint CLI を使用したアプリケーションのデプロイ これらのコマンドを使用して、Cloudhub 2.0 でアプリケーションをデプロイおよび管理します。
コマンド 説明

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

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

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

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

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

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

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

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

仕様のアプリケーションのログを追跡する

## [](#runtime-mgr-application-delete)runtime-mgr:application:delete \> runtime-mgr:application:delete \[flags\] ``​ で指定された実行中のアプリケーションを削除します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-describe)runtime-mgr:application:describe \> runtime-mgr:application:describe \[flags\] ``​ で指定されたアプリケーションに関する情報を表示します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ## [](#runtime-mgr-application-deploy)runtime-mgr:application:deploy \> runtime-mgr:application:deploy \[flags\] ``​ で指定されたアプリケーションを、次のオプションを使用して指定されたデプロイメント対象にデプロイします。
値 説明 例

--artifactId

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

--artifactId mule-test-plugin

--deploymentTargetId

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

--deploymentTargetId 7de39400-a2b3-0a93-b2349-23eacbca9e322

--name

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

--name testcloudhub2app

--runtimeVersion

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

--runtimeVersion 4.4.0

--secureProperty

暗号化されたプロパティを設定します。

--secureProperty secureTestProperty:true​

このコマンドでは、デフォルトの ​`--help`​ フラグ以外に次のフラグも使用できます。
フラグ 説明 例

--assetVersion

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

--assetVersion 2.0.4

--[no-]clustered

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

--no-clustered

--[no-]disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled

--disableAmLogForwarding

--[no-]forwardSslSession

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

--no-forwardSslSession

--groupId

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

--groupId org.mule.test

--[no-]lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled

--no-lastMileSecurity

--[no-]objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled

--no-objectStoreV2

--pathRewrite

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

--pathRewrite /http://localhost:3000

--property

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

--property testproperty:true

--propertiesFile

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

--propertiesFile /Users/mule/Documents/properties.txt

--publicEndpoints

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

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

--replicas

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

--replicas 2

--replicaSize

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

--replicaSize 0.5

--scopeLoggingConfig

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

--scopeLoggingConfig testscope1:WARN,testscope2:DEBUG

--scopeLoggingConfigFile

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

--scopeLoggingConfigFile /Users/mule/Documents/cert.txt

--updateStrategy

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

--updateStrategy recreate

このコマンドには複数オプションのフラグがあります。コマンドで複数オプションのフラグを使用する場合は、フラグの前にパラメーターを置くか、パラメーターの前に ​`-- `​ (2 つのダッシュの後にスペース) を使用します。

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-download-logs)runtime-mgr:application:download-logs \> runtime-mgr:application:download-logs \[flags\] ``​ で指定された仕様から、選択したディレクトリに ​``​ で指定されたアプリケーションのログをダウンロードします。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ## [](#runtime-mgr-application-list)runtime-mgr:application:list \> runtime-mgr:application:list \[flags\] 組織内のすべてのアプリケーションをリストします。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ を受け入れます。 ## [](#runtime-mgr-application-modify)runtime-mgr:application:modify \> runtime-mgr:application:modify \[flags\] ``​ で指定された既存のアプリケーションの設定を更新します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトの ​`--help`​ フラグ以外に次のフラグも使用できます。
フラグ 説明 例

--artifactId

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

--artifactId mule-maven-plugin

--assetVersion

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

--assetVersion 2.0.4

--[no-]clustered

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

--no-clustered

--[no-]disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled

--disableAmLogForwarding

--[no-]forwardSslSession

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

--no-forwardSslSession

--groupId

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

--groupId org.mule.testgroup

--[no-]lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled

--no-lastMileSecurity

--[no-]objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled

--no-objectStoreV2

--pathRewrite

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

--pathRewrite /http://localhost:3000​。

--property

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

--property testproperty:true

--propertiesFile

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

--propertiesFile /Users/mule/Documents/properties.txt

--publicEndpoints

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

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

--replicas

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

--replicas 2

--replicaSize

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

--replicaSize 0.5

--runtimeVersion

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

--runtimeVersion 4.4.0

--secureProperty

暗号化されたプロパティを設定します。

--secureProperty secureTestProperty:true

--scopeLoggingConfig

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

--scopeLoggingConfig testscope1:WARN,testscope2:DEBUG

--scopeLoggingConfigFile

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

--scopeLoggingConfigFile /Users/mule/Documents/cert.txt

--updateStrategy

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

--updateStrategy recreate​

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

--artifactId

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

--artifactId mule-maven-plugin

--assetVersion

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

-assetVersion 2.0.4

--[no-]clustered

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

--no-clustered

--[no-]disableAmLogForwarding

Anypoint Monitoring へのアプリケーションログの転送を無効にします。
デフォルト: enabled

--disableAmLogForwarding

--[no-]forwardSslSession

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

--no-forwardSslSession

--groupId

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

-groupId org.mule.testgroup

--[no-]lastMileSecurity

Last Mile セキュリティを有効にします。
デフォルト: disabled

--no-lastMileSecurity

--[no-]objectStoreV2

Object Store v2 を有効にします。
デフォルト: disabled

--no-objectStoreV2

--pathRewrite

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

--pathRewrite /http://localhost:3000​。

--property

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

--property testproperty:true

--propertiesFile

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

--propertiesFile /Users/mule/Documents/properties.txt

--publicEndpoints

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

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

--replicas

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

--replicas 2

--replicaSize

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

--replicaSize 0.5

--runtimeVersion

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

--runtimeVersion 1.0.1

--scopeLoggingConfig

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

--scopeLoggingConfig testscope1:WARN,testscope2:DEBUG

--scopeLoggingConfigFile

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

--scopeLoggingConfigFile /Users/mule/Documents/cert.txt

--updateStrategy

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

--updateStrategy recreate​

## [](#runtime-mgrapplicationstart)runtime-mgr:application:start \> runtime-mgr:application:start \[flags\] ``​ で指定されたアプリケーションの実行を開始します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ## [](#runtime-mgrapplicationstop)runtime-mgr:application:stop \> runtime-mgr:application:stop \[flags\] ``​ で指定されたアプリケーションの実行を停止します。この ID を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ## [](#runtime-mgrapplicationlogs)runtime-mgr:application:logs \> runtime-mgr:application:logs \[flags\] ``​ で指定された仕様から、​``​ で指定されたアプリケーションのアプリケーションログを追跡します。 ``​ を取得するには、​`runtime-mgr application list`​ コマンドを実行します。 ``​ を取得するには、​`runtime-mgr application describe`​ コマンドを実行します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 # Anypoint 仮想プライベートネットワーク Anypoint VPN (仮想プライベートネットワーク) は、非公開スペースとオンプレミスネットワークの間に安全な接続を作成します。 Anypoint VPN を使用すると、非公開スペースで実行されているアプリケーションが企業ファイアウォールの背後にあるオンプレミスデータセンターのリソースにアクセスできます。 必要であれば、サイト間で複数の VPN を作成できます。
作成できる VPN の数は、アカウントで利用できるネットワーク接続エンタイトルメントの数によって異なります。 自分のアカウントに割り当てられているネットワーク接続エンタイトルメントの数が不明な場合は、MuleSoft アカウント担当者までお問い合わせください。
Anypoint VPN では、非公開スペースと VPN エンドポイント、​_ゲートウェイデバイス_​、ネットワーク内にある物理的なアプライアンスまたはソフトウェアアプライアンスとの間のサイト間でのインターネットプロトコルセキュリティ (IPsec) 接続がサポートされています。 接続の MuleSoft 側は、仮想プライベートゲートウェイ (VGW) の実装となります。 MuleSoft VGW は単一の非公開スペースに関連付けられますが、最大 10 件の VPN 接続をサポートできます。
MuleSoft 実装の機能は、他の VGW 製品とは異なる場合があります。
![IPsec トンネルの概要](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-overview-ipsec.png) ネットワークとの Anypoint VPN 接続を作成するには、​[「外部ネットワークへの接続を作成する」](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#create-connection-to-external-network)​を参照してください。 ## [](#vpn-features)Anypoint VPN の機能 各 Anypoint VPN 接続にはトンネルが 2 つあり、リモートロケーションにある 1 件のパブリック IP アドレスに接続できます。 リモートロケーションで接続するパブリック IP アドレスを 1 件増やすには、2 件の VPN 接続を作成する必要があります。 ルーチンメンテナンスによって VPN 接続の 2 つのトンネルの片方が短時間だけ無効になることがあります。 このときは VPN 接続が他方のトンネルに自動的にフェールオーバーするため、アクセスは中断されません。 このため、エンドポイントで両方のトンネルを設定する必要があります。 トンネルの選択は、VPN エンドポイントの容量とルーティング種別の選択によって決まります。 MuleSoft VGW 実装では、最大 1.25 Gbps のスループットをサポートします。同じ非公開スペースに対する複数の VPN 接続では、1 つの VGW のスループット容量が共有されます。 VPN 接続スループットは、VPN エンドポイントの容量、接続容量、平均パケットサイズ、プロトコル、ゲートウェイ間のネットワークレイテンシーなどの要因に左右されます。 Anypoint VPN は​_高可用性_​もサポートしており、各 Anypoint VPN 接続は 2 つのエンドポイントで構成されているため、接続障害の可能性が軽減されます。 ## [](#vpn-ipsec)IPsec 設定 Anypoint VPN では、以下の IPsec 設定の任意の組み合わせがサポートされています。 - IKE バージョン 1 - IKE バージョン 2 はルートベース VPN のみ - CBC と GCM の AES 128 または 256 ビット暗号化 - SHA または SHA-2 (256、384、512) ハッシュ - Diffie-Hellman フェーズ 1 グループ 2、14 ~ 24 - Diffie-Hellman フェーズ 2 グループ 2、5、14、24 - IKEv1 のタイムアウト: - IKE (フェーズ 1) 有効期間: 28800 秒 (8 時間) - IPsec (フェーズ 2) 有効期間: 3600 秒 (1 時間) - IKEv2 のタイムアウト: - IKE (フェーズ 1) 有効期間: 28000 秒 (7 時間 50 分) - IPsec (フェーズ 2) 有効期間: 3000 秒 (50 分) ## [](#vpn-routing)Anypoint VPN ルーティング Anypoint VPN では、VPN 接続で動的ルーティングと静的ルーティングがサポートされています。 動的ルーティング ユーザーのデバイスがボーダーゲートウェイプロトコル (BGP) を使用して Anypoint VPN へのルートを動的にアドバタイズします。 デバイスがこのプロトコルをサポートする場合は、BGP ルーティングを使用してください。 静的ルーティング Anypoint VPN を介したアクセスを可能にするネットワークのルート (サブネット) を指定する必要があります。 静的 VPN 接続のルートを削除できます。 ### [](#vpn-routing-limitations)Anypoint VPN ルーティングの制限事項 - VPN 接続の数には関係なく、非公開スペースごとに最大 95 件のルートテーブルエントリが許可されます。 この制限を超えないように、ネットワークを統合して接続数を可能な限り少なく抑えてください。 - 優先ルート (非公開ネットワークで使用されるルート) に一致するルートは追加できません。 - 一度に 1 つの接続のみがルートを使用できます。 非ローカル/インターネットゲートウェイ (IGW) ルートをルートテーブルに入力すると、CloudHub 2.0 によって別の接続がそのルートを使用していることが警告されます。 - ルートは既存のルートと重複することはできません。 ルートテーブル内の別のルートと重複するルートを入力すると、警告が表示されます。 ## [](#vpn-limitations)Anypoint VPN の制限事項 Anypoint VPN では、以下の機能と設定はサポートされていません。 - ネットワークアドレス変換 (NAT) - IPv6 - ポリシーベース VPN を使用した IKEv2 - BGP または静的ルーティングでのデフォルトルート (0.0.0.0/0) のアドバタイズ ## [](#vpn_requirements)静的 VPN 接続の要件 静的 VPN 接続を作成するには、ユーザーの VPN エンドポイントで以下が可能である必要があります。 - 事前共有キー (PSK) を使用して IKE セキュリティアソシエーションを確立する - トンネルモードで IPsec セキュリティアソシエーションを確立する - MuleSoft がサポートする IPsec 設定の任意の組み合わせを使用する - 暗号化前に IP パケットを分割する 送信するのに大きすぎるパケットは分割する必要があります。VPN デバイスは、パケットをカプセル化する前に分割できる必要があります。 - トンネルごとの 1 つのセキュリティアソシエーション (SA) ペアの使用 Anypoint VPN では、トンネルごとに一意の 1 組の SA ペアがサポートされます (ペアとは、インバウンドとアウトバウンド接続のペアを意味します)。一部のポリシーベースのデバイスは、各 ACL (アクセスコントロールリスト) エントリに対して SA を作成します。この場合は、ルールを統合してから、不要なトラフィックを除去する必要があります。 - IPsec デッドピア検出 (DPD) の使用 DPD により、デバイスはネットワーク条件の変化をすばやく特定できます。MuleSoft エンドポイントでの DPD は ​`DPD Interval: 10`​ と ​`DPD Retries: 3`​ で有効化できます。 - 非対称ルーティングの許可 非対称ルーティングとは、ルーティングポリシーによってネットワークから非公開スペースに送信されるトラフィックと非公開スペースから返されるトラフィックが別々のトンネルを通るルーティング方式です。MuleSoft VPN エンドポイントは、内部アルゴリズムを使用してトンネルを選択するため、戻りパスは動的に決定されます。デバイスでアクティブ/アクティブトンネル設定を使用している場合は、各 Anypoint VPN 接続で非対称ルーティングを許可する必要があります。 - IPsec の場合、上記のフェーズ 2 Diffie-Hellman グループを使用した Perfect Forward Secrecy (PFS) の有効化 ## [](#動的-vpn-接続の要件)動的 VPN 接続の要件 動的 VPN 接続を作成するには、静的 VPN 接続の要件に加えて、VPN エンドポイントで以下がサポートされている必要があります。 - BGP ピアリングの確立 - ルートベースの VPN の使用 (トンネルを論理インターフェースにバインドする) - IPsec の場合、上記のフェーズ 2 Diffie-Hellman グループを使用した Perfect Forward Secrecy (PFS) の有効化 ## [](#vpn-recommendations)Anypoint VPN の推奨事項 - VPN トンネルに入る TCP パケットの最大セグメントサイズを調整してください。 VPN ヘッダーには追加スペースが必要であり、データで利用できるスペース量が少なくなります。 この影響を抑えるには、エンドポイントを TCP MSS 調整: 1387 バイトで設定します。 - パケットで ​`DF`​ フラグをリセットしてください。 パケットに Don’t Fragment (​`DF`​) フラグが付いていると、パケットの分割が禁止されます。 一部の VPN デバイスでは、​`DF`​ フラグを変更して、必要であればパケットを無条件に分割できます。 利用できる場合は、​`Clear Don’t Fragment (DF) Bit`​ 設定を有効にしてください。 ## [](#vpn-ha)VPN 高可用性 アプリケーションと関連する操作が Anypoint VPN の更新、問題、または個別のカスタマーゲートウェイのエラーの影響を受けないようにするには、高可用性 VPN 接続を実装します。冗長 VPN 接続をセットアップして、別の VPN または接続デバイスが使用できない場合に接続が失われるのを防ぎ、メンテナンスダウンタイムを可能にします。 冗長 VPN は、最初の VPN 設定からいくつかの設定を自動的に継承します。 たとえば、最初の VPN のルーティング種別が動的 (BGP) の場合、冗長 VPN も動的になります。 動的ルーティング用のリモート ASN など、冗長 VPN のその他の設定には最初の VPN の値が含まれていますが、その値を変更できます。 冗長 VPN 接続を設定するには、以下が必要です。 - 異なる公開 IP アドレスを使用する 2 つの VPN エンドポイントをネットワークで使用できるようにする。 各ゲートウェイデバイスが 1 つの VPN をサポートする。 - 非公開スペースに 2 つの VPN 接続を作成する。 ### [](#anypoint-vpn-を使用した高可用性の設定)Anypoint VPN を使用した高可用性の設定 次の例は、1 つの Anypoint VPC と 2 つの VPN 接続を使用した高可用性 VPN トポロジーを示しています。 MuleSoft 仮想プライベートゲートウェイ (VGW) でサポートしている Anypoint VPC 関連付けは 1 つですが、最大 10 個の VPN 接続をサポートしています。 VPN ゲートウェイは同じデータセンター内で見つけることも、異なる物理的な場所で見つけることもできます。 ![VPN 高可用性トポロジー](/mulesoft/current/ja-jp/cloudhub-2/_images/vpn-ha-topology.png) BGP ルーティングを使用して、VPN-1 と VPN-2 経由の同じルートをアドバタイズします。ルーティングプロトコルを使用したパス選択の制御手順については、 [「Anypoint VPN Path Selection using BGP Routing (BGP ルーティングを使用した Anypoint VPN パスの選択)」](https://help.mulesoft.com/s/article/Anypoint-VPN-Path-Selection-using-BGP-Routing)​を参照してください。 このシナリオでは、VPN ゲートウェイは VPN-1 Tunnel-1、VPN-1 Tunnel-2、VPN-2 Tunnel-1、VPN-2 Tunnel-2 の順に優先するように設定されています。 この設定により、VPN の接続で問題が発生した場合に別のトンネル、および別の VPN への自動フェールオーバーが実現されます。これによって Anypoint VPN ソリューションの弾力性と堅牢性が高まります。 高可用性 VPN 接続では、VPN-1 でエラーが発生した場合に備えて冗長性のあるスタンバイ接続として機能するように VPN-2 を確立する静的ルーティングもサポートしています。 ### [](#vpn-フェールオーバーのしくみ)VPN フェールオーバーのしくみ 冗長 VPN へのフェールオーバーは、ルーティング種別によって異なります。 - Dynamic (BGP) (動的 (BGP)) - Static (静的) 動的または BGP VPN のフェールオーバーは自動です。静的 VPN フェールオーバーの場合、ルートを変更して、他の使用可能な VPN に手動でフェールオーバーする必要があります。 ### [](#vpn-とトンネルの状況)VPN とトンネルの状況 作成した新しい VPN 接続は、非公開スペースの ​**\[Connections (接続)\]**​ セクションに表示されます。 インフラストラクチャの作成中は、両方の VPN トンネルには DOWN と最初に表示されます。 設定によっては、正常な動作中にもトンネルに DOWN と表示される場合があります。
状況 トンネル 1/2 説明

Pending

DOWN/DOWN

VPN 接続が作成されたばかりで、アクションはバックグラウンドで待機中です。

VPN を作成してから 10 ~ 15 分は、この状況が表示されることがあります。

Available

DOWN/DOWN

VPN 接続が作成されていますが、リモート側が設定されていないか、またはトラフィックを送信していません。

Available

Up/Up​ または ​Up/Down

VPN 接続が作成され、リモート側が接続を正常に確立しました。

トンネルは、ルーティング設定と VPN デバイス種別により、アクティブ/アクティブモードまたはアクティブ/パッシブモードで動作します。

Failed

DOWN/DOWN

VPN 接続が作成されませんでした。

VPN を削除してやり直してください。この障害が再発する場合は、MuleSoft サポートにお問い合わせください。

## [](#関連情報)関連情報 - [非公開スペースの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure) - [非公開ネットワークリージョン](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#private-network-region) - [非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules) - [動的 VPN 接続の要件](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#dynamic-vpn-routing) - [静的 VPN 接続の要件](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#static-vpn-routing) - [サポートされるゲートウェイデバイス](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#supported-gateway-devices) # Application Manager API を使用した TCP を使用するアプリケーションのデプロイ HTTP または HTTPS 以外のプロトコルを設定するには、まず非公開スペースの TCP トラフィックを許可する TCP インバウンドファイアウォールルールを設定します。その後、 [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/pages/home/)​ を使用して TCP を使用するアプリケーションをデプロイできます。TCP インバウンドファイアウォールルールでは、カスタムエンドポイントはサポートされていません。 TCP を使用してファイアウォールルールを設定するには、​[「ファイアウォールルールを設定する」](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules#configure-firewall-rules)​の手順に従って TCP を選択してください。 ## [](#始める前に)始める前に 非公開スペースでファイアウォールの次のネットワークレベルのルールを設定します。 - イングレスルール: ポート範囲 ​`30500 ~ 32500`​ で ​`[Allow TCP (TCP を許可)]`​ を設定します。 - エグレスルール: `[Allow HTTP/HTTPS (HTTP/HTTP を許可)]`​ を ​`[Any Destination (任意の宛先)]`​ に設定します。 アウトバウンドトラフィックを制限する必要がある場合、ポート ​``​ で ​`[Allow TCP (TCP を許可)]`​ を ​`[Any Destination (任意の宛先)]`​ に設定します。 ## [](#アプリケーションに使用可能なポートの確認)アプリケーションに使用可能なポートの確認 TCP のポート範囲は 30500 ~ 32500 です。ポートが使用できることを確認するには、使用可能なポートのリストを返す [CloudHub 2.0 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/)​ を使用します。 次の例は、使用可能なポートを確認するために使用した場合の API 要求と応答を示しています。 要求: ```json GET https:/anypoint.mulesoft.com/runtimefabric/api/organizations/{organizationId}/privatespaces/{privatespaceId}/ports?available=true&count=10 ``` 要求の ​`available`​ パラメーターで、応答の未使用ポートを指定できます。 `count`​ パラメーターでポートの数 (1 ~ 10) を指定できます。実際に使用可能なポートの数によって最終的な結果は制限されます。 応答: ```json { "ports": [ 30500, 30501, 30502, 30503, 30504, 30511, 30512, 30513, 30514, 30515 ] } ``` ## [](#application-manager-api-を使用したアプリケーションのデプロイ)Application Manager API を使用したアプリケーションのデプロイ [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/minor/4.0/console/method/%231158/)​ で、​`deploymentSettings`​ の ​`tcp`​ セクションを使用して TCP ポートをマップし、アプリケーションをデプロイします。マッピングでは、外部ポートを使用して ​`portNumber`​ とアプリケーションレベルで定義されたポート ​`applicationPortNumber`​ を公開します。アプリケーションごとに最大 10 個のポートを設定できます。 次の例は、TCP ポートマッピングを使用して新しいアプリケーションをデプロイする要求を示しています。 ```json POST https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{organizationId}/environments/{environmentId}/deployments { "name": "logs-app-uc01", "labels": [ "beta" ], "target": { "provider": "MC", "targetId": "cfe2157f-438b-4fb8-81fe-13ec89c55545", "deploymentSettings": { "clustered": false, "enforceDeployingReplicasAcrossNodes": false, //------------------------------------NEW------------------------------------- "tcp": { "inbound": { "ports": [ { "portNumber": 30500, "applicationPortNumber": 9000 }, { "portNumber": 30501, "applicationPortNumber": 9001 }, { "portNumber": 30502, "applicationPortNumber": 9002 }, ] } }, //------------------------------------NEW------------------------------------- "jvm": {}, "runtimeVersion": "4.4.0:20220523-1", "updateStrategy": "rolling", "disableAmLogForwarding": false, "generateDefaultPublicUrl": true }, "replicas": 1 }, "application": { "ref": { "groupId": "66310c16-bce5-43c4-b978-5945ed2f99c5", "artifactId": "app-with-40-schedulers", "version": "1.0.5", "packaging": "jar" }, "assets": [], "desiredState": "STARTED", "configuration": { "mule.agent.application.properties.service": { "applicationName": "logs-app-uc01", "properties": {}, "secureProperties": {} }, "mule.agent.logging.service": { "artifactName": "logs-app-uc01", "scopeLoggingConfigurations": [] } }, "integrations": { "services": { "objectStoreV2": { "enabled": false } } }, "vCores": "0.05" } } ``` 使用できないポートが含まれているデプロイメントは失敗します。成功したデプロイメントでは新たにマップされたポートを使用しており、これらのポートは使用できなくなります。アプリケーションが削除されると、ポートは再び使用可能になります。 ## [](#application-manager-api-を使用したアプリケーションの更新)Application Manager API を使用したアプリケーションの更新 [Application Manager API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/amc-application-manager/minor/4.0/console/method/%231158/)​ を使用して、​`deploymentSettings`​ の ​`tcp`​ マッピングを変更して TCP ポートを更新してからアプリケーションをデプロイします。 次の例は、新しい TCP マッピングを使用して既存のアプリケーションとその本文を更新する要求を示しています。 ```json PATCH https://anypoint.mulesoft.com/amc/adam/api/organizations/{organizationId}/environments/{environmentId}/deployments/{deploymentId} { "id": "id", "target": { "provider": "MC", "targetId": "873a9879-cca7-4211-b90e-826e98123929", "deploymentSettings": { "tcp": { "inbound": { "ports": [ { "portNumber": 30507, "applicationPortNumber": 9007 }, { "portNumber": 30508, "applicationPortNumber": 9008 }, { "portNumber": 30509, "applicationPortNumber": 9009 } ] } } } } } ``` 使用できないポートが含まれている更新は失敗します。成功したデプロイメントでは新たにマップされたポートを使用しており、これらのポートは使用できなくなります。新しいマッピングで置き換えたポートは使用できるようになります。 ## [](#tcp-アプリケーションへのアクセス)TCP アプリケーションへのアクセス - VPN または移行ゲートウェイを使用して非公開スペース内でアプリケーションにアクセスできます。アプリケーションはワーカーノードで実行されるため、インターネットを介して直接アクセスすることはできません。 TCP エンドポイントでは、ワイルドカードドメインが使用されます。アプリケーション名またはプレフィックスは無関係です。エンドポイント ​`*...tcp.cloudhub.io:`​ でアプリケーションにアクセスできます。 URL の例としては ​`mllp-app-2-mpskt5.q8b5lv.usa-e2.tcp.cloudhub.io:30500`​ のようになります。 - `corvette-azeiuc.internal-yvs7m6.usa-w1.tcp.cloudhub.io`​ のような TCP URL への直接接続を確立することはできません。 TCP URL 形式は {application-url}.{environment}.tcp.cloudhub.io:{port} のような構造になります。CloudHub 2.0 では TCP アプリケーションの内部エンドポイントがサポートされていないため、「internal-」を {environment} に追加することはできません。 # CloudHub 1.0 ユーザー向けの CloudHub 2.0 CloudHub 2.0 の改善により、CloudHub 1.0 よりも学習、開発、管理が簡単になりました。次の利点があります。 - 複数のレプリカを使用したデプロイメント用のシームレスな Mule クラスタリング - リソース消費を調整し、アプリケーションの可用性を確保し、拡張性を実現するコンテナベースのアプリケーションデプロイメント - 高度な設定やインフラストラクチャのメンテナンスを必要としない共有スペースへのアプリケーションのデプロイ - リソースアクセス制御用の Amazon Web Services (AWS) サービス - より詳細な vCore 割り当てオプション - アウトバウンドファイアウォールルールの設定 - イングレスセルフサービスログ CloudHub 2.0 機能の完全なリストについては、​[「CloudHub 2.0 機能」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-features)​を参照してください。 ## [](#cloudhub-1-0-から-cloudhub-2-0-への技術的機能強化)CloudHub 1.0 から CloudHub 2.0 への技術的機能強化 CloudHub 1.0 でも使用可能な機能に対して次の改善が行われました。 - CloudHub 2.0 で追加された断片的 vCore の提供により、リソースの使用量を削減するために同じアプリケーションへの複数のリスナーのバンドルが不要になる可能性があります。 - CloudHub 2.0 では、非公開スペースは CloudHub 1.0 から改善された VPC として機能します。非公開スペース内のアプリケーションに非公開ネットワークを自動的に割り当てることができます。トラフィックに対応するために自動スケーリングを使用する非公開イングレスロードバランサーを設定することもできます。 - デフォルトで、VPN により高可用性が可能になります。 - アプリケーションには、デフォルトで​[エンドポイントと内部エンドポイント](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths)​が含まれるようになりました。複数のエンドポイントを設定することもできます。Runtime Manager でエンドポイントアドレスにアクセスできます。 - イングレスレイヤーの TLS コンテキストとトラストストアのインプレース編集および更新を実行できます。 - CloudHub 1.0 では、アプリケーション名はコントロールプレーンごとに一意である必要がありました。CloudHub 2.0 では、アプリケーション名は非公開スペースごとに一意である必要があります。 - カスタム log4j.xml は、外部ログコレクターへの​[ログのストリーミング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-integrate-log-system)​の有効化がデフォルトでサポートされています。この機能を有効または無効にするためにサポートに問い合わせる必要はなくなりました。 - Runtime Manager を使用してログのストリーミングを無効にできます。この機能を有効または無効にするためにサポートに問い合わせる必要はなくなりました。 - 専用ロードバランサーとイングレスのセルフサービスログは、非公開スペースを介して使用できます。Titanium ユーザーは、Anypoint Monitoring からログをダウンロードすることもできます。 - ポート 80 と 443 を使用すると、非公開スペース内のアプリケーションは内部エンドポイント経由で内部ロードバランサーを使用して通信できます。これはアプリケーションプロトコルによって異なります。 ## [](#考慮事項と制限事項)考慮事項と制限事項 CloudHub 2.0 には CloudHub 1.0 からの多数の改善点がありますが、組織で切り替える前に次の微妙な違いを考慮する必要があります。 ### [](#インフラストラクチャの考慮事項)インフラストラクチャの考慮事項 CloudHub 2.0 インフラストラクチャの動作は、次の点で CloudHub 1.0 とは異なります。 - CloudHub 1.0 の VPC ピアリングおよび直接接続は、CloudHub 2.0 で廃止されました。トランジットゲートウェイアタッチメントを使用できるようになりました。また、トランジットゲートウェイがアタッチされている非公開スペースを削除すると、トランジットゲートウェイは保持され、別の非公開スペースに再度アタッチできます。 - CloudHub 1.0 の VPC とは異なり、Sandbox や本番などの環境の種別のみに基づいて、非公開スペースを複数の環境に関連付けることができます。非公開スペースを共有する環境種別と個々のビジネスグループを選択できるようになりました。 - リージョン間でアプリケーションを移動するには、アプリケーションを別のリージョンの別の共有スペースまたは非公開スペースに再デプロイする必要があります。一度デプロイしたアプリケーションを別のリージョンに移動することはできません。 - HTTP および HTTPS トラフィックはポート 8081 を使用します。 - CloudHub 1.0 VPC と CloudHub 2.0 非公開スペース間の VPN 接続を作成することはできません。 CloudHub 2.0 は、CloudHub 1.0 がサポートする次のインフラストラクチャ機能をサポートしていません。 - [\[Get from sandbox (Sandbox から取得)](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#copy-an-application-from-sandbox-to-production.adoc) 機能\] - インサイト。代わりに ​[Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/)​ を使用します。 ### [](#アプリケーションの考慮事項)アプリケーションの考慮事項 CloudHub 2.0 アプリケーションの動作は、次の点で CloudHub 1.0 とは異なります。 - Mule 4.3.0 以降のバージョンのみがサポートされています。 - アプリケーションのバーストは、非公開スペースにデプロイされた他のアプリケーションのリソース使用量に依存し、保証されません。 - セキュアアプリケーションプロパティは、暗号化された非公開コンテナに保存され、作成後にユーザーや MuleSoft スタッフが直接表示することはできません。セキュアプロパティには、アプリケーション自体からのみアクセスできます。プロパティはいつでも新しい値に上書きできます。 - 永続的なキューおよびその他のキュー管理には、​[Anypoint MQ](https://docs.mulesoft.com/jp/mq/)​ を使用します。永続的なキューはサポートされていません。 - HTTP、HTTPS、および TCP インバウンドプロトコルはサポートされていません。TCP または HTTP ベースではないインバウンドプロトコルはサポートされていません。 - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/alerts)​ では、アプリケーションのアラートを個別に設定する必要があります。すべてのアプリケーションに対するアラートの同時設定はサポートされていません。 - 同じ vCore サイズの CloudHub アプリケーションワーカーと CloudHub 2.0 アプリケーションレプリカはパフォーマンスメトリクスが異なる場合があり、比較できません。 - CloudHub アプリケーションの猶予期間は 2 分で、CloudHub 2.0 アプリケーションの猶予期間は 5 分です。詳細は、​[「猶予期間」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy#grace-period)​を参照してください。 CloudHub 2.0 は、CloudHub 1.0 がサポートする次のアプリケーション機能をサポートしていません。 - 4.3.0 より前の Mule バージョン - JVM パラメーターの上書き - カスタムトラストストアによるデフォルトの JVM トラストストアの上書き - カスタム通知の作成 - CloudHub Connector の使用 - TLS 1.0。代わりに 1.2 または 1.3 を使用します。 ## [](#関連情報)関連情報 - [CloudHub 2.0 機能](https://docs.mulesoft.com/cloudhub-2/ch2-features) - [エンドポイント](https://docs.mulesoft.com/cloudhub-2/ch2-config-endpoints-paths) - [非公開スペース](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/) - [Anypoint MQ](https://docs.mulesoft.com/jp/mq/) - [Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/) # CloudHub 2.0 Release Notes - [CloudHub 2.0 Feature Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-release-notes) - [CloudHub 2.0 Runtime Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes) - [Anypoint VPN Updates Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub/anypoint-vpn-release-notes) ## [](#see-also)See Also - [CloudHub 2.0 Documentation](https://docs.mulesoft.com/cloudhub-2/) - [Known Issues](https://help.salesforce.com/s/issues) # CloudHub 2.0 アーキテクチャ CloudHub 2.0 のセキュリティや可用性を理解するには、CloudHub 2.0 の背後にあるアーキテクチャを理解する必要があります。 CloudHub 2.0 アーキテクチャは、Anypoint Platform サービスと共有グローバルリージョンの 2 つの主要コンポーネントで構成されます。 これらの 2 つのコンポーネントは、それらのコンポーネントへのアクセスに使用する Anypoint Runtime Manager と連携して、インテグレーションアプリケーションを実行します。 ![CloudHub 2.0 アーキテクチャと 4 つのコールアウト](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-architecture.png)

1 インテグレーションアプリケーション

ビジネスのインテグレーションロジックを実行するために作成して CloudHub 2.0 にデプロイするアプリケーション

2 Runtime Manager

インテグレーションのデプロイや監視、ランタイムプレーンのセットアップを行うことができるユーザーインターフェース

3 プラットフォームサービス

アラート管理、ログ管理、アカウント管理、非公開スペース/セキュアデータゲートウェイ、負荷分散を提供する Anypoint Monitoring が含まれる共有 CloudHub 2.0 プラットフォームサービスと API

4 CloudHub 2.0

インテグレーションアプリケーションを実行する​レプリカ​ (Mule インスタンス) の拡張性の高いクラウド

デフォルトの (米国でホストされる) コントロールプレーンの status.mulesoft.com​ および EU コントロールプレーンの eu1-status.mulesoft.com​ では、Runtime Manager、プラットフォームサービス、CloudHub 2.0 のライブ状況と詳細なサービス履歴を表示できます。
## [](#integrations-apps)インテグレーションアプリケーション インテグレーションアプリケーションは、Anypoint Studio を使用して作成したインテグレーションです。 これらのアプリケーションは、Salesforce からデータベースへのデータの同期、SOAP または REST API のパブリッシュ、ビジネスプロセスの複雑なオーケストレーションの作成など、あらゆる作業を実行できます。 インテグレーションアプリケーションの作成やデプロイについての詳細は、​[CloudHub 2.0 の概要](https://docs.mulesoft.com/jp/cloudhub-2/) and [CloudHub 2.0 へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy)​を参照してください。 ## [](#runtime-manager)Runtime Manager Runtime Manager は、 [Anypoint Platform](https://anypoint.mulesoft.com)​ に統合されています。 実行時にインテグレーションアプリケーションをデプロイおよび管理するには、Anypoint Platform ログイン情報を使用してサインインします。 コンソールには、プラットフォームサービスの有益な監視情報が表示されます。また、コンソールはアプリケーションレベルとアカウントレベルの両方の管理に対応する包括的なダッシュボードとしても機能します。 システム管理者アカウントを所持しているユーザーは、Anypoint Platform を使用して、組織の他のユーザーを追加および管理したり、ユーザーロールを定義したり、Sandbox 環境を作成および管理したりできます。 詳細は、[アクセス管理について](https://docs.mulesoft.com/jp/access-management/)を参照してください。 ## [](#platform-services)プラットフォームサービス プラットフォームサービスは、プラットフォームのあらゆる側面の調整を担当します。 アプリケーションのデプロイメントの調整、インテグレーションの監視、分析データの提供、アプリケーションデータの保存、スケジュール済みジョブの実行などを行います。 また、これらのサービスの多くは、CloudHub 2.0 REST API を介して公開されています。 ## [](#cloudhub-2-replicas)CloudHub 2.0 レプリカ _レプリカ_​は、CloudHub 2.0 のインテグレーションアプリケーションを実行する Mule Runtime Engine の専用のインスタンスです。 レプリカには、次の特性があります。 **容量** 各レプリカには、データを処理するための特定の容量があります。 レプリカのサイズは、アプリケーションの設定時に選択します。 **分離** 各レプリカは、ほかのすべてのアプリケーションから隔離されたコンテナで実行されます。 **管理** 各レプリカは個別にデプロイおよび監視されます。 **地域** 各レプリカは、特定のグローバルリージョン (米国、EU、アジア太平洋など) で実行されます。 レプリカのメモリ容量と処理能力は、アプリケーションレベルでの設定方法によって異なります。 各レプリカサイズの計算容量、メモリ容量、およびストレージ容量は異なります。 使用可能ないずれかの vCore サイズを選択して、レプリカを垂直方向にスケールできます。
vCore サイズ メモリ合計 ヒープメモリ ストレージ

0.1

1.2 GB

480 MB

8 GB

0.2

2 GB

1 GB

8 GB

0.5

2.6 GB

1.3 GB

10 GB

1

4 GB

2 GB

12 GB

1.5

6 GB

3 GB

20 GB

2

8 GB

4 GB

20 GB

2.5

9.5 GB

4.75 GB

20 GB

3

11 GB

5.5 GB

20 GB

3.5

13 GB

6.5 GB

20 GB

4

15 GB

7.5 GB

20 GB

1 vCore 未満のレプリカ: - 小さいワークロードのアプリケーションで CPU と I/O が制限される - 短期間、より高い CPU 速度に上げることができる この機能は、アプリケーションの起動時間の向上に役立つほか、まれに発生する大きなワークロードの処理に役立ちます。アプリケーションのバーストは、ノードのリソースの可用性に依存し、発生は保証されません。一貫したパフォーマンスが必要な場合は、vCore の多いレプリカを使用してください。 1 つ以上の vCore のレプリカは、パフォーマンスが一貫します。 各レプリカには、システムとアプリケーションの両方のストレージで使用する最小限の 8 GB のストレージがあります。 アプリケーションでより多くのストレージが必要な場合 (冗長ログなど) は、2 以上の vCore のレプリカを使用して、アプリケーションが ​`/tmp`​ の追加のストレージにアクセスできるようにしてください。 すべての実行中のアプリケーションがレプリカの使用量に含まれます。停止したアプリケーションは含まれません。 アプリケーションで、使用可能な量より多くの vCore を必要とする場合、CloudHub 2.0 ではアプリケーションを作成することはできますが、追加の vCore が使用可能になるまでアプリケーションを開始できません。 vCore の割り当てを増やすには、アプリケーションを停止または削除するか、アカウントマネージャーに連絡してサブスクリプションの vCore の割り当てを増やすよう依頼してください。 CloudHub 2.0 にデプロイされたアプリケーションのメタ領域の制限は、レプリカサイズに関係なく現在のところ 256 MB となっています。 メタ領域の初期サイズは 128 MB で、メタ領域がこのしきい値に達すると、メタ領域のガベージコレクションが開始されます。 永続的なキューに複数のレプリカを追加することで、アプリケーションを水平方向にスケールできます。 [「レプリカのスケールアウト」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering#replica-scale-out)​を参照してください。 CloudHub 2.0 は、レプリカを監視して正常に動作していることを確認し、必要に応じてアプリケーションを自動的に再起動します。 ## [](#anypoint-インテグレーションユーザーのための-cloudhub-2-0-のリソーシング)Anypoint インテグレーションユーザーのための CloudHub 2.0 のリソーシング 組織で Anypoint Integration Starter パッケージまたは Anypoint Integration Advanced パッケージを使用している場合、CloudHub 2.0 はアプリケーションデプロイメントのためにレプリカサイズ設定を使用します。アプリケーションのプロファイルまたはサイズに基づいて次のレプリカサイズの中から選択し、vCore に関連して同等のものを表示できます。
製品 同等の vCore サイズ メモリ合計 ヒープメモリ ストレージ

mule.nano

0.05

1 GB

0.5 GB

8 GB

mule.micro

0.1

1 GB

0.5 GB

8 GB

mule.micro.mem

0.1

2 GB

1 GB

8 GB

mule.small

0.2

2 GB

1 GB

8 GB

mule.medium

0.5

3 GB

1.5 GB

10 GB

mule.medium.mem

0.5

5 GB

2.5 GB

10 GB

mule.large

1

4 GB

2 GB

12 GB

mule.large.mem

1

8 GB

4 GB

12 GB

mule.xlarge

2

7 GB

3.5 GB

20 GB

mule.xlarge.mem

2

12 GB

6 GB

20 GB

mule.2xlarge.mem

4

15 GB

7.5 GB

20 GB

サフィックス ​`.mem`​ が付いたレプリカサイズは、同じ計算を使用するメモリ負荷の高いオプションです。 毎月のパッチサイクル中に、アプリケーションは自動的に同等のレプリカサイズに移行されます。Runtime Manager UI または Mule Maven プラグインを使用してアプリケーションをデプロイできます。​`target.deploymentSettings`​ の ​`instanceType`​ という新しい項目を活用して、Application Manager Experience API を使用することもできます。詳細は、[API コミュニティマネージャー](https://docs.mulesoft.com/jp/api-community-manager/)を参照してください。 ## [](#shared-global-regions)共有グローバルリージョン CloudHub 2.0 は、世界のさまざまなリージョン (北米、南米、欧州、アジア太平洋) でアプリケーションをデプロイする機能を提供しています。 このグローバルな分散により、各自のサービスに最も近い場所でインテグレーションをホストできるため、レイテンシーが減少します。 また、EU データ保護指令などの地域の法律に準拠することもできます。 US コントロールプレーンと MuleSoft Government Cloud コントロールプレーンの場合、MuleSoft では米国で管理コンソールとプラットフォームサービスをホストします。 EU クラウドコントロールプレーンの場合、MuleSoft ではこれらのサービスをヨーロッパでホストします。 アプリケーションをデプロイするリージョンによって、アプリケーションについて指定されるドメインが決まります。 CloudHub 2.0 で要求のルーティングに使用されるロードバランサーは、アプリケーションと同じリージョンに存在します。 ### [](#regions-and-dns-records)ランタイムプレーンリージョンおよび DNS レコード アプリケーションをどのリージョンにデプロイするかに応じて、インテグレーションの DNS レコードとロードバランサーが変わる場合があります。 各リージョンでアプリケーションがどの DNS レコードを使用できるかについて次の表にまとめました。
Region Name (リージョン名) リージョン 対象 ID DNS レコードの例 対象名

US クラウド: ランタイムプレーンリージョン

米国東部 (北バージニア)

usa-e1

cloudhub-us-east-1

myapp-​uniq-id​.shard.usa-e1.cloudhub.io

Cloudhub-US-East-1

米国東部 (オハイオ)

usa-e2

cloudhub-us-east-2

myapp-​uniq-id​.shard.usa-e2.cloudhub.io

Cloudhub-US-East-2

米国西部 (北カリフォルニア)

usa-w1

cloudhub-us-west-1

myapp-​uniq-id​.shard.usa-w1.cloudhub.io

Cloudhub-US-West-1

米国西部 (オレゴン)

usa-w2

cloudhub-us-west-2

myapp-​uniq-id​.shard.usa-w2.cloudhub.io

Cloudhub-US-West-2

カナダ (中央部)

can-c1

cloudhub-ca-central-1

myapp-​uniq-id​.shard.can-c1.cloudhub.io

Cloudhub-CA-Central-1

南米 (サンパウロ)

bra-s1

cloudhub-sa-east-1

myapp-​uniq-id​.shard.bra-s1.cloudhub.io

Cloudhub-SA-East-1

アジア太平洋 (シンガポール)

sgp-s1

cloudhub-ap-southeast-1

myapp-​uniq-id​.shard.sgp-s1.cloudhub.io

Cloudhub-AP-Southeast-1

アジア太平洋 (シドニー)

aus-s1

cloudhub-ap-southeast-2

myapp-​uniq-id​.shard.aus-s1.cloudhub.io

Cloudhub-AP-Southeast-2

アジア太平洋 (東京)

jpn-e1

cloudhub-ap-northeast-1

myapp-​uniq-id​.shard.jpn-e1.cloudhub.io

Cloudhub-AP-Northeast-1

EU (アイルランド)

irl-e1

cloudhub-eu-west-1

myapp-​uniq-id​.shard.irl-e1.cloudhub.io

Cloudhub-EU-West-1

EU (フランクフルト)

deu-c1

cloudhub-eu-central-1

myapp-​uniq-id​.shard.deu-c1.cloudhub.io

Cloudhub-EU-Central-1

EU (ロンドン)

gbr-e1

cloudhub-eu-west-2

myapp-​uniq-id​.shard.gbr-e1.cloudhub.io

Cloudhub-EU-West-2​

EU クラウド: ランタイムプレーンリージョン

EU (アイルランド)

irl-e1.eu1

cloudhub-eu-west-1

myapp-​uniq-id​.shard.irl-e1.eu1.cloudhub.io

Cloudhub-EU-West-1

EU (フランクフルト)

deu-c1.eu1

cloudhub-eu-central-1

myapp-​uniq-id​.shard.deu-c1.eu1.cloudhub.io

Cloudhub-EU-Central-1​

カナダクラウド: ランタイムプレーンリージョン

カナダ (中央部)

can-c1

cloudhub-ca-central-1

myapp-uniq-id.can-c1.ca1.cloudhub.io

Cloudhub-CA-Central-1​

日本クラウド: ランタイムプレーンリージョン

アジア太平洋 (東京)

jpn-e1

cloudhub-ap-northeast-1

myapp-uniq-id.jpn-e1.jp1.cloudhub.io

Cloudhub-AP-Northeast-1

たとえば、​`myapp`​ という名前のアプリケーションをカナダ (中央部) にデプロイする場合、アプリケーションにアクセスするために使用されるドメインは ​`myapp-​_uniq-id_​._shard_.can-c1.cloudhub.io`​ になります。 CloudHub 2.0 バックエンドサービスによって、次の値が決定されます。 `uniq-id`​ 一意性を確保するためにアプリケーション名に追加される 6 桁の値 (​`a9cdqr`​ など)。 `shard`​ アプリケーションがデプロイされる非公開スペースに関連付けられた 6 桁の値 (​`q9opcf`​ など)。 アプリケーションがデプロイされる共有スペースに関連付けられた 6 桁の値とそれに続くハイフン (​`-`​) と数値 (​`bsb3v6-2`​ など)。 CloudHub 2.0 は、各非公開スペースに ​`shard`​ の値を割り当てます。 共有スペースにデプロイされたアプリケーションの場合、各リージョンに複数の ​`shard`​ 値がある可能性があります。アプリケーションが停止または再起動されても、​`shard`​ 値は変更されません。ただし、共有スペースでアプリケーションが削除されて再デプロイされると、​`shard`​ 値は変更される場合があります。 DNS レコードは各コントロールプレーンで一意です。 EU コントロールプレーンは、US コントロールプレーンがサポートするリージョンの一部をサポートしますが、DNS レコードは異なります。 EU コントロールプレーンについての詳細は、[EU コントロールプレーンについて](https://docs.mulesoft.com/jp/eu-control-plane/)を参照してください。 たとえば、US コントロールプレーンを使用していてそれをアイルランドリージョンにデプロイした場合、外部および内部の IP アドレスの DNS レコードは ​`myapp-​_uniq-id_​._shard_.irl-e1.cloudhub.io`​ および ​`myapp-​_uniq-id_​.internal-​_shard_​.irl-e1.cloudhub.io`​ になります。 ## [](#マルチテナンシー)マルチテナンシー サービスに応じてさまざまなレベルのセキュリティと分離が必要になるため、プラットフォームでは 3 つの異なるレベルのマルチテナンシーが提供されます。 - 共有グローバルリージョンは、仮想マシン (VM) のマルチテナントクラウドです。 これらの VM は、他に影響を与えずにインテグレーションでカスタムコードを実行するために必要なセキュリティと分離を提供します。 - 必要に応じて、アプリケーションを実行する CloudHub 2.0 の仮想、非公開、および分離領域である、シングルテナントの​_非公開スペース_​を作成できます。 詳細は、[非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about)を参照してください。 - 管理コンソールとプラットフォームサービスは、すべてのテナントで同じ Web UI、監視サービス、ロードバランサーを共有する、​_「すべてを共有する」_​アーキテクチャで構成されています。 これらのサービスは、データを処理したり送信したりすることはありません。 ## [](#可用性と拡張性)可用性と拡張性 CloudHub 2.0 は、冗長性、インテリジェントな回復、ダウンタイムなしの更新などにより、可用性と拡張性が高くなるように設計されています。 また、​[クラスタリング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​を使用してスケーリングと信頼性の向上を実現することもできます。 ### [](#冗長性のあるプラットフォーム)冗長性のあるプラットフォーム CloudHub 2.0 のすべてのプラットフォームサービス (負荷分散や API レイヤーなど) には 1 つ以上の冗長性レイヤーが組み込まれており常に 2 つ以上のデータセンターで使用できます。 どのデータセンターも 60 マイル以上離れています。 この冗長性により、1 つのデータセンターが停止しても、プラットフォームを引き続き使用できます。 ### [](#インテリジェントな回復)インテリジェントな回復 CloudHub 2.0 は、レプリカの問題を監視し、問題から回復する自己回復メカニズムを提供します。 基盤となるハードウェアに障害が発生すると、プラットフォームによって自動的にアプリケーションが新しいレプリカに移行されます。 アプリケーションがクラッシュすると、カスタムコードの問題が原因でも、基盤となるスタックのバグが原因でも、プラットフォームでクラッシュを認識し、自動的にレプリカを再デプロイできます。 ### [](#ダウンタイムなしの更新)ダウンタイムなしの更新 CloudHub 2.0 では、アプリケーションを実行時に更新できるため、HTTP API のエンドユーザーのダウンタイムはありません。 アプリケーションでローリング更新デプロイメントモデルを使用している場合、CloudHub 2.0 は、アプリケーションの更新がデプロイメントされている間、アプリケーションの古いバージョンを実行し続けます。 ドメインは、新しくアップロードされたバージョンが完全に開始されるまで古いバージョンのアプリケーションを参照します。 これにより、新しいバージョンのアプリケーションを開始している間も古いアプリケーションからの要求を引き続き処理できます。
ローリング更新デプロイメントモデルを使用しているアプリケーションでは、まれに長い処理中の要求が猶予期間中に完了しないことがあります。その場合、アプリケーションの古いインスタンスをアップグレード中に再起動する必要があるため、ダウンタイムがゼロであることは保証されません。
### [](#クラスタリング)クラスタリング クラスタリングを使用すると、CloudHub 2.0 のアプリケーションで拡張性、ワークロードの分散、信頼性の向上を実現できます。 これらの機能は、拡張性の高い負荷分散サービスとレプリカのスケールアウト機能によって提供されます。 詳細は、[クラスタリング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)を参照してください。 #### [](#スケールアウトとデータセンターの冗長性)スケールアウトとデータセンターの冗長性 [クラスタリング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​を使用すると、複数のレプリカをアプリケーションに追加して、水平方向にスケールできます。 CloudHub は、自動的に同じアプリケーションで複数のレプリカを 2 つ以上のデータセンターで分散し、最大限の信頼性を確保します。 アプリケーションを 2 つ以上のレプリカにデプロイすると、HTTP 負荷分散サービスはこれらのレプリカで要求を分散します。これにより、サービスを水平方向にスケールできます。 CloudHub は、ラウンドロビンベースで要求を分散します。 ## [](#アプリケーション監視と自動再起動)アプリケーション監視と自動再起動 CloudHub 2.0 はすべてのアプリケーションを監視し、必要に応じて自動的に再起動するため、ユーザーが介入しなくてもアプリケーションが回復されます。 CloudHub 2.0 は、アプリケーションが再起動中であることを知らせる通知を表示し、その後で再起動の成功または失敗を報告する通知を表示します。 ログに再起動プロシージャーの詳細が表示されます。 アプリケーションが応答しなくなった場合に、アラートと診断情報を受信することもできます。詳細は、[アプリケーションアラートの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-app-alerts)を参照してください。 ## [](#セキュリティ)セキュリティ CloudHub 2.0 アーキテクチャは、インテグレーションのセキュアなプラットフォームを提供します。 CloudHub 2.0 は、ペイロードデータの検査や保存、または直接のやりとりを行いません。 CloudHub レプリカは、各アプリケーションに独自のコンテナを提供することで、データの転送および処理に対応するセキュアな機能を提供します。 これにより、ペイロードのセキュリティを確保するためのテナント間の完全な分離と、他のテナントのコードからの隔離が実現します。 CloudHub 2.0 は、CloudHub レプリカから監視データ、分析データ、ログデータを収集したり、ユーザーの代わりにアクションを実行したりできます。 プラットフォームサービスと CloudHub 間のすべての通信は、SSL とクライアント証明書認証を使用して保護されるため、認証されていないパーティはデータを読み取ることができず、不正なアクションを開始できません。 [アプリケーションのプロパティ値を保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props)​することもできます。 保護されたプロパティ値は、どのユーザーも参照したり取得したりできません。 これらの保護されたアプリケーション値は暗号化され、Anypoint Security シークレットマネージャーに保存されます。その後、ユーザー組織ごとに暗号化されます。 MuleSoft セキュリティについての詳細は、 [「Anypoint Cloud Security & Compliance (Anypoint クラウドセキュリティおよびコンプライアンス)」ホワイトペーパー](https://mulesoft.com/downloads/whitepapers/security-whitepaper.pdf)​を参照してください。 ## [](#関連情報)関連情報 - [CloudHub 2.0 にデプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-apps) - [CloudHub 2.0 にデプロイされたアプリケーションの監視](https://docs.mulesoft.com/jp/cloudhub-2/ch2-monitor-apps) - [アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props) - [アプリケーションアラートの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-app-alerts) - [status.mulesoft.com](https://status.mulesoft.com/) - [eu1-status.mulesoft.com](https://eu1-status.mulesoft.com/) - [「Anypoint Cloud Security & Compliance (クラウドセキュリティおよびコンプライアンス)」ホワイトペーパー](https://mulesoft.com/downloads/whitepapers/security-whitepaper.pdf) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) # CloudHub 2.0 オペレーティングシステムのパッチ更新 CloudHub 2.0 はサービスとしてのインテグレーションプラットフォーム (iPaaS) であり、オペレーティングシステムのパッチ設定を自動で管理するため、ユーザーはアプリケーションの開発と更新に集中できます。 CloudHub 2.0 によって必要に応じてセキュリティパッチが適用されるため、アプリケーションが保護されます。 パッチ更新では、ローリング更新デプロイメントモデルを使用するアプリケーションに青/緑デプロイメントを使用し、それをサポートするアプリケーションのダウンタイムをゼロにしています。 CloudHub 2.0 では、MuleSoft が管理する 2 つのデプロイメントプラットフォームに継続的な更新を適用します。 - US クラウド - EU クラウド ## [](#cloudhub-2-0-インフラストラクチャの更新)CloudHub 2.0 インフラストラクチャの更新 コンテナベースのプラットフォームである CloudHub 2.0 は、必要に応じてインフラストラクチャ修正とセキュリティパッチが適用されるため、インフラストラクチャが保護され、最新の状態に保たれます。パッチ更新では、ローリングアップグレードデプロイメントが使用され (デプロイメントモデルとして選択されている場合)、オペレーティングシステムの変更または内部ソフトウェアへの変更が含まれる場合があります。ローリング更新デプロイメントモデルを使用している場合、更新により基盤となるホストの段階的な循環、ドレイン、置換が行われるため、ダウンタイムがゼロになります。アップグレード中に、Mule アプリケーションが新しいセキュアホスト上で再起動される場合があります。Mule ワーカーが複数のレプリカで実行されていない場合、または再作成デプロイメントモデルを使用している場合、わずかなダウンタイムが発生します。 更新が利用可能になると、CloudHub 2.0 はそれを新しい非公開スペースのデフォルトとして本番環境に含めます。既存のインフラストラクチャパッチスケジュールは、​[CloudHub 2.0 Runtime パッチ](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes)​と同じメンテナンス期間で実行されます。インフラストラクチャと Runtime の更新により、アプリケーションの再起動が行われる場合があります。 CloudHub 2.0 で使用される ​[Anypoint VPN](https://docs.mulesoft.com/cloudhub/vpn-maintenance)​ は、継続的にアップグレードされます。新しい更新が利用可能になるたびに、サービスレベル契約内で VPN にパッチが適用されます。Anypoint VPN が高可用性としてセットアップされていない場合、または非高可用性 VPN が 2 つのトンネルを使用してセットアップされていない場合、ダウンタイムが予想されます。 ### [](#クラスタリングされたレプリカとローリング更新)クラスタリングされたレプリカとローリング更新 [クラスター](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​で Mule を実行している場合、Hazelcast バージョンの変更を含む Mule Runtime バージョンのローリング更新を行うと、クラスターに異なる Hazelcast バージョンを持つ複数のメンバーが存在することになる可能性があります。 その結果、各種 Hazelcast バージョンに互換性がない場合、Hazelcast のシリアル化エラーによってアプリケーションが失敗することがあります。 このようなエラーを防ぐには、再作成更新戦略を使用します。 ## [](#self-upgrade-schedule)インフラストラクチャアップグレードのスケジュール (省略可能) リリースが使用可能になってから​[月 1 回の更新テーブル](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes)​に記載されている自動更新日までの間に、スケジュールされたパッチプロセスよりも早くインフラストラクチャアップグレードをスケジュールします。こうすることで、組織にとって都合の良い将来日付を選択できます。 平均で、このアップグレードが完了するには 30 ~ 60 分かかります。アップグレードがキューに登録されている場合は、30 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。 スケジュールされたアップグレードは、まだ進行中でなければ変更または削除できます。これは、​`[Queued (キューに登録済み)]`​ 状況で確認できます。スケジュールをキャンセルした場合、別のスケジュールを作成するか、以前のアップグレードにオプトインしないと、必須のパッチ適用期間中にアップグレードが発生します。 ### [](#runtime-manager-でアップグレードをスケジュールする)Runtime Manager でアップグレードをスケジュールする 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 非公開スペースでアップグレードが可能になったら、​**\[Infra Status (インフラ状況)\]**​ 列に ​**\[Upgrade Available (アップグレードが使用可能)\]**​ 状況が表示されます。 2. **\[Schedule an Upgrade (アップグレードをスケジュール)\]**​ をクリックします。 3. 非公開スペースをアップグレードする日付を選択します。 アップグレードは選択した日付の 00:00 UTC に実行されます。 4. チェックボックスをオンにして、早期のアップグレードに同意することを確定します。 5. **\[Upgrade (アップグレード)\]**​ をクリックします。 アップグレードを適用したら、​**\[Infra Status (インフラ状況)\]**​ 列ので状況を確認できます。 ## [](#早期インフラストラクチャアップグレードへのオプトイン-省略可能)早期インフラストラクチャアップグレードへのオプトイン (省略可能) リリースが使用可能になってから​[月 1 回の更新テーブル](https://docs.mulesoft.com/jp/release-notes/cloudhub-2/cloudhub-2-runtimes-release-notes)​に記載されている自動更新日までの間に、スケジュールされたパッチプロセスよりも早くインフラストラクチャアップグレードを適用します。こうすることで、組織にとって都合の良いタイミングを選択できます。 平均で、このアップグレードが完了するには 30 ~ 60 分かかります。アップグレードがキューに登録されている場合は、30 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。
このアップグレードは元に戻すことができます。必ずアップグレードの影響を理解してから、本番環境で適用する前に組織のニーズに基づいてアップグレードをトリガーするタイミングを選択してください。
### [](#runtime-manager-を使用してオプトインアップグレードを適用する)Runtime Manager を使用してオプトインアップグレードを適用する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 非公開スペースでアップグレードが可能になったら、​**\[Infra Status (インフラ状況)\]**​ 列に ​**\[Upgrade Available (アップグレードが使用可能)\]**​ 状況が表示されます。 2. **\[Upgrade available (使用可能なアップグレード)\]**​ をクリックします。 3. **\[Upgrade now (今すぐアップグレード)\]**​ をクリックして、早期アップグレードにオプトインします。 4. **\[Upgrade (アップグレード)\]**​ をクリックします。 アップグレードを適用したら、​**\[Infra Status (インフラ状況)\]**​ 列ので状況を確認できます。 ### [](#api-を使用してアップグレードをスケジュールまたは適用する)API を使用してアップグレードをスケジュールまたは適用する 非公開スペースのアップグレード API を使用して非公開スペースをアップグレードできます。詳細は、Exchange の [「Upgrade Private Space API (非公開スペース API のアップグレード)」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/endpoint/%232428/)​ドキュメントを参照してください。 ## [](#runtime-updates)月 1 回の日付パッチ更新 各月の最初の 1 週間に、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 月 1 回のパッチでは、アプリケーションがパッチバージョンの最新の日付パッチのみに更新されます。 パッチバージョン番号は変更されません。 これらの 4.3.x または 4.4.x バージョンへの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ : _日付_ パッチ日付が含まれるバージョン番号の例を示します。 `4.4.0:20211015` 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](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)を参照してください。 ### [](#更新スケジュール)更新スケジュール - 月の第 1 週に MuleSoft によって日付パッチがリリースされます。 - 月の第 3 週に MuleSoft によってその月の第 1 週にリリースされた日付パッチが自動的に適用されます。 - 本番以外の環境のアプリケーションは週内に更新されます。 - 本番環境のアプリケーションは週末に更新されます。 自動更新が行われた場合、アプリケーションの監査ログにはユーザー Anypoint Staff によるエントリが追加され、更新が行われた日時と更新に成功したかどうかが示されます。 更新に成功した場合、アクションは必要ありません。アプリケーションでダウンタイムなしの更新がサポートされないか、手動での更新が必要な場合、月の第 1 週にリリースされた日付パッチを第 1 週または第 2 週に手動で適用できます。​[手動でのランタイムバージョンの更新](#update-the-runtime-version-manually)​を参照してください。 ## [](#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. For CloudHub and CloudHub 2.0 customers, once Standard Support for Mule 4.4 ends, if you want to deploy new apps, you must do so on Mule 4.6 LTS or Mule 4.8 Edge. 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-リリースケイデンスサポート)Mule Runtime リリースケイデンスサポート 次の表に、CloudHub 2.0 の Mule Runtime リリースケイデンスサポートを示します。
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.
CloudHub または CloudHub 2.0 ユーザーが Anypoint Studio で Mule 4.6 アプリケーションを作成またはテストする場合、必要な Studio バージョンは 3 月の次に予定されているリリースになります。一方、MuleSoft では、2 月 14 日から 4 月 19 日まで API、Mule Maven プラグイン、Anypoint Platform CLI を介して Mule Runtime 4.5e バージョンに新しいアプリケーションをデプロイできます。CloudHub および CloudHub 2.0 アプリケーションでは、2 月ではなく 4 月に Mule 4.5 Edge から Mule 4.6 Edge への自動アップグレードが実行されます。 「Mule 4.5 Edge の自動アップグレードおよび新しいアプリケーションデプロイメントの一時的な変更」​を参照してください。
## [](#deployment-models-and-application-lifecycle-management)Deployment Models and Application Lifecycle Management Application lifecycle management depends on the deployment model.
アクション CloudHub 2.0

新規アプリケーションのデプロイ

Deploy to the latest minor-patch version available under Standard Support of each channel.

自動アップグレード

MuleSoft applies two distinct types of automatic updates:

  • Auto-patching (within the same minor version): Every month, apps in both the Edge and LTS channels are automatically updated to the latest available patch of their current minor version, as long as the app’s TLS version is compatible with the new patch. For example, an app can be updated from Mule 4.9.19 to 4.9.20. Monthly auto-patching doesn’t change the minor version. Patches are backward compatible and include bug fixes and security updates. Security updates can also be applied outside the regular schedule to address critical vulnerabilities. See the patching schedule for CloudHub and CloudHub 2.0.

  • Auto-upgrade (to a new minor version): When a minor version reaches End of Standard Support, apps are handled differently depending on the release channel:

    • Edge: Apps are automatically upgraded to the latest minor version in the Edge channel. The auto-upgrade occurs six weeks after the version reaches End of Standard Support, during that month’s patching schedule. Before the auto-upgrade, you have a self-upgrade window to move to the new minor version yourself.

    • LTS: Apps aren’t automatically upgraded to a new minor version when the version reaches End of Standard Support. To move to a later LTS minor version, upgrade your application manually. Apps that remain on a version through End of Extended Support are subject to the forced-upgrade behavior described in End of Extended Support.

Runtime version compatibility: Apps running Mule runtime 4.9 or earlier aren’t auto-upgraded to Mule runtime 4.10 or later. Mule 4.10 removes support for TLS 1.0 and 1.1, which can cause compatibility issues and break existing applications if upgraded automatically. Apps running earlier versions, such as Mule 4.6, can be auto-upgraded only as far as the Mule 4.9 release line and are moved to the latest available Mule 4.9 patch. To use Mule runtime 4.10 or later, upgrade your application manually.

自己アップグレード

For apps in the Edge channel, you can manually upgrade during the fixed window after the runtime version reaches End of Standard Support. See patching schedule for CloudHub and CloudHub 2.0.

  • Edge: Six weeks

  • LTS: Manual upgrade only (no automatic minor upgrade schedule)

ロールバック

Available to the previously used version

アプリケーションの再起動

Always

アプリケーションの実行維持

Until End of Extended Support

延長サポートの終了

Shutdown running apps.
Starting with Mule 4.7, CloudHub and CloudHub 2.0 applications in the Edge or LTS channels that are still running End of Life versions will undergo a forced upgrade to the latest version during the monthly upgrade window (See upgrade window for CloudHub and CloudHub 2.0).

廃止

Mule apps don’t reach End of Life because they’re always auto-upgraded.

サポート可能性

All Mule apps are under Standard Support.

## [](#mule-runtime-version-naming-changes)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. ### [](#cloudhub-2-0)CloudHub 2.0 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 CloudHub 2.0 では、 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. ## [](#通知の更新)通知の更新 最新のランタイムバージョンが使用できる場合: - **\[Applications (アプリケーション)\]**​ ページには、アプリケーションの使用可能な更新があるかどうかを示す ​**\[Update Available (更新が使用可能)\]**​ 列が表示されます。 ![ch2 update available column](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-update-available-column.png) - ​**\[Update available (更新が使用可能)\]**​ と新しい使用可能な更新がアプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Deployment Target (デプロイメント対象)\]**​ タブに表示されます。 ![ch2 update available field](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-update-available-field.png) MuleSoft によって、パブリッシュされたスケジュールに基づいて更新が自動的に適用されます。 必要があれば、都合に合わせて手動で更新できます。 ## [](#手動でのランタイムバージョンの更新)手動でのランタイムバージョンの更新 1. Anypoint Platform にログインします。 2. Runtime Manager に移動します。 3. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 4. 更新するアプリケーションを選択します。 5. **\[Settings (設定)\]**​ の ​**\[Deployment Target (デプロイメント対象)\]**​ タブで、​**\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンをクリックします。 6. バージョンの最新ビルドを選択します。 7. **\[Deploy (デプロイ)\]**​ をクリックします。 アプリケーションが新しいランタイムバージョンで再デプロイされます。 Edge リリースチャネルを選択すると、次の自動更新の日付を示すバナーが表示されます。 ![Edge リリースチャネルの自動更新の日付を示すバナー。](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-app-edge-auto-update.png) ## [](#ps-status)非公開スペースのアップグレードおよび更新の可能な状況種別 **\[Private Space (非公開スペース)\]**​ ページの ​**\[Infra Status (インフラ状況)\]**​ 列には、非公開スペースのインフラストラクチャのアップグレードの状況が表示されます。
状況 説明

Latest (最新)

非公開スペースでは、最新の使用可能なインフラストラクチャバージョンが実行されています。インフラストラクチャのアップグレードまたは設定の更新は現在行われていません。

Upgrade Available (アップグレードが使用可能)

非公開スペースのアップグレードが使用可能です。アップグレードをすぐに実行するか、アップグレードを開始する時刻をスケジュールできます。

Upgrade Scheduled (アップグレードがスケジュール済み)

非公開スペースのアップグレードが将来日付にスケジュールされています。

Queued (キュー内)

スケジュールまたは起動されたアップグレードがまもなく開始されます。スケジュールの変更やアップグレードの中断を行うことができなくなりました。

Upgrading (アップグレード中)

非公開スペースでは、スケジュールされたか、自己トリガーされたか、月 1 回のインフラストラクチャアップグレードの一環として、インフラストラクチャアップグレードが行われています。

Updating (更新中)

非公開ワークスペースでは、設定の変更によってトリガーされた更新が行われています。

Failed (失敗)

非公開スペースでは、スケジュールされたか、自己トリガーされたか、月 1 回のインフラストラクチャアップグレードの一環として、ユーザー設定の更新、またはインフラストラクチャのアップグレードに関連している可能性がある障害が発生しました。

Degraded (低下)

非公開スペースは、低下状態になっています。

 — 

非公開スペースの状況の詳細を取得できないため、状況が不明です。

## [](#セキュリティの更新)セキュリティの更新 MuleSoft では定期的にスキャンを実行し、JVM および基礎となるオペレーティングシステムのセキュリティ脆弱性を特定し、次の SLA に基づいて自動的にセキュリティパッチを適用します。
重要度レベル 重要度の定義 パッチの適用期間

P0

Critical (重大)

7 日

P1

高

30 日

## [](#更新後のアプリケーション状況の確認)更新後のアプリケーション状況の確認 新しい更新が行われた後で、Runtime Manager の ​**\[Applications (アプリケーション)\]**​ タブの ​**\[Status (状況)\]**​ 列で​[アプリケーション状況の状態](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#replica-statuses)​を確認できます。 また、アプリケーションログをチェックして、アプリケーションが正しくデプロイされたかどうかを確認し、一部の自動マイナー更新関連の問題が発生した場合に修正アクションを実行することもできます。詳細は、[デプロイ済みアプリケーションのログデータの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-logs)を参照してください。 ## [](#関連情報)関連情報 - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)。 # CloudHub 2.0 デプロイメントの水平自動スケーリング (HPA) の設定 Mule アプリケーションが必要に応じて自動的にデプロイメントレプリカをスケールアップまたはスケールダウンして CPU 使用量に対応できるように CPU ベースの水平自動スケーリングを設定します。
この機能の対象は、新しい価格設定およびパッケージモデルにオプトインしているお客様のみです。詳細は、Anypoint Platform 価格設定を参照してください。
Kubernetes では、水平ポッド自動スケーリング (HPA) により、需要に合わせてワークロードをスケーリングするために、ワークロードリソースが自動的に更新されます。水平スケーリングでは、負荷の増加に対応してより多くのポッドが自動的にデプロイされます。詳細は、 [Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale)​を参照してください。 水平ポッド自動スケーリングで設定されたアプリケーションには、​[グローバルリソースプールの制限](https://docs.mulesoft.com/jp/general/pricing#global-resource-pool-limits)​が適用されません。 ## [](#水平ポッド自動スケーリングの設定)水平ポッド自動スケーリングの設定 CloudHub 2.0 にデプロイされた Mule アプリケーションの水平自動スケーリングを設定する手順は次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 3. **\[Runtime (ランタイム)\]**​ タブで、​**\[Enable CPU Based Horizontal Autoscaling (CPU ベースの水平自動スケーリングを有効化)\]**​ ボックスをオンにします。 4. 最小と最大の ​**\[Replica Count (レプリカ数)\]**​ を設定します。 最大 8 個 (Anypoint Integration Advanced パッケージや、Anypoint Platform の Platinum または Titanium サブスクリプションがある場合は最大 16 個) のレプリカを使用してアプリケーションをデプロイできます。 5. ドロップダウンメニューから ​**\[Replica Size (レプリカサイズ)\]**​ を選択します。 Anypoint Integration Advanced パッケージがある場合、​`[Micro (極小)]`​、​`[Micro.Mem]`​、​`[Small (小)]`​ レプリカサイズから選択できます。別の料金プランがある場合、​`[Micro (極小)]`​ または ​`[Micro.Mem]`​ レプリカサイズを選択します。詳細は、​[「CloudHub 2.0 アプリケーションのデプロイメント」](https://docs.mulesoft.com/jp/general/pricing#cloudhub-2-0-application-deployment)​を参照してください。 6. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ![水平自動スケーリングを設定する](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-config-autoscaling.png) ## [](#自動スケーリングの状況とログ)自動スケーリングの状況とログ 自動スケーリングイベントが発生し、水平自動スケーリングを設定している Mule アプリケーションがスケールアップされたら、アプリケーションの詳細ウィンドウで ​**\[View status (状況を表示)\]**​ をクリックして、​**\[Scaling (スケーリング)\]**​ 状況を確認できます。​**\[Applications (アプリケーション)\]**​ リストでアプリケーションの ​**\[Scaling (スケーリング)\]**​ 状況を確認することもできます。 ![アプリケーションのスケーリング状況を確認します。](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-status-autoscaling.png) スケールアップされたレプリカの起動と、アプリケーションのスケーリング元またはスケーリング先のレプリカ数を追跡するには、アプリケーションのログを確認します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. 自動スケーリングが設定されたアプリケーションの行をクリックします。 3. **\[Manage application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Logs (ログ)\]**​ タブを選択します。 アプリケーションログの例 ```console Info 8 minutes ago - 2023-11-08 14:35:01.466 PST - Runtime Manager Application id: scaled UP from 1 to 2 replicas. Info a minute ago - 2023-11-08 14:41:24.819 PST - Runtime Manager Application id: scaled DOWN from 2 to 1 replicas. : ``` また、アクセス管理の ​[\[Audit Logs (監査ログ)](https://docs.mulesoft.com/jp/access-management/audit-logging)\]​ では、自動スケーリングイベントを追跡できます。アプリケーションデプロイメントのスケーリングが発生するたびに、製品が ​**Runtime Manager**​、ユーザーが ​**Anypoint Staff**​ として監査ログがパブリッシュされます。このログでは、​**\[Action (アクション)\]**​ は ​`[Scaling (スケーリング)]`​ に設定され、​**\[Object (オブジェクト)\]**​ はアプリケーション ID になっています。 次に、ログペイロードの例を示します。 ```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"} ``` ## [](#cpu-ベースの自動スケーリングポリシーの理解)CPU ベースの自動スケーリングポリシーの理解 MuleSoft は、お客様の Mule アプリケーションデプロイメントの [自動スケーリング](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)​ポリシーを所有し、適用します。 CloudHub 2.0 にデプロイされるすべての Mule アプリケーションで使用される CPU ベースの HPA ポリシーは次のとおりです。 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: 3 metrics: - resource: name: cpu target: averageUtilization: 70 type: Utilization type: Resource minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app 考慮すべき点をいくつか挙げます。 - スケールアップは最長 180 秒おきに実行されます。水平自動スケーリングでは、設定された最大レプリカ数に達するまで、現在実行中のレプリカの最大 100% を追加できます。スケールアップの場合、安定化期間はありません。メトリクスでスケールアップが必要であることが示された直後に対象がスケールアップされます。 - スケールダウンは最長 15 秒おきに実行されます。水平自動スケーリングでは、現在実行中のレプリカの最大 100% を削除できます。対象は許容される最小レプリカ数までスケールダウンされます。削除されるレプリカ数は、過去 1800 秒間の安定化期間に集計された計算に基づきます。 最小レプリカ数: - 任意の時点で実行が保証されるレプリカの最小数。 - スケールダウンポリシーによって、この数を下回るまでレプリカが削除されることはありません。 最大レプリカ数: - 上限となるレプリカの最大数。スケールアップでこの数を超えるレプリカを追加することはできません。 - スケールアップポリシーによってこの数を超えてレプリカが追加されることはありません。 HPA を有効にすると、アプリケーションが水平にスケーリングされるときにお客様に追加のフロー使用量が発生することがあります。予期しないスケーリングによる超過を避けるため、購入したフロー制限内に収まるように最大レプリカ数は慎重に設定してください。発生したフロー使用量は​[使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports)​で追跡できます。 ## [](#パフォーマンスに関する考慮事項)パフォーマンスに関する考慮事項 Mule アプリケーションの水平自動スケーリングを成功させるために、パフォーマンスに関する次の考慮事項を確認してください。 - CPU 使用量に基づいてスケーリングされる Mule アプリケーションは CPU ベースの HPA に適しています。次に例を示します。 - 非同期要求を使用する HTTP/HTTPS アプリケーション。 - リバースプロキシ。 - 低レイテンシーで高スループットのアプリケーション。 - DataWeave 変換。 - APIkit ルーティング。 - ポリシーを使用する API ゲートウェイ。 - バッチジョブなどの並列処理が組み込まれていない非リエントラントアプリケーション、リエントランスやアプリケーション間の重複スケジューリングがないスケジューラーアプリケーション、大きな要求を使用する低スループット高レイテンシーのアプリケーションなどは、CPU ベースの HPA に適していません。 # CloudHub 2.0 にデプロイされたアプリケーションの更新 アプリケーションを CloudHub 2.0 にデプロイすると、Runtime Manager によって自動的にバージョン管理され、新しい​_設定_​が作成されます。 アプリケーションの設定により、次のことができます。 - アプリケーションの設定変更履歴を表示する。 - 現在適用されている設定に問題がある場合や不安定な場合に、設定を以前のバージョンにロールバックする。 - アプリケーションの状況を表示する。 可能な値: Running (実行中) 少なくとも 1 つのレプリカがトラフィックを受信中 (開始状態) です。 Not Running (停止中) どのレプリカもトラフィックを受信していません。 Unknown (不明) 対象が切断されています。 この値が表示される場合、MuleSoft 関連の停止またはインシデントがあります。 - 次のようなデプロイされたアプリケーションの設定を更新する。 - アプリケーションファイル - アプリケーションデプロイメントのパッケージバージョン - ランタイムバージョン、レプリカ数、アプリケーションがクラスターモードで実行されているかどうかなどのデプロイメント対象設定 - エンドポイントと TLS の設定 - リソース割り当て (CPU とメモリを含む) - アプリケーションプロパティ値 - 設定に関連付けられたログと診断を表示する。 ## [](#アプリケーション設定を更新する)アプリケーション設定を更新する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Configuration (設定)\]**​ をクリックして、アプリケーション設定履歴を表示します。 \[Config changes (設定の変更)\] タブ 正常にデプロイされたアプリケーション設定への変更が表示され、最新の 10 個の設定デプロイメントが設定日順に表示されます。 一意のハッシュによって、履歴内の各設定が識別されます。 \[All changes (すべての変更)\] タブ 設定デプロイメントから作成されたバージョンの履歴、および各バージョンで実行されたアクションが表示されます。 5. デプロイメント対象 (共有スペースまたは非公開スペース) に応じて、デプロイされた設定を変更します。 - 新しいアプリケーションファイルのアップロード、デプロイメント対象とリソース割り当ての変更など、ランタイムオプションを指定する。 - アプリケーションの現在のバージョンを表示する。 - アプリケーションのエンドポイントを変更する。 - プロパティを使用してアプリケーションの動作を変更する。 - アプリケーションログを無効または有効にし、ログレベルを指定する。 6. **\[Apply Changes (変更を適用)\]**​ をクリックします。 設定が進行中であることを示すメッセージがページの上部に表示されます。 7. **\[View status (状況を表示)\]**​ をクリックし、デプロイメントの各レプリカの​[状況](#replica-statuses)​を表示します。 設定が正常に適用およびデプロイされると、ページの上部にメッセージが表示され、アプリケーションの状態、設定識別子、日付、およびレプリカの状態が示されます。 新しい設定が ​**\[Config changes (設定の変更)\]**​ リストに表示されます。 設定の更新のデプロイに失敗した場合、メッセージは CloudHub 2.0 が設定を適用しなかったことを示し、設定の状況は ​`[Update failed (更新失敗)]`​ になり、設定は表示ラベルなしで ​**\[Config changes (設定の変更)\]**​ 履歴に表示されます。 失敗した場合、デプロイメントは最後に成功したバージョンの設定にロールバックしようとします。 場合によっては、ロールバックが成功せず、設定の状況が ​`[Update failed (更新失敗)]`​ になります。 ## [](#replica-statuses)レプリカの状況 Started (開始済み) レプリカはトラフィックを受信中です。 Pending (保留中) レプリカは開始を待機中です。 Starting (開始中) レプリカは開始中です。 Deleting (削除中) レプリカの削除が進行中です。 Deleted (削除済み) レプリカは削除されました。 Stopping (停止中) レプリカは停止中です。 Stopped (停止) レプリカが停止しました (トラフィックを受信していません)。 Failed (失敗) 設定のデプロイメントが失敗しました。 Recovering (回復中): レプリカは終了後に再起動しようとしています。 最後に正常にデプロイされた設定は、新しい (目的の) 設定が正常にデプロイされるまで保持されます。 Applying (適用中) レプリカの以前の設定が実行されており、新しい設定の実装処理中です。 レプリカの理想的な状態を示す ​_\[desired state (望ましい状態)\]_​ を設定できます。たとえば、レプリカが実行中である必要がある場合は、望ましい状態を ​`[Running (実行中)]`​ に設定できます。 ## [](#ローリング更新とデプロイモデルの再作成の比較)ローリング更新とデプロイモデルの再作成の比較 デプロイメントモデルに応じて、CloudHub 2.0 は新しい設定を次のいずれかとして適用します。 - Rolling update (ローリング更新) レプリカを増分的に更新することで、可用性を維持します。 このモデルは、CloudHub 2.0 がアプリケーションに更新を適用する間、ダウンタイムがゼロであることを意味します。 CloudHub 2.0 は更新をローリング更新として適用するため、更新が完了するまで異なるバージョンのアプリケーションが同時に実行されます。 そのため、アプリケーションは複数のバージョンを並行して実行できることを確認してください。 - Recreate (再作成) 再デプロイメントの前にレプリカを終了します。 再デプロイメントはより高速で、追加リソースは必要ありません。 ## [](#以前に成功した設定にロールバックする)以前に成功した設定にロールバックする デプロイした設定に問題がある場合、以前に成功したバージョンの設定にロールバックできます。
これがアプリケーションの最初のデプロイメントである場合、ロールバックバージョンは定義されません。 失敗したデプロイメントの場合、アプリケーションは失敗状況のままになります。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Configuration (設定)\]**​ をクリックして、アプリケーションの設定履歴を表示します。 5. **\[Config changes (設定の変更)\]**​ 履歴からロールバックするバージョンを選択します。 以前に使用されていた設定のランタイムバージョンを変更するには、​**\[Runtime Version (ランタイムバージョン)\]**​ ドロップダウンリストから目的のバージョンを選択します。デプロイする前に他の設定を変更できます。 6. **\[Deploy (デプロイ)\]**​ をクリックします。 設定は ​**\[Config changes (設定の変更)\]**​ 履歴リストの一番上に移動し、新しいデプロイメント日が表示され、元の識別ハッシュが保持されます。 Unresolved include directive in modules/ROOT/pages/ch2-update-apps.adoc - include::cloudhub::partial$mule-runtime-eos-note.adoc\[\] ## [](#関連情報)関連情報 - [共有スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-shared-space) - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [プロパティを使用したアプリケーションの動作の変更](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-props) - [デプロイ済みアプリケーションのログデータの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-logs) - [デプロイ済みアプリケーションの診断データの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-diag) - [アプリケーションスケジュールの管理](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-schedules) # CloudHub 2.0 にデプロイされたアプリケーションの監視 - [デプロイ済みアプリケーションのログデータの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-logs) - [デプロイ済みアプリケーションの診断データの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-diag) - [アプリケーションアラートの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-app-alerts) # CloudHub 2.0 にデプロイされたアプリケーションの管理 - [CloudHub 2.0 にデプロイされたアプリケーションの更新](https://docs.mulesoft.com/jp/cloudhub-2/ch2-update-apps) - [アプリケーションスケジュールの管理](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-schedules) - [プロパティを使用したアプリケーションの動作の変更](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-props) - [アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props) - [アプリケーションログの管理](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-app-logs) - [アプリケーションの自動再起動](https://docs.mulesoft.com/jp/cloudhub-2/ch2-understand-app-restart) # CloudHub 2.0 ネットワークアーキテクチャ CloudHub 2.0 は、MuleSoft の完全に管理されコンテナ化されたサービスとしてのインテグレーションプラットフォーム (iPaaS) です。API とインテグレーションを軽量コンテナとしてクラウドにデプロイします。これにより、これらの保守性、安全性、拡張性が確保されます。 このドキュメントでは、CloudHub 2.0 ネットワーク、ネットワークインターフェース、ネットワークサービスの設定と管理に関する情報が提供されます。各種シナリオについては、[デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)を参照してください。 CloudHub 2.0 ネットワークアーキテクチャの基本コンポーネントは、HTTP ロードバランサー、Mule レプリカ DNS レコード、非公開スペース、リージョンサービスです。 - [\[HTTP Load Balancer\]](<#HTTP Load Balancer>) - [\[DNS Records\]](<#DNS Records>) - [\[Private Spaces Configurations\]](<#Private Spaces Configurations>) - [\[Regional Services\]](<#Regional Services>)​ ![非公開スペースの CloudHub 2.0 ネットワークアーキテクチャの基本コンポーネント](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-networking-architecture-ps-diagram.png) ![共有スペースの CloudHub 2.0 ネットワークアーキテクチャの基本コンポーネント](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-networking-architecture-shs-diagram.png) ## [](#http-ロードバランサー)HTTP ロードバランサー CloudHub 2.0 はすべてのインテグレーションに負荷分散サービスを提供します。デフォルトのエンドポイントを使用することも、独自の証明書を使用してカスタムエンドポイントをプロビジョニングすることもできます。 アプリケーションを 2 つ以上のレプリカにデプロイすると、CloudHub 2.0 は、割り当てたレプリカで HTTP 要求を自動的に分散する HTTP 負荷分散サービスを提供します。 CloudHub 2.0 負荷分散サービスは、アプリケーションレプリカ間でラウンドロビン方式の負荷分散を実行します。これにより、水平拡張性を確保できます。また、この負荷分散サービスでは、アプリケーションのアップグレード時に切り替えが透過的に実行されます。[CloudHub 2.0 にデプロイされたアプリケーションの更新](https://docs.mulesoft.com/jp/cloudhub-2/ch2-update-apps)を参照してください。 CloudHub 2.0 にデプロイされる各アプリケーションには、ロードバランサーを参照するデフォルトの公開 DNS レコード (​`...cloudhub.io`​) と内部 DNS レコード (​`.internal-..cloudhub.io`​) の両方があります。 CloudHub 2.0 非公開スペース負荷分散サービスは、標準 HTTPS ポート ​`443`​ で公開トラフィックを受け入れます。非公開スペースでは、標準 HTTP ポート ​`80`​ で HTTP トラフィックを受け入れることもできます。共有スペースでは、​`80`​ を受け入れません。 ### [](#mule-アプリケーションポート)Mule アプリケーションポート アプリケーションは、予約されたプロパティ ​`${http.port}`​ を介してホスト ​`0.0.0.0`​ とポートをリスンする必要があります。MuleSoft は、このプロパティの値を割り当てます。 負荷分散サービスは、トラフィックをデプロイ済みアプリケーションに転送します。 ### [](#アップストリーム-https-トラフィック)アップストリーム HTTPS トラフィック デフォルトでは、負荷分散サービスは HTTP を介してトラフィックをデプロイ済みアプリケーションに転送します。HTTPS を使用する方法: - [\[deployment settings (デプロイメント設定)](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space#configure-endpoint-path)\]​ の ​**\[Ingress (イングレス)\]**​ タブで ​**\[Last-Mile Security (Last -Mile セキュリティ)\]**​ 設定を有効にします。 - 非公開スペースの TLS コンテキストで証明書を指定して、HTTPS をリスンするようにアプリケーションを設定します。 次の例は、HTTPS エンドポイントを公開する Mule アプリケーション設定を示しています。 ```console ``` ### [](#ロードバランサーの接続)ロードバランサーの接続 クライアントが CloudHub 2.0 ロードバランサー ​`(...cloudhub.io)`​ を介して実行する要求ごとに、ロードバランサーは 2 つの接続 (クライアントとロードバランサー間の接続とロードバランサーとアプリケーション間の接続) を維持します。接続ごとにロードバランサーは 300 秒のデフォルトのアイドルタイムアウトを管理します。これは、どちらの接続にもデータが送信されていない場合にトリガーされます。この期間にデータが送受信されない場合、ロードバランサーは両方の接続を閉じます。 どちらの側からでも接続の処理に 300 秒を超える時間がかかる場合、処理を非同期で実行します。アイドルタイムアウト値は、Runtime Manager の ​[\[private space settings (非公開スペース設定)](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-advanced#configure-http-requests-and-read-response-timeout)\]​ の ​**\[Advanced (詳細)\]**​ タブ、または Mule アプリケーションの ​[Mule 設定ファイル](https://docs.mulesoft.com/mule-runtime/latest/about-mule-configuration)​の​[グローバル設定](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration)​でカスタマイズできます。 ## [](#dns-レコード)DNS レコード 次の DNS レコードが CloudHub 2.0 アプリケーションに公開されます。

*.<space-id>.<region>.cloudhub.io

非公開スペース内で実行されるアプリケーション。

<space-id>.<region>.cloudhub.io

ロードバランサーを参照するレコード。このレコードは、カスタムドメイン CNAME の対象として使用します。

*.internal-<space-id>.<region>.cloudhub.io

非公開スペース内で実行されるアプリケーション。この DNS レコードの IP アドレスには、​非公開スペース​内でのみアクセスできます。​共有スペース​内からはアクセスできません。

internal-<space-id>.<region>.cloudhub.io

内部ロードバランサー。このレコードは、カスタムドメイン CNAME の対象として使用します。この DNS レコードの IP アドレスには、非公開スペース内でのみアクセスできます。共有スペース内からはアクセスできません。

## [](#非公開スペース設定)非公開スペース設定 次の設定は、非公開スペースにのみ適用されます。 ### [](#アプリケーション間の通信)アプリケーション間の通信 アプリケーション間の通信方法を次に示します。 - デフォルトの公開 DNS 名: `app.sxjsip.aus-s1.cloudhub.io` - デフォルトの内部 DNS 名 (非公開スペースのみ): `app.internal-sxjsip.aus-s1.cloudhub.io` - カスタムドメイン名 (設定されている場合): `acme.example.com` - クラスターローカル DNS: `app`​ または ​`app.envid.svc.cluster.local:8081` 内部 DNS 名を使用する場合、トラフィックは非公開スペースネットワークに留まります。アプリケーションを非公開スペースにデプロイする場合、外部に公開されるエンドポイントを削除または省略できます。その場合、内部トラフィック用にアプリケーションの内部エンドポイントを使用します。 非公開スペースのローカルエンドポイントを使用する場合、トラフィックは非公開スペース内に留まります。ただし、非公開スペースのローカルエンドポイントは高可用性ではありません。一部の非公開スペース操作 (障害回復など) 中にエンドポイントに到達できなくなることがあります。非公開スペースのローカルエンドポイントでは、同じ環境内のトラフィックのみが許可されます。 ### [](#カスタムドメイン名)カスタムドメイン名 カスタム証明書を非公開スペースに適用できます。CloudHub 2.0 は、証明書の CN および SAN リストを解析して、アプリケーションをデプロイするときにそれらのドメインを使用できるようにします。 公開 DNS レコードまたは内部 DNS レコードのいずれかを CNAME に設定します。次に例を示します。 \*.example.com => sxjsip.aus-s1.cloudhub.io \*.example.com => internal-sxjsip.aus-s1.cloudhub.io ### [](#ip-範囲)IP 範囲 インターネットへのエグレストラフィックは、非公開ネットワーク設定の ​**\[Outbound Static IPs (アウトバウンド静的 IP)\]**​ 項目にリストされている IP アドレスから取得されます。 非公開スペースの有効期間中は、公開 DNS 対象と非公開 DNS 対象の IP は変更されません。 VPN またはトランジットゲートウェイ (TGW) へのエグレストラフィックは、非公開スペースの CIDR ブロックから取得されます。 ![UI にリストされているインバウンドおよびアウトバウンド IP](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-networking-ip-ranges.png) 非公開スペースでは、いくつかのセカンダリ CIDR を内部的に使用します。 BGP ルーティングプロトコルを使用している場合、次の CIDR ブロックをゲートウェイにパブリッシュできます。 100.64.0.0/16 100.66.0.0/16 100.67.0.0/16 100.68.0.0/16 このため、​`100.64.0.0/10`​ は非公開スペースでは​[サポートされません](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#unusable-cidr)​。 ルートマップからこれらのプレフィックスから絞り込むことができます。詳細は、 [「CloudHub 2.0 VPN から余分な BGP ルートを受信する」](https://help.mulesoft.com/s/article/Received-Extra-BGP-routes-from-CloudHub-2-0-VPN)​を参照してください。 非公開スペースの作成時にオンプレミスネットワークの予約済み範囲を指定することもできます。お客様によって指定された予約済み範囲は、CloudHub 2.0 で使用されません。詳細は、​[「予約する企業の CIDR 」](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#reserved-cidr)​を参照してください。 ### [](#接続)接続 非公開スペースでは、仮想プライベートネットワーク (VPN) とトランジットゲートウェイ (TGW) の 2 種類の接続がサポートされています。 各 Anypoint VPN 接続にはトンネルが 2 つあり、リモートロケーションにある 1 件のパブリック IP アドレスに接続できます。エンドポイントで両方のトンネルを設定すると、VPN は高可用性になります。 また、冗長 VPN 接続を定義して弾力性を高めることができます。通常、管理対象サービスとして基盤となる VPN サービスがアップグレードされます。ルーチンメンテナンスによって VPN 接続の 2 つのトンネルの片方が短時間だけ無効になることがあります。このときは VPN 接続が他方のトンネルに自動的にフェールオーバーするため、アクセスは中断されません。このため、エンドポイントで両方のトンネルを設定する必要があります。詳細は、 [「Anypoint Dynamic (BGP) VPN の更新でのトンネルの切り替え」](https://help.mulesoft.com/s/article/Tunnel-Switch-in-an-Anypoint-Dynamic-BGP-VPN-Update)​を参照してください。 設計上、TGW 接続は高可用性であるため、冗長 TGW 接続を作成しないでください。詳細は、[トランジットゲートウェイアタッチメント](https://docs.mulesoft.com/jp/cloudhub-2/ps-tgw-about)を参照してください。 CloudHub VPC AWS Direct Connect 接続は、CloudHub 2.0 で非推奨になっています。代わりに、TGW アタッチメントを使用してください。また、TGW がアタッチされている非公開スペースを削除すると、トランジットゲートウェイは保存され、別の非公開スペースに再度アタッチできます。 #### [](#cloudhub-と-cloudhub-2-0-間の接続)CloudHub と CloudHub 2.0 間の接続 [TGW アタッチメント](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw)​を使用して、CloudHub の専用 VPC を CloudHub 2.0 非公開スペースに接続します。CloudHub と CloudHub 2.0 で個別にアタッチメントを適用する必要があります。 ### [](#ファイアウォールルールおよびポートアドレス)ファイアウォールルールおよびポートアドレス HTTP イングレス デフォルトでは、ポート ​`443`​ および ​`80`​ は、すべての外部インバウンドトラフィックに公開されます。これらのポートを削除または変更して、インバウンドトラフィックを制限できます。 非 HTTP イングレス デフォルトでは、非 HTTP ポートは開いていません。TCP ポート (30500 ~ 32500) の固定リストを開いて、非 HTTP トラフィックが Mule アプリケーションに流れることを許可できます。これらのポートは、非公開スペース内からのみ到達でき、VPN または TGW から取得されます。非公開スペースで TCP トラフィックを許可する方法についての詳細は、[Application Manager API を使用した TCP を使用するアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-api)を参照してください。 エグレス デフォルトでは、アプリケーションは任意の宛先およびポートへのアウトバウンド接続を作成できます。この動作を変更して、エグレストラフィックを制限できます。 インターネットに対するすべてのイングレスルールとエグレスルールを削除できます。その場合、次の制御措置のため、非公開スペースは引き続き通常どおり機能します。 - Anypoint Monitoring の取り込みトラフィックファイアウォールルールがすべての Mule アプリケーションのファイアウォールルールに暗黙的に追加されます。 - 必要不可欠な AWS サービストラフィックフローは、Mule アプリケーションから常に許可されます。 - エグレスルールはアプリケーションレベルで適用できます。詳細は、[アプリケーションレベルのエグレスルールの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-app-level-egress)を参照してください。 - インターネットゲートウェイへのデフォルトルートを削除できます。ただし、エグレスファイアウォールルールが機能するには、宛先 IP がルーティング可能である必要があります。 ## [](#リージョンサービス)リージョンサービス インテグレーションの DNS レコードとロードバランサーは、アプリケーションをデプロイするリージョンによって異なります。 各リージョンでアプリケーションがどの DNS レコードを使用できるかについて次の表にまとめました。
リージョン リージョン名 コントロールプレーン DNS レコードの例 内部 DNS レコードの例

北米

米国東部 (北バージニア)

us-east

US

myapp.us-e1.cloudhub.io

<app>.internal-<space-id>.usa-e1.cloudhub.io​

米国東部 (オハイオ)

us-east-2

US

myapp.us-e2.cloudhub.io

<app>.internal-<space-id>.usa-e2.cloudhub.io​

米国西部 (北カリフォルニア)

us-west

US

myapp.us-w1.cloudhub.io

<app>.internal-<space-id>.usa-w1.cloudhub.io​

米国西部 (オレゴン)

us-west-2

US

myapp.us-w2.cloudhub.io

<app>.internal-<space-id>.usa-w2.cloudhub.io​

カナダ (中央部)

ca-central

US

myapp.ca-c1.cloudhub.io

<app>.internal-<space-id>.can-c1.cloudhub.io​

US GovCloud (西部)

us-gov-west

US Gov

myapp.usg-w1.gov.cloudhub.io

-

南米

ブラジル (サンパウロ)

br-south

US

myapp.br-s1.cloudhub.io

<app>.internal-<space-id>.bra-s1.cloudhub.io​

APAC

Singapore

ap-southeast

US

myapp.sg-s1.cloudhub.io

<app>.internal-<space-id>.sgp-s1.cloudhub.io​

オーストラリア (シドニー)

ap-southeast-2

US

myapp.au-s1.cloudhub.io

<app>.internal-<space-id>.aus-s1.cloudhub.io​

日本 (東京)

ap-northeast

US

myapp.jp-e1.cloudhub.io

<app>.internal-<space-id>.jpn-e1.cloudhub.io​

ヨーロッパ

アイルランド

eu-west

US

myapp.ir-e1.cloudhub.io

<app>.internal-<space-id>.irl-e1.cloudhub.io​

ドイツ (フランクフルト)

eu-central

US

myapp.de-c1.cloudhub.io

<app>.internal-<space-id>.deu-c1.cloudhub.io​

UK (ロンドン)

eu-west-2

US

myapp.uk-e1.cloudhub.io

<app>.internal-<space-id>.gbr-e1.cloudhub.io​

アイルランド (EU コントロールプレーン)

eu-west

EU

myapp.ir-e1.eu1.cloudhub.io

-

ドイツ (EU コントロールプレーン)

eu-central

EU

myapp.de-c1.eu1.cloudhub.io

-

## [](#関連情報)関連情報 - [非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about) - [SSL エンドポイントと証明書の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-ssl-endpoints) # CloudHub 2.0 の制限 CloudHub 2.0 には次の制限があります。 ビジネスグループあたりの環境数 200 組織あたりの非公開スペース数 100 非公開スペースあたりの接続数 5.接続が冗長でない場合は 10。 非公開スペースあたりの VPN 数 10 トランジットゲートウェイの接続 非公開スペースあたり 5 (使用可能なネットワーク接続エンタイトルメントの数によって異なる) HTTP ヘッダー長 (​`maxHeaderLength`​) 32K 最大 HTTP 要求サイズ 1 GB 最大 HTTP 要求タイムアウト 300 秒 最大イングレス URI サイズ 4 KB ファイアウォールルール数 (インバウンド) 300 ファイアウォールルール数 (アウトバウンド) 300 アプリケーションサイズ 最大 350 MB アプリケーションプロパティ 300 アプリケーションプロパティキーと値 1024 文字 非公開スペースあたりのカスタム TLS コンテキスト 50 TLS コンテキストでのクライアント証明書の最大数 クライアント証明書の数に制限はありませんが、ストアファイルサイズに制限があります。 TLS コンテキストでは 1 つのキーストアと 1 つのトラストストアを参照できますが、それらにはそれぞれファイルサイズ制限があります。 - トラストストアの最大ファイルサイズ: 131072 バイト (128 KB) - 種別 JKS、JCEKS、PKCS12 のキーストアの最大ファイルサイズ: 40960 バイト (40 KB)。 - 種別 PEM のキーストアの最大ファイルサイズ: - 証明書ファイル: 4096 バイト (4 KB)。 - CA パス証明書ファイル: 28672 バイト (28 KB)。 POST 要求のイングレスコントローラー ​`content-length`​ 0 以上。 値が 0 の場合も、​`content-length`​ は POST 要求に含まれている必要があります。 Anypoint Platform CloudHub 2.0 API レート制限 リモート IP アドレスあたり 15 要求/秒。 Exchange での制限についての詳細は、​[「アセット制限」](https://docs.mulesoft.com/jp/exchange/asset-versions#asset-limits)​を参照してください。
制限は変更される場合があります。
# CloudHub 2.0 の概要 CloudHub 2.0 は、完全に管理されコンテナ化されたサービスとしてのインテグレーションプラットフォーム (iPaaS) であり、API とインテグレーションを軽量コンテナとしてクラウドにデプロイできます。 ## [](#cloudhub-2-0-でデプロイする理由は)CloudHub 2.0 でデプロイする理由は? CloudHub 2.0: - 世界の 12 リージョンにわたるデプロイメントを提供。 - 拡張性の高いトランザクション量をサポートするために、インフラストラクチャと組み込みサービスを動的に拡大または縮小。 - セキュリティポリシーが組み込まれ、暗号化されたシークレット、ファイアウォールコントロール、制限されたシェルアクセスでサービスと機密データを保護。 - Anypoint Platform 内で保管時および送信時に証明書、パスワード、その他の機密設定データを暗号化。 - 各 Mule インスタンスとサービスを個別のコンテナとして実行することにより、標準化された分離境界を提供。 CloudHub 2.0 の価格情報については、アカウントエグゼクティブまたはアカウント開発担当者にお問い合わせください。 ## [](#cloudhub2-hyperforce)コントロールプレーンごとの CloudHub 2.0 機能 すべての CloudHub 2.0 機能は、すべてのコントロールプレーンでサポートされますが、いくつかの例外があり、デプロイメントリージョンによって異なります。 - デフォルトのエグレストラフィックルート (0.0.0.0) を削除すると、CloudHub 2.0 で Anypoint Monitoring が失敗する可能性があります。 - エンドポイント URL 形式で ​`cloudhub.io`​ の前にリージョンサフィックスが必要な場合と、そうでない場合があります。
CloudHub 2.0 機能 US クラウド EU クラウド カナダクラウド 日本クラウド

デフォルトルートの削除

使用可能

使用可能

使用不可

使用不可

エンドポイント URL

リージョンサフィックスなし: https://*.10u6w7.usa-e1.cloudhub.io

リージョンサフィックスが必要: https://*.10u6w7.usa-e1.eu1.cloudhub.io

リージョンサフィックスが必要: https://*.10u6w7.ca-c1.cloudhub.io

リージョンサフィックスが必要: https://*.10u6w7.jp-e1.cloudhub.io

## [](#関連情報)関連情報 - [CloudHub 2.0 の機能](https://docs.mulesoft.com/jp/cloudhub-2/ch2-features) - [非公開スペースの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure) - [非公開ネットワークリージョン](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#private-network-region) # CloudHub 2.0 の機能 CloudHub 2.0 には、CloudHub 1.0、および自己管理型 Kubernetes の Anypoint Runtime Fabric の多くの機能が含まれています。 ## [](#cloudhub-2-0-機能の比較)CloudHub 2.0 機能の比較 次の表は、CloudHub 2.0、CloudHub 1.0、および自己管理型 Kubernetes の Anypoint Runtime Fabric の機能とサポートを比較しています。
Table 1. 機能の比較
機能 CloudHub 2.0 CloudHub 1.0 Runtime Fabric

VM 管理

プロビジョニング/スケーリング

完全管理型

完全管理型

自己管理型

OS パッチ適用

完全管理型

完全管理型

自己管理型

VM 自己回復

完全管理型

完全管理型

サポート (管理ノード)

永続的な VM キュー

サポート対象外

サポート

サポート対象外

負荷分散およびイングレス

デフォルトのエンドポイント

完全管理型

完全管理型

サポート対象外

URL 書き換え

サポート

(app-level)

サポート

(DLB)

サポート

プロビジョニング/更新

Fully-managed

Fully-managed

サポート

証明書管理

サポート

サポート

サポート

複数のトラストストア​

(相互 TLS のクライアント証明書)

サポート

サポート対象外

サポート

カスタムエンドポイント

サポート

サポート

サポート

複数のカスタムエンドポイント​

アプリケーションごと

サポート

一部サポート

サポート

TLS 1.0

サポート対象外

サポート

サポート

TLS 1.1

サポート対象外

サポート

サポート

TLS 1.2

サポート

サポート

サポート

TLS 1.3

サポート

サポート

サポート

非公開エンドポイント

サポート

サポート

サポート

ロードバランサーのログ

サポート

(ダウンロード)

サポート対象外

サポート

イングレスログ

サポート

サポート対象外

サポート対象外

ネットワーク

デプロイメントリージョン

12 個の地理的リージョン

12 個の地理的リージョン

サポート

(手動)

Virtual Private Cloud

完全管理型

(非公開スペース)

完全管理型 (Anypoint VPC)

サポート

(手動)

Virtual Private Network

完全管理型

(非公開スペース)

完全管理型

(Anypoint VPN)

サポート

(手動)

AWS トランジットゲートウェイ

サポート

(非公開スペース)

サポート

サポート

Direct Connect

サポート対象外

サポート

(非セルフサービス)

サポート

VPC ピアリング

サポート対象外

サポート

(非セルフサービス)

サポート

DNS

完全管理型

完全管理型

サポート

インバウンドファイアウォールルール

サポート

サポート

サポート

アウトバウンドファイアウォールルール

サポート

(非公開スペース)

サポート対象外

サポート

静的 IP アドレス

サポート

(非公開スペース)

サポート

(アプリケーションごと)

サポート

アプリケーションの機能

スケジュール管理

サポート

サポート

サポート対象外

TLS 証明書​

API ゲートウェイデプロイメント用

サポート

サポート

サポート対象外

DataGraph

サポート対象外

サポート

サポート対象外

Mule パッチ更新

自動

自動

再デプロイメントが必要

クラスター​

管理

完全管理型

完全管理型

自己管理型

オブジェクトストア

完全管理型

(Object Store v2)

完全管理型

(Object Store v2)

サポート

高可用性​

AZ 全体

完全管理型

(2 つ以上のレプリカ)

完全管理型

(2 つ以上のワーカー)

サポート

(2 つ以上のレプリカ)

セキュアプロパティ

サポート

サポート

一部サポート

ログテーリング

完全管理型

完全管理型

Anypoint Platform 外部でサポート

継続的インテグレーションのデプロイメント

サポート

(API、Maven プラグイン、Anypoint CLI 経由)

サポート

(API、Maven プラグイン、Anypoint CLI 経由)

サポート

(API と Maven プラグイン経由)

組み込み通知

サポート対象外

サポート

サポート

カスタム通知​

(​CloudHub Connector​)

サポート対象外

サポート

サポート対象外

ログ転送

手動

サポート

(アプリケーションごと)

手動

メッセージブローカー

完全管理型

(Anypoint MQ)

完全管理型

(Anypoint MQ)

完全管理型

(Anypoint MQ)

アプリケーション監視

完全管理型

(Anypoint Monitoring)

完全管理型

(Anypoint Monitoring)

完全管理型

(Anypoint Monitoring)

アプリケーションの分離

サポート

サポート

サポート

自動回復

完全管理型

完全管理型

サポート

Mule クラスタリング

サポート

サポート対象外

サポート

自動スケーリング

サポート

サポート

サポート

サポート

VM 管理

MuleSoft

MuleSoft

インフラストラクチャプロバイダー/

公開クラウド

ネットワーク

MuleSoft

MuleSoft

インフラストラクチャプロバイダー/

公開クラウド

アプリケーションの機能

MuleSoft

MuleSoft

MuleSoft/

インフラストラクチャプロバイダー/

公開クラウド

負荷分散およびイングレス

MuleSoft

MuleSoft

自己管理型

バックアップおよび復元

完全管理型

完全管理型

自己管理型

完全管理型 MuleSoft が機能を提供および管理します。 自己管理型 MuleSoft が機能を提供しますが、顧客が機能を管理します。 サポート MuleSoft は機能を提供しませんが、サポート対象パートナープラットフォームで使用できます。機能はベンダー、プラットフォーム、または顧客によって管理されます。 サポート対象外 MuleSoft は機能を提供せず、顧客が機能を設定することはできません。 # CloudHub 2.0 へのアプリケーションのデプロイ CloudHub 2.0 の共有スペースまたは非公開スペースに Mule アプリケーションをデプロイできます。 - [共有スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-shared-space) - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [Exchange からのテストアプリケーションのダウンロード](https://docs.mulesoft.com/jp/cloudhub-2/ch2-download-test-app)
CloudHub 2.0 では、Mule Runtime Engine バージョン 4.3.x 以降がサポートされます。 Mule 3.x はサポートされていません。
## [](#アプリケーションデプロイメント)アプリケーションデプロイメント デプロイメントをトリガーすると、アプリケーションの状況は最終的に ​`RUNNING`​ になります。 アプリケーションの状況が ​`RUNNING`​ に変わらない場合、アプリケーションの状況が ​`RUNNING`​ にならない理由を示す ​`state`​ および ​`reason`​ がレプリカに含まれます。 アプリケーションがデプロイされると、次のイベントが発生します。 1. アプリケーションの想定される状態 (アプリケーションバンドルやレプリカの数など) が保存される。 2. アプリケーションレプリカの状況が ​`PENDING`​ になる。 3. 十分な計算リソースとメモリリソースを使用できる場合、各レプリカがノードに接続される。 4. レプリカの状況が ​`STARTING`​ になる。 5. レプリカがアプリケーションの読み込みを完了する。 6. レプリカの状況が ​`STARTED`​ になり、レプリカが作業を実行できるようになる。 ## [](#アプリケーションデプロイメントの失敗)アプリケーションデプロイメントの失敗 メモリ不足などが原因でアプリケーションが失敗すると、次のイベントが発生します。 1. レプリカの状況が ​`TERMINATED`​ になる。 2. CloudHub 2.0 がすぐにレプリカを再起動しようとする。 3. レプリカの状況が ​`RECOVERING`​ になる。 レプリカを再起動できる場合: 1. レプリカがアプリケーションの読み込みを完了する。 2. レプリカの状況が ​`STARTED`​ になり、レプリカが作業を実行できるようになる。 レプリカを再起動できない場合 (一時的に使用できなくなっているネットワークリソースをレプリカが利用している場合など)、次のイベントが発生します。 1. 「CrashLoopBackoff」を示すメッセージと共に、レプリカの状況が ​`PENDING`​ になる。 CloudHub 2.0 は、過剰な数の再起動が試行されないようにエクスポネンシャルバックオフを使用してレプリカを再起動しようとします。 2. 正常な再起動が妨げている問題が解決するまで、レプリカが ​`RECOVERING`​ と ​`PENDING`​ の状況を繰り返す。 3. レプリカがアプリケーションを読み込む。 正常に再起動すると、レプリカの状況が ​`STARTED`​ になり、レプリカが作業を実行できるようになる。 ## [](#猶予期間)猶予期間 アプリケーションを停止、再起動、更新、再デプロイ、終了すると、CloudHub 2.0 はアプリケーションを Mule から削除しようとします。処理中のメッセージが確実に配信されるように、5 分のタイムアウト期間があります。その期間の後、CloudHub 2.0 はインスタンス全体をシャットダウンします。この猶予期間は、ランタイムではなくアプリケーションインスタンスに適用されます。ランタイムは、独自のシャットダウン設定を使用します。デフォルトでは、ランタイムの猶予期間は 5 秒です。 ## [](#関連情報)関連情報 - [共有スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-shared-space-about) - [非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about) # Exchange からのテストアプリケーションのダウンロード テストする Mule アプリケーションがない場合、Anypoint Exchange からサンプルアプリケーションをダウンロードできます。
Exchange でサンプルアセットを表示するには、Anypoint Platform アカウントにログインする必要があります。
1. Anypoint Platform から ​**\[Exchange\]**​ を選択します。 2. **\[All assets (すべてのアセット)\]**​ リストから、​**\[Provided by MuleSoft (MuleSoft による提供)\]**​ をクリックします。 3. **\[All types (すべての種別)\]**​ メニューから、​**\[Examples (例)\]**​ を選択します。 4. ダウンロードするアプリケーション (​**\[Hello World\]**​ など) をクリックします。 CloudHub 2.0 では、Mule Runtime Engine バージョン 4.3.x 以降がサポートされます。 Mule 3.x はサポートされていません。 5. **\[Download (ダウンロード)\]**​ をクリックします。 ![Exchange の \[Download (ダウンロード)\] ボタン](_images/exchange-app-download.png) Exchange により、アプリケーションの JAR ファイルがローカルシステムにダウンロードされます。 ## [](#関連情報)関連情報 - Exchange の [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) # Log4j を使用したログシステムとのインテグレーション Log4j 設定を使用して、CloudHub 2.0 アプリケーションをログシステムに統合できます。 ## [](#要件と制限事項)要件と制限事項 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、支援しません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 非同期ログアペンダーのみを使用してください。 - FileAppender、RollingFileAppender、AnypointMonitoringFileAppender、RandomAccessFileAppender などのファイルアペンダーは自動的に削除されます。 - カスタム Log4j 設定を使用する場合、Mule Runtime Engine とアプリケーションログの両方を Runtime Manager で引き続き使用できます。 - サードパーティアペンダーのみを使用して、Tracing Module ログを転送することはできません。ログパターンを更新して Anypoint Monitoring に送信することはできません。 任意の Log4j アペンダーを使用できます。 `log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 ## [](#例-splunk-を使用して-log4j-設定を作成する)例: Splunk を使用して Log4j 設定を作成する ログを CloudHub 2.0 で表示可能にし、Splunk に送信するには、​`SplunkHttp`​ Log4j アペンダーを設定します。 Log4j アペンダーを有効にする手順は、次のとおりです。 1. `log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、​`SplunkHttp`​ Log4j アペンダーを含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 ```xml ```
CloudHub 2.0 へのアプリケーションのデプロイにより ​AnypointMonitoringFileAppender​ が自動的に設定されるため、​log4j2.xml​ で設定する必要はありません。
2. 設定に 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 アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [共有スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-shared-space) - [CloudHub Log4j ナレッジ記事](https://help.mulesoft.com/s/global-search/%40uri#q=log4j&t=SalesforceArticle&f:@sfdcproduct=) # Mule Maven プラグインを使用したアプリケーションのデプロイ Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-deploy-maven.adoc - include::mule-runtime::partial$mmp-deploy-to-cloudhub-2.adoc\[\] ## [](#関連情報)関連情報 - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/mmp-concept) # SSL エンドポイントと証明書の設定 CloudHub 2.0 ではロードバランサーを手動で管理する必要はありませんが、各非公開スペースには少なくとも 1 つの証明書が関連付けられている必要があります。クライアントにサービスを提供するロードバランサー用の SSL エンドポイントを設定するには、ロードバランサー用の証明書と非公開鍵のペアを指定します。 各ロードバランサーには、複数の独立した SSL エンドポイントを設定でき、各エンドポイントはサーバー証明書の一般名によって識別されます。 ## [](#始める前に)始める前に SSL エンドポイントを関連付けるには、次のファイルが必要です。 - 暗号化されている、PEM (Privacy-Enhanced Mail) でエンコードされた証明書ファイル。 - PEM 証明書の非公開鍵が含まれるファイル。 ## [](#pem)openssl コマンドを使用した証明書ファイルと非公開鍵の作成 `openssl`​ を使用して、暗号化されている、PEM でエンコードされた証明書ファイルと非公開鍵の両方を作成できます。 たとえば、自己署名証明書と対応する非公開鍵を作成するには、次の手順を実行します。 1. 次のように入力します。 openssl req -newkey rsa:2048 -keyout example-com-private-key.pem -x509 -days 3000 -out example-com-crt.pem -passout pass:examplePassword 2. 証明書の情報の入力を促されたら、入力します。 このコマンドは 2 つの ​`.pem`​ ファイルを作成します。 example-com-crt.pem example-com-private.pem これらの ​`.pem`​ ファイルを Runtime Manager でアップロードするか、または SSL エンドポイントをロードバランサーに追加するときにコマンドラインで渡します。 `-config`​ オプションを使用して、証明書情報の設定ファイルを ​`openssl`​ コマンドに渡すこともできます。 たとえば、​`example-com.cfg`​ という名前のこの証明書設定ファイルには、​`app1.example.com`​ と ​`app2.example.com`​ という Mule アプリケーションのいくつかの SAN (サブジェクト代替名) が含まれている DNS ドメイン ​`example.com`​ が定義されています。 \[ req \] default\_bits = 2048 distinguished\_name = req\_distinguished\_name req\_extensions = req\_ext prompt = no \[ req\_distinguished\_name \] countryName = US stateOrProvinceName = California localityName = San Francisco organizationName = MuleSoft commonName = example.com \[ req\_ext \] subjectAltName = @alt\_names \[alt\_names\] DNS.1 = app1.example.com DNS.2 = app2.example.com 次のコマンドを実行します。 openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem -config example-com.cfg ### [](#ワイルドカード証明書の作成)ワイルドカード証明書の作成 サブドメイン要求をサポートするワイルドカード証明書を作成することができます。たとえば、​`example.com`​ へのサブドメイン要求をサポートすることで、​`app1.example.com`​ や ​`app2.example.com`​、さらにこれから作成されるサブドメイン名を含めることができます。 サブドメイン名を ​`example.com`​ にマップするワイルドカード証明書を作成するには、次の手順を実行します。 1. 次の設定を含むファイルを作成します。 \[ req \] default\_bits = 2048 distinguished\_name = req\_distinguished\_name prompt = no \[ req\_distinguished\_name \] countryName = US stateOrProvinceName = California localityName = San Francisco organizationName = MuleSoft commonName = \*.example.com 2. 証明書設定ファイルを ​`openssl`​ コマンドに渡します。 openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem -config example-com.cfg 3. `openssl`​ を使用して非公開鍵を復号化します。 openssl rsa -in example-com-private.pem -out example-com-private-decrypted.pem ## [](#本番用の証明書の設定)本番用の証明書の設定 通常、本番環境で使用する証明書は、有効な認証機関 (CA) によって署名されています。 各 SSL エンドポイントには、複数の CA 証明書と CRL (証明書失効リスト) を設定できます。暗号化されている、PEM でエンコードされた 1 つのファイルでこれらの各証明書を指定する必要があります。独立した CA 証明書では順序は重要ではありませんが、信頼チェーンの証明書は連結されている必要があります。 # VPN 接続の作成 VPN を使用して非公開ネットワークを外部ネットワークに接続するには、​**\[Network (ネットワーク)\]**​ タブで VPN 接続を作成します。 既存の Anypoint VPN がある場合は、リモート IP を変更して、CloudHub 2.0 で使用するために VPN を再利用します。詳細は、​[Anypoint VPN のドキュメント](https://docs.mulesoft.com/cloudhub/vpn-about)​を参照してください。
VPN を作成した後は、静的ルーティングの静的 IP プレフィックスを除き、VPN 設定を変更することはできません。
## [](#始める前に)始める前に VPN 接続を作成する前に、​[非公開ネットワークを作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#create-private-network)​します。 ## [](#create-vpn)VPN の作成 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ タブで、​**\[Create Connection (接続を作成)\]**​ をクリックします。 4. **\[Create Connection (接続を作成)\]**​ ページで、​**\[VPN\]**​ を選択し、​**\[Connection Name (接続名)\]**​ 項目に​[名前](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#vpn-name)​を入力して、​**\[Next (次へ)\]**​ をクリックします。 接続名には最大 60 文字の英数字 (a-z, A-Z、0-9)、スペース、ハイフン (-) を含めることができます。 Runtime Manager では、接続名で Unicode 文字がサポートされています。 5. **\[Create VPN Connection (VPN 接続を作成)\]**​ ページで、VPN エンドポイントの​[リモート IP アドレス](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#remote-ip-address)​ (1 つの静的 IP アドレス) を入力します。 6. ルーティング種別を選択します。 [Dynamic (BGP) (動的 (BGP))](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#dynamic-vpn-routing)​ デバイスがボーダーゲートウェイプロトコル (BGP) をサポートしている場合、このオプションを選択します。 BGP は、冗長な接続の自動フェールオーバーをサポートしています。 1. **\[Local ASN (ローカル ASN)\]**​ 項目で、ネットワークにまだ割り当てられていない​[ローカル非公開 ASN](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#local-asn)​ を入力します。 この非公開スペースにすでに VPN を作成している場合、​**\[Create VPN Connection (VPN 接続を作成)\]**​ ページに ​**\[Local ASN (ローカル ASN)\]**​ 項目は表示されません。 2. **\[Remote ASN (リモート ASN)\]**​ 項目で、​[リモート非公開 ASN](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#remote-asn)​ を入力します。 [Static (静的)](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#static-vpn-routing)​ デバイスが BGP をサポートしていない場合、このオプションを選択します。 1. **\[Local ASN (ローカル ASN)\]**​ 項目で、ネットワークにまだ割り当てられていない​[ローカル非公開 ASN](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#local-asn)​ を入力します。 ローカル ASN は静的ルーティングには使用されませんが、最初の VPN を作成するときにこの値を指定する必要があります。これは、この非公開スペースに BGP を使用する将来の VPN 接続で必要になるためです。 2. **\[Static Routes (静的ルート)\]**​ 項目で、(カンマ区切りの) ​[静的 IP プレフィックス](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#static-ip-prefixes)​を CIDR 表記で指定します。 **\[Show Existing Routes for this Network (このネットワークの既存のルートを表示)\]**​ をクリックして、非公開ネットワークの既存のルートを表示します。
静的ルートに次の​予約済み CIDR ブロック​との重複を使用することはできません
1. トンネル設定をカスタマイズする場合は、​**\[Advanced Options (詳細オプション)\]**​ を展開します。 1. VPN が自動的に起動するように指定するには、​[**\[Automatic Tunnel Initiation (自動トンネル開始)**](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#auto-tunnel-initiation)\]​ を選択します。 このオプションを選択解除した場合、カスタマーゲートウェイからのトラフィックを生成して VPN トンネルを確立する必要があります。 この非公開スペースにすでに VPN を作成している場合、このオプションは使用できません。 2. トンネル設定を選択します。 - **Automatic (自動)** デフォルトのトンネル設定を使用するには、このオプションを選択します。 - **Custom (カスタム)** カスタマイズするには、このオプションを選択します - 各 VPN トンネルの内部アドレスの ​[IP 範囲](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#inside-ip-cidrs)​ (CIDR 形式)。 - 各 VPN トンネルの​[事前共有キー](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#preshared-keys)​ (PSK)。
4 つすべての項目の値を指定する必要があります。
2. **\[Create VPN (VPN を作成)\]**​ をクリックします。 VPN の作成には最大 15 分かかります。 作成されたら、​[VPN を企業ネットワークに接続](#connect-vpn)​するか、​**\[Close (閉じる)\]**​ をクリックして後でこの手順を完了できます。 VPN が作成されている間、​[冗長 VPN を作成](#create-redundant-vpn)​できます。 VPN の作成に失敗した場合は、​**\[Create VPN (VPN を作成)\]**​ をクリックして再試行します。 . 非公開スペースから VPN への​[接続をテストします](#test-connection)​。 ## [](#connect-vpn)VPN を企業ネットワークに接続する VPN の作成が正常に完了したら、VPN を企業ネットワークに接続するまで、トンネルの状況は ​**\[Down (ダウン)\]**​ になります。 VPN を企業ネットワークに接続するには、ユーザーかネットワーク管理者が Anypoint Platform の外部でゲートウェイデバイスを設定する必要があります。 この設定を容易にするために、ゲートウェイデバイスに関する情報を提供します。この情報は、Anypoint Platform でデバイスの設定に使用する接続ガイドを生成するために使用されます。 VPN 接続の作成が完了したら、​**\[Create VPN Connection (VPN 接続を作成)\]**​ ウィンドウに ​**\[Connect VPN (VPN を接続)\]**​ ステップが表示されます。 このページは、​**\[Network (ネットワーク)\]**​ タブから ​**\[View Connection Guide (接続ガイドを表示)\]**​ をクリックするか、VPN メニュー (​**\[…​\]**​) をクリックして ​**\[Connection Guide (接続ガイド)\]**​ を選択して表示することもできます。 1. ドロップダウンリストからオプションを選択します。 - **Device vendor (デバイスベンダー)** - **Device platform (デバイスのプラットフォーム)** - **Device software (デバイスソフトウェア)** [「サポートされるゲートウェイデバイス」](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#supported-gateway-devices)​を参照してください。 2. **\[Download Connection Guide (接続ガイドをダウンロード)\]**​ をクリックします。 `.txt`​ 形式の接続ガイドがローカルシステムにダウンロードされます。 3. 接続ガイドをネットワーク管理者に渡して、ゲートウェイデバイスの設定に使用するように依頼します。 詳細は、AWS VPN ドキュメントの [「カスタマーゲートウェイデバイス」](https://docs.aws.amazon.com/vpc/latest/adminguide/Welcome.html)​を参照してください。 ## [](#create-redundant-vpn)冗長 VPN を作成する VPN が 1 つしか設定されていない場合、​**\[Network (ネットワーク)\]**​ タブには冗長 VPN を作成するオプションが表示されます。 MuleSoft では、冗長 VPN を作成することを強くお勧めします。 詳細は​[「VPN 高可用性」](https://docs.mulesoft.com/jp/cloudhub-2/ps-vpn-about#vpn-ha)​を参照してください。 冗長 VPN は、最初の VPN 設定からいくつかの設定を自動的に継承します。
冗長 VPN を作成した後は、どの設定も変更できません。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブで、​**\[Create Redundant VPN (冗長 VPN を作成)\]**​ をクリックします。 4. **\[Create Redundant VPN Connection (冗長 VPN 接続を作成)\]**​ ページで、最初の VPN のルーティング種別に基づいて項目に入力します。 Dynamic (BGP) (動的 (BGP)) 1. **\[Remote IP (リモート IP)\]**​ 項目で、VPN エンドポイントの公開 IP アドレス (他の VPN では使用されない 1 つの静的 IP アドレス) を入力します。 2. **\[Remote ASN (リモート ASN)\]**​ 項目で、非公開 ASN を入力します。 デフォルトでは、​**\[Remote ASN (リモート ASN)\]**​ には最初の VPN の値が含まれていますが、この値を変更できます。 Static (静的) **\[Remote IP (リモート IP)\]**​ 項目で、VPN エンドポイントの公開 IP アドレス (他の VPN では使用されない 1 つの静的 IP アドレス) を入力します。 この非公開スペースにはすでに VPN を作成しているため、​**\[Create Redundant VPN Connection (冗長 VPN 接続を作成)\]**​ ページに ​**\[Local ASN (ローカル ASN)\]**​ 項目は表示されません。 5. トンネル設定をカスタマイズする場合は、​**\[Advanced Options (詳細オプション)\]**​ を展開して次の値を指定します。 - 各 VPN トンネルの内部アドレスの IP 範囲 (CIDR 形式)。 - 各 VPN トンネルの PSK。
冗長 VPN は、最初の VPN に指定されたトンネル開始オプションを使用します。
カスタマイズしないトンネル設定値はすべてデフォルトに設定されます。 6. **\[Create VPN (VPN を作成)\]**​ をクリックします。 冗長 VPN の作成には最大 15 分かかります。 冗長 VPN の作成に失敗した場合は、​**\[Create Redundant VPN (冗長 VPN を作成)\]**​ をクリックして再試行します。 ## [](#test-connection)非公開スペースへの接続のテスト VPN を作成したら、CloudHub 2.0 からネットワークへの接続をテストします。 接続をテストするには、ネットワークツールアプリケーションを使用します。 ネットワークツールアプリケーションのダウンロードと使用方法については、 [「How To Use Network Tools Application (ネットワークツールアプリケーションの使用方法)」](https://help.mulesoft.com/s/article/How-To-Use-Network-Tools-Application)​ を参照してください。 ## [](#関連情報)関連情報 - [必要なセットアップ情報の収集](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info) - [Anypoint 仮想プライベートネットワーク](https://docs.mulesoft.com/jp/cloudhub-2/ps-vpn-about) # アプリケーションアラートの設定 _アラート_​は、アプリケーションが期待どおりに動作しているかどうかを示します。CloudHub 2.0 にデプロイされているアプリケーション用に、​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager)​ でアラートを作成できます。 Anypoint Monitoring で、メッセージ数や CPU 使用率などのアプリケーションメトリクスに焦点を絞った基本アラートを作成することもできます。​[基本アラートの作成](https://docs.mulesoft.com/jp/monitoring/basic-alerts)​に関する詳細な案内については、Anypoint Monitoring ドキュメントを参照してください。 ## [](#アラートのレート制限)アラートのレート制限 Anypoint Platform では、アラートをトリガーする頻度を決定するレート制限が適用され、過度なメール送信を回避します。組織あたり 2.5 秒ごとに 1 つのアラート通知メールが送信されるというレート制限があります。 この制限は、組織、環境、アラート (名前または ID)、アプリケーションの組み合わせで適用されます。 ## [](#始める前に)始める前に - デフォルト環境 (プロファイルで定義されています) に「Read Application (アプリケーションの参照)」権限が付与されていることを確認します。 ## [](#configure-custom-app-alerts)カスタムアラートの作成 Runtime Manager で、カスタム通知をアラートにバインドします。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ を選択します。 2. ナビゲーションメニューで ​**\[Alerts (アラート)\]**​ をクリックします。 3. 青色のプラス記号 (​**+**​) をクリックして新しいアラートを作成します。 4. **\[Create an Alert (アラートを作成)\]**​ ページで、カスタムアラートを設定して ​**\[Submit (送信)\]**​ をクリックします。 Name (名前) カスタムアラートのわかりやすい名前を入力します。 Severity level (重要度レベル) アラートに適用する重要度レベルを選択します。 - **Critical (重大)** - **Warning (警告)** - **Info (情報)** Source (提供元) アラートの提供元の ​**\[Application (アプリケーション)\]**​ を選択します。 Application type (アプリケーション種別) **\[CloudHub 2.0 and RTF Applications (CloudHub 2.0 および RTF アプリケーション)\]**​ を選択します。 アプリケーション数 カスタムアラートをトリガーするために設定したフローが含まれるアプリケーションを選択します。 Condition (条件) 次のいずれかを選択します。 - Deployment success (デプロイメントに成功しました): アプリケーションがデプロイされて実行されています。 - Deployment failure (デプロイメントに失敗しました): アプリケーションをデプロイできません。この条件は、アプリケーションがデプロイメントループに陥っている場合ではなく、失敗した場合にのみトリガーされます。 Subject (件名) 通知メールに付ける件名を入力します。 Message (メッセージ) 通知に含めるカスタムメッセージを入力します。 Recipients (受信者) 通知受信者のメールアドレスを入力します。 アラートの ​**\[Subject (件名)\]**​ 項目と ​**\[Message (メッセージ)\]**​ 項目では変数を使用できます。 アラートでの変数の使用については、​[「アラート変数」](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager#alert-variables)​を参照してください。 アラートをトリガーすると、指定された受信者はアプリケーションに追加したカスタムメッセージが含まれるメールを受信します。 ## [](#関連情報)関連情報 - [Anypoint Monitoring の基本アラートのセットアップ](https://docs.mulesoft.com/jp/monitoring/basic-alerts) # アプリケーションスケジュールの管理 Runtime Manager を使用して、実行中のアプリケーションを変更することなく、デプロイされたアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 たとえば、アプリケーションのうちの 1 つがメンテナンス中である間に、スケジュールされたジョブを無効にすることができます。 **\[Schedules (スケジュール)\]**​ タブでは以下を行うことができます。 - 実行中のアプリケーションでスケジュールを表示する。 - アプリケーションでスケジュールを変更する。 - スケジュールを変更せずに、スケジュールされたジョブを直ちに実行する。 - フローのスケジュールを無効または有効にする。 定期的な間隔でトリガーする​_一定間隔_​、または指定した Cron 式に基づいた日時にトリガーする ​_Cron_​ として、Scheduler コンポーネントの種類を設定します。
スケジュールタイプを (一定間隔から Cron、またはその逆に) 変更するには、アプリケーションを更新して再デプロイする必要があります。 デプロイされたアプリケーションのスケジュールタイプを変更することはできません。
アプリケーションスケジュールを表示するには、​「Read Applications (アプリケーションの参照)」​権限に加えて​「Exchange Viewer (Exchange 閲覧者)」​権限が必要です。
## [](#design-schedule)スケジュールの設計に関する考慮事項 スケジュールを設計するときには、次の点を考慮してください。 - ネットワーク障害時の高可用性を計画する。CloudHub 2.0 インフラストラクチャは、ハードウェアの問題や定期メンテナンス、およびセキュリティ更新で再起動します。 サービス更新やセキュリティパッチ適用中、CloudHub 2.0 では既存のスケジュールが完了するまで 5 分待機します。新しいレプリカが起動すると、次のスケジュール時刻にスケジュールが実行されます。詳細は、​[「グローバル設定リファレンス」](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration#global-configurations-reference)​の ​`shutdownTimeout`​ 属性を参照してください。 - セキュリティパッチの適用後、Runtime Manager を介したカスタム設定はアプリケーション設定ファイルよりも優先されます。 スケジューラーをリセットし、API を介してカスタム設定を削除できます。 ```curl DELETE /organizations/{organizationId}/environments/{environmentId}/deployments/{deploymentId}/schedulers/{flowName} ``` - スケジュールが複数回トリガーされる可能性があるため、データ処理の重複を避けるようスケジュールを設計します。 クラスタリングが有効になっていると、実行されているレプリカの数に関係なく CloudHub 2.0 は 1 つのレプリカでスケジュールを実行します。後続のスケジュールは、別のレプリカで実行される可能性があります。CloudHub 2.0 は、レプリカ全体に複数の同時スケジュールを分散します。 - クラスタリングされたアプリケーションの場合、CloudHub 2.0 はプライマリノードでのみスケジュールをトリガーします。 - クラスタリングが有効になっていない場合、スケジュールはすべてのレプリカで個別に実行されます。 - 一定間隔スケジューラーの場合、最小開始遅延は 5 秒にすることをお勧めします。詳細は、​[「Scheduler 要素の無効化または有効化」](https://docs.mulesoft.com/cloudhub-2/ch2-manage-schedules#disable-enable-scheduler)​を参照してください。 - アプリケーションが実行されていないためにスケジュールが実行されていない場合、CloudHub 2.0 はアプリケーションが開始されてもすぐにトリガーしません。スケジュールは、次のスケジュール時刻で実行されます。 - CloudHub 2.0 スケジューラーは、毎回の実行時にジョブ設定を読み取ります。 スケジューラー設定を更新した場合、次回スケジューラーが実行されるときに変更が有効になります。 - スケジュールを変更すると、アプリケーションが再デプロイされます。 - アプリケーションが実行されていない間に過去の時刻にジョブをスケジュールすると、アプリケーションが開始されてもジョブは実行されません。 - スケジュールは、スケジューラーの定義されたタイムゾーンに基づきます。 - 複数のレプリカがあるアプリケーションの場合、CloudHub 2.0 はスケジュールされたジョブをすべてのレプリカで実行します。 **\[Run (実行)\]**​ をクリックしてスケジュールされたジョブを直ちに実行する場合、スケジューラーは 1 つのレプリカで実行されます。 CloudHub 2.0 は、レプリカ全体に複数の同時スケジューラーを分散します。 - スクリプトを使用して CloudHub 2.0 のスケジュールを管理することはできません。 CloudHub 2.0 のスケジュールを管理するには、​**\[Schedules (スケジュール)\]**​ タブまたは CloudHub 2.0 API を使用してください。 - フロー名には、文字、数字、ハイフン (​`-`​)、アンダースコア (​`_`​)、ピリオド (​`.`​) のみを含めることができます。文字 ​`/`​、​`[`​、​`]`​、​`{`​、​`}`​、​`#`​ は無効です。 - デフォルトでは、CloudHub 2.0 のスケジュールは同時に実行されます。スケジューラーは、以前にトリガーされた実行の処理中にスケジュールフローの実行をトリガーします。スケジュールを順番に実行するには、​[scheduler](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#props_scheduler)​ 設定ファイルで ​`disallowConcurrentExecution`​ プロパティを ​`true`​ に設定します。 - デフォルトでは、スケジューラーは Mule が動作しているマシンと同じタイムゾーンを使用します。これは、必要なタイムゾーンを追加して変更できます。詳細は、​[「Cron 式」](https://docs.mulesoft.com/jp/anypoint-code-builder/acb-component-scheduler#cron-expressions)​を参照してください。 ## [](#始める前に)始める前に Runtime Manager のスケジュール機能を使用するには、Anypoint Studio 7.13 を使用して 1 つ以上の Scheduler 要素を含むアプリケーションをデプロイします。 ![Anypoint Studio キャンバスの Scheduler コンポーネント](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-scheduler-studio.png) アプリケーションをデプロイしたら、Runtime Manager でスケジュールを管理できます。 アプリケーションが実行されている必要はありません。 ## [](#runtime-manager-でアプリケーションを表示して管理する)Runtime Manager でアプリケーションを表示して管理する アプリケーションを CloudHub 2.0 にデプロイしたら、Runtime Manager で Scheduler 要素を表示して管理します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 Runtime Manager では、Scheduler 要素がアプリケーションに表示される順序でリストされます。 ![「Schedules (スケジュール)」 ページの (1) フロー名と (2) 頻度リンク。](/mulesoft/current/ja-jp/cloudhub-2/_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/cloudhub-2/_images/ch2-scheduler-fixed-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 ![一定間隔スケジュール設定](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-scheduler-editor-fixed.png) 頻度には、ミリ秒、秒、分、時間、または日を指定できます。 コール間の最小の推奨頻度は 10 秒です。 Unresolved include directive in modules/ROOT/pages/ch2-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/cloudhub-2/_images/ch2-scheduler-cron-rtm.png) 4. 要素の頻度リンクをクリックして、スケジュールエディターを開きます。 5. スケジュールエディターで、スケジュールを変更するか、または ​**\[Enabled (有効)\]**​ (1) チェックボックスをオフにしてスケジュールを無効にします。 ![(1) \[Enabled (有効)\] オプションと (2) \[Quick reference (クイックリファレンス)\] リンクを含む Cron スケジュール設定](_images/ch2-scheduler-editor-cron.png) 6. スケジュールエディターの ​**\[Time Zone (タイムゾーン)\]**​ ドロップダウンメニューからスケジュールのタイムゾーンを選択します。 7. スケジュールエディターで ​**\[Quick reference (クイックリファレンス)\]**​ (3) をクリックして、必須項目と許可される値のテーブルを展開するか折りたたみます。 この例の Cron 式は、10 秒間隔のスケジュールを設定しています。 Cron トリガーの作成についての詳細は、次の方法で確認できます。 1. [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation)​を参照します。 2. バージョンを選択し、​**\[Documentation (ドキュメント)\] > \[User’s Guide (ユーザーガイド)\] > \[Tutorial (チュートリアル)\]**​ をクリックして、​**\[CronTrigger\]**​ レッスンをクリックします。 8. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#run-immediately)スケジュールされたジョブの即時実行 毎晩実行するジョブを今すぐデバッグする場合は、アプリケーションでスケジュールを更新しなくても、実行中のジョブをトリガーできます。実行中のスケジューラーのインスタンス間でジョブをトリガーすると、指定された期間のタイマーがリセットされます。
スケジュールされたジョブを直ちに実行する場合、複数のレプリカがあるアプリケーションの場合でも、スケジューラーは 1 つのレプリカで実行されます。
スケジュールを上書きしてジョブを直ちに実行する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Run (実行)\]**​ をクリックします。 ## [](#disable-enable-scheduler)Scheduler 要素の無効化または有効化 接続しているアプリケーションがメンテナンス中である間に、スケジュールされたジョブを無効にし、メンテナンスの完了後に再度有効にすることができます。 スケジューラーを再度有効にするまで、CloudHub 2.0 はスケジュールされたジョブを実行しません。 **既知の問題**​: スケジューラーを無効にしても、スケジューラーはアプリケーションの起動時に実行されます。スケジューラーが実行されないようにする場合は、Anypoint Studio を使用してアプリケーションで ​`startdelay`​ プロパティを 5 秒に設定します。 Scheduler 要素を無効にする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Schedules (スケジュール)\]**​ をクリックします。 4. 管理する要素を選択してから、​**\[Disable (無効化)\]**​ をクリックします。 スケジュールエディターで ​**\[Enabled (有効)\]**​ を選択解除または選択して、スケジュールを無効または有効にすることもできます。 ![スケジュールエディターので \[Enabled (有効)\] 切り替え](_images/ch2-scheduler-enable.png) ## [](#ローリング更新デプロイメントモデルと再作成デプロイメントモデルのスケジュールの動作)ローリング更新デプロイメントモデルと再作成デプロイメントモデルのスケジュールの動作 クラスターモードとローリング更新デプロイメントモデルが有効になっているアプリケーションの初期デプロイメント中は、アプリケーションの一定間隔スケジューラーがアプリケーションの起動と共に実行されます。​[ローリング更新プロイメントモデルから再作成デプロイメントモデル](https://docs.mulesoft.com/jp/cloudhub-2/ch2-update-apps#rolling-update-vs-recreate-deployment-model)​に切り替えると、スケジューラーはアプリケーションの起動と共に再度トリガーされます。再作成デプロイメントモデルからローリング更新デプロイメントモデルに切り替えると、スケジューラーは起動時に実行されなくなり、代わりに設定された頻度に基づいてトリガーされるようになります。 これは、再作成デプロイメントモデルで以前のアプリケーションインスタンスが無効になり、新しいクラスターで再起動することが原因で発生します。スケジューラーが最後に実行されたときの以前のレコードは保存されません。この場合、固定日付の頻度であるかどうかに関係なく、Mule でスケジューラーが実行されます。ただし、ローリング更新デプロイメントモデルでは、以前の設定が保存されます。 ## [](#関連情報)関連情報 - [CloudHub 2.0 へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy) - [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) # アプリケーションの自動再起動 CloudHub 2.0 は、インフラストラクチャの障害またはメンテナンス、セキュリティパッチの適用、レプリカのクラッシュ、レプリカの再調整時に Mule アプリケーションを再起動します。 CloudHub 2.0 インフラストラクチャでは、トラフィックをアプリケーションレプリカの新しいインスタンスに移行して古いインスタンスを終了する前に接続をドレーンしてグレースフルシャットダウンを実行します。アプリケーション設定で明示的に ​`shutdownTimeout`​ 属性が 2 分 30 秒より大きな値に設定されている場合、シャットダウンの合計猶予期間は 5 分になります。それ以外の場合、猶予期間は設定された ​`shutdownTimeout`​ 値の 2 倍になります。デフォルトでは、​`shutdownTimeout`​ は 5 秒です。​[「グローバル設定リファレンス」](https://docs.mulesoft.com/mule-runtime/latest/global-settings-configuration#global-configurations-reference)​を参照してください。 ```javascript ``` ビジネスに弾力性を持たせるために、羃等性が確保されたアプリケーションを設計して、永続性のレイヤー (​[Object Store v2](https://docs.mulesoft.com/jp/object-store/)​) で​[クラスタリング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​が有効になっている複数のレプリカでデプロイします。 ## [](#インフラストラクチャの障害とメンテナンス)インフラストラクチャの障害とメンテナンス コンピューティングインフラストラクチャに障害が発生すると、CloudHub 2.0 はアプリケーションを健全なインフラストラクチャに移動してアプリケーションレプリカを再起動します。同様に、インフラストラクチャのメンテナンス時は機能停止またはサービス終了になるコンピューティングインフラストラクチャで実行されているアプリケーションレプリカを新しいインフラストラクチャに移行して可用性を確保します。 ## [](#セキュリティパッチの適用)セキュリティパッチの適用 セキュリティの脆弱性を軽減するために、CloudHub 2.0 は毎月アプリケーションにパッチを適用して再起動します。 [「Critical Security Vulnerabilities (重大なセキュリティ脆弱性)」](https://www.salesforce.com/content/dam/web/en_us/www/documents/legal/Agreements/versioning-back-support-policy.pdf#critical)​ポリシーを参照してください。 ## [](#レプリカのクラッシュ)レプリカのクラッシュ 何らかの理由でアプリケーションレプリカがクラッシュすると、CloudHub 2.0 は自動的にそのアプリケーションレプリカを再起動します。それでも起動に失敗する場合、エクスポネンシャルバックオフポリシーを使用して再起動が試行されます。 ## [](#レプリカの再調整)レプリカの再調整 CloudHub 2.0 インフラストラクチャは、レプリカを再調整してアプリケーションの効率を最適化します。2 つ以上のレプリカを使用できる場合、このプロセスでレプリカの移行と再起動が適切に行われます。 再調整時は、最大 30% のアプリケーションのレプリカが同時に再調整されます。この割合は、中断可能なレプリカ数に丸められます。たとえば、アプリケーションの 2 つのレプリカがある場合、中断が 1 つのレプリカに影響すると、設定された 30% を超えます。 この方法により、アプリケーションの設定 (Mule Runtime バージョンやインフラストラクチャなど) の一貫性がすべての再起動の後も保たれます。ただし、セキュリティパッチ適用後の再起動は除きます。セキュリティパッチの適用についての詳細は、[CloudHub 2.0 オペレーティングシステムのパッチ更新](https://docs.mulesoft.com/jp/cloudhub-2/ch2-patch-updates)を参照してください。 # アプリケーションプロパティ値の保護 CloudHub 2.0 を使用すると、Anypoint Runtime Manager でプロパティ名を表示してその値は表示しないことで、アプリケーションのプロパティ値を保護できます。 さらに、この値はどのユーザーも表示または取得できません。 CloudHub 2.0 は、実行時にプロパティを内部的に解決します。 これらの保護されたアプリケーション値は暗号化され、Anypoint Security シークレットマネージャーに保存されます。その後、ユーザー組織ごとに暗号化されます。値は暗号化されているため、Anypoint Security シークレットマネージャーまたは Anypoint Runtime Manager では表示できません。
保護されたプロパティ値は、セキュアな設定ファイルに保存される暗号化された Mule アプリケーションのプロパティとは別のものです。 「Secure Configuration Properties」を参照してください。
## [](#runtime-manager-でプロパティ値を保護する)Runtime Manager でプロパティ値を保護する テーブルビューを介して保護されたプロパティを設定し、各プロパティと値を詳細に制御します。 1 つのプロパティを複数回保護しようとすることはできますが、Runtime Manager によって警告が発行され、そのプロパティの最後のインスタンスのみが保護されます。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. 保護するプロパティの数に応じて、次のいずれかを選択します。 - プロパティを 1 つずつ保護するには、​**\[Table view (テーブルビュー)\]**​ をクリックします。 - 複数のプロパティを保護するには、​**\[Text view (テキストビュー)\]**​ を使用してキー-値ペアを追加し、​**\[Table view (テーブルビュー)\]**​ に切り替え、ステップ 8 に進んでプロパティを保護します。 6. **\[New Key (新しいキー)\]**​ 項目に、保護するプロパティ名を入力します。 7. **\[New Value (新しい値)\]**​ 項目で、プロパティ値を追加します。 8. 値項目で、​**\[Protect (保護)\]**​ をクリックしてから、​**\[Protect value (値を保護)\]**​ をクリックして確定します。 ![「Properties (プロパティ)」 タブの 「Protect (保護)」 ボタン](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-protected-props-protect.png) 9. デプロイメントの状況に応じて、次のいずれかを選択します。 - このアプリケーションがデプロイされている場合、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Properties (プロパティ)\]**​ タブで、ここで保護したプロパティの値は自分にも他のユーザーにも表示されなくなります。 次の例では、​`birthdate`​ と ​`password`​ の値が保護されていますが、​`username`​ の値は保護されていません。 ![アプリケーションの \[Settings (設定)\] ページの \[Properties (プロパティ)\] タブで保護された値](_images/ch2-protected-props.png) 値をコミットし、アプリケーションをデプロイしたら、保護されたプロパティの値はコンソールに表示されなくなります。また、コンソールと CloudHub の間で送受信されることもありません。 ## [](#保護されたプロパティ値を置き換える)保護されたプロパティ値を置き換える プロパティ値の設定後、その値は取得できません。 ただし、保護されたプロパティ値を新しい保護された値に置き換えることができます。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. **\[Table view (テーブルビュー)\]**​ をクリックします。 6. **\[…​\]**​ > ​**\[Replace protected value (保護された値を置換)\]**​ をクリックします。 ![「Replace protected value (保護された値を置換)」 オプション](/mulesoft/current/ja-jp/cloudhub-2/_images/ch2-protected-props-replace.png) 7. 項目に新しい値を入力します。 8. **\[Apply (適用)\]**​ をクリックして、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [セキュア設定プロパティ](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties) - [プロパティを使用したアプリケーションの動作の変更](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-props) - [CloudHub 2.0 へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy) # アプリケーションレベルのエグレスルールの設定 アプリケーションレベルのエグレスルールは、非公開スペースレベルのファイアウォールルールとは無関係です。エグレストラフィックを通過させるには、非公開スペースとアプリケーションの両方のレベルのコントロールを渡す必要があります。 ## [](#始める前に)始める前に - 非公開スペースを設定し、非公開ネットワークのプロビジョニングを完了します。 - 非公開スペースのファイアウォールとアプリケーションレベルのルールを表示するために必要な「CloudHub Network Viewer (CloudHub ネットワーク閲覧者)」権限がアカウントにあることを確認します。 - 非公開スペースのファイアウォールとアプリケーションレベルのルールを変更するために必要な「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限がアカウントにあることを確認します。 ## [](#非公開スペースでアプリケーションレベルのルールを設定する)非公開スペースでアプリケーションレベルのルールを設定する 非公開スペースでアプリケーションレベルのルールを設定する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Firewall rules (ファイアウォールルール)\]**​ タブで、​**\[App-Level Rules (アプリケーションレベルのルール)\]**​ セクションを展開します。 デフォルトでは、新しい非公開スペースを作成するときにアプリケーションレベルのエグレスルール機能は無効になります。機能を有効に切り替えます。 内部 DNS サーバーに到達するトランジットゲートウェイがあり、デフォルトルートがトランジットゲートウェイにルーティングされている場合、非公開 DNS IP アドレスをルートテーブルに追加します。
スイッチを有効化する前に、非公開ネットワークのプロビジョニングを完了したことを確認してください。
**\[App-Level Egress Rules (アプリケーションレベルのエグレスルール)\]**​ を有効に切り替えると、​**\[Default-Egress-Rule-Group (デフォルトのエグレスルールグループ)\]**​ が有効になります。デフォルトのエグレスルールは ​**\[Allow any protocol to any destination (任意の宛先への任意のプロトコルを許可)\]**​ です。 ![アプリケーションレベルのエグレスルール機能を有効に切り替え](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-toggle-app-level-egress.png) デフォルトのエグレスルールグループを変更する手順は、次のとおりです。 1. **\[Edit (編集)\]**​ をクリックします。 2. グループ設定ウィンドウの ​**\[Egress Rules (エグレスルール)\]**​ セクションで、目的のプロトコルと宛先を選択します。 3. **\[Add Rule (ルールを追加)\]**​ をクリックして新しいルールをルールグループに追加します。 削除ボタン (​![「Delete (削除)」 ボタン](/mulesoft/current/ja-jp/cloudhub-2/_images/trash-icon.png)) をクリックすればルールを削除できます。 4. **\[Update Egress Rules (エグレスルールを更新)\]**​ をクリックして変更内容を保存します。 変更は、現在の非公開スペースのすべてのアプリケーションに影響します。 デフォルトのルールグループは名前を変更したり削除したりすることはできません。 ![アプリケーションレベルのエグレスルールグループの編集](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-egress-edit-default.png) 新しいカスタムエグレスルールグループを作成する手順は、次のとおりです。 1. **\[Create Rule Group (ルールグループを作成)\]**​ をクリックします。 2. ルールグループ設定ウィンドウで、グループ名を追加します。 カスタムルールグループは編集したり名前を変更したりできます。生成されるグループ名 (​`-`​) は 53 文字以下になります。 3. **\[Egress Rules (エグレスルール)\]**​ セクションで、​**\[Add Rule (ルールを追加)\]**​ をクリックして追加するすべてのルールのプロトコルと宛先を選択します。 削除ボタン (​![「Delete (削除)」 ボタン](/mulesoft/current/ja-jp/cloudhub-2/_images/trash-icon.png)) をクリックすればルールを削除できます。 4. **\[Create Egress Rules (エグレスルールを作成)\]**​ をクリックして変更内容を保存します。 カスタムルールグループを使用するには、アプリケーション設定で選択します。 既存のカスタムルールグループを削除する手順は、次のとおりです。 1. ​**\[More actions (その他のアクション)\]**​ (​![「More actions (その他のアクション)」 メニュー](/mulesoft/current/ja-jp/cloudhub-2/_images/more-icon.png)) > ​**\[Delete (削除)\]**​ を選択します。 2. 要求されたら、​**\[Delete Rule Group (ルールグループを削除)\]**​ をクリックして削除を確定します。
カスタムルールグループを削除したら、そのカスタムルールグループを使用するアプリケーションではすぐにデフォルトのエグレスルールグループが代わりに使用されるようになります。
![カスタムエグレスルールグループの削除](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-egress-delete-ruleset.png) この機能のスイッチをクリックして、アプリケーションレベルのエグレスルール機能を無効にできます。要求されたら、​**\[Delete and Disable App-Level Rules (アプリケーションレベルのルールを削除して無効化)\]**​ をクリックして確定します。
アプリケーションレベルのエグレスルール機能を無効にしたら、カスタムのアプリケーションレベルのエグレスルールグループがすべて無効になり、すべてのアプリケーションレベルのエグレスがすべてのアプリケーションで許可されます。
## [](#アプリケーションのデプロイ時にアプリケーションレベルのエグレスルールを適用する)アプリケーションのデプロイ時にアプリケーションレベルのエグレスルールを適用する アプリケーションをデプロイするときに、非公開スペースで設定したアプリケーションレベルのエグレスルールを適用できます。 1. アプリケーションを非公開スペースにデプロイするときに、​**\[Firewall Rules (ファイアウォールルール)\]**​ タブを選択します。 2. **\[Egress Rule Group (エグレスルールグループ)\]**​ セクションで、アプリケーションに適用するルールセットを選択します。 3. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#anypoint-mq-へのアプリケーションレベルのエグレス接続の設定)Anypoint MQ へのアプリケーションレベルのエグレス接続の設定 Anypoint MQ への HTTPS 接続を許可するには、次のルールを使用してアプリケーションレベルのエグレスルールグループを追加します。 Anypoint コントロールプレーンへのエグレスを許可: - **Protocol (プロトコル)**​: `HTTPS` - **Destination (宛先)**​: `Custom Domains (カスタムドメイン)` - 値あり: - prod: `anypoint.mulesoft.com` - prod-eu: `eu1.anypoint.mulesoft.com` MQ の宛先へのエグレスを許可: - **Protocol (プロトコル)**​: HTTPS - **Destination (宛先)**​: `Custom Domains (カスタムドメイン)` - MQ コネクタ URL で設定されたドメイン名の値あり たとえば、MQ コネクタ URL が ​`[https://mq-us-east-1.anypoint.mulesoft.com/api/v1/organizations/{{anypointOrgId}}/environments/{{anypointEnvId}}/](https://mq-us-east-1.anypoint.mulesoft.com/api/v1/organizations/{{anypointOrgId}}/environments/{{anypointEnvId}}/)`​ の場合は、​`mq-us-east-1.anypoint.mulesoft.com`​ という値を使用します。 ## [](#object-store-v2-へのアプリケーションレベルのエグレス接続の設定)Object Store v2 へのアプリケーションレベルのエグレス接続の設定 Object Store v2 への HTTPS 接続を許可するには、次のルールを使用してアプリケーションレベルのエグレスルールグループを追加します。 Anypoint コントロールプレーンへのエグレスを許可: - **Protocol (プロトコル)**​: `HTTPS` - **Destination (宛先)**​: `Custom Domains (カスタムドメイン)` - 値あり: - prod: `anypoint.mulesoft.com` - prod-eu: `eu1.anypoint.mulesoft.com` Object Store v2 の宛先へのエグレスを許可: - **Protocol (プロトコル)**​: `HTTPS` - **Destination (宛先)**​: `Custom Domains (カスタムドメイン)` - 値あり: - prod: `object-store-us-east-1.anypoint.mulesoft.com` - prod-eu: `eu1.anypoint.mulesoft.com` この URL はリージョンによって異なります。たとえば、​`ap-southeast-1`​ のオブジェクトストアにアクセスするには、URL ​`object-store-ap-southeast-1.anypoint.mulesoft.com`​ を値として追加します。 `salesforce.com`​ が ​`www.salesforce.com`​ にリダイレクトされる場合など、リダイレクトが含まれるドメインのエグレスを有効にする場合は、元の対象である ​`salesforce.com`​ とリダイレクト後の対象である ​`www.salesforce.com`​ の両方のエグレスを許可してください。 ワイルドカードレコードはサポートされていません。たとえば、​`salesforce.com`​ では ​`example.salesforce.com`​ が自動的にカバーされません。

連続した 2 つのハイフンが含まれるドメインは有効にできません。たとえば、​abc—​xyz.com​ です。

同じ IP アドレスのドメインは一緒に処理されます。1 つのドメインを許可すると、同じドメインがすべて許可されます。

## [](#api-manager-へのアプリケーションレベルのエグレス接続の設定)API Manager へのアプリケーションレベルのエグレス接続の設定 API Manager にアプリケーションレベルのエグレスのサポートを追加するには、次のルールを使用してカスタム ルール グループを追加し、Anypoint コントロールプレーンへのエグレスを許可してください。 - **Protocol (プロトコル)**​: `HTTPS` - **Destination (宛先)**​: `Custom Domains (カスタムドメイン)` - 値あり: - prod: - `anypoint.mulesoft.com` - `exchange-files.anypoint.mulesoft.com` - `analytics-ingest.anypoint.mulesoft.com` - prod-eu: - `eu1.anypoint.mulesoft.com` - `exchange-files.eu1.anypoint.mulesoft.com` - `analytics-ingest.eu1.anypoint.mulesoft.com` ユースケースに応じて、Anypoint Platform のホスト名やポートを追加して、MuleSoft が管理するオンライン Anypoint Platform の API やサービスとアプリケーションが通信できるようにします。[ポート、IP、ホスト名の許可](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-hostnames)を参照してください。

Anypoint MQ、Object Store v2、または API Manager へのアプリケーションレベルのエグレス接続を設定する際には、非公開スペースレベルで個別にすべての 443 ポートへのアウトバウンドアクセスも許可する必要があります。443 ポートへのアウトバウンドアクセスの許可についての詳細は、非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定にアクセスしてください。

非公開スペースの内部 DNS でカスタムドメインは使用できません。

## [](#パフォーマンスへの影響)パフォーマンスへの影響 検証が一層強化されることになるため、アプリケーションレベルのエグレスルールを使用することで、アプリケーションの接続に対して 3 ~ 10 ミリ秒のネットワークレイテンシーが発生する可能性はあります。セキュリティとパフォーマンスのバランスを取る方法は、次のとおりです。 - 非公開スペースで有効なルールグループを 20 個に制限する。 - ルールグループ毎に使用するルールを最大 40 個にする。 - ルールグループとルールの組み合わせの合計を 800 個に制限する。 組み合わせにおけるルールグループとルールの数は、ニーズに合わせてカスタマイズできます。 これらの方法により、レイテンシーを最適化してネットワークセキュリティを効果的に保つことができます。
DNS レコードのタイミングの問題により、予期しない接続エラーが発生する場合があります。Mule アプリケーションの信頼性を高めるには、堅牢なエラー処理と接続再試行のメカニズムを実装してください。
## [](#関連情報)関連情報 - [非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about) - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules) - [Anypoint MQ の概要](https://docs.mulesoft.com/jp/mq/) - [Object Store v2 の概要](https://docs.mulesoft.com/jp/object-store/) - [Anypoint API Manager](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept) # アプリケーションログの管理 ログは、共有スペースと非公開スペースのどちらにデプロイされたアプリケーションでも使用できます。 組織に Titanium サブスクリプションがある場合、Anypoint Monitoring を使用して、より高度な検索とログ管理を行うことができます。詳細は、[Anypoint Monitoring の概要](https://docs.mulesoft.com/jp/monitoring/)を参照してください。 ## [](#configure-logging)アプリケーションのログの設定 CloudHub 2.0 にデプロイされたアプリケーションの場合、デフォルトでログが有効になっています。 ### [](#ログを無効化または有効化する)ログを無効化または有効化する アプリケーションのログを無効化または再有効化する手順は、次のとおりです。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Forward application logs to Anypoint Platform (Anypoint Platform にアプリケーションログを転送)\]**​ オプションを選択解除または選択します。 3. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ログを無効にしても、Runtime Manager ナビゲーションメニュー ​**\[Logs (ログ)\]**​ ヘッダーが引き続き表示されますが、アプリケーションログは収集されません。 ### [](#ログレベルおよびカテゴリを設定する)ログレベルおよびカテゴリを設定する ログに含める追加のログレベルとカテゴリを設定する手順は、次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. ログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (重要)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 3. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 4. **\[Apply Changes (変更を適用)\]**​ をクリックします。
ログレベルを変更して ​[Apply Changes (変更を適用)]​ をクリックすると、アプリケーションが再起動します。
## [](#関連情報)関連情報 - [Log4j を使用したログシステムとのインテグレーション](https://docs.mulesoft.com/jp/cloudhub-2/ch2-integrate-log-system) - [デプロイ済みアプリケーションのログデータの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-logs) - [Anypoint Monitoring の概要](https://docs.mulesoft.com/jp/monitoring/) # クラスタリング クラスタリングを使用すると、CloudHub 2.0 のアプリケーションで拡張性、ワークロードの分散、信頼性の向上を実現できます。 この機能は、CloudHub の拡張性の高い負荷分散サービスおよびレプリカのスケールアウトによって提供されます。 新しいアプリケーションをデプロイするときや、既存のアプリケーションを再デプロイするときに Anypoint Runtime Manager コンソールを使用して、アプリケーションごとにクラスタリング機能を有効にできます。 ## [](#高可用性およびクラスタリング)高可用性およびクラスタリング _高可用性_​とは、クラスタリングとは異なり、各レプリカ間でデータを共有しない複数のレプリカがあることを指します。 _クラスタリング_​では、複数のレプリカが相互に通信し、メモリを共有しているためにデータを共有できます。 ### [](#cloudhub-2-0-クラスタリングおよび-object-store-v2)CloudHub 2.0 クラスタリングおよび Object Store v2 CloudHub 2.0 は、Mule 4 アプリケーション用 Object Store v2 に加えて、Mule を使用したクラスタリングをサポートしています。CloudHub 2.0 で Object Store v2 を有効にする場合、レート制限がある点に注意してください。詳細は、[Object Store v2 の概要](https://docs.mulesoft.com/jp/object-store/)を参照してください。 CloudHub 2.0 でオブジェクトストアを使用するようにアプリケーションを設定する必要はありません。さらに、Mule 4 アプリケーションでは、Anypoint Runtime Manager コンソールから有効化できる Object Store v2 がサポートされています。 ## [](#始める前に)始める前に クラスタリングでは、以下が必要です。 - Anypoint Integration Advanced パッケージ、または Anypoint Platform の Platinum または Titanium サブスクリプション - この機能を使用できる CloudHub Enterprise または Partner アカウント種別。 - Runtime Manager を使用したアプリケーションのデプロイについての理解。 ## [](#replica-scale-out)レプリカのスケールアウト CloudHub 2.0 では、アプリケーションの vCore オプションを選択して、水平方向に拡張できます。 このように計算能力のプロビジョニングを詳細に制御できるため、高い負荷に対処する場合はアプリケーションをスケールアップし、負荷が低い期間はスケールダウンするという作業を任意のタイミングで柔軟に行うことができます。 最大 8 個 (Anypoint Integration Advanced パッケージや、Anypoint Platform の Platinum または Titanium サブスクリプションがある場合は最大 16 個) のレプリカを使用してアプリケーションをデプロイできます。 十分なリソースがあることを確認するには、​[「CloudHub 2.0 レプリカ」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-architecture#cloudhub-2-replicas)​を参照してください。 レプリカのスケールアウトにより、信頼性も向上します。 Mule Runtime Engine (Mule) は、自動的に同じアプリケーションで複数のレプリカを 2 つ以上のデータセンターで分散し、最大限の信頼性を確保します。 アプリケーションを 2 つ以上のレプリカにデプロイすると、それらの Mule インスタンスでワークロードを分散できます。 CloudHub では、割り当てたレプリカで HTTP 要求を自動的に分散する、次の HTTP 負荷分散サービスが提供されます。 バッチジョブは、一度に 1 つのレプリカでのみ実行され、複数のレプリカで分散できません。 同じデプロイメントで Mule が再起動すると、その状況は保持され、バッチの処理が続行されます。 バッチの実行中にアプリケーション全体が更新または再デプロイされると、残りのバッチジョブは続行されません。 CloudHub 2.0 の永続的なバッチジョブの主な解決策は、[Object Store v2 の概要](https://docs.mulesoft.com/jp/object-store/)を参照してください。 Kubernetes では、水平ポッド自動スケーリング (HPA) により、需要に合わせてワークロードをスケーリングするために、ワークロードリソースが自動的に更新されます。水平スケーリングでは、負荷の増加に対応してより多くのポッドが自動的にデプロイされます。これらの定期的な自動スケーリング操作により、ユーザーアクションなしでアプリケーションを新しいレプリカに変更できます。 ## [](#クラスタリング機能の有効化)クラスタリング機能の有効化 次の 2 つのいずれかの方法でクラスターモードおよび水平自動スケーリングのいずれかまたは両方を有効/無効にできます。 - 初めてアプリケーションを CloudHub 2.0 にデプロイする場合は、Runtime Manager 使用します。 - **\[Runtime (ランタイム)\]**​ タブの ​**\[Replica Count (レプリカ数)\]**​ および ​**\[Replica Size (レプリカサイズ)\]**​ ドロップダウンメニューを使用して、vCore オプションを選択し、必要な計算能力を設定します。 - **\[Runtime Options (ランタイムオプション)\]**​ セクションで ​**\[Run in Runtime Cluster Mode (ランタイムクラスターモードで実行)\]**​ をオンにして、アプリケーションの各レプリカで Mule クラスタリングを有効にします。このオプションには、少なくとも 2 つのレプリカが必要です。 - 以前にアプリケーションをデプロイしている場合は、​**\[Deployment Target (デプロイメント対象)\]**​ タブの ​**\[Replica Count (レプリカ数)\]**​ および ​**\[Replica Size (レプリカサイズ)\]**​ ドロップダウンメニューを使用します。 - **\[Runtime Options (ランタイムオプション)\]**​ セクションで ​**\[Run in Runtime Cluster Mode (ランタイムクラスターモードで実行)\]**​ をオンにして、アプリケーションの各レプリカで Mule クラスタリングを有効にします。このオプションには、少なくとも 2 つのレプリカが必要です。 複数のレプリカへのデプロイについての詳細は、​[「CloudHub 2.0 レプリカ」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-architecture#cloudhub-2-replicas)​を参照してください。 アプリケーションがすでにデプロイされている場合、新しい設定を有効にするには、再デプロイする必要があります。 ## [](#高可用性の実装方法)高可用性の実装方法 HTTP 負荷分散は、内部リバースプロキシサーバーで実装されます。 アプリケーション (ドメイン) URL への要求は、自動的にすべてのアプリケーションのレプリカ URL で負荷分散されます。 ## [](#クラスタリングの実装方法)クラスタリングの実装方法 クラスタリングを有効にすると、Mule アプリケーションのすべてのレプリカがユニットとして機能します。クラスターとは複数のレプリカで構成された仮想サーバーです。クラスター内のノードは分散された共有メモリグリッドを通じて通信を行い、情報を共有します。つまり、データがさまざまなレプリカのメモリ間で複製されます。 詳細は、[On-Premises Mule Runtime High Availability Cluster Overview](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters)を参照してください。 ## [](#ユースケース)ユースケース 単一のアプリケーションで、クラスタリング機能を組み合わせることができます。
ユースケース 推奨されるクラスタリング設定 影響

アプリケーションをスケールアウトしたいが、サービスの中断とメッセージの損失については、既存の可用性の高い CloudHub 2.0 アーキテクチャに満足している。Mule スケジュールが同時に複数回実行されることに同意しており、競合を回避するために、スケジュールフローは羃等であることが望ましい。

レプリカの数: 2 つ以上
クラスタリングは有効になっていない

  • キューのレイテンシーによるアプリケーションパフォーマンスへの影響はない。

  • キューをサポートするようにアプリケーションを設定する必要はない。

  • アプリケーションスケジュールはすべてのレプリカで独立して実行される。

  • オブジェクトストアはレプリカ間で共有されない。

  • オブジェクトが 1 つのレプリカに書き込まれる場合、クラウドオブジェクトストアが使用されていないと、レプリカでオブジェクトが参照されない。

  • 1 つのデータセンターが停止しても、別のデータセンターでレプリカを使用できる。

メッセージの損失に対する保護が必要な大きな利害が関係するプロセスがあるが、処理負荷の対処に問題は発生しておらず、データセンターが停止した場合に一部のサービスが中断されても問題はない。

レプリカの数: 1 つ
クラスタリングは有効になっている

  • アプリケーションでキューのレイテンシーが発生する可能性がある。

  • デプロイする前にキューをサポートするようにアプリケーションを設定する。

  • アプリケーションスケジュールは 1 つのレプリカで 1 回実行される。

  • アプリケーションランタイムが実行時に使用できない場合、アプリケーションスケジュールが実行されない可能性がある。

  • レプリカが動作しているデータセンターが停止すると、CloudHub 2.0 によって自動的にアプリケーションが別の可用性ゾーンに移行される。移行時にダウンタイムが発生する場合もありますが、キューにより、メッセージの損失はありません。

メッセージの損失に対する保護が必要な大きな利害が関係するプロセスがあり、サービスの中断を避けて、大きな処理負荷に対処する。

レプリカの数: 2 つ以上
クラスタリングは有効になっている

  • アプリケーションでキューのレイテンシーが発生する可能性がある。

  • デプロイする前にキューをサポートするようにアプリケーションを設定する必要がある。

  • アプリケーションスケジュールはプライマリレプリカで 1 回のみ実行される。

  • リード選択時にアプリケーションスケジュールが実行されない可能性がある。

  • 1 つのデータセンターが停止すると、レプリカが自動的に分散されて冗長性が確保される。

処理負荷やメッセージの損失に関して特殊な要件のないアプリケーションがある。

レプリカの数: 1 つ
クラスタリングは有効になっていない

  • キューのレイテンシーによるアプリケーションパフォーマンスへの影響はない。

  • キューをサポートするようにアプリケーションを設定する必要はない。

  • アプリケーションスケジュールは 1 つのレプリカで 1 回実行される。

  • オブジェクトストアは複製されて各レプリカと共有される。

  • すべてのレプリカは、クラウドオブジェクトストアの有無に関係なく、別のレプリカによって書き込まれたオブジェクトを読み取ることができる。

  • レプリカが動作しているデータセンターが停止すると、CloudHub 2.0 によって自動的にアプリケーションが別の可用性ゾーンに移行されるが、移行時にダウンタイムやメッセージの損失が発生するが場合がある。

## [](#関連情報)関連情報 - [CloudHub 2.0 アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-architecture) - [Object Store v2 の概要](https://docs.mulesoft.com/jp/object-store/) # デプロイ済みアプリケーションのログデータの表示 CloudHub 2.0 により、各レプリカのデプロイメントのメッセージとイベントおよび Mule Runtime Engine ログを含むログデータへのアクセスが可能になります。 より高度な検索とログ管理の場合、Anypoint Monitoring を使用できます (Titanium サブスクリプションが必要)。 「[Anypoint Monitoring の概要](https://docs.mulesoft.com/jp/monitoring/)」を参照してください。 CloudHub 2.0 では、ログデータは、設定あたり最大 100 MB または最長 30 日間のいずれかの制限に達するまで保存されます。 ログは、対応するクラスターがデプロイされているリージョンに保存されます。
CloudHub 2.0 では、ログデータは協定世界時 (UTC) で保存されますが、コンソールにはコンピューターのローカルタイムゾーンを使用してログが表示されます。
## [](#ログを表示する)ログを表示する 非公開スペースにデプロイされたアプリケーションのログを表示する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 ログページには、選択した設定のすべてのレプリカのすべてのログが表示され、最新のメッセージが下部に表示されます。 設定は、最後の更新以降のデプロイメントを表します。
アプリケーションを更新すると、新しい設定が作成されます。 この場合、ログページは空の可能性があります。
ページでは、最後にデプロイされたセクションが閉じられていない限り、発生したログメッセージがストリーミングされます。 最終更新時刻より前のログは、以前のデプロイメントを含むドロップダウンに表示されます。 各メッセージには、重要度、時間 (相対および絶対)、レプリカ名が含まれます。 別の設定のログを表示するには、​**\[Config (設定)\]**​ ドロップダウンリストをクリックして設定を選択します。 設定の表示ラベルは、デプロイメントの相対的な時間 (10 時間前など) を示します。 ## [](#ログを検索する)ログを検索する 現在表示されている設定内を検索する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 4. **\[Search (検索)\]**​ 項目に検索語を入力します。 結果表示には、現在選択されている設定、レプリカ、およびログレベルが含まれます。 クエリを使用して検索できます。詳細は、「[ログ検索クエリ構文](https://docs.mulesoft.com/jp/cloudhub-2/ch2-log-search-syntax)」を参照してください。 ## [](#ログを絞り込む)ログを絞り込む ログ結果を絞り込む手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 4. 検索条件オプションを選択します。 - 設定 ID でログを絞り込む **\[Config (設定)\]**​ ドロップダウンメニューをクリックして、表示する設定を選択します。 - **レプリカでログを絞り込む** 目的のレプリカのログメッセージで、レプリカの名前をクリックします。 選択したレプリカのログのみが表示されます。 レプリカの検索条件をクリアしてすべてのレプリカのログを表示するには、選択したレプリカの ​**\[X\]**​ ボタンをクリックします。 - **日時と時間範囲でログを絞り込む** **\[Time Range (時間範囲)\]**​ をクリックし、日付範囲と必要に応じて時間を選択して、​**\[Apply (適用)\]**​ をクリックします。 **\[Time Range (時間範囲)\]**​ ボタンの表示ラベルが変わり、選択した日時の範囲が表示されます。 - **ログレベルでログを絞り込む** **\[Log Levels (ログレベル)\]**​ をクリックし、表示するログレベルを確認します。 - **Fatal (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ - **Error (エラー)**​: 例外が発生した場合などのエラーメッセージ - **Warn (警告)**​: 警告メッセージ - **Info (情報)**​: 有益情報のメッセージ - **Debug (デバッグ)**​: デバッグメッセージ
デプロイメントの動的ログレベル設定によっては、一部のログレベルを使用できない場合があります。
**\[Log Levels (ログレベル)\]**​ ボタンの表示ラベルが変わり、選択した数のログレベルが表示されます。 ## [](#ログをダウンロードする)ログをダウンロードする 現在の検索条件に基づいてログをダウンロードする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 4. \[ダウンロード\] ボタンをクリックします。 CloudHub 2.0 により、現在の検索条件、および 16 進形式の命名規則と ​`log`​ を使用して、ログ出力がダウンロードされます (例: `c6c671_462ccf_2022-07-21T20-08-32X.log`​)。ログファイルを表示するには、テキストエディターを使用します。 ## [](#関連情報)関連情報 - [デプロイ済みアプリケーションの診断データの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-diag) - [CloudHub 2.0 にデプロイされたアプリケーションの更新](https://docs.mulesoft.com/jp/cloudhub-2/ch2-update-apps) # デプロイ済みアプリケーションの診断データの表示 レプリカ内のすべてのスレッドのスナップショットであるスレッドダンプを実行できます。 スレッドダンプはサーバーの現在の状態を示し、デバッグとサポートに役立ちます。 CloudHub 2.0 は、スレッドダンプを 30 日間または最大 100 MB 保持します。 ## [](#スレッドダンプを実行する)スレッドダンプを実行する
スレッドダンプを実行するには、アプリケーションが実行されている必要があります。
スレッドダンプを実行する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Diagnostics (診断)\]**​ をクリックします。 4. **\[Run Thread Dump (スレッドダンプを実行)\]**​ をクリックし、ドロップダウンリストからスレッドダンプをトリガーするアクティブなレプリカを選択します。 ![\[Diagnostics (診断)\] タブの \[Run Thread Dump (スレッドダンプを実行)\] ボタン](_images/ch2-thread-dump-run.png) CloudHub 2.0 によりスレッドダンプが実行され、最新のスレッドダンプがリストの一番上に表示されます。 スレッドダンプをダウンロードする準備ができたときに、​**\[Download (ダウンロード)\]**​ ボタンが使用可能になります。 ## [](#過去のスレッドダンプを表示してダウンロードする)過去のスレッドダンプを表示してダウンロードする 過去のスレッドダンプを表示する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Diagnostics (診断)\]**​ をクリックします。 このページには、過去のスレッドダンプが表示されます。 ![\[Diagnostics (診断)\] タブのスレッドダンプ](_images/ch2-thread-dumps.png) - スレッドダンプに関連付けられたデプロイメントとレプリカのログを表示するには、​**\[Replica (レプリカ)\]**​ 列の ​**\[View Logs (ログを表示)\]**​ リンク (1) をクリックします。 - スレッドダンプをダウンロードするには、​**\[Download (ダウンロード)\]**​ ボタン (2) をクリックします。 CloudHub 2.0 により、診断出力が 16 進形式でテキストファイルに保存されます (例: `5b181bef-b61c-524c-a0c8-698592977954_2022-07-20T15-06-27D`​)。診断ファイルを表示するには、テキストエディターを使用します。 ## [](#関連情報)関連情報 - [デプロイ済みアプリケーションのログデータの表示](https://docs.mulesoft.com/jp/cloudhub-2/ch2-view-logs) # トランジットゲートウェイアタッチメント AWS トランジットゲートウェイは AWS のクラウドルーターとして機能し、非公開スペース、オンプレミスデータセンター、サードパーティソフトウェア間のネットワークアクセスを簡略化すると同時に、ネットワークの可視性を高め、制御を強化します。 トランジットゲートウェイは、事実上組織のクラウドリソースとオンプレミスデータセンターを 1 つのネットワークトポロジーにマージするものです。 CloudHub 2.0 では、非公開スペースを AWS アカウントの AWS トランジットゲートウェイに安全にアタッチすることで、このネットワークの簡略化を活用できます。 複数のトランジットゲートウェイを Anypoint Platform 組織に追加できます。 追加できるトランジットゲートウェイの数は、アカウントで利用できるネットワーク接続エンタイトルメントによって異なります。 自分のアカウントに割り当てられているエンタイトルメントが不明な場合は、MuleSoft アカウント担当者までお問い合わせください。 トランジットゲートウェイアタッチメントを使用するには、非公開スペースと AWS トランジットゲートウェイが同じリージョンにある必要があります。 ![トランジットゲートウェイの概要](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-overview-tgw.png) 非公開スペースをトランジットゲートウェイにアタッチするには、​[「外部ネットワークへの接続を作成する」](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#create-connection-to-external-network)​を参照してください。 ## [](#制限事項)制限事項 次の制限事項は AWS の制限を受けます。 - VPC ごとのトランジットゲートウェイの最大数 - トランジットゲートウェイにアタッチできる VPC の最大数 VPC をトランジットゲートウェイにアタッチする場合の制限については、AWS ドキュメントの [「Transit gateway attachments to a VPC (VPC へのトランジットゲートウェイアタッチメント)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)​を参照してください。 ## [](#関連情報)関連情報 - AWS ドキュメントの [「What is a transit gateway? (トランジットゲートウェイとは?)」](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) - AWS ドキュメントの [「Transit gateway route tables (トランジットゲートウェイのルートテーブル)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) # トランジットゲートウェイアタッチメントの作成 トランジットゲートウェイを非公開スペースにアタッチすると、CloudHub 2.0 は、Amazon Web Services (AWS) の接続を表す​_トランジットゲートウェイアタッチメント_​を作成します。同じトランジットゲートウェイを独自の AWS アカウントのオンプレミス VPC にアタッチして、非公開スペースと VPC 間の通信を有効にできます。複数の非公開スペースを内部 VPC に接続できます。 トランジットゲートウェイアタッチメントを再利用するには、別の非公開スペースをそのアタッチメントに接続して受け入れます。 リソース共有を再度作成する必要はありません。 ## [](#始める前に)始める前に - トランジットゲートウェイアタッチメントを作成する前に、​[非公開ネットワークを作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#create-private-network)​します。 - 非公開スペースは、トランジットゲートウェイアタッチメントを作成するリージョンと同じリージョンに属していることを確認します。リージョン間のピアリングはサポートされていません。 たとえば、リージョン A のトランジットゲートウェイアタッチメントをリージョン B に属する非公開スペースにアタッチすることはできません。
トランジットゲートウェイアタッチメントを作成する前に、インフラストラクチャ (ファイアウォール、ルート、接続など) を更新します。トランジットゲートウェイが受け入れの保留中の場合、すべてのインフラストラクチャの更新は、添付ファイルを受け入れるまで延期されます。
## [](#connect-tgw)トランジットゲートウェイに接続する VPC をトランジットゲートウェイにアタッチする場合の制限については、AWS ドキュメントの [「Transit gateway attachments to a VPC (VPC へのトランジットゲートウェイアタッチメント)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)​を参照してください。 トランジットゲートウェイに接続する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ タブで、​**\[Create Connection (接続を作成)\]**​ をクリックします。 4. **\[Create Connection (接続を作成)\]**​ ページで、​**\[Transit Gateway (トランジットゲートウェイ)\]**​ を選択します。 CloudHub 2.0 が組織内の既存のトランジットゲートウェイを検出した場合は、トランジットゲートウェイを選択するか、​**\[Add a new transit gateway (新しいトランジットゲートウェイを追加)\]**​ をクリックして ​**\[Connection Name (接続名)\]**​ 項目に​[名前](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#transit-gateway-name)​を入力します。 AWS のトランジットゲートウェイに同じ名前を使用します。 この名前は後から変更できます。 接続名には最大 60 文字の英数字 (a-z, A-Z、0-9)、スペース、ハイフン (-) を含めることができます。 Runtime Manager では、接続名で Unicode 文字がサポートされています。 5. **\[Next (次へ)\]**​ をクリックします。 既存のトランジットゲートウェイを選択したか、新しいトランジットゲートウェイを追加しているかに応じて、​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページに AWS でリソース共有を作成する手順がリストされます。 1. [ルートを設定する](#configure-tgw-routes)​。 2. [リソース共有を作成する](#create-resource-share)​。(新しいゲートウェイのみ) 3. [リソース共有を検証する](#verify-resource-share)​。(新しいゲートウェイのみ) 4. [アタッチメントを受け入れる](#accept-tgw-attachment)​。 ## [](#configure-tgw-routes)ルートを設定する **\[Static Routes (静的ルート)\]**​ で、トランジットゲートウェイ経由で接続する外部ネットワークの IP プレフィックスを入力し、​**\[Next (次へ)\]**​ をクリックします。 AWS の非公開 VPC と CloudHub 2.0 の非公開スペースの間でトラフィックが流れるように、ルートは VPC CIDR 範囲と一致する必要があります。 トランジットゲートウェイをアタッチしたら、ここで指定したルートが非公開スペースに含まれます。 ネットワークの既存のルートを表示するには、​**\[Show Existing Routes for this Network (このネットワークの既存のルートを表示)\]**​ をクリックします。 後でルートを追加または削除できます。 詳細は、​[「ルートテーブルへのルートの追加または削除」](https://docs.mulesoft.com/jp/cloudhub-2/ps-manage#add-remove-routes)​を参照してください。 ## [](#create-resource-share)リソース共有を作成する 1. 別のブラウザーウィンドウで、AWS 企業アカウントにサインインします。 2. Anypoint Platform で、​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページの ​**\[Create Resource Share (リソース共有を作成)\]**​ リンクをクリックします。 このリンクにより、非公開スペースに指定したリージョンでリソース共有を作成するためのページへの AWS RAM コンソールが開きます。 3. AWS の ​**\[Create resource share (リソース共有を作成)\]**​ ページで次のアクションを実行します。 1. **\[Description (説明)\]**​ の ​**\[Name (名前)\]**​ 項目にリソース共有のわかりやすい名前を入力します。 2. **\[Resources - ​_optional_​ (リソース - 省略可能)\]**​ で、​**\[Select resource type (リソース種別を選択)\]**​ メニューから ​**\[Transit Gateways (トランジットゲートウェイ)\]**​ を選択し、共有するトランジットゲートウェイリソースを選択します。 トランジットゲートウェイ ID が ​**\[Selected resources (選択したリソース)\]**​ 項目に表示されます。 3. **\[Principals - ​_optional_​ (プリンシパル - 省略可能)\]**​ で、​**\[Allow external accounts (外部アカウントを許可)\]**​ が選択されていることを確認し、Anypoint Platform の ​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページに表示される MuleSoft AWS アカウント ID を入力し、​**\[Add (追加)\]**​ をクリックします。 AWS アカウント番号が ​**\[Selected principals (選択したプリンシパル)\]**​ 項目に表示されます。 4. 必要に応じて、​**\[Tags (タグ)\]**​ でタグを追加します。 5. **\[Create resource share (リソース共有を作成)\]**​ をクリックします。 6. 作成したばかりのリソース共有の ​**\[ID\]**​ 値と ​**\[Owner (オーナー)\]**​ 値をコピーします。 7. **\[Next (次へ)\]**​ をクリックします。 ## [](#verify-resource-share)リソース共有を検証する 1. Anypoint Platform の ​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページで、AWS からコピーした値を ​**\[ID\]**​ 項目と ​**\[Owner (オーナー)\]**​ 項目に貼り付けます。 - リソース共有の ​**\[ID\]**​ 項目には英数字 (a-z、A-Z、0-9) およびハイフン (-) を使用できます。 - リソース共有の ​**\[Owner (オーナー)\]**​ 項目には数値しか使用できません。 2. **\[Next (次へ)\]**​ をクリックします。 CloudHub 2.0 は、指定したリソース共有のオーナーと ID を使用して、AWS で関連付けられたトランジットゲートウェイを非公開スペースにアタッチします。 アタッチメントが成功すると、​`「Attachment Created (アタッチメントが作成されました)」`​というメッセージが表示され、​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページに戻されます。 ## [](#accept-tgw-attachment)アタッチメントを受け入れる 1. **\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページで、​**\[Transit Gateway Attachments (トランジットゲートウェイアタッチメント)\]**​ リンクをクリックします。 このリンクにより、指定したリージョンでトランジットゲートウェイアタッチメントを受け入れるためのページへの AWS RAM コンソールが開きます。 2. **\[Transit Gateway Attachments (トランジットゲートウェイアタッチメント)\]**​ ページで、​**\[State (状態)\]**​ 列に ​**\[pending acceptance (受け入れの保留中)\]**​ と表示されているアタッチメントを選択します。 アタッチメントが表示されるまで数分かかる場合もあります。 アタッチメントが正しいことを検証するには、トランジットゲートウェイアタッチメント ID を選択し、​**\[Details (詳細)\]**​ タブで、​**\[Resource owner account ID (リソースオーナーアカウント ID)\]**​ が ​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページの MuleSoft AWS アカウント ID であることを確認します。 3. **\[Actions (アクション)\]**​ メニューから、​**\[Accept (受け入れる\])**​ を選択します。 4. アタッチメントの状態が ​**\[Available (使用可能)\]**​ に変わったら、​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ ページに戻り、​**\[Done (完了)\]**​ をクリックします。 非公開スペースの ​**\[Network (ネットワーク)\]**​ タブに戻ります。 **\[Connections (接続)\]**​ セクションには、AWS からのトランジットゲートウェイ ID とオーナーが表示され、トランジットゲートウェイの状態が ​**\[Available (使用可能)\]**​ でありアタッチメントの状態が ​**\[Attached to Private Network (非公開ネットワークにアタッチ済み)\]**​ であることが示されます。 VPC アタッチメントの状態が ​**\[Not Attached to VPC (VPC にアタッチされていない)\]**​ の場合、トランジットゲートウェイはアタッチされていません。 **\[Accept the attachment (アタッチメントを受け入れる)\]**​ リンクをクリックして、もう一度手順を実行します。 5. 非公開スペースからトランジットゲートウェイへの​[接続をテストします](#test-connection)​。 ## [](#configure-tgw-routing)トランジットゲートウェイのルーティングの設定 CloudHub 2.0 では、トランジットゲートウェイの静的ルーティングがサポートされています。 トランジットゲートウェイを通じてアクセス可能にするネットワークルート (サブネット) を設定します。 - Anypoint Platform で、​[非公開スペースから外部宛先へのアウトバウンドトラフィックのルートを設定します](#enable-outbound-traffic-from-ps)​。 - AWS で、トランジットゲートウェイを通じた​[インバウンドトラフィックを有効化します](#enable-inbound-traffic-on-aws)​。 ### [](#enable-outbound-traffic-from-ps)非公開スペースからのアウトバウンドトラフィックのルートの設定 **\[Attached to Private Network (非公開ネットワークにアタッチ済み)\]**​ メッセージが表示されたら、非公開スペースに​[指定した](#connect-tgw)​ルートが追加され、非公開スペースにデプロイされたアプリケーションがトランジットゲートウェイにアクセスできるようになります。 トランジットゲートウェイのルートテーブルにルートを追加するには、​[「ルートテーブルからルートを追加または削除」](https://docs.mulesoft.com/jp/cloudhub-2/ps-manage#add-remove-routes)​を参照してください。 ### [](#enable-inbound-traffic-on-aws)トランジットゲートウェイを通じたインバウンドトラフィックの有効化 Anypoint Platform でトランジットゲートウェイのルートテーブルへのルートの追加に成功したら、AWS でトランジットゲートウェイを通じたインバウンドトラフィックを有効にします。 インバウンドトラフィックを有効にするにはネットワーク管理者と連携する必要がある場合もあります。 ## [](#test-connection)非公開スペースへの接続のテスト トランジットゲートウェイに接続したら、CloudHub 2.0 からネットワークへの接続をテストします。 接続をテストするには、ネットワークツールアプリケーションを使用します。 ネットワークツールアプリケーションのダウンロードと使用方法については、 [「How To Use Network Tools Application (ネットワークツールアプリケーションの使用方法)」](https://help.mulesoft.com/s/article/How-To-Use-Network-Tools-Application)​ (KB 記事) を参照してください。 ## [](#best-practices)トランジットゲートウェイを維持する 非公開スペースへの接続をテストしたら、トランジットゲートウェイへの接続を定期的に確認します。 非公開スペースからトランジットゲートウェイにアクセスできなくなると、トランジットゲートウェイの状態が ​`[unknown (不明)]`​ または ​`[deleted (削除済み)]`​ に変わります。トランジットゲートウェイの状態が 14 日間 ​`[unknown (不明)]`​ または ​`[deleted (削除済み)]`​ のままである場合、Anypoint Platform によって非公開スペースアタッチメントがトランジットゲートウェイから削除されます。ただし、トランジットゲートウェイ自体は削除されません。 以下の場合、非公開スペースからトランジットゲートウェイにアクセスできなくなります。 - トランジットゲートウェイが CloudHub 2.0 から削除される。 - トランジットゲートウェイが AWS コンソールから削除される。 - リソース共有が削除される。 - MuleSoft アカウントプリンシパルがリソース共有から削除される。 トランジットゲートウェイを CloudHub 2.0 から削除するには、トランジットゲートウェイ、トランジットゲートウェイアタッチメント、またはリソース共有を AWS コンソールから削除する前に「​[トランジットゲートウェイを削除する](#delete-tgw)​」の手順を完了します。CloudHub 2.0 から接続を削除せずに AWS コンソールから削除すると、接続は中断されますが、削除されることはありません。 ## [](#troubleshoot-tgw)トランジットゲートウェイまたはトランジットゲートウェイアタッチメントの状態のトラブルシューティング トランザクションゲートウェイ接続が中断されると、トランザクションゲートウェイまたはトランジットゲートウェイアタッチメントの状態が ​`[unknown (不明)]`​、​`[rejected (拒否済み)]`​、または ​`[deleted (削除済み)]`​ に変わります。状態が変わった原因に応じて、トランジットゲートウェイまたはトランジットゲートウェイアタッチメントを削除、作成、デタッチ、再アタッチしてそれらの状態を修正できます。 ### [](#トランジットゲートウェイの状態の解決)トランジットゲートウェイの状態の解決 トランジットゲートウェイは、次の場合に ​`[unknown (不明)]`​ 状態になります。 - トランジットゲートウェイまたはリソース共有が削除される。 この状態を修正するには、「​[トランジットゲートウェイを削除する](#delete-tgw)​」の手順を使用して、トランジットゲートウェイを CloudHub 2.0 から削除します。 - MuleSoft アカウントプリンシパルが削除される。 この状態を修正するには、リソース共有にプリンシパルを追加します。 `[deleted (削除済み)]`​ 状態は、CloudHub 2.0 ではなく AWS コンソールからトランジットゲートウェイが削除されたときに発生します。この状態を修正するには、「​[トランジットゲートウェイを削除する](#delete-tgw)​」の手順を使用して、トランジットゲートウェイを CloudHub 2.0 から削除し、新しいトランジットゲートウェイを作成します。 ### [](#トランジットゲートウェイアタッチメントの状態の解決)トランジットゲートウェイアタッチメントの状態の解決 トランジットゲートウェイアタッチメントの ​`[deleted (削除済み)]`​ 状態は、CloudHub 2.0 ではなく AWS コンソールからトランジットゲートウェイアタッチメントが削除されたときに発生します。この状態を修正するには、「​[非公開スペースからトランジットゲートウェイをデタッチする](#detach-tgw)​」の手順を使用して、トランジットゲートウェイアタッチメントを非公開スペースからデタッチし、トランジットゲートウェイアタッチメントを再アタッチします。 トランジットゲートウェイアタッチメントの ​`[rejected (拒否済み)]`​ 状態は、トランジットゲートウェイアタッチメントが拒否されたときに発生します。この状態を修正するには、「​[非公開スペースからトランジットゲートウェイをデタッチする](#detach-tgw)​」の手順を使用して、トランジットゲートウェイアタッチメントを非公開スペースからデタッチし、トランジットゲートウェイアタッチメントを再アタッチします。 ## [](#rename-tgw)トランジットゲートウェイアタッチメントの名前を変更する AWS のアタッチメント名に合うようにトランジットゲートウェイアタッチメントの名前を変更する必要がある場合もあります。 トランジットゲートウェイアタッチメントの名前を変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、トランジットゲートウェイメニュー (​**\[…​\]**​) をクリックし、​**\[Rename (名前を変更)\]**​ を選択します。 4. 新しい名前を入力し、​**\[Save (保存)\]**​ をクリックします。 ## [](#detach-tgw)非公開スペースからトランジットゲートウェイをデタッチする 次の理由で、トランジットゲートウェイアタッチメントのデタッチが必要な場合があります。 - AWS でアタッチメントを拒否した場合、Anypoint Platform でトランジットゲートウェイアタッチメントが ​`[Rejected (拒否済み)]`​ と表示されます。 この場合、もう一度アタッチを試みる前にアタッチメントを削除する必要があります。 - AWS でアタッチメントが削除された場合、そのアタッチメントを Anypoint Platform から削除できます。 トランジットゲートウェイアタッチメントを削除すると、関連付けられたルートも削除されます。 AWS のリソース共有は影響を受けないため、新しいトランジットゲートウェイを作成することなく再追加できます。ただし、非公開スペースからトランジットゲートウェイをデタッチすると、AWS のアタッチメントも削除されます。 トランジットゲートウェイをデタッチのみして組織から削除しない場合、そのトランジットゲートウェイは ​**\[Add a transit gateway (トランジットゲートウェイを追加)\]**​ の下に表示されます。 非公開スペースにデプロイされたアプリケーションは引き続き動作しますが、Amazon VPC および VPN には接続されなくなります。 トランジットゲートウェイをデタッチする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、トランジットゲートウェイメニュー (​**\[…​\]**​) をクリックし、​**\[Detach (デタッチ)\]**​ を選択します。 4. 確認プロンプトで ​**\[Detach (デタッチ)\]**​ をクリックします。 トランジットゲートウェイのデタッチには数分かかることもあります。 ## [](#delete-tgw)トランジットゲートウェイを削除する Anypoint Platform 組織からトランジットゲートウェイを完全に削除するには、 [トランジットゲートウェイの削除 API コール](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/method/%234136/) ​(​`DELETE <>/organizations/:orgId/transitgateways/:tgw-id`​) を使用して AWS のリソース共有を削除します。 詳細は、AWS ドキュメントの [「AWS RAM 内のリソース共有の削除」](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-delete.html)​を参照してください。 ## [](#関連情報)関連情報 - [必要なセットアップ情報の収集](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info) # ビジネスグループと環境の非公開スペースへの関連付け 非公開スペースにデプロイする前に、環境およびそれに関連付ける 1 つ以上のビジネスグループを指定できます。 この関連付けでは、アプリケーションのデプロイ時に非公開スペースが ​**\[Deployment Target (デプロイメント対象)\]**​ リストの対象デプロイメントとして表示される環境を指定します。 詳細は、「[非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)」を参照してください。 非公開スペースは、ビジネスグループ、およびそのビジネスグループまたはビジネスグループのサブセットで登録されている子ビジネスグループの本番環境と Sandbox 環境に関連付けることができます。 デフォルトでは、非公開スペースはそのビジネスグループ内のすべての Sandbox 環境に関連付けられます。 ## [](#ビジネスグループと環境の関連付け)ビジネスグループと環境の関連付け 「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限がある場合、ビジネスグループまたはグループの環境を非公開スペースに関連付けます。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Environments (環境)\]**​ タブをクリックして、次の操作を実行します。 - [\[associate-business-groups\]](#associate-business-groups) - [\[associate-environments\]](#associate-environments) ### [](#ビジネスグループを関連付ける)ビジネスグループを関連付ける 1. ドロップダウンリストからビジネスグループを選択します。 - **This business group and its children (このビジネスグループとその子)** このオプションでは、選択したビジネスグループおよびその全ての子のすべての環境、すべての Sandbox 環境、またはすべての本番環境のいずれかを選択できます。 - **Selected business groups (選択したビジネスグループ)** **\[Add business group (ビジネスグループを追加)\]**​ 項目にビジネスグループ名を入力し、リストから選択します。このオプションでは、特定のビジネスグループの特定の環境を選択できます。 リストには、非公開スペースが登録されており、まだ追加されていないビジネスグループとその子ビジネスグループが含まれます。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![ドロップダウンリストからビジネスグループを選択します。](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-select-business-group.png) ### [](#環境を関連付ける)環境を関連付ける 1. ドロップダウンリストから環境を選択します。 - **All Environment (すべての環境)** ビジネスグループとそのすべての子、または特定のビジネスグループのすべての Sandbox 環境と本番環境に非公開スペースを関連付けます。 - **All Sandbox Environments (すべての Sandbox 環境)** ビジネスグループとそのすべての子、または特定のビジネスグループの Sandbox 環境のみに非公開スペースを関連付けます。 - **All Production Environments (すべての本番環境)** ビジネスグループとそのすべての子、または特定のビジネスグループの本番環境のみに非公開スペースを関連付けます。 - **Select Environments Manually (手動で環境を選択)** 特定のビジネスグループの特定の環境に非公開スペースを関連付けることができます。 - 特定のビジネスグループのすべての Sandbox 環境または本番環境を一括で選択するには、​**\[Sandbox\]**​ または ​**\[Production (本番)\]**​ ボックスをオンにします。 - 特定のビジネスグループの目的の環境を個別に選択するには、特定のサブ環境のボックスをオンにします。 1. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックし手、関連付けを確定または破棄します。 ![ドロップダウンリストから環境を選択します。](/mulesoft/current/ja-jp/cloudhub-2/_images/ps-select-environment.png) ### [](#ビジネスグループの追加または削除)ビジネスグループの追加または削除 非公開スペースのビジネスグループを追加または削除できます。 新しいビジネスグループを追加するには、​**\[Add business group (ビジネスグループを追加)\]**​ 項目を使用します。 ビジネスグループを削除するには、エントリのゴミ箱アイコンをクリックします。 ![「Environments (環境)」 タブの削除アイコン](/mulesoft/current/ja-jp/cloudhub-2/_images/bg-delete.png) ## [](#ビジネスグループのリソースを管理する)ビジネスグループのリソースを管理する 「Organization Administrator (組織のシステム管理者)」権限がある場合、ビジネスグループに関連付けられたリソースを表示または管理します。 1. 組織のシステム管理者権限を持つアカウントを使用して Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のメインページで、​**\[Access Management (アクセス管理)\]**​ をクリックします。 3. \[Access Management (アクセス管理)\] ナビゲーションメニューで、​**\[Business Groups (ビジネスグループ)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ タブをクリックします。 5. **\[Resources (リソース)\]**​ セクションで、​**\[Production vCores (本番 vCore)\]**​ などのリソースの割り当てを表示または変更します。 6. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックします。 \[Access Management (アクセス管理)\] ナビゲーションメニューに ​**\[Business Groups (ビジネスグループ)\]**​ がない場合: 1. 組織のシステム管理者権限を持つアカウントを使用して Anypoint Platform にログインします。 2. ナビゲーションバーまたは Anypoint Platform のメインページで、​**\[Access Management (アクセス管理)\]**​ をクリックします。 3. \[Access Management (アクセス管理)\] ナビゲーションメニューで、​**\[Organization (組織)\]**​ をクリックします。 4. 変更するビジネスグループの名前をクリックします。 5. **\[Production vCores (本番 vCore)\]**​ などのリソースの割り当てを表示または変更します。 6. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [アクセス管理について](https://docs.mulesoft.com/jp/access-management/) # プロパティを使用したアプリケーションの動作の変更 _プロパティ_​を使用して、実行中のアプリケーションの動作を変更できます。 アプリケーションプロパティは、Mule アプリケーションでプレースホルダーとして動作する変数で、実行時に設定されます。 Runtime Manager でアプリケーションをデプロイ、または既存のアプリケーションを更新するときに、Mule Runtime Engine は ​**\[Properties (プロパティ)\]**​ タブで設定される情報を使用してプロパティの変数の値を提供します。 たとえば、ユーザー名が ​`${dbUsername}`​、パスワードが ​`${dbPassword}`​ に設定される JDBC Connector を設定できます。 Runtime Manager で、これら 2 つのプロパティをアプリケーションプロパティとして設定できます。 機密情報の場合は、プロパティの値を保護できます。そうすると、Runtime Manager で保存された後、それらの値はコンソールに表示されず、コンソールと CloudHub 2.0 の間で渡されることもありません。 詳細は、「[アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props)」を参照してください。 Anypoint Runtime Manager またはプロパティファイルでプロパティを設定できます。 アプリケーションのプロパティファイルと Runtime Manager の両方でプロパティを設定してある場合、アプリケーションをデプロイすると、常に Runtime Manager の値がプロファイルファイルの値よりも優先されます。 ## [](#runtime-manager-でアプリケーションのプロパティを追加する)Runtime Manager でアプリケーションのプロパティを追加する 非公開スペースにデプロイされたアプリケーションにプロパティを読み込む最も簡単な方法は、アプリケーションの ​**\[Properties (プロパティ)\]**​ タブでそれらを定義することです。 プロパティを追加する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 ![アプリケーションの \[Settings (設定)\] ページにある \[Properties (プロパティ)\] と \[New Key (新しいキー)\] および \[New Value (新しい値)\] 項目](_images/ch2-props-rtm.png) 5. **\[Table view (テーブルビュー)\]**​ をクリックします。 代わりに、​**\[Text view (テキストビュー)\]**​ をクリックし、テキスト項目に ​`New Key=New Value`​ の形式でキー-値ペアを入力することもできます。 6. **\[New Key (新しいキー)\]**​ 項目にプロパティ名を入力します。 7. **\[New Value (新しい値)\]**​ 項目で、プロパティ値を追加します。プロパティ値にスペースが含まれている場合は、​`"ApiKey 898jdey1-13232"`​ のように引用符で囲みます。
Chrome のパスワード保存機能が有効化されていて、[Key (キー)] 項目のコンテンツと一致する ​anypoint.mulesoft.com​ のユーザー名が保存されている場合、Chrome はそのユーザー名に関連付けられている保存済みパスワードで [Value (値)] 項目の値を上書きします。 この制約を回避するには、Chrome をシークレットモードで使用するか、または他のブラウザーを使用してください。
**\[Table view (テーブルビュー)\]**​ で、必要に応じて次の操作を実行します。 - Runtime Manager で値を非表示にするには、​**\[Protect (保護)\]**​ をクリックしてから、​**\[Protect value (値を保護)\]**​ をクリックして確定します。 「[アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props)」を参照してください。 - キーまたは値を変更するには、項目内のテキストを編集します。 - プロパティを削除するには、​**\[…​\]**​ > ​**\[Delete property (プロパティを削除)\]**​ をクリックします。 8. **\[Apply Changes (変更を適用)\]**​ をクリックします。 変更を適用すると、新しい設定が作成され、レプリカが再起動されます。 詳細は、「[CloudHub 2.0 にデプロイされたアプリケーションの更新](https://docs.mulesoft.com/jp/cloudhub-2/ch2-update-apps)」を参照してください。 ### [](#例-プロパティを使用した環境変数の設定)例: プロパティを使用した環境変数の設定 アプリケーションの環境変数を設定できます。 プロパティにより、デプロイ先の環境に応じて変わる設定を外部化することができます。 たとえば、ローカルで Mule アプリケーションを使用している場合は、データベースホストを ​`0.0.0.0`​ に設定する可能性があります。 同じアプリケーションを CloudHub 2.0 にデプロイする場合は、データベースホストを Amazon RDS サーバーなどに設定することがあります。 アプリケーションプロパティを使用して環境変数を設定する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブをクリックします。 5. **\[Text view (テキストビュー)\]**​ に ​`key=value`​ の形式で変数を入力して、変数を定義します。
[Text view (テキストビュー)]​ では、バックスラッシュ文字 (​\​) はエスケープ文字として使用します。 たとえば、キーまたは値内で ​:​ を使用するには、構文で ​\:​ を使用します。 キーまたは値内で ​\​ を使用するには、構文で ​\\​ を使用します。 [Table view (テーブルビュー)]​ の構文には、エスケープ文字は必要ありません。
6. Mule アプリケーション設定で環境変数を使用します。 ## [](#プロパティファイルを使用したアプリケーションプロパティの追加)プロパティファイルを使用したアプリケーションプロパティの追加 プロパティプレースホルダー YAML ファイルのデプロイ可能なアプリケーションのアーカイブファイルにファイルを含めることで、アプリケーションにプロパティを追加できます。 「[Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties)」を参照してください。 これらのプロパティは、アプリケーションの起動時に CloudHub 2.0 によってアプリケーションに読み込まれます。 この方法は CloudHub 2.0 でのベストプラクティスではありません (​**\[Properties (プロパティ)\]**​ タブの値によってファイル内の同じ名前を持つすべてのプロパティが上書きされるため) が、Mule アプリケーションのオプションを変更することでこの問題を回避できます。 CloudHub 2.0 プロパティによって、デプロイ可能なアーカイブにバンドルされたプロパティが上書きされるのを防ぐには、Mule アプリケーションの ​`property-placeholder`​ 要素のオプションを変更します。 デフォルト以外のプロパティプレースホルダーオプションの詳細は、 [プロパティプレースホルダーオプションに関する Spring のドキュメント](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/support/PropertySourcesPlaceholderConfigurer.html)​を参照してください。 ## [](#制限事項)制限事項 - 最大 300 個のプロパティを追加できます。 - プロパティキーとその値は 1024 文字を超えることはできません。 ## [](#予約されたプロパティ)予約されたプロパティ CloudHub 2.0 では、一部のプロパティが予約されており、これらのプロパティの値は変更できません。 アプリケーションが予約されたプロパティに値を割り当てようとしても、CloudHub 2.0 はその値を使用しません。 代わりに、エラーや例外をスローすることなく、内部で設定されている値を返し、ログに警告メッセージを追加します。
プロパティ 説明 例

${java.runtime.name}

JVM 名

OpenJDK Runtime Environment

${java.version}

JVM バージョン

1.8.0_342

${java.runtime.version}

ドット (ポイント) リリースを含む JVM バージョン

1.8.0_342​-8u342-b07-0ubuntu1~20.04-b07

${http.port}

HTTP ポート

8081

${https.port}

HTTPS ポート

8081

${http.private.port}

HTTP 非公開ポート

8081

${https.private.port}

HTTPS 非公開ポート

8081

独自の理由により、MuleSoft は予約されたすべての内部プロパティを公開しません。 CloudHub 2.0 ランタイムリリースの更新により、予約されたプロパティが変更される場合があります。
## [](#関連情報)関連情報 - [Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties) - [CloudHub 2.0 へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy) - [アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props) # ログ検索クエリ構文 Runtime Manager ログ検索では、クエリビルダーとファセット検索ユーザーインターフェースを使用するだけでなく、ログ検索クエリ言語を使用できます。 ## [](#search-terms)検索語 検索語は語と演算子で構成されます。検索語は単一語 ("hello" など) にすることも、語句 ("hello dolly" など) にすることもできます。 複数の語を Boolean 演算子で組み合わせて複雑なクエリを作成できます。 ## [](#term-modifiers)語の修飾 ログ検索クエリ言語を使用してクエリ語を修飾し、幅広い検索オプションを提供できます。 ## [](#wildcard-searches-cloudhub)ワイルドカード検索 単一語の中の 1 文字および複数文字のワイルドカード検索を使用できます。 1 文字のワイルドカード検索を実行するには、​`?`​ 記号を使用します。1 文字のワイルドカード検索では、語の 1 文字を ​`?`​ で代替して一致する語を検索します。たとえば、"text" または "test" を検索する場合は、次の検索を使用できます。 `te?t` 複数文字のワイルドカード検索を実行するには、\* 記号を使用します。複数文字のワイルドカード検索では、0 文字以上を代替して検索します。たとえば、test、tests、または tester を検索するには、次の検索を使用します。 `test*` `te*t`​ のように、語の中間でワイルドカード検索を使用することもできます。 ## [](#boolean-operators)Boolean 演算子 Boolean 演算子では、語を論理演算子で組み合わせることができます。ログ検索クエリ言語では、Boolean 演算子として ​`AND`​、​`+`​、​`OR`​、​`NOT`​、​`-`​ をサポートしています。
Boolean 演算子はすべて大文字にする必要があります。
Boolean 演算子 説明 例

AND​

AND​ 演算子は、1 つのドキュメントのテキスト内の任意の場所に両方の語が存在するドキュメントを照合します。これは、共通集合と同じです。

「anypoint monitoring」を含むドキュメントを検索するには、次のクエリを使用します。 ​"anypoint monitoring" AND "results"

OR​

OR​ 演算子は、2 つの語の間に Boolean 演算子が挿入されていない場合にデフォルトで使用されます。​OR​ 演算子は 2 つの語を関連付け、いずれかの語がドキュメントに存在すれば、一致ドキュメントを返します。これは、和集合と同じです。​OR​ の代わりに ​| |​ を使用することもできます。

「anypoint monitoring」または単に「monitoring」のみを含むドキュメントを検索するには、次のクエリを使用します。

"monitoring anypoint" monitoring​

または

"monitoring anypoint" OR monitoring

NOT

NOT​ 演算子は、​NOT​ の後に語が含まれるドキュメントを除外します。これは、差集合と同じです。​NOT​ の代わりに ​!​ を使用することもできます。

「anypoint monitoring」を含み、「functional」を含まないドキュメントを検索するには、次のクエリを使用します。 ​"anypoint monitoring" NOT "functional"

NOT​ 演算子は、1 語だけの場合は使用できません。たとえば、次の検索では結果が返されません。
NOT "functional"

+

+​ 記号に続く単語が、単一ドキュメントの項目内のどこかに存在する必要があります。

「anypoint」を必ず含み、「monitoring」を含んでいるかも知れないドキュメントを検索するには、次のクエリを使用します。

+anypoint monitoring

-

-​ 記号に続く単語を含むドキュメントを除外します。

「anypoint monitoring」を含み、「results」を含まないドキュメントを検索するには、次のクエリを使用します。

"anypoint monitoring" -"results"

## [](#special-characters)特殊文字 クエリ構文の一部として特殊文字をエスケープできます。現在サポートされている特殊文字は次のとおりです。 `+ - && || ! ( ) { } [ ] ^ " ~ * ? : \ < >` これらの文字をエスケープするには、その文字の前に ​`\`​ を使用します。たとえば、(1+1):2 を検索するには、次のクエリを使用します。 `\(1\+1\)\:2` ## [](#search-fields)検索項目 検索を実行するときには、項目名を指定するか、デフォルトを使用します。項目名とデフォルト項目は、検索実装に固有です。 項目名の後にコロン、検索する語を続けて入力して、任意の項目を検索します。 たとえば、「my-app」というアプリケーションで「called the function Value Selector」というメッセージが含まれるロゴを見つけるには、次のいずれかを入力します。 - `application: "my-app" AND message: "called the function Value Selector"` - `application: "my-app" AND "called the function Value Selector"` `message`​ はデフォルト項目であるため、クエリで項目インジケーターを指定する必要はありません。ただし、​`application`​ 項目は、このクエリの ​`message`​ 項目の前に指定する必要があります。 # 共有スペース _共有スペース_​は、マルチテナント環境で実行される Mule インスタンスを含むリソースの拡張性の高いクラウドです。 CloudHub 2.0 は、サポートされている​[リージョン](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#private-network-region)​ごとに 1 つの共有スペースを提供し、そこにインテグレーションアプリケーションをデプロイします。 共有スペースへのデプロイには、基盤となるインフラストラクチャのセットアップやメンテナンスは必要ありません。 次の条件を満たす場合、リージョン内の共有スペースにアプリケーションをデプロイできます。 - パブリッククラウドから分離する必要がない。 - アプリケーションをオンプレミスデータセンターに接続する必要がない。 - アプリケーションは (バニティドメイン名ではなく) ​`cloudhub.io`​ ドメイン名を使用できる。 - カスタム証明書を構成する必要がない。 次の機能には非公開スペースが必要です。 - アプリケーションのシングルテナント - データセンターへのネットワーク接続 (VPN またはトランジットゲートウェイアタッチメント) - バニティドメイン名 - カスタム証明書 - 非公開エンドポイント - 静的アプリケーションソース IP アドレス ## [](#関連情報)関連情報 - [非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about) # 共有スペースへのアプリケーションのデプロイ Runtime Manager を使用して、アプリケーションを共有スペースにデプロイします。
CloudHub 2.0 では、Mule Runtime Engine バージョン 4.3.x 以降がサポートされます。 Mule 3.x はサポートされていません。
Exchange で以前にアセットが​論理削除​されている場合、Runtime Manager でアプリケーションを CloudHub 2.0 または Runtime Fabric にデプロイできません。
## [](#共有スペースにアプリケーションをデプロイする)共有スペースにアプリケーションをデプロイする 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ ページで、次の手順を実行します。 1. アプリケーションの​[名前](#app-name-reqs)​を入力します。
アプリケーションのデプロイ後は名前を変更することはできません。名前を変更するには、削除してから新しい名前でアプリケーションを再デプロイしてください。
2. アプリケーションファイルを選択します。 - システムから Mule アプリケーション JAR ファイルをアップロードするには、​**\[Choose file (ファイルを選択)\] > \[Upload file (ファイルをアップロード)\]**​ を選択します。 - Anypoint Exchange からサンプルアプリケーションを選択する手順は、次のとおりです。 1. **\[Choose File (ファイルを選択)\] > \[Import file from Exchange (Exchange からファイルをインポート)\]**​ を選択します。 2. **\[Get from Exchange (Exchange から取得)\]**​ ページで、​**\[Search assets by name (アセットを名前で検索)\]**​ に​`「hello」`​と入力します。 ![「Get from Exchange (Exchange から取得)」 ページ](/mulesoft/current/ja-jp/cloudhub-2/_images/rtm-get-from-exchange.png) 3. **\[Hello World\]**​ をクリックし、​**\[Select (選択)\]**​ をクリックします。 3. **\[CloudHub 2.0\]**​ を選択し、​**\[Deployment Target (デプロイメント対象)\]**​ からリージョンに ​**\[Shared Space (共有スペース)\]**​ を選択します。 リージョンのリストについては、​[「共有グローバルリージョン」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-architecture#shared-global-regions)​を参照してください。グローバルデプロイメントエンタイトルメントがある場合、すべてのリージョンを使用できます。サブスクリプションに基づくリージョン制限がある場合、組織で使用可能なリージョンのみが表示されます。 4. デプロイメントのオプションを設定します。 - [ランタイムオプションを指定する](#specify-runtime-options)​。 - [プロパティを使用してアプリケーションの動作を変更する](#app-properties)​。 - [アプリケーションのログを設定する](#configure-logging)​。 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ### [](#specify-runtime-options)ランタイムオプションを指定する **\[Runtime (ランタイム)\]**​ タブをクリックし、次のオプションを指定します。 ランタイムバージョン Mule Runtime Engine バージョンを指定します。バージョン 4.3.x、4.4.x、4.5.x、4.6.x がサポートされています。 Release Channel (リリースチャネル) Mule 4.5 以降、MuleSoft は ​[Edge と長期サポート (LTS)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)​ という 2 つの新しいリリースチャネルを導入します。 新しいアプリケーションでは、​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンメニューで Edge チャネルがデフォルトで選択されます。 従来のバージョンを使用している既存のアプリケーションでは、​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストで ​`[None (なし)]`​ がデフォルトで選択されます。​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストを使用して、目的のリリースチャネルを選択します。 Edge バージョンを使用している既存のアプリケーションでは、​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストで ​`[Edge]`​ がデフォルトで選択されます。​**\[Runtime Version (Runtime バージョン)\]**​ ドロップダウンリストでは、更新が利用できるかどうか、およびアプリケーションの以前のバージョンと最新バージョンが示されます。​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストを使用して、従来バージョンに変更します。 拡張サポートで Edge または LTS バージョンを使用している既存のアプリケーションでは、バージョンの EOL を示す警告メッセージが表示されます。 Unresolved include directive in modules/ROOT/pages/\_partials/deployment.adoc - include::cloudhub::partial$mule-runtime-eos-note.adoc\[\] Java バージョン アプリケーションの Java バージョンを選択します。詳細は、[Java サポート](https://docs.mulesoft.com/jp/general/java-support)を参照してください。 Replica size (レプリカサイズ) アプリケーションを実行するレプリカ内の vCore の数を指定します。 レプリカのサイズ、メモリ、ストレージについては、​[「CloudHub 2.0 レプリカ」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-architecture#cloudhub-2-replicas)​を参照してください。 CloudHub 2.0 では、デプロイメントあたりのレプリカサイズは 4 つの vCore に制限されています。 Replica Count (レプリカ数) デプロイするアプリケーションのレプリカまたはインスタンスの数を指定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Run in Runtime Cluster Mode (ランタイムクラスターモードで実行) アプリケーションの各レプリカで ​[Mule のクラスタリング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​を有効にします。 このオプションには、少なくとも 2 つのレプリカが必要です。 Use Object Store V2 (Object Store V2 を使用) **\[Use Object Store V2 (Object Store V2 を使用)\]**​ チェックボックスをオンにすることで、Mule 3 と Mule 4 の実装として ​[Object Store v2](https://docs.mulesoft.com/jp/object-store/)​ を選択できます。 Deployment model (デプロイメントモデル) - **Rolling update (ローリング更新)**​: - レプリカを増分的に更新することで、可用性を維持します。 - **Recreate (再作成)**​: - 再デプロイメントの前にレプリカを終了します。 - 再デプロイメントはより高速で、追加リソースは必要ありません。 ### [](#app-name-reqs)アプリケーション名 アプリケーション名では、3 ~ 42 文字の英数字 (a-z、A-Z、0-9) とハイフン (-) を使用できます。 スペースやその他の文字を含めることはできません。 アプリケーション名の先頭は文字 (a-z または A-Z) にする必要があります。先頭を数値やハイフンにしたり、末尾をハイフンにしたりすることはできません。 名前が一意になるようにし、ドメインの競合を回避するために、CloudHub 2.0 では公開エンドポイント URL で指定したアプリケーション名に 6 文字の ​`_unique-id_`​ が追加されます。 アプリケーション名は、Runtime Manager だけでなく、公開 ​`cloudhub.io`​ ドメインでもアプリケーションを識別するものです。 たとえば、​`myapp`​ という名前のアプリケーションには ​`http://myapp-​_unique-id_​._shard_.usa-w2.cloudhub.io`​ でアクセスできます。各デプロイメント対象に固有のアプリケーション名が必要です。 アプリケーション名をさらにカスタマイズするために、命名規則を作成できます。 たとえば、​`mycompany-mydept-myapp`​ のように会社名と部署をすべてのアプリケーション名の前に付けることもできます。 そして、DNS レコードを追加して、複雑なアプリケーション名を非表示にすることができます。 たとえば、​`myapp.mycompany.com`​ に対する要求を ​`mycompany-mydept-myapp-​_unique-id_​._shard_._region_​.cloudhub.io`​ にルーティングすることもできます。 アプリケーションファイル名は、できる限り一意にします。Exchange のアセットと同じ名前を共有しているアプリケーションはデプロイできません。 ## [](#app-properties)プロパティを使用したアプリケーションの動作の変更 アプリケーションのデプロイメント時に、環境の指定やパスワードとユーザー名の設定などのプロパティ値を設定できます。 アプリケーションのプロパティの設定については、次のリンク先を参照してください。 - [プロパティを使用したアプリケーションの動作の変更](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-props) - [アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props) ## [](#configure-logging)アプリケーションのログの設定 CloudHub 2.0 にデプロイされたアプリケーションの場合、デフォルトでログが有効になっています。 ### [](#ログを無効化または有効化する)ログを無効化または有効化する アプリケーションのログを無効化または再有効化する手順は、次のとおりです。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Forward application logs to Anypoint Platform (Anypoint Platform にアプリケーションログを転送)\]**​ オプションを選択解除または選択します。 3. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ログを無効にしても、Runtime Manager ナビゲーションメニュー ​**\[Logs (ログ)\]**​ ヘッダーが引き続き表示されますが、アプリケーションログは収集されません。 ### [](#ログレベルおよびカテゴリを設定する)ログレベルおよびカテゴリを設定する ログに含める追加のログレベルとカテゴリを設定する手順は、次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. ログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (重要)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 3. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 4. **\[Apply Changes (変更を適用)\]**​ をクリックします。
ログレベルを変更して ​[Apply Changes (変更を適用)]​ をクリックすると、アプリケーションが再起動します。
## [](#トレースデータ収集の有効化)トレースデータ収集の有効化
この機能は、組織に 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 以降で実行されている CloudHub 2.0 アプリケーションで有効にすることができます。 トレースデータ収集は、Mule Maven プラグイン、Anypoint CLI、または Anypoint Studio を使用して有効にすることはできません。トレースデータ収集を有効にするには、UI や API を使用する必要があります。 アプリケーションのトレースデータ収集を有効にする手順は次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. **\[Enable tracing (トレースを有効化する)\]**​ チェックボックスをオンにします。 3. 新しいデプロイメントでこの機能を有効にする場合には、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。既存のアプリケーションを編集している場合は ​**\[Apply Changes (変更を適用)\]**​ をクリックします。 トレースを有効にしてアプリケーションを再デプロイすると、Runtime Manager バックエンドによってアプリケーションのトレース計測が開始されます。 ## [](#関連情報)関連情報 - [Exchange からのテストアプリケーションのダウンロード](https://docs.mulesoft.com/jp/cloudhub-2/ch2-download-test-app) - Exchange の [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) - [Log4j を使用したログシステムとのインテグレーション](https://docs.mulesoft.com/jp/cloudhub-2/ch2-integrate-log-system) # 必要なセットアップ情報の収集 次のセクションを使用して、非公開スペースをセットアップするために必要な情報を収集します。 非公開スペースについての詳細は、[非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about)を参照してください。 この情報にアクセスできない場合は、ネットワーク管理者の支援が必要な可能性があります。 その場合、このセットアップチェックリストを共有してください。 ## [](#organization-limits)組織のエンタイトルメントおよび CloudHub 2.0 組織のエンタイトルメントに基づいて、Anypoint Platform では、vCore 消費、ネットワーク接続 (VPN とトランジットゲートウェイアタッチメント)、および非公開スペースに対して制限が適用されます。 CloudHub 1.0 と CloudHub 2.0 でエンタイトルメントクォータが共有されます。組織で CloudHub 1.0 と CloudHub 2.0 の両方を使用する場合、この両方を念頭に置いて消費量を割り当てる必要があります。たとえば、組織に 4 つのネットワーク接続のエンタイトルメントがある場合、組織は CloudHub 1.0 の 1 つのトランジットゲートウェイ接続、CloudHub 2.0 の 1 つのトランジットゲートウェイ接続、および 2 つの VPN (またはこれらの任意の組み合わせ) をサポートできます。つまり、ネットワーク接続のエンタイトルメントが 4 の場合、CloudHub の各バージョンでそれぞれ 4 つのネットワーク接続を取得することはできません。ニーズを満たす十分なエンタイトルメントを組織で確保するには、リソースがエンタイトルメントにどのようにマップされるかを理解する必要があります。 - Private Cloud クォータには、CloudHub 1.0 の VPC (Virtual Private Cloud) と CloudHub 2.0 の非公開スペースの両方が含まれます。 - ネットワーク接続クォータには、CloudHub 1.0 と CloudHub 2.0 の両方の VPN とトランジットゲートウェイアタッチメントが含まれます。 - vCore 使用量クォータは、CloudHub 1.0 と CloudHub 2.0 にデプロイされたアプリケーションに適用されます。 Anypoint Platform では、ユーザーは組織の制限を超えるリソースを消費することはできません。また、Anypoint Platform では、ユーザーは既存のリソースの制限を超えている場合にそのリソースを変更することはできません。CloudHub 2.0 での失敗したアプリケーションのデプロイと失敗した非公開スペースの作成も制限に含まれます。 ## [](#setup-info-private-space)非公開スペースのセットアップに必要な情報 次のリストは、非公開スペースをセットアップするために必要な情報が要約されています。 各要件についての詳細は、その後のセクションを参照してください。 **非公開ネットワークのセットアップ** - [非公開スペース名](#private-space-name) - [非公開ネットワークリージョン](#private-network-region) - [CIDR ブロック](#cidr-block) - [内部 DNS サーバー](#internal-dns-server)​ (省略可能) - [IP アドレス](#server-ip-addresses) - [ドメイン](#domains) **VPN 接続種別** - [VPN 名](#vpn-name) - [リモート IP](#remote-ip-address) - **[動的ルーティング種別](#dynamic-vpn-routing)** - [ローカル ASN](#local-asn) - [リモート ASN](#remote-asn) - **[静的ルーティング種別](#static-vpn-routing)** - [\[Local ASN\]](<#Local ASN>)​(​_最初の VPN のみ_​) - [静的 IP プレフィックス](#static-ip-prefixes) - **[高度なトンネル設定](#advanced-tunnel-configuration)**​ (​_省略可能_​) - トンネル 1 - [内部 IP CIDR](#inside-ip-cidrs) - [事前共有キー](#preshared-keys) - トンネル 2 - [内部 IP CIDR](#inside-ip-cidrs) - [事前共有キー](#preshared-keys) - [自動トンネル開始](#auto-tunnel-initiation)​ (​_最初の VPN のみ_​) - [**サポートされるゲートウェイデバイス**](#supported-gateway-devices) - デバイスベンダー - デバイスのプラットフォーム - デバイスソフトウェア **冗長 VPN 接続**​ (​_省略可能_​) - **[動的ルーティング種別](#dynamic-vpn-routing)** - [リモート IP](#remote-ip-address) - [リモート ASN](#remote-asn) - **[静的ルーティング種別](#static-vpn-routing)** - [静的 IP プレフィックス](#static-ip-prefixes) - **[高度なトンネル設定](#advanced-tunnel-configuration)**​ (​_省略可能_​) - トンネル 1 - [内部 IP CIDR](#inside-ip-cidrs) - [事前共有キー](#preshared-keys) - トンネル 2 - [内部 IP CIDR](#inside-ip-cidrs) - [事前共有キー](#preshared-keys) - [**サポートされるゲートウェイデバイス**](#supported-gateway-devices) - デバイスベンダー - デバイスのプラットフォーム - デバイスソフトウェア **トランジットゲートウェイアタッチメント種別** - [トランジットゲートウェイ名](#transit-gateway-name) - [トランジットゲートウェイリージョン](#transit-gateway-region) - [トランジットゲートウェイルーティング](#transit-gateway-routing) - [MuleSoft AWS アカウント ID](#mulesoft-aws-account-id) - [リソース共有 ID](#resource-share-id-owner) - [リソース共有オーナー](#resource-share-id-owner) ## [](#private-network-requirements)非公開ネットワーク要件 - [非公開スペース名](#private-space-name) - [非公開ネットワークリージョン](#private-network-region) - [CIDR ブロック](#cidr-block) - [接続種別](#connection-type) - [内部 DNS サーバー (省略可能)](#internal-dns-server) ### [](#private-space-name)非公開スペース名 非公開スペース名では、1 ~ 36 文字の英数字 (a-z、A-Z、0-9) とハイフン (-) を使用できます。 Runtime Manager では、非公開スペース名で Unicode 文字がサポートされています。 アプリケーションのデプロイメント対象を選択すると、リストに非公開スペース名が表示されます。 非公開スペースの名前を変更することはできません。 ### [](#private-network-region)非公開ネットワークリージョン _リージョン_​は、アプリケーションをデプロイする Amazon リージョン (​`usa-e1`​ など) です。 サポートされているリージョンの完全なリストを次に示します。 US East (Northern Virginia) US East (Ohio) US West (Northern California) US West (Oregon) Canada (Central) South America (Sao Paulo) Europe (Ireland) Europe (Frankfurt) Europe (London) Asia Pacific (Singapore) Asia Pacific (Sydney) Asia Pacific (Tokyo) ### [](#cidr-block)CIDR ブロック _CIDR ブロック_​は、非公開スペースにデプロイされたアプリケーションで使用する CIDR (クラスレスドメイン間ルーティング) 表記の IPv4 アドレスの範囲です。 CIDR ブロックは、非公開スペースのサイズを定義します。 たとえば、非公開ネットワークに ​`10.111.0.0`​ ~ ​`10.111.0.255`​ の 256 個の IP アドレスを付与するには、CIDR ブロックを ​`10.111.0.0/24`​ に設定します。 非公開スペースを作成するときに、CIDR ブロックを指定する必要があります。 非公開スペースを作成した後に、CIDR ブロックのサイズ変更や変更を行うことはできません。 そのため、このパラメーターを設定する前に、要件に適切に対応できることを確認してください。 `/22`​ ブロックをお勧めします。 一部のアドレスはフォールトトレランス、インフラストラクチャ、ダウンタイムなし用に予約されているため、Anypoint VPC に割り当てることができる許容ブロックサイズは ​`/16`​ ~ ​`/24`​ です。ブロックのサイズは、アプリケーションで使用できる IP の数を制限しません。 CIDR ブロックを指定するときは、CIDR ブロックが次の条件を満たしていることを確認してください。 - 非公開 IP スペースからである。 - 他の非公開スペースに割り当てられているほかの CIDR ブロックと重複しない。 - 企業ネットワークで使用されている CIDR ブロックと重複しない。 MuleSoft では、​`10.0.0.0/8`​、​`172.16.0.0/12`​、​`192.168.0.0/16`​ などの標準 RFC 1918 アドレスのサブネットを使用することをお勧めします。 #### [](#unusable-cidr)使用できない非公開スペースネットワークの CIDR 次の CIDR ブロックのリストは使用できません。 100.64.0.0/10 198.19.0.0/16 224.0.0.0/4 169.254.0.0/16 127.0.0.0/8 172.17.0.0/16 0.0.0.0/8 #### [](#reserved-cidr)予約する企業の CIDR (省略可能) 必要に応じて、非公開スペースを作成して非公開ネットワークを設定するときに、予約する企業ネットワークの CIDR に対応する​_予約済み CIDR ブロック_​設定できます。非公開ネットワーク設定で CIDR を予約すると、IP アドレスを非公開スペースに関連付けるときに指定するブロックが Anypoint Platform で使用されなくなります。これにより、企業ネットワークの CIDR と Anypoint Platform インフラストラクチャ間の重複を回避できます。 非公開スペースの作成中に CIDR を予約する戦略は 2 つあります。 1. 予約する企業の CIDR をすべて指定する 企業ネットワーク内で使用するすべての CIDR ブロックを指定します。CloudHub 2.0 では、MuleSoft インフラストラクチャの CIDR プールとの競合が自動的にチェックされ、重複していないオプションが選択されます。 このアプローチでは、セットアップが簡略化されますが、指定するリストが長くなる可能性があります。 2. 重複する企業の CIDR を手動で特定する MuleSoft インフラストラクチャの CIDR プールを手動で確認します。次に、MuleSoft インフラストラクチャの CIDR プールと競合する企業ネットワークの CIDR リストの CIDR のみを指定します。このアプローチでは、指定するリストは最小限に抑えられますが、事前に重複を確認する必要があります。 MuleSoft インフラストラクチャの CIDR プールは変更される場合があります。 #### [](#infra-cidr-pool)MuleSoft インフラストラクチャの CIDR プール Anypoint Platform には、非公開スペースネットワークをプロビジョニングするための内部 CIDR プールとして CIDR のリストがあります。MuleSoft インフラストラクチャの CIDR プールは変更される場合があります。次のいくつかは予約済み CIDR ブロックとして設定できますが、非公開スペースネットワークの CIDR として使用することはできません。 100.64.0.0/16 100.66.0.0/16 100.67.0.0/16 100.68.0.0/16 ### [](#internal-dns-server)内部 DNS サーバー (省略可能) 企業ネットワークが内部 DNS サーバーを使用してカスタムドメインへの要求を解決する場合は、これらのサーバーを設定して、非公開スペースにデプロイされたアプリケーションが公開インターネットからは到達できない内部リソースにアクセスできるようにする必要があります。 内部 DNS サーバーを設定するには、内部ドメインサーバーの IP アドレス、および内部 DNS によって解決されるドメインを指定します。 非公開スペースは、指定された DNS サーバーを使用してドメインを解決し、アプリケーションが FQDN を使用してバックエンドリソースを要求する限り、非公開ネットワークで内部ホスト名を使用できます。 #### [](#server-ip-addresses)サーバー IP アドレス _サーバー IP アドレス_​は、カスタムドメインへの要求を解決する内部 DNS サーバーを識別します。 冗長性を提供するために、複数の内部 DNS サーバーを設定できます。 DNS サーバーの IP アドレスを設定するときは、次の点に注意してください。 - 非公開スペース内で DNS サーバーを設定するため、設定するサーバー IP アドレスは非公開スペースから到達できる必要があります。 サーバーに到達できない場合、DNS 解決は失敗します。 - 複数のサーバーを設定する場合、非公開スペースはリスト内の DNS サーバーに対して、指定されたドメインをいつでも任意の順序で照会します。 - すべてのネームサーバーは同じ DNS レコードを提供する必要があります。 - 非公開スペースは、設定されたネームサーバーから有効な応答を受信した後に、要求を再試行しません。 いずれかのネームサーバーにドメインのレコードがない場合、応答 ​`NXDOMAIN`​ (存在しないドメイン) が返されます。 この応答は有効であるため、非公開スペースは照会を他のサーバーに送信しません。 #### [](#domains)ドメイン _ドメイン_​は、非公開スペースからアクセスできる必要がある内部ドメインを識別します。 設定された内部 DNS サーバーは指定されたドメインを解決し、外部 DNS サーバーはその他すべてのドメインを解決します。 内部ドメインを設定するには、IP アドレスを指定します。 次の内部非公開 DNS ドメインはサポートされていません。 - `cloudhub.io` - `mulesoft.com` - `anypointdns.net` - `amazon.com` - `amazonaws.com` - `compute.internal` - `io` - `com` - `net` - `internal` - `local` - `domain.com` MuleSoft ドメインまたは公開ドメインを非公開スペースの内部 DNS として追加することはできません。 これらの制限は、それぞれのサブドメインにも適用されます。 回避策として、独自の DNS サーバーで CNAME レコードを作成し、追加する制限付きドメインに許可されたカスタムドメインをリダイレクトします。 [「特定のドメインを CloudHub VPC 内部 DNS に追加できない」](https://help.salesforce.com/s/articleView?id=001119691&type=1)​を参照してください。
設定されたすべてのドメインの合計文字数は 229 です。
### [](#connection-type)接続種別 - [仮想プライベートネットワーク (VPN)](#vpn-requirements) - [トランジットゲートウェイアタッチメント](#tgw-requirements) ## [](#vpn-requirements)VPN 要件 [Anypoint 仮想プライベートネットワーク](https://docs.mulesoft.com/jp/cloudhub-2/ps-vpn-about)で推奨事項と制限事項を確認してください。 - [VPN 名](#vpn-name) - [リモート IP アドレス](#remote-ip-address) - [動的 VPN ルーティング (BGP)](#dynamic-vpn-routing) - [静的 VPN ルーティング](#static-vpn-routing) - [ローカル ASN](#local-asn) - [リモート ASN](#remote-asn)​ (動的ルーティングのみ) - [静的 IP プレフィックス](#static-ip-prefixes)​ (静的ルーティングのみ) - [内部 IP CIDR](#inside-ip-cidrs)​ (高度なトンネル設定のみ) - [事前共有キー](#preshared-keys)​ (高度なトンネル設定のみ) - [自動トンネル開始](#auto-tunnel-initiation)​ (高度なトンネル設定のみ) - [サポートされるゲートウェイデバイス](#supported-gateway-devices)
ルーティングを設定する前に、ネットワークを統合して接続数を可能な限り少なく抑えてください。 接続の数には関係なく、非公開スペースごとに最大 95 件のルートテーブルエントリが許可されます。
### [](#vpn-name)VPN 名 _VPN 名_​は、VPN 接続の名前です。 ### [](#remote-ip-address)リモート IP アドレス _リモート IP アドレス_​は、VPN エンドポイントの公開 (1 つの静的) IP アドレスです。 ### [](#dynamic-vpn-routing)動的 VPN ルーティング (BGP) 動的ルーティングの場合、ユーザーのデバイスがボーダーゲートウェイプロトコル (BGP) を使用して Anypoint VPN へのルートを動的にアドバタイズします。 デバイスが BGP をサポートしている場合、動的ルーティングを選択できます。それ以外の場合は、静的ルーティングを選択します。 動的 VPN 接続を作成するには、静的 VPN 接続の要件に加えて、VPN デバイスで以下が可能である必要があります。 - BGP ピアリングを確立する - ルートベースの VPN をサポートする (トンネルを論理インターフェースにバインドする) - IPsec の場合、Diffie-Hellman フェーズ 2 グループ 2、5、14 ~ 24 を使用した Perfect Forward Secrecy (PFS) の有効化。 ### [](#static-vpn-routing)静的 VPN ルーティング ゲートウェイデバイスが BGP をサポートしていない場合、静的ルーティングを使用する必要があります。 独自のシークレットを提供する場合は、静的ルーティングを使用することもできます。 静的ルーティングでは、Anypoint VPN を介したアクセスを可能にするネットワークのルート (サブネット) を指定する必要があります。 静的 VPN 接続を作成するには、ユーザーの VPN エンドポイントで以下が可能である必要があります。 - 事前共有キー (PSK) を使用して IKE セキュリティアソシエーションを確立する - トンネルモードで IPsec セキュリティアソシエーションを確立する - Anypoint Platform がサポートする IPsec 設定の任意の組み合わせを使用する - 暗号化前に IP パケットを分割する 送信するのに大きすぎるパケットは分割する必要があります。 ゲートウェイデバイスは、パケットをカプセル化する前に分割できる必要があります。 - トンネルごとの 1 つのセキュリティアソシエーション (SA) ペアの使用 Anypoint VPN では、トンネルごとに一意の 1 組の SA ペア (1 つのインバウンド接続と 1 つのアウトバウンド接続) がサポートされます。 一部のポリシーベースのデバイスは、各 ACL (アクセスコントロールリスト) エントリに対して SA を作成します。 この場合は、ルールを統合してから、不要なトラフィックを除去する必要があります。 - IPsec デッドピア検出 (DPD) の使用 DPD により、デバイスはネットワーク条件の変化をすばやく特定できます。 Anypoint Platform エンドポイントでの DPD は ​`DPD Interval: 10`​ と ​`DPD Retries: 3`​ で有効化できます。 - 非対称ルーティングの許可 非対称ルーティングとは、ルーティングポリシーによってネットワークから非公開スペースに送信されるトラフィックと非公開スペースから返されるトラフィックが別々のトンネルを通るルーティング方式です。 Anypoint Platform VPN エンドポイントは、内部アルゴリズムを使用してトンネルを選択するため、戻りパスは動的に決定されます。 デバイスでアクティブ/アクティブトンネル設定を使用している場合は、各 Anypoint VPN 接続で非対称ルーティングを許可する必要があります。 - IPsec の場合、Diffie-Hellman フェーズ 2 グループ 2、5、14 ~ 24 を使用した Perfect Forward Secrecy (PFS) の有効化。 ### [](#local-asn)ローカル ASN _ローカル ASN_​ (自律システム番号) では、VPN の Anypoint Platform 側に割り当てるプライベート ASN (​`64512–65534`​) を指定します。 ネットワークに割り当てられていないプライベート ASN を使用してください。 デフォルト値は ​`64512`​ です。
静的ルーティングと動的ルーティングの両方に対してローカル ASN を設定します。
ローカル ASN は静的ルーティングには使用されませんが、最初の VPN を作成するときにこの値を指定する必要があります。これは、この非公開スペースに BGP を使用する将来の VPN 接続で必要になるためです。 非公開スペースで作成する後続の VPN では、​**\[Local ASN (ローカル ASN)\]**​ オプションは静的ルーティングに使用できません。 VPN の作成後にローカル ASN を変更するには、最初に既存の接続をすべて削除する必要があります。 ### [](#remote-asn)リモート ASN _リモート ASN_​ では、バックエンドに対応するプライベート ASN を指定します。
動的ルーティング専用のリモート ASN を設定します。
ネットワークに割り当てられている既存の ASN、またはネットワークに割り当てられていないプライベート ASN (​`64512–65534`​) を使用します。 デフォルト値は ​`65001`​ です。 ### [](#static-ip-prefixes)静的 IP プレフィックス _静的 IP プレフィックス_​は、Anypoint Platform の非公開ネットワークに CIDR 表記でアドバタイズする IP プレフィックスです。
静的 IP プレフィックスは、静的ルーティングに対してのみ設定します。
VPN 接続の数には関係なく、非公開ネットワークごとに最大 95 件のルートテーブルエントリが許可されます。 この制限を超えないように、ネットワークを統合して接続数を可能な限り少なく抑えてください。 ### [](#advanced-tunnel-configuration)高度なトンネル設定 (省略可能) 内部 IP CIDR および事前共有キーにカスタム値を指定する場合、または自動トンネル開始を無効にする場合、トンネル設定をカスタマイズできます。 指定しない値はすべてデフォルトに設定されます。 #### [](#inside-ip-cidrs)内部 IP CIDR _内部 IP CIDR_​ は、VPN トンネルの内部アドレスの IP アドレス範囲です。
内部 IP CIDR は、カスタムトンネル設定に対してのみ指定します。 自動トンネル設定の場合、これらの値は自動生成されます。
各トンネルに対して、VPN トンネルの内部アドレスの IP アドレス範囲を入力します。 `169.254.0.0/16`​ 範囲から、サイズ /30 の CIDR ブロックを指定できます。 CIDR ブロックはすべての非公開ネットワーク接続で一意であることが必要です。 次の CIDR ブロックのリストは使用できません。 169.254.0.0/30 169.254.1.0/30 169.254.2.0/30 169.254.3.0/30 169.254.4.0/30 169.254.5.0/30 169.254.169.252/30 #### [](#preshared-keys)事前共有キー _事前共有キー_​ (PSK) は、VPN トンネルの接続の 2 つのエンドポイント間で以前に共有された共有シークレットです。
カスタムトンネル設定に対してのみ PSK を指定します。 自動トンネル設定の場合、これらの値は自動生成されます。
静的接続の場合、VPN エンドポイントは事前共有キー (PSK) を使用して IKE セキュリティアソシエーションを確立します。 各トンネルに対して、先頭が 0 ではない 8 ~ 64 文字の値を入力します。 英数字、ピリオド (.)、およびアンダースコア (\_) のみを使用してください。 #### [](#auto-tunnel-initiation)自動トンネル開始 デフォルトでは、VPN トンネルは自動的に開始されます。 このオプションを選択解除した場合、カスタマーゲートウェイからのトラフィックを生成して VPN トンネルを確立する必要があります。 この設定は接続内のすべての VPN に適用され、このオプションは後続の冗長 VPN では使用できません。
VPN の作成後にトンネル開始を変更すると、この接続内のすべての VPN が再起動されます。
### [](#supported-gateway-devices)サポートされるゲートウェイデバイス _ゲートウェイデバイス_​は、VPN 接続の組織側にある物理的なアプライアンスまたはソフトウェアアプライアンスです。 ネットワーク管理者は、Anypoint VPN 接続で動作するようにデバイスを設定する必要があります。 Anypoint VPN で動作することがわかっているゲートウェイネットワークデバイスを以下に示します。 テスト済みデバイスのリストに自分のデバイスが記載されていない場合は、要件を参照して、自分のデバイスが Anypoint VPN での使用に適しているかどうかを確認してください。 [動的 VPN ルーティング (BGP)](#dynamic-vpn-routing)​および​[静的 VPN ルーティング](#static-vpn-routing)​を参照してください。
Table 1. サポートされるゲートウェイデバイス
デバイスベンダー デバイスのプラットフォーム デバイスソフトウェア

Check Point

Security Gateway

R77.10 以降

Cisco

ASA

ASA 8.2 以降

IOS

Cisco IOS 12.4 以降

Dell

SonicWALL

SonicOS 5.9 以降

Fortinet

Fortigate 40+ Series

FortiOS 4.0 以降

Juniper

J-Series Service Router

JunOS 9.5 以降

SRX-Series Services Gateway

JunOS 11.0 以降

SSG

ScreenOS 6.1 または 6.2 以降

ISG

ScreenOS 6.1 または 6.2 以降

Netgate

pfSense

OS 2.2.5 以降

Palo Alto Networks

PANOS 4.1.2 以降

Yamaha

RT107e

RTX1200

RTX1210

RTX1500

RTX3000

SRT100

Microsoft

Windows Server

2008 R2 以降

2012 R2 以降

Zyxel

Zywall Series

4.静的にルーティングされる Anypoint VPN 接続の場合は 20 以降

4.動的にルーティングされる Anypoint VPN 接続の場合は 30 以降

## [](#redundant-vpn)冗長 VPN **リモート ASN**​ のデフォルト値は、最初の VPN から継承されます。 この値は変更できます。 ## [](#tgw-requirements)トランジットゲートウェイアタッチメントの要件 - [トランジットゲートウェイ名](#transit-gateway-name) - [トランジットゲートウェイリージョン](#transit-gateway-region) - [トランジットゲートウェイのルーティング](#transit-gateway-routing)
ルーティングを設定する前に、ネットワークを統合して接続数を可能な限り少なく抑えてください。 接続の数には関係なく、非公開スペースごとに最大 95 件のルートテーブルエントリが許可されます。
### [](#始める前に)始める前に CloudHub にトランジットゲートウェイを追加する前に、次の操作を実行します。 - 企業 AWS アカウントでトランジットゲートウェイを作成する。 AWS でのトランジットゲートウェイの作成については、AWS ドキュメントの [「Getting started with transit gateways (トランジットゲートウェイ入門)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html)​を参照してください。 1 つのトランジットゲートウェイで最大 10 個の VPC アタッチメントをサポートできます。 - AWS トランジットゲートウェイエンタイトルメントを含む非公開スペースサービスを購入する。 **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページは、Anypoint VPC および VPN ライセンスを持つ Anypoint 組織に Runtime Manager で表示されます。 1 つの Anypoint VPC を AWS トランジットゲートウェイにアタッチするために、1 つの Anypoint VPN ライセンスを使用します。 - 「CloudHub 2.0 Network Administrator (CloudHub 2.0 ネットワーク管理者)」または「CloudHub 2.0 Network Viewer (CloudHub 2.0 ネットワーク閲覧者)」ユーザー権限を使用して Anypoint Platform アカウントにサインインする。 [「Grant Permissions and Roles to Users (ユーザーへの権限とロールの付与)」](https://docs.mulesoft.com/jp/access-management/users#grant-user-permissions)​を参照してください。 - トランジットゲートウェイを通じてアクセス可能にするネットワークのサブネットを識別 (CIDR 表記) する。 ### [](#transit-gateway-name)トランジットゲートウェイ名 トランジットゲートウェイアタッチメント名には最大 255 文字の英数字 (a-z、A-Z、0-9) およびハイフン (-) を含めることができます。 Runtime Manager では、非公開スペース名で Unicode 文字がサポートされています。 AWS のトランジットゲートウェイに同じ名前を使用します。 この名前は後から変更できます。 ### [](#transit-gateway-region)トランジットゲートウェイリージョン AWS トランジットゲートウェイの場所に対応するリージョン。 非公開スペースと AWS トランジットゲートウェイは同じリージョンにある必要があります。 ### [](#transit-gateway-routing)トランジットゲートウェイのルーティング トランジットゲートウェイアタッチメントの数に関係なく、VPC ごとに最大 95 件のルートテーブルエントリが許可されます。 制限を超えないように、可能な限り少ない数にネットワークを統合してください。 ### [](#mulesoft-aws-account-id)MuleSoft AWS アカウント ID MuleSoft AWS アカウント ID は、US クラウドや EU クラウドなどのコントロールプレーンによって異なり、トランジットゲートウェイ接続の作成を選択すると、​**\[Add transit gateway (トランジットゲートウェイを追加)\]**​ ページに表示されます。 AWS でリソース共有を作成するときに、この ID を指定して、Anypoint Platform がリソース共有にアクセスできるようにします。 別のチームが AWS 設定を行う場合は、この MuleSoft AWS アカウント ID をチームと共有します。 ### [](#resource-share-id-owner)リソース共有 ID およびオーナー リソース共有 ID およびオーナーは、AWS の ​**\[Create a resource share (リソース共有を作成)\]**​ ページに表示されます。 これらの値を使用して、Anypoint Platform のリソース共有を検証します。 - リソース共有の ​**\[ID\]**​ 項目には英数字 (a-z、A-Z、0-9) およびハイフン (-) を使用できます。 - リソース共有の ​**\[Owner (オーナー)\]**​ 項目には数値しか使用できません。 ## [](#関連情報)関連情報 - [非公開スペース](https://docs.mulesoft.com/jp/cloudhub-2/ch2-private-space-about) - [Anypoint 仮想プライベートネットワーク](https://docs.mulesoft.com/jp/cloudhub-2/ps-vpn-about) # 権限の割り当て 非公開スペースをセットアップする前に、ユーザーアカウントまたは所属するチームに必要な権限が割り当てられていることを確認します。 権限を割り当てるには、アクセス管理へのアクセス権と「Organization Administrator (組織のシステム管理者)」権限が必要です。 - 非公開スペースをセットアップおよび管理するには、「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限が必要です。 - 組織内の各ユーザーとして非公開スペースを表示するには、次の権限のいずれか 1 つ以上が必要です。 - 非公開スペースとその詳細を表示できる「Cloudhub Network Viewer (CloudHub ネットワーク閲覧者)」。 - 非公開スペースを管理して更新できる組織のシステム管理者。 - 非公開スペースを管理して更新できる「Cloudhub Network Administrator (CloudHub ネットワーク管理者)」。 上記のいずれかの権限が 1 つ以上ない場合、​**\[Private Spaces (非公開スペース)\]**​ タブの選択時に詳細を確認できません。代わりに、​**\[Not Authorized (未承認)\]**​ メッセージが表示されます。 - Exchange からアプリケーションをデプロイするには、アセットを所有するビジネス組織に「Exchange Contributor (Exchange コントリビューター)」権限と「Exchange Viewers (Exchange 閲覧者)」権限を割り当てる必要があります。 - Runtime Manager でアプリケーションをデプロイするには、「Create Applications (アプリケーションの作成)」権限が必要です。 - Runtime Manager の ​**\[Applications (アプリケーション)\]**​ ページですべてのアプリケーションを表示するには、「Read Applications (アプリケーションの読み取り)」および「CloudHub Network Viewer (CloudHub ネットワーク閲覧者)」権限が必要です。 - Runtime Fabric および CloudHub 2.0 にデプロイされたアプリケーションを表示するには、次の 2 つの権限も必要です。 - Read Applications for the Environment (環境のアプリケーションの読み取り) - Read Runtime Fabrics for the Business Group (ビジネスグループの Runtime Fabric の読み取り) - **「Create Applications (アプリケーションの作成)」**​ロールをユーザーに割り当てると、アプリケーションのデプロイに必要な​**「Read Applications (アプリケーションの読み取り)」**​ロールも付与されます。 - CloudHub 2.0 および Runtime Fabric にデプロイされたアプリケーションでスケジュールを表示するには、アセットを所有するビジネス組織に「Exchange Viewer (Exchange 閲覧者)」権限を割り当てる必要があります。 組織の権限構造に応じて、​[チーム](https://docs.mulesoft.com/jp/access-management/teams)​機能、​[ロール](https://docs.mulesoft.com/jp/access-management/users#grant-user-permissions)​機能 (非推奨) を使用するか、​[個々のユーザー権限](https://docs.mulesoft.com/jp/access-management/users#grant-user-permissions)​を割り当てることで、これらの権限を割り当てることができます。 「Organization Administrator (組織のシステム管理者)」権限を持つユーザーは、Anypoint Platform 全体ですべての非公開スペースと追加の権限を表示および管理することもできます。ただし、CloudHub 2.0 固有の権限の代わりとしてこの権限を割り当てないでください。詳細は、​[「一般的な権限」](https://docs.mulesoft.com/jp/access-management/permissions-by-product)​を参照してください。 ## [](#関連情報)関連情報 - [アクセス管理について](https://docs.mulesoft.com/jp/access-management/) # 脆弱性評価と侵入テストの実行 Unresolved include directive in modules/ROOT/pages/ch2-penetration-testing-policies.adoc - include::cloudhub::partial$ch-penetration-testing.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-penetration-testing-policies.adoc - include::cloudhub::partial$ch-penetration-testing.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-penetration-testing-policies.adoc - include::cloudhub::partial$ch-penetration-testing.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-penetration-testing-policies.adoc - include::cloudhub::partial$ch-penetration-testing.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-penetration-testing-policies.adoc - include::cloudhub::partial$ch-penetration-testing.adoc\[\] Unresolved include directive in modules/ROOT/pages/ch2-penetration-testing-policies.adoc - include::cloudhub::partial$ch-penetration-testing.adoc\[\] ## [](#関連情報)関連情報 - [CloudHub 2.0 の概要](https://docs.mulesoft.com/jp/cloudhub-2/) - [CloudHub 2.0 へのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy) - [CloudHub 2.0 にデプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-apps) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) # 非公開スペース _非公開スペース_​は、アプリケーションを実行する CloudHub 2.0 の仮想、非公開、および分離論理スペースです。 同じリージョンまたは異なるリージョンに複数の非公開スペースを作成できます。 非公開イントラネットを非公開スペースに接続して、1 つの非公開ネットワークとして機能させます。 各非公開スペースで、次の情報を定義します。 - この非公開スペースにデプロイされたアプリケーションが実行される仮想クラウドである​_非公開ネットワーク_​。 - Anypoint VPN またはトランジットゲートウェイを介した、非公開ネットワークから外部ネットワークへの 1 つ以上の接続。 - アプリケーションを非公開スペースにデプロイするときに使用できるドメインを定義し、必要に応じて相互 TLS を有効にする TLS コンテキスト。 - 非公開スペースへのインバウンドおよびアウトバウンドトラフィックを許可およびブロックするファイアウォールルール。 - 非公開スペースへのデプロイを許可する環境とビジネスグループ。 非公開スペースを作成すると、Mule Runtime のライセンスが自動的に挿入され、MuleSoft によって管理されます。 ## [](#非公開ネットワーク)非公開ネットワーク 非公開ネットワークを作成するときは、非公開スペース内のアプリケーションで使用する IP アドレスの範囲、アプリケーションが実行されるリージョン、および必要に応じて内部 DNS サーバーを関連付けて、カスタムドメインへの要求を解決します。 1 つのリージョンで複数の非公開スペースを設定できるため、開発環境やステージング環境など、本番環境と本番以外の環境用に分離された個別のネットワークをセットアップできます。 リージョンについての詳細は、​[「非公開ネットワークリージョン」](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#private-network-region)​を参照してください。 ## [](#非公開ネットワーク接続)非公開ネットワーク接続 次の方法を使用して、非公開スペースを非公開ネットワークに接続できます。 - [Anypoint 仮想プライベートネットワーク](https://docs.mulesoft.com/jp/cloudhub-2/ps-vpn-about) - [トランジットゲートウェイアタッチメント](https://docs.mulesoft.com/jp/cloudhub-2/ps-tgw-about) ## [](#tls-コンテキスト)TLS コンテキスト CloudHub 2.0 では、Transport Layer Security (TLS) コンテキストの使用により、クライアントがカスタムドメインとパスを使用して、非公開スペースにデプロイされたアプリケーションに到達できます。 非公開スペースをセットアップする場合、アプリケーションを非公開スペースにデプロイするときに使用可能なドメインを定義する Transport Layer Security (TLS) コンテキストを設定し、必要に応じて相互 TLS を有効にします。 アプリケーションを非公開スペースにデプロイする場合、TLS コンテキストのドメインを使用して、クライアントがインターネットからアプリケーションに到達するために使用する複数のエンドポイントを設定できます。 TLS コンテキストのドメインにワイルドカードが含まれる場合、アプリケーション名や組織などの省略可能なサブドメインを設定できます。 必要な数のエンドポイントを作成できます。 ## [](#パス書き換え)パス書き換え アプリケーションがリスンするベースパスとは異なるパスからアクセスできるように、アプリケーションを設定できます。 ## [](#ファイアウォールルール)ファイアウォールルール 非公開スペースとの間のトラフィックを制御します。 Inbound (インバウンド) デフォルトでは、CloudHub 2.0 はポート 80 (HTTP) および 443 (HTTPS) 上の非公開スペースへのトラフィックを任意の場所 (0.0.0.0/0) から許可します。指定したポートを介した接続を許可したり、ポートを削除したり、ポート 80 と 443 を使用して非公開スペースへのトラフィックを制御したりするように、ファイアウォールルールを設定します。 非公開スペースでは負荷分散が提供され、アプリケーションへのインバウンドトラフィックが複数のレプリカに分散されます。 Outbound デフォルトでは、CloudHub 2.0 は非公開スペースから非公開スペース外部の宛先へのすべてのトラフィックを許可します。このルールを削除し、指定されたポートでのみトラフィックを許可するようにファイアウォールルールを設定します。 ファイアウォールルールと TLS コンテキスト設定を組み合わせることで、アプリケーショントラフィックのイングレスとエグレスを微調整できます。 ## [](#関連情報)関連情報 - [非公開スペースの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure) - [VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn) - [トランジットゲートウェイアタッチメントの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw) - [非公開スペースの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-configure) - [非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains) - [非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules) - [ビジネスグループと環境の非公開スペースへの関連付け](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-env) - [非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths) # 非公開スペース _非公開スペース_​は、アプリケーションを実行する CloudHub 2.0 の仮想、非公開、および分離領域です。 同じリージョンまたは異なるリージョンに複数の非公開スペースを作成できます。 非公開イントラネットを非公開スペースに接続して、1 つの非公開ネットワークとして機能させます。 各非公開スペースで、次の情報を定義します。 - この非公開スペースにデプロイされたアプリケーションが実行される仮想クラウドである​_非公開ネットワーク_​。 - Anypoint VPN またはトランジットゲートウェイ接続を介した、非公開ネットワークから外部ネットワークへの接続。 - アプリケーションを非公開スペースにデプロイするときに使用できるドメインを定義する TLS コンテキスト。 - 非公開スペースへのインバウンドおよびアウトバウンドトラフィックを許可およびブロックするファイアウォールルール。 - 非公開スペースへのデプロイを許可する環境とビジネスグループ。 - ログの転送先 (Anypoint Monitoring または Splunk などの外部サービス)。 ## [](#非公開ネットワーク)非公開ネットワーク 非公開ネットワークを作成するときは、非公開スペース内のアプリケーションで使用する IP アドレスの範囲、アプリケーションが実行されるリージョン、および必要に応じて内部 DNS サーバーを関連付けて、カスタムドメインへの要求を解決します。 非公開スペースでは、Amazon リージョンがサポートされています。 1 つの Amazon リージョンで複数の非公開スペースを設定できるため、QA 環境やステージング環境など、本番環境と本番以外の環境用に分離された個別のネットワークをセットアップできます。 ## [](#非公開ネットワーク接続)非公開ネットワーク接続 次の方法を使用して、非公開スペースを非公開ネットワークに接続できます。 - [Anypoint 仮想プライベートネットワーク](https://docs.mulesoft.com/jp/cloudhub-2/ps-vpn-about) - [トランジットゲートウェイアタッチメント](https://docs.mulesoft.com/jp/cloudhub-2/ps-tgw-about)
ルーティングを設定する前に、ネットワークを統合して接続数を可能な限り少なく抑えてください。 接続の数には関係なく、非公開スペースごとに最大 95 件のルートテーブルエントリが許可されます。
## [](#tls-コンテキスト)TLS コンテキスト CloudHub 2.0 では、Transport Layer Security (TLS) コンテキストの使用により、クライアントがカスタムドメインを使用して、非公開スペースにデプロイされたアプリケーションに到達できます。 非公開スペースをセットアップする場合、アプリケーションを非公開スペースにデプロイするときに使用可能なドメインを定義する Transport Layer Security (TLS) コンテキストを設定します。 アプリケーションを非公開スペースにデプロイする場合、TLS コンテキストのドメインを使用して、クライアントがインターネットからアプリケーションに到達するために使用する複数のエンドポイントを設定します。 TLS コンテキストのドメインにワイルドカードが含まれる場合、アプリケーション名や組織などの省略可能なサブドメインを設定できます。 必要な数のエンドポイントを作成できます。 カスタムドメインに加えて、アプリケーションがリスンするベースパスとは異なるパスからアクセスできるように、アプリケーションを設定できます。 ## [](#ファイアウォールルール)ファイアウォールルール 非公開スペースとの間のトラフィックを制御します。 デフォルトでは、CloudHub 2.0 は非公開スペースへのすべてのトラフィックをブロックし、指定されたポートを介した接続を許可するファイアウォールルールを提供します。 追加のファイアウォールルールを設定して、非公開スペースへのトラフィックを制御し、カスタムポートを公開またはブロックし、アプリケーションへの要求をブロックできます。 非公開スペースでは負荷分散が提供され、アプリケーションへのインバウンドトラフィックが複数のレプリカに分散されます。 ファイアウォールルールと TLS コンテキスト設定を組み合わせることで、外部サービスがアプリケーションに到達する方法を微調整できます。 ## [](#関連情報)関連情報 - [非公開スペースの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure) - [VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn) - [トランジットゲートウェイアタッチメントの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw) - [非公開スペースの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-configure) - [非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains) - [非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules) - [ビジネスグループと環境の非公開スペースへの関連付け](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-env) - [非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths) # 非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定 デフォルトでは、ファイアウォールルールで明示的に許可されていない限り、非公開スペースへのすべてのトラフィックがブロックされます。 非公開スペースを作成すると、次のファイアウォールルールが自動的に作成されます。 - 任意のホストからのインバウンド接続を許可する 2 つのルール: - HTTPS: ポート 443 - HTTP: ポート 80 - 非公開スペース内から任意のホストへのアウトバウンド接続を許可する 2 つのルール: - TCP: すべてのポート - HTTPS: 443 プロトコルとして TCP を使用するインバウンドファイアウォールルールを設定することもできます。 Anypoint MQ、API Manager、および ObjectStore v2 をサポートするには、ポート 443 (HTTPS) でアウトバウンドトラフィックを許可する必要があります。 ## [](#ファイアウォールルールを設定する)ファイアウォールルールを設定する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Firewall rules (ファイアウォールルール)\]**​ タブをクリックします。 4. ドロップダウンリストから ​**\[Protocol (プロトコル)\]**​ と ​**\[Source (ソース)\]**​ を選択し、インバウンドトラフィックのデフォルトルールを設定します。 Protocol (プロトコル) プロトコル種別: - **HTTP** - **HTTPS** Source (ソース) ソース IP アドレス: - **Anywhere (0.0.0.0/0) (すべて (0.0.0.0/0))** - **Local private network (ローカル非公開ネットワーク)** このオプションは、非公開ネットワークが非公開スペース内に存在する場合にのみ使用できます。 ポート インバウンドトラフィックのポートは設定できません。 - ポート 80 は HTTP 用に予約されています。 - ポート 443 は HTTPS 用に予約されています。 - 1024 未満のその他のポートは使用できません。プレーン TCP 接続ではポート 1024 以上がサポートされていますが、追加の HTTP/HTTPS イングレスエンドポイントではサポートされていません。 5. ドロップダウンリストから ​**\[Protocol (プロトコル)\]**​ と ​**\[Destination (宛先)\]**​ を選択し、アウトバウンドトラフィックのデフォルトルールを設定します。 Protocol (プロトコル) プロトコル種別: - **All (すべて)** - **TCP** - **UTP** - **HTTP** - **HTTPS** Destination (宛先) 宛先 IP アドレス: - **Anywhere (0.0.0.0/0) (すべて (0.0.0.0/0))** - **Local private network (ローカル非公開ネットワーク)** このオプションは、非公開ネットワークが非公開スペース内に存在する場合にのみ使用できます。 ポート アウトバウンドトラフィックのポート範囲を設定できます。 6. **\[Add rule (ルールを追加)\]**​ をクリックしてルールをさらに追加します。 7. ファイアウォールルールを削除するには、エントリのゴミ箱アイコン (​**\[Delete (削除)\]**​) をクリックします。 ![「Firewall rules (ファイアウォールルール)」 タブの削除アイコン](/mulesoft/current/ja-jp/cloudhub-2/_images/fw-rule-delete.png) 8. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard changes (変更を破棄)\]**​ をクリックします。
重複するファイアウォールルールを設定することはできません。重複するファイアウォールルールを設定しようとすると、エラーが表示され、重複するファイアウォールルールを削除するように求められます。
# 非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定
CloudHub 2.0 では、共有スペースではなく非公開スペースにデプロイされたアプリケーションでのみ、エンドポイントのカスタマイズがサポートされています。
非公開スペースは、クライアントからの要求を非公開スペースにデプロイされたアプリケーションに転送します。 アプリケーションを非公開スペースにデプロイすると、2 種類の​_エンドポイント_​が作成されます。 - **エンドポイント**​: 公開スペースにデプロイされたアプリケーションに到達するために使用される URL。このコンテキストでは、外部からエンドポイントにアクセスできるため、ネットワーク外のクライアントがアプリケーションに到達できます。このエンドポイントを削除すれば、外部トラフィックがアプリケーションに到達することを回避できます。 - **内部エンドポイント**​: 公開スペースにデプロイされたアプリケーションに到達するために使用される URL。ただし、非公開ネットワーク内、VPN、またはトランジットゲートウェイ (TGW) でのみアクセスできます。このエンドポイント種別は変更または削除できません。 エンドポイント URL の例としては、​`https://my-app.example.com/`​ のようになります。エンドポイントでは、ネットワーク外のクライアントがアプリケーションに到達できます。内部エンドポイントには、非公開ネットワーク内、VPN、またはトランジットゲートウェイ (TGW) でのみアクセスできます。ネットワーク内でのみアプリケーションにアクセスできるようにするには、内部エンドポイントを使用します。 次の設定により、クライアントからの要求がアプリケーションに到達する方法をカスタマイズできます。 - 複数のカスタムエンドポイント システム管理者は、非公開スペース設定で TLS コンテキストを設定することにより、エンドポイントに使用できるドメインを指定します。 詳細は、[非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains)を参照してください。 - アプリケーションとエンドポイント URL で異なるパス _パス_​は、アプリケーションの HTTP リスナーに必要なベースパス (​`my-app.example.com/v1/api`​ など) です。 詳細は、​[「HTTP リスナーリファレンス - Mule 4」](https://docs.mulesoft.com/http-connector/latest/http-listener-ref)​を参照してください。 エンドポイントを削除して、非公開ネットワークの外部にあるクライアントがアプリケーションに要求を送信できないようにすることもできます。 ## [](#before-you-begin)始める前に システム管理者は、アプリケーションのエンドポイントとパスを設定する前に、非公開スペースの TLS コンテキストをセットアップする必要があります。 詳細は、[非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains)を参照してください。 ## [](#configure-multiple-endpoints)複数のエンドポイントを設定する 複数のエンドポイント (​`my-app.example.com`​ と ​`my-old-app.oldname.com`​ など) を介してアプリケーションに到達可能にすることができます。
各エンドポイント名が一意になるように、サブドメインで ​app-name​ プレースホルダーを使用するか、ドメインにワイルドカードが含まれていない場合はパスを使用します。
複数のエンドポイントを設定する手順は、次のとおりです。 1. アプリケーションを非公開スペースにデプロイする場合、​**\[Ingress (イングレス)\]**​ タブをクリックします。 [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)を参照してください。 アプリケーションがすでにデプロイ済みの場合: 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Ingress (イングレス)\]**​ タブをクリックします。 2. 最初のエンドポイントを設定します。 1. **\[Domain (ドメイン)\]**​ ドロップダウンリストから、最初のドメイン (​`*.example.com`​ など) を選択します。 ドメインにワイルドカードが含まれる場合、​**\[Subdomain (サブドメイン)\]**​ 項目を使用できます。 2. サブドメインを入力するか、​**\[Subdomain (サブドメイン)\]**​ 項目に ​`my-app`​ プレースホルダーを入力して、​**\[Application Name (アプリケーション名)\]**​ 項目で指定したアプリケーションの名前をサブドメインとして使用します。 詳細は、​[「プレースホルダー」](#placeholder-table)​を参照してください。 3. アプリケーションの HTTP リスナーがリスンするパス (​`v1/api`​ など) を入力します。 3. 追加のエンドポイントを設定する場合は、​**\[Add Endpoint (エンドポイントを追加)\]**​ をクリックして、ステップ 2.1 ~ 2.3 を繰り返します。 4. デプロイメントの状況に応じて、次のいずれかを選択します。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy (デプロイ)\]**​ をクリックします。 - このアプリケーションがデプロイされている場合、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 5. 設定された各エンドポイントでアプリケーションに到達できることを確認します。 ### [](#placeholder-table)プレースホルダー サブドメインとパスでは、次の小文字プレースホルダー (省略可能) がサポートされます。
プレースホルダー 解決対象

app-name

アプリケーションをデプロイするときに ​[Application Name (アプリケーション名)]​ 項目で指定したアプリケーションの名前

business-group-id

アプリケーションに関連付けられビジネスグループ ID

environment-id

アプリケーションをデプロイする環境

## [](#configure-different-paths)アプリケーションと URL エンドポイントに異なるパスを設定する アプリケーションと URL エンドポイントに異なるパスを設定できます。 たとえば、アプリケーションが ​`my-app.example.com/v1/api`​ でリスンしているときに、​`my-app.example.com/api`​ を使用してインターネットからアプリケーションにアクセスすることができます。 パス URL を書き換えると、新しいパスがすべてのエンドポイントに適用されます。 異なるパスを設定する手順は、次のとおりです。 1. [非公開スペースにアプリケーションをデプロイします](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)​。 2. **\[Ingress (イングレス)\]**​ タブをクリックします。 3. **\[Path (パス)\]**​ 項目で、アプリケーションにアクセスできるようにするパス (​`/api`​ など) を入力します。 4. **\[Path Rewrite (パス書き換え)\]**​ 項目で、アプリケーションの HTTP リスナーに必要なベースパス (​`/v1/api`​ など) を入力します。 この項目は、カスタム TLS コンテキストでデプロイされたアプリケーションでのみ使用できます。 5. アプリケーションの新しい設定を作成するには、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#remove-external-endpoint)エンドポイントを削除する エンドポイントを変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Ingress (イングレス)\]**​ タブをクリックします。 5. エンドポイントリンクの行で、​**\[X\]**​ (​**\[Delete (削除)\]**​) をクリックします。 ## [](#view-internal-endpoint)アプリケーションの内部エンドポイントを表示する 内部エンドポイントには、同じ非公開スペース内から、または非公開スペースの VPN やトランジットゲートウェイ接続を介してアクセスできます。内部エンドポイントのパスまたはドメインを変更することはできません。 内部エンドポイントの URL を表示またはコピーする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Ingress (イングレス)\]**​ タブをクリックします。 5. **\[internal endpoint (内部エンドポイント)\]**​ にマウスポインターを置きます。 ## [](#非公開スペース内でアプリケーション間要求を送信する)非公開スペース内でアプリケーション間要求を送信する 非公開スペースでは、すべてのアプリケーションレプリカが非公開スペース内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。 非公開スペースの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`helloch2`​ の DNS レコードは次のとおりです。 ```none helloch2.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じ非公開スペース内の別のアプリケーションに要求を送信するには、アプリケーション名のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://helloch2:8081/hello ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。
svc.cluster.local​ エンドポイントを使用して、異なる名前空間のアプリケーション間でトラフィックを送信することはできません。
### [](#アプリケーション間の通信)アプリケーション間の通信 アプリケーション間の通信方法を次に示します。 - デフォルトの公開 DNS 名: `app.sxjsip.aus-s1.cloudhub.io` - デフォルトの内部 DNS 名 (非公開スペースのみ): `app.internal-sxjsip.aus-s1.cloudhub.io` - カスタムドメイン名 (設定されている場合): `acme.example.com` - クラスターローカル DNS: `app`​ または ​`app.envid.svc.cluster.local` 内部 DNS 名を使用する場合、トラフィックは非公開スペースネットワークに留まります。アプリケーションを非公開スペースにデプロイする場合、外部に公開されるエンドポイントを削除または省略できます。その場合、内部トラフィック用にアプリケーションの内部エンドポイントを使用できます。 クラスターローカルエンドポイントを使用する場合、トラフィックはクラスター内に留まります。ただし、クラスターローカルエンドポイントは高可用性ではありません。一部のクラスター操作 (障害回復など) により、エンドポイントに到達できなくなる可能性があります。 障害回復中にアプリケーションが新しいクラスターに移行すると、クラスターローカル DNS エンドポイントが失敗する可能性があります。これは、ローカル DNS エンドポイントを介してルーティングされるトラフィックが、トラフィックを新しいクラスターに転送するために必要なイングレスロードバランサーをトラバースしないために発生します。ただし、ほかの使用可能なエンドポイントを使用すると、トラフィックがイングレスロードバランサーを通過するようになります。イングレスロードバランサーは、障害回復イベントが発生しているかどうかを検出します。また、特定のエンドポイントにリンクされているアプリケーションが新しいクラスターに移動したかどうかも把握しています。これにより、必要に応じてトラフィックが新しいクラスターにルーティングされます。 複数のアプリケーションレプリカをデプロイすれば、ノードのアップグレードおよびスケーリング中にクラスターローカル DNS エンドポイントは到達可能な状態を維持できます。 クラスターローカルエンドポイントでは、同じ環境内のトラフィックのみが許可されます。 ## [](#関連情報)関連情報 - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains) - [HTTP リスナーリファレンス - Mule 4](https://docs.mulesoft.com/http-connector/latest/http-listener-ref) # 非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定 CloudHub 2.0 は、Transport Layer Security (TLS) コンテキストを使用して、非公開スペースへのインバウンドトラフィックを暗号化します。 TLS コンテキストを使用すると、カスタムドメインでアプリケーションに到達できるようになり、必要に応じて部分的なクライアント認証を有効にすることができます。 各非公開スペースには、デフォルトで 1 つの TLS コンテキスト (​`cloudhub.io`​ へのトラフィック用) が含まれています。これは削除できません。 デフォルトの証明書は自動的に更新され、ユーザーによる操作は必要ありません。 必要に応じて、追加の TLS コンテキストを作成できます。 非公開スペース用に設定する TLS コンテキストでは、アプリケーションを非公開スペースにデプロイするときに使用できるドメインを定義します。 [非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths)を参照してください。 ## [](#tls-コンテキスト)TLS コンテキスト 各 TLS コンテキストには、キーストアと省略可能なトラストストアが含まれます。 [TLS コンテキストを作成する](#create-tls-context)​手順は、次のとおりです。 1. キーストアをアップロードします。 2. トラストストアをアップロードします (省略可能)。 3. デフォルトの暗号化を受け入れるか、追加または削除する暗号化を選択します。 ### [](#キーストア)キーストア _キーストア_​は、セキュリティ証明書 (承認証明書または公開鍵証明書のいずれか)、および SSL 暗号化などで使用される対応する非公開鍵のリポジトリです。 キーストアにより、カスタムドメインを使用してアプリケーションと通信できます。 CloudHub 2.0 では、次のキーストア種別がサポートされています。 PEM (Privacy-Enhanced Mail) PEM ファイルは ​`.cer`​、​`.crt`​、または ​`.pem`​ 拡張子の Base64 でエンコードされた ASCII ファイルです。 PEM の場合、キーストアは次の要素で構成されます。 - 公開証明書 - 非公開鍵 - 認証機関 (CA) パスファイル (省略可能) PEM 形式のキーストアは、TLS のデフォルト値を使用します。 JKS (Java Keystore) JKS ファイルは認証用のリポジトリまたは公開鍵証明書です。 JKS ファイルをアップロードして TLS のデフォルト値を使用するには、このオプションを使用します。 このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。
JKS キーストアのアップロード後に証明書に問題が見つかったら、代わりに PEM ファイルを使用します。
### [](#トラストストア)トラストストア トラストストアは、サーバーが部分的なクライアント認証を適用するためにチェックするクライアント証明書のセットです。 省略可能なトラストストアは、信頼できる外部クライアントまたは認証機関 (CA) を識別します。 部分的なクライアント認証を有効にするには、トラストストアを設定します。 トラストストアが設定されていない場合、部分的なクライアント認証は無効になります。 CloudHub 2.0 は、PEM 形式のトラストストアファイルを受け入れます。 ### [](#dns-対象)DNS 対象 クライアントが非公開ネットワークの内外からアプリケーションにアクセスできるように、DNS 対象を設定します。 _公開 DNS 対象_​では、外部クライアントがカスタムドメインでアプリケーションにアクセスできます。 _非公開 DNS 対象_​には、非公開ネットワーク内から、または VPN やトランジットゲートウェイ接続を介してのみアクセスできます。接続された外部ネットワークの内部 DNS または許可リストでそれらを使用して、それらのネットワークのクライアントがアプリケーションに要求を送信できるようにします。 ### [](#暗号化)暗号化 TLS コンテキストを追加すると、TLS コンテキストで使用する暗号化を選択できます。 ## [](#before-you-begin)始める前に 1. キーストアを生成します。 - [PEM](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-ssl-endpoints#pem) - [JKS](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#generate-a-keystore) 2. [トラストストア](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#truststore-generation)​を生成します (部分的なクライアント認証を有効にする場合)。 3. ドメインの DNS レコードを作成します。 カスタムドメインを使用して非公開スペースにデプロイされたアプリケーションにトラフィックが到達できるようにする手順は、次のとおりです。 1. ドメイン登録機関にログインします。 [Whois](https://www.whois.com/)​ を使用して登録機関を検索します。 2. バニティドメインに CNAME レコードを作成し、ワイルドカードを使用していない非公開スペースの FQDN を参照します。 登録機関が変更を適用するまでに最大 24 時間かかります。 4. 非公開スペースを変更するために必要な「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限がアカウントにあることを確認します。 詳細は、[チームを使用したユーザーアクセスの管理](https://docs.mulesoft.com/jp/access-management/teams)を参照してください。 ## [](#create-tls-context)TLS コンテキストを作成する 新しい TLS コンテキストを作成する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Domains & TLS (ドメインと TLS)\]**​ タブをクリックし、​**\[Create TLS Context (TLS コンテキストを作成)\]**​ をクリックします。 「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限がない場合、​**\[Create TLS Context (TLS コンテキストを作成)\]**​ ボタンは使用できません。 4. TLS コンテキストの名前を入力します。 TLS コンテキスト名には、文字、数字、スペース、およびハイフンを含めることができます。 5. **キーストアを設定します**​。 PEM 形式 1. **\[Upload PEM files (PEM ファイルをアップロード)\]**​ を選択します。 2. **\[Choose File (ファイルを選択)\]**​ をクリックし、アップロードする公開証明書を選択します。 公開証明書をアップロードすると、証明書の概要が表示されます。 - キーストアの詳細を表示するには、​**\[…​\]**​ > ​**\[View Details (詳細を表示)\]**​ をクリックします。 - 公開証明書を削除するには、​**\[…​\]**​ > ​**\[Delete (削除)\]**​ をクリックします。 3. **\[Choose File (ファイルを選択)\]**​ をクリックし、アップロードする非公開鍵を選択します。 4. キーストア内の非公開鍵へのアクセスに使用するキーパスワードを入力します。 非公開鍵が暗号化されていない (プレーンテキストの) 場合 (非推奨)、​**\[Key Password (キーパスワード)\]**​ 項目は空白のままにします。 CloudHub 2.0 により、キーストアに対してパスワードが検証されます。 5. 認証機関 (CA) パス証明書ファイルがある場合は、​**\[Choose file (ファイルを選択)\]**​ をクリックしてアップロードします。 JKS 形式 1. **\[Upload JKS file (JKS ファイルをアップロード)\]**​ を選択します。 2. **\[Choose File (ファイルを選択)\]**​ をクリックし、アップロードするキーストアファイルを選択します。 3. キーストアファイルにアクセスするために使用するパスワードを入力します。 CloudHub 2.0 により、キーストアに対してパスワードが検証されます。 4. ドロップダウンリストから別名を選択します。 別名を選択すると、別名の概要が表示されます。 **\[i\]**​ をクリックすると、別名の詳細が表示されます。 5. キーストア内の非公開鍵へのアクセスに使用するキーパスワードを入力します。 CloudHub 2.0 により、鍵に対してパスワードが検証されます。 6. [始める前に](#before-you-begin)​の手順に従って、DNS を設定します。 7. **トラストストアを設定します (省略可能)。** 部分的なクライアント認証を使用する場合は、トラストストアを設定します。 トラストストアでは、設定されたキーストアで部分的なクライアント認証を有効にするために使用するクライアント証明書を定義します。 **\[Add Certificates (証明書を追加)\]**​ をクリックし、証明書ファイル (PEM 形式) をアップロードします。 PEM ファイルをアップロードすると、CloudHub 2.0 にトラストストアファイルからのクライアント証明書が表示されます。 - 追加の証明書ファイルをアップロードするには、​**\[Add Certificates (証明書を追加)\]**​ をクリックします。 - 個々のクライアント証明書の詳細を表示するには、情報アイコン (​**\[View Details (詳細を表示)\]**​) をクリックします。 - 個々のクライアント証明書を削除するには、ゴミ箱アイコン (​**\[Delete (削除)\]**​) をクリックします。 - 5 個以上の証明書がアップロードされている場合、​**\[Show all x Certificates (x 個すべての証明書を表示)\]**​ をクリックしてリンクを展開します。 8. **詳細オプションを設定します (省略可能)。** 暗号化をカスタマイズする場合、詳細オプションを設定します。 1. **\[Advanced Options (詳細オプション)\]**​ をクリックして暗号化設定を表示します。 2. **\[Use Default Ciphers (デフォルトの暗号化を使用)\]**​ または ​**\[Customize Ciphers (暗号化をカスタマイズ)\]**​ を選択します。 暗号化のカスタマイズを選択した場合、CloudHub 2.0 にデフォルトの (選択済みの) 暗号化が表示されます。 - リストから暗号化を削除するには、​**\[X\]**​ をクリックします。 - ドロップダウンリストから別の暗号を選択するには、​**\[Select (選択)\]**​ をクリックします。 9. 変更を破棄するには、​**\[Create TLS Context (TLS コンテキストを作成)\]**​ または ​**\[Cancel (キャンセル)\]**​ をクリックします。 ## [](#tls-コンテキストの詳細を表示する)TLS コンテキストの詳細を表示する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Domains & TLS (ドメインと TLS)\]**​ タブのカスタム TLS セクションで、TLS コンテキストメニュー (​**\[…​\]**​) をクリックし、​**\[View Details (詳細を表示)\]**​ を選択します。 ## [](#tls-コンテキストを削除する)TLS コンテキストを削除する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Domains & TLS (ドメインと TLS)\]**​ タブのカスタム TLS セッションで、TLS コンテキストメニュー (​**\[…​\]**​) をクリックし、​**\[Delete (削除)\]**​ を選択します。 **\[Delete (削除)\]**​ オプションは、「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限がある場合にのみ表示されます。 ## [](#tls-コンテキストを編集する)TLS コンテキストを編集する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Domains & TLS (ドメインと TLS)\]**​ タブをクリックし、​**\[Edit (編集)\]**​ をクリックします。 **\[Edit (編集)\]**​ ボタンは、「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限がある場合にのみ表示されます。 4. **キーストアを設定します**​。 PEM 形式 1. **\[Choose file (ファイルを選択)\]**​ をクリックし、現在の公開証明書を新しい公開証明書に置き換えます。 公開証明書を置き換えない限り、非公開鍵またはパスワードを変更することはできません。 公開証明書をアップロードすると、証明書の概要が表示されます。 情報アイコン (​**\[View Details (詳細を表示)\]**​) をクリックすると、キーストアの詳細が表示されます。 2. アップロードする非公開鍵を選択します。 3. キーストア内の非公開鍵へのアクセスに使用するパスワードを入力します。 キーパスワードが暗号化されていない (プレーンテキストの) 場合 (非推奨)、​**\[Key Password (キーパスワード)\]**​ 項目は空白のままにします。 CloudHub 2.0 により、キーストアに対してパスワードが検証されます。 4. 認証機関 (CA) パス証明書ファイルがある場合は、​**\[Choose file (ファイルを選択)\]**​ をクリックしてアップロードします。 公開証明書を置き換えることなく、CA パス証明書を削除および追加できます。 JKS 形式 1. **\[Choose file (ファイルを選択)\]**​ をクリックし、現在のキーストアファイルを新しいキーストアファイルに置き換えます。 2. キーストアファイルにアクセスするために使用するパスワードを入力します。 CloudHub 2.0 により、キーストアに対してパスワードが検証されます。 3. ドロップダウンリストから別名を選択します。 キーストアファイルを置き換えることなく、異なる別名を選択できます。 別名を選択すると、別名の概要が表示されます。 情報アイコン (​**\[View Details (詳細を表示)\]**​) をクリックすると、別名の詳細が表示されます。 4. キーストア内の非公開鍵へのアクセスに使用するキーパスワードを入力します。 CloudHub 2.0 により、鍵に対してパスワードが検証されます。 5. **トラストストアを設定します (省略可能)。** 部分的なクライアント認証を使用する場合は、トラストストアを設定します。 トラストストアでは、設定されたキーストアで部分的なクライアント認証を有効にするために使用するクライアント証明書を定義します。 **\[Add Certificates (証明書を追加)\]**​ をクリックし、証明書ファイル (PEM 形式) をアップロードします。 PEM ファイルをアップロードすると、CloudHub 2.0 にトラストストアファイルからのクライアント証明書が表示されます。 - 追加の証明書ファイルをアップロードするには、​**\[Add Certificates (証明書を追加)\]**​ をクリックします。 - 個々のクライアント証明書の詳細を表示するには、情報アイコン (​**\[View Details (詳細を表示)\]**​) をクリックします。 - 個々のクライアント証明書を削除するには、ゴミ箱アイコン (​**\[Delete (削除)\]**​) をクリックします。 6. **詳細オプションを設定します (省略可能)。** 暗号化をカスタマイズする場合、詳細オプションを設定します。 1. **\[Advanced options (詳細オプション)\]**​ をクリックして暗号化設定を表示します。 2. **\[Use Default Ciphers (デフォルトの暗号化を使用)\]**​ または ​**\[Customize Ciphers (暗号化をカスタマイズ)\]**​ を選択します。 暗号化のカスタマイズを選択した場合、CloudHub 2.0 にデフォルトの (選択済みの) 暗号化が表示されます。 - リストから暗号化を削除するには、​**\[X\]**​ をクリックします。 - 別の暗号化を選択するには、​**\[Select a cipher to add (追加する暗号化を選択)\]**​ をクリックします。 7. 変更を破棄するには、​**\[Update TLS Context (TLS コンテキストを更新)\]**​ または ​**\[Cancel (キャンセル)\]**​ をクリックします。 クライアントに ​`cloudhub.io`​ 証明書を信頼させる場合、LetsEncrypt ルートをトラストストアに追加します。 ## [](#関連情報)関連情報 - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths) - [Configure TLS with Keystores and Truststores](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration) # 非公開スペースの作成 ネットワークを Anypoint Platform に拡張するには、CloudHub 2.0 でホストされている​_非公開スペース_​、分離された仮想非公開ネットワークを作成して、アプリケーションをデプロイします。 ## [](#create-private-space)非公開スペースを作成する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 このページには、選択したビジネスグループに関連付けられたすべての非公開スペースが表示されます。 2. **\[Create private space (非公開スペースを作成)\]**​ をクリックします。 3. 非公開スペースの​[名前](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#private-space-name)​を入力して、​**\[Create (作成)\]**​ をクリックします。 非公開スペースの作成後は名前を変更することはできません。 ## [](#create-private-network)非公開ネットワークを作成する
非公開ネットワーク設定を作成した後に変更することはできません。 設定を変更するには、非公開スペースを削除して再度作成します。 非公開スペースの管理を参照してください。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 このページには、選択したビジネスグループに関連付けられたすべての非公開スペースが表示されます。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブで、​**\[Create Private Network (非公開ネットワークを作成)\]**​ をクリックします。 4. **\[Create Private Network (非公開ネットワークを作成)\]**​ ページで、次の手順を実行します。 1. アプリケーションを実行する​[リージョン](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#private-network-region)​を選択します。 2. アプリケーションで使用できる IP アドレスの範囲である ​[CIDR ブロック](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#cidr-block)​を入力します。 3. 必要に応じて、非公開スペースに接続する企業の非公開ネットワークの CIDR をカンマ区切りリストで入力して予約します。 企業の CIDR を予約すると、Anypoint Platform は企業の非公開ネットワークと競合しないようにこれらのブロックを使用せずに非公開スペースの IP を作成します。 4. **\[Create (作成)\]**​ をクリックします。 非公開ネットワークの作成には最大 30 分かかります。 ネットワークが作成されている間、​[外部ネットワークへの接続を作成](#create-connection-to-external-network)​できます。 5. ネットワークの作成が成功したら、​[アプリケーションをデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)​して非公開ネットワーク接続をテストできます。 非公開ネットワークの作成に失敗した場合は、それを削除し、​**\[Create Private Network (非公開ネットワークを作成)\]**​ をクリックして再試行します。 ### [](#resolve-private-domains)内部ネットワークの非公開ドメインの解決 企業ネットワークで内部 DNS サーバーを使用してカスタムドメインへの要求を解決する場合は、これらの IP アドレスとドメイン名を使用して非公開スペースを設定します。 非公開スペースは内部 DNS を使用して、非公開ネットワークの内部ホスト名を解決します (アプリケーションからバックエンドリソースを FQDN で呼び出すようにしてください)。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブで、​**\[Internal DNS servers (内部 DNS サーバー)\]**​ の ​**\[Configure (設定)\]**​ リンクをクリックします。 4. 内部 DNS サーバーの (カンマ区切りの) ​[サーバー IP アドレス](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#server-ip-addresses)​を入力します。 5. 内部 DNS によって解決される (カンマ区切りの) ​[ドメインアドレス](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#domains)​を入力します。 6. **\[Save (保存)\]**​ をクリックします。 内部 DNS を設定したら、​**\[Network (ネットワーク)\]**​ タブに設定済みのサーバー IP アドレスとドメインの数が表示されます。 ![「Private Network (非公開ネットワーク)」 セクションの内部 DNS 設定](/mulesoft/current/ja-jp/cloudhub-2/_images/internal-dns.png)
MuleSoft ドメインまたは公開ドメインを非公開スペースの内部 DNS として追加することはできません。
## [](#create-connection-to-external-network)外部ネットワークへの接続を作成する 非公開ネットワークを作成したら、VPN またはトランジットゲートウェイアタッチメントを使用して外部ネットワークに接続します。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブで、​**\[Create Connection (接続を作成)\]**​ をクリックします。 4. **\[Create Connection (接続を作成)\]**​ ページで、接続種別を選択し、​[VPN](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#vpn-name)​ または​[トランジットゲートウェイ](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info#transit-gateway-name)​の接続名を入力して、​**\[Next (次へ)\]**​ をクリックします。 選択した接続種別に応じて、次の操作を実行します。 - **VPN**​: [VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn)の手順に従います。 - **Transit Gateway (トランジットゲートウェイ)**​: [トランジットゲートウェイアタッチメントの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw)の手順に従います。 ## [](#関連情報)関連情報 - [必要なセットアップ情報の収集](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info) - [VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn) - [トランジットゲートウェイアタッチメントの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw) - [非公開スペースの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-configure) - [非公開スペースの管理](https://docs.mulesoft.com/jp/cloudhub-2/ps-manage) # 非公開スペースの管理 Anypoint Runtime Manager を使用して、ルートテーブルからのルートの追加や削除、または非公開スペースからのトランジットゲートウェイのデタッチなど、非公開スペースを管理します。 ## [](#add-remove-routes)ルートテーブルへのルートの追加または削除 ルートは、非公開スペースからのトラフィックを転送する方法 (公開インターネットへ、または接続 (VPN またはトランジットゲートウェイ) 経由など) を決定します。 ルートを追加して新しいサブネットにアクセスできるようにしたり、トランジットゲートウェイからサブネットにアクセスできる必要がなくなった場合はルートを削除したりできます。 新しい非公開スペースを作成する場合、MuleSoft により提供されたデフォルトルートを削除できます。ただし、デフォルトルートを変更すると、非公開スペースのダウンタイムが発生する可能性があります。ルートに ​**\[X\]**​ アイコンが表示されていない場合、そのルートは削除できません。 2023 年 3 月 9 日より前に作成された既存の非公開スペースに対して MuleSoft により定義されたルートは削除できません。MuleSoft により定義されたデフォルトルートを削除するには、新しい非公開スペースを作成して設定する必要があります。MuleSoft では、ルートテーブルで参照または削除できない他のルート (コントロールプレーントラフィックルートなど) が定義されています。Anypoint MQ、ObjectStore v2、API Manager にはネットワークからのインターネットアクセスが必要です。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Private Network (非公開ネットワーク)\]**​ セクションで、​**\[Route Table (ルートテーブル)\]**​ をクリックします。 ルートテーブルには、非公開スペースのすべてのルートが表示されます。 - サブネットを CIDR 表記で入力し、接続を選択し、​**\[Add Route (ルートを追加)\]**​ をクリックしてルートを追加する。 優先ルート (非公開ネットワークで使用されるルート) に一致するルートは追加できません。 ルートは、一度に 1 つの接続でのみ使用できます。 非ローカル/インターネットゲートウェイ (IGW) ルートを入力すると、CloudHub 2.0 によってそのルートが別の接続で使用されていることが警告されます。 ルートは既存のルートと重複することはできません。 ルートテーブル内の別のルートと重複するルートを入力すると、CloudHub 2.0 により警告されます。 - テーブル内の行の ​**\[X\]**​ アイコンをクリックしてルートを削除し、​**\[Delete (削除)\]**​ をクリックして確認する。 ルートに ​**\[X\]**​ アイコンが表示されていない場合、そのルートは削除できません。 静的 VPN 接続のルートを削除できます。 4. **\[Done (完了)\]**​ をクリックして、ルートテーブルを閉じます。 Anypoint Platform により、AWS への新しいルートが送信されます。
(AWS によって予約されている) 169.254.168.0/22 をルートの宛先として追加することはできません。
## [](#rename-connection)接続の名前を変更する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、接続メニュー (​**\[…​\]**​) をクリックし、​**\[Rename (名前を変更)\]**​ を選択します。 4. 新しい名前を入力し、​**\[Save (保存)\]**​ をクリックします。 ## [](#create-redundant-vpn)冗長 VPN を作成する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、VPN メニュー (​**\[…​\]**​) をクリックし、​**\[Create Redundant VPN (冗長 VPN を作成)\]**​ を選択します。 4. [「冗長 VPN を作成する」](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn#create-redundant-vpn)​の手順を実行します。 ## [](#rename-vpn)VPN の名前を変更する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、VPN メニュー (​**\[…​\]**​) をクリックし、​**\[Rename (名前を変更)\]**​ を選択します。 4. 新しい名前を入力し、​**\[Save (保存)\]**​ をクリックします。 ## [](#change-vpn-connection)VPN 接続設定を変更する VPN 接続を設定したら、トンネル開始の動作を変更できます。 この設定は、この接続のすべての VPN に適用され、デフォルトで有効になります。
VPN の作成後にトンネル開始を変更すると、この接続内のすべての VPN が再起動されます。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、VPN メニュー (​**\[…​\]**​) をクリックし、​**\[Connection Settings (接続設定)\]**​ を選択します。 4. **\[Connection Settings (接続設定)\]**​ ページでは次のことができます。 - VPN 接続の新しい名前を入力する。 - **\[Advanced Options (詳細オプション)\]**​ を展開して、​**\[Automatic Tunnel Initiation (自動トンネル開始)\]**​ オプションを変更する。 VPN が自動的に起動するように指定するには、このオプションを有効にします。 このオプションを選択解除した場合、カスタマーゲートウェイからのトラフィックを生成して VPN トンネルを確立する必要があります。 5. **\[Save (保存)\]**​ または ​**\[Cancel (キャンセル)\]**​ をクリックして、​**\[Connection Settings (接続設定)\]**​ ウィンドウを閉じます。 **\[Automatic Tunnel Initiation (自動トンネル開始)\]**​ オプションを変更すると、接続内のすべての VPN が再起動されます。 ## [](#view-vpn-status)VPN の状況を表示する 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、VPN メニュー (​**\[…​\]**​) をクリックし、​**\[View Details (詳細を表示)\]**​ を選択します。 4. **\[X\]**​ をクリックして、​**\[VPN Details (VPN の詳細)\]**​ ウィンドウを閉じます。 ## [](#enable-vpn-logs)VPN ログの有効化 VPN ログを有効にすると、MuleSoft サポートエンジニアが VPN ログに直接アクセスできるようになります。これにより、AWS からログを取得するプロセスが短縮されます。 1. 2023 年 3 月 8 日以降に作成された VPN 接続の場合、VPN ログは作成時にデフォルトで有効になります。 2. 既存の VPN 接続の場合: 1. 次の既存のエンドポイントへの PATCH コールを介して VPN ログを有効にすることができます。 `[https://anypoint.mulesoft.com/runtimefabric/api/organizations/{{org-id}}/privatespaces/{{ps-id}}/connections/{{connection-id}}/vpns/{{vpn-id}}](https://anypoint.mulesoft.com/runtimefabric/api/organizations/{{org-id}}/privatespaces/{{ps-id}}/connections/{{connection-id}}/vpns/{{vpn-id}})`​. 2 つのトンネルがあり、その他の変更がない、VPN のログを有効化するためのペイロードは、​`{"vpnTunnels":[{"isLogsEnabled": true}, {"isLogsEnabled": true}]}`​ です。 `isLogsEnabled`​ フラグは ​`true`​ にのみ設定できます。それ以外の場合、API は 400 エラーを返します。 2. 2023 年 3 月 8 日以降に既存の VPN を更新すると、MuleSoft サポートエンジニアは VPN ログに直接アクセスできるようになります。
この機能を有効にすると、AWS サポートチケットを申請しなくても MuleSoft サポートチームが VPN ログを直接ダウンロードできるようになるため、AWS から VPN ログを取得するプロセスの時間が短縮されます。
## [](#delete-vpn)VPN を削除する 接続の最後の VPN を削除すると、接続全体が削除されます。
このアクションは元に戻すことができません。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、VPN メニュー (​**\[…​\]**​) をクリックし、​**\[Delete (削除)\]**​ を選択します。 4. **\[Delete (削除)\]**​ をクリックして削除を確認するか、​**\[Cancel (キャンセル)\]**​ をクリックします。 ## [](#rename-tgw)トランジットゲートウェイアタッチメントの名前を変更する AWS のアタッチメント名に合うようにトランジットゲートウェイアタッチメントの名前を変更する必要がある場合もあります。 トランジットゲートウェイアタッチメントの名前を変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、トランジットゲートウェイメニュー (​**\[…​\]**​) をクリックし、​**\[Rename (名前を変更)\]**​ を選択します。 4. 新しい名前を入力し、​**\[Save (保存)\]**​ をクリックします。 ## [](#detach-tgw)非公開スペースからトランジットゲートウェイをデタッチする 次の理由で、トランジットゲートウェイアタッチメントのデタッチが必要な場合があります。 - AWS でアタッチメントを拒否した場合、Anypoint Platform でトランジットゲートウェイアタッチメントが ​`[Rejected (拒否済み)]`​ と表示されます。 この場合、もう一度アタッチを試みる前にアタッチメントを削除する必要があります。 - AWS でアタッチメントが削除された場合、そのアタッチメントを Anypoint Platform から削除できます。 トランジットゲートウェイアタッチメントを削除すると、関連付けられたルートも削除されます。 AWS のリソース共有は影響を受けないため、新しいトランジットゲートウェイを作成することなく再追加できます。ただし、非公開スペースからトランジットゲートウェイをデタッチすると、AWS のアタッチメントも削除されます。 トランジットゲートウェイをデタッチのみして組織から削除しない場合、そのトランジットゲートウェイは ​**\[Add a transit gateway (トランジットゲートウェイを追加)\]**​ の下に表示されます。 非公開スペースにデプロイされたアプリケーションは引き続き動作しますが、Amazon VPC および VPN には接続されなくなります。 トランジットゲートウェイをデタッチする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブの ​**\[Connections (接続)\]**​ セクションで、トランジットゲートウェイメニュー (​**\[…​\]**​) をクリックし、​**\[Detach (デタッチ)\]**​ を選択します。 4. 確認プロンプトで ​**\[Detach (デタッチ)\]**​ をクリックします。 トランジットゲートウェイのデタッチには数分かかることもあります。 ## [](#delete-tgw)トランジットゲートウェイを削除する Anypoint Platform 組織からトランジットゲートウェイを完全に削除するには、 [トランジットゲートウェイの削除 API コール](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-20-api/minor/1.0/console/method/%234136/) ​(​`DELETE <>/organizations/:orgId/transitgateways/:tgw-id`​) を使用して AWS のリソース共有を削除します。 詳細は、AWS ドキュメントの [「AWS RAM 内のリソース共有の削除」](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-delete.html)​を参照してください。 ## [](#delete-private-network)非公開ネットワークを削除する アプリケーションがデプロイされている場合、または接続が存在する場合は、非公開ネットワークは削除できません。
このアクションは元に戻すことができません。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Network (ネットワーク)\]**​ タブで、非公開ネットワークメニュー (​**\[…​\]**​) をクリックして ​**\[Delete (削除)\]**​ を選択します。 4. **\[Delete (削除)\]**​ をクリックして削除を確認します。 ## [](#delete-private-space)非公開スペースを削除する 関連する非公開ネットワーク、VPN、またはトランジットゲートウェイアタッチメントがある場合、非公開スペースは削除できません。
このアクションは元に戻すことができません。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. 非公開スペースメニュー (​**\[…​\]**​) をクリックして ​**\[Delete (削除)\]**​ を選択します。 ![非公開スペースメニューの \[Delete (削除)\] オプション](_images/ps-delete.png) 4. **\[Delete private space (非公開スペースを削除)\]**​ をクリックして削除を確認するか、​**\[Cancel (キャンセル)\]**​ をクリックします。 ## [](#関連情報)関連情報 - AWS ドキュメントの [「AWS RAM 内のリソース共有の削除」](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-delete.html) # 非公開スペースの設定 非公開スペース、非公開ネットワーク、および外部ネットワークへの接続を作成したら、次の操作で非公開スペースを設定できます。 - [SSL エンドポイントと証明書の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-ssl-endpoints) - [非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains) - [非公開スペースとの間のトラフィックを管理するためのファイアウォールルールの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules) - [ビジネスグループと環境の非公開スペースへの関連付け](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-env) - [高度な非公開スペース設定の定義](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-advanced) ## [](#関連情報)関連情報 - [必要なセットアップ情報の収集](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info) - [非公開スペースの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure) - [VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn) - [トランジットゲートウェイアタッチメントの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw) - [非公開スペースの管理](https://docs.mulesoft.com/jp/cloudhub-2/ps-manage) # 非公開スペースへのアプリケーションのデプロイ Runtime Manager を使用して、アプリケーションを非公開スペースにデプロイします。
CloudHub 2.0 では、Mule Runtime Engine バージョン 4.3.x 以降がサポートされます。 Mule 3.x はサポートされていません。
Exchange で以前にアセットが​論理削除​されている場合、Runtime Manager でアプリケーションを CloudHub 2.0 または Runtime Fabric にデプロイできません。
## [](#deploy-app-private-space)非公開スペースにアプリケーションをデプロイする 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. **\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 3. **\[Deploy Application (アプリケーションをデプロイ)\]**​ ページで、次の手順を実行します。 1. アプリケーションの​[名前](#app-name-reqs)​を入力します。
アプリケーションのデプロイ後は名前を変更することはできません。名前を変更するには、削除してから新しい名前でアプリケーションを再デプロイしてください。
2. アプリケーションファイルを選択します。 - システムから Mule アプリケーション JAR ファイルをアップロードするには、​**\[Choose file (ファイルを選択)\] > \[Upload file (ファイルをアップロード)\]**​ を選択します。 ファイル名には、 [一意のパッケージ名](https://docs.oracle.com/javase/specs/jls/se6/html/packages.html#7.7)​に関するガイドラインに従って、文字、数字、アンダースコアのみを含めることができます。 - Anypoint Exchange からサンプルアプリケーションを選択する手順は、次のとおりです。 1. **\[Choose file (ファイルを選択)\] > \[Import file from Exchange (Exchange からファイルをインポート)\]**​ を選択します。 2. **\[Get from Exchange (Exchange から取得)\]**​ ページで、​**\[Search assets by name (アセットを名前で検索)\]**​ に​`「hello」`​と入力します。 ![「Get from Exchange (Exchange から取得)」 ページ](/mulesoft/current/ja-jp/cloudhub-2/_images/rtm-get-from-exchange.png) 3. **\[Hello World\]**​ をクリックし、​**\[Select (選択)\]**​ をクリックします。 3. **\[Deployment Target (デプロイメント対象)\]**​ リストから、非公開または共有スペースの名前を選択します。 4. デプロイメントのオプションを設定します。 - [ランタイムオプションを指定する](#specify-runtime-options)​。 - [アプリケーションのエンドポイントとパスを設定する](#configure-endpoint-path)​。 - [プロパティを使用してアプリケーションの動作を変更する](#app-properties)​。 - [アプリケーションのログを設定する](#configure-logging)​。 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ### [](#specify-runtime-options)ランタイムオプションを指定する **\[Runtime (ランタイム)\]**​ タブをクリックし、次のオプションを指定します。 ランタイムバージョン Mule Runtime Engine バージョンを指定します。バージョン 4.3.x、4.4.x、4.5.x、4.6.x がサポートされています。 Release Channel (リリースチャネル) Mule 4.5 以降、MuleSoft は ​[Edge と長期サポート (LTS)](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)​ という 2 つの新しいリリースチャネルを導入します。 新しいアプリケーションでは、​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンメニューで Edge チャネルがデフォルトで選択されます。 従来のバージョンを使用している既存のアプリケーションでは、​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストで ​`[None (なし)]`​ がデフォルトで選択されます。​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストを使用して、目的のリリースチャネルを選択します。 Edge バージョンを使用している既存のアプリケーションでは、​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストで ​`[Edge]`​ がデフォルトで選択されます。​**\[Runtime Version (Runtime バージョン)\]**​ ドロップダウンリストでは、更新が利用できるかどうか、およびアプリケーションの以前のバージョンと最新バージョンが示されます。​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストを使用して、従来バージョンに変更します。 拡張サポートで Edge または LTS バージョンを使用している既存のアプリケーションでは、バージョンの EOL を示す警告メッセージが表示されます。 Unresolved include directive in modules/ROOT/pages/\_partials/deployment.adoc - include::cloudhub::partial$mule-runtime-eos-note.adoc\[\] Java バージョン アプリケーションの Java バージョンを選択します。詳細は、[Java サポート](https://docs.mulesoft.com/jp/general/java-support)を参照してください。 Replica size (レプリカサイズ) アプリケーションを実行するレプリカ内の vCore の数を指定します。 レプリカのサイズ、メモリ、ストレージについては、​[「CloudHub 2.0 レプリカ」](https://docs.mulesoft.com/jp/cloudhub-2/ch2-architecture#cloudhub-2-replicas)​を参照してください。 CloudHub 2.0 では、デプロイメントあたりのレプリカサイズは 4 つの vCore に制限されています。 Replica Count (レプリカ数) デプロイするアプリケーションのレプリカまたはインスタンスの数を指定します。 高可用性には、少なくとも 2 つのレプリカが必要です。 Run in Runtime Cluster Mode (ランタイムクラスターモードで実行) アプリケーションの各レプリカで ​[Mule のクラスタリング](https://docs.mulesoft.com/jp/cloudhub-2/ch2-clustering)​を有効にします。 このオプションには、少なくとも 2 つのレプリカが必要です。 Use Object Store V2 (Object Store V2 を使用) **\[Use Object Store V2 (Object Store V2 を使用)\]**​ チェックボックスをオンにすることで、Mule 3 と Mule 4 の実装として ​[Object Store v2](https://docs.mulesoft.com/jp/object-store/)​ を選択できます。 Deployment model (デプロイメントモデル) - **Rolling update (ローリング更新)**​: - レプリカを増分的に更新することで、可用性を維持します。 - **Recreate (再作成)**​: - 再デプロイメントの前にレプリカを終了します。 - 再デプロイメントはより高速で、追加リソースは必要ありません。 ## [](#configure-endpoint-path)アプリケーションのエンドポイントとパスを設定する 詳細は、[非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths)を参照してください。 アプリケーションのエンドポイントを設定して、インターネットからのアクセスを有効にする手順は、次のとおりです。 1. **\[ingress (イングレス)\]**​ タブをクリックし、次のオプションを指定します。 エンドポイント - **Host (ホスト)**​: ドロップダウンリストから、アプリケーションのドメイン (​`cloudhub.io`​ など) を選択します。
cloudhub.io​ (デフォルトのドメイン) を選択した場合、サブドメインまたはパスは選択できません。
システム管理者が非公開スペースのドメインと証明書 (TLS コンテキスト) を設定します。 詳細は、[非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains)を参照してください。 非公開スペースのドメインを選択したら、​**\[View TLS Context (TLS コンテキストを表示)\]**​ をクリックして、対応する TLS コンテキストを表示できます。 - **\[Subdomain (サブドメイン)\]**​: 選択したドメインにワイルドカードが含まれる場合、サブドメインを設定できます。 サブドメインの先頭と末尾は英数字にする必要があり、英数字 (a-z、A-Z、0-9)、ハイフン (-)、アンダースコア (-)、ピリオド (.) のみを含めることができます。 サブドメインでは​[プレースホルダー](#placeholder-table)​がサポートされています。 デフォルトのサブドメインは ​`app-name`​ で、アプリケーションをデプロイするときに ​**\[Application Name (アプリケーション名)\]**​ 項目で指定したアプリケーションの名前に解決されます。 - **\[Path (パス)\]**​: アプリケーションエンドポイントへの URL パスを指定します。 パスの先頭と末尾は英数字にする必要があり、英数字、ハイフン、およびアンダースコアのみを含めることができます。 パスでは​[プレースホルダー](#placeholder-table)​がサポートされています。 - エンドポイントを追加するには、​**\[Add Endpoint (エンドポイントを追加)\]**​ をクリックしてオプションを指定します。 - エンドポイントを削除するには、エンドポイントの行の ​**\[X\]**​ をクリックします。
デプロイするコントロールプレーンによって、エンドポイント URL 形式で ​cloudhub.io​ の前にリージョンサフィックスが必要な場合と、そうでない場合があります。US コントロールプレーンにアプリケーションをデプロイする場合、リージョンサフィックスは追加しません (例: https://.10u6w7.usa-e1.cloudhub.io​)。ほかのコントロールプレーンにアプリケーションをデプロイする場合、対応するリージョンサフィックスを追加します (例: https://.10u6w7.usa-e1.eu1.cloudhub.io​)。
パス書き換え アプリケーションの HTTP リスナーが ​**\[Endpoints (エンドポイント)\]**​ で定義されたパスとは異なるパスでリスンする場合: 1. **\[Rewrite Request Paths (要求パスを書き換え)\]**​ オプションを有効にします。 2. アプリケーションで必要とされる対象パスを入力します。 アプリケーションに送信される要求は、ここで指定したパスを使用します。 以下の例をチェックして、非公開スペースがパスを書き換える方法を確認します。 **アプリケーションエンドポイント 1:** ```console https://sapi-one-o4azsf.2x9yyp.usa-e2.cloudhub.io/acct ``` **パス書き換え 1:** ```console /version1 ``` **アプリケーションエンドポイント 2:** ```console https://sapi-one-o4azsf.2x9yyp.usa-e2.cloudhub.io/acct/moreInfo ``` **パス書き換え 2:** ```console /version1/moreInfo ``` TLS オプション - **Forward SSL session (SSL セッションを転送)** セッション中に SSL 転送を有効にします。 SSL は、主にクライアント認証で使用されます。 詳細は、[クライアント認証の有効化](https://docs.mulesoft.com/jp/anypoint-security/enable-client-authentication)を参照してください。 SSL 転送は、HTTP リクエストヘッダーでクライアント証明書の詳細を転送して、アプリケーションで使用できるようにします。 これらの項目は、認証済みクライアントを識別し、アプリケーションが ID を判別して使用できるようにします。 次のヘッダーを使用できます。
ヘッダー名 値

x-ssl-client-verify

SUCCESS/FAIL

x-ssl-issuer

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

x-ssl-client-serial

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

x-ssl-client-dn

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

x-ssl-client-cert

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

- **Last-Mile Security (Last -Mile セキュリティ)** 転送された HTTPS 接続の TLS の終了と復号化がアプリケーションで行われることを指定します。 このオプションでは Mule アプリケーションに SSL 証明書が含まれている必要があり、より多くの CPU リソースも必要です。 2. アプリケーションの新しい設定を作成するには、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ### [](#app-name-reqs)アプリケーション名 アプリケーション名では、3 ~ 42 文字の英数字 (a-z、A-Z、0-9) とハイフン (-) を使用できます。 スペースやその他の文字を含めることはできません。 アプリケーション名の先頭は文字 (a-z または A-Z) にする必要があります。先頭を数値やハイフンにしたり、末尾をハイフンにしたりすることはできません。 名前が一意になるようにし、ドメインの競合を回避するために、CloudHub 2.0 では公開エンドポイント URL で指定したアプリケーション名に 6 文字の ​`_unique-id_`​ が追加されます。 アプリケーション名は、Runtime Manager だけでなく、公開 ​`cloudhub.io`​ ドメインでもアプリケーションを識別するものです。 たとえば、​`myapp`​ という名前のアプリケーションには ​`http://myapp-​_unique-id_​._shard_.usa-w2.cloudhub.io`​ でアクセスできます。各デプロイメント対象に固有のアプリケーション名が必要です。 アプリケーション名をさらにカスタマイズするために、命名規則を作成できます。 たとえば、​`mycompany-mydept-myapp`​ のように会社名と部署をすべてのアプリケーション名の前に付けることもできます。 そして、DNS レコードを追加して、複雑なアプリケーション名を非表示にすることができます。 たとえば、​`myapp.mycompany.com`​ に対する要求を ​`mycompany-mydept-myapp-​_unique-id_​._shard_._region_​.cloudhub.io`​ にルーティングすることもできます。 アプリケーションファイル名は、できる限り一意にします。Exchange のアセットと同じ名前を共有しているアプリケーションはデプロイできません。 ### [](#placeholder-table)プレースホルダー サブドメインとパスでは、次の小文字プレースホルダー (省略可能) がサポートされます。
プレースホルダー 解決対象

app-name

アプリケーションをデプロイするときに ​[Application Name (アプリケーション名)]​ 項目で指定したアプリケーションの名前

business-group-id

アプリケーションに関連付けられビジネスグループ ID

environment-id

アプリケーションをデプロイする環境

## [](#app-properties)プロパティを使用したアプリケーションの動作の変更 アプリケーションのデプロイメント時に、環境の指定やパスワードとユーザー名の設定などのプロパティ値を設定できます。 アプリケーションのプロパティの設定については、次のリンク先を参照してください。 - [プロパティを使用したアプリケーションの動作の変更](https://docs.mulesoft.com/jp/cloudhub-2/ch2-manage-props) - [アプリケーションプロパティ値の保護](https://docs.mulesoft.com/jp/cloudhub-2/ch2-protect-app-props) ## [](#configure-logging)アプリケーションのログの設定 CloudHub 2.0 にデプロイされたアプリケーションの場合、デフォルトでログが有効になっています。 ### [](#ログを無効化または有効化する)ログを無効化または有効化する アプリケーションのログを無効化または再有効化する手順は、次のとおりです。 1. **\[Logging (ログ)\]**​ タブをクリックします。 2. **\[Forward application logs to Anypoint Platform (Anypoint Platform にアプリケーションログを転送)\]**​ オプションを選択解除または選択します。 3. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ログを無効にしても、Runtime Manager ナビゲーションメニュー ​**\[Logs (ログ)\]**​ ヘッダーが引き続き表示されますが、アプリケーションログは収集されません。 ### [](#ログレベルおよびカテゴリを設定する)ログレベルおよびカテゴリを設定する ログに含める追加のログレベルとカテゴリを設定する手順は、次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. ログレベルを選択します。 - **INFO (情報)**​: 有益情報のメッセージ - **DEBUG (デバッグ)**​: デバッグメッセージ - **WARNING (重要)**​: 警告メッセージ - **ERROR (エラー)**​: 例外が発生した場合などのエラーメッセージ - **FATAL (致命的)**​: アプリケーションが失敗した場合の致命的なメッセージ 3. 必要に応じて、ログレベルを選択し、​`package.name`​ を入力して Enter キーを押すことで、特定の Java パッケージクラスのログレベルを設定します。 4. **\[Apply Changes (変更を適用)\]**​ をクリックします。
ログレベルを変更して ​[Apply Changes (変更を適用)]​ をクリックすると、アプリケーションが再起動します。
## [](#トレースデータ収集の有効化)トレースデータ収集の有効化
この機能は、組織に 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 以降で実行されている CloudHub 2.0 アプリケーションで有効にすることができます。 トレースデータ収集は、Mule Maven プラグイン、Anypoint CLI、または Anypoint Studio を使用して有効にすることはできません。トレースデータ収集を有効にするには、UI や API を使用する必要があります。 アプリケーションのトレースデータ収集を有効にする手順は次のとおりです。 1. **\[Monitoring (監視)\]**​ タブをクリックします。 2. **\[Enable tracing (トレースを有効化する)\]**​ チェックボックスをオンにします。 3. 新しいデプロイメントでこの機能を有効にする場合には、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。既存のアプリケーションを編集している場合は ​**\[Apply Changes (変更を適用)\]**​ をクリックします。 トレースを有効にしてアプリケーションを再デプロイすると、Runtime Manager バックエンドによってアプリケーションのトレース計測が開始されます。 ## [](#関連情報)関連情報 - [Exchange からのテストアプリケーションのダウンロード](https://docs.mulesoft.com/jp/cloudhub-2/ch2-download-test-app) - Exchange の [MuleSoft によって提供されるサンプルアセット](https://anypoint.mulesoft.com/exchange/?view=grid&type=example&search=&organizationId=68ef9520-24e9-4cf2-b2f5-620025690913) - [非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定](https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths) - [非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains) - [Log4j を使用したログシステムとのインテグレーション](https://docs.mulesoft.com/jp/cloudhub-2/ch2-integrate-log-system) # 非公開スペースを使用した Anypoint Platform へのネットワークの拡張 ## [](#始める前に)始める前に - [権限を割り当てる](https://docs.mulesoft.com/jp/cloudhub-2/ps-assign-permissions)​。 - [必要なセットアップ情報を収集する](https://docs.mulesoft.com/jp/cloudhub-2/ps-gather-setup-info)​。 ## [](#ワークフロー)ワークフロー 1. [非公開スペースを作成する](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure)​。 2. [非公開ネットワークを作成する](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#create-private-network)​。 1. [アプリケーションをデプロイして非公開ネットワークをテストする](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)​。 2. [必要に応じて内部 DNS サーバーを設定する](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#resolve-private-domains)​。 3. [外部ネットワークへの接続を作成する](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure#create-connection-to-external-network)​。 - [VPN 接続を作成する](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-vpn)​。 - [トランジットゲートウェイに接続する](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure-tgw)​。 4. [非公開スペースをカスタマイズする](https://docs.mulesoft.com/jp/cloudhub-2/ps-configure)​。 1. [非公開スペースのドメインおよび証明書 (TLS コンテキスト) を設定する](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains)​。 2. [非公開スペースへのトラフィックを管理するためのファイアウォールルールを設定する](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-fw-rules)​。 3. [環境とビジネスグループを非公開スペースに関連付ける](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-env)​。 4. [詳細設定を定義する](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-advanced)​ (HTTP 要求処理やイングレスロードバランサーログレベルなど)。 ## [](#関連情報)関連情報 - [非公開スペースの作成](https://docs.mulesoft.com/jp/cloudhub-2/ps-create-configure) - [非公開スペースの設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-configure) # 高度な非公開スペース設定の定義 **\[Advanced (詳細)\]**​ タブのオプションを使用して、次の操作を実行します。 - イングレスロードバランサーが HTTP 要求を処理する方法を設定する。 - 読み取り応答タイムアウトを指定する。 この値は、CloudHub 2.0 が Mule アプリケーションからの応答を待機する時間です。 指定された時間内にデータが送受信されない場合、CloudHub 2.0 は 504 エラーで要求を削除します。 - イングレスロードバランサーのログレベルを設定し、ログをダウンロードする。 - Amazon Web Services (AWS) サービスロールを設定する。 ## [](#http-要求と読み取り応答タイムアウトを設定する)HTTP 要求と読み取り応答タイムアウトを設定する HTTP 要求を変更すると、最大 5 秒間アプリケーションに到達できない可能性があります。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Advanced (詳細)\]**​ タブをクリックします。 4. 非公開スペースでインバウンドトラフィックを受け入れる方法を設定します。 CloudHub 2.0 では、安全でない HTTP 要求のみを受け入れることはできません。 **\[HTTP Requests (HTTP 要求)\]**​ リストから、次のいずれかを選択します。 - **Redirect to HTTPS (HTTPS にリダイレクト)** HTTPS プロトコルを使用して同じ URL に HTTP 要求をリダイレクトします。 - **Accept HTTP (HTTP を受け入れる)** デフォルトの SSL エンドポイントで HTTP プロトコルを使用してインバウンド要求を受け入れます。 - **Drop HTTP (HTTP を削除)** HTTP 要求を警告なしで削除します。 5. 読み取り応答タイムアウト値を指定します。 デフォルトタイムアウトは 300 秒です。 6. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックします。
最大要求サイズは 1 GB です。
## [](#configure-ingress-load-balancer-log-levels)デフォルトのイングレスロードバランサーログレベルを設定する CloudHub 2.0 では、非公開スペースにデプロイされたすべてのアプリケーションのログファイルに書き込まれるメッセージのデフォルトの重要度レベルを指定できます。
さらに詳細なログレベルは、パフォーマンスに影響を与える可能性があります。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Advanced (詳細)\]**​ タブをクリックします。 4. ドロップダウンリストからデフォルトの​[ログレベル](#ingress-load-balancer-log-levels)​を選択します。 5. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard Changes (変更を破棄)\]**​ をクリックします。 ## [](#configure-custom-ingress-load-balancer-log-levels)カスタムイングレスロードバランサーログレベルを設定する CloudHub 2.0 では、トラブルシューティングなどのために、特定の IP アドレスのログファイルに書き込まれるメッセージのデフォルトの重要度レベルを指定できます。
さらに詳細なログレベルは、パフォーマンスに影響を与える可能性があります。
1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Advanced (詳細)\]**​ タブをクリックします。 4. カスタムログレベルを設定します。 1. IP アドレスを入力し、ドロップダウンリストからその​[ログレベル](#ingress-load-balancer-log-levels)​を選択します。 2. **\[Add IP Address (IP アドレスの追加)\]**​ をクリックして、追加のカスタムログレベルを入力します。 3. カスタムログレベルを削除するには、エントリのゴミ箱アイコン (​**\[Delete (削除)\]**​) をクリックします。 5. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard changes (変更を破棄)\]**​ をクリックします。 ## [](#ingress-load-balancer-log-levels)イングレスロードバランサーログレベル IP アドレス絞り込みのデフォルトのログレベルは ​`[DEBUG (デバッグ)]`​ です。
Table 1. イングレスロードバランサーログレベル
レベル 説明

Error (エラー) (推奨)

例外が発生した場合などのエラーメッセージのみ

Debug (デバッグ)

デバッグメッセージ

Trace (トレース)

イングレスと API 間のパス、ヘッダー、状態、タイムラインなどのアプリケーションメタデータを追跡して、コラボレーションを促進

Info (情報)

有益情報のメッセージ

### [](#download-ingress-load-balancer-logs)イングレスロードバランサーログをダウンロードする イングレスロードバランサーログをダウンロードする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Advanced (詳細)\]**​ タブをクリックします。 4. **\[Download Logs (ログをダウンロード)\]**​ をクリックします。 ## [](#configure-aws-role)AWS サービスロールを設定する AWS で Identity and Access Management (IAM) ロールが設定されている場合、そのロールを非公開スペースに関連付けることができます。非公開スペースは、AWS の IAM ロールから権限を受け取り、AWS リソースにアクセスできます。AWS でこの機能を設定するには、以下を行います。 - Anypoint Platform で生成される一意の AWS IAM ロール名を使用します。 - 非公開スペースが設定された組織の組織 ID を使用します。 - この機能を使用するには、ポート 443 でアウトバウンドトラフィックを許可します。 詳細は、 [「IAM ロール」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)​を参照してください。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Private Spaces (非公開スペース)\]**​ を選択します。 2. 管理する非公開スペースの名前を選択します。 3. **\[Advanced (詳細)\]**​ タブをクリックします。 4. **\[Enable AWS Service Role (AWS サービスロールを有効化)\]**​ をクリックします。 5. **\[Save Changes (変更を保存)\]**​ または ​**\[Discard changes (変更を破棄)\]**​ をクリックします。 一意のサービスロール名が生成され、このロールを使用して AWS の Identity and Access Management を設定できます。ロールの生成には数分かかることがあります。ロール名が表示されない場合は、ページを更新してください。
非公開スペースごとに設定できる AWS サービスロールは 1 つのみです。
## [](#関連情報)関連情報 - AWS ドキュメントの [「IAM ロール」](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)