前提。引越し先スペック
- インスタンスイメージの選択: Linux/Unix
- 設計図の選択: アプリ + OS, WordPress
- インスタンスプラン:
- $3.50 USD
- 512 MB
- 1 vCPU
- 20 GB のSSD
- 1 TB <= 転送
騒動まとめ
- メモリが足りない? Mariadb をインストールした後に他のパッケージを yum インストールしようとすると失敗する。
- 稼働後、
yum update
すると強制終了となってできない。メモリ不足?
Ansible でサーバをプロビジョニングしましたけれども、さまざまな問題にぶつかり、かなり時間がかかってしまいました。
その問題たちを、挙げていこうと思います。
yum コマンドが失敗し、その後 yum が使えなくなる
Mariadb をインストールした後に他のパッケージを yum インストールしようとすると失敗しました。 その時のエラーメッセージを残しておくのを忘れてしまいましたけれども、 yum のデータベースにアクセスできないと出力されていました。 下記の参考ページと同じような出力でした。 メモリが足りないためにこのようなトラブルが発生するのでしょうか?
復帰方法は、次のコマンドです。ですが、うまくいかない時もあり、釈然としない思いです。やっぱりメモリ。。。
sudo rm -f /var/lib/rpm/__db*
sudo yum clean all
WordPress に必要な PHP 拡張モジュール
これは、発生した問題ではありません。けれども、問題なくインストール完了するまでに時間が少しかかったので残しておきます。
まず、必要な PHP 拡張モジュールのリストはこちらです。
- System Packages Server Environment – Make WordPress Hosting
- PHP Extensions Server Environment – Make WordPress Hosting
WordPress を動かすための環境が整っているかどうかは、 WordPress 管理画面のツール > サイトヘルスページから確認できます。
さて、必要な PHP 拡張モジュールをインストールするために、次のような Ansible タスクを書きました。これはリストに記載されたものをインストールするのに特化した内容となっております。下記とは別に、 PHP そのものを別途インストールするタスクが必要です。
# https://make.wordpress.org/hosting/handbook/handbook/server-environment/#system-packages
- name: Install system packages for WordPress
yum:
name:
- ImageMagick6
- ghostscript
- ghostscript
- libsodium
enablerepo: epel,remi
state: present
# https://make.wordpress.org/hosting/handbook/handbook/server-environment/#php-extensions
- name: PHP extensions for WordPress
yum:
name:
- php-curl
- php-dom
- php-exif
- php-fileinfo
- php-hash
- php-json
- php-mbstring
- php-mysqli
- php-sodium
- php-openssl
- php-pcre
- php-imagick
- php-xml
- php-zip
enablerepo: epel,remi-php74
state: latest
WordPress ディレクトリに SELinux 設定を行う
これも問題ではありませんでしたけれども、作業に時間がかかりましたのでメモしておきます。普段は行わない作業で、毎回忘れてしまうのです。。。
CentOS 7 ですので、 SELinux が標準で有効です。無効にして運用しても良いのですけれども、活かす場合は、設定が必要です。
WordPress を /srv/wordpress/
ディレクトリにインストールしました。
その場所に対して、基本的にはウェブサーバが読み取りのみできるようにしています。
そして、プラグインやテーマを追加等できるように /srv/wordpress/wp-content
以下は書き込みもできるようにしました。
ただしこの設定の場合、 WordPress 本体のアップグレードはできませんでしたので、 wp-cli 等の別の手段で行う必要があります。
最後に、 restorecon
で変更を確定させて、その変更内容を ls -Z
で確認して終わりです。
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/wordpress(/.*)?'
sudo semanage fcontext -a -t httpd_sys_rw_content_t '/srv/wordpress/wp-content(/.*)?'
sudo restorecon -RF /srv/wordpress/
ls -Z -a /srv/wordpress/
WordPress 本体のアップデートが、 wp-cli でできない。
権限が足りなかったようです。 ですので、 sudo で実行すればどうだろうと、やってみると、、、できませんでしたので、次のコマンドでできるようにいたしました。
sudo ln -s /usr/local/bin/wp /usr/bin/wp
そして、実行してみたところ、WordPress 本体のアップデートに成功しました!
↓ WordPress 本体のアップデートに失敗><。
[centos@ip-172-26-1-202 wordpress]$ wp core update
Updating to version 5.3.1 (ja)...
https://downloads.wordpress.org/release/ja/wordpress-5.3.1.zip から更新をダウンロード中...
更新を展開しています…
Error: ディレクトリを作成できませんでした。
[centos@ip-172-26-1-202 wordpress]$
↓ WordPress 本体のアップデートに成功♪
[centos@ip-172-26-1-202 wordpress]$ sudo wp core update
Updating to version 5.3.1 (ja)...
https://downloads.wordpress.org/release/ja/wordpress-5.3.1.zip から更新をダウンロード中...
更新を展開しています…
Success: WordPress updated successfully.
[centos@ip-172-26-1-202 wordpress]$
Let’encrypt を certbot で設定
今の時代の普通のウェブサイトですので、 https にします。 Let’s Encrypt を使用します。 これもやり方を忘れていましたけれども、公式のページがとてもわかりやすく説明しておりました。
なお、 sudo certbot certonly --nginx
した際に、どのように Let’s Encrypt とやりとりしているかを理解しておくと、トラブルシューティングが楽になると感じました。
- 動作の仕組み – Let’s Encrypt – フリーな SSL/TLS 証明書
- ベスト・プラクティス – 80 番ポートを開放しよう – Let’s Encrypt – フリーな SSL/TLS 証明書
- ウェブサーバは 80 ポートでアクセスできなければならない。
- ウェブサーバは、 80 ポートへのアクセスを https ポートへリダイレクトしてもよい。
実際の作業は次のページです。
sudo certbot certonly --nginx
# nginx 設定ファイルを編集
echo "0 0,12 * * * root python -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew" | sudo tee -a /etc/crontab > /dev/null
/etc/nginx/conf.d/default.conf への編集内容
ssl_certificate /etc/letsencrypt/live/oki2a24.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/oki2a24.com/privkey.pem;
MariaDB のデータベースダンプの取得とリストア
mysqldump -u wpoki2a24user -p wpoki2a24db > wpoki2a24db.sql
mysql -u wpoki2a24user -p wpoki2a24db < wpoki2a24db.sql
MariaDB がフリーズする
Status: "Waiting for page cleaner"
になってしまいました。
sudo systemctl restart mysqld
でも再起動できませんでしたので、 都度 OS を reboot
しています。
[centos@ip-172-26-1-202 ~]$ sudo systemctl status mysqld
● mariadb.service - MariaDB 10.4.10 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/mariadb.service.d
└─migrated-from-my.cnf-settings.conf
Active: activating (auto-restart) (Result: signal) since 水 2019-12-11 07:16:48 JST; 222ms ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 25670 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 18557 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=killed, signal=ABRT)
Process: 18509 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
Process: 18507 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Main PID: 18557 (code=killed, signal=ABRT)
Status: "Waiting for page cleaner"
12月 11 07:16:48 ip-172-26-1-202.ap-northeast-1.compute.internal systemd[1]: mariad...
12月 11 07:16:48 ip-172-26-1-202.ap-northeast-1.compute.internal systemd[1]: Failed...
12月 11 07:16:48 ip-172-26-1-202.ap-northeast-1.compute.internal systemd[1]: Unit m...
12月 11 07:16:48 ip-172-26-1-202.ap-northeast-1.compute.internal systemd[1]: mariad...
Hint: Some lines were ellipsized, use -l to show in full.
[centos@ip-172-26-1-202 ~]$
CentOS 7~8 MariaDB インストール、及び初期設定 – eTuts+ Server Tutorial に、 MySQL 5.6.8 以前に付属していた設定オプションファイルが掲載されておりました。 低スペックマシン向けの設定 my-small.cnf を、 InnoDB のコメントを外して使用痛しまいした。
1日くらいなら、サーバダウンしないようになった。その後、ダウンしない記録を伸ばしています。
おわりに
ある時、久しぶりに本ブログをホストしているウェブサーバを yum アップデートしようかな、と軽い気持ちで実行したところ、、、、無事完了したのにアクセスできなくなってしまいました。
この時、原因を探るのも面倒でしたし、そろそろ新しい環境に移るのもいいなと思い、 Amazon Lightsail に引越しすることにいたしました。
低スペックなインスタンスであれば、 1 ヶ月程度の時間は無料、ということでしたので、試してみています。
yum が途中で失敗したり、 MariaDB が落ちたり、 yum update ができなかったり、メモリが少ないことが原因と睨んでおりますけれども、なかなかハードです。
一応は完了できましたので、つまづいたことをいつものようにノートいたしました。
次に行っていることとして、 yum update はできませんので、代わりにインスタンスを新しく作ってそこに移し替える、ということが気楽にできるようにするために、 Ansible のプレイブックを整理しているところです。
以上です。
「Amazon Lightsail に WordPress サーバを引越しした騒動まとめ」への1件の返信
[…] Amazon Lightsail に WordPress サーバを引越しした騒動まとめ – oki2a24 で感じていたメモリ不足を、 Swap を作ることで解消できるのではないかと考え、実施しました。 […]