[解決済み] Dockerfilesとイメージコミットのどちらを使うべきですか？

質問

この2つのオプションについて、少し混乱しています。 これらは関連しているように見えます。 しかし、実際には互換性がありません。

例えば、Dockerfile を使用するということは、イメージにコミットすべきではないということです。なぜなら、実際には git で Dockerfile を追跡し、それに変更を加えるだけで良いからです。 そうすれば、何が権威あるものであるかについて曖昧さがなくなります。

しかし、イメージのコミットは本当に素晴らしいものだと思います。 コンテナを直接変更し、その変更にタグを付けて別のイメージを作成することができるのはとても素晴らしいことです。 イメージのコミット履歴からファイルシステムの差分のようなものさえ得られると理解しています。 すごいな。 でもそれならDockerfilesは使わない方がいい。 そうでなければ、イメージをコミットした場合、Dockerfileに戻り、あなたが行ったことを表す何らかの変更を行わなければならなくなります。

ですから、私は悩んでいます。 イメージの状態を Dockerfile で表現する必要がなく、直接追跡することができるのです。 しかし、イメージの中に何があるのかの簡単な概観を与えてくれるある種のマニフェスト ファイルという考えをあきらめるのは不安です。 また、同じソフトウェア パッケージの中に、互換性がないように見える 2 つの機能があることにも違和感を覚えます。

このことについて何か考えをお持ちの方はいらっしゃいますか？ イメージのコミットを使用するのは悪い習慣だと思われますか。 それとも、Puppet 時代からのマニフェスト ファイルへの愛着を捨て去るべきでしょうか? 私はどうしたらよいでしょうか？

アップデートについて :

これが意見に基づく質問だと思う皆さん、私はそうではありません。 主観的な部分もありますが、ほとんど客観的な質問だと思います。 さらに、このトピックに関する良い議論は、有益なものになると思います。

最終的には、この投稿を読んだ人が、Dockerfileと画像コミットがお互いにどのように関連しているかについて、より良い理解を持って帰ってくることを望みます。

アップデート - 2017/7/18 :

つい最近、イメージコミットの正当な使い方を発見しました。 私たちの会社では CI パイプラインをセットアップしたばかりで、パイプラインの 1 つのステージでは、アプリのテストがコンテナの内部で実行されます。 テストランナープロセスがカバレッジ結果を生成し（コンテナのファイルシステム内に）、コンテナの実行が停止した後、終了したコンテナからカバレッジ結果を取得する必要があります。 そのためには、停止したコンテナをコミットして新しいイメージを作成し、カバレッジファイルを表示したり stdout にダンプしたりするコマンドを実行することで、イメージコミットを使用します。 だから、これがあると便利なんです。 この非常に特殊なケースを除けば、私たちは Dockerfile を使って環境を定義しています。

どのように解決するのか？

Dockerfilesは、イメージを作成するために使用されるツールです。

を実行した結果 docker build . はコミットされたイメージなので コミットを作成しないDockerfileを使用することはできません。 . 問題は、何かが変更されるたびに手作業でイメージを更新する必要があり、その結果 ゴールデンイメージの呪いに自らを陥れるのか？ ?

ゴールデンイメージの呪いとは、ソフトウェアを実行するために、バグだらけのセキュリティホールだらけのベースイメージを使い続けなければならない人々にかけられた恐ろしい呪いです。なぜなら、それを作った人はとっくの昔に古代人に食われ（あるいは新しい仕事に移り）、誰もそのイメージに組み込まれた imagemagic のバージョンをどこで入手したかを知らないからです。また、たとえ imagemagic がどこから来たのかわかったとしても、サポート ツールの JNI コールに使用されている libstdc++ のバージョンが、長髪のインターンが作成したサポートされていないバージョンの ubuntu にしか存在しないため、とにかく重要ではありません。