旧ブログ復旧とKusanagiから脱却

2022-08-15 (最終更新: 2024-11-04)

夏休みに入った初日に、旧ブログ(https://blog.washo3.com )のセキュリティ対策しようと思ったのが、悪夢の始まりでした。
これは、ブログ消失から復旧し、Kusanagiから脱却した失敗談です。

もう、旧ブログを閉鎖して2年ほど経つのですが、まだアクセスがあるので、残してたわけですが、そのまま放置していたため、WordPressやPHPの更新を行い、セキュリティを保ちたいと思いました。
ちなみに、旧ブログはDocker+Kusanagi-Wordpressの構成になってます。

ブログデータ消失

最近では、仕事でもよくDockerで開発環境を作っているため、WordPressのデータは永続化しているので、戸惑いなくdocker-compose downを行なった。
しかし、永続化しているデータはWordPress上のファイル群であり、ブログ記事などはMySQLのDBにVolume保存さてたため、downコマンドでVolumeデータが消失してしまいました。

直前に、WordPressのAll in One Migration（aim)のプラグインでバックアップをとっていたのが幸いでした。

kusanagiのイメージファイルが変更になってた

再度、kusanagi-wordpressを起動し、新たにWordPressをインストールして、Migrationで戻せるだろうと安易に考えてましたが、かなり難航しました。 dockerで起動しようとしたところ、今までのイメージファイル primestrategy/kusanagi-php7:7.0.6-1が見つからないと。?

DockerHubで確認したところ、kusanagi-php7がkusanagi-phpへ変更になっていたので変更してみたところ、7.0.xは既になくなっていた。
仕方ないので、7.4系を設定したところ、WordPress新規インストールまでたどり着いた

all in one migrationでインポートが止まる

これで、新規WordPressにaimをインストールしてインポートを行えば、元に戻るはず？とインポートを始めたが、何度やっても途中で止まってしまう。
データが10GB近くあるので、phpiniの設定を確認し、アップロード容量もタイムアウトも問題ないはずなのに、何度行なっても途中で止まる？？

環境の問題なのか確認するため、別PCの環境のDockerでインポートしても、やはり止まるので、PCの環境ではなさそう。

よく考えてみると、aimで取ったバックアップファイルはWordPress 5.x系、現在のWordPress環境を構築すると6.0系がインストールされるので、これが原因だろうと、Wordpress 5.xのDockerを作成し、インポートしてみたら、成功した。

バックアップ・復元では、極力PHPやWordPressのバージョンを同じにしておくのが重要なのかもしれない！

kusanagiから脱却

kusanagi-wordpressの環境では、PHPやWordPressとの依存関係で今後も更新が面倒くさそうなので、以前からkusanagiから脱却したいと思っていたので、ちょうど良い機会だろうと、これを機に純粋なwordpress+php+mysqlのDockerで稼働させる事にした。

とりあえずのdocker-compose.ymlとDockerfile

version: '3.3'
services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: root
       MYSQL_PASSWORD: wordpress
   wordpress:
     depends_on:
       - db
     build:
      context: .
      dockerfile: Dockerfile
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: root
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
       TZ: Asia/Tokyo
volumes:
    db_data: {}

FROM wordpress:5.9-php7.4-apache
RUN { \
  echo 'max_execution_time=0'; \
  echo 'memory_limit=-1'; \
  echo 'post_max_size=20000M'; \
  echo 'upload_max_filesize=20000M'; \
} > /usr/local/etc/php/conf.d/wp.ini

このDockerで起動後は、WordPress 5.9の環境なのに、初期インストール画面を完了させると6.0になってしまうのは何故？？
6.0になってしまうとaimのバックアップファイルがインポートできないので、どうしようか悩む。

まだデータが入っていないので、思い切ってダウングレードしようと情報を探ったら、ダウングレードの便利なプラグインがあったので、あっけなくダウングレードできた。

そして、ようやくaimのバックアップファイルをインポート出来た。

kusanagi関連を削除

インポートしたデータ内には、今までのkusanagi関連が残ったままなので、該当すると思われるDBのテーブルやファイルを削除

ファイル・ディレクトリ
WordPress/wp-content/mu-plubins内

kusanagi-core ディレクトリ
kusanagi-wp-configure.php
wp-kusanagi.php

DB内

wp_site_cache
wp_sitemanager_device
wp_sitemanager_device_group
wp_sitemanager_device_relation
加えて、KUSANAGI 関連のデータベースのデータとして、wp_options 内の option_name が以下のレコードも削除してください。

kusanagi-translate-accelerator-settings
site_manager_cache_installed
sitemanager_device_rules

advanced-cache.phpも削除した方が良いとの情報があるが、念の為、残しておいた

この時点で、ブログの表示等に問題ないか確認

DB内URL変更

SiteURL等が開発用のURLになっているので、Search Regex等のプラグインで置換しようとしたが、正常に動作しないので、結局DBのダンプファイルからVimで置換し、SQLで再インポートを行なった。

終わりに

もう更新もしていないブログなのに、手をつけてしまったのが運の尽きで、復旧までに丸々1日費やしてしまいました。
なぜか、メニューが出なかったり、ウィジェットが消失してたり、レイアウトやCSSの面でテーマが有効にならない不具合も残ってますが、ブログ記事が元通りになったので、とりあえず良しとしました。

まぁ、ちょっと重い腰を上げて作業した甲斐もあって、ようやくkusanagiから脱却する事が出来たので、今後は、ApacheからNginxに変更したり、PHPもバージョンを上げられたり、自由度が効くようになったのは、思わぬ成果なのかもしれません。

こんな記事誰も読まないかと思いますが、再発防止のため、失敗談として残しておきました。