Comments 17
, а автоматизировать процесс будем с помощью werf
не избыточно?
Обстоятельная статья, спасибо. Большой поклонник гитлаба, но самое неприятное пайплайны настраивать. Если ли способ сэмулировать шаги?
И чтобы два раза не вставать. Бросьте плиз актуальную доку интеграции с кубером. Насколько она хороша по сравнению с argocd?
Чем этот подход принципиально лучше запуском 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 и выполнить мой скрипт.
Отличная статья, спасибо! От себя могу сказать, что установка 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 именно для статьи. Но помимо процесса установки и оплаты все остальные шаги и методики так или иначе подходят для платной версии
Автоматизируем сборку и деплой приложения в GitLab CI/CD: подробное руководство с примерами