Назад | Перейти на главную страницу

Тестовые примеры для проверки работоспособности образа виртуальной машины

Сейчас я работаю над своей домашней лабораторией, используя автоматизацию. В настоящее время я создаю образы Ubuntu, которые предполагается распространять среди моих студентов во время лабораторных работ.

Мне интересно: могу ли я создать тесты, которые можно запустить, чтобы убедиться, что обновленный образ можно использовать? Я был бы признателен, если бы вы предложили несколько тестов, которые имеют решающее значение для изображения.

Пример:

  1. Допустим, я недавно обновил образ (добавил новое ПО, патчи и т. Д.).
  2. Теперь я хочу запустить автоматические тесты, чтобы убедиться, что все работает: я хочу проверить, можно ли войти в систему с помощью графического интерфейса и определенных служб.

Одна из теорий тестирования сборников пьес Ansible: продолжайте добавлять задачи, делая то, что вы хотите. Думайте об этом как об утверждении желаемого состояния. Хорошо модули потерпят неудачу рано и громко, если не смогут выполнить задачу.

Допустим, вы хорошо относитесь к своим интерактивным пользователям и хотите предоставить tmux и Midnight Commander. Добавьте их в список пакетов

# in some vars file
packages:
- mc
- tmux

... с задачей установки.

# in some role's tasks file
- name: Install software for thing
  package:
    state: present
    name: "{{ packages }}"

Добавьте в список пакетов, если хотите установить больше. Что делать, если что-то для установки из стороннего репозитория еще недоступно? Перед вашей задачей пакета добавьте задачи для установки репо. И воспользуйтесь возможностью настроить автоматические обновления, если применимо.

Сделайте всю настройку в своей автоматизации. Шаблоны из файлов конфигурации. Включите и запустите службы. Сопоставьте пользователей с их открытыми ключами ssh и избавьтесь от паролей. Отображать информативный баннер при входе в систему. Что еще ты хочешь делать.

Поддерживайте тестового пользователя с такими же ограниченными привилегиями, как и у остальных пользователей. Протестируйте ssh, чтобы он работал, используя его учетные данные (ansible_user и ansible_ssh_private_key_file) и выполнение основной задачи.

Некоторые вещи, которые вы хотите проверить, не обязательно являются ошибками модулей. Измените способ сбоя задач, когда failed_when: выражение где необходимо. Добавить assert: задачи, проверяющие произвольные условия на переменных.

Когда playbook запускается против группы хостов, проблемные будут очевидны, потому что они потерпели неудачу.

Ansible - это инструмент на языке сценариев. Он подключается к хостам и запускает Python, Powershell или что-то еще. Графические интерфейсы - это не его дело. Получите какой-нибудь другой инструмент, если вам нужно автоматическое тестирование фактического запуска графического интерфейса и выполнения каких-либо действий.

Хотя, учитывая то, насколько быстро и точно вы сможете настраивать хосты, вам может не понадобиться много инструментов автоматического тестирования. Когда хост переходит от базового образа к настроенному за минуты, а не часы, возможно, это освобождает время для быстрой ручной проверки работоспособности перед каждым «выпуском», который вы делаете.