Понятно. Спасибо.
И каким макаром это делается ?
Прост делал обычный Hello World в докере.
Можете примерно расписать шаги, как создается docker image, чтобы я его мог передать коллеге ?
На примере простого проекта.
И что должно быть установлено у коллеги ?
Насколько я понимаю (на примере java-тестов):
Берётся докер с java, нужным браузером (есть официальные докеры).
К нему добавляется мавен или грэдл для сборки проекта.
Добавляется код тестов.
Добавляется команда на сборку и запуск этих тестов.
Докер сохраняется в своём или открытом хранилище докеров.
Разработчик запускает нужный докер 1 командой, указывая откуда брать докер (из своего или открытого хранилища).
Т.е. исходя из примера - раз настроив такую сборку докера - вы гарантированно получаете запуск тестов в нужном браузере не важно где - у себя на машине, на машине разраба, или на каком-то сервере (т.к. они запускаются в докере).
Понимаю.
Берётся докер с java, нужным браузером (есть официальные докеры).
ok, допустим нашел такой официальный образ
К нему добавляется мавен или грэдл для сборки проекта.
А как добавить мавен в этот же образ ?
Добавляется код тестов.
Как добавляется код тестов ?
Хотя бы примерные команды ?
А какое преимущество поднятого Jenkins в докере или просто Jenkins на сервере? Здесь тоже любой человек, может зайти в Jenkins и запускать тесты.
Могу только посоветовать начинать с этого:
Основные команды в этом разделе - Dockerfile instructions.
Вот пример ещё (Start a Java instance in your app):
https://hub.docker.com/_/openjdk
Не знаю, никогда не запускал Дженкинс в докере.
Возможно, что у вас уже есть готовая инфраструктура для докеров и вам надо развернуть быстро Дженкинс - тогда да, одной командой это всё разворачивается.
Посмотрите фреймворк TestContainers. Вы один раз его попробуете и больше никогда не захотите использовать DB или Kafka (или любой другой внешний сервис) для интеграционных тестов вне контейнера. Там есть и Браузер с вебдрайвером, если к примеру нужно это запустить на CI-Агенте, где кроме Docker ничего нет.
Смысл в том, чтобы загрузить и поднять любой внешний для вашего приложения сервис или группу сервисов на время тестов, а потом безопасно убить. И каждый запуск получается stateless на свежем окружении. Также можно поднять несколько инстансов окружения и распараллелить тесты на уровне окружений без синхронизации в коде или каких либо коллизий между потоками (но это уже Kubernetes нужен).
И тут встает вопрос ресурсов Памяти и Процессора на машинах с Docker (или Kubernetes), то есть масштабирование ничем не ограничено кроме ресурсов.
Ок, допустим такую ситуацию.
У меня написаны и бегают UI тесты с использование Java 8 + maven + TestNG + Selenide.
Я так понимаю, что теперь нужно написать Dockerfile.
Как мне узнать какой FROM вызывать первой строчкой в файле ?
FROM java
или
FROM maven ?
И еще такой вопрос:
- могу ли я в свой image включить уже созданные images другими людьми ? Если да, покажите пожалуйста примеры.
- Верно понимаю, что эти контейнеры понимает только докер. То есть не имея докера этот контейнер никак не запустить другими способами ?
Нет. Вам нужно базовую теорию сначала изучить. Начать можно:
- установить 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
, а потом убьет
Это уже пройдено. С теорией знаком.
Хотелось бы услышать ответы на мои вопросы.
PS: > Так вот в вашем случае вами тесты нет необходимости разворачивать в контейнере и писать Dockerfile не нужно.
RLY ? Это почему это ?
FROM maven:3.6.3-jdk-8
- Docker ( Supported tags and respective Dockerfile
links )
Либо, вы можете посмотреть как этот докер получается - docker-maven/Dockerfile at 26ba49149787c85b9c51222b47c00879b2a0afde · carlossg/docker-maven · GitHub
Смодифицировать его и добавить ещё свои команды на копирование исходников тестов и запуск их.
Докер композ - как раз пример того как несколько докеров связывать, в каждом запускается какое-то приложение и они общаются (как Максим подсказал). Например - в одном докере компилятся и выполняются тесты, в другом - запускается само приложение, в третьем запускается браузер и в нём выполняются тесты. Можно это упростить до 1 докера в который вы сами копируете к тестам еще и сам браузер и у вас всё в одном.
Dockerfile
- это описание того, как собрать приложение, поместить его в какую то среду и запустить, чтобы оно работало в режиме сервера как правило.
Далее собранный образ публикуется в Registry и доступен для публичного использования.
Тесты не являются приложением которое работает в режиме сервера и собирать их в образ не имеет никакого смысла, хотя кто-то так делает для Kubernetes, но я считаю это ошибкой.
Тесты запускаются на ХОСТ машине, а тестируемое приложение разворачивается в контейнерах.
Если варианты с CI агентами в контейнерах, но я не буду углубляться в эту тему.
Ответы на ваши вопросы:
-
Да. Это называется
базовый
образ и указывается в самом начале DockerfileFROM alpine
- базовый образ Linux Alpine. Можно указать абсолютно любой. -
Нет. Контейнеры может поднимать не только
Docker
. Сейчас реализаций уже довольно много, в том числе нативная встроенная в Linux, а такжеPodman
и они понимаютDockerfile
для сборки образа.
Но пока стоит ориентироваться только наDocker
Верно - тесты, это не само приложение и нет смысла их заворачивать в image.
Тогда возвращаясь к первому посту: с какой целью его(докер) применять для автотестинга ?
Никак не могу уловить.
- разработчики разработали приложение
- положили код в репозиторий
- затем собрали образ приложения в контейнер и положили в хранилище артефактов
- вы где угодно скачиваете образ контейнера и сколько угодно копий запустили
Удобно в случае, если вам нужно запускать тесты параллельно, с использованием разных браузеров и OS, с разными переменными окружения, например, или версиями какой-нибудь синтегренной к приложению внешней библиотеки. В контейнере работает для этих целей тот же Selenium Grid.
Jenkins можно соответственно разворачивать там же, в контейнере. Но можно и не делать так.
Тесты можно не заворачивать в имейдж, но ранать их внутри него.
Пример - CI построенный на TeamCity, где на куче агентов ранаются джобы, в том числе и тесты.
Доступа к настройке окружения на агенте у тебя нет - можно либо оформлять кучу заявок на установку нужного тебе ПО, потом терзать инженеров, чтобы они донастроили то что тебе нужно, либо создать доккер имейдж настроенный как тебе надо, и ранать свои тесты внутри этого контейнера. Сам код тестов при этом каждый запуск пуллится непосредственно внутри контейнера, т.е хранится все по отдельности - код в своем репозитории, доккер в своем
В каждой CI есть возможность настроить агенты-контейнеры.
Они поднимаются в контейнере с git и другими приложениями пробрасывают сокет докера с хост машины, либо сами с докером внутри. А внутри контейнера уже разворачиваются еще контейнеры стенда - называется DockerInDocker (DinD).
Подкажите, с Selenide удобно использовать TestContainers?
С TestContainers удобно использовать как Selenide так и Selenium. Просо нужно из контейнера получить ссылку на remote web driver и записать в конфиг Селенида, например так Configuration.remote = "http://" + browser.host + ":" + browser.firstMappedPort
и все. Далее все будет происходить внутри контейенера.
А образ можно использовать например такой new BrowserWebDriverContainer<>(DockerImageName.parse("selenium/standalone-chrome:4.1.0"))
- он будет сразу с Хромом внутри и хромд-райвером под 4-ый селениум. Пример для Kotlin: selenide-pages/TestConfiguration.kt at main · kochetkov-ma/selenide-pages · GitHub