wp-envにAdminerとMailHogを組み合わせる開発環境

記事内に広告が含まれていることがあります。

Local(旧Local by flywheel)から中々wp-envに移行できない理由としてよく「データベースマネジメントツールとMailHogがない」ことが挙げられます。

ということでnpm run wp-env startで全部立ち上がるようにしていきます。

WordPressカテゴリーCTA
\ココナラでWordPressエラー修正サービス始めました!/

ココナラでWordPressのエラー解決サービスを始めました!

追加オプション無しで3,000円から受け付けておりますが、新規会員登録で300円、僕の紹介コードを入力すると1,000円分のポイントが貰えるので実質1,700円から利用することができます!

  • 突然画面が真っ白になった
  • 英語のエラーが表示されてどうしたらいいかわからない
  • とにかく困っている

どんなことでもぜひお気軽にご相談ください!

紹介コード:K0GR23
スポンサーリンク
スポンサーリンク

wp-env × Adminer × MailHogの要点

  • データベースのチェックをGUIで行える、書き換えも容易
  • WordPressのメール機能に関する開発を行える

wp-envにAdminerとMailHogが組み合わさると何が嬉しいかというとこの2点。

僕はSend Chat ToolsというSlackやDiscordにWordPressのコメント通知やログイン通知、アップデート通知、Rinkerの終売通知なんかを送信するプラグインを作っているのですが、もし正常に遅れなかった場合メール通知する必要があります。

そのためMailHogはぜひとも欲しい機能でした。

wp-envは標準でこの2つに対応していないので、連携するDockerコンテナを建ててこれらの機能を使えるようにします。

GitHubリポジトリ

当記事で解説しているコードは以下のリポジトリにあります。

GitHub Repository:https://github.com/braveryk7/wp-env-with-adminer-mailhog

要点

  • compose.yamlを用意しAdminerとMailHogの設定を記述する
  • .wp-env.jsonにはメールに関する定数を記述する
  • docker compose up -ddocker compose downwp-envと連動するようにする

基本的に操作を増やすのはナンセンスなので、.wp-env.jsonに用意されているライフサイクルスクリプトセクションを使って自動的に目的のコンテナが立ち上がり、終了時には自動的にコンテナが終了するように設定します。

ただしこれは仕組み上、どうしても既存のwp-envコマンドとdocker composeコマンドの組み合わせだけでは行えないので簡単なシェルスクリプトを書いてそれを実行するようにします。

環境

僕の環境構築時点での各種バージョンです。

$ node -v
v18.17.1

$ npm -v
9.6.7

$ docker -v
Docker version 25.0.0, build e758fe5

