AWS LightsailのWordPressを移行！PHPの脆弱性対策とハマったポイント
AWS LightsailのWordPressを移行！PHPの脆弱性対策とハマったポイント こんにちは！はるぱかパパです！ 今回は、このブログを運用している AWS LightsailのWordPress環境を移行したお話です。 きっかけは、PHPの脆弱性への対応。 これまでAWS LightsailのBitnami版WordPressを利用していましたが、セキュリティ対策を進めるため、新しいLightsail版WordPressの環境へ移行することにしました。 移行自体は無事に完了しましたが、データベースの復元やSSL証明書の設定、Jetpackのアクセス統計など、いくつかつまずいたポイントもありました。 備忘録も兼ねて、今回の作業内容を紹介します！ 目次 PHPの脆弱性対策が必要に！ WordPressはPHPで動作しているため、WordPress本体やプラグインだけでなく、PHP自体のセキュリティ対策も重要です。 これまで利用していたLightsailのBitnami版WordPressでは、PHPの脆弱性への対応が必要になっていました。 AWSの公式ドキュメントでも、PHPの脆弱性への対応方法が案内されています。 AWS公式：PHPのセキュリティ脆弱性への対応 そこで今回は、従来のBitnami版WordPressから、新しいLightsail版WordPressへ移行することにしました。 Bitnami版からLightsail版WordPressへ移行 今回実施したのは、既存のWordPress環境をそのままアップデートするのではなく、新しいインスタンスを作成して、ブログのデータを移行する方法です。 大まかな作業の流れは以下のとおりです。 AWS公式にも移行手順が公開されているので、こちらを参考に進めました。 AWS公式：BitnamiからLightsailブループリントへの移行 ① まずは旧WordPressをバックアップ 移行作業で一番重要なのがバックアップです。 今回は、WordPressのエクスポート機能に加えて、データベースとファイルも個別にバックアップしました。 WordPressのエクスポート WordPressの管理画面から「ツール」→「エクスポート」を選択し、投稿や固定ページなどのデータを保存します。 データベースのバックアップ MySQLのデータをエクスポートして保存します。 WordPressの記事や各種設定などはデータベースに格納されているため、こちらも重要です。 画像やプラグインなどのバックアップ wp-content ディレクトリもバックアップしました。 ここにはアップロードした画像やテーマ、プラグインなどが保存されています。 WordPressのエクスポート機能だけでは、サイト全体を完全に復元できるわけではないので注意が必要です。 ② 新しいLightsailインスタンスを作成 続いて、AWS Lightsailの管理画面から新しいWordPressインスタンスを作成します。 今回は従来のBitnami版ではなく、Lightsail版のWordPressブループリントを選択しました。 この時点では旧インスタンスを停止せず、新旧の環境を並行して用意しておきます。 新しい環境で問題なくWordPressが動作することを確認してから切り替えれば、万が一トラブルが発生しても元の環境に戻しやすくなります。 ③ WordPressのデータを復元 新しいインスタンスが作成できたら、バックアップしたデータを復元します。 今回はWordPressのインポート機能に加え、MySQLのデータと wp-content のファイルも移行しました。 データベースの復元では、新しい環境のデータベース設定を確認し、バックアップしたSQLファイルをインポートします。 ただし、WordPressのインポートとデータベース全体の復元は、対象となるデータが重複することがあります。 一般的には、データベース全体を復元する方法か、WordPressのインポート機能を利用する方法のどちらかを中心に進めるのがわかりやすいと思います。 今回は環境の違いもあったため、設定やファイルの整合性を確認しながら作業しました。 特に、テーマやプラグイン、画像ファイルが正常に引き継がれているかは重要な確認ポイントです。 ④ 静的IPアドレスを新しいインスタンスへ移行 データの復元が完了したら、公開先を新しいインスタンスに切り替えます。 AWS Lightsailでは静的IPアドレスを利用できるため、今回は旧インスタンスから静的IPアドレスをデタッチし、新しいインスタンスにアタッチしました。 これなら、既存のIPv4アドレスを引き継げるので、DNS設定の変更を最小限に抑えられます。 ただし、切り替えのタイミングによっては一時的にサイトへアクセスできなくなる可能性があります。 アクセスの少ない時間帯に作業するのがよさそうです。 SSL証明書の設定でエラー発生！ 今回、少しハマったのがSSL/TLS証明書の設定です。 新しいWordPress環境でHTTPS対応を進めようとしたところ、次のようなエラーが表示されました。 DNS records do not match instance IPs. Did not find IPv6 match for 1 domain(s). どうやら、ドメインのDNS設定と新しいインスタンスのIPv6アドレスが一致していないことが原因のようです。 Route 53にAAAAレコードを追加 今回はAWS Route 53でドメインを管理しているため、DNS設定を確認しました。 IPv4アドレスに対応するAレコードは設定していましたが、新しいインスタンスのIPv6アドレスに対応するAAAAレコードが不足していました。 そこで、ルートドメインとwww用にAAAAレコードを追加しました。 項目 設定内容 レコードタイプ AAAA レコード名 ルートドメイン、www 値 新しいLightsailインスタンスのIPv6アドレス TTL 300秒 なお、AAAAレコードは、インスタンスでIPv6が有効になっており、そのアドレスでWebサイトへ正常にアクセスできることを確認してから設定する必要があります。 DNSの変更が反映されるまで少し待ってから再度SSL証明書の設定を実行すると、無事に進めることができました！ WordPress側もHTTPSに統一 SSL証明書の設定が完了したら、WordPress内のURLもHTTPSに統一します。 WordPressの管理画面でサイトURLを確認するとともに、データベース内に残っているHTTPのURLも必要に応じて置き換えました。 この作業にはWordPressの管理ツール「WP-CLI」の検索・置換機能が便利です。 ただし、データベース内のURLを一括変更するため、必ずバックアップを取得し、事前に変更対象を確認してから実行する必要があります。 最後にWebサーバーを再起動し、HTTPSで正常にアクセスできることを確認しました。 無事にセットアップ完了しました！ HTTPSの設定は正しいのに「保護されていない通信」！？ 実は、SSL証明書の設定が完了したあとにも、もうひとつつまずいたポイントがありました。 …