docker環境を構築する際の意見をお聞かせください。

Question

例えば、rails用、nginx用、db用のイメージがあって docker-compose で管理しているとします。
railsのコンテナから何かしらのコマンド(ffmpeg、snmptt、ssh)を実行したい場合にはrailsのイメージにコマンドをインストールしますか？

私は、railsのイメージは別のアプリを作成する場合なども考えて再利用した際に、不必要なコマンド(ffmpeg、snmptt、ssh)があるのがdockerの考え方的にもそぐわないと思い、コマンドはコマンドだけがインストールされたイメージを作成した方が良いと考えて、ベースイメージがdocker公式の centos で各種コマンドをインストールしたイメージを作成しました。

その場合、rails側でコマンドを実行できるように volumes で各コマンドがあるPATHを管理するようにしました。
ところが、rails側のベースイメージにdocker公式の rubyを使用しているので、OSがdebian系のため、
コマンドをインストールしている側のイメージとrails側のイメージのディストリビューションが異なるので、PATHの構成などが違い、上手くコマンドが実行できません。

なぜこうゆうディストリビューションが違う構成になったのかは、既存の仮想環境で動いているシステムをdockerに移行する際に、既存のシステムが centos で動いているので、コマンド用のイメージに centos を採用しました。
そして、railsのイメージを作成する際には、rubyの公式のイメージがdebian系だったためです。

対応としては、rails側のイメージのベースイメージを公式の ruby を使わずに、 centos に変更し、rubyをインストールし、コマンドも同じイメージ内にインストールしました。

皆さんは、どのように対応するのか意見をお聞かせください。
0. rails用のイメージを centos で作成し、コマンド群は別の centos のイメージを作成し、 volumes でrails側からコマンドを実行する。
0. rails側とコマンド側のイメージのディストリビューションが異なっていてもできるやり方がある。(あれば教えてください。

理由も添えて、教えていただけると助かります。
上の１、２以外のやり方でやる方もご意見いただけると助かります。

よろしくお願いします。

Answer 1

rails 側からコマンドを叩き、それがアプリケーションとして必要なのであれば、素直に単一のイメージに入れた方がシンプルでよいと思います。イメージは軽量であればあるほどいいですが、それはイメージを改変してはならない、ということにはなりません。ベストプラクティスとしても、不要なパッケージのインストールを避けると書いてありますが、それは必要であれば入れてください、ということを意味するでしょう。
http://docs.docker.jp/engine/articles/dockerfile_best-practice.html#id3
再作成する場合は改変前のベースイメージから作成すればよいかと。

以下は参考までに。
トラブルシューティング目的なら名前空間を部分的に接続して対応してください。例えばホストからNW 名前空間だけ接続することで、コンテナのIP アドレスやルーティングテーブル"だけ"利用することができます。ちなみにこれを実行するにはnsenter コマンドが最も楽です。
同様の考えで、busybox のようなコマンドの集合体であるコンテナを他のコンテナの名前空間に接続することで、接続されるコンテナを汚さずにコマンドを実行できます。

Answer 2

依存関係のあるものは単一のイメージにまとめた方が良いと思います。
依存関係がイメージの外側にある場合に比べて、コンテナを移動した際に一貫したサービスを提供できるという考えです。