非IT企業に勤める中年サラリーマンのIT日記

非IT企業でしかもITとは全く関係ない部署にいる中年エンジニア。唯一の趣味がプログラミングという”自称”プログラマー。

【Xserver VPS】docker-compose.yml のDBパラメータを編集した際に起きた問題と復旧方法

   

docker-compose.yml の 設定（SQLのパスワードなど）を書き換えた場合、コンテナを再起動するだけでは設定が反映されないことがあります。特にデータベースの初期化情報は最初の起動時に作成されるためです。

Dockerを使用した開発環境において、データベースのユーザー名やパスワードを変更する作業は一見単純に思えますが、実際には「データの永続化」や「リバースプロキシ（Nginx Proxy Manager）の仕様」が複雑に絡み合い、単純な設定ファイルの書き換えだけでは解決できない深い迷宮に陥ることがあります。

今回は、docker compose down -v が効かない条件下でのDBリセット、およびコンテナ再生成時に発生するネットワークの不整合を解消し、確実に環境を復旧させるためのルートを記録します。

直面した課題：なぜ設定変更が反映されないのか

docker-compose.yml 内の環境変数（MYSQL_USER, MYSQL_PASSWORD）を書き換え、コンテナを再起動しても接続エラーや 502 Bad Gateway が解消されない。この背景には、Dockerの2つの仕様が関係しています。

  • バインドマウントの不揮発性: ./db_data:/var/lib/mysql のようにホスト側のディレクトリを直接指定している場合、Dockerコマンド（down -v）ではその中身は削除されません。
  • MySQLの初期化仕様: MySQLコンテナは、データディレクトリが空の時にしか環境変数を読み込みません。既にデータが存在する場合、古い認証情報が維持され続けます。

当初は設定現行後に以下のコマンドで解決できると思っていました。-v を付けることで、古いパスワード設定が残っているデータベースの保存領域（ボリューム）も一緒に削除されるはずだからです。が、残念ながら接続失敗となりました。

docker compose down -v
docker compose up -d

 

データベース設定変更の正解ルート

以下の手順は、既存の古いデータとコンテナの残骸を物理的に排除し、新しい設定を確実に適用するためのプロセスです。

ステップ1：コンテナの停止と幽霊コンテナの排除

まず、現在のプロジェクトを停止させます。プロジェクト名（フォルダ名）の変更などでDockerが管理を失っている「古いコンテナ」が存在する場合は、名前の競合を避けるために強制削除を行います。

# プロジェクトの停止
docker compose down

# 名前が競合している古いコンテナの強制削除
docker rm -f my-web-app my-db

 

ステップ2：データディレクトリの物理削除

バインドマウントを使用している場合、これが最も重要な工程です。ホスト側に残っている古い認証情報を物理的に削除します。

# ホスト側のデータフォルダを削除（中身が空になることで次回の起動時に初期化が走る）
rm -rf ./db_data

 

ステップ3：設定ファイルの更新

docker-compose.yml およびアプリケーション（index.php 等）の接続情報を、新しいユーザー名・パスワードへ書き換えます。

 

ステップ4：コンテナの再生成と起動

データディレクトリが空の状態で起動することで、MySQLは新しい設定値に基づいた初期化を実行します。

docker compose up -d

 

インフラ側の接続復旧（Nginx Proxy Manager）

コンテナを再生成すると、Docker内部のIPアドレスが変動します。これにより、Nginx Proxy Manager（NPM）などのリバースプロキシが古いIPを参照し続け、502 Bad Gateway を引き起こします。

ステップ5：外部ネットワークへの再結合

コンテナを外部のプロキシネットワーク（例：npm_default）に手動で接続し直します。

docker network connect npm_default my-web-app

 

ステップ6：プロキシ設定の強制リフレッシュ

NPMに新しいコンテナの場所を再認識させます。

  1. NPMコンテナの再起動: docker restart npm_app_1 で内部DNSキャッシュをクリアします。
  2. 管理パネルでの再保存: NPMの管理画面を開き、対象ドメインの Edit から何も変えずに Save を押します。この操作により、Nginxの upstream 設定が最新の内部IPアドレスで書き換えられます。

結論

DockerにおけるDB設定の変更は、単なるテキストの書き換えではなく、「物理データの破棄」と「ネットワーク経路の再認識」という2つの側面からアプローチする必要があります。

特にバインドマウントを利用している場合は、Dockerの管理外にある実データの状態を常に意識することが、トラブルシューティングの最短距離となります。

 

スポンサーリンク

 - Xserver VPS