Amazon Lightsail に WordPress サーバを引越しした騒動まとめ

前提。引越し先スペック

  • インスタンスイメージの選択: 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 拡張モジュールのリストはこちらです。

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 とやりとりしているかを理解しておくと、トラブルシューティングが楽になると感じました。

実際の作業は次のページです。

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 のプレイブックを整理しているところです。

以上です。

ディスカッションに参加

1件のコメント

コメントを残す

コメントを残す