Адская кухня. Обзор средств виртуализации и контейнеров во FreeBSD

Введение

Под­дер­жка аппа­рат­ной вир­туали­зации (в качес­тве хос­товой сис­темы) во FreeBSD появи­лась недав­но — пер­вое упо­мина­ние о bhyve встре­чает­ся в новос­тях 2011 года. С одной сто­роны, в дру­гих ОС эта под­дер­жка гораз­до более зре­ла. С дру­гой же — при раз­работ­ке bhyve были учте­ны некото­рые момен­ты, которые мог­ли воз­никнуть, раз­рабаты­вай­ся он с нуля. Кро­ме того, что­бы не пло­дить сущ­ности, в гос­тевых сис­темах исполь­зует­ся virtIO (как и в KVM и Xen).

А вот тех­нология для соз­дания кон­тей­неров во FreeBSD сущес­тву­ет с дав­них пор под наз­вани­ем Jail. В осно­ве ее лежит груп­па сис­темных вызовов (jail(), jail_get(), jail_set(), jail_remove() и jail_attach()). Воп­реки рас­простра­нен­ному мне­нию, в пос­ледних вер­сиях FreeBSD они не вызыва­ют chroot(), хотя и исполь­зуют некото­рые общие с дан­ным сис­темным вызовом про­цеду­ры. Из пре­иму­ществ Jail, помимо собс­твен­но изо­ляции, мож­но отме­тить так­же гиб­кое управле­ние ресур­сами с помощью RCTL (для вклю­чения дан­ной фун­кции, одна­ко, тре­бует­ся переком­пиляция ядра).

Пос­мотрим, нас­коль­ко удоб­но исполь­зовать дан­ные тех­нологии по срав­нению с их ана­лога­ми из дру­гих ОС.

Установка FreeBSD на bhyve

Для исполь­зования дан­ной сис­темы вир­туали­зации необ­ходима вер­сия FreeBSD не ниже 10 (а с про­цес­сором AMD — не ниже 11-CURRENT). Что­бы ее вклю­чить, нуж­но добавить сле­дующие стро­ки в файл boot/loader.conf:

Пос­ле перезаг­рузки (или добав­ления дан­ных модулей с помощью kldload) нуж­но соз­дать бридж и интерфейс tap для под­нятия сети в будущей вир­туаль­ной машине:

За­тем объ­еди­няем tap0 и реаль­ный интерфейс в бридж и запус­каем его — в моем слу­чае для это­го пот­ребова­лись сле­дующие коман­ды:

Соз­даем файл обра­за, куда будем ста­вить сис­тему:

За­тем либо кача­ем bootonly-образ, либо исполь­зуем образ DVD, который ты при­менял при уста­нов­ке FreeBSD (файл устрой­ства по неиз­вес­тным при­чинам для этих целей не под­ходит). Копиру­ем скрипт, облегча­ющий запуск вир­туаль­ной машины, и редак­тиру­ем в нем нуж­ные парамет­ры:

Скрипт доволь­но боль­шой и дела­ет сле­дующее:

1. Про­веря­ет, явля­ется ли вызыва­ющий поль­зователь при­виле­гиро­ван­ным.
2. Про­веря­ет, заг­ружен ли модуль vmm.ko.
3. Смот­рит задава­емые опции.
4. Про­веря­ет, явля­ется ли файл жес­тко­го дис­ка заг­рузоч­ным обра­зом.
5. На­конец, заг­ружа­ет с помощью bhyveload ядро FreeBSD и переда­ет ему управле­ние через bhyve.

О пос­леднем эта­пе сто­ит рас­ска­зать под­робнее. Пос­коль­ку bhyve пока не под­держи­вает ни BIOS, ни UEFI, а ини­циали­зиро­вать вир­туаль­ное обо­рудо­вание все же необ­ходимо, для это­го был сде­лан модифи­циро­ван­ный заг­рузчик для FreeBSD. Ана­логич­но есть и bhyve-модифи­циро­ван­ный GRUB 2, слу­жащий для заг­рузки иных сис­тем. Но вот ты его отре­дак­тировал. Теперь мож­но и запус­кать:

