DevDevデブ!!

プログラミングのこととか書きます。多分。。。

DockerオフィシャルのMySQLとmysql/mysql-serverを間違えるとハマる

前回のエントリに引き続き、codebuildでCI環境を作ってる最中にハマったネタ。

stk132.hatenablog.com

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/配下に配置したハズですけどぉ〜〜〜〜〜〜〜?????

以下のページとか参考にしてさ〜

dqn.sakusakutto.jp

間違って、mysql/mysql-serverをベースイメージにしていた

なんでやねんと思い、コンテナにログインして/etc/my.cnfを見たら、

!includedir /etc/mysql/conf.d/

の記載がない。

そりゃ/etc/mysql/conf.d/に配置しても反映されませんわなw

って思って自分が書いた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で接続を試みるようなシェルスクリプトを書けば済む話なんですけどね。(もちろん失敗したら一定時間のスリープを挟むようにする)