
背景
以前の記事でdocker-composeを利用してDjango+MySQLの環境を作成しました。
今回、別のプロジェクトでDjango+MySQLのアプリケーションを作成することにしたので、久々環境を構築したところ、以下のエラーにハマったので備忘録として記載します。
エラー内容
エラーはこんな感じでした。
1 | django-web-1 | django.db.utils.OperationalError: (1044, "Access denied for user 'django'@'%' to database 'django'") |
認証に失敗しているようです…
docker-compose.ymlの確認
まずMySQLコンテナの認証を設定しているdocker-compose.ymlを確認します。
1 | version: '3' |
問題なさそうです。
Djangoのデータベース接続設定の確認
次に接続に行っているDjango側の設定を確認します。プロジェクト配下のsettings.pyを確認します。
1 | DATABASES = { |
こちらも問題なさそうです。
原因
だいぶ長い間ハマって気づいたのは、mysqlのvolumeが意図しない動作を引き起こしているのではないかということでした。
一度volumeを削除してみます。
1 | $ docker volume rm 該当のvolume |
(volumeの確認はdocker volume lsで行いました)
削除後にdocker-compose upを行うと、認証のエラーはなくなり、無事アプリケーションが起動しました。
公式ドキュメントを確認
MySQLコンテナのドキュメントのEnvironment Variablesを確認するとちゃんと書いてありました。
Do note that none of the variables below will have any effect if you start the container with a data directory that already contains a database: any pre-existing database will always be left untouched on container startup.
Google翻訳にすると
すでにデータベースが含まれているデータディレクトリでコンテナを起動した場合、以下の変数はいずれも効果がないことに注意してください。既存のデータベースは、コンテナの起動時に常に変更されません。
ということなので、認証情報を変更する場合は毎回volumeを削除する必要があるということでした。
まとめ
MySQLコンテナはvolumeを使っている場合、認証情報は環境変数で変更することはできないことがわかりました。(最初の1回だけ環境変数で指定)
認証情報だけではなく、データベース名なども変更する場合は、既存のvolumeを削除してから起動すると、環境変数で指定した値が反映されます。