# mulesoft Cloudhub - Full Documentation # Anypoint Platform CLI での VPC の作成 このセクションでは、Anypoint Platform CLI を使用して Anypoint Virtual Private Cloud (Anypoint VPC) を作成および設定する方法について説明します。 組織にログインし、​`vpc create`​ コマンドを使用して Anypoint VPC を作成します。 cloudhub vpc create **(1)** vpc-tutorial **(2)** us-east-1 **(3)** 10.111.0.0/24 **(4)** --default 例について説明します。 - Anypoint VPC の名前は ​`vpc-tutorial`​ です。 - Anypoint VPC は ​`us-east-1`​ リージョンにバインドされます。

すべての Anypoint VPC を CloudHub リージョンに関連付ける必要があります。

- Anypoint VPC のサイズは ​`10.111.0.0/24`​ です。CIDR 通知では、これにより 10.111.0.0 ~ 10.111.0.255 の 256 個の IP アドレスが付与されます。 - 作成された Anypoint VPC をサイズ変更することはできません。 - この時点では、Anypoint VPC のサイズの設定方法を理解することが重要です。この設定方法がわからない場合は、​[VPC のサイズ設定](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud#size-your-vpc)​ガイドに従うようにしてください。 - Anypoint VPC 用の CIDR ブロックは、非公開 IP 空間から選択することをお勧めします。これを Anypoint VPC の他の CIDR ブロックや、社内ネットワーク内で使用されている CIDR ブロックと重複しないようにする必要があります。 - Anypoint VPC はデフォルトとして設定されます。つまり、Anypoint VPC に関連付けられていない、このリージョン内のすべての環境は、デフォルトでこの Anypoint VPC に関連付けられます。

この例では、以下の情報を渡しません。

  • 環境情報:
    特定の環境を設定しないことで、US-EAST (米国東部) にデプロイされたすべてのアプリケーションは、デプロイ先の環境を無視してこの Anypoint VPC に関連付けられます。

  • ビジネスグループ情報:
    これにより、この Anypoint VPC がメイン組織に関連付けられます。

操作が成功すると、Anypoint Platform CLI は、新しく作成された Anypoint VPC の詳細を表示します。 ```text ┌──────────────────────────────┬───────────────────┐ │ Name │ vpc-tutorial │ ├──────────────────────────────┼───────────────────┤ │ Region │ us-east-1 │ ├──────────────────────────────┼───────────────────┤ │ CIDR Block │ 10.111.0.0/24 │ ├──────────────────────────────┼───────────────────┤ │ Inherited │ No │ ├──────────────────────────────┼───────────────────┤ │ Organization default │ Yes │ ├──────────────────────────────┼───────────────────┤ │ Special domains │ │ ├──────────────────────────────┼───────────────────┤ │ DNS Servers │ │ ├──────────────────────────────┼───────────────────┤ │ Firewall rules │ │ ├──────────────────────────────┼───────────────────┤ │ Environments │ │ ├──────────────────────────────┼───────────────────┤ │ Business groups │ │ ├──────────────────────────────┼───────────────────┤ │ Load balancers │ │ └──────────────────────────────┴───────────────────┘ ``` ## [](#ファイアウォールルールの作成)ファイアウォールルールの作成 Anypoint VPC が作成されると、デフォルトで 4 つのファイアウォールルールが設定されます。​[vpc firewall-rules describe](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-describe)​ コマンドを使用して、これらを確認できます。 cloudhub vpc firewall-rules describe vpc-tutorial このコマンドは以下の情報を返します。 ```text ┌───────┬────────────────────┬──────────┬────────────┬──────────┐ │ Index │ CIDR Block │ Protocol │ From port │ To port │ ├───────┼────────────────────┼──────────┼────────────┼──────────┤ │ 0 │ 10.111.0.0/24 │ TCP │ 8091 │ 8092 │ ├───────┼────────────────────┼──────────┼────────────┼──────────┤ │ 1 │ 0.0.0.0/0 │ TCP │ 8081 │ 8082 │ └───────┴────────────────────┴──────────┴────────────┴──────────┘ ```

ルール ​0​ では、ポート 8091 および 8092 でのローカル Anypoint VPC からのインバウンド接続が許可されます。ルール ​1​ では、任意のホストからのトラフィックがポート 8081 および 8082 を介してワーカーにアクセスすることが許可されます。

[`vpc firewall-rules remove`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-remove)​ コマンドを使用して任意のデフォルトルールを削除できます。また、​[`vpc firewall-rules add`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-add)​ コマンドを使用して新しいルールを追加できます。 Anypoint VPC 内でポート 8090 を介した TCP トラフィックを有効にする必要があるとします。次の手順を実行する必要があります。 cloudhub vpc firewall-rules add **(1)** vpc-tutorial **(2)** 10.111.0.0/24 **(3)** tcp **(4)** 8090 1. `vpc-tutorial`​ をこの新しいファイアウォールルールの対象 Anypoint VPC として設定します。 2. `10.111.0.0/24`​ を設定して、Anypoint VPC 内からのホストのみを許可するように IP 範囲を設定します。 CIDR 通知では、​`10.111.0.0`​ ~ ​`10.111.0.255`​ の範囲が許可されます。 3. 許可リストに登録されたプロトコルを ​`tcp`​ に設定します。 4. ポート番号 ​`8090`​ を許可します。 新しいファイアウォールルールを作成すると、Anypoint Platform CLI は次の成功メッセージを表示します。 VPC firewall modified successfully ## [](#既存の-anypoint-vpc-の更新)既存の Anypoint VPC の更新 Anypoint Platform CLI を使用して Anypoint VPC の特定の値を更新することはできませんが、 [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)​ を使用して Anypoint VPC をプログラムで管理および更新することはできます。 1. `https://anypoint.mulesoft.com/accounts/login`​ エンドポイントを介して、ログイン情報を渡して CloudHub サービスにログインします。 2. `organizations/{orgid}/vpcs/{vpcId}`​ エンドポイントを使用して、Anypoint VPC を更新します。
API のリソースとやり取りする方法についての詳細は、 「CloudHub API」​を参照してください。
たとえば、Anypoint VPC の環境を更新するには、​`PUT`​ 要求を JSON ペイロードと共に ​`anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs/{vpcId}`​ エンドポイントに送信する必要があります。

Account ​account business-group describe​ コマンドを使用して、​{orgid}​ を照会できます。

cloudhub vpc describe-json​ コマンドを実行すると、​{vpcId}​ 値のリストが表示されます。

```json { "associatedEnvironments": [ "" ] } ```

<EnvironmentId>​ は、この Anypoint VPC を関連付ける環境の ID で置き換える必要があります。
account environment list​ コマンドを実行して、環境の ID を取得できます。

## [](#関連情報)関連情報 - [CloudHub ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/dedicated-load-balancer-tutorial) - [Anypoint Platform CLI](https://docs.mulesoft.com/jp/anypoint-cli/latest/) # Anypoint Platform CLI でのロードバランサーの作成 Anypoint Platform CLI を使用して専用ロードバランサー (DLB) を作成できます。 ## [](#前提条件)前提条件 ロードバランサーを作成する前に以下を行ってください。 - 自分が DLB を作成する組織のシステム管理者であることを確認する。 - DLB を作成する組織で Anypoint Virtual Private Cloud (Anypoint VPC) インスタンスを作成する。 - 少なくとも 1 つの証明書と証明書用の非公開鍵を作成する。 ## [](#cli-を使用したロードバランサーの作成)CLI を使用したロードバランサーの作成 CLI から DLB を作成するには、次のコマンドを使用します。 ```linenums cloudhub load-balancer create myVPC myLB_name certificateName privateKey ``` このコマンドでは、DLB を作成する Anypoint VPC インスタンス ​_myVPC_​ と、DLB が使用する ​_certificateName_​ および ​_privateKey_​ を指定します。
DLB の作成後は名前を変更することはできません。名前を変更するには、削除してから新しい名前で作成し直してください。
CloudHub DLB 名の先頭を ​`internal-`​ にすることはできません。 ## [](#cli-を使用した-dlb-での-tls-1-0-の有効化)CLI を使用した DLB での TLS 1.0 の有効化 セキュリティの脆弱性のため TLS 1.0 は推奨されませんが、従来のクライアントとの通信に必要な場合はサポートを有効にできます。 TLS 1.0 のサポートは、DLB のデフォルトの SSL エンドポイントでのみ有効にできます。 TLS 1.0 のサポートの有効化は単一の SSL エンドポイントではなく DLB 全体に適用されます。
セキュリティ上の理由により、TLS 1.0 は有効にしたままにしないでください。 TLS 1.0 が不要になった場合は、デフォルトの暗号化スイートを、たとえば ​NewDefault​ などに置き換えてください。
CLI を使用して DLB で TLS 1.0 のサポートを有効にする手順は、次のとおりです。 1. 次のコマンドを実行して ​_myLB\_name_​ ロードバランサーの SSL エンドポイントを再作成し、TLS 1.0 のサポートを追加します。 ```linenums cloudhub load-balancer ssl-endpoint add --tlsv1 myLB_name certificateName privateKey ``` 2. 次のコマンドを実行して、​_certificateName_​ を ​_myLB\_name_​ ロードバランサーのデフォルトの SSL エンドポイントとして設定します。 ```linenums cloudhub load-balancer ssl-endpoint set-default myLB_name certificateName ``` 3. API を使用して、デフォルトの暗号化スイートを ​`OldDefault`​ に変更します。 [「TLS 1.0 をサポートするようにデフォルトの暗号化スイートを変更する」](https://docs.mulesoft.com/jp/cloudhub/lb-cert-validation#change-the-default-cipher-suite-to-support-tls-1-0)​を参照してください。 ## [](#関連情報)関連情報 - [cloudhub load-balancer create](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-create) - [cloudhub load-balancer ssl-endpoint add](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-ssl-endpoint-add) - [cloudhub load-balancer ssl-endpoint set-default](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-ssl-endpoint-set-default) - [専用ロードバランサーへの証明書の追加](https://docs.mulesoft.com/jp/cloudhub/lb-cert-upload) - [アクセス管理](https://docs.mulesoft.com/jp/access-management/) # Anypoint VPC 接続方法 次の方法を使用して Anypoint Virtual Private Cloud (Anypoint VPC) をプライベートネットワークに接続できます。 - IPsec トンネル - トランジットゲートウェイアタッチメント - VPC ピアリング VPC ピアリングを使用して Anypoint VPC に接続するには、MuleSoft サポート担当者にお問い合わせください。 - AWS Direct Connect AWS Direct Connect を使用して Anypoint VPC を接続するには、MuleSoft サポート担当者にお問い合わせください。
接続の数には関係なく、VPC ごとに最大 95 件のルートテーブルエントリが許可されます。この制限を超えないように、ネットワークを統合して接続数を可能な限り少なく抑えてください。
## [](#ipsec-トンネル)IPsec トンネル ネットワーク間設定で IPsec トンネルを使用して、オンプレミスのデータセンターを Anypoint VPC に接続することができます。IPsec VPN トンネルは、標準化されたセキュアな接続方法が提供されるので、VPC とオンプレミスの接続で一般に推奨されるソリューションです。この方法は、ルーターやアプライアンスなどの既存の IT インフラストラクチャともうまく統合します。 ![IPsec トンネルの概要](/mulesoft/current/ja-jp/cloudhub/_images/vpc-overview-ipsec.png)
レガシー VPN を使用している場合は、変更を行う前に Anypoint VPN に移行してください。
ネットワークとの Anypoint VPN 接続を作成するには、​[「Anypoint VPN」](https://docs.mulesoft.com/jp/cloudhub/vpn-about)​を参照してください。 ## [](#トランジットゲートウェイアタッチメント)トランジットゲートウェイアタッチメント AWS トランジットゲートウェイは AWS のクラウドルーターとして機能し、VPC、オンプレミスデータセンター、サードパーティソフトウェア間のネットワークアクセスを簡略化すると同時に、ネットワークの可視性を高め、制御を強化します。 トランジットゲートウェイは、事実上組織のクラウドリソースとオンプレミスデータセンターを 1 つのネットワークトポロジーにマージするものです。 CloudHub では、Anypoint VPC を AWS アカウントの AWS トランジットゲートウェイに安全にアタッチすることでこのネットワークの簡略化を活用できます。 トランジットゲートウェイアタッチメントを使用するには、Anypoint VPC と AWS トランジットゲートウェイが同じリージョンにある必要があります。 ![トランジットゲートウェイの概要](/mulesoft/current/ja-jp/cloudhub/_images/vpc-overview-tgw.png) Anypoint VPC をトランジットゲートウェイにアタッチするには、​[「トランジットゲートウェイアタッチメント」](https://docs.mulesoft.com/jp/cloudhub/tgw-about)​を参照してください。 ## [](#vpc-ピアリング)VPC ピアリング VPC ピアリングは、2 つの VPC 間の接続を提供します。この場合、プライベート Amazon VPC が Anypoint VPC と直接ペアリングされます。これにより、2 つの VPC 間でトラフィックを転送し、同じネットワーク内にあるのと同様の通信が可能になります。 ![VPC ピアリングの概要](/mulesoft/current/ja-jp/cloudhub/_images/vpc-overview-peering.png)

VPC ピアリングを使用するには、AWS VPC と Anypoint VPC が同じリージョンにある必要があります。

## [](#aws-direct-connect)AWS Direct Connect Anypoint VPC への Direct Connect 接続を作成するには、AWS アカウントで既存の AWS トランジットゲートウェイを作成または利用してトランジットゲートウェイへの Direct Connect 接続をセットアップします。 続いて、Anypoint VPC をトランジットゲートウェイにアタッチし、必要なルーティングを設定して Anypoint VPC オンプレミス接続を有効にします。 ![AWS Direct Connect の概要](/mulesoft/current/ja-jp/cloudhub/_images/vpc-overview-dx.png)

Direct Connect を使用するには、AWS Direct Connect パートナーと Anypoint VPC が同じリージョンにある必要があります。Direct Connect ゲートウェイはサポートされていません。 Direct Connect では、ボーダーゲートウェイプロトコル (BGP) を使用した動的ルーティングが必要です。

可用性を高めるには、異なる AWS Direct Connect の場所から複数の Direct Connect を使用してください。

## [](#関連情報)関連情報 - [ネットワークへの VPC 接続の要求](https://docs.mulesoft.com/jp/cloudhub/to-request-vpc-connectivity) - [Anypoint VPN](https://docs.mulesoft.com/jp/cloudhub/vpn-about) - [トランジットゲートウェイアタッチメント](https://docs.mulesoft.com/jp/cloudhub/tgw-about) # Anypoint VPN Anypoint VPN を使用すると、MuleSoft Virtual Private Cloud (VPC) と自分のオンプレミスネットワークを安全に接続できます。必要であれば、サイト間で複数の VPN を作成できます。
作成できる VPN の数は、アカウントで利用できる VPN エンタイトルメントの数によって異なります。自分のアカウントに割り当てられている VPN エンタイトルメントの数が不明な場合は、MuleSoft アカウント担当者までお問い合わせください。
Anypoint VPN では、サイト間でのインターネットプロトコルセキュリティ (IPsec) 接続がサポートされています。VPN エンドポイントと呼ばれる物理的なアプライアンスまたはソフトウェアアプライアンスが、ユーザー側の接続終端装置となります。接続の MuleSoft 側は、仮想プライベートゲートウェイ (VGW) の実装となります。MuleSoft VGW は単一の MuleSoft VPC に関連付けられますが、最大 10 件の VPN 接続をサポートできます。
MuleSoft 実装の機能は、他の VGW 製品とは異なる場合があります。
## [](#anypoint-vpn-の機能)Anypoint VPN の機能 各 Anypoint VPN 接続にはトンネルが 2 つあり、リモートロケーションにある 1 件のパブリック IP アドレスに接続できます。リモートロケーションで接続するパブリック IP アドレスを 1 件増やすには、2 件の VPN 接続を作成する必要があります。 1 件の VPN によって MuleSoft VPC の可用性が高まります。ルーチンメンテナンスによって VPN 接続の 2 つのトンネルの片方が短時間だけ無効になることがあります。このときは VPN 接続が他方のトンネルに自動的にフェールオーバーするため、アクセスは中断されません。このため、エンドポイントでは両方のトンネルを設定する必要があります。トンネルの選択は、VPN エンドポイントの容量とルーティング種別の選択によって決まります。 MuleSoft VGW 実装では、最大 1.25 Gbps のスループットをサポートします。同じ VPC に対する複数の VPN 接続では、1 つの VGW のスループット容量が共有されます。VPN 接続スループットは、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 分)
これらの IPsec 設定の一部は Government Cloud ではサポートされません。特定の Government Cloud VPN 設定については、​「Anypoint VPN 設定」​を参照してください。
### [](#anypoint-vpn-ルーティング)Anypoint VPN ルーティング Anypoint VPN では、VPN 接続で動的ルーティングと静的ルーティングがサポートされています。 - **動的ルーティング**​ - ユーザーのデバイスがボーダーゲートウェイプロトコル (BGP) を使用して Anypoint VPN へのルートを動的にアドバタイズします。デバイスがこのプロトコルをサポートする場合は、BGP ルーティングを使用してください。 - **静的ルーティング**​ - Anypoint VPN を介したアクセスを可能にするネットワークのルート (サブネット) を指定する必要があります。
VPN 接続の数には関係なく、VPC ごとに最大 95 件のルートテーブルエントリが許可されます。制限を超えないように、可能な限り少ない数にネットワークを統合してください。
### [](#制限事項)制限事項 Anypoint VPN では、以下の機能と設定はサポートされていません。 - ネットワークアドレス変換 (NAT) - IPv6 - ポリシーベース VPN を使用した IKEv2 - AWS Direct Connect と Anypoint VPN 接続の両方を使用した単一の VPC - 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`​ で有効化できます。 - 非対称ルーティングの許可 非対称ルーティングとは、ルーティングポリシーによってネットワークから VPC に送信されるトラフィックと VPC から返されるトラフィックが別々のトンネルを通るルーティング方式です。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 トンネルに入る TCP パケットの最大セグメントサイズを調整してください。 VPN ヘッダーには追加スペースが必要であり、データで利用できるスペース量が少なくなります。 この影響を抑えるには、エンドポイントを TCP MSS 調整: 1387 バイトで設定します。 - パケットで ​`DF`​ フラグをリセットしてください。 パケットに Don’t Fragment (​`DF`​) フラグが付いていると、パケットの分割が禁止されます。一部の VPN デバイスでは、​`DF`​ フラグを変更して、必要であればパケットを無条件に分割できます。利用できる場合は、​`Clear Don’t Fragment (DF) Bit`​ 設定を有効にしてください。 ## [](#テスト済みのネットワークデバイス)テスト済みのネットワークデバイス Anypoint VPN で動作することがわかっているネットワークデバイスを以下に示します。テスト済みデバイスのリストに自分のデバイスが記載されていない場合は、​[要件](#vpn_requirements)​を参照して、自分のデバイスが Anypoint VPN での使用に適しているかどうかを確認してください。
ハードウェア ソフトウェア

Check Point Security Gateway

R77.10 以降

Cisco ASA

ASA 8.2 以降

Cisco 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 以降

Juniper SRX-Series Services Gateway

JunOS 11.0 以降

Juniper SSG

ScreenOS 6.1 または 6.2 以降

Juniper 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

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

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

リストされているデバイスの ​**\[Get VPN Config (VPN 設定を取得)\]**​ メニューから特定の​**デバイス設定**​ファイルをダウンロードできない場合、​**\[Generic (汎用)\]**​ VPN 設定ファイルを使用してください。 ![「Generic (汎用)」 VPN 設定ファイルオプション](/mulesoft/current/ja-jp/cloudhub/_images/vpn-device-generic-config.png) ## [](#関連情報)関連情報 - [Anypoint VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub/vpn-create-arm) - [Anypoint VPN 高可用性](https://docs.mulesoft.com/jp/cloudhub/vpn-high-availability) - [Anypoint VPN ナレッジ記事](https://help.mulesoft.com/s/article/Anypoint-VPN-Knowledge-Articles) # Anypoint VPN のダウンタイムリスク Mulesoft にプロビジョニングされたすべての VPN には、VPN トンネルの状態に応じて関連付けられたリスクがあります。 ダウンタイムリスクが高い VPN の場合は、​[高可用性 VPN](https://docs.mulesoft.com/jp/cloudhub/vpn-high-availability)​ソリューションをデプロイして AWS で配信される自動更新に関連付けられたダウンタイムを回避してください。詳細は、​[「Anypoint VPN のメンテナンス」](https://docs.mulesoft.com/jp/cloudhub/vpn-maintenance)​を参照してください。 ## [](#ダウンタイムリスクの種類)ダウンタイムリスクの種類 VPN ダウンタイムリスクはアップ状態のトンネルの数に応じて異なります。 ダウンタイムリスクには次の 3 種類があります。 - UNAVAILABLE (使用不可) - LOW (低) - HIGH (高) VPN の両方のトンネルがダウンしている場合、VPN を通過するデータがないため、VPN ダウンタイムリスクは ​**\[UNAVAILABLE (使用不可)\]**​ になります。 VPN にアップ状態のトンネルが 1 つあり、もう 1 つのトンネルがダウンしている場合、VPN のダウンタイムリスクは ​**\[HIGH (高)\]**​ になります。 VPN の両方のトンネルがアップ状態の場合、VPN のダウンタイムリスクは ​**\[LOW (低)\]**​ になります。 ## [](#anypoint-platform-で-vpn-のリスクを確認する)Anypoint Platform で VPN のリスクを確認する Anypoint Platform で VPN に関連付けられたダウンタイムリスクを確認できます。 VPN のダウンタイムリスクを確認する手順は、次のとおりです。 1. Anypoint Platform にサインインします。 2. Runtime Manager に移動します。 3. **\[VPNs (VPN)\]**​ タブを開きます。 4. VPN の ​**\[Downtime Risk (ダウンタイムリスク)\]**​ 列を確認します。 ![VPN のダウンタイムリスクの UI](/mulesoft/current/ja-jp/cloudhub/_images/vpn-downtime-risk.png) ## [](#関連情報)関連情報 - [Anypoint VPN 高可用性](https://docs.mulesoft.com/jp/cloudhub/vpn-high-availability) - [Anypoint VPN のメンテナンス](https://docs.mulesoft.com/jp/cloudhub/vpn-maintenance) - [Using Redundant Site-to-Site VPN Connections to Provide Failover (冗長性のあるサイト間 VPN 接続を使用したフェールオーバーの実現)](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) # Anypoint VPN のトラブルシューティング 以下に、Anypoint VPN との接続を試みると発生する可能性があるエラーをいくつか示します。 ## [](#anypoint-vpn-に接続できない)Anypoint VPN に接続できない Anypoint VPN に接続できない場合は、設定されているファイアウォールで、VPN トンネルの ​`localExternalIpAddress`​ 項目の IP アドレスを経由するトラフィックが許可されていることを確認してください。 ## [](#no_proposal_chosen-エラーまたは-cannot-establish-phase-1-connection)`NO_PROPOSAL_CHOSEN`​ エラーまたは ​`Cannot Establish Phase 1 Connection` これはフェーズ 1 設定の問題が原因である考えられます。 Anypoint VPN 接続は IKEv1 のみをサポートするため、IKEv2 は機能しません。 サポートされるフェーズ 1 Diffie-Hellman (DH) グループは、2、14-18、22、23、24 です。 ## [](#フェーズ-2-接続を確立できない)フェーズ 2 接続を確立できない フェーズ 2 DH グループがサポートされていない可能性があります。サポートされるフェーズ 2 DH グループは、2、5、14-18、22、23、24 です。 ## [](#vpc-ルートテーブルにルートが存在しない)VPC ルートテーブルにルートが存在しない VPC ルートテーブルは、トンネルがアクティブになるまでは更新されません。 静的ルーティングを使用している場合は、トンネルがアクティブになるとリモートネットワークがルートテーブルに追加され、非アクティブになるとテーブルから削除されます。これは想定される動作です。 BGP を使用している場合は、トンネルがアクティブになると VPN エンドポイントからルートが伝播されます。ルートテーブルに必要なエントリが表示されていない場合は、BGP セッションがアクティブであることを確認し、デバイスの BGP 設定が正しいことを検証してください。 ## [](#anypoint-vpn-トンネル接続は機能しているがルートが伝播されない)Anypoint VPN トンネル接続は機能しているがルートが伝播されない トンネルの近隣の IP アドレスが、トンネルの詳細のローカルポイントツーポイント IP アドレスから取得されていることを確認してください。 ## [](#フェーズ-2-sa-は確立されているがトラフィックがトンネルを通過しない)フェーズ 2 SA は確立されているがトラフィックがトンネルを通過しない VPN 接続では、トンネルにつき 1 つのみのセキュリティアソシエーション (SA) ペアがサポートされるので、接続ごとに複数のトラフィックセレクターがあると予期しない結果となります。 これを解決するには、VPN トンネル接続ごとに一意の SA が 1 つだけ使用されていることを確認してください。複数のポリシーが必要な場合は、ネットワーク内のトラフィックを統合して絞り込む必要があります。 ## [](#anypoint-vpn-トンネルが非アクティブ期間後に切断される)Anypoint VPN トンネルが非アクティブ期間後に切断される IPsec は「対象トラフィック」 (Anypoint VPN 接続を介して暗号化されるトラフィック) を送信することで確立されます。対象トラフィックがない場合、トンネルは切断されます。これは想定される動作であり、タイムアウト値は可変です。 一部の VPN 設定では、トンネルをアクティブ状態に維持するための追加ステップが必要であり、対象トラフィックを定期的に送信する必要があります。たとえば、CloudHub ワーカーの内部 IP アドレスまたは FQDN に対して ICMP 要求を 5 秒ごとに送信すると、トンネルはアクティブ状態を維持できます。 ## [](#runtime-manager-ui-の-tunnel-status-トンネルの状況-に誤った値が表示される)Runtime Manager UI の \[Tunnel Status (トンネルの状況)\] に誤った値が表示される トンネルの状況を取得する時間には、インフラストラクチャプロバイダー API の固有の遅延が含まれるため、正しい状況が報告されるまで最大 5 分遅れる可能性があります。この情報を使用して、トンネル間のフェールオーバーをトリガーしないでください。代わりに、顧客側の VPN ゲートウェイのトンネルを監視します。 ## [](#関連情報)関連情報 - [Anypoint VPN ナレッジ記事のメインページ](https://help.mulesoft.com/s/knowledge) # Anypoint VPN のメンテナンス ## [](#anypoint-vpn-の更新)Anypoint VPN の更新 MuleSoft Anypoint VPN は、AWS サイト間 VPN 接続に裏打ちされた管理されたサービスです。VPN の使用は、オンプレミスまたは外部プラットフォームへの接続が必要なインテグレーションやフローにとって重要です。更新する Anypoint VPN が BGP ルーティングを使用するトンネルのペアがまったくない状態でセットアップされていると、更新時にダウンタイムが発生します。詳細は、​[「Anypoint VPN 高可用性」](https://docs.mulesoft.com/jp/cloudhub/vpn-high-availability)​を参照してください。 2022 年 10 月の四半期メンテナンス期間以降は、Anypoint VPN では四半期ごとの顧客による自己アップグレードはサポートされません。この時点以降、Anypoint VPN に更新を行う場合、AWS の標準的な継続的アップグレードプロセスに従って行われます。アップグレードはオンデマンドで適用され、メンテナンス期間のスケジュールはパブリッシュされず、顧客によるオプトインの自己アップグレード機能は提供されませんが、​[高可用性 (HA) VPN 実装](https://docs.mulesoft.com/jp/cloudhub/vpn-high-availability)​**がない顧客の場合は (限定的な) ダウンタイムが発生する可能性があります**​。 [高可用性 VPN](https://docs.mulesoft.com/jp/cloudhub/vpn-high-availability)​ソリューションをデプロイして、AWS で配信されるセキュリティ更新に関連付けられたダウンタイムを回避してください。推奨事項とトラブルシューティングの情報については、下のセクションを参照してください。 ## [](#オンデマンドメンテナンス中のダウンタイムの回避または短縮)オンデマンドメンテナンス中のダウンタイムの回避または短縮 Anypoint VPN 接続を使用する Mule アプリケーションは、オンデマンドメンテナンス中に影響を受けます。Anypoint VPN に対する影響は VPN 設定によって異なります。 - トリガー時にトンネルをリセットするための BGP ルーティングと DPD (デッドピア検出) で設定されているトンネルのペアが 1 つ以上ある Anypoint VPN では、ダウンタイムが最小限に抑えられます。切り替えに要する時間は数秒です。DPD と VPN の説明は、 [「DPD (Dead Peer Detection) and Anypoint VPN (Virtual Private Networking) (DPD (デッドピア検出) と Anypoint VPN (仮想プライベートネットワーキング))^」](https://help.mulesoft.com/s/article/DPD-Dead-Peer-Detection-and-Anypoint-VPN-Virtual-Private-Networking)​を参照してください。 - 静的ルーティングで設定されている Anypoint VPN トンネルペアでは、再接続前に多少のダウンタイムが発生します。失敗したトンネルを検出する自動フェールオーバーメカニズムがない場合、再接続に要する時間が長くなります。 - BGP ルーティングまたはフェールオーバーメカニズムなしで設定されているか、1 つのトンネルしか設定されていない Anypoint VPN では、更新が行われ、元のトンネルが復旧するまでの停止時間が最大 60 分となります。 ## [](#anypoint-vpn-のオンデマンドメンテナンス中の問題のトラブルシューティング)Anypoint VPN のオンデマンドメンテナンス中の問題のトラブルシューティング オンデマンドメンテナンス中に、次のような問題が発生する可能性があります。 ### [](#トンネルが表示されない)トンネルが表示されない いずれかの時点で 10 ~ 15 分以内にトンネルが再び表示されない場合は、再び表示されるようにトンネルを再起動してみてください。 VPN が静的ルーティングで設定されている場合は、VPN が表示されるように Anypoint VPN に対する「興味深いトラフィック」(Anypoint VPN 接続で暗号化する必要があるトラフィック) を生成してみてください。詳細は、 [「How to Generate Interesting Traffic for Anypoint VPN (Anypoint VPN の興味深いトラフィックの生成方法)^」](https://help.mulesoft.com/s/article/How-to-Generate-Interesting-Traffic-for-Anypoint-VPN)​を参照してください。 ### [](#非アクティブが原因でトンネルがダウンする)非アクティブが原因でトンネルがダウンする VPN トンネルを経由するトラフィックがない場合、非アクティブが原因でダウンします。この場合、興味深いトラフィックを生成してください。BGP に移行することをお勧めします。 ### [](#ike-フェーズの有効期間が一致しない)IKE フェーズの有効期間が一致しない #### [](#ikev2-を使用している場合)IKEv2 を使用している場合: オンデマンドメンテナンス後に信頼性の高いトンネル操作を維持するには、IKEv2 フェーズ 1 とフェーズ 2 の有効期間が​[「IPsec の設定」](https://docs.mulesoft.com/jp/cloudhub/vpn-about#ipsec-settings)​で説明されているように設定されていることを確認してください。 - IKE フェーズ 1 の有効期間: 28000 秒 - IKE フェーズ 2 の有効期間: 3000 秒
AWS ドキュメントでは、IKE フェーズ 1 の有効期間は 28800 秒、IKE フェーズ 2 の有効期間は 3600 秒と記されています。MuleSoft では、ファイアウォールデバイスが最初にタイムアウトになり、鍵再設定プロセスが制御されるように、28000/3000 の組み合わせを推奨しています。
#### [](#ikev1-を使用している場合)IKEv1 を使用している場合: IKEv1 を使用している場合は、デフォルトの組み合わせ (フェーズ 1 の有効期間には 28800 秒、フェーズ 2 の有効期間には 3600 秒) を使用してください。 ### [](#ipsec-フェーズ-2-で-pfs-が有効になっていないことが原因で-anypoint-vpn-が定期的にダウンする)IPsec フェーズ 2 で PFS が有効になっていないことが原因で Anypoint VPN が定期的にダウンする Azure VPN を使用している場合は、PFS が有効になっていることを確認して、フェーズ 2 の有効期間を調整してください。詳細は、以下を参照してください。 - [IPsec フェーズ 2 で PFS が有効になっていないことが原因で Anypoint VPN が定期的にダウンする](https://help.mulesoft.com/s/article/Anypoint-VPN-goes-Down-Periodically-Due-to-PFS-is-not-Enabled-for-IPsec-Phase-2) - [Anypoint VPN to Azure Keeps Going Down Every Hour (Anypoint VPN から Azure の接続が 1 時間ごとにダウンする)](https://help.mulesoft.com/s/article/Anypoint-VPN-to-Azure-keeps-going-down-every-hour) ### [](#更新後に-bgp-ルーティングがある-anypoint-vpn-が非同期モードになる)更新後に BGP ルーティングがある Anypoint VPN が非同期モードになる 同じ VPN の 2 つのトンネルの AS パスが異なる場合、オンデマンドメンテナンス後に Anypoint VPN は非同期モードになります。詳細は、 [「Anypoint VPN with BGP Routing Enters Asymmetric Mode after Upgrade (アップグレード後に BGP ルーティングがある Anypoint VPN が非同期モードになる)^」](https://help.mulesoft.com/s/article/Anypoint-VPN-with-BGP-Routing-Enters-Asymmetric-Mode-After-update)​を参照してください。 ### [](#vpn-ログに-ipsec-dpd-エラーが表示される)VPN ログに IPsec DPD エラーが表示される DPD 設定が正しく定義されていることを確認してください。詳細は、 [「VPN ログに IPsec DPD エラーが表示される」](https://help.mulesoft.com/s/article/Seeing-IPsec-DPD-Failures-in-VPN-Logs)​を参照してください。 ### [](#その他の問題)その他の問題 Anypoint VPN の他の問題については、​[「Anypoint VPN のトラブルシューティング」](https://docs.mulesoft.com/jp/cloudhub/vpn-troubleshooting)​を参照してください。 # Anypoint VPN 接続の作成 Runtime Manager を使用して Anypoint VPN 接続を作成できます。 ## [](#前提条件)前提条件 Anypoint VPN を作成するための前提条件は次のとおりです。 - Anypoint Virtual Private Cloud (Anypoint VPC) を作成する必要があります。 詳細は​[「Virtual Private Cloud」](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​を参照してください。 1 つの Anypoint VPC は最大 10 個の Anypoint VPN に対応できます。 - VPN ページにアクセスするための「CloudHub Network Administrator (CloudHub ネットワーク管理者)」または「CloudHub Network Viewer (CloudHub ネットワーク閲覧者)」ユーザー権限を持っている必要があります。 - デフォルト環境 (プロファイルで定義されています) に「Read Application (アプリケーションの参照)」権限が付与されている必要があります。 ![vpn permissions](/mulesoft/current/ja-jp/cloudhub/_images/vpn-permissions.png) [「Grant Permissions and Roles to Users (ユーザーへの権限とロールの付与)」](https://docs.mulesoft.com/jp/access-management/users#grant-permissions-and-roles-to-users)​を参照してください。 VPN ページは、VPN エンタイトルメントを持つ Anypoint 組織に対して表示されます。 ### [](#anypoint-vpn-を作成する場合のチェックリスト)Anypoint VPN を作成する場合のチェックリスト Anypoint VPN を作成または設定するときには、次の情報を入力する必要があります。 Remote IP アドレス (リモート IP アドレス) VPN エンドポイントの公開 IP アドレス。単一の静的 IP アドレスである必要があります。 Static Routes (CIDR) (静的ルート (CIDR)) VPN 経由でアクセスできるようにするネットワークのサブネット。この情報は静的ルーティングを使用する場合のみ必須です。 Remote and Local ASN (リモートおよびローカル ASN) ASN (自律システム番号) は、ルーティングのプレフィックスのコレクションを指定します。リモート ASN とローカル ASN の両方を設定する必要があります。これは動的ルーティングを使用する場合のみ必須です。 Pre-shared Key (PSK) (事前共有キー (PSK)) VPN トンネルの共有シークレット。これらの値は ​**\[Automatic Tunnel Configuration (自動トンネル設定)\]**​ を選択すると自動生成されます。 Point-to-Point CIDR (ポイントツーポイント CIDR) VPN トンネルインターフェースの非公開 IP 範囲。これらの値は ​**\[Automatic Tunnel Configuration (自動トンネル設定)\]**​ を選択すると自動生成されます。 ## [](#anypoint-vpn-の作成)Anypoint VPN の作成 Anypoint VPN を作成する手順は、次のとおりです。 1. Anypoint Platform にサインインして、​**\[Runtime Manager\]**​ を選択します。 2. Anypoint VPN を作成する環境を選択します。 3. 左側のメニューで ​**\[VPNs\]**​ タブをクリックしてから ​**\[Create VPN (VPN を作成)\]**​ をクリックします。 4. Anypoint VPN について次の情報を入力または選択します。 **Name (名前)** Anypoint VPN の名前を入力します。 **VPC** リストから、Anypoint VPN 接続の Virtual Private Cloud を選択します。 **Remote IP アドレス (リモート IP アドレス)** VPN エンドポイントのパブリック IP アドレスを入力します。 5. 使用するルーティング種別を選択します。 **\[BGP\]**​ (動的) または ​**\[Static (静的)\]**​ を選択できます。デバイスでサポートされている場合は、ボーダーゲートウェイプロトコル (BGP) 種別を選択してください。 **動的ルーティングを作成する場合**​: 1. **\[BGP\]**​ を選択します。 2. リモート ASN を定義します。 バックエンドに対応する ASN を入力します。ネットワークに割り当てられている既存の ASN、またはネットワークに割り当てられていないプライベート ASN (64512–65534) を使用できます。デフォルト値は ​`65001`​ です。 3. ローカル ASN を定義します。 MuleSoft 側の ASN を割り当てます。ネットワークに割り当てられていないプライベート ASN (64512–65534) を使用してください。デフォルト値は ​`64512`​ です。 **静的ルーティングを作成する場合**​: 1. **\[Static (静的)\]**​ を選択します。 2. **\[CIDR\]**​ 項目に、VPN 経由でアクセスできるようにするサブネットを入力します (例: `10.0.0.0/8`​)。 3. サブネットを追加する場合は、​**\[Add New Rule (新規ルールを追加)\]**​ をクリックして、上のステップを繰り返します。 VPN 接続の数には関係なく、VPC ごとに最大 95 件のルートテーブルエントリが許可されます。この制限を超えないように、ネットワークを統合して接続数を可能な限り少なく抑えてください。 6. **\[Tunnel Configuration (トンネル設定)\]**​ 種別を選択します。 **\[Automatic (自動)\]**​ または ​**\[Custom (カスタム)\]**​ を選択できます。ほとんどの場合は ​**\[Automatic (自動)\]**​ で十分です。手順は選択したトンネル種別によって異なります。 **\[Automatic (自動)\] トンネル設定を使用する場合**​: 1. **\[Automatic (自動)\]**​ を選択します。 他の入力は不要です。このオプションは、Anypoint VPN に必要なトンネルを自動的に設定します。 トンネルの設定は VPN の作成後に表示されます。 **\[Custom (カスタム)\] トンネル設定を使用する場合**​: 1. **\[Custom (カスタム)\]**​ を選択します。 2. 各トンネルの ​**\[PSK\]**​ 項目に、先頭が 0 ではない 8 ~ 64 文字の値を入力します。 英数字、ピリオド (.)、およびアンダースコア (\_) のみを使用してください。 3. 各トンネルの ​**\[Point-to-Point CIDR (ポイントツーポイント CIDR)\]**​ 項目に、VPN トンネルの内部アドレスの IP アドレス範囲を入力します。 `169.254.0.0/16`​ 範囲から、サイズ /30 の CIDR ブロックを指定できます。CIDR ブロックはすべての VPN 接続で一意であることが必要です。 次の 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
Anypoint VPN 接続を作成した後にトンネル設定を変更することはできません。既存の接続の設定を変更するには、Anypoint VPN 接続を削除して新しい接続を作成してください。
7. **\[Create VPN (VPN を作成)\]**​ をクリックします。 VPN の初期状況は ​`PENDING`​ です。これは、インフラストラクチャの作成中に想定される状況です。状況が ​`AVAILABLE`​ に変わってから次の手順に進んでください。 詳細は ​[\[vpn-and-tunnel-status\]](#vpn-and-tunnel-status)​ を参照してください。 8. Anypoint VPN から設定ファイルをダウンロードします。 1. Runtime Manager で、今作成した Anypoint VPN の名前をクリックします。 2. **\[Get VPN Config (VPN 設定を取得)\]**​ をクリックします。 3. **\[Download VPN Config (VPN 設定をダウンロード)\]**​ ウィンドウで、VPN エンドポイントデバイスのベンダー、プラットフォーム、ソフトウェアバージョンを選択します。 使用しているデバイス種別が表示されていない場合は、​**\[generic (汎用)\]**​ を選択します。 4. **\[View Config (設定を表示)\]**​ をクリックしてから、右上隅にある ​**\[Copy (コピー)\]**​ ボタンをクリックします。 5. 設定内容をテキストファイルに貼り付けます。 すべての設定ファイルは、IKEv1、AES128、SHA1、および DH Group 2 の最小要件を表しています。使用している VPN エンドポイントに合わせて設定を変更することで、他のサポート対象の IPsec 設定を利用できます。​[「IPsec の設定」](https://docs.mulesoft.com/jp/cloudhub/vpn-about#ipsec-settings)​を参照してください。 9. VPN エンドポイントを設定します。 1. VPN 設定ファイル (ステップ 8) を VPN エンドポイント管理者と共有します。 2. VPN エンドポイントの設定によっては、追加の設定手順が必要になる場合もあります。 詳細は、​[「VPN の要件」](https://docs.mulesoft.com/jp/cloudhub/vpn-about#vpn_requirements)​を参照してください。 使用している VPN エンドポイントのドキュメントを参照し、ネットワークのコンポーネントが正しく設定されていることを確認してください。 予期しない動作を回避するため、VPN エンドポイントで両方のトンネルを設定してください。 ## [](#vpn-とトンネルの状況)VPN とトンネルの状況 作成した新しい VPN 接続が VPN のリストに表示されます。インフラストラクチャの作成中は、​**\[Status (状況)\]**​ 列には ​`PENDING`​、両方の Anypoint 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 サポートにお問い合わせください。

## [](#関連情報)関連情報 - [Anypoint VPN](https://docs.mulesoft.com/jp/cloudhub/vpn-about) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [Anypoint VPN ナレッジ記事](https://help.mulesoft.com/s/article/Anypoint-VPN-Knowledge-Articles) # Anypoint VPN 接続の変更 Runtime Manager を使用して Anypoint VPN 接続設定の一部を更新できます。 ## [](#ip-アドレス)IP アドレス Anypoint VPN 接続の作成後は、​**\[Remote IP Address (リモート IP アドレス)\]**​ と ​**\[Tunnel Configuration (トンネル設定)\]**​ の設定は変更できません。これらの設定を変更するには、Anypoint VPN を作成し直して、VPN エンドポイントを新しい値で更新する必要があります。 ローカル外部 IP アドレスは、VPN の作成時に動的に割り当てられます。 外部 IP アドレスの予約や再利用はできません。VPN を作成し直すと、新しいローカル外部 IP アドレスが割り当てられます。 ポイントツーポイント IP アドレスと事前共有キー (PSK) は、VPN の作成時に定義されます。 **\[Automatic Tunnel Configuration (自動トンネル設定)\]**​ を使用してこれらの値を自動的に生成するか、または ​**\[Custom Tunnel Configuration (カスタムトンネル設定)\]**​ を使用して自分で値を設定することができます。 詳細は、​[「Anypoint VPN の作成」](https://docs.mulesoft.com/jp/cloudhub/vpn-create-arm#create-an-anypoint-vpn)​を参照してください。 ## [](#ルーティング)ルーティング Anypoint VPN 接続の作成後は、ルーティング種別や自律システム番号 (ASN) は変更できません。これらの設定を変更するには、Anypoint VPN を作成し直して、VPN エンドポイントを新しい値で更新する必要があります。 ## [](#ネットワーク)ネットワーク Anypoint VPC からローカルネットワークが継承されます。Anypoint VPC CIDR ブロックでサブネットを指定することはできません。 Anypoint VPN のリモートネットワークは、接続の作成後でも変更できます。手順は設定されているルーティング種別 (静的または動的) によって異なります。
VPN 接続の数には関係なく、Anypoint VPC ごとに最大 95 件のルートテーブルエントリが許可されます。この制限を超えないように、ネットワークを統合して接続数を可能な限り少なく抑えてください。
### [](#静的ルート)静的ルート 静的ルーティングを使用している Anypoint VPN でリモートネットワークを変更する手順は、次のとおりです。 1. Anypoint Platform にサインインして、​**\[Runtime Manager\]**​ を選択します。 2. 左側のメニューで ​**\[VPNs\]**​ をクリックしてから、更新する VPN の名前をクリックします。 3. **\[Static Routes (静的ルート)\]**​ の下で ​**\[Add New Rule (新規ルールを追加)\]**​ をクリックします。 4. **\[CIDR\]**​ 項目に、VPN 経由でアクセスできるようにするサブネットを入力します (例: `10.0.0.0/8`​)。 5. サブネットを追加する場合は、​**\[Add New Rule (新規ルールを追加)\]**​ をクリックして、ステップ 4 を繰り返します。 6. **\[Apply Changes (変更を適用)\]**​ をクリックして新しいルールを追加します。 7. 対応する Anypoint VPC のファイアウォールルールを確認します。 [「ファイアウォールルールの追加または編集」](https://docs.mulesoft.com/jp/cloudhub/vpc-firewall-rules-concept#add-or-edit-firewall-rules)​を参照してください。 デフォルトでは、ファイアウォールルールで明示的に許可されていない限り、AnypointVPC へのすべてのトラフィックがブロックされます。 8. VPN エンドポイントで設定を更新します。 使用しているデバイスのドキュメントを参照してください。 トンネルがアクティブになると、ルートテーブルが自動的に更新されます。 ### [](#動的ルート)動的ルート 動的ルーティングを使用している Anypoint VPN でリモートネットワークを変更する手順は、次のとおりです。 1. 対応する Anypoint VPC のファイアウォールルールを確認します。 [「ファイアウォールルールの追加または編集」](https://docs.mulesoft.com/jp/cloudhub/vpc-firewall-rules-concept#add-or-edit-firewall-rules)​を参照してください。 デフォルトでは、ファイアウォールルールで明示的に許可されていない限り、AnypointVPC へのすべてのトラフィックがブロックされます。 2. VPN エンドポイントでボーダーゲートウェイプロトコル (BGP) の設定を更新します。 使用しているデバイスのドキュメントを参照してください。 BGP が変更内容を伝播すると、ルートテーブルが自動的に更新されます。 ## [](#ipsec)IPsec Anypoint VPN に対して​**イニシエーターモード**​を設定できます。有効にすると、Anypoint VPN はトンネルを有効にするための IKE ネゴシエーションを開始します。この機能を使用する場合は、次の手順を実行します。 - IKEv1 がサポートされないため、IKEv2 接続を受け入れるようにゲートウェイを設定します。 - ポリシーベースの VPN がサポートされないため、ルートベースの VPN を使用してください。 すべての IPsec 設定はエンドポイント上で定義されます。 エンドポイントの VPN 設定を変更することで、サポート対象のすべての IPsec 設定を利用できます。 [「IPsec の設定」](https://docs.mulesoft.com/jp/cloudhub/vpn-about#ipsec-settings)​を参照してください。 Runtime Manager では、VPN 設定を変更する必要はありません。 ### [](#関連情報)関連情報 - [Anypoint VPN](https://docs.mulesoft.com/jp/cloudhub/vpn-about) - [Anypoint Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [Anypoint VPN ナレッジ記事](https://help.mulesoft.com/s/article/Anypoint-VPN-Knowledge-Articles) - [Issues when Establishing an Anypoint VPN Connection with Initiator Mode enabled (イニシエーターモードを有効にして Anypoint VPN 接続を確立するときの問題)](https://help.mulesoft.com/s/article/Issues-when-establishing-an-Anypoint-VPN-connection-with-Initiator-Mode-enabled) # Anypoint VPN 高可用性 VPN 接続は 2 つの VPN トンネルで構成されます。それぞれの VPN トンネルの終端は異なる可用性ゾーンにあり、VPC での可用性を高めています。必須のアップグレード中に、AWS では VPN 接続の 2 つのトンネルの片方が短時間だけ無効になることがあります。 カスタマーゲートウェイを設定するときは、冗長性を実現するために両方のトンネルを設定してください。片方のトンネルが使用不可になる (たとえば、メンテナンスによる停止) と、AWS では自動的にネットワークトラフィックをその特定の VPN 接続に使用可能なもう一方のトンネルに転送します。AWS では一方の VPN トンネルで更新を実行するときに、フェールオーバーを実現するためにもう一方のトンネルで下側のアウトバウンド Multi-Exit Discriminator (MED) 値を設定します。 AWS のサイト間 VPN の [SLA](https://aws.amazon.com/vpn/site-to-site-vpn-sla/)​ では接続ごとに 2 つの VPN エンドポイントが要求されます。 冗長な Anypoint VPN トンネル設定により、AWS の自動パッチ適用期間中の MuleSoft サービスダウンタイムを防止できます。 アプリケーションと関連する操作が Anypoint VPN の更新、問題、または個別の顧客ゲートウェイのエラーに対応できるようにするには、冗長な Anypoint VPN 接続を使用した高可用性を実装します。 各 Anypoint VPN 接続にはエンドポイントが 2 つあり、デフォルトで MuleSoft 側で高可用性 (HA) が提供されます。 ## [](#前提条件)前提条件 - 各 VPN 接続に十分なエンタイトルメントがあること - 異なる公開 IP アドレスを使用する 2 つの VPN エンドポイントがあること - Runtime Manager に 2 つの VPN 接続があること ## [](#anypoint-vpn-を使用した高可用性の設定)Anypoint VPN を使用した高可用性の設定 次の例は、1 つの Anypoint VPC と 2 つの VPN 接続を使用した高可用性 VPN トポロジーを示しています。 MuleSoft 仮想プライベートゲートウェイ (VGW) では、1 つの Anypoint VPC 関連付けと最大 10 個の VPN 接続をサポートしています。 VPN ゲートウェイは同じデータセンター内で見つけることも、異なる物理的な場所で見つけることもできます。 すべての単一障害点をなくすには、2 つのカスタマーゲートウェイが異なるデータセンターにある必要があり、異なる都市にあるのが理想的です。理想としては、2 つ目のゲートウェイに障害回復ロケーションを使用してください。 ![VPN 高可用性トポロジー](/mulesoft/current/ja-jp/cloudhub/_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 を確立する静的ルーティングもサポートしています。 ## [](#関連情報)関連情報 - [Anypoint VPN 接続の作成](https://docs.mulesoft.com/jp/cloudhub/vpn-create-arm) - [Anypoint VPN のダウンタイムリスク](https://docs.mulesoft.com/jp/cloudhub/vpn-downtime-risk) - [Using Redundant Site-to-Site VPN Connections to Provide Failover (冗長性のあるサイト間 VPN 接続を使用したフェールオーバーの実現)](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) - [Continue to Have Redundant Pair of VPNs as Well (VPN の冗長なペアの継続的な使用)](https://docs.aws.amazon.com/vpn/latest/s2svpn/disaster-recovery-resiliency.html) - [How to Calculate VPC and VPN License Requirements (VPC および VPN ライセンス要件の計算方法)](https://help.mulesoft.com/s/article/How-to-Calculate-VPC-and-VPN-License-Requirements) # CloudHub API CloudHub 管理 API (CloudHub API) を使用すると、Anypoint Runtime Manager の次の機能にプログラムでアクセスできます。 - アプリケーションの管理: - CloudHub でアプリケーションを作成、デプロイ、開始、終了、リスト、削除する。 - ワーカー数、Mule Runtime Engine バージョン、システムプロパティなどのアプリケーションのメタデータを更新する。 - アプリケーションやワーカーの統計情報を取得する。 - アプリケーションのトランザクションやトランザクションのイベントを取得する。 - 再生データを確認し、トランザクションのフローを再生して、アプリケーションの再生データを削除する。 - 静的 IP アドレスを管理して、アプリケーションに関連付けられている未使用の IP アドレスを解放する。 - アプリケーションの Mule パッケージをダウンロードする。 - スケジュールの全部または一部を更新、有効化、無効化、または実行する。 - ログ、通知、アラートの管理: - アプリケーションのログレベルを追加、更新、取得する。 - アプリケーションまたはインスタンスのログファイルをダウンロードする。 - 通知を作成、更新、取得する。 - 通知を既読または未読としてマークする。 - アプリケーションによってトリガーされるアラートを作成、更新、削除する。 - アラートとアラート履歴を取得する。 - ロードバランサーの管理: - ロードバランサーを作成、更新、削除する。 - 組織内のロードバランサーをリストする。 - ロードバランサールールをテストして、入力に適用されるルールの数を返す。 - VPC、VPN、TGW の管理: - VPC を作成、更新、リスト、削除する。 - VPN 接続を作成、削除する。 - Anypoint Platform 組織への複数の AWS トランジットゲートウェイアタッチメントを追加、変更、削除する。 - 永続的なキューの管理: - 永続的なキューの統計情報を取得する。 - 永続的なキューからエントリをクリアする。 - 以下に関する追加情報を取得する: - サポート対象の Mule バージョン - 現在の組織 (使用状況の統計情報を含む) - ワーカー (スレッドダンプとワーカー領域を含む) - ユーザー (権限を含む) - 使用可能なドメイン名 サポートされているリソース、メソッド、必須プロパティ、予想される応答の対話型リファレンスについては、 [「CloudHub API」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)​を参照してください。 CloudHub API は、クラウドベースバージョンの Runtime Manager にデプロイされたアプリケーションのみを管理します。 API を使用したオンプレミスアプリケーションの管理については、 [「Runtime Manager REST サービス」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/arm-rest-services)​を参照してください。 ## [](#cloudhub-api-の使用)CloudHub API の使用 アプリケーションの操作に慣れてから開始してください。 CloudHub API ではどの HTTP クライアントでも使用できます。 Java を使用する場合は、JSON 用の [Jackson](https://github.com/codehaus/jackson)​ がサポートされている [Jersey クライアント](https://jersey.github.io/)​または [HttpClient](http://hc.apache.org/httpclient-3.x/index.html)​ を使用してください。 CloudHub API の操作にアクセスするには、以下を行う必要があります。 1. API を使用して認証するには認証ベアラートークン (​AUTH\_BEARER\_TOKEN​) を生成します。 アクセストークンを取得するには、組織のシステム管理者ロールが割り当てられたユーザーの Anypoint Platform ユーザー名とパスワードが必要です。 [「アクセス管理 API」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/home/)​の [「認証」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/Authentication/)​を参照してください。 ユーザー名により、アクセスする環境が指定されます。 たとえば、ユーザー名が ​`consuela`​ で環境が ​`Development`​ の場合、ユーザー名は ​`consuela@Development`​ になります。 環境を指定しない場合の API のデフォルトは ​`Production`​ です。 2. 組織 ID (​ORG\_ID​) を取得します。 [「アクセス管理 API」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/home/)​の [`/api/me`](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%234250/)​ エンドポイントを参照してください。 3. 環境 ID (​ENV\_ID​) を取得します。 [「アクセス管理 API」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/pages/home/)​の [`/api/organizations/_ORG_ID_/environments`​_ORG\_ID_](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%234762/)​ エンドポイントを参照してください。 ### [](#アプリケーションのリストの取得)アプリケーションのリストの取得 CloudHub にデプロイされたアプリケーションのリストを取得するには、次の ​`curl`​ コマンドを実行します。 curl -X GET \\ --url https://anypoint.mulesoft.com/cloudhub/api/applications \\ -H 'authorization: Bearer AUTH\_BEARER\_TOKEN' \\ -H 'X-ANYPNT-ENV-ID: ENV\_ID' \\ -H 'X-ANYPNT-ORG-ID: ORG\_ID' ## [](#データ形式)データ形式 型を返すまたは受け入れるリソースやメソッドは、JSON データ形式を使用します。 アプリケーションの取得要求への応答として JSON 形式で受信するデータの例を示します。 ```json { "versionId": "xxxxxxxx", "domain": "hello", "fullDomain": "hello.us-e1.cloudhub.io", "properties": { "foo":"bar" }, "propertiesOptions": {}, "status": "STARTED", "workers": { "type": { "name": "Micro", "weight": 0.1, "cpu": "0.1 vCores", "memory": "500 MB memory" }, "amount": 1, "remainingOrgWorkers": 223.7, "totalOrgWorkers": 1000.0 }, "workerStatuses": [ { "id": "i-xxxxxxxx", "host": "xxx.xxx.xxx.xxx", "port": 0, "status": "STARTED", "deployedRegion": "us-east-1", "staticIPEnabled": false } ], "lastUpdateTime": 1589868960908, "fileName": "hello.zip", "muleVersion": { "version": "4.3.0", "updateId": "xxxxxxxx", "latestUpdateId": "xxxxxxxx", "endOfSupportDate": 1633737600000 }, ... } ``` ## [](#レート制限)レート制限 CloudHub 管理 API は、グローバル使用制限を適用しますが、いくつかの例外があります。 ### [](#cloudhub-管理-api-のグローバルレート制限)CloudHub 管理 API のグローバルレート制限 [グローバルレート制限の例外](#グローバルレート制限の例外)​に示す例外を除いた CloudHub 管理 API エンドポイントのレート制限を下表に示します。 アプリケーションがレート制限に達すると、CloudHub は 503 状況コードを返します。
エンドポイント コントロールプレーン クライアント IP アドレスごとのレート制限 状況コード

指定されたエンドポイント以外のすべてのエンドポイント

米国

75 要求/秒

503

EU

25 要求/秒

Government Cloud

### [](#グローバルレート制限の例外)グローバルレート制限の例外 [CloudHub 管理 API のグローバルレート制限](#cloudhub-管理-api-のグローバルレート制限)​の例外を下表に示します。 アプリケーションがレート制限に達すると、CloudHub は下表の状況コードを返します。
エンドポイント コントロールプレーン クライアント IP アドレスごとのレート制限 状況コード

/api ​下のエンドポイント​

/notifications

米国

75 要求/分

503

EU

25 要求/分

Government Cloud

v2/applications/{domain} ​下のエンドポイント

/logs​

すべて

10 要求/秒

429

/deployments/{deploymentId}/logs

/instances/{instanceId}/logs

/instances/{instanceId}/log-file

1 要求/分

500

## [](#状況コードとエラー処理)状況コードとエラー処理 CloudHub API をコールすると、次の状況コードが返されます。
状況コード 説明

200

操作に成功した。

201

リソース (アプリケーションなど) が作成された。

Location​ ヘッダーには、リソースの場所が含まれています。

404

リソースが見つからなかった。

409

リソース (サーバー、サーバーグループ、デプロイメントなど) の作成時に同じ名前のリソースがすでに存在していた。

429

レート制限に達したために操作に失敗した。

500

操作に失敗した。

詳細は、HTTP 本文を参照してください。

503

一時的なじょうたい (例: サーバーの過負荷、レート制限に達した) のために操作に失敗した。

操作を再試行します。

エラーが発生した場合 (500 状況コードなど)、HTTP 応答には JSON 応答とエラーメッセージが含まれます。 ```json 500 Content-Type: application/json Server: Apache-Coyote/1.1 Date: Mon, 10 Aug 2015 00:12:55 GMT { message : "Some error message." } ``` ## [](#関連情報)関連情報 - [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/) - [アクセス管理 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [アプリケーションとサーバーの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) # CloudHub API でのロードバランサーの作成 CloudHub API を使用して専用ロードバランサー (DLB) を作成できます。 ## [](#前提条件)前提条件 CloudHub API を使用してロードバランサーを作成するには、次のことを実行します。 - 自分がロードバランサーを作成する組織のシステム管理者であることを確認する。 - ロードバランサーを作成する組織で Anypoint Virtual Private Cloud (Anypoint VPC) を作成する。 - 少なくとも 1 つの証明書と証明書用の非公開鍵を作成する。 ## [](#ロードバランサーの作成)ロードバランサーの作成 CloudHub API を使用してロードバランサーを作成するには、次のエンドポイントを使用します。 - `anypoint.mulesoft.com/cloudhub/api/organizations/​_orgid_​/loadbalancers` - `anypoint.mulesoft.com/cloudhub/api/organizations/​_orgid_​/vpcs`
DLB の作成後は名前を変更することはできません。名前を変更するには、削除してから新しい名前で作成し直してください。
CloudHub DLB 名の先頭を ​`internal-`​ にすることはできません。DLB 名の先頭を ​`internal-`​ にすると、​`LB name=internal-dlb-name cannot start with -internal`​ のエラーメッセージが返されます。 ## [](#cloudhub-api-を使用した-dlb-での-tls-1-0-の有効化)CloudHub API を使用した DLB での TLS 1.0 の有効化 セキュリティの脆弱性のため TLS 1.0 は推奨されませんが、従来のクライアントとの通信に必要な場合はサポートを有効にできます。 TLS 1.0 のサポートは、DLB のデフォルトの SSL エンドポイントでのみ有効にできます。 TLS 1.0 のサポートの有効化は単一の SSL エンドポイントではなく DLB 全体に適用されます。
セキュリティ上の理由により、TLS 1.0 は有効にしたままにしないでください。 TLS 1.0 が不要になった場合は、デフォルトの暗号化スイートを、たとえば ​NewDefault​ などに置き換えてください。
CloudHub API を使用して DLB で TLS 1.0 のサポートを有効にする手順は、次のとおりです。 1. 次のコマンドを実行します。 ```linenums curl -X PATCH \ https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID \ -H 'authorization: Bearer myAccessToken' \ -H 'content-type: application/json' \ -d '[ { "op": "replace", "path": "/sslEndpoints/0/tlsv1", "value": "true" } ]' ``` コマンドでは: - `_myOrgID_`​ が組織 ID です。 - `_myVpcID_`​ は VPC の ID です。 - `_myDlbID_`​ は DLB の ID です。 - `_myAccessToken_`​ は、生成したアクセストークンです。 応答には以下が含まれます。 `"tlsv1": true,` 2. デフォルトの暗号化スイートを ​`OldDefault`​ に変更します。 [「TLS 1.0 をサポートするようにデフォルトの暗号化スイートを変更する」](https://docs.mulesoft.com/jp/cloudhub/lb-cert-validation#change-the-default-cipher-suite-to-support-tls-1-0)​を参照してください。 ## [](#関連情報)関連情報 - [CloudHub API での新規ロードバランサーの作成](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/1.0.13/console/method/%233964/) - [アクセス管理](https://docs.mulesoft.com/jp/access-management/) - [専用ロードバランサーへの証明書の追加](https://docs.mulesoft.com/jp/cloudhub/lb-cert-upload) - [専用ロードバランサーでの証明書の検証](https://docs.mulesoft.com/jp/cloudhub/lb-cert-validation) # CloudHub FAQ ## [](#cloudhub-とは)CloudHub とは? CloudHub はクラウドベースの、サービスとしてのインテグレーションプラットフォーム (Integration Platform as a Service: iPaaS) であり、これにより、開発者はアプリケーションとサービスの統合およびオーケストレーションができ、運用部門には、ミッションクリティカルな要求に応じるために必要な制御と可視性が提供されます。このすべてを、ミドルウェアまたはハードウェアインフラストラクチャをインストールまたは管理することなく利用できます。 [Anypoint Platform](https://anypoint.mulesoft.com)​ にある Anypoint Runtime Manager を使用して、アプリケーションを CloudHub にデプロイできます。詳細は、CloudHub ​[アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture)​を参照してください。 ## [](#ipaas-とは)iPaaS とは? 名前が示すとおり、iPaaS (サービスとしてのインテグレーションプラットフォーム) はインテグレーションアプリケーションを作成するための開発プラットフォームです。クラウドおよびエンタープライズ内でアプリケーションを統合するための一連のサービスと機能を提供します。iPaaS の核となる理念は、プラットフォーム上のサービスがインテグレーション向けに作成されているという点を除いて PaaS と同じです。マルチテナント、弾力性、信頼性など、期待されるいくつかの基本機能に加えて、iPaaS では、データとイベントの仲介、オーケストレーション、REST および SOAP サービスをパブリッシュするためのサービスコンテナ、強力なセキュリティ機能、監視および開発者ツールが提供されます。 詳細は、 [「Introducing integration PaaS (iPaaS) (インテグレーション PaaS (iPaaS) の概要)」](https://blogs.mulesoft.com/dev/mule-dev/introducing-integration-paas-ipaas/)​を参照してください。 ## [](#cloudhub-アカウントを作成する方法は)CloudHub アカウントを作成する方法は? 2014 年 11 月の時点で、CloudHub と Anypoint Platform for APIs の両方のアカウントが 1 つのプラットフォームにマージされました。 [Anypoint Platform アカウント](https://anypoint.mulesoft.com/#/signup)​を使用すると、​**Runtime Manager**​ にアクセスして、​**CloudHub**​ と他のサーバーの両方にアプリケーションをデプロイして管理できるほか、Anypoint Platform for APIs にアクセスして、API を作成し、ライフサイクル全体にわたって API を管理できます。 - [アカウントの作成](https://docs.mulesoft.com/jp/access-management/managing-your-account) - [アカウントのロールと権限の管理](https://docs.mulesoft.com/jp/access-management/managing-permissions) ## [](#anypoint-studio-の入手場所は)Anypoint Studio の入手場所は? Anypoint Studio は [ここで](https://www.mulesoft.com/lp/dl/studio)​ダウンロードできます。Studio から、CloudHub に直接デプロイしたり、埋め込み Mule Runtime Engine (Mule) でアプリケーションをローカルで実行したりできます。 ## [](#cloudhub-の費用は)CloudHub の費用は? 具体的な価格は、アカウントエグゼクティブまたはアカウント開発担当者にお問い合わせください。 ## [](#サポートを受けるにはどうすればよいですか)サポートを受けるにはどうすればよいですか? CloudHub チームは可能な最良のカスタマーエクスペリエンスを提供することに取り組んでいます。 [MuleSoft ヘルプセンター](https://help.mulesoft.com)​で CloudHub チームにお問い合わせください。 当社のオンライン [フォーラム](https://help.mulesoft.com/s/forum)​を参照および検索して、回答を見つけることができます。または、質問を投稿して新しいスレッドを開始してください。 有料プランのお客様は、サポートポータルをご利用いただけます。 サポートポータルからケースを申請する手順は、次のとおりです。 1. Anypoint Platform にサインインします。 2. **\[?\]**​ メニューから、​**\[Support Center (サポートセンター)\]**​ を選択します。 3. **\[Support (サポート)\]**​ タイルをクリックします。 オープンケースを参照するか、​**\[Contact Support (サポートに問い合わせ)\]**​ をクリックして新しいケースを申請できます。 4. 新しいケースを作成する場合、必須項目 (赤でマークされています) を入力します。 問題の詳細な説明と補足情報を入力します。情報 (​**\[i\]**​) アイコンの上にマウスを置くと、項目固有のガイドラインまたは手順を確認できます。 5. 完了したら、​**\[Submit (送信)\]**​ をクリックします。 一意のケース番号が生成され、ナレッジベースの関連領域が紹介されます。ケースの応答を待っている間にこれをご覧ください。 ## [](#サブスクリプションの期限が切れた場合はどうなりますか)サブスクリプションの期限が切れた場合はどうなりますか? Anypoint Platform アカウントのサブスクリプションの期限が切れる 7 日前に、アカウントの期限切れが迫っていることを通知してアカウント担当者に連絡してアカウントを保持するよう促すメールが届きます。 サブスクリプションの期限が切れると、既存のアプリケーションを再起動したり新しいアプリケーションを作成したりできなくなります。実行中のアプリケーションは、MuleSoft の裁量により、通知なく停止する場合があります。 サブスクリプションを更新するには、アカウント担当者にお問い合わせください。 ## [](#ワーカーとは)ワーカーとは? リアルタイムサービスまたは API を公開するアプリケーションは 1 つ以上の「ワーカー」上で実行されます。 各ワーカーは、インテグレーションアプリケーションを実行する Mule のインスタンスです。アプリケーションを拡大し、高可用性を提供するためにワーカーを共有または二重化する方法の詳細は、​[「高可用性」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric)​を参照してください。 ## [](#インテグレーションアプリケーションとは)インテグレーションアプリケーションとは? インテグレーションアプリケーションは、2 つ以上のアプリケーションまたはサービスを統合するアプリケーションです。これには、Salesforce データをローカルデータベースに同期するだけの単純なものから、Google Apps、Facebook、および Salesforce を使用してマッシュアップを作成する複雑なものまであります。このアプリケーションは、さまざまな取得元からデータを取得し、そのデータを新しい場所にパブリッシュするか、REST または Web サービスとしてパブリッシュすることで、機能を実行します。従来の 3 層アプリケーションモデルでは、インテグレーションアプリケーションは、アプリケーションデータへの接続性を介してデータ層を表し、このデータを組み合わせて変換し、コンシューマーにルーティングするために使用するロジックを介してサービス層を表します。 ## [](#anypoint-connector-とは)Anypoint Connector とは? Anypoint Connector は、SaaS および Cloud API (Salesforce、Facebook、AWS、PayPal など) を容易に統合し、それらを Mule 内でサービスとして使用するための簡単な方法を提供します。このコネクタを使用すると、Mule を使用して、SaaS とオンプレミスの両方のアプリケーションにわたるオーケストレーションを作成できます。 ## [](#mule-フローとは)Mule フローとは? Mule フローでは、さまざまなアプリケーション間で Mule がメッセージをどのように処理するかを定義します。フローでは、アプリケーション内のイベント、Web サービスや REST サービスへの要求、またはスケジュールされたトリガーによってトリガーされたメッセージに対してアクションを実行する一連のプロセッサーを定義します。 ## [](#使用されている-java-バージョンは)使用されている Java バージョンは? - Mule 4.0.0 以降を使用するワーカーは JDK 8 で動作します。 - Mule 3.8.0 以降を使用するワーカーは JDK 8 で動作します。 - Mule 3.7.0 以降を使用するワーカーは JDK 8 で動作します。 - Mule 3.5.1 以降を使用するワーカーは JDK 7 で動作します。 - Mule 3.5.0 以前を使用するワーカーは JDK 6 で動作します。 ## [](#各ワーカーのストレージ容量は)各ワーカーのストレージ容量は? 各ワーカーのストレージ量は、ワーカーサイズによって異なります。 ワーカーサイズについては、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。 ## [](#環境変数とは)環境変数とは? 環境変数は、Mule アプリケーションに設定を渡すために設定できるプロパティです。たとえば、ユーザー名を ​`${db.username}`​ に設定した JDBC Connector を作成したとします。次に、環境変数内で名前を ​`db.username`​ に設定し、値をアプリケーションの追加または更新時の実際のユーザー名に設定できます。 ## [](#アプリケーションを別のリージョンにデプロイできますか)アプリケーションを別のリージョンにデプロイできますか? はい! [MuleSoft ヘルプセンター](https://help.mulesoft.com)​で、アカウントのグローバルデプロイメントを有効にするためのサポートケースを申請してください。アプリケーションは、米国東部 (オハイオ州北バージニア)、米国西部 (オレゴン州北カリフォルニア)、カナダ、南米 (ブラジル - サンパウロ)、ヨーロッパ (アイルランド、フランクフルト)、UK (ロンドン)、およびアジア太平洋 (シドニー、東京、シンガポール) にデプロイできます。システム管理者は \[Account Settings (アカウント設定)\] の ​**\[Organization (組織)\]**​ タブで​[デフォルトリージョンを設定](https://docs.mulesoft.com/jp/cloudhub/managing-cloudhub-specific-settings)​できますが、そのリージョンを、アプリケーションのデプロイ時に必要に応じて調整できます。 別のリージョンにデプロイされているアプリケーションのドメインは、新しいリージョンを反映するように自動的に更新されます。 ## [](#アプリケーションの起動時にfailed-to-bind-to-uri-uri-へのバインドに失敗しましたが表示される理由は)アプリケーションの起動時に「Failed to bind to uri (URI へのバインドに失敗しました)」が表示される理由は? このようなメッセージが表示されるのは、0.0.0.0 ではなく特定のホストにバインドしようとしているためです。 ```console INFO 11-04-06 20:13:50 [DefaultSystemExceptionStrategy] Failed to bind to uri `+http://foo.cloudhub.io:8081/+` ``` CloudHub ドメイン名ではなく 0.0.0.0 を使用するように HTTP Connector を変更し、再デプロイしてください。 ## [](#アプリケーションの停止方法は)アプリケーションの停止方法は? \[Runtime Manager\] コンソールで、アプリケーションを選択し、左のナビゲーションバーで ​**\[Deployment (デプロイ)\]**​ をクリックします。そして、​**\[Stop application (アプリケーションを停止)\]**​ をクリックします。 ## [](#cloudhub-で実行されている私の-mule-アプリケーションがプラットフォームで再起動されることはありますか)CloudHub で実行されている私の Mule アプリケーションがプラットフォームで再起動されることはありますか? はい。以下のシナリオでは、プラットフォームはアプリケーションを再起動します (アプリケーションが初期状態で停止していた場合を除き、すべての再起動は​[ダウンタイムなし](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#zero-downtime-updates)​で行われます)。 - **基盤となるインフラストラクチャの問題** 基盤となるインフラストラクチャに障害が発生すると、プラットフォームによってアプリケーションが新しいワーカーに移行されます。 - **インフラストラクチャの機能停止** 機能停止または製造中止とマークされたハードウェアで実行中のアプリケーションは、潜在的な機能停止を防止するために、先制的に再起動されて新しいワーカーに移行されます。 - **セキュリティパッチ** セキュリティの脆弱性が特定されると、関連するアプリケーションにパッチが適用されて再起動されます。 [「Critical Security Vulnerabilities (重大なセキュリティ脆弱性)」](https://www.mulesoft.com/legal/versioning-back-support-policy#critical)​ポリシーを参照してください。 - **アプリケーションのクラッシュ** プラットフォームが (カスタムコードや基礎となるスタックの問題による) アプリケーションのクラッシュを認識すると、自動再起動オプションが選択されている場合は、ワーカーを自動的に再起動します。 ## [](#複数のアプリケーションをデプロイできない理由は)複数のアプリケーションをデプロイできない理由は? MuleSoft では無料アカウントを 1 つのワーカーに制限しているため、デプロイできるのは 1 つのアプリケーションのみになります。 [有料サブスクリプション](http://www.mulesoft.com/cloudhub/cloudhub-pricing)​にアップグレードすると、複数のアプリケーションをデプロイしたり、1 つのアプリケーションを複数のワーカーに拡大したりできます。 ## [](#アプリケーションは正常にデプロイされたがmysubdomain-cloudhub-io-に移動するとyou-need-to-change-the-configuration-of-your-docroot-ドキュメントルートの設定を変更する必要がありますと表示されるのは何故ですか)アプリケーションは正常にデプロイされたが、mysubdomain.cloudhub.io に移動すると、「you need to change the configuration of your docroot (ドキュメントルートの設定を変更する必要があります)」と表示されるのは何故ですか? このメッセージが表示された場合、アプリケーションのエンドポイントを異なるパスに表示するように設定している可能性があります。これを mysubdomain.cloudhub.io に表示するには、エンドポイントを再設定してパス変数を削除してください。汎用のエンドポイントを使用している場合、(パスではなく) アドレスを変更してください。 ## [](#http-リードタイムアウトの長さは)HTTP リードタイムアウトの長さは? ロードバランサーは、読み取られたデータがない場合、300 秒後にタイムアウトします。 ## [](#アプリケーションの静的-ip-を取得できますか)アプリケーションの静的 IP を取得できますか? **\[Static IPs (静的 IP)\]**​ アプリケーション設定タブを使用して、静的 IP をアプリケーションに割り当てることができます。詳細は、​[「\[Static IPs (静的 IP)](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub#static-ips-tab-settings) タブの設定」\]​を参照してください。デフォルトでは、サブスクリプション内の本番 vCore の 2 倍の数の静的 IP が割り当てられます。この制限を上げるには、MuleSoft サポートにお問い合わせください。 ## [](#静的-ip-を知る方法は)静的 IP を知る方法は? アプリケーションに割り当てられた静的 IP はアプリケーション設定ページの ​**\[Static IPs (静的 IP)\]**​ タブに表示されます。 ## [](#静的-ip-が割り当てられた後でアプリケーションを変更できますか)静的 IP が割り当てられた後でアプリケーションを変更できますか? はい。アプリケーションを停止して開始し、新しいプロジェクト zip ファイルをアップロードし、アプリケーションの設定を変更して、アプリケーションを再デプロイできます。 ## [](#静的-ip-が変わる可能性がある状況は)静的 IP が変わる可能性がある状況は? 静的 IP が削除または再割り当てされる状況はいくつかあります。 - アプリケーションを削除すると、その静的 IP も削除されます。同じ名前で新しいアプリケーションを作成した場合、動的に割り当てられた新しい IP アドレスが設定されます。 - 新しいアプリケーションを Sandbox から本番環境に移動して追加した場合は、新しいアプリケーション名と新しい静的 IP が必要になります。 - 組織の ​[Anypoint Virtual Private Cloud (Anypoint VPC)](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ が構築されている場合、Anypoint VPC にまだ含まれていない既存のアプリケーションは、Anypoint VPC 内で再起動されたときに新しい IP アドレスを受け取ります。 - アプリケーションは、異なる地理的リージョンに再デプロイされます。 アプリケーション設定ページの ​**\[Static IPs (静的 IP)\]**​ タブで、新しいリージョンの静的 IP を事前に割り当てることができます。 ## [](#特定の静的-ip-アドレスを要求できますか)特定の静的 IP アドレスを要求できますか? いいえ。 CloudHub は、最初のデプロイ時に CloudHub アプリケーションに割り当てられる静的 IP アドレスのプールを使用します。アプリケーションが静的 IP を解放すると、その IP アドレスはプールに戻り、他のアプリケーションで使用できます。 ## [](#cloudhub-vpc-を実行しているが静的-ip-を内部の非公開-ip-に割り当てる方法は)CloudHub VPC を実行しているが、静的 IP を内部の非公開 IP に割り当てる方法は? CloudHub では、ワーカーの公開 IP アドレスを「静的」に設定できます。ただし、内部の非公開 IP アドレスは常に「動的」のままです。非公開 IP アドレスは、​[Anypoint VPC](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ の作成時に決定した CloudHub ワーカーのアドレス空間で指定された範囲から割り当てられます。 ## [](#静的-ip-アドレスに割り当てることができる可能な-ip-範囲は)静的 IP アドレスに割り当てることができる可能な IP 範囲は? CloudHub は Amazon EC2 にデプロイされるため、IP アドレスは Amazon EC2 IP プールから選択されます。この範囲のリストについては、 [Amazon EC2 の公開 IP 範囲](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html)​を参照してください。 ## [](#アプリケーションのタイムゾーンを変更する方法は)アプリケーションのタイムゾーンを変更する方法は? Enterprise アカウントを持つユーザーは、アプリケーションをデプロイするグローバルリージョンを選択できます。実際のワーカーは常に UTC タイムゾーンで実行されます。 ## [](#プロアクティブな監視)プロアクティブな監視 CloudHub プラットフォームは自動化システムによって 24 時間 365 日監視されています。CloudHub インフラストラクチャの健全性に影響する問題が発生した場合は、運用チームに通知されます。運用チームは直ちに対応し、問題を診断して修正します。この 24 時間 365 日の監視は CloudHub プラットフォーム全体を対象とするため、すべての CloudHub ユーザーにメリットがあります。CloudHub サービスの状況および今後のメンテナンスについては、 [`status.mulesoft.com`](http://status.mulesoft.com)​ および [`eu1-status.mulesoft.com`](http://eu1-status.mulesoft.com)​ で確認できます。 ## [](#関連情報)関連情報 - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) - [アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [高可用性](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric) - [キューの管理](https://docs.mulesoft.com/jp/cloudhub/managing-queues) - [スケジュールの管理](https://docs.mulesoft.com/jp/cloudhub/managing-schedules) - [オブジェクトストアを使用したアプリケーションデータの管理](https://docs.mulesoft.com/jp/cloudhub/managing-application-data-with-object-stores) - [Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [アプリケーションプロパティを安全に隠す](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) - [Anypoint Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [侵入テストポリシー](https://docs.mulesoft.com/jp/cloudhub/penetration-testing-policies) # CloudHub Release Notes - [CloudHub Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub/cloudhub-release-notes) - [CloudHub Runtime and OS Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub/cloudhub-runtimes-release-notes) - [CloudHub Dedicated Load Balancer Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub/cloudhub-dedicated-load-balancer-release-notes) - [Anypoint VPN Updates Release Notes](https://docs.mulesoft.com/jp/release-notes/cloudhub/anypoint-vpn-release-notes) # CloudHub Runtime の継続的な更新 CloudHub はサービスとしてのインテグレーションプラットフォーム (iPaaS) であり、オペレーティングシステムと Mule Runtime Engine のパッチ設定を管理するため、アプリケーションの開発と更新に集中できます。 CloudHub によって必要に応じてセキュリティパッチが適用されるため、アプリケーションは保護され、月に 1 回 Mule が更新されてアプリケーションの安定性が保たれます。 パッチ更新では、青/緑デプロイメントを使用し、ダウンタイムをゼロにしています。 CloudHub では、MuleSoft が管理する 3 つのデプロイメントプラットフォームすべてに継続的な更新を適用します。 - US クラウド - EU クラウド - MuleSoft Government Cloud ## [](#セキュリティの更新)セキュリティの更新 MuleSoft では定期的にスキャンを実行し、Mule Runtime Engine、JVM、基礎となるオペレーティングシステムのセキュリティ脆弱性を特定し、次の SLA に基づいて自動的にセキュリティパッチを適用します。
重要度レベル 重要度の定義 パッチの適用期間

P0

Critical (重大)

7 日

P1

高

30 日

## [](#月-1-回の日付パッチ更新)月 1 回の日付パッチ更新 月 1 回、MuleSoft では​_日付パッチ更新_​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。 これらの更新のバージョン番号の形式は次のようになります。 _メジャー_​._マイナー_._パッチ_​ - ​_日付_ パッチ日付が含まれるバージョン番号の例を示します。 `4.2.2 - 05-04-2020` 月 1 回のパッチでは、アプリケーションがパッチバージョンの最新の日付パッチのみに更新されます。 パッチバージョン番号は変更されません。 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 週にリリースされた日付パッチが自動的に適用されます。 本番以外の環境のアプリケーションは週内に更新されます。 本番環境のアプリケーションは週末に更新されます。
All releases occur in GMT-3 time. All automatic updates occur in the local time zone of the app’s deployment region. For example, CloudHub applies updates to apps deployed in the Asia-Pacific (Sydney) region in the AEST time zone and to apps deployed in the US West region in the PST time zone.
自動更新が行われた場合、アプリケーションの監査ログにはユーザー ​`Anypoint Staff`​ によるエントリが含まれ、更新が行われた日時と更新に成功したかどうかが示されます。 更新に成功した場合、アクションは必要ありません。 [\[Zero-Downtime Restart Limitations\]](<#Zero-Downtime Restart Limitations>)​を参照してください。 アプリケーションでダウンタイムなしの更新がサポートされないか、手動での更新が必要な場合、月の第 1 週にリリースされた日付パッチを第 1 週または第 2 週に適用できます。 [\[Update the Runtime Version Manually\]](<#Update the Runtime Version Manually>)​を参照してください。 複数のアプリケーションを更新するには、CloudHub API を使用します。 [\[Update Multiple Apps to the Latest Runtime Release\]](<#Update Multiple Apps to the Latest Runtime Release>)​を参照してください。 ## [](#ライブパッチ)ライブパッチ CloudHub は、OS に最新のセキュリティパッチや重要なバグパッチを適用するため、基盤となる VM でカーネルライブパッチを使用します。毎月のパッチ適用サイクルの間に CloudHub アプリケーションを再起動する必要はありません。

ライブパッチを適用するためには、CloudHub アプリケーションが過去 90 日までのリリースを実行している必要があります。

CloudHub のライブパッチプロセスは、ライブパッチを適用するのに十分なメモリおよび CPU リソースがあるかどうかを確認します。十分な容量がない場合には、パッチはスキップされて後で再試行されます。

### [](#アプリケーションにライブパッチが適用されているかどうかの確認)アプリケーションにライブパッチが適用されているかどうかの確認 [アプリケーションのログ](https://docs.mulesoft.com/jp/cloudhub/viewing-log-data#view-logs)​を確認することで、ライブパッチが適用されたかどうかを判断できます。 ![アプリケーションのライブパッチログ](/mulesoft/current/ja-jp/cloudhub/_images/live-patching-log.png) ## [](#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 での 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

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

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)CloudHub 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 では、以下が必要です。 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. ## [](#手動でのランタイムバージョンの更新)手動でのランタイムバージョンの更新 **\[Update Available (更新が使用可能)\]**​ 列では、ランタイムバージョンの更新が必要なアプリケーションが示されます。 都合に合わせて更新の予定を立ててください。 本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。 ### [](#1-つのアプリケーションの最新のランタイムリリースへの更新)1 つのアプリケーションの最新のランタイムリリースへの更新 アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。 1. Runtime Manager のナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. 更新するアプリケーションの名前をクリックし、詳細ペインを表示します。 3. アプリケーションの ​**\[Settings (設定)\]**​ ページにアクセスします。 4. **\[Runtime (ランタイム)\]**​ タブをクリックします。 アプリケーションで更新が必要な場合、​**\[Update available (更新が使用可能)\]**​ が ​**\[Runtime version (ランタイムバージョン)\]**​ メニューに表示されます。 ![アプリケーションの \[Settings (設定)\] ページの \[Update available (更新が使用可能)\] と \[Runtime version (ランタイムバージョン)\] メニュー](_images/cloudhub-app-update-available-setting.png) 5. **\[Runtime version (ランタイムバージョン)\]**​ ドロップダウンメニューから最新バージョンを選択します。 6. バージョンの詳細を確認するには、​**\[Read release notes (リリースノートを読む)\]**​ リンクをクリックします。 7. **\[Apply Changes (変更を適用)\]**​ ボタンをクリックしてアプリケーションを更新します。 CloudHub により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。 アプリケーションの更新に失敗した場合、アプリケーションは ​**\[Update Available (更新が使用可能)\]**​ タブに表示されたままになります。 この場合、アプリケーションは引き続き以前のランタイムバージョンで正常に実行されたままになり、アクションは必要ありません。 Edge リリースチャネルを選択すると、次の自動更新の日付を示すバナーが表示されます。 ![Edge リリースチャネルの自動更新の日付を示すバナー。](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-app-edge-auto-update.png) ### [](#複数のアプリケーションの最新のランタイムリリースへの更新)複数のアプリケーションの最新のランタイムリリースへの更新 Runtime Manager UI では複数のアプリケーションの最新のランタイムバージョンへの更新はサポートされていませんが、CloudHub API を使用して一括更新を実行することはできます。 [「How to Perform a Bulk CloudHub Application Update to the Latest Runtime Releases (CloudHub アプリケーションの最新のランタイムリリースへの一括更新の実行方法)」](https://help.mulesoft.com/s/article/How-to-Perform-a-Bulk-CloudHub-Application-Update-to-the-Latest-Runtime-Releases)​を参照してください。
Bulk Update API を使用して更新されたアプリケーションは、低い優先度で処理され、更新にかかる時間が若干長くなることがあります。
## [](#通知の更新)通知の更新 最新のランタイムバージョンが使用できる場合: - **\[Applications (アプリケーション)\]**​ ページには、アプリケーションの使用可能な更新があるかどうかを示す ​**\[Update Available (更新が使用可能)\]**​ 列が表示されます。 ![バナーと \[Update Available (更新が使用可能)\] タブが表示された \[Applications (アプリケーション)\] ページ](_images/cloudhub-app-update-req-page.png) - ​**\[Update available (更新が使用可能)\]**​ と新しい使用可能な更新がアプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Runtime version (ランタイムバージョン)\]**​ タブに表示されます。 ![「Runtime version (ランタイムバージョン)」 メニューのランタイム更新バージョンと 「Update available (更新が使用可能)\]。](_images/cloudhub-app-update-versions.png) MuleSoft によって、パブリッシュされたスケジュールに基づいて更新が自動的に適用されます。 必要があれば、都合に合わせて手動で更新できます。 ## [](#ダウンタイムなしの再起動の制限)ダウンタイムなしの再起動の制限 ダウンタイムなしの再起動は、次の場合には機能しません。 - CloudHub アプリケーションが永続的なサブスクライバーである。 この場合、一度にアクティブにできるのは 1 つの一意のサブスクライバーのみです。 これらのアプリケーションの場合、最新の更新を適用するにはアプリケーションを手動で停止して開始する必要があります。 - CloudHub アプリケーションが接続している外部連動関係が使用できないか、応答しないか、ウォームアップが必要である。 この場合、CloudHub はアプリケーションドメインおよび関連する静的 IP アドレス (使用する場合) を新しいバージョンのアプリケーションに割り当てる前に、アプリケーションが連動関係に接続するのを最大 3 分待機します。 いずれかの場合がアプリケーションに当てはまる場合、サポートおよび CSM アカウント担当者にアプリケーションのクラウド対応への更新に関する情報を問い合わせてください。 ## [](#更新後のアプリケーション状況の確認)更新後のアプリケーション状況の確認 新しい更新が行われた後で、Runtime Manager の ​**\[Applications (アプリケーション)\]**​ タブの ​**\[Status (状況)\]**​ 列で​[アプリケーション状況の状態](#managing-deployed-applications.adoc#application_status_states)​を確認できます。 また、アプリケーションログをチェックして、アプリケーションが正しくデプロイされたかどうかを確認し、一部の自動マイナー更新関連の問題が発生した場合に修正アクションを実行することもできます。詳細は、​[「ログを表示する」](https://docs.mulesoft.com/jp/cloudhub/viewing-log-data#view-logs)​を参照してください。 自動更新後にエラーが発生した場合にメールで通知を受け取るには、​[アラートを作成](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager#create-an-alert)​します。 ## [](#自動更新の失敗)自動更新の失敗 青/緑デプロイメントで新しいワーカーへの自動更新のデプロイが失敗すると、アプリケーションは、現在実行中のワーカーでは最新でないパッチバージョンの実行を続行します。 考えられる失敗の原因の一部は次のとおりです。 - デプロイ後に Anypoint Runtime Manager UI からアプリケーションプロパティの 1 つを削除した。 - カスタムモジュールと最新パッチバージョンのリリースの間に互換性がない。 毎月のパッチサイクルを 2 回繰り返してもアプリケーションが自動更新されない場合は、アプリケーションが停止されて、最新のパッチバージョンに強制更新されます。更新後にアプリケーションが起動に失敗する場合は、手動でのパッチ対応が必要になります。 ## [](#関連情報)関連情報 - [Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence). - [CloudHub API Portal](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/) - [CloudHub API Portal](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/) - [ダウンタイムなしの更新](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#zero-downtime-updates) - [リージョンサービス](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide#regional-services) # CloudHub アーキテクチャ [CloudHub](https://docs.mulesoft.com/jp/cloudhub/)​ の目的は、マルチテナントのセキュアで拡張性と可用性の高いサービスとしてインテグレーションプラットフォーム (iPaaS) を企業に提供することです。CloudHub を最大限に活用するには、これらの目標を達成するために CloudHub プラットフォームの基盤となるメカニズムのしくみを理解する方法を理解する必要があります。 CloudHub は、Anypoint Platform の Anypoint Runtime Manager コンソールで管理します。Anypoint Studio、​[CloudHub REST API](https://docs.mulesoft.com/jp/cloudhub/cloudhub-api)​ または ​[Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/)​から​[デプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​することもできます。

オンプレミスや Anypoint Platform Private Cloud Edition (Anypoint PCE) などのさまざまなデプロイメントシナリオについての詳細は、​「デプロイメントオプション」​を参照してください。

セキュリティや可用性に対する CloudHub のアプローチを理解するには、CloudHub の背後にあるアーキテクチャを理解することが重要です。 CloudHub には、2 つの主要なコンポーネント (Anypoint プラットフォームサービスとワーカークラウド) があります。これらの 2 つのコンポーネントと、それらのコンポーネントへのアクセスに使用する Runtime Manager コンソールは、連携してインテグレーションアプリケーションを実行します。 ![architecture diagram](/mulesoft/current/ja-jp/cloudhub/_images/architecture-diagram.png)

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

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

2 Runtime Manager

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

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

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

4 CloudHub 2.0

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

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

0.1 vCore

1 GB

500 MB

8 GB

0.2 vCore

2 GB

1 GB

8 GB

1 vCore

4 GB

2 GB

12 GB

2 vCore

8 GB

4 GB

40 GB

4 vCore

16 GB

8 GB

88 GB

8 vCore

32 GB

16 GB

168 GB

16 vCore

64 GB

32 GB

328 GB

0.1 vCore および 0.2 vCore のワーカー: - 小さいワークロードのアプリケーションで CPU と I/O が制限される - 短期間、より高い CPU 速度に上げることができる この機能は、アプリケーションの起動時間の向上に役立つほか、まれに発生する大きなワークロードの処理に役立ちます。 一貫したパフォーマンスが必要な場合は、vCore の多いワーカーを使用してください。 1 以上の vCore のワーカー: - パフォーマンスが一貫している - Mule バージョン 3.6.2 以降または API ゲートウェイバージョン 2.0.2 以降でのみ使用できる 各ワーカーには、システムとアプリケーションの両方のストレージで使用する 8 GB 以上のストレージが割り当てられており、約 3.0 GB が OS と Mule コンポーネントで使用されます。アプリケーションでより多くのストレージが必要な場合 (冗長ログなど) は、2 以上の vCore のワーカーを使用して、アプリケーションが追加のストレージにアクセスできるようにしてください。 実行中のアプリケーションのみがワーカーの使用量に含まれます。 アプリケーションで、使用可能な量より多くの vCore を必要とする場合、CloudHub ではアプリケーションを作成することはできますが、追加の vCore が使用可能になるまでアプリケーションを開始できません。 vCore の割り当てを増やすには、別のアプリケーションを停止するか、アカウントマネージャーに連絡してサブスクリプションの vCore の割り当てを増やすよう依頼してください。 CloudHub にデプロイされたアプリケーションのメタ領域のサイズは、ワーカーサイズに関係なく現在のところ無制限となっています。 メタ領域の初期サイズは 128 MB で、メタ領域がこのしきい値に達すると、メタ領域のガベージコレクションが開始されます。 複数のワーカーを追加して永続的なキューでワーカー間にワークロードを分散できるようにすることで、アプリケーションを水平方向にスケールできます。 [「ワーカーのスケールアウト」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric#worker-scale-out)​と​[「永続的なキュー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric#persistent-queues)​を参照してください。 CloudHub は、ワーカーを監視して正常に動作していることを確認します。 自動再起動を有効にした場合、CloudHub は必要に応じてアプリケーションの再起動も行います。 ## [](#グローバルワーカークラウド)グローバルワーカークラウド CloudHub は、世界のさまざまなリージョン (北米、南米、欧州、アジア太平洋) でワーカークラウドを提供しています。 サポートされているリージョンの完全なリストについては、​[「リージョンサービス」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide#regional-services)​を参照してください。 このグローバルな分散により、各自のサービスに最も近い場所でインテグレーションをホストできるため、レイテンシーが減少します。 また、EU データ保護指令などの地域の法律に準拠することもできます。 US コントロールプレーンと US-Gov コントロールプレーンの場合、MuleSoft では米国で管理コンソールとプラットフォームサービスをホストします。 EU コントロールプレーンの場合、MuleSoft ではこれらのサービスをヨーロッパでホストします。 アプリケーションをデプロイするリージョンによって、アプリケーションについて指定されるドメインが決まります。 たとえば、​`myapp`​ という名前のアプリケーションをカナダ (中央部) にデプロイする場合、アプリケーションにアクセスするために使用されるドメインは ​`myapp.ca-c1.cloudhub.io`​ になります。要求のルーティングに使用されるロードバランサーは、アプリケーションと同じリージョンに存在します。 別のリージョンへのアプリケーションのデプロイについての詳細は、​[「CloudHub へのデプロイ」](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​を参照してください。 CloudHub のセキュリティおよびコンプライアンスについての詳細は、 [「Anypoint Cloud Security & Compliance (Anypoint クラウドセキュリティおよびコンプライアンス)」ホワイトペーパー](https://www.mulesoft.com/lp/whitepaper/saas/cloud-security)​をダウンロードしてください。 ## [](#ワーカーとマルチテナンシー)ワーカーとマルチテナンシー サービスに応じてさまざまなレベルのセキュリティと分離が必要になるため、プラットフォームでは 2 つの異なるレベルのマルチテナンシーが提供されます。 - 第 1 に、ワーカークラウドは、仮想マシンのマルチテナントクラウドです。これらの VM は、他に影響を与えずにインテグレーションでカスタムコードを実行するために必要なセキュリティと分離を提供します。 - 第 2 に、管理コンソールとプラットフォームサービスは、すべてのテナントで同じ Web UI、監視サービス、ロードバランサーなどを共有する「すべてを共有する」アーキテクチャで構成されています。 これらのサービスは、データの処理や転送を行いません。 ## [](#可用性と拡張性)可用性と拡張性 CloudHub は、冗長性、インテリジェントな回復、ダウンタイムなしの更新などにより、可用性と拡張性が高くなるように設計されています。また、​[高可用性機能](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric)​によってスケーリングと信頼性の向上を実現できます。 ### [](#冗長性のあるプラットフォーム)冗長性のあるプラットフォーム CloudHub のすべてのプラットフォームサービス (負荷分散や API レイヤーなど) には 1 つ以上の冗長性レイヤーが組み込まれており、常に 2 つ以上のデータセンターで使用できます。どのデータセンターも 60 マイル以上離れています。この冗長性により、1 つのデータセンターが停止しても、プラットフォームを引き続き使用できます。 ### [](#インテリジェントな回復)インテリジェントな回復 CloudHub は、ワーカークラウドの問題を監視し、問題から回復する自己回復メカニズムを提供します。基盤となるハードウェアに障害が発生すると、プラットフォームによって自動的にアプリケーションが新しいワーカーに移行されます。アプリケーションがクラッシュすると、カスタムコードの問題が原因でも、基盤となるスタックのバッグが原因でも、プラットフォームでクラッシュを認識し、​[自動的にワーカーを再起動](https://docs.mulesoft.com/jp/cloudhub/worker-monitoring#enabling-automatic-restarts)​できます。 アプリケーションの監視と自動再起動についての詳細は、​[「アプリケーション監視と自動再起動」](https://docs.mulesoft.com/jp/cloudhub/worker-monitoring)​を参照してください。 ### [](#ダウンタイムなしの更新)ダウンタイムなしの更新 CloudHub では、アプリケーションを実行時に更新できるため、HTTP API のエンドユーザーのダウンタイムはありません。CloudHub は、アプリケーションの更新をデプロイしている間も古いバージョンのアプリケーションを引き続き実行します。ドメインは、新しくアップロードされたバージョンが完全に開始されるまで古いバージョンのアプリケーションを参照します。これにより、新しいバージョンのアプリケーションを開始している間も古いアプリケーションからの要求を引き続き処理できます。 ### [](#高可用性)高可用性 高可用性機能を使用すると、CloudHub のアプリケーションで拡張性、ワークロードの分散、信頼性の向上を実現できます。これらの機能は、拡張性の高い負荷分散サービス、​[ワーカーのスケールアウト](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric#worker-scaleout)​、​[永続的なキュー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric#persistent-queues)​機能によって提供されます。 #### [](#ワーカーのスケールアウトとデータセンターの冗長性)ワーカーのスケールアウトとデータセンターの冗長性 [高可用性機能](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric)​を使用すると、複数のワーカーをアプリケーションに追加して、水平方向にスケールできます。CloudHub は、自動的に同じアプリケーションで複数のワーカーを 2 つ以上のデータセンターで分散し、最大限の信頼性を確保します。 アプリケーションを 2 つ以上のワーカーにデプロイすると、HTTP 負荷分散サービスはこれらのワーカーで要求を分散します。これにより、サービスを水平方向にスケールできます。要求は、ラウンドロビンベースで分散されます。 #### [](#永続的なキュー)永続的なキュー 永続的なキューにより、メッセージの損失がなくなり、HTTP 以外のワークロードを一連のワーカーで分散できます。たとえば、アプリケーションを複数のワーカーにデプロイする場合、永続的なキューを使用すると、ワーカー間の通信とワークロードの分散を実現できます。大きなファイルがキューに配置された場合、ワーカーはこれを分割して並列で処理できます。 また、永続的なキューでは、1 つ以上のワーカーまたはデータセンターがダウンしても、メッセージが確実に配信されます。永続的なキューにより、障害回復が促進され、ハードウェアまたはアプリケーションの障害に対する回復力を得られます。 ワーカーのスケールアウトと永続的なキューの詳細は、​[「高可用性」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric)​を参照してください。 ## [](#セキュリティ)セキュリティ CloudHub アーキテクチャは、インテグレーションのセキュアなプラットフォームを提供します。 ペイロードデータの保護は、非常に重要です。この目的を達成するために、CloudHub は、ペイロードデータの検査や保存、または直接のやりとりを行いません。CloudHub ワーカーは、各アプリケーションに独自の仮想マシンを提供することで、データの転送および処理に対応するセキュアな機能を提供します。これにより、ペイロードのセキュリティを確保するためのテナント間の完全な分離と、他のテナントのコードからの隔離が実現します。 CloudHub は、CloudHub ワーカーから監視データ、分析データ、ログデータを収集したり、ユーザーの代わりに CloudHub ワーカーでアクションを実行したりできます。CloudHub プラットフォームサービスとワーカークラウド間のすべての通信は、SSL とクライアント証明書認証を使用して保護されます。これにより、認証されていないパーティはデータを読み取ることができず、不正なアクションを開始できません。 [セキュアなプロパティ](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties)​をアプリケーションバンドルの一部として読み込むこともできます。プロパティにセキュアフラグが設定されている場合、Runtime Manager コンソールでも表示できなくなります。実際には、アプリケーションを実行している CloudHub ワーカー以外の場所に伝播されなくなります。 セキュリティに関する MuleSoft のアプローチについての詳細は、 [「Anypoint Cloud Security & Compliance whitepaper (Anypoint クラウドセキュリティおよびコンプライアンス)」ホワイトペーパー](http://mulesoft.com/downloads/whitepapers/security-whitepaper.pdf)​を参照してください。 ## [](#関連情報)関連情報 - [CloudHub ネットワークガイド](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide) - [CloudHub FAQ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-faq) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [メンテナンスおよびアップグレードポリシー](https://docs.mulesoft.com/jp/cloudhub/maintenance-and-upgrade-policy) - [status.mulesoft.com](http://status.mulesoft.com/) - [eu1-status.mulesoft.com](http://eu1-status.mulesoft.com/) - [高可用性](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric) - [アプリケーション監視と自動再起動](https://docs.mulesoft.com/jp/cloudhub/worker-monitoring) - [Amazon EC2 インスタンス種別](https://aws.amazon.com/ec2/instance-types/) # CloudHub コマンドラインインターフェース Anypoint Platform には、CloudHub のスクリプトおよびコマンドラインツールが用意されています。 コマンドラインインターフェース (CLI) は、対話型シェルと標準 CLI モードの両方をサポートしており、以下で動作します。 - [CloudHub アプリケーション](#cloudhub-apps) - [CloudHub 専用ロードバランサー](#cloudhub-dlb) - [CloudHub Anypoint VPC](#cloudhub-vpc) ## [](#cloudhub-apps)CloudHub アプリケーション
コマンド 説明

環境内のすべてのアラートをリストする

アラームの履歴の情報を表示する

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

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

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

アプリケーションを開始する

実行中のアプリケーションを再起動する

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

新しいアプリケーションをデプロイする

既存のアプリケーションを変更する (必要に応じて ZIP ファイルを更新する)

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

アプリケーションログの末尾を表示する

CloudHub アプリケーションをコピーする

### [](#runtime-mgr-cloudhub-alert-list)runtime-mgr:cloudhub-alert:list \> runtime-mgr:cloudhub-alert:list \[flags\] このコマンドでは、現在の環境に関連付けられているすべてのアラートをリストします。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#runtime-mgr-cloudhub-alert-history-describe)runtime-mgr:cloudhub-alert-history:describe \> runtime-mgr:cloudhub-alert-history:describe \[flags\] このコマンドは、​``​ で渡されるアラームの履歴の情報を表示します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#runtime-mgr-cloudhub-application-list)runtime-mgr:cloudhub-application:list \> runtime-mgr:cloudhub-application:list \[flags\] このコマンドは、Anypoint Platform CLI で使用できるすべてのアプリケーションをリストします。アプリケーション、その状況、割り当てられている vCore の数、最終更新時間を返します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#runtime-mgr-cloudhub-application-describe)runtime-mgr:cloudhub-application:describe \> runtime-mgr:cloudhub-application:describe \[flags\] このコマンドは、​``​ で渡すアプリケーションに関する情報を表示します。 フラグ ​`-o json`​ を使用して、​``​ で指定するアプリケーションの未加工の JSON 応答を取得します。 アプリケーションのドメイン、その状況、最終更新時間、Mule バージョン、ZIP ファイル名、リージョン、監視、ワーカー、および永続的なキューや静的 IP の有効化に関する ​`TRUE`​ または ​`FALSE`​ 情報などのデータを返します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#runtime-mgr-cloudhub-application-stop)runtime-mgr:cloudhub-application:stop \> runtime-mgr:cloudhub-application:stop \[flags\] このコマンドは、​``​ で指定する実行中のアプリケーションを停止します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#runtime-mgr-cloudhub-application-start)runtime-mgr:cloudhub-application:start \> runtime-mgr:cloudhub-application:start \[flags\] このコマンドは、​``​ で指定する実行中のアプリケーションを開始します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#runtime-mgr-cloudhub-application-restart)runtime-mgr:cloudhub-application:restart \> runtime-mgr:cloudhub-application:restart \[flags\] このコマンドは、​``​ で指定する実行中のアプリケーションを再起動します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#runtime-mgr-cloudhub-application-delete)runtime-mgr:cloudhub-application:delete \> runtime-mgr:cloudhub-application:delete \[flags\] このコマンドは、​``​ で指定する実行中のアプリケーションを削除します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#deploy-to-cloudhub)runtime-mgr:cloudhub-application:deploy \> runtime-mgr:cloudhub-application:deploy \[flags\] このコマンドは、​``​ で設定する名前を使用して、​``​ で指定する Mule のデプロイ可能なアーカイブ ZIP ファイルをデプロイします。 ローカルハードドライブのデプロイ可能な ZIP ファイルの絶対パスまたは相対パスを指定する必要があります。また、アプリケーションには一意の名前を付ける必要があります。
成功すると、このコマンドの出力に ​UNDEPLOYED​ のデプロイメントの状況が含まれます。これは、CloudHub でアプリケーションが正常にアップロードされたことを示します。
このコマンドで使用できるフラグは、次のとおりです。
フラグ 説明

--runtime

ランタイム環境の名前とバージョン。
このフラグを使用して、デプロイするランタイムの名前とバージョンを指定します。
この値の例として、​2.1.1-API-Gateway​、​3.9.1-visualizer​、​4.1.1​ などが挙げられます。
(この値は、デフォルトでは最新の CloudHub Runtime バージョンとなります。)

--workers

ワーカーの数。(このデフォルト値は「1」)。

--workerSize

vCore のワーカーのサイズ。(このデフォルト値は「1」)。

--region

デプロイ先のリージョンの名前。
サポートされているすべてのリージョンのリストを取得するには、​cloudhub:region:list​ コマンドを使用します。

--property

プロパティ (​name:value​) を設定する。
設定するプロパティは引用符で囲み、文字 ​:​ および ​=​ はエスケープする必要があります。
(例: --property "salesforce.password:qa\=34534"​)。

文字 ​:​ は、プロパティの名前に使用できません。

--propertiesFile

このファイルの値ですべてのプロパティを上書きする。ファイル形式は、1 行以上の ​name:value​ 形式です。ローカルハードドライブのプロパティファイルの絶対パスを設定します。

--[no-]persistentQueues

永続的なキューを有効または無効にする (このデフォルト値は ​disabled​)。

--[no-]persistentQueuesEncrypted

永続的なキューの暗号化を有効または無効にする (このデフォルト値は ​disabled​)。

--[no-]staticIPsEnabled

静的 IP を有効または無効にする。このデフォルト値は ​disabled​。

--[no-]objectStoreV1

Object Store V1 を有効または無効にする。
objectStoreV1​ フラグを使用する場合、​objectStoreV2​ も指定することはできません。

--[no-]objectStoreV2

Object Store V2 を有効または無効にする。
objectStoreV2​ フラグを使用する場合、​objectStoreV1​ も指定することはできません。

--[no-]autoRestart

応答しない場合にアプリケーションを自動的に再起動する。このデフォルト値は ​enabled​。

--output

応答形式を指定する。サポートされている値は、​table​ (デフォルト) および ​json​ です。

--help

使用量情報を出力する

--timeout

タイムアウト値をミリ秒単位で設定します。​60000​ ~ ​300000​ の値を設定できます。

Anypoint Platform CLI から静的 IP を割り当てることはできません。有効化または無効化のみが可能です。

フラグを使用せずにデプロイする場合、アプリケーションはすべてのデフォルト値を使用してデプロイされます。

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を参照してください。

このコマンドには複数オプションのフラグがあります。コマンドで複数オプションのフラグを使用する場合は、フラグの前にパラメーターを置くか、パラメーターの前に ​`-- `​ (2 つのダッシュの後にスペース) を使用します。
### [](#runtime-mgr-cloudhub-application-modify)runtime-mgr:cloudhub-application:modify \> runtime-mgr:cloudhub-application:modify \[zipfile\] \[flags\] このコマンドは、既存のアプリケーションの設定を更新します。必要に応じて、新しい ZIP ファイルをアップロードして更新できます。 このコマンドでは、​`deploy`​ コマンドとまったく同じフラグを使用できます。
このコマンドの出力には、​Status​ (アプリケーションの以前のデプロイメントの状況の状態) が含まれます。
このコマンドには複数オプションのフラグがあります。コマンドで複数オプションのフラグを使用する場合は、フラグの前にパラメーターを置くか、パラメーターの前に ​`-- `​ (2 つのダッシュの後にスペース) を使用します。
### [](#runtime-mgr-cloudhub-application-download-logs)runtime-mgr:cloudhub-application:download-logs \> runtime-mgr:cloudhub-application:download-logs \[flags\] このコマンドは、​``​ で指定されるアプリケーションのログを指定のディレクトリにダウンロードします。 UI とは異なり、CLI からダウンロードするログでは、システムログとワーカーログが分離されません。 ### [](#runtime-mgr-cloudhub-application-tail-logs)runtime-mgr:cloudhub-application:tail-logs \> runtime-mgr:cloudhub-application:tail-logs \[flags\] このコマンドは、アプリケーションログの末尾を表示します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#runtime-mgr-cloudhub-application-copy)runtime-mgr:cloudhub-application:copy \> runtime-mgr:cloudhub-application:copy \[flags\] このコマンドは、​`source`​ で渡される CloudHub アプリケーションを ​`target`​ で渡される対象にコピーします。 引数 ​`source`​ および ​`target`​ は、​`([group_id]/)/`​ の形式にする必要があります。 `group_id`​ が指定されていない場合、現在選択されている組織 ID がデフォルトに設定されます。 次に例を示します。 \> runtime-mgr:cloudhub-application:copy Services:QA/application-1 Development:QA/application-2 `application-1`​ という名前のアプリケーションをサービス組織の QA 環境から開発組織の QA 環境にコピーします。 Anypoint Platform CLI でサービス組織の QA 環境を使用する場合、コマンドの ​`source`​ としてアプリケーション名を使用できます。 \> runtime-mgr:cloudhub-application:copy application-1 Development/QA/application-2
このコマンドを実行するには、ユーザーに OS の ​/tmp​ ディレクトリ (CLI のインストール先) への参照/更新アクセス権が必要です。
このコマンドでは、デフォルトの ​`--help`​ および ​`-f`​/​`--fields`​ フラグ以外に次のフラグも使用できます。
フラグ 説明

--property

プロパティ (​name:value​) を設定する。

プロパティは引用符で囲み、​:​ 文字と ​=​ 文字はエスケープします。例:

--property "salesforce.password:qa\=34534"

このコマンドには複数オプションのフラグがあります。コマンドで複数オプションのフラグを使用する場合は、フラグの前にパラメーターを置くか、パラメーターの前に ​`-- `​ (2 つのダッシュの後にスペース) を使用します。
安全な隠しアプリケーションプロパティが含まれるアプリケーションをコピーする場合は、​--property​ フラグを使用して ​copy​ コマンドのプロパティを渡します。 安全な隠しアプリケーションプロパティについては、​「アプリケーションプロパティを安全に隠す」​を参照してください。
## [](#cloudhub-dlb)CloudHub 専用ロードバランサー
コマンド 説明

組織内のすべてのロードバランサーをリストする

ロードバランサーの詳細を表示する

ロードバランサーを作成する

ロードバランサーを開始する

ロードバランサーを停止する

ロードバランサーを削除する

証明書を既存のロードバランサーに追加する

ロードバランサーから証明書を削除する

ロードバランサーが提供するデフォルトの証明書を設定する

特定の証明書のロードバランサー設定を表示する

IP または IP の範囲をロードバランサーの許可リストに追加する

IP または IP の範囲をロードバランサーの許可リストから削除する

ロードバランサーのプロキシマッピングルールをリストする。​certificateName​ が指定されていない場合、デフォルトの SSL エンドポイントのマッピングが表示されます。

指定されたインデックスでプロキシマッピングルールを追加する。​certificateName​ が指定されていない場合、デフォルトの SSL エンドポイントのマッピングが表示されます。

プロキシマッピングルールを削除する。​certificateName​ が指定されていない場合、デフォルトの SSL エンドポイントのマッピングが表示されます。

動的 IP を有効にする

動的 IP を無効にする

サポートされているすべてのリージョンをリストする

使用可能なすべてのランタイムをリストする

### [](#cloudhub-load-balancer-list)cloudhub:load-balancer:list \> cloudhub:load-balancer:list \[flags\] このコマンドは、Anypoint Platform のすべてのロードバランサーをリストします。ロードバランサーの名前、ドメイン、その状態、およびロードバランサーがバインドされている Anypoint VPC ID を表示します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#cloudhub-load-balancer-describe)cloudhub:load-balancer:describe \> cloudhub:load-balancer:describe \[flags\] このコマンドは、​``​ で指定されるロードバランサーに関する情報を表示します。 フラグ ​`-o json`​ を使用して、​``​ で指定するアプリケーションの未加工の JSON 応答を取得します。 ロードバランサーの名前、ドメイン、その状態、およびロードバランサーがバインドされている Anypoint VPC ID を表示します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#cloudhub-load-balancer-create)cloudhub:load-balancer:create \> cloudhub:load-balancer:create \[flags\] このコマンドは、環境変数で指定される値を使用してロードバランサーを作成します。
値 説明 例

vpc

このロードバランサーがバインドされる Anypoint VPC の名前。
Anypoint VPC 名にスペースが含まれている場合、「"」文字で囲んで渡す必要があります。

vpc-demo

name

ロードバランサーの名前。

newtestloadbalancer

certificate

ローカルハードドライブのサーバー証明書の ​.pem​ ファイルへの絶対パス。
証明書ファイルは、暗号化せずに PEM でエンコードする必要があります。

/Users/mule/Documents/cert.pem

privateKey

ローカルハードドライブのサーバー証明書の非公開キーの ​.pem​ ファイルへの絶対パス。
非公開キーファイルは、パスフレーズレスである必要があります。

/Users/mule/Documents/privateKey.pem

<name>​ で渡すロードバランサーの名前は一意である必要があります。
デフォルトでは、ロードバランサーは HTTPS で外部要求をリスンし、HTTP で内部的にワーカーと通知します。
HTTPS でリスンするように Anypoint VPC 内の Mule アプリケーションを設定している場合、​load-balancer mappings add​ コマンドを使用してマッピングリストを作成するときに ​upstreamProtocol​ が HTTPS に設定されていることを確認してください。

このコマンドでは、デフォルトの ​`--help`​ フラグ以外に次のフラグも受け入れます。
フラグ 説明

--http

ロードバランサーの HTTP 動作を指定する。これは ​on​ (HTTP 要求を受け入れて、設定したデフォルトの ​sslendpoint​ に転送する)、​off​ (すべての HTTP 要求を拒否する)、または ​--redirect​ (HTTPS にリダイレクトする) に設定できます。

--clientCertificate

クライアント証明書ファイル

--verificationMode

クライアント検証モードを指定する。​on​ (常に検証)、​off​ (検証しない)、または ​optional​ (検証は省略可能) に設定できます。

--crl

証明書失効リストファイル

--[no-]tlsv1

TLSv1、TLSv1.1、TLSv1.2 をサポートする

--[no-]dynamic-ips

再起動後は保持されない動的 IP を使用する。

CloudHub は、オンライン証明書状況プロトコル (OCSP) を実装しません。証明書失効リストを最新の状態に保つには、 CloudHub API​ を使用してプログラムで証明書を更新することをお勧めします。
設定に関する詳細は、​[「SSL エンドポイントと証明書の設定」](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints)​を参照してください。 ### [](#cloudhub-load-balancer-start)cloudhub:load-balancer:start \> cloudhub:load-balancer:start \[flags\] このコマンドは、​``​ で指定されるロードバランサーを開始します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-stop)cloudhub:load-balancer:stop \> cloudhub:load-balancer:stop \[flags\] このコマンドは、​``​ で指定されるロードバランサーを停止します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-delete)cloudhub:load-balancer:delete \> cloudhub:load-balancer:delete \[flags\] このコマンドは、​``​ で指定されるロードバランサーを削除します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-ssl-endpoint-add)cloudhub:load-balancer:ssl-endpoint:add \> cloudhub:load-balancer:ssl-endpoint:add \[flags\] このコマンドは、渡される証明書と非公開キーを使用して、SSL エンドポイントを ​``​ で指定されるロードバランサーに追加します。
値 説明 例

name

ロードバランサーの名前。

newtestloadbalancer

certificate

ローカルハードドライブの証明書の ​.pem​ ファイルへの絶対パス。
証明書ファイルは、暗号化せずに PEM でエンコードする必要があります。

/Users/mule/Documents/cert.pem

privateKey

ローカルハードドライブの非公開キーの ​.pem​ ファイルへの絶対パス。
非公開キーファイルは、パスフレーズレスである必要があります。

/Users/mule/Documents/privateKey.pem

CloudHub は、オンライン証明書状況プロトコル (OCSP) を実装しません。証明書失効リストを最新の状態に保つには、 CloudHub API​ を使用してプログラムで証明書を更新することをお勧めします。
このコマンドでは、デフォルトの ​`--help`​ フラグ以外に次のフラグも受け入れます。
フラグ 説明

--clientCertificate

クライアント証明書ファイル

--verificationMode

クライアント検証モードを指定する。​on​ (常に検証)、​off​ (検証しない)、または ​optional​ (検証は省略可能) に設定できます。

--crl

証明書失効リストファイル

--tlsv1

TLSv1、TLSv1.1、TLSv1.2 をサポートする

設定に関する詳細は、​[「SSL エンドポイントと証明書の設定」](https://docs.mulesoft.com/cloudhub/lb-ssl-endpoints)​を参照してください。 ### [](#cloudhub-load-balancer-ssl-endpoint-remove)cloudhub:load-balancer:ssl-endpoint:remove \> cloudhub:load-balancer:ssl-endpoint:remove \[flags\] このコマンドは、​``​ で指定されるロードバランサーから ​``​ で指定される SSL 証明書を削除します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-ssl-endpoint-set-default)cloudhub:load-balancer:ssl-endpoint:set-default \> cloudhub:load-balancer:ssl-endpoint:set-default \[flags\] このコマンドは、​``​ で渡されるロードバランサーのデフォルトの証明書として ​``​ で指定される証明書を設定します。 このコマンドでは、デフォルトの ​`--help`​ フラグ以外に次のフラグも受け入れます。
フラグ 説明

--http

ロードバランサーの HTTP 動作を指定する

### [](#cloudhub-load-balancer-ssl-endpoint-describe)cloudhub:load-balancer:ssl-endpoint:describe \> cloudhub:load-balancer:ssl-endpoint:set-describe \[flags\] このコマンドは、​``​ で指定される証明書の ​``​ で渡されるロードバランサーの設定に関する情報を表示します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#cloudhub-load-balancer-allowlist-add)cloudhub:load-balancer:allowlist:add \> cloudhub:load-balancer:allowlist:add \[flags\] このコマンドでは、​``​ で指定される IP アドレスの範囲を ​``​ で指定されるロードバランサーの許可リストに追加します。
許可リストは、CN 証明書レベルではなく、ロードバランサーレベルで動作します。 CIDR 表記​の形式の IP アドレスのみを渡してください。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-allowlist-remove)cloudhub:load-balancer:allowlist:remove \> cloudhub:load-balancer:allowlist:remove このコマンドでは、​``​ で指定される IP または IP アドレスの範囲を ​``​ で指定されるロードバランサーの許可リストから削除します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-mappings-describe)cloudhub:load-balancer:mappings:describe \> cloudhub:load-balancer:mappings:describe \[certificateName\] このコマンドは、​``​ で指定されるロードバランサーのマッピングルールをリストします。 `certificateName`​ が渡されない場合、Anypoint Platform CLI はデフォルトの SSL エンドポイントのマッピングを返します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#cloudhub-load-balancer-mappings-add)cloudhub:load-balancer:mappings:add \> cloudhub:load-balancer:mappings:add \[flags\] \[certificateName\] このコマンドは、​`certificateName`​ フラグで渡される CN の ​``​ で指定されるロードバランサーにプロキシマッピングルールを追加します。 `certificateName`​ が渡されない場合、Anypoint Platform CLI はマッピングをデフォルトの SSL エンドポイントに追加します。
値 説明 例

name

ルールが適用されるロードバランサーの名前。

testloadbalancer

inputUri

入力 URL の URI の名前

example.com

appName

要求が転送される出力 URL のアプリケーションの名前

{app}-example

appUri

要求が転送される出力 URL のアプリケーションの URI

/

上の例の値の場合、​`my-superapp.api.example.com/status?limit=10`​ への入力コールでアプリケーションのエンドポイント ​`my-superapp-example: /status?limit=10`​ がコールされます。 このコマンドでは、​`--upstreamProtocol`​ フラグも使用できます。 `--upstreamProtocol`​ フラグは、内部的にロードバランサーと通信するためにアプリケーションで使用されるプロトコルを設定します。アップストリームプロトコルが設定されていない場合、HTTP がデフォルトとして使用されます。
フラグ 説明

--upstreamProtocol <protocol>

HTTP ポート 8091 または HTTPS ポート 8092 でアップストリームアプリケーションを確認する。 サポートされている値: http​、​https

--certificateName <certificate name>

省略可能なフラグ

### [](#cloudhub-load-balancer-mappings-remove)cloudhub:load-balancer:mappings:remove \> cloudhub:load-balancer:mappings:remove \[flags\] \[certificateName\] このコマンドは、​``​ で指定される優先度インデックスおよび ​`certificateName`​ フラグとして指定される CN で、​``​ で指定されるロードバランサーからプロキシマッピングルールを削除します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 `certificateName`​ が渡されない場合、Anypoint Platform CLI はデフォルトの SSL エンドポイントのマッピングを削除します。 ### [](#cloudhub-load-balancer-dynamic-ips-enable)cloudhub:load-balancer:dynamic-ips:enable \> cloudhub:load-balancer:dynamic-ips:enable \[flags\] このコマンドは、​``​ で指定されるロードバランサーの動的 IP を有効にします。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-load-balancer-dynamic-ips-disable)cloudhub:load-balancer:dynamic-ips:disable \> cloudhub:load-balancer:dynamic-ips:disable \[flags\] このコマンドは、​``​ で指定されるロードバランサーの動的 IP を無効にします。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-region-list)cloudhub:region:list \> cloudhub:region:list \[flags\] このコマンドは、サポートされているすべてのリージョンをリストします。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#cloudhub-runtime-list)cloudhub:runtime:list \> cloudhub:runtime:list \[flags\] このコマンドは、サポートされているすべてのランタイムをリストします。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ## [](#cloudhub-vpc)CloudHub Anypoint VPC
コマンド 説明

すべての Anypoint VPC をリストする

Anypoint VPC の詳細を表示する

新しい Anypoint VPC を作成する

既存の Anypoint VPC を削除する

Runtime Manager 環境と Anypoint VPC の関連付けを変更する。

Runtime Manager 環境と Anypoint VPC の関連付けを変更する。

Anypoint VPC を一連のビジネスグループと共有する。

Anypoint VPC を一連のビジネスグループと共有する。

内部 DNS サーバーを使用して解決されるドメイン名を設定する。フラグを指定せずに使用する場合、内部 DNS が無効になります。

内部 DNS サーバーを使用して解決されるドメイン名のリストをクリアする

この Anypoint VPC の Mule アプリケーションのファイアウォールルールを表示する

この Anypoint VPC の Mule アプリケーションのファイアウォールルールを追加する

この Anypoint VPC の Mule アプリケーションのファイアウォールルールを削除する

### [](#cloudhub-vpc-list)cloudhub:vpc:list \> cloudhub:vpc:list \[flags\] このコマンドは、使用可能なすべての Anypoint VPC をリストします。ID、リージョン、ネットワークの環境、およびデフォルトの Anypoint VPC かどうかを返します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 ### [](#cloudhub-vpc-describe)cloudhub:vpc:describe \> cloudhub:vpc:describe \[flags\] このコマンドは、​``​ で指定される Anypoint VPC に関する情報を表示します。 フラグ ​`-o json`​ を使用して、​``​ で指定するアプリケーションの未加工の JSON 応答を取得します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-vpc-create)cloudhub:vpc:create \> cloudhub:vpc:create \[flags\] \[environments...\] このコマンドは、クラスレスインタードメインルーティング (CIDR) ブロック形式 ( [CIDR 表記](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks)​を使用) の ​``​ で渡される​[サイズ](https://docs.mulesoft.com/cloudhub/vpc-provisioning-concept#faq_how_to_size_vpc)​で ​``​ の名前を使用して ​``​ で指定されるリージョンに Anypoint VPC を作成し、後で引数として渡される​[環境](https://docs.mulesoft.com/jp/access-management/environments)​に関連付けます。
Anypoint VPC は、組織内のビジネスグループにバインドされている必要があります。Anypoint VPC を作成するときに ​business-groups add​ コマンドを使用して、ビジネスグループに割り当ててください。
このコマンドでは、デフォルトの ​`--help`​ フラグ以外に ​`--default`​ フラグも使用できます。渡されると、Anypoint VPC は選択された環境のデフォルトの Anypoint VPC として作成されます。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 ### [](#cloudhub-vpc-delete)cloudhub:vpc:delete \> cloudhub:vpc:delete このコマンドは、​``​ で指定される Anypoint VPC を削除します。
このコマンドは、削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-vpc-environments-add)cloudhub:vpc:environments:add \> cloudhub:vpc:environments:add \[flags\] \[environments...\] このコマンドは、​``​ で定義される Anypoint VPC を、後で引数として渡される環境に割り当てます。 `--default`​ フラグでは、Anypoint VPC を組織のデフォルトとして設定できます。これは、Anypoint VPC が明示的に関連付けられていないすべての環境に適用されます。 このコマンドでは、デフォルトの ​`--help`​ フラグも使用できます。 ### [](#cloudhub-vpc-environments-remove)cloudhub:vpc:environments:remove \> cloudhub:vpc:environments:remove \[flag\] \[environments...\] このコマンドは、​``​ で定義される Anypoint VPC を、後で引数として渡される環境から削除します。 このコマンドでは、デフォルトの ​`--help`​ フラグ以外に、この Anypoint VPC を環境のデフォルトの Anypoint VPC として削除する ​`--default`​ フラグも使用できます。 ### [](#cloudhub-vpc-business-groups-add)cloudhub:vpc:business-groups:add \> cloudhub:vpc:business-groups:add \[flags\] このコマンドは、​``​ で定義される Anypoint VPC を、後で引数として渡されるビジネスグループに割り当てます。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-vpc-business-groups-remove)cloudhub:vpc:business-groups:remove \> cloudhub:vpc:business-groups:remove \[flags\] このコマンドは、​``​ で定義される Anypoint VPC を、後で引数として渡されるビジネスグループから削除します。
このコマンドは、指定されたリソースから Anypoint VPC を削除する前に 2 回入力を促しません。削除命令を送信する場合、確認を求められることはありません。
このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-vpc-dns-servers-set)cloudhub:vpc:dns-servers:set \> cloudhub:vpc:dns-servers:set \[flags\] このコマンドは、非公開アドレスでも公開アドレスでも IP アドレスを指定する必要がある DNS サーバーを使用して解決されるローカルホスト名 (内部ドメイン名) のリストを設定します。 それらの非公開ドメインが指定されている場合、ワーカーは非公開 DNS を使用して解決するため、非公開ネットワークの内部ホスト名を引き続き使用できます。
この機能は、Mule バージョン 3.5.x、3.6.x、3.7.4、3.8.0-HF1、3.8.1、3.8.2 を実行しているワーカーでサポートされます。
このコマンドでは、デフォルトの ​`--help`​ フラグ以外に次のフラグも受け入れます。
フラグ 説明

--server

特殊なドメインを解決する DNS サーバーの IP アドレス。最大 3 回指定できます。

--domain

特殊な DNS サーバーリストで解決するドメイン。複数回指定できます。

ドメインは任意の数、IP アドレスは最大 3 個渡すことができます。 例: `$ cloudhub:vpc:dns-servers:set --domain example.com --server 192.168.1.10 `​. このコマンドを実行するたびに、以前の DNS セットコマンドは上書きされます。 DNS セットを削除するには、​[vpc dns-servers unset](#cloudhub-vpc-dns-servers-unset)​ コマンドを使用する必要があります。 ### [](#cloudhub-vpc-dns-servers-unset)cloudhub:vpc:dns-servers:unset \> cloudhub:vpc:dns-servers:unset \[flags\] このコマンドは、​``​ で渡される Anypoint VPC の DNS サーバーを使用して解決されるローカルホスト名 (内部ドメイン名) のリストをクリアします。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-vpc-firewall-rules-describe)cloudhub:vpc:firewall-rules:describe \> cloudhub:vpc:firewall-rules:describe このコマンドは、​``​ で定義される Anypoint VPC のすべてのファイアウォールルールの情報を表示します。 このコマンドには ​`--output`​ フラグを使用できます。​`--output`​ フラグを使用して、応答形式を指定します。サポートされている値は、​`table`​ (デフォルト) および ​`json`​ です。 このコマンドでは、デフォルトのフラグ ​`--help`​ も受け入れます。 ### [](#cloudhub-vpc-firewall-rules-add)cloudhub:vpc:firewall-rules:add \> cloudhub:vpc:firewall-rules:add \[flags\] \[toPort\] このコマンドは、変数で設定される値を使用して、​``​ で定義される Anypoint VPC にファイアウォールルールを追加します。
値 説明 例

vpc

このロードバランサーがバインドされる Anypoint VPC の名前。
Anypoint VPC 名にスペースが含まれている場合、「"」文字で囲んで渡す必要があります。

vpc-demo

cidrBlock

ファイアウォールで許可する CIDR 表記の IP アドレス。

192.0.1.0/27

protocol

ルールで使用するプロトコル。​tcp​ または ​udp​ になります。

tcp

fromPort

ファイアウォールで要求を許可するポート。(0 ~ 65535)。

8888

toPort

省略可能​。ポート範囲が必要な場合、​fromPort​ および ​toPort​ 変数でそのような範囲を定義します。

8090

Anypoint VPC を作成するときにアウトバウンドアドレスを許可してください。
デフォルトでは、すべての IP アドレスがブロックされるため、Anypoint VPC ファイアウォールルールに対して IP アドレスまたはアドレスの範囲を承認する必要があります。

このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ### [](#cloudhub-vpc-firewall-rules-remove)cloudhub:vpc:firewall-rules:remove \> cloudhub:vpc:firewall-rules:remove このコマンドは、​``​ で渡されるインデックスで、​``​ で指定される Anypoint VPC 内のワーカーからファイアウォールルールを削除します。 このコマンドでは、デフォルトのフラグ ​`--help`​ のみを受け入れます。 ## [](#関連情報)関連情報 - [Anypoint Platform CLI 3.x](https://docs.mulesoft.com/jp/anypoint-cli/latest/) # CloudHub でのアプリケーションの管理 [CloudHub](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​ にアプリケーションをデプロイした後に、Runtime Manager を使用して実行時にアプリケーションを管理できます。 アプリケーションが ​[CloudHub](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​ または​[独自サーバー](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers)​のどちらにデプロイされているかに応じて、実行できる一連のアクションが異なります。
このドキュメントは、Runtime Manager コンソールを使用して ​CloudHub​ にデプロイされたアプリケーションについてのものです。すべての種別のデプロイメントに共通する基本的な管理ツールについては、​「デプロイ済みアプリケーションの管理」​を参照してください。プラットフォームで使用できるさまざまなデプロイメントシナリオを理解するには、​「デプロイメントオプション」​を参照してください。
[CloudHub](https://docs.mulesoft.com/jp/cloudhub/)​ にデプロイされたアプリケーションでは、次の機能を処理できます。 - [キュー](https://docs.mulesoft.com/jp/cloudhub/managing-queues) - [スケジュール](https://docs.mulesoft.com/jp/cloudhub/managing-schedules) - [アプリケーションプロパティの保護](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) - [オブジェクトストア](https://docs.mulesoft.com/jp/cloudhub/managing-application-data-with-object-stores) - [カスタムアプリケーションアラート](https://docs.mulesoft.com/jp/cloudhub/custom-application-alerts) ## [](#アプリケーションダッシュボード)アプリケーションダッシュボード **\[Applications (アプリケーション)\]**​ タブでいずれかのアプリケーションを選択すると、右側にパネルが開き、アプリケーションの追加情報を参照したり、設定にアクセスしたりできます。 ![ダッシュボード](/mulesoft/current/ja-jp/cloudhub/_images/dashboard-ch.png) このダッシュボードに表示される内容は、アプリケーションが ​[CloudHub](https://docs.mulesoft.com/jp/cloudhub/)​ と ​[Mule](https://docs.mulesoft.com/jp/runtime-manager/managing-applications-on-your-own-servers)​ のどちらにデプロイされているかによって異なります。 CloudHub にデプロイされているアプリケーションの場合は、状況、最終変更日時、デプロイされたアプリケーション ZIP ファイルが表示されます。ZIP ファイルは、このメニューから ​**\[Choose File (ファイルを選択)\]**​ ボタンを使用して変更できます。 また、アプリケーションが実行されている CloudHub ワーカーに関する追加情報として、Mule バージョン、ワーカーサイズ、ワーカー数、リージョンも表示されます。さらに、ログとインサイトを表示するボタンと ​**\[Manage Application (アプリケーションを管理)\]**​ メニューを開くボタンも表示されます。 ## [](#アプリケーション設定にアクセスする)アプリケーション設定にアクセスする 1. [Anypoint Platform](https://anypoint.mulesoft.com)​ にサインインし、Runtime Manager の ​**\[Applications (アプリケーション)\]**​ タブを表示します。 2. CloudHub で実行されているアプリケーションのいずれかを選択して、右側のパネルを開きます。 3. 右側のパネルで、​**\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックして、アプリケーションの設定を開きます。 ![「Manage Application (アプリケーションを管理)」](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-manage-application.png) このメニューでは、デプロイ時に定義できる多くの設定を変更できます。CloudHub 上のアプリケーションの場合は、ログデータ、インサイト、アラート、キューにアクセスし、スケジュールとアプリケーションデータのセットアップと管理を実行できます。また、​**\[Alerts History (アラート履歴)\]**​ タブも表示できます。このタブには、このアプリケーションでトリガーされたアラートの記録が表示されます。詳細は、​[「Runtime Manager のアラート」](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager)​を参照してください。
アプリケーションのデプロイ後は名前を変更することはできません。名前を変更するには、削除してから新しい名前でアプリケーションを再デプロイしてください。
## [](#アプリケーションの監視)アプリケーションの監視 アプリケーションが CloudHub にデプロイされている場合は、アプリケーションで発生するイベントやアプリケーションが実行されている仮想サーバーのパフォーマンスを監視するための充実したツール群があります。詳細は、​[「アプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-manager/monitoring)​を参照してください。 ## [](#異なるリージョンへの再デプロイ)異なるリージョンへの再デプロイ アカウントでグローバルデプロイメントが有効になっている場合は、CloudHub デプロイメントに異なるリージョンを選択できます。 . 設定ページで、​**\[Runtime (ランタイム)\]**​ セクションを選択し、ドロップダウンメニューから目的のリージョンを選択します。 . リージョンを選択した後に ​**\[Apply Changes (変更を適用)\]**​ ボタンをクリックすると、新しいリージョンでアプリケーションが再起動されます。 ![SetRegion](/mulesoft/current/ja-jp/cloudhub/_images/setregion.png) システム管理者は、\[Account Settings (アカウント設定)\] の ​**\[Organization (組織)\]**​ タブで​[デフォルトのリージョンを設定](https://docs.mulesoft.com/jp/cloudhub/managing-cloudhub-specific-settings)​できますが、アプリケーションがデプロイされると、その設定を必要に応じて上書きできます。
ヨーロッパにデプロイされたアプリケーションのドメインは、自動的に ​http://myapplicationdomain.eu.cloudhub.io​ に更新されます。
## [](#アプリケーションの拡張)アプリケーションの拡張 **\[Worker size (ワーカーサイズ)\]**​ ドロップダウンからオプションを選択し、​**\[Apply Changes (変更を適用)\]**​ ボタンをクリックすることで、アプリケーションを動的に拡張できます。アプリケーションでは、指定したワーカーサイズとワーカー数が使用されます。複数のワーカーのデプロイについての詳細は、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。 ![WorkerSize](/mulesoft/current/ja-jp/cloudhub/_images/workersize.png)
デフォルトでは、すべてのアプリケーションは任意のサイズの最大 4 つのワーカーに制限されています。無料アカウントと Professional アカウントでは、アプリケーションごとに 1 つのワーカーに制限されています。ワーカー数や vCore 容量を増やす必要がある場合は、サブスクリプションを変更してください。1 つのドメインに対して 5 つ以上のワーカーが必要な場合は、直接 MuleSoft ヘルプセンター​までお問い合わせください。
## [](#デプロイしたアプリケーションのコピーをダウンロードする)デプロイしたアプリケーションのコピーをダウンロードする 最後にデプロイしたアプリケーションアーカイブは、常にコンソールからダウンロードできます。 アプリケーションアーカイブをダウンロードするには、アプリケーションの ​**\[Settings (設定)\]**​ ページにある ​**\[Application File (アプリケーションファイル)\]**​ 内のリンクをクリックします。 ![DownloadAppFile](/mulesoft/current/ja-jp/cloudhub/_images/downloadappfile.png)
アプリケーション名が表示されるが、その名前が有効なリンクでない場合、システム管理者が開発者およびサポートアカウント種別のユーザーによるアプリケーションのダウンロードを無効にしています。アプリケーションのコピーが必要な場合は、システム管理者にお問い合わせください。
## [](#アプリケーションを更新する)アプリケーションを更新する アプリケーションに変更を加えた場合、新しいバージョンをアップロードする手順は次のとおりです。 1. そのアプリケーションの \[Deployment (デプロイメント)\] 画面で ​**\[Choose file (ファイルを選択)\]**​ をクリックします。新しいファイル名が斜体テキストで表示されます。 2. デプロイメントに新しいファイルを使用するには、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 数秒以内に、アプリケーションは正常に再デプロイされます。再デプロイ中はアプリケーションの状況インジケーターが青に変わり、デプロイメントが完了すると緑に変わります。 3. **\[Logs (ログ)\]**​ をクリックすると、アプリケーションの再デプロイメントをライブで確認できます。 アプリケーションの最新のバージョンを使用して新しいワーカーの開始に成功すると、以前のバージョンは上書きされ、以前のアーカイブをダウンロードしたり、アプリケーションの以前のバージョンに戻したりすることはできなくなります。 ### [](#アプリケーションの-mule-バージョンの更新)アプリケーションの Mule バージョンの更新 古いバージョンの Mule でアプリケーションを実行している場合は、最新の Mule バージョンを使用するようにアプリケーションを更新できます。更新するには、​**\[Runtime version (ランタイムバージョン)\]**​ をクリックし、​**\[New (最新)\]**​ という表示ラベルの付いたバージョンを選択して、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ![アプリケーションのランタイムバージョンを更新するための \[New (最新)\] の表示ラベル](_images/apps-update-runtime-version.png) Figure 1. アプリケーションの ​**\[Settings (設定)\]**​ ページで ​**\[Runtime version (ランタイムバージョン)\]**​ の表示ラベル ​**\[New (最新)\]**​ を示す矢印。 複数のアプリケーションを同時に更新するには、 [CloudHub API Bulk Action](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/1.0.13/console/method/%231545/)​ 操作を使用してください。 ### [](#cloudhub-を使用したダウンタイムなしの更新)CloudHub を使用したダウンタイムなしの更新 CloudHub では、HTTP API のユーザーにダウンタイムが発生しないアプリケーションの更新がサポートされています。アプリケーションの更新中は、実行しているアプリケーションの古いバージョンと新しいバージョンの両方が保持されます。新しいバージョンが完全に開始されるまで、ドメインはアプリケーションの古いバージョンを参照します。これにより、新しいバージョンのアプリケーションを開始している間も古いアプリケーションからの要求を引き続き処理できます。
アイコン 説明

image2014-10-24+16:43:57

アプリケーションの更新をデプロイ中です。

image2014-10-24+16:44:47

アプリケーションの更新済みバージョンは、正常に開始されませんでした。新しいバージョンはシャットダウンされ、古いアプリケーションが引き続き実行されます。

アプリケーションで静的 IP を使用している場合、更新により、CloudHub が静的 IP アドレスをアプリケーションの以前のバージョンから新しいバージョンに再割り当てしている間に最大 1 分間のダウンタイムが発生する可能性があります。ダウンタイムを考慮するために必要な再試行メカニズムがクライアントに含まれていることを確認します。
デプロイメントをキャンセルしたり、キャンセルが完了する前に同じアプリケーションで新しいデプロイメントを開始したりすると、1 ~ 3 分のダウンタイムが生じる可能性があります。
## [](#静的-ip)静的 IP CloudHub では、アプリケーションの静的 IP の割り当てがサポートされるため、他のサービス用に静的 IP を許可リストに登録できます。アプリケーションの静的 IP を有効にするには、アプリケーションの設定ページで ​**\[Static IPs (静的 IP)\]**​ タブに移動し、​**\[Use Static IP (静的 IP を使用)\]**​ チェックボックスをオンにします。静的 IP がアプリケーションに割り当てられ、下のテーブルに表示されます。アプリケーションが再起動されると、この静的 IP が使用されます。アプリケーションが実行中でない場合は、アプリケーションを開始する前に静的 IP を事前に割り当てることができます。詳細は、​[「\[Static IPs (静的 IP)](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub#static-ips-tab-settings) タブの設定」\]​を参照してください。
アプリケーションが削除されると、静的 IP は失われるため、新しい IP を要求する必要があります。
## [](#アプリケーションの-http-サービスの作成)アプリケーションの HTTP サービスの作成 HTTP ベースのサービスをドメインで使用できるようにするには、設定内で ​`${http.port}`​ 変数を使用します。次に例を示します。 ```xml ``` このポートは CloudHub によって指定され、ドメインの負荷は指定した数のワーカーに自動的に分散されます。 ## [](#関連情報)関連情報 - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [クラスタリング](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric) - [キューの管理](https://docs.mulesoft.com/jp/cloudhub/managing-queues) - [スケジュールの管理](https://docs.mulesoft.com/jp/cloudhub/managing-schedules) - [オブジェクトストアを使用したアプリケーションデータの管理](https://docs.mulesoft.com/jp/cloudhub/managing-application-data-with-object-stores) - [Anypoint Platform CLI](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [アプリケーションプロパティを安全に隠す](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) # CloudHub での自動スケーリング
自動スケーリング機能を使用するには、組織にエンタープライズライセンス契約 (ELA) が必要です。エンタイトルメントは、適格なユースケースに基づいて承認されます。この機能に興味がある場合は、アカウントの担当者にお問い合わせください。
CloudHub により、使用量の変化に合わせてアプリケーションの背後の処理能力を即座に対応させることができます。アプリケーションで使用される処理リソースをスケールアップまたはスケールダウンして CPU やメモリの使用量のしきい値に対応するポリシーを定義できます。 ## [](#自動スケーリングを設定する)自動スケーリングを設定する 1. Runtime Manager の ​**\[Applications (アプリケーション)\]**​ タブをクリックします。 2. CloudHub にデプロイされているアプリケーションを選択して、そのパネルを開きます。 3. パネルで、​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 4. **\[Settings (設定)\]**​ セクションで ​**\[Autoscaling (自動スケーリング)\]**​ タブを選択します。 すべての既存の自動スケーリングポリシーを確認したり、アクティブ化または非アクティブ化したり、作成または削除したり、関連する ​[Runtime Manager のアラート](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager)​を作成したりできます。 ## [](#ポリシーを作成する)ポリシーを作成する ポリシーを作成するには、​**\[Create Policy (ポリシーを作成)\]**​ ボタンをクリックし、ポリシーをセットアップする項目を設定します。 ![ポリシー](/mulesoft/current/ja-jp/cloudhub/_images/autoscale-create-policy.png) ポリシーの要件を満たすと、ワーカーのサイズまたは数の変更がトリガーされます。ポリシーは、CPU またはメモリの使用量に基づいて作成することができ、ワーカーの数やサイズを変更できます。どのポリシーにも、スケールアップとスケールダウンの条件が含まれます。 ![form](/mulesoft/current/ja-jp/cloudhub/_images/policy-form.png) 1. ポリシーの​**名前**​を入力します。 2. スケーリングが​**メモリ使用量と CPU 使用量**​のどちらに基づくのかを決定します。
表示されている割合は、使用されている JVM に割り当てられる合計メモリまたは CPU の割合です。これには、JVM 自体でコンシュームされるメモリも含まれます。
3. スケーリングの​**ルール**​を決定します。アップスケールとダウンスケールの両方の条件で次の値を入力します。 1. 使用量の​**割合** 2. ポリシーが適用されるまでこのレベルを維持する必要がある​**期間** 3. このポリシーや他のポリシーが適用されてスケーリングに影響することを防止する​**クールダウン期間** 4. ポリシーの適用時に実行される​**アクション**​を定義します。 1. ワーカーの​**数**​またはワーカーの​**サイズ**​に影響を与える 2. 変動期間の​**最大**​値と​**最小**​値を設定する
自動スケーリングポリシーでは、ワーカーの最大数は 4、ワーカーの最大サイズは 16 vCore です。
## [](#スケーリングの考慮事項)スケーリングの考慮事項 どのポリシーでも、アプリケーションは段階的にスケールされます。多くのスケーリングステップが必要となる強いスパイクに合わせてスケールアップする場合、ポリシーの評価時間とクールダウン期間の両方の時間がステップごとにかかります。 アプリケーションごとに 1 つの自動スケーリングポリシーのみを適用できます。 使用可能なワーカーの最大量およびサイズは、アカウントの特性によって制限されます。アカウントで実行されている複数のアプリケーションが限られたリソースで競合している場合、先着順に割り当てられます。 ## [](#既存のポリシーの編集)既存のポリシーの編集 既存のポリシーを編集するには、​**\[Policies (ポリシー)\]**​ タブを開きます。ポリシー名をクリックすると、新規ポリシーの作成時に使用するメニューにアクセスします。 ## [](#ポリシーの非アクティブ化)ポリシーの非アクティブ化 実行中のポリシーを非アクティブ化するには、\[policies (ポリシー)\] タブを開き、対応する ​**\[Status (状況)\]**​ 項目で切り替えます。 ![有効化](/mulesoft/current/ja-jp/cloudhub/_images/enable-policy.png) ## [](#ポリシーの削除)ポリシーの削除 既存のポリシーを削除するには、\[policies (ポリシー)\] タブに移動し、対応する削除アイコンをクリックします。 ## [](#アラートの設定と自動スケーリング履歴の表示)アラートの設定と自動スケーリング履歴の表示 CloudHub では、ワーカーの自動スケーリングイベントが発生したときに警告する 2 つの固有のアラートタイプをアプリケーションにセットアップできます。一方はスケールアップについて警告するアラートで、他方はスケールダウンについて警告するアラートです。 このアラートを設定すると、そのようなイベントが発生したときに、入力したアドレスに自動的にメールが送信されます。 また、アラートがトリガーされたすべての時間の全履歴を表示することもできます。これを表示するには、​**\[Alerts (アラート)\]**​ ページで、アラート名をクリックして対応するパネルを開きます。 ![履歴](/mulesoft/current/ja-jp/cloudhub/_images/alerts-history-autoscale.png) ## [](#関連情報)関連情報 - [Runtime Manager のアラート](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [クラスタリング](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric) - [Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [アプリケーションプロパティの保護](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) # CloudHub ネットワークガイド このガイドは、Runtime Manager のクラウドベースバージョンを使用するクラウドデプロイを対象とします。別のデプロイメントシナリオについては、​[「デプロイメントオプション」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 ## [](#概要)概要 CloudHub にはインテグレーションと API を設計するためのさまざまなツールが用意されており、インテグレーションと API の保守性、安全性、拡張性が確保されます。このガイドでは、基本的なネットワークアーキテクチャ、DNS、およびファイアウォールルールについて説明します。 ![CloudHub ネットワークの概要](/mulesoft/current/ja-jp/cloudhub/_images/ch-networking-guide.png) Figure 1. この画像は、CloudHub コンポーネントを示しています (ロードバランサー、Virtual Private Cloud、Mule ワーカーの DNS レコード)。 負荷分散および DNS レコードについては、以下の各セクションを参照してください。 VPC については、​[「Virtual Private Cloud」](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​を参照してください。 ## [](#負荷分散)負荷分散 CloudHub はすべてのインテグレーションに負荷分散サービスを提供します。デフォルトの負荷分散サービスを使用するか、​[専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer)​を取得することができます。 CloudHub 負荷分散サービスはワーカー間でラウンドロビン方式の負荷分散を実行します。これにより、ワーカーは、受け取る要求が増加するにつれて規模を線形的に拡大できます。また、この負荷分散では、アプリケーションのアップグレード時に切り替えが透過的に実行されます。​[「CloudHub でのアプリケーションの管理」](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub)​を参照してください。 CloudHub にデプロイされた各アプリケーションには、ロードバランサーを参照する ​`CNAME`​ レコードがあります (例: `myapp.region.cloudhub.io`​)。CloudHub にデプロイされた Mule アプリケーションはホスト ​`0.0.0.0`​ 上で HTTP ポート (​`8081`​) または HTTPS ポート (​`8082`​) をリスンする必要があります。 Mule ワーカーでは次のポートが割り当てられます。 - `http.port`​ が ​`8081`​ に設定されます - `https.port`​ が ​`8082`​ に設定されます 次に、ロードバランサーは Mule ワーカー上の割り当てられたポートに要求を転送します。転送されたトラフィックは引き続き HTTP および HTTPS プロトコルを使用します。つまり、​`${http.port}`​ で HTTPS をリスンしたり、​`${https.port}`​ でプレーン HTTP をリスンしたりできません。 これらのポートを、それぞれに予約されたプロパティ ​`${http.port}`​ および ​`${https.port}`​ を使用して参照する必要があります。これで、CloudHub サービスはデプロイ時にポートを動的に割り当てることができます。 HTTPS エンドポイントを公開する Mule 設定の例を次に示します。 ```xml ```
Mule ワーカー上で CloudHub ロードバランサーは自動的に ​http.port ​:80​ を HTTP 用のポート ​:8081​ にプロキシし、​https.port ​:443​ を HTTPS 用の ​:8082​ にプロキシします。
mule-app.properties​ ファイルで ​http.port​ と ​https.port​ に他の値が指定されている場合、それらはデプロイ時に上書きされます。

CloudHub のロードバランサー (​myapp.region.cloudhub.io​) を介してクライアントが実行した要求ごとに、ロードバランサーは 2 つの接続を維持します。1 つはクライアントからの接続で、もう 1 つはワーカーへの接続です。 接続ごとにロードバランサーは 300 秒のアイドルタイムアウトを管理します。これは、どちらの接続にもデータが送信されていない場合にトリガーされます。この期間にデータが送受信されない場合、ロードバランサーは両方の接続を閉じます。

どちらの側からでも接続の処理に 300 秒を超える時間がかかる場合、処理を非同期で実行することを検討してください。

## [](#dns-レコード)DNS レコード アプリケーションが CloudHub にデプロイされると、アプリケーションの以下の DNS レコードが公開されます。

myapp.region.cloudhub.io

ロードバランサー。ポート 80 と 443 はそれぞれ ​${http.port}​ と ​${https.port}​ に転送されます。

mule-worker-myapp.region.cloudhub.io

Mule ワーカーの外部 IP アドレス。公開 HTTP サービスは ​${http.port}​ と ​${https.port}​ で公開されます。

mule-worker-internal-myapp.region.cloudhub.io

Mule ワーカーの内部 IP アドレス。この DNS レコードの IP アドレスには、顧客の非公開 ​Anypoint VPC​ 内でのみアクセスできます。​MuleSoft の共有 VPC 内で実行されているワーカーはこの IP アドレスにアクセスできません。​内部 HTTP サービスは ​${http.private.port}​ と ​${https.private.port}​ で公開されます。割り当てられたデフォルトのポートはそれぞれ 8091 および 8092 であり、これらを変更することはできません。

たとえば、次のような特定の状況では、アプリケーションの内部 IP アドレスを知ることが必要になる場合があります。 - 公開インターネットにデータを送信せずに、顧客の ​[Anypoint VPC](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ 内でワーカーと直接通信する - 独自のロードバランサーをセットアップする この IP アドレスには、Anypoint VPC 内から ​`mule-worker-internal-myapp.region.cloudhub.io`​ レコードを介してアクセスできます。ワーカーに直接アクセスする場合、CloudHub の負荷分散レイヤーから得られる負荷分散のすべてのメリットが失われます。 ## [](#ip-範囲および静的-ip)IP 範囲および静的 IP CloudHub IP アドレスは Amazon EC2 IP プールから選択されます。この範囲のリストについては、 [Amazon AWS IP アドレス範囲 API](http://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)​ を参照してください。このページの「Download (ダウンロード)」リンクでは、リージョンを含むすべての範囲の動的に生成された JSON 表現を取得できます。これらの範囲は通知なしに変更される可能性があるため、この情報を定期的に更新する必要があります。 CloudHub では、アプリケーションの静的 IP の割り当てがサポートされるため、他のサービス用に静的 IP を許可リストに登録できます。アプリケーションの静的 IP を有効にするには、Runtime Manager UI のアプリケーション設定ページの ​**\[Static IPs (静的 IP)\]**​ タブに移動して、​**\[Use Static IP (静的 IP を使用)\]**​ チェックボックスをオンにします。デフォルトでは、サブスクリプション内の本番 vCore の 2 倍の数の静的 IP が割り当てられます。この制限を増やすには、 [MuleSoft ヘルプセンター](https://help.mulesoft.com)​にお問い合わせください。 アプリケーションの静的 IP が割り当てられると、IP アドレスはアプリケーション設定ページの ​**\[Static IPs (静的 IP)\]**​ タブに表示されます。静的 IP についての詳細は、​[「Static IPs Tab Settings (\[Static IPs (静的 IP)](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub#static-ips-tab-settings) タブの設定)」\]​を参照してください。
静的 IP アドレスは、Anypoint VPC 内部の非公開 IP アドレスではサポートされません。
場合によって、ファイアウォールまたはインフラストラクチャの設定により、Mule Runtime Engine が Runtime Manager の公開サービスにアクセスできないことがあります。これは、Mule を登録する場合や、Mule を開始し、Runtime Manager と連携するするように Mule を登録する場合に問題となることがあります。 [Runtime Manager エージェント](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-agent)​と Runtime Manager コンソール間の通信のために IP アドレスを許可する必要がある場合、​[「ポート、IP アドレス、ホスト名の許可」](https://docs.mulesoft.com/jp/runtime-manager/rtm-agent-allowlists)​を参照してください。
複数のワーカーを使用するアプリケーションに静的 IP を割り当てることができます。ただし、複数のワーカーの静的 IP を事前に割り当てることはできません。複数のワーカーの場合、IP アドレスは自動的に割り当てられます。
## [](#リージョンサービス)リージョンサービス アプリケーションをどのリージョンにデプロイするかに応じて、インテグレーションの DNS レコードとロードバランサーが変わる場合があります。各リージョンでアプリケーションがどの DNS レコードを使用できるかについて次の表にまとめました。
リージョン名 Region (リージョン) DNS レコードの例

US コントロールプレーンリージョン

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

us-e1

myapp.us-e1.cloudhub.io

米国東部 (オハイオ)

us-e2

myapp.us-e2.cloudhub.io

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

us-w1

myapp.us-w1.cloudhub.io

米国西部 (オレゴン)

us-w2

myapp.us-w2.cloudhub.io

カナダ (中央部)

ca-c1

myapp.ca-c1.cloudhub.io

南米 (サンパウロ)

br-s1

myapp.br-s1.cloudhub.io

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

sg-s1

myapp.sg-s1.cloudhub.io

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

au-s1

myapp.au-s1.cloudhub.io

アジア太平洋 (東京)

jp-e1

myapp.jp-e1.cloudhub.io

EU (アイルランド)

ir-e1

myapp.ir-e1.cloudhub.io

EU (フランクフルト)

de-c1

myapp.de-c1.cloudhub.io

EU (ロンドン)

uk-e1

myapp.uk-e1.cloudhub.io​

MuleSoft Government Cloud

US Gov West (米国政府西部)

usg-w1.gov

myapp.usg-w1.gov.cloudhub.io​

EU コントロールプレーンリージョン

EU (アイルランド)

ir-e1.eu1

myapp.ir-e1.eu1.cloudhub.io

EU (フランクフルト)

de-c1.eu1

myapp.de-c1.eu1.cloudhub.io

DNS レコードは各コントロールプレーンで一意です。EU コントロールプレーンは、米国コントロールプレーンがサポートする地域の一部をサポートしますが、DNS レコードは異なります。EU コントロールプレーンの詳細については、​[「EU コントロールプレーンについて」](https://docs.mulesoft.com/jp/eu-control-plane/)​を参照してください。 リージョンへのデプロイは、内部および外部のワーカー DNS アドレスにも影響します。たとえば、米国のコントロールプレーンを使用していてそれをアイルランド地域にデプロイした場合、内部および外部の IP アドレスの DNS レコードは ​`mule-worker-myapp.ir-e1.cloudhub.io`​ および ​`mule-worker-internal-myapp.ir-e1.cloudhub.io`​ になります。 ## [](#ファイアウォールルールおよびポートアドレス)ファイアウォールルールおよびポートアドレス 外部に公開されるポートは ​`${http.port}`​ と ​`${https.port}`​ (デフォルトではそれぞれ 8081 と 8082) の 2 つのみです。他のポートにアクセスする必要がある場合、​[Anypoint Virtual Private Cloud (Anypoint VPC)](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ を使用できます。 たとえば JMX ベースの監視を行うために追加のポートを Anypoint VPC 内で開くことができます。​[Anypoint VPC のドキュメント](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud#firewall-rules)​でファイアウォールルールに関するセクションを参照してください。 ## [](#専用の負荷分散の設定)専用の負荷分散の設定 場合によって、Mule ワーカー用のカスタム負荷分散レイヤーのセットアップが必要になることがあります。たとえば、カスタムドメイン名や SSL 証明書を提供する必要がある場合です。 ワーカー用の内部または外部 DNS レコードを介してトラフィックをロードバランサーから CloudHub ワーカーにルーティングできます。このレコードにはアプリケーション内のすべてのワーカーの IP アドレスが含まれます。DNS タイムアウトを 20 ~ 60 秒の間で設定することをお勧めします。これで、あらゆる DNS 変更がすばやく反映され、影響が最小限に抑えられます。 独自の ​[Anypoint VPC](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ を設定した後に、独自の​[専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer)​を設定できます。 ## [](#cloudhub-上のアプリケーションの一般公開の回避)CloudHub 上のアプリケーションの一般公開の回避 [Anypoint VPC](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ および ​[CloudHub 専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer)​がある場合、CloudHub でホストされるアプリケーションが一般に公開されることを回避できます。 1. 次の方法を使用して、ポート 8081 および 8082 の ​[Anypoint VPC ファイアウォールルール](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud#firewall-rules)​を削除します。 1. Anypoint VPC Management Center の ​**\[Firewall Rules (ファイアウォールルール)\]**​ タブ。​**接続元**​ ​`Anywhere (0.0.0.0/0)`​ とポート 8081 および 8082 を使用する両方のルールを削除します。 2. Anypoint Platform CLI。インデックス ​`1`​ および ​`3`​ を使用して ​[`cloudhub vpc firewall-rules remove`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-vpc-firewall-rules-remove)​ コマンドを実行します。 2. 承認する IP アドレスを使用して、専用ロードバランサーで​[許可リスト](https://docs.mulesoft.com/jp/cloudhub/lb-allowlists)​を作成します。
CloudHub 専用ロードバランサー​がない場合、最初のステップを実行すれば、Anypoint VPC にデプロイされたアプリケーションは一般に公開されません。
## [](#関連情報)関連情報 - [CloudHub にデプロイする場合の外部 HTTP/HTTPS ポートの提供](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub#providing-an-external-http-https-port) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) # CloudHub のアプリケーションの開発 CloudHub にデプロイするアプリケーションを開発する場合、次の考慮事項を確認してください。 ## [](#httphttps-ホストの指定)HTTP/HTTPS ホストの指定 HTTP 用 Anypoint Connector (HTTP Connector) を使用する場合、CloudHub 設定でホストアドレスを ​`0.0.0.0`​ として定義します。 CloudHub は、アプリケーションドメイン URL からの要求をエンドポイントに転送します。 複数のワーカーをデプロイした場合は、受信トラフィックはワーカーに自動的に負荷分散されます。 アプリケーションが拡張されると、ワークロードは自動的にワーカーの間で分散されます。 ## [](#外部-httphttps-ポートの指定)外部 HTTP/HTTPS ポートの指定 メッセージの受信、イベントのトリガー、Web サービスやユーザーインターフェースの公開のために外部からアクセス可能な HTTP ポートまたは HTTPS ポートがアプリケーションに必要な場合は、予約されているプロパティの ​`${http.port}`​ または ​`${https.port}`​ を使用して HTTP リスナーポートを宣言します。CloudHub では、ポート ​`${http.port}`​ または ​`${https.port}`​ がプラットフォームサービスによって自動的に割り当てられます。アプリケーションドメインの URL へのポート 80 のトラフィックは、​`${http.port}`​ に転送され、ポート 443 のトラフィックは ​`${https.port}`​ に転送されます。 このポートでの複数の CloudHub サービスへのルーティングをサポートするには、公開されている URL 上でそれぞれに一意のパスを設定する必要があります。次に例を示します。 ```console http://0.0.0.0:${http.port}/service/path/one http://0.0.0.0:${http.port}/service/path/two ``` ## [](#デプロイメントオプションの柔軟性)デプロイメントオプションの柔軟性 同じ Mule アプリケーションを異なるデプロイメント対象 (オンプレミスサーバーや CloudHub など) にデプロイするには、​[「Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/mule-runtime/latest/deploying)​を参照してください。 デプロイメント環境の主な違いについては、​[「デプロイメントオプション」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 アプリケーションの外部で各デプロイメントのプロパティと変数を定義し、アプリケーションからそれらを参照できます。 たとえば、変数 ​`http.port`​ や ​`https.port`​ にローカル値を定義できます。 詳細は、​[「プロパティの設定」](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties)​を参照してください。 Runtime Manager または Anypoint Platform コマンドラインインターフェースを使用して、これらのプロパティ変数を設定することもできます。 ### [](#http-プロキシ設定を回避する)HTTP プロキシ設定を回避する CloudHub 環境では、Mule アプリケーションはインターネット上で直接対象の HTTP サーバーにアクセスします。ローカル開発環境では、インターネットは HTTP プロキシサーバーを介してのみアクセスできます。 アプリケーションを CloudHub にデプロイしたときにコードを変更しなくて済むように JVM システムプロパティを使用することにより、Mule アプリケーションの HTTP 要求設定でプロキシ設定を追加するのを回避できます。 次の手順を実行します。 1. Mule 4 アプリケーションの場合は、次のように HTTP 要求設定のタイムアウト設定を入力します。 - **\[HTTP Request configuration (HTTP 要求設定)\]**​ > ​**\[General (一般)\]**​ > ​**\[Connection idle timeout (接続アイドルタイムアウト)\]**​: 30000 - **\[HTTP Request configuration (HTTP 要求設定)\]**​ > ​**\[Settings (設定)\]**​ > ​**\[Response timeout (応答タイムアウト)\]**​: 30000 タイムアウト値は 0 よりも大きい数値に調整してください。空白または 0 のタイムアウト値にすると、接続エラーが発生する場合があります。 2. ローカル Mule Runtime のコマンドラインに以下を追加します。Anypoint Studio で、​**\[Run Configurations (実行設定)\]**​ を変更して次のパラメーターを 1 行として追加します。 ```console -Dhttp.nonProxyHosts="localhost"\-Dhttps.proxyHost={proxy server ip}\-Dhttps.proxyPort={proxy server port}\-Dhttp.proxyHost={proxy server ip}\-Dhttp.proxyPort={proxy server port}\-Djava.net.useSystemProxies=false\-Dcom.ning.http.client.AsyncHttpClientConfig.useProxySelector=false\-Dcom.ning.http.client.AsyncHttpClientConfig.useProxyProperties=true ```
{proxy server ip}​ と ​{proxy server port}​ を実際の HTTP プロキシサーバーの IP アドレスとポート番号に置き換えます。
## [](#ログの設定)ログの設定 CloudHub ログサービスは、アプリケーションのすべてのログメッセージを取得します。 Runtime Manager コンソールの ​**\[Logging (ログ)\]**​ タブでログを表示できます。 診断や監査のためにログ内で追加情報を公開するには、​[Logger コンポーネント](https://docs.mulesoft.com/mule-runtime/latest/logger-component-reference)​を使用します。
CloudHub では、アプリケーションを削除すると、コンソールからログデータにアクセスできなくなります。CloudHub では、古いログデータはパージされる前に一定期間アーカイブされるため、必要に応じてデータを復元できます。 詳細は、 MuleSoft ヘルプセンター​でサポートケースを開いてください。
## [](#サードパーティライブラリのパッケージ化)サードパーティライブラリのパッケージ化 CloudHub には、さまざまなプロトコルでの接続やさまざまなデータ形式の変換をサポートするための Anypoint Platform のサービスがあります。 すべての標準 Mule ライブラリは、アプリケーションに含まれていて、使用できます。 別のサードパーティライブラリを含める必要がある場合には、そのライブラリをアプリケーションの JAR ファイルにパッケージできます。 詳細は、​[「Mule 4 の概要: アプリケーションのパッケージ化」](https://docs.mulesoft.com/mule-runtime/latest/mule-app-dev)​を参照してください。 ## [](#ファイアウォールの内側のリソースへのアクセス)ファイアウォールの内側のリソースへのアクセス ファイアウォールの内側のリソースにアクセスする必要があるアプリケーションを開発するときには、Anypoint Virtual Private Cloud (Anypoint VPC) を設定して CloudHub ワーカーをホストし、アプリケーションにアクセスするための IPSec トンネルを設定します。 ## [](#サードパーティ-api-およびサービスへのアクセス)サードパーティ API およびサービスへのアクセス MuleSoft には、Salesforce、NetSuite、Twitter など、多くのサードパーティアプリケーション用のコネクタが用意されています。 アプリケーションでコネクタを検索および使用する方法については、​[「Anypoint Connector の概要」](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)​を参照してください。 また、Anypoint Connector DevKit を使用して、独自のコネクタを作成することもできます。 ## [](#セキュアプロパティの使用)セキュアプロパティの使用 アプリケーションプロパティをセキュアとしてフラグ付けすると、その値は実行時にユーザーに表示されず、サーバーとコンソール間で渡されなくなります。 詳細は、​[「アプリケーションプロパティの保護」](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties)​を参照してください。 ## [](#関連情報)関連情報 - [HTTP Connector](https://docs.mulesoft.com/jp/http-connector/1.10/) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [Anypoint Studio](https://docs.mulesoft.com/studio/) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [ログデータの表示](https://docs.mulesoft.com/jp/cloudhub/viewing-log-data) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [Anypoint Connector DevKit](#connector-devkit::index.adoc) - [アプリケーションプロパティの保護](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) # CloudHub の使用 Anypoint Runtime Manager を使用すれば、Mule アプリケーションをオンプレミスサーバーや CloudHub などのさまざまなデプロイメント対象にデプロイできます。CloudHub を使用すると、次の状況を示していることになります。 - 特定の考慮事項に従い、​[CloudHub 用のアプリケーションを開発している](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub)​。 - 選択できるさまざまなツールを利用して、​[CloudHub にデプロイしている](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​。 - 各ワーカーのデプロイメントのメッセージとイベントおよび Mule Runtime Engine ログを含む​[ログデータを表示している](https://docs.mulesoft.com/jp/cloudhub/viewing-log-data)​。 - Log4j 設定と一緒にログシステムに取り込まれるようにログを設定すること (その後、CloudHub ログを無効にできる) で、​[ロギングシステムと統合している](https://docs.mulesoft.com/jp/cloudhub/custom-log-appender)​。 - リージョン、サブスクリプションレベル、プラン種別を含む ​[CloudHub 固有の設定を管理している](https://docs.mulesoft.com/jp/cloudhub/managing-cloudhub-specific-settings)​。 # CloudHub の概要 [CloudHub](http://www.mulesoft.com/cloudhub/ipaas-cloud-based-integration-demand)​ は、サービスとしてのインテグレーションプラットフォーム (iPaaS) であり、高度なクロスクラウドインテグレーションアプリケーションをクラウドにデプロイしたり、既存のデータソース上に新しい API を作成したり、オンプレミスアプリケーションをクラウドサービスと統合したりできます。 ## [](#cloudhub-のアプリケーションの作成)CloudHub のアプリケーションの作成 ![アプリケーション](/mulesoft/current/ja-jp/cloudhub/_images/logo-app.png) - [「CloudHub へのデプロイ」](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​を参照してください。 - HTTPS をサポートするようにこのアプリケーションを設定する方法については、​[「HTTPS サービスの構築」](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service)​を参照してください。
その他のアプリケーションの例については、​「Anypoint Exchange」​を参照してください。
同じ Mule アプリケーションを CloudHub または​[オンプレミスサーバー](https://docs.mulesoft.com/jp/runtime-manager/deploying-to-your-own-servers)​にデプロイできます。環境間では機能の動作が若干異なるため、デプロイメント戦略を立てるときにはこの点を考慮する必要があります。​[「デプロイメントオプション」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 ## [](#cloudhub-へのアプリケーションのデプロイ)CloudHub へのアプリケーションのデプロイ ![デプロイ](/mulesoft/current/ja-jp/cloudhub/_images/logo-deploy.png) アプリケーションを CloudHub にデプロイする方法について説明します。 - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [Anypoint Platform コマンドラインインターフェース (CLI)](https://docs.mulesoft.com/jp/anypoint-cli/latest/) ### [](#高い拡張性)高い拡張性 CloudHub は拡張性の高いクラウドで、オンデマンドでスケールできます。小さく始めて、拡張が必要なときにアプリケーションの変更やダウンタイムなしでスケールアップできます。CloudHub は、インテグレーションアプリケーションを構築したり、REST API や Web サービスをパブリッシュしたりできる拡張性の高いアーキテクチャを提供します。 ### [](#anypoint-studio-とのインテグレーション)Anypoint Studio とのインテグレーション [Anypoint Studio (Studio)](https://docs.mulesoft.com/studio/)​ を使用すれば、数回クリックするだけで、インテグレーションアプリケーションを構築して CloudHub にデプロイできます。 プラットフォームを介してデプロイされた他のアプリケーションと同様に、Anypoint Platform に [サインイン](http://anypoint.mulesoft.com)​して Runtime Manager に移動することでアクセスできます。 [「Studio からのアプリケーションのデプロイ」](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub#from-anypoint-platform)​を参照してください。 ### [](#クラウドアプリケーションとエンタープライズアプリケーションのインテグレーション)クラウドアプリケーションとエンタープライズアプリケーションのインテグレーション CloudHub ​[Anypoint Virtual Private Cloud (Anypoint VPC)](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud)​ では、IPsec VPN トンネル、Anypoint VPC ピアリング、トランジットゲートウェイ、または AWS Direct Connect を介してオンプレミスアプリケーションへのセキュアなパイプを作成できます。 ### [](#cloudhub-api)CloudHub API タスクを自動化したり、CloudHub に自動的にデプロイしたりするには、 [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api)​ を使用します。これにより、アプリケーションの管理、監視、スケーリングなどのタスクを実行できます。 ## [](#アプリケーションの管理)アプリケーションの管理 ![管理](/mulesoft/current/ja-jp/cloudhub/_images/logo-manage.png) 現在 CloudHub で実行されているアプリケーションを管理する方法について説明します。 - [「デプロイ済みアプリケーションの管理」](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications)​では、すべてのアプリケーション (CloudHub にデプロイされているアプリケーションとオンプレミスサーバーにデプロイされているアプリケーション) に関する情報を提供します。 - [「CloudHub でのアプリケーションの管理」](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub)​では、CloudHub のアプリケーションに固有の設定に関する情報を提供します。 ### [](#runtime-manager-でのアプリケーションの管理)Runtime Manager でのアプリケーションの管理 アプリケーションのあらゆる側面をすべて 1 か所で​[管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications)​および​[監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring)​できる直感的なクラウドコンソールの ​[Runtime Manager](https://docs.mulesoft.com/jp/runtime-manager/)​ を介して CloudHub のアプリケーションを維持管理します。
US プラットフォームの status.mulesoft.com​ では、Runtime Manager コンソール、プラットフォームサービス、CloudHub ワーカークラウドのライブ状況と詳細なサービス履歴を表示できます。 EU プラットフォームの場合は eu1-status.mulesoft.com​ を参照してください。
## [](#アプリケーションの監視)アプリケーションの監視 ![監視](/mulesoft/current/ja-jp/cloudhub/_images/logo-monitor.png) Runtime Manager では、さまざまなツールを介して問題の選別、ログの表示、アラートのセットアップ、ダッシュボードの表示などを行うことができます。Runtime Manager で実行中のアプリケーションを監視するさまざまな方法の概要については、​[「アプリケーションの監視」](https://docs.mulesoft.com/jp/runtime-manager/monitoring)​を参照してください。
Unresolved include directive in modules/ROOT/pages/index.adoc - include::partial$heap-dump-note.adoc[]
## [](#制限事項)制限事項 CloudHub にデプロイする場合は、次の制限事項に留意してください。 - CloudHub は、1 時間に送信されるメールが 20 通を超えると、アウトバウンド SMTP トラフィックをブロックします。 ## [](#関連情報)関連情報 - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [CloudHub FAQ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-faq) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) - [高可用性](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric) - [CloudHub ネットワークガイド](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [侵入テストポリシー](https://docs.mulesoft.com/jp/cloudhub/penetration-testing-policies) - [「Cloud Security and Compliance Whitepaper (クラウドセキュリティおよびコンプライアンス)」ホワイトペーパー](https://www.mulesoft.com/lp/whitepaper/saas/cloud-security) - [CloudHub の概要](http://www.mulesoft.com/cloudhub/ipaas-cloud-based-integration-demand) # CloudHub へのデプロイ Mule アプリケーションは以下を使用して CloudHub にデプロイできます。 - [Anypoint Runtime Manager](#deploy-an-application-from-runtime-manager) - [Anypoint Studio](#deploy-an-application-from-studio) - [Anypoint Code Builder](https://docs.mulesoft.com/jp/anypoint-code-builder/int-deploy-mule-apps) - [CloudHub CLI](#deploy-an-application-from-the-command-line) - [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/) - [Mule Maven プラグイン](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub) API プロキシを API Manager から CloudHub に直接デプロイすることもできます。 [「プロキシを設定して CloudHub にデプロイする」](https://docs.mulesoft.com/jp/api-manager/latest/getting-started-proxy#configure_and_deploy_to_cloudhub)​を参照してください。 デプロイ中にエラーが発生した場合に通知をメールで受け取るには、​**「Deployment failed (デプロイに失敗しました)」**​アラートをセットアップします。 [「アラートの作成」](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager#create-an-alert)​を参照してください。 ## [](#runtime-manager-からのアプリケーションのデプロイ)Runtime Manager からのアプリケーションのデプロイ Runtime Manager から CloudHub にデプロイする手順は、次のとおりです。 1. Anypoint Platform にサインインします。 2. **\[Runtime Manager\]**​ を選択します。 3. **\[Applications (アプリケーション)\]**​ ページで ​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ページが表示されます。 ![「Application Name (アプリケーション名)」 項目、「Choose file (ファイルを選択)」 メニュー、「Deploy Application (アプリケーションをデプロイ)」 ボタン](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-deploy-app.png) 4. アプリケーションの名前を入力します。 [\[Application Names\]](<#Application Names>)​を参照してください。 5. **\[Deployment Target (デプロイメント対象)\]**​ メニューで、​**\[CloudHub\]**​ がまだ選択されていなければ選択します。 6. アプリケーションファイルを指定します。 - Exchange からファイルをインポートします。 1. **\[Choose file (ファイルを選択)\]**​ > ​**\[Import file from Exchange (Exchange からファイルをインポート)\]**​ を選択します。 2. 種別には ​**\[Application (アプリケーション)\]**​ を選択します。 3. 検索ボックスにアプリケーションの名前を入力します。 4. デプロイするアプリケーションを選択し、​**\[Version (バージョン)\]**​ メニューからバージョンを選択して、​**\[Select (選択)\]**​ をクリックします。 - アプリケーションのアーカイブ (ZIP または JAR) ファイルをアップロードします。 1. **\[Choose file (ファイルを選択)\]**​ > ​**\[Upload file (ファイルをアップロード)\]**​ を選択します。 2. アップロードするファイルを選択して ​**\[Open (開く)\]**​ をクリックします。 アプリケーションファイルのサイズ制限は 200 MB です。 - 非本番環境からアプリケーションをコピーします。 [\[Copy an Application from Sandbox to Production\]](<#Copy an Application from Sandbox to Production>)​を参照してください。 7. タブをクリックしてアプリケーションオプションを設定します。 [\[Configure Application Settings\]](<#Configure Application Settings>)​を参照してください。 8. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#studio-からアプリケーションをデプロイする)Studio からアプリケーションをデプロイする アプリケーションを Studio から CloudHub に直接デプロイできます。 この操作は、アプリケーションを開発中にテストしたい場合に便利です。

アプリケーションは Studio から ​[Design (設計)]​ を除くすべての環境にデプロイできます。

Studio から CloudHub にデプロイする手順は、次のとおりです。 1. Studio でアプリケーションを開きます。 2. **Package Explorer**​ でプロジェクトフォルダーを右クリックして、​**\[Anypoint Platform\] > \[Deploy to CloudHub (CloudHub にデプロイ)\]**​ を選択します。 3. Studio から初めてデプロイする場合は、確認ダイアログで Anypoint Platform ログイン情報を入力します。 Studio では、将来の使用のためにログイン情報を保存します。 このログイン情報は、​**\[Anypoint Studio\] > \[Preferences (プリファレンス)\] > \[Anypoint Studio\] > \[Authentication (認証)\]**​ を選択して管理できます。 サインインしたら、​**\[Deploying Application (アプリケーションのデプロイ)\]**​ ページが表示されます。 ![「Application Name (アプリケーション名)」 項目、「Deploy Application (アプリケーションをデプロイ)」 ボタン](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-deploy-app-studio.png) Figure 1. このスクリーンショットは、​**\[Deploying Application (アプリケーションのデプロイ)\]**​ ページの (​**1**​) ​**\[Application Name (アプリケーション名)\]**​ 項目、(​**2**​) ​**\[Deploy Application (アプリケーションをデプロイ)\]**​ ボタンを示しています。 4. 必要に応じて、アプリケーション名を変更します。 5. タブをクリックしてアプリケーションオプションを設定します。 [アプリケーション設定の定義](#configure-application-settings)​を参照してください。 6. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#コマンドラインからアプリケーションをデプロイする)コマンドラインからアプリケーションをデプロイする CloudHub コマンドラインユーティリティ (CLI) から Mule アプリケーションをデプロイする手順は、次のとおりです。 1. まだ Anypoint コマンドラインツールにアクセスできない場合は、インストールしてください。 [「Anypoint Platform CLI」](https://docs.mulesoft.com/jp/anypoint-cli/latest/)​を参照してください。 2. コマンドラインから Anypoint Platform アカウントにログインします。 1. ユーザー名を入力します。 `anypoint-cli --username="user"` 2. 確認ダイアログで、パスワードを入力します。 3. 次のコマンドを、​`myMuleApp`​ をアプリケーションのデプロイメント名に、​`/Users/exported-app-folder/my-mule-app.jar`​ をファイルシステムのデプロイ可能アーカイブ (JAR または ZIP) ファイルに置き換えて実行します。 runtime-mgr cloudhub-application deploy myMuleApp /Users/exported-app-folder/my-mule-app.zip コマンドラインユーティリティにデプロイメント情報のテーブルが表示されます。 Deploying myMuleApp ... ┌──────────────────────────────┬────────────────────────────────────────┐ │ Domain │ mymuleapp.cloudhub.io │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Status │ UNDEPLOYED │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Updated │ a few seconds ago │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Runtime │ 4.1.0 │ ├──────────────────────────────┼────────────────────────────────────────┤ │ File name │ my-mule-app.zip │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Persistent queues │ false │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Persistent queues encrypted │ false │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Static IPs enabled │ false │ ├──────────────────────────────┼────────────────────────────────────────┤ │ Monitoring │ Enabled. Auto-restart if not responding│ ├──────────────────────────────┼────────────────────────────────────────┤ │ Workers │ 1 vCore \* 1 │ CloudHub にアプリケーションをデプロイしたら、Runtime Manager で表示して管理できるようになります。 4. コマンドラインからアプリケーションを停止する場合は、次のコマンドを、​`app-name`​ をアプリケーションのデプロイメント名に置き換えて実行します。 `runtime-mgr cloudhub-application stop app-name` コマンドラインツールを終了するには、Ctrl+c を 2 回押します。 コマンドの完全なリストについては、​[「Anypoint Platform CLI」](https://docs.mulesoft.com/jp/anypoint-cli/latest/)​を参照してください。 ## [](#sandbox-環境から本番環境にアプリケーションをコピーする)Sandbox 環境から本番環境にアプリケーションをコピーする Sandbox 環境でアプリケーションを作成してテストする場合、デプロイする前に本番環境に移動する必要があります。 環境間でアプリケーションを移動するには、CloudHub Admin (CloudHub 管理者) ロールが必要です。 名前の競合を避けるために、別の環境にデプロイする前にアプリケーションの名前を変更してください。 Runtime Manager では、1 つの環境内でアプリケーションを重複できないため、アプリケーションを、それがすでに含まれている環境に移行することはできません。 アプリケーションを 1 つの環境で重複させるには、デプロイする前に 1 つのアプリケーションのファイル名を変更します。 Sandbox から本番環境にアプリケーションを移動する手順は、次のとおりです。 1. Anypoint Platform にサインインします。 2. **\[Runtime Manager\]**​ を選択し、本番環境に切り替えます。 [「Runtime Manager を使用した環境の切り替え」](https://docs.mulesoft.com/jp/runtime-manager/runtime-manager-switch-env#switch-environments-using-runtime-manager)​を参照してください。 3. **\[Applications (アプリケーション)\]**​ ページで ​**\[Deploy application (アプリケーションをデプロイ)\]**​ をクリックします。 **\[Deploy Application (アプリケーションをデプロイ)\]**​ ページが表示されます。 ![「Application Name (アプリケーション名)」 項目、「Get from sandbox (Sandbox から取得)」 ボタン、「Deploy Application (アプリケーションをデプロイ)」 ボタン](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-deploy-app-sandbox.png) 4. 本番環境でアプリケーションの一意の名前を付けて、​**\[Get from sandbox (Sandbox から取得)\]**​ をクリックします。 このボタンは、非本番環境が存在しない場合は使用できません。 5. Sandbox 環境を選択し、本番環境に移動するアプリケーションを選択します。 他の CloudHub ワーカーに移動できるのは現在 CloudHub にデプロイされているアプリケーションのみであるため、CloudHub にデプロイされているアプリケーションのみがリストに表示されます。 たとえば、現在ローカルサーバーにデプロイされているアプリケーションを CloudHub に移動することはできません。 6. 環境変数と Mule バージョンをコピー元のアプリケーションからコピーするには、​**\[Merge environment variables and mule version (環境変数と Mule バージョンのマージ)\]**​ を使用します。 送信元アプリケーションに安全な隠しアプリケーションプロパティが含まれている場合、​**\[Properties (プロパティ)\]**​ タブで再定義する必要があります。 安全な隠しアプリケーションプロパティについては、​[「アプリケーションプロパティを安全に隠す」](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties)​を参照してください。 7. **\[Apply (適用)\]**​ をクリックします。 8. タブをクリックしてアプリケーションオプションを設定します。 [アプリケーション設定の定義](#configure-application-settings)​を参照してください。 9. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 ## [](#アプリケーション名)アプリケーション名 アプリケーション名では、3 ~ 42 文字の英数字 (a-z、A-Z、0-9) とハイフン (-) を使用できます。 スペースやその他の文字を含めることはできません。
アプリケーションのデプロイ後は名前を変更することはできません。名前を変更するには、削除してから新しい名前でアプリケーションを再デプロイしてください。
アプリケーション名は、Runtime Manager だけでなく、公開 ​`cloudhub.io`​ ドメインでもアプリケーションを識別するものです。 たとえば、​`myapplication`​ という名前のアプリケーションには ​`http://myapplication.cloudhub.io`​ でアクセスできます。 ドメインの競合を避けるには、アプリケーション名は CloudHub 全体でグローバルに一意である必要があります。 そのため、一意のアプリケーション名になる命名規則を作成してください。 たとえば、​`mycompany-mydept-myapplication`​ のように会社名と部署をすべてのアプリケーション名の前に付けることもできます。 そして、DNS レコードを追加して、複雑なアプリケーション名を非表示にすることができます。 たとえば、​`myapplication.mycompany.com`​ に対する要求を ​`mycompany-mydept-myapplication.cloudhub.io`​ にルーティングすることもできます。 CloudHub の専用ロードバランサーを使用すると、マッピングルールを実装し、アプリケーションの公開 URL を、その他のパスに設定することもできます (ただし、そのドメインを所有している場合に限ります)。 [「マッピングルール」](https://docs.mulesoft.com/jp/cloudhub/lb-mapping-rules)​を参照してください。 ## [](#アプリケーション設定の定義)アプリケーション設定の定義 **\[Deploy Application (アプリケーションのデプロイ)\]**​ ページのタブをクリックして、アプリケーションデプロイメントを設定できます。 ![「Deploy Application (アプリケーションのデプロイ)」 ページの設定タブ](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-deploy-app-config-tabs.png) Figure 2. 矢印は、​**\[Deploy Application (アプリケーションのデプロイ)\]**​ ページの設定タブを示しています。 - [ランタイム](https://docs.mulesoft.com/jp/cloudhub/%3C#Runtime Tab Settings>) - [自動スケーリング](https://docs.mulesoft.com/jp/cloudhub/%3C#Autoscaling Tab Settings>) - [プロパティ](https://docs.mulesoft.com/jp/cloudhub/%3C#Properties Tab Settings>) - [インサイト](https://docs.mulesoft.com/jp/cloudhub/%3C#Insight Tab Settings>) - [Logging (ログ)](https://docs.mulesoft.com/jp/cloudhub/%3C#Logging Tab Settings>) - [静的 IP](https://docs.mulesoft.com/jp/cloudhub/%3C#Static IPs Tab Settings>) ### [](#runtime-ランタイム-タブの設定)\[Runtime (ランタイム)\] タブの設定 **\[Runtime (ランタイム)\]**​ タブには、次の設定が含まれています。 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 (ランタイムバージョン)\]**​ ドロップダウンリストでは、更新が利用できるかどうか、およびアプリケーションの以前のバージョン、最新バージョン、推奨バージョンが示されます。​**\[Release Channel (リリースチャネル)\]**​ ドロップダウンリストを使用して、従来バージョンに変更します。 拡張サポートで Edge または LTS バージョンを使用している既存のアプリケーションでは、バージョンの EOL を示す警告メッセージが表示されます。 ランタイムバージョン ランタイムバージョンは、アプリケーションの開発で使用された Mule バージョンと同じである必要があります。 アプリケーションをデプロイすると、選択したランタイムバージョンの更新が使用可能になったときに CloudHub によって自動的にアラートされます。 [「CloudHub Runtime の継続的な更新」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-app-runtime-version-updates)​を参照してください。 Java バージョン アプリケーションの Java バージョンを選択します。詳細は、[Java サポート](https://docs.mulesoft.com/jp/general/java-support)を参照してください。 Worker size (ワーカーサイズ) [\[Worker Size and vCores\]](<#Worker Size and vCores>)​を参照してください。 ワーカー 複数のワーカーを使用するアプリケーションをデプロイすると、CloudHub は受信トラフィック負荷を、割り当てられたワーカー間で自動的に負荷分散します。 [「クラスタリング」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric)​を参照してください。 リージョン アカウントでグローバルデプロイメントが有効になっている場合は、デプロイメントリージョンを変更できます。 リージョンを変更すると、ドメインが自動的に更新されます。 [「リージョンサービス」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide#regional-services)​を参照してください。 Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動) 監視システムで問題が検出されたときに CloudHub はアプリケーションを自動的に再起動します。 [「アプリケーション監視と自動再起動」](https://docs.mulesoft.com/jp/cloudhub/worker-monitoring)​を参照してください。 Persistent queues (永続的なキュー) アプリケーションで永続的なキューを使用し、入力キューのデータをディスクに保存できます。 永続的なキューを使用すると、メッセージの損失を防ぐことができ、ワークロードを一連のワーカーに分散できます。 [「キューの管理」](https://docs.mulesoft.com/jp/cloudhub/managing-queues)​を参照してください。 永続的なキューを利用する前に、キューを使用するようにアプリケーションをセットアップする必要があります。 [「クラスタリング」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric)​を参照してください。 Encrypt persistent queues (永続的なキューを暗号化) 永続的なキューを有効にすると、必要に応じてディスク上の入力キューに保存したデータを暗号化できます。 Object Store v2 の使用 Mule 4 では、Object Store v2 はデフォルトで有効になっています。 Mule 3 では Object Store v2 にアクセスするにはこのオプションを選択します。 [「Object Store V2」](https://docs.mulesoft.com/jp/object-store/)​を参照してください。 Enable Monitoring and Visualizer (Monitoring と Visualizer を有効化) サポートされている Mule バージョンで動作している Mule アプリケーションで Anypoint Monitoring および Visualizer を使用します。 この機能は、組織に Anypoint Integration Advanced パッケージまたは Anypoint Platform の Titanium サブスクリプションがある場合にのみ利用できます。詳細は、​[価格設定およびパッケージ](https://docs.mulesoft.com/jp/general/pricing)​のドキュメントを参照してください。 [「Anypoint Monitoring」](https://docs.mulesoft.com/jp/monitoring/)​および​[「Anypoint Visualizer」](https://docs.mulesoft.com/visualizer/)​を参照してください。 ### [](#autoscaling-自動スケーリング-タブの設定)\[Autoscaling (自動スケーリング)\] タブの設定 自動スケーリングにより、アプリケーションで使用される処理リソースをスケールアップまたはスケールダウンして CPU やメモリの使用量のしきい値に対応するポリシーを定義できます。 このタブは、デフォルトでは表示されません。 詳細は、​[「CloudHub での自動スケーリング」](https://docs.mulesoft.com/jp/cloudhub/autoscaling-in-cloudhub)​を参照してください。 ### [](#properties-プロパティ-タブの設定)\[Properties (プロパティ)\] タブの設定 **\[Properties (プロパティ)\]**​ タブでは、デプロイ時と実行時にアプリケーションで使用されるプロパティ (キー-値ペア) を指定できます。
非本番環境からアプリケーションをデプロイすると (​[Get from sandbox (Sandbox から取得)]​)、新しいアプリケーションは元のアプリケーションで定義されているすべてのプロパティを継承します。 これらのプロパティは、アプリケーションをデプロイする前に必要に応じて ​[Properties (プロパティ)]​ タブで変更できます。
Runtime Manager での非表示も含めてプロパティの指定についての詳細は、​[「CloudHub 上のアプリケーションのプロパティ管理」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-manage-props)​と​[「アプリケーションプロパティを安全に隠す」](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties)​を参照してください。 ### [](#insight-インサイト-タブの設定)\[Insight (インサイト)\] タブの設定 **\[Insight (インサイト)\]**​ タブではインサイト分析機能を有効にしてメタデータオプションを指定できます。 このツールの使用については、​[「インサイト」](https://docs.mulesoft.com/jp/runtime-manager/insight)​を参照してください。 ### [](#logging-ログ-タブの設定)\[Logging (ログ)\] タブの設定 CloudHub には、Runtime Manager から参照またはダウンロードできる活動ログが保存されます。 [「ログデータの表示」](https://docs.mulesoft.com/jp/cloudhub/viewing-log-data)​を参照してください。 アプリケーションのログレベル (​`DEBUG`​、​`WARN`​、​`ERROR`​、または ​`INFO`​) は ​**\[Logging (ログ)\]**​ タブで設定できます。 `log4j2.xml`​ ファイルで ​`level`​ 値を変更することでログレベルを設定することもできます。 [「カスタムログの設定」](https://docs.mulesoft.com/mule-runtime/latest/logging-in-mule#configuring-custom-logging-settings)​と [「Apache ログサービス」](https://logging.apache.org/log4j/2.x/manual/configuration.html)​を参照してください。 ### [](#static-ips-静的-ip-タブの設定)\[Static IPs (静的 IP)\] タブの設定 **\[Static IPs (静的 IP)\]**​ タブを使用して、特定のリージョンにデプロイされているアプリケーションに静的 IP アドレスを割り当てます。 障害回復 (DR) シナリオに対応する複数リージョンの静的 IP アドレスルールを事前に設定することもできます。 アプリケーションに複数のリージョンで割り当てられている静的 IP アドレスがある場合、その静的 IP アドレスはアプリケーションが新しいリージョンにデプロイされたときに割り当てられます。 アプリケーションがすでに実行されている場合、静的 IP アドレスの変更を適用すると、新しく適用された静的 IP アドレスを使用してアプリケーションが再起動されます。 デフォルトでは、組織に割り当てられる静的 IP アドレスの数は、サブスクリプション内の本番 vCore 数の 2 倍であり、​**\[Use Static IP (静的 IP を使用)\]**​ に表示されます。 静的 IP 割り当ての一部を解放する必要がある場合、アプリケーションから未使用の IP アドレスを解放できます。 静的 IP アドレスの割り当てを増やすには、カスタマーサクセスマネージャーに連絡してください。 静的 IP の追加についての詳細は、 [「How to Request Additional Static IPs for your Anypoint Organization (Anypoint 組織の追加の静的 IP を要求する方法)」](https://help.salesforce.com/s/articleView?id=001121221&type=1)​を参照してください。 ## [](#ワーカーサイズと-vcore)ワーカーサイズと vCore 各アプリケーションでワーカーがアプリケーションロジックを実行します。 各ワーカーサイズの計算容量、メモリ容量、およびストレージ容量は異なります。 ワーカーサイズと vCore については、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。 ## [](#デプロイ済みアプリケーションの設定を変更する)デプロイ済みアプリケーションの設定を変更する ほとんどのアプリケーション設定はアプリケーションを CloudHub にデプロイした後に変更できます。 デプロイ済みアプリケーションの設定を編集する手順は、次のとおりです。 1. **\[Applications (アプリケーション)\]**​ タブで、アプリケーション名を選択します。 2. **\[Settings (設定)\]**​ タブをクリックします。 3. 変更を加えて ​**\[Apply Changes (変更を適用)\]**​ をクリックします。 CloudHub により、ダウンタイムなしでアプリケーションが再デプロイされます。
デプロイメントをキャンセルしたり、キャンセルが完了する前に同じアプリケーションで新しいデプロイメントを開始したりすると、1 ~ 3 分のダウンタイムが生じる可能性があります。
## [](#デプロイメントの進行状況)デプロイメントの進行状況 CloudHub によりアプリケーションがアップロードされてデプロイが開始されると、デプロイメントの進行状況を監視できるように CloudHub でユーザーインターフェースが ​**\[Logs (ログ)\]**​ ビューに切り替えられます。 アプリケーションの状況が ​`Deploying`​ に変わり、デプロイメントが進行中であることが示されます。 デプロイメントが完了すると、アプリケーションの状況が ​`Started`​ に変わり、アプリケーションが正常にデプロイされたことを示すメッセージが状況領域とログに表示されます。
Mule Runtime Engine バージョン 4.1.x 以降でアプリケーションをデプロイする場合は、​Gatekeeper​ メカニズムが ​API 自動検出​と連動することで、デプロイメントの準備ができているかどうかを判断します。 アプリケーションの準備がデプロイメントの初期化である 5 分以内に整わないと Gatekeeper が判断した場合、アプリケーションの状況は ​Deploy failed​ になります。
## [](#デプロイメントの失敗)デプロイメントの失敗 エラーが発生し、アプリケーションをデプロイできない場合、アプリケーションの状況が ​`Deploy failed`​ に変わります。 **\[Logs (ログ)\]**​ タブにはアプリケーションのデプロイメントエラーに関する詳細が含まれます。 ## [](#関連情報)関連情報 - [CloudHub 固有の設定の管理](https://docs.mulesoft.com/jp/cloudhub/managing-cloudhub-specific-settings) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [アプリケーションの状況の状態](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications#application_status_states) - [アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [CloudHub REST API](https://docs.mulesoft.com/jp/cloudhub/cloudhub-api) # CloudHub ロードバランサー CloudHub は次の 2 種類のロードバランサーを提供します。 - 共有ロードバランサー 基本的な負荷分散機能を提供します。 - 専用ロードバランサー これを使用すると、Anypoint Virtual Private Cloud (Anypoint VPC) 内で 1 つ以上のカスタムロードバランサーをデプロイおよび設定できます。 ## [](#共有ロードバランサー)共有ロードバランサー CloudHub は、すべての環境で使用できるデフォルトの共有ロードバランサーを提供します。共有ロードバランサーは、TCP 負荷分散などの基本機能を提供します。共有ロードバランサーでは、カスタム SSL 証明書やプロキシルールを設定できません。 また、共有ロードバランサーでは、プラットフォームの安定性を確保できる低いレート制限が設定されます。MuleSoft はこの制限を定期的に監視し、必要に応じて拡大します。共有ロードバランサーのレート制限はリージョンに従って適用されます。アプリケーションを複数のリージョンのワーカーにデプロイしている場合、各リージョンのレート制限が異なる場合があります。 アプリケーションが共有ロードバランサーのレート制限を超えると、ロードバランサーは「429 Service Unavailable (429 サービスは使用できません)」の応答を返します。 カスタムロードバランサー設定を実行するか、レート制限のしきい値を上げるには、専用ロードバランサーを使用する必要があります。 共有ロードバランサーは TLS バージョン 1.1 および TLS 1.2 をサポートします。 ## [](#専用ロードバランサー)専用ロードバランサー 専用ロードバランサーを使用すると、次のことができます。 - アプリケーションを実行するさまざまな CloudHub ワーカー内で負荷分散を処理する。 - カスタム証明書を提供し、必要に応じて双方向 SSL クライアント認証を適用するように SSL 設定を定義する。 - カスタムドメインにアプリケーションをマップするプロキシルールを設定する。 これにより、アプリケーションを 1 つのドメイン下でホストできます。 - CloudHub で API を介して HTTP ストリーミングを有効にします。
アップロードできる最大ファイルサイズは 1000MB です。
専用ロードバランサーは Anypoint Platform の省略可能なコンポーネントです。 専用ロードバランサーについては、​[「専用ロードバランサー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer)​を参照してください。 ## [](#関連情報)関連情報 - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [専用ロードバランサーアーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/lb-architecture) - [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/) - [CloudHub で API を介して DLB ストリーミング機能を有効にする方法](https://help.mulesoft.com/s/article/How-to-Enable-DLB-Streaming-Feature-via-the-API-in-Cloudhub-1-0) # CloudHub 上のアプリケーションのプロパティ管理 CloudHub デプロイメントでは、Anypoint Runtime Manager またはプロパティファイルを使用してプロパティをアプリケーションに追加できます。 アプリケーションのプロパティファイルと Runtime Manager の両方でプロパティを設定してある場合、アプリケーションをデプロイすると、常に Runtime Manager の値がプロファイルファイルの値よりも優先されます。 ## [](#runtime-manager-でアプリケーションのプロパティを追加する)Runtime Manager でアプリケーションのプロパティを追加する CloudHub にデプロイされたアプリケーションにプロパティを読み込む最も簡単な方法は、Anypoint Runtime Manager の ​**\[Properties (プロパティ)\]**​ タブを使用することです。 プロパティを追加する手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. **\[Applications (アプリケーション)\]**​ タブをクリックします。 3. **\[Status (状況)\]**​ 列をクリックして詳細ペインを表示します。 4. **\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 5. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブで以下を行います。 ![\*\[Settings (設定)\]\* ページの \*\[Properties (プロパティ)\]\* タブ、\[Key (キー)\] 項目と \[Value (値)\] 項目、\*\[X\]\* アイコン](_images/cloudhub-app-props.png) Figure 1. このスクリーンショットは、アプリケーションの ​**\[Settings (設定)\]**​ ページの (​**1**​) ​**\[Properties (プロパティ)\]**​ タブ、(​**2**​) ​**\[List (リスト)\]**​ ボタン、(​**3**​) \[Key (キー)\] 項目と \[Value (値)\] 項目、(​**4**​) ​**\[X\]**​ アイコンを示しています。 6. **\[List (リスト)\]**​ をクリックします。 代わりに、​**\[Text (テキスト)\]**​ 項目に ​`key=value`​ の形式でキー-値ペアを入力することもできます。 7. \[Key (キー)\] 項目にプロパティ名を入力します。 8. \[Value (値)\] 項目にプロパティ値を入力します。 Chrome のパスワード保存機能が有効化されていて、\[Key (キー)\] 項目のコンテンツと一致する ​`anypoint.mulesoft.com`​ のユーザー名が保存されている場合、Chrome はそのユーザー名に関連付けられている保存済みパスワードで \[Value (値)\] 項目の値を上書きします。 この制約を回避するには、Chrome をシークレットモードで使用するか、または他のブラウザーを使用してください。 9. キーまたは値を変更するには、項目ないのテキストを編集します。 10. プロパティを削除するには、​**\[X\]**​ をクリックします。 11. **\[Apply Changes (変更を適用)\]**​ をクリックします。 12. 右上のメニューから ​**\[Restart (再起動)\]**​ を選択してアプリケーションを再起動します。 ### [](#例-プロパティを使用した環境変数の設定)例: プロパティを使用した環境変数の設定 Java システム環境変数を指定できます。この機能は、オンプレミスサーバーへのデプロイで環境変数を追加した場合と同じです。 アプリケーションの環境変数も設定できます。 プロパティにより、デプロイ先の環境に応じて変わる設定を外部化することができます。 たとえば、ローカルで Mule アプリケーションを使用している場合は、データベースホストを ​`0.0.0.0`​ に設定する可能性があります。 同じアプリケーションを CloudHub にデプロイする場合は、データベースホストを Amazon RDS サーバーなどに設定することがあります。 アプリケーションプロパティを使用して環境変数を作成または設定する手順は、次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. **\[Applications (アプリケーション)\]**​ タブをクリックします。 3. **\[Status (状況)\]**​ 列をクリックして詳細ペインを表示します。 4. **\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 5. **\[Settings (設定)\]**​ ページで ​**\[Properties (プロパティ)\]**​ タブで以下を行います。 6. **\[Text (テキスト)\]**​ ビューに ​`key=value`​ の形式で変数を入力します。 ![\*\[Settings (設定)\]\* ページの \*\[Properties (プロパティ)\]\* タブ](_images/rtm-env-variables.png) Figure 2. 矢印は ​**\[Settings (設定)\]**​ ページの ​**\[Properties (プロパティ)\]**​ タブの変数を示しています。
[Text (テキスト)]​ ビューでは、バックスラッシュ文字 (​\​) はエスケープ文字として使用します。 たとえば、キーまたは値内で ​:​ を使用するには、構文で ​\:​ を使用します。 キーまたは値内で ​\​ を使用するには、構文で ​\\​ を使用します。 [List (リスト)]​ ビューの構文には、エスケープ文字は必要ありません。
7. Mule アプリケーション設定で環境変数を使用します。 ## [](#プロパティファイルを使用したアプリケーションプロパティの追加)プロパティファイルを使用したアプリケーションプロパティの追加 デプロイ可能なアプリケーションのアーカイブファイルにファイルをインクルードすることで、アプリケーションにプロパティを追加できます。 - プロパティプレースホルダー YAML ファイル (Mule 4) [「プロパティの設定」](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties)​を参照してください。 - `mule-app.properties`​ (Mule 3) [「プロパティの設定」](#3.9@mule-runtime::configuring-properties.adoc)​を参照してください。 これらのプロパティはアプリケーションの起動時に CloudHub によってアプリケーションに読み込まれます。 この方法は CloudHub でのベストプラクティスではありません (CloudHub の ​**\[Properties (プロパティ)\]**​ タブの値によってファイル内の同じ名前を持つすべてのプロパティが上書きされるため) が、Mule アプリケーションのオプションを変更することでこの問題を回避できます。 CloudHub プロパティによって、デプロイ可能なアーカイブにバンドルされたプロパティが上書きされるのを防ぐには、Mule アプリケーションの ​`property-placeholder`​ 要素のオプションを変更します。 デフォルト以外のプロパティプレースホルダーオプションの詳細は、 [プロパティプレースホルダーオプションに関する Spring のドキュメント](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/support/PropertySourcesPlaceholderConfigurer.html)​を参照してください。 ## [](#cloudhub-の予約されたプロパティ)CloudHub の予約されたプロパティ CloudHub では、一部のプロパティが予約されており、これらのプロパティの値は変更できません。 アプリケーションが予約されたプロパティに値を割り当てようとしても、CloudHub はその値を使用しません。 代わりに、エラーや例外をスローすることなく、内部で設定されている値を返し、ログに警告メッセージを追加します。 アプリケーションは、予約されたプロパティを参照して、アプリケーション名やデプロイメントリージョンなどを取得できます。 アプリケーションで Anypoint Platform API コールを実行する場合は、​`${csorganization.id}`​ および ​`${environment.id}`​ プロパティを使用してこれらの値を取得します。 複数ワーカーアプリケーションで各ワーカーを識別するには、​`${worker.id}`​ を使用してください。
${spring.profiles.active}​ および ​${logging.*}​ プロパティは使用しないでください。
プロパティ 説明 例

${java.vendor}

JVM を提供するベンダー

Oracle Corporation

${java.runtime.name}

JVM 名

Java™ SE Runtime Environment

${java.version}

ドット (ポイント) リリースを除外した JVM バージョン。

この値は、CloudHub ランタイムリリースで JDK がアップグレードされると変更されます。

1.8.0_141

${csorganization.id}

メインまたはビジネスグループ ID

09396371-2cd4-412e-8d08-4356dd3e7bfc

${environment.id}

環境 ID

52a69d49e4b0e3c7324ae5b6

${environment.type}

環境種別

本番

${worker.id}

ワーカー ID (複数ワーカーアプリケーション用)

0

${domain}

アプリケーション名

ch-https-41-demo

${fullDomain}

アプリケーションの完全ドメイン名

ch-https-41-demo.au-s1.cloudhub.io

${application.aws.region}

アプリケーションデプロイリージョン

ap-southeast-2

${http.port}

HTTP ポート

8081

${https.port}

HTTPS ポート

8082

${http.private.port}

HTTP 非公開ポート

8091

${https.private.port}

HTTPS 非公開ポート

8092

${mule.home}

Mule インスタンスへの絶対パス

/opt/mule/mule-4.1.1

${spring.profiles.active}

内部で使用、​使用しないでください

***

${logging.*}

内部で使用、​使用しないでください

***

${host}

内部でワーカーのローカル IP アドレスに使用

10.40.122.33

${anypoint.url}

内部で基本 Anypoint Platform URL として使用

US: https://anypoint.mulesoft.com​

MuleSoft Government Cloud: https://gov.anypoint.mulesoft.com

独自の理由により、MuleSoft は予約されたすべての内部プロパティを公開しません。 CloudHub ランタイムリリースの更新により、予約されたプロパティが変更される場合があります。
### [](#予約されていない事前入力されるプロパティ)予約されていない事前入力されるプロパティ 次の 2 つのプロパティの値は事前入力されます。ただし、事前入力された値を上書きすることができます。
プロパティ 説明 例

${app.name}

アプリケーションの ​.jar​ ファイルの名前。

myApplication

${app.home}

実行時のアプリケーションのルートディレクトリ。

/opt/mule/mule-4.3.0/apps/myApplication

### [](#例-予約されたプロパティ値の取得)例: 予約されたプロパティ値の取得 ```xml ``` 出力例: ```console 16:33:08.572 07/02/2020 Worker-0 [cloudhub-reserved-properties].HTTP_Listener_Configuration.worker.01 INFO java.vendor=Oracle Corporation, java.runtime.name=Java(TM) SE Runtime Environment, java.version=1.8.0_141, application.aws.region=ap-southeast-2, http.port=8081, http.ports=8081, mule.home=/opt/mule/mule-4.3.0, csorganization.id=09396371-2cd4-412e-8d08-4356dd3e7bfc, environment.id=52a69d49e4b0e3c7324ae5b6, environment.type=production, worker.id=0, domain=cloudhub-reserved-properties, fullDomain=cloudhub-reserved-properties.au-s1.cloudhub.io ``` ## [](#関連情報)関連情報 - [「プロパティの設定」](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties)​ (Mule 4) - [「プロパティの設定」](#3.9@mule-runtime::configuring-properties.adoc)​ (Mule 3) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [アプリケーションプロパティを安全に隠す](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) # CloudHub 固有の設定の管理 このドキュメントでは、CloudHub にデプロイされたアプリケーションに関する Anypoint Platform の設定について説明します。 これらの設定は、Anypoint Platform の ​[**\[Access Management (アクセス管理)**](https://docs.mulesoft.com/jp/access-management/)\]​ から管理できます。
アクセス管理設定を編集するには、アカウントに ​Cloudhub administrator (Cloudhub 管理者)​ または ​Organization Administrator (組織のシステム管理者)​ のロールが必要です。
## [](#リージョンの管理)リージョンの管理 アカウントでグローバルデプロイメントが有効になっている場合は、デフォルトのリージョンも設定できます。リージョンは、組織のユーザーによってデプロイされたすべてのアプリケーションのデプロイメント画面設定で自動入力され、個々のデプロイメントで必要に応じてアプリケーションレベルで調節できます。 このメニューにアクセスするには、画面上部のユーザー名の横にある歯車アイコンをクリックし、左側のメニューの ​**\[Settings (設定)\]**​ で ​**\[CloudHub\]**​ リンクを選択します。 ![GearGeneral](/mulesoft/current/ja-jp/cloudhub/_images/geargeneral.png)
現在、アカウントでグローバルデプロイメントが有効になっていない場合に有効にするには、MuleSoft アカウントマネージャーにお問い合わせください。
使用可能なリージョンのリストについては、​[「リージョンサービス」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide#regional-services)​を参照してください。 ## [](#cloudhub-のサブスクリプション)CloudHub のサブスクリプション 最初に CloudHub にサインアップすると、自動的に無料プラン (サブスクリプションレベル) に追加されます。有料プランにアップグレードするには、MuleSoft アカウントマネージャーにお問い合わせください。 サブスクリプションレベルと使用状況を表示するには画面上部の歯車アイコンをクリックし、​**\[Subscription (サブスクリプション)\]**​ をクリックします。 ![\[Subscription (サブスクリプション)\]](_images/subscription.png) 次の ​**\[Subscription (サブスクリプション)\]**​ の例では、本番環境では使用可能な 20 vCore のうち 13.1 vCore を使用しており、Sandbox 環境では使用可能な 20 vCore のうち 2 vCore を使用していることが表示されています。 ![SubscriptionLevel](/mulesoft/current/ja-jp/cloudhub/_images/subscriptionlevel.png)

ワーカーの数はアプリケーションの数と同じではありません。 ワーカーのサイズ変更についての詳細は、​「高可用性」​と​「CloudHub ワーカー」​を参照してください。

vCore 処理使用状況には、実行中のアプリケーションのみが計数されます。 `Stopped`​ アプリケーションは、vCore の可用性をコンシュームしません。 ## [](#プランの変更)プランの変更 プランを変更するには、アカウントの担当者またはカスタマーサクセスマネージャーに問い合わせてください。 ## [](#関連情報)関連情報 - [環境](https://docs.mulesoft.com/jp/access-management/environments) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub のプランと価格設定](http://www.mulesoft.com/cloudhub/pricing) # CloudHub 高可用性および障害回復 CloudHub は高可用性 (HA) と、アプリケーションおよびハードウェアの障害に対する障害回復を提供します。 CloudHub はそのインフラストラクチャで Amazon AWS を使用しているため、可用性は Amazon に依存します。CloudHub の可用性とデプロイメントはさまざまなリージョンに分割され、各リージョンは、対応する Amazon リージョンを参照します。Amazon リージョンがダウンすると、そのリージョン内のアプリケーションは使用できなくなり、他のリージョンに自動的に複製されません。 たとえば、米国東部リージョンが使用できない場合、CloudHub の管理 UI だけでなく、デプロイメントを可能にするさまざまな REST サービスも、リージョンの可用性が復元されるまで使用できません。 米国東部がダウンしている間は、新しいアプリケーションをデプロイできません。 コントロールプレーンが使用できない間、ランタイムプレーンでは引き続きログデータをはじめとするテレメトリーデータが送信され、ワーカーはコントロールプレーンが再び使用できるようになるまでこれらのテレメトリーデータをバッファします (最大 1 GB)。 CloudHub は、メッセージの信頼性確保を目的として使用する永続的なキューの形式で内部メッセージングメカニズムを提供します。 永続的なキューは、リージョン内での可用性は高くなりますが、リージョンまたはその一部が (通常は数秒から数分) 使用できなくなると、永続的なキューにアクセスできなくなり、一部のデータが失われることがあります。 リージョンが再び使用できるようになると、CloudHub はキューとの通信を再開します。 デプロイ先のリージョンに関係なく、すべてのアプリケーションの一部の CloudHub Module (Anypoint Object Store v1 など)、アプリケーション設定、および Insight 関連の情報は、米国東部リージョンでは維持されます。Anypoint Object Store v2 は、デプロイされた CloudHub アプリケーションと同じリージョンで維持されます。Anypoint Object Store v1 および v2 では、リージョンを使用できなくなった場合もデータは保持され、リージョンが復旧すると再度使用可能になります。 Anypoint Virtual Private Cloud (Anypoint VPC) はリージョンレベルでセットアップされます。このため、リージョンを使用できない場合、他のリージョンで以前の Anypoint VPC インスタンスのセットアップが完了していない限り、Anypoint VPC は使用できません。 ## [](#anypoint-cloudhub-のデフォルトデプロイメントモデル)Anypoint CloudHub のデフォルトデプロイメントモデル アプリケーションで複数のワーカーを使用する場合、CloudHub はデフォルトで個別の可用性ゾーンにワーカーをデプロイし、可用性ゾーン全体に対して HA を提供します。可用性ゾーン間の距離は可変であり、一般に 350 マイル以上離れることはありません。 ![hadr am web services](/mulesoft/current/ja-jp/cloudhub/_images/hadr-am-web-services.png) アプリケーションが 1 つのワーカーのみを使用している場合、可用性ゾーンが使用できなくなると、CloudHub はそのアプリケーションを別の可用性ゾーンで自動的に再起動します。 この場合は、アプリケーションのダウンタイムが発生することがあります。 可用性ゾーンまたはリージョンで障害が発生したときにアラートを受信するように ​`status.mulesoft.com`​ をセットアップできます。 ## [](#推奨の代替デプロイメントモデル)推奨の代替デプロイメントモデル ロードバランサー (クラウドまたはオンプレミス) を使用すると、さまざまなリージョンにデプロイされたアプリケーションでより適切な障害回復戦略を提供できます。 ![hadr load balancer](/mulesoft/current/ja-jp/cloudhub/_images/hadr-load-balancer.png) ## [](#ステートレスなインテグレーション)ステートレスなインテグレーション インテグレーションがステートレスになるようにしてください。クライアントの呼び出しや実行 (スケジュールされたサービスの場合) の間でトランザクション情報を共有しないということです。システムの制限により一部のデータをミドルウェアで維持する必要がある場合は、ミドルウェアのインフラストラクチャまたはメモリ内ではなく、外部ストア (データベース、メッセージキューなど) でデータを保持する必要があります。 特にクラウド内で規模を拡大する場合、各ワーカーやノードの状態および各ワーカーやノードで使用するリソースが他のワーカーから独立するようにしてください。このモデルでは、パフォーマンスと拡張性だけでなく信頼性も向上します。 ### [](#関連情報)関連情報 - [高可用性および障害回復](https://docs.mulesoft.com/hosting-home/hadr-guide) - [Anypoint Object Store v2](https://docs.mulesoft.com/jp/object-store/) # CloudHub 高可用性機能 CloudHub 高可用性 (HA) 機能を使用すると、CloudHub のアプリケーションで拡張性、ワークロードの分散、信頼性の向上を実現できます。この機能は、CloudHub の拡張性の高い負荷分散サービス、ワーカーのスケールアウト、永続的なキュー配置機能によって提供されます。 新しいアプリケーションをデプロイするときや、既存のアプリケーションを再デプロイするときに Anypoint Runtime Manager コンソールを使用して、アプリケーションごとに HA 機能を有効にできます。 ## [](#前提条件)前提条件 CloudHub HA では、以下が必要です。 - この機能を使用できるようにする CloudHub Enterprise または Partner アカウント種別。 - Runtime Manager コンソールを使用したアプリケーションのデプロイについての理解。 ## [](#ワーカーのスケールアウト)ワーカーのスケールアウト CloudHub では、アプリケーションのワーカーの容量とサイズを選択して、水平拡方向に拡張できます。このように計算能力のプロビジョニングを詳細に制御できるため、高い負荷に対処する場合はアプリケーションをスケールアップし、負荷が低い期間はスケールダウンするという作業を任意のタイミングで柔軟に行うことができます。 **\[workers (ワーカー)\]**​ の横にあるドロップダウンメニューを使用して、アプリケーションのワーカーの数とサイズを選択し、必要な計算能力を設定します。 サブスクリプションに応じて、任意の種類の最大 8 個のワーカー、アプリケーションごとに最大 128 個の vCore でアプリケーションをデプロイできます。 十分なリソースがあることを確認するには、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。 ワーカーのスケールアウトにより、信頼性も向上します。Mule Runtime Engine (Mule) は、自動的に同じアプリケーションで複数のワーカーを 2 つ以上のデータセンターで分散し、最大限の信頼性を確保します。 アプリケーションを 2 つ以上のワーカーにデプロイすると、それらの Mule インスタンスでワークロードを分散できます。CloudHub では、以下が提供されます。 1. HTTP 負荷分散サービス。割り当てたワーカーで HTTP 要求を自動的に分散します。 2. 永続的なメッセージキュー (下記参照) バッチジョブは、一度に 1 つのワーカーでのみ実行され、複数のワーカーで分散できません。 同じデプロイメントで Mule が再起動すると、その状況は保持され、バッチの処理が続行されます。バッチの実行中にアプリケーション全体が更新または再デプロイされると、残りのバッチジョブは続行されません。CloudHub の永続的なバッチジョブの主な解決策は、クラウドオブジェクトストアを使用することです。 ## [](#永続的なキュー)永続的なキュー 永続的なキューにより、メッセージの損失がなくなり、ワークロードを一連のワーカーで分散できます。 - アプリケーションを複数のワーカーにデプロイする場合、永続的なキューを使用すると、ワーカー間の通信とワークロードの分散を実現できます。たとえば、大きなファイルがキューに配置された場合、ワーカーはこれを分割して並列で処理できます。 - 永続的なキューでは、大きな利害が関係する処理のメッセージセキュリティが追加されており、1 つ以上のワーカーまたはデータセンターがダウンしても、メッセージが確実に配信されます。 - アプリケーションで永続的なキューが有効になっていると、実行時に Runtime Manager コンソールの ​**\[Queues (キュー)\]**​ タブでキューを表示できます。 - すべての永続的なキューで保存時のデータの暗号化を有効にできます。この機能を有効にすると、永続的なキューに書き込まれる共有アプリケーションデータが暗号化され、セキュリティとコンプライアンスのニーズを満たすことができます。 - 永続的なキューのメッセージの保持期間は最大 4 日です。永続的なキューのメッセージのサイズや数に制限はありません。 - ワーカーの永続的なキューは、ワーカーと同じリージョンにあります。 永続的なキューでは 1 回のみのメッセージ配信は保証されません。重複するメッセージが送信される場合もあります。1 回のみのメッセージ配信が重要なユースケースの場合、永続的なキューを有効にしないでください。 アプリケーションでの永続的なキューの動作についての詳細は、​[「キューの管理」](https://docs.mulesoft.com/jp/cloudhub/managing-queues)​を参照してください。 ## [](#cloudhub-ha-機能の有効化)CloudHub HA 機能の有効化 次の 2 つのいずれかの方法で CloudHub HA の機能のいずれかまたは両方を有効/無効にできます。 - 初めてアプリケーションを CloudHub にデプロイするときに Runtime Manager コンソールを使用する - 以前にデプロイされたアプリケーションの Runtime Manager コンソールで ​**\[Deployment (デプロイメント)\]**​ タブにアクセスする 1. **\[Workers (ワーカー)\]**​ の横で、ドロップダウンメニューからオプションを選択し、アプリケーションに割り当てられているワーカーの数と種別を定義します。 複数のワーカーへのデプロイについての詳細は、​[「CloudHub ワーカー」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers)​を参照してください。 アプリケーションをクリックして概要を表示し、​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。​**\[Settings (設定)\]**​ をクリックして ​**\[Persistent Queues (永続的なキュー)\]**​ チェックボックスをオンにし、キューの永続性を有効にします。 アプリケーションがすでにデプロイされている場合、新しい設定を有効にするには、再デプロイする必要があります。 ## [](#ha-の実装方法)HA の実装方法 HTTP 負荷分散は、内部リバースプロキシサーバーで実装されます。アプリケーション (ドメイン) URL ​`http://appname.cloudhub.io`​ への要求は、自動的にすべてのアプリケーションのワーカー URL で負荷分散されます。 クライアントは、ワーカーの直接 URL を使用してアプリケーションのロードバランサーをバイパスできます。特定の CloudHub ワーカーでアプリケーションにアクセスする方法についての詳細は、​[「CloudHub ネットワークガイド」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide)​を参照してください。 ## [](#ユースケース)ユースケース 単一のアプリケーションでは、HA 機能のどちらか片方または両方を使用する、あるいはどちらも使用しないように選択できます。 - 永続的なキューを利用するには、この機能をサポートするように Mule アプリケーションを設定します。詳細については、「​[永続的なキューをサポートする Mule アプリケーションの構築](#永続的なキューをサポートする-mule-アプリケーションの構築)​」を参照してください。 - 永続的なキューを有効にすると、パフォーマンスに影響があります。小さなメッセージ (50KB 以下) をキューに配置する場合は 10 ~ 20 ミリ秒 (ms) かかりますが、同じメッセージをキューから取り出す場合は 70 ~ 100 ミリ秒かかります。 - ワーカーを追加すると、サービスのコストが増加します。
ユースケース 推奨される HA 設定 影響

アプリケーションをスケールアウトしたいが、サービスの中断とメッセージの損失については、既存の可用性の高い CloudHub アーキテクチャに満足している。

永続的なキューを有効にしない。

ワーカーの数: 2 つ以上

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

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

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

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

永続的なキューを有効にする。

ワーカーの数: 1

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

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

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

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

永続的なキューを有効にする。

ワーカーの数: 2 つ以上

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

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

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

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

永続的なキューを有効にしない。

ワーカーの数: 1

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

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

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

## [](#バッチジョブが含まれるアプリケーションの永続的なキュー)バッチジョブが含まれるアプリケーションの永続的なキュー バッチジョブが含まれるアプリケーションを永続的なキューが有効になっている CloudHub にデプロイする場合、バッチジョブは CloudHub の永続的なキューを使用して、バッチキュー機能を実現します。 永続的なキューを有効にする場合、次の制限事項に留意してください。 - CloudHub の永続的なキューを使用すると、バッチジョブのレイテンシーが増加します。 パフォーマンスを向上させるには、永続的なキューを無効にしてください。 - CloudHub の永続的なキューは、複数回メッセージを処理することがあります。 メッセージが 1 回だけ処理されるようにするには、永続的なキューを無効にしてください。 - アプリケーションが再起動されると、メッセージの損失が起こる場合があります。 これらの制限事項を踏まえて、Mulesoft ではバッチジョブについては永続的なキューを無効にすることをお勧めします。 バッチジョブの永続的なキューを無効にするには、次のプロパティをアプリケーションに追加します。 ```xml batch.persistent.queue.disable=true ``` デフォルトでは、このプロパティの値は ​`false`​ です。 true に設定すると、アプリケーションではバッチジョブに永続的なキューが使用されませんが、他の Mule コンポーネントについては永続的なキューが有効なままになります。 ## [](#永続的なキューをサポートする-mule-アプリケーションの構築)永続的なキューをサポートする Mule アプリケーションの構築 アプリケーションで永続的なキューの利点を得るには、信頼性パターンをアプリケーションコードに実装して、個々の XA トランザクションを VM トランスポートから分離します。詳細は、​[「信頼性パターン」](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns)​を参照してください。 ![信頼性パターン](/mulesoft/current/ja-jp/cloudhub/_images/ch-fabric.png) 信頼性の高い取得フローでは、インバウンド HTTP Connector からアウトバウンド VM エンドポイントにメッセージが確実に配信されます。信頼性の高い取得フローでメッセージを VM キューに配置できない場合、クライアントが要求を再試行できるように「要求失敗」応答をクライアントに返して、メッセージの損失を回避します。 アプリケーションロジックフローでは、インバウンド VM エンドポイントからアプリケーションのビジネスロジック処理にメッセージが配信されます。このフローは、1 つのトランザクションを表します。各自のビジネスロジックには、表示されていない他のトランザクションがいくつか含まれる可能性があります。 信頼性の高い取得フローでコミットされたメッセージは、アプリケーションロジックフローで処理する準備が整うまで、これらの 2 つのフローの間にある永続的な VM キューで保持されます。トランザクション内で処理エラーが発生した場合や、トランザクションがタイムアウト (トランザクションに割り当てられている時間を超過) した場合、Mule はロールバックをトリガーします。このロールバックにより、メッセージで行われた部分的な処理が消去され、メッセージがキューに戻ります。Mule インスタンスが停止した場合や、トランザクションを明示的にロールバックできない場合、トランザクションに割り当てられている時間を超えると、トランザクションが自動的にロールバックします。割り当て時間は、トランザクション要素の ​`timeout`​ 属性によって決まります。自分でタイムアウトを設定することも、デフォルトを受け入れることもできます。 3 つのステップで各トランザクションを考えるとわかりやすくなります。 1. 開始。Mule は、トランザクション内のすべてのサブコンポーネントの処理を開始します。 2. コミット。Mule は、完了したトランザクションの結果を次のステップに送信します。XA トランザクションの場合、コミットステップは、​_コミット要求フェーズ_​と​_コミットフェーズ_​の 2 つのフェーズになります。コミット要求フェーズでは、Mule はトランザクションのスコープ内の複数の応答の結果を調整し、すべての処理が正常に実行されて、コミットの準備が整っていることを確認します。その後、コミットフェーズで各リソースがコールされ、その処理がコミットされます。 3. ロールバック。「開始」または「コミット」ステップのいずれかでエラーが発生した場合、Mule は部分的な完了がないようにトランザクション内の処理をロールバックします。 次のコードスニペットは、CloudHub でキューの永続性を確保するために VM トランスポートを使用する信頼性パターンでセットアップされたアプリケーションの例です。 ```xml .... ``` ### [](#ハイブリッド-vm-キューと-cloudhub-vm-キューの違い)ハイブリッド VM キューと CloudHub VM キューの違い 次の表に、ハイブリッド VM キューと CloudHub VM キューの主な違いを示します。
オンプレミスアプリケーションの VM キュー CloudHub にデプロイされているアプリケーションの VM キュー

queue-profile 要素を使用して、未処理メッセージの最大数を設定できます。

CloudHub では、未処理メッセージの数に制限はありません。アプリケーションで未処理メッセージの最大数を使用して queue-profile 要素をコーディングしていても、​[Persistent Queues (永続的なキュー)]​ チェックボックスをオンにしてアプリケーションを CloudHub にデプロイすると、未処理メッセージは無制限になります。

queue-profile 要素を使用して、キューの永続性を切り替えることができます。

キューの永続性は、[deployment (デプロイメント)] ダイアログの ​[Advanced Details (高度な詳細)]​ セクションにある ​[Persistent Queues (永続的なキュー)]​ チェックボックスを使用して管理します。アプリケーションで queue-profile 要素をコーディングしていても、​[Persistent Queues (永続的なキュー)]​ チェックボックスをオンにしてアプリケーションを CloudHub にデプロイすると、これらの設定は上書きされます。

使用する VM キューのキューストアを定義できます。

キューストアは CloudHub で管理されるため、キューストアを定義する必要はありません。

XA トランザクションのコミットとロールバックは、2 フェーズコミットアルゴリズムに従って処理されます。

CloudHub でメッセージをキューに追加する場合、XA トランザクションの 2 フェーズコミットアルゴリズムの動作に重要な例外があります。詳細は、以下の既知の問題を参照してください。注意: CloudHub で永続的なキューのメッセージをコンシュームする場合、この 2 フェーズコミットアルゴリズムの例外は適用されません。

## [](#考慮事項)考慮事項 CloudHub でメッセージを VM キューに追加する場合、次の条件を満たすと、XA トランザクションの 2 フェーズコミットプロトコルが失敗し、完了したトランザクションがロールバックされる可能性があります。 - コミット要求フェーズが正常に完了した。トランザクション内の関連するすべての処理が正常に実行されるため、メッセージをキューにコミットできるようになります。 - コミットフェーズでエラーが発生し、トランザクション内のサブプロセスをコミットできなくなり、トランザクションのロールバックがトリガーされる。 - ロールバックが発生する前に VM アウトバウンドエンドポイントでコミットが完了する。 上記の 3 つの条件をすべて満たす場合、メッセージは意図したとおりトランザクションロールバックプロセスでロールバックされる代わりにキューに追加されます。メッセージの損失は発生せず、トランザクションを引き続き繰り返すことができますが、アウトバウンド VM キューに意図しないメッセージが追加されます。
この問題は、VM キューに追加する必要のあるメッセージがフローで生成される場合にのみ発生します。キューのメッセージをコンシュームするプロセスには影響はありません。
## [](#関連情報)関連情報 - [CloudHub ワーカー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture#cloudhub-workers) - [キューの管理](https://docs.mulesoft.com/jp/cloudhub/managing-queues) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) - [トランザクションの管理](https://docs.mulesoft.com/mule-runtime/latest/transaction-management) - [VM Connector](https://docs.mulesoft.com/jp/vm-connector/latest/) - [信頼性パターン](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns) # Log4j を使用したログシステムとのインテグレーション CloudHub のログを無効化して、Log4j 設定を使用して CloudHub アプリケーションをログシステムに統合できます。 ユーザーのログシステムと CloudHub の両方にログが送信されるように設定したら、デフォルトの CloudHub アプリケーションログを無効化してください。 ## [](#要件と制限事項)要件と制限事項 - この機能は要求に応じてのみ使用できます。 Runtime Manager に ​**\[Disable CloudHub logs (CloudHub ログを無効化)\]**​ オプションが表示されていない場合は、 [ヘルプセンター](https://help.mulesoft.com/)​で要求できます。 - MuleSoft のサポートは、カスタムログ設定の実装や、カスタムログ設定に起因する問題の解決については、助言を行いません。 - MuleSoft では、以下のような Log4j アペンダーの設定ミスによる問題については責任を負いません。 - ログデータの消失 - パフォーマンスの低下 - ディスクスペースの不足 - 同期ログアペンダーは使用しないでください。 非同期ログアペンダーのみを使用してください。 - CloudHub ログを無効化すると: - Runtime Manager ではシステムログのみを使用できます。 システムログでは、ワーカーのデプロイ状況と、アプリケーションが適切に起動したかどうかが示されますが、アプリケーションログは提供されません。 アプリケーションワーカーのログについては、アプリケーションのログシステムを確認してください。 - **\[Applications (アプリケーション)\] > \[Logs (ログ)\]**​ ページではアプリケーションワーカーのログをダウンロードできません。 - CloudHub は、ログが使用できないことを示す警告を表示します。 - システムログ (​`mule_ee.log`​) はアプリケーションログと同じ方法で外部ログソリューションに転送することはできません。 ## [](#log4j-設定の作成)Log4j 設定の作成 独自のログシステムにログを送信すると共に CloudHub でもログを表示できるようにするには、CloudHub Log4j アペンダーを設定する必要があります。 任意の Log4j アペンダーを使用できます。​`log4j2.xml`​ の設定については、 [「Log4j の設定構文」](https://logging.apache.org/log4j/2.x/manual/configuration.html#ConfigurationSyntax)​を参照してください。 Log4j アペンダーを有効化するには、​`log4j2.xml`​ 設定ファイルを自分のロガー設定で更新し、Log4j アペンダー ​`Log4J2CloudhubLogAppender`​ および ​`RollingFile`​ を含めます。 Anypoint Studio では、​`log4j2.xml`​ ファイルは ​`src/main/resources`​ ディレクトリにあります。 `log4j2.xml`​ ファイルの Log4j アペンダーの 2 つの例を示します。 Log4J2CloudhubLogAppender ログデータを CloudHub に送信します。 RollingFile ログデータを VM のファイルシステムに送信します。
MuleSoft サポートチームがログを表示できるようにするには、​log4j2.xml​ ファイルのカスタム設定にアペンダーを含める必要があります。
```xml ```
log4j2.xml​ カスタム設定で スクリプト​を使用する必要がある場合は、​log4j2.Script.enableLanguages​ システムプロパティを適宜設定して、使用する言語を有効化してください。値のカンマ区切りリストを指定することで、複数の言語を有効化できます。例: log4j2.Script.enableLanguages=js,groovy​。
## [](#cloudhub-でのカスタム-log4j-設定の有効化)CloudHub でのカスタム Log4j 設定の有効化 Log4j アペンダーを設定したら、アプリケーションを CloudHub にデプロイしてから、以下の手順に従って CloudHub ログを無効化します。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左側のメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 3. **\[Type (種別)\]**​ 列をクリックしてアプリケーションの詳細ペインを表示します。 4. **\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 5. **\[Settings (設定)\]**​ ページで、​**\[Disable CloudHub logs (CloudHub ログを無効化)\]**​ をクリックします。 ![「Applications Settings (アプリケーションの設定)」 ページの 「Disable CloudHub logs (CloudHub ログを無効化)」 オプション](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-disable-logs.png) Figure 1. **\[Settings (設定)\]**​ ページの ​**\[Disable CloudHub logs (CloudHub ログを無効化)\]**​ オプションを示す矢印。 6. **\[Disable CloudHub logs (CloudHub ログを無効化)\]**​ 確認ウィンドウで、CloudHub ログの無効化を確認するためのチェックボックスをオンにします。 ![「Disable CloudHub logs (CloudHub ログを無効化)」 確認ウィンドウ](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-disable-logs-verify.png) Figure 2. **\[Disable CloudHub logs (CloudHub ログを無効化)\]**​ 確認ウィンドウが表示された画面。 7. **\[Apply Changes (変更を適用)\]**​ をクリックします。 8. アプリケーション設定を参照して、設定が正しいことを確認します。 9. **\[Apply Changes (変更を適用)\]**​ をクリックして、アプリケーションを再起動します。 アプリケーションが起動すると、カスタム Log4j アペンダーへのログの送信が開始され、対象ログシステムでログを参照できるようになります。 ## [](#関連情報)関連情報 - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub Log4j ナレッジ記事](https://help.mulesoft.com/s/global-search/%40uri#q=log4j&t=SalesforceArticle&f:@sfdcproduct=) # Runtime Manager でのロードバランサーの作成 Runtime Manager を使用して、CloudHub 環境内に専用ロードバランサー (DLB) を作成できます。 ## [](#前提条件)前提条件 ロードバランサーを作成する前に、以下を実行します。 - ロードバランサーを作成する組織のプロファイルに​**「CloudHub Network Administrator (CloudHub ネットワーク管理者)」**​権限を追加して、プロファイルにこのアクションを実行する権限があるようにする。 同様に、同じ組織のシステム管理者ロールによっても必要な権限が得られます。 - ロードバランサーを作成する組織で Anypoint Virtual Private Cloud (Anypoint VPC) を作成する。 - 少なくとも 1 つの証明書と証明書用の非公開鍵を作成する。 ## [](#ロードバランサーの作成)ロードバランサーの作成 1. Anypoint Platform から ​**\[Runtime Manager\]**​ をクリックします。 2. **\[Load Balancers (ロードバランサー)\]**​ > ​**\[Create Load Balancer (ロードバランサーを作成)\]**​ をクリックします。 3. ロードバランサーの名前を入力します。 CloudHub DLB の名前は、Anypoint Platform で (すべての MuleSoft ユーザーによって) 定義されているすべての DLB で一意である必要があります。 このため、たとえば DLB 名の最後に組織名を付加するなどしてください。
DLB の作成後は名前を変更することはできません。名前を変更するには、削除してから新しい名前で作成し直してください。
各専用ロードバランサーは外部ドメイン名の ​`_lb-name_​.lb.anypointdns.net`​ を公開します。​`_lb-name_`​ はこの手順で入力した名前です。 CloudHub DLB 名の先頭を ​`internal-`​ にすることはできません。 4. ドロップダウンリストから目的の Anypoint VPC を選択します。 5. DLB が Mule アプリケーションからの応答を待つ時間を ​**\[Timeout in Seconds (タイムアウト (秒))\]**​ 項目に入力します。 デフォルト値は 300 秒です。 6. 必要に応じて、許可リストに登録する Classless Inter-Domain Routing (CIDR) を追加します。 ここで指定した IP アドレスのみがロードバランサーにアクセスできる IP アドレスになります。デフォルト値は ​`0.0.0.0/0`​ です。 7. ロードバランサーのインバウンド HTTP モードを選択します。 このプロパティでは、HTTP 要求を受信したときのロードバランサーの動作を指定します。有効な値: - **Off (オフ)** ロードバランサーは要求を警告なしで削除します。 - **On (オン)** デフォルトの SSL エンドポイントで HTTP プロトコルを使用してインバウンド要求を受け入れます。 - **Redirect (リダイレクト)** HTTPS プロトコルを使用して同じ URL に要求をリダイレクトします。 8. オプションを指定します。 - **\[Enable Static IPs (静的 IP を有効化)\]**​ は、DLB を再起動しても変更されない静的 IP を使用するように指定します。 静的 IP アドレスについての詳細は、​[「Static IP Addresses (静的 IP アドレス)」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer#static-ip-addresses)​を参照してください。 - **\[Keep URL encoding (URL エンコードを保持)\]**​ は、DLB が ​`%20`​ および ​`%23`​ 文字のみをそのまま渡すように指定します。 このオプションの選択を解除すると、DLB は要求 URI のエンコードされている部分をデコードしてから CloudHub ワーカーに渡します。 - **\[Support TLS 1.0 (TLS 1.0 をサポート)\]**​ は、クライアントと DLB の間で TLS 1.0 をサポートするように指定します。 TLS 1.0 を使用するには、「​[Runtime Manager を使用した DLB での TLS 1.0 の有効化](#runtime-manager-を使用した-dlb-での-tls-1-0-の有効化)​」を参照してください。 - **\[Upstream TLS 1.2 (アップストリーム TLS 1.2)\]**​ は、DLB とアップストリーム CloudHub ワーカーの間で TLS 1.2 を強制するように指定します。 - **\[Forward Client Certificate (クライアント証明書を転送)\]**​ は、DLB がクライアント証明書を CloudHub ワーカーに転送するように指定します。 9. 証明書を追加します。 1. **\[Add certificate (証明書を追加)\]**​ をクリックします。 ![\[Create Load Balancer (ロードバランサーを作成)\] ページの \[Add certificate (証明書を追加)\] オプション](_images/lb-cert-upload-create.png) Figure 1. **\[Create Load Balancer (ロードバランサーを作成)\]**​ ページの ​**\[Add certificate (証明書を追加)\]**​ オプションを示す矢印。 2. **\[Create Load Balancer (ロードバランサーを作成)\] | \[Add certificate (証明書を追加)\]**​ ページで、​**\[Choose File (ファイルを選択)\]**​ を選択して公開キーファイルと非公開キーファイルの両方をアップロードします。 3. クライアント証明書を追加する場合は、​**\[Choose File (ファイルの選択)\]**​ をクリックしてファイルをアップロードします。 このクライアント証明書は、クライアント証明書を検証するために使用される信頼された CA 証明書です。 4. URL マッピングルールを追加する場合は、​**\>**​ アイコンをクリックしてオプションを表示します。 ![\[Create Load Balancer (ロードバランサーを作成)\] | \[Add certificate (証明書を追加)\] ページの拡張アイコン](_images/lb-create-mapping-rules.png) Figure 2. **\[Create Load Balancer (ロードバランサーを作成)\] | \[Add certificate (証明書を追加)\]**​ ページの拡張アイコンを示す矢印。 複数の URL マッピングルールを追加する場合は、適用する優先度に従ってリスト内のルールの順序を決定します。 **\[Add New Rule (新規ルールを追加)\]**​ をクリックして、入力パス、対象アプリケーション、出力パス、プロトコルを指定します。 5. **\[Save Certificate (証明書を保存)\]**​ をクリックします。 10. **\[Create Load Balancer (ロードバランサーを作成)\]**​ をクリックします。 ## [](#runtime-manager-を使用した-dlb-での-tls-1-0-の有効化)Runtime Manager を使用した DLB での TLS 1.0 の有効化 セキュリティの脆弱性のため TLS 1.0 は推奨されませんが、従来のクライアントとの通信に必要な場合はサポートを有効にできます。 TLS 1.0 のサポートは、DLB のデフォルトの SSL エンドポイントでのみ有効にできます。 TLS 1.0 のサポートの有効化は単一の SSL エンドポイントではなく DLB 全体に適用されます。
セキュリティ上の理由により、TLS 1.0 は有効にしたままにしないでください。 TLS 1.0 が不要になった場合は、デフォルトの暗号化スイートを、たとえば ​NewDefault​ などに置き換えてください。
TLS のサポートを有効にする手順は、次のとおりです。 1. **\[Support TLS 1.0 (TLS 1.0 をサポート)\]**​ オプションを選択します。 2. API を使用して、デフォルトの暗号化スイートを ​`OldDefault`​ に変更します。 [「TLS 1.0 をサポートするようにデフォルトの暗号化スイートを変更する」](https://docs.mulesoft.com/jp/cloudhub/lb-cert-validation#change-the-default-cipher-suite-to-support-tls-1-0)​を参照してください。 ## [](#関連情報)関連情報 - [アクセス管理](https://docs.mulesoft.com/jp/access-management/) - [専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer) - [専用ロードバランサーへの証明書の追加](https://docs.mulesoft.com/jp/cloudhub/lb-cert-upload) - [専用ロードバランサーでの証明書の検証](https://docs.mulesoft.com/jp/cloudhub/lb-cert-validation) - [許可リスト](https://docs.mulesoft.com/jp/cloudhub/lb-allowlists) - [マッピングルール](https://docs.mulesoft.com/jp/cloudhub/lb-mapping-rules) # Runtime Manager の CloudHub 通知 ## [](#概要)概要 **通知**​は、アプリケーションの状況に関する情報を提供するために、Runtime Manager コンソールに表示される標準メッセージです。通知には、コンソールの右上隅にあるベルアイコンを使用してアクセスできます。 新しい通知がある場合は、ベルが赤に変わります。
また、特定のイベントが発生した場合に警告するために、任意のメールアドレスに送信できるメール​アラート​をセットアップすることもできます。通知は現在、CloudHub にデプロイされたアプリケーションのみで生成されます。オンプレミスにデプロイされたアプリケーションの場合はアラートを使用してください。
## [](#通知の管理)通知の管理 各通知には、優先度レベルと、関連付けられたメッセージがあります。通知が特定のアプリケーションに関連付けられている場合は、アプリケーション名も表示されます。 ![AlertMessage](/mulesoft/current/ja-jp/cloudhub/_images/alertmessage.png) 既読のものも含め、すべての通知を表示するには、​**\[Show All Notifications (すべての通知を表示)\]**​ をクリックします。 ## [](#標準通知)標準通知 CloudHub にデプロイされたアプリケーションの場合、いずれかのアプリケーションに特定のイベントが発生することによって通知が自動的に生成されます。
Event (イベント) Message (メッセージ)

Worker will restart (ワーカーが再起動します)

A worker ​<ip>​ has become unresponsive. Restarting the worker. (ワーカー ​<ip>​ が応答しなくなりました。 ワーカーを再起動しています。)

Worker has restarted (ワーカーが再起動しました)

Restart SUCCEEDED for worker ​<ip>​. (ワーカー ​<ip>​ の再起動に成功しました。)

Worker restart failed (ワーカーの再起動に失敗しました)

Restart FAILED for worker ​<ip>​. (ワーカー ​<ip>​ の再起動に失敗しました。)

Maximum Restarts attempted for a worker (ワーカーの再起動を最大回数まで試行しました)

We’ve reached the maximum amount of restart attempts. (再起動の最大試行回数に達しました。)

Worker needs restarting, but restarts are disabled (ワーカーの再起動が必要ですが、再起動が無効になっています)

A worker ​<ip>​ has become unresponsive. Restarts are disabled. (ワーカー ​<ip>​ が応答しなくなりました。 ワーカーの再起動が無効になっています。)

## [](#カスタム通知)カスタム通知 CloudHub にデプロイされたアプリケーションでは、アプリケーションにインストールされている必要がある CloudHub Connector を使用して、カスタム通知を作成できます。 1. [Anypoint Exchange](https://docs.mulesoft.com/jp/exchange/)​ から CloudHub Connector をダウンロードしてください。 ![cloudhub connector](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-connector.png) 2. 何か意味のあることが起きるとトリガーされるよう、CloudHub Connector のインスタンスをプロジェクトのフローに配置します。 3. コネクタを設定します。​**\[Operation (操作)\]**​ 項目で ​**\[Create Notification (通知を作成)\]**​ を選択し、​**\[Domain (ドメイン)\]**​、​**\[Message (メッセージ)\]**​、​**\[Priority (優先度)\]**​ を設定します。 これで通知を受信するようになります。 4. 必要に応じて、いずれかのカスタムイベントが発生したときに、そのことを知らせるメールアラートをセットアップします。メールアラートのセットアップ方法は、​[Runtime Manager のアラート](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager)​を参照してください。カスタム通知に一致する ​**\[Custom Notification Alert (カスタム通知アラート)\]**​ 種別のアラートを作成する必要があります。 チュートリアルを参照してください。 ## [](#通知の保持)通知の保持 通知は、次の制限の (先に生じた) 範囲内で Anypoint Platform によって保持されます。 - 30 日間 - アプリケーションあたり最大 1000 個の通知 ## [](#関連情報)関連情報 - [カスタムアプリケーションアラート](https://docs.mulesoft.com/jp/cloudhub/custom-application-alerts)​のチュートリアル。 - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub の概要](https://docs.mulesoft.com/jp/cloudhub/) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [クラスタリング](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric) - [アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [キューの管理](https://docs.mulesoft.com/jp/cloudhub/managing-queues) - [スケジュールの管理](https://docs.mulesoft.com/jp/cloudhub/managing-schedules) - [オブジェクトストアを使用したアプリケーションデータの管理](https://docs.mulesoft.com/jp/cloudhub/managing-application-data-with-object-stores) - [Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [アプリケーションプロパティの保護](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [侵入テストポリシー](https://docs.mulesoft.com/jp/cloudhub/penetration-testing-policies) # Runtime Manager を使用した VPC の作成と更新 Anypoint VPC を作成する前に、組織には次が必要です。 - Anypoint VPC の購入 - Anypoint VPC を作成および管理するために必要なアカウントの権限 ## [](#anypoint-vpn-を作成する)Anypoint VPN を作成する 1. **Organization Administrators (組織のシステム管理者)**​ ロールを持つユーザーとして Anypoint Platform アカウントにサインインします。 2. **\[Management Center\]**​ で、​**\[Runtime Manager\]**​ をクリックします。 3. 左ナビゲーションで、​**\[VPCs\]**​ をクリックします。 4. **\[Create VPC (VPC を作成)\]**​ をクリックし、次の情報を入力して Anypoint VPC を定義および設定します。 - **Name (名前)**​: Anypoint VPC を識別する名前。 名前は次の条件を満たす必要があります。 - 組織内で一意 - 3 ~ 42 文字 - 小文字、数字、ダッシュのみを含む
VPC の作成後は名前を変更することはできません。名前を変更するには、VPC を削除して作成し直してください。
- **Region (リージョン)**​: Anypoint VPC がバインドされるリージョン。

すべての Anypoint VPC は CloudHub リージョンに関連付けられている必要があります。

- **CIDR Block (CIDR ブロック)**​: クラスレスドメイン間ルーティング (​**CIDR**​) 表記の Anypoint VPC のサイズ。 たとえば、10.111.0.0/24 に設定すると、Anypoint VPC には 10.111.0.0 ~ 10.111.0.255 の 256 個の IP アドレスが付与されます。 理想的なのは、Anypoint VPC 用に選択する CIDR ブロックがプライベート IP 空間から取得されることで、他の Anypoint VPC の CIDR ブロックや企業ネットワーク内で使用されている他の CIDR ブロックと重複しないようにします。

この設定は、Anypoint VPC の最初の作成時のみ可能です。Anypoint VPC インスタンスが作成されたら、サイズの変更や選択した CIDR ブロックの編集はできません。
このパラメーターを設定する前に、ニーズを満たす Anypoint VPC のサイズを適切に指定する方法をよく理解してください。これを設定する方法がわからない場合は、​Anypoint VPC のサイズ指定​ガイドに従ってください。

- **Environments (環境)**​: (省略可能) Anypoint VPC をバインドする環境を選択します。 環境を選択しないと、選択されたリージョンにデプロイされたすべてのアプリケーションがこの Anypoint VPC に関連付けられます。 Anypoint VPC を設計環境に関連付けないでください。Runtime Manager ではなく Design Center でのみアプリケーションを設計環境にデプロイできます。
Anypoint コントロールプレーン間での異なる時間設定によってレート制限エラーが発生するのを防ぐために、サービス間にはキャッシュ期間があります。 アクセス管理で環境を作成し、Runtime Manager ですぐにそれを使用して VPC を編集しようとすると、新しく作成された環境が VPC の ​[Environments (環境)]​ ドロップダウンに表示されるまでに遅延があることがあります。
- **Set as default VPC (デフォルトの VPC として設定)**​: Anypoint VPC を、設定したリージョンのデフォルトに設定する場合はこのオプションを選択します。 これは、Anypoint VPC に関連付けられないこのリージョン内のすべての環境が、この Anpypoint VPC にデフォルトで関連付けられることを意味します。 - **Business Groups (ビジネスグループ)**​: (省略可能) Anypoint VPC をビジネスグループにバインドします。 ビジネスグループを選択しない場合、Anypoint VPC はメイン組織に関連付けられます。これは Anypoint VPC 管理設定で後で変更できます。 ![create vpc](/mulesoft/current/ja-jp/cloudhub/_images/create-vpc.png) 5. **\[Firewall Rules (ファイアウォールルール)\]**​ をクリックして項目を展開し、​[ファイアウォールルールを設定します](https://docs.mulesoft.com/jp/cloudhub/vpc-firewall-rules-concept)​。 デフォルトではすべてのインバウンドトラフィックがブロックされるので、ワーカーへのトラフィックを許可するにはファイアウォールルールを設定する必要があります。これらのルールは後で設定できます。 UI には最も一般的に使用されるファイアウォールルールの候補が事前入力されます。 次の例は、​`Anywhere`​ (任意の場所) からの ​`http.private.port`​ 種別のファイアウォールルールを示しています。ポート範囲は自動的に ​`8091`​ に設定されます。 ![vpc and load balancer creation 97c25](/mulesoft/current/ja-jp/cloudhub/_images/vpc-and-load-balancer-creation-97c25.png) つまり、ポート ​`8091`​ 経由の接続のみが Anypoint VPC 内部の許可リストに登録され、ワーカーはポート ​`8091`​ 経由のすべてのインターフェースをリスンします。 このファイアウォールルールを設定すると、デフォルトの設定を使用して​[専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer)​がワーカーと通信することが許可されます。

さらに、ロードバランサーから適切に要求を受信するには、Anypoint VPC にデプロイされたすべてのアプリケーションがポート ​8091​ をリスンしている必要があります。

6. 必要に応じて ​**\[Internal DNS (内部 DNS)\]**​ オプションをクリックして、プライベートホスト名を解決するよう​[内部 DNS サーバーをセットアップ](https://docs.mulesoft.com/jp/cloudhub/resolve-private-domains-vpc-task)​することができます。 ![vpc tutorial 31341](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-31341.png) これは、Anypoint VPC を最初に作成するときに行うか、後で内部 DNS を設定することができます。 7. **\[Create VPC (VPN を作成)\]**​ をクリックします。 ## [](#anypoint-vpc-に接続する)Anypoint VPC に接続する 設定のステップは、選択した ​[VPC 接続方法](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud#vpc-connectivity-methods-concept)​によって異なります。​[「ネットワークとの Anypoint VPC 接続の申請」](https://docs.mulesoft.com/jp/cloudhub/to-request-vpc-connectivity)​の指示に従ってください。 ## [](#既存の-anypoint-vpc-の更新)既存の Anypoint VPC の更新 ![vpc tutorial c5a66](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-c5a66.png) 1. UI で既存の Anypoint VPC のリストから目的の Anypoint VPC を見つけ、選択します。 2. 次を更新できます。 1. **Environments (環境)**​ ドロップダウンメニューから特定の環境を 1 つ以上選択できます。 ![vpc tutorial 6dea0](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-6dea0.png) 2. **Business Groups (ビジネスグループ)**​ ドロップダウンメニューから 1 つ以上のビジネスグループを選択できます。 ![vpc tutorial 981cc](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-981cc.png) 3. **Firewall Rules (ファイアウォールルール)**​ 既存の​[ファイアウォールルール](https://docs.mulesoft.com/jp/cloudhub/vpc-firewall-rules-concept)​を編集するか、新しいルールを追加します。 ![vpc tutorial fa890](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-fa890.png) 4. **Internal DNS (内部 DNS)**​ 既存の​[内部 DNS 設定](https://docs.mulesoft.com/jp/cloudhub/resolve-private-domains-vpc-task)​を編集するか、新しい設定を追加します。 ![vpc tutorial 0b7b2](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-0b7b2.png) パブリック DNS IP アドレスを設定して ​`enter`​ キーを押すか、青のチェックマークをクリックします。 ![vpc tutorial df177](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-df177.png) DNS サーバーを使用して解決する必要があるプライベートドメインを追加して ​`enter`​ キーを押すか、青のチェックマークをクリックします。 3. 変更が終了したら、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [VPC ファイアウォールルール](https://docs.mulesoft.com/jp/cloudhub/vpc-firewall-rules-concept) - [CloudHub ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/dedicated-load-balancer-tutorial) - [FAQ: 組織内のどこに Anypoint VPC を配置するか](https://docs.mulesoft.com/jp/cloudhub/vpc-provisioning-concept#faq-where-to-place-an-anypoint-vpc-inside-my-organization) - [プライベートドメインの設定](https://docs.mulesoft.com/jp/cloudhub/resolve-private-domains-vpc-task) # SSL エンドポイントと証明書の設定 専用ロードバランサーには、少なくとも 1 つの証明書を関連付ける必要があります。クライアントにサービスを提供するロードバランサー用の SSL エンドポイントを設定するには、ロードバランサー用の証明書と非公開鍵のペアを指定します。 各ロードバランサーには、複数の独立した SSL エンドポイントを設定でき、各エンドポイントはサーバー証明書の一般名によって識別されます。 ## [](#要件)要件 SSL エンドポイントを関連付けるには、次のファイルが必要です。 - 暗号化されていない、PEM (Privacy-Enhanced Mail) でエンコードされた証明書ファイル。 - PEM 証明書の非公開鍵が含まれるファイル。 非公開鍵ファイルは、​_パスフレーズレス_​である必要があります。 ## [](#openssl-コマンドを使用した証明書ファイルと非公開鍵の作成)openssl コマンドを使用した証明書ファイルと非公開鍵の作成 `openssl`​ を使用して、暗号化されていない、PEM でエンコードされた証明書ファイルと非公開鍵の両方を作成できます。 たとえば、自己署名証明書と対応する非公開鍵を作成するには、次の手順を実行します。 1. 次のように入力します。 openssl req -newkey rsa:2048 -nodes -keyout example-com-private.pem -x509 -days 3000 -out example-com-crt.pem 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 証明書では順序は重要ではありませんが、信頼チェーンの証明書は連結されている必要があります。 ## [](#関連情報)関連情報 - [証明書の追加](https://docs.mulesoft.com/jp/cloudhub/lb-cert-upload) - [証明書の検証](https://docs.mulesoft.com/jp/cloudhub/lb-cert-validation) - [許可リスト](https://docs.mulesoft.com/jp/cloudhub/lb-allowlists) - [マッピングルール](https://docs.mulesoft.com/jp/cloudhub/lb-mapping-rules) # Virtual Private Cloud Anypoint Virtual Private Cloud (VPC) を使用して、分離された仮想プライベートネットワークセグメントをクラウドに作成し、CloudHub ワーカーをホストすることができます。 Anypoint VPC に接続することにより企業ネットワークが拡張され、CloudHub ワーカーから企業ファイアウォールの内側にあるリソースにアクセスできます。 セキュアな VPN トンネルまたはトランジットゲートウェイアタッチメント経由でオンプレミスのデータセンターを接続したり、VPC ピアリングまたは AWS Direct Connect 経由でプライベート AWS VPC Anypoint VPC に接続したりできます。 基本の Anypoint VPC サブスクリプションには 2 つの Anypoint VPC が含まれており、各 Anypoint VPC を複数の環境に関連付けることができます。たとえば、分離されたネットワークの 1 つを本番環境に、もう 1 つを QA やステージングなどの非本番環境に使用できます。ライセンス要件は、特定のデプロイメントシナリオによって異なります。 Anypoint VPC では、さまざまな Amazon リージョンがサポートされています。セットアップ時に必要な Amazon リージョンを指定する必要があります。1 つの Amazon リージョンで複数の Anypoint VPC をセットアップすることもできます。 ![virtual private cloud 78b5f](/mulesoft/current/ja-jp/cloudhub/_images/virtual-private-cloud-78b5f.png) 各 Anypoint VPC で、ワーカーに適用するファイアウォールルールを設定できます。カスタムポートを公開またはブロックしたり、CloudHub の共有ロードバランサーからのアプリケーションに対する要求をブロックすることもできます。 専用のロードバランサーを使用する場合は、1 つまたは複数の専用ロードバランサーを設定して、独自の SSL 証明書を使用して要求を検証したり、コールする入力 URL をさまざまな CloudHub アプリケーションにマップしたりできます。 ファイアウォールルールと専用ロードバランサーの設定を組み合わせることで、外部サービスがどのようにアプリケーションに到達するかを微調整できます。 ## [](#関連情報)関連情報 - [Anypoint VPC ネットワークアーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/vpc-architecture-concept) - [Anypoint VPC のプロビジョニング](https://docs.mulesoft.com/jp/cloudhub/vpc-provisioning-concept) - [CloudHub 専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer) - [Anypoint VPC ファイアウォールルール](https://docs.mulesoft.com/jp/cloudhub/vpc-firewall-rules-concept) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) # VPC ネットワークアーキテクチャ Anypoint VPC は、CloudHub 内でホストされる分離された論理プライベートネットワークです。Anypoint VPC には、1 つのプライベートネットワークの一部であるかのように、プライベートイントラネットを接続できます。 Anypoint VPC の設定では、DNS レコード ​`mule-worker-internal-.cloudhub.io`​ が公開されます。これは DNS A レコードで、すべてのワーカーの IP アドレスが含まれています。Anypoint VPC の外部からこの DNS レコードにアクセスすることはできません。 各 Anypoint VPC では、直接ワーカーに対してインバウンド接続をチェックするファイアウォールルールを設定できます。 ポート 8091 および 8092 経由でプライベートアドレス空間を接続できるルールが 2 つと、ポート 8081 および 8082 経由で CloudHub の共有ロードバランサーによってプロキシされる外部要求を許可リストに登録するルールが 2 つ、計 4 つのファイアウォールルールがデフォルトで作成されます。 ファイアウォールルールの許可リストに登録されていないトラフィックはすべてデフォルトでブロックされます。 ![デフォルトの Anypoint VPC アーキテクチャ](/mulesoft/current/ja-jp/cloudhub/_images/vpc-default-arch.png) Figure 1. この図は、デフォルトの Anypoint VPC アーキテクチャを示しています。 VPC 内で専用のロードバランサーを設定することで、このサービスでは、カスタム証明書を提供し、必要に応じて双方向 SSL クライアント認証を適用できます。カスタムドメインにアプリケーションをマップするプロキシルールを設定することで、たとえば、1 つのバニティドメイン下のすべてをホストできます。 ![専用ロードバランサーを使用する Anypoint VPC アーキテクチャ](/mulesoft/current/ja-jp/cloudhub/_images/vpc-dlb-arch.png) Figure 2. この図は、専用ロードバランサーを使用する Anypoint VPC アーキテクチャを示しています。 CloudHub 専用ロードバランサーは、特定の Anypoint VPC に割り当てられます。専用ロードバランサーによって、VPC の特定のサービスリージョン内の特定の Anypoint VPC にトラフィックが転送されます。 各専用ロードバランサーには、DNS A レコードの ​`_lb-name_​.lb.anypointdns.net`​ or ​`_lb-name_​.lb-prod-eu-rt.anypointdns.net`​ (EU コントロールプレーン用) があり、その 2 つのインスタンスの 2 つの公開 IP アドレスに解決されます。 DNS プロバイダー経由で、専用の ​`A`​ レコードを参照する ​`CNAME`​ レコードを追加し、独自のドメイン名を使用してアクセスすることができます。この DNS A レコードは、VPC の外部からもアクセスできます。 さらに、CloudHub の専用ロードバランサーには、Anypoint VPC 内のアプリケーションとクライアントによって使用される内部ドメイン名があります。その構造は ​`internal-​_lb-name_​.lb.anypointdns.net`​ です。 ## [](#関連情報)関連情報 - [内部ネットワークの非公開ドメインの解決](https://docs.mulesoft.com/jp/cloudhub/resolve-private-domains-vpc-task) # VPC のプロビジョニング 組織での Anypoint VPC のプロビジョニングは、2 つの主要ステップで構成されます。 1. VPC を作成する。 これはセルフサービスプロセスです。Runtime Manager UI または Anypoint Platform CLI を使用して VPC を作成できます。
Anypoint Platform の基本サブスクリプションには 2 つの Anypoint VPC ライセンスが含まれており、Anypoint Platform 組織に 2 つの VPC の権利が与えられます。Anypoint VPC ライセンス制限に達すると、ユーザーインターフェースの ​[Create VPC (VPC を作成)]​ オプションが無効になります。
2. Anypoint VPC に接続する。 Anypoint VPC をオンプレミスネットワークに接続するように ​[Anypoint VPN](https://docs.mulesoft.com/jp/cloudhub/to-request-vpc-connectivity)​ または​[トランジットゲートウェイ](https://docs.mulesoft.com/jp/cloudhub/tgw-about)​を設定します。 VPC ピアリングまたは AWS Direct Connect を使用して Anypoint VPC を接続するには、MuleSoft サポート担当者にお問い合わせください。

不要なダウンタイムを回避するために、新しい Anypoint VPC を最初に作成するときに Anypoint VPC 設定を定義することが重要です。
Anypoint VPC を作成した後にこれらの設定を編集する場合は、変更後にすべてのワーカーを削除し、再デプロイする必要があります。

これらの設定は次のとおりです。 - ネットワークのアドレス空間。 これで Anypoint VPC のサイズが判断されます。 - VPC の場所。 VPC でワーカーをホストできるようにするには、Anypoint VPC をビジネスグループまたは特定の CloudHub リージョンにバインドする必要があります。 - VPC の組織またはビジネスグループ。 - VPC の CloudHub リージョン。 以下の FAQ を参照し、適切な VPC セットアップを計画する方法を理解してください。 ## [](#faq-anypoint-vpc-および-vpn-ライセンス要件の計算方法)FAQ: Anypoint VPC および VPN ライセンス要件の計算方法 IPSec VPN を介して Anypoint VPC を接続するには、デプロイメントシナリオに必要な数のライセンスを所有している必要があります。 Anypoint Platform の基本サブスクリプションには 2 つの Anypoint VPC ライセンスが含まれており、Anypoint Platform 組織にライセンス供与された 2 つ VPC の権利が与えられます。Anypoint VPN ライセンスは Anypoint VPC ライセンスにバンドルされており、各 Anypoint VPC ライセンスでは、リモートロケーションにある 1 つのパブリック IP アドレスに接続する 1 つの VPN ゲートウェイの権利が組織に与えられます。
Anypoint VPN ライセンスは、Anypoint VPC ライセンスと 1 対 1 の関係にする必要はありません。たとえば、1 つの Anypoint VPC で 2 つの Anypoint VPN を使用し、もう 1 つの Anypoint VPC では VPN を使用しないことができます。
Anypoint VPC からアクセスできるようにする各リモートロケーションに、Anypoint VPC ライセンスがもう 1 つ必要です。 ## [](#faq_how_to_size_vpc)FAQ: VPC のサイズの計算方法 Anypoint VPC を作成するときに、クラスレスドメイン間ルーティング (CIDR) 表記法を使用して、CIDR ブロック形式でネットワークの IP アドレス範囲を指定する必要があります。 このアドレス空間は Mule ワーカー用に予約されているので、VPC とピアリングする場合は、データセンターで使用されている他のアドレス空間と重複させることはできません。 Anypoint VPC の適切なサイズを計算するには、専用 IP アドレスの数は、デプロイしたワーカーの数とは同じでないことをまず理解する必要があります。 CloudHub にデプロイされた各ワーカーで、次の IP 割り当てが行われます。 - フォールトトレランスを向上するために、VPC サブネットを最大 4 つの可用性ゾーンに分割できます。 - いくつかの IP アドレスはインフラストラクチャ用に予約されています。 - ゼロダウンタイムを実現するためにワーカーごとに少なくとも 2 つの IP アドレス。 この構造により、Anypoint VPC に割り当てることができる最小のネットワークサブネットブロックは /24、最大は /16 になります。 Anypoint VPC サブネットのサイズを決めるときの無難な経験則は、VPC にデプロイすることが予想される最大アプリケーション数の 10 倍を計算することです。 ## [](#faq-組織内のどこに-anypoint-vpc-を配置するか)FAQ: 組織内のどこに Anypoint VPC を配置するか 組織のシステム管理者として、Anypoint VPC を作成し、メイン組織内の任意のビジネスグループと共有することができます。 ただし、Anypoint VPC がビジネスグループによって継承されたら、そのビジネスグループのシステム管理者のみが Anypoint VPC を操作できます。たとえば、Anypoint 組織のシステム管理者またはビジネスグループオーナーは、Anypoint VPC を作成、または既存の (所有または継承した) Anypoint VPC を更新し、リージョン、環境、またはその両方のデフォルトに設定できます。 ただし、このような関連付けがすでに存在している場合、要求した Anypoint VPC によって上書きされます。 ビジネスグループの関連付けを指定しない場合、または組織にビジネスグループがない場合、Anypoint VPC の所有権はメイン組織に関連付けられたままになります。Anypoint VPC が作成される組織が VPC オーナーであり、この組織のシステム管理者が Anypoint VPC を共有できる唯一のユーザーです。 Anypoint VPC は、メイン組織からビジネスグループのいずれか、またはビジネスグループから子ビジネスグループのいずれかに、縦に共有することができます。 ビジネスグループによって作成された Anypoint VPC を、階層内の上位にあるビジネスグループと共有することはできません。 メイン組織で Anypoint VPC を作成し、他のビジネスグループと共有することをお勧めします。 ## [](#faq-anypoint-vpc-を作成するときにどのリージョンを使用するか)FAQ: Anypoint VPC を作成するときにどのリージョンを使用するか 使用可能な任意の CloudHub リージョン内に Anypoint VPC を作成できます。 推奨されるリージョンは、Anypoint VPC との接続方法によって異なります。VPN トンネルを使用する場合は、データセンターに最も近い CloudHub リージョンを選択します。 ただし、プライベート AWS VPC とピアリングする場合は、同じ AWS リージョンに Anypoint VPC を作成する必要があります。 ## [](#faq-アプリケーションを-vpc-にデプロイまたは移動する方法)FAQ: アプリケーションを VPC にデプロイまたは移動する方法 MuleSoft アプリケーションを開発や Sandbox などの環境にデプロイします。 デプロイメントのリージョンが VPC リージョンと一致した場合: - アプリケーションのデプロイメントの時点ですでに環境が VPC に関連付けられている場合は、アプリケーションは VPC 内で動作します。 - アプリケーションのデプロイメント後に環境が VPC に関連付けられた場合は、アプリケーションを再起動するまでは、アプリケーションは VPC 内では動作しません。 デプロイメントのリージョンが VPC リージョンと一致しない場合は、アプリケーションは VPC の外部でデプロイされます。この場合、アプリケーションは VPC で設定されている接続方法にはアクセスできません。 ## [](#関連情報)関連情報 - [ネットワークへの VPC 接続の要求](https://docs.mulesoft.com/jp/cloudhub/to-request-vpc-connectivity) # VPC ファイアウォールルール CloudHub のデフォルト設定では、すべてのアプリケーションは、公開されているロードバランサーによって分散されたマルチテナントクラウドでホストされます。 Anypoint Virtual Private Cloud (Anypoint VPC) を作成するときに、独自のファイアウォールルールを追加して、特定の IP 範囲やポートがワーカーにアクセスすることを許可できます。「​[ファイアウォールルールの設定](#configurefirewall)​」を参照してください。
Anypoint VPC で設定するファイアウォールルールでチェックされるのはワーカーへのインバウンド接続のみで、Anypoint VPC、専用ロードバランサー、公開されているロードバランサーはチェックされません。
## [](#デフォルトのファイアウォールルール)デフォルトのファイアウォールルール デフォルトでは、ファイアウォールルールで明示的に許可されていない限り、VPC へのすべてのトラフィックがブロックされます。 Anypoint VPC を作成すると、4 つのファイアウォールルールがデフォルトで作成されます。 - ポート 8091 および 8092 経由でローカルの Anypoint VPC 内からのインバウンド接続を許可する 2 つのルールを次に示します。 ```json { "CIDR Block": "10.111.0.0/24", // (Local VPC) "Protocol": "TCP", "From port": 8092, }, { "CIDR Block": "10.111.0.0/24", // (Local VPC) "Protocol": "TCP", "From port": 8091, }, ``` これらのファイアウォールルールは、ポート 8091 および 8092 経由で Anypoint VPC 内からのトラフィックがワーカーに到達するのを許可します。CloudHub 専用ロードバランサーがワーカーへのすべての外部通信をプロキシするために使用できるポートはこれらのみです。 - ポート 8081 および 8082 経由であらゆる場所からのインバウンド接続を許可する 2 つのルールを次に示します。 ```json { "CIDR Block": "0.0.0.0/0", // (Anywhere) "Protocol": "TCP", "From port": 8082, }, { "CIDR Block": "0.0.0.0/0", // (Anywhere) "Protocol": "TCP", "From port": 8081, } ```

これらのルールは、ポート 8081 および 8082 経由でどのホストからでもトラフィックがワーカーに到達するのを許可します。 これらのポートは、ワーカーへの外部要求をプロキシするために CloudHub の共有ロードバランサーによって使用されます。 公開されているロードバランサーが内部ワーカーに到達できないようにする場合はこれらのルールを削除できます。

## [](#ファイアウォールルールの制限)ファイアウォールルールの制限 CloudHub で必要なルールの数 (可変) に応じて、VPC ごとに約 35 個のファイアウォールルールを設定できます。 使用可能な数を超えるファイアウォールルールを作成すると、ルールの最大数に達したことを示すエラーが VPC から返されます。 ## [](#configurefirewall)ファイアウォールルールの設定 Anypoint VPC を作成するときに Anypoint Runtime Manager UI でファイアウォールルールを設定するか、既存の Anypoint VPC に追加できます。また、Anypoint VPC のファイアウォールルールはいつでも変更できます。 ファイアウォールルールを実装または既存のルールに変更を加える前に、すべてのセキュリティ上の影響を完全に理解しておく必要があります。ファイアウォールルールに変更を加える前に、組織の確立されたベストプラクティスに従ってください。一般に、Anypoint VPC へのアクセスを定義するために使用するルールは、できる限り具体的にする必要があります。 ファイアウォールルールはインバウンドで、次のパラメーターを使用します。 - **Type (種別)**​: プロトコル種別 (TCP など) - **Source (接続元)**​: 接続元 IP アドレス - **Port Range (ポート範囲)**​: 外部に公開されるポートは 8081 (http.port) と 8082 (https.port) の 2 つのみです。このパラメーターを使用して、VPC 内部で追加ポートを開くことができます。
1024 より下のポートに対しては、ファイアウォールルールを設定できません。
### [](#ファイアウォールルールの追加または編集)ファイアウォールルールの追加または編集 1. **Organization Administrators (組織のシステム管理者)**​ ロールを持つユーザーとして Anypoint Platform にサインインします。 2. **\[Management Center\]**​ で、​**\[Runtime Manager\]**​ をクリックします。 3. すでに Anypoint VPC がある場合は、次を実行します。 1. 左側のメニューで ​**\[VPCs\]**​ をクリックし、ファイアウォールルールを設定する Anypoint VPC の行をクリックします。 右パネルに Anypoint VPC インスタンスに関する情報が表示されます。 2. **\[Manage VPC (VPC を管理)\]**​ をクリックし、​**\[Firewall Rules (ファイアウォールルール)\] タブ**​をクリックします。 4. Anypoint VPC を作成するときにファイアウォールルールを作成する場合は、次を実行します。 1. **\[Firewall Rules > (ファイアウォールルール >)\]**​ をクリックして項目を展開します。 ![firewall rules page](/mulesoft/current/ja-jp/cloudhub/_images/firewall-rules-page.png) 5. ルールを編集するには、​**\[Type (種別)\]**​ および ​**\[Source (接続元)\]**​ ドロップダウンリストから新しい値を選択し、​**\[Port Range (ポート範囲)\]**​ に値を入力します。 6. ルールを追加する場合は、次を実行します。 1. **\[Add New Rule (新規ルールを追加)\]**​ をクリックします。 2. 対応する列で次の種別と接続元の値を選択します。 - **Type (種別)**​: ルールのトランスポートプロトコル種別を選択します。 - **Source (接続元)**​: 接続元 IP アドレスを選択するか、​**\[Custom (カスタム)\]**​ を選択して独自の接続元を定義します。 3. **\[Port Range (ポート範囲)\]**​ に値を入力し、​**\[Add to list (リストに追加)\]**​ をクリックします。 7. ファイアウォールルールを削除するには、削除するファイアウォールルールにカーソルを置き、右端の列にあるゴミ箱アイコンをクリックします。

ファイアウォールルールを削除するときに確認ダイアログは表示されないので、削除する必要があることを確認してください。

## [](#関連情報)関連情報 - [CloudHub ネットワークガイド](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide) - [CloudHub ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/dedicated-load-balancer-tutorial) - [専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) # アプリケーションプロパティを安全に隠す CloudHub では、安全な隠しアプリケーションプロパティがサポートされています。つまり、プロパティの名前は Anypoint Runtime Manager に表示されますが、値はどのユーザーにも表示されず、取得することもできません。 プロパティは機密情報を公開せずに実行時に解決されます。 内部では、安全な隠しアプリケーションプロパティは暗号化され、MuleSoft 管理 CloudHub プロパティデータベースに保存されます。このデータベースはユーザー組織ごとに暗号化されます。 CloudHub ワーカーにデプロイされたアプリケーションまたはハイブリッドデプロイメントの場合、Runtime Manager を使用して隠しプロパティを設定できます。 その他のデプロイメントオプションを使用してデプロイするアプリケーションでは、デプロイ可能なアプリケーションのアーカイブファイルにバンドルされるセキュアなプロパティプレースホルダーファイルを使用する必要があります。
安全な隠しアプリケーションプロパティは、セキュアな設定ファイルに保存される暗号化された Mule アプリケーションのプロパティとは別の機能および概念です。 「セキュア設定プロパティ」​を参照してください。
## [](#概要)概要 アプリケーションプロパティは、Mule アプリケーションでプレースホルダーとして動作する変数で、実行時に設定されます。 Runtime Manager でアプリケーションをデプロイ、または既存のアプリケーションを更新するときに、Mule Runtime Engine は ​**\[Properties (プロパティ)\]**​ タブで設定される情報を使用してプロパティの変数の値を提供します。 たとえば、ユーザー名が ​`${dbUsername}`​、パスワードが ​`${dbPassword}`​ に設定される JDBC Connector を設定できます。 Runtime Manager で、これら 2 つのプロパティをアプリケーションプロパティとして設定できます。 機密情報の場合は、これらのプロパティに非表示としてフラグを付けることができます。そうすると、Runtime Manager で入力および保存された後、それらの値はコンソールに表示されず、コンソールと CloudHub サーバーの間で渡されることもありません。
ハイブリッドデプロイメントの場合、再デプロイ後も値は表示されたままになります。
## [](#安全な隠しアプリケーションプロパティの作成)安全な隠しアプリケーションプロパティの作成 安全な隠しアプリケーションプロパティを作成する手順は次のとおりです。 1. 適切なファイルにプロパティを追加します。 Mule 4.0 以降では、​`secureProperties`​ キーの下にある ​`mule-artifact.json`​ ファイルに安全に隠すプロパティ名がカンマ区切り配列としてリストされます。 ```json { "configs": [ "testprops-app.xml" ], "secureProperties": ["password", "birthdate"], "redeploymentEnabled": true, "name": "secure-properties", "minMuleVersion": "4.2.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` 5 行目には 2 つのセキュアなプロパティが示されています。 `secureProperties`​ エントリは、定義されている場所 (または定義されているか否か) に関係なく、すべてのプロパティに影響します。 ローカルテストを実行する場合は、プロパティとその値を定義する YAML ファイルを作成して ​`src/main/resources`​ フォルダーに追加します。 ```yaml http: port: 8081 username: "testuser" password: "testpass123" birthdate: "01/01/2006" ``` Mule 3 では ​`mule-app.properties`​ ファイルにプロパティを配置します。 ```code db.user=john db.password=mypassword salesforce.user=john1 salesforce.password=mysfpassword secure.properties=db.password,salesforce.password ``` 2. Mule アプリケーションを CloudHub にデプロイします。 3. **\[Applications (アプリケーション)\]**​ ページでアプリケーション名をクリックしてから ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Properties (プロパティ)\]**​ タブで、​**\[Text View (テキストビュー)\]**​ をクリックしてからアプリケーションのプロパティを入力します。 ![アプリケーションの 「Settings (設定)」 ページの 「Properties (プロパティ)」 タブとキー-値プロパティ](/mulesoft/current/ja-jp/cloudhub/_images/rtm-hide-props.png) Figure 1. このスクリーンショットには、​**\[Settings (設定)\]**​ ページの (​**1**​) ​**\[Properties (プロパティ)\]**​ タブと (​**2**​) キー-値プロパティが表示されています。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 6. アプリケーションを再デプロイまたは再起動します。 アプリケーションを再デプロイしたら、​**\[Properties (プロパティ)\]**​ タブに移動します。 安全な隠しプロパティとしてマークしたプロパティの値は、これで自分にも他のユーザーにも表示されなくなります。 次の例では、​`birthdate`​ と ​`password`​ が安全に隠されていますが、​`username`​ は隠されていません。 ![「Servers (サーバー)」 ページの 「Properties (プロパティ)」 タブの隠し値](/mulesoft/current/ja-jp/cloudhub/_images/rtm-hidden-props.png) Figure 2. 矢印は、​**\[Servers (サーバー)\]**​ ページの ​**\[Properties (プロパティ)\]**​ タブの隠し値を示しています。 値をコミットし、アプリケーションをアップロードしたら、安全な隠しプロパティはコンソールに表示されなくなります。また、コンソールと CloudHub サーバーの間で送受信されることもありません。 プロパティの設定後はプロパティを取得することはできませんが、新しい値で上書きすることはできます。 値を更新するには、項目に新しい値を入力します。 安全な隠しアプリケーションプロパティを持つアプリケーションがデプロイされたら、CloudHub ではそれらのプロパティのセキュリティフラグが維持されます。 アプリケーションファイルを編集して ​`mule-artifact.json`​ ファイルから ​`secureProperties`​ 定義を削除し、編集したアプリケーションファイルを CloudHub にアップロードしたとしても、CloudHub では安全な隠しプロパティとして以前にフラグが付けられたプロパティの非表示が維持されます。 ## [](#sandbox-間での安全な隠しアプリケーションプロパティのコピー)Sandbox 間での安全な隠しアプリケーションプロパティのコピー アプリケーションを Sandbox 間で移動するとき、安全な隠しアプリケーションプロパティの値は新しい環境にコピーされません。すべての安全な隠しアプリケーションプロパティの名前はコピーされますが、値は空白のままになります。 ## [](#暗号化されたアプリケーションプロパティと安全な隠しアプリケーションプロパティ)暗号化されたアプリケーションプロパティと安全な隠しアプリケーションプロパティ Mule アプリケーションでは、セキュアなプロパティプレースホルダーを使用して、値が暗号化されたプロパティを保存することもできます。 セキュアな設定プロパティの作成と使用についての詳細は、​[「セキュアな設定プロパティ」](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties)​を参照してください。 Mule アプリケーションでは、暗号化されたプロパティを使用して、Mule アプリケーションのデプロイ可能な .jar アーカイブファイル内にセキュアなプロパティプレースホルダーファイルがバンドルされます。 セキュアなプロパティプレースホルダーは、暗号化されたプロパティを含むファイルと、セキュアなプロパティ値を暗号化するために使用される暗号化アルゴリズムの詳細の組み合わせで構成されます。セキュアなプロパティは、秘密鍵を使用して暗号化されます。秘密鍵は、Mule アプリケーション内には絶対に保存しないでください。その代わりに、デプロイ時に秘密鍵値を安全 (セキュア) に渡す必要があります。 Mule アプリケーションに秘密鍵を安全に渡すには、秘密鍵値を表すプロパティプレースホルダーを使用して Mule アプリケーションを開発します。オペレーターがデプロイ時に秘密鍵値を安全に渡すには、いくつかの方法があります。 ファイルシステムとコマンドラインにアクセスできるオンプレミスのデプロイメントでは、システム環境変数を設定することで Mule Runtime のスタートアップ時に秘密鍵を渡すことができます。ファイルシステムがセキュリティで保護されている場合は、ファイルシステムにある特別なセキュアフォルダーに秘密鍵を保存することもできます。Mule アプリケーションの制限付き権限でスタートアップ時に秘密鍵を読み取るようにすると安全です。 秘密鍵がメモリに読み込まれたら、Mule アプリケーションではそれを使用してセキュアなプロパティプレースホルダーのその他すべてのプロパティを復号化し、復号化された値はメモリに保存されます。Mule アプリケーションをセキュリティで保護するには、Mule アプリケーションのメモリまたは JVM メモリを誰も読み取ることができないよう、Mule Runtime のホストへのアクセスをロックダウンすることが重要です。

セキュリティプロパティモジュールを使用して定義されたプロパティに、​mule-artifact.json​ ファイルで ​secure properties​ を指定するときには、​secure::​ プレフィックスを忘れずに追加してください。

## [](#暗号化されたプロパティを使用する-cloudhub-アプリケーションの開始)暗号化されたプロパティを使用する CloudHub アプリケーションの開始 Mule アプリケーションは、セキュアなプロパティプレースホルダーファイルに暗号化されたプロパティが保存されるよう開発することもできます。 CloudHub デプロイメントの場合、オペレーターには CloudHub ワーカーのファイルシステムへのアクセス権がなく、コマンドラインにログインして CloudHub ワーカーをスタートアップすることもできないため、お客様がホストするデプロイメントで説明したセキュアなデプロイメントアプローチは CloudHub ではどれも使用できません。 また、Mule アプリケーションの ​`mule-artifact.json`​ ファイルの ​`secureProperties`​ エントリに、暗号化されたプロパティの名前をリストすることで、暗号化されたプロパティに安全な隠しアプリケーションプロパティとしてフラグを付けることもできます。具体的には、暗号化されたプロパティを復号化するために使用する秘密鍵を、​`mule-artifact.json`​ ファイルの ​`secureProperties`​ 鍵で安全な隠しプロパティとして設定できます。 例を挙げます。 `config.yaml` ```yaml http: port: 8081 username: "testuser" password: "![r8weir09458riwe0r9484oi]" birthdate: "01/01/2015" ``` `mule-artifact.json` ```json { "configs": [ "secure-properties.xml" ], "secureProperties": ["secure::password", "birthdate", "secure.key"], "redeploymentEnabled": true, "name": "secure-properties", "minMuleVersion": "4.1.1", "requiredProduct": "MULE_EE", "classLoaderModelLoaderDescriptor": { "id": "mule", "attributes": { "exportedResources": [] } }, "bundleDescriptorLoader": { "id": "mule", "attributes": {} } } ``` その後、デプロイ時に、オペレーターは Runtime Manager の \[Properties (プロパティ)\] タブに ​`secure.key`​ 値を入力できます。 安全な鍵には、コンソールに表示されないようフラグが付けられているため、オペレーターが入力している内容は誰にも表示されません。 秘密鍵が Mule アプリケーションに渡されたら、お客様がホストするデプロイメントと同じように、暗号化されたプロパティがメモリ内に複合化されます。CloudHub ワーカーは高度なセキュリティで保護されているので、これを CloudHub で行うと安全です。CloudHub ワーカーのコマンドラインはアクセス不可能で、侵入者が CloudHub ワーカーのメモリまたは JVM プロパティを読み取る手立てもありません。 ## [](#暗号化されたプロパティの上書き方法)暗号化されたプロパティの上書き方法 セキュアなプロパティプレースホルダーファイル内で Mule アプリケーションにバンドルされる暗号化されたプロパティは、Runtime Manager の ​**\[Properties (プロパティ)\]**​ タブには表示されません。これによって値は Mule アプリケーション内部に安全にロックされます。 暗号化されたプロパティの名前が Mule アプリケーションの ​`mule-artifact.json`​ の ​`secureProperties`​ エントリにもリストされている場合、アプリケーションがデプロイされると、複合化されるプロパティと同じく、この暗号化されたプロパティの値も Runtime Manager の ​**\[Properties (プロパティ)\]**​ タブには表示されません。 複合化された値は Mule ワーカーのメモリに安全に保存され、暗号化された値はユーザーアカウントの CloudHub データベースに安全に保存されます。復号化された値は、CloudHub ワーカーのファイルに保存されたり、(Runtime Manager コンソールを含む) その他のマシン間で渡されたりすることは決してありません。 したがって、Mule アプリケーションの ​`secureProperties`​ エントリで安全な隠しプロパティとしてもマークされている暗号化されたプロパティの場合は、暗号化されたプロパティをクリアテキスト値に安全に置き換えることができます。クリアテキスト値は、CloudHub プロパティデータベースに安全に保存され、Mule アプリケーションが開始されるたびに、Mule アプリケーションに安全に渡されます。 CloudHub デプロイメントの場合は、アプリケーションがデプロイされると、新しい値は非表示になり、二度と参照することはできません。 ハイブリッドデプロイメントの場合、再デプロイ後も新しい値は表示されたままになります。 つまり、アプリケーションで CloudHub の ​**\[Properties (プロパティ)\]**​ タブでセキュアなプロパティを上書きするときには、値を暗号化しないでください。このシナリオでは、セキュアアプリケーションのデプロイまたは再デプロイ時にアプリケーションのソースファイルの値へのアクセス権を持つユーザーのみが、セキュアなプロパティを上書きできます。 セキュアなプロパティを上書きする必要があるケースとしては、本番アプリケーションで ​`db.user`​ と ​`db.password`​ という 2 つのプロパティに保存されているデータベースユーザーとパスワードを更新する必要がある場合などがあります。アプリケーションで CloudHub の ​**\[Properties (プロパティ)\]**​ タブで新しい ​`db.user`​ と ​`db.password`​ の値を入力して、アプリケーションを起動または再起動します。これにより、新しいアプリケーションでは、このセキュアなログイン情報をダウンタイムなしでアップグレードできます。 すべての連動アプリケーションを移行したら、古いアカウントの使用を停止できます。
アプリケーションの ​[Properties (プロパティ)]​ タブで ​[Table View (テーブルビュー)]​ を使用してプロパティを更新する場合は、プロパティ名のコロンをエスケープする必要はありません (例: secure::someproperty​)。​[Text View (テキストビュー)]​ を使用してプロパティを更新する場合は、プロパティ名のコロンをエスケープする必要があります (例: secure\:\:someproperty​)。
## [](#cloudhub-ワーカーにのみデプロイされる-mule-アプリケーション)CloudHub ワーカーにのみデプロイされる Mule アプリケーション CloudHub ワーカーにのみデプロイされる Mule アプリケーションのプロパティを暗号化しない場合は、Mule アプリケーションの ​`mule-artifact.json`​ ファイルの ​`secureProperties`​ エントリで、これらのプロパティに安全な隠しプロパティとしてのフラグを付けることができます。 ## [](#関連情報)関連情報 - [セキュア設定プロパティ](https://docs.mulesoft.com/mule-runtime/latest/secure-configuration-properties) - [CloudHub 上のアプリケーションのプロパティ管理](https://docs.mulesoft.com/jp/cloudhub/cloudhub-manage-props) - [オンプレミスのアプリケーションのプロパティ管理](https://docs.mulesoft.com/jp/runtime-manager/hybrid-manage-props) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [ハイブリッドデプロイメントでの設定プロパティの非表示](https://help.mulesoft.com/s/article/How-to-hide-configuration-properties-in-hybrid-deployments) - [How to Secure Properties before Deployment in Anypoint Studio (Anypoint Studio でのデプロイメント前にプロパティを保護する方法)](https://developer.mulesoft.com/tutorials-and-howtos/getting-started/how-to-secure-properties-before-deployment) # アプリケーション監視と自動再起動 CloudHub はすべてのアプリケーションを監視し、アプリケーションが応答しなくなった場合に通知と診断情報をユーザーに送信します。 ユーザーが介入しなくてもアプリケーションが自動的に回復されるように、自動再起動を有効にすることができます。 ## [](#アプリケーションによる動作の監視方法)アプリケーションによる動作の監視方法 監視動作は Mule バージョンによって異なります。 - Mule 4.x CloudHub は Mule エージェント状態チェックエンドポイントを使用して、デプロイメントの準備状況を決定します。この監視方法では、徹底的なチェックによってアプリケーションがデプロイされ、ゲートウェイポリシーが適用されていることが確認されます。 30 秒おきに CloudHub が状態チェックエンドポイントをチェックします。状態チェックエンドポイントの失敗が 3 回連続して検出されると、ログに警告が出力されます。 - Mule 3.8.x デプロイ時には、CloudHub によって監視 ping フローがアプリケーションに挿入されます。 アプリケーションが起動すると、監視が有効になっていることと、ping フローがアプリケーションに挿入されたことを示すメッセージがログに表示されます。 ![ログの Monitoring enabled メッセージと Registering ping flow injector メッセージ](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-app-monitor-enabled.png) Figure 1. ログの ​`Monitoring enabled`​ メッセージと ​`Registering ping flow injector`​ メッセージを示す矢印。 30 秒おきに CloudHub が HTTP GET 要求を ping フローに送信します。 アプリケーションが正常に実行されている場合、ping フローは応答を送信します。 CloudHub が 3 回連続で ping から応答を受信しないと、ログに警告とフルスレッドダンプが表示されます。 どちらの場合でも、CloudHub ではコンソールへの通知がトリガーされ、アプリケーションのワーカーが応答しなくなったことが通知されます。 メールアラートを設定してある場合、応答しないワーカーによって、​`Worker Not Responding`​ イベントに基づくメールアラートもトリガーされます。 ## [](#自動再起動の有効化)自動再起動の有効化 新しいアプリケーションをデプロイするとき、または既存のアプリケーションを再デプロイするときに、自動再起動を有効化できます。 - 新しいアプリケーションをデプロイする 1. Runtime Manager の左側のメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックして、​**\[Deployment Target (デプロイメント対象)\]**​ から ​**\[CloudHub\]**​ を選択します。 3. **\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\]**​ オプションを選択します。 ![\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\] オプション](_images/cloudhub-app-autorestart.png) Figure 2. **\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\]**​ オプションを示す矢印。 4. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 - 既存アプリケーションの再デプロイ 1. Runtime Manager の左側のメニューで ​**\[Applications (アプリケーション)\]**​ をクリックします。 2. アプリケーション状況をクリックして、詳細ペインを右側に表示します。 3. **\[Manage Application (アプリケーションを管理)\]**​ ボタンをクリックして、アプリケーションの ​**\[Settings (設定)\]**​ ページを表示します。 4. **\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\]**​ オプションを選択します。 ![\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\] オプション](_images/cloudhub-app-autorestart.png) Figure 3. **\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\]**​ オプションを示す矢印。 5. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#自動再起動の動作)自動再起動の動作 **\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\]**​ オプションを選択すると、CloudHub はワーカーを監視し、必要に応じてアプリケーションを再起動します。 CloudHub は、アプリケーションが再起動中であることを知らせる通知を表示し、その後で再起動の成功または失敗を報告する通知を表示します。 - 再起動に成功すると、ping スクリプトが再初期化されて監視が続行されます。 - 再起動に失敗すると、CloudHub は引き続きアプリケーションの再起動を 5 回まで再試行します。 再起動の最大試行回数を超えると、CloudHub はそれ以上は何も行いません。監視スクリプトが終了し、アプリケーションは手動で介入するまでそのままの状態です。 ログに再起動プロシージャーの詳細が表示されます。 **\[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)\]**​ オプションを選択しないと、監視スクリプトが終了し、アプリケーションは手動で再起動するまでそのままの状態になります。 CloudHub は通知とログメッセージを表示しますが、それ以上は何も行いません。 ## [](#関連情報)関連情報 - [アラートの設定](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [アプリケーションとサーバーの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) # オブジェクトストアを使用したアプリケーションデータストレージの管理 CloudHub には、管理する各アプリケーションのアプリケーションデータストレージが含まれます。 このデータは、Mule Object Store および Object Store v2 機能を使用してアクセスできます。 Object Store は、任意のものを保存するために使用できますが、主な用途は次の 2 つです。 - 同期状態の保存: アプリケーションで最後に同期したレコードを記録する必要がある場合があります。そうすることで、アプリケーションが次回同期するときに、中断したところから再開できます。 - OAuth トークン: OAuth 対応コネクタは、数行の設定コードを使用することで、Object Store 内にトークンを保存できます。 アプリケーションは、下記の制限内でカスタムインテグレーションデータも保存できます。
  • Object Store は、CloudHub ワーカーにデプロイされたアプリケーションに対してのみ、このドキュメントで説明する方法で処理されます。Runtime Manager を使用してローカルサーバーにデプロイしたアプリケーションについては、独自のリポジトリでデータの保存を処理する必要があります。詳細は、​「デプロイメントオプション」​を参照してください。

  • Object Store v1 のすべてのデータは、アプリケーションがデプロイされたゾーンに関係なく、​US-East ゾーン​のサーバーによって処理されます。これは、パフォーマンスに影響する場合があります。

  • Object Store v2​ では、クラウドオブジェクトストアリージョン数が増え、Mule 3.8.5 以降および Mule 4 で使用するためのオブジェクトストア機能が拡張されました。

## [](#データの保存と取得)データの保存と取得 Mule フロー内のアプリケーションデータを操作するには、Object Store Connector を使用します。このコネクタでは、Runtime Manager Object Store に対してデータを保存、取得、リスト、削除する操作が提供されます。Object Store Connector は、Object Store v1 と Object Store v2 の両方で機能します。 ### [](#oauth-データの取得)OAuth データの取得 OAuth トークンの取得方法については、​[「OAuth Module」](https://docs.mulesoft.com/jp/oauth-module/latest/)​を参照してください。 ## [](#アプリケーションデータの表示)アプリケーションデータの表示 オブジェクトストアのアプリケーションデータを確認するには、Runtime Manager でアプリケーション名をクリックしてから、​**\[Manage Application (アプリケーションの管理)\]**​ > ​**\[Object Store (オブジェクトストア)\]**​ をクリックします。 ![左側のナビゲーションペインの \[Object Store (オブジェクトストア)\]](_images/cloudhub-object-store-rtm.png) Figure 1. 矢印は、左側のナビゲーションペインの ​**\[Object Store (オブジェクトストア)\]**​ を示しています。 アプリケーションで Object Store v1 を使用している場合、表示ラベルは​**「Application Data (アプリケーションデータ)」**​になります。
プロパティをセキュアにして、Runtime Manager UI やその他の場所に表示されないようにするには、​「Safely Hide Application Properties (アプリケーションプロパティを安全に非表示にする)」​を参照してください。
## [](#セマンティクスとストレージ制限)セマンティクスとストレージ制限 Object Store v1 では、リードアフターライトによる一貫性が提供され、最後に書き込まれた内容によって更新されます。 Object Store v1 の制限は次のとおりです。 - アプリケーションごとの最大キー数: 100,000 - キーのサイズ: 768 バイト - 値のサイズ: 1 MB - アプリケーションあたりのデータ: 1 GB Object Store v2 の制限は次のとおりです。 - Mule 3.8.5 以降および Mule 4 と連携 - アプリケーションごとのキー数: 無制限 - 値の最大サイズ: 10 MB - TPS: トライアルレベルの場合は 10、プレミアムレベルの場合は 100 - キーの最長保持期間: 30 日間 - [商用のすべての CloudHub リージョン](https://docs.mulesoft.com/jp/object-store/osv2-faq)​で使用可能。 ## [](#高度な情報)高度な情報 内部では、Mule にはいくつかの異なる種類のオブジェクトストアがあります。Runtime Manager では Object Store v1 (Mule 3 用) と Object Store v2 (Mule 3.8.5 以降および Mule 4 用) が提供されます。これらのオブジェクトストアは、上記のユースケースのようにアプリケーションに関する実行時の情報のためのものです。このオブジェクトストアに内部で直接アクセスする必要がある場合は、Mule レジストリの '\_defaultUserObjectStore\` にあります。Object Store Module と Object Store Connector では、デフォルトではすべてのデータの保存にこのストアが使用されます。 ### [](#関連情報)関連情報 - [Object Store v1](https://docs.mulesoft.com/mule-runtime/latest/mule-object-stores) - [Object Store v2](https://docs.mulesoft.com/jp/object-store/) - [チュートリアル: Object Store v2](https://docs.mulesoft.com/jp/object-store/osv2-tutorial) - [Anypoint Exchange の Mule 4 用 Object Store Connector](https://www.mulesoft.com/exchange/org.mule.connectors/mule-objectstore-connector/) - [Anypoint Exchange の Mule 3 用 Object Store Connector](https://www.mulesoft.com/exchange/org.mule.modules/mule-module-objectstore/) # カスタムアプリケーションアラートおよび通知 CloudHub を使用すると、アプリケーションからの通知を Runtime Manager コンソールに表示できます。 元の問題を解決できるように、これらの通知を​_カスタムアラート_​として特定の相手にメールで送信するよう CloudHub を設定できます。
カスタムアラートと通知は、CloudHub ワーカーにデプロイされているアプリケーションでのみ使用できます。 オンプレミスサーバーにデプロイされているアプリケーションでは使用できません。 CloudHub 機能についての詳細は、​「デプロイメントオプション」​を参照してください。
## [](#前提条件)前提条件 - CloudHub にアプリケーションをデプロイしていること。 [「CloudHub へのデプロイ」](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub)​を参照してください。 - Anypoint Studio 6.x 以前の場合は、Mule プロジェクトの Maven サポートを有効化していること。 [「Enabling Maven Support for a Studio Project (Studio プロジェクトの Maven サポートの有効化)」](#6.5@studio::enabling-maven-support-for-a-studio-project.adoc)​を参照してください。 Studio 7.x 以降のすべてのプロジェクトでは、デフォルトで Maven をサポートしています。 ## [](#カスタムアプリケーションアラート)カスタムアプリケーションアラート アラートを使用すると、アプリケーションの通知に基づいてメールを送信できます。 CloudHub またはオンプレミスサーバーにデプロイされているサーバーとアプリケーション用に、Runtime Manager で標準的なアラートを作成できます。 [アラート](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager)​の詳細を参照してください。 CloudHub にデプロイされているアプリケーションの​_カスタムアラート_​を作成することもできます。 カスタムアプリケーションアラートを作成する手順は、次のとおりです。 1. CloudHub 用 Anypoint Connector (CloudHub Connector) を Anypoint Studio の Mule アプリケーションのフローに追加し、通知を設定します。 CloudHub Connector は、Mule 3 アプリケーションと Mule 4 アプリケーションの両方で使用できます。 2. CloudHub にアプリケーションをデプロイします。 3. Runtime Manager で、カスタムアプリケーションアラートを設定します。 ### [](#cloudhub-connector-で通知を設定する)CloudHub Connector で通知を設定する Studio で、Mule プロジェクトに CloudHub Connector を追加して設定します。 1. **\[Mule Palette (Mule パレット)\]**​ ビューで ​**\[CloudHub\]**​ をクリックし、キャンバスでアラートをトリガーするアプリケーションフローに ​**\[Create Notification\]**​ 操作をドラッグします。 2. キャンバスで ​**\[Create Notification\]**​ をクリックします。 3. **\[Create Notification\]**​ プロパティウィンドウで、​**\[Connector configuration (コネクタ設定)\]**​ 項目の右にある緑のプラスアイコン (​**+**​) をクリックします。 4. **\[Global Element Properties (グローバル要素プロパティ)\]**​ ウィンドウで、Anypoint Platform に対する認証を設定し、​**\[OK\]**​ をクリックします。 ![\[Global Element Properties (グローバル要素プロパティ)\] ウィンドウの \[Username (ユーザー名)\] 項目](_images/alerts-custom-ch-connector.png) Figure 1. 矢印は、​**\[Global Element Properties (グローバル要素プロパティ)\]**​ ウィンドウの ​**\[Username (ユーザー名)\]**​ 項目を示しています。 このコネクタでは、基本認証または継承されたトークン認証を使用できます。 5. **\[Create Notification\]**​ プロパティウィンドウで、​**\[Domain (ドメイン)\]**​ 項目に CloudHub アプリケーション名を、​**\[Message (メッセージ)\]**​ 項目に通知を入力します。 ![\[Create Notification\] プロパティウィンドウの \[Message (メッセージ)\] 項目](_images/alerts-custom-ch-connector-notification.png) Figure 2. 矢印は、​**\[Create Notification\]**​ プロパティウィンドウの ​**\[Message (メッセージ)\]**​ 項目を示しています。 CloudHub Connector を使用した通知の作成についての詳細は、​[「通知の作成」](https://docs.mulesoft.com/jp/cloudhub-connector/latest/#creating-notifications)​を参照してください。 6. CloudHub にアプリケーションをデプロイします。 ### [](#カスタムアラートの作成)カスタムアラートの作成 Runtime Manager で、カスタム通知をアラートにバインドします。 1. 左側のメニューで ​**\[Alerts (アラート)\]**​ をクリックします。 2. 青色のプラス記号 (​**+**​) をクリックして新しいアラートを作成します。 3. **\[Create an Alert (アラートを作成)\]**​ ページで、カスタムアラートを設定して ​**\[Submit (送信)\]**​ をクリックします。 ![\[Create an Alert (アラートを作成)\] ウィンドウの \[Applications (アプリケーション)\] 項目](_images/alerts-custom-rtm-create.png) Figure 3. 矢印は、​**\[Create an Alert (アラートを作成)\]**​ ウィンドウの ​**\[Applications (アプリケーション)\]**​ 項目を示しています。 Name (名前) カスタムアラートの分かりやすい名前を入力します。 Severity level (重要度レベル) アラートに適用する重要度レベルを選択します。 - **Critical (重大)** - **Warning (警告)** - **Info (情報)** Source (提供元) アラートの提供元の ​**\[Application (アプリケーション)\]**​ を選択します。 Application type (アプリケーション種別) **\[CloudHub Applications (CloudHub アプリケーション)\]**​ を選択します。 アプリケーション数 カスタムアラートをトリガーするために設定したフローが含まれるアプリケーションを選択します。 Conditional (条件) **\[Custom application notification (カスタムアプリケーション通知)\]**​ を選択します。 - **\[Priority (優先度)\]**​ メニューから優先度を選択するか、または優先度を ​**\[Any (任意)\]**​ のままにして優先度に関係なく通知を送信します。 - **\[Contains (含まれる)\]**​ に通知をトリガーするために使用する文字列を入力します。 この文字列は、CloudHub Connector で設定した ​**\[Message (メッセージ)\]**​ 項目の文字列と一致する必要があります。 Subject (件名) 通知メールに付ける件名を入力します。 Message (メッセージ) 通知に含めるカスタムメッセージを入力します。 Recipients (受信者) 通知受信者のメールアドレスを入力します。 アラートの ​**\[Subject (件名)\]**​ 項目と ​**\[Message (メッセージ)\]**​ 項目では変数を使用できます。 アラートでの変数の使用については、​[「アラート変数」](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager#alert-variables)​を参照してください。 アラートをトリガーすると、指定された受信者はアプリケーションに追加したカスタムメッセージが含まれるメールを受信します。 ## [](#notifications-通知)Notifications (通知) _\[Notifications (通知)\]_​ では、アプリケーション内のビジネス関連のイベントを把握できます。 たとえば、次のような場合に表示される通知を作成できます。 - アプリケーションがリモートサービスに接続できない。 - データマッピングの問題など、人の介入を必要とするエラーが発生した。 - 処理された注文数など、アプリケーションで実行された処理のサマリーを作成したい。
CloudHub では、アプリケーションごとに最大 1000 件の通知を保存できます。 通知の数が最大数を超えると、CloudHub によって最も古い通知が削除されます。 通知ごとに最大 10,000 文字を含めることができます。
### [](#通知をトリガーする)通知をトリガーする CloudHub にデプロイされたアプリケーションの通知をトリガーする手順は、次のとおりです。 1. 次のような、アプリケーションの URL とパスを開きます。 `http://myApp.us-w1.cloudhub.io/store` ページにエラーメッセージが表示され、新しい通知が Runtime Manager コンソールに送信されます。 2. Runtime Manager の ​**\[Applications (アプリケーション)\]**​ ページで、右上にある赤いベルアイコンをクリックすると、通知が表示されます。 ![通知ドロップダウンのエラー](/mulesoft/current/ja-jp/cloudhub/_images/alerts-custom-rtm-notification-error.png) Figure 4. 矢印は、通知ドロップダウンのエラーを示しています。 例外の発生後に通知が送信された場合、Runtime Manager コンソールからアクセスできる ​`exception.message`​ と ​`exception.stacktrace`​ が通知のカスタムプロパティとして含まれます。 ### [](#エラー通知の送信)エラー通知の送信 ``​ コンポーネント内で CloudHub Connector を使用し、エラーの発生時に通知を送信できます。 たとえば、​``​ コンポーネントを使用してエラーメッセージを送信し、フローの処理を停止します。 ```xml ... ... ``` On-Error コンポーネントについては、​[「On-Error コンポーネントを使用したメッセージングエラーの処理」](https://docs.mulesoft.com/mule-runtime/latest/error-handling#on_error_continue)​を参照してください。 ## [](#関連情報)関連情報 - [アラート](https://docs.mulesoft.com/jp/runtime-manager/alerts-on-runtime-manager) - [コネクタを Mule プロジェクトに追加する](https://docs.mulesoft.com/connectors/introduction/intro-config-use-studio#install) - Exchange の [CloudHub Connector](https://www.mulesoft.com/exchange/com.mulesoft.connectors/mule-cloudhub-connector/) - [CloudHub 設定の作成](https://docs.mulesoft.com/jp/cloudhub-connector/latest/#create-the-cloudhub-configuration) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [Mule 4 の概要: エラーハンドラー](https://docs.mulesoft.com/mule-runtime/latest/mule-error-concept) # キューの管理 Runtime Manager の ​**\[Queues (キュー)\]**​ タブから、仮想マシン (VM) または段階的なイベント駆動型アーキテクチャ ( [SEDA](http://en.wikipedia.org/wiki/Staged_event-driven_architecture)​) のキューを、デプロイされたアプリケーションのフロー内で表示および制御できます。 キューは、CloudHub ワーカーにデプロイされたアプリケーションでのみ使用可能です。Runtime Manager からローカルサーバーにデプロイするアプリケーションでは使用できません。詳細は、​[「デプロイメントオプション」](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)​を参照してください。 ![QueuesTab](/mulesoft/current/ja-jp/cloudhub/_images/queuestab.png) CloudHub では、フロー内から自動的にキューが検出され、​**\[Queues (キュー)\]**​ タブにリストされます。 基になるアプリケーションに一切変更を加えずに、以下を行うことができます。 - 各キューでキューに格納されているメッセージと送信中のメッセージの数を確認する。 - 過去 24 時間のキューのスループットをスナップショットとして表示する。 - キューで待機中のすべてのメッセージをクリアする。 また、永続的なキューの保存データの暗号化を有効にすることもできます。これにより、永続的なキューに書き出される共有アプリケーションデータは必ず暗号化されます。 ## [](#ユースケース)ユースケース **\[Queues (キュー)\]**​ タブは、次のようなユースケースで役立ちます。 - アプリケーションのキューを実行時に可視化したい。 - メッセージが期待どおりにキューを通過しているかどうかを確認するためにアプリケーションをテストする。 - アプリケーションがメッセージの処理で停滞しており、問題を解決するためにそのキューだけメッセージを消去したい。 ## [](#キューを有効にする)キューを有効にする キューを有効にする手順は、次のとおりです。 1. 1 つ以上のキューが含まれる CloudHub にアプリケーションをデプロイします。 [「VM Connector」](https://docs.mulesoft.com/jp/vm-connector/latest/)​を参照してください。 2. Runtime Manager で、アプリケーションをクリックし、​**\[Manage Application (アプリケーションを管理)\]**​ をクリックします。 3. ​**\[Persistent queues (永続的なキュー)\]**​ のチェックボックスをクリックします。 4. アプリケーションをデプロイするときにこの設定を有効にする場合は、​**\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。 既存のアプリケーションを更新する場合は、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ![PersistentQueuesSetOnDeploy](/mulesoft/current/ja-jp/cloudhub/_images/persistentqueuessetondeploy.png) ## [](#キューの表示)キューの表示 \[Persistent queues (永続的なキュー)\] を有効にした後、左ナビゲーションメニューの ​**\[Queues (キュー)\]**​ をクリックします。アプリケーション内のキューがアプリケーションに表示される順序でリストされます。 ![CHQConsole](/mulesoft/current/ja-jp/cloudhub/_images/chqconsole.png) 各キューの名前は、関連付けられた VM エンドポイントの ​`path`​ 属性によって、または SEDA キューの場合はフロー名から判断されます。 - **\[Queued (キュー内)\]**​ 列には、アプリケーションの各キューで現在待機中のメッセージ数が表示されます。 - **\[In-Flight (インフライト)\]**​ 列には、そのキューの後にフローで処理中のメッセージ数が表示されます。 インフライトメッセージは処理が完了するまでまだキュー内にあり、完了後にキューから削除されます。 - **\[Processed Messages (処理済みメッセージ)\]**​ 列には、過去 24 時間に各キューを通過して処理されたメッセージ数を表すサムネイルグラフが表示されます。 **\[Queued (キュー内)\]**​ 列と ​**\[In-Flight (インフライト)\]**​ 列は 5 秒ごとに更新され、​**\[Processed Messages (処理済みメッセージ)\]**​ のグラフは 5 分ごとに更新されます。 ## [](#キューのクリア)キューのクリア 1 つまたは複数のキューをクリアするには、クリアするキューのチェックボックスをオンにしてから ​**\[Clear (クリア)\]**​ をクリックします。 ![CHQClearQ](/mulesoft/current/ja-jp/cloudhub/_images/chqclearq.png) Runtime Manager は、クリアするキューとこのプロセスの所要時間を確認する警告メッセージを表示します。​**\[Clear Queues (キューをクリア)\]**​ をクリックして続行します。 ![CHQClear](/mulesoft/current/ja-jp/cloudhub/_images/chqclear.png) 確認した後、選択したキューにはクリアプロセスが完了するまで「Clearing queue in progress (キューをクリアしています)」メッセージが表示されます。 ![CHQClearInProgress](/mulesoft/current/ja-jp/cloudhub/_images/chqclearinprogress.png) キューをクリアすると、キュー内の待機中メッセージとインフライトメッセージがすべて消去されます。キューがクリアされると、キューは直ちにメッセージの受け入れを再開します。 ## [](#永続的なキュー内の保存データの暗号化)永続的なキュー内の保存データの暗号化 すべての永続的なキューで保存時のデータの暗号化を有効にできます。この機能を有効にすると、永続的なキューに書き込まれる共有アプリケーションデータが暗号化され、セキュリティとコンプライアンスのニーズを満たすことができます。 ![有効化 + 暗号化](/mulesoft/current/ja-jp/cloudhub/_images/enable-encripting.png)
暗号化を有効にして、その後無効にすると、以前に暗号化されているメッセージは読み取り不可になります。
## [](#batch-コンポーネントと永続的なキュー)Batch コンポーネントと永続的なキュー Mule アプリケーションで Batch コンポーネントおよび永続的なキューを使用している場合、バッチレコードが複数回処理されることがあります。 すべてのバッチレコードは Amazon SQS に保存され、デフォルトではメッセージの表示が 70 秒に設定されています。 バッチプロセスの実行時間が 70 秒を超える場合、バッチプロセスは同じメッセージを再度認識して、メッセージを複数回処理することがあります。 この問題を回避するには、アプリケーションの ​**\[Settings (設定)\]**​ ページの ​**\[Properties (プロパティ)\]**​ タブで ​`persistent.queue.min.timeout`​ システムパラメーターを大きな値に設定します。 たとえば、バッチプロセスの完了まで 30 分かかる場合、値を ​`persistent.queue.min.timeout=2700000`​ ミリ秒 (45 分) に設定します。 最大値は 43000000 ミリ秒 (12 時間) です。 ## [](#制限事項)制限事項 アプリケーションで永続的なキューを有効にする場合は、次の点に注意してください。 - 永続的なキューでは 1 回のみのメッセージ配信は保証されません。重複するメッセージが送信される場合もあります。1 回のみのメッセージ配信が重要なユースケースの場合、永続的なキューを有効にしないでください。 - **\[Queues (キュー)\] タブ**​を使用してキューをクリアする場合、キューのクリアプロセス中にキューに送信された新しいメッセージは失われる可能性があります。 - 永続的なキューを有効にすると、パフォーマンスへの影響があります。小さなメッセージ (50kb 以下) をキューに追加するには 10 ~ 20 ミリ秒 (ms) かかります。一方で、同じメッセージをキューから削除するのには 70 ~ 100ms かかることがあります。 ## [](#関連情報)関連情報 - [永続的なキュー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-fabric#persistent-queues) - [信頼性パターン](https://docs.mulesoft.com/mule-runtime/latest/reliability-patterns) - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [Anypoint Studio](https://docs.mulesoft.com/studio/) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [CloudHub アーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture) - [アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [スケジュールの管理](https://docs.mulesoft.com/jp/cloudhub/managing-schedules) - [オブジェクトストアを使用したアプリケーションデータの管理](https://docs.mulesoft.com/jp/cloudhub/managing-application-data-with-object-stores) - [Anypoint Platform コマンドラインインターフェース](https://docs.mulesoft.com/jp/anypoint-cli/latest/) - [アプリケーションプロパティの保護](https://docs.mulesoft.com/jp/cloudhub/secure-application-properties) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [侵入テストポリシー](https://docs.mulesoft.com/jp/cloudhub/penetration-testing-policies) # スケジュールの管理 Runtime Manager を使用して、デプロイされたアプリケーションのフロー内の Scheduler コンポーネントの表示と制御を行うことができます。 左側のナビゲーションメニューにある ​**\[Schedules (スケジュール)\]**​ タブを使用して、実行中のアプリケーションを変更することなく、Scheduler 要素を有効化または無効化するか、頻度を変更するか、スケジュール済みジョブを直ちに実行します。 **\[Schedules (スケジュール)\]**​ タブは、次のようなユースケースで特に役立ちます。 - 毎晩実行するジョブがあるが、今すぐデバッグしたい。 アプリケーションでスケジュールを更新しなくても、実行中のジョブをトリガーできます。 - 再デプロイせずに実行時にアプリケーションでスケジュールを変更したい。 - 接続しているアプリケーションのうちの 1 つがメンテナンス中である間に、スケジュールされたジョブを無効にしたい場合。 - アプリケーション内のスケジュールを実行時に可視化したい場合。 CloudHub スケジューラーは、毎回の実行時にジョブ設定を読み取ります。 スケジューラー設定を更新した場合、次回スケジューラーが実行されるときに変更が有効になります。
スクリプトを使用して CloudHub のスケジュールを管理することはできません。 CloudHub のスケジュールを管理するには、​[Schedules (スケジュール)]​ タブまたは CloudHub API を使用してください。
## [](#考慮事項と制限事項)考慮事項と制限事項 スケジュールを設計するときには、次の点を考慮してください。 - ネットワーク障害、ハードウェアの問題や定期メンテナンスによるインフラストラクチャの再起動、セキュリティ更新の間の高可用性を計画します。 サービス更新やセキュリティパッチ適用中、CloudHub では既存のスケジュールが完了するまで 2 分待機します。 2 分後に、CloudHub によって未完了のスケジュールが再トリガーされます。 長時間実行されるスケジュールの再トリガーを避けるために、アプリケーションによってフローが冪等で実行されるようにしてください。 - 上記の問題が原因で 2 回以上トリガーされる可能性があるため、データ処理の重複を避けるようスケジュールをデザインします。 - マルチワーカーアプリケーションの場合、CloudHub ではスケジュールトリガーが 1 つのワーカーで実行されることを保証します。 ただし、以降のトリガーは別のワーカーで実行される場合もあります。 CloudHub では、複数の同時スケジュールがワーカー間で分散されます。 - コール間の最小の推奨頻度は 10 秒です。 - アプリケーションが実行されていないためにスケジュールされたジョブがトリガーされない場合は、CloudHub では、再起動されるとすぐにジョブをトリガーします。 - Mule 4.x アプリケーションでスケジュールを使用してサブフローが含まれるフローをトリガーする場合、スケジューラーは次の実行をスケジュールする前にメインフローとサブフローの両方が完了するまで待機します。 フロー名には、文字 (a-zA-Z)、数字 (0-9)、ハイフン (-)、アンダースコア (\_)、ピリオド (.) の各文字のみを含めることができます。 - アプリケーションをデプロイしている地域に関係なく、スケジュールはすべて UTC タイムゾーンに基づきます。 ## [](#runtime-manager-でアプリケーションを表示して管理する)Runtime Manager でアプリケーションを表示して管理する Runtime Manager のスケジュール機能を使用するには、1 つ以上の Scheduler 要素を含むアプリケーションをデプロイします。 ![Anypoint Studio キャンバスの Scheduler コンポーネント](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-scheduler-studio.png) Figure 1. 矢印は、Anypoint Studio キャンバスの ​**Scheduler**​ コンポーネントを示しています。 このサンプルアプリケーションは Exchange からダウンロードできます。 アプリケーションを CloudHub にデプロイしたら、Runtime Manager で Scheduler 要素を表示して管理します。 1. 左ペインで ​**\[Applications (アプリケーション)\]**​ をクリックし、アプリケーションをクリックしてから ​**\[Schedules (スケジュール)\]**​ をクリックします。 ![\[Schedules (スケジュール)\] ページの \[Logs (ログ)\] オプション、\[Last Run (最終実行)\] 列、頻度リンク](_images/cloudhub-scheduler-rtm.png) Figure 2. このスクリーンショットは、​**\[Schedules (スケジュール)\]**​ ページの (​**1**​) ​**\[Logs (ログ)\]**​ オプション、(​**2**​) ​**\[Last Run (最終実行)\]**​ 列、(​**3**​) 頻度リンクを示しています。 **\[Last Run (最終実行)\]**​ 列には、各 Scheduler 要素が最後に実行された日時が表示されます。 左側のナビゲーションメニューにある ​**\[Logs (ログ)\]**​ をクリックすると、スケジュールされたジョブの実行がいつ開始され、終了したのかについて詳細を参照できます。 Runtime Manager では、Scheduler 要素がアプリケーションに表示される順序でリストされます。 2. 管理する要素を選択してから、以下を実行します。 - スケジュールを上書きしてジョブを直ちに実行する場合は、​**\[Run now (今すぐ実行)\]**​ をクリックします。 - Scheduler 要素をサスペンドする場合は、​**\[Disable (無効化)\]**​ をクリックします。 再び有効化されるまで、スケジュールされたジョブは実行されません。 - **\[Schedule (スケジュール)\]**​ 列で頻度リンクをクリックして、スケジュールエディターを開きます。 ![スケジュールエディターの \[Switch to advanced mode (高度なモードに切り替え)\] リンク](_images/cloudhub-scheduler-frequency.png) Figure 3. 矢印は、スケジュールエディターの ​**\[Switch to advanced mode (高度なモードに切り替え)\]**​ リンクを示しています。 スケジュールエディターで、スケジュールの頻度を変更するか、または ​**\[Enabled (有効化)\]**​ チェックボックスをオフにしてスケジュールを無効にします。 頻度の値としては 10 ~ 100 秒を指定できます。 また、高度なモードに切り替えて Cron 式を使用することで、「毎週木曜日の午後 3 時 00 分」のような詳細なスケジュールを作成することもできます。
デフォルトでは、スケジュールはアプリケーションで定義された頻度で実行されます。Runtime Manager でスケジュールの頻度を変更すると、同じスケジュールをアプリケーションの JAR ファイルで更新して再デプロイしても、スケジュールは Runtime Manager で設定された頻度で実行されます。
3. **\[Update (更新)\]**​ をクリックして設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#cron-式の使用)Cron 式の使用 Cron 式を使用すると、「毎週金曜日の午前 9 時 00 分から午前 10 時 00 分まで 5 分おき」といった複雑なスケジュール頻度を作成できます。 Cron 式を使用してスケジュール頻度を指定する手順は、次のとおりです。 1. スケジュールエディターで ​**\[Switch to advanced mode (高度なモードに切り替え)\]**​ をクリックします。 2. 高度なモードページで ​**\[Quick reference (クイックリファレンス)\]**​ をクリックして、必須項目と許可される値のテーブルを展開するか折りたたみます。 ![高度なモードページの \[Quick reference (クイックリファレンス)\] 切り替え、\[more (その他)\] リンク、\[Switch to basic mode (基本モードに切り替え)\] リンク](_images/cloudhub-scheduler-cron.png) Figure 4. このスクリーンショットは、高度なモードページの (​**1**​) ​**\[Quick reference (クイックリファレンス)\]**​ 切り替え、(​**2**​) ​**\[more (その他)\]**​ リンク、​**\[Switch to basic mode (基本モードに切り替え)\]**​ リンクを示しています。 この例の Cron 式は、10 秒間隔 (サポートされる最小限の頻度) のスケジュールを設定しています。 このページで、次の手順を実行します。 - **\[more (詳細)\]**​ をクリックして [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation)​を表示し、Cron トリガーの作成方法を確認します。 バージョンを選択し、​**\[Documentation (ドキュメント)\] > \[User’s Guide (ユーザーガイド)\] > \[Tutorial (チュートリアル)\]**​ をクリックして、​**\[CronTrigger\]**​ レッスンをクリックします。
スケジュールはすべて UTC タイムゾーンに基づくため、タイムゾーン設定は無視されます。
- 詳細モードを終了する場合は ​**\[Switch to basic mode (基本モードに切り替え)\]**​ をクリックします。 3. **\[Update (更新)\]**​ をクリックして Cron 設定の変更内容を保存するか、または ​**\[Cancel (キャンセル)\]**​ をクリックして保存せずに終了します。 ## [](#関連情報)関連情報 - [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub) - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [アプリケーションの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [スケジューラーエンドポイント (トリガー)](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Poll コンポーネントの移行](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept) - [Exchange のサンプルアプリケーション](https://www.mulesoft.com/exchange/org.mule.examples/sending-a-csv-file-through-email-using-smtp/) - [Quartz ドキュメント](http://www.quartz-scheduler.org/documentation) # トランジットゲートウェイアタッチメント AWS トランジットゲートウェイは AWS のクラウドルーターとして機能し、VPC、オンプレミスデータセンター、サードパーティソフトウェア間のネットワークアクセスを簡略化すると同時に、ネットワークの可視性を高め、制御を強化します。 トランジットゲートウェイは、事実上組織のクラウドリソースとオンプレミスデータセンターを 1 つのネットワークトポロジーにマージするものです。 CloudHub では、Anypoint Virtual Private Cloud (VPC) を AWS アカウントの AWS トランジットゲートウェイに安全にアタッチすることでこのネットワークの簡略化を活用できます。 複数のトランジットゲートウェイを Anypoint Platform 組織に追加できます。 追加できるトランジットゲートウェイの数は、アカウントで利用できるネットワーク接続エンタイトルメントによって異なります。 自分のアカウントに割り当てられているエンタイトルメントが不明な場合は、MuleSoft アカウント担当者までお問い合わせください。 ## [](#制限事項)制限事項 次の値は AWS の制限を受けます。 - VPC ごとのトランジットゲートウェイの最大数 - トランジットゲートウェイにアタッチできる VPC の最大数 VPC を AWS トランジットゲートウェイにアタッチする場合の制限については、AWS ドキュメントの [「Transit gateway attachments to a VPC (VPC へのトランジットゲートウェイアタッチメント)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)​を参照してください。 ## [](#関連情報)関連情報 - [トランジットゲートウェイへのアタッチ](https://docs.mulesoft.com/jp/cloudhub/tgw-attach-arm) - 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) # トランジットゲートウェイアタッチメントのトラブルシューティング 以下に、トランジットゲートウェイへのアタッチを試みると発生する可能性があるエラーをいくつか示します。 ## [](#トランジットゲートウェイにアタッチできない)トランジットゲートウェイにアタッチできない トランジットゲートウェイへのアタッチを試みたときに ​`Resource Share Not Found`​ エラーが表示された場合は、次の手順を実行してください。 1. 指定した ​**\[ID\]**​ および ​**\[Owner (オーナー)\]**​ の値が正しいことを確認します。 2. リージョンがトランジットゲートウェイのリージョンと一致することを確認します。 3. これらの値を編集するには鉛筆アイコンをクリックします。 ## [](#トランジットゲートウェイを削除できない)トランジットゲートウェイを削除できない **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページに VPC がリストされていないがトランジットゲートウェイを削除できず ​`Can’t remove this transit gateway`​ エラーが表示された場合、アクセス権のない別のビジネスグループに属す VPC にトランジットゲートウェイがアタッチされている可能性もあります。 ## [](#トランジットゲートウェイを表示できない)トランジットゲートウェイを表示できない Runtime Manager では、常にルートビジネスグループレベルでトランジットゲートウェイを追加します。 トランジットゲートウェイを表示するには、「CloudHub Network Viewer (CloudHub ネットワーク閲覧者)」権限が必要です。 ## [](#トランジットゲートウェイを変更できない)トランジットゲートウェイを変更できない トランジットゲートウェイを変更するには、「CloudHub Network Admin (CloudHub ネットワーク管理者)」権限が必要です。 ## [](#トランジットゲートウェイの状況が不明である)トランジットゲートウェイの状況が不明である トランジットゲートウェイの状況が ​`Unknown`​ の場合、AWS のリソース共有が無効にされているか削除されています。 **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページの ​**\[View on AWS (AWS で表示)\]**​ ボタンをクリックして、AWS でこの問題を解決してください。 ![\[Transit Gateways (トランジットゲートウェイ)\] ページの \[View on AWS (AWS で表示)\] ボタン](_images/tgw-view-on-aws.png) ## [](#vpc-アタッチメントが拒否される)VPC アタッチメントが拒否される トランジットゲートウェイへの VPC のアタッチを試みたときに ​`The attachment was rejected in AWS`​ エラーが表示された場合は、VPC を削除して再アタッチします。 [「トランジットゲートウェイから Anypoint VPC を削除する」](https://docs.mulesoft.com/jp/cloudhub/tgw-manage-arm#remove-an-anypoint-vpc-from-the-transit-gateway)​を参照してください。 ## [](#サブネットがすでにルートテーブルに追加されている)サブネットがすでにルートテーブルに追加されている `This subnet has already been added to this route table`​ エラーが表示された場合、別のサブネットをテーブルに追加します。 ## [](#cidr-サブネットが無効である)CIDR サブネットが無効である `Please enter a single subnet in CIDR notation`​ エラーが表示された場合は、サブネットが正しい CIDR 形式であることを確認します。 ## [](#attach-vpc-vpc-をアタッチ-ボタンが無効である)\[Attach VPC (VPC をアタッチ)\] ボタンが無効である **\[Attach VPC (VPC をアタッチ)\]**​ ボタンが無効な場合、アクセスできるすべての VPC がすでにトランジットゲートウェイにアタッチされています。 ## [](#接続の上限に達した)接続の上限に達した `Connections limit has been reached (max=4, used=4) for the organization`​ のようなエラーが表示された場合、すべてのネットワーク接続エンタイトルメント (VPC/VPN ライセンス) をコンシュームしています。 アカウントチームに連絡して追加のライセンスをご購入ください。 ## [](#関連情報)関連情報 - [トランジットゲートウェイのルートテーブルからのルートの削除](https://docs.mulesoft.com/jp/cloudhub/tgw-manage-arm#remove-a-route-from-the-transit-gateway-route-table) - [トランジットゲートウェイのルートテーブルへのルートの追加](https://docs.mulesoft.com/jp/cloudhub/tgw-manage-arm#add-a-route-to-the-transit-gateway-route-table) - AWS ドキュメントの [「Troubleshoot VPC attachment creation (VPC アタッチメント作成のトラブルシューティング)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#transit-gateway-vpc-attch-troubleshooting) # トランジットゲートウェイアタッチメントの管理 Anypoint Runtime Manager を使用して、ルートテーブルからのルートの追加や削除、またはトランジットゲートウェイからの Anypoint VPN のデタッチなど、トランジットゲートウェイアタッチメントを管理します。 ## [](#トランジットゲートウェイアタッチメントの名前を変更する)トランジットゲートウェイアタッチメントの名前を変更する AWS のアタッチメント名に合うようにトランジットゲートウェイアタッチメントの名前を変更する必要がある場合もあります。 トランジットゲートウェイアタッチメントの名前を変更する手順は、次のとおりです。 1. **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページで、トランジットゲートウェイメニュー (​**\[…​\]**​) をクリックして ​**\[Edit name (名前を編集)\]**​ を選択します。 ![トランジットゲートウェイメニューの \[Edit name (名前を編集)\] オプション](_images/tgw-rename.png) 2. ポップアップウィンドウに名前を入力し、​**\[Save (保存)\]**​ をクリックします。 ## [](#トランジットゲートウェイのルートテーブルへのルートの追加)トランジットゲートウェイのルートテーブルへのルートの追加 トランジットゲートウェイを通じて新しいサブネットにアクセスできるようにするために、ルートを追加する必要がある場合もあります。 1. Anypoint Platform で、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ > ​**\[VPCs (VPC)\]**​ に移動して ​**\[Add Route (ルートを追加)\]**​ をクリックします。 2. **\[Add VPC Route (VPC ルートを追加)\]**​ ウィンドウで、CIDR 表記を使用して AWS VPC のサブネットを 1 つ入力します。 ![「Add VPC route (VPC ルートを追加)」](/mulesoft/current/ja-jp/cloudhub/_images/tgw-add-vpc-route.png) 3. **\[Add Route (ルートを追加)\]**​ をクリックします。 Anypoint Platform により、AWS への新しいルートが送信されます。
新しいルートを追加すると、プラットフォームで VPC の既存のルートと競合していないか、静的であるか、または BGP 接続から伝播されているかどうかが確認されます。新しいルートが重複している場合、既存のルートを削除するか、新しいルートを小さいルートに分割して競合を回避します。
ルートの追加に成功したら、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページに ​**\[Route added (ルートが追加されました)\]**​ というメッセージが表示され、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページのルートテーブルにルートの CIDR が表示されます。 ルートテーブルで、追加されたルートの ​**\[Next Hop (次のホップ)\]**​ 列の値として ​**\[Transit Gateway (トランジットゲートウェイ)\]**​ が表示されます。 トランジットゲートウェイにアタッチされた特定のルートは、​**\[Transit Gateway Routes (トランジットゲートウェイルート)\]**​ に表示されます。VPC のその他のルートは、​**\[VPC Routes (VPC ルート)\]**​ に表示されます。 ![ルートテーブルの \[Next Hop (次のホップ)\] 列の \[Transit Gateway (トランジットゲートウェイ)\]](_images/tgw-route-added.png) ## [](#トランジットゲートウェイのルートテーブルからのルートの削除)トランジットゲートウェイのルートテーブルからのルートの削除 トランジットゲートウェイからサブネットにアクセスできる必要がなくなった場合、ルートを削除する必要がある場合もあります。 ルートを削除する手順は、次のとおりです。 1. **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページの ​**\[VPCs (VPC)\]**​ セクションで、ルートテーブルの適切なトランジットゲートウェイルート行の ​**\[X\]**​ アイコンをクリックします。 ![「VPCs (VPC)」 セクションのルートの削除アイコン](/mulesoft/current/ja-jp/cloudhub/_images/tgw-remove-vpc-route.png) 2. 確認プロンプトで ​**\[Remove (削除)\]**​ をクリックします。 ## [](#トランジットゲートウェイから-anypoint-vpc-をデタッチする)トランジットゲートウェイから Anypoint VPC をデタッチする 再アタッチできるように VPC をデタッチする必要がある場合もあります。 トランジットゲートウェイから VPC をデタッチすると、AWS のアタッチメントも削除されます。 VPC にデプロイされたアプリケーションは引き続き動作しますが、Amazon VPC および VPN には接続されなくなります。 トランジットゲートウェイから VPC をデタッチする手順は、次のとおりです。 1. **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページで、VPC メニュー (​**\[…​\]**​) をクリックして ​**\[Detach (デタッチ)\]**​ を選択します。 ![VPC メニューの \[Detach VPC (VPC をデタッチ)\] オプション](_images/tgw-detach-vpc.png) 2. 確認プロンプトで ​**\[Detach (デタッチ)\]**​ をクリックします。 VPC のデタッチには数分かかることもあります。 ## [](#トランジットゲートウェイから-anypoint-vpc-を削除する)トランジットゲートウェイから Anypoint VPC を削除する AWS でアタッチメントを拒否した場合、Anypoint Platform で VPC アタッチメントが ​`rejected`​ と表示されます。 この場合、もう一度アタッチを試みる前にアタッチメントを削除する必要があります。 トランジットゲートウェイから VPC を削除する手順は、次のとおりです。 1. **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページで、VPC メニュー (​**\[…​\]**​) をクリックして ​**\[Remove (削除)\]**​ を選択します。 2. 確認プロンプトで ​**\[Remove (削除)\]**​ をクリックします。 VPC の削除には数分かかることもあります。 VPC が削除されたら、​**\[Attach VPC (VPC をアタッチ)\]**​ ボタンが使用できるようになります。 ## [](#anypoint-platform-からトランジットゲートウェイを削除する)Anypoint Platform からトランジットゲートウェイを削除する エンタイトルメントの上限に達した場合や新しいトランジットゲートウェイへの接続を切り替える場合は、トランジットゲートウェイを削除する必要がある場合もあります。 トランジットゲートウェイに VPC がアタッチされていない場合、Anypoint Platform から削除できます。
トランジットゲートウェイを削除すると、AWS で Anypoint Platform でトランジットゲートウェイにアクセスするために使用しているリソース共有が削除されます。
Anypoint Platform からトランジットゲートウェイを削除する手順は、次のとおりです。 1. **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページで、トランジットゲートウェイメニュー (​**\[…​\]**​) をクリックして ​**\[Remove (削除)\]**​ を選択します。 ![トランジットゲートウェイメニューの \[Remove (削除)\] オプション](_images/tgw-remove.png) VPC がアタッチされている場合、Anypoint Platform ではトランジットゲートウェイを削除できません。 **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページに VPC がリストされていないがトランジットゲートウェイを削除できない場合、アクセス権のない別のビジネスグループに属す VPC にトランジットゲートウェイがアタッチされている可能性もあります。 2. 確認プロンプトで ​**\[Remove (削除)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [トランジットゲートウェイアタッチメントのトラブルシューティング](https://docs.mulesoft.com/jp/cloudhub/tgw-troubleshoot) - [トランジットゲートウェイへのアタッチ](https://docs.mulesoft.com/jp/cloudhub/tgw-attach-arm) - [トランジットゲートウェイアタッチメント](https://docs.mulesoft.com/jp/cloudhub/tgw-about) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [Runtime Manager の VPC の作成と更新](https://docs.mulesoft.com/jp/cloudhub/vpc-tutorial) - [ユーザーへの権限とロールの付与](https://docs.mulesoft.com/jp/access-management/users#grant-permissions-and-roles-to-users) # トランジットゲートウェイへのアタッチ Anypoint Runtime Manager を使用してトランジットゲートウェイを追加し、Anypoint Virtual Private Cloud (VPC) を非公開企業ネットワークに接続します。 ## [](#前提条件)前提条件 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 ライセンスを使用します。ビジネスグループに割り当てられたライセンスは、​**\[Access Management (アクセス管理)\]**​ > ​**\[Organizations (組織)\]**​ に移動して関連するビジネスグループを選択することで確認または編集できます。必要に応じて ​**\[Network Connection (ネットワーク接続)\]**​ オプションを更新または表示し、変更内容を保存します。 - 「CloudHub Network Administrator (CloudHub ネットワーク管理者)」または「CloudHub Network Viewer (CloudHub ネットワーク閲覧者)」ユーザー権限を使用して Anypoint Platform アカウントにサインインします。 [「Grant Permissions and Roles to Users (ユーザーへの権限とロールの付与)」](https://docs.mulesoft.com/jp/access-management/users#grant-permissions-and-roles-to-users)​を参照してください。 - Anypoint Platform で Anypoint VPC を作成します。 [「Runtime Manager の VPC の作成と更新」](https://docs.mulesoft.com/jp/cloudhub/vpc-tutorial)​を参照してください。 - トランジットゲートウェイを通じてアクセス可能にするネットワークのサブネットを識別 (CIDR 表記) します。 ## [](#トランジットゲートウェイアタッチメントのワークフロー)トランジットゲートウェイアタッチメントのワークフロー トランジットゲートウェイをアタッチする手順は、次のとおりです。 1. [AWS でリソース共有を作成](#create_resource_share)​してトランジットゲートウェイを Anypoint Platform と共有することで、Anypoint Platform に​[トランジットゲートウェイを追加します](#add_tgw)​。 2. トランジットゲートウェイに ​[VPC をアタッチ](#attach_vpc_tgw)​し、AWS で ​[VPC アタッチメントを受け入れ](#accept_attachment)​ます。 3. [トランジットゲートウェイのルーティングを設定します](#configure_tgw_routing)​。 1. [Anypoint VPC からのアウトバウンドトラフィックを有効化します](#enable_outbound_traffic_from_vpc)​。 2. [AWS でのトランジットゲートウェイを通じたインバウンドトラフィックを有効化します](#enable_inbound_traffic_on_aws)​。 ## [](#add_tgw)トランジットゲートウェイを追加する トランジットゲートウェイを追加する手順は、次のとおりです。 1. Anypoint Platform にサインインし、​**\[Runtime Manager\]**​ を選択します。 2. Runtime Manager ナビゲーションメニューで ​**\[Transit Gateways (トランジットゲートウェイ)\]**​ をクリックし、​**\[Add Transit Gateway (トランジットゲートウェイを追加)\]**​ をクリックします。 **\[Here’s what’s coming (次の手順)\]**​ ページにトランジットゲートウェイを追加する手順がリストされます。 ![「Here’s what’s coming (次の手順)」 ページ](/mulesoft/current/ja-jp/cloudhub/_images/tgw-process-overview.png) 3. **\[I’m ready (準備ができました)\]**​ をクリックします。 4. トランジットゲートウェイの名前を指定します。 ![「Add transit gateway (トランジットゲートウェイを追加)」 ページ](/mulesoft/current/ja-jp/cloudhub/_images/tgw-add.png) AWS のトランジットゲートウェイに同じ名前を使用します。 この名前は後から変更できます。 名前には最大 255 文字の英数字 (a-z、A-Z、0-9) およびハイフン (-) を含めることができます。 5. AWS トランジットゲートウェイの場所に対応するリージョンを選択します。 [「リージョンサービス」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-networking-guide#regional-services)​を参照してください。 Anypoint VPC と AWS トランジットゲートウェイは同じリージョンにある必要があります。 6. **\[Next (次へ)\]**​ をクリックします。 **\[Add transit gateway (トランジットゲートウェイを追加)\]**​ ページに AWS でリソース共有を作成する手順がリストされます。 ![「Add transit gateway (トランジットゲートウェイを追加)」 ページ: リソース共有を作成する手順](/mulesoft/current/ja-jp/cloudhub/_images/tgw-add-overview.png)
このステップでは、Anypoint VPC に関連する MuleSoft AWS アカウント ID が表示されます。この ID は変動するため、AWS 設定には必ずこのステップで表示されるアカウント ID を使用してください。AWS 設定が組織内の他のチームまたはリソースによって実行される場合は、この MuleSoft AWS アカウント ID を実行者と共有してください。
## [](#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 (外部アカウントを許可)\]**​ が選択されていることを確認し、​**\[Add transit gateway (トランジットゲートウェイを追加)\]**​ ページに表示される MuleSoft AWS アカウント ID を入力し、​**\[Add (追加)\]**​ をクリックします。 AWS アカウント番号が ​**\[Selected principals (選択したプリンシパル)\]**​ 項目に表示されます。 4. 必要に応じて、​**\[Tags (タグ)\]**​ でタグを追加します。 5. **\[Create resource share (リソース共有を作成)\]**​ をクリックします。 6. 作成したばかりのリソース共有の ​**\[ID\]**​ 値と ​**\[Owner (オーナー)\]**​ 値をコピーします。 4. Anypoint Platform の ​**\[Add transit gateway (トランジットゲートウェイを追加)\]**​ ウィンドウで次のアクションを実行します。 1. **\[Next (次へ)\]**​ をクリックします。 2. AWS からコピーした値を ​**\[ID\]**​ 項目と ​**\[Owner (オーナー)\]**​ 項目に貼り付けます。 ![「Add transit gateway (トランジットゲートウェイを追加)」 ページ: リソース共有 ID およびオーナー ID](/mulesoft/current/ja-jp/cloudhub/_images/tgw-add-resource-share.png) - リソース共有の ​**\[ID\]**​ 項目には英数字 (a-z、A-Z、0-9) およびハイフン (-) を使用できます。 - リソース共有の ​**\[Owner (オーナー)\]**​ 項目には数値しか使用できません。 3. **\[Add (追加)\]**​ をクリックします。 **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページには、AWS に接続してトランジットゲートウェイを Anypoint Platform に追加する進捗状況が表示されます。 トランジットゲートウェイの追加に成功すると、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページには ​**\[Transit gateway added (トランジットゲートウェイが追加されました)\]**​ というメッセージが表示されます。 **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページで、AWS からのオーナーおよび ID と状態が ​**\[Available (使用可能)\]**​ と更新されます。 ![Transit gateway added (トランジットゲートウェイが追加されました)](/mulesoft/current/ja-jp/cloudhub/_images/tgw-resource-share-available.png) トランジットゲートウェイの追加に失敗した場合は、​[「トランジットゲートウェイアタッチメントのトラブルシューティング」](https://docs.mulesoft.com/jp/cloudhub/tgw-troubleshoot)​を参照してください。 ## [](#attach_vpc_tgw)Anypoint VPC をトランジットゲートウェイにアタッチする トランジットゲートウェイアタッチメントに成功したら、Anypoint VPC をアタッチしてアプリケーションがトランジットゲートウェイにアクセスできるようにします。 Anypoint VPC をトランジットゲートウェイにアタッチする場合の制限については、AWS ドキュメントの [「Transit gateway attachments to a VPC (VPC へのトランジットゲートウェイアタッチメント)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html)​を参照してください。 Anypoint VPC をトランジットゲートウェイにアタッチする手順は、次のとおりです。 1. Anypoint Platform の ​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページで、​**\[Attach VPC (VPC をアタッチ)\]**​ をクリックします。 **\[Attach VPC (VPC をアタッチ)\]**​ ボタンは、アタッチできる VPC がない場合、またはトランジットゲートウェイの追加に失敗した場合は無効になります。 2. **\[Select VPC (VPC を選択)\]**​ ウィンドウから、アタッチする VPC を選択します。 ![「Select VPC (VPC を選択)」 ウィンドウ](/mulesoft/current/ja-jp/cloudhub/_images/tgw-select-vpc.png) ウィンドウには、次の条件を満たす VPC のみが表示されます。 - トランジットゲートウェイと同じリージョンにある。 - まだトランジットゲートウェイにアタッチされていない。 - 「CloudHub Network Administrator (CloudHub ネットワーク管理者)」権限を持つビジネスグループにある。 3. **\[Next (次へ)\]**​ をクリックします。 ## [](#accept_attachment)VPC アタッチメントを受け入れる 1. AWS 企業アカウントにサインインします。 2. Anypoint Platform の ​**\[Accept VPC Attachment (VPC アタッチメントを受け入れる)\]**​ ページで、​**\[Transit Gateway Attachments (トランジットゲートウェイアタッチメント)\]**​ リンクをクリックします。 ![「Accept VPC Attachment (VPC アタッチメントを受け入れる)」 ページ](/mulesoft/current/ja-jp/cloudhub/_images/tgw-accept-vpc-attachment.png) このリンクにより、​**\[Create Transit Gateway Attachment (トランジットゲートウェイアタッチメントを作成)\]**​ ページへの AWS RAM コンソールが開きます。 3. AWS コンソールで、次の手順を実行します。 1. **\[State (状態)\]**​ 列に ​**\[pending acceptance (受け入れの保留中)\]**​ と表示されているアタッチメントを選択します。 アタッチメントが表示されるまで数分かかる場合もあります。 2. トランジットゲートウェイアタッチメント ID を選択し、​**\[Details (詳細)\]**​ タブで、​**\[Resource owner account ID (リソースオーナーアカウント ID)\]**​ が MuleSoft AWS アカウント ID であることを確認します。 3. アタッチメントの鉛筆アイコンをクリックして、名前を入力します。 4. **\[Actions (アクション)\]**​ > ​**\[Accept (受け入れる)\]**​ を選択し、​**\[Accept (受け入れる)\]**​ をクリックして確定します。 アタッチメントの受け入れに成功したら、​**\[State (状態)\]**​ 列に ​**\[available (使用可能)\]**​ と表示されます。 4. Anypoint Platform の ​**\[Accept VPC Attachment (VPC アタッチメントを受け入れる)\]**​ ウィンドウで、​**\[Done (完了)\]**​ をクリックします。 **\[Transit Gateways (トランジットゲートウェイ)\]**​ ページには、Anypoint Platform から AWS への VPC アタッチメントを受け入れる進捗状況が表示されます。 ![VPC アタッチメント状況の確認](/mulesoft/current/ja-jp/cloudhub/_images/tgw-checking-attachment-status.png) 5. **\[Refresh (更新)\]**​ をクリックして、アタッチメント状況を更新します。 VPC アタッチメントに成功したら、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページに ​**\[VPC attached (VPC がアタッチされました)\]**​ というメッセージが表示され、アタッチメント状況で AWS トランジットゲートウェイにアタッチされたことが示されます。 ![VPC が正常にアタッチされた](/mulesoft/current/ja-jp/cloudhub/_images/tgw-attached.png) VPC アタッチメント状態が ​`Rejected`​ の場合は、​[「トランジットゲートウェイアタッチメントのトラブルシューティング」](https://docs.mulesoft.com/jp/cloudhub/tgw-troubleshoot)​を参照してください。 ## [](#configure_tgw_routing)トランジットゲートウェイのルーティングの設定 Anypoint VPC では、トランジットゲートウェイの静的ルーティングがサポートされています。 トランジットゲートウェイを通じてアクセス可能にするネットワークルート (サブネット) を設定します。 - Anypoint Platform で、外部宛先への ​[Anypoint VPC からのアウトバウンドトラフィックを有効化します](#enable_outbound_traffic_from_vpc)​。 - AWS で、トランジットゲートウェイを通じた​[インバウンドトラフィックを有効化します](#enable_inbound_traffic_on_aws)​。 ### [](#前提条件-2)前提条件 ルーティングを設定する前に、ネットワークを統合して接続数を可能な限り少なく抑えてください。 トランジットゲートウェイアタッチメントの数に関係なく、VPC ごとに最大 95 件のルートテーブルエントリが許可されます。 ### [](#enable_outbound_traffic_from_vpc)VPC からのアウトバウンドトラフィックを有効にする VPC をアタッチした後で、Anypoint VPC から外部宛先へのアウトバウンドトラフィックを有効にして、アプリケーションがトランジットゲートウェイにアクセスでき、トランジットゲートウェイがトラフィックを正しくルーティングできるようにします。 そのためには、トランジットゲートウェイのルートテーブルへのルートを追加します。 1. Anypoint Platform で、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ > ​**\[VPCs (VPC)\]**​ に移動して ​**\[Add Route (ルートを追加)\]**​ をクリックします。 2. **\[Add VPC Route (VPC ルートを追加)\]**​ ウィンドウで、CIDR 表記を使用して AWS VPC のサブネットを 1 つ入力します。 ![「Add VPC route (VPC ルートを追加)」](/mulesoft/current/ja-jp/cloudhub/_images/tgw-add-vpc-route.png) 3. **\[Add Route (ルートを追加)\]**​ をクリックします。 Anypoint Platform により、AWS への新しいルートが送信されます。 ルートの追加に成功したら、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページに ​**\[Route added (ルートが追加されました)\]**​ というメッセージが表示され、​**\[Transit Gateways (トランジットゲートウェイ)\]**​ ページのルートテーブルにルートの CIDR が表示されます。 ルートテーブルで、追加されたルートの ​**\[Next Hop (次のホップ)\]**​ 列の値として ​**\[Transit Gateway (トランジットゲートウェイ)\]**​ が表示されます。 トランジットゲートウェイにアタッチされた特定のルートは、​**\[Transit Gateway Routes (トランジットゲートウェイルート)\]**​ に表示されます。VPC のその他のルートは、​**\[VPC Routes (VPC ルート)\]**​ に表示されます。 ![ルートテーブルの \[Next Hop (次のホップ)\] 列の \[Transit Gateway (トランジットゲートウェイ)\]](_images/tgw-route-added.png) ### [](#enable_inbound_traffic_on_aws)トランジットゲートウェイを通じたインバウンドトラフィックの有効化 Anypoint Platform でトランジットゲートウェイのルートテーブルへのルートの追加に成功したら、AWS でトランジットゲートウェイを通じたインバウンドトラフィックを有効にします。 インバウンドトラフィックを有効にするにはネットワーク管理者と連携する必要がある場合もあります。 ## [](#関連情報)関連情報 - [トランジットゲートウェイアタッチメントのトラブルシューティング](https://docs.mulesoft.com/jp/cloudhub/tgw-troubleshoot) - [トランジットゲートウェイアタッチメントの管理](https://docs.mulesoft.com/jp/cloudhub/tgw-manage-arm) - [トランジットゲートウェイアタッチメント](https://docs.mulesoft.com/jp/cloudhub/tgw-about) - AWS ドキュメントの [「Transit gateway attachments to a VPC (VPC へのトランジットゲートウェイアタッチメント)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html) - AWS ドキュメントの [「Transit gateway route tables (トランジットゲートウェイのルートテーブル)」](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [Runtime Manager の VPC の作成と更新](https://docs.mulesoft.com/jp/cloudhub/vpc-tutorial) - [ユーザーへの権限とロールの付与](https://docs.mulesoft.com/jp/access-management/users#grant-permissions-and-roles-to-users) # ネットワークとの Anypoint VPC 接続の申請 ネットワークとの Anypoint Virtual Private Cloud (Anypoint VPC) 接続の申請や更新の手順は、使用している接続方式 (IPsec、トランジットゲートウェイアタッチメント、VPC ピアリング、AWS Direct Connect) によって異なります。
Anypoint VPC 接続のプロビジョニングの SLA は、MuleSoft サポートが記入内容に不備のない Anypoint VPC 検出フォームを受領して承認してから 5 営業日です。
## [](#ipsec-vpn-接続を設定する)IPsec VPN 接続を設定する 2018 年 11 月の時点で、MuleSoft サポートは新規 VPN 接続の作成を終了しています。 すべての新しい VPN では、​[「Anypoint VPN の作成」](https://docs.mulesoft.com/jp/cloudhub/vpn-create-arm)​のセルフサービスステップに従ってください。 2018 年 11 月以前に MuleSoft サポートによって作成された​_既存の_​ IPsec VPN 接続を更新する手順は次のとおりです。 1. [Anypoint VPC 検出フォーム](https://docs.mulesoft.com/jp/cloudhub/_attachments/VPC-form-v9.5-template.xlsx)をダウンロードします。 このフォームを開くには Microsoft Excel 2007 以降が必要です (マクロを有効にする必要があります)。 2. 更新する VPC 接続ごとに Anypoint VPC 検出フォームを準備して送信します。 1. **\[Overview (概要)\]**​ タブと ​**\[IPSec\]**​ タブのすべての項目に情報を記入します。 処理が遅れないように、必ず両方のタブのすべての項目に記入してください。 2. サポートチケットを開いて、記入したフォームを送信します。 MuleSoft サポートチームは、Anypoint VPC 検出フォームに記入されている詳細に従って VPN 接続の設定を更新します。 申請の処理が完了すると、サポートはチケットを更新して通知します。 ## [](#トランジットゲートウェイアタッチメントを設定する)トランジットゲートウェイアタッチメントを設定する トランジットゲートウェイアタッチメントを設定するには、​[「トランジットゲートウェイへのアタッチ」](https://docs.mulesoft.com/jp/cloudhub/tgw-attach-arm)​のセルフサービスステップに従ってください。 ## [](#vpc-ピアリング接続を設定する)VPC ピアリング接続を設定する MuleSoft ではリージョン間のピアリングをサポートしていないため、両方の VPC が同じリージョンに存在する必要があります。 新規 VPC ピアリング接続の作成または既存の VPC ピアリング接続の更新を申請する手順は、次のとおりです。 1. [Anypoint VPC 検出フォーム](https://docs.mulesoft.com/jp/cloudhub/_attachments/VPC-form-v9.5-template.xlsx)をダウンロードします。 このフォームを開くには Microsoft Excel 2007 以降が必要です (マクロを有効にする必要があります)。 2. VPC ピアリング接続ごとに Anypoint VPC 検出フォームを準備して送信します。 Anypoint VPC 検出フォームは、新規の接続と既存接続の更新のどちらの場合にも必要です。 1. **\[Overview (概要)\]**​ タブと ​**\[VPC Peering (VPC ピアリング)\]**​ タブのすべての項目に情報を記入します。 処理が遅れないように、必ず両方のタブのすべての項目に記入してください。 2. サポートチケットを開いて、記入したフォームを送信します。 MuleSoft サポートチームは、Anypoint VPC 検出フォームに記入されている詳細に従って VPC ピアリング接続を作成または更新します。 申請の処理が完了すると、サポートはチケットを更新して通知します。 ## [](#direct-connect-の設定)Direct Connect の設定 新規の直接 (DX) 接続の作成または既存の DX 接続の更新を申請する手順は、次のとおりです。 1. 自分の AWS アカウントまたはパートナーの AWS アカウントとの DX 接続を確立します。 2. MuleSoft のアカウント ID で仮想インターフェース (VIF) またはホスト済み接続を作成します。 3. [Anypoint VPC 検出フォーム](https://docs.mulesoft.com/jp/cloudhub/_attachments/VPC-form-v9.5-template.xlsx)をダウンロードします。 このフォームを開くには Microsoft Excel 2007 以降が必要です (マクロを有効にする必要があります)。 4. DX 接続ごとに Anypoint VPC 検出フォームを準備して送信します。 Anypoint VPC 検出フォームは、新規の接続と既存接続の更新のどちらの場合にも必要です。 1. **\[Overview (概要)\]**​ タブと ​**\[Direct Connect\]**​ タブのすべての項目に情報を記入します。 処理が遅れないように、必ず両方のタブのすべての項目に記入してください。 2. サポートチケットを開いて、記入したフォームを送信します。 MuleSoft サポートチームは VIF または接続の申請を受け付けます。 申請の処理が完了すると、サポートはチケットを更新して通知します。 ## [](#関連情報)関連情報 - [Anypoint VPC 接続方法](https://docs.mulesoft.com/jp/cloudhub/vpc-connectivity-methods-concept) - [Anypoint VPN](https://docs.mulesoft.com/jp/cloudhub/vpn-about) # メンテナンスおよびアップグレードポリシー Runtime Manager コンソール、プラットフォームサービス、ワーカークラウド (​[「CloudHub アーキテクチャ」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-architecture)​を参照) に対するすべてのメンテナンスは、 [\[Status (状況)](http://status.mulesoft.com)\]​ ページで指定されたメンテナンス実施時間中に行われます。ただし、重要なセキュリティ問題は例外で、これらは直ちに修正されます。 MuleSoft のポリシーは、すべてのメンテナンスを透過的に実行し、ワーカークラウドで実行中のインテグレーションに可能な限りダウンタイムを発生させないというものです。コンソール、プラットフォームサービス、ワーカーのダウンタイムが避けられない場合は、MuleSoft はこれらのメンテナンス実施時間を少なくとも 8 時間前、通常は 7 日前にお知らせします。ただし、重要なセキュリティパッチは例外で、これらは直ちに修正されます。 Runtime Manager コンソール、CloudHub プラットフォームサービス、CloudHub ワーカークラウドの現在の状況と詳細なサービス履歴は、以下で参照できます。 - US: [status.mulesoft.com](http://status.mulesoft.com/) - EU: [eu1-status.mulesoft.com](http://eu1-status.mulesoft.com) - MuleSoft Government Cloud: [gov-status.mulesoft.com](https://gov-status.mulesoft.com) ## [](#関連情報)関連情報 - [バージョン設定ポリシーとサポートポリシー](https://www.mulesoft.com/legal/versioning-back-support-policy) # ログデータの表示 CloudHub により、各ワーカーのデプロイメントのメッセージとイベントおよび Mule Runtime Engine ログを含むログデータへのアクセスが可能になります。 ログと診断は、現在 CloudHub ワーカーにデプロイされたアプリケーションのみで使用可能です。 ローカルサーバーにデプロイされたアプリケーションの場合、外部の分析ソフトウェアにデータを送信できます。 [「外部分析ツールへのデータのエクスポート」](https://docs.mulesoft.com/jp/runtime-manager/sending-data-from-arm-to-external-analytics-software)​を参照してください。 以下の手段により、さらに詳細な検索やログ管理を行うことができます。 - Anypoint Monitoring を使用する。 [「Anypoint Monitoring の概要」](https://docs.mulesoft.com/jp/monitoring/)​を参照してください。 - Log4j 設定を使用して CloudHub アプリケーションをログシステムに統合する。 [「Log4j を使用したログシステムとのインテグレーション」](https://docs.mulesoft.com/jp/cloudhub/custom-log-appender)​を参照してください。 ## [](#ログの表示)ログの表示 CloudHub にデプロイされたアプリケーションのログを表示する手順は、次のとおりです。 1. Anypoint Platform で、​**\[Runtime Manager\]**​ を選択します。 2. Runtime Manager ナビゲーションメニューで ​**\[Applications (アプリケーション)\]**​ をクリックし、アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Logs (ログ)\]**​ をクリックします。 4. **\[Deployments (デプロイメント)\]**​ セクションで、日付、デプロイメント、システムログ、ワーカーで出力を絞り込みます。 検索条件の適用を解除するには、日付のチェックボックスをオフにします。 ![「Deployments (デプロイメント)」 セクションのデプロイメントでログ出力を絞り込みます。](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-logs-deploy.png) Figure 1. 矢印は、​**\[Deployments (デプロイメント)\]**​ セクションのデプロイメントでログ出力を絞り込むためのチェックボックスを示しています。 ## [](#ログのダウンロード)ログのダウンロード CloudHub デプロイメントの各ワーカーについて、そのワーカーのアクティビティに固有のログをダウンロードできます。 1. **\[Deployments (デプロイメント)\]**​ セクションで、ログをダウンロードする日付とワーカーを選択します。 2. ワーカーのダウンロードアイコンをクリックして、​**\[Logs (ログ)\]**​ を選択します。 ![「Deployments (デプロイメント)」 セクションのワーカー別にログ出力をダウンロードします。](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-logs-download.png) Figure 2. 矢印は、​**\[Deployments (デプロイメント)\]**​ セクションのデプロイメント別にログ出力をダウンロードするためのアイコンを示しています。 CloudHub では、ログ出力を ​`_deploymentID_​._instanceID_​-​_workerNumber_​.log`​ の形式でテキストファイルにダウンロードします。 ログファイルを表示するには、テキストエディターを使用します。 CloudHub のアプリケーションログを、監査、分析、または同様の目的で定期的にアーカイブまたはダウンロードする必要がある場合は、カスタムログアペンダーを使用してログを抽出します。 [「Log4j を使用したログシステムとのインテグレーション」](https://docs.mulesoft.com/jp/cloudhub/custom-log-appender)​を参照してください。 ## [](#診断のダウンロード)診断のダウンロード 診断には、各デプロイメントの各 CloudHub ワーカーの Java スレッドダンプが表示されます。これらはサーバーの現在の状態を示し、デバッグとサポートに役立ちます。 3.8.0 より前の Mule バージョン (バージョン 3.7.4 を除く) で実行されるアプリケーションでは、診断は利用できません。 診断をダウンロードする手順は次のとおりです。 1. **\[Deployments (デプロイメント)\]**​ セクションで、診断をダウンロードする日付とワーカーを選択します。 2. ワーカーのダウンロードアイコンをクリックして、​**\[Diagnostics (診断)\]**​ を選択します。 ![「Deployments (デプロイメント)」 セクションのワーカー別に診断をダウンロードします。](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-logs-diag-download.png) Figure 3. 矢印は、​**\[Deployments (デプロイメント)\]**​ セクションのワーカー別に診断をダウンロードするためのアイコンを示しています。 CloudHub では、診断出力を ​`_appName_​-instance-​_instanceID_​-​_workerNumber_​-diag.txt`​ の形式でテキストファイルにダウンロードします。 診断ファイルを表示するには、テキストエディターを使用します。

次の URL を使用して診断ファイルを直接ダウンロードすることもできます。

api/v2/applications/​appName​/instances/​instanceId​/diagnostics

## [](#mule-ログをダウンロードする)Mule ログをダウンロードする Mule ログには、CloudHub 用の Mule Runtime Engine のログが表示されます。 Mule ログにはアプリケーションとライフサイクルイベントに関する情報が含まれます。 たとえば、Mule サービスまたはアプリケーションの開始、デプロイ、停止、またはアンデプロイ時にログにエントリが記録されます。 1. **\[Deployments (デプロイメント)\]**​ セクションで、Mule ログをダウンロードする日付とワーカーを選択します。 2. ワーカーのダウンロードアイコンをクリックして、​**\[Mule Logs (Mule ログ)\]**​ を選択します。 ![「Deployments (デプロイメント)」 セクションで Mule ログ出力をダウンロードします。](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-logs-mule-download.png) Figure 4. 矢印は、​**\[Deployments (デプロイメント)\]**​ セクションのデプロイメント別に Mule ログ出力をダウンロードするためのアイコンを示しています。 CloudHub では、Mule ログ出力を ​`_appName_​-instance-​_instanceID_​-​_workerNumber_​-mule_ee.log`​ の形式でテキストファイルにダウンロードします。 ログファイルを表示するには、テキストエディターを使用します。 Mule ログについての詳細は、​[「Runtime Log (ランタイムログ)」](https://docs.mulesoft.com/mule-runtime/latest/logging-in-mule#runtime-log)​を参照してください。 ## [](#デプロイメント履歴の永続性)デプロイメント履歴の永続性 CloudHub は、非アクティブなデプロイメント履歴をデプロイメントの最終更新時間に基づいて最大 30 日間保存します。 ## [](#ログの永続性)ログの永続性 CloudHub では、ログは、ワーカーごとにアプリケーションあたり最大 100 MB または最長 30 日間のいずれかの制限に達するまで保存されます。 ## [](#ログのタイムゾーン)ログのタイムゾーン CloudHub では、ログデータは協定世界時 (UTC) で保存されますが、コンソールにはコンピューターのローカルタイムゾーンを使用してログが表示されます。 ## [](#検索ログ)検索ログ 特定の値を含むログを検索したり、日付や優先度でログを検索したりできます。 ログを検索する手順は次のとおりです。 1. 検索ボックスに値を入力するか、または ​**\[Advanced (詳細)\]**​ をクリックして、時刻、日付、日付範囲、およびメッセージ優先度を指定してログを検索します。 2. **\[Apply (適用)\]**​ をクリックします。 ![「Logs (ログ)」 ページで 「Advanced (詳細)」 検索と 「Priority (優先度)」 を表示します。](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-logs-search-adv.png) Figure 5. このスクリーンショットは ​**\[Logs (ログ)\]**​ ページの (​**1**​) ​**\[Advanced (詳細)\]**​ 検索と (​**2**​) ​**\[Priority (優先度)\]**​ を示しています。 クエリを使用して検索できます。詳細は、​[「ログ検索構文」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-log-search-syntax)​を参照してください。 ### [](#日時による検索)日時による検索 **\[Date & Time (日時)\]**​ 検索条件では、日付範囲を指定してログを検索できます。可能な値: - **Last hour (過去 1 時間)** - **Last 24 hours (過去 24 時間)** - **Last week (先週)** - **Last month (先月)** ### [](#メッセージの優先度による検索)メッセージの優先度による検索 **\[Priority (優先度)\]**​ 検索条件では、ログの特定のイベントを表示できます。表の​**コマンド**​列に示すように、検索ボックスに​`priority`​を入力してさまざまな優先度を指定することもできます。 可能な値:
値 説明 コマンド

すべての優先度

すべてのメッセージをリストします。

なし

ERROR

例外が発生した場合のエラーメッセージのみをリストします。

priority:ERROR

FATAL

アプリケーションが失敗した場合の致命的なメッセージのみをリストします。

priority:FATAL

INFO

有益情報のメッセージをリストします。

priority:INFO

SYSTEM

アプリケーションとワーカーのスタートアップに関するメッセージをリストします。

priority:SYSTEM

CONSOLE

オブジェクトストアの設定など、コンソールイベントに関するメッセージをリストします。

priority:CONSOLE

WARN

警告メッセージをリストします。

priority:WARN

DEBUG

デバッグメッセージをリストします。

priority:DEBUG

## [](#関連情報)関連情報 - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [外部分析ツールへのデータのエクスポート](https://docs.mulesoft.com/jp/runtime-manager/sending-data-from-arm-to-external-analytics-software) - [Log4j を使用したログシステムとのインテグレーション](https://docs.mulesoft.com/jp/cloudhub/custom-log-appender) - [アプリケーションとサーバーの監視](https://docs.mulesoft.com/jp/runtime-manager/monitoring) - [ログの設定](https://docs.mulesoft.com/mule-runtime/latest/logging-in-mule) - [ログ検索構文](https://docs.mulesoft.com/jp/cloudhub/cloudhub-log-search-syntax) # ログ検索クエリ構文 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`​ 項目の前に指定する必要があります。 # ワーカー監視の機能停止 CloudHub は、Mule アプリケーションを実行しているワーカーの健全性を継続的に検証します。 ネットワークの使用不能、メモリの問題、サーバーハードウェアの障害、ファイルの破損など、ハードウェアまたはソフトウェアの障害によってワーカーが機能停止になると、自動的に CloudHub はアプリケーションを新しいワーカーで再起動しようと試みます。 CloudHub では正常に機能しないワーカーが定期的 (基盤となるインフラストラクチャによる) に置換されるため、新しいワーカーが開始するタイミングと負荷の共有が開始されるタイミングの間に遅延が生じる可能性もあります。 アプリケーションが複数のワーカーで実行されている限り、この遅延はアプリケーションに影響しません。 CloudHub は、アプリケーションが完全に起動して動作状態になってから、トラフィックを新しいアプリケーションインスタンスに切り替えて古いアプリケーションインスタンスを削除するため、ダウンタイムは発生しません。 アプリケーションが 5 回の試行で起動できないと、状況が ​**\[Failed (失敗)\]**​ または ​**\[Unrecoverable Runtime Error (回復不能なランタイムエラー)\]**​ になり、手動でアプリケーションを再起動する必要があります。 自動再起動が発生したことが通知されます。アプリケーションログには、アプリケーションの自動再起動と発生した障害が記録されます。次に例を示します。 ```console Your application was running on an impaired worker instance. To avoid any downtime, the platform has restarted the application. ```
自動ワーカー再起動機能は、アプリケーションの ​[Settings (設定)]​ ページの ​[Automatically restart application when not responding (応答がない場合にアプリケーションを自動的に再起動)]​ オプションで設定できる自動アプリケーション再起動機能とは異なります。 アプリケーション再起動設定に関係なく、CloudHub は、機能停止したワーカーを自動的に再起動しようと試みます。
## [](#定期メンテナンスアクティビティ)定期メンテナンスアクティビティ CloudHub は、実行中のアプリケーションのダウンタイム (インスタンスの再起動、停止、起動、置換) が発生する可能性のある、ワーカーインフラストラクチャ上で予定されている定期メンテナンスアクティビティを確認します。ダウンタイムをなくすため、CloudHub はメンテナンスが開始される前に新しいワーカーでアプリケーションを自動的に再起動するようにスケジュールします。 自分の都合に合わせてアプリケーションを手動で再起動することも、CloudHub に自動的にアプリケーションを再起動させることもできます。 スケジュールされている再起動の 1 か月前になると、そのアプリケーションの ​**\[Applications (アプリケーション)\]**​ ページと ​**\[Settings (設定)\]**​ ページの右上にある通知 (ベル) アイコンが赤色に変わり、新しい通知があることを示します。 ![アプリケーションの \[Settings (設定)\] ページの通知アイコン](_images/cloudhub-notification-icon.png) Figure 1. アプリケーションの ​**\[Settings (設定)\]**​ ページの通知アイコンを示す矢印。 アイコンをクリックすると通知が表示され、CloudHub が自動的にワーカーを再起動する日付が示されます。 この通知は、アプリケーションの自動再起動の 1 週間前にも表示されます。 ## [](#関連情報)関連情報 - [Runtime Manager の通知](https://docs.mulesoft.com/jp/cloudhub/notifications-on-runtime-manager) - [アプリケーション監視と自動再起動](https://docs.mulesoft.com/jp/cloudhub/worker-monitoring) - [デプロイされたアプリケーションの管理](https://docs.mulesoft.com/jp/runtime-manager/managing-deployed-applications) # 内部ネットワークの非公開ドメインの解決 ネットワークの IP アドレスとドメイン名を追加して、カスタムプライベートドメインを指定できます。プライベートドメインを提供すると、ワーカーはプライベート DNS を使用してそれらを解決するので、まだプライベートネットワークの内部ホスト名を使用することできます (アプリケーションからバックエンドリソースを FQDN で呼び出すようにしてください)。 1. Anypoint Platform にサインインし、​**\[Management Center\]**​ で ​**\[Runtime Manager\]**​ をクリックします。 2. 左ナビゲーションで、​**\[VPCs\]**​ をクリックします。 3. 設定する Anypoint VPC の行を選択し、​**\[Manage VPC (VPC を管理)\]**​ をクリックします。 4. **\[Internal DNS (内部 DNS)\]**​ タブをクリックします。 5. **\[Add New IP (新規 IP を追加)\]**​ をクリックして、内部 DNS サーバーの IP アドレスを入力し、​**\[Add to List (リストに追加)\]**​ をクリックします。 IP アドレスは 3 つまで入力できます。 ![vpc tutorial f7641](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-f7641.png) 6. **\[Add New Domain (新規ドメインを追加)\]**​ をクリックし、内部ドメイン名を入力して、​**\[Add to List (リストに追加)\]**​ をクリックします。 追加する必要があるのはドメイン名の共通部分のみです (例: `mulesoft.com`​)。 複数のプライベートドメインを追加できます。 ![vpc tutorial 7770c](/mulesoft/current/ja-jp/cloudhub/_images/vpc-tutorial-7770c.png) 7. **\[Apply Changes (変更を適用)\]**​ をクリックします。
内部 DNS IP アドレスおよびドメインへの変更が CloudHub ワーカーに伝播されるまで最大 60 分かかる場合があります。
内部ネットワーク内でドメイン名を解決する場合、次の点に留意してください。 - 設定する IP アドレスは、内部ネットワークの DNS サーバーのものです。接続先のサービスの IP アドレスではありません。 - 設定するすべてのドメインの最大文字数は 229 文字以内にする必要があります。たとえば、​`mydomain1.com`​ と ​`mydomain2.com`​ というドメインを追加するには 28 文字が必要です。DNS 階層では、すべてのドメインの末尾は "." 文字になるので、各ドメイン名には追加で 1 文字が使用されます。 - 229 文字制限を超えてしまわないように、ホスト名は入力しないでください。 - すべての DNS サーバーには、リストされているすべての非公開ドメインに対して有効な同一レコードが存在する必要があります。 ## [](#関連情報)関連情報 - [VPC ネットワークアーキテクチャ](https://docs.mulesoft.com/jp/cloudhub/vpc-architecture-concept) - [VPC の作成](https://docs.mulesoft.com/jp/cloudhub/vpc-tutorial) # 専用ロードバランサー CloudHub 専用ロードバランサー (DLB) は Anypoint Platform の省略可能なコンポーネントであり、外部 HTTP および HTTPS トラフィックを、Virtual Private Cloud (VPC) 内の CloudHub ワーカーにデプロイされた複数の Mule アプリケーションに転送できるようにします。 専用ロードバランサーを使用すると、次のことができます。 - アプリケーションを実行するさまざまな CloudHub ワーカー内で負荷分散を処理する。 対象 CloudHub アプリケーションに複数のワーカーがあり、定義されたタイムアウト以内に応答しない場合、DLB によって次のワーカーへの要求が順次作成されます。​[デフォルトのタイムアウト値](https://docs.mulesoft.com/jp/cloudhub/lb-create-arm#create-a-load-balancer)​は 300 秒です。 - カスタム証明書を提供し、必要に応じて双方向 SSL クライアント認証を適用するように SSL 設定を定義する。 - カスタムドメインにアプリケーションをマップするプロキシルールを設定する。 これにより、アプリケーションを 1 つのドメイン下でホストできます。 環境で専用ロードバランサーを使用するには、最初に Anypoint VPC を作成する必要があります。同じ Anypoint VPC に複数の環境を関連付けることができるため、異なる環境で同じ専用ロードバランサーを使用できます。 Anypoint Platform 組織のロードバランサーと Anypoint VPC エンドポイントは、API Portal から参照できます。 ## [](#専用ロードバランサーの作成と設定)専用ロードバランサーの作成と設定 ロードバランサーを作成および設定するには、ロードバランサーが関連付けられている組織のシステム管理者である必要があります。 DLB 名は、Anypoint Platform で (すべての MuleSoft ユーザーによって) 定義されているすべての DLB で一意である必要があります。 Anypoint VPC の専用ロードバランサーを作成および設定する方法は 3 つあります。 - Anypoint Platform から ​[Runtime Manager](https://docs.mulesoft.com/jp/cloudhub/lb-create-arm)​ を使用する - Anypoint Platform CLI から ​[cloudhub load-balancer create](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-create)​ コマンドを使用する - 次のエンドポイントで ​[CloudHub REST API](https://docs.mulesoft.com/jp/cloudhub/cloudhub-api)​ を使用する - `anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers` - `anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs` `loadbalancers`​ および ​`vpcs`​ エンドポイントの詳細は、 [「CloudHub API」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)​を参照してください。 ## [](#専用ロードバランサーのライセンス)専用ロードバランサーのライセンス 購入した各 DLB ユニットは、CloudHub ワーカー間の負荷分散を処理する 2 つのワーカーに相当します。 最大 4 つのロードバランサーユニットを DLB に割り当てることができます。 4 つのロードバランサーユニットが割り当てられた DLB のワーカーは 8 つになります。 ## [](#静的-ip-アドレス)静的 IP アドレス DLB の静的 IP アドレスを有効にした場合、DLB に割り当てられる静的 IP アドレスの数は、ワーカー数の 2 倍です。 たとえば、DLB に 4 つのワーカーがある場合、DLB には関連付けられた静的 IP アドレスが 8 つあります。 常に静的 IP の半分 (ワーカーインスタンス数と同じ) が使用されます。 DLB を再起動または更新すると、DLB は未使用の静的 IP アドレスを使用するように切り替わり、最初の静的 IP アドレスのグループを未使用状態に移行します。 2 つのグループの静的 IP アドレスを切り替えることで、ダウンタイムなしの再起動および更新を実現でき、トランザクション時間が 600 秒または ​**\[Mule Application Response Timeout (Mule アプリケーション応答タイムアウト)\]**​ の値のいずれか (短いほう) より短い限り、トランザクションがドロップされたり失われたりすることがありません。 ### [](#考慮事項)考慮事項 - DLB を再起動または更新すると静的 IP が変更されるため、外部サービスから DLB をコールするときは IP アドレスではなく DLB の DNS アドレスを使用してください。DNS の切り替えを考慮するために必要な再試行メカニズムがクライアントに含まれていることを確認します。 - ロードバランサーを再起動するときに接続の問題を回避するため、接続のキープアライブを含めて、DNS TTL (30 秒) に準拠してください。新しいワーカーがオンラインになって TTL の有効期限が切れると、接続がクローズされます。 - DLB では DNS ベースのルーティングを使用してトラフィックを DLB ワーカーに分散し、すべての DLB ワーカーの IP アドレスを呼び出し側のクライアントに返します。1 秒あたりのトランザクションの量に関係なく、TTL ウィンドウ内で 1 つの DLB ワーカーがすべてのクライアントトラフィックを受信する可能性もあります。これを回避するには、DNS 解決で返される IP アドレス間で相互に繰り返すことにより、DLB ワーカー間できめ細かく負荷分散を行ってください。 - 設定変更中に DLB が停止すると、DNS は削除されます。再起動時に DNS ルックアップが行われると、​`NXDOMAIN`​ エラーが 15 分間キャッシュされます。このネガティブなキャッシュを回避するには、必ずすべての API コールを停止してください。 - Anypoint 専用ロードバランサーでは、プロキシバッファがデフォルトで有効になります。この機能により、サーバーからの応答が受信時に内部バッファに保存され、応答全体がバッファされるまでクライアントへのデータ送信が遅延されます。プロキシバッファを使用すると、プロキシされたサーバーが応答をすばやく返して他の要求に対応できるため、低速なクライアントでパフォーマンスが最適化されます。ただし、小さなペイロードのストリーミングでは、バッファバケットが埋まるまで時間がかかるため適していません。 小さなペイロードのストリーミングのパフォーマンスの問題を回避するには、​`X-Accel-Buffering`​ レスポンスヘッダー項目に ​`no`​ を渡してプロキシバッファを無効にします。
2021 年 10 月より前に作成された DLB の場合、​[Update (更新)]​ をクリックしてこの機能を有効にします。​[Update (更新)]​ をクリックすると、DLB では前述の静的 IP モデルを使用するようになり、以前のモデルに戻れなくなります。
DLB の更新については、​[「専用ロードバランサーの更新」](https://docs.mulesoft.com/jp/cloudhub/lb-updates)​を参照してください。 ## [](#関連情報)関連情報 - [SSL エンドポイントと証明書の設定](https://docs.mulesoft.com/jp/cloudhub/lb-ssl-endpoints) - [Anypoint VPC](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [マッピングルール](https://docs.mulesoft.com/jp/cloudhub/lb-mapping-rules) - [許可リスト](https://docs.mulesoft.com/jp/cloudhub/lb-allowlists) # 専用ロードバランサーアーキテクチャ CloudHub 専用ロードバランサー (DLB) を使用すると、外部 HTTP および HTTPS トラフィックを、Virtual Private Cloud (VPC) 内の CloudHub ワーカーにデプロイされた複数の Mule アプリケーションに転送できます。各 CloudHub DLB は、Anypoint VPC に割り当てられ、その Anypoint VPC は特定のサービスリージョン内で実行されます。DLB は、外部トラフィックと Anypiont VPC の内部トラフィックの両方を、Anypiont VPC にデプロイされた CloudHub ワーカーに転送します。 公開 CloudHub ロードバランサーはすでにこれらの要求をリダイレクトしています。​`_myApp_`​ は CloudHub への Mule アプリケーションデプロイメントの名前です。 - `http://myApp.cloudhub.io`​ への HTTP 要求は ​`mule-worker-myApp.cloudhub.io:8081`​ にリダイレクトされます。 - `https://myApp.cloudhub.io:443`​ への HTTPS トラフィックは ​`https://mule-worker-myApp.cloudhub.io:8082`​ にリダイレクトされます。 ロードバランサーは、HTTPS 上の外部要求をリスンし、デフォルトでは HTTP を介して内部の通信を行います。HTTPS でリスンするように Anypoint VPC 内の Mule アプリケーションを設定している場合、​[`cloudhub load-balancer mappings add`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-mappings-add)​ コマンドを使用してマッピングリストを作成するときに ​`upstreamProtocol`​ が ​`HTTPS`​ に設定されていることを確認してください。 ## [](#専用ロードバランサーへの外部要求のルーティング)専用ロードバランサーへの外部要求のルーティング CloudHub 専用ロードバランサーでは、ポート 8091 でリスンする Mule アプリケーションへの HTTP 要求とポート 8092 でリスンする Mule アプリケーションへの HTTPS 要求を転送するための代替ドメイン名が提供されます。また、マッピングルールを使用して、CloudHub DLB への要求の名前を異なる Mule アプリケーションドメイン名に変更することもできます。 CloudHub DLB は、CloudHub Anypoint VPC ネットワークの外部からアクセスできる 2 つの公開 IP アドレスに解決される外部ドメイン名を公開します。 `[lb-name]`​ は作成時にロードバランサーに付けた名前です。 - `[lb-name].lb.anypointdns.net` - `[lb-name].lb-prod-eu-rt.anypointdns.net`​ (EU コントロールプレーン) - `[lb-name].lb-gprod-rt.anypointdns.net`​ (Government Cloud コントロールプレーン) ## [](#専用ロードバランサーによる外部-mule-アプリケーション-url-の名前変更)専用ロードバランサーによる外部 Mule アプリケーション URL の名前変更 Mule アプリケーションの名前を変更するマッピングルールを作成することで、異なるドメイン名によってアクセスできるようになります。 たとえば、myApp-myCompany-prod.cloudhub.io という名前の Mule アプリケーションをデプロイするとします。CloudHub ドメイン名は、他のすべての MuleSoft のお客様と Mule アプリケーションの間でグローバルに一意である必要があります。DLB によって、企業 DNS ドメイン名内のこの命名の複雑さを隠すことができます。 企業 DNS 名前サーバーで CNAME レコードを設定して、​`lb-name.lb.anypointdns.net`​ ドメインを会社のバニティドメインにマスクすることができます。 たとえば、会社が DNS ドメイン ​`example.com`​ を所有しているとします。​`{subdomain}`​ パターンを使用して、​`myapp.example.com`​ への要求を ​`myapp`​ という名前の CloudHub アプリケーションにルーティングする CNAME レコードを作成できます。これで、​`cloudhub.io`​ ドメインの CloudHub ドメイン名の複雑さが隠されます。 ## [](#専用ロードバランサーへの内部要求のルーティング)専用ロードバランサーへの内部要求のルーティング CloudHub 専用ロードバランサーには、Anypoint VPC 内のアプリケーションとクライアントによって使用される内部ドメイン名があります。 内部ドメインは次の命名規則を使用します (​`[lb-name]`​ は、ロードバランサーの作成時に付けた名前です)。 internal-\[lb-name\].lb.anypointdns.net 各 DLB には DNS A レコード ​`[lb-name].lb.anypointdns.net`​ があり、これはインスタンスの公開 IP アドレスに解決されます。 公開 IP アドレスの数は、ワーカーの数に相関します。 DNS プロバイダーを介して、この A レコードを指し示す CNAME レコードを追加したり、アクセスする自分のドメイン名を使用したりできます。 ロードバランサーでアプリケーションへのすべての接続を管理しても、アプリケーションのデフォルトのドメイン名を公開しない場合は、各アプリケーションが HTTP ポート 8091 または 8092 でリスンする必要があります。または、カスタムマッピングポリシーを作成して、ロードバランサーからの外部要求を特定のアプリケーションにリダイレクトできます。 次の図は、ロードバランサーが VPC と Anypoint Platform の間でやりとりを行うしくみを示しています。 ![ロードバランサー](/mulesoft/current/ja-jp/cloudhub/_images/pxty-lb.png) ロードバランサーは、HTTPS 上の外部要求をリスンし、デフォルトでは HTTP を介して内部の通信を行います。Anypoint VPC 内の Mule アプリケーションを HTTPS 上でリスンするように設定した場合は、​`load-balancer mappings add`​ コマンドを使用してマッピングリストを作成するときに ​`upstreamProtocol`​ を HTTPS に設定する必要があります。 内部 HTTP モードでは、HTTP 要求がどのように管理されるかを設定できます。処理は、無視する、デフォルト SSL エンドポイント上の HTTPS にマップする、URL を対応する HTTPS URL にマップするのいずれかです。 ## [](#dlb-の-url-エンコード)DLB の URL エンコード DLB が要求の URI を変更せずに渡すかデコードして渡すかを設定できます。 - **\[Keep URL encoding (URL エンコードを保持)\]**​ を選択すると、DLB は %20 および %23 文字のみをそのまま渡します。 - **\[Keep URL encoding (URL エンコードを保持)\]**​ の選択を解除すると、DLB は要求 URI のエンコードされている部分をデコードしてから CloudHub ワーカーに渡します。 ## [](#関連情報)関連情報 - [Virtual Private Cloud](https://docs.mulesoft.com/jp/cloudhub/virtual-private-cloud) - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [マッピングルール](https://docs.mulesoft.com/jp/cloudhub/lb-mapping-rules) # 専用ロードバランサーでの証明書の検証 SSL エンドポイントの CA 証明書を 1 つ以上指定すると、ロードバランサーは以下の HTTP ヘッダーを使用してクライアント証明書データを API に渡します。 - X-SSL-Client-Verify 次のいずれかが返されます。 - `SUCCESS` クライアントは ​`SUCCESS`​ が返された場合にのみ検証されます。 - 証明書が存在しない場合は ​`NONE`​ が返されます。 - 他の検証エラーが発生した場合は ​`FAILED`​ が返されます。 - X-SSL-Client-DN クライアント証明書の完全な識別名が含まれます。 - X-SSL-Issuer 発行元証明書の完全な識別名が含まれます。 - X-SSL-Client-Serial クライアントを識別するために CA で使用されるシリアル番号が含まれます。
クライアント証明書は DLB レベルで検証されますが、API レベルでの再検証は行われません。TLS は DLB と API の間で一方向になります。
## [](#失効リストの追加)失効リストの追加 CloudHub ロードバランサーは、必要に応じて証明書失効リスト (CRL) に対してクライアント要求を検証できます。アップロードするには、暗号化されていない、PEM でエンコードされた 1 つのファイルにすべての CRL ファイルを連結する必要があります。CRL 内での項目の順序は重要ではありません。 失効リストを追加するには、ロードバランサーの作成時に ​[`cloudhub load-balancer create`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-create)​ コマンドで ​`--crl`​ オプションを使用します。 ロードバランサーがすでに作成されている場合は、 [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/)​ を使用して CRL を追加または更新できます。この場合は、​`PATCH`​ 要求に ​`revocationList`​ 要素を追加して ​`/organizations/{myOrgID}/vpcs/{myVpcID}/loadbalancers/{myDlbID}`​ エンドポイントに送信します。 ```json [ { "op": "replace", "path": "/sslEndpoints/0/revocationList", "value": "-----BEGIN X509 CRL-----\nMIIBTTCBtwIBATANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJBVTETMBEGA1UE\nCBMKU29tZS1TdGF0ZTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRk\nMRAwDgYDVQQDEwdvcmcuY29tFw0xNjAzMTUwOTI2MThaFw0xODAzMTUwOTI2MTha\nMBwwGgIJAIBvvO4dJHjhFw0xNjAzMTUwODUwMTZaoA4wDDAKBgNVHRQEAwIBBjAN\nBgkqhkiG9w0BAQUFAAOBgQCCAbGXW+Hnzmd1bXqWsFXfogOsJScoxkJOhhmjui3I\nhTUyO5plGHUBLjBnDkypM+iLfn0W4wPcNj7FZdz4Hu/WLntxwrTtR5YOcfIhEGcq\nwvJq/1+WKUPC6eqGwx0iKOOBIWsaf5CNOOUQMo6RaeTeu8Uba2EGFk1Vu/SoZYAK\nsw==\n-----END X509 CRL-----\n" } ] ``` CLI から ​`myVpcID`​ と ​`myDlbID`​ の値を取得するには、それぞれ ​[`cloudhub vpc describe-json`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json)​ コマンドと ​[`cloudhub load-balancer describe-json`](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-describe-json)​ コマンドを使用します。 他のプロパティを更新するには、​`PATCH`​ 要求をロードバランサーエンドポイントに送信します。 ## [](#証明書暗号化スイートを管理するための準備)証明書暗号化スイートを管理するための準備 CloudHub API で暗号化スイートを管理するためには、事前に以下を行う必要があります。 - [認証ベアラートークンを生成する](#認証ベアラートークンの生成)​。 - CloudHub API を使用して組織 ID を取得する。 [「単一組織の取得」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/minor/1.0/console/method/%233736/)​を参照してください。 - CloudHub API を使用して VPC ID を取得する。 [cloudhub vpc describe-json](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-vpc-describe-json)​ を参照してください。 - CloudHub API を使用して DLB ID を取得する。 [cloudhub load-balancer describe-json](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-describe-json)​ を参照してください。 - `jq`​ をインストールして JSON 出力を書式化する。 [jq](https://stedolan.github.io/jq/)​ を参照してください。 ### [](#認証ベアラートークンの生成)認証ベアラートークンの生成 Anypoint Platform 用の認証ベアラートークンを生成する手順は次のとおりです。 1. Anypoint Platform のユーザー名とパスワードを API に送信します。 ```json curl -X POST 'https://anypoint.mulesoft.com/accounts/login' -H 'Content-Type: application/json' -d '{"username":"myUsername","password":"myPassword"}' ``` このコマンドによりアクセストークンが返されます。 ```json { "access_token": "myAccessToken", "token_type": "bearer", "redirectUrl": "/home/" } ``` 2. API コールで使用する ​`access_token`​ の値をコピーします。 ## [](#証明書暗号化スイートの管理)証明書暗号化スイートの管理 CloudHub API を使用すると、以下を行うことができます。 - [使用可能な暗号化スイートをリストする](#使用可能な暗号化スイートのリスト)​。 - [DLB のデフォルト暗号化スイートを表示する](#dlb-のデフォルト暗号化スイートの表示)​。 - [デフォルトの暗号化スイートを置換することで暗号化を循環する](#デフォルトの暗号化スイートの置換による暗号化の循環)​。 ### [](#使用可能な暗号化スイートのリスト)使用可能な暗号化スイートのリスト CloudHub API を使用して組織で使用可能な暗号化スイートをリストする手順は、次のとおりです。 1. [証明書暗号化スイートを管理するための準備](#prepare-to-manage-certificate-cipher-suites)​をします。 2. 次の GET コールを実行します。 ```linenums curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/loadbalancers/ciphersuites -H 'Authorization: Bearer myAccessToken' | jq ``` - `_myOrgID_`​ が組織 ID です。 - `_myAccessToken_`​ は、生成したアクセストークンです。 出力には ​`ciphers`​ が含まれます。 ```json { "data": [ { "id": "5b4a36e1e65c892316abd4d1", "name": "NewDefault-v1", "ciphers": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384", "description": "Default ciphers (new version)-v1", "defaultSuite": true }, { "id": "5b4a36e1e65c892316abd4d2", "name": "OldDefault", "ciphers": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4", "description": "Default ciphers (old version)", "defaultSuite": false }, { "id": "5b4bfedee4b0f45ab1de6979", "name": "EcdheEcdsaRsa", "ciphers": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384", "description": "ECDHE ECDSA RSA ciphers", "defaultSuite": false }, { "id": "5ba28106e4b00522d78f40b6", "name": "RestrictCiphers", "ciphers": "AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256", "description": "Restricted Ciphers", "defaultSuite": false } ], "total": 4 } ``` ### [](#推奨される暗号化スイート)推奨される暗号化スイート 次に示す推奨される暗号化スイートは、SSL エンドポイントの互換性とセキュリティのバランスが取れています。 ECDHE-RSA-AES256-GCM-SHA512 DHE-RSA-AES256-GCM-SHA512 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ほとんどの暗号化スイートは、前方秘匿性を提供します。RC4-SHA (Internet Explorer 8 をサポート) は前方秘匿性を提供しません。 そのため、MuleSoft と Microsoft は RC4-SHA の使用を推奨していません。 CloudHub の専用ロードバランサーでは、TLS 1.2 をサポートしています。 TLS 1.1 は無効になっており、デフォルトではサポートされていません。 TLS 1.0 を設定することもできますが、このプロトコルには重大な脆弱性があるため PCI コンプライアンスでは受け入れられません。 ### [](#dlb-のデフォルト暗号化スイートの表示)DLB のデフォルト暗号化スイートの表示 CloudHub API を使用して DLB のデフォルトの暗号化スイートを表示する手順は、次のとおりです。 1. [証明書暗号化スイートを管理するための準備](#prepare-to-manage-certificate-cipher-suites)​をします。 2. 次の GET コールを実行します。 ```linenums curl https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID -H 'Authorization: Bearer myAccessToken' | jq ``` コマンドでは: - `_myOrgID_`​ が組織 ID です。 - `_myVpcID_`​ は VPC の ID です。 - `_myDlbID_`​ は DLB の ID です。 - `_myAccessToken_`​ は、生成したアクセストークンです。 出力には ​`defaultCipherSuite`​ が含まれます。 ```json "defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384" ``` ### [](#デフォルトの暗号化スイートの置換による暗号化の循環)デフォルトの暗号化スイートの置換による暗号化の循環 CloudHub API を使用して DLB のデフォルトの暗号化スイートを置換することで暗号化を循環する手順は、次のとおりです。 1. [証明書暗号化スイートを管理するための準備](#prepare-to-manage-certificate-cipher-suites)​をします。 2. 次の PATCH コールを実行します。 ```linenums curl -X PATCH https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/ myDlbID -H 'Authorization: Bearer myAccessToken' -H 'Content-Type: application/json' -d '[{"op":"replace", "path":"/defaultCipherSuiteName", "value":"NewDefault-v1"}]' | jq ``` コマンドでは: - `_myOrgID_`​ が組織 ID です。 - `_myVpcID_`​ は VPC の ID です。 - `_myDlbID_`​ は DLB の ID です。 - `_myAccessToken_`​ は、生成したアクセストークンです。 - `NewDefault`​ は、​[使用可能な暗号化スイートのリスト](#使用可能な暗号化スイートのリスト)​で生成した使用可能な暗号化スイートのリストに含まれている暗号化スイートの ​`name`​ です。 この出力には ​`defaultCipherSuite`​ が含まれます。 ```json "defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384" ``` ### [](#tls-1-0-をサポートするようにデフォルトの暗号化スイートを変更する)TLS 1.0 をサポートするようにデフォルトの暗号化スイートを変更する TLS 1.0 をサポートするには、デフォルトの暗号化スイートを ​`OldDefault`​ に変更します。 1. [証明書暗号化スイートを管理するための準備](#prepare-to-manage-certificate-cipher-suites)​をします。 2. [現在のデフォルトの暗号化スイートを表示します](#display-the-default-cipher-suite-for-a-dlb)​。 3. デフォルトの暗号化スイートを変更します。 ```linenums curl -X PATCH https://anypoint.mulesoft.com/cloudhub/api/organizations/myOrgID/vpcs/myVpcID/loadbalancers/myDlbID -H 'Authorization: Bearer myAccessToken' -H 'Content-Type: application/json' -d '[{"op":"replace", "path":"/defaultCipherSuiteName", "value":"OldDefault"}]' | jq ``` コマンドでは: - `_myOrgID_`​ が組織 ID です。 - `_myVpcID_`​ は VPC の ID です。 - `_myDlbID_`​ は DLB の ID です。 - `_myAccessToken_`​ は、生成したアクセストークンです。 - `OldDefault`​ は TLS 1.0 をサポートする暗号化スイートの名前です。 4. デフォルトの暗号化スイートを確認して、出力に次の行が含まれることを確認します。 ```linenums "defaultCipherSuite": "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4" ``` ### [](#tls-1-0-接続の確認)TLS 1.0 接続の確認 TLS 1.0 を有効にしたら、接続をテストします。 - `openssl` DLB SSL エンドポイントに対して次のコマンドを実行します。 `openssl s_client -connect ​_DNS of the SSL endpoint_​:443 -tls1` - 出力に証明書情報と ​`Secure Renegotiation IS supported`​ というメッセージが含まれる場合、TLS 1.0 がサポートされています。 - コマンドで ​`write:errno=54`​ が返された場合、TLS 1.0 はサポートされていません。 - `curl` DLB SSL エンドポイントに対して次のコマンドを実行します。 `curl -vI --insecure --tlsv1.0 [https://​](https://​)_DNS of the SSL endpoint_` - バックエンドサーバーまたは HTTP エラーコードから返された結果が表示される場合、TLS 1.0 がサポートされています。 - コマンドで ​`curl: (35) Server aborted the SSL handshake`​ が返された場合、TLS 1.0 はサポートされていません。 ## [](#制限事項)制限事項 ECDSA ベースの認証暗号化を使用するには、ECDSA ベースのアルゴリズムを使用する証明書と鍵のペアを生成し、同じアルゴリズムを DLB の SSL 証明書と鍵の設定に適用します。 RSA ベースの証明書と鍵のペアで ECDSA ベースの認証暗号化を使用しようとすると、SSL ハンドシェイクが失敗し、次のいずれかのエラーメッセージが表示されます。 ```linenums SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure ``` または ```linenums Error: write EPROTO 140434219616616:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:594:SSL alert number 40 140434219616616:error:1000009a:SSL routines:OPENSSL_internal:HANDSHAKE_FAILURE_ON_CLIENT_HELLO:../../third_party/boringssl/src/ssl/handshake.cc:603: ``` 現在の DLB 設定で許可されているのは SSL エンドポイントごとに 1 つの種別の SSL 証明書と鍵のペアのみであるため、RSA ベースの暗号化を使用するクライアントは ECDSA ベースの設定に接続できず、ECDSA ベースの暗号化を使用するクライアントは RSA ベースの設定に接続できません。 ## [](#関連情報)関連情報 - [SSL エンドポイントと証明書の設定](https://docs.mulesoft.com/jp/cloudhub/lb-ssl-endpoints) - [専用ロードバランサーへの証明書の追加](https://docs.mulesoft.com/jp/cloudhub/lb-cert-upload) - [許可リスト](https://docs.mulesoft.com/jp/cloudhub/lb-allowlists) - [マッピングルール](https://docs.mulesoft.com/jp/cloudhub/lb-mapping-rules) - [Runtime Manager でのロードバランサーの作成](https://docs.mulesoft.com/jp/cloudhub/lb-create-arm) - [Runtime Manager を使用した DLB での TLS 1.0 の有効化](https://docs.mulesoft.com/jp/cloudhub/lb-create-arm#enable-tls-1-0-on-a-dlb-using-runtime-manager) - [CLI を使用した DLB での TLS 1.0 の有効化](https://docs.mulesoft.com/jp/cloudhub/lb-create-cli#enable-tls-1-0-on-a-dlb-using-the-cli) - [CloudHub API を使用した DLB での TLS 1.0 の有効化](https://docs.mulesoft.com/jp/cloudhub/lb-create-api#enable-tls-1-0-on-a-dlb-using-the-cloudhub-api) # 専用ロードバランサーのマッピングルール CloudHub 専用ロードバランサー (DLB) は、クライアントからの要求を VPC 内でデプロイされている Mule アプリケーションに転送します。 _マッピングルール_​により、DLB が受信する要求を (HTTP ホストヘッダーによって一致ルールを特定して) 異なる Mule アプリケーション名とドメインに転送できます。 マッピングルールは、DLB の作成時に定義するか、または Runtime Manager、コマンドラインインターフェース (CLI)、CloudHub API を使用して既存の DLB に追加できます。 シンプルな一致ルールを作成する場合、1 つの入力アドレスが定義済みの出力 (アプリケーションのエンドポイント) に一致します。 リテラル一致の代わりにパターンを使用して、変数のような入力テキストをエンドポイントに対して照合することができます。 ルールの優先度は順序によって決まります。 リスト中で最初に一致したルールが適用されます。
マッピングルールを定義していない場合、DLB はデフォルトのマッピングルールを作成して使用します。 デフォルトのマッピングルールは後で変更できます。
## [](#マッピングルールの作成)マッピングルールの作成 マッピングルールは、証明書の共通名 (CN) で識別されるロードバランサーの SSL エンドポイントの属性です。 マッピングルールを作成すると証明書が関連付けられます。 - Runtime Manager マッピングルールは証明書の定義内で定義します。 - CLI または CloudHub API 証明書の CN を指定する必要があります。 証明書名を省略すると、マッピングはデフォルトのエンドポイントに追加されます。 ### [](#runtime-manager-でのマッピングルールの作成)Runtime Manager でのマッピングルールの作成 Runtime Manager を使用して DLB の SSL エンドポイントでマッピングルールを作成する手順は次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左側のメニューで ​**\[Load Balancers (ロードバランサー)\]**​ を選択します。 3. ロードバランサー名をクリックして、証明書名をクリックします。 4. **\[URL Mapping Rules (URL マッピングルール)\]**​ セクションで ​**\[Add New Rule (新規ルールを追加)\]**​ をクリックします。 ![\*\[Add New Rule (新規ルールを追加)\]\* アイコンとマッピングルールの作成に必要な項目](_images/cloudhub-dlb-mapping-rules.png) Figure 1. このスクリーンショットは、(​**1**​) ​**\[Add New Rule (新規ルールを追加)\]**​ アイコンと (​**2**​) マッピングルールの作成に必要な項目を示しています。 5. 次の項目に入力します。 - **Input Path (入力パス)**​ (​`inputUri`​) クライアントが要求する URI (例: `/{app}/`​) 入力 URI は、ロードバランサーのホストヘッダーに付加されます。 - **Target App (対象アプリケーション)**​ (​`appName`​) 要求を処理する CloudHub アプリケーションの名前 (例: `{app}-example`​) - **Output Path (出力パス)**​ (​`appURI`​) アプリケーションに渡す URI 文字列 (例: `/`​) 出力パスではパターンを指定することはできません。 - **Protocol (プロトコル)**​ (​`upstreamProtocol`​) アプリケーションがリスンするプロトコル: - `http`​ (ポート 8091) - `https`​ (ポート 8092) - `ws`​ WebSockets (ポート 8091) - `wss`​ SSL/TLS 経由の WebSockets (8092) デフォルトでは、ロードバランサーは HTTPS で外部要求をリスンし、HTTP でワーカーと内部的に通信します。VPC で HTTPS をリスンするように Mule アプリケーションを設定してある場合は、マッピングルールリストを作成するときに ​**\[Protocol (プロトコル)\]**​ を ​`https`​ に設定します。 この DLB では、項目の値とクライアントの要求を使用して対象アプリケーションに送信されるパスを生成します。 たとえば、クライアントの要求が ​`/hello/world/`​ でマッピングルール項目が次のように設定されているとします。 - **Input Path (入力パス)**​: `/hello/` - **Target App (対象アプリケーション)**​: `myApp1` - **Output Path (出力パス)**​: `/test/` この DLB では出力パスの値 (​`/test/`​) を使用し、クライアントの要求から入力パスに一致するセクション (​`/hello/`​) を削除して、残り (​`/world/`​) をクライアントの要求に追加します。 次に、生成されたパス (​`/test/world/`​) を対象アプリケーション (​`myApp1`​) に送信します。 入力パスを定義するときは、パターンまたはリテラル文字列を仕様できます。 出力パスの場合は、リテラル文字列のみを使用できます。 ### [](#cli-を使用したマッピングルールの作成)CLI を使用したマッピングルールの作成 CLI を使用して DLB でマッピングルールを作成する手順は次のとおりです。 ```text cloudhub load-balancer mappings add [options] [certificateName] ``` [「cloudhub load-balancer mappings add」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-mappings-add)​を参照してください。 ### [](#cloudhub-api-を使用したマッピングルールの作成)CloudHub API を使用したマッピングルールの作成 CloudHub CLI を使用して DLB でマッピングルールを作成する手順は次のとおりです。 ```text anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId} ``` [「CloudHub API」](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/version/V1/pages/home/)​を参照してください。 ## [](#マッピングルールでのパターンの使用)マッピングルールでのパターンの使用 _パターン_​は、入力テキストを照合するためのテンプレートを定義する文字列です。 中括弧 (​`{ }`​) の値は変数として処理されます。 - 変数の​**名前**​では、小文字の英文字 (​`a-z`​) のみを使用できます。 - 変数の​**値**​には、​`a-z0-1.&?-_`​ の文字を含めることができますが、スラッシュ (​`/`​) を含めることはできません。
DLB では、​[Output Path (出力パス)]​ (​appURI​) ではパターンをサポートしていません。
### [](#url-マッピング)URL マッピング **Input Path (入力パス)**​ としてアプリケーション名を渡し、CloudHub のアプリケーション名に直接マップできます。
ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/{app}/

{app}

/

http

このルールは ​`lb-demo.lb.anypointdns.net/{app}`​ への要求をマップして ​`{app}.cloudhub.io`​ にリダイレクトします。 `{app}`​ のパターンは、インバウンド要求で渡すアプリケーション名と一致します。 ### [](#ホストマッピング)ホストマッピング SSL エンドポイントで ​`*.example.com`​ のような [ワイルドカード証明書](https://en.wikipedia.org/wiki/Wildcard_certificate)​を設定してある場合、​`subdomain`​ 変数を使用して任意のサブドメインをマップできます。
ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/

{subdomain}

/

https

このルールは、​`example.com`​ のサブドメインに渡される要求を対応する ​`appName`​ に自動的にマップします。 - `api.example.com`​ を渡すと、​`api.cloudhub.io`​ にリダイレクトされる。 - `application.example.com`​ を渡すと、​`application.cloudhub.io`​ にマップされる。 `subdomain`​ 変数では、SSL エンドポイントの [サブジェクト代替名](https://en.wikipedia.org/wiki/Subject_Alternative_Name)​ (SAN) を使用することもできます。 DLB を介して任意のサブドメインのアプリケーション名を渡すことができるワイルドカード証明書を使用する代わりに、許可されるサブドメイン名を指定できます。 これを行うには、証明書の共通名に対して SAN を設定する必要があります。 `subdomain`​ 変数を使用してドメイン名のサブドメイン部分をアプリケーションにマップできます。 この例には以下が含まれます。 - 2 つのデプロイ済みアプリケーション: - `dev-app` - `qa-app` - 以下の SAN が設定された SSL エンドポイント: - `dev.example.com` - `qa.example.com` - マッピングルール:
ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/

{subdomain}-app

/

https

このルールは、ドメイン名のサブドメイン部分をアプリケーション名にマップします。 - `dev.example.com`​ は ​`dev-app.cloudhub.io`​ にリダイレクトされます。 - `qa.example.com`​ は ​`qa-app.cloudhub.io`​ にリダイレクトされます。 ## [](#リテラル-11-マッピングの使用)リテラル 1:1 マッピングの使用 パターンを使用する代わりに、リテラルアプリケーション名をマップできます。 この場合、ルールはアプリケーションと正確に一致する必要があります。 このルールは、デフォルトのロードバランサー ​`lb-demo.lb.anypointdns.net`​ を CloudHub のアプリケーション ​`myApp.cloudhub.io`​ に直接マップします。
ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/

myApp

/

http

このルールは、入力 URI が ​`/misc/myhellotest/v1/ping`​ の場合は ​`dev-misc-myhellotest-v1-myapp`​ アプリケーションと一致しますが、​`/misc/myhellootest/v1/ping`​ の場合は一致しません。
ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/{layera}/{domaina}/v{versiona}/

dev-{layera}-{domaina}-{versiona}-myapp

/api/

http

**\[Input Path (入力パス)\]**​ を、定義したパターンではなく静的な文字列に変更することで、リテラル 1:1 マッピングを複数のアプリケーションに対して使用することもできます。
ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/v1/applicationX

application-x

/api/

http

2

/v1/applicationY

application-y

/api/

http

3

/v2/applicationx

application-x-v2

/api/

http

## [](#マッピングルールの優先度)マッピングルールの優先度 各ルールで優先度を定義します。 リスト内では、先にあるルールの方が後のルールより優先されます。 DLB は、さらに一致精度の高いルールがリストの後の方にある場合でも、常に最初に一致したルールを使用します。 ルールを作成する場合は、複数のルールが互いに上書きしてしまわないように、各ルールの順序に注意してください。 次の例では、​`/api/v1/secondapp`​ という URL を ​`default-app`​ アプリケーションにマップしています。
Priority (優先度) Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) プロトコル

1

/api/v1/

default-app

/api/v1/

http

2

/api/v1/secondapp/

second-app

/api/v1

http

ルールが ​`second-app`​ のみと一致するようにするには、ルールの優先度を次のように定義する必要があります。
Priority (優先度) Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) プロトコル

1

/api/v1/secondapp/

second-app

/api/v1

http

2

/api/v1/

default-app

/api/v1/

http

### [](#runtime-manager-でのマッピングルールの優先度の変更)Runtime Manager でのマッピングルールの優先度の変更 Runtime Manager でマッピングルールの優先度を変更するための手順は次のとおりです。 1. Anypoint Platform の ​**\[Runtime Manager\]**​ を選択します。 2. 左側のメニューで ​**\[Load Balancers (ロードバランサー)\]**​ を選択します。 3. ロードバランサー名をクリックして、証明書名をクリックします。 4. **\[URL Mapping Rules (URL マッピングルール)\]**​ セクションで、ルールにマウスポインターを置いてハンドルを表示します。 ![マッピングルールの順序を変更するために使用するハンドル](/mulesoft/current/ja-jp/cloudhub/_images/cloudhub-dlb-mapping-rules-reorder.png) Figure 2. 矢印は、マッピングルールの順序を変更するために使用するハンドルを示しています。 5. ハンドルをクリックしてドラッグすることで、リスト内でルールを上下に移動します。 6. **\[Done Editing (編集完了)\]**​ をクリックします。 ### [](#cli-を使用したマッピングルールの優先度の変更)CLI を使用したマッピングルールの優先度の変更 CLI でマッピングルールを作成するときにマッピングルールの優先度を指定するには、​`index`​ 値を使用します。 インデックス ​`0`​ のルールが最高の優先度となります。割り当てられたインデックスが大きいほど、優先度は低くなります。 [「cloudhub load-balancer mappings add」](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-mappings-add)​を参照してください。 ### [](#cloudhub-cli-を使用したマッピングルールの優先度の変更)CloudHub CLI を使用したマッピングルールの優先度の変更 API を使用してマッピングルールを作成する場合は、優先度を指定することはできません。 新たに作成されたルールは、リストの末尾に付加されます。 後でロードバランサーエンドポイントに ​`PATCH`​ 要求を送信することで、ルールの順序を変更できます。 ```text anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId} ``` ロードバランサー ID を調べるには、エンドポイントに対して GET 要求を実行します。 ```text /organizations/{orgid}/loadbalancers ``` ## [](#関連情報)関連情報 - [CloudHub 専用ロードバランサー](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli) - [CloudHub API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/cloudhub-api/version/V1/pages/home/) - [証明書の追加](https://docs.mulesoft.com/jp/cloudhub/lb-cert-upload) - [許可リスト](https://docs.mulesoft.com/jp/cloudhub/lb-allowlists) # 専用ロードバランサーの更新 CloudHub 専用ロードバランサーサービスには、最新の OS とセキュリティパッチを含むアップデートが四半期ごとに提供されます。また、必要に応じて追加のパッチによる更新が随時提供されます。 これらの更新には機能の変更は含まれません。 これらの更新には必須のセキュリティパッチが含まれるため、一度適用したらロールバックすることはできません。 更新が利用できるようになると、ロードバランサーのページに ​**\[Update (更新)\]**​ ボタンが表示されます。 ![LoadBalancerUpdatePage](/mulesoft/current/ja-jp/cloudhub/_images/lb-update-page.png) **\[Update (更新)\]**​ ボタンは、個別のロードバランサーの詳細ページにも表示されます。 ![LoadBalancerUpdateDetails ページ](/mulesoft/current/ja-jp/cloudhub/_images/lb-update-details.png) ## [](#専用ロードバランサーを更新する)専用ロードバランサーを更新する **\[Update (更新)\]**​ ボタンが表示された場合は、ロードバランサーの更新が必要なことを意味しています。都合に合わせて更新の予定を立ててください。本番環境の DLB を更新する前に、Sandbox の DLB を更新して、必要なテストを実施してください。 ロードバランサーを更新するには、次の手順を実行します。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ をクリックします。 2. **\[Load Balancers (ロードバランサー)\]**​ をクリックします。 3. **\[Update (更新)\]**​ ボタンをクリックします。 4. **\[Update load balancer (ロードバランサーを更新)\]**​ 画面で ​**\[Update (更新)\]**​ をクリックします。 更新の詳細を見るには、​**\[View release notes (リリースノートを表示)\]**​ リンクをクリックしてください。
静的 IP アドレスを使用して DLB を更新する場合、更新に追加の静的 IP アドレスが必要なこともあります。これらの新しい IP アドレスを許可リストに追加するよう要求された場合は、​[Update (更新)]​ をクリックする前に追加してください。
更新が完了すると、ダウンタイムなしでローリング再起動が実行されます。ただし、一部の処理中の要求が影響を受ける可能性があります。 更新後にシステムが停止したままになった場合は、MuleSoft サポートに連絡してください。 ## [](#関連情報)関連情報 - [静的 IP アドレス](https://docs.mulesoft.com/jp/cloudhub/cloudhub-dedicated-load-balancer#static-ip-addresses) - [DLB の月 1 回のスケジュール済み更新に関する FAQ](https://help.mulesoft.com/s/article/DLB-Monthly-Scheduled-Update-FAQ) # 専用ロードバランサーの許可リスト IP アドレスによる専用ロードバランサー (DLB) へのアクセスを許可するには、それらの IP アドレスを DLB の許可リストに CIDR 表記で追加する必要があります。
許可リストは、CN 証明書レベルではなく、ロードバランサーレベルのインバウンド接続でのみ動作します。
許可リストに登録した IP アドレスは、DLB を作成するときに追加するか、または Runtime Manager やコマンドラインインターフェースを使用して既存の DLB に追加できます。 ## [](#dlb-許可リストエントリの制限)DLB 許可リストエントリの制限 DLB 許可リストに追加できる IP アドレスエントリの最大数は、HTTP 要求を受信したときの DLB の動作を指定する DLB 設定のインバウンド HTTP モード設定によって異なります。
インバウンド HTTP モード 許可リストエントリの最大数

Off (オフ)

240

On (オン)

120

Redirect (リダイレクト)

120

DLB 許可リストのエントリ数が 120 を超えると、HTTP モードを ​[On (オン)]​ に設定できなくなります。
## [](#既存の-dlb-の許可リストに-ip-アドレスを追加する)既存の DLB の許可リストに IP アドレスを追加する Runtime Manager を使用して DLB の許可リストに IP アドレスを追加する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ をクリックします。 2. **\[Load Balancers (ロードバランサー)\]**​ をクリックして、ロードバランサー名をクリックします。 3. **\[Allowlisted CIDRs (許可リストに登録されている CIDR)\]**​ タブで、​**\[Add New CIDR (新規 CIDR を追加)\]**​ をクリックします。 ![ロードバランサーの設定ページの \*\[Add New CIDR (新規 CIDR を追加)\]\* オプション](_images/lb-allowlist-update.png) Figure 1. **\[Allowlisted CIDRs (許可リストに登録されている CIDR)\]**​ タブの ​**\[Add New CIDR (新規 CIDR を追加)\]**​ を示す矢印。 4. 有効な CIDR 形式で IP アドレスを入力します (例: `10.2.0.0/16`​)。 5. **\[Add To List (リストに追加)\]**​ をクリックします。 6. CIDR を削除する場合は、​**…​**​ アイコンにマウスポインターを置いて、ごみ箱アイコンを表示します。 7. **\[Apply Changes (変更を適用)\]**​ をクリックします。 CLI を使用して DLB の許可リストに IP アドレス範囲を追加するには、次のように入力します。 cloudhub load-balancer allowlist add myLB\_name myCIDRblock IP アドレスは有効な CIDR 形式で指定されている必要があります (例: `10.2.0.0/16`​)。 許可リストから IP アドレスを削除するには、次のように入力します。 cloudhub load-balancer allowlist remove myLB\_name myCIDRblock ## [](#関連情報)関連情報 - [cloudhub load-balancer allowlist add](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-allowlist-add) - [cloudhub load-balancer allowlist remove](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-allowlist-remove) - [IPv4 CIDR ブロック](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#IPv4_CIDR_blocks) - [Runtime Manager でのロードバランサーの作成](https://docs.mulesoft.com/jp/cloudhub/) - [Anypoint Platform CLI でのロードバランサーの作成](https://docs.mulesoft.com/jp/cloudhub/lb-create-cli) - [内部ワーカー DNS と CloudHub の内部 DLB DNS](https://help.mulesoft.com/s/article/Internal-Worker-DNS-vs-Internal-DLB-DNS-in-CloudHub) # 専用ロードバランサーへの証明書の追加 専用ロードバランサー (DLB) を作成するときには、最低 1 つの証明書を追加する必要があります。 Runtime Manager またはコマンドラインインターフェースを使用して DLB に証明書を追加できます。 証明書は、暗号化されていない 1 つの PEM エンコードファイルに含まれている必要があります。 Windows ツールで作成された証明書を移行する場合は、次の操作を実行します。 - すべての「Bag Attributes (バッグ属性)」および「Key Attributes (キー属性)」を削除します。 - 必要に応じて、すべての行末文字を ​`\r\n`​ から ​`\n`​ に変換します。 このファイルには、連続する順序の証明書チェーン全体が含まれている必要があります。
Certificate (証明書) 例

プライマリ証明書

-----BEGIN CERTIFICATE-----
(プライマリ SSL 証明書: <ドメイン名>.crt)
-----END CERTIFICATE-----

中間証明書

-----BEGIN CERTIFICATE-----
(中間証明書: DigiCertCA.crt)
-----END CERTIFICATE-----

証明書チェーンにルート証明書を含める必要はありません。 ただし、各証明書に ASCII アーマーを含める必要があります。 ## [](#証明書を既存のロードバランサーに追加する)証明書を既存のロードバランサーに追加する Runtime Manager またはコマンドラインインターフェースを使用して DLB に証明書を追加できます。 Runtime Manager を使用して証明書を追加する手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ をクリックします。 2. **\[Load Balancers (ロードバランサー)\]**​ をクリックして、ロードバランサー名をクリックします。 3. **\[Certificates (証明書)\]**​ タブで ​**\[Add certificate (証明書を追加)\]**​ をクリックします。 ![ロードバランサーの設定ページの \[Add certificate (証明書を追加)\] オプション](_images/lb-cert-upload-update.png) Figure 1. **\[Certificates (証明書)\]**​ タブの ​**\[Add certificate (証明書を追加)\]**​ オプションを示す矢印。 4. **\[Choose File (ファイルを選択)\]**​ を選択して、次のような公開キーファイルと非公開キーファイルをアップロードします。 - 公開キーファイル サーバー証明書と中間 CA 証明書の両方を含む PEM ファイル (例: `example-com-crt.pem`​) - 非公開キーファイル パスフレーズのない非公開キーを含む PEM ファイル (例: `example-com-private-noencrypt.pem`​) パスフレーズのないファイルを作成するには、次のようなコマンドを実行します。 ```console openssl rsa -in example-com-private.pem -out example-com-private_noencrypt.pem ``` 5. **\[Save Certificate (証明書を保存)\]**​ をクリックします。 CLI を使用して既存の DLB に証明書を追加するには、次のように入力します。 ```console cloudhub load-balancer ssl-endpoint add myLB_name example-com-crt.pem example-com-private.pem ``` ## [](#既存のロードバランサーの証明書を置き換える)既存のロードバランサーの証明書を置き換える 証明書が期限切れの場合や更新の必要がある場合には、既存のロードバランサーの証明書を置き換えることができます。 Runtime Manager を使用して証明書を置き換える手順は、次のとおりです。 1. Anypoint Platform から ​**\[Runtime Manager\]**​ をクリックします。 2. **\[Load Balancers (ロードバランサー)\]**​ をクリックして、ロードバランサー名をクリックします。 3. **\[Certificates (証明書)\]**​ タブで証明書名をクリックします。 4. **\[Choose File (ファイルを選択)\]**​ を選択して、次のような公開キーファイルと非公開キーファイルをアップロードします。 - 公開キーファイル サーバー証明書と中間 CA 証明書の両方を含む PEM ファイル (例: `new-example-com-crt.pem`​) - 非公開キーファイル: パスフレーズのない非公開キーを含む PEM ファイル (例: `new-example-com-private-noencrypt.pem`​) パスフレーズのないファイルを作成するには、次のようなコマンドを実行します。 ```console openssl rsa -in new-example-com-private.pem -out new-example-com-private_noencrypt.pem ``` 5. **\[Done Editing (編集完了)\]**​ をクリックします。 6. **\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#関連情報)関連情報 - [SSL エンドポイントの設定](https://docs.mulesoft.com/jp/cloudhub/lb-ssl-endpoints) - [Runtime Manager でのロードバランサーの作成](https://docs.mulesoft.com/jp/cloudhub/lb-create-arm) - [Anypoint Platform CLI でのロードバランサーの作成](https://docs.mulesoft.com/jp/cloudhub/lb-create-cli) - [cloudhub load-balancer ssl-endpoint add](https://docs.mulesoft.com/jp/cloudhub/cloudhub-cli#cloudhub-load-balancer-ssl-endpoint-add) # 脆弱性評価と侵入テストの実行 会社のセキュリティポリシーで、Anypoint Platform に対して脆弱性テストと侵入テストの実行が求められている場合は、事前に Salesforce に通知せずにテストを開始できます。 すべての評価は、 [セキュリティ評価同意書](https://help.salesforce.com/s/articleView?id=000392845&type=1)​に準拠して実施する必要があります。 ## [](#侵入テストと脆弱性テストを実行する)侵入テストと脆弱性テストを実行する 侵入テストは他のテナントに干渉する可能性があるため、MuleSoft では侵入テストの実行をユーザーのワーカー上でのみ許可しており、他の Anypoint Platform サービス上では許可していません。
Salesforce は、カスタムデプロイメントで見つかった脆弱性については対応していません。 カスタムデプロイメントの検証と見つかった問題の修復は、お客様の責任となります。
### [](#前提条件)前提条件 侵入テストを開始する前に行うこと: - アプリケーションの静的 IP を有効化する。 デフォルトでは、CloudHub ワーカーは静的 IP アドレスを使用せず、IP アドレスが変更されてしまうため、テストすることはできません。静的 IP を有効化する方法は、​[「Static IPs Tab Settings (\[Static IPs (静的 IP)](https://docs.mulesoft.com/jp/cloudhub/deploying-to-cloudhub#static-ips-tab-settings) タブの設定)」\]​を参照してください。 - テストの結果を確認して検証するための会社のセキュリティリソースを割り当てる。 ### [](#手順)手順 1. 侵入テストを実行します。 セキュリティ評価同意書には、テストの制限と要件も含まれています。 2. 次のドキュメントを参考にして、よくある偽陽性や設定に関するセキュリティの問題を特定するように、セキュリティリソースに指示します。 - [プラットフォームのセキュリティに関する FAQ](https://help.salesforce.com/articleView?id=Salesforce-Platform-Security-FAQs&type=1&language=en_US) - [Salesforce ヘルプ](https://help.salesforce.com) 3. 評価で脆弱性が検出された場合は、自動検出の検証を完了してください。未解決の検証済みセキュリティ脆弱性が見つかったら、すべて [security@salesforce.com](mailto:security@salesforce.com) に報告してください。 メールには次の情報を含めてください。 - Salesforce が承認したセキュリティ評価の確認番号 - 見つかった脆弱性の概要とそれぞれの重大度レベル - それぞれの脆弱性を説明した詳細な評価レポート - 脆弱性を再現するための手順 - 関連するすべての HTTP 要求と応答 - サンプルを脆弱性だと判断した理由の説明 ### [](#セキュリティの脆弱性のレポート)セキュリティの脆弱性のレポート セキュリティ脆弱性の発見についてレポートするには、 [「Security Vulnerability Finding Submittal Guide (見つかったセキュリティ脆弱性の送信ガイド)」](https://help.salesforce.com/articleView?id=000320207&type=1&mode=1)​の手順に従ってください。必要な手順に従っていないセキュリティ脆弱性レポートは拒否されます。 Salesforce では、次のカテゴリのセキュリティ脆弱性については対応していません。 - 有効な概念実証のない自動脆弱性スキャンツールからのスキャン出力 - 有効な概念実証のないセキュリティバグ - 以前のまたは非推奨のバージョンの Mule Runtime Engine で識別された脆弱性 - 自社で行ったコードのカスタマイズにより発生した脆弱性 - リスクが発生しない既知のセキュリティの問題 ## [](#関連情報)関連情報 - [CloudHub でのアプリケーションの管理](https://docs.mulesoft.com/jp/cloudhub/managing-applications-on-cloudhub) - [CloudHub](https://docs.mulesoft.com/jp/cloudhub/) - [CloudHub のアプリケーションの開発](https://docs.mulesoft.com/jp/cloudhub/developing-applications-for-cloudhub) - [デプロイメントオプション](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies)