CloudHub 2.0 オペレーティングシステムのパッチ更新

コンテナベースのプラットフォームである CloudHub 2.0 は、必要に応じてインフラストラクチャ修正とセキュリティパッチが適用されるため、インフラストラクチャが保護され、最新の状態に保たれます。パッチ更新では、ローリングアップグレードデプロイメントが使用され (デプロイメントモデルとして選択されている場合)、オペレーティングシステムの変更または内部ソフトウェアへの変更が含まれる場合があります。ローリング更新デプロイメントモデルを使用している場合、更新により基盤となるホストの段階的な循環、ドレイン、置換が行われるため、ダウンタイムがゼロになります。アップグレード中に、Mule アプリケーションが新しいセキュアホスト上で再起動される場合があります。Mule ワーカーが複数のレプリカで実行されていない場合、または再作成デプロイメントモデルを使用している場合、わずかなダウンタイムが発生します。

更新が利用可能になると、CloudHub 2.0 はそれを新しい非公開スペースのデフォルトとして本番環境に含めます。既存のインフラストラクチャパッチスケジュールは、​『CloudHub 2.0 Runtime パッチ』​と同じメンテナンス期間で実行されます。インフラストラクチャと Runtime の更新により、アプリケーションの再起動が行われる場合があります。

CloudHub 2.0 で使用される ​『Anypoint VPN』​ は、継続的にアップグレードされます。新しい更新が利用可能になるたびに、サービスレベル契約内で VPN にパッチが適用されます。Anypoint VPN が高可用性としてセットアップされていない場合、または非高可用性 VPN が 2 つのトンネルを使用してセットアップされていない場合、ダウンタイムが予想されます。

リリースが使用可能になってから​『月 1 回の更新テーブル』​に記載されている自動更新日までの間に、スケジュールされたパッチプロセスよりも早くインフラストラクチャアップグレードをスケジュールします。こうすることで、組織にとって都合の良い将来日付を選択できます。

平均で、このアップグレードが完了するには 30 ～ 60 分かかります。アップグレードがキューに登録されている場合は、30 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。

スケジュールされたアップグレードは、まだ進行中でなければ変更または削除できます。これは、​[Queued (キューに登録済み)]​ 状況で確認できます。スケジュールをキャンセルした場合、別のスケジュールを作成するか、以前のアップグレードにオプトインしないと、必須のパッチ適用期間中にアップグレードが発生します。

リリースが使用可能になってから​『月 1 回の更新テーブル』​に記載されている自動更新日までの間に、スケジュールされたパッチプロセスよりも早くインフラストラクチャアップグレードを適用します。こうすることで、組織にとって都合の良いタイミングを選択できます。

平均で、このアップグレードが完了するには 30 ～ 60 分かかります。アップグレードがキューに登録されている場合は、30 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。

各月の最初の 1 週間に、MuleSoft では​日付パッチ更新​をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。

月 1 回のパッチでは、アプリケーションがパッチバージョンの最新の日付パッチのみに更新されます。 パッチバージョン番号は変更されません。

これらの 4.3.x または 4.4.x バージョンへの更新のバージョン番号の形式は次のようになります。

メジャー​.マイナー.パッチ​ : 日付

パッチ日付が含まれるバージョン番号の例を示します。

4.4.0:20211015

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

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

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

詳細は、『Edge and LTS Releases for Mule』を参照してください。

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. Consider the following factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.

In February, both Edge and LTS release with the same underlying version, including a 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.

Starting with Mule 4.5, MuleSoft releases Edge versions in February, June, and October. 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.

Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions annually in February. If you are on Mule 4.4, you are not required to upgrade to Mule 4.6. However, because Mule 4.5 releases 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.

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.

次の表に、CloudHub 2.0 の Mule Runtime リリースケイデンスサポートを示します。

Application lifecycle management depends on the deployment model.

The version naming convention depends on the deployment model you are using. A version increments:

最新のランタイムバージョンが使用できる場合:

MuleSoft によって、パブリッシュされたスケジュールに基づいて更新が自動的に適用されます。 必要があれば、都合に合わせて手動で更新できます。

Edge リリースチャネルを選択すると、次の自動更新の日付を示すバナーが表示されます。

[Private Space (非公開スペース)]​ ページの ​[Infra Status (インフラ状況)]​ 列には、非公開スペースのインフラストラクチャのアップグレードの状況が表示されます。

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

新しい更新が行われた後で、Runtime Manager の ​[Applications (アプリケーション)]​ タブの ​[Status (状況)]​ 列で​「アプリケーション状況の状態」​を確認できます。

また、アプリケーションログをチェックして、アプリケーションが正しくデプロイされたかどうかを確認し、一部の自動マイナー更新関連の問題が発生した場合に修正アクションを実行することもできます。詳細は、​「ログを表示する」​を参照してください。