違い - dockerイメージとは




Dockerイメージとコンテナの違いは何ですか? (14)

Dockerを使用する場合は、ベースイメージから始めます。 私たちはそれを起動し、変更を作成し、それらの変更は別のイメージを形成するレイヤーに保存されます。

最終的に私は自分のPostgreSQLインスタンスのイメージとWebアプリケーションのイメージを持っています。変更は永続化され続けます。

だから問題は:コンテナとは何ですか?


ワークフロー

ここでは、さまざまなコマンドと関連する入力と出力を示すエンドツーエンドのワークフローを示します。 それはイメージとコンテナの関係を明確にするはずです。

+------------+  docker build   +--------------+  docker run -dt   +-----------+  docker exec -it   +------+
| Dockerfile | --------------> |    Image     | --------------->  | Container | -----------------> | Bash |
+------------+                 +--------------+                   +-----------+                    +------+
                                 ^
                                 | docker pull
                                 |
                               +--------------+
                               |   Registry   |
                               +--------------+

実行可能なイメージを一覧表示するには、次のコマンドを実行します。

docker image ls

コンテナを表示するには、次のコマンドを実行します。

docker ps

Dockerfileは、tarball(Dockerイメージ)を生成するbashスクリプトと似ています。

ドッカーのコンテナは、抽出されたバージョンのtarballに似ています。 異なるフォルダ(コンテナ)に好きなだけ多くのコピーを置くことができます。


Dockerコンテナがイメージのインスタンスを実行しています。 あなたはプロセスを使ってイメージをプログラムとコンテナと関連付けることができます:)


ドッカーの自動配置に関する私の記事から:

ドッカー画像とコンテナ

Dockerlandでは、 画像があり、 コンテナがあります。 2つは密接に関連していますが、区別されます。 私にとって、この二分法をつかむことは、ドッカーを非常に明確にしました。

画像とは何ですか?

イメージは不活性で不変なファイルであり、本質的にコンテナのスナップショットです。 イメージはbuildコマンドで作成され、 run時に開始されるとコンテナが生成されrun 。 画像はDockerレジストリ(registry.hub.docker.comなど)に保存されregistry.hub.docker.com 。 それらはかなり大きくなる可能性があるため、画像は他の画像のレイヤーで構成されるように設計されているため、ネットワーク経由で画像を転送するときに、相当量のデータを送信できます。

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

注意すべき事項

  1. IMAGE IDは、画像の真の識別子の最初の12文字です。 あなたは与えられたイメージの多くのタグを作ることができますが、それらのIDはすべて同じです(上記と同じです)。
  2. 仮想サイズは、すべての個別の下層のサイズを合計するため、 仮想です。 これは、その列のすべての値の合計が、おそらくそれらのすべてのイメージで使用されているディスク容量よりもはるかに大きいことを意味します。
  3. REPOSITORY列の値は、 docker buildコマンドの-tフラグ、または既存のイメージをdocker tag dockerから取得されます。 あなたは、あなたに合った命名法を使ってイメージにタグを付けることは自由ですが、ドッカーがdocker pushまたはdocker pullでレジストリロケーションとしてタグを使用することを知っています。
  4. タグの完全な形式は[REGISTRYHOST/][USERNAME/]NAME[:TAG]です。 上記のubuntu場合、REGISTRYHOSTはregistry.hub.docker.comと推測されregistry.hub.docker.com 。 したがって、 my-applicationという名前のイメージをdocker.example.comレジストリに格納する予定がある場合は、そのイメージにdocker.example.com/my-applicationというタグを付ける必要があります。
  5. TAG列は、 完全タグの[:TAG]部分だけです。 これは不幸な用語です。
  6. latestタグは魔法的ではありません。タグを指定しないと、デフォルトのタグになります。
  7. タグの付いていない画像をIMAGE IDで識別できるようにすることができます。 これらは<none> TAGとREPOSITORYを取得します。 彼らを忘れるのは簡単です。

画像の詳細は、 Dockerのドキュメントglossaryから入手できます。

コンテナは何ですか?

プログラミングのメタファーを使用するには、イメージがクラスの場合、コンテナはクラスのインスタンス、つまり実行時オブジェクトです。 コンテナは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

ここで私はドッカーのレジストリのドッキングされたバージョンを実行しているので、自分のイメージを保存する私的な場所があります。 もう一度、注意すべき点がいくつかあります。

  1. IMAGE IDと同様に、CONTAINER IDはコンテナの真の識別子です。 それは同じ形式を持ちますが、異なる種類のオブジェクトを識別します。
  2. docker ps実行中のコンテナのみを出力します。 docker ps -aして、 実行中または停止中のすべてのコンテナを表示できます。
  3. NAMESは、-- --nameフラグを使用して開始コンテナを識別するために使用できます。

