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 のウェブサーバーの 2 つのコンテナが作成されます。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 のアドレス設定はそのリダイレクトの Base 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 にあるので、失うのは本当に少し惜しいです。