Автоматизация системных тестов на базе QEMU (Часть 1/2)

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

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

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

Я бы просуммировал это так: чем более простым средством Вы можете обойтись для системных автотестов — тем лучше. Хватает контейнеров — конечно используйте контейнеры — отличный выбор. Эта статья скорее для тех, кому контейнеров не хватает, но системных автотестов очень хочется. И непонятно с чего начать

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

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