Ус­танав­лива­ем стан­дар­тным обра­зом. Для нор­маль­ного завер­шения работы нуж­но перезаг­рузить­ся и в приг­лашении loader’а наб­рать quit.

Вмес­то исполь­зования фай­ла обра­за мож­но взять фун­кцию ZFS под наз­вани­ем zvol. Преж­де все­го соз­дадим этот самый zvol:

Ус­танав­лива­ем FreeBSD обыч­ным путем, ука­зав вмес­то фай­ла обра­за zvol (в моем слу­чае — /dev/zvol/zroot/fbsd), метод раз­биения выбира­ем «ZFS - Automatic Root-on-ZFS». Пос­ле уста­нов­ки для запус­ка вво­дим при­мер­но сле­дующие две коман­ды (так как скрипт не всег­да кор­рек­тно работа­ет):

И работа­ем как обыч­но.

Bhyve: установка Linux

Для уста­нов­ки Linux пот­ребу­ется уста­новить grub2-bhyve:

За­тем нуж­но ска­чать образ дис­три­бути­ва (я взял CentOS 7) и соз­дать файл device.map и образ дис­ка.

Со­дер­жимое device.map:

За­пус­каем grub-bhyve и набира­ем соот­ветс­тву­ющие коман­ды для заг­рузки ядра:

Здесь нуж­но объ­яснить некото­рые детали. Пос­коль­ку bhyve пока не под­держи­вает гра­фичес­кий режим, нуж­но запус­тить уста­нов­ку в тек­сто­вом, для чего и переда­ем ядру параметр text. Кро­ме того, коман­да boot ядро, конеч­но, в память заг­ружа­ет — но управле­ние не переда­ет. Для переда­чи же управле­ния исполь­зует­ся сле­дующая коман­да:

Раз­берем опции:

• -A — генери­ровать таб­лицы ACPI (в которых хра­нит­ся, нап­ример, количес­тво про­цес­соров);
• -H — реали­зует инс­трук­цию HLT в вир­туаль­ном CPU. В слу­чае если эту опцию не ука­зать, реаль­ный про­цес­сор будет заг­ружен на 100%;
• -P — при­оста­нав­лива­ет VCPU по получе­нии им инс­трук­ции PAUSE;
• мно­жес­тво опций -s кон­фигури­руют сло­ты PCI. Пос­ле пер­вой запятой ука­зыва­ется, какое устрой­ство будет эму­лиро­вать­ся или проб­расывать­ся. Пос­ле вто­рой ука­зыва­ется кон­фигура­ция для дан­ного устрой­ства — так, в при­мере выше для virtio-blk ука­зан путь к обра­зу. При необ­ходимос­ти для сетево­го интерфей­са таким же спо­собом мож­но ука­зать MAC-адрес;
• -l — пред­назна­чено для мап­пинга COM-пор­тов;
• -c — количес­тво вир­туаль­ных про­цес­соров;
• -m — память.

По­мимо ука­зан­ных, есть еще и допол­нитель­ные опции:

• -C — вклю­чать память гос­тевой ОС в фай­лы дам­па;
• -e — при­нуди­тель­но завер­шать работу bhyve, если гос­тевая ОС обра­щает­ся к неэму­лиру­емым пор­там вво­да‑вывода — что полез­но для целей отладки;
• -p vcpu:hostcpu — при­вязать ука­зан­ный VCPU к CPU хос­товой машины;
• -U uuid — уни­каль­ный иден­тифика­тор в струк­туре SMBIOS System Information. Если его не ука­зать, генери­рует­ся на осно­ве име­ни хос­та хос­товой сис­темы и име­ни вир­туаль­ной машины;
• -w — игно­риро­вать обра­щения к нере­али­зован­ным регис­трам MSR, что опять же полез­но для отладки;
• -W — исполь­зовать в эму­лиру­емой сис­теме ста­рую сис­тему пре­рыва­ний (MSI) вмес­то более новой (MSI-X);
• -x — исполь­зовать в гос­тевой сис­теме режим x2APIC;
• -Y — отклю­чить генера­цию MPTable.

