ConoHaVPSのDockerを /var/www/に移行する手順

この記事を読むと、ConoHa VPS の Docker 構成をホームディレクトリからフォルダごと /var/www/ に移行する全手順が分かります✨

• 💬 VPS のプロジェクトフォルダをどこに置くべきか分からない（~/に置いたまま）
• 💬 フォルダを移動したら Docker コンテナが起動しなくなった
• 💬 COMPOSE_PROJECT_NAME を変えるとボリュームのデータはどうなるか不安

弊社でもこの移行作業を実際に行いました。
ネットワーク名の更新漏れなどハマった箇所も含めて共有します。

実行環境

docker compose version   # v2 が入っている場合はこちらが通る
docker-compose version   # v1 が入っている場合はこちらが通る

移行前後のフォルダ構成

移行前：

~/yourname/       ← Next.js プロジェクト
~/wordpress/      ← WordPress プロジェクト

移行後：

/var/www/
└── yourname/
    └── site/
        ├── nextjs/      ← Next.js プロジェクト
        └── wordpress/   ← WordPress プロジェクト

移行前後でコンテナ・ボリューム・ネットワークの名前がどう変わるかを図で示します。

【移行前】
[プロジェクト: wordpress]
 ├ コンテナ: wordpress_wordpress_1
 ├ コンテナ: wordpress_db_1
 ├ ボリューム: wordpress_db_data
 ├ ボリューム: wordpress_wp_data
 └ ネットワーク: wordpress_default

[プロジェクト: yourname]
 └ コンテナ: yourname_app_1
    （wordpress_default ネットワーク経由で接続）

【移行後】
[プロジェクト: yourname-wordpress]
 ├ コンテナ: yourname-wordpress_wordpress_1
 ├ コンテナ: yourname-wordpress_db_1
 ├ ボリューム: yourname-wordpress_db_data
 ├ ボリューム: yourname-wordpress_wp_data
 └ ネットワーク: yourname-wordpress_default

[プロジェクト: yourname-nextjs]
 └ コンテナ: yourname-nextjs_app_1
    （yourname-wordpress_default ネットワーク経由で接続）

正直に言うと、~/ホームディレクトリにWebサービスを置いたまま運用するのは、1案件・1サービスの段階では問題ありません。
ただ、案件が増えた時点でフォルダが乱立して管理が破綻します。
だからうちでは、最初から /var/www/クライアント名/ という構成に統一することにしました。
別のエンジニアに引き継ぐ際の説明コストも大幅に下がります。

ConoHa VPS の Docker 構成を /var/www/ に移行する手順

事前準備：tmux でセッションを保持する

SSH接続が切れても作業が継続するよう、tmux セッション内で作業します。

tmux new -s migrate

# 再接続時
tmux attach -t migrate
# 作業完了後
tmux kill-session -t migrate

Step 1：スナップショットを撮る

作業前にVPS全体のスナップショットを撮ります。問題が起きたときにここに戻せます。シャットダウン中はサイトがダウンします（数分〜10分程度）。

1. ConoHa コントロールパネル → 「シャットダウン」→ 停止を確認
2. 「イメージ保存」→ 名前例：2026-04-22_before-folder-migrate
3. 「保存イメージ」タブで作成を確認
4. 「起動」で VPS を再起動

# 再起動後：SSH接続とコンテナ起動を確認
ssh yourname@xxx.xxx.xxx.xxx
docker ps
# nextjs と wordpress のコンテナが Up になっていることを確認

Step 2：コンテナを停止する

ファイルコピー中にDBファイルが書き変わるとデータが壊れる恐れがあります。すべて停止してから作業します。

cd ~/yourname && docker-compose down
cd ~/wordpress && docker-compose down

Step 3：/var/www/ にフォルダを作成する

sudo mkdir -p /var/www/yourname/site/nextjs
sudo mkdir -p /var/www/yourname/site/wordpress
sudo chown -R yourname:yourname /var/www/yourname

