Infinite Debian - Platform for mass-producing system every second

Debian サーバ量産工場～ ISO install から量産への道～

@tyamadajp

第 0 回福岡 Debian 勉強会

本日の目標

明日から

　　　『それ、ぽちっとな』

で何台でもシステム作れる人になる！

※ ただし Debian に限る（嘘

禁則事項

　　　『それ、クラウドででき（ ry 』

１．ただ使うのと、何ができるか知って　　使うのは全然別の話

２．「よいパッケージ・システム」を作る　　知識の集大成なので応用できる

３．面白いは正義

まず質問

１．（半）自動構築、してますか？

２．何ベースで、してますか？　・ dd/tar 系　・ kickstart/preseeding/jumpstart 系　・ vm/container 系　・ XaaS 系

今日の主題

１．いかに速く「構築」できるか　　→高速な「展開」　　→高速な「稼動」

２．いかに楽に「構築」できるか　　→作業の自動化　　→作業の不要化

３．いかに楽に「再現」できるか　　→構成のデータ化　　→構成の非データ化

今日の全体像

mediainstall

netinst

PXE

NFS

inetbootchef

initramfs

corebootkexec

virtfs

fai

snapshotbtrfs

unionfs

dd

dm

preseeding

aufs

crowbar

原始手法の輪

多重化手法の輪

ブートロード手法の輪Debian 方面の輪

ファイルシステム関連

tar

dump

debconf

iSCSI nbd

AoE

ブロックデバイス関連

qcow2

lvm etc, etcetc, etc

debootstrap

container: lxc, etcvm: kvm, xen, ...

統合管理の輪

hardware

ランタイムの輪正直バラバラだが、様々な組み合わせで各手法が実現される

今日の概要

１．メディアベースのインストールから、　　量産工場化まで順を追って要素を　　足し引きしてゆく

２．「導入手法」としての評価とは別に　　その知識が Debian 等のシステムの　　一般的な理解に繋がることを示す

ここで一呼吸

ブート、インストール、稼動メモリ空間

boot loader

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs


boot loader

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

boot loader

プロセス

/


boot loader

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

boot loader

プロセスプロセスインストーラ

/

netboot & netinst

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

インストーラ

netboot=ローダやシステムをネットワークの先から取得する

netinst=インストーラが構築システムをネットワークの先から取得する

当然、 netboot した後で localmedia install することも可能。意味なさそうだが、一部だけローカルメディア依存にする方法は応用できる。

ここで一呼吸

netboot - 基本形

bootpc/w PXE

DHCP TFTP

bootpc/w PXE

DHCP TFTP

1. DHCP DISCOVER2. (サーバ応答 )3. DHCP REQUEST4. （サーバ応答）

1. DHCP DISCOVER2. DHCP OFFER3. DHCP REQUEST4. DHCP ACK

DHCP OPTIONS

bootpc/w PXE

DHCP TFTP

TFTP GET1: subnet mask (=1,255.255.255.0)3: default router (=3,10.254.8.2)6: DNS server (=6,10.254.8.2)...66: tftp server (=66,"1.2.3.4")67: tftp bootfile (=67,"pxelinux.0")...

