前回（開発5日目）は、VPS本体にDockerをインストールし、コンテナを動かすための下準備を行いました。
いよいよ今回は、Dockerを使って「Nginx（案内役）」と「WordPress（ブログ部屋）」のコンテナを立ち上げ、現在稼働しているこのブログ（SWELL環境）をそっくりそのまま新しいDockerの部屋へ「お引っ越し」させます。
しかし、いざ作業を始めてみると、Docker移行ならではの強烈な罠（エラー）が次々と牙を剥きました…。これから同じようにDockerへの移行を考えている方の参考になるよう、環境構築の手順と、私が直面した「5つの罠」とその解決策を全記録として残します！
1. システムの設計図「docker-compose.yml」の作成
まずは、どんなコンテナをどのように動かすかを定義する設計図、docker-compose.yml を作成します。 セキュリティを考慮し、データベースのパスワードなどの機密情報は .env という別ファイルに分けて読み込ませる構成にしました。
▼ .env ファイル（パスワードなどの保管）
DB_ROOT_PASS=ランダムな強力なパスワード
DB_NAME=wp_db_name
DB_USER=wp_db_user
DB_PASS=ランダムな強力なパスワード▼ docker-compose.yml（設計図）
services:
nginx:
image: nginx:latest
ports:
- "80:80"
- "443:443"
# ※後述するSSL化やアップロード制限解除の設定をここに追記していきます
db:
image: mysql:8.4.10
command: --mysql-native-password=ON # 【重要】MySQL 8.4の接続エラー回避
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASS}
MYSQL_DATABASE: ${DB_NAME}
MYSQL_USER: ${DB_USER}
MYSQL_PASSWORD: ${DB_PASS}
wordpress:
image: wordpress:latest
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: ${DB_USER}
WORDPRESS_DB_PASSWORD: ${DB_PASS}
WORDPRESS_DB_NAME: ${DB_NAME}
この構成で docker compose up -d を実行！……したところから、数々の罠との戦いが始まりました。
データ移行で立ちはだかった5つの罠
ここからは、実際に私がDockerへのデータ移行作業でつまずいた強烈なエラーたちと、その解決策を順番に紹介していきます！
【罠その1】ポート80番がすでに使われているエラー
起動コマンドを打った直後、address already in use（ポート80番が既に使用中）というエラーが出てNginxコンテナが立ち上がりませんでした。
【解決策】旧Webサーバーの停止 原因は、移行前のVPS上で直接動いていたWebサーバー（Apacheや旧Nginx）が、まだポート80番を占有していたためです。VPSに直接入り、旧サーバーを完全に停止・無効化することでDocker側がポートを使えるようになりました。
# Apacheが動いていた場合の停止コマンド
sudo systemctl stop apache2
sudo systemctl disable apache2【罠その2】移行プラグインの洗礼「2MBの壁」
土台となる真っ新なWordPressコンテナが立ち上がったので、「All-in-One WP Migration」プラグインを使って旧ブログのデータをインポートしようとしました。 しかし、インポート画面に表示されたのは「最大アップロードサイズ: 2MB」という絶望的な数字。数百MBあるブログデータは到底入りません。
【解決策】PHPとNginx両方の制限を解除する Docker環境では、WordPress本体（PHP）だけでなく、前に立つNginxの制限も解除する必要があります。 PHP側には uploads.ini（500Mに設定）をコンテナ内に配置し、Nginx側の default.conf にも client_max_body_size 500M; を追記。これで無事に大容量ファイルのインポートが可能になりました。
【罠その3】IPアドレスでインポートした悲劇（デザイン崩壊）
ドメインの切り替え前に「IPアドレス」でアクセスしてインポート作業を行ってしまったため、WordPressのシステムに「新しいサイトのURLはIPアドレスだ」と誤って記憶されてしまいました。 その結果、後からドメイン（https化）でアクセスしても、SWELLの美しいデザインが一切効かず、文字化けやレイアウト崩れを起こす「Mixed Content」状態に…。
【解決策】強制上書きとデータベース置換 ターミナルからWordPressコンテナに入り、wp-config.php へ直接正しいドメインを書き込みました。
docker exec docker-web-wordpress-1 sh -c "sed -i '/<?php/a define(\"WP_HOME\", \"https://puffin.jp\");' /var/www/html/wp-config.php"
# WP_SITEURL も同様に追記その後、「Better Search Replace」プラグインでデータベース内の古いIPアドレスURLを新ドメインへ一括置換し、SWELLのキャッシュをクリアすることで完全復活しました！
【罠その4】SiteGuardの画像認証エラーによる「締め出し」
IPアドレス問題の二次災害として、セキュリティプラグイン「SiteGuard」のログイン画像認証（CAPTCHA）が割れて表示されなくなりました。画像が読めないため、管理者である自分自身がログインできないという大ピンチ！
【解決策】コマンドによるプラグインの強制無効化 FTPも使えない状況だったため、ターミナルからコンテナに潜り込み、プラグインのフォルダ名を直接書き換えて強制的に無効化しました。
docker exec docker-web-wordpress-1 mv /var/www/html/wp-content/plugins/siteguard /var/www/html/wp-content/plugins/siteguard-disable【罠その5】WPS Hide Loginの404エラー
最後に、旧環境から引き継いだ「Let’s Encrypt」のSSL証明書をNginxコンテナにマウントし、完全なHTTPS化に成功！……と思いきや、「WPS Hide Login」で設定していた独自のログインURLにアクセスしても、404エラー（ページが見つかりません）になる現象が発生。
【解決策】パーマリンクの空更新 これはお引っ越し直後で、WordPressの裏側のルーティング（道案内ルール）が寝ぼけていたのが原因でした。 通常の管理画面から 「設定」＞「パーマリンク」 を開き、何も変更せずに「変更を保存」ボタンを押すだけで、無事に秘密の入り口が機能するようになりました。
次回の予定：いよいよ自作アプリの開発へ！
数々の罠に見舞われましたが、無事にDockerコンテナへの完全移行が完了しました！これでブログ（WordPress）環境と、その他の環境をきれいに分離することができました。
環境が整ったので、次はいよいよ本来の目的であった「多次元データの可視化や分析ができる自作Webアプリ」の開発と、同居環境へのデプロイ準備に取り掛かっていきます！
