Amazon Lightsail WordPressイメージを最新版に更新する

Network

このブログはAWSのLightsail上で動作していますが、構築してから2年経ったためイメージの更新を行うことにしました。2年も経つとイメージの中身も結構変わっていたので、備忘含めて記載します。

以前の記事はこちら：

さくらからAmazon Lightsailへの移行
さくらのVPSを長年使っていたのですが、全然更新されないWordPressのためだけにそれなりに課金するのもアレだったので、断捨離がてらAmazon Lightsailへ移行しました。その備忘録。
blog.hiroaki.jp
2021.05.06
Lightsail + WordPress (bitnami) WebP対応でのトラブルシュート
先の投稿でLightsailでWordPressを立ち上げWebP対応を進めたところ、.htaccessとPageSpeedでハマったので備忘のため記載。
blog.hiroaki.jp
2021.05.07
スポンサーリンク

bitnamiイメージは、イメージごと更新することを推奨

Lightsailでは、あらかじめWordPressがインストールされたイメージが用意されており、それを利用するのが簡単です。このイメージを提供しているのはbitnamiです。様々なアプリケーションがインストールされたイメージが配布されており、WordPressはその一つです。

ubuntuなどは、OSそのものを再インストールすることなく、利用しているパッケージをを丸ごとアップデートして最新バージョン同等に更新できたりしますが、bitnamiの場合はイメージを更新せずに中身だけ最新版にするということができません(中身はdebianなのでバックポートはできるかもしれませんが)。そのため、ある程度利用したら “式年遷宮” よろしくイメージを更新し、データを移行する必要があります。

動いていればいいじゃないかという意見もあるかもしれませんが、古いイメージには様々な脆弱性が潜んでいる可能性もありますし、新しいイメージの方がランタイムが更新されてパフォーマンスにも期待が持てるかもしれませんので、更新した方が良いでしょう。

スポンサーリンク

2年間でのイメージの主な変更点

2年前のWordPressイメージからどの程度変化があったか、ざっと書き出してみます。

パッケージの変化

まずは、イメージ内で使われている各種パッケージです。WordPressのバージョン自体も変わっていますが、WordPress自体はイメージ固定でもバージョンアップができますので、ここでは言及しません。

イメージのバージョン

  • 2年前にインストールしたもの：Bitnami WordPress 5.6.1-1 
  • 今回インストールしたもの：WordPress packaged by Bitnami 6.2.0-14

主なパッケージのバージョン

5.6.1-16.2.0-14
Linux kernel4.19.0-23-cloud-amd645.10.0-21-cloud-amd64
Apache2.4.462.4.57
PHP7.4.158.1.18
MySQL8.0.23
MariaDB10.11.2
（参考）Debian version10.13 (buster)11.7(bullseye)

MySQLからMariaDBの利用に変更になっているという違いもありますが、バージョンという意味ではLinux kernelとPHPが大きく変わっています。Linux kernelは新しいプロセッサへの最適化などが進んでいるようですし、PHPに関してはメジャーバージョンアップでパフォーマンスも向上しているようです。

なお、bitnamiがChangelogを提供しているので、正確な情報はこちらをご確認ください。

スポンサーリンク

ディレクトリ構成の変化

いくつかディレクトリ構成に変化がありました。

/bitnamiディレクトリの新設

今までは/opt/bitnami配下に全てのファイルが保管されていましたが、ユーザ作成のコンテンツ関係が/bitnami配下に移動されました。/opt/bitnami以下からはシンボリックリンクが貼られています。具体的には、

/bitnami$ tree -L 2 -F
.
├── mariadb/
│   └── data/
├── phpmyadmin/
└── wordpress/
    ├── wp-config.php
    └── wp-content/

このようになっており、DB全般とWordPressの設定ファイル・画像等コンテンツディレクトリが切り出されています。バックアップを取ったりするのに便利だと思います。

/opt/bitnami/apps ディレクトリの(デフォルト)削除

