WordPress のまるっと移行 Linux to Linux

69

このサイト(WordPress)は、長らくAmazon Lightsail にお世話になってきました。月額1,800円くらいで1インスタンスと DNS や Firewall、スナップショット機能が GUI でお手軽に使えたため、お得感が強かったのです。何よりハードのメンテナンスが不要でしたから。
ですが、容量不足から一つ上のインスタンスにアップグレードしたところ、当たり前ですが月額の請求額が4,600円を超えるようになりました。こんな過疎ブログサイトであるにも関わらず。さすがに1サーバへの投資許容範囲を超えたので、オンプレミス環境(ローカルサーバ)に引っ越しすることにしました。

同様のことをご検討されている人がいるかもしれませんので、ざっくりですが、移行概要を共有します。移行先の環境が整っていれば、すんなり WP を表示させることが可能です。

なお、まるっと移行は実現できませんが、WP の拡張プラグインを使用した移行方法があります。少しでも技術的な難易度を下げつつ、多少不都合が出たとしても、とにかく移行できればいい!という人は、別サイトの情報をご参照ください。

移行元と移行先の環境について

ドメインの変更もしません。移行完了後に DNS のレコード修正(グローバルIPの変更)により、新旧を切り替えます。

・移行元(AWS)
OS:CentOS 7.9
MySQL:5.7.24
PHP:7.4
Apache:2.4.6x
WP:6.8.3
WP URL:https://makorin.org/

・移行先(オンプレ)
OS:RockyLinux9(VMware上のゲストOS)
MySQL:8.0.43
PHP-FPM:8.2.29
Apache:2.4.62
WP:6.8.3
WP URL:https://makorin.org/

移行元でのバックアップ

以後、細かなコマンドなどは省略してますので、適時対応ください。

・WP のコンテンツフォルダのバックアップ
WP のコンテンツが含まれるディレクトリをまるっとまとめましょう。

# 実行例
tar -czvf ./wordpress_backup.tar.gz /home/www/htdocs

・MySQL の WP データベースのバックアップ

# 実行例
mysqldump -u root -p WPのDBネーム > ./wp-db-dump.sql

・MySQL 接続情報の記録
WP から MySQL のデータベースに接続するためのユーザ ー ID とパスワード、データベース名が分かっていればOKです。必ず記録しておきましょう。MySQL にコマンドでログインできるところまで確認しておけばさらに確実です。

移行先の OS 環境整備

まるっとコピーですのでできればホストネームなどは合わせておきたいですが、変更しても WP への影響はありません。但し、WP の管理画面などが元のドメイン(当サイトであれば https://makorin.org/) をブラウザに返すため、移行先の環境で WP を表示させるときに備えたローカル DNS の準備か 、クライアントの hosts 追記などで対策を打っておきます。
Linux における通常の OS セットアップを完了させます。

移行先の MySQL 導入と WP 用の設定

一通りのコマンドは以下のとおりです。

# インストールと自動起動設定
dnf install mysql-server -y
systemctl start mysqld
systemctl status mysqld
systemctl enable mysqld

# rootパスワードの厳格化や設定など必須初期設定をウイザード形式で対応可能なコマンド
mysql_secure_installation

# 現状確認
mysql -u root -p
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.01 sec)

# WP用のデータベースの作成
mysql> create database wordpress1db;
Query OK, 1 row affected (0.00 sec)

# 作成結果の確認
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| wordpress1db       |
+--------------------+
5 rows in set (0.01 sec)

# WP用のユーザ作成(移行元と同じMySQL接続用のユーザーIDとパスワードを設定)
mysql> select Host, User FROM mysql.user;
mysql> create user 'ユーザーID'@'localhost' identified by 'パスワード';

# WP用のデータベースにユーザーの権限を付与する。
mysql> grant all privileges on WPのDBネーム.* to 'ユーザID'@'localhost';

# 試しに作成したユーザーアカウントでMySQLにログインしてみる。
mysql -u ユーザID -p -P 3306
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| performance_schema |
| wordpress1db       |
+--------------------+
3 rows in set (0.00 sec)

MySQL に移行元 WP データベースをリストア

さきほど作成した MySQL のユーザー ID とパスワードで、移行元でバックアップしたデータベースを、空のデータベースにリストアします。

# 実行例
mysql -u ユーザーID -p WPのDBネーム < ./wp-db-dump.sql

移行元のコンテンツファイルを移行先にリストア

# 実行例
tar -xzvf wordpress_backup.tar.gz -C /home/www/

ウェブサイトに手慣れている人は知っている話なんでしょうが、念のため。
移行元は mod_php でしたので、Apache の実行ユーザー権限でコンテンツの権限管理していました。
今回、Apache と PHP-FPM と別れて動作させますから、セキュリティ観点から、Apache と PHP-FPM の実行ユーザーは分けるべきです。Apache と PHP-FPM 連携構成では、Apache はコンテンツに対して原則読み取り権限が必要で、PHP-FPM は書き込み権限が必要ですので、移行元の Apache の実行ユーザーで PHP-FPM を動作させるのがスマートと思います。

