WordPress on Lightsail のバージョンアップをしてみた。

 Lightsail の WordPress のバージョンが 5.6.0 になっていたので当サーバーを新しいバージョンのインスタンスに切り替えることにした。

バージョンアップのモチベーション

 WordPress のバージョンを上げること自体は、WordPress の管理画面から行うことが出来るが、Lightsail のインスタンス作成時(イメージ)のバージョンが上がると、WordPress だけではなく、PHP や Apache といったミドルウェアのバージョンも上がっているのだ。ソフトウェアのバージョンアップは、機能・パフォーマンスの改善やセキュリティの向上などメリットは非常に大きい。ただバグが潜んでいる可能性もあるが。

 Lightsail の WordPress の正体は、Bitnami WordPress という WordPress に必要なミドルウェアなどの必要なものをパッケージングし使いやすくしたアプリケーションなのである。WordPress のバージョンが上がったというよりかは Lightsail のイメージにインストールされた Bitnami のバージョンが上がったと言った方が正しい。

 WordPress 自体のバージョンアップは前述のように可能だが、PHP などのミドルウェアのバージョンは Bitnami にパッケージングされいるため容易には上げることが出来ないらしい。Bitnami の中の人も以下のように言っている。

Updating single components of our stacks is not possible because we build them all together to ensure they will properly work.
We recommend you to create a new server with latest versions and then migrate your application data. 

How can I update my PHP version. My wordpress site health is saying update php. When I checked it shows php 7.3 version

 Bitnami 自体のバージョンアップ方法をドキュメント内で探したのだが全然見つからなかったので、現在のインスタンス内のソフトウェアのバージョンアップではなく、5.6.0 の新しいインスタンスを作成して現在のインスタンスと切り変えることにした。

Lightsail のバージョンアップの最大のモチベーション

PHP や Apache 等の Bitnami に組み込まれたソフトウェアのバージョンアップ

なおこちらにそれぞれのバージョンに組み込まれたソフトウェアのバージョンが記載されている。今回の 5.6.0 の場合、主要なソフトウェアのバージョンは以下のようになる。特に PHP は脆弱性 CVE-2020-7070 を解消しているバージョンである。

5.6.0 の主要なソフトウェアのバージョン

  • PHP 7.4.13
  • Apache 2.4.46
  • MySQL 8.0.22

インスタンスの切り替え方法

 当サーバーは CloudFront のディストリビューションを前段に置いているので、切り替えは以下のように新しいバージョンのインスタンスを作成し CloudFront のディストリビューションのオリジンを切り替える形で行う。もしディストリビューションが前段に無かった場合は DNS レコードを書き換える等して切り替えることになるだろう。

 上述した通り Bitnami の中の人が言っているように今回はこのようにしてバージョンアップを図るが、この方法には以下のようなメリットとデメリットがある。

メリット

  • 新しいインスタンスでの作業が既存のインスタンスに何も影響を与えない。
  • 新しいインスタンスに何か問題があった場合の切り戻しが容易である。
デメリット

  • 作成から切り替え、廃棄までにコストが倍に増える。
  • データや設定等移行漏れの可能性がある。

 独身奇族的に一番のメリットは切り戻しの容易さ。どんなに事前の動作確認をしても切り替えてトラフィックが流れてきて初めて気づく問題はある。そのような問題が起きた場合に、正常に動いていたインスタンスは残っているのですぐに切り戻しが出来るのが最大のメリットだと思っている。

 コストは規模によってはなかなかインパクトがある場合もあるだろう。しかし作成時はインスタンスタイプを安価なものにして切り替えの直後に本来のものに変更する等で抑えることが出来るだろう。またデータや設定の移行漏れは、切り替え前後での動作確認は勿論、古いインスタンスを廃棄する前にスナップショットを取得すればデータの喪失といった最悪の自体は回避出来る。

切り替えまでの準備

