Это заключительная часть серии из трех статей (первая статья, вторая статья), которые посвящены автоматизированному тестированию программных продуктов в Openshift Origin. В данной статье будут рассмотрены аспекты тестирования в контейнерах и особенности выстраивания CI/CD при участии таких продуктов как:

1. Openshit Origin — как система для развертывания тестовых окружений.
2. Jenkins — как инструмент непрерывной интеграции.
3. Testlink — как система управления тестами.

4. Robot Framework — как framework для написания тестов.

   
   

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

   
   

Быстрый старт:

1. Загрузить Vagrant образ и Vagrantfile
2. vagrant box add --name viewshift viewshift-1.0.box && vagrant up

Задача сборки:

Задача сборки подразумевает под собой сборку образа Docker с приложением "curl", которое в последующем будет участвовать в задаче тестирования.

Примечание: в качестве корневого процесса (PID 1) в контейнере используется supervisord. supervisord и другие похожие инструменты очень полезны в тех случаях, когда нужно завершить работу приложения полностью или управлять процессами удаленно.

Принципиальная схема:

Этапы:

1. Определяем переменные, которые будут задействованы в задаче:
   
   PROJECT — название проекта Openshift. Для данного проекта был создан ServiceAccount "jenkins", который обладает правами администратора в проекте. Данный ServiceAccount используется для доступа к проекту из Jenkins (данный аккаунт также используется в задаче тестирования).
   APP_NAME и APP_VERSION — условное название и версия приложения, которые, тем не менее, фигурируют в нескольких местах: название и таг результирующего образа Docker, название запускаемого Build и т.д.

   
   

2. После того, как требуемые переменные были определены (продумана гранулярность/отличимость задач в проекте), требуется разнести их по всем YAML конфигурациям Openshift и другим шагам Jenkins.

   
   

3. На данном этапе создается объект BuildConfig, на базе которого будет создан и выполнен объект Build.

   
   

4. Происходит запуск процесс сборки на основе созданного BuildConfig. В случае успеха результирующий образ будет помещен во внутренний Docker регистр.

   
   
5. Все созданные объекты удаляются вне зависимости от успешности сборки.

Задача тестирования:

Под задачей тестирования подразумевается процесс тестирования приложения "curl", которое взаимодействует с сервисом "nginx" по протоколу HTTP. Мы хотим удостовериться, что приложение работает корректно и проходит заданные тесты.

Принципиальная схема:

Этапы:

1. Определяем параметры, которые будут задействованы в задаче:
   
   PROJECT — название проекта Openshift.
   TESTPLAN — название тест-плана в Testlink. Задача завершится ошибкой, если указанный тест-план отсутствует в Testlink.
   APP_NAME и APP_VERSION — условное название и версия приложения, которые аналогичным образом как и в задаче сборки.
   TEST_CMD — переменная, которая содержит название исполняемого файла, который будет запущен внутри контейнера. Аргументы командной строки указаываются в соотвествующем шаге Jenkins.
   TEST_TIMEOUT — численное выражение, которое задает время ожидания выполнения команды внутри контейнера. По истечении данного времени Jenkins задача завершает своё выполнение с ошибкой.

   
   

2. см. задачу сборки.

   
   

3. На данном этапе задается конфигурация Testlink, в которой указывается: с каким сервером будет установлена связь, какой тест-план будет использоваться (из тест-плана загружаются все назначенные данном тест-плану тесты для последующего сравнения), под какой платформой проводилось тестирование и т.д. Всё это требуется для последующей публикации пройденных тестов обратно в Testlink и отображения отчета тестирования непосредственно в Jenkins.

   
   

4. Данный этап предназначен для создания Service. Создаваемые сервисы будут указывать на приложения, которые будут запущены позднее. Через данные сервисы осуществляется проверка доступности приложений.

   
   

5. На данном этапе создается Pod для приложения "nginx".

   
   

6. На данном этапе создается Pod для приложения "curl". Образом для данного контейнера является образ, который создается в процессе задачи сборки. В отличии от "nginx", в данный образ добавлен том данных "share", который позволит контейнеру коммуницировать с файловой системой рабочего узла.

   
   

7. После того, как все Pod созданы, требуется проверка доступности приложений через опубликованные раннее сервисы.

   
   

8. На данном этапе происходит запуск команды тестирования в Pod с последующим ожиданием завершения выполнения данной команды.

   
   

9. После прохождения всех тестов происходит копирование отчета о тестировании в workspace задачи для последующего иморта в Testlink.

   
   

10. На данном этапе указывается стратегия (может быть не одна) сопоставления пройденных тестов с тем, что было получено из указанного раннее тест-плана. В данном случае идет простое сравнение названий тест-кейсов. После всех операции происходит публикация отчета о тестировании в Testlink.

    
    

11. Помимо отчета Teslink в формате Junit присутствует отчет о тестировании в формате Robot Framework, который установит статус выполненной задачи исходя из пороговых значений пройденных тестов.

    
    
12. На данном этапе происходит удаление всех созданных в процессе выполнения задачи объектов Openshift.

Всё вместе:

Преимущества и недостатки тестирования в контейнерах:

Недостатки:

1. Только Linux. Развивается так называемая "легкая" виртуализация и стоит, наверное, ожидать изменений в ситуациии, но пока только Linux.
2. Единая версия ядра для всех контейнеров. Возможно в п.1
3. Только x86_64. Нет, безусловно, ваш образ может быть x86, но ядро будет x86_64. Для кого-то это может стать препятствием.
4. Отсутствие вложенного SELinux (вложенные CGroups существуют).
5. Отсутствие полноценного видеоустройства и доступа к экрану. Возможно в п.1

Плюсы:

1. Скорость работы и гибкость запускаемых окружений, высокая плотность.
2. Унифицированный способ доставки, переносимости и повторяемости приложений.

Заключение:

Openshift Origin в связке с другими инструментами позволяет добиться впечатляющей гибкости и эффективности. Продуманная схема именования проектов/объектов позволяет избежать возникновения ошибок при массовых запусках задач тестирования.

Благодарность:

Хочу выразить благодарность сотрудникам компании Google за то, что сделали такую замечательную платформу.

Хочу выразить благодарность сотрудникам компании Red Hat, которые сделали из замечательной платформы законченный продукт.

Полезные ссылки:

1. Minikube — быстрый способ познакомиться с Kubernetes
2. Minishift — быстрый способ познакомиться с Openshift
3. v2c — утилита для конвертации виртуальных машин в контейнеры
4. Почему для встроенного регистра используется IP-адрес вместо FQDN