Conoha VPS KUSANAGIのWordPressとローカルWPをwordmoveで同期

2024年6月12日

By Murodon

WordPressのローカル開発環境について

開発環境でWordPressが使えるようになりましたが、サーバー側と同期できれば、便利ですね。

Conoha VPSでWordPressを立てる

■ 世界最速級 WordPressならConoHa VPS｜VPSならConoHa
https://www.conoha.jp/vps/kusanagi/

クイックスタートの内容に従って、初期設定後、ConohaVPS内にWordPressを立ち上げます。

■ KUSANAGI 9クイックスタート – 超高速CMS実行環境 KUSANAGI
https://kusanagi.tokyo/document/kusanagi-quickstart/

sudo su -
dnf upgrade -y
reboot

(再起動後)
kusanagi init --passwd "パスワード" --nophrase --dbrootpass "パスワード" --nginx124 --php80 --mariadb10.6

(途中省略)

init completed.

KUSANAGI9プロビジョニング

クイックスタートの内容に沿ってWordPressをプロビジョニングします。

kusanagi provision --wp --fqdn www.example.com --email kusanagi@example.com --dbname kusanagi_db --dbuser kusanagi_db --dbpass "パスワード" "任意のプロファイル名"

(途中省略)

Provisioning of "任意のプロファイル名" completed. Access www.example.com and install wp.
provison completed.

DNSのAレコードをサーバーに向けておきましょう。

KUSANAGIユーザーをsshでログインできるように変更

passwd kusanagi
パスワード設定

WordPress初期設定

さきほど設定したfqdnのドメインにアクセスし、WordPressの初期設定を行う。

サイトができました。すこしスタイリングしておきます。

ローカルサイトを用意する

git clone git@github.com:murodon/docker-wp-local.git local-site
cd local-site

mkcertでcertsフォルダにssl証明書を用意し、.envファイルに設定する

# -------------------------------------------
# wordpress PROJECT_SETTING
# -------------------------------------------
# PROJECT NAME 接頭辞に使用
PROJECT_NAME=local-wp
# SUFFIX PROJECT_NAME.SUFFIXでホスト名を作成する
SUFFIX=proto
# TIMEZONE
TIMEZONE=Asia/Tokyo
# mkcertの証明書名(.より前)
CERT_NAME=localhost+2

一旦ローカルサイトも立ち上げておきます。

docker-compose build
docker-compose up -d

sshフォルダに証明書をセット

クローンしたディレクトリにあるsshフォルダへ「config」と「id_rsa」を作成します。

📦ssh
 ┣ 📜.gitkeep
 ┣ 📜config
 ┣ 📜id_rsa
 ┗ 📜known_hosts

Configファイル

Host、HostName、PortなどKUSANAGIサーバーとのSSH接続の設定をします。

Host mysite <-　ホストのエイリアス名
 HostName "サーバのIPアドレス"
 Port "サーバーのSSHポート"
 User kusanagi
 IdentityFile ~/.ssh/id_rsa
 TCPKeepAlive yes
 IdentitiesOnly yes

Host *
 IgnoreUnknown UseKeychain,AddKeysToAgent
 AddKeysToAgent yes
 UseKeychain yes

id_rsa

KUSANAGI VPSと接続に使用している認証鍵ファイルを~/.sshのオリジナルファイルからコピーします。

-----BEGIN OPENSSH PRIVATE KEY-----
(省略)
-----END OPENSSH PRIVATE KEY-----

wordmoveの設定

フォルダ直下の.envへ設定を追加します。

# -------------------------------------------
# WORDMOVE
# https://github.com/welaika/wordmove
# -------------------------------------------

# WordMoveのmovefile.ymlに設定する内容
# LOCAL_VHOST=https://local-wp.proto
LOCAL_VHOST=https://local-wp.proto

# ssh/confgファイルに設定したホストエイリアス
CONFIG_HOST=mysite

STAGING_VHOST="KUSNAGIのFQDM"
STAGING_WORDPRESS_PATH=/home/kusanagi/mysite/DocumentRoot # KUSANAGIのWordPress格納ディレクトリ
STAGING_DB_NAME=mysite_db
STAGING_DB_USER=mysite_db
STAGING_DB_PASSWORD="KUSANAGIで設定したDBのパスワード"
STAGING_DB_HOST=localhost
STAGING_SSH_HOST="サーバのIPアドレス"
STAGING_SSH_USER=kusanagi
STAGING_SSH_PORT="サーバーのSSHポート"
STAGING_SSH_KEY=id_rsa

docker-composeを再ビルドして、変数をWordmoveコンテナに読み込ませます。