/opt/bitnami/apps以下にwordpressなどのディレクトリがありましたが、/opt/bitnami直下に置かれるようになりました。

before

/opt/bitnami$ tree -L 2 -F -d
.
├── apache2
(snip.)
├── apps
│   ├── bitnami
│   ├── phpmyadmin
│   └── wordpress
(snip.)
├── mysql
│   ├── bin
│   ├── bitnami
│   ├── data
│   ├── include
│   ├── lib
│   ├── scripts
│   ├── share
│   ├── support-files
│   └── tmp
(snip.)

after

/opt/bitnami$ tree -L 2 -F -d
.
├── apache
(snip.)
├── apache2 -> apache
├── apps
│   └── letsencrypt
(snip.)
├── mariadb
│   ├── bin
│   ├── conf
│   ├── data -> /bitnami/mariadb/data
│   ├── include
│   ├── lib
│   ├── licenses
│   ├── logs
│   ├── plugin
│   ├── sbin
│   ├── share
│   └── tmp
(snip.)
├── phpmyadmin
(snip.)
├── wordpress
│   ├── licenses
│   ├── tmp
│   ├── wp-admin
│   ├── wp-content -> /bitnami/wordpress/wp-content
│   └── wp-includes
└── wp-cli
    ├── bin
    ├── conf
    └── licenses

/opt/bitnami/apps以下にletsencryptディレクトリがありますが、これはSSL証明書を自動更新するスクリプトを走らせた際にその設定ファイルが保存されています。

スポンサーリンク

Apache設定ファイル群の変化

/opt/bitnami/apache2/conf以下にある設定ファイルが結構変わっています。

before

/opt/bitnami/apache2/conf$ tree -P "*.conf"
.
├── bitnami
│   ├── bitnami-apps-prefix.conf
│   ├── bitnami-apps-vhosts.conf
│   ├── bitnami.conf
│   ├── httpd-2xlarge.conf
│   ├── httpd.conf -> /opt/bitnami/apache2/conf/bitnami/httpd-micro.conf
│   ├── httpd-large.conf
│   ├── httpd-medium.conf
│   ├── httpd-micro.conf
│   ├── httpd-small.conf
│   └── httpd-xlarge.conf
├── brotli.conf
├── deflate.conf
├── extra
│   ├── httpd-autoindex.conf
│   ├── httpd-dav.conf
│   ├── httpd-default.conf
│   ├── httpd-info.conf
│   ├── httpd-languages.conf
│   ├── httpd-manual.conf
│   ├── httpd-mpm.conf
│   ├── httpd-multilang-errordoc.conf
│   ├── httpd-ssl.conf
│   ├── httpd-userdir.conf
│   ├── httpd-vhosts.conf
│   └── proxy-html.conf
├── httpd.conf
├── modsecurity.conf
├── original
│   ├── extra
│   │   ├── httpd-autoindex.conf
│   │   ├── httpd-dav.conf
│   │   ├── httpd-default.conf
│   │   ├── httpd-info.conf
│   │   ├── httpd-languages.conf
│   │   ├── httpd-manual.conf
│   │   ├── httpd-mpm.conf
│   │   ├── httpd-multilang-errordoc.conf
│   │   ├── httpd-ssl.conf
│   │   ├── httpd-userdir.conf
│   │   ├── httpd-vhosts.conf
│   │   └── proxy-html.conf
│   └── httpd.conf
├── pagespeed.conf
├── pagespeed_libraries.conf
├── php-fpm-apache.conf
└── ssi.conf

/opt/bitnami/apps/wordpress/conf$ tree -P "*.conf"
.
├── banner.conf
├── certs
├── htaccess.conf
├── httpd-app.conf
├── httpd-prefix.conf
├── httpd-vhosts.conf
└── php-fpm
    ├── php-settings.conf
    └── pool.conf

after

