4133

Docker と完全な VM の違いを理解しようと、Docker のドキュメントを読み返し続けています。重くすることなく、完全なファイルシステム、分離されたネットワーク環境などを提供するにはどうすればよいでしょうか?

Docker イメージへのソフトウェアのデプロイ (それが正しい用語である場合) が、一貫した実稼働環境への単純なデプロイよりも簡単なのはなぜですか?

4

22 に答える 22

3780

Docker は当初、 Linux コンテナー(LXC) を使用していましたが、後にそのホストと同じオペレーティング システムで実行されるrunC (以前はlibcontainerとして知られていた) に切り替えました。これにより、多くのホスト オペレーティング システム リソースを共有できます。また、レイヤード ファイルシステム ( AuFS ) を使用し、ネットワークを管理します。

AuFS は階層化されたファイル システムであるため、読み取り専用部分と書き込み部分をマージすることができます。オペレーティング システムの共通部分を読み取り専用 (およびすべてのコンテナー間で共有) にして、各コンテナーに書き込み用の独自のマウントを与えることができます。

たとえば、1 GB のコンテナー イメージがあるとします。完全な VM を使用する場合は、1 GB x 必要な VM の数が必要です。Docker と AuFS を使用すると、すべてのコンテナー間で 1 GB の大部分を共有できます。コンテナーが 1000 個ある場合でも、コンテナー OS 用に 1 GB 強のスペースしかない可能性があります (すべてが同じ OS イメージを実行していると仮定します)。 .

完全に仮想化されたシステムは、独自のリソース セットを割り当てられ、最小限の共有を行います。より多くの分離が得られますが、より重くなります (より多くのリソースが必要になります)。Docker を使用すると、分離性は低くなりますが、コンテナーは軽量です (必要なリソースが少なくなります)。そのため、ホスト上で何千ものコンテナを簡単に実行でき、点滅することさえありません. Xen でそれを試してみてください。非常に大きなホストがない限り、それは不可能だと思います。

通常、完全な仮想化システムの起動には数分かかりますが、Docker/LXC/runC コンテナーは数秒、多くの場合 1 秒未満です。

仮想化システムのタイプごとに長所と短所があります。リソースが保証された完全な分離が必要な場合は、完全な VM が最適です。プロセスを相互に分離し、適度なサイズのホストで大量のプロセスを実行したい場合は、Docker/LXC/runC が適しているようです。

詳細については、LXC の仕組みをうまく説明しているこの一連のブログ投稿を確認してください。

ソフトウェアを docker イメージにデプロイする (それが適切な用語である場合) 方が、一貫した実稼働環境に単純にデプロイするよりも簡単なのはなぜですか?

一貫した運用環境を展開することは、言うは易く行うは難しです。ChefやPuppetなどのツールを使用している場合でも、ホストと環境の間で OS の更新やその他の変更が常に行われます。

Docker では、OS を共有イメージにスナップショットする機能が提供され、他の Docker ホストへの展開が容易になります。ローカル、dev、qa、prod など: すべて同じイメージ。確かに他のツールを使ってこれを行うことはできますが、それほど簡単でも速くもありません。

これはテストに最適です。データベースに接続する必要がある何千ものテストがあり、各テストにはデータベースの元のコピーが必要であり、データに変更を加えるとします。これに対する古典的なアプローチは、カスタム コードまたはFlywayなどのツールを使用して、すべてのテストの後にデータベースをリセットすることです。これは非常に時間がかかる可能性があり、テストを連続して実行する必要があることを意味します。ただし、Docker を使用すると、データベースのイメージを作成し、テストごとに 1 つのインスタンスを実行してから、データベースの同じスナップショットに対してすべてのテストが実行されることがわかっているため、すべてのテストを並行して実行できます。テストは並行して実行され、Docker コンテナーで実行されるため、すべてのテストを同じボックスで同時に実行でき、はるかに速く終了するはずです。完全な VM でそれを試してみてください。

コメントから...

面白い！「OS のスナップショット」という概念にまだ混乱していると思います。OSのイメージを作成せずに、どうやってそれを行うのでしょうか?

