2026.11.03 Java

Tomcatのインストール手順｜Ubuntuのtar.gz＋systemd・Windowsサービス・Docker公式イメージと初期設定の堅牢化【11.0.27】

Q: Tomcatが正しくインストールできたかはどう確認しますか？

systemdで動かしているなら systemctl status tomcat で稼働を見て、 curl -I http://localhost:8080/ で応答を確かめます。この記事の手順のように webapps が空なら、404が返るのが正常です。版は bin/version.sh で表示できます。Windowsなら sc query Tomcat11 でサービスの状態を確認できます。

Q: Tomcatのポート番号8080を変更するにはどうしますか？

conf/server.xml の Connector 要素の port を書き換えて再起動します。80番や443番で受けたい場合、Linuxでは1024番未満のポートを使うのに特権が必要です。Tomcatをrootで動かして済ませず、前段にnginxやApache HTTP Serverを置いて80・443番で受け、Tomcatへ転送する構成にしてください。

Q: apt install tomcatと公式サイトの配布物はどちらを選ぶべきですか？

本番は公式の配布物を選びます。Ubuntu 24.04のaptで入るのは tomcat10 パッケージの10.1.16系で、11.0系はありません。aptはOSの更新とまとめて管理できる利点がある一方、版上げの時期はディストリビューションが決めます。検証用の短命な環境で、版を問わず動けばよい場合にだけaptを使います。

Q: インストールしたTomcatを新しい版に上げるにはどうしますか？

この記事の配置なら、新しい版のtar.gzを照合してから /opt/tomcat に展開し、 current のシンボリックリンクを付け替えて systemctl restart tomcat を実行します。設定は CATALINA_BASE にあるので移し替えは要りません。Dockerなら FROM のタグを書き換えて再ビルドします。上げるべきかの判断は、版を確かめてから脆弱性情報の影響範囲と照合して決めます。

Tomcatのインストール手順｜Ubuntuのtar.gz＋systemd・Windowsサービス・Docker公式イメージと初期設定の堅牢化【11.0.27】

Tomcatのインストールは、公式サイトから配布物を取得して展開すれば終わる、と説明されることが多い作業です。ただ、本番のサーバーに入れるなら、その先の決めごとのほうが手間を食います。どのユーザーで動かすか、OS起動時にどう立ち上げるか、版上げのたびに設定を移し替えずに済む置き方はどれか、入れた直後に開いたままの入口をどう閉じるか、です。この記事では、2026年11月3日時点の最新版11.0.27を例に、Ubuntuに公式のtar.gzを入れてsystemdで動かす手順、Windowsサービスとして登録する手順、Docker公式イメージで動かす手順の3経路を、公式ドキュメントとソースの記載に沿って整理します。

まとめ｜本番は公式tar.gzをsystemdで動かし入口を3つ閉じてから公開する

Linuxのサーバーに入れるなら、公式のtar.gzをSHA-512で照合してから展開し、本体（CATALINA_HOME）と設定・ログ・アプリ（CATALINA_BASE）を別のディレクトリに分けます。起動はsystemdに任せ、専用ユーザーでcatalina.sh runを動かす形が扱いやすい構成です。

Ubuntu・RHEL系のサーバー：公式tar.gz＋systemd。版上げはシンボリックリンクの付け替えで済む
Windowsサーバー：公式インストーラーかzip版のservice.batでサービス登録し、専用の実行アカウントに切り替える
コンテナ基盤：Docker公式イメージを、パッチ番号まで固定したタグで使う

どの経路でも、公開前に閉じる入口は同じです。シャットダウンポート、Manager、初期同梱のWebアプリの3つを閉じてから外へ出すのが、この記事の結論です。

インストール前に決める系列・Javaの版・導入経路と各経路の向き不向き

Tomcat 11.0・10.1・9.0の系列と必要なJavaの版の対応

最初に系列を決めます。公式の系列表では、11.0系はJava 17以降、10.1系はJava 11以降、9.0系はJava 8以降が必要です。新しく作るアプリなら11.0系を選びます。9.0系はjavax.*のパッケージ名で書かれた古いアプリを動かすための系列で、サポートの期限が決まっています。系列ごとの期限はTomcatのバージョン一覧とサポート期限で確認してください。

Javaは実行環境（JRE）があれば動きます。RUNNING.txtも、まずJava SEの実行環境を入れる手順から始まっています。開発機で複数のJavaを切り替えたい場合は、SDKMAN!でJavaを入れる方法が手軽です。サーバーではOSのパッケージで入れたほうが、セキュリティ更新をOSの更新とまとめて当てられます。

