Dockerの学習をぼちぼち進めている。
Software Design誌の2020年12月号の第1特集に、Docker Composeの初歩としてWordPressを動かすサンプルが掲載されている。これを動かすまでの過程で一つハマったので、備忘として記録しておく。ハマりの原因は、もちろん自分のミスにある。
やろうとしたこと
- 雑誌に掲載している
docker-compose.ymlを使用して、WordPressとMySQLのコンテナからなるアプリケーションを実行する。 - なお雑誌掲載の
docker-compose.ymlは、Docker Hubの公式WordPressイメージに載っているものとほぼ同じ内容。
ハマりの内容
-
docker-compose.ymlを作成する際に編集を誤り、WordPressコンテナとMySQLコンテナのそれぞれに設定するDBユーザー名(WORDPRESS_DB_USER, MYSQL_USER)が一致しない状態になっていた。 - この状態で
docker-compose upでアプリケーションを起動し、http://localhost:8080/のURLでWordPressにアクセスしようとしたところ、(当然の結果として)WordPressがデータベースの接続に失敗し、ブラウザに "Error Establishing a Database Connection"のエラーメッセージが出た。同時に、MySQLコンテナに下記のログが出た。
[Note] Access denied for user 'exampleuser'@'172.19.0.3' (using password: YES)
-
docker-compose.ymlの誤りを修正した後で、コンテナとイメージを削除して再度アプリケーションを起動しようとしたが、エラーが解消されなかった。 - 雑誌掲載の
docker-compose.ymlの代わりに、公式WordPressイメージのサンプルをまるまる上書きコピーしてアプリケーションを起動しても、同じくエラーが解消されなかった。
原因
- 最初に誤った
docker-compose.ymlを使用してコンテナを起動したときに、誤った設定情報をもとにWordPress用/MySQL用のそれぞれにボリュームができた。 -
docker-compose.ymlを修正しても、一度できたボリュームは前回の誤った設定を保持したままになっていた。 - 2回目以降に起動したコンテナが誤った設定を持ったままのボリュームを参照していたために、エラーが解消されなかった。
対応
誤ったdocker-compose.ymlをもとにできたボリュームを削除してアプリケーションを再起動し、正しい設定でボリュームを再作成する。
-
docker-compose down -vでコンテナと同時にボリュームも消す
% docker-compose down -v
Removing wordpress-sd2020dec_wordpress_1 ... done
Removing wordpress-sd2020dec_db_1 ... done
Removing network wordpress-sd2020dec_default
Removing volume wordpress-sd2020dec_wordpress
Removing volume wordpress-sd2020dec_db
-
docker-compose upでアプリケーションを再起動すると、ボリュームが正しい設定で再作成される
余談：docker compose rm -vではボリュームが消えない(2021/05/09時点)
Docker Desktop for Mac/for Windowsのバージョン3.2.1以降では、dockerコマンドにcompose CLIが統合されている。そのため、ハイフンをつけないdocker compose down -vコマンドでもボリュームが消せるはずなのだけれど、実際にはボリュームが削除されなかった(Docker version 20.10.6, build 370c289 on macOS Big Sur 11.3.1)。
この事象はcompose CLIのIssuesで報告されていて(https://github.com/docker/compose-cli/issues/1553) 、修正のプルリクエストも上がっている(https://github.com/docker/compose-cli/pull/1618) ようなので、いずれ修正版がリリースされるのだろう。
余談：解決までの経緯
- Docker Hubの公式WordPressイメージを見たが、収穫なし
-
docker wordpress access denied for userをキーワードにググったところ、今回に類似した事象の報告として https://forums.docker.com/t/wordpress-example-in-docker-compose-fails/30438 を発見。日本語でも同様のことを書いたブログ記事があった(https://swan-once.com/docker-compose-yml_forwordpress/) 。 - これらの記事では、解決法として「
docker-compose.ymlを修正し、MySQL用ボリュームをマウントする先のディレクトリー設定を、元の/var/lib/mysqlから/var/lib/mysql2などに変更する」という方法が示されていた - しかし「公式サイトのサンプルを変えないと動かない」というのは不自然で、真の解決法は別にあるはず
- コンテナ自体は前回起動時のことを覚えていないはずだし、…と考えた結果、「ボリュームに古い情報が残っている」ことに気づいた