さて、説明できるか見てみましょう。基本イメージから始めて変更を加え、docker を使用してそれらの変更をコミットすると、イメージが作成されます。この画像には、ベースとの違いのみが含まれています。イメージを実行する場合は、ベースも必要です。レイヤード ファイル システムを使用してベースの上にイメージをレイヤー化します。前述のように、Docker は AuFS を使用します。AuFS はさまざまなレイヤーを一緒にマージし、必要なものを取得します。実行するだけです。より多くの画像 (レイヤー) を追加し続けることができ、差分のみを保存し続けます。Docker は通常、レジストリからの既製のイメージの上に構築されるため、OS 全体を自分で「スナップショット」する必要はほとんどありません。

于 2013-04-16T22:35:27.317 に答える
687

仮想化とコンテナーが低レベルでどのように機能するかを理解しておくと役立つ場合があります。それは多くのことをクリアします。

注: 以下の説明では、少し単純化しています。詳細については、参考文献を参照してください。

仮想化は低レベルでどのように機能しますか?

この場合、VM マネージャーは CPU リング 0 (または新しい CPU の「ルート モード」) を引き継ぎ、ゲスト OS によって行われるすべての特権呼び出しをインターセプトして、ゲスト OS が独自のハードウェアを持っているという錯覚を生み出します。興味深い事実: 1998 年以前は、この種の傍受を行う方法がなかったため、x86 アーキテクチャでこれを達成することは不可能であると考えられていました。これを実現するために、ゲスト OS の特権呼び出し用にメモリ内の実行可能なバイトを書き換えるというアイデアを最初に思いついたのは、 VMware の人々でした。

最終的な効果は、仮想化により、同じハードウェア上で 2 つの完全に異なる OS を実行できるようになることです。各ゲスト OS は、ブートストラップ、カーネルのロードなどのすべてのプロセスを実行します。非常に厳格なセキュリティを確保できます。たとえば、ゲスト OS はホスト OS または他のゲストに完全にアクセスできず、混乱します。

コンテナーは低レベルでどのように機能しますか?

2006年頃、Google の何人かの従業員を含む人々が、名前空間と呼ばれる新しいカーネル レベルの機能を実装しました(ただし、その考えは FreeBSDにずっと前から存在していました)）。OS の機能の 1 つは、ネットワークやディスクなどのグローバル リソースをプロセス間で共有できるようにすることです。これらのグローバル リソースが名前空間にラップされて、同じ名前空間で実行されるプロセスだけに見えるようになったらどうなるでしょうか? たとえば、ディスクのチャンクを取得してそれを名前空間 X に配置すると、名前空間 Y で実行されているプロセスはそれを表示またはアクセスできなくなります。同様に、名前空間 X 内のプロセスは、名前空間 Y に割り当てられているメモリ内の何にもアクセスできません。もちろん、X 内のプロセスは、名前空間 Y 内のプロセスを見たり、話したりすることはできません。これにより、グローバル リソースに一種の仮想化と分離が提供されます。これが Docker の仕組みです。各コンテナーは独自の名前空間で実行されますが、まったく同じ名前空間を使用します。カーネルを他のすべてのコンテナと同様に。分離が行われるのは、カーネルがプロセスに割り当てられた名前空間を認識し、API 呼び出し中にプロセスが独自の名前空間内のリソースにのみアクセスできるようにするためです。

コンテナーと VM の制限は今や明らかです。VM のように、完全に異なる OS をコンテナーで実行することはできません。ただし、同じカーネルを共有しているため、異なる Linux ディストリビューションを実行できます。分離レベルは VM ほど強力ではありません。実際、初期の実装では「ゲスト」コンテナがホストを引き継ぐ方法がありました。また、新しいコンテナをロードすると、VM のように OS の新しいコピー全体が起動しないことがわかります。すべてのコンテナが同じカーネルを共有. これが、コンテナが軽量である理由です。また、VM とは異なり、OS の新しいコピーを実行していないため、かなりの量のメモリをコンテナーに事前に割り当てる必要はありません。これにより、1 つの OS で何千ものコンテナーをサンドボックス化しながら実行できますが、独自の VM で OS の個別のコピーを実行していた場合、これは不可能な場合があります。

于 2016-01-13T01:49:50.753 に答える
361

Ken Cochrane の答えが好きです。

ただし、ここでは詳しく説明しませんが、追加の視点を追加したいと思います。私の意見では、Docker はプロセス全体でも異なります。VM とは対照的に、Docker はハードウェアのリソースを最適に共有するだけではありません。さらに、アプリケーションをパッケージ化するための「システム」を提供します (マイクロサービスのセットとして望ましいですが、必須ではありません)。

