この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
こんにちは、協栄情報のきおかです。
この度Wordpressのサーバーを移行する機会がありまして、全て手作業で行ったのでナレッジ共有しておきます。
私はBitnamiを利用しましたが、この記事で紹介する範囲に関してはいわゆるLAMP環境が整っていれば無理やりbitnamiを利用する必要はないです。
Bitnamiとは?
特定のアプリの環境を簡易に準備してそのアプリをデプロイするために、Webアプリと開発環境をパッケージ化し、必要な依存関係とコンポーネントを含んだものです。
AWSで使われるAMIで構築する場合は、そのAMIを使って構築してアクセスできるように設定して、wordpressの設定をすればすぐにWordpressサイトが構築運用できるようになるといった感じです。
Bitnami公式ページはこちら。
今回私が利用したものはWordPress packaged by Bitnamiです。
これは、Apache, MySQL/MariaDB, PHP, PHPMyAdmin, WordPressが入っている、Debianベースのスタック構成になっています。
Bitnamiが提供するWordpress用のイメージはPHPを更新できない
今回サーバを移行することになった一番の理由です。こちらのQiita記事ではAll-in-One WP Migrationを利用する方法が紹介されています。
手作業で行うことのメリット
-
コストが浮きます。無料版では512MBのみで、それ以上であれば$69かかります。結構高い…。
-
いい学びになります。Wordpressの仕組みはもちろん、OSに対する理解も深まります。
前提
既存環境の整理
下記と同じ状態であれば、後ほど紹介する作業手順のままで進められます。
異なる場合は、ご自身のケースに当てはまり、かつ実際に必要である手順のみ参考にしてください。
- WordPressを運用しているサーバ
- MySQLデータベースサーバもしくは上記サーバにDBがありMySQLを利用している
移行にあたって起こりうる課題
課題 | 説明 | 対処方法 |
---|---|---|
検証環境でDNS解決できない | まずは検証環境で動作確認などしますが、Wordpressではwp-config.phpいじったりwp_options tableのレコードを書き換えたりと色々面倒です。 | WindowsのhostsファイルをいじってDNS解決を回避します。こちらの記事で詳細書いてます。 |
バージョンの違いでうまく動作しない | DBとwp-contentを移行して検証するだけなので特にエラーはないと思いますが、あれば調べて対処してみてください。 | 個別具体的に調査。 |
プラグインがうまく動作しない | これは移行とは主旨がずれるのでここでは触れません。「プラグイン名 エラー」で日本語や英語で調べると出てくると思いますので、そちらでお願いします。 | 個別具体的に調査。 |
必要な作業
今回の移行作業にあたって、おおまかに以下の手順が必要です。具体的には各章で解説していきます。
- サーバ構築
- データベース移行
- wp-content移行
- DB連携
- その他各種設定
サーバ構築
移行先となるサーバを構築してください。
先ほど紹介したWordPress packaged by Bitnamiのスタックに従って構築してください。
AWSであれば、AWS Marketplaceからサブスクして、AMIからインスタンスを作成してください。
具体的な構成については、個別具体的にあると思うのと、今回の主題は移行なので割愛します。
bitnamiでサーバを構築した場合の注意点
WordPress packaged by Bitnamiでインスタンスを起動した場合、起動時にMySQL等の初期パスワードが発行されます。
EC2であればマネジメントコンソール画面のシステムログから確認できます。
もしくは、/home/bitnami/
ディレクトリにあるbitnami_credentials
に記載されています。
下記を実行して確認できます。
sudo cat /home/bitnami/bitnami_credentials
データベース移行
DBバックアップファイルを作成
移行元のサーバでmysqldump
コマンドを実行して、データベースのバックアップファイルを作成します。
コマンドスニペットは以下です。
sudo mysqldump -u ${username} -p ${database you want to migrate} > /tmp/db_migration.dump.sql
mysqldump
コマンドが見つからない場合は、findやgrepなどで探してみてください。具体的なやり方についてはこちらの記事で解説しています。
DBバックアップファイルを送信
DBバックアップファイルができたら、移行先サーバに送信します。
私はscpコマンドで公開鍵方式で実行しました。
以下、コマンド例です。${path to keypair file}でキーペアのパスを指定して、${endpoint you want to send the db backup file}で移行先サーバをエンドポイントで指定しています。
bitnamiベースのインスタンスであれば、bitnami@ec2-xxx-xxx-xxx-xxx.${region}.compute.amazonaws.com
がエンドポイントになります。
scp -i ${path to keypair file} /tmp/db_migration.dump.sql ${endpoint you want to send the db backup file}:/tmp
受け取れたかどうか、移行先のサーバで下記を実行して確認してみてください。
sudo ls /tmp
db_migration.dump.sql
があれば成功です。
空のデータベースを構築
移行先サーバでMySQLにログインします。
mysql -u root -p
先ほどメモした初期設定パスワードを入力してログインしてください。
下記コマンドを実行してデータベースを作成します。
CREATE DATABASE ${db name};
データベースを移行
exit
コマンドでログアウトして、下記を実行してデータベースを移行します。
mysql -u root -p ${db name} < /tmp/db_migration.dump.sql
先ほどメモした初期設定パスワードを入力して実行してください。
念のため、正しく移行されたか確認しておきます。
mysqlにログインして、
mysql -u root -p
データベースを選択して、
USE ${db name};
テーブルが移行されているか確認して、
SHOW TABLES;
適当なテーブルを選択して移行元と同じレコードが存在するか確認します。
SELECT COUNT(*) FROM ${table};
確認できたらデータベースの移行は完了です。
次に移ります。
wp-content移行
それではwp-contentを移行していきます。wp-contentには、テーマやプラグイン、これまでにアップロードした画像データなどが入っています。
バックアップファイルを作成する
wordpressのディレクトリに移動します。
cd ${path to your wordpress directory}
下記を実行して、zip化します。
sudo zip -r /tmp/wp-content.zip wp-content
-r
がないと空のディレクトリのみ追加され、ファイルやサブディレクトリ、その中のファイルは追加されないので注意してください。
/tmp/wp-content.zip
で/tmp
ディレクトリに圧縮したwp-content
のzipファイルを保存します。
バックアップファイルを送信する
先ほどと同様に送信してください。
もう一度コマンド例を載せておきます。
${path to keypair file}でキーペアのパスを指定して、${endpoint you want to send the db backup file}で移行先サーバをエンドポイントで指定しています。
bitnamiベースのインスタンスであれば、bitnami@ec2-xxx-xxx-xxx-xxx.${region}.compute.amazonaws.com
がエンドポイントになります。
scp -i ${path to keypair file} /tmp/db_migration.dump.sql ${endpoint you want to send the db backup file}:/tmp
受け取れたかどうか、移行先のサーバで下記を実行して確認してみてください。
sudo ls /tmp
wp-contentのバックアップをとっておく
wp-contentがあると邪魔なので、バックアップと称して名称を変更して置いておきます。
下記コマンドを実行します。
cd ${path to wordpress directory}
sudo mv wp-content default-wp-content.bk
バックアップファイルを解凍してwordpressディレクトリに配置
移行先サーバで下記を実行して、wp-contentの移行を完了します。
sudo unzip /tmp/wp-content.zip
sudo rm -rf /tmp/wp-content.zip
cd /tmp
sudo mv wp-content ${path to wordpress directory}
wordpressディレクトリの権限を設定する
下記を実行して、wordpressのディレクトリやファイルの権限を設定します。
こちらはBitnamiの公式ドキュメントを参考にしています。
cd /
sudo chown -R bitnami:daemon ${path to wordpress directory}
sudo find ${path to wordpress directory} -type d -exec chmod 775 {} \;
sudo find ${path to wordpress directory} -type f -exec chmod 664 {} \;
sudo chmod 640 ${path to wordpress directory}/wp-config.php
DB連携
wp-config.phpを編集してDBを連携する
移行先サーバで下記を実行するか、エディタアプリでwp-config.phpを編集します。
sudo vi ${path to wordpress directory}/wp-config.php
viが開けたら、i
を押してEditorモードにします。
設定する変数 | 設定する値 |
---|---|
DB_NAME | ${db name} |
DB_USER | root |
DB_PASSWORD | 冒頭の方でメモした初期設定のパスワード |
DB_HOST | localhost |
※DB_HOSTに関して、RDSなどを使っている場合はエンドポイントを指定してください。
編集できたら、esc
キーを押して:wq
を押してEnterを押してください。これで編集内容が保存されます。
その他各種設定
検証環境でDNS解決できない問題を解決する
冒頭でお話しした移行にあたって起こりうる課題の検証環境でDNS解決できないを解決します。
DNSとは
DNS解決とは、ある予約されたドメイン(文字列)とIPアドレスを紐づける技術です。
例えばgoogle.com
にアクセスすると216.58.220.142
や142.251.42.206
に紐づけられます(2023/06/29 14:26時点)(負荷分散されたりCDNがあったりと色々あるので変わります)。ドメインからIPアドレスを調べる方法は、以下のコマンドをターミナルやcmdで実行してください。
nslookup ${domain}
何が問題なのか
現状、データベースとwp-contentの移行が完了し、DB連携も完了しています。
移行自体は完了したわけですが、移行先サーバの動作確認が済んでいません。動作確認したいですが、接続するためのIPアドレスとドメイン名が紐づけられていないため、wordpressの(DBのwp_optionsテーブルで指定されている)site urlとhomeのアドレスが一致せず、サイトにアクセスできません。
これは、WordpressがIPアドレス直接指定のアクセスを許可していない(ような設定になっている)からです。
DBを編集することでこの問題を回避することは可能ですが、本番環境に移行後にDBを編集するという怖くて面倒なことをする必要があります。いやですね。
ということで、hostsファイルをいじってDNS解決を回避することで、この問題を解決しましょう。詳しくはこちらの記事で解説しています。
とにかくやってみましょう。
Windowsの場合
エディターで以下のパスを指定してhostsファイルを開いてください。
Windows/System32/drivers/etc/hosts
以下のように一番下に追記してください。
${ip address to your server} ${domain}
例えば、当ブログのドメインであれば、以下のように設定します。
xxx.xxx.xxx.xxx cloud5.jp
Linuxの場合
以下に接続して編集してください。
/etc/hosts
以下のように一番下に追記してください。
${ip address to your server} ${domain}
例えば、当ブログのドメインであれば、以下のように設定します。
xxx.xxx.xxx.xxx cloud5.jp
実際にアクセスしてみる
ブラウザに先ほどのドメインを入れてアクセスを試みてみてください。本来接続されるはずの移行元のサーバではなく、移行先のサーバに接続されたはずです。
WordPressサイトが正しく表示されていれば成功です。
仕組み
そもそもDNS解決のためのドメインですが、これはHTTPリクエストのヘッダー部分の’Host’フィールドに含まれるようです。
Wordpressの場合、受け取ったパケットのHTTPヘッダを確認し、’Host’フィールドにある文字列とDBのwp_optionsのsite url もしくは homeにある文字列が一致していれば表示、という動作を行っているのでしょう。憶測なので間違っていたらご指摘お願いします。
動作確認
以下が確認できれば、基本的な動作確認は完了と言えるでしょう。
- サイトにアクセスできる
- 記事を表示できる
- 管理画面にログインできる
- 記事を追加→画像をアップロードできる
- 記事を投稿(保存)できる
- 保存した記事をサイトから表示できる
- プラグインの追加や削除などができる
まとめ
今回はWodpressの移行を、プラグインなど用いずに手動で行う方法をご紹介しました。
この試みで私自身、OSやソフトウェアへの理解が非常に高まりました。また、ここでは共有できませんが内部設計書や手順書を作成したりと、少し上のレイヤーも経験することができました。
引き続き学習を続けていきたいですね。
それではまた。