Для чего юзают Docker, с какой целью его применять для автотестинга ?

инфраструктура docker
, , , ,
#1

Всем привет.

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

Буду очень благодарен, если кто-то опишет на пальцах в чем фишка его использования при автоматизированном тестировании.
Может быть даже приведет пример со своего проекта и pipeline CI/CD где этот докер задействован.

dcoekr
dcoekr1586×600 57.7 KB

1 лайк
#2

В первую очередь для быстрого и удобного переноса твоих тестов в другую среду выполнения.

2 лайка
#3

Что имеется ввиду под средой выполнения ? Другая OS ?
Для чего переносить тесты на другую среду выполнения ? Ведь автотесты проверяют функционал ( пусть в данном примере будут UI автотесты )

#4

Может и другая OS.
Например, если ты хочешь, чтобы твои тесты запускались не только с твоего локального компьютера, но и на CI сервере.
Или, чтобы твой коллега мог просто запустить твои тесты, не устанавливая у себя на компьютере весь стек тестовых технологий (nodejs, selenium и т. д.).

#5

докер контейнер - это маленький образ куска операционной системы с нужными тебе зависимостями.
именно из-за того, что контейнер - это кусок операционной системы, ему нужна базовая ОС, внутри которой можно запускать какое-то количество контейнеров
ну и поскольку это кусок системы - контейнер менее требователен, чем полноценная виртуалка + контейнерам можно выделять например процессорные тики, а не целиком отдавать ядро или поток ядра
собственно вот

4 лайка
#6

Понятно. Спасибо.

#7

И каким макаром это делается ?
Прост делал обычный Hello World в докере.
Можете примерно расписать шаги, как создается docker image, чтобы я его мог передать коллеге ?
На примере простого проекта.
И что должно быть установлено у коллеги ?

#8

Насколько я понимаю (на примере java-тестов):
Берётся докер с java, нужным браузером (есть официальные докеры).
К нему добавляется мавен или грэдл для сборки проекта.
Добавляется код тестов.
Добавляется команда на сборку и запуск этих тестов.
Докер сохраняется в своём или открытом хранилище докеров.
Разработчик запускает нужный докер 1 командой, указывая откуда брать докер (из своего или открытого хранилища).

Т.е. исходя из примера - раз настроив такую сборку докера - вы гарантированно получаете запуск тестов в нужном браузере не важно где - у себя на машине, на машине разраба, или на каком-то сервере (т.к. они запускаются в докере).

1 лайк
#9

Понимаю.

Берётся докер с java, нужным браузером (есть официальные докеры).

ok, допустим нашел такой официальный образ

К нему добавляется мавен или грэдл для сборки проекта.

А как добавить мавен в этот же образ ?

Добавляется код тестов.

Как добавляется код тестов ?

Хотя бы примерные команды ?

#10

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

#11

Могу только посоветовать начинать с этого:

Основные команды в этом разделе - Dockerfile instructions.

Вот пример ещё (Start a Java instance in your app):
https://hub.docker.com/_/openjdk

1 лайк
#12

Не знаю, никогда не запускал Дженкинс в докере.
Возможно, что у вас уже есть готовая инфраструктура для докеров и вам надо развернуть быстро Дженкинс - тогда да, одной командой это всё разворачивается.

#13

Посмотрите фреймворк TestContainers. Вы один раз его попробуете и больше никогда не захотите использовать DB или Kafka (или любой другой внешний сервис) для интеграционных тестов вне контейнера. Там есть и Браузер с вебдрайвером, если к примеру нужно это запустить на CI-Агенте, где кроме Docker ничего нет.

Смысл в том, чтобы загрузить и поднять любой внешний для вашего приложения сервис или группу сервисов на время тестов, а потом безопасно убить. И каждый запуск получается stateless на свежем окружении. Также можно поднять несколько инстансов окружения и распараллелить тесты на уровне окружений без синхронизации в коде или каких либо коллизий между потоками (но это уже Kubernetes нужен).

И тут встает вопрос ресурсов Памяти и Процессора на машинах с Docker (или Kubernetes), то есть масштабирование ничем не ограничено кроме ресурсов.

1 лайк
#14

Ок, допустим такую ситуацию.
У меня написаны и бегают UI тесты с использование Java 8 + maven + TestNG + Selenide.

Я так понимаю, что теперь нужно написать Dockerfile.

