Comments 18
- У нас достаточно быстро прогоняются тесты. Перед каждым запуском создается новый хаб и нужные ноды, а после прохождения — уничтожаются. Поэтому пока не сталкивались с отказами хаба. И даже если это станет действительно проблемой, можно так же динамически создавать дополнительные хабы для проекта с тестами. Более вероятен сценарий, когда по каким-то причинам отваливаются вычислительные ноды. Но это решается на уровне Apache Mesos и Marathon.
- Для конкретного проекта поднимается свой единственный selenium grid. Поэтому хаб — один. А вот количество нод — это динамический параметр, который вычисляется в зависимости от количества тест-сьюитов в проекте. В статье указан пример для cucumber-проектов, когда параметр nodes_count рассчитывается bash-скриптом, и этот параметр мы передаем плейбуку перед созданием самого selenium grid-а для проекта. То есть для каких-то проектов это значение может равно 3, а для других — 15.
- Так как все проекты, которые мы тестируем, не обладают огромными количествами тестов, поэтому нам хватает одного грида. Изначально, задачи выбора конкретного хаба для проекта не было, и думаю, если будет, то тут можно будет легко подключить selenoid. Ведь он заточен именно под работу с несколькими хабами для проекта.
А вот расскажите, как себя ведёт в 2017 фантом? Как много провалов из-за ковшей самого фантома?
*ковшей=крашей
Мы изначально попробовали пойти этим путем. Но тут есть нюансы:
- PhantomJS не все поведенческие кейсы отлавливает, и после такого автотестирования, часть кейсов остается для ручного тестирования. В итоге эта не тот идеальный мир, к которому мы стремились бы, когда весь регресс полностью автоматизирован.
- с его помощью нельзя протестировать кроссбраузерность. Для Банка это очень важно. С использованием selenium grid в docker мы можем протестировать в большинстве популярных браузерах, кроме IE (пока).
Если у нас трехпоточный тест, то получится 3 параллельно выполняющихся потока с тестами. Т.е. поднимаются 3 сессии с драйвером браузера, которые поднимают браузер и выполняют тесты. Это реализуется на уровне test runner-а. Мы у себя реализовали такую логику, что runner-ы создаются по количеству тест-сьюитов в проекте и распараллеливаются. Это мотивирует тестировщиков более граммотно организовывать структуру тестового проекта, а также стараться в тест-сьюит группировать тесты по фичам. Таким образом, у нас не бывает ситуации, когда в проекте всего 3 тест-сьюита, и они выполняются долго из-за того, что очень много тестов внутри каждого из них. Сделали мы это с помощью самописного gradle plugin для cucumber.
В вашем случае работает все верно =) Когда маленький проект, и при этом нет потребности встраивать запуск тестов в continuous delivery — то можно и локально запускать.
Docker-compose пробовали. С ним на самом деле те же проблемы с Service Discovery, если вы пытаетесь с помощью Swarm поднять Selenium Grid в multimachine-режиме. Там есть дополнительные сложности с Overlay Network. Поднять на существующей инфраструктуре с Mesos получилось проще.
С чего он ест меньше ресурсов, чем запуск на обычной виртуалке?
Я бы понял, если бы вы взяли реальный железный сервер и там стали создавать докер контейнеры.
Почему не пошли проторенной дорожкой?
https://habrahabr.ru/post/322742/
Свой подход в подобной организации инфраструктуры мы пропилотировали еще в ноябре 2016 года. И до тех пор, пока не убедились в стабильности этого решения и его гибкости — публично нигде и не рассказывали. Поэтому, на момент нашей реализации — selenoid-а еще не было.
Я сравнивала работу selenoid-а с тем, как инфра организована у нас. Могу лишь сказать, что оба этих решения не конкурируют друг с другом с точки зрения функциональности. Потому что они решают немного разные задачи. И нам ничего не мешает на наш кластер с Apache Mesos прикрутить Selenoid, но тогда мы все-равно столкнемся с теми же проблемами, которые обозначены в статье с Service Discovery.
Также selenoid не решает задачу, обозначенную в самом начале статьи. Приведу в примерах:
- Когда поднимаешь на хосте selenoid, то необходимо самостоятельно вычислять, а сколько контейнеров потянет этот хост. Причем важно понимать, что для контейнера, запускаемом в debug-режиме, конфигурация будет отличаться. Например, если тесты мы можем прогонять на ноде в 512 мб RAM, то когда мы захотим запускать тесты в debug-режиме, исполнение тестов значительно замедлится. Потому что для debug-режима используется image с vnc-сервером, для производительной работы которого необходима конфигурация контейнера как минимум в 750 мб. У selenoid-а нет возможности задавать различные конфигурации контейнерам на одном хосте. То есть, если мы захотим запустить грид в debug-режиме, то придется менять конфигурационные настройки хостов. Это уже выглядит каким-то костылем.
- Когда у тебя много хостов, то задача настройки selenoid-а сводится к тому, что каждый этот хост надо законфигурить.Это много времени. И не достаточно гибко.
- Если хосты разного размера, то значит на каждом хосте может подниматься грид с каким-то определенным количеством нод. Например, если у меня один хост позволяет поднять только 10 нод, а остальные 15, то когда у меня запустится проект с потребностью в 15 нод — хост, законфигуренный под 10 нод, будет простаивать. Это не оптимальное использование существующих ресурсов.
- И наконец, каждый раз когда вы будете конфигурить хост, вам придется делать либо разного размера контейнеры, чтобы по-максимуму заиспользовать ресурсы хоста, либо какую-то часть ресурсов — просто не использовать. Это тоже не оптимально. В нашей же схеме mesos решает вопрос оптимального использования ресурсов в кластере.
Обьясню: один проект у вас исполняется в три потока на одном гриде, но на этом хосте поднят грид в 10 нод. То есть 7 нод свободны. И в тот же промежуток времени нам надо запустить тесты другого проекта, для которого нужно 7 нод, но с другим типом браузера и другой версией. Нам придется тесты запускать на другом гриде, где будет нужная конфигурация грида. А те 7 нод так и будут простаивать.
Надеюсь достаточно понятно объяснила.
В случае фиксированного количества нод селениума есть один довольно важный плюс — вы точно знаете, что вам хватит (или не хватит) ресурсов для запуска задачи.
Если тестов у вас всего 20 — это не страшно. А если у вас около 400 тестов и они запускаются по своим триггерам и плюс есть ещё CI, который тоже может дёргать эти тесты? Ресурсов уже может не хватать.
Вы эту проблему как-то пытались решить?
Минусы статического грида я уже описала в статье. Получается, как минимум в статике мы не сможем поднять все нужные нам конфигурации нод. А если вспомнить о том, как много мы ловили проблем именно из-за нестабильности хаба и нод в статическом состоянии, то текущая концепция on-demand полечила все наши боли по этому поводу.
По поводу проблемы нехватки ресурсов. У Marathon есть одна особенность, когда он не может задеплоить контейнер из-за нехватки места, то задача висит в статусе ожидания, пока не появится место. А нам же ничего не мешает запустить тесты на том количестве нод, места для поднятия которых хватило.
То есть, отправили запрос в marathon на поднятие грида в 20 нод, а место у нас есть только для 5ти. Грид соберется и тесты запустятся на этих 5ти нодах в в параллельном режиме, все остальные тесты будут висеть в очереди на хабе. Как только у нас будет освободождаться место в кластере, то остальные ноды начинаются доподниматься и количество параллельных потоков увеличивается.
Также есть защита от "дурака", встроенная в сам фреймворк с тестами. Так как все наши приложения — это single page приложения, то нам сложно представить для такого приложения тестов в количестве больше 100. Поэтому устанавливаем ограничение сверху по количеству потоков, который проект может сгенерировать.
Ну а так как у нас еще не было проектов с 400+ тестов, то и конкретной проблемы еще не возникало. Как мне видится, в текущей реализации мы словим лишь проблему того, что тесты в 5 минут не прогонятся, а значит мы заставим команду ждать отчет где-то 30 минут точно.
Спасибо за развёрнутый ответ.
С минусами статического грида я согласен. Сами с этим сталкивались, пришли к режиму автоматического перезапуска.
И, всё же, использование контейнеров с селениумом возможно только в тех случаях, когда на ферме гарантированно всегда хватает места для обработки минимум N заданий в очереди.
А то у вас наверняка рано или поздно будет вылезать ситуация, что в очереди висят задачи, которые приходится убивать только для того, чтобы протолкнуть тесты для третьего релиза за день, который и так задерживается… А вот тесты и багу словили, надо перезапустить… а там опять очередь… а в кластере уже докеры отдали под продакшн-контейнеры. И приходится либо тормозить билд, либо просить ещё пару машин докинуть в марафон.
Такого ещё не было? Будет :)
Все машинки были виндовые
А сейчас они виндовые? Если да, то как в контейнерах запускаете винду?
Ставим Selenium Grid на колеса Apache Mesos