KUSANAGI 8 から KUSANAGI 9 に移行してみた。migrate コマンドで楽々
以前から使用していた 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');
の ftpsockets
を ftpext
に変更する。
そして 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 で)。