Как мне узнать какой FROM вызывать первой строчкой в файле ?
FROM java
или
FROM maven ?

И еще такой вопрос:

  1. могу ли я в свой image включить уже созданные images другими людьми ? Если да, покажите пожалуйста примеры.
  2. Верно понимаю, что эти контейнеры понимает только докер. То есть не имея докера этот контейнер никак не запустить другими способами ?
#15

Нет. Вам нужно базовую теорию сначала изучить. Начать можно:

  • установить Docker для Linux или Windows (на свою тачку)
  • выполнить docker run -d -p 80:80 docker/getting-started
  • скачается image веб приложения getting-started и будет доступен на http://localhost
  • там много полезной информации для начала

Так вот в вашем случае вами тесты нет необходимости разворачивать в контейнере и писать Dockerfile не нужно.

Допустим вы хотите протестировать приложение docker/getting-started и у вас машина без chromedriver и браузера Chrome и вообще без интерфейса, но установлен Docker и docker-compose.

В файле docker-compose.yml описывается стенд приложение + браузер
version: "3.7"
services:
  browser:
    image: selenium/standalone-chrome:85.0
    ports:
      - 4444:4444

  testing-application:
    image: docker/getting-started
    ports:
      - 80:80
Запускаете этот файл docker-compose -f docker-compose.yml up -d
Вы можете зайти в приложение по http://localhost:80/, а к браузеру можете подключиться через RemoteWebDriver по http://localhost:4444/wd/hub
Между контейнерами в сети docker-compose DNS имена используются сервисов, то есть чтобы из контейнера браузера попасть на docker/getting-started нужно вводить в браузере http://testing-application:80

Пример, правда на котлин github.com/kochetkov-ma/pump-samples/tree/master/docker-sample
Достаточно просто запустить gradle docker-sample:test и если у вас установлен Docker + Docker-Compose и есть доступ до Docker Hub, то TestContainer все сам скачает и запустит docker-compose.yml, а потом убьет

1 лайк
#16

Это уже пройдено. С теорией знаком.

Хотелось бы услышать ответы на мои вопросы.

PS: > Так вот в вашем случае вами тесты нет необходимости разворачивать в контейнере и писать Dockerfile не нужно.
RLY ? Это почему это ?

#17

FROM maven:3.6.3-jdk-8 - Docker ( Supported tags and respective Dockerfile links )

Либо, вы можете посмотреть как этот докер получается - docker-maven/Dockerfile at 26ba49149787c85b9c51222b47c00879b2a0afde · carlossg/docker-maven · GitHub
Смодифицировать его и добавить ещё свои команды на копирование исходников тестов и запуск их.
Докер композ - как раз пример того как несколько докеров связывать, в каждом запускается какое-то приложение и они общаются (как Максим подсказал). Например - в одном докере компилятся и выполняются тесты, в другом - запускается само приложение, в третьем запускается браузер и в нём выполняются тесты. Можно это упростить до 1 докера в который вы сами копируете к тестам еще и сам браузер и у вас всё в одном.

1 лайк
#18

Dockerfile - это описание того, как собрать приложение, поместить его в какую то среду и запустить, чтобы оно работало в режиме сервера как правило.
Далее собранный образ публикуется в Registry и доступен для публичного использования.

Тесты не являются приложением которое работает в режиме сервера и собирать их в образ не имеет никакого смысла, хотя кто-то так делает для Kubernetes, но я считаю это ошибкой.
Тесты запускаются на ХОСТ машине, а тестируемое приложение разворачивается в контейнерах.
Если варианты с CI агентами в контейнерах, но я не буду углубляться в эту тему.

Ответы на ваши вопросы:

  • Да. Это называется базовый образ и указывается в самом начале Dockerfile FROM alpine - базовый образ Linux Alpine. Можно указать абсолютно любой.
  • Нет. Контейнеры может поднимать не только Docker. Сейчас реализаций уже довольно много, в том числе нативная встроенная в Linux, а также Podman и они понимают Dockerfile для сборки образа.
    Но пока стоит ориентироваться только на Docker
1 лайк
#19

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

#20
  • разработчики разработали приложение
  • положили код в репозиторий
  • затем собрали образ приложения в контейнер и положили в хранилище артефактов
  • вы где угодно скачиваете образ контейнера и сколько угодно копий запустили
1 лайк