新規インスタンスの立ち上げ

 普通に立ち上げるだけ。しかし若干の問題が。
 インスタンスの名前はユニークである必要があり、かつ作成後には変更出来ないのだ。なので独身奇族のようにインスタンス名にドメインをそのまま付けていると二台目のインスタンスの名前に非常に困る。だいたいドメインは一個だけどその裏のインスタンスが複数になることだってあるのだから、やっぱりこの名前は適切ではない。

 今後のリソース拡張を考えて汎用性のある名前にしても良かったが、汎用性を高めるとそれだけ冗長な名前になりそうだし、そもそも拡張することなんて無いだろうってことで、今回の作業がバージョンアップということを踏まえて以下の画像のような名前にしてみた。

 また今回はインスタンスにしっかりとタグを付与してみた。AWS のリソース管理にタグは必須である。ただ一台だけ(今は切り替える前なので2台だが)しかないインスタンスにタグを付与するメリットはあるのか・・。

 念の為各種ソフトウェアのバージョンが意図したものになっているかも確認しましょう。

$ wp core version
5.6.1

5.6.1 ….だと….
どうせ後で上げるだろうし問題なしかな。

$ apachectl -v
server version: Apache/2.4.46 (Unix)
Server built:   Dec  1 2020 10:39:20
$ php -v
PHP 7.4.13 (cli) (built: Dec  1 2020 10:42:31) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
   with Zend OPcache v7.4.13, Copyright (c), by Zend Technologies
$ mysqld --version
/opt/bitnami/mysql/bin/mysqld.bin  Ver 8.0.22 for Linux on x86_64 (MySQL Community Server - GPL)

インスタンス変更による副産物

その他にも新しいインスタンスについて調べてみたら色々と変わっていることが分かった。
まず OS が Ubuntu から Debian に変わっていた。マジかw

$ uname -a
Linux ip-172-26-5-93 4.4.0-1111-aws #123-Ubuntu SMP Sat Jul 4 02:03:15 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

$ uname -a
Linux ip-172-26-3-29 4.19.0-13-cloud-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux

さらに CPU までも。(一部出力を省略)

$ lscpu
Architecture:          x86_64
(略)
Model name:            Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz

$ lscpu
Architecture:        x86_64
(略)
Model name:          Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz

 CPU モデルは、こちらの記事によると古いインスタンスのものは t2 タイプに搭載されているもので、新しいインスタンスのものはいくつかのタイプで搭載されているようだが、いずれも t2 タイプよりは良いスペックのものになっている。Lightsail も恐らくはその実体は EC2 だと思われる(そういったドキュメントは見当たらないが)ので、恐らくは HW の性能が上昇していると思われる。どのくらいの性能差かは分からないが Lightsail の値段は変わっていないのでこれはお得??

データの移行

 こちらは WordPress の投稿や画像などの移行で、プラグイン「All-in-One WP Migration」を使いました。ファイルサイズが 512MB 以上になると有償版を購入する必要がありますが、今回は 400MB ほどで収まったので無償版で済みました。

 ただ次回の移行時には無償版のサイズを超えてるかもしれない。バックアップサイズを一番大きく占めているのが画像ファイルである。今はローカルストレージに保存しているが、これを外部、例えば S3Bucket などに配置することが出来れば移行のコストは抑えられそう。ただ S3Bucket の利用料金は発生するし、有償版も買い切り $69 ではあるので(安くはないけど)、次回の移行時に考えよう(先送り)。

 ちなみにインポートの際、アップロードサイズが 40MB となっていて、「512MB まで無料じゃないんか!!」って思ったら単なる PHP 側の設定値(post_max_size, upload_max_filesize)のせいでした。アホでした。

