【WebPerformer / Docker】WebPerformer2.7.1.0をDockerで動かすには
こんにちは。エヌデーデーの金子です。
WebPerformerをご使用の皆様、ビルド環境及びランタイムの管理はバッチリでしょうか。
WebPerformerはv2.7.0からコンテナ環境での稼働ができるようになりました。
パブリッククラウドにおけるコンテナサービスでWebPerformerを動かすことができるという利点はもちろん、実行環境の一元管理ができるという点で、コンテナ活用はWebPerformer運用に強力に作用することでしょう。
本記事ではWebPerformerのコンテナ活用における第一歩として、実際にWebPerformerをDockerで動かす方法をご紹介します。
【本記事を読み進めるにあたっての注意事項】
- 使用するバージョンはWebPerformer2.7.1.0のWEBアプリです。
- テストアプリケーションをコンテナ化し、Docker環境のあるローカルマシンで実行をします。
- テストアプリケーションにつき、DB接続・ログ管理・セッション管理・ミドルウェアのカスタマイズなどは考慮しません。
- 実稼働するサービスの場合、dockerコンテナに対するメモリやCPU、javaヒープなど適切にリソースを割り当てることが推奨されます。
- 実際にコンテナをパブリッククラウドで稼働及び運用をする場合、使用するクラウドサービスに応じた追加設定が必要です。
はじめに
本記事では「パターン①：ビルドをローカルマシン上で行う場合」と「パターン②：dockerビルド時にアプリケーションビルドも同時に行う場合」で分けてご紹介します。
WebPerformerの利用者の多くは、ローカルに開発環境を構築しその中でビルドを行っているかと思います。このケースの場合、今まで通りビルドはローカルで行いDockerは実行環境の一元管理として使用するのが何かと便利でしょう。
しかし今日のシステム開発では開発者の環境差異の影響を受けないように、リリース対象のアプリケーションは専用のビルドマシン上で一元的にビルドを行うチームも少なくないかと思います。このケースであれば開発者はソース修正のみ行い、アプリケーションビルドはdockerに任せてしまうのが理想的です。この場合、ビルドマシンはDockerビルド環境のみを保持していればよいです。
Docker環境とWebPerformerの準備
まずDockerビルドが可能な環境を用意します。
当記事ではdocker-desktopの使用を前提としますが、dockerとdocker-composeが使えればdocker-desktopの使用は必須ではないです。
次にWebPerformerインストール時に同梱される「稼働環境表」と「ツールインストール手順書」を参照し必要なツールを確認します。今回は以下を使っていきます。
| 用途 | 名称 | バージョンなど | パターン①でローカルマシンに必要なもの | パターン②でビルドマシンに必要なもの |
|---|---|---|---|---|
| ゲストOS | Ubuntu | Ubuntu 24 | × | × |
| JDK | OpenJDK | OpenJDK21 | 〇 | × |
| APサーバ | Apache Tomcat | Apache Tomcat 10.1 | 〇 | × |
| ビルドツール | Apache Ant | Apache Ant 1.10.15 | 〇 | × |
| IDE | Eclipse | Eclipse2024-12 | 〇 | × |
| WebPerformer | WebPerformer | 2.7.1.0 | WebPerformer Plugin | WPコマンドラインツール |
※2025年6月現在のWebPerformer2.7.1.0のマニュアルを参照しています。使用可能な各種ツールのバージョンは構築時に必ず確認することを推奨します。
v2.7.1.0を稼働させるのに必要な設定
jarファイル
WebPerformer v2.7.1.0を稼働させるには、jakarta.activation-apiとjakarta.mail-apiの指定バージョン以上のjarが必要です。これらはマニュアルの通りにランタイムのtomcatのlibに仕込むか、WPアプリケーション拡張ディレクトリ内に配置する必要があります。
1.3.2. libディレクトリへのJarファイルのコピー
Tomcatのlibディレクトリ（Tomcatのルートディレクトリの下のlib）に以下のjarファイルをコピーします。 以下に記載されているバージョン以降のものを使用してください。 以下のバージョンのjarファイルは、eclipse/dropins/wp/plugins/jp.co.canon_soft.wp.generator.ui_X.X.X/lib-generation/にもあります。
- jakarta.activation-api-2.1.3.jar
- jakarta.mail-api-2.1.3.jar
メール送信機能を利用する場合はさらに以下のjarファイルをコピーします。
- angus-mail-2.0.3.jar
tomcatのserver.xml
また、tomcatのserver.xmlに追加設定が必要です。
Tomcatでは、FORMのGETメソッドでパラメータを送信した場合、setCharacterEncodingメソッドを無視するようになりました。
そのため、下記設定を追加してください。{Tomcatのインストールディレクトリ}\conf\server.xmlファイルの<Connector>の設定に、useBodyEncodingForURI="true" を追加してください。
<Connector port="8080″ protocol="HTTP/1.1″
connectionTimeout="20000″
redirectPort="8443″
useBodyEncodingForURI="true" />
パターン①：ビルドをローカルマシン上で行う場合
ホストマシンディレクトリ構成
ローカルマシンで開発とビルドを行う前提でのコンテナ作成を行っていきます。
ホスト側のディレクトリ構成は以下とします。適宜構築した環境に合わせて読み代えてください。
C:\WP_2_7_1_0
apache-ant-1.10.15 ...antインストールフォルダ
apache-tomcat-10.1.41 ...tomcatインストールフォルダ
eclipse-2024-12 ...eclipseインストールフォルダ
OpenJDK21U-jdk_x64_windows_hotspot_21.0.7_6 ...jdkインストールフォルダ
docker-workspace ...docker関連のワークスペース
Dockerfile ...Dockerイメージ作成における設計図
dokcer-compose.yml ...DockerコンテナRUNの設定yamlファイル
build ...ビルドしたwarを格納するフォルダ
workspace ...eclipseワークスペース
container-test-space
app ...対象アプリケーションはContainerTestWpAppとする
bp
io
...WebPerformerアプリケーション生成
WebPerformerのアプリケーションをGUIから生成する際に、「WARを作成」オプションを選択します。
ビルドが成功した場合、開発用tomcatフォルダ直下にwarが出力されるので、これをdocker-workspace/buildフォルダにコピーします。
DockerビルドとRUN
docker-desktopを起動させておきます。
以下のDockerfileとdocker-compose.ymlをdocker-workspaceフォルダに配置します。
Dockerfile
# syntax=docker/dockerfile:1.4
FROM tomcat:10.1-jre21-temurin-noble
ENV LANG=C.UTF-8 \
TZ=Asia/Tokyo
# server.xmlのConnector設定にuseBodyEncodingForURI="true"を追加
RUN sed -i 's/<Connector port="8080" protocol="HTTP\/1.1"/<Connector port="8080" protocol="HTTP\/1.1" useBodyEncodingForURI="true"/' $CATALINA_HOME/conf/server.xml
# ビルドコンテキスト内の 'build' ディレクトリからWARファイルをTomcatのwebappsにコピー
COPY build/ContainerTestWpApp.war $CATALINA_HOME/webapps/ContainerTestWpApp.war
# Tomcatがデフォルトでリッスンするポートを公開
EXPOSE 8080
# コンテナ起動時にTomcatを開始
CMD ["catalina.sh", "run"]Dockerfileで行っている内容はおおむね以下の通りです。
- tomcat10.1のベースイメージを取得 ※稼働環境表に合わせたOS・JRE・tomcatの組み合わせのイメージを選ぶ
- server.xmlにuseBodyEncodingForURIを設定
- 事前にビルドしているwarファイルをコンテナ内のtomcat/webappsにコピー
- 8080をリッスンポートに設定し、tomcat起動
※Dockerビルドの中でインターネットからベースイメージを取得するので、外と通信ができるようにしておいてください。
docker-compose.yml
# docker-compose.yml
version: '3.8' # Docker Composeファイルのバージョン指定
services:
web:
image: container-test-wpapp:1.0.0
build:
context: . # Dockerfileが置かれているディレクトリ (C:\WP_2_7_1_0\docker-workspace) をビルドコンテキストとする
dockerfile: ./Dockerfile # Dockerfileのパス
ports:
- "8080:8080" # ホストの8080ポートをコンテナの8080ポートにマッピング
container_name: container-test-wpapp # コンテナ名を指定（任意）
restart: unless-stopped # コンテナが停止した場合に自動で再起動
上記を配置したら、dockerビルドとコンテナRUNをします。
# Dockerfileのある位置へ移動
cd C:\WP_2_7_1_0\docker-workspace
# dockerビルドとコンテナRUN
docker-compose up --build -dビルドが成功したかどうかを確認しましょう。もし失敗している場合、Dockerはどこのステップで失敗しているのかがログで確認できるのでわかりやすいと思います。
C:\WP_2_7_1_0\docker-workspace>docker-compose up --build -d
time="2025-06-28T22:44:42+09:00" level=warning msg="C:\\WP_2_7_1_0\\docker-workspace\\docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion"
Compose can now delegate builds to bake for better performance.
To do so, set COMPOSE_BAKE=true.
[+] Building 25.8s (13/13) FINISHED docker:desktop-linux
=> [web internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 732B 0.0s
=> [web] resolve image config for docker-image://docker.io/docker/dockerfile:1.4 2.0s
=> [web auth] docker/dockerfile:pull token for registry-1.docker.io 0.0s
=> CACHED [web] docker-image://docker.io/docker/dockerfile:1.4@sha256:9ba7531bd80fb0a858632727cf7a112fbfd19b17e9 0.0s
=> [web internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [web internal] load metadata for docker.io/library/tomcat:10.1.42-jre21 3.4s
=> [web auth] library/tomcat:pull token for registry-1.docker.io 0.0s
=> [web 1/3] FROM docker.io/library/tomcat:10.1.42-jre21@sha256:e0f633dd965e61a3cd1a9d6e54a57a6bef9954b4a0f8aca 18.8s
=> => resolve docker.io/library/tomcat:10.1.42-jre21@sha256:e0f633dd965e61a3cd1a9d6e54a57a6bef9954b4a0f8acaeb9b4 0.0s
=> => sha256:a156ac8fc59e1707c9f501f0739b750edf0a7eee174a746f875ff6095203a864 52.89MB / 52.89MB 13.2s
=> => sha256:b4d570382bab9a8f261ccabe2287081c1d484a97c6ea8d4fc6225bfe706ccb3b 159B / 159B 0.9s
=> => sha256:e0f633dd965e61a3cd1a9d6e54a57a6bef9954b4a0f8acaeb9b4ff186c64e13e 6.64kB / 6.64kB 0.0s
=> => sha256:a3e70fb445cfcd660c5a9c8beb82c394c3a92e3efd4755cde10f6957e87e43e4 2.91kB / 2.91kB 0.0s
=> => sha256:e29c34f781222f1562a12ade8e5c20fa715a368969d2e9109570547dcedfabe9 9.12kB / 9.12kB 0.0s
=> => sha256:35394ce74242c5b7ece149865352a48182efc427381c78444f4d0d8eb1f42de6 16.97MB / 16.97MB 5.2s
=> => sha256:b894632d8872eed0f9df445b209dd701a6186ce7c4df92157736141508657d61 2.28kB / 2.28kB 1.4s
=> => sha256:c3f1bf3f44e60a6291f511d328cff79513f89d600ecad628cf3eb49c719e4cc1 138B / 138B 1.8s
=> => sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 32B / 32B 2.2s
=> => sha256:ede6d46ebff305e59c539ef8a0b682eac31df4f5e83112e9040292d4ee1b68a3 14.06MB / 14.06MB 7.2s
=> => sha256:b5589f9155133263156afeae952f440176002e766962495de3b5493dee8643af 224.69kB / 224.69kB 5.7s
=> => extracting sha256:35394ce74242c5b7ece149865352a48182efc427381c78444f4d0d8eb1f42de6 4.4s
=> => extracting sha256:a156ac8fc59e1707c9f501f0739b750edf0a7eee174a746f875ff6095203a864 3.8s
=> => extracting sha256:b4d570382bab9a8f261ccabe2287081c1d484a97c6ea8d4fc6225bfe706ccb3b 0.0s
=> => extracting sha256:b894632d8872eed0f9df445b209dd701a6186ce7c4df92157736141508657d61 0.0s
=> => extracting sha256:c3f1bf3f44e60a6291f511d328cff79513f89d600ecad628cf3eb49c719e4cc1 0.0s
=> => extracting sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1 0.0s
=> => extracting sha256:ede6d46ebff305e59c539ef8a0b682eac31df4f5e83112e9040292d4ee1b68a3 0.9s
=> => extracting sha256:b5589f9155133263156afeae952f440176002e766962495de3b5493dee8643af 0.0s
=> [web internal] load build context 16.9s
=> => transferring context: 90.15MB 16.9s
=> [web 2/3] RUN sed -i 's/<Connector port="8080" protocol="HTTP\/1.1"/<Connector port="8080" protocol="HTTP\/1. 0.6s
=> [web 3/3] COPY build/ContainerTestWpApp.war /usr/local/tomcat/webapps/ContainerTestWpApp.war 0.2s
=> [web] exporting to image 0.4s
=> => exporting layers 0.3s
=> => writing image sha256:c4c98229811fb0e42c7e4679be9de6254cfa7f8d1f4d750a14a1f3d8e1f2d774 0.0s
=> => naming to docker.io/library/container-test-wpapp:1.0.0 0.0s
=> [web] resolving provenance for metadata file 0.0s
[+] Running 3/3
✔ web Built 0.0s
✔ Network docker-workspace_default Created 0.1s
✔ Container container-test-wpapp Started 0.9s
C:\WP_2_7_1_0\docker-workspace>正常に終了したら、localhost:8080/アプリ名にアクセスして稼働していることを確認します。
Dockerfileの中で書き込んだserver.xmlの設定が反映されているか、コンテナの中に入って確認してみましょう。
# コンテナの中に入る
docker exec -it container-test-wpapp bash
# server.xml確認
cat conf/server.xml
～中略～
<Connector port="8080" protocol="HTTP/1.1" useBodyEncodingForURI="true"
connectionTimeout="20000"
redirectPort="8443"
maxParameterCount="1000"
/>
～中略～パターン②：dockerビルド時にアプリケーションビルドも同時に行う場合
ホストマシンディレクトリ構成
では開発を行わないビルドマシンでのコンテナ作成を試します。
必要なのは、ターゲットアプリケーションのソースとWPインストール時に同梱されるwpコマンドラインツールの一式です。
C:\WP_2_7_1_0
tools ...wpツールフォルダ
workspace ...ビルド用ワークスペース
container-test-space ...ビルド対象アプリケーションソースコード
app ...対象アプリケーションはContainerTestWpAppとする
bp
io
...
Dockerfile
docker-compose.yml
WebPerformerコマンドラインツールは、C:\WP_2_7_1_0\toolsに配置します。
DockerビルドとRUN
docker-desktopを起動させておきます。
以下のDockerfileとdocker-compose.ymlをworkspace/container-test-spaceフォルダに配置します。
Dockerfile
# syntax=docker/dockerfile:1.4
# 複数ビルドコンテキストを使いたいのでDockerFile1.4
# https://www.docker.com/ja-jp/blog/dockerfiles-now-support-multiple-build-contexts/
FROM tomcat:10.1-jdk21-temurin-noble
ENV LANG=C.UTF-8 \
PROJECT_HOME=/usr/src/app \
TOOL_HOME=/opt/WPCommand_2.7.1
# 必要なパッケージをインストール
RUN apt-get update && apt-get -o=Dpkg::Progress-Fancy=1 install -y \
wget \
unzip \
ant \
&& rm -rf /var/lib/apt/lists/*
# server.xmlの<Connector>にuseBodyEncodingForURI="true"を追加
RUN sed -i 's/<Connector port="8080" protocol="HTTP\/1.1"/<Connector port="8080" protocol="HTTP\/1.1" useBodyEncodingForURI="true"/' $CATALINA_HOME/conf/server.xml
# WPツールをZIPファイルから展開
COPY --from=wp-tools /WPCommand_2710.zip /tmp/WPCommand_2710.zip
RUN unzip /tmp/WPCommand_2710.zip -d /opt && \
rm /tmp/WPCommand_2710.zip
# アプリケーションをコピー（別ビルドコンテキストとして）
# ホストのworkspace（WPプロジェクトルート）からコピー
COPY --from=workspace / $PROJECT_HOME
WORKDIR $PROJECT_HOME
# RUN find /usr/src/app ログ出し
# build.xmlやwp-build_propertiesの<property>によって上書きされてしまわないよう、
# Ant 実行時に各種プロパティを明示指定
ARG APP_CODE
RUN ant \
-Dtarget.app.code=$APP_CODE \
-Dtarget.project=$PROJECT_HOME \
-Dtool.home=$TOOL_HOME \
-Dtarget.dir=$CATALINA_HOME/webapps \
-buildfile build.xml
EXPOSE 8080
CMD ["/usr/local/tomcat/bin/catalina.sh", "run"]
内容はおおむね以下の通りです。
- tomcat10.1のベースイメージを取得 ※稼働環境表に合わせたOS・JDK・tomcatの組み合わせのイメージを選ぶ
- ビルドに必要な各種パスと環境変数を設定
- antおよび各種ツールをaptインストール
- server.xmlにuseBodyEncodingForURIを設定
- WPコマンドラインツールを解凍
- ホストディレクトリからアプリケーションソースをコピー
- antビルドを実行
- 8080をリッスンポートに設定し、tomcat起動
※Dockerビルドの中でインターネットから各種ディストリビューションをインストールするので、マシンがインターネットと通信ができるようにしておく必要があります。
また実際にコンテナ化をしてみての反省ですが、ベースイメージのopenJDKと「3. antおよび各種ツールをaptインストール」で追加インストールしているApache Ant, およびホスト側から受け渡しをしているWPコマンドラインツールはランタイムではなくWPアプリケーションビルドに必要な資材です。
実サービス運用に際してはdockerイメージの中に含めないほうが望ましいかもしれません。
その際はベースイメージをtomcat:10.1-jre21-temurin-nobleなどにし、AntやWPコマンドラインツールはビルドマシンのホスト側にあらかじめ展開したうえで、Docker daemonに受け渡してビルドを行う、といった施策が考えられますね。
docker-compose.yml
# docker-compose.yml
version: '3.8'
services:
wp-app: # サービス名（コンテナ名）
image: container-test-wpapp:1.0.0 # 使用するイメージ名
build:
context: . # メインのビルドコンテキスト（Dockerfileとこのdocker-compose.ymlがあるディレクトリ）
dockerfile: ./Dockerfile # Dockerfileのパス (contextからの相対パス)
# 複数ビルドコンテキストを指定する場合、additional_contextsを使用
additional_contexts:
workspace: .
wp-tools: C:\WP_2_7_1_0\tools
args: # ビルド引数
APP_CODE: "ContainerTestWpApp"
ports:
- "8080:8080" # ホストの8080ポートをコンテナの8080ポートにマッピング
container_name: container-test-wpapp # コンテナに割り当てる名前
environment:
- TZ=Asia/Tokyo # 環境変数
restart: unless-stopped # コンテナが終了した場合の再起動ポリシー（オプション）
dockerビルドをする際にアプリケーションソースディレクトリとWPツールディレクトリを複数コンテキストとして渡しているところがポイントです。
上記を配置したら、dockerビルドとコンテナRUNをします。
※jdkのインストールがかなり重たいので、初回は時間がかかります。2回目以降はキャッシュが使用されるようになります。
# Dockerfileのある位置へ移動
cd C:\WP_2_7_1_0\workspace\container-test-space
# dockerビルドとコンテナRUN
docker-compose up --build -d同じようにコンテナを実行してアプリケーションが稼働しているか確認してみましょう。
以上です。お疲れさまでした。
補足：tomcatの設定永続化について
今回、tomcatのserver.xmlをコンテナビルド時に設定書き換えを行っています。
しかしserver.xmlに限らず、web.xmlやtomcat-users.xmlなど、カスタムしている方々も多いと思います。
こういった設定ファイルの書き換えをDockerfileに書いてももちろん良いですが、
ホスト側で/conf下のファイルを管理し、docker立ち上げ時にマウントする方式をとることも可能です。
この場合はdocker-compose.ymlのvolumesセクションで、ホスト側で管理する/confとコンテナ内tomcatの/confをマッピングすればOKです。
終わりに
今回はWebPerformerコンテナ稼働対応を受けて、実際にコンテナ稼働をローカルで実行してみました。
今回の記事で扱ったのはシンプルなアプリケーションでしたが、実際の業務アプリケーションをコンテナ化し、運用する際には、いくつかの重要な追加考慮事項があることに注意してください。
例えば。。
- リソース管理: 実稼働するサービスでは、Dockerコンテナに対してメモリ、CPU、Javaヒープなどを適切に割り当てることを強く推奨します。他にもtomcatに持たせる別ライブラリや外部ファイルがある場合のボリュームマウントなど、ランタイムや運用に合わせたdockerイメージの調整を行う必要があります。
- クラウド環境適応: パブリッククラウドのマネージドサービスでコンテナを稼働させる場合、利用するクラウドサービスに応じた追加設定やセキュリティ対策（DB接続、ログ管理、セッション管理、ミドルウェアのカスタマイズなど）が不可欠です。
しかしトライ＆エラーがやりやすいのもコンテナの強力な魅力の一つです。
色々試してみてダメだったらコンテナごと破棄して。。といった試行錯誤のサイクルを回しやすいですね。
「WebPerformerをコンテナで動かしてみたい」
「オンプレミスで実行しているWebPerformerをパブリッククラウドのマネージドサービスに移行したい」
このようなご要望をお持ちであれば、WebPerformerのコンテナ化にぜひチャレンジしてみてはいかがでしょうか。