/opt/bitnami/apache2/conf$ tree -P "*.conf"
.
├── bitnami
│   ├── bitnami.conf
│   ├── bitnami-ssl.conf
│   ├── certs
│   ├── httpd.conf -> memory/httpd-micro.conf
│   ├── memory
│   │   ├── httpd-2xlarge.conf
│   │   ├── httpd-large.conf
│   │   ├── httpd-medium.conf
│   │   ├── httpd-micro.conf
│   │   ├── httpd-small.conf
│   │   └── httpd-xlarge.conf
│   ├── php-fpm.conf
│   └── phpmyadmin.conf
├── deflate.conf
├── extra
│   ├── httpd-autoindex.conf
│   ├── httpd-dav.conf
│   ├── httpd-default.conf
│   ├── httpd-info.conf
│   ├── httpd-languages.conf
│   ├── httpd-manual.conf
│   ├── httpd-mpm.conf
│   ├── httpd-multilang-errordoc.conf
│   ├── httpd-ssl.conf
│   ├── httpd-userdir.conf
│   ├── httpd-vhosts.conf
│   └── proxy-html.conf
├── httpd.conf
├── modsecurity.conf
├── original
│   ├── extra
│   │   ├── httpd-autoindex.conf
│   │   ├── httpd-dav.conf
│   │   ├── httpd-default.conf
│   │   ├── httpd-info.conf
│   │   ├── httpd-languages.conf
│   │   ├── httpd-manual.conf
│   │   ├── httpd-mpm.conf
│   │   ├── httpd-multilang-errordoc.conf
│   │   ├── httpd-ssl.conf
│   │   ├── httpd-userdir.conf
│   │   ├── httpd-vhosts.conf
│   │   └── proxy-html.conf
│   └── httpd.conf
└── vhosts
    ├── 00_status-vhost.conf
    ├── htaccess
    │   └── wordpress-htaccess.conf
    ├── wordpress-https-vhost.conf
    └── wordpress-vhost.conf

といった感じになっています。WordPressの設定ファイルもapache配下に置かれるようになったのが大きな違いでしょうか。

全体的に、見るべき設定ファイルが浅い階層に置かれるように整理されたので、以前よりも見通しは良くなった…気がします。

スポンサーリンク

デフォルト設定の変化

設定を行っていて気づいたのですが、Apacheの初期設定にいくつか違いがありました。もしかしたら気づいていないだけで他にもあるかもしれません。

mod_pagespeedが無効になっている

最近はメンテナンスモードになっているようにも見えるmod_pagespeedですが、無効化されていました。こいつが悪さをすることも結構あるので、サポートの大変さという意味でもデフォルト無効で良いのではないかと思います。

今回CloudFrontによるCDNも利用することにしたので、mod_pagespeedを改めて有効化することはしませんでした。

mod_http2が有効になっている

デフォルトでmod_http2モジュールを読み込むようになっていました。オフィシャルドキュメントではデフォルトでは有効になっていない旨記載がありますが…。

ただ、いずれにせよApacheのVirtualHost設定では有効化されていないため、設定ファイルをいじって有効にする必要があります。

bitnamiバナー表示がなくなった

誰がbitnamiのバナーを表示したまま使うんだ、と自分の中で不評だった「バナー無効化手続き」ですが、デフォルトで表示されなくなっていました。

WordPressのプラグインが最初から色々入るようになった

有効化はされていませんが、いくつかのプラグインが最初から同梱されていました。使いたいものは自分で入れるというポリシーの人も多いと思いますが、WordPressのプラグインは玉石混交でもあるので、ある程度実績があるもの（と信じたい）があらかじめ入っているのは初心者にとっては悪くないかもしれません。

スポンサーリンク

デフォルト設定からの変更

いくつか、自身のブログをホストするにあたって行った設定を備忘兼ねて記載します。次回の移行時に役立てます…。

追加パッケージのインストール