　　　　＿＿＿＿＿＿＿＿＿＿＿＿　　　　ヾミ || || || || || || || ,l,,l,,l 川〃彡 |　　　　　 V~~''- 山┴ ''''""~ 　　ヾニﾆ彡 | 　　　　　　　設定できる・・・・・・！　　　　 / 　二ー― ''二　　　　　ヾﾆニ┤　　　　　　できるが・・・　　　 <'-., 　　￣￣　　 _,,,..-‐ ､　〉ニﾆ | 　　　　　　　今回　まだ　それが使用される時と　　　 /"''- ﾆ ,‐l 　　 l`__ ニ -‐'''""` /ニ二 | 　　　　　　　使用方法の指定まではしていない　　　 | 　 ==＝､ ! 　　 `＝ ==== ､　　 l = ｌべ =|. 　　　 | `ーﾟ‐ '/ 　　 `ー‐ﾟ― ' 　　 l.=l へ |~| 　　　　　そのことを　　　 |`ー‐ / 　　　　 `ー――　　 H<, 〉 |=| 　　　　　　　どうか諸君らも　　　 | 　　 / 　　　､　　　　　　 l|__ ノｰ | 　　　　　　　思い出していただきたい. 　　　 | ／`ー　 ~ 　′　　＼　　　 .| ヾ .ニ | ヽ　　　 | ｌ　下王 l王 l王 l王 lヲ｜　　 | 　ヾ _,| 　＼　　　つまり・・・・. 　　 | 　　　　≡　　　　　　　　　 | 　　 `l 　　＼ __ 　　　インプリがその気になれば　　　　 ! 、　　　　　　　　　　 _,,..-'′ ／ l 　　　 | 　 ~''' 　設定が本当に利用されるのは‐''"￣ | 　 `i ｰ -..,,,＿ ,,,,,....-‐'''" 　　／　 | 　　　 | 　 10年後　 20年後ということも　 -―| 　　 | ＼　　　　　　　　　／　　 | 　　　　 | 　　　可能だろう・・・・・・・・・・ということ・・・・！　　 | 　　 | 　＼　　　　　　／　　　 | 　　　　　 |

余談： DHCP OPTION について

PXE ブート位は問題ないですが、その他の多くはクライアント側はデフォルトでスルーなので、各種の設定配信に使うなら DHCP client script を書いて自分ですり合わせになる…はず（書ける実装だとして）

ここで一呼吸

(また後で netboot に戻ります )

netinst と debian installer (d-i)

１．中身：menu付き apt-get

２．つまり、 netinst だから何が特別、　　という違いは一切ない

３．「インストーラ」アプリというよりも　　「ただのパッケージ」の集合体

４．つまり、 apt-get/dpkg の自動処理　　＝自動インストーラの実現

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)}

*.(preinst|postinst)*.(prerm|postrm)

debconf - d-i＆ package の中の人

debconffrontend

debconfdatabase

パッケージインストールのフロー

debconfAPI/script

パラメータをdebconf API で参照すると… パラメータに

基づいてファイルの配置や設定生成を行う

DBになければUI確認が出て…

もしこれが全部データ登録済みの状態で apt-get/dpkg したならば・・・？

debconf によって実現されること

１． UI独立　　→ frontend を「 gtk 」や「 readline 」と　　　指定するだけでデスクトップ用や　　　リモート管理用インストーラに。　　

２．構成情報のパラメタライズ　　→ DBに入っている情報こそが　　　　パッケージレベルでの設定

３．日常利用から自動インストールまで　　すべて同じコードで実現される

debconf の使い方

# apt-get install debconf-utils# debconf-get-selections | less# debconf-get-selections –installer | less



あれ？見たことがあるような・・・？



あれ？見たことがあるような・・・？

# dpkg –-get-selections# dpkg --set-selections

前者は「どのパッケージがどういう構成で入れられたか」後者は「どのパッケージが導入されているか」

前者の debconfレベルの情報を加味することで、インストーラレベルでの同一構成を再現する


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 usex11-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

using debconf, harder

debconf-set-selections < config

debconf DBへのインポート

#!/bin/sh. /usr/share/debconf/confmoduledb_get mypackage/paramdb_set mypackage/param "value"db_input 'foo/bar' || true...

debconf DBへのアクセス

API は sh/confmodule(3)と perl/Debconf::Client::ConfModule(3)ただし激しく undocumented なので /var/lib/dpkg/info/見るともっと参考にはよい（ mysql-server のが勉強になった）。

using debconf, harder

# debconf -o dbname cmd... #呼び方# debconf -o d-i /usr/bin/main-menu #例： d-i の本体

debconf を使ってコマンドを自動実行

対応コマンドは DebianPolicy の stdio ベースの debconfprotocol をサポートすることで、自分のクエリに debconf が応答してくれるようになる。 debconf は DBになければ指定のフロントエンド UI で対話確認をする。

debian preseeding

「 debconf DBを外部から流し込んで d-i を実行する」

# debconf-get-selections -–installer > myseed.cfg# debconf-get-selections > myseed.cfg