chown は省略不可です。sudo mkdir で作ったフォルダはデフォルトで root 所有になっており、このままだと VS Code の Remote SSH やデプロイスクリプトが「Permission Denied」で弾かれます。自分のユーザーに所有権を変更することで、以降の作業・デプロイが通常ユーザー権限で通るようになります。

Step 4：ファイルをコピーする

末尾の /. で .env などの隠しファイルも含めてコピーします。この時点では元フォルダを削除しません。

cp -r ~/yourname/. /var/www/yourname/site/nextjs/
cp -r ~/wordpress/. /var/www/yourname/site/wordpress/

# 確認
ls -la /var/www/yourname/site/nextjs/
ls -la /var/www/yourname/site/wordpress/

# 権限を再設定
sudo chown -R yourname:yourname /var/www/yourname/

# docker-compose.yml 内のマウントパスを確認
grep -A5 "volumes:" /var/www/yourname/site/wordpress/docker-compose.yml
grep -A5 "volumes:" /var/www/yourname/site/nextjs/docker-compose.yml

確認するのは2種類です。

• ⚠️ 相対パス（./data:/var/lib/mysql 形式）： コンテナ起動時のカレントディレクトリが基準になります。cd /var/www/.../site/wordpress && docker-compose up のように docker-compose.yml があるフォルダで実行すれば問題ありません。
• ⚠️ 旧ホームディレクトリへの絶対パス（/home/yourname/wordpress/data 形式）： ファイルをコピーしただけでは動きません。yml ファイル内のパスを新しい場所（/var/www/yourname/site/wordpress/data など）に書き換える必要があります。

Step 5：COMPOSE_PROJECT_NAME を設定する

将来的に同名のプロジェクトが増えたときのコンテナ名衝突を防ぐために、明示設定します。これにより、複数クライアントのコンテナ名が一目で判別でき、誤ったコンテナを操作するミスが減ります。

# wordpress 側
ENV=/var/www/yourname/site/wordpress/.env
NEW="COMPOSE_PROJECT_NAME=yourname-wordpress"
if grep -q "COMPOSE_PROJECT_NAME" "$ENV" 2>/dev/null; then
  sed -i "s/^COMPOSE_PROJECT_NAME=.*/$NEW/" "$ENV"
else
  echo "$NEW" >> "$ENV"
fi

# 確認（COMPOSE_PROJECT_NAME=yourname-wordpress が含まれていればOK）
cat /var/www/yourname/site/wordpress/.env

# nextjs 側
ENV=/var/www/yourname/site/nextjs/.env
NEW="COMPOSE_PROJECT_NAME=yourname-nextjs"
if grep -q "COMPOSE_PROJECT_NAME" "$ENV" 2>/dev/null; then
  sed -i "s/^COMPOSE_PROJECT_NAME=.*/$NEW/" "$ENV"
else
  echo "$NEW" >> "$ENV"
fi

COMPOSE_PROJECT_NAME を設定すると、コンテナ名・ボリューム名・ネットワーク名がすべて連動して変わります：

COMPOSE_PROJECT_NAME=yourname-wordpress
         ↓ プロジェクト名として使用
コンテナ名:     yourname-wordpress_wordpress_1
                yourname-wordpress_db_1
ボリューム名:   yourname-wordpress_db_data
                yourname-wordpress_wp_data
ネットワーク名: yourname-wordpress_default

COMPOSE_PROJECT_NAME=yourname-nextjs
         ↓ プロジェクト名として使用
コンテナ名:     yourname-nextjs_app_1
ネットワーク名: yourname-nextjs_default
                （wordpress のネットワークに外部参加）

Step 6：コンテナ名・ネットワーク名を更新する

このステップが必要な理由を図で説明します。

【同じプロジェクト内：サービス名で通信できる】
[yourname-wordpress プロジェクト]
 wordpress コンテナ ──► db コンテナ
  （サービス名 "db" で参照可）
 ネットワーク: yourname-wordpress_default