イメージとコンテナの蓄積を避けるには?

ドッカーとの私の初期の不満の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の既知の苦境点であり、将来のリリースで対処される可能性があります。 しかし、イメージとコンテナをはっきりと理解することで、次のような状況を避けることができます。

  1. docker rm [CONTAINER_ID]を使用して、無用で停止したコンテナを必ず削除してdocker rm [CONTAINER_ID]
  2. docker rmi [IMAGE_ID]て、無用で停止したコンテナの後ろのイメージを必ず削除してdocker rmi [IMAGE_ID]

ImageはOOPのクラス定義と同等であり、レイヤはそのクラスの異なるメソッドとプロパティです。

コンテナは、オブジェクトがインスタンス化またはクラスのインスタンスと同じようにイメージの実際のインスタンス化です。


イメージのインスタンスはコンテナと呼ばれます。 あなたはイメージを持っています。これは、あなたが描いているように、一連のレイヤーです。 このイメージを起動すると、このイメージの実行中のコンテナがあります。 同じイメージの多くの実行コンテナを持つことができます。

docker imagesすべてのイメージを見ることができますが、 docker ps実行中のコンテナを見ることができます( docker ps -aすべてのコンテナを見ることができます)。

したがって、イメージの実行インスタンスはコンテナです。


コンテナは、適用する制限をOSに通知する方法を知っているアプリケーション(例えば、ドッカー)を使用して予め設定された制限のセットの下で、ホストOSによって実行される実行可能バイナリである。

典型的な制限は、プロセス分離関連、セキュリティ関連(SELinux保護のような)、システムリソース関連(メモリ、ディスク、CPU、ネットワーキング)です。

最近まで、Unixベースのシステムのカーネルだけが、厳格な制限の下で実行可能ファイルを実行する機能をサポートしていました。 だからこそ、今日のコンテナの話のほとんどは、主にLinuxやその他のUnixディストリビューションに関係しています。

Dockerは、実行可能ファイルを実行するためにどのような制限があるのか​​をOS(Linuxほとんど)に伝える方法を知っているアプリケーションの1つです。 実行可能ファイルはDockerイメージに含まれています。これは単なるtarfileです。 その実行可能ファイルは、通常、1つまたは複数のアプリケーションを実行するように事前設定された、Linuxディストリビューション(Ubuntu、centos、Debianなど)の削除版です。

ほとんどの人は実行可能ファイルとしてLinuxベースを使用しますが、ホストOSが実行できる限り、他のバイナリアプリケーションでもかまいません。 ( スクラッチを使用した簡単なベースイメージの作成を参照)。 ドッカーイメージ内のバイナリがOSであるかアプリケーションであるかに関係なく、OSホストにとってはそれは単なる別のプロセスであり、含まれるプロセスはあらかじめ設定されたOS境界によって決まります。

Dockerと同様に、実行中のプロセスに適用する境界をLXClibvirt 、およびsystemdなどのホストOSに伝えることができる他のアプリケーションもあります。 Dockerはこれらのアプリケーションを使ってLinux OSと間接的に対話していましたが、現在はDockerが独自のライブラリ「 libcontainer 」を使用してLinuxと直接対話しています。

そのため、コンテナは、 chrootやり方と同様に、制限されたモードで実行されているプロセスだけです。

Dockerを他のコンテナ技術と区別して設定するIMOは、リポジトリ(Docker Hub)とその管理ツールを備えているので、コンテナでの作業が非常に簡単です。

https://en.m.wikipedia.org/wiki/Docker_(Linux_container_engine)参照してhttps://en.m.wikipedia.org/wiki/Docker_(Linux_container_engine)


コンテナを実行イメージと考えるのは簡単ですが、これはあまり正確ではありません。

イメージは実際にはコンテナに変換できるテンプレートです。 イメージをコンテナに変換するために、Dockerエンジンはイメージを取得し、読み書き可能なファイルシステムを上に追加し、ネットワークポート、コンテナ名、ID、リソース制限などのさまざまな設定を初期化します。 実行中のコンテナには現在実行中のプロセスがありますが、コンテナを停止することもできます(またはDockerの用語で終了することもできます)。 終了したコンテナは、イメージと同じではありません。イメージを再起動して、設定やファイルシステムの変更を保持します。


