Данная статья будет интересна как тестировщикам, так и разработчикам, но рассчитана в большей степени на автоматизаторов, которые столкнулись с проблемой настройки GitLab CI/CD для проведения интеграционного тестирования в условиях недостаточности инфраструктурных ресурсов и/или отсутствия платформы оркестрации контейнеров. Я расскажу, как настроить развертывание тестируемых окружений при помощи docker compose на одном единственном GitLab shell раннере и так, чтобы при развертывании нескольких окружений запускаемые сервисы друг другу не мешали. В моей практике частенько случалось "лечить" интеграционное тестирование на проектах. И зачастую первой и самой значительной проблемой является CI pipeline, в котором интеграционное тестирование разрабатываемого сервиса(ов) проводится в dev/stage окружении. Это вызывало не мало проблем: Кто-то скажет, что хорошие автотесты должны чистить данные после себя. У меня есть аргументы против:  По моему мнению, самое оптимальное решение — это динамическое окружение. У меня есть собственный GitLab раннер для своих проектов и с этими вопросами я столкнулся при разработке Java клиента для TestRail. А точнее при запуске интеграционных тестов. Вот далее и будем решать эти вопросы с примерами из данного проекта. К содержанию Для раннера рекомендую линуксовую виртуалку с 4 vCPU, 4 GB RAM, 50 GB HDD.
На просторах интернета очень много информации по настройке gitlab-runner, поэтому коротко: Если у вас менее 8 GB RAM, то рекомендую сделать swap 10 GB, чтобы не приходил OOM killer и не убивал нам задачи из-за нехватки RAM. Такое может случится, когда запускается одновременно более 5 задач. Задачи будут проходить помедленнее, зато стабильно.  Если в логах задачи вы увидите bash: line 82: 26474 Killed, то просто выполните на раннере sudo dmesg | grep 26474 И если картина выглядит примерно так, то или добавляйте swap, или докидывайте RAM. Открываем на редактирование /etc/gitlab-runner/config.toml и добавляем Это позволит запускать параллельные задачи на одном раннере. Более подробно читать тут.
Если у вас машинка помощнее, например 8 vCPU, 16 GB RAM, то эти цифры можно сделать как минимум в 2 раза больше. Но все зависит от того, что конкретно будет запускаться на данном раннере и в каком количестве. Этого достаточно. К содержанию Основная задача — это docker-compose.yml, который будет использован как локально, так и в CI pipeline. Для запуска нескольких экземпляров окружения будет использоваться переменная COMPOSE_PROJECT_NAME (см. makefile). Пример моего docker-compose.yml К содержанию Я использую Makefile, так как это весьма удобно как для локального управления окружением, так и в CI.  Далее комментарии инлайн  К содержанию В результате запуска такой задачи в артефактах директория logs будет содержать логи сервисов и тестов. Что очень удобно в случае возникновения ошибок. У меня каждый тест в параллели пишет свой лог, но об этом я расскажу отдельно.   К содержанию Задача будет запускаться только по расписанию. Далее идем в наш GitLab проект -> CI/CD -> Schedules -> New Schedule и добавляем новое расписание  К содержанию Запускаем 4 задачи в GitLab CI
 В логах последней задачи с интеграционными тестами видим контейнеры от разных задач  Артефакты задачи содержат логи сервисов и тестов
  Вроде все по красоте, но есть нюанс. Pipeline может быть принудительно отменен во время выполнения интеграционных тестов, и в этом случае запущенные контейнеры не будут остановлены. Время от времени нужно чистить раннер. К сожалению, задача на доработку в GitLab CE все еще в статусе Open Но у нас добавлен запуск задачи по расписанию, и никто нам не запрещает ее запустить вручную.
Переходим в наш проект -> CI/CD -> Schedules и запускаем задачу Clean runner   Итого: Время настройки — ~2 часа.
Вот, собственно, и все. Буду рад фидбэку. P.S.
Особая благодарность freeseacher vvasilenok ivanych. Ваши коментарии оказались очень ценными в контектсе публикации. К содержанию Head of QA / Quality Architect