GITLAB CI CD сокращаем код. Gitlab ci include, extends, reference, remote, local
Vložit
- čas přidán 10. 04. 2022
- Надежный хостинг FirstVDS! Переходи по ссылке и получай скидку 25% на первый месяц на любой тариф firstvds.ru/s/gjdwe
Бывает такое: смотришь на yaml файл pipline, а он похож на какой-то рулон туалетной бумаги. Листаешь листаешь, и ловишь какое-то дежавю. Этото код был сверху. В этом видео я раскажу как уменьшить твой конфиг gitlab ci cd c помощью include, extends и как собрать pipline из кусочков в помощью reference.
#ityoutubersru #ityoutubers #gitlab
ХОТИТЕ ПОМОЧЬ РАЗВИТИЮ КАНАЛА?
★ Станьте спонсором канала / @pavlenkoat
★ Boosty (подписка донаты) boosty.to/pavlenkoat
★ Яндекс.Деньги: money.yandex.ru/to/4100124083...
★ www.donationalerts.com/r/pavl...
★ www.tinkoff.ru/rm/pavlenko.an...
КОНТАКТЫ:
✦ Канал в TELEGRAM: t.me/worlditech (worlditech)
✦ DevOps/SRE чат t.me/devopssre
✦ Чат для Сисадминов и эникеев t.me/sys_hell
✦ Linux чат в TELEGRAM: t.me/linux_wit - Věda a technologie
Напишу приятный комментарий
Спрашивал у chat gpt как делать темплейты - получил кукиш
искал информацию в инете как делать тепмлпейты - получил ответ что только в ee версии
смотрел видео бусурманов - получил какие-то тыкалки в ui, которых у меня в gitlab-ce нет
Наконец то нашел видео как делать темплейты и сделал ЛАЙК
Четко, коротко, понятно!
Ничего лишнего и с оригинальной подачей!
Спасибо, Антон!
Даже захотелось больше погрузиться в работу пайплайнов))
Спасибо, Антон!
Спасибо за твои ролики. Только начинаю вплывать в тему CICD эта информация очень вовремя.
Спасибо, Антон! Задорный стиль изложения, доходчивое объяснение. Приятнее нежели документацию читать ))
спасибо, коментарий для продвижения канала
Огромное спасибо!)
Спасибо большое за контент!
Приятный комментарий: Спасибо это была полезная информация, как раз этим занимаюсь, но использовал только include и extends
Про reference не знал, спасибо!
Рад что полезно
Спасибо!
Шикарно. Побольше бы контента по gitlab ci
Да что-то просмотров мало
@@pavlenkoat айти тусовка ведь тоже не велика))
Авот и приятный или не очень комментарий,
Спасибо за работу!
Ах, вот ровно день назад сам все это обнаружил. Хорошая тема для видео
Знал всё кроме последнего (референс) - спасибо.
Не все понял, но мне понравилось, классный канал
Ко всему надо подходить из практических соображений. Если пайплайн - как рулон, то шаблоны - очевидное спасение. Но есть и обратная сторона медали.
Когда есть один мелкий микросервис, а половина его пайплайнов разбросана по разным репозиториям.
И вот, чтобы это все принять, приходится скакать между ними как сайгаку и смотреть откуда что берется, хотя весь пайплайн умещается на паре страниц кода с применением того же extends внутри одной репы.
Еще нужно учитывать, что переменные определенные в bash'e через export, например - в before_script и script не передаются в after_script.
Для этого лучше использовать репу с шаблонами. Я так и поступаю.
@@pavlenkoat Я немного о другом. Если приложения в группе репозиториев однотипные и не выходят за пределы группы - то да, маст хев.
Но бывает так, что в одном шаблоне не получится описать все для всех, и начинают плодиться разного рода сущности вида .tempalte_mongo_sync_api_migrate_mock
И все они отличаются не большими изменениями и годами не меняются. Потом начинается dependency hell.
И если репозиторий не твой, а достался в наследство - то добавлять в шаблон - черевато изменениями других сервисов, о которых ты пока не знаешь.
И процесс этот получается долгим и мучительным с несколькими вкладками в IDE для разных проектов и их сверкой.
Я сейчас для "будущей смены" делаю так, чтобы прочитать мой пайплайн было проще. Для этого большие однотипные куски выношу в tech репу (там же, шаблоны для чартов, сборки БД с данными и тп), в той же группе проектов, а мелкие куски добавляю через extends в .gitlab-ci.yml. В одной группе может быть до десяти и больше разных проектов, которые используют tech репу. Но для других таких групп, я стараюсь делать их собственную tech репу, чтобы изменения в ней, касались только той группы проектов и никак не влили на другие проекты.
Часто используемые в скриптах команды, по возможности параметризируеммые через переменные, можно обозначить как якоря, сделать для них понятный нейминг, и потом в скрипт вставлять *имя_якоря.
Молодец!
вот это годноту подвезли, автор канала просто красавчег! Темка сверхактуальная.
В GitLab CI довольно удобно и гибко настраиваются паплайны. Но вот тонкости... Они как раз и заставляют "попотеть". Как пример раздел "rules" в job'е: при использовании extend и добавлении нового правила, rules из "оригинальной" job'ы затрутся. А "! reference" как-то странно сливает rules
Лично выкрутился через YAML якоря
А видео очень полезное! В особенности для начинающих :)
Огромное спасибо за ваш контент!
У меня у всех микросервисов были одинокые rules, которые зависели лишь от переменных конкретного микросервиса
Отличный и, самое главное, понятный гайд, по неочевидной теме.
Очень понравилось
очень нужный плейлист gitlab ci/cd развивайте его пожалуйста, лайк!
Накидал видео
Как же вовремя вышло это видео. Спасибо
Вместо reference в script, имхо, гораздо проще использовать анчеры. Благо в секция script gitlab-ci интерпретирует вложеные листы (даже глубокой вложености) как 1 плоский лист. Таким образом подготавливаем наши атомарные кусочки конфигурации как анчоры с листом из баш кода и добавляем их анчорами в скрипт. Так же кусочки анчоров можно объединять в более высокоуровневые анчоры и так же использовать их в скрипт, гитлаб их так же пережёвывает.
Очень интересный кейс! А главная отличная доходчивая подача
Ты Большой Молодец ! Был бы очень признателен что бы у тебя появился какой нибудь большой курс по Bash Script от Zero 2 Hero или что то на подобие. У меня в компании мне все чаще надо писать Bash скрипты для автоматизации процессов. Например для интегральных проверок Aide или по копированию MariaDB и потом скармливания результата скрипту Nagios (который так же мне надо сделать). Хотелос бы еще раз все освежить в памяти и что бы доступным как ты умеешь языком.
спасибо )
в будущем пригодится )
все понятно объяснил
Спасибо за информацию. Хотелось бы узнать как для определенной задачи использовать свой образ докер, а не выкачивать с хаба
Спасибо за твой подход к объяснению) ты забавный и полезный )
Я ищу баланс сейчас. Раньше юморка было больше.
@@pavlenkoat имхо в этом видео идеальный баланс. хотя я всегда за юмор)
Комментарий поддрежки
Приятный или не очень комментарий! =)
Спасибо за видио
Можно ещё добавит в пейплайн when и only = огонь .
before/script/after - списки, поэтому их нельзя расширить, их можно только смержить
для справедливости стоит добавить, что экстенды делают код не только меньше, но и запутаннее.
к слову, docker-compose выпилили у себя этот функционал ещё 5 лет назад, начиная с v3, не смотря на истошный вой пользователей, драма до сих пор открыта ))
мотивировали это тем, что код с использованием экстендов становится очень запутанным и не поддерживаемым, но основная причина в том, что они не могут больше это поддерживать, возникает неопределённое поведение.
в общем, там ребята закопались в своём коде ))
Всё хорошо в меру и таблетками можно себя угробить.
Фон огонь 🔥
привет
Дженкинс юзаешь? Или ток гит?
Сейчас нет, но с ним работал
Чувствую я не стану DevOps так просто(((
годный контент, но в связи с тем что gitlab покрасился в жевто-блакитный цвет стал вопрос о целесообразности продолжения использования gitlabci...
200 строк на 4 джобы это не туалетная бумага))
Посмотрел пару видосов. Полезное есть, но слишком много лирических отступлений. Хочется вот прямо мяса, а получаешь больше макарошек)
Мясо никто не смотрит. Всё любят овощи
Firstvds Дааааа
Антон после развода посвежел.
А вот и не работает extends, слову вообще ничего из этого видео не работает
заинключить темплейт получилось так:
include:
- project: 'INFRA/pipeline_templates'
ref: master
file: '/.kubernetes_deploy_template.yaml'
а вот к маске привязать уже не выходит