私にとっては、rpm、Debianパッケージ、Maven、npm + Gitなどの開発者向けツールと、 Puppet、VMware、Xen などの ops ツールの間のギャップに収まります...

ソフトウェアを docker イメージにデプロイする (それが正しい用語である場合) のは、一貫した実稼働環境に単純にデプロイするよりも簡単なのはなぜですか?

あなたの質問は、一貫した実稼働環境を想定しています。しかし、一貫性を保つにはどうすればよいでしょうか。 サーバーとアプリケーション、パイプラインの段階をいくらか (>10) 検討してください。

これを同期させるために、Puppet、Chef、または独自のプロビジョニング スクリプト、未公開のルール、および/または多くのドキュメントなどを使用し始めます。理論的には、サーバーは無期限に実行でき、完全に一貫して最新の状態に保つことができます。実際には、サーバーの構成を完全に管理することはできないため、構成のドリフトや実行中のサーバーへの予期しない変更が生じる可能性がかなりあります。

したがって、これを回避するための既知のパターン、いわゆるimmutable serverがあります。しかし、不変のサーバー パターンは好まれませんでした。主に、Docker の前に使用されていた VM の制限が原因です。アプリケーションのいくつかのフィールドを変更するためだけに、数ギガバイトの大きなイメージを処理し、それらの大きなイメージを移動するのは、非常に面倒でした。分かりやすい...

Dockerエコシステムを使用すると、「小さな変更」でギガバイトを移動する必要がなくなり（aufsとRegistryに感謝）、実行時にアプリケーションをDockerコンテナにパッケージ化することでパフォーマンスが低下することを心配する必要がなくなります. そのイメージのバージョンについて心配する必要はありません。

そして最後に、Linux ラップトップでも複雑な実稼働環境を再現できることがよくあります (あなたのケースで動作しない場合は、私に電話しないでください ;))

そしてもちろん、VM で Docker コンテナーを開始することもできます (それは良い考えです)。VM レベルでサーバーのプロビジョニングを減らします。上記はすべて Docker で管理できます。

PS 一方、Docker は LXC の代わりに独自の実装「libcontainer」を使用します。しかし、LXC はまだ使用可能です。

于 2014-09-19T16:21:40.260 に答える
302

Docker は仮想化の方法論ではありません。コンテナベースの仮想化またはオペレーティング システム レベルの仮想化を実際に実装する他のツールに依存しています。そのため、Docker は当初 LXC ドライバーを使用していましたが、その後 libcontainer に移動され、現在は runc に名前が変更されています。Docker は主に、アプリケーション コンテナー内でのアプリケーションのデプロイの自動化に重点を置いています。アプリケーション コンテナは単一のサービスをパッケージ化して実行するように設計されていますが、システム コンテナは仮想マシンのように複数のプロセスを実行するように設計されています。したがって、Docker は、コンテナー化されたシステムでのコンテナー管理またはアプリケーション展開ツールと見なされます。

他の仮想化との違いを知るために、仮想化とその種類について見ていきましょう。そうすれば、何が違うのかが理解しやすくなります。

仮想化

考えられた形では、メインフレームを論理的に分割して複数のアプリケーションを同時に実行できるようにする方法と考えられていました。しかし、企業やオープン ソース コミュニティが何らかの方法で特権命令を処理する方法を提供し、単一の x86 ベースのシステムで複数のオペレーティング システムを同時に実行できるようになると、シナリオは大きく変わりました。

ハイパーバイザー

ハイパーバイザーは、ゲスト仮想マシンが動作する仮想環境の作成を処理します。ゲスト システムを監視し、必要に応じてリソースがゲストに割り当てられるようにします。ハイパーバイザーは物理マシンと仮想マシンの間に位置し、仮想化サービスを仮想マシンに提供します。これを実現するために、仮想マシン上のゲスト オペレーティング システムの操作を傍受し、ホスト マシンのオペレーティング システム上の操作をエミュレートします。

主にクラウドにおける仮想化テクノロジーの急速な発展により、Xen、VMware Player、KVM などのハイパーバイザーを利用して、単一の物理サーバー上に複数の仮想サーバーを作成できるようになり、仮想化の使用がさらに促進されました。 Intel VT や AMD-V などのコモディティ プロセッサにハードウェア サポートを組み込む。

仮想化の種類

仮想化方法は、ハードウェアをゲスト オペレーティング システムに模倣し、ゲスト オペレーティング環境をエミュレートする方法に基づいて分類できます。主に、仮想化には次の 3 つのタイプがあります。

  • エミュレーション
  • 準仮想化
  • コンテナベースの仮想化

