ドッカーイメージをローカルファイルシステムに変更しました

Question

ドッカーイメージの作成に使用されたローカルファイルシステムを変更するときに、既存のイメージをどのように更新できるかを試しています。私はそれを行うためにドッカーのコミットを使うことができると思っていましたが、実行中のイメージ上でファイルシステムが変更されたときにイメージを変更することができますか？

/app.py 

ファイルシステムからのビルド

sudo docker build -t app 

今/app.pyするローカル変更があります。/app.pyの変更を反映するためにイメージアプリを変更するにはどうすればよいですか？今は古いイメージを削除して新しいイメージを作成する必要があります。

sudo docker rmi app 
sudo docker build -t app 

ご了承ください。

Answer 1

まず、running image、running containerのみがあります。画像はDockerの方法で配信可能なもので、imageを構築してからcontainerを開始します。あなたの問題へ

は、私はあなたのオプションを言及していると思う：

1. docker commitそれをバック、実行中のコンテナ内の
2. ゴーあなたのイメージを再構築変更を行います。個人的には、docker buildが本当に時間がかかる場合、私はちょっとした問題を修正したり、イメージに修正を加えたりするためにこの方法を使用します。

ドッカーは、あなたがイメージに変更を加える場合は、あなたがその場でそれを変更することはできませんを意味し、画像を構築するためにcopy on writeでunion FSを使用しています、それはあなたの変更を反映するために余分な層（複数可）を作成しますが場合によっては同じ画像名を使用するだけです。そして配信の観点からは、リリースごとに新しい画像（別のタグを使用）を作成することはまったく問題ないと思います。つまり、この方法で行う必要があります。そのため、あなたはDockerfileを持っています。あなたのコンテナは、実際にバージョン管理された配信成果物であり、必要に応じて任意のバージョンにロールバックすることができます。だからあなたの現在の解決策はOKだと思います。ここ

さらにいくつかの単語：あなたは、docker run -v /path/to/host/app.py:/path/to/container/app.py your_base_image_to_run_appのように、あなたがapp.pyに、ローカルFSに変更し、その後は何も何かを、それを起動するときに、ローカルの開発とテストのために、あなたは自分のコンテナにボリュームとしてご/app.pyをマウントすることができ、それは容器に反射する。仕事が終わったら、新しいイメージを作ります。

Answer 2

あなたの現在のデザインごとに解決策は、新しいイメージを作成し、同じタグを割り当てることです。

ベストソリューションは、ドッカーイメージから環境変数を公開し、その変数を使用してapp.pyを更新し、毎回イメージを変更する必要がないようにすることです.1つのイメージで十分です。