Какие задачи пользователю нужно выполнять в рамках CI-пайплайна или при локальной разработке? Среди них может быть что угодно, но самое очевидное — это, наверное, запуск линтеров, всевозможных unit-тестов и получение покрытия и других отчетов по результатам выполнения команды. Также при разработке и отладке может быть полезен интерактивный режим, который позволит быстрее разобраться в проблеме или проверить гипотезу. Мы рассмотрим «классическое» решение этой задачи штатными средствами, а затем — простой пример, как Open Source-утилита werf помогает сократить трудозатраты на выполнение этих действий. Такой подход позволяет перенести нагрузку со сборочной или локальной машины в кластер Kubernetes, что дает возможность упростить масштабирование и обслуживание инфраструктуры, а также избавиться от зависимости от Docker. Попробуем протестировать приложение в контейнере Docker с ручным запуском. Для этого создадим простое приложение на Go, выполняющее одну задачу — вычисление площади прямоугольника: Убедимся, что все работает. Скомпилируем программу и запустим: Теперь добавим простой тест, проверяющий, что функция подсчета площади работает верно. Создадим файл main_test.go: Запустим тест, чтобы убедиться, что все работает корректно: Теперь соберем из нашего тестового приложения Docker-контейнер. Для этого добавим Dockerfile в корень проекта: Соберем контейнер и убедимся, что все работает: Исходные коды приложения можно найти в репозитории. За'push'им собранный контейнер в container registry: Создадим в Kubernetes-кластере отдельное пространство имен и Secret для доступа к container registry: Развернем созданный контейнер в кластере и выполним тесты приложения: Контейнер запустился в Pod’е, выполнил тесты и до сих пор висит в состоянии Completed. Удалим его: Итак, мы собрали контейнер с приложением, создали пространство имен и Secret с доступами к container registry в нём, затем, используя все данные с предыдущих шагов, запустили Pod с нашим образом и командой запуска тестов. Последним шагом удалили оставшийся Pod. Теперь давайте сделаем то же самое с помощью werf. Для этого воспользуемся новой командой werf – werf kube-run. Она отчасти аналогична уже знакомой пользователям утилиты команде werf run, но в отличие от последней создаёт Pod в K8s-кластере, а не запускает локальный контейнер. Чтобы werf смогла собрать контейнер и задеплоить его в кластер, нужно создать файл werf.yaml в корне проекта: Здесь мы указываем название проекта, наименование создаваемого образа и Dockerfile, из которого будут браться инструкции для сборки. Для работы werf необходимо, чтобы все файлы проекта находились в Git-репозитории. Инициализируем новый репозиторий в корне проекта: Запустим выполнение тестов в кластере командой: Здесь мы указываем репозиторий, в который werf за'push'ит собранный образ, и команду, которую необходимо выполнить: go test. Подробнее о команде и ее настройках (доступных флагах) можно прочитать в официальной документации. После выполнения увидим примерно следующее: Стоит отметить, что в целях демонстрации мы используем Docker-сервер для сборки тестового образа, чтобы не усложнять статью особенностями сборки с Buildah. Однако такой режим работы тоже доступен в werf и позволяет собирать образы без Docker-сервера (подробнее про настройку окружения с Buildah можно прочитать в документации). Все запустилось и выполнилось. Проверим, что Pod, в котором запускались тесты, удален: Все действия werf выполняет в рамках одной команды, автоматизируя рутину и позволяя пользователю сосредоточиться на выполняемой задаче. По умолчанию команда действует по следующему алгоритму: Берёт параметры доступа для указанного $WERF_REPO из ~/.docker/config.json. Создает в кластере Image Pull Secret с этими параметрами (для доступа к приватным container registry). Создаёт в кластере Pod с указанной командой, монтирует к нему созданный Pull Secret. После завершения работы Pod'а удаляет созданные Image Pull Secret и Pod. Мы рассмотрели простой запуск команды во временном Pod’е. Возможны и другие, более сложные, сценарии использования werf kube-run. Взглянем на несколько таких примеров — уже без практики, а с целью лучше раскрыть ее возможности.  Запустить выполнение тестов в ранее созданном Pod’е (например, frontend_image)  можно командой: Запустить тесты в Pod’e, но перед выполнением команды скопировать файл с секретными переменными окружения в контейнер: Запустить тесты в Pod’е и получить отчет о покрытии: Выполнить команду по умолчанию для созданного образа в Kubernetes Pod с установленными параметрами CPU: Мы рассмотрели решение проблемы запуска разовых задач в кластере Kubernetes с помощью новой команды утилиты werf. Она позволяет сэкономить немного времени при выполнении таких задач, а также перенести нагрузку, с ними связанную, в кластер. С вопросами и предложениями ждем вас в комментариях к статье, а также в Telegram-каналe werf_ru, где  700+ участников и всегда готовы помочь. Также мы всегда рады правкам и улучшениям для проекта в виде Pull Request’ов для GitHub-репозитория werf. Полезные ссылки: Чат по werf, в котором на вопросы пользователей отвечают разработчики — если вдруг что-то пойдет не так или не получится.  Самоучитель по Kubernetes от команды werf для DevOps-инженеров и разработчиков с уроками по CI/CD созданию приложений и разворачиванию окружения с примерами для node.js, Spring, django, Python, Go, Ruby on Rails, Laravel. Читайте также в нашем блоге: «Новые возможности werf: CI/CD на основе werf и Argo CD»; «Запуск werf в GitLab CI/CD без Docker-сервера»; «Локальная разработка в Kubernetes с помощью werf 1.2 и minikube».  Technical writer, Linux-user