Comments 4
Так же кажется странной установка компонентов GitLab НЕ в Kubernetes а на отдельные ВМ.
Кэширование есть и в docker-е, но в Dappfile можно определить зависимость пересборки от изменений в определённых файлах — такого нет в gitlab. И ещё проблема — чистка ненужных образов, gitlab тут не сильно помогает, даже немного вредит, не давая прав через CI_JOB_TOKEN.
С выкатом через интеграцию с kubernetes не сталкивался вплотную, но из документации складывается впечатление, что это некий свой выкат через использование API или kubectl. Второй вариант — Clusters использует helm, но ещё не совсем готов. Если clusters в Gitlab CE будет уметь ожидать успешности выката (запуск helm это выдача задания в tiller и выход), то будем брать на вооружение.
GitLab НЕ в Kubernetes
Некоторым заказчикам мы ставим gitlab в Kubernetes, эту тему можно даже в отдельную статью превратить. А для демонстрационного стенда проще настроить две ВМ — gitlab в vagrant-е + minikube. Есть особенность, что если собирать образы тем же docker, который установлен в minikube, то kubelet будет уничтожать образы стадий по мере сборки. Поэтому для сборки нужен свой отдельный docker, настройка получается сложнее. Опять же можно использовать ВМ по отдельности, например, запустить только gitlab, чтобы отладить пайплайн.
На всех DevOps проектах с которыми мне приходилось сталкиваться, в качестве репозитория артефактов (в т.ч. Docker Registry) использовали Nexus либо Artifactory, в которых нет пробоем с вычисткой и с доступом. К тому же такой подход позволяет организовать хранение всех проектных артефактов в одном месте (npm, pypi, docker, maven, etc).
Выкатка через интеграцию k8s возможна через Deployment update (replace) либо patch. Всё это отлично ложится на CI GitLab`a.
По поводу использования helm всё зависит как Вы организуете CI/CD для выкатки чартов, но тут так-же всё можно сделать достаточно красиво.
По поводу установки GitLab в k8s — быстрее поставить в minikube (helm install… буквально в одну команду) чем описывать процесс с vargant и отдельными ВМ, раз уж это не являляется целью данной публикации. Но это безусловно ИМХО
А можно поподробнее про «kubelet будет уничтожать образы стадий по мере сборки»??
Речь про DIND?
Попробую разъяснить сразу два момента. Упрощённо dapp работает таким образом, что сборка разделена на 4 стадии. Каждая стадия это образ (с тэгом), который можно запушить в registry. Таким образом, для одной сборки в registry попадёт несколько тэгов. По мере разработки появляется дерево образов, когда сборка, например, новой ветки основана на стадии предыдёщей сборки — это и есть кэширование.
Проблем с очисткой как таковой в целом нет — dapp умеет смотреть что есть в registry и давать команды на удаление. Это скорее неудобство, что gitlab при запуске задачи ci не даёт токен с правами на удаление образов в Registry, хотя пользователь такие права имеет и приходится создавать токен отдельно — такая же ситуация будет с любым registry.
Про kubelet очень просто — он чистит локальный registry от тэгов, которых нет в ресурсах. И, если собирать dapp-ом на том же docker-е, то возникает ситуация, что dapp собрал стадию, а kubelet её тут же удалил.
По поводу использования helm всё зависит как Вы организуете CI/CD для выкатки чартов, но тут так-же всё можно сделать достаточно красиво.
Критичная фича — ожидание выката helm релиза. dapp следит за этим, а Clusters надо пробовать. Это всё конечно «исторически сложилось» — выкат через helm был реализован в dapp, ещё когда много клиентов были на 9-ой версии gitlab, где интеграции с k8s не было.
По поводу установки GitLab в k8s — быстрее поставить в minikube
Тут полностью согласен, установка в куб больших приложений очень проста. Цель статьи показать как у нас в большинстве проектов настроен CI и получить стенд для экспериментов с gitlab + k8s.
dapp умеет работать с remote docker, есть успешные попытки запускать сборку в pod-е с docker-dind и dapp. Но основное препятствие использовать gitlab в кубе для сборки — как быть с монтированием. Т.е. вариант с двумя ВМ заведомо рабочий для всех вариантов сборки. А вариант с gitlab в кубе это более сложная конструкция, которая тянет на отдельную статью.
Сборка и дeплой приложений в Kubernetes с помощью dapp и GitLab CI