実行中のコンテナからDockerイメージを作成する方法

Dockerコンテナーは通常、内部状態を欠く一時的なアプリケーションインスタンスです。これは、いつでもコンテナを停止または再起動できる、それらを処理するためのベストプラクティスの方法です。

ただし、コンテナのファイルシステムへの変更が避けられない場合もあります。おそらく、ソフトウェアを試していて、スナップショットを後で戻したいと考えています。もう1つの使用例は、コンテナ内のソフトウェアが機能しなくなり、将来デバッグできるレプリカを保存したい場合です。

既存のコンテナから新しいDockerイメージを作成する方法は次のとおりです。その後、別のを開始できるようになります最初のファイルシステムのファイルシステムが読み込まれる、そのイメージのコンテナ。

コンテナのコミット

docker commit コマンドは、コンテナを取得し、そこから新しいイメージを生成するために使用されます。停止中または実行中のコンテナのいずれかで動作します。

基本的な構文は次のとおりです。

docker commit example-container example-image:latest

これにより、example-containerという名前のコンテナからイメージが作成されます。必要に応じて、IDでコンテナを識別することもできます。両方の情報は、docker psの出力から入手できます。ホスト上のすべてのコンテナが一覧表示されます。

結果の画像には、コマンドの2番目のパラメータとして指定されたタグが割り当てられます。これはexample-image:latestです上記の例では。通常の画像のタグ付け操作と同様に、タグの参照がすでに存在する場合は、新しい画像がタグの参照に置き換わります。

これで、イメージを使用して、example-containerからファイルシステムを復元できます。新しいコンテナインスタンスに：

docker run -d example-image:latest

ファイルシステムのコンテンツは、example-containerと一致します docker commit時のコンテナコマンドが実行されました重要な注意点が1つあります。マウントされたボリュームのコンテンツは含まれないため、作成されたコンテナイメージではマウント位置が空になります。ボリュームデータをそのままにして新しいコンテナを実行するには、-vを使用します docker runで2番目のインスタンスを開始するときに、最初のコンテナーからボリュームを再接続するためのフラグ。

もう1つの注目すべき点は、Dockerが実行中のコンテナーのコミットを処理する方法です。ほとんどの場合、これはシームレスに機能するはずですが、デフォルトでは、コミットが作成される前にターゲットコンテナを一時停止します。コンテナ内のすべてのプロセスは一時停止され、イメージの作成が完了した後に再開されます。これにより、新しいイメージのデータの一貫性が向上しますが、コンテナに一時的にアクセスできなくなります。 --pause falseを含めることで、この動作を無効にできます docker commitを使用しますコマンド。

コミットメッセージの追加

docker commit コマンドは、Gitなどのバージョン管理ソフトウェアと同様の方法でコミットメッセージをサポートします。コンテナから画像を作成するときにメッセージを追加すると、変更内容とコミットの背後にある理由を文書化できます。

--messageを使用しますまたは-m コミットメッセージを適用するためのフラグ：

docker commit -m "Example commit" example-container example-image:latest

専用フラグを使用して著者情報を追加することもできます。一般的なFirst Name <[email protected]>に文字列を入力します --authorにフォーマットしますまたは-a 国旗。コミットメッセージと一緒に保存されます。

docker commit -a "Example Author <[email protected]>" -m "Example commit" example-container example-image:latest

docker historyを使用すると、コミットメッセージが表示されます画像内のレイヤーを表示するコマンド。 COMMENTに表示されます右端の列。

この情報にアクセスする別の方法は、docker inspectを使用することです。 grepと連携して画像のJSON表現から作成者とコメントの値を抽出するには：

docker inspect <image-id> | grep 'Created|Author|Comment'

これにより、画像の最上位レイヤーに関連付けられたデータが表示されます。

Dockerfile命令の変更

イメージをコミットすると、Dockerfile命令の一部を変更する機会が与えられます。新しい画像では、次の値を上書きできます。

CMD
ENTRYPOINT
ENV
EXPOSE
LABEL
ONBUILD
USER
VOLUME
WORKDIR

命令を設定するには、--changeを使用しますまたは-c フラグ：

docker commit --change 'ENTRYPOINT ["sh"]' example-container example-image:latest

フラグを必要な回数繰り返すことで、意図したすべての変更を適用できます。

最上位のファイルシステム層に影響を与える命令のみがサポートされます。 RUNなどの手順を使用して、コミットされたイメージを新しいレイヤーでシームレスに拡張することはできません。およびCOPY 。ただし、コミットの結果を取得して、必要に応じて新しいコンテンツを追加する新しいDockerfileを作成することもできます。

# Created via `docker commit`
FROM example-image:latest
RUN apt install example-package

を介して作成

コミット時にDockerfile命令を変更する場合は、変更内容とその理由を説明するコミットメッセージを追加する価値があります。これにより、イメージにアクセスできる他のユーザーは、イメージが作成されたコンテナーと比較した動作の違いを理解するのに役立ちます。

概要

Dockerイメージは通常、Dockerfileから構築され、使い捨てコンテナーを開始するために使用されます。コンテナのファイルシステムの状態を変更するには、イメージを再構築し、既存のコンテナを破棄して、新しいコンテナを起動します。理想的な世界では、コンテナには内部状態がありませんが、実際には必ずしもそうとは限りません。

コンテナをコミットすると、将来、現在のファイルシステムを復元する方法が提供されます。コミットは、面倒なコンテナのレプリカを作成するのに役立ちます。これにより、以前に生成されたログと一時ファイルへのアクセスを維持しながら、別の環境でデバッグできます。

コンテナのコミットはVMスナップショットに似ていると感じることがよくありますが、まったく同じではありません。 VMは仮想ハードウェアを制御し、そのハードウェアの状態はスナップショット内に存在します。 Dockerコンテナーは、ホスト上で実行される一連のプロセスにすぎません。コミットは、コンテナのファイルシステムを表す新しいDockerイメージです。ただし、プロセス、カーネル、およびハードウェアの状態に関するデータは必然的に不足しています。