WordPress の Docker 移行 - 文诗inscripoem

WordPress の移行問題は、私にとって常に大きな難題でした。

実際、私だけではなく、この移行は面倒ですが、ディレクトリをコピーしてデータベースに SQL を書くだけで（ドメインを変更しない場合は書かなくても）完了します。今では、既存のプラグイン（例えば Duplicator）を使えばワンクリックで完了しますが、私が心配しているのは風蓝（前提については当我们谈论风蓝官网时我们在谈论什么を参照）。

風蓝にとっては、もっと簡単でワンクリックの（これは必ずしも良いことではありませんが）解決策が必要です。長年の Docker ユーザーとして、当然コンテナ化を思いつきました。Docker Compose を使えば、ウェブサイトとデータベースを一つのディレクトリにパッケージ化し、新しいマシンに移動しても変更は不要で、コマンド一行で起動または停止できます。

実際の操作では、いくつかの罠に遭遇しました（以前 Docker を使用していなかったときに記録できなかったものも含めて）、ここにまとめて書きます。

操作手順#

Compose ファイルはdocker/awsome-composeから来ています：

services:
  db:
    # We use a mariadb image which supports both amd64 & arm64 architecture
    image: mariadb:10.6.4-focal
    # If you really want to use MySQL, uncomment the following line
    #image: mysql:8.0.27
    command: '--default-authentication-plugin=mysql_native_password'
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=somewordpress
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wordpress
      - MYSQL_PASSWORD=wordpress
    expose:
      - 3306
      - 33060
  wordpress:
    image: wordpress:latest
    volumes:
      - wp_data:/var/www/html
    ports:
      - 80:80
    restart: always
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=wordpress
      - WORDPRESS_DB_PASSWORD=wordpress
      - WORDPRESS_DB_NAME=wordpress
volumes:
  db_data:
  wp_data:

実際の操作では、マウントされた 2 つのボリューム db_data と wp_data をローカルディレクトリに移動し、他は基本的に変更しません。

このステップでは、1 つの mariadb データベースと 1 つの nginx+wordpress のウェブサーバーが作成されます。 wordpress がマッピングされたポートは、ホストマシンにウェブサーバーがインストールされていなければ直接 80 でアクセスできます。私は他のポートにマッピングしてリバースプロキシを行うのが好きです（宝塔の新しいバージョンではリバースプロキシプロジェクトを直接作成できるようになりました、これは良い評価です~~結局 2024 年になっても宝塔を使っているのは誰でしょう~~）。ここでは詳しくは述べません。

docker compose up -d の後、ポートまたはドメインにアクセスすると、全く新しい WordPress が表示されます。移行が必要な場合は、前述の Duplicator を使って直接パッケージ化し、wp_data にインストールできます。

踏み外し#

ついに~~私の好きなセクション~~最も苦痛なトラブルシューティングのセクションに到達しました。今振り返ると、大多数の問題はコンテナ化ではなく、WordPress 自体のいくつかの厄介な特性によるものであり、WordPress は素晴らしいですが、やはり断固として捨てるべきだという信念をさらに強めました。

注意が必要なのは、以下のほとんどの問題について私は根本的な原因を探ることなく、単に推測と検索で解決策を見つけただけです。結局のところ、もしこのような奇技淫巧を使わなければ現代の環境での使用が保証されないのであれば、これらのことに大量の時間を浪費する必要はないと思います。使えればそれで良いのです。

ERR_TOO_MANY_REDIRECTS#

この問題は、設定の WordPress アドレスとサイトアドレスを両方とも https://example.com に変更した後に発生しました。ウェブサイト自体には問題がありませんが、管理サイトにアクセスすると ERR_TOO_MANY_REDIRECTS が表示されます。何度も再起動し、長時間待っても改善しなかったため、StackExchange のこの投稿を見つけ、一気に理解しました。

ネイティブの WordPress は、サイト内で HTTPS を設定することをサポートしていないため、私の SSL 設定はリバースプロキシの位置にある Nginx にあります。そして、WordPress のアドレス設定はリダイレクトのベース URL を管理しているため、HTTPS を伴うサイトにアクセスすると、外側の Nginx が私を内側の WordPress に導きますが、その時点で設定により、WordPress は私を HTTPS サイトにリダイレクトしようとします。こうしてリダイレクトが死のループに入ってしまいます。

私自身の解決策はこのスレッドに似ていますが、Docker 内の Nginx で SSL を設定していないことを明確に知っていたので、アドレスを http に戻しました。

