Запуск E2E-тестов в кластере Kubernetes

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

Один из способов, которым это может работать, заключается в том, что при git push вы создаете свой образ, затем, используя свою диаграмму управления, вы развертываете весь стек с этим новым изображением, затем вы запускаете другой контейнер, который запускает тесты e2e. В зависимости от того, как вы развертываете, вам, возможно, придется поставить в свой контейнер e2e, где ваше развертывание

Другой способ - у вас есть развертывание внешнего интерфейса, которое указывает на открытое тестовое развертывание вашего внутреннего интерфейса. Назовем развертывание внутреннего тестирования и развертывание интегрированного тестирования внешнего интерфейса. С точки зрения кода передняя часть является главной, но указывает на бэкэнд, который может вообще не работать. В git push to backend вы создаете и отправляете контейнер, затем устанавливаете образ на тестовом сервере, ждете развертывания и запускаете тесты для интегрированного тестового интерфейса. И вы должны сделать то же самое наоборот

У Helm действительно есть идея теста, которую можно используется для запуска тестовых команд. Но похоже, что ваш вопрос больше о том, как запустить тесты внутри контейнера. В этом примере показана одна команда оболочки, выполняемая в контейнере. В вашем случае, возможно, ваши тесты будут реализованы с использованием java или транспортира. Затем вы хотите создать контейнер, содержащий ваш тестовый код, и вызвать там команду для его запуска (например, mvn verify).

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

Ваша идея создания нового пространства имен и развертывания в звуках очень похожа на концепцию Jenkins-X создания среды предварительного просмотра и тестирования на ней для каждого запроса на вытягивание. Или, возможно, вы думаете просто о запуске тестов в выделенном пространстве имен промежуточного / тестового. В любом случае вы можете захотеть взглянуть на Jenkins-X. То, как он использует модули сборки, может представлять интерес, поскольку они выполняют шаги конвейера из кластера. Я думаю, что у gitlab есть похожая концепция. Но я понимаю, что вы, возможно, уже выбрали свое решение CI / CD.

Или вы можете посмотреть на это и решить, что проще запускать тесты вне кластера. Это означает преодоление препятствий, связанных с безопасностью, но означает, что вы можете запускать тесты, не помещая тесты в контейнеры. Я подозреваю, что это будет зависеть от ваших тестовых технологий, ваших настроек безопасности и вашего CI / CD.