エミュレーション

エミュレーションは、完全な仮想化とも呼ばれ、仮想マシンの OS カーネルを完全にソフトウェアで実行します。このタイプで使用されるハイパーバイザーは、タイプ 2 ハイパーバイザーとして知られています。これは、ホスト オペレーティング システムの最上位にインストールされ、ゲスト OS カーネル コードをソフトウェア命令に変換します。変換は完全にソフトウェアで行われ、ハードウェアの関与は必要ありません。エミュレーションにより、エミュレートされる環境をサポートする変更されていないオペレーティング システムを実行できます。このタイプの仮想化の欠点は、他のタイプの仮想化と比較してパフォーマンスの低下につながる追加のシステム リソース オーバーヘッドです。

エミュレーション

このカテゴリの例には、VMware Player、VirtualBox、QEMU、Bochs、Parallels などがあります。

準仮想化

タイプ 1 ハイパーバイザーとも呼ばれる準仮想化は、ハードウェアまたは「ベアメタル」上で直接実行され、その上で実行されている仮想マシンに仮想化サービスを直接提供します。オペレーティング システム、仮想化されたハードウェア、および実際のハードウェアが連携して最適なパフォーマンスを実現するのに役立ちます。これらのハイパーバイザーは通常、フットプリントがかなり小さく、それ自体は大規模なリソースを必要としません。

このカテゴリの例には、Xen、KVM などが含まれます。

準仮想化

コンテナベースの仮想化

コンテナー ベースの仮想化は、オペレーティング システム レベルの仮想化とも呼ばれ、単一のオペレーティング システム カーネル内で複数の分離された実行を可能にします。可能な限り最高のパフォーマンスと密度を備え、動的なリソース管理機能を備えています。このタイプの仮想化によって提供される分離された仮想実行環境はコンテナーと呼ばれ、トレースされたプロセスのグループと見なすことができます。

コンテナベースの仮想化

コンテナーの概念は、Linux カーネル バージョン 2.6.24 に追加された名前空間機能によって可能になりました。コンテナーはその ID をすべてのプロセスに追加し、新しいアクセス制御チェックをすべてのシステム コールに追加します。これは、以前はグローバルだった名前空間の個別のインスタンスを作成できるようにするclone()システム コールによってアクセスされます。

名前空間はさまざまな方法で使用できますが、最も一般的な方法は、コンテナの外部にあるオブジェクトへの可視性やアクセス権を持たない分離されたコンテナを作成することです。コンテナー内で実行されているプロセスは、通常の Linux システムで実行されているように見えますが、他の種類のオブジェクトと同様に、他の名前空間にあるプロセスと基礎となるカーネルを共有しています。たとえば、名前空間を使用する場合、コンテナー内の root ユーザーはコンテナー外では root として扱われないため、セキュリティが強化されます。

Linux コントロール グループ (cgroups) サブシステムは、コンテナー ベースの仮想化を可能にする次の主要コンポーネントであり、プロセスをグループ化し、それらの総リソース消費を管理するために使用されます。これは、コンテナのメモリと CPU の消費を制限するためによく使用されます。コンテナー化された Linux システムにはカーネルが 1 つしかなく、カーネルはコンテナーを完全に可視化できるため、リソースの割り当てとスケジューリングのレベルは 1 つだけです。

Linux コンテナーでは、LXC、LXD、systemd-nspawn、lmctfy、Warden、Linux-VServer、OpenVZ、Docker など、いくつかの管理ツールを使用できます。

コンテナ vs 仮想マシン

仮想マシンとは異なり、コンテナーはオペレーティング システム カーネルを起動する必要がないため、コンテナーは 1 秒未満で作成できます。この機能により、コンテナー ベースの仮想化は、他の仮想化アプローチよりもユニークで望ましいものになります。

コンテナ ベースの仮想化はホスト マシンにほとんど、またはまったくオーバーヘッドを追加しないため、コンテナ ベースの仮想化はネイティブに近いパフォーマンスを実現します。

コンテナベースの仮想化では、他の仮想化とは異なり、追加のソフトウェアは必要ありません。

ホスト マシン上のすべてのコンテナは、ホスト マシンのスケジューラを共有し、追加のリソースの必要性を節約します。

