Комментарии 16
Важно, что в версии 1.0 все операции по одному проекту (build, deploy, cleanup) должны выполняться с одного хоста. Это означает, что в CI-системе должен использоваться фиксированный worker. При этом нет никаких ограничений по параллельности заданий: werf этот вопрос полностью разруливает. Также можно распределить разные проекты по разным worker’ам.
Читал по диагонали. Ничего не понял. Прошу дать комментарии. Т.е. как я понял из этого описания — кубернетес экзекутор гитлаба не подойдёт, т.к. фактически каждый под будет уникален и верфь не сможет внутри себя синхронизировать состояние ?
Версия 1.2: март-апрель 2020 г.
Т.е. из этого я понимаю, что озвученный мною функционал пока отсутствует, ну, ок
Получается, лично для меня выход — ждать 1.2.
Всё верно, werf требует наличия сборочного кэша на всех этапах. И этот сборочный кэш не ограничен только docker-образами (stages).
На текущий момент поддерживается работа только на одном узле. При желании можно запустить docker-in-docker (issue), но мы не рекомендуем данный подход.
[[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 есть такие кеши, но скорее всего есть.
Кэши есть S3 и, кажется, от Гугла.
Можно даже самостоятельно делать импорт в начале job и экспорт архива с образами в конце. Если job-ы не запускаются параллельно, то такая схема будет работать. Иначе будут проблемы, связанные с тем, что образы стадий будут перетираться и инвалидироваться в параллельных процессах — нарушится целостность + это очень долго.
Вывод: подождать реализации распределённой сборки, где мы учтём все тонкости.
Кеши в S3 будут сохраняться по разным директориям в зависимости от индекса параллельного job.
Привет.
А поясни, плиз, при чем здесь "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 обязательно в планах, но несколько позже, пока ничего не могу сказать по срокам
Я открыл главную и кажется понял, в чем проблема. У нас там большими буквами в самом верху написано "CLI tool to construct CI/CD pipelines". Это полный провал с нашей стороны. Должно быть так: "CLI tool to use in your CI/CD pipelines`".
— 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 глобальных (для продвинутых случаев)
Самый сок, кмк, в том, что argo объединяется с flux
https://www.weave.works/blog/argo-flux-join-forces
https://www.intuit.com/blog/technology/introducing-argo-flux/
Представляем werf 1.0 stable: при чём тут GitOps, статус и планы