【別プロジェクト間：コンテナ名 + 外部ネットワーク参照が必要】
[yourname-nextjs プロジェクト]
 nextjs コンテナ
  接続先: yourname-wordpress_wordpress_1
  （サービス名でなくコンテナ名で参照）
  使用ネットワーク:
    yourname-wordpress_default (external)
         ↓
[yourname-wordpress プロジェクト]
 wordpress コンテナ

COMPOSE_PROJECT_NAME を変えると、Dockerのデフォルトネットワーク名も連動して変わります（wordpress_default → yourname-wordpress_default）。Next.js の docker-compose.yml が古いネットワーク名を参照したままだと WordPress コンテナに接続できません。

# WORDPRESS_API_URL がどのファイルにあるか確認
grep -r WORDPRESS_API_URL /var/www/yourname/site/nextjs/

# .env.local に入っていた場合の更新
# ↓ この下3行を、そのまま一括してコピーして、貼り付けてください。（\ は省略不可）
NEW_URL="http://yourname-wordpress_wordpress_1/graphql"
sed -i "s|WORDPRESS_API_URL=.*|WORDPRESS_API_URL=${NEW_URL}|" \
  /var/www/yourname/site/nextjs/.env.local

# 確認
cat /var/www/yourname/site/nextjs/.env.local | grep WORDPRESS_API_URL

# 現在のネットワーク名を確認
grep -A10 "networks" /var/www/yourname/site/nextjs/docker-compose.yml

# ネットワーク名を更新
# ↓ この下2行を、そのまま一括してコピーして、貼り付けてください。（\ は省略不可）
sed -i 's/wordpress_default/yourname-wordpress_default/g' \
  /var/www/yourname/site/nextjs/docker-compose.yml

# 確認（yourname-wordpress_default が表示されればOK）
# ↓ この下2行を、そのまま一括してコピーして、貼り付けてください。（\ は省略不可）
grep "yourname-wordpress_default" \
  /var/www/yourname/site/nextjs/docker-compose.yml

Step 7：新しいボリュームを作成する

COMPOSE_PROJECT_NAME を変えるとボリューム名も変わります。起動前に名前だけ作っておき、次のステップでデータをコピーします。

docker volume create yourname-wordpress_db_data
docker volume create yourname-wordpress_wp_data

Step 8：ボリュームのデータをコピーする

古いボリュームのデータを確認してからコピーします。

docker volume ls
docker run --rm -v wordpress_db_data:/data alpine ls /data
docker run --rm -v wordpress_wp_data:/data alpine ls /data
# ファイルが表示されればOK

# DB データをコピー
# ↓ この下4行を、そのまま一括してコピーして、貼り付けてください。（\ は省略不可）
docker run --rm \
  -v wordpress_db_data:/from \
  -v yourname-wordpress_db_data:/to \
  alpine sh -c "cp -av /from/. /to/"

# 確認（ファイルが表示されればOK）
docker run --rm -v yourname-wordpress_db_data:/data alpine ls /data

# WP データをコピー
# ↓ この下4行を、そのまま一括してコピーして、貼り付けてください。（\ は省略不可）
docker run --rm \
  -v wordpress_wp_data:/from \
  -v yourname-wordpress_wp_data:/to \
  alpine sh -c "cp -av /from/. /to/"

# 確認（ファイルが表示されればOK）
docker run --rm -v yourname-wordpress_wp_data:/data alpine ls /data

コンテナ起動後に画像アップロードで Permission Denied が出る場合は、コンテナ内から権限を修正します：

# ↓ この下2行を、そのまま一括してコピーして、貼り付けてください。（\ は省略不可）
docker exec yourname-wordpress_wordpress_1 \
  chown -R www-data:www-data /var/www/html/wp-content/uploads

Step 9：コンテナを起動して確認する

WordPress から先に起動します。DBの初期化に10〜30秒かかる場合があります。

