1. Homepage
  2. CloudHub

  3. CloudHub Runtime の継続的な更新

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

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

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

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

4.2.2 - 05-04-2020

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

更新スケジュール

日付パッチ更新のスケジュールは次のとおりです。

  • 月の第 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​ によるエントリが含まれ、更新が行われた日時と更新に成功したかどうかが示されます。

    更新に成功した場合、アクションは必要ありません。 ダウンタイムなしの再起動の制限​を参照してください。

アプリケーションでダウンタイムなしの更新がサポートされないか、手動での更新が必要な場合、月の第 1 週にリリースされた日付パッチを第 1 週または第 2 週に適用できます。 手動でのランタイムバージョンの更新​を参照してください。

複数のアプリケーションを更新するには、CloudHub API を使用します。 複数のアプリケーションの最新のランタイムリリースへの更新​を参照してください。

通知の更新

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

  • [Applications (アプリケーション)]​ ページにバナーが表示され、​[Update Available (更新が使用可能)]​ タブに更新が必要なアプリケーションがリストされます。

    バナーと 「Update Available (更新が使用可能)」 タブが表示された 「Applications (アプリケーション)」 ページ
    Figure 1. このスクリーンショットは、​[Applications (アプリケーション)]​ ページの (​1​) バナーと (​2​) ​[Update Available (更新が使用可能)]​ タブを示しています。

    更新が必要なアプリケーションがない場合、バナーは表示されず、​[Update Available (更新が使用可能)]​ タブは空白になります。

  • ​[Update available (更新が使用可能)]​ と新しい日付パッチがアプリケーションの ​[Settings (設定)]​ ページの ​[Runtime version (ランタイムバージョン)]​ メニューに表示されます。

    「Runtime version (ランタイムバージョン)」 メニューの日付パッチバージョン更新と 「Update available (更新が使用可能)」。
    Figure 2. このスクリーンショットは、(​1​) 日付パッチバージョンの更新と (​2​) ​[Runtime version (ランタイムバージョン)]​ メニューの ​[Update available (更新が使用可能)]​ を示しています。

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

ライブパッチ

CloudHub は、OS に最新のセキュリティパッチや重要なバグパッチを適用するため、基盤となる VM でカーネルライブパッチを使用します。毎月のパッチ適用サイクルの間に CloudHub アプリケーションを再起動する必要はありません。

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

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

アプリケーションにライブパッチが適用されているかどうかの確認

アプリケーションのログ​を確認することで、ライブパッチが適用されたかどうかを判断できます。

アプリケーションのライブパッチログ

手動でのランタイムバージョンの更新

[Update Available (更新が使用可能)]​ タブでは、ランタイムバージョンの更新が必要な 1 つ以上のアプリケーションが示されます。 都合に合わせて更新の予定を立ててください。

本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。

1 つのアプリケーションの最新のランタイムリリースへの更新

アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。

  1. Runtime Manager のナビゲーションメニューで ​[Applications (アプリケーション)]​ をクリックします。

  2. [Update Available (更新が使用可能)]​ タブをクリックします。

  3. アプリケーションの ​[Status (状況)]​ 列をクリックして、詳細ペインを表示します。

  4. [Manage Application (アプリケーションを管理)]​ ボタンをクリックして、アプリケーションの ​[Settings (設定)]​ ページを表示します。

    アプリケーションで更新が必要な場合、​[Update available (更新が使用可能)]​ が ​[Runtime version (ランタイムバージョン)]​ メニューに表示されます。

    アプリケーションの 「Settings (設定)」 ページの 「Update available (更新が使用可能)」 と 「Runtime version (ランタイムバージョン)」 メニュー
    Figure 3. このスクリーンショットは、​[Settings (設定)]​ ページの (​1​) ​[Update available (更新が使用可能)]​ と (​2​) ​[Runtime version (ランタイムバージョン)]​ メニューを示しています。

  5. [Runtime Version (ランタイムバージョン)]​ メニューから最新バージョンを選択します。

    更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。

    「Runtime Version (ランタイムバージョン)」 メニューのバージョン更新日
    Figure 4. 矢印は、​[Runtime version (ランタイムバージョン)]​ メニューのバージョン更新日を示しています。

  6. バージョンの詳細を確認するには、​[Read release notes (リリースノートを読む)]​ リンクをクリックします。

  7. [Apply Changes (変更を適用)]​ ボタンをクリックしてアプリケーションを更新します。