公式tar.gz・aptパッケージ・Windowsインストーラー・Dockerの比較

入れ方は4つあります。公式のダウンロードページには、tar.gz、zip、Windows用zip、Windowsサービス用インストーラーが並んでいます。

経路	入る版	版上げの主導権	向く環境
公式tar.gz	11.0.27	自分	Linuxの本番
Ubuntu 24.04のapt	10.1.16系	Ubuntu	検証用の短命な環境
Windowsインストーラー	11.0.27	自分	Windowsサーバー
Docker公式イメージ	11.0.27	イメージの更新	コンテナ基盤

aptの版はUbuntu 24.04のパッケージ情報で2026年11月3日時点の値です。Ubuntu 24.04では11.0系はパッケージになっておらず、10.1系もApacheの最新版（10.1.61）とは番号が離れています。ディストリビューションは番号を据え置いて修正だけを取り込むことがあるため、番号だけで未修正とは言い切れません。ただ、Apacheの脆弱性公表に合わせて自分の判断で版を上げられない点は変わりません。

UbuntuにTomcat 11をtar.gzで入れてsystemdで自動起動する手順

UbuntuでのJava 21の導入とログインできない専用ユーザーの作成

公式のセキュリティ設定ガイドは、Tomcatをrootで動かさず、リモートからログインできない専用ユーザーを作るよう求めています。Javaはopenjdk-21-jre-headlessを入れます。

# Javaの実行環境を入れる（画面を持たないサーバー向けのheadless版）
sudo apt update
sudo apt install -y openjdk-21-jre-headless
java -version

# ログインシェルを持たないシステムユーザーを作る
sudo useradd -r -M -d /opt/tomcat -s /usr/sbin/nologin tomcat

amd64のマシンでは、Javaは/usr/lib/jvm/java-21-openjdk-amd64に入ります。arm64では末尾が変わるので、ls /usr/lib/jvmで実際の名前を確かめてから後の設定に書いてください。

公式配布物のSHA-512照合と本体・設定を分けて展開する配置

ダウンロードページの記載では、取得したファイルの検証は必須（must）です。.sha512ファイルには「ハッシュ値 *ファイル名」の形で値が入っているので、sha512sum -cでそのまま照合できます。署名まで確かめるならKEYSを取り込み、ASFの検証手順に沿って.ascを照合します。

VER=11.0.27
cd /tmp
curl -fLO https://dlcdn.apache.org/tomcat/tomcat-11/v$VER/bin/apache-tomcat-$VER.tar.gz
curl -fLO https://downloads.apache.org/tomcat/tomcat-11/v$VER/bin/apache-tomcat-$VER.tar.gz.sha512
sha512sum -c apache-tomcat-$VER.tar.gz.sha512   # 「OK」と出なければ展開しない

# 本体（CATALINA_HOME）を版番号つきで置き、current というリンクを張る
sudo mkdir -p /opt/tomcat
sudo tar -xzf apache-tomcat-$VER.tar.gz -C /opt/tomcat
sudo ln -sfn /opt/tomcat/apache-tomcat-$VER /opt/tomcat/current

# 設定・ログ・アプリの置き場（CATALINA_BASE）を別に作り、conf だけ写す
sudo mkdir -p /opt/tomcat/base/webapps /opt/tomcat/base/logs /opt/tomcat/base/temp /opt/tomcat/base/work
sudo cp -r /opt/tomcat/current/conf /opt/tomcat/base/

# 本体と設定は root 所有・tomcat グループは読むだけ。書き込む場所だけ tomcat 所有にする
sudo chown -R root:tomcat /opt/tomcat/apache-tomcat-$VER /opt/tomcat/base
sudo chmod -R g+rX,g-w,o-rwx /opt/tomcat/apache-tomcat-$VER /opt/tomcat/base
sudo chown -R tomcat:tomcat /opt/tomcat/base/logs /opt/tomcat/base/temp /opt/tomcat/base/work /opt/tomcat/base/webapps

dlcdn.apache.orgには最新版しか置かれません。前の版が要るときはアーカイブから取ります。所有権の付け方は、セキュリティ設定ガイドが紹介するASF自身の構成（本体はroot所有でグループは読み取りのみ、logs・temp・workだけTomcatのユーザー所有）に合わせました。ASFは自動配備を止めているためwebappsもroot所有ですが、WARを置いて展開させる運用なら上のようにwebappsをtomcat所有にします。CATALINA_BASEのwebappsが空のまま始まる点は、後の章で効いてきます。

