あらすじ
最近、大学の卒業課題でDockefileを弄っている。
実験とかに使うDockerfile達はなんとなくGithubから持ってきている。その際に、一部のDockerfileがビルドに失敗し、実験が成立しない事態に直面した経験が何度かある。
Dockerを使う利点の１つに、どんな環境で実行しても出力結果は同じになるというものがある。だけど実際には、どんな環境で実行してもビルドエラーを吐く、再現性に対して中指立ててる悪夢のようなDockerfileが巷に点在している模様。
私の場合は経験からなんとなく、下手な書き方をすると、主にアップデートなどでDockerfileが本来意図していたビルドに失敗してしまうことは理解していた。
で、ここ最近この論文とこの論文を読んだことで事態の深刻さを知ります。前者の論文ではGithubにて★10を超えるリポジトリに絞り、かつ少なく見ても約26%のDockerfileがビルドに失敗。後者の論文では560の代表的なリポジトリのうち34%はビルドに失敗するという報告がありました。
……マーフィーの法則よろしく、ビルド失敗の印象が強く残るからビルドに失敗するDockerfileが多いように感じているんだろうな～と思っていたんですけど、マジで多かったんですね……
本題
そんなこんなで、アップロードされてるのにいざ実行しようとするとビルドに失敗するDockerfile、いわゆる「壊れた」Dockerfileのせいで何度も痛い目に遭ったので、壊れないDockerfileを書くのに意識するべき点を書きなぐっていこうと思い、現在に至ります。
自分なりにDockerfileの再現性を保つために気を付けるべきことを纏めたみました。
壊れる原因
主にこの4つに分けられます
①ファイル更新・追加・削除で、Dockerfileに修正が必要になったのに修正していない
②バージョン固定しないせいで、Dockerfileが意図しないバージョンを使用しようとしている
③Dockerfile更新した時にミスって、ビルド成立しない状態にしてしまった事に気付かない
④ビルド時に使ってたURLが壊れた
ファイルの更新によって破損するケースは、更新時にDockerfileをちゃんと保守してもらうしかないです。
ですが、最新バージョン・URL使用の2つを行った場合、時間経過によって、気づかない間にDockerfileは壊れます。この場合は、Dockerfileは時限爆弾を抱えているのと同じだと思った方がいいです。
Githubの約1/4を占めている破損したDockerfileの多くは、壊れた事に気付かないでDockerfileをアップロードした事が原因では無く、意図しない時限爆弾を仕込んだまま保守を忘れて廃墟と化した事が原因だと思われます。
対処方法
それぞれこんな感じです
①実行環境を変える時は必ずDockerfileも編集する。
②むやみやたらにに最新版を使わない。ベースイメージ決定やインストールの際に、自分のプロジェクトがどのバージョンを必要しているのか把握する。
③Dockerfileを編集したらテストビルドして下さい。
④安易にURLを使用しない。そのURLは誰かが保守してるから使える訳です。
バージョン固定とURL封印だけで時間経過による破損の大多数は未然に防げます。ただ、バージョン固定はともかくURLは使わないといけないシーンとかもあるので、URLの方に関してはこういったリスクがある事を承知の上で使って下さい。