Представляем werf 1.0 stable: при чём тут GitOps, статус и планы

[gecube]

Важно, что в версии 1.0 все операции по одному проекту (build, deploy, cleanup) должны выполняться с одного хоста. Это означает, что в CI-системе должен использоваться фиксированный worker. При этом нет никаких ограничений по параллельности заданий: werf этот вопрос полностью разруливает. Также можно распределить разные проекты по разным worker’ам.

Читал по диагонали. Ничего не понял. Прошу дать комментарии. Т.е. как я понял из этого описания — кубернетес экзекутор гитлаба не подойдёт, т.к. фактически каждый под будет уникален и верфь не сможет внутри себя синхронизировать состояние ?

Версия 1.2: март-апрель 2020 г.

Т.е. из этого я понимаю, что озвученный мною функционал пока отсутствует, ну, ок
Получается, лично для меня выход — ждать 1.2.

[aigrychev]

Всё верно, werf требует наличия сборочного кэша на всех этапах. И этот сборочный кэш не ограничен только docker-образами (stages).

На текущий момент поддерживается работа только на одном узле. При желании можно запустить docker-in-docker (issue), но мы не рекомендуем данный подход.

[ReDev1L]

/etc/gitlab-runner/config.toml

[[runners]]
name = "CI server"
url = ""
token = ""
executor = "docker"
environment = ["DOCKER_DRIVER=overlay2"]
[runners.custom_build_dir]
[runners.docker]
tls_cert_path = "/etc/gitlab-runner/certs"
tls_verify = true
image = "docker:stable"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
shm_size = 0
[runners.cache]
Type = "s3"
Shared = true
[runners.cache.s3]
ServerAddress = ""
AccessKey = ""
SecretKey = ""
BucketName = "ci-cache"
BucketLocation = "us-east-1"


Если включить priveleged и добавить tmp и home/.werf в volumes, неужели не заработает?
Гитлаб всё пакует в архив и отправляет на S3.
Я не уверен что в kubernetes executor есть такие кеши, но скорее всего есть.

[VolCh]

Кэши есть S3 и, кажется, от Гугла.

[aigrychev]

Можно даже самостоятельно делать импорт в начале job и экспорт архива с образами в конце. Если job-ы не запускаются параллельно, то такая схема будет работать. Иначе будут проблемы, связанные с тем, что образы стадий будут перетираться и инвалидироваться в параллельных процессах — нарушится целостность + это очень долго.

Вывод: подождать реализации распределённой сборки, где мы учтём все тонкости.

[ReDev1L]

Забыл про concurrency, да.
Кеши в S3 будут сохраняться по разным директориям в зависимости от индекса параллельного job.

[gecube]

Кеши в S3 будут сохраняться по разным директориям в зависимости от индекса параллельного job.

Насколько я помню, это не совсем так. В смысле кэш отдельный, например, для каждой ветки может быть — как настроишь. Но все однородные джобы разделяют (шарят) один и тот же кэш

[ReDev1L]

Нет =)

[gecube]

Ну, так правильно. Цифирка после названия ветки — это типа поколения кэша. И увеличивается на единичку, когда кто-то его сбрасывает через кнопку в гуи гитлаба

[ReDev1L]

Вот это фейспалм )) я всё время думал что это из-за concurrent билдов появляется ) Спасибо за срыв покровов )

[allexx]

С уважением отношусь к тем усилиям, что вы тратите на освещение вашей CLI утилиты и качеству оформления материалов, но никак не пойму кто ваша ЦА? Все что делает werf на 146% перекрывается более продвинутыми и популярными сервисами и утилитами. У разных аудиторий разный выбор от travis, circleci, gitlab ci до argocd и teckton pipelines. Всюду есть продвинутые решения с кешированием сборки, DIND и огромной коллекцией лучших решений для чего угодно (тот же circleci orbs circleci.com/orbs/registry) для push-еров CD с UI. Почему не помочь развитую чего-то известного аля tekton и, например, написать продвинутый модуль (аля triggers) или просто делать его более стабильным?

[distol]

Привет.

А поясни, плиз, при чем здесь "travis, circleci, gitlab ci до argocd и teckton pipelines"? У нас нет вообще ничего про CI часть и никогда не будет.

Есть задача: "вот есть реп, нужно сделать, чтобы в кубе было тоже самое, что в репе". Привести kubernetes в состояние с git. Чтобы это сделать нужно, всего то, вызвать docker build, docker tag, docker push и helm install. В этом смысле – конечно, перекрывается. Ну а дальше много нюансов.

Что касается tekton и, вцелом, интеграции с другими CI-системами. Сейчас у нас есть два пути – штатная поддержка gitlab ci и возможность использовать что угодно через переменные окружения, есть только важный момент, что мы сейчас ограничены работой на одном хосте (см. в статье выше). Прямо сейчас мы пилим поддержку Github Actions. Явная поддержка Tekton обязательно в планах, но несколько позже, пока ничего не могу сказать по срокам

[distol]

Я открыл главную и кажется понял, в чем проблема. У нас там большими буквами в самом верху написано "CLI tool to construct CI/CD pipelines". Это полный провал с нашей стороны. Должно быть так: "CLI tool to use in your CI/CD pipelines`".

[allexx]

Позволю себе сравнить werf c ArgoCD:
— Build And Publish A New Container Image
— CD into k8s с такими возможностями argoproj.github.io/argo-cd/#features (есть Helm, UI мордочка, деплой в разные кластеры ...)

Итого комбинация Skaffold (для Dev+CI) и ArgoCD мне видится покрывающий что у вас есть и немного сверху.

Еще бóльшую гибкость можно получить добавив Tekton как CRD для описания workflow глобальных (для продвинутых случаев)

[gecube]

Самый сок, кмк, в том, что argo объединяется с flux

https://www.weave.works/blog/argo-flux-join-forces
https://www.intuit.com/blog/technology/introducing-argo-flux/