Комментарии 14
Я дико извиняюсь, но, имхо, вся эта статья пропитана костылями.
Попробую защитить своё мнение.
Итак, мы получили пайплайн, который при фиксации изменений в репозитории запускает сборку проекта и затем докер-образа, публикует его в отдельном реестре, забирает и деплоит докером целевой машины. Благодаря гибкости докера все это мы проделали на локальном компьютере, но теперь, отладив процессы, легко сможем перенести их в производственную среду.
1) Я сторонник DevOps, но самостоятельное развёртывание и администрирование инстанса GitLab, имхо, не должно касаться стороны Dev. Это задача исключительно инфраструктурной команды. Я развёртывал в НИИ в 2015 году инстанс и пару лет админил его, так что это не диванная аналитика =)
1.1) Однако, ничего не имею против развёртывания своих раннеров. Настолько, что мне кажется более стройной идея установки раннера на целевой хост и запуск джобы с деплоем прямо на нём, без всех этих приключений с SSH-ключами.
2) Про поднятие своего реестра -- не уверен, кто-нибудь ниже мб меня поправит. Но если инстанс GitLab развёрнут нормально, в нём же есть встроенный и Image Registry, и Maven / npm Registry и т.п. (честно не помню, может что-то в платных Tier, но образы точно есть в бесплатном).
3) Зачем нам игнорировать базовый функционал раннера по скачиванию репы? Ради чего? Потому что у нас кривая среда?
4) У вас only.refs: main, а если MR из фича ветки в main кривой и всё ломает?
5) В таком виде процессы не "отлажены", я бы на прод это не допускал =)
Раз уж покритиковал, напишу свой вариант. Он, конечно, может быть к вашей ситуации неприменим, я не знаю всех тонкостей.
1) GitLab у нас один и управляется специалистами нужного профиля. Они же предоставляют общие раннеры (и желательно не privileged).
2) У нас есть джоба, которая собирает приложение, прогоняет тесты, пакует всё в образ и пушит в registry под управлением специалистов нужного профиля. На общем раннере, для любой ветки.
3) Для веток, соответствующим стендам (тест/прод), запускаются джобы с тегами раннеров, стоящих в этих средах. Раннеры на месте делают pull нового образа и рестарт приложа.
это статья-туториал(к сожалению не нашел такой опции при публикации, хотя раньше она была), т.е. этакий практикум для тех кто еще не знаком с темой, поэтому одной из главных ее задач является отработка потенциальных проблемных зон. Если их не рассмотреть, специалисту придется искать другие статьи, копаться на стековерфлоу в гугле и ассистентах. Мне в свое время как раз приходилось решать не только упомянутые проблемы, но и многие другие. Конечно, лучше быть здоровым и богатым, но в реальности все бывает по-разному. А для совсем стандартных решений типа использования встроенных или докерхабовских реестров существует официальная документация, правда в ней тоже не всегда могут быть такие квикстарты для новичков закрывающие сразу некоторый полный минимальный набор. А что-бы побеждать в борьбе с деревом официальной документации уже требуются некоторые знания и опыт. Поэтому для освоения технологии достаточно эффективным оказывается пройти сначала некий базовый туториал, а потом с пониманием идти в сторону улучшений. Программистам тоже приходится в этом ориентироваться, сейчас у каждого локально могут быть развернуты кластеры, каталоги, субд, что-бы разбираться и решать проблемы их использование часто оказывается необходимым и оправданным как раз в ситуациях с большими компаниями, когда хождение в официальную инфраструктуру требует долгих согласований, а сроки горят как по-аджайлу;)
1. Гитлаб, по моему опыту, - самое беспроблемное приложение, не требующее особого ухода. По крайней мере в команде из 10 человек. Я трачу на его сопровождение всего 10 минут в неделю: делаю бэкап, скачиваю новую версию образа (если успела выйти) и перезапускаю на новом образе.
1.1. Ваше предложение не масштабируется. Придется переделывать, когда возникнет необходимость деплоить более чем на один сервер. Плюс есть проблемы с безопасностью - прод не должен иметь доступ к деву, а в вашей схеме потребуется пробить дырку из прода к гитлабу.
2. Встроенный container registry появился в 2016 году и сразу был доступен для всех. А вот package registry (maven, npm и прочие) был изначально платным, но переехал во free tier в 2020 году. Видимо, автор в 2015 настроил CI до состояния "работает - не трожь" и теперь делится хоть и готовым, но, увы, устаревшим рецептом. А может он поленился узнать какими фичами вообще обладает гитлаб. Или просто теряется в имеющейся документации (как он пишет в комментарии выше).
1. Гитлаб, по моему опыту, - самое беспроблемное приложение, не требующее особого ухода. По крайней мере в команде из 10 человек. Я трачу на его сопровождение всего 10 минут в неделю: делаю бэкап, скачиваю новую версию образа (если успела выйти) и перезапускаю на новом образе.
Имея достаточно устаревший опыт (развёртывание omnibus в 2015-2017), я, скорее, соглашусь с этим. Действительно, установка и администрирование были простыми и времени особо не требовали.
Встроенный container registry появился в 2016 году и сразу был доступен для всех. А вот package registry (maven, npm и прочие) был изначально платным, но переехал во free tier в 2020 году. Видимо, автор в 2015 настроил CI до состояния "работает - не трожь" и теперь делится хоть и готовым, но, увы, устаревшим рецептом. А может он поленился узнать какими фичами вообще обладает гитлаб. Или просто теряется в имеющейся документации (как он пишет в комментарии выше).
Ну вообще нет, т.к. я перестал регулярно читать ежемесячные дайджесты по 22 числам только год назад, и сейчас читаю их просто нерегулярно.
Но хочу отметить, что я не являюсь сис.админом, в данный момент я исключительно разработчик. И считаю избыточным для разработчика самостоятельно развёртывать и поддерживать GitLab.
Я продолжаю придерживаться мысли, что GitLab в компании должен быть один и управляться сис.админами, их не должно быть по штуке на разработчика (локально в докере), и разделять инстансы гитлаба на дев/прод среду тоже не нужно. Если речь в статье про разработчика-одиночку, почему бы ему не воспользоваться облачным GitLab.com? Если статья написана про ещё более узкую ситуацию, то, имхо, это должно быть обозначено, а не приведено как универсальный quickstart для любой ситуации.
1.1. Ваше предложение не масштабируется. Придется переделывать, когда возникнет необходимость деплоить более чем на один сервер. Плюс есть проблемы с безопасностью - прод не должен иметь доступ к деву, а в вашей схеме потребуется пробить дырку из прода к гитлабу.
Извините, но не вижу, где оно не масштабируется. Я применяю эту схему на разных проектах. GitLab это не часть ни dev-среды, ни prod-среды, это инфраструктурный компонент, такой же, как и вероятно установленный где-то рядом Registry. Поэтому речь о пробитии дырки прод->дев некорректна, это дырка prod->infra.
Деплойте на сколько угодно серверов, из каких угодно веток. Разделите ветки стендов на protected и нет, чтобы обезопасить прод. Собирайте и пуште образы на общих раннерах, деплойте на "стендовых" раннерах, фильтруя джобы деплоя через фильтры only:refs и tags. Запретите Dev мержить в protected, только Maintainer.
Я продолжаю придерживаться мысли, что GitLab в компании должен быть один и управляться сис.админами
А что делать если вам надо отладить саму сборку или пайплайн и сисадмины такого точно не смогут?
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе? Часто это минимум команд, которые можно просто запустить из IDE, например та же сборка спринговым плагином сразу образа. Если сложнее, можно вынести все команды в .sh, и запускать его. Вариантов очень много, на самом деле.
Что значит отладить пайплайн? Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
Смотря, что вы имеете ввиду под этими словами. Сборка — скрипт, запускаемый в джобе?
некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу. Кроме того, это может быть какая-то новая для вашей ситуации технология или контекст. Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
Некий набор операций которые необходимы для преобразования исходников в артефакты для запуска на тестовых или продуктивных серверах: получение, сборка, упаковка, прогон тестов. Все они могут принадлежать разным источникам и иметь разную природу.
Полностью согласен с таким определением.
Девопсам или сисадминам, как минимум, могут потребоваться конкретные инструкции по настройке сложного процесса полностью понимать который будет только разработчик.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций. "Мне нужен доступ в интернет с общего раннера, чтобы скачать образ с gradle и jdk; мне нужен docker, чтобы собирать образы; мне нужен registry, чтобы хранить их; мне нужен shell-runner на таком-то стенде с тегом prod, чтобы деплоить туда". Если процесс убер-сложный, нужно его документировать, обсуждать, чтобы обе стороны понимали, что и как работает. Тогда это и есть DevOps.
Да. Но мне ещё здесь хочется добавить, что удобнее общаться в стиле декларативных зависимостей, а не инструкций.
просто не всегда бывает так, что вы можете все определить самостоятельно и решить задачу "с нуля", реестр может потребоваться использовать уже готовый и сторонний, например из артифактори или нексуса или того же докерхаба или аналога. Конкретно для программиста отдельный реестр удобнее в том плане, что гитлаб наигравшись можно выключить, а реестр оставить для поддержки других своих задач.
девопс это почти сисадмин готовый заниматься вопросами выше уровней сетевой маршрутизации, но он не программист и может и не знать для чего надо запускать препроцессоры или с какими профилями собирать. Конечно, надо ему эти знания как-то передать, но прежде чем это получится сделать этот процесс желательно проработать разработчику, т.к. если с какой-то проблемой застрянет девопс ему разобраться в особенностях наделанного программистами будет гораздо сложнее. Ну и я совершенно не возражаю против того, что бы этой статьей воспользовались сисадмины и девопсы, даже хочу им помочь как в плане получения базовых рецептов, так и специфики типа развертывания джава-приложений в контейнерах.
Если вы отлаживаете их на локальном инстансе, вы гарантируете, что настройки раннеров и всех других важных административных настроек идентичны тем, что на удаленной среде?
хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды, а одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами. Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
Хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды
Полностью согласен.
А одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами
Согласен, конечно, 12factor app никто не отменял =) Приложение отдельно, конфигурация отдельно.
Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
Смотрите, я триггерю на то, что в статье описывается развёртывание инстанса GitLab локально, и на то, что вы написали "отлаживать пайплайны". Всё это звучит так, будто это туториал по размножению инстансов гитлабов на своей машине, на тестовом стенде, на продовом стенде. Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
В том числе протестировать пайплайн, ситуация может быть различной, у вас могут быть отдельные виртуалки или железяки под все включая реестр, надо быть готовым ко всему. Специфика данной статьи - джава-проекты которые надо деплоить автоматически, докер как среда их выполнения, гитлаб как система неприрывной интеграции. Вы не становитесь сисадмином от того, что выполнеяте docker start локально или на выделенном сервере.
Не думаю, что во всех командах/проектах есть и разрабы и девопс.
Однако достаточно команд где разраб и сисадмины. Последние так привыкли всё делать только кликами мышки в UI ну или в крайнем случае давно написанными кем-то шелл-скриптами. В девопс идти не хотят.
И получается, что разраб вынужден в этой ситуации сидеть на двух-трех стульях постигая смежные области кроме весьма глубокой своей, повышая time-to-market.
Экономия времени на разворачивание тестовых окружений весьма кстати. Автоматизация одинаковых и рутинных действий сводит к минимуму ошибки. Бегать за девопс’ом чтобы он развернул тестовое окружение от которого мало что зависит, такое себе.
Да вероятно производственные среды лучше разворачивать под контролем человека, но не завязывать на него.
Данная статья - мануал для тех кто входит «в реку». И для нерадивых сисадминов и для разрабов столкнувшихся с «голой» инфраструктурой один-на-один при недостатке времени. По мере опыта и костыли уйдут и лучшие практики применятся. Но начинать с чего-то надо. И такие статьи часто являются отправной точкой.
Как классно когда только одним коммитом в определенную ветку за несколько минут собирается проект, прогоняются тесты, поднимается сервис и все это без участия кого-либо, пока ты ходил за чашечкой чая, а не к девопсу «на поклон». Ведь это только первый шаг к тому чтобы качественно подготовиться к релизу. И таких шагов может быть увы много …
P.S.
Автору респект, однако согласен в тексте есть шероховатости и есть куда рости чтобы мануал стал безупречным.
Настройка конвейерной сборки Java-проектов в GitLab