コンテナーの状態 (Docker または LXC イメージ) は、仮想マシン イメージと比較してサイズが小さいため、コンテナー イメージは配布が容易です。

コンテナー内のリソース管理は、cgroups によって実現されます。cgroups は、コンテナが割り当てられた以上のリソースを消費することを許可しません。ただし、現時点では、ホスト マシンのすべてのリソースが仮想マシンに表示されますが、使用することはできません。topこれは、またはhtopコンテナーとホスト マシンで同時に実行することで実現できます。すべての環境での出力は似ています。

アップデート：

Docker は Linux 以外のシステムでコンテナーをどのように実行しますか?

Linux カーネルで利用可能な機能によってコンテナーが可能である場合、明らかな問題は、Linux 以外のシステムでコンテナーをどのように実行するかです。Docker for Mac と Windows はどちらも Linux VM を使用してコンテナーを実行します。Virtual Box VM でコンテナーを実行するために使用される Docker Toolbox。ただし、最新の Docker は、Windows では Hyper-V を使用し、Mac では Hypervisor.framework を使用します。

それでは、Docker for Mac がどのようにコンテナーを実行するかについて詳しく説明します。

Docker for Mac はhttps://github.com/moby/hyperkitを使用してハイパーバイザー機能をエミュレートし、Hyperkit はコアで hypervisor.framework を使用します。Hypervisor.framework は、Mac のネイティブ ハイパーバイザー ソリューションです。Hyperkit は VPNKit と DataKit も使用して、それぞれネットワークとファイルシステムの名前空間を作成します。

Docker が Mac で実行する Linux VM は読み取り専用です。ただし、次を実行することで、それにバッシュできます。

screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty.

これで、この VM のカーネル バージョンを確認することもできます。

# uname -a Linux linuxkit-025000000001 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:86_64 Linux.

すべてのコンテナーは、この VM 内で実行されます。

hypervisor.framework にはいくつかの制限があります。docker0そのため、Docker はMac でネットワーク インターフェイスを公開しません。そのため、ホストからコンテナーにアクセスすることはできません。現時点でdocker0は、VM 内でのみ使用できます。

Hyper-v は、Windows のネイティブ ハイパーバイザーです。また、Windows 10 の機能を活用して Linux システムをネイティブに実行しようとしています。

于 2016-04-02T00:55:59.610 に答える
70

両者は大きく異なります。Docker は軽量で、LXC/libcontainer (カーネルの名前空間と cgroup に依存する) を使用し、ハイパーバイザーや KVM などのマシン/ハードウェア エミュレーションを備えていません。重いXen。

Docker と LXC は、サンドボックス化、コンテナ化、およびリソースの分離を目的としています。IPC、NS (マウント)、ネットワーク、PID、UTS などの名前空間を提供するホスト OS (現在は Linux カーネルのみ) のクローン API を使用します。