作り方

kernel …/linuxinitrd …/initrd.gz (debian installer 用 initrd)append auto=true url=http://.../path/to/myseed.cfg

使い方（ブートロード時に指定）

作り方

※ パスワードなどは保存されてないので、多少編集は必要

d-i [+ preseeding] の中身

１． initramfs環境として起動

２． init は /sbin/debian-installer* を　　実行（これ＋ rescue console 用意）

３． /sbin/d-i は preseeding file を　　同梱ファイルや指定URLからロード

４． initrd同梱 +DLしたパッケージの　　「普通」の apt-get/dpkg処理をする

※ 「普通」といっても initrd同梱分はサイズ削減のため udeb というサイズ縮小された deb ベース

まとめ

１． Debian の d-i もパッケージも同じ　　 *.deb + debconf という枠組みで、　　見せ方が違うだけ

２． debconf を活用することで、対話　　インストーラも自動インストーラも　　（勝手？に）実現される

３． d-i/preseed を使わないとしても、　　 debconf はパッケージ開発者として　　押さえるべき知識　

ここで一呼吸

残念なお知らせ

preseeding はオワコン


な、なんだってー

・・・と煽ってみましたが、つまり

・ preseeding や kickstart のような　固有方式は使わなくなった（自分）

・特に Debian は環境作るだけなら　はるかに軽量な方式が多数

・本格的なほうだと fai （…は 10年前からありますが）やその後継的な　クロスアーキテクチャなものが

FAI: Fully Automatic Install

メモリ空間

boot loader

kernel +initramfs

メモリ空間

boot loader

kernel +initramfs

boot loader

プロセスプロセスインストーラ

/

こちらが d-i/preseeding 方式。initramfs の中で頑張る。

コンパクト化しつつ多様な環境に対応するため、Debian の仕組みをフル活用している（が、それが仇となる）

こちらが FAI＆仲間の方式。

　インストーラが頑張るより　インストール済みの環境で　頑張ればいいじゃない

的に NFSroot して好きにする

FAI の３本柱

１．どの機材を FAI NFSroot環境で　　起動させるかの PXE 構成の切替

２． NFSroot 後に構築スクリプトを　　どう走らせるか、という規約

３．自動パーティションツールなどの　　支援ツール

（パッケージングではなく）起動環境の制御、というメタレベルで管理するので、 OS に関係なく構築できる。もちろん、中で apt-get + debconf にリレーして協調もできる。

余談： chef+crowbar について

・最近出てきた自動構築・運営ツール

・概ね fai++++- = chef + crowbar　→ crowbar = PXE起動管理　→ chef = 導入・更新管理

・簡潔になるよう、記述方法などまで　踏み込んでいる。 Ruby で書くので　記述力も高い。

・でも使ってないので言及に留め省略

ここで一呼吸


fai もオワコン


な、なんだってー

・・・と煽ってみましたが、つまり

「特に Debian は環境作るだけなら　はるかに軽量な方式が多数」

・本当にインストールしたいですか？

・↓をするだけなら、他の方法もある　１．いかに速く「構築」できるか　２．いかに楽に「構築」できるか　３．いかに楽に「再現」できるか

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

http://cdn.debian.or.jp/debian

multistrap - better debootstrap

debootstrap の弱点１．リポジトリ指定が１つだけ２．パッケージ指定ができない

そこで multistrap ：# multistrap -a i386 -d sid32 -f sid.conf

※複数リポジトリを CLI指定するのは大変なので、設定ファイル方式になっている

元々は emdebian という組込向けの構成を自動構築するために作られたdebian+αのカスタム版作成に強力

ここで一呼吸

sid.conf

[general] # セクション名は case-insensitivecleanup=true # 構築ツリー中の *.deb cache を残すnoauth=true # キーサインのチェックをするかどうかbootstrap=sid local # 構築に使うリポジトリaptsources=sid local # /etc/apt/sources.list.d/* に残す

[sid]suite=sidsource=http://my.repo.local:9999/debiankeyring=debian-archive-keyring

