NAME¶
lxc.container.conf - LXC
コンテナ設定ファイル
linux コンテナ (
lxc)
は、常に使用する前に作成されます。
コンテナは、プロセスがコンテナを使う時に仮想化/隔離するシステムリソースのセットを定義することによって作成します。
デフォルトでは、pid, sysv ipc,
マウントポイントが仮想化され、隔離されます。
他のシステムリソースは、設定ファイルで明確に定義されない限りは、コンテナをまたいで共有されます。
例えば、もしネットワークが設定されていなければ、コンテナを作成する側とコンテナでネットワークを共有します。
しかし、ネットワークが指定されれば、新しいネットワークスタックがコンテナ用に作成され、コンテナは作成元の環境のネットワークを使いません。
設定ファイルは、コンテナに割り当てられる様々なシステムリソースを定義します。
現時点では、utsname、ネットワーク、マウントポイント、root
ファイルシステム、ユーザ名前空間、control
groups
がサポートされます。
設定ファイルのオプション一つを、
key = value
の形で一行で表します。
'#'
は、その行はコメントであることを示します。
ケーパビリティや cgroup
のオプションのような、リスト形式で指定するオプションでは、value
がない形式で指定できます。このように使うと、それ以前に定義した値をすべてクリアします。
複数の関係するコンテナの管理を容易にするために、コンテナの設定ファイルに別のファイルをロードすることが可能です。
例えば、ネットワークの設定を、複数のコンテナから
include させるように 1
つのファイルに定義することが可能です。
その場合、コンテナが他のホストに移動すると、そのファイルだけを更新する必要があるかもしれません。
- lxc.include
- include
させたいファイルを指定します。
include
するファイルは、lxc
設定ファイルのフォーマットとして有効でなければいけません。
アーキテクチャ¶
コンテナに対してアーキテクチャを設定することが可能です。
例えば、64
ビットのホスト上で 32
ビットのバイナリを動かすために
32
ビットアーキテクチャを設定することが可能です。
この設定を行うことにより、パッケージのダウンロードを行うなどの作業のうち、アーキテクチャ名に依存するような作業を行うコンテナスクリプトの修正を行います。
- lxc.arch
- コンテナに設定するアーキテクチャを指定します。
有効なオプションは以下です。
x86, i686, x86_64, amd64
ホスト名¶
utsname
セクションは、コンテナに設定されるホスト名を定義します。
コンテナは、システムのホスト名を変えることなく、自身のホスト名を持つ事が可能です。
このことにより、ホスト名はコンテナ専用となります。
- lxc.utsname
- コンテナのホスト名を指定します。
クリーンなシャットダウン時のシグナル¶
lxc-stop
がコンテナをクリーンにシャットダウンするためにコンテナの
init
プロセスに送るシグナル名か番号を指定できます。
init
システムによって、クリーンなシャットダウンを行うために使うシグナルは異なります。
このオプションではシグナルとして
kill(1)
で使う形式を指定することができます。
例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10
のような形式、もしくは数字を指定します。デフォルトのシグナルは
SIGPWR です。
- lxc.haltsignal
- コンテナをシャットダウンするために使うシグナルを指定します。
リブート時のシグナル¶
lxc-stop
がコンテナをリブートするために送るシグナル名か番号を指定できます。
このオプションではシグナルとして
kill(1)
で使う形式を指定することができます。
例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10
のような形式、もしくは数字を指定します。デフォルトのシグナルは
SIGINT です。
- lxc.rebootsignal
- コンテナをリブートするために使うシグナルを指定します。
強制停止時のシグナル¶
lxc-stop
がコンテナを強制的にシャットダウンするために送るシグナル名か番号を指定することができます。
このオプションではシグナルとして
kill(1)
で使う形式を指定することができます。
例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10
のような形式、もしくは数字を指定します。デフォルトのシグナルは
SIGKILL です。
- lxc.stopsignal
- コンテナを停止するのに使用するシグナルを指定します。
INIT コマンド¶
コンテナの init
として使うコマンドを設定します。
このオプションは lxc-execute
では無視されます。
デフォルトは /sbin/init
です。
- lxc.init_cmd
- init
として使うバイナリの、コンテナの
rootfs
からの絶対パスを指定します。
INIT が使う ID¶
lxc-execute
が実行するコンテナの
init
と、その後に起動するコマンドが使用する
UID/GID を設定します。
このオプションは lxc-execute
がユーザ名前空間内で起動するときのみ使われます。
デフォルト値は UID(0), GID(0)
です。
- lxc.init_uid
- ユーザ名前空間内で
init が使う UID です。
- lxc.init_gid
- ユーザ名前空間内で
init が使う GID です。
一時的なコンテナ¶
シャットダウン後にコンテナを削除するかどうかを指定できます。
- lxc.ephemeral
- 指定できる値は 0
または 1
のみです。この値を 1
に設定すると、シャットダウン後にコンテナを削除します。
ネットワーク¶
ネットワークセクションは、コンテナ内でどのようにネットワークを仮想化するかを定義します。
ネットワークの仮想化はレイヤー
2 で作動します。
ネットワークの仮想化を使用するためには、コンテナのネットワークインターフェースを定義しなければなりません。
いくつかの仮想インターフェースをアサインすることができます。
そして、仮に物理ネットワークインターフェースが一つしかなくても、コンテナ内でいくつもの仮想インターフェースを使うことができます。
- lxc.network
- 値を指定せずに使い、それ以前に定義されたすべてのネットワークオプションをクリアできます。
- lxc.network.type
- コンテナがどの種類のネットワーク仮想化を使うかを指定します。
一つのネットワークの設定ごとに
lxc.network.type
フィールドを指定します。
このように、一つのコンテナに複数のネットワークインターフェースを割り当てることができるだけでなく、同じコンテナに対して複数のネットワーク仮想化の種類を指定することが出来ます。
仮想化の種類は以下の値を取る事が出来ます:
none:
ホストのネットワーク名前空間を共有します。
これにより、ホストのネットワークデバイスをコンテナ内で使うことが可能になります。
もしコンテナもホストも
init として upstart
を使っている場合、(例えば)
コンテナ内で 'halt'
を実行すると、ホストがシャットダウンしてしまうことにもなります。
empty:
ループバックインターフェースだけを作成します。
veth:
一方がコンテナに、もう一方が
lxc.network.link
オプションで指定されたブリッジに接続されるペアの仮想イーサネットデバイスを作成します。
もし、ブリッジが指定されていない場合、veth
ペアデバイスは作成されますが、ブリッジには接続されません。
ブリッジはコンテナが開始する前にシステムで事前に設定しておく必要があります。
lxc
はコンテナ外の設定を扱うことはありません。
デフォルトでは、
lxc
がコンテナの外部に属するネットワークデバイスに対する名前を決定します。
しかし、もしこの名前を自分で指定したい場合、
lxc.network.veth.pair
オプションを使って名前を設定し、lxc
に対して指定をすることができます
(非特権コンテナの場合をのぞきます。セキュリティ上の理由からこのオプションは無視されます)。
vlan: vlan
インターフェースは
lxc.network.link
で指定されたインターフェースとリンクし、コンテナに割り当てられます。
vlan の指定は lxc.network.vlan.id
オプションで指定します。
macvlan: macvlan
インターフェースは
lxc.network.link
により指定されるインターフェースとリンクし、コンテナに割り当てられます。
lxc.network.macvlan.mode
でモードを指定すると、その
macvlan
の指定を、同じ上位デバイスで異なる
macvlan
の間の通信をする時に使います。
指定できるモードは
private、vepa、bridge、passthru
のいずれかです。
private
モードの場合、デバイスは同じ上位デバイスの他のデバイスとの通信を行いません
(デフォルト)。
新しい仮想イーサネットポート集約モード
(Virtual Ethernet Port Aggregator (VEPA)) である
vepa
モードの場合、隣接したポートが、ソースとデスティネーションの両方が
macvlan
ポートに対してローカルであるフレームを全て返すと仮定します。
すなわち、ブリッジが
reflective relay
として設定されているということです。
上位デバイスから入ってくるブロードキャストフレームは、VEPA
モードである全ての
macvlan
インターフェースに送りつけられます。
ローカルのフレームはローカルには配送されません。
bridge
モードの場合、同じポートの異なる
macvlan
インターフェースの間のシンプルなブリッジとして動作します。
あるインターフェースから他のインターフェースへのフレームは、直接配送され、外部には送出されません。
ブロードキャストフレームは、全ての他のブリッジと外部のインターフェースに対して送られます。
しかし、reflective relay
からフレームが返ってきたときは、再度それを配送することはしません。
全ての MAC
アドレスを知っているので、ブリッジモジュールのように、macvlan
ブリッジモードは学習や
STP
の必要はありません。
passthru
モードの場合、物理インターフェースで受け取った全てのフレームは
macvlan
インターフェースに転送されます。
passthru
モードの場合、ひとつの
macvlan
インターフェースだけが、ひとつの物理インターフェースに対して設定できます。
phys: lxc.network.link
で指定された、すでに存在しているインターフェースがコンテナに割り当てられます。
- lxc.network.flags
- ネットワークに対して行うアクションを指定します。
up:
インターフェースを起動させます。
- lxc.network.link
- 実際のネットワークトラフィックに使うインターフェースを指定します。
- lxc.network.mtu
- インターフェースに対する
MTU を指定します。
- lxc.network.name
- インターフェース名は動的に割り当てられます。
しかし、もしコンテナが使用する設定ファイルが一般的な名前を使用するために、他の特定の名前が必要であれば
(例えば eth0
など)、コンテナ内のインターフェースは、このオプションで指定した名前にリネームされます。
- lxc.network.hwaddr
- 仮想インターフェースの
MAC
アドレスは、デフォルトでは動的に割り当てられます。
しかし、MAC
アドレスの衝突や、リンクローカルIPv6
アドレスを常に同じにした場合などは、このオプションが必要です。
アドレス中の "x"
という文字は、ランダムな値に置き換えられます。
これによりテンプレートに
hwaddr
を設定することが可能になります。
- lxc.network.ipv4
- 仮想インターフェースに割り当てる
ipv4
アドレスを指定します。
複数行により複数の
ipv4
アドレスを指定します。
このアドレスは x.y.z.t/m
というフォーマットで指定します。
例えば、192.168.1.123/24。ブロードキャストアドレスも同じ行の
ipv4
アドレスのすぐ後で指定しなくてはなりません。
- lxc.network.ipv4.gateway
- コンテナでゲートウェイとして使う
IPv4
アドレスを指定します。
アドレスは x.y.z.t
というフォーマットです。
例えば、192.168.1.123。 auto
という特別な値を記述する事も可能です。
これは ( lxc.network.link
で指定した)
ブリッジインターフェースの最初のアドレスを使用し、それをゲートウェイに使うという意味になります。
auto
はネットワークタイプとして
veth と macvlan
を指定している時だけ有効となります。
- lxc.network.ipv6
- 仮想インターフェースに割り当てる
ipv6
アドレスを指定します。
複数行により複数の
ipv6
アドレスを指定します。
このアドレスは x::y/m
というフォーマットで指定します。
例えば、2003:db8:1:0:214:1234:fe0b:3596/64。
- lxc.network.ipv6.gateway
- コンテナでゲートウェイとして使う
IPv6
アドレスを指定します。
アドレスは x::y
というフォーマットです。例えば、2003:db8:1:0::1。
auto
という特別な値を記述する事も可能です。
これは ( lxc.network.link
で指定した)
ブリッジインターフェースの最初のアドレスを使用し、それをゲートウェイに使うという意味になります。
auto
はネットワークタイプとして
veth と macvlan
を指定している時だけ有効となります。
- lxc.network.script.up
- ホスト側から使われる、ネットワークの作成と設定が済んだ後に実行するスクリプトを指定します。
以下の引数がスクリプトに渡されます:
コンテナ名、設定セクション名(net)。
その後の引数はスクリプトのフックで使われる設定セクションに依存します。
以下がネットワークシステムによって使われます:
実行コンテキスト
(up)、ネットワークのタイプ
(empty/veth/macvlan/phys)
ネットワークのタイプによっては、更に別の引数が渡されるかもしれません:
veth/macvlan/phys の場合
(ホスト側の)
デバイス名
スクリプトからの標準出力は
debug
レベルでロギングされます。
標準エラー出力はロギングされません。
しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。
- lxc.network.script.down
- ホスト側から使われる、ネットワークを破壊する前に実行するスクリプトを指定します。
以下の引数がスクリプトに渡されます:
コンテナ名、設定セクション名(net)。
その後の引数はスクリプトのフックで使われる設定セクションに依存します。
以下がネットワークシステムによって使われます:
実行コンテキスト
(up)、ネットワークのタイプ
(empty/veth/macvlan/phys)。
ネットワークのタイプによっては、更に別の引数が渡されるかもしれません:
veth/macvlan/phys。そして最後に
(ホスト側の)
デバイス名が渡されます。
スクリプトからの標準出力は
debug
レベルでロギングされます。
標準エラー出力はロギングされません。
しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。
新しい擬似端末のインスタンス (DEVPTS)¶
さらに厳しい隔離のために、コンテナは自身のプライベートな
pseudo tty (擬似端末)
を持つことが可能です。
- lxc.pts
- もし設定された場合、コンテナは新しい
pseudo tty
インスタンスを持ち、それを自身のプライベートとします。
この値は pts
インスタンスに許可される
pseudo tty
の最大数を指定します
(この制限はまだ実装されていません)。
コンテナのシステムコンソール¶
コンテナでルートファイルシステムを持つように設定されており、inittab
ファイルでコンソールの使用が設定されている場合、このコンソールの出力がどこになされるのかを指定したいと思うでしょう。
- lxc.console.logfile
- コンソール出力を書き込むファイルのパスを指定します。
- lxc.console
- コンソールを割り当てるデバイスのパスを指定します。'none'
というキーワードは、単純にコンソールを無効にします。
この設定は、アプリケーションが書き込む事ができるコンソールデバイスファイルが
rootfs
に存在する場合、メッセージがホスト側に出力されるので危険です。
TTY を通したコンソール¶
このオプションはコンテナが
root
ファイルシステムを持つように設定されており、inittab
ファイルで tty 上に getty
の起動が設定されている場合に役に立ちます。
このオプションはコンテナで利用できる
tty の数を指定します。
inittab
ファイルに設定する getty
の数は、このオプションの指定する
tty
の数より大きくしてはいけません。
さもなければ、超過した分の
getty
セッションはコンソールか
/var/log/messages
にうっとうしいメッセージを生死を表示しながら、永久に生死を繰り返すでしょう。
- lxc.tty
- コンテナに作成出来る
tty
の数を指定します。
コンソールデバイスの位置¶
LXC
のコンソールはホストによって作られ、コンテナ内で要求されたデバイスに
bind マウントされた Unix98 PTY
経由で提供されます。
デフォルトでは
/dev/console
と
/dev/ttyN に bind
マウントされます。
これはゲスト内でのパッケージのアップグレードを妨げる可能性があります。
なので
/dev
以下のディレクトリを指定することができます。
LXC
はこのディレクトリ以下にファイルを作成し、これらのファイルを
bind マウントします。
そして、これらの
(作成された)
ファイルは
/dev/console と
/dev/ttyN
にシンボリックリンクされます。
シンボリックリンクを消去したり置き換えたりすることは可能ですから、パッケージのアップグレードは成功します。
- lxc.devttydir
- コンテナのコンソールデバイスを作成するための
/dev
以下のディレクトリを指定します。
/DEV ディレクトリ¶
デフォルトでは、lxc
はコンテナの
/dev
以下に fd, stdin, stdout, stderr
のシンボリックリンクを作成しますが、自動的にはデバイスノードのエントリは作成しません。
これは、コンテナの
rootfs
で必要な設定を行えるようにするものです。
lxc.autodev が 1
に設定されている場合、コンテナの
rootfs
をマウントした後、LXC
は新しい tmpfs を
/dev
以下にマウントします
(500k 制限の)。
そして初期デバイスの最小限のセットを作成します。
これは、"systemd"
ベースの "init"
環境のコンテナを起動する時に通常必要ですが、他の環境の場合はオプショナルなものです。
コンテナの /dev
ディレクトリ内の追加デバイスは
lxc.hook.autodev
フックを使用して作成されます。
- lxc.autodev
- コンテナの起動時に
LXC が /dev
をマウントして最小限の
/dev
を作成するのを止めるには、この値を
0
に設定してください。
KMSG のシンボリックリンクの有効化¶
/dev/console
へのシンボリックリンクとして
/dev/kmsg
を作成することを有効にします。デフォルトは
0 です。
- lxc.kmsg
- /dev/kmsg
へのシンボリックリンクを有効にするには
1
を設定してください。
マウントポイント¶
マウントポイントセクションは、マウントするための区別された場所を指定します。
これらのマウントポイントは、コンテナだけに見え、コンテナ外で実行されるプロセスから見えることはありません。
例えば、/etc や /var や /home
をマウントするときに役に立つでしょう。
注意: 通常 LXC
は、マウント対象と相対パス指定のバインドマウントを、適切にコンテナルート以下に閉じ込めます。
これは、ホストのディレクトリやファイルに対して重ね合わせを行うようなマウントによる攻撃を防ぎます。(絶対パス指定のマウントソース中の各パスがシンボリックリンクである場合は無視されます。)
しかし、もしコンテナの設定が最初に、/home/joe
のようなコンテナユーザのコントロール配下にあるディレクトリを、コンテナ中のある
path
にマウントし、その後
path
以下でマウントが行われるような場合、コンテナユーザがタイミングを見計らって自身のホームディレクトリ以下でシンボリックリンクを操作するような
TOCTTOU
攻撃が成立する可能性があります。
- lxc.mount
- マウント情報の書かれた
fstab
フォーマットで書かれたファイルの場所を指定します。
マウントする場所は相対バスで書くことができます。そして、ほとんどの場合にコンテナの
root
からの相対パスとなるはずです。例えば、以下のように書きます。
proc proc proc nodev,noexec,nosuid 0 0
.fi
この例は、root ファイルシステムがどこにあっても、コンテナの /proc 以下に proc ファイルシステムをマウントします。
これは、ブロックデバイスがバックエンドのファイルシステムだけでなく、コンテナのクローンにも柔軟に対応できます。
ファイルシステムがイメージファイルやブロックデバイスからマウントされている場合、3 つ目のフィールド (fs_vfstype) は
mount(8)
のように auto を指定することはできず、明確に指定しなければいけません。
- lxc.mount.entry
-
fstab フォーマットの一行と同じフォーマットのマウントポイントの指定をします。
fstab フォーマットに加えて、LXC ではマウントに対して独自の 2 つのオプションが使えます。
optional は、マウントが失敗しても失敗を返さずに無視します。
create=dir と create=file は、マウントポイントをマウントする際にディレクトリもしくはファイルを作成します。
- lxc.mount.auto
-
標準のカーネルファイルシステムで自動的にマウントするものを指定します。
これは劇的に設定を容易にする可能性があります。
- •
-
proc:mixed (or proc):
/proc を読み書き可能でマウントします。
ただし、 /proc/sys と /proc/sysrq-trigger は、セキュリティとコンテナの隔離の目的でリードオンリーで再マウントされます。
- •
-
proc:rw:
/proc を読み書き可能でマウントします。
- •
-
sys:mixed (or sys):
/sys/devices/virtual/net のみ書き込み可能で、その他の /sys はリードオンリーでマウントします。
- •
-
sys:ro:
/sys を、セキュリティとコンテナの隔離の目的でリードオンリーでマウントします。
- •
-
sys:rw:
/sys を読み書き可能でマウントします。
- •
-
cgroup:mixed:
/sys/fs/cgroup を tmpfs でマウントし、そのコンテナの追加が行われた全ての階層構造に対するディレクトリを作製し、その cgroup の名前でその中にサブディレクトリを作製し、そのコンテナ自身の cgroup をそのディレクトリにバインドマウントします。
コンテナは自身の cgroup ディレクトリに書き込みが可能ですが、親ディレクトリはリードオンリーで再マウントされているため書き込めません。
- •
-
cgroup:ro:
cgroup:mixed と同様にマウントされますが、全てリードオンリーでマウントされます。
- •
-
cgroup:rw:
cgroup:mixed と同様にマウントされますが、全て読み書き可能でマウントされます。
コンテナ自身の cgroup に至るまでのパスも書き込み可能になることに注意が必要ですが、cgroup ファイルシステムにはならず、
/sys/fs/cgroup の tmpfs の一部分になるでしょう。
- •
-
cgroup (マウントオプションなしの場合):
コンテナが CAP_SYS_ADMIN ケーパビリティを保持している場合、 cgroup:rw となります。保持していない場合、cgroup:mixed となります。
- •
-
cgroup-full:mixed:
/sys/fs/cgroup を tmpfs でマウントし、そのコンテナの追加が行われた全ての階層構造に対するディレクトリを作製し、ホストからコンテナまでの階層構造を全てバインドマウントし、コンテナ自身の cgroup を除いてリードオンリーにします。
cgroup と比べると、コンテナ自身の cgroup に至るまでの全てのパスが tmpfs の下層のシンプルなディレクトリとなり、コンテナ自身の cgroup の外ではリードオンリーになりますが、/sys/fs/cgroup/$hierarchy はホストの全ての cgroup 階層構造を含みます。
これにより、コンテナにはかなりの情報が漏洩します。
- •
-
cgroup-full:ro:
cgroup-full:mixed と同様にマウントされますが、全てリードオンリーでマウントされます。
- •
-
cgroup-full:rw:
cgroup-full:mixedと同様にマウントされますが、全て読み書き可能でマウントされます。
この場合、コンテナは自身の cgroup から脱出する可能性があることに注意してください (コンテナが CAP_SYS_ADMIN を持ち、自身で cgroup ファイルシステムをマウント可能なら、いずれにせよそのようにするかもしれないことにも注意してください)。
- •
-
cgroup-full (マウントオプションなしの場合):
コンテナが CAP_SYS_ADMIN ケーパビリティを保持している場合、 cgroup-full:rw となります。保持していない場合、cgroup-full:mixed となります。
cgroup 名前空間が有効の場合、 cgroup の自動マウントの指定はどれも無視されます。これは、コンテナが自身でファイルシステムをマウントするため、自動マウントがコンテナの init を混乱させる可能性があるためです。
cgroup ファイルシステムの自動マウントが有効の場合、 /sys/fs/cgroup 以下の tmpfs は常に読み書き可能でマウントされることに注意が必要です (しかし :mixed と :ro の場合は、個々の階層の /sys/fs/cgroup/$hierarchy は読み込み専用となるでしょう)。これは Ubuntu の
mountall(8)
コマンドの特異な動きに対処するためのものです。特異な動きとは、 /sys/fs/cgroup が読み込み専用でマウントされた状態で、コンテナが CAP_SYS_ADMIN を持たない場合、/sys/fs/cgroup を読み書き可能で再マウントしようとしてできないため、コンテナのブート時にユーザからの入力を待ってしまうというものです。
例:
lxc.mount.auto = proc sys cgroup
lxc.mount.auto = proc:rw sys:rw cgroup-full:rw
ルートファイルシステム¶
コンテナのルートファイルシステムは、ホストのルートファイルシステムと異なるようにすることも可能です。
- lxc.rootfs
- コンテナのルートファイルシステムを指定します。
この値はイメージファイル、ディレクトリ、ブロックデバイスのどれかを取ることができます。
もし指定されない場合、コンテナはホストとルートファイルシステムを共有します。
ディレクトリ、単純なブロックデバイスのバックエンドを持つコンテナの場合、パス名を使うことができます。
もし rootfs が nbd
デバイスの場合、
nbd:file:1 という指定は
file を nbd
デバイスとして使用し、その
1
番目のパーティションが
rootfs
としてマウントされます。
nbd:file
という指定は、nbd
デバイス自身をマウントします。
overlayfs:/lower:/upper
という指定は、rootfs は
/lower
という読み込み専用でマウントされるディレクトリの上に、
/upper
というディレクトリを読み書き可能で重ね合わせてマウントします。
aufs:/lower:/upper は overlayfs
で指定している部分を
aufs
と指定すれば同じことになります。
overlayfs と aufs
は両方とも、複数の
/lower
ディレクトリを指定できます。
loop:/file は /file を loop
デバイスとして使用し、loop
デバイスをマウントします。
- lxc.rootfs.mount
- root
ファイルシステムの変更の前に、
lxc.rootfs
を再帰的にどこにバインドするのかを指定します。これは
pivot_root(8)
システムコールが確実に成功する事を保証します。
どんなディレクトリでも良く、デフォルトでも通常は動くはずです。
- lxc.rootfs.options
- rootfs
をマウントするときに追加したいマウントオプション。
- lxc.rootfs.backend
- 使用するバックエンドのタイプを、例えば
'dir' や 'zfs'
のように指定します。
コンテナ起動時に LXC
が推測できますが、時間がかかります。これを指定すると、余分な処理を避けられます。
CONTROL GROUP¶
CONTROL GROUP セクションは、(lxc
とは)
別のサブシステムの設定を含みます。
lxc
は、このサブシステム名の正しさはチェックしません。
実行時のエラーを検出するのに不便ですが、別の将来のサブシステムをサポート出来るという有利な点もあります。
- lxc.cgroup.[subsystem name]
- 設定する control group
の値を指定します。
サブシステム名は、control
group
のそのままの名前です。
許される名前や値の書式は
LXC
が指示することはなく、コンテナが実行された時に実行されている
Linux
カーネルの機能に依存します。
例えば lxc.cgroup.cpuset.cpus
ケーパビリティ¶
コンテナが root
権限で実行されていても、コンテナ内ではケーパビリティ
(capabilities)
を削除する事は可能です。
- lxc.cap.drop
- コンテナ内で削除するケーパビリティ
(capability) を指定します。
一行でスペース区切りで複数のケーパビリティを指定することも可能です。
指定は、"CAP_"
というプレフィックスなしで、小文字でケーパビリティを指定します。
例えば、CAP_SYS_MODULE
というケーパビリティは
sys_module
と指定する必要があります。
詳しくは以下を参照してください。
capabilities(7)
この設定を、値を指定しない状態で使った場合、それ以前に指定された削除対象のケーパビリティの指定をすべてクリアします
(lxc.cap.drop
に何も指定しない状態になります)。
- lxc.cap.keep
- コンテナ内で維持するケーパビリティを指定します。指定した以外の全てのケーパビリティはドロップされます。
特別な値 "none"
が指定されている時点で、lxc
はこの時点で保持することになっている全てのケーパビリティをクリアします。"none"
を単独で使用するとすべてのケーパビリティを削除できます。
APPARMOR プロファイル¶
lxc が apparmor
サポートでコンパイルされ、インストールされている場合で、ホストで
apparmor
が有効な場合、コンテナが従って動くべき
apparmor
プロファイルは、コンテナの設定で指定することが可能です。
デフォルトは、ホストのカーネルで
cgroup
名前空間が使える場合は
lxc-container-default-cgnsです。使えない場合は
lxc-container-default です。
- lxc.aa_profile
- コンテナが従うべき
apparmor
プロファイルを指定します。
コンテナが apparmor
による制限を受けないように設定するには、以下のように設定します。
lxc.aa_profile = unconfined
もし apparmor
プロファイルが変更されないままでなくてはならない場合
(ネストしたコンテナである場合や、すでに
confined されている場合)
は以下のように設定します。
lxc.aa_profile = unchanged
- lxc.aa_allow_incomplete
- apparmor
プロファイルはパス名ベースですので、多数のファイルの制限を行う際、執念深い攻撃者に対して効果的であるためにはマウントの制限が必要です。
しかし、これらのマウントの制限は
upstream
のカーネルではまだ実装されていません。マウントの制限なしでも、apparmor
プロファイルによって予想外のダメージに対する保護が可能です。
このフラグが 0 の場合
(デフォルト)、カーネルが
apparmor
のマウント機能をサポートしていない場合にコンテナが起動しません。これはカーネルを更新した後に機能が退行したことが検出できるようにするためです。
不完全な apparmor
の保護の下でコンテナを起動するためには、このフラグを
1
に設定してください。
SELINUX コンテキスト¶
lxc が SELinux
サポートでコンパイルされ、インストールされている場合で、ホストで
SELinux
が有効な場合、コンテナが従って動くべき
SELinux
コンテキストは、コンテナの設定で指定することが可能です。
デフォルトは
unconfined_t
であり、これは lxc
がコンテキストを変えないという意味になります。
ポリシーの例と追加の情報は
/usr/share/lxc/selinux/lxc.te
ファイルを参照してください。
- lxc.se_context
- コンテナが従うべき
SELinux
コンテキストを指定するか、
unconfined_t
を指定します。例えば以下のように設定します。
lxc.se_context = system_u:system_r:lxc_t:s0:c22
SECCOMP の設定¶
コンテナは、起動時に
seccomp
プロファイルをロードすることで、利用可能なシステムコールを減らして起動することが可能です。
seccomp
の設定ファイルは、1
行目がバージョン番号、2
行目がポリシーのタイプで始まる必要があり、その後に設定を書きます。
現時点では、バージョン番号は
1 と 2
をサポートしています。バージョン
1
では、ポリシーはシンプルなホワイトリストですので、2
行目は "whitelist"
でなければなりません。
そして残りの行には 1
行に 1
つずつ、システムコール番号を書きます。各行のシステムコール番号がホワイトリスト化され、リストにない番号は、そのコンテナではブラックリストに入ります。
バージョン 2
では、ポリシーはブラックリストもしくはホワイトリストで表され、ルールごとのアクションと、ポリシーごとのデフォルトのアクションを設定できます。そして、アーキテクチャごとの設定と、テキストで書かれたシステムコール名での設定が可能です。
以下にブラックリストのポリシーの例を示します。これは
mknod
以外の全てのシステムコールが許可され、mknod
が呼ばれると、何もせずに単に
0(成功) を返します。
2
blacklist
mknod errno 0
.fi
- lxc.seccomp
-
コンテナがスタートする前にロードする seccomp の設定を含むファイルを指定します。
UID のマッピング¶
コンテナは、ユーザとグループの
id
のマッピングを持った専用のユーザ名前空間で起動することが可能です。
たとえば、コンテナ内のユーザ
id 0 を、ホストのユーザ
id 200000
にマッピングすることが可能です。
コンテナの root
ユーザはコンテナ内では特権を持ちますが、ホストでは特権を持ちません。
通常は、システムコンテナは
id
の範囲を要求し、それをマッピングします。
例えば、コンテナ内のユーザとグループの
id 0 から 20,000 を 200,000 から 220,000
にマッピングします。
- lxc.id_map
- 4
つの値を記述する必要があります。
最初の文字は 'u' か 'g'
のどちらかで、ユーザかグループの
ID
のどちらをマッピングするかを指定します。
次はコンテナのユーザ名前空間内に現れる最初のユーザ
ID です。
その次は、そのユーザ
ID
のホスト上での値です。
最後は、ID
のマッピングをいくつ連続して行うかの数を指定します。
コンテナのフック¶
コンテナのフックは、コンテナの存続期間の色々な場面で実行することのできるプログラムやスクリプトです。
コンテナのフックが実行されるとき、情報がコマンドライン引数と環境変数の両方を通して渡されます。引数は:
- •
- コンテナ名
- •
- セクション (常に 'lxc')
- •
- フックのタイプ ('clone' や
'pre-mount' など)
- •
- 追加の引数。clone
フックの場合、lxc-clone
に渡される追加の引数は、フックへの引数として追加されます。stop
フックの場合は、コンテナの名前空間のそれぞれに対するファイルディスクリプタへのパスが、名前空間名とともに渡されます。
以下の環境変数がセットされます。
- •
- LXC_NAME: コンテナ名
- •
- LXC_ROOTFS_MOUNT: マウントされた
root
ファイルシステムへのパス
- •
- LXC_CONFIG_FILE:
コンテナの設定ファイルのパス
- •
- LXC_SRC_NAME: clone
フックの場合、元のコンテナの名前
- •
- LXC_ROOTFS_PATH: コンテナの lxc.rootfs
エントリ。これはマウントされた
rootfs
が存在する場所にはならないでしょう。それには
LXC_ROOTFS_MOUNT
を使用してください。
スクリプトからの標準出力は
debug
レベルでロギングされます。
標準エラー出力はロギングされません。
しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。
- lxc.hook.pre-start
- コンテナの
tty、コンソールの作成、マウントが実行される前に、ホストの名前空間内で実行するフック。
- lxc.hook.pre-mount
- コンテナのファイルシステムの名前空間で実行されますが、rootfs
が設定される前に実行するフック。
これにより rootfs
の操作が可能になります。
例えば、暗号化されたファイルシステムのマウントなどです。
このフック内でなされるマウントはホストには影響しません
(mounts propagation を除いて)。
なので、それらはコンテナがシャットダウンする時に自動的にクリーンアップされます。
- lxc.hook.mount
- マウントが完了した後ですが、pivot_root
の前にコンテナの名前空間で実行されるフック。
- lxc.hook.autodev
- lxc.autodev == 1
が設定されている場合で、マウントが完了し、マウント時のフックも実行された後ですが、pivot_root
の前にコンテナの名前空間で実行するフック。
このフックの目的は、systemd
ベースのコンテナ向けの
autodev
オプションが設定されている時に、コンテナの
/dev
ディレクトリを設定するのを支援することです。コンテナの
/dev
ディレクトリは、このフックが実行される時有効な
${ LXC_ROOTFS_MOUNT}
環境変数からの相対パスとなります。
- lxc.hook.start
- コンテナの init
が実行される直前にコンテナの名前空間で実行されるフック。
コンテナ内で利用可能なプログラムである必要があります。
- lxc.hook.stop
- コンテナのシャットダウン後、コンテナの名前空間への参照とともに、ホストの名前空間で実行されるフックです。
それぞれの名前空間に対応する追加の引数がフックに渡されます。その引数にはコロンで区切られた名前空間のタイプ名とファイル名が含まれており、ファイル名は名前空間に対するファイルディスクリプタを取得するのに使えます。
タイプ名は /proc/PID/ns
ディレクトリ内のファイル名です。
例えば、マウント名前空間に対応する引数は通常は
mnt:/proc/PID/fd/12
のようになります。
- lxc.hook.post-stop
- コンテナがシャットダウンされた後にホストの名前空間で実行するフック。
- lxc.hook.clone
- コンテナが新しいコンテナにクローンされる際に実行されるフック。詳しくは
lxc-clone(1)
を参照してください。
- lxc.hook.destroy
- コンテナを破壊する際に実行されるフックです。
コンテナのフックで使える環境変数¶
起動時のフックに設定情報を提供し、フックの機能を助けるための環境変数がいくつか利用可能です。
全ての変数が全てのコンテキストで利用可能なわけではありません。
具体的には、全てのパスはホストシステム上のパスであり、そのため、
lxc.hook.start
フックの時点では使用できません。
- LXC_NAME
- LXC
コンテナの名前。共通のログ環境内でのログメッセージに使うときに便利です。[
-n]
- LXC_CONFIG_FILE
- コンテナの設定ファイルのホスト上でのパス。
これは、他の方法では得られない追加の設定情報を見つけるために、コンテナに、元の、トップレベルの設定ファイルの位置を与えるものです。
[ -f]
- LXC_CONSOLE
- 設定されている場合のコンテナのコンソール出力のパス。
[ -c] [lxc.console]
- LXC_CONSOLE_LOGPATH
- 設定されている場合のコンテナのコンソールログ出力のパス。
[ -L]
- LXC_ROOTFS_MOUNT
- 初期にコンテナがマウントされる場所。
これは、コンテナインスタンスが起動するためのコンテナの
rootfs
へのホスト上のパスであり、インスタンスのための移行が行われる場所です。
[ lxc.rootfs.mount]
- LXC_ROOTFS_PATH
- rootfs.mount
へマウントされるコンテナのルートへのホスト上のパスです。
[ lxc.rootfs]
- LXC_SRC_NAME
- clone
フックの場合のみ使われます。クローン元のコンテナ名が設定されます。
- LXC_TARGET
- stop
フックの場合のみ使われます。コンテナのシャットダウンの場合は
"stop"、リブートの場合は
"reboot"
が設定されます。
- LXC_CGNS_AWARE
- この変数が設定されていない場合、お使いのバージョンの
LXC は cgroup
名前空間を扱えません。設定されている場合、この値は
1
に設定されています。そして、cgroup
名前空間を扱えます。
この変数はカーネルで
cgroup
名前空間が有効であることは保証しません。この変数は
lxcfs
のマウントフックが使います。
ロギング¶
ロギングはコンテナごとに設定することが可能です。
デフォルトでは、lxc
パッケージのコンパイル条件に依存し、コンテナのスタートアップは
ERROR
レベルでのみロギングされ、コンテナのパス以下か、/var/lib/lxc
以下のどちらかにコンテナ名
(の後に '.log'
が付与される)
をもとにした名前でロギングされます。
デフォルトのログレベルとログファイルは両方とも、コンテナの設定ファイル内で指定され、デフォルトの値を上書きします。
同様に、設定ファイルのエントリは
lxc-start
のコマンドラインオプションで上書きすることも可能です。
- lxc.loglevel
- ログを取得するレベル。
ログレベルは 0..8
の範囲の整数です。
数字が小さいほど冗長なデバッグを意味します。
具体的には、0 = trace, 1 = debug, 2 =
info, 3 = notice, 4 = warn, 5 = error, 6 = critical, 7 = alert, and 8 =
fatal です。
指定されない場合、レベルのデフォルトは
5 (error)
で、それ以上のエラーがロギングされます。
(フックスクリプトやネットワークインターフェースの起動、停止時のスクリプトのような)
スクリプトが呼ばれた時、スクリプトの標準出力は
level 1 の debug
でロギングされます。
- lxc.logfile
- ログ情報を書き込むファイル。
自動起動¶
自動起動オプションでは、自動起動させるコンテナと順番の設定が可能です。
このオプションは LXC
ツールが直接使用するか、ディストリビューションが提供する外部ツールが使用するかもしれません。
- lxc.start.auto
- コンテナを自動起動させるかどうかを設定します。
有効な値は 0(オフ) か
1(オン) です。
- lxc.start.delay
- コンテナを起動させた後、次のコンテナを起動させるまでにどれくらい
(秒)
待つかを設定します。
- lxc.start.order
- 多数の自動起動させるコンテナがある場合のコンテナの起動順を決めるのに使う整数を指定します。
- lxc.monitor.unshare
- この値が 0
でない場合、コンテナが初期化される前
(pre-start
フックが実行される前)
にマウント名前空間がホストから
unshare
されます。この機能を使う場合、スタート時に
CAP_SYS_ADMIN
ケーパビリティが必要です。デフォルト値は
0 です。
- lxc.group
- コンテナを追加したいコンテナグループ名を指定します。
複数の値を設定でき、複数回指定することもできます。
設定されたグループは、関連する一連のコンテナを起動させるために使われます。
自動起動とシステムブート¶
コンテナはいくつでもグループに属することができ、全く属さないことも可能です。特別なグループが
2 つ存在します。1 つは
NULL
グループです。これはどのグループにも属さないコンテナです。もう
1 つは "onboot"
グループです。
LXC
サービスが有効になった状態でシステムがブートすると、最初に
"onboot"
グループのメンバーである
lxc.start.auto == 1
が設定されたコンテナを起動しようとします。起動は
lxc.start.order
の順に起動します。
lxc.start.delay
が指定されている場合、現在対象となっているコンテナに初期化の時間を与え、ホストシステムの負荷を低減するために、次のコンテナを開始させるまでに遅延時間を与えます。
"onboot"
グループのメンバーが開始した後、LXC
システムは lxc.start.auto == 1
が設定された、どのグループのメンバーでもない
(NULL グループの)
コンテナのブートを
onboot
グループのコンテナと同様に開始します。
コンテナの環境変数¶
コンテナに環境変数を渡したい場合
(環境変数はコンテナの
init
とその子孫全てで利用可能です)、
lxc.environment
パラメータがその用途に使えます。
機微 (センシティブ)
な情報を渡さないように注意が必要です。そのような情報を持たないコンテナ内のプロセスでこれらの環境変数が利用可能になってしまいます。環境変数は常に
/proc/PID/environ
経由で利用可能になります。
この設定項目は、設定したい環境変数ごとに
1
度ずつ、何度でも指定できます。
- lxc.environment
- コンテナに渡したい環境変数を指定します。
例:
lxc.environment = APP_ENV=production
lxc.environment = SYSLOG_SERVER=192.0.2.42
以下に紹介するいくつかの例に加えて、他の設定例が
/usr/share/doc/lxc/examples にあります。
ネットワーク¶
この設定は、片方をブリッジである
br0 と接続される veth
ペアデバイスを使うコンテナを設定します
(ブリッジは管理者によりあらかじめシステム上に設定済みである必要があります)。
仮想ネットワークデバイスは、コンテナ内では
eth0
とリネームされます。
lxc.utsname = myhostname
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.hwaddr = 4a:49:43:49:79:bf
lxc.network.ipv4 = 1.2.3.5/24 1.2.3.255
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
UID/GID のマッピング¶
この設定は、コンテナ内のユーザとグループ両方の
id 0-9999
の範囲を、ホスト上の
100000-109999
へマッピングします。
lxc.id_map = u 0 100000 10000
lxc.id_map = g 0 100000 10000
CONTROL GROUP¶
この設定は、アプリケーションのための
control group
をいくつか設定します。
cpuset.cpus は定義された cpu
のみ使用できるように制限します。
cpus.share は、control group の (cpu)
優先度を指定します。
devices.allow
は、特定のデバイスを使用可能にします。
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw
複雑な設定¶
この例は、control group
を使って、複雑なネットワークスタックを作成し、新しいホスト名を指定し、いくつかの場所をマウントし、ルートファイルシステムを変更するような複雑な設定を示します。
lxc.utsname = complex
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.hwaddr = 4a:49:43:49:79:bf
lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597
lxc.network.ipv6 = 2003:db8:1:0:214:5432:feab:3588
lxc.network.type = macvlan
lxc.network.flags = up
lxc.network.link = eth0
lxc.network.hwaddr = 4a:49:43:49:79:bd
lxc.network.ipv4 = 10.2.3.4/24
lxc.network.ipv4 = 192.168.10.125/24
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596
lxc.network.type = phys
lxc.network.flags = up
lxc.network.link = dummy0
lxc.network.hwaddr = 4a:49:43:49:79:ff
lxc.network.ipv4 = 10.2.3.6/24
lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3297
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw
lxc.mount = /etc/fstab.complex
lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
lxc.rootfs = /mnt/rootfs.complex
lxc.cap.drop = sys_module mknod setuid net_raw
lxc.cap.drop = mac_override
SEE ALSO¶
chroot(1),
pivot_root(8),
fstab(5)
capabilities(7)
SEE ALSO¶
lxc(7),
lxc-create(1),
lxc-copy(1),
lxc-destroy(1),
lxc-start(1),
lxc-stop(1),
lxc-execute(1),
lxc-console(1),
lxc-monitor(1),
lxc-wait(1),
lxc-cgroup(1),
lxc-ls(1),
lxc-info(1),
lxc-freeze(1),
lxc-unfreeze(1),
lxc-attach(1),
lxc.conf(5)
Daniel Lezcano <daniel.lezcano@free.fr>