Пос­ле заг­рузки запус­тится Anaconda в самом что ни на есть тек­сто­вом режиме (даже без исполь­зования ncurses — прос­то чер­но‑белый тер­минал, навева­ющий нос­таль­гичес­кие мыс­ли о вре­менах DOS). Уста­нов­ка более чем стан­дар­тна. Пос­ле ее завер­шения нас выб­росит во FreeBSD — bhybe не уме­ет перезаг­ружать­ся. Для даль­нейшей работы нуж­но завер­шить работу bhyve, сно­ва запус­тить grub-bhyve и вновь исполь­зовать ту же коман­ду:

Вы­бира­ем нуж­ный пункт и переда­ем управле­ние коман­дой bhyve с соот­ветс­тву­ющи­ми опци­ями.

Другие статьи в выпуске:

Хакер #194. Car hacking!

• Содержание выпуска
• Подписка на «Хакер»-60%

Но что, если нуж­но под­клю­чать­ся к кон­соли и отклю­чать­ся от нее? В этом слу­чае мож­но исполь­зовать нуль‑модем­ное устрой­ство, для которо­го преж­де все­го необ­ходимо заг­рузить модуль ядра nmdm:

За­тем в опции -l ука­зыва­ем вмес­то stdio /dev/nmdm0A и под­клю­чаем­ся к нему:

Кро­ме того, при соз­дании вир­туаль­ной машины соз­дает­ся так­же и файл в катало­ге /dev/vmm, что поз­воля­ет быс­тро пос­мотреть спи­сок заг­ружен­ных машин.

Настройка Jail

FreeBSD под­держи­вает так­же ана­лог LXC — Jail. Мы будем рас­смат­ривать его вку­пе с ZFS. Для начала соз­дадим фай­ловую сис­тему:

Вто­рая коман­да соз­дает сжа­тую ZFS, а третья — собс­твен­но ту ФС, куда мы будем его раз­верты­вать и отку­да затем кло­ниро­вать. Ска­чива­ем фай­лы FreeBSD 10.1 и рас­паковы­ваем их:

Сде­лаем некото­рую базовую нас­трой­ку (ско­пиру­ем resolv.conf, пос­тавим пароль, соз­дадим каталог /usr/home и сим­линк /home, уста­новим обновле­ния):

Соз­дадим снап­шот текуще­го «чис­того» Jail.

Кон­фигури­руем шаб­лон даль­ше. Соз­дадим в Jail сле­дующий файл — /etc/make.conf:

В фай­ле /etc/rc.conf (в Jail) дол­жно быть при­мер­но сле­дующее:

На дан­ном эта­пе мож­но так­же добавить все нас­трой­ки и прог­раммы, которые необ­ходимо иметь во всех песоч­ницах. Пос­ле это­го выходим из chroot и на хос­товой сис­теме сно­ва дела­ем снап­шот:

Здесь p0 — номер условно­го «пат­ча».

На хос­товой же сис­теме соз­даем файл /etc/jail.conf сле­дующе­го содер­жания:

За­тем соз­даем на осно­ве того снап­шота, что был ранее сде­лан, клон:

И в /etc/rc.conf добавим строч­ку (если нуж­но, что­бы соз­данные Jail запус­кались авто­мати­чес­ки):

Для запус­ка же опре­делен­ного Jail вруч­ную набира­ем коман­ду:

где test — запус­каемая песоч­ница.

Что­бы запус­тить какую‑нибудь прог­рамму в песоч­нице, исполь­зуем сле­дующие коман­ды:

Пер­вая коман­да показы­вает спи­сок запущен­ных песоч­ниц, вто­рая же запус­кает в песоч­нице с ука­зан­ным ID задан­ную прог­рамму. Оста­нав­лива­ют их ана­логич­но запус­ку, толь­ко вмес­то аргу­мен­та start пишем соот­ветс­твен­но stop.

Тонкая настройка Jail. Интересные особенности