ドッカーのコアコンセプトは、この場合はコンテナと見なすことができる「マシン」を簡単に作成できるようにすることです。 コンテナは再利用性を助け、コンテナの作成と削除を容易に行えます。

イメージは、あらゆる時点でのコンテナの状態を表しています。 基本的なワークフローは次のとおりです。

  1. イメージを作成する
  2. コンテナを始める
  3. コンテナを変更する
  4. コンテナをイメージとして保存する

プログラミングの側面と同様に、

画像はソースコードです。

ソースコードがコンパイルされ、ビルドされると、アプリケーションとして呼び出されます。

Simillarに「インスタンスがイメージ用に作成されたとき」には、「 コンテナ 」と呼ばれ、


多分、ワークフロー全体を助けることができると説明してください。

すべてはDockerfileから始まります。 DockerfileはImageのソースコードです。

Dockerファイルが作成されると、それを作成してコンテナのイメージを作成します。 イメージはDockerfileである "ソースコード"の "コンパイルされたバージョン"です。

コンテナのイメージを取得したら、 レジストリを使用して再配布する必要があります 。 レジストリはgitリポジトリのようなものです。イメージをプッシュしてプルすることができます。

次に、イメージを使用してコンテナを実行できます。 実行中のコンテナは、多くの面で仮想マシンと非常によく似ています(ただし、 hypervisorません)。

このポストは、ドッカーのコンテナに関する多くの基本的なことを説明しています(これはDockerとPuppetについて言及していますが、どのようなコンテキストでも使用できる多くの概念があります)


私はここですべての質問を読んでいたにもかかわらず、 イメージレイヤーのコンセプトを理解することができず、ついにDockerのこの優れたドキュメントを見つけました。

この例では、概念全体を理解するための鍵があります。 それは長い投稿ですので、私は明確にするために本当に把握する必要がある要点を要約しています。

  • 画像 :ドッカー画像は一連の読み取り専用レイヤーから構築されます

  • レイヤー :各レイヤーは画像のDockerfile内の命令を表します。

Example :以下のDockerfileには4つのコマンドがあり、それぞれがレイヤーを作成します。

FROM ubuntu:15.04

COPY。 / app

RUN make / app

CMD python /app/app.py

重要なのは 、各レイヤーはそれ以前のレイヤーとの違いだけです。

  • コンテナ 。 新しいコンテナを作成するときは、下にあるレイヤーの上に新しい書き込み可能なレイヤーを追加します 。 この層はしばしば「コンテナ層」と呼ばれます。 実行中のコンテナに対する新しいファイルの書き込み、既存のファイルの変更、およびファイルの削除などのすべての変更は、この書き込み可能な薄いコンテナレイヤーに書き込まれます。

したがって、コンテナとイメージの主な違いは、 一番上の書き込み可能なレイヤーです。 既存のデータを新規に追加したり変更したりするコンテナへのすべての書き込みは、この書き込み可能なレイヤに格納されます。 コンテナが削除されると、書き込み可能なレイヤーも削除されます。 基本となるイメージは変更されません。

イメージの理解cndディスク上の観点からのコンテナ

実行中のコンテナのおおよそのサイズを表示するには、 docker ps -sコマンドを使用します。 2つの出力としてsizevirtual sizeが得られます。

  • サイズ:各コンテナの書き込み可能なレイヤに使用されるデータ量(ディスク上)

  • 仮想サイズ:コンテナによって使用される読み取り専用画像データに使用されるデータの量。 複数のコンテナは、読み取り専用の画像データの一部または全部を共有してもよい。 したがって、これらは相加的ではありません。 つまり、イメージに使用されているディスク上のサイズを計算するために、すべての仮想サイズを追加することはできません

別の重要な概念は、コピーオンライト戦略です

ファイルまたはディレクトリがイメージ内の下位層に存在し、別の層(書き込み可能な層を含む)に読み込みアクセスが必要な場合は、既存のファイルを使用するだけです。 最初に別のレイヤーがファイルを変更する必要があるとき(イメージの作成時またはコンテナの実行時)、ファイルはそのレイヤーにコピーされ、変更されます。

それが私のような誰かを助けることを願っています。


簡単に言えば、画像がクラスの場合、コンテナはクラスのインスタンスです。ランタイムオブジェクトです。


要するに:

コンテナは、共通のOSを共有し、イメージ(Dockerイメージ)を実行するカーネル内の分割(仮想)です。

コンテナは、コードを実行するために必要なすべての依存関係とパッケージを持つ、自立可能なアプリケーションです。







docker-image