sudo apt install lynx htop webp
  • lynxは、apachectlを動かそうとするとこれが必要というので…。
  • htopは、topよりも慣れているので
  • webpは、コマンドラインで画像をwebpに変換するcwebpコマンドを使いたかったため

Apacheの読み込みモジュールとしてmod_expiresを追加

キャッシュ期限をコントロールするmod_expiresが最初は無効になっているので、

/opt/bitnami/apache/conf/httpd.conf ファイルのコメントアウトをはずします。

MaxConnectionsPerChildの調整

/opt/bitnami/apache/conf/bitnami/httpd.confはデフォルトではmemory/httpd-micro.confへのリンクになっています。これは、あまり大きくないインスタンスでの実行を念頭に置いた設定になっています。

普通に使っている分にはこれで良いのかもしれませんが、Lightsailの小さなインスタンスでWordPressを長時間動かしていると、httpdスレッドがどんどん増えてしまいメモリが枯渇する事態が発生しました。そこで、以下のようにMaxConnectionsPerChildの値をググッと小さくしています。

<IfModule mpm_prefork_module>
  StartServers    5
  MinSpareServers 5
  MaxSpareServers 10
  MaxRequestWorkers       5
  MaxConnectionsPerChild  1000
# MaxConnectionsPerChild  5000
  KeepAliveTimeout 1
</IfModule>

<IfModule mpm_event_module>
  ServerLimit               4
  StartServers              2
  MinSpareThreads         128
  MaxSpareThreads         192
  ThreadsPerChild          64
  MaxRequestWorkers       256
  MaxConnectionsPerChild 1000 
# MaxConnectionsPerChild 5000
  KeepAliveTimeout          2
</IfModule>

<IfModule mod_passenger.c>
  PassengerMinInstances       1
  # PassengerMaxInstancesPerApp 1
  PassengerMaxPoolSize        3
</IfModule>

ちなみに、デフォルトではmpm_event_moduleがロードされていますので、上段は本来は不要です。

php.iniの調整

/opt/bitnami/php/etc/php.ini の値を調整します。

upload_max_filesize = 200M
post_max_size = 200M

bitnamiのイメージでは、PHPはApacheモジュールではなくphp-fpmで動いているため、Apache側で調整するのではなく、PHP側で調整することになります。

iniファイルを別に用意する(user.ini)方法もあるようですが、このインスタンスはWordPress専用なのでphp.iniを直接いじってしまいました。user.iniの場合は5分ごとに読み込まれるようなのでphp-fpmを再起動する必要がないのですが、php.iniをいじった場合には再起動が必要です。

sudo /opt/bitnami/ctlscript.sh restart php-fpm

PHP-FPMの調整

しばらく動作させていたら、php-fpmのログ（/opt/bitnami/php/logs/php-fpm.log）がwarningを吐いていました。

[05-May-2023 18:04:16] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[05-May-2023 18:06:00] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[05-May-2023 18:08:12] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[05-May-2023 18:10:27] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[05-May-2023 18:12:17] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[05-May-2023 18:20:27] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it
[05-May-2023 18:20:41] WARNING: [pool www] server reached pm.max_children setting (15), consider raising it

その後は（CDNを入れたから？）エラーが出ていないのですが、あまり気分の良いものでもないので、いったん倍にしてみました。いじるファイルは/opt/bitnami/php/etc/memory.conf です。

; Bitnami memory configuration for PHP-FPM
;
; Note: This will be modified on server size changes

;pm.max_children=15
pm.max_children=30
pm.start_servers=10
pm.min_spare_servers=10
pm.max_spare_servers=10
pm.max_requests=5000
スポンサーリンク

htaccessの設定

以前の記事でも指摘した通り、bitnamiのイメージでは.htaccessがデフォルトでは利用できないようになっています。

.htaccessを利用できるようにしても良いのですが、行儀の悪いWordPressプラグインがやらかす可能性もありますので、bitnamiの意向通り、静的に設定することにします。