動作確認

 データの移行が終わったら動作確認です。一番簡単なのは新しいインスタンスにアタッチされている ElasticIP をブラウザに打ち込んで確認することです。しかし通常は FQDN を打ち込んでくるはずです。出来るだけ本番に似た環境で動作確認をするために、お使いの PC の hosts ファイルを編集してアクセスしてみましょう。
 ただし インスタンスには SSL 証明書がインストールされていない場合(前段に CDN がある場合は、ほとんどのケースでインスタンスには SSL 証明書はインストールされていないと思うので)、ブラウザで SSL 証明書のエラーが発生します。ひとまずエラーを無視して進みましょう。従って hosts を書き換えても完全な動作確認にはなりません。やらないよりはマシな程度です。
 なお動作確認をしたら hosts ファイルをしっかりと戻しておきましょう。独身奇族は戻すのをよく忘れます。

 確認すべき項目は以下のような感じでしょうか。

確認したい項目

  1. ページが表示されるか。
  2. コメントは投稿可能か。
  3. 管理画面にログイン出来るか。
  4. 記事を投稿出来るか。
  5. 記事を修正出来るか。
  6. 記事のプレビューが表示されるか。

インスタンスの切り替え

 新しいインスタンスを構築し、データを移行し、正常な動作を確認出来たら CloudFront のディストリビューションのオリジンを新しいインスタンスに切り替えましょう。だいたい20分程度で切り替わるはずです。以下のコマンドを新旧のインスタンスにログインしてアクセス状況を確認してみましょう。だんだん新しいインスタンスへのアクセスが増えていくはずです。

$ tail -f /opt/bitnami/apache2/logs/access_log

 自分でも動作確認をして問題なければ、古いインスタンスはスナップショットを取得して削除してしまいましょう。Lightsail は停止しても料金が発生するので料金の発生を停止するには廃棄しかありません。ただし切り替え後ある程度時間が経ってから問題が発覚する場合もあるので心配であれば古いインスタンスを残しておくのも手です。ただ切り替え後すぐに見つからないような問題は切り戻しが必要なほどのインパクトなものである可能性は低く、新しいインスタンス内で解消するのも手です。

移行後見つかったドラブル

2件、移行後に見つかったトラブルがあった。

編集画面の画像が表示されない。

1件目の症状は以下の通り。症状からしてインポート時に問題があった可能性が高い。FQDN で管理画面に接続し再度インポートしたら解消することが出来た。

トラブルの症状

  • 記事編集の画像だけが表示されない。
    メディアやプレビュー、公開記事では画像が表示される。
  • 新規の画像はアップロード・表示が出来る。
  • 画像の URL のホストがインポート時のサーバーの IP アドレスになっている。
解消方法

FQDN で管理画面にログイン(移行後に普通にログイン)し、再度インポートする。

編集画面に遷移するとエラーが出て編集出来ない。

 2件目も編集画面だが、こちらは上記より深刻。そもそも編集画面を開けないのだ。また発生したトリガーもよく分からず、移行後数時間ぐらい経過して確認された。原因は Cookie の有効期限切れ?ただ Chrome のシークレットモードや別のブラウザでは問題がないので、キャッシュや Cookie が悪さしている可能性があった。Chrome でキャッシュと Cookie を削除したら解消した。

トラブルの症状

編集画面に遷移するとエラーとなり、編集画面が開けない。エラーは以下の通り。

TypeError: Cannot read property 'authorId' of undefined
    at Ho (https://doc-sin.life/wp-includes/js/dist/editor.min.js:7:79588)
    at we (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:84:293)
    at zj (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:226:496)
    at Th (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:152:223)
    at tj (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:152:152)
    at Te (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:146:151)
    at https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:61:68
    at unstable_runWithPriority (https://doc-sin.life/wp-includes/js/dist/vendor/react.min.js:26:340)
    at Da (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:60:280)
    at Pg (https://doc-sin.life/wp-includes/js/dist/vendor/react-dom.min.js:61:14)
解消方法

Chrome の設定からキャッシュ及び cookie を削除する。
「設定」->「閲覧履歴データの削除」->「Cookie と他のサイトデータ」と「キャッシュされた画像とファイル」にチェックを入れて「データを削除」