Type=execとcatalina.sh runで書くsystemdユニットの設定例

多くの手順記事はType=forkingでstartup.shを呼ぶユニットを書きます。しかしsystemd.serviceのマニュアルはforkingの使用については非推奨という立場です。catalina.shのrunはexecでJavaを前面のまま起動するので、Type=execと組み合わせればJavaのプロセスをsystemdが直接見張れます。

# /etc/systemd/system/tomcat.service
[Unit]
Description=Apache Tomcat 11
After=network.target

[Service]
Type=exec
User=tomcat
Group=tomcat
Environment=JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64
Environment=CATALINA_HOME=/opt/tomcat/current
Environment=CATALINA_BASE=/opt/tomcat/base
Environment="CATALINA_OPTS=-Xms512m -Xmx1g"
ExecStart=/opt/tomcat/current/bin/catalina.sh run
# SIGTERMで止めたJavaは終了コード143を返すため、正常終了として扱う
SuccessExitStatus=143
Restart=on-failure

[Install]
WantedBy=multi-user.target

停止はsystemdが送るSIGTERMで行い、shutdown.shは使いません。これが、後の章でシャットダウンポートを閉じられる理由です。catalina.shは既定でumaskを0027に設定するので、ユニット側で指定し直す必要はありません。メモリの指定をCATALINA_OPTSに書くのはRUNNING.txtの推奨どおりで、ヒープの大きさの決め方はJVMのメモリ構成を参照してください。

Tomcatの起動確認で404が返る理由と版上げ時のリンク付け替え

sudo systemctl daemon-reload
sudo systemctl enable --now tomcat
systemctl status tomcat
journalctl -u tomcat -n 50 --no-pager   # run で動かすと起動ログはジャーナルに出る

# 応答の確認。webapps が空なので 404 が返れば正常
curl -I http://localhost:8080/

# 版の確認
sudo -u tomcat env CATALINA_BASE=/opt/tomcat/base /opt/tomcat/current/bin/version.sh

猫のロゴの初期画面は出ません。CATALINA_BASEのwebappsが空なので、404が返れば正しく動いています。ログの読み方と版の確かめ方はTomcatのバージョン確認方法で詳しく扱っています。

版上げは、新しい版を同じ手順で/opt/tomcatに展開し、currentのリンクを付け替えて再起動するだけです。設定はCATALINA_BASE側にあるので、confを写し直す必要はありません。戻すときもリンクを前の版に向け直せば済みます。ただし、新しい版のconfに設定項目の追加があれば、差分を見て手で取り込んでください。

WindowsにTomcat 11をサービスとして入れる手順と実行アカウントの変更

Windows公式インストーラーの選択項目とJava 17以降の自動検出

公式のセットアップ説明によると、Windowsインストーラーで入れたTomcatは、選択に関係なく必ずWindowsサービスとして登録されます。コンポーネント画面のチェックは、Windows起動時に自動で立ち上げる（auto）かどうかの切り替えです。Javaは、レジストリからJava 17以降の実行環境を探し、見つからなければJAVA_HOMEを使います。

インストーラーは管理画面の利用者も作れますが、使う予定が無ければ空欄のまま進めてください。/S（画面なし）・/D=（インストール先）・/C=（設定ファイル）を組み合わせれば、複数台へ同じ設定で無人インストールできます。設定ファイルに書ける項目名（TomcatPortHttpやTomcatServiceNameなど）は同じページに一覧があります。

zip版をservice.batで登録しLocalServiceで動かす手順

インストーラーを使わず、Windows用zipを展開して登録する方法もあります。Windowsサービスの説明ではservice.batが最も安全な登録方法とされ、既定のサービス名はTomcat11です。

rem 管理者のコマンドプロンプトで実行する（パスは環境に合わせて読み替える）
certutil -hashfile apache-tomcat-11.0.27-windows-x64.zip SHA512
rem 表示された値を .sha512 ファイルの値と見比べてから展開する

set "JAVA_HOME=C:\Java\jdk-21"
cd C:\tomcat\apache-tomcat-11.0.27\bin
service.bat install

rem 自動起動にし、権限の小さい組み込みアカウントで動かす
tomcat11 //US//Tomcat11 --Startup=auto --ServiceUser="NT Authority\LocalService"

rem LocalService が書き込む logs・temp・work に変更権限を与える
icacls C:\tomcat\apache-tomcat-11.0.27\logs /grant "NT AUTHORITY\LocalService:(OI)(CI)M"
icacls C:\tomcat\apache-tomcat-11.0.27\temp /grant "NT AUTHORITY\LocalService:(OI)(CI)M"
icacls C:\tomcat\apache-tomcat-11.0.27\work /grant "NT AUTHORITY\LocalService:(OI)(CI)M"
net start Tomcat11

