Это заключительная часть серии из трех статей (первая статья, вторая статья), которые посвящены автоматизированному тестированию программных продуктов в Openshift Origin. В данной статье будут рассмотрены аспекты тестирования в контейнерах и особенности выстраивания CI/CD при участии таких продуктов как:
- Openshit Origin — как система развертывании тестовых окружений.
- Jenkins — как инструмент непрерывной интеграции.
- Testlink — как система управления тестами.
-
Robot Framework — как framework для написания тестов.
Для лучшей репрезентативности я подготовил образ Vagrant, который содержит преднастроенную среду из вышеперечисленных продуктов (все перечисленные в данной статье объекты и механизмы могут быть легко проинспектированы). Чтобы повысить градус понимания материала я создал две задачи: задачу сборки, задачу тестирования. Обе задачи разбиты на этапы и детально описаны.
Быстрый старт:
- Загрузить Vagrant образ и Vagrantfile
vagrant box add --name viewshift viewshift-1.0.box && vagrant up
Создание полноценного окружения не входило в мои планы, но проиграв несколько сценариев со связыванием minishift c docker контейнерами пришло понимание, что это категорически неудобно и чревато ошибками. Тренировать воображение читателей с помощью одного текста считаю бесполезным занятием.
По умолчанию окружение стартует в графическом режиме. Сделано это для того, чтобы обойти проблему с доступом к продуктам извне. Настроен автоматический вход пользователя. Пользовательский Firefox содержит сохраненные закладки и учетные данные для доступа к продуктам.
Системные пользователи user и vagrant имеют неограниченный sudo доступ.
Задействованное ПО:
Название | Версия | Учетные данные |
---|---|---|
Openshift | 1.5.1 | admin:admin |
Jenkins | 2.60.1 | admin:admin |
Testlink | 1.9.16 | admin:admin |
Gogs | 0.11.19.0609 | git:git |
Mariadb | 5.5.52 | root:root |
OpenShift Pipeline Jenkins Plugin | 1.0.47 | - |
TestLink Plugin | 3.12 | - |
Robot Framework plugin | 1.6.4 | - |
Post-Build Script Plug-in | 0.17 | - |
system | - | root:root |
system | - | user:user |
system | - | vagrant:vagrant |
SHA1:
0992d621809446e570be318067b70fe2b8e786b2 viewshift-1.0.box
Задача сборки:
Задача сборки подразумевает под собой сборку образа Docker с приложением "curl", которое в последующем будет участвовать в задаче тестирования.
Примечание: в качестве корневого процесса (PID 1) в контейнере используется supervisord. supervisord и другие похожие инструменты очень полезны в тех случаях, когда нужно завершить работу приложения полностью или управлять процессами удаленно.
Принципиальная схема:
Этапы:
-
Определяем переменные, которые будут задействованы в задаче:
PROJECT — название проекта Openshift. Для данного проекта был создан ServiceAccount "jenkins", который обладает правами администратора в проекте. Данный ServiceAccount используется для доступа к проекту из Jenkins (данный аккаунт также используется в задаче тестирования).
APP_NAME и APP_VERSION — условное название и версия приложения, которые, тем не менее, фигурируют в нескольких местах: название и таг результирующего образа Docker, название запускаемого Build и т.д. -
После того, как требуемые переменные были определены (продумана гранулярность/отличимость задач в проекте), требуется разнести их по всем YAML конфигурациям Openshift и другим шагам Jenkins.
-
На данном этапе создается объект BuildConfig, на базе которого будет создан и выполнен объект Build.
-
Происходит запуск процесс сборки на основе созданного BuildConfig. В случае успеха результирующий образ будет помещен во внутренний Docker регистр.
- Все созданные объекты удаляются вне зависимости от успешности сборки.
Задача тестирования:
Под задачей тестирования подразумевается процесс тестирования приложения "curl", которое взаимодействует с сервисом "nginx" по протоколу HTTP. Мы хотим удостовериться, что приложение работает корректно и проходит заданные тесты.
Принципиальная схема:
Этапы:
-
Определяем параметры, которые будут задействованы в задаче:
PROJECT — название проекта Openshift.
TESTPLAN — название тест-плана в Testlink. Задача завершится ошибкой, если указанный тест-план отсутствует в Testlink.
APP_NAME и APP_VERSION — условное название и версия приложения, которые аналогичным образом как и в задаче сборки.
TEST_CMD — переменная, которая содержит название исполняемого файла, который будет запущен внутри контейнера. Аргументы командной строки указаываются в соотвествующем шаге Jenkins.
TEST_TIMEOUT — численное выражение, которое задает время ожидания выполнения команды внутри контейнера. По истечении данного времени Jenkins задача завершает своё выполнение с ошибкой. -
см. задачу сборки.
-
На данном этапе задается конфигурация Testlink, в которой указывается: с каким сервером будет установлена связь, какой тест-план будет использоваться (из тест-плана загружаются все назначенные данном тест-плану тесты для последующего сравнения), под какой платформой проводилось тестирование и т.д. Всё это требуется для последующей публикации пройденных тестов обратно в Testlink и отображения отчета тестирования непосредственно в Jenkins.
-
Данный этап предназначен для создания Service. Создаваемые сервисы будут указывать на приложения, которые будут запущены позднее. Через данные сервисы осуществляется проверка доступности приложений.
-
На данном этапе создается Pod для приложения "nginx".
-
На данном этапе создается Pod для приложения "curl". Образом для данного контейнера является образ, который создается в процессе задачи сборки. В отличии от "nginx", в данный образ добавлен том данных "share", который позволит контейнеру коммуницировать с файловой системой рабочего узла.
-
После того, как все Pod созданы, требуется проверка доступности приложений через опубликованные раннее сервисы.
-
На данном этапе происходит запуск команды тестирования в Pod с последующим ожиданием завершения выполнения данной команды.
-
После прохождения всех тестов происходит копирование отчета о тестировании в workspace задачи для последующего иморта в Testlink.
-
На данном этапе указывается стратегия (может быть не одна) сопоставления пройденных тестов с тем, что было получено из указанного раннее тест-плана. В данном случае идет простое сравнение названий тест-кейсов. После всех операции происходит публикация отчета о тестировании в Testlink.
-
Помимо отчета Teslink в формате Junit присутствует отчет о тестировании в формате Robot Framework, который установит статус выполненной задачи исходя из пороговых значений пройденных тестов.
- На данном этапе происходит удаление всех созданных в процессе выполнения задачи объектов Openshift.
Всё вместе:
Преимущества и недостатки тестирования в контейнерах:
Недостатки:
- Только Linux. Развивается так называемая "легкая" виртуализация и стоит, наверное, ожидать изменений в ситуациии, но пока только Linux.
- Единая версия ядра для всех контейнеров. Возможно в п.1
- Только x86_64. Нет, безусловно, ваш образ может быть x86, но ядро будет x86_64. Для кого-то это может стать препятствием.
- Отсутствие вложенного SELinux (вложенные CGroups существуют).
- Отсутствие полноценного видеоустройства и доступа к экрану. Возможно в п.1
Плюсы:
- Скорость работы и гибкость запускаемых окружений, высокая плотность.
- Уифицированный способ доставки, переносимости и повторяемости приложений.
Заключение:
Openshift Origin в связке с другими инструментами позволяет добиться впечатляющей гибкости и эффективности. Продуманная схема именования проектов/объектов позволяет избежать возникновения ошибок при массовых запусках задач тестирования.
Благодарность:
Хочу выразить благодарность сотрудникам компании Google за то, что сделали такую замечательную платформу.
Хочу выразить благодарность сотрудникам компании Red Hat, которые сделали из замечательной платформы законченный продукт.
Полезные ссылки:
- Minikube — быстрый способ познакомиться с Kubernetes
- Minishift — быстрый способ познакомиться с Openshift
- v2c — утилита для конвертации виртуальных машин в контейнеры
- Почему для встроенного регистра используется IP-адрес вместо FQDN
Автор: livelace