メモリ、I/O、CPU などはどうですか? これは、特定のリソース (CPU、メモリなど) の仕様/制限を持つグループを作成し、そこにプロセスを配置できる cgroups を使用して制御されます。LXC の上に、Docker はストレージ バックエンド ( http://www.projectatomic.io/docs/filesystems/ ) を提供します。たとえば、レイヤーを追加し、異なるマウント名前空間間でレイヤーを共有できるユニオン マウント ファイルシステムです。

これは強力な機能であり、基本イメージは通常読み取り専用であり、コンテナーがレイヤー内の何かを変更した場合にのみ、読み取り/書き込みパーティションに何かを書き込みます (別名、コピー オン ライト)。また、レジストリやイメージのバージョン管理など、他の多くのラッパーも提供します。

通常の LXC では、いくつかの rootfs を用意するか、rootfs を共有する必要があり、共有すると変更が他のコンテナーに反映されます。これらの追加機能が多いため、Docker は LXC よりも人気があります。LXC は、ネットワークや UI などの外部エンティティに公開されているプロセスの周りにセキュリティを実装するための組み込み環境で人気があります。Docker は、一貫した運用環境が期待されるクラウド マルチテナンシー環境で人気があります。

通常の VM (VirtualBox や VMware など) はハイパーバイザーを使用し、関連するテクノロジには、最初の OS (ホスト OS、またはゲスト OS 0) の最初のレイヤーとなる専用のファームウェア、またはホスト OS 上で実行されるソフトウェアを使用して、 CPU、USB/アクセサリ、メモリ、ネットワークなどのハードウェア エミュレーションをゲスト OS に提​​供します。VM は (2015 年現在) 高セキュリティのマルチテナント環境で依然として人気があります。

Docker/LXC はほとんどの安価なハードウェアで実行できます (新しいカーネルを使用している限り、1 GB 未満のメモリでも問題ありません)。通常の VM では、意味のあることを行うために少なくとも 2 GB のメモリが必要です。 . ただし、ホスト OS での Docker サポートは、Windows などの OS では利用できません (2014 年 11 月現在)。多くの種類の VM を Windows、Linux、および Mac で実行できます。

docker/rightscale からの写真は次のとおりです。ここにrightscaleからの写真があります

于 2014-11-03T17:44:42.813 に答える
48

1.軽量

これはおそらく、多くの docker 学習者の第一印象です。

まず、docker イメージは通常 VM イメージよりも小さいため、ビルド、コピー、共有が容易になります。

次に、Docker コンテナーは数ミリ秒で起動できますが、VM は数秒で起動します。

2.階層化ファイルシステム

これは、Docker のもう 1 つの重要な機能です。イメージにはレイヤーがあり、異なるイメージでレイヤーを共有できるため、さらに省スペースでビルドが高速になります。

すべてのコンテナがベース イメージとして Ubuntu を使用している場合、すべてのイメージが独自のファイル システムを持っているわけではありませんが、同じ下線付きの ubuntu ファイルを共有し、独自のアプリケーション データのみが異なります。

3. 共有 OS カーネル

コンテナーをプロセスと考えてください。

ホスト上で実行されているすべてのコンテナーは、実際には、異なるファイル システムを持つ一連のプロセスです。これらは同じ OS カーネルを共有し、システム ライブラリと依存関係のみをカプセル化します。

これはほとんどの場合 (余分な OS カーネルが維持されない) には適していますが、コンテナー間で厳密な分離が必要な場合は問題になる可能性があります。

なぜ重要なのですか？

これらはすべて、革命ではなく改善のように見えます。まあ、量的な蓄積は質的な変化につながります。

アプリケーションの展開について考えてみましょう。新しいソフトウェア (サービス) を展開したり、アップグレードしたりする場合は、新しい VM を作成する代わりに、構成ファイルとプロセスを変更することをお勧めします。更新されたサービスを使用して VM を作成し、それをテストし (開発と QA の間で共有)、本番環境への展開には数時間、場合によっては数日かかるためです。何か問題が発生した場合は、最初からやり直す必要があり、さらに多くの時間を無駄にします。そのため、構成管理ツール (puppet、saltstack、chef など) を使用して新しいソフトウェアをインストールし、新しいファイルをダウンロードすることをお勧めします。

docker に関して言えば、新しく作成された docker コンテナーを使用して古いものを置き換えることは不可能です。メンテナンスははるかに簡単です!新しいイメージの構築、QA との共有、テスト、展開には数分 (すべてが自動化されている場合)、最悪の場合は数時間しかかかりません。これは不変インフラストラクチャと呼ばれます。ソフトウェアを保守 (アップグレード) せず、代わりに新しいものを作成します。

サービスの提供方法を​​変革します。アプリケーションが必要ですが、VM を維持する必要があります (これは苦痛であり、アプリケーションとはほとんど関係ありません)。Docker を使用すると、アプリケーションに集中でき、すべてがスムーズになります。

于 2017-08-10T04:25:41.233 に答える
27

に関して：-

「一貫した実稼働環境に単純にデプロイするよりも、docker イメージにソフトウェアをデプロイする方が簡単なのはなぜですか?」

ほとんどのソフトウェアは多くの環境に展開されます。通常は、次のうち少なくとも 3 つに展開されます。

  1. 個々の開発者用 PC
  2. 共有開発環境
  3. 個々のテスター PC
  4. 共有テスト環境
  5. QA環境
  6. UAT 環境
  7. 負荷/パフォーマンス テスト
  8. ライブステージング
  9. 製造
  10. 記録

考慮すべき次の要因もあります。

  • 開発者、そして実際にはテスターは、仕事の性質上、微妙に、または大幅に異なる PC 構成を持っています。
  • 開発者は、企業またはビジネスの標準化ルールの制御を超えて PC 上で開発することがよくあります (たとえば、自分のマシンで (多くの場合リモートで) 開発するフリーランサーや、PC を特定の構成に「雇用」または「契約」していないオープン ソース プロジェクトへの貢献者など)。仕方）
  • 一部の環境は、負荷分散された構成の固定数の複数のマシンで構成されます
  • 多くの運用環境では、トラフィック レベルに応じて動的に (または「弾力的に」) 作成および破棄されるクラウドベースのサーバーが使用されます。

ご覧のように、組織の推定サーバー総数が 1 桁になることはめったになく、3 桁になることが非常に多く、さらに大幅に増える可能性があります。

これはすべて、最初から一貫した環境を作成することは、膨大な量のため (グリーン フィールド シナリオであっても) 十分に難しいことを意味しますが、多数のサーバー、新しいサーバーの追加 (動的またはo/s ベンダー、ウイルス対策ベンダー、ブラウザー ベンダーなどによる自動更新、開発者またはサーバー技術者による手動ソフトウェア インストールまたは構成変更など。繰り返しますが、事実上 (しゃれた意図はありませんが) 不可能です。環境の一貫性を維持するためです (純粋主義者にとっては可能ですが、膨大な時間、労力、規律が必要です。これがまさに、そもそも VM とコンテナー (Docker など) が考案された理由です)。

したがって、あなたの質問を次のように考えてみてください。「すべての環境の一貫性を維持することは非常に困難です。学習曲線を考慮したとしても、ソフトウェアを Docker イメージにデプロイする方が簡単ですか?」. 答えは常に「はい」であることがわかると思いますが、調べる方法は 1 つしかありません。この新しい質問を Stack Overflow に投稿してください。

于 2016-10-15T11:25:12.500 に答える
0
Feature virtualization (Docker) Containers
OS 各 VM にはGuest OS 各 Docker コンテナには、Guest OS
ハードウェア 各 VM には、OS の実行に必要なハードウェアの仮想コピーが含まれています。 コンテナによるH/Wの仮想化はありません
重さ VM は重い -- 上記の理由 -- コンテナは軽量であるため、高速です
必要なソフトウェア ハイパーバイザーと呼ばれるソフトウェアを利用して仮想化を実現 Dockerと呼ばれるソフトウェアを使用してコンテナ化を実現
芯 仮想マシンは、仮想ハードウェア (または、オペレーティング システムやその他のプログラムをインストールできるハードウェア) を提供します。 Docker コンテナーはハードウェア仮想化を使用しません。**コンテナを使用すると便利です
抽象化 仮想マシンはハードウェアの抽象化を提供するため、複数のオペレーティング システムを実行できます。 コンテナーはOS の抽象化を提供するため、複数のコンテナーを実行できます。
起動時間 使用するソフトウェアに加えてオペレーティング システム全体を実行するため、作成に長い時間 (多くの場合数分) がかかり、かなりのリソース オーバーヘッドが必要になります。 Docker コンテナー内で実行されているプログラムは、ホストの Linux カーネルと直接やり取りするため、時間がかかりません。
于 2022-02-27T09:57:12.117 に答える
-4

ドッカーのドキュメント (および自己説明) では、「仮想マシン」と「コンテナー」を区別しています。彼らは物事を少し変わった方法で解釈して使用する傾向があります。彼らがそれを行うことができるのは、ドキュメントに何を書くかは彼ら次第であり、仮想化の用語がまだ正確ではないためです。

事実は、Docker のドキュメントが「コンテナー」で理解していることであり、現実には準仮想化(「OS レベルの仮想化」の場合もある) であり、逆にハードウェアの仮想化であり、これは docker ではありません。

Docker は低品質の準仮想化ソリューションです。コンテナーと VM の区別は、Docker 開発によって考案されたものであり、製品の重大な欠点を説明しています。

普及した理由は、彼らが「一般の人々に火をつけた」からです。つまり、Win10 ワークステーション上で通常のサーバー (= Linux) 環境/ソフトウェア製品を簡単に使用できるようにしたからです。これは、私たちが彼らの小さな「ニュアンス」を許容する理由でもあります. しかし、それは私たちもそれを信じるべきだという意味ではありません。

Windows ホスト上の docker が HyperV に組み込まれた Linux を使用し、そのコンテナーがその中で実行されているという事実によって、状況はさらに不透明になります。したがって、Windows 上の docker は、ハードウェアと準仮想化ソリューションを組み合わせて使用​​します。

要するに、Docker コンテナーは低品質の (準) 仮想マシンであり、大きな利点と多くの欠点があります。

于 2020-11-26T15:53:35.600 に答える