多くの変更方法がありますが、データベースにアクセスできる場合は、[sitename]_options テーブルの home と siteurl フィールドを変更できます。また、ファイルのルートディレクトリにある wp-config.php に以下を追加することもできます：

define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');

同時に、wp-config.php を変更した後、サイト設定で上書きされた項目はグレーアウトして変更できなくなります。つまり、データベース内の値は無効になります。この点は必ず注意してください~~なぜ変更できないのか長い間疑問に思っていました~~。

プラグインのインストールとディレクトリの権限#

ホストマシンに直接インストールされた WordPress では、プラグインのインストールは非常にスムーズで、特別な操作なしでプラグインマーケットでワンクリックでインストールできます。しかし、Docker イメージには問題があり、WordPress の公式イメージは www-data ユーザーで実行されているため、コピーされたり自動的に作成されたファイルの権限が正しくありません。これが原因で、プラグインをインストールする際に FTP アカウントを入力する必要があります。

解決策はこの issueと返信で言及されている gistを参考にしました。まずはおなじみの wp-config.php に以下を追加します：

define('FS_METHOD', 'direct');

これにより、プラグインのインストールモードが変更されます。次に、ターミナルで WordPress フォルダの所有者と権限を変更します：

docker exec -u root -it {CONTAINER_ID} /bin/bash
chown -R www-data wp-content
chmod -R 755 wp-content

もちろん、私は所有者を変更せずに直接フォルダの権限を 777 にしました。私のようにしないでください、叩かれます（）~~一言で言うと、風蓝の公式サイトが前回ダウンしたのはハッカーに攻撃されたからだと思います~~

長所と短所#

私見ですが、WordPress のような古いフレームワークを Docker に移行することにはいくつかの利点があります：

移行が容易

私が最も好きな利点は、ウェブサイト全体が一つのフォルダにあるため、引っ越すときにデータベースのバックアップや復元が不要で、設定を変更する必要もなく、ディレクトリを圧縮して持ち運ぶだけで済むことです。
デプロイが容易

システム全体の起動は docker compose up -d の一行で済み、停止や再起動も一行で解決できます。また、docker compose logs を使って同時に 2 つのコンテナのログを見ることもできます。原則としてデータベースをコンテナ内に置くことは推奨されていませんが、コンテナは快適です！
より安全（？）

Docker Compose 内では、データベースと WordPress 本体が全て仮想ネットワーク内にあり、通常データベースは外部にポートを公開しないため、攻撃されるリスクが低減します。ただし、この点は疑問が残ります。なぜなら、WordPress がデータベースにアクセスできる限り、既存の WordPress の脆弱性を直接攻撃するコストも非常に低いからです。

もちろん、欠点も明らかです：

データベースおよびファイルアクセスが煩雑

Docker に入れると、ファイルとポートにアクセスするためにマッピングが必要であり、一部の操作はコンテナ内に入る必要があります。データベースとファイル管理に関しては、確かに以前よりも煩雑になりました。ただし、Compose の設定に PHPMyAdmin のようなデータベース管理プログラムを追加することもできます（成品）が、ポート管理が少し面倒で、私は成功しなかったので、自分で試してみてください。
権限の問題を処理する必要がある

前述のように、Docker もまた、コンテナ内外で所有者と権限の不一致が発生しやすく、通常は解決するのに一定の時間を要します（Dockerfile を見直したり、コンテナに入ったりする必要があるかもしれません）。
アクセス速度が遅くなる

これは私が最も受け入れられない欠点です。もともと WordPress はその弱い性能で悪名高いですが、Docker に入れると、ファイルアクセスごとにディレクトリマウントを経由し、データベースリクエストもディレクトリマウントを経由するため、体感的にウェブサイトの読み込み時間が 100% 以上増加しました。

まとめと展望#

全体的に見て、比較的楽しい体験でしたが、この作業をしている間に、サーバー上のパネルが突然 Nginx の設定を読み取れなくなり、非常に遅いアクセス速度と時折ダウンするホストマシンの Nginx の二重の圧力の下で、私はより新しい技術スタックに移行することを考えています。もう 2024 年です。なぜ HTTPS をネイティブにサポートしていないブログフレームワークにこんなに長い時間を費やさなければならないのでしょうか（しかし、実際には WordPress には存在する必要があることが証明されており、現在のコミュニティで最もカスタマイズ性が高く、複数の著者による執筆をサポートするフル機能の CMS です）、新しい選択をする時期です！

今日は新しい最適化方法（Redis、jsDelivr）をいくつか見ました。もし今後まだ余力があれば、少し試してみるかもしれません。結局、今風蓝のほぼすべての投稿が WordPress にあるので、失うのは本当に惜しいです。