DockerオフィシャルのMySQLとmysql/mysql-serverを間違えるとハマる
前回のエントリに引き続き、codebuildでCI環境を作ってる最中にハマったネタ。
dockerhubにあるMySQLのイメージにDockerオフィシャルのmysqlと、オラクルのMySQLチームが管理しているmysql/mysql-serverというのがある。(もちろんこの他にもたくさんある)
ユニットテスト用のMySQLイメージのベースイメージにDockerオフィシャルの方と間違って、mysql/mysql-serverの方を指定しててハマったという話
結論から先に言うと、mysql/mysql-serverの方は設定ファイルの差分追加ができない
(もちろんやりようはある)
ローカルで全テストパスするのに、CodeBuild上でfailするテストケースがある
ローカルはコンテナじゃなくてhomebrewで入れたMySQLを使っていたんだけど、テスト用MySQLコンテナと全く同じデータでテストしたので、CodeBuild側だけfailするのはおかしい。
エラーログを見たら、期待値と実際の結果(actual)を比較してるところでactualが文字化けしてることに気づいた。
MySQLコンテナにmysql-clientで接続し、statusコマンドを打つと、
Server characterset: latin1 Db characterset: latin1
となっている。
なるほどね。
え〜〜〜〜〜〜ちゃんとutf8になるようにmy.cnfに設定書いて/etc/mysql/conf.d/配下に配置したハズですけどぉ〜〜〜〜〜〜〜？？？？？
以下のページとか参考にしてさ〜
間違って、mysql/mysql-serverをベースイメージにしていた
なんでやねんと思い、コンテナにログインして/etc/my.cnfを見たら、
!includedir /etc/mysql/conf.d/
の記載がない。
そりゃ/etc/mysql/conf.d/に配置しても反映されませんわなｗ
って思って自分が書いたDockerfileを見たら、mysql/mysql-serverをベースイメージに指定してたってオチ
しかも残念なことに、/docker-entrypoint-initdb.d/配下に配置したファイルに関してはmysql/mysql-serverも反映してくれるんですよね。
そのせいで気づくのに時間がかかりました。
mysql/mysql-serverのほうがいいところもある
コンテナ立ち上げてからmysql-serverが起動して接続を受け付けられるようになるまでいくらか時間がかかると思うんだけど、mysql/mysql-serverのほうはdocker psを叩いたときにSTATUS欄にその状況を表示してくれる。
healthyって表示されてると、接続可能な状態。
まあDockerオフィシャルのほうも、接続が成功するまでmysql-clientで接続を試みるようなシェルスクリプトを書けば済む話なんですけどね。(もちろん失敗したら一定時間のスリープを挟むようにする)
