Мы уже рассказывали, как/почему нам нравится Rook: в заметной мере он упрощает работу с хранилищами в кластерах Kubernetes. Однако с этой простотой приходят и определённые сложности. Надеемся, новый материал поможет лучше разбираться в таких сложностях ещё до того, как они себя проявят.

А чтобы читать было интереснее, начнём с последствий гипотетической проблемы в кластере.

Несмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!

Вводные

Для начала обозначу контекст:

• Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
• Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
• В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).

Kubernetes Dashboard — простой в работе инструмент для получения актуальных сведений о работающем кластере и минимального управления им. Начинаешь его ценить ещё больше, когда доступ к этим возможностям нужен не только администраторам/DevOps-инженерам, но и тем, кто меньше привык к консоли и/или не намерен разбираться со всеми тонкостями взаимодействия с kubectl и другими утилитами. Так случилось и у нас: разработчикам захотелось быстрого доступа к веб-интерфейсу Kubernetes, а поскольку мы используем GitLab, решение напросилось само собой.