Flex Gateway新着情報
Governance新着情報
Monitoring API Manager以下で、Anypoint Runtime Fabric の Mule Runtime Engine パッチ更新と Mule Runtime Engine リリースチャネルに関する重要な情報を提供します。
月 1 回、MuleSoft では日付パッチ更新をリリースします。これには、Mule Runtime Engine で発見された問題を解決するための後方互換性があるバグ修正が含まれています。 スケジュールされた日付がセキュリティ SLA 内であれば、月 1 回の日付パッチ更新にセキュリティパッチが含まれる場合もあります。
これらの更新のバージョン番号の形式は次のようになります。
メジャー.マイナー.パッチ - 日付
パッチ日付が含まれるバージョン番号の例を示します。
4.3.0:20210101
月 1 回のパッチでは、アプリケーションが最新の日付のパッチのみに更新されます。ランタイムバージョンは変更されません。
Runtime Fabric では、各アプリケーションおよびゲートウェイのデプロイメントが個別の Mule Runtime インスタンスで実行されます。これらのデプロイメントに使用されるコンテナ化された Mule イメージを管理することで、Runtime Fabric では次のスケジュールで各デプロイメントの Mule Runtime バージョンをアップグレードできます。
月の第 1 週には、更新された Mule Runtime インスタンスの新しい日付のパッチにアクセスできます。
次の 2 週間は、より新しい日付のパッチを使用してアプリケーションを再デプロイしてその動作を検証できます。これは猶予期間と呼ばれます。
月の第 3 週の開始時に、新しいアプリケーションをデプロイするとき、または既存のアプリケーションに変更を加えるときに、選択した Mule Runtime バージョンの最新の日付のパッチを選択する必要があります。
Mule Runtime Engine のバージョン 4.5 から、バージョンのピン留めに必要なタグを渡すことで、再デプロイ時に Mule アプリケーションの自動アップグレードを無効にできます。
猶予期間中は、前の日付のパッチバージョンが Runtime Manager UI で使用できなくなるまで、これらのバージョンを選択できます (その後も API 経由であれば使用できます)。この動作は、Edge および LTS チャネルリリースの Mule Runtime Engine バージョン 4.5 から変更されます。すべてのビルドタグは、Runtime Manager UI および API で利用できます。
本番環境でアプリケーションを更新する前に、Sandbox 環境で更新して、必要なテストを実施してください。
アプリケーションを最新の日付パッチに更新する手順は、次のとおりです。
Runtime Manager のナビゲーションメニューで [Applications (アプリケーション)] をクリックします。
[Deployment Target (デプロイメント対象)] の [Runtime version (ランタイムバージョン)] リストから、new
とタグ付けされたバージョンを選択します。
更新のバージョン番号がインストール済みバージョンと同じ場合があったとしても、日付が後であれば更新であることがわかります。
バージョンの詳細を確認するには、[Read release notes (リリースノートを読む)] リンクをクリックします。
[Apply Changes (変更を適用)] をクリックしてアプリケーションを更新します。
Runtime Fabric により、選択したバージョンでアプリケーションが更新され、成功または失敗を示すメッセージが表示されます。
アプリケーションを再デプロイします。
Runtime Fabric の 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.
Channel Type | Release Cadence | Recommended Customer Profile | Differentiators | Support Coverage |
---|---|---|---|---|
Edge |
Three times per year:
|
|
|
For versions 4.5 to 4.7:
For version 4.8 and later:
|
LTS |
Annual:
|
On-premises:
|
|
For version 4.6 and later:
|
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』. |
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.
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.
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. |
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.
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 経由でデプロイされた場合は、最新のビルドが自動的に選択されます。