Открыть список
Как стать автором
Обновить

Комментарии 11

В случае, если Вы работаете с гипервизором Hyper-V, то помимо последовательного порта можно попробовать воспользоваться механизмом KVP (Key-Value Pairs) или Hyper-V Sockets.

В QEmu/KVM помимо сетевого и серийных интерфейсов тоже можно использовать vhost-vsock, если ядро не слишком старое.

А чем Vagrant не подошёл?

Vargrant отлично бы подошёл. Больше того, эта платформа инкапсулирует в себе практически всю логику, которая так скурпулёзно выстраиваится в статье (и эти параллели только усилятся во второй части статьи). Почему в статье обошлось без него?
Ну, во-первых, про vagrant написано уже довольно много всего. Про virt-builder и virt-install несоизмеримо меньше, и хотелось немного восполнить этот пробел.
Во-вторых, Vagrant «скрывает» от пользователя внутреннюю кухню, выставляя наружу отполированный инкапсуляцией cli. Я же хотел показать именно суть/принципы системных тестов и тех процессов, которые протекают внутри при их автоматизации. Поэтому тут мы руками проделываем те же вещи, которые в большинстве своём тот же Vagrant сделает за Вас.

Vagrant ещё подразумевает инкапсуляцию гипервизора (virtualbox/libvirt/hyperv), что на моём опыте приводило к сложности тюнинга qemu через слоёный пирог ruby template -> libvirt xml -> qemu opts.

Понятное дело, что если что-то для нелинуха тестировать, или, скажем, модули ядра — тут без VM не обойтись. Но вот насчёт GUI я бы поспорил, подозреваю, многое можно сделать и в контейнерах при помощи Xvfb, например https://github.com/metal3d/docker-xvfb


По поводу работы с оборудованием — host devices в контейнер можно прокинуть, тут вопрос скорее с изоляцией, чтобы тестовая среда слишком много не могла себе позволить. Хотя, в зависимости от ситуации, можно, скажем, сделать одну виртуалку для тех же CI jobs с доступом к нужным устройствам, а на ней уже гонять контейнеры (а для этого материал статьи весьма полезен)

Если Вам хватает работы с контейнерами для автоматизации системных тестов — то это действительно хороший выбор:
1) Контейнеры практически невесомы и их можно запускать целыми пачками без последсвтий для хоста;
2) Вопрос автоматизации тестов на контейнерах проработан вдоль и поперёк, легко найти устраивающее Вас решение.
Соответственно, если для тестирования GUI Вам хватает Xvfb (ещё кстати вопрос как будут выглядеть такие тесты), то, опять же, лучше не устраивать себе overkill с подключением виртуалок. То же самое касается работы с оборудованием.

Виртуалки хороши только в одном — в своей универсальности. С их помощью можно тестировать с одинаковым успехом как стенды с виндой, так и консольные приложения на Ubuntu Server. И хоть сейчас мы действуем несколько наивно (предполагая, что всё общение с виртуалкой можно свести к набору bash-команд), но в дальнейшем подход с виртуалками откроет перед нами очень большие возможности для автотестов.

Я бы просуммировал это так: чем более простым средством Вы можете обойтись для системных автотестов — тем лучше. Хватает контейнеров — конечно используйте контейнеры — отличный выбор. Эта статья скорее для тех, кому контейнеров не хватает, но системных автотестов очень хочется. И непонятно с чего начать
Спасибо за статью! Актуально!
Что же за «скользкий момент, связанный с sudo»?
Добавить свой публичный ключ на гостевую систему проще всего с помощью параметра --ssh-inject USERNAME_ON_GUEST. Однако, если Вы запускаете virt-builder от рута, то и ключи будут использоваться рутовские. Лично у меня root не имеет ssh ключей, и я не собираюсь ему их создавать. А если Вы запускаете virt-builder от имени обычного пользователя — то нужно наделить этого пользователя соответствующими правами. Я решил описать вариант с паролем, поскольку он требует наименьшего количества объяснений, и, соответственно, позволяет сделать статью чуть короче и проще.

Чет не очень понятно, а где прописывание уникальных имен хостов, UUID диска, mac-адреса и тд в каждую свежесозданную виртуалку?

Конкретно для наших тестов вполне хватает всех этих значений по-умолчанию (кроме MAC-адресов, но этот момент рассматривается во второй части статьи). Конечно же, и virt-builder и virt-install обладают широченными возможностями по кастомизации буквально всего, чего угодно (как раз перечисленные значения можно прописать через дополнительные параметры этих утилит). Но цель этой статьи — не показать все возможности этих утилит, а сосредоточиться на системных тестах, поэтому я охватил лишь необходимый минимум.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.