Amazon Lightsail+WordPressのPHPやApacheを更新する

このブログはAmaozn Lightsail上の一番安価な仮想サーバ上でWordpress+Apache HTTP Server+MariaDBという組み合わせで動いているのですが、全てを自分でセットアップしたわけではなく、Lightsailで用意されているWordPress Certified by Bitnamiを使っています。簡単にWordpress環境が利用できるのですが、インストール後は定期的にWordpress、PHP、Apache、MariaDB等の更新をしていく必要があります。その更新方法についての記録です。

セットアップされるWordpress環境とその更新範囲

Lightsailの仮想サーバでは、素のOS環境を利用することも可能ですが、上の図にあるように各種ソフトウェアがセットアップ済の状態で起動させることも可能です。このブログでは WordPress Certified by Bitnamiを使っています。なお、同じ(と思われる)仮想マシンイメージ(AMI)がAWS Marketplaceでも提供されていますので、Amazon EC2環境でも同様に利用可能です。

執筆時点の最新のWordpress 5.8.2-4を例にとると、OSはDebian 10を使用しています。OSに含まれる各種パッケージは定期的に更新されるようセットアップされるので、この更新を気にする必要はあまりありません。しかしWordpressを構成する重要なコンポーネントであるWordPress本体、PHP、RDB(MariaDB)等は自動的な更新の対象になりません。これらはDebianの標準パッケージを使わず/opt以下で独自に管理されているためです。

~$ ls /opt/bitnami/
apache   bncert       bndiagnostic            bndiagnostic-tool  common        gonit    mysql  php         properties.ini  stats  varnish    wp-cli
apache2  bncert-tool  bndiagnostic-regex.ini  brotli             ctlscript.sh  mariadb  nami   phpmyadmin  scripts         var    wordpress

例えばPHPやApacheを/optに置かずに、OS標準のパッケージを使うという方法も考えられますが、OS側でパッケージが更新された時にWordpressの動作に不具合が出てしまう可能性がありそうです。多くの部分はOSのパッケージ更新を活用しつつ、Wordpressに必須のコンポーネントだけは独自管理するというのはリーズナブルな選択でしょう。

このような構成のため、/opt以下はユーザ側で更新する必要があります。Wordpressはそれ自体に更新機能があるため、マイナーバージョンの更新は自動更新できます。一方でApache HTTP Server、PHP、MariaDBは手動で更新する必要があります。

前提となる環境

前提となる環境は、Amazon Lightsailで1つのインスタンスをBitnamiのWordpressイメージベースで起動し、固定IPアドレスを付けただけのシンプルなサイトです。このサイトでは加えてAmazon CloudFrontを使用してSSL化とキャッシュによる高速化(インスタンスへの負荷低減)を行っていますが、このエントリの内容はCloudFrontの部分には関係しません。

更新の方法

追記(2022/1/2):移行した後、サイトの表示には問題が無いのに、過去に投稿したエントリを編集しようとすると、画像のURLがドメイン名ではなくIPアドレスになってしまう現象が出たので対処方法を末尾に追記しました。

Bitnamiは詳細なドキュメントが整備されていますし、コミュニティサイトでのQ&Aも活発ですので、情報を得やすいのが素晴らしいですね。ドキュメントを調べたところ/opt以下のソフトウェアについては、現状ではインプレースでの更新はできない(サポートされていない)ようです。つまり、いったん新しいLightsailサーバを最新のWordPress Certified by Bitnamiイメージで起動し、旧サーバからデータをマイグレーションする必要があります。

余談ですが、もしかしたら今後はインプレース更新可能なように改善されるのかもしれません。Bitnamiイメージのディレクトリ構成はバージョンによって少しづつ変わってきているのですが、最近のバージョンではルートに/bitnamiというディレクトリができ、ここにユーザーデータ(MariaDBの表データとかWordpressのwp-contentとか)が格納されるようになっているためです。以前は/opt以下に全部入っていたのですが、このように変わったことで、ユーザーデータを維持したまま/opt以下の入れ替えがしやすくなったように思います。

$ ls /bitnami/
mariadb  phpmyadmin  wordpress

$ ls /bitnami/wordpress/
wp-config.php  wp-content

旧Lightsailインスタンスのバックアップ

更新の最初のステップとして、旧インスタンスで手動スナップショットを取得します。操作としてはスナップショットの名前を入れて作成ボタンを押すだけです。

