レガシーミドルウェアからの段階的Docker移行戦略
GlassFish 4.1、Java 8、MySQL 5.7 の保守期限切れにより、新規環境の導入時に問題が顕在化しました。既存環境では Apache、GlassFish、MySQL をローカル環境に直接インストールしており、オンプレミス環境のセットアップに膨大な時間がかかっていました。
本記事では、約 7 日間で単独実施した Docker 移行プロジェクトについて、「どのような順番で進めたか」「どのようにリスクを潰したか」といった戦略・アプローチに絞ってまとめます。
具体的な Dockerfile / docker-compose.yml / JSON-B 実装 などの技術詳細は、以下の関連記事に分割しています。
プロジェクト概要
抱えていた課題
-
保守期限切れのミドルウェア
- GlassFish および MySQL 5.7 が保守期限切れ
- 新規環境構築時にミドルウェアの入手が困難に
-
環境構築の属人化と再現性の欠如
- オンプレミス環境のセットアップ手順が複雑で属人化
- EC2 の AMI が「秘伝のタレ」化し、構築経緯が不明
- 環境差異によるトラブルシューティングが困難
- 新規環境の立ち上げに膨大な時間を要する
-
マルチ環境対応の課題
- オンプレミス（Windows Server）とクラウド（AWS EC2）の両環境で稼働
- 環境差異による不具合のリスク
- 構成の再現性と移植性の欠如
移行の目標
- GlassFish 4.1 から Payara 6.11（オープンソース版 GlassFish 後継）への移行
- Java 8 から Java 21 への移行
- MySQL 5.7 から MySQL 8.0 への移行
- すべてのミドルウェアの Docker コンテナ化
- Windows Server（Hyper-V）と AWS EC2（Linux）の両環境対応
- 環境構築の標準化と自動化
なぜ段階的アプローチを選択したのか
一気に全環境を Docker 化すると、以下のリスクがあります:
- 影響範囲が大きすぎる - 問題発生時の切り戻しが困難
- デバッグが困難 - 複数の変更が絡み合い、原因特定に時間がかかる
- 検証不足 - 十分なテストができないまま本番適用のリスク
そこで、リスクを最小化するため段階的な移行を実施しました。
段階的な移行アプローチ
段階1: 開発環境の部分 Docker 化
対応内容:
- Apache + MySQL を Docker 化
- Payara はローカル起動のまま維持
- Docker Compose で Apache と MySQL を連携
判断理由:
- まずは影響範囲の小さい部分から Docker 化
- Payara のコンテナ化は難易度が高いため後回し
- MySQL の動作確認を先行して実施
所要期間: 1日
成果:
- Docker Compose の基本構成を確立
- MySQL 8.0 の認証方式問題を発見・解決
- 開発メンバーに Docker 環境を慣れてもらう
学び:
MySQL 8.0 の caching_sha2_password 認証方式の変更により、既存アプリケーションが接続できない問題が発生しました。この段階で発見できたことで、後続の移行がスムーズになりました。
段階2: Payara の Docker 化
対応内容:
- Payara 専用の Dockerfile を作成
-
domain.xml、myapp-api.war、設定ファイルをコンテナに配置 - Apache + Payara + MySQL の 3 層構成を Docker Compose で統合
工夫点:
- 既存の
domain.xmlを最大限活用 - 環境変数による設定の外部化
- ログとデータの永続化設計
所要期間: 2日
成果:
- 開発環境の完全な Docker 化を実現
- Jakarta EE への移行完了
- JSON-B のカスタムシリアライザ実装
苦労した点:
-
domain.xmlの設定が複雑で、環境ごとの差分管理が難しい - Payara の起動時間が長く、
docker-compose upで他サービスとタイミングがずれる
解決策:
- 環境固有の設定は環境変数で外部化
- ヘルスチェックを実装して起動順序を制御
段階3: AWS EC2 環境への適用
対応内容:
- Amazon Linux 2023 環境で Docker 構成を構築
- CloudFormation による IaC 化（EC2、ALB、Route 53、ターゲットグループ）
- 初期セットアップスクリプトの作成
ポイント:
- 開発環境で検証済みの Docker 構成をそのまま適用
- 環境差異を
.envファイルで吸収 - インフラ構成をコード化して再現性を確保
所要期間: 2日
成果:
- クラウド環境での Docker 構成を確立
- インフラのコード化（IaC）により再現性を確保
- セットアップスクリプトにより環境構築を自動化
工夫点:
開発環境で検証済みの Docker Compose ファイルをそのまま使えたため、環境差異による問題はほとんど発生しませんでした。.env ファイルで環境変数を管理することで、同じ構成を異なる環境で再利用できました。
段階4: Windows Server 環境の Hyper-V + Docker 化
対応内容:
- Hyper-V 上に Rocky Linux を構築
- セキュアブート無効化、静的 IP 設定
- Docker 環境の構築と動作確認
新規チャレンジ:
- Hyper-V の利用は初めて
- 詳細な手順書を作成して知見を蓄積
所要期間: 2日
成果:
- オンプレミス環境の Docker 化を実現
- AWS 環境と同じ Docker 構成を維持
- マルチ環境対応の完成
判断:
Windows Server に Docker を直接インストールする方法もありましたが、Linux コンテナを動かすには複雑な設定が必要でした。Hyper-V 上に Rocky Linux を構築することで、AWS 環境と同じ構成を維持でき、運用スクリプトの共通化も実現できました。
移行による成果
環境構築の標準化と脱属人化
インフラ構成のコード化:
- Docker Compose と CloudFormation により環境定義を完全にコード化
- AMI の「秘伝のタレ」問題を解消
- 誰でも同じ環境を再現可能に
環境構築時間の劇的な短縮:
# 従来: 手作業で数時間〜数日
# Docker 化後: スクリプト実行のみで完結
./setup.sh
具体的な効果:
- 新規環境構築: 8時間 → 30分（約95%削減）
- 環境差異によるトラブル: 月5-10件 → ほぼゼロ
- 新規メンバーの環境セットアップ: 1日 → 1時間
再現性の確保
構成管理のコード化により:
- AMI の中身がブラックボックス化する問題を解消
- 環境の変更履歴を Git で追跡可能
- どの環境でも同じ構成を保証
これにより、「あの AMI は何が入っているか分からない」という状況から脱却できました。
属人化を排除し、新規メンバーでも即座に環境構築が可能になりました。
マルチ環境対応
同一の Docker 構成で以下の環境を統一:
- 開発環境（ローカル PC）
- Windows Server（Hyper-V + Rocky Linux）
- AWS EC2（Amazon Linux 2023）
環境差異による不具合が大幅に減少しました。
段階的移行の重要なポイント
1. 小さく始める
影響範囲の小さい部分から段階的に移行することで、リスクを最小化できます。
良い例:
- まず Apache と MySQL を Docker 化
- 次に Payara を Docker 化
- 最後に全体を統合
悪い例:
- 一気に全部を Docker 化
- いきなり本番環境で実施
2. 各段階で検証を徹底
次の段階に進む前に、現在の段階を十分に検証します。
検証項目:
- 機能が正常に動作するか
- パフォーマンスに問題はないか
- エラーログに異常はないか
- 運用スクリプトが動作するか
3. ロールバック計画を用意
万が一問題が発生した場合に備えて、ロールバック計画を準備します。
準備したもの:
- 旧環境の手順書
- データベースのバックアップ
- 切り戻し手順書
4. ドキュメント化を並行
各段階で学んだことをドキュメント化します。
記録したこと:
- 発生した問題と解決策
- 設定ファイルの変更内容
- 環境構築手順
- 運用Tips
所感と学び
Docker 化の意義
GlassFish から Payara に変えても、WAR モデルの重さ自体は解決しません。
しかし Docker 化により:
- AMI の「秘伝のタレ」問題を完全に解消
- オンプレミスと AWS で同じ構成を維持
- 環境構築の手順が完全に標準化
特に、インフラ構成がブラックボックス化していた問題が解決できたことは、運用面で極めて大きな価値がありました。
段階的アプローチの重要性
一気に全環境を移行するのではなく、
- 開発環境の一部 Docker 化
- Payara の Docker 化
- AWS への適用
- Windows Server の移行
というステップを踏んだことで、各段階でリスクを検証しながら進められました。
もし一気に移行していたら:
- 問題の切り分けが困難
- 切り戻しの影響が大きい
- メンバーの学習コストが高い
IaC の価値
CloudFormation でインフラ構成をコード化したことで:
- 環境の再構築が容易に
- 変更履歴が Git で管理可能
- レビューとバージョン管理が可能に
インフラもコードとして扱う重要性を実感しました。
生成 AI の活用
Jakarta EE への移行や、初見の Hyper-V 構築など、未経験の技術に対して生成 AI が大いに役立ちました。特に:
- パッケージ名の一括置換スクリプト
- JSON-B のカスタムシリアライザ実装
- Hyper-V の設定手順の調査
これらを AI の支援を受けながら短期間で実装できました。
まとめ
本記事では、レガシーミドルウェアからの Docker 移行を段階的に実施した戦略について紹介しました。
重要なポイント:
- 段階的な移行でリスクを最小化
- 各段階で十分な検証を実施
- ドキュメント化と知見の蓄積
- IaC によるインフラのコード化
移行スケジュール:
- 段階1（Apache + MySQL）: 1日
- 段階2（Payara）: 2日
- 段階3（AWS EC2）: 2日
- 段階4（Windows Server）: 2日
- 合計: 7日間
Docker 化により、環境構築の標準化、脱属人化、マルチ環境対応を実現できました。
関連記事・詳細解説
本記事は「戦略と進め方」にフォーカスしています。
技術的な詳細は、以下の個別記事に分割してあります。
Discussion