また、リストア後のコンテンツパス(/home/www/htdocsなど)は、移行元と同一パスにします。Apache の httpd.conf 内のディレクトリパスを変更するつもりなら、変えても問題ありません。

PHP-FPM 導入と WP 用設定

代表的な WP のプラグインが必要とする拡張モジュールの導入と、少々のチューニングを行います。

# PHPの最新バージョンを利用するためRemiリポジトリをインストールする。
dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm

# デフォルトで有効になっているPHPモジュールをリセットする。
dnf module reset php

# PHP 8.2モジュールを有効化
dnf module enable php:remi-8.2

# WP 及び Web アプリケーション向けコアパッケージ、MySQL接続、画像処理、
# 多言語対応の拡張モジュールをインストールする。
dnf install -y php php-cli php-common php-mysqlnd php-gd php-xml php-mbstring php-opcache php-fpm php-imagick php-zip php-intl

# 拡張パッケージやモジュールの簡易説明
# php-mysqlnd:MySQLデータベース接続に必須(WordPressで必要)
# php-fpm:NginxやApacheでPHPを処理するための推奨インターフェイス
# php-gd:画像処理機能(サムネイル生成など)
# php-mbstring:日本語などマルチバイト文字の処理
# php-opcache:PHPコードの高速化(パフォーマンス向上)
# php-imagick:画像処理機能(一部WPプラグイン用)
# php-zip:プラグイン・テーマのインストールなどに必要
# php-intl:国際化機能用

# WP向けに以下箇所を修正する。
vi /etc/php.ini
--
upload_max_filesize = 100M
post_max_size = 100M
--

# PHP-FPMを再起動して設定を反映、自動起動設定も行う。
systemctl restart php-fpm
systemctl enable php-fpm

Apache の導入

移行元の Apache で IP ベースのバーチャルホストなど、複雑な設定をしているのであれば httpd.conf の見直しが必要ですが、makorin のホストでは単純構成でしたので、Apache 実行用のユーザーとグループだけ修正しました。

Apache と PHP-FPM との実行ユーザーとグループを、例として以下のように移行先で運用することにしました。Apache の実行ユーザーとグループを httpd.conf で環境に合わせて修正してください。
まとめると以下のようになります。

Apache ⇒ 実行ユーザー:apache、グループ:www
※apacheの実行ユーザーは移行元と変えます。併せて移行先のOS上で、apacheをグループ「www」に所属させることもお忘れなく。

PHP-FPM ⇒ 実行ユーザー:www、グループ:www
※移行元の Apache の実行ユーザーとグループを使用します。移行後のコンテンツ(ディレクトリとファイル)との権限問題は発生しないはず。

なお、上記は例なので当ウェブサイトの実際は別のユーザーを使用しています。
併せて、コピーしたコンテンツのディレクトリとファイルの権限の再チェックもしましょう。

Forbidden
You don't have permission to access this resource.Server unable to read htaccess file, 
denying access to be safe

後述の動作チェックで上記エラーをブラウザが応答してきたら、SELinux を除くと、ほぼ原因はディレクトリやファイルの権限問題です。

# Apacheのインストールと自動起動設定
dnf install httpd
systemctl start httpd
systemctl status httpd
systemctl enable httpd

# 実行ユーザーとグループの設定変更
vi /etc/httpd/conf/httpd.conf
--
User apache
Group www
--

# ファイヤーウォールの設定

# HTTP (ポート 80) を許可
firewall-cmd --permanent --add-service=http

# HTTPS (ポート 443) を許可
firewall-cmd --permanent --add-service=https

# 設定をファイアウォールに反映
# firewall-cmd --reload

PHP-FPM の Apache 連携の設定

UNIX ソケットでの Apache と PHP-FPM の連携は、ソケットの権限問題をすぐにクリアできそうにもなかったため、TCP ポートによる連携に切り替え(恥ずかしいけれど仕方なし)。
PHP-FPM (FastCGI Process Manager) の最も重要な役割は、従来の PHP 実行方式(mod_php)の欠点を解消し、高負荷な Web アプリケーションである WP を高速に動作させるために不可欠なものです。

# ApacheがPHP-FPMにリクエストを転送するようにする
# 以下のApache設定ファイルを新規作成する
vi /etc/httpd/conf.d/php_fpm.conf
--
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
<FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>
--
# Apacheの起動時にmod_proxy.soとmod_proxy_fcgi.soがロード済みとエラーが出力された場合、
# LoadModuleの二行を削除する。

# PHP-FPMの設定ファイルの修正
# PHP-FPMの実行ユーザーは、移行元のApacheと同一のユーザーとグループを指定する。
# (Apacheの実行ユーザーは別とすること)
vi /etc/php-fpm.d/www.conf
--
user = www
group = www

