Comments 11
В случае, если Вы работаете с гипервизором Hyper-V, то помимо последовательного порта можно попробовать воспользоваться механизмом KVP (Key-Value Pairs) или Hyper-V Sockets.
В QEmu/KVM помимо сетевого и серийных интерфейсов тоже можно использовать vhost-vsock, если ядро не слишком старое.
А чем Vagrant не подошёл?
Ну, во-первых, про vagrant написано уже довольно много всего. Про virt-builder и virt-install несоизмеримо меньше, и хотелось немного восполнить этот пробел.
Во-вторых, Vagrant «скрывает» от пользователя внутреннюю кухню, выставляя наружу отполированный инкапсуляцией cli. Я же хотел показать именно суть/принципы системных тестов и тех процессов, которые протекают внутри при их автоматизации. Поэтому тут мы руками проделываем те же вещи, которые в большинстве своём тот же Vagrant сделает за Вас.
Понятное дело, что если что-то для нелинуха тестировать, или, скажем, модули ядра — тут без VM не обойтись. Но вот насчёт GUI я бы поспорил, подозреваю, многое можно сделать и в контейнерах при помощи Xvfb, например https://github.com/metal3d/docker-xvfb
По поводу работы с оборудованием — host devices в контейнер можно прокинуть, тут вопрос скорее с изоляцией, чтобы тестовая среда слишком много не могла себе позволить. Хотя, в зависимости от ситуации, можно, скажем, сделать одну виртуалку для тех же CI jobs с доступом к нужным устройствам, а на ней уже гонять контейнеры (а для этого материал статьи весьма полезен)
1) Контейнеры практически невесомы и их можно запускать целыми пачками без последсвтий для хоста;
2) Вопрос автоматизации тестов на контейнерах проработан вдоль и поперёк, легко найти устраивающее Вас решение.
Соответственно, если для тестирования GUI Вам хватает Xvfb (ещё кстати вопрос как будут выглядеть такие тесты), то, опять же, лучше не устраивать себе overkill с подключением виртуалок. То же самое касается работы с оборудованием.
Виртуалки хороши только в одном — в своей универсальности. С их помощью можно тестировать с одинаковым успехом как стенды с виндой, так и консольные приложения на Ubuntu Server. И хоть сейчас мы действуем несколько наивно (предполагая, что всё общение с виртуалкой можно свести к набору bash-команд), но в дальнейшем подход с виртуалками откроет перед нами очень большие возможности для автотестов.
Я бы просуммировал это так: чем более простым средством Вы можете обойтись для системных автотестов — тем лучше. Хватает контейнеров — конечно используйте контейнеры — отличный выбор. Эта статья скорее для тех, кому контейнеров не хватает, но системных автотестов очень хочется. И непонятно с чего начать
Чет не очень понятно, а где прописывание уникальных имен хостов, UUID диска, mac-адреса и тд в каждую свежесозданную виртуалку?
Автоматизация системных тестов на базе QEMU (Часть 1/2)