WordPress、kusanagiでのアップデート

アップデート手順

システム構成

• AWS 上で CloudFront + ALB + EC2 + RDS の構成で運用中。
• SSL アクセラレーターは ALB
• RDS は毎日スナップショットを取れる運用。
• アップデート前には_AMI から検証用 Wordpress を別に構築する。

WordPress はアップデートに失敗すると、真っ白になったりする、と聞いたので 別サーバーを立てて検証してからアップデートを試みた方が良いと思う。

デフォルトの状態だとアップデートできなかった。

別サーバーを立てて検証中、怖い表示になった。本番とは別にサーバーを立てて検証してて助かった。

事前のステージング環境での確認

0. 作業前に対象ドメインの Wordpress で非公開のページを作っておく( これを目印にする )
1. RDS, EC2 をそれぞれバックアップから作成する
2. EC2 が参照する RDS を新しく作ったものに変更する
3. EC2 をロードバランサー配下に追加する

本番での作業の流れ

後述するが下記のような流れ

0. 作業前に対象ドメインの Wordpress で非公開のページを作っておく( これを目印にする )
1. RDS, EC2 をそれぞれバックアップから作成する
2. EC2 が参照する RDS を新しく作ったものに変更する
3. EC2 を新しく作ったロードバランサー配下に追加する
4. ローカル PC の/etc/hosts を修正し、対象ドメインを新しいロードバランサーの IP アドレスに変更する
5. 再度、アクセスし[0]で作った目印が「無い事」を確認する
6. アップデートの検証を行う
7. アップデートが正常にできたら EC2 をターゲットグループ内の EC2 インスタンスを新旧を入れ替える
8. [4]で /etc/hosts で追加した箇所をコメントアウト
9. 対象ドメインの動作を確認する

RDS のスナップショットから DB 作成

RDS、スナップショットリスト=>[システム]=>[前日のスナップショットのチェックボックスをオン]=>[アクション]=>[スナップショットを復元]

変更箇所は 3 点

• DB インスタンス識別子
• バースト可能クラス (t クラスを含む) => db.t3.small
• VPC セキュリティグループ <- デフォルトだと疎通できない

DB エンドポイントが決定されるのでメモしておく。

EC2 のバックアップイメージ(AMI)から起動

EC2 起動後、Wordpress の wp-config.php の DB 設定を変更。

sudo vi /home/kusanagi/ドメイン名/DocumentRoot/wp-config.php

