TomcatをDockerで起動するなら、docker run -it --rm -p 8080:8080 tomcat:11-jdk21 の1行で十分です。数分でWebサーバーが立ち上がります。
ここでは、(1) docker runでの即起動、(2) DockerfileとDocker ComposeでのWARデプロイ、(3) 404・ポート接続のつまずき対処を順に解説します。使うのは、Tomcat公式イメージ（Tomcat 11/10.1、JDK 21/25）です。
コマンドをコピペしながら進めれば、初心者でもTomcatが動く環境を手に入れられます。
TomcatをDockerで起動するとは、Javaの代表的なWebアプリケーションサーバーであるApache Tomcatを、公式Dockerイメージを使ってコンテナとして動かすことです。
この記事でわかること
- docker runでTomcatを即起動する手順
- DockerfileとDocker ComposeでのWARファイルデプロイ方法
- 404表示・ポート接続のつまずきへの対処法
PARTS LIST ／目次
TomcatをDocker化するメリットとは
ローカル環境を汚さずに開発を進めると、OSの再インストールのようなやり直し作業を避けられます。
Dockerを使う最大の理由は、OSから独立した「隔離空間」でTomcatを動かせる点にあります。具体的なメリットは次の3つです。
- バージョンの共存：古いプロジェクトで必要なJava 8と、最新LTSのJava 25を共存させるような運用も、コンテナを分けるだけで解決します
- PC環境のクリーンさ：物理的なPCの環境は常にクリーンなまま、必要なときだけ必要なバージョンのサーバーを呼び出せます
- 誰かが作ったDockerfileを共有すれば、新しく入ったメンバーも数秒で全く同じ環境を再現できます
この機動性こそが、現代の開発スタイルにおいて欠かせない要素です。「手順書通りにやったのに動かない」という、あの不毛なチャットのやり取りを消し去れます。合理性とメンテナンス性を追求するなら、もはやDockerを使わない選択肢はありません。
ローカルに直接Tomcatを入れると起きがちな問題
ローカルに直接Tomcatを入れると、アンインストールが面倒だという問題に直面します。
インストーラーやZIP解凍で配置したファイルは、レジストリや隠しフォルダに設定を残していくことがよくあります。
また、Javaのバージョン競合はプログラミング初心者が最初にぶつかる大きな壁です。
Tomcatの特定のバージョンが特定のJavaにしか対応していない場合、OS全体のJavaを書き換える必要が出てきます。
この書き換えを繰り返すと、OSの環境変数が「秘伝のタレ」のように複雑化し、最終的にOSの再インストールが必要になることさえあります。
DockerでTomcatを動かすと何が楽になるのか
Dockerを使えば、コマンド一つでTomcat環境を丸ごと捨てられるのが最高に気持ちいいです。
実験的に設定をいじくり回して壊してしまっても、コンテナを削除して作り直せば、1秒で初期状態に戻ります。
この「失敗してもすぐにやり直せる」という安心感は、学習効率を飛躍的に高めてくれます。
さらに、本番環境もDockerであれば、自分のPCで動いたものがサーバーでも確実に動くという保証が得られます。
環境の差異に怯えながらデプロイ作業をするストレスから、永遠に解放されます。
DockerでTomcatを動かす仕組み
DockerでTomcatを動かす仕組みは、よく「引越し用のコンテナ」に例えられます。
Tomcatという家具が入った箱を、自分のPCという土地の上にポンと置くようなイメージです。
このとき、箱の中の家具（Tomcat）に外からアクセスするためには、箱の壁に「穴（ポート）」を開ける必要があります。
全体像としては、まず「イメージ」と呼ばれるテンプレートを用意し、このイメージを元に「コンテナ」という実体を作ります。
イメージはレシピ本、コンテナは実際に出来上がった料理だと考えると分かりやすいでしょう。
私たちはDocker Hubという世界最大のレシピサイトから、公式が用意したTomcatのイメージをダウンロードして利用します。
-p でホストのポートとつなぎます。WARを配置すればデプロイできます。Dockerイメージ・コンテナ・ポートの関係
Dockerイメージは実行に必要なすべてのファイルが詰まった静かな塊です。
Dockerイメージをdocker runコマンドで実行すると、メモリ上で動き出す「コンテナ」に進化します。
コンテナは内部で8080番ポートを使って待ち構えていますが、外の世界（手元のPCのブラウザ）からは直接見えません。
そのため、PCの8080番とコンテナの8080番を繋ぐトンネルを掘る設定を行います。
ホストとコンテナのポートをつなぐこの設定をポートフォワーディングと呼び、設定を忘れるとブラウザで「接続拒否」の画面を見て絶望することになります。
Tomcatの公式イメージを取得してコンテナとして起動し、WARファイルをデプロイするまでを扱います。データベース連携や複雑なネットワーク構築は扱いませんので、まずはTomcat単体をDocker上で動かすことに集中しましょう。
この記事で進める構築手順の流れを図にすると、次のようになります。目的に応じて、docker run・Dockerfile・Docker Composeのどれを使うかを選びます。
docker --version で確認tomcat:11-jdk21-p 8080:8080 で即起動docker builddocker compose up -dTomcatをDockerで動かす事前準備
まずは道具が揃っているか確認しましょう。何事も準備が8割です。Dockerさえ動けば、残りは滞りなく進みます。
もし、まだDocker Desktopをインストールしていない場合は、公式サイトからダウンロードしてください。インストール後、クジラのアイコンがタスクバーで泳いでいる状態になれば準備完了です。
ここで注意したいのが、Dockerのバージョンです。
あまりに古すぎると最新のイメージが動かないことがあるので、できるだけ新しいバージョンに更新しておきましょう。
また、Windowsユーザーの方はWSL 2が有効になっているかも確認しておきましょう。
Docker DesktopのWSL 2バックエンド（推奨設定）を使う場合、WSL 2が有効でないと、動作が極端に重くなったり、起動しなかったりしてストレスが溜まります。
Dockerがインストールされているか確認する
ターミナル（WindowsならPowerShellやコマンドプロンプト）を開いて、以下のコマンドを打ち込んでみてください。
docker --versionこのコマンドでバージョン番号が表示されれば準備完了です。もし「コマンドが見つかりません」と言われたら、パスが通っていないか、インストールが完了していません。
PCを再起動すると直ることも多いので、まずは焦らずに再起動を試してみるのが賢明な判断です。
Tomcat公式Dockerイメージのタグはどう選ぶ？
Docker Hubには無数のTomcatイメージがありますが、基本的には「Official Image」と書かれたものを選びましょう。
タグと呼ばれるバージョン指定にもコツがあります。
何も考えずにlatest（最新版）を使うのは、プロの現場ではあまり推奨されません。
なぜなら、ある日突然バージョンが上がって、昨日まで動いていたコードが動かなくなるリスクがあるからです。
例えばtomcat:11-jdk21やtomcat:10.1-jdk21のように、TomcatのバージョンとJavaのバージョンが明示されているタグを選ぶのが、安定性を重視する大人の選択です。
2026年10月時点のDocker Hub公式イメージでは、latestはTomcat 11＋JDK 25を指しています。主なタグの使い分けは次のとおりです。
Tomcat公式イメージの主なタグ（Docker Hub、2026年9月時点）
Tomcat 11はJava 17以降、10.1はJava 11以降が必要です。-jdkの代わりに-jre21のようなJREタグを選ぶと、実行に不要な開発ツールを省いた小さめのイメージです。
2026年10月6日時点でdocker manifest inspect tomcat:11-jdk21とdocker manifest inspect tomcat:11-jre21を実行して比較すると、linux/amd64向けの圧縮レイヤー合計は-jdk21が約230MiB、-jre21が約127MiBでした（タグの中身は更新されるため、数値は実行時期で変わります）。
開発ツール（javac等）を含まない分、-jre21は-jdk21よりおよそ半分のサイズで済みます。ビルド環境と実行環境を分け、本番コンテナには-jre系タグを使うとイメージの取得・起動が速くなります。
docker runでTomcatを即起動する手順
ここからは、実際にTomcatを動かしてみましょう。細かい設定は後回しにして、まずは「動いた！」という成功体験を味わうことが大切です。
以下のコマンドは、Docker界における「Hello World」のようなものです。
ターミナルにコマンドを1行打ち込むだけで、世界中で使われているWebサーバーが自分のPCで動き出します。
この手軽さを知ってしまうと、もう重たいインストーラーを実行していた頃には戻れません。
ネットワーク環境にもよりますが、イメージのダウンロードを含めても数分で完了するはずです。
TomcatをDockerで即起動するコマンド
以下のコマンドをコピーして、ターミナルで実行してください。
docker run -it --rm -p 8080:8080 tomcat:11-jdk21ここで使っているオプションの意味を軽く説明します。
-itはコンテナに疑似ターミナルを割り当てて標準入力を開いたままにするための設定で、Ctrl+Cでの停止などインタラクティブな操作を可能にします（ログがリアルタイムに表示されるのは、-dを付けずフォアグラウンドで実行しているためです）。--rmはコンテナを止めたら自動で削除するための設定です。
-p 8080:8080が先ほど説明したポートのトンネル設定です。
初回実行時はイメージのダウンロードが始まりますので、コーヒーでも飲みながらゆっくり待ちましょう。
なお、Java 25で動かしたい場合はtomcat:11-jdk25、Tomcat 10.1を使いたい場合はtomcat:10.1-jdk21のようにタグを変更してください。
ブラウザでTomcatの起動確認をする
ログに「Server startup in [XXX] milliseconds」（Tomcat 9のイメージでも同じ形式）と表示されたら、ブラウザを開いて http://localhost:8080 にアクセスしてみてください。
Tomcat公式イメージは、セキュリティ上の理由で初期状態では「404 Not Found」が表示されます。
「えっ、失敗？」と思うかもしれませんが、この404表示は正常な動作です。
Tomcatの猫のキャラクターが表示されなくても、サーバー自体が反応していれば、Docker上での起動には成功しています。
この404は、Docker公式イメージが上流のセキュリティ推奨に従い、サンプルアプリをwebapps.distに退避させていることが原因です。Tomcat 9・10.1・11のどのタグでも同じ動作です。
後述のDockerfileセクションで、この問題を解決するコマンドを紹介しています。
DockerfileでTomcat環境を管理する方法
先ほどのdocker runコマンドは手軽ですが、毎回長いオプションを打つのは面倒ですよね。そこで登場するのが「Dockerfile」です。
Dockerfileは、コンテナの構成をテキストファイルに書き留めておける、いわば「設計図」のようなものです。
Dockerfileを使うことで、どのバージョンのTomcatを使い、どのファイルをどこに配置するのかをコードとして管理できます。
DockerfileをGitなどのバージョン管理システムに入れておけば、チームメンバー全員が同じ設計図をもとに環境を構築できます。
設定を「記憶」に頼るのではなく「記録」に残す。この習慣がエンジニアとしての生産性を高めるための第一歩です。
DockerfileでTomcatを定義する基本構成
プロジェクト用のフォルダを作成し、その中に Dockerfile という名前のファイル（拡張子なし）を作成してください。中身は以下のように記述します。
FROM tomcat:11-jdk21
LABEL maintainer="your-name"
# デフォルトで入っているwebapps.distをwebappsにコピーする（404対策）
RUN cp -av /usr/local/tomcat/webapps.dist/* /usr/local/tomcat/webapps/
EXPOSE 8080FROMでベースとなるイメージを指定します。RUNの行は、先ほどブラウザで404が出た問題を解決するための魔法の言葉です。
最近のイメージではサンプルアプリが別フォルダに隔離されているので、そのサンプルアプリを本来の場所に戻してあげています。
イメージをビルドしてコンテナを起動する流れ
設計図ができたら、このDockerfileを元に「自分専用のイメージ」を作ります。以下のコマンドでビルドを行いましょう。
docker build -t my-tomcat .末尾の「.（ドット）」を忘れないように注意してください。ビルドが終わったら、今度は自分のイメージを指定して起動します。
docker run -p 8080:8080 my-tomcatこのイメージを使えば、毎回長いオプションを指定しなくても、自分好みにカスタマイズされたTomcatが立ち上がります。一度作ってしまえば、残りは使い回すだけです。
この圧倒的な効率の良さが、Dockerを使い続ける最大の理由です。
WARファイルをTomcatコンテナにデプロイする手順
サーバーが動くだけでは面白くありませんよね。自分の作ったWebアプリ（WARファイル）を載せてこそ本番です。
Dockerを使えば、アプリの配備（デプロイ）もDockerfileの中で完結します。
従来の方法では、Tomcatのインストールディレクトリを探し出し、webappsフォルダに手動でファイルを放り込んでいました。
しかしDockerなら、ビルド時にファイルをコピーするよう指示するだけです。
これにより、「デプロイ手順書」という名の古いドキュメントをシュレッダーにかけられます。
WARファイルをDockerコンテナに配置する手順
やり方はとても簡単です。Dockerfileに1行追加するだけ。
自分のプロジェクトで生成された sample.war がカレントディレクトリにあると仮定します。
FROM tomcat:11-jdk21
COPY sample.war /usr/local/tomcat/webapps/このCOPY命令によって、コンテナが起動したときにはすでにアプリが配置された状態になります。
コンテナを起動するたびにデプロイ作業をする必要はありません。コンテナそのものが、アプリを含んだ「完成品」になるわけです。
稼働中のコンテナにdocker cpでWARを配置する
イメージを作り直さずに、今動いているTomcatコンテナへWARを1つ試しに載せたいだけなら、docker cpコマンドが手軽です。
# 起動中のコンテナ名（またはID）を確認する
docker ps
# WARファイルをコンテナのwebappsへコピーする
docker cp sample.war my-tomcat:/usr/local/tomcat/webapps/Tomcatはwebappsに置かれたWARを自動で展開するため、再起動しなくても数秒でデプロイされます。my-tomcatの部分は、docker psで表示されたコンテナ名に置き換えてください。
ただし、コピーしたWARはそのコンテナの中にしか存在しません。--rm付きで起動したコンテナを止めたり作り直したりすると消えてしまいます。継続して使うなら、前述のDockerfileのCOPYか、後述のDocker Composeのvolumesで管理しましょう。
アプリが正しくデプロイされたか確認する
イメージをビルドし直してコンテナを起動したら、ブラウザで http://localhost:8080/sample/（WARファイルの名前がsampleの場合）にアクセスしましょう。
もし画面が表示されない場合は、コンテナのログを確認してください。
Javaのクラスが見つからない、あるいは設定ファイルのパスが間違っているなどのエラーが出ているはずです。
Dockerならログがターミナルに垂れ流されるので、わざわざ深い階層にあるログファイルを開きに行く手間も省けます。
不具合の特定が早くなるのも、Docker化の隠れた恩恵です。
Docker ComposeでTomcatを管理する方法
ここまでの手順ではdocker runコマンドを直接実行してきましたが、プロジェクトが大きくなると毎回オプションを指定するのは煩雑です。
Docker Composeを使えば、起動設定をYAMLファイルに書いておくだけで、コマンド一発でTomcat環境を立ち上げられます。
docker-compose.ymlの書き方
プロジェクトのルートに docker-compose.yml を作成し、以下のように記述します。
services:
tomcat:
image: tomcat:11-jdk21
container_name: my-tomcat
ports:
- "8080:8080"
volumes:
- ./webapps:/usr/local/tomcat/webappsportsはポートフォワーディング、volumesはホスト側のフォルダをコンテナ内にマウントする設定です。
volumesを指定しておけば、ホスト側のwebappsフォルダにWARファイルを置くだけで、コンテナを再ビルドせずにデプロイできます。
起動は以下のコマンドです。-dはバックグラウンド実行のオプションです。
docker compose up -d停止する場合は以下を実行します。コンテナの削除まで一括で行ってくれます。
docker compose downdocker runとDocker Composeはどう使い分ける？
「どちらを使えばいいの？」と迷ったときは、目的で判断しましょう。Tomcat単体をサッと動かして動作確認したいならdocker runで十分です。
一方、WARのデプロイ設定を固定化したい場合はDocker Composeを選びましょう。将来的にMySQLなど他のコンテナと連携させる予定がある場合も、Docker Composeのほうが拡張しやすくなります。
Tomcat×Dockerのよくあるトラブルと解決策
Dockerを使っていると、必ずと言っていいほど壁にぶつかります。特に「起動しているはずなのに繋がらない」というトラブルは、初心者の登竜門です。
トラブルが起きたときは、感情的にならずに一歩引いて「通信の経路」を想像してみることが大切です。
自分のPCからコンテナまで、データがどこで止まっているのかを一つずつ確認していけば、必ず解決策は見つかります。
ポートが開かない・接続できないときの原因
最も多い原因は、-pオプションの指定ミスです。
8080:8080と書くべきところを逆にしてしまったり、あるいは他のソフトがすでに8080番ポートを使っていたりすることがあります。
Windowsだと、以前インストールしたTomcatがサービスとして常駐していて、ポートを占有しているパターンがよくあります。
もしエラーで起動できない場合は、docker run -p 9000:8080 のように、左側の数字を変えて試してみてください。
別のポート番号でアクセスできれば、原因はポートの競合で確定です。
もう一つ見落としがちなのが、ファイアウォールやセキュリティソフトによるブロックです。
特にWindowsでは注意が必要です。環境によっては、Windows Defenderファイアウォールやセキュリティソフトの設定で、コンテナへの通信が遮られることがあります。
「ポート設定は合っているのに繋がらない」というときは、ファイアウォールの設定を確認してみてください。
コンテナがすぐ停止する場合に見るべき点
docker runをした直後にコンテナが終了してしまう場合は、Tomcat自体がエラーで落ちています。
よくあるのが、メモリ不足やWARファイルの不正です。
まずは docker logs [コンテナID] を実行して、エラーメッセージを読みましょう。
英語のメッセージが並んでいて面食らうかもしれませんが、一番下の数行に答えが書いてあることがほとんどです。
また、Dockerfileの記述ミスで実行権限が足りない場合もあります。
コンテナは「やるべきことがなくなると死ぬ」という性質を持っているので、異常終了したときは必ずその理由を教えてくれているはずです。
ログが長くて読みきれないときは、Caused by:というキーワードを探してください。Javaのスタックトレースでは、この行が根本原因を示しています。
最後のCaused by:から読み始めるのが、トラブルシュート最速の近道です。
Tomcat 10以降で古いWARが動かない原因
Tomcatは起動しているのに、昔作ったWARだけが404になったり、ログにClassNotFoundExceptionが出たりする場合は、パッケージ名の違いを疑ってください。
Tomcat 10以降はJakarta EEに対応しており、サーブレットAPIのパッケージがjavax.servletからjakarta.servletに変わっています。javax.servletを使って作られたアプリは、tomcat:11やtomcat:10.1のイメージではそのまま動きません。
すぐに動かしたいだけなら、Java EE 8（javax）に対応したtomcat:9-jdk21のようなTomcat 9系のタグに切り替えるのが近道です。長く使うアプリであれば、ソースコードのimportや依存ライブラリをJakarta EE版に移行しましょう。
よくある質問（FAQ）
TomcatをDockerで起動する方法について、読者からよく聞かれる質問をまとめました。タグの選び方からトラブル対処まで、ここまでの内容と重複する質問も含め、要点だけを短くまとめています。細かい手順や根拠は各見出しの本文もあわせて確認してください。
Q1. DockerのTomcatはどのバージョンを選べばいい？
A1. 本番利用や学習用途を問わず、tomcat:11-jdk21のようにTomcatとJavaのバージョンが明示されたタグを選ぶのが安全です。latestは予告なくバージョンが変わるリスクがあるため、安定性を重視するなら避けましょう。
Q2. Docker上のTomcatでログはどこに出る？
A2. docker logs [コンテナID]コマンドで標準出力のログを確認できます。ホスト側にログファイルを残したい場合は、-vオプションやdocker-compose.ymlのvolumesで/usr/local/tomcat/logsをマウントしてください。
Q3. Docker ComposeとDockerfileの違いは？
A3. Dockerfileは「イメージの設計図」で、どのOSにどのソフトを入れるかを定義します。Docker Composeは「コンテナの起動設定」で、ポートやボリュームなどの実行時オプションをまとめて管理するものです。両者は併用するのが一般的です。
Q4. 起動直後に404 Not Foundが出るのはなぜ？
A4. Tomcat公式イメージは初期状態でサンプルアプリをwebapps.distに退避させており、webappsフォルダが空になっているためです。Tomcat 9・10.1・11のどのタグでも同じ動作で、サーバー自体は正常に起動しています。webapps.distの中身をwebappsへコピーするか、WARファイルを配置すれば解消します。
Q5. ポートに接続できないときはどう対処する？
A5. まず-pオプションの指定ミス（左右の数字の逆転）や、他のソフトによる8080番ポートの占有を疑ってください。docker run -p 9000:8080のように左側の数字を変えて接続できれば、原因はポートの競合で確定です。Windowsではファイアウォールのブロックも確認しましょう。
Q6. javax.servletを使った古いアプリがTomcat 11で動かないのはなぜ？
A6. Tomcat 10以降はJakarta EEに対応し、サーブレットAPIのパッケージがjavax.servletからjakarta.servletに変わったためです。すぐに動かしたいだけならtomcat:9-jdk21のようなTomcat 9系のタグに切り替えるのが近道で、長く使うアプリならソースコードをJakarta EE版に移行しましょう。
TomcatをDockerで起動する方法のまとめ
ここまで、TomcatをDockerで動かす方法を一通り解説してきました。
手順の使い分けは3つです。公式タグ（例: tomcat:11-jdk21）を指定したdocker runで、まず動作確認をします。WARを載せて固定したいならDockerfile、設定をファイルで管理したいならDocker Composeを選びましょう。404が出た場合はwebapps.distのコピー、接続できない場合はポート指定やファイアウォールを疑う、という切り分けも覚えておきましょう。
最初はコマンドや設定ファイルに戸惑うかもしれませんが、一度この快適さを知ると、もう直接インストールする環境構築には戻れなくなるはずです。
Dockerは単なるツールではなく、あなたの「開発に対する姿勢」を変えてくれる存在です。
環境を使い捨てにする勇気を持つことで、新しい技術への挑戦がぐっと気楽になります。「壊してもいいんだ」という安心感こそが、エンジニアとしての成長を加速させる一番のスパイスです。これからの時代を生き抜くための心構えは、次の2つに集約できます。
- コンテナは「ペット」ではなく「家畜」のように扱い、調子が悪くなったらすぐに新しいものと取り替える
- Dockerfileを資産として育て、いつでもどこでも同じ環境を再現できるようにしておく
この潔さと再現性こそが、これからの時代を生き抜くエンジニアに求められるスキルです。
| REV. | DATE | 内容 |
|---|---|---|
| 4 | 2026-10-16 | 図解を描き直し（図面のデザインにそろえた） |
| 3 | 2026-10-06 | 2026年10月時点の情報で全体を見直し（古い記述を1件更新） |
| 2 | 2026-07-15 | 2026年7月時点の情報で全体を見直し（古い記述を4件更新） |
| 1 | 2026-02-01 | 初版 |