Dockerイメージとコンテナの違いは何ですか？
回答:
画像のインスタンスはコンテナと呼ばれます。説明したとおりのレイヤーのセットである画像があります。このイメージを開始すると、このイメージの実行中のコンテナがあります。同じイメージの実行中のコンテナを多数持つことができます。
ですべてのイメージをdocker images表示できますが、実行中のコンテナdocker psはで表示できます（すべてのコンテナはで表示できますdocker ps -a）。
したがって、実行中のイメージのインスタンスはコンテナです。
Dockerデプロイメントの自動化に関する私の記事から：
Dockerイメージとコンテナ
Dockerlandには、イメージとコンテナがあります。2つは密接に関連していますが、区別されます。私にとって、この二分法を理解することで、Dockerは非常に明確になりました。
画像とは？
イメージは、本質的にコンテナのスナップショットである、不活性で不変のファイルです。イメージはbuildコマンドで作成され、runで開始するとコンテナーを生成します。画像は、registry.hub.docker.comなどのDockerレジストリに保存されます。画像は非常に大きくなる可能性があるため、画像は他の画像のレイヤーで構成されるように設計されており、ネットワーク経由で画像を転送するときに最小限のデータを送信できます。
次のコマンドを実行すると、ローカルイメージを一覧表示できますdocker images。
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu 13.10 5e019ab7bf6d 2 months ago 180 MB
ubuntu 14.04 99ec81b80c55 2 months ago 266 MB
ubuntu latest 99ec81b80c55 2 months ago 266 MB
ubuntu trusty 99ec81b80c55 2 months ago 266 MB
<none> <none> 4ab0d9120985 3 months ago 486.5 MB
注意すべき点：
- IMAGE IDは、画像の真の識別子の最初の12文字です。特定の画像の多くのタグを作成できますが、それらのIDはすべて同じです（上記のとおり）。
- VIRTUAL SIZEは、基礎となるすべてのレイヤーのサイズを合計するため、仮想サイズです。これは、その列のすべての値の合計が、それらのすべてのイメージで使用されるディスク領域よりもはるかに大きいことを意味しています。
- REPOSITORY列の値
-tは、docker buildコマンドのフラグから、またはdocker tag既存のイメージから取得されます。あなたには、レジストリの場所としてタグを使用するあなたに理にかなって命名法を使用してタグ画像への自由だが、それドッキングウィンドウを知っていますdocker pushかdocker pull。 - タグの完全な形式は
[REGISTRYHOST/][USERNAME/]NAME[:TAG]です。ubuntu上記、REGISTRYHOSTがあることを推測されますregistry.hub.docker.com。したがってmy-application、でレジストリに呼び出されたイメージを保存する場合はdocker.example.com、そのイメージにタグを付ける必要がありますdocker.example.com/my-application。 - TAG列は、完全なタグの[：TAG]部分です。これは残念な用語です。
latestタグは、それは単にあなたがタグを指定しないデフォルトのタグだ、魔法ではありません。- タグなしの画像は、画像IDでのみ識別できます。これらは
<none>タグとリポジトリを取得します。それらのことは忘れがちです。
画像の詳細については、Dockerのドキュメントと用語集を参照してください。
コンテナとは？
プログラミングメタファを使用するには、画像がクラスの場合、コンテナはクラスのインスタンス、つまりランタイムオブジェクトです。コンテナーがDockerを使用している理由です。それらは、アプリケーションを実行する環境の軽量でポータブルなカプセル化です。
で実行中のローカルコンテナを表示docker ps：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f2ff1af05450 samalba/docker-registry:latest /bin/sh -c 'exec doc 4 months ago Up 12 weeks 0.0.0.0:5000->5000/tcp docker-registry
ここでは、Dockerレジストリのdockerizedバージョンを実行しているので、画像を保存するためのプライベートな場所があります。繰り返しますが、注意すべき点がいくつかあります。
- IMAGE IDと同様に、CONTAINER IDはコンテナの真の識別子です。フォームは同じですが、異なる種類のオブジェクトを識別します。
docker ps実行中のコンテナのみを出力します。すべてのコンテナ（実行中または停止中）をで表示できますdocker ps -a。- NAMESは、
--nameフラグを介して開始されたコンテナーを識別するために使用できます。
イメージとコンテナーのビルドアップを回避する方法
Dockerに対する私の初期の不満の1つは、タグの付いていないイメージと停止したコンテナーが一見一定して蓄積されているようでした。ほんの一握りの場合、このビルドアップにより、ハードドライブが使い果たされ、ラップトップの速度が低下したり、自動ビルドパイプラインが停止したりしました。「どこでもコンテナ」について話してください！
docker rmi最近のdangling=trueクエリと組み合わせることで、タグなしの画像をすべて削除できます。
docker images -q --filter "dangling=true" | xargs docker rmi
Dockerは既存のコンテナーの背後にあるイメージを削除できないため、docker rm最初に停止したコンテナーを削除する必要がある場合があります。
docker rm `docker ps --no-trunc -aq`
これらはDockerの既知の問題点であり、将来のリリースで対処される可能性があります。ただし、イメージとコンテナを明確に理解していれば、次の2つの方法でこれらの状況を回避できます。
- 常に、不要な停止したコンテナをで削除し
docker rm [CONTAINER_ID]ます。 - を使用して、役に立たない停止したコンテナの背後にあるイメージを常に削除してください
docker rmi [IMAGE_ID]。
docker image pruneして、ぶら下がっている画像をクリーンアップできます。未使用のDockerオブジェクトを削除する
docker system prune
簡単な言葉で。
画像 -
コンテナーの作成に使用されるファイルシステムと構成（読み取り専用）アプリケーション。詳細。
コンテナ -
これらは、Dockerイメージの実行中のインスタンスです。コンテナは実際のアプリケーションを実行します。コンテナーには、アプリケーションとそのすべての依存関係が含まれます。カーネルを他のコンテナーと共有し、ホストOSのユーザー空間で分離プロセスとして実行されます。詳細。
注意すべきその他の重要な用語：
Dockerデーモン -
Dockerコンテナーの構築、実行、配布を管理するホストで実行されるバックグラウンドサービス。
Dockerクライアント -
ユーザーがDockerデーモンを操作できるようにするコマンドラインツール。
ドッカー店 -
ストアは、とりわけ、Dockerイメージのレジストリです。レジストリは、利用可能なすべてのDockerイメージのディレクトリと考えることができます。
このブログ投稿の写真は、1000語に値します。
（より深い理解のためにこれを読んでください。）
概要：
- Dockerハブからイメージをプルするか、Dockerfileからビルドする=> Dockerイメージを提供します（編集不可）。
- 画像を実行（
docker run image_name:tag_name）=>実行中の画像、つまりコンテナ（編集可能）を提供します
それが実行されている画像などの容器を考えるために最も簡単なのですが、これではありません、非常に正確。
画像は、実際にはコンテナに変換できるテンプレートです。イメージをコンテナに変換するために、Dockerエンジンはイメージを取得し、読み書き可能なファイルシステムを上に追加し、ネットワークポート、コンテナ名、ID、リソース制限などのさまざまな設定を初期化します。実行中のコンテナーには現在実行中のプロセスがありますが、コンテナーを停止する（またはDockerの用語で終了する）こともできます。終了コンテナはない、それを再起動することができ、その設定および任意のファイルシステムの変更を保持するように、画像と同じ。
docker createます。
おそらくワークフロー全体を説明することが役立つでしょう。
すべてはDockerfileから始まります。Dockerfileはイメージのソースコードです。
Dockerfileを作成したら、それをビルドしてコンテナのイメージを作成します。イメージは、Dockerfileである「ソースコード」の「コンパイル済みバージョン」にすぎません。
コンテナのイメージを取得したら、レジストリを使用して再配布する必要があります。レジストリはGitリポジトリのようなものです。イメージをプッシュしたりプルしたりできます。
次に、イメージを使用してコンテナを実行できます。実行中のコンテナーは、多くの点で仮想マシンに非常に似ています（ただし、ハイパーバイザーはありません）。
ワークフロー
これは、さまざまなコマンドとそれに関連する入力と出力を示すエンドツーエンドのワークフローです。これにより、画像とコンテナの関係が明確になります。
+------------+ docker build +--------------+ docker run -dt +-----------+ docker exec -it +------+
| Dockerfile | --------------> | Image | ---------------> | Container | -----------------> | Bash |
+------------+ +--------------+ +-----------+ +------+
^
| docker pull
|
+--------------+
| Registry |
+--------------+
実行できるイメージを一覧表示するには、次のコマンドを実行します。
docker image ls
コンテナを一覧表示するには、次のコマンドを実行します。
docker ps
ここですべての質問を読んだにもかかわらず、イメージとレイヤーの概念を理解できず、ついにDockerからのこの優れたドキュメントに出くわしました（そうです！）。
そこにある例は、概念全体を理解するための鍵です。長い記事ですので、わかりやすくするためにしっかりと把握しておく必要のある要点をまとめています。
画像：Dockerイメージは、一連の読み取り専用レイヤーから構築されます
レイヤー：各レイヤーは、イメージのDockerfile内の命令を表します。
Example：以下のDockerfileには4つのコマンドが含まれており、それぞれがレイヤーを作成します。
からubuntu：15.04
コピー / app
make / appを実行します。
CMD python /app/app.py
重要なことに、各レイヤーはその前のレイヤーとの違いのセットにすぎません。
- コンテナ。新しいコンテナを作成するときは、下にあるレイヤーの上に新しい書き込み可能なレイヤーを追加します。この層は、しばしば「コンテナ層」と呼ばれます。新しいファイルの書き込み、既存のファイルの変更、ファイルの削除など、実行中のコンテナーに加えられたすべての変更は、この薄い書き込み可能なコンテナーレイヤーに書き込まれます。
したがって、コンテナと画像の主な違いは、書き込み可能な最上位のレイヤーです。新しいデータを追加したり既存のデータを変更したりするコンテナーへのすべての書き込みは、この書き込み可能なレイヤーに格納されます。コンテナが削除されると、書き込み可能なレイヤーも削除されます。基になるイメージは変更されません。
ディスク上のサイズの観点からのイメージとコンテナーの理解
実行中のコンテナーのおおよそのサイズを表示するには、docker ps -sコマンドを使用できます。2つの出力としてsize、次virtual sizeを取得します。
サイズ：各コンテナーの書き込み可能なレイヤーに使用される（ディスク上の）データの量
仮想サイズ：コンテナが使用する読み取り専用の画像データに使用されるデータの量。複数のコンテナが一部またはすべての読み取り専用画像データを共有する場合があります。したがって、これらは加算的ではありません。つまり、イメージで使用されているディスク上のサイズを計算するためにすべての仮想サイズを追加することはできません
別の重要な概念は、コピーオンライト戦略です
画像内の下位層にファイルまたはディレクトリが存在し、別の層（書き込み可能層を含む）が読み取りアクセスを必要とする場合、既存のファイルを使用します。別のレイヤーが初めてファイルを変更する必要があるとき（イメージのビルド時またはコンテナーの実行時）、ファイルはそのレイヤーにコピーされて変更されます。
それが私のような誰かを助けることを願っています。
Dockerfile →（ビルド）→ 画像 →（実行）→ コンテナ。
Dockerfile：好みの方法でオペレーティングシステムをプロビジョニングし、すべてのソフトウェアをインストール/構成するDocker命令のセットが含まれています。
画像：コンパイルされたDockerfile。コンテナーを実行する必要があるたびにDockerfileを再構築する時間を節約できます。そして、それはあなたのプロビジョニングコードを隠す方法です。
コンテナ：仮想オペレーティングシステム自体。それをsshで実行して、まるで実際の環境であるかのように、必要なコマンドを実行できます。同じイメージから1000以上のコンテナを実行できます。
コンテナーは、適用する制限をOSに通知する方法を知っているアプリケーション（Dockerなど）を使用して事前設定された一連の制限の下でホストOSによって実行される実行可能バイナリにすぎません。
典型的な制限は、プロセス分離関連、セキュリティ関連（SELinux保護の使用など）、およびシステムリソース関連（メモリ、ディスク、CPU、ネットワーク）です。
最近まで、UNIXベースのシステムのカーネルのみが、厳しい制限の下で実行可能ファイルを実行する機能をサポートしていました。そのため、今日のほとんどのコンテナトークには、主にLinuxまたは他のUnixディストリビューションが関係しています。
Dockerは、実行可能ファイルを実行するための制限をOS（ほとんどLinux）に伝える方法を知っているアプリケーションの1つです。実行可能ファイルは、単にtarfileであるDockerイメージに含まれています。その実行可能ファイルは、通常、1つ以上のアプリケーションを実行するように事前構成されたLinuxディストリビューション（Ubuntu、CentOS、Debianなど）の簡略版です。
ほとんどの人は実行可能ファイルとしてLinuxベースを使用しますが、ホストOSが実行できる限り、他のバイナリアプリケーションでもかまいません（スクラッチを使用した単純なベースイメージの作成を参照）。DockerイメージのバイナリがOSであるか、単なるアプリケーションであるかに関係なく、OSホストにとってそれは単なる別のプロセスであり、事前に設定されたOS境界によって支配される包含プロセスです。
Dockerのように、実行中にプロセスに適用する境界をホストOSに通知できる他のアプリケーションには、LXC、libvirt、systemdなどがあります。Dockerはこれらのアプリケーションを使用してLinux OSと間接的に対話していましたが、今ではDockerは「libcontainer」と呼ばれる独自のライブラリを使用してLinuxと直接対話しています。
したがって、コンテナーは、chrootが行っていたのと同様に、制限されたモードで実行される単なるプロセスです。
IMO、Dockerを他のコンテナーテクノロジーと差別化するのは、リポジトリー（Docker Hub）とコンテナーを簡単に操作できるようにする管理ツールです。
Docker（software）を参照してください。
多くの答えが、このアウトを指摘したように：あなたは構築 Dockerfileを取得するには、画像を、あなたが実行し た画像を取得するための容器を。
ただし、以下の手順を実行することで、Dockerイメージとコンテナーがどのようなものであるかをよく理解できました。
1）Dockerfileをビルドします。
docker build -t my_image dir_with_dockerfile
2）画像を.tarファイルに保存します
docker save -o my_file.tar my_image_id
my_file.tar画像を保存します。それをtar -xvf my_file.tarで開くと、すべてのレイヤーが表示されます。各レイヤーの詳細を確認すると、各レイヤーにどのような変更が加えられたかを確認できます。（Dockerfileのコマンドにかなり近いはずです）。
3）コンテナの内部を見るには、次のようにします。
sudo docker run -it my_image bash
これはOSに非常によく似ています。
画像はOOPのクラス定義に相当し、レイヤーはそのクラスの異なるメソッドとプロパティです。
コンテナは、オブジェクトがインスタンス化またはクラスのインスタンスであるのと同じように、イメージの実際のインスタンス化です。
最初に説明した方がいいと思います。
コマンドを実行するとしますdocker run hello-world。何が起こるのですか？
Dockerコマンドを受け取り、変換してDockerサーバーコマンドを呼び出すDocker CLIを呼び出します。すぐにドッカーサーバが実行するコマンドを取得した画像を、そのチェックは天候の画像キャッシュが保持している画像をような名前のを。
hello-worldが存在しないとします。DockerサーバーはDocker Hub（Docker Hubは単なる画像の無料リポジトリです）にアクセスし、「ねえ、Hub、というイメージがありhello-worldますか？」ハブの応答-はい、そうです。それから私にそれをください。そして、ダウンロードプロセスが始まります。Dockerイメージがダウンロードされるとすぐに、Dockerサーバーはそれをイメージキャッシュに配置します。
DockerイメージとDockerコンテナーについて説明する前に、コンピューターのオペレーティングシステムとソフトウェアの実行方法について紹介します。
たとえば、コンピューターでChromeを実行すると、オペレーティングシステムが呼び出され、オペレーティングシステム自体がカーネルを呼び出して、このプログラムを実行したいかどうかを尋ねます。カーネルは、ハードディスクからファイルを実行するために管理します。
次に、ChromeとNode.jsの2つのプログラムがあるとします。Chromeを実行するにはPythonバージョン2が必要であり、Node.jsを実行するにはPythonバージョン3が必要です。パソコンにPython v2のみをインストールした場合は、Chromeのみが実行されます。
両方のケースを機能させるには、ネームスペースと呼ばれるオペレーティングシステム機能を使用する必要があります。名前空間は、プロセス、ハードドライブ、ネットワーク、ユーザー、ホスト名などを分離する機会を提供する機能です。
したがって、イメージについて話すときは、実際にはファイルシステムのスナップショットについて話します。画像は、特定の構築に方向およびメタデータが含まれている物理的なファイルであるコンテナを。容器自体は、のインスタンスである画像。このコンテナでのみ使用可能な名前空間を使用してハードドライブを分離します。したがって、コンテナは、それに割り当てられたさまざまなリソースをグループ化するプロセスまたはプロセスのセットです。
プログラミングの側面と同様に、
画像はソースコードです。
ソースコードがコンパイルされてビルドされるとき、それはアプリケーションと呼ばれます。
「イメージのインスタンスが作成されるとき」と同様に、「コンテナ」と呼ばれます。
画像は、の「スナップショット」であるコンテナ。コンテナーからイメージを作成でき（新しい「スナップショット」）、イメージから新しいコンテナーを開始することもできます（「スナップショット」をインスタンス化します）。
たとえば、ベースイメージから新しいコンテナをインスタンス化し、コンテナでいくつかのコマンドを実行して、それを新しいイメージとしてスナップショットできます。次に、その新しいイメージから100個のコンテナを実行できます。
その他の考慮事項：
- 画像はレイヤーで構成され、レイヤーはスナップショットの「差分」です（したがって、イメージをプッシュするときは、「差分」をレジストリに送信するだけで済みます）。
- Dockerfileは、基本イメージの上にいくつかのコマンドを定義し、新しいレイヤー（「差分」）を作成して、新しいイメージ（「スナップショット」）を作成します。
- 画像タグは単なるタグではありません。これらは画像の「フルネーム」（「repository：tag」）です。同じ画像に複数の名前がある場合、を実行すると複数回表示されます
docker images。
私は間ここに欠けている部分を埋めたいdocker imagesとcontainers。Dockerはコンテナーにユニオンファイルシステム（UFS）を使用します。これにより、複数のファイルシステムを階層にマウントし、単一のファイルシステムとして表示することができます。イメージのファイルシステムはread-onlyレイヤーとしてマウントされており、実行中のコンテナーに対する変更は、read-writeこの上にマウントされたレイヤーに加えられます。このため、Dockerは、実行中のシステムに加えられた変更を見つけるために、最上位の読み書きレイヤーを調べるだけで済みます。
ダミーのプログラミングの例えとして、DockerにはストアからのImageFactoriesを保持する抽象的なImageFactoryがあると考えることができます。
次に、そのImageFactoryからアプリを作成したい場合は、新しいコンテナーが作成され、必要に応じてそれを変更できます。DotNetImageFactoryは、必要なインスタンスのみを提供する抽象ファクトリクラスとして機能するため、不変です。
IContainer newDotNetApp = ImageFactory.DotNetImageFactory.CreateNew(appOptions);
newDotNetApp.ChangeDescription("I am making changes on this instance");
newDotNetApp.Run();
要するに：
コンテナーは、共通のOSを共有し、イメージ（Dockerイメージ）を実行するカーネルの部門（仮想）です。
コンテナーは、パッケージと、コードを実行するために必要なすべての依存関係を一緒に持つ、自立可能なアプリケーションです。