Contenu connexe Similaire à Infinite Debian - Platform for mass-producing system every second (20) Plus de Taisuke Yamada (20) Infinite Debian - Platform for mass-producing system every second6. 今日の全体像
多重化手法の輪
ファイルシステム関連 ブロックデバイス関連
aufs initramfs
unionfs NFS iSCSI nbd
btrfs qcow2
snapshot virtfs etc, etc AoE
etc, etc
dm lvm
統合管理の輪
Debian 方面の輪 ブートロード手法の輪
debootstrap chef crowbar PXE inetboot
preseeding
netinst fai kexec
coreboot
media debconf
install
ランタイムの輪
dump 正直バラバラだが、
dd container: lxc, etc
tar vm: kvm, xen, ... 様々な組み合わせで
原始手法の輪 hardware 各手法が実現される
9. ブート、インストール、稼動
メモリ空間 メモリ空間
kernel +
initramfs
boot loader boot loader
メモリ空間 メモリ空間
kernel + kernel +
initramfs initramfs
boot loader boot loader
10. ブート、インストール、稼動
メモリ空間 メモリ空間
kernel +
initramfs
boot loader boot loader
メモリ空間 メモリ空間
プロセス
kernel + / kernel +
initramfs initramfs
boot loader boot loader
11. ブート、インストール、稼動
メモリ空間 メモリ空間
kernel +
initramfs
boot loader boot loader
メモリ空間 メモリ空間
プロセス インストーラ プロセス
kernel + / kernel +
initramfs initramfs
boot loader boot loader
12. netboot & netinst
メモリ空間
netboot=
ローダやシステムを
kernel +
initramfs
ネットワークの先から取得する
boot loader netinst=
インストーラが構築システムを
ネットワークの先から取得する
メモリ空間
インストーラ 当然、 netboot した後で local
media install することも可能。
kernel +
意味なさそうだが、一部だけ
initramfs ローカルメディア依存にする
boot loader
方法は応用できる。
14. netboot - 基本形
DHCP TFTP DHCP TFTP
1. DHCP DISCOVER 1. DHCP DISCOVER
2. ( サーバ応答 ) 2. DHCP OFFER
3. DHCP REQUEST bootpc 3. DHCP REQUEST bootpc
4. (サーバ応答) /w PXE 4. DHCP ACK /w PXE
DHCP OPTIONS
DHCP TFTP
1: subnet mask (=1,255.255.255.0)
3: default router (=3,10.254.8.2) TFTP GET
6: DNS server (=6,10.254.8.2)
...
66: tftp server (=66,"1.2.3.4") bootpc
67: tftp bootfile (=67,"pxelinux.0") /w PXE
...
15. 余談: DHCP OPTION について
____________
ヾミ || || || || || || || ,l,,l,,l 川〃彡 |
V~~''- 山┴ ''''""~ ヾニニ彡 | 設定できる・・・・・・!
/ 二ー― '' 二 ヾニニ┤ できるが・・・
<'-.,  ̄ ̄ _,,,..-‐ 、 〉ニニ | 今回 まだ それが使用される時と
/"''- ニ ,‐l l`__ ニ -‐'''""` / ニ二 | 使用方法の指定まではしていない
| == =、 ! ` = ==== 、 l = lべ =|
. | ` ー゚‐ '/ ` ー‐゚― ' l.=l へ |~| そのことを
|` ー‐ / ` ー―― H<, 〉 |=| どうか諸君らも
| / 、 l|__ ノー | 思い出していただきたい
. | / ` ー ~ ′ \ .| ヾ . ニ | ヽ
| l 下王 l 王 l 王 l 王 l ヲ| | ヾ _,| \ つまり・・・・
. | ≡ | `l \ __ インプリがその気になれば
! 、 _,,..-'′ / l | ~''' 設定が本当に利用されるのは
‐''"  ̄ | `i ー -..,,, _ ,,,,,....-‐'''" / | | 10 年後 20 年後ということも
-―| | \ / | | 可能だろう・・・・・・・・・・ということ・・・・!
| | \ / | |
PXE ブート位は問題ないですが、その他の多くは
クライアント側はデフォルトでスルーなので、各種の
設定配信に使うなら DHCP client script を書いて
自分ですり合わせになる…はず(書ける実装だとして)
17. netinst と debian installer (d-i)
1.中身: menu 付き apt-get
2.つまり、 netinst だから何が特別、
という違いは一切ない
3.「インストーラ」アプリというよりも
「ただのパッケージ」の集合体
4.つまり、 apt-get/dpkg の自動処理
=自動インストーラの実現
19. debconf - d-i & package の中の人
パッケージインストールのフロー
*.(preinst|postinst)
*.(prerm|postrm)
debconf
frontend
パラメータを
debconf API で
参照すると… パラメータに
debconf
API/script 基づいて
ファイルの配置や
設定生成を行う
DB になければ debconf
UI 確認が出て… database
もしこれが全部データ登録済みの
状態で apt-get/dpkg したならば・・・?
20. debconf によって実現されること
1. UI 独立
→ frontend を「 gtk 」や「 readline 」と
指定するだけでデスクトップ用や
リモート管理用インストーラに。
2.構成情報のパラメタライズ
→ DB に入っている情報こそが
パッケージレベルでの設定
3.日常利用から自動インストールまで
すべて同じコードで実現される
21. debconf の使い方
# apt-get install debconf-utils
# debconf-get-selections | less
# debconf-get-selections –installer | less
22. debconf の使い方
# apt-get install debconf-utils
# debconf-get-selections | less
# debconf-get-selections –installer | less
あれ?見たことがあるような・・・?
23. debconf の使い方
# apt-get install debconf-utils
# debconf-get-selections | less
# debconf-get-selections –installer | less
あれ?見たことがあるような・・・?
# dpkg –-get-selections
# dpkg --set-selections
前者は「どのパッケージがどういう構成で入れられたか」
後者は「どのパッケージが導入されているか」
前者の debconf レベルの情報を加味することで、インストーラ
レベルでの同一構成を再現する
24. debconf configuration
…
tzdata tzdata/Zones/Etc select UTC
# Generate a new configuration file for OpenSSH?
openssh-server ssh/new_config boolean true
# New certificates to activate:
# Choices:
ca-certificates ca-certificates/new_crts multiselect
# for internal use
x11-common x11-common/xwrapper/actual_allowed_users
string console
# Do you want to risk killing active SSH sessions?
openssh-server ssh/use_old_init_script boolean true
25. using debconf, harder
debconf DB へのインポート
debconf-set-selections < config
debconf DB へのアクセス
#!/bin/sh
. /usr/share/debconf/confmodule
db_get mypackage/param
db_set mypackage/param "value"
db_input 'foo/bar' || true
...
API は sh/confmodule(3) と perl/Debconf::Client::ConfModule(3)
ただし激しく undocumented なので /var/lib/dpkg/info/ 見ると
もっと参考にはよい( mysql-server のが勉強になった)。
26. using debconf, harder
debconf を使ってコマンドを自動実行
# debconf -o dbname cmd... # 呼び方
# debconf -o d-i /usr/bin/main-menu # 例: d-i の本体
対応コマンドは DebianPolicy の stdio ベースの debconf
protocol をサポートすることで、自分のクエリに debconf が
応答してくれるようになる。 debconf は DB になければ
指定のフロントエンド UI で対話確認をする。
27. debian preseeding
「 debconf DB を外部から流し込んで d-i を実行する」
作り方
# debconf-get-selections -–installer > myseed.cfg
# debconf-get-selections > myseed.cfg
使い方(ブートロード時に指定)
kernel …/linux
initrd …/initrd.gz (debian installer 用 initrd)
append auto=true url=http://.../path/to/myseed.cfg
※ パスワードなどは保存されてないので、多少編集は必要
28. d-i [+ preseeding] の中身
1. initramfs 環境として起動
2. init は /sbin/debian-installer* を
実行(これ+ rescue console 用意)
3. /sbin/d-i は preseeding file を
同梱ファイルや指定 URL からロード
4. initrd 同梱 +DL したパッケージの
「普通」の apt-get/dpkg 処理をする
※ 「普通」といっても initrd 同梱分はサイズ削減のため udeb というサイズ縮小された deb ベース
29. まとめ
1. Debian の d-i もパッケージも同じ
*.deb + debconf という枠組みで、
見せ方が違うだけ
2. debconf を活用することで、対話
インストーラも自動インストーラも
(勝手?に)実現される
3. d-i/preseed を使わないとしても、
debconf はパッケージ開発者として
押さえるべき知識
33. ・・・と煽ってみましたが、つまり
・ preseeding や kickstart のような
固有方式は使わなくなった(自分)
・特に Debian は環境作るだけなら
はるかに軽量な方式が多数
・本格的なほうだと fai (…は 10 年前
からありますが)やその後継的な
クロスアーキテクチャなものが
34. FAI: Fully Automatic Install
メモリ空間 メモリ空間
プロセス インストーラ プロセス
kernel + / kernel +
initramfs initramfs
boot loader boot loader
こちらが d-i/preseeding 方式。 こちらが FAI &仲間の方式。
initramfs の中で頑張る。
インストーラが頑張るより
コンパクト化しつつ多様な インストール済みの環境で
環境に対応するため、 頑張ればいいじゃない
Debian の仕組みをフル活用
している(が、それが仇となる) 的に NFSroot して好きにする
35. FAI の3本柱
1.どの機材を FAI NFSroot 環境で
起動させるかの PXE 構成の切替
2. NFSroot 後に構築スクリプトを
どう走らせるか、という規約
3.自動パーティションツールなどの
支援ツール
(パッケージングではなく)起動環境の制御、というメタレベルで
管理するので、 OS に関係なく構築できる。
もちろん、中で apt-get + debconf にリレーして協調もできる。
41. debootstrap: 超手軽 chroot 構築ツール
# debootstrap sid sid64 http://cdn.debian.or.jp/debian
# chroot ./sid64 /bin/sh
応用:
1.常に Debian USB 環境を持ち歩く
2. mkfs /dev/sda1
3. mount /dev/sda1 /target
4. debootstrap sid /target
5. chroot sid apt-get install linux-
image ...
6. extlinux-install /dev/sda
42. multistrap - better debootstrap
debootstrap の弱点
1.リポジトリ指定が1つだけ
2.パッケージ指定ができない
そこで multistrap :
# multistrap -a i386 -d sid32 -f sid.conf
※ 複数リポジトリを CLI 指定するのは大変なので、設定ファイル方式になっている
元々は emdebian という組込向けの
構成を自動構築するために作られた
debian+α のカスタム版作成に強力
44. sid.conf
[general] # セクション名は case-insensitive
cleanup=true # 構築ツリー中の *.deb cache を残す
noauth=true # キーサインのチェックをするかどうか
bootstrap=sid local # 構築に使うリポジトリ
aptsources=sid local # /etc/apt/sources.list.d/* に残す
[sid]
suite=sid
source=http://my.repo.local:9999/debian
keyring=debian-archive-keyring
[local]
suite=sid
components=local # dists/(suite)/(components)/ を使う
source=http://my.repo.local/debian
packages=lx-image-3.2.5-tai-4f364f2e # このパッケージも入れる
48. 多重化方式での量産
方法#1
# qemu-img -f qcow2 -o backing_file=sys.img copy.img
# kvm -hda clone.img
方法#2
# btrfs sub snap sys copy
# kvm -hda clone.img
方法#3
# mkdir -p copy/rw
# ln -s ../sys copy/ro
# mount -t aufs -o br:copy/rw:copy/ro=ro none copy
# lxc-start … -slxc.rootfs=”/to/copy”
49. まだまだあります
方法#4
# mkdir -p copy/rw
# ln -s ../sys copy/ro
# mount -t aufs -o br:copy/rw:copy/ro=ro none copy
# kvm -virtfs local,path=/to/copy,mount_tag=foo,
security_model=none #まだ微妙だけど期待中
・・・ていうか、「クローン環境の名前が初登場なら、自動で
作って起動すればよくね?」→やってみた
方法#5678
# lxc-ex-clone sd32 sd32-a
# kvm-nfs /n/sid32{a,b,c,d,e,f,g}
# kvm-virtfs /n/sid64{a,b,c,d,e,f,g}
まだ完全自動でない部分を残してますが、一行コマンドで
30 秒くらいで環境量産などができる>実験に便利
57. BIOS は20世紀のオワコン
BIOS
→ LinuxBIOS(coreboot) へようこそ
・ BIOS が Linux なら最初から Linux
・ハードウェアもオープンにしよう!
・実績としては 10s 以下で X まで上がる
・オモチャではなく、意外に組込みから
ハイエンドボードまでサポート
起動後に「自分の Linux 環境」をさらにロードするので
その時間はかかるが、 PXE BIOS より圧倒的に速い
58. init も20世紀のオワコン
init
→ parallel init, upstart, systemd
・要は並列で /etc/rc*.d/* 実行
・ systemd はさらにアグレッシブ
→ デマンドベース並列起動
→ init + inetd + cron + udev 位
個人的に systemd はかなり期待中。
が、クロスプラットフォーム性も必要な Debian だと
デフォルトになるのは現状だと難しい(パッケージはある)
61. Why Debian?
今日の内容のほとんどは Debian に
標準で入っている機能で実現できる
・元々サーバー構築・運用関係が充実
・マルチアーキテクチャなのでクロス
環境構築ツールという面でも強い
→別環境を生産するという意味で共通
・最近 Ubuntu/Debian で先に出る
ケースが増えてる、ような?
なので、 Debian オススメ。
とりあえず ls 位の気軽さで量産すると
気持ちいいのは保証できます。