---
schema_version: "1"
id: bf2ecad057335cb5e68d0dc1af82b60f6a00f3f57e78fc2385ba7bf2c6f22ca3
title: オンプレミスデプロイモデル
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.7/mule-deployment-model.md
canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-deployment-model
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 45ffd4d063c5b531afe3a259f907308e169b62ccb0b8eadf57ecc9f8d83ff47e
description: MuleSoft Documentation Site
release: "4.7"
latest: false
---
# オンプレミスデプロイモデル

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

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

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

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

## [](#1-つの-mule-インスタンスでの複数のアプリケーションの実行)1 つの Mule インスタンスでの複数のアプリケーションの実行

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

- 複雑なアプリケーションをそれぞれが特有のロジックを持つ複数の Mule アプリケーションに分割して、これらの Mule アプリケーションを 1 つの 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`​ のドメインを参照し、追加の設定は必要ありません。コンソールでアプリケーションと一緒にドメインがデプロイされるのを確認できます。

![ドメインとデプロイ済みアプリケーションおよびその状況](/mulesoft/current/ja-jp/mule-runtime/4.7/_images/deploy-domain.png)

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

## [](#アプリケーションのホットデプロイメント)アプリケーションのホットデプロイメント

Mule アプリケーションの設定ファイルとカスタムクラスを変更した場合は、Mule を再起動せずにそれらを読み込み直すことができます。Mule アプリケーションの設定ファイルから変更を取得するには、システムプロパティ ​`mule.deployment.forceParseConfigXmls`​ が ​`true`​ に設定されている必要があります。Mule アプリケーションの設定ファイルを変更して強制的に再デプロイした場合、アプリケーションがパッケージ化された場合に行われる検証は実行されないことに注意してください。

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

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

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

- 該当のアプリケーションのアンカーファイルを ​`touch`​ します。
- `mule-artifact.json`​ ファイル内で宣言されている Mule 設定ファイルのいずれかを ​`touch`​ または更新します。

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

## [](#mule-インスタンスと管理ペイン間の通信)Mule インスタンスと管理ペイン間の通信

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

## [](#関連情報)関連情報

- [共有リソース](https://docs.mulesoft.com/jp/mule-runtime/4.7/shared-resources)
- [オンプレミスでの Mule Runtime Engine の実行](https://docs.mulesoft.com/jp/mule-runtime/4.7/mule-standalone)