ローカルで WordPress を立ち上げて、ブラウザで localhost:8888 を開きました。
出てきたのは、見慣れない青いヘッダーの「Html Checker」というツールの画面でした。
WordPress の管理画面でも、初期セットアップ画面でもありません。
そして、その正体に辿り着くまで、私は 1 時間ほど右往左往することになりました。
書いてみるとあっけないのですが、最後にわかったのは「過去の自分が動かしていたコンテナが、まだそこに残っていた」というだけのことでした。けれど、その「だけのこと」を切り分ける手順は意外と知らなかったので、書き残しておきます。
起きていたこと
docker compose up でも wp-env start でもなく、本来であれば WordPress がそのポートで応答するはずでした。私の手元の設定ファイルでは、間違いなく 8888 をマッピングしていたはずです。
にもかかわらず、ブラウザの上半分は知らないアプリのヘッダーで埋まっていました。
最初に疑ったのは、自分の設定ミスでした。.wp-env.json を開き、ポートの記述を確認し、Docker のログを覗き、コンテナは確かに上がっていることだけ何度も見直しました。WordPress のコンテナは動いている。なのに 8888 には別のアプリが座っている。これは、起きていることと頭の中の理解が噛み合わない、地味につらい状況でした。
切り分けに使った 2 つのコマンド
最終的に切り分けに使ったのは、2 つだけです。
1. lsof -i :8888
そのポートを「いま誰が掴んでいるか」を見るためのコマンドです。lsof は「list open files」の略ですが、ポートも開かれたソケットとして見えるので、何のプロセスが listening しているかを名指しで教えてくれます。
lsof -i :8888
これを叩いたら、本来見えるはずの Docker のプロセスではなく、別のものが顔を出しました。あ、これは私が以前に動かしていたものだ。記憶が一気に蘇ったのは、この瞬間でした。
2. docker ps -a
docker ps は今動いているコンテナを見せてくれますが、-a を付けると、過去に存在した（止まっているものも含む）コンテナの一覧が出ます。
docker ps -a
私の環境には、すでに何ヶ月も前のプロジェクトのコンテナが、Exited 状態で大量に残っていました。別の Symfony プロジェクト、ちょっと試していた TypeScript の dev container、もう何年も触っていない PostgreSQL のコンテナ。どれも私が一度立ち上げて、片付けないままにしてきたものです。
その中に、今動いている WordPress のコンテナも紛れているわけですが、ポートを 0.0.0.0:8888->80/tcp のように expose しているのが見えました。「Docker は確かにバインドしようとしている」「でも host 側の何かが先に答えている」という状況が、ここで初めて言語化できました。
解決の手順
切り分けがついてしまえば、解決自体はすぐでした。
過去のコンテナを掃除する
止まっているコンテナを全削除します。
docker container prune -f
docker volume prune -f
docker image prune -f
最初の 1 行で止まっているコンテナがすべて削除されます。ボリュームと未使用イメージは、容量を返してくれるおまけです。残しておきたいプロジェクトがある場合は、prune の前に docker ps -a の出力を見直すのが安全です。
ポートを変える
そもそも 8888 は、私のように HTML 検証ツールを過去に立てたことがあるエンジニアにとっては、もう「自分のポート」とは言いにくい番号でした。
今回はあきらめて 9876 に変えました。.wp-env.json の port を変更し、wp-env destroy で一度落としきって、wp-env start で再起動。
wp-env destroy
wp-env start
新しいポートで開いてみたら、見たかった WordPress の初期画面が、当たり前のように映りました。
学んだこと
ローカル環境は「過去の自分」と地続きにある
本番環境は、ある時点でちゃんと整えて終わりがあります。ローカル環境にはそれがありません。気がつくと、何年も前のプロジェクトのコンテナや、忘れたツールが、ポートを掴んだままになっています。片付けの履歴がない場所ほど、雑然としていきます。
lsof と docker ps -a だけで多くは見える
ポートが取り合いになっているとき、まず叩くべきはこの 2 つだと、今回はっきり実感しました。lsof -i :<ポート番号> で、そのポートを誰が掴んでいるかが一発でわかります。docker ps -a で過去の遺産を含めて見渡せます。
ローカル環境のトラブルでは、アプリより外側で起きていることも意識しておきたいです。
ポート番号は「自分の癖」を引きずる
8888 も 3000 も 8080 も、誰かが必ず使っています。誰かというのは、過去の自分も含めて、です。
新しい環境を立てるときは、最初から少し珍しい番号（9876 のような）にしておくと、未来の自分が困りにくくなる、というのは今回得た小さな教訓です。
結びに
トラブルそのものは数十分で解決しましたが、その間に「過去の自分のコンテナが今の自分の邪魔をしている」という構図が見えたのは、地味に新鮮でした。
ローカル環境を、たまに掃除する。これは、机の上を片付けるのと、たぶん同じくらい大事なことなんだろうと思います。年に一度くらいは、docker ps -a を眺めて、要らないものを prune する習慣を、これからは持っていきたいです。