Это заключительная часть серии из трех частей ( первая статья , вторая статья ), которые посвящены автоматизированному тестированию программных продуктов в Openshift Origin. В этой статье будут рассмотрены аспекты тестирования в контейнерах и особенности построения CI/CD с участием таких продуктов, как:
- Openshit Origin — как система для развертывания тестовых сред.
- Jenkins — как инструмент непрерывной интеграции.
- Testlink похож на систему управления тестированием.
- Robot Framework — как фреймворк для написания тестов.
Для большей репрезентативности я подготовил образ Vagrant, содержащий предварительно настроенную среду из вышеперечисленных продуктов (все объекты и механизмы, перечисленные в этой статье, можно легко проверить).
Для повышения уровня понимания материала я создал два задания: задание на сборку и задание на тестирование.
Обе задачи разделены на этапы и подробно описаны.
Быстрый старт:
- Скачать образ Vagrant И Vagrantfile
-
vagrant box add --name viewshift viewshift-1.0.box && vagrant up
Я считаю бесполезным занятием тренировать воображение читателей с помощью одного текста.
По умолчанию среда запускается в графическом режиме.
Это было сделано для того, чтобы обойти проблему с доступом к продуктам извне.
Настроен автоматический вход пользователя.
Пользовательский Firefox содержит сохраненные закладки и учетные данные для доступа к продуктам.
Системные пользователи user и vagrant имеют неограниченный доступ к sudo. Используемое программное обеспечение:
| Имя | Версия | Реквизиты для входа |
|---|---|---|
| Опеншифт | 1.5.1 | админ:админ |
| Дженкинс | 2.60.1 | админ:админ |
| Тестлинк | 1.9.16 | админ:админ |
| Гоги | 0.11.19.0609 | мерзавец: мерзавец |
| Мариадб | 5.5.52 | корень: корень |
| Плагин OpenShift Pipeline Jenkins | 1.0.47 | - |
| Плагин TestLink | 3.12 | - |
| Плагин Robot Framework | 1.6.4 | - |
| Плагин сценария после сборки | 0.17 | - |
| система | - | корень: корень |
| система | - | пользователь: пользователь |
| система | - | бродяга: бродяга |
Задача сборки:
Задача сборки предполагает создание образа Docker с приложением «curl», которое впоследствии будет участвовать в задаче тестирования.Примечание: корневой процесс (PID 1) в контейнере руководитель .
Supervisord и другие подобные инструменты очень полезны в тех случаях, когда вам необходимо полностью закрыть приложение или удаленно управлять процессами.
Принципиальная схема: 
? краны :
- Определим переменные, которые будут задействованы в задаче: ПРОЕКТ — название проекта Openshift. Для этого проекта была создана учетная запись ServiceAccount «jenkins», имеющая права администратора в проекте.
Этот ServiceAccount используется для доступа к проекту из Jenkins (эта учетная запись также используется в задаче тестирования).
ИМЯ ПРИЛОЖЕНИЯ И ПРИЛОЖЕНИЕ_ВЕРСИЯ — условное имя и версия приложения, которые, тем не менее, фигурируют в нескольких местах: имя и тег полученного Docker-образа, имя запущенного билда и т.д.
- После того, как необходимые переменные определены (продумана детализация/различимость задач в проекте), необходимо распределить их по всем YAML-конфигурациям Openshift и другим шагам Jenkins.
- На этом этапе создается объект BuildConfig, на основе которого будет создан и выполнен объект Build.
- Процесс сборки начинается на основе созданного BuildConfig. В случае успеха полученный образ будет помещен во внутренний реестр Docker.
- Все созданные объекты удаляются независимо от успеха сборки.
Задача тестирования:
Под задачей тестирования понимается процесс тестирования приложения «curl», которое взаимодействует с сервисом «nginx» по протоколу HTTP. Мы хотим убедиться, что приложение работает корректно и проходит указанные тесты.
Принципиальная схема: 
? краны :
- Определяем параметры, которые будут задействованы в задаче: ПРОЕКТ — название проекта Openshift. ПЛАН ТЕСТИРОВАНИЯ — название плана тестирования в Testlink. Задача завершится неудачно, если указанный план тестирования отсутствует в Testlink. ИМЯ ПРИЛОЖЕНИЯ И ПРИЛОЖЕНИЕ_ВЕРСИЯ — условное имя и версия приложения, аналогичные тем, что указаны в задаче сборки.
TEST_CMD — переменная, содержащая имя исполняемого файла, который будет запущен внутри контейнера.
Аргументы командной строки указываются на соответствующем этапе Jenkins. TEST_TIMEOUT — числовое выражение, задающее время ожидания выполнения команды внутри контейнера.
По истечении этого времени задача Jenkins завершается с ошибкой.
- см.
задачу сборки.
- На этом этапе задается конфигурация Testlink, в которой указывается: с каким сервером будет установлено соединение, какой план тестирования будет использоваться (все тесты, назначенные этому плану тестирования, загружаются из плана тестирования для последующего сравнения), под какой платформой было проведено тестирование и т. д. Все это необходимо для последующей публикации пройденных тестов обратно в Testlink и отображения отчета о тестировании непосредственно в Jenkins.
- Этот этап предназначен для создания Сервиса.
Созданные сервисы будут указывать на приложения, которые будут запущены позже.
Эти сервисы проверяют доступность приложений.
- На этом этапе создается Pod для приложения «nginx».
- На этом этапе создается Pod для приложения «curl».
Образ для данного контейнера — это образ, созданный во время задачи сборки.
В отличие от «nginx», в этот образ добавлен «общий» том данных, который позволит контейнеру взаимодействовать с файловой системой рабочего узла.
- После создания всех подов необходимо проверить доступность приложений через ранее опубликованные сервисы.
- На этом этапе в поде запускается команда тестирования и далее ожидается завершение этой команды.
- После прохождения всех тестов отчет о тестировании копируется в рабочую область задачи для последующего импорта в Testlink.
- На этом этапе указывается стратегия (их может быть несколько) сравнения пройденных тестов с тем, что было получено из ранее заданного плана тестирования.
В этом случае происходит простое сравнение названий тестовых случаев.
После всех операций в Testlink публикуется отчет о тестировании.
- Помимо отчета Teslink в формате Junit, существует отчет о тестировании в формате Robot Framework, который установит статус выполненной задачи на основе пороговых значений пройденных тестов.
- На этом этапе все объекты Openshift, созданные в ходе выполнения задачи, удаляются.
Вместе:
Преимущества и недостатки тестирования в контейнерах:
Недостатки:- Только Линукс.
Так называемое «легкая» виртуализация и, наверное, стоит подождать изменения в ситуации , но пока только Linux.
- Версия с одним ядром для всех контейнеров.
Возможно в пункте 1
- Только х86_64. Нет, конечно у вас образ может быть х86, но ядро будет х86_64. Для кого-то это может стать препятствием.
- Отсутствие вложенного SELinux ( существуют вложенные группы CGroups ).
- Отсутствие полноценного видеоустройства и доступа к экрану.
Возможно в пункте 1
- Скорость и гибкость запускаемых сред, высокая плотность.
- Унифицируйте доставку, переносимость и повторяемость приложений.
Заключение:
Openshift Origin в сочетании с другими инструментами обеспечивает впечатляющую гибкость и эффективность.Продуманная схема именования проектов/объектов позволяет избежать ошибок при массовом запуске задач тестирования.
Благодарность:
Хочу выразить огромную благодарность сотрудникам Google за создание такой замечательной платформы.
Хочу выразить благодарность сотрудникам Red Hat, которые превратили замечательную платформу в готовый продукт.
Полезные ссылки:
- Minikube — быстрый способ начать работу с Kubernetes
- Minishift — быстрый способ начать работу с Openshift
- Почему встроенный реестр использует IP-адрес вместо полного доменного имени?
-
Проблема С Суммой
19 Oct, 24 -
10 Атак На Веб-Приложения В Действии
19 Oct, 24 -
История Внедрения Сэд На Одном Предприятии
19 Oct, 24 -
Технические Фанаты Развлекаются
19 Oct, 24 -
Многопользовательская Архитектура Данных
19 Oct, 24
