Mule Runtime パッチ更新の管理

以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新と Mule Runtime Engine リリースチャネルに関する重要な情報を提供します。

月 1 回の日付パッチ更新

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

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

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

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

4.3.0:20210101

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

Mule Runtime Fabric のランタイムパッチ更新スケジュール

Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。

  1. 月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。

  2. 次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは​猶予期間​と呼ばれます。

  3. 月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。

Mule Runtime Engine のバージョン 4.5 から、バージョンのピン留めに必要なタグを渡すことで、再デプロイ時に Mule アプリケーションの自動アップグレードを無効にできます。

猶予期間中は、前の日付のパッチバージョンが Runtime Manager UI で使用できなくなるまで、これらのバージョンを選択できます (その後も API 経由であれば使用できます)。この動作は、Edge および LTS チャネルリリースの Mule Runtime Engine バージョン 4.5 から変更されます。すべてのビルドタグは、Runtime Manager UI および API で利用できます。

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

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

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

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

  2. [Deployment Target (デプロイメント対象)]​ の ​[Runtime version (ランタイムバージョン)]​ リストから、​new​ とタグ付けされたバージョンを選択します。

    新しいランタイムバージョンが選択されています。

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

    日付で示されている最新のランタイムバージョン。
  3. バージョンの詳細を確認するには、​[Read release notes (リリースノートを読む)]​ リンクをクリックします。

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

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

  5. アプリケーションを再デプロイします。

    Runtime Fabric の Mule デプロイメントには、自動的にパッチが適用されません。最新の日付のパッチ更新を適用するにはアプリケーションを再デプロイする必要があります。

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.

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 PolicyLeaving the Site.

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.

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.

アクション Runtime Fabric

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

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

自動アップグレード

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

自己アップグレード

Always available

ロールバック

Available to the previously used version

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

Always

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

Always

延長サポートの終了

Cannot deploy new apps

廃止

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

サポート可能性

Supported while Mule apps are within the assigned support period.

Mule Runtime Version 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.

Runtime Fabric

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

Runtime Fabric の要件 regular OS updates, hence the addition of the build enumeration in the full runtime version schema.

Here are examples of the version numbers:

  • Edge: 4.5.0:1e

  • Edge: 4.6.0:1e

  • LTS: 4.6.0:1

Mule runtime does not introduce a semVer increment if there is a month with no fixes.

Here is an example of the versioning schema using different patch and builds:

Hybrid Standalone CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

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.

Runtime Manager UI で ​[Use Edge Release Channel (Edge リリースチャネルを使用)]​ オプションを選択すると、プラットフォームには Edge チャネルと LTS チャネルのすべてのビルドタグが表示されます。このビルドタグにより、指定した Mule Runtime バージョンでイメージを複数回ビルドできるため、このビルドタグは Runtime Manager と CloudHub 2.0 に固有となっています。 Runtime Manager UI には Mule Runtime Engine のバージョン 4.5 以前用のビルドタグは表示されませんが、API 経由で任意のビルドを使用できます。

バージョンの書き換え

バージョンの書き換えは、デプロイメント要求で指定されたビルドタグがサポート終了または無効だった場合に、そのビルドタグを上書きするために使用されます。2023 年 10 月 3 日以降、バージョン書き換えは、どのバージョンでも指定されたタグを上書きしません。ただし、ビルドタグなしで Mule アプリケーションが API 経由でデプロイされた場合は、最新のビルドが自動的に選択されます。