執筆時現在、docker-composeコマンドはdockerコマンドのサブコマンドになりました。(コマンド自体は`docker composeコマンドのエイリアスとして残っています。

そのため当記事ではdocker-composeコマンドではなくdocker composeコマンドを使用しております。

また、docker-compose.ymlが非推奨になりcompose.yamlが推奨されています。

古いDocker環境で実行する場合等は適宜読み替えてください。

# package.json
{
  "devDependencies": {
    "@wordpress/env": "^9.2.0"
  }
}

特に@wordpress/envパッケージはバージョンによって結構大きな違いがあるので、必ず最新情報を公式でキャッチアップしてください(動かない等あったら教えて下さると嬉しいです)。

手順

実際に必要なファイル群を用意していきます。

ファイル構成

/
├── .wp-env.json
├── /bin
│   └── after-start-scripts.sh
├── /node_modules
│   └── /.bin
│       └── wp-env
├── compose.yaml
├── package-lock.json
└── package.json

必須なファイルは.wp-env.jsoncompose.yamlぐらいです。

.wp-env.jsonはwp-envの立ち上げを、compose.yamlはAdminerとMailHogの立ち上げを行います。

より便利に使えるようにbinディレクトリ配下にシェルスクリプトをおいてあります。

ファイル作成

まずは必要なファイル群を生成していきます。

# git管理するなら
$ git init

# ディレクトリの作成
$ mkdir bin

# ファイル作成
# package.jsonはnpm initしても可
# .wp-env.jsonは後で作成
$ touch bin/after-start-scripts.sh compose.yaml package.json

# package.jsonはnpm install時、正しいjson形式である必要がある
# そのため最低限jsonとして認識されるように{}を記述
$ echo "{}" > package.json

続いて@wordpress/envパッケージを導入します。

起動できるかテストも兼ねて一度動かしてみます。

# @wordpress/envインストール
$ npm i -D @wordpress/env

# wp-envが実行されるかどうか確認
# .wp-env.jsonが無いと警告されるが一旦無視
$ node_modules/.bin/wp-env start

Warning: could not find a .wp-env.json configuration file and could not determine if
'/home/user_name/develop/wp-env-with-adminer-mailhog'
is a WordPress installation, a plugin, or a theme.

WordPress development site started at http://localhost:8888
WordPress test site started at http://localhost:8889
MySQL is listening on port 32784
MySQL for automated testing is listening on port 32785

 ✔ Done! (in 6s 592ms)

これで表示されたURLにアクセスして問題が無いか確認してください。

続いてこのコンテナのハッシュ値を取得します。

# ハッシュ値取得
# この場合ハッシュ値は242ad077a237e5d5c0781dd085d26fdf
# ハッシュ値はcompose.yamlで使用する
$ node_modules/.bin/wp-env install-path
/home/user_name/wp-env/242ad077a237e5d5c0781dd085d26fdf
✔  (in 0s 605ms)

# .wp-env.json作成
$ touch .wp-env.json

ハッシュ値は後ほど使用するのでどこかにメモしておくかターミナルに表示しておいてください。

.wp-env.json

{
    "config": {
        "WP_DEBUG": true,
        "WP_DEBUG_LOG": true,
        "WP_DEBUG_DISPLAY": true,
        "WPMS_ON": true,
        "WPMS_SMTP_HOST": "mailhog",
        "WPMS_SMTP_PORT": 1025,
        "WPMS_MAILER": "smtp"
    },
    "core": "https://ja.wordpress.org/latest-ja.zip",
    "env": {},
    "mappings": {},
    "phpVersion": "8.2",
    "port": 59650,
    "testsPort": 59651,
    "plugins": [
        "https://downloads.wordpress.org/plugin/query-monitor.zip",
        "https://downloads.wordpress.org/plugin/wordpress-beta-tester.zip",
        "https://downloads.wordpress.org/plugin/wp-crontrol.zip",
        "https://downloads.wordpress.org/plugin/wp-multibyte-patch.zip",
        "https://downloads.wordpress.org/plugin/wp-mail-smtp.zip"
    ],
    "themes": [
        "https://github.com/xserver-inc/cocoon/archive/refs/heads/master.zip"
    ],
    "lifecycleScripts": {
        "afterStart": "sh bin/after-setup-scripts.sh"
    }
}

色々書いてありますが、重要な部分をピックアップします。

    "config": {
        "WP_DEBUG": true,
        "WP_DEBUG_LOG": true,
        "WP_DEBUG_DISPLAY": true,
        "WPMS_ON": true,
        "WPMS_SMTP_HOST": "mailhog",
        "WPMS_SMTP_PORT": 1025,
        "WPMS_MAILER": "smtp"
    },

まずconfigブロックでWP_DEBUGの設定と後ほど紹介するWP Mail SMTPというプラグインの定数を設定しています。

他にもWP Mail SMTP向けの設定はありますが、とりあえず最低限これだけ記述しておけば動きます。

特にWPMS_SMTP_HOSTは後述するcompose.yamlcontainer_nameと合わせるようにしてください。

    "plugins": [
        "https://downloads.wordpress.org/plugin/query-monitor.zip",
        "https://downloads.wordpress.org/plugin/wordpress-beta-tester.zip",
        "https://downloads.wordpress.org/plugin/wp-crontrol.zip",
        "https://downloads.wordpress.org/plugin/wp-multibyte-patch.zip",
        "https://downloads.wordpress.org/plugin/wp-mail-smtp.zip"
    ],

ここでは開発に便利な各種プラグインをまとめてインストールしていますが、一番最後のwp-mail-smtp.zipが今回の肝です。

WP Mail SMTPはWordPressのメール機能を強化するプラグインで、テストメールの送信機能があるため採用しています。

それ以外のプラグインは不要なら削除してください。

    "themes": [
        "https://github.com/xserver-inc/cocoon/archive/refs/heads/master.zip"
    ],

テーマは日本でも人気があり無料で使えるCocoonをインストールしてあります、これも好みで変えてください。

後で手動でアップロードして好きなテーマを実装することももちろん可能です。

    "lifecycleScripts": {
        "afterStart": "sh bin/after-start-scripts.sh"
    }

最後のlifecycleScriptsセクションはざっくりいうと「特定のタイミングで特定の処理が走らせられますよ」というもの。

ここではafterStartというタイミングでシェルスクリプトを走らせています。

その名の通り、npm run wp-env startコマンドが走った後に実行されます。

bin/after-start-scripts.sh

npm run wp-env run cli -- wp plugin delete akismet hello
docker compose up -d

ここでは試しにコンテナ内のwp-cliを動かしてデフォルトで入っている邪魔なAkismetとHello Doryという2つのプラグインを削除しています。

重要なのは2行目、docker compose up -dコマンドを使って後述するcompose.yamlを元にAdminerとMailHogコンテナを立ち上げています。

compose.yaml

volumes:
  maildir: {}

services:
  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080
    networks:
      - wpnetwork

  mail:
    image: mailhog/mailhog
    container_name: mailhog
    ports:
      - 1025:1025
      - 8025:8025
    environment:
      MH_STORAGE: maildir
      MH_MAILDIR_PATH: /tmp
    volumes:
      - maildir:/tmp
    networks:
      - wpnetwork

networks:
  wpnetwork:
    external:
      name: 242ad077a237e5d5c0781dd085d26fdf_default

今回一番重要な部分がこのcompose.yamlです。

volumes:
  maildir: {}

まずはMailHogのメールがコンテナを終了させるたびに消えてしまうのは困るので永続化しています。

  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080
    networks:
      - wpnetwork

Adminerの設定部分です。

バージョン指定がある場合はバージョンを記述してください。

portsは空いてるものであれば何でも良いですが、何故か僕のWSL/Ubuntu環境だと59000番台以降が使えませんでした。どうして・・・!

networkswpnetworkという名称を指定しています。

  mail:
    image: mailhog/mailhog
    container_name: mailhog
    ports:
      - 1025:1025
      - 8025:8025
    environment:
      MH_STORAGE: maildir
      MH_MAILDIR_PATH: /tmp
    volumes:
      - maildir:/tmp
    networks:
      - wpnetwork

MailHogの方はコンテナ名をmailhogと明示しています、これは.wp-env.jsonで指定したWPMS_SMTP_HOSTで使用するためです。

portsは2つ設定してありますが、MailHogコンテナがデフォルトで1025番をSMTPに、8025番をWeb UI用に充てているのでそのまま同じポート番号を充てています。

networksにはAdminerと同様wpnetworkを指定しています。

networks:
  wpnetwork:
    external:
      name: 242ad077a237e5d5c0781dd085d26fdf_default

最後のnetworkswp-envdocker composeそれぞれで立ち上げたコンテナを同じネットワーク内であると明示しています。

ネットワーク全体をwpnetworkという名前で定義し、wp-env側で作成するネットワークを接続するために冒頭取得したハッシュ値を記述します。

wp-envで起動したコンテナは「ハッシュ値_default」という命名規則でNAMEがつくので、特に_defaultを忘れないようにしましょう。

package.json

最後にwp-envコマンドをいちいちnode_modulesから指定するのは面倒なので、package.jsonのscriptsにコマンドを記述します。

{
  "scripts": {
    "wp-env": "wp-env"
  },
  "devDependencies": {
    "@wordpress/env": "^9.2.0"
  }
}

これでnpm run wp-envというコマンドで呼び出せるようになりました。

wp-env × Adminer × MailHog 稼働チェック

それでは準備ができたので実際に稼働してみましょう!

一度wp-envを起動しているので、--updateオプションをつけて再起動させます。

$ npm run wp-env start --update

> wp-env
> wp-env start

WordPress development site started at http://localhost:59650
WordPress test site started at http://localhost:59651
MySQL is listening on port 32788
MySQL for automated testing is listening on port 32789

 ✔ Done! (in 48s 25ms)

無事起動ができたようです。

$ docker ps
CONTAINER ID   IMAGE                                              COMMAND                  CREATED          STATUS          PORTS                                                                                  NAMES
8523fb34e763   adminer                                            "entrypoint.sh php -…"   24 seconds ago   Up 22 seconds   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp                                              wp-env-with-adminer-mailhog-adminer-1
5d3a69adbbef   mailhog/mailhog                                    "MailHog"                24 seconds ago   Up 22 seconds   0.0.0.0:1025->1025/tcp, :::1025->1025/tcp, 0.0.0.0:8025->8025/tcp, :::8025->8025/tcp   mailhog
d6a32d426eb4   242ad077a237e5d5c0781dd085d26fdf_cli               "docker-entrypoint.s…"   37 seconds ago   Up 35 seconds                                                                                          242ad077a237e5d5c0781dd085d26fdf-cli-1
5ff14b9c9b5a   242ad077a237e5d5c0781dd085d26fdf_tests-cli         "docker-entrypoint.s…"   37 seconds ago   Up 35 seconds                                                                                          242ad077a237e5d5c0781dd085d26fdf-tests-cli-1
43bdc86764d6   242ad077a237e5d5c0781dd085d26fdf_tests-wordpress   "docker-entrypoint.s…"   37 seconds ago   Up 35 seconds   0.0.0.0:59651->80/tcp, :::59651->80/tcp                                                242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1
d7241cbb6603   242ad077a237e5d5c0781dd085d26fdf_wordpress         "docker-entrypoint.s…"   37 seconds ago   Up 35 seconds   0.0.0.0:59650->80/tcp, :::59650->80/tcp                                                242ad077a237e5d5c0781dd085d26fdf-wordpress-1
f24a2125bb97   mariadb                                            "docker-entrypoint.s…"   37 seconds ago   Up 36 seconds   0.0.0.0:32789->3306/tcp, :::32789->3306/tcp                                            242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1
41f310e73dcc   mariadb                                            "docker-entrypoint.s…"   57 seconds ago   Up 55 seconds   0.0.0.0:32788->3306/tcp, :::32788->3306/tcp                                            242ad077a237e5d5c0781dd085d26fdf-mysql-1

docker psコマンドでコンテナ状況を見てみると、Adminrとmailhogのコンテナが確認できます。

今回の設定通りなら、以下のURLでアクセスができるはずです。

コンテナURL
WordPress環境http://localhost:59650
WordPressテスト環境http://localhost:59651
Adminerhttp://localhost:8080
MailHoghttp://localhost:8025
wp-envとdocker composeで立ち上げたコンテナのURL

WordPress環境

WordPress環境

WordPress環境にアクセスすると問題がなければサイトトップページが表示されます。

もちろん/wp-adminへアクセスするとログインページが表示されます。

項目
IDadmin
Passwordpassword
WordPressログインID/Pass

初期設定は上記のIDとパスワードでログインが行なえます。

Cocoonがインストールされている

.wp-env.jsonで指定したCocoonがインストールされています。

本来なら.wp-env.jsonthemesブロックで指定したテーマが有効化されるはずですがなぜかされていません。

理由は分かりませんが、立ち上げた時点で明示的に有効化したい場合は後述するwp-cliを使いましょう。

プラグイン一覧

こちらはプラグインページ。

ライフサイクルスクリプトで指定したように、デフォルトでは必ずインストールされているAkismetとHello Dollyが削除されています。

ライフサイクルスクリプトはどんなLinuxコマンドも実行できるので、立ち上げ段階から記事データを入れておきたいとかタイムゾーン設定、パーマリンク設定等を記述しておけばとても便利になります。

先程のテーマの有効化も、必ずこのテーマを使うぞ!と決まっているならシェルスクリプトに追記します。

# bin/after-start-scripts.sh

# npm run wp-env run cli -- wp theme activate <theme_slug>
# theme_slugはテーマの名前のようなもの
# Twenty-Twenty Fourならtwentytwentyfour
# 今回のCocoonの場合、本来はcocoon-masterだがmasterを指定する
# 以下はTwenty-Twenty Fourを明示的に有効化
npm run wp-env run cli -- wp theme activate twentytwentyfour

Adminerコンテナ

Adminerコンテナ

Adminerはlocalhost:8080でアクセスできます。

項目
サーバmysql
ユーザ名root
パスワードpassword
データベースwordpress
MySQLの接続情報

デフォルトでは以上の情報で接続可能、これはwp-envで立ち上げたWordPressのwp-config.phpに記述された情報で、wp-cliを使って確認することができます。

# ~/wp-env/<ハッシュ値>/<WordPressのバージョン>/wp-config.phpに記載されいてる情報
# <WordPressのバージョン>は今回ならlatest-ja

$ npm run wp-env run cli -- wp config get DB_HOST
mysql

$ npm run wp-env run cli -- wp config get DB_USER
root

$ npm run wp-env run cli -- wp config get DB_PASSWORD
password

$ npm run wp-env run cli -- wp config get DB_NAME
wordpress
Adminerの管理画面

無事ログインできました。

MailHogコンテナ

MailHog

MailHogはlocalhost:8025でアクセスできます。

メールがMailHogで正常に受信(WordPress側から送信)できるかテストします。

WP Mail SMTPのToolsページ

左側のメニューからWP Mail SMTP->ToolsにアクセスしSend Emailボタンをクリックします。

WP Mail SMTPからのテストメール

MailHog側でテストメールが受信できていればOK、これでメール送信を伴う機能のテストはMailHog経由で行なえます。

wp-env × Adminer × MailHogの弱点改善

以上で欲しい機能は満たせましたが、実は問題点がいくつかあります。

終了はwp-envとdocker composeを順番通り手動で行う必要がある

まずは終了時。

wp-envはコンテナが必要なくなった時、または.wp-env.jsonを書き換えてリスタートする時に一度明示的にコンテナを削除します。

その時同時にネットワークも削除しますが、AdminerやMailHogのコンテナがアクティブの場合この2つのコンテナもネットワークに接続されているため、先にwp-envのコンテナを終了/破棄/再起動するとネットワークが削除できずエラーが出ます。

# 以下はwp-env stopの例だがwp-env start --updateもwp-env destroyも同様の結果となる
$ npm run wp-env stop

> wp-env
> wp-env stop

✖ Error while running docker compose command.
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1  Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1  Removing
Container 242ad077a237e5d5c0781dd085d26fdf-cli-1  Removed
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1  Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1  Removing
Container 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1  Removed
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1  Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1  Removing
Container 242ad077a237e5d5c0781dd085d26fdf-wordpress-1  Removed
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1  Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1  Removing
Container 242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1  Removed
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1  Stopping
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1  Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1  Removing
Container 242ad077a237e5d5c0781dd085d26fdf-mysql-1  Removed
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1  Stopped
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1  Removing
Container 242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1  Removed
Network 242ad077a237e5d5c0781dd085d26fdf_default  Removing
Network 242ad077a237e5d5c0781dd085d26fdf_default  Error
failed to remove network 242ad077a237e5d5c0781dd085d26fdf_default: Error response from daemon: error while removing network: network 242ad077a237e5d5c0781dd085d26fdf_default id e395e5150627852f03cb6b1849f83aeb98c9c4ce72774be3c733f36ba0ef9991 has active endpoints

最後のfailed to remove networkがそれで、ネットワークの削除に失敗しています。

$ docker ps
CONTAINER ID   IMAGE             COMMAND                  CREATED        STATUS        PORTS                                                                                  NAMES
8523fb34e763   adminer           "entrypoint.sh php -…"   13 hours ago   Up 13 hours   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp                                              wp-env-with-adminer-mailhog-adminer-1
5d3a69adbbef   mailhog/mailhog   "MailHog"                13 hours ago   Up 13 hours   0.0.0.0:1025->1025/tcp, :::1025->1025/tcp, 0.0.0.0:8025->8025/tcp, :::8025->8025/tcp   mailhog

wp-envのコンテナは全て削除されています。

$ docker network ls
NETWORK ID     NAME                                       DRIVER    SCOPE
e395e5150627   242ad077a237e5d5c0781dd085d26fdf_default   bridge    local

しかしこのようにnetworkはアクティブなままです。

これの何が問題かというと、wp-envのライフサイクルスクリプトにはafterStartと同じくafterDestroyが存在します。

つまりafterStartと同じノリでシェルスクリプトにdocker compose downを書いてafterDestroyで呼んでもwp-envがエラーで落ちてしまうのでafterDestroyが実行されずコンテナの削除ができません。

wp-env start

wp-envを実行してコンテナ/ネットワークが立ち上がってからAdminer/MailHogコンテナを追加しているので問題なし

wp-env stop/destroy/start –update

wp-envコンテナ/ネットワークを先に削除するが、まだAdminer/MailHogがネットワークに存在したままになるためエラーになる

これを解決する手段はいくつかありますが、重要な点は以下の順番を守ること。

  1. docker compose downコマンドでAdminerとMailHogコンテナを終了させる
  2. wp-envコマンドを実行する

この順番さえ守れればOK。

スマートな方法として、package.jsonにカスタムコマンドを設定することが考えられます。

{
  "scripts": {
    "wp-env": "wp-env",
    "env-start": "wp-env start",                                   //追記
    "env-stop": "docker compose down && wp-env stop",              //追記
    "env-restart": "docker compose down && wp-env start --update", //追記
    "env-rm": "docker compose down && wp-env destroy"              //追記
  },
  "devDependencies": {
    "@wordpress/env": "^9.2.0"
  }
}

今回はenv-stopという名前で定義してみました、このように明示的にdocker compose downを行ってからwp-env stopを順番に実行しています。

カスタムコマンド名は何でも良いんですが “wp-env”という名称は混乱するので避けた方が良いでしょう、他にも”server-stop”や”dev-stop”等が考えられます。

ちなみにnpm scripts内にスペース(例えばenv stop)を使うとコマンド実行時にnpm run "env stop"のように明示的にクオーテーションで囲う必要があり面倒なので避けた方がベター。

stopと同じようにenv-start、env-restart、env-rmを定義しています。

wp-env startはライフサイクルスクリプトを使わずに直接カスタムコマンドを作って使うこともできます、これはお好みの方でOK。

ライフサイクルスクリプトにはもう1つ、afterCleanも存在しますが僕は全く使わないので記述していません。

ただしafterCleanはコンテナとネットワークの削除を行わないので、docker compose donwを先に行う必要はありません。

複数wp-env環境が存在するとdestroyに失敗する

wp-envは1つ仮想環境を建てると合計5つのdocker imageを使用します。

# wp-env実行
$ npm run wp-env start

# docker image確認
$ docker image ls
REPOSITORY                                         TAG       IMAGE ID       CREATED        SIZE
1249c7a84e1c8b5a5dcf75e0841ed384_cli               latest    0eeceacf00f0   22 hours ago   457MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-cli         latest    0eeceacf00f0   22 hours ago   457MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-wordpress   latest    e906d2d1a247   8 days ago     815MB
1249c7a84e1c8b5a5dcf75e0841ed384_wordpress         latest    e906d2d1a247   8 days ago     815MB
mariadb                                            latest    2b54778e06a3   2 months ago   404MB

ではwp-envを2つ使用、例えばプラグインAとプラグインBの開発を行っており、それぞれの環境で利用するとどうでしょう。

# 別プラグインに移動
$ cd /path/to/plugin_b/

# wp-env実行
$ npm run wp-env start

# dockerコンテナ確認
$ docker ps
CONTAINER ID   IMAGE                                              COMMAND                  CREATED          STATUS          PORTS                                         NAMES
6b3e24ebfd76   242ad077a237e5d5c0781dd085d26fdf_tests-cli         "docker-entrypoint.s…"   33 seconds ago   Up 31 seconds                                                 242ad077a237e5d5c0781dd085d26fdf-tests-cli-1
0938b959c846   242ad077a237e5d5c0781dd085d26fdf_cli               "docker-entrypoint.s…"   33 seconds ago   Up 32 seconds                                                 242ad077a237e5d5c0781dd085d26fdf-cli-1
d5ee5778eae9   242ad077a237e5d5c0781dd085d26fdf_tests-wordpress   "docker-entrypoint.s…"   34 seconds ago   Up 32 seconds   0.0.0.0:59651->80/tcp, :::59651->80/tcp       242ad077a237e5d5c0781dd085d26fdf-tests-wordpress-1
8bd9b0e50310   242ad077a237e5d5c0781dd085d26fdf_wordpress         "docker-entrypoint.s…"   34 seconds ago   Up 32 seconds   0.0.0.0:59650->80/tcp, :::59650->80/tcp       242ad077a237e5d5c0781dd085d26fdf-wordpress-1
ec2dd15e0105   mariadb                                            "docker-entrypoint.s…"   34 seconds ago   Up 32 seconds   0.0.0.0:32805->3306/tcp, :::32805->3306/tcp   242ad077a237e5d5c0781dd085d26fdf-tests-mysql-1
341d26832857   mariadb                                            "docker-entrypoint.s…"   57 seconds ago   Up 56 seconds   0.0.0.0:32804->3306/tcp, :::32804->3306/tcp   242ad077a237e5d5c0781dd085d26fdf-mysql-1
0e29b54ca37e   1249c7a84e1c8b5a5dcf75e0841ed384_tests-cli         "docker-entrypoint.s…"   6 minutes ago    Up 6 minutes                                                  1249c7a84e1c8b5a5dcf75e0841ed384-tests-cli-1
6ced35965caa   1249c7a84e1c8b5a5dcf75e0841ed384_cli               "docker-entrypoint.s…"   6 minutes ago    Up 6 minutes                                                  1249c7a84e1c8b5a5dcf75e0841ed384-cli-1
7a519859bb06   1249c7a84e1c8b5a5dcf75e0841ed384_tests-wordpress   "docker-entrypoint.s…"   6 minutes ago    Up 6 minutes    0.0.0.0:49651->80/tcp, :::49651->80/tcp       1249c7a84e1c8b5a5dcf75e0841ed384-tests-wordpress-1
0e4e4be07091   1249c7a84e1c8b5a5dcf75e0841ed384_wordpress         "docker-entrypoint.s…"   6 minutes ago    Up 6 minutes    0.0.0.0:49650->80/tcp, :::49650->80/tcp       1249c7a84e1c8b5a5dcf75e0841ed384-wordpress-1
01f0f2fb18a1   mariadb                                            "docker-entrypoint.s…"   6 minutes ago    Up 6 minutes    0.0.0.0:32803->3306/tcp, :::32803->3306/tcp   1249c7a84e1c8b5a5dcf75e0841ed384-tests-mysql-1
55d74d4c7325   mariadb                                            "docker-entrypoint.s…"   7 minutes ago    Up 7 minutes    0.0.0.0:32802->3306/tcp, :::32802->3306/tcp   1249c7a84e1c8b5a5dcf75e0841ed384-mysql-1

この通り、242ad077a237e5d5c0781dd085d26fdf1249c7a84e1c8b5a5dcf75e0841ed384の2つの環境が存在していることが確認できます。

# docker image確認
$ docker image ls
REPOSITORY                                         TAG       IMAGE ID       CREATED        SIZE
1249c7a84e1c8b5a5dcf75e0841ed384_cli               latest    0eeceacf00f0   22 hours ago   457MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-cli         latest    0eeceacf00f0   22 hours ago   457MB
242ad077a237e5d5c0781dd085d26fdf_cli               latest    0eeceacf00f0   22 hours ago   457MB
242ad077a237e5d5c0781dd085d26fdf_tests-cli         latest    0eeceacf00f0   22 hours ago   457MB
242ad077a237e5d5c0781dd085d26fdf_wordpress         latest    e906d2d1a247   8 days ago     815MB
1249c7a84e1c8b5a5dcf75e0841ed384_tests-wordpress   latest    e906d2d1a247   8 days ago     815MB
1249c7a84e1c8b5a5dcf75e0841ed384_wordpress         latest    e906d2d1a247   8 days ago     815MB
242ad077a237e5d5c0781dd085d26fdf_tests-wordpress   latest    e906d2d1a247   8 days ago     815MB
mariadb                                            latest    2b54778e06a3   2 months ago   404MB

しかしdocker imageを確認するとmariadbは1つしかありません。

wp-env destroyはdocker imageの削除も行うので、つまり2つ以上のwp-env環境が存在している場合、wp-env destroyは100%失敗します。

コンテナ使用中はimageを削除できないためです。

何が言いたいかというと、wp-envのライフサイクルスクリプトにおけるafterDestroyは100%実行されることが保証できないということです。

あまりafterDestroyを多用する場面は思いつかないとはいえ、提供されている機能なのに利用できない場面があるというのは安心して使用できません。

そのため、基本的にはafterDestroyは使わずにnpm scripts内で完結するほうが現状好ましいといえます。

wp-envにAdminerとMailHogを組み合わせる開発環境 まとめ

wp-envは非常に簡単なコマンドで開発環境の構築が行なえ、更に少し工夫することでAdminerやMailHogといった非常に便利なコンテナを連携させることができます。

特に複数人で開発を行っているなら、.wp-env.jsoncompose.yamlをコミットしてGitHubにプッシュするだけで全員が同じ環境を共有できます。

まだ正直wp-env自体に荒削りな部分がある点は否めませんが、これからWordPress開発を行うなら必ず導入したい必須ツールです。

WordPress&PHPUnitのモダンユニットテスト環境をwp-envを使って構築する
WordPressはPHPUnit関連に限らず良くも悪くも歴史あるプロジェクトなのでレガシーな情報にぶち当たることが非常に多いです。 特にユニットテストに関しては正直関心も低いのか情報が多いとは言えません。 まして公式の情報も充実していると...
SynologyのNAS上でDockerを動かしてPython×seleniumのスクレイピングを定期実行する
seleniumを使ったスクレイピングは非常に便利ですが、毎日定期実行するとなると必要になるのは実行環境。 手元のパソコンで動かしても良いんですが、やはりパソコンは電源を切ることもあるしあまりローカルの環境汚染もしたくない。 そこで思い立っ...
スポンサーリンク
WordPress
スポンサーリンク
\この記事いいね!と思ったらシェアしてね/
スポンサーリンク
L'7 Records

コメント