1. 構成システム管理 (管理 Web アプリケーション)
ほとんどの商用 J2EE サーバーは強力な管理インターフェースを提供しており、ほとんどがわかりやすい Web アプリケーション インターフェースを使用しています。 Tomcat は、独自の方法で、商用競合他社に劣らない成熟した管理ツールも提供します。 Tomcat の Admin Web アプリケーションはバージョン 4.1 で初めて登場しました。当時のその機能には、コンテキスト、データ ソース、ユーザーおよびグループなどの管理が含まれていました。もちろん、初期化パラメータ、ユーザー、グループ、ロールなどのさまざまなデータベース管理も行うことができます。次のバージョンでは、これらの機能は大幅に拡張されますが、既存の機能はすでに非常に便利です。管理 Web アプリケーションは、自動展開ファイル CATALINA_BASE/webapps/admin.xml で定義されます。 (翻訳者注: CATALINA_BASE は、Tomcat インストール ディレクトリの下のサーバー ディレクトリです)
このファイルを編集して、Context の docBase パラメータが絶対パスであることを確認する必要があります。つまり、CATALINA
_BASE/webapps/admin.xml のパスは絶対パスになります。別のオプションとして、この自動デプロイメント ファイルを削除して、server.xml ファイルに管理 Web アプリケーション コンテキストを作成することもできます。結果は同じです。 Admin Web アプリケーションを管理することはできません。つまり、CATALINA_BASE/webapps/admin.xml を削除すること以外は何もできない可能性があります。
UserDatabaseRealm (デフォルト) を使用する場合は、CATALINA_BASE/conf/tomcat-users.xml ファイルにユーザーとロールを追加する必要があります。このファイルを編集し、次のようにファイルに「admin」という名前のロールを追加します。
ユーザーも必要で、このユーザーのロールは「admin」です。既存のユーザーと同様にユーザーを追加します (パスワードを変更して安全性を高めます):
役割="管理者"/>
これらの手順を完了したら、Tomcat を再起動し、 http://localhost:8080/adminにアクセスしてください。ログイン インターフェイスが表示されます。 Admin Web Applicationはコンテナ管理によるセキュリティ機構を採用し、Jakarta Strutsフレームワークを採用しています。 「admin」ロールを持つユーザーとして管理インターフェイスにログインすると、この管理インターフェイスを使用して Tomcat を設定できるようになります。
2. アプリケーション管理の構成 (マネージャー Web アプリケーション)
マネージャー Web アプリケーションを使用すると、管理 Web アプリケーションよりも単純なユーザー インターフェイスを通じて、いくつかの単純な Web アプリケーション タスクを実行できます。 Manager Web アプリケーションは、自動デプロイメント ファイル
?CATALINA_BASE/webapps/manager.xml
で定義されます。このファイルを編集して、コンテキストの docBase パラメータが絶対パス、つまり CATALINA_HOME/server/ の絶対パスであることを確認する必要があります。 webapps/マネージャー 。 (翻訳者注: CATALINA_HOME は tomcat のインストール ディレクトリです)
UserDatabaseRealm を使用している場合は、ロールとユーザーを CATALINA_BASE/conf/tomcat-users.xml ファイルに追加する必要があります。次に、ファイルを編集し、「manager」という名前のロールをファイルに追加します。
また、ロール「manager」を持つユーザーも必要です。既存のユーザーと同様に新しいユーザーを追加します (パスワードを変更して安全性を高めます):
role="manager"/>
次に、Tomcat を再起動し、 http://localhost/manager/listにアクセスすると、非常に単純なテキスト管理インターフェイスが表示されます。または、 http://localhost/manager/html/list にアクセスすると、次の内容が表示されます。 HMTL 管理インターフェイス。いずれにせよ、これは Manager Web アプリケーションが開始されたことを意味します。
Manager アプリケーションを使用すると、システム管理者権限がなくても、テスト用に新しい Web アプリケーションをインストールできます。 /home/user/hello に新しい Web アプリケーションがあり、アプリケーションをテストするために /hello にインストールしたい場合は、最初のファイル ボックスに「/hello」と入力します (パスとして)アクセスする場合)、2 番目のテキスト ボックスに「file:/home/user/hello」(構成 URL として) と入力します。
Manager アプリケーションを使用すると、Web アプリケーションを停止、再起動、削除、再デプロイすることもできます。アクセスできないようにアプリケーションを停止します。停止したアプリケーションにユーザーがアクセスしようとすると、「503 - このアプリケーションは現在利用できません」という 503 エラーが表示されます。
Web アプリケーションの削除は、単に Tomcat の実行コピーからアプリケーションを削除することを意味します。Tomcat を再起動すると、削除されたアプリケーションが再び表示されます (つまり、削除はハード ドライブから削除することを意味しません)。 3.
Web アプリケーションをデプロイする
システムに Web サービスをデプロイするには 2 つの方法があります。
1. WAR ファイルまたは Web アプリケーション フォルダー (Web のすべてのコンテンツを含む) を $CATALINA_BASE/webapps ディレクトリにコピーします。
2. コンテキスト コンテンツのみを含む Web サービスの XML フラグメント ファイルを作成し、そのファイルを $CATALINA_BASE/webapps ディレクトリに配置します。 Web アプリケーション自体はハード ドライブ上のどこにでも保存できます。
WAR ファイルがあり、それをデプロイする場合は、そのファイルを CATALINA_BASE/webapps ディレクトリにコピーするだけです。ファイルの拡張子は「.war」である必要があります。 Tomcat がこのファイルをリッスンすると、(デフォルトで) ファイルをサブディレクトリとして解凍し、そのサブディレクトリに WAR ファイルの名前を付けます。
次に、Tomcat は、server.xml ファイルで作成したのと同じように、メモリ内にコンテキストを作成します。もちろん、その他の必要なコンテンツは、server.xml の DefaultContext から取得されます。
Web アプリケーションをデプロイするもう 1 つの方法は、コンテキスト XML スニペット ファイルを作成し、そのファイルを CATALINA_BASE/webapps ディレクトリにコピーすることです。コンテキスト フラグメントは完全な XML ファイルではなく、コンテキスト要素とそれに対応するアプリケーションの説明にすぎません。
この種のフラグメント ファイルは、server.xml からコンテキスト要素を切り出したようなものであるため、この種のフラグメントは「コンテキスト フラグメント」と呼ばれます。
たとえば、アクセス制御メソッドとしてレルムを使用する MyWebApp.war という名前のアプリケーションをデプロイする場合は、次のフラグメントを使用できます。
<コンテキストパス="/demo"
docBase="webapps/MyWebApp.war"
debug="0" 特権="true">
<レルムクラス名=
「org.apache.catalina.realm.UserDatabaseRealm」
resourceName="ユーザーデータベース"/>
フラグメントに「MyWebApp.xml」という名前を付け、CATALINA_BASE/webapps ディレクトリにコピーします。
このコンテキスト フラグメントは、Web アプリケーションをデプロイするための便利な方法を提供します。デフォルトのデプロイメント特性を変更しない限り、新しい Web アプリケーションをインストールするときに Tomcat を再起動する必要はありません。
4. 仮想ホストの設定（Virtual Host）
server.xmlの「Host」要素については、仮想ホストを設定する場合のみ変更する必要があります。仮想ホスティングは、Web サーバー上で複数のドメイン名を提供するメカニズムであり、各ドメイン名に対してホスト全体が排他的であるように見えます。実際、ほとんどの中小企業 Web サイトは仮想ホストを使用して実装されています。これは主に、仮想ホストがインターネットに直接接続し、適切なアクセス応答速度を確保するために対応する帯域幅を提供できるためです。また、仮想ホストは安定した固定速度も提供できます。 IP。
名前ベースの仮想ホストは、ドメイン ネーム サーバー (DNS) 上に IP アドレスのエイリアスを作成し、異なるドメイン名に対する要求を対応する Web ディレクトリに分散するように Web サーバーに指示することで、任意の Web サーバー上に確立できます。この記事は主に Tomcat に関するものであるため、さまざまなオペレーティング システムで DNS を設定する方法については紹介しません。この点に関してヘルプが必要な場合は、Paul Albitz と Cricket が執筆した書籍『DNS and Bind』を参照してください。リュー（オライリー）。デモンストレーションのために、エイリアスをテストする最も簡単な方法である静的ホスト ファイルを使用します。
Tomcat で仮想ホストを使用するには、DNS またはホスト データを設定する必要があります。
テストするには、ローカル IP の IP エイリアスを設定するだけで十分です。次に、のように、server.xml に数行を追加する必要があります。 /エンジン>
シャットダウン="SHUTDOWN" デバッグ="0">
<サービス名="Tomcat-Standalone">
<コネクタクラス名=
「org.apache.coyote.tomcat4.CoyoteConnector」
ポート="8080"
minProcessors="5" maxProcessors="75"
EnableLookups="true"
redirectPort="8443"/>
<コネクタクラス名=
「org.apache.coyote.tomcat4.CoyoteConnector」
port="8443" minProcessors="5"
maxProcessors = "75"
acceptCount="10" デバッグ="0"
スキーム="https" secure="true"/>
<エンジン名="スタンドアロン"
デフォルトホスト = "ローカルホスト" デバッグ = "0">
<ホスト名="ローカルホスト"
debug="0" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<コンテキストパス="" docBase="ROOT" デバッグ="0"/>
<コンテキストパス="/orders"
docBase="/home/ian/orders" デバッグ="0"
reloadable="true"crossContext="true">
<ホスト名=" www.example.com "
appBase="/home/example/webapp">
<コンテキストパス="" docBase="."/>
<
Tomcat のserver.xml ファイルには、初期状態では仮想ホストが 1 つだけ含まれていますが、複数の仮想ホストをサポートするように簡単に拡張できます。前の例は、server.xml の単純なバージョンを示しています。太字の部分は仮想ホストを追加するために使用されます。各 Host 要素には 1 つ以上のコンテキスト要素が含まれている必要があり、含まれるコンテキスト要素の 1 つがデフォルト コンテキストである必要があります (たとえば、path="")。