Как стать автором
Обновить

Автоматизируем сборку и деплой приложения в GitLab CI/CD: подробное руководство с примерами

Уровень сложностиПростой
Время на прочтение22 мин
Количество просмотров19K
Всего голосов 36: ↑35 и ↓1+34
Комментарии17

Комментарии 17

, а автоматизировать процесс будем с помощью werf

не избыточно?

ну конечно ребята из Флант будут использовать свои in-house тулы) почему избыточно?

Обстоятельная статья, спасибо. Большой поклонник гитлаба, но самое неприятное пайплайны настраивать. Если ли способ сэмулировать шаги?

И чтобы два раза не вставать. Бросьте плиз актуальную доку интеграции с кубером. Насколько она хороша по сравнению с argocd?

gitlab ci и argocd - абсолютно разные вещи. argocd - полноценная gitops платформа, заточенная конкретно на деплой в кубер. gitlab - классическая ci/cd платформа для любых задач.

Деплоить в кубер конечно удобнее через argo, сборку и тестирование - классической CI системой.

Чем этот подход принципиально лучше запуском gitlab джобы, которая собирала бы образ обычным докером и деплоем в кубер через helm install/update? В теории можно даже без репозитория образов такую схему собрать

Если вы запустите джобу 2 раза у вас будет 2 собранных образа или один? А если два, то будут ли они одинаковые, или могу получиться разные? А если они запустятся на двух разных раннерах? Должна ли сборка, запущенная дважды на одном коммите давать одинаковый результат или может давать разный?

Ну, без docker registry в любом случае не обойтись - сам образ контейнера кубер должен откуда-то взять.

Чем лучше - вопрос хороший ) Почему авторы werf предлагают использовать werf вместо голого helm - понятно. Лично я не использовал werf, но использовал GitOps-решения (flux). Мои впечатления - GitOps хорош для управления на уровне кластера/неймспейса, но отдельные микросервисы я бы предпочел деплоить хелмом. Особенно в связке с GitLab'ом, где из коробки есть флоу, когда, к примеру, деплой на staging идёт автоматом, а на production - по ручному аппруву.

Но, повторюсь, сам werf я не использовал. Его даже не позиционируют как GitOps (хотя по описанию werf не очень понятно почему). Так что может им действительно удобнее

Как сделать "hello world" в 2024.

Н-да. Явно не в два клика. Я для своих проектов обхожусь без локального гитлаба, werf, kubectl и всего такого прочего. Docker Compose + git + скрипт на bash/zsh + Gitlab Runner. Вот и все, что нужно на VPS. Пайплайн тривиален: подключиться к машине по ssh и выполнить мой скрипт.

Для своих проектов это вполне норм подход, да. Я примерно таким же образом собирал LaTeX-документы :) Но задачи ведь разные бывают, и проекты…

Отличная статья, спасибо! От себя могу сказать, что установка GitLab'а на виртуалках по описанию понравилась больше, чем поднятие его же на двух docker-контейнерах (под сам gitlab + runner). С докер-подходом больше внезапных граблей с дефолтным конфигом, настройкой reverse-proxy, обеспечения сборки докер-образов внутри докера и т.д. Хотя он тоже работает.

Ещё совет тем, кто хочет попробовать настроить себе CI/CD: gitlab сейчас будет советовать 2 фичи - хорошо подумайте, прежде чем согласиться ) Первая фича - Auto DevOps. В идеале - у вас будет сборка, тесты и деплой в кубернетес просто так. Вообще ничего делать не надо. Из проблем - если вам нужно что-то кастомизировать, то это сложно. А ещё это медленно работает. И я считаю, что buildpacks и heroku - это какое-то переусложненное решение проблемы сборки, в которой за пару дней можно с нуля разобраться.

Вторая фича - как раз GitOps (flux) для деплоя. На мой взгляд, само по себе настраивается сложно, а оправдано наоборот, только в очень простых случаях (деплоим сразу в прод).

Спасибо :)

Про докер вспомнилось, как не так давно поднимал в нем Gitea - там тоже были какие-то дополнительные телодвижения не совсем очевидные сходу, чтобы заработал SSH.

Насчет GitOps боюсь вы ошибаетесь. Как раз таки потенциала там в разы больше и когда у вас пару десятков микросервисов каждый со своим хелм чартом, и по паре кластеров для каждой команды разработки, не считая стейджингов и прода - деплоить это все тем же ArgoCD куда как проще, чем обслуживать зоопарк из десятков разных пайплайнов.

Попробуйте как нибудь тулы от Argo, мне кажется они медленно и верно двигаются в сторону стандарта де-факто для CD в кубер.

Кстати, устанавливать мы будем бесплатную версию — GitLab Community Edition

К сожалению, CE нормально настроить (для code review в частности) невозможно, для этого разработчики в бесплатной версии отключили всё самое нужное.

Я бы хотел предостеречь от использования данного софта, вот.

можете рассказать подробнее?

У меня сейчас нет под руками гитлаба.

По памяти - в ce нельзя например не давать сливать merge request без аппрува конкретного человека/людей из списка. Были ещё какие-то ограничения, уже не помню деталей. Причём в более ранних версиях данных ограничений не было, их прямо добавили специально.

В общем на гитлабе бесплатно процесс review не построить, если условно больше 3 человек.

Кроме того гитлаб - украинский, купить для него лицензию немножко сложно.
Существуют кряки, но сами понимаете..

Ну, мы использовали CE именно для статьи. Но помимо процесса установки и оплаты все остальные шаги и методики так или иначе подходят для платной версии

Зарегистрируйтесь на Хабре, чтобы оставить комментарий