Dockerfileの代わりに構成管理ツールを使用しないのはなぜですか？

私はDockerと構成管理ツールにかなり慣れています。

最初はbashスクリプトの作成を開始して、開発マシン用のVagrantボックスをプロビジョニングしましたが、今はそのためにChefを使用するように切り替えました。同じソースを使用して、開発環境と本番環境の両方をプロビジョニングし、同じようにそれらを試して取得できるようになりましたできるだけ。

Chefを使い始めてから、シェルスクリプトの行をプロジェクト間でコピーして貼り付ける必要がないというDRYの側面、1つの統合されたソースを使用してさまざまなLinuxディストリビューションを実行するマシンをプロビジョニングする機能、および便利さを楽しんだコミュニティ提供のクックブックを使用する方法。

Chefを使用してvmをプロビジョニングしているので、RUNコマンドに続いてシェルコマンドをDockerfileに追加してChefレシピを実行するだけで達成できることを達成するとき、後退するような気がします。

私はググって何も見つかりませんでした（しかし、たぶんそれを逃しただけかもしれません）が、Dockerコンテナーを構築するChefレシピを使用する簡単な方法があるようには見えません。何故ですか？

コンテナは不変であることを意図しており、構成管理ツールは通常、マシンの寿命全体でマシンを再構成するために使用されますが、コンテナの最初の構築中に使用した場合でも、多くの利点を提供しませんか？

必要なツールは、Dockerを「ビルダー」、Chefを「プロビジョニング担当者」として使用するPackerです。次に、結果のイメージをリポジトリに追加し、レシピが変更されるまで、再度パックする必要なく再利用できます。

これらの戦略は互いに何の関係もありません。

コンテナー（Dockerなど）は、アプリケーションをデプロイおよび分離するための方法論です。コンテナは持ち運びが可能であるため、好まれています。ほとんどの場合、ローカルで開発してプレビューできるため、アプリケーションを配置することは理にかなっています。

Dockerがシェルスクリプトを使用する理由については、Dockerイメージは文字通りLinuxコンテナイメージです。これはLinuxオペレーティングシステムであり、そのコンテナが可能な限り軽量で効率的であることがポイントです。Chef、Ruby、Erlang、およびDockerfileのプロビジョナーとしてChefを使用するために必要なその他のすべてのライブラリーを追加し始めた場合、コンテナーを使用する意味がなくなります。

構成管理は、計算ノードをプロビジョニングするためのものです。構成の最終状態は通常コードに反映され、状態を維持するための中央サーバーがあります。vagrantなどのツールを使用すると、Chefを使用してVagrantマシンを構成できます。これらのツールのほとんどはローカル専用モードで使用できますが、それらのメンテナンスは非常に負担になります。これらの中央サーバーは、バージョン管理と依存関係管理を自動的に分類するようなものです。

バッシュは本質的に一歩後退したものではありません。たとえば、完全に不変の画像パイプラインを構築している多くの組織は、Bashを使用して画像を構築しています。これにより、安定性と予測可能性、およびエンジニア間の共通言語が保証されます（多くのエンジニアは、さまざまな構成管理のバックグラウンドを持っている可能性があります）。

コンフィグ管理対不変。不変のインフラストラクチャは変更されないため、更新するには完全に置き換える必要があります。構成管理は、マシンの状態がエージェントまたは外部接続（Ansibleなど）によって維持されることを意味します。

Dockerコンテナは本質的に不変です。あなたはそれらにデータを永続化せず、更新するためにそれらをロールバックする必要があります。