cd /var/www/yourname/site/wordpress && docker-compose up -d
docker ps
# Up になるまで待ってからブラウザで WP 管理画面を確認

# WP 管理画面が正常に開いたら Next.js を起動
cd /var/www/yourname/site/nextjs && docker-compose up -d
docker ps

コンテナ名が以下になっていればOKです：

# ▼ 出力例
yourname-nextjs_app_1
yourname-wordpress_wordpress_1
yourname-wordpress_db_1

表示されない場合はログで確認：

docker logs yourname-wordpress_wordpress_1
docker logs yourname-wordpress_db_1
docker logs yourname-nextjs_app_1

Step 10：デプロイコマンドを更新する

フォルダが変わったため、デプロイスクリプト・cron・CI/CD のパスを更新します。

# 変更前
cd ~/yourname && docker-compose pull && docker-compose up -d

# 変更後
cd /var/www/yourname/site/nextjs && docker-compose pull && docker-compose up -d

# cron の確認・更新（~/yourname や ~/wordpress を参照しているジョブがあれば更新）
crontab -l
crontab -e

# Nginx の設定確認
grep -rE "yourname|wordpress" /etc/nginx/sites-enabled/

Step 11：旧フォルダを削除する

rm -rf ~/yourname
rm -rf ~/wordpress

# 旧ボリュームも削除
docker volume rm wordpress_db_data
docker volume rm wordpress_wp_data

よくある失敗：ネットワーク名の更新漏れ

よく「フォルダをコピーしてコンテナを起動すれば移行完了」と思われます。 ところが実際に Docker Compose v1 環境でこの作業をすると、COMPOSE_PROJECT_NAME の変更に連動してネットワーク名も変わるという落とし穴があります。 Next.js の docker-compose.yml に wordpress_default というネットワーク参照がハードコードされていると、サイトは起動しているように見えて WP GraphQL への通信だけが失敗します。 このことを知っているかどうかで、原因調査に1時間かかるか5分で終わるかが変わります。

# ネットワーク名が正しく更新されているか確認
grep "networks" /var/www/yourname/site/nextjs/docker-compose.yml -A5

ロールバック手順

cd /var/www/yourname/site/nextjs && docker-compose down
cd /var/www/yourname/site/wordpress && docker-compose down

ConoHa コントロールパネル → 「シャットダウン」
→「イメージ」→「保存イメージ」→「復元」

# 復元後の確認
ssh yourname@xxx.xxx.xxx.xxx
docker ps
# 旧コンテナ名（wordpress_wordpress_1 等）で起動しているか確認

VPS の Docker Compose 構成を移行するときのチェックリスト

まずこの4点だけ確認すれば、移行後の典型的なトラブルはほぼ防げます。

• ✅ /var/www/ 以下に nextjs・wordpress フォルダが移動しているか
• ✅ .env に COMPOSE_PROJECT_NAME が明示設定されているか
• ✅ docker-compose.yml のネットワーク名が新しいプロジェクト名ベースに更新されているか
• ✅ デプロイスクリプト・cron のパスが新しいフォルダを指しているか

1つでも当てはまっていない項目があれば、本番稼働前に必ず確認してください。

まずはここから始めてみませんか？

自分で移行したい方へ

まずは tmux でセッションを保持した状態での作業 から始めてみてください。セッション保護なしでの移行作業は、SSH切断時に中断するリスクがあります。

プロに相談したい方へ

「自社のVPS環境を整理したいが、既存サービスを止めたくない」という方は、お気軽にご相談ください。現状の構成を確認した上で、ダウンタイムを最小化した移行手順を専門用語なしでご説明します。

私たち株式会社grandiosoは、関西エリアを中心に全国の中小企業・個人事業主の皆さまにホームページ制作やシステム開発をご提供しています。
この記事でご紹介した内容も、すべて当サイトで実際に運用しているものです。
相談は無料ですので、お気軽にお問い合わせください✨