1. Homepage
  2. Mule Runtime (4.2)
  3. オンプレミスでの Mule Runtime Engine の実行

  4. オンプレミスデプロイモデル

オンプレミスデプロイモデル

このバージョンの Mule は、拡張サポートが終了する 2023 年 5 月 2 日にその すべてのサポート​が終了しました。

このバージョンの Mule を使用する CloudHub には新しいアプリケーションをデプロイできなくなります。許可されるのはアプリケーションへのインプレース更新のみになります。

標準サポートが適用されている最新バージョンの Mule 4 にアップグレード​することをお勧めします。これにより、最新の修正とセキュリティ機能強化を備えたアプリケーションが実行されます。

Mule アプリケーションのデプロイメントには 2 つの大きな要素があります。

  • Mule Runtime Engine インスタンス

  • その Mule インスタンスにデプロイされる Mule アプリケーション

CloudHub や Anypoint Runtime Fabric にアプリケーションをデプロイする場合は、アプリケーションの実行に必要な Mule Runtime Engine インスタンスをこれらのサービスが管理します。

アプリケーションをオンプレミスでデプロイする場合は、Mule アプリケーションを実行する Mule Runtime Engine のインストールと設定はユーザーの責任となります。オンプレミスインスタンスは (CloudHub や Runtime Fabric デプロイメントとは異なり) ユーザーが完全に制御するため、オンプレミスデプロイに特有の特性について理解しておく必要があります。

1 つの Mule インスタンスでの複数のアプリケーションの実行

Mule Runtime Engine の 1 つのインスタンスで複数のアプリケーションを実行することができるため、異なるアプリケーションで競合したり、情報を共有したりせずに同じ名前空間を利用できます。これにより、次のような利点がもたらされます。

  • 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの Mule インスタンスにデプロイできます。

  • Mule アプリケーションで操作を実行するための境界をクリアできます。

  • Mule Runtime Engine は、Mule アプリケーションを監視して、設定の変更を自動的に読み込み直します。

  • アプリケーションは異なるライブラリバージョンに依存できます。

  • 複数のバージョンのアプリケーションを同じ Mule インスタンス内で実行できます。

アプリケーションのパッケージとデプロイメント

Mule Runtime Engine は、すべてのアプリケーションを実行時に展開し、元の ​.jar​ ファイルを ​/apps​ ディレクトリから削除し、アプリケーションごとに新しいフォルダーを作成して、各フォルダーにアプリケーションファイルと同じ名前 (から ​.jar​ 拡張子を削除したもの) を付けます。

デプロイメントが成功したかどうかは以下で確認してください。

  • コンソールに表示されるアプリケーションの状況が ​DEPLOYED​ である。

  • Mule インスタンスの ​/apps​ ディレクトリに展開されたアプリケーションフォルダー (例: stockTrader.jar​ であれば ​$MULE_HOME/apps/stockTrader​) が存在する。

  • 実行中のアプリケーション用のアンカーファイル (例: $MULE_HOME/apps/stockTrader-anchor.txt​) が存在する。

アプリケーションを別の場所に保存する場合、​$MULE_HOME/apps​ からアプリケーションディレクトリへのシンボリックリンクを作成して、Unix ベースのシステムに保存できます。

アプリケーションとドメインのデプロイメント

すべてのアプリケーションは​ドメイン​内で一緒にデプロイされます。. デフォルトでは、アプリケーションは ​default​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。

deploy+domain

複数のアプリケーションを同じ Mule インスタンスにデプロイしていて、アプリケーションが同じリソースを共有する必要がある場合は、共通の​ドメイン​を作成して複数のプロジェクトから参照できる設定を定義できます。この方法なら、競合を起こすことなく、同じ HTTP ホストおよびポートから異なるプロジェクトの異なるサービスを公開できます。

アプリケーションのホットデプロイメント

Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。

Mule は、​$MULE_HOME/apps​ ディレクトリ下の設定ファイルが更新されているかどうかを 3 秒ごとに確認し、更新された設定ファイルを見つけると、設定ファイルと JAR をそのアプリケーションの ​java​ ソースディレクトリに再読み込みします。

Mule を起動し、​mule.deploy.applications​ プロパティを使用してアプリケーションを指定する場合、ホットデプロイメントプロセスは、指定されたアプリケーションに対してのみ機能します。

アプリケーションを再読み込みするには、以下の操作を実行できます。

  • 該当のアプリケーションのアンカーファイルを ​touch​ します。

  • mule-artifact.json​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​touch​ または更新します。

たとえば、カスタムクラスの 1 つを変更する場合、そのカスタムクラスに変更を加え、更新したクラスを Java ディレクトリにコピーした後、アンカーファイルを ​touch​ します。

Mule インスタンスと管理ペイン間の通信

Mule インスタンスは管理ペインを使用して個別に実行され、インテグレーションロジックの実行や API 要求の提供を行います。このアーキテクチャにより、Mule Runtime Engine を戦略的にデプロイし、通信のボトルネックにならないようにすることができます。
Mule インスタンスが管理ペインから切断されるようなイベントが発生すると、設計どおりに実行が継続され、インテグレーションの実行や API の提供が中断することなく行われます。ただし、新しいまたは更新されたポリシーは、接続が再確立されるまで取り込まれず、更新されません。

関連情報