Виртуализация при помощи VirtualBox
Введение
В последние годы виртуализация стала очень модным словом в ИТ, но до недавнего времени для меня она оставалась некой абстрактной технологией. В этой статье я хочу поделиться своим опытом практического использования технологии виртуализации. Речь пойдет создании полностью самодостаточной среды разработки проекта.
Зачем? Попробую перечислить возможные варианты использования:
- вам важно иметь возможность запуска сайта по Windows/Mac OS X, даже если проект Linux only
- вы хотите отладить процесс развертывания, на «чистой» системе (особенно если процесс автоматизирован)
- вы хотите взять работу в дорогу/в отпуск, работать придется на чужом ПК/ноутбуке
- вы привлекаете в проект фрилансера и не хотите целый день ей/ему объяснять как поднять локальную копию сайта
- не-программисты из вашей команды хотят иметь «свою» копию проекта, но не могут самостоятельно ее настроить
Если ни один из вариантов вас не заинтриговал, дальше можно не читать.;)
Виртуализация дает удобный инструмент для использования в качестве тестового окружения или переносного окружения разработчика. Чем сложнее программный проект, чем больше у него внешних зависимостей, тем больше выгод может дать его виртуализация.
Виртуализация в коробке
Уяснив для себя, что виртуализация мне нужна, первое с чем я столкнулся: многообразие различных решений. Тут и гипервизор Xen и контейнеры OpenVZ, и KVM, которая идет из коробки в последних дистрибутивах Ubuntu/Fedora, и целая линейка продуктов VMWare, которая кажется закрывает все продуктовые ниши.
Цели применения виртуализации могут быть очень разные, также отличаются и соответствующие продукты. Я искал «обычную» виртуализацию, которая выполняет эмуляцию аппаратного обеспечения и позволяет исполнять несколько полноценных виртуальных машин внутри одной ОС (хост-машины).
Перепробовав разные варианты в итоге выбрал Sun VirtualBox. Почему? Кроссплатформенность, бесплатность, управление через ком. строку, отличная документация, хорошая скорость работы, небольшой размер дистрибутива (24Мб против 400+ у VMWare Server).
Похожие по функциональности продукты: бесплатный VMWare Server и Linux KVM. Если VirtualBox «не совсем» устраивает имеет смысл взглянуть на эту парочку. Интересно выглядит и ovirt (на базе libvirt/kvm).
Примечание: в процессе моего изучения VirtualBox и написания этой статьи вышла версия VirtualBox 2.0. О ней я еще ничего не знаю, в данной статье описывается версия 1.6.4.
Установка VirtualBox
В качестве host-ОС я использую Ubuntu Linux, ее же использовал и для виртуальной машины.
На сайте VirtualBox к загрузке доступно две ветки, OSE (Open source edition) и «free». OSE есть в репозиториях Ubuntu, но она не такая свежая (1.5. х против 1.6. х) и не поддерживает PAE. Что оказалось критичным, но об этом позже.
VirtualBox конфликтует с KVM, которая идет по умолчанию в свежих дистрибутивах Ubuntu (а также Fedora). Решение заключается в выгрузке kvm-модуля ядра:
# rmmod kvm-intel
При установке non-OSE ветки необходима компиляция драйвера ядра, для чего потребуются его (ядра) include-файлы. Их обеспечивает виртуальный пакет linux-headers нужной версии:
# apt-get install linux-header
Установка Ubuntu
Процедура простая:
- Создается новая виртуальная машина (проще всего — через GUI VirtualBox). Для нее понадобится создать.vdi диск. Я бы рекомендовал либо expandable либо диск меньше 4Гб, для максимальной переносимости (файловая система, используемая на
DVD-дисках не позволяет создавать файлы размером в 4Гб или больше; делать gzip/ungzip для записи можно, но очень ресурсоемко). - В настройках машины подключается.iso образ установочного диска ОС.
- Выполняется запуск VM и дальше идет обычный процесс установки.
Для виртуальной машины имеет смысл использовать Ubuntu Server Edition, который идет с text-mode installer или даже JeOS, которая еще компактнее и создавалась специально для целей виртуализации.
Установку я выполнял OSE версией VirtualBox и в результате после окончания установки и перезагрузки получил такую ошибку:
This kernel requires the following features not present on the CPU 0:6 Unable to boot - please use a kernel that is appropiate for your CPU
Как выяснилось, это проблема совместимости. Один из способов решения — использовать версию 1.6. х и включить в настройках галочку PAE. Альтернативный вариант — загрузить VM в recovery mode и поставить ядро -generic вместо -i386.
Есть и другой способ — сразу ставить JeOS, у которой эта ошибка не проявляется.
Настройка SSH-доступа
По умолчанию VirtualBox использует NAT, благодаря чему гостевая VM видит интернет без необходимости какой-либо настройки с вашей стороны (при условии, что гостевая ОС обнаружит и настроит виртуальную Ethernet-карту).
Ключевая «особенность» технологии NAT состоит в том, что гостевая и хост-машина никак не «видят» друг друга в IP-сети. Самое простое решение — проброс (форвард) портов средствами VirtualBox. Выглядит это так (пример из документации):
VBoxManage setextradata guest-vm "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP VBoxManage setextradata guest-vm "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22 VBoxManage setextradata guest-vm "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222
Важно: для активации этих настроек требуется перезапуск гостевой VM.
Теперь можно подключаться через порт 2222 на хост-машине:
ssh -p2222 localhost # Linux C:\>putty localhost:2222 ; Windows
Если пишет «connection refused», значит на виртуалке не установлен sshd (он отсутствует по умолчанию в JeOS). Ставим:
$ sudo aptitude install openssh-server
Сразу имеет смысл настроить беспарольный вход по SSH:
$ ssh-keygen -t rsa $ ssh guest mkdir -p .ssh $ cat ~/.ssh/id_rsa.pub | ssh guest 'cat >> .ssh/authorized_keys' $ ssh guest chmod 600 .ssh/authorized_keys
Клонирование VM
Фактически у нас уже есть полностью работоспособная виртуалка, только пока «голая», без нашего приложения и сопутствующих библиотек. В этот момент имеет смысл «сохраниться», чтобы в следующий раз не выполнять рутинную операцию установки/настройки базовой ОС.
Для этого можно сделать «снимок» (snapshot), но лучше — клонировать VM целиком. В результате мы получим отдельную VM, полностью независимую от оригинала.
Клонирование выполняется просто, одной командой clonevdi, которая создает копию нашего.vdi файла. Но эта на первый взгляд простая операция содержит несколько подводных камней.
Копировать VM необходимо только средствами VirtualBox, иначе копию не удастся запустить на той же машине (при клонировании меняется UUID виртуального диска, который хранится в.vdi файле).
Я написал такой примерно скриптик, который автоматизирует операцию клонирования и настройки копии (см. cсылки в конце статьи):
$ VBoxManage -nologo clonevdi $vboxdir/$orig.vdi $vboxdir/$name.vdi $ VBoxManage -nologo createvm -name $name -register $ VBoxManage -nologo modifyvm $name -hda $vboxdir/"$name.vdi" $ VBoxManage -nologo modifyvm $name -macaddress1 $nic $ VBoxManage -nologo modifyvm $name -nic1 nat
Современные версии Linux используют UUID в качестве указателей на разделы, поэтому их придется обновлять при каждом клонировании. О чем, кстати, явно предупреждает документация на VirtualBox.
Я решил поступить проще. До клонирования я исправил все ссылки по UUID в /etc/fstab и /boot/grub/menu.lst на обычные ссылки /dev/sda*. (напоминание: после правки menu.lst необходимо перезаписать GRUB командой sudo grub-install /dev/sda).
Если вы делали «снимки» (snapshots), при клонировании они не будут скопированы. Чтобы клонированная копия имела изменения из snapshots их необходимо «объединить» с оригинальным.vdi неочевидным способом: делая Discard каждому из снимков, начиная с самого старого (верхнего в дереве).
Еще после клонирования новая VM будет видеть сетевую карту с новым mac-адресом. Поэтому нужно либо использовать тот же MAC-адрес (его можно изменить через Settings -> Network), либо поправить в гостевом линуксе файл /etc/network/interfaces (заменив eth0 на ethX, см. ifconfig -a). Я использую один MAC для всех виртуалок (устанавливается скриптом выше), работает замечательно.
Настройка VPN-сети
VPN: Виртуальная локальная сеть, доступная из любой точки интернета. Это единственный способ сделать виртуалку видимой извне (документация описывает настройку bridge networking, но он позволяет добиться только того, что виртуалка видна в локальной сети хост-машины; сама же хост-сеть, как правило, невидима извне).
Обычно настроить VPN-сеть еще сложнее, чем bridge networking. Но, к счастью, нашлась такая штука, как Hamachi. Благодаря ей весь процесс занимает буквально минуты.
Выглядит это так:
- На гостевую VM устанавливается клиент Hamachi. Т. к. Hamachi-клиент написан на Си, потребуется сначала установить компилятор и вспомогательные утилиты: sudo aptitude install build-essentials.
- Командой hamachi create создается наша VPN-сеть и устанавливается пароль на подключение к сети.
- Командой hamachi join выполняется вход в VPN-сеть и hamachi go-online, чтобы эта машина стала видима другим машинам VPN-сети.
- Для удобства каждой машине ставится уникальное имя (hamachi set-nick).
Пункты
В результате доступ на гостевую VM будет работать с любой другой машины, подключенной к VPN сети. Даже если сама host-машина никак «извне» не видна. Это просто фантастика. Вы можете скопировать виртуалку на свой ноутбук, уехать с ним за тридевять земель и подключившись к интернет, сделать VM доступной коллегам. Или же зайти удаленно на VM, которая осталась на офисном сервере, пока вы в разъездах.
Автозапуск VM на host-машине
Автозапуск гостевой VM может потребоваться если мы хотим работать с ней удаленно, а host-машина извне недоступна (по соображениям безопасности). Если сделать автозапуск, мы сможем войти на гостевую машину без необходимости промежуточного входа на host-машину.
Запуск выполняется через VBoxHeadless, размещение и формат скрипта зависит от дистрибутива. Мой скрипт для upstart (используется в Ubuntu) можно найти в коде vbox-utils, см. ссылки. Фактически это всего одна команда:
$ VBoxHeadless -startvm dou-staging1
Проверить, что машина была успешно запущена можно командой VBoxManage:
$ VBoxManage -nologo list runningvms
При этом можно подключиться удаленно, через протокол RDP:
$ rdesktop host.machine.ip:3389 # IP хост-машины, где выполняется VBoxHeadless
Ну и конечно должен работать SSH-доступ из любой точки VPN-сети.
Для полноты картины привожу команду усыпления VM:
$ VBoxManage controlvm dou-staging1 savestate
Развертывание приложения
Здесь особо писать и нечего, т. к. процесс развертывания полностью определяется приложением. Главное — что у нас есть база — виртуальная ОС, досупная по ssh, с открытым веб-интерфейсом.
Заключение
На этом считаю свою миссию выполненной. О преимуществах виртуализации я рассказал, использование VirtualBox подробно описал. Если есть вопросы — спрашивайте, буду отвечать.
Ссылки
- VirtualBox.org — официальный сайт VirtualBox
- All about VDIs (tutorial) — хороший FAQ на форуме virtualbox
- vbox-utils — мои скрипты для VirtualBox, о которых шла речь в статье
zaperilo
Влад как бы
Vladyslav Lazarenko
Max Ischenko
Ostap Vyshnya
Vsevolod Solovyov
Сергей Савостин
Александр Лозовюк
Denis Osetrov
38 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.