「第4回 コンテナ型仮想化の情報交換会@東京」に参加してきました
「第4回 コンテナ型仮想化の情報交換会@東京」に参加してきました
第4回 コンテナ型仮想化の情報交換会@東京に参加してきました。
以下は勉強会のメモです。私の理解に間違い勘違いがあるかもしれませんのでご注意ください。
最新cgroup事情
- 発表者は@hiro_kamezawaさん
- 発表資料は以下のURLにて公開されています
私が遅れて到着してしまったため、最初の部分は聞き逃してしまいました……。
cgroup概要
(プロセス等の?)コントロールはタスク単位だが、リソースはタスク単位ではない。そのため、タスク単位でリソースを扱うのは正しいのか、という議論がある。
cgroupの自由度を高めた結果、カオスな状況になっている。そこでsane_behaviorオプションにより「制限を加えること」で正しい使い方を強制する。これはKernel3.19-3.20あたりでデフォルトで有効なオプションになるかも。
systemdの話
systemdは全てのcgroupを牛耳るというスタンス。systemdが有効なシステムでは、systemdでcgroupを作る。Unit file, DBUS APIで作る。libvirtのcgroupもsystemdを使うよう修正された。
Systemdに新たに加わったユニットタイプの一つにsliceがある。systemdの下には3つのsliceがあり、注意が必要なのはuser.sliceとsystem.slice。user.sliceの下にあるやつはsystemdが完全に掴んでいる。
systemd/src/shared/unit-name.h: 33 enum UnitType { 34 UNIT_SERVICE = 0, 35 UNIT_SOCKET, 36 UNIT_BUSNAME, 37 UNIT_TARGET, 38 UNIT_SNAPSHOT, 39 UNIT_DEVICE, 40 UNIT_MOUNT, 41 UNIT_AUTOMOUNT, 42 UNIT_SWAP, 43 UNIT_TIMER, 44 UNIT_PATH, 45 UNIT_SLICE, 46 UNIT_SCOPE, 47 _UNIT_TYPE_MAX, 48 _UNIT_TYPE_INVALID = -1 49 };
systemd/src/shared/path-lookup.h: 34 typedef enum SystemdRunningAs { 35 SYSTEMD_SYSTEM, 36 SYSTEMD_USER, 37 _SYSTEMD_RUNNING_AS_MAX, 38 _SYSTEMD_RUNNING_AS_INVALID = -1 39 } SystemdRunningAs;
systemdから設定できるパラメータは限定的。CPUパラメータに"Share"は設定可能だが"Limit"は設定不可。また、Memoryの上限を設定できてもSwapの設定はできない。現状では設定可能なパラメータを増やす予定は無い。これはLinux Kernel側のcgroupが再設計中であるため、それが一段落して安定してからAPIの追加が行われるためとのこと。
Memory cgroupの話
TCPバッファ量の設定機能は他のメモリ上限設定とは趣きが異なるが、これはNECのHPCのグループの要望によるものとのこと。メモリとスワップの上限設定があるのは、これらを制限すれば、グローバルなリソースを都度触らなくても管理できるよね、という考え方。また、swap上限の設定は、fork bomb等でswapを使いきってしまうのを防ぐ側面もある。
最近のcgroupの実装では、最初にメモリページを読んだ人に課金されている。が、Dockerの流行など考えると、ページキャッシュを占有しているとよかったね……という話も(最初にページを触った人に課金されてしまう)。
kernelメモリのアカウンティング
kernelメモリのアカウンティングは、以下の2つのケースで発生する。カーネルメモリ課金はfree()された時に減算。とはいえ、特定のmemory cgroup狙い撃ちでカーネルメモリを開放するルーチンは今のところ無い。
- SLAB/SLUBアロケータからページを割り当てた場合
- alloc_kmem_pages()を呼ぶ場合
TCP bufferのアカウンティング
TCP bufferのアカウンティング。元々システム全体でtcp bufferを制限するための仕組みがあり、これを流用している。Socketのdata用のメモリ領域をアロケートする所で判定する。
memory cgroupの面倒な所
タスクとメモリのライフサイクルが異なる場合がある。莫大な性能オーバーヘッドがあると信じられている。タスクに課金ではなくページメモリ課金なのでレースコンディションが多い。課金に関する点で見ると、ページメモリに大して課金する。race conditionを回避するためロックを使っていると性能に影響する
性能オーバーヘッドの改善方法のひとつとして、各CPU毎に課金の前借り情報を付与している。前借りなので、メモリのusageのカウント誤差を許容(memory cgroupは性能のためにカウント誤差を許容)する。cgroupの利用、BMと比較すると場合によっては3,4%性能が落ちる。メモリ解放処理はput_page()のバッチ処理の中で複数のページ文をまとめて開放する。LRUはmemory cgroup毎に持つ。システム全体のLRUは「存在しない」
今後の強化ポイント(予想)
- kernel memory cgroyupのメモり回収処理を追加
- Blkio cgroupと連動してのbufferd I/Oの制御
- Page付帯情報を16byteから8byteにする
- soft limitの再実装
- kswapd per memory cgroup
- 不揮発メモリの扱い?
- 今後の議論になってゆくと思う
質疑応答
- 質問. ドキュメントでcgroup,cgroupsの表記が揺らいでいる、理由は?
回答. OSSの悪い所。特に理由は無い。cgroupsと表記する人が多い感じ。
質問. cgroupのカーネルメモリも課金対象との話だが、これはプロセスに紐づいているもの?
- 回答. プロセスには紐づいていない。i-node等も課金される。プロセスがいなくなっても課金は継続される。基本的にはkmalloc()を(最初に)使っている人に課金される。例えば、ファイルを複数のグループで使っている場合、最初に使った人に課金される。
Using LXC on Production
- 発表者は@isaoshimizuさん
mixiのモンストスタジオに所属されている方で、「OpenStackとLXCを導入した話」を元にした発表でした。
mixiにおける仮想化環境
当初はKVM(Kernel-based Virtual Machine)だった。用途は開発・ステージング環境。構築は自作のシェルスクリプトでbridge I/F、Cobblerとの連系でホスト名の連番化やIPの重複防止、virt-install,Kickstartをやっていた。しかし、基本手作業で面倒であったとのこと。
次にOpenStackを使ってみた。用途は社内プロダクト向けのPaaS("Gizumo"という名称でたぶん水をかけると増える)。アプリサーバは独自のデプロイツールを利用。ミドルウェアの構成はChefでMySQL, Redis, Jenkins等を展開。後に個人の開発環境にも展開していった。シェルスクリプトでKVMを使っていた時期よりも楽になった。
現在の運用はLXCを利用しているとのこと。
LXC概要
KVMのようなハードウェアエミュレーション上で仮想マシンを動作させるのはなく、Kernelの機能を利用してプロセスやネットワーク、ユーザ空間を分離し、仮想的な環境を提供する。KVMのケースのようなCPU、ディスクI/O等のパフォーマンス劣化がほとんど発生しない。KVMと比べて起動が速い。
同時期にDockerの人気が出始めたようで、AUFSが気にななったり、Docker Registryが便利そうだったり、Goのポータビリティは素晴らしかったり。IPマスカレードはちょっと面倒くさい(DockerはIPマスカレード)。バージョンアップが激しい。コンテナにIPを個別に振って、仮想マシンのように扱いたい(macvlan使いたい)。taggedVLANの環境でも問題なく使いたい。ネットワーク周りの要件の兼ね合いでDockerは見送ったらしい。
独自ツールtrailerの開発
LXCにかぶせる形での独自ツール"trailer"を開発。Rubyで記述されている。現段階ではオープンソースではない。LXCのラッパーとして動作。mixi内での運用に必要な機能に絞って実装。IP,MACアドレスの採番。コンテナイメージのダウンロードと展開。起動中のコンテナからイメージを作成する。Trailerfileと呼ばれるコンテナ定義。 リポジトリサーバへのイメージアップロード。
LXC向けに用意してあるイメージ
- ベースイメージ
- Reverse Proxy(mod_proxy)
- Varnish
- Q4M(Job Queue)
- Application Server(mod_perl)
- Tokyo Tyrant
- memcached
これらを起動するとIPとMACが振られた状態で起動する。アプリケーションサーバはさらにアプリのデプロイが必要。
コンテナを作るときの注意点
スレッド、PID数の上限に注意。ファイルディスクリプタ数やTCP/IP周りのKernelパラメータも用途に応じて調整する。インスタンス側では設定できないKernelパラメータがあったりするので注意。
その他に気をつける点として、利用リソースの予測と見積りを行い、他のコンテナに悪影響を及ぼさないようにする。ディスク容量については(LXCでは)容量制限ができない。モニタリングデータのグラフ化は重要(=監視は重要)。trailerではコンテナ単体とCPUとメモリの利用量、ホスト側でのメモリ量を取得できるようにしている。
発表者によるtrailerのデモ。以下のような感じでtrailerコマンドを使用していました。
$ trailer image-list $ sudo trailer image-destroy fedora19 $ sudo trailer start --image fedora19-x86_64 --hostname container-test --dhcp --briged-interface eth0 Copying rootfs from fedora19-x86_64 ---done Starting container container-test
trailerコマンドからLXCでコンテナが起動します。アタッチしたコンテナからはCtrl-q Ctrl-aで抜けられるようです。
$ ps ax | grep container-test ...中略... lxc-start --name container-test --daemon --rcfile /data/lxc/container-test/config --lxcpath /data/lxc -o /data/lxc/container-test/log/lxc.log -l debug -p /data/lxc/container-test/container-test.pid -- /.trailerinit
trailerを利用して一つの物理マシン上にコンテナとしてサービスを集約。考え方として、複数のサービスを一つのマシンに集約するのではなく、mod_perl,memcached等のサービス毎に集約したコンテナを利用する。
質疑応答
- 質問. trailerからLXCへのアドレス付与はどう行っている?
回答. init起動した後にifconfig/ipコマンドを発行している。内部からIPを設定している。基本的には固定IPを(起動時に)動的に付与し、DHCPは使っていない。root fsの中にIPを記述した設定ファイルを置いておき、それを用いてIPを設定している。(補足:LXCの設定項目にIPアドレスの項目がある、とのこと)
質問. ディスクイメージ内のFSとして、ZFSとか使ってみたりしてますか?
回答. ディスクは気をつけていれば特に問題なく、こういったサービスでは不要かも。
質問. LXCシステムコンテナの元になるイメージ、trailerではどうやっていいますか?
回答. LXCに付属しているtemplatesを元にしてイメージ作成していますが、だいぶ変更しています。(補足:LXC 1.0でのtemplatesでだいぶ改善された)
質問. リソース監視は外から行うのですか?
回答. 外から取得している。snmpdを動かしている。コンテナ側の情報はextendと独自のスクリプトで取得している。
質問. アプリケーションコンテナの場合、ログインする(sshが必ず動いている?)
回答. sshdは全てのコンテナで立ち上げています。普通のマシンとして利用できることを想定したコンテナにしています。
質問. trailerの1ホスト上にコンテナはいくつくらい立ち上げている?
回答. 多くて6個か8個、少なくて2個。プロセスをたくさん立ち上げるやつはコンテナ数を少なくしている。
質問. LXC 0.9から1.0への以降は考えている?
回答. 考えている。lxc start以外のコマンドではうまく動かないものもあるので移行したい。が、今のところ移行の予定は無いです。
質問. プロダクション運用する際、コンテナ周りで困ったことは?
回答. スライドにもあったがPIDの問題(これは気づきやすい類の問題)。メモリ使用量は取れてもロードバランスは取りにくい等があり、監視・リソースのモニタリングは難しい。意外と大問題にはぶち当たっていない気はする。
質問. KVMからLXCに移行する際、セキュリティはどう考えた?
- 回答. 子の親殺しといった、(LXCの機能に起因する)セキュリティは意識していない。ホスティングサービスとは異なり、社内で利用するのであれば、あまり神経質になることは無いかもしれない。
LT資料 (第4回 コンテナ型仮想化の情報交換会@東京)
- 発表者は@tukiyo3さん
vagrantやLXC,Docker、OpenVZのproxmoxに関するTips集とDocker上でCentOS7のsystemctlを動作させる内容の発表でした。
個人的にはDockerでUbuntuを起動してみたことがあるだけで、Docker+CentOS 7でハマり所があるのは知りませんでした。
- 発表内容は以下で公開されています
vagrant 1.6.5(2014/9/6)でCentOS 7ゲストに対応された。/etc/yum.confのautoupdateを無効化しておくとよい。vagrantcloud(vagrant init chef/centos-7.0)を用いたvagrant shareは便利とのことです。
- boot2dockerでvagrant share使ってみた
Docker Hubはdockerhubにアカウントを作成後、"docker login", "docker push'するだけでお手軽に使い始められます、とのことです。ただ、ちょっと帯域が細く、apt-getとかが遅いようです。"docker search tukiyo3"で@tukiyo3さんのイメージが検索できます。
OpenVZのproxmoxについてはバックアップの方法が解説されており、proxmoxを使うとそのままホストOS、ゲストOS間で通信ができるため、定期的にバックアップが取れるとのことです。バックアップは一時的にOSをスリープさせているようだが、たまに復帰できない時があるという話が……。
他にもDockerのデータ永続化の方法として、cronで定期的にdocker commitを実行する方法が紹介されていました。
CoreOSによるDockerコンテナのクラスタリング
- 発表者は@yujiodさん
- PukiWikiの開発者さん(!)とのことです
- 発表スライドは以下で公開されています
- CoreOSによるDockerコンテナのクラスタリング
- http://www.slideshare.net/yujiod/coreosdocker
CoreOSはChorome OSベースのLinuxディストリビューション。単体で開発機として利用可能だが、クラスタリング構成で最も威力を発揮する。Google,Twitter,Mozilla,Suse,Cisco,Rackspace等のメンバーが開発に参加している。基本的に64bit CPUであれば動作する。IaaSではAmazon EC2,Google Compute Engine,Rackspace Cloudで動作、他にもさくらVPS,mac miniで動作する。
CoreOSの特徴
- 省メモリ
- 起動時で114MB(Dockerの動作のみに注力)
- 自動OSアップデート
- Docker専用OS
- ファイルシステムはread only
- アプリケーションはDockerで起動する必要がある
- クラスタリング機能が標準搭載
- ノードの自動構成
- コンテナのプロセス情報
- key-vlaueストア
- 分散デプロイ、フェイルオーバーの管理
- すべてGo言語で開発されている
- 自動フェイルオーバー
- 事前に「このロールのノードはn台」と定義しておく
CoreOSの構成要素
- locksmith
- OSアップデートのためのノードとupdate_engintプロセスの監視
- systemd
- コンテナを一つのUnitとして動作させられる
- 発表スライドの15枚目にsystemd unitの記述例があります
- X-Fleetというセクションが特別
- etcd
- fleet
- cloud-config
- クラスタ全体の構成管理を行う。YAMLで記述し、OSアップデートポリシーやプロセス、コンテナ管理(systemd)、他ファイルの書き込みやCoreOSのログイン(ssh)設定、hostsファイルの設定を行う
- (cloud-configの例→写真参照)
- 発表スライドの25,26枚目にデモ用のcloud-configの完全な例が提示されています。
CoreOS上のコンテナでの分散デプロイ、フェイルオーバーのデモ
以下のコマンドを投入し、CoreOS上での分散デプロイとフェイルオーバのデモがありました。
CoreOS$ # CoreOSにログインして以下を実行 CoreOS$ fleectl list-machine CoreOS$ fleectl list-unit CoreOS$ fleectl submit busybox\@{1,2}.service CoreOS$ fleectl start busybox@*.service
デモの補足として、クラスタを組む際にはフェイルオーバーを前提にすること。RDB/NoSQLのデータは外部ディスクに保存。ロードバランサーへの自動組込が必要との説明がありました。
- Dynamic Docker links with an ambassador powered by etcd
最近のCoreOS(2014/09-)に関する情報
CoreOS Managed Linuxという有償サポートも開始された。CoreUpdateというノード管理GUIが提供される。Premium Managed Linuxという上位プランにはプライベートDocker Hub Registryも提供される。
デバッグを目的としてFedoraの環境が利用できる。実態はCoreOSと同じ名前空間で起動するコンテナ。コンテナはDockerではなくsystemd-nspawnを利用しており、ファイルシステムは/media/rootにマウントされる。CoreOS自体の管理等にも利用できる。
質疑応答
- 質問. EFIな環境にインストールする方法が分からないです。ベアメタル環境にCoreOSをインストールされたとの話ですが、EFI環境へのインストールは試したことがありますか?
質問. Linuxコンテナ内のログをFluentd等で管理したい場合、どうしたら良いですか?
- 回答. Fluentdでの設定方法は未調査。Fluentdにこだわってログ管理しなくても良いかも。
コンテナ仮想化とはなんだったのか?
- 発表者は@m_birdさん
- 発表資料は以下のURLで公開されています
仮想化の概念を振り返りつつ、完全仮想化とコンテナ型仮想化(OSレベル仮想化)についての比較と共にFreeBSDのjail機能を説明するという内容での発表でした。
仮想化の概念の話として、PopekとGoldbergの仮想化要件の説明がありました。まず、仮想マシンモニタ(VMM)の要件として等価性(Equivalence)、資源の管理(Resource Control)、効率性(Efficiency)があり、仮想マシンモニタを構築に際し、CPU命令セットを以下の3つに分類します。
- 特権命令
- 特権センシティブ命令
- 動作センシティブ命令
ただし、これらは完全仮想化に関するものであり、コンテナ型仮想化の観点からこの要件と分類を比較する形で、仮想化「っぽい」要件とは何か、という説明がありました。いずれも「コンテナ型仮想化から見た場合」の話です。
- 等価性→コンテナに分けた環境は同じ振る舞いをするので、「コンテナ環境」が等価性を満たす要件といえる。
- 効率性→(後述)
- 資源管理→コンテナはホストOSが完全に掌握しているので、「ホストOS」が資源管理を満たす要件といえる。
効率性については、完全仮想化の場合「大部分の機械の命令をVMMの介在無く実行できると」(Wikipediaから引用)とありますが、コンテナ型仮想化の場合はユーザ空間のレベルでコンテナが作られるので、機械の命令云々の話はそもそも出てこない、というワケです。
それでも完全仮想化とコンテナ型仮想化のI/O性能の比較について言及があり、完全仮想化ではI/O性能低下の要因としてホストOSとゲストOS間でのコンテキストスイッチの増加、その改善方法としてvirtio等の準仮想化ドライバでコンテキストスイッチを減らす方法とPlan9由来のプロトコルを使用し、ホストOSのファイルシステムを直接読み書きするvirtfsの仕組みが紹介されていました。
完全仮想化におけるI/O性能低下のデータも提示されており、実機上のI/O性能を100%とした場合に、virtfsで99%、準仮想化ドライバで81%、IDEブロックデバイスエミュレーションで41%の性能になるという結果になっていました。
FreeBSD jail
FreeBSD jailについては、jail(2)システムコールから見た説明となっていました。コンテナ型仮想化ではホストOS(コンテナホスト)でリソースを制限をしており、FreeBSDでは4.2BSD以降に追加されたgetrlimit/setrlimitや/etc/login.confでリソース制限を行います(Linuxでは/etc/security/limits.confとのことです)。
jailの設定は/etc/jail.confで行います。jailはOS標準の仕組みで構成されている。jailシステムコール自体にはリソース制限は存在しないため、FreeBSD 9よりRACCTL(カーネル内の資源量把握), RCTL(資源の制限を行う)が利用できますが、GENERICカーネルでは提供されていない機能なのでカーネルの再構築が必要とのことです。
その他、FreeBSD jailの面白い機能として、jail環境でCentOSを動作させる方法が紹介されていました。
- Running CentOS 5.5 in a Jail
質疑応答
- 質問. 完成版の資料はいつかどこかで見られる(笑)?
回答. 予定は未定です(笑)
回答. 別のカーネルを動かして別のコンテナを動かすことは技術的には可能、Dragonfly BSDでそうったことをやっているはず。ただ、それはコンテナ型仮想化とは異なる別の概念の仮想化になるかと思う。(参加者からの補足→)カーネルレベルでは無理だが、エミュレーションレベルだとOKかも。例えば、FreeBSD 9の上でFreeBSD 8バイナリを動かすことは可能。
質問. jailってOS Xでも使える?
- 回答. カーネルが別物なので利用できないと思う。
Oracle Solaris Zones -Oracle Solarisのコンテナ技術-
- 発表者は@satokazさん
Oracle Solaris Zoneに関する発表でした。Oracle Solarisは「研究及び開発目的であれば無償利用可能」とのことです。
Solaris Zone
2003年代のOracle Solaris Zonesの開発目標としては以下のが挙げられていた(当時からリソースの制御も要件に含めていたようです)。「粒度」はリソースを分配可能にするという話で、「透過性」はコンテナに分離する際にアプリケーションの移植を必要としない(させない)というものです。
- セキュリティ(Security)
- 隔離(Isolation)
- 仮想化(Virtualization)
- 粒度(Granularity)
- 透過性(Transparency)
隔離(Isolation)のアプローチとしてchroot,FreeBSDのjail等があり、基本的にはjailの考え方に基づいて実装されたようです。
Oracle Solaris Zonesは単一のシステム上に複数の隔離されたSolarisインスタンスを提供する機能で、イメージとしてはjailやLXC,Docker等と同じです。ただし、Zonesは以下の2種類に分類されます。
- 大域ゾーン(global zone)
- → オペレーティングシステムの実体(ホストOS)
- 非大域ゾーン(non-global zone)
ネットワークについても以下の2種類に分類されます。
- 共有IPゾーン(shared IP zone)
- →デフォルトのネットワーク
- 排他的IPゾーン(shared IP zone)
- →非大域ゾーン専用の物理ネットワーク
これらのゾーン間でのアクセス可否は以下のようになっています。
アクセス元ゾーン | アクセス先ゾーン | アクセス可否 |
---|---|---|
大域ゾーン | 非大域ゾーン | 可能 |
非大域ゾーン | 大域ゾーン | 可能 |
非大域ゾーン | 非大域ゾーン | 不可 |
Oracle Solaris Zonesでのリソースは「資源プール」として管理されており、以下のリソースがあります。
- プロセッサセット(CPU)
- スケジューリングクラス
Solaris Kernel Zones
Oracle Solaris 11.2から提供されるゾーンとして、"Solaris Kernel Zones"があります。物理ホストには以下の高いスペックが要求されます。
- CPU
- メモリは最小8GB必要
- ZFS
- ZFS ARC(Adaptive Replacement Cache)の上限値を搭載物理メモリの半分程度におさえる
- これは重要なポイントで、これを忘れるとある日突然Kernel Zonesが起動しなくなる現象に見舞われるとのこと
Kernel Zonesの内部についても解説があり、kzhostプロセスとzvmmカーネルモジュールの説明がありました。kzhostプロセスはゲストOSに仮想CPUを利用させるためのもので、Kernel Zones毎に生成され、I/Oスレッドや各種管理、Zonesに割り当てられるメモリ管理を行います。zvmm(zone virtual machine monitor)カーネルモジュールは擬似ドライバでゲストOSに対して仮想ハードウェアとして振る舞います。
Oracle Solaris Zoneの参考情報として、以下が紹介されていました。
- Solaris Zones: Operating System Support for Consolidating Commercial Workloads
- Oracle Solaris 11.2 Information Library
- Introduction to Oracle Solaris Zones
- http://docs.oracle.com/cd/E36784_01/html/E36848/index.html
- 日本語版はもう少しで公開とのことです
質疑応答
- 質問. Zoneをいくら作ってもお値段同じですか?
回答. 残念ながら……「無料」です。(というワケで、リソースの許す限りZoneを作れます)
質問. トワイライトゾーンについて聞きたいです。
- 回答. ゾーン毎に作成される(ゾーンに紐づいている)。ネイティブゾーンにはトワイライトゾーンが存在しない。kzprocessが裏でちょっとしたゾーンを作っている。
ニフティのクラウドへの取り組み
- 発表者は@ysaotomeさん
- 発表資料は以下のURLにて公開されています
ニフティクラウド→エンタープライズ向けで時間貸しのクラウド、が、法人向けのクラウド。そこで、個人でも使えるサービスを始めた。「ニフティクラウド C4SA」。15日間は無料で利用できる。
コンテナを「キャンバス」という概念で示し、Webブラウザから操作する形。コントロールパネルにsshっぽい画面がある。リソースは内部からデータを取ってお客さんに見せている。cgroupsの機能はバリバリ利用している。
管理、権限、課金ノードについてはセキュリティの観点から互いを信用せず、相互に監視しつづけるアーキテクチャになっている(例えば課金ノードの情報が不正に書き換えられても他のノードはそれを検知できる、ということ?)。
LXC最新情報
- 発表者は@ten_forwardさん
- 発表資料は以下のURLで公開されています。
LXCの最新状況に関する発表でした。現在LXC 1.0.5がリリース(2014/07/14)がされており、LXC 1.0の新機能として、公式APIバインディング(Python2.7とPython3、lua,Go,ruby)、stableなliblxc1によるAPIの提供、非特権コンテナのサポートがあり、セキュリティに関しては、SELinuxとAppArmorをサポートし、seccompによるコンテナ毎のケーパビリティ指定が可能とのことです。
cgmanager(1)というコマンドが追加されており、DBusメッセージを送ることでcgroupを管理できるようです。
そしてこの度LXC日本語サイト作りました、とのこと。URLは以下です。
- LXC Linux Containers
まとめ
第4回 コンテナ型仮想化の情報交換会@東京に参加し、勉強会メモをまとめてみました。6時間近く開催された内容をまとめるのは大変でしたが、放っておくと頭から内容が揮発して行くので忘れない内に文章にしておくのが良さそうです。