先日投稿したWordPressのローカル開発環境とConohaVPS KUSANAGIをwordmoveを利用して同期してみようと思います。

Conoha VPS KUSANAGIにWordPressを立ち上げる

超高速でSSL設定も簡単。VPSなのに専用管理画面付きと至れり尽くせりのConoha VPS KUSNAGIでさくっとサイトを立ち上げます。

前提条件

ConohaVPSでKUSANAGI契約済み、認証鍵を利用したSSHができる環境を前提で進めます。

KUSANAGIサーバーでサイトを用意する

# ルートユーザーで操作
sudo su -
# updata
dnf upgrade -y
reboot

(再起動後ログイン)

# 初期設定の実行（適宜修正してください）
kusanagi init --passwd "パスワード" --nophrase --dbrootpass "パスワード" --nginx124 --php80 --mariadb10.6

(途中省略)

init completed.

WordPressを起動しますが、SSL証明書をセットしたい場合は、予め設定予定のfqdnにDNSのAレコードを向けておくと、SSLも同時に設定できます。仮に「mysite.zounode.com」で進めます。

#ルートユーザーで操作
sudo su -

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

kusanagi provision --wp --fqdn mysite.zounode.com --email "メールアドレス" --dbname mysite_db --dbuser mysite_db --dbpass "パスワード" mysite

(途中省略)

Provisioning of mysite completed. Access mysite.zounode.com and install wp.
provison completed.

WordPressのセッティングまで完了したので、インストールを行います。
先ほど設定したホスト名（FQDN）にブラウザでアクセスします。

管理画面に入れました。せっかくなので、サイト名やテンプレートなどでスタイリングしておきます。

ローカルサイトを立ち上げる

前回ご紹介したGithubからリポジトリをクローンします。

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

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

.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

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

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

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

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

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

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

wordmove push --all -e staging

無事リモートのKUSANAGIサーバー側も切り替わりました！

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

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

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

サーバーで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をカスタムして利用しています。
せっかくなので、別の記事でそちらは紹介してみたいと思います。