[local]suite=sidcomponents=local # dists/(suite)/(components)/ を使うsource=http://my.repo.local/debianpackages=lx-image-3.2.5-tai-4f364f2e # このパッケージも入れる

しかし残念なお知らせ

そんな装備で　　　大丈夫か？

つまり…

・手軽だけど、結局分単位の時間が・真に手軽というなら秒単位で欲しい

→ 使い捨て環境を量産したい→ 実験実験実験→ 構成固まったら、またそれを量産

インストール、しなくてよくね？

「コピー」が欲しいのか、「環境」が欲しいのか、の問題

→ そこで多重化技術

ベース環境

差分 A差分B差分C

環境 C

環境B

環境 A

ブロックレベル・スナップショット、ファイルシステム・スナップショット、非スナップショット、の３方式がある

多重化方式での量産

# 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”

方法＃３

まだまだあります方法＃４

# 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秒くらいで環境量産などができる＞実験に便利

ここで一呼吸

（デモできます）

１．ブート、インストール、稼動の　　正統的な流れをまとめた

２．正統的な自動導入・展開方法を　　まとめた。 initrd式とフル環境式が。

３． Debian では日常のパッケージングで　　自動導入や多様な環境への対応が　　できるような設計が採用されてること

ここまでの流れ

４．正統的な方法は 10分単位の時間が　　かかり、現代のインストール厨には　　とても耐えられないこと

５．軽量構築ツール、 debootstrap の　　素晴らしさと組み込み由来の　　 multistrapお勧めな話

６．それでも分単位の時間で、我々の　　ニーズには応えられない事（誰？）


７．多重化技術を使うと RTTが秒単位に　　短縮して幸せなこと


しかし残念なお知らせ

そんな装備で　　　大丈夫か？

まだまだ改良点はある

１．環境が秒単位で用意できるのに、　　起動が 30s とかほとんどの待ち時間を　　占めるのは我慢できないなぁ

２．多重化って IO が元環境に戻るから、　　性能が欲しい時は使いにくいなぁ

もっと高速な起動を！

待ち時間の内容は？

　１． BIOS　２． kernel　３． init

BIOS は２０世紀のオワコン

BIOS→ LinuxBIOS(coreboot)へようこそ

・ BIOS が Linux なら最初から Linux・ハードウェアもオープンにしよう！・実績としては 10s以下で X まで上がる・オモチャではなく、意外に組込みから　ハイエンドボードまでサポート

起動後に「自分の Linux環境」をさらにロードするのでその時間はかかるが、 PXE BIOS より圧倒的に速い

init も２０世紀のオワコン

init→ parallel init, upstart, systemd

・要は並列で /etc/rc*.d/*実行・ systemd はさらにアグレッシブ

→ デマンドベース並列起動→ init + inetd + cron + udev位

個人的に systemd はかなり期待中。が、クロスプラットフォーム性も必要な Debian だとデフォルトになるのは現状だと難しい（パッケージはある）

そもそも起動しなければよい

kernel→ kexec boot

・カーネルで kernel+initrd をロード・当然超速い（ coreboot とペアで使う　事例がある）・ nfsroot=sv1:/foo から sv2:/bar に　渡り鳥するような荒業ができる

本来はカーネルメモリダンプを採取するためのツールとして開発された

コピーせずにコピーが欲しい

方向＃１・バックグラウンド同期・要は md/raid1 over network 。　裏でアイドルタイムにコピーが進む

方向＃２・ブロック分散・ 100GBのコピーも、 1GBずつ分散して　保持すれば100並列なので 1/100 の　時間で完了

※ このあたりは各所で開発途上

Why Debian?

・元々サーバー構築・運用関係が充実・マルチアーキテクチャなのでクロス　環境構築ツールという面でも強い　→別環境を生産するという意味で共通・最近Ubuntu/Debian で先に出る　ケースが増えてる、ような？

今日の内容のほとんどは Debian に標準で入っている機能で実現できる

なので、 Debianオススメ。とりあえず ls位の気軽さで量産すると気持ちいいのは保証できます。

Infinite Debian - Platform for mass-producing system every second

Technology

Transcript of Infinite Debian - Platform for mass-producing system every second