手動スナップショットをとることで作業直前の状態にいつでも復旧できるようになりますし、この後旧インスタンスを消しても手動スナップショットは残りますので(インスタンスを削除すると自動スナップショットも消まえます)、ここで手動スナップショットを取得しておくことは重要です。

手動スナップショットが取得できたら、Wordpressに管理者でログインしてマイグレーションに不要なものを削除するのもお勧めです。例えばインストールしたけど使っていないテーマやプラグイン等は削除しておくことでマイグレーション対象のファイルサイズを縮小できます。

旧LightsailインスタンスからWordpressデータをエクスポートする

WordPressのデータのエクスポート方法は色々な方法があるようですが、BitnamiのドキュメントではAll-in-One WP Migrationプラグインが推奨されているので、こちらを使います。最近のWordPress Certified by BitnamiイメージではデフォルトでAll-in-One WP Migrationが導入済になっているので、有効化するだけで使えます。

エクスポートは、All-in-One WP Migrationのエクスポートメニューでエクスポート先にファイルを選択するだけです。少し待つとアーカイブされたファイルがダウンロード可能になりますので、ローカルPC等にダウンロードします。私の環境では137MBのファイルになりました(非圧縮のファイル)。

※補足:ダウンロードボタンを押してもダウンロードが始まらない場合は、右クリックでアーカイブファイルのURLを確認して、wgetコマンド等で別途取得することが可能です。また、サーバ上の/wp-content/ai1wm-backups/以下にアーカイブが作成されるので、それをSFTPで取得することも可能です。

なおこのAll-in-One WP Migrationは無料版(コミュニティ版)では最大512MBまでサポートするそうなので、それ以上のサイズの場合は有償版を購入するか、エクスポート時の指定でメディアライブラリをエクスポート対象から外し、/wp-content/uploads/のファイルを手動でコピーする等で対応するのが良いと思います。

新しいLightsailインスタンスを起動する

これは通常通りなので、特に難しいところは無いと思います。 最新のWordPress Certified by Bitnamiイメージを選択し、インスタンスプラン(仮想サーバのサイズ)を選択するだけです。また、自動スナップショットの有効化はONにする事をお勧めします(サーバ起動後にも設定できます)。

こうすることで毎日ディスクのバックアップが取得され、7世代(一週間分)維持されます。7世代も保存すると費用が心配と思われるかもしれませんが、スナップショットは増分(差分)で保存されるので実際の請求はそんなに大きくなりませんし、バックアップがあれば何か設定ミス等でトラブルがあってもすぐに前日の状態に戻すことが可能になります。

ご参考までに、このサイトで利用しているのは一か月3.5ドルの最小の仮想サーバで、この価格に20GBのSSDがバンドルされているのですが、スナップショットの請求はだいたい月0.5~0.6ドルぐらいです。(ブログを投稿していなくてもOSやWordpressの更新によってストレージ差分は日々少しづつ発生します)

なお固定IPアドレスを新たに作成する必要はありません。これは旧Lightsailインスタンスにつけている固定IPアドレスを後から新インスタンスに付け替えるためです。

新インスタンスのWordpressにログインしてインポート

新LightsailインスタンスにSSHログインし、以下のコマンドを実行してアプリケーションパスワードを確認してメモします。この後でWordpressにログインする際に利用するパスワードです。

$  cat bitnami_application_password

次に、PHPの設定を変更します。今回使ったイメージではデフォルトではPHPのファイルアップロード設定の最大サイズが80MBになっているため、マイグレーション用にphp.iniを編集して最大サイズを大きくします(ドキュメントはこちら)。php.iniを更新したらctlscript.shコマンドでサーバをリスタートします。

$ cp /opt/bitnami/php/etc/php.ini ~/php.ini-bak
$ sudo vi /opt/bitnami/php/etc/php.ini

※以下2箇所を更新
upload_max_filesize = 200M
post_max_size = 200M

$ diff /opt/bitnami/php/etc/php.ini ~/php.ini-bak
694c694
< post_max_size = 200M
---
> post_max_size = 80M
846c846
< upload_max_filesize = 200M
---
> upload_max_filesize = 80M

$ sudo /opt/bitnami/ctlscript.sh restart

なお、php.iniの位置はBitnamiのバージョンによって異なるので、上記位置に無い場合は find /opt -name 'php.ini'等で探すのが良いでしょう。

