水たまりは希望を写している

KUSANAGI 8 から KUSANAGI 9 に移行してみた。migrate コマンドで楽々

高速CMS実行環境 KUSANAGI 8 から 9 へ

以前から使用していた KUSANAGI 8 だが、今年 6 月末で EOL ということもあり、新バージョンである KUSANAGI 9 に移行したい。しよう

基本的にはプライム・ストラテジーが公開しているドキュメントと同じ事をすれば簡単に移行できる。

移行元環境を更新 & プロファイルのエクスポート

移行元の KUSANAGI で、

yum update --enablerepo=remi,remi-php56

を実行してインストールされているパッケージを更新する。終わったら kusanagi restart する。移行先の KUSANAGI では MariaDB 10.5 が使用できるため、

kusanagi upgrade mariadb 10.5

というコマンドで MariaDB をアップグレードし、移行元の環境で正しく動作しているかをチェックする。

kusanagi target

というコマンドでプロファイルの一覧が取得できるので、

kusanagi migrate --export プロファイル名

というコマンドでプロファイルを書き出す。書き出したプロファイルは tarball として /home/kusanagi に保存される。
Let’s Encrypt を使用している場合、SSL の自動更新を止めるよう表示されるため、

certbot delete --cert-name FQDN

で止めることができる。

バックアップが完了すると、/home/kusanagi の直下はこのようになる。あとはプロファイルのバックアップを手元にコピーしておく。

移行先環境を準備 & プロファイルのインポート

移行先の KUSANAGI で init コマンドを実行する。

kusanagi init --passwd kusanagiユーザのパスワード --nophrase --dbrootpass DBのrootパスワード --php74 --mariadb10.5

移行元の KUSANAGI では PHP 7.4 が使用されていたので、バージョンを合わせることができるよう指定する。

KUSANAGI 9 からは kusanagi ユーザーでも各種コマンドが使用できるようになっているため (root を使用しなくて良い)、これからは kusanagi ユーザーで作業する。

また、KUSANAGI 9 からプロファイルの切り替えはカレントディレクトリ基準に切り替えることができるようになったので、プロファイル別にコマンドを変える際は、カレントディレクトリを変える。

/home/kusanagi にプロファイルのバックアップをアップロードし、下記のコマンドを実行する。

kusanagi migrate --import バックアップのファイル名

インポートが完了すれば、もう既に稼働しているような状態なので hosts などを使用して検証しても良いし、そのまま DNS のレコードを書き換えても良い。

Let’s Encrypt を使用している場合、DNS レコードを書き換えたら、カレントディレクトリを変更した後

kusanagi ssl --email メールアドレス

を実行して SSL の自動更新を再開する。

ハマったところ

PHP 8 系を使おうとすると WordPress のエラーが出る

kusanagi php --use php83

というコマンドで PHP 8.3 に切り替えることができるが、この後 WordPress が正しく動かなくなる

Deprecated: Creation of dynamic property ftp::$features is deprecated in /home/kusanagi/wangel/DocumentRoot/wp-admin/includes/class-ftp.php on line 151

Deprecated: Creation of dynamic property ftp::$features is deprecated in /home/kusanagi/wangel/DocumentRoot/wp-admin/includes/class-ftp.php on line 151

WordPress の悲痛な叫び

このようなエラーが出るっぽい。

この場合、wp-config.php にある define('FS_METHOD', 'ftpsockets');ftpsocketsftpext に変更する。

そして KUSANAGI の WordPress プラグインをアップデートする。カレントディレクトリを変更した後

kusanagi update plugin

を実行する。するとエラーは出なくなる。少なくとも僕の環境では。

HTTP/3 が使えない

Nginx の最新バージョンを使用していれば多分自動的に使える HTTP/3 だが、使えなかった。

これは KUSANAGI の問題ではなく、VPS のファイアウォールによる制限だった。

ConoHa のコンパネでセキュリティグループを追加して、画像のように UDP 443 のポートを許可する。Chrome の開発者ツールのネットワークタブで、HTTP/3 で通信しているかどうかを確かめることができる。プロトコル欄が h3 だと HTTP/3。

AVIF のキャッシュを利かせたい

/etc/opt/kusanagi/nginx/conf.d/static.inc の中身を見てみる。

# static files
location ~* \.(jpg|jpeg|gif|png|webp|css|js|swf|ico|pdf|svg|eot|ttf|woff|woff2)$ {
    expires $expire_days;
    access_log off;
}

というように、avif が入っていないので webp の後ろとかに追加してやる (root で)。

kusanagi nginx --test 

で設定ファイルをテストして、問題がなければ

kusanagi nginx

で再起動。

画像のキャッシュを長くしたい

デフォルトだと 90 日で PageSpeed Insights から怒られるので、

cd /etc/opt/kusanagi/nginx/conf.d 

で設定ファイルがあるフォルダに移動して (root で)、

grep -l '90d' ./* | xargs sed -i -e 's/90d/365d/g'

でプロファイルすべての日数を変更する。この場合 90 日から 365 日 に変更している。

設定ファイルをテストして、問題がなければ再起動。

ダッシュボード内「セキュリティ状況」の警告を削除

移行元ではオールクリアーな状態だったが、また戻っているので対処する。

chmod 0775 wp-content/
chown kusanagi.www wp-content/

をドキュメントルートで実行 (root で)。