#きょうのsystemd : machinectlにブロックデバイスをイメージとして認識させられるように(なるはず)
LennartがnspawnについてMLに投稿していた件について、今朝調べていたら、動きがあったことがわかったので翻訳。 GPTイメージの話も興味深い。
[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
やぁ、
systemd-nspawnでLUKSで暗号化されたLVを使う正しい方法を探している。
"containername" と名付けたLVを用意していて、これはLUKSで暗号化されている。 で、次のコマンドを使って、コンテナを起動させた。
systemd-nspawn --boot --image=/dev/vg/containername
LUKSのパスフレーズの入力が求められて、コマンドライン上はうまく動いているように見える。
だけど、ちょっと質問がある。
1) パーティションを使わなかったり、ファイルシステムを使わない場合に比べて、単一パーティションのGPTを使うメリットってあるんだろうか?
2) machinectl list-imagesがLVにあるイメージを検出しないんだ。/var/lib/machinesにあるイメージは(auto)mountされるものだと思ってるんだけど?
3) これ(訳注: LVをnspawnのイメージとして起動させること)を起動時に有効にするのはどうするのがベストだろうか? "machinectl enable"は動かなかった。というのも、どのイメージを使うのか認識できないみたいなんだ。イメージから起動するnspawnコンテナのsystemd unitファイルの例ってあるの?
Thanks,
-- M
Lennartの回答。
[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
(引用省略) (訳注: 1について)
イメージの分析ロジックはどちらも取り扱えるよ。 GPTを使う方法が少しだけ良いと思うね。というのも、rootパーティションをそれとマークすることができるし、そのイメージに適したCPUアーキテクチャの情報も同梱することができる(し、nspawnがそこから--personality= オプションを引っ張ることができる)から。 つまり、この方法を使えば、より多くの情報を見つけることができ、nspawnに適したイメージは簡単にそういうものだと見分けが付くんだ。 そして、もちろん、同じイメージの中に複数のパーティションをもたせることだってできる。 例えば、単一のイメージの中に、読み出し専用のsquashfsな/usrに書き込み可能な/homeを組み合わせたりってことができる。 言い忘れてたけど、GPTを使うことで、KVM(や物理システム)とnspawnとでほとんどおんなじ方法でブートさせられるイメージを作ることができる。
もし、これらの特徴、つまり、見つけやすさやアーキテクチャのサポート、複数パーティション、KVMとの互換性、に関心がないのなら、GPTなしのほうがいいかもね。
(ところで、mkosiを使うと、GPTの特徴の恩恵を受けたイメージを簡単に作ることができるよ。)
(引用省略) (訳注: 2について)
/var/lib/machinesでイメージを利用できないなら、そこにマウントするか、シンボリックリンクを張れば、動くはずだよ。
Lennart
-- Lennart Poettering, Red Hat
でも、動かなかったようで、
[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
(訳注: 1について)
オーライ、納得したよ。
(引用省略) (訳注: 2について)
LVブロックデバイス(/dev/vg/containername - こいつはGPTを含んでる)へのシンボリックリンクを/var/lib/machinesに作ってみたよ。 "containername"や"containername.raw"って名前でシンボリックリンクを作ってみた。 でも、"machinectl list-images -a"はどうやら、このイメージをどの方法でも見つけられないみたいだ。 ところで、使ってるのはDebian stretchのsystemd 234だ。
/var/lib/machinesでイメージを利用できないなら、そこにマウントするか、シンボリックリンクを張れば、動くはずだよ。
できれば、イメージをマウントするのは避けたいな。GPTパーティションを手動で検出させたり、LUKSを解除したり、などなどは避けたいし、ホストにコンテナのデータを不必要に見せることもしたくないんだ。 でも、どうやら、自分が張ったシンボリックリンクがおかしいようだ。
-- M
Lennartの返答。どうやら、ブロックデバイスは認識できないらしい。
[systemd-devel] systemd-nspawn/machinectl with LUKS/LVM
(引用省略)
あー、ふーむ。目的のものはデバイスファイル?
あぁ、忘れてたけど、イメージはブロックデバイスだったんだ。 ブロックデバイスを使うにはサポートがいくつか足りないんだ。 /var/lib/machinesに入れられるのは、ディレクトリやサブボリューム、rawファイルに今のところ限られていて、ブロックデバイスはサポートしていないんだ。 でも、ブロックデバイスのサポートを追加するのは簡単でもある。 RFE*1バグとしてgithubにこのことを報告してもらえるかな?
Lennart
-- Lennart Poettering, Red Hat
というわけで、RFEがまとめられた。
RFE: allow symlinks to block devices in /var/lib/machines · Issue #6990 · systemd/systemd · GitHub
で、この件について機能強化したのが次のマージリクエスト。
昨日にマージされたみたい。ただ、xenial(amd64)の自動テストでコケてるのが気になるけど、次のリリースまでにはmachinectlがブロックデバイスをイメージとして取れるんじゃないかな。
*1:Request for enhancement: 機能強化要求
