dockerイメージに起因するトラブル例

docker / kubernetes特有のトラブルのひとつに、配布されているdockerイメージが原因のトラブルがあります。

自分で作成したDockerfileが適切に設定されていても、取得してきたイメージとの組み合わせで動作しないことがあります。

設定を見直してもそこに原因はないため、対処しづらいケースです。

ベースイメージが原因のトラブルには以下のようなものが考えられます。

dockerのバージョンアップにより、一番目のセキュリティ懸念についてはイメージ検証でいちおうの対処はされつつあります。

一方で、イメージのバージョンに起因する問題についてはツール上の対処法もないと考えられ、今後とも”つきもの”の問題となります。

古いイメージが選択されるトラブルの実例

dockerコマンドがインストールされているマシーンであれば、Dockerfileをもとにどこでもイメージを生成できます。

いろいろなホストでイメージを作成しているため、久しぶりに利用したホスト上の古いイメージキャッシュが用いられるというトラブルに遭遇しました。

nginxで最新の機能（http2）をオンにする設定になっているのに、イメージが古いためその機能がない、というケースでした。

kubernetesでpodコンテナの再起動をかけてもリトライがかかって最終的にエラー停止する、という挙動になります。

コンテナがリトライすると外部からログを取得できないため原因把握が難しくなります。今回はkubectl logsを繰り返し実行してコンテナが停止する直前にエラーを取り出せました。

この場合の解決策は、docker pull nginx:latestのように手元のイメージを更新することです。

また、より確実な運用を行うためには、イメージのバージョンを固定することが有効でしょう。

latestタグは複数のバージョンを指しうるため、開発スピードの速いイメージではこのような事象に遭遇しやすくなります。

latestも絶対値のバージョン別名を持っているので、ある程度実環境用の設定ができあがったところで、明示的にバージョン指定した方が安全といえます。