Comments 27
Вы наводите порядок в хаосе и унынии gitlab'а, но инструментарий крайне болезненный.
Интрефейс между компонентами в форме переменных среды окружения работает ровно до того момента, пока в интерфейс не прилетает что-то структурированное (yaml с перменной, внутри которой cloud-init, внутри котого run секция). После этого где-то взрывается эскейпинг и становится грустно.
Вторая грустная часть (я не про вашу работу, она титаническая и впечатляет) в том, что нет возможности вести локальную отладку. Как пишется код на питоне? Шмяк-шмяк-редактор-подчеркнул, поправил, питон ругнулся, поправил, юнит-тест свалился, поправил, коммит, вроде, работает.
А как выглядит отладка на птичьем языке гитлаба? шмяк, коммит, опечатка, шмяк, коммит, опечатка, шмяк, коммит, подождал линтера, поправил, шмяк, коммит, подождал линтера, подождал тесты, свалилось. Шмяк-поправил, коммит, подождал линтеры, подождал тесты, подождал билд, свалилось. Конец рабочего дня, завтра продолжу.
tight loop у них нет, к сожалению.
Вы правы, механизм передачи через dotenv крайне хрупкий, к тому же есть ограничения не более 50 переменных и не более 5 кб. На данный момент мы обходим моменты с многострочными переменными через конвертацию в base64. Но нам никто не мешает сделать свою упаковку и распаковку переменных в обычный файл, который будет передаваться между job через artifacts. Будем думать в эту сторону.
С тестированием частично соглашусь. Сейчас мы можем протестировать всю логику исполнения action локально (ведь это python runtime), но полноценно эмулировать работу runner локально способа нет. Инструмент, который предоставляет gitlab для локального тестирования job крайне ограничен, но у них есть epic, чтобы исправить это.
Я не включил в статью ничего про тестирование, но у нас для этого написан небольшой инструмент, который позволяет описывать входные переменные и ожидания, таким образом мы автоматизируем функциональное тестирование в самом pipeline. Но как вы и сказали, эти тесты требуют коммита.
Касательно передачи переменных со структурой и большого объёма:
А что если рассмотреть возможность использования Consul или etcd?
Использование вышеописанных инструментов должно благотворно повлиять на скорость - избавляемся от работы с файлами и упаковки/распаковки этих файлов, как в случае работы с артефактами. И эти сервисы обеспечивают минимальный уровень отказоустойчивости, в отличии от тех же артефактов.
Интересная мысль, спасибо!
Тут нужно хорошо будет подумать в сторону безопасности. Так как etcd будет общий для всех запусков actions, то важно продумать разграничение данных, исключая чтение переменных из соседних actions.
Но мы не исключаем издержки на сетевые соединения, и если объем данных действительно большой, то мы зависим от сети до стороннего по отношению к gitlab сервиса. Но вероятно в общей картине повседневного использования, вариант с etcd будет производительней, хоть и более хрупкий, все же.
Но мы не исключаем издержки на сетевые соединения, и если объем данных действительно большой, то мы зависим от сети до стороннего по отношению к gitlab сервиса.
Будто в самом гитлабе нет сетевого взаимодействия между гитлабом и гитлаб Раннерами. Артефакты - сохраняются на S3 (после шага пайплайна, а перед следующим шагом выкачиваются) а метаданные запусков - в постгрес базе самого гитлаба. Так что возможно, что со своим хранилищем (только етсд не берите, лучше уж консул тогда) будет даже быстрее и надежнее… тут сложно давать какие прогнозы, все равно ошибёшься в одну или в другую сторону.
Работал с гитлабом последние два года и полностью согласен.
Субъективное мнение что гитлаб заточен под отдельных разработчиков и небольшие компании, где каждый пайплайн можно позволить себе копипастить между проектами.
Как только начинается какая-либо деятельность по стандартизации CI/CD в гитлаб - это или боль и слезы, или такие большие DIY как описаны в статье. Больше всего бесит что очевидные и, в принципе не большие, но важные проблемы в этом направлении давным давно зарепорчены юзерами в трекере гитлаба и висят там годами (например передача значений между джобами - сделано мягко говоря через жопу, документация почти отсутствует, намного проще самому в файле перемещать).
Проект в топике очень интересный, особенно тем что походу это боль в каждой большой компании на гитлабе. Нам пришлось делать очень похожое решение, но не такое продвинутое - мы просто сделали одну команд лайн тулзу со встроенным рантаймом которая покрывала все веб и stdin/stdout возможные сценарии (разные апи, ченжлог генераторы, версии и тд).
Всё что как либо касалось сборки самих проектов и было non-generic - пришлось отдавать самим командам разработчиков, так как поддерживать весь зоопарк стеков и версий просто не хватало рук. Многие команды сами делали shared pipelines yamls уже под свой стак в отдельном проекте, и уже от туда или делали нормальный импорт, или просто копипастили.
И весь этот цирк просто потому что в гитлабе нет нормального концепта реюза CI - да, есть импорт, референсы, даже yaml-якоря, но это просто убогий костыль копипастинга, который в итоге как-нибудь мерджит все куски в одну кучу и как нибудь.
Автор, если вы сможете зарелизить этот проект в опенсорс - я думаю он выстрелит очень быстро и найдет поддержку во многих компаниях.
А есть ли какой-то способ тестировать github actions локально?
По поводу GitHub Actions не возьмусь комментировать, так как не доводилось писать Actions.
А Gitlab Actions мы тестируем локально так:
Unit-tests. Так как у нас runtime это python, то мы можем покрывать тестами логику и code action type и template action type (jinja можно тестировать)
Есть идея для template actions использовать snapshot тестирование (когда мы делаем шаблонизацию и сверяем результат рендеринга)
Так как action это контейнер запущенный в gitlab runner, то мы можем локально запустить тот же контейнер, передав в него все необходимые переменные окружения. Результат исполнения у нас пишется в файлы (один для output variables, другой со структурой json, где и время исполнения, и exit code и ошибки, если были)
https://github.com/nektos/act Но там щас сломано выставление прав для джобы внутри контейнера, а автор ПР с фиксом на него подзабил
для гитлаба есть аналог (для локального запуска пайплайнов) - https://github.com/firecow/gitlab-ci-local - сам не тестировал, но недавно наткнулся.
Отличная работа!
Это не поможет вообще обойтись без ямла гитлаба и все в коде делать?
Начинал и заложил основу идеи и базу реализации runtime один человек. Сейчас нас трое и это один из продуктов нашей команды.
Это не унаследованная деятельность. Эту деятельность инициировал наш руководитель, head of devops, который более чем понимает важность этой деятельности. И как доказательство важности инициатив по DX, мы видим зарождение в компании подобных инициатив в других департаментах. Кажется, мы на пути к переходу из команд в рамках департамента к объединению таких инициитив в стрим, в рамках всей компании X5 Tech.
Я думаю это стечение нескольких обстоятельств:
Мы в X5 Tech, и наш заказчик это X5 Groups. Т.е. у нас лояльный, доверяющий заказчик - внутренний
У нас понимающее и стратегически мыслящее руководство, которое не только решает текущие задачи, но и инвестирует в подобные команды
У нас достаточный масштаб (около 3000 ИТ специалистов), чтобы подобные инициативы окупались
Молодцы! Что сказать. Звучит круто. И идея очень правильная - использовать те самые функции гитлаба, которые позволяют переиспользовать код. Как в виде инклюдов и экстендов, так и при помощи упаковки конкретных «атомарных» шагов в докер образ. Очень похожий подход, кстати, в почему-то не очень популярной системе concourse-ci - и из неё тоже можно череп ь вдохновение для новых кубиков “actions”.
Насчёт чего не обольщался бы - так это насчёт того, что сентри поможет статистику собрать по пайплайнам. Потому что чтобы статистику снимать, она должна корректно отправляться, а единственным источником правды по количеству и качеству запусков пайплайнов является сам гитлаб. По крайней мере в моменте времени, потому что пользователь задним числом из UI может старые джобы и пайплайны почистить, чтобы они не мозолили глаза. А в случае многообразия команд - получается, законтролировать прохождение всех необходимых этапов секурити чеков попросту невозможно. Ещё раз подчеркну - данные от пайплайна команды попросту могут не приходить. По разным причинам. И потом сматчить, что такая-то команда байпасснули проверки… это надо будет бегать по 100500 различных информационных систем (какой-нибудь внутренний портал со списком сотрудников/команд, потом в сам гитлаб, потом где-то искать мапинги - где чьё репо). В общем мрак.
Думал над этой проблемой и пока увидел два возможных решения - либо в окончательный артефакт на каждом этапе вшивать каждый новый кусочек информации о пройденном шаге (в виде метаданных и ещё подписывать это изменение эцп), либо делегировать запись информации внешнему сервису, который, конечно, же в лучших традициях жанра ещё предстоит написать ) Сервис завсегда может проверить откуда пришёл вызов и вытащить необходимые метаданные из того же гитлаб апи… в общем, целая история.
В общем - очень интересно будет послушать как вы вот этот вот энфорсмент правильных практик и кволити гейтов реализовали или ещё планируете сделать.
P.s. Очень рад, что за последнюю неделю не первая отличная статья из х5
У нас информация в сентри поступает по push модели, инициирует отправку сам action - на старте и при завершении. Action собирает инфу о контексте запуска и окружении в gitlab в этот момент, и засылает ее в сентри. Там мы уже можем на основе этих полей определять какой action в каких проектах используется, смотреть успешность запусков и прочие манипуляции делать.
Sentry это временное решение, но вероятно в какой-то момент придется строить систему сбора метрик, так как sentry все же ограничен по операциям с его данными.
Если говорить о задаче байпаса каких-то шагов, то тут у Gitlab есть хороший инструмент - Security Compliance. Он позволяет насильно включать какие-то шаги в пайплайн. Жаль что эта фича только в Ultimate.
@artemiyokulov поделитесь как именно реализовали интеграцию Backstage + Gitlab? Выглядит достаточно интересно в т.ч. для реализации выкатки новых репозиториев из шаблонов для разработчиков.
У backstage из коробки есть интеграция с gitlab для получения из него данных (наполнение каталога)
Работает это так:
в настройках backstage мы указываем какие группы и ветки сканировать
backstage подписывается на event stream от гитлаб и выискивает изменения в проектах которые подxодят под условия выборки
в каждом проекте в корне он ищем файл catalog-info.yaml (можно поменять путь и имя), в котором в формате kubernetes objects описан компонент
Что касательно создание из шаблона и публикация нового проекта в гитлаб. Тут тоже есть готовый компонент. Backstage использует для этого scaffolder plugin, который оперирует таким понятием как scaffolder action - кусок кода с определенным интерфейсом, который делают небольшую задачу. Среди встроенных actions есть gitlab:publish. Мы его форкнули и немного доработали под наши реалии и расширили функции. Там typescript, все очень легко дорабатывается. Вообще backstage это платформа, и в ее архитектуру заложена возможность расширения, что очень удобно сделано.
Мы собственно backstage сейчас и используем не только для создания Action из шаблона, но и для создания cloud-native web приложений на java/python/react.
"У нас есть желание открыть исходный код Gitlab Actions для использования его всеми желающими, так как инструмент завязан только на GitLab, и каждый, кто использует GitLab, может его к себе разместить и использовать. Будем вести работы в эту сторону."
вы хотите сделать Gitlab Actions в рамках компании X5 или поделиться со всем сообществом?
Хотелось бы со всем сообществом, потому что инструмент получился почти универсальным, зависит разве что от версии gitlab.
Чтобы поделиться со всеми, нам нужно:
провести рефакторинг кода (убрать из кода специфичный для компании нейминг)
понять как мы зависим от фич гитлаба (минимально необходимую его версию)
отрефакторить текущую документацию и написать много недостающих страниц
подумать над "пакетом" поставки
организовать contribution process, как это принято в open source, в чем у нас почти нет опыта
Спасибо за статью и огромную работу, взял себе на заметку. А по поводу опенсорса - не изменились ли ещё эти планы (скоро 9 месяцев :))? Очень уж интересно посмотреть на экшены внутри более подробно, чем в этой статье. Или хотя бы в виде статьи с описанием уже самой внутрянки экшена с парой тройкой примеров (например цепочку коммит, канико, релиз).
@artemiyokulov, еще раз скажу: титаническая и очень замечательная работа!
"У нас есть желание открыть исходный код Gitlab Actions для использования его всеми желающими, так как инструмент завязан только на GitLab, и каждый, кто использует GitLab, может его к себе разместить и использовать. Будем вести работы в эту сторону."
Если до этого дойдете, то с удовольствием попытаемся помочь в популяризации с нашей стороны как можем.
Спасибо большое, за отличную статью!
Для тех, кому интересно, за работой по созданию CI/CD каталога шаблонов в GitLab можно следить (и активно участвовать) через эпик: https://gitlab.com/groups/gitlab-org/-/epics/7462
В частности, прямо сейчас можно проголосовать, какое имя выбрать для этого каталога: https://gitlab.com/gitlab-org/gitlab/-/issues/355678 ;-)
Actions: как в GitHub, но в GitLab