WordPressのサイトヘルスステータスでPHPバージョンが指摘される

　そもそもなぜ PHP のバージョンを上げるかと言うと、WordPressのサイトヘルスステータスで下記のようにPHPのバージョンが古いことが指摘されるようになったからです。

サイトがPHPの古いバージョン（7.2.13）を実行しており、更新をおすすめします

　また、たとえここで指摘されなかったとしても、PHP7.2系は2020年11月30日でセキュリティサポートが停止されますから、アップデートしておくに越したことはありません。

bitnami でインストールされた WordPress のPHPバージョンアップは難しい

　PHPやMySQLのバージョンアップであれば、Lightsailのインスタンスのディストリビューション（ubuntu）に合わせて所定のアップデート作業を行えばよいと考えていましたが、bitnamiでインストールされた PHP は、通常の構成ではなくbitnami用のディレクトリ構成となっており、アップデートするのであれば bitnami 丸ごと最新バージョンに上げる必要がありそうでした。それはそれで面白そうではあるので検証環境で試してみたいのですが、今回は確実な方法を取ることとしました。

Lightsailの新インスタンスを立ち上げ、WordPressのバックアップを復元する

　今回実施するのは、現行のインスタンスでコンテンツとDBのバックアップを取得しておき、それを新しいLightsailのインスタンスで復元する、という方法です。bitnamiの最新バージョンインストールを試すにせよ、検証環境の立ち上げは必要となるので、それならば別インスタンスへのバックアップによる移行を検証しつつ、バージョンアップ（新しいインスタンスでは各種ツールのバージョンが更新されている）を狙っています。

現行インスタンスでWordPressのコンテンツとDBをバックアップ

　まずは現行のインスタンスにSSHログインし、コンテンツとDBをバックアップします。

　なお、MySQLのrootユーザーのパスワードは

$ cat ~/bitnami_application_password

で確認できますので、確認しておきます。こちらのパスワードを使用してMySQLサーバーへログイン後、DB名を確認してDBをバックアップします。

バックアップのためのコマンドは

$ mysqldump --single-transaction -u root -p bitnami_wordpress > ~/bitnami_wordpress.dump

です。

なお、WordPressのコンテンツ側のバックアップは

$ tar acvf wp.tar.gz /opt/bitnami/apps/wordpress/htdocs/

で可能です。作成された wp.tar.gz と bitnami_wordpress.dump は、SCPなどでローカルに保存しておきます。続いて新しいインスタンスを立ち上げます。

新しいインスタンスにSSHログインして、PHPバージョンを確認してみましょう。

PHPが7.3に更新されていることが分かります。

バックアップからWordPressを復元する

　WordPressをバックアップから復元しますが、DBユーザーとして既に存在するWordPressのデフォルトユーザーをそのまま使用するため、予めWordPressのユーザーパスワードを控えておきます。

$ cat /opt/bitnami/apps/wordpress/htdocs/wp-config.php | grep DB_PASSWORD

　wp.tar.gz と bitnami_wordpress.dump を任意の場所（今回はホームディレクトリ）にSCPなどで格納しておき、展開とDBリストアを行います。

$ cd /
$ sudo tar ~/xvf wp.tar.gz
$ mysql -u root -p bitnami_wordpress < ~/bitnami_wordpress.dump

　上記コマンドでwp-config.php が上書きされてしまっていますので、控えておいたDBユーザーのパスワードを再度記載しておきます。

$ vim /opt/bitnami/apps/wordpress/htdocs/wp-config.php

　ここまで実行すれば、新しいインスタンス上でWordPressが動作するはずです。あとはDNSのAレコードなどを書き換えて、新インスタンスとドメインを紐づければ移行が完了します。なお、Aレコード変更前に直接新インスタンスのIPを指定するなどしてアクセスすると、Jetpackがセーフモードで実行されてしまいますが、これは別ドメインでJetpackが実行されているためで、Aレコードの書き換えが反映され、移行前のURLで新インスタンスへアクセスすれば解消されます。

　また、コンテンツかDBどちらかのバックアップ、復元が失敗するなどしてDBとWordPressが不整合となっていると、下記のような画像が表示されることがあるので注意してください。この場合は、復元手順にミスがないか確認し、ミスが無いのであればバックアップの作成からやり直すのが良いです。

まとめ

　いかがでしたでしょうか？このほか、bitnamiのロゴを消したり、証明書を旧インスタンスからコピーしたり、証明書更新用のLet’s Encrypt用cronタブを再設定したりと、面倒なこともありますので、次回はスナップショットからの検証環境立ち上げと、bitnamiの最新バージョンインストールによるバージョンアップが可能か、を検証していきたいと思います。

作業はWebターミナルで行う

　今回は簡単に進めるため、LightsailのダッシュボードからWebターミナルを起動します。オレンジ色の「>_」と表示されているボタンをクリックすればWebのターミナルが起動します。

　Webターミナルが起動しました。

　それでは証明書を更新していきましょう。Let’s Encrypt のインストールディレクトリに移動した後に、こちらのコマンドを実行すれば証明書の更新が確認できます。

$ sudo certbot-auto renew

　証明書が更新され、次回の有効期限は 2020/07/30 であることがわかります。（画像は更新後に再度実行したため、実際の更新ログが表示されていません）また、「./certbot-auto has insecure permissions!」という警告メッセージが表示されていますので続いてこれを解消していきます。

certbot-auto has insecure permissions を解消する

　「./certbot-auto has insecure permissions!」については、こちらの記事に解消方法が載っています
https://community.letsencrypt.org/t/certbot-auto-deployment-best-practices/91979/

1. 一般ユーザーに書き込み権限がないディレクトリに certbot-auto を配置すること（例えば /usr/local/bin など）
2. 所有者を root ユーザーにすること
3. パーミッションを 0755 （所有者のみが書き込み可能）に設定すること

まとめると、下記の一連のコマンドで解消できそうです。

$ sudo chown root:root certbot-auto
$ sudo chmod 755 certbot-auto
$ mv certbot-auto /usr/local/bin

上記を実施した結果、エラーが解消されました。

dry-run について

　なお、certbot-auto renew には –-dry-run のオプションが設定可能です。サーバーの設定を変更した後、事前にcertbot-auto renewで正しく証明書が取得、更新されるか確認したい場合は –-dry-run のオプション付きで実行しましょう。

　実際に–dry-runオプション付きで実行したところ、「Congratulations, all renewals succeeded. The following certs have been renewed:」と出力されているので、証明書の更新処理には成功することがわかります。

　さらに「DRY RUN: simulating」や「(The test certificates above have not been saved.)」という出力から、実際には証明書更新が行われないことがわかります。

　ここまでが、Lightsail上でLet’s Encryptの証明書を更新した際の作業記録でした。もちろん、Lightsail や WordPress に限定した話ではないので、他のVPSなどでも同様の手順で更新できると思います。次回は機会があれば、cron（クロン）による証明書の自動更新設定を解説します。