結果

プラグインやテーマが原因でコンテナが落ちることがありそうです。
自分の場合以下のようなタイポがあり
おそらくそれが何らかの形でdocker側のキャッシュに記録されてしまったような感じでした。

タイポしてしまった部分

misstype.php


switch ($type):
        case 'miss':
            return 'miss';
            break;
        default;//←コロンをセミコロンでタイポしている
            break;
endswitch;

get_template_part('no', 'file');//←存在しないファイルを呼び出している

状況

ローカルで運用していたwordpressコンテナが落ちるようになりました。
原因がよくわからない状態。
直前の作業はいつもやっているプラグインやテーマの編集作業でした。

環境

nginxプロキシコンテナ　→　wordpressコンテナ　→　mysqlコンテナをdocker-composeで運用
立ち上げ時セッティングするためDockerfile＋シェルスクリプトファイルからイメージを作成しています。

同様の環境で複数のwordpressサイトを運用しており
nginxプロキシでURL振り分けをしている。

ただし運用ルールとしてdocker-compose upするサイトは１つとし
docker container ls した際に３つ以上のコンテナが表示されることはないように運用している。

エラーの具体的な動作

docker-compose up -d --buildで立ち上げると
wordpressのコンテナだけがrestartされ(restartは繰り返される)
ブラウザでアクセスすると502になるという現象。

最初に探ったこと

以前似たようなエラーの際、イメージを作り直したら治ったという経験があったので試すも改善されず。

remake.sh


$ docker image rm wordpress
$ docker build --no-cache

２番目に探ったところ

volumeも削除して検証。(この時imageも再度削除して検証)
テストやエラーで自動生成されたよくわからない乱数volumeもこの機会に整理してみました。
>>docker volumeの中身を確認してみました
結果は改善されず。

3番目に探ったところ

docker-compose.yml
Dockerfile
docker-entrypoint.sh
apacheのconfファイル（バインドマウントで最初に読み込んでいてバーチャルホストを設定している）
全てdiff、目視で確認するも以上なし。

4番目に探ったところ

エラーの動きから可能性は薄いと思いながら
バインドマウントしているwp-contentを
docker-compose.ymlで指定せず立ち上げてみる。

結果立ち上がりました。。。
~~具体的な原因は現在調査中です。~~

最終的に解決した流れ

その後git logなどをみながら原因を探っているところ冒頭のタイポを発見。
修正しdocker-compose up -dをしたり、docker-compose build --no-cacheしたり
試すも状況は変わらず。

タイポする前までコミットを巻き戻し
docker image rm
docker volume rm
DockerFileでwordpressのバージョンをあげて立ち上げ
つまり全く違うイメージを立ち上げてみたところ
無事立ち上がるようになりました。

原因っぽいところ

最初に書いたタイポした部分がおそらくdockerのキャッシュに入ってしまった！？
もしかするとプラグインも関係しているかもしれません。
ヌルッと治ってしまったので原因が特定できませんでした（汗

dockerのwordpressコンテナが落ちる原因

結果