既存のサーバーデータをWSL2へ移す
VirtualBox上で運用していたPixelmonサーバーを、WSL2上のDocker環境へ移行します。2026年4月の作業では、23GBと表示されたアーカイブを転送し、展開先の階層に合わせて設定を直した後、サーバーの起動とゲームへの接続を確認しました。
この記事の中心は、データを展開した場所とDockerから参照する場所のずれを解消した過程です。Dockerを初めて導入する手順ではなく、既存サーバーのデータを移す作業として扱います。
移行元と移行先を確認する
移行元はVirtualBox内のLinux、移行先はDocker ComposeとAnsibleを利用できるWSL2のLinux環境です。Windowsを中継し、次の順序でデータを移しました。
- 旧環境のアーカイブをWindowsのデスクトップへ転送します。
- Windows側のファイルをWSL2側へ配置します。
- Ansibleで展開とCompose設定の配置を行います。
- コンテナを起動し、ログとゲーム接続を確認します。
旧環境の minecraft_migration_data.tar.gz は作成済みの状態から始めています。アーカイブ作成時の停止操作や作成コマンドはこの記事の記録に含まれていません。同様の移行では、書き込みを止めたデータを用意し、移行が確認できるまで旧環境を残しておく必要があります。
Windowsを経由してアーカイブを転送する
WindowsのPowerShellから、旧環境のSSH接続先に対して scp を実行しました。minecraft は旧環境のユーザー名、192.168.1.x は伏せたIPアドレスです。再利用する場合は実際の接続先へ置き換えます。
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転送ログには 100%、23GB、60.3MB/s、06:25 と表示されています。これはこの転送時の表示で、常に同じ速度になるわけではありません。
続いて、Windows側のファイルをWSL2のホーム配下へ配置しました。WindowsのCドライブはLinux側から /mnt/c として参照できます。たとえば C:\Users\user\Desktop は /mnt/c/Users/user/Desktop に対応します。当時はエクスプローラーでWSL2のホームディレクトリへ配置しており、コマンドの記録はないため、パスの対応として説明しています。
アーカイブの保存容量だけでなく、展開後のデータを置く空き容量も必要です。配置後はAnsibleの migration_archive が、そのアーカイブのパスを指すようにします。
Ansibleで展開先とComposeの配置を定義する
Ansibleのロールは、関連するタスクや変数をまとめる単位です。この作業では pixelmon ロールでアーカイブの展開、Composeファイルの生成、コンテナ起動を行っています。
必要なファイルと変数の役割は次のとおりです。
| 名前 | 役割 |
|---|---|
site.yml | pixelmonロールを呼び出すPlaybook |
hosts | Ansibleの実行対象を指定するインベントリ |
roles/pixelmon/tasks/main.yml | 展開・設定配置・起動のタスク |
docker-compose.yml.j2 | Compose設定を生成するテンプレート |
migration_archive | WSL2側に置いたアーカイブのパス |
base_dir | アーカイブを展開する親ディレクトリ |
data_dir | Composeを実行するサーバーディレクトリ |
以下は当時の記事に掲載したタスクの抜粋です。site.yml やComposeテンプレートの全体は含まれていないため、これだけで新規環境を構築する一式ではありません。
---
# 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: yesremote_src: yes は、Ansibleの実行対象側にあるアーカイブを使う指定です。展開先には base_dir、Composeファイルの配置と実行には data_dir を使っています。この2つの関係が、次の接続エラーの調査で重要になりました。
展開されたserverディレクトリにパスを合わせる
初回の起動後、クライアントから接続すると、Waystonesのチャンネルがサーバー側にないというエラーが出ました。
当時の調査では、アーカイブを展開すると base_dir の下に server ディレクトリができ、実データが想定より1段深い場所にあると分かりました。データを移し直す代わりに、Ansibleの参照先を実際の配置へ合わせています。
# roles/pixelmon/vars/main.yml の修正
# 実際にデータが展開されたserverフォルダをルートとして再定義
data_dir: "{{ base_dir }}/server"つまり、base_dir は展開先の親、data_dir はその中の server です。Composeテンプレート側のデータ参照も、この実データを使う必要があります。エラー画面だけで原因を判断せず、展開後の構造と参照パスを照合することが切り分けになります。
修正後は ~/ansible-minecraft で ansible-playbook -i hosts site.yml -K を実行しました。-i hosts はインベントリの指定、-K は権限昇格用パスワードの入力を求める指定です。
集計は ok=7 changed=3 unreachable=0 failed=0 でした。展開・テンプレート配置・起動が changed になっています。これは処理が完了した記録で、再実行時に変更が出ないことまで確認した結果ではありません。既存データへ再展開する際も、上書きの影響を確認する必要があります。
サーバーの起動とゲームへの接続を確認する
掲載ログにはPixelmon 9.3.14の読み込み、起動完了を示す Done、プレイヤー参加の記録が残っています。
# Pixelmon 9.3.14 のロード開始を確認
[modloading-worker-0/INFO] [co.pi.pi.Pixelmon/]: Loading Pixelmon version 9.3.14
# 検出されたデータパックの一覧
[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ログ中の Datapacks found は検出されたデータパックの一覧で、全Modの全機能が正常である証明ではありません。今回の到達点は、サーバーが起動し、クライアントから接続してゲーム画面を表示できたことです。
当時はWindows側から localhost:25565 へ接続したと記録しています。ここでの localhost は操作中のPCを指し、別のPCからの接続確認とは区別します。その後の運用では、ホスト側の待ち受けポートを25577にしています（4月28日のバックアップ手順の記事）。
ゲーム画面にはワールド内の建物や設備が表示されています。すべてのワールドデータやModの動作を網羅した比較ではないため、普段使う場所や機能は移行後にも個別に確認する必要があります。
メモリ使用量は測定対象を分けて読む
コンテナの使用量は、次のコマンドで確認しました。
docker stats pixelmon-server --no-streamCONTAINER ID NAME CPU % MEM USAGE / LIMIT
300316fb7b54 pixelmon-server 0.96% 5.18GiB / 5.788GiBここでの 5.18GiB / 5.788GiB はコンテナの使用量と上限の表示です。一方、Windowsのタスクマネージャーでは移行前のVirtualBoxが8,200.3MB、移行後の VmmemWSL が4,644.9MBと表示されていました。
コンテナ、WSL全体、VirtualBoxのプロセスは測定対象が異なります。撮影時点の負荷も揃えていないため、これらの差をそのまま移行による削減量とは扱いません。移行前後を比較する場合は、同じワールド・人数・稼働時間などの条件を揃える必要があります。
データの配置と参照先を揃えて移行を進める
23GBのアーカイブを転送し、展開後の server ディレクトリに参照先を合わせたことで、Playbookの完了とゲームへの接続まで進みました。今回の切り分けでは、ファイルが存在することだけでなく、実際にどの階層を使って起動しているかを確認することが重要でした。
継続運用では、別端末からの接続、再起動後の状態、バックアップと復元をそれぞれ確認します。旧環境の整理は、移行したデータと必要な機能を確認してから判断する工程です。
