先日投稿した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ファイルに設定する
# -------------------------------------------
# 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をカスタムして利用しています。
せっかくなので、別の記事でそちらは紹介してみたいと思います。