htaccess関係は

/opt/bitnami/apache/conf/vhosts/htaccess/wordpress-htaccess.conf

に記載することが期待されています。

ここに追記するのは、自分の場合は主に以下です。

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css A31536000
    ExpiresByType application/x-javascript A31536000
    ExpiresByType application/javascript A31536000
    ExpiresByType text/javascript A31536000
    ExpiresByType image/jpeg A31536000
    ExpiresByType image/webp A31536000
(snip.)
</IfModule>

こんなやつです。

HTTP/2の利用

せっかくmod_http2がロードされているので、利用できるようにします。

/opt/bitnami/apache/conf/vhosts/wordpress-https-vhost.conf の<VirtualHost 127.0.0.1:443 _default_:443>内に、

Protocols h2 h2c http/1.1
H2Direct on

を追加すればHTTP/2での通信が始まります。

Let’s Encryptの設定

/opt/bitnami/bncert-tool を立ち上げて対話形式で実行します。

入力したドメイン名が名前解決できなかったり、動作しているインスタンスのIPと異なる場合には先に進めないので、あらかじめDNSで設定しておく必要があります。AAAAレコード（IPv6）が設定されているとうまくいかなかったので、一旦外しておく必要があり、地味に面倒でした。

wp-config.phpの修正

下記の移行ではwp-config.phpは対象外のようなので、必要に応じて修正します。必須なのは

  • WP_HOME
  • WP_SITEURL

あたりでしょうか。

スポンサーリンク

WordPressデータの移行

…まぁこのあたりはいろんなところに記事がありますので、そちらを参考にやっていただければ…。

自分は今回はAll-in-One WP Migrationを以下の設定で利用しました。

  • wp-content以下の画像データは手作業で移行
  • プラグインも手作業で再インストール

プラグイン自体をAll-in-One WP Migrationを使って移行しなくても、設定自体は残っているようで正しく反映されました。以下の順序で移行したのが良かったのかもしれません。

  1. プラグインをインストール
  2. wp-content以下の画像データを移行
    • 移行後にアクセス権・所有者などのチェックを行う必要がある(daemonグループに書き込み権限を与える)
  3. All-in-One WP Migrationにて過去データのインポート

データ移行時のトラブル

データ移行して困ったことは、一部のファイルのURLがFQDN表記（https://blog.hiroaki.jp/…）ではなくIPアドレス表記（http://12.34.56.78/…）になってしまったことです。データ移行前にwp-config.phpを修正する必要があったのかもしれません。

元々のサイトを活かしつつ、HTTPの状態で設定していたからだと思いますが、あるあるだと思いますので、どう対処したかだけ記載します。

影響箇所

  • 埋め込みURL（他のブログ記事へのリンク）
  • 画像URL
  • blogテーマ（自分の場合はCocoon）内の画像ファイル（背景とか）へのリンク
  • blogテーマ内のメニューでの「ホーム」リンク

対処方法

記事内のデータに関しては、Search Regexプラグインで一括置換しました。

Search Regex
Search Regex は、WordPress の投稿、ページ、独自の投稿種別、またその他のデータに対する強力な検索と置換機能を追加します。
ja.wordpress.org

それ以外（blogテーマ関連）は、気づいたら直すという対症療法でしたが、そこまで数は多くありませんでした。ブラウザのデベロッパーツールで怪しいアクセスを見つければOKです。

スポンサーリンク

まとめ

2年ぶりにWordPressイメージを更新しました。

面倒ではありますが、一方で動作確認されたイメージを利用した方が個々にパッケージをアップデートするよりもトラブルは少ないかもしれません。ファイル構成なども改善されていたので、古いものを使い続けるよりも結局は「急がば回れ」になるかもしれません。

今回はこの式年遷宮に加え、CloudFrontによるCDNも導入しましたので、別記事にて手順を紹介しようと思います。

スポンサーリンク

コメント

タイトルとURLをコピーしました