Настройка Buildbot для виртуальных машин — общие принципы

Установки выполняются минимально, в основном выбирая стандартные параметры. Это помогает убедиться, что наше оборудование работает с типовыми установками, а также экономит усилия при создании виртуальных машин.

Поскольку большая часть логики происходит в узле Buildbot на хост-машине и внутри мастера Buildbot, нет необходимости устанавливать Buildbot или другие подобные сложные вещи внутри ВМ.

ssh

Виртуальные машины настраиваются с доступом ssh. Создается учетная запись с именем 'buildbot' с безпарольным входом (с использованием аутентификации с открытым ключом ssh) и безпарольным доступом sudo (необходимым для автоматизированного скриптинга). Открытый ключ для пользователя buildbot устанавливается на каждой ВМ, а закрытый ключ добавляется к учетной записи, выполняющей мастер Buildbot на хост-машине.

Для создания ключей ssh:

ssh-keygen -t dsa

Оставьте фразу для пароля пустой. Запустите эту команду от пользователя, запускающего узел Buildbot на хост-машине KVM. Результирующий файл /.ssh/id_dsa.pub потребуется ниже для каждой виртуальной машины.

Порт последовательного канала

ВМ настраиваются для использования (эмулируемого) последовательного порта в качестве консоли. При запуске KVM на хосте консоль отображается в stdin/stdout. Это полезно для получения сообщений журнала ядра, чтобы проще отладить любые проблемы. Загрузчик Grub также настроен для использования последовательного порта.

ВМ также настроены для вывода приглашения входа на последовательном порту (запуск getty). Впоследствии это оказалось не очень необходимым, так как если нужно вручную войти и исследовать вещи, часто проще просто запустить KVM в графическом режиме. Это может быть полезно в случаях, когда хост-машина удалённа (в этом случае графический режим всё ещё работает, но может быть немного медленнее).

Для настройки последовательной консоли ниже ссылаются на два файла и их нужно подготовить заранее:

ttyS0

# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc2
start on stopped rc3
start on stopped rc4
start on stopped rc5

stop on runlevel 0
stop on runlevel 1
stop on runlevel 6

respawn
exec /sbin/getty 115200 ttyS0

ttyS0.conf

# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/getty -L 115200 ttyS0 vt102

Безответственная установка MariaDB на Debian/Ubuntu

my.seed

Пакет MariaDB (и MySQL) на Debian и Ubuntu запрашивает у пользователя пароль для root. Мы хотим проверить этот важный шаг, но, разумеется, не хотим запрос. Для этого мы используем следующий конфигурационный файл для значений по умолчанию для debconf. Этот файл необходим в шагах ниже под именем «my.seed» (будьте внимательны, чтобы сохранить его точно так, как здесь, включая все пробелы и табуляции!)

    mariadb-server-5.1	mysql-server/root_password_again	password	rootpass
    mariadb-server-5.1	mysql-server/root_password	password	rootpass
    mariadb-server-5.1	mysql-server/error_setting_password	error	
    mariadb-server-5.1	mysql-server-5.1/nis_warning	note	
    mariadb-server-5.1	mysql-server-5.1/really_downgrade	boolean	false
    mariadb-server-5.1	mysql-server-5.1/start_on_boot	boolean	true
    mariadb-server-5.1	mysql-server-5.1/postrm_remove_databases	boolean	false
    mariadb-server-5.1	mysql-server/password_mismatch	error	
    mariadb-server-5.1	mysql-server/no_upgrade_when_using_ndb	error	

Для дополнительной информации см. здесь. Файл my.seed можно сгенерировать из существующей установки с помощью debconf-get-selections.

sources.append

Для Debian/Ubuntu мы добавляем локальный репозиторий в список источников apt, чтобы иметь возможность протестировать `apt-get install`. Для этого должен быть подготовлен файл «sources.append»:

deb file:///home/buildbot/buildbot/debs binary/
deb-src file:///home/buildbot/buildbot/debs source/

Параметры эмуляции

У эмулированной сетевой карты по умолчанию в KVM низкая производительность. Чтобы решить эту проблему, мы вместо этого используем сетевое устройство «virtio», используя параметры KVM «-net nic,model=virtio -net user». За исключением Debian 4, который имеет старое ядро без поддержки virtio. Дополнительная информация здесь.

Отметим, что некоторые 32-битные ВМ аварийно завершали работу во время загрузки с параметрами по умолчанию. Это было исправлено с помощью параметра kvm «-cpu qemu32,-nx». Дополнительная информация здесь.