CloudHub により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。

アプリケーションの更新に成功した場合、アプリケーションは ​[Applications (アプリケーション)]​ ページの ​[Update Available (更新が使用可能)]​ タブに表示されなくなります。

アプリケーションの更新に失敗した場合、アプリケーションは ​[Update Available (更新が使用可能)]​ タブに表示されたままになります。 この場合、アプリケーションは引き続き以前のランタイムバージョンで正常に実行されたままになり、アクションは必要ありません。

複数のアプリケーションの最新のランタイムリリースへの更新

Runtime Manager UI では複数のアプリケーションの最新のランタイムバージョンへの更新はサポートされていませんが、CloudHub API を使用して一括更新を実行することはできます。 「How to Perform a Bulk CloudHub Application Update to the Latest Runtime Releases (CloudHub アプリケーションの最新のランタイムリリースへの一括更新の実行方法)」​を参照してください。

Bulk Update API を使用して更新されたアプリケーションは、低い優先度で処理され、更新にかかる時間が若干長くなることがあります。

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

Channel Type Release Cadence Recommended Customer Profile Differentiators Support Coverage

Edge

Three times per year:

  • February

  • June

  • October

  • CloudHub and CloudHub 2.0

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions are not FedRAMP approved.

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

For version 4.8 and later:

  • 5 months of Standard Support

  • 3 months of Extended Support

LTS

Annual:

  • February

On-premises:

  • Hybrid Standalone

  • Runtime Fabric

  • 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.

  • Versions are FedRAMP approved.

For version 4.6 and later:

  • 18 months of Standard Support

  • 6 months of Extended 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.

The monthly patching process remains unchanged. See Update Patches to Mule.

Edge Channel

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.

LTS Channel

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.

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.

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.

自動アップグレード

  • Monthly upgrade when a new patch version is available.

  • Edge channel apps are auto-upgraded within two weeks.

  • LTS channel apps are auto-upgraded after two months when a new minor version is available.

自己アップグレード

The auto-upgrade occurs during a fixed period after MuleSoft releases the version and enforces the force-upgrade. During that period, you can do a manual upgrade.

  • Edge: two weeks

  • LTS: two months

ロールバック

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 do not reach End of Life because they are always auto-upgraded.

サポート可能性

All Mule apps are under Standard Support.

Mule Runtime Version Naming Changes

The version naming convention depends on the deployment model you are 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

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 are 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

N/A

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

N/A

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 the following 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.

ダウンタイムなしの再起動の制限

ダウンタイムなしの再起動は、次の場合には機能しません。

  • CloudHub アプリケーションが永続的なサブスクライバーである。

    この場合、一度にアクティブにできるのは 1 つの一意のサブスクライバーのみです。 これらのアプリケーションの場合、最新の更新を適用するにはアプリケーションを手動で停止して開始する必要があります。

  • CloudHub アプリケーションが接続している外部連動関係が使用できないか、応答しないか、ウォームアップが必要である。

    この場合、CloudHub はアプリケーションドメインおよび関連する静的 IP アドレス (使用する場合) を新しいバージョンのアプリケーションに割り当てる前に、アプリケーションが連動関係に接続するのを最大 3 分待機します。

いずれかの場合がアプリケーションに当てはまる場合、サポートおよび CSM アカウント担当者にアプリケーションのクラウド対応への更新に関する情報を問い合わせてください。

自動更新の失敗

青/緑デプロイメントで新しいワーカーへの自動更新のデプロイが失敗すると、アプリケーションは、現在実行中のワーカーでは最新でないパッチバージョンの実行を続行します。

考えられる失敗の原因の一部は次のとおりです。

  • デプロイ後に Anypoint Runtime Manager UI からアプリケーションプロパティの 1 つを削除した。

  • カスタムモジュールと最新パッチバージョンのリリースの間に互換性がない。

毎月のパッチサイクルを 2 回繰り返してもアプリケーションが自動更新されない場合は、アプリケーションが停止されて、最新のパッチバージョンに強制更新されます。更新後にアプリケーションが起動に失敗する場合は、手動でのパッチ対応が必要になります。

関連情報