セットアップ説明は、サービスを権限を絞った別ユーザーで動かすよう勧めています。登録後はsc qc Tomcat11で実行アカウントを確かめ、上のように--ServiceUserで権限の小さいアカウントを指定してください。Javaのヒープなどはtomcat11w.exeの画面か、//USに--JvmMxなどを付けて変えます。

Docker公式イメージでTomcatを動かす手順とタグ固定・root実行の注意点

Dockerfileで自分のWARだけを載せたイメージを作る手順

公式イメージのDockerfileは、CATALINA_HOMEを/usr/local/tomcatに置き、同梱のWebアプリをwebapps.distへ退避してwebappsを空にしています。起動コマンドはcatalina.sh runで、前の章のsystemdと同じ考え方です。動作だけを確かめたい場合は、親記事のTomcatとはにサーブレットを1本動かす手順があります。

# Dockerfile
FROM tomcat:11.0.27-jre21-temurin-noble

# 公式イメージは USER の指定が無く root で動くので、専用ユーザーを作って切り替える
RUN useradd -r -M -s /usr/sbin/nologin tomcat \
 && chown -R tomcat:tomcat /usr/local/tomcat/logs /usr/local/tomcat/temp /usr/local/tomcat/work /usr/local/tomcat/webapps
USER tomcat

# 自分のアプリだけを置く（webapps.dist は戻さない）
COPY --chown=tomcat:tomcat target/app.war /usr/local/tomcat/webapps/ROOT.war

docker build -t myapp:1.0 .
docker run -d --name myapp -p 8080:8080 myapp:1.0
docker exec myapp version.sh

Dockerのlatestや11.0の浮動タグを本番で使わない理由

公式イメージのタグ一覧では、2026年11月3日時点でlatestと11.0はJava 25のjdk25-temurin-resoluteを指しています。tomcat:11.0と書いていると、ある日の再ビルドでJavaの版とベースOSまで変わります。本番は11.0.27-jre21-temurin-nobleのようにTomcat・Java・OSを全部固定したタグか、ダイジェストで指定してください。

固定すると、修正版が出ても自動では上がりません。脆弱性の公表を受けてタグを書き換え、再ビルドする手順を決めておきます。CVEごとの影響範囲はApache Tomcatの脆弱性一覧で確認できます。

インストール直後に閉じる設定｜シャットダウンポート・Manager・同梱アプリ

シャットダウンポート8005を-1にして停止をsystemdに任せる設定

既定のserver.xmlは、8005番で「SHUTDOWN」という文字列を受け取るとTomcatを止める設定になっています。セキュリティ設定ガイドは、portを-1にすればこの入口が無効になり、無効にしないなら推測されにくい文字列にすべきだとしています。属性の意味を確認する際の参照先はServer要素のリファレンスです。

<!-- /opt/tomcat/base/conf/server.xml -->
<Server port="-1" shutdown="SHUTDOWN">
  <!-- root での起動と緩い umask を拒否するリスナー（既定はコメントアウト） -->
  <Listener className="org.apache.catalina.security.SecurityListener" />
  ...
  <!-- 前段に nginx などを置くなら、自ホストからの接続だけを受ける -->
  <Connector port="8080" protocol="HTTP/1.1" address="127.0.0.1"
             connectionTimeout="20000" redirectPort="8443" />

ポートを閉じるとshutdown.shは使えなくなります。前の章のsystemdユニットはSIGTERMで止めるので影響を受けません。startup.shとshutdown.shで運用している環境でいきなり-1にすると、止められなくなります。先に停止方法を切り替えてください。

リスナーのリファレンスによると、SecurityListenerは既定で無効で、有効にするとrootでの起動と0007より緩いumaskを拒否します。addressはHTTPコネクタのリファレンスの属性で、既定ではすべてのアドレスで待ち受けます。前段の構成はnginxの更新手順もあわせて参照してください。

Tomcat同梱アプリの削除とManagerを使う場合の接続元制限

セキュリティ設定ガイドは、使わない同梱アプリを消すよう求めています。examplesは機微な環境から必ず削除し、ROOTとdocsは版番号を表示するので公開環境から外す、という扱いです。この記事の手順でCATALINA_BASEを分けた場合、webappsは空なので、そもそも配備されていません。CATALINA_HOMEをそのまま使う構成では、webappsの中身を自分のアプリ以外は消してください。

