元のイメージはそのまま!docker commitで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 は省略可能で、指定しない場合は latest が適用されます。
補足: docker commit は docker container commit のレガシーなエイリアスであり、両者は完全に同じ動作をします。
docker commit の主なオプション
docker commit コマンドには、メタデータの追加、設定変更の適用、コミット処理の制御などを行うための複数のオプションが用意されています。サポートされている主なオプションは以下の通りです。
| オプション | 長い形式 | 説明 | 使用例 |
|---|---|---|---|
| -a | --author | 新しいイメージのメタデータに作者名を追加します。 | docker commit -a "Anees" my-container my-image |
| -c | --change | ENV、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 <CONTAINER_ID> 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
curlのバージョン情報が表示されれば、変更が新しいイメージに正しく永続化されていることが証明されます。
docker commit と Dockerfile の使い分け
Dockerfileと docker commit はどちらもDockerイメージを作成する手段ですが、仕組みも得意分野も大きく異なります。
Dockerfile は、信頼性が高く再現可能なビルドが必要な場合、特にCI/CDパイプラインや本番環境において最適な選択肢です。すべての変更がコードとして明確に定義されるため、追跡・レビュー・バージョン管理が容易になります。このアプローチにより、誰がビルドしても必ず同じ結果が得られることが保証され、長期的な保守やチーム開発にとって不可欠な要素となります。
一方、docker commit は、Dockerfile全体を書き直したり再ビルドしたりせずに試したい、ちょっとした修正やテスト、細かな調整に向いています。実験中の検証、デバッグ、その場での変更確認などに便利です。ただし、変更内容がファイルとして記録されないため、あくまで短期利用向けの手法であり、本番運用には不向きです。
まとめると、docker commit は主に実験や一時的な修正のために使うのがよいでしょう。本番環境向けのイメージを作る場合は、必ずDockerfileを選択してください。また、Dockerを最大限に活用するために、コンテナ・イメージ・ワークフロー操作を効率化するその他の重要なコマンドについても学んでおくことをおすすめします。
-
なぜLinuxにはこんなに多くのディストリビューションがあるのか?その理由を徹底解説
WindowsやmacOSと違い、Linuxの導入はそう簡単ではありません。インターネットで「Linux」と検索すると、さまざまな名前を持つ無数のOSがヒットしますが、そのどれもが「Linux」という名前を冠してはいません。一体なぜなのでしょうか?Linuxは、テクニカル好きな上級者から一般ユーザーまで、選ばれるOSとして存在感を増しています。では、なぜ「Linux」と総称されるOS(ディストリビューション)が数千も存在するのでしょうか? そして、なぜ開発者たちは今も同じ種類のOSを作り続けるのでしょうか? 本記事でその謎を解き明かします。Linuxディストリビューションとは?まず重要なのは、
-
cURLの使い方完全ガイド|コマンドラインでデータ転送・ダウンロードを自在に操る
Linuxアプリのターミナル向けインストール手順を調べていると、必ずと言っていいほど目にするのがcurlコマンドです。cURLはURLを使ってデータを転送するためのコマンドラインツールで、最もシンプルな使い方は「コマンドラインからのファイルダウンロード」。しかし実際にはそれだけにとどまらず、驚くほど多機能なパワフルなツールです。 cURLとは? cURLは1996年、Daniel Stenberg(ダニエル・ステンベリ)がWebサーバーから金融データを取得してIRCチャンネルへ配信するために開発したのが始まりです。その後進化を重ね、ブラウザを使わずにデータを取得できる強力なツールとなりました