Кон­фигура­ция, при­веден­ная выше, конеч­но же, может исполь­зовать­ся и на прак­тике. Тем не менее всех воз­можнос­тей песоч­ницы она не охва­тыва­ет. Пос­мотрим, какие еще воз­можнос­ти име­ются у дан­ной тех­нологии. Пос­коль­ку песоч­ницы нераз­рывно свя­заны с огра­ниче­ниями, соот­ветс­твен­но, и раз­бирать будем дан­ный фун­кци­онал.

Боль­шинс­тво парамет­ров, нас­тра­иваемых в фай­ле jail.conf, на самом деле явля­ются парамет­рами sysctl (ветвь security.jail), поэто­му опи­сыва­емые ниже опции могут быть изме­нены так­же с помощью дан­ной ути­литы.

Па­раметр securelevel слу­жит для огра­ниче­ния securelevel в Jail. Отме­чу, что зна­чение дан­ного парамет­ра не может быть ниже, чем в хос­товой сис­теме (оно и понят­но). Сто­ит напом­нить, что огра­ничи­вает тот или иной уро­вень:

• 0 — раз­решено все; фак­тичес­ки это уро­вень по умол­чанию;
• 1 — зап­реща­ется изме­нение фла­гов фай­лов с помощью chflags, запись в фай­лы дис­ковых устрой­ств (при смон­тирован­ных ФС) и в некото­рые дру­гие и заг­рузка модулей ядра (пос­леднее, впро­чем, в jail-окру­жении зап­рещено и так). Кро­ме того, зап­реща­ется вызов отладчи­ка ядра;
• 2 — помимо зап­ретов пре­дыду­щего уров­ня, писать в фай­лы дис­ковых устрой­ств может толь­ко сис­темный вызов mount и зап­рещено изме­нять вре­мя боль­ше, чем на секун­ду;
• 3 — те же огра­ниче­ния, что и на пре­дыду­щем, плюс зап­рет на изме­нение пра­вил бран­дма­уэра.

Па­раметр devfs_ruleset ука­зыва­ет, какой набор пра­вил devfs будет при­менять­ся для кон­тей­нера. Вез­де пишут, что по умол­чанию ни еди­ного набора не при­меня­ется, — и при исполь­зовании коман­ды /sbin/jail все вер­но. Одна­ко в слу­чае со стан­дар­тным скрип­том запус­ка /etc/rc,d/jail это не так — при­меня­ется набор пра­вил, заточен­ный спе­циаль­но для Jail и опи­сан­ный в /etc/defaults/devfs.rules.

Во FreeBSD под­держи­вают­ся так­же вло­жен­ные кон­тей­неры. Для их исполь­зования надо уста­новить параметр children.max, ука­зыва­ющий мак­сималь­ное количес­тво вло­жен­ных кон­тей­неров. По умол­чанию он равен нулю, то есть вло­жен­ные кон­тей­неры соз­давать зап­реща­ется. Текущее же количес­тво потом­ков мож­но пос­мотреть в перемен­ной children.cur.

С помощью парамет­ра enforce_statfs мож­но управлять видимостью точек мон­тирова­ния. При уста­нов­ке его в 0 про­цесс может получать информа­цию обо всех точ­ках мон­тирова­ния. При уста­нов­ке в 1 — толь­ко о точ­ках мон­тирова­ния в самой песоч­нице. Зна­чение же по умол­чанию, 2, и вов­се огра­ничи­вает информа­цию под­монти­рован­ным кор­нем.

Па­рамет­ры, начина­ющиеся с «allow.», булевы и в под­робном опи­сании не нуж­дают­ся. Упо­мина­ния сто­ит раз­ве что allow.raw_sockets — без дан­ного парамет­ра некото­рые ути­литы, такие как ping, работать не будут. Кро­ме того, при добав­лении пре­фик­са no пос­ле «allow.» зна­чение парамет­ра инверти­рует­ся. К при­меру, allow.nomount зап­реща­ет какое‑либо мон­тирова­ние. Это име­ет смысл, если в сек­ции парамет­ров для всех кон­тей­неров дей­ствие раз­решено, но для опре­делен­ного его необ­ходимо зап­ретить. По умол­чанию поч­ти вез­де сто­ит зап­рет — исклю­чение сос­тавля­ет лишь allow.set_hostname.

