Infinite Debian - Platform for mass-producing system every second
•
8 likes•1,768 views
Starting from standard install and various "Debian internal" for mass-installation system, the talk goes on to describe generic "instant system generation" which shortens turnaround time from 10s of minutes to seconds. All based on Debian. Prepared for kickstart meetup of FukuokaDebian.
![d-i [+ preseeding] の中身
１． initramfs 環境として起動
２． init は /sbin/debian-installer* を
実行（これ＋ rescue console 用意）
３． /sbin/d-i は preseeding file を
同梱ファイルや指定 URL からロード
４． initrd 同梱 +DL したパッケージの
「普通」の apt-get/dpkg 処理をする
※ 「普通」といっても initrd 同梱分はサイズ削減のため udeb というサイズ縮小された deb ベース](https://image.slidesharecdn.com/infinite-debian-mass-production-120218080754-phpapp02/85/Infinite-Debian-Platform-for-mass-producing-system-every-second-28-320.jpg)
![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 # このパッケージも入れる](https://image.slidesharecdn.com/infinite-debian-mass-production-120218080754-phpapp02/85/Infinite-Debian-Platform-for-mass-producing-system-every-second-44-320.jpg)
Infinite Debian - Platform for mass-producing system every second
- 1. Debian サーバ量産工場 ～ ISO install から量産への道～ 第 0 回 福岡 Debian 勉強会 @tyamadajp
- 2. 本日の目標 明日から 『それ、ぽちっとな』 で何台でもシステム作れる人になる！ ※ ただし Debian に限る（嘘
- 4. まず質問 １．（半）自動構築、してますか？ ２．何ベースで、してますか？ ・ dd/tar 系 ・ kickstart/preseeding/jumpstart 系 ・ vm/container 系 ・ XaaS 系
- 6. 今日の全体像 多重化手法の輪 ファイルシステム関連 ブロックデバイス関連 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 各手法が実現される
- 8. ここで一呼吸
- 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 方法は応用できる。
- 13. ここで一呼吸
- 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 へ |~| そのことを |` ー‐ / ` ー―― H<, 〉 |=| どうか諸君らも | / ､ l|__ ノｰ | 思い出していただきたい . | ／ ` ー ~ ′ ＼ .| ヾ . ニ | ヽ | ｌ 下王 l 王 l 王 l 王 l ヲ｜ | ヾ _,| ＼ つまり・・・・ . | ≡ | `l ＼ __ インプリがその気になれば ! 、 _,,..-'′ ／ l | ~''' 設定が本当に利用されるのは ‐''" ￣ | `i ｰ -..,,, ＿ ,,,,,....-‐'''" ／ | | 10 年後 20 年後ということも -―| | ＼ ／ | | 可能だろう・・・・・・・・・・ということ・・・・！ | | ＼ ／ | | PXE ブート位は問題ないですが、その他の多くは クライアント側はデフォルトでスルーなので、各種の 設定配信に使うなら DHCP client script を書いて 自分ですり合わせになる…はず（書ける実装だとして）
- 16. ここで一呼吸 ( また後で netboot に戻ります )
- 17. netinst と debian installer (d-i) １．中身： menu 付き apt-get ２．つまり、 netinst だから何が特別、 という違いは一切ない ３．「インストーラ」アプリというよりも 「ただのパッケージ」の集合体 ４．つまり、 apt-get/dpkg の自動処理 ＝自動インストーラの実現
- 18. debian package のライフサイクル ＃実コードの抜粋でもなく、実行内容のイメージです ＃前後のフック処理と依存解析が注目ポイント。 install() { install $(find_depends $package) tar xf mypackage.meta.tar -C / $package.preinst (install|upgrade|...) tar xf mypackage.data.tar -C / $packge.postinst (configure|...) } remove() { $package.prerm (remove|...) rm … $package.postrm (remove|...) if (autoremove) remove $(find_unused $package) }
- 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 によって実現されること １． UI 独立 → frontend を「 gtk 」や「 readline 」と 指定するだけでデスクトップ用や リモート管理用インストーラに。 ２．構成情報のパラメタライズ → DB に入っている情報こそが パッケージレベルでの設定 ３．日常利用から自動インストールまで すべて同じコードで実現される
- 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] の中身 １． initramfs 環境として起動 ２． init は /sbin/debian-installer* を 実行（これ＋ rescue console 用意） ３． /sbin/d-i は preseeding file を 同梱ファイルや指定 URL からロード ４． initrd 同梱 +DL したパッケージの 「普通」の apt-get/dpkg 処理をする ※ 「普通」といっても initrd 同梱分はサイズ削減のため udeb というサイズ縮小された deb ベース
- 29. まとめ １． Debian の d-i もパッケージも同じ *.deb + debconf という枠組みで、 見せ方が違うだけ ２． debconf を活用することで、対話 インストーラも自動インストーラも （勝手？に）実現される ３． d-i/preseed を使わないとしても、 debconf はパッケージ開発者として 押さえるべき知識
- 30. ここで一呼吸
- 32. 残念なお知らせ な、なんだってー
- 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 の３本柱 １．どの機材を FAI NFSroot 環境で 起動させるかの PXE 構成の切替 ２． NFSroot 後に構築スクリプトを どう走らせるか、という規約 ３．自動パーティションツールなどの 支援ツール （パッケージングではなく）起動環境の制御、というメタレベルで 管理するので、 OS に関係なく構築できる。 もちろん、中で apt-get + debconf にリレーして協調もできる。
- 36. 余談： chef+crowbar について ・最近出てきた自動構築・運営ツール ・概ね fai++++- = chef + crowbar → crowbar = PXE 起動管理 → chef = 導入・更新管理 ・簡潔になるよう、記述方法などまで 踏み込んでいる。 Ruby で書くので 記述力も高い。 ・でも使ってないので言及に留め省略
- 37. ここで一呼吸
- 38. 残念なお知らせ fai もオワコン
- 39. 残念なお知らせ な、なんだってー
- 41. debootstrap: 超手軽 chroot 構築ツール # debootstrap sid sid64 http://cdn.debian.or.jp/debian # chroot ./sid64 /bin/sh 応用： １．常に Debian USB 環境を持ち歩く ２． mkfs /dev/sda1 ３． mount /dev/sda1 /target ４． debootstrap sid /target ５． chroot sid apt-get install linux- image ... ６． extlinux-install /dev/sda
- 42. multistrap - better debootstrap debootstrap の弱点 １．リポジトリ指定が１つだけ ２．パッケージ指定ができない そこで multistrap ： # multistrap -a i386 -d sid32 -f sid.conf ※ 複数リポジトリを CLI 指定するのは大変なので、設定ファイル方式になっている 元々は emdebian という組込向けの 構成を自動構築するために作られた debian+α のカスタム版作成に強力
- 43. ここで一呼吸
- 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 # このパッケージも入れる
- 46. つまり… ・手軽だけど、結局分単位の時間が ・真に手軽というなら秒単位で欲しい → 使い捨て環境を量産したい → 実験実験実験 → 構成固まったら、またそれを量産
- 47. インストール、しなくてよくね？ 「コピー」が欲しいのか、「環境」が欲しいのか、の問題 → そこで多重化技術 環境 C 差分 C 差分 B 環境 B 差分 A 環境 A ベース環境 ブロックレベル・スナップショット、 ファイルシステム・スナップショット、 非スナップショット、の３方式がある
- 48. 多重化方式での量産 方法＃１ # qemu-img -f qcow2 -o backing_file=sys.img copy.img # kvm -hda clone.img 方法＃２ # btrfs sub snap sys copy # kvm -hda clone.img 方法＃３ # 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. まだまだあります 方法＃４ # 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 ＃まだ微妙だけど期待中 ・・・ていうか、「クローン環境の名前が初登場なら、自動で 作って起動すればよくね？」→やってみた 方法＃５６７８ # 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 秒くらいで環境量産などができる＞実験に便利
- 50. ここで一呼吸 （デモできます）
- 51. ここまでの流れ １．ブート、インストール、稼動の 正統的な流れをまとめた ２．正統的な自動導入・展開方法を まとめた。 initrd 式とフル環境式が。 ３． Debian では日常のパッケージングで 自動導入や多様な環境への対応が できるような設計が採用されてること
- 52. ここまでの流れ ４．正統的な方法は 10 分単位の時間が かかり、現代のインストール厨には とても耐えられないこと ５．軽量構築ツール、 debootstrap の 素晴らしさと組み込み由来の multistrap お勧めな話 ６．それでも分単位の時間で、我々の ニーズには応えられない事（誰？）
- 55. まだまだ改良点はある １．環境が秒単位で用意できるのに、 起動が 30s とかほとんどの待ち時間を 占めるのは我慢できないなぁ ２．多重化って IO が元環境に戻るから、 性能が欲しい時は使いにくいなぁ
- 57. BIOS は２０世紀のオワコン BIOS → LinuxBIOS(coreboot) へようこそ ・ BIOS が Linux なら最初から Linux ・ハードウェアもオープンにしよう！ ・実績としては 10s 以下で X まで上がる ・オモチャではなく、意外に組込みから ハイエンドボードまでサポート 起動後に「自分の Linux 環境」をさらにロードするので その時間はかかるが、 PXE BIOS より圧倒的に速い
- 58. init も２０世紀のオワコン init → parallel init, upstart, systemd ・要は並列で /etc/rc*.d/* 実行 ・ systemd はさらにアグレッシブ → デマンドベース並列起動 → init + inetd + cron + udev 位 個人的に systemd はかなり期待中。 が、クロスプラットフォーム性も必要な Debian だと デフォルトになるのは現状だと難しい（パッケージはある）
- 59. そもそも起動しなければよい kernel → kexec boot ・カーネルで kernel+initrd をロード ・当然超速い（ coreboot とペアで使う 事例がある） ・ nfsroot=sv1:/foo から sv2:/bar に 渡り鳥するような荒業ができる 本来はカーネルメモリダンプを採取するためのツールとして 開発された
- 60. コピーせずにコピーが欲しい 方向＃１ ・バックグラウンド同期 ・要は md/raid1 over network 。 裏でアイドルタイムにコピーが進む 方向＃２ ・ブロック分散 ・ 100GB のコピーも、 1GB ずつ分散して 保持すれば 100 並列なので 1/100 の 時間で完了 ※ このあたりは各所で開発途上
- 61. Why Debian? 今日の内容のほとんどは Debian に 標準で入っている機能で実現できる ・元々サーバー構築・運用関係が充実 ・マルチアーキテクチャなのでクロス 環境構築ツールという面でも強い →別環境を生産するという意味で共通 ・最近 Ubuntu/Debian で先に出る ケースが増えてる、ような？ なので、 Debian オススメ。 とりあえず ls 位の気軽さで量産すると 気持ちいいのは保証できます。