Linuxでcompose upできたからといってMacでできるとは限らない

お仕事で Dockerfile や docker-compose.yml を書いていた。

自分の環境(Ubuntu 20.04)・・・OK。
Github Actions・・・OK。

ということでレビューしてもらったのだが、Mac の人がコンテナが立ち上がらなかった、ということがあった。

 

まずは落ち着くことだ。
しばしばあることなので、慌てないで良い。

 

docker の管理内で収まる範囲なら、そういうことはあまりない。
今まで見てきた中でそういうことが起きるのは、

• イメージを作ってコンテナを実行させる過程のどこか
• 永続化するためにファイルシステムをホスト側とつなげているどこか

が多かった。

今回は、Dockerfile で RUN してディレクトリやファイルの操作をしつつ、compose.yml の方でも volumes や entrypont を書いていて、Dockerfile でやった内容が volumes でマウントしたことで見えなくなった、みたいな感じだった。
そういう順番的なもので Linux と Mac の違いが出てくるとは思わなかったが、ドキュメントを探してもどれがどの順番で処理されるかの記述は見つけられなかった。

---

あとはありがちなのが、Permission denied だ。
未だに悩まされる。
ユーザ権限で動作する docker も experimental で出ているようだが、うまく動かない Dockerfile/compose.yml があったので使うのはやめておいた。というより、他の人が普通の docker を使っていたら混乱するので、全員合わせない限りはまだ使わないだろう。

Permission denied でどうするのがよいかよくわからんが、ユーザ指定はするようにした。
何も指定しないと root で動作するので、コンテナからしか書き込まないのであれば問題ないと思うが、ホスト側で作ったファイルを読もうとすると面倒なことになる。あと、ホスト側からそのファイルを見たいときに sudo しないといけないのが地味に嫌だったりもする。

わかりにくいのが、イメージ側が持っているユーザID とホスト側のユーザIDが一致しないときだ。
Linux で最初にアカウントを作るとだいたい 1000 から始まって、それから 1001, 1002 とユーザが追加されるごとにインクリメントされる。
ホスト側が 1001 のユーザでイメージが 1000 だった場合も権限が違うので Permission denied になるだろう。

なので面倒だが id -u や id -g で与えるようにしている。
これをうまいことやってくれるのがユーザ権限で動作する docker かもしれんが、よく知らん。