Комментарии 20
Я возможно не верно понял Makefile, но у вас в остановке контейнеров и их чистке нет фильтрации по CI_JOB_ID. т.е убиваются контейнеры из параллельных пайпов, которые возможно еще работают?
Все верно.
Задача по расписанию на очистку раннера настроена на 5 утра. В 5 утра крайне низкая вероятность, что кто-то будет что-то пушить.
Но, если возникла необходимость почистить стенд прямо сейчас, то да. Все запущенные контейнеры будут остановлены и выполняемые задачи с интеграционными тестами упадут. Но предполагается, что запускающий понимает последствия.
Еще момент. Для очистки стенда, фильтрация по CI_JOB_ID и не предполагается. Мы же раннер чистим в принципе, а не от «ошметков» какой-либо конкретной задачи.
Задача по расписанию на очистку раннера настроена на 5 утра. В 5 утра крайне низкая вероятность, что кто-то будет что-то пушить.
Но, если возникла необходимость почистить стенд прямо сейчас, то да. Все запущенные контейнеры будут остановлены и выполняемые задачи с интеграционными тестами упадут. Но предполагается, что запускающий понимает последствия.
Еще момент. Для очистки стенда, фильтрация по CI_JOB_ID и не предполагается. Мы же раннер чистим в принципе, а не от «ошметков» какой-либо конкретной задачи.
Ясно. Пропустил момент что вы чистите по расписанию, а не после сборки. А у вас места хватает тогда? У нас за рабочий день может быть до 100 сборок (тестируем каждый новый пуш коммитов во всех ветках). Если волумы не удалять сразу — за день гигов 100 мусора. И это с ограничением в 4 раннера.
Коммитов могло быть много, а пушей в репу вот не сильно много было. Чтоб 100 гигов за день, такого не помню.
В моей практике мы делали максимально удобно для локального запуска окружения/тестов. Разработчики прежде чем пушить гоняли тесты у себя локально. Но тут повторюсь все должно быть максимально удобно. И собрать и тесты прогнать (быстро), и в случае ошибок максимально информативные логи посмотреть. Как оказалось, разработчику проще локально все прогнать и чуть-что логи грепнуть, чем по ссылкам GitLab маневрировать.
В моей практике мы делали максимально удобно для локального запуска окружения/тестов. Разработчики прежде чем пушить гоняли тесты у себя локально. Но тут повторюсь все должно быть максимально удобно. И собрать и тесты прогнать (быстро), и в случае ошибок максимально информативные логи посмотреть. Как оказалось, разработчику проще локально все прогнать и чуть-что логи грепнуть, чем по ссылкам GitLab маневрировать.
А почему бы не фильтровать по дате запуска? Ну к примеру чистить только то, что живо более часа?
А с отменой мы вроде с помощью trap справляемся вместо after_script, но надо посмотреть точнее, возможно ошибаюсь.
А с отменой мы вроде с помощью trap справляемся вместо after_script, но надо посмотреть точнее, возможно ошибаюсь.
Почему не docker-runner и dind? Это решает проблему чистки раннера, а логи в виде артефактов так же можно сохранять и видеть в панели гитлаба.
Почему docker-compose v3? Вы же наверняка swarm не используете — так и используйте тогда v2.4
Почему docker-compose v3? Вы же наверняка swarm не используете — так и используйте тогда v2.4
НЛО прилетело и опубликовало эту надпись здесь
Нет. Вы все правильно говорите. С другой стороны, кто мешает пустить весь трафик через docker registry proxy, чтобы не скачивать образы из интернета?
Зато в плюсах у вас всегда «чистая» среда. Просто реально бывают кейсы, что образ скачан, в источнике он обновился, а пока ручками пулл не сделаешь, то и сборка пойдет на базе старого.
К тому же, между тестами можно сервисы пошарить. В общем, проблема со временем загрузки — надуманная.
Поэтому, кмк, dind — хорошая вещь.
гитлаб так не работает. Я сам долго допетрить не мог, но суть в том, что поднимается два контейнера.
Один — в котором бегут ваши тесты (и докер-клиентом, если нужно). А второй — с докер-демоном. Из контейнера с тестами с помощью docker cli можно сходить во второй контейнер и запустить еще контейнеров. А еще есть volume в котором лежат данные запусков… Рекомендую ознакомиться с документацией и поэкспериментировать.
Зато в плюсах у вас всегда «чистая» среда. Просто реально бывают кейсы, что образ скачан, в источнике он обновился, а пока ручками пулл не сделаешь, то и сборка пойдет на базе старого.
К тому же, между тестами можно сервисы пошарить. В общем, проблема со временем загрузки — надуманная.
Поэтому, кмк, dind — хорошая вещь.
Вы же имеете в виду запустить в dind-е демон docker, а потом в этом же dind-е запускать инстансы docker-compose?
гитлаб так не работает. Я сам долго допетрить не мог, но суть в том, что поднимается два контейнера.
Один — в котором бегут ваши тесты (и докер-клиентом, если нужно). А второй — с докер-демоном. Из контейнера с тестами с помощью docker cli можно сходить во второй контейнер и запустить еще контейнеров. А еще есть volume в котором лежат данные запусков… Рекомендую ознакомиться с документацией и поэкспериментировать.
dind — не нужен, ибо тру мозахизм. А вот образ dind с примонтированным docker.sock — вот это вещь! И кэширование работает!
Спасибо, очень интересно и полезно для новичка.
Действительно, почему не docker-runner и services?
gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/ci/docker/using_docker_images.md#what-is-a-service
Делаем свои образы с центральным логированием на основном, логи в артефактах забираем.
И concurrent на одной машине без изоляции — плохо. Лично сталкивался с этим багом gitlab.com/gitlab-org/gitlab-ee/issues/2588
Лучше сделать несколько раннеров, способных работать с одним инстансом системы.
gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/ci/docker/using_docker_images.md#what-is-a-service
Делаем свои образы с центральным логированием на основном, логи в артефактах забираем.
И concurrent на одной машине без изоляции — плохо. Лично сталкивался с этим багом gitlab.com/gitlab-org/gitlab-ee/issues/2588
Лучше сделать несколько раннеров, способных работать с одним инстансом системы.
Спасибо! Весьма полезно. А какую задачу вырешали выводя CI_JOB_ID в имя контейнера?
И знали ли при -p ключ у docker-compose? Что бы можно было делать например так
script:
- docker-compose -f .docker/docker-compose.yml -p ${CI_COMMIT_REF_SLUG}-tests build tests
- docker-compose -f .docker/docker-compose.yml -p ${CI_COMMIT_REF_SLUG}-tests up --exit-code-from tests tests
after_script:
- docker-compose -f .docker/docker-compose.yml -p ${CI_COMMIT_REF_SLUG}-tests down -v
А почему не использовать COMPOSE_PROJECT_NAME=CI_JOB_ID, в этом случае у всех контейнеров и сетей будет уникальное имя?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Решение выше предложил 411.
trap “<муваем логи в отдельную папочку>” ERR
make test
В этом случе, если make test завершится с ошибкой, то сработает перемещение логов в специальную папку, а дальше их уже собрать как артефакты. Если же все хорошо, то в логах пайплайна будет предупреждение, что артефакты не найдены.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GitLab Shell Runner. Конкурентный запуск тестируемых сервисов при помощи Docker Compose