Ес­ли нуж­но пос­тавить в Jail более ста­рую вер­сию FreeBSD, необ­ходимо будет уста­новить перемен­ную UNAME_r соот­ветс­тву­юще дан­ной вер­сии — в про­тив­ном слу­чае некото­рые прог­раммы могут отка­зать­ся работать.

CBSD

Для облегче­ния соз­дания Jail’ов мож­но исполь­зовать набор ути­лит CBSD — удоб­ный фрон­тенд для работы с кон­тей­нерами, пос­ледние вер­сии которо­го к тому же под­держи­вают и bhyve. Его осо­бен­ности:

• на­личие готово­го репози­тория — что дела­ет перес­борку FreeBSD необя­затель­ной;
• под­дер­жка ZFS;
• эк­спорт/импорт кон­тей­неров;
• ути­лита кон­фигури­рова­ния в сти­ле bsdinstall.

И мно­гое дру­гое. Для уста­нов­ки нуж­но выпол­нить сле­дующую коман­ду:

Пос­ле это­го нуж­но его ини­циали­зиро­вать:

Скрипт задаст с десяток воп­росов, пос­ле чего мож­но будет запус­кать ути­литу jconstruct-tui:

По­явит­ся тек­сто­вое диало­говое окно, в котором нуж­но ука­зать парамет­ры вновь соз­дава­емой песоч­ницы, такие как имя, IP-адрес, вер­сия FreeBSD... Пос­ле соз­дания мож­но исполь­зовать сле­дующую коман­ду для запус­ка Jail:

У дан­ного ПО есть еще мно­жес­тво воз­можнос­тей, которые мы здесь опи­сывать не будем. В целом фун­кци­онал ана­логи­чен ран­нему Docker — но, конеч­но, про­екту до него еще рас­ти и рас­ти.

Заключение

Тех­нологии вир­туали­зации во FreeBSD про­изво­дят двой­ствен­ное впе­чат­ление. С одной сто­роны, да, они есть, и с их помощью мож­но даже что‑то запус­кать. С дру­гой же...

Не будем силь­но кри­тико­вать bhyve — в кон­це кон­цов, это отно­ситель­но недав­няя раз­работ­ка. Но помилуй­те — даже абсо­лют­но тек­сто­вые вари­анты ОС (которы­ми, к сло­ву, обла­дают толь­ко *nix-подоб­ные, да и то не все) уста­нав­ливать исклю­читель­но с исполь­зовани­ем эму­лиру­емо­го нуль‑модем­ного соеди­нения край­не неудоб­но. Хотя бы по той при­чине, что на дру­гую вир­туаль­ную кон­соль не перек­лючишь­ся — а зачас­тую там появ­ляет­ся полез­ная информа­ция. Помимо того, опции самой коман­ды bhyve пред­назна­чены ско­рее для внут­ренне­го при­мене­ния его раз­работ­чиков, чем для пов­седнев­ного исполь­зования в качес­тве средс­тва вир­туали­зации.

В слу­чае с Jail дела обсто­ят получ­ше — но тоже нес­коль­ко отста­ют от ана­логич­ных тех­нологий в Linux. Ярчай­ший при­мер это­го — во FreeBSD, начиная с вер­сии 7.0, под­держи­вает­ся такая воз­можность, как privileges, ана­логич­ная capabilities в Linux. Одна­ко, нес­мотря на то что сама реали­зация сис­темных вызовов, отно­сящих­ся к Jail, в сво­ем исходном коде ими опе­риру­ет, интерфей­са, поз­воля­юще­го адми­нис­тра­тору кон­тей­неров опре­делить, какие имен­но при­виле­гии будут дос­тупны супер­поль­зовате­лю того или ино­го кон­тей­нера, не сущес­тву­ет.

Та­ким обра­зом, тех­нологии аппа­рат­ной вир­туали­зации во FreeBSD еще недос­таточ­но ста­биль­ны, а кон­тей­неры (как бы они ни называ­лись) выг­лядят рабочи­ми, хотя и нем­ного ста­ромод­ными — что, спра­вед­ливос­ти ради, никак не меша­ет их исполь­зовать.