付与されたパブリックIPアドレスにブラウザでアクセスすると、初期状態のWordpressが起動している事が確認できます。次に http://パブリックIP/wp-admin/にアクセスします。初期状態ではuserという名前でWordpressの管理ユーザが登録されていますので、先ほどのアプリケーションパスワードでログインします。

管理画面で導入済みプラグインを確認すると、All-in-One WP MigrationだけでなくJetPackや著名なプラグインが多数導入されていますが、JetPack以外は有効化はされていないので、 All-in-One WP Migrationを有効化(Activate)し、 All-in-One WP Migration メニューからインポートを選択します。

先ほどローカルにダウンロードしたファイルを選択してアップロードすると環境がリストアされます。

リストアの後は、パーマリンク構造の確認が必要になるので、上記「パーマリンク構造を保存する」をクリックすると、再度ログインが求められます。すでに環境がリストアされているので、旧環境の管理ユーザ、パスワードでログインしてください。 パーマリンク構造を確認し、問題無ければ「変更を保存」します(特に変更なくても「変更を保存」することが推奨されています)。また、後述するようにAll-in-One WP Migrationの対象範囲ではない、wp-config.phpやads.txt等は別途保存しておいてください。

新Wordpress環境に移行する

http://パブリックIP/ にアクセスしてコンテンツが再現されているか確認します。念のため、ブラウザでページソースを確認して、新しいIPアドレスが入っている要素が無いかを確認するのも良いと思います(私の場合、ブログトップを指すメニューがなぜかIPアドレスになっていたので、メニューから更新しました)。

また、All-in-One WP MigrationはWordpressのコンテンツ以外は移行されない点には注意してください。例えばGoogle Adsese用に/ads.txtを置いている場合、手動でコピーする必要がありますし、wp-config.php等を直接編集したカスタマイズは移行されないので、これも別途移行する必要があります。

問題なければ、Lightsailの管理画面で、旧Lightsailインスタンスにつけてあった固定IPアドレスを外し、新インスタンスに付け替えます。付け替えたら、固定IPアドレスやホスト名で新インスタンスが表示できているかを確認します。

確認できたら、旧インスタンスを停止・削除します(念のため、手動スナップショットは少しの間維持しておくのが良いでしょう)

データベース内のIPアドレスの更新(追記:2022/1/2)

エントリを書いた後に気づいたのですが、過去に投稿したエントリを編集すると、画像のURLがホスト名ではなくIPアドレスになってしまうという現象が出ました(閲覧するだけなら問題が発生しません)。これはRDB側のどこかにインスタンス作成時のIPアドレスが残ってしまっているためのようです。今回はVelvet Blues Update URLsプラグインを導入して、URLを一括置換して対処しましたが、このプラグインは最近メンテナンスされなくなっているため、今から利用する場合はforkしたUpdate URLs プラグインを利用する方が良いでしょう。念のため作業前にスナップショットを作成してから実施することをお勧めします

プラグインを導入するとツールに”Update URLs”というメニューが追加されるのでそれを選択します。Oldの方に置換したいURL、Newの方に正しいURLをセットし、更新対象を以下のようにURLs in page content、URLs in links、URLs for attachmentsにチェックをいれて”Update URLs NOW”を押すと更新できました。

まとめ:更新しやすい環境を維持する

現時点では、バージョンアップをするには上記のような方法しか存在しないため定期的な移行作業が必要です。作業量を減らすには、できるだけAll-in-One WP Migration(もしくは他のWordpressマイグレーションのソリューション)だけで移行できるようにしておくと楽です。この事から、本サイトは以下の方針で維持しようと思っています。

  • (極力)wp-config.php、functions.php、httpd.confといったファイルを手で変更するカスタマイズはしない
  • HTTPS(SSL)証明書をLightsail上のApacheで設定しない

プラグインでの設定であればAll-in-One WP Migrationで引き継がれるため、サイトのカスタマイズはできるだけプラグインで実現していく方針です。また、www.portablecode.info => portablecode.infoへのリダイレクトはhttpd.confでやるのではなく、S3のリダイレクト機能で実現しています(詳細はこちらに書きました)。

Bitnamiは簡単にLet’s EncryptのSSL証明書をインストールできる便利な仕組みがあるのですが、これを使用するとスタック更新のたびにSSL証明書の移行も必要になってしまいますので、このサイトではAmazon CloudFront (CDN)を利用し、HTTPS化はCloudFrontに任せています(この設定方法も後程書く予定です)。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です