Dockerはlxc-tools（ユーザースペースのLXCツール）に何を追加しますか？
Dockerの機能を見れば、それらのほとんどはすでにLXCによって提供されています。
Dockerは何を追加しますか？普通のLXCよりもDockerを使うのはなぜですか？
Dockerはlxcの代わりにはなりません。 "lxc"はLinuxカーネルの機能（具体的には名前空間と制御グループ）のことで、プロセスを互いにサンドボックス化し、それらのリソース割り当てを制御することを可能にします。
カーネル機能のこの低レベルの基盤の上に、Dockerはいくつかの強力な機能を備えた高レベルのツールを提供します。
マシン間でのポータブルな配置。 Dockerは、アプリケーションとそのすべての依存関係を、あらゆるdocker対応マシンに転送し、そこで実行される実行環境が同じになることを保証してそこで実行できる単一のオブジェクトにまとめるためのフォーマットを定義します。 Lxcはプロセスサンドボックス化を実装しています。これは移植可能な配置のための重要な前提条件ですが、それだけでは移植可能な配置には十分ではありません。カスタムlxc設定でインストールしたアプリケーションのコピーを私に送った場合、それはあなたのマシンの特定の設定（ネットワーク、ストレージ、ロギング、ディストリビューション、 Dockerはこれらのマシン固有の設定の抽象化を定義しているので、まったく同じdockerコンテナをさまざまな構成でさまざまなマシン上で（変更せずに）実行できます。
アプリケーション中心。 Dockerは、マシンとは対照的に、 applications の展開用に最適化されています。これは、そのAPI、ユーザーインターフェース、設計理念、およびドキュメントに反映されています。それとは対照的に、lxcヘルパースクリプトは軽量マシンとしてのコンテナに焦点を当てています - 基本的にはより速く起動し、より少ないramを必要とするサーバです。コンテナーにはそれだけではないと思います。
自動ビルド 。 Dockerには、開発者がソースコードから自動的にコンテナを組み立てるためのツールが含まれています。アプリケーションの依存関係、ビルドツール、パッケージングなどを完全に制御できます。make、maven、chef、puppet、salt、debianパッケージ、rpm、source tarball、または上記の任意の組み合わせ、 マシンの構成に関係なく 。
バージョニング。 Dockerには、コンテナの連続したバージョンの追跡、バージョン間の差分の確認、新しいバージョンのコミット、ロールバックなどのためのgit風の機能が含まれています。また、履歴には how が含まれています。そのため、本番サーバーから上流の開発者に至るまで、完全なトレーサビリティが得られます。 Dockerは "git pull"に似た増分アップロードとダウンロードも実装しているので、差分を送るだけで新しいバージョンのコンテナを転送することができます。
コンポーネントの再利用 任意のコンテナをより基本的なコンポーネントを作成するための「ベースイメージ」として使用できます。これは手動でまたは自動ビルドの一部として行うことができます。たとえば、理想的なPython環境を準備し、それを10種類のアプリケーションのベースとして使用できます。あなたの理想的なpostgresql設定は将来のすべてのプロジェクトに再利用できます。等々。
共有しています。 Dockerは、何千人もの人々が便利なコンテナをアップロードした公開レジストリ（ https://registry.hub.docker.com/ ）にアクセスできます。 ：redis、couchdb、様々なディストリビューションのためのベース画像を用意するためのRailsアプリケーションサーバーへのIRCバウンサーからpostgresまで。このレジストリには、dockerチームによって管理されている便利なコンテナの公式「標準ライブラリ」も含まれています。レジストリ自体はオープンソースであるため、たとえば内部サーバーへの展開など、誰でも独自のレジストリを展開してプライベートコンテナを格納および転送できます。
ツールエコシステム。 Dockerは、コンテナーの作成とデプロイを自動化およびカスタマイズするためのAPIを定義します。その機能を拡張するためにdockerと統合するツールは非常に多数あります。 PaaSライクな展開（Dokku、Deis、Flynn）、マルチノードオーケストレーション（maestro、salt、mesos、openstack nova）、管理ダッシュボード（docker-ui、openstack horizon、造船所）、構成管理（chef、puppet）、継続的統合（jenkins、strider、travis）などDockerは、コンテナベースのツーリングの標準として急速に地位を確立しています。
これが役に立つことを願っています！
Dockerの技術的な機能の リスト を見て、LXCが提供している機能とそうでない機能を確認しましょう。
特徴：
1）ファイルシステム分離：各プロセスコンテナは完全に独立したルートファイルシステムで実行されます。
普通のLXCで提供されています。
2）リソース分離：CPUやメモリなどのシステムリソースは、cgroupを使用して、各プロセスコンテナに別々に割り当てることができます。
普通のLXCで提供されています。
3）ネットワーク分離：各プロセスコンテナは、独自の仮想インタフェースとIPアドレスを持つ独自のネットワークネームスペースで実行されます。
普通のLXCで提供されています。
4）コピーオンライト：ルートファイルシステムは、コピーオンライトを使用して作成されます。これにより、展開が非常に高速になり、メモリが節約され、ディスクが節約されます。
これは、Dockerが依存している共用ファイルシステムであるAUFSによって提供されます。 LXCを使用してAUFSを手動で設定することもできますが、Dockerはそれを標準として使用します。
5）ロギング：各プロセスコンテナの標準ストリーム（stdout/stderr/stdin）が収集され、リアルタイムまたはバッチ検索のために記録されます。
Dockerがこれを提供します。
6）変更管理：コンテナのファイルシステムへの変更は新しいイメージにコミットされ、さらにコンテナを作成するために再利用されます。テンプレートや手動設定は不要です。
「テンプレート化または手動設定」はLXCへの参照です。ここでは、これらの両方について学ぶ必要があります。 Dockerを使用すると、LXC構成について学習することなく、仮想マシンの処理に慣れている方法でコンテナを処理できます。
7）対話型シェル：dockerは疑似端末を割り当てて、たとえば使い捨ての対話型シェルを実行するために任意のコンテナの標準入力にアタッチすることができます。
LXCはすでにこれを提供しています。
私はLXCとDockerについて学び始めたばかりなので、訂正やより良い答えを歓迎します。
上記の投稿と回答は、 LXDがLXCを強化し続けています の開発に伴い、急速に古くなっています。はい、Dockerもまだ立ち上がっていません。
LXDは現在、LXCコンテナイメージのリポジトリを実装しており、ユーザーはそこからプッシュ/プルして貢献したり再利用したりできます。
LXDのREST api toLXCは、非常に単純なコマンド構文を使用して、LXCコンテナーのローカルおよびリモート作成/展開/管理の両方を有効にします。
LXDの主な機能は次のとおりです。
- 安全な設計（非特権コンテナ、リソース制限など）
- スケーラブル（ラップトップのコンテナーから数千の計算ノードまで）
- 直感的（シンプルで明確なAPIおよび鮮明なコマンドラインエクスペリエンス）
- 画像ベース（配布テンプレートは不要、信頼できる適切な画像のみ）ライブ移行
OpenStackでOpenStackを許可するNCLXDプラグイン は、KVMやvmwareなどを使用する代わりに、LXDを使用してLXCコンテナーをOpenStackのVMとしてデプロイ/管理します。
ただし、NCLXDでは、従来のHW VMとLXC VMが混在したハイブリッドクラウドも可能になります。
OpenStack nclxdプラグインには、サポートされている機能のリストが含まれます。
stop/start/reboot/terminate container
Attach/detach network interface
Create container snapshot
Rescue/unrescue instance container
Pause/unpause/suspend/resume container
OVS/bridge networking
instance migration
firewall support
2016年4月にUbuntu 16.04がリリースされるまでに、ブロックデバイスのサポート、ライブマイグレーションのサポートなどのクールな機能が追加されます。
Dockerはレイヤーで構築された画像を使います。これにより、移植性、共有、バージョン管理、およびその他の機能に関して多くのことが追加されます。これらのイメージは移植や転送が非常に簡単です。また、それらはレイヤー内にあるため、後続のバージョンでの変更は前のレイヤーの上にレイヤーの形で追加されます。そのため、何度も移植しながら、ベースレイヤを移植する必要はありません。 Dockerには実行環境を含めてこれらのイメージを実行するコンテナーがあり、それらは新しいレイヤーとして変更を加え、バージョン管理を容易にします。
それとは別に、Docker Hubは何千ものパブリックイメージを持つ優れたレジストリで、そこにはOSや他のソフトウェアがインストールされたイメージがあります。それで、あなたはあなたのアプリケーションのためにかなり良い先行きを得ることができます。
この忠実さを保とうとしている、これはすでに尋ねられ、答えられています。
しかし、私は後退して、少し違った答えをしたいと思います。Dockerエンジン自体がオーケストレーションをその追加機能の1つとして追加していますが、これは破壊的な部分です。複数のコンテナエンジンで「どこかで」実行されているコンテナの組み合わせとしてアプリの実行を開始すると、とてもエキサイティングになります。堅牢性、水平スケーリング、基礎となるハードウェアからの完全な抽象化、私は何度も続けることができます...
これを実現するDockerだけでなく、事実上のContainer Orchestration標準は、Dockerの1つだけでなく、OpenShift、SuSe、Azure、AWSなど、さまざまな種類のKubernetesです。
それからK8Sの下に代替コンテナエンジンがあります。興味深いものはDockerとCRIOです - 最近構築された、デーモンのない、特にKubernetesのためのコンテナエンジンとして意図されていますが、未熟です。これらの間の競争は、私がコンテナエンジンの本当の長期的な選択になると思います。