質問: 例えば、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をインストールし、コマンドも同じイメージ内にインストールしました。 皆さんは、どのように対応するのか意見をお聞かせください。 1. rails用のイメージを `centos` で作成し、コマンド群は別の `centos` のイメージを作成し、 `volumes` でrails側からコマンドを実行する。 2. rails側とコマンド側のイメージのディストリビューションが異なっていてもできるやり方がある。(あれば教えてください。 理由も添えて、教えていただけると助かります。 上の1、2以外のやり方でやる方もご意見いただけると助かります。 よろしくお願いします。
回答: 依存関係のあるものは単一のイメージにまとめた方が良いと思います。 依存関係がイメージの外側にある場合に比べて、コンテナを移動した際に一貫したサービスを提供できるという考えです。