shivab.com/blog/docker/2019/01/10/…の
—
イリュージョニスト
回答:
コンテナについて最初に知っておくべきことは次のとおりです。
何よりもまず、プロセスです。
それが理解されると、コンテナが仮想マシンとどのように比較対照されるかを理解し始めることができます。コンテナとVMはどちらも、ホストからの分離を共有しています。分離の方法は重大な違いです。
コンテナプロセスは、実行されるOSカーネルホストの拡張機能を使用して、他のプロセスから分離します。他の拡張機能もディスクとリソースを分離します。コンテナは、カーネルとメモリをホストOSと共有します。
仮想マシンは、ハイパーバイザーを使用してホストからVMを分離します。これは、リソースの要求を「ゲスト」（VM）からハードウェアに転送するソフトウェアのレイヤーです。ディスクの分離は、ディスクの仮想化によって提供されます。VM はカーネルをホストと共有しません。VM専用のメモリ空間に独自のカーネルをロードします。
この違いの重要な影響の1つは、コンテナがそのホストとカーネル互換でなければならないことです。たとえば、LinuxホストでWindows Nano Serverベースのコンテナを実行したり、WindowsホストでUbuntuコンテナを直接実行したりすることはできません。対照的に、仮想マシンは、ホストOSに関係なく、任意のカーネルを実行できます。WindowsホストでLinuxコンテナーを実行する場合、DockerはLinux VMでコンテナーを実行します。
操作上の違いは俊敏性にあります。コンテナは通常のプロセスとほぼ同じ速さで起動および停止します。VMは「重い」ため、専用のリソースを確保しておく必要があり、起動とシャットダウンに時間がかかります。
コンテナは、DevOpsオペレーティングモデルに多くの柔軟性を提供します。
コンテナという用語は、最新のLinuxカーネルで利用可能な軽量仮想化技術を指します。この技術は、FreeBSDの刑務所に非常に似ています。
古い、コンテナ非対応のLinuxカーネルは、プロセスを同時に実行できます。プロセス環境やプロセスメモリなど、システムの一部の属性はプロセス専用です。これらの属性を所有するプロセスとオペレーティングシステム自体のみがこのデータにアクセスできます。（いくつかのps実装のように多くの抜け穴がありますが、それは本質的に本当です！）他の属性は、例えばファイルシステムやネットワークインターフェースのようにプロセス間で共有されます。
コンテナ対応の最新のLinuxカーネルは、システムのより多くの属性を、プロセスまたはプロセスのグループに関連付けられたプライベートデータとして処理できます。結果のコンテキストはコンテナであり、オペレーティングシステムによって初期化されたファイルシステムとネットワークインターフェイスを使用して「初期コンテナ」でプログラムを実行する代わりに、他のコンテナでプロセスを実行して、異なるファイルシステムとネットワークインターフェイスの異なるリスト。したがって、個別のコンテナで実行されている2つのプロセスは、実際にカーネルを共有するだけです。異なるファイル階層でプロセスを実行できるchrootコマンドに慣れている方もいるかもしれませんが、コンテナはさらに一歩進んだアイデアを取り入れています。
もちろん、これは非常に大雑把な説明にすぎませんが、コンテナとは何かを理解するのに役立つことを願っています。さて、彼らは何のために良いのでしょうか？
Linuxカーネルのコンテナー機能への一般的なインターフェイスは、ファイルシステム（ドッカーイメージ）を表すアーティファクトを生成し、これらのファイルシステムがアクセス可能なコンテナーでプロセスを実行するために使用できるコマンドラインユーティリティであるdockerによって実装されます。このソフトウェアスイートは、アドホック仮想ネットワークシステムを構築して、複数のコンテナがプライベートネットワークで通信できるようにすることもできます。
コンテナベースの技術は次の場合に便利です。
（Virtual Boxのような他の仮想化技術に精通しているように思われるかもしれませんが、これらの技術は上記の3つの点にも便利に対応できることに気付くかもしれません。コンピューター言語の人気のある特定のコンテキスト：それはおそらく個々のソリューションの技術的なメリットに依存しますが、「チャンス」とラベル付けする多くの要因にも依存します。）
通常、コンテナは、名前を一般化したdockerコンテナのようなものを指します
dockerの定義から引用しています：
コンテナを使用すると、ソフトウェアを実行するために必要なすべてのものが分離されたコンテナにパッケージ化されます。VMとは異なり、コンテナには完全なオペレーティングシステムがバンドルされていません。ソフトウェアを動作させるために必要なライブラリと設定のみが必要です。
ルートの命名は、ホストシステムからプロセスを分離することを目標としたLinuxコンテナ（lxc）に由来します。最初の目標は、ホストシステムを引き継ぐプロセスの妥協を避けることでした。
現在、それらはより広い範囲で使用されています。現代の「コンテナ」の定義では、アプリケーションを既に含むランタイム用のパッケージを多少リリースします。必要に応じて基礎となるミドルウェアとすべての必要なライブラリであり、互換性のあるシステムで実行されることを確認してください。
2番目の利点は、環境変数を大幅に調整して正しいものをロードすることなく、異なるバージョンで同じ依存関係を持つ複数のアプリケーションを使用できることです。
仮想ボックス仮想マシンやAWS上のEC2インスタンスなどのVMシステムとは異なり、コンテナはファイルシステムレベルでのみ仮想であり、メモリスタックでのみ分離されます。彼らはまだ同じホストを共有し、それらの下のオペレーティングシステムはCPUティックを調停します。
仮想マシンはハードウェアレベルで仮想的であり、オペレーティングシステムを内部で実行し、コンテナはOSレベルで仮想的であり、内部でプロセスを実行します。
AWSの定義から：
コンテナは、リソース分離プロセスでアプリケーションとその依存関係を実行できるオペレーティングシステム仮想化の方法です。コンテナを使用すると、アプリケーションのコード、構成、および依存関係を簡単にパッケージ化して、環境の一貫性、運用効率、開発者の生産性、バージョン管理を実現する使いやすいビルディングブロックを作成できます。コンテナは、デプロイメント環境に関係なく、アプリケーションが迅速に、確実に、一貫してデプロイされるようにするのに役立ちます。コンテナを使用すると、リソースをよりきめ細かく制御できるため、インフラストラクチャの効率が向上します。
コンテナ化は、特定のタスク/環境を実行するために必要なすべての必要なものを詰め込んで、それが自給自足であり、あらゆるプラットフォームで実行できるようにします。