docker-compose down
docker-compose build --no-cache
（しばらく待つ）
docker-compose up -d

wordmoveコンテナで操作

wordmoveコンテナにexecで入ります。

# コンテナ名はdocker psなどで確認してください。
docker exec -it -w /root/wordmove local-wp_wordmove /bin/bash

envコマンドで値を確認

env | grep STAGING

設定されているようです。

sshでサーバーにアクセスできるか確認

初回はid_rsaのパーミッションを確認したほうが良いようです。

ls -la ~/.ssh

root@a093525ce008:~/wordmove# ls -la ~/.ssh
total 16
drwxr-xr-x 6 root root  192 Jun 11 08:45 .
drwx------ 1 root root 4096 Jun 11 08:43 ..
-rw-r--r-- 1 root root    0 Jun 11 08:38 .gitkeep
-rw-r--r-- 1 root root  226 Jun 11 08:41 config
-rw-r--r-- 1 root root  411 Jun 11 08:46 id_rsa
-rw-r--r-- 1 root root  222 Jun 11 08:45 known_hosts

# 644になっていることが多いので、６００に変更します。
chmod 600 ~/.ssh/id_rsa

# configに設定したホストエイリアスで接続をテストします。
ssh mysite

ロゴが見えれば疎通完了。リモートサーバーからはexitで出て、コンテナに戻ります。

wordmove

まずは設定値があっているか確認します。
movefile.ymlのあるフォルダで「wordmove doctor」コマンドで調査します。

cd /root/wordmove
wordmove doctor

赤い項目が無いかチェックしましょう。

さっそくwordmoveを試しますが、まずはドライラン(-s)で動作チェックします。

wordmove pull --all -s -e staging

下に同期される内容が表示されます。テストなので、項目が見えるだけです。それでは最後に同期させてみます。

wordmove pull --all -e staging

コマンドが最後までエラーなしで進めば成功です。

ローカルサイトを開いてみます。

MySiteZounode_–_Just_another_WordPress_Test_Site.png

KUSANAGIサーバーの表示と同じ内容になっています。

サーバー側の管理画面でインストールしたテーマが表示されました。
今度はローカル側でテーマをインストールします。

データベースも連携した場合、ローカルサイト側管理画面のユーザーはKUSANAGIサーバーで設定したユーザーのアカウントになっています。

すごい適当です。
これをサーバー側に同期してみます。

wordmove push --all -e staging

無事切り替わりました！

KUSANAGI環境でwordmoveする際の注意点

pull/push -allは避けたほうが良い

KUSANAGIを利用する場合、管理画面に管理用のメニューが表示されています。

ダッシュボード_‹mysite-elephantnode—_WordPress.png

サーバーでWordPressをプロビジョニングすると、自動的にインストールされるプラグインなのですが、普通のプラグインと違って、wp-content直下のmu-pluginsにインストールされます。

ローカル環境に立ち上げたWordPressは初期状態でこのプラグインはありませんので、最初にpull -allすればローカルにもインストールされますが、間違えて最初にpush –allすると、プラグインが消えちゃいます。
こうなると、KUSANAGI側で一度別のサイトを立ち上げてそこからコピーする羽目になります。

プラグインとデータベースの同期も慎重に

データベースの値を利用するプラグインなどがある場合、まるっと同期してしまうとプラグインがエラーを起こしたり、逆にデータベースの値が、管理プラグインが無くなったことで残り続けてしまったりします。

こうなるとエラーの解消に時間が掛かったり、将来的に管理が難しくなったりします。テンプレートにも言えることではありますが、管理画面も落ちてしまうようなエラーが出る可能性のあるプラグインはwordmoveで扱うのが難しいです。

本番環境はバックアップを忘れずに

wordmove自体、バックアップ目的のツールではありますが、手動でテンプレートやDBを予め取っておくことをお薦めいたします。

Conoha VPSのKUSANAGIはなんとKUSANAGI Managerで自動バックアップ付きです。ほんと便利。

この環境のwordmoveについて

Quiitaの記事作成時にしばらくやっていなかったwordmoveのデータベース同期を試しました。なぜか一向にうまくいかないので、いろいろと試した結果、本家のgemでインストールしたwordmoveでは、私の使用している認証鍵やmaria dbの最新版に対応できなくなっていることがわかりました。

そのため、本家のレポジトリからフォークしたwordmoveをカスタムして利用しています。

■ murodon/wordmove_custom: Multi-stage command line deploy/mirroring and task runner for WordPress. Custom Version for Conoha Kusanagi.
https://github.com/murodon/wordmove_custom