# 以下の設定はコメントアウトする(UNIXソケットを使用しないため不要)。
; listen.owner = apache
; listen.group = apache
; listen.mode = 0660
; listen.acl_users = apache,nginx
; listen.acl_groups = apache
--

# 設定を完了したらPHP-FPMを再起動する。
systemctl restart php-fpm

# Apacheも再起動する。
systemctl restart httpd

# PHP-FPMの起動状態の確認
systemctl status php-fpm
# 以下の出力があるかどうか確認する。
php-fpm.service; enabled
Active: active (running)

# PHP-FPMがポート9000でLISTENしているかも確認する。
ss -tunlp | grep 9000
tcp  LISTEN 0  4096 127.0.0.1:9000  0.0.0.0:*  users:(("php-fpm",pid=4605,fd=10) 以降省略

Apache の SSL 設定

手順は記載しませんが、秘密鍵の作成、証明書の発行手続き、証明書の設置まで完了します。なお、SSL 証明書はドメインに対して発行されるため、移行元の秘密鍵と証明書をコピーして利用することも可能です(今回はセキュリティを考慮し新規取得しました)。

また、Apache 起動時に秘密鍵のパスワードを毎回聞かれて自動起動しない問題への対処を忘れないでください。makorin は毎回これを忘れてます。

Postfix(メールサーバ)の導入と設定

移行元でメールの送信には困っていなかったのですが、別のローカル環境となるとそうもいきません。コメントなどが投稿された時の WP からの通知メールなどのために、メールの送信機能が必要です。メールサーバを立てなくても WP からの送信方法はあると思いますが、RockyLinux からの管理メールも受信したいなど、利便性を考慮してローカルにメールサーバを構築しておきます。

なお、最近のプロバイダーは SMTP が使用する TCP:25 番ポートをブロックしていることが多いため、以下の構成をとることにしました。すでに別途メールサーバが有る人はこんなことをしなくても構いません。

WP — Local TCP25 –> Postfix — TCP:587 –> Gmail MTA

※Postfix は受け付けたメールを、全て Gmail にリレーするようにし、Gmail はサブミッションポートで受付して、宛先に配送してもらいます。Gmail からのメールは、差出人が Gmail アカウントのメールアドレスに強制変換されるので留意してください。

# Postfixのインストールと起動設定
dnf install postfix
systemctl start postfix
systemctl enable postfix

# アクセス許可とメール中継許可を設定する。
vi /etc/postfix/main.cf
--
# inet_interfaces記載例(メールの受付をするかどうかの範囲指定)
inet_interfaces = localhost ⇒ ローカルのみ
inet_interfaces = all ⇒ 全て(他のサーバやクライアントからも受付する)

# メール中継の記載例(受付したあと、外部へのメールリレーを許可するかどうかの指定)
mynetworks = 168.100.189.0/28, 127.0.0.0/8, localhost
--

# SMTPサービスの種別設定。TCP:25番だけのメール受付ならば以下行をコメントアウトすれば問題ない。
vi /etc/postfix/master.cf
smtp      inet  n       -       n       -       -       smtpd

# ここから受付・受信したメールをsmtp.gmail.comにリレーするための設定となる。

# まず、Gmailアカウントにブラウザでログインして「アプリパスワード」を入手すること。検索推奨。
# 入手出来たら以下のファイルを新規作成する。
# XXX@gmail.com は自身のアカウント、**kuqykqcjpdga** は先に取得したアプリパスワード。
vi /etc/postfix/sasl_passwd
--
[smtp.gmail.com]:587 XXX@gmail.com:**kuqykqcjpdga**
--

# 権限の再設定(必須)
chmod 600 /etc/postfix/sasl_passwd

# データベース形式に再変換
postmap /etc/postfix/sasl_passwd

# Postfixサービスの再起動
systemctl restart postfix

# メールクライアントでPostfixを指定して外部アドレスへテスト送信するか、telnetコマンドで手動送信してもいい。
# PostfixはTCP:25番で受信し、その後smtp.gmail.comに対してはTCP:587番でメールを送信する。
# smtp.gmail.comは宛先に対してさらにメールリレーする。という流れ。

以上です。

細かな修正箇所はいろいろと残ると思いますが、上記の流れまでをきちんと対応できていれば、ブラウザで移行先にアクセスすれば、見知った WP サイトが表示されると思います。ここから正常に動作しているか確認をして回ります。最初に管理ページにアクセスしてサイトヘルスでおかしな通知がでていないか確認します。

冒頭で言いましたが、移行元が稼働していて、DNS の切替をしていない状態でドメインでアクセスすると、当たり前ですが移行元がブラウザに表示されます。
そのため、移行先の IP アドレスでまずはアクセスして動作確認してください。また、うっかり管理画面などにアクセスすると、WP がドメインで返してきますので、再び移行元の管理画面が表示される羽目になります。必ず、作業用 PC などの OS の hosts に細工してから確認してください。

コメントする

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