オリジナルを変更せずに Docker イメージへの変更を即座に永続化

Docker イメージは不変です。一度構築されると、それらは変わりません。これにより、一貫性、予測可能性、安定性が確保されます。同じイメージから作成されたすべてのコンテナーは同じように動作し、バージョン管理が安全かつ簡単になります。しかし、パッケージのインストールや構成の更新など、実行中のコンテナー内で何かを調整する必要がある場合はどうすればよいでしょうか?ここで docker commit が登場します。これを使用すると、実行中のコンテナーの変更をキャプチャし、元のイメージに手を加えることなく新しいイメージを作成できます。これは、修正をテストし、迅速に反復し、最初から再構築せずにカスタム イメージをロールアウトする場合に最適です。

目次

Docker イメージが変更されない理由

Docker イメージは複数の読み取り専用レイヤーで構成されます。コンテナーを実行すると、Docker はコンテナー層と呼ばれる書き込み可能な薄い層を上に追加します。加えた変更はすべて、この最上位レイヤーでのみ行われます。コンテナが削除されると、そのレイヤー内のすべての変更が消え、元の画像は変更されないままになります。

この設計により、次のようないくつかの利点が保証されます。

• 同じイメージのすべてのコンテナは同じように動作するため、一貫性が確保されます。
• あるコンテナの変更が他のコンテナに影響を与えないため、予測可能性が得られます。
• 特定のイメージ バージョンをリスクなく安全にタグ付けできます。

この設計は優れた安定性を提供しますが、実行中のコンテナーに迅速な変更を加えたい場合には制限があります。それが docker commit です。 助けます。

実行中のコンテナから新しいイメージを作成します

docker commit を実行すると コマンドを実行すると、Docker は実行中のコンテナーの現在の状態をキャプチャし、そこから新しいイメージを作成します。コンテナーのファイル システムのスナップショットを取得し、インストールされたパッケージ、更新された構成、変更されたファイルなどの変更を新しいイメージ レイヤーとして保存します。こうすることで、元の画像は変更されずに残るため、すばやく実験して反復することができます。

これにより、将来の再利用のためにカスタムの基本セットアップを保存したり、テスト中に小さな修正や構成変更を適用したり、Dockerfile を最初から再構築することなく更新されたイメージをチームと共有したりするのに最適です。

docker commit を使用できます。 次の構文を使用してコマンドを実行し、実行中のコンテナから新しいイメージを作成します。

docker commit [OPTIONS] CONTAINER_ID NEW_IMAGE_NAME[:TAG]

ここでは、CONTAINER_ID キャプチャするコンテナの ID または名前、NEW_IMAGE_NAME は新しい画像の名前です。TAG はオプションで、デフォルトは最新です。

注: docker commit は docker container commit のレガシー エイリアスです;両方とも同一です。

docker commit コマンドには、メタデータの追加、構成変更の適用、コミット プロセスの動作の制御を可能にするいくつかのオプションが用意されています。以下の表は、サポートされているすべてのオプションをまとめたものです。

オプション 長い形式 説明 例 -a–author新しい画像メタデータに作成者名を追加します。docker commit -a "Anees" my-container my-image -c–changeENV、LABEL、CMD などの Dockerfile 命令を新しいイメージに適用します。docker commit -c "ENV APP_ENV=prod" my-container my-image -m–message 画像に加えられた変更を説明する短いメッセージを追加します。docker commit -m "Installed curl" my-container my-image -p–pause一貫性を確保するためにコミット中にコンテナを一時停止します (デフォルト:true)。docker commit --pause=false my-container my-image

docker commit の仕組みを参照

Dockerfile を再構築せずに、Alpine コンテナーにcurl をインストールするとします。これを行うには、ベース イメージからコンテナを実行します。

docker run -it alpine:latest /bin/sh

コンテナに入ったら、必要な変更を加えます。

apk update && apk add curl

ここでコンテナを終了します。

exit

この後、コンテナを新しいイメージとしてコミットします。

docker commit alpine-with-curl:1.0

新しいイメージを確認します:

docker images

これで、curl がプリインストールされた新しいイメージがどこでも実行できるようになりました。

新しいイメージを実行して、保存された変更をテストする

新しいイメージを作成した後、そのイメージからコンテナを実行して、変更が保存されたことを確認できます。

docker run -it alpine-with-curl:1.0 /bin/sh

このコマンドは、alpine-with-curl:1.0 に基づいてコンテナ内で対話型シェルを開きます。 画像。中に入ると、変更が損なわれていないことを確認できます。

curl --version

これは、変更が新しいイメージに保持されていることを示しています。

docker commit と Dockerfile:いつどちらを使用するか

Dockerfile と docker commit の両方を使用して Docker イメージを作成できますが、動作方法は大きく異なり、さまざまな状況に適しています。

Dockerfile は、信頼性が高く再現性のあるビルドが必要な場合、特に CI/CD パイプラインや運用環境の場合に最適です。すべての変更がコード内で明確に定義された状態に保たれるため、長期にわたる変更の追跡、レビュー、バージョン管理が容易になります。このアプローチにより、後でイメージを構築する人が同じ結果を得ることができます。これは、長期的なメンテナンスやチームのコラボレーションにとって重要です。

一方、docker commit Dockerfile 全体を書き換えたり再構築したりせずに試したい、簡単な修正、テスト、または小さな調整に適しています。これは、変更をその場で実験、デバッグ、または検証するときに便利です。ただし、変更はファイルに文書化されないため、この方法は運用環境よりも短期間の使用に適しています。

簡単に言うと、docker commit を使用できます。 主に実験や一時的な修正用です。本番環境に対応したイメージの場合は、常に Dockerfile を優先します。 Docker を最大限に活用するには、コンテナ、イメージ、ワークフローの操作を容易にする他の主要なコマンドを検討する価値があります。