PixelmonサーバーをWSL2へ移行する【23GBデータとDocker起動確認】

前回記事

【Ansibleで整える】Docker環境構築とSystemdエラー対応

前回のログでは、WSL2上のRocky Linux環境に対してAnsibleを用いたDocker構築を行い、Systemdおよびfstab起因のエラーを解消しました。

本記事では、構築済みのDocker基盤へVirtualBox側のPixelmonサーバーデータを移行し、コンテナとして再デプロイするまでのプロセスを記録します。

1. 23GBのサーバーデータ移行プロセス

Docker基盤のプロビジョニング完了後、旧環境（VirtualBox）に存在するPixelmonサーバーデータの移行を実施しました。アーカイブ状態で23GBに達するデータボリュームの移送経路を以下の通り定義・実行しました。

本記事では、実際に実行する操作を COMMAND、設定ファイルやAnsible定義を CONFIG、正常な実行結果や確認ログを OUTPUT として分けて記録します。

// 1. ホストOS(Windows)を経由したリレー転送

仮想マシンからWSL2へ直接転送するのではなく、ホストOS（Windows）を中継地点とするリレー転送方式を採用しました。PowerShellからSCPプロトコルでVirtualBox内のデータをローカルへ転出後、マウントポイント経由でWSL2のホームディレクトリへ配置しています。

scp minecraft@192.168.1.x:~/minecraft_migration_data.tar.gz $HOME\Desktop\

PS C:\Users\user> scp minecraft@192.168.1.x:~/minecraft_migration_data.tar.gz $HOME\Desktop\
minecraft_migration_data.tar.gz   100%   23GB   60.3MB/s   06:25

実行ログより平均60.3MB/sのスループットを観測し、約6.5分で23GBのデータ転出が完了したことを確認しました。なお、本文中のIPアドレスはローカル検証用の値をマスクしたものです。

2. Ansibleによる自動構築とデプロイ

データの配置完了後、Ansibleを経由して環境の復元およびコンテナの起動シーケンスを自動化します。

// 1. pixelmonロールのタスク定義

アーカイブの展開からDocker Composeによる起動制御までを包括するタスクを実装しました。unarchive モジュールを利用して巨大なデータの展開ステートを管理し、再実行時における処理の冪等性を担保しています。

---
# roles/pixelmon/tasks/main.yml
- name: Extract migration data to base directory
  ansible.builtin.unarchive:
    src: "{{ migration_archive }}"
    dest: "{{ base_dir }}"
    remote_src: yes

- name: Deploy docker-compose.yml from template
  ansible.builtin.template:
    src: docker-compose.yml.j2
    dest: "{{ data_dir }}/docker-compose.yml"

- name: Start Pixelmon container via Docker Compose
  ansible.builtin.shell:
    cmd: "docker compose up -d"
    chdir: "{{ data_dir }}"
    become: yes

3. ディレクトリ階層の不整合とパス修正

初回デプロイ実行後、一部のModが正常にロードされず、クライアントからの接続がリジェクトされるインシデントを観測しました。

// 1. 実体構造へのパス定義修正

原因調査の結果、アーカイブ展開時に server/ ディレクトリが生成され、データが想定パスより一段深い階層へ配置されていることが判明しました。これによりMod群がマウントされず、接続エラーが発生した状態です。

サーバー側のMod未検出に起因する接続エラー画面

23GBの実データを再配置するI/Oコストとデータ破損リスクを回避するため、Ansible側のパス定義変数（data_dir）を実体のディレクトリ構造へ適合させる修正を適用しました。

# roles/pixelmon/vars/main.yml の修正
# 実際にデータが展開されたserverフォルダをルートとして再定義
data_dir: "{{ base_dir }}/server"

パス定義の修正とPlaybookの再実行により、正常にデプロイタスクが完了

4. 稼働確認と運用プロセスの変更

パス修正後の再デプロイにより、要求されるすべてのModが正常にロードされたことを確認しました。

// 1. ログイン試行とログ監視体制

サーバーコンソールログにて Pixelmon 9.3.14 のロード完了を確認後、ホストOSから localhost:25565 へログインテストを実施。旧環境のワールド資産が引き継がれていることを確認しました。

実際のゲーム画面：サーバーへの正常な接続とデータ引き継ぎを証明

# Pixelmon 9.3.14 のロード開始を確認
[modloading-worker-0/INFO] [co.pi.pi.Pixelmon/]: Loading Pixelmon version 9.3.14

# サーバーが認識しているModリスト（Datapacks）の正常表示
[Server thread/INFO] [co.pi.pi.Pixelmon/]: Datapacks found: vanilla,mod_data,mod/pixelmon,tcg,mod/waystones,mod/journeymap,mod/modernfix,...

# サーバー起動完了と、プレイヤー Agetate20 のログイン成功を確認
[Server thread/INFO] [minecraft/DedicatedServer]: Done (1.105s)! For help, type "help"
[Server thread/INFO] [minecraft/MinecraftServer]: Agetate20 joined the game

今後の運用オペレーションとして、常時監視には docker logs -f を、サーバー内コンソール操作には docker attach を利用します。バインドマウントによりデータはLinux側へ永続化されていますが、データ整合性を保つため、停止時は原則として docker compose stop 等による正常終了プロセス（SIGTERM）を使用します。

5. リソース使用量の最適化エビデンス

本アーキテクチャ移行における最大の成果は、サーバー稼働時におけるホストOS（Windows）側のリソース消費量が大幅に最適化された点にあります。

// 1. 技術的エビデンスによる比較検証

VirtualBox環境下ではメモリを静的に固定確保していましたが、WSL2+Docker環境下では動的管理機構により、プロセスが要求する実消費分のみを占有します。docker stats コマンドによりコンテナ単体の実測値を観測しました。

docker stats pixelmon-server --no-stream

CONTAINER ID   NAME               CPU %     MEM USAGE / LIMIT
300316fb7b54   pixelmon-server    0.96%     5.18GiB / 5.788GiB

旧環境：メモリの固定確保による甚大なオーバーヘッド

新環境：実消費リソースに応じた柔軟なメモリ管理を証明

6. 外部公開に向けたネットワークと運用の最適化

資産の移行とリソース最適化のフェーズは完了しましたが、本番運用環境として以下の技術的要件が残存しています。

// 1. 今後の実装要件と技術的背景

① ネットワークの固定化（networkingMode=mirrored）：
WSL2のデフォルトNATモードでは起動ごとにIPアドレスが変動し、ポートフォワーディングの維持が困難です。ホストIPを共有するミラーモードへ変更し、外部接続の安定性を確保します。

② 旧環境資産のクリーンアップ：
不要となった旧環境の起動スクリプト等をパージし、誤実行によるデータ競合（Level.dat破損等）のクリティカルなリスクを排除します。

③ バックアップ運用の再構築：
手動バックアップはヒューマンエラーによるデータ損失を招きます。Ansibleを利用し、「コンテナ停止・アーカイブ圧縮・再開」のバックアップサイクルを自動化タスクとして実装します。

次回のログでは、これらの運用最適化タスクを順次実装・記録する予定です。