WordPressの移行　その①　バックアップ

2023.04.03
この記事は約6分で読めます。

　ちょっと前になりますが、WordPressを移行しました。理由は、セキュリティの関係でphpが古いなど、Kusanagi runs on Dockerから指摘を受けていたから。phpなどのバージョンアップをなんとかしようと試みてたもののうまくいかず、最終的に移行した手順などを記録しておきます。

Dockerを利用したWordPress環境の反省点

　最初にWordPress環境を構築する際、Kusanagi runs on Dockerが無料だったため、試しにインストールし、そのまま利用していました。しかし、phpのバージョンが古いなど色々お叱りを受けていたため前々から何度かアップデートを試みていましたが、うまくいってませんでした。

Docker コンテナの更新がうまくいかない

　Dockerは、仮想コンテナなので簡単に置き換えができる、環境の移行ができるというのが売りです。しかし、すべてのアプリのバージョンを上げようとすると、様々な原因で簡単にはアップデートできません。にわか知識ではどこに原因があるか追求ができません。少し例をあげると

  • ymlのバージョンの違いで記載方法が異なる
  • アプリケーション自体のバージョンの問題で他のアプリケーションとの連携ができない
  • コンテナ同士のリンクがうまくできない

　要は、Dockerで構築するより、普通にDBやWebサーバーなどを色々インストールしていった方がよかったかもしれません。

以前の環境

  • VPS：Web Arena Indigo
  • 実行環境：Kusanagi runs on Docker
  • CMS：WordPress

　次に、新しい環境を作ってそこへ移行することを考えました。前回同様Kusanagi runs on Dockerの使用も考えましたが、Kusanagiのバージョンが8で止まっていること、また、今回のようにDocker コンテナの更新がうまくいかないのであれば、Dockerを利用する価値はないし、そもそも、Kusanagiを利用する時としない時の差がどこまであるのかわからないため、大変悩みました。

しかし、そこで出てきたのがWebArena IndigoでKusanagiが使えるというお話。2022年12月現在では、クーポンもついてきたため、それに乗っかってみることにしました。OSは変わりましたが、Kusanagi 9 for WebARENA Indigoです。

全体の流れ

さくっと全体の流れをまとめると、

  • 既存環境全体のバックアップ（サーバーまるごと）
  • データベースのバックアップ
  • 新環境の作成（Indigo VPS)
  • Kusanagiの初期設定、プロビジョニング
  • データベースのリストア
  • その他の設定

既存環境全体のバックアップ（サーバーまるごと）

　普段のバックアップについては、Indigoのスナップショットに頼ってます。スナップショットだと色々いじって環境を壊してもスナップショットを戻すだけで治るため大変楽でした。しかし、移行にあたってはそれではだめで、既存の環境を別の方法でバックアップを取る必要があります。

　バックアップについて調べると大概プラグインが出てきますが、そこまで大層なことではないし、プラグインは極力入れたくないため却下。次に公式のサポートなどではphpmyAdminが出てきます。しかしこれもDocker環境に後から入れようとすると大変です。既存の環境の中にうまく組み込むことができず断念しました。

　そこで、私が採用した方法はデータベースのダンプを取得することです。これなら何もアプリケーションは追加で入れなくてもできるのでできるのではないかと思いました。（実際何とかなりました）

前置きが長くなりましたが、次に実際のバックアップの取得方法を紹介します。

データベースのバックアップ

まずは既存のデータベースを確認します。

$ docker ps
CONTAINER ID        IMAGE         　　　 COMMAND      　　　　　  CREATED       STATUS              PORTS           NAMES
~
ad0c111e1e61      mariadb:10.1.21      "docker-entrypoint.s…"   2 years ago      Up 2 weeks          3306/tcp

mariaDBがあるDockerのコンテナを調べ、入ります。(ad0c111e1e61がコンテナ名）

$ docker container exec -it ad0c111e1e61 bash

MariaDBに接続し、バックアップするデータベースを確認します。

# mysql -u root -p
※パスワードを入力

SQLコマンドプロンプト上で、以下を入力し、Kusanagiで作成していたDBを確認します。

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| KusanagiDB         |　←対象のデータベース名
+--------------------+
4 rows in set (0.01 sec)

対象のファイルをバックアップします。

mysqldump --single-transaction -u root -p データベース名 > yyyymmdump.sql（ダンプ先ファイル名）
※オプションの–single-transactionは必須ではないが、付けることでダンプ処理をトランザクションで囲むことができデータの整合性が担保されます。

MariaDB [(none)]>exit

バックアップファイルの確認をします。

root@ad0c111e1e61:/# ls
202212dump.sql  boot  docker-entrypoint-initdb.d  etc   lib    media  opt   root  sbin  sys  usr

Dockerコンテナ内からホストへファイルをコピーします。

$ docker cp ad0c111e1e61:2022dump.sql 2022dump.sql
※docker cpコマンドはリンクを参照。

新サーバーはまだ作成していないため、ホストから一旦ローカルPCへ保存（WinSCPなどを利用）します。その後、新サーバーを立ててから、新サーバーへコピーします。

新環境の作成は次回に続きます。