• 事前に別ドメインで確認する場合は、WP_HOME , WP_SITEURL も変更
• DB_HOST の行を検証用 DB インスタンスのライターインスタンスに修正する。
• wp-config.php 中で ^M の余計な文字を削除する( vi で :%s/^M//gc で削除できる。 ^M は ctrl + v して ctrl + m で入力できる )参考

アップデート検証用に別ドメインを用意する場合

本番の場合は別 ALB を立てその配下に入れる必要があるが、 別ドメインにする場合、同じ ALB でルールを追加する形で別ターゲットグループに振り分けることができる。

Nginx で受け入れるドメイン名を追加する。

cd /etc/nginx/conf.d
cp -rp staging.example.com_http.conf www-update.example.com_http.conf
vi www-update.example.com_http.conf

下記のように server_name だけ変えるので良い。

server {
     listen 80;
     server_name www-update.example.com example.com;
     access_log  /home/kusanagi/www.example.com/log/nginx/access.log main;
     error_log   /home/kusanagi/www.example.com/log/nginx/error.log warn;

server_name の箇所をアップデート検証用ドメインに変更。 サーバーを再起動、ターゲットグループに追加。ALB のルールを適切なものに変更。 外部から curl で確認。

curl https://アップデート検証用ドメイン/

閲覧可能であれば管理画面にログイン( All in One Security などでログイン URL を変えていただ場合は変わる)

https://アップデート検証用ドメイン/wp-admin/

固定ページに何かページを追加すると、本番との違いが分かって便利。 例えば非公開で「開発用ページ」を作ってみて、

• 間違って本番サーバに繋がっていないこと。
• 管理ページを見ただけで、どちらで作業しているかはっきりする というメリットがある。

EC2 インスタンスをターゲットグループに追加、必要に応じてターゲットグループや ALB のルールの追加を行う。

本番での作業の流れ

上の方で書いたように ALB を立て、ターゲットグループに追加、ALB の IP アドレスを確認した上で、 作業用 PC の hosts ファイルにその IP アドレスを加えて 「作業用 PC で本番のドメインにアクセスした場合は、別 ALB を見る」ように設定する。

上手く接続できない場合

1. DB のアドレスは正しいか?( wp-config.php )
2. DB のセキュリティグループが default ではないか?( default は MySQL のポートを許可していない )
3. /etc/hosts は正しいか?( kusanagi は/etc/hosts を更新する )
4. ロードバランサーのルールに似たものは無いか?
5. ターゲットグループへの振り分けは正常か、ターゲットグループ内にインスタンスはあるか?( つまりサーバーまで疎通はできるのか?)
6. curl コマンドで目的の URL にアクセスする
7. アクセスするのは http か https か絶えず意識すること

Wordpress のアップデートを行う準備を行う。

通常の Wordpress の場合、 httpd:www の権限で Wordpress やプラグインを上書きしていく想定のようだが、 この場合、Apache、Nginx のプロセスの権限が奪われると HP が改ざんされてしまう。

kusanagi では kusagi:kusanagi というユーザー権限で書き換えていく。 (このため Apache、 Nginx のプロセス権限が奪われても改ざんされるリスクが減る ) 必要に応じてファイル、ディレクトリの権限を kusanagi:kusanagi に変更していく。

sudo kusanagi status
yum -y update
cd /home/kusanagi/ドメイン名/DocumentRoot
chown -R kusanagi:kusanagi wp-admin/ wp-includes/ *.php wp-content/languages wp-content/themes wp-content/plugins
chown -R httpd:www wp-content/plugins/siteguard/really-simple-captcha
chown -R httpd:www wp-content/plugins/all-in-one-wp-migration
chown -R httpd:www wp-config.php

yum -y update の時に

問題を回避するために --skip-broken を用いることができます。
これらを試行できます: rpm -Va --nofiles --nodigest

上記エラーが出たら下記でアップデートする

yum update --enablerepo=remi,remi-php56

上記「必要に応じて」としているのには悩みがある。 セキュリティ的には「全てのファイルを kusanagi:kusanagi に変更した方がよりセキュアではないか?」とも思う、 が、Web から実行されるような処理、かつ、ファイルを書き出す様なプラグインの場合、 所有者権限は httpd:www である必要がある。このため必要に応じてというポリシーにしている。 ( 実際に All in one migration のように所有者が httpd:www でないと動作に問題があるプラグインがあった )

あとは Web 管理画面に戻り、ひとつひとつアップデートを行う。

本番の切り替え

Route53 での DNS の切り替えで行う。CDN、CloudFront 等を使っている場合はオリジンサーバの切り替えになる。

参考

試行錯誤の記録です。得られた知見は上記に反映済み。

wp コマンドを使うと [Error: Strange wp-config.php file: wp-settings.php is not loaded directly. というエラー]

いくつかの要因で出る可能性があるようだ。

How to use wp-cli with a non-standard wp-config.php location Add global option (–config-path) to specify location of WordPress config file 設定ファイルの設置場所が異なる場合、問題が発生する場合がある。

私の場合、 yum update した後(つまり kusanagi は最新)で、wordpress がアップデートしてない、という状況で出た。 wordpress アップデート後、wp コマンドが動作するようになった。

「現在メンテナンス中のため、しばらくの間ご利用いただけません」というエラーが出た場合

アップデート時、全てのプラグインをアップデートする場合、時間がかかってタイムアウトする場合がある。 この場合、上記の表示でずっとメンテナンス中になった。 復旧方法だが

rm /home/kusanagi/ドメイン/DocumentRoot/.maintenance

で復旧した。 .maintenance ファイルを削除すれば良い。

kusanagi だとパーミッションが厳しい

2021/09 時点での作業。

【KUSANAGI 】WordPress のバージョンアップ(更新)ができない！そんなときの対処方法 kusanagi のパーミッションについて参考になった。通常の wordpress より厳しめに設定されてる( 個人的には良いことだと思う。少し面倒だけど必要なコスト) ただ一旦、アップデートのために

find . -type d -exec chmod 777 {} +
アップデート後
find . -type d -exec chmod 755 {} +

が勧められていた。確かにこれでアプデできるようになると思う。ただ私の環境で

find . -type d -exec ls -ld {} +

で確認してみると、私の環境だと追加プラグインなどのディレクトリで 777 のものがあった。 777 前提のプラグイン( あまり良いものだとは思えないのだが )がある場合、注意が必要かもしれない。

別のアプローチとして、_Wordpress がエラーメッセージを正しくだしてくれる、プラグインがエラーを握りつぶさない前提が必要だけど、 Web UI で出たエラーのファイルのパーミッションを順次変更していくというアプローチ。 ひとまず、これで修正が必要なファイルについて把握することにした。

アップデートは Web UI の[更新]->[WordPress 5.6.2 から WordPress 5.8–ja に手動更新できます:]から行った。

いくつか行ってみて、 wp-admin, wp-includes 配下、 DocumentRoot 配下の *.php は全て kusanagi:kusanagi になっている必要がありそう。かつ、 全てファイルの所有者が httpd:www だったので確実に元の所有者に戻せる。ので、所有者を変更する。

chown -R kusanagi:kusanagi wp-admin/ wp-includes/ *.php wp-content/languages wp-content/themes wp-content/plugins
chown -R httpd:www wp-content/plugins/all-in-one-wp-migration

ただしマイグレーションツールの All in One Migration は下記ディレクトリのファイルを更新できる必要がある。 つまり httpd:www である必要がある。

wp-content/plugins/all-in-one-wp-migration

ファイルをコピーできませんでした。: themes/twentytwentyone-ja.mo

というエラーが出た。 検索する

find . -name 'twentytwentyone-ja.mo'

./wp-content/languages/themes/twentytwentyone-ja.mo

テーマディレクトリの所有者も変更する必要がある。

デフォルトテーマは正常にできた。　まぁ予想内の振る舞い。

Snow Monkey テーマで失敗した。

Snow Monkey の更新中にエラーが発生しました: ファイルをコピーできませんでした。 /home/kusanagi/ドメイン名/DocumentRoot/wp-content/themes/snow-monkey/vendor/inc2734/wp-share-buttons/src/view/twitter/twitter.php

というエラー。 所有者の問題かな? と思ったが、所有者は kusanagi:kusanagi で大丈夫。

[root@ip-172-37-1-242 DocumentRoot]# ls -l wp-content/themes/snow-monkey/vendor/inc2734/wp-share-buttons/src/view/twitter/
合計 4
-rw-r--r--. 1 kusanagi kusanagi 682  9月  2 15:27 official.php
-rw-r--r--. 1 kusanagi kusanagi   0  9月  2 15:27 twitter.php

ディスクの空き容量を疑う。が、大丈夫だった。

[root@ip-172-37-1-242 DocumentRoot]# df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         1.9G     0  1.9G    0% /dev
tmpfs            1.9G     0  1.9G    0% /dev/shm
tmpfs            1.9G   17M  1.9G    1% /run
tmpfs            1.9G     0  1.9G    0% /sys/fs/cgroup
/dev/xvda1        30G  6.5G   24G   22% /
tmpfs            379M     0  379M    0% /run/user/1000
tmpfs            379M     0  379M    0% /run/user/0

[root@ip-172-37-1-242 DocumentRoot]# df -i
ファイルシス    Iノード  I使用    I残り I使用% マウント位置
devtmpfs         478763    279   478484     1% /dev
tmpfs            484831      1   484830     1% /dev/shm
tmpfs            484831    394   484437     1% /run
tmpfs            484831     16   484815     1% /sys/fs/cgroup
/dev/xvda1     15728064 148479 15579585     1% /
tmpfs            484831      1   484830     1% /run/user/1000
tmpfs            484831      1   484830     1% /run/user/0

twitter 連携はしないので大丈夫かと思うが… 途中で止まったとかだとやばい。 snow mokey のアップデートに失敗した後、下記の画面で止まった。

このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメール受信ボックスを確認してください。

WordPress のトラブルシューティングについてはこちらをご覧ください。

一旦、SnowMonkey テーマを別領域に退避すると表示はできるようになる。

cd /home/kusanagi/ドメイン名/DocumentRoot/wp-content/themes
mv snow-monkey/ /root/

別途 SnowMonkey のプラグインをダウンロードしてインストールするか… この原因だが、SnowMonkey のライセンスを投入していないだけだった。

kusanagi をアップデートする時に詰まった

sudo yum update しようとすると下記のエラー

問題を回避するために --skip-broken を用いることができます。
これらを試行できます: rpm -Va --nofiles --nodigest

厄介な依存関係だろうか… と思ったら対策があった。

KUSANAGI の Anacron が「libonig.so.105」でエラーになる原因 KUSANAGI モジュール更新情報

なるほど、こういうケースもありか。　 remi-php56 の中のパッケージに依存してるのか。

下記でアップデートする

yum update --enablerepo=remi,remi-php56