Конкретно для наших тестов вполне хватает всех этих значений по-умолчанию (кроме MAC-адресов, но этот момент рассматривается во второй части статьи). Конечно же, и virt-builder и virt-install обладают широченными возможностями по кастомизации буквально всего, чего угодно (как раз перечисленные значения можно прописать через дополнительные параметры этих утилит). Но цель этой статьи — не показать все возможности этих утилит, а сосредоточиться на системных тестах, поэтому я охватил лишь необходимый минимум.
Потому что 99% всей работы делают утилиты, на которые я полагаюсь в этой статье. Потрудитесь изучить финальный скрипт и увидите, что подавляющая часть этого скрипта — это вызов утилит virsh, virt-builder, virt-install и ssh. Разумеется, вызывать эти команды из баша удобнее, чем из питона.
Почему я выбрал именно эти утилиты, а не WhateverYouWant? Потому что, потрудитесь, наконец, прочитать дисклеймер.
Кроме того, если у Вас за 20 лет стажа так и не сложились отношения с башем, это не значит, что у других дела обстоят так же. Я, как и многие другие люди, не считаю его эзотерическим. Для того, чтобы скомпозировать вызов нескольких утилит, он вполне годится, что я и сделал в этой статье. В следующих статьях я его использовать уже не планирую.
Я согласен с тем, что писать системные тесты для продакшена на баше — это плохая, плохая идея.
Но я также считаю, что использование баша в этой статье в познавательных целях вполне оправдано. Вы что-нибудь слышали о принципе «от простого к сложному?». Сейчас я объясняю базовые принципы. А в одной из следующих статей я могу написать «Ребятки, а помните сколько манипуляций мы делали, чтобы автоматизировать системные тесты на баше? Давайте теперь посмотрим, как теперь за нас это сделает инструмент Х».
Пожалуйста, прочитайте ещё раз дисклеймер.
Статья ориентирована на начинающих, причём не на программистов, а на тестировщиков. Далеко не все тестировщики знают Python и, уж тем более, Ansible. А для понимания этой статьи достаточно базовых знаний Linux и Bash.
Главная цель статьи — внести понимание о системных тестах на виртуалках и об основных моментах, на которых нужно заострить внимание. Выбор инструментов, будь то bash, SSH или virt-builder — это лишь способ максимально упростить статью. Разумеется, я не рекомендую этот инструментарий для продакшена.
Добавить свой публичный ключ на гостевую систему проще всего с помощью параметра --ssh-inject USERNAME_ON_GUEST. Однако, если Вы запускаете virt-builder от рута, то и ключи будут использоваться рутовские. Лично у меня root не имеет ssh ключей, и я не собираюсь ему их создавать. А если Вы запускаете virt-builder от имени обычного пользователя — то нужно наделить этого пользователя соответствующими правами. Я решил описать вариант с паролем, поскольку он требует наименьшего количества объяснений, и, соответственно, позволяет сделать статью чуть короче и проще.
Если Вам хватает работы с контейнерами для автоматизации системных тестов — то это действительно хороший выбор:
1) Контейнеры практически невесомы и их можно запускать целыми пачками без последсвтий для хоста;
2) Вопрос автоматизации тестов на контейнерах проработан вдоль и поперёк, легко найти устраивающее Вас решение.
Соответственно, если для тестирования GUI Вам хватает Xvfb (ещё кстати вопрос как будут выглядеть такие тесты), то, опять же, лучше не устраивать себе overkill с подключением виртуалок. То же самое касается работы с оборудованием.
Виртуалки хороши только в одном — в своей универсальности. С их помощью можно тестировать с одинаковым успехом как стенды с виндой, так и консольные приложения на Ubuntu Server. И хоть сейчас мы действуем несколько наивно (предполагая, что всё общение с виртуалкой можно свести к набору bash-команд), но в дальнейшем подход с виртуалками откроет перед нами очень большие возможности для автотестов.
Я бы просуммировал это так: чем более простым средством Вы можете обойтись для системных автотестов — тем лучше. Хватает контейнеров — конечно используйте контейнеры — отличный выбор. Эта статья скорее для тех, кому контейнеров не хватает, но системных автотестов очень хочется. И непонятно с чего начать
Vargrant отлично бы подошёл. Больше того, эта платформа инкапсулирует в себе практически всю логику, которая так скурпулёзно выстраиваится в статье (и эти параллели только усилятся во второй части статьи). Почему в статье обошлось без него?
Ну, во-первых, про vagrant написано уже довольно много всего. Про virt-builder и virt-install несоизмеримо меньше, и хотелось немного восполнить этот пробел.
Во-вторых, Vagrant «скрывает» от пользователя внутреннюю кухню, выставляя наружу отполированный инкапсуляцией cli. Я же хотел показать именно суть/принципы системных тестов и тех процессов, которые протекают внутри при их автоматизации. Поэтому тут мы руками проделываем те же вещи, которые в большинстве своём тот же Vagrant сделает за Вас.
Почему я выбрал именно эти утилиты, а не WhateverYouWant? Потому что, потрудитесь, наконец, прочитать дисклеймер.
Кроме того, если у Вас за 20 лет стажа так и не сложились отношения с башем, это не значит, что у других дела обстоят так же. Я, как и многие другие люди, не считаю его эзотерическим. Для того, чтобы скомпозировать вызов нескольких утилит, он вполне годится, что я и сделал в этой статье. В следующих статьях я его использовать уже не планирую.
Но я также считаю, что использование баша в этой статье в познавательных целях вполне оправдано. Вы что-нибудь слышали о принципе «от простого к сложному?». Сейчас я объясняю базовые принципы. А в одной из следующих статей я могу написать «Ребятки, а помните сколько манипуляций мы делали, чтобы автоматизировать системные тесты на баше? Давайте теперь посмотрим, как теперь за нас это сделает инструмент Х».
Статья ориентирована на начинающих, причём не на программистов, а на тестировщиков. Далеко не все тестировщики знают Python и, уж тем более, Ansible. А для понимания этой статьи достаточно базовых знаний Linux и Bash.
Главная цель статьи — внести понимание о системных тестах на виртуалках и об основных моментах, на которых нужно заострить внимание. Выбор инструментов, будь то bash, SSH или virt-builder — это лишь способ максимально упростить статью. Разумеется, я не рекомендую этот инструментарий для продакшена.
1) Контейнеры практически невесомы и их можно запускать целыми пачками без последсвтий для хоста;
2) Вопрос автоматизации тестов на контейнерах проработан вдоль и поперёк, легко найти устраивающее Вас решение.
Соответственно, если для тестирования GUI Вам хватает Xvfb (ещё кстати вопрос как будут выглядеть такие тесты), то, опять же, лучше не устраивать себе overkill с подключением виртуалок. То же самое касается работы с оборудованием.
Виртуалки хороши только в одном — в своей универсальности. С их помощью можно тестировать с одинаковым успехом как стенды с виндой, так и консольные приложения на Ubuntu Server. И хоть сейчас мы действуем несколько наивно (предполагая, что всё общение с виртуалкой можно свести к набору bash-команд), но в дальнейшем подход с виртуалками откроет перед нами очень большие возможности для автотестов.
Я бы просуммировал это так: чем более простым средством Вы можете обойтись для системных автотестов — тем лучше. Хватает контейнеров — конечно используйте контейнеры — отличный выбор. Эта статья скорее для тех, кому контейнеров не хватает, но системных автотестов очень хочется. И непонятно с чего начать
Ну, во-первых, про vagrant написано уже довольно много всего. Про virt-builder и virt-install несоизмеримо меньше, и хотелось немного восполнить этот пробел.
Во-вторых, Vagrant «скрывает» от пользователя внутреннюю кухню, выставляя наружу отполированный инкапсуляцией cli. Я же хотел показать именно суть/принципы системных тестов и тех процессов, которые протекают внутри при их автоматизации. Поэтому тут мы руками проделываем те же вещи, которые в большинстве своём тот же Vagrant сделает за Вас.