インターネットでLXCを称賛し、この技術には未来があると主張する記事が複数あります。 現在の状況を調査するために座っているのは3回目で、多くのニュアンスを見つけるたびに。 最初の試みは約1年半か2年前、2番目はDebian 7のリリース後、3番目は今週末でした。 その理由は、私はDebian / UbuntuがCentOS / RHELよりも桁違いに好きだからです。 しかし、残念なことに、Debain / Ubuntuでのコンテナ仮想化（特にOpenVZ）に関しては、最近のリリースではかなり悲しくなりました。 LXCのより積極的なプロモーションによるものを含む。 実際、LXCはLXCなので、必要な問題を解決するためだけです。 私はホスティング会社ではありません。そのような仮想化は、主に開発、テスト、および自分のプロジェクトのいくつかの作業のために使用しています。
将来を考えると、3回目の試みが再び失敗したと言えます。 LXCは、商業的利用は言うまでもなく、家庭で使用する場合でも依然として非常に生々しく見えます。 その理由は次のとおりです。
実験ウサギ
近い将来、LXC 1.0のリリースが約束されています。 さらに、4月には、次のUbuntu LTSがリリースされます-4月14日（長期サポート付き）。 Debian 7、Ubuntu 12.04、Ubuntu 13.10を装備して、進捗状況と現在の状況を確認しに行きました。 場所はOpenVZとの比較になります。 これは、実験のために、サーバーの1つをLXCコンテナーのOpenVZコンテナーに置き換えようとしたかったためです。
Debian 7
LXCバージョンは0.8.0-rc1です。
前回から覚えている最も印象的な瞬間は、Debian 7のLXCでDebian 7コンテナテンプレートがそのままでは機能しなかったことです。商業開発では、この種の問題は通常ショーストッパーと見なされます。 3回目の更新にもかかわらず、物事はまだあります。 / usr / share / lxc / templates /を見て、他のテンプレートを試してみると、fedoraにはyumがなく、opensuseにはzypperがなく、ubuntu-cloudはubuntu-cloudimg-queryを望んでおり、altlinuxを試してみると喜んで報告していますALTLinuxホストがないこと。 実際、同じDebian 7テンプレートに対して、修復されたものを検索してダウンロードするか、自分で修復することをお勧めします。 OpenVZの場合、サイトには公式および非公式のテンプレートを含むリポジトリがあり、これは非常に便利です。 Vagrantにはwww.vagrantbox.esがありますが、DropboxとGoogleドライブへのリンクが怖いです。 誠実さを期待できますが、組み込みの軸を簡単に取得できます。 現時点でのLXCの場合、ディストリビューションにあるもの、またはインターネットを精査する（Vagrantの場合よりもさらに少ない）。
Ubuntu 12.04
LXCバージョン-0.7.5
明らかな理由により、バージョンは古いです。 しかし、Ubuntuを含むコンテナは問題なく作成されます。
バックアップ/復元を使用しようとします。 バックアップは、rootfsの内容を/var/lib/lxc/ct-name/rootfs.backup1にコピーすることで作成されます。結局、アーカイブを作成するのが慣習であり、それをただのバカなディレクトリにコピーするだけではないようです。 バックアップを別のホストにコピーすることにした場合、自分でアーカイブを作成する必要があります。 LXCおよびバックアップ/復元に関するUbuntu Webサイトで、この機能を使用しないという推奨事項を読むことができます。 意外と。
私が興味を持ったもう1つのポイントは、少なくともオフラインでのコンテナの移行です。 実際、仮想マシンの便利な利点の1つは、物理サーバー間で簡単に移行できることです。 残念ながら、この点でLXCではヘルプは表示されません-自分で実行してください。
Ubuntu 13.10
LXCバージョン-1.0.0.alpha1
最初に目を引くのは、lxc-checkconfigの出力に問題があることを示しています。 特に、特定の「ユーザー名前空間：欠落」。 テクノロジーの内部から遠く離れている人にとっては、これは第一に疑わしく見え、第二に「このために機能しないもの」とは実質的に言いません。 さらに、12.04では、すべての点で問題はありませんでした。
さらに調べてみると、Ubuntuを含むコンテナが作成されています（そのようなことにすでに満足しています:)）lxc-listの代わりに、lxc-lsを使用するように指示されます。 1.0までのAPIが安定することは約束されていなかったことは明らかですが、それでも疑わしい革新のように見えます。
バックアップ/復元はどうですか？ 何らかの理由でユーティリティlxc-backup / lxc-restoreが見つかりません。 これは私のインストールの詳細です（しかし何ですか？）、または彼らは本当にそれらを捨てることに決めました-質問は未解決のままです。 接頭辞lxc-およびlxc-checkpointが付いたコマンドのリストを再度確認します。 これを使用して、「チェックポイント関数が実装されていない」ようにします。 悲しいです
メイントピック-コンテナの使用に戻ります。 その起動はlxc-startコマンドによって実行されます。 このコマンドを実行した後、コンテナコンソールでデフォルトの動作のかなり奇妙な選択を見つけます。 これを回避するには、-dスイッチを渡すことを忘れないでください。 2番目のポイントは、コンソールからの適切な終了です。 ドキュメントではCtrl + aqメソッドについて説明していますが、機能しません（明らかに私だけではありません）。
次の瞬間-入力後、メモリとディスク容量がホストシステムの値と一致することがわかります。 従来のdfと無料の助けを借りてそれを見てください。 直感的に、lxc-createコマンド（vzctlとの類推による）に、コンテナーのメモリー量とディスク容量の設定に役立つパラメーターを表示させたいのですが、そのようなパラメーターは表示されません。 この瞬間は私にとって非常に重要なので、私はそれを理解しようとしています。 LXCでの最後の研究以来、この点に関して実質的に何も変わっていません。 カーネル内のサブツリーにクォータを設定する方法はなく、通常のヒントから、コンテナのFSとしてLVMボリュームを使用することをお勧めします。 この方法は明らかに便利でも単純でもありません。 コンテナ構成に特定のディレクティブlxc.cgroup.memory.limit_in_bytesを書き込むことで、何らかの形式のメモリ制限を設定できます。 このメソッドはユーザーフレンドリーとは言えませんが、問題はそれでもありません。 第一に、すべてのメモリが制限されるわけではありません。第二に、free -mのコンテナでは、ホストシステムの制限が表示されます。 はい、新しい制限が実際に表示され、特定のプロセスがそれを超えると、OOMキラーがそれを打ち負かします。 しかし、一見すると、このようなコンテナでmongoを起動すべきではないようです。 そして、いずれにしても、このアプローチは実用的ではありません。 仮想マシンを自由に利用でき、仮想化の種類について誰も話していないと想像してください。 従来の方法で使用可能なメモリの量を確認すると、十分なメモリがあるはずなのに、特定のプロセスが停止する理由に非常に驚かされます。
結論
これは非常に表面的な研究ですが、もう一度自分で判断するのに十分です-LXCはまだ成長する必要があります。 実際のコンテナ仮想化の代わりに、少し高度なchrootを取り入れようとしているように感じます。 LXCサポートはカーネル内にあり、それを使用するためのユーティリティを提供するのに十分であるという事実にもかかわらず、これはまだ十分ではありません。 もちろん、いくつかのタスクに適用することができます。たとえば、同じDockerを実行しようとしています。 しかし、明らかに、ここで短所として言及した瞬間が完了するまで、大規模な使用を期待する価値はありません。 「95％準備完了」の場合がこれに該当します。まだ準備ができていません。
PSこのトピックに興味がある場合は、プレゼンテーションをご覧ください-www.slideshare.net/kolyshkin/seven-problems-of-linux-containers