Managerは、利用者を登録しない限り使えない状態で配布されています。使うなら、Managerのcontext.xmlにあるRemoteCIDRValveが自ホスト（127.0.0.0/8と::1/128）からの接続に限っているので、許可範囲は特定のIPだけに広げます。Managerを全アドレスに開ける構成は採用しない方針です。リモート配備ができるため、弱いパスワードを狙う攻撃の標的になりやすいとガイドにも書かれています。エラーページから版番号を消す設定は版確認の記事のValveの章にまとめました。

tar.gz・apt・Dockerのどれで入れるかを決める判断基準と見送る場面

サーバー環境と運用体制からTomcatの導入経路を選ぶための条件

Linuxの仮想マシンや物理サーバーで長く動かすなら、公式tar.gz＋systemdを選びます。Apacheの修正版の公表から自分の判断で当てられ、版上げと切り戻しがリンクの付け替えで済むためです。コンテナの実行基盤があり、イメージの再ビルドとデプロイが自動化されているなら、Docker公式イメージを固定タグで使います。Windowsサーバーで既存の監視やバックアップの仕組みに乗せたい場合だけ、Windowsサービスを選びます。

これから作るSpring Bootのアプリなら、Tomcatを別に入れる必要はありません。実行可能jarに組み込まれたTomcatが動きます。組み込み版の版上げと設定はSpring Bootの組み込みTomcatで扱っています。

aptやlatestタグでの導入を見送る場面と保守を外へ任せる判断

次の場面では、手軽な入れ方を見送ります。11.0系が必要なのにUbuntu 24.04のaptで入れようとしている場合は、10.1系しか入らないので、導入する配布物は公式tar.gzです。脆弱性の公表から数日以内に修正版を当てる社内基準がある場合も、aptは更新の時期をUbuntuに委ねることになるので見送ります。Dockerでlatestや11.0のタグを本番に使うのも、Javaの版まで黙って変わるため避けます。

Tomcatが1〜2台で、構成を担当者が把握しているなら、この記事の手順を手作業で回せば足ります。一方、古い9.0系や8.5系のTomcatが複数台に散らばり、誰が入れたか分からない状態なら、入れ直しの前に、まず着手すべき作業は既存環境の棚卸しです。既存のTomcat環境の現状調査から版上げ後の回帰テストまでを外部に任せたい場合は、保守運用・内製化支援で相談を受けています。

よくある質問

Tomcatのインストールについて、検索の多い質問に答えます。

TomcatのインストールにはJDKとJREのどちらが必要ですか？

動かすだけならJREで足ります。RUNNING.txtもJava SEの実行環境を入れる手順から始まっています。版の条件は系列ごとに違い、11.0系はJava 17以降、10.1系はJava 11以降、9.0系はJava 8以降です。サーバー上でソースをコンパイルするならJDKが必要になります。Ubuntuならopenjdk-21-jre-headless、Docker公式イメージならjre21を含むタグを選びます。

Tomcatが正しくインストールできたかはどう確認しますか？

systemdで動かしているならsystemctl status tomcatで稼働を見て、curl -I http://localhost:8080/で応答を確かめます。この記事の手順のようにwebappsが空なら、404が返るのが正常です。版はbin/version.shで表示できます。Windowsならsc query Tomcat11でサービスの状態を確認できます。

Tomcatのポート番号8080を変更するにはどうしますか？

conf/server.xmlのConnector要素のportを書き換えて再起動します。80番や443番で受けたい場合、Linuxでは1024番未満のポートを使うのに特権が必要です。Tomcatをrootで動かして済ませず、前段にnginxやApache HTTP Serverを置いて80・443番で受け、Tomcatへ転送する構成にしてください。

apt install tomcatと公式サイトの配布物はどちらを選ぶべきですか？

本番は公式の配布物を選びます。Ubuntu 24.04のaptで入るのはtomcat10パッケージの10.1.16系で、11.0系はありません。aptはOSの更新とまとめて管理できる利点がある一方、版上げの時期はディストリビューションが決めます。検証用の短命な環境で、版を問わず動けばよい場合にだけaptを使います。

インストールしたTomcatを新しい版に上げるにはどうしますか？

この記事の配置なら、新しい版のtar.gzを照合してから/opt/tomcatに展開し、currentのシンボリックリンクを付け替えてsystemctl restart tomcatを実行します。設定はCATALINA_BASEにあるので移し替えは要りません。DockerならFROMのタグを書き換えて再ビルドします。上げるべきかの判断は、版を確かめてから脆弱性情報の影響範囲と照合して決めます。