自己紹介

今日の目標

  • Linux のコンテナ関連の開発は活発です．しかしまとまった情報がないのが現状です
  • 最近の Linux のコンテナに関する動向をまとめてみましたので発表します
  • が，最新情報は，個人でまとめられるものではなさそうです (^_^;)
  • なので今日のこの資料は不完全です
  • 出席者からのツッコミで資料を本当の最新情報にするのが本当の目標です
  • LXC の使い方，みたいな話はあまり入ってません
  • カーネルも LXC も私は外から見てるだけなので間違いや抜けも多いかと思います

Agenda

  • コンテナの概要
  • イマドキの環境での LXC
  • Kernel 最新情報
    • Namespace
    • Cgroups
    • その他
  • LXC 最新情報
  • その他

コンテナの概要

コンテナとは

  • OS レベルの仮想化

  • プロセスをグループ化して他のグループと隔離

  • グループ化したプロセスに対するリソース制限

  • カーネルの持つ上記機能を使って仮想化を実現

VM vs CT

コンテナの特徴

  • 一つの OS (カーネル) のみが動作している
    • → 高密度
  • ハードウェアの仮想化が不要
    • → オーバーヘッドが小さい
  • 異なる OS のシステム / プログラムは動かせない
  • 起動が早い
  • 仮想マシンの上でも問題なく動くぜ!w

Linux におけるコンテナ実装

  • OpenVZ / Virtuozzo(商用)

  • Linux VServer

  • カーネルがコンテナ向けの機能を持たないため，膨大なパッチを適用し，コンテナ仮想化を実現していた

  • しかし，Linux 2.6.19 辺りから徐々に実装され始め，ようやく最近になって実用的になってきた
  • OpenVZ/Parallels をはじめとして IBM, Oracle, Google 等，色々な所で実装に関わっていたエンジニアが開発に参加

LXC

Linux カーネルの持つ機能のみを使ってコンテナを実現するツールとして

  • LXC (http://lxc.sourceforge.net/)
    • Linux でコンテナを操作する userspace ツール (コマンド群)

  • libvirt (のLXCコンテナドライバ) (http://libvirt.org/)

  • どちらも同じ "LXC" という名前を使っているが，設定ファイルは別々．機能も微妙に違っていた

    • 最近は?

  • あと systemd でも軽量コンテナが作れるらしい (良く知らない)

イマドキの環境での LXC

主要ディストリビューションでの LXC 簡単起動

Ubuntu

  • 現在の LXC の事実上の開発プラットフォーム
    • Ubuntu で開発された後，他のディストリビューションで動くように調整されている感じ
  • 現在の主要開発者は Ubuntu デベロッパー
  • Ubuntu パッケージは LXC の新機能がバックポート
    • というより，先に Ubuntu で実装された機能を本家にマージしてる感
  • LXC / libvirt 共に問題なく動く (はず)
    • 最近 libvirt の lxc ドライバ使ってないので...
  • precise(12.04LTS) 以降の完成度が高い
    • apparmor で危険な動きはできなくなっている．新機能の先取り．
    • precise は 0.7.5 だが 0.8.0 の機能がかなり入っている

Ubuntu で LXC が動くまで

# apt-get install lxc
# lxc-create -n ct01 -t ubuntu
# lxc-start -n ct01 -d
# lxc-console -n ct01
  • lxc パッケージをインストールするだけ．cgroup のマウント用コマンド等，関連のものもインストールされる
  • 起動スクリプトも lxc が動くように調整されている (Upstart の init 等)
  • AppArmor も調整済み

CentOS

  • 標準パッケージに LXC はない．epel 他，非標準リポジトリにも lxc パッケージはなし
  • Wiki を見ると libvirt を使った方法が紹介 → HOWTO: Configure a LXC Linux Container CentOS 6
    • CentOS (RHEL) では libvirt が今後標準?
    • 上記手順だけでは起動しませんでした
  • 標準にはテンプレート (lxc-centos) が含まれない．github/gist を探ればあります → lxc-centos
  • kernel が 2.6.32 なのでかなり古い
    • 実装が古い
      • NS Cgroup (namespace サブシステム) というものが存在 (cgroup の clone_children と階層構造で置き換え)
  • ソースからコンパイルすればとりあえず動く
    • ただし，最新の 0.9.0 は動きが怪しい (気がする)
    • 実装が不十分な net_prio, perf_event 辺りはマウントしないのが無難

Debian

  • Debian 7.0 では lxc パッケージあり (0.8.0-rc1)
  • テンプレートも存在 (lxc-debian)
    • lxc-debian でコンテナ作成すると，必要事項を質問して来てくれる親切さ
  • 惜しいことにパッケージの lxc-debian テンプレートは細かいところの完成度がイマイチ (な気がする)
    • コンテナ内の /etc/inittab をソース同梱のテンプレート的に修正するとコンソールは OK
    • openssh-server の鍵も config で消去してるけど Why?
  • lxc ソース同梱の lxc-debian 使うとあっさり起動 (6.0 コンテナですが)
  • カーネルはなぜか Memory Cgroup が有効でビルドされているのに普通に起動するとデフォルトで無効になっている
    • カーネル起動オプションで "enable_cgroup=memory" を与える (ようにするパッチが当たってる/6.0, 7.0)

Debian で lxc が動くまで

  • cgroupfs マウント
# apt-get install lxc
# lxc-create -n ct01 -t debian
  : (色々質問に答える)
# vi /var/lib/lxc/ct01/config
  (ネットワーク関係の設定の追加)
# lxc-start -n ct01
  (debian 標準テンプレートそのままだと起動処理途中でだんまり ><)

コンテナ内の inittab の getty 付近はこんな感じに

1:2345:respawn:/sbin/getty 38400 console
c1:12345:respawn:/sbin/getty 38400 tty1 linux
c2:12345:respawn:/sbin/getty 38400 tty2 linux
c3:12345:respawn:/sbin/getty 38400 tty3 linux
c4:12345:respawn:/sbin/getty 38400 tty4 linux

Fedora

[root@localhost ~]# lxc-start -n ct01 -d -o log -l DEBUG
[root@localhost ~]# lxc-info -n ct01
state:   STOPPED
lxc-info: 'ct01' is not running
pid:        -1

起動しない (^_^;)

  • Fedora 18 には lxc, lxc-libs, lxc-templates パッケージが存在．
    • しかしそのままでは 0.7.5
    • しかもテンプレートには lxc-sshd のみ
  • "update-testing" リポジトリから 0.8.0 を入れてみる
    • テンプレートがバグってて，きちんとコンテナツリーが作成されません :p
  • Fedora Wiki の Features/Securecontainers を見ると virt-sandbox-service コマンドでアプリケーションコンテナを作成する方法が書かれている (試してません)

Plamo

  • まだ開発されている :-p 日本発のディストリビューション
  • contrib ながら，lxc パッケージが存在し，マメに更新されている (現在 0.9.0)
    • 私がパッケージメンテナですからw
    • ただし，カーネルパッケージのメンテナではないので時々必要な機能が落ちる事も ^^;
      • Plamo 5.1 付属 3.9.3 カーネルは Memory Cgroup がオフに
    • Plamo はインストール後，カーネル再構築が基本です．なので気にしない :p
    • 最新パッケージは 0.9.0 だが python3 が Plamo にないので python API や一部コマンドは入らず
  • plamo テンプレートも存在
  • contrib/Virtualization 以下のパッケージを全部入れれば簡単に Plamo コンテナが起動可能．
    • 実は lxc, dnsmasq パッケージがあれば OK です．

Plamo で lxc が動くまで

# installpkg /path/to/contrib/Virtulization/*.txz
# cd /etc/rc.d/init.d ; chmod 755 lxc-net cgroups-mount
# /etc/rc.d/init.d/lxc-net
# /etc/rc.d/init.d/cgroups-mount
# lxc-create -n ct01 -t plamo
# lxc-start -n ct01 -d
# lxc-console -n ct01
  • lxcbr0 というブリッジを作成し，veth で lxcbr0 にアタッチするようになっている (Ubuntu のパクリ)
  • dnsmasq を使い DHCP でアドレスが割当たるようにしてある

Kernel 最新情報

Linux Kernel のコンテナ関連機能の更新を追う

コンテナを実現するための機能

  • プロセスをグループ化して他のグループと隔離
    • → Namespace (名前空間)
  • グループ化したプロセスに対するリソース制限
    • → Cgroups

Namespace

Namespace

比較的古くから実装されている．lxc.sourceforge.net によると

  • utsname: 2.6.19
  • pid: 2.6.24
  • ipc: 2.6.19
  • user: 2.6.23
  • network: 2.6.26

ただし，user に関しては，確かに実装はされていてカーネルの config でも USER_NS は出てくるが，この頃実装されていた機能がどのようなものでどう使われていたのか不明．(後述)

Namespace の操作

こんなところにも Namespace

  • LinuxSUIDSandbox (chromium)
    • pid, network namespace
  • Network Namespace は ip コマンド (iproute2) で簡単に作れます
  • util-linux に nsenter, unshare コマンド (nsenter は 2.23 で追加なのでディストリビューションには含まれないかも?)

Namespace 機能の変遷 〜 setns(2) (kernel 3.0)

  • clone(), unshare() で新しい Namespace を作成することは可能だが，その Namespace は新しく起動したプロセスとその子孫からしか見えない．
  • そこで外部から Namespace にアクセスする機能が 3.0 から追加 → setns() と Namespace を参照する手段 (ファイルディスクリプタ)
    • 3.0 では net, uts, ipc の Namespace のみ

man 2 setns によると

       int setns(int fd, int nstype);

ファイルディスクリプタを渡すようになっている．

  • このファイルディスクリプタは /proc/[pid]/ns 以下の Namespace を参照する特殊なファイルディスクリプタ
  • ちなみに glibc では 2.14 以降使用可能
  • Namespace file descriptors (lwn.net)

Namespace 機能の変遷 〜 User Namespace (kernel 3.8)

  • LXC での FAQ 『lxc のセキュリティは?』に対する回答．
  • これまではコンテナの root はホストの root と同じ権限を持っていたので，コンテナからホストを落としたりできた．
  • Ubuntu は 12.04 から AppArmor でホストのセキュリティを確保していたが，根本解決は『User Namespace の実装』となっていた長年の懸案事項

Namespace 機能の変遷 〜 User Namespace (kernel 3.8)

  • これまでカーネル内でのユーザ・グループに関わるチェックには uid/gid が使われていた
  • カーネル内のチェックのために専用の uid/gid が新設
typedef struct {
    uid_t val;
} kuid_t;

typedef struct {
    gid_t val;
} kgid_t;

Namespace 機能の変遷 〜 User Namespace (kernel 3.8)

  • Namespace 内の uid/gid とカーネル内 uid/gid をマッピングする
    • /proc/[pid]/uid_map, /proc/[pid]/gid_map
         0     100000      10000

        Namespace内のID   kernel内のID  範囲
  • 例えば，上記が uid_map とすると，Namespace 内で uid=0〜10000 までのユーザが，元の Namespace (kernel uid/gid) では uid=100000〜110000 にマッピングされる
  • Namespace 内で 10000 以上の uid を作成すると kernel uid/gid としては /proc/sys/kernel/overflowuid，/proc/sys/kernel/overflowgid の値となる
  • これで Namespace (コンテナ) 内のユーザがホストに対して危険な事ができなくなる

Namespace 機能の変遷 〜 User Namespace (kernel 3.9)

  • 3.8 でコンプリート! との事で期待していた User Namespace だが，kernel uid/gid による実装が各種ファイルシステムを中心に未実装で，かなりの機能をオフにした config でないと CONFIG_USER_NS 自体有効にできなかった
    • → テスト目的以外使えない
  • 3.9 で XFS 以外のファイルシステムでは実装が済んだ
    • とりあえず手元では XFS は『さよなら〜』とご退場願って USER_NS を有効に :-)
    • しかし，各ディストリビューションのカーネルでは XFS をオフにするわけにはいかないので，もうしばらくこの機能が普通につかえるのは先かも

Namespace 機能の変遷 〜 User Namespace (kernel 3.8)

Namespace 機能の変遷 〜 setns(2) (kernel 3.8)

  • User Namespace と一緒にマージされた重要機能!! (最初気づかなかった)
  • pid, mount, user Namespace のファイルディスクリプタが /proc/[pid]/ns 以下に
    • これまで pid, mount Namespace に setns できなかった
      • コンテナ外部からコンテナ内部のコマンドの実行ができなかった
        • lxc-attach コマンド (OpenVZ の vzctl exec 的なコマンド) が動かなかった
      • 管理的にかなり不便であった
  • User Namespace 以上に重要!?
    • setns がどの Namespace に対しても出来るようになり，コンテナ外部からコンテナ内部のコマンドを実行できるようになった

Namespace 機能の変遷 〜 setns(2) (kernel 3.8)

3.7 以前の /proc/[pid]/ns 以下

-r-------- 1 root root 0 Mar  1 15:41 ipc
-r-------- 1 root root 0 Mar  1 15:41 net
-r-------- 1 root root 0 Mar  1 15:41 uts

3.8 以降の /proc/[pid]/ns 以下

lrwxrwxrwx 1 root root 0  3月  1日  14:59 ipc -> ipc:[4026532301]
lrwxrwxrwx 1 root root 0  3月  1日  15:06 mnt -> mnt:[4026532299]
lrwxrwxrwx 1 root root 0  3月  1日  15:06 net -> net:[4026532304]
lrwxrwxrwx 1 root root 0  3月  1日  15:06 pid -> pid:[4026532302]
lrwxrwxrwx 1 root root 0  3月  1日  15:06 uts -> uts:[4026532300]
  • /proc/[pid]/ns 以下のファイルが特殊なシンボリックリンクとなった
  • 同じ名前空間に属している場合は，同じ inode を指すようになった
    • stat() で簡単に同じ名前空間に属しているかどうか確認可能

Namespace 機能の変遷 〜 その他

  • NFS のコードが Network Namespace 対応 (Linux 3.9) (未確認)
  • 他に何か気になる更新は?

Namespace 〜 未実装の機能

  • コンテナの quota を mount namespace の機能として実装 (未確認)
    • コンテナの quota も繰り返し出てくる話題
    • container disk quota
    • 2012 年 5 月のメールだが，その後どうなったかは未確認

Namespace 〜 未実装の機能

Cgroups

Cgroups

グループ化したプロセスに対してリソース制御を行う機構．

  • 2006 年 9 月に Google のエンジニアにより Containers というパッチが投稿される
  • 2.6.24 (2008 年) で Control Groups マージ (Task Control Groups)
  • 2.6.25 で Memory Resource Controller
  • 2.6.26 で Device controller (Device whitelist)
  • 2.6.28 で Freezer controller
  • 2.6.29 で Control Group Classifier (Network)
  • 2.6.33 で Block I/O controller
  • 2.6.37 で Block I/O controller I/O throttling (linux 2.6.37 の新機能 "I/O throttling" (2))

Cgroups

RHEL 6.0 で Cgroups サポートが入り，専用マニュアル(リソース管理ガイド)もあるので一躍メジャーに!!

  • 勉強会でも結構このネタがあったような
    • 私が最初に Cgroup をいじりだしたのが RHEL6 前夜という感じの時期 (2010 年 2 月頃に勉強会で LT してる)
  • hbstudy#19 での RedHat の平さんの資料 なんかはかなりじっくり目を通した覚え
  • この頃はとりあえずお気軽に試せた．結果もわかりやすいものが多かったので楽しい時期
  • この後も Cgroup はどんどん機能追加と改良が進んでいます．その辺りを以降で

Cgroups の変遷 〜 cgroupfs のマウントポイント

  • ご存知の通り cgroup 用のファイルシステムはどこにマウントしても OK
  • 太古の昔: /cgroup とか
  • 昔?: /dev/cgroup とか
  • イマドキ: /sys/fs/cgroup

Cgroups の変遷 〜 Kernel 3.0

  • ns_cgroup の削除．"clone_children" に
    • cgroup: remove the ns_cgroup
    • ns_cgroup 色々問題があったみたい (良く知りません ^^;)
    • 2.6.37 で "clone_children" が追加され，ns_cgroup はもうすぐ消えるという通知が追加されている
    • lxc の古いバージョン (0.7.5 辺り?) だと必須? 0.8.0 (0.9.0 も?) でも古いカーネルだとそちらを使う (多分)
    • CentOS などの少し前のものを使うときは注意が必要

Cgroups の変遷 〜 CFS bandwidth control (Kernel 3.2)

  • 従来の cgroups による cpu の制御は「優先度」の制御だった
  • 3.2 で CFS に使える CPU 帯域を制限する機能が付いた
    • リアルタイムクラスのプロセス (SCHED_RR) に対する制限機能は存在していた (CONFIG_RT_GROUP_SCHED)
    • この機能は標準のスケジューリングポリシー (SCHED_OTHER) クラスに対して CPU を使用する時間を制限するもの
  • 設定項目は 2 つ
    • cpu.cfs_period_us (割り当て単位時間の設定)
    • cpu.cfs_quota_us (割り当て上限値)
    • cpu.cfs_period_us 時間内で cpu.cfs_quota_us だけ CPU を使える
  • 統計値を cpu.stat で取得可能に
  • Linux 3.2 の CFS bandwidth control (2)
  • LinuxのCFSを使ってプロセスのCPU消費量を制御するツール作った (人間とウェブの未来)

Cgroups の変遷 〜 CFS bandwidth control (Kernel 3.2)

制限値の登録 (同じ処理をしているプロセスに同じ値) 

# echo 5000 > /sys/fs/cgroup/cpu/test1/cpu.cfs_quota_us
# echo 5000 > /sys/fs/cgroup/cpu/test2/cpu.cfs_quota_us
# ps aux
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3146 karma     20   0 19104 2204 1540 R    5  0.0   0:42.52 bash
 3168 karma     20   0 19104 2208 1540 R    5  0.0   0:42.50 bash

片方だけ増やす 

# echo 10000 > /sys/fs/cgroup/cpu/test2/cpu.cfs_quota_us
# ps aux
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3146 karma     20   0 19104 2204 1540 R   10  0.0   2:13.11 bash
 3168 karma     20   0 19104 2208 1540 R    5  0.0   2:04.39 bash

Cgroups の変遷 〜 Per-cgroup TCP buffer limits (Kernel 3.3)

  • Memory Controller でカーネルメモリに対する制限を行う第一弾
  • これまではユーザ空間の制限のみ
    • ... とは言え，中身は少し予想と外れるものでした
  • 関連する項目は 2 つ
    • memory.kmem.tcp.limit_in_bytes (制限値の設定)
    • memory.kmem.tcp.usage_in_bytes (現在の使用量)
  • 軽い気持ちで試してみたものの何か動きが期待と違うような...
  • どういう機能かの解説がない! カーネル付属文書に少しあるが，結局どういう機能かわからない (何も書いてないので従来通りに機能するんだろうね，と想像してたけど違った ^^;)．あったら教えてください．

Cgroups の変遷 〜 Per-cgroup TCP buffer limits (Kernel 3.3)

  • 結局，コードを読むハメに (なので以下は怪しいかも?)．
  • Memory Controller の仕組み (Resource Counter) を使ってはいるものの，この仕組み内では制限はかかってない (模様)
  • 従来から存在する sysctl パラメータの net.ipv4.tcp_mem が cgroup ごとに適用されるというものだった
  • 設定した memory.kmem.tcp.limit_in_bytes がグループ毎の tcp_mem に反映される
    • tcp_mem = min pressure max という設定の時，limit の値が...
    • limit < min の時，"limit limit limit"
    • min <= limit < pressure の時 "min limit limit"
    • pressure <= limit < max の時 "min pressure limit"
    • max <= limit の時，元の tcp_mem の値

Cgroups の変遷 〜 Per-cgroup TCP buffer limits (Kernel 3.3)

Cgroups の変遷 〜 Network priority cgroup (Kernel 3.3)

  • こちらは素直な機能 :-)
  • プロセスグループの各ネットワークインターフェースに対する優先度を設定する
  • 関連する項目は 2 つ
    • net_prio.prioidx (カーネルが内部で使用するグループを表す値)
    • net_prio.ifpriomap (各インターフェースに対する優先度)
$ cat /sys/fs/cgroup/net_prio/net_prio.ifpriomap 
lo 0
eth1 0
eth0 0

Cgroups の変遷 〜 Network priority cgroup (Kernel 3.3)

優先度の設定 

# echo "eth0 1" > /sys/fs/cgroup/net_prio/test1/net_prio.ifpriomap
# echo "eth0 100" > /sys/fs/cgroup/net_prio/test2/net_prio.ifpriomap

iperf を実行した結果 

[  4]  0.0-20.5 sec  2.17 GBytes   908 Mbits/sec <= priority 100 の方
[  5]  0.0-20.6 sec  71.2 MBytes  29.1 Mbits/sec <= priority 1 の方

net_prio.ifpriomap 

# cat /sys/fs/cgroup/net_prio/test1/net_prio.ifpriomap
eth0 1
# cat /sys/fs/cgroup/net_prio/test2/net_prio.ifpriomap 
eth0 100

Cgroups の変遷 〜 Network priority cgroup (Kernel 3.3)

Cgroups の変遷 〜 HugeTLB cgroup (Kernel 3.6)

Cgroups の変遷 〜 Memory Controller の Kernel Memory サポート (Kernel 3.8)

  • スタックとスラブの使用量のアカウンティングをサポート
  • 普通に Resource Counter を使っている
  • 普通に設定すれば期待通りに動く
  • いくつか注意点がある．これもパフォーマンスを落とさないための工夫の一環

Cgroups の変遷 〜 Memory Controller の Kernel Memory サポートの注意点

  • (他の Memory Controller と同様) root グループに対する制限は利かない
  • root グループの usage はアテにならない．子グループでカウントされたメモリ使用量はカウントされるかもしれないしされないかもしれない
  • 使用量のカウントは制限を設定してから始まる
    • グループを作成するだけでは始まらない
    • 一度，カウントされ始めると，グループ内にタスクがなくなっても，グループ自体がなくなるまではカウントされる
    • 一度，制限を設定してカウントが始まると，制限を解除 ( echo -1 > memory.kmem.limit_in_bytes ) してもカウントされる

Cgroups の変遷 〜 Memory Controller の Kernel Memory サポートの注意点

  • 制限を設定できないケース
    • 子グループを作成した後
    • グループにタスクが存在する場合
  • カーネルメモリの使用量はグローバルの使用量にも足される
    • memory.kmem.usage_in_bytes に足された値は，同時に memory.usage_in_bytes にも足される
      • ただし，同じカーネルメモリの memory.kmem.tcp.usage_in_bytes の値は足されない (と思われる)

Cgroups の変遷 〜 その他

  • xattr サポート (3.7)
    • security.* と trusted.* のみ許可
  • Memory Controller
    • カバーする範囲が広いので常に改良が加えられている

Cgroups の今後

その他関連しそうなカーネル機能

CRIU

a project to implement checkpoint/restore functionality for Linux in userspace.

試したのが少し前なので今はだいぶ動きが変わっているかと (開発がかなり活発な印象)

LXC

LXC の進化

LXC の歴史

  • Linux Container = Namespace + cgroup + ユーザスペースのツール (lxc)
  • 2008 年頃から IBM フランスの Daniel Lezcano 氏らにより開発
  • 0.6.5 辺りで基本的な機能は動作していた
  • 0.7.5 以降，徐々に Daniel Lezcano 氏の動きが鈍くなるとともに，Serge Hallyn, Stéphane Graber両氏 (Canonical) が前面に出てきた．
  • 両氏とも Ubuntu のデベロッパーであり，lxc の開発は Ubuntu メインで進む
    • Ubuntu では動いてから Fedora (systemd) で動くように追加，調整していた
  • Ubuntu に先取りで実装された機能をメインツリーにマージしていく感じで開発が進む
  • 最近は開発に参加する人が増えているような気がする
  • Github(https://github.com/lxc/lxc) で開発し，ある程度実装が固まった区切りで sourceforge のリポジトリにマージする形で開発が進むようになった
  • Ubuntu のパッケージに適用されたパッチを本家にマージ
    • 12.04LTS の lxc は 0.7.5 だが，ほぼ 0.8.0 に等しい (気がする) (86 のパッチ)

Ubuntu 12.04LTS の Ubuntu / lxc-0.8.0 新機能

  • 基本的な実装が済んだ印象の 0.7.5 の細かい所を色々改良した印象 + Ubuntu ならではの面白い機能

    • Apparmor サポート (Ubuntu で lxc 入れるとそれ用の profile も入って何も考えずにセキュア(コンテナ→親という視点)なコンテナが起動)
    • lxc-create, lxc-clone で LVM, Btrfs サポート
    • コンテナの rootfs を置く場所が
      • Btrfs の場合，rootfs は subvolume に．clone の時は snapshot を取る
      • LVM を使うよう指定すると，create は LV を作成，ファイルシステムを作って rootfs にする．clone は LVM の snapshot
    • ネスト構造のコンテナ (Ubuntu 12.04 だとネスト用の apparmor profile 必要．12.10 でネスト用 profile も含まれる)
    • テンプレートの追加 (Arch Linux, ALT Linux)
    • [Ubuntu] ARM コンテナの作成 (QEMU のエミュレーション)
    • [Ubuntu] lxc-start-ephemeral 追加

  • Ubuntu Weekly Recipe 第226回　LXCで軽量仮想環境の活用 (gihyo.jp)

lxc 0.9.0 新機能

  • たぶん Ubuntu 12.10 の lxc (0.8.0-rc1) も一部機能がバックポートされている

  • liblxc API 公開

  • API python, lua バインディング (python3)
    • 一部シェルで書かれていたコマンドを python で書き直し
  • seccomp サポート
  • コンテナ起動，停止時の各段階でのフックが可能に
    • pre-start, pre-mount, mount, autodev, start, post-stop
  • ネットワーク down 時に実行するスクリプトを指定可能に (up 時は以前からあった)

lxc 0.9.0 新機能

  • lxc-start-ephemeral 追加 (python3 必要)
  • Oracle Linux テンプレート
  • コンテナの /dev に最低限のデバイスを自動的に作成可能に
  • lxc-attach 改良
    • 環境変数廻りなど
    • そもそも lxc-attach は以前から存在はしていたが，パッチを当てた特別なカーネルでしか動かなかったので，事実上使えなかった．Ubuntu 13.04 で 3.8 カーネルが採用されたので使えるように．
  • lxc-setcap, lxc-setuid 削除

lxc 1.0 へ向けて

おそらく次の LTS (もちろん Ubuntu) をターゲットに lxc-1.0 を考えてるんじゃないかなー

lxc-1.0 に向けて考えること → [lxc-devel] 0.9 final release, plans for 1.0 and Linux Plumbers 2013

  • libvirt の lxc ドライバを liblxc (LXC の API) ベースに
  • User Namespace サポート
  • マルチスレッドのコマンドソケット
    • 複数のコンテナが起動してる時，同時にコンテナを監視するようなコマンドが実行できない (lxc-wait, lxc-monitor)
    • 今，lxc-monitord コマンドとか議論，開発されている → [lxc-devel] [RFC PATCH] allow multiple monitor clients
  • API の整備 (stable な API に)
  • ストレージバックエンド (プラグイン的に色々追加可能なように)

lxc 1.0 へ向けて

  • lxc-attach 書き換え → [lxc-devel] [PATCH] [RFC] Complete rewrite of lxc-attach functionality
    • 今は lxc-attach - 子プロセス - 孫プロセス の 3 階層になっているのを lxc-attach - 子プロセスx2 の 2 階層に
    • マルチスレッドなプログラムからも安全に attach できるように (多分)
  • overlayfs 対応 (lxc-start-ephemeral ?)
  • zfs 対応 (create, clone)

その他

その他

  • lxc JP グループ
    • 日本語でユーザがコンテナの話を出来る場所
    • こういう場がなかったのは，とりあえず動かすのは簡単だから?
    • まったりと盛り上がってます
  • lxc man pages 翻訳
    • 私が個人でやってます
    • 現在 0.9.0 の翻訳公開中 (但し初稿でノーチェック)
    • 校正者募集．その他気づいた所は是非お知らせください

さいごに

  • 3.8 カーネルでようやく Linux カーネルの機能だけでコンテナを実行し，運用できる環境が整いました
  • コンテナを簡単に試す環境も整ってます
  • 日々，どんどん改良が加えられ，新しい機能もどんどん出てきて，目が離せない分野です
  • 今後もコンテナや周辺技術の話題で盛り上がっていきたいです

参考文献

<Thank You!>