Comments 14
Напомню коллегам что пока поддерживаться в k8s сборка только через Dockerfile.
Долгое время у нас была поддержка только Dockerfile с Buildah, но сейчас можно использовать и Stapel (с несущественными ограничениями).
Немного деталей для прояснения комментария:
Образы, собираемые werf, можно описывать с помощью Dockerfile или нашего собственного синтаксиса — Stapel.
Собирать образы можно опять-таки используя два различных бэкенда — Docker-демон или Buildah (userspace сборка, именно этот вариант должен использоваться в K8s).
Вопрос, а зачем gitlab-agent? Установку вижу, цель использования не вижу. Я пробовал все варианты связки гитлаба с кубом, отказался от всех и остался только с ранером.
Позволяет присоединять кластеры куба за NAT, в режиме реального времени общаться с API K8s по ws (может понадобиться для сбора метрик Prometheus), etc.
Вот тут здорово описано, даже с FAQ. В описанном случае, сработало бы и без. Но хотел поделиться настройкой kas, потому что она на тот момент была плохо описана. Думаю, что вскоре к этой связке прикрутят еще много разных интсрументов.
Ранеры в кубе и за натом нормально работают.
Прометей в кластере куда надёжней для сбора метрик, а его проще через федерацию научить шарить данные.
Согласно ЧаВО идёт работа с апи куба и кеширование, вопрос остаётся неизменным зачем троллейбус?
Ваши мысли относительно того, что прикрутят интересная теория, но учитывая развитие opstrace мне видится, что развитие будет идти иначе.
Есть какие нибудь другие полезные инструменты, для которых надо ставить и настраивать по kas?
Напишите статью про ранер?
Я делаю так:
helm upgrade --install gitlab-runner gitlab/gitlab-runner \
-n gitlab-runners --create-namespace --set rbac.create=true \
--set rbac.clusterWideAccess=true --set gitlabUrl="https://gitlab.com/" \
--set runners.secret=gitlab-runner-secret --set rbac.rules[apiGroups=['*'],resources=['*'],verbs=['*']] \
--set runners.config=
[[runners]]
[runners.kubernetes]
namespace = "{{.Release.Namespace}}"
image = "ubuntu:22.04"
resource_availability_check_max_attempts = 5
service_account = "{{ if .Values.rbac.create }}{{ include "gitlab-runner.fullname" . }}{{ else }}"{{ .Values.rbac.serviceAccountName }}"{{ end }}"
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: gitlab-runner-secret
type: Opaque
data:
runner-registration-token: "<TOKEN>"
EOF
Не знаю как из этого сделать целую статью.
Подскажите, а в чем плюс этого решения по сравнению с Gitlab AutoDevOps, который работает из коробки и умеет ещё и тесты запускать, как минимум, кроме просто деплоя?
Как по мне, недостаточно гибкости инструмента. Если хочется сократить таким образом .gitlab-ci.yaml— то да. Если же хочется в автоматизацию — то лучше использовать GitOps инструменты для CD, например, FluxCD, AgroCD
GitOps-тулзы не покрывают весь CI/CD, они обычно отвечают только за доставку релиза в контур кубернетес определённым способом.
Если есть желание/потребность построить полный флоу CI/CD с использованием GitOps на основе pull-модели, то есть вариант совместной работы werf+argocd как на следующей схеме: https://werf.io/documentation/v1.2/advanced/ci_cd/werf_with_argocd/ci_cd_flow_overview.html#reference-cicd-flow.
Интересный тезис. Расскажите про какую именно автоматизацию речь? Работал с Argo - показалось, что плюсом над werf только reconciliation (приведение обратно в нужное состояние).
Мне очень понравилось, что внутри werf есть поддержка helm secrets из коробки, да и аналог image uploader для ArgoCD, тоже уже встроен.
GitLab + K8s + Werf