CloudHub 2.0 オペレーティングシステムのパッチ更新
CloudHub 2.0 はサービスとしてのインテグレーションプラットフォーム (iPaaS) であり、オペレーティングシステムのパッチ設定を自動で管理するため、ユーザーはアプリケーションの開発と更新に集中できます。
CloudHub 2.0 によって必要に応じてセキュリティパッチが適用されるため、アプリケーションが保護されます。
パッチ更新では、ローリング更新デプロイメントモデルを使用するアプリケーションに青/緑デプロイメントを使用し、それをサポートするアプリケーションのダウンタイムをゼロにしています。
CloudHub 2.0 では、MuleSoft が管理する 2 つのデプロイメントプラットフォームに継続的な更新を適用します。
-
US クラウド
-
EU クラウド
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 分以上かかる場合があります。実行中のアプリケーションに対するアップグレードプロセスの影響は、前のセクションに記されている自動パッチ適用の動作と同じです。
| このアップグレードは元に戻すことができます。必ずアップグレードの影響を理解してから、本番環境で適用する前に組織のニーズに基づいてアップグレードをトリガーするタイミングを選択してください。 |
Runtime Manager を使用してオプトインアップグレードを適用する
-
Anypoint Platform から、[Runtime Manager] > [Private Spaces (非公開スペース)] を選択します。
非公開スペースでアップグレードが可能になったら、ツールチップが [Infra Status (インフラ状況)] 列の下に表示されます。
-
[Upgrade available (使用可能なアップグレード)] をクリックします。
-
チェックボックスをオンにして、早期のアップグレードに同意することを確定します。
-
[Upgrade (アップグレード)] をクリックします。
アップグレードを適用したら、[Infra Status (インフラ状況)] 列の下で状況を確認できます。
API を使用した自己トリガーアップグレードの適用
非公開スペースのアップグレード API を使用して非公開スペースをアップグレードできます。
使用可能なアップグレードの確認
非公開スペースに使用可能なアップグレードがあるかどうかを確認するには、既存の PrivateSpaces API に追加された isSpaceUpgradeAvailable 項目を使用します。次の例は、API 要求と応答を示しています。
要求:
GET
https:/anypoint.mulesoft.com/runtimefabric/api/organizations/{organizationId}/privatespaces/{privatespaceId}応答:
{
"id": "69f1b6f6-2bd9-4ceb-a145-a75f11a5eaee",
"name": "mySpace",
"status": "Active",
// EXTRA NON-RELEVANT FIELDS
"isSpaceUpgradeAvailable": true
}非公開スペースへのアップグレードの適用
新しいバージョンが使用可能になったら、非公開スペースのアップグレード API を使用して非公開スペースを使用可能な最新バージョンにアップグレードできます。次の例は、API 要求と応答を示しています。
要求:
PATCH
https:/anypoint.mulesoft.com/runtimefabric/api/organizations/{organizationId}/privatespaces/{privateSpaceId}/upgrade?optIn=true応答:
{
"id": "69f1b6f6-2bd9-4ceb-a145-a75f11a5eaee",
"name": "mySpace",
"status": "Active",
// EXTRA NON-RELEVANT FIELDS
"isSpaceUpgradeAvailable": false
}
この要求には、optIn パラメーターが含まれている必要があります。optIn パラメーターが渡されないか、false 値で渡された場合、API によって 400 Bad Request エラーが返されます。
|
アップグレード状況の確認
アップグレードをトリガーしたら、現在のアップグレードの状況のサブ項目が含まれている非公開スペース API の応答の globalSpaceStatus 項目を使用して状況を確認できます。
要求:
GET
https:/anypoint.mulesoft.com/runtimefabric/api/organizations/{organizationId}/privatespaces/{privatespaceId}応答:
{
"id": "69f1b6f6-2bd9-4ceb-a145-a75f11a5eaee",
"name": "mySpace",
"status": "Active",
// EXTRA NON-RELEVANT FIELDS
"globalSpaceStatus": {
"space": {
"status": "Active"
},
"cluster": [
{
"name": "jferaPreviousAP11-ap-southeast-2-eabb4",
"infra": {
"status": "InfrastructureProvisionSuccess",
"lastSeenTimeStamp": 1695756774114
},
"fabric": {
"status": "Active",
"lastSeenTimeStamp": 1695763243212
},
"ingress": {
"status": "INGRESS_APPLIED",
"lastSeenTimeStamp": 1695760545873
}
}
],
"network": {
"status": "InfrastructureProvisionSuccess",
"lastSeenTimeStamp": 1695756773862
},
"upgrade": {
"status": "In Progress"
}
},
"isSpaceUpgradeAvailable": false
}可能な状況種別
| 状況 | 説明 |
|---|---|
Active (アクティブ) |
非公開スペースでは現在インフラストラクチャのアップグレードまたは設定の更新が行われておらず、正常に動作しています。 |
In Progress (進行中) |
非公開スペースは現在、自己トリガーされたか、月 1 回のインフラストラクチャアップグレードの一環として、ユーザー設定の更新、またはインフラストラクチャのアップグレードに関連している可能性があるインフラストラクチャの変更が行われています。 |
Failed (失敗) |
非公開スペースでは、自己トリガーされたか、月 1 回のインフラストラクチャアップグレードの一環として、ユーザー設定の更新、またはインフラストラクチャのアップグレードに関連している可能性がある障害が発生しました。 |
Degraded (低下) |
非公開スペースは接続解除された状態にあり、使用する準備ができていません。 |
月 1 回の日付パッチ更新
各月の最初の 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 となります。
更新スケジュール
-
月の第 1 週に MuleSoft によって日付パッチがリリースされます。
-
月の第 3 週に MuleSoft によってその月の第 1 週にリリースされた日付パッチが自動的に適用されます。
-
本番以外の環境のアプリケーションは週内に更新されます。
-
本番環境のアプリケーションは週末に更新されます。
-
自動更新が行われた場合、アプリケーションの監査ログにはユーザー Anypoint Staff によるエントリが追加され、更新が行われた日時と更新に成功したかどうかが示されます。 更新に成功した場合、アクションは必要ありません。アプリケーションでダウンタイムなしの更新がサポートされないか、手動での更新が必要な場合、月の第 1 週にリリースされた日付パッチを第 1 週または第 2 週に手動で適用できます。手動でのランタイムバージョンの更新を参照してください。
手動でのランタイムバージョンの更新
-
Anypoint Platform にログインします。
-
Runtime Manager に移動します。
-
Runtime Manager のナビゲーションメニューで [Applications (アプリケーション)] をクリックします。
-
更新するアプリケーションを選択します。
-
[Settings (設定)] の [Deployment Target (デプロイメント対象)] タブで、[Runtime Version (ランタイムバージョン)] ドロップダウンをクリックします。
-
バージョンの最新ビルドを選択します。
-
[Deploy (デプロイ)] をクリックします